Re: [PATCH] c-family: Improve location for -Wunknown-pragmas in a _Pragma [PR118838]

On Mon, Apr 07, 2025 at 01:58:08PM -0400, Marek Polacek wrote: > On Wed, Feb 12, 2025 at 08:27:37PM -0500, Lewis Hyatt wrote: > > Hello- > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118838 > > > > This patch addresses the issue mentioned in the PR (anoth

ping: [PATCH] c-family: Improve location for -Wunknown-pragmas in a _Pragma [PR118838]

Hello- May I please ping this patch? Thanks! https://gcc.gnu.org/pipermail/gcc-patches/2025-February/675645.html -Lewis On Wed, Feb 12, 2025 at 8:27 PM Lewis Hyatt wrote: > > Hello- > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118838 > > This patch addresses the issue m

Re: [PATCH] ggc: Avoid using ATTRIBUTE_MALLOC for allocations that need finalization [PR117047]

On Sat, Mar 1, 2025 at 3:41 AM Jakub Jelinek wrote: > --- gcc/ggc-common.cc.jj2025-01-02 11:23:32.505293652 +0100 > +++ gcc/ggc-common.cc 2025-02-28 12:12:20.207598711 +0100 > @@ -119,6 +119,25 @@ ggc_mark_roots (void) > } > > /* Allocate a block of memory, then clear it. */ > +#ifdef

Re: [committed] d: Increase max parallelism of the D testsuite

On Thu, Feb 27, 2025 at 5:11 AM Iain Buclaw wrote: > > Excerpts from Lewis Hyatt's message of Februar 26, 2025 2:04 am: > > On Tue, Feb 25, 2025 at 12:00 PM Iain Buclaw wrote: > >> > >> Hi, > >> > >> It was noticed that when running the testsuite for gdc and libphobos in > >> parallel, this was c

Re: [committed] d: Increase max parallelism of the D testsuite

On Tue, Feb 25, 2025 at 12:00 PM Iain Buclaw wrote: > > Hi, > > It was noticed that when running the testsuite for gdc and libphobos in > parallel, this was capped at 10 simultaneous jobs each. Increase this > limit to 128, which enables running for example `make check-d -j48` to > complete in ha

[PATCH] c-family: Improve location for -Wunknown-pragmas in a _Pragma [PR118838]

Hello- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118838 This patch addresses the issue mentioned in the PR (another instance of _Pragma string location issues). bootstrap + regtest all languages on aarch64 looks good. Is it OK please for now or for stage 1? Note, it is not a regression, since

[PATCH] options: Adjust cl_optimization_compare to avoid checking ICE [PR115913]

Hello- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115913#c10 This tweak to optc-save-gen.awk weakens the check performed by cl_optimization_compare() to avoid checking asserts that have been there since this function was first added in r11-1141. Is it OK for 15 please? I think it would be appro

Re: [PATCH] testsuite: libitm: Adjust how libitm.c++ passes link flags

