[Bug lto/44150] [4.6 regression] g++.dg/lto/20081109 cp_lto_20081109_0.o-cp_lto_20081109_1.o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44150 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #12 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-15 09:43:49 UTC --- Fixed.
[Bug lto/44150] [4.6 regression] g++.dg/lto/20081109 cp_lto_20081109_0.o-cp_lto_20081109_1.o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44150 --- Comment #11 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-15 09:43:09 UTC --- Author: rguenth Date: Mon Nov 15 09:43:01 2010 New Revision: 166744 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=166744 Log: 2010-11-15 Richard Guenther rguent...@suse.de PR lto/44150 * lto-opts.c (lto_write_options): Write -fexceptions even if not set by the user. Modified: trunk/gcc/ChangeLog trunk/gcc/lto-opts.c
[Bug lto/44150] [4.6 regression] g++.dg/lto/20081109 cp_lto_20081109_0.o-cp_lto_20081109_1.o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44150 --- Comment #10 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-11 14:05:29 UTC --- Ah, I think it has gone latent by disabling frame-pointer by default on i?86-linux and enabling (async) unwind tables. No unwind tables was exactly the problem, on i?86-linux at least. So on i?86-linux the issue only reproduces with -fno-omit-frame-pointer -fno-asynchronous-unwind-tables -flto-partition=1to1. I have a hack.
[Bug lto/44150] [4.6 regression] g++.dg/lto/20081109 cp_lto_20081109_0.o-cp_lto_20081109_1.o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44150 --- Comment #9 from Richard Guenther rguenth at gcc dot gnu.org 2010-10-08 09:13:00 UTC --- Honza made it go latent by defaulting to balanced partitioning.
[Bug lto/44150] [4.6 regression] g++.dg/lto/20081109 cp_lto_20081109_0.o-cp_lto_20081109_1.o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44150 --- Comment #8 from Hans-Peter Nilsson hp at gcc dot gnu.org 2010-10-08 01:16:24 UTC --- Has this intentionally been solved or did it just go latent? For cris-elf, it disappeared in (r164989:165011].
[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 changed: What|Removed |Added Priority|P3 |P1 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
--- 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
--- 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
--- 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
--- 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
--- 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
