https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61682
Andi Kleen andi-gcc at firstfloor dot org changed:
What|Removed |Added
CC||andi-gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61635
--- Comment #4 from Andi Kleen andi-gcc at firstfloor dot org ---
Yes it uses -fno-toplevel-reordering to avoid the problems with the initializer
reordering.
I tried some workarounds for this, but nothing worked so far. Likely would need
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61635
--- Comment #5 from Andi Kleen andi-gcc at firstfloor dot org ---
Also I forgot to state: the git tree above now has a workaround
(disabling LTO for that file). If you want to reproduce revert the latest
commit first.
: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: andi-gcc at firstfloor dot org
I currently don't have a small compilable test case, except a build tree from a
large project. But what happened was code like this
f()
{
static void *addr[] = {
label1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49611
Andi Kleen andi-gcc at firstfloor dot org changed:
What|Removed |Added
CC||andi-gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61043
--- Comment #3 from Andi Kleen andi-gcc at firstfloor dot org ---
Unfortunately, gcc does not allow using SIMD intrinsics if not enabled by
compiler switches, so leaving the compiler options for a generic target CPU
wouldn't work. At least
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61043
Andi Kleen andi-gcc at firstfloor dot org changed:
What|Removed |Added
CC||andi-gcc
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: andi-gcc at firstfloor dot org
Target x86_64-linux
Following simple test case:
#define N 64
#define ALIGN // __attribute__((aligned(64)))
int
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60989
Andi Kleen andi-gcc at firstfloor dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: andi-gcc at firstfloor dot org
While linking libstdc++
`_.stapsdt.base' referenced in section `.note.stapsdt' of
../libsupc++/.libs/libsupc++convenience.a(eh_catch.o): defined in discarded
section `.stapsdt.base
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60946
--- Comment #1 from Andi Kleen andi-gcc at firstfloor dot org ---
Obviously only happens with systemtap-devel installed
Unfortunately seems to be no switch to disable :-(
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60946
--- Comment #5 from Andi Kleen andi-gcc at firstfloor dot org ---
binutils 2.23.88.0.1.-13.fc20
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60946
--- Comment #6 from Andi Kleen andi-gcc at firstfloor dot org ---
From the links you provided it looks just always broken when
systemtap-sdt-devel is installed.
When it's not installed the configure check disables the broken code.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60804
--- Comment #8 from Andi Kleen andi-gcc at firstfloor dot org ---
I went through my collection of gimplify:8335 from the generator.
Not all of them are special statements. So some more general check would be
needed.
Some examples:
(*l_11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60804
Andi Kleen andi-gcc at firstfloor dot org changed:
What|Removed |Added
Attachment #32577|0 |1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60469
--- Comment #3 from Andi Kleen andi-gcc at firstfloor dot org ---
I've tried a couple of things to fix this:
- Fill in DECL_CONTEXT to current_fn_decl in cilk
- Fill in DECL_CONTEXT for VAR_DECLs when creating the nested wrapper
No banana so far
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60469
--- Comment #5 from Andi Kleen andi-gcc at firstfloor dot org ---
You're right. It works in C++.
That's similar to my earlier patch, but I didn't comment out the other check
like you did. If commenting out the check work it would seem right to me
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60467
--- Comment #1 from Andi Kleen andi-gcc at firstfloor dot org ---
We could add this patch to avoid the original problem:
diff --git a/gcc/c-family/cilk.c b/gcc/c-family/cilk.c
index f2179dfc..a535948 100644
--- a/gcc/c-family/cilk.c
+++ b/gcc/c
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: andi-gcc at firstfloor dot org
Created attachment 32577
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32577action=edit
test case from csmith
I hacked csmith to add some _Cilk_spawn keywords
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50679
Andi Kleen andi-gcc at firstfloor dot org changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60469
--- Comment #1 from Andi Kleen andi-gcc at firstfloor dot org ---
I investigated this a bit.
The problem is in get_chain_decl() in the nested function lowering because Cilk
creates nested functions.
info-outer is NULL
created_nesting_tree does
Assignee: unassigned at gcc dot gnu.org
Reporter: andi-gcc at firstfloor dot org
gcc version 4.9.0 20140209 (experimental) (GCC)
gcc -fcilkplus test.c
cilk.c: In function 'main':
tcilk.c:14:5: internal compiler error: Segmentation fault
int main()
^
0x8a5df7 crash_signal
Assignee: unassigned at gcc dot gnu.org
Reporter: andi-gcc at firstfloor dot org
The LTO symbol table read by the linker plugin does not contain static symbols.
This is fine for the linker, but changes behavior of gcc-nm (which also uses
the linker plugin) drastically. Normally nm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56912
--- Comment #6 from Andi Kleen andi-gcc at firstfloor dot org ---
Seems to be fixed.
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: andi-gcc at firstfloor dot org
On x86_64-linux
Works without --enable-gather-detailed-mem-stats
make[2]: *** [compare] Error 1
make[1]: *** [stage3-bubble] Error 2
make: *** [all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56912
Bug #: 56912
Summary: scheduler change breaks linux kernel LTO build with
4.8
Classification: Unclassified
Product: gcc
Version: unknown
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53315
Andi Kleen andi-gcc at firstfloor dot org changed:
What|Removed |Added
Status|NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56619
Andi Kleen andi-gcc at firstfloor dot org changed:
What|Removed |Added
Status|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56618
Bug #: 56618
Summary: inline assembler with too many lines causes ICE in
account_size_time, at ipa-inline-analysis.c
Classification: Unclassified
Product: gcc
Version:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56619
Bug #: 56619
Summary: i386 hle atomic intrinsics flags are undocumented
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56619
--- Comment #1 from Andi Kleen andi-gcc at firstfloor dot org 2013-03-14
13:18:32 UTC ---
This is a more complete version of the documentation (also including RTM
intrinsics), again not approved:
http://patchwork.ozlabs.org/patch/211504/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55947
--- Comment #3 from Andi Kleen andi-gcc at firstfloor dot org 2013-03-13
13:49:10 UTC ---
It was pointed out to me that atomic triggers this with, when compiled with no
optimization. For HLE wrong hints would be generated.
bool
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55948
Andi Kleen andi-gcc at firstfloor dot org changed:
What|Removed |Added
Status|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50584
Andi Kleen andi-gcc at firstfloor dot org changed:
What|Removed |Added
CC||andi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55233
--- Comment #2 from Andi Kleen andi-gcc at firstfloor dot org 2013-01-21
01:22:14 UTC ---
Oops typo, I'll fix the ChangeLog
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55966
--- Comment #1 from Andi Kleen andi-gcc at firstfloor dot org 2013-01-14
19:06:02 UTC ---
Here's a test case. This requires the libstdc++ HLE patch from
http://gcc.gnu.org/ml/gcc-patches/2013-01/msg00673.html
g++ -std=gnu++0x
#include
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55966
--- Comment #2 from Andi Kleen andi-gcc at firstfloor dot org 2013-01-14
19:52:03 UTC ---
Created attachment 29163
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29163
preprocessed testcase
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55966
Andi Kleen andi-gcc at firstfloor dot org changed:
What|Removed |Added
Attachment #29163|0 |1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55966
--- Comment #6 from Andi Kleen andi-gcc at firstfloor dot org 2013-01-14
22:05:38 UTC ---
Hmm that's true. x86 doesn't have xand, x_or, x_xor, only xadd
Maybe cmpxchg is the only way?
For some special cases it can be done (like
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55966
--- Comment #8 from Andi Kleen andi-gcc at firstfloor dot org 2013-01-14
22:32:06 UTC ---
forbid = give warning and drop bit
It's a hint, but in a good implementation it should not be silently dropped or
code generated that has no chance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17886
--- Comment #25 from Andi Kleen andi-gcc at firstfloor dot org 2013-01-14
22:32:59 UTC ---
Also i need to look more closely, but most likely the C++ atomic code should be
changed to avoid this situation. This would give much better code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55966
--- Comment #9 from Andi Kleen andi-gcc at firstfloor dot org 2013-01-14
22:34:16 UTC ---
Also i need to look more closely, but most likely the C++ atomic code should be
changed to avoid this situation. This would give much better code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17886
--- Comment #26 from Andi Kleen andi-gcc at firstfloor dot org 2013-01-14
22:37:34 UTC ---
Sorry commented on the wrong bug. ignore.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55966
Bug #: 55966
Summary: __atomic_fetch_* generate wrong code for HLE
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55947
Bug #: 55947
Summary: non constant memory models lose HLE qualifiers
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55948
Bug #: 55948
Summary: __atomic_clear / __atomic_store_n ignore HLE_RELEASE
flags
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55947
--- Comment #2 from Andi Kleen andi-gcc at firstfloor dot org 2013-01-11
22:01:49 UTC ---
I would probably add at least a warning. The whole concept of a runtime
switched memory barrier is imho ill-defined.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55461
--- Comment #2 from Andi Kleen andi-gcc at firstfloor dot org 2012-11-25
18:07:49 UTC ---
That's a design not matching the hardware then -- read up on reformatting
penalties.
Also the way the rule in the md file is written it more looks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55461
Andi Kleen andi-gcc at firstfloor dot org changed:
What|Removed |Added
Status|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55461
Bug #: 55461
Summary: _mm_loadu_si128 generates wrong instruction on 4.8
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55139
--- Comment #4 from Andi Kleen andi-gcc at firstfloor dot org 2012-11-09
14:06:20 UTC ---
My earlier analysis was not correct. I was chasing the wrong warning.
Rather the problem is in c-common.c, where the atomic models are checked again
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55233
Bug #: 55233
Summary: libstdc++ atomic does not support hle_acquire/release
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55139
--- Comment #3 from Andi Kleen andi-gcc at firstfloor dot org 2012-11-07
14:45:17 UTC ---
I saw the problem both with bootstrapped and non bootstrapped (4.6 base)
compilers
I haven't checked if it's always the missing and, but it's likely
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55139
--- Comment #1 from Andi Kleen andi-gcc at firstfloor dot org 2012-11-07
04:03:53 UTC ---
This is an interesting one. This is the gcc code:
enum memmodel
{
MEMMODEL_RELAXED = 0,
MEMMODEL_CONSUME = 1,
MEMMODEL_ACQUIRE = 2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55139
Bug #: 55139
Summary: __atomic store does not support __ATOMIC_HLE_RELEASE
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55066
Andi Kleen andi-gcc at firstfloor dot org changed:
What|Removed |Added
Status|WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54095
--- Comment #14 from Andi Kleen andi-gcc at firstfloor dot org 2012-10-25
14:20:31 UTC ---
Is there a chance to fix this in 4.8? What remains to be done?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55066
Bug #: 55066
Summary: lto integer-cst change causes ICE
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54206
--- Comment #5 from Andi Kleen andi-gcc at firstfloor dot org 2012-10-04
18:50:52 UTC ---
This is the configure snippet glibc is using for this.
Someone with better autoconf-fu than me could add it
if test `cd $srcdir; /bin/pwd
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54206
--- Comment #2 from Andi Kleen andi-gcc at firstfloor dot org 2012-08-09
12:39:14 UTC ---
I didn't do it, but I had to debug a user's gcc config who did it.
WONTFIX would be wrong, if you really don't support it error out in configure
please
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54206
Bug #: 54206
Summary: build in source dir breaks lto plugin detection
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54095
Andi Kleen andi-gcc at firstfloor dot org changed:
What|Removed |Added
CC||andi-gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53831
--- Comment #21 from Andi Kleen andi-gcc at firstfloor dot org 2012-07-04
12:24:45 UTC ---
For non fat (slim) LTO builds you need to use these tools yes. ar needs to
know the symbol table for its index and that needs LTO specific knowledge
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53404
Andi Kleen andi-gcc at firstfloor dot org changed:
What|Removed |Added
Component|c |preprocessor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53404
Bug #: 53404
Summary: warning column reported on comment in warning during
bootstrap
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53315
--- Comment #14 from Andi Kleen andi-gcc at firstfloor dot org 2012-05-12
16:04:27 UTC ---
I can confirm the simple test program works correctly with Jakub's patch.
I'll leave full bootstrap to HJ.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53315
--- Comment #15 from Andi Kleen andi-gcc at firstfloor dot org 2012-05-12
16:06:00 UTC ---
Oh yes and it would be really nice to have those peepholes for xbegin Jakub.
I normally use my own macros with asm goto to avoid the ugly code.
Do you
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53315
--- Comment #8 from Andi Kleen andi-gcc at firstfloor dot org 2012-05-11
18:02:43 UTC ---
I tested HJs fix on the test case and also on a more complex program and it all
works as expected. Please commit.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53315
--- Comment #9 from Andi Kleen andi-gcc at firstfloor dot org 2012-05-11
21:35:47 UTC ---
Sorry I was wrong earlier. Retested now fully with a full test case and HJs
patch and i always get aborts
The xbegin gets miscompiled now
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53315
Bug #: 53315
Summary: simple xtest program generates ICE
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53315
Andi Kleen andi-gcc at firstfloor dot org changed:
What|Removed |Added
CC||kirill.yukhin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53291
--- Comment #6 from Andi Kleen andi-gcc at firstfloor dot org 2012-05-10
22:52:30 UTC ---
Uros patch fixes it and the code is correct now. Please commit.
However in testing it I quickly hit PR53315
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53291
--- Comment #9 from Andi Kleen andi-gcc at firstfloor dot org 2012-05-11
03:36:11 UTC ---
The example in PR53315 is a runtime test case, except:
- it needs cpuid checks to be part of the test suite
- the printfs need to be replaced with asserts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53291
--- Comment #3 from Andi Kleen andi-gcc at firstfloor dot org 2012-05-09
17:17:56 UTC ---
Correction. We can keep the xor %reg,%reg. We just need it because setnz only
sets 8 bit to initialize the higher order bits.
Alternatively the value can
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50602
--- Comment #17 from Andi Kleen andi-gcc at firstfloor dot org 2012-05-03
14:57:13 UTC ---
Hmm, my assumption was always that this option would be passed through and then
used by lto1 step. That's true for other -f* options at least.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50602
--- Comment #13 from Andi Kleen andi-gcc at firstfloor dot org 2012-05-02
14:23:57 UTC ---
This still happens with a recent 4.7 and bites 32bit Linux kernel builds badly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53126
--- Comment #4 from Andi Kleen andi-gcc at firstfloor dot org 2012-05-02
20:04:50 UTC ---
Patch looks good. Thanks Jakub.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52762
Andi Kleen andi-gcc at firstfloor dot org changed:
What|Removed |Added
CC||andi-gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50602
--- Comment #12 from Andi Kleen andi-gcc at firstfloor dot org 2012-01-08
01:37:29 UTC ---
LTO saves the options in the object files and collects them for the final
link. This works as far as I know.
The only thing it cannot handle is different
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51417
--- Comment #2 from Andi Kleen andi-gcc at firstfloor dot org 2011-12-07
18:54:57 UTC ---
Hmm, you mean a copy with the version number in addition? Would be reasonable I
guess.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50602
--- Comment #10 from Andi Kleen andi-gcc at firstfloor dot org 2011-11-23
00:22:46 UTC ---
FWIW the problem is still there and prevents any 32bit kernel LTO builds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51109
Bug #: 51109
Summary: bdver1 scheduler state machine too large
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50602
--- Comment #9 from Andi Kleen andi-gcc at firstfloor dot org 2011-10-30
15:53:10 UTC ---
Sorry made a mistake and i supplied the wrong command line
With this
gcc47 -O2 -m32-freg-struct-return io_apic.i -flto -c
gcc47 -O2 -flto io_apic.o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49934
Andi Kleen andi-gcc at firstfloor dot org changed:
What|Removed |Added
CC||andi-gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49677
Andi Kleen andi-gcc at firstfloor dot org changed:
What|Removed |Added
CC||andi-gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644
--- Comment #14 from Andi Kleen andi-gcc at firstfloor dot org 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50602
--- Comment #7 from Andi Kleen andi-gcc at firstfloor dot org 2011-10-29
12:12:09 UTC ---
Created attachment 25659
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25659
reproducer
Managed to minimize now
Unpack the tar file and on x86-64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45631
--- Comment #3 from Andi Kleen andi-gcc at firstfloor dot org 2011-10-30
02:33:29 UTC ---
Honza, any further ideas how to proceed? Should the threshold just be lowered?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50824
Bug #: 50824
Summary: memset or memcpy on structure prevents SRA
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644
--- Comment #9 from Andi Kleen andi-gcc at firstfloor dot org 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644
--- Comment #11 from Andi Kleen andi-gcc at firstfloor dot org 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 #13 from Andi Kleen andi-gcc at firstfloor dot org 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50786
--- Comment #2 from Andi Kleen andi-gcc at firstfloor dot org 2011-10-19
14:40:53 UTC ---
I'm not 100% sure which stage generates them, but I have lots of
cc*.o and some others (.res etc.) left over after the LTRANS failure.
After two failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50786
--- Comment #4 from Andi Kleen andi-gcc at firstfloor dot org 2011-10-19
15:28:07 UTC ---
I'm not, this was a normal lto bootstrap without any special flags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50636
Andi Kleen andi-gcc at firstfloor dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644
--- Comment #7 from Andi Kleen andi-gcc at firstfloor dot org 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50783
Bug #: 50783
Summary: builtin c++ demanger does not handle clones
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50786
Bug #: 50786
Summary: temporary files not cleaned up on LTO errors
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644
--- Comment #5 from Andi Kleen andi-gcc at firstfloor dot org 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=50679
Bug #: 50679
Summary: Linux kernel LTO tracking bug
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
201 - 300 of 483 matches
Mail list logo
