On Fri, 31 Dec 2021, FX via Gcc wrote: > The reason I ended up in this rabbit hole is that I am implementing some > handling of signalling NaNs in libgfortran. Could someone either confirm > that the behavior observed above is a bug, or if not, kindly explain to > me why it happens?
1. You should use -fsignaling-nans if you want signaling NaNs to work correctly. 2. I suspect this has the same, or similar, underlying cause to bug 86367 (whatever that cause is): something is interpreting conversions between types with the same floating-point format (in this case, the same type but using a typedef name on one side of the conversion) as being a convertFormat operation - but apparently only without -fsignaling-nans. 3. There is probably a reasonable case for interpreting such conversions (including casts) as copy operations instead, including in the absence of -fsignaling-nans; C23 Annex F leaves that implementation-defined, and handling such conversions as copy operations is likely to be more predictable and more useful. 4. Note however that in some cases the ABI may mean the conversion has to be treated as convertFormat (returning float or double on 32-bit x86, in particular, because that return uses an x87 register). 5. In other cases on 32-bit x86, the failure of GCC to model excess precision explicitly by default (instead pretending the machine has SFmode and DFmode loads and stores) makes it hard to avoid spurious conversions (even in some cases where there is no floating-point operation or lvalue-to-rvalue conversion at all in the abstract machine and so -fsignaling-nans shouldn't be needed at all, see bugs 58416, 71460, 93934). -- Joseph S. Myers jos...@codesourcery.com
