--- Comment #8 from steven at gcc dot gnu dot org 2009-04-05 17:40 ---
Bug is not in an FSF-GCC supported port.
Does the problem reproduce on supported targets? Otherwise this bug should be
closed as "INVALID".
--
steven at gcc dot gnu dot org changed:
What
--- Comment #23 from steven at gcc dot gnu dot org 2009-04-05 12:38 ---
Could it be that this is now fixed by the a-i-b merge?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from steven at gcc dot gnu dot org 2009-04-04 18:41 ---
*sigh* I wanted to say in comment #3 that you need explitit
-f*no*-tree-vectorize and got it wrong :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39573
--- Comment #3 from steven at gcc dot gnu dot org 2009-04-04 17:30 ---
I'm not sure how the -march=native option changes codegen behavior, but the
most likely suspect is the vectorizer. Do things pass with -march=native if
you don't vectorize (needs explicit -ftree
--- Comment #13 from steven at gcc dot gnu dot org 2009-04-04 12:00 ---
Re. comment #10: I don't know about the "buggier" and "slower" parts.
But for "bigger" I know we have benchmarks that say otherwise. e.g. CSiBE for
arm-elf (http://www.inf.u-szege
--- Comment #12 from steven at gcc dot gnu dot org 2009-04-04 11:53 ---
Re. comment #10: And who are you funding, Martin Guy, to improve GCC for ARM?
Or are you just another user who expects magic for free?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39501
--- Comment #1 from steven at gcc dot gnu dot org 2009-04-03 16:43 ---
This feature requires a substantial re-work of symbol handling in gfortran
(make it block based).
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from steven at gcc dot gnu dot org 2009-03-29 22:38 ---
Jakub, this is what we discussed last night.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from steven at gcc dot gnu dot org 2009-03-29 22:36 ---
Created an attachment (id=17557)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17557&action=view)
Always create a new BIND_EXPR for VLA decls
I tried to make use of scopes: If a label is defined in a
--- Comment #8 from steven at gcc dot gnu dot org 2009-03-28 23:32 ---
*NetBSD* seems to be using jemalloc, i.e. jemalloc is your system's malloc()
and it is the same as FreeBSD where the test case *does* work.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39571
--- Comment #3 from steven at gcc dot gnu dot org 2009-03-28 01:02 ---
Completely beyond you, how?
What gcc does for darwin (and this is a hack, mind you), is basically replace
the standard C99 builtins with darwin-specific ones. You have to do the same
for NetBSD.
See the following
--- Comment #1 from steven at gcc dot gnu dot org 2009-03-28 00:51 ---
Which version of GMP are you using?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #23 from steven at gcc dot gnu dot org 2009-03-27 17:27 ---
The checkin of the broken patch mentioned in comment #15 is here:
http://gcc.gnu.org/ml/gcc-cvs/2005-03/msg01521.html
Poor ctice also didn't manage to properly check in a ChangeLog entry, but oh
well.
--
s
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #5 from steven at gcc dot gnu dot org 2009-03-22 21:17 ---
I think this should be in GCC 4.4 and maybe even in 4.c. The patch is obvious
enough and it fixes a wrong-code issue. Language maintainers have some freedom
to fix bugs even on release branches (so also certainly
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
--- Comment #1 from steven at gcc dot gnu dot org 2009-03-22 10:16 ---
Bug 28879 is fixed for GCC 4.4. It was the last bug that blocked this
meta-bug.
--> FIXED
--
steven at gcc dot gnu dot org changed:
What|Removed |Ad
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|other |rtl-optimization
--- Comment #2 from steven at gcc dot gnu dot org 2009-03-22 10:01 ---
fastjar is gone. The rest still has AM_MAKEFLAGS.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from steven at gcc dot gnu dot org 2009-03-22 09:59 ---
Long time in "WAITING" state, and per comment #4 -> FIXED.
If the problem resurfaced at the toplevel, a new report should be opened for
this.
--
steven at gcc dot gnu dot org changed:
--- Comment #22 from steven at gcc dot gnu dot org 2009-03-22 09:51 ---
Fixed in GCC 4.4 with -frecord-gcc-switches
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from steven at gcc dot gnu dot org 2009-03-22 09:43 ---
No progress for *years* now. Was bug 14354 the same issue?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12955
--- Comment #9 from steven at gcc dot gnu dot org 2009-03-22 09:38 ---
I wonder if toplevel bootstrap fixed this issue...
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from steven at gcc dot gnu dot org 2009-03-21 00:54 ---
I'm considering implementing/experimenting with something along the lines of
this:
http://www.cs.ualberta.ca/~amaral/cascon/CDP05/slides/CDP05-horspool.pdf
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35305
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |NEW
Last reconfirmed|2006-09-17 19:41:31 |2009-03-20 22:56
--- Comment #11 from steven at gcc dot gnu dot org 2009-03-20 19:36 ---
Reconfirmed for test cases of comment #9 (same spill failures).
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18190
--- Comment #12 from steven at gcc dot gnu dot org 2009-03-20 18:30 ---
Tom, this hasn't been reconfirmed in a while. Does this bug still exist in
gcj?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18190
--- Comment #3 from steven at gcc dot gnu dot org 2009-03-17 07:20 ---
Copying a pseudo to the required register before an __asm__ is not so easy,
because at expand time the data flow engine doesn't know anything, it's not
even initialized.
What you could do, I suppose in c
--- Comment #5 from steven at gcc dot gnu dot org 2009-03-16 08:46 ---
Can someone point me to the IA64 optimiation manuals mentioned in comment #0?
I'm looking for some answers, for example:
* Which branch registers can I use? bt-load can actually perform register
renaming. I
--- Comment #3 from steven at gcc dot gnu dot org 2009-03-15 23:45 ---
Related to Bug PR20211, too. It's all the same problem, basically: Undoing
constant propagation and discovering how to re-create constant values using
cheap arithmetic on live values in registers...
--
--- Comment #5 from steven at gcc dot gnu dot org 2009-03-15 23:43 ---
*** This bug has been marked as a duplicate of 39469 ***
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from steven at gcc dot gnu dot org 2009-03-15 23:43 ---
*** Bug 39468 has been marked as a duplicate of this bug. ***
--
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 #3 from steven at gcc dot gnu dot org 2009-03-15 23:35 ---
Is there a test case for this PR?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from steven at gcc dot gnu dot org 2009-03-15 23:32 ---
Discover_flag_regs has disappeared for GCC 4.4. WONTFIX for earlier releases.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from steven at gcc dot gnu dot org 2009-03-10 06:48 ---
The load to the general register should also be moved by bt-load, then.
The bt-load pass is "designed" for SH only, in its current state, but I think
extending it to move a small group of insns instead o
--- Comment #14 from steven at gcc dot gnu dot org 2009-03-10 06:32 ---
ISTR Richi has scripts to automatically identify file+function that is
miscompiled...?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from steven at gcc dot gnu dot org 2009-03-08 21:40 ---
Not working on this anymore. Can't get it to produce sensible warnings...
--
steven at gcc dot gnu dot org changed:
What|Removed |
--
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 #6 from steven at gcc dot gnu dot org 2009-03-08 18:08 ---
Re. comment #5.
Two years without a test case that allows us to reproduce the bug. REPRODUCE
the bug. Is that too hard for you to understand?
If we can't reproduce the bug, we can't diagnose the probl
--- Comment #3 from steven at gcc dot gnu dot org 2009-03-08 14:23 ---
Why special-case -O0? Is there anything in the compiler that makes it
impossible to trigger this problem with the right set of options
(-fno-tree-{vrp,ccp} or something like that)?
--
http://gcc.gnu.org
--- Comment #5 from steven at gcc dot gnu dot org 2009-02-23 23:19 ---
Should unfactor. We have pass_duplicate_computed_gotos for this. We should
look into this, see why it doesn't work.
Someone added a "optimize_for_size_p()" check in duplicate_computed_gotos()
--- Comment #2 from steven at gcc dot gnu dot org 2009-02-23 00:41 ---
In fact, with glibc, printf may have side effects to local variables.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39268
--- Comment #13 from steven at gcc dot gnu dot org 2009-02-22 19:13 ---
Works on the trunk. The .final_cleanup dumps are the same for f and f1, and so
is the asm output.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from steven at gcc dot gnu dot org 2009-02-22 19:09 ---
Richi, this may be easy to fix on the AIB...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13962
--- Comment #18 from steven at gcc dot gnu dot org 2009-02-22 16:38 ---
Orphaned bug.
HJ?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from steven at gcc dot gnu dot org 2009-02-22 16:37 ---
Three years, no progress... Is this still an issue?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from steven at gcc dot gnu dot org 2009-02-22 16:36 ---
Locations are now handled differently (mapped locations).
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from steven at gcc dot gnu dot org 2009-02-22 16:34 ---
Probably a linker bug -> INVALID
(and also no progress for 3 years anyway)
--
steven at gcc dot gnu dot org changed:
What|Removed |Ad
--- Comment #2 from steven at gcc dot gnu dot org 2009-02-22 16:32 ---
Don't see that failure here:
http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg02195.html
FIXED?
--
steven at gcc dot gnu dot org changed:
What|Removed |
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23347
--- Comment #1 from steven at gcc dot gnu dot org 2009-02-22 16:31 ---
Is this still an issue, with a new Java front end and a new PRE implementation?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23347
--- Comment #9 from steven at gcc dot gnu dot org 2009-02-22 16:29 ---
>3 years of inaction. What is going to be done about this?
--
steven at gcc dot gnu dot org changed:
What|Removed |Ad
--- Comment #7 from steven at gcc dot gnu dot org 2009-02-22 16:21 ---
Works with gcc 4.3, 4.4.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from steven at gcc dot gnu dot org 2009-02-22 14:32 ---
If it works with one debian version, but not another, isn't it something you
should report to debian as their problem, then? It is impossible to tell what
is going on without knowing/understanding the diffe
--- Comment #7 from steven at gcc dot gnu dot org 2009-02-22 14:27 ---
Works for me on a machine limited to 512MB (tops at <300MB, which is
unfortunately a small footprint by GCC's current standard).
--
steven at gcc dot gnu dot org changed:
What
--- Comment #15 from steven at gcc dot gnu dot org 2009-02-22 14:23 ---
Re. Comment #14 -- Fixed on AIB?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23940
--- Comment #10 from steven at gcc dot gnu dot org 2009-02-22 14:19 ---
What happened with the alloca patch? Looks like it was never committed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29442
--- Comment #22 from steven at gcc dot gnu dot org 2009-02-22 14:15 ---
"Last modified" is long ago. Richi, you added it to the daily testers. How is
it doing there?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12392
--- Comment #3 from steven at gcc dot gnu dot org 2009-02-22 14:14 ---
I can't reproduce this on i686-cygwin, i686-linux, and x86_64-linux with GCC
4.3.3 and with current trunk (r144372).
--
steven at gcc dot gnu dot org changed:
What|Re
--- Comment #4 from steven at gcc dot gnu dot org 2009-02-22 14:11 ---
Test case has disappeared, and should have been in bugzilla anyway instead of
on a website -> INVALID.
--
steven at gcc dot gnu dot org changed:
What|Removed |Ad
--- Comment #3 from steven at gcc dot gnu dot org 2009-02-22 14:06 ---
All leaks from the posted patch were plugged.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from steven at gcc dot gnu dot org 2009-02-22 14:01 ---
Trees were refactored, and we currently have:
struct tree_base
{
ENUM_BITFIELD(tree_code) code : 16;
/* 48 bits for various bitfield flags */
union tree_ann_d *ann;
} /* So on a 64-bit host this is 128bits
--- Comment #50 from steven at gcc dot gnu dot org 2009-02-22 13:39 ---
Honza, you realize that the numbers are completely unreadable in bugzilla,
right?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14179
--- Comment #5 from steven at gcc dot gnu dot org 2009-02-22 12:59 ---
Indeed.
But Rob, Pinski has a point: There really are better things to spend your time
on than building development branches. Such branches are often highly
experimental or very unstable, so bugs are not usually
--- Comment #4 from steven at gcc dot gnu dot org 2009-02-22 12:56 ---
> Did you ever read: http://gcc.gnu.org/svn.html#devbranches
>
> The "miro branch" is listed under "Active Development Branches".
Well, it doesn't look active to me.
Seb, please d
--- Comment #2 from steven at gcc dot gnu dot org 2009-02-22 12:21 ---
"creating MIRO (Mudflap Improved with Referent Objects) branch"
Seb?
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from steven at gcc dot gnu dot org 2009-02-21 22:25 ---
Confirmed, then... I've tested 3.4, 4.1, and 4.3. I suppose 4.2 is the same.
--
steven at gcc dot gnu dot org changed:
What|Removed |
--- Comment #23 from steven at gcc dot gnu dot org 2009-02-21 22:17 ---
What is the "Assigned:" field worth if nothing happens for 3 years?
How about just moving this one to SUSPENDED?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26266
--- Comment #105 from steven at gcc dot gnu dot org 2009-02-21 19:04
---
SCC as in SCCVN
DFS = Depth First Search
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
--- Comment #10 from steven at gcc dot gnu dot org 2009-02-21 16:09 ---
OK, I checked what we're PREing here. This is indeed partial-partial PRE.
I suppose something like the following is a good idea. I'll admit it's
brute-force, but I'm not sure how else to stop
--- Comment #9 from steven at gcc dot gnu dot org 2009-02-21 15:25 ---
It looks like this is some kind of quadratic insertion problem, maybe PPRE
after all. I hacked GCSE a bit to see what is going on.
I fist counted the number basic blocks and edges per function, the number of
--- Comment #8 from steven at gcc dot gnu dot org 2009-02-19 19:57 ---
Indeed the same issue.
*** This bug has been marked as a duplicate of 36439 ***
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from steven at gcc dot gnu dot org 2009-02-19 19:57 ---
*** Bug 39210 has been marked as a duplicate of this bug. ***
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from steven at gcc dot gnu dot org 2009-02-17 06:31 ---
Investigating...
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo
--- Comment #1 from steven at gcc dot gnu dot org 2009-02-16 23:13 ---
Hours is excessive alright.
Unfortunately, there are a couple of things missing to reproduce your problem.
There has to be at least a test case (preprocessed source), and the output of
gcc when you compile the test
--- Comment #15 from steven at gcc dot gnu dot org 2009-02-13 10:03 ---
Re. Comment #14
No, this is not crazy. It is called postreload-gcse. But it is a stupid pass
that doesn't handle all cases it ought to handle.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38134
--- Comment #20 from steven at gcc dot gnu dot org 2009-02-13 07:44 ---
Re: "Moving loop invariants out of this loop might help if it detected as a
loop, but I don't know how to check whether it is." (Comment #19):
It's not like there will not be any loop invaria
--- Comment #8 from steven at gcc dot gnu dot org 2009-02-12 12:49 ---
If there is a test case that compiles in less than 4GB, I'll take this bug (I
have no access to machines with more memory than that ;-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39157
--- Comment #6 from steven at gcc dot gnu dot org 2009-02-12 12:01 ---
In the past, we did not unfactor them (see e.g. Bug 15242).
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from steven at gcc dot gnu dot org 2009-02-12 11:26 ---
Even for code with lots of computed gotos, the CFG should not be fully
connected. We factorize computed gotos to avoid exactly that. At least we used
to. Maybe the factorizing is broken, or it is undone somewhere
--- Comment #2 from steven at gcc dot gnu dot org 2009-02-08 14:20 ---
No news since almost two years ago. Is this still a problem?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from steven at gcc dot gnu dot org 2009-02-08 14:17 ---
No news for almost three years. Where are we with this one today?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from steven at gcc dot gnu dot org 2009-02-08 14:15 ---
This is a really old bug with no changes for a long time. Could someone check
whether there still is an issue here, and if so, confirm the bug?
Uros, I added you because you seem to be interested in Alpha lately
--- Comment #3 from steven at gcc dot gnu dot org 2009-02-08 14:13 ---
This is a really old bug. Since 2005, a lot has happened in GCC. Could
someone interested in AVR please check whether this is still an issue?
--
steven at gcc dot gnu dot org changed:
What
--- Comment #7 from steven at gcc dot gnu dot org 2009-02-06 22:43 ---
Then they should be grouped. And kept grouped.
Here's one case where there has to be a trade-off between micro-optimizations
for specific cases, and compile time for everyone. Please, for once, let us
seri
--- Comment #5 from steven at gcc dot gnu dot org 2009-02-06 22:17 ---
Unable to reproduce. Seems to work, even!
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from steven at gcc dot gnu dot org 2009-02-06 22:16 ---
Looks like it really was a dup. Can't reproduce it anymore now, anyway.
--
steven at gcc dot gnu dot org changed:
What|Removed |
--- Comment #1 from steven at gcc dot gnu dot org 2009-02-06 22:01 ---
Confirmed with r143992. The tail call is correctly identified in the
.final_cleanup dump, but not expanded to a tail call.
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from steven at gcc dot gnu dot org 2009-02-06 21:53 ---
Could be added to PPRE.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from steven at gcc dot gnu dot org 2009-02-06 21:52 ---
Confirmed. Looks like something for postreload-gcse to handle. Before that,
there are no partial redundancies in the RTL (at least, not in the quick look I
gave it).
--
steven at gcc dot gnu dot org changed
--- Comment #3 from steven at gcc dot gnu dot org 2009-02-06 21:46 ---
ping?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33524
--- Comment #1 from steven at gcc dot gnu dot org 2009-02-06 21:45 ---
This would be fixed if someone would fix the Sign Extension Elimination pass
(yes, it also handles zero extensions). But that pass is probably broken
beyond repair at this point, and likely needs a rewrite instead
--- Comment #3 from steven at gcc dot gnu dot org 2009-02-06 21:43 ---
c4x is no longer supported.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from steven at gcc dot gnu dot org 2009-02-06 21:41 ---
We have a new candidate: bswap optimization.
Diego's idea to do "a single scan that calls back to all these transformations
on every statement" really still sounds like The Right Thing to do.
--
--- Comment #3 from steven at gcc dot gnu dot org 2009-02-06 21:39 ---
Confirmed with GCC 4.3 (ubuntu).
I recently fixed one of the worst bottlenecks in the 'expand' phase, so this
may be fixed in GCC 4.4.
--
steven at gcc dot gnu dot org changed:
What
--- Comment #3 from steven at gcc dot gnu dot org 2009-02-06 21:35 ---
GCC 3.3 is not supported anymore.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from steven at gcc dot gnu dot org 2009-02-06 21:34 ---
Confirmed with gcc 4.3. Where do we stand today?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from steven at gcc dot gnu dot org 2009-02-06 21:21 ---
GCC has the bt-load optimization for this. But this code is not enabled for
ia64. It could be so simple as just setting flag_branch_target_optimize{,2} to
true in the ia64 backend, but maybe more work is needed (I
701 - 800 of 3051 matches
Mail list logo
