Re: [committed] libstdc++: Add std::is_scoped_enum for C++23

On Fri, Mar 19, 2021 at 3:13 PM Jonathan Wakely via Libstdc++ wrote: > > Implement this C++23 feature, as proposed by P1048R1. > > This implementation assumes that a C++23 compiler supports concepts > already. I don't see any point in using preprocessor hacks to detect > compilers which define __c

Re: fix ssse3_pshufbv8qi3 post-reload const pool load

On Fri, Mar 19, 2021 at 07:44:01PM -0300, Alexandre Oliva wrote: > > Testcase? > > Uhh, sorry I failed to mention that. > > gcc.target/i386/pr94467-1.c was what I used (with -mcmodel=large) to > duplicate the problem and then confirm the fix in the trunk. > > However, I had a total of 15 similar

Re: fix ssse3_pshufbv8qi3 post-reload const pool load

On Mar 19, 2021, Uros Bizjak wrote: >> * config/i386/predicates.md (register_or_const_vec_operand): >> New. >> * config/i386/sse.md (ssse3_pshufbv8qi3): Add an expander for >> the now *-prefixed insn_and_split, turn the splitter const vec >> into an input for the insn, making it an ignored immedi

Re: [PATCH] rs6000: Fix some unexpected empty split conditions

On Fri, Mar 19, 2021 at 11:50:41PM +0800, Kewen.Lin wrote: > > I am curious if the splitters ever triggered where they should not have? > > Do you have any suggestion to catch this? I thought the regression > testing probably can show something different but it didn't unfortunately. Well, you ca

Re: [PATCH] c: FIx up -Wunused-but-set-* warnings for _Atomics [PR99588]

On Fri, 19 Mar 2021, Jakub Jelinek via Gcc-patches wrote: > Hi! > > As the following testcases show, compared to -D_Atomic= case we have many > -Wunused-but-set-* warning false positives. > When an _Atomic variable/parameter is read, we call mark_exp_read on it in > convert_lvalue_to_rvalue, but

Re: [PATCH] c++: Diagnose references to void in structured bindings [PR99650]

