On 12/14/2009 09:31 PM, John Regehr wrote:
Ok, thanks for the feedback Andi. Incidentally, the LLVM folks seem to
agree with both of your suggestions. I'll re-run everything w/o frame
pointers and ignoring testcases where some compiler warns about use of
uninitialized local. I hate the way
On Dec 15, 2009, at 12:28 AM, Paolo Bonzini wrote:
On 12/14/2009 09:31 PM, John Regehr wrote:
Ok, thanks for the feedback Andi. Incidentally, the LLVM folks seem to
agree with both of your suggestions. I'll re-run everything w/o frame
pointers and ignoring testcases where some compiler
HI,
Can I get an array's offset from the stack point at pass-sched?
thanks
--
Jianzhang Peng
I also wonder if you have something like LTO enabled.
No, he doesn't enable LLVM LTO. Even if it did, LTO wouldn't touch
the 'CC1000SendReceiveP*' definitions because they are not static
(unless he explicitly built with an export map).
Interesting.
I haven't analyzed what is going on in
Hi!
You didn't what target you are using. Pentium D can run both 32bit
and 64bit. codes.
This was done with 32bit code. I have opened PR 42376 describing
the issue and added some more information.
Cheers,
Martin
On Mon, 2009-12-14 at 19:18 +0100, Thomas Schwinge wrote:
Hello!
I noticed the following on ARM, GCC trunk -- didn't check yet whether it
is ARM-specific; may be a general issue.
Hacking out the forcing-off of emitting CFI statements in arm.c, I see
the following function prologue
John Regehr reg...@cs.utah.edu writes:
I would only be worried for cases where no warning is issued *and*
unitialized accesses are eliminated.
Yeah, it would be excellent if GCC maintained the invariant that for
all uses of uninitialized storage, either the compiler or else
valgrind will
On Tue, 2009-12-15 at 11:24 +0100, Andi Kleen wrote:
John Regehr reg...@cs.utah.edu writes:
I would only be worried for cases where no warning is issued *and*
unitialized accesses are eliminated.
Yeah, it would be excellent if GCC maintained the invariant that for
all uses of
Hi, Ian,
ELIMINATE_REGS and TARGET_CAN_ELIMINATE are set correctly. As far as I
understand from further investigation, at some point during
compilation, the argument pointer register is used, then the
expand_prologue() produces INSNs including push argp (as argp is
I am not a valgrind expert so, take the following with a grain of salt
but I think that the above statement is wrong: valgrind reliably detects
use of uninitialized variables if you define 'use' as meaning 'affects
control flow of your program' in valgrind.
It works in some cases for the
On Sun, Dec 13, 2009 at 15:51, Richard Guenther rguent...@suse.de wrote:
+ /* ??? We could free non-constant DECL_SIZE, DECL_SIZE_UNIT
+ and DECL_FIELD_OFFSET. But it's cheap enough to not do
+ that and refrain from adding workarounds to dwarf2out.c */
+
+ /* DECL_FCONTEXT is only
You are correct. So I should be changing things in the adjust_cost
function instead.
I was also wondering, these instructions modify an internal register
that has been set as a fixed register. However, the compiler optimizes
them out when the accumulator is not retrieved for a calculation. How
Ivan Shcherbakov shcherba...@eit.uni-kl.de writes:
ELIMINATE_REGS and TARGET_CAN_ELIMINATE are set correctly. As far as I
understand from further investigation, at some point during
compilation, the argument pointer register is used, then the
expand_prologue() produces
On Tue, Dec 15, 2009 at 10:08:02AM -0500, Jean Christophe Beyler wrote:
You are correct. So I should be changing things in the adjust_cost
function instead.
I was also wondering, these instructions modify an internal register
that has been set as a fixed register. However, the compiler
Hi, Ian,
I have created a simpler example, just a function computing a sum of
its arguments:
int sum(int a, int b, int c, int d, int e, int f, int g, int h)
{
return a + b + c + d + e + f + g + h;
}
The argp is a pseudo-register included in all register classes, that
contain normal
Ivan Shcherbakov shcherba...@eit.uni-kl.de writes:
It seems that in x86 the argp register gets
eliminated before the reload phase.
That seems unlikely to me. What pass do you think is eliminating the
argument register?
Ian
EPILOGUE_USES does not seem to work, the code still gets optimized out.
However, unspec_volatile works but then, as you have said, the
compiler doesn't optimize out things that it then could.
I have for example an instruction to set this special register.
Theoretically, if we had :
set (x);
set
Hi, Ian,
For i386-gcc, this seems to happen during global register allocation
pass. This corresponds to IRA pass of gcc 4.4.x. I have attached the
corresponding RTL dump files.
--
Best regards,
Ivan Shcherbakov mailto:shcherba...@eit.uni-kl.de
TU Kaiserslautern,
Ivan Shcherbakov shcherba...@eit.uni-kl.de writes:
For i386-gcc, this seems to happen during global register allocation
pass. This corresponds to IRA pass of gcc 4.4.x. I have attached the
corresponding RTL dump files.
That means that reload is where the register is eliminated, as
On Tue, 15 Dec 2009, Diego Novillo wrote:
On Sun, Dec 13, 2009 at 15:51, Richard Guenther rguent...@suse.de wrote:
+ /* ??? We could free non-constant DECL_SIZE, DECL_SIZE_UNIT
+ and DECL_FIELD_OFFSET. But it's cheap enough to not do
+ that and refrain from adding workarounds to
Hello!
On 2009-12-15 10:15, Richard Earnshaw wrote:
On Mon, 2009-12-14 at 19:18 +0100, Thomas Schwinge wrote:
.LCFI0:
.cfi_def_cfa_offset 8
+ push{lr}
+ bl __gnu_mcount_nc
.loc 1 4 0
mov r0, #33
Shouldn't
Also, we're not running LTO in any compiler and we removed all static
declarations from the code to keep compilers from making closed-world
assumptions.
John Regehr
On 12/10/09 18:33, daniel tian wrote:
Hi,
I have a problem about RTL sequence.
If I wanna generate the RTL in sequence, and don't let gcc to schedule
them.
Then you need to generate them as a single insn which outputs multiple
instructions.
Jeff
John Regehr reg...@cs.utah.edu writes:
I would only be worried for cases where no warning is issued *and*
unitialized accesses are eliminated.
Yeah, it would be excellent if GCC maintained the invariant that for all
uses of uninitialized storage, either the compiler or else valgrind will
Hi, Ian,
Thank you for the information about register allocation sequence.
My problem was solved by adding AP-to-FP entry to ELIMINABLE_REGS.
I also encountered another minor problem. When GCC tries to generate a
push SP instruction (e.g. some_func(the_only_local_var);), it is
detected
Snapshot gcc-4.4-20091215 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20091215/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
[cross-posting to the GCC and LLVM lists]
I've updated the code size results here:
http://embed.cs.utah.edu/embarrassing/dec_09/
The changes for this run were:
- delete a number of testcases that contained use of uninitialized local
variables
- turn off frame pointer emission for all
John Regehr reg...@cs.utah.edu writes:
I've updated the code size results here:
http://embed.cs.utah.edu/embarrassing/dec_09/
The thing that bothers me about this is that you seem to put a lot of
emphasis on the test X generated larger code than Y without any
reflection of how much larger
--- Comment #7 from spop at gcc dot gnu dot org 2009-12-15 08:21 ---
I will add -fgraphite-identity to the testcase as otherwise we're not going to
test graphite on trunk...
diff --git a/gcc/testsuite/g++.dg/graphite/pr42130.C
b/gcc/testsuite/g++.dg/graphite/pr42130.C
index
--- Comment #7 from irar at il dot ibm dot com 2009-12-15 08:25 ---
I can't reproduce it with current mainline on powerpc64-suse-linux. Could you
please attach vectorizer dump? Does the good old version gets vectorized? If
so, could you please attach it as well?
Thanks,
Ira
--
--- Comment #8 from spop at gcc dot gnu dot org 2009-12-15 08:27 ---
Also, I don't know why the test fails at runtime like this:
FAIL: g++.dg/graphite/pr42130.C execution test
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42130
--- Comment #2 from burnus at gcc dot gnu dot org 2009-12-15 08:37 ---
Subject: Bug 41235
Author: burnus
Date: Tue Dec 15 08:37:41 2009
New Revision: 155247
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155247
Log:
2009-12-15 Tobias Burnus bur...@net-b.de
Daniel
--- Comment #2 from spop at gcc dot gnu dot org 2009-12-15 08:39 ---
Subject: Bug 42334
Author: spop
Date: Tue Dec 15 08:39:25 2009
New Revision: 155248
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155248
Log:
Fix PR42334: correct the update of the LST on loop interchange and
--- Comment #3 from spop at gcc dot gnu dot org 2009-12-15 08:39 ---
Subject: Bug 42178
Author: spop
Date: Tue Dec 15 08:39:25 2009
New Revision: 155248
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155248
Log:
Fix PR42334: correct the update of the LST on loop interchange and
I have noticed a big performance decrease in one of my numerical codes
when switching from gcc 4.4 to gcc 4.5. A small test case is attached.
When compiling this test case with gcc -O3 perf.c -lm -std=c99
and executing the resulting binary, the CPU time with the head of
the 4.4 branch is about
--- Comment #3 from spop at gcc dot gnu dot org 2009-12-15 08:41 ---
Fixed in the graphite branch. I will commit this to trunk after further test.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from spop at gcc dot gnu dot org 2009-12-15 08:41 ---
Fixed in the graphite branch. I will commit this to trunk after further test.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from martin at mpa-garching dot mpg dot de 2009-12-15 08:41
---
Created an attachment (id=19305)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19305action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42376
--- Comment #2 from martin at mpa-garching dot mpg dot de 2009-12-15 08:42
---
Created an attachment (id=19306)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19306action=view)
assembler generated by gcc 4.5
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42376
--- Comment #3 from martin at mpa-garching dot mpg dot de 2009-12-15 08:43
---
Created an attachment (id=19307)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19307action=view)
assembler generated by gcc 4.4
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42376
--- Comment #4 from burnus at gcc dot gnu dot org 2009-12-15 08:44 ---
It also should check (kind/length) type-parameters, cf.
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/d710371aed91e75f
This is kind of a follow up to PR 41235; cf. also PR 41603.
--
--- Comment #3 from burnus at gcc dot gnu dot org 2009-12-15 08:45 ---
FIXED
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #1 from chris at bubblescope dot net 2009-12-15 08:54 ---
I see you are building with fink. Looking on the fink website, they do not seem
to have a gcc45 package. Where did you get it from? Or has it just not made it
to the website yet?
--
chris at bubblescope dot net
--- Comment #2 from paolo dot carlini at oracle dot com 2009-12-15 09:12
---
And these can only be either target or, maybe, c++ front-end, certainly not
libstdc++ proper
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #4 from paolo dot carlini at oracle dot com 2009-12-15 09:22
---
Ok, thanks, I'll track that one instead...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42336
--- Comment #4 from jakub at gcc dot gnu dot org 2009-12-15 09:35 ---
make -j4 -k check-g++ RUNTESTFLAGS=--target_board=unix/-g
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42364
--- Comment #3 from ramana at gcc dot gnu dot org 2009-12-15 09:50 ---
Created an attachment (id=19308)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19308action=view)
Reduced testcase.
Reduced testcase attached - Compiling with -c -Os -frename-registers exposes
the problem.
--
--- Comment #8 from dominiq at lps dot ens dot fr 2009-12-15 09:58 ---
I can't reproduce it with current mainline on powerpc64-suse-linux.
I know;)
Does the good old version gets vectorized?
I don't have any working 4.5 version, but 4.4.2 is working. The differences are
(4.4.2)
--- Comment #9 from dominiq at lps dot ens dot fr 2009-12-15 09:59 ---
Created an attachment (id=19309)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19309action=view)
dump file for gfortran 4.4.2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082
--- Comment #10 from dominiq at lps dot ens dot fr 2009-12-15 10:00 ---
Created an attachment (id=19310)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19310action=view)
dump file for gfortran 4.5.0 revision 155196
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082
--- Comment #99 from dominiq at lps dot ens dot fr 2009-12-15 10:14 ---
i686-apple-darwin9 bootstraps without dsymutil fails at 155225, thanks Jakub.
powerpc-apple-darwin9 too at 155239. For x86_64-apple-darwin10, I think the
problem is fixed too, but between revisions 154996 and
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #11 from irar at il dot ibm dot com 2009-12-15 10:59 ---
Looks that it has to be my patch that enables vectorization of conditions:
r149806 | irar | 2009-07-20 14:59:10 +0300 (Mon, 20 Jul 2009) | 19 lines
* tree-vectorizer.h (vectorizable_condition): Add
--- Comment #37 from rguenth at gcc dot gnu dot org 2009-12-15 11:08
---
No, there isn't. I'd simply allow TREE_THIS_NOTRAP on all expression codes
that in principle could. Now of course the middle-end would still need to
make use of this (like transition it to a stmt flag on a
Even though libstdc++-6.dll has: 6fc94700 T
std::string::reserve(unsigned long long),
libstdc++.dll.a misses a definition of std::string::reserve!
Which makes it impossible to build libgmpxx against a shared version of
libstdc++-6, see:
/bin/sh ./libtool --mode=link g++ -O2 -pedantic
--- Comment #5 from paolo dot carlini at oracle dot com 2009-12-15 11:29
---
FYI, I have checked, however, that the last posted patch for 42225
http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00755.html
doesn't fix this one at once.
--
--- Comment #6 from dodji at seketeli dot org 2009-12-15 11:48 ---
Subject: Re: [c++0x] ICE with pointer-to-member-function
decltype argument in template function
FYI, I have checked, however, that the last posted patch for 42225
doesn't fix this one at once.
To be honest, I am
--- Comment #1 from davek at gcc dot gnu dot org 2009-12-15 11:49 ---
Hi Rainer, it'll take a little time but I'll set myself up a build environment
and see if I can reproduce this.
The libtool dependency libs stuff is a known problem in libtool IIRC. Details
to follow.
--
--- Comment #12 from dominiq at lps dot ens dot fr 2009-12-15 13:05 ---
Looks that it has to be my patch that enables vectorization of conditions:
I am doing a clean bootstrap of C and FORTRAN of revision 149805 to see if the
test works for it (allow for ~6h on my poor G5). Then I'll
--- Comment #13 from irar at il dot ibm dot com 2009-12-15 13:07 ---
(In reply to comment #12)
Looks that it has to be my patch that enables vectorization of conditions:
I am doing a clean bootstrap of C and FORTRAN of revision 149805 to see if the
test works for it (allow for ~6h
--- Comment #14 from irar at il dot ibm dot com 2009-12-15 13:08 ---
Created an attachment (id=19311)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19311action=view)
powerpc64-suse-linux vect dump
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-12-15 13:15 ---
This is because (quoting http://gcc.gnu.org/gcc-4.5/changes.html):
GCC now supports handling floating-point excess precision arising from use of
the x87 floating-point unit in a way that conforms to ISO C99. This
I have started to see the following failures between revisions 148215 and
148502 (likely 148285, which means that these tests never passed on
powerpc-apple-darwin9):
Running target unix
FAIL: libffi.call/cls_double_va.c -O0 -W -Wall output pattern test, is -0.0
FAIL:
--- Comment #26 from dominiq at lps dot ens dot fr 2009-12-15 13:21 ---
I have open pr42378 for the remaining failures in comment #21 (I did not
include libffi.call/nested_struct5.c that is pr34311). Closing this PR as
fixed, please reopen if you disagree.
--
dominiq at lps dot ens
--- Comment #15 from dominiq at lps dot ens dot fr 2009-12-15 13:29 ---
and the second one has this bb:
bb 43:
dt_parm.33.common.filename = where_2.f90[1]{lb: 1 sz: 1};
...
_gfortran_st_write_done (dt_parm.33);
This is probably due to a print I put in the code to look at the
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-12-15 13:33 ---
Is this a regression? If so please mark it so.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from irar at il dot ibm dot com 2009-12-15 13:35 ---
But in comment #5 you wrote that it passes with the print, right? So, this dump
contains correct or incorrect code?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-12-15 13:35 ---
This is a bug in the test. Early inter-procedural SRA avoids passing array by
reference in the recurse() function and instead passes the first element
which is the only one read. Thus the function is optimized to
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-12-15 13:38 ---
This is because we never re-compute the address-taken flag of functions.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-12-15 13:50 ---
I can reproduce it with the testcase in comment #1 on i?86-linux:
$ ./f951 -quiet t.f -O2 -floop-strip-mine -fprefetch-loop-arrays -msse2
t.f: In function 'blts':
t.f:1:0: internal compiler error: Segmentation
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-12-15 13:51 ---
Works for me with 4.4.2 on i?86-linux.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2009-12-15
13:53 ---
I am building with custom fink packaging for the gcc45 pre-releases. All the
important build information should be in the specs output of the compiler.
--
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-12-15 13:54 ---
Still fails the same way for me.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from dominiq at lps dot ens dot fr 2009-12-15 14:15 ---
But in comment #5 you wrote that it passes with the print, right? So, this
dump
contains correct or incorrect code?
The dump for 4.5 is from the incorrect code. The behavior of this bug has
change over time, it
--- Comment #2 from rainer at emrich-ebersheim dot de 2009-12-15 14:25
---
(In reply to comment #1)
Hi Rainer, it'll take a little time but I'll set myself up a build
environment
and see if I can reproduce this.
The libtool dependency libs stuff is a known problem in libtool
--- Comment #8 from jakub at gcc dot gnu dot org 2009-12-15 15:13 ---
Subject: Bug 41183
Author: jakub
Date: Tue Dec 15 15:13:08 2009
New Revision: 155254
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155254
Log:
PR c++/41183
* cp-tree.h (current_class_ptr): Give
Revision 155245:
http://gcc.gnu.org/ml/gcc-cvs/2009-12/msg00389.html
caused:
FAIL: 23_containers/map/operators/1_neg.cc (test for errors, line 212)
FAIL: 23_containers/map/operators/1_neg.cc (test for errors, line 216)
FAIL: 23_containers/map/operators/1_neg.cc (test for excess errors)
FAIL:
--- Comment #9 from jakub at gcc dot gnu dot org 2009-12-15 15:15 ---
Subject: Bug 41183
Author: jakub
Date: Tue Dec 15 15:14:59 2009
New Revision: 155255
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155255
Log:
PR c++/41183
* cp-tree.h (current_class_ptr): Give
--- Comment #4 from dominiq at lps dot ens dot fr 2009-12-15 15:16 ---
See also http://gcc.gnu.org/ml/gcc-testresults/2009-12/msg01308.html for
i686-pc-linux-gnu.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42374
--- Comment #4 from aldyh at gcc dot gnu dot org 2009-12-15 15:18 ---
Subject: Bug 42185
Author: aldyh
Date: Tue Dec 15 15:17:46 2009
New Revision: 155256
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155256
Log:
PR graphite/42185
* graphite-sese-to-poly.c
--- Comment #5 from aldyh at gcc dot gnu dot org 2009-12-15 15:18 ---
That's because I hadn't committed. Tests pass. Committing and closing.
--
aldyh at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from dominiq at lps dot ens dot fr 2009-12-15 15:37 ---
A patch has been posted to
http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00772.html .
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41146
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-12-15 15:42 ---
*** Bug 42374 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-12-15 15:42 ---
*** This bug has been marked as a duplicate of 42379 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[4.5 Regression] Revision |[4.5 Regression] Revision
|155245 failed 1_neg.cc
--- Comment #2 from paolo dot carlini at oracle dot com 2009-12-15 15:59
---
It's trivial, just one more candidates are which must be adjusted to
candidate is in the dg-error strings.
--
paolo dot carlini at oracle dot com changed:
What|Removed
--- Comment #3 from paolo at gcc dot gnu dot org 2009-12-15 16:11 ---
Subject: Bug 42379
Author: paolo
Date: Tue Dec 15 16:11:32 2009
New Revision: 155258
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155258
Log:
2009-12-15 Paolo Carlini paolo.carl...@oracle.com
PR
--- Comment #4 from paolo dot carlini at oracle dot com 2009-12-15 16:12
---
Done.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.5.0 |4.4.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27425
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.5.0 |4.4.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34274
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to work||4.4.0
Summary|[4.2/4.3 regression] Broken |[4.3
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[4.2/4.3 Regression] ICE in |[4.3 Regression] ICE in
--- Comment #34 from rguenth at gcc dot gnu dot org 2009-12-15 16:40
---
4.4 is also slow, we know what causes it so this can't be P1.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
See http://gcc.gnu.org/ml/gcc/2009-12/msg00183.html.
To sum up: the question is whether the CFA needs to be adjusted after push
{lr}, and before calling __gnu_mcount_nc. Currently it is not valid until
__gnu_mcount_nc returns.
--
Summary: CFI statements vs. -pg
Product:
--- Comment #1 from tschwinge at gcc dot gnu dot org 2009-12-15 16:57
---
Richard Earnshaw wrote:
I'm not sure what other architectures do in this case. Do they also put
out adjustments to the cfi?
I had a look at x86 and x86_64 -- they still need a frame pointer together with
-pg,
--- Comment #17 from paolo dot carlini at oracle dot com 2009-12-15 17:00
---
At the moment, not actively working on this...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #14 from paolo dot carlini at oracle dot com 2009-12-15 17:02
---
Is this still an issue?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35942
--- Comment #18 from paolo dot carlini at oracle dot com 2009-12-15 17:04
---
I'm closing this as fixed for 4.5.0.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #6 from paolo dot carlini at oracle dot com 2009-12-15 17:17
---
Ok, let's close this as invalid.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #8 from paolo dot carlini at oracle dot com 2009-12-15 17:19
---
Roger, are you still actively working on this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35968
1 - 100 of 151 matches
Mail list logo
