http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644
Michael Matz changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644
--- Comment #20 from Michael Matz 2011-11-17 16:04:04
UTC ---
Author: matz
Date: Thu Nov 17 16:03:56 2011
New Revision: 181443
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181443
Log:
PR middle-end/50644
PR middle-end/50741
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644
--- Comment #19 from Michael Matz 2011-10-31 13:41:59
UTC ---
Bah, I checked against the patched compiler. Nope, with the unpatched
compiler both descriptor variables stay in the local_decls of native_cpu_up
after inlining (with the source chang
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644
--- Comment #18 from Michael Matz 2011-10-31 13:37:33
UTC ---
Ah, wrong, native_cpu_up of course calls check_tsc_sync_source, which under
LTO can be inlined. So it's the same issues as PR50741, the patch from
there works around the issue. Unfor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644
--- Comment #17 from Michael Matz 2011-10-31 13:16:49
UTC ---
Thank you very much! This really helps and at least reveals something quite
strange with LTO. It falls over the __func__ member of one of the two
static initializers:
Program receiv
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644
--- Comment #16 from Markus Trippelsdorf
2011-10-29 13:08:13 UTC ---
Or as one file:
% cat test.i
struct _ddebug {
const char *modname;
const char *function;
const char *filename;
const char *format;
char enabled;
}
cpu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644
Markus Trippelsdorf changed:
What|Removed |Added
CC||markus at trippelsdorf dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644
--- Comment #14 from Andi Kleen 2011-10-29
11:31:31 UTC ---
Created attachment 25658
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25658
3 files
I managed to reduce a test case to 3 LTO files now
unpack the tar on x86-64 and
gcc47 -O2 -fl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644
--- Comment #13 from Andi Kleen 2011-10-20
16:44:42 UTC ---
I only have a core file. It's really hard to catch the correct lto1
in gdb in a complex LTO build. The only sane way I found to at least
get some gdb information is to use -dH and use th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644
--- Comment #12 from Jakub Jelinek 2011-10-20
16:39:15 UTC ---
It doesn't contain enough info though.
In particular, it would be nice to see
p debug_tree (*(tree *)0x2b11d2f00c00)
(the first argument for the innermost walk_tree_1)
and possibly fo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644
--- Comment #11 from Andi Kleen 2011-10-20
16:30:27 UTC ---
I did fire gdb up of course, the output is in the initial report.
I also tracked it down to exactly your commit.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644
--- Comment #10 from Michael Matz 2011-10-20 16:15:36
UTC ---
Why is it so difficult to just fire up gdb? This all could be solved in a
couple of minutes.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644
--- Comment #9 from Andi Kleen 2011-10-20
14:05:49 UTC ---
Previously the builds produced working code. Now they just segfault.
If I revert the patches (plus the ones depending on it) I get working
code again.
In my book that's a "fix". I don't
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644
--- Comment #8 from Michael Matz 2011-10-20 08:14:45
UTC ---
Andi, the patch you bisected transformed a pre-existing bug into a segfault.
Reverting it wouldn't fix anything.
You could try the stab-in-the-dark patch from PR50741, but if that does
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644
--- Comment #7 from Andi Kleen 2011-10-20
05:53:49 UTC ---
Can someone mark this as a regression please? This still keeps crashing and
crashing.
I don't see why I need to debug a clear regression when I already bisected
it.
IMHO this should be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644
--- Comment #6 from Michael Matz 2011-10-13 14:04:36
UTC ---
See comment #2, you need to help in debugging it. I can't reproduce, the
emutls problem is fixed, and with the information I have I can't speculate
which (probably global) variables ne
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644
--- Comment #5 from Andi Kleen 2011-10-13
13:22:40 UTC ---
Note I need to keep reverting this patch to do any substantial builds.
I hear it's also failing for other too.
Any progress in fixing it? Thanks.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644
--- Comment #4 from Michael Matz 2011-10-07 16:34:49
UTC ---
The fortran segfault is tracked as PR50640.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644
--- Comment #2 from Michael Matz 2011-10-07 15:45:44
UTC ---
Try to find out what var is. The segfault should also happen with an
unoptimized cc1 so that you can see the value of var.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644
Andi Kleen changed:
What|Removed |Added
CC||matz at gcc dot gnu.org
--- Comment #1 from
21 matches
Mail list logo
