public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug tree-optimization/43716] [4.6/4.7/4.8 Regression] Revision 158105 miscompiles doduc.f90
[not found] <bug-43716-4@http.gcc.gnu.org/bugzilla/>
@ 2012-07-21 10:42 ` ubizjak at gmail dot com
2012-07-21 10:45 ` ubizjak at gmail dot com
` (18 subsequent siblings)
19 siblings, 0 replies; 20+ messages in thread
From: ubizjak at gmail dot com @ 2012-07-21 10:42 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
Uros Bizjak <ubizjak at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|FIXED |
Summary|[4.6 Regression] Revision |[4.6/4.7/4.8 Regression]
|158105 miscompiles |Revision 158105 miscompiles
|doduc.f90 |doduc.f90
--- Comment #30 from Uros Bizjak <ubizjak at gmail dot com> 2012-07-21 10:42:22 UTC ---
This still happens with:
gcc version 4.8.0 20120720 (experimental) [trunk revision 189718] (GCC)
on x86_64-unknown-linux-gnu.
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug tree-optimization/43716] [4.6/4.7/4.8 Regression] Revision 158105 miscompiles doduc.f90
[not found] <bug-43716-4@http.gcc.gnu.org/bugzilla/>
2012-07-21 10:42 ` [Bug tree-optimization/43716] [4.6/4.7/4.8 Regression] Revision 158105 miscompiles doduc.f90 ubizjak at gmail dot com
@ 2012-07-21 10:45 ` ubizjak at gmail dot com
2012-07-21 10:49 ` ubizjak at gmail dot com
` (17 subsequent siblings)
19 siblings, 0 replies; 20+ messages in thread
From: ubizjak at gmail dot com @ 2012-07-21 10:45 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
Uros Bizjak <ubizjak at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ubizjak at gmail dot com
--- Comment #31 from Uros Bizjak <ubizjak at gmail dot com> 2012-07-21 10:44:26 UTC ---
*** Bug 54034 has been marked as a duplicate of this bug. ***
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug tree-optimization/43716] [4.6/4.7/4.8 Regression] Revision 158105 miscompiles doduc.f90
[not found] <bug-43716-4@http.gcc.gnu.org/bugzilla/>
2012-07-21 10:42 ` [Bug tree-optimization/43716] [4.6/4.7/4.8 Regression] Revision 158105 miscompiles doduc.f90 ubizjak at gmail dot com
2012-07-21 10:45 ` ubizjak at gmail dot com
@ 2012-07-21 10:49 ` ubizjak at gmail dot com
2012-07-21 11:31 ` ubizjak at gmail dot com
` (16 subsequent siblings)
19 siblings, 0 replies; 20+ messages in thread
From: ubizjak at gmail dot com @ 2012-07-21 10:49 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
--- Comment #32 from Uros Bizjak <ubizjak at gmail dot com> 2012-07-21 10:49:31 UTC ---
gcc version 4.8.0 20120720 (experimental) [trunk revision 189718] (GCC)
==2822== Memcheck, a memory error detector
==2822== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==2822== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==2822== Command: ./a.out
==2822==
MAIN : FIN S00002
MAIN : FIN S00001
MAIN : FIN S00011
MAIN : FIN S00022
TEMPS = 33.00000000 , NITERA : 1
TEMPS = 34.00031044 , NITERA : 186
TEMPS = 35.00497388 , NITERA : 955
TEMPS = 36.00007615 , NITERA : 1512
TEMPS = 37.00012624 , NITERA : 1765
TEMPS = 38.00060760 , NITERA : 2044
TEMPS = 39.00312223 , NITERA : 2327
TEMPS = 40.00168143 , NITERA : 2607
TEMPS = 45.00187475 , NITERA : 4017
TEMPS = 50.00261983 , NITERA : 5492
TEMPS = 55.00263522 , NITERA : 6981
TEMPS = 60.00087007 , NITERA : 8679
==2822== Invalid read of size 8
==2822== at 0x4040E8: s00061_ (doduc.f90:568)
==2822== by 0x412AD3: s00013_ (doduc.f90:1150)
==2822== by 0x41B9D4: MAIN__ (doduc.f90:182)
==2822== by 0x400B4C: main (doduc.f90:199)
==2822== Address 0x3fefff770 is not stack'd, malloc'd or (recently) free'd
==2822==
I can reproduce it here with Rev. 189737; it also crashes without running
valgrind.
It crashes (on x86-64 openSUSE Factory) with
-O3 -ffast-math [-g]
It does not crash with either of the following added:
-fno-fast-math
-fno-inline-functions
-fno-predictive-commoning
-fno-tree-vectorize
-fno-protect-parens (implied by -Ofast)
Nor does it crash with:
-O2 -ftree-vectorize -finline-functions -ffpredictive-commoning -ffast-math
-m32 -O3 -ffast-math
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug tree-optimization/43716] [4.6/4.7/4.8 Regression] Revision 158105 miscompiles doduc.f90
[not found] <bug-43716-4@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2012-07-21 10:49 ` ubizjak at gmail dot com
@ 2012-07-21 11:31 ` ubizjak at gmail dot com
2012-07-21 12:17 ` ubizjak at gmail dot com
` (15 subsequent siblings)
19 siblings, 0 replies; 20+ messages in thread
From: ubizjak at gmail dot com @ 2012-07-21 11:31 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
--- Comment #33 from Uros Bizjak <ubizjak at gmail dot com> 2012-07-21 11:31:18 UTC ---
The NaN is generated as a mask for DFmode ABS_EXPR:
(insn 124 123 125 (set (reg:V2DF 508)
(mem/u/c:V2DF (symbol_ref/u:DI ("*.LC13") [flags 0x2]) [5 S16 A128]))
doduc.f90:5376 -1
(expr_list:REG_EQUAL (const_vector:V2DF [
(const_double:DF +QNaN [+QNaN])
(const_double:DF 0.0 [0x0.0p+0])
])
(nil)))
or V2DFmode ABS_EXPR:
(insn 1648 1647 1649 (set (reg:V2DF 4657)
(mem/u/c:V2DF (symbol_ref/u:DI ("*.LC138") [flags 0x2]) [5 S16 A128]))
doduc.f90:1851 -1
(expr_list:REG_EQUAL (const_vector:V2DF [
(const_double:DF +QNaN [+QNaN])
(const_double:DF +QNaN [+QNaN])
])
(nil)))
Probably, some mixup happens somewhere in RTL optimization passes.
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug tree-optimization/43716] [4.6/4.7/4.8 Regression] Revision 158105 miscompiles doduc.f90
[not found] <bug-43716-4@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2012-07-21 11:31 ` ubizjak at gmail dot com
@ 2012-07-21 12:17 ` ubizjak at gmail dot com
2012-07-21 12:35 ` ubizjak at gmail dot com
` (14 subsequent siblings)
19 siblings, 0 replies; 20+ messages in thread
From: ubizjak at gmail dot com @ 2012-07-21 12:17 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
--- Comment #34 from Uros Bizjak <ubizjak at gmail dot com> 2012-07-21 12:16:42 UTC ---
Maybe no problem with gcc at all:
Compile doduc.f90 with -g -O3 -ffast-math -ffpe-trap=invalid
Starting program: /home/uros/pb11/lin/source/a.out
MAIN : FIN S00002
MAIN : FIN S00001
MAIN : FIN S00011
MAIN : FIN S00022
Program received signal SIGFPE, Arithmetic exception.
0x0000000000402a71 in s00018 (i12=0, i21=0, iorg=0) at doduc.f90:3789
3789 & dtpa = 2.*sens*DABS(TMI(k)/DTMi(k))
(gdb) disass
0x0000000000402a4f <+431>: movsd 0x229e61(%rip),%xmm3 # 0x62c8b8
<aaa11_+856>
0x0000000000402a57 <+439>: movsd %xmm3,0x100(%rsp)
0x0000000000402a60 <+448>: movsd 0x21c790(%rip),%xmm3 # 0x61f1f8
<aaa77_+19416>
0x0000000000402a68 <+456>: movsd 0x100(%rsp),%xmm6
=> 0x0000000000402a71 <+465>: divsd %xmm3,%xmm0
0x0000000000402a75 <+469>: addsd %xmm6,%xmm6
0x0000000000402a79 <+473>: andpd %xmm1,%xmm3
0x0000000000402a7d <+477>: andpd %xmm1,%xmm0
(gdb) i r xmm3 xmm0
xmm3 0
xmm0 0
To me, it looks like invalid test. Any fortraners here to share their opinion?
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug tree-optimization/43716] [4.6/4.7/4.8 Regression] Revision 158105 miscompiles doduc.f90
[not found] <bug-43716-4@http.gcc.gnu.org/bugzilla/>
` (4 preceding siblings ...)
2012-07-21 12:17 ` ubizjak at gmail dot com
@ 2012-07-21 12:35 ` ubizjak at gmail dot com
2012-07-21 13:40 ` dominiq at lps dot ens.fr
` (13 subsequent siblings)
19 siblings, 0 replies; 20+ messages in thread
From: ubizjak at gmail dot com @ 2012-07-21 12:35 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
--- Comment #35 from Uros Bizjak <ubizjak at gmail dot com> 2012-07-21 12:35:17 UTC ---
Actually, exception happens at:
Starting program: /home/uros/pb11/lin/source/a.out
MAIN : FIN S00002
MAIN : FIN S00001
MAIN : FIN S00011
MAIN : FIN S00022
Program received signal SIGFPE, Arithmetic exception.
s00017 () at doduc.f90:1852
1852 IF ( yy.GE.y ) qsec = qsec*y/yy
(gdb) bt
#0 s00017 () at doduc.f90:1852
#1 0x000000000041ba3a in doduc () at doduc.f90:186
#2 0x0000000000400ba7 in main (argc=argc@entry=1, argv=0x7fffffffe163) at
doduc.f90:199
#3 0x0000003c02e21735 in __libc_start_main (main=0x400b80 <main>, argc=1,
ubp_av=0x7fffffffdde8, init=<optimized out>,
fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffddd8)
at libc-start.c:226
#4 0x0000000000400bd1 in _start ()
(gdb) disass $pc-20,+30
Dump of assembler code from 0x40a1f4 to 0x40a212:
0x000000000040a1f4 <s00017_+6212>: push %rsp
0x000000000040a1f5 <s00017_+6213>: fisub 0x41(%rsi)
0x000000000040a1f8 <s00017_+6216>: mulps %xmm1,%xmm0
0x000000000040a1fb <s00017_+6219>: maxpd %xmm7,%xmm0
0x000000000040a1ff <s00017_+6223>: mulpd %xmm0,%xmm1
0x000000000040a203 <s00017_+6227>: cmplepd %xmm3,%xmm0
=> 0x000000000040a208 <s00017_+6232>: divpd %xmm3,%xmm1
0x000000000040a20c <s00017_+6236>: andpd %xmm0,%xmm1
0x000000000040a210 <s00017_+6240>: andnpd %xmm2,%xmm0
End of assembler dump.
(gdb) i r xmm3 xmm1
xmm3 ( (0x0, 0x0, 0x0, 0x2), (0x0, 0x6), (0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0, 0x0, 0xc4, 0x6b, 0x1b, 0xef, 0xc0, 0x60, 0x1b, 0x40), (0x0, 0x0, 0x0,
0x0, 0x6bc4, 0xef1b, 0x60c0, 0x401b), (0x0, 0x0, 0xef1b6bc4, 0x401b60c0), (0x0,
0x401b60c0ef1b6bc4), 0x401b60c0ef1b6bc40000000000000000 )
xmm1 ( (0x0, 0x0, 0x0, 0xfffffffe), (0x0, 0xfffffffffffffffe), (0x0,
0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0xea, 0x1e, 0x50, 0xb1, 0x21, 0xbd, 0x2,
0xc0), (0x0, 0x0, 0x0, 0x0, 0x1eea, 0xb150, 0xbd21, 0xc002), (0x0, 0x0,
0xb1501eea, 0xc002bd21), (0x0, 0xc002bd21b1501eea),
0xc002bd21b1501eea0000000000000000 )
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug tree-optimization/43716] [4.6/4.7/4.8 Regression] Revision 158105 miscompiles doduc.f90
[not found] <bug-43716-4@http.gcc.gnu.org/bugzilla/>
` (5 preceding siblings ...)
2012-07-21 12:35 ` ubizjak at gmail dot com
@ 2012-07-21 13:40 ` dominiq at lps dot ens.fr
2012-07-21 13:52 ` ubizjak at gmail dot com
` (12 subsequent siblings)
19 siblings, 0 replies; 20+ messages in thread
From: dominiq at lps dot ens.fr @ 2012-07-21 13:40 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
--- Comment #36 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2012-07-21 13:40:09 UTC ---
> To me, it looks like invalid test. Any fortraners here to share their opinion?
Please read comments #23 and #24. One problem with NaN is that they propagate
until something trap them. When did you get a successful compilation?
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug tree-optimization/43716] [4.6/4.7/4.8 Regression] Revision 158105 miscompiles doduc.f90
[not found] <bug-43716-4@http.gcc.gnu.org/bugzilla/>
` (6 preceding siblings ...)
2012-07-21 13:40 ` dominiq at lps dot ens.fr
@ 2012-07-21 13:52 ` ubizjak at gmail dot com
2012-07-21 14:43 ` dominiq at lps dot ens.fr
` (11 subsequent siblings)
19 siblings, 0 replies; 20+ messages in thread
From: ubizjak at gmail dot com @ 2012-07-21 13:52 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
--- Comment #37 from Uros Bizjak <ubizjak at gmail dot com> 2012-07-21 13:51:59 UTC ---
(In reply to comment #36)
> > To me, it looks like invalid test. Any fortraners here to share their opinion?
>
> Please read comments #23 and #24. One problem with NaN is that they propagate
> until something trap them. When did you get a successful compilation?
No, the first NaN was born exactly at this instruction. Please note 0 / 0
which is the definition of NaN.
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug tree-optimization/43716] [4.6/4.7/4.8 Regression] Revision 158105 miscompiles doduc.f90
[not found] <bug-43716-4@http.gcc.gnu.org/bugzilla/>
` (7 preceding siblings ...)
2012-07-21 13:52 ` ubizjak at gmail dot com
@ 2012-07-21 14:43 ` dominiq at lps dot ens.fr
2012-07-22 10:48 ` dominiq at lps dot ens.fr
` (10 subsequent siblings)
19 siblings, 0 replies; 20+ messages in thread
From: dominiq at lps dot ens.fr @ 2012-07-21 14:43 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
--- Comment #38 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2012-07-21 14:43:10 UTC ---
> No, the first NaN was born exactly at this instruction. Please note 0 / 0
> which is the definition of NaN.
AFAIU the loop around line 1852, the only possibility for 0/0 is yy==qsec==0,
but since 0.1<=y, the line 1852 should not be accessed.
If I compile doduc.f90 with '-O3 -ffast-math -ffpe-trap=invalid' I get the
"Floating-point exception" with trunk and 4.4. If I compile with
-fno-tree-loop-if-convert the exception occurs somewhere else:
#3 0x10000306e
#4 0x10001d17c
#5 0x10001eca8
versus
#3 0x10000a863
#4 0x10001d11e
#5 0x10001ec98
!-(poor backtrace on darwin).
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug tree-optimization/43716] [4.6/4.7/4.8 Regression] Revision 158105 miscompiles doduc.f90
[not found] <bug-43716-4@http.gcc.gnu.org/bugzilla/>
` (8 preceding siblings ...)
2012-07-21 14:43 ` dominiq at lps dot ens.fr
@ 2012-07-22 10:48 ` dominiq at lps dot ens.fr
2012-07-23 8:13 ` rguenth at gcc dot gnu.org
` (9 subsequent siblings)
19 siblings, 0 replies; 20+ messages in thread
From: dominiq at lps dot ens.fr @ 2012-07-22 10:48 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
--- Comment #39 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2012-07-22 10:47:42 UTC ---
> If I compile with -fno-tree-loop-if-convert the exception occurs
> somewhere else:
It occurs in s00018 in the loop between lines 3782 to 3796
DO j = 1 , n1
dtpar = V0012
IF ( i.EQ.NIV .AND. j.EQ.ISLni ) THEN
k1 = 2
DO k = 1 , k1
dtpa = V0012
IF ( DABS(DTMi(k)).GT.eps ) &
& dtpa = 2.*sens*DABS(TMI(k)/DTMi(k))
dtpar = DMIN1(dtpar,dtpa)
ENDDO
ELSEIF ( DABS(DTGai(i,j)).GT.eps ) THEN
dtpar = sens*DABS(TGAi(i,j)/DTGai(i,j))
ENDIF
DTTemp = DMIN1(DTTemp,dtpar)
ENDDO
Before the loop i=2, n1=2, NIV=0, ISLni=0, eps=1.0e-8, sens=0.01,
DTTemp=0.05, DTGai(2,1)=3.4750524086054519, DTGai(2,2)=2.8245839253949421,
TGAi(2,1)=905.00000000000000, and TGAi(2,1)=1040.0000000000000. So
(i.EQ.NIV .AND. j.EQ.ISLni) is false, DTGai(2,:)>eps and dtpar>20.0>DTTemp,
hence the loop does nothing and should not generate any "Floating-point
exception" as it does.
If I read correctly the assembly bellow, the loop
k1 = 2
DO k = 1 , k1
dtpa = V0012
IF ( DABS(DTMi(k)).GT.eps ) &
& dtpa = 2.*sens*DABS(TMI(k)/DTMi(k))
dtpar = DMIN1(dtpar,dtpa)
ENDDO
is unrolled and moved outside the 'DO j = 1 , n1' loop when s00018.f90 is
compiled with -O2 -ffpe-trap=invalid -fno-trapping-math. The worst part of
the optimization and the cause of the floating-point exception seems that
the test 'IF ( DABS(DTMi(k)).GT.eps )' is removed (or delayed, even if I
replace eps
with 1.0) while both TMI and DTMI are filled with zeroes.
Note that if I replace
IF ( DABS(DTMi(k)).GT.eps ) &
& dtpa = 2.*sens*DABS(TMI(k)/DTMi(k))
with
dtpa = 2.*sens*DABS(TMI(k))/max(DABS(DTMi(k)),eps)
there is no exception.
IMO computing TMI(k)/DTMi(k) without the IF is over-agressive: if
DABS(DTMi(k)).LT.eps, dtpa will have to be recomputed. In addition, if the
k loop is moved outside the j loop, it should at least protected by
IF ( i.EQ.NIV), or better by
IF ( i.EQ.NIV .AND. ISLni.GE.1 .AND. ISLni.LE.n1).
Also since the ELSEIF depends on j and the IF is taken at most once,
moving the k loop outside the j loop seems dubious.
Note that the exception is (should be) harmless as it occurs in a dead
branch.
L29:
movl 36404(%r9,%rdi,4), %ecx # aaa77.nasl, n1
movsd %xmm9, 936(%r11) # x, aaa11.dtphy
movsd 856(%r11), %xmm8 # aaa11.v22202, sens
movl $1, 396(%rsp) #, j
testl %ecx, %ecx # n1
jle L41 #,
movsd 19416(%r9), %xmm7 # aaa77.dtmi, D.2813
movapd %xmm8, %xmm11 # sens, D.2817
movl $0, %edx #, tmp908
movsd 19400(%r9), %xmm0 # aaa77.tmi, x
addsd %xmm8, %xmm11 # sens, D.2817
movapd %xmm7, %xmm10 # D.2813, D.2814
movq _aaa13_@GOTPCREL(%rip), %rax #,
divsd %xmm7, %xmm0 # D.2813, x
andpd %xmm1, %xmm10 # tmp1323, D.2814
movsd 19424(%r9), %xmm12 # aaa77.dtmi, D.2813
movsd 19408(%r9), %xmm7 # aaa77.tmi, x
movsd 944(%r11), %xmm6 # aaa11.dttemp, x
movl 240(%rax), %esi # aaa13.niv, pretmp.160
movl 244(%rax), %r14d # aaa13.islni, D.2806
xorl %eax, %eax # pretmp.165
divsd %xmm12, %xmm7 # D.2813, x
andpd %xmm1, %xmm0 # tmp1323, x
mulsd %xmm11, %xmm0 # D.2817, x
ucomisd %xmm0, %xmm2 # x, x
seta %al #, pretmp.165
ucomisd %xmm3, %xmm10 # tmp1324, D.2814
cmovbe %edx, %eax # pretmp.165,, tmp908, pretmp.165
xorl %edx, %edx #
ucomisd %xmm2, %xmm2 # x, x
setp %dl #,
addl $1, %ecx #,
movl %ecx, 12(%rsp) #, %sfp
xorl %ecx, %ecx #
movl %edx, 336(%rsp) #, %sfp
leaq 30032(%r9,%rdi,8), %rdx #, ivtmp.264
andpd %xmm1, %xmm7 # tmp1323, x
mulsd %xmm11, %xmm7 # D.2817, x
movapd %xmm3, %xmm11 # tmp1324,
cmpltsd %xmm10, %xmm11 #, D.2814,
movapd %xmm11, %xmm10 #, tmp923
andpd %xmm11, %xmm0 # tmp923, tmp924
movapd %xmm2, %xmm11 # x, x
andnpd %xmm2, %xmm10 # x, tmp921
orpd %xmm0, %xmm10 # tmp924, tmp921
ucomisd %xmm10, %xmm10 # tmp921, tmp921
setp %cl #,
orl 336(%rsp), %eax # %sfp, pretmp.165
movl %ecx, 364(%rsp) #, %sfp
movl %eax, 336(%rsp) # pretmp.165, %sfp
je L34 #,
movapd %xmm10, %xmm11 # tmp921, x
L34:
movapd %xmm3, %xmm0 # tmp1324,
andpd %xmm1, %xmm12 # tmp1323, D.2814
xorl %eax, %eax #
cmpltsd %xmm12, %xmm0 #, D.2814,
movapd %xmm1, %xmm10 # tmp1323, tmp1385
movl 12(%rsp), %ecx # %sfp, D.3602
movapd %xmm0, %xmm12 #, tmp933
andpd %xmm0, %xmm7 # tmp933, tmp934
andnpd %xmm2, %xmm12 # x, x
orpd %xmm7, %xmm12 # tmp934, x
ucomisd %xmm12, %xmm11 # x, x
seta %al #,
movl %eax, 360(%rsp) #, %sfp
movl $1, %eax #, prephitmp.161
jmp L42 #
.align 4,0x90
L255:
movsd -10560(%rdx), %xmm0 # MEM[base: D.3603_170, offset: -10560B], x
divsd %xmm7, %xmm0 # D.2831, x
andpd %xmm10, %xmm0 # tmp1385, x
mulsd %xmm8, %xmm0 # sens, x
L37:
ucomisd %xmm0, %xmm6 # x, x
ja L160 #,
ucomisd %xmm6, %xmm6 # x, x
jnp L39 #,
L160:
movapd %xmm0, %xmm6 # x, x
L39:
addl $1, %eax #, prephitmp.161
addq $176, %rdx #, ivtmp.264
cmpl %ecx, %eax # D.3602, prephitmp.161
je L253 #,
L42:
cmpl %esi, %r10d # pretmp.160, prephitmp.132
je L254 #,
L35:
movsd (%rdx), %xmm7 # MEM[base: D.3603_170, offset: 0B], D.2831
movapd %xmm7, %xmm0 # D.2831, D.2832
andpd %xmm1, %xmm0 # tmp1323, D.2832
ucomisd %xmm3, %xmm0 # tmp1324, D.2832
ja L255 #,
movapd %xmm2, %xmm0 # x, x
jmp L37 #
.align 4,0x90
L254:
cmpl %eax, %r14d # prephitmp.161, D.2806
jne L35 #,
cmpl $0, 336(%rsp) #, %sfp
je L238 #,
cmpl $0, 364(%rsp) #, %sfp
jne L158 #,
L238:
cmpl $0, 360(%rsp) #, %sfp
movapd %xmm11, %xmm0 # x, x
je L37 #,
L158:
movapd %xmm12, %xmm0 # x, x
jmp L37 #
.align 4,0x90
L253:
movl %eax, 396(%rsp) # prephitmp.161, j
movsd %xmm6, 944(%r11) # x, aaa11.dttemp
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug tree-optimization/43716] [4.6/4.7/4.8 Regression] Revision 158105 miscompiles doduc.f90
[not found] <bug-43716-4@http.gcc.gnu.org/bugzilla/>
` (9 preceding siblings ...)
2012-07-22 10:48 ` dominiq at lps dot ens.fr
@ 2012-07-23 8:13 ` rguenth at gcc dot gnu.org
2012-12-07 9:21 ` rguenth at gcc dot gnu.org
` (8 subsequent siblings)
19 siblings, 0 replies; 20+ messages in thread
From: rguenth at gcc dot gnu.org @ 2012-07-23 8:13 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
--- Comment #40 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-07-23 08:12:55 UTC ---
tree if-conversion happily executes both arms of the conditional
unconditionally
with -ffast-math, so for example
if (x != 0)
tem = y / x;
else
tem = 0.;
... do sth with tem ...
will execute y / x unconditionally based on the fact that it cannot trap.
So simply generation of NaNs is not what you should check for, but
"usage" of 'tem' with NaN in the above should be (it shouldn't be used
if x is zero).
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug tree-optimization/43716] [4.6/4.7/4.8 Regression] Revision 158105 miscompiles doduc.f90
[not found] <bug-43716-4@http.gcc.gnu.org/bugzilla/>
` (10 preceding siblings ...)
2012-07-23 8:13 ` rguenth at gcc dot gnu.org
@ 2012-12-07 9:21 ` rguenth at gcc dot gnu.org
2012-12-07 13:40 ` dominiq at lps dot ens.fr
` (7 subsequent siblings)
19 siblings, 0 replies; 20+ messages in thread
From: rguenth at gcc dot gnu.org @ 2012-12-07 9:21 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |WAITING
Target Milestone|4.6.0 |4.6.4
--- Comment #41 from Richard Biener <rguenth at gcc dot gnu.org> 2012-12-07 09:21:12 UTC ---
Re-adjust target milestone. Please somebody revisit the regression status
and fill in known-to-work/fail fields. ISTR it only fails on darwin.
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug tree-optimization/43716] [4.6/4.7/4.8 Regression] Revision 158105 miscompiles doduc.f90
[not found] <bug-43716-4@http.gcc.gnu.org/bugzilla/>
` (11 preceding siblings ...)
2012-12-07 9:21 ` rguenth at gcc dot gnu.org
@ 2012-12-07 13:40 ` dominiq at lps dot ens.fr
2012-12-07 14:29 ` rguenth at gcc dot gnu.org
` (6 subsequent siblings)
19 siblings, 0 replies; 20+ messages in thread
From: dominiq at lps dot ens.fr @ 2012-12-07 13:40 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
--- Comment #42 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2012-12-07 13:40:17 UTC ---
> Re-adjust target milestone. Please somebody revisit the regression status
> and fill in known-to-work/fail fields. ISTR it only fails on darwin.
(1) doduc.f90 is correctly compiled on x86_64-apple-darwin10 (r194291) with the
options I have tried (typically -fprotect-parens -Ofast -funroll-loops
-ftree-loop-linear -fomit-frame-pointer -fwhole-program -flto, no valgrind
error with -O3 -ffast-math, no error with -fsanitize=address).
(2) Per comment #30, this PR has been reopened for x86_64-unknown-linux-gnu.
(3) Per comment #40:
> tree if-conversion happily executes both arms of the conditional
> unconditionally with -ffast-math, ...
so compiling with -ffpe-trap=invalid traps for results discarded later.
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug tree-optimization/43716] [4.6/4.7/4.8 Regression] Revision 158105 miscompiles doduc.f90
[not found] <bug-43716-4@http.gcc.gnu.org/bugzilla/>
` (12 preceding siblings ...)
2012-12-07 13:40 ` dominiq at lps dot ens.fr
@ 2012-12-07 14:29 ` rguenth at gcc dot gnu.org
2012-12-18 9:14 ` jakub at gcc dot gnu.org
` (5 subsequent siblings)
19 siblings, 0 replies; 20+ messages in thread
From: rguenth at gcc dot gnu.org @ 2012-12-07 14:29 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
--- Comment #43 from Richard Biener <rguenth at gcc dot gnu.org> 2012-12-07 14:28:56 UTC ---
(In reply to comment #42)
> > Re-adjust target milestone. Please somebody revisit the regression status
> > and fill in known-to-work/fail fields. ISTR it only fails on darwin.
>
> (1) doduc.f90 is correctly compiled on x86_64-apple-darwin10 (r194291) with the
> options I have tried (typically -fprotect-parens -Ofast -funroll-loops
> -ftree-loop-linear -fomit-frame-pointer -fwhole-program -flto, no valgrind
> error with -O3 -ffast-math, no error with -fsanitize=address).
>
> (2) Per comment #30, this PR has been reopened for x86_64-unknown-linux-gnu.
>
> (3) Per comment #40:
>
> > tree if-conversion happily executes both arms of the conditional
> > unconditionally with -ffast-math, ...
>
> so compiling with -ffpe-trap=invalid traps for results discarded later.
-ffpe-trap=invalid -ffast-math is a non-sensical flag combination. You
tell the compiler nothing will ever trap and then enable traps! So seeing
errors with that tells you nothing ...
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug tree-optimization/43716] [4.6/4.7/4.8 Regression] Revision 158105 miscompiles doduc.f90
[not found] <bug-43716-4@http.gcc.gnu.org/bugzilla/>
` (13 preceding siblings ...)
2012-12-07 14:29 ` rguenth at gcc dot gnu.org
@ 2012-12-18 9:14 ` jakub at gcc dot gnu.org
2012-12-18 10:24 ` jakub at gcc dot gnu.org
` (4 subsequent siblings)
19 siblings, 0 replies; 20+ messages in thread
From: jakub at gcc dot gnu.org @ 2012-12-18 9:14 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #44 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-12-18 09:14:13 UTC ---
Can't reproduce on x86_64-linux with current trunk at -O3 -g -ffast-math, both
with LRA and when LRA is disabled. From what I understood, this bug used to be
present on darwin, but went away two years ago, then it got reopened for
x86_64-linux in July and apparently doesn't reproduce anymore either. So, is
this broken anywhere now?
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug tree-optimization/43716] [4.6/4.7/4.8 Regression] Revision 158105 miscompiles doduc.f90
[not found] <bug-43716-4@http.gcc.gnu.org/bugzilla/>
` (14 preceding siblings ...)
2012-12-18 9:14 ` jakub at gcc dot gnu.org
@ 2012-12-18 10:24 ` jakub at gcc dot gnu.org
2013-01-08 18:26 ` dominiq at lps dot ens.fr
` (3 subsequent siblings)
19 siblings, 0 replies; 20+ messages in thread
From: jakub at gcc dot gnu.org @ 2012-12-18 10:24 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
--- Comment #45 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-12-18 10:23:59 UTC ---
I've bisected this and the bug went away (or has gone latent) with
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189915
There is a huge number of changes in *.optimized dumps, mainly D.NNNNN DECL_UID
numbers but also SSA_NAME versions, if I abstract from those, the only real
change is in a comparison:
- x_15 = MIN_EXPR <x_572, x_317>;
+ x_382 = MIN_EXPR <x_572, x_317>;
...
- x_89 = MIN_EXPR <x_17, x_552>;
+ x_95 = MIN_EXPR <x_17, x_372>;
x_320 = aaa11.v0011;
- x_384 = MAX_EXPR <x_89, x_320>;
- aaa13.dt = x_384;
- if (prephitmp.1593_1033 > 2)
+ x_15 = MAX_EXPR <x_95, x_320>;
+ aaa13.dt = x_15;
+ if (prephitmp.1593_1034 > 2)
...
<bb 100>:
- if (x_342 < x_384)
+ if (x_15 > x_342)
(x_342 is the same thing in both cases, the < vs. > is probably the result of
canonicalizing the comparison based on SSA_NAME versions).
Anyway, is it really worth it to have this open as P1 on questionable testcase
(well, questionable is mainly whether the testcase doesn't assume IEEE 754
semantics to make -ffast-math invalid for it) where the problem is just latent
(and unclear whether it is a compiler issue at all)?
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug tree-optimization/43716] [4.6/4.7/4.8 Regression] Revision 158105 miscompiles doduc.f90
[not found] <bug-43716-4@http.gcc.gnu.org/bugzilla/>
` (15 preceding siblings ...)
2012-12-18 10:24 ` jakub at gcc dot gnu.org
@ 2013-01-08 18:26 ` dominiq at lps dot ens.fr
2013-01-08 19:24 ` ubizjak at gmail dot com
` (2 subsequent siblings)
19 siblings, 0 replies; 20+ messages in thread
From: dominiq at lps dot ens.fr @ 2013-01-08 18:26 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
Dominique d'Humieres <dominiq at lps dot ens.fr> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|WAITING |RESOLVED
Resolution| |WORKSFORME
--- Comment #46 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2013-01-08 18:25:29 UTC ---
Let me close this PR as WORKSFORME. If the problem resurface, please open a new
PR.
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug tree-optimization/43716] [4.6/4.7/4.8 Regression] Revision 158105 miscompiles doduc.f90
[not found] <bug-43716-4@http.gcc.gnu.org/bugzilla/>
` (16 preceding siblings ...)
2013-01-08 18:26 ` dominiq at lps dot ens.fr
@ 2013-01-08 19:24 ` ubizjak at gmail dot com
2013-01-08 19:53 ` dominiq at lps dot ens.fr
2013-01-09 8:52 ` richard.guenther at gmail dot com
19 siblings, 0 replies; 20+ messages in thread
From: ubizjak at gmail dot com @ 2013-01-08 19:24 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
--- Comment #47 from Uros Bizjak <ubizjak at gmail dot com> 2013-01-08 19:23:41 UTC ---
(In reply to comment #44)
> Can't reproduce on x86_64-linux with current trunk at -O3 -g -ffast-math, both
> with LRA and when LRA is disabled. From what I understood, this bug used to be
> present on darwin, but went away two years ago, then it got reopened for
> x86_64-linux in July and apparently doesn't reproduce anymore either. So, is
> this broken anywhere now?
Sorry for late answer, the NaN is still generated with current mainline, as can
be proved with:
"-g -O3 -ffast-math -ffpe-trap=invalid"
$ ./a.out
MAIN : FIN S00002
MAIN : FIN S00001
MAIN : FIN S00011
MAIN : FIN S00022
Program received signal SIGFPE: Floating-point exception - erroneous arithmetic
operation.
Backtrace for this error:
#0 0x7F9A9AF66FD7
#1 0x7F9A9AF675A4
#2 0x346B2359AF
#3 0x40AAA6 in s00017_ at doduc.f90:1852
#4 0x41B9E9 in MAIN__ at doduc.f90:186
Floating point exception
*However*, --ffast-math implies -fno-signaling-nans, and this contradicts with
-ffpe-trap=invalid.
Going a bit further:
"-g -O3 -ffast-math -fsignaling-nans -ffpe-trap=invalid"
works as expected, without FP exceptions.
So, as far as I'm concerned, "--fast-math -ffpe-trap=invalid" combination of
options (and the whole issue with NaNs on x86_64 as dubiously raised in comment
#34) is invalid.
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug tree-optimization/43716] [4.6/4.7/4.8 Regression] Revision 158105 miscompiles doduc.f90
[not found] <bug-43716-4@http.gcc.gnu.org/bugzilla/>
` (17 preceding siblings ...)
2013-01-08 19:24 ` ubizjak at gmail dot com
@ 2013-01-08 19:53 ` dominiq at lps dot ens.fr
2013-01-09 8:52 ` richard.guenther at gmail dot com
19 siblings, 0 replies; 20+ messages in thread
From: dominiq at lps dot ens.fr @ 2013-01-08 19:53 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
--- Comment #48 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2013-01-08 19:52:39 UTC ---
>From comment #40:
> with -ffast-math, so for example
>
> if (x != 0)
> tem = y / x;
> else
> tem = 0.;
> ... do sth with tem ...
>
> will execute y / x unconditionally based on the fact that it cannot trap.
This optimization generates an exception trapped when using -ffpe-trap=invalid
along with -ffast-math.
This unfortunately prevents any debugging based -ffpe-trap=invalid for
miscompilations occurring with -ffast-math. One thing I hope, though I am not
sure about it, is that the above block is still compiled as
tem=y/x
if (x==0) tem=0.
My original report was for '-O3 -funsafe-math-optimizations -ffinite-math-only'
without -ffpe-trap=invalid. The segmentation fault resulted from the fact that
some variables were used to access a table and were out of bound when the
miscompilation generated some NAN (see comment #13).
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug tree-optimization/43716] [4.6/4.7/4.8 Regression] Revision 158105 miscompiles doduc.f90
[not found] <bug-43716-4@http.gcc.gnu.org/bugzilla/>
` (18 preceding siblings ...)
2013-01-08 19:53 ` dominiq at lps dot ens.fr
@ 2013-01-09 8:52 ` richard.guenther at gmail dot com
19 siblings, 0 replies; 20+ messages in thread
From: richard.guenther at gmail dot com @ 2013-01-09 8:52 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
--- Comment #49 from richard.guenther at gmail dot com <richard.guenther at gmail dot com> 2013-01-09 08:52:21 UTC ---
On Tue, Jan 8, 2013 at 8:52 PM, dominiq at lps dot ens.fr
<gcc-bugzilla@gcc.gnu.org> wrote:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43716
>
> --- Comment #48 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2013-01-08 19:52:39 UTC ---
> From comment #40:
>
>> with -ffast-math, so for example
>>
>> if (x != 0)
>> tem = y / x;
>> else
>> tem = 0.;
>> ... do sth with tem ...
>>
>> will execute y / x unconditionally based on the fact that it cannot trap.
>
> This optimization generates an exception trapped when using -ffpe-trap=invalid
> along with -ffast-math.
> This unfortunately prevents any debugging based -ffpe-trap=invalid for
> miscompilations occurring with -ffast-math.
Well - that's maybe unfortunate but expected. You can't have both ;)
> One thing I hope, though I am not
> sure about it, is that the above block is still compiled as
>
> tem=y/x
> if (x==0) tem=0.
Yes, it's basically turned into an unconditional divide plus a conditional move
based on the fact that we cannot vectorize non-straight-line-code (so
it's really
only a vectorization enabler).
> My original report was for '-O3 -funsafe-math-optimizations -ffinite-math-only'
> without -ffpe-trap=invalid. The segmentation fault resulted from the fact that
> some variables were used to access a table and were out of bound when the
> miscompilation generated some NAN (see comment #13).
Yes, that's another common issue - with FP indexing even slight
rounding differences can cause bogus accesses (consider producing
a[0.99] instead of a[1.0]). That mostly happens with FP loop induction
variables that are also used for indexing (a really bad practice the frontend
should warn about - at least when -funsafe-math-optimizations is in effect).
Richard.
> --
> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2013-01-09 8:52 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <bug-43716-4@http.gcc.gnu.org/bugzilla/>
2012-07-21 10:42 ` [Bug tree-optimization/43716] [4.6/4.7/4.8 Regression] Revision 158105 miscompiles doduc.f90 ubizjak at gmail dot com
2012-07-21 10:45 ` ubizjak at gmail dot com
2012-07-21 10:49 ` ubizjak at gmail dot com
2012-07-21 11:31 ` ubizjak at gmail dot com
2012-07-21 12:17 ` ubizjak at gmail dot com
2012-07-21 12:35 ` ubizjak at gmail dot com
2012-07-21 13:40 ` dominiq at lps dot ens.fr
2012-07-21 13:52 ` ubizjak at gmail dot com
2012-07-21 14:43 ` dominiq at lps dot ens.fr
2012-07-22 10:48 ` dominiq at lps dot ens.fr
2012-07-23 8:13 ` rguenth at gcc dot gnu.org
2012-12-07 9:21 ` rguenth at gcc dot gnu.org
2012-12-07 13:40 ` dominiq at lps dot ens.fr
2012-12-07 14:29 ` rguenth at gcc dot gnu.org
2012-12-18 9:14 ` jakub at gcc dot gnu.org
2012-12-18 10:24 ` jakub at gcc dot gnu.org
2013-01-08 18:26 ` dominiq at lps dot ens.fr
2013-01-08 19:24 ` ubizjak at gmail dot com
2013-01-08 19:53 ` dominiq at lps dot ens.fr
2013-01-09 8:52 ` richard.guenther at gmail dot com
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).