On Fri, Jan 03, 2025 at 05:48:12PM +, Matthew Malcomson wrote: > On 1/3/25 17:14, Joseph Myers wrote: > > Does this patch cover everything dealt with by > > > > ([PATCH] testsuite: libitm: Remove build directory path from tes

[PATCH] tree-optimization: Fix ICE in tree-parloops.cc reduction_phi() [PR118205]

Hello- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118205 The PR shows that on some code involving indexing into a zero-length array in a loop, we try to look up in reduction_phi() a statement that is not a PHI. Since r15-6001, that asserts, whereas it used to return NULL, so this patch restores

[PATCH] testsuite: libitm: Remove build directory path from test names

Hello- This patch helps tools like contrib/compare_tests work out of the box for the libitm testsuite. Without this change, compare_tests complains if the test runs being compared were in different build directories. I just moved the -B argument from one place to another, so the command line exec

[PATCH] libcpp: Fix overly large buffer allocation

Hello- Happened to notice this minor issue that seems worth fixing. bootstrap + regtest on x86-64, is it OK please? Thanks! -Lewis -- >8 -- It seems that tokens_buff_new() has always been allocating the virtual location buffer 4 times larger than intended, and now that location_t is 64-bit, it

[PATCH] c++: modules: Fix 32-bit overflow with 64-bit location_t [PR117970]

Hello- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117970 This fixes one place in module.cc that I missed updating for 64-bit location_t in r15-5616. bootstrap + regtested on x86-64 + aarch64. Also verified that the regression reported on the PR is fixed on that specific configuration. OK to pus

Re: [PATCH v3 1/7] middle-end: Handle resized PHI nodes in loop_version()

On Mon, Dec 09, 2024 at 02:07:07PM +0100, Richard Biener wrote: > On Tue, Dec 3, 2024 at 2:42 PM Richard Biener > wrote: > > > > On Tue, Dec 3, 2024 at 2:07 PM Lewis Hyatt wrote: > > > > > > On Tue, Dec 03, 2024 at 01:28:28PM +0100, Richard Biener wrote: &g

Re: [PATCH v3 5/7] Support for 64-bit location_t: Activate 64-bit location_t

On Tue, Dec 3, 2024 at 7:33 AM Richard Biener wrote: > > On Mon, Dec 2, 2024 at 1:50 AM Lewis Hyatt wrote: > > > > With the codebase having already been prepared to handle it, change > > location_t to be a 64-bit integer instead of a 32-bit integer. > > OK if t

Re: [PATCH] Fix incorrect line numbers in large files bug#108900

On Fri, Dec 6, 2024 at 7:27 AM Sam James wrote: > > Jeremy Bettis writes: > > > Patch to fix known bug from > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108900 > > > > diff -ur gcc-clean/gcc-14.2.0/libcpp/files.cc gcc-14.2.0/libcpp/files.cc > > --- gcc-clean/gcc-14.2.0/libcpp/files.cc 2024-08

Re: [PATCH v3 5/7] Support for 64-bit location_t: Activate 64-bit location_t

On Tue, Dec 3, 2024 at 7:33 AM Richard Biener wrote: > > On Mon, Dec 2, 2024 at 1:50 AM Lewis Hyatt wrote: > > > > With the codebase having already been prepared to handle it, change > > location_t to be a 64-bit integer instead of a 32-bit integer. > > OK if t

Re: [PATCH v3 1/7] middle-end: Handle resized PHI nodes in loop_version()

On Tue, Dec 03, 2024 at 01:28:28PM +0100, Richard Biener wrote: > On Mon, Dec 2, 2024 at 1:55 AM Lewis Hyatt wrote: > > > > This patch is my new way to handle what was previously done in v2 patch > > 04/14, discussed at: > > https://gcc.gnu.org/pipermail/gcc-patche

Re: [PATCH v3 4/7] Support for 64-bit location_t: libgdiagnostics parts

On Mon, Dec 02, 2024 at 07:35:12PM -0500, David Malcolm wrote: > On Sun, 2024-12-01 at 19:44 -0500, Lewis Hyatt wrote: > > This patch is new in v3 and is a small change to libgdiagnostics > > similar to > > other changes required by 64-bit location_t. > >

[PATCH v3 3/7] Support for 64-bit location_t: RTL parts

This patch was previously approved in v2. I have included it unchanged here because it cannot be applied until the issue with reemit_insn_block_notes() addressed by patch v3 2/7 is resolved first. -- >8 -- Some RTL objects need to store a location_t. Currently, they store it in the rt_int field o

[PATCH v3 1/7] middle-end: Handle resized PHI nodes in loop_version()

This patch is my new way to handle what was previously done in v2 patch 04/14, discussed at: https://gcc.gnu.org/pipermail/gcc-patches/2024-November/669527.html The only places I have found running into trouble with reallocated PHI nodes (at least, the only places revealed by changing the size of

[PATCH v3 6/7] Support for 64-bit location_t: gimple parts

This patch was previously discussed here: https://gcc.gnu.org/pipermail/gcc-patches/2024-November/669437.html This version addresses that feedback, and I have also moved it in the patch ordering to be after the change to 64-bit location_t, since it would be inaccurate prior to that. -- >8 -- The

[PATCH v3 7/7] Support for 64-bit location_t: Remove -flarge-source-files

This patch was already approved in v2. I have included it here because a) It should not be applied until after the rest of the series, since the option is useful as long as location_t is 32-bit. b) The previous version neglected to regenerate common.opt.urls, which I have co

[PATCH v3 4/7] Support for 64-bit location_t: libgdiagnostics parts

