On Mon, Jan 24, 2022 at 11:17:00AM +0100, Richard Biener wrote:
> > I think with the 2) patch I achieve what we want for Fortran, for 1)
> > the only behavior from gcc 11 is that
> > -fsanitize-coverage=trace-cmp,trace-cmp is now rejected.
>
> But -fsanitize-coverage=trace-cmp -fsanitize-coverage=trace-cmp is not?
With the incremental patch, the -fsanitize-coverage behavior is simply
that trace-pc is 1 and trace-cmp is 2 (both are required to be pow2p)
and any time trace-cmp appears in the -fsanitize-coverage=, it does |= 2,
any time trace-pc appears there it does |= 1, for -fno-sanitize-coverage=
any times trace-cmp appears it does &= ~2 and trace-pc &= ~1.
> What's the semantics of -fconvert=big-endian
> -fconvert=little-endian,r16_ieeee?
> Does the latter replace big-endian with little-endian but add r16_ieeee?
Yes. big-endian and little-endian is mutually exclusive, so a latter
occurrence of one of those overrides the former. big-endian and r16_ieee
aren't mutually exclusive, different Set, so it is set next to it.
Similarly for
-fconvert=big-endian,r16_ibm -fconvert=little-endian,r16_ieee
the end effect for both is the same as just
-fconvert=little-endian,r16_ieee
But e.g.
-fconvert=big-endian -fconvert=r16_ibm
the effect is -fconvert=big-endian,r16_ibm
> I suppose we could interpret -fFOO=BAR,BAZ as -fFOO=BAR -fFOO=BAZ
> thus process items left-to-right? It's at least odd if
They behave very similarly, the only difference is that in the -fFOO=BAR,BAZ
syntax we error on mutually exclusive options. My rationale is, the
overriding through -fFOO=BAR -fFOO=BAZ if BAR and BAZ are mutually exclusive
is desirable, the two options could come from different make etc. variables
or compiler wrapper scripts or -specs etc. But when it is a single option,
that option comes from a single source only and users should be told they
are doing something weird like -fconvert=little-endian,big-endian,swap
The compiler should hint them that they likely don't know what they want.
Jakub
