On Thu, Mar 06, 2014 at 08:12:13PM +0000, Dimitri John Ledkov wrote:
> > On Thu, Mar 6, 2014, at 2:23, Adam Conrad wrote:
> >> I wouldn't be entirely against this option, if the performance hit is
> >> measurably not awful in general purpose usage.
> > I'd rather approach the problem from the point of "we must have correct
> > code".
> 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.
> """
> As a programmer, my primary concern is that when I type "cc -o x x.c", I
> get correct output, as per the specification. That's not currently
> happening on Ubuntu.
> """
> whilst we do a lot with our toolchain to produce hardened and correct
> code, executing compiler without any flags is not going to guess the
> programmer's desires/expectations. Currently we still default to gnu89
> standard, whereas c11/c++11 is the default in the current Xcode
> (clang/llvm). On the other hand Visual Studio only conforms to c89 yet
> uses and supports c++11 features (selectively). Similarly, Intel
> compiler also applies floating point optimisations not allowed by the
> standards.
> Imho, the expectation upon executing "cc -o x x.c" is that resulting
> binary will work on any other ubuntu installation for the same
> architecture, with reasonable forward/backwards compatibility. If one
> is testing / coding against standards specifications one should set
> appropriate -std= flag for the target specification revision
> with/without GNU extensions.
> Floating point computation is not precise, unless special care is
> taken, but most things do not require nor assume standards compliance
> down to the very nitty gritty details.
> Neither dropping support for chipsets, or having slower operations
> sounds attractive nor so far justified.
Thanks, Dimitri, you took the words out of my mouth. The issue is not that
our compiler is not standards-compliant (because it is); the issue is (test
suite) code assuming behavior that's only specified in a standard other than
the one the compiler defaults to.
If you want the c99 standard behavior, specify -std=c99. There's no reason
that this issue should lead us to dropping support for any
currently-supported CPUs.
I have no opinion about the suggestion to change the -fexcess-precision
default, except to note that this isn't something we should be tampering
with post-feature freeze.
--
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
