Hi!
And ditto for powerpc. Written as separate patch because it was dependent
on the no-strict-aliasing patch.
Committed to trunk as obvious.
2021-01-22 Jakub Jelinek
* gcc.target/powerpc/m128-check.h (CHECK_EXP, CHECK_FP_EXP): Fix a
typo, UINON_TYPE to UNION_TYPE.
--- gcc/t
On Fri, Jan 22, 2021 at 04:44:42PM -0500, Jason Merrill wrote:
> On 1/22/21 4:01 PM, Marek Polacek wrote:
> > On Thu, Jan 21, 2021 at 09:47:35PM -0500, Jason Merrill via Gcc-patches
> > wrote:
> > > On 1/21/21 5:45 PM, Marek Polacek wrote:
> > > > I discovered very strange code in inject_parm_decl
This is referenced by my recent release notes changes for GCC 11:
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/564164.html
Pushed as 9cead79073862f207c1df4f7bcacb6e43d01384f.
gcc/ChangeLog:
* doc/invoke.texi (GCC_EXTRA_DIAGNOSTIC_OUTPUT): Add @findex
directive.
---
gc
Hi Jason,
Attached changes. I just edited the patch file directly.
Kind regards,
Anthony
From 7984020f16e715017e62b8637d2e69c1aec3478a Mon Sep 17 00:00:00 2001
From: Anthony Sharp
Date: Thu, 21 Jan 2021 15:26:25 +
Subject: [PATCH] c++: Private inheritance access diagnostics fix [PR17314]
Th
Hi Jakub,
On Fri, Jan 22, 2021 at 07:02:04PM +0100, Jakub Jelinek wrote:
> The x86 __m64 type is defined as:
> /* The Intel API is flexible enough that we must allow aliasing with other
>vector types, and their scalar components. */
> typedef int __m64 __attribute__ ((__vector_size__ (8), __m
On Fri, Jan 22, 2021 at 05:45:54PM -0600, Segher Boessenkool wrote:
> On Fri, Jan 22, 2021 at 07:02:04PM +0100, Jakub Jelinek wrote:
> > The x86 __m64 type is defined as:
> > /* The Intel API is flexible enough that we must allow aliasing with other
> >vector types, and their scalar components.
On Sat, Jan 23, 2021 at 01:03:31AM +0100, Jakub Jelinek via Gcc-patches wrote:
> The problem is that the testcase uses the
> _mm_loadl_pi
> API, and per the Intel intrinsic rules it is ok when that intrinsic
> loads from wide range of types, e.g. including pairs of integers or
> 4 shorts or 8 chars
Hi!
On Fri, Jan 22, 2021 at 08:02:28PM +0100, Jakub Jelinek wrote:
> On Mon, Sep 21, 2020 at 10:12:20AM +0200, Richard Biener wrote:
> > On Mon, 21 Sep 2020, Jan Hubicka wrote:
> > > these testcases now fails because they contains an invalid type puning
> > > that happens via const VALUE_TYPE *v p
On Fri, Jan 22, 2021 at 03:02:47PM -0500, David Edelsohn wrote:
> All of these testcases no fail on AIX. This was not tested properly.
> Please fix.
They fail on -m32 Linux as well: all failures are an unexpected count
of addi insns. This may be related to the LRA regression we have (just
based
Those are the fold-vec-extract-* changes. And they fix a regression
on AIX. Another difference to detangle.
I'm referring to the new fold-vec-insert-* failures. I fixed the p9
failures, but some of the tests now ICE when targeting P8.
Thanks, David
On Fri, Jan 22, 2021 at 8:03 PM Segher Boess
Hi!
On Sat, Jan 23, 2021 at 01:03:31AM +0100, Jakub Jelinek wrote:
> On Fri, Jan 22, 2021 at 05:45:54PM -0600, Segher Boessenkool wrote:
> > On Fri, Jan 22, 2021 at 07:02:04PM +0100, Jakub Jelinek wrote:
> > > The x86 __m64 type is defined as:
> > > /* The Intel API is flexible enough that we must
101 - 111 of 111 matches
Mail list logo