and I was hoping that this might clear up a significant fraction of
the 7,000+ 64-bit testsuite failures for 4.1 on powerpc-apple-
darwin8.4.0. But it appears this hasn't happened yet.
Does anyone wish to try yet again to drive it into my thick skull
what goals gcc 4.1 has on powerpc-appl
On Sat, Jan 21, 2006 at 07:03:27PM -0800, Mark Mitchell wrote:
> Andrew Pinski wrote:
> > I noticed today that there were three projects which were merged into
> > the mainline within a 24 hour period yesterday.
> >
> > Date: Thu, 19 Jan 2006 01:42:49 - IAB - Daniel Berlin
> > Date: Thu, 19
ian@airs.com (Ian Lance Taylor) wrote on 21.01.06 in <[EMAIL PROTECTED]>:
> "Dave Korn" <[EMAIL PROTECTED]> writes:
>
> > I think he's saying that _this_ one might generate invalid code:
> >
> > void test(void)
> > {
> > union { int i; double d; } u;
> > int *ip;
> > dou
Ian Lance Taylor writes:
> [EMAIL PROTECTED] (Kai Henningsen) writes:
>> void test(void)
>> {
>> union { int i; double d; } u;
>> int *ip;
>> double *dp;
>> int ii;
>> double dd;
>>
>> ip = &u.i;
>> *ip = 15;
>> ii = *ip;
>>
Mark Mitchell <[EMAIL PROTECTED]> wrote:
>> Date: Thu, 19 Jan 2006 01:42:49 - IAB - Daniel Berlin
>> Date: Thu, 19 Jan 2006 10:24:04 - Vect - Dorit
>> Date: Thu, 19 Jan 2006 16:55:54 - GOMP - Diego Novillo
>>
>> So I am requesting that we go through a 48 hour period starting
>> Mon
On Mon, 16 Jan 2006, DJ Delorie wrote:
> Two copies of gcc, both configured for the same target and built from
> the same sources, should produce identical objects regardless of how
> they are built or what they run on.
For the record, this unfortunately isn't so, at least wasn't
weeks ago, compar
On 1/22/06, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Andrew Pinski wrote:
> > I noticed today that there were three projects which were merged into
> > the mainline within a 24 hour period yesterday.
> >
> > Date: Thu, 19 Jan 2006 01:42:49 - IAB - Daniel Berlin
> > Date: Thu, 19 Jan 2006 10
On Jan 22, 2006, Richard Sandiford <[EMAIL PROTECTED]> wrote:
> Ian Lance Taylor writes:
>> [EMAIL PROTECTED] (Kai Henningsen) writes:
>>> void test(void) { union { int i; double d; } u;
>>> int *ip; double *dp; int ii; double dd;
>>> ip = &u.i; *ip = 15; ii = *ip; dp = &u.d; *dp = 1.5; dd =
On 1/22/06, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> I don't think it is any different. GCC's exception for unions only
> applies if the object is accessed using the union type. So they are
> indeed equivalent. The scary thing is that I don't think they
> actually violate the ISO C strict a
> I use:
> --enable-checking=misc,tree,gc,rtl,rtlflag,assert
> [...]
>
> Andreas
FYI, you're missing "runtime" checking in that list which is normally
part fo the default set. I use --enable-checking=yes,rtl when I want
to add "rtl" to the default list so I don't miss any existing (or
newly
On 2006-01-22, at 04:35, Andrew Pinski wrote:
OK. Looking closer I have just found that in gcc/toplev.c
#if GCC_VERSION < 3004
...
#endif
Is missing around the floor_log2() and exact_log2() functions.
You are mssing the fact that the ones in the headers are declared
as extern inline.
Yes
On Sun, 22 Jan 2006, Richard Sandiford wrote:
> I'm going to regret this, but... I don't follow. How is Kai's testcase
> different from:
>
> int ii;
> double dd;
> void foo (int *ip, double *dp)
> {
> *ip = 15;
> ii = *ip;
> *dp = 1.5;
> dd = *dp;
> }
>
> void test (void)
> {
> union
On Sun, 22 Jan 2006, Richard Guenther wrote:
> ISO C says that the following violates aliasing rules:
>
> int foo(float f)
> {
> union { int i; float f; } u;
> i.f = f;
> return i.i;
> }
>
> because the memory at u is accessed as two different effective types.
> Using a union doesn't chang
Andrew Pinski <[EMAIL PROTECTED]> writes:
> No. This is GCC "extern inline" and not C99 "extern inline".
Does GCC plan to move to the C99 semantics of inline and extern inline
in C?
--
__("< Marcin Kowalczyk
\__/ [EMAIL PROTECTED]
^^ http://qrnik.knm.org.pl/~qrczak/
Inside gcc/target.h we have the declaration of
struct gcc_target { struct asm_out { struct sched { ...
there is a function refernce field named
int (* branch_target_register_class) (void);
The only place where this is referenced is in gcc/bt-load.c
and in esp the global branch_target_loa
On Sun, Jan 22, 2006 at 05:00:34PM +0100, Marcin Dalecki wrote:
> Inside gcc/target.h we have the declaration of
> struct gcc_target { struct asm_out { struct sched { ...
> there is a function refernce field named
>
> int (* branch_target_register_class) (void);
>
> The only place where thi
"Joseph S. Myers" <[EMAIL PROTECTED]> writes:
> On Sun, 22 Jan 2006, Richard Sandiford wrote:
>
>> I'm going to regret this, but... I don't follow. How is Kai's testcase
>> different from:
>>
>> int ii;
>> double dd;
>> void foo (int *ip, double *dp)
>> {
>> *ip = 15;
>> ii = *ip;
>> *dp =
Andreas,
FWIW I've had successful bootstrap with these checking flags on
x86_64-unknown-lunux-gnu
Graham
Richard Sandiford <[EMAIL PROTECTED]> writes:
> I was just trying to point out that Ian's claim that the original code
> was valid doesn't reflect what GCC implements.
Yeah, I think I'm going to step back from trying to argue what is and
is not valid. To cut to the chase, I think the best approa
On 2006-01-22, at 17:08, Daniel Jacobowitz wrote:
On Sun, Jan 22, 2006 at 05:00:34PM +0100, Marcin Dalecki wrote:
Inside gcc/target.h we have the declaration of
struct gcc_target { struct asm_out { struct sched { ...
there is a function refernce field named
int (* branch_target_regist
Graham Stott wrote:
Andreas,
FWIW I've had successful bootstrap with these checking flags on
x86_64-unknown-lunux-gnu
Graham
My bootstrap was fine also using x86_64-suse-linux-gnu.
Kenny
Andreas Jaeger wrote:
Andrew Pinski <[EMAIL PROTECTED]> writes:
On Jan 21, 2006, at 1:09 PM, Andreas Jaeger wrote:
On Sat, Jan 21, 2006 at 12:42:24PM -0500, Andrew Pinski wrote:
On Jan 21, 2006, at 12:38 PM, Andreas Jaeger wrote:
I'm still seeing this with current S
Ian Lance Taylor wrote:
> Yeah, I think I'm going to step back from trying to argue what is and
> is not valid. To cut to the chase, I think the best approach for this
> particular problem is to wholly avoid having union types share the
> same stack slot.
RTH agrees with you.
Upon reading the th
Hi!
I'm keeping an eye on building GCC for vax-linux /vax-linux-uclibc (only
some config changes needed for that; I'll submit those once the first libc
support is committed). Note that this is a cc0 port.
An automated build at 20060120-141501 UTC still showed the ICE in
udivmodsi4.c . This was p
Hello,
> I'm keeping an eye on building GCC for vax-linux /vax-linux-uclibc (only
> some config changes needed for that; I'll submit those once the first libc
> support is committed). Note that this is a cc0 port.
>
> An automated build at 20060120-141501 UTC still showed the ICE in
> udivmodsi4.
On Sun, 2006-01-22 21:49:31 +0100, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
[...]
> > This is the SIGN_EXTRACT case of expand_compound_operation(), maybe this
> > does ring a
> > bell?
>
> no idea; this is either completely unrelated, or we randomly clobber memory
> somewhere.
> Could you please
On Sun, 2006-01-22 21:54:47 +0100, Jan-Benedict Glaw <[EMAIL PROTECTED]> wrote:
> On Sun, 2006-01-22 21:49:31 +0100, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
> [...]
> > > This is the SIGN_EXTRACT case of expand_compound_operation(), maybe this
> > > does ring a
> > > bell?
> >
> > no idea; this
> Sometimes I have got a bus error at libstdc++ with gcc 3.4.2 in SUN.
I'm afraid the information you've given is pretty scant. Far more
information will be required, plus some work on your side to try and
isolate the problem.
Perhaps you could try reporting the problem to the gcc-help@ list,
wi
>
> Mark Mitchell <[EMAIL PROTECTED]> wrote:
>
> >> Date: Thu, 19 Jan 2006 01:42:49 - IAB - Daniel Berlin
> >> Date: Thu, 19 Jan 2006 10:24:04 - Vect - Dorit
> >> Date: Thu, 19 Jan 2006 16:55:54 - GOMP - Diego Novillo
> >>
> >> So I am requesting that we go through a 48 hour perio
>
> --ZMT28BdW279F9lxY
> Content-Type: text/plain; charset=utf-8
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> On Sun, 2006-01-22 21:49:31 +0100, Zdenek Dvorak <[EMAIL PROTECTED]
> cuni.cz> wrote:
> [...]
> > > This is the SIGN_EXTRACT case of expand_compound_ope
Andrew Pinski <[EMAIL PROTECTED]> writes:
| >
| > Mark Mitchell <[EMAIL PROTECTED]> wrote:
| >
| > >> Date: Thu, 19 Jan 2006 01:42:49 - IAB - Daniel Berlin
| > >> Date: Thu, 19 Jan 2006 10:24:04 - Vect - Dorit
| > >> Date: Thu, 19 Jan 2006 16:55:54 - GOMP - Diego Novillo
| > >>
|
Richard Guenther wrote:
> I would even extend this "slush" to the point where all P1 4.1 regressions are
> fixed and a first 4.1.0 RC could be built.
Shutting down the mainline to get folks to focus on 4.1 is a step I'd
prefer not to take; I'm hopeful that the 4.1 P1s will get the attention
they
I'll look further into this myself now, thanks for trying to reproduce
this,
Andreas
--
Andreas Jaeger, [EMAIL PROTECTED], http://www.suse.de/~aj/
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
pgpm7PO
33 matches
Mail list logo
