--
steven at gcc dot gnu dot org changed:
What|Removed |Added
CC||jason at gcc dot gnu dot org
Status|UNCONFIRMED
--- Comment #3 from steven at gcc dot gnu dot org 2010-09-12 17:14 ---
This is not a job for the FE.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36841
--- Comment #5 from steven at gcc dot gnu dot org 2010-09-12 21:24 ---
OK, I thought you meant that this would be something for a separate Fortran
front end optimization pass. Expanding SUM differently is a job for the FE,
yes.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36841
--- Comment #3 from steven at gcc dot gnu dot org 2010-09-11 12:58 ---
Created an attachment (id=21776)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21776action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45635
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |NEW
Ever Confirmed|0 |1
Last
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45635
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Severity|minor |enhancement
Status|UNCONFIRMED |NEW
--- Comment #2 from steven at gcc dot gnu dot org 2010-08-19 20:24 ---
Gross.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45346
--- Comment #3 from steven at gcc dot gnu dot org 2010-08-19 20:28 ---
The proper fix for this is not to just go back to the include everything
everywhere. The proper fix is instead to move struct rtl_data out of
function.h (as I have said before) and into e.g. emit-rtl.h.
--
http
--- Comment #1 from steven at gcc dot gnu dot org 2010-08-19 21:57 ---
Makefile should be changed, the reference to c-family/c-common.h is
intentionally relative to $srcdir.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #23 from steven at gcc dot gnu dot org 2010-08-18 10:50 ---
So the scheduler uses cselib to get a better view of the address, but cselib
doesn't actually give a better address. And the solution is to just give up in
that case? It seems to me that if cselib doesn't give
--- Comment #2 from steven at gcc dot gnu dot org 2010-08-18 20:58 ---
WONTFIX for an ICE seems a bit odd to me.
Just needs a diagnostic to reject nonsense target attributes, or a sorry. But
not an ICE.
--
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
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|target |middle-end
--- Comment #1 from steven at gcc dot gnu dot org 2010-08-15 19:05 ---
Is this still a problem for you? I can try to help you here, but I need to know
what patch I should apply and to what revision, to reproduce the problem.
--
steven at gcc dot gnu dot org changed:
What
--- Comment #4 from steven at gcc dot gnu dot org 2010-08-15 20:48 ---
Investigating...
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo
--- Comment #1 from steven at gcc dot gnu dot org 2010-08-13 07:22 ---
Should use sreal, then?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45273
--- Comment #1 from steven at gcc dot gnu dot org 2010-08-13 07:42 ---
Does anyone have a daily autotester for profiled-bootstrap?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #19 from steven at gcc dot gnu dot org 2010-08-12 10:00 ---
According to comment#14, a patch from Alexander Monakov introduced this bug,
therefore:
1. this is a regression on a primary platform = priority should be set P1
--
steven at gcc dot gnu dot org changed
--- Comment #20 from steven at gcc dot gnu dot org 2010-08-12 10:00 ---
...and
2. Add richi and amonakov to CC:
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644
--- Comment #21 from steven at gcc dot gnu dot org 2010-08-12 10:08 ---
Re. comment #14 I am a bit irritated why this bug survived the 4.4.0
and 4.5.0 release.: Yes, well, ARM maintainers have been in the CC-list for
this bug since the beginning, and apparently it was even too much
--- Comment #23 from steven at gcc dot gnu dot org 2010-08-12 11:37 ---
The patch from comment #16 only fixes the symptom, and only on ARM. It is not a
proper fix for the generic problem that is apparently also visible on POWER.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644
--- Comment #3 from steven at gcc dot gnu dot org 2010-08-12 21:07 ---
Re. comment #1: Looks more like that commit made this problem latent on the
trunk.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45267
--- Comment #5 from steven at gcc dot gnu dot org 2010-08-12 21:30 ---
I don't think this is a heuristics bug at all. You're not getting an error or a
warning about a missed optimization (inlining).
You get a sorry, and that only happens if GCC tries but fails to inline
--- Comment #3 from steven at gcc dot gnu dot org 2010-08-12 22:00 ---
Indeed any attempt to fix -combine for checking failures would be a waste of
resources that are better spent on LTO/WHOPR...
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from steven at gcc dot gnu dot org 2010-08-11 10:17 ---
WHOPR involved, MEM_REF involved... Richi?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from steven at gcc dot gnu dot org 2010-08-11 15:27 ---
I don't see how the compiler can know that this input causes an infinite loop.
This is just the halting problem. Not a bug in the sense that there is anything
to fix.
--
steven at gcc dot gnu dot org changed
--- Comment #5 from steven at gcc dot gnu dot org 2010-08-09 17:11 ---
http://gcc.gnu.org/ml/gcc-cvs/2009-11/msg01067.html
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from steven at gcc dot gnu dot org 2010-08-09 17:11 ---
Needs fixing in 4.4 still.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #34 from steven at gcc dot gnu dot org 2010-08-09 21:13 ---
The FIXME here is this one in varasm.c:
---
/* We delay assemble_external processing until
the compilation unit is finalized. This is the best we can do for
right now (i.e. stage
--- Comment #4 from steven at gcc dot gnu dot org 2010-08-09 21:32 ---
This blocks 17982. There are assemble_external calls are for
objc_get_class_decl, objc_assign_global_decl, and objc_assign_strong_cast_decl.
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from steven at gcc dot gnu dot org 2010-08-07 10:57 ---
Patch of comment #1 loops obviously OK to me. We shouldn't want to move
trapping insns in any case that I can think of.
--
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 #3 from steven at gcc dot gnu dot org 2010-08-06 21:24 ---
What's the plan with the patch of comment #2?
NB, the result of gfc_dep_compare_expr (l_start, r_start) could be cached
instead of computed twice:
+ ((res = gfc_dep_compare_expr (l_start, r_start)) == 0
--
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-08-06 23:02 ---
pathetic... :)
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #18 from steven at gcc dot gnu dot org 2010-08-06 23:12 ---
Martin, perhaps a test case you want to watch if you or someone else is going
to play with SRA vs. bitfields.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from steven at gcc dot gnu dot org 2010-08-06 23:17 ---
Related to PR17886, where it says that: gcc can detect the (x y)|(x
(bitwidth-y)) idiom for rotate and convert it into the machine rotate
instruction. But it only works when y is a constant and is not long long
--- Comment #3 from steven at gcc dot gnu dot org 2010-08-01 10:38 ---
Confirmed.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
CC
--- Comment #7 from steven at gcc dot gnu dot org 2010-08-01 10:40 ---
Isn't this bug description just a request for shrink-wrapping?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10474
--- Comment #3 from steven at gcc dot gnu dot org 2010-07-25 10:29 ---
VRP does this with ASSERT_EXPRs. DOM does not optimize this because bb4 has
two predecessors, and record_equivalences_from_incoming_edge only records from
a single predecessor.
This should probably be handled
--- Comment #4 from steven at gcc dot gnu dot org 2010-07-25 16:25 ---
cprop_into_successor_phis only propagates SSA_NAME_VALUEs, but not conditional
copies/constants. May be a better place to fix this bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43940
--- Comment #4 from steven at gcc dot gnu dot org 2010-07-24 12:38 ---
Subject: Bug 45035
Author: steven
Date: Sat Jul 24 12:37:51 2010
New Revision: 162499
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162499
Log:
PR middle-end/45035
* alias.c (true_dependence_1
--- Comment #5 from steven at gcc dot gnu dot org 2010-07-24 12:39 ---
.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from steven at gcc dot gnu dot org 2010-07-24 21:21 ---
IMA (-combine) = WONTFIX?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44041
--- Comment #17 from steven at gcc dot gnu dot org 2010-07-24 21:22 ---
IMA (-combine) = WONTFIX?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23104
--- Comment #2 from steven at gcc dot gnu dot org 2010-07-24 22:04 ---
Investigating...
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo
--
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 2010-07-23 08:58 ---
Somehow managed to make a mistake in the merge for the case that x_addr is
non-NULL.
Index: alias.c
===
--- alias.c (revision 162430)
+++ alias.c
--- Comment #1 from steven at gcc dot gnu dot org 2010-07-22 20:58 ---
Looks related to bug 20070.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45032
--- Comment #16 from steven at gcc dot gnu dot org 2010-07-21 08:22 ---
OK, I think I finally understand what Alexander tried to explain, and I've
annotated the code. Alexander, does this look right to you?
f1: // vector int f1(vector int t)
.mmi
--- Comment #18 from steven at gcc dot gnu dot org 2010-07-21 09:27 ---
Created an attachment (id=21277)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21277action=view)
debug log
I think the problem is that fixed_scalar_and_varying_struct_p is called with a
VALUE address, i.e
--- Comment #19 from steven at gcc dot gnu dot org 2010-07-21 09:33 ---
x_addr is a VALUE that has no locs:
Breakpoint 4, true_dependence (mem=0x205ddf68, mem_mode=VOIDmode,
x=0x205ddfb0, varies=0x20496720) at
../../trunk/gcc/alias.c:2330
2330
--- Comment #20 from steven at gcc dot gnu dot org 2010-07-21 09:49 ---
Since this bug only triggers if cselib is used, the bug affects schedule_ebbs
only. The other schedulers are !use_cselib schedulers.
(Even sel-sched apparently does not use cselib, that's surprising!)
OTOH
--- Comment #1 from steven at gcc dot gnu dot org 2010-07-21 09:54 ---
Investigating...
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo
--- Comment #3 from steven at gcc dot gnu dot org 2010-07-21 09:58 ---
Look at the ia64 port (and a few others too, e.g. blackfin), they call
compute_bb_for_insn first thing in machine reorg and that works. It is
obviously not ideal, but the only pass between free_cfg and machine_reorg
--- Comment #12 from steven at gcc dot gnu dot org 2010-07-21 20:54 ---
Fixed with MEM_REF.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from steven at gcc dot gnu dot org 2010-07-21 21:00 ---
Optimizes to an empty function for me with r162374.
Probably thanks to Martin's SRA rewrite.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
: steven at gcc dot gnu dot org
GCC target triplet: ia64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45026
--- Comment #7 from steven at gcc dot gnu dot org 2010-07-21 21:09 ---
The SRA rewrite for GCC 4.6 probably fixes the SRA part of this bug report (at
last!).
Can someone with a powerpc box have a look?
--
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 #7 from steven at gcc dot gnu dot org 2010-07-21 21:53 ---
9 years
0 progress
Tom?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from steven at gcc dot gnu dot org 2010-07-20 08:37 ---
Note, it's often helpful for us non-ARM-assembly-gurus to explain the pattern
you would like to have, instead of the mnemonic :-)
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #10 from steven at gcc dot gnu dot org 2010-07-20 13:20 ---
Re. comment 9: Well, the order of *this* store and *this* load is the
difference between the test case failing or passing. So I do not think the
problem is between this load and another store.
Before sched2
--- Comment #11 from steven at gcc dot gnu dot org 2010-07-20 13:22 ---
insn 28 and insn 9 in non-slim form, with assembler output:
//(insn:TI 28 48 9 2 vector-2.c:7 (set (reg:DI 9 r9 [+8 ])
//(mem/c/i:DI (reg/f:DI 14 r14 [351]) [2 t+8 S8 A64]))
//5 {movdi_internal
--- Comment #4 from steven at gcc dot gnu dot org 2010-07-20 13:40 ---
We might as well close this as WONTFIX, I don't think anyone is interested in
fixing this. We would have to document this problem in the manual, but then at
least we can close the Bugzilla entry. Thoughts
--- Comment #6 from steven at gcc dot gnu dot org 2010-07-20 13:51 ---
So what's the verdict, 4 years later. Is there a bug here, or can this PR be
closed now?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from steven at gcc dot gnu dot org 2010-07-20 13:55 ---
May be a dup of 43494, based on comment #7.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35658
--- Comment #12 from steven at gcc dot gnu dot org 2010-07-20 13:57 ---
Bug 35658 is another case where a store is scheduled after a load that depends
on the store. It may well be that bug 35658 and this bug are the same issue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43494
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|echristo at apple dot com |unassigned at gcc dot gnu
--- Comment #2 from steven at gcc dot gnu dot org 2010-07-20 14:02 ---
No test case. Nothing to do here.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from steven at gcc dot gnu dot org 2010-07-20 14:03 ---
Patches for this were commited in the last decade.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from steven at gcc dot gnu dot org 2010-07-20 14:04 ---
This is still a problem. Iain, one for you?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from steven at gcc dot gnu dot org 2010-07-20 14:06 ---
If it works for Ramana, it works for me.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30254
--- Comment #14 from steven at gcc dot gnu dot org 2010-07-20 17:56 ---
The options -O2 -fno-inline is enough to make the test case of comment #5
fail. This bug is not specific to -fpic / -fPIC, inlining of f1 just hides the
bug for the non-PIC case.
--
steven at gcc dot gnu dot org
--- Comment #15 from steven at gcc dot gnu dot org 2010-07-20 18:08 ---
Works with gcc-4.3 (Debian 4.3.5-1) 4.3.5, both with -fpic and with
-fno-inline.
That makes this bug a regression. CC:RM - who happens to know a thing or two
about the alias analysis code also.
--
steven at gcc
--- Comment #53 from steven at gcc dot gnu dot org 2010-07-20 22:12 ---
Could the OP be so kind to see if this is still a problem?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31849
--- Comment #3 from steven at gcc dot gnu dot org 2010-07-20 22:15 ---
Fixed with patch of comment #2.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from steven at gcc dot gnu dot org 2010-07-20 22:21 ---
Mis-categorized as a treelang bug (?!).
rth, you added these primitive types and the _sync_* builtins... Could you have
a look at this bug and at the patch of comment #1, please?
--
steven at gcc dot gnu dot org
--- Comment #4 from steven at gcc dot gnu dot org 2010-07-20 22:26 ---
sv.po for gcc 4.5.0 has the fixed translation.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from steven at gcc dot gnu dot org 2010-07-20 22:32 ---
I have forwarded this problem to the French team of the Translation Project
(http://translationproject.org/team/fr.html).
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #7 from steven at gcc dot gnu dot org 2010-07-20 22:33 ---
obviously that latest comment was not for this bug (but for bug 32428), sorry.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45006
--- Comment #4 from steven at gcc dot gnu dot org 2010-07-20 22:33 ---
I have forwarded this problem to the French team of the Translation Project
(http://translationproject.org/team/fr.html).
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from steven at gcc dot gnu dot org 2010-07-20 22:37 ---
Why should an .md file call error()? The ones in neon.md look like they should
be internal_error, or something should catch the problem earlier.
Should internal_error messages be translated?
--
steven at gcc dot
--- Comment #2 from steven at gcc dot gnu dot org 2010-07-20 22:40 ---
Closing as invalid because the bug should be reported to the translation team
for Russian (http://translationproject.org/team/ru.html).
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from steven at gcc dot gnu dot org 2010-07-20 22:43 ---
So, another translation bug that fell through the cracks.
Unfortunately the GCC project does not maintain its own translations. This is
taken care of by the Translation Project. The translation team for Russian has
--- Comment #4 from steven at gcc dot gnu dot org 2010-07-20 22:44 ---
See http://translationproject.org/team/fr.html. Not a valid GCC bug report.
Please do report the problem to the translation team for French.
We should have some kind of forwarding system for this...
--
steven
--- Comment #5 from steven at gcc dot gnu dot org 2010-07-20 22:45 ---
Not a GCC bug = closing as INVALID for gcc.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from steven at gcc dot gnu dot org 2010-07-20 22:46 ---
Not a valid bug for GCC. Please report to the translation team for Russian
instead, see http://translationproject.org/team/ru.html.
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #12 from steven at gcc dot gnu dot org 2010-07-20 22:50 ---
Someone should dust off the patch and submit it for trunk. Joern?
--
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
Component|regression |rtl-optimization
--- Comment #3 from steven at gcc dot gnu dot org 2010-07-20 22:53 ---
Martin, PGO and IPA-CP -- isn't that your area of interest? :-)
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from steven at gcc dot gnu dot org 2010-07-20 22:56 ---
Uros, what do you think of this bug, as i386 arch maintainer?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from steven at gcc dot gnu dot org 2010-07-19 09:58 ---
Should be easy, this one. I like easy.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from steven at gcc dot gnu dot org 2010-07-19 19:04 ---
Offending insns that are scheduled in the wrong order:
(insn:TI 28 48 9 2 vector-2.c:7 (set (reg:DI 9 r9 [+8 ])
(mem/c/i:DI (reg/f:DI 14 r14 [351]) [2 t+8 S8 A64])) 5 {movdi_internal}
(expr_list:REG_DEAD
--- Comment #5 from steven at gcc dot gnu dot org 2010-07-18 17:21 ---
It looks like a store is scheduled wrong.
Slightly reduced test case:
-- 8 #define vector
__attribute__((vector_size(16) ))
vector int f1(vector int t, int a)
{
((int*)t)[1
--- Comment #6 from steven at gcc dot gnu dot org 2010-07-18 17:29 ---
Smaller hand-changed assembly without new bundle (left aborts, right does not):
.global f1# .global f1#
.type f1#, @function .type f1#, @function
--- Comment #7 from steven at gcc dot gnu dot org 2010-07-18 17:40 ---
Ah, and since both r14 and r15 are initially copies of r12, they point to the
same memory area (modulo auto-increments/decrements). So indeed an alias thing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43494
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|steven at gcc dot gnu dot |unassigned at gcc dot gnu
|org
1 - 100 of 3017 matches
Mail list logo
