public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/55633] New: [4.8 Regression] FAIL: gfortran.dg/g77/f90-intrinsic-bit.f -Os execution test
@ 2012-12-09 20:53 danglin at gcc dot gnu.org
2012-12-10 8:57 ` [Bug fortran/55633] " burnus at gcc dot gnu.org
` (10 more replies)
0 siblings, 11 replies; 12+ messages in thread
From: danglin at gcc dot gnu.org @ 2012-12-09 20:53 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55633
Bug #: 55633
Summary: [4.8 Regression] FAIL:
gfortran.dg/g77/f90-intrinsic-bit.f -Os execution
test
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned@gcc.gnu.org
ReportedBy: danglin@gcc.gnu.org
Host: hppa*-*-* (32-bit)
Target: hppa*-*-* (32-bit)
Build: hppa*-*-* (32-bit)
Executing on host: /test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../gfortran
-B/test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../
-B/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/
/test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/g77/f90-intrinsic-bit.f
-fno-diagnostics-show-caret -Os -pedantic-errors
-B/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs
-L/test/gnu/gcc/objdi
r/hppa2.0w-hp-hpux11.11/./libgfortran/.libs
-L/test/gnu/gcc/objdir/hppa2.0w-hp-h
pux11.11/./libgfortran/.libs
-B/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libq
uadmath/.libs -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libquadmath/.libs
-
L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libquadmath/.libs -lm -o
./f90-
intrinsic-bit.exe (timeout = 300)
spawn /test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../gfortran
-B/test/gnu/gcc
/objdir/gcc/testsuite/gfortran/../../
-B/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.
11/./libgfortran/
/test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/g77/f90-intrinsic-bit.f
-fno-diagnostics-show-caret -Os -pedantic-errors
-B/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs
-L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs
-L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs
-B/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libquadmath/.libs
-L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libquadmath/.libs
-L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libquadmath/.libs -lm -o
./f90-intrinsic-bit.exePASS: gfortran.dg/g77/f90-intrinsic-bit.f -Os (test
for excess errors)
Setting LD_LIBRARY_PATH to
.:/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs:/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs:/test
/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libquadmath/.libs:/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libquadmath/.libs:/test/gnu/gcc/objdir/gcc:.:/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs:/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs:/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libquadmath/.libs:/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libquadmath/.libs:/test/gnu/gcc/objdir/gcc
spawn [open ...]
Test BIT_SIZE(integer(8)) FAILED
Got 64 expected 0
Backtrace for this error:
#0 0xC1C39DDB
FAIL: gfortran.dg/g77/f90-intrinsic-bit.f -Os execution test
Expected value seems wrong...
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/55633] [4.8 Regression] FAIL: gfortran.dg/g77/f90-intrinsic-bit.f -Os execution test
2012-12-09 20:53 [Bug fortran/55633] New: [4.8 Regression] FAIL: gfortran.dg/g77/f90-intrinsic-bit.f -Os execution test danglin at gcc dot gnu.org
@ 2012-12-10 8:57 ` burnus at gcc dot gnu.org
2012-12-10 9:43 ` rguenth at gcc dot gnu.org
` (9 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: burnus at gcc dot gnu.org @ 2012-12-10 8:57 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55633
Tobias Burnus <burnus at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |burnus at gcc dot gnu.org
--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-12-10 08:57:04 UTC ---
Can you pin-point which version causes the regression?
BIT_SIZE(m) is (correctly) 64 while "ma" is (wrongly) "0". And "NOT returns the
bitwise Boolean inverse of I."
Can you run the following code? It matches the failing code but contains some
debugging printout.
Can you also try "kind=4"? That seems to work while "kind=8" seems to fail.
integer(kind=8) m, ma
ma = 0
m = 0
print '("m =",i21,z17," ma=",i2,z13)', m, m, ma, ma
m = not(m)
print '("m =",i21,z17," ma=",i2,z13)', m, m, ma, ma
do while ( (m.ne.0) .and. (ma.lt.127) )
ma = ma + 1
m = ishft(m,-1)
print '("m =",i21,z17,", ma=",i2,z13)', m, m, ma, ma
end do
print *, BIT_SIZE(m), ma
if (BIT_SIZE(m) /= ma) error stop
end
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/55633] [4.8 Regression] FAIL: gfortran.dg/g77/f90-intrinsic-bit.f -Os execution test
2012-12-09 20:53 [Bug fortran/55633] New: [4.8 Regression] FAIL: gfortran.dg/g77/f90-intrinsic-bit.f -Os execution test danglin at gcc dot gnu.org
2012-12-10 8:57 ` [Bug fortran/55633] " burnus at gcc dot gnu.org
@ 2012-12-10 9:43 ` rguenth at gcc dot gnu.org
2012-12-10 13:31 ` dave.anglin at bell dot net
` (8 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: rguenth at gcc dot gnu.org @ 2012-12-10 9:43 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55633
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |wrong-code
Target Milestone|--- |4.8.0
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> 2012-12-10 09:42:58 UTC ---
If only -Os fails then it's (liekly) not a frontend issue. Leaving P3 for the
moment.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/55633] [4.8 Regression] FAIL: gfortran.dg/g77/f90-intrinsic-bit.f -Os execution test
2012-12-09 20:53 [Bug fortran/55633] New: [4.8 Regression] FAIL: gfortran.dg/g77/f90-intrinsic-bit.f -Os execution test danglin at gcc dot gnu.org
2012-12-10 8:57 ` [Bug fortran/55633] " burnus at gcc dot gnu.org
2012-12-10 9:43 ` rguenth at gcc dot gnu.org
@ 2012-12-10 13:31 ` dave.anglin at bell dot net
2012-12-10 16:29 ` jakub at gcc dot gnu.org
` (7 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: dave.anglin at bell dot net @ 2012-12-10 13:31 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55633
--- Comment #3 from dave.anglin at bell dot net 2012-12-10 13:31:31 UTC ---
On 10-Dec-12, at 3:57 AM, burnus at gcc dot gnu.org wrote:
> Can you pin-point which version causes the regression?
At this point, I onnly know the test didn't fail in early September.
>
> BIT_SIZE(m) is (correctly) 64 while "ma" is (wrongly) "0". And "NOT
> returns the
> bitwise Boolean inverse of I."
>
> Can you run the following code? It matches the failing code but
> contains some
> debugging printout.
>
> Can you also try "kind=4"? That seems to work while "kind=8" seems
> to fail.
>
> integer(kind=8) m, ma
> ma = 0
> m = 0
> print '("m =",i21,z17," ma=",i2,z13)', m, m, ma, ma
> m = not(m)
> print '("m =",i21,z17," ma=",i2,z13)', m, m, ma, ma
> do while ( (m.ne.0) .and. (ma.lt.127) )
> ma = ma + 1
> m = ishft(m,-1)
> print '("m =",i21,z17,", ma=",i2,z13)', m, m, ma, ma
> end do
> print *, BIT_SIZE(m), ma
> if (BIT_SIZE(m) /= ma) error stop
> end
Here are the results from hppa-unknown-linux-gnu which also fails.
kind=8:
m = 0 0 ma= 0 0
m = -1 FFFFFFFFFFFFFFFF ma= 0 0
m = 9223372036854775807 7FFFFFFFFFFFFFFF, ma= 1 1
m = 4611686018427387903 3FFFFFFFFFFFFFFF, ma= 2 2
m = 2305843009213693951 1FFFFFFFFFFFFFFF, ma= 3 3
m = 1152921504606846975 FFFFFFFFFFFFFFF, ma= 4 4
m = 576460752303423487 7FFFFFFFFFFFFFF, ma= 5 5
m = 288230376151711743 3FFFFFFFFFFFFFF, ma= 6 6
m = 144115188075855871 1FFFFFFFFFFFFFF, ma= 7 7
m = 72057594037927935 FFFFFFFFFFFFFF, ma= 8 8
m = 36028797018963967 7FFFFFFFFFFFFF, ma= 9 9
m = 18014398509481983 3FFFFFFFFFFFFF, ma=10 A
m = 9007199254740991 1FFFFFFFFFFFFF, ma=11 B
m = 4503599627370495 FFFFFFFFFFFFF, ma=12 C
m = 2251799813685247 7FFFFFFFFFFFF, ma=13 D
m = 1125899906842623 3FFFFFFFFFFFF, ma=14 E
m = 562949953421311 1FFFFFFFFFFFF, ma=15 F
m = 281474976710655 FFFFFFFFFFFF, ma=16 10
m = 140737488355327 7FFFFFFFFFFF, ma=17 11
m = 70368744177663 3FFFFFFFFFFF, ma=18 12
m = 35184372088831 1FFFFFFFFFFF, ma=19 13
m = 17592186044415 FFFFFFFFFFF, ma=20 14
m = 8796093022207 7FFFFFFFFFF, ma=21 15
m = 4398046511103 3FFFFFFFFFF, ma=22 16
m = 2199023255551 1FFFFFFFFFF, ma=23 17
m = 1099511627775 FFFFFFFFFF, ma=24 18
m = 549755813887 7FFFFFFFFF, ma=25 19
m = 274877906943 3FFFFFFFFF, ma=26 1A
m = 137438953471 1FFFFFFFFF, ma=27 1B
m = 68719476735 FFFFFFFFF, ma=28 1C
m = 34359738367 7FFFFFFFF, ma=29 1D
m = 17179869183 3FFFFFFFF, ma=30 1E
m = 8589934591 1FFFFFFFF, ma=31 1F
m = 4294967295 FFFFFFFF, ma=32 20
m = 2147483647 7FFFFFFF, ma=33 21
m = 1073741823 3FFFFFFF, ma=34 22
m = 536870911 1FFFFFFF, ma=35 23
m = 268435455 FFFFFFF, ma=36 24
m = 134217727 7FFFFFF, ma=37 25
m = 67108863 3FFFFFF, ma=38 26
m = 33554431 1FFFFFF, ma=39 27
m = 16777215 FFFFFF, ma=40 28
m = 8388607 7FFFFF, ma=41 29
m = 4194303 3FFFFF, ma=42 2A
m = 2097151 1FFFFF, ma=43 2B
m = 1048575 FFFFF, ma=44 2C
m = 524287 7FFFF, ma=45 2D
m = 262143 3FFFF, ma=46 2E
m = 131071 1FFFF, ma=47 2F
m = 65535 FFFF, ma=48 30
m = 32767 7FFF, ma=49 31
m = 16383 3FFF, ma=50 32
m = 8191 1FFF, ma=51 33
m = 4095 FFF, ma=52 34
m = 2047 7FF, ma=53 35
m = 1023 3FF, ma=54 36
m = 511 1FF, ma=55 37
m = 255 FF, ma=56 38
m = 127 7F, ma=57 39
m = 63 3F, ma=58 3A
m = 31 1F, ma=59 3B
m = 15 F, ma=60 3C
m = 7 7, ma=61 3D
m = 3 3, ma=62 3E
m = 1 1, ma=63 3F
m = 0 0, ma=64 40
64 64
kind=4:
m = 0 0 ma= 0 0
m = -1 FFFFFFFF ma= 0 0
m = 2147483647 7FFFFFFF, ma= 1 1
m = 1073741823 3FFFFFFF, ma= 2 2
m = 536870911 1FFFFFFF, ma= 3 3
m = 268435455 FFFFFFF, ma= 4 4
m = 134217727 7FFFFFF, ma= 5 5
m = 67108863 3FFFFFF, ma= 6 6
m = 33554431 1FFFFFF, ma= 7 7
m = 16777215 FFFFFF, ma= 8 8
m = 8388607 7FFFFF, ma= 9 9
m = 4194303 3FFFFF, ma=10 A
m = 2097151 1FFFFF, ma=11 B
m = 1048575 FFFFF, ma=12 C
m = 524287 7FFFF, ma=13 D
m = 262143 3FFFF, ma=14 E
m = 131071 1FFFF, ma=15 F
m = 65535 FFFF, ma=16 10
m = 32767 7FFF, ma=17 11
m = 16383 3FFF, ma=18 12
m = 8191 1FFF, ma=19 13
m = 4095 FFF, ma=20 14
m = 2047 7FF, ma=21 15
m = 1023 3FF, ma=22 16
m = 511 1FF, ma=23 17
m = 255 FF, ma=24 18
m = 127 7F, ma=25 19
m = 63 3F, ma=26 1A
m = 31 1F, ma=27 1B
m = 15 F, ma=28 1C
m = 7 7, ma=29 1D
m = 3 3, ma=30 1E
m = 1 1, ma=31 1F
m = 0 0, ma=32 20
32 32
--
John David Anglin dave.anglin@bell.net
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/55633] [4.8 Regression] FAIL: gfortran.dg/g77/f90-intrinsic-bit.f -Os execution test
2012-12-09 20:53 [Bug fortran/55633] New: [4.8 Regression] FAIL: gfortran.dg/g77/f90-intrinsic-bit.f -Os execution test danglin at gcc dot gnu.org
` (2 preceding siblings ...)
2012-12-10 13:31 ` dave.anglin at bell dot net
@ 2012-12-10 16:29 ` jakub at gcc dot gnu.org
2012-12-11 1:16 ` dave.anglin at bell dot net
` (6 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: jakub at gcc dot gnu.org @ 2012-12-10 16:29 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55633
--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-12-10 16:29:10 UTC ---
The test is really large, I guess it would be useful if you could try to reduce
the testcase as long as it still fails that BIT_SIZE(integer(8)) test.
Or can you step through the interesting part of the testcase and see where
things go wrong? I've eyeballed the *.final assembly of the ma computation and
it looks ok to me.
ldi 0,%r19
ldi 0,%r20
ldi 126,%r31
ldi -1,%r28
ldi -1,%r29
L$0032:
copy %r19,%r21
copy %r20,%r22
addi 1,%r20,%r20
addc %r19,%r0,%r19
comiclr,>= 0,%r21,%r0
b,n L$0029
comib,<> 0,%r21,L$0050
or %r28,%r29,%r23
comclr,>>= %r31,%r22,%r0
b,n L$0029
L$0050:
comib,=,n 0,%r23,L$0029
shd %r28,%r29,1,%r21
extru %r28,30,31,%r22
copy %r21,%r29
b L$0032
copy %r22,%r28
L$0029:
stw %r21,-240(%r30)
ldo -240(%r30),%r25
ldi 20,%r23
stw %r22,-236(%r30)
is the assembly I get for the interesting part. So, if you have the same, can
you step through this and see why you get 0 in %r21/%r22?
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/55633] [4.8 Regression] FAIL: gfortran.dg/g77/f90-intrinsic-bit.f -Os execution test
2012-12-09 20:53 [Bug fortran/55633] New: [4.8 Regression] FAIL: gfortran.dg/g77/f90-intrinsic-bit.f -Os execution test danglin at gcc dot gnu.org
` (3 preceding siblings ...)
2012-12-10 16:29 ` jakub at gcc dot gnu.org
@ 2012-12-11 1:16 ` dave.anglin at bell dot net
2012-12-11 1:29 ` danglin at gcc dot gnu.org
` (5 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: dave.anglin at bell dot net @ 2012-12-11 1:16 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55633
--- Comment #5 from dave.anglin at bell dot net 2012-12-11 01:16:16 UTC ---
On 10-Dec-12, at 11:29 AM, jakub at gcc dot gnu.org wrote:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55633
>
> --- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org>
> 2012-12-10 16:29:10 UTC ---
> The test is really large, I guess it would be useful if you could
> try to reduce
> the testcase as long as it still fails that BIT_SIZE(integer(8)) test.
>
> Or can you step through the interesting part of the testcase and see
> where
> things go wrong? I've eyeballed the *.final assembly of the ma
> computation and
> it looks ok to me.
I'm seeing different code:
; /home/dave/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/g77/f90-
intrinsic-bit.f:48
.loc 1 48 0
ldi 0,%r28
ldi 0,%r29
.LBB19:
; /home/dave/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/g77/f90-
intrinsic-bit.f:55
.loc 1 55 0
ldo -240(%r30),%r25
.LBE19:
; /home/dave/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/g77/f90-
intrinsic-bit.f:48
.loc 1 48 0
stw %r28,-240(%r30)
stw %r29,-236(%r30)
.LBB20:
; /home/dave/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/g77/f90-
intrinsic-bit.f:55
.loc 1 55 0
ldi 20,%r23
ldil LR'.LC12,%r26
ldil LR'.LC13,%r24
ldo RR'.LC12(%r26),%r26
ldo RR'.LC13(%r24),%r24
bl c_i8_,%r2
ldil LR'.LC15,%r3
The second argument of the call is passed in r25 (pointer to ma). As
can be seen,
ma is 0.
In .expand, we have:
ma = 0;
c_i8 (&C.920, &ma, &"BIT_SIZE(integer(8))"[1]{lb: 1 sz: 1}, 20);
So, I guess this is likely a tree optimization bug.
--
John David Anglin dave.anglin@bell.net
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/55633] [4.8 Regression] FAIL: gfortran.dg/g77/f90-intrinsic-bit.f -Os execution test
2012-12-09 20:53 [Bug fortran/55633] New: [4.8 Regression] FAIL: gfortran.dg/g77/f90-intrinsic-bit.f -Os execution test danglin at gcc dot gnu.org
` (4 preceding siblings ...)
2012-12-11 1:16 ` dave.anglin at bell dot net
@ 2012-12-11 1:29 ` danglin at gcc dot gnu.org
2012-12-11 2:00 ` danglin at gcc dot gnu.org
` (4 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: danglin at gcc dot gnu.org @ 2012-12-11 1:29 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55633
--- Comment #6 from John David Anglin <danglin at gcc dot gnu.org> 2012-12-11 01:29:00 UTC ---
Created attachment 28920
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28920
Reduced testcase
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/55633] [4.8 Regression] FAIL: gfortran.dg/g77/f90-intrinsic-bit.f -Os execution test
2012-12-09 20:53 [Bug fortran/55633] New: [4.8 Regression] FAIL: gfortran.dg/g77/f90-intrinsic-bit.f -Os execution test danglin at gcc dot gnu.org
` (5 preceding siblings ...)
2012-12-11 1:29 ` danglin at gcc dot gnu.org
@ 2012-12-11 2:00 ` danglin at gcc dot gnu.org
2012-12-11 9:00 ` jakub at gcc dot gnu.org
` (3 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: danglin at gcc dot gnu.org @ 2012-12-11 2:00 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55633
--- Comment #7 from John David Anglin <danglin at gcc dot gnu.org> 2012-12-11 02:00:11 UTC ---
Created attachment 28921
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28921
Tree dump
Looks to me like things go bad in lim1.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/55633] [4.8 Regression] FAIL: gfortran.dg/g77/f90-intrinsic-bit.f -Os execution test
2012-12-09 20:53 [Bug fortran/55633] New: [4.8 Regression] FAIL: gfortran.dg/g77/f90-intrinsic-bit.f -Os execution test danglin at gcc dot gnu.org
` (6 preceding siblings ...)
2012-12-11 2:00 ` danglin at gcc dot gnu.org
@ 2012-12-11 9:00 ` jakub at gcc dot gnu.org
2012-12-11 10:23 ` jakub at gcc dot gnu.org
` (2 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: jakub at gcc dot gnu.org @ 2012-12-11 9:00 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55633
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2012-12-11
CC| |jakub at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-12-11 08:59:53 UTC ---
Indeed, looks like HWI issue, as I can reproduce it with i686-linux -> hppa
cross, but not x86_64-linux -> hppa. The first difference starts during
ivcanon, looking into it.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/55633] [4.8 Regression] FAIL: gfortran.dg/g77/f90-intrinsic-bit.f -Os execution test
2012-12-09 20:53 [Bug fortran/55633] New: [4.8 Regression] FAIL: gfortran.dg/g77/f90-intrinsic-bit.f -Os execution test danglin at gcc dot gnu.org
` (7 preceding siblings ...)
2012-12-11 9:00 ` jakub at gcc dot gnu.org
@ 2012-12-11 10:23 ` jakub at gcc dot gnu.org
2012-12-12 9:33 ` jakub at gcc dot gnu.org
2012-12-12 9:46 ` jakub at gcc dot gnu.org
10 siblings, 0 replies; 12+ messages in thread
From: jakub at gcc dot gnu.org @ 2012-12-11 10:23 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55633
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org
|gnu.org |
--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-12-11 10:22:49 UTC ---
Created attachment 28923
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28923
gcc48-pr55633.patch
Untested fix.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/55633] [4.8 Regression] FAIL: gfortran.dg/g77/f90-intrinsic-bit.f -Os execution test
2012-12-09 20:53 [Bug fortran/55633] New: [4.8 Regression] FAIL: gfortran.dg/g77/f90-intrinsic-bit.f -Os execution test danglin at gcc dot gnu.org
` (8 preceding siblings ...)
2012-12-11 10:23 ` jakub at gcc dot gnu.org
@ 2012-12-12 9:33 ` jakub at gcc dot gnu.org
2012-12-12 9:46 ` jakub at gcc dot gnu.org
10 siblings, 0 replies; 12+ messages in thread
From: jakub at gcc dot gnu.org @ 2012-12-12 9:33 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55633
--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-12-12 09:33:00 UTC ---
Author: jakub
Date: Wed Dec 12 09:32:52 2012
New Revision: 194438
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194438
Log:
PR fortran/55633
* tree-ssa-loop-niter.c (discover_iteration_bound_by_body_walk):
Ignore bounds on which bound += double_int_one overflowed.
* gcc.dg/torture/pr55633.c: New test.
Added:
trunk/gcc/testsuite/gcc.dg/torture/pr55633.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-loop-niter.c
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug fortran/55633] [4.8 Regression] FAIL: gfortran.dg/g77/f90-intrinsic-bit.f -Os execution test
2012-12-09 20:53 [Bug fortran/55633] New: [4.8 Regression] FAIL: gfortran.dg/g77/f90-intrinsic-bit.f -Os execution test danglin at gcc dot gnu.org
` (9 preceding siblings ...)
2012-12-12 9:33 ` jakub at gcc dot gnu.org
@ 2012-12-12 9:46 ` jakub at gcc dot gnu.org
10 siblings, 0 replies; 12+ messages in thread
From: jakub at gcc dot gnu.org @ 2012-12-12 9:46 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55633
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED
--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-12-12 09:46:10 UTC ---
Fixed.
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2012-12-12 9:46 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-12-09 20:53 [Bug fortran/55633] New: [4.8 Regression] FAIL: gfortran.dg/g77/f90-intrinsic-bit.f -Os execution test danglin at gcc dot gnu.org
2012-12-10 8:57 ` [Bug fortran/55633] " burnus at gcc dot gnu.org
2012-12-10 9:43 ` rguenth at gcc dot gnu.org
2012-12-10 13:31 ` dave.anglin at bell dot net
2012-12-10 16:29 ` jakub at gcc dot gnu.org
2012-12-11 1:16 ` dave.anglin at bell dot net
2012-12-11 1:29 ` danglin at gcc dot gnu.org
2012-12-11 2:00 ` danglin at gcc dot gnu.org
2012-12-11 9:00 ` jakub at gcc dot gnu.org
2012-12-11 10:23 ` jakub at gcc dot gnu.org
2012-12-12 9:33 ` jakub at gcc dot gnu.org
2012-12-12 9:46 ` jakub at gcc dot gnu.org
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).