Great, thank you very much for taking a look at it. Sorry if this
email is unnecessary noise, but it wasn't quite clear to me whether
this should also still be approved from a content perspective? I
didn't want to assume. Thanks!
-Lewis
On Sat, Mar 7, 2020 at 6:23 PM Gerald Pfeifer wrote:
>
>
Hello David-
I would appreciate hearing your thoughts please on the following
(relatively minor) issue... There is a little bug with colorization in
diagnostics: in case a location only points to the first byte of a
multibyte sequence, the colorization produces corrupted output as it
interrupts
Hello-
Currently, if an option is both undocumented and an alias for a second option,
the help text generated by gcc --help directs the reader to use the other
option instead. This makes sense for deprecated options, but it seems this
pattern is also used for another case, namely when an option
On Fri, Mar 13, 2020 at 01:24:07AM +, Joseph Myers wrote:
> On Thu, 30 Jan 2020, Lewis Hyatt wrote:
>
> > Is this something that would be desirable to change for GCC 10? Attached
> > patch would do so, and the output would become instead:
>
> This patch is OK. (It may mean some translation
On Wed, Mar 11, 2020 at 9:12 AM Lewis Hyatt wrote:
> On Sat, Mar 7, 2020 at 6:23 PM Gerald Pfeifer wrote:
> >
> > On Tue, 25 Feb 2020, Lewis Hyatt wrote:
> > > Just checking whether the below is OK for gcc 10 changes.html please.
> > > Thanks!
> > >
On Tue, Mar 17, 2020 at 11:52:13AM +, Richard Sandiford wrote:
> Lewis Hyatt writes:
> > On Mon, Mar 16, 2020 at 06:11:08PM +, Richard Sandiford wrote:
> >> Lewis Hyatt via Gcc-patches writes:
> > ...
> >> > FWIW there are three other optio
at 06:11:08PM +0000, Richard Sandiford wrote:
> > > > > > Lewis Hyatt via Gcc-patches writes:
> > > > > ...
> > > > > > > FWIW there are three other options currently affected by this
> > > > > > > change
> > > > >
On Mon, Mar 16, 2020 at 06:11:08PM +, Richard Sandiford wrote:
> Lewis Hyatt via Gcc-patches writes:
...
> > FWIW there are three other options currently affected by this change
> > (-Wimplicit-fallthrough, -fcf-protection, and -flive-patching). The change
> > for
>
On Mon, Mar 16, 2020 at 6:11 PM Lewis Hyatt wrote:
> Regarding -Wmissing-format-attribute, that is an interesting case, it's the
> only
> instance in any *.opt that has an = sign in the Alias target. If I understand
> correctly, this one can't use the 3-argument form of Alias() because
>
On Fri, Jan 31, 2020 at 03:31:59PM -0500, David Malcolm wrote:
> On Fri, 2020-01-31 at 14:31 -0500, Lewis Hyatt wrote:
> > Hello-
> >
> > Here is the second patch that I mentioned when I submitted the other
> > related
> > patch (which is awaiting review):
> >
On Tue, Oct 6, 2020 at 11:09 AM David Malcolm wrote:
>
> I've taken the liberty of pushing this website patch, having checked
> that it validates.
>
> It covers the changes by Lewis in 004bb936d6d5f177af26ad4905595e843d5665a5
> (PR 49973 and PR 86904).
>
Cool, thank you for mentioning it here!
On Tue, Aug 18, 2020 at 09:43:31AM +0100, Jonathan Wakely wrote:
> On 13/08/20 18:15 -0400, Lewis Hyatt via Libstdc++ wrote:
> > Hello-
> >
> > The attached patch was discussed briefly on PR 54185 here:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54185#c14
> > The test case for this PR
Hello-
The attached patch updates cpp_wcwidth() (for computation of display
widths needed to calculate column numbers in diagnostics) from Unicode 12
to Unicode 13. The patch was purely mechanical, following the directions
in contrib/unicode/README without any unexpected hiccups. A couple
Hello-
The attached patch was discussed briefly on PR 54185 here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54185#c14
The test case for this PR sometimes fails due to random failures in
pthread_create() that are not related to the original PR. This patch fixes
it up by ignoring those failures.
Hello-
Attached is the patch I mentioned in another discussion here:
https://gcc.gnu.org/pipermail/gcc-patches/2020-August/551442.html
This adds a new option -fdiagnostics-plain-output that currently means the
same thing as:
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
On Fri, Jul 24, 2020 at 02:49:36PM +0100, Richard Sandiford wrote:
> Lewis Hyatt via Gcc-patches writes:
> > On Thu, Jul 23, 2020 at 05:47:28PM -0400, David Malcolm wrote:
> >> On Thu, 2020-07-23 at 12:28 -0400, Lewis Hyatt via Gcc-patches wrote:
> >> > Hello-
>
Hello-
May I please ping you about this patch? Thanks!
https://gcc.gnu.org/pipermail/gcc-patches/2020-June/547900.html
-Lewis
On Thu, Jun 11, 2020 at 11:26:28AM -0400, Lewis Hyatt wrote:
> On Wed, Jun 10, 2020 at 12:11:00PM -0400, David Malcolm wrote:
> > Thanks for the patch; sorry about the
On Mon, Jul 13, 2020 at 03:04:20PM -0400, David Malcolm wrote:
> > +@item -fdiagnostics-column-unit=@var{UNIT}
> > +@opindex fdiagnostics-column-unit
> > +Select the units for the column number. This affects traditional
> > diagnostics
> > +(in the absence of @option{-fno-show-column}), as well
May I please ping this patch?
https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545426.html
Thanks!
-Lewis
On Fri, May 08, 2020 at 03:35:25PM -0400, Lewis Hyatt wrote:
> On Fri, Jan 31, 2020 at 03:31:59PM -0500, David Malcolm wrote:
> > On Fri, 2020-01-31 at 14:31 -0500, Lewis Hyatt wrote:
> >
On Wed, Jun 10, 2020 at 12:11:00PM -0400, David Malcolm wrote:
> Thanks for the patch; sorry about the delay in reviewing it.
>
> Some high-level review points
>
> - I like the patch overall
>
> - This will deserve an item in the release notes
>
> - I don't like adding "global_tabstop" (I
Hello-
The attached patch is complete including docs, but I tagged as RFC
because I am not sure if anyone will like it, or if the general reaction may
be closer to recoiling in horror :). Would appreciate your thoughts,
please...
Currently, if a UTF-8 locale is detected, GCC changes the quote
On Thu, Jul 23, 2020 at 05:47:28PM -0400, David Malcolm wrote:
> On Thu, 2020-07-23 at 12:28 -0400, Lewis Hyatt via Gcc-patches wrote:
> > Hello-
> >
> > The attached patch is complete including docs, but I tagged as RFC
> > because I am not sure if anyone will
On Wed, Aug 12, 2020 at 12:54 PM Richard Sandiford
wrote:
>
> Lewis Hyatt writes:
> > Hello-
> >
> > Attached is the patch I mentioned in another discussion here:
> > https://gcc.gnu.org/pipermail/gcc-patches/2020-August/551442.html
> >
> > This adds a new option -fdiagnostics-plain-output that
Hello-
The attached patch addresses PR93067:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93067#c0
This is similar to the patch I posted last year on the PR, with some tweaks
to make it a little simpler. Recapping some of the commentary on the PR:
When source lines are needed for diagnostics
On Thu, Nov 19, 2020 at 07:16:52PM +, Jonathan Wakely wrote:
> On 19/11/20 12:57 -0500, Lewis Hyatt via Libstdc++ wrote:
> > Hello-
> >
> > PR61369 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61369) points out
> > that std::discrete_distribution can return an event even if it has 0
> >
On Thu, Jul 23, 2020 at 05:47:28PM -0400, David Malcolm wrote:
> On Thu, 2020-07-23 at 12:28 -0400, Lewis Hyatt via Gcc-patches wrote:
> > Hello-
> >
> > The attached patch is complete including docs, but I tagged as RFC
> > because I am not sure if anyone will
On Fri, Nov 13, 2020 at 5:27 PM Jeff Law wrote:
>
>
> On 1/14/20 5:05 PM, Lewis Hyatt wrote:
> > Hello-
> >
> > I thought I might ping this short patch please, just in case it may
> > make sense to include in GCC 10 along with the other UTF-8-related
> > fixes to diagnostics. Thanks!
> >
> >
Hello-
PR61369 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61369) points out
that std::discrete_distribution can return an event even if it has 0
probability, and proposes a simple fix. It seems that this fix was never
applied, because there was an expectation of redoing this code anyway to
use
On Fri, Nov 6, 2020 at 12:46 PM Jeff Law wrote:
>
>
> On 10/23/20 9:01 AM, Lewis Hyatt via Gcc-patches wrote:
> > Hello-
> >
> > The attached patch updates cpp_wcwidth() (for computation of display
> > widths needed to calculate column numbers in diagnostics)
On Thu, Jan 14, 2021 at 4:34 PM David Malcolm via Gcc-patches
wrote:
...
> > One remaining issue raised in that Emacs bug is the encoding of these
> > lines, and, indeed, the encoding of GCC's stderr in general:
> > currently we emit a mixture of bytes and UTF-8; I believe we emit
> > filenames
On Tue, May 18, 2021 at 5:31 AM Iain Buclaw wrote:
>
> Excerpts from Lewis Hyatt via Gcc-patches's message of January 29, 2021 4:46
> pm:
> > Q1: What is the input charset?
> > A1:
> >
> > libcpp: Whatever was passed to -finput-charset (note, for Fortran,
> > -finput-charset is not
Hi David-
I thought this might be a good opportunity to ask about the patch that
supports -finput-charset in diagnostic.c please?
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/564527.html
The patch will require some work to adapt to the new changes below. I
am happy to do that, but
Hi David-
With GCC 11 released now, I thought it might be a good time to ping this patch
that supports -finput-charset for diagnostics please?
[https://gcc.gnu.org/pipermail/gcc-patches/2021-January/564527.html]
Patch still applies to master, and tests still look good as before. If you
have any
On Tue, Jan 26, 2021 at 04:02:52PM -0500, David Malcolm wrote:
> On Fri, 2020-12-18 at 18:03 -0500, Lewis Hyatt wrote:
> > Hello-
> >
> > The attached patch addresses PR93067:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93067#c0
> >
> > This is similar to the patch I posted last year on the
Hello-
I thought it might be a good time to check on this patch please? Thanks!
https://gcc.gnu.org/pipermail/gcc-patches/2021-July/576449.html
-Lewis
On Fri, Jul 30, 2021 at 4:13 PM Lewis Hyatt wrote:
>
> On Fri, Jan 29, 2021 at 10:46:30AM -0500, Lewis Hyatt wrote:
> > On Tue, Jan 26, 2021 at
On Wed, Aug 25, 2021 at 9:45 AM David Malcolm wrote:
> > BTW, do you think it would be worthwhile to work on the other half of
> > encoding support, i.e. translating from UTF-8 to the user's locale,
> > when outputting diagnostics? I have probably 90% of a patch that does
> > this, however it
On Tue, Aug 24, 2021 at 6:51 PM David Malcolm wrote:
>
> On Tue, 2021-08-24 at 08:17 -0400, Lewis Hyatt wrote:
> > Hello-
> >
> > I thought it might be a good time to check on this patch please?
> > Thanks!
> > https://gcc.gnu.org/pipermail/gcc-patches/2021-July/576449.html
> >
> > -Lewis
>
> I
On Fri, Jan 29, 2021 at 10:46:30AM -0500, Lewis Hyatt wrote:
> On Tue, Jan 26, 2021 at 04:02:52PM -0500, David Malcolm wrote:
> > On Fri, 2020-12-18 at 18:03 -0500, Lewis Hyatt wrote:
> > > Hello-
> > >
> > > The attached patch addresses PR93067:
> > >
On Thu, Oct 7, 2021 at 9:01 AM Jakub Jelinek via Gcc-patches
wrote:
> And another thing, if HOST_CHARSET == HOST_CHARSET_EBCDIC, how does the
> libcpp/lex.c
> static const cppchar_t utf8_signifier = 0xC0;
> ...
> if (*buffer->cur >= utf8_signifier)
> {
> if
Hello-
As discussed on PR c++/53431, currently "#pragma GCC diagnostic" does
not always take effect for diagnostics generated by libcpp. The reason
is that libcpp itself does not interpret this pragma and only sends it on
to the frontend, hence the pragma is only honored if the frontend
arranges
Hello-
I would like please to follow up on this patch submitted for PR53431 here:
https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586191.html
However, it was suggested on the PR that part of it could be split into a
separate simpler patch. I have now done that, and also made a few tweaks
Hello-
Here is part 2/2 of the patch version 2 introduced here:
https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587357.html
to resolve PR53431. Thank you!
-Lewis
>From 79dfa93ff94bbf492b396d1e6b3d06f1f95a6315 Mon Sep 17 00:00:00 2001
From: Lewis Hyatt
Date: Sat, 4 Dec 2021 11:20:00
Hello-
This fixes an old PR, bootstrap + regtest on x86-64 Linux. Please let me know
if it's ok? Thanks!
-Lewis
-- >8 --
As noted in the PR, GCC will segfault if a file name is first seen in a
linemarker directive, and then later seen in a normal #include. This is
because the fake include
On Tue, Aug 8, 2023 at 5:53 PM Jason Merrill wrote:
>
> On 7/31/23 22:22, Lewis Hyatt via Gcc-patches wrote:
> > `#pragma GCC target' is not currently handled in preprocess-only mode (e.g.,
> > when running gcc -E or gcc -save-temps). As noted in the PR, this means that
> &
Hello-
May I please ping this one? It's adding a testcase prior to closing
the PR. Thanks!
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628488.html
-Lewis
On Fri, Aug 25, 2023 at 4:46 PM Lewis Hyatt wrote:
>
> Hello-
>
> This is adding a testcase for a PR that was already incidentally
On Tue, Aug 15, 2023 at 04:08:47PM -0400, Lewis Hyatt wrote:
> On Tue, Aug 15, 2023 at 3:46 PM David Malcolm wrote:
> >
> > On Tue, 2023-08-15 at 14:15 -0400, Lewis Hyatt wrote:
> > > On Tue, Aug 15, 2023 at 12:15:15PM -0400, David Malcolm wrote:
> > > > On Wed, 2023-08-09 at 18:14 -0400, Lewis
On Tue, Aug 15, 2023 at 03:39:40PM -0400, David Malcolm wrote:
> On Tue, 2023-08-15 at 13:58 -0400, Lewis Hyatt wrote:
> > On Tue, Aug 15, 2023 at 11:43:05AM -0400, David Malcolm wrote:
> > > On Wed, 2023-08-09 at 18:14 -0400, Lewis Hyatt wrote:
> > > > Class file_cache_slot in input.cc is used to
Hello-
This is adding a testcase for a PR that was already incidentally fixed. OK
to commit please? Thanks...
-Lewis
-- >8 --
The PR was fixed by r12-5454. Since the fix was somewhat incidental,
although related, add a testcase from PR90400 too before closing it out.
gcc/testsuite/ChangeLog:
On Tue, Aug 15, 2023 at 01:04:04PM -0400, David Malcolm wrote:
> On Wed, 2023-08-09 at 18:14 -0400, Lewis Hyatt wrote:
> > The diagnostics routines for SARIF output need to read the source code back
> > in, so that they can generate "snippet" and "content" records, so they need
> > to
> > be able
On Tue, Aug 15, 2023 at 11:43:05AM -0400, David Malcolm wrote:
> On Wed, 2023-08-09 at 18:14 -0400, Lewis Hyatt wrote:
> > Class file_cache_slot in input.cc is used to query specific lines of source
> > code from a file when needed by diagnostics infrastructure. This will be
> > extended in a
On Tue, Aug 15, 2023 at 12:15:15PM -0400, David Malcolm wrote:
> On Wed, 2023-08-09 at 18:14 -0400, Lewis Hyatt wrote:
> > This patch enhances location_get_source_line(), which is the primary
> > interface provided by the diagnostics infrastructure to obtain the line of
> > source code
On Tue, Aug 15, 2023 at 3:46 PM David Malcolm wrote:
>
> On Tue, 2023-08-15 at 14:15 -0400, Lewis Hyatt wrote:
> > On Tue, Aug 15, 2023 at 12:15:15PM -0400, David Malcolm wrote:
> > > On Wed, 2023-08-09 at 18:14 -0400, Lewis Hyatt wrote:
> > > > This patch enhances location_get_source_line(),
Hello-
Now that we're back in stage 1, I thought it might be a better time to
ask for feedback on this pair of patches that tries to resolve PR53431
please?
https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587357.html
https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587358.html
Hello-
https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595556.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431#c49
Would a C++ maintainer have some time to take a look at this patch
please? I feel like the PR is still worth resolving. If this doesn't
seem like a good way, I am happy to
Hello-
The PR (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91733) points out that,
while libcpp recognizes a lone '\r' as a valid line-ending character, the
infrastructure that obtains source lines to be printed in diagnostics does
not, and hence diagnostics do not output the intended portion of
On Fri, Jul 1, 2022 at 3:59 PM Jason Merrill wrote:
>
> On 6/29/22 12:59, Jason Merrill wrote:
> > On 6/23/22 13:03, Lewis Hyatt via Gcc-patches wrote:
> >> Hello-
> >>
> >> https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595556.html
> >> https:
Hello-
PR97498 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97498) is another PR
related to the fact that imprecise locations for _Pragma result in
counterintuitive behavior for GCC diagnostic pragmas, which inhibit the
ability to make convenient wrapper macros for enabling and disabling
On Sat, Jul 9, 2022 at 11:59 PM Jeff Law via Gcc-patches
wrote:
>
>
>
> On 7/9/2022 2:52 PM, Lewis Hyatt via Gcc-patches wrote:
> > Hello-
> >
> > PR97498 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97498) is another PR
> > related to the fact that im
Re-sending this without the large attachment, since it was rejected by the
list. The second attachment was just the Unicode data files to be added:
ftp://ftp.unicode.org/Public/UNIDATA/DerivedNormalizationProps.txt
ftp://ftp.unicode.org/Public/UNIDATA/DerivedCoreProperties.txt
Thanks!
-Lewis
On Fri, Jun 24, 2022 at 3:26 PM Joseph Myers wrote:
>
> On Fri, 24 Jun 2022, David Malcolm via Gcc-patches wrote:
>
> > > BTW, is this something simple enough I should just commit it without
> > > bugging
> > > the list for approval?
> >
> > The patch seems reasonable to me, but Joseph seems to
Hello-
As discussed here:
https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598136.html
Here is another short patch that improves "#pragma GCC diagnostic" handling.
Longer term, it will be desirable to make the handling of this pragma
independent of the global input_location. But in the
Hello-
PR106252 notes an error found by the address sanitizer from r13-1544. This was
my mistake during refactoring of handle_pragma_diagnostic(), the check
for the option arg was moved earlier than it should be. Committed the obvious
fix putting this back where it was before.
-Lewis
c-family:
On Tue, Jul 12, 2022 at 2:33 AM Thomas Schwinge wrote:
>
> Hi!
>
> On 2022-07-11T11:27:12+0200, I wrote:
> > [...], I've just pushed to master branch
> > commit 06b2a2abe26554c6f9365676683d67368cbba206
> > "Enhance '_Pragma' diagnostics verification in OMP C/C++ test cases"
>
> > ---
On Fri, Jul 01, 2022 at 08:23:53PM -0400, Jason Merrill wrote:
> On 7/1/22 18:05, Lewis Hyatt wrote:
> > On Fri, Jul 1, 2022 at 3:59 PM Jason Merrill wrote:
> > >
> > > On 6/29/22 12:59, Jason Merrill wrote:
> > > > On 6/23/22 13:03, Lewis Hyatt
On Wed, Jul 6, 2022 at 2:17 PM Jason Merrill wrote:
>> On 7/6/22 10:23, Lewis Hyatt wrote:
> > Here is an updated patch addressing all your comments, thanks again for the
> > review. Regarding the idea about rewinding tokens, it seems potentially
> > problematic to try to make use of libcpp's
On Tue, Jun 14, 2022 at 05:26:49PM -0400, Lewis Hyatt wrote:
> Hello-
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103902
>
> The attached patch resolves PR preprocessor/103902 as described in the patch
> message inline below. bootstrap + regtest all languages was successful on
> x86-64
Hello-
The attached fixes PR preprocessor/55971:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55971
, which is the issue that we don't currently allow raw string literals
containing embedded newlines to appear in #define. With the patch, they can be
used in any preprocessing directive.
While I
Hello-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103902
The attached patch resolves PR preprocessor/103902 as described in the patch
message inline below. bootstrap + regtest all languages was successful on
x86-64 Linux, with no new failures:
FAIL 103 103
PASS 542338 542371
UNSUPPORTED 15247
Hello-
The attached patch upgrades the cpp_wcwidth() function (needed for
computing display columns in diagnostics output) from Unicode 13 to
Unicode 14. I just mechanically followed the procedure in
contrib/unicode/README with nothing unexpected coming up. I attached it
compressed since it's a
Hello-
May I please ping these two preprocessor patches?
For PR103902:
https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596704.html
For PR55971:
https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596820.html
Thanks!
-Lewis
On Sat, Jul 9, 2022 at 11:59 PM Jeff Law via Gcc-patches
wrote:
>
>
>
> On 7/9/2022 2:52 PM, Lewis Hyatt via Gcc-patches wrote:
> > Hello-
> >
> > PR97498 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97498) is another PR
> > related to the fact that im
> Hi Lewis,
>
> Thanks! Good spot. I think it should be calling dg-runtest however,
> same as what libphobos.cycles/cycles.exp is doing. Could also fix the
> test name so each one is unique, just to hit two birds in one -
> something like the following would suffice (haven't had time to check).
>
Hello-
I get a different number of test results from libphobos.unittest/unittest.exp,
depending on server load. I believe it's because this testsuite doesn't check
runtest_file_p:
$ make -j 1 RUNTESTFLAGS='unittest.exp' check-target-libphobos | grep '^#'
# of expected passes 10
$
On Tue, Jul 12, 2022 at 9:10 AM Tobias Burnus wrote:
> On 12.07.22 13:50, Lewis Hyatt via Gcc-patches wrote:
> > On Tue, Jul 12, 2022 at 2:33 AM Thomas Schwinge
> > wrote:
> >> On 2022-07-11T11:27:12+0200, I wrote:
> >>> Oh my, PR101551 "[o
In C++, since all tokens are lexed from libcpp up front, diagnostics generated
by libcpp after lexing has completed do not get a valid location from libcpp
(rather, libcpp thinks they all pertain to the end of the file.) This has long
been addressed using the global variable "done_lexing", which
Hello-
This backport from r13-1596 to GCC 12 has been committed after
pre-approval. This was a straightforward cherry-pick from master with no
adjustments needed. I would like to note that subsequent to r13-1596, Thomas
made a few commits to the libgomp testsuite to test for new diagnostic
On Tue, Aug 16, 2022 at 9:50 AM Lewis Hyatt wrote:
>
> On Wed, Jul 20, 2022 at 8:56 PM Lewis Hyatt wrote:
> >
> > Hello-
> >
> > May I please ping these two preprocessor patches?
> >
> > For PR103902:
> > https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596704.html
> >
> > For PR55971:
> >
The function rebuild_location_adhoc_htab() was meant to reconstruct the
adhoc location hash map after restoring a line_maps instance from a
PCH. However, the function has never performed as intended because it
missed the last step of adding the data into the newly reconstructed hash
map. This
On Wed, Jun 15, 2022 at 03:06:16PM -0400, Lewis Hyatt wrote:
> On Tue, Jun 14, 2022 at 05:26:49PM -0400, Lewis Hyatt wrote:
> > Hello-
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103902
> >
> > The attached patch resolves PR preprocessor/103902 as described in the patch
> > message
When a GTY'ed struct is streamed to PCH, any plain char* pointers it contains
(whether they live in GC-controlled memory or not) will be marked for PCH
output by the routine gt_pch_note_object in ggc-common.cc. This routine
special-cases plain char* strings, and in particular it uses strlen() to
On Wed, Oct 19, 2022 at 8:23 AM Jakub Jelinek wrote:
>
> On Wed, Oct 19, 2022 at 01:17:02PM +0100, Richard Sandiford wrote:
> > Jakub Jelinek writes:
> > > On Wed, Oct 19, 2022 at 12:54:11PM +0100, Richard Sandiford via
> > > Gcc-patches wrote:
> > &g
Currently, the ipa-free-lang-data pass resets most of the frontend's
diagnostic customizations, such as the diagnostic_finalizer that prints macro
expansion information, which is the subject of the two PRs. In most cases,
however, there is no need to reset these customizations; they still work
On Tue, Oct 25, 2022 at 7:35 AM Richard Biener
wrote:
>
> On Thu, Oct 20, 2022 at 1:09 AM Lewis Hyatt via Gcc-patches
> wrote:
> >
> > Currently, the ipa-free-lang-data pass resets most of the frontend's
> > diagnostic customizations, such as the diagnostic_final
Hello-
May I please ask for a review of this patch from June? I realize it's a
10-year-old PR that doesn't seem to be bothering people much, but I still feel
like it's an unfortunate gap in C++11 support that is not hard to fix.
Original submission is here:
Hello-
https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599397.html
May I please ping this patch? Thank you.
-Lewis
On Fri, Aug 5, 2022 at 12:14 PM Lewis Hyatt wrote:
>
>
> When libcpp reports diagnostics whose locus is a macro name (such as for
> -Wunused-macros), it uses the location in
Warnings issued for -Wuninitialized have been using the spelling location of
the problematic usage, discarding any information on the location of the macro
expansion point if such usage was in a macro. This makes the warnings
impossible to control reliably with #pragma GCC diagnostic, and also
Hello-
https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599397.html
Since Jeff was kind enough to ack one of my other preprocessor patches
today, I have become emboldened to ping this one again too :). Would
anyone have some time to take a look at it please? Thanks!
-Lewis
On Thu, Sep 15,
This PR related to _Pragma locations and diagnostic pragmas was fixed by a
combination of r10-325 and r13-1596. Add missing test coverage.
gcc/testsuite/ChangeLog:
PR c/91669
* c-c++-common/pr91669.c: New test.
---
Notes:
Hello-
The token_streamer class (which implements gcc mode -E and
-save-temps/-no-integrated-cpp) needs to keep track whether the last tokens
output were in a system header, so that it can generate line marker
annotations as necessary for a downstream consumer to reconstruct the
state. The logic for
When libcpp reports diagnostics whose locus is a macro name (such as for
-Wunused-macros), it uses the location in the cpp_macro object that was
stored by _cpp_new_macro. This is currently set to pfile->directive_line,
which contains the line number only and no column information. This patch
On Wed, Jul 20, 2022 at 8:56 PM Lewis Hyatt wrote:
>
> Hello-
>
> May I please ping these two preprocessor patches?
>
> For PR103902:
> https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596704.html
>
> For PR55971:
> https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596820.html
>
> Thanks!
On Sat, Jul 30, 2022 at 7:06 PM Tom Honermann via Gcc-patches
wrote:
>
> On 7/27/22 7:09 PM, Joseph Myers wrote:
> > On Sun, 24 Jul 2022, Tom Honermann via Gcc-patches wrote:
> >
> >> Gcc's '#pragma GCC diagnostic' directives are processed in "early mode"
> >> (see handle_pragma_diagnostic_early)
On Sat, Jul 30, 2022 at 10:43 PM Jeff Law wrote:
> > There was a request to backport this
> > (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97498#c7) since it is
> > relevant to this one:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106267. Is that OK as
> > well for any of the current
On Mon, Aug 01, 2022 at 07:15:48PM -0400, Lewis Hyatt wrote:
> Hello-
>
> This backport from r13-1596 to GCC 12 has been committed after
> pre-approval. This was a straightforward cherry-pick from master with no
> adjustments needed. I would like to note that subsequent to r13-1596, Thomas
>
libcpp's directives-only mode does not expect deferred pragmas to be
registered, but to date the c-family registration process has not checked for
this case. That issue became more visible since r13-1544, which added the
commonly used GCC diagnostic pragmas to the set of those registered in
On Thu, Nov 17, 2022 at 4:21 PM Lewis Hyatt wrote:
>
> On Sat, Nov 05, 2022 at 12:23:28PM -0400, David Malcolm wrote:
> > On Fri, 2022-11-04 at 09:44 -0400, Lewis Hyatt via Gcc-patches wrote:
> > [...snip...]
> > >
> > > diff --git a/gcc/c-family/c-common.cc b/
Class edit_context handles outputting fixit hints in diff form that could be
manually or automatically applied by the user. This will not make sense for
generated data locations, such as the contents of a _Pragma string, because
the text to be modified does not appear in the user's input files. We
The diagnostics routines for SARIF output need to read the source code back
in, so that they can generate "snippet" and "content" records, so they need to
be able to cope with generated data locations. Add support for that in
diagnostic-format-sarif.cc.
gcc/ChangeLog:
*
Hello-
This series contains the four remaining patches in the series originally
sent here:
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/605029.html
which implements improved locations for tokens lexed from a string inside a
_Pragma directive.
v2 1/4: diagnostics: libcpp: Add LC_GEN
Currently, the tokens obtained from a destringified _Pragma string do not get
assigned proper locations while they are being lexed. After the tokens have
been obtained, they are reassigned the same location as the _Pragma token,
which is sufficient to make things like _Pragma("GCC diagnostic
1 - 100 of 153 matches
Mail list logo
