Hi Segher and Peter,
Thanks a lot for your insightful comments on this.
I just read through all discussions and plan to give a
try as replied below.
on 2022/8/31 23:24, Segher Boessenkool wrote:
> On Wed, Aug 31, 2022 at 05:33:28PM +0800, Kewen.Lin wrote:
>> Test case bswap64-4.c suffers the issue as its comments:
>>
>> /* On some versions of dejagnu this test will fail when
>> biarch testing with RUNTESTFLAGS="--target_board=unix
>> '{-m64,-m32}'" due to -m32 being added on the command
>> line after the dg-options -mpowerpc64.
>> common/config/rs6000/rs6000-common.c:
>> rs6000_handle_option disables -mpowerpc64 for -m32. */
>>
>> As tested, on test machine with dejaGnu 1.6.2, the compilation
>> option order looks like: -m32 ... -mpowerpc64, option
>> -mpowerpc64 still takes effect; While on test machine with
>> dejaGnu 1.5.1, the option order looks like: -mpowerpc64 ... -m32,
>> option -mpowerpc64 is disabled by -m32, then the case fails.
>
> *Should* -mpowerpc64 be disabled by -m32?
I think the reason to disable -mpowerpc64 at -m32 is that we have
-mpowerpc64 explicitly specified at -m64 (equivalent behavior).
In the current implementation, when -m64 is specified, we set the
bit OPTION_MASK_POWERPC64 in both opts and opts_set. Since we
set OPTION_MASK_POWERPC64 in opts_set for -m64, when we find the
OPTION_MASK_POWERPC64 is ON in opts_set, we don't know if there
is one actual cmd-line option -mpowerpc64 or just -m64.
Assuming there is -m32 given after -m64 in cmd-line option, it's
also unclear how OPTION_MASK_POWERPC64 in opts_set is set, so
to keep conservative it has to disable -mpowerpc64 to ensure
the options like "-m64 -m32" not to have OPTION_MASK_POWERPC64
ON, just like what we have when just specifying "-m32".
Without any explicit -mpowerpc64 (and -mno-), I think we all agree
that -m64 should set OPTION_MASK_POWERPC64 in opts, conversely -m32
should unset OPTION_MASK_POWERPC64 in opts.
To make -m32/-m64 and -mpowerpc64 orthogonal, IMHO we should not
set bit OPTION_MASK_POWERPC64 in opts_set for -m64. I'm not sure
if there is some particular reason why we set OPTION_MASK_POWERPC64
in opts_set, I hope no. :) One possible reason I can imagine is
that we want to get the cmd-line options "-mno-powerpc64 -m64" not
raise error, but I think having it to error makes more senses.
So if no objections I'm going to give it a shot like:
```
Iff -mpowerpc64 (or -mno-powerpc64) is specified, the bit
OPTION_MASK_POWERPC64 in opts_set is set. Either -m64 and -m32
will leave OPTION_MASK_POWERPC64 in opts alone, it only honors
the specified option, and we will raise error for "-m64" +
"-mno-powerpc64" (either order).
When no explicit -mpowerpc64 (or -mno-powerpc64) is provided,
for -m64, set bit OPTION_MASK_POWERPC64 in opts; while for -m32,
unset bit OPTION_MASK_POWERPC64 in opts. Both will not touch
OPTION_MASK_POWERPC64 in opts_set.
```
btw, I guess the option compatibility isn't an blocking issue
here, right?
BR,
Kewen
