Re: [PATCH] c-family: Introduce the -Winvalid-noreturn flag from clang with extra tuneability

On 6/1/24 11:31, Julian Waters wrote: Hi Jason, Thanks for the reply! I'll address your comments soon. I have a question, if there is an option defined in c.opt as an Enum, like fstrong-eval-order, and the -no variant of the option is passed, would the Var somehow reflect the negated option? Eg

[PATCH v3 2/3] diagnostics: Don't hardcode auto_enable_urls to false for mingw hosts

Windows terminal and mintty both have support for link escape sequences, and so auto_enable_urls shouldn't be hardcoded to false. For older versions of the windows console, mingw_ansi_fputs's console API translation logic does mangle these sequences, but there's nothing useful it could do even if t

[PATCH v3 1/3] diagnostics: Enable escape sequence processing on windows consoles

Since windows 10 release v1511, the windows console has had support for VT100 escape sequences. We should try to enable this, and utilize it where possible. gcc/ChangeLog: * diagnostic-color.cc (should_colorize): Enable processing of VT100 escape sequences on windows consoles Sign

[PATCH v3 3/3] pretty-print: Don't translate escape sequences to windows console API

Modern versions of windows (after windows 10 v1511) support VT100 escape sequences, so translation for them is not necessary. The translation also mangles embedded warning documentation links. gcc/ChangeLog: * pretty-print.cc (mingw_ansi_fputs): Don't translate escape sequences if

Re: [PATCH v6 1/8] Improve must tail in RTL backend

On Mon, Jun 03, 2024 at 07:02:00PM +0200, Michael Matz wrote: > Hello, > > On Fri, 31 May 2024, Andi Kleen wrote: > > > > I think the ultimate knowledge if a call can or cannot be implemented as > > > tail-call lies within calls.cc/expand_call: It is inherently > > > target and ABI specific how

Re: [PATCH v6 1/8] Improve must tail in RTL backend

> > Yes maybe the checks could be all moved, but that's a much larger > > project. > > Hmm. I count six tests in about 25 lines of code in > tree-tailcall.cc:suitable_for_tail_opt_p and suitable_for_tail_call_opt_p. There are more checks in find_tail_calls. The logic is fairly spread out. Some

Re: [C PATCH, v3] Fix for redeclared enumerator initialized with different type [PR115109]

On Sat, 1 Jun 2024, Martin Uecker wrote: > This is a new version of the patch. I changed the overflow warning to > an error and added your other example to the test case. > > Bootstrapped and regression tested on x86_64. > > > c23: Fix for redeclared enumerator initialized with different t

Re: [PATCH] Fix -Wstringop-overflow warning in 23_containers/vector/types/1.cc PR109849

On 03/06/2024 18:20, Jonathan Wakely wrote: On Mon, 3 Jun 2024 at 05:56, François Dumont wrote: I hadn't try to make my patch as limited as possible to fix the problem, indeed. libstdc++: Fix -Wstringop-overflow warning coming from std::vector [PR109849] libstdc++-v3/ChangeLog:

Re: [PATCH 09/52] Replace {FLOAT, {, LONG_}DOUBLE}_TYPE_SIZE with new hook mode_for_floating_type

On Sun, 2 Jun 2024, Kewen Lin wrote: > +value less than or equal to mode precision of the mode used for C type > +@code{long double} (from hook @code{targetm.c.mode_for_floating_type} > +with tree_index TI_LONG_DOUBLE_TYPE). If you do not define this macro, > +mode precision of the mode used for

Re: [PATCH 06/52] m2: Replace uses of {FLOAT,{,LONG_}DOUBLE}_TYPE_SIZE

On Sun, 2 Jun 2024, Kewen Lin wrote: > diff --git a/gcc/m2/gm2-gcc/m2type.cc b/gcc/m2/gm2-gcc/m2type.cc > index 571923c08ef..d52cbdf0b99 100644 > --- a/gcc/m2/gm2-gcc/m2type.cc > +++ b/gcc/m2/gm2-gcc/m2type.cc > @@ -1420,7 +1420,7 @@ build_m2_short_real_node (void) >/* Define `REAL'. */ > >

Re: [patch] [gcn][nvptx] Add warning to mkoffload for 32bit host code

Hi! On 2024-04-25T16:07:53+0100, Andrew Stubbs wrote: > On 25/04/2024 11:51, Tobias Burnus wrote: >> Motivated by a surprise of a colleague that with -m32, >> no offload dumps were created; that's because mkoffload >> does not process host binaries when the are 32bit (i.e. ilp32). >> >> Internal

