On Tue, Mar 10, 2020 at 7:39 AM Jakub Jelinek wrote:
>
> Hi!
>
> In r10-1938-g460bf043c8266dd080308f4783137aee0d0f862c *testdi_1 has been
> changed, so that if the mask has upper 32-bits 0 and then at least one bit
> set, it requires CCZmode rather than CCNOmode, because in that case it uses
> tes
On 3/9/20 8:45 PM, Michael Matz wrote:
Hello,
On Mon, 9 Mar 2020, Martin Liška wrote:
On 3/9/20 4:36 PM, H.J. Lu wrote:
We nee to support different variables, like TLS, data and bss variables.
Why do we need TLS? Right now, it's not supported by nm.
Of course it does. It's the 'T' (or 't
The 24_iterators/ostream_iterator/1.cc test uses VERIFY and so is
obviously meant to have been run, not just compiled.
* testsuite/23_containers/unordered_set/allocator/ext_ptr.cc: Add
comment explaining multiple dg-do directives.
* testsuite/24_iterators/ostream_iterator/1
Hi all,
I'd like to submit this patch introducing the following 64bit builtins
variants as FPCR and FPSR registers getter/setter:
unsigned long long __builtin_aarch64_get_fpcr64 ()
void __builtin_aarch64_set_fpcr64 (unsigned long long)
unsigned long long __builtin_aarch64_get_fpsr64 ()
void __bui
Hi all,
second and last patch of the two reworking FPCR and FPSR builtins.
This rework __builtin_aarch64_set_fpcr (unsigned) and
__builtin_aarch64_set_fpsr (unsigned) to emit a read-modify-sequences
as:
mrs x1, fpsr
bfi x1, x0, 0, 32
msr fpsr, x1
This in o
On Thu, Mar 5, 2020 at 10:18 PM Iain Sandoe wrote:
>
> Hello JunMa,
>
> JunMa wrote:
>
> > Ping
>
> Once again, sorry for taking time to review this.
>
> > 在 2020/2/27 上午10:18, JunMa 写道:
> >> 在 2020/2/11 上午10:14, JunMa 写道:
> >> Kindly ping
> >>
> >> Regards
> >> JunMa
> >>> Hi
> >>> In maybe_prom
On 3/9/20 9:19 PM, Jan Hubicka wrote:
On Mon, Mar 9, 2020 at 9:56 AM Martin Liška wrote:
On 3/9/20 4:36 PM, H.J. Lu wrote:
We nee to support different variables, like TLS, data and bss variables.
Why do we need TLS? Right now, it's not supported by nm. Or am I wrong?
Since you are introdu
Hi.
One more that I've just tested.
Martin
>From 40b6c70febc36e523caf9d8615fa4e1e1d68508b Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Mon, 9 Mar 2020 14:13:04 +0100
Subject: [PATCH] Backport 314b91220a07bd63f13c58e37f1b5b9430a3702b
gcc/ChangeLog:
2020-03-09 Martin Liska
PR target/9
On Tue, Mar 10, 2020 at 11:05 AM Martin Liška wrote:
>
> On 3/9/20 9:19 PM, Jan Hubicka wrote:
> >> On Mon, Mar 9, 2020 at 9:56 AM Martin Liška wrote:
> >>>
> >>> On 3/9/20 4:36 PM, H.J. Lu wrote:
> We nee to support different variables, like TLS, data and bss variables.
> >>>
> >>> Why do w
> > >>> @Honza/Richi: Do you have any opinion about that?
> > >
> > > I guess we indeed want to get as close to non-LTO nm behaviour as
> > > possible. So we want to support them and perhaps think of .symtab
> > > section file format that can be made backward compatible (such as having
> > > attrib
On Tue, Mar 10, 2020 at 12:09 PM Jan Hubicka wrote:
>
> > > >>> @Honza/Richi: Do you have any opinion about that?
> > > >
> > > > I guess we indeed want to get as close to non-LTO nm behaviour as
> > > > possible. So we want to support them and perhaps think of .symtab
> > > > section file format
G++ fails to diagnose this non-dependent expression, but Clang doesn't
like it.
PR c++/94117
* include/std/ranges (ranges::transform_view::_Iterator::iter_move):
Change expression in noexcept-specifier to match function body.
Tested x86_64-linux, committed to master.
com
Tamar Christina writes:
> Hi All,
>
> This works around an ICE in reload where from expand we get the following RTL
> generated for VSTRUCT mode writes:
>
> (insn 446 354 445 2 (set (reg:CI 383)
> (subreg:CI (reg:V4SI 291) 0)) "small.i":146:22 3408 {*aarch64_movci}
> (nil))
>
> This sequence is
On 3/10/20 12:24 PM, Richard Biener wrote:
Not sure how symtab is encoded right now but we also could have
Ok, right now I don't see symtab entry much extensible.
But what am I suggesting is to parse LTO bytecode version and then
process conditional parsing of lto_symtab section.
Thoughts?
Ma
On 3/10/20 10:39 AM, Martin Liška wrote:
Are you sure about it?
$ gcc gcc/testsuite/gcc.target/i386/pr56564-3.c -c -fpic && nm pr56564-3.o
...
D s
0010 D t
?
A nicer example:
$ cat tls.c
__thread struct S { long a, b; } s = { 0, 0 };
__thread char t[16] = { 7 };
Hi!
25.02.2020 13:36, Roman Zhuykov wrote:
> So, IMHO the best next step is to improve the behavior rather then docs :)
I want to add one more point into this discussion. I have recently
decided to test some stuff on old branches, e.q gcc-4.9, 5 and 6.
On modern systems there are some issues wi
Hi!
I'd like to ping the
https://gcc.gnu.org/legacy-ml/gcc-patches/2020-03/msg00154.html
P1 PR94015
patch, with the https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94015#c5
testcase instead of the one sent in the patch, so that it FAILs without the
fix on more targets and more reliably.
Thanks
On Thu, Mar 5, 2020 at 3:47 PM Jeff Law wrote:
>
> On Sat, 2020-02-29 at 06:16 -0800, H.J. Lu wrote:
> > On x86, when AVX and AVX512 are enabled, vector move instructions can
> > be encoded with either 2-byte/3-byte VEX (AVX) or 4-byte EVEX (AVX512):
> >
> >0: c5 f9 6f d1 vmovdqa %
This is the second go at this patch, and now with a testcase!
In summary:
If the type is derived in the current compilation unit, and Allocate is not
overridden on derivation (as is typically the case with
Root_Storage_Pool_With_Subpools), the entity for Allocate for the derived
type is then an a
Hi,
This is a fix tring to solve PR94121.
The ICE appears when generating an add insn with the offset. If the offset is
negative, function aarch64_add_offset_1 in aarch64.c will take its absolute
value.
With this fix, offset does not take absolute value if it equals to the minimum
value of mac
Hi,
This is a fix tring to solve PR94121.
The ICE appears when generating an add insn with the offset. If the offset is
negative, function aarch64_add_offset_1 in aarch64.c will take its absolute
value.
With this fix, offset does not take absolute value if it equals to the minimum
value of mac
Hello,
On Tue, 10 Mar 2020, Martin Liška wrote:
> >>> We nee to support different variables, like TLS, data and bss variables.
> >>
> >> Why do we need TLS? Right now, it's not supported by nm.
> >
> > Of course it does. It's the 'T' (or 't') character.
>
> Thank you reply!
>
> Are you sure a
I suspect there'll be a couple more as the tester churns through the targets.
commit aed151bb53b44d523e2732ca6add9324c4ff9798
Author: Jeff Law
Date: Tue Mar 10 08:38:14 2020 -0600
Revert "Fix regression reported by tester due to recent IRA changes"
This reverts commit d48e1175279
On Tue, 10 Mar 2020 at 01:52, Joseph Myers wrote:
>
> On Mon, 9 Mar 2020, Christophe Lyon wrote:
>
> > Hi Joseph,
> >
> > I've noticed that your patch introduces regressions on aarch64:
> > FAIL: gcc.target/aarch64/sve/acle/general-c/sizeless-1.c
> > -march=armv8.2-a+sve (test for errors, line 33
Hi!
Current modulo-sched implementation is a bit faulty from -fcompile-debug
perspective.
I found that few years ago, the most simple example is pr42631.c which fails
(with just -fmodulo-sched or together with -fmodulo-sched-allow-regmoves) on
powerpc64le with at least any gcc-4.9 or newer com
The function needs more than 8 SSE registers, avoid
false positives triggered by SSE spills for 32bit targets.
2020-03-10 Uroš Bizjak
* g++.dg/pr80481.C (dg-final): Scan for SSE reg-reg moves only.
Tested on x86_64-linux-gnu {,-m32}.
Uros.
diff --git a/gcc/testsuite/g++.dg/pr80481.C b/gc
This obvious patch fixes indentation in PR90001-related code.
Committed as r10-7106.
Roman
--
gcc/ChangeLog:
* ddg.c (create_ddg): Fix intendation.
(set_recurrence_length): Likewise.
(create_ddg_all_sccs): Likewise.
diff --git a/gcc/ddg.c b/gcc/ddg.c
index aae92adf89a..ca
[This fixes a bunch of issues found when actually only
wanting to add a check for the following restriction.]
OpenACC's "Declare Directive" has the following restriction:
"A declare directive must be in the same scope
as the declaration of any var that appears in
the data clauses of the direct
This patch marks find_simple_exit function as static.
Committed as r10-7107 after successful bootstrap on x86_64 and powerpc64le.
Roman
--
Function 'find_simple_exit' is used only from loop-iv.c
In 2004-2006 it was also used in predict.c, but since r118694
(992c31e62304ed5d34247dbdef2db276d08fac0
On 2020-02-24, Fangrui Song wrote:
On 2020-02-13, Fangrui Song wrote:
On 2020-02-09, Fangrui Song wrote:
PR driver/93645
* common.opt (-fuse-ld=): Delete -fuse-ld=[bfd|gold|lld]. Add -fuse-ld=.
* opts.c (common_handle_option): Handle OPT_fuse_ld_.
* gcc.c (driver
When using `check-function-bodies`, the subroutine `parse_function_bodies` uses
the `fluff` regexp to remove uninteresting assembly lines.
Arm targets generate assembly with some lines prefixed by `@`, these lines are
left by this process.
As an example of some lines prefixed by `@': the assembly
Cc'ing maintainers and original author of `check-function-bodies`.
It looks like I missed that the first time around.
Forwarded Message
Subject: [testsuite] Add @ lines to check-function-bodies fluff
Date: Tue, 10 Mar 2020 17:22:52 +
From: Matthew Malcomson
To: gcc-patche
On 10/03/20 11:40 +, Jonathan Wakely wrote:
G++ fails to diagnose this non-dependent expression, but Clang doesn't
like it.
PR c++/94117
* include/std/ranges (ranges::transform_view::_Iterator::iter_move):
Change expression in noexcept-specifier to match function body
On 09/03/20 14:17 -0400, Patrick Palka wrote:
... a call to ranges::begin on an input range.
This implements LWG 3286. The new wording for the single-argument
subrange::subrange constructor is implemented by splitting the constructor into
two delegating constructors, one constrained by _S_store
Hi,
I think this commit causes a failure on aarch64-none-elf due to a DejaGnu
typo in gcc.target/aarch64/advsimd-intrinsics/bfcvt-nosimd.c.
{ dg-final { check-function-bodies "**" "" "-O[^0]" } }
I think the square brackets need to be escaped or use {-O[^0]}.
Regards
Vasee
Fri, Mar 06, 2020 at
Hello Kyrill,
This patch addresses all the comments in patch version v2.
(version v2) https://gcc.gnu.org/pipermail/gcc-patches/2020-February/540415.html
Hello,
This patch creates the required framework for MVE ACLE intrinsics.
The following changes are done in this patch to support MVE A
Hello Kyrill,
This patch addresses all the comments in patch version v2.
(version v2) https://gcc.gnu.org/pipermail/gcc-patches/2020-February/540416.html
Hello,
This patch is part of MVE ACLE intrinsics framework.
This patches add support to update (read/write) the APSR (Application Progr
Hello Kyrill,
This patch addresses all the comments in patch version v2.
(version v2) https://gcc.gnu.org/pipermail/gcc-patches/2020-February/540417.html
Hello,
This patch is part of MVE ACLE intrinsics framework.
The patch supports the use of emulation for the single-precision arithmeti
Hello Kyrill,
Following patch is the rebased version of v1.
(version v1) https://gcc.gnu.org/pipermail/gcc-patches/2019-November/534343.html
Hello,
This patch supports MVE ACLE intrinsics vcvtq_f16_s16, vcvtq_f32_s32,
vcvtq_f16_u16, vcvtq_f32_u32n
vrndxq_f16, vrndxq_f32, vrndq_f16, vrndq
Hello Kyrill,
Following patch is the rebased version of v1.
(version v1) https://gcc.gnu.org/pipermail/gcc-patches/2019-November/534328.html
Hello,
This patch supports MVE ACLE intrinsics vst4q_s8, vst4q_s16, vst4q_s32,
vst4q_u8,
vst4q_u16, vst4q_u32, vst4q_f16 and vst4q_f32.
In this pat
Hello Kyrill,
Following patch is the rebased version of v1.
(version v1) https://gcc.gnu.org/pipermail/gcc-patches/2019-November/534331.html
Hello,
This patch supports following MVE ACLE intrinsics with binary operand.
vsubq_n_f16, vsubq_n_f32, vbrsrq_n_f16, vbrsrq_n_f32, vcvtq_n_f16_s16
Hello Kyrill,
Following patch is the rebased version of v1.
(version v1) https://gcc.gnu.org/pipermail/gcc-patches/2019-November/534326.html
Hello,
This patch supports following MVE ACLE intrinsics with unary operand.
vmvnq_n_s16, vmvnq_n_s32, vrev64q_s8, vrev64q_s16, vrev64q_s32, vcvtq_
Hello Kyrill,
Following patch is the rebased version of v1.
(version v1) https://gcc.gnu.org/pipermail/gcc-patches/2019-November/534330.html
Hello,
This patch supports following MVE ACLE intrinsics with binary operands.
vqmovntq_u16, vqmovnbq_u16, vmulltq_poly_p8, vmullbq_poly_p8, vmovnt
Hello Kyrill,
Following patch is the rebased version of v1.
(version v1) https://gcc.gnu.org/pipermail/gcc-patches/2019-November/534342.html
Hello,
This patch supports following MVE ACLE intrinsics with unary operand.
vctp16q, vctp32q, vctp64q, vctp8q, vpnot.
Please refer to M-profile V
Hello Kyrill,
Following patch is the rebased version of v1.
(version v1) https://gcc.gnu.org/pipermail/gcc-patches/2019-November/534329.html
Hello,
This patch supports following MVE ACLE intrinsics with binary operands.
vaddlvq_p_s32, vaddlvq_p_u32, vcmpneq_s8, vcmpneq_s16, vcmpneq_s32,
Hello Kyrill,
Following patch is the rebased version of v1.
(version v1) https://gcc.gnu.org/pipermail/gcc-patches/2019-November/534321.html
Hello,
This patch supports following MVE ACLE intrinsics with unary operand.
vdupq_n_s8, vdupq_n_s16, vdupq_n_s32, vabsq_s8, vabsq_s16, vabsq_s32,
Hello Kyrill,
Following patch is the rebased version of v1.
(version v1) https://gcc.gnu.org/pipermail/gcc-patches/2019-November/534325.html
Hello,
This patch supports following MVE ACLE intrinsics with binary operands.
vcvtq_n_s16_f16, vcvtq_n_s32_f32, vcvtq_n_u16_f16, vcvtq_n_u32_f32,
Hello Kyrill,
Following patch is the rebased version of v1.
(version v1) https://gcc.gnu.org/pipermail/gcc-patches/2019-November/534336.html
Hello,
This patch supports following MVE ACLE intrinsics with binary operands.
vsubq_u8, vsubq_n_u8, vrmulhq_u8, vrhaddq_u8, vqsubq_u8, vqsubq_n_u8
On 3/9/20 4:34 PM, Marek Polacek wrote:
On Mon, Mar 09, 2020 at 04:25:00PM -0400, Marek Polacek wrote:
On Mon, Mar 09, 2020 at 03:37:56PM -0400, Jason Merrill wrote:
On 3/9/20 9:40 AM, Marek Polacek wrote:
On Mon, Mar 09, 2020 at 09:19:30AM -0400, Jason Merrill wrote:
On 3/9/20 8:58 AM, Jakub
On 10/03/20 17:52 +, Jonathan Wakely wrote:
On 10/03/20 11:40 +, Jonathan Wakely wrote:
G++ fails to diagnose this non-dependent expression, but Clang doesn't
like it.
PR c++/94117
* include/std/ranges (ranges::transform_view::_Iterator::iter_move):
Change expres
On Tue, 10 Mar 2020, Christophe Lyon wrote:
> sizeless-1.c and sizeless-2.c have the same code, but the latter is
> compiled with -msve-vector-bits=256 and expects different
> warnings/errors.
> For line 33:
> svint8_t *invalid_sve_sc_ptr = &(svint8_t) { *global_sve_sc_ptr };
> we now have:
> size
This is a bad interaction between sharing a constructor for an array
and stripping its trailing zero-initializers. Here we reuse a ctor
and then strip its 0s. This breaks overload resolution in this test:
D can be initialized from {} but not from {0}, so if we truncate the
constructor not to incl
reshape_init only wants to work on BRACE_ENCLOSED_INITIALIZER_P, i.e. raw
initializer lists, and here was getting a CONSTRUCTOR that had already been
processed for type A. maybe_aggr_guide should also use that test.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog
2020-03-10 Jaso
My change in r10-4394 to only update clones when we actually instantiate a
deferred noexcept-spec broke this because deferred parsing updates the
primary function but not the clones. For GCC 10, let's just revert it.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog
2020-03-10 Jas
On 3/10/20 7:38 PM, Marek Polacek wrote:
This is a bad interaction between sharing a constructor for an array
and stripping its trailing zero-initializers. Here we reuse a ctor
and then strip its 0s. This breaks overload resolution in this test:
D can be initialized from {} but not from {0}, so
The tester started spitting out these errors on bfin recently:
> Tests that now fail, but worked before (3 tests):
>
> bfin-sim: c-c++-common/torture/vector-compare-1.c -Os (test for excess
> errors)
> bfin-sim: c-c++-common/torture/vector-compare-1.c -Os (test for excess
> errors)
> bfin-
Hi,
Gentle ping this patch, also request to backport to gcc9 after some burn-in
time.
BR,
Kewen
on 2020/2/26 下午2:17, Kewen.Lin wrote:
> Hi,
>
> This patch is to apply the same fix as r267528 to another similar case
> bb-slp-over-widen-2.c which requires misaligned vector access.
>
> Verified
On Tue, Mar 10, 2020 at 07:38:17PM -0400, Marek Polacek via Gcc-patches wrote:
> --- a/gcc/cp/decl.c
> +++ b/gcc/cp/decl.c
> @@ -6062,6 +6062,13 @@ reshape_init_array_1 (tree elt_type, tree max_index,
> reshape_iter *d,
>else if (last_nonzero < nelts - 1)
> nelts = last_nonzero + 1;
58 matches
Mail list logo
