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)
>
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},
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
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
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
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:
>
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
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,
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,
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/534330.html
Hello,
This patch supports following MVE ACLE intrinsics with binary operands.
vqmovntq_u16, vqmovnbq_u16, vmulltq_poly_p8, vmullbq_poly_p8,
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
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/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,
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
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,
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,
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
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
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
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
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
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
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:
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
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
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
[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
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
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
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
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
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
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
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
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
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
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
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
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
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 };
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?
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
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.
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
> > >>> @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
> > >
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
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
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
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
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
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
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.
*
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
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
>
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
testl instruction rather than testq and so the SF flag wouldn't
57 matches
Mail list logo
