public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug rtl-optimization/64921] New: [5 Regression] FAIL: gfortran.dg/class_allocate_18.f90 with -fPIC
@ 2015-02-03 15:42 hjl.tools at gmail dot com
2015-02-03 16:03 ` [Bug rtl-optimization/64921] " jakub at gcc dot gnu.org
` (28 more replies)
0 siblings, 29 replies; 30+ messages in thread
From: hjl.tools at gmail dot com @ 2015-02-03 15:42 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64921
Bug ID: 64921
Summary: [5 Regression] FAIL: gfortran.dg/class_allocate_18.f90
with -fPIC
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
On x86-32, r220369 gave
FAIL: gfortran.dg/class_allocate_18.f90 -O0 execution test
FAIL: gfortran.dg/class_allocate_18.f90 -O1 execution test
FAIL: gfortran.dg/class_allocate_18.f90 -O2 execution test
FAIL: gfortran.dg/class_allocate_18.f90 -O3 -fomit-frame-pointer execution
test
FAIL: gfortran.dg/class_allocate_18.f90 -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions execution test
FAIL: gfortran.dg/class_allocate_18.f90 -O3 -fomit-frame-pointer
-funroll-loops execution test
FAIL: gfortran.dg/class_allocate_18.f90 -O3 -g execution test
FAIL: gfortran.dg/class_allocate_18.f90 -Os execution test
when -fPIC is used. r220364 is OK.
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug rtl-optimization/64921] [5 Regression] FAIL: gfortran.dg/class_allocate_18.f90 with -fPIC
2015-02-03 15:42 [Bug rtl-optimization/64921] New: [5 Regression] FAIL: gfortran.dg/class_allocate_18.f90 with -fPIC hjl.tools at gmail dot com
@ 2015-02-03 16:03 ` jakub at gcc dot gnu.org
2015-02-03 17:22 ` hjl.tools at gmail dot com
` (27 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: jakub at gcc dot gnu.org @ 2015-02-03 16:03 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64921
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
r220371 generates identical code to r220350 on this testcase.
Do you mean libgfortran.so has been miscompiled?
But then really -fPIC shouldn't matter here, as libgfortran is built with
-fpic, and I've certainly bootstrapped/regtested my patch on both i686-linux
and x86_64-linux.
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug rtl-optimization/64921] [5 Regression] FAIL: gfortran.dg/class_allocate_18.f90 with -fPIC
2015-02-03 15:42 [Bug rtl-optimization/64921] New: [5 Regression] FAIL: gfortran.dg/class_allocate_18.f90 with -fPIC hjl.tools at gmail dot com
2015-02-03 16:03 ` [Bug rtl-optimization/64921] " jakub at gcc dot gnu.org
@ 2015-02-03 17:22 ` hjl.tools at gmail dot com
2015-02-03 17:32 ` [Bug rtl-optimization/64921] [4.9/5 Regression] FAIL: gfortran.dg/class_allocate_18.f90 hjl.tools at gmail dot com
` (26 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: hjl.tools at gmail dot com @ 2015-02-03 17:22 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64921
--- Comment #2 from H.J. Lu <hjl.tools at gmail dot com> ---
I got
Program received signal SIGSEGV: Segmentation fault - invalid memory reference.
Backtrace for this error:
#0 0xF763FACE
#1 0xF763EBDE
#2 0xF773CBBF
#3 0x8048BA5 in __final_main_T2.3337 at class_allocate_18.f90:?
#4 0x8048D68 in __final_main_T3.3328 at class_allocate_18.f90:?
#5 0x8048A59 in MAIN__ at class_allocate_18.f90:?
FAIL: gfortran.dg/class_allocate_18.f90 -O1 execution test
But I couldn't reproduce it on another machine. I will keep an eye on it.
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug rtl-optimization/64921] [4.9/5 Regression] FAIL: gfortran.dg/class_allocate_18.f90
2015-02-03 15:42 [Bug rtl-optimization/64921] New: [5 Regression] FAIL: gfortran.dg/class_allocate_18.f90 with -fPIC hjl.tools at gmail dot com
2015-02-03 16:03 ` [Bug rtl-optimization/64921] " jakub at gcc dot gnu.org
2015-02-03 17:22 ` hjl.tools at gmail dot com
@ 2015-02-03 17:32 ` hjl.tools at gmail dot com
2015-02-03 21:30 ` pault at gcc dot gnu.org
` (25 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: hjl.tools at gmail dot com @ 2015-02-03 17:32 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64921
H.J. Lu <hjl.tools at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |pault at gcc dot gnu.org
Summary|[5 Regression] FAIL: |[4.9/5 Regression] FAIL:
|gfortran.dg/class_allocate_ |gfortran.dg/class_allocate_
|18.f90 with -fPIC |18.f90
--- Comment #3 from H.J. Lu <hjl.tools at gmail dot com> ---
gfortran.dg/class_allocate_18.f90 seems to fail at random on trunk
and 4.9 branch:
https://gcc.gnu.org/ml/gcc-testresults/2015-02/msg00308.html
It is caused by r220191.
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug rtl-optimization/64921] [4.9/5 Regression] FAIL: gfortran.dg/class_allocate_18.f90
2015-02-03 15:42 [Bug rtl-optimization/64921] New: [5 Regression] FAIL: gfortran.dg/class_allocate_18.f90 with -fPIC hjl.tools at gmail dot com
` (2 preceding siblings ...)
2015-02-03 17:32 ` [Bug rtl-optimization/64921] [4.9/5 Regression] FAIL: gfortran.dg/class_allocate_18.f90 hjl.tools at gmail dot com
@ 2015-02-03 21:30 ` pault at gcc dot gnu.org
2015-02-04 3:00 ` ramana at gcc dot gnu.org
` (24 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: pault at gcc dot gnu.org @ 2015-02-03 21:30 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64921
--- Comment #4 from Paul Thomas <pault at gcc dot gnu.org> ---
(In reply to H.J. Lu from comment #3)
> gfortran.dg/class_allocate_18.f90 seems to fail at random on trunk
> and 4.9 branch:
>
> https://gcc.gnu.org/ml/gcc-testresults/2015-02/msg00308.html
>
> It is caused by r220191.
HJ,
I'll take a look at this tomorrow night. I find it to be enormously surprising
that r220191 is causing this regression. I rather think that I have exposed
another underlying bug.
Thanks
Paul
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug rtl-optimization/64921] [4.9/5 Regression] FAIL: gfortran.dg/class_allocate_18.f90
2015-02-03 15:42 [Bug rtl-optimization/64921] New: [5 Regression] FAIL: gfortran.dg/class_allocate_18.f90 with -fPIC hjl.tools at gmail dot com
` (3 preceding siblings ...)
2015-02-03 21:30 ` pault at gcc dot gnu.org
@ 2015-02-04 3:00 ` ramana at gcc dot gnu.org
2015-02-04 18:21 ` pault at gcc dot gnu.org
` (23 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: ramana at gcc dot gnu.org @ 2015-02-04 3:00 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64921
Ramana Radhakrishnan <ramana at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ramana at gcc dot gnu.org
--- Comment #5 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
(In reply to Paul Thomas from comment #4)
> (In reply to H.J. Lu from comment #3)
> > gfortran.dg/class_allocate_18.f90 seems to fail at random on trunk
> > and 4.9 branch:
> >
> > https://gcc.gnu.org/ml/gcc-testresults/2015-02/msg00308.html
> >
> > It is caused by r220191.
>
> HJ,
>
> I'll take a look at this tomorrow night. I find it to be enormously
> surprising that r220191 is causing this regression. I rather think that I
> have exposed another underlying bug.
>
> Thanks
>
> Paul
I've been seeing this test fail in cross-testing on arm-linux-gnueabi{hf} too.
However native testresults from gcc-testresults don't show this coming up
often. Not sure what's going on here.
Ramana
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug rtl-optimization/64921] [4.9/5 Regression] FAIL: gfortran.dg/class_allocate_18.f90
2015-02-03 15:42 [Bug rtl-optimization/64921] New: [5 Regression] FAIL: gfortran.dg/class_allocate_18.f90 with -fPIC hjl.tools at gmail dot com
` (4 preceding siblings ...)
2015-02-04 3:00 ` ramana at gcc dot gnu.org
@ 2015-02-04 18:21 ` pault at gcc dot gnu.org
2015-02-04 18:31 ` hjl.tools at gmail dot com
` (22 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: pault at gcc dot gnu.org @ 2015-02-04 18:21 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64921
Paul Thomas <pault at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jaydub66 at gmail dot com
--- Comment #6 from Paul Thomas <pault at gcc dot gnu.org> ---
(In reply to H.J. Lu from comment #2)
> I got
>
> Program received signal SIGSEGV: Segmentation fault - invalid memory
> reference.
>
> Backtrace for this error:
> #0 0xF763FACE
> #1 0xF763EBDE
> #2 0xF773CBBF
> #3 0x8048BA5 in __final_main_T2.3337 at class_allocate_18.f90:?
> #4 0x8048D68 in __final_main_T3.3328 at class_allocate_18.f90:?
> #5 0x8048A59 in MAIN__ at class_allocate_18.f90:?
> FAIL: gfortran.dg/class_allocate_18.f90 -O1 execution test
>
> But I couldn't reproduce it on another machine. I will keep an eye on it.
Hi HJ,
Given that the error is sporadic, are you sure that the offending revisions are
not 220125 and 220130 - PR64230. The error messages that you are getting are
remarkably similar to the original report for this PR.
In the case of PR62044, the fix only applies to allocation with MOLD = derived
type. class_allocate_18.f90 involves a CLASS entity and does not use MOLD =
anything.
I will investigate if there is not some horrible kludge that is spoofing up the
allocate expression in class_allocate_18.f90 by passing the typespec through a
hidden MOLD expression. If this is not the case, there is nothing that I can
do.
I'll come back to you in about twenty minutes. I have put Janus in copy.
Cheers
Paul
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug rtl-optimization/64921] [4.9/5 Regression] FAIL: gfortran.dg/class_allocate_18.f90
2015-02-03 15:42 [Bug rtl-optimization/64921] New: [5 Regression] FAIL: gfortran.dg/class_allocate_18.f90 with -fPIC hjl.tools at gmail dot com
` (5 preceding siblings ...)
2015-02-04 18:21 ` pault at gcc dot gnu.org
@ 2015-02-04 18:31 ` hjl.tools at gmail dot com
2015-02-04 19:00 ` dominiq at lps dot ens.fr
` (21 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: hjl.tools at gmail dot com @ 2015-02-04 18:31 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64921
--- Comment #7 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Paul Thomas from comment #6)
> (In reply to H.J. Lu from comment #2)
> > I got
> >
> > Program received signal SIGSEGV: Segmentation fault - invalid memory
> > reference.
> >
> > Backtrace for this error:
> > #0 0xF763FACE
> > #1 0xF763EBDE
> > #2 0xF773CBBF
> > #3 0x8048BA5 in __final_main_T2.3337 at class_allocate_18.f90:?
> > #4 0x8048D68 in __final_main_T3.3328 at class_allocate_18.f90:?
> > #5 0x8048A59 in MAIN__ at class_allocate_18.f90:?
> > FAIL: gfortran.dg/class_allocate_18.f90 -O1 execution test
> >
> > But I couldn't reproduce it on another machine. I will keep an eye on it.
>
> Hi HJ,
>
> Given that the error is sporadic, are you sure that the offending revisions
> are not 220125 and 220130 - PR64230. The error messages that you are getting
> are remarkably similar to the original report for this PR.
>
I don't know for sure. This failure seems more consistent on 4.9 branch
than on trunk.
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug rtl-optimization/64921] [4.9/5 Regression] FAIL: gfortran.dg/class_allocate_18.f90
2015-02-03 15:42 [Bug rtl-optimization/64921] New: [5 Regression] FAIL: gfortran.dg/class_allocate_18.f90 with -fPIC hjl.tools at gmail dot com
` (6 preceding siblings ...)
2015-02-04 18:31 ` hjl.tools at gmail dot com
@ 2015-02-04 19:00 ` dominiq at lps dot ens.fr
2015-02-04 19:03 ` dominiq at lps dot ens.fr
` (20 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: dominiq at lps dot ens.fr @ 2015-02-04 19:00 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64921
--- Comment #9 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> If I have understood correctly, -fPIC is not supported on x86_64 and so,
> unless I am mistaken, I cannot help you further.
This is not how I understand comment 1.
Note that if I compile with -fsanitize=address, the executable crashes with
allocated!
=================================================================
==73209==ERROR: AddressSanitizer: heap-buffer-overflow on address
0x60200000e040 at pc 0x000103b59dbd bp 0x7fff5c0a6fa0 sp 0x7fff5c0a6f98
READ of size 8 at 0x60200000e040 thread T0
#0 0x103b59dbc
(/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x100001dbc)
#1 0x103b595aa
(/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x1000015aa)
#2 0x103b59889
(/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x100001889)
#3 0x103b5a7a6
(/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x1000027a6)
#4 0x7fff8fd1e5c8 (/usr/lib/system/libdyld.dylib+0x35c8)
#5 0x0 (<unknown module>)
0x60200000e040 is located 0 bytes to the right of 16-byte region
[0x60200000e030,0x60200000e040)
allocated by thread T0 here:
#0 0x103b8d1fa (/opt/gcc/gcc4.10w/lib/libasan.2.dylib+0x2f1fa)
#1 0x103b59642
(/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x100001642)
#2 0x103b5a7a6
(/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x1000027a6)
#3 0x7fff8fd1e5c8 (/usr/lib/system/libdyld.dylib+0x35c8)
#4 0x0 (<unknown module>)
SUMMARY: AddressSanitizer: heap-buffer-overflow ??:0 ??
Shadow bytes around the buggy address:
0x1c0400001bb0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x1c0400001bc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x1c0400001bd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x1c0400001be0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x1c0400001bf0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa 01 fa
=>0x1c0400001c00: fa fa 00 fa fa fa 00 00[fa]fa 07 fa fa fa 07 fa
0x1c0400001c10: fa fa 06 fa fa fa 00 06 fa fa 00 00 fa fa 03 fa
0x1c0400001c20: fa fa 00 06 fa fa 00 07 fa fa 00 fa fa fa 00 00
0x1c0400001c30: fa fa 00 00 fa fa 00 00 fa fa 00 00 fa fa 00 00
0x1c0400001c40: fa fa 00 00 fa fa 00 00 fa fa 00 00 fa fa 00 00
0x1c0400001c50: fa fa 00 00 fa fa 00 00 fa fa 00 00 fa fa 00 00
I see this for r220302, r220156, r220109, and r219830 (i.e., all the revisions
I have tested).
Note that Janus has removed the -fsanitize=undefined option at r220181, while
it worked for me provided I ran the test after install.
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug rtl-optimization/64921] [4.9/5 Regression] FAIL: gfortran.dg/class_allocate_18.f90
2015-02-03 15:42 [Bug rtl-optimization/64921] New: [5 Regression] FAIL: gfortran.dg/class_allocate_18.f90 with -fPIC hjl.tools at gmail dot com
` (7 preceding siblings ...)
2015-02-04 19:00 ` dominiq at lps dot ens.fr
@ 2015-02-04 19:03 ` dominiq at lps dot ens.fr
2015-02-09 0:07 ` pinskia at gcc dot gnu.org
` (19 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: dominiq at lps dot ens.fr @ 2015-02-04 19:03 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64921
--- Comment #10 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
This is probably a duplicate of pr64849.
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug rtl-optimization/64921] [4.9/5 Regression] FAIL: gfortran.dg/class_allocate_18.f90
2015-02-03 15:42 [Bug rtl-optimization/64921] New: [5 Regression] FAIL: gfortran.dg/class_allocate_18.f90 with -fPIC hjl.tools at gmail dot com
` (8 preceding siblings ...)
2015-02-04 19:03 ` dominiq at lps dot ens.fr
@ 2015-02-09 0:07 ` pinskia at gcc dot gnu.org
2015-02-09 10:00 ` rguenth at gcc dot gnu.org
` (18 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: pinskia at gcc dot gnu.org @ 2015-02-09 0:07 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64921
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |5.0
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug rtl-optimization/64921] [4.9/5 Regression] FAIL: gfortran.dg/class_allocate_18.f90
2015-02-03 15:42 [Bug rtl-optimization/64921] New: [5 Regression] FAIL: gfortran.dg/class_allocate_18.f90 with -fPIC hjl.tools at gmail dot com
` (9 preceding siblings ...)
2015-02-09 0:07 ` pinskia at gcc dot gnu.org
@ 2015-02-09 10:00 ` rguenth at gcc dot gnu.org
2015-02-09 14:26 ` rguenth at gcc dot gnu.org
` (17 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: rguenth at gcc dot gnu.org @ 2015-02-09 10:00 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64921
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|5.0 |4.9.3
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug rtl-optimization/64921] [4.9/5 Regression] FAIL: gfortran.dg/class_allocate_18.f90
2015-02-03 15:42 [Bug rtl-optimization/64921] New: [5 Regression] FAIL: gfortran.dg/class_allocate_18.f90 with -fPIC hjl.tools at gmail dot com
` (10 preceding siblings ...)
2015-02-09 10:00 ` rguenth at gcc dot gnu.org
@ 2015-02-09 14:26 ` rguenth at gcc dot gnu.org
2015-02-16 13:40 ` dominiq at lps dot ens.fr
` (16 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: rguenth at gcc dot gnu.org @ 2015-02-09 14:26 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64921
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P3 |P4
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug rtl-optimization/64921] [4.9/5 Regression] FAIL: gfortran.dg/class_allocate_18.f90
2015-02-03 15:42 [Bug rtl-optimization/64921] New: [5 Regression] FAIL: gfortran.dg/class_allocate_18.f90 with -fPIC hjl.tools at gmail dot com
` (11 preceding siblings ...)
2015-02-09 14:26 ` rguenth at gcc dot gnu.org
@ 2015-02-16 13:40 ` dominiq at lps dot ens.fr
2015-02-16 13:48 ` [Bug fortran/64921] " dominiq at lps dot ens.fr
` (15 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: dominiq at lps dot ens.fr @ 2015-02-16 13:40 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64921
Dominique d'Humieres <dominiq at lps dot ens.fr> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |danglin at gcc dot gnu.org
--- Comment #11 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
*** Bug 64849 has been marked as a duplicate of this bug. ***
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug fortran/64921] [4.9/5 Regression] FAIL: gfortran.dg/class_allocate_18.f90
2015-02-03 15:42 [Bug rtl-optimization/64921] New: [5 Regression] FAIL: gfortran.dg/class_allocate_18.f90 with -fPIC hjl.tools at gmail dot com
` (12 preceding siblings ...)
2015-02-16 13:40 ` dominiq at lps dot ens.fr
@ 2015-02-16 13:48 ` dominiq at lps dot ens.fr
2015-04-27 12:26 ` [Bug fortran/64921] [4.9/5/6 " mathewc at nag dot co.uk
` (14 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: dominiq at lps dot ens.fr @ 2015-02-16 13:48 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64921
Dominique d'Humieres <dominiq at lps dot ens.fr> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2015-02-16
Component|rtl-optimization |fortran
Ever confirmed|0 |1
--- Comment #12 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
If I comment the line
Deallocate (t)
the test compiled with -fsanitize=address runs without error. This is also the
case for the following variant
Program main
Implicit None
Type :: t1
End Type
Type, Extends (t1) :: t2
Integer, Allocatable :: i
End Type
Type, Extends (t2) :: t3
Integer, Allocatable :: j
End Type
Class (t1), Allocatable :: t
Allocate (t3 :: t)
if (allocated(t)) then
print *,"allocated!"
select type (t)
type is (t1)
print *, "type is t1"
type is (t2)
print *, "type is t2"
type is (t3)
print *, "type is t3"
t%i = 42
t%j = 99
print *, t%i, t%j
Deallocate (t%i, t%j)
end select
! deallocate (t)
else
call abort ()
end if
End
which outputs at run time
allocated!
type is t3
42 99
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug fortran/64921] [4.9/5/6 Regression] FAIL: gfortran.dg/class_allocate_18.f90
2015-02-03 15:42 [Bug rtl-optimization/64921] New: [5 Regression] FAIL: gfortran.dg/class_allocate_18.f90 with -fPIC hjl.tools at gmail dot com
` (13 preceding siblings ...)
2015-02-16 13:48 ` [Bug fortran/64921] " dominiq at lps dot ens.fr
@ 2015-04-27 12:26 ` mathewc at nag dot co.uk
2015-06-26 20:04 ` jakub at gcc dot gnu.org
` (13 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: mathewc at nag dot co.uk @ 2015-04-27 12:26 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64921
--- Comment #14 from Mat Cross <mathewc at nag dot co.uk> ---
For the record, perhaps it is of interest for me to note that we are running
into this (cf. PR64230 comment 9) on code like
Program test
Implicit None
Type :: t1
Integer, Allocatable :: i
End Type
Type :: t2
Integer, Allocatable :: i
End Type
Type, Extends (t1) :: t3
Type (t2) :: j
End Type
Type, Extends (t3) :: t4
Integer, Allocatable :: k
End Type
Call s
Print *, 'ok'
Contains
Subroutine s
Class (t1), Allocatable :: x
Allocate (t4 :: x)
End Subroutine
End Program
Since the crash is in bad compiler-generated finalization code (since 4.9), and
given that (if I recall correctly) gfortran is using the Fortran 2008 semantics
for entities declared in a main program being implicitly saved, this is why
removing the Deallocate (in the comment 12 example) works - the finalizer is
never called then.
In the interim, does anyone have any bright ideas for a reasonable (few-line)
workaround?
Thanks.
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug fortran/64921] [4.9/5/6 Regression] FAIL: gfortran.dg/class_allocate_18.f90
2015-02-03 15:42 [Bug rtl-optimization/64921] New: [5 Regression] FAIL: gfortran.dg/class_allocate_18.f90 with -fPIC hjl.tools at gmail dot com
` (14 preceding siblings ...)
2015-04-27 12:26 ` [Bug fortran/64921] [4.9/5/6 " mathewc at nag dot co.uk
@ 2015-06-26 20:04 ` jakub at gcc dot gnu.org
2015-06-26 20:34 ` jakub at gcc dot gnu.org
` (12 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: jakub at gcc dot gnu.org @ 2015-06-26 20:04 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64921
--- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.9.3 has been released.
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug fortran/64921] [4.9/5/6 Regression] FAIL: gfortran.dg/class_allocate_18.f90
2015-02-03 15:42 [Bug rtl-optimization/64921] New: [5 Regression] FAIL: gfortran.dg/class_allocate_18.f90 with -fPIC hjl.tools at gmail dot com
` (15 preceding siblings ...)
2015-06-26 20:04 ` jakub at gcc dot gnu.org
@ 2015-06-26 20:34 ` jakub at gcc dot gnu.org
2015-07-07 15:29 ` ktkachov at gcc dot gnu.org
` (11 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: jakub at gcc dot gnu.org @ 2015-06-26 20:34 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64921
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|4.9.3 |4.9.4
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug fortran/64921] [4.9/5/6 Regression] FAIL: gfortran.dg/class_allocate_18.f90
2015-02-03 15:42 [Bug rtl-optimization/64921] New: [5 Regression] FAIL: gfortran.dg/class_allocate_18.f90 with -fPIC hjl.tools at gmail dot com
` (16 preceding siblings ...)
2015-06-26 20:34 ` jakub at gcc dot gnu.org
@ 2015-07-07 15:29 ` ktkachov at gcc dot gnu.org
2015-07-25 13:31 ` ubizjak at gmail dot com
` (10 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: ktkachov at gcc dot gnu.org @ 2015-07-07 15:29 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64921
ktkachov at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ktkachov at gcc dot gnu.org
--- Comment #16 from ktkachov at gcc dot gnu.org ---
I see this execution fail on aarch64-linux-gnu and arm-none-linux-gnueabihf on
the GCC 5 branch
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug fortran/64921] [4.9/5/6 Regression] FAIL: gfortran.dg/class_allocate_18.f90
2015-02-03 15:42 [Bug rtl-optimization/64921] New: [5 Regression] FAIL: gfortran.dg/class_allocate_18.f90 with -fPIC hjl.tools at gmail dot com
` (17 preceding siblings ...)
2015-07-07 15:29 ` ktkachov at gcc dot gnu.org
@ 2015-07-25 13:31 ` ubizjak at gmail dot com
2015-07-25 15:13 ` ubizjak at gmail dot com
` (9 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: ubizjak at gmail dot com @ 2015-07-25 13:31 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64921
--- Comment #17 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Mat Cross from comment #14)
> For the record, perhaps it is of interest for me to note that we are running
> into this (cf. PR64230 comment 9) on code like
>
> Program test
> Implicit None
> Type :: t1
> Integer, Allocatable :: i
> End Type
> Type :: t2
> Integer, Allocatable :: i
> End Type
> Type, Extends (t1) :: t3
> Type (t2) :: j
> End Type
> Type, Extends (t3) :: t4
> Integer, Allocatable :: k
> End Type
> Call s
> Print *, 'ok'
> Contains
> Subroutine s
> Class (t1), Allocatable :: x
> Allocate (t4 :: x)
> End Subroutine
> End Program
>
> Since the crash is in bad compiler-generated finalization code (since 4.9),
> and given that (if I recall correctly) gfortran is using the Fortran 2008
> semantics for entities declared in a main program being implicitly saved,
> this is why removing the Deallocate (in the comment 12 example) works - the
> finalizer is never called then.
No wonder this test crashes. Tree-optimizers (-O2) on x86_64 produce:
--cut here--
test ()
{
integer(kind=8)[0:D.4089] * restrict sizes;
integer(kind=8)[0:D.4068] * restrict sizes;
void * _13;
integer(kind=4) * _63;
integer(kind=4) * _121;
<bb 2>:
_13 = __builtin_malloc (24);
if (_13 == 0B)
goto <bb 3>;
else
goto <bb 4>;
<bb 3>:
_gfortran_os_error (&"Allocation would exceed memory limit"[1]{lb: 1 sz: 1});
<bb 4>:
MEM[(c_char * {ref-all})_13] = MEM[(c_char * {ref-all})&__def_init_test_T4];
sizes_22 = __builtin_malloc (8);
MEM[(integer(kind=8)[0:D.3483] *)sizes_22][0] = 1;
_63 = MEM[(struct t4 *)_13].k;
if (_63 == 0B)
goto <bb 6>;
else
goto <bb 5>;
<bb 5>:
__builtin_free (_63);
<bb 6>:
sizes_79 = __builtin_malloc (8);
_121 ={v} MEM[(struct t3 *)0B].j.i;
__builtin_trap ();
}
--cut here--
The <bb 6>: part reads from address 0x0+, and if this doesn't crash, trap insn
surely crashes program.
>From gcc-bugs-return-493320-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Jul 25 14:07:55 2015
Return-Path: <gcc-bugs-return-493320-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 2295 invoked by alias); 25 Jul 2015 14:07:54 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 1909 invoked by uid 55); 25 Jul 2015 14:07:49 -0000
From: "olegendo at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/66930] [5 Regression]: gengtype.c is miscompiled during stage2
Date: Sat, 25 Jul 2015 14:07:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 5.2.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: olegendo at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.3
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-66930-4-R7bXVPZqCA@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66930-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66930-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-07/txt/msg02210.txt.bz2
Content-length: 469
https://gcc.gnu.org/bugzilla/show_bug.cgi?idf930
--- Comment #17 from Oleg Endo <olegendo at gcc dot gnu.org> ---
Author: olegendo
Date: Sat Jul 25 14:07:17 2015
New Revision: 226218
URL: https://gcc.gnu.org/viewcvs?rev"6218&root=gcc&view=rev
Log:
gcc/
PR target/66930
* config/sh/sh.c (sh_split_movrt_negc_to_movt_xor): Add missing
T bit register modified_between_p check.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sh/sh.c
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug fortran/64921] [4.9/5/6 Regression] FAIL: gfortran.dg/class_allocate_18.f90
2015-02-03 15:42 [Bug rtl-optimization/64921] New: [5 Regression] FAIL: gfortran.dg/class_allocate_18.f90 with -fPIC hjl.tools at gmail dot com
` (18 preceding siblings ...)
2015-07-25 13:31 ` ubizjak at gmail dot com
@ 2015-07-25 15:13 ` ubizjak at gmail dot com
2015-07-27 7:57 ` rguenth at gcc dot gnu.org
` (8 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: ubizjak at gmail dot com @ 2015-07-25 15:13 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64921
Uroš Bizjak <ubizjak at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rguenther at suse dot de
--- Comment #18 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Uroš Bizjak from comment #17)
> (In reply to Mat Cross from comment #14)
> > For the record, perhaps it is of interest for me to note that we are running
> > into this (cf. PR64230 comment 9) on code like
> >
> > Program test
> > Implicit None
> > Type :: t1
> > Integer, Allocatable :: i
> > End Type
> > Type :: t2
> > Integer, Allocatable :: i
> > End Type
> > Type, Extends (t1) :: t3
> > Type (t2) :: j
> > End Type
> > Type, Extends (t3) :: t4
> > Integer, Allocatable :: k
> > End Type
> > Call s
> > Print *, 'ok'
> > Contains
> > Subroutine s
> > Class (t1), Allocatable :: x
> > Allocate (t4 :: x)
> > End Subroutine
> > End Program
> >
> > Since the crash is in bad compiler-generated finalization code (since 4.9),
> > and given that (if I recall correctly) gfortran is using the Fortran 2008
> > semantics for entities declared in a main program being implicitly saved,
> > this is why removing the Deallocate (in the comment 12 example) works - the
> > finalizer is never called then.
>
> No wonder this test crashes. Tree-optimizers (-O2) on x86_64 produce:
[...]
I was able to trace dumps down to _.fre2 tree dump, where we have:
<bb 12>:
# idx_104 = PHI <0(11), idx_122(16)>
offset_115 = 0;
ptr2_119 = (struct t3 *) offset_115;
_120 = &ptr2_119->j;
This can't be right, we have a dereference from zero. If the frontend produced
correct code, then tree-optimization passes made a mess here.
CC Richi.
>From gcc-bugs-return-493325-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Jul 25 16:37:08 2015
Return-Path: <gcc-bugs-return-493325-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 84813 invoked by alias); 25 Jul 2015 16:37:07 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 84750 invoked by uid 48); 25 Jul 2015 16:37:01 -0000
From: "Casey at Carter dot net" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/67007] New: [c++-concepts] Deduction constraint
Date: Sat, 25 Jul 2015 16:37:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: c++-concepts
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: Casey at Carter dot net
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone
Message-ID: <bug-67007-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-07/txt/msg02215.txt.bz2
Content-length: 2742
https://gcc.gnu.org/bugzilla/show_bug.cgi?idg007
Bug ID: 67007
Summary: [c++-concepts] Deduction constraint
Product: gcc
Version: c++-concepts
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Casey at Carter dot net
Target Milestone: ---
r226205 ICEs compiling this program:
template <class U>
concept bool A requires (U u) { u; };
template <class T>
concept bool B requires (T t) { { t } -> A; };
void foo(B);
apparently while normalizing the constraints of B:
~/concept-gcc/bin/g++ -std=c++1z foo.cpp -c
foo.cpp:9:11: internal compiler error: in tsubst_constraint, at
cp/constraint.cc:1511
void foo(B);
^
0x8032b1 tsubst_constraint(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/constraint.cc:1511
0x65794f tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.c:12798
0x806bf0 tsubst_compound_requirement
../../gcc/cp/constraint.cc:1604
0x806bf0 tsubst_requirement
../../gcc/cp/constraint.cc:1632
0x806bf0 tsubst_requirement_body
../../gcc/cp/constraint.cc:1651
0x806bf0 tsubst_requires_expr(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/constraint.cc:1682
0x65103a tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/cp/pt.c:16429
0x64462e tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:15092
0x80591f lift_variable_initializer
../../gcc/cp/constraint.cc:440
0x805220 normalize_predicate_constraint
../../gcc/cp/constraint.cc:955
0x805220 normalize_constraint
../../gcc/cp/constraint.cc:993
0x805508 build_constraints(tree_node*, tree_node*)
../../gcc/cp/constraint.cc:1096
0x5af175 grokfndecl
../../gcc/cp/decl.c:7788
0x6208f6 grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
decl_context, int, tree_node**)
../../gcc/cp/decl.c:11202
0x621126 start_decl(cp_declarator const*, cp_decl_specifier_seq*, int,
tree_node*, tree_node*, tree_node**)
../../gcc/cp/decl.c:4744
0x710580 cp_parser_init_declarator
../../gcc/cp/parser.c:17728
0x71336d cp_parser_simple_declaration
../../gcc/cp/parser.c:11685
0x70c8f4 cp_parser_block_declaration
../../gcc/cp/parser.c:11559
0x718783 cp_parser_declaration
../../gcc/cp/parser.c:11456
0x716f5a cp_parser_declaration_seq_opt
../../gcc/cp/parser.c:11338
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug fortran/64921] [4.9/5/6 Regression] FAIL: gfortran.dg/class_allocate_18.f90
2015-02-03 15:42 [Bug rtl-optimization/64921] New: [5 Regression] FAIL: gfortran.dg/class_allocate_18.f90 with -fPIC hjl.tools at gmail dot com
` (19 preceding siblings ...)
2015-07-25 15:13 ` ubizjak at gmail dot com
@ 2015-07-27 7:57 ` rguenth at gcc dot gnu.org
2015-07-27 18:45 ` mikael at gcc dot gnu.org
` (7 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: rguenth at gcc dot gnu.org @ 2015-07-27 7:57 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64921
--- Comment #19 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Uroš Bizjak from comment #18)
> (In reply to Uroš Bizjak from comment #17)
> > (In reply to Mat Cross from comment #14)
> > > For the record, perhaps it is of interest for me to note that we are running
> > > into this (cf. PR64230 comment 9) on code like
> > >
> > > Program test
> > > Implicit None
> > > Type :: t1
> > > Integer, Allocatable :: i
> > > End Type
> > > Type :: t2
> > > Integer, Allocatable :: i
> > > End Type
> > > Type, Extends (t1) :: t3
> > > Type (t2) :: j
> > > End Type
> > > Type, Extends (t3) :: t4
> > > Integer, Allocatable :: k
> > > End Type
> > > Call s
> > > Print *, 'ok'
> > > Contains
> > > Subroutine s
> > > Class (t1), Allocatable :: x
> > > Allocate (t4 :: x)
> > > End Subroutine
> > > End Program
> > >
> > > Since the crash is in bad compiler-generated finalization code (since 4.9),
> > > and given that (if I recall correctly) gfortran is using the Fortran 2008
> > > semantics for entities declared in a main program being implicitly saved,
> > > this is why removing the Deallocate (in the comment 12 example) works - the
> > > finalizer is never called then.
> >
> > No wonder this test crashes. Tree-optimizers (-O2) on x86_64 produce:
>
> [...]
>
> I was able to trace dumps down to _.fre2 tree dump, where we have:
>
> <bb 12>:
> # idx_104 = PHI <0(11), idx_122(16)>
> offset_115 = 0;
> ptr2_119 = (struct t3 *) offset_115;
> _120 = &ptr2_119->j;
This isn't a dereference, it's just an address computation. Iff j
is not at offset zero then of course...
if (_120 != 0B)
goto <bb 19>;
else
goto <bb 22>;
<bb 19>:
_121 = ptr2_119->j.i;
we'll crash right here.
So the question is whether the frontend emits the correct test against zero:
offset = offset * byte_stride;
D.3466 = (void *) array->data;
D.3467 = D.3466;
D.3465 = 8;
D.3469 = 8;
__builtin_memcpy ((void *) &transfer.4, (void *) &D.3467,
(unsigned long) MAX_EXPR <MIN_EXPR <D.3469, D.3465>, 0>);
ptr2 = (struct t4 *) (transfer.4 + offset);
if (ptr2 != 0B)
{
{
integer(kind=4) stat.5;
if (ptr2->k == 0B)
to me it looks like if we really want to test transfer.4 (array->data) against
zero. We do
0x0000000000400b26 <+502>: cmp $0xfffffffffffffff8,%r15
0x0000000000400b2a <+506>: je 0x400b42 <test+530>
=> 0x0000000000400b2c <+508>: mov 0x8(%r15),%rdi
and %r15 is zero, so offset is _not_ zero here (but ends up constant
propagated and we "optimize" the compare - offset seems to be 8).
> This can't be right, we have a dereference from zero. If the frontend
> produced correct code, then tree-optimization passes made a mess here.
>
> CC Richi.
>From gcc-bugs-return-493428-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jul 27 08:03:54 2015
Return-Path: <gcc-bugs-return-493428-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 128002 invoked by alias); 27 Jul 2015 08:03:54 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 127956 invoked by uid 48); 27 Jul 2015 08:03:50 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/65974] [5/6 Regression] Bogus deprecated-declarations warnings for inline definitions of deprecated virtual methods
Date: Mon, 27 Jul 2015 08:03:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 5.1.1
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.3
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status cf_known_to_work keywords cf_reconfirmed_on cc everconfirmed short_desc target_milestone cf_known_to_fail
Message-ID: <bug-65974-4-7uibWlaN6g@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65974-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65974-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-07/txt/msg02318.txt.bz2
Content-length: 1148
https://gcc.gnu.org/bugzilla/show_bug.cgi?ide974
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Known to work| |4.9.3
Keywords| |diagnostic
Last reconfirmed| |2015-07-27
CC| |rguenth at gcc dot gnu.org
Ever confirmed|0 |1
Summary|Bogus |[5/6 Regression] Bogus
|deprecated-declarations |deprecated-declarations
|warnings for inline |warnings for inline
|definitions of deprecated |definitions of deprecated
|virtual methods |virtual methods
Target Milestone|--- |5.3
Known to fail| |5.1.0, 5.2.0, 6.0
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed.
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug fortran/64921] [4.9/5/6 Regression] FAIL: gfortran.dg/class_allocate_18.f90
2015-02-03 15:42 [Bug rtl-optimization/64921] New: [5 Regression] FAIL: gfortran.dg/class_allocate_18.f90 with -fPIC hjl.tools at gmail dot com
` (20 preceding siblings ...)
2015-07-27 7:57 ` rguenth at gcc dot gnu.org
@ 2015-07-27 18:45 ` mikael at gcc dot gnu.org
2015-07-27 19:44 ` rguenther at suse dot de
` (6 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: mikael at gcc dot gnu.org @ 2015-07-27 18:45 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64921
Mikael Morin <mikael at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mikael at gcc dot gnu.org
--- Comment #20 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #19)
> So the question is whether the frontend emits the correct test against zero:
>
> offset = offset * byte_stride;
> D.3466 = (void *) array->data;
> D.3467 = D.3466;
> D.3465 = 8;
> D.3469 = 8;
> __builtin_memcpy ((void *) &transfer.4, (void *)
> &D.3467, (unsigned long) MAX_EXPR <MIN_EXPR <D.3469, D.3465>, 0>);
> ptr2 = (struct t4 *) (transfer.4 + offset);
> if (ptr2 != 0B)
> {
> {
> integer(kind=4) stat.5;
>
> if (ptr2->k == 0B)
>
> to me it looks like if we really want to test transfer.4 (array->data)
> against
> zero.
transfer.4 + offset calculates the address of an element of an array.
I believe that if that code is executed, array.data is non-zero, and of course
array.data + offset as well.
I think the the test should check for ptr2%j's nullness before deallocating
ptr2%j, instead of testing ptr2.
With a patch like this:
diff --git a/gcc/fortran/class.c b/gcc/fortran/class.c
index 218973d..1ff7437 100644
--- a/gcc/fortran/class.c
+++ b/gcc/fortran/class.c
@@ -967,7 +967,7 @@ finalize_component (gfc_expr *expr, gfc_symbol *derived,
gfc_component *comp,
cond->block->expr1->ts.kind = gfc_default_logical_kind;
cond->block->expr1->value.function.isym = gfc_intrinsic_function_by_id
(GFC_ISYM_ASSOCIATED);
cond->block->expr1->value.function.actual = gfc_get_actual_arglist ();
- cond->block->expr1->value.function.actual->expr = gfc_copy_expr (expr);
+ cond->block->expr1->value.function.actual->expr = gfc_copy_expr (e);
cond->block->expr1->value.function.actual->next = gfc_get_actual_arglist
();
cond->block->next = dealloc;
Unfortunately, it doesn't seem to fix the problem.
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug fortran/64921] [4.9/5/6 Regression] FAIL: gfortran.dg/class_allocate_18.f90
2015-02-03 15:42 [Bug rtl-optimization/64921] New: [5 Regression] FAIL: gfortran.dg/class_allocate_18.f90 with -fPIC hjl.tools at gmail dot com
` (21 preceding siblings ...)
2015-07-27 18:45 ` mikael at gcc dot gnu.org
@ 2015-07-27 19:44 ` rguenther at suse dot de
2015-07-28 12:07 ` mikael at gcc dot gnu.org
` (5 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: rguenther at suse dot de @ 2015-07-27 19:44 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64921
--- Comment #21 from rguenther at suse dot de <rguenther at suse dot de> ---
On July 27, 2015 8:45:41 PM GMT+02:00, "mikael at gcc dot gnu.org"
<gcc-bugzilla@gcc.gnu.org> wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64921
>
>Mikael Morin <mikael at gcc dot gnu.org> changed:
>
> What |Removed |Added
>----------------------------------------------------------------------------
> CC| |mikael at gcc dot gnu.org
>
>--- Comment #20 from Mikael Morin <mikael at gcc dot gnu.org> ---
>(In reply to Richard Biener from comment #19)
>> So the question is whether the frontend emits the correct test
>against zero:
>>
>> offset = offset * byte_stride;
>> D.3466 = (void *) array->data;
>> D.3467 = D.3466;
>> D.3465 = 8;
>> D.3469 = 8;
>> __builtin_memcpy ((void *) &transfer.4, (void *)
>> &D.3467, (unsigned long) MAX_EXPR <MIN_EXPR <D.3469, D.3465>, 0>);
>> ptr2 = (struct t4 *) (transfer.4 + offset);
>> if (ptr2 != 0B)
>> {
>> {
>> integer(kind=4) stat.5;
>>
>> if (ptr2->k == 0B)
>>
>> to me it looks like if we really want to test transfer.4
>(array->data)
>> against
>> zero.
>
>transfer.4 + offset calculates the address of an element of an array.
>I believe that if that code is executed, array.data is non-zero, and
>of course
>array.data + offset as well.
Yes but if transfer.4 is null then transfer.4 + offset does not have to be.
Transfer.4 _is_ null in the case we segfault. So the guard us clearly wrong.
>I think the the test should check for ptr2%j's nullness before
>deallocating
>ptr2%j, instead of testing ptr2.
>
>With a patch like this:
>
>diff --git a/gcc/fortran/class.c b/gcc/fortran/class.c
>index 218973d..1ff7437 100644
>--- a/gcc/fortran/class.c
>+++ b/gcc/fortran/class.c
>@@ -967,7 +967,7 @@ finalize_component (gfc_expr *expr, gfc_symbol
>*derived,
>gfc_component *comp,
> cond->block->expr1->ts.kind = gfc_default_logical_kind;
> cond->block->expr1->value.function.isym = gfc_intrinsic_function_by_id
>(GFC_ISYM_ASSOCIATED);
> cond->block->expr1->value.function.actual = gfc_get_actual_arglist ();
>- cond->block->expr1->value.function.actual->expr = gfc_copy_expr
>(expr);
>+ cond->block->expr1->value.function.actual->expr = gfc_copy_expr
>(e);
>cond->block->expr1->value.function.actual->next =
>gfc_get_actual_arglist
>();
> cond->block->next = dealloc;
>
>
>Unfortunately, it doesn't seem to fix the problem.
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug fortran/64921] [4.9/5/6 Regression] FAIL: gfortran.dg/class_allocate_18.f90
2015-02-03 15:42 [Bug rtl-optimization/64921] New: [5 Regression] FAIL: gfortran.dg/class_allocate_18.f90 with -fPIC hjl.tools at gmail dot com
` (22 preceding siblings ...)
2015-07-27 19:44 ` rguenther at suse dot de
@ 2015-07-28 12:07 ` mikael at gcc dot gnu.org
2015-07-28 12:31 ` rguenther at suse dot de
` (4 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: mikael at gcc dot gnu.org @ 2015-07-28 12:07 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64921
--- Comment #22 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to rguenther@suse.de from comment #21)
> Transfer.4 _is_ null in the case we segfault. So the guard us clearly wrong.
>
OK, let's try something else.
Are you positive transfer.4 is null?
I don't see anything that would make it so.
If it is transfer.10 that is null, I can see the call to __final_main_T2 that
is suspicious; it seems to pass a descriptorless array to an argument expecting
a descriptor.
Draft patch, seems to fix it
diff --git a/gcc/fortran/class.c b/gcc/fortran/class.c
index 218973d..7a9e275 100644
--- a/gcc/fortran/class.c
+++ b/gcc/fortran/class.c
@@ -1599,6 +1599,7 @@ generate_finalization_wrapper (gfc_symbol *derived,
gfc_namespace *ns,
final->ts.type = BT_INTEGER;
final->ts.kind = 4;
final->attr.artificial = 1;
+ final->attr.always_explicit = 1;
final->attr.if_source = expr_null_wrapper ? IFSRC_IFBODY : IFSRC_DECL;
if (ns->proc_name->attr.flavor == FL_MODULE)
final->module = ns->proc_name->name;
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug fortran/64921] [4.9/5/6 Regression] FAIL: gfortran.dg/class_allocate_18.f90
2015-02-03 15:42 [Bug rtl-optimization/64921] New: [5 Regression] FAIL: gfortran.dg/class_allocate_18.f90 with -fPIC hjl.tools at gmail dot com
` (23 preceding siblings ...)
2015-07-28 12:07 ` mikael at gcc dot gnu.org
@ 2015-07-28 12:31 ` rguenther at suse dot de
2015-07-28 12:43 ` ubizjak at gmail dot com
` (3 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: rguenther at suse dot de @ 2015-07-28 12:31 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64921
--- Comment #23 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 28 Jul 2015, mikael at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64921
>
> --- Comment #22 from Mikael Morin <mikael at gcc dot gnu.org> ---
> (In reply to rguenther@suse.de from comment #21)
> > Transfer.4 _is_ null in the case we segfault. So the guard us clearly wrong.
> >
> OK, let's try something else.
> Are you positive transfer.4 is null?
> I don't see anything that would make it so.
>From inspecting registers and the assembly. The debugger cannot get
at the artificial decls.
> If it is transfer.10 that is null, I can see the call to __final_main_T2 that
> is suspicious; it seems to pass a descriptorless array to an argument expecting
> a descriptor.
>
> Draft patch, seems to fix it
>
> diff --git a/gcc/fortran/class.c b/gcc/fortran/class.c
> index 218973d..7a9e275 100644
> --- a/gcc/fortran/class.c
> +++ b/gcc/fortran/class.c
> @@ -1599,6 +1599,7 @@ generate_finalization_wrapper (gfc_symbol *derived,
> gfc_namespace *ns,
> final->ts.type = BT_INTEGER;
> final->ts.kind = 4;
> final->attr.artificial = 1;
> + final->attr.always_explicit = 1;
> final->attr.if_source = expr_null_wrapper ? IFSRC_IFBODY : IFSRC_DECL;
> if (ns->proc_name->attr.flavor == FL_MODULE)
> final->module = ns->proc_name->name;
even better
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug fortran/64921] [4.9/5/6 Regression] FAIL: gfortran.dg/class_allocate_18.f90
2015-02-03 15:42 [Bug rtl-optimization/64921] New: [5 Regression] FAIL: gfortran.dg/class_allocate_18.f90 with -fPIC hjl.tools at gmail dot com
` (24 preceding siblings ...)
2015-07-28 12:31 ` rguenther at suse dot de
@ 2015-07-28 12:43 ` ubizjak at gmail dot com
2015-08-05 15:42 ` mikael at gcc dot gnu.org
` (2 subsequent siblings)
28 siblings, 0 replies; 30+ messages in thread
From: ubizjak at gmail dot com @ 2015-07-28 12:43 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64921
--- Comment #24 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Mikael Morin from comment #22)
> (In reply to rguenther@suse.de from comment #21)
> > Transfer.4 _is_ null in the case we segfault. So the guard us clearly wrong.
> >
> OK, let's try something else.
> Are you positive transfer.4 is null?
> I don't see anything that would make it so.
I can confirm that this patch fixes "Invalid read of size 8" valgrind memory
error for gfortran.dg/class_allocate_18.f90.
>From gcc-bugs-return-493558-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jul 28 13:17:49 2015
Return-Path: <gcc-bugs-return-493558-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 64661 invoked by alias); 28 Jul 2015 13:17:49 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 64598 invoked by uid 48); 28 Jul 2015 13:17:44 -0000
From: "anders.granlund.0 at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/67026] GCC incorrectly rejects well-formed constexpr function definition
Date: Tue, 28 Jul 2015 13:17:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: anders.granlund.0 at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-67026-4-raybog8UrS@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-67026-4@http.gcc.gnu.org/bugzilla/>
References: <bug-67026-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-07/txt/msg02448.txt.bz2
Content-length: 1697
https://gcc.gnu.org/bugzilla/show_bug.cgi?idg026
--- Comment #3 from Anders Granlund <anders.granlund.0 at gmail dot com> ---
(In reply to Andrew Pinski from comment #2)
> Actually wait. I think this is invalid and clang is incorrect in not
> rejecting it. Because you have a call to a non constexpr in a constexpr
> function; does not matter if it is after a return or not.
My program is valid. Just having a call expression with a non-constexpr
function inside the body of a constexpr function is not in it self a reason for
the program to be ill-formed.
The c++ standard is quite permissive about what a function body of a constexpr
function can contain, see [dcl.constexpr]p3
(http://eel.is/c++draft/dcl.constexpr#3).
The program would however be ill-formed with no diagnostics required, if the
constexpr function could never be called without calling the non-constexpr
function. For details, see [dcl.constexpr]p5
(http://eel.is/c++draft/dcl.constexpr#5).
Also the program wold be ill-formed, if the constexpr function needs to be
called when evaluating an expression that needs to be a constant expression,
and that call would result in a call to the non-constexpr function. For
details, see [expr.const]p2 (http://eel.is/c++draft/expr.const#2) (item 2 in
the list).
I choose the return type void to avoid having to return a value in f. The test
case works with int as return type also.
void g() {}
constexpr int f() { return 0; g(); }
int main() {}
Anyways GCC supports the return type void for constexpr functions. Also relaxed
requirements on constexpr functions have been implemented since version 5 of
GCC according to this:
https://gcc.gnu.org/projects/cxx1y.html
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug fortran/64921] [4.9/5/6 Regression] FAIL: gfortran.dg/class_allocate_18.f90
2015-02-03 15:42 [Bug rtl-optimization/64921] New: [5 Regression] FAIL: gfortran.dg/class_allocate_18.f90 with -fPIC hjl.tools at gmail dot com
` (25 preceding siblings ...)
2015-07-28 12:43 ` ubizjak at gmail dot com
@ 2015-08-05 15:42 ` mikael at gcc dot gnu.org
2015-08-05 16:42 ` mikael at gcc dot gnu.org
2015-08-05 17:04 ` mikael at gcc dot gnu.org
28 siblings, 0 replies; 30+ messages in thread
From: mikael at gcc dot gnu.org @ 2015-08-05 15:42 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64921
Mikael Morin <mikael at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |mikael at gcc dot gnu.org
--- Comment #26 from Mikael Morin <mikael at gcc dot gnu.org> ---
I'm preparing the backports.
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug fortran/64921] [4.9/5/6 Regression] FAIL: gfortran.dg/class_allocate_18.f90
2015-02-03 15:42 [Bug rtl-optimization/64921] New: [5 Regression] FAIL: gfortran.dg/class_allocate_18.f90 with -fPIC hjl.tools at gmail dot com
` (26 preceding siblings ...)
2015-08-05 15:42 ` mikael at gcc dot gnu.org
@ 2015-08-05 16:42 ` mikael at gcc dot gnu.org
2015-08-05 17:04 ` mikael at gcc dot gnu.org
28 siblings, 0 replies; 30+ messages in thread
From: mikael at gcc dot gnu.org @ 2015-08-05 16:42 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64921
--- Comment #28 from Mikael Morin <mikael at gcc dot gnu.org> ---
Author: mikael
Date: Wed Aug 5 16:42:00 2015
New Revision: 226639
URL: https://gcc.gnu.org/viewcvs?rev=226639&root=gcc&view=rev
Log:
Fix random class_allocate_18.f90 failure
PR fortran/64921
gcc/fortran/
* class.c (generate_finalization_wrapper): Set finalization
procedure symbol's always_explicit attribute.
gcc/testsuite/
* gfortran.dg/class_allocate_20.f90: New.
Added:
branches/gcc-4_9-branch/gcc/testsuite/gfortran.dg/class_allocate_20.f90
Modified:
branches/gcc-4_9-branch/gcc/fortran/ChangeLog
branches/gcc-4_9-branch/gcc/fortran/class.c
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
^ permalink raw reply [flat|nested] 30+ messages in thread
* [Bug fortran/64921] [4.9/5/6 Regression] FAIL: gfortran.dg/class_allocate_18.f90
2015-02-03 15:42 [Bug rtl-optimization/64921] New: [5 Regression] FAIL: gfortran.dg/class_allocate_18.f90 with -fPIC hjl.tools at gmail dot com
` (27 preceding siblings ...)
2015-08-05 16:42 ` mikael at gcc dot gnu.org
@ 2015-08-05 17:04 ` mikael at gcc dot gnu.org
28 siblings, 0 replies; 30+ messages in thread
From: mikael at gcc dot gnu.org @ 2015-08-05 17:04 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64921
Mikael Morin <mikael at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution|--- |FIXED
--- Comment #29 from Mikael Morin <mikael at gcc dot gnu.org> ---
Fixed for 6.0, 5.3 and 4.9.4, closing.
^ permalink raw reply [flat|nested] 30+ messages in thread
end of thread, other threads:[~2015-08-05 17:04 UTC | newest]
Thread overview: 30+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-02-03 15:42 [Bug rtl-optimization/64921] New: [5 Regression] FAIL: gfortran.dg/class_allocate_18.f90 with -fPIC hjl.tools at gmail dot com
2015-02-03 16:03 ` [Bug rtl-optimization/64921] " jakub at gcc dot gnu.org
2015-02-03 17:22 ` hjl.tools at gmail dot com
2015-02-03 17:32 ` [Bug rtl-optimization/64921] [4.9/5 Regression] FAIL: gfortran.dg/class_allocate_18.f90 hjl.tools at gmail dot com
2015-02-03 21:30 ` pault at gcc dot gnu.org
2015-02-04 3:00 ` ramana at gcc dot gnu.org
2015-02-04 18:21 ` pault at gcc dot gnu.org
2015-02-04 18:31 ` hjl.tools at gmail dot com
2015-02-04 19:00 ` dominiq at lps dot ens.fr
2015-02-04 19:03 ` dominiq at lps dot ens.fr
2015-02-09 0:07 ` pinskia at gcc dot gnu.org
2015-02-09 10:00 ` rguenth at gcc dot gnu.org
2015-02-09 14:26 ` rguenth at gcc dot gnu.org
2015-02-16 13:40 ` dominiq at lps dot ens.fr
2015-02-16 13:48 ` [Bug fortran/64921] " dominiq at lps dot ens.fr
2015-04-27 12:26 ` [Bug fortran/64921] [4.9/5/6 " mathewc at nag dot co.uk
2015-06-26 20:04 ` jakub at gcc dot gnu.org
2015-06-26 20:34 ` jakub at gcc dot gnu.org
2015-07-07 15:29 ` ktkachov at gcc dot gnu.org
2015-07-25 13:31 ` ubizjak at gmail dot com
2015-07-25 15:13 ` ubizjak at gmail dot com
2015-07-27 7:57 ` rguenth at gcc dot gnu.org
2015-07-27 18:45 ` mikael at gcc dot gnu.org
2015-07-27 19:44 ` rguenther at suse dot de
2015-07-28 12:07 ` mikael at gcc dot gnu.org
2015-07-28 12:31 ` rguenther at suse dot de
2015-07-28 12:43 ` ubizjak at gmail dot com
2015-08-05 15:42 ` mikael at gcc dot gnu.org
2015-08-05 16:42 ` mikael at gcc dot gnu.org
2015-08-05 17:04 ` mikael 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).