<div dir="ltr">On Fri, Aug 16, 2013 at 2:22 PM, Eli Friedman <span dir="ltr"><<a href="mailto:eli.friedman@gmail.com" target="_blank">eli.friedman@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="im">On Fri, Aug 16, 2013 at 2:39 AM, Peter N Lewis <span dir="ltr"><<a href="mailto:peter@stairways.com.au" target="_blank">peter@stairways.com.au</a>></span> wrote:<br>
</div><div class="gmail_extra"><div class="gmail_quote"><div class="im">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">This patch supersedes my previous patch and defines explicit flags for each of the eight remaining generic -gnu features.<br>


<br>
Flags are:<br>
<br>
        -gnu-alignof-expression<br>
        -gnu-case-range<br>
        -gnu-complex-integer<br>
        -gnu-conditional-omitted-operand<br>
        -gnu-empty-initializer<br>
        -gnu-label-as-value<br>
        -gnu-local-label<br>
        -gnu-statement-expression<br>
<br>
I would have preferred to do each as an independent patch, but because they all touch the "def GNU : DiagGroup" line they would conflict which each other unless applied in exactly the right order. They are all related in any event, simply adding explicit control over the features covered by -gnu.<br>


<br>
For conditional-omitted-operand, I changed the error message slightly, from:<br>
<br>
        use of GNU ?: expression extension, eliding middle term<br>
<br>
to<br>
<br>
        use of GNU ?: conditional expression extension, omitting middle operand<br>
<br>
to better match the GCC documentation of the feature and hence the flag name.<br>
<br>
gnu-label-as-value covers both errors "use of GNU address-of-label extension" and "use of GNU indirect-goto extension" as it would seem to me that one is useless without the other, so they are functionally the same feature.<br>


<br>
There does not seem to be any way to get the "use of GNU empty initializer extension" warning without also getting some other warning (such as "zero size arrays are an extension").<br>
<br>
There are test cases for each of the flags.<br>
<br>
I'd like to move on to some other similar patches now, so hopefully I can get either approval of this patch or some feedback or something.<br><br></blockquote><div><br></div></div><div>diag::ext_gnu_local_label shouldn't exist; it's not something we need to diagnose.</div>

<div><br></div><div>You can trigger <span style="font-family:arial,sans-serif;font-size:13px">ext_gnu_empty_initializer with "struct { int x; } x = {};"</span></div><div><br></div><div>It would be nice if you could avoid adding thirty invocations of clang to the regression tests; we rely on them to run quickly.</div>
</div></div></div></blockquote><div><br></div><div>Perhaps fold all the tests into one file, add a -D for each warning flag, then do</div><div><br></div><div>// RUN: %clang_cc1 -verify %s</div><div>// RUN: %clang_cc1 -verify %s -Wgnu-alignof-expression -DALIGNOF</div>
<div>// RUN: %clang_cc1 -verify %s -Wgnu-case-range -DCASE_RANGE</div><div>// ... </div><div>// RUN: %clang_cc1 -verify %s -Wgnu -DALIGNOF -DCASE_RANGE -DCOMPLEX_INTEGER ...<br></div><div><br></div><div>... though even this is more thorough testing than we'd usually have for warning flags.</div>
</div></div></div>