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.
