On Wed, 30 Sep 2020, Tom de Vries wrote:
> [ was: Re: [committed][testsuite] Require non_strict_align in
> pr94600-{1,3}.c ]
>
> On 9/30/20 4:53 AM, Hans-Peter Nilsson wrote:
> > On Thu, 24 Sep 2020, Tom de Vries wrote:
> >
> >> Hi,
> >>
> >> With the nvptx target, we run into:
> >> ...
> >>
On 9/25/20 1:41 PM, Andrew MacLeod via Gcc-patches wrote:
On 9/23/20 7:53 PM, Martin Sebor via Gcc-patches wrote:
On 9/18/20 12:38 PM, Aldy Hernandez via Gcc-patches wrote:
As part of the ranger work, we have been trying to clean up and
generalize interfaces whenever possible. This not only
This libgo patch by Maciej W. Rozycki adds 32-bit RISC-V support.
Bootstrapped and ran Go tests on x86_64-pc-linux-gnu. Committed to
mainline.
Ian
a119b20263517656379c4833a3341031a6d58dc4
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofrontend/MERGE
index 314ffd2efab..8d9fda54619 100644
---
Hi Alan,
On Thu, Oct 01, 2020 at 08:49:44AM +0930, Alan Modra wrote:
> On Wed, Sep 30, 2020 at 05:36:08PM -0500, Segher Boessenkool wrote:
> > On Wed, Sep 30, 2020 at 05:06:57PM +0930, Alan Modra wrote:
> > > Generate assembly that is .localentry 1 with @notoc calls to match.
> >
> > What is the
-Wstring-compare triggers under the same strict conditions as
the strcmp/strncmp call is folded into a constant: only when
all the uses of the result are [in]equality expressions with
zero. However, even when the call cannot be folded into
a constant because the result is in addition used in
On Wed, Sep 30, 2020 at 05:36:08PM -0500, Segher Boessenkool wrote:
> On Wed, Sep 30, 2020 at 05:06:57PM +0930, Alan Modra wrote:
> > Generate assembly that is .localentry 1 with @notoc calls to match.
>
> What is the purpose of this? Non-obvious patchexs without any
> explanation like that cost
On Wed, Sep 30, 2020 at 05:06:57PM +0930, Alan Modra wrote:
> Generate assembly that is .localentry 1 with @notoc calls to match.
What is the purpose of this? Non-obvious patchexs without any
explanation like that cost needless extra time to review :-/
"Support __PCREL__ code." suggests that it
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552903.html
(I lost track of this patch.)
On 9/9/20 3:42 PM, Martin Sebor wrote:
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552903.html
On 8/28/20 11:12 AM, Martin Sebor wrote:
The gimple_call_alloc_size() function
On 9/19/20 5:33 PM, Marek Polacek wrote:
This PR points out that we accept
template struct tuple { tuple(T); }; // #1
template explicit tuple(T t) -> tuple; // #2
tuple t = { 1 };
despite the 'explicit' deduction guide in a copy-list-initialization
context. That's because in
On 9/29/20 5:01 PM, Patrick Palka wrote:
This patch fixes an "unguarded" call to coerce_template_parms in
build_standard_check: processing_template_decl could be zero if we
we get here during processing of the first 'auto' parameter of an
abbreviated function template. In the testcase below,
Hi!
On Wed, Sep 30, 2020 at 05:01:45PM +0930, Alan Modra wrote:
> * config/rs6000/linux64.h (SUBSUBTARGET_OVERRIDE_OPTIONS): Don't
> set -mcmodel=small for -mno-minimal-toc when pcrel.
> - SET_CMODEL (CMODEL_SMALL);\
> + if
On 30/09/20 16:03 +0100, Jonathan Wakely wrote:
On 29/09/20 13:51 +0200, Christophe Lyon via Libstdc++ wrote:
On Sat, 26 Sep 2020 at 21:42, Jonathan Wakely via Gcc-patches
wrote:
Glibc 2.32 adds a global variable that says whether the process is
single-threaded. We can use this to decide
On 9/30/20 3:57 AM, Jakub Jelinek wrote:
On Fri, Sep 25, 2020 at 04:30:26PM -0400, Jason Merrill via Gcc-patches wrote:
On 9/15/20 3:57 AM, Jakub Jelinek wrote:
The following testcase is miscompiled (in particular the a and i
initialization). The problem is that build_special_member_call due
On 9/30/20 4:01 AM, Jakub Jelinek wrote:
Hi!
As mentioned in the PR, we only support due to a bug in constant expressions
std::construct_at on non-automatic variables, because we VERIFY_CONSTANT the
second argument of placement new, which fails verification if it is an
address of an automatic
On Wed, Sep 30, 2020 at 09:02:34AM +0200, Richard Biener wrote:
> On Tue, 29 Sep 2020, Segher Boessenkool wrote:
> > I don't see much about optabs in the docs either. Add some text to
> > optabs.def itself then?
>
> All optabs are documented in doc/md.texi as 'instruction patterns'
Except for
Thanks for the patch and sorry for the slow reply.
Must admit that I hadn't realised that we'd quite that many
autodetect_types, sorry. Obviously the operand numbering is a lot
less regular in arm than in aarch64. :-) The approach still seems
reasonable to me though, and the patch generally
On 21/09/20 15:40 +0100, Jonathan Wakely wrote:
On 15/09/20 20:35 -0700, Thomas Rodgers wrote:
From: Thomas Rodgers
From llvm-project/pstl @ 0b2e0e80d96
libstdc++-v3/ChangeLog:
* include/pstl/algorithm_impl.h: Update file.
* include/pstl/execution_impl.h: Likewise.
*
Redeclaring a function that takes a VLA parameter with attribute
access that references the same parameter can cause conflicts
when the two aren't in sync. The conflicts are detected and
diagnosed but also have to be resolved. The code wasn't robust
enough to handle all cases gracefully,
On 9/30/20 3:57 AM, Jakub Jelinek wrote:
On Tue, Sep 29, 2020 at 03:40:40PM -0600, Martin Sebor via Gcc-patches wrote:
I will commit this patch later this week unless I hear concerns
or suggestions for changes.
That is not how the patch review process works.
The review process hasn't been
> On Sep 30, 2020, at 11:25 AM, Richard Sandiford
> wrote:
>
> Qing Zhao writes:
As I checked, when the FP registers are zeroed, the above failure happened.
I suspect that the issue still relate to the following statement:
machine_mode mode =
Hi Honza, Tobias,
Yes, I am willing to help and will do so as soon as my small vacation ends
on Monday.
Regards,
Andre
Andre Vehreschild * ve...@gmx.de
Am 30. September 2020 19:12:48 schrieb Tobias Burnus :
Hi Honza,
On 9/30/20 6:12 PM, Jan Hubicka wrote:
_gfortran_caf_co_sum
> > Subject: [PATCH][GCC][ARM] Add support for Cortex-A78 and Cortex-A78AE
> >
> > This patch introduces support for Cortex-A78 [0] and Cortex-A78AE [1]
> > cpus.
> >
> > [0]: https://www.arm.com/products/silicon-ip-cpu/cortex-a/cortex-
> > a78
> > [1]:
> > Subject: [PATCH][GCC][AArch64] Add support for Cortex-A78 and Cortex-
> > A78AE
> >
> > This patch introduces support for Cortex-A78 [0] and Cortex-A78AE [1]
> > cpus.
> >
> > [0]: https://www.arm.com/products/silicon-ip-cpu/cortex-a/cortex-a78
> > [1]:
> >
PR 92271 added __is_same as another spelling of __is_same_as. Since
Clang also spells it __is_same, let's just use that consistently.
It appears that Intel icc sets __GNUC__ to 10, but only supports
__is_same_as. If we only use __is_same for __GNUC__ >= 11 then we won't
break icc again (it looks
This rewrites ranges::construct_at in terms of std::construct_at so
that we can piggy back on the compiler's existing support for
recognizing placement new within std::construct_at during constexpr
evaluation instead of having to additionally teach the compiler about
ranges::construct_at.
While
Hi Honza,
On 9/30/20 6:12 PM, Jan Hubicka wrote:
_gfortran_caf_co_sum (gfc_descriptor_t *a __attribute__ ((unused)),
Should have fnspec
".XXWXX"
First dot represents return value, then X is for unused parameters
'X' is definitely wrong. In GCC there is only a stub implementation for
Hi,
On Wed, Sep 30 2020, Richard Biener wrote:
> On Tue, Sep 29, 2020 at 9:31 PM Jan Hubicka wrote:
>>
>> >
>> > gcc/ChangeLog:
>> >
>> > 2020-09-07 Martin Jambor
>> >
>> > * params.opt (ipa-cp-large-unit-insns): New parameter.
>> > * ipa-cp.c (get_max_overall_size): Use the new
On Wed, Sep 30, 2020 at 06:06:31PM +0200, Florian Weimer wrote:
> This is what I came up with. It is not valid to set ix86_arch to
> PROCESSOR_GENERIC, which is why PTA_NO_TUNE is still needed.
Ok, LGTM, but would prefer Uros to have final voice.
Jakub
Qing Zhao writes:
>>> + }
>>> + return need_zeroed_hardregs;
>>> +}
>>> +
>>>
>>> With the small testing case:
>>> int
>>> test ()
>>> {
>>> return 1;
>>> }
>>>
>>> If I compiled it with
>>>
>>> /home/qinzhao/Install/latest/bin/gcc -O2 -fzero-call-used-regs=all-arg t.c
>>>
>>> It will
Hi,
this patch contains basic fixup of the fnspec strings for caf, however I
am quite sure I need help on this (short of dropping them all).
I first assumed that we have missing "." for return values since most
strings had as many letters as parametrs, but it is not true.
I tried to check the
* Jakub Jelinek:
> On Wed, Sep 30, 2020 at 04:29:34PM +0200, Florian Weimer wrote:
>> > Thinking about it more, wouldn't it better to just imply generic tuning
>> > for these -march= options?
>>
>> I think this is what the patch does? See the x86-64-v3-haswell.c
>> test.
>
> No, I think it will
On 9/28/20 3:09 PM, Jason Merrill wrote:
On 9/28/20 3:56 AM, Richard Biener wrote:
On Fri, 25 Sep 2020, Jason Merrill wrote:
On 9/25/20 2:30 AM, Richard Biener wrote:
On Thu, 24 Sep 2020, Jason Merrill wrote:
On 9/24/20 3:43 AM, Richard Biener wrote:
On Wed, 23 Sep 2020, Jason Merrill
Add a testcase for PR target/96827 which was fixed by r11-3559:
commit 97b798d80baf945ea28236eef3fa69f36626b579
Author: Joel Hutton
Date: Wed Sep 30 15:08:13 2020 +0100
[SLP][VECT] Add check to fix 96837
PR target/96827
* gcc.target/i386/pr96827.c: New test.
---
On Wed, 30 Sep 2020 at 16:03, Alex Coplan wrote:
>
> Ping. Are these testsuite fixes for ILP32 OK?
>
LGTM, by looking at the patch (I didn't run it in ilp32 mode)
Thanks
Christophe
> On 18/09/2020 17:15, Alex Coplan wrote:
> > Hi Christophe,
> >
> > On 08/09/2020 10:14, Christophe Lyon wrote:
On 29/09/20 13:51 +0200, Christophe Lyon via Libstdc++ wrote:
On Sat, 26 Sep 2020 at 21:42, Jonathan Wakely via Gcc-patches
wrote:
Glibc 2.32 adds a global variable that says whether the process is
single-threaded. We can use this to decide whether to elide atomic
operations, as a more
This amends SLP reduction testcases that currently trigger
vect_attempt_slp_rearrange_stmts eliding load permutations to
verify this is actually happening.
tested on x86_64-unknown-linux-gnu, pushed
2020-09-30 Richard Biener
* gcc.dg/vect/pr37027.c: Amend.
*
On Wed, Sep 30, 2020 at 04:29:34PM +0200, Florian Weimer wrote:
> > Thinking about it more, wouldn't it better to just imply generic tuning
> > for these -march= options?
>
> I think this is what the patch does? See the x86-64-v3-haswell.c
> test.
No, I think it will have that behavior solely
> On Sep 30, 2020, at 4:21 AM, Richard Sandiford
> wrote:
>
> Qing Zhao mailto:qing.z...@oracle.com>> writes:
>> Hi, Richard,
>>
>> At the same time testing aarch64, I also tested the default implementation
>> on rs6000 target.
>>
>> The default implementation now is:
>>
>> +/* The
* Jakub Jelinek:
> On Wed, Sep 30, 2020 at 04:05:41PM +0200, Florian Weimer wrote:
>> > I think the documentation should state that these are not valid in -mtune=,
>> > just in -march=, and that using -march=x86-64-v* will not change tuning.
>> > I guess there should be some testsuite coverage
On Wed, Sep 30, 2020 at 04:05:41PM +0200, Florian Weimer wrote:
> > I think the documentation should state that these are not valid in -mtune=,
> > just in -march=, and that using -march=x86-64-v* will not change tuning.
> > I guess there should be some testsuite coverage for the for some
* Jakub Jelinek:
> On Wed, Sep 30, 2020 at 02:27:38PM +0200, Florian Weimer wrote:
>> --- a/gcc/doc/invoke.texi
>> +++ b/gcc/doc/invoke.texi
>> @@ -29258,6 +29258,13 @@ of the selected instruction set.
>> @item x86-64
>> A generic CPU with 64-bit extensions.
>>
>> +@item x86-64-v2
>> +@itemx
Thanks for the fix! I forgot that we don't have builtin check for
target-supports.exp.
Will update these once we implement AMX with builtins.
Jakub Jelinek 于2020年9月30日周三 下午7:51写道：
> On Fri, Sep 18, 2020 at 04:31:55PM +0800, Hongyu Wang via Gcc-patches
> wrote:
> > Very Appreciated for your
Ping. Are these testsuite fixes for ILP32 OK?
On 18/09/2020 17:15, Alex Coplan wrote:
> Hi Christophe,
>
> On 08/09/2020 10:14, Christophe Lyon wrote:
> > On Mon, 17 Aug 2020 at 11:00, Alex Coplan wrote:
> > >
> > > gcc/ChangeLog:
> > >
> > > * config/aarch64/aarch64.md
> > >
Now adding gcc-patches too
> -Original Message-
> From: Kyrylo Tkachov
> Sent: 30 September 2020 15:02
> To: Christophe Lyon
> Subject: RE: [PATCH 1/1] arm: [testsuite] Skip thumb2-cond-cmp tests on
> Cortex-M [PR94595]
>
> Hi Christophe,
>
> > -Original Message-
> > From:
Hi Srinath,
> -Original Message-
> From: Srinath Parvathaneni
> Sent: 30 September 2020 12:51
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov
> Subject: [GCC][PATCH] arm: Fix MVE intrinsics polymorphic variants wrongly
> generating __ARM_undef type (pr96795).
>
> Hello,
>
> This
Ping?
On Thu, 24 Sep 2020 at 15:18, Christophe Lyon
wrote:
>
> Ping?
>
> On Mon, 7 Sep 2020 at 18:13, Christophe Lyon
> wrote:
> >
> > Since r204778 (g571880a0a4c512195aa7d41929ba6795190887b2), we favor
> > branches over IT blocks on Cortex-M. As a result, instead of
> > generating two nested
Now hiddenness is managed by name-lookup, we no longer need
DECL_HIDDEN_FRIEND_P.
This removes it. Mainly by deleting its bookkeeping, but there are a
couple of uses
1) two name lookups look at it to see if they found a hidden thing.
In one we have the OVERLOAD, so can record OVL_HIDDEN_P.
On Wed, Sep 30, 2020 at 01:39:11PM +0200, Jakub Jelinek wrote:
> On Wed, Sep 30, 2020 at 01:21:44PM +0200, Stefan Schulze Frielinghaus wrote:
> > I think the problem boils down that on S/390 we distinguish between four
> > states of a flag: explicitely set to yes/no and implicitely set to
> >
> -Original Message-
> From: Przemyslaw Wirkus
> Sent: 30 September 2020 11:39
> To: gcc-patches@gcc.gnu.org
> Cc: Richard Earnshaw ; Richard Sandiford
> ; Kyrylo Tkachov
> ; Marcus Shawcroft
>
> Subject: [PATCH][GCC][AArch64] Add support for Cortex-A78 and Cortex-
> A78AE
>
> This
> -Original Message-
> From: Przemyslaw Wirkus
> Sent: 30 September 2020 11:42
> To: gcc-patches@gcc.gnu.org
> Cc: ni...@redhat.com; Ramana Radhakrishnan
> ; Kyrylo Tkachov
> ; Richard Earnshaw
>
> Subject: [PATCH][GCC][ARM] Add support for Cortex-A78 and Cortex-A78AE
>
> This patch
On Wed, Sep 30, 2020 at 02:27:38PM +0200, Florian Weimer wrote:
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -29258,6 +29258,13 @@ of the selected instruction set.
> @item x86-64
> A generic CPU with 64-bit extensions.
>
> +@item x86-64-v2
> +@itemx x86-64-v3
> +@itemx
* Uros Bizjak:
> On Wed, Sep 30, 2020 at 2:27 PM Florian Weimer wrote:
>>
>> These micro-architecture levels are defined in the x86-64 psABI:
>>
>> https://gitlab.com/x86-psABIs/x86-64-ABI/-/commit/77566eb03bc6a326811cb7e9
>>
>> PTA_NO_TUNE is introduced so that the new processor alias table
On Wed, Sep 30, 2020 at 2:27 PM Florian Weimer wrote:
>
> These micro-architecture levels are defined in the x86-64 psABI:
>
> https://gitlab.com/x86-psABIs/x86-64-ABI/-/commit/77566eb03bc6a326811cb7e9
>
> PTA_NO_TUNE is introduced so that the new processor alias table entries
> do not affect the
On Tue, 29 Sep 2020 at 12:38, Kyrylo Tkachov wrote:
>
>
>
> > -Original Message-
> > From: Richard Sandiford
> > Sent: 29 September 2020 11:27
> > To: Kyrylo Tkachov
> > Cc: gcc-patches@gcc.gnu.org; ni...@redhat.com; Richard Earnshaw
> > ; Ramana Radhakrishnan
> > ; Dennis Zhang
> >
>
Hi Tobias,
This looks good to me - OK for master.
Thanks for the patch
Paul
On Wed, 30 Sep 2020 at 09:59, Tobias Burnus wrote:
> The non-contiguous had both check false positive and false
> negative results. Some more refinements
> are surely possible, but hopefully there are no longer
>
These micro-architecture levels are defined in the x86-64 psABI:
https://gitlab.com/x86-psABIs/x86-64-ABI/-/commit/77566eb03bc6a326811cb7e9
PTA_NO_TUNE is introduced so that the new processor alias table entries
do not affect the CPU tuning setting in ix86_tune.
The tests depend on the macros
[ was: Re: [committed][testsuite] Require non_strict_align in
pr94600-{1,3}.c ]
On 9/30/20 4:53 AM, Hans-Peter Nilsson wrote:
> On Thu, 24 Sep 2020, Tom de Vries wrote:
>
>> Hi,
>>
>> With the nvptx target, we run into:
>> ...
>> FAIL: gcc.dg/pr94600-1.c scan-rtl-dump-times final "\\(mem/v" 6
>>
On Tue, Sep 29, 2020 at 2:18 PM Tom de Vries wrote:
>
> On 9/29/20 8:59 AM, Richard Biener wrote:
> > On Mon, Sep 28, 2020 at 7:28 PM Tom de Vries wrote:
> >>
> >> [ was: Re: [Patch][nvptx] return true in libc_has_function for
> >> function_sincos ]
> >>
> >> On 9/26/20 6:47 PM, Tobias Burnus
Hello,
This patch fixes (PR96795) MVE intrinsic polymorphic variants vaddq, vaddq_m,
vaddq_x, vcmpeqq_m,
vcmpeqq, vcmpgeq_m, vcmpgeq, vcmpgtq_m, vcmpgtq, vcmpleq_m, vcmpleq, vcmpltq_m,
vcmpltq,
vcmpneq_m, vcmpneq, vfmaq_m, vfmaq, vfmasq_m, vfmasq, vmaxnmavq, vmaxnmavq_p,
vmaxnmvq,
vmaxnmvq_p,
On Fri, Sep 18, 2020 at 04:31:55PM +0800, Hongyu Wang via Gcc-patches wrote:
> Very Appreciated for your review again
>
> I just update the patch with adding XSAVE dependency and use
> __builtin_cpu_supports for runtime test.
Several tests FAIL when using older binutils that don't support AMX.
On Wed, Sep 30, 2020 at 01:37:46PM +0200, Tobias Burnus wrote:
> We missed to handle nested procedures.
>
> OK for the trunk?
Yes, thanks.
Jakub
On Wed, Sep 30, 2020 at 01:21:44PM +0200, Stefan Schulze Frielinghaus wrote:
> I think the problem boils down that on S/390 we distinguish between four
> states of a flag: explicitely set to yes/no and implicitely set to
> yes/no. If set explicitely, the option wins. For example, the options
>
We missed to handle nested procedures.
OK for the trunk?
Tobias
-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander
Walter
OpenMP: Add implicit declare target for nested
On Wed, Sep 30, 2020 at 11:32:55AM +0200, Jakub Jelinek wrote:
> On Mon, Sep 28, 2020 at 09:50:00PM +0200, Stefan Schulze Frielinghaus via
> Gcc-patches wrote:
> > This patch breaks quite a view test cases (target-attribute/tattr-*) on
> > IBM Z. Having a look at function
Hi all,
In this PR we have the wrong return type for some intrinsics. It should be
unsigned, but we implement it as signed.
Fix this by adjusting the type qualifiers used when creating the builtins and
fixing the type in the arm_neon.h intrinsic.
With the adjustment in qualifiers we now don't
Hi all,
In this PR the second argument to the intrinsics should be signed but we use an
unsigned one erroneously.
The corresponding builtins are already using the correct types so it's just a
matter of correcting the signatures
in arm_neon.h
Bootstrapped and tested on aarch64-none-linux-gnu.
> gcc/
>
> PR target/97184
> * config/i386/i386.md (UNSPECV_MOVDIRI): Renamed to ...
> (UNSPEC_MOVDIRI): This.
> (UNSPECV_MOVDIR64B): Renamed to ...
> (UNSPEC_MOVDIR64B): This.
> (movdiri): Use SET operation.
> (@movdir64b_): Likewise.
>
> gcc/testsuite/
>
> PR target/97184
> *
movti lacked an way of zeroing an FPR, meaning that we'd do:
mov x0, 0
mov x1, 0
fmovd0, x0
fmovv0.d[1], x1
instead of just:
moviv0.2d, #0
movtf had the opposite problem for GPRs: we'd generate:
moviv0.2d, #0
fmov
On 29/09/2020 14:20, Segher Boessenkool wrote:
> On Tue, Sep 29, 2020 at 11:36:12AM +0100, Alex Coplan wrote:
> > Is the combine change (a canonicalization fix, as described below) OK
> > for trunk in light of this info?
>
> Can you please resend it with correct info and a corresponding commit
>
This patch introduces support for Cortex-A78 [0] and Cortex-A78AE [1]
cpus.
[0]: https://www.arm.com/products/silicon-ip-cpu/cortex-a/cortex-a78
[1]: https://www.arm.com/products/silicon-ip-cpu/cortex-a/cortex-a78ae
OK for master branch ?
kind regards
Przemyslaw Wirkus
This patch introduces support for Cortex-A78 [0] and Cortex-A78AE [1]
cpus.
[0]: https://www.arm.com/products/silicon-ip-cpu/cortex-a/cortex-a78
[1]: https://www.arm.com/products/silicon-ip-cpu/cortex-a/cortex-a78ae
OK for master branch ?
kind regards
Przemyslaw Wirkus
gcc/ChangeLog:
Currently, make_extraction() identifies where we can emit an ASHIFT of
an extend in place of an extraction, but fails to make the corresponding
canonicalization/simplification when presented with a MULT by a power of
two. Such a representation is canonical when representing a left-shifted
address
Thanks for the update, looks good apart from…
"duanbo (C)" writes:
> @@ -4361,7 +4391,7 @@ vect_recog_mask_conversion_pattern (vec_info *vinfo,
>if (known_eq (TYPE_VECTOR_SUBPARTS (vectype1),
> TYPE_VECTOR_SUBPARTS (vectype2))
> && (TREE_CODE (rhs1) == SSA_NAME
On Tue, Sep 29, 2020 at 5:47 PM Florian Weimer wrote:
>
> It looks like these have been omitted by accident.
>
> gcc/
> * config/i386/i386-c.c (ix86_target_macros_internal): Define
> __LAHF_SAHF__ and __MOVBE__ based on ISA flags.
LGTM.
Thanks,
Uros.
>
> ---
>
On Tue, Sep 29, 2020 at 03:40:40PM -0600, Martin Sebor via Gcc-patches wrote:
> I will commit this patch later this week unless I hear concerns
> or suggestions for changes.
That is not how the patch review process works.
> + arat = tree_cons (get_identifier ("array"), flag, NULL_TREE);
On Mon, Sep 28, 2020 at 09:50:00PM +0200, Stefan Schulze Frielinghaus via
Gcc-patches wrote:
> This patch breaks quite a view test cases (target-attribute/tattr-*) on
> IBM Z. Having a look at function cl_target_option_restore reveals that
> some members of opts_set are reduced to 1 or 0
Qing Zhao writes:
> Hi, Richard,
>
> At the same time testing aarch64, I also tested the default implementation on
> rs6000 target.
>
> The default implementation now is:
>
> +/* The default hook for TARGET_ZERO_CALL_USED_REGS. */
> +
> +HARD_REG_SET
> +default_zero_call_used_regs
The non-contiguous had both check false positive and false
negative results. Some more refinements
are surely possible, but hopefully there are no longer
false positives.
I also now used this check for pointer assignments where the
LHS pointer has the contiguous attribute.
In the
Hi!
As mentioned in the PR, we only support due to a bug in constant expressions
std::construct_at on non-automatic variables, because we VERIFY_CONSTANT the
second argument of placement new, which fails verification if it is an
address of an automatic variable.
The following patch fixes it by
On Fri, Sep 25, 2020 at 04:30:26PM -0400, Jason Merrill via Gcc-patches wrote:
> On 9/15/20 3:57 AM, Jakub Jelinek wrote:
> > The following testcase is miscompiled (in particular the a and i
> > initialization). The problem is that build_special_member_call due to
> > the immediate constructors
On Tue, Sep 29, 2020 at 08:25:44PM +0100, Andrew Stubbs wrote:
> 2020-09-29 Andrew Stubbs
>
> * parallel.c (gomp_resolve_num_threads): Ignore nest_var on nvptx
> and amdgcn targets.
>
> diff --git a/libgomp/parallel.c b/libgomp/parallel.c
> index 2423f11f44a..0618056a7fe 100644
>
Casting to intptr_t states the intent of an integer to pointer cast
more clearly and ensures that the cast causes no loss of precision on
any platforms. LLP64 platforms eg. have a long value of 4 bytes and
pointer values of 8 bytes which may even cause compiler errors.
Fixes PR 96608
Would need
Generate assembly that is .localentry 1 with @notoc calls to match.
Bootstrapped and regression tested powerpc64le-linux on power8, and
bootstrapped on power10. (I lost the power10 machine to someone else
before I could build a baseline to compare against.)
gcc/
*
We've had this hack in the libgcc config to build libgcc with
-mcmodel=small for powerpc64 for a long time. It wouldn't be a bad
thing if someone who knows the multilib machinery well could arrange
for -mcmodel=small to be passed just for ppc64 when building for
earlier than power10. But for
On Tue, 29 Sep 2020, Segher Boessenkool wrote:
> Hi Raoni,
>
> Some of this isn't an rs6000 patch, but the subject says it is, so it
> might well not draw the attention it needs.
>
> Adding some Cc:s.
>
> On Fri, Sep 04, 2020 at 12:52:30PM -0300, Raoni Fassina Firmino wrote:
> > There is one
On Wed, Sep 30, 2020 at 5:56 AM Jim Wilson wrote:
>
> This is the gcc-10 branch version of the patch on mainline.
>
> Extends the configure check for zstd.h to also verify the zstd version,
> since gcc requires features that only exist in 1.3.0 and newer. Without
> this patch we get a build
On Tue, Sep 29, 2020 at 9:31 PM Jan Hubicka wrote:
>
> >
> > gcc/ChangeLog:
> >
> > 2020-09-07 Martin Jambor
> >
> > * params.opt (ipa-cp-large-unit-insns): New parameter.
> > * ipa-cp.c (get_max_overall_size): Use the new parameter.
> OK,
Maybe the IPA CP large-unit should be a
On Tue, 29 Sep 2020, Joel Hutton wrote:
> Hi All,
>
> The following patch adds a simple check to prevent slp stmts from vector
> constructors being rearranged. vect_attempt_slp_rearrange_stmts tries to
> rearrange to avoid a load permutation.
>
> This fixes PR target/96837
On Tue, 29 Sep 2020, Jan Hubicka wrote:
> > On September 29, 2020 4:20:42 PM GMT+02:00, Jan Hubicka
> > wrote:
> > >Hi,
> > >this patch is not needed but makes it possible to sanity check that
> > >fnspec match function signature. It turns out that there are quite few
> > >mistakes in that in
On Tue, Sep 29, 2020 at 3:07 PM Alexandre Oliva wrote:
>
> On Sep 29, 2020, Richard Biener wrote:
>
> > On Tue, Sep 29, 2020 at 9:23 AM Alexandre Oliva wrote:
>
> >> On Sep 28, 2020, Richard Biener wrote:
>
> > ifcombine should stop using fold*, yeah
>
> Wow, that's quite a lot of work for no
90 matches
Mail list logo
