--- Comment #23 from andi-gcc at firstfloor dot org 2010-06-19 13:13
---
It's two instructions with some metadata that controls patching these
instructions depending on the CPU capabilities.
Detecting that for gcc would be likely hard.
What would have also prevented this problem
--- Comment #16 from andi-gcc at firstfloor dot org 2010-06-18 21:11
---
This turned out to be a kernel bug, rdtsc_barrier() needed to be marked
__force_inline, otherwise gcc would not inline this function.
(although it's slightly fishy for gcc too not inline a function that
only has
--- Comment #19 from andi-gcc at firstfloor dot org 2010-06-11 17:09
---
Sorry you need -nostdlib too (forgot that)
-r is immediate linking
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44464
--- Comment #1 from andi-gcc at firstfloor dot org 2010-06-10 12:22 ---
I noticed that setting -fwhole-program on both compile and link stage
makes the weak problem go away. Expected?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44463
--- Comment #3 from andi-gcc at firstfloor dot org 2010-06-10 12:58 ---
On the link stage it's apparently not ignored and it fixes the weak
problem.
So just whatever weak magic -fwhole-program does would need to be done
when it's not enabled too.
--
http://gcc.gnu.org/bugzilla
--- Comment #16 from andi-gcc at firstfloor dot org 2010-06-10 13:20
---
I reduced another of my ICEs from this build and it's in the same place.
(gdb) bt
#0 var_map_base_init (map=0x10abe60) at ../../gcc/gcc/tree-ssa-live.c:87
#1 0x007248fb in coalesce_ssa_name
--- Comment #17 from andi-gcc at firstfloor dot org 2010-06-10 13:21
---
Created an attachment (id=20882)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20882action=view)
other test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44464
builds
Product: gcc
Version: 4.6.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 host
--- Comment #3 from andi-gcc at firstfloor dot org 2010-06-09 10:13 ---
Sorry my example was not very good.
Anyways this typically happens with #ifdefs, so the some ifdef path
is actually using the variable, it's just not enabled in the current build.
In theory the ifdefs could be put
--- Comment #4 from andi-gcc at firstfloor dot org 2010-06-09 10:55 ---
I was told that the whopr link step would inherit the optimization
flags from the build step. Is that not true?
Here's a reduced test case with only a single input file (reduced too)
gcc46 -O2 -fwhopr -c
--- Comment #5 from andi-gcc at firstfloor dot org 2010-06-09 10:56 ---
Created an attachment (id=20875)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20875action=view)
reduced input file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44464
--- Comment #5 from andi-gcc at firstfloor dot org 2010-06-09 11:08 ---
Hmm yes there was another temporary and a inline inbetween
unsigned inlinefunc(void)
{
unsigned var;
asm( ... : =r (var));
return var;
}
#define macro(x,y)
{
unsigned var = inlinefunc();
x = var;
y
--- Comment #3 from andi-gcc at firstfloor dot org 2010-06-09 11:09 ---
Jakub, for this example: how would you suggest to work around this warning?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16427
--- Comment #16 from andi-gcc at firstfloor dot org 2010-06-09 11:21
---
I don't need a backport to 4.4 and I double checked it works as expected
in gcc 4.5. Closing.
--
andi-gcc at firstfloor dot org changed:
What|Removed |Added
--
andi-gcc at firstfloor dot org changed:
What|Removed |Added
Status|WAITING |UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44464
--- Comment #9 from andi-gcc at firstfloor dot org 2010-06-09 12:16 ---
Unfortunate. Fixing that in the makefiles would be major effort for all the -f
and -m flags, which sometimes vary by target.
I thought LTO was designed to minimize makefile changes?
--
http://gcc.gnu.org
--- Comment #10 from andi-gcc at firstfloor dot org 2010-06-09 12:18
---
The tree input that leads to the NULL annotation is a error_mark
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44464
--- Comment #13 from andi-gcc at firstfloor dot org 2010-06-09 13:35
---
What happens then when some files need different options that other files?
This sounds more and more like a showstopper if you're right.
I was not prepared to redesign the Makefiles
--
http://gcc.gnu.org
--- Comment #14 from andi-gcc at firstfloor dot org 2010-06-09 13:42
---
I found this code in lto.c which seems to disagree:
/* Read the options saved from each file in the command line. Called
from lang_hooks.post_options which is called by process_options
right before all
--- Comment #15 from andi-gcc at firstfloor dot org 2010-06-09 13:55
---
Ok seems it does not do what I want:
FIXME lto. Currently the scheme is limited in that only the
options saved on the first object file (f1.o) are read back during
the link step. This means
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
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
--- Comment #1 from andi-gcc at firstfloor dot org 2010-06-08 09:38 ---
Ok unable to attach and I've been told reporting LTO bugs requires some magic
voodoo incarnations first.
If it helps here's the gdb information of the crash:
(gdb) pt var
error_mark 0x1200022
(gdb) bt
#0
--- Comment #2 from andi-gcc at firstfloor dot org 2010-06-08 09:40 ---
The object files are at http://halobates.de/whopr-ice.tar.bz2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44464
--- 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
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 target triplet: x86_64-linux
http://gcc.gnu.org
--- 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
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=42592
--- 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 use
: 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
ReportedBy: andi-gcc
--- 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_bug.cgi?id
--- 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 sun cc
--- 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
: 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
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/bugzilla
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
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?id
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
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: x86_64-linux
GCC target triplet: x86_64
--- 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/
typically
() 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 triplet: x86_64-linux
--- 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=19352action=view)
preprocessed file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42439
)
--
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 dot org
GCC build
--- 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=19353action=view)
object files for lto
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42441
--- Comment #1 from andi-gcc at firstfloor dot org 2009-10-05 14:04 ---
Created an attachment (id=18710)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18710action=view)
tlto1.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41589
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 dot org
GCC host triplet: x86_64-linux
GCC target triplet
--- Comment #2 from andi-gcc at firstfloor dot org 2009-10-05 14:04 ---
Created an attachment (id=18711)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18711action=view)
tlto2.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41589
--- Comment #3 from andi-gcc at firstfloor dot org 2009-10-05 14:04 ---
Created an attachment (id=18712)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18712action=view)
Makefile.lto
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41589
and -
fwhole-program
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 dot org
GCC host
--- Comment #6 from andi-gcc at firstfloor dot org 2009-10-05 15:42 ---
I use binutils 2.19 (from opensuse 11.1).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41589
--- Comment #4 from andi-gcc at firstfloor dot org 2009-08-07 08:50 ---
The RTL loop optimizer does this optimization. I had to fix it a couple
of years ago for unsigned variables.
I think the loop optimizer still does it, just the gcc 4 frontend doesn't
give it input RTL
--- Comment #6 from andi-gcc at firstfloor dot org 2009-08-07 09:38 ---
It worked on x86 at least
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40886
--- Comment #8 from andi-gcc at firstfloor dot org 2009-08-07 09:52 ---
At least my example in the original bug description shows that the optimization
worked on gcc 3.3. If your theory doesn't explain this then your theory is
wrong.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
: regression
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=40886
Status: UNCONFIRMED
Severity: normal
Priority: 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
--- Comment #1 from andi-gcc at firstfloor dot org 2008-09-01 11:22 ---
Created an attachment (id=16178)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16178action=view)
test case
checksum functions extracted from the Linux kernel.
Not preprocessed, but should compile on any x86
--- Comment #3 from andi-gcc at firstfloor dot org 2008-09-01 14:20 ---
Thanks for the us^whelpful comment. If you can suggest a way to do carry
preserving addition without inline assembler that would be fine, otherwise not.
-Os seems to do something that improves it at least
--- Comment #1 from hp at gcc dot gnu dot org 2008-08-29 16:02 ---
(In reply to comment #0)
I attached a preprocessed test case.
Where?
--- Comment #2 from andi-gcc at firstfloor dot org 2008-08-29 16:02 ---
Created an attachment (id=16164)
-- (http://gcc.gnu.org/bugzilla
401 - 462 of 462 matches
Mail list logo
