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 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 without understanding all the issues especially when that code (for ast mostly vmalloc) is at the heart of the rest of the sw being aware of such problems, however, is important for the future of the sw so keep them coming On Wed, 29 Feb 2012 23:33:24 +0100 Cedric Blancher wrote: > On 29 February 2012 08:49, Michal Hlavinka <[email protected]> wrote: > > On 02/28/2012 08:32 PM, ÏÌØÇÁ ËÒÙÖÁÎÏ×ÓËÁÑ wrote: > >> > >> Michal, why are you comiling with -fno-strict-aliasing? Any problems > >> with C aliasing should IMO be reported as bugs and fixed quickly, > >> because it causes trouble with other platforms and portabilty. > > > > > > Why? Because of this: > > > > warning: dereferencing type-punned pointer will break strict-aliasing rules > > > > If some optimization can't be used, it should be turned off. > This is not an issue with optimisation which is open for debate. This > issue is about strict aliasing rules which are part of the ANSI/ISO C > specification (older versions of the ANSI/ISO standard and K&R left > the issue open for interpretation but since ANSI/ISO C99 there are > clear and strict rules to end the chaos) and the violation of those > rules result in undefined behaviour. It may work with one compiler and > break with others. Likely more going to break with modern compilers > like icc, Sun Studio or gcc with O3/LTO enabled. > > Why do you think it's a bug? > > """ > > -fstrict-aliasing > > Allow the compiler to assume the strictest aliasing rules > > applicable to the language being compiled. For C (and C++), this ctivates > > optimizations based on the type of expressions. > > """ > > > > The code is still valid and works as expected. Only some type of > > optimization can't be used. Maybe it's an annoyance, but I won't call it a > > bug. > I'd call it poor workmanship of the person who composed the rpm > package. Instead of fixing the one or two warnings the whole package > (~210000 lines of code vs two lines of code which trigger the > warning!) is castrated down to low performance with > -fno-strict-aliasing. > Ced > -- > Cedric Blancher <[email protected]> > Institute Pasteur > _______________________________________________ > ast-developers mailing list > [email protected] > https://mailman.research.att.com/mailman/listinfo/ast-developers _______________________________________________ ast-developers mailing list [email protected] https://mailman.research.att.com/mailman/listinfo/ast-developers
