[Bug middle-end/44150] New: [4.6 regression] g++.dg/lto/20081109 cp_lto_20081109_0.o-cp_lto_20081109_1.o

[Bug middle-end/44150] New: [4.6 regression] g++.dg/lto/20081109 cp_lto_20081109_0.o-cp_lto_20081109_1.o

[hjl dot tools at gmail dot com]

On Linux/ia32, revision 159428 gave:

FAIL: g++.dg/lto/20081109 cp_lto_20081109_0.o-cp_lto_20081109_1.o execute -O2
-fwhopr

Revision 159421 is OK.


-- 
           Summary: [4.6 regression] g++.dg/lto/20081109
                    cp_lto_20081109_0.o-cp_lto_20081109_1.o
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: hjl dot tools at gmail dot com


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

[Bug middle-end/44150] [4.6 regression] g++.dg/lto/20081109 cp_lto_20081109_0.o-cp_lto_20081109_1.o

[hjl dot tools at gmail dot com]

------- Comment #1 from hjl dot tools at gmail dot com  2010-05-15 14:00 -------
It is caused by revision 159428:

http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00480.html


-- 

hjl dot tools at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jason at redhat dot com


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

[Bug middle-end/44150] [4.6 regression] g++.dg/lto/20081109 cp_lto_20081109_0.o-cp_lto_20081109_1.o

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.6.0


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

[Bug middle-end/44150] [4.6 regression] g++.dg/lto/20081109 cp_lto_20081109_0.o-cp_lto_20081109_1.o

[jason at gcc dot gnu dot org]

-- 

jason at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |jason at gcc dot gnu dot org
                   |dot org                     |
             Status|UNCONFIRMED                 |ASSIGNED
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2010-05-15 21:40:13
               date|                            |


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

[Bug lto/44150] [4.6 regression] g++.dg/lto/20081109 cp_lto_20081109_0.o-cp_lto_20081109_1.o

[jason at gcc dot gnu dot org]

------- Comment #2 from jason at gcc dot gnu dot org  2010-05-15 22:49 -------
OK, here's what's going wrong:

The LTO design is such that EH is only enabled if we encounter a function with
an EH personality.

With -fwhopr we process one translation unit at a time, so when we look at
20081109_1.C we only see foo(int).

Before my patch foo(int) contained an ERT_MUST_NOT_THROW region, so we required
the C++ personality function.  After my patch, it contains an ERT_CLEANUP
region instead, which doesn't require the C++ personality function

So cgraph doesn't set DECL_FUNCTION_PERSONALITY, so lto1 doesn't think that foo
needs EH, so it never sets flag_exceptions, so we don't get unwind information,
so the throw can't unwind through foo.

There seem to be two issues here:
1) lto1 incorrectly thinks foo doesn't need EH.
2) -fwhopr means that lto1 can make different decisions about EH for different
translation units, so things blow up when linked together.

With #2 fixed, #1 isn't as big a problem--but it could still be an issue if we
aren't compiling the entire program, i.e. a shared library wants to throw from
a callback.  If anything we call can throw, we need unwind information and
should turn on -fexceptions.


-- 

jason at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|jason at gcc dot gnu dot org|unassigned at gcc dot gnu
                   |                            |dot org
             Status|ASSIGNED                    |NEW
          Component|middle-end                  |lto


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

[Bug lto/44150] [4.6 regression] g++.dg/lto/20081109 cp_lto_20081109_0.o-cp_lto_20081109_1.o

[steven at gcc dot gnu dot org]

------- Comment #3 from steven at gcc dot gnu dot org  2010-05-15 23:04 -------
Why is flag_exceptions not just streamed out/in with other options?


-- 


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

[Bug lto/44150] [4.6 regression] g++.dg/lto/20081109 cp_lto_20081109_0.o-cp_lto_20081109_1.o

[rguenth at gcc dot gnu dot org]

------- Comment #4 from rguenth at gcc dot gnu dot org  2010-05-16 10:56 -------
(In reply to comment #3)
> Why is flag_exceptions not just streamed out/in with other options?

It is, but the option merging is basically broken by design (and comes too
late anyway).


-- 


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

[Bug lto/44150] [4.6 regression] g++.dg/lto/20081109 cp_lto_20081109_0.o-cp_lto_20081109_1.o

[rguenth at gcc dot gnu dot org]

------- Comment #5 from rguenth at gcc dot gnu dot org  2010-05-16 10:58 -------
(In reply to comment #2)
> OK, here's what's going wrong:
> 
> The LTO design is such that EH is only enabled if we encounter a function with
> an EH personality.
> 
> With -fwhopr we process one translation unit at a time, so when we look at
> 20081109_1.C we only see foo(int).
> 
> Before my patch foo(int) contained an ERT_MUST_NOT_THROW region, so we required
> the C++ personality function.  After my patch, it contains an ERT_CLEANUP
> region instead, which doesn't require the C++ personality function
> 
> So cgraph doesn't set DECL_FUNCTION_PERSONALITY, so lto1 doesn't think that foo
> needs EH, so it never sets flag_exceptions, so we don't get unwind information,
> so the throw can't unwind through foo.
> 
> There seem to be two issues here:
> 1) lto1 incorrectly thinks foo doesn't need EH.
> 2) -fwhopr means that lto1 can make different decisions about EH for different
> translation units, so things blow up when linked together.
> 
> With #2 fixed, #1 isn't as big a problem--but it could still be an issue if we
> aren't compiling the entire program, i.e. a shared library wants to throw from
> a callback.  If anything we call can throw, we need unwind information and
> should turn on -fexceptions.

2) should be fixed by deciding on EH info at WPA stage (and not re-deciding
at LTRANS stage for every translation unit).

The current way of detecting whether to init EH is somewhat of a hack, and
there is no convenient place to store such overall properties (no, the
current option saving/restoring machiner is not it).


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hubicka at gcc dot gnu dot
                   |                            |org


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

[Bug lto/44150] [4.6 regression] g++.dg/lto/20081109 cp_lto_20081109_0.o-cp_lto_20081109_1.o

[rguenth at gcc dot gnu dot org]

------- Comment #6 from rguenth at gcc dot gnu dot org  2010-05-26 12:11 -------
Mine.


-- 

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|NEW                         |ASSIGNED
   Last reconfirmed|2010-05-15 21:40:13         |2010-05-26 12:11:52
               date|                            |


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

[Bug lto/44150] [4.6 regression] g++.dg/lto/20081109 cp_lto_20081109_0.o-cp_lto_20081109_1.o

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1


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