https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101953
--- Comment #28 from Jakub Jelinek ---
That flag does work:
gcc -fsanitize=float-cast-overflow -Wall -o pr101953{,.c} -lm; ./pr101953
pr101953.c:12:11: runtime error: -32000 is outside the range of representable
values of type 'unsigned int'
-32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101953
--- Comment #27 from Harald van Dijk ---
(In reply to jos...@codesourcery.com from comment #25)
> The option to use to detect this is -fsanitize=float-cast-overflow (note:
> I haven't tested if it detects this particular case). As per the manu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101953
--- Comment #26 from M W ---
pi@raspberrypi:~ $ gcc -fsanitize=float-cast-overflow -Wall -o badpi badpi.c
-lm
pi@raspberrypi:~ $
That flag doesn't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101953
--- Comment #25 from joseph at codesourcery dot com ---
The option to use to detect this is -fsanitize=float-cast-overflow (note:
I haven't tested if it detects this particular case). As per the manual:
"Unlike other similar options, @option{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101953
--- Comment #24 from M W ---
I know it is documented as "undefined," but it is also unexpected without even
a warning. Anyone maintaining code and/or porting to rpi will simply not expect
this behavior. I certainly didn't. I had been using my co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101953
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101953
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101953
--- Comment #21 from Andrew Pinski ---
(In reply to M W from comment #18)
> I can't believe that this is acceptable. Shocked. in fact.
You should read bug 323.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101953
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101953
M W changed:
What|Removed |Added
Resolution|INVALID |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101953
--- Comment #18 from M W ---
I can't believe that this is acceptable. Shocked. in fact.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101953
--- Comment #17 from Andrew Pinski ---
(In reply to M W from comment #15)
> I'm quite sure that is impacting way more projects than have realized it.
Almost all of the open source ones have been fixed years ago. Both with IBM
and ARM doing a l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101953
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101953
M W changed:
What|Removed |Added
Resolution|INVALID |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101953
--- Comment #14 from Andrew Pinski ---
MIPS64 does:
trunc.w.d $f0,$f0 ; int
c.le.d $fcc0,$f1,$f0
bc1t$fcc0,.L2
nop
trunc.w.d $f0,$f0
mfc1$2,$f0
b .L3
nop
.L2:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101953
--- Comment #13 from Andrew Pinski ---
Newer PowerPC does:
fctiwz 0,0 ; int
fctiwuz 0,0 ;unsigned
Older PPC does:
fctiwz 0,0 ; int
fctidz 0,0 ; unsigned
So it depends on which generation of PowerPC ISA you use.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101953
--- Comment #12 from Andrew Pinski ---
For aarch64 we do:
fcvtzs w0, d0 ; int
fcvtzu w0, d0 ; uint32_t
For ARM:
vcvt.s32.f64s15, d16 ; int
vcvt.u32.f64s15, d7 ; uint32_t
For x86 we do:
cvttsd2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101953
--- Comment #11 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #10)
> 6.3.1.4 Real floating and integer
> 1 When a finite value of real floating type is converted to an integer type
> other than _Bool,
> the fractional part is di
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101953
--- Comment #10 from Andrew Pinski ---
6.3.1.4 Real floating and integer
1 When a finite value of real floating type is converted to an integer type
other than _Bool,
the fractional part is discarded (i.e., the value is truncated toward zero). I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101953
Andrew Pinski changed:
What|Removed |Added
Resolution|DUPLICATE |INVALID
--- Comment #9 from Andrew Pins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101953
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101953
M W changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101953
--- Comment #6 from M W ---
"Unexpected because not understanding C/C++ standard is normal these days."
I'm sort of ticked off by that. I have used some form of this code for over two
decades on a lot of different platforms. Mac, Windows, Linu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101953
--- Comment #5 from Andrew Pinski ---
>it is unexpected.
Unexpected because not understanding C/C++ standard is normal these days.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101953
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101953
M W changed:
What|Removed |Added
Resolution|INVALID |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101953
Andreas Schwab changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101953
--- Comment #1 from M W ---
This also happens on C++
28 matches
Mail list logo
