[Bug fortran/90813] [10 regression] gfortran.dg/proc_ptr_51.f90 fails (SIGSEGV) after 272084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813 --- Comment #37 from Thomas Koenig --- Author: tkoenig Date: Sat Aug 3 11:50:39 2019 New Revision: 274038 URL: https://gcc.gnu.org/viewcvs?rev=274038=gcc=rev Log: 2019-08-03 Thomas Koenig Paul Thomas Backport from trunk PR fortran/90786 PR fortran/90813 * trans-expr.c (pointer_assignment_is_proc_pointer) Remove as it is very simple and only called from one place. (gfc_trans_pointer_assignment): Rename non_proc_pointer_assign as non_proc_ptr_assign. Assign to it directly, rather than call to above, deleted function and use gfc_expr_attr instead of only checking the reference chain. * trans-decl.c (sym_identifier): New function. (mangled_identifier): New function, doing most of the work of gfc_sym_mangled_identifier. (gfc_sym_mangled_identifier): Use mangled_identifier. Add mangled identifier to global symbol table. (get_proc_pointer_decl): Use backend decl from global identifier if present. 2019-08-03 Thomas Koenig Paul Thomas Backport from trunk PR fortran/90786 PR fortran/90813 * gfortran.dg/proc_ptr_51.f90: New test. Added: branches/gcc-7-branch/gcc/testsuite/gfortran.dg/proc_ptr_51.f90 Modified: branches/gcc-7-branch/gcc/fortran/ChangeLog branches/gcc-7-branch/gcc/fortran/trans-decl.c branches/gcc-7-branch/gcc/fortran/trans-expr.c branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug fortran/90813] [10 regression] gfortran.dg/proc_ptr_51.f90 fails (SIGSEGV) after 272084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813 --- Comment #36 from Thomas Koenig --- Author: tkoenig Date: Fri Aug 2 17:51:45 2019 New Revision: 274026 URL: https://gcc.gnu.org/viewcvs?rev=274026=gcc=rev Log: 2019-08-02 Thomas Koenig Paul Thomas Backport from trunk PR fortran/90786 PR fortran/90813 * trans-expr.c (pointer_assignment_is_proc_pointer) Remove as it is very simple and only called from one place. (gfc_trans_pointer_assignment): Rename non_proc_pointer_assign as non_proc_ptr_assign. Assign to it directly, rather than call to above, deleted function and use gfc_expr_attr instead of only checking the reference chain. * trans-decl.c (sym_identifier): New function. (mangled_identifier): New function, doing most of the work of gfc_sym_mangled_identifier. (gfc_sym_mangled_identifier): Use mangled_identifier. Add mangled identifier to global symbol table. (get_proc_pointer_decl): Use backend decl from global identifier if present. 2019-08-02 Thomas Koenig Paul Thomas Backport from trunk PR fortran/90786 PR fortran/90813 * gfortran.dg/proc_ptr_51.f90: New test. Added: branches/gcc-8-branch/gcc/testsuite/gfortran.dg/proc_ptr_51.f90 Modified: branches/gcc-8-branch/gcc/fortran/ChangeLog branches/gcc-8-branch/gcc/fortran/trans-decl.c branches/gcc-8-branch/gcc/fortran/trans-expr.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug fortran/90813] [10 regression] gfortran.dg/proc_ptr_51.f90 fails (SIGSEGV) after 272084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813 Thomas Koenig changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #35 from Thomas Koenig --- Fixed on trunk and gcc 9, closing.
[Bug fortran/90813] [10 regression] gfortran.dg/proc_ptr_51.f90 fails (SIGSEGV) after 272084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813 --- Comment #34 from Thomas Koenig --- Author: tkoenig Date: Tue Jul 30 19:11:03 2019 New Revision: 273913 URL: https://gcc.gnu.org/viewcvs?rev=273913=gcc=rev Log: 2019-07-29 Thomas Koenig Paul Thomas Backport from trunk PR fortran/90786 PR fortran/90813 * trans-expr.c (pointer_assignment_is_proc_pointer) Remove as it is very simple and only called from one place. (gfc_trans_pointer_assignment): Rename non_proc_pointer_assign as non_proc_ptr_assign. Assign to it directly, rather than call to above, deleted function and use gfc_expr_attr instead of only checking the reference chain. * dump-parse-tree.c (show_global_symbol): New function. (gfc_dump_global_symbols): New function. * gfortran.h (gfc_traverse_gsymbol): Add prototype. (gfc_dump_global_symbols): Likewise. * invoke.texi: Document -fdump-fortran-global. * lang.opt: Add -fdump-fortran-global. * parse.c (gfc_parse_file): Handle flag_dump_fortran_global. * symbol.c (gfc_traverse_gsymbol): New function. * trans-decl.c (sym_identifier): New function. (mangled_identifier): New function, doing most of the work of gfc_sym_mangled_identifier. (gfc_sym_mangled_identifier): Use mangled_identifier. Add mangled identifier to global symbol table. (get_proc_pointer_decl): Use backend decl from global identifier if present. 2019-07-29 Thomas Koenig Paul Thomas Backport from trunk PR fortran/90786 PR fortran/90813 * gfortran.dg/proc_ptr_51.f90: New test. Added: branches/gcc-9-branch/gcc/testsuite/gfortran.dg/proc_ptr_51.f90 Modified: branches/gcc-9-branch/gcc/fortran/ChangeLog branches/gcc-9-branch/gcc/fortran/dump-parse-tree.c branches/gcc-9-branch/gcc/fortran/gfortran.h branches/gcc-9-branch/gcc/fortran/invoke.texi branches/gcc-9-branch/gcc/fortran/lang.opt branches/gcc-9-branch/gcc/fortran/parse.c branches/gcc-9-branch/gcc/fortran/symbol.c branches/gcc-9-branch/gcc/fortran/trans-decl.c branches/gcc-9-branch/gcc/fortran/trans-expr.c branches/gcc-9-branch/gcc/testsuite/ChangeLog
[Bug fortran/90813] [10 regression] gfortran.dg/proc_ptr_51.f90 fails (SIGSEGV) after 272084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813 --- Comment #33 from Thomas Koenig --- Author: tkoenig Date: Mon Jul 29 17:45:24 2019 New Revision: 273880 URL: https://gcc.gnu.org/viewcvs?rev=273880=gcc=rev Log: 2019-07-29 Thomas Koenig PR fortran/90813 * dump-parse-tree.c (show_global_symbol): New function. (gfc_dump_global_symbols): New function. * gfortran.h (gfc_traverse_gsymbol): Add prototype. (gfc_dump_global_symbols): Likewise. * invoke.texi: Document -fdump-fortran-global. * lang.opt: Add -fdump-fortran-global. * parse.c (gfc_parse_file): Handle flag_dump_fortran_global. * symbol.c (gfc_traverse_gsymbol): New function. * trans-decl.c (sym_identifier): New function. (mangled_identifier): New function, doing most of the work of gfc_sym_mangled_identifier. (gfc_sym_mangled_identifier): Use mangled_identifier. Add mangled identifier to global symbol table. (get_proc_pointer_decl): Use backend decl from global identifier if present. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dump-parse-tree.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/invoke.texi trunk/gcc/fortran/lang.opt trunk/gcc/fortran/parse.c trunk/gcc/fortran/symbol.c trunk/gcc/fortran/trans-decl.c
[Bug fortran/90813] [10 regression] gfortran.dg/proc_ptr_51.f90 fails (SIGSEGV) after 272084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813 --- Comment #32 from rguenther at suse dot de --- On Wed, 24 Jul 2019, tkoenig at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813 > > --- Comment #31 from Thomas Koenig --- > (In reply to rguent...@suse.de from comment #30) > > > > So something is odd with how the frontend handles 'c_'. > > > > The symbol table has two: > > > > __f_MOD_c_/2 (c_) @0x7f763892d300 > > Type: variable definition analyzed > > Visibility: public > > References: > > Referring: __f_MOD_fs/6 (write) > > Availability: not-ready > > Varpool flags: > > > > __f_MOD_c_/15 (c_) @0x7f763892df80 > > Type: variable > > Visibility: external public > > previous sharing asm name: 2 > > References: > > Referring: MAIN__/8 (read) > > Availability: not-ready > > Varpool flags: > > Ok, so I presume the best way would be to add module variables > to the Fortran global variables (name mangling should make that > uniquie, if not we have serious other problems :-) > > One question: How do I get that symbol table printed out? > I can see it can be _extremely_ useful, but I don't know > how to get at it. It's dumped by -fdump-ipa-cgraph into source.000i.cgraph.
[Bug fortran/90813] [10 regression] gfortran.dg/proc_ptr_51.f90 fails (SIGSEGV) after 272084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813 --- Comment #31 from Thomas Koenig --- (In reply to rguent...@suse.de from comment #30) > So something is odd with how the frontend handles 'c_'. > > The symbol table has two: > > __f_MOD_c_/2 (c_) @0x7f763892d300 > Type: variable definition analyzed > Visibility: public > References: > Referring: __f_MOD_fs/6 (write) > Availability: not-ready > Varpool flags: > > __f_MOD_c_/15 (c_) @0x7f763892df80 > Type: variable > Visibility: external public > previous sharing asm name: 2 > References: > Referring: MAIN__/8 (read) > Availability: not-ready > Varpool flags: Ok, so I presume the best way would be to add module variables to the Fortran global variables (name mangling should make that uniquie, if not we have serious other problems :-) One question: How do I get that symbol table printed out? I can see it can be _extremely_ useful, but I don't know how to get at it. Thanks for the debugging on this!
[Bug fortran/90813] [10 regression] gfortran.dg/proc_ptr_51.f90 fails (SIGSEGV) after 272084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813
--- Comment #30 from rguenther at suse dot de ---
On Tue, 23 Jul 2019, tkoenig at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813
>
> --- Comment #29 from Thomas Koenig ---
> (In reply to rguent...@suse.de from comment #28)
>
> > -fdump-tree-all-uid without the space
>
> OK, so this works.
>
> What we have in the *.004t.original dump is
>
> fs ();
> {
> struct __class_f_S_p rhs.2D.3928;
>
> rhs.2D.3928 = c_ ();
> resD.3913._vptrD.3910 = rhs.2D.3928._vptrD.3910;
> resD.3913._dataD.3909 = rhs.2D.3928._dataD.3909;
> }
>
> which looks, good and in *.005t.gimple
>
> fs ();
> {
> struct __class_f_S_p rhs.2D.3928;
>
> try
> {
> c_.5_10 = c_D.3927;
> rhs.2D.3928 = c_.5_10 ();
> _11 = rhs.2D.3928._vptrD.3910;
> resD.3913._vptrD.3910 = _11;
> _12 = rhs.2D.3928._dataD.3909;
> resD.3913._dataD.3909 = _12;
> }
> finally
> {
> rhs.2D.3928 = {CLOBBER};
> }
> }
>
> From the naming convention, the variable c_D.3927 looks like something
> generated by the front end, but it's not there in the *.original dump:
>
> $ grep 3927 proc_ptr_51.f90.00*
> proc_ptr_51.f90.005t.gimple: c_.5_10 = c_D.3927;
> proc_ptr_51.f90.007t.omplower: c_.5_10 = c_D.3927;
> proc_ptr_51.f90.008t.lower: c_.5_10 = c_D.3927;
>
> So, there might possibly be something wrong about
>
> rhs.2D.3928 = c_ ();
>
> but what?
c_D.3918 = cD.3925;
c_.5_12 = c_D.3933;
rhs.2D.4008 = c_.5_12 ();
which is what I showed. So the initialization of 'c_' happens
to the variable with UID 3918 while the read from 'c_' happens
through the variable with UID 3933. Looking at the fortran
source I assume 'c_' is a global variable so we should only
have one, correct?
I can see in .original (x86_64 btw!)
fs ()
{
c_D.3918 = cD.3925;
return;
}
MAIN__ ()
{
extern struct __class_f_S_p (*) (void) c_D.3951;
(!)
...
rhs.2D.3934 = c_ ();
(unfortunately we don't dump the UID here, but it's 3933).
this is gimplified to
c_.5_10 = c_D.3933;
rhs.2D.3934 = c_.5_10 ();
so this is yet another variable!? (again extern declared)
So something is odd with how the frontend handles 'c_'.
The symbol table has two:
__f_MOD_c_/2 (c_) @0x7f763892d300
Type: variable definition analyzed
Visibility: public
References:
Referring: __f_MOD_fs/6 (write)
Availability: not-ready
Varpool flags:
__f_MOD_c_/15 (c_) @0x7f763892df80
Type: variable
Visibility: external public
previous sharing asm name: 2
References:
Referring: MAIN__/8 (read)
Availability: not-ready
Varpool flags:
In principle this might work out but it seems that on powerpc
one gets a section anchor while the other not and we end up
disambiguating based on that.
So I'd say frontends are not expected to do this. For example
the C fronted for a similar
void f(){}
void (*g)();
void bar()
{
g = f;
}
int main()
{
extern void (*g)();
bar();
g();
}
produces
bar ()
{
gD.1909 = fD.1907;
}
main ()
{
intD.6 D.1917;
{
extern voidD.51 (*) () gD.1915;
^^ for debug info only
bar ();
g.0_1 = gD.1909; // g, merged with the earlier definition
g.0_1 ();
}
D.1917 = 0;
return D.1917;
}
since the variables are not recorded as aliases but only
share the assembler name nothing in symtab_node::equal_address_to
fires. On x86 you are lucky enough that load and store are not
re-ordered (even with -fschedule-insns).
[Bug fortran/90813] [10 regression] gfortran.dg/proc_ptr_51.f90 fails (SIGSEGV) after 272084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813
--- Comment #29 from Thomas Koenig ---
(In reply to rguent...@suse.de from comment #28)
> -fdump-tree-all-uid without the space
OK, so this works.
What we have in the *.004t.original dump is
fs ();
{
struct __class_f_S_p rhs.2D.3928;
rhs.2D.3928 = c_ ();
resD.3913._vptrD.3910 = rhs.2D.3928._vptrD.3910;
resD.3913._dataD.3909 = rhs.2D.3928._dataD.3909;
}
which looks, good and in *.005t.gimple
fs ();
{
struct __class_f_S_p rhs.2D.3928;
try
{
c_.5_10 = c_D.3927;
rhs.2D.3928 = c_.5_10 ();
_11 = rhs.2D.3928._vptrD.3910;
resD.3913._vptrD.3910 = _11;
_12 = rhs.2D.3928._dataD.3909;
resD.3913._dataD.3909 = _12;
}
finally
{
rhs.2D.3928 = {CLOBBER};
}
}
From the naming convention, the variable c_D.3927 looks like something
generated by the front end, but it's not there in the *.original dump:
$ grep 3927 proc_ptr_51.f90.00*
proc_ptr_51.f90.005t.gimple: c_.5_10 = c_D.3927;
proc_ptr_51.f90.007t.omplower: c_.5_10 = c_D.3927;
proc_ptr_51.f90.008t.lower: c_.5_10 = c_D.3927;
So, there might possibly be something wrong about
rhs.2D.3928 = c_ ();
but what?
[Bug fortran/90813] [10 regression] gfortran.dg/proc_ptr_51.f90 fails (SIGSEGV) after 272084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813 --- Comment #28 from rguenther at suse dot de --- On July 7, 2019 2:59:29 PM GMT+02:00, "tkoenig at gcc dot gnu.org" wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813 > >--- Comment #27 from Thomas Koenig --- >(In reply to Richard Biener from comment #26) > >> The odd thing is that for the Fortran example even the tree oracle >claims >> the store doesn't alias the load... >> >> Because they are different variables! Dumping with -uid shows >> >> c_D.3918 = cD.3925; >> c_.5_12 = c_D.3933; >> rhs.2D.4008 = c_.5_12 (); >> >> that's probably not intended either... c_D.3933 is never initialized >> anywhere in the testcase. > >Sorry to have to ask but... How did you get this dump? > >gfortran -O3 -fdump-tree-all -uid proc_ptr_51.f90 -fdump-tree-all-uid without the space > >and grepping for c_D under proc_ptr.f90.* (on POWER) does not show any >hits for me. (And what does -uid do?) > >The last useful dump I can find results in what can be seen in >comment #14, which seems correct.
[Bug fortran/90813] [10 regression] gfortran.dg/proc_ptr_51.f90 fails (SIGSEGV) after 272084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813 --- Comment #27 from Thomas Koenig --- (In reply to Richard Biener from comment #26) > The odd thing is that for the Fortran example even the tree oracle claims > the store doesn't alias the load... > > Because they are different variables! Dumping with -uid shows > > c_D.3918 = cD.3925; > c_.5_12 = c_D.3933; > rhs.2D.4008 = c_.5_12 (); > > that's probably not intended either... c_D.3933 is never initialized > anywhere in the testcase. Sorry to have to ask but... How did you get this dump? gfortran -O3 -fdump-tree-all -uid proc_ptr_51.f90 and grepping for c_D under proc_ptr.f90.* (on POWER) does not show any hits for me. (And what does -uid do?) The last useful dump I can find results in what can be seen in comment #14, which seems correct.
[Bug fortran/90813] [10 regression] gfortran.dg/proc_ptr_51.f90 fails (SIGSEGV) after 272084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813 --- Comment #13 from Segher Boessenkool --- addis 9,2,.LC1@toc@ha ld 9,.LC1@toc@l(9) ... ld 9,0(9) ... ld 10,0(9) ... mtctr 10 ... bctrl .LC1: .quad __f_MOD_c_ So that symbol is dereferenced twice to get the address to jump to; and that gets 0. I can't read this Fortran so I don't know what is happening, either :-/
[Bug fortran/90813] [10 regression] gfortran.dg/proc_ptr_51.f90 fails (SIGSEGV) after 272084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813 --- Comment #12 from Thomas Koenig --- Another data point. If the test case is split across two files (the module separate from the main program), then it works.
[Bug fortran/90813] [10 regression] gfortran.dg/proc_ptr_51.f90 fails (SIGSEGV) after 272084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813 Thomas Koenig changed: What|Removed |Added CC||segher at gcc dot gnu.org --- Comment #11 from Thomas Koenig --- Looking at the generated POWER assembly with -O2 -fverbose-asm (on gcc135), one gets addis 10,2,.LC1@toc@ha # tmp142,, ld 10,.LC1@toc@l(10) # tmp142,, tmp142 which loads gdb with a reasonable-looking address, and then later # proc_ptr_51.f90:35: res => c_() ld 12,0(10) # c_, c_ which loads the value 0x0 into r12, so the later # proc_ptr_51.f90:35: res => c_() mtctr 12 #, branches to a NULL pointer. I don't read POWER assembly all that well (and have no idea what the @toc@ things mean). Segher, could you maybe take a look at what happens here?
[Bug fortran/90813] [10 regression] gfortran.dg/proc_ptr_51.f90 fails (SIGSEGV) after 272084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813 --- Comment #10 from Thomas Koenig --- I checked the *.optimized dump on POWER and x86_64 against each other, and there are no differences (some renumbering of variables, that's all). Looking further...
[Bug fortran/90813] [10 regression] gfortran.dg/proc_ptr_51.f90 fails (SIGSEGV) after 272084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813 Dominique d'Humieres changed: What|Removed |Added Target|powerpc64*-unknown-linux-gn |powerpc64*-unknown-linux-gn |u |u aarch64-unknown-linux-gnu Host|powerpc64*-unknown-linux-gn |powerpc64*-unknown-linux-gn |u |u aarch64-unknown-linux-gnu Build|powerpc64*-unknown-linux-gn |powerpc64*-unknown-linux-gn |u |u aarch64-unknown-linux-gnu --- Comment #9 from Dominique d'Humieres --- FAIL: gfortran.dg/proc_ptr_51.f90 -O2 execution test FAIL: gfortran.dg/proc_ptr_51.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test FAIL: gfortran.dg/proc_ptr_51.f90 -O3 -g execution test also on aarch64-unknown-linux-gnu, see https://gcc.gnu.org/ml/gcc-testresults/2019-06/msg03167.html
[Bug fortran/90813] [10 regression] gfortran.dg/proc_ptr_51.f90 fails (SIGSEGV) after 272084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813 --- Comment #8 from Paul Thomas --- (In reply to Thomas Koenig from comment #7) > I think we can move this to NEW. Please look at comment #10 to PR90786. I am at a complete loss on this one. What to do? Paul
[Bug fortran/90813] [10 regression] gfortran.dg/proc_ptr_51.f90 fails (SIGSEGV) after 272084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813 Thomas Koenig changed: What|Removed |Added Status|WAITING |NEW --- Comment #7 from Thomas Koenig --- I think we can move this to NEW.
[Bug fortran/90813] [10 regression] gfortran.dg/proc_ptr_51.f90 fails (SIGSEGV) after 272084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #6 from Thomas Koenig --- See also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90786#c6 to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90786#c8 - basically, the code jumps to a NULL pointer.
[Bug fortran/90813] [10 regression] gfortran.dg/proc_ptr_51.f90 fails (SIGSEGV) after 272084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813 --- Comment #5 from paul.richard.thomas at gmail dot com --- Hi there, That might well have pinpointed the problem sufficiently. Thanks Paul On Mon, 10 Jun 2019 at 20:18, seurer at gcc dot gnu.org wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813 > > --- Comment #4 from seurer at gcc dot gnu.org --- > So, adding in a -g3 I see: > > Program received signal SIGSEGV: Segmentation fault - invalid memory > reference. > > Backtrace for this error: > #0 0x3fffb7f80477 in ??? > #1 0x1878 in MAIN__ > at > /home/seurer/gcc/gcc-test2/gcc/testsuite/gfortran.dg/proc_ptr_51.f90:35 > #2 0x1878 in main > at > /home/seurer/gcc/gcc-test2/gcc/testsuite/gfortran.dg/proc_ptr_51.f90:32 > Segmentation fault > > > line 35 of the test case is: > res => c_() > > which looks like some kind of call via a function pointer maybe? > > Is there some specific trace or dump that would help you that I could > generate? > Be specific about options if so please. Assembler listing maybe? > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug fortran/90813] [10 regression] gfortran.dg/proc_ptr_51.f90 fails (SIGSEGV) after 272084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.0
[Bug fortran/90813] [10 regression] gfortran.dg/proc_ptr_51.f90 fails (SIGSEGV) after 272084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813 --- Comment #4 from seurer at gcc dot gnu.org --- So, adding in a -g3 I see: Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x3fffb7f80477 in ??? #1 0x1878 in MAIN__ at /home/seurer/gcc/gcc-test2/gcc/testsuite/gfortran.dg/proc_ptr_51.f90:35 #2 0x1878 in main at /home/seurer/gcc/gcc-test2/gcc/testsuite/gfortran.dg/proc_ptr_51.f90:32 Segmentation fault line 35 of the test case is: res => c_() which looks like some kind of call via a function pointer maybe? Is there some specific trace or dump that would help you that I could generate? Be specific about options if so please. Assembler listing maybe?
[Bug fortran/90813] [10 regression] gfortran.dg/proc_ptr_51.f90 fails (SIGSEGV) after 272084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813 --- Comment #3 from seurer at gcc dot gnu.org --- I don't know Fortran but will try to get some more information about the failure.
[Bug fortran/90813] [10 regression] gfortran.dg/proc_ptr_51.f90 fails (SIGSEGV) after 272084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813 --- Comment #2 from Paul Thomas --- (In reply to Dominique d'Humieres from comment #1) > See also https://gcc.gnu.org/ml/fortran/2019-06/msg00034.html. I have responded to Christophe on the above thread to the effect that I cannot see anything that would give rise to this on x86_64. Valgrind gives the runtime a clean bill of health - no unused variables being used nor mismatches in word lengths. Can you do some debugging for me? Thanks Paul
[Bug fortran/90813] [10 regression] gfortran.dg/proc_ptr_51.f90 fails (SIGSEGV) after 272084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |WAITING Last reconfirmed||2019-06-10 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- See also https://gcc.gnu.org/ml/fortran/2019-06/msg00034.html.
