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/
>
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
> >
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
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
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
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
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
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
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