Hello-
Ping please? Thanks.
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/613247.html
-Lewis
On Tue, May 2, 2023 at 9:27 AM Lewis Hyatt wrote:
>
> May I please ping this one? Thanks...
> https://gcc.gnu.org/pipermail/gcc-patches/2023-March/613247.html
>
> On Thu, Mar 2, 2023 at 6:21 PM L
On Fri, Mar 24, 2023 at 9:04 PM David Malcolm via Gcc-patches
wrote:
>
> PR analyzer/109098 notes that the SARIF spec mandates that .sarif
> files are UTF-8 encoded, but -fdiagnostics-format=sarif-file naively
> assumes that the source files are UTF-8 encoded when quoting source
> artefacts in the
May I please ping this patch again? I think it would be worthwhile to
close this gap in the support for UTF-8 sources. Thanks!
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/613247.html
-Lewis
On Fri, Jun 2, 2023 at 9:45 AM Lewis Hyatt wrote:
>
> Hello-
>
> Ping please? Thanks.
> https://g
These tests need to use "size_t" rather than "unsigned long"
for the user-defined literal function arguments.
gcc/testsuite/ChangeLog:
PR preprocessor/103902
* g++.dg/cpp0x/udlit-extended-id-1.C: Change "unsigned long" to
"size_t" throughout.
* g++.dg/cpp0x/udlit-e
Hello-
This is an update to the v2 patch series last sent in January:
https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609473.html
While I did not receive any feedback on the v2 patches yet, they did need some
rebasing on top of other recent commits to input.cc, so I thought it would be
hel
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:
* diagnostic-format
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 ignor
Add a new linemap reason LC_GEN which enables encoding the location of data
that was generated during compilation and does not appear in any source file.
There could be many use cases, such as, for instance, referring to the content
of builtin macros (not yet implemented, but an easy lift after thi
May I please ping this?
I am just about ready with the followup patch that fixes PR87299, but
it depends on this one. Thanks!
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/623364.html
-Lewis
On Fri, Jun 30, 2023 at 6:59 PM Lewis Hyatt wrote:
>
> In order to support processing #pragma in pr
On Wed, Jul 26, 2023 at 5:36 PM Jason Merrill wrote:
>
> On 6/30/23 18:59, Lewis Hyatt wrote:
> > In order to support processing #pragma in preprocess-only mode (-E or
> > -save-temps for gcc/g++), we need a way to obtain the #pragma tokens from
> > libcpp. In full compilation modes, this is accom
In order to support processing #pragma in preprocess-only mode (-E or
-save-temps for gcc/g++), we need a way to obtain the #pragma tokens from
libcpp. In full compilation modes, this is accomplished by calling
pragma_lex (), which is a symbol that must be exported by the frontend, and
which is cur
On Thu, Jul 27, 2023 at 06:18:33PM -0700, Jason Merrill wrote:
> On 7/27/23 18:59, Lewis Hyatt wrote:
> > In order to support processing #pragma in preprocess-only mode (-E or
> > -save-temps for gcc/g++), we need a way to obtain the #pragma tokens from
> > libcpp. In full compilation modes, this i
On Fri, Jul 28, 2023 at 6:22 PM David Malcolm wrote:
>
> On Fri, 2023-07-21 at 19:08 -0400, Lewis Hyatt wrote:
> > Hello-
> >
> > This is an update to the v2 patch series last sent in January:
> > https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609473.html
> >
> > While I did not receive an
On Fri, Jul 28, 2023 at 6:58 PM David Malcolm wrote:
>
> On Fri, 2023-07-21 at 19:08 -0400, Lewis Hyatt wrote:
> > Add a new linemap reason LC_GEN which enables encoding the location
> > of data
> > that was generated during compilation and does not appear in any
> > source file.
> > There could b
`#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
if the target pragma defines any macros, those macros are not effective in
preprocess-only mode. Similarly, such macros are not effective when
co
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:
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 back
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
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
diagnost
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 impre
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: Fi
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 meantim
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"
>
> > --- a/libgomp/tes
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
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
$ make
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 impre
> 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-
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
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 t
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 release
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)
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 not
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
> m
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
chang
On Tue, Aug 1, 2023 at 11:01 AM Joseph Myers wrote:
>
> On Mon, 31 Jul 2023, Lewis Hyatt via Gcc-patches wrote:
>
> > I added some additional testcases from the PR for x86. The other targets
> > that support `#pragma GCC target' (aarch64, arm, nios2, powerpc, s390)
>
On Mon, Jul 31, 2023 at 06:39:15PM -0400, Lewis Hyatt wrote:
> On Fri, Jul 28, 2023 at 6:58 PM David Malcolm wrote:
> >
> > On Fri, 2023-07-21 at 19:08 -0400, Lewis Hyatt wrote:
> > > Add a new linemap reason LC_GEN which enables encoding the location
> > > of data
> > > that was generated during
The previous patch in this series introduced the concept of LC_GEN line
maps. This patch continues on the path to using them to improve _Pragma
diagnostics, by adding a new source_id SRC member to struct
expanded_location, which is populated by linemap_expand_location. This
member allows call sites
Add a new linemap reason LC_GEN which enables encoding the location of data
that was generated during compilation and does not appear in any source file.
There could be many use cases, such as, for instance, referring to the content
of builtin macros (not yet implemented, but an easy lift after thi
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:
* diagnostic-format
This patch enhances location_get_source_line(), which is the primary
interface provided by the diagnostics infrastructure to obtain the line of
source code corresponding to a given location, so that it understands
generated data locations in addition to normal file-based locations. This
involves ch
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 subsequent patch to support obtaining the source code from
in-memory generated buffers rather than from a file. The present patch
refact
Add selftests for the new capabilities in input.cc related to source code
locations that are stored in memory rather than ordinary files.
gcc/ChangeLog:
* input.cc (temp_source_file::do_linemap_add): New function.
(line_table_case::line_table_case): Add GENERATED_DATA argument.
Previous patches in this series have laid the groundwork for supporting
source code locations in memory ("generated data") rather than ordinary
files. This patch completes the support by adding awareness of such
locations to all places that need to support them. The main changes are to
diagnostic-s
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 ignor
On Fri, Aug 11, 2023 at 06:45:31PM -0400, David Malcolm wrote:
> On Wed, 2023-08-09 at 18:14 -0400, Lewis Hyatt wrote:
>
> Hi Lewis, thanks for the patch...
>
> > Add a new linemap reason LC_GEN which enables encoding the location of data
> > that was generated during compilation and does not app
On Fri, Aug 11, 2023 at 07:02:49PM -0400, David Malcolm wrote:
> On Wed, 2023-08-09 at 18:14 -0400, Lewis Hyatt wrote:
> > The previous patch in this series introduced the concept of LC_GEN line
> > maps. This patch continues on the path to using them to improve _Pragma
> > diagnostics, by adding a
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 subse
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 correspondin
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(), whic
May I please ping this one? FWIW, it's 10 months old now without any feedback.
https://gcc.gnu.org/pipermail/gcc-patches/2022-December/607647.html
Most of the changes are just adapting the testsuite to look for the
improved diagnostic location. Otherwise it's a handful of lines in
libcpp and it ju
In order to support processing #pragma in preprocess-only mode (-E or
-save-temps for gcc/g++), we need a way to obtain the #pragma tokens from
libcpp. In full compilation modes, this is accomplished by calling
pragma_lex (), which is a symbol that must be exported by the frontend, and
which is cur
'libcpp/include/symtab.h:struct ht_identifier':
>
> On 2022-10-18T18:14:54-0400, Lewis Hyatt via Gcc-patches
> wrote:
> > When a GTY'ed struct is streamed to PCH, any plain char* pointers it
> > contains
> > (whether they live in GC-controlled memory or no
On Wed, Feb 15, 2023 at 1:39 PM Jason Merrill wrote:
>
> On 9/26/22 15:27, Lewis Hyatt wrote:
> > 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=103
The PR complains that we do not handle UTF-8 in the suffix for a user-defined
literal, such as:
bool operator ""_π (unsigned long long);
In fact we don't handle any extended identifier characters there, whether
UTF-8, UCNs, or the $ sign. We do handle it fine if the optional space after
the "" to
Hello-
May I please ping this short patch that fixes an old bug? Thanks...
-Lewis
On Sat, Jan 14, 2023 at 1:46 PM Lewis Hyatt wrote:
>
> get__Pragma_string() in directives.cc is responsible for lexing the parens
> and the string argument from a _Pragma("...") operator. This function does
> not
On Fri, Nov 04, 2022 at 10:03:13AM +0100, Jakub Jelinek via Gcc-patches wrote:
> Hi!
>
> The following pseudo-patch (for uname2c.h part
> just a pseudo patch with a lot of changes replaced with ...
> because it is too large but the important changes like
> -static const char uname2c_dict[59418] =
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 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 we
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 comp
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! So
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
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 inlin
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 disc
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-
https://gcc.gnu.org/bugzilla/show_bug.
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 track
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 f
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,
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 ge
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 just
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_
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:
https://gcc.gnu.org/pipermail/gcc-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!
He
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:
> > htt
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 patch
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
Par
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, 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!
> >
> > https
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 suppor
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 (_cpp_valid_utf
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 thoug
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:
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=
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 co
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
preproc
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/
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 l
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:
* diagnostic-format
Add a new linemap reason LC_GEN which enables encoding the location of data
that was generated during compilation and does not appear in any source file.
There could be many use cases, such as, for instance, referring to the content
of builtin macros (not yet implemented, but an easy lift after thi
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 ignor
https://gcc.gnu.org/pipermail/gcc-patches/2022-December/607647.html
May I please ping this one again? It will enable closing out the PR. Thanks!
-Lewis
On Thu, Dec 1, 2022 at 9:22 AM Lewis Hyatt wrote:
>
> Hello-
>
> https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599397.html
>
> May I ple
get__Pragma_string() in directives.cc is responsible for lexing the parens
and the string argument from a _Pragma("...") operator. This function does
not handle the case when the closing paren is not on the same line as the
string; in that case, libcpp will by default reuse the token buffer it
prev
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 Hy
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:
1 - 100 of 153 matches
Mail list logo
