On Thu, 1 Mar 2012 00:18:06 +0100 Cedric Blancher wrote:
> On 29 February 2012 23:58, Glenn Fowler <[email protected]> wrote:
> >
> > you have to cut package maintainers some slack
> > I can point to at least a dozen places in the ast Makefiles
> > that contain workarounds that disable optimization for specific source
> > files and compilers
> Do you have a list of such locations and entries in a bug database to
> track them?
from $PACKAGEROOT (the dir containing bin/package)
tw -P -d src/cmd -d src/lib -e "name=='Makefile'" grep :NOOPTIMIZE:
some of these may no longer be needed
> > there may be similar issues for other -f* style options as they themselves
> > get exercised
> >
> > we are not going to change working code for (currently) non-default options
> Our trouble is that ANSI/ISO C99 mandates strict aliasing rules. They
> are enabled by default, e.g. gcc 4.x defaults to -fstrict-aliasing.
> The warning which reports strict aliasing issues [-Wstrict-aliasing]
> is not enabled by default but your code is still silently compiled
> with strict aliasing rules.
if the compiler were to act on the strict-aliasing violation
(to actually generate code relying on strict-aliasing)
the it seems it should warn about that
> > without understanding all the issues
> > especially when that code (for ast mostly vmalloc) is at the heart of the
> > rest of the sw
> I understand. But right now, with AST compiled as C99 or C2011 code,
> the vmalloc code breaks because of the strict aliasing rules being
> enforced by *default*. No extra compiler options required to cause the
> breakage.
now we get to the crux
this thread started off with ast being compiled with non-default strict-aliasing
given that strict-aliasing is finally becoming a default
it will be at the top of the todo list
but after the next official release (due this week)
so the latest glibc malloc.c compiles gcc 4.7.0 strict-alias clean?
there's punning wrapped in macros all over the place
(e.g., taking the free() pointer and punning it into the free list)
I guess they are carefully sequestered on either side of (char*)
thanks
_______________________________________________
ast-developers mailing list
[email protected]
https://mailman.research.att.com/mailman/listinfo/ast-developers
