Re: [PATCH, v2] PR fortran/105184 - ICE in gfc_array_init_size, at fortran/trans-array.cc:5841

Hi Harald, It looks good to me - OK for mainline. Thanks Paul On Fri, 8 Apr 2022 at 21:45, Harald Anlauf via Fortran wrote: > Dear all, > > Am 06.04.22 um 22:30 schrieb Harald Anlauf via Fortran: > > Dear all, > > > > the logic for checking the allocate-coshape-spec in an ALLOCATE > > statem

Re: [PATCH, v2] PR fortran/105184 - ICE in gfc_array_init_size, at fortran/trans-array.cc:5841

Hi Harald, Regtested again with no new failures.  OK for mainline? Looks good to me. Thanks for the patch! Best regards Thomas

New Swedish PO file for 'gcc' (version 12.1-b20220403)

Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the Swedish team of translators. The file is available at: https://translationproject.org/latest/gcc/sv.po (This file, 'gcc-12.1-b20220403.sv.po'

Re: [PATCH v3] MIPS: IPL is 8bit in Cause and Status registers if TARGET_MCU

On Tue, 15 Mar 2022, YunQiang Su wrote: > If MIPS MCU extension is enable, the IPL section in Cause and Status > registers has been expand to 8bit instead of 6bit. > > In Cause: the bits are 10-17. > In Status: the bits are 10-16 and 18. > > MD00834-2B-MUCON-AFP-01.03.pdf: P49 and P61. I can s

Avoid overflow in ipa-modref-tree.cc

Hi, the testcase triggers ICE since computation overflows on two accesses that are very far away d->b[-144115188075855873] and d->b[144678138029277184]. This patch makes the relevant part of modref to use poly_offset_int. It is kind of weird to store bit offsets into poly_int64 but it is what alia

Re: [PATCH, rs6000] Correct match pattern in pr56605.c

Hi, On 9/4/2022 上午 12:48, will schmidt wrote: > On Mon, 2022-02-28 at 11:17 +0800, HAO CHEN GUI via Gcc-patches wrote: >> Hi, >> This patch corrects the match pattern in pr56605.c. The former pattern >> is wrong and test case fails with GCC11. It should match following insn on >> each subtarget

[committed] Minor bfin codegen bugfix

builtin-arith-overflow-3 has been failing on bfin-elf for a while. I've had a workaround installed on the tester for a few months and I finally got some time to dig into it over the weekend. Ultimately I was able to nail the problem down to the representation of the rotate left by one position

[PATCH v2, pushed] rs6000/test: Adjust p9-vec-length-{full, epil}-7.c [PR103196]

on 2022/4/8 10:34 PM, Segher Boessenkool wrote: > Hi! > > Thanks for investigating. > > On Fri, Apr 08, 2022 at 03:25:51PM +0800, Kewen.Lin wrote: >> on 2022/4/8 3:29 AM, Segher Boessenkool wrote: >>> On Thu, Apr 07, 2022 at 09:19:51AM -0500, will schmidt wrote: On Mon, 2022-02-28 at 13:37 +

Re: [PATCH, rs6000] Correct match pattern in pr56605.c

Hi, On 9/4/2022 上午 3:36, Segher Boessenkool wrote: > Hi! > > On Mon, Feb 28, 2022 at 11:17:27AM +0800, HAO CHEN GUI wrote: >> This patch corrects the match pattern in pr56605.c. The former pattern >> is wrong and test case fails with GCC11. It should match following insn on >> each subtarget af

Re: rustc_codegen_gcc and libgccjit for GCC 12 ?

On Fri, 8 Apr 2022, David Malcolm wrote: > I'm excited to read that rustc_codegen_gcc, the libgccjit-based backend > for rustc can now bootstrap rustc: > https://blog.antoyo.xyz/rustc_codegen_gcc-progress-report-10 > > I've been focusing on the analyzer, and so haven't been as on top of > libgc

Re: [PATCH] phiopt: Optimize (x != cst1 ? x : cst2) != cst3 [PR104639]

On Sat, 9 Apr 2022, Jakub Jelinek wrote: > Hi! > > Here is an attempt to resolve a P1 regression, where due to threading > changes we no longer optimize > bool foo(int i) { > while (i == 4) > i += 2; > return i; > } > to just return i != 0; by enhancing the phiopt value_replacemen