--- Comment #2 from ramana at gcc dot gnu dot org 2010-01-29 08:02 ---
Created an attachment (id=19748)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19748action=view)
Testcase
This is a Thumb1 ICE. For completeness , the architecture flags to be used are
-march=armv5te -mthumb.
--- Comment #3 from ramana at gcc dot gnu dot org 2010-01-29 08:04 ---
Confirmed.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from ramana at gcc dot gnu dot org 2010-01-29 08:30 ---
Marking as P2 .
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #12 from doko at ubuntu dot com 2010-01-29 08:37 ---
checked the patch on the 4.4 branch; the error message for the test case in the
original report is gone, but there are some warnings about the mangling in the
libstdc++ files as well. not reopening yet, as I didn't check a
--- Comment #3 from steven at gcc dot gnu dot org 2010-01-29 08:42 ---
See arm.c:#define REG_ALLOC_ORDER. Comment before it says: It is good to use
ip since no saving is required (though calls clobber it) and it never contains
function parameters. It is quite good to use lr since other
--- Comment #25 from chrbr at gcc dot gnu dot org 2010-01-29 08:59 ---
by the way, FYI, trying to explain the differences between your results and
mine for sh4-linux. my build was is configured with --enable-target-optspace,
so all my runtime build tests are ran with -Os, not -O2 like
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-01-29 09:14 ---
Only RMs may set priority.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from paolo dot carlini at oracle dot com 2010-01-29 10:08
---
Thanks Jakub, let's see what submitter has to say.
Just want to add here that I'm building submitter' app **exactly** in the same
way with g++ / icc, on the very same machine indeed, and in the former case
--- Comment #20 from rearnsha at gcc dot gnu dot org 2010-01-29 10:18
---
(In reply to comment #18)
Function that seems to cost the most time is add_functions(), which is one big
basic block of ~7500 insns (~500 of them call insns).
List scheduling is quadratic in the number of
--- Comment #3 from jakub at gcc dot gnu dot org 2010-01-29 10:28 ---
Seems s is alternating between VALUE 1 and VALUE 11:
dataflow difference found: old and new follow:
name: s
offset 0
(value/s/u:DI 1 @0x2ff4100/0x3009f40)
name: s
offset 0
(value/s/u:DI 11
--- Comment #9 from law at redhat dot com 2010-01-29 11:01 ---
At some point IRA's handling of earlyclobber constraints improved enough to get
the conflicts right in this PR. Unfortunately, that is not sufficient to
generate good code.
If we compile the testcase on i686-pc-linux-gnu
--- Comment #39 from rguenth at gcc dot gnu dot org 2010-01-29 11:26
---
Subject: Bug 37448
Author: rguenth
Date: Fri Jan 29 11:26:27 2010
New Revision: 156343
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156343
Log:
2010-01-29 Richard Guenther rguent...@suse.de
PR
--- Comment #4 from jakub at gcc dot gnu dot org 2010-01-29 11:27 ---
When doing dataflow_set_merge where s variable is in VALUE 1 in one hash table
and in VALUE 11 in the other hash table, apparently always the one that is
first wins, as VALUE 11 has var-var_part[0].loc_chain-loc VALUE
--- Comment #20 from jakub at gcc dot gnu dot org 2010-01-29 12:15 ---
Subject: Bug 42889
Author: jakub
Date: Fri Jan 29 12:14:47 2010
New Revision: 156344
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156344
Log:
PR rtl-optimization/42889
* df.h
--- Comment #13 from manu at gcc dot gnu dot org 2010-01-29 13:09 ---
Why is this a note and not simply a warning? Anyway, in_system_header should
slowly go away, either use diagnostic_report_warnings_p (input_location) or
in_system_header_at (input_location). None of them is necessary
Configuring with --enable-languages=c --disable-multilib --without-build-config
bootstrap fails with
Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1obj-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
Bootstrap comparison failure!
gcc/dse.o differs
make[2]:
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42896
I just tried to compile the package htmldoc-1.8.27-174.19 with the GNU
C++ compiler version 4.5 snapshot 20100128 and the compiler said
image.cxx:389:1: error: definition in block 7 does not dominate use in block 13
for SSA_NAME: i_36 in statement:
# DEBUG i = i_36
image.cxx:389:1: internal
--- Comment #1 from dcb314 at hotmail dot com 2010-01-29 13:37 ---
Created an attachment (id=19749)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19749action=view)
C++ source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42897
--- Comment #14 from paolo dot carlini at oracle dot com 2010-01-29 13:40
---
I can see that exception_ptr.h doesn't have the system header pragma, I think
on purpose, some time ago we briefly discussed that and decided to not add it
to the libsupc++ user-visible headers, if possible.
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-29 13:51 ---
r156291 is fine, r156292 is broken.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42896
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-01-29 13:57 ---
var-tracking dump difference:
--- dse.c.208r.vartrack.equal 2010-01-29 14:55:01.0 +0100
+++ dse.c.208r.vartrack.differs 2010-01-29 14:54:34.0 +0100
@@ -1889899,8 +1889899,8 @@
(value/s/u:DI 44
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-01-29 14:00 ---
Created an attachment (id=19750)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19750action=view)
testcase
inside stage3/gcc:
obj/gcc /abuild/rguenther/obj/./prev-gcc/cc1 -fpreprocessed dse.i -quiet
-dumpbase
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-01-29 14:04 ---
Needs randomized va-space to trigger. My guess:
/* Determine a total order between two distinct pointers. Compare the
pointers as integral types if size_t is wide enough, otherwise
resort to bitwise memory
--- Comment #4 from dodji at gcc dot gnu dot org 2010-01-29 14:31 ---
Subject: Bug 42797
Author: dodji
Date: Fri Jan 29 14:30:41 2010
New Revision: 156351
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156351
Log:
Fix PRs c++/42758, c++/42634, c++/42797
... and mitigate PR
--- Comment #47 from dodji at gcc dot gnu dot org 2010-01-29 14:31 ---
Subject: Bug 42880
Author: dodji
Date: Fri Jan 29 14:30:41 2010
New Revision: 156351
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156351
Log:
Fix PRs c++/42758, c++/42634, c++/42797
... and mitigate PR
--- Comment #15 from dodji at gcc dot gnu dot org 2010-01-29 14:31 ---
Subject: Bug 42634
Author: dodji
Date: Fri Jan 29 14:30:41 2010
New Revision: 156351
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156351
Log:
Fix PRs c++/42758, c++/42634, c++/42797
... and mitigate PR
--- Comment #23 from dodji at gcc dot gnu dot org 2010-01-29 14:31 ---
Subject: Bug 42336
Author: dodji
Date: Fri Jan 29 14:30:41 2010
New Revision: 156351
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156351
Log:
Fix PRs c++/42758, c++/42634, c++/42797
... and mitigate PR
--- Comment #7 from dodji at gcc dot gnu dot org 2010-01-29 14:31 ---
Subject: Bug 42758
Author: dodji
Date: Fri Jan 29 14:30:41 2010
New Revision: 156351
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156351
Log:
Fix PRs c++/42758, c++/42634, c++/42797
... and mitigate PR
--- Comment #4 from hubicka at gcc dot gnu dot org 2010-01-29 14:33 ---
Yes, the clone_of and similar datastructures are cleared because function is no
longer a virtual clone. Probably best way to get to original function is via
DECL_ABSTRACT_ORIGIN same way as debug info does. Is
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #5 from jakub at gcc dot gnu dot org 2010-01-29 15:00 ---
Created an attachment (id=19751)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19751action=view)
gcc45-pr42896.patch
Try this. If we ever hit the assertion, some more patching will be needed to
break the ties.
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-01-29 15:04 ---
After fixing the typo it ICEs with the testcase:
../../trunk/gcc/dse.c: In function 'check_mem_read_rtx':
../../trunk/gcc/dse.c:2300:1: internal compiler error: in tie_break_values, at
var-tracking.c:1179
Please
--- Comment #15 from mark at codesourcery dot com 2010-01-29 15:12 ---
Subject: Re: warnings about 'mangling of 'va_list' has changed
in GCC 4.4' not suppressed in sytem headers
manu at gcc dot gnu dot org wrote:
Why is this a note and not simply a warning?
Because, as noted
--- Comment #7 from jakub at gcc dot gnu dot org 2010-01-29 15:21 ---
:(, there apparently are VALUEs without locs so we can't always compare this
way.
Both the problematic VALUEs are created through
e = new_cselib_val (hashval, mode, x);
(the only place which doesn't assign VALUE
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org
|dot org
--- Comment #24 from dodji at seketeli dot org 2010-01-29 15:48 ---
Subject: Re: [4.5 Regression] ICE with
pointer-to-member-function argument in template function with -fipa-sra
So this commit r156351 won't fix the root cause this issue, but I
believe it prevents the compiler from
--- Comment #16 from dodji at gcc dot gnu dot org 2010-01-29 16:07 ---
Hopefully fixed in 4.5 (trunk) now.
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from dodji at gcc dot gnu dot org 2010-01-29 16:08 ---
Fixed in 4.5 (trunk)
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org
|dot org
--- Comment #5 from dodji at gcc dot gnu dot org 2010-01-29 16:09 ---
Fixed in 4.5 (trunk).
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from hjl dot tools at gmail dot com 2010-01-29 16:22 ---
It is caused by revision 154402:
http://gcc.gnu.org/ml/gcc-cvs/2009-11/msg00623.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42897
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-01-29 16:26 ---
Created an attachment (id=19752)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19752action=view)
reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42896
--- Comment #12 from eric dot weddington at atmel dot com 2010-01-29 16:33
---
Setting target milestone.
--
eric dot weddington at atmel dot com changed:
What|Removed |Added
--- Comment #4 from eric dot weddington at atmel dot com 2010-01-29 16:43
---
Changed Target Milestone.
--
eric dot weddington at atmel dot com changed:
What|Removed |Added
--- Comment #9 from jakub at gcc dot gnu dot org 2010-01-29 16:43 ---
In theory we could reuse the next_containing_mem field for a counter, as it
isn't used for anything once cselib_preserve_only_values is called (and I
believe canon_value_cmp is only ever used after vt_initialize phase
--- Comment #4 from eric dot weddington at atmel dot com 2010-01-29 16:46
---
Setting Target Milestone.
--
eric dot weddington at atmel dot com changed:
What|Removed |Added
--- Comment #9 from eric dot weddington at atmel dot com 2010-01-29 17:01
---
Closing as WONTFIX.
--
eric dot weddington at atmel dot com changed:
What|Removed |Added
--- Comment #16 from mjtruog at fastmail dot ca 2010-01-29 17:04 ---
I am using -fpic/-fPIC and in fact am using:
// g++ -g -O0 main.cpp -ldl
// g++ -g -O0 -rdynamic -c -fPIC -o library.o library1.cpp
// g++ -shared -Wl,-export-dynamic -o library.so library.o
I do want to use
--- Comment #11 from eric dot weddington at atmel dot com 2010-01-29 17:07
---
Setting Target Milestone.
--
eric dot weddington at atmel dot com changed:
What|Removed |Added
--- Comment #7 from eric dot weddington at atmel dot com 2010-01-29 17:08
---
Setting Target Milestone.
--
eric dot weddington at atmel dot com changed:
What|Removed |Added
--- Comment #13 from jason at gcc dot gnu dot org 2010-01-29 17:10 ---
Created an attachment (id=19753)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19753action=view)
work snapshot
Here's a final snapshot of the work I did on this if anyone ever feels like
picking it up again.
--- Comment #14 from jason at gcc dot gnu dot org 2010-01-29 17:11 ---
And closing.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from eric dot weddington at atmel dot com 2010-01-29 17:12
---
Setting Target Milestone.
--
eric dot weddington at atmel dot com changed:
What|Removed |Added
--- Comment #10 from rguenther at suse dot de 2010-01-29 17:17 ---
Subject: Re: [4.5 Regression] Random debug generation
differences, bootstrap fails
On Fri, 29 Jan 2010, jakub at gcc dot gnu dot org wrote:
--- Comment #9 from jakub at gcc dot gnu dot org 2010-01-29 16:43
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #21 from jakub at gcc dot gnu dot org 2010-01-29 17:26 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #8 from ro at gcc dot gnu dot org 2010-01-29 17:34 ---
Mine.
--
ro at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc
--- Comment #9 from ro at gcc dot gnu dot org 2010-01-29 17:37 ---
Patch here:
http://gcc.gnu.org/ml/gcc-patches/2010-01/msg01508.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29986
--- Comment #20 from eric dot weddington at atmel dot com 2010-01-29 17:45
---
I have in my list that this bug as fixed in 4.4.0. Closing.
--
eric dot weddington at atmel dot com changed:
What|Removed |Added
--- Comment #3 from burnus at gcc dot gnu dot org 2010-01-29 17:45 ---
I have now asked at comp.lang.fortran:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/c00efc5679b6a879
(In reply to comment #2)
The way usually recommended is to use a struct for
--- Comment #10 from eric dot weddington at atmel dot com 2010-01-29 17:47
---
I have in my list this bug as fixed in 4.4.0. Closing.
--
eric dot weddington at atmel dot com changed:
What|Removed |Added
--- Comment #4 from eric dot weddington at atmel dot com 2010-01-29 17:50
---
Closing as WONTFIX.
--
eric dot weddington at atmel dot com changed:
What|Removed |Added
--- Comment #2 from meissner at gcc dot gnu dot org 2010-01-29 17:53
---
Subject: Bug 41701
Author: meissner
Date: Fri Jan 29 17:53:46 2010
New Revision: 156359
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156359
Log:
PR 41701, prevent pow in compiler pathname from a false
--- Comment #3 from meissner at gcc dot gnu dot org 2010-01-29 17:54
---
Subject: Bug 41701
Author: meissner
Date: Fri Jan 29 17:54:14 2010
New Revision: 156360
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156360
Log:
PR 41701, prevent pow in compiler pathname from a false
--- Comment #7 from mrestelli at gmail dot com 2010-01-29 18:24 ---
(In reply to comment #5)
Further reduced test case:
type t
integer, allocatable :: d(:)
end type
type(t), allocatable :: a(:)
allocate(a(2))
call sub( (/ a /) )
contains
subroutine
--- Comment #14 from janus at gcc dot gnu dot org 2010-01-29 19:01 ---
Ok, I think the best solution is to move the code setting up the initializer
back to resolve.c. Here is a patch which does so (without any testsuite
regressions):
Index: gcc/fortran/trans-stmt.c
--- Comment #15 from janus at gcc dot gnu dot org 2010-01-29 19:18 ---
(In reply to comment #14)
Note: There is another call to 'gfc_default_initializer' in
'gfc_trans_allocate', which should be moved to resolve.c too, I guess.
Here is a small test case (very similar to comment #0,
I've recently upgraded to GCC 4.3.2 from 4.2.2, and I noticed a strange
change in how volatile bitmask structures are optimized.
Consider the following code (compiled using just the -O3 option):
/* 32-bit MMIO */
struct hardware {
int parm1:8;
int :4;
int parm2:4;
int parm3:15;
int
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-01-29 19:38 ---
Confirmed, I think this was caused/exposed by:
2007-11-20 Jakub Jelinek ja...@redhat.com
PR c/34146
* c-gimplify.c (optimize_compound_literals_in_ctor): New function.
(c_gimplify_expr):
--- Comment #4 from carrot at google dot com 2010-01-29 19:42 ---
(In reply to comment #3)
See arm.c:#define REG_ALLOC_ORDER. Comment before it says: It is good to use
ip since no saving is required (though calls clobber it) and it never contains
function parameters. It is quite
--- Comment #5 from steven at gcc dot gnu dot org 2010-01-29 19:49 ---
This isn't confusing at all. ORDER_REGS_FOR_LOCAL_ALLOC is unused. All targets
that define it should be fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42895
John Regehr points out this size-regression WRT 3.4:
Sometimes a function modifies globals but even so has no net effect:
http://embed.cs.utah.edu/embarrassing/jan_10/harvest/source/8A/8AB0B238.shtml
http://embed.cs.utah.edu/embarrassing/jan_10/harvest/source/14/14157FE8.shtml
Somehow gcc3 sees
--- Comment #3 from steven at gcc dot gnu dot org 2010-01-29 19:58 ---
*** Bug 42899 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-01-29 19:58 ---
*** This bug has been marked as a duplicate of 42893 ***
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-01-29 20:03 ---
Note, I think this works on targets where movs cannot have a mem with a
constant like most RISC targets.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42893
--- Comment #5 from pinskia at gcc dot gnu dot org 2010-01-29 20:07 ---
Yep:
tui_registers_changed_hook:
blr
Which means this is the same as PR 23488 which was caused by:
2005-07-30 Jan Hubicka j...@suse.cz
* expr.c (expand_expr_real_1): Do not load mem targets into
I've noticed that all the gfortran.dg/stat_[12].f90 fail for me on all
platforms
(i.e. sparc-sun-solaris2, alpha-dec-osf, mips-sgi-irix).
FAIL: gfortran.dg/stat_1.f90 -O0 execution test
at all optimization levels. Running it under gdb reveals that it aborts here:
#4 0x000110f0 in MAIN__ ()
--- Comment #6 from steven at gcc dot gnu dot org 2010-01-29 20:17 ---
I think the issue here is more that we should look for a way to optimize this
early on. I'm guessing it's one of the ce[123] passes that cleans this up for
you on your RISCy machine? IMHO it would be better even in
--- Comment #7 from pinskia at gcc dot gnu dot org 2010-01-29 20:19 ---
(In reply to comment #6)
I think the issue here is more that we should look for a way to optimize this
early on. I'm guessing it's one of the ce[123] passes that cleans this up for
you on your RISCy machine? IMHO
--- Comment #20 from amylaar at gcc dot gnu dot org 2010-01-29 20:33
---
Subject: Bug 38785
Author: amylaar
Date: Fri Jan 29 20:33:19 2010
New Revision: 156365
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156365
Log:
PR tree-optimization/38785
2009-02-02 Jorn Rennecke
--- Comment #10 from vmakarov at redhat dot com 2010-01-29 20:33 ---
Jeff, I saw analogous problem when I worked on improving IRA performance. I
checked the approach you are proposing. But it works considerably worse on
SPEC2000. Finally, I found that the best conflicting cost
--- Comment #40 from hubicka at ucw dot cz 2010-01-29 20:54 ---
Subject: Re: [4.3/4.4/4.5 Regression] gcc 4.3.1 cannot compile big function
But it miscompares. Honza?!
Patch seems sane to me, so I guess it was other bootstrap issue.
I was actually working on similar fix yesterday
Reading a namelist that contains a variable that is an array of structures
fails. Whatever the index of the array element, the values that are read are
assigned to the first array element.
Below a more or less minimal example:
PROGRAM test_nml
! Start declarations
! Struct with one
--- Comment #21 from vmakarov at redhat dot com 2010-01-29 21:54 ---
Thanks everyone who works on the bug.
I am sorry that the bug was really introduced by my patch more accurately by
the part which should fix reload crashes when the 1st scheduling works for some
targets. The patch
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2010-01-29 22:27
---
I will have a look at this one.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
gcc.dg/pr34668-1.c FAILs on x86_64-unknown-linux-gnu
(e.g. gcc{11,13,16}.fsffrance.org).
--
Summary: gcc.dg/pr34668-1.c FAILs on x86_64-unknown-linux-gnu
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-01-29 22:32 ---
*** This bug has been marked as a duplicate of 39959 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #19 from pinskia at gcc dot gnu dot org 2010-01-29 22:32
---
*** Bug 42902 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-29 22:35 ---
I'd say add a comment to the testcase and WONTFIX.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42900
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-01-29 22:37 ---
(In reply to comment #6)
I think the issue here is more that we should look for a way to optimize this
early on. I'm guessing it's one of the ce[123] passes that cleans this up for
you on your RISCy machine? IMHO
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-01-29 22:41 ---
Yep:
f2 ()
{
volatile struct hardware * ptr;
struct hardware set;
ptr = 287454020B;
set = {};
set.parm1 = 42;
set.parm2 = -3;
set.parm3 = 11850;
set.parm4 = -1;
*ptr = set;
}
f1 ()
{
volatile
--- Comment #16 from janus at gcc dot gnu dot org 2010-01-29 22:41 ---
Created an attachment (id=19754)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19754action=view)
patch
Here is an updated patch which fixes the test case in the last comment and the
original problem.
--
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.4 |4.3.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42898
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-01-29 22:42 ---
I will have a look.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #22 from steven at gcc dot gnu dot org 2010-01-29 22:46 ---
FWIW: with the patch of comment #21 compile time goes down by a factor 10 and
memory tops out at 107MB with the same x86_64 X armv5tejl-unknown-linux-gnueabi
compiler as yesterday (but this time patched).
--
--- Comment #6 from carrot at google dot com 2010-01-29 22:47 ---
I tried to change the register order in REG_ALLOC_ORDER, moved ip and lr after
r4/r5/r6/r7, but I still got the same result.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42895
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||wrong-code
Known to fail||4.4.2
for prologue
pop {r4, pc}
.size test, .-test
.ident GCC: (GNU) 4.5.0 20100129 (experimental) [trunk revision
156352]
I have a really bad hack that makes loop-invariant look at addresses inside
MEMs (attached).
(Looking at Zdenek:) Would something like this in a more
--- Comment #2 from ramana at gcc dot gnu dot org 2010-01-29 23:32 ---
(In reply to comment #1)
Could be done in a peephole if there's a scratch available for the
destination.
We already do this for Thumb1 don't we ? Turning on *tlobits_cbranch and the
appropriate bit in arm.c
1 - 100 of 122 matches
Mail list logo