Re: [PATCH] RISC-V: Add min/max patterns for ifcvt.

On 6/3/24 11:03 AM, Palmer Dabbelt wrote: +;; Provide a minmax pattern for ifcvt to match. +(define_insn "*_cmp_3" +  [(set (match_operand:X 0 "register_operand" "=r") +    (if_then_else:X +    (bitmanip_minmax_cmp_op +    (match_operand:X 1 "register_operand" "r") +    (match_op

Re: [PATCH] Fix -Wstringop-overflow warning in 23_containers/vector/types/1.cc PR109849

On Mon, 3 Jun 2024 at 18:46, François Dumont wrote: > > > On 03/06/2024 18:20, Jonathan Wakely wrote: > > On Mon, 3 Jun 2024 at 05:56, François Dumont wrote: > >> I hadn't try to make my patch as limited as possible to fix the problem, > >> indeed. > >> > >> libstdc++: Fix -Wstringop-overfl

Re: [PATCH] RISC-V: Add min/max patterns for ifcvt.

On Mon, 03 Jun 2024 11:50:54 PDT (-0700), jeffreya...@gmail.com wrote: On 6/3/24 11:03 AM, Palmer Dabbelt wrote: +;; Provide a minmax pattern for ifcvt to match. +(define_insn "*_cmp_3" +  [(set (match_operand:X 0 "register_operand" "=r") +    (if_then_else:X +    (bitmanip_minmax_cmp_op

Re: [PATCH v7 4/9] C++: Support clang compatible [[musttail]] (PR83324)

On Mon, Jun 03, 2024 at 12:29:28PM -0400, Jason Merrill wrote: > On 6/3/24 11:44, Jakub Jelinek wrote: > > On Mon, Jun 03, 2024 at 08:33:52AM -0700, Andi Kleen wrote: > > > On Mon, Jun 03, 2024 at 10:42:20AM -0400, Jason Merrill wrote: > > > > > @@ -30316,7 +30348,7 @@ cp_parser_std_attribute (cp_p

Re: [PATCH 03/52] fortran: Replace uses of {FLOAT, {, LONG_}DOUBLE}_TYPE_SIZE

Hi, Am 03.06.24 um 05:00 schrieb Kewen Lin: Joseph pointed out "floating types should have their mode, not a poorly defined precision value" in the discussion[1], as he and Richi suggested, the existing macros {FLOAT,{,LONG_}DOUBLE}_TYPE_SIZE will be replaced with a hook mode_for_floating_type.

Re: [PATCH] libstdc++: Fix simd conversion for -fno-signed-char for Clang

On Mon, 3 Jun 2024 at 16:31, Matthias Kretz wrote: > > Tested on x86_64-linux-gnu (also -m32 and -mx32), aarch64-linux-gnu, and arm- > linux-gnueabi(hf). > > OK for trunk and backports? OK for all. > > --- 8< --- > > The special case for Clang in the trai

[PATCH] Fortran: fix ALLOCATE with SOURCE=, zero-length character [PR83865]

Dear all, the attached simple patch fixes an ICE for ALLOCATE with SOURCE= of a deferred-length character array with source-expression being an array of character with length zero. The reason was that the array descriptor of the source-expression was discarded in the special case of length 0. So

Re: [PATCH v2 1/2] libstdc++: Handle extended alignment in std::get_temporary_buffer [PR105258]

On Sat, 1 Jun 2024 at 12:23, Jonathan Wakely wrote: > > Although it's only used from places where we are allocating a sensible > size, __detail::__get_temporary_buffer should really still check that > len * sizeof(T) doesn't wrap around to zero and allocate a buffer that's > smaller than expected.

Re: [PATCH 2/2] libstdc++: Reuse temporary buffer utils in

On Sat, 1 Jun 2024 at 11:29, Jonathan Wakely wrote: > > The non-throwing allocation logic in std::stacktrace duplicates the > logic in , so we can just reuse those utilities. Pushed to trunk now. > > libstdc++-v3/ChangeLog: > > * include/std/stacktrace (basic_stacktrace::_Impl::_M_alloca

Re: [PATCH v7 4/9] C++: Support clang compatible [[musttail]] (PR83324)

On 6/3/24 15:35, Andi Kleen wrote: On Mon, Jun 03, 2024 at 12:29:28PM -0400, Jason Merrill wrote: On 6/3/24 11:44, Jakub Jelinek wrote: On Mon, Jun 03, 2024 at 08:33:52AM -0700, Andi Kleen wrote: On Mon, Jun 03, 2024 at 10:42:20AM -0400, Jason Merrill wrote: @@ -30316,7 +30348,7 @@ cp_parser_

Re: [PATCH v2] RISC-V: Add Zfbfmin extension

On 6/1/24 1:45 AM, Xiao Zeng wrote: 1 In the previous patch, the libcall for BF16 was implemented: 2 Riscv provides Zfbfmin extension, which completes the "Scalar BF16 Converts":

Re: [PATCH] Add config file so b4 uses inbox.sourceware.org automatically

On 5/23/24 9:49 AM, Jonathan Wakely wrote: It looks like my patch[1] to make b4 figure this out automagically won't be accepted, so this makes it work for GCC. A similar commit could be done for each project hosted on sourceware.org if desired. [1] https://lore.kernel.org/tools/2024052314375

Re: [patch] libgomp: Enable USM for some nvptx devices

Andrew Stubbs wrote: On 03/06/2024 17:46, Tobias Burnus wrote: Andrew Stubbs wrote: +    /* If USM has been requested and is supported by all devices +   of this type, set the capability accordingly. */ +    if (omp_requires_mask & GOMP_REQUIRES_UNIFIED_SHARED_MEMORY) + 

Re: [PATCH] rs6000: Fix up PCH in --enable-host-pie builds [PR115324]

Hi! On Mon, Jun 03, 2024 at 04:55:05PM +0200, Jakub Jelinek wrote: > PCH doesn't work properly in --enable-host-pie configurations on > powerpc*-linux*. PCH and PIE, two of my favourites ;-) > For PCH though it actually results in saving those huge arrays (one is > 130832 bytes, another 81568 by

[pushed] diagnostics: add SARIF property artifact.roles (3.24.6)

Add the property "roles" (SARIF v2.1 3.24.6) to artifacts. Populate it with: * "analysisTarget" for the top-level input file * "resultFile" for any other file a diagnostic is reported in * "tracedFile" for any file a diagnostic event is reported in Successfully bootstrapped & regrtested on x86_64

[PATCH] testsuite: analyzer: Skip tests with non-numeric macros on Solaris [PR107750]

A couple of gcc.dg/analyzer/fd-*.c tests still FAIL on Solaris. The reason is always the same: they use macros that don't expand to simple numbers, something which c/c-parser.cc (ana::c_translation_unit::consider_macro) cannot handle: * : #define SOCK_STREAM NC_TPI_COTS /* stream socket

Re: [PATCH 34/52] xtensa: Remove macros {FLOAT, DOUBLE, LONG_DOUBLE}_TYPE_SIZE

Approved On Sun, Jun 2, 2024 at 8:02 PM Kewen Lin wrote: > This is to remove macros {FLOAT,{,LONG_}DOUBLE}_TYPE_SIZE > defines in xtensa port. > > gcc/ChangeLog: > > * config/xtensa/xtensa.h (FLOAT_TYPE_SIZE): Remove. > (DOUBLE_TYPE_SIZE): Likewise. > (LONG_DOUBLE_TYPE_SI

Re: [PATCH] testsuite: analyzer: Skip tests with non-numeric macros on Solaris [PR107750]

On Mon, 2024-06-03 at 22:57 +0200, Rainer Orth wrote: > A couple of gcc.dg/analyzer/fd-*.c tests still FAIL on Solaris.  The > reason is always the same: they use macros that don't expand to > simple > numbers, something which c/c-parser.cc > (ana::c_translation_unit::consider_macro) cannot handle:

[PATCH v2 0/3] RISC-V: Add basic Zaamo and Zalrsc support

The A extension has been split into two parts: Zaamo and Zalrsc. This patch adds basic support by making the A extension imply Zaamo and Zalrsc. Zaamo/Zalrsc spec: https://github.com/riscv/riscv-zaamo-zalrsc/tags Ratification: https://jira.riscv.org/browse/RVS-1995 v2: Rebased and updated some te

[PATCH v2 1/3] RISC-V: Add basic Zaamo and Zalrsc support

The A extension has been split into two parts: Zaamo and Zalrsc. This patch adds basic support by making the A extension imply Zaamo and Zalrsc. Zaamo/Zalrsc spec: https://github.com/riscv/riscv-zaamo-zalrsc/tags Ratification: https://jira.riscv.org/browse/RVS-1995 gcc/ChangeLog: * commo

[PATCH v2 3/3] RISC-V: Add Zalrsc amo-op patterns

All amo patterns can be represented with lrsc sequences. Add these patterns as a fallback when Zaamo is not enabled. gcc/ChangeLog: * config/riscv/sync.md (atomic_): New expand pattern. (amo_atomic_): Rename amo pattern. (atomic_fetch_): New lrsc sequence pattern.

[PATCH v2 2/3] RISC-V: Add Zalrsc and Zaamo testsuite support

Convert testsuite infrastructure to use Zalrsc and Zaamo rather than A. gcc/testsuite/ChangeLog: * gcc.target/riscv/amo-table-a-6-amo-add-1.c: Use Zaamo rather than A. * gcc.target/riscv/amo-table-a-6-amo-add-2.c: Ditto. * gcc.target/riscv/amo-table-a-6-amo-add-3.c: Ditto.

Re: [Ada] Document the SuSE kernel bug

On Tue, 9 Nov 2021, Pierre-Marie de Rodat via Gcc-patches wrote: > We found a SuSE kernel bug that affects 32-bit debugging on 64-bit > machines. We agreed to document the problem in gnat_ugn. Late at catching this: Note that it's not been SuSE since 2003. Also even "SUSE 15" does not exist, I a

Re: [PATCH] Fortran: fix ALLOCATE with SOURCE=, zero-length character [PR83865]

On 6/3/24 1:12 PM, Harald Anlauf wrote: Dear all, the attached simple patch fixes an ICE for ALLOCATE with SOURCE= of a deferred-length character array with source-expression being an array of character with length zero. The reason was that the array descriptor of the source-expression was disc

Re: [PATCH v7 4/9] C++: Support clang compatible [[musttail]] (PR83324)

> > I used this variant which passes tests. It assumes that there are no > > wrapped calls with this flag, but I assume that's ok. > > musttail10.C should also check the case where the function called with > [[musttail]] returns a non-trivially-copyable class (e.g. that has a > destructor). It fa

[PATCH] aarch64: Add fix_truncv4sfv4hi2 pattern [PR113882]

This patch adds the fix_truncv4sfv4hi2 (V4SF->V4HI) pattern which is implemented using fix_truncv4sfv4si2 (V4SF->V4SI) and then truncv4siv4hi2 (V4SI->V4HI). PR target/113882 gcc/ChangeLog: * config/aarch64/aarch64-simd.md (fix_truncv4sfv4hi2): New pattern. gcc/testsuite/ChangeLo

Re: [PATCH 49/52] mips: New hook implementation mips_c_mode_for_floating_type

Kewen Lin 于2024年6月3日周一 11:03写道： > > This is to add new port specific hook implementation > mips_c_mode_for_floating_type, remove macros FLOAT_TYPE_SIZE > and DOUBLE_TYPE_SIZE, rename LONG_DOUBLE_TYPE_SIZE to > MIPS_LONG_DOUBLE_TYPE_SIZE since we poison LONG_DOUBLE_TYPE_SIZE > but some subtarget wa

[PATCH 0/3] Add support for -mcpu=power11

The following 3 patches add support for -mcpu=power11 to GCC 15. Assuming these patches are approved and go into GCC 15, I will need to back port them to GCC 14. The first patch adds the basic support for -mcpu=power11, except for the scheduling infomration. The second patch goes through power10

[PATCH 2/3] Add tuning support for power11

This patch makes -mtune=power11 use the same tuning decisions as -mtune=power10. It needs the previous patch to be applied. I have bootstrapped these patches on both little endian and big endian systems. Can I check these changes into the GCC 15 trunk. After a waiting period, can I check these p

Re: [PATCH 47/52] loongarch: New hook implementation loongarch_c_mode_for_floating_type

Ok! Thanks! Lulu Cheng 在 2024/6/3 上午11:01, Kewen Lin 写道: This is to add new port specific hook implementation loongarch_c_mode_for_floating_type, remove macro defines for FLOAT_TYPE_SIZE and DOUBLE_TYPE_SIZE, and rename LONG_DOUBLE_TYPE_SIZE to LA_LONG_DOUBLE_TYPE_SIZE as we poison LONG_DOUBLE_

[PATCH 1/3] Add support for -mcpu=power11

This patch adds the power11 option to the -mcpu= and -mtune= switches. This patch treats the power11 like a power10 in terms of costs and reassociation width. This patch issues a ".machine power11" to the assembly file if you use -mcpu=power11. This patch defines _ARCH_PWR11 if the user uses -mc

[PATCH 3/3] Add power11 tests

This patch adds some simple tests for -mcpu=power11 support. In order to run these tests, you need an assembler that supports the appropriate option for supporting the Power11 processor (-mpower11 under Linux or -mpwr11 under AIX). I have bootstrapped these patches on both little endian and big e

[PATCH] [x86] Adjust testcase for -march=cascadelake

Commit as an obvious patch. gcc/testsuite/ChangeLog: PR target/115299 * gcc.target/i386/pr86722.c: Also scan for blendvpd. --- gcc/testsuite/gcc.target/i386/pr86722.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/testsuite/gcc.target/i386/pr86722.c b/gc

Re: [PATCH v2 1/3] RISC-V: Add basic Zaamo and Zalrsc support

Hi Patrick: One dumb question around Zaamo and Zalrsc, could we still got correct atomic semantic with only Zaamo or only Zalrsc? I guess Zalrsc only probably ok, but how about Zaamo only? And another question around authorship: I notice you are listed as co-authored, and signed off by Edwin, but

[PATCH 02/52 v2] d: Replace use of LONG_DOUBLE_TYPE_SIZE

Hi Iain, on 2024/6/3 22:39, Iain Buclaw wrote: > Excerpts from Kewen.Lin's message of Juni 3, 2024 10:57 am: >> Hi Iain, >> >> on 2024/6/3 16:40, Iain Buclaw wrote: >>> Excerpts from Kewen Lin's message of Juni 3, 2024 5:00 am: Joseph pointed out "floating types should have their mode, n

Re: [PATCH 06/52] m2: Replace uses of {FLOAT,{,LONG_}DOUBLE}_TYPE_SIZE

Hi Joseph and Gaius, on 2024/6/4 02:02, Joseph Myers wrote: > On Sun, 2 Jun 2024, Kewen Lin wrote: > >> diff --git a/gcc/m2/gm2-gcc/m2type.cc b/gcc/m2/gm2-gcc/m2type.cc >> index 571923c08ef..d52cbdf0b99 100644 >> --- a/gcc/m2/gm2-gcc/m2type.cc >> +++ b/gcc/m2/gm2-gcc/m2type.cc >> @@ -1420,7 +1420

RE: [r15-983 Regression] FAIL: gcc.target/i386/avx10_1-25.c (test for excess errors) on Linux/x86_64

The fail is expected since -march=cascadelake -mavx10.1-256 will lead to a warning. Also, we could not use -mno-avx512f with -mavx10.1-256, which also lead to a warning. > -Original Message- > From: haochen.jiang > Sent: Monday, June 3, 2024 10:22 PM > To: Jiang, Haochen ; gcc-regress..

[PATCH 09/52 v2] Replace {FLOAT, {, LONG_}DOUBLE}_TYPE_SIZE with new hook mode_for_floating_type

Hi Joseph, on 2024/6/4 01:59, Joseph Myers wrote: > On Sun, 2 Jun 2024, Kewen Lin wrote: > >> +value less than or equal to mode precision of the mode used for C type >> +@code{long double} (from hook @code{targetm.c.mode_for_floating_type} >> +with tree_index TI_LONG_DOUBLE_TYPE). If you do not

Re: [PATCH] fix PowerPC < 7 w/ Altivec not to default to power7

Hi Rene, on 2024/5/31 22:57, Rene Rebe wrote: > Hi Kewen, > > thank you for your reply. > >> on 2024/3/8 19:33, Rene Rebe wrote: >>> This might not be the best timing -short before a major release-, >>> however, Sam just commented on the bug I filled years ago [1], so here >>> we go: >>> >>> Gli

Re: [PATCH 3/13 ver 3] rs6000, fix error in unsigned vector float to unsigned int built-in definition

Hi, on 2024/5/29 23:56, Carl Love wrote: > This patch was updated per the feedback comment from the previous version in > series 2. > > Carl > --- > > rs6000, fix error in unsigned vector float to unsi

Re: [PATCH 7/13 ver 3] rs6000, add overloaded vec_sel with int128 arguments

Hi, on 2024/5/30 00:03, Carl Love wrote: > This was patch 6 in the previous series. Updated the documentation file per > the comments. No functional changes to the patch. > > Carl > > > rs6000, add overloa

Re: [PATCH 8/13 ver 3] rs6000, remove the vec_xxsel built-ins, they are, duplicates

Hi, on 2024/5/30 00:05, Carl Love wrote: > This was patch 7 in the previous series. Patch was updated to address the > feedback comments. > > Carl > > > rs6000, remove the vec_xxsel built-ins,

Re: [PATCH 9/13 ver 3] rs6000, remove __builtin_vsx_vperm_* built-ins

Hi, on 2024/5/30 00:06, Carl Love wrote: > This was patch 8 in the previous series. Updated patch per the feedback > comments. > > Carl > > > rs6000, remove __builtin_vsx_vperm_* built-ins > > Th

Re: [PATCH 11/13 ver 3] rs6000, extend vec_xxpermdi built-in for __int128 args

Hi, on 2024/5/30 00:10, Carl Love wrote: > This was patch 10 from the previous series. The patch was updated to > address feedback comments. > > Carl > --- > > rs6000, extend vec_xxpermdi built-in for __int128 args >

Re: [PATCH 13/13 ver 3] rs6000, remove vector set and vector init built-ins.

Hi, on 2024/5/30 00:16, Carl Love wrote: > This was patch 13 from the previous series. Note the previous series patch > 12 was dropped. This patch is the same as the previous version. The > additional work to remove __builtin_vec_set_v1ti, __builtin_vec_set_v2di, > __builtin_vec_set_v2d pe

Re: [PATCH 12/13 ver 3] rs6000, remove __builtin_vsx_xvcmpeqsp_p built-in

Hi Carl, on 2024/5/30 00:11, Carl Love wrote: > This was patch 11 from the previous series. Patch was updated to address > feedback comments. > >Carl > -- > > rs6000, remove __builtin_vsx_xvcmpeqsp_p built-in > >

Re: [PATCH 1/13 ver 3] rs6000, Remove __builtin_vsx_cmple* builtins

Hi Carl, on 2024/5/29 23:52, Carl Love wrote: > This patch was approved in the previous series. There are no changes to this > patch. Reposting for completeness. I guess you can just push the approved ones, as there is no dependency between any two of them? It can help to reduce the size of

Re: [PATCH 5/13 ver 3] rs6000, Remove redundant float/double type conversions

Hi, on 2024/5/30 00:00, Carl Love wrote: > This is a new patch to removed the built-ins that were inadvertently missing > in the previous series. > > Carl > -- > > rs6000, Remove redundant float/double ty

Re: [PATCH 07/52] darwin: Replace use of LONG_DOUBLE_TYPE_SIZE

Hi Kewen, > On 3 Jun 2024, at 04:00, Kewen Lin wrote: > > Joseph pointed out "floating types should have their mode, > not a poorly defined precision value" in the discussion[1], > as he and Richi suggested, the existing macros > {FLOAT,{,LONG_}DOUBLE}_TYPE_SIZE will be replaced with a > hook mo

[PATCH] builtins: Force SAVE_EXPR for __builtin_{add,sub,mul}_overflow and __builtin{add,sub}c [PR108789]

Hi! The following testcase is miscompiled, because we use save_expr on the .{ADD,SUB,MUL}_OVERFLOW call we are creating, but if the first two operands are not INTEGER_CSTs (in that case we just fold it right away) but are TREE_READONLY/!TREE_SIDE_EFFECTS, save_expr doesn't actually create a SAVE_E

[PATCH] c: Fix up pointer types to may_alias structures [PR114493]

Hi! The following testcase ICEs in ipa-free-lang, because the fld_incomplete_type_of gcc_assert (TYPE_CANONICAL (t2) != t2 && TYPE_CANONICAL (t2) == TYPE_CANONICAL (TREE_TYPE (t))); assertion doesn't hold. This is because t is a struct S * type which was created whi

[PATCH] rs6000: Decrease code size of rs6000_init_generated_builtins [PR115324]

On Mon, Jun 03, 2024 at 03:40:38PM -0500, Segher Boessenkool wrote: > > So, either we'd need to add some further GTY extensions, or the following > > patch instead reworks it such that the fntype members which were the only > > reason for PCH in those arrays are moved to separate arrays. > > And t

<    1   2