This is the mail archive of the
gcc-cvs@gcc.gnu.org
mailing list for the GCC project.
r187845 - in /trunk/gcc: ChangeLog testsuite/Ch...
- From: dodji at gcc dot gnu dot org
- To: gcc-cvs at gcc dot gnu dot org
- Date: Thu, 24 May 2012 19:37:46 -0000
- Subject: r187845 - in /trunk/gcc: ChangeLog testsuite/Ch...
Author: dodji
Date: Thu May 24 19:37:45 2012
New Revision: 187845
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187845
Log:
Make unwound macro expansion trace less redundant
As discussed previously, the unwinder for macro expansion is quite
verbose [1]. This patch proposes to address that shortcoming.
Consider this test case:
$ cat -n test.c
1 #define MYMAX(A,B) __extension__ ({ __typeof__(A) __a = (A); \
2 __typeof__(B) __b = (B); __a < __b ? __b : __a; })
3
4 struct mystruct {};
5 void
6 foo()
7 {
8 struct mystruct p;
9 float f = 0.0;
10 MYMAX (p, f);
11 }
$
The output of the compiler from trunk yields:
$ cc1 -quiet ./test.c
./test.c: In function âfooâ:
./test.c:2:31: error: invalid operands to binary < (have âstruct mystructâ and âfloatâ)
__typeof__(B) __b = (B); __a < __b ? __b : __a; })
^
./test.c:2:31: note: in expansion of macro 'MYMAX'
__typeof__(B) __b = (B); __a < __b ? __b : __a; })
^
./test.c:10:3: note: expanded from here
MYMAX (p, f);
^
$
After this patch, the compiler yields:
$ ./cc1 -quiet ./test.c
./test.c: In function âfooâ:
./test.c:2:31: error: invalid operands to binary < (have âstruct mystructâ and âfloatâ)
__typeof__(B) __b = (B); __a < __b ? __b : __a; })
^
./test.c:10:3: note: in expansion of macro 'MYMAX'
MYMAX (p, f);
^
$
The gotcha is, in the general case, we cannot simply eliminate the
context of the macro definition. That is, the line from the first
output that is redundant with the first diagnostic line that has
line/column number:
./test.c:2:31: note: in expansion of macro 'MYMAX'
__typeof__(B) __b = (B); __a < __b ? __b : __a; })
^
We cannot simply eliminate that context of macro definition because
there are cases where the first diagnostic that has a line/column
number doesn't point to a location inside the definition of the macro
where the relevant token is used. For instance:
$ cat -n test2.c
1 #define OPERATE(OPRD1, OPRT, OPRD2) \
2 OPRD1 OPRT OPRD2;
3
4 #define SHIFTL(A,B) \
5 OPERATE (A,<<,B)
6
7 #define MULT(A) \
8 SHIFTL (A,1)
9
10 void
11 g ()
12 {
13 MULT (1.0);// 1.0 << 1; <-- so this is an error.
14 }
$
Which yields without the patch:
$ cc1 -quiet ./test2.c
./test2.c: In function âgâ:
./test2.c:5:14: error: invalid operands to binary << (have âdoubleâ and âintâ)
OPERATE (A,<<,B)
^
./test2.c:2:9: note: in expansion of macro 'OPERATE'
OPRD1 OPRT OPRD2;
^
./test2.c:5:3: note: expanded from here
OPERATE (A,<<,B)
^
./test2.c:5:14: note: in expansion of macro 'SHIFTL'
OPERATE (A,<<,B)
^
./test2.c:8:3: note: expanded from here
SHIFTL (A,1)
^
./test2.c:8:3: note: in expansion of macro 'MULT'
SHIFTL (A,1)
^
./test2.c:13:3: note: expanded from here
MULT (1.0);// 1.0 << 1; <-- so this is an error.
^
$
Here, the line that has the context of macro definition:
./test2.c:2:9: note: in expansion of macro 'OPERATE'
OPRD1 OPRT OPRD2;
^
is useful, because the first diagnostic that has line/column number
wasn't pointing into the definition of the macro OPERATE, where the
token '<<' is used.
./test2.c:5:14: error: invalid operands to binary << (have âdoubleâ and âintâ)
OPERATE (A,<<,B)
^
So in this this case, displaying the macro definition context is not
redundant. I think it is even desirable.
The patch changes the output in that case to be:
./test2.c: In function âgâ:
./test2.c:5:14: erreur: invalid operands to binary << (have âdoubleâ and âintâ)
OPERATE (A,<<,B)
^
./test2.c:2:9: note: in definition of macro 'OPERATE'
OPRD1 OPRT OPRD2;
^
./test2.c:8:3: note: in expansion of macro 'SHIFTL'
SHIFTL (A,1)
^
./test2.c:13:3: note: in expansion of macro 'MULT'
MULT (1.0);// 1.0 << 1; <-- so this is an error.
^
$
It's shorter, but I believe it has all the information that was
present before the patch.
[1]: http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00321.html
Bootstrapped and tested on x86_64-unknown-linux-gnu against trunk.
gcc/
Make unwound macro expansion trace less redundant
* tree-diagnostic.c (maybe_unwind_expanded_macro_loc): Don't print
context of macro definition in the trace, when it's redundant.
Update comments.
gcc/testsuite/
Make unwound macro expansion trace less redundant
* gcc.dg/cpp/macro-exp-tracking-1.c: Adjust.
* gcc.dg/cpp/macro-exp-tracking-2.c: Likewise.
* gcc.dg/cpp/macro-exp-tracking-3.c: Likewise.
* gcc.dg/cpp/macro-exp-tracking-4.c: Likewise.
* gcc.dg/cpp/macro-exp-tracking-5.c: Likewise.
* gcc.dg/cpp/pragma-diagnostic-2.c: Likewise.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/warn/Wconversion-real-integer2.C
trunk/gcc/testsuite/g++.dg/warn/Wdouble-promotion.C
trunk/gcc/testsuite/gcc.dg/cpp/macro-exp-tracking-1.c
trunk/gcc/testsuite/gcc.dg/cpp/macro-exp-tracking-2.c
trunk/gcc/testsuite/gcc.dg/cpp/macro-exp-tracking-3.c
trunk/gcc/testsuite/gcc.dg/cpp/macro-exp-tracking-4.c
trunk/gcc/testsuite/gcc.dg/cpp/macro-exp-tracking-5.c
trunk/gcc/testsuite/gcc.dg/cpp/pragma-diagnostic-2.c
trunk/gcc/tree-diagnostic.c