Steve Ellcey wrote:
Steve Ellcey wrote:
I am investigating a bad code generation bug on the 64 bit HPPA platform
with GCC 4.3.0 and would like some help and/or ideas on how to analyze
and fix it. The failing test is the SPEC 2000 GCC benchmark (version
2.7.2.2) and I have been unable to create
With the compiler from the ira branch on x86_64-linux, here are the
timings reported by gfortran -c -time -save-temps with and without
IRA (two timings provided for each set of option, to check
reproducibility)
OK, I come back with fresh numbers from the current IRA branch, rev.
135035,
FX wrote:
PS: I attach the file containing all timings. For each set of option,
I ran the compiler twice; when timings differ significantly, that's
because of other users using the machine (which is a rather underused
dual-core biprocessor, with an average load during my tests of 1.09),
and I
Thanks for testing IRA. As I understand, in
# f951 135.59 6.88
the first number is wall compilation time. Could you tell me what is the
second one? Is it system time?
I suppose so. The two times are the output from gfortran -time -S.
I am trying to analyze the results and it would
If it aborts, as in calling abort, rather than segfaulting, then it's
not a flipped base/index in a memory reference -- those almost always
segfault. This is the case that most worries me about Andrew's patch.
Sorry I wasn't clearer, it is a segfault. Running under gdb:
Program received
Steve Ellcey wrote:
If it aborts, as in calling abort, rather than segfaulting, then it's
not a flipped base/index in a memory reference -- those almost always
segfault. This is the case that most worries me about Andrew's patch.
Sorry I wasn't clearer, it is a segfault. Running under gdb:
Mohamed Shafi [EMAIL PROTECTED] writes:
For the 16-bit target that i porting now to gcc 4.1.2 doesn't have any
branch instructions. It only has jump instructions. For comparison
operation it has this instruction:
if cond Rx Ry
execute this insn
So compare and branch is implemented as
Jeff Law wrote:
And just to be certain, we've used a recent GCC trunk to compile an old
rev of gcc (2.7 era?), which is then segfaulting when it's trying to
compile code, right?
Correct, I am using GCC 4.3.0 to compile the old (2.7) GCC and when I
run that old GCC it segfaults. If I start
If I am reading things right, the use of r8 and r19 in the ldw
instruction are switched around.
Yes. If you do an rtl dump, you should be able to see where the
REG_POINTER flag gets set and if the operand order gets switched.
Sometimes the REG_POINTER flag gets removed by reload, etc. So,
the
Oops, in my cutting and past I omitted the -O2 that goes with all
compilations.
Without it no optimization gets done, so no warnings...
Regards
Edmar
Lijuan Hai wrote:
sorry that I couldn't re-produce the warning as you said.
micro# /import/dr3/s10/gcc-4.2/bin/gcc val-prof-1.c
Steve Ellcey wrote:
The psuedo for %r8 does have REG_POINTER set and the psuedo for %r19
does not. I first see REG_POINTER set for ivtmp___1536 (the psuedo for
%r8) in flow.c.138r.loop2_invariant. This seems interesting because
Peter's patch, that fixes this problem without undoing Andrews
On Thu, May 8, 2008 at 11:48 AM, Jeff Law [EMAIL PROTECTED] wrote:
Hmmm, fails for 4.3... Hmmm, does 4.3 have POINTER_PLUS_EXPR?
(search tree.def for POINTER_PLUS_EXPR).
Yes it made it in 4.3 :). Which is why the other patch went in.
Thanks,
Andrew Pinski
On Thu, 2008-05-08 at 11:38 -0700, Steve Ellcey wrote:
The psuedo for %r8 does have REG_POINTER set and the psuedo for %r19
does not. I first see REG_POINTER set for ivtmp___1536 (the psuedo for
%r8) in flow.c.138r.loop2_invariant. This seems interesting because
Peter's patch, that fixes
Peter Bergner wrote:
On Thu, 2008-05-08 at 11:38 -0700, Steve Ellcey wrote:
The psuedo for %r8 does have REG_POINTER set and the psuedo for %r19
does not. I first see REG_POINTER set for ivtmp___1536 (the psuedo for
%r8) in flow.c.138r.loop2_invariant. This seems interesting because
Peter's
Snapshot gcc-4.3-20080508 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20080508/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
The tuples branch is at the point now that it should bootstrap all
primary languages and targets. There are things that are still broken
and being worked on (http://gcc.gnu.org/wiki/tuples), but by and large
things should Just Work.
I expect things like code generation to be sub-par
Dear mailing list:
I am writing GCC code that constructs GIMPLE (after pass_apply_inline
and before pass_all_optimizations) to take the address of each of a
function's parameters and store those addresses in an array. The code
is at the bottom of this message. Right now I need help in
On Thu, May 8, 2008 at 4:02 PM, Sean Callanan [EMAIL PROTECTED] wrote:
Dear mailing list:
I am writing GCC code that constructs GIMPLE (after pass_apply_inline and
before pass_all_optimizations) to take the address of each of a function's
parameters and store those addresses in an array. The
Diego == Diego Novillo [EMAIL PROTECTED] writes:
are OK. If you are creating a bugzilla report, please add my address
to the CC field.
Me too please.
Aldy
I have questions about function parameter attributes. I'm trying to use
attributes to indicate parameters that are used to pass values back out
of functions and then analyze how they are used. I tried something like
this:
void foo(int *a __attribute__((user(out;
By itself, this works
Hi all,
I was looking for ways to improve the MaverickCrunch division routine on
ARM ep93xx, and noticed that there are few other architectures that
don't have a hardware divide.
IA-64 has a frcpa instruction that returns an estimate of the
reciprocal of a float or double.
Likewise, RS-6000 has
--- Comment #8 from ubizjak at gmail dot com 2008-05-08 06:56 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--
ubizjak at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36174
--- Comment #12 from rguenth at gcc dot gnu dot org 2008-05-08 08:20
---
Subject: Bug 36172
Author: rguenth
Date: Thu May 8 08:19:16 2008
New Revision: 135070
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=135070
Log:
2008-05-08 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-05-08 08:21 ---
Subject: Bug 36154
Author: rguenth
Date: Thu May 8 08:20:45 2008
New Revision: 135071
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=135071
Log:
2008-05-08 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-05-08 08:24 ---
Subject: Bug 36154
Author: rguenth
Date: Thu May 8 08:23:59 2008
New Revision: 135072
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=135072
Log:
2008-05-08 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #13 from rguenth at gcc dot gnu dot org 2008-05-08 08:24
---
Subject: Bug 36172
Author: rguenth
Date: Thu May 8 08:23:59 2008
New Revision: 135072
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=135072
Log:
2008-05-08 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-05-08 08:29 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #14 from rguenth at gcc dot gnu dot org 2008-05-08 08:30
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Building gcc on powerpc-apple-darwin9, I got the following error:
...
/opt/gcc/darwin_buildw/./prev-gcc/xgcc -B/opt/gcc/darwin_buildw/./prev-gcc/
-B/opt/gcc/gcc4.4w/powerpc-apple-darwin9/bin/ -c -g -O2 -mdynam
ic-no-pic -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes
--- Comment #9 from manu at gcc dot gnu dot org 2008-05-08 10:44 ---
(In reply to comment #8)
Sorry, you got it totally wrong! When someone suggests a feature that he
thinks
would be useful, he does definitely not imply that the current developers are
bored and have nothing to
--- Comment #1 from ktietz at gcc dot gnu dot org 2008-05-08 11:37 ---
Created an attachment (id=15618)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15618action=view)
Committed patch at revision 135079.
--
ktietz at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from ktietz at gcc dot gnu dot org 2008-05-08 11:38 ---
Committed at revision135079 to gcc trunk.
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from matz at gcc dot gnu dot org 2008-05-08 15:13 ---
Hmm, actually I sort of agree with HJ. It's a global (and unhidden)
definition, which very well can be replaced by a different definition at
runtime. In particular that will happen for instance if the global data
is
--- Comment #5 from spop at gcc dot gnu dot org 2008-05-08 15:54 ---
Subject: Re: verify_ssa ICE with -ftree-loop-linear
The patch is already in trunk:
2008-02-29 Sebastian Pop [EMAIL PROTECTED]
* tree-loop-linear.c (try_interchange_loops): Compare memory access
--- Comment #28 from dje at gcc dot gnu dot org 2008-05-08 16:36 ---
Subject: Bug 36090
Author: dje
Date: Thu May 8 16:35:56 2008
New Revision: 135086
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=135086
Log:
2008-05-08 Paolo Bonzini [EMAIL PROTECTED]
PR target/36090
--- Comment #3 from tromey at gcc dot gnu dot org 2008-05-08 16:40 ---
I finally submitted this patch.
http://gcc.gnu.org/ml/gcc-patches/2008-05/msg00520.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22231
--- Comment #29 from dje at gcc dot gnu dot org 2008-05-08 16:41 ---
Subject: Bug 36090
Author: dje
Date: Thu May 8 16:40:17 2008
New Revision: 135087
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=135087
Log:
2008-05-08 Paolo Bonzini [EMAIL PROTECTED]
PR target/36090
--- Comment #1 from zadeck at naturalbridge dot com 2008-05-08 16:46
---
Subject: Re: [4.4 Regression] g++.dg/tree-ssa/pr19637.C
ICEs with 135041 - 135057
Here is the bug. I do not know if this is just an illegal insn
generated by a bad port or if we are missing something in the
This simple test case fails:
--
#include stdio.h
int main(int argc, const char* argv[])
{
int data[1024];
int sum = 0;
int i = 0;
for(; i1024; i++)
sum += data[i];
printf(%d, sum);
return 0;
}
--- Comment #3 from jkrahn at nc dot rr dot com 2008-05-08 18:19 ---
Fortran files should not be put into /usr/local/include or /usr/include. Those
directories are defined for C headers. It is particularly bad to put binary
files there. We should instead develop a standard location for
--- Comment #13 from hjl at gcc dot gnu dot org 2008-05-08 19:12 ---
Subject: Bug 35657
Author: hjl
Date: Thu May 8 19:11:23 2008
New Revision: 135089
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=135089
Log:
2008-05-08 H.J. Lu [EMAIL PROTECTED]
Backport from
--- Comment #14 from hjl dot tools at gmail dot com 2008-05-08 19:12
---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #2 from hp at gcc dot gnu dot org 2008-05-08 22:07 ---
(In reply to comment #1)
In particular, i assume that the dce code is getting confused because it
does not see the call inside the parallel.
i do not know if this is a bug in the cris port or if there are other
--- Comment #3 from steven at gcc dot gnu dot org 2008-05-08 22:16 ---
I would have thought that since this can generate an exception and it is
a call insn that it would have been declared as a non deleteable insn by
dce.c:deleteable_insn_p.
deletable_insn_p() *will* declare this
--- Comment #4 from steven at gcc dot gnu dot org 2008-05-08 22:27 ---
So I was looking at an older revision of dce.c. There is this new check before
the !NONJUMP_INSN_P check now:
/* We can delete dead const or pure calls as long as they do not
infinite loop and are not
With 135074 no regressions.
With 135087, I see the following regressions:
FAIL: ext/malloc_allocator/deallocate_local.cc (test for excess errors)
WARNING: ext/malloc_allocator/deallocate_local.cc compilation failed to produce
executable
FAIL: ext/mt_allocator/deallocate_local-2.cc (test for excess
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-08 22:47 ---
I have a similar issue on spu-elf where we get [EMAIL PROTECTED] which is too
complex for
the linker to handle.
/tmp/ccbhdI9l.s:19: Error: reloc 132 not supported by object file format^M
/tmp/ccbhdI9l.s:22: Error:
--- Comment #5 from zadeck at naturalbridge dot com 2008-05-08 23:04
---
Subject: Re: [4.4 Regression] g++.dg/opt/pr23714.C
ICEs with 135041 - 135057
steven at gcc dot gnu dot org wrote:
--- Comment #4 from steven at gcc dot gnu dot org 2008-05-08 22:27
---
So I was
class B
{
public:
B() {}
explicit B(const B ref) {}
};
void f(B obj) {}
int main()
{
const B b;
const B r(b);
f(b); // error: no matching function for call to 'B::B(const B)'
// error: initializing argument 1 of 'void f(B)'
f(r); // error: no matching function for
Per mailing list instructions and using a branch checkout from today,
../gimple-tuples-branch/configure --disable-libgomp --disable-libmudflap
make
on Darwin fails with an illegal instruction:
/Users/shebs/s/gcc/tuples/macosx/./prev-gcc/xgcc
-B/Users/shebs/s/gcc/tuples/macosx/./prev-gcc/
--- Comment #4 from froydnj at gcc dot gnu dot org 2008-05-09 03:14 ---
If I understand correctly, one would just need to add vector modes with
appropriate alignment restrictions to SLOW_UNALIGNED_ACCESS. If I add an extra
|| (((MODE) == V4SFmode || (MODE) == V2DFmode) (ALIGN) 128)
--- Comment #6 from hp at bitrange dot com 2008-05-09 03:49 ---
Subject: Re: [4.4 Regression] g++.dg/opt/pr23714.C
ICEs with 135041 - 135057
On Thu, 8 May 2008, zadeck at naturalbridge dot com wrote:
I am testing this patch on x86. But hp needs to test it on the cris
before i will
--- Comment #2 from bonzini at gnu dot org 2008-05-09 05:04 ---
unfortunately my current gcc time is ~0, which is why dje actually tested and
committed the patch for me, but sorry for causing these regressions anyway.
for cris, i believe the correct fix is to strengthen the check and
--- Comment #3 from bonzini at gnu dot org 2008-05-09 05:05 ---
i'll post a temptative patch for the cris issue if i get to it during the
commute.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36182
--- Comment #4 from bonzini at gnu dot org 2008-05-09 05:05 ---
ahem, tentative
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36182
--- Comment #30 from cnstar9988 at gmail dot com 2008-05-09 05:36 ---
fixed?
--
cnstar9988 at gmail dot com changed:
What|Removed |Added
CC|
57 matches
Mail list logo
