[Bug fortran/37992] [4.4 Regression] ICE segfault for character(len=len(x)) :: foo,x

2008-11-05 Thread mikael at gcc dot gnu dot org


-- 

mikael at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |mikael at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-11-01 22:42:53 |2008-11-05 14:02:04
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37992



[Bug fortran/37992] [4.4 Regression] ICE segfault for character(len=len(x)) :: foo,x

2008-11-04 Thread pault at gcc dot gnu dot org


--- Comment #6 from pault at gcc dot gnu dot org  2008-11-04 07:59 ---
(In reply to comment #5)
 The patch in comment #4 generate a lot of bus errors in my tests. Looking at
 it, I think there is something missing: gfc_current_ns-old_cl_list is only 
 set
 to NULL, it should likely be set to gfc_current_ns-cl_list somewhere.
 
It should not be necessary to do anything to the cl_list.  As long as nothing
points to a member, it can do nothing and gets cleaned up at the end of
compilation. The reason for this is that any number, including zero, of
typespecs can point to it, so it is very risky to delete a cl_list member.

Paul

Paul


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37992



[Bug fortran/37992] [4.4 Regression] ICE segfault for character(len=len(x)) :: foo,x

2008-11-03 Thread dominiq at lps dot ens dot fr


--- Comment #5 from dominiq at lps dot ens dot fr  2008-11-03 11:02 ---
The patch in comment #4 generate a lot of bus errors in my tests. Looking at
it, I think there is something missing: gfc_current_ns-old_cl_list is only set
to NULL, it should likely be set to gfc_current_ns-cl_list somewhere.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37992



[Bug fortran/37992] [4.4 Regression] ICE segfault for character(len=len(x)) :: foo,x

2008-11-02 Thread mikael dot morin at tele2 dot fr


--- Comment #3 from mikael dot morin at tele2 dot fr  2008-11-02 17:50 
---
(In reply to comment #1)
 First valgrind error:
 
 ==21621== Invalid read of size 8
 ==21621==at 0x46AAEA: gfc_resolve_expr (resolve.c:4248)

 Second valgrind error:
 
 ==21621==  Address 0x65b2ef8 is 40 bytes inside a block of size 56 free'd
 ==21621==at 0x4C243AF: free (in
 /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
 ==21621==by 0x482C6A: gfc_delete_symtree (symbol.c:2269)


Those are the same error (look carefully, the second one is indented).
The first part indicates where the error appears. 
The second one precises the error (here access to a freed block) and where (in
this case) the free was. 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37992



[Bug fortran/37992] [4.4 Regression] ICE segfault for character(len=len(x)) :: foo,x

2008-11-02 Thread mikael dot morin at tele2 dot fr


--- Comment #4 from mikael dot morin at tele2 dot fr  2008-11-02 18:03 
---
Created an attachment (id=16612)
 -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16612action=view)
hackish patch

I think I got it. 
When the statement is rejected, all changes are reverted. 
However, the namespace is still holding the expression for len(x) in cl_list. 
So, when resolving len(x) we have a pointer to len's freed symtree. 

This patch solves the problem by adding a old_cl_list field which is copied
back to cl_list if the statement is rejected. 

I'm not sure it is the right way to do it though. 
As an inquiry function, len should always be reachable, whatever happens. 
What's your opinion?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37992



[Bug fortran/37992] [4.4 Regression] ICE segfault for character(len=len(x)) :: foo,x

2008-11-01 Thread burnus at gcc dot gnu dot org


--- Comment #1 from burnus at gcc dot gnu dot org  2008-11-01 22:38 ---
First valgrind error:

==21621== Invalid read of size 8
==21621==at 0x46AAEA: gfc_resolve_expr (resolve.c:4248)
That is:
  if (e-symtree == NULL || e-symtree-n.sym == NULL)

I think e-expr_type == EXPR_FUNCTION, i.e. the access should be OK?!?


Second valgrind error:

==21621==  Address 0x65b2ef8 is 40 bytes inside a block of size 56 free'd
==21621==at 0x4C243AF: free (in
/usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
==21621==by 0x482C6A: gfc_delete_symtree (symbol.c:2269)

That's
  st0 = gfc_find_symtree (*root, name);
  st.name = gfc_get_string (name);
  gfc_delete_bbt (root, st, compare_symtree);
  gfc_free (st0);  //  Line 2269


Seemingly, the recovery after detecting the error half deletes a symbol. I
think the problem is the foo which exists not only as local symbol.

Note: If one adds IMPLICIT NONE the ICE disappears.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37992



[Bug fortran/37992] [4.4 Regression] ICE segfault for character(len=len(x)) :: foo,x

2008-11-01 Thread janus at gcc dot gnu dot org


--- Comment #2 from janus at gcc dot gnu dot org  2008-11-01 22:42 ---
This is really funny. If I compile a file which contains exactly the three
lines given in comment #0 (and nothing else), I get some errors, but no ICE.

However, if I add at least two blank lines (no matter where), the ICE appears.

Someone with a clear mind should check this, I feel a little paranoid ;)


-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-11-01 22:42:53
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37992