Re: [PATCH v3] i386: Check AX input in any_mul_highpart peepholes

On Sat, Dec 25, 2021 at 3:28 PM H.J. Lu wrote: > > When applying peephole optimization to transform > > mov imm, %reg0 > mov %reg1, %AX_REG > imul %reg0 > > to > > mov imm, %AX_REG > imul %reg1 > > disable peephole optimization if reg1 == AX_REG. > > gcc/ >

Re: [PATCH v3] i386: Check AX input in any_mul_highpart peepholes

On Sun, Dec 26, 2021 at 2:31 AM Uros Bizjak wrote: > > On Sat, Dec 25, 2021 at 3:28 PM H.J. Lu wrote: > > > > When applying peephole optimization to transform > > > > mov imm, %reg0 > > mov %reg1, %AX_REG > > imul %reg0 > > > > to > > > > mov imm, %AX_REG > >

Re: [PATCH] Make integer output faster in libgfortran

Hi, > I tested this on x86_64-pc-linux-gnu with > make -k -j8 check-fortran RUNTESTFLAGS="--target_board=unix'{-m32,-m64}'" > and didn't see any problems. Thanks Thomas! Pushed. > (We could also do something like that for a 32-bit system, but > that is another kettle of fish). We probably woul

Re: [PATCH] Make integer output faster in libgfortran

Hi FX, (We could also do something like that for a 32-bit system, but that is another kettle of fish). We probably wouldn’t get a speed-up that big. Even on 32-bit targets (at least common ones), the 64-bit type and its operations (notably division) are implemented via CPU instructions, not l

Re: [PATCH v2] ix86: Don't use the 'm' constraint for x86_64_general_operand

On Fri, Dec 24, 2021 at 12:19 AM Uros Bizjak wrote: > > On Thu, Dec 23, 2021 at 3:42 PM H.J. Lu wrote: > > > > On Mon, Dec 20, 2021 at 2:22 PM H.J. Lu wrote: > > > > > > On Mon, Dec 20, 2021 at 12:38 PM Jakub Jelinek wrote: > > > > > > > > On Mon, Dec 20, 2021 at 11:44:08AM -0800, H.J. Lu wrote

[PATCH] Emit correct types for CHARACTER(C_CHAR), VALUE

Hi, I’ve spent many hours going down a rabbit hole, namely that we emit incorrect types for C interoperable procedure parameters of type CHARACTER(C_CHAR), VALUE. The full details can be found here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103828 I will try here to be as brief as I can. T

[PATCH] Prune LTO warnings that some tests fail

The testcase g++.dg/torture/pr31863.C fails on *-apple-darwin with: FAIL: g++.dg/torture/pr31863.C -O2 -flto (test for excess errors) Excess errors: lto-wrapper: warning: using serial compilation of 2 LTRANS jobs The test otherwise works fine, but those lto warnings should be pruned. OK to co

[PATCH] Set __FLT_EVAL_METHOD__/__FLT_EVAL_METHOD_TS_18661_3__ to FLT_EVAL_METHOD_PROMOTE_TO_FLOAT when FLT_EVAL_METHOD_PROMOTE_TO_FLOAT16.

Since FLT_EVAL_METHOD only accepts negative value, 0, 1 or 2. gcc/c-family/ChangeLog: PR c/100854 * c-common.c (excess_precision_mode_join): Return FLT_EVAL_METHOD_PROMOTE_TO_FLOAT when both x and y are FLT_EVAL_METHOD_PROMOTE_TO_FLOAT16. --- gcc/c-family/c-common

Re: [PATCH] fixed testcase riscv/pr103302.c

Hi ShiHua: Thanks for the fix, committed with Andrew's comment and minor fix for commit comment. On Thu, Dec 23, 2021 at 3:41 PM Andrew Pinski via Gcc-patches wrote: > > On Wed, Dec 22, 2021 at 11:37 PM wrote: > > > > From: LiaoShihua > > > > because riscv32 not support __int128, so sk