This is the mail archive of the
mailing list for the GCC project.
Re: [tree-ssa] Merge status
- From: law at redhat dot com
- To: "Joseph S. Myers" <jsm at polyomino dot org dot uk>
- Cc: Ian Lance Taylor <ian at wasabisystems dot com>, Jason Merrill <jason at redhat dot com>, Diego Novillo <dnovillo at redhat dot com>, Paolo Bonzini <bonzini at gnu dot org>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 17 Mar 2004 07:31:09 -0700
- Subject: Re: [tree-ssa] Merge status
- Reply-to: law at redhat dot com
In message <Pine.LNX.email@example.com>, "Joseph
S. Myers" writes:
>I thought that free software was generally designed to be portable, not
>just to systems with GCC, and that glibc and the Linux kernel were
>exceptions to the norm of portability; certainly GNU software tries to be
I don't disagree. However, I suspect that GCC has become quite pervasive
and (sometimes unknowingly) people have started relying upon GCC extensions,
even in code which is supposed to be portable.
Assuming that's the case, I would _expect_ that these developers will happily
fix their code when the problems are pointed out. Unfortunately, I don't
have good insight into the hundred+ projects that are affected to know if
the reports that have been sent their way are being acted upon.
>(I suppose copying in the current version of obstack from gnulib, or in
>similar cases disabling __GNUC__ conditionals to switch to the portable
>non-GCC alternative, may be needed in some cases.)
Most of the cases I'm running into are not inside __GNUC__ conditionals.
Most are in fact inside macros with a small splattering directly in the
>(I also have the impression from past discussions on the GCC lists that
>the new C++ parser in 3.4 breaks almost all C++ software by being stricter
>without any deprecation period at all.)
I wouldn't say all C++ software. And so far the breakage I've seen has been
very straightforward to fix. Remove a semi-colon here, add a semi-colon
elsewhere, add a name to anonymous enum/class/structs which are used to
create objects with non-local scope and the like. Basically stuff that
doesn't require any brainpower to know what the correct fix would be.
There's a couple of cases where it looks like we might be mucking up
access control that I'll be sending to the C++ folks to get a "good/no good"
>So how were these casts-as-lvalues originally implemented by Sun for
>non-GCC platforms? Surely not using __extension__ and GNU extensions.
I suspect they simply didn't have the casts on incremented values inside
the offending macros. I suspect a great number of the lvalue casts which
have appeared are there merely to silence warnings.
>Perhaps the fixinclude for obstack.h needs to be generalised to cover
The obstack.h fix will take care of one case of what happens in xdr.h, but
I didn't see how to generalize it to the other cases.
>The 3.4 manual defines what a cast-as-lvalue means, so
>replacing with the expansion there (using __typeof__, in general, if the
>type of a macro parameter isn't specified) should suffice.
I've found it necessary to use a statement expression to fix a few of
these -- and I would expect to need __typeof__ to fix some of the ones
I've left dangling for the moment.
> I certainly
>hope these macros aren't specified to allow arguments with side effects.
I seriously doubt the semantics of these macros are specified to that level