[committed] libgcc pru: Define TARGET_HAS_NO_HW_DIVIDE

This patch aligns the configuration to the actual PRU capabilities. It also reduces the size of the affected libgcc functions. For a real-world project using integer arithmetics the savings are significant: Before: textdata bss dec hex filename 3688 865 544

[committed] Enable LRA on several ports

Spurred by Segher's RFC, I went ahead and tested several ports with LRA enabled. Not surprisingly, many failed, but a few built their full set of libraries successful and of those a few even ran their testsuites with no regressions. In fact, enabling LRA fixes a small number of failures on

[committed] Convert xstormy16 to LRA

This patch converts the xstormy16 patch to LRA. It introduces a code quality regression in the shiftsi testcase, but it also fixes numerous aborts/errors. IMHO it's a good tradeoff. Committed to the trunk, Jeff commit 977a3be3ccbc7f177316b2b349523023cac37bcd Author: Jeff Law Date: Mon May

Re: [PATCH V5] Use reg mode to move sub blocks for parameters and returns

Hi! On Fri, Mar 17, 2023 at 11:39:52AM +0800, Jiufu Guo wrote: > gcc/testsuite/ChangeLog: > > * gcc.target/powerpc/pr65421-1.c: New test. > * gcc.target/powerpc/pr65421.c: New test. Please name the tests something else? -1.c and -2.c maybe. Or something more inspired. Just not som

[PATCH] RISC-V: Name newly added flags in changelog

This patch fixes the changelog to explicitly name the added command line flags introduced in this patch: https://gcc.gnu.org/pipermail/gcc-patches/2023-April/616807.html 2023-05-01 Patrick O'Neill gcc/ChangeLog: * ChangeLog: Name the flags added by the patch in the changelog. Signed-of

Re: [PATCH v4 4/4] ree: Improve ree pass for rs6000 target using defined ABI interfaces.

Hi! On Sat, Apr 22, 2023 at 02:36:20PM +0530, Ajit Agarwal wrote: > * ree.cc (combline_reaching_defs): Add zero_extend > using defined abi interfaces. Typo. Also, please don't wrap lines early. Also, you are missing some changes in this file in the changelog. > (add_rem

[PATCH] Fortran: overloading of intrinsic binary operators [PR109641]

Dear all, the attached patch is mostly self-explaining: we mishandled the overloading of intrinsic binary operators in the case the actual operands were of intrinsic numeric type and the ranks of the operands were not conformable, i.e. both were of non-zero and different ranks. In that case the o

[PATCH] PHIOPT: Update comment about what the pass now does

I noticed I didn't update the comment about how the pass works after I initially added match_simplify_replacement. Anyways this updates the comment to be the current state of the pass. OK? gcc/ChangeLog: * tree-ssa-phiopt.cc: Update comment about how the transformation are implem

Re: [PATCH] PHIOPT: Update comment about what the pass now does

On 5/1/23 10:37, Andrew Pinski via Gcc-patches wrote: I noticed I didn't update the comment about how the pass works after I initially added match_simplify_replacement. Anyways this updates the comment to be the current state of the pass. OK? gcc/ChangeLog: * tree-ssa-phiopt.cc: Upd

Re: [PATCH] c++: RESULT_DECL replacement in constexpr call result [PR105440]

On 4/28/23 15:40, Patrick Palka wrote: On Fri, 28 Apr 2023, Patrick Palka wrote: On Fri, 28 Apr 2023, Patrick Palka wrote: After mechanically replacing RESULT_DECL within a constexpr call result (for sake of RVO), we can in some cases simplify the call result further. In the below testcase t

[r14-332 Regression] FAIL: gcc.target/i386/pr89618-2.c scan-tree-dump vect "loop vectorized using 16 byte vectors" on Linux/x86_64

On Linux/x86_64, 24905a4bd1375ccd99c02510b9f9529015a48315 is the first bad commit commit 24905a4bd1375ccd99c02510b9f9529015a48315 Author: Richard Biener Date: Wed Jan 18 11:04:49 2023 +0100 Adjust costing of emulated vectorized gather/scatter caused FAIL: gcc.target/i386/pr88531-2a.c sca

[PATCH 2/2] c++: non-dep init folding and access checking [PR109480]

enforce_access currently inspects processing_template_decl to determine whether to defer the given access check until instantiation time. But using this flag is unreliable because it gets cleared during e.g. non-dependent initializer folding, and can lead to premature access check failures as in t

[PATCH 1/2] c++: potentiality of templated memfn call [PR109480]

Here we're incorrectly deeming the templated call a.g() inside b's initializer as potentially constant, despite g being non-constexpr, which leads to us wastefully instantiating the initializer ahead of time and triggering a bug in access checking deferral (which will get fixed in the subsequent pa

[pushed] c++: array DMI and member fn [PR109666]

Tested x86_64-pc-linux-gnu, applying to trunk. Patrick, can you verify that this resolves 109506 and add whatever testcase(s) seem appropriate from that PR? -- 8< -- Here it turns out I also needed to adjust cfun when stepping out of the member function to instantiate the DMI. But instead of ad

[pushed] ubsan: ubsan_maybe_instrument_array_ref tweak

In we discussed that the copy_node in ubsan_maybe_instrument_array_ref is redundant, but also that it'd be best to postpone the optimization to GCC 14. So I'm making that change now. Tested x86_64-pc-linux-gnu, applying to trunk.

Re: [committed] Convert xstormy16 to LRA

Jeff Law wrote: > This patch converts the xstormy16 patch to LRA. It introduces a code > quality regression in the shiftsi testcase, but it also fixes numerous > aborts/errors. IMHO it's a good tradeoff. I've investigated the shiftsi regression on xstormy16 and the underlying cause appears t

[PATCH] c++: Move -Wdangling-reference to -Wextra [PR109642]

Sadly, -Wdangling-reference generates false positives for std::span-like user classes, and it seems imprudent to attempt to improve the heuristic in GCC 13. Let's move the warning to -Wextra, that will hopefully reduce the number of false positives the users have been seeing with 13. I'm leaving

Re: [committed] Enable LRA on several ports

> Date: Mon, 1 May 2023 07:21:59 -0600 > From: Jeff Law > Spurred by Segher's RFC, I went ahead and tested several ports with LRA > enabled. Not surprisingly, many failed, but a few built their full set > of libraries successful and of those a few even ran their testsuites > with no regressio

Re: [aarch64] Code-gen for vector initialization involving constants

On Tue, 25 Apr 2023 at 16:29, Richard Sandiford wrote: > > Prathamesh Kulkarni writes: > > Hi Richard, > > While digging thru aarch64_expand_vector_init, I noticed it gives > > priority to loading a constant first: > > /* Initialise a vector which is part-variable. We want to first try > >

GCC 12.2.1 Status Report (2023-05-02), branch frozen for release

The GCC 12 branch is now frozen in preparation for a GCC 12.3 release candidate and the release of GCC 12.3 next week. All changes require release manager approval. Quality Data Priority # Change from last report --- --- P1