The gcc.target/i386 test sse2-mmx-maskmovq.c requires the mmap
feature, but that's not enough for the test to be able to call
sysconf.
I've combined the target triplets used in other sysconf-calling tests,
omitting non-x86 ones, with the preexisting mmap requirement in this
test.
Regstrapped on
On Wed, Mar 24, 2021 at 7:55 AM Alexandre Oliva wrote:
>
>
> Both of these tests fail on platforms that reject -fPIC/-fPIE
> altogether.
>
> Other tests that perform PIE compilation or linking require the pie
> feature, whether for -fpie/-fPIE compilation or for -pie linking.
>
> This patch annota
On Wed, Mar 24, 2021 at 7:51 AM Alexandre Oliva wrote:
>
>
> In -mcmodel=large, callee symbols are pulled ahead of the call insns.
>
> The patterns in funcspec-[12].c tests in gcc.target/i386 match even
> line breaks between 'call' and a function symbol expected to be
> called, however, so it ends
Both of these tests fail on platforms that reject -fPIC/-fPIE
altogether.
Other tests that perform PIE compilation or linking require the pie
feature, whether for -fpie/-fPIE compilation or for -pie linking.
This patch annotates both tests with the required target feature.
Regstrapped on x86_6
On target systems that don't support any random_device, not even the
default one, other random_device constructor tests are disabled by
dg-require-effective-target random_device. The token.cc also
exercises the default constructor, in a way that doesn't expect an
exception to be raised, but it's
On Wed, Mar 24, 2021 at 7:46 AM Alexandre Oliva wrote:
>
> Hello, Jakub,
>
> On Mar 19, 2021, Jakub Jelinek wrote:
>
> > On Fri, Mar 19, 2021 at 07:44:01PM -0300, Alexandre Oliva wrote:
>
> >> However, I had a total of 15 similar fails within gcc.target/i386 in a
> >> gcc-10 tree configured with
In -mcmodel=large, callee symbols are pulled ahead of the call insns.
The patterns in funcspec-[12].c tests in gcc.target/i386 match even
line breaks between 'call' and a function symbol expected to be
called, however, so it ends up unexpectedly matching a previous,
unrelated indirect call, up t
Hello, Jakub,
On Mar 19, 2021, Jakub Jelinek wrote:
> On Fri, Mar 19, 2021 at 07:44:01PM -0300, Alexandre Oliva wrote:
>> However, I had a total of 15 similar fails within gcc.target/i386 in a
>> gcc-10 tree configured with -mcmodel=large
> But then we should add at least one new testcase for
UNSPEC_SI_FROM_SF is not supported for -m32 caused ICE on P8BE-32bit,
since P8 Vector and above doesn't have fast mechanism to move SFmode to
SImode for m32, don't generate IFN VEC_SET for it.
Tested pass on P8BE/LE {m32,m64}.
gcc/ChangeLog:
2021-03-24 Xionghu Luo
* config/rs6000/pre
l2 cache size for Power8 is 512kB, correct the copy paste error from Power7.
Tested no performance change for SPEC2017.
gcc/ChangeLog:
2021-03-24 Xionghu Luo
* config/rs6000/rs6000.c (struct processor_costs): Change to
512.
---
gcc/config/rs6000/rs6000.c | 2 +-
1 file change
---
htdocs/gcc-11/changes.html | 32 +++-
1 file changed, 31 insertions(+), 1 deletion(-)
diff --git a/htdocs/gcc-11/changes.html b/htdocs/gcc-11/changes.html
index 69869309..ec136349 100644
--- a/htdocs/gcc-11/changes.html
+++ b/htdocs/gcc-11/changes.html
@@ -688,7 +6
On Mon, Mar 22, 2021 at 4:10 AM Richard Biener
wrote:
> Oh, and for a type like
>
> struct { struct { struct { ... { double x; } } } } } };
>
> the layout now looks quadratic in work (each field layout will look at
> the nest rooted at it
> up to the bottom). It looks to me as we require(?) the
On Fri, Mar 19, 2021 at 9:22 AM Kito Cheng via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
> On Mon, Mar 15, 2021 at 5:42 AM Marcus Comstedt wrote:
> > I've now delved a bit deeper into the failure of the testcase
> > gcc.c-torture/compile/pr35318.c on big endian RV32.
>
Looking at this testca
On Tue, Mar 23, 2021 at 04:53:54PM -0400, Jason Merrill via Gcc-patches wrote:
> It's simpler to use iloc_sentinel for this.
Indeed, it is.
Here is the new version, bootstrapped on x86_64-linux and i686-linux,
so far regtested on i686-linux, regtest on x86_64 ongoing, ok for trunk
if it passes?
2
Check if host supports multi-byte NOPs before enabling CET on host.
gcc/
PR bootstrap/99703
* configure: Regenerated.
libbacktrace/
PR bootstrap/99703
* configure: Regenerated.
libcc1/
PR bootstrap/99703
* configure: Regenerated.
libcpp/
Check if host supports multi-byte NOPs before enabling CET on host.
config/
PR binutils/27397
* cet.m4 (GCC_CET_HOST_FLAGS): Check if host supports multi-byte
NOPs.
libiberty/
PR binutils/27397
* configure: Regenerated.
---
config/cet.m4 | 19 +
Check if host supports multi-byte NOPs before enabling CET on host.
This fixes:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99703
H.J. Lu (2):
GCC_CET_HOST_FLAGS: Check if host supports multi-byte NOPs
GCC_CET_HOST_FLAGS: Check if host supports multi-byte NOPs
config/cet.m4 | 19 +
On 2021-03-23 5:33 p.m., Richard Sandiford wrote:
Vladimir Makarov writes:
On 2021-03-23 2:24 p.m., Vladimir Makarov wrote:
Here is the patch solving the problem.
Also although asm tests only checks assembler code, a lot of them use
dg-require-effective-target and therefore can not be tes
On Mon, 22 Feb 2021, Patrick McGehearty via Gcc-patches wrote:
> diff --git a/gcc/c-family/c-cppbuiltin.c b/gcc/c-family/c-cppbuiltin.c
> index 9f993c4..7dd319c 100644
> --- a/gcc/c-family/c-cppbuiltin.c
> +++ b/gcc/c-family/c-cppbuiltin.c
> @@ -1026,10 +1026,10 @@ c_cpp_builtins (cpp_reader *pfil
Vladimir Makarov writes:
> On 2021-03-23 2:24 p.m., Vladimir Makarov wrote:
>>
>> On 2021-03-23 1:55 p.m., Christophe Lyon wrote:
>>> On Tue, 23 Mar 2021 at 17:54, Vladimir Makarov
>>> wrote:
Can you check?
Sorry, I've rerun (cd gcc && make check-gcc) on gcc114 for today trun
On 3/8/21 7:34 PM, Marek Polacek wrote:
On Fri, Mar 05, 2021 at 05:03:45PM -0500, Jason Merrill wrote:
On 3/4/21 9:37 PM, Marek Polacek wrote:
This PR complains that we issue a -Wconversion warning in
template struct X {};
template X foo();
saying "conversion from 'long unsigned int
On Tue, Mar 23, 2021 at 04:51:52PM -0400, Jason Merrill wrote:
> > --- gcc/cp/tree.c.jj2021-03-18 09:49:22.112712307 +0100
> > +++ gcc/cp/tree.c 2021-03-23 00:08:35.901724895 +0100
> > @@ -3128,6 +3128,35 @@ bot_manip (tree* tp, int* walk_subtrees,
> > }
> > return NULL_TREE;
On 3/23/21 5:34 AM, Jakub Jelinek wrote:
Hi!
The srcloc19.C testcase shows inconsistency in
std::source_location::current() locations between calls from
templates and non-templates. The location used by __builtin_source_location
comes in both cases from input_location which is set on it by bot_
On 3/23/21 5:57 AM, Jakub Jelinek wrote:
Hi!
When adding P0784R7 constexpr new support, we still didn't have
P1331R2 implemented and so I had to change also build_vec_delete_1
- instead of having uninitialized tbase temporary later initialized
by MODIFY_EXPR I've set the DECL_INITIAL for it - be
On 2021-03-23 2:24 p.m., Vladimir Makarov wrote:
On 2021-03-23 1:55 p.m., Christophe Lyon wrote:
On Tue, 23 Mar 2021 at 17:54, Vladimir Makarov
wrote:
Can you check?
Sorry, I've rerun (cd gcc && make check-gcc) on gcc114 for today trunk
and I don't see the regressions mentioned above.
Can
Hi
I modified the diagnostic message to avoid a build-time warning
omitting a colon intentionally; since that has produced a translation
comment, this adds the colon back.
tested with a build of host-darwin (produces no build-time diagnostic).
pushed to master,
thanks
Iain
Add a ':' to ma
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Finnish team of translators. The file is available at:
https://translationproject.org/latest/gcc/fi.po
(This file, 'gcc-11.1-b20210321.fi.po'
I ran into this reducing 99283, we were failing to mark binding vectors
when the current TU declares a duplicate decl (as opposed to an import
introduces a duplicate).
PR c++/99283
gcc/cp/
* name-lookup.c (check_module_override): Set global or partition
DUP on
ping
Any hope for getting this in? We really need this support.
Thanks!
> On 3/12/21 6:39 PM, Martin Liška wrote:
> PING^2
>
> On 3/1/21 1:07 PM, Martin Liška wrote:
>> PING
>> On 2/18/21 10:18 AM, Martin Liška wrote:
>>> On 2/16/21 10:17 PM, Qing Zhao wrote:
Hello,
What’s the
From: Thomas Rodgers
* This patch addresses jwakely's previous feedback.
* This patch also subsumes thiago.macie...@intel.com 's 'Uncontroversial
improvements to C++20 wait-related implementation'.
* This patch also changes the atomic semaphore implementation to avoid
checking for any waiters
On Tue, 2021-03-23 at 12:48 +, Richard Sandiford wrote:
> Ilya Leoshkevich writes:
> > +inline use_info *
> > +set_info::single_nondebug_use () const
> > +{
> > + use_info *nondebug_insn = single_nondebug_insn_use ();
> > + if (nondebug_insn)
> > + return has_phi_uses () ? nullptr : nonde
On 23/03/21 18:45 +0100, Moritz Sichert via Libstdc++ wrote:
Thank you!
You are right. The idea was that the test also tests the const overloads of
begin() and end() of reverse_view. But the view concept requires movable.
Maybe, this should just be
static_assert(std::ranges::range);
instead?
On 2021-03-23 1:55 p.m., Christophe Lyon wrote:
On Tue, 23 Mar 2021 at 17:54, Vladimir Makarov wrote:
Can you check?
Sorry, I've rerun (cd gcc && make check-gcc) on gcc114 for today trunk
and I don't see the regressions mentioned above.
Can you check this too and if I am doing something wr
On Tue, 23 Mar 2021 at 17:54, Vladimir Makarov wrote:
>
>
> On 2021-03-23 9:07 a.m., Christophe Lyon wrote:
> > On Mon, 22 Mar 2021 at 18:38, Vladimir Makarov via Gcc-patches
> > wrote:
> >>
> > Hi,
> >
> > This patch causes regressions (116) on aarch64:
> > gcc.target/aarch64/sve/acle/aarch64-sv
Hi Paul,
On 23.03.21 18:34, Paul Richard Thomas wrote:
I took something of a detour in reviewing this patch. Although short,
understanding it is not straightforward!
I concur – and as I wrote both in the patch email and in the PR, it is
not straight forward which message is showing with which
Thank you!
You are right. The idea was that the test also tests the const overloads of
begin() and end() of reverse_view. But the view concept requires movable.
Maybe, this should just be
static_assert(std::ranges::range);
instead?
The test in the patch now has the same static_assert twice.
Cancel the thought on my patchlet null_5.f90 fails on excess errors.
Paul
On Tue, 23 Mar 2021 at 17:34, Paul Richard Thomas <
paul.richard.tho...@gmail.com> wrote:
> Hi Tobias,
>
> I took something of a detour in reviewing this patch. Although short,
> understanding it is not straightforward!
>
Hi Tobias,
I took something of a detour in reviewing this patch. Although short,
understanding it is not straightforward!
Your patch works as advertised and regtests OK (with the patch for PR93660
on board as well). Is NULL the only case where this can happen?
Just to aid my understanding, I trie
On Thu, Mar 18, 2021 at 05:13:38PM +0100, Jakub Jelinek wrote:
> On Thu, Mar 18, 2021 at 09:27:17AM +0800, Xionghu Luo via Gcc-patches wrote:
> > gcc/ChangeLog:
> >
> > 2021-03-18 Xionghu Luo
> >
> > PR target/98914
> > * config/rs6000/rs6000.c (rs6000_expand_vector_set_var_p9):
> >
On 23/03/21 16:25 +, Jonathan Wakely wrote:
On 03/03/21 20:26 +0100, Moritz Sichert via Libstdc++ wrote:
Thanks for the review. I attached the updated patch.
Can you commit this for me or point me to what I should do next? This is my
first contribution here.
I was about to do this, but .
On 2021-03-23 9:07 a.m., Christophe Lyon wrote:
On Mon, 22 Mar 2021 at 18:38, Vladimir Makarov via Gcc-patches
wrote:
Hi,
This patch causes regressions (116) on aarch64:
gcc.target/aarch64/sve/acle/aarch64-sve-acle-asm.exp
gcc.target/aarch64/sve/acle/asm/ld1ro_bf16.c -std=gnu90 -O2
-
Hi!
On Wed, Mar 17, 2021 at 03:49:09PM -0500, Pat Haugen wrote:
> This patch creates a new attribute, prepend_prefixed_insn, which is used to
> mark
> those instructions that are prefixed and need to have a 'p' prepended to their
> mnemonic at asm emit time. The existing "prefix" attribute is now
On 23/03/21 09:26 -0700, Thiago Macieira via Libstdc++ wrote:
On Tuesday, 23 March 2021 08:39:43 PDT Thomas Rodgers wrote:
I will be submitting a new patch for the
atomic.wait/barrier/latch/semaphore functionality a bit later today that
subsumes the changes to atomic_wait and latch, and includes
GCC at the moment uses COMDAT groups for things like virtual thunks,
even on targets that do not support COMDAT groups. This has not been a
problem as on platforms not supporting these (such as PE COFF on
Windows), the backend handled it through directives to GAS. GCC would
simply use a .linkonce d
On Tuesday, 23 March 2021 08:39:43 PDT Thomas Rodgers wrote:
> I will be submitting a new patch for the
> atomic.wait/barrier/latch/semaphore functionality a bit later today that
> subsumes the changes to atomic_wait and latch, and includes the changes
> to barrier.
Thanks, Thomas
Is that meant t
On 03/03/21 20:26 +0100, Moritz Sichert via Libstdc++ wrote:
Thanks for the review. I attached the updated patch.
Can you commit this for me or point me to what I should do next? This is my
first contribution here.
I was about to do this, but ...
+namespace test_ns
+{
+ struct A {};
+ tem
On 20/03/21 22:32 +0100, François Dumont wrote:
Following your feedback here is the simplified version. I grouped it
with the patch I submitted before.
On 19/03/21 8:41 pm, Jonathan Wakely wrote:
On 16/03/21 21:55 +0100, François Dumont via Libstdc++ wrote:
Following:
https://gcc.gnu.org/pi
On 2021-03-22 08:29, Thiago Macieira via Libstdc++ wrote:
Discussion at:
https://gcc.gnu.org/pipermail/libstdc++/2021-February/052043.html
This patch set includes the uncontroversial parts that improve
performance but don't otherwise change ABI.
Please note we still need to decide on how to de
On Tue, 23 Mar 2021 at 15:59, Kyrylo Tkachov wrote:
>
>
>
> > -Original Message-
> > From: Gcc-patches On Behalf Of
> > Christophe Lyon via Gcc-patches
> > Sent: 23 March 2021 14:33
> > To: gcc-patches@gcc.gnu.org
> > Subject: [PATCH 8/8] testsuite/arm: Add arm_dsp_ok effective target and
On Tue, Mar 23, 2021 at 09:05:42AM -0400, Jason Merrill via Gcc-patches wrote:
> On 3/9/21 10:22 PM, Marek Polacek wrote:
> > In GCC 10, I introduced cp_warn_deprecated_use_scopes so that we can
> > handle attribute deprecated on a namespace declaration. This
> > function walks the decl's contexts
Clang does not currently support the __ibm128 type [1] and only supports
the __ieee128 type in the unreleased 12.0.0 version [2]. That means it
is not possible to provide support for -mabi=ieeelongdouble with Clang
in an ABI compatible way (as we do for GCC by defining new facets and
other types in
> -Original Message-
> From: Gcc-patches On Behalf Of
> Christophe Lyon via Gcc-patches
> Sent: 23 March 2021 14:33
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH 8/8] testsuite/arm: Add arm_dsp_ok effective target and
> use it in arm/acle/dsp_arith.c
>
> gcc.target/arm/acle/dsp_arith
> -Original Message-
> From: Gcc-patches On Behalf Of
> Christophe Lyon via Gcc-patches
> Sent: 23 March 2021 14:33
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH 7/8] testsuite/arm: Fix -mfloat-abi order in
> arm_v8_1m_mve_ok_nocache and arm_v8_1m_mve_fp_ok_nocache
>
> Make the order
> -Original Message-
> From: Gcc-patches On Behalf Of
> Christophe Lyon via Gcc-patches
> Sent: 23 March 2021 14:33
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH 6/8] testsuite/arm: Fix -mfloat-abi order in
> arm_v8_2a_bf16_neon_ok_nocache and arm_v8_2a_i8mm_ok_nocache
>
> Make the o
> -Original Message-
> From: Gcc-patches On Behalf Of
> Christophe Lyon via Gcc-patches
> Sent: 23 March 2021 14:33
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH 5/8] testsuite/arm: Add arm_hard_ok check in armv8_2-
> fp16-scalar-2.c
>
> This test relies on -mfloat-abi=hard to pass (
> -Original Message-
> From: Gcc-patches On Behalf Of
> Christophe Lyon via Gcc-patches
> Sent: 23 March 2021 14:33
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH 4/8] testsuite/arm: Add arm_softfp_ok or arm_hard_ok as
> needed.
>
> Several tests override the -mfloat-abi option detect
> -Original Message-
> From: Gcc-patches On Behalf Of
> Christophe Lyon via Gcc-patches
> Sent: 23 March 2021 14:33
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH 3/8] testsuite/arm: Remove useless -mfloat-abi option
>
> These tests pass with their current dg-add-options, no need to f
> -Original Message-
> From: Gcc-patches On Behalf Of
> Christophe Lyon via Gcc-patches
> Sent: 23 March 2021 14:33
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH 2/8] testsuite/arm: Add arm_v8_2a_i8mm options in
> gcc.target/arm/simd/vmmla_1.c
>
> We need to add the options correspon
> -Original Message-
> From: Gcc-patches On Behalf Of
> Christophe Lyon via Gcc-patches
> Sent: 23 March 2021 14:33
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH 1/8] testsuite/arm: Add arm_v8_2a_fp16_neon and
> arm_v8_2a_bf16_neon options
>
> A few tests lack the dg-add-options dire
Hi
I expect this to be my last (substantial) regression fix for GCC-11.
Although this is a Darwin patch, I’d welcome any comments - if none appear
then I plan to apply the patch later in the week.
tested on Darwin8 .20, x86_64-linux-gnu and powerpc-linux-gnu.
thanks
Iain
==
This address
Hi Tobias,
The patch looks fine to me. OK for 10- and 11-branches. I am not convinced
that a delay is needed for the backport.
Thanks
Paul
On Thu, 11 Mar 2021 at 18:19, Tobias Burnus wrote:
> This fixes an ICE with OpenMP 'omp decare simd' but is a generic bug.
>
> Namely TREE_TYPE(fndecl) h
gcc.target/arm/acle/dsp_arith.c uses DSP intrinsics, which arm_acle.h
defines only with __ARM_FEATURE_DSP, so make the test check for that
property rather than arm_qbit_ok.
However, the existing arm_dsp effective target only checks if DSP
features are supported with the current multilib rather tha
Make the order in which we try -mfloat-abi options consistent with the
other similar effective targets: try softfp first, then hard.
This shows that a few tests implicitly rely on -mfloat-abi=hard, so we
add this option via dg-additional-options so that it comes after any
potential -mfloat-abi opt
Make the order in which we try -mfloat-abi options consistent with the
other similar effective targets: try softfp first, then hard.
This shows that a few tests implicitly rely on -mfloat-abi=hard, so we
now check arm_hard_ok where needed.
This makes these tests unsupported rather than fail on
ar
This test relies on -mfloat-abi=hard to pass (otherwise
test_mov_imm_[12] directly build the 1.0 fp16 representation via movw
r0, #15360 rather than using vmov.f16 s0, #1.0e+0 as expected by
scan-assembler-times)
Adding the arm_hard_ok check makes the test unsupported eg. on
arm-linux-gnueabi inst
Several tests override the -mfloat-abi option detected by their
effective targets. Make sure it is supported, so that these tests are
unsupported rather than failures (the inclusion of arm_neon.h
otherwise fails for lack of gnu/stubs-*.h)
This avoids failures with
bfloat16_simd_2_1.c
bfloat16_simd
These tests pass with their current dg-add-options, no need to force
-mfloat=abi.
I've noticed no impact on armv8_1m-shift-imm-1.c and
armv8_1m-shift-reg-1.c, bf16_reinterpret.c now passes on
arm-linux-gnueabi and bf16_dup.c now passes on arm-linux-gnueabihf.
This allows pr51534.c to pass when fo
We need to add the options corresponding to the arm_v8_2a_i8mm_ok
effective target in order to use the right float-abi option:
-mfloat-abi=softfp makes the test pass for arm-linux-gnueabi,
while no -mfloat-abi option is needed for arm-linux-gnueabihf.
2021-03-19 Christophe Lyon
gcc/tes
A few tests lack the dg-add-options directives associated with the
dg-require-effective-target they are using. Adding them enables to
pass the right float-abi option, and thus make the tests pass instead
of emit an error.
For instance, we now pass -mfloat-abi=softfp on arm-linux-gnueabi
targets an
Several arm tests fail in various testing configurations due to
incomplete or incorrect effective-target or
dg-options/dg-additional-options settings.
This series improves this, to avoid repeated reports with lots of
useless errors. Hopefully this will help focus on real compiler bugs.
There's st
Hi Gerald,
> -Original Message-
> From: Gerald Pfeifer
> Sent: 20 March 2021 16:31
> To: Kyrylo Tkachov
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [wwwdocs] arm,aarc64: add initial gcc-11/changes.html entries
>
> Hi Kyrylo,
>
> On Tue, 26 Jan 2021, Kyrylo Tkachov via Gcc-patches wrot
Hi all,
I'd like to record the fix for the RNG intrinsics fix in the 10.3 release notes.
The GCC 10 branch is the only released branch that was affected by the bug.
Pushing to wwwdocs.
Thanks,
Kyrill
wwwdocs-rng.patch
Description: wwwdocs-rng.patch
aarch64_add_offset uses expand_mult to multiply the SVE VL by an
out-of-range constant. expand_mult takes an argument to indicate
whether the multiplication is signed or unsigned, but in this
context the multiplication is effectively signless and so the
choice seemed arbitrary.
However, one of th
On Mon, 22 Mar 2021 at 18:38, Vladimir Makarov via Gcc-patches
wrote:
>
>
> On 2021-03-21 8:51 a.m., Richard Sandiford wrote:
> > Vladimir Makarov writes:
> >> On 2021-03-19 11:42 a.m., Richard Sandiford wrote:
> >>> Vladimir Makarov via Gcc-patches writes:
> The following patch solves P1 P
On 3/9/21 10:22 PM, Marek Polacek wrote:
In GCC 10, I introduced cp_warn_deprecated_use_scopes so that we can
handle attribute deprecated on a namespace declaration. This
function walks the decl's contexts so that we warn for code like
namespace [[deprecated]] N { struct S { }; }
N::S s;
Ilya Leoshkevich writes:
> +inline use_info *
> +set_info::single_nondebug_use () const
> +{
> + use_info *nondebug_insn = single_nondebug_insn_use ();
> + if (nondebug_insn)
> +return has_phi_uses () ? nullptr : nondebug_insn;
> + use_info *phi = single_phi_use ();
> + if (phi)
> +ret
This was simply an overzealous assert. Possibly correct thinking at the
time that code was written, but not true now. Of course we can have
imported artificial decls.
PR c++/99239
gcc/cp/
* decl.c (duplicate_decls): Remove assert about maybe-imported
artificia
[AMD Public Use]
Hi Honza,
> -Original Message-
> From: Jan Hubicka
> Sent: Monday, March 22, 2021 4:31 PM
> To: Kumar, Venkataramanan
> Cc: gcc-patches@gcc.gnu.org; mjam...@suse.cz
> Subject: Re: znver3 tuning part 1
>
> [CAUTION: External Email]
>
> > > Hi,
> > > I plan to commit s
On 09/03/2021 15:41, Alex Coplan via Gcc-patches wrote:
> Hi all,
>
> Here is a v2 patch which provides a more obviously fake answer to
> TARGET_BUILTIN_DECL: this can hopefully go in for GCC 11. For GCC 12, it
> seems that we should consider removing the target hook.
>
> Original patch:
> https:
Hi,
this is a regression present on the mainline, 10 and 9 branches introduced by
a preparation patch for modules applied to libcpp a while ago by Nathan:
2018-10-31 Nathan Sidwell
* include/line-map.h (IS_ORDINARY_LOC, IS_MACRO_LOC): New
predicates.
(IS_ADHOC_LOC): M
Hello, gentle maintainer.
This is a message from the Translation Project robot. (If you have
any questions, send them to .)
A new POT file for textual domain 'gcc' has been made available
to the language teams for translation. It is archived as:
https://translationproject.org/POT-files/gcc
Since they are already skipped on other 32-bit architectures.
Tested on x86-64/Linux and SPARC/Solaris, OK for the mainline?
2021-03-23 Eric Botcazou
* go.test/test/fixedbugs/issue6036.go: Skip on sparc.
* go.test/test/fixedbugs/issue22200b.go: Likewise.
--
Eric Botcazoudif
Hi!
When adding P0784R7 constexpr new support, we still didn't have
P1331R2 implemented and so I had to change also build_vec_delete_1
- instead of having uninitialized tbase temporary later initialized
by MODIFY_EXPR I've set the DECL_INITIAL for it - because otherwise
it would be rejected during
This makes sure we'll not run into SLP scheduling issues later by
rejecting all-constant children nodes without any scalar stmts early.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
2021-03-23 Richard Biener
PR tree-optimization/99721
* tree-vect-slp.c (vect_slp
On Mon, Mar 22, 2021 at 5:19 AM H.J. Lu wrote:
>
> Tested on Linux/x86-64 and Linux/i686. OK for master and release
> branches?
>
> Thanks.
>
> H.J.
> ---
> Since CPUID instruction may return different values on hybrid core.
> volatile is needed on asm statements in .
>
> PR target/99704
Hi!
The srcloc19.C testcase shows inconsistency in
std::source_location::current() locations between calls from
templates and non-templates. The location used by __builtin_source_location
comes in both cases from input_location which is set on it by bot_manip
when handling the default argument, c
Hi Marcus:
Verified with spike for rv32be and rv64be.
Committed to trunk, appreciate your work on this, RISC-V big-endian
support just reached a great milestone today!
On Sat, Mar 20, 2021 at 3:50 AM Marcus Comstedt wrote:
>
> New update of the RISC-V big endian support.
>
> Changes since v3:
>
For details, see PR.
If I have not miscounted, the failing message has
32 characters + three names → (3*62 + 1 + 32) = 219 > 200.
I add another 18 characters for longer translation strings.
If that is not enough, there will be truncation but
no buffer overflow thanks to snprintf.
OK for mainline
On Tue, 23 Mar 2021, Xionghu Luo wrote:
>
>
> On 2020/12/23 00:53, Richard Biener wrote:
> > On December 21, 2020 10:03:43 AM GMT+01:00, Xiong Hu Luo
> > wrote:
> >> Here comes another case that requires run a pass once more, as this is
> >> not the common suggested direction to solve problems,
On Tue, Mar 23, 2021 at 8:55 AM bin.cheng wrote:
>
> > > In the patch, I just duplicated and created new function
> > > loop_first_rev_post_order_compute_fn.
> > > I am not sure if I should change the original function
> > > pre_and_rev_post_order_compute_fn
> > > (maybe not at this stage)? I am
On Tue, Mar 23, 2021 at 3:41 AM Hongyu Wang wrote:
>
> > Hongyue, please collect code size differences on SPEC CPU 2017 and
> > eembc.
>
> Here is code size difference for this patch
Thanks, nothing too bad although slightly larger impacts than envisioned.
> SPEC CPU 2017
>
Hi Tom!
Ping, one item specifically: "backporting [...] to release branches" (see
below) -- this ping is dedicated to the upcoming GCC 10.3 release. ;-)
On 2021-01-13T12:59:14+0100, I wrote:
> On 2020-10-09T13:56:09+0200, Tom de Vries wrote:
>> The nvptx-as assembler verifies the ptx code using
thoughts are appreciated.
Maybe another more straightforward or easier to understand function name?
Thanks,
bin
>
> Thanks,
> Richard.
>
pr98736-20210323.txt
Description: Binary data
This fixed what I broke in g:c38f679eebffd601d977330f24def69f4b620c93.
Thanks,
Martin
contrib/ChangeLog:
* mklog.py: Fix broken tests.
---
contrib/mklog.py | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/contrib/mklog.py b/contrib/mklog.py
index 00a001ec5ae.
94 matches
Mail list logo
