From: Andrew Pinski
Even though this does not change the generated code,
it does improve the initial RTL generation.
gcc/ChangeLog:
* tree-ssa-math-opts.c (match_arith_overflow):
Add range and nonzero bits information to
the new overflow ssa name. Also fold
the
From: Andrew Pinski
I noticed this while Richard B. fixing PR101756.
Basically min of two bools is the same as doing an "and"
and max of two bools is doing an "ior".
gcc/ChangeLog:
* match.pd: Add min/max patterns for bool types.
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/bool
From: Andrew Pinski
While working on some more boolean optimizations, I noticed
that there are places which does SSA_NAME@0 and then look
at then either use get_nonzero_bits or ssa_name_has_boolean_range
to see if the ssa name had a boolean range. This cleans this
up slightly by have a simple mat
On Fri, Aug 13, 2021 at 04:33:26PM -0400, David Edelsohn wrote:
> There is a song from Sesame Street: "Which of these is not like the
> others?" altivec.md seems like an outlier. crypto.md and vsx.md also
> seem unusual.
>
> We have
>
> register_operand
> gpc_reg_operand
> altivec_register_oper
On Fri, 13 Aug 2021 09:52:53 -0700
Ian Lance Taylor wrote:
> On Fri, Aug 13, 2021 at 12:05 AM Sergei Trofimovich wrote:
> >
> > On Thu, 12 Aug 2021 16:16:04 -0700
> > Ian Lance Taylor wrote:
> >
> > > On Thu, Aug 12, 2021 at 3:34 PM Sergei Trofimovich via Gcc-patches
> > > wrote:
> > > >
>
Hi Ian,
> Sorry about that. I've committed this patch.
thanks.
unfortunately, things are considerably worse: syscall.lo fails to build
and go1 even ICEs:
/vol/gcc/src/hg/master/local/libgo/go/syscall/libcall_posix_utimesnano.go:13:1:
error: redefinition of ‘UtimesNano’
13 | func UtimesNano
Hi!
On 2021-08-12T22:48:33+0200, Jakub Jelinek via Gcc-patches
wrote:
> The patch also contains something I should have done much earlier,
... and as its own commit... ;-|
> for clauses that accept some integral expression where we only care
> about the value, forces during gimplification tha
On Fri, Aug 13, 2021 at 4:24 PM Segher Boessenkool
wrote:
>
> On Fri, Aug 13, 2021 at 02:07:25PM -0400, David Edelsohn wrote:
> > On Fri, Aug 13, 2021 at 12:08 PM Segher Boessenkool
> > wrote:
> > >
> > > On Fri, Aug 13, 2021 at 11:15:21AM -0400, David Edelsohn wrote:
> > > > On Fri, Aug 13, 2021
On Fri, Aug 13, 2021 at 02:07:25PM -0400, David Edelsohn wrote:
> On Fri, Aug 13, 2021 at 12:08 PM Segher Boessenkool
> wrote:
> >
> > On Fri, Aug 13, 2021 at 11:15:21AM -0400, David Edelsohn wrote:
> > > On Fri, Aug 13, 2021 at 10:49 AM Segher Boessenkool
> > > wrote:
> > > >
> > > > On Fri, Aug
On 13.08.21 16:37, Tobias Burnus wrote:
When converting the C/C++ runtime testcase to Fortran, I did run into
a bug:
https://gcc.gnu.org/PR101899 (see PR or testcase; related to 'omp
taskloop'.)
I am any more sure whether it is a bug or not or what is the bug (see
PR) – however, for this patch
From: Andrew Pinski
So the problem here is there is code in the C++ front-end not to add a
break statement (to the IR) if the previous block does not fall through.
The problem is the code which does the check to see if the block
may fallthrough does not check a CLEANUP_STMT; it assumes it is alwa
On Fri, Aug 13, 2021 at 12:08 PM Segher Boessenkool
wrote:
>
> On Fri, Aug 13, 2021 at 11:15:21AM -0400, David Edelsohn wrote:
> > On Fri, Aug 13, 2021 at 10:49 AM Segher Boessenkool
> > wrote:
> > >
> > > On Fri, Aug 13, 2021 at 12:14:14AM -0400, Michael Meissner wrote:
> > > > I noticed that th
Ping.
On Thu, Aug 5, 2021 at 11:11 AM Christoph Müllner wrote:
>
> Ping.
>
> On Thu, Jul 29, 2021 at 9:36 PM Christoph Müllner
> wrote:
> >
> > On Thu, Jul 29, 2021 at 8:54 PM Palmer Dabbelt wrote:
> > >
> > > On Tue, 27 Jul 2021 02:32:12 PDT (-0700), cmuell...@gcc.gnu.org wrote:
> > > > Ok, s
Ping.
On Thu, Aug 5, 2021 at 11:11 AM Christoph Müllner wrote:
>
> Ping.
>
> On Thu, Jul 29, 2021 at 4:33 PM Christoph Muellner
> wrote:
> >
> > The RISC-V cpymemsi expansion is called, whenever the by-pieces
> > infrastructure will not be taking care of the builtin expansion.
> > Currently, tha
On Fri, Aug 13, 2021 at 5:43 AM Rainer Orth
wrote:
>
> Hi Ian,
>
> > This patch updates libgo from the Go1.16.5 release to the Go 1.17rc2
> > release. As usual with these version updates, the patch itself is too
> > large to attach to this e-mail message. I've attached the changes to
> > files
On Linux/x86_64,
4341b1b165751e728692eec12405fc04b2c681aa is the first bad commit
commit 4341b1b165751e728692eec12405fc04b2c681aa
Author: Jan Hubicka
Date: Fri Aug 13 10:04:52 2021 +0200
Introduce EAF_NOREAD and cleanup EAF_UNUSED + ipa-modref
caused
FAIL: g++.dg/warn/uninit-1.C -std=gn
Hi Segher, thank you for the review, I'll work on the issues you pointed.
On 13/08/2021 13:04, Segher Boessenkool wrote:
Hi!
On Fri, Aug 13, 2021 at 10:46:37AM -0300, Raphael Moreira Zinsly wrote:
* config/rs6000/linux-unwind.h (struct rt_sigframe): Move it to
outside of get_re
On Fri, 13 Aug 2021, Andreas Schwab wrote:
> On Aug 12 2021, Patrick McGehearty via Gcc-patches wrote:
>
> > diff --git a/libgcc/config/rs6000/_divkc3.c b/libgcc/config/rs6000/_divkc3.c
> > index a1d29d2..2b229c8 100644
> > --- a/libgcc/config/rs6000/_divkc3.c
> > +++ b/libgcc/config/rs6000/_divk
Hi Peter,
On 8/13/21 12:01 PM, Peter Bergner wrote:
On 8/12/21 1:20 PM, David Edelsohn wrote:
On Tue, Aug 10, 2021 at 7:37 PM Peter Bergner wrote:
gcc/
PR target/101849
* config/rs6000/rs6000-call.c (rs6000_gimple_fold_mma_builtin): Cast
pointer to __vector_pair *.
On Thu, 12 Aug 2021, Patrick McGehearty via Gcc-patches wrote:
> If _divkc3.c is not intended to provide a version of complex divide
> that handles IBM-128 format, then where should that option be handled?
That should be the function __divtc3. (A single libgcc binary supports
multiple long doub
On 8/12/21 1:20 PM, David Edelsohn wrote:
> On Tue, Aug 10, 2021 at 7:37 PM Peter Bergner wrote:
>> gcc/
>> PR target/101849
>> * config/rs6000/rs6000-call.c (rs6000_gimple_fold_mma_builtin): Cast
>> pointer to __vector_pair *.
>>
>> gcc/testsuite/
>> PR target/1018
On 8/12/2021 9:24 AM, Martin Liška wrote:
When we have a target_clone *declaration*, it does not make sense doing
the default version local. The use-case in the PR is that the reporter
wants to implement the function in assembly.
Patch can bootstrap on x86_64-linux-gnu and survives regression
On 8/13/2021 7:47 AM, Martin Liška wrote:
Hello.
Currently, the IPA ICF pass optimistically assumes that SSA NAMES do
match.
It's fine, but we should match SSA_NAME_IS_DEFAULT_DEF, otherwise we get
the verification error where a pair of SSA_NAMEs is equal, but hash
values
do differ.
Patc
On Fri, Aug 13, 2021 at 12:05 AM Sergei Trofimovich wrote:
>
> On Thu, 12 Aug 2021 16:16:04 -0700
> Ian Lance Taylor wrote:
>
> > On Thu, Aug 12, 2021 at 3:34 PM Sergei Trofimovich via Gcc-patches
> > wrote:
> > >
> > > From: Sergei Trofimovich
> > >
> > > I noticed test failures when ran gcc t
Hi,
On 8/12/21 3:43 PM, Bill Schmidt via Gcc-patches wrote:
Per discussion with Martin, I'm also changing the post-increment to
pre-increment in safe_inc_pos. That's what I'm regstrapping at the moment.
Thanks,
Bill
On 8/12/21 3:28 PM, Bill Schmidt via Gcc-patches wrote:
Although safe_inc_po
On Fri, Aug 13, 2021 at 11:15:21AM -0400, David Edelsohn wrote:
> On Fri, Aug 13, 2021 at 10:49 AM Segher Boessenkool
> wrote:
> >
> > On Fri, Aug 13, 2021 at 12:14:14AM -0400, Michael Meissner wrote:
> > > I noticed that the xxeval built-in function used the
> > > altivec_register_operand
> > >
Hi!
On Fri, Aug 13, 2021 at 10:46:37AM -0300, Raphael Moreira Zinsly wrote:
> * config/rs6000/linux-unwind.h (struct rt_sigframe): Move it to
> outside of get_regs() in order to use it in another function.
Say you do this twice, once for __powerpc64__, once for !__powerpc64__?
>
On Fri, Aug 13, 2021 at 10:49 AM Segher Boessenkool
wrote:
>
> On Fri, Aug 13, 2021 at 12:14:14AM -0400, Michael Meissner wrote:
> > I noticed that the xxeval built-in function used the
> > altivec_register_operand
> > predicate. Since it takes vsx registers, this might force the register
> > al
On Fri, Aug 13, 2021 at 12:14:14AM -0400, Michael Meissner wrote:
> I noticed that the xxeval built-in function used the altivec_register_operand
> predicate. Since it takes vsx registers, this might force the register
> allocate to issue a move when it could use a traditional floating point
> reg
Hi all, hi Jakub,
On 12.08.21 22:48, Jakub Jelinek via Gcc-patches wrote:
This construct has been introduced as a replacement for master
construct, but unlike that construct is slightly more general,
has an optional clause which allows to choose which thread
will be the one running the region, i
Update the OpenMP section again, now that Jakub has added the 'masked'
construct.
Comments?
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; S
On 8/13/21 12:31 PM, Jan Hubicka wrote:
Hi.
This is a first part fixing the PR. It makes sense making "naked" functions
"noipa".
What's missing is IPA MOD pass support where the pass should not optimize fns
with "noipa" attributes.
@Honza: Can you please implement that?
Hmm, I had patch for
On Fri, Aug 13, 2021 at 12:14 AM Michael Meissner
wrote:
>
> Fix xxeval predicates (PR 99921).
>
> I originally posted this patch in May and in June. I'm reposting it now.
>
> I noticed that the xxeval built-in function used the altivec_register_operand
> predicate. Since it takes vsx registers,
1. Intrinsics in only require GPR ISAs. Add
#if defined __MMX__ || defined __SSE__
#pragma GCC push_options
#pragma GCC target("general-regs-only")
#define __DISABLE_GENERAL_REGS_ONLY__
#endif
and
#ifdef __DISABLE_GENERAL_REGS_ONLY__
#undef __DISABLE_GENERAL_REGS_ONLY__
#pragma GCC pop
Add -mmwait so that the MWAIT and MONITOR intrinsics can be used with
-mgeneral-regs-only and make -msse3 to imply -mmwait.
gcc/
* config.gcc: Install mwaitintrin.h for i[34567]86-*-* and
x86_64-*-* targets.
* common/config/i386/i386-common.c (OPTION_MASK_ISA2_MWAIT_SET):
and target("general-regs-only") function attribute
were added to GCC 11. But their implementations are incomplete. I'd
like to backport the following patches to GCC 11 branch to finish them.
H.J. Lu (5):
x86: Add -mmwait for -mgeneral-regs-only
x86: Use crc32 target option for CRC32 intrins
For -mgeneral-regs-only, enable the GPR only instructions which are
enabled implicitly by SSE ISAs unless they have been disabled explicitly.
gcc/
PR target/101492
* common/config/i386/i386-common.c (ix86_handle_option): For
-mgeneral-regs-only, enable the GPR only instruc
Use crc32 target option for CRC32 intrinsics to support CRC32 intrinsics
without enabling SSE vector instructions.
* config/i386/i386-c.c (ix86_target_macros_internal): Define
__CRC32__ for -mcrc32.
* config/i386/i386-options.c (ix86_option_override_internal):
Enabl
Since
commit 39671f87b2df6a1894cc11a161e4a7949d1ddccd
Author: H.J. Lu
Date: Thu Apr 15 05:59:48 2021 -0700
x86: Use crc32 target option for CRC32 intrinsics
enabled OPTION_MASK_ISA_CRC32 for -msse4 and removed TARGET_SSE4_2 check
in sse4_2_crc32 pattens, remove OPTION_MASK_ISA_SSE4_2 from
It's backport of 8bf728aecc4fea46b4490e950b9ae229f90597b0, where I'm not willing
to introduce a new warning.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests on gcc-11
branch.
I'm going to push the revision.
Martin
PR gcov-profile/100788
gcc/ChangeLog:
*
Hello.
Currently, the IPA ICF pass optimistically assumes that SSA NAMES do match.
It's fine, but we should match SSA_NAME_IS_DEFAULT_DEF, otherwise we get
the verification error where a pair of SSA_NAMEs is equal, but hash values
do differ.
Patch can bootstrap on x86_64-linux-gnu and survives r
This is followup to this RFC:
https://gcc.gnu.org/pipermail/gcc-patches/2021-June/573954.html
---8<---
Without dwarf2 unwind tables available _Unwind_Backtrace() is not
able to return the full backtrace.
This patch adds a fallback function on powerpc to get the backtrace
by doing a backchain, th
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"))) void foo () {
> __builti
Hi Ian,
> This patch updates libgo from the Go1.16.5 release to the Go 1.17rc2
> release. As usual with these version updates, the patch itself is too
> large to attach to this e-mail message. I've attached the changes to
> files that are specific to gccgo. Bootstraped and ran Go testsuite on
>
On Thu, 5 Aug 2021 at 15:37, Prathamesh Kulkarni
wrote:
>
> On Thu, 29 Jul 2021 at 19:58, Prathamesh Kulkarni
> wrote:
> >
> > Hi,
> > The attached patch replaces builtins in vld1_dup intrinsics with call
> > to corresponding vdup_n intrinsic and removes entry for vld1_dup from
> > arm_neon_built
On Thu, 5 Aug 2021 at 15:44, Prathamesh Kulkarni
wrote:
>
> On Mon, 12 Jul 2021 at 15:24, Prathamesh Kulkarni
> wrote:
> >
> > On Mon, 12 Jul 2021 at 15:23, Prathamesh Kulkarni
> > wrote:
> > >
> > > On Mon, 5 Jul 2021 at 14:47, Prathamesh Kulkarni
> > > wrote:
> > > >
> > > > Hi,
> > > > This
Hello.
The patch is about a refactoring where we now repeat string message
multiple times.
I'm going to push the commit as obvious.
Martin
gcc/ChangeLog:
* opts.c (LIVE_PATCHING_OPTION): Define.
(control_options_for_live_patching): Use it in error messages.
---
gcc/opts.c | 53
> Hi.
>
> This is a first part fixing the PR. It makes sense making "naked" functions
> "noipa".
> What's missing is IPA MOD pass support where the pass should not optimize fns
> with "noipa" attributes.
>
> @Honza: Can you please implement that?
Hmm, I had patch for that somewhere, will do tha
> Hello.
>
> Right now, target_clone pass complains when a target_clone function is an
> alias.
> That happens when localalias is created by callgraph. I think we should not
> create
> such aliases as we won't benefit much from it in case of target_clones.
>
> Patch can bootstrap on x86_64-linu
Hello.
Right now, target_clone pass complains when a target_clone function is an alias.
That happens when localalias is created by callgraph. I think we should not
create
such aliases as we won't benefit much from it in case of target_clones.
Patch can bootstrap on x86_64-linux-gnu and survives
Hi.
This is a first part fixing the PR. It makes sense making "naked" functions
"noipa".
What's missing is IPA MOD pass support where the pass should not optimize fns
with "noipa" attributes.
@Honza: Can you please implement that?
Patch can bootstrap on x86_64-linux-gnu and survives regression
Jakub Jelinek via Gcc-patches writes:
> On Fri, Aug 13, 2021 at 09:42:00AM +0800, Hongtao Liu wrote:
>> > So, I wonder if your new routine shouldn't be instead done after
>> > in ix86_expand_vec_perm_const_1 after vec_perm_1 among other 2 insn cases
>> > and handle the other vpmovdw etc. cases in
On Fri, Aug 13, 2021 at 09:42:00AM +0800, Hongtao Liu wrote:
> > So, I wonder if your new routine shouldn't be instead done after
> > in ix86_expand_vec_perm_const_1 after vec_perm_1 among other 2 insn cases
> > and handle the other vpmovdw etc. cases in combine splitters (see that we
> > only use
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"))) void foo () { __builtin_printf
("arch=x86-64-v4\n"); }
|
Return content of flag_sanitize_coverage when fn is null.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
PR c++/101331
gcc/ChangeLog:
* asan.h (sanitize_coverage_p): Handle when fn == NULL.
gcc/testsuite/ChangeLog:
On Fri, Aug 13, 2021 at 2:48 AM Hongyu Wang wrote:
>
> Hi,
>
> For lea + zero_extendsidi insns, if dest of lea and src of zext are the
> same, combine them with single leal under 64bit target since 32bit
> register will be automatically zero-extended.
>
> Bootstrapped and regtested on x86_64-linux
On Thu, 12 Aug 2021 16:16:04 -0700
Ian Lance Taylor wrote:
> On Thu, Aug 12, 2021 at 3:34 PM Sergei Trofimovich via Gcc-patches
> wrote:
> >
> > From: Sergei Trofimovich
> >
> > I noticed test failures when ran gcc test suite from under mc shell.
> > mc opens fd=9 and exposes it to child proces
On Mon, 9 Aug 2021 at 21:50, Christophe Lyon
wrote:
>
>
>
> On Mon, Aug 9, 2021 at 7:07 AM Prathamesh Kulkarni
> wrote:
>>
>> On Fri, 6 Aug 2021 at 17:31, Christophe Lyon
>> wrote:
>> >
>> >
>> >
>> > On Fri, Aug 6, 2021 at 11:51 AM Prathamesh Kulkarni
>> > wrote:
>> >>
>> >> On Fri, 6 Aug 20
58 matches
Mail list logo
