"H.J. Lu" <[EMAIL PROTECTED]> wrote on 27.04.2008 21:31:14:
> Is this related to
>
> http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01951.html
>
>
> H.J.
> On Sun, Apr 27, 2008 at 11:47 AM, FX <[EMAIL PROTECTED]> wrote:
> >
> > > Cygwin native built gfortran 4.4 was already broken, even when it
On 2008/4/28 Ben Elliston <[EMAIL PROTECTED]> wrote:
> On Sun, 2008-04-27 at 21:45 +0200, J.C. Pizarro wrote:
>
> > Don't be stupid!
>
> Could you be a bit more civil, please? It's fairly unusual for people
> on this list to talk to each other in this way.
>
> Thanks,
> Ben
Excuse me, i'm no
Hi,
I've been rebootstrapping my switch conversion patch (which is still
waiting for review) to make sure it still works. Unfortunately, it
did not. The error given was the following and I believe this is the
warning introduced by Ian as a response to the infamous CERT advisory.
(Furthermo
Hello,
I am looking at a testsuite failure (wo_prof_global_var.c) in my
porting. Somehow, I found GCC 4.3.0 seems to generate unnecessary malloc
during structure optimization. In the code, the structure is split into
two individual fields (D.2240 and D.2242) and they are allocated
separately. But
I am trying to look at assembler code, and representing it as C code.
For ia32, x86 platforms,
assembler like the following
ADD eax,ebx;
JO integer_overflow_detected;
How would I represent this in C?
Kind Regards
James
[EMAIL PROTECTED] wrote on 28.04.2008 13:11:39:
> I am trying to look at assembler code, and representing it as C code.
>
> For ia32, x86 platforms,
> assembler like the following
>
> ADD eax,ebx;
> JO integer_overflow_detected;
>
> How would I represent this in C?
>
> Kind Regards
>
> James
Dear Reader,
A few years ago I had already posted a question about implementing a
metrication tool in GCC, i.e. a tool that can measure several metrics
from the source code. Examples could be, the number of variables,
number of multiplications, number of loops, number of functions, etc.
At that ti
On Mon, Apr 28, 2008 at 09:07:51AM +0200, J.C. Pizarro wrote:
> Excuse me, i'm not the unique and first person that says you stupid,
> GCC did it too.
GCC is not posting on the mailing list. Please be polite to other
contributors; that includes not insulting their intelligence.
--
Daniel Jacobo
2008/4/28 Kai Tietz <[EMAIL PROTECTED]>:
> [EMAIL PROTECTED] wrote on 28.04.2008 13:11:39:
>
>
>
> > I am trying to look at assembler code, and representing it as C code.
> >
> > For ia32, x86 platforms,
> > assembler like the following
> >
> > ADD eax,ebx;
> > JO integer_overflow_detected;
"James Courtier-Dutton" <[EMAIL PROTECTED]> wrote on 28.04.2008
15:28:56:
> 2008/4/28 Kai Tietz <[EMAIL PROTECTED]>:
> > [EMAIL PROTECTED] wrote on 28.04.2008 13:11:39:
> >
> >
> >
> > > I am trying to look at assembler code, and representing it as C
code.
> > >
> > > For ia32, x86 platforms,
Mark Mitchell wrote:
Janis Johnson wrote:
This will involve editing every test that using dg-options
to add a -mcpu/-march flag. Would it make sense to let
dg-options check for the conflict as it adds an option?
Yes, it would meaning adding the new option to hundreds of tests,
but t
On 4/28/08 7:46 AM, Roel Meeuws wrote:
So here is what I would like to know: what kind of metrics could I
measure at e.g. GIMPLE level, and what steps do I need to take to
implement a pass for GIMPLE to measure the needed values?
You can measure anything that is language-independent (though yo
J.C. Pizarro wrote on :
> On 2008/4/28 Ben Elliston wrote:
>> On Sun, 2008-04-27 at 21:45 +0200, J.C. Pizarro wrote:
>>
>> > Don't be stupid!
>>
>> Could you be a bit more civil, please? It's fairly unusual for people
>> on this list to talk to each other in this way.
>>
>> Thanks,
>> Ben
On 2008/4/28 Dave Korn <[EMAIL PROTECTED]> wrote:
> J.C. Pizarro wrote on :
>
>
> > On 2008/4/28 Ben Elliston wrote:
> >> On Sun, 2008-04-27 at 21:45 +0200, J.C. Pizarro wrote:
> >>
> >> > Don't be stupid!
> >>
> >> Could you be a bit more civil, please? It's fairly unusual for people
> >
Joel Sherrill wrote:
1. Make these tests say something about what capability they require,
with a dg-require directive, and then write autoconf-style tests run by
the testsuite to determine whether the current compiler has that
capability. For example, add a "dg-require-hard-float" directive, a
I've just tested gcc/gfortran with CP2K, which some of you might know from
PR29975 and other messages to the list, and observed some very pleasing
evolution in the runtime of the code. In each case the set of compilation
options is '-O2 -ffast-math -funroll-loops -ftree-vectorize -march=native
On 2008/4/27 J.C. Pizarro <[EMAIL PROTECTED]> wrote:
> On Fri 25 Apr 2008 22:22:55 -0500, Peter Bergner <[EMAIL PROTECTED]> wrote:
> > The difference between a compressed upper triangular bit matrix from a
> standard
> > upper triangular bit matrix like the one above, is we eliminate space from
On Mon, 2008-04-28 at 07:47 -0700, Mark Mitchell wrote:
> Joel Sherrill wrote:
>
> >> 1. Make these tests say something about what capability they require,
> >> with a dg-require directive, and then write autoconf-style tests run by
> >> the testsuite to determine whether the current compiler has
[ Apologies if this comes out twice. I posted this message last week,
but I think it was rejected because of a .pdf attachment. ]
We have been bouncing ideas for a new mechanism to describe the behavior
of function calls so that optimizers can be more aggressive at call
sites. Currently, GCC
On Mon, Apr 28, 2008 at 3:04 PM, Diego Novillo <[EMAIL PROTECTED]> wrote:
> [ Apologies if this comes out twice. I posted this message last week,
>but I think it was rejected because of a .pdf attachment. ]
>
> We have been bouncing ideas for a new mechanism to describe the behavior
> of fun
Hi,
I noticed that x86 builtin load functions aren't defined
with def_builtin_const. Is this an oversight or intentional?
Thanks.
H.J.
On Mon, Apr 28, 2008 at 12:47 PM, H.J. Lu <[EMAIL PROTECTED]> wrote:
> I noticed that x86 builtin load functions aren't defined
> with def_builtin_const. Is this an oversight or intentional?
I don't see why they can't be defined as const, the only time I can
think of is when you have -fnon-call-
Diego Novillo wrote:
[ Apologies if this comes out twice. I posted this message last week,
but I think it was rejected because of a .pdf attachment. ]
We have been bouncing ideas for a new mechanism to describe the behavior
of function calls so that optimizers can be more aggressive at call
Peter Bergner wrote:
On Thu, 2008-04-24 at 20:23 -0400, Vladimir Makarov wrote:
Hi, Peter. The last time I looked at the conflict builder
(ra-conflict.c), I did not see the compressed matrix. Is it in the
trunk? What should I look at?
Yes, the compressed bit matrix was committed as
I am combining most x86 SIMD builtins into bdesc_sse_args.
I only define store builtins with def_builtin. The rest will be
defined with def_builtin_const., including load builtins. I want
to make sure that it is OK to do so.
Thanks.
H.J.
On Mon, Apr 28, 2008 at 12:50 PM, Andrew Pinski <[EMAIL PRO
On Mon, 2008-04-28 at 16:01 -0400, Vladimir Makarov wrote:
> Thanks, Peter. That was clever and email is very enlightening. I have
> analogous idea for more compact conflict matrix representation. IRA
> builds allocno live ranges first (they are ranges of program points
> where the allocno li
On Apr 28, 2008, at 12:04 PM, Diego Novillo wrote:
[ Apologies if this comes out twice. I posted this message last week,
but I think it was rejected because of a .pdf attachment. ]
We have been bouncing ideas for a new mechanism to describe the
behavior
of function calls so that optimize
Hi guys,
I am trying to get as close mapping from liveness information ( in
bb->il.rtl->global_live_at_start )
to global and local variables as possible. Mapping to stack slots
would be a good first step.
What data structures should I look at use?
What would be the best way to do it?
Any sugges
Peter Bergner wrote:
On Mon, 2008-04-28 at 16:01 -0400, Vladimir Makarov wrote:
Thanks, Peter. That was clever and email is very enlightening. I have
analogous idea for more compact conflict matrix representation. IRA
builds allocno live ranges first (they are ranges of program points
wh
Snapshot gcc-4.1-20080428 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20080428/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Load builtins can't be const since they may return different values on
the same pointer value.
H.J.
On Mon, Apr 28, 2008 at 1:19 PM, H.J. Lu <[EMAIL PROTECTED]> wrote:
> I am combining most x86 SIMD builtins into bdesc_sse_args.
> I only define store builtins with def_builtin. The rest will be
>
On Mon, Apr 28, 2008 at 5:16 PM, H.J. Lu <[EMAIL PROTECTED]> wrote:
> Load builtins can't be const since they may return different values on
> the same pointer value.
They should be pure though.
-- Pinski
Martin Jambor <[EMAIL PROTECTED]> writes:
> I've been rebootstrapping my switch conversion patch (which is still
> waiting for review) to make sure it still works. Unfortunately, it
> did not. The error given was the following and I believe this is the
> warning introduced by Ian as a resp
On Mon, 2008-04-28 at 18:07 -0400, Vladimir Makarov wrote:
> I am currently working on bit matrix compression. It is not implemented
> yet. I hope it will be ready in a week.
Ahh, ok. Well, hopefully the code I wrote on the trunk is useful for IRA.
If you have questions about it, let me know,
Vladimir Makarov wrote:
Peter Bergner wrote:
On Mon, 2008-04-28 at 16:01 -0400, Vladimir Makarov wrote:
Thanks, Peter. That was clever and email is very enlightening. I
have analogous idea for more compact conflict matrix
representation. IRA builds allocno live ranges first (they are
ran
-- Forwarded message --
From: NoFirst NoLast <[EMAIL PROTECTED]>
Date: Mon, Apr 28, 2008 at 6:46 PM
Subject: gcc cross compiler problem
To: gcc@gcc.gnu.org
Hello gcc,
I am running into a problem when I am trying to compile GCC to run on
a i686-pc-linux-gnu (host) but to build sou
Diego Novillo wrote:
We have been bouncing ideas for a new mechanism to describe the behavior
of function calls so that optimizers can be more aggressive at call
sites. Currently, GCC supports the notion of pure/impure,
const/non-const, but that is not enough for various cases.
Fortran support
37 matches
Mail list logo
