--- Comment #1 from steven at gcc dot gnu dot org 2010-04-26 17:21 ---
Regression from GCC 4.3, which still had libcall notes.
--- t.s.434 2010-04-26 10:21:18.0 -0700
+++ t.s.442 2010-04-26 10:21:36.0 -0700
@@ -2,6 +2,7 @@
.pred.safe_across_calls p1-p5
--- Comment #1 from steven at gcc dot gnu dot org 2010-04-25 11:42 ---
You can compare the code if you compile with -S (output .s assembler file). Or
you can compile with -S and attach the output of both compilers here, so
someone else can have a look.
--
http://gcc.gnu.org
--- Comment #2 from steven at gcc dot gnu dot org 2010-04-25 12:13 ---
Confirmed on x86_64-linux by comparing gcc 4.3.3 vs. gcc 4.6.0 (r158482). The
average of 10 runs on each is 5.1s with gcc 4.3.3 vs. 5.7s for gcc 4.4.2, gcc
4.5.0 and gcc 4.6.0.
One interesting difference is that GCC
--- Comment #2 from steven at gcc dot gnu dot org 2010-04-23 07:38 ---
*** This bug has been marked as a duplicate of 20070 ***
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #33 from steven at gcc dot gnu dot org 2010-04-23 07:38 ---
*** Bug 43864 has been marked as a duplicate of this bug. ***
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from steven at gcc dot gnu dot org 2010-04-23 22:43 ---
This one appears to have fallen through the cracks. Reported exactly one year
ago, and now accidentally shows up in my search because my brain believed we
still live in 2009... Oh well.
I tried to reproduce
--- Comment #1 from steven at gcc dot gnu dot org 2010-04-21 12:51 ---
Scalarization is just difficult...
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from steven at gcc dot gnu dot org 2010-04-21 16:31 ---
How can this possibly be a regression in 4.5 if -fwhole-program is new there?
Regression means worked in an earlier release and there is no earlier release
with this feature.
--
steven at gcc dot gnu dot org
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot
|dot org
--- Comment #4 from steven at gcc dot gnu dot org 2010-04-19 10:21 ---
Do we have a warning option for this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43794
--- Comment #3 from steven at gcc dot gnu dot org 2010-04-19 21:39 ---
Removing -O2 is never a proper work-around anyway. This should just work.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from steven at gcc dot gnu dot org 2010-04-16 16:31 ---
/data2/share/gcc/gcc-4.4.3/host-x86_64-unknown-linux-gnu/gcc/f951: symbol
lookup error: /data2/share/matlab2007/bin/glnxa64/libmpfr.so.1: undefined
symbol: __gmp_get_memory_functions
Do you have the right GMP
--- Comment #12 from steven at gcc dot gnu dot org 2010-04-15 09:06 ---
.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #18 from steven at gcc dot gnu dot org 2010-04-15 22:18 ---
*** Bug 43761 has been marked as a duplicate of this bug. ***
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from steven at gcc dot gnu dot org 2010-04-15 22:18 ---
*** This bug has been marked as a duplicate of 43170 ***
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from steven at gcc dot gnu dot org 2010-04-14 09:24 ---
Does FSF gcc-4.2 exhibit the problem? Maybe the OSX compiler has local changes
in the specs processing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43751
--- Comment #1 from steven at gcc dot gnu dot org 2010-04-14 15:41 ---
With checking enabled, anything can happen. Try without.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43753
--- Comment #2 from steven at gcc dot gnu dot org 2010-04-14 15:44 ---
FWIW, there are so many var-tracking is slow bugs now, that one might
reasonably question the QoI of it.
See also http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31412
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #10 from steven at gcc dot gnu dot org 2010-04-14 18:04 ---
Yes, release checking is OK. And I don't think it is OK to have 90% of the
compile time spent on calculating debugging info, no matter how crazy the test
case may be. We should try to speed this up
--- Comment #8 from steven at gcc dot gnu dot org 2010-04-14 20:49 ---
Created an attachment (id=20379)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20379action=view)
Classic GCSE, resurrected (with some improvements)
Updated patch for trunk r158281.
Bootstrapped and tested
--- Comment #5 from steven at gcc dot gnu dot org 2010-04-14 22:10 ---
Collecting bits and pieces from all over, I'm trying to make a plan...
Consensus on IRC is that LTO data does not need its own Mach-O segment, and
that can it just fit as a section in the _TEXT (since LTO data
--- Comment #2 from steven at gcc dot gnu dot org 2010-04-13 06:59 ---
The patch of comment #1 is not the right thing to do. What it means, is that
recog_data finds an operand for which the insn has no df_ref.
Caused by http://gcc.gnu.org/viewcvs?view=revisionrevision=158187
--- Comment #5 from steven at gcc dot gnu dot org 2010-04-13 21:23 ---
Matz, can you at least attach the patch to this PR, so that someone else can
polish it if you're not going to do it?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42963
--- Comment #35 from steven at gcc dot gnu dot org 2010-04-12 10:40 ---
So if I understand correctly, the state of things at the moment is this:
Without LTO:
Time: 419.938 sec (6 m 59 s)
with LTO incl linker flags:
Time: 443.047 sec (7 m 23 s)
In other words, with LTO is ~6% slower
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Status|UNCONFIRMED |NEW
--- Comment #37 from steven at gcc dot gnu dot org 2010-04-12 15:58 ---
LTO for Mach-O is now being tracked in bug 43729.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from steven at gcc dot gnu dot org 2010-04-12 15:59 ---
From http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42776#c8 :
Can we use a similar approach for Mach-O [as for PE-COFF]?
I don't speak Mach-O, but yes, the approach should work. You'd start by
saying
--- Comment #2 from steven at gcc dot gnu dot org 2010-04-12 16:15 ---
For the Mach-O file format, follow this link:
http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/MachORuntime/Reference/reference.html
First step for Mach-O support would be figuring out
--- Comment #28 from steven at gcc dot gnu dot org 2010-04-12 19:56 ---
Triggers in 4.4 with an out-of-tree port.
See http://gcc.gnu.org/ml/gcc/2010-04/msg00243.html
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Keywords|build |patch
Summary|[4.4 Regression] bootstrap |[4.4 Regression
--- Comment #33 from steven at gcc dot gnu dot org 2010-04-11 22:59 ---
A common mistake is to not pass the optimizer flags properly to the linker.
There is a thread about that, too:
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00438.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #1 from steven at gcc dot gnu dot org 2010-04-08 10:37 ---
Supposed to be addressed before release except that they haven't. So let's
make it a 4.5 Regression, which it is to some degree.
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from steven at gcc dot gnu dot org 2010-04-08 10:39 ---
No progress since this PR was opened. Ping.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41528
--- Comment #2 from steven at gcc dot gnu dot org 2010-04-08 10:39 ---
What happened to the patch mentioned in comment #1?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41576
--- Comment #2 from steven at gcc dot gnu dot org 2010-04-08 10:43 ---
Should LTO reject function declarations with incompatible attributes? Or should
the discovery of the attribute in one translation unit be used to update the
control flow graph in the other units (e.g. by writing out
--- Comment #3 from steven at gcc dot gnu dot org 2010-04-08 11:09 ---
Interestingly, LTO actually tries to use the original file name:
/* Since SET does not need to be processed by LTRANS, use
the original file name and mark it with a '*' prefix so
--- Comment #30 from steven at gcc dot gnu dot org 2010-04-06 10:56 ---
I think it is a really, really bad signal if a bug like this, where the
revision that introduced the issue was identified 9 months ago, remains
unfixed for GCC 4.5.
I, for one, wouldn't care hunting down revisions
--- Comment #2 from steven at gcc dot gnu dot org 2010-04-06 11:01 ---
Wow, taking the address of a bit field. That can only be C++. This should be
closed as a dup of bug 5... Oh, well... :-)
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #8 from steven at gcc dot gnu dot org 2010-04-06 11:07 ---
It would be really helpful if someone can explain how to reproduce this with a
cross-compiler. I will analyze/fix this problem when this is reproducible with
a cross.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #35 from steven at gcc dot gnu dot org 2010-04-06 11:32 ---
If your discussions are only slightly related to this bug and don't affect -Os,
then why are you having that discussion here?
Anyway. If this is WONTFIX for GCC 4.5, then it should be marked as such
(remove 4.5
--- Comment #7 from steven at gcc dot gnu dot org 2010-04-05 12:34 ---
According to comment #6 this works now. Can the OP please confirm?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
GCC target
--- Comment #46 from steven at gcc dot gnu dot org 2010-04-05 12:52 ---
What happened with the patch of comment #33?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
--- Comment #4 from steven at gcc dot gnu dot org 2010-04-05 12:55 ---
Joel, is this still a problem, or not? If so, please reconfirm the bug and
change the bug status back to NEW.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37440
--- Comment #5 from steven at gcc dot gnu dot org 2010-04-05 12:56 ---
*** Bug 40775 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37440
--- Comment #5 from steven at gcc dot gnu dot org 2010-04-05 12:56 ---
*** This bug has been marked as a duplicate of 37440 ***
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #49 from steven at gcc dot gnu dot org 2010-04-05 13:01 ---
At least the tree-vrp.c bit did not get applied (as of trunk r157950)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
--- Comment #3 from steven at gcc dot gnu dot org 2010-04-02 09:18 ---
This tells me you are comparing apples and cows: Extra diagnostic checks
enabled; compiler may run slowly.
Could you try again with a compiler configured with --enable=checking=release?
--
steven at gcc dot gnu
--- Comment #1 from steven at gcc dot gnu dot org 2010-04-02 09:29 ---
The GCC project is not responsible for its own translations. You should take
this proposal to the GNU translation project (or
http://translationproject.org).
--
steven at gcc dot gnu dot org changed
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
Status: UNCONFIRMED
Keywords: wrong-debug
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: steven at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43631
--- Comment #3 from steven at gcc dot gnu dot org 2010-04-01 13:51 ---
How is the polishing going?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42963
--- Comment #6 from steven at gcc dot gnu dot org 2010-04-01 16:17 ---
I am testing this patch on ia64 now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21803
--- Comment #7 from steven at gcc dot gnu dot org 2010-04-01 17:57 ---
With the patch linked to in commment #4, I get an ICE on ia64:
../../trunk/gcc/fortran/trans-intrinsic.c: In function
'gfc_conv_intrinsic_minmaxloc':
../../trunk/gcc/fortran/trans-intrinsic.c:2529:1: internal
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #2 from steven at gcc dot gnu dot org 2010-03-31 14:59 ---
In .final, the insns look like this:
@(insn:TI 9 7 8 t.c:8 (set (reg:CC 24 cc)
@(compare:CC (reg:SI 0 r0 [orig:134 f ] [134])
@(const_int 0 [0x0]))) 220 {*arm_cmpsi_insn} (expr_list:REG_DEAD
--- Comment #3 from steven at gcc dot gnu dot org 2010-03-31 15:15 ---
Well, according to GDB, combine does try to combine in try_combine:
Breakpoint 8, try_combine (i3=0x204fc8b8, i2=0x204fc828,
i1=0x0, new_direct_jump_p=0x6fd4ae28) at ../../trunk/gcc/combine.c
--- Comment #4 from steven at gcc dot gnu dot org 2010-03-31 22:49 ---
It's not very hard to add a define_peephole2 pattern for this case also,
although it's a bit of a hack.
I'm not even sure if it would handle the case cmp+mov and mov+cmp case -- does
peephole2 care about the order
--- Comment #5 from steven at gcc dot gnu dot org 2010-03-31 22:51 ---
...remove accidental CC-list additions...
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from steven at gcc dot gnu dot org 2010-03-31 22:55 ---
Primary/secondary targets are listed on
http://gcc.gnu.org/gcc-4.5/criteria.html. That list should probably be
clarified for GCC 4.6 to explain what arm-eabi means, exactly. It makes little
sense to me, to make arm
--- Comment #2 from steven at gcc dot gnu dot org 2010-03-26 12:24 ---
No, the user should be able to say do this and then the compiler should do
so. Right now the flag to enable BB-reorder has no effect at -Os, and that is a
bug.
--
steven at gcc dot gnu dot org changed
--- Comment #2 from steven at gcc dot gnu dot org 2010-03-25 09:53 ---
Any reason why combine-stack-adj.c doesn't perform this optimization for you?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from steven at gcc dot gnu dot org 2010-03-25 15:27 ---
Add link to GIMPLE hoisting work.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
--- Comment #4 from steven at gcc dot gnu dot org 2010-03-21 09:54 ---
Why such a big hammer? You should be able to figure out which copy props are
allowed and which should be disallowed in loop-closed SSA form.
Is if (current_loops) the right test here? This will break if Zdenek's
--- Comment #1 from steven at gcc dot gnu dot org 2010-03-21 09:57 ---
How did you configure the compilers? (Think --enable-checking=release, etc.)
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #19 from steven at gcc dot gnu dot org 2010-03-21 12:03 ---
Cause here is better register allocation and lack of cross-jumping before
register allocation. This will not be fixed. For GCC 4.6 we should add a
cross-jumping patch (an improved version if this pass, anyway
--- Comment #6 from steven at gcc dot gnu dot org 2010-03-21 12:09 ---
I believe this should be fixed for GCC 4.5. Setting to P3 to ask release
managers for their opinion.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #50 from steven at gcc dot gnu dot org 2010-03-21 12:13 ---
Performance loss within acceptable limits (by the you give some, you take
some principle). GCC 4.5 optimizes the test case away completely. I see no
reason to do anything more here. Fixed for GCC 4.5 and GCC 4.4
--- Comment #45 from steven at gcc dot gnu dot org 2010-03-21 12:14 ---
Mark, I'm assuming you have no plans to work on this? If so, please unassign
yourself from this bug.
Can anyone reconfirm this bug for GCC 4.4 and/or GCC 4.5?
--
steven at gcc dot gnu dot org changed
--- Comment #16 from steven at gcc dot gnu dot org 2010-03-21 12:16 ---
Known to work in 4.4.0 so not a 4.4/4.5 Regression anymore.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from steven at gcc dot gnu dot org 2010-03-21 12:20 ---
Bug in WAITING for a long time, no feedback. Very small, hard-to-catch code
difference. It's been noted before that the core2 scheduler description
(contributed by Intel itself!) often results in worse code than
--- Comment #10 from steven at gcc dot gnu dot org 2010-03-21 12:22 ---
With all attention going out to debug info in GCC 4.5, and with TER
more-or-less rewritten for GCC 4.5 -- perhaps re-evaluate this bug's priority?
--
steven at gcc dot gnu dot org changed:
What
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P5 |P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19192
--- Comment #9 from steven at gcc dot gnu dot org 2010-03-21 14:35 ---
Still needs to be applied to GCC 4.4.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from steven at gcc dot gnu dot org 2010-03-21 19:04 ---
Development branches have extra checking enabled, and it's always been like
that. If you compile with -ftime-report, the compiler warns if the extra
checking is enabled, and that's quite enough.
--
steven at gcc
--- Comment #8 from steven at gcc dot gnu dot org 2010-03-20 12:58 ---
Shouldeth be fixedeth by aforementionedeth patcheth (comment #7). Yay!
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from steven at gcc dot gnu dot org 2010-03-20 12:59 ---
Carrot, re. your comment #7: Time for that thoroughly testing.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #2 from steven at gcc dot gnu dot org 2010-03-20 13:02 ---
Waiting for OP to try suggestion of comment #1.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #4 from steven at gcc dot gnu dot org 2010-03-19 18:39 ---
Comment #3 makes no sense: There is no such thing as target specific GIMPLE
canonicalization. And also there is no hoisting for GIMPLE so the form of the
IR given in comment #3 wouldn't make a difference.
Even
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO||16996
nThis
--- Comment #6 from steven at gcc dot gnu dot org 2010-03-18 08:27 ---
Reopening...
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #7 from steven at gcc dot gnu dot org 2010-03-18 08:29 ---
...to close as dup of bug 39871
*** This bug has been marked as a duplicate of 39871 ***
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #21 from steven at gcc dot gnu dot org 2010-03-18 08:29 ---
*** Bug 43286 has been marked as a duplicate of this bug. ***
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #22 from steven at gcc dot gnu dot org 2010-03-18 08:31 ---
In the test case from bug 43286, should_replace_address does not perform the
following replacement because the address cost is the same and the replacement
is only done if new_rtx is more expensive than old_rtx
--- Comment #19 from steven at gcc dot gnu dot org 2010-03-18 13:20 ---
For the record: bootstrapped+tested on amd64-linux and ia64-linux.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43360
--- Comment #11 from steven at gcc dot gnu dot org 2010-03-17 08:23 ---
So why not just something like the following:
Note that uses in REG_EQUAL notes are taken into account in
the computation of invariants. Hence it is safe to retain the
note even
--- Comment #13 from steven at gcc dot gnu dot org 2010-03-17 08:33 ---
Mine.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #6 from steven at gcc dot gnu dot org 2010-03-17 11:59 ---
Perhaps add a comment why the peephole is needed? That information tend to get
lost rather quickly.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42258
--- Comment #2 from steven at gcc dot gnu dot org 2010-03-14 12:53 ---
(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) Starting program:
/home/stevenb/devel/build-mips/gcc/cc1 -quiet -O1 t.c
Breakpoint 1, fancy_abort (file
--- Comment #4 from steven at gcc dot gnu dot org 2010-03-10 16:21 ---
Another arm_arm_address_cost problem, dup of something I'm not even going to
try to find.
Until ARM or an ARM maintainer cares (or Google folks stop filing and start
fixing bugs), we don't need more reports
--- Comment #4 from steven at gcc dot gnu dot org 2010-03-03 10:57 ---
I think pinskia means we could transform the test case of comment #0 to:
void DoHuffIteration(int);
int f(int *a)
{
int i;
int plaintextlen=*a;
pretmp = plaintextlen;
for(i = 0; i 1; i
--- Comment #6 from steven at gcc dot gnu dot org 2010-03-03 14:26 ---
Well, it is not hoisting, either.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38497
--- Comment #21 from steven at gcc dot gnu dot org 2010-03-02 21:56 ---
Prototype patch here: http://gcc.gnu.org/bugzilla/attachment.cgi?id=19755
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36758
--- Comment #4 from steven at gcc dot gnu dot org 2010-03-02 21:58 ---
Can you post the output .s of gcc, and the .s you expect?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
CC||rakdver at gcc dot gnu dot
--- Comment #2 from steven at gcc dot gnu dot org 2010-02-25 19:51 ---
Paul, looks like one of yours.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
201 - 300 of 3017 matches
Mail list logo