This patch is new in v3 and is a small change to libgdiagnostics similar to other changes required by 64-bit location_t. -- >8 -- Tweak libgdiagnostics.cc, which is necessarily sensitive to line-map internals, to support 64-bit location_t as well. gcc/ChangeLog: * libgdiagnostics.cc (st

[PATCH v3 0/7] Support for 64-bit location_t

Hello- Here is v3 of the 64-bit location_t series. Many of the v2 patches have already been approved and pushed (those that are preparatory and don't change any functionality.) In this series, patches 3 and 7 have already been acked and should not need another review. Patches 1, 2, and 6 are revis

[PATCH v3 5/7] Support for 64-bit location_t: Activate 64-bit location_t

With the codebase having already been prepared to handle it, change location_t to be a 64-bit integer instead of a 32-bit integer. libcpp/ChangeLog: * include/cpplib.h (struct cpp_token): Adjust comment about the struct size. * include/line-map.h (location_t): Change typed

[PATCH v3 2/7] final: Fix call to INSN_LOCATION on a NOTE rtl

This patch was previously discussed at: https://gcc.gnu.org/pipermail/gcc-patches/2024-November/670354.html I have attempted to fix it per the feedback in the above thread. Note that this version is a change in behavior. In my v2 patch, I changed it so as to preserve the exact existing behavior --

Re: [PATCH 13/15] Support for 64-bit location_t: Internal parts

On Wed, Nov 27, 2024 at 09:41:13AM -0500, David Malcolm wrote: > On Wed, 2024-11-27 at 14:56 +0100, Richard Biener wrote: > > On Sun, Nov 3, 2024 at 11:28 PM Lewis Hyatt wrote: > > > > > > Several of the selftests in diagnostic-show-locus.cc and input.cc > >

Re: [PATCH 13/15] Support for 64-bit location_t: Internal parts

On Wed, Nov 27, 2024 at 8:56 AM Richard Biener wrote: > > On Sun, Nov 3, 2024 at 11:28 PM Lewis Hyatt wrote: > > > > Several of the selftests in diagnostic-show-locus.cc and input.cc are > > sensitive to linemap internals. Adjust them here so they will support 64-bit >

Re: [PATCH v2 04/14] tree-phinodes: Use 4 instead of 2 as the minimum number of phi args

On Wed, Nov 20, 2024 at 10:19:13AM +0100, Richard Biener wrote: > On Tue, Nov 19, 2024 at 5:46 PM Lewis Hyatt wrote: > > > > On Tue, Nov 19, 2024 at 9:59 AM Richard Biener > > wrote: > > > > > > On Sun, Nov 17, 2024 at 4:28 AM Lewis Hyatt wrote: > &

Re: [PATCH v2 01/14] Support for 64-bit location_t: libcpp part 1

On Wed, Nov 20, 2024 at 11:58:30AM +0100, Richard Biener wrote: > On Sun, Nov 17, 2024 at 4:24 AM Lewis Hyatt wrote: > > > > Prepare libcpp to support 64-bit location_t, without yet making > > any functional changes, by adding new typedefs that enable code to be > >

Re: [PATCH v2 04/14] tree-phinodes: Use 4 instead of 2 as the minimum number of phi args

On Tue, Nov 19, 2024 at 9:59 AM Richard Biener wrote: > > On Sun, Nov 17, 2024 at 4:28 AM Lewis Hyatt wrote: > > > > Currently, when we allocate a gphi object, we round up the capacity for the > > trailing arguments array such that it will make full use of the pag

Re: [PATCH v2 10/14] Support for 64-bit location_t: gimple parts

On Tue, Nov 19, 2024 at 10:06 AM Richard Biener wrote: > > On Sun, Nov 17, 2024 at 4:30 AM Lewis Hyatt wrote: > > > > The size of struct gimple increases by 8 bytes with the change in size of > > location_t from 32- to 64-bit; adjust the WORD markings in the comments &

Re: [PATCH v2 05/14] gimple: Handle tail padding when computing gimple_ops_offset

On Tue, Nov 19, 2024 at 9:55 AM Richard Biener wrote: > > On Sun, Nov 17, 2024 at 4:25 AM Lewis Hyatt wrote: > > > > The array gimple_ops_offset_[], which is used to find the trailing op[] > > array for a given gimple struct, is computed assuming that op[] will be > &g

[PATCH v2 09/14] Support for 64-bit location_t: C++ modules parts

Note: This patch was acked in v1 (https://gcc.gnu.org/pipermail/gcc-patches/2024-November/667608.html). The only change from that version is that #ifdef ENABLE_LARGE_SOURCE_LOCATIONS has been changed to if (sizeof (location_t) > sizeof (unsigned)) , because it was decided to remove the conf

[PATCH v2 11/14] Support for 64-bit location_t: RTL parts

Some RTL objects need to store a location_t. Currently, they store it in the rt_int field of union rtunion, but in a world where location_t could be 64-bit, they need to store it in a larger variable. Unfortunately, rtunion does not currently have a 64-bit int type for that purpose, so add one. In

[PATCH v2 12/14] Support for 64-bit location_t: Backend parts

A few targets have been using "unsigned int" function arguments that need to receive a "location_t". Change to "location_t" to prepare for the possibility that location_t can be configured to be a different type. gcc/ChangeLog: * config/aarch64/aarch64-c.cc (aarch64_resolve_overloaded_bui

[PATCH v2 13/14] Support for 64-bit location_t: Internal parts

Several of the selftests in diagnostic-show-locus.cc and input.cc are sensitive to linemap internals. Adjust them here so they will support 64-bit location_t if configured. Likewise, handle 64-bit location_t in the support for -fdump-internal-locations. As was done with the analyzer, convert to (u

[PATCH v2 01/14] Support for 64-bit location_t: libcpp part 1

Prepare libcpp to support 64-bit location_t, without yet making any functional changes, by adding new typedefs that enable code to be written such that it works with any size location_t. Update the usage of line maps within libcpp accordingly. Subsequent patches will prepare the rest of the codeba

[PATCH v2 05/14] gimple: Handle tail padding when computing gimple_ops_offset

The array gimple_ops_offset_[], which is used to find the trailing op[] array for a given gimple struct, is computed assuming that op[] will be found at sizeof(tree) bytes away from the end of the struct. This is only correct if the alignment requirement of a pointer is the same as the alignment re

[PATCH v2 14/14] Support for 64-bit location_t: Final parts

With the codebase having already been prepared to handle it, change location_t to be a 64-bit integer instead of a 32-bit integer. libcpp/ChangeLog: * include/cpplib.h (struct cpp_token): Adjust comment about the struct size. * include/line-map.h (location_t): Change typed

[PATCH v2 06/14] Support for 64-bit location_t: Frontend parts

The C/C++ frontend code contains a couple instances where a callback receiving a "location_t" argument is prototyped to take "unsigned int" instead. This will make a difference once location_t can be configured to a different type, so adjust that now. Also remove a comment about -flarge-source-fil

[PATCH v2 10/14] Support for 64-bit location_t: gimple parts

The size of struct gimple increases by 8 bytes with the change in size of location_t from 32- to 64-bit; adjust the WORD markings in the comments accordingly. It seems that most of the WORD markings were off by one already, probably not having been updated after a previous reduction in the size of

[PATCH v2 08/14] Support for 64-bit location_t: Analyzer parts

The analyzer occasionally prints internal location_t values for debugging; adjust those parts so they will work if location_t is 64-bit. For simplicity, to avoid hassling with the printf format string, just convert to (unsigned long long) in either case. gcc/analyzer/ChangeLog: * checker-

[PATCH v2 04/14] tree-phinodes: Use 4 instead of 2 as the minimum number of phi args

Currently, when we allocate a gphi object, we round up the capacity for the trailing arguments array such that it will make full use of the page size that ggc will allocate. While there is also an explicit minimum of 2 arguments, in practice after rounding to the ggc page size there is always room

[PATCH v2 07/14] Support for 64-bit location_t: toplev parts

With the move from 32-bit to 64-bit location_t, the recommended number of range bits will change from 5 to 7. line-map.h now exports the recommended setting, so use that instead of hard-coding 5. Also silently ignore -flarge-source-files, which will become unnecessary with 64-bit location_t and wo

[PATCH v2 03/14] tree-cfg: Fix call to next_discriminator_for_locus()

While testing 64-bit location_t support, I ran into an -fcompare-debug issue that was traced back here. Despite the name, next_discriminator_for_locus() is meant to take an integer line number argument, not a location_t. There is one call site which has been passing a location_t instead. For the mo

[PATCH v2 00/14] Support for 64-bit location_t

Hello- Here is an upated patch series. Most of the patches have not changed from v1. v1 thread: https://gcc.gnu.org/pipermail/gcc-patches/2024-November/667333.html The changes are: - As Richard suggested, I changed to make the feature not configurable, since it will be too hard to optimize st

[PATCH v2 02/14] libcpp: Fix potential unaligned access in cpp_buffer

libcpp makes use of the cpp_buffer pfile->a_buff to store things while it is handling macros. It uses it to store pointers (cpp_hashnode*, for macro arguments) and cpp_macro objects. This works fine because a cpp_hashnode* and a cpp_macro have the same alignment requirement on either 32-bit or 64-b

Re: [PATCH 10/15] Support for 64-bit location_t: C++ modules parts

On Tue, Nov 5, 2024 at 10:57 AM Jason Merrill wrote: > > OK. > > On 11/3/24 5:22 PM, Lewis Hyatt wrote: > > The modules implementation is necessarily sensitive to the internal workings > > of class line_map, and so it needed changes in order to handle a 64-bit > >

[PATCH 15/15] Support for 64-bit location_t: Configury parts

Add --enable-large-source-locations (off by default for now) to enable 64-bit location_t. gcc/ChangeLog: * configure.ac: Add --enable-large-source-locations. * config.in: Regenerate. * configure: Regenerate. * doc/install.texi: Document the new option. libcpp/Chan

[PATCH 13/15] Support for 64-bit location_t: Internal parts

Several of the selftests in diagnostic-show-locus.cc and input.cc are sensitive to linemap internals. Adjust them here so they will support 64-bit location_t if configured. Likewise, handle 64-bit location_t in the support for -fdump-internal-locations. As was done with the analyzer, convert to (u

[PATCH 11/15] Support for 64-bit location_t: RTL parts

Some RTL objects need to store a location_t. Currently, they store it in the rt_int field of union rtunion, but in a world where location_t could be 64-bit, they need to store it in a larger variable. Unfortunately, rtunion does not currently have a 64-bit int type for that purpose, so add one. In

[PATCH 07/15] Support for 64-bit location_t: toplev parts

The recommended bits reserved in a line_map to store ranges has always been 5, meaning that identifiers up to length 32 can be stored without generating an ad-hoc location. When 64-bit location_t is configured, there are plenty of bits to go around, and so the recommended default is larger. line-ma

[PATCH 10/15] Support for 64-bit location_t: C++ modules parts

The modules implementation is necessarily sensitive to the internal workings of class line_map, and so it needed changes in order to handle a 64-bit location_t. The changes mostly boil down to supporting that in the debug dumping routines (which is accomplished by using a new custom code %K for tha

[PATCH 04/15] tree-phinodes: Use 4 instead of 2 as the minimum number of phi args

Currently, when we allocate a gphi object, we round up the capacity for the trailing arguments array such that it will make full use of the page size that ggc will allocate. While there is also an explicit minimum of 2 arguments, in practice after rounding to the ggc page size there is always room

[PATCH 14/15] Support for 64-bit location_t: Testsuite parts

Add support to the testsuite for effective target "large_location_t" indicating if 64-bit location support has been configured. Adjust the tests that are sensitive to location_t internals so they can test large locations too. gcc/testsuite/ChangeLog: * lib/target-supports.exp (check_no_co

[PATCH 01/15] Support for 64-bit location_t: libcpp parts

This patch adds support in the libcpp line-maps infrastructure for a 64-bit location_t type that is capable of representing more source locations than the current 32-bit location_t. The support will be made configurable at build time in a subsequent patch; for now it will be off by default. libcpp

[PATCH 09/15] Support for 64-bit location_t: Frontend parts

The C/C++ frontend code contains a couple instances where a callback receiving a "location_t" argument is prototyped to take "unsigned int" instead. This will make a difference once location_t can be configured to a different type, so adjust that now. gcc/c-family/ChangeLog: * c-lex.cc (c

[PATCH 12/15] Support for 64-bit location_t: Backend parts

A few targets have been using "unsigned int" function arguments that need to receive a "location_t". Change to "location_t" to prepare for the possibility that location_t can be configured to be a different type. gcc/ChangeLog: * config/aarch64/aarch64-c.cc (aarch64_resolve_overloaded_bui

[PATCH 06/15] gimple: Handle tail padding when computing gimple_ops_offset

The array gimple_ops_offset_[], which is used to find the trailing op[] array for a given gimple struct, is computed assuming that op[] will be found at sizeof(tree) bytes away from the end of the struct. This is only correct if the alignment requirement of a pointer is the same as the alignment re

[PATCH 05/15] c++: Fix tree_contains_struct for TRAIT_EXPR

CODE_CONTAINS_STRUCT () currently reports that a TRAIT_EXPR contains a TS_EXP struct, but it does not actually start with a TS_EXP as an initial sequence. In modules.cc, when we stream out a tree, we explicitly check for the TS_EXP case and call note_location(t->exp.locus) if so. Currently, this ac

[PATCH 08/15] Support for 64-bit location_t: Analyzer parts

The analyzer occasionally prints internal location_t values for debugging; adjust those parts so they will work if location_t is 64-bit. For simplicity, to avoid hassling with the printf format string, just convert to (unsigned long long) in either case. gcc/analyzer/ChangeLog: * checker-

[PATCH 03/15] tree-cfg: Fix call to next_discriminator_for_locus()

While testing 64-bit location_t support, I ran into an -fcompare-debug issue that was traced back here. Despite the name, next_discriminator_for_locus() is meant to take an integer line number argument, not a location_t. There is one call site which has been passing a location_t instead. For the mo

[PATCH 02/15] libcpp: Fix potential unaligned access in cpp_buffer

libcpp makes use of the cpp_buffer pfile->a_buff to store things while it is handling macros. It uses it to store pointers (cpp_hashnode*, for macro arguments) and cpp_macro objects. This works fine because a cpp_hashnode* and a cpp_macro have the same alignment requirement on either 32-bit or 64-b

[PATCH 00/15] Support for 64-bit location_t

Hello- There is no shortage of PRs complaining about things that go wrong when the line_maps data structure in libcpp starts to run into its limits. Being restricted to a 32-bit location_t to cover all source locations means it has the following limitations, among others: -Column numbers larg

Re: [PATCH] diagnostics: libcpp: Improve locations for _Pragma lexing diagnostics [PR114423]

On Fri, Oct 18, 2024 at 6:21 PM David Malcolm wrote: > > On Fri, 2024-10-18 at 13:58 -0400, Lewis Hyatt wrote: > > On Fri, Oct 18, 2024 at 11:25 AM David Malcolm > > wrote: > > > >if (!pfile->cb.diagnostic) > > > > abort (); > > >

Re: [PATCH] diagnostics: libcpp: Improve locations for _Pragma lexing diagnostics [PR114423]

On Fri, Oct 18, 2024 at 11:25 AM David Malcolm wrote: > >if (!pfile->cb.diagnostic) > > abort (); > > - ret = pfile->cb.diagnostic (pfile, level, reason, richloc, > > _(msgid), ap); > > - > > - return ret; > > + if (pfile->diagnostic_override_loc && level != CPP_DL_NOTE) > > +{ > >

[PATCH] diagnostics: libcpp: Improve locations for _Pragma lexing diagnostics [PR114423]

Hello- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114423 The diagnostics we issue while lexing tokens from a _Pragma string have always come out at invalid locations. I had tried a couple years ago to fix this in a general way, but I think that ended up being too invasive a change to fix a prob

[PATCH] libcpp: Fix ICE lexing invalid raw string in a deferred pragma [PR117118]

Hello- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117118 This fixes an old regression from GCC 11. Is it OK for trunk and all backports please? Bootstrap + regtested all languages on x86-64 Linux. Thanks! -Lewis -- >8 -- The PR shows that we ICE after lexing an invalid unterminated raw strin

Re: ping: [PATCH] libcpp: Support extended characters for #pragma {push,pop}_macro [PR109704]

On Fri, Oct 11, 2024 at 08:52:45PM +, Joseph Myers wrote: > On Wed, 25 Sep 2024, Lewis Hyatt wrote: > > > Hello- > > > > May I please ping this one? Is there something maybe sub-optimal about > > how I organized it? I can adjust or break it into two maybe if t

Re: [PATCH] diagnostic: Save/restore diagnostic context history and push/pop state for PCH [PR116847]

On Fri, Sep 27, 2024 at 10:26 AM Jakub Jelinek wrote: > > On Fri, Sep 27, 2024 at 09:54:13AM -0400, Lewis Hyatt wrote: > > A couple comments that may be helpful... > > > > -This is also PR 64117 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64117) > > > > -I

Re: [PATCH] diagnostic: Save/restore diagnostic context history and push/pop state for PCH [PR116847]

On Fri, Sep 27, 2024 at 10:23 AM David Malcolm wrote: > > -I submitted a patch last year for that but did not get any response > > ( > > https://gcc.gnu.org/pipermail/gcc-patches/2023-November/635648.html). > > I guess I never pinged it because I am still trying to ping two other > > ones :). > >

Re: [PATCH] diagnostic: Save/restore diagnostic context history and push/pop state for PCH [PR116847]

On Fri, Sep 27, 2024 at 9:41 AM David Malcolm wrote: > > On Thu, 2024-09-26 at 23:28 +0200, Jakub Jelinek wrote: > > Hi! > > > > The following patch on top of the just posted cleanup patch > > saves/restores the m_classification_history and m_push_list > > vectors for PCH. Without that as the tes

ping: [PATCH] libcpp: Support extended characters for #pragma {push,pop}_macro [PR109704]

in the support for UTF-8 input, and this is I think the last one, or at least, the last obvious one. Thanks! https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642926.html -Lewis On Sun, Aug 25, 2024 at 11:45 AM Lewis Hyatt wrote: > > Hello- > > https://gcc.gnu.org/piperma

Re: ping: [PATCH] libcpp: Support extended characters for #pragma {push,pop}_macro [PR109704]

Hello- https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642926.html Monthly ping for this one please :). Thanks... -Lewis On Sat, Jul 27, 2024 at 3:09 PM Lewis Hyatt wrote: > > Hello- > > https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642926.html > > Ping ple

ping: [PATCH] libcpp: Support extended characters for #pragma {push,pop}_macro [PR109704]

Hello- https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642926.html Ping please? Jakub + Jason, hope you don't mind that I CCed you, I saw you had your attention on extended character identifiers a bit now :). Thanks! -Lewis On Fri, Jul 5, 2024 at 4:23 PM Lewis Hyatt wrote: >

ping: [PATCH] libcpp: Support extended characters for #pragma {push,pop}_macro [PR109704]

Hello- https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642926.html May I please ping this one again? It's the largest remaining gap in UTF-8 support for libcpp that I know of. Thanks! -Lewis On Tue, May 28, 2024 at 7:46 PM Lewis Hyatt wrote: > > Hello- > > May I ple

[PATCH] build: Fix "make install" for MinGW

Hello- I noticed this while trying to test another patch on Windows (using the MSYS2 environment). Tested that it fixes the issue for x86_64-w64-mingw32 and doesn't affect anything for x86_64-pc-linux-gnu. It looks like the same fix for C was applied back in r11-702. OK? Thanks... -Lewis -- >8 -

[PATCH] preprocessor: Create the parser before handling command-line includes [PR115312]

Hello- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115312 This fixes a 14.1 regression with PCH for MinGW and other platforms that don't use stdc-predef.h. Bootstrap + regtest all languages on x86-64 Linux; bootstrap + regtest c,c++ on x86_64-w64-mingw32. Is it OK for 14 branch and master please

Re: ping: [PATCH] libcpp: Support extended characters for #pragma {push,pop}_macro [PR109704]

Hello- May I please ping this one (now for GCC 15)? Thanks! https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642926.html -Lewis On Sat, Feb 10, 2024 at 9:02 AM Lewis Hyatt wrote: > > Hello- > > https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642926.html > > May

[PATCH] libcpp: Fix _Pragma("GCC system_header") [PR114436]

Hello- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114436 This is a small fix for the issue mentioned in the PR that _Pragma("GCC system_header") does not work completely. I believe it was always the case since _Pragma() support was first added. bootstrap + regtested all languages on x86-64 Linu

ping: [PATCH] diagnostics: Fix behavior of permerror options after diagnostic pop [PR111918]

https://gcc.gnu.org/pipermail/gcc-patches/2023-November/638692.html Thanks! On Fri, Feb 16, 2024 at 7:02 PM Lewis Hyatt wrote: > https://gcc.gnu.org/pipermail/gcc-patches/2023-November/638692.html > > On Thu, Jan 25, 2024 at 4:57 PM Lewis Hyatt wrote: > > > > May I please

Re: ping: [PATCH] libcpp: Fix __has_include_next ICE in the last directory of the path [PR80755]

, 2024 at 7:34 AM Lewis Hyatt wrote: > > Can I please ping this one? Thanks... > https://gcc.gnu.org/pipermail/gcc-patches/2023-December/641247.html > > -Lewis > > On Thu, Dec 21, 2023 at 7:37 AM Lewis Hyatt wrote: > > > > Hello- > > > > https

Re: [PATCH] libcpp: Improve location for macro names [PR66290]

On Thu, Feb 22, 2024 at 3:56 AM Richard Biener wrote: > > On Tue, Feb 20, 2024 at 3:33 PM Lewis Hyatt wrote: > > > > On Mon, Feb 19, 2024 at 11:36 PM Alexandre Oliva wrote: > > > > > > This backport for gcc-13 is the first of two required for the > &

Re: [PATCH] libcpp: Improve location for macro names [PR66290]

On Mon, Feb 19, 2024 at 11:36 PM Alexandre Oliva wrote: > > This backport for gcc-13 is the first of two required for the > g++.dg/pch/line-map-3.C test to stop hitting a variant of the known > problem mentioned in that testcase: on riscv64-elf and riscv32-elf, > after restoring the PCH, the locat

ping: [PATCH] diagnostics: Fix behavior of permerror options after diagnostic pop [PR111918]

CCing some global reviewers as well, in case anyone has a minute to take a look please? Thanks! https://gcc.gnu.org/pipermail/gcc-patches/2023-November/638692.html On Thu, Jan 25, 2024 at 4:57 PM Lewis Hyatt wrote: > > May I please ask again about this one? It's just a couple l

ping: [PATCH] libcpp: Support extended characters for #pragma {push,pop}_macro [PR109704]

Hello- https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642926.html May I please ping this one? Thanks! On Sat, Jan 13, 2024 at 5:12 PM Lewis Hyatt wrote: > > Hello- > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109704 > > The below patch fixes the issue noted in th

Re: [PATCH] c-family: Fix ICE with large column number after restoring a PCH [PR105608]

On Thu, Feb 1, 2024 at 7:24 AM Rainer Orth wrote: > > Hi Lewis, > > > On Fri, Jan 26, 2024 at 04:16:54PM -0500, Jason Merrill wrote: > >> On 12/5/23 20:52, Lewis Hyatt wrote: > >> > Hello- > >> > > >> > https://gcc.gnu.org/bugzill

Re: [PATCH] c-family: Fix ICE with large column number after restoring a PCH [PR105608]

On Wed, Jan 31, 2024 at 03:18:01PM -0500, Jason Merrill wrote: > On 1/30/24 21:49, Lewis Hyatt wrote: > > On Fri, Jan 26, 2024 at 04:16:54PM -0500, Jason Merrill wrote: > > > On 12/5/23 20:52, Lewis Hyatt wrote: > > > > Hello- > > > > > > > &g

Re: [PATCH] c-family: Fix ICE with large column number after restoring a PCH [PR105608]

On Fri, Jan 26, 2024 at 04:16:54PM -0500, Jason Merrill wrote: > On 12/5/23 20:52, Lewis Hyatt wrote: > > Hello- > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105608 > > > > There are two related issues here really, a regression since GCC 11 where we >

ping: [PATCH] c-family: Fix ICE with large column number after restoring a PCH [PR105608]

Hello- May I please ping this small patch? Thanks https://gcc.gnu.org/pipermail/gcc-patches/2023-December/639467.html -Lewis On Wed, Dec 20, 2023 at 8:02 PM Lewis Hyatt wrote: > > Hello- > > May I please ping this PCH patch? Thanks! > https://gcc.gnu.org/pipermail/gcc-patche

ping: [PATCH] diagnostics: Fix behavior of permerror options after diagnostic pop [PR111918]

ember/638692.html -Lewis On Mon, Jan 8, 2024 at 6:53 PM Lewis Hyatt wrote: > > Can I please ping this one again? It's 3 lines or so to fix the PR. Thanks! > https://gcc.gnu.org/pipermail/gcc-patches/2023-November/638692.html > > On Tue, Dec 19, 2023 at 6:20 PM Lewis Hy

[PATCH] libcpp: Support extended characters for #pragma {push, pop}_macro [PR109704]

Hello- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109704 The below patch fixes the issue noted in the PR that extended characters cannot appear in the identifier passed to a #pragma push_macro or #pragma pop_macro. Bootstrap + regtest all languages on x86-64 Linux. Is it OK for GCC 13 please?

ping: [PATCH] libcpp: Fix __has_include_next ICE in the last directory of the path [PR80755]

Can I please ping this one? Thanks... https://gcc.gnu.org/pipermail/gcc-patches/2023-December/641247.html -Lewis On Thu, Dec 21, 2023 at 7:37 AM Lewis Hyatt wrote: > > Hello- > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80755 > > Here is a short fix for the ICE in libc

ping^3: [PATCH] diagnostics: Fix behavior of permerror options after diagnostic pop [PR111918]

Can I please ping this one again? It's 3 lines or so to fix the PR. Thanks! https://gcc.gnu.org/pipermail/gcc-patches/2023-November/638692.html On Tue, Dec 19, 2023 at 6:20 PM Lewis Hyatt wrote: > > Hello- > > May I please ping this one? Thanks... > https://gcc.gnu.org/piperm

Re: [PATCH v2] libstdc++: Add Unicode-aware width estimation for std::format

On Sat, Jan 6, 2024 at 11:40 AM Jonathan Wakely wrote: > > Here's a V2 patch which addresses the two things I mentioned: the new > Python script now generates a complete file that can just be included by > , and the full Unicode 15.1.0 grapheme cluster break > rules are supported (I think ... more

ping: [PATCH] libcpp: Fix macro expansion for argument of __has_include [PR110558]

Hello- May I please ping this one? Thanks... https://gcc.gnu.org/pipermail/gcc-patches/2023-December/640386.html -Lewis On Tue, Dec 12, 2023 at 6:18 PM Lewis Hyatt wrote: > > Hello- > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110558 > > This is a small fix for the lib

[PATCH] libcpp: Fix __has_include_next ICE in the last directory of the path [PR80755]

Hello- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80755 Here is a short fix for the ICE in libcpp noted in the PR. Bootstrap + regtest all languages on x86-64 Linux. Is it OK please? Thanks! -Lewis -- >8 -- In libcpp/files.cc, the function _cpp_has_header(), which implements __has_include an

Re: [PATCH] c-family: Fix ICE with large column number after restoring a PCH [PR105608]

Hello- May I please ping this PCH patch? Thanks! https://gcc.gnu.org/pipermail/gcc-patches/2023-December/639467.html -Lewis On Tue, Dec 5, 2023 at 8:52 PM Lewis Hyatt wrote: > > Hello- > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105608 > > There are two related iss

ping^2: [PATCH] diagnostics: Fix behavior of permerror options after diagnostic pop [PR111918]

Hello- May I please ping this one? Thanks... https://gcc.gnu.org/pipermail/gcc-patches/2023-November/638692.html -Lewis On Wed, Nov 29, 2023 at 7:05 PM Lewis Hyatt wrote: > > On Thu, Nov 09, 2023 at 04:16:10PM -0500, Lewis Hyatt wrote: > > https://gcc.gnu.org/bugzilla/show_bug.c

  1   2   3   >