On Tue, 31 Mar 2020, Maciej W. Rozycki wrote:
> Correct an issue with GCC commit 906b3eb9df6c ("Improve endianess
> detection.") and fix a typo in the __BYTE_ORDER fallback macro check
> that causes compilation errors like:
>
> .../include/plugin-api.h:162:2: error: #error "Could not detect
Hi!
The following testcase ICEs on armv7hl-linux-gnueabi.
try_combine is called on:
(gdb) p debug_rtx (i3)
(insn 20 12 22 2 (set (mem/c:SI (plus:SI (reg/f:SI 102 sfp)
(const_int -4 [0xfffc])) [1 x+0 S4 A32])
(reg:SI 125)) "pr94291.c":7:8 241 {*arm_movsi_insn}
Hi!
The following testcase ICEs in final_scan_insn_1. The problem is in the
@aarch64_compare_and_swaphi define_insn_and_split, since 9 it uses
aarch64_plushi_operand predicate for the "expected value" operand, which
allows either 0..0xfff constants or 0x1000..0xf000 constants (i.e. HImode
values
Richard Earnshaw writes:
> On 17/03/2020 12:34, Wilco Dijkstra wrote:
>> Hi Andrea,
>> I think the first part is fine when approved, but the 2nd part is
>> problematic like Szabolcs
>> already pointed out. We can't just change the ABI or semantics, and these
>> builtins are critical
>> for
On Tue, 31 Mar 2020, Jakub Jelinek wrote:
> Hi!
>
> The following testcase is optimized with char/unsigned char/signed char,
> but not with std::byte. The following patch fixes that. Didn't use
> INTEGRAL_TYPE_P because bswapping bools is just too weird.
Is it?
> Bootstrapped/regtested on
On Tue, 31 Mar 2020, Jakub Jelinek wrote:
> Hi!
>
> The following testcase is miscompiled since 4.9, we treat unsigned
> vector types as if they were signed and "optimize" negations across it.
>
> Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
> trunk?
OK.
David Malcolm writes:
> Andrea: I've pushed my proposed fix for the above to master as
> 3809bcd6c0ee324cbd855c68cee104c8bf134dbe. Does this fix the issue you
> were seeing?
>
> Thanks
> Dave
Hi,
yes super! I'll update the patch thanks.
Andrea
On Tue, 31 Mar 2020, Jakub Jelinek wrote:
> Hi!
>
> The following patch adjusts simplify_rotate to recognize more rotates,
> basically we allow even some same precision integral -> integral
> conversions, with the requirement that the RSHIFT_EXPR operand has to be
> done in unsigned type (i.e.
Jakub Jelinek writes:
> Hi!
>
> The following testcase ICEs in final_scan_insn_1. The problem is in the
> @aarch64_compare_and_swaphi define_insn_and_split, since 9 it uses
> aarch64_plushi_operand predicate for the "expected value" operand, which
> allows either 0..0xfff constants or
Pushed.
Thank you,
Claudiu
On Sun, Mar 29, 2020 at 2:05 AM Vineet Gupta via Gcc-patches
wrote:
>
> Enable big-endian suffixed dynamic linker per glibc multi-abi support.
>
> And to avoid a future churn and version pairingi hassles, also allow
> arc700 although glibc for ARC currently doesn't
Hi!
The following testcase is miscompiled since 4.9, we treat unsigned
vector types as if they were signed and "optimize" negations across it.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?
2020-03-31 Marc Glisse
Jakub Jelinek
PR
- The alignment for local variable was adjust during estimate_stack_frame_size,
however it seems wrong spot to adjust that, expand phase will adjust that
but it little too late to some gimple optimization, which rely on certain
target hooks need to check alignment, forwprop is an example
Hi Srinath,
> -Original Message-
> From: Srinath Parvathaneni
> Sent: 25 March 2020 18:48
> To: gcc-patches@gcc.gnu.org
> Cc: Richard Earnshaw ; Kyrylo Tkachov
>
> Subject: [GCC][ARM][PATCH]: Add support for MVE ACLE intrinsics
> polymorphic variants for +mve.fp option.
>
> Hello,
>
>
Hi!
The following patch adjusts simplify_rotate to recognize more rotates,
basically we allow even some same precision integral -> integral
conversions, with the requirement that the RSHIFT_EXPR operand has to be
done in unsigned type (i.e. logical right shift), so that we compensate for
the
- The arch string rule has changed in latest spec, it introduced new
multi-letter extension prefix with 'h' and 'z', and drop `sx`. also
adjust parsing order for 's' and 'x'.
gcc/ChangeLog
* riscv-common.c (parse_sv_or_non_std_ext): Rename to
parse_multiletter_ext.
- Implied rule are introduced into latest RISC-V isa spec.
- Only implemented D implied F-extension. Zicsr and Zifence are not
implement yet, so the rule not included in this patch.
gcc/ChangeLog
* common/config/riscv/riscv-common.c (riscv_implied_info_t): New.
Hi!
The following testcase is optimized with char/unsigned char/signed char,
but not with std::byte. The following patch fixes that. Didn't use
INTEGRAL_TYPE_P because bswapping bools is just too weird.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for GCC11 (or is
it simple enough
Hi!
> -Original Message-
> From: Richard Sandiford [mailto:richard.sandif...@arm.com]
> Sent: Monday, March 30, 2020 8:08 PM
> To: Yangfei (Felix)
> Cc: gcc-patches@gcc.gnu.org; rguent...@suse.de
> Subject: Re: [PATCH] ICE: in vectorizable_load, at tree-vect-stmts.c:9173
>
> "Yangfei
"Yangfei (Felix)" writes:
> Hi!
>
>> -Original Message-
>> From: Richard Sandiford [mailto:richard.sandif...@arm.com]
>> Sent: Monday, March 30, 2020 8:08 PM
>> To: Yangfei (Felix)
>> Cc: gcc-patches@gcc.gnu.org; rguent...@suse.de
>> Subject: Re: [PATCH] ICE: in vectorizable_load, at
Hello,
For the following MVE ACLE intrinsics, polymorphic variant support is missing
on the trunk.
vbicq_n_s16, vbicq_n_s32, vbicq_n_u16 and vbicq_n_u32.
This patch add the polymorphic variant support for above intrinsics.
Please refer to M-profile Vector Extension (MVE) intrinsics [1] for
Hi Srinath,
> -Original Message-
> From: Srinath Parvathaneni
> Sent: 31 March 2020 10:19
> To: gcc-patches@gcc.gnu.org
> Cc: Richard Earnshaw ; Kyrylo Tkachov
>
> Subject: [GCC][ARM][PATCH]: Add MVE ACLE intrinsics vbicq_n_*
> polymorphic variant support.
>
> Hello,
>
> For the
This is a somewhat large patch that does nothing. :-)
The output mddump file has only whitespace changes, plus a few constant
64's replaced by GET_MODE_NUNITS that always evaluate to 64.
The point is that I can add more vector modes, in a future patch,
without also making all these
On 3/31/20 2:29 PM, Jan Hubicka wrote:
Well, I basically went through all pointers and tried to get rid of as
many of them as possible. CONTEXT pointers do increase size of SCCs
that increases chance they will not get merged and also processing time
of merging algorithm. I guess if we need to
Hi all,
Updated version of the patch addressing last comments.
Regression clean, okay to apply?
Bests
Andrea
gcc/jit/ChangeLog
2020-??-?? Andrea Corallo
David Malcolm
* docs/topics/compatibility.rst (LIBGCCJIT_ABI_13): New ABI tag
plus add version
> On Mon, Mar 30, 2020 at 10:41 AM Martin Liška wrote:
> >
> > Hi.
> >
> > The patch ensures that a deleted new/delete pair has a same context.
> > That will fix the issue presented in the PR.
> >
> > Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> I think this will
Hi,
This patch adds weak linkage to internal TypeInfo data on top of the
existing DECL_COMDAT, which helps in the unlikely event that two of the
same TypeInfo data ends up in multiple places.
Tested on x86_64-linux-gnu and committed to mainline.
Regards
Iain
---
gcc/d/ChangeLog:
*
Hi!
> -Original Message-
> From: Richard Sandiford [mailto:richard.sandif...@arm.com]
> Sent: Tuesday, March 31, 2020 4:55 PM
> To: Yangfei (Felix)
> Cc: gcc-patches@gcc.gnu.org; rguent...@suse.de
> Subject: Re: [PATCH] ICE: in vectorizable_load, at tree-vect-stmts.c:9173
> >
> > Yes, I
Correct an issue with GCC commit 906b3eb9df6c ("Improve endianess
detection.") and fix a typo in the __BYTE_ORDER fallback macro check
that causes compilation errors like:
.../include/plugin-api.h:162:2: error: #error "Could not detect architecture
endianess"
on systems that do not provide
"Yangfei (Felix)" writes:
>> > I think I need a sponsor if this patch can go separately.
>>
>> Yeah, please fill in the form on:
>>
>>https://sourceware.org/cgi-bin/pdw/ps_form.cgi
>>
>> listing me as sponsor.
>
> Hmm, I already have an account : - )
Oops, yes. I should have checked,
cpplib-10.1-b20200209.sr.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'cpplib' has been submitted
by the Serbian team of translators. The file is available at:
https://translationproject.org/latest/cpplib/sr.po
(This file,
Committed as obvious.
gcc/
-xx-xx Claudiu Zissulescu
* config/arc/arc.h (ASM_FORMAT_PRIVATE_NAME): Fix it.
---
gcc/ChangeLog| 6 +-
gcc/config/arc/arc.h | 6 +++---
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index
Use HOST_WIDE_INT_PRINT_DEC macro instead of %ld for format printing.
Committed as obvious.
gcc/
-xx-xx Claudiu Zissulescu
* config/arc/arc.c (arc_print_operand): Use
HOST_WIDE_INT_PRINT_DEC macro.
---
gcc/ChangeLog| 5 +
gcc/config/arc/arc.c | 6 +++---
2
gomp_map_vars_internal contains:
if ((kind & typemask) == GOMP_MAP_TO_PSET)
{
size_t j;
for (j = i + 1; j < mapnum; j++)
if (!GOMP_MAP_POINTER_P (get_kind (short_mapkind, kinds, j)
where one accesses not only the i-th hostaddr
Hello,
Following MVE ACLE intrinsics have an issue with writeback to the base address.
vldrdq_gather_base_wb_s64, vldrdq_gather_base_wb_u64,
vldrdq_gather_base_wb_z_s64,
vldrdq_gather_base_wb_z_u64, vldrwq_gather_base_wb_s32,
vldrwq_gather_base_wb_u32,
vldrwq_gather_base_wb_z_s32,
Hi,
This patch removes the manual insertion of padding for fields in
constructed struct literals, and instead uses memset() on the
declaration being initialized.
When compiling optimized builds, the intent is usually missed, and
alignment holes end up with non-zero values in them anyway.
On Tue, 2020-03-31 at 14:05 +0200, Andrea Corallo wrote:
> Hi all,
>
> Updated version of the patch addressing last comments.
Thanks.
> Regression clean, okay to apply?
OK
> Bests
>
> Andrea
>
> gcc/jit/ChangeLog
> 2020-??-?? Andrea Corallo
> David Malcolm
>
> *
Ping, can we have the -moutline-atomics patches committed to the gcc-9 branch?
Thanks,
Sebastian
On 3/24/20, 7:24 PM, "Pop, Sebastian" wrote:
Hi Kyrill,
Thanks for pointing out the two missing bug fixes.
Please see attached all the back-ported patches.
All the patches
Richard Henderson writes:
> While cmp (extended register) and cmp (immediate) uses ,
> cmp (shifted register) uses . So we can perform cmp xzr, x0.
>
> For ccmp, we only have as an input.
>
> * config/aarch64/aarch64.md (cmp): For operand 0, use
> aarch64_reg_or_zero. Shuffle
On 3/30/20 6:46 PM, Patrick Palka wrote:
On Mon, 30 Mar 2020, Jason Merrill wrote:
On 3/30/20 3:58 PM, Patrick Palka wrote:
On Thu, 26 Mar 2020, Jason Merrill wrote:
On 3/22/20 9:21 PM, Patrick Palka wrote:
This patch relaxes an assertion in tsubst_default_argument that exposes
a
latent
bug
Hi Claus,
> -Original Message-
> From: linux-snps-arc On Behalf
> Of Claudiu Zissulescu
> Ianculescu
> Sent: Tuesday, March 31, 2020 1:07 PM
> To: Vineet Gupta
> Cc: linux-snps-...@lists.infradead.org; gcc-patches@gcc.gnu.org; Claudiu
> Zissulescu
>
> Subject: Re: [PATCH] [ARC] Allow
Since constant_call_address_operand has
;; Test for a pc-relative call operand
(define_predicate "constant_call_address_operand"
(match_code "symbol_ref")
{
if (ix86_cmodel == CM_LARGE || ix86_cmodel == CM_LARGE_PIC
|| flag_force_indirect_call)
return false;
if
On Tue, Mar 31, 2020 at 05:14:17PM +0200, Tobias Burnus wrote:
> gomp_map_vars_internal contains:
>
> if ((kind & typemask) == GOMP_MAP_TO_PSET)
> {
> size_t j;
> for (j = i + 1; j < mapnum; j++)
> if (!GOMP_MAP_POINTER_P (get_kind
On 3/31/20 9:55 AM, Richard Sandiford wrote:
>> (define_insn "cmp"
>>[(set (reg:CC CC_REGNUM)
>> -(compare:CC (match_operand:GPI 0 "register_operand" "rk,rk,rk")
>> -(match_operand:GPI 1 "aarch64_plus_operand" "r,I,J")))]
>> +(compare:CC (match_operand:GPI 0
Well its a hard requirement considering glibc is still using gcc-9 !
Thx,
-Vineet
On 3/31/20 9:26 AM, Alexey Brodkin wrote:
> Hi Claus,
>
>> -Original Message-
>> From: linux-snps-arc On Behalf
>> Of Claudiu Zissulescu
>> Ianculescu
>> Sent: Tuesday, March 31, 2020 1:07 PM
>> To:
Richard Henderson writes:
> Duplicate all usub_*_carryinC, but use xzr for the output when we
> only require the flags output. The signed versions use sign_extend
> instead of zero_extend for combine's benefit.
>
> These will be used shortly for TImode comparisons.
>
> *
On Tue, 31 Mar 2020, Jason Merrill wrote:
> On 3/30/20 6:46 PM, Patrick Palka wrote:
> > On Mon, 30 Mar 2020, Jason Merrill wrote:
> > > On 3/30/20 3:58 PM, Patrick Palka wrote:
> > > > On Thu, 26 Mar 2020, Jason Merrill wrote:
> > > >
> > > > > On 3/22/20 9:21 PM, Patrick Palka wrote:
> > > > >
On 3/31/20 5:35 PM, Jakub Jelinek via Gcc-patches wrote:
Doing the mappings separately is intentional, while for target data or
target region mappings it is very likely they will be all released together
as well, so it doesn't matter if they all go from the single same mapping,
for target enter
On Tue, Mar 31, 2020 at 07:41:40PM +0200, Tobias Burnus wrote:
> On 3/31/20 5:35 PM, Jakub Jelinek via Gcc-patches wrote:
>
> > Doing the mappings separately is intentional, while for target data or
> > target region mappings it is very likely they will be all released together
> > as well, so it
David Malcolm writes:
> On Tue, 2020-03-31 at 14:05 +0200, Andrea Corallo wrote:
>> Hi all,
>>
>> Updated version of the patch addressing last comments.
>
> Thanks.
>
>> Regression clean, okay to apply?
>
> OK
Committed as 63b2923dc6f5.
Thanks
Andrea
We represent 'this' in a default member initializer with a PLACEHOLDER_EXPR.
Normally in constexpr evaluation when we encounter one it refers to
ctx->ctor, but when we're creating a temporary of class type, that replaces
ctx->ctor, so a PLACEHOLDER_EXPR that refers to the type of the member being
On Mon, 30 Mar 2020, Mike Stump wrote:
> > I have actually considered extracting the bits already, but I hesitated
> > putting that forward that as having looked at the part that we require I
> > have thought it to be very messy:
>
> Yeah, sometimes it's like that. I glanced at the work, if
On 3/31/20 11:34 AM, Richard Sandiford wrote:
>> +(define_insn "*cmp3_carryinC"
>> + [(set (reg:CC CC_REGNUM)
>> +(compare:CC
>> + (ANY_EXTEND:
>> +(match_operand:GPI 0 "register_operand" "r"))
>> + (plus:
>> +(ANY_EXTEND:
>> + (match_operand:GPI 1
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index e0e7f540c219..f1f2064df459 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -2817,7 +2817,7 @@ the same type as the target function. As a result of
the @code{copy}
attribute the alias also shares the same attributes as the
Hi,
This patch adds always_inline to the d_langhook_common_attribute_table.
The attribute is not directly accessible from user code, rather it is
indirectly added from the @forceinline attribute. Even so, a handler
should be present for it to prevent false positive warnings.
Said warnings are
Hi,
This change fixes the symbol merging in get_symbol_decl to also consider
prototypes. This allows the ability to set user defined attributes on
the prototype of a function, which then get applied to the definition,
if found later in the compilation.
The lowering of UDAs to GCC attributes has
On Fri, Mar 27, 2020 at 7:36 PM Fritz Reese wrote:
>
> On Fri, Mar 6, 2020 at 6:18 PM Steve Kargl
> wrote:
> [...]
> > TL;DR version.
> >
> > Fix the simplification and handling of the degree trigonometric functions.
> > This includes fixing a number of ICEs. See PR 93871.
>
> An updated
FWIW this change needs a pairing glibc change so must NOT be included for
upcoming
2020.x release which still has old version of glibc !
-Vineet
On 3/31/20 10:57 AM, Vineet Gupta wrote:
> Well its a hard requirement considering glibc is still using gcc-9 !
>
> Thx,
> -Vineet
>
> On 3/31/20
58 matches
Mail list logo
