[RISC-V] Fix PR target/115591

This is an ICE in the RISC-V back-end calling tree_to_uhwi on the DECL_SIZE of a global variable-length array. Fixed thusly, tested and approved by Jeff in the audit trail, and applied on the mainline. 2024-07-06 Eric Botcazou PR target/115591 * config/riscv/riscv.cc (riscv

[patch,avr,applied] Create more opportunities for the -mfuse-add optimization pass

Up to now, a post-reload split for fake PLUS addresses was only run on AVR_TINY. However, also non-AVR_TINY cores have some address registers that don't support PLUS addressing, which is the X register, and the Z register with [E]LPM. This patch splits also these patterns. The fuse-add pass can

Re: [PATCH] Fix test errors introduced with fix for PR115157

Am Montag, dem 01.07.2024 um 14:29 -0300 schrieb Thiago Jung Bauermann: > Hello Martin, > > Martin Uecker writes: > > > This should fix the test failures introduced by the fix for PR115157. > > > > Tested on x86_64 and also tested with -m32. > > > > > > Fix test errors introduced with fix

[pushed] wwwdocs: gcc-3.0: Use testing/testing-lapack.html

testing/testing-lapack.html appears newer and a generic page, which allows us to retire the mostly redundant gcc-3.0/lapack-guide.html . (Still essentially obsolete information, at least only half of it now.) Gerald --- htdocs/gcc-3.0/criteria.html | 4 +- htdocs/gcc-3.0/lapack-guide.html

Re: [PATCH] contrib: add cxx-dr-table.sh

On Thu, 11 Apr 2024, Marek Polacek wrote: > Ok for trunk? > > -- >8 -- > I use this script to keep > up-to-date. I thought it might be good to have it in contrib/, so I've > polished it a little bit. > > contrib/ChangeLog: > > * cxx-dr-tab

[committed] Fix various sh define_insn_and_split predicates

The sh4-linux-gnu port has failed to bootstrap since the introduction of late combine due to failures to split certain insns. This is caused by incorrect predicates in various define_insn_and_split patterns. Essentially the insn's predicate is something like "TARGET_SH1". The split predicate

Re: [RFC WIP] RAW_DATA_CST for #embed optimization

On Fri, 5 Jul 2024, Jakub Jelinek wrote: > Hi! > > Just to show what I'm working on on top of the already posted #embed > patches. > Working on the C FE only for now, the patch emits CPP_EMBED tokens > when preprocessing C (but still with the important simplification that > CPP_EMBED token is alw

[patch,testsuite,applied] PR52641: Fix more sloppy tests.

Such tests exists because pre-processed sources are used as test cases, like they are provided in PRs. This means they have, say, "unsigned long" instead of size_t, but "unsigned long" is not a correct size_t on some targets. Some of the tests can be transformed back so that they use __SIZE_TYPE

Re: [committed] Fix various sh define_insn_and_split predicates

On Sat, 2024-07-06 at 06:40 -0600, Jeff Law wrote: > The sh4-linux-gnu port has failed to bootstrap since the introduction of > late combine due to failures to split certain insns. > > This is caused by incorrect predicates in various define_insn_and_split > patterns. Essentially the insn's

Re: [RFC/PATCH] libgcc: sh: Use soft-fp for non-hosted SH3/SH4

On 7/5/24 1:28 AM, Sébastien Michelland wrote: Hi Oleg! I don't understand why this is being limited to SH3 and SH4 only? Almost all SH4 systems out there have an FPU (unless special configurations are used).  So I'd say if switching to soft-fp, then for SH-anything, not just SH3/SH4. If

Re: [patch,avr] PR87376: Disable -ftree-ter

On 7/3/24 2:32 PM, Georg-Johann Lay wrote: Am 03.07.24 um 21:39 schrieb Jeff Law: On 7/3/24 1:26 PM, Georg-Johann Lay wrote: Am 02.07.24 um 15:48 schrieb Richard Biener: On Tue, Jul 2, 2024 at 3:43 PM Georg-Johann Lay wrote: Hi Jeff, This is a patch to get correct code out of 64-b

Re: [PATCH] Remove trailing whitespace from invoke.texi

On 7/2/24 7:28 PM, Patrick O'Neill wrote: gcc/ChangeLog: * doc/invoke.texi: Remove trailing whitespace. OK jeff

Re: [PATCH 1/2] [RISC-V] add implied extension repeatly until stable

On 7/5/24 3:56 AM, Fei Gao wrote: Call handle_implied_ext repeatly until there's no new subset added into the subset list. gcc/ChangeLog: * common/config/riscv/riscv-common.cc (riscv_subset_list::riscv_subset_list): init m_subset_num to 0. (riscv_subset_list::add)

Re: [PATCH 2/2] [RISC-V] c implies zca, and conditionally zcf & zcd

On 7/5/24 3:56 AM, Fei Gao wrote: According to Zc-1.0.4-3.pdf from https://github.com/riscvarchive/riscv-code-size-reduction/releases/tag/v1.0.4-3 The rule is that: 1. C always implies Zca 2. C+F implies Zcf (RV32 only) 3. C+D implies Zcd gcc/ChangeLog: * common/config/riscv/riscv-c

Re: [PATCH] RISC-V: Add basic support for the Zacas extension

On 7/3/24 3:16 PM, Patrick O'Neill wrote: Regarding the amocas.q follow-up patch: I'm having trouble with matching any TImode compare-and-swap patterns. Here's the RTL I'm trying: (define_mode_iterator SUPERGPR [SI DI TI]) (define_insn "zacas_atomic_cas_value" [(set (match_operand:SUPE

Re: [RFC WIP] RAW_DATA_CST for #embed optimization

On Sat, Jul 06, 2024 at 02:45:45PM +0200, Richard Biener wrote: > > Anyway, thoughts on this before I spend too much time on it? > > Why do we have an "element type"? Would > > int a[] = { > #embed "cc1plus" > }; > > be valid? Yes, that is valid. The way #embed is defined for C is that it is e

Re: [PATCH, gfortran] libgfortran: implement fpu-macppc for Darwin, support IEEE arithmetic

>From f19315cd425d0a23c02ba1be9c24c2a1f82cb47c Mon Sep 17 00:00:00 2001 From: Sergey Fedorov Date: Sat, 29 Apr 2023 14:55:44 +0800 Subject: [PATCH] libgfortran: implement fpu-macppc for Darwin, support IEEE arithmetic Signed-off-by: Sergey Fedorov --- libgfortran/config/fpu-macppc.h | 414

Re: [PATCH v8 07/12] Enable musttail tail conversion even when not optimizing

> > +class pass_musttail : public gimple_opt_pass > > +{ > > +public: > > + pass_musttail (gcc::context *ctxt) > > +: gimple_opt_pass (pass_data_musttail, ctxt) > > + {} > > + > > + /* opt_pass methods: */ > > + /* This pass is only used when not optimizing to make [[musttail]] still > > +

Re: [PATCH v8 03/12] Add a musttail generic attribute to the c-attribs table

On Fri, Jul 05, 2024 at 12:44:47PM +0200, Richard Biener wrote: > On Sat, Jun 22, 2024 at 8:57 PM Andi Kleen wrote: > > > > It does nothing currently since statement attributes are handled > > directly in the parser. > > Is this needed at all? a "'musttail' attribute ignored" diagnostic isn't >

Re: [PATCH, gfortran] libgfortran: implement fpu-macppc for Darwin, support IEEE arithmetic

On Sat, Jul 6, 2024 at 6:07 AM FX Coudert wrote: > > This part of the patch is quite old, but from the remaining log it looks > I got an error here: > > Now on a second thought, this did not require a fix perhaps. We can drop > it. > > I have addressed this: > https://gcc.gnu.org/pipermail/gcc-pa

Re: [PATCH v8 09/12] Delay caller error reporting for musttail

On Fri, Jul 05, 2024 at 01:45:17PM +0200, Richard Biener wrote: > On Sat, Jun 22, 2024 at 9:00 PM Andi Kleen wrote: > > > > Move the error reporting for caller attributes to be > > after the tail call discovery, so that we can give proper > > error messages tagged to the calls. > > Hmm. This all

Re: [PATCH v8 08/12] Give better error messages for musttail

> >if (!single_succ_p (bb)) > > -return; > > +{ > > + int num_eh, num_other; > > + bb_get_succ_edge_count (bb, num_eh, num_other); > > + /* Allow EH edges so that we can give a better > > +error message later. */ > > Please instead use has_abnormal_or_eh_outgoin

Re: [PATCH 0/2] fix RISC-V zcmp popretz [PR113715]

On 6/28/24 4:46 AM, Fei Gao wrote: On 2024-06-09 04:36  Jeff Law wrote: On 6/5/24 8:42 PM, Fei Gao wrote: But let's back up and get a good explanation of what the problem is. Based on patch 2/2 it looks like we have lost an assignment to the return register. To someone not familiar wit

[committed] libstdc++: Restore support for including in extern "C" [PR115797]

Tested x86_64-linux. Pushed to trunk. -- >8 -- The r15-1857 change means that is included by for C++17 and up, which breaks code including inside an extern "C" block. Although doing that is not allowed by the C++ standard, there's lots of existing code which incorrectly thinks it's a good idea

Re: [committed] libstdc++: Use reserved form of [[__likely__]] in

This one needs to be backported too. On Sat, 6 Jul 2024 at 21:18, Jonathan Wakely wrote: > > Tested x86_64-linux. Pushed to trunk. > > -- >8 -- > > We should not use [[unlikely]] before C++20, so use [[__unlikely__]] > instead. > > libstdc++-v3/ChangeLog: > > * include/std/variant (_Varia

[committed] libstdc++: Use reserved form of [[__likely__]] in

Tested x86_64-linux. Pushed to trunk. -- >8 -- We should not use [[unlikely]] before C++20, so use [[__unlikely__]] instead. libstdc++-v3/ChangeLog: * include/std/variant (_Variant_storage::_M_reset): Use __unlikely__ form of attribute instead of unlikely. --- libstdc++-v3/incl

[committed] libstdc++: Remove redundant 17_intro/headers tests

Tested x86_64-linux. Pushed to trunk. -- >8 -- We have several nearly identical tests under 17_intro/headers which only differ in a -std option set using dg-options. Since the testsuite now supports running tests with multiple -std options (and I test that regularly) we don't need these duplicate

Re: [RFC/PATCH] libgcc: sh: Use soft-fp for non-hosted SH3/SH4

Hi, ( For some weird reason I keep losing Sebastien's messages ... ) On Sat, 2024-07-06 at 07:35 -0600, Jeff Law wrote: > > On 7/5/24 1:28 AM, Sébastien Michelland wrote: > > Hi Oleg! > > > > > I don't understand why this is being limited to SH3 and SH4 only? > > > Almost all SH4 systems out th

[PATCH] c++: xobj fn call without obj [PR115783]

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk/14? -- >8 -- The code path for rejecting an object-less call to a non-static member function should also consider xobj member functions so that we properly reject the below calls with a "cannot call member function wit

[PATCH 1/3] c++: Introduce USING_DECLs for non-function usings [PR114683]

Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? -- >8 -- With modules, a non-function using-declaration is not completely interchangable with the declaration that it refers to; in particular, such a using-declaration may be exported without revealing the name of the entity it ref

[PATCH 2/3] c++/modules: Handle redefinitions of using-decls

Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? -- >8 -- This fixes an ICE exposed by supporting exported non-function using-decls. Sometimes when preparing to define a class, xref_tag will find a using-decl belonging to a different namespace, which triggers the checking_assert

[PATCH 3/3] c++: Add locations to using_p OVERLOADs

Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? I have also been working on a patch that uses the locations of using-decls in 'diagnose_name_conflict' and 'duplicate_decls' calls, but that will need a fair bit more work that I'll probaby put off for the meantime. Otherwise, as fa

Re: [PATCH] c++/modules: Ensure deduction guides are always reachable [PR115231]

Ping for https://gcc.gnu.org/pipermail/gcc-patches/2024-June/654792.html On Sun, Jun 16, 2024 at 3:41 PM Nathaniel Shead wrote: > > On Sun, Jun 16, 2024 at 12:29:23PM +1000, Nathaniel Shead wrote: > > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? > > > > This probably isn't the

[PATCH] c++/modules: Stream warning suppressions [PR115757]

Bootstrapped on x86_64-pc-linux-gnu, successfully regtested modules.exp; OK for trunk if full regtest passes? -- >8 -- Currently we don't stream the contents of 'nowarn_map'; this means that warning suppressions don't get applied in importers, which is particularly relevant for templates (as in t