[cfe-dev] RFC: switch default C language mode from gnu99 to gnu11

[Richard Smith]

On Thu, Oct 16, 2014 at 1:29 PM, Chandler Carruth <chandlerc at google.com>
wrote:

>
> On Thu, Oct 16, 2014 at 1:25 PM, Richard Smith <richard at metafoo.co.uk>
> wrote:
>
>> I suspect that: (a) the ones we want to run in all modes is "all tests,
>> unless otherwise specified",
>>
>
> I'm not sure why. CodeGen certainly doesn't seem very interesting here?
>

Why not? If we start generating wrong code in C++11 mode (due to a subtle
change in AST representation in that mode), I want our tests for $feature
to catch that. I can't think of *any* tests that should not run in all
modes, other than those which are testing the behavior of a particular mode.

and (b) it is too expensive to do so by default (it would increase our
>> testing time by probably around 4x).
>>
>
> I'm not sure it would.
>

This is obviously predicated on (a).

I think the biggest risk for failure-on-bots-but-not-locally would be when
>> developers add new tests that accidentally rely on a particular language
>> standard. To that end, we could possibly run C tests in C89 and C++ tests
>> in C++98, independent of the driver's default mode, if we're not in "run in
>> all modes" mode. I'm open to suggestions.
>>
>
> I just don't think this is a good way to get coverage. Either getting
> coverage is important, in which case we should figure out which tests to
> run in multiple modes, or it isn't and we shouldn't bother with it. Having
> the build bots use magic configurations to waste time exhaustively
> searching for compile modes which don't work seems like a bad approach. =/
>

Having to explicitly write RUN: lines for all languages for all tests seems
like a bad approach too. I'm claiming that (1) getting coverage is probably
important, and (2) figuring out which tests to run will probably result in
"all tests that don't specify otherwise".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20141016/b664f1eb/attachment.html>