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/ [email protected] [email protected]
signature.asc
Description: Digital signature
-- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
