Bug 121807 - compare (<, <=, >=, >) with NAN is not raising "invalid"
Summary: compare (<, <=, >=, >) with NAN is not raising "invalid"
Status: RESOLVED DUPLICATE of bug 34678
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 15.2.1
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-09-05 13:03 UTC by Fred J. Tydeman
Modified: 2025-09-05 17:11 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Fred J. Tydeman 2025-09-05 13:03:46 UTC
This code fails:
#include <assert.h>
#include <limits.h>
#include <errno.h>
#include <stdio.h>
#include <float.h>
#include <fenv.h>
#include <math.h>

int main(void){

  if(1){
    int i;
    int flags;
    feclearexcept( FE_ALL_EXCEPT );
    if( !(NAN > 0.f) ){		/* raise invalid */
      i = 1;
    }else{
      i = 0;
    }
    flags = fetestexcept( FE_ALL_EXCEPT );
    assert( 0 != flags );	/* fails here */
  }
  return 0;
}

C23: 7.12.17 Comparison macros
The descriptions of the various macros mention that the relational operators raise invalid
Comment 1 Drea Pinski 2025-09-05 13:09:45 UTC
Can you provide the output of gcc -v. This is very much target specific.
Comment 2 Fred J. Tydeman 2025-09-05 13:47:02 UTC
Using built-in specs.
COLLECT_GCC=gcc                                                                                                              
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/15/lto-wrapper                                                      
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa                                                                                
OFFLOAD_TARGET_DEFAULT=1                                                                                                     
Target: x86_64-redhat-linux                                                                                                  
Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,m2,cobol,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --enable-libstdcxx-backtrace --with-libstdcxx-zoneinfo=/usr/share/zoneinfo --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl=/builddir/build/BUILD/gcc-15.2.1-build/gcc-15.2.1-20250808/obj-x86_64-redhat-linux/isl-install --enable-offload-targets=nvptx-none,amdgcn-amdhsa --enable-offload-defaulted --without-cuda-driver --enable-gnu-indirect-function --enable-cet --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux --with-build-config=bootstrap-lto --enable-link-serialization=1        
Thread model: posix                                                                                                          
Supported LTO compression algorithms: zlib zstd                                                                              
gcc version 15.2.1 20250808 (Red Hat 15.2.1-1) (GCC) 

Also, here is what I compile with:
export CFLAGS="-H -std=gnu23 -O0 -march=native -mhard-float -mfpmath=387 -mieee-fp \
 -enable-decimal-float=yes \
 -fexcess-precision=standard \
 -ffloat-store \
 -ffp-contract=off \
 -fmath-errno \
 -fno-associative-math \
 -fno-builtin \
 -fno-cx-limited-range \
 -fno-fast-math \
 -fno-finite-math-only \
 -fno-reciprocal-math \
 -fno-unsafe-math-optimizations \
 -frounding-math \
 -fsignaling-nans \
 -fsigned-zeros \
 -ftrapping-math \
 ${INCS} \
 -I/usr/include/dfp"

This bug has existed in every version of gcc that I have tested since about 2000
(with some support for C99).
Comment 3 Xi Ruoyao 2025-09-05 15:25:44 UTC
The standard only mandates this exception to be raised if #pragma STDC FENV_ACCESS ON, that GCC has not implemented yet.

In this case "!(NAN > 0.f)" is folded to simply "true" and caused the problem, and the standard explicitly says it's allowed without FENV_ACCESS ON:

The purpose of the FENV_ACCESS pragma is to allow certain optimizations that could subvert flag tests and mode changes (e.g., global common subexpression elimination, code motion, and constant folding). In general, if the state of FENV_ACCESS is "off", the translator can assume that the flags are not tested, and that default modes are in effect, except where specified
otherwise by an FENV_ROUND pragma.

Thus this is a dup of 34678 (lacking FENV_ACCESS support), actually.  And 34678 already has a lot of discussion about constant folding.

*** This bug has been marked as a duplicate of bug 34678 ***
Comment 4 Vincent Lefèvre 2025-09-05 17:11:24 UTC
For the particular case of flags that are not raised on comparison with NaN like here, I had already been reported bug 56020, which had also been marked as a duplicate of bug 34678.

Perhaps the title of bug 34678 could be updated to also mention flags.