--- Comment #4 from steven at gcc dot gnu dot org 2006-04-10 19:49 ---
Boooiinngg...
Or, is anyone working on this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7625
--- Comment #4 from steven at gcc dot gnu dot org 2006-04-10 19:57 ---
GCC 3.4 did better, said the reporter in comment #0.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from steven at gcc dot gnu dot org 2006-04-10 20:18 ---
The resulting code for -march=opteron:
test_bit:
.LFB2:
leal63(%rsi), %edx
testl %esi, %esi
movl%esi, %eax
cmovns %esi, %edx
sarl$31, %eax
shrl$26
--- Comment #3 from steven at gcc dot gnu dot org 2006-04-10 20:31 ---
This is what the i386 machine description has to say about BT and friends:
;; %%% bts, btr, btc, bt.
;; In general these instructions are *slow* when applied to memory,
;; since they enforce atomic operation. When
--- Comment #8 from steven at gcc dot gnu dot org 2006-04-11 23:03 ---
Code size issue
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO
--- Comment #12 from steven at gcc dot gnu dot org 2006-04-12 21:28 ---
fold_truthop is called with this input:
Breakpoint 11, fold_truthop (code=TRUTH_ANDIF_EXPR, truth_type=0x2adff4d0,
lhs=0x2adf64b0, rhs=0x2adf6690) at fold-const.c:4820
4820 if
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
CC||rth at gcc dot gnu dot org
Status|UNCONFIRMED
--- Comment #7 from steven at gcc dot gnu dot org 2006-04-20 20:53 ---
I have tested this test case again with lcm.c patched with the patch below to
check for insertions on edges where an expression is already available. The
abort does not trigger.
The version of GCC that I patched and
--- Comment #8 from steven at gcc dot gnu dot org 2006-04-20 21:13 ---
Created an attachment (id=11306)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11306&action=view)
CFG at the start of gcse
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16967
--- Comment #9 from steven at gcc dot gnu dot org 2006-04-20 21:14 ---
Created an attachment (id=11307)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11307&action=view)
LCM dataflow solution for the first gcse pass
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16967
--- Comment #10 from steven at gcc dot gnu dot org 2006-04-20 21:15 ---
Created an attachment (id=11308)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11308&action=view)
LCM dataflow solution for the second gcse pass
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16967
--- Comment #11 from steven at gcc dot gnu dot org 2006-04-20 21:16 ---
One of these days someone should manually compute the LCM sets from attachments
1, 2, and 3 ...
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from steven at gcc dot gnu dot org 2006-04-24 22:28 ---
Reporter has disappeared. No-one has complained about this in recent GCCs (i.e.
open branches) so closing as WONTFIX.
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #11 from steven at gcc dot gnu dot org 2006-04-24 22:29 ---
Still an issue here??
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from steven at gcc dot gnu dot org 2006-04-24 22:32 ---
Works for me. Works for the reporter. I say this works.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from steven at gcc dot gnu dot org 2006-04-24 22:34 ---
What are loop notes again? Ah, yes. Legacy. Fixed on mainline.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from steven at gcc dot gnu dot org 2006-04-24 22:37 ---
I'm sure Zdenek would argue that strength reduction is not the unroller's task
(and fwiw I agree), and Joern would argue that it is. Either way, this is a
valid bug report.
--
steven at gcc dot g
--- Comment #9 from steven at gcc dot gnu dot org 2006-04-24 22:44 ---
The loop optimizer in gcc 4.2 has lots of changes. How does it perform for
this code now?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from steven at gcc dot gnu dot org 2006-04-24 22:45 ---
Has this one fallen through the cracks?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from steven at gcc dot gnu dot org 2006-04-24 22:51 ---
I'm inclined to say "don't do this" but i can see why this is a problem for the
reporter. I can't reproduce the issue myself, though. Tom, do you still see a
problem here? Sor
--- Comment #2 from steven at gcc dot gnu dot org 2006-04-27 19:10 ---
Patches addressing some of the issues:
http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00969.html
http://gcc.gnu.org/ml/gcc-patches/2006-04/msg01049.html
I'm linking them from here for reference.
--
--- Comment #5 from steven at gcc dot gnu dot org 2006-04-27 20:46 ---
So I asked myself, why are we not catching this in vrp? I know we can derive
ranges from types, so why don't we derive a [0,1] range from the bitfield load?
It turns out that we make _all_ loads VARYING right
--- Comment #7 from steven at gcc dot gnu dot org 2006-04-27 21:32 ---
Yes, BIT_IOR_EXPR is also not handled.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18031
--
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
URL||http://gcc.gnu.org/ml/gcc
--- Comment #4 from steven at gcc dot gnu dot org 2006-05-01 19:17 ---
Re. comment #2 and comment #3, yes you are expecting too much of the nonnull
attribute. The attribute only applies to function arguments, not to function
results.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #5 from steven at gcc dot gnu dot org 2006-05-01 19:19 ---
Ehm, right, ignore comment #4.
Yes it is possible.
No, it's not very practical. Your code looks like,
bool f(A *a) {
g(a);
return a;
}
to the middle end. It would take a significant amount of extra wo
--- Comment #1 from steven at gcc dot gnu dot org 2006-05-02 16:57 ---
Index: parse.c
===
--- parse.c (revision 113473)
+++ parse.c (working copy)
@@ -624,6 +624,7 @@ next_statement (void)
if (gfc_at_eol
--- Comment #4 from steven at gcc dot gnu dot org 2006-05-02 17:38 ---
The inner loop in the .cunroll, .ivopts and .final_cleanup with GVN-PRE
disabled look like this:
# Int_Index_37 = PHI ;
:;
(*D.1561_56)[Int_Index_37] = Int_Loc_3;
Int_Index_58 = Int_Index_37 + 1;
if (D
--- Comment #7 from steven at gcc dot gnu dot org 2006-05-03 21:33 ---
Re. comment #5, user code could also have a CFG like that, so we should handle
this case properly (and we do, tree-ch is doing the right thing afaict). Re.
comment #6, I don't see what the register allocator h
--- Comment #17 from steven at gcc dot gnu dot org 2006-05-04 21:10 ---
Too old. Upgrade. :-)
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from steven at gcc dot gnu dot org 2006-05-05 18:42 ---
Bud already voted to close this in comment #11 :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21130
--- Comment #2 from steven at gcc dot gnu dot org 2006-05-13 09:45 ---
Index: alpha.c
===
--- alpha.c (revision 113736)
+++ alpha.c (working copy)
@@ -7410,6 +7410,7 @@ alpha_does_function_need_gp (void)
for
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |sayle at gcc dot gnu dot org
|dot org
--- Comment #9 from steven at gcc dot gnu dot org 2006-05-14 14:23 ---
Please take bugs if you post patches for them, it makes it easier to search for
bugs that nobody is looking at.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from steven at gcc dot gnu dot org 2006-05-14 14:25 ---
Seb, wrong code regression in your code. Are you working on this??
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26719
--- Comment #7 from steven at gcc dot gnu dot org 2006-05-15 04:36 ---
Investigating a fix.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from steven at gcc dot gnu dot org 2006-05-15 19:55 ---
No need for investigation anymore :-)
--
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 #13 from steven at gcc dot gnu dot org 2006-05-24 06:08 ---
Re. comment #12, my copy of the June 1997 Fortran 95 draft is very clear
assuming we agree that there is no default initialization for this pointer.
14.6.2.1 Pointer association status
A pointer may have a pointer
--- Comment #4 from steven at gcc dot gnu dot org 2006-05-28 09:50 ---
It is sad that this is not release critical, and even worse that the
contributor of vrp apparently can't miss half an hour to document his work as
he is required to do.
--
steven at gcc dot gnu dot org ch
--- Comment #4 from steven at gcc dot gnu dot org 2006-05-28 09:53 ---
This looks like one that the mem-ssa folks may want to give a look.
Will it be easier in mem-ssa to attach alias info to INDIRECT_REF nodes?
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from steven at gcc dot gnu dot org 2006-06-02 23:19 ---
Real bug, despite Andrew's usual portion of x86-hate.
--
steven at gcc dot gnu dot org changed:
What|Removed |
--- Comment #8 from steven at gcc dot gnu dot org 2006-06-03 23:49 ---
You could add a basic block list scheduler at the tree level just before
out-of-ssa, with heuristics to make life times as short as possible :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27855
--
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 #6 from steven at gcc dot gnu dot org 2006-06-04 09:32 ---
This should have a higher priority than P3 IMHO.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26251
--- Comment #6 from steven at gcc dot gnu dot org 2006-06-04 09:34 ---
Would be fixed with fwprop due to not recursively calling fold_rtx.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27616
--
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
AssignedTo|steven at gcc dot gnu dot |unassigned at gcc dot gnu
|org
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |NEW
Last reconfirmed|2005-11-11 18:50:50 |2006-06-05 10:19
--- Comment #8 from steven at gcc dot gnu dot org 2006-06-05 10:25 ---
Four patches for loop-invariant.c went in since comment #7, and the bug hasn't
been reconfirmed since.
http://gcc.gnu.org/ml/gcc-testresults/2006-06/msg00241.html suggests we still
have the bug. Can someone co
--- Comment #17 from steven at gcc dot gnu dot org 2006-06-05 10:27 ---
Following comment #16, closing as FIXED.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from steven at gcc dot gnu dot org 2006-06-05 10:29 ---
Just like other bugs, this one will need a test case.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from steven at gcc dot gnu dot org 2006-06-05 10:34 ---
Andrew, if you have nothing to say, don't say anything as silly as "This is
interesting".
Rainer, there is no test case and no description for how to reproduce this.
But is this still an issue at al
--- Comment #11 from steven at gcc dot gnu dot org 2006-06-05 10:37 ---
When regstack is involved, Sayle is probably the only one who can fix it for
real.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from steven at gcc dot gnu dot org 2006-06-05 10:41 ---
Unassigning rth, since he's obviously not actually interested in fixing this.
--
steven at gcc dot gnu dot org changed:
What|Removed |
--- Comment #14 from steven at gcc dot gnu dot org 2006-06-05 10:44 ---
The failures in 3.4 and later are in fold_const, so the gen_lowpart problem is
now avoided by, well, ICEing earlier :)
--
steven at gcc dot gnu dot org changed:
What|Removed
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #32 from steven at gcc dot gnu dot org 2006-06-11 08:35 ---
Issues in general are not specific enough. The question is, do we still have a
regression here.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #18 from steven at gcc dot gnu dot org 2006-06-11 08:36 ---
A pre-processed C test case would be nice.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27882
--- Comment #2 from steven at gcc dot gnu dot org 2006-06-11 08:38 ---
Are your host and build machine really mipsel-linux-gnu? Or is this a cross to
mipsel?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27861
--- Comment #11 from steven at gcc dot gnu dot org 2006-06-11 08:54 ---
This problem may be in some other place than expand. rebuild_jump_labels for
example can also add REG_LABEL notes.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27531
--- Comment #2 from steven at gcc dot gnu dot org 2006-06-11 08:55 ---
I can't reproduce this with ToT.
--
steven at gcc dot gnu dot org changed:
What|Removed |
--- Comment #12 from steven at gcc dot gnu dot org 2006-06-11 09:21 ---
The offending insns for me are (using -dAP):
!(insn 315 243 316 (set (reg/f:SI 19 %l3 [167])
!(high:SI (label_ref:SI 123))) 40 {*movsi_high} (nil)
!(nil))
sethi %hi(.LL20), %l3 ! 315
--- Comment #13 from steven at gcc dot gnu dot org 2006-06-11 09:34 ---
I spoke too soon. The code_label that is removed for me is code_label 123,
which disappears after flow2. Calling rebuild_jump_labels at the end of
rest_of_handle_flow2 makes the problem disappear for me, but that
--- Comment #14 from steven at gcc dot gnu dot org 2006-06-11 09:55 ---
This hacks around this particular problem.
Not a fix, you know, but it explains what is going wrong here.
Index: reload1.c
===
--- reload1.c
--- Comment #35 from steven at gcc dot gnu dot org 2006-06-11 20:28 ---
Re. comment #34: Read comment #31. If one bug is used for (at least) two
different problems, confusion is what you get.
Anyway, your patch is apparently still unreviewed...?
--
http://gcc.gnu.org/bugzilla
--- Comment #2 from steven at gcc dot gnu dot org 2006-06-12 19:43 ---
This will never be implemented.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from steven at gcc dot gnu dot org 2006-06-13 04:22 ---
Could it be an issue on the autovect branch?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from steven at gcc dot gnu dot org 2006-06-13 20:26 ---
The solution is "don't do -fschedule-insns on x86".
Unless you first add heuristics in the scheduler to keep a better eye on
register pressure, and fix the many known bugs in scheduling for x86.
--
--- Comment #12 from steven at gcc dot gnu dot org 2006-06-14 05:28 ---
.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #2 from steven at gcc dot gnu dot org 2006-06-17 10:18 ---
It actually does finish for me at -O with gcc 4.0.2. It just takes an
incredible amount of time and memory, but that doesn't surprise me so much,
given the nature of this evil test case ;-)
With gcc 4.2 200606
--- Comment #3 from steven at gcc dot gnu dot org 2006-06-17 11:05 ---
Caused by excessive inlining:
inline heuristics : 37.25 (25%) usr 0.04 ( 1%) sys 36.56 (15%) wall
2312 kB ( 0%) ggc
integration : 19.91 (13%) usr 1.49 (36%) sys 62.70 (26%) wall
1058857 kB
--- Comment #4 from steven at gcc dot gnu dot org 2006-06-17 11:05 ---
Platform independent. Honza, one for you I suppose.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #101 from steven at gcc dot gnu dot org 2006-06-17 22:06
---
Release folks from the I-use-C-but-do-not-understand-its-semantics punishment
list.
Seriously, though... There is no reason to spam every one of these people
every time there is another duplicate of this bug
--
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 #3 from steven at gcc dot gnu dot org 2006-06-24 13:50 ---
We ICE in fold-const.c line 1691 (r114961):
= const_binop (PLUS_EXPR,
const_binop (MULT_EXPR, r2, r2, notrunc),
const_binop (MULT_EXPR, i2, i2
--- Comment #4 from steven at gcc dot gnu dot org 2006-06-24 13:53 ---
Uhm, Richi is right. Ignore comment #4.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28151
bout wrong use _Complex prints __complex__
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy:
--- Comment #6 from steven at gcc dot gnu dot org 2006-06-24 14:13 ---
The code that causes this "regression" is actually in the first ever checkin of
fold-const.c (r330).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28151
--- Comment #7 from steven at gcc dot gnu dot org 2006-06-24 14:15 ---
The problem appears to be caused by the change of semantics of const_binop in
this patch:
2005-11-16 Eric Botcazou <[EMAIL PROTECTED]>
* fold-const.c (const_binop): Don't constant fold th
--
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 #8 from steven at gcc dot gnu dot org 2006-06-24 14:20 ---
Another test case:
_Complex float b;
int
main (void)
{
_Complex float a = __FLT_MAX__;
b = __FLT_MAX__ + a;
}
--
steven at gcc dot gnu dot org changed:
What|Removed
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #25 from steven at gcc dot gnu dot org 2006-06-28 17:30 ---
Pure luck or not, this is a regression.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from steven at gcc dot gnu dot org 2006-07-01 11:18 ---
Mark, this bug concerns a C++ standard question, perhaps you could give your
interpretation...
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from steven at gcc dot gnu dot org 2006-07-03 21:52 ---
Paul,
Since gfortran is developed by volunteers who are often gfortran users
themselves, it usually depends on the needs of the developers what gets
implemented in gfortran. Given that nobody has responded to your
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||wrong-code
Priority|P3 |P1
http
--- Comment #3 from steven at gcc dot gnu dot org 2006-07-06 08:57 ---
Uros,
You could post it now, just so that people can have a look at it and maybe
suggest some changes. You know how that goes.
It would be interesting to see if this actually gives speedups...
--
http
--- Comment #14 from steven at gcc dot gnu dot org 2006-07-09 00:34 ---
Fixed on the trunk? If so, please remove the "4.2" marker from this bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28170
--- Comment #2 from steven at gcc dot gnu dot org 2006-07-09 07:48 ---
To quote from the F95 June 97 working draft, note 12.17:
"Because an INTENT(OUT) variable is considered undefined on entry to the
procedure, any default initialization specified for its type will be applied.
--- Comment #4 from steven at gcc dot gnu dot org 2006-07-09 10:29 ---
FX, are you working on this problem?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24285
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25104
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25709
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||wrong-code
Priority|P3 |P1
http
--- Comment #18 from steven at gcc dot gnu dot org 2006-07-13 21:47 ---
Re. comment #16: That looks like you get an internal compiler error (ICE )while
building g++ which has nothing to do with libgfortran. If that ICE is
reproducible, it deserves its own bug report.
--
http
--- Comment #2 from steven at gcc dot gnu dot org 2006-07-14 16:59 ---
Enhancement request for compatibility with XLF. Not a high-priority
enhancement, but probably not very difficult to implement for a hobbyist.
--
steven at gcc dot gnu dot org changed:
What
--- Comment #9 from steven at gcc dot gnu dot org 2006-07-14 17:02 ---
The patch identified in comment #8 can't have caused the CSE problem, but it
probably exposed a latent bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27616
--- Comment #4 from steven at gcc dot gnu dot org 2006-07-15 22:58 ---
Probably latent on mainline.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28243
1 - 100 of 3051 matches
Mail list logo