On 3/19/21 12:49 PM, Jakub Jelinek via Gcc-patches wrote: On Fri, Mar 19, 2021 at 02:17:39PM -0400, Jason Merrill wrote: --- gcc/cp/decl.c.jj2021-03-16 21:17:41.014498713 +0100 +++ gcc/cp/decl.c 2021-03-18 19:31:22.430149523 +0100 @@ -8629,6 +8629,11 @@ cp_finish_decomp (tree decl, tre

[wwwdocs] Document std::is_scoped_enum support

Pushed to wwwdocs. commit 3aca43b28c04f6d0c7f446bafcd2f539a2eec5b0 Author: Jonathan Wakely Date: Fri Mar 19 20:12:01 2021 + Document std::is_scoped_enum support diff --git a/htdocs/gcc-11/changes.html b/htdocs/gcc-11/changes.html index 9734eee8..99fb9d8f 100644 --- a/htdocs/gcc-11/chan

[committed] libstdc++: Add std::is_scoped_enum for C++23

Implement this C++23 feature, as proposed by P1048R1. This implementation assumes that a C++23 compiler supports concepts already. I don't see any point in using preprocessor hacks to detect compilers which define __cplusplus to a post-C++20 value but don't support concepts yet. libstdc++-v3/Chan

Re: [patch, fortran] Also use size estimate for vector-matrix matmul

Yes Ok for trunk. Thanks much! On 3/19/21 10:37 AM, Thomas Koenig via Fortran wrote: Hell world, here is the patch I talked about earlier.  It passes regression testing. OK for trunk? Best regards Thomas Add size check to vector-matrix matmul. It turns out the library version is much

[PATCH v4 6/7] RISC-V: Fix matches against subreg with a bytenum of 0 in riscv.md

These all intend the least significant subpart of the register. Use the same endian-neutral "subreg_lowpart_operator" predicate that ARM does instead. gcc/ * config/riscv/predicates.md (subreg_lowpart_operator): New predicate * config/riscv/riscv.md (*addsi3_extended2, *subsi3_exte

[PATCH v4 7/7] RISC-V: Fix riscv_subword() for big endian

gcc/ * config/riscv/riscv.c (riscv_subword): Take endianness into account when calculating the byte offset. --- gcc/config/riscv/riscv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/config/riscv/riscv.c b/gcc/config/riscv/riscv.c index 1cd795bd19c..2f624e

[PATCH v4 5/7] RISC-V: Update shift-shift-5.c testcase for big endian

gcc/ * testsuite/gcc.target/riscv/shift-shift-5.c (sub): Change order of struct fields depending on byteorder. --- gcc/testsuite/gcc.target/riscv/shift-shift-5.c | 4 1 file changed, 4 insertions(+) diff --git a/gcc/testsuite/gcc.target/riscv/shift-shift-5.c b/gcc/testsuite/

[PATCH v4 4/7] RISC-V: Fix trampoline generation on big endian

gcc/ * config/riscv/riscv.c (riscv_swap_instruction): New function to byteswap an SImode rtx containing an instruction. (riscv_trampoline_init): Byteswap the generated instructions when needed. --- gcc/config/riscv/riscv.c | 19 +++ 1 file changed, 1

[PATCH v4 3/7] RISC-V: Update soft-fp config for big-endian

libgcc/ * config/riscv/sfp-machine.h (__BYTE_ORDER): Set according to __BYTE_ORDER__. --- libgcc/config/riscv/sfp-machine.h | 4 1 file changed, 4 insertions(+) diff --git a/libgcc/config/riscv/sfp-machine.h b/libgcc/config/riscv/sfp-machine.h index db2697157ce..8adbf4b8b2e

[PATCH v4 2/7] RISC-V: Add riscv{32,64}be with big endian as default

gcc/ * common/config/riscv/riscv-common.c (TARGET_DEFAULT_TARGET_FLAGS): Set default endianness. * config.gcc (riscv32be-*, riscv64be-*): Set TARGET_BIG_ENDIAN_DEFAULT to 1. * config/riscv/elf.h (LINK_SPEC): Change -melf* value depending on default en

[PATCH v4 1/7] RISC-V: Support -mlittle-endian and -mbig-endian

gcc/ * config/riscv/elf.h (LINK_SPEC): Pass linker endianness flag. * config/riscv/freebsd.h (LINK_SPEC): Likewise. * config/riscv/linux.h (LINK_SPEC): Likewise. * config/riscv/riscv.h (ASM_SPEC): Pass -mbig-endian and -mlittle-endian. (BYTES_BIG_ENDI

[PATCH v4 0/7] RISC-V big endian support

New update of the RISC-V big endian support. Changes since v3: * Changed riscv_subword to take endianness into account. This fixed multiple issues with long long on 32-bit. Testsuite results are now on par with little endian also on 32 bit. The only exception is gcc.c-torture/

Re: [PATCH] Complete __gnu_debug::basic_string

On 16/03/21 21:55 +0100, François Dumont via Libstdc++ wrote: Following: https://gcc.gnu.org/pipermail/libstdc++/2021-March/052158.html Here is the patch to complete __gnu_debug::basic_string support. Contrarily to what I thought code in std::basic_string to generate a basic_string_view works

[COMMITTED] [PR99663] Don't use unknown constraint for address constraint in process_address_1.

The following patch solves https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99663 The patch was successfully bootstrapped and tested on x86-64. commit d81019db099ad95febbb2d4b4afd8cbe95762062 Author: Vladimir N. Makarov Date: Fri Mar 19 15:34:48 2021 -0400 [PR99663] Don't use unknown constr

Re: [PATCH] c++: Diagnose references to void in structured bindings [PR99650]

On Fri, Mar 19, 2021 at 02:17:39PM -0400, Jason Merrill wrote: > > --- gcc/cp/decl.c.jj2021-03-16 21:17:41.014498713 +0100 > > +++ gcc/cp/decl.c 2021-03-18 19:31:22.430149523 +0100 > > @@ -8629,6 +8629,11 @@ cp_finish_decomp (tree decl, tree first, > > : get_tuple_ele

Re: [PATCH] c++: Diagnose references to void in structured bindings [PR99650]

On 3/19/21 5:53 AM, Jakub Jelinek wrote: Hi! We ICE on the following testcase, because std::tuple_element<...,...>::type is void and for structured bindings we therefore need to create void & or void && which is invalid. We created such REFERENCE_TYPE and later ICEd in the middle-end. The follo

[patch, fortran] Also use size estimate for vector-matrix matmul

Hell world, here is the patch I talked about earlier. It passes regression testing. OK for trunk? Best regards Thomas Add size check to vector-matrix matmul. It turns out the library version is much faster for vector-matrix multiplications for large sizes than what inlining can prod

Re: [PATCH] c++: Only reject reinterpret casts from pointers to integers for manifestly_const_eval evaluation [PR99456]

On 3/19/21 5:03 AM, Jakub Jelinek wrote: On Thu, Mar 18, 2021 at 05:20:54PM -0400, Jason Merrill wrote: On 3/9/21 10:31 AM, Jakub Jelinek wrote: Hi! My PR82304/PR95307 fix moved reinterpret cast from pointer to integer diagnostics from cxx_eval_outermost_constant_expr where it caught invalid c

RE: [PATCH] arm: Fix MVE ICEs with vector moves and -mpure-code [PR97252]

Hi Alex, > -Original Message- > From: Alex Coplan > Sent: 19 March 2021 16:45 > To: gcc-patches@gcc.gnu.org > Cc: ni...@redhat.com; Richard Earnshaw ; > Ramana Radhakrishnan ; Kyrylo > Tkachov > Subject: [PATCH] arm: Fix MVE ICEs with vector moves and -mpure-code > [PR97252] > > Hi all,

Re: [PATCH] ubsan: Don't test for NaNs if those do not exist (PR97926)

On 3/19/2021 9:12 AM, Segher Boessenkool wrote: Tested on powerpc64-linux {-m32,-m64}. No regressions. Is this okay for trunk? Segher 2021-03-19 Segher Boessenkool PR target/97926 * ubsan.c (ubsan_instrument_float_cast): Don't test for unordered if there are no

[pushed] Darwin : Fix build failure for powerpc-darwin8 [PR99661].

Hi, Seems I fluffed a merge or rebase .. A hunk had been missed from r11-6417, fixed thus: tested with a complete cross from x86_64-darwin16 -> powerpc-darwin8 and a host only build on x86_64-linux-gnu. pushed to master, thanks Iain gcc/ChangeLog: PR target/99661 * config.gcc

[PATCH] arm: Fix MVE ICEs with vector moves and -mpure-code [PR97252]

Hi all, This patch fixes around 500 ICEs in the testsuite which can be seen when testing with -march=armv8.1-m.main+mve -mfloat-abi=hard -mpure-code (leaving the testsuite free of ICEs in this configuration). All of the ICEs are in arm_print_operand (which is expecting a mem and gets another rtx,

Re: [PATCH v2 0/5] RISC-V big endian support

Hi Marcus: Thank you for digging this issue out, I would suggest you sent v4 patch which only v3 + riscv_subword fix, and then merge into master first, and then sent separate patch for that issue, not sure what your fix, but I guess it might fix some code for IRA/LRA, so I think has a separate pat

Re: [PATCH] [PR99581] Define relaxed memory and use it for aarch64

On 2021-03-19 11:42 a.m., Richard Sandiford wrote: Vladimir Makarov via Gcc-patches writes: The following patch solves P1 PR99581     https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99581 The patch was successfully tested and bootstrapped on x86-64, ppc64le, aarch64. Is it ok for the trunk?

[committed] hppa: Use memcpy instead of strncpy to avoid error with -Werror=stringop-truncation

This change fixes a stringop-truncation warning in pa.c. Tested on hppa-unknown-linux-gn, hppa2.0w-hp-hpux11.11 and hppa64-hp-hpux11.11. Committed to trunk. Dave -- Use memcpy instead of strncpy to avoid error with -Werror=stringop-truncation. gcc/ChangeLog: * config/pa/pa.c (import_

Re: [PATCH] [PR99581] Define relaxed memory and use it for aarch64

On Fri, Mar 19, 2021 at 03:42:42PM +, Richard Sandiford via Gcc-patches wrote: > Vladimir Makarov via Gcc-patches writes: > > The following patch solves P1 PR99581 > > > >     https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99581 > > > > The patch was successfully tested and bootstrapped on x86

Re: [PATCH] rs6000: Fix some unexpected empty split conditions

Hi Segher, Thanks for the review. on 2021/3/19 下午8:36, Segher Boessenkool wrote: > Hi! > > On Fri, Mar 19, 2021 at 10:46:54AM +0800, Kewen.Lin wrote: >> As Segher and Mike pointed out, the define_insn_and_split should avoid >> to use empty split condition if the condition for define_insn isn't e

Fix for PR target/99660 - vxworksae/mils build failure from missing VX_CPU_PREFIX

Hello, This fixes an oversight which causes make all-gcc to fail for --target=*vxworksae or vxworksmils, a regression introduced by the recent VxWorks7 related updates. Thanks @Martin for opening the PR. Both AE and MILS variants resort to a common config/vxworksae.h, which misses a definition o

Re: [PATCH] [PR99581] Define relaxed memory and use it for aarch64

Vladimir Makarov via Gcc-patches writes: > The following patch solves P1 PR99581 > >     https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99581 > > The patch was successfully tested and bootstrapped on x86-64, ppc64le, > aarch64. > > Is it ok for the trunk? As I mentioned in bugzilla though, the mo

Re: [PATCH] [PR99581] Define relaxed memory and use it for aarch64

On 2021-03-19 11:03 a.m., Alex Coplan wrote: Hi Vladimir, On 19/03/2021 10:21, Vladimir Makarov via Gcc-patches wrote: The following patch solves P1 PR99581     https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99581 The patch was successfully tested and bootstrapped on x86-64, ppc64le, aarch64

Re: [PATCH] [PR99581] Define relaxed memory and use it for aarch64

On Fri, Mar 19, 2021 at 03:03:42PM +, Alex Coplan via Gcc-patches wrote: > Hi Vladimir, > > On 19/03/2021 10:21, Vladimir Makarov via Gcc-patches wrote: > > The following patch solves P1 PR99581 > > > >     https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99581 > > > > The patch was successfully

Re: [patch] PR/99296: Handle setting of 1-bit anti-ranges uniformly

On Fri, Mar 19, 2021 at 10:01:50AM +0100, Aldy Hernandez via Gcc-patches wrote: > --- a/gcc/value-range.cc > +++ b/gcc/value-range.cc > @@ -184,12 +184,46 @@ irange::irange_set (tree min, tree max) > verify_range (); > } > > +void > +irange::irange_set_1bit_anti_range (tree min, tree max) >

[PATCH] ubsan: Don't test for NaNs if those do not exist (PR97926)

Tested on powerpc64-linux {-m32,-m64}. No regressions. Is this okay for trunk? Segher 2021-03-19 Segher Boessenkool PR target/97926 * ubsan.c (ubsan_instrument_float_cast): Don't test for unordered if there are no NaNs. --- gcc/ubsan.c | 12 ++-- 1 file ch

Re: [PATCH] [PR99581] Define relaxed memory and use it for aarch64

Hi Vladimir, On 19/03/2021 10:21, Vladimir Makarov via Gcc-patches wrote: > The following patch solves P1 PR99581 > >     https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99581 > > The patch was successfully tested and bootstrapped on x86-64, ppc64le, > aarch64. > > Is it ok for the trunk? Can we

Re: [PATCH] libstdc++: Avoid accidental ADL when calling make_reverse_iterator

Quick reminder: Can you (or anyone) please commit this? The updated patch is attached in the last email. Best, Moritz Am 03.03.21 um 20:26 schrieb Moritz Sichert: Thanks for the review. I attached the updated patch. Can you commit this for me or point me to what I should do next? This is my

Re: [PATCH V5 0/6] Support for the CTF and BTF debug formats

> [Changes from V4: > - Rebased to latest master. > - Support for DATASEC in BTF. > - Bug fixes in the CTF support. > - Be more silent: do not inform() the user anymore if -gctf is used > along with a frontend for which there is no CTF support. Ignore > the request instead. > - Got rid of la

[PATCH] [PR99581] Define relaxed memory and use it for aarch64

The following patch solves P1 PR99581     https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99581 The patch was successfully tested and bootstrapped on x86-64, ppc64le, aarch64. Is it ok for the trunk? commit 20a38c39e57fe4d8a72391184e3b67129f0bf88c Author: Vladimir N. Makarov Date: Fri Mar 1

Re: [PATCH] slp: remove unneeded permute calculation (PR99656)

On Fri, 19 Mar 2021, Tamar Christina wrote: > Hi Richi, > > The attach testcase ICEs because as you showed on the PR we have one child > which is an internal with a PERM of EVENEVEN and one with TOP. > > The problem is while we can conceptually merge the permute itself into > EVENEVEN, > mergin

[PATCH] slp: remove unneeded permute calculation (PR99656)

Hi Richi, The attach testcase ICEs because as you showed on the PR we have one child which is an internal with a PERM of EVENEVEN and one with TOP. The problem is while we can conceptually merge the permute itself into EVENEVEN, merging the lanes don't really make sense. That said, we no longer

GCC 10.2.1 Status Report (2021-03-19)

Status == The GCC 10 branch is open for regression and documentation fixes. It's time to do the GCC 10.3 release and barring arrival of P1 priority regressions the plan is to do a release candidate in two weeks, around Mar 31th with a release following a week later. Please see to backport reg

[committed] analyzer: mark epath_finder with DISABLE_COPY_AND_ASSIGN [PR99614]

cppcheck warns that class epath_finder does dynamic memory allocation, but is missing a copy constructor and operator=. This class isn't meant to be copied or assigned, so mark it with DISABLE_COPY_AND_ASSIGN. Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. Pushed to trunk as r11-7

Re: [PATCH] aarch64: Don't emit -Wpsabi note when ABI was never affected [PR91710]

Jakub Jelinek writes: > Hi! > > As the following testcase shows, we emit a -Wpsabi note about argument > passing change since GCC 9, but in reality the ABI didn't change. > The alignment is 8 bits in GCC < 9 and 32 bits in GCC >= 9 and > the aarch64_function_arg_alignment returns in that case: > r

Re: [PATCH] rs6000: Fix some unexpected empty split conditions

Hi! On Fri, Mar 19, 2021 at 10:46:54AM +0800, Kewen.Lin wrote: > As Segher and Mike pointed out, the define_insn_and_split should avoid > to use empty split condition if the condition for define_insn isn't empty, > otherwise it can sometimes leads to unexpected consequence. > > This patch is to f

Re: [PATCH v2] x86: Issue error for return/argument only with function body

On Fri, Mar 19, 2021 at 1:11 PM H.J. Lu wrote: > > On Fri, Mar 19, 2021 at 1:39 AM Uros Bizjak wrote: > > > > On Thu, Mar 18, 2021 at 11:44 PM H.J. Lu wrote: > > > > > > If we never generate function body, we shouldn't issue errors for return > > > nor argument. Add init_cumulative_args_called

[PATCH v2] x86: Issue error for return/argument only with function body

On Fri, Mar 19, 2021 at 1:39 AM Uros Bizjak wrote: > > On Thu, Mar 18, 2021 at 11:44 PM H.J. Lu wrote: > > > > If we never generate function body, we shouldn't issue errors for return > > nor argument. Add init_cumulative_args_called to i386 machine_function > > to avoid issuing errors for retur

RE: [PATCH] arm: Fix mve_vshlq* [PR99593]

> -Original Message- > From: Jakub Jelinek > Sent: 18 March 2021 10:08 > To: Richard Earnshaw ; Ramana > Radhakrishnan ; Kyrylo Tkachov > > Cc: gcc-patches@gcc.gnu.org; Christophe Lyon > Subject: [PATCH] arm: Fix mve_vshlq* [PR99593] > > Hi! > > As mentioned in the PR, before the r1

Re: [committed] amdgcn: Silence warnings in gcn.c

This follow-up fixes a typo in the placement of the close quote. Thanks to Tobias for pointing it out. Andrew On 18/03/2021 17:41, Andrew Stubbs wrote: This patch has no functional changes; it merely cleans up some warning messages. Thanks to Jan-Benedict for pointing them out, off-list.

[PATCH] c-family: Fix PR94272 -fcompare-debug issue even for C [PR99230]

Hi! The following testcase results in -fcompare-debug failure. The problem is the similar like in PR94272 https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542562.html When genericizing, with -g0 we have just a TREE_SIDE_EFFECTS DO_STMT in a branch of if, while with -g we have that wrapped into

[committed] testsuite: Fix up pr98099.c testcase for big endian [PR98099]

On Thu, Dec 03, 2020 at 11:47:26AM +0100, Eric Botcazou wrote: > 2020-12-03 Eric Botcazou > > * gcc.dg/pr98099.c: New test. The testcase fails on big-endian without int128 support, because due to -fsso-struct=big-endian no swapping is needed for big endian. This patch restricts the testc

[PATCH] arm: Fix mve_vshlq* [PR99593]

Hi! As mentioned in the PR, before the r11-6708-gbfab355012ca0f5219da8beb04f2fdaf757d34b7 change v[al]shr3 expanders were expanding the shifts by register to gen_ashl3_{,un}signed which don't support immediate CONST_VECTOR shift amounts, but now expand to mve_vshlq_ which does. The testcase ICEs,

Patch ping

Hi! I'd like to ping two patches: https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566324.html PR99388 dwarf2out half float fix https://gcc.gnu.org/pipermail/gcc-patches/2021-March/59.html PR99490 dwarf2out -gsplit-dwarf ranges fixes Thanks Jakub

[PATCH] c++: Diagnose references to void in structured bindings [PR99650]

Hi! We ICE on the following testcase, because std::tuple_element<...,...>::type is void and for structured bindings we therefore need to create void & or void && which is invalid. We created such REFERENCE_TYPE and later ICEd in the middle-end. The following patch fixes it by diagnosing that, wit

[PATCH] aarch64: Don't emit -Wpsabi note when ABI was never affected [PR91710]

Hi! As the following testcase shows, we emit a -Wpsabi note about argument passing change since GCC 9, but in reality the ABI didn't change. The alignment is 8 bits in GCC < 9 and 32 bits in GCC >= 9 and the aarch64_function_arg_alignment returns in that case: return MIN (MAX (alignment, PARM_BOUN

[PATCH] c: FIx up -Wunused-but-set-* warnings for _Atomics [PR99588]

Hi! As the following testcases show, compared to -D_Atomic= case we have many -Wunused-but-set-* warning false positives. When an _Atomic variable/parameter is read, we call mark_exp_read on it in convert_lvalue_to_rvalue, but build_atomic_assign does not. For consistency with the non-_Atomic case

Re: [PATCH] c++: Only reject reinterpret casts from pointers to integers for manifestly_const_eval evaluation [PR99456]

On Thu, Mar 18, 2021 at 05:20:54PM -0400, Jason Merrill wrote: > On 3/9/21 10:31 AM, Jakub Jelinek wrote: > > Hi! > > > > My PR82304/PR95307 fix moved reinterpret cast from pointer to integer > > diagnostics from cxx_eval_outermost_constant_expr where it caught > > invalid code only at the outermo

[patch] PR/99296: Handle setting of 1-bit anti-ranges uniformly

Creation of inverse ranges in the irange code was not dealing with signed 1-bit quantities correctly. The legacy code had special cased this case, so I adapted and pulled out some code to do it in one place. Could someone double check the logic here, please? Thanks. Aldy commit 43c72ceb5dc11

[Patch] Fortran: Fix intrinsic null() handling [PR99651]

See PR for some analysis. The problem is that during gfc_intrinsic_func_interface, sym->attr.flavor == FL_PROCEDURE, hence, attr.intrinsic is not set – but later when parsing 'null()', gfortran calls: if (sym->attr.proc != PROC_INTRINSIC && !(sym->attr.use_assoc && sym->attr.intrinsic)

Re: [PATCH] x86: Issue error for return/argument only with function body

On Thu, Mar 18, 2021 at 11:44 PM H.J. Lu wrote: > > If we never generate function body, we shouldn't issue errors for return > nor argument. Add init_cumulative_args_called to i386 machine_function > to avoid issuing errors for return and argument without function body. > > gcc/ > > PR ta

Re: fix ssse3_pshufbv8qi3 post-reload const pool load

On Fri, Mar 19, 2021 at 7:29 AM Alexandre Oliva wrote: > > > The split in ssse3_pshufbv8qi3 forces a const vector into the constant > pool, and loads from it. That runs after reload, so if the load > requires any reloading, we're out of luck. Indeed, if the load > address is not legitimate, e.g.

Re: [patch] Fix PR middle-end/99641

On Thu, Mar 18, 2021 at 6:25 PM Eric Botcazou wrote: > > > Can you use wide_ints instead of building trees here please? > > Note that this will reject array types whose lower bound is not fixed, but the > wide_int version is attached. Yes, but that's no different than before. Thus, OK. Thanks,