Assignee: unassigned at gcc dot gnu.org
Reporter: andi-gcc at firstfloor dot org
When I boot a current Linux mainline kernel compiled with mainline gcc
and the section fix patch applied I always get a crash at boot in the block
layer.
gcc version 5.0.0 20140926 (experimental
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63404
--- Comment #1 from Andi Kleen ---
Created attachment 33607
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33607&action=edit
not quite yet runnable test case
In the real execution blk_flush_complete_seq always ends up in the default case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63404
Andi Kleen changed:
What|Removed |Added
Component|middle-end |target
--- Comment #2 from Andi Kleen ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61898
Andi Kleen changed:
What|Removed |Added
CC||andi-gcc at firstfloor dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63450
Andi Kleen changed:
What|Removed |Added
CC||andi-gcc at firstfloor dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61898
--- Comment #4 from Andi Kleen ---
The patch has several issues (making it currently fail bootstrap):
- it warns for vfprintf too (fixed)
- on i386 it gets confused between va_list * and char *, so something like
char *format;
char buf[100];
p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63462
Andi Kleen changed:
What|Removed |Added
CC||andi-gcc at firstfloor dot org
--- Comment
: unassigned at gcc dot gnu.org
Reporter: andi-gcc at firstfloor dot org
sstream is very slow. Comparing two simple programs that parse a stream with C
and with sstream. The sstream version is an order of magnitude slower.
gcc version 4.9.1 20140423 (prerelease) (GCC)
# C++
% time
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: andi-gcc at firstfloor dot org
Currently any inline asm statement in a loop prevents vectorization, like
#define N 100
int a[N], b[N], c[N];
main()
{
int i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63467
--- Comment #2 from Andi Kleen ---
It's the same with asm("" :::);
At least the vectorizer bombs out on any asm.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63467
--- Comment #6 from Andi Kleen ---
For the marker case it's enough if it just stays in the same position in the
basic block and does get duplicated if the BB gets too.
That's somewhat special semantics, that is why I think it would need some way
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63466
--- Comment #2 from Andi Kleen ---
Looking at the profile there's plenty of room for optimization. e.g. not using
getc/ungetc, but directly accessing the buffer, or maybe even some kind of
template specialization.
With the variables pulled out i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61969
--- Comment #6 from Andi Kleen ---
I looked at this a bit more. It's definitely the nrv pass that causes the
problem.
When I disable it in the source code the 32bit version compiles correctly.
I also tried disabling the next pass (cfgcleanup), b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61969
--- Comment #9 from Andi Kleen ---
Patch fixes the test case.
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: andi-gcc at firstfloor dot org
Target Milestone: ---
gcc -v --help does not output all the possible options for -mtune=/-march=
For example corei7-avx is missing for arch, which is Sandy Bridge. tune is also
mising
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66229
--- Comment #2 from Andi Kleen ---
Some analysis of the problem:
At the time cc1 is streaming out profile_data it is not set to anything in
autofdo. So the LTO files contain all 0 profile data, which later causes the
ICE here.
Seems to be some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28901
Andi Kleen changed:
What|Removed |Added
CC||andi-gcc at firstfloor dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28901
--- Comment #17 from Andi Kleen ---
There were a few false or useless ones (e.g. related to macros and specific
build configs). I didn't look through them all, but various were semi
legitimate, but also very minor (small) so fixing it won't help
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: andi-gcc at firstfloor dot org
Target Milestone: ---
Consider this simple example:
volatile int count;
int main()
{
int i;
for (i = 0; i < 10; i++) {
if (i ==
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66890
--- Comment #1 from Andi Kleen ---
The problem seems to be that
bb-reorder.c:find_rarely_executed_basic_blocks_and_crossing_edges
returns no edges without profile feedback, which prevents generation of a
section split note.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66890
--- Comment #2 from Andi Kleen ---
Created attachment 35993
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35993&action=edit
Potential patch
This patch fixes the problem for my simple test case. It adds a fall back path
to the partition c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66890
--- Comment #3 from Andi Kleen ---
I suspect the patch may be too simple because it could get stuck in unlikely,
but high frequency edges in the cold area. Perhaps need to adapt more of the
code of the non partitioning reordering
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66890
--- Comment #4 from Andi Kleen ---
Created attachment 36008
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36008&action=edit
Updated patch with documentation and param
I updated the patch with proper documentation and a param for the cut o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50676
--- Comment #6 from Andi Kleen ---
The patch doesn't seem to be checked in yet. Is there a reason for that?
ux kernel BUILD_BUG_ON() broke
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andi-gcc at firstfloor dot org
GCC build tr
--- Comment #1 from andi-gcc at firstfloor dot org 2009-12-20 00:54 ---
Created an attachment (id=19352)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19352&action=view)
preprocessed file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42439
perimental) (GCC)
--
Summary: lto segfaults
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andi-gcc at firstfloor do
--- Comment #1 from andi-gcc at firstfloor dot org 2009-12-20 02:26 ---
Created an attachment (id=19353)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19353&action=view)
object files for lto
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42441
tion
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andi-gcc at firstfloor dot org
GCC host triplet: x86_64-linux
GCC target triplet: x86_64-linux -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42585
ONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andi-gcc at firstfloor dot org
GCC host triplet: x86_64-linux
GCC target triplet: x86_64-linux -m32
http://gcc.gnu.org/
iority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andi-gcc at firstfloor dot org
GCC host triplet: x86_64-linux
GCC target triplet: x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42587
MED
Severity: enhancement
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andi-gcc at firstfloor dot org
GCC host triplet: x86_64-linux
GCC target triplet: x86_64-linux -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi
IRMED
Severity: enhancement
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andi-gcc at firstfloor dot org
GCC host triplet: x86_64-linux
GCC target triplet: x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42589
--- Comment #7 from andi-gcc at firstfloor dot org 2010-01-03 06:55 ---
This bug was not about the unnecessary stack frame, but about unnecessary
read-modify-write
(it seems you didn't read my description completely)
For stack frame probably another bug should be opened. I can do
me set up
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andi-gcc at firstfloor dot org
GCC host triplet
--- Comment #9 from andi-gcc at firstfloor dot org 2010-01-03 07:00 ---
SRA issue handled in #42590
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42586
--- Comment #11 from andi-gcc at firstfloor dot org 2010-01-03 07:03
---
My naive assumption was that the read-modify-write pattern is handled late by
the RTL backend when generating instructions while SRA is somewhere early in
the tree oriented middle end.
--
http://gcc.gnu.org
--- Comment #15 from andi-gcc at firstfloor dot org 2010-01-03 07:47
---
As an addendum the unnecessary stack frame seems to be a very common problem,
it's in a lot of the examples near the end of
http://embed.cs.utah.edu/embarrassing/dec_09/harvest/gcc-head_suncc-5.10/
typi
y: really bad register allocation for x86
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andi-gcc at first
--- Comment #17 from andi-gcc at firstfloor dot org 2010-01-03 08:12
---
Nope, the examples all disable frame pointer
(the first version of the tester had this problem, but that was fixed)
It's all not frame pointer set up anyways, but sub $...,%esp ... ; add
$...,%esp
with no u
Summary: no store merging for structure stores
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
R
--- Comment #5 from andi-gcc at firstfloor dot org 2010-01-03 13:11 ---
I would expect two bswaps yes, like llvm generates
I also can't see how this should be a bad idea for any target with a bswap
like operation (unless it's 64bit)
--
http://gcc.gnu.org/bugzilla/show_
--- Comment #19 from andi-gcc at firstfloor dot org 2010-01-03 13:18
---
Here's another example with the bogus stack frame problem with a tail call
(the embarassing website has quite a lot of similar cases, normally
near the tail of the tables with 16 vs 22 bytes e.g. against s
--- Comment #2 from andi-gcc at firstfloor dot org 2010-01-03 15:40 ---
An obvious improvement would be to use the non callee clobbered registers
as temporal storage, instead of putting into registers that just get spilled
again. I think one of the other compilers in the comparison
did
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48952
Summary: ICE in inline_merge_summary during linux kernel LTO
build
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48952
--- Comment #1 from Andi Kleen 2011-05-10
16:37:17 UTC ---
Some more information from gdb. So it follows some pointer in the VEC
that is NULL
(gdb) p edge
$1 = (struct cgraph_edge *) 0x7f1ce05d90d0
(gdb) p edge->uid
$2 = 38701
(gdb) disp/3i $pc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48952
--- Comment #2 from Andi Kleen 2011-05-10
20:49:28 UTC ---
I uploaded a (large) test case to
http://firstfloor.org/~andi/lto-kernel.tar.bz2
Run R2 in the directory after pointing the script to the right gcc binary.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48978
Summary: excessive hash table allocation for large lto build
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
AssignedTo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48978
--- Comment #2 from Andi Kleen 2011-05-12
16:16:19 UTC ---
I will try.
BTW this was a much larger test case (allyesconfig), the tarball I sent you
is a much more limited config.
Normally noone uses allyesconfig kernels (they barely boot), but t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48978
--- Comment #3 from Andi Kleen 2011-05-12
16:22:30 UTC ---
looks like the revert is really needed, i just ran out of memory
even on the small config on the large memory system.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48978
Andi Kleen changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|FIXED
D
Severity: normal
Priority: P3
Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andi-gcc at firstfloor dot org
GCC host triplet: x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44965
--- Comment #1 from andi-gcc at firstfloor dot org 2010-07-16 23:07 ---
One way to solve this would be to use a hash of the option table as a version
number.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44965
LTO with gold causes ICE in
lto_symtab_merge_decls_1
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
Re
--- Comment #1 from andi-gcc at firstfloor dot org 2010-07-16 23:23 ---
Created an attachment (id=21228)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21228&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44966
--- Comment #3 from andi-gcc at firstfloor dot org 2010-07-16 23:58 ---
It's not only development versions, options can change between minor releases
Also I don't think LTO_major/minor is always increased anyways.
Why should a hash over the option table not work?
IRMED
Severity: normal
Priority: P3
Component: driver
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andi-gcc at firstfloor dot org
GCC host triplet: x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44986
t org
ReportedBy: andi-gcc at firstfloor dot org
GCC host triplet: x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44987
--- Comment #3 from andi-gcc at firstfloor dot org 2010-07-19 15:47 ---
HJ, are you saying that target("sse4.2") is broken too (seems to work here in
simple tests?) or just that some target sub options are broken?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44987
: unassigned at gcc dot gnu dot org
ReportedBy: andi-gcc at firstfloor dot org
GCC host triplet: x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44992
--- Comment #2 from andi-gcc at firstfloor dot org 2010-07-19 16:31 ---
Not sure I understand the comment.
The case I've been looking at is ld -r (without a LTO code generation stage)
to combine existing object and then using gold for the final linking/LTO code
generation based o
--- Comment #4 from andi-gcc at firstfloor dot org 2010-07-19 19:13 ---
The test case works, but my big project now crashes with
758 prevailing->node->local.used_from_object_file = false;
(gdb) p prevailing->vnode
$1 = (struct varpool_node *) 0x0
I thi
--- Comment #4 from andi-gcc at firstfloor dot org 2010-07-19 19:46 ---
This is actually what I tried first, but it turned out to be quite complicated,
had to change a lot of code and my patch was growing and growing and it didn't
fit clearly with the different readers etc.
That i
--- Comment #7 from andi-gcc at firstfloor dot org 2010-07-20 00:23 ---
Thanks. Unfortunately with that patch I still get the same ICE:
758 prevailing->node->local.used_from_object_file = false;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44966
--- Comment #9 from andi-gcc at firstfloor dot org 2010-07-20 10:15 ---
I ignored all nodes with NULL node/vnode now as
you suggested and get much further.
It takes a lot of memory in multiple lto1 runs (>2GB in some cases)
Then after a long time I have a new ICE in the garb
--- Comment #10 from andi-gcc at firstfloor dot org 2010-07-20 12:36
---
I hacked around the GC problem by ignoring the NULL pointer here.
It works now when I disable vma randomization, if i keep it enabled it
crashes occasionally.
Main issue is that it uses a lot of memory now
--- Comment #11 from andi-gcc at firstfloor dot org 2010-07-20 20:39
---
Some more debugging on the gc crash, suggested by honza:
The corruption seems to happen in cgraph_hash
(gdb) p *x
$2 = {hash_f = 0x827750 , eq_f = 0x827760 , del_f = 0,
entries = 0x7f67b734c000, size = 262139
--- Comment #13 from andi-gcc at firstfloor dot org 2010-07-21 15:21
---
I know I lost some assembler files, but I think I didn't lose all of them.
Some assembler code is still there. Any suggestion how to fix this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44966
--- Comment #15 from andi-gcc at firstfloor dot org 2010-07-27 06:56
---
I'm working on a solution for the lost code problem. It will require
-ffunction/data-sections so that it can be undone section by section.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44966
efile does not enable instrumentation
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andi-gcc at firstfloor do
--- Comment #8 from andi-gcc at firstfloor dot org 2010-08-31 09:32 ---
Sorry this is not fixed yet, only partially. Still working on the last bits,
in particular passthrough of non LTOed code like assembler functions.
--
andi-gcc at firstfloor dot org changed:
What
se in libcpp breaks LTO bootstrap
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andi-gcc at firstfloor dot org
GCC
se in libcpp breaks LTO bootstrap
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andi-gcc at firstfloor dot org
GCC
--- Comment #1 from andi-gcc at firstfloor dot org 2010-09-01 10:14 ---
Working on a fix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45477
--- Comment #2 from andi-gcc at firstfloor dot org 2010-09-01 10:15 ---
Yes, I have most of a patch already, but will add the check value.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45475
--- Comment #3 from andi-gcc at firstfloor dot org 2010-09-01 10:36 ---
*** Bug 45477 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45475
--- Comment #2 from andi-gcc at firstfloor dot org 2010-09-01 10:36 ---
*** This bug has been marked as a duplicate of 45475 ***
--
andi-gcc at firstfloor dot org changed:
What|Removed |Added
--- Comment #5 from andi-gcc at firstfloor dot org 2010-09-01 17:05 ---
Patch fixing it went in
--
andi-gcc at firstfloor dot org changed:
What|Removed |Added
--- Comment #6 from andi-gcc at firstfloor dot org 2010-09-02 07:01 ---
Cannot reproduce this anymore with the latest changes.
--
andi-gcc at firstfloor dot org changed:
What|Removed |Added
for function pointers
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andi-gcc at firstfloor dot org
d at gcc dot gnu dot org
ReportedBy: andi-gcc at firstfloor dot org
GCC host triplet: x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45632
--- Comment #1 from andi-gcc at firstfloor dot org 2010-09-10 08:50 ---
Created an attachment (id=21763)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21763&action=view)
testcase, compiled with -O3
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45632
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45871
Summary: lto bootstrap miscompiles expmed.c1
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig..
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46055
--- Comment #6 from Andi Kleen 2010-10-17
22:28:09 UTC ---
Could simply mark the variable volatile?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46176
Summary: profile feedback causes 20% linux kernel binary growth
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46176
--- Comment #2 from Andi Kleen 2010-10-26
08:01:01 UTC ---
Thanks.
Unrolling seems to be part of it, but not all. I rebuilt/retrained with
-fno-unroll-loops
Trained:
textdata bss dec hex filename
127744891198572 13576
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46176
--- Comment #3 from Andi Kleen 2010-10-26
10:28:34 UTC ---
Interesting tidbit: the file containing r600_kms_blit_copy -- which grew most
--
didn't get any profile feedback during training, there was no data file.
I generated lists and cgraph ipa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45475
Andi Kleen changed:
What|Removed |Added
Status|RESOLVED|NEW
Resolution|FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46812
Summary: Linux libgo compilation fails when a "libnet" is
already installed
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46812
--- Comment #1 from Andi Kleen 2010-12-05
22:58:12 UTC ---
BTW I specified a different prefix than /usr, so libtool looked into the wrong
directory anyways here.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46812
Andi Kleen changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46812
Andi Kleen changed:
What|Removed |Added
Status|RESOLVED|VERIFIED
--- Comment #7 from Andi Kleen 201
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46905
Summary: -flto -fno-lto does not disable lto
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
AssignedTo: unassig...@gcc.g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46905
--- Comment #1 from Andi Kleen 2010-12-12
14:19:00 UTC ---
Same bug seems to be in the code generating phase
gcc -O2 -flto -fno-lto object.o
does code generation even if object.o has fallback code
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andi-gcc at firstfloor dot org
GCC host triplet: x86_64-linux
GCC ta
--- Comment #1 from andi-gcc at firstfloor dot org 2010-05-13 13:44 ---
Hmm sorry actually it stepped over everything except the last iteration.
Still unexpected
--
andi-gcc at firstfloor dot org changed:
What|Removed |Added
--- Comment #3 from andi-gcc at firstfloor dot org 2010-05-13 16:16 ---
I think it should describe multiple lines.
next is expected to iterate through loops, not skip them.
If I wanted to skip I would use "until"
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44113
--- Comment #6 from andi-gcc at firstfloor dot org 2010-05-19 15:40 ---
Jakub, are you saying this should be fixed in gdb?
How could gdb detect this case?
If gcc emitted another .loc like you said couldn't gdb check for this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44113
Severity: normal
Priority: P3
Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andi-gcc at firstfloor dot org
GCC host triplet: x86_64-linux
GCC target triplet: x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44463
to
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andi-gcc at firstfloor dot org
GCC host triplet: x86_64-linux
GCC target triplet: x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44464
301 - 400 of 592 matches
Mail list logo
