This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] MIPS: IEEE 754-2008 features support

"Maciej W. Rozycki" <> writes:
>> >  Please also note that the writability of the individual new (HAS2008) 
>> > FCSR bits is optional e.g. a conforming processor may have NAN2008 
>> > hardwired to 1 and ABS2008 hardwired to 0 (or likewise with NAN2008 
>> > writable).
>> OK, I'd missed that this was allowed, sorry.  It just seems really
>> unfortunate...
>  Well, I'm not really sure what the Big Plan here is.  It looks to me like 
> the non-arithmetic ABS/NEG feature is a really good thing,

Me too. :-)

> while the 2008 
> NaN encoding has its shortcomings, e.g. unlike with the legacy encoding 
> there's no single sNaN bit pattern to preset FPRs or variables with to 
> catch uninitialised use that would work across all the floating-point 
> formats (S, D and PS).  So it seems to me like there's no single superior 
> setting we could make the default for a group option.

I see what you mean, and I suppose it wouldn't be too bad having
separate -mabs=2008 and -mmac=2008 options for the legacy IEEE case.
But when going to the trouble of switching NAN encoding, which needs a
separate runtime, it seemed a shame that we couldn't also rely on the
new improved ABS/NEG behaviour in that runtime too.  Instead we have
to potentially pass all three of -mnan=2008 -mabs=2008 -mmac=2008
in order to get what other targets get.  Oh well...

>> >  It is needed in case the compiler was built without support for this 
>> > option i.e. configured against old binutils.  I verified that it indeed 
>> > triggered in this case:
>> >
>> > Executing on host: mips-linux-gnu-gcc  -fno-diagnostics-show-caret -fdiagnostics-color=never  -mnan=2008 -c  -o mips_nan21474.o mips_nan21474.c    (timeout = 300)
>> > mips-linux-gnu-gcc: error: unrecognized command line option '-mnan=2008'
>> > compiler exited with status 1
>> > output is:
>> > mips-linux-gnu-gcc: error: unrecognized command line option '-mnan=2008'
>> That seems like bad practice though.  In other cases we leave the
>> assembler to report options that it doesn't understand.  I think that's
>> better because it's then clearer that the assembler needs to be upgraded.
>> Within config/mips, the configure test should just control whether it's
>> safe to use .nan when no -mnan option has been given.  (This is what we
>> did for -mmicromips vs ".set nomicromips" FWIW.)
>  I can see your point and acknowledge the preexisting practice, but I 
> don't feel particularly convinced, especially in this case where we have a 
> feature that's never going to raise the user's attention when 
> miconfigured, but it also applies to the microMIPS case.  The two issues I 
> see with it are:
> 1. Conceptually I see the toolchain as a whole and I don't see a value in 
>    GCC producing known-unsupported assembly and relying on the assembler 
>    (or the linker if applicable) to complain.  I agree pointing at the 
>    other tool being incapable or obsolete is a useful practice, but I also 
>    think a clear message from GCC itself would be more appropriate (e.g. 
>    "`-mfoo' unsupported, please reconfigure against current binutils").

But doing that consistently would mean e.g. that we would need to test
assembler support for each individual -march= option, since new -march=
options are added fairly often.  It seems a lot of hassle to do that
just so that we can force the user to rebuild GCC from the same sources
as before.  I think it's more user-friendly to include support for -mfoo
and assume that the assembler supports whatever's needed -- leaving it
to issue an error if not -- both because the problem tool is the one that
reports the error, and because we don't force users to rebuild GCC when
the first build could quite easily have had the feature they wanted.

> 2. Technically I think we have an actual problem here, e.g. in the example 
>    you referred we have a situation where GCC supports microMIPS 
>    compilation in all cases, however non-microMIPS code is different
>    depending on whether the compiler has been configured against modern or 
>    obsolete binutils.  Now the latter case may prompt someone to upgrade
>    binutils, but there is nothing to prompt that person to reconfigure GCC
>    afterwards.  As a result we have two cases of a toolchain comprised of 
>    the same versions of both GCC and binutils, but depending on the 
>    "history" of the GCC binaries code produced will be different.  I think
>    this is subtler and riskier than just rejecting the relevant compiler 
>    option outright.

I think your argument is that it's bad for things like
__attribute__((nomicromips)) to produce different code depending on the
configured assembler, and that we should therefore just reject the attribute
if the assembler doesn't support ".set nomicromips".  Is that right?
That has negative consequences too though.  People often use GCC version
checks to decide whether an attribute is supported.  Conditionally
disabling even nomicromips would force users to have an autoconf-style
test instead.  And the point is that __attribute__((nomicromips))
indicates that the user _doesn't_ want a function to be micromips,
so it wouldn't be very friendly to force them to upgrade to a binutils
that does support micromips and then rebuild GCC.

Instead the idea is that __attribute__((nomicromips)) should behave in
the same way as when nomicromips is the default.

> Applying this to the 2008-NaN case the compiler would have to refrain from 
> producing the .nan directive in the legacy case if built against old 
> binutils but would produce the directive regardless in the 2008 case.  I 
> don't feel safe with such an arrangement.

Hmm, I think you're arguing against something different from what I was
suggesting.  I was saying that (within config/mips) the configure test
should just control whether it's safe to use .nan _when no -mnan option
has been given_.  (I.e. it shouldn't affect the case when -mnan is passed.)
If no option is given, we should put a ".nan legacy" in there anyway for
good measure if possible, but we can't if binutils is too old.  That's
already what your patch does and I think we should keep that bit.

I was suggesting that the behaviour of the -mnan option should be
the same regardless of which version of binutils you use.  It should
always pass the -mnan down to the assembler, and it should always
generate the .nan directive.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]