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 pe
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 now,
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/
* config/rs6000/ppc-asm.h
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 t
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
> -
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 (b
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 not
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 non-contiguous-
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 (HARD_REG_SET
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 dependin
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);
Be
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.
>
> ---
> gcc/config/i386/i
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
>
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 i
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:
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/Chang
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
> m
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
> 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
> * gcc.target/i386/movd
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.
P
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 ne
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 cl_target_option_restore
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 p
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
> `-
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 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.
F
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, v
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 wro
[ 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
>>
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 ad
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
> fal
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
> >
> >
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
* 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 entr
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 x86-64-v4
> -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 i
> -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 pa
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
> > yes/n
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.
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 I
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 pat
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: Gcc-p
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
> > > (*a
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 revi
* 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 x
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 unexpecte
* 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 for
> 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 defau
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 wh
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.
* gcc.dg/vect/pr6779
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 precise
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:
>
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.
---
gcc/tests
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 wrot
* 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
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 stri
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
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
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 pa
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
gfortra
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 we
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 l
> > 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]: https://www.arm.com/products/silicon-
> > 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]:
> > https://www.arm.com/products/
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 (gfc_descriptor
> 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 = reg_raw_mode[reg
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 wo
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, leading
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.
*
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 look
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 wh
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 va
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 t
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 whet
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 (TARGET_MINIMAL_T
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, thi
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 deduction
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 t
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
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
-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 othe
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
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
--- a/gc
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 hel
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:
> >> ...
> >> FAIL:
On Wed, 30 Sep 2020, Segher Boessenkool wrote:
> 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 docume
On Wed, Sep 30, 2020 at 9:20 PM Martin Sebor via Gcc-patches
wrote:
>
> 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 chang
87 matches
Mail list logo
