[Bug lto/44464] ICE during linux kernel whopr build

2010-06-16 Thread jamborm at gcc dot gnu dot org


--- Comment #22 from jamborm at gcc dot gnu dot org  2010-06-16 17:02 
---
This is now fixed on both the trunk and the 4.5 branch.


-- 

jamborm at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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



[Bug lto/44464] ICE during linux kernel whopr build

2010-06-16 Thread jamborm at gcc dot gnu dot org


--- Comment #21 from jamborm at gcc dot gnu dot org  2010-06-16 17:01 
---
Subject: Bug 44464

Author: jamborm
Date: Wed Jun 16 17:01:06 2010
New Revision: 160852

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160852
Log:
2010-06-15  Martin Jambor  

PR lto/44464
* tree-sra.c (replace_removed_params_ssa_names): Call release_ssa_name
on the newly dead SSA name.


Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/tree-sra.c


-- 


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



[Bug lto/44464] ICE during linux kernel whopr build

2010-06-15 Thread jamborm at gcc dot gnu dot org


--- Comment #20 from jamborm at gcc dot gnu dot org  2010-06-15 11:09 
---
Subject: Bug 44464

Author: jamborm
Date: Tue Jun 15 11:09:12 2010
New Revision: 160777

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160777
Log:
2010-06-15  Martin Jambor  

PR lto/44464
* tree-sra.c (replace_removed_params_ssa_names): Call release_ssa_name
on the newly dead SSA name.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-sra.c


-- 


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



[Bug lto/44464] ICE during linux kernel whopr build

2010-06-11 Thread andi-gcc at firstfloor dot org


--- Comment #19 from andi-gcc at firstfloor dot org  2010-06-11 17:09 
---
Sorry you need -nostdlib too (forgot that)

-r is immediate linking


-- 


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



[Bug lto/44464] ICE during linux kernel whopr build

2010-06-11 Thread jamborm at gcc dot gnu dot org


--- Comment #18 from jamborm at gcc dot gnu dot org  2010-06-11 16:49 
---
When I tried the LTO step in any of the two testcases I got:

jamb...@tuc:~/gcc/mine/test/pr44464$ ~/gcc/inst/mine/bin/gcc -r -fwhopr
igmp.mini.o
/usr/bin/ld: cannot find -lgcc_s
collect2: ld returned 1 exit status

What am I doing wrong?  (And what does the -r switch, I can't find it
in the documentation)


-- 


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



[Bug lto/44464] ICE during linux kernel whopr build

2010-06-10 Thread andi-gcc at firstfloor dot org


--- Comment #17 from andi-gcc at firstfloor dot org  2010-06-10 13:21 
---
Created an attachment (id=20882)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20882&action=view)
other test case


-- 


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



[Bug lto/44464] ICE during linux kernel whopr build

2010-06-10 Thread andi-gcc at firstfloor dot org


--- Comment #16 from andi-gcc at firstfloor dot org  2010-06-10 13:20 
---
I reduced another of my ICEs from this build and it's in the same place.

(gdb) bt
#0  var_map_base_init (map=0x10abe60) at ../../gcc/gcc/tree-ssa-live.c:87
#1  0x007248fb in coalesce_ssa_name () at
../../gcc/gcc/tree-ssa-coalesce.c:1405
...


-- 


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



[Bug lto/44464] ICE during linux kernel whopr build

2010-06-09 Thread andi-gcc at firstfloor dot org


--- Comment #15 from andi-gcc at firstfloor dot org  2010-06-09 13:55 
---
Ok seems it does not do what I want:

   FIXME lto.  Currently the scheme is limited in that only the
   options saved on the first object file (f1.o) are read back during
   the link step.  This means that the options used to compile f1.o
   will be applied to ALL the object files in the final link step.
   More work needs to be done to implement a merging and validation
   mechanism, as this will not be enough for all cases.  */

Anyways OT for this bug, maybe needs a new one?


-- 


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



[Bug lto/44464] ICE during linux kernel whopr build

2010-06-09 Thread andi-gcc at firstfloor dot org


