<div dir="ltr">On Tue, Feb 23, 2016 at 6:42 PM, Richard Smith <span dir="ltr"><<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Fri, Feb 19, 2016 at 4:33 PM, Saleem Abdulrasool via cfe-dev<br>
<<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br>
> On Fri, Feb 19, 2016 at 1:17 PM, Martin J. O'Riordan via cfe-dev<br>
> <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br>
>><br>
>> I have the same kind of dilemma - I really like having a "strictly<br>
>> conforming" option because I love Standards, but realistically I need them<br>
>> to be supplemented by a relaxed mode that permits extensions.<br>
>><br>
>> What I think would be the right thing for Clang, would be for '-std=XXX'<br>
>> to enforce the ISO definition of XXX, but to be able to supplement it with<br>
>> an additional option or options that enabled the extensions or relaxed the<br>
>> ISO rules (warnings of divergence are still good).  Normally when I use<br>
>> '-std=XXX', I also find I have to use at least ' -U__STRICT_ANSI__' because<br>
>> the extended or non-Standard behaviour is what I often want; and sometimes<br>
>> other additional options.  But having '-std=XXX' mean exactly the ISO<br>
>> definition is really useful, and cool.<br>
>><br>
>> Ironically, having '-std=XXX' be really strict about ISO compliance is<br>
>> almost certainly the wrong thing for my code; for example it means enabling<br>
>> exceptions which are simply too expensive for embedded; but I would still<br>
>> like to tell the compiler to enforce strict ISO conformance rules - unless I<br>
>> have supplemented it with options to relax particular constraints.<br>
>> Sometimes we use '-std=XXX' to select a dialect (e.g. C++11 versus C++14),<br>
>> but then have to supplement it by a bunch of other options that tune it to<br>
>> our actual non-Standard needs.  But I still need warnings and error<br>
>> messages, they tell me where I need to be very specific about what and why I<br>
>> am doing something that strays outside the ISO interpretation.<br>
>><br>
>> An alternative would to be to add something like '-fstrict-iso' to make<br>
>> '-std=XXX' be strict, but my own feeling is that strict should be the<br>
>> default, and relaxed should be the deliberately selected alternative.<br>
><br>
><br>
> It seems that there is some interest in keeping the default be standards<br>
> conforming.  It would be nice to get a consensus on this issue so that we<br>
> can move forward.<br>
<br>
</div></div>I would be very happy with us adding -fgnu-compatibility, and making<br>
-std=gnuX be a synonym for -std=cX -fgnu-compatibility. This would<br>
just cover the non-conforming GNU extensions (in particular, the GNU<br>
keywords), in the same way that -fms-compatibility covers only the<br>
non-conforming MS behavior.<br></blockquote><div><br></div><div>This sounds like a great idea to me.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
That would leave us with a collection of GNU extensions (and Clang<br>
extensions and Embarcadero extensions and probably others) that are<br>
enabled with no explicit opt-out flag (such as __attribute__, folding<br>
of non-constant array bounds). Some of the GNU extensions are at this<br>
point Clang extensions as well (we have our own __attribute__s that<br>
use GNU syntax), some of them are essential for the correct<br>
functioning of system headers or for the compilation of widespread<br>
code patterns, and some of them are things we could reasonably hide<br>
behind a "GNU extensions" flag (etc). Unpicking the differences seems<br>
like a significant challenge -- there's no point adding a flag for<br>
these things that causes (in practice) all non-trivial compilations to<br>
fail -- and we already have -pedantic-errors for cases where there is<br>
a desire for errors on code that uses such an extension (we may miss<br>
some extension diagnostics today; those are easy bugs to fix). I think<br>
what we need here is for someone to come up with a proposal for a good<br>
end state here.<br></blockquote><div><br></div><div>I think that another option is having an option that is enabled by default to enable these extensions to permit users to force a strict compilation mode.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
There's a separate question of what the default -std= value should be,<br>
for each language. Right now, we use -std=gnu11 for C and -std=gnu++98<br>
for C++, although we should aim to bump the latter to -std=gnu++14 for<br>
Clang 3.9. Changing these from -std=gnuX to -std=cX seems likely to<br>
break a fair amount of real code, so we should be cautious about that.</blockquote><div><br></div><div>Sure, but I don't think that the changes being discussed here really impact our choice of defaults outside of what the mapping of flags would be.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
>>         MartinO<br>
>><br>
>> -----Original Message-----<br>
>> From: cfe-dev [mailto:<a href="mailto:cfe-dev-bounces@lists.llvm.org">cfe-dev-bounces@lists.llvm.org</a>] On Behalf Of Joerg<br>
>> Sonnenberger via cfe-dev<br>
>> Sent: 19 February 2016 15:20<br>
>> To: <a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
>> Subject: Re: [cfe-dev] Enabling strong enum extensions under C<br>
>><br>
>> On Tue, Feb 16, 2016 at 09:46:27AM -0500, Nico Weber via cfe-dev wrote:<br>
>> > Personally, I'd like if -std=c11 would give you C11 without extensions.<br>
>><br>
>> Speaking with OS developer hat, it is not practical to disable all<br>
>> extensions like the protected versions of keywords or attributes.<br>
>><br>
>> Joerg<br>
>> _______________________________________________<br>
>> cfe-dev mailing list<br>
>> <a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
>> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
>><br>
>> _______________________________________________<br>
>> cfe-dev mailing list<br>
>> <a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
>> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
><br>
><br>
><br>
><br>
> --<br>
> Saleem Abdulrasool<br>
> compnerd (at) compnerd (dot) org<br>
><br>
> _______________________________________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Saleem Abdulrasool<br>compnerd (at) compnerd (dot) org</div>
</div></div>