On Sat, Sep 10, 2005 at 12:57:49PM +0930, Alan Modra wrote:
> Also stack deallocation when finished with alloca memory.
Ah.
> For some reason 4.0/4.1 doesn't combine this deallocation with
> stack adjustment in the epilogue, a regression from 3.4.
Yeah, I've been meaning to write a pass that goe
On Fri, Sep 09, 2005 at 05:03:48PM -0700, Richard Henderson wrote:
> On Sat, Sep 10, 2005 at 01:00:04AM +0930, Alan Modra wrote:
> > 2) Next, I defined parallels to keep things together. Like the
> > following, with another for DImode.
>
> This seems most reasonable to me.
>
> > This works, but
Ian Lance Taylor wrote:
> According to the PR, the bug is fixed in 4.1. You are testing a
> gcc-4.0 snapshot. Try testing a gcc-4.1 snapshot.
Then he's saying this is still a regression in gcc-4.0?
On Fri, Sep 09, 2005 at 04:58:50PM +0100, Joern RENNECKE wrote:
> The lack of a debugger that works reliably with recent gcc versions has
> led to an increasing backlog of uninvestigated execution failures.
Do you think it's the debugger or the compiler that's at fault?
r~
On Sat, Sep 10, 2005 at 01:00:04AM +0930, Alan Modra wrote:
> 2) Next, I defined parallels to keep things together. Like the
> following, with another for DImode.
This seems most reasonable to me.
> This works, but doesn't give ideal power4/5 insn grouping, with (I
> think) one too many nops bei
On Fri, Sep 09, 2005 at 11:57:07AM +0100, Andrew Haley wrote:
> I can't find a Bugzilla entry for this. Is it really a bug?
You'd have to get a c++ ruling to be sure, but from the code that
makes it to the middle end, it's not a bug.
The main::bar::bar() constructor catches the throw from the f
Olivier Hainque wrote:
> I'm not yet clear why the call is not issued there. This is my first
> dive in the gimplifier, so it might well be simple.
FWIW, I think part of the problem is that TREE_SIDE_EFFECTS is not
set on the constructor, despite the presence of a function call in
the compone
On Sep 9, 2005, at 4:40 PM, Olivier Hainque wrote:
Olivier Hainque wrote:
I'm not yet clear why the call is not issued there. This is my first
dive in the gimplifier, so it might well be simple.
FWIW, I think part of the problem is that TREE_SIDE_EFFECTS is not
set on the constructor, de
On Sep 9, 2005, at 4:40 PM, Olivier Hainque wrote:
Olivier Hainque wrote:
I'm not yet clear why the call is not issued there. This is my first
dive in the gimplifier, so it might well be simple.
FWIW, I think part of the problem is that TREE_SIDE_EFFECTS is not
set on the constructor, de
Etienne Lorrain <[EMAIL PROTECTED]> writes:
> I do not know if
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23477
> should be fixed in this release, but I am sure
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23631
> which was marked as duplicate is not fixed:
According to the PR, the bug
On Fri, Sep 09, 2005 at 10:47:43AM -0400, Vladimir N. Makarov wrote:
> - If you want to see the hybrid compiler as a part of gcc project, how
> are you going to solve the copyright problem? As I know, although ORC
> code is also distributed under GNU license, the copyright belongs to
> SGI. A
Ian Lance Taylor wrote:
> Mark Mitchell <[EMAIL PROTECTED]> writes:
>
>
>>Let's start with the simpler friend10.C. There, the "operator bool()"
>>conversion operator is irrelevant, as far as I can see. However, we
>>*should* still call the friend operator<<, because argument-dependent
>>lookup
Mark Mitchell <[EMAIL PROTECTED]> writes:
> Let's start with the simpler friend10.C. There, the "operator bool()"
> conversion operator is irrelevant, as far as I can see. However, we
> *should* still call the friend operator<<, because argument-dependent
> lookup is explicitly defined that way.
=
Both binutils and glibc's configure scripts will see
it as a mips32, because it does not start off with
mips64 in the name.
Should probably fix the configury to recognize mipsisa64 as a 64-bit
target. binutils should already do this for mipsisa64-linux-gnu, but
I don't know about current g
> Is 'ld' a part of gcc toolchain?
See http://sources.redhat.com/binutils/
>6617 char *s = find_a_file (&exec_prefixes, "collect2", X_OK, 0);
collect2 is a wrapper around ld which invokes ld twice if needed -
once to gather information, and a second time with an additional
object it g
On Sep 9, 2005, at 10:28 AM, sean yang wrote:
Hi
I am looking for the source code related to linking stage--coz I am
trying to modify (very slightly) the linker. I understand that 'ld'
is the linker in Linux. My question is:
Is 'ld' a part of gcc toolchain?
--If it is, I should be able to
As I said, I haven't looked at the code in awhile (before GIMPLE), but
the TREE code is the symbol table that allows you to look up the types
of arguments and the function return type. The RTX code are the
instructions you produce for va_arg, etc. For example, I believe the
eabi/System V had a st
hey
i could become a mirror if you want
i'm from rome italy
the server is in Arezzo Italy
i have 3 domains that you could mirror though if u wanted
let me know please :)
win.ac3bf1.com
lnx.ac3bf1.com
rjn.it
P.S. = send me the files to upload right away if u want or tell me
what u want 2 upl
Hi
I am looking for the source code related to linking stage--coz I am trying
to modify (very slightly) the linker. I understand that 'ld' is the linker
in Linux. My question is:
Is 'ld' a part of gcc toolchain?
--If it is, I should be able to find source file producing 'ld'. But I
haven't fou
Joern RENNECKE <[EMAIL PROTECTED]> wrote:
> I can't justify spending the amount time that it would take to make the
> sh64 port regression free.
> The lack of a debugger that works reliably with recent gcc versions has
> led to an increasing
> backlog of uninvestigated execution failures.
For ref
I can't justify spending the amount time that it would take to make the
sh64 port regression free.
The lack of a debugger that works reliably with recent gcc versions has
led to an increasing
backlog of uninvestigated execution failures.
Ian Lance Taylor wrote:
> Now that my patch handles the above case correctly, the test
> g++.dg/template/friend10.C fails. And the original test case in PR
> 5116 fails.
>
> I think the issue here is whether we should prefer an explicitly
> declared conversion operator over a friend function foun
PR23774 shows a situation where powerpc-linux (and other rs6000 targets)
break an ABI requirement that 0(r1) always holds a pointer to the
previous stack frame, except for the topmost frame. This particular
case concerns dynamic stack (eg. alloca) deallocation. The other case
where this happens i
Hi all,
is it possible to map a region on memory copy on write using this idea?
I have an invalid argument in the mmap call.
Why?
#include
#include
#include
#include
#include
#include
#include
#include
#include
#define MAXPATH 255
int main (int argc, char **argv)
{
char *s,*x;
int
On 09/08/05 16:25, Laurent GUERBY wrote:
FYI, this fixes both PR ada/23141 and ada/23142.
Well, but I cannot get a clean bootstrap with it. It fails building
libstdc++ on x86_64 and libgfortran on x86. I'll have to poke more.
Andrew Pinski wrote:
> > I have been experimenting with a simple patch adding side effects
> > checks to the conditions, like "! TREE_SIDE_EFFECTS (value)"
> > in init_ctor_eval
>
> Yes the one in needs to gimplify only the expression as a statement
> and not add a modify statement. More on the t
[EMAIL PROTECTED] wrote:
Although many of us are involved, or have been involved, with other
compiler projects, the focus of the Gelato GCC Improvement Group is to
work *with* the GCC community *and* the GCC community *process* to
improve GCC for Itanium.
Some of the other projects which indi
> Yao qi writes:
>> Yes. TARGET_HARD_FLOAT is defined as
>>
>> #define TARGET_HARD_FLOAT ((target_flags & MASK_SOFT_FLOAT) == 0)
>>
>> The -mhard-float option will clear the MASK_SOFT_FLOAT bit in
>> target_flags.
Yao> Yes, this option works when I use it in GDB like this,
Yao> (gdb) run -
hi,
if this bug get's fixed, will there be an upcoming release of gcc3.4
that could include it ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21931
it will be some work to figure it out, fix it, and make sure everyone is
happy. i don't want to make
that investment if it will not get out to t
Daniel Berlin wrote:
> > spinlock_t lock = (spinlock_t) { .raw_lock = one_raw_spinlock() };
>
> What exactly is this code expected to do?
> Call one_raw_spinlock and then throw away the result?
Yes. As you said, the result is nothing anyway, but the function should
still be called IMO.
>
Daniel Berlin <[EMAIL PROTECTED]> writes:
| >int main(void)
| >{
| > spinlock_t lock = (spinlock_t) { .raw_lock = one_raw_spinlock() };
|
| What exactly is this code expected to do?
| Call one_raw_spinlock and then throw away the result?
yes, that is implied by C99 semantics.
-- Ga
Dave Korn wrote:
> Surely returning the vaule of this uninitialised variable makes your code
> invalid?
Well, sure. Adding an initializer in one_raw_spinlock doesn't help.
The t03.gimple dump reads:
main ()
{
struct spinlock_t D.1783;
int D.1784;
struct spinlock_t lock;
>int main(void)
>{
> spinlock_t lock = (spinlock_t) { .raw_lock = one_raw_spinlock() };
What exactly is this code expected to do?
Call one_raw_spinlock and then throw away the result?
If so, feel free to change gimplify_init_ctor_eval to do that.
But again, if you expect "real" sets
Original Message
>From: Olivier Hainque
>Sent: 09 September 2005 14:25
> You may have side effect from an initializer when setting a zero
> sized field.
>
> For instance (variant of gcc.c-torture/compile/zero-strct-4.c), compiled
> with GCC 3.4, the code below prints "returning raw_lo
Daniel Berlin wrote:
> Even if you "fixed" init_ctor_eval (modify_expr gimplifies the lhs and rhs
> and throws away the assignment), you're going to run into problems in
> the subvar machinery if you really have 0 sized field accesses with side
> effects.
>
> I'm not sure what the heck a "0 siz
On Fri, 9 Sep 2005, Olivier Hainque wrote:
Hello,
In a number of places, the gimplifier simply discards what involves
zero sized entities. For instance:
in "gimplify_init_ctor_eval"...
FOR_EACH_CONSTRUCTOR_ELT (elts, ix, purpose, value)
...
if (zero_sized_field_decl (purpose
On Sep 9, 2005, at 8:30 AM, Olivier Hainque wrote:
Hello,
I have been experimenting with a simple patch adding side effects
checks to the conditions, like "! TREE_SIDE_EFFECTS (value)"
in init_ctor_eval
Yes the one in needs to gimplify only the expression as a statement
and not add a modify
Hello,
In a number of places, the gimplifier simply discards what involves
zero sized entities. For instance:
in "gimplify_init_ctor_eval"...
FOR_EACH_CONSTRUCTOR_ELT (elts, ix, purpose, value)
...
if (zero_sized_field_decl (purpose))
continue;
or in "gimplify_mod
Please, explain, why mips.md specifies c.eq.d, c.eq.s instructions
in seq_df and seq_sf RTF templates? Why not c.seq.d and c.seq.s?
Seems, use of c.eq.d, c.eq.s causes violation of IEC 60559.
Best regards,
Nadezhda I. Vyukova
Snapshot gcc-4.1-20050909 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20050909/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 CVS branch
with the following options: -D2005-09-09 10:43 UTC
You'll
Yes. TARGET_HARD_FLOAT is defined as
#define TARGET_HARD_FLOAT ((target_flags & MASK_SOFT_FLOAT) == 0)
The -mhard-float option will clear the MASK_SOFT_FLOAT bit in
target_flags.
Yes, this option works when I use it in GDB like this,
(gdb) run -mhard-float
../../gcc-dfp-cvs-Aung-10/gcc/t
There's a thread at
http://groups.google.co.uk/group/gnu.gcc.help/tree/browse_frm/thread/e85dce7d69fb7dc1
which looks odd. It seems that the exception filter is not being
correctly processed.
I can't find a Bugzilla entry for this. Is it really a bug?
Andrew.
quoted message ---
From: "Meissner, Michael" <[EMAIL PROTECTED]>
To: "Yao qi" <[EMAIL PROTECTED]>
CC: gcc@gcc.gnu.org
Subject: RE: var_args for rs6000 backend
Date: Thu, 8 Sep 2005 21:19:25 -0400
Yes, the eABI is a modification of the System V ABI. IIRC (but it has
been several years since I worked on PowerPC),
I do not know if
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23477
should be fixed in this release, but I am sure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23631
which was marked as duplicate is not fixed:
[EMAIL PROTECTED]:~/projet/gujin$ cat > tmp.c
int
sub (int i)
{
int array[100]
Hello again!
Olivier> Can GCC 4.X be used to generate code running properly on a MPC5554
Olivier> processor ?
The base PowerPC Book-E UISA generated by GCC should work on the
MPC5554. I am not sure about the difference between the 5554 e200 core
and the 8540 e500 core.
Oh, i've just
Hello!
David Edelsohn wrote:
Olivier Hainque writes:
Olivier> Can GCC 4.X be used to generate code running properly on a MPC5554
Olivier> processor ?
The base PowerPC Book-E UISA generated by GCC should work on the
MPC5554. I am not sure about the difference between the 5554 e200 cor
"Yao qi" <[EMAIL PROTECTED]> writes:
> Do you mean the value of TARGET_HARD_FLOAT is *1* when option -mhard-float
> is specified according to rs6000.opt ?
Yes. TARGET_HARD_FLOAT is defined as
#define TARGET_HARD_FLOAT ((target_flags & MASK_SOFT_FLOAT) == 0)
The -mhard-float option will clear t
[ Redirected from gcc-patches@ to gcc@ ]
Mark Mitchell <[EMAIL PROTECTED]> writes:
> This case is particularly tricky because of the fact that accepting
> the invalid code also means that we'll change the meaning of some
> valid code. For example, in:
>
> int f(int) {
>return 1;
> }
>
> st
From: Andrew Pinski <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] (Yao qi)
CC: ian@airs.com, gcc@gcc.gnu.org
Subject: Re: var_args for rs6000 backend
Date: Fri, 9 Sep 2005 01:51:58 -0400 (EDT)
> BTW, I am concerned about the value of TARGET_HARD_FLOAT and
TARGET_FPRS,
> I think both of them is 1 her
49 matches
Mail list logo
