--- Comment #42 from steven at gcc dot gnu dot org 2009-10-08 11:06 ---
Add Matz, following comment #40. Micha, maybe you can open a separate bug
report for the issues you mention in your mail
(http://gcc.gnu.org/ml/fortran/2009-08/msg00200.html) and make that new PR
block this
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #6 from steven at gcc dot gnu dot org 2009-10-19 15:42 ---
You should not depend on NOTE_INSN_SWITCH_TEXT_SECTIONS. There are other ways
to see if a jump goes from one section to another: edge->flags & EDGE_CROSSING
(preferred), and REG_CROSSING_JUMP notes (more reli
--- Comment #5 from steven at gcc dot gnu dot org 2009-10-19 17:34 ---
You can't merge no-exception and exception code, it seems. Should exceptions
be enabled per-function for LTO?
--
steven at gcc dot gnu dot org changed:
What|Removed |
--- Comment #3 from steven at gcc dot gnu dot org 2009-10-23 19:35 ---
There is already a patch for this one.
Paolo, can you perhaps (as build system maintainer) foster-parent it that patch
into the trunk?
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from steven at gcc dot gnu dot org 2009-10-23 19:38 ---
This one should just be monitored from week to week. There is so much stuff
going into the trunk right now that results vary from one day to another by +5%
to -5% in the last four days alone.
--
steven at gcc dot
--
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 2009-10-29 10:57 ---
Mine. Investigating.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from steven at gcc dot gnu dot org 2007-04-27 21:43 ---
I suppose this is something that requires new builtins?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from steven at gcc dot gnu dot org 2007-04-28 09:53 ---
Can we PLEASE make this a fatal error instead of a warning?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from steven at gcc dot gnu dot org 2007-04-28 09:56 ---
Re. comment #8, I have to disagree. Add some flag to disable some optimization
(DOM iiuc) and you do have a code generation regression.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31130
--- Comment #11 from steven at gcc dot gnu dot org 2007-04-28 21:32 ---
Can this go into gcc 4.2?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from steven at gcc dot gnu dot org 2007-04-29 10:07 ---
This will not be backported to GCC 4.1.
Thanks for catching this, it's very helpful to find bugs that won't be resolved
in released compilers. There are already enough bugs in Bugzilla that do have
to be
--- Comment #1 from steven at gcc dot gnu dot org 2007-04-29 17:50 ---
Why is this a bug in your opinion? ERF and the Bessel functions are MIL/GNU
extensions. I don't think there's a standard that requires these functions to
be elemental. Do you think this is a bug b
--
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 #3 from steven at gcc dot gnu dot org 2007-04-30 12:01 ---
There are at least 2 issues here:
1) We just lose the locus of the goto statements when we lower GIMPLE and when
we jump across forwarded blocks.
2) When we don't lose the locus in GIMPLE, we lose it in cfge
--- Comment #20 from steven at gcc dot gnu dot org 2007-05-06 11:10 ---
Re. comment #19: What "code size regression"? Your comment is too unspecific.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31360
--- Comment #22 from steven at gcc dot gnu dot org 2007-05-06 18:10 ---
Again, please be specific: Please identify the benchmark, the file, maybe even
the function, and extra bonus for figuring out what causes the size to
increase.
I don't understand why you expect anyone to go f
--- Comment #3 from steven at gcc dot gnu dot org 2007-05-06 18:31 ---
Added link to patch that should have fixed this bug.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from steven at gcc dot gnu dot org 2007-05-07 04:14 ---
Yup. So the heuristic to just move everything out of the loop needs another
tweak. This is sort-of the reverse of the problem for Bug 31360.
Adding Mark to put this bug on his radar.
--
steven at gcc dot gnu
--- Comment #3 from steven at gcc dot gnu dot org 2007-05-08 23:15 ---
This patch would fix it, but it's brute-force and it causes a ~1.5% slowdown.
Some form of DCE a little more delicate than this will be necessary to fix this
bug, though.
Index: cfgclea
--- Comment #4 from steven at gcc dot gnu dot org 2007-05-09 07:06 ---
Investigating...
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo
--- Comment #5 from steven at gcc dot gnu dot org 2007-05-09 18:45 ---
The cause of this bug is obvious. We move insns out of the loop either by
emitting the SET_SRC of an insn before the loop, or by reordering the insns
such that the invariant SET is moved into the pre-header. The
--- Comment #2 from steven at gcc dot gnu dot org 2007-05-10 07:13 ---
Try compiling with "--param min-crossjump-insns=1". I'm curious to hear if
that fixes this problem for you.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31889
--- Comment #7 from steven at gcc dot gnu dot org 2007-05-11 00:14 ---
Patch posted...
Waiting for Richard Earnshaw to confirm whether this fixes his problem, and
also waiting for some performance numbers.
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from steven at gcc dot gnu dot org 2007-05-11 18:22 ---
For "convert" the issue is caused by a decision that reload makes, but I don't
understand why. The .lreg dump is this:
;; Start of basic block 2, registers live: 5 [di] 6 [bp] 7 [sp] 16 [argp] 20
--- Comment #5 from steven at gcc dot gnu dot org 2007-05-11 18:26 ---
For gcc 3.4, same function convert, lreg:
;; Register 60 in 5.
;; Register 62 in 0.
(note:HI 2 0 27 NOTE_INSN_DELETED)
;; Start of basic block 0, registers live: 5 [di] 6 [bp] 7 [sp] 16 [argp] 20
[frame]
(note:HI
--- Comment #6 from steven at gcc dot gnu dot org 2007-05-11 18:28 ---
Note that with SVN gcc 4.3 (20070506) lreg actually _does_ tie reg 58 and reg
21 in lreg:
;; Register 58 in 21.
;; Register 59 in 5.
But we then fail due to the confict, I think.
--
http://gcc.gnu.org/bugzilla
--- Comment #7 from steven at gcc dot gnu dot org 2007-05-11 21:42 ---
This bug is beyond my regalloc/reload fu, so unassigning...
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from steven at gcc dot gnu dot org 2007-05-11 21:51 ---
There doesn't seem to be another way to get this to work, than the proposed way
with extra basic blocks. The things I've tried either break gcc, or gdb, or
debug info. Unassigning.
--
steven at gcc d
--- Comment #9 from steven at gcc dot gnu dot org 2007-05-12 18:47 ---
I also looked at "load" but it is fixed on the dataflow branch, which will be
merged into the trunk soon (and thereby fixing this bug).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30961
--- Comment #9 from steven at gcc dot gnu dot org 2007-05-12 19:13 ---
Subject: Bug 31848
Author: steven
Date: Sat May 12 18:12:54 2007
New Revision: 124639
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124639
Log:
PR rtl-optimization/31848
* loop-inv
--- Comment #10 from steven at gcc dot gnu dot org 2007-05-13 09:13 ---
Should be fixed now, but I'll put this into the WAITING state pending
confirmation from the reporter that this patch really fixes the issue for him..
--
steven at gcc dot gnu dot org changed:
--- Comment #22 from steven at gcc dot gnu dot org 2007-05-25 20:32 ---
With the current implementation of SEE it is almost impossible to make it work
on x86. You have to take into account the liveness of the flags register, and
there currently is no way to include that in the dataflow
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|steven at gcc dot gnu dot |unassigned at gcc dot gnu
|org
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|steven at gcc dot gnu dot |unassigned at gcc dot gnu
|org
--- Comment #4 from steven at gcc dot gnu dot org 2007-05-25 20:35 ---
Something in the backward pass increases the register pressure, inducing extra
spills. Not much can be done about this except for tuning the transformations
involved.
--
steven at gcc dot gnu dot org changed
--- Comment #5 from steven at gcc dot gnu dot org 2007-06-03 11:47 ---
Re. comment #3:
Wow. Thanks for your encouraging comment. Now people know not to waste time on
your bugs, because you're just another rude complaining troll.
Oh, wait... Maybe not.
Fortunately, most p
--- Comment #7 from steven at gcc dot gnu dot org 2007-07-11 21:42 ---
The proposed patch (http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01098.html)
breaks library compatibility. Is this intentional?
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Additional Comments From steven at gcc dot gnu dot org 2005-08-31
21:38 ---
Can the alias gurus please give their view on this one?
--
What|Removed |Added
--- Additional Comments From steven at gcc dot gnu dot org 2005-09-01
11:22 ---
This also appears to be a source of compile time problems.
--
What|Removed |Added
--- Additional Comments From steven at gcc dot gnu dot org 2005-09-01
11:37 ---
I'll have a look at this.
--
What|Removed |Added
AssignedTo|unassigned at gc
--- Additional Comments From steven at gcc dot gnu dot org 2005-09-02
11:21 ---
Not reconfirmed for almost a year.. Is this still an issue?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11824
--- Additional Comments From steven at gcc dot gnu dot org 2005-09-02
11:24 ---
Kazu, is this still not optimized properly?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14583
--- Additional Comments From steven at gcc dot gnu dot org 2005-09-05
21:14 ---
Without a test case, the bug report is invalid even if you're seeing a
legitimate bug. That's why it is closed as INVALID. Bugs are put in
the SUSPENDED state if the problem is reproducib
--- Additional Comments From steven at gcc dot gnu dot org 2005-09-10
14:56 ---
If I replace the declaration of a in foo with,
integer :: a(0:1)
then the test does pass.
So this seems to be a problem with assumed shape arrays.
--
http://gcc.gnu.org/bugzilla
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |2005-09-
--- Additional Comments From steven at gcc dot gnu dot org 2005-09-11
23:46 ---
For the reporter: what the compiler is telling you is that your code is not
valid ISO C++. What it is not telling you is that G++ 3.3.4 did not really
actually know what is valid C++ and what is not
--- Additional Comments From steven at gcc dot gnu dot org 2005-09-13
10:27 ---
Bloody hell. Stupid bug.
Alright then, let's see if I can fix this one.
--
What|Removed |
--- Additional Comments From steven at gcc dot gnu dot org 2005-09-14
08:21 ---
(From update of attachment 7541)
Already in mainline
--
What|Removed |Added
Attachment #7541
--- Additional Comments From steven at gcc dot gnu dot org 2005-09-15
09:34 ---
Add the PR for Paolo Bonzini's SSE regalloc improvements patch.
--
What|Removed |
: missed-optimization, TREE
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: steven at gcc dot gnu dot org
CC: bonzini at gcc dot gnu dot org,gcc-bugs at gcc dot gnu
--
What|Removed |Added
BugsThisDependsOn||23911
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
--- Additional Comments From steven at gcc dot gnu dot org 2005-09-16
09:58 ---
This fixes it. Sadly only store-ccp propagates constants out of
initializers right now, which is a separate bug -- we _do_ find the
constant in the initializer... but then we don't propagate i
--- Additional Comments From steven at gcc dot gnu dot org 2005-09-16
10:39 ---
The reason why this only happens in store-ccp is this:
/* If we are not doing store-ccp, statements with loads
and/or stores will never fold into a constant. */
if (!do_store_ccp
EC benchmark candidate.
--
Summary: ICE trying to fold_convert a REAL_TYPE to a RECORD_TYPE
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P2
Component: fortran
--
What|Removed |Added
BugsThisDependsOn||23922
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15502
--- Additional Comments From steven at gcc dot gnu dot org 2005-09-16
16:53 ---
Huh, I better look at this bug then, eh?
--
What|Removed |Added
AssignedTo
--- Additional Comments From steven at gcc dot gnu dot org 2005-09-16
17:01 ---
Not being a C++ fan, I reduced it to this C test case:
==
extern int *F2 (void) __attribute__ ((__const__));
void
S4 (int *i)
{
int *D2171;
D2171 = F2 ();
L0
--- Additional Comments From steven at gcc dot gnu dot org 2005-09-17
23:53 ---
It is hardly a DOM bug. More an oversight. Probably easily fixed.
--
What|Removed |Added
--- Additional Comments From steven at gcc dot gnu dot org 2005-09-18
10:37 ---
DJ, apparently you caused this one.
--
What|Removed |Added
CC
--- Additional Comments From steven at gcc dot gnu dot org 2005-09-18
10:41 ---
Re. comment #24 -- I guess Devang didn't update fold_stmt and similar
functions for the (still undocumented) modification to GIMPLE to make
>> valid.
--
http://gcc.gnu.org/bugzilla/s
--- Additional Comments From steven at gcc dot gnu dot org 2005-09-18
11:23 ---
Janis, could you please unleash your binary search scripts on this one?
--
What|Removed |Added
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: steven at gcc dot gnu dot or
--- Additional Comments From steven at gcc dot gnu dot org 2005-09-18
12:15 ---
Created an attachment (id=9762)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9762&action=view)
Test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23946
--- Additional Comments From steven at gcc dot gnu dot org 2005-09-18
12:57 ---
This is bogus RTL:
(compare:CCZ (mem/s:QI (plus:DI (expr_list:REG_DEP_TRUE (use (mem:BLK
(scratch)
[0 A8]))
It looks like the bug is introduced earlier.
--
http://gcc.gnu.org/bugzilla
--- Additional Comments From steven at gcc dot gnu dot org 2005-09-18
13:10 ---
CPROP1 introduces a gem of a fined up REG_EQUAL note:
(insn 20 16 21 0 (set (reg:CCZ 17 flags)
(compare:CCZ (mem/s:QI (plus:DI (plus:DI (reg:DI 62)
(reg/f:DI 60
--- Additional Comments From steven at gcc dot gnu dot org 2005-09-18
13:20 ---
After the first local_cprop, the insn stream still looks sane.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23943
--- Additional Comments From steven at gcc dot gnu dot org 2005-09-18
13:30 ---
hm, it's not even a REG_EQUAL note, but something else...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23943
--- Additional Comments From steven at gcc dot gnu dot org 2005-09-18
14:13 ---
The problematic RTL is produced in cse.c:find_best_addr(),
Breakpoint 12, find_best_addr (insn=0x2a95a5d820, loc=0x2a95a64ac8,
mode=QImode) at cse.c:3004
3004rtx new
--- Additional Comments From steven at gcc dot gnu dot org 2005-09-18
14:27 ---
Not being even closely an RTL guru (as you can see in this bug audit trail ;-)
I'd propose the following patch:
Index: cse.c
===
RCS
--- Additional Comments From steven at gcc dot gnu dot org 2005-09-18
15:11 ---
Smaller test case:
static unsigned short int crc_table[256];
void AC3_encode_init(void)
{
unsigned int c, n;
for (n = 0; n < 256; n++)
{
c = n << 8;
if (c & 16384)
--- Additional Comments From steven at gcc dot gnu dot org 2005-09-18
15:59 ---
Actually fold_stmt has nothing to do with it. It is fold (cached_lhs) in
trhead_across_edge that is the problem here. Jeff, what do you think about
this patch?
Index: tree-ssa-dom.c
--- Additional Comments From steven at gcc dot gnu dot org 2005-09-19
00:07 ---
I'll look at the "load CSE after reload" (postreload-gcse, gddmmtgrmbl!),
which I've looked at before.
The top functions in the profile of the report are from RTL alias an
--- Additional Comments From steven at gcc dot gnu dot org 2005-09-19
00:15 ---
Another SSA operands cache slowness example...
--
What|Removed |Added
CC
--- Additional Comments From steven at gcc dot gnu dot org 2005-09-19
05:08 ---
Fixed by my patch, but the issue would have disappeared with Honza's patch to
remove libcalls for standard library function calls anyway (my fix is still
necessary to prevent the bug from resurfaci
ice-on-valid-code
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: steven at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23960
--- Additional Comments From steven at gcc dot gnu dot org 2005-09-19
11:07 ---
Even the bad timings for postreload-gcse are almost entirely to blame on RTL
alias analysis:
CPU: P4 / Xeon with 2 hyper-threads, speed 3194.18 MHz (estimated)
Counted GLOBAL_POWER_EVENTS events (time
--- Additional Comments From steven at gcc dot gnu dot org 2005-09-21
15:02 ---
Let's fix this.
--
What|Removed |Added
AssignedTo|unassigned at gcc do
--- Additional Comments From steven at gcc dot gnu dot org 2005-09-29
12:40 ---
.
--
What|Removed |Added
Status|NEW |RESOLVED
--
Bug 19721 depends on bug 23911, which changed state.
Bug 23911 Summary: Failure to propagate constants from a const initializer for
_Complex
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23911
What|Old Value |New Value
--
Bug 23111 depends on bug 23911, which changed state.
Bug 23911 Summary: Failure to propagate constants from a const initializer for
_Complex
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23911
What|Old Value |New Value
--- Additional Comments From steven at gcc dot gnu dot org 2005-09-29
15:38 ---
A number of xfailed tests in the tree-ssa test suite (e.g. bool-3.c) should
start working if you add a tree combiner.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15459
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot
|dot org |org
Status|NEW
--- Additional Comments From steven at gcc dot gnu dot org 2005-09-30
12:46 ---
Hmmm... vrp_meet merges ~[1,1] and [1,1] to [0,0]:
3489 vrp_meet (&vr_result, &vr_arg);
(gdb) p vr_result
$21 = {type = VR_ANTI_RANGE, min = 0x2a958a8750, max = 0x2a958a875
--- Additional Comments From steven at gcc dot gnu dot org 2005-09-30
12:59 ---
range_includes_zero_p (~[1,1]) is false:
(gdb) step
range_includes_zero_p (vr=0x7fbfffedd0) at tree-vrp.c:606
606 gcc_assert (vr->type != VR_UNDEFINED
(gdb) p vr
$43 = (value_rang
--- Additional Comments From steven at gcc dot gnu dot org 2005-09-30
13:31 ---
Yes. I have a patch too, but it doesn't work yet ;-) So if you could
attach yours or mail it to me, that'd be nice.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24141
--- Additional Comments From steven at gcc dot gnu dot org 2005-09-30
13:43 ---
Fixing value_inside_range to understand the difference between a VR_RANGE
and a VR_ANTI_RANGE exposes other problems (most likely related to PR23604)
which Diego is trying to fix. So I'm assigning
--- Additional Comments From steven at gcc dot gnu dot org 2005-09-30
13:46 ---
I'm not so sure that this is a dup. Bug 24141 is a wrong-code problem,
and this is an ICE. Just the fact that the same test case triggers both
bugs doesn't mean they are the sa
--- Additional Comments From steven at gcc dot gnu dot org 2005-09-30
15:51 ---
Maybe an Ada maintainer could at least confirm the bug?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21717
--- Additional Comments From steven at gcc dot gnu dot org 2005-09-30
22:09 ---
In fact, combine also doesn't catch this for me on AMD64.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14847
--- Additional Comments From steven at gcc dot gnu dot org 2005-09-30
22:29 ---
For AMD64, the functions from the first test case don't produce the
same code either, so combine is not catching this either.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15348
--- Comment #3 from steven at gcc dot gnu dot org 2005-10-03 06:14 ---
No it is not.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
BugsThisDependsOn
--- Comment #34 from steven at gcc dot gnu dot org 2005-10-07 14:09 ---
This is basically unfixable without serious hacking that is not appropriate for
GCC 3.4, so Gaby, with your permission, I'd like to close this one as
WONTFIX...
--
steven at gcc dot gnu dot org ch
--- Comment #36 from steven at gcc dot gnu dot org 2005-10-07 20:06 ---
Not really fixable for 3.4.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from steven at gcc dot gnu dot org 2005-10-07 21:11 ---
I think I have every right to complain after what happened to
e.g. the CD-DCE patch, thank you very much. FY.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from steven at gcc dot gnu dot org 2005-10-07 21:12 ---
Oh, and for the record, if you don't care about compile time, fine, but SAY SO
and say it in public so people know that even the top gcc hacker doesn't give
shit about compile time, and so that I can stop
--- Comment #14 from steven at gcc dot gnu dot org 2005-10-07 21:21 ---
I don't have time to work on these (new job), so unassigning.
--
steven at gcc dot gnu dot org changed:
What|Removed |
--- Comment #3 from steven at gcc dot gnu dot org 2005-10-07 21:21 ---
I don't have time to work on these (new job), so unassigning.
--
steven at gcc dot gnu dot org changed:
What|Removed |
--- Comment #8 from steven at gcc dot gnu dot org 2005-10-07 21:21 ---
I don't have time to work on these (new job), so unassigning.
--
steven at gcc dot gnu dot org changed:
What|Removed |
1201 - 1300 of 3051 matches
Mail list logo
