Re: PING^1 [PATCH] DWARF: Relax SUPPORTS_STACK_ALIGNMENT with !crtl->stack_realign_tried

On Wed, Aug 29, 2018 at 5:43 PM, H.J. Lu wrote: > On Wed, Aug 29, 2018 at 2:17 PM, Jason Merrill wrote: >> On Wed, Aug 29, 2018 at 3:38 PM, H.J. Lu wrote: >>> On Wed, Aug 29, 2018 at 12:32 PM, Jason Merrill wrote: On Wed, Aug 29, 2018 at 2:59 PM, H.J. Lu wrote: > On Wed, Aug 29, 2018

Re: [PATCH 3/3] or1k: gcc: initial support for openrisc

On 08/29/2018 03:29 PM, Richard Henderson wrote: > On 08/28/2018 07:13 AM, Jeff Law wrote: >> Your port defines instruction scheduling, so please check that you're >> emitting the proper barriers, particularly in your epilogue code. In >> particular most ports need a barrier to prevent movement of

Re: [PATCH 3/3] or1k: gcc: initial support for openrisc

On 08/29/2018 04:38 PM, Jeff Law wrote: > On 08/29/2018 03:29 PM, Richard Henderson wrote: > > As far as I'm concerned, you can commit this once the barriers & > speculation bits are fixed. If you can avoid trampolines, that can be a > follow-up. And long branches can definitely be punted until

Re: [PATCH 3/3] or1k: gcc: initial support for openrisc

On Wed, Aug 29, 2018 at 02:29:45PM -0700, Richard Henderson wrote: > On 08/28/2018 07:13 AM, Jeff Law wrote: > > I didn't see any provision for long vs short branches. How are branches > > to targets within the same function, but which are out of the range that > > can be encoded in a single instr

Re: [PATCH 3/3] or1k: gcc: initial support for openrisc

On 08/29/2018 03:38 PM, Jeff Law wrote: > As far as I'm concerned, you can commit this once the barriers & > speculation bits are fixed. If you can avoid trampolines, that can be a > follow-up. And long branches can definitely be punted until it's really > needed. Thanks. > ps. Any plans for gl

[PATCH, v2], Improve PowerPC switch behavior on medium code model system

This patch is a respin of the original patch. I moved the support for the LWAX instruction in a separate patch, and it has already been committed. I added a test case for the switch code on PowerPC LE medium code. I made the labelref insn not have a generator because there was no caller for it (

Re: [PATCH 3/3] or1k: gcc: initial support for openrisc

On Wed, Aug 29, 2018 at 04:38:45PM -0600, Jeff Law wrote: > ps. Any plans for glibc? How complete is the qemu support? I'm having > reasonable success building little chroot filesystems, then using qemu > to do bootstrap testing within those chroots. Hello Juff, I was planning to start to look

Re: PING^1 [PATCH] DWARF: Relax SUPPORTS_STACK_ALIGNMENT with !crtl->stack_realign_tried

On Wed, Aug 29, 2018 at 3:37 PM, Jason Merrill wrote: > On Wed, Aug 29, 2018 at 5:43 PM, H.J. Lu wrote: >> On Wed, Aug 29, 2018 at 2:17 PM, Jason Merrill wrote: >>> On Wed, Aug 29, 2018 at 3:38 PM, H.J. Lu wrote: On Wed, Aug 29, 2018 at 12:32 PM, Jason Merrill wrote: > On Wed, Aug 29,

Re: [PATCH] Rewrite pic.md to improve medany and pic code size.

On Wed, 29 Aug 2018 09:52:00 PDT (-0700), Jim Wilson wrote: On Wed, Aug 29, 2018 at 9:22 AM, Palmer Dabbelt wrote: Thanks Jim -- I'm afraid at least part of this was my mess, as I had to go add in the ZERO_EXTEND_LOAD hackery to work around some bug in this file that I couldn't figure out how t

C++ PATCH/RFC for c++/87109, wrong overload with ref-qualifiers

I've now gotten to the point where I question the validity of this PR, so it's probably a good time to stop and ask for some advice. As discussed in , we choose the wrong overload for f1: struct C { }; struct A { operator C() &; operat

[PATCH] look harder for MEM_REF operand equality to avoid -Wstringop-truncation (PR 84561)

The attached patch adds code to work harder to determine whether the destination of an assignment involving MEM_REF is the same as the destination of a prior strncpy call. The included test case demonstrates when this situation comes up. During ccp, dstbase and lhsbase returned by get_addr_base_

Re: [PATCH] avoid warning on constant strncpy until next statement is reachable (PR 87028)

On 08/28/2018 06:12 PM, Martin Sebor wrote: >>> Sadly, dstbase is the PARM_DECL for d.  That's where things are going >>> "wrong".  Not sure why you're getting the PARM_DECL in that case.  I'd >>> debug get_addr_base_and_unit_offset to understand what's going on. >>> Essentially you're getting diff

Re: [PATCH AArch64]Fix test failure for pr84682-2.c

On Thu, Aug 30, 2018 at 2:47 AM Richard Sandiford wrote: > > Joey Ye writes: > > diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c > > index 07c55b1..9e965ab 100644 > > --- a/gcc/config/aarch64/aarch64.c > > +++ b/gcc/config/aarch64/aarch64.c > > @@ -5674,9 +5674,6 @@ aarch

Re: [PATCH][testcase]patch for fixing PR 86519

On 08/29/2018 08:53 AM, Qing Zhao wrote: > Hi, > > this is the patch to fix PR86519. > > Per Jeff’s suggestion, I removed strcmpopt_6.c from gcc.dg, and > added it to gcc.target/aarch64 and gcc.target/i386. > > retested on x86 and aarch64. no issue. > > Okay to commit? > > thanks. > > Qing. >

Re: [PR c++/87137] GCC-8 Fix

在 2018-08-30 01:36, Nathan Sidwell 写道: But, it would be bad to make that particular ABI fix in a point release, so this patch just reverts the regression I caused.  Sadly, because it requires understanding TEMPLATE_DECL, we can't simply update place_field.  Instead I temporarily stitch out unde

Re: [PATCHv2] Call braced_list_to_string after array size is fixed

On 08/24/2018 03:52 PM, Bernd Edlinger wrote: this updated patch fixes one regression with current trunk due to a new test case. Sorry for the confusion. The change to the previous version is: 1) the check to avoid folding on empty char arrays is restored. 2) A null-termination character is add

[PATCH 1/1] Move AESNI generation to Skylake and Goldmont

The instruction set first appeared with Westmere, but not all processors in that and the next few generations have the instructions. According to Wikipedia[1], the first generation in which all SKUs have AES instructions are Skylake and Goldmont. I can't find any Skylake, Kabylake, Kabylake-R or Ca

Re: [PATCHv2] Handle overlength strings in C++ FE

On 08/30/18 00:17, Jason Merrill wrote: > On Fri, Aug 24, 2018 at 4:02 PM, Bernd Edlinger > wrote: >> Hi! >> >> >> This is an alternative approach to handle overlength strings in the C++ FE. >> >> The difference to the previous version is that overlength >> STRING_CST never have a longer TREE_STRI

Re: [PATCH 1/1] Move AESNI generation to Skylake and Goldmont

On Thu, Aug 30, 2018 at 7:14 AM, Thiago Macieira wrote: > The instruction set first appeared with Westmere, but not all processors > in that and the next few generations have the instructions. According to > Wikipedia[1], the first generation in which all SKUs have AES > instructions are Skylake a

<    1   2