Re: [PATCH] i386: Improve ix86_expand_int_movcc [PR105338]

On Sat, Apr 23, 2022 at 8:53 AM Jakub Jelinek wrote: > > Hi! > > The following testcase regressed on x86_64 on the trunk, due to some GIMPLE > pass changes (r12-7687) we end up an *.optimized dump difference of: > @@ -8,14 +8,14 @@ int foo (int i) > > [local count: 1073741824]: >if (i_2(D)

[PATCH] ppc: testsuite: float128-hw{,4}.c need -mlong-double-128 (was: [PATCH] ppc: testsuite: pr79004 needs -mlong-double-128)

On Apr 14, 2022, Alexandre Oliva wrote: > * gcc.target/powerpr/pr79004.c: Add -mlong-double-128. Just like pr79004, float128-hw.c requires -mlong-double-128 for some the expected asm opcodes to be output on target variants that have 64-bit long doubles. That's because their expanders, e.g

Re: [PATCH] PR target/89125

ping. On Fri, Apr 15, 2022 at 09:23:43AM -0700, Steve Kargl wrote: > Can someone, anyone, please commit the attach patch, which is > also attached to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89125 > where one can read the audit trail. The original patch was > submitted 2 years ago, and requ

Re: [PATCH v2] fortran: Detect duplicate unlimited polymorphic types [PR103662]

Hi Mikael, Am 22.04.22 um 12:53 schrieb Mikael Morin: Le 21/04/2022 à 23:14, Mikael Morin a écrit : Hello, this is a fix for PR103662, a TBAA issue with unlimited polymorphic types. I attached a draft patch to the PR which was accumulating all unlimited polymorphic symbols to a single namespa

[PATCH v1] RISC-V: Implement C[LT]Z_DEFINED_VALUE_AT_ZERO

The Zbb support has introduced ctz and clz to the backend, but some transformations in GCC need to know what the value of c[lt]z at zero is. This affects how the optab is generated and may suppress use of CLZ/CTZ in tree passes. Among other things, this is needed for the transformation of table-ba

Re: *PING* [PATCH 0/4] Use pointer arithmetic for array references [PR102043]

Yes, Thank you Mikael! On 4/22/22 6:59 AM, Thomas Koenig via Fortran wrote: Hi Mikael, Ping for the four patches starting at https://gcc.gnu.org/pipermail/fortran/2022-April/057759.html : https://gcc.gnu.org/pipermail/fortran/2022-April/057757.html https://gcc.gnu.org/pipermail/fortran/2022-

Re: [PATCH] AVX512F: Add missing macro for mask(z?)_scalf_s[sd] [PR 105339]

On Fri, Apr 22, 2022 at 8:43 PM Hongyu Wang wrote: > > > Please add the corresponding intrinsic test in sse-14.c > > Sorry for forgetting this part. Updated patch. Thanks. > LGTM. > Hongtao Liu via Gcc-patches 于2022年4月22日周五 16:49写道： > > > > On Fri, Apr 22, 2022 at 4:12 PM Hongyu Wang via Gcc-patc

[PATCH 0/1] RISC-V: Fix canonical extension order (K and J)

**note** My copyright assignment to FSF is not yet started (will start just after sending this patch). Please take care of the assignment status. This patch fixes RISC-V's canonical extension order... from: "J" -> "K" to : "K" -> "J" as per the RISC-V ISA Manual draft-20210402-1271737 or late

[PATCH 1/1] RISC-V: Fix canonical extension order (K and J)

This commit fixes canonical extension order to follow the RISC-V ISA Manual draft-20210402-1271737 or later. gcc/ChangeLog: * common/config/riscv/riscv-common.cc (riscv_supported_std_ext): Fix "K" extension prefix to be placed before "J". --- gcc/common/config/riscv/riscv-common.

Re: [PATCH 1/1] RISC-V: Fix canonical extension order (K and J)

Neither K nor J is an extension that exists, and so it doesn't make sense to mandate any particular ordering. The better change would be to delete the letters `k' and `j' from that string, so that we aren't enforcing constraints that don't serve a useful purpose. cf. https://github.com/riscv/ris

Re: [PATCH 1/1] RISC-V: Fix canonical extension order (K and J)

Hello, > Neither K nor J is an extension that exists, That is correct. > and so it doesn't make > sense to mandate any particular ordering. No. It affects Z* extension ordering... On 2022/04/24 14:36, Andrew Waterman wrote: > Neither K nor J is an extension that exists, and so it doesn't make