Re: [tree-ssa] Merge status

[law at redhat dot com]

In message <Pine.LNX.4.58.0403171047390.7682@digraph.polyomino.org.uk>, "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
 >portable.
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
code.

 >(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"
warning.


 >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
 >other headers. 
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
of detail.


jeff