Hi Bill,
on 2021/9/13 上午12:34, Bill Schmidt wrote:
> Hi Kewen,
>
> I'll leave the continued review of the back-end parts of this to Segher, but
> I do have one long-term comment. The rs6000_builtin_info[code].mask field
> that you're relying on is going away as part of the built-in function
>
I reworked the fix today based on feedback from Jason and Jakub (thank
you), and the subject line is now outdated. I added another test for a
closely related bug that's also fixed here (dependent-expr11.C -- this one
would even fail without the second declaration). All the new tests in the
patch su
i'm going to commit 8 patches:
[PATCH 16/62] AVX512FP16: Add vsqrtph/vrsqrtph/vsqrtsh/vrsqrtsh.
[PATCH 17/62] AVX512FP16: Add testcase for vsqrtph/vsqrtsh/vrsqrtph/vrsqrtsh.
[PATCH 18/62] AVX512FP16: Add vrcpph/vrcpsh/vscalefph/vscalefsh.
[PATCH 19/62] AVX512FP16: Add testcase for vrcpph/vrcpsh/vs
On 9/13/21 11:07 AM, Tobias Burnus wrote:
On 13.09.21 18:59, Sandra Loosemore wrote:
On 9/13/21 10:51 AM, Jakub Jelinek wrote: >>> Wouldn't it be better to use the
__LDBL_* macros anyway and not rely on
float.h? The header doesn't want to test what float.h tells about the
long double type, bu
On Tue, Sep 14, 2021 at 10:06 AM Hongtao Liu wrote:
>
> On Tue, Sep 14, 2021 at 8:58 AM Andrew Pinski wrote:
> >
> > On Wed, Sep 8, 2021 at 2:55 AM Hongtao Liu via Gcc-patches
> > wrote:
> > >
> > > On Wed, Sep 8, 2021 at 5:33 PM Jakub Jelinek wrote:
> > > >
> > > > On Wed, Sep 08, 2021 at 05:2
On Tue, Sep 14, 2021 at 8:58 AM Andrew Pinski wrote:
>
> On Wed, Sep 8, 2021 at 2:55 AM Hongtao Liu via Gcc-patches
> wrote:
> >
> > On Wed, Sep 8, 2021 at 5:33 PM Jakub Jelinek wrote:
> > >
> > > On Wed, Sep 08, 2021 at 05:23:40PM +0800, Hongtao Liu wrote:
> > > > > Bootstrapped/regtested on x8
On 2021/9/13 16:17, Richard Biener wrote:
On Mon, 13 Sep 2021, Xionghu Luo wrote:
On 2021/9/10 21:54, Xionghu Luo via Gcc-patches wrote:
On 2021/9/9 18:55, Richard Biener wrote:
diff --git a/gcc/tree-ssa-loop-im.c b/gcc/tree-ssa-loop-im.c
index 5d6845478e7..4b187c2cdaf 100644
--- a/gcc
On Wed, Sep 8, 2021 at 2:55 AM Hongtao Liu via Gcc-patches
wrote:
>
> On Wed, Sep 8, 2021 at 5:33 PM Jakub Jelinek wrote:
> >
> > On Wed, Sep 08, 2021 at 05:23:40PM +0800, Hongtao Liu wrote:
> > > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> > > >
> > > Patch LGTM.
> >
On Mon, Sep 13, 2021 at 05:10:42PM -0500, Peter Bergner wrote:
> >>* config/rs6000/mma.md (unspec): Delete UNSPEC_MMA_XXSETACCZ.
> >>(unspecv): Add UNSPECV_MMA_XXSETACCZ.
> >
> > Unrelated to this patch, but I have been wondering this for years:
> > should we have an unspecv enum at all?
Signed-off-by: Benjamin Peterson
gcc/
* attribs.c (make_unique_name): Delete.
* attribs.h (make_unique_name): Delete.
---
gcc/attribs.c | 34 --
gcc/attribs.h | 1 -
2 files changed, 35 deletions(-)
diff --git a/gcc/attribs.c b/gcc/attribs.c
inde
On Wed, Sep 01, 2021 at 11:13:37AM -0500, Bill Schmidt wrote:
> Although this patch looks quite large, the changes are fairly minimal.
> Most of it is duplicating the large function that does the overload
> resolution using the automatically generated data structures instead of
> the old hand-gener
On Tue, 2021-09-14 at 03:35 +0900, Michel Morin via Gcc-patches wrote:
> Hi,
>
> PR77565 reports that, with the code `typdef int Int;`, GCC emits
> "did you mean 'typeof'?" instead of "did you mean 'typedef'?".
>
> This happens because the typo corrector determines that `typeof` is a
> candidate
On 9/12/21 2:26 PM, Segher Boessenkool wrote:
>> I also removed the mma_xxsetaccz define_expand and
>> define_insn_and_split and replaced it with a simple define_insn.
>
> In the future pleaase do that in a separate patch. That makes it *much*
> easier to read and review this.
Will do.
>>
On Linux/x86_64,
76b75018b3d053a890ebe155e47814de14b3c9fb is the first bad commit
commit 76b75018b3d053a890ebe155e47814de14b3c9fb
Author: Jason Merrill
Date: Thu Jul 15 15:30:17 2021 -0400
c++: implement C++17 hardware interference size
caused
FAIL: 29_atomics/atomic_flag/test_and_set/ex
Here, the union's constructor is defined to activate its empty data
member _M_rest, but during constexpr evaluation of this constructor the
subobject constructor call to O::O(&_M_rest, 42) produces no side
effects that actually activates the member, so the union still appears
uninitialized after th
I merged trunk revision 104c05c5284b7822d770ee51a7d91946c7e56d50 to
the gccgo branch.
Ian
On Wed, 2021-09-01 at 11:13 -0500, Bill Schmidt via Gcc-patches wrote:
> This patch just duplicates a couple of functions and adjusts them to use the
> new builtin names. There's no logical change otherwise.
>
> 2021-08-31 Bill Schmidt
>
> gcc/
> * config/rs6000/rs6000.c (rs6000-builtin
On 9/13/2021 10:52 AM, Koning, Paul wrote:
On Sep 13, 2021, at 3:31 AM, Richard Biener wrote:
This makes defaults.h choose DWARF2_DEBUG if PREFERRED_DEBUGGING_TYPE
is not specified by the target and NO_DEBUG if DWARF is not supported.
It also makes us warn when STABS is enabled and remove
Hi Folks
> On 10 Sep 2021, at 16:16, Jeff Law wrote:
> On 9/10/2021 1:19 AM, Richard Biener via Gcc-patches wrote:
>> This removes the always defined DARWIN_PREFER_DWARF and the code
>> guarded by it being not defined, removing the possibility to
>> default some i386 darwin configurations to STAB
On Wed, 2021-09-01 at 11:13 -0500, Bill Schmidt via Gcc-patches wrote:
> Peter Bergner recently added two new builtins __builtin_vsx_lxvp and
> __builtin_vsx_stxvp. These happened to break a pattern in MMA builtins that
> I had been using to automate gimple folding of MMA builtins. Previously,
>
On Wed, 2021-09-01 at 11:13 -0500, Bill Schmidt via Gcc-patches wrote:
> This is another patch that looks bigger than it really is. Because we
> have a new namespace for the builtins, allowing us to have both the old
> and new builtin infrastructure supported at once, we need versions of
> these f
Hi,
PR77565 reports that, with the code `typdef int Int;`, GCC emits
"did you mean 'typeof'?" instead of "did you mean 'typedef'?".
This happens because the typo corrector determines that `typeof` is a
candidate for suggestion (through `cp_keyword_starts_decl_specifier_p`),
but `typedef` is not.
On Mon, Sep 13, 2021 at 05:56:53PM +0200, Gerald Pfeifer wrote:
> % egrep -r '#define.*LDBL_(MANT_DIG|MIN_EXP|MAX_EXP)' /usr/include/
> /usr/include/x86/float.h:#define LDBL_MANT_DIG 64
> /usr/include/x86/float.h:#define LDBL_MIN_EXP (-16381)
> /usr/include/x86/float.h:#define LDBL_MAX_EXP 163
On Wed, 2021-09-01 at 11:13 -0500, Bill Schmidt via Gcc-patches wrote:
> I over-restricted use of __builtin_mffsl, since I was unaware that it
> automatically uses mffs when mffsl is not available. Paul Clarke
> pointed
> this out in discussion of his SSE 4.1 compatibility patches.
>
> 2021-08-31
On Sep 13 2021, Gerald Pfeifer wrote:
> % egrep -r '#define.*LDBL_(MANT_DIG|MIN_EXP|MAX_EXP)' /usr/include/
> /usr/include/x86/float.h:#define LDBL_MANT_DIG 64
> /usr/include/x86/float.h:#define LDBL_MIN_EXP (-16381)
> /usr/include/x86/float.h:#define LDBL_MAX_EXP 16384
>
> This looks like it
On Mon, Sep 13, 2021 at 07:07:01PM +0200, Tobias Burnus wrote:
> Regarding FreeBSD: Does this output different values? – If yes, we know
> what to do, otherwise – hmm.
>
> [...]
>
> > > Wouldn't it be better to use the __LDBL_* macros anyway and not rely on
> > > float.h? The header doesn't want
On Wed, 2021-09-01 at 11:13 -0500, Bill Schmidt via Gcc-patches wrote:
Hi,
Just a couple cosmetic nits noted below, the majority if which is also in
the original code this is based on.
THanks
-Will
> Although this patch looks quite large, the changes are fairly minimal.
> Most of it is dupl
On 13.09.21 18:59, Sandra Loosemore wrote:
On 9/13/21 10:51 AM, Jakub Jelinek wrote:
On Mon, Sep 13, 2021 at 06:32:56PM +0200, Tobias Burnus wrote:
On 13.09.21 17:56, Gerald Pfeifer wrote:
This broke bootstrap on i586-unknown-freebsd11:
% egrep -r '#define.*LDBL_(MANT_DIG|MIN_EXP|MAX_EXP)' /u
On 9/13/21 4:18 PM, Michael Matz wrote:
> Hello,
>
> On Mon, 13 Sep 2021, Jeff Law via Gcc-patches wrote:
>
>>> So it looks like there's some undefined behavior going on, even before
>>> my patch. I'd like to get some feedback, because this is usually the
>>> type of problems I see in the presence
On 9/13/21 10:51 AM, Jakub Jelinek wrote:
On Mon, Sep 13, 2021 at 06:32:56PM +0200, Tobias Burnus wrote:
On 13.09.21 17:56, Gerald Pfeifer wrote:
This broke bootstrap on i586-unknown-freebsd11:
In file included from
.../GCC-HEAD/libgfortran/runtime/ISO_Fortran_binding.c:30:
.../GCC-HE
> On Sep 13, 2021, at 3:31 AM, Richard Biener wrote:
>
> This makes defaults.h choose DWARF2_DEBUG if PREFERRED_DEBUGGING_TYPE
> is not specified by the target and NO_DEBUG if DWARF is not supported.
>
> It also makes us warn when STABS is enabled and removes the corresponding
> diagnostic fr
On Mon, Sep 13, 2021 at 06:32:56PM +0200, Tobias Burnus wrote:
> On 13.09.21 17:56, Gerald Pfeifer wrote:
> > This broke bootstrap on i586-unknown-freebsd11:
> >
> >In file included from
> > .../GCC-HEAD/libgfortran/runtime/ISO_Fortran_binding.c:30:
> >.../GCC-HEAD/libgfortran/ISO_Fortran
Hi Gerald,
On 13.09.21 17:56, Gerald Pfeifer wrote:
This broke bootstrap on i586-unknown-freebsd11:
In file included from
.../GCC-HEAD/libgfortran/runtime/ISO_Fortran_binding.c:30:
.../GCC-HEAD/libgfortran/ISO_Fortran_binding.h:255:2:
error: #error "Can't determine kind of long double
On Wed, 18 Aug 2021, Sandra Loosemore wrote:
> I realized last week that having multilib-specific versions of
> ISO_Fortran_binding.h (generated by running the compiler to ask what kinds it
> supports) was still broken outside of the test support; the directory where
> it's being installed isn't on
On 9/13/2021 9:44 AM, John David Anglin wrote:
On 2021-09-13 11:05 a.m., Jeff Law wrote:
On 9/13/2021 8:58 AM, John David Anglin wrote:
On 2021-09-13 9:53 a.m., Jeff Law wrote:
It is in fact also hpux11*, thus all 32bit pa configs that do not support
DWARF (for whatever reasons).
We used
On 2021-09-13 11:05 a.m., Jeff Law wrote:
>
>
> On 9/13/2021 8:58 AM, John David Anglin wrote:
>> On 2021-09-13 9:53 a.m., Jeff Law wrote:
It is in fact also hpux11*, thus all 32bit pa configs that do not support
DWARF (for whatever reasons).
>>> We used embedded stabs for SOM (the native
On Mon, Sep 13, 2021 at 10:10 PM Jeff Law via Gcc-patches
wrote:
>
>
>
> On 9/9/2021 10:36 PM, liuhongt via Gcc-patches wrote:
> >Currently for (vec_concat:M (vec_select op0 idx1)(vec_select op0 idx2)),
> > optimizer wouldn't simplify if op0 has different mode with M, but that's too
> > restri
On Mon, Sep 13, 2021 at 10:10 PM Jeff Law via Gcc-patches
wrote:
>
>
>
> On 9/9/2021 10:36 PM, liuhongt via Gcc-patches wrote:
> >Currently for (vec_concat:M (vec_select op0 idx1)(vec_select op0 idx2)),
> > optimizer wouldn't simplify if op0 has different mode with M, but that's too
> > restri
On 9/13/2021 8:58 AM, John David Anglin wrote:
On 2021-09-13 9:53 a.m., Jeff Law wrote:
It is in fact also hpux11*, thus all 32bit pa configs that do not support
DWARF (for whatever reasons).
We used embedded stabs for SOM (the native format for 32bit PA). SOM is a
variant of COFF and could
On 2021-09-13 9:53 a.m., Jeff Law wrote:
>> It is in fact also hpux11*, thus all 32bit pa configs that do not support
>> DWARF (for whatever reasons).
> We used embedded stabs for SOM (the native format for 32bit PA). SOM is a
> variant of COFF and could easily support dwarf I would think since
>
On Mon, Sep 13, 2021 at 4:40 PM Jakub Jelinek wrote:
> On Mon, Sep 13, 2021 at 01:57:52PM +0200, Christophe Lyon wrote:
> > > --- gcc/testsuite/c-c++-common/gomp/atomic-29.c.jj 2021-09-10
> > > 11:47:17.093164041 +0200
> > > +++ gcc/testsuite/c-c++-common/gomp/atomic-29.c 2021-09-10
> > > 11
On Mon, Sep 06, 2021 at 11:56:21AM +0200, Richard Biener wrote:
> On Fri, Sep 3, 2021 at 10:01 AM Stefan Schulze Frielinghaus
> wrote:
> >
> > On Fri, Aug 20, 2021 at 12:35:58PM +0200, Richard Biener wrote:
> > [...]
> > > > >
> > > > > + /* Handle strlen like loops. */
> > > > > + if (store_dr
On Sun, Sep 12, 2021 at 10:29 PM Jason Merrill wrote:
>
> On 9/12/21 7:48 PM, Patrick Palka wrote:
> > On Thu, 2 Sep 2021, Jason Merrill wrote:
> >
> >> On 8/30/21 10:05 PM, Patrick Palka wrote:
> >>> Here when partially substituting into the pack expansion, substitution
> >>> into the constexpr i
Hi Richard,
> -Original Message-
> From: Richard Sandiford
> Sent: 13 September 2021 12:09
> To: Kyrylo Tkachov
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] aarch64: PR target/102252 Invalid addressing mode for
> SVE load predicate
>
> Kyrylo Tkachov writes:
> > Hi all,
> >
> >
On Mon, Sep 13, 2021 at 01:57:52PM +0200, Christophe Lyon wrote:
> > --- gcc/testsuite/c-c++-common/gomp/atomic-29.c.jj 2021-09-10
> > 11:47:17.093164041 +0200
> > +++ gcc/testsuite/c-c++-common/gomp/atomic-29.c 2021-09-10
> > 11:52:33.428722747 +0200
> > @@ -0,0 +1,43 @@
> > +/* { dg-do compi
> On Fri, Sep 10, 2021 at 3:47 PM Jose E. Marchesi via Gcc-patches
> wrote:
>>
>>
>> Hi Richard.
>>
>> > On Thu, 9 Sep 2021, Kees Cook wrote:
>> >
>> >> On Thu, Sep 09, 2021 at 10:49:11PM +, Qing Zhao wrote:
>> >> > Hi, FYI
>> >> >
>> >> > I just committed the following patch to gcc upstream
This changes us to maintain and compute (mis-)alignment info for
the first element of a group only rather than for each DR when
doing interleaving and for the earliest, first, or first in the SLP
node (or any pair or all three of those) when SLP vectorizing.
For this to work out the easiest way I
On Thu, Aug 12, 2021 at 5:32 PM Martin Liška wrote:
>
> On 8/12/21 5:26 PM, H.J. Lu wrote:
> > Will it hurt if they have proper feature_priorities you added?
>
> No. They are unused, by we should use the proper priorities.
gcc/ChangeLog:
* common/config/i386/cpuinfo.h (cpu_indicator_init): Add s
On 9/13/2021 8:18 AM, Michael Matz wrote:
Hello,
On Mon, 13 Sep 2021, Jeff Law via Gcc-patches wrote:
So it looks like there's some undefined behavior going on, even before
my patch. I'd like to get some feedback, because this is usually the
type of problems I see in the presence of a smar
On Mon, Sep 13, 2021 at 4:10 PM Jeff Law via Gcc-patches
wrote:
>
>
>
> On 9/9/2021 10:36 PM, liuhongt via Gcc-patches wrote:
> >Currently for (vec_concat:M (vec_select op0 idx1)(vec_select op0 idx2)),
> > optimizer wouldn't simplify if op0 has different mode with M, but that's too
> > restric
Hello,
On Mon, 13 Sep 2021, Jeff Law via Gcc-patches wrote:
> > So it looks like there's some undefined behavior going on, even before
> > my patch. I'd like to get some feedback, because this is usually the
> > type of problems I see in the presence of a smarter threader... things
> > get shuff
On 9/9/2021 10:36 PM, liuhongt via Gcc-patches wrote:
Currently for (vec_concat:M (vec_select op0 idx1)(vec_select op0 idx2)),
optimizer wouldn't simplify if op0 has different mode with M, but that's too
restrict which will prevent below optimization, the condition can be relaxed
to op0 mus
On 9/10/2021 1:45 AM, Thomas Schwinge wrote:
0001-Simplify-gcc-diagnostic-spec.h-nowarn_map-setup.patch
From 095c16ead5d432726f2b6de5ce12fd367600076d Mon Sep 17 00:00:00 2001
From: Thomas Schwinge
Date: Wed, 1 Sep 2021 16:48:55 +0200
Subject: [PATCH 1/3] Simplify 'gcc/diagnostic-spec.h:now
On 9/13/2021 7:47 AM, Richard Biener wrote:
On Mon, 13 Sep 2021, Jeff Law wrote:
On 9/13/2021 1:31 AM, Richard Biener wrote:
This makes defaults.h choose DWARF2_DEBUG if PREFERRED_DEBUGGING_TYPE
is not specified by the target and NO_DEBUG if DWARF is not supported.
It also makes us warn w
On 8/27/21 11:05, Richard Biener wrote:
So with ignoring darktable which seems completely insane the cases
will likely continue
to work as intended if we change from the current scheme to appending
as proposed.
All right, I'm addressing the flag_complex_method in a separate sub-thread.
There's
On Mon, 13 Sep 2021, Jeff Law wrote:
>
>
> On 9/13/2021 1:31 AM, Richard Biener wrote:
> > This makes defaults.h choose DWARF2_DEBUG if PREFERRED_DEBUGGING_TYPE
> > is not specified by the target and NO_DEBUG if DWARF is not supported.
> >
> > It also makes us warn when STABS is enabled and remo
On 9/13/2021 7:29 AM, Aldy Hernandez wrote:
Jeff has pointed out that after my change adding global ranges to the
path solver, torture/pr55107.c is failing. Before I start digging
deep into the IL, I'd like to make sure this is not either expected or
a bogus test.
Compiling this test on x86
On Tue, Sep 7, 2021 at 8:01 PM H.J. Lu wrote:
>
> On Sun, Aug 22, 2021 at 8:28 AM H.J. Lu wrote:
> >
> > On Tue, Mar 23, 2021 at 09:19:38AM +0100, Richard Biener wrote:
> > > On Tue, Mar 23, 2021 at 3:41 AM Hongyu Wang
> > > wrote:
> > > >
> > > > > Hongyue, please collect code size differences
On 9/11/2021 12:01 PM, Aldy Hernandez wrote:
So another thing to consider is that the threaders initially record
their paths in different directions. Forward threading records
starting at the first block, backward from the final block. At some
point (I no longer remember where) we invert
PING^1
On 9/7/21 11:43, Martin Liška wrote:
Hi.
I'm planning some refactoring related to 'section *' and I noticed we have
quite ugly mask definitions (of form 1UL << N), where SECTION_FORGET is unused
and
#define SECTION_STYLE_MASK 0x60 /* bits used for SECTION_STYLE */
Is actually OR
On 9/13/2021 3:54 AM, Aldy Hernandez wrote:
Now that the jump thread back registry has been split into the generic
copier and the custom (old) copier, it becomes trivial to remove the
FSM bits from the jump threaders.
First, there's no need for an EDGE_FSM_THREAD type. The only reason
we wer
Ping.
Message-Id:
Thanks!
Bill
On 9/1/21 11:13 AM, Bill Schmidt via Gcc-patches wrote:
Hi!
Original patch series here:
https://gcc.gnu.org/pipermail/gcc-patches/2021-April/568840.html
V2 patch series here:
https://gcc.gnu.org/pipermail/gcc-patches/2021-June/572231.html
V3 patch series here
PING^1
On 9/7/21 11:42, Martin Liška wrote:
On 9/6/21 14:16, Richard Biener wrote:
On Mon, Sep 6, 2021 at 1:46 PM Jakub Jelinek wrote:
On Mon, Sep 06, 2021 at 01:37:46PM +0200, Martin Liška wrote:
--- a/gcc/opts.c
+++ b/gcc/opts.c
@@ -1323,6 +1323,14 @@ finish_options (struct gcc_options *o
Jeff has pointed out that after my change adding global ranges to the
path solver, torture/pr55107.c is failing. Before I start digging
deep into the IL, I'd like to make sure this is not either expected or
a bogus test.
Compiling this test on x86 with -Wall yields:
$ gcc -c -O2 pr55107.c -Wall
PING^1
On 8/13/21 15:41, H.J. Lu wrote:
On Fri, Aug 13, 2021 at 1:10 AM Martin Liška wrote:
On 8/12/21 7:35 PM, H.J. Lu wrote:
What happens for arch=x86-64-v5?
pr101696.c:5:55: error: bad value (‘x86-64-v5’) for ‘target("arch=")’ attribute
5 | __attribute__ ((target ("arch=x86-64-v5
On 9/13/2021 1:31 AM, Richard Biener wrote:
This makes defaults.h choose DWARF2_DEBUG if PREFERRED_DEBUGGING_TYPE
is not specified by the target and NO_DEBUG if DWARF is not supported.
It also makes us warn when STABS is enabled and removes the corresponding
diagnostic from the Ada frontend.
On 9/13/2021 1:11 AM, apinski--- via Gcc-patches wrote:
From: Andrew Pinski
m32r support never made it to glibc and the support for the Linux kernel
was removed with 4.18. It does not remove much but no reason to keep
around a port which never worked or one which the support in other
project
On 9/13/2021 5:36 AM, Richard Biener wrote:
This removes m68k-openbsd as a valid configuration, according
to openbsd.org m68k-openbsd [on the mac] was discontinued after
the 5.1 release. The configuration is also not (or no longer)
supported by gas and GNU ld so I could not figure whether it
On 9/13/2021 5:41 AM, Richard Biener via Gcc-patches wrote:
This removes the support for vax-openbsd which has been discontinued
after the OpenBSD 5.9 release and which has no supported gas or GNU ld
configuration [anymore]. In particular this target does only support
STABS debuginfo generati
On Mon, Sep 13, 2021 at 1:49 PM Christophe Lyon
wrote:
> This last test now fails on aarch64:
> FAIL: gcc.dg/tree-ssa/ssa-dom-thread-7.c scan-tree-dump thread3 "Jumps
> threaded: 8"
>
> Can you check?
These rather large tests checking for some random number of jump
threads are very annoying.
Hi!
Gcc5 has implemented 'SSO'. The length of small string local buffer is 15,
which
is enough to store an integer. So we can use
'numeric_limits::digits+1' to
get the max length of int instead of dynamically obtaining the length of
the
integer through __to_chars_len. In this way, I will get a per
On Fri, Sep 10, 2021 at 8:47 PM Jakub Jelinek via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
> Hi!
>
> This patch implements OpenMP 5.1 atomics (with clarifications from
> upcoming 5.2).
> The most important changes are that it is now possible to write (for C/C++,
> for Fortran it was possible
On Fri, Sep 10, 2021 at 6:32 PM Jeff Law via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
>
>
> On 9/10/2021 7:53 AM, Aldy Hernandez via Gcc-patches wrote:
> >
> >
> > On 9/10/21 3:16 PM, Michael Matz wrote:
> >> Hi,
> >>
> >> On Fri, 10 Sep 2021, Aldy Hernandez via Gcc-patches wrote:
> >>
> >>>
On Mon, Sep 13, 2021 at 1:14 PM Hongtao Liu wrote:
>
> On Mon, Sep 13, 2021 at 5:15 PM Richard Biener
> wrote:
> >
> > On Mon, Sep 13, 2021 at 8:26 AM Hongtao Liu wrote:
> > >
> > > On Mon, Sep 13, 2021 at 2:11 PM Richard Biener via Gcc-patches
> > > wrote:
> > > >
> > > > On Fri, Sep 10, 2021
On 13.09.21 13:14, Hongtao Liu via Gcc-patches wrote:
Yes, update patch
bootstrapped and regtested on x86_64-linux-gnu{-m32,}.
Ok for trunk?
If that patch gets approved, can you add PR bootstrap/102302 to the
commit changelog ?
cf. https://gcc.gnu.org/PR102302
Thanks,
Tobias
gcc/Chang
apinski--- via Gcc-patches writes:
> From: Andrew Pinski
>
> This patch adds simple folding of __builtin_aarch64_im_lane_boundsi where
> we are not going to error out. It fixes the problem by the removal
> of the function from the IR.
>
> OK? Bootstrapped and tested on aarch64-linux-gnu with no r
This removes the support for vax-openbsd which has been discontinued
after the OpenBSD 5.9 release and which has no supported gas or GNU ld
configuration [anymore]. In particular this target does only support
STABS debuginfo generation.
OK for trunk?
Thanks,
Richard.
2021-09-13 Richard Biener
This removes m68k-openbsd as a valid configuration, according
to openbsd.org m68k-openbsd [on the mac] was discontinued after
the 5.1 release. The configuration is also not (or no longer)
supported by gas and GNU ld so I could not figure whether it is still
a.out (I suspect it is). But first and
We need to use the pointer equivalence tracking from evrp in the jump
threader. Instead of moving it to some *evrp.h header, it's cleaner for
it to live in its own file, since it's completely independent and not
evrp specific.
Tested on x86-64 Linux.
gcc/ChangeLog:
* Makefile.in (OBJS):
On Mon, Sep 13, 2021 at 5:15 PM Richard Biener
wrote:
>
> On Mon, Sep 13, 2021 at 8:26 AM Hongtao Liu wrote:
> >
> > On Mon, Sep 13, 2021 at 2:11 PM Richard Biener via Gcc-patches
> > wrote:
> > >
> > > On Fri, Sep 10, 2021 at 2:58 PM liuhongt wrote:
> > > >
> > > > gcc/ChangeLog:
> > > >
> > >
Kyrylo Tkachov writes:
> Hi all,
>
> In the testcase we generate invalid assembly for an SVE load predicate
> instruction.
> The RTL for the insn is:
> (insn 9 8 10 (set (reg:VNx16BI 68 p0)
> (mem:VNx16BI (plus:DI (mult:DI (reg:DI 1 x1 [93])
> (const_int 8 [0x8]))
>
On Mon, Sep 13, 2021 at 11:42:08AM +0100, Roger Sayle wrote:
> gcc/c-family/ChangeLog
> PR c/102245
> * c-common.c (c_common_truthvalue_conversion) [LSHIFT_EXPR]:
> Special case (optimize) shifts by zero.
>
> gcc/testsuite/ChangeLog
> PR c/102245
> * gcc.dg/Wint-in-bo
If the tree expression X is a truthvalue, then X << 0 is a truthvalue.
In fact, because _Bool (truthvalue_type) has 1 bit precision, and shifts
are only well defined for bit counts less than the precision, the only
reasonable(?) left shift of a _Bool is by zero [where this reasonable
overlooks tha
Hi!
On Mon, 2021-09-13 11:58:59 +0200, Richard Biener wrote:
> On Mon, 13 Sep 2021, Jan-Benedict Glaw wrote:
> > contrib/ChangeLog:
> >
> > * config-list.mk (LIST): --enable-obsolete for cr16-elf.
> >
[...]
> OK.
Committed, thanks!
MfG, JBG
--
signature.asc
Description: PGP signature
Hi!
On Mon, 2021-09-13 11:11:30 +0200, Richard Biener
wrote:
> On Sun, Sep 12, 2021 at 8:12 PM Jan-Benedict Glaw wrote:
> > gcc/ChangeLog:
> >
> > * config/alpha/vms.h (INIT_CUMULATIVE_ARGS): Wrap multi-statment
> > define into a block.
> OK.
Committed, thanks!
MfG, JBG
--
On Mon, 13 Sep 2021, Jan-Benedict Glaw wrote:
> Hi Richard,
>
> On Mon, 2021-09-13 11:24:53 +0200, Richard Biener via Gcc-patches
> wrote:
> > This adds cr16-*-* to the list of obsoleted targets in config.gcc
> >
> > Approved by Jeff in another thread, pushed. cr16 has no maintainer and
> > i
Hi Richard,
On Mon, 2021-09-13 11:24:53 +0200, Richard Biener via Gcc-patches
wrote:
> This adds cr16-*-* to the list of obsoleted targets in config.gcc
>
> Approved by Jeff in another thread, pushed. cr16 has no maintainer and
> it's still cc0.
>
> 2021-09-13 Richard Biener
>
> * c
Richard Earnshaw writes:
> On 13/09/2021 10:38, Richard Sandiford via Gcc-patches wrote:
>> Richard Earnshaw via Gcc-patches writes:
>>> gen_lowpart_general handles forming a lowpart of a MEM by using
>>> adjust_address to rework and validate a new version of the MEM.
>>> Do the same for gen_high
Now that the jump thread back registry has been split into the generic
copier and the custom (old) copier, it becomes trivial to remove the
FSM bits from the jump threaders.
First, there's no need for an EDGE_FSM_THREAD type. The only reason
we were looking at the threading type was to determine
On 13/09/2021 10:38, Richard Sandiford via Gcc-patches wrote:
Richard Earnshaw via Gcc-patches writes:
gen_lowpart_general handles forming a lowpart of a MEM by using
adjust_address to rework and validate a new version of the MEM.
Do the same for gen_highpart rather than calling simplify_gen
Richard Earnshaw via Gcc-patches writes:
> gen_lowpart_general handles forming a lowpart of a MEM by using
> adjust_address to rework and validate a new version of the MEM.
> Do the same for gen_highpart rather than calling simplify_gen_subreg
> for this case.
Looks OK, but what went wrong with t
On Fri, Sep 10, 2021 at 4:48 PM Richard Earnshaw wrote:
>
>
> gen_lowpart_general handles forming a lowpart of a MEM by using
> adjust_address to rework and validate a new version of the MEM.
> Do the same for gen_highpart rather than calling simplify_gen_subreg
> for this case.
OK from my side.
On Fri, Sep 10, 2021 at 3:47 PM Jose E. Marchesi via Gcc-patches
wrote:
>
>
> Hi Richard.
>
> > On Thu, 9 Sep 2021, Kees Cook wrote:
> >
> >> On Thu, Sep 09, 2021 at 10:49:11PM +, Qing Zhao wrote:
> >> > Hi, FYI
> >> >
> >> > I just committed the following patch to gcc upstream:
> >> >
> >> >
With the last adjustment I failed to remove a stray
Pushed.
2021-09-13 Richard Biener
* config/i386/lynx.h: Remove undef of PREFERRED_DEBUGGING_TYPE
to inherit from elfos.h
---
gcc/config/i386/lynx.h | 4
1 file changed, 4 deletions(-)
diff --git a/gcc/config/i386/lynx.
On Mon, 13 Sep 2021, Jan-Benedict Glaw wrote:
> Hi Richard,
>
> On Fri, 2021-09-10 08:02:00 +0200, Richard Biener via Gcc-patches
> wrote:
> > > On 9/9/2021 7:19 AM, Richard Biener via Gcc-patches wrote:
> > > > The patch also removes the PREFERRED_DEBUGGING_TYPE define from
> > > > lynx.h whic
This adds cr16-*-* to the list of obsoleted targets in config.gcc
Approved by Jeff in another thread, pushed. cr16 has no maintainer and
it's still cc0.
2021-09-13 Richard Biener
* config.gcc: Add cr16-*-* to the list of obsoleted targets.
---
gcc/config.gcc | 1 +
1 file changed, 1
On Mon, Sep 13, 2021 at 8:26 AM Hongtao Liu wrote:
>
> On Mon, Sep 13, 2021 at 2:11 PM Richard Biener via Gcc-patches
> wrote:
> >
> > On Fri, Sep 10, 2021 at 2:58 PM liuhongt wrote:
> > >
> > > gcc/ChangeLog:
> > >
> > > * expmed.c (extract_bit_field_using_extv): validate_subreg
> > >
On Sun, Sep 12, 2021 at 8:12 PM Jan-Benedict Glaw wrote:
>
> Hi!
>
> While mass-building a cross-gcc, I noticed that for
> alpha-dec-vms/alpha64-dec-vms, recent GCC versions correctly throw a warning
> due to a multi-statement define that gets rippen in an if/else case:
>
> [all 2021-09-12 15:51:5
On Sun, Sep 12, 2021 at 6:12 PM apinski--- via Gcc-patches
wrote:
>
> From: Andrew Pinski
>
> So right now liblto_plugin.so exports many libiberty symbols and
> simple_object file symbols but really it just needs to export onload.
>
> This fixes the problem by using "-export-symbols-regex onload"
On Fri, Sep 10, 2021 at 5:07 PM Segher Boessenkool
wrote:
>
> On Fri, Sep 10, 2021 at 12:53:37PM +0200, Richard Biener wrote:
> > On Fri, Sep 10, 2021 at 1:50 AM Segher Boessenkool
> > wrote:
> > > And many targets have strange rules for bit-strings in which modes can
> > > be used as bit-strings
1 - 100 of 111 matches
Mail list logo
