[Bug preprocessor/69126] [6 regression] _Pragma does not apply if part of a macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69126 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #30 from David Malcolm --- The issue reported in comment #18 should be fixed as of r233638; marking this one as resolved again.
[Bug preprocessor/69126] [6 regression] _Pragma does not apply if part of a macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69126 --- Comment #29 from David Malcolm --- Author: dmalcolm Date: Tue Feb 23 17:44:28 2016 New Revision: 233638 URL: https://gcc.gnu.org/viewcvs?rev=233638=gcc=rev Log: PR preprocessor/69126: avoid comparing ad-hoc and non-ad-hoc locations gcc/testsuite/ChangeLog: PR preprocessor/69126 PR preprocessor/69543 * c-c++-common/pr69126-2-long.c: New test. * c-c++-common/pr69126-2-short.c: New test. * c-c++-common/pr69543-1.c: Remove xfail. libcpp/ChangeLog: PR preprocessor/69126 PR preprocessor/69543 * line-map.c (linemap_compare_locations): At the function top, replace inlined bodies of get_location_from_adhoc_loc with calls to get_location_from_adhoc_loc. Add a pair of calls to get_location_from_adhoc_loc at the bottom of the function, to avoid meaningless comparisons of ad-hoc and non-ad-hoc locations. Added: trunk/gcc/testsuite/c-c++-common/pr69126-2-long.c trunk/gcc/testsuite/c-c++-common/pr69126-2-short.c Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/pr69543-1.c trunk/libcpp/ChangeLog trunk/libcpp/line-map.c
[Bug preprocessor/69126] [6 regression] _Pragma does not apply if part of a macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69126 --- Comment #28 from David Malcolm --- Author: dmalcolm Date: Tue Feb 23 17:39:16 2016 New Revision: 233637 URL: https://gcc.gnu.org/viewcvs?rev=233637=gcc=rev Log: Add test coverage for _Pragma (PR preprocessor 69126, 69543, 69558) We had some regressions in the ability for _Pragma to disable a warning (PR preprocessor/69126, PR preprocessor/69543, PR preprocessor/69558). This patch attempts to add more test coverage for this, for the various combinations of: - various warnings: -Wunused-variable -Wuninitialized -Wdeprecated-declarations - various combinations of location of _Pragma relative to location of the warning: - _Pragma is in a macro, warning isn't a macro - neither is in a macro - _Pragma isnt't in a macro, warning is in a macro - in different macros - both in the same macro - C vs C++ frontend. It adds some XFAILs: - pr69543-1.c for C++ (fixed in the followup patch) - pr69543-3.c for both C and C++ - pr69543-4.c for both C and C++ - pr69558.c for C++ (moving it from gcc.dg to c-c++-common, marking it as xfail for C++ for now) gcc/testsuite/ChangeLog: PR preprocessor/69126 PR preprocessor/69543 PR preprocessor/69558 * c-c++-common/pr69126.c (MACRO_1, test_1): New. (f): Rename to... (test_2): ...this, and add leading comment. (MACRO_3, test_3): New. (MACRO_4A, MACRO_4B, test_4): New. (MACRO): Rename to... (MACRO_5): ...this. (g): Rename to... (test_5): ...this, updating for renaming of MACRO, and add leading comment. * c-c++-common/pr69543-1.c: New. * c-c++-common/pr69543-2.c: New. * c-c++-common/pr69543-3.c: New. * c-c++-common/pr69543-4.c: New. * c-c++-common/pr69558-1.c: New. * c-c++-common/pr69558-2.c: New. * c-c++-common/pr69558-3.c: New. * c-c++-common/pr69558-4.c: New. * gcc.dg/pr69558.c: Move to... * c-c++-common/pr69558.c: ...here. Add dg-bogus directives, with xfail for c++. Added: trunk/gcc/testsuite/c-c++-common/pr69543-1.c trunk/gcc/testsuite/c-c++-common/pr69543-2.c trunk/gcc/testsuite/c-c++-common/pr69543-3.c trunk/gcc/testsuite/c-c++-common/pr69543-4.c trunk/gcc/testsuite/c-c++-common/pr69558-1.c trunk/gcc/testsuite/c-c++-common/pr69558-2.c trunk/gcc/testsuite/c-c++-common/pr69558-3.c trunk/gcc/testsuite/c-c++-common/pr69558-4.c trunk/gcc/testsuite/c-c++-common/pr69558.c - copied, changed from r233636, trunk/gcc/testsuite/gcc.dg/pr69558.c Removed: trunk/gcc/testsuite/gcc.dg/pr69558.c Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/pr69126.c
[Bug preprocessor/69126] [6 regression] _Pragma does not apply if part of a macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69126 Paolo Carlini changed: What|Removed |Added CC||paolo.carlini at oracle dot com --- Comment #27 from Paolo Carlini --- Many thanks once more, David!
[Bug preprocessor/69126] [6 regression] _Pragma does not apply if part of a macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69126 --- Comment #26 from David Malcolm --- (In reply to David Malcolm from comment #25) [...] > I have a patch that seems to work for this test case; am testing it more > thoroughly now. Candidate patch posted here: https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01424.html (see also: https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01425.html )
[Bug preprocessor/69126] [6 regression] _Pragma does not apply if part of a macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69126
David Malcolm changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #25 from David Malcolm ---
Stephan provided me with a tarball of his reproducer (thanks!), and I'm able to
reproduce this locally.
The root cause is a bug in linemap_compare_locations.
(gdb) call inform (pre, "pre")
test.cc:8:16: note: pre
#define IGNORE _Pragma("GCC diagnostic ignored \"-Wdeprecated-declarations\"")
^
test.cc:8:16: note: in definition of macro ‘IGNORE’
#define IGNORE _Pragma("GCC diagnostic ignored \"-Wdeprecated-declarations\"")
^~~
(gdb) call inform (post, "post")
test.cc:12:5: note: post
f();
^
After macro expansion, we have (at the end of linemap_compare_locations):
(gdb) p /x l0
$13 = 0x800101ec
(gdb) p /x l1
$14 = 0x50684c05
and hence:
(gdb) p /x l1 - l0
$23 = 0xd0674a19
it's effectively negative, and so before_p is false.
But this is wrong: l0 is an ad-hoc loc, whereas l1 is a non-ad-hoc loc.
It's clearly insane to treat all ad-hoc locations as being later than all
non-ad-hoc locations. The fix is simple: resolve ads-hoc locations at the end
of linemap_compare_locations.
For this bug to occur, we need a location for the macro name that's an ad-hoc
location, and a location for the diagnostic that's *not* an ad-hoc location.
The reason it triggered for Stephan is that the sheer quantity of code in his
reproducer meant that both locations in question were above
LINE_MAP_MAX_LOCATION_WITH_PACKED_RANGES (but below
LINE_MAP_MAX_LOCATION_WITH_COLS), so range-packing was disabled, in particular
for the "IGNORE" macro.
I can reproduce it trivially by using a macro name that's >=32 characters (thus
forcing the use of an ad-hoc location):
/* { dg-options "-Wdeprecated-declarations" } */
#define IGNORE_WHERE_MACRO_IS_LONGER_THAN_31_CHARS _Pragma("GCC diagnostic
ignored \"-Wdeprecated-declarations\"")
__attribute__((deprecated)) void f();
int main() {
IGNORE_WHERE_MACRO_IS_LONGER_THAN_31_CHARS
f();
}
I have a patch that seems to work for this test case; am testing it more
thoroughly now.
[Bug preprocessor/69126] [6 regression] _Pragma does not apply if part of a macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69126 --- Comment #24 from Stephan Bergmann --- (In reply to Manuel López-Ibáñez from comment #23) > That is weird. If you use "GCC diagnostic warning" instead of "ignored", you > should be able to see some changes in locations between -O0 and -O1 and > before/after the bug appeared, don't you? No. The reported locations remain unaffected (errors/warnings at test.cc:12:5 and test.cc:12:7, notes at test.cc:9:34). Just that (after replacing "ignored" with "warning") they get reported as errors with -O1 and r232893 included, and as warnings otherwise (i.e., either with -O0 and r232893 included, or with either -O0/1 and r232893 reverted).
[Bug preprocessor/69126] [6 regression] _Pragma does not apply if part of a macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69126 --- Comment #22 from Stephan Bergmann --- (In reply to Jakub Jelinek from comment #20) > Does the http://gcc.gnu.org/ml/gcc-patches/2016-01/msg02347.html workaround > help here in any way? No, unfortunately not. Doesn't change the behaviour in any way.
[Bug preprocessor/69126] [6 regression] _Pragma does not apply if part of a macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69126 --- Comment #23 from Manuel López-Ibáñez --- (In reply to Stephan Bergmann from comment #18) > (Also, the problem > only happens with -O or higher.) That is weird. If you use "GCC diagnostic warning" instead of "ignored", you should be able to see some changes in locations between -O0 and -O1 and before/after the bug appeared, don't you?
[Bug preprocessor/69126] [6 regression] _Pragma does not apply if part of a macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69126
Stephan Bergmann changed:
What|Removed |Added
CC||sbergman at redhat dot com
--- Comment #18 from Stephan Bergmann ---
A GCC trunk build past r232893 started causing building LibreOffice to fail now
for me, with a _Pragma("GCC diagnostic ignored \"-Wdeprecated-declarations\"")
coming from a macro expansion being ignored, thus causing a
-Werror=deprecated-declarations.
I cannot easily reduce the test case further than what I have below. I tried
to expand the remaining includes inline in the main source file, but then ran
into strange effects where e.g. removing an arbitrary single line from the
middle of a multi-line /*...*/ comment made the problem go away, while
replacing the line with an empty line made the problem stay. The first
#include is for a file coming from LO's own bundled Boost, the remaining
#includes are from the (F22, x86_64) system. (Also, the problem only happens
with -O or higher.)
> $ cat test.cc
> #include
> #define __GDK_H_INSIDE__
> #include
> #include
> #include
> #include
>
> #define IGNORE _Pragma("GCC diagnostic ignored \"-Wdeprecated-declarations\"")
> __attribute__((deprecated)) void f();
> int main() {
> IGNORE
> f();
> }
> $ /home/sbergman/gcc/trunk/inst/bin/g++ -Werror -O -c test.cc \
> -I/home/sbergman/lo/core/workdir/UnpackedTarball/boost \
> -I/usr/include/gtk-3.0 -I/usr/include/cairo -I/usr/include/pango-1.0 \
> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 \
> -I/usr/lib64/glib-2.0/include
>
> test.cc: In function ‘int main()’:
> test.cc:12:5: error: ‘void f()’ is deprecated
> [-Werror=deprecated-declarations]
> f();
> ^
> test.cc:9:34: note: declared here
> __attribute__((deprecated)) void f();
> ^
> test.cc:12:7: error: ‘void f()’ is deprecated
> [-Werror=deprecated-declarations]
> f();
>^
> test.cc:9:34: note: declared here
> __attribute__((deprecated)) void f();
> ^
> cc1plus: all warnings being treated as errors
[Bug preprocessor/69126] [6 regression] _Pragma does not apply if part of a macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69126 --- Comment #20 from Jakub Jelinek --- Does the http://gcc.gnu.org/ml/gcc-patches/2016-01/msg02347.html workaround help here in any way?
[Bug preprocessor/69126] [6 regression] _Pragma does not apply if part of a macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69126 Jakub Jelinek changed: What|Removed |Added Status|RESOLVED|NEW Resolution|FIXED |--- --- Comment #19 from Jakub Jelinek --- Reopening then.
[Bug preprocessor/69126] [6 regression] _Pragma does not apply if part of a macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69126 --- Comment #21 from Jakub Jelinek --- In any case, we need much better testsuite coverage for the cases that the various projects use (glib2, LO, ...), so that we don't regress on those without knowing about it months later.
[Bug preprocessor/69126] [6 regression] _Pragma does not apply if part of a macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69126 --- Comment #16 from David Malcolm --- Author: dmalcolm Date: Wed Jan 27 18:57:51 2016 New Revision: 232893 URL: https://gcc.gnu.org/viewcvs?rev=232893=gcc=rev Log: libcpp: use better locations for _Pragma tokens (preprocessor/69126) gcc/testsuite/ChangeLog: PR preprocessor/69126 * c-c++-common/pr69126.c: New test case. libcpp/ChangeLog: PR preprocessor/69126 * directives.c (destringize_and_run): Add expansion_loc param; use it when handling unexpanded pragmas to fixup the locations of the synthesized tokens. (_cpp_do__Pragma): Add expansion_loc param and use it when calling destringize_and_run. * internal.h (_cpp_do__Pragma): Add expansion_loc param. * macro.c (builtin_macro): Pass expansion location of _Pragma to _cpp_do__Pragma. Added: trunk/gcc/testsuite/c-c++-common/pr69126.c Modified: trunk/gcc/testsuite/ChangeLog trunk/libcpp/ChangeLog trunk/libcpp/directives.c trunk/libcpp/internal.h trunk/libcpp/macro.c
[Bug preprocessor/69126] [6 regression] _Pragma does not apply if part of a macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69126 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #17 from David Malcolm --- Should be fixed as of r232893; marking this as resolved.
[Bug preprocessor/69126] [6 regression] _Pragma does not apply if part of a macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69126 --- Comment #15 from Manuel López-Ibáñez --- (In reply to Paolo Carlini from comment #2) > the regression and I'm pretty sure would not introduce other wrt the status > pre-r226234, but I don't fully understand why that is necessary, there are Wasn't the reason for removing '+' a bug report showing a similar case (#pragma diagnostic being ignored because '+' does not affect the pragma)? Cases that did work before but don't work now just worked by chance. Unrelated changes to input_location would also break them. David's fix is a step in the right direction.
[Bug preprocessor/69126] [6 regression] _Pragma does not apply if part of a macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69126 --- Comment #14 from Manuel López-Ibáñez --- Related bug 52116
[Bug preprocessor/69126] [6 regression] _Pragma does not apply if part of a macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69126
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Comment #13 from Manuel López-Ibáñez ---
(In reply to Jakub Jelinek from comment #3)
> For whatever reason, the DECL_SOURCE_LOCATION of the x decl when it comes
> from macro is the locus where the macro is used rather than the locus in the
> macro.
The actual issue is that "GCC diagnostic" uses the location passed to the
diagnostic function explicitly (or input_location), never the location set by
'+'. That is, warning("%q+D") uses input_location for testing against the
pragma but DECL_SOURCE_LOCATION for reporting the warning. Of course, such
behaviour breaks other cases, which is one reason to avoid '+'.
[Bug preprocessor/69126] [6 regression] _Pragma does not apply if part of a macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69126 --- Comment #12 from David Malcolm --- Patch posted here: https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01212.html
[Bug preprocessor/69126] [6 regression] _Pragma does not apply if part of a macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69126 David Malcolm changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot gnu.org
