[Bug sanitizer/111063] New: [UBSAN] Implement "-inf is outside the range of representable values of type 'unsigned long'" to be on par with Clang

[Bug sanitizer/111063] New: [UBSAN] Implement "-inf is outside the range of representable values of type 'unsigned long'" to be on par with Clang

[burnus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111063

            Bug ID: 111063
           Summary: [UBSAN] Implement "-inf is outside the range of
                    representable values of type 'unsigned long'" to be on
                    par with Clang
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: sanitizer
          Assignee: unassigned at gcc dot gnu.org
          Reporter: burnus at gcc dot gnu.org
                CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
                    jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at gcc dot gnu.org
  Target Milestone: ---

Jonathan Wakely wrote in bug 110860 comment 10:
-----------<cut>-------------------------
GCC's ubsan doesn't seem to diagnose this rule:

"A prvalue of a floating-point type can be converted to a prvalue of an integer
type. The conversion truncates; that is, the fractional part is discarded. The
behavior is undefined if the truncated value cannot be represented in the
destination type."

There's no ubsan diagnostic for:

unsigned long i = -HUGE_VAL;

So it doesn't complain about adding log10(0) to a size_t.
-----------<cut>-------------------------


That diagnostic exists in Clang as reported by
Paul Dreik in bug 110860 comment 8:

-----------<cut>-------------------------
When 0 is passed, log10 returns -inf, which can not be converted to an integer.

I had a bit of problem to reproduce this with gcc, but it worked with clang.
The following program:

#include <cstdio>
#include <format>
#include <string_view>

int main(int argc, char* argv[]) {
    [[maybe_unused]] auto x = std::format("{:.292f}", 0.f);
}

causes the following output when compiled with clang-16 using
-fsanitize=undefined -fno-sanitize-recover=all -g -O0:

/opt/compiler-explorer/gcc-snapshot/lib/gcc/x86_64-linux-gnu/14.0.0/../../../../include/c++/14.0.0/format:1496:15:
runtime error: -inf is outside the range of representable values of type
'unsigned long'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
/opt/compiler-explorer/gcc-snapshot/lib/gcc/x86_64-linux-gnu/14.0.0/../../../../include/c++/14.0.0/format:1496:15
in 

Link to reproducer (expected to go stale quick, had to use clang trunk to get a
sufficiently new libstdc++): https://godbolt.org/z/8aGf7YGWs

[Bug sanitizer/111063] [UBSAN] Implement "-inf is outside the range of representable values of type 'unsigned long'" to be on par with Clang

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111063

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
-fsanitize=float-cast-overflow is there, just not turned on by
-fsanitize=undefined .

https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Instrumentation-Options.html#index-fsanitize_003dfloat-cast-overflow

The reasoning on why it is NOT part of -fsanitize=undefined for GCC is located
in this email:
https://gcc.gnu.org/pipermail/gcc-patches/2014-May/388356.html


Specificially this:
```
As with divide-by-zero, this should not be part of -fsanitize=undefined 
because under Annex F this is not undefined behavior (instead it raises 
"invalid" and returns an unspecified value, C11 F.4).
```

That is it is not exactly undefined behavior ...

[Bug sanitizer/111063] [UBSAN] Implement "-inf is outside the range of representable values of type 'unsigned long'" to be on par with Clang

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111063

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Also I tested GCC 13.2.0 with  -fsanitize=float-cast-overflow and GCC does
produce an error message at runtime for the original testcase too.

/opt/compiler-explorer/gcc-13.2.0/include/c++/13.2.0/format:1489:38: runtime
error: -inf is outside the range of representable values of type 'int'

[Bug sanitizer/111063] [UBSAN] Implement "-inf is outside the range of representable values of type 'unsigned long'" to be on par with Clang

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111063

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |NEW
         Resolution|INVALID                     |---
   Last reconfirmed|                            |2023-08-22
     Ever confirmed|0                           |1

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
For C++ it's undefined behaviour. Annex F of the C standard doesn't apply to
C++.

Either the sanitizer should be enabled for C++, or the docs should say that G++
applies the rules of Annex F to floating-point types even where the standard
says it's UB.

[Bug sanitizer/111063] [UBSAN] Implement "-inf is outside the range of representable values of type 'unsigned long'" to be on par with Clang

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111063

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Yet, even for C++ both the compiler middle-end and users assume they can do say
0.0 / 0.0 and get a NaN, not UB etc.  Even for the conversions, the generated
code or library functions just set the resulting integer to minimum or maximum
value of the type depending on what is closer to the value.
So, I think it is good that -fsanitize=undefined doesn't include
-fsanitize=float-divide-by-zero,float-cast-overflow.