[Bug fortran/44348] ICE in build_function_decl

2015-08-13 Thread bdavis at gcc dot gnu.org
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

2015-08-13 Thread bdavis at gcc dot gnu.org
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

2015-01-03 Thread bdavis at gcc dot gnu.org
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

2015-01-03 Thread bdavis at gcc dot gnu.org
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

2014-08-24 Thread bdavis at gcc dot gnu.org
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

2014-06-29 Thread bdavis at gcc dot gnu.org
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

2014-03-09 Thread bdavis at gcc dot gnu.org
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

2014-03-07 Thread bdavis at gcc dot gnu.org
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

2014-03-03 Thread bdavis at gcc dot gnu.org
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

2013-12-22 Thread bdavis at gcc dot gnu.org
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

2013-12-21 Thread bdavis at gcc dot gnu.org
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

2013-12-21 Thread bdavis at gcc dot gnu.org
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

2013-10-05 Thread bdavis at gcc dot gnu.org
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!

2013-07-17 Thread bdavis at gcc dot gnu.org
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

2013-06-21 Thread bdavis at gcc dot gnu.org
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

2013-06-15 Thread bdavis at gcc dot gnu.org
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

2013-05-25 Thread bdavis at gcc dot gnu.org
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

2013-05-21 Thread bdavis at gcc dot gnu.org
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

2013-05-20 Thread bdavis at gcc dot gnu.org
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

2013-05-18 Thread bdavis at gcc dot gnu.org
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

2013-05-18 Thread bdavis at gcc dot gnu.org
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

2013-05-17 Thread bdavis at gcc dot gnu.org
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

2013-05-12 Thread bdavis at gcc dot gnu.org
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

2013-05-11 Thread bdavis at gcc dot gnu.org
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

2012-07-06 Thread bdavis at gcc dot gnu.org
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

2012-02-03 Thread bdavis at gcc dot gnu.org
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

2012-02-03 Thread bdavis at gcc dot gnu.org
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

2011-11-30 Thread bdavis at gcc dot gnu.org
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

2011-11-28 Thread bdavis at gcc dot gnu.org
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

2011-11-28 Thread bdavis at gcc dot gnu.org
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

2011-11-28 Thread bdavis at gcc dot gnu.org
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

2011-11-28 Thread bdavis at gcc dot gnu.org
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