[Bug ada/96590] New: testsuite spins forever on test_prio when run as root
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96590 Bug ID: 96590 Summary: testsuite spins forever on test_prio when run as root Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: lhyatt at gcc dot gnu.org Target Milestone: --- Hello- I ran into this trying to "make check" all languages, when run as root, the test_prio.adb test never terminates. After 5 minutes it seems that dejagnu tries to kill it, but the signal is ignored. This is on x86-64 linux, Ubuntu 18.04, current gcc 11 trunk. $ gcc -v: Using built-in specs. COLLECT_GCC=../release/bin/gcc COLLECT_LTO_WRAPPER=/home/lewis/gccdev/release/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../git/configure --disable-multilib --enable-languages=all --prefix=/home/lewis/gccdev/release --with-tune=native : (reconfigured) ../git/configure --disable-multilib --prefix=/home/lewis/gccdev/release --with-tune=native --enable-languages=c,ada,brig,c++,d,fortran,go,lto,objc,obj-c++ --no-create --no-recursion : (reconfigured) ../git/configure --disable-multilib --enable-languages=all --prefix=/home/lewis/gccdev/release --with-tune=native : (reconfigured) ../git/configure --disable-multilib --prefix=/home/lewis/gccdev/release --with-tune=native --enable-languages=c,ada,brig,c++,d,fortran,go,lto,objc,obj-c++ --no-create --no-recursion Thread model: posix Supported LTO compression algorithms: zlib gcc version 11.0.0 20200810 (experimental) (GCC) $ uname -a Linux host 4.15.0-47-generic #50-Ubuntu SMP Wed Mar 13 10:44:52 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux $ /lib/x86_64-linux-gnu/libc.so.6 GNU C Library (Ubuntu GLIBC 2.27-3ubuntu1) stable release version 2.27. Copyright (C) 2018 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 7.3.0. libc ABIs: UNIQUE IFUNC For bug reporting instructions, please see: <https://bugs.launchpad.net/ubuntu/+source/glibc/+bugs>. $ cat /etc/issue Ubuntu 18.04.2 LTS \n \l To test it, I do: cd $objdir/gcc; make -k check-gnat RUNTESTFLAGS=dg.exp=test_prio\* And observe the test_prio.exe runs forever. If I strace it, it's like this: sched_setscheduler(32599, SCHED_OTHER, [0]) = 0 sched_setscheduler(32599, SCHED_OTHER, [99]) = -1 EINVAL (Invalid argument) sched_setscheduler(32599, SCHED_OTHER, [0]) = 0 sched_setscheduler(32599, SCHED_OTHER, [99]) = -1 EINVAL (Invalid argument) sched_setscheduler(32599, SCHED_OTHER, [0]) = 0 sched_setscheduler(32599, SCHED_OTHER, [99]) = -1 EINVAL (Invalid argument) sched_setscheduler(32599, SCHED_OTHER, [0]) = 0 sched_setscheduler(32599, SCHED_OTHER, [99]) = -1 EINVAL (Invalid argument) sched_setscheduler(32599, SCHED_OTHER, [0]) = 0 sched_setscheduler(32599, SCHED_OTHER, [99]) = -1 EINVAL (Invalid argument) sched_setscheduler(32599, SCHED_OTHER, [0]) = 0 sched_setscheduler(32599, SCHED_OTHER, [99]) = -1 EINVAL (Invalid argument) ... And if I get a backtrace, it's like this: #0 0x7feab01f8df7 in sched_setscheduler () at ../sysdeps/unix/syscall-template.S:78 #1 0x7feab06fd2dc in __pthread_tpp_change_priority (previous_prio=previous_prio@entry=-1, new_prio=new_prio@entry=99) at tpp.c:149 #2 0x7feab06f59d0 in __pthread_mutex_cond_lock_full (mutex=0x18a43f8) at ../nptl/pthread_mutex_lock.c:541 #3 0x7feab06f5f35 in __pthread_mutex_cond_lock (mutex=mutex@entry=0x18a43f8) at ../nptl/pthread_mutex_lock.c:71 #4 0x7feab06f7d9d in __pthread_cond_wait_common (abstime=0x7ffee1b75aa0, mutex=0x18a43f8, cond=0x18a43c8) at pthread_cond_wait.c:645 #5 __pthread_cond_timedwait (cond=cond@entry=0x18a43c8, mutex=mutex@entry=0x18a43f8, abstime=abstime@entry=0x7ffee1b75aa0) at pthread_cond_wait.c:667 #6 0x00422a45 in system.task_primitives.operations.monotonic.timed_sleep (reason=, mode=0, time=0.01, self_id=0x18a4280) at s-tpopmo.adb:194 #7 system.task_primitives.operations.timed_sleep (self_id=self_id@entry=0x18a4280, time=time@entry=0.01, mode=mode@entry=0, reason=) at s-taprop.adb:600 #8 0x0042de16 in system.tasking.stages.finalize_global_tasks () at s-tassta.adb:867 #9 0x00404667 in adafinal () at s-tassta.adb:1217 #10 0x00404bbc in main () at s-tassta.adb:1217 #11 0x7feab0116b97 in __libc_start_main (main=0x404b5c , argc=1, argv=0x7ffee1b75c08, init=, fini=, rtld_fini=, stack_end=0x7ffee1b75bf8) at ../csu/libc-start.c:310 #12 0x0040444a in _start () at s-tassta.adb:1217 Not sure if it is an issue in ada usage of pthreads or in pthread implementation or my configuration, seems it gets into an infinite loop there? When run as non-root, it terminates right away and prints "error", and
[Bug ipa/91853] [10 Regression] ICE in gimplify_modify_expr, at gimplify.c:5902 since r275982
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91853 --- Comment #7 from lhyatt at gcc dot gnu.org --- Author: lhyatt Date: Wed Dec 11 14:52:31 2019 New Revision: 279226 URL: https://gcc.gnu.org/viewcvs?rev=279226&root=gcc&view=rev Log: Adds multibyte awareness to pretty-print.c 2019-12-11 Lewis Hyatt PR 91853 * pretty-print.c (pp_quoted_string): Avoid hex-escaping valid multibyte input. Fix off-by-one-bug printing the last byte before a hex-escaped output. (pp_character): Don't apply line wrapping in the middle of multibyte characters. (test_utf8): New test. (pretty_print_c_tests): Call the new test. Modified: trunk/gcc/ChangeLog trunk/gcc/pretty-print.c
[Bug other/93067] diagnostics are not aware of -finput-charset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93067 lhyatt at gcc dot gnu.org changed: What|Removed |Added Attachment #47547|0 |1 is obsolete|| CC||lhyatt at gcc dot gnu.org --- Comment #3 from lhyatt at gcc dot gnu.org --- Created attachment 49557 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49557&action=edit updated patch to apply to current master It seems I did not pursue this beyond filing this bug report with the patch. The patch requires some minor rebasing, just due to surrounding context, so here is a version that applies now, and still bootstraps and works. Should I send to gcc-patches as well? I think the main potential issue with it is that it requires input.h / input.c to get a global variable so that frontends can let it know they are using libcpp to read their input. (Otherwise -finput-charset is not applicable). I am sure there is a better way to do that, but not sure the cleanest one, none of the routines in input.c seem to make use of a diagnostic_context or similar thing. -Lewis
[Bug preprocessor/108244] [13 Regression] `pragma GCC diagnostic` and -E -fdirectives-only causes the preprocessor to become confused since r13-1544-ge46f4d7430c52104
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108244 Lewis Hyatt changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #12 from Lewis Hyatt --- Fixed by r13-5114.
[Bug preprocessor/67046] [10/11/12/13 Regression] Segmentation fault when a preprocessor directive follows the argument to _Pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67046
Lewis Hyatt changed:
What|Removed |Added
CC||lhyatt at gcc dot gnu.org
--- Comment #4 from Lewis Hyatt ---
By default, libcpp reuses token buffers whenever it begins a new line.
get__Pragma_string() in directives.cc doesn't account for this, and so the
string token it obtains is overwritten by the paren token if the paren token is
not on the same line. If the no-op directive is removed as in:
===
_Pragma(
"message(\"msg\")"
)
===
Then it ends up returning a "weird" string token with type set to
CPP_CLOSE_PAREN, but with still-valid string contents because the lexing of a
paren token does not touch the rest of the data. So by chance it all ends up
working. But interposing an empty directive there makes it not to work, the
string contents get cleared out and destringize_and_run() ends up seeing a
string token with length 0 which it does not expect and calls alloca() with -1.
The fix is just to use the existing keep_tokens mechanism to avoid invalidating
the token. I am testing this patch now and will follow up.
diff --git a/libcpp/directives.cc b/libcpp/directives.cc
index 9dc4363c65a..15de1826373 100644
--- a/libcpp/directives.cc
+++ b/libcpp/directives.cc
@@ -1840,7 +1840,7 @@ get_token_no_padding (cpp_reader *pfile)
/* Check syntax is "(string-literal)". Returns the string on success,
or NULL on failure. */
static const cpp_token *
-get__Pragma_string (cpp_reader *pfile)
+get__Pragma_string_1 (cpp_reader *pfile)
{
const cpp_token *string;
const cpp_token *paren;
@@ -1868,6 +1868,17 @@ get__Pragma_string (cpp_reader *pfile)
return string;
}
+/* Make sure we don't invalidate the string token, if the parenthesis
+ ended up on a different line. */
+static const cpp_token *
+get__Pragma_string (cpp_reader *pfile)
+{
+ ++pfile->keep_tokens;
+ const auto result = get__Pragma_string_1 (pfile);
+ --pfile->keep_tokens;
+ return result;
+}
+
/* Destringize IN into a temporary buffer, by removing the first \ of
\" and \\ sequences, and process the result as a #pragma directive. */
static void
[Bug preprocessor/67046] [10/11/12/13 Regression] Segmentation fault when a preprocessor directive follows the argument to _Pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67046 --- Comment #5 from Lewis Hyatt --- The patch was submitted for review here: https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609951.html
[Bug preprocessor/67046] [10/11/12/13 Regression] Segmentation fault when a preprocessor directive follows the argument to _Pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67046 Lewis Hyatt changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #7 from Lewis Hyatt --- Fixed for GCC 13.
[Bug c++/66290] wrong location for -Wunused-macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66290 --- Comment #5 from Lewis Hyatt --- Patch submitted for review: https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598989.html
[Bug c++/66290] wrong location for -Wunused-macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66290 --- Comment #7 from Lewis Hyatt --- The wrong location is fixed for GCC 13. Shall I leave the PR open for now, since there was also the issue of getting a caret pointing to the name of macro, rather than just a diagnostic for the whole line? I can look into that too.
[Bug c++/66290] wrong location for -Wunused-macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66290 --- Comment #8 from Lewis Hyatt --- (In reply to Lewis Hyatt from comment #7) > The wrong location is fixed for GCC 13. Shall I leave the PR open for now, > since there was also the issue of getting a caret pointing to the name of > macro, rather than just a diagnostic for the whole line? I can look into > that too. Patch to improve the range information on the diagnostic submitted for review here: https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599397.html I think if that gets applied then we could close this one.
[Bug preprocessor/69543] [10/11/12/13 Regression] _Pragma does not apply within macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69543 Lewis Hyatt changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED
[Bug c/91669] #pragma's and _Pragma's work but _Pragma's used in an equivalent macro don't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91669
Lewis Hyatt changed:
What|Removed |Added
CC||lhyatt at gcc dot gnu.org
--- Comment #4 from Lewis Hyatt ---
This is already fixed on the latest GCC 10, 11, and 12 branches and on trunk
for GCC 13.
There were two separate issues contributing to this problem. The first one was
common to both C and C++, and it was fixed by r10-325 for PR90382. (That PR was
primarily about something else so was not focused on _Pragma locations, but the
fix resolved this PR too.)
The second issue made it stay broken longer for C only, not C++. In that sense
it's partially a dupe of PR97498 and this aspect was fixed by r13-1596. (Issue
was that in C, input_location used to be always the start of the line.) That
fix has been backported to 10, 11, and 12 branches already.
The testcase I added in r13-1596 provides partial coverage for this issue as
well, but it does not quite cover the issue with adhoc locations addressed by
r10-325. Here is a reduced testcase for this PR:
===
#define ENDFUNC \
_Pragma("GCC diagnostic push") \
_Pragma("GCC diagnostic ignored \"-Wreturn-type\"") \
} \
_Pragma("GCC diagnostic pop")
int f () {
ENDFUNC
===
I will submit a patch to add this testcase and then close this one once that's
applied.
[Bug c++/55578] Disabling warnings inside macro definition doesn't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55578 Lewis Hyatt changed: What|Removed |Added CC||lhyatt at gcc dot gnu.org --- Comment #9 from Lewis Hyatt --- This was fixed by r9-1926 (see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69558#c25) and is a dupe of that aspect of PR69558. I would suggest to mark this one resolved, however comment 8 brought up that there was potentially a change in behavior in GCC 11. Do you have an example test case that doesn't behave as you expect? If not, I would suggest to close this one, there has been a lot of progress on pragma locations and I believe most such issues are now fixed on GCC 13 master branch.
[Bug c/91669] #pragma's and _Pragma's work but _Pragma's used in an equivalent macro don't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91669 Lewis Hyatt changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from Lewis Hyatt --- Testcase has been added, resolving fixed.
[Bug middle-end/103036] incorrect #pragma GCC diagnostic suppression for macro expansion and -Wuninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103036 Lewis Hyatt changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED CC||lhyatt at gcc dot gnu.org --- Comment #2 from Lewis Hyatt --- This was fixed by r13-2994. Sorry for not tagging this PR, I came upon the issue via PR69543 comment 9 instead. Regarding PR90400, I think that is about the way the token streamer class works for gcc -E, and it needs to handle _Pragma distinctly from #pragma. I will look at it too sometime.
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 103036, which changed state. Bug 103036 Summary: incorrect #pragma GCC diagnostic suppression for macro expansion and -Wuninitialized https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103036 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug preprocessor/83256] inconsistent _Pragma behavior in multi-line macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83256 Lewis Hyatt changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED CC||lhyatt at gcc dot gnu.org --- Comment #5 from Lewis Hyatt --- 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.
[Bug c++/55578] Disabling warnings inside macro definition doesn't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55578 --- Comment #11 from Lewis Hyatt --- (In reply to Vadim Zeitlin from comment #10) > There definitely was a change in behaviour in gcc 11 because I had to make > this change > > https://github.com/wxWidgets/wxWidgets/commit/ > 95c98a0b5ff71caca6654327bf341719c6587766 Thanks for that. I made a bisectable test that compiles allheaders.cpp (without your GCC 11-specific workaround in place) and counts the number of -Wsuggest-override warnings, which does indeed change in GCC 11.1 vs older and newer versions. The bisect confirmed that this issue was the same as that of PR100796. It existed only in GCC 11.1, as it was introduced by r11-7179 and was fixed by r12-1538, which was also backported to GCC 11.2. This particular issue only materializes with a sufficiently large source file, so I don't think you should find any "reasonably" sized testcase to reproduce it. All basic examples I tried work fine in 11.1 as well. As far as I can tell, I think your workaround should be needed only for sufficiently large translation units (approx 10 lines or more), not for typical size user code, and I think it should be needed only for 11.1 and no other version. If you know otherwise, please advise... otherwise, I think this is resolved.
[Bug c++/55578] Disabling warnings inside macro definition doesn't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55578 Lewis Hyatt changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #13 from Lewis Hyatt --- (In reply to Vadim Zeitlin from comment #12) > Thanks for looking at this! I'm happy to hear that the problem is fixed in > 11.2, but I'm probably not going to change our code anyhow, especially as > we're going to finally drop support for C++98 very soon and so will be able > to just use "override" unconditionally anyhow. > > I.e. from my point of view there is no real problem any more, I just replied > here to give more information about the problem in case it could be useful. Thanks, yes it was useful. Hopefully, issues with warning suppression will be increasingly rare going forward.
[Bug preprocessor/60014] Bad warning suppression caused by track-macro-expansion when not using integrated cpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60014
Lewis Hyatt changed:
What|Removed |Added
CC||lhyatt at gcc dot gnu.org
--- Comment #8 from Lewis Hyatt ---
The testcase for this PR was one of many that got fixed by r9-1926 (for
PR69558). The location of the token resulting from expanding the builtin macro
__LINE__ was, prior to r9-1926, pointing to the closing paren of the macro
invocation, i.e. not in the system header. After r9-1926, the location of the
token is a virtual location encoding that the token resulted from expansion of
a macro defined in a system header, and so the "system"-ness of the token no
longer gets lost.
Fredrik's original testcase is a nice one. Every element in it is essential to
reveal the issue, including the extra semicolon in the FOO macro and the
newline in the invocation. Although that testcase now works correctly, Manuel's
point still stands, c-ppoutput.cc should not have behaved this way, even absent
r9-1926. The problem is that here:
==
if (do_line_adjustments
&& !in_pragma
&& !line_marker_emitted
&& print.prev_was_system_token != !!in_system_header_at (loc)
&& !is_location_from_builtin_token (loc))
/* The system-ness of this token is different from the one of
the previous token. Let's emit a line change to mark the
new system-ness before we emit the token. */
{
do_line_change (pfile, token, loc, false);
print.prev_was_system_token = !!in_system_header_at (loc);
}
===
print.prev_was_system_token should be set always, not only when the if
statement is reached and evaluates to true. In this PR's testcase prior to
r9-1926, the check evaluated to false when streaming the semicolon from the
macro expansion, because a line marker had been printed due to the fact that
the __LINE__ token and the semicolon were assigned locations on different
lines.
So the logic in c-ppoutput.cc assumes that you can never get two tokens on
different lines without a line change callback, which is not a crazy assumption
but was violated due to the issue fixed by r9-1926.
However, there are other code paths besides the line change logic that can
trigger the same issue still now. One way is to stream a deferred CPP_PRAGMA
token, since that code path doesn't even execute the above if statement. As of
r13-1544, we do see such tokens while preprocessing, so here is a modified
testcase that fails on master:
==
$ cat t2.h
#pragma GCC system_header
#define X _Pragma("GCC diagnostic push");
$ cat t2.c
#include "./t2.h"
X
const char* should_warn = 1;
$ gcc -Wint-conversion -c t2.c
t2.c:3:27: warning: initialization of ‘const char *’ from ‘int’ makes pointer
from integer without a cast [-Wint-conversion]
3 | const char* should_warn = 1;
| ^
$ gcc -Wint-conversion -c t2.c -save-temps
$
==
I can test the fix and prepare a patch for that.
[Bug c/89549] [10/11/12/13 Regression] -Wmisleading-indentation is disabled from this point onwards, since column-tracking was disabled due to the size of the code/headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89549
--- Comment #25 from Lewis Hyatt ---
This patch would make the note controllable via #pragma GCC diagnostic in the
same way as the warning is:
=
diff --git a/gcc/c-family/c-indentation.cc b/gcc/c-family/c-indentation.cc
index 85a3ae1b303..3b5d3b17cc9 100644
--- a/gcc/c-family/c-indentation.cc
+++ b/gcc/c-family/c-indentation.cc
@@ -310,7 +310,8 @@ should_warn_for_misleading_indentation (const
token_indent_info &guard_tinfo,
if (!guard_exploc.column || !body_exploc.column || !next_stmt_exploc.column)
{
static bool issued_note = false;
- if (!issued_note)
+ if (!issued_note
+ && warning_enabled_at (guard_loc, OPT_Wmisleading_indentation))
{
/* Notify the user the first time this happens. */
issued_note = true;
=
I am not quite sure how to interpret Jakub's comments though (comment 14 and
comment 16)... not sure whether he was saying this change would be undesirable,
or just explaining why it doesn't seem strictly necessary.
[Bug preprocessor/60014] Bad warning suppression caused by track-macro-expansion when not using integrated cpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60014 Lewis Hyatt changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Lewis Hyatt --- The underlying issue is fixed for GCC 13 now.
[Bug c++/85266] Inconsistent _Pragma behavior for macro with and without arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85266 Lewis Hyatt changed: What|Removed |Added CC||lhyatt at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Lewis Hyatt --- Another _Pragma bug that was fixed by r9-1926. Similar to PR69558, we have test coverage for it already.
[Bug c/91669] #pragma's and _Pragma's work but _Pragma's used in an equivalent macro don't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91669 Lewis Hyatt changed: What|Removed |Added CC||falemagn at gmail dot com --- Comment #7 from Lewis Hyatt --- *** Bug 85153 has been marked as a duplicate of this bug. ***
[Bug c++/85153] _Pragma to disable -Wswitch-unreachable diagnostic not properly working when used within preprocessor macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85153 Lewis Hyatt changed: What|Removed |Added Resolution|--- |DUPLICATE CC||lhyatt at gcc dot gnu.org Status|NEW |RESOLVED --- Comment #6 from Lewis Hyatt --- This was the same issue as PR91669. Fixed by r10-325 and a testcase was added in r13-3051. *** This bug has been marked as a duplicate of bug 91669 ***
[Bug c/95239] Unable to ignore -Wattribute-warning in macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95239 Lewis Hyatt changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE CC||lhyatt at gcc dot gnu.org --- Comment #1 from Lewis Hyatt --- Same issue as PR97498. *** This bug has been marked as a duplicate of bug 97498 ***
[Bug preprocessor/97498] #pragma GCC diagnostic ignored "-Wunused-function" inconsistent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97498 Lewis Hyatt changed: What|Removed |Added CC||e...@coeus-group.com --- Comment #12 from Lewis Hyatt --- *** Bug 95239 has been marked as a duplicate of this bug. ***
[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431 --- Comment #47 from Lewis Hyatt --- (In reply to Manuel López-Ibáñez from comment #46) > If you don't get much attention to the patch, it may be worth pinging it. > But before that, I would also suggest submitting all the cleanups separately > as their own, easy-to-review patch. For example, the bits about > cp_token_is_module_directive. Thank you for the note, I have resubmitted it to gcc-patches in two parts: https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587357.html https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587358.html The cp_token_is_module_directive that you highlighted clearly should be in its own patch, yes. I looked through the rest though and wasn't able to identify anything else that seemed to make sense when split out on its own, so that ended up being the only thing I factored out.
[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431 Lewis Hyatt changed: What|Removed |Added CC||lhyatt at gcc dot gnu.org --- Comment #44 from Lewis Hyatt --- I have a patch for this submitted to the mailing list here: https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586191.html Initially I tried resurrecting Manuel's patch from comment #10 and got it working, however it led to other issues for C++. The problem is that, with that change, the C++ frontend processes the pragmas too early, instead of too late; it processes every #pragma GCC diagnostic in the file prior to handling any tokens. This makes a large demand on the diagnostics infrastructure, namely that it correctly handles every case of processing source lines and determining which #pragmas are in effect at that time and which are for the future. This infrastructure is in place and generally works, however it doesn't handle all cases, notably a change to the argument of an option (say something like, #pragma GCC diagnostic warning "-Wimplicit-fallthrough=4") is not tracked properly (see also PR c/71603). The state of warning options is also often queried directly by the frontend code, not making use of the diagnostics state tracking facilities, and this also leads to warnings being generated or not generated unexpectedly. So this patch leads to a lot of testcase failures, for example, c-c++-common/Wshadow-1.c. I think in the ideal case, it should be made to work correctly that all diagnostic pragmas could be parsed prior to processing the tokens and everything would work, but this seems like a large overhaul. I can try to tackle improving that later, but for the purpose of resolving this PR, I thought it was worth trying another approach, which is just to arrange that every frontend does indeed handle the #pragma when it needs to. My patch does things this way, it adds the concept of an early pragma handler, which can be registered similar to a normal one and runs in addition to it. The early handler for diagnostic pragmas then filters for libcpp-generated diagnostics and processes those when called. Then the C++ frontend, and gcc -E, are both modified to make use of it. This asks much less of the state tracking, since only libcpp diagnostics are handled early. The C++ frontend changes are not too extensive, it basically notes when it sees a CPP_PRAGMA_EOL token during initial parsing, and if so, it handles it immediately. In order to reuse the existing handler for diagnostic pragmas, it sets up the main lexer so that it is sufficiently prepared for pragma_lex() to work, which is all that is needed. For preprocessing mode, I needed to refactor the code for handle_diagnostic_pragma a bit, since in preprocess-only mode, there is no C or C++ parser available and the tokens need to be lexed directly from libcpp. I also needed adjustments in c-ppoutput.c to make sure, as Manuel pointed out, that we do still output the #pragma GCC diagnostic in the preprocessed output. I hope this looks workable, happy to adjust the patch as needed.
[Bug other/102099] New: Diagnostics do not consider the user's locale when printing source lines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102099 Bug ID: 102099 Summary: Diagnostics do not consider the user's locale when printing source lines Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: lhyatt at gcc dot gnu.org Target Milestone: --- If the user has a non-UTF-8 locale configured, they will currently still receive UTF-8 output from GCC's stderr under some conditions: -If a filename for which diagnostics are issued contains extended characters -If a source line for which diagnostics are issued contains extended characters. When a source line contains identifier names with extended characters, the C/C++ front ends take care to convert them to the user's locale, by always passing them to identifier_to_locale() before output. However, this only affects the diagnostics messages generated by the front end, and does not affect the source line itself which is printed separately. Example: $ cat á.cpp int á = 0; int á = 1; #in UTF-8 locale, looks fine $ gcc -c á.cpp á.cpp:2:5: error: redefinition of ‘int á’ 2 | int á = 1; | ^ á.cpp:1:5: note: ‘int á’ previously defined here 1 | int á = 0; | ^ #in C locale, only partially converted to UCNs $ LC_ALL=C gcc -c á.cpp á.cpp:2:5: error: redefinition of 'int \U00e1' 2 | int á = 1; | ^ á.cpp:1:5: note: 'int \U00e1' previously defined here 1 | int á = 0; | ^ The attached patch arranges for the output to be rather: #corrected by this patch $ LC_ALL=C gcc -c á.cpp \U00e1.cpp:2:5: error: redefinition of 'int \U00e1' 2 | int \U00e1 = 1; | ^ \U00e1.cpp:1:5: note: 'int \U00e1' previously defined here 1 | int \U00e1 = 0; | ^ In the above example I showed C locale, where the extended characters need to be escaped, but the patch would also handle e.g. latin1 locale, where it would output as expected, using iconv to convert to the output charset. The patch is pretty complete, and bootstraps all languages with no regression. However there are a couple potential issues with it that may need to be discussed before it's ready to be used, so I have held off submitting to gcc-patches for now. The two main points of concern are: 1. Diagnostics recently acquired a lot of infrastructure to know the correct display width of extended characters, so that things like carets and label lines show up at the correct place. This infrastructure however is not currently able to handle locale dependence of the display width. Changing that is rather complicated, because determining that the display width of "á" is actually 10 columns instead of 1 (in case of UCN escape), requires attempting to convert the character to the user's locale (perhaps with iconv), and determining if it can be displayed or requires an escape. So the process of determining the display width becomes an expensive operation that should be optimized and performed once for the line, not something that can be computed on the fly as is done now. This breaks the assumptions in the design of the current approach and so would require it to be redone. That is certainly doable but it seems unfortunate to make that process much more complicated, for what's not probably a commonly needed use case. I suspect, that in many cases, users with a C locale configured actually still see UTF-8 output fine in their terminal anyway... The output with UCN escapes already looks bad, so perhaps having misaligned labels and carets is not a big deal and it's fine as it is. 2. The testsuite always runs with LC_ALL=C currently. Therefore, after the change in this patch, a test is no longer able to test for UTF-8 output in diagnostics, it will be UCN escaped instead. There is one such test currently (gcc.dg/diagnostic-input-charset-1.c). It doesn't seem suitable to change that test to look for UCN escapes, because the purpose of that test is to confirm that correct UTF-8 is generated when an input file is in another charset. So I instead added a new option -fdiagnostics-format=force-utf8. This is the same as -fdiagnostics-format=text except it disables the conversion to the user's locale and restores the previous behavior. That seemed more simple than adding ability to change the locale in the testsuite, plus I thought users may want this option for themselves for some reason, if say they do not have access to a UTF-8 locale somehow but their terminal still displays it fine. So that much seems fine, however there is a wrinkle here that I am not sure how to fix. The user probably expects that this new option will cause all diagnostics output to be UTF-8 regardless of locale. But some of the output is not gene
[Bug other/102099] Diagnostics do not consider the user's locale when printing source lines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102099 --- Comment #1 from Lewis Hyatt --- Created attachment 51365 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51365&action=edit Tested patch
[Bug preprocessor/55971] Preprocessor macros with C++11 raw string literals fail to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55971 Lewis Hyatt changed: What|Removed |Added Status|NEW |RESOLVED Target Milestone|--- |13.0 Resolution|--- |FIXED --- Comment #10 from Lewis Hyatt --- Fixed for GCC 13.
[Bug bootstrap/107722] [13 Regression] Bootstrap failure for some locales starting with r13-4070
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107722 Lewis Hyatt changed: What|Removed |Added CC||lhyatt at gcc dot gnu.org --- Comment #5 from Lewis Hyatt --- Thanks for the fix, and sorry for missing this case.
[Bug preprocessor/108244] [13 Regression] `pragma GCC diagnostic` and -E -fdirectives-only causes the preprocessor to become confused
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108244 Lewis Hyatt changed: What|Removed |Added CC||lhyatt at gcc dot gnu.org --- Comment #6 from Lewis Hyatt --- I am taking a look.
[Bug preprocessor/108244] [13 Regression] `pragma GCC diagnostic` and -E -fdirectives-only causes the preprocessor to become confused
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108244
--- Comment #7 from Lewis Hyatt ---
The testcases mentioned so far in this PR (the original report, and the
reduction in Comment 5) started failing in r13-1544, because that revision
added #pragma GCC diagnostic to the set of pragmas that are registered in
preprocess-only mode, including in -fdirectives-only. But the same issue has
existed always it seems for other pragmas similarly registered; for instance
this testcase fails since gcc 9 and before:
=
$ cat t2.cpp
#pragma message "hello"
#ifdef t
#endif
$ gcc-9 -E -fdirectives-only t2.cpp > /dev/null
t2.cpp:1:9: warning: extra tokens at end of #ifdef directive
1 | #pragma message "hello"
| ^
=
I think with -fdirectives-only, #pragma is not meant to be registered or
processed.
The below patch fixes all testcases mentioned so far:
===
diff --git a/gcc/c-family/c-pragma.cc b/gcc/c-family/c-pragma.cc
index 142a46441ac..e9bcd1869d0 100644
--- a/gcc/c-family/c-pragma.cc
+++ b/gcc/c-family/c-pragma.cc
@@ -1647,7 +1647,8 @@ c_register_pragma_1 (const char *space, const char *name,
if (flag_preprocess_only)
{
- if (!(allow_expansion || ihandler.early_handler.handler_1arg))
+ if (cpp_get_options (parse_in)->directives_only
+ || !(allow_expansion || ihandler.early_handler.handler_1arg))
return;
pragma_pp_data pp_data;
However it doesn't fix an analogous one using "#pragma omp" even though it
suppresses the registration of the pragma there too. I will track that down and
follow up with a complete patch.
[Bug preprocessor/108244] [13 Regression] `pragma GCC diagnostic` and -E -fdirectives-only causes the preprocessor to become confused
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108244 --- Comment #8 from Lewis Hyatt --- Here is the patch: https://gcc.gnu.org/pipermail/gcc-patches/2022-December/609275.html
[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431 --- Comment #49 from Lewis Hyatt --- I rebased the patches so they apply to the current master branch and pinged them on gcc-patches here: https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595556.html -Lewis
[Bug c++/84920] Better handling of unmatched/ambiguous calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84920
Lewis Hyatt changed:
What|Removed |Added
CC||lhyatt at gcc dot gnu.org
--- Comment #8 from Lewis Hyatt ---
Created attachment 53108
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53108&action=edit
One possible approach
Hello-
What do you all think of this approach?
The new options -foverload-candidates-reduce-level and
-foverload-candidates-stop-level would configure the amount of information that
is output regarding overload candidates. When the number of overloads exceeds
-foverload-candidates-reduce-level (default 3), then the source lines are no
longer printed for each candidate, cutting the output length in half. The
source lines seem rarely useful anyway, since the diagnostic's first line
already prints the overload being considered. When the number of overloads
exceeds -foverload-candidates-stop-level (default 7), none of the overloads is
printed, since this is presumably a case such as a heavily overloaded operator
where the large number of candidates is less likely to be helpful in fixing the
problem.
For a testcase like this common (for me) typo:
=
#include
void f(std::ostream& o, int a) {
o << a < '\n';
}
=
GCC then outputs:
=
iowarn.cpp: In function ‘void f(std::ostream&, int)’:
iowarn.cpp:3:12: error: no match for ‘operator<’ (operand types are
‘std::basic_ostream’ and ‘char’)
3 | o << a < '\n';
| ~~ ^
| | |
| | char
| std::basic_ostream
iowarn.cpp:3:12: note: declining to output 15 candidates (limit 7); compile
with ‘-foverload-candidates-stop-level=15’ to see them
=
which at least for this specific case feels like an improvement to me... It's
obvious what is wrong now.
If you follow the suggestion and add the flag to the compile, then you see:
=
iowarn.cpp: In function ‘void f(std::ostream&, int)’:
iowarn.cpp:3:12: error: no match for ‘operator<’ (operand types are
‘std::basic_ostream’ and ‘char’)
3 | o << a < '\n';
| ~~ ^
| | |
| | char
| std::basic_ostream
iowarn.cpp:3:12: note: candidate: ‘operator<(int, int)’ (built-in)
iowarn.cpp:3:12: note: no known conversion for argument 1 from
‘std::basic_ostream’ to ‘int’
In file included from /home/lewis/gccdev/release/include/c++/13.0.0/string:46,
from
/home/lewis/gccdev/release/include/c++/13.0.0/bits/locale_classes.h:40,
from
/home/lewis/gccdev/release/include/c++/13.0.0/bits/ios_base.h:41,
from /home/lewis/gccdev/release/include/c++/13.0.0/ios:42,
from /home/lewis/gccdev/release/include/c++/13.0.0/ostream:38,
from iowarn.cpp:1:
/home/lewis/gccdev/release/include/c++/13.0.0/bits/stl_iterator.h:451:5: note:
candidate: ‘template constexpr bool std::operator<(const
reverse_iterator<_Iterator>&, const reverse_iterator<_Iterator>&)’
/home/lewis/gccdev/release/include/c++/13.0.0/bits/stl_iterator.h:451:5: note:
template argument deduction/substitution failed:
iowarn.cpp:3:14: note: ‘std::basic_ostream’ is not derived from ‘const
std::reverse_iterator<_Iterator>’
/home/lewis/gccdev/release/include/c++/13.0.0/bits/stl_iterator.h:496:5: note:
candidate: ‘template constexpr bool
std::operator<(const reverse_iterator<_Iterator>&, const
reverse_iterator<_IteratorR>&)’
/home/lewis/gccdev/release/include/c++/13.0.0/bits/stl_iterator.h:496:5: note:
template argument deduction/substitution failed:
iowarn.cpp:3:14: note: ‘std::basic_ostream’ is not derived from ‘const
std::reverse_iterator<_Iterator>’
/home/lewis/gccdev/release/include/c++/13.0.0/bits/stl_iterator.h:1683:5: note:
candidate: ‘template constexpr bool
std::operator<(const move_iterator<_IteratorL>&, const
move_iterator<_IteratorR>&)’
/home/lewis/gccdev/release/include/c++/13.0.0/bits/stl_iterator.h:1683:5: note:
template argument deduction/substitution failed:
iowarn.cpp:3:14: note: ‘std::basic_ostream’ is not derived from ‘const
std::move_iterator<_IteratorL>’
/home/lewis/gccdev/release/include/c++/13.0.0/bits/stl_iterator.h:1748:5: note:
candidate: ‘template constexpr bool std::operator<(const
move_iterator<_IteratorL>&, const move_iterator<_IteratorL>&)’
/home/lewis/gccdev/release/include/c++/13.0.0/bits/stl_iterator.h:1748:5: note:
template argument deduction/substitution failed:
iowarn.cpp:3:14: note: ‘std::basic_ostream’ is not derived from ‘const
std::move_iterator<_IteratorL>’
In file included from
/home/lewis/gccdev/release/include/c++/13.0.0/bits/s
[Bug c++/84920] Better handling of unmatched/ambiguous calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84920
--- Comment #10 from Lewis Hyatt ---
(In reply to Jonathan Wakely from comment #9)
> That looks pretty good to me. What does it produce for the operator<<
> example in comment 1?
With the default options:
=
iowarn2.cpp: In function ‘void f(std::ostream&, const A&)’:
iowarn2.cpp:13:5: error: no match for ‘operator<<’ (operand types are
‘std::ostream’ {aka ‘std::basic_ostream’} and ‘const A’)
13 | o << a;
| ~ ^~ ~
| ||
| |const A
| std::ostream {aka std::basic_ostream}
iowarn2.cpp:13:5: note: declining to output 34 candidates (limit 7); compile
with ‘-foverload-candidates-stop-level=34’ to see them
=
With the suggestion from the diagnostic -foverload-candidates-stop-level=34, so
this is the ~50% abbreviated mode:
=
iowarn2.cpp: In function ‘void f(std::ostream&, const A&)’:
iowarn2.cpp:13:5: error: no match for ‘operator<<’ (operand types are
‘std::ostream’ {aka ‘std::basic_ostream’} and ‘const A’)
13 | o << a;
| ~ ^~ ~
| ||
| |const A
| std::ostream {aka std::basic_ostream}
In file included from iowarn2.cpp:1:
/home/lewis/gccdev/dev/rel/include/c++/13.0.0/ostream:108:7: note: candidate:
‘std::basic_ostream<_CharT, _Traits>::__ostream_type&
std::basic_ostream<_CharT, _Traits>::operator<<(__ostream_type&
(*)(__ostream_type&)) [with _CharT = char; _Traits = std::char_traits;
__ostream_type = std::basic_ostream]’
/home/lewis/gccdev/dev/rel/include/c++/13.0.0/ostream:108:36: note: no known
conversion for argument 1 from ‘const A’ to
‘std::basic_ostream::__ostream_type&
(*)(std::basic_ostream::__ostream_type&)’ {aka ‘std::basic_ostream&
(*)(std::basic_ostream&)’}
/home/lewis/gccdev/dev/rel/include/c++/13.0.0/ostream:117:7: note: candidate:
‘std::basic_ostream<_CharT, _Traits>::__ostream_type&
std::basic_ostream<_CharT, _Traits>::operator<<(__ios_type& (*)(__ios_type&))
[with _CharT = char; _Traits = std::char_traits; __ostream_type =
std::basic_ostream; __ios_type = std::basic_ios]’
/home/lewis/gccdev/dev/rel/include/c++/13.0.0/ostream:117:32: note: no known
conversion for argument 1 from ‘const A’ to
‘std::basic_ostream::__ios_type&
(*)(std::basic_ostream::__ios_type&)’ {aka ‘std::basic_ios&
(*)(std::basic_ios&)’}
/home/lewis/gccdev/dev/rel/include/c++/13.0.0/ostream:127:7: note: candidate:
‘std::basic_ostream<_CharT, _Traits>::__ostream_type&
std::basic_ostream<_CharT, _Traits>::operator<<(std::ios_base&
(*)(std::ios_base&)) [with _CharT = char; _Traits = std::char_traits;
__ostream_type = std::basic_ostream]’
/home/lewis/gccdev/dev/rel/include/c++/13.0.0/ostream:127:30: note: no known
conversion for argument 1 from ‘const A’ to ‘std::ios_base&
(*)(std::ios_base&)’
/home/lewis/gccdev/dev/rel/include/c++/13.0.0/ostream:166:7: note: candidate:
‘std::basic_ostream<_CharT, _Traits>::__ostream_type&
std::basic_ostream<_CharT, _Traits>::operator<<(long int) [with _CharT = char;
_Traits = std::char_traits; __ostream_type = std::basic_ostream]’
/home/lewis/gccdev/dev/rel/include/c++/13.0.0/ostream:166:23: note: no known
conversion for argument 1 from ‘const A’ to ‘long int’
/home/lewis/gccdev/dev/rel/include/c++/13.0.0/ostream:170:7: note: candidate:
‘std::basic_ostream<_CharT, _Traits>::__ostream_type&
std::basic_ostream<_CharT, _Traits>::operator<<(long unsigned int) [with _CharT
= char; _Traits = std::char_traits; __ostream_type =
std::basic_ostream]’
/home/lewis/gccdev/dev/rel/include/c++/13.0.0/ostream:170:32: note: no known
conversion for argument 1 from ‘const A’ to ‘long unsigned int’
/home/lewis/gccdev/dev/rel/include/c++/13.0.0/ostream:174:7: note: candidate:
‘std::basic_ostream<_CharT, _Traits>::__ostream_type&
std::basic_ostream<_CharT, _Traits>::operator<<(bool) [with _CharT = char;
_Traits = std::char_traits; __ostream_type = std::basic_ostream]’
/home/lewis/gccdev/dev/rel/include/c++/13.0.0/ostream:174:23: note: no known
conversion for argument 1 from ‘const A’ to ‘bool’
In file included from
/home/lewis/gccdev/dev/rel/include/c++/13.0.0/ostream:833:
/home/lewis/gccdev/dev/rel/include/c++/13.0.0/bits/ostream.tcc:91:5: note:
candidate: ‘std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT,
_Traits>::operator<<(short int) [with _CharT = char; _Traits =
std::char_traits]’
/home/lewis/gccdev/dev/rel/include/c++/13.0.0/bits/ostream.tcc:92:22: note:
no known conversion for argument 1 from ‘const A’ to ‘short int’
/home/lewis/gccdev/dev/rel/include/c++/13.0.0/ostream:181:7: note: candidate:
‘std::basic_ostream<_CharT, _Traits>::__ostream_type&
std::basic_ostream<_CharT, _Traits>::operator<<(short unsigned int) [with
_CharT = char; _Traits = std::char_traits; __ostream_type =
std::basic_ostream]’
/home/lewis/gccdev/dev/rel/include/c++/13.0.0/ostream:181:33: note: no known
conversion for argument 1 from ‘const A’ to ‘short unsigned int’
/home/lewis/gccdev/dev/rel/include/c++/13.0.0/bits/ostream.tcc:105:5: note
[Bug preprocessor/104640] incomplete unicode support for User-defined literals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104640 Lewis Hyatt changed: What|Removed |Added Status|NEW |RESOLVED CC||lhyatt at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #4 from Lewis Hyatt --- Dup of PR103902. I'll take a look. *** This bug has been marked as a duplicate of bug 103902 ***
[Bug preprocessor/103902] GCC requires a space between string-literal and identifier in a literal-operator-id where the identifier is not in basic character set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103902 Lewis Hyatt changed: What|Removed |Added CC||maik.urbannek at cattatech dot de --- Comment #2 from Lewis Hyatt --- *** Bug 104640 has been marked as a duplicate of this bug. ***
[Bug preprocessor/103902] GCC requires a space between string-literal and identifier in a literal-operator-id where the identifier is not in basic character set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103902 --- Comment #3 from Lewis Hyatt --- I can look into that.
[Bug preprocessor/64698] preprocessor ignores #pragma GCC diagnostic when using -save-temps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64698 Lewis Hyatt changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE CC||lhyatt at gcc dot gnu.org --- Comment #3 from Lewis Hyatt --- It is indeed a dup of PR53920. Also, I have a patch awaiting review for PR53431; that fixes all 3. *** This bug has been marked as a duplicate of bug 53920 ***
[Bug preprocessor/53920] "gcc -E" does not honor #pragma GCC diagnostic ignored "-Wunused-macro"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53920 --- Comment #4 from Lewis Hyatt --- *** Bug 64698 has been marked as a duplicate of this bug. ***
[Bug preprocessor/53920] "gcc -E" does not honor #pragma GCC diagnostic ignored "-Wunused-macro"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53920 Lewis Hyatt changed: What|Removed |Added CC||lhyatt at gcc dot gnu.org --- Comment #5 from Lewis Hyatt --- I have a patch awaiting review to fix PR53431 which would fix this one too. https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595556.html
[Bug preprocessor/55971] Preprocessor macros with C++11 raw string literals fail to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55971 Lewis Hyatt changed: What|Removed |Added CC||lhyatt at gcc dot gnu.org --- Comment #8 from Lewis Hyatt --- I submitted a patch for this here: https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596820.html
[Bug preprocessor/103902] GCC requires a space between string-literal and identifier in a literal-operator-id where the identifier is not in basic character set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103902 --- Comment #4 from Lewis Hyatt --- (In reply to Lewis Hyatt from comment #3) > I can look into that. Patch waiting for review here: https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596660.html
[Bug preprocessor/100125] -Wunused-macros generated while should be ignored; if undef is seen?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100125 Lewis Hyatt changed: What|Removed |Added CC||lhyatt at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Lewis Hyatt --- The reason it works without #undef is that cpp_finish() is called late by the C++ frontend, after it has processed everything including pragmas. With #undef, the warning is generated immediately by libcpp and so is subject to PR53431. There is a patch waiting for review that will resolve it. *** This bug has been marked as a duplicate of bug 53431 ***
[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431 Lewis Hyatt changed: What|Removed |Added CC||gcc at behdad dot org --- Comment #50 from Lewis Hyatt --- *** Bug 100125 has been marked as a duplicate of this bug. ***
[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431 Lewis Hyatt changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #52 from Lewis Hyatt --- Fixed for GCC 13.
[Bug preprocessor/53920] "gcc -E" does not honor #pragma GCC diagnostic ignored "-Wunused-macro"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53920 Lewis Hyatt changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #7 from Lewis Hyatt --- Fixed for GCC 13.
[Bug preprocessor/91037] #pragma GCC diagnostic ignored "-Wunused-macros" ignored for doubly-defined macro with g++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91037 Lewis Hyatt changed: What|Removed |Added Resolution|--- |DUPLICATE CC||lhyatt at gcc dot gnu.org Status|NEW |RESOLVED --- Comment #2 from Lewis Hyatt --- Same issue as PR53431; fixed by r13-1544 *** This bug has been marked as a duplicate of bug 53431 ***
[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431 Lewis Hyatt changed: What|Removed |Added CC||f.heckenb...@fh-soft.de --- Comment #53 from Lewis Hyatt --- *** Bug 91037 has been marked as a duplicate of this bug. ***
[Bug preprocessor/97498] #pragma GCC diagnostic ignored "-Wunused-function" inconsistent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97498
Lewis Hyatt changed:
What|Removed |Added
CC||lhyatt at gcc dot gnu.org
Ever confirmed|0 |1
Last reconfirmed||2022-07-07
Status|UNCONFIRMED |NEW
--- Comment #1 from Lewis Hyatt ---
This is closely related to PR69543, but it's not quite the same. That PR is
about the use of input_location when processing a "#pragma GCC diagnostic
ignored"; this one is about the use of input_location when processing a pop
rather.
In c-pragma.cc line ~943 we call
diagnostic_pop_diagnostics (global_dc, input_location);
When processing the line:
static int f(int p) {return p + 1;} _Pragma("GCC diagnostic pop");
In C++ mode, input_location points to the _Pragma and so it works fine. In
preprocess mode (gcc -E or gcc with -save-temps), it's fine also because the
_Pragma turns into a #pragma on the next line before being actually processed.
In C mode though, input_location points to the start of the line and hence the
pop takes effect too early which leads to the issue.
It feels to me like we shouldn't use input_location anywhere in this function,
rather the location of the relevant tokens, but I am not sure all the details
of that, will see if anyone on PR69543 has ideas as well.
Here is a one-line test case that reveals the same problem with using
input_location while processing the GCC diagnostic pragma, i.e. exactly
PR69543's case:
==
static void f() {} _Pragma("GCC diagnostic error \"-Wunused-function\"")
==
Compiled without any other arguments, it works with gcc -x c++ and with gcc
-save-temps, but it fails with gcc -x c.
[Bug preprocessor/69543] [10/11/12/13 Regression] _Pragma does not apply within macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69543
Lewis Hyatt changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=97498
CC||lhyatt at gcc dot gnu.org
--- Comment #20 from Lewis Hyatt ---
See PR97498 which is closely related to this. It seems that the use of
input_location while handling diagnostic pragmas is problematic in other cases
besides the one discussed here (i.e. also when processing a diagnostic pop.)
Here is a test case from that PR, which breaks because of the input_location
workaround discussed here though:
==
static void f() {} _Pragma("GCC diagnostic error \"-Wunused-function\"")
==
The above errors for C but not C++, because in C, input_location points to the
start of the line and so it takes effect too early.
[Bug preprocessor/91733] No longer treat carriage return as an end-of-line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91733 Lewis Hyatt changed: What|Removed |Added CC||lhyatt at gcc dot gnu.org --- Comment #4 from Lewis Hyatt --- Patch to fix the diagnostics issue submitted for review here: https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598047.html
[Bug preprocessor/91733] No longer treat carriage return as an end-of-line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91733 --- Comment #6 from Lewis Hyatt --- The diagnostics issue is fixed now. Do we want to mark this resolved, or keep it open given the other question regarding support for \r line endings in general?
[Bug c++/83473] pragma problems with raw string literals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83473 Lewis Hyatt changed: What|Removed |Added CC||lhyatt at gcc dot gnu.org --- Comment #2 from Lewis Hyatt --- I have a patch waiting for review to fix PR55971 here: https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596820.html That will fix this one too.
[Bug preprocessor/97498] #pragma GCC diagnostic ignored "-Wunused-function" inconsistent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97498 --- Comment #2 from Lewis Hyatt --- Patch submitted for review here: https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598116.html
[Bug preprocessor/97498] #pragma GCC diagnostic ignored "-Wunused-function" inconsistent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97498 Lewis Hyatt changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Lewis Hyatt --- Fixed for GCC 13.
[Bug preprocessor/106252] [13 Regression] AddressSanitizer: global-buffer-overflow on address since r13-1544-ge46f4d7430c521
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106252 Lewis Hyatt changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |lhyatt at gcc dot gnu.org --- Comment #1 from Lewis Hyatt --- Thanks, and sorry about that, I will fix it now. BTW, am I missing an argument to configure or something such that I would have seen this? Or this is something external to the main testsuite?
[Bug preprocessor/106252] [13 Regression] AddressSanitizer: global-buffer-overflow on address since r13-1544-ge46f4d7430c521
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106252 Lewis Hyatt changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Lewis Hyatt --- (In reply to Martin Liška from comment #2) > It's a ASAN bootstrap that needs the following configure option: > --with-build-config=bootstrap-asan I see, thank you. It is fixed now.
[Bug c++/66290] wrong location for -Wunused-macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66290
Lewis Hyatt changed:
What|Removed |Added
CC||lhyatt at gcc dot gnu.org
--- Comment #3 from Lewis Hyatt ---
(https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598188.html)
This testcase, hopefully soon to be committed as c-c++-common/pragma-diag-15.c:
---
/* { dg-do compile } */
/* { dg-additional-options "-Wunused-macros" } */
#define X /* { dg-warning "-:-Wunused-macros" {} { xfail c++ } } */
#pragma GCC diagnostic ignored "-Wunused-macros"
---
fails for C++, I believe it's the same thing pointed out in this PR. The reason
is because of this in c_cpp_diagnostic() in c-common.cc:
---
if (done_lexing)
richloc->set_range (0, input_location, SHOW_RANGE_WITH_CARET);
---
This warning is issued at the end of compilation, when done_lexing is true.
However, input_location is not the right thing to use here, the location
provided was remembered from the time the macro was lexed, and that's the one
that needs to be used. The way it is now, input_location is at the end of the
file, and so the macro is deemed to have been defined after the #pragma.
I think this done_lexing concept was added to solve PR17964 many years ago.
Does anyone know if it's still needed, are there still cases where libcpp can
generate a diagnostic while C++ is parsing the already-lexed tokens? I have
checked anyway, that the particular testcase on PR17964 passes if done_lexing
is kept always false. I am trying the full testsuite now as well. If it can't
be removed, then I think we need some way to tell c_cpp_diagnostic not to
override a location for instances like this. Or paradoxically, we could set
done_lexing=false in c_common_finish(), which would fix it as well. It fixes
both my testcase, and the one in this original PR. Could be a reasonable fix,
perhaps combined with renaming done_lexing to something more like
override_libcpp_locations, but would be nice if it could just be removed as
well. I can look into that but perhaps Joseph knows the details here already?
diff --git a/gcc/c-family/c-opts.cc b/gcc/c-family/c-opts.cc
index b9f01a65ed7..25a3c50de8e 100644
--- a/gcc/c-family/c-opts.cc
+++ b/gcc/c-family/c-opts.cc
@@ -1283,6 +1283,7 @@ c_common_finish (void)
/* For performance, avoid tearing down cpplib's internal structures
with cpp_destroy (). */
+ done_lexing = false;
cpp_finish (parse_in, deps_stream);
if (deps_stream && deps_stream != out_stream && deps_stream != stdout
[Bug c++/66290] wrong location for -Wunused-macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66290 --- Comment #4 from Lewis Hyatt --- OK, I understand now why done_lexing is necessary, plenty of places call back into libcpp after lexing, e.g. to interpret strings, and this may generate warnings. I think that one line patch is the way to go then. diff --git a/gcc/c-family/c-opts.cc b/gcc/c-family/c-opts.cc index b9f01a65ed7..25a3c50de8e 100644 --- a/gcc/c-family/c-opts.cc +++ b/gcc/c-family/c-opts.cc @@ -1283,6 +1283,7 @@ c_common_finish (void) /* For performance, avoid tearing down cpplib's internal structures with cpp_destroy (). */ + done_lexing = false; cpp_finish (parse_in, deps_stream); if (deps_stream && deps_stream != out_stream && deps_stream != stdout
[Bug lto/106274] New: Loss of macro tracking information with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106274
Bug ID: 106274
Summary: Loss of macro tracking information with -flto
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: lhyatt at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
This is related to PR101551 but easier to demonstrate a testcase for:
===
#define X(p) p == 0
int f(void *) __attribute__((nonnull));
int f(void *p) {
return X(p);
}
When compiled without -flto, there is information on the macro expansion in the
diagnostics:
$ gcc -c t5.c -Wnonnull-compare
/home/lewis/t5.c: In function ‘f’:
/home/lewis/t5.c:1:16: warning: nonnull argument ‘p’ compared to NULL
[-Wnonnull-compare]
1 | #define X(p) p == 0
|^
/home/lewis/t5.c:4:12: note: in expansion of macro ‘X’
4 | return X(p);
|^
However, if you add -flto, you don't get the extra information:
$ gcc -c t5.c -Wnonnull-compare -flto
/home/lewis/t5.c: In function ‘f’:
/home/lewis/t5.c:1:16: warning: nonnull argument ‘p’ compared to NULL
[-Wnonnull-compare]
1 | #define X(p) p == 0
|^
The reason is that this warning is generated after the ipa_free_lang_data pass,
and that does this:
/* If we are the LTO frontend we have freed lang-specific data already. */
if (in_lto_p
|| (!flag_generate_lto && !flag_generate_offload))
{
/* Rebuild type inheritance graph even when not doing LTO to get
consistent profile data. */
rebuild_type_inheritance_graph ();
return 0;
}
...
/* Reset diagnostic machinery. */
tree_diagnostics_defaults (global_dc);
With -flto, flag_generate_lto is true, so it doesn't return early, and proceeds
to the last line, which resets the diagnostic finalizer to
default_diagnostic_finalizer, which is not aware of virtual locations.
PR101551 is about more or less the same thing except it's the other case that
prevents this function from returning early (flag_generate_offload == true). I
am not sure to what extent they are otherwise related.
Is it possible to avoid resetting the diagnostics machinery in either of these
cases? Thanks...
[Bug lto/106274] Loss of macro tracking information with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106274 --- Comment #3 from Lewis Hyatt --- (In reply to Martin Liška from comment #2) > I think it's a dup of PR80922. I think it's a bit different, if I understand correctly, PR80922 is asking for something much more difficult, it wants the LTO streaming process to be able to remember that it saw a diagnostic pragma, so that the LTO frontend can know about it when reading the data back in, and so suppress new warnings it is able to generate due to the power of the interprocedural analysis it has access to. That seems pretty challenging, given we still have a lot of bugs with just handling diagnostic pragmas properly in the non-LTO case. In my testcase here, the diagnostic is emitted by cc1/cc1plus while producing the data for LTO, not by the LTO frontend, and everything is fine with it except that it gets printed with a barebones printer, rather than a virtual location aware printer.
[Bug lto/106274] Loss of macro tracking information with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106274 --- Comment #4 from Lewis Hyatt --- (In reply to Richard Biener from comment #1) > I'm not sure to what extent this is still required with respect to the > diagnostic context though - you'd have to try. Thanks for the explanation, the general nature of it makes sense to me now. There is one current testcase (g++.dg/20090121-1.C) which demonstrates that it's not OK to simply skip calling tree_diagnostics_defaults () entirely for -flto... For that testcase, the -Wuninitialized diagnostic calling back into the C+ frontend (cp_printer) would ICE after ipa-free-lang-data pass if so. It seems like it should be doable to address this, maybe frontends could specify how they want ipa-free-lang-data to adjust their diagnostic context, so it wouldn't have to be all or nothing. I can look into that sometime, perhaps it would help with enabling this pass to run during non-LTO compilation as well.
[Bug other/93067] diagnostics are not aware of -finput-charset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93067 Lewis Hyatt changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #4 from Lewis Hyatt --- Fixed for GCC 12 by r12-3140
[Bug preprocessor/80755] __has_include_next: internal compiler error: NULL directory in find_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80755 --- Comment #6 from Lewis Hyatt --- (In reply to Sam James from comment #5) > Thank you Lewis! > > Would you mind pinging this again? > > I've just started hitting this on glibc systems too as we added a wrapper to > a libbsd header (which I'm probably going to have to drop for now). Sure, I tried... https://gcc.gnu.org/pipermail/gcc-patches/2024-February/646695.html. I think reviewers are probably focused on other things for the GCC 14 release though, I have 3 or 4 libcpp patches that have been waiting for months now, and they may not make it into 14.0 if they aren't regressions. It may help if you chime in on the gcc-patches thread as well?
[Bug preprocessor/80755] __has_include_next: internal compiler error: NULL directory in find_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80755 Lewis Hyatt changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |14.0 --- Comment #8 from Lewis Hyatt --- Fixed for GCC 14.
[Bug preprocessor/110558] __has_include argument expansion results in unexpected filename
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110558 Lewis Hyatt changed: What|Removed |Added Target Milestone|--- |14.0 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #7 from Lewis Hyatt --- Fixed for GCC 14.
[Bug c++/111918] #pragma GCC diagnostic pop does not restore error status of -Wnarrowing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111918 Lewis Hyatt changed: What|Removed |Added Target Milestone|--- |14.0 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Lewis Hyatt --- Fixed for GCC 14.
[Bug c/114423] Incorrectly placed caret in the message about expanded _Pragma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114423
Lewis Hyatt changed:
What|Removed |Added
CC||lhyatt at gcc dot gnu.org
--- Comment #2 from Lewis Hyatt ---
libcpp is unfortunately not equipped to get valid locations when it lexes from
a _Pragma string. (It thinks it is lexing from a file as normal.) The locations
are wrong even without macros involved. The current situation is that we
produce invalid locations (that happen to usually be close to reasonable,
without macros, although they will be off by a few columns usually) for all the
tokens, then after lexing the tokens, we replace all of their locations with
the (valid) location of the _Pragma operator. This is good enough to make
_Pragma("GCC diagnostic") work and do the right thing (after many bug fixes
over the years), which has been the primary focus. But it means that any
diagnostics generated by libcpp during lexing itself have bad locations.
I submitted a rather large patch series a couple years ago that fixed it
comprehensively. The bulk of it is that the line_map class needs to be able to
handle locations for data that exist in memory and not in any file. Then all
code that uses line_map locations and all diagnostics code needs to be aware of
that concept and support it. The thread was left off here, for reference:
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628290.html with the last
full patchset I sent being at
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626885.html. It worked
fine then, however a lot of interfaces have been changed since that time, and
so it would need to be rebased extensively now.
FWIW, with the above-linked patch series, on this example we output:
==
In buffer generated from t.cpp:1:
:1:11: error: message
1 | GCC error "message"
| ^
t.cpp:1:1: note: in <_Pragma directive>
1 | _Pragma("GCC error \"message\"")
| ^~~
In buffer generated from t.cpp:6:
:1:11: error: message
1 | GCC error "message"
| ^
t.cpp:4:1: note: in <_Pragma directive>
4 | _Pragma("GCC error \"message\"")
| ^~~
t.cpp:6:1: note: in expansion of macro ‘err’
6 | err
| ^~~
==
I am not sure why I stopped getting responses to that patch series. I was
disinclined to ping it further because I worried that it was perhaps deemed too
large and invasive, to fix what ends up being a rather minor problem in
practice? I think it would be doable to handle it with a more incremental
approach... we could at least achieve that diagnostics generated during lexing
get assigned to the valid location of the _Pragma operator instead of an
invalid one.
[Bug preprocessor/114436] #pragma GCC system_header vs. _Pragma("GCC system_header")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114436 Lewis Hyatt changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-03-22 Status|UNCONFIRMED |NEW CC||lhyatt at gcc dot gnu.org --- Comment #2 from Lewis Hyatt --- This should fix it correctly, will test it sometime. diff --git a/libcpp/directives.cc b/libcpp/directives.cc index 479f8c716e8..36cc762e704 100644 --- a/libcpp/directives.cc +++ b/libcpp/directives.cc @@ -1986,7 +1986,9 @@ destringize_and_run (cpp_reader *pfile, const cpp_string *in, /* Finish inlining run_directive. */ pfile->buffer->file = NULL; + const auto new_sysp = pfile->buffer->sysp; _cpp_pop_buffer (pfile); + pfile->buffer->sysp = new_sysp; /* Reset the old macro state before ... */ XDELETE (pfile->context);
[Bug preprocessor/114436] #pragma GCC system_header vs. _Pragma("GCC system_header")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114436 Lewis Hyatt changed: What|Removed |Added Keywords||patch URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2024-March/6 ||48297.html --- Comment #3 from Lewis Hyatt --- Slight variation of the above submitted for review at https://gcc.gnu.org/pipermail/gcc-patches/2024-March/648297.html
[Bug preprocessor/103902] GCC requires a space between string-literal and identifier in a literal-operator-id where the identifier is not in basic character set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103902 --- Comment #9 from Lewis Hyatt --- Thanks, sorry about that, I need to replace "unsigned long" with "size_t". Will fix it.
[Bug preprocessor/87299] #pragma GCC target behaves differently when using -save-temps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87299 Lewis Hyatt changed: What|Removed |Added CC||lhyatt at gcc dot gnu.org --- Comment #4 from Lewis Hyatt --- Patch submitted for review: https://gcc.gnu.org/pipermail/gcc-patches/2023-August/625924.html
[Bug preprocessor/90400] _Pragma not always expanded in the right location within macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90400 Lewis Hyatt changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2023-08-25 CC||lhyatt at gcc dot gnu.org Ever confirmed|0 |1 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=103165, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=102409 --- Comment #8 from Lewis Hyatt --- (In reply to Tobias Burnus from comment #7) > Regarding "-E": Actually, looking at PR103165 comment 2, I note that for the > example there 'clang -E' outputs: > > "hello; \"\" _Pragma(\"GCC diagnostic pop\") world;" > > that is: While the macros are replaced, the (unknown) _Pragma remains as > _Pragma - such that it is then later only processed when running the > compiler. > > No idea whether that makes sense or not not - just as observation. This issue was indeed fixed by r12-5454, the fix for PR103165. I will get a testcase added and then close this one. The testcase will be a tweaked version of the original one from this PR. It needs to use a different _Pragma, because nowadays, '#pragma GCC diagnostic' is recognized by the preprocessor. The existing c-c++-common/gomp/pragma-2.c provides coverage for that case. '#pragma GCC unroll' is a useful new testcase, being another pragma that is explicitly ignored during preprocess-only modes.
[Bug c++/102409] _pragma ("omp ...") expansion issue - placed in the wrong scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102409 Lewis Hyatt changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED CC||lhyatt at gcc dot gnu.org --- Comment #4 from Lewis Hyatt --- Fixed by r12-4797.
[Bug preprocessor/61474] ICE (segfault) in preprocessor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61474 Lewis Hyatt changed: What|Removed |Added CC||lhyatt at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |14.0 --- Comment #4 from Lewis Hyatt --- Thanks for the testcase, this is fixed for GCC 14.
[Bug preprocessor/90400] _Pragma not always expanded in the right location within macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90400 Lewis Hyatt changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Lewis Hyatt --- Marking it fixed now that the testcase is added.
[Bug preprocessor/91517] Pragma expansion in variadic macro reorders pragmas and breaks code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91517 Lewis Hyatt changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE CC||lhyatt at gcc dot gnu.org --- Comment #6 from Lewis Hyatt --- Same issue as bug 90400... was resolved as well by r12-5454. *** This bug has been marked as a duplicate of bug 90400 ***
[Bug preprocessor/90400] _Pragma not always expanded in the right location within macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90400 Lewis Hyatt changed: What|Removed |Added CC||paboyle at ph dot ed.ac.uk --- Comment #11 from Lewis Hyatt --- *** Bug 91517 has been marked as a duplicate of this bug. ***
[Bug preprocessor/36887] Please report #pragma GCC poison" location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36887 Lewis Hyatt changed: What|Removed |Added CC||lhyatt at gcc dot gnu.org --- Comment #4 from Lewis Hyatt --- Patch submitted for review at https://gcc.gnu.org/pipermail/gcc-patches/2023-September/630967.html
[Bug preprocessor/82335] Incorrect _Pragma expansion if macro passed to another macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82335 Lewis Hyatt changed: What|Removed |Added Last reconfirmed||2023-10-02 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||lhyatt at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=90400, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=102409 --- Comment #2 from Lewis Hyatt --- Depending which variant of the test you look at, this ended up getting resolved by r12-4797 and/or by r12-5454. It is the same issue as bug 102409 and bug 90400. The testcase from this PR seems worth adding in addition, so I will do that prior to closing this one. Patch adding the testcase submitted for review here: https://gcc.gnu.org/pipermail/gcc-patches/2023-October/631814.html
[Bug preprocessor/105608] [11/12/13/14 Regression] ICE: in linemap_add with a really long defined macro on the command line r11-338-g2a0225e47868fbfc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105608 --- Comment #2 from Lewis Hyatt --- When a PCH file is restored, the global line_maps instance is replaced with the one that was stored in the PCH file. Hence any locations that were generated prior to restoring the PCH file need to be added back to it. Currently, the only such locations that can arise will be from preprocessor directives, such as #define. The save/restore process is handled by libcpp/pch.cc and, looking over this now, it doesn't seem it makes any effort to assign valid locations when re-adding the saved macros. If the just-restored line map is at depth=0, as it is after processing the empty pch, then it produces the ICE noted here in case the first line map added is of type LC_RENAME, which happens if an ad-hoc location is needed due to the long line. However you can see the invalid locations without an ICE as well, for instance in this simpler example: $ echo -n > h.h $ cat > a.cpp #define HELLO #include "h.h" $ gcc -x c++-header -c h.h $ gcc -x c++ -c a.cpp -Wunused-macros h.h:2: warning: macro "HELLO" is not used [-Wunused-macros] Note that the warning is emitted with the wrong filename and the wrong line number. If the PCH is absent, it will be correct, but when the definition of HELLO is processed the second time after PCH restore, it comes out wrong. Fixing this issue will also fix the ICE reported here; I think it will be needed to add some more infrastructure in libcpp/pch.cc so that it can add to the line map with proper locations. I can look into it sometime. This was always incorrect AFAIK, and did not regress with r11-338-g2a0225e47868fbfc specifically; that commit did make the line number change from 1 to 2, because it handles EOF differently, and I think that caused Sergei's test case to ICE rather than be silently wrong. BTW, the issue can also be papered over by moving these 2 lines: diff --git a/gcc/c-family/c-pch.cc b/gcc/c-family/c-pch.cc index 2f014fca210..9ee6f179002 100644 --- a/gcc/c-family/c-pch.cc +++ b/gcc/c-family/c-pch.cc @@ -342,6 +342,8 @@ c_common_read_pch (cpp_reader *pfile, const char *name, gt_pch_restore (f); cpp_set_line_map (pfile, line_table); rebuild_location_adhoc_htab (line_table); + line_table->trace_includes = saved_trace_includes; + linemap_add (line_table, LC_ENTER, 0, saved_loc.file, saved_loc.line); timevar_push (TV_PCH_CPP_RESTORE); if (cpp_read_state (pfile, name, f, smd) != 0) @@ -355,9 +357,6 @@ c_common_read_pch (cpp_reader *pfile, const char *name, fclose (f); - line_table->trace_includes = saved_trace_includes; - linemap_add (line_table, LC_ENTER, 0, saved_loc.file, saved_loc.line); - /* Give the front end a chance to take action after a PCH file has been loaded. */ if (lang_post_pch_load) = With that change, you still get wrong locations for the restored macros, but the line_map state is sufficiently improved that the ICE is avoided. (The locations get assigned, as if all the macros were defined on the line following the PCH include.)
[Bug pch/115312] [14/15 Regression] ICE when including a PCH via compiler option -include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115312
Lewis Hyatt changed:
What|Removed |Added
CC||lhyatt at gcc dot gnu.org
--- Comment #1 from Lewis Hyatt ---
Hmm that is odd. It works fine on x86-64/Linux so I think this is something
target-specific with PCH? If this assert is firing:
void
c_init_preprocess ()
{
gcc_assert (!the_parser);
...
It means that the_parser was not NULL after reading in the PCH. But it should
be, because the_parser is explicitly set to NULL prior to writing the PCH (at
the end of c_parse_file() in cp/parse.cc) and so that's what it should get set
to after reading the PCH back in. Are you able to confirm whether the_parser
stored in the PCH is indeed NULL, maybe? I don't have anywhere to test this
platform myself at the moment. Thanks...
That assert could be simply removed too, but it does seem worth understanding
how it can trigger here...
[Bug c++/89038] #pragma GCC diagnostic ignored "-Wunknown-pragmas" does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89038 Lewis Hyatt changed: What|Removed |Added CC||lhyatt at gcc dot gnu.org Status|RESOLVED|NEW Resolution|DUPLICATE |--- --- Comment #6 from Lewis Hyatt --- -Wunknown-pragmas is a special case because it is emitted during preprocessing, but not directly by the preprocessor (rather from a callback in C frontend), so in the options file, it is not tagged as a preprocessor warning, and hence wasn't fixed by the mechanism introduced for PR53431. I'll submit a patch shortly: diff --git a/gcc/c-family/c-pragma.cc b/gcc/c-family/c-pragma.cc index 293311dd4ce..98dfb0f108b 100644 --- a/gcc/c-family/c-pragma.cc +++ b/gcc/c-family/c-pragma.cc @@ -963,7 +963,8 @@ handle_pragma_diagnostic_impl () /* option_string + 1 to skip the initial '-' */ unsigned int option_index = find_opt (data.option_str + 1, lang_mask); - if (early && !c_option_is_from_cpp_diagnostics (option_index)) + if (early && !(c_option_is_from_cpp_diagnostics (option_index) +|| option_index == OPT_Wunknown_pragmas)) return; if (option_index == OPT_SPECIAL_unknown)
[Bug preprocessor/82335] Incorrect _Pragma expansion if macro passed to another macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82335 Lewis Hyatt changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Lewis Hyatt --- Closing it now that the testcase has been added.
[Bug c++/89038] #pragma GCC diagnostic ignored "-Wunknown-pragmas" does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89038 Lewis Hyatt changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #10 from Lewis Hyatt --- Fixed for GCC 14 and 13.3.
[Bug preprocessor/36887] Please report #pragma GCC poison" location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36887 Lewis Hyatt changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Lewis Hyatt --- Added for GCC 14.
[Bug preprocessor/87299] #pragma GCC target behaves differently when using -save-temps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87299 Lewis Hyatt changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from Lewis Hyatt --- Fixed for GCC 14.
[Bug preprocessor/108244] [13 Regression] `pragma GCC diagnostic` and -E -fdirectives-only causes the preprocessor to become confused since r13-1544-ge46f4d7430c52104
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108244 Lewis Hyatt changed: What|Removed |Added CC||jpewhacker at gmail dot com --- Comment #13 from Lewis Hyatt --- *** Bug 91152 has been marked as a duplicate of this bug. ***
[Bug preprocessor/91152] endif-label error when using #pragma with -fdirectives-only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91152 Lewis Hyatt changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE CC||lhyatt at gcc dot gnu.org --- Comment #2 from Lewis Hyatt --- This issue eventually got dealt with when it came up again in PR 108244. The testcase c-c++-common/gomp/pr108244-3.c covers this one. *** This bug has been marked as a duplicate of bug 108244 ***
[Bug preprocessor/47254] ICE: unspellable token PRAGMA_EOL with #pragma redefine_extname and -fdirectives-only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47254 Lewis Hyatt changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=108244 Status|NEW |RESOLVED Resolution|--- |FIXED CC||lhyatt at gcc dot gnu.org --- Comment #5 from Lewis Hyatt --- This got fixed by r13-5114 (PR 108244) and is the same thing. That issue with deferred pragmas in -fdirectives-only was identified as a latent problem (revealed for diagnostic pragmas by r13-1544), and indeed this PR was there pointing to the same thing much earlier. In any case, the testcases added already (esp. c-c++-common/cpp/pr108244-2.c) provide coverage for this one too, so closing it as fixed.
[Bug preprocessor/79948] _Pragma(“GCC error”) is processed differently inside and outside of a #if directive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79948 Lewis Hyatt changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=103165 CC||lhyatt at gcc dot gnu.org Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Lewis Hyatt --- It's the same issue addressed in PR 103165, this one is most closely a dupe of PR 91517 but they are all the same underlying issue, which was fixed by r12-5454. *** This bug has been marked as a duplicate of bug 91517 ***
[Bug preprocessor/91517] Pragma expansion in variadic macro reorders pragmas and breaks code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91517 Lewis Hyatt changed: What|Removed |Added CC||duparq at free dot fr --- Comment #7 from Lewis Hyatt --- *** Bug 79948 has been marked as a duplicate of this bug. ***
[Bug pch/112319] segfault with pch and #pragma GCC diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112319 Lewis Hyatt changed: What|Removed |Added CC||lhyatt at gcc dot gnu.org Last reconfirmed||2023-10-31 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Lewis Hyatt --- Thanks, I see it (with u.h containing a #pragma GCC diagnostic as its first line). Will sort that out.
[Bug pch/112319] [14 Regression] segfault with pch and #pragma GCC diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112319 --- Comment #2 from Lewis Hyatt --- Patch sent for review: https://gcc.gnu.org/pipermail/gcc-patches/2023-November/634931.html
[Bug pch/64117] warning control #pragmas in precompiled headers are not obeyed for template code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64117 Lewis Hyatt changed: What|Removed |Added Keywords||patch Severity|normal |enhancement Last reconfirmed|2015-08-23 00:00:00 |2023-11-7 CC||lhyatt at gcc dot gnu.org URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2023-Novembe ||r/635648.html --- Comment #8 from Lewis Hyatt --- There is not currently any attempt to store the necessary information in the PCH. Here is a patch submitted for review: https://gcc.gnu.org/pipermail/gcc-patches/2023-November/635648.html
