Snapshot gcc-4.4-20090313 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20090313/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
Hi,
Ian Lance Taylor ha scritto:
Francesco Montorsi writes:
I'm new to GCC project so let me know if this is the wrong place
where I can ask such a question.
The mailing list gcc-h...@gcc.gnu.org would be a better place.
ok, thanks for the info; I'll post there in future.
However if I
I set up your patch and I get an internal error on this test program:
extern void foo(int, int);
extern int bar(void);
int startup;
void foobar()
{
int i;
while(1)
{
if (bar()) {
foo(0,0);
}
}
}
Here's the error:
/home/beyler/cyclops64/src/tnt/kernel/process_manager/testn
Francesco Montorsi writes:
> I'm new to GCC project so let me know if this is the wrong place
> where I can ask such a question.
The mailing list gcc-h...@gcc.gnu.org would be a better place.
> I've found a bug in Gcc 4.3.3 (on machine "Linux ubuntu
> 2.6.28-9-generic #31-Ubuntu SMP Wed Mar
Hi,
I'm new to GCC project so let me know if this is the wrong place where I can
ask such a question.
I've found a bug in Gcc 4.3.3 (on machine "Linux ubuntu 2.6.28-9-generic
#31-Ubuntu SMP Wed Mar 11 15:43:49 UTC 2009 x86_64 GNU/Linux") which I can
reliably reproduce (just running "make")
Steven Bosscher wrote:
On Fri, Mar 13, 2009 at 5:04 PM, Richard Guenther wrote:
We have been asked by the SC to not branch for now but wait for
the wording for the new runtime license to arrive from the FSF and
that being put in place.
This is the saddest thing that I have seen in GCC politi
This is similar to the discussion that happened some time ago about
extending return values. The decisions for that was that the callee
could just leave the higher bits undefined and the caller would
extent the result if it needed to.
We have a similar issue with function arguments. We compile
vo
On Fri, Mar 13, 2009 at 6:06 PM, Paolo Bonzini wrote:
>
> So, I'd still need the information for arm and m68k, because that
> information is about the bitfield instructions.
For ARM, shifts by immediate use a 5-bit constant, shifts by register
use the lower 8 bits of the register.
For ARMv6T2/AR
> Date: Fri, 13 Mar 2009 12:34:49 +0100
> From: Paolo Bonzini
> I would like to know whether for avr,bfin,cris,frv,h8300,pdp11,rs6000
> (which define SHIFT_COUNT_TRUNCATED as 0) and for mcore,sh,vax (which
> do not define it at all) it is right that shift counts are never
> truncated.
The answer
On Fri, 13 Mar 2009, Richard Guenther wrote:
> Last time I sent a patch to remove the SHIFT_COUNT_TRUNCATED check
> from fold-const.c the reason that this was rejected was that we want to
> be consistend with target behavior...
I would disagree with such a rejection. If we want to provide any so
On Fri, Mar 13, 2009 at 10:25:34AM -0700, Richard Guenther wrote:
> The topmost sentence should be unambiguous. Yes, the SC asked us not
> to branch.
The request came from RMS, the SC just passed it on.
On Fri, Mar 13, 2009 at 7:03 PM, Joe Buck wrote:
> On Fri, Mar 13, 2009 at 09:30:19AM -0700, Steven Bosscher wrote:
>> On Fri, Mar 13, 2009 at 5:04 PM, Richard Guenther wrote:
>> > We have been asked by the SC to not branch for now but wait for
>> > the wording for the new runtime license to arri
Paolo Bonzini writes:
> In addition, for arm and m68k I'd like to know whether bitfield
> instructions truncate the bit position the same as shifts (8 bits for
> arm, 6 bits for m68k).
For the m68k bitfield insns (when operating on memory) the bit position
can be in the full range of a signed 32
On Fri, Mar 13, 2009 at 7:07 PM, Joseph S. Myers
wrote:
> On Fri, 13 Mar 2009, Richard Guenther wrote:
>
>> Hm. In fold-const.c we try to make sure to produce the same result
>> as the target would for constant-folding shifts. Thus, Paolo, I think
>> what fold-const.c does is what we should assu
On Fri, 13 Mar 2009, Richard Guenther wrote:
> Hm. In fold-const.c we try to make sure to produce the same result
> as the target would for constant-folding shifts. Thus, Paolo, I think
> what fold-const.c does is what we should assume for
> !SHIFT_COUNT_TRUNCATED. No?
I think attempting the s
On Fri, Mar 13, 2009 at 09:30:19AM -0700, Steven Bosscher wrote:
> On Fri, Mar 13, 2009 at 5:04 PM, Richard Guenther wrote:
> > We have been asked by the SC to not branch for now but wait for
> > the wording for the new runtime license to arrive from the FSF and
> > that being put in place.
>
> T
On Fri, 13 Mar 2009, Steven Bosscher wrote:
> Or what about branching now and starting the gcc 4.5 development
> cycle? The argument against this, that the same changes will have to
There might also be the temptation to create a trunk-substitute branch to
receive Stage 1 developments and branch
> Note, one thing I encountered when doing the SSE5 work at AMD, is
> SHIFT_COUNT_TRUNCATED really needs a mode argument (and ideally should be
> moved
> into the gcc_target structure).
In fact I'm reusing the TARGET_SHIFT_TRUNCATION_MASK element that is
already there and accepts a mode.
Paolo
> "Paolo" == Paolo Bonzini writes:
Paolo> These are all the !SHIFT_COUNT_TRUNCATED targets. For 4.5 I
Paolo> would like to improve our RTL canonicalization so that no
Paolo> out-of-range shifts are ever in the RTL representation.
Paolo> This in turn means that the description given by
On Fri, Mar 13, 2009 at 6:47 PM, Dave Korn
wrote:
> Steven Bosscher wrote:
>
>> Or ship as-is and fix the license for GCC 4.5. I haven't followed the
>> legal discussion -- so maybe I'm being naive or I've missed it -- but
>> I haven't seen anyone explaining why this is not an option.
>
> I can
Steven Bosscher wrote:
> Or ship as-is and fix the license for GCC 4.5. I haven't followed the
> legal discussion -- so maybe I'm being naive or I've missed it -- but
> I haven't seen anyone explaining why this is not an option.
I can see why that won't work. If there's a problem with the cur
Richard Guenther wrote:
> On Fri, 13 Mar 2009, Dave Korn wrote:
>
On Fri, Mar 13, 2009 at 5:04 PM, Richard Guenther
wrote:
> We have been asked by the SC to not branch for now but wait for
>
> [...]
>
>> Can anyone clarify if the SC *really* need us to not branch before the
>>
On Fri, Mar 13, 2009 at 06:25:34PM +0100, Richard Guenther wrote:
> On Fri, 13 Mar 2009, Dave Korn wrote:
>
> > >> On Fri, Mar 13, 2009 at 5:04 PM, Richard Guenther
> > >> wrote:
> > >>> We have been asked by the SC to not branch for now but wait for
>
> [...]
>
> > Can anyone clarify if the
I found that compiling for mips with -mabi=n32 produces such inefficient code.
When -mabi=n32, mips_return_in_memory returns 0 if size is small regardless
BLKmode or not.
.type foo, @function
foo:
.frame $sp,16,$31 # vars= 16, regs= 0/0, args= 0, gp= 0
a
On Fri, 13 Mar 2009, Janis Johnson wrote:
> On Fri, 2009-03-13 at 17:04 +0100, Richard Guenther wrote:
> > Status
> > ==
> >
> > The trunk is still in stage 4 which means it is open under the usual
> > release branch rules. Thus the trunk is open for regression and
> > documentation fixes on
On Fri, 2009-03-13 at 17:04 +0100, Richard Guenther wrote:
> Status
> ==
>
> The trunk is still in stage 4 which means it is open under the usual
> release branch rules. Thus the trunk is open for regression and
> documentation fixes only.
What do you think about possibly-disruptive testsuit
On Fri, 13 Mar 2009, Dave Korn wrote:
> >> On Fri, Mar 13, 2009 at 5:04 PM, Richard Guenther
> >> wrote:
> >>> We have been asked by the SC to not branch for now but wait for
[...]
> Can anyone clarify if the SC *really* need us to not branch before the
> license change, as opposed to merely
[resend to list only owing to running up against the spamfilter]
Manuel López-Ibáñez wrote:
> 2009/3/13 Steven Bosscher :
>> On Fri, Mar 13, 2009 at 5:04 PM, Richard Guenther wrote:
>>> We have been asked by the SC to not branch for now but wait for
>>> the wording for the new runtime license to
On Fri, Mar 13, 2009 at 5:42 PM, Manuel López-Ibáñez
wrote:
> 2009/3/13 Steven Bosscher :
>> On Fri, Mar 13, 2009 at 5:04 PM, Richard Guenther wrote:
>>> We have been asked by the SC to not branch for now but wait for
>>> the wording for the new runtime license to arrive from the FSF and
>>> that
On Mar 13, 2009, at 10:06 AM, Paolo Bonzini wrote:
Hm. In fold-const.c we try to make sure to produce the same result
as the target would for constant-folding shifts. Thus, Paolo, I
think
what fold-const.c does is what we should assume for
!SHIFT_COUNT_TRUNCATED. No?
Unfortunately it is
>>> Hm. In fold-const.c we try to make sure to produce the same result
>>> as the target would for constant-folding shifts. Thus, Paolo, I think
>>> what fold-const.c does is what we should assume for
>>> !SHIFT_COUNT_TRUNCATED. No?
>> Unfortunately it is not so simple. fold-const.c is actuall
2009/3/13 Steven Bosscher :
> On Fri, Mar 13, 2009 at 5:04 PM, Richard Guenther wrote:
>> We have been asked by the SC to not branch for now but wait for
>> the wording for the new runtime license to arrive from the FSF and
>> that being put in place.
>
> This is the saddest thing that I have seen
Hello,
I came across an issue regarding BLKmode and returning structure in register.
For following code, I try to return the structure in register instead of
memory.
extern void abort();
typedef struct {
short x;
short y;
} COMPLEX;
COMPLEX foo (void) __attribute__ ((noinline));
COMPLE
On Fri, Mar 13, 2009 at 5:04 PM, Richard Guenther wrote:
> We have been asked by the SC to not branch for now but wait for
> the wording for the new runtime license to arrive from the FSF and
> that being put in place.
This is the saddest thing that I have seen in GCC politics so far.
Gr.
Steven
Richard Guenther writes:
> We have been asked by the SC to not branch for now but wait for
> the wording for the new runtime license to arrive from the FSF and
> that being put in place.
We've been waiting a long time. At what point do we give up and
branch anyway?
Status
==
The trunk is still in stage 4 which means it is open under the usual
release branch rules. Thus the trunk is open for regression and
documentation fixes only.
We have been asked by the SC to not branch for now but wait for
the wording for the new runtime license to arrive from the
On Fri, Mar 13, 2009 at 12:34:49PM +0100, Paolo Bonzini wrote:
> These are all the !SHIFT_COUNT_TRUNCATED targets.
>
> For 4.5 I would like to improve our RTL canonicalization so that no
> out-of-range shifts are ever in the RTL representation.
>
> This in turn means that the description given by
On Thu, 12 Mar 2009, H.J. Lu wrote:
> > Executing on host:
> > /sw/src/fink.build/gcc44-4.3.999-20090312/darwin_objdir/gcc/xgcc
> > -B/sw/src/fink.build/gcc44-4.3.999-20090312/darwin_objdir/gcc/
> > /sw/src/fink.build/gcc44-4.3.999-20090312/gcc-4.4
> > -20090312/gcc/testsuite/gcc.dg/asm-b.c -
Paolo Bonzini wrote:
> So you have that in the RTL stream we should canonicalize "a << 32" to
> "a", but "a << (b & 31)" is not the same as "a << b"?
Yes when the msb of b is set.
> Also, how is the sign bit is significant? Does it determine whether the
> value is left- or right-shifted?
Yep
On Fri, Mar 13, 2009 at 4:07 PM, Paolo Bonzini wrote:
>
>> Hm. In fold-const.c we try to make sure to produce the same result
>> as the target would for constant-folding shifts. Thus, Paolo, I think
>> what fold-const.c does is what we should assume for
>> !SHIFT_COUNT_TRUNCATED. No?
>
> Unfort
> Hm. In fold-const.c we try to make sure to produce the same result
> as the target would for constant-folding shifts. Thus, Paolo, I think
> what fold-const.c does is what we should assume for
> !SHIFT_COUNT_TRUNCATED. No?
Unfortunately it is not so simple. fold-const.c is actually wrong, a
On Fri, Mar 13, 2009 at 2:14 PM, Bernd Schmidt wrote:
> Paolo Bonzini wrote:
>> These are all the !SHIFT_COUNT_TRUNCATED targets.
>>
>> For 4.5 I would like to improve our RTL canonicalization so that no
>> out-of-range shifts are ever in the RTL representation.
>>
>> This in turn means that the d
> /* Immediate shift counts are truncated by the output routines (or was it
>the assembler?). Shift counts in a register are truncated by SH. Note
>that the native compiler puts too large (> 32) immediate shift counts
>into a register and shifts by the register, letting the SH decide
On Fri, 2009-03-13 at 12:34 +0100, Paolo Bonzini wrote:
> These are all the !SHIFT_COUNT_TRUNCATED targets.
>
> For 4.5 I would like to improve our RTL canonicalization so that no
> out-of-range shifts are ever in the RTL representation.
>
> This in turn means that the description given by SHIFT_
> The Blackfin does not truncate shift counts. The documentation
> specifies that e.g. for "Dx >>= Dy" instructions, shift counts greater
> than 31 produce a result of zero. Other shift instructions use a sign
> extended part of the shift count to shift either left or right. "I
> don't know" is
Ian Lance Taylor wrote:
> Paolo Bonzini writes:
>
>> This in turn means that the description given by SHIFT_COUNT_TRUNCATED
>> must be exact. Right now !SHIFT_COUNT_TRUNCATED means "I don't know",
>> I want it to mean "it is never truncated".
>
> You need to do more work to make that happen, as
Paolo Bonzini wrote:
> These are all the !SHIFT_COUNT_TRUNCATED targets.
>
> For 4.5 I would like to improve our RTL canonicalization so that no
> out-of-range shifts are ever in the RTL representation.
>
> This in turn means that the description given by SHIFT_COUNT_TRUNCATED
> must be exact. R
Paolo Bonzini writes:
> This in turn means that the description given by SHIFT_COUNT_TRUNCATED
> must be exact. Right now !SHIFT_COUNT_TRUNCATED means "I don't know",
> I want it to mean "it is never truncated".
You need to do more work to make that happen, as SHIFT_COUNT_TRUNCATED
applies to b
Paolo Bonzini wrote:
> I would like to know whether for avr,bfin,cris,frv,h8300,pdp11,rs6000
> (which define SHIFT_COUNT_TRUNCATED as 0) and for mcore,sh,vax (which
> do not define it at all) it is right that shift counts are never
> truncated.
sh defines SHIFT_COUNT_TRUNCATED according to target
Andreas Schwab wrote:
> James Dennett writes:
>
>> This appears to be a difference between C and C++. Unfortunate.
>> 6.6.3 [stmt.return]/2 of N2800 says "Flowing off the end of a function
>> is equivalent to a return with no value; this results in undefined
>> behavior in a value-returning func
Hello,
I have been discussing lately with other people about implementing a
proof of concept for multiarch[1] (my objectives are to improve cross
building), as I understand you already have a nice approach to cross
building with-sysroot option, but I would like to know how much it
this compatibl
These are all the !SHIFT_COUNT_TRUNCATED targets.
For 4.5 I would like to improve our RTL canonicalization so that no
out-of-range shifts are ever in the RTL representation.
This in turn means that the description given by SHIFT_COUNT_TRUNCATED
must be exact. Right now !SHIFT_COUNT_TRUNCATED mea
Hello I posted to binutils list as I guess it is an ld problem, but
maybe some gcc people might be interested as well.
-- Forwarded message --
From: Hector Oron
Date: 2009/3/13
Subject: Re: ld fails to look under /usr/$arch-linux-gnu/lib64
To: binut...@sources.redhat.com
Hello,
James Dennett writes:
> This appears to be a difference between C and C++. Unfortunate.
> 6.6.3 [stmt.return]/2 of N2800 says "Flowing off the end of a function
> is equivalent to a return with no value; this results in undefined
> behavior in a value-returning function."
Since it's merely unde
On Thu, Mar 12, 2009 at 5:50 PM, Diego Novillo wrote:
> On Thu, Mar 12, 2009 at 12:46, Steven Bosscher wrote:
>> On Thu, Mar 12, 2009 at 5:36 PM, Diego Novillo wrote:
>>> The temptation is to use C++'s limits, but I'm concerned that may
>>> produce confusion somewhere down the line with the opti
Revital1 Eres/Haifa/IBM wrote on 13/03/2009 07:50:08:
> Hello,
>
> > > Using testsuite/gcc.dg/sms-6.c as an example and compiling it for
> > PowerPC,
> > > node 18 (see attachment) is in a SCC and cannot be scheduled until
> > spliting
> > > twice. The MII = 20 and the schedule can only be found
56 matches
Mail list logo
