[Bug fortran/44348] ICE in build_function_decl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44348 Bud Davis bdavis at gcc dot gnu.org changed: What|Removed |Added CC||bdavis at gcc dot gnu.org --- Comment #7 from Bud Davis bdavis at gcc dot gnu.org --- Current status: Original report is fixed. GNU Fortran (GCC) 6.0.0 20150811 (experimental) [bdavis@linux1 ~/gcc]$ cat a.f subroutine sub(ff) contains subroutine ff end subroutine end [bdavis@linux1 ~/gcc]$ ./run/bin/gfortran a.f a.f:3:72: Error: internal procedure 'ff' at (1) conflicts with DUMMY argument From comment #2, still broken [bdavis@linux1 ~/gcc]$ cat b.f subroutine s contains SUBROUTINE s END SUBROUTINE end subroutine [bdavis@linux1 ~/gcc]$ ./run/bin/gfortran b.f b.f:3:0: SUBROUTINE s 1 internal compiler error: in gfc_generate_function_code, at fortran/trans-decl.c:5781 0x6e7ff0 gfc_generate_function_code(gfc_namespace*) ../../current/gcc/fortran/trans-decl.c:5781 0x6e5f37 gfc_generate_contained_functions ../../current/gcc/fortran/trans-decl.c:5038 0x6e5f37 gfc_generate_function_code(gfc_namespace*) ../../current/gcc/fortran/trans-decl.c:5824 0x673490 translate_all_program_units ../../current/gcc/fortran/parse.c:5521 0x673490 gfc_parse_file() ../../current/gcc/fortran/parse.c:5726 0x6b4d22 gfc_be_parse_file ../../current/gcc/fortran/f95-lang.c:209 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.
[Bug fortran/44348] ICE in build_function_decl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44348 --- Comment #8 from Bud Davis bdavis at gcc dot gnu.org --- subroutine s contains SUBROUTINE s END SUBROUTINE end subroutine q? Is this valid ?
[Bug fortran/63494] ICE with deferred-character-length component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63494 Bud Davis bdavis at gcc dot gnu.org changed: What|Removed |Added CC||bdavis at gcc dot gnu.org --- Comment #3 from Bud Davis bdavis at gcc dot gnu.org --- type :: lrStringType character(:), allocatable :: a end type type(lrStringType), allocatable :: storage(:) storage(1)%a(j+2:) ='a' end I think the above is a bit more concise representative of the problem.
[Bug fortran/63494] ICE with deferred-character-length component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63494 --- Comment #4 from Bud Davis bdavis at gcc dot gnu.org --- my comment sounded snarky; not intended. I did not know that you were also reducing this test case !!! This page was 'stale' in my browser when i added the comment. --bud
[Bug fortran/60774] f951: internal compiler error: Segmentation fault: 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60774
--- Comment #5 from Bud Davis bdavis at gcc dot gnu.org ---
Index: gcc/gcc/fortran/parse.c
===
--- gcc/gcc/fortran/parse.c(revision 214408)
+++ gcc/gcc/fortran/parse.c(working copy)
@@ -868,8 +868,6 @@
{
gfc_warning_now (Ignoring statement label in empty statement
at %L, label_locus);
- gfc_free_st_label (gfc_statement_label);
- gfc_statement_label = NULL;
return ST_NONE;
}
}
Looks very promising.
[Bug fortran/60774] f951: internal compiler error: Segmentation fault: 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60774 Bud Davis bdavis at gcc dot gnu.org changed: What|Removed |Added CC||bdavis at gcc dot gnu.org --- Comment #3 from Bud Davis bdavis at gcc dot gnu.org --- reduced a bit further. program energy go to 123 123 contains function T(i,j,k,l,iu,ju,ku,lu,id,jd,kd,ld) end function T end program energy the label is 123 make it 123 and the segfault does not happen. (random strange thing seen when reducing it)
[Bug fortran/59746] internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59746 --- Comment #4 from Bud Davis bdavis at gcc dot gnu.org --- http://gcc.gnu.org/ml/fortran/2014-03/msg00066.html
[Bug fortran/59746] internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59746 --- Comment #3 from Bud Davis bdavis at gcc dot gnu.org --- Not so fast... Made a test for it: !pr59746 CALL RCCFL(NVE,IR,NU3,VE(1,1,1,I)) COMMON /CCFILE/ INTG,NT1,NT2,NT3,NVM,NVE,NFRLE,NRESF,NRESL COMMON /CCFILE/ INTG,NT1,NT2,NT3,NVM,NVE,NFRLE,NRESF,NRESL ! the PR only contained the two above. ! success is no segfaults or infinite loops. ! let's check some combinations CALL ABC (INTG) COMMON /CCFILE/ INTG,NT1,NT2,NT3,NVM,NVE,NFRLE,NRESF,NRESL COMMON /CCFILE/ INTG,NT1,NT2,NT3,NVM,NVE,NFRLE,NRESF,NRESL CALL DEF (NT1) COMMON /CCFILE/ INTG,NT1,NT2,NT3,NVM,NVE,NFRLE,NRESF,NRESL COMMON /CCFILE/ INTG,NT1,NT2,NT3,NVM,NVE,NFRLE,NRESF,NRESL CALL GHI (NRESL) COMMON /CCFILE/ INTG,NT1,NT2,NT3,NVM,NVE,NFRLE,NRESF,NRESL COMMON /CCFILE/ INTG,NT1,NT2,NT3,NVM,NVE,NFRLE,NRESF,NRESL END And all the 'extras' also cause a segfault.
[Bug fortran/59746] internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59746
Bud Davis bdavis at gcc dot gnu.org changed:
What|Removed |Added
CC||bdavis at gcc dot gnu.org
--- Comment #2 from Bud Davis bdavis at gcc dot gnu.org ---
it looks like what was happening was the variable that was previously defined,
NVE, was not getting deleted out of the common block by
restore_last_undo_checkpoint. Then the next time it was called, the common
block list was messed up.
The code would only remove a variable from a common block if it was just
defined in the previous statement. I changed it so it would remove a variable
from a common block if it was just defined, or if it previously existed and was
put in the common block in the last statement.
This patch works with the example given and has no regressions in the
testsuite.
Short on time, wanted to save this info so it is not lost. If anyone wants to
finish this up (testcase, blah. blah...) please feel free to do so.
--bud davis
[bdavis@budlinux1 current]$ svn diff gcc
Index: gcc/gcc/fortran/symbol.c
===
--- gcc/gcc/fortran/symbol.c(revision 208254)
+++ gcc/gcc/fortran/symbol.c(working copy)
@@ -3069,9 +3069,10 @@
FOR_EACH_VEC_ELT (latest_undo_chgset-syms, i, p)
{
- if (p-gfc_new)
+ if (p-gfc_new || (p-old_symbol !p-old_symbol-common_block))
{
- /* Symbol was new. */
+ /* Symbol was new. Or it is old, and was just put in a common
+ block */
if (p-attr.in_common p-common_block p-common_block-head)
{
/* If the symbol was added to any common block, it
@@ -3092,7 +3093,9 @@
}
if (p-common_block-head == p)
+ {
p-common_block-head = p-common_next;
+ }
else
{
gfc_symbol *cparent, *csym;
@@ -3107,25 +3110,29 @@
}
gcc_assert(cparent-common_next == p);
-
cparent-common_next = csym-common_next;
}
}
+}
+if (p-gfc_new)
+ {
- /* The derived type is saved in the symtree with the first
- letter capitalized; the all lower-case version to the
- derived type contains its associated generic function. */
- if (p-attr.flavor == FL_DERIVED)
-gfc_delete_symtree (p-ns-sym_root, gfc_get_string (%c%s,
-(char) TOUPPER ((unsigned char) p-name[0]),
-p-name[1]));
- else
-gfc_delete_symtree (p-ns-sym_root, p-name);
+/* The derived type is saved in the symtree with the first
+ letter capitalized; the all lower-case version to the
+ derived type contains its associated generic function. */
+if (p-attr.flavor == FL_DERIVED)
+ gfc_delete_symtree (p-ns-sym_root, gfc_get_string (%c%s,
+ (char) TOUPPER ((unsigned char) p-name[0]),
+ p-name[1]));
+else
+ gfc_delete_symtree (p-ns-sym_root, p-name);
- gfc_release_symbol (p);
-}
- else
-restore_old_symbol (p);
+gfc_release_symbol (p);
+ }
+else
+ {
+restore_old_symbol (p);
+ }
}
latest_undo_chgset-syms.truncate (0);
[Bug fortran/52075] OpenMP atomic update failing if -fbounds-check specified
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52075 Bud Davis bdavis at gcc dot gnu.org changed: What|Removed |Added CC||bdavis at gcc dot gnu.org --- Comment #2 from Bud Davis bdavis at gcc dot gnu.org --- The attached code does not demonstrate the error shown on the following: GNU Fortran (GCC) 4.9.0 20131220 (experimental) 32 bit / CentOS 6
[Bug fortran/59016] f951: internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016 Bud Davis bdavis at gcc dot gnu.org changed: What|Removed |Added CC||bdavis at gcc dot gnu.org --- Comment #2 from Bud Davis bdavis at gcc dot gnu.org --- Is the reduced test case valid code ? Should it compile cleanly or should it provide a warning or error ?
[Bug fortran/34928] Extension: volatile common blocks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34928 --- Comment #9 from Bud Davis bdavis at gcc dot gnu.org --- I completely support closing this PR with a note in the documentation. On shared memory mini computers of a bygone era, it was common to map the common blocks to a specific memory address, and then more than one program (in more than one cpu) could access them. You used the volatile keyword to ensure the writes happened to memory, and didn't stay in the register set of a cpu. I also wouldn't be surprised if I/O devices (think VME) were mapped to a fortan common block name, and thus also required volatile. Both concepts are long gone, but the code still lives. A note in the documentation is all it needs. --bud p.s. This explanation may be wrong. It was a long time ago. !!
[Bug fortran/58226] negative subscript pos at fortran/options.c:1205
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58226 Bud Davis bdavis at gcc dot gnu.org changed: What|Removed |Added CC||bdavis at gcc dot gnu.org --- Comment #2 from Bud Davis bdavis at gcc dot gnu.org --- works for me. GNU Fortran (GCC) 4.9.0 20131005 (experimental)
[Bug fortran/57373] ICE on invalid: insert_bbt(): Duplicate key found!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57373 Bud Davis bdavis at gcc dot gnu.org changed: What|Removed |Added CC||bdavis at gcc dot gnu.org --- Comment #2 from Bud Davis bdavis at gcc dot gnu.org --- 0 0x45f20f60 in exit () from /lib/libc.so.6 #1 0x08161d73 in gfc_internal_error ( format=0x8b5da50 insert_bbt(): Duplicate key found!) at ../../gcc/gcc/fortran/error.c:1101 #2 0x0813c644 in insert (new_bbt=new_bbt@entry=0x8f844d0, t=0x8f843f0, compare=compare@entry=0x81d5400 compare_symtree(void*, void*)) at ../../gcc/gcc/fortran/bbt.c:119 #3 0x0813c69c in gfc_insert_bbt (root=0x8fc3410, new_node=0x8f844d0, compare=0x81d5400 compare_symtree(void*, void*)) at ../../gcc/gcc/fortran/bbt.c:137 #4 0x081d80b1 in gfc_new_symtree (root=0x8fc3410, name=0xbfffe980 a) at ../../gcc/gcc/fortran/symbol.c:2384 #5 0x081500bc in get_proc_name (name=name@entry=0xbfffe980 a, result=result@entry=0xbfffe978, module_fcn_entry=module_fcn_entry@entry=false) at ../../gcc/gcc/fortran/decl.c:943 #6 0x081573db in gfc_match_function_decl () at ../../gcc/gcc/fortran/decl.c:5249 #7 0x081a4a81 in decode_statement () at ../../gcc/gcc/fortran/parse.c:312 #8 0x081a600c in next_free () at ../../gcc/gcc/fortran/parse.c:784 #9 next_statement () at ../../gcc/gcc/fortran/parse.c:977 #10 0x081a6a32 in parse_interface () at ../../gcc/gcc/fortran/parse.c:2384 Is the backtrace in case anyone is interested.
[Bug fortran/34928] Extension: volatile common blocks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34928 --- Comment #5 from Bud Davis bdavis at gcc dot gnu.org --- As the reporter of this enhancement request, I think it is something that should be left open. Low priority, but this was a 'feature' of some f77 compilers in the past. Even if no-one ever adds this functionality, those porting old f77 code that encounter this will be able to see that it is not implemented and they can infer why it was not added.
[Bug fortran/22210] gfc_conv_array_initializer weirdness
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22210 Bud Davis bdavis at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||bdavis at gcc dot gnu.org Resolution|--- |WONTFIX --- Comment #17 from Bud Davis bdavis at gcc dot gnu.org --- Closing due to no clear problem defined. If more info is available, please re-open.
[Bug fortran/56806] make: *** [spher_harm.o] Error 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56806 Bud Davis bdavis at gcc dot gnu.org changed: What|Removed |Added CC||bdavis at gcc dot gnu.org --- Comment #2 from Bud Davis bdavis at gcc dot gnu.org --- Need a reduced test case. The smallest sequence of valid code that reproduces the problem. 5 to 10 lines is idea. If possible.
[Bug fortran/57328] Missed optimization: Unable to vectorize Fortran min and max intrinsics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57328 --- Comment #8 from Bud Davis bdavis at gcc dot gnu.org --- The compiler generates code for min and max that checks if an argument is NaN. (floating point numbers only, of course). This is different than the example you posted, as it would not give the correct answer when an argument is NaN.
[Bug fortran/57328] Missed optimization: Unable to vectorize Fortran min and max intrinsics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57328 Bud Davis bdavis at gcc dot gnu.org changed: What|Removed |Added CC||bdavis at gcc dot gnu.org --- Comment #1 from Bud Davis bdavis at gcc dot gnu.org --- subroutine max_in_loop(rin, rout) integer :: rin(1000), rout(1000), tmp !real :: rin(1000), rout(1000), tmp integer :: i do i = 2, 1000 tmp = min(rin(i-1), rin(i)) rout(i) = tmp end do end subroutine Is vectorized. The floating point number makes it special in some way. Looking in trans-intrinic.c , it is special. /* FIXME: When the IEEE_ARITHMETIC module is implemented, the call to __builtin_isnan might be made dependent on that module being loaded, to help performance of programs that don't rely on IEEE semantics. */
[Bug fortran/46703] Wrong I/O output (only) when running under valgrind
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46703 Bud Davis bdavis at gcc dot gnu.org changed: What|Removed |Added CC||bdavis at gcc dot gnu.org --- Comment #5 from Bud Davis bdavis at gcc dot gnu.org --- From the world of 2013gcc-4.8 / FC18 / i386 The example posted above gives good answers when compiled and ran. And all zeroes when ran under valgrind.
[Bug fortran/46703] Wrong I/O output (only) when running under valgrind
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46703 --- Comment #6 from Bud Davis bdavis at gcc dot gnu.org --- It is a problem with Valgrind. One that is even mentioned in the (valgrind) manual. https://bugs.kde.org/show_bug.cgi?id=197915 It has been open for about 4 years, not fixed yet. Short summary. Don't use valgrind on real's larger than 64 bits. --bud davis
[Bug fortran/38312] Unexpected STATEMENT FUNCTION statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38312 Bud Davis bdavis at gcc dot gnu.org changed: What|Removed |Added CC||bdavis at gcc dot gnu.org --- Comment #7 from Bud Davis bdavis at gcc dot gnu.org --- 18 months since any comments were made... If I had a vote, it would be close as a WONT FIX. --bud
[Bug fortran/50405] allocation LOOP or SIGSEGV
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50405
Bud Davis bdavis at gcc dot gnu.org changed:
What|Removed |Added
CC||bdavis at gcc dot gnu.org
--- Comment #1 from Bud Davis bdavis at gcc dot gnu.org ---
possible patch:
Index: gcc/gcc/fortran/resolve.c
===
--- gcc/gcc/fortran/resolve.c(revision 198804)
+++ gcc/gcc/fortran/resolve.c(working copy)
@@ -306,6 +306,14 @@
!resolve_procedure_interface (sym))
return;
+ if (strcmp (proc-name,sym-name) == 0)
+{
+ gfc_error (Self referential argument
+ '%s' at %L is not allowed, sym-name,
+ proc-declared_at);
+ return;
+}
+
if (sym-attr.if_source != IFSRC_UNKNOWN)
resolve_formal_arglist (sym);
[Bug fortran/51591] Strange output from STOP statement in OpenMP region
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51591 --- Comment #4 from Bud Davis bdavis at gcc dot gnu.org --- Upon closer reflection, the underlying problems is the OpenMP threads doing I/O while the units are being closed. So, stop shows in the output, followed by output from threads whose units have been destroyed, but the call to exit() handler has not yet terminated.
[Bug libfortran/51418] Fortran format sp,f0.0 output wrong with NaN and 0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51418 Bud Davis bdavis at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||bdavis at gcc dot gnu.org Resolution||FIXED --- Comment #4 from Bud Davis bdavis at gcc dot gnu.org 2012-07-06 18:16:49 UTC --- From reading the summary, the bug is fixed in recent versions, and no further action is to be taken. Thus RESOLVED / FIXED.
[Bug fortran/51591] Strange output from STOP statement in OpenMP region
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51591 Bud Davis bdavis at gcc dot gnu.org changed: What|Removed |Added CC||bdavis at gcc dot gnu.org --- Comment #3 from Bud Davis bdavis at gcc dot gnu.org 2012-02-03 22:08:10 UTC --- Index: gcc/libgfortran/io/unit.c === --- gcc/libgfortran/io/unit.c (revision 183873) +++ gcc/libgfortran/io/unit.c (working copy) @@ -637,6 +637,7 @@ if (u-previous_nonadvancing_write) finish_last_advance_record (u); + __gthread_mutex_lock (u-lock); rc = (u-s == NULL) ? 0 : sclose (u-s) == -1; u-closed = 1; As theorized, the above patch does seem to correct the problem with no regressions in the testsuite.
[Bug fortran/49011] Wrong repeat count in error message for REPEAT intrinsic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49011 Bud Davis bdavis at gcc dot gnu.org changed: What|Removed |Added CC||bdavis at gcc dot gnu.org --- Comment #3 from Bud Davis bdavis at gcc dot gnu.org 2012-02-03 22:31:23 UTC --- 32 bit, 2.6 kernel, revision 183881, message is correct. Should this be closed or is it an X86-64 thing ? --bud davis
[Bug fortran/50619] Surprising interaction between -finit-real=NAN and the associate construct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50619 Bud Davis bdavis at gcc dot gnu.org changed: What|Removed |Added CC||bdavis at gcc dot gnu.org --- Comment #2 from Bud Davis bdavis at gcc dot gnu.org 2011-11-30 21:30:30 UTC --- Reduced a bit more, for those that like it simple real :: rmult = 1.0e0 real :: e print*,'No Associate',rmult associate (rmult=e) print*,' Associate',e end associate end
[Bug fortran/51338] seg fault in gfc_dep_compare_expr with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51338
Bud Davis bdavis at gcc dot gnu.org changed:
What|Removed |Added
CC||bdavis at gcc dot gnu.org
--- Comment #2 from Bud Davis bdavis at gcc dot gnu.org 2011-11-28 21:40:40
UTC ---
Program received signal SIGSEGV, Segmentation fault.
0x081bc9af in gfc_dep_compare_expr (e1=0x0, e2=0x0) at
../../gcc/gcc/fortran/dependency.c:242
242{
Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.7.el6_0.5.i686
(gdb) bt
#0 0x081bc9af in gfc_dep_compare_expr (e1=0x0, e2=0x0) at
../../gcc/gcc/fortran/dependency.c:242
#1 0x081bd105 in are_identical_variables (e1=0x905d440, e2=0x905c520) at
../../gcc/gcc/fortran/dependency.c:177
#2 gfc_dep_compare_expr (e1=0x905d440, e2=0x905c520) at
../../gcc/gcc/fortran/dependency.c:438
#3 0x081be244 in gfc_dep_compare_functions (e1=0x905d668, e2=0x905d2f0,
impure_ok=true)
at ../../gcc/gcc/fortran/dependency.c:221
#4 0x0823bf67 in cfe_expr_0 (e=0x905cdb8, walk_subtrees=0xbfffee3c, data=0x0)
at ../../gcc/gcc/fortran/frontend-passes.c:386
#5 0x0823bbd6 in gfc_expr_walker (e=0x905cdb8, exprfn=0x823bea0
cfe_expr_0(gfc_expr**, int*, void*), data=0x0)
at ../../gcc/gcc/fortran/frontend-passes.c:1039
#6 0x0823c72c in gfc_code_walker (c=0x905c4b8, codefn=0x823ae40
cfe_code(gfc_code**, int*, void*),
exprfn=0x823bea0 cfe_expr_0(gfc_expr**, int*, void*), data=0x0) at
../../gcc/gcc/fortran/frontend-passes.c:1361
#7 0x0823c70e in gfc_code_walker (c=0x905c670, codefn=0x823ae40
cfe_code(gfc_code**, int*, void*),
exprfn=0x823bea0 cfe_expr_0(gfc_expr**, int*, void*), data=0x0) at
../../gcc/gcc/fortran/frontend-passes.c:1363
#8 0x0823c70e in gfc_code_walker (c=0x905c150, codefn=0x823ae40
cfe_code(gfc_code**, int*, void*),
exprfn=0x823bea0 cfe_expr_0(gfc_expr**, int*, void*), data=0x0) at
../../gcc/gcc/fortran/frontend-passes.c:1363
#9 0x0823c70e in gfc_code_walker (c=0x9058620, codefn=0x823ae40
cfe_code(gfc_code**, int*, void*),
exprfn=0x823bea0 cfe_expr_0(gfc_expr**, int*, void*), data=0x0) at
../../gcc/gcc/fortran/frontend-passes.c:1363
#10 0x0823c70e in gfc_code_walker (c=0x9057608, codefn=0x823ae40
cfe_code(gfc_code**, int*, void*),
exprfn=0x823bea0 cfe_expr_0(gfc_expr**, int*, void*), data=0x0) at
../../gcc/gcc/fortran/frontend-passes.c:1363
#11 0x0823d25c in optimize_namespace (ns=0x9055320) at
../../gcc/gcc/fortran/frontend-passes.c:510
#12 0x0823d2ea in gfc_run_passes (ns=0x9055320) at
../../gcc/gcc/fortran/frontend-passes.c:80
#13 0x0818a4b9 in resolve_all_program_units () at
../../gcc/gcc/fortran/parse.c:4342
#14 gfc_parse_file () at ../../gcc/gcc/fortran/parse.c:4608
#15 0x081c641d in gfc_be_parse_file () at ../../gcc/gcc/fortran/f95-lang.c:250
#16 0x085a97c5 in compile_file (argc=21, argv=0xb1f4) at
../../gcc/gcc/toplev.c:565
[Bug fortran/51338] seg fault in gfc_dep_compare_expr with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51338 --- Comment #3 from Bud Davis bdavis at gcc dot gnu.org 2011-11-28 21:59:02 UTC --- Reduced: SUBROUTINE PAXCUT(CHIN,CHOUT) CHARACTER*(*) CHIN,CHOUT IF(INDEX(CHOUT(K:),'.OR.').EQ.INDEX(CHOUT(K:),'.AND.')) THEN ENDIF END
[Bug fortran/51338] [4.6/4.7 Regression] seg fault in gfc_dep_compare_expr with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51338 --- Comment #5 from Bud Davis bdavis at gcc dot gnu.org 2011-11-28 22:49:33 UTC --- Index: gcc/gcc/fortran/dependency.c === --- gcc/gcc/fortran/dependency.c(revision 181789) +++ gcc/gcc/fortran/dependency.c(working copy) @@ -245,6 +245,10 @@ int i; gfc_expr *n1, *n2; + /* nothing to do here, move along */ + if (e1 == NULL e2 == NULL) + return 0; + n1 = NULL; n2 = NULL;
[Bug fortran/51338] [4.6/4.7 Regression] seg fault in gfc_dep_compare_expr with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51338 --- Comment #6 from Bud Davis bdavis at gcc dot gnu.org 2011-11-28 23:20:27 UTC --- The above patch has no new testsuite regressions. If someone wants to check and make sure the optimisation(s) that could or were being done is still correct, and check this in, feel free to do so. 1 Hour 40 minutes after bug posted. not bad. --bud
