On Thu, Mar 06, 2014 at 04:06:31PM -0500, Ryan Lortie wrote:
> On Thu, Mar 6, 2014, at 15:12, Dimitri John Ledkov wrote:
> > I don't think that's the right approach here. We do have correct code
> > in our packages, and where needed packages do raise standards version
> > / target cpu features etc. to generate performant / correct or
> > optimized code.
> It seems like you are advising that the correct solution here is to
> apply CFLAGS on a package-by-package basis, as they are needed. ie: if
> a package relies on the C compiler producing correct code then we should
> have CFLAGS=-mexcess-precision=standard in the CFLAGS for this package?
This is a prejudicial framing of the question. :) The compiler is not
producing code that is incorrect, it's producing code that is inconsistent
with the particular standard that glib upstream is expecting. If glib
requires a C99 compiler, then glib should specify (via autoconf) that, when
using gcc, it wants -std=c99.
> > Neither dropping support for chipsets, or having slower operations
> > sounds attractive nor so far justified.
> The justification is that it wasted several hours of my time (and the
> time of other desktop team members due to failed package uploads)
> tracking this issue down. The 50+ duplicates of this bug filed against
> GCC suggest that we're not the only ones...
> Regardless of your beliefs about if or if not the C99 spec is correct in
> specifying this behaviour, you must surely agree that gcc is in
> violation of the spec. You could argue (as I believe you have) that gcc
> has no obligation to follow the spec. I believe that the wording in the
> C99 spec was chosen for a reason, and a very good one: not to follow
> this rule produces extremely bizarre and difficult to debug
> non-deterministic behaviour.
It makes no sense to appeal to the C99 standard as a justification for
changing the default behavior of the compiler, when a) there are lots of
other ways in which gcc's default behavior does not conform to C99, b) if
you really want C99 conformance, you should be using -std=c99, and not
working around this one *particular* incompatibility with either
-mfpmath=sse or -fexcess-precision=standard.
It's interesting to ask whether we *should* use -std=c99 by default. But
that's a rather large change, and not something we would do this late in the
cycle and not without rebuild tests beforehand.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
