http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52998
Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |diagnostic
Priority|P3 |P4
CC| |dodji at gcc dot gnu.org
Version|unknown |4.8.0
--- Comment #1 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2012-04-15
20:35:08 UTC ---
I think with and without macro expansion, the error should be given at 13:3,
and unwind from outermost to innermost. Innermost to outermost makes sense if
we show preprocessed lines:
macro-caret.c:5:14: error: invalid operands to binary << (have ‘double’ and
‘int’)
1.0 << 1
^
macro-caret.c:2:9: note: in expansion of macro 'OPERATE' [with OPRD1=0.1,
OPRT=<<, OPRD2=1]
OPRD1 OPRT OPRD2;
^
macro-caret.c:5:3: note: expanded from here
OPERATE (1.0,<<,1)
^
macro-caret.c:5:14: note: in expansion of macro 'SHIFTL' [with A=1.0, B=1]
OPERATE (A,<<,B)
^
macro-caret.c:8:3: note: expanded from here
SHIFTL (1.0,1)
^
macro-caret.c:8:3: note: in expansion of macro 'MULT' [with A=1.0]
SHIFTL (A,1)
^
macro-caret.c:13:3: note: expanded from here
MULT (1.0);// 1.0 << 1; <-- so this is an error.
Otherwise, the error is shown at some code the user has not typed, and that
shows no obvious error (OPERATE (A,<<,B)) . Hence, the user has to read the
output once to find the source of the error (MULT), and then again to unwind
the macro expansion. In that case, it is better to go outermost to innermost,
so the user can follow the macro expansion as it occurs.
What do you think Dodji?
