------- Comment #31 from dodji at gcc dot gnu dot org 2010-06-14 14:13 ------- Subject: Re: __extension__ keyword doesn't suppress warning on LL or ULL constants
"manu at gcc dot gnu dot org" <gcc-bugzi...@gcc.gnu.org> writes: >> Next stop is to disable this feature by default, and enable it with a >> -ftrack-macro-expansion flag, and update the regressions tests of the C FE. > > Great but... you should just prune the output in the general case (extending > prune.exp) and only bother to handle the extra output in cases where it makes > sense to specifically test it. This is what we do for the "inlined from" > messages and it makes sense to do the same for this kind of message. Indeed. Thanks for the reference to prune.exp. Though, one of the reasons why I want to be able to disable the feature and fall back to the previous behaviour is the memory consumption and speed penalty that *could* arise from the patch. This bug report http://llvm.org/bugs/show_bug.cgi?id=5610 gives an idea of what I am talking about. I agree that I need to make the C++ FE work with the patch before really worrying about this, but I felt I could do the work right now and be done with it. As for prune.exp, I think I will eventually prune at least some parts of the output when time comes. > > I see now the sense in the column numbers, I think it is the order that > confused me (and not seeing the code clearly). I would prefer a different > output like: > > test.c:13:3: in expansion of macro MULT2 > test.c:5:14: in expansion of macro SHIFTL > test.c:8:3: in expansion of macro OPERATE > test.c:2:8: error: invalid operands to binary << (have 'double' and > 'int') Ah, okay. Thanks for the comment I'll consider doing this when polishing the error messages. > > But this is bike-shedding at this stage and it is more important to get the > internals working. > Nah. Quite the contrary. I think this is a valuable comment. > BTW, do we also keep the information about the macro arguments? If so, after > your patch goes in we could even go as far as to print macro arguments: > > test.c:13:3: in expansion of macro MULT2 [with A=1.0] > test.c:5:14: in expansion of macro SHIFTL [with A=1.0, B=1] > test.c:8:3: in expansion of macro OPERATE [with OPRD1=1.0, OPTR=<<, OPTRD2=1] > test.c:2:8: error: invalid operands to binary << (have 'double' and 'int') > Not yet. We only keep track of the location of the token accross macro expansion. We don't keep track of the the kind of information you are talking about. But I guess this is something we could do. My TODO list is growing :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7263
