On 12/2/2022 1:01 AM, Joseph Myers wrote:
> On Thu, 1 Dec 2022, Longjun Luo via Gcc-patches wrote:
>
>> diff --git a/gcc/testsuite/gcc.dg/builtin-redefine.c b/gcc/testsuite/gcc.dg/builtin-redefine.c
>> index 882b2210992..9d5b42252ee 100644
>> --- a/gcc/testsuite/gcc.dg/builtin-redefine.c
>> +++ b/gcc/testsuite/gcc.dg/builtin-redefine.c
>> @@ -71,7 +71,6 @@
>>   /* { dg-bogus "Expected built-in is not defined" "" { target *-*-* } .-1 } */
>>   #endif
>>   
>> -#define __LINE__ 0           /* { dg-warning "-:\"__LINE__\" redef" } */
>>   #define __INCLUDE_LEVEL__ 0  /* { dg-warning "-:\"__INCLUDE_LEVEL__\" redef" } */
>>   #define __COUNTER__ 0        /* { dg-warning "-:\"__COUNTER__\" redef" } */
> Is there some existing test that verifies that this redefinition is still
> diagnosed by default (in the absence of -Wno-builtin-macro-redefined)?

I am not sure I have fully understood your meaning. The problem here is 
that if I try to redefine __LINE__ macro in the situation that projects 
use the option '-Werror', the compile will fail.

For example, the following compilation will fail:

/echo "void main(){}" | gcc -D__LINE__=0 -Werror -x c -/


The compilation output is:

<command-line>: error: "__LINE__" redefined [-Werror]
cc1: all warnings being treated as errors


As I know, most projects including Linux kernel enable '-Werror' by 
default. So if I try to redefine __LINE__ macro in this situation, it 
will be impossible.

The reason that I want to redefine __LINE__ macro has been explained in 
the commit.

Thanks for your patience and hope I hit the point.