[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>: mov%esp,%ebp 0x11bc <+3>: push %ebx 0x11bd <+4>: sub$0x14,%esp 0x11c0 <+7>: call 0x1292 <__x86.get_pc_thunk.ax> 0x11c5 <+12>:add$0x2e3b,%eax 0x11ca <+17>:mov0x8(%ebp),%edx 0x11cd <+20>:mov%edx,-0x10(%ebp) 0x11d0 <+23>:mov0xc(%ebp),%edx 0x11d3 <+26>:mov%edx,-0xc(%ebp) 0x11d6 <+29>:fldl -0x10(%ebp) 0x11d9 <+32>:fldz 0x11db <+34>:fucomip %st(1),%st 0x11dd <+36>:fstp %st(0) 0x11df <+38>:setnp %dl 0x11e2 <+41>:mov$0x0,%ecx 0x11e7 <+46>:fldl -0x10(%ebp) 0x11ea <+49>:fldz 0x11ec <+51>:fucomip %st(1),%st 0x11ee <+53>:fstp %st(0) 0x11f0 <+55>:cmovne %ecx,%edx 0x11f3 <+58>:movzbl %dl,%edx 0x11f6 <+61>:test %edx,%edx 0x11f8 <+63>:je 0x120e 0x11fa <+65>:sub$0xc,%esp 0x11fd <+68>:lea-0x1ff8(%eax),%edx 0x1203 <+74>:push %edx 0x1204 <+75>:mov%eax,%ebx 0x1206 <+77>:call 0x1040 0x120b <+82>:add$0x10,%esp 0x120e <+85>:nop 0x120f <+86>:mov-0x4(%ebp),%ebx 0x1212 <+89>:leave 0x1213 <+90>:ret
[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 c3 0 0 samuel-2 0 0 c3-2 0 0 nehemiah 0 0 c7 0 0 esther 0 0 i686 0 0 pentiumpro 0 0 pentium2 0 0 pentium3 0 0 pentium3m 0 0 pentium-m 0 0 pentium4 0 0 pentium4m 0 0 prescott 0 0 nocona 0 0 core2 0 1 nehalem 0 1 corei7 0 1 westmere 0 1 sandybridge 0 1 corei7-avx 0 1 ivybridge 0 1 core-avx-i 0 1 haswell 0 1 core-avx2 0 1 broadwell 0 1 skylake 0 1 skylake-avx512 0 1 cannonlake 0 1 icelake-client 0 1 icelake-server 0 1 cascadelake 0 1 tigerlake 0 1 cooperlake 0 1 bonnell 0 1 atom 0 1 silvermont 0 1 slm 0 1 goldmont 0 1 goldmont-plus 0 1 tremont 0 1 knl 0 1 knm 0 1 intel 0 1 geode 0 0 k6 0 0 k6-2 0 0 k6-3 0 0 athlon 0 0 athlon-tbird 0 0 athlon-4 0 0 athlon-xp 0 0 athlon-mp 0 0 x86-64 cc1: warning: ‘-mtune=x86-64’ is deprecated; use ‘-mtune=k8’ or ‘-mtune=generic’ instead as appropriate [-Wdeprecated] 0 1 eden-x2 0 1 nano 0 1 nano-1000 0 1 nano-2000 0 1 nano-3000 0 1 nano-x2 0 1 eden-x4 0 1 nano-x4 0 1 k8 0 1 k8-sse3 0 1 opteron 0 1 opteron-sse3 0 1 athlon64 0 1 athlon64-sse3 0 1 athlon-fx 0 1 amdfam10 0 0 barcelona 0 0 bdver1 0 0 bdver2 0 0 bdver3 0 0 bdver4 0 0 znver1 0 0 znver2 0 0 btver1 0 0 btver2 0 0 generic 0 1 native 0 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 Samuel Thibault changed: What|Removed |Added Known to work||9.3.0 Known to fail||10.1.0 Target||i386-linux-gnu Build||i386-linux-gnu Host||i386-linux-gnu --- Comment #1 from Samuel Thibault --- Here is the disassemble of -march=i386 -mtune=generic, which raises the exception: Dump of assembler code for function f: 0x11b9 <+0>: push %ebp 0x11ba <+1>: mov%esp,%ebp 0x11bc <+3>: push %ebx 0x11bd <+4>: sub$0x14,%esp 0x11c0 <+7>: call 0x11b5 <__x86.get_pc_thunk.dx> 0x11c5 <+12>:add$0x2e3b,%edx 0x11cb <+18>:mov0x8(%ebp),%eax 0x11ce <+21>:mov%eax,-0x10(%ebp) 0x11d1 <+24>:mov0xc(%ebp),%eax 0x11d4 <+27>:mov%eax,-0xc(%ebp) 0x11d7 <+30>:fldl -0x10(%ebp) 0x11da <+33>:fldz 0x11dc <+35>:fucompp 0x11de <+37>:fnstsw %ax 0x11e0 <+39>:sahf 0x11e1 <+40>:setnp %cl 0x11e4 <+43>:fldz 0x11e6 <+45>:fcompl -0x10(%ebp) 0x11e9 <+48>:fnstsw %ax 0x11eb <+50>:sahf 0x11ec <+51>:setne %al 0x11ef <+54>:sub$0x1,%eax 0x11f2 <+57>:and%ecx,%eax 0x11f4 <+59>:movzbl %al,%eax 0x11f7 <+62>:test %eax,%eax 0x11f9 <+64>:je 0x120f 0x11fb <+66>:sub$0xc,%esp 0x11fe <+69>:lea-0x1ff8(%edx),%eax 0x1204 <+75>:push %eax 0x1205 <+76>:mov%edx,%ebx 0x1207 <+78>:call 0x1040 0x120c <+83>:add$0x10,%esp 0x120f <+86>:nop 0x1210 <+87>:mov-0x4(%ebp),%ebx 0x1213 <+90>:leave 0x1214 <+91>:ret
[Bug c/95169] New: i386 comparison between nan and 0.0 triggers Invalid operation exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95169 Bug ID: 95169 Summary: i386 comparison between nan and 0.0 triggers Invalid operation exception Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: 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=edit testcase Hello, On building the attached testcase with gcc-10 -m32 test.c -o test -march=i386 -mtune=generic -lm its execution prints "0 1", i.e. an Invalid operation exception is raised by the mere comparison of y (that contains NaN) against 0.0. This was tested with Debian's gcc-10 10.1.0-1. This does not happen with previous versions of gcc. This happens with half of the values of -mtune (I'll attach the details) ; this also happens with -march=i486, i586, pentium ; this does not happen with -march=i686 or pentiumpro etc. (whatever the value of -mtune). Samuel
[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 |--- --- Comment #4 from Samuel Thibault --- Reopening the bug for the fix to be commited
[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=edit fix duplicate definition Ah, sorry, _CLOCK_REALTIME is actually already getting defined in the generated libgo/runtime_sysinfo.go file, the attached patch is needed on top of what was already committed.
[Bug go/92861] New: Passes relative time to sem_timedwait on GNU/Hurd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92861 Bug ID: 92861 Summary: Passes relative time to sem_timedwait on GNU/Hurd Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 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=edit proposed fix In src/libgo/go/runtime/os_hurd.go, a relative time is set in var ts, and is passed to sem_timedwait. But sem_timedwait expects an absolute time, not a relative time. The attached patch fixes this by using the time from clock_gettime(CLOCK_REALTIME), like is done in os_aix.go.
[Bug middle-end/84078] New: false positive for -Wmaybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84078
Bug ID: 84078
Summary: false positive for -Wmaybe-uninitialized
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-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=edit
testcase
Hello,
The attached testcase compiled with -O2 -Wall produces
test.c:30:2: warning: 'c' may be used uninitialized in this function
[-Wmaybe-uninitialized]
printf("%d %d %d\n", a, b, c);
^
test.c:30:2: warning: 'b' may be used uninitialized in this function
[-Wmaybe-uninitialized]
test.c:30:2: warning: 'a' may be used uninitialized in this function
[-Wmaybe-uninitialized]
while they are only used when `err' is equal to zero, and in the only case
where that happens, they do get initialized.
This is the minimal testcase I could reduce to, it seems both the asm snippet
and testing its result does make a difference, as well as the two ifs and the
three variables.
I could verify this with gcc snapshot 20180124 (Debian buster x86_64)
Samuel
[Bug c/82967] New: "did you mean" suggestions are way too suggestive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82967 Bug ID: 82967 Summary: "did you mean" suggestions are way too suggestive Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: 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 'PATH_MAX' undeclared (first use in this function); did you mean 'INT8_MAX'? implicit declaration of function ‘time’; did you mean ‘nice’? implicit declaration of function ‘bar’; did you mean ‘carg’? programming beginners will start writing all kinds of crazy code due to this: "the compiler told me to do it"... Changing half of the letters of a word, or 3 or more letters, looks too suggestive to me, I'd say it should be reduced to at most 2 letters, and less than a quarter or a third of the word. Samuel
[Bug tree-optimization/35503] Warning about restricted pointers?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35503 --- Comment #10 from Samuel Thibault <samuel.thiba...@ens-lyon.org> --- 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 useful to raise it.
[Bug c/35503] Warning about restricted pointers?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35503 --- Comment #6 from Samuel Thibault <samuel.thiba...@ens-lyon.org> --- 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 least -Wextra (I'd even argue for -Wall because it's really sure that there is a bug in code doing this)
[Bug c/52390] New: only linux uses nptl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52390
Bug #: 52390
Summary: only linux uses nptl
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
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
debian, which was updated to r184373 for the 4.6 branch) in
__generic_morestack_set_initial_sp() masks out __SIGRTMIN and
__SIGRTMIN+1 on all glibc platforms (ifdef __GLIBC__). It used to do
that on all linux platforms (ifdef __linux__). I guess the change was
made to avoid issues with uclibc and such on linux, but on the other it
brings issues with glibc on other ports that linux: NPTL is only ported
to Linux, and I doubt there'll be other ports actually, since it is so
much tied to the Linux kernel.
It should thus turned into if defined(__GLIBC__) defined(__linux__),
as attached patch does.
Samuel
