On 2021/12/14 17:27, Xionghu Luo via Gcc-patches wrote:
>
>
> On 2021/12/13 17:25, Jan Hubicka wrote:
>>> r12-4526 cancelled jump thread path rotates loop. It exposes a issue in
>>> profile-estimate when predict_extra_loop_exits, outer loop's exit edge
>>> is marked as inner loop's extra loop
On Tue, Dec 14, 2021 at 07:32:30AM -0600, Bill Schmidt wrote:
> On 12/13/21 6:22 PM, Segher Boessenkool wrote:
> > On Mon, Dec 13, 2021 at 02:37:43PM -0600, Bill Schmidt wrote:
> >> On 12/13/21 10:54 AM, Segher Boessenkool wrote:
> >>> On Mon, Dec 13, 2021 at 11:30:28AM -0500, David Edelsohn wrote:
Hi!
On Fri, Dec 03, 2021 at 07:42:52PM -, Roger Sayle wrote:
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/addcmp.c
> @@ -0,0 +1,12 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2" } */
> +
> +unsigned long add_leu(unsigned long a, unsigned long b, unsigned long c) {
> + retu
Also add verbose argument support like analyze_brprob.py
contrib/ChangeLog:
* analyze_brprob_spec.py: Add verbose argument.
---
contrib/analyze_brprob_spec.py | 1 +
1 file changed, 1 insertion(+)
diff --git a/contrib/analyze_brprob_spec.py b/contrib/analyze_brprob_spec.py
index e621853
Hi all,
This patch fix the regression previously reported on the combine splitter under
'-m32 -march=cascadelake' options.
Regtested on x86_64-pc-linux-gnu.
BRs,
Haochen
gcc/ChangeLog:
PR target/100738
* config/i386/sse.md (*avx_cmp3_lt, *avx_cmp3_ltint):
Remove MEM_P
On Tue, Dec 14, 2021 at 3:30 PM Jeff Law wrote:
>
>
>
> On 11/22/2021 7:29 PM, H.J. Lu wrote:
> > On Mon, Nov 22, 2021 at 4:29 PM Jeff Law wrote:
> >>
> >>
> >> On 11/13/2021 9:33 AM, H.J. Lu via Gcc-patches wrote:
> >>> Sync with binutils for building binutils with LTO:
> >>>
> >>> From 50ad12
On 12/14/2021 2:43 AM, Tamar Christina wrote:
Hi All,
This and the report in PR103632 are caused by a bug in REE where it generates
incorrect code.
It's trying to eliminate the following zero extension
(insn 54 90 102 2 (set (reg:V4SI 33 v1)
(zero_extend:V4SI (reg/v:V4HI 40 v8)))
On 10/27/2021 2:05 PM, Richard Purdie via Gcc-patches wrote:
OpenEmbedded/Yocto Project extensively uses the --sysroot support within gcc.
We discovered that when compiling preprocessed source (.i or .ii files), the
compiler will try and access the builtin sysroot location rather than the
--sy
Tested x86_64-linux (glibc 2.33) and powerpc64le-linux (glibc 2.17).
Pushed to trunk.
This checks whether the locale data for en_HK includes %p and adjusts
the string being tested accordingly. To account for Jakub's fix to make
%I parse "12" as 0 instead of 12, we need to change the expected valu
On 12/14/2021 3:27 PM, Jakub Jelinek wrote:
On Tue, Dec 14, 2021 at 03:05:37PM -0700, Jeff Law wrote:
2021-12-14 Jakub Jelinek
PR debug/103619
* dwarf2cfi.c (dwf_cfa_reg): Remove gcc_assert.
(operator==, operator!=): New overloaded operators.
(dwarf2out_fra
On 12/13/2021 5:27 PM, Joseph Myers wrote:
This is missing an invoke.texi update for the new option.
And that update should probably note that -Oz turns on O2. OK with that
change.
jeff
On 11/22/2021 7:29 PM, H.J. Lu wrote:
On Mon, Nov 22, 2021 at 4:29 PM Jeff Law wrote:
On 11/13/2021 9:33 AM, H.J. Lu via Gcc-patches wrote:
Sync with binutils for building binutils with LTO:
From 50ad1254d5030d0804cbf89c758359ae202e8d55 Mon Sep 17 00:00:00 2001
From: "H.J. Lu"
Date: S
On 12/2/2021 11:24 PM, Sören Tempel wrote:
Hi,
Jeff Law wrote:
So what doesn't make sense here is how both stddef.h files get
included. That's the core problem I think you need to resolve.
The libgo/sysinfo.c file includes stddef.h (for which the GCC version in
ginclude is used on my syst
On 12/10/2021 3:42 PM, Thomas Schwinge wrote:
Hi!
OK to push the attached "testsuite: Be more informative for ICEs"?
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsfüh
The attached patch avoids an ICE when using
the CLASSTYPE_IMPLICIT_INSTANTIATION() macro with an argument
that is not a class type but rather a typename_type.
The test case should trigger a warning but doesn't because
the code doesn't fully handle explicit instantiations.
Martin
Check for class
On Tue, Dec 14, 2021 at 03:05:37PM -0700, Jeff Law wrote:
> > 2021-12-14 Jakub Jelinek
> >
> > PR debug/103619
> > * dwarf2cfi.c (dwf_cfa_reg): Remove gcc_assert.
> > (operator==, operator!=): New overloaded operators.
> > (dwarf2out_frame_debug_adjust_cfa, dwarf2out_frame_debug
Here during constraint checking for the recursive call to 'f',
substitution into the PARM_DECL 'd' in the atomic constraint gives us
the wrong local specialization because local_specializations at this
point contains entities associated with the _outer_ call to 'f'.
This patch fixes this by callin
On 12/14/21 9:43 AM, Qing Zhao wrote:
Hi,
On Dec 9, 2021, at 12:13 PM, Qing Zhao via Gcc-patches
wrote:
+ return;
+
+ /* Get the variable declaration location from the def_stmt. */
+ var_decl_loc = gimple_location (def_stmt);
+
+ /* The LHS of the call
On 12/14/2021 1:18 PM, Jakub Jelinek wrote:
On Tue, Dec 14, 2021 at 10:32:21AM -0700, Jeff Law wrote:
I think the attached testcase should trigger on c6x with -mbig-endian -O2 -g
Thanks. Finally I see what's going on. c6x doesn't really need the CFA
with span > 1 (and I bet neither does ar
On Linux/x86_64,
3305135c29e1c3e988bd9bad40aefc01d138aaca is the first bad commit
commit 3305135c29e1c3e988bd9bad40aefc01d138aaca
Author: Jan Hubicka
Date: Tue Dec 14 16:50:27 2021 +0100
Determine global memory accesses in ipa-modref
caused
FAIL: gfortran.dg/unlimited_polymorphic_3.f03
On 12/10/2021 4:23 PM, Iain Sandoe via Gcc-patches wrote:
While doing tests of the PCH changes, I noticed that all the
plugin tests were being omitted from m32 Darwin under some
permutations of flags. It turned out to be a broken config
test - it was not removing -mdynamic-no-pic properly.
W
On 12/10/2021 10:18 PM, Alexandre Oliva wrote:
On Dec 10, 2021, Jeff Law wrote:
The patch is clearly safe. My question is should we have caught this
earlier in the call chain?
Callers will call try_store_by_multiple_pieces if set_storage_via_setmem
fails. setmem doesn't necessarily need
On 12/13/2021 6:40 PM, Jojo R wrote:
Hi,
Thank you for your review & help.
I could not fetch the merged patch from gcc master of git.
Is there any problem for this ?
I assumed you'd commit the change. I thought you had commit
privileges. I'll go ahead and push it momentarily.
Thanks f
Tested powerpc64le-linux, pushed to trunk.
std::regex currently allows invalid bracket ranges such as [\w-a] which
are only allowed by ECMAScript when in web browser compatibility mode.
It should be an error, because the start of the range is a character
class, not a single character. The current
Tested powerpc64le-linux, pushed to trunk.
libstdc++-v3/ChangeLog:
* include/ext/pointer.h (_Relative_pointer_impl::_UIntPtrType):
Rename to uintptr_t and define as __UINTPTR_TYPE__.
---
libstdc++-v3/include/ext/pointer.h | 50 --
1 file changed, 19 i
Tested powerpc64le-linux, pushed to trunk.
This removes the __syntax_option and __match_flag enumeration types,
which are only used to define enumerators with successive values that
are then used to initialize the std::regex_constants global variables.
By defining enumerators in the syntax_optio
On Tue, Dec 14, 2021 at 1:33 PM Eric Gallager wrote:
>
> On Mon, Dec 13, 2021 at 1:17 PM Martin Sebor via Gcc-patches
> wrote:
> >
> > On 12/12/21 3:13 AM, Andrea Monaco via Gcc-patches wrote:
> > >
> > > Hello.
> > >
> > >
> > > I propose to make that message more verbose. It sure would have he
Dear all,
the attached patch fixes an obvious NULL pointer dereference.
Committed as obvious after regtesting on x86_64-pc-linux-gnu.
Will "backport" to 11-branch after waiting a few days unless
someone protests.
Thanks,
Harald
From ca39102e10643a6b3f07d06934cc0907ba83d9ee Mon Sep 17 00:00:00 2
On Tue, Dec 14, 2021 at 10:32:21AM -0700, Jeff Law wrote:
> I think the attached testcase should trigger on c6x with -mbig-endian -O2 -g
Thanks. Finally I see what's going on. c6x doesn't really need the CFA
with span > 1 (and I bet neither does armbe), the only reason why
dwf_cfa_reg is called
Hi Harald,
there are several pretty obvious NULL pointer dereferences on
valid and invalid code when checking do-loop contained stuff.
Reported by Gerhard.
Regtested on x86_64-pc-linux-gnu. OK for mainline/11-branch?
OK for both. Thanks for cleaning this up!
Regards
Thomas
Dear all,
there are several pretty obvious NULL pointer dereferences on
valid and invalid code when checking do-loop contained stuff.
Reported by Gerhard.
Regtested on x86_64-pc-linux-gnu. OK for mainline/11-branch?
Thanks,
Harald
From 89bf4b17022890b539cd4b5dbe9bd9142ff8706c Mon Sep 17 00:00:
On 12/14/2021 12:51 PM, Andrew MacLeod via Gcc-patches wrote:
On 12/3/21 11:46, Richard Biener wrote:
On December 3, 2021 3:15:25 PM GMT+01:00, Andrew MacLeod
wrote:
When something like the loop unswitching code adds elements to the
CFGs,
does this invalidate the dominators? or are they up
On 12/3/21 11:46, Richard Biener wrote:
On December 3, 2021 3:15:25 PM GMT+01:00, Andrew MacLeod
wrote:
When something like the loop unswitching code adds elements to the CFGs,
does this invalidate the dominators? or are they updated? or is it in
an in between state.
Im curious because a) th
On 12/13/2021 10:17 PM, liuhongt via Gcc-patches wrote:
This testcase should just go in gcc.c-torture/compile and remove the
dg-options too.
The main reason there is nothing specific to x86 here.
Thanks, here's the updated patch.
Check is_gimple_assign before gimple_assign_rhs_code.
gcc/C
On Mon, Dec 13, 2021 at 1:17 PM Martin Sebor via Gcc-patches
wrote:
>
> On 12/12/21 3:13 AM, Andrea Monaco via Gcc-patches wrote:
> >
> > Hello.
> >
> >
> > I propose to make that message more verbose. It sure would have helped
> > me once. You don't always have a Web search available :)
>
> War
On Mon, Dec 6, 2021 at 3:49 PM Bill Schmidt wrote:
>
> Hi!
>
> While we had two sets of built-in infrastructure at once, I added _x as a
> suffix to two arrays to disambiguate the old and new versions. Time to fix
> that also.
>
> Bootstrapped and tested on powerpc64le-linux-gnu with no regressio
On Mon, Dec 6, 2021 at 3:49 PM Bill Schmidt wrote:
>
> Hi!
>
> While we had two sets of built-in functionality at the same time, I put "new"
> in the names of quite a few functions. Time to undo that.
>
> Bootstrapped and tested on powerpc64le-linux-gnu with no regressions. Is this
> okay for tr
On Mon, Dec 6, 2021 at 3:49 PM Bill Schmidt wrote:
>
> Hi!
>
> The old rs6000-builtin.def file is no longer needed. Remove it and the code
> that depends on it.
>
> Bootstrapped and tested on powerpc64le-linux-gnu with no regressions. Is this
> okay for trunk?
>
> Thanks!
> Bill
>
> 2021-12-02
On Mon, Dec 6, 2021 at 3:49 PM Bill Schmidt wrote:
>
> Hi!
>
> This patch just renames a file and updates the build machinery accordingly.
>
> Bootstrapped and tested on powerpc64le-linux-gnu with no regressions. Is this
> okay for trunk?
>
> Thanks!
> Bill
>
> 2021-12-02 Bill Schmidt
>
> gcc/
On Mon, Dec 6, 2021 at 3:49 PM Bill Schmidt wrote:
>
> Hi!
>
> This patch just removes the huge altivec_overloaded_builtins array.
>
> Bootstrapped and tested on powerpc64le-linux-gnu with no regressions. Is this
> okay for trunk?
>
> Thanks!
> Bill
>
> 2021-12-02 Bill Schmidt
>
> gcc/
>
On 12/13/21 10:41 PM, Jason Merrill wrote:
On 12/13/21 14:22, Martin Sebor wrote:
On 12/11/21 10:39 PM, Jason Merrill via Gcc-patches wrote:
In reading C++ diagnostics, it's often hard to find the name of the
function
in the middle of the template header, return type, parameters, and
template
Ping. Thanks!
Bill
On 12/6/21 2:49 PM, Bill Schmidt via Gcc-patches wrote:
> Hi!
>
> While we had two sets of built-in infrastructure at once, I added _x as a
> suffix to two arrays to disambiguate the old and new versions. Time to fix
> that also.
>
> Bootstrapped and tested on powerpc64le-lin
Ping. Thanks!
Bill
On 12/6/21 2:49 PM, Bill Schmidt via Gcc-patches wrote:
> Hi!
>
> While we had two sets of built-in functionality at the same time, I put "new"
> in the names of quite a few functions. Time to undo that.
>
> Bootstrapped and tested on powerpc64le-linux-gnu with no regressions
Ping. Thanks!
Bill
On 12/6/21 2:49 PM, Bill Schmidt via Gcc-patches wrote:
> Hi!
>
> The old rs6000-builtin.def file is no longer needed. Remove it and the code
> that depends on it.
>
> Bootstrapped and tested on powerpc64le-linux-gnu with no regressions. Is this
> okay for trunk?
>
> Thanks!
Ping. Thanks!
Bill
On 12/6/21 2:49 PM, Bill Schmidt via Gcc-patches wrote:
> Hi!
>
> This patch just renames a file and updates the build machinery accordingly.
>
> Bootstrapped and tested on powerpc64le-linux-gnu with no regressions. Is this
> okay for trunk?
>
> Thanks!
> Bill
>
> 2021-12-02
This is a preparation patch that moves VxHF vector set/insert/extract
expansions from AVX512FP16 ABI to lower ABIs. There are no functional
changes for -mavx512fp16 and a follow-up patch is needed to actually
enable VxHF vector modes for lower ABIs.
2021-12-14 Uroš Bizjak
gcc/ChangeLog:
On 12/14/2021 9:53 AM, Jakub Jelinek via Gcc-patches wrote:
On Thu, Dec 09, 2021 at 05:32:02PM +, Hafiz Abid Qadeer wrote:
Commit 13b6c7639cf assumed that registers in a span will be in a certain
order. But that assumption is not true at least for the big endian targets.
Currently amdgcn i
Hi! I'd like to ping patches 2 through 6 of this series. Much obliged!
Thanks,
Bill
On 12/6/21 2:49 PM, Bill Schmidt via Gcc-patches wrote:
> Hi!
>
> Now that the new built-in function support is all upstream and enabled, it
> seems safe and prudent to remove the old code to avoid confusion.
On Fri, Nov 5, 2021 at 3:38 PM will schmidt wrote:
>
> On Fri, 2021-11-05 at 00:11 -0400, Michael Meissner wrote:
> > Generate XXSPLTIDP for scalars on power10.
> >
> > This patch implements XXSPLTIDP support for SF, and DF scalar constants.
> > The previous patch added support for vector constant
On Fri, Nov 5, 2021 at 3:24 PM will schmidt wrote:
>
> On Fri, 2021-11-05 at 00:10 -0400, Michael Meissner wrote:
> > Generate XXSPLTIDP for vectors on power10.
> >
> > This patch implements XXSPLTIDP support for all vector constants. The
> > XXSPLTIDP instruction is given a 32-bit immediate that
On Fri, Nov 5, 2021 at 2:50 PM will schmidt wrote:
>
> On Fri, 2021-11-05 at 00:09 -0400, Michael Meissner wrote:
> > Generate XXSPLTIW on power10.
> >
>
> Hi,
>
>
> > This patch adds support to automatically generate the ISA 3.1 XXSPLTIW
> > instruction for V8HImode, V4SImode, and V4SFmode vector
On Fri, Nov 5, 2021 at 2:13 PM Michael Meissner wrote:
>
> On Fri, Nov 05, 2021 at 12:01:43PM -0500, will schmidt wrote:
> > On Fri, 2021-11-05 at 00:04 -0400, Michael Meissner wrote:
> > > Add new constant data structure.
> > >
> > > This patch provides the data structure and function to convert
On Fri, Nov 5, 2021 at 2:01 PM Michael Meissner wrote:
>
> On Fri, Nov 05, 2021 at 12:52:51PM -0500, will schmidt wrote:
> > > diff --git a/gcc/config/rs6000/predicates.md
> > > b/gcc/config/rs6000/predicates.md
> > > index 956e42bc514..e0d1c718e9f 100644
> > > --- a/gcc/config/rs6000/predicates.
On Thu, Dec 09, 2021 at 05:32:02PM +, Hafiz Abid Qadeer wrote:
> Commit 13b6c7639cf assumed that registers in a span will be in a certain
> order. But that assumption is not true at least for the big endian targets.
> Currently amdgcn is probably only target where CFA is split into multiple
> r
Hi,
> On Dec 9, 2021, at 12:13 PM, Qing Zhao via Gcc-patches
> wrote:
>>
>>> + return;
>>> +
>>> + /* Get the variable declaration location from the def_stmt. */
>>> + var_decl_loc = gimple_location (def_stmt);
>>> +
>>> + /* The LHS of the call is a temporary variable, we
Hi, Roger!
Thanks very much for investigating this issue and developing a patch
to leverage this feature of the PowerPC architecture.
2021-12-03 Roger Sayle
gcc/ChangeLog
PR target/43892
* config/rs6000/rs6000.md (*add3_carry_in_0_2): New
define_insn to recognize commu
On Tue, Dec 14, 2021 at 04:07:55PM +0100, Martin Liška wrote:
> On 12/14/21 11:28, Jakub Jelinek wrote:
> > Wouldn't this be better done only if field_val has the msb set
>
> Yes, updated in the attached patch.
>
> > and keep the CONVERT_EXPR otherwise (why isn't it NOP_EXPR?)?
>
> Dunno, but I
The patch fixes various tests in i386.exp that fail with:
make check -k RUNTESTFLAGS="i386.exp --target_board=unix/-fsanitize=address"
Survives i386.exp w/o sanitizer.
Ready for master?
Thanks,
Martin
gcc/testsuite/ChangeLog:
* gcc.target/i386/avx2-i32gatherpd256-4.c: Fix ASAN errors.
On 12/14/21 7:32 AM, Bill Schmidt wrote:
> Hi!
>
> On 12/13/21 6:22 PM, Segher Boessenkool wrote:
>>
>> These builtins should just return a "long", just like __builtin_ppc_mftb
>> does. All three of them.
> Well, that seems wrong for __builtin_darn_32, which maps to an SImode pattern.
>
> So, I as
On 12/14/21 11:28, Jakub Jelinek wrote:
Wouldn't this be better done only if field_val has the msb set
Yes, updated in the attached patch.
and keep the CONVERT_EXPR otherwise (why isn't it NOP_EXPR?)?
Dunno, but I can prepare a separate patch (likely stage1 material,
right)? Note that are o
This is one more patch for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99531
The following patch fixes the test failure on ia32.
commit 4ddeae2b2777aa5136fc2bb21c15b0fcccdafece
Author: Vladimir N. Makarov
Date: Tue Dec 14 08:57:30 2021 -0500
[PR99531] Do not scan push insn for ia32 in
Changelog:
* MAINTAINERS: Add myself to write after approval.
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index b74db64c1a2..8afbda71888 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -574,6 +574,7 @@ Nicolas Pitre
> -Original Message-
> From: Richard Sandiford
> Sent: 14 December 2021 11:58
> To: Przemyslaw Wirkus
> Cc: gcc-patches@gcc.gnu.org; Richard Earnshaw
> ; Marcus Shawcroft
> ; Kyrylo Tkachov
> Subject: Re: [PATCH][GCC] aarch64: Add LS64 extension and intrinsics
>
> Przemyslaw Wirkus wri
The tests failed on my machine as they contain out-of-bounds
access.
I'm going to push the fix.
Martin
gcc/testsuite/ChangeLog:
* gcc.target/i386/avx2-psraq-1.c: Use ARRAY_SIZE.
* gcc.target/i386/m128-check.h: Move it to the top-level
context.
* gcc.target/i386/
Tested powerpc64le-linux, committed to trunk.
libstdc++-v3/ChangeLog:
* include/bits/regex_compiler.tcc (_Compiler::_M_match_token):
Use reserved name for parameter.
* testsuite/17_intro/names.cc: Check "token".
---
libstdc++-v3/include/bits/regex_compiler.tcc | 4 ++--
On Tue, 14 Dec 2021 at 13:50, Jakub Jelinek via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
> Hi!
>
> This patch uses the same not completely correct case insensitive
> comparisons
> as used elsewhere in the same header. Proper comparisons that would handle
> even multi-byte characters would be har
Hi!
This patch uses the same not completely correct case insensitive comparisons
as used elsewhere in the same header. Proper comparisons that would handle
even multi-byte characters would be harder, but I don't see them implemented
in __ctype's methods.
Tested on x86_64-linux, ok for trunk?
20
Hi!
On 12/13/21 6:22 PM, Segher Boessenkool wrote:
> On Mon, Dec 13, 2021 at 02:37:43PM -0600, Bill Schmidt wrote:
>> On 12/13/21 10:54 AM, Segher Boessenkool wrote:
>>> On Mon, Dec 13, 2021 at 11:30:28AM -0500, David Edelsohn wrote:
On Mon, Dec 13, 2021 at 10:48 AM Bill Schmidt
wrote:
Tamar Christina writes:
>> -Original Message-
>> From: Richard Sandiford
>> Sent: Tuesday, December 14, 2021 12:38 PM
>> To: Tamar Christina
>> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
>> ; Marcus Shawcroft
>> ; Kyrylo Tkachov
>> Subject: Re: [PATCH]AArch64 Fix the AAPCs for n
On Tue, 14 Dec 2021 at 06:53, François Dumont wrote:
> Hi
>
> Any conclusion regarding this thread ?
>
> François
>
>
> On 06/10/21 7:25 pm, François Dumont wrote:
> > I forgot to ask if with this patch this overload:
> >
> > template
> > constexpr auto
> > __to_address(const _Ptr&
> -Original Message-
> From: Richard Sandiford
> Sent: Tuesday, December 14, 2021 12:38 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
> ; Marcus Shawcroft
> ; Kyrylo Tkachov
> Subject: Re: [PATCH]AArch64 Fix the AAPCs for new partial and full SIMD
> stru
The addition of fPIC for shared libraries is performed
independently from multilibs and fpic multilibs have
no other particular purpose for VxWorks at this stage.
Tested together with our recent cleanups in the shared-objects
support area, for a mix of builds/tests for vxworks 6.9 and 7.2
with our
Tamar Christina writes:
> Hi All,
>
> The new partial and full vector types added to AArch64, e.g.
>
> int8x8x2_t with mode V2x8QI are incorrectly being defined as being short
> vectors and not being composite types.
>
> This causes the layout code to incorrectly conclude that the registers are
>
The addition of fPIC for shared libraries is performed
independently from multilibs and fpic multilibs have
no other particular purpose for VxWorks at this stage.
They incur extra build time, complexify the install tree
and are a bit tricky because -fpic is not supported for kernel
mode.
Tested t
Przemyslaw Wirkus writes:
> Hello Richard,
>
> I've updated my patch following all your comments. Thank you.
>
> Boostrapped on aarch64-linux-gnu and all new ACLE tests pass.
>
> OK to install?
Thanks. OK with a couple of formatting nits:
> @@ -2130,6 +2203,57 @@ aarch64_expand_builtin_tme (int
Le 13/12/2021 à 21:27, Harald Anlauf via Fortran a écrit :
Works better with patch attached...
Am 13.12.21 um 21:25 schrieb Harald Anlauf via Gcc-patches:
The code is so similar (for good reason) that it makes sense to keep
it synchronous. I added code for 'zero_sized' array with the minor
di
Robin Dapp writes:
> Hi Richard,
>
> I incorporated all your remarks (sorry for the hunk from a different
> branch) except for this one:
>
>> Think it would be better to make it:
>>
>>if (use_bias_adjusted_len)
>> {
>>gcc_assert (i == 0);
>>
>> But do we need to do t
"Andre Vieira (lists)" writes:
> Hi,
>
> Added an extra step to skip unusable epilogue modes when we know the
> target does not support predication. This uses a new function
> 'support_predication_p' that is generated at build time and checks
> whether the target supports at least one optab tha
On 13.12.2021 18:20, Alexander Monakov wrote:
On Mon, 13 Dec 2021, Richard Biener wrote:
On December 13, 2021 3:25:47 PM GMT+01:00, Alexander Monakov
wrote:
Greetings!
While testing our patch that reimplements -Wclobbered on GIMPLE we found
a case where tree-ssa-sink moves a statement to a
On Tue, Dec 14, 2021 at 10:46:39AM +, Joel Hutton wrote:
> > + if (ot_plus == unknown_optab
> > + || ot_minus == unknown_optab
> > + || optab_handler (ot_minus, TYPE_MODE (step_vectype)) ==
> > CODE_FOR_nothing
> > + || optab_handler (ot_plus, TYPE_MODE (step_vectype)) ==
> > +
Kyrylo Tkachov via Gcc-patches writes:
> @@ -23568,6 +23568,28 @@ aarch64_copy_one_block_and_progress_pointers (rtx
> *src, rtx *dst,
>*dst = aarch64_progress_pointer (*dst);
> }
>
> +/* Expand a cpymem using the MOPS extension. OPERANDS are taken
> + from the cpymem pattern. Return tr
> + if (ot_plus == unknown_optab
> + || ot_minus == unknown_optab
> + || optab_handler (ot_minus, TYPE_MODE (step_vectype)) ==
> CODE_FOR_nothing
> + || optab_handler (ot_plus, TYPE_MODE (step_vectype)) ==
> + CODE_FOR_nothing)
> return false;
>
> Won't optab_handler just retu
"Roger Sayle" writes:
> A common idiom is to create a DImode value from the "concat" of two SImode
> values, using "(long long)hi << 32 | (long long)lo", where the operation
> may be ior, xor or plus. On x86, with -m32, the high and low parts of
> a DImode register are actually different SImode r
On Tue, Dec 14, 2021 at 10:55:01AM +0100, Martin Liška wrote:
> The patch fixes __builtin_cpu_supports("avx512vbmi2") which returns a negative
> value (that's not allowed in the documentation).
>
> I also checked ppc target that does the same, and __builtin_cpu_is, which
> are fine.
>
> Patch can
Hi,
I'd just like to ping this for review:
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/585785.html
Thanks,
Alex
On 30/11/2021 16:48, Alex Coplan via Gcc-patches wrote:
> Hi,
>
> This fixes PR103500 i.e. ensuring that stack slots for
> passed-by-reference overaligned types are appro
The patch fixes __builtin_cpu_supports("avx512vbmi2") which returns a negative
value (that's not allowed in the documentation).
I also checked ppc target that does the same, and __builtin_cpu_is, which
are fine.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be
On Tue, Dec 14, 2021 at 09:37:03AM +, Joel Hutton via Gcc-patches wrote:
> Bootstrapped and regression tested on releases/gcc-11 on aarch64.
>
> Ok for 11?
>
> Previous commit broke build as it relied on directly_supported_p which
> is not in 11. This reworks to avoid using directly_supported
Hi All,
This and the report in PR103632 are caused by a bug in REE where it generates
incorrect code.
It's trying to eliminate the following zero extension
(insn 54 90 102 2 (set (reg:V4SI 33 v1)
(zero_extend:V4SI (reg/v:V4HI 40 v8)))
(nil))
by folding it in the definition of `v8`:
Hi All,
The new partial and full vector types added to AArch64, e.g.
int8x8x2_t with mode V2x8QI are incorrectly being defined as being short
vectors and not being composite types.
This causes the layout code to incorrectly conclude that the registers are
packed. i.e. for V2x8QI it thinks those
Bootstrapped and regression tested on releases/gcc-11 on aarch64.
Ok for 11?
Previous commit broke build as it relied on directly_supported_p which
is not in 11. This reworks to avoid using directly_supported_p.
gcc/ChangeLog:
PR bootstrap/103688
* tree-vect-loop.c (
On 2021/12/13 17:25, Jan Hubicka wrote:
>> r12-4526 cancelled jump thread path rotates loop. It exposes a issue in
>> profile-estimate when predict_extra_loop_exits, outer loop's exit edge
>> is marked as inner loop's extra loop exit and set with incorrect
>> prediction, then a hot inner loop wi
On 2021/12/13 18:24, Jan Hubicka wrote:
>>> gcc/ChangeLog:
>>>
>>> * loop-invariant.c (find_invariants_bb): Check profile count
>>> before motion.
>>> (find_invariants_body): Add argument.
>>> ---
>>> gcc/loop-invariant.c | 10 +++---
>>> 1 file changed, 7 insertions(+), 3 delet
On Tue, 7 Dec 2021 at 19:08, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> > On Thu, 2 Dec 2021 at 23:11, Richard Sandiford
> > wrote:
> >>
> >> Prathamesh Kulkarni writes:
> >> > Hi Richard,
> >> > I have attached a WIP untested patch for PR96463.
> >> > IIUC, the PR suggests to t
93 matches
Mail list logo
