[cfe-commits] [PATCH][driver] Frontend parsing of warnings and compliance with gcc

[Jeremy Huddleston]

That looks about right to me, and it's doing the right thing for me ...

Tested-by: Jeremy Huddleston <jeremyhu at apple.com>
Reviewed-by: Jeremy Huddleston <jeremyhu at apple.com>

On Jan 31, 2012, at 2:49 PM, Chad Rosier wrote:

> The clang frontend currently parses warning options in the canonical "last option wins" paradigm.  This leads to what odd behavior IMO and non-compliance to how gcc handles things.
> 
> For example,
> 
> mcrosier$ cat t.c
> int main() { return implicit(); }
> 
> mcrosier$ clang -Werror=implicit -Wall -c t.c -o /dev/null
> t.c:1:21: warning: implicit declaration of function 'implicit' is invalid in C99 [-Wimplicit-function-declaration]
> int main() { return implicit(); }
>                    ^
> 1 warning generated.
> 
> Reversing the order of the warning options results in an error:
> mcrosier$ clang -Wall -Werror=implicit -c t.c -o /dev/null
> t.c:1:21: error: implicit declaration of function 'implicit' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
> int main() { return implicit(); }
>                    ^
> 1 error generated.
> 
> AFAIK gcc always emits an error.
> 
> If I understand the gcc standard correctly (and admittedly I'm no expert), I believe a -W option should never downgrade something that has already been marked as an error/fatal warning.
> 
> The attached patch does precisely this.  The other practical effect is that if you would like to change a warning that is an error by default to just a warning you need to use the -Wno-error=foo option rather then -Wfoo.
> 
> Chad
> 
> <fe_warnings.diff>_______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits