Re: [PATCH] rs6000/test: Fix bswap64-4.c with has_arch_ppc64 [PR106680]

["Kewen.Lin" <linkw@linux.ibm.com>]

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