[Bug target/95169] i386 comparison between nan and 0.0 triggers Invalid operation exception

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95169 --- Comment #3 from Samuel Thibault --- And for comparison, here is the disassemble of -march=i686 -mtune=generic, which does not raise the exception: Dump of assembler code for function f: 0x11b9 <+0>: push %ebp 0x11ba <+1>:

[Bug c/95169] i386 comparison between nan and 0.0 triggers Invalid operation exception

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95169 --- Comment #2 from Samuel Thibault --- Here are the results with -march=i386 -mtune=$i. "0 1" thus means an exception is raised i386 0 0 i486 0 0 i586 0 0 pentium 0 0 lakemont 0 0 pentium-mmx 0 0 winchip-c6 0 0 winchip2 0 0 c

[Bug c/95169] i386 comparison between nan and 0.0 triggers Invalid operation exception

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95169 Samuel Thibault changed: What|Removed |Added Known to work||9.3.0 Known to fail|

[Bug c/95169] New: i386 comparison between nan and 0.0 triggers Invalid operation exception

: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: samuel.thiba...@ens-lyon.org Target Milestone: --- Created attachment 48549 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48549&action=edit testcase Hello, On b

[Bug go/92861] Passes relative time to sem_timedwait on GNU/Hurd

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92861 Samuel Thibault changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED

[Bug go/92861] Passes relative time to sem_timedwait on GNU/Hurd

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92861 --- Comment #3 from Samuel Thibault --- Created attachment 47446 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47446&action=edit fix duplicate definition Ah, sorry, _CLOCK_REALTIME is actually already getting defined in the generated libg

[Bug go/92861] New: Passes relative time to sem_timedwait on GNU/Hurd

Component: go Assignee: ian at airs dot com Reporter: samuel.thiba...@ens-lyon.org CC: cmang at google dot com Target Milestone: --- Created attachment 47442 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47442&action=edit proposed fix In src/libgo/go/

[Bug middle-end/84078] New: false positive for -Wmaybe-uninitialized

-end Assignee: unassigned at gcc dot gnu.org Reporter: samuel.thiba...@ens-lyon.org Target Milestone: --- Created attachment 43265 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43265&action=edit testcase Hello, The attached testcase compiled with -O2 -Wall p

[Bug c/82967] New: "did you mean" suggestions are way too suggestive

iority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: samuel.thiba...@ens-lyon.org Target Milestone: --- Hello, The new suggestions brought by recent gcc are nice to catch up mere typoes. They are however quite often misleading, I could for instance see

[Bug tree-optimization/35503] Warning about restricted pointers?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35503 --- Comment #10 from Samuel Thibault --- Well, the fact that there are a lot of false negative is not an argument for not including it in -Wall :) The current implementation does catch the issues I have seen in existing code, so it is already us

[Bug c/35503] Warning about restricted pointers?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35503 --- Comment #6 from Samuel Thibault --- Well, yes and no: -Wrestrict does indeed warn about this in gcc 7 now, but -Wall -Wextra does not contain -Wrestrict, so that makes it almost useless. Is there a reason for not including -Wrestrict in at l

[Bug c/52390] New: only linux uses nptl

Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: samuel.thiba...@ens-lyon.org Created attachment 26756 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26756 mask __SIGRTMIN{,+1} on glibc linux only Hello, src/libgcc/generic-morestack.c currently (as of 4.6.2 in deb