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