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.
1350
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 th
> 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
> 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 impleme
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 star
> 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,
th
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 -fprofile-arcs
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 pat
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 pa
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 because
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 dea
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
> "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
21 matches
Mail list logo
