* [Bug preprocessor/83256] inconsistent _Pragma behavior in multi-line macros
[not found] <bug-83256-4@http.gcc.gnu.org/bugzilla/>
@ 2022-10-04 22:35 ` lhyatt at gcc dot gnu.org
0 siblings, 0 replies; only message in thread
From: lhyatt at gcc dot gnu.org @ 2022-10-04 22:35 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83256
Lewis Hyatt <lhyatt at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |FIXED
CC| |lhyatt at gcc dot gnu.org
--- Comment #5 from Lewis Hyatt <lhyatt at gcc dot gnu.org> ---
For the testcases in comment 2 and comment 4, the problem was the loss of macro
tracking information for the _Pragma token, and r9-1926 (for PR69558) fixed
that, resolving a large class of diagnostic _Pragma location problems including
these.
For the current PR's original testcase (attachment 42777), there are two
separate issues combined together:
-For -Wuninitialized, this was caused for both C and C++ by -Wuninitialized
using the spelling location rather than the macro expansion location. It has
been fixed recently (r13-2994) for GCC 13. That fix has so far not been
backported but it would backport fine if someone wants it.
-For -Wattribute-alias, this one is applicable only to C, since C++ issues
a hard error for this testcase rather than a warning. Note, to avoid potential
confusion, the testcase as posted does not fail, it is needed to remove the
"struct s;" line to exhibit the problem. This was fixed by r13-1596 (for
PR97498) and was the same issue. (That was the fact that in C, input_location
was often pointing to the start of the line.) This is backported to 10,11,12
branches already.
It seems to me that the testcases added for the above three cases cover
everything in this PR, so I am resolving it now.
^ permalink raw reply [flat|nested] only message in thread