Quoting daniel tian :
2009/2/26 Joern Rennecke :
the address label "common_reg " used many times. I think it will
load one time. But after optimized with '-Os' or '-O2', it still loads
the label "common_reg " six times..
Previously, you could define LEGITIMIZE_ADDRESS and
LEGITIMIZE_RELOAD_AD
2009/2/26 Dave Korn :
> daniel tian wrote:
>
>> there is a 'movm' problem that puzzled me. In my target machine,
>> to load a large immediate data, can only move into zero register "R0".
>> but R0 is a generally register. I defined the the way in the
>> following:
>>
>> if the immediate dat
2009/2/26 Joern Rennecke :
>> the address label "common_reg " used many times. I think it will
>> load one time. But after optimized with '-Os' or '-O2', it still loads
>> the label "common_reg " six times..
>
> Previously, you could define LEGITIMIZE_ADDRESS and
> LEGITIMIZE_RELOAD_ADDRESS
> to ge
Ian Lance Taylor writes:
> I've put a project proposal for split stacks on the wiki at
> http://gcc.gnu.org/wiki/SplitStacks . The idea is to permit the stack
> of a single thread to be split into discontiguous segments, thus
> permitting many more threads to be active at one time without worryi
On Thu, 2009-02-26 at 17:02 -0800, David Daney wrote:
> Laurent GUERBY wrote:
> > On Thu, 2009-02-26 at 21:04 +, Richard Sandiford wrote:
> >> Laurent GUERBY writes:
> >>> I was wondering why mips64*-*-linux does not have the same
> >>> handling of multiarch as powerpc/sparc/x86 in gcc/config.
Laurent GUERBY wrote:
On Thu, 2009-02-26 at 21:04 +, Richard Sandiford wrote:
Laurent GUERBY writes:
I was wondering why mips64*-*-linux does not have the same
handling of multiarch as powerpc/sparc/x86 in gcc/config.gcc:
32 bits compiler binaries with 32/64 target choice via "-m", --with-
On Thu, 2009-02-26 at 21:04 +, Richard Sandiford wrote:
> Laurent GUERBY writes:
> > I was wondering why mips64*-*-linux does not have the same
> > handling of multiarch as powerpc/sparc/x86 in gcc/config.gcc:
> > 32 bits compiler binaries with 32/64 target choice via "-m", --with-cpu
> > and
Hi,
in general, I like this proposal a lot. However,
> As a start there will be no-overflow variants of NEGATE_EXPR,
> PLUS_EXPR, MINUS_EXPR, MULT_EXPR and POINTER_PLUS_EXPR.
>
> The sizetypes will simply be operated on in no-overflow variants
> by default (by size_binop and friends).
>
> Nami
Snapshot gcc-4.3-20090226 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20090226/
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
Joel Sherrill writes:
> Ian Lance Taylor wrote:
>> I've put a project proposal for split stacks on the wiki at
>> http://gcc.gnu.org/wiki/SplitStacks . The idea is to permit the stack
>> of a single thread to be split into discontiguous segments, thus
>> permitting many more threads to be active
Ian Lance Taylor wrote:
I've put a project proposal for split stacks on the wiki at
http://gcc.gnu.org/wiki/SplitStacks . The idea is to permit the stack
of a single thread to be split into discontiguous segments, thus
permitting many more threads to be active at one time without worrying
about
I've put a project proposal for split stacks on the wiki at
http://gcc.gnu.org/wiki/SplitStacks . The idea is to permit the stack
of a single thread to be split into discontiguous segments, thus
permitting many more threads to be active at one time without worrying
about stack overflow or about wa
If you want to help admin the wiki, I am more than happy to make you a
super user.
That goes for Steven, etc.
On Thu, Feb 26, 2009 at 12:31 PM, Manuel López-Ibáñez
wrote:
> 2009/2/25 Gerald Pfeifer :
>> On Tue, 24 Feb 2009, Steven Bosscher wrote:
>>> Can someone *please* ban this nutcase from t
Laurent GUERBY writes:
> I was wondering why mips64*-*-linux does not have the same
> handling of multiarch as powerpc/sparc/x86 in gcc/config.gcc:
> 32 bits compiler binaries with 32/64 target choice via "-m", --with-cpu
> and --enable-targets support for configure. Is there any specific reason
>
2009/2/26 Grigori Fursin :
> Hi Manuel,
> I have been talking to a few mentors and students (not GCC related)
> who got their proposals accepted in the last year's Google Summer of Code
> and they basically told me that the mentors listed many different proposals
> so that students could have a ch
Hi Manuel,
Sure and thanks for the info - I know that students have
to submit proposals, but maybe I misunderstood the concept:
I have been talking to a few mentors and students (not GCC related)
who got their proposals accepted in the last year's Google Summer of Code
and they basically told m
2009/2/25 Gerald Pfeifer :
> On Tue, 24 Feb 2009, Steven Bosscher wrote:
>> Can someone *please* ban this nutcase from the wiki?
>> There is almost weekly spam added to the wiki from this account.
>> Thanks,
>
> Let me forward this to the overseers team...
>
A solution for only this particular cas
Hi Grigori,
About the wiki page http://gcc.gnu.org/wiki/SummerOfCode
Perhaps the table format for specific project ideas is clearer than
the bullet list format. However, we should not have two formats. If
the table is preferred, I suggest that other people that have added
ideas in a bullet list
Hi Grigori,
On Thu, Feb 26, 2009 at 04:57, Grigori Fursin wrote:
> Hello All,
>
> I just saw an announcement that a new Google Summer of Code'2009
> (http://code.google.com/soc) will be accepting project proposals
> in a week or so. My colleagues and I would like to submit a few proposals
> so wa
Alex Turjan wrote:
Hello,
Some time ago I asked a question regarding the possibility to schedule an operation on alternative functional units (FUs) AND depending on the chosen FUs to generate a dedicated assembly mnemonic.
To give a simple example suppose I have a move operation that can be is
Paul Brook wrote:
As I understand it, the ARM kernel can now do something similar. So,
the only use for a __builtin_return_address(N) that used the frame
pointer chain would be if the code were compiled with nonstandard
options.
>>> Correct.
>> Well, but wouldn't it still be
> >> As I understand it, the ARM kernel can now do something similar. So,
> >> the only use for a __builtin_return_address(N) that used the frame
> >> pointer chain would be if the code were compiled with nonstandard
> >> options.
> >
> > Correct.
>
> Well, but wouldn't it still be nice if __bui
Richard Guenther wrote:
> As a start there will be no-overflow variants of NEGATE_EXPR,
> PLUS_EXPR, MINUS_EXPR, MULT_EXPR and POINTER_PLUS_EXPR.
> Naming suggestions welcome, at the moment I consider NEGATEV_EXPR
> (thus appending V to the first part).
Wow, an actual /invitation/ to bikeshed!
daniel tian wrote:
> there is a 'movm' problem that puzzled me. In my target machine,
> to load a large immediate data, can only move into zero register "R0".
> but R0 is a generally register. I defined the the way in the
> following:
>
> if the immediate data (op1) is larger than 1024
>
I managed to build it with my own compiled version of GCC-4.3 under
Ubuntu. The stock 4.1 compilers failed on a -f flag IIRC, can't remember
what it was exactly though.
Luke.
On Thu, 26 Feb 2009, Joseph S. Myers wrote:
> On Thu, 26 Feb 2009, Richard Guenther wrote:
>
> > As a start there will be no-overflow variants of NEGATE_EXPR,
> > PLUS_EXPR, MINUS_EXPR, MULT_EXPR and POINTER_PLUS_EXPR.
>
> So you would have both wrapping and no-overflow versions of these codes
On Thu, 26 Feb 2009, Richard Guenther wrote:
> As a start there will be no-overflow variants of NEGATE_EXPR,
> PLUS_EXPR, MINUS_EXPR, MULT_EXPR and POINTER_PLUS_EXPR.
So you would have both wrapping and no-overflow versions of these codes
(with it of course always being valid for a transformatio
Hi,
I was wondering why mips64*-*-linux does not have the same
handling of multiarch as powerpc/sparc/x86 in gcc/config.gcc:
32 bits compiler binaries with 32/64 target choice via "-m", --with-cpu
and --enable-targets support for configure. Is there any specific reason
for this?
If reason is "jus
On Thu, 26 Feb 2009, Manuel López-Ibáñez wrote:
> 2009/2/26 Richard Guenther :
> >
> > There shall be no construct in the GIMPLE IL that invokes
> > undefined behavior.
>
> What about uninitialized variables?
That's unrelated and something I do not care about.
Richard.
the address label "common_reg " used many times. I think it will
load one time. But after optimized with '-Os' or '-O2', it still loads
the label "common_reg " six times..
Previously, you could define LEGITIMIZE_ADDRESS and LEGITIMIZE_RELOAD_ADDRESS
to get reasonable code. However, that no long
Hi Jean,
> Do you have a link to that patch? So that I can see if it applies for
me ?
See patch below. I put in some comments to try and explain what I have
attempted to do.
The hash SET generation, to track potential candidates in replacing a
register USE, needed some tweaking. This function wa
2009/2/26 Richard Guenther :
>
> There shall be no construct in the GIMPLE IL that invokes
> undefined behavior.
What about uninitialized variables?
Cheers,
Manuel.
There have been numerous issues in the past with respect to the
undefinedness of signed overflow in our IL, with the non-semantics
of sizetype and friends and with the pessimization of using
unsigned arithmetic vs. signed arithmetic in loop optimizations.
The goal of the no-undefined-overflow bra
hello,
there is a 'movm' problem that puzzled me. In my target machine,
to load a large immediate data, can only move into zero register "R0".
but R0 is a generally register. I defined the the way in the
following:
if the immediate data (op1) is larger than 1024
then do
{
Joel Sherrill wrote:
Hi,
I made a stupid typo and accidentally included
an unprotected file from itself. The error
message generated by gcc surprised me and I
wondered if there was a better alternative.
Seems like a perfectly fine message to me, what
do you suggest in its place (remember that
35 matches
Mail list logo