--- Comment #14 from andi-gcc at firstfloor dot org  2010-06-09 13:42 
---
I found this code in lto.c which seems to disagree:

/* Read the options saved from each file in the command line.  Called
   from lang_hooks.post_options which is called by process_options
   right before all the options are used to initialize the compiler.
   This assumes that decode_options has already run, so the
   num_in_fnames and in_fnames are properly set.

   Note that this assumes that all the files had been compiled with
   the same options, which is not a good assumption.  In general,
   options ought to be read from all the files in the set and merged.
   However, it is still unclear what the merge rules should be.  */

void
lto_read_all_file_options (void)

Still remains to be seen if it DTRT though (e.g. for -pg vs no -pg)


-- 


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



[Bug lto/44464] ICE during linux kernel whopr build

2010-06-09 Thread andi-gcc at firstfloor dot org


--- Comment #13 from andi-gcc at firstfloor dot org  2010-06-09 13:35 
---
What happens then when some files need different options that other files? 
This sounds more and more like a showstopper if you're right.
I was not prepared to redesign the Makefiles


-- 


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



[Bug lto/44464] ICE during linux kernel whopr build

2010-06-09 Thread rguenth at gcc dot gnu dot org


--- Comment #12 from rguenth at gcc dot gnu dot org  2010-06-09 13:03 
---
(In reply to comment #9)
> Unfortunate.  Fixing that in the makefiles would be major effort for all the 
> -f
> and -m  flags, which sometimes vary by target.
> 
> I thought LTO was designed to minimize makefile changes? 

Yes.

But you want to be able to have different optimizations at compile/link time.

Also we would need to start on how to automagically merge different settings
at compile-time ...

Well - option handling is still an awkward area.


-- 


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



[Bug lto/44464] ICE during linux kernel whopr build

2010-06-09 Thread rguenth at gcc dot gnu dot org


--- Comment #11 from rguenth at gcc dot gnu dot org  2010-06-09 13:01 
---
(In reply to comment #10)
> The tree input that leads to the NULL annotation is a "error_mark"

Not for me.


-- 


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



[Bug lto/44464] ICE during linux kernel whopr build

2010-06-09 Thread andi-gcc at firstfloor dot org


--- Comment #10 from andi-gcc at firstfloor dot org  2010-06-09 12:18 
---
The tree input that leads to the NULL annotation is a "error_mark"


-- 


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



[Bug lto/44464] ICE during linux kernel whopr build

2010-06-09 Thread andi-gcc at firstfloor dot org


--- Comment #9 from andi-gcc at firstfloor dot org  2010-06-09 12:16 ---
Unfortunate.  Fixing that in the makefiles would be major effort for all the -f
and -m  flags, which sometimes vary by target.

I thought LTO was designed to minimize makefile changes? 


-- 


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



[Bug lto/44464] ICE during linux kernel whopr build

2010-06-09 Thread rguenth at gcc dot gnu dot org


--- Comment #8 from rguenth at gcc dot gnu dot org  2010-06-09 12:16 ---
CC'ing martin even.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu dot
   ||org


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



[Bug lto/44464] ICE during linux kernel whopr build

2010-06-09 Thread rguenth at gcc dot gnu dot org


--- Comment #7 from rguenth at gcc dot gnu dot org  2010-06-09 12:15 ---
Actually - we seem to get IPA SRA parm repacements done but the original
parameter SSA names are not released.

(gdb) call debug_function (cfun->decl, 0)
igmp_mc_get_next ( * ISRA.14, struct ip_mc_list * ISRA.15)
{
  struct ip_mc_list * im;

(gdb) call debug_generic_expr ($5)
im_1

Martin - can you have a look?


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|rguenth at gcc dot gnu dot  |unassigned at gcc dot gnu
   |org |dot org
 Status|ASSIGNED|NEW


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



[Bug lto/44464] ICE during linux kernel whopr build

2010-06-09 Thread rguenth at gcc dot gnu dot org


--- Comment #6 from rguenth at gcc dot gnu dot org  2010-06-09 12:08 ---
(In reply to comment #4)
> I was told that the whopr link step would inherit the optimization
> flags from the build step. Is that not true?

That's not true.

> Here's a reduced test case with only a single input file (reduced too)
> 
> gcc46 -O2 -fwhopr -c igmp.mini.i
> gcc46 -r -fwhopr igmp.mini.o

Thanks.

Confirmed (also with -flto).

Program received signal SIGSEGV, Segmentation fault.
0x00a196e8 in var_map_base_init (map=0x16479c0)
at /space/rguenther/src/svn/trunk/gcc/tree-ssa-live.c:87
87if (!ann->base_var_processed)
(gdb) p ann
$1 = (var_ann_t) 0x0

probably not too hard to track down.  The decl is a PARM_DECL and not
registered with referenced vars.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-06-09 12:08:51
   date||


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



[Bug lto/44464] ICE during linux kernel whopr build

2010-06-09 Thread andi-gcc at firstfloor dot org


-- 

andi-gcc at firstfloor dot org changed:

   What|Removed |Added

 Status|WAITING |UNCONFIRMED


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



[Bug lto/44464] ICE during linux kernel whopr build

2010-06-09 Thread andi-gcc at firstfloor dot org


--- Comment #5 from andi-gcc at firstfloor dot org  2010-06-09 10:56 ---
Created an attachment (id=20875)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20875&action=view)
reduced input file


-- 


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



[Bug lto/44464] ICE during linux kernel whopr build

2010-06-09 Thread andi-gcc at firstfloor dot org


--- Comment #4 from andi-gcc at firstfloor dot org  2010-06-09 10:55 ---
I was told that the whopr link step would inherit the optimization
flags from the build step. Is that not true?

Here's a reduced test case with only a single input file (reduced too)

gcc46 -O2 -fwhopr -c igmp.mini.i
gcc46 -r -fwhopr igmp.mini.o


-- 


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



[Bug lto/44464] ICE during linux kernel whopr build

2010-06-08 Thread rguenth at gcc dot gnu dot org


--- Comment #3 from rguenth at gcc dot gnu dot org  2010-06-08 09:55 ---
Did you reduce the number of object files already?  Note that you are linking
without optimization (and you probably built the .o files with optimization?)
So this might be a duplicate of PR41159.

Can you put output of adding -v to one of the .o file compiles?  Can you
put preprocessed source of all .o file sources that are required to reproduce
the bug somewhere?

Thx.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Keywords||lto
Version|lto |4.6.0


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



[Bug lto/44464] ICE during linux kernel whopr build

2010-06-08 Thread andi-gcc at firstfloor dot org


--- Comment #2 from andi-gcc at firstfloor dot org  2010-06-08 09:40 ---
The object files are at http://halobates.de/whopr-ice.tar.bz2


-- 


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



[Bug lto/44464] ICE during linux kernel whopr build

2010-06-08 Thread andi-gcc at firstfloor dot org


--- Comment #1 from andi-gcc at firstfloor dot org  2010-06-08 09:38 ---
Ok unable to attach and I've been told reporting LTO bugs requires some magic
voodoo incarnations first.

If it helps here's the gdb information of the crash:

(gdb) pt var
 
(gdb) bt
#0  var_map_base_init (map=0x1102b00) at ../../gcc/gcc/tree-ssa-live.c:87
#1  0x007248fb in coalesce_ssa_name ()
at ../../gcc/gcc/tree-ssa-coalesce.c:1405
#2  0x006fd30f in rewrite_out_of_ssa (sa=0x10540a0)
at ../../gcc/gcc/tree-outof-ssa.c:909
#3  0x004d46d8 in gimple_expand_cfg ()
at ../../gcc/gcc/cfgexpand.c:3742
#4  0x0062afd1 in execute_one_pass (pass=0xf503e0)
at ../../gcc/gcc/passes.c:1576
#5  0x00fe28e0 in ?? ()
#6  0x0162aeb4 in ?? ()
#7  0x00f503e0 in ?? ()
#8  0x in ?? ()
(gdb)


Somehow "error_mark" got in there.


-- 


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