Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542113.html
On 3/16/20 6:00 PM, Martin Sebor wrote:
On 3/16/20 3:41 PM, Jeff Law wrote:
On Mon, 2020-03-16 at 11:39 -0600, Martin Sebor via Gcc-patches wrote:
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-March/541521.html
I
Updated patch, fixes some whitespace issues along with ensuring that
libstdc++-v3/include/Makefile.in is regenerated.
>From 2f707faab97abde776bc7c6e06f7a7c471711962 Mon Sep 17 00:00:00 2001
From: Thomas Rodgers
Date: Thu, 12 Mar 2020 17:50:09 -0700
Subject: [PATCH] Add C++2a
As outlined in the BZ simplify_logical_relational_operation does not validate
that the comparison code it selects is ultimately valid for the mode of the
comparison.
So we could have something like:
(ior (lt (...)) (gt (...))
Which it happily turns into
(ltgt (...))
Which is not valid for
This is a revision of a patch that I've submitted several times. It makes
-mpcrel the default on Linux 64-bit systems that use ELF v2, use the medium
code mode, and if the user did not disable prefixed load/store instructions for
-mcpu=future.
Previous versions of the patch had two macros that
rs6000 - allow builtin initialization regardless of mask
Hi,
Disable the code that limits initialization of builtins based
on the rs6000_builtin_mask. This allows all built-ins to be
properly referenced when building code using #pragma for cpu
targets newer than what was specified by the
On Mon, 23 Mar 2020, Jason Merrill wrote:
> On 3/22/20 5:14 PM, Patrick Palka wrote:
> > In this PR we're emitting -Wnoexcept warnings about potentially-throwing
> > NSDMIs
> > when computing the noexcept specification of a class's defaulted default
> > constructor. Alhough these warnings are in
On 3/22/20 5:14 PM, Patrick Palka wrote:
In this PR we're emitting -Wnoexcept warnings about potentially-throwing NSDMIs
when computing the noexcept specification of a class's defaulted default
constructor. Alhough these warnings are in some sense valid, this patch takes
the route of
On Sat, Mar 21, 2020 at 09:40:24AM +0100, Jakub Jelinek wrote:
> Hi!
>
> On Thu, Mar 19, 2020 at 09:38:30PM +, Joseph Myers wrote:
> > The second patch is OK.
>
> Unfortunately the patch broke
> +FAIL: gcc.dg/pr20245-1.c (internal compiler error)
> +FAIL: gcc.dg/pr20245-1.c (test for excess
g:497498c878d48754318e486428e2aa30854020b9 caused lra to cycle
on some SDmode reloads for power6. As explained in more detail
in the PR comments, the problem was a conflict between two target
hooks: rs6000_secondary_memory_needed_mode required SDmode FPR
reloads to use DDmode memory (rightly,
Hi Srinath,
> -Original Message-
> From: Srinath Parvathaneni
> Sent: 23 March 2020 17:45
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov
> Subject: [PATCH v2][ARM][GCC][14x]: MVE ACLE whole vector left shift with
> carry intrinsics.
>
> Hello Kyrill,
>
> Following patch is the
Hi Srinath,
> -Original Message-
> From: Srinath Parvathaneni
> Sent: 23 March 2020 17:44
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov
> Subject: [PATCH v2][ARM][GCC][13x]: MVE ACLE scalar shift intrinsics.
>
> Hello Kyrill,
>
> Following patch is the rebased version of v1.
>
Hi Srinath,
> -Original Message-
> From: Srinath Parvathaneni
> Sent: 23 March 2020 17:43
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov
> Subject: [PATCH v2][ARM][GCC][12x]: MVE ACLE intrinsics to set and get
> vector lane.
>
> Hello Kyrill,
>
> Following patch is the rebased
Hi all,
attached the final version of the patch for the 200 characters limit
for literal strings addressing comments on the missing "testcases"
array entry (apologies) and alphabetic order.
make check-jit is passing clean.
Pushed into trunk.
Best Regards
Andrea
gcc/jit/ChangeLog
2020-03-23
Hello Kyrill,
Following patch is the rebased version of v1.
(version v1) https://gcc.gnu.org/pipermail/gcc-patches/2019-November/534344.html
Hello,
This patch supports following MVE ACLE whole vector left shift with carry
intrinsics.
vshlcq_m_s8, vshlcq_m_s16, vshlcq_m_s32, vshlcq_m_u8,
Hello Kyrill,
Following patch is the rebased version of v1.
(version v1) https://gcc.gnu.org/pipermail/gcc-patches/2019-November/534350.html
Hello,
This patch supports following MVE ACLE scalar shift intrinsics.
sqrshr, sqrshrl, sqrshrl_sat48, sqshl, sqshll, srshr, srshrl, uqrshl,
Hello Kyrill,
Following patch is the rebased version of v1.
(version v1) https://gcc.gnu.org/pipermail/gcc-patches/2019-November/534346.html
Hello,
This patch supports following MVE ACLE intrinsics to get and set vector lane.
vsetq_lane_f16, vsetq_lane_f32, vsetq_lane_s16,
On Mon, Mar 23, 2020 at 10:17 AM Martin Liška wrote:
>
> On 3/23/20 5:06 PM, H.J. Lu wrote:
> > #if __has_include ()
> > ...
> > #ifdef __BYTE_ORDER
> > #if __BYTE_ORDER == __BIG_ENDIAN
> > ...
> >
> > We support V2 interface only if defines __BYTE_ORDER?
>
> Right now we rely on __BIG_ENDIAN__
On 3/23/20 5:06 PM, H.J. Lu wrote:
#if __has_include ()
...
#ifdef __BYTE_ORDER
#if __BYTE_ORDER == __BIG_ENDIAN
...
We support V2 interface only if defines __BYTE_ORDER?
Right now we rely on __BIG_ENDIAN__ which is a weak endianess detection.
So we either need a very robust endianess
Hi,
the ordering of some fields in struct sigaction on s390x (64bit)
differs compared to s390 and other architectures.
This patch adjusts this order according to the definition of
/sysdeps/unix/sysv/linux/s390/bits/sigaction.h
Without this fix e.g. the call
sigaction( suspendSignalNumber, ,
Hi,
this patch picks up Robin Dapps patch __tls_get_offset-in-separate.S.
See "Bugzilla 91628 - libdruntime uses glibc internal symbol on s390"
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91628)
The original purpose was to get rid of the usage of the glibc-internal
symbol
On 3/23/20 8:49 AM, Jason Merrill wrote:
On 3/21/20 5:59 PM, Martin Sebor wrote:
+ /* Diagnose class/struct/union mismatches. IS_DECLARATION is
false
+ for alias definition. */
+ bool decl_class = (is_declaration
+ && cp_parser_declares_only_class_p (parser));
On Mon, Mar 23, 2020 at 8:39 AM Richard Biener
wrote:
>
> On Mon, Mar 23, 2020 at 4:07 PM Martin Liška wrote:
> >
> > Hi.
> >
> > There's a patch draft that will do the proper versioning of API.
>
> Would sth like this be preferred on the binutils side or would
> splitting up the 'def' field via
On Mon, 2020-03-23 at 16:32 +0100, Andrea Corallo wrote:
> Hi all,
>
> I'd like to submit this for PR94144.
>
> The patch prevent 'simplify_logical_relational_operation' to generate
> insn with a float only operator with non float operands.
>
>
> In the PR the following
>
> (ior:SI (gt:SI
On Mon, Mar 23, 2020 at 4:34 PM Jakub Jelinek wrote:
>
> On Mon, Mar 23, 2020 at 04:29:12PM +0100, Richard Biener wrote:
> > I wonder if we can leverage the bswap pass for rotate detection
> > (see find_bswap_or_nop which matches the symbolic number
> > against either 1:1 or byte-swapped
On Mon, Mar 23, 2020 at 4:07 PM Martin Liška wrote:
>
> Hi.
>
> There's a patch draft that will do the proper versioning of API.
Would sth like this be preferred on the binutils side or would
splitting up the 'def' field via shift better?
@@ -87,25 +87,30 @@ struct ld_plugin_symbol
{
char
On Mon, Mar 23, 2020 at 04:29:12PM +0100, Richard Biener wrote:
> I wonder if we can leverage the bswap pass for rotate detection
> (see find_bswap_or_nop which matches the symbolic number
> against either 1:1 or byte-swapped variants, to be added would be
> rotate and shift patterns).
That pass
Hi all,
I'd like to submit this for PR94144.
The patch prevent 'simplify_logical_relational_operation' to generate
insn with a float only operator with non float operands.
In the PR the following
(ior:SI (gt:SI (reg:CC 66 cc)
(const_int 0 [0]))
(le:SI (reg:CC 66 cc)
Hi!
Now that I'm looking into enabling AMD GCN offloading in my builds, I
have a few concerns here. ;-)
On 2018-09-14T10:18:12-0600, Jeff Law wrote:
> On 9/5/18 5:52 AM, a...@codesourcery.com wrote:
>>
>> The GCN toolchain must use the LLVM assembler and linker because there's no
>> binutils
On Mon, Mar 23, 2020 at 2:23 PM Stefan Schulze Frielinghaus via
Gcc-patches wrote:
>
> Hi all,
>
> A rotate of a signed integer is not recognized so far.
>
> int32_t f (int32_t x)
> {
> return (x << 5) | (int32_t)((uint32_t)x >> 27);
> }
>
> The code above is unoptimized in contrast to
Hi Andre,
> -Original Message-
> From: Andre Vieira (lists)
> Sent: 23 March 2020 14:38
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov
> Subject: [PATCH 1/2] arm: Add earlyclobber to MVE instructions that require
> it
>
>
> Hi,
>
> This patch adds an earlyclobber to the MVE
On Mon, Mar 23, 2020 at 10:53 AM Yangfei (Felix) wrote:
>
> Hi,
>
> I created a bug for this issue:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94269
> Looks like widening_mul phase may move multiply instruction from outside
> the loop to inside the loop, merging with one add instruction
On March 23, 2020 1:43:30 PM GMT+01:00, "Martin Liška" wrote:
>On 3/23/20 11:35 AM, Jakub Jelinek wrote:
>> I don't think so. That is about the target, but you care about the
>host.
>
>I see.
>
>> Wouldn't it be much easier not to do this and simply use macros for
>bits
>> from the full 32-bit
Hi.
The patch was supposed to be a next stage1 material, but then PR94271
was reported. The patch for it includes the hunk and one more that
leaves unique_name and resolution for the "default" clone. That will
align the symbol with other target clones and it's name will become
privatized
On Tue, Mar 17, 2020 at 04:05:31PM -0400, Jason Merrill wrote:
> On 3/16/20 10:01 PM, Marek Polacek wrote:
> > On Mon, Mar 16, 2020 at 05:12:15PM -0400, Jason Merrill wrote:
> > > On 3/16/20 10:57 AM, Marek Polacek wrote:
> > > > Now that convert_like creates an IMPLICIT_CONV_EXPR when it converts
Hi.
There's a patch draft that will do the proper versioning of API.
It's a subject for discussion.
Martin
>From b3f88adc91c36649bec3ed125b3e36ee89143bab Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Mon, 23 Mar 2020 16:01:29 +0100
Subject: [PATCH] Introduce ld_plugin_symbol_v2 for LTO
Apologies, 2nd attempt:
gcc/fortran/ChangeLog:
Steven G. Kargl
PR fortran/93814
* resolve.c (gfc_verify_binding_labels): Handle symbols with
the subroutine attribute separately from symbols with the
function attribute.
gcc/testsuite/ChanheLog:
Mark Eggleston
On 3/21/20 5:59 PM, Martin Sebor wrote:
+ /* Diagnose class/struct/union mismatches. IS_DECLARATION is false
+for alias definition. */
+ bool decl_class = (is_declaration
+&& cp_parser_declares_only_class_p (parser));
cp_parser_check_class_key
Attached patch fixes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88877.
ChangeLog Entry.
2020-03-23 Kamlesh Kumar
* rtl.h : Defined Tuple for bundling rtx, mode and
unsignedness default as 0
Added Extra argument (unsignedp) in emit_library_call and
emit_library_call_value.
On 3/20/20 7:02 PM, Marek Polacek wrote:
On Fri, Mar 20, 2020 at 02:12:49PM -0400, Jason Merrill wrote:
On 3/20/20 1:06 PM, Marek Polacek wrote:
Wonderful. I've added a bunch of tests, and some from the related DRs too.
But I had a problem with the class-or-decltype case: if we have
template
Hi,
This patch adds an earlyclobber to the MVE instructions that require it
and were missing it. These are vrev64 and 32-bit element variants of
vcadd, vhcadd vcmul, vmull[bt] and vqdmull[bt].
Regression tested on arm-none-eabi.
Is this OK for trunk?
Cheers,
Andre
2020-03-23 Andre
Hi,
This patch series changes all MVE tests into assembly tests so we check whether
the generated assembly is syntactically correct. The first patch of the series
fixes an issue this caught where the instructions don't allow destination and
source registers to be the same.
Andre Vieira (2):
The remaining IL adjustment done by SLP analysis turns out harmful
since we share them in the now multiple analyses states. It turns
out we do not actually need those apart from the case where we
reorg scalar stmts during re-arrangement when optimizing load
permutations in SLP reductions. But
On 22/03/2020 18:15, Jérémy Lefaure wrote:
> Hi Wilco,
>
> On Mon, Mar 09, 2020 at 05:53:41PM +, Wilco Dijkstra wrote:
>> Hi,
>>
>> There is no single PC offset that is correct given CPUs may use different
>> offsets.
>
> Isn't it always an offset of 8 in ARM mode and 4 bytes in Thumb mode
On Mon, Mar 23, 2020 at 02:40:12PM +0100, Tobias Burnus wrote:
> This patch fixes two issues:
>
> (a) The target size is the pointer size and
> host size is the variable size itself; thus, it fails often.
>
> (b) Only the host variable has the link-var bit flip, hence,
> we need to check this
This patch fixes two issues:
(a) The target size is the pointer size and
host size is the variable size itself; thus, it fails often.
(b) Only the host variable has the link-var bit flip, hence,
we need to check this one not the target var's size.
With this patch, the test case passes on
Hi all,
A rotate of a signed integer is not recognized so far.
int32_t f (int32_t x)
{
return (x << 5) | (int32_t)((uint32_t)x >> 27);
}
The code above is unoptimized in contrast to a version consisting only
of unsigned integers. I'm wondering if this is intended or not. Since
GCC
On Mon, Mar 23, 2020 at 02:10:08PM +0100, Tobias Burnus wrote:
> As discussed in IRC, it makes sense to use '$' or '.' as
> separator instead of '_' – and, if it is not available,
> use a '__' prefix besides the '_' suffix separator.
>
> OK?
Ok (the function does what we want, although for vars
As discussed in IRC, it makes sense to use '$' or '.' as
separator instead of '_' – and, if it is not available,
use a '__' prefix besides the '_' suffix separator.
OK?
Tobias
-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht
On Fri, 20 Mar 2020, David Malcolm wrote:
> On Wed, 2020-03-18 at 23:51 +0100, Andrea Corallo wrote:
> > Hi all,
> >
> > Updated version of the patch mainly addressing comments on the
> > concurrency issues.
> >
> > I came to the conclusions that the caching should be done in the
> > function
On 3/23/20 11:35 AM, Jakub Jelinek wrote:
I don't think so. That is about the target, but you care about the host.
I see.
Wouldn't it be much easier not to do this and simply use macros for bits
from the full 32-bit value (and use shifts)?
That would make the current small hack even
On Mon, Mar 23, 2020 at 07:46:17AM +, Yangfei (Felix) wrote:
> I think the problem here is how to make sure we are doing a ***equality***
> comparison with zero.
> We can only do the transformation under this condition.
> Then I see combine tries the following pattern:
>
> 173 Failed to
On 3/23/20 5:36 AM, Kito Cheng wrote:
Hi Nathan:
Tested variadic-sizeof4.C on x86, x86_64 with native compiler
Tested variadic-sizeof4.C on aarch64, arm-eabi, riscv32, riscv64,
mips, mips64 and nds32 with cross compiler.
And tested g++/dg.exp on arm-eabi with this patch, no new fail
On 20/03/2020 21:08, Tobias Burnus wrote:
Dear all,
normally, the target triplet does not play much of a role as
it is not really exposed to the user. However, for offloading,
it appears often:
* In distribution use, offloading support is compiled in, but
not enabled by default; one needs to
On Mon, Mar 23, 2020 at 11:28:00AM +0100, Martin Liška wrote:
> > > > You can use them but should be prepared for some fallback (e.g.
> > > > endian.h,
> > > > whatever else).
> > > > And there is also PDP endian...
> > >
> > > Huh, are we talking about something so complex like:
> > >
On 3/23/20 11:10 AM, Jakub Jelinek wrote:
On Mon, Mar 23, 2020 at 11:00:21AM +0100, Martin Liška wrote:
On 3/23/20 10:43 AM, Jakub Jelinek wrote:
On Mon, Mar 23, 2020 at 10:25:32AM +0100, Martin Liška wrote:
Hi.
As seen in the PR, sparc64 LTO test-suite fails due to missing
definition of
On Mon, Mar 23, 2020 at 11:00:21AM +0100, Martin Liška wrote:
> On 3/23/20 10:43 AM, Jakub Jelinek wrote:
> > On Mon, Mar 23, 2020 at 10:25:32AM +0100, Martin Liška wrote:
> > > Hi.
> > >
> > > As seen in the PR, sparc64 LTO test-suite fails due to missing
> > > definition of __BIG_ENDIAN__
On 3/23/20 10:43 AM, Jakub Jelinek wrote:
On Mon, Mar 23, 2020 at 10:25:32AM +0100, Martin Liška wrote:
Hi.
As seen in the PR, sparc64 LTO test-suite fails due to missing
definition of __BIG_ENDIAN__ macro. That said, I updated the
endianess detection to use __BYTE_ORDER__.
I tested the
Hi,
I created a bug for this issue:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94269
Looks like widening_mul phase may move multiply instruction from outside the
loop to inside the loop, merging with one add instruction inside the loop.
This will increase the cost of the loop at
On Mon, Mar 23, 2020 at 10:25:32AM +0100, Martin Liška wrote:
> Hi.
>
> As seen in the PR, sparc64 LTO test-suite fails due to missing
> definition of __BIG_ENDIAN__ macro. That said, I updated the
> endianess detection to use __BYTE_ORDER__.
>
> I tested the detection on x86_64-linux-gnu,
Hi Nathan:
Tested variadic-sizeof4.C on x86, x86_64 with native compiler
Tested variadic-sizeof4.C on aarch64, arm-eabi, riscv32, riscv64,
mips, mips64 and nds32 with cross compiler.
And tested g++/dg.exp on arm-eabi with this patch, no new fail introduced.
On Mon, Mar 23, 2020 at 2:27 AM Jim
Hi.
As seen in the PR, sparc64 LTO test-suite fails due to missing
definition of __BIG_ENDIAN__ macro. That said, I updated the
endianess detection to use __BYTE_ORDER__.
I tested the detection on x86_64-linux-gnu, ppc64-linux-gnu and
lto.exp testsuite survives on a sparc64-linux machine.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2020-03-23 Richard Biener
PR tree-optimization/94266
* tree-ssa-forwprop.c (pass_forwprop::execute): Do not propagate
addresses of TARGET_MEM_REFs.
---
gcc/tree-ssa-forwprop.c | 1 +
1 file
Another case where build_fold_addr_expr is harmful.
Bootstrap/regtest running on x86_64-unknown-linux-gnu.
2020-03-23 Richard Biener
PR ipa/94245
* ipa-prop.c (ipa_read_jump_function): Build the ADDR_EXRP
directly rather than also folding it via build_fold_addr_expr.
> -Original Message-
> From: Segher Boessenkool [mailto:seg...@kernel.crashing.org]
> Sent: Friday, March 20, 2020 9:38 AM
> To: Yangfei (Felix)
> Cc: gcc-patches@gcc.gnu.org; Zhanghaijian (A)
> Subject: Re: [PATCH PR94026] combine missed opportunity to simplify
> comparisons with zero
>
On Sat, 21 Mar 2020, Tobias Burnus wrote:
> On 3/21/20 8:03 AM, Richard Biener wrote:
>
> >> OK for the trunk?
> > It should be TYPE_ALIGN (type). OK with that change.
>
> I am confused. The patch has:
> + SET_DECL_ALIGN (link_ptr_var, TYPE_ALIGN (ptr_type_node));
> which looks correct
On Sun, Mar 22, 2020 at 11:13 PM qianchao wrote:
>
> Hi
>
> The attached testcase triggers ICE when testing GCC trunk on aarch64 with -S
> -O2 -ftree-loop-vectorize -march=armv8.2-a+sve -msve-vector-bits=256.
>
> Before the forwprop pass, we have two gimple statements as follows:
>
> _43 =
Hi
The attached testcase triggers ICE when testing GCC trunk on aarch64 with -S
-O2 -ftree-loop-vectorize -march=armv8.2-a+sve -msve-vector-bits=256.
Before the forwprop pass, we have two gimple statements as follows:
_43 = [base: _5, offset: 0B];
vect__2.7_24 = MEM [(int *)_43];
The
67 matches
Mail list logo
