On 5/19/2021 3:01 PM, Martin Sebor via Gcc-patches wrote:
The front end -Wnonnull handler has code to suppress warning for
lambdas with null this pointers but the middle end handler has
no corresponding logic. This leads to spurious -Wnonnull in
lambda calls that aren't inlined. That might
Hello,
can I ask somebody to push the patch to fix the PCH large file problem
(BUG 14940)? The bug fix was sent in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14940#c49
and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14940#c50
I would copy and paste it, but I'm not the author of this patch.
We were crashing because invalid_nontype_parm_type_p allowed _Complex
template parms, but convert_nontype_argument didn't know what to do for
them. Let's just disallow it, people can and should use std::complex
instead.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/100634
Here the code for 'using enum' is confused by the combination of a
using-decl and an enum that are not from 'using enum'; this CONST_DECL is
from the normal unscoped enum scoping.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/100659
gcc/cp/ChangeLog:
* cp-tree.h
Hello.
This patch adds support to set the link section of global variables.
I used the ABI 18 because I submitted other patches up to 17.
Thanks for the review.
From c867732ee36003759d479497c85135ecfc4a0cf3 Mon Sep 17 00:00:00 2001
From: Antoni Boucher
Date: Wed, 12 May 2021 07:57:54 -0400
On Linux/x86_64,
cd67343703ef4fa61de837f4690eba70d2760825 is the first bad commit
commit cd67343703ef4fa61de837f4690eba70d2760825
Author: Jason Merrill
Date: Tue May 18 12:29:33 2021 -0400
c++: ICE with <=> fallback [PR100367]
caused
FAIL: g++.dg/opt/pr94589-2.C -std=gnu++2a
Hi!
On Wed, May 19, 2021 at 08:35:26PM +0200, Tobias Burnus wrote:
> On 19.05.21 17:15, Segher Boessenkool wrote:
> >>real(16) :: y ! 128bit REAL
> >>integer(16), parameter :: k2 = nint (2 / epsilon (y), kind(k2))
> >>integer(16), parameter :: m2 =
Hi!
On Mon, Apr 26, 2021 at 02:00:36PM -0500, acsaw...@linux.ibm.com wrote:
> This adds some test cases to make sure that the combine patterns for p10
> fusion are working.
> +++ b/gcc/testsuite/gcc.target/powerpc/fusion-p10-2logical.c
> @@ -0,0 +1,205 @@
> +/* { dg-do compile { target {
On 19/05/21 11:51 -0600, Martin Sebor wrote:
On 5/19/21 10:39 AM, Jonathan Wakely via Gcc-patches wrote:
Jakub pointed out I'd forgotten the spaces before the opening parens
for function calls. The attached patch should fix all those, with no
other changes.
Tested x86_64-linux. OK for trunk?
On 19/05/21 11:51 -0600, Martin Sebor wrote:
On 5/19/21 10:39 AM, Jonathan Wakely via Gcc-patches wrote:
Jakub pointed out I'd forgotten the spaces before the opening parens
for function calls. The attached patch should fix all those, with no
other changes.
Tested x86_64-linux. OK for trunk?
On 19/05/21 16:08 -0400, Jason Merrill wrote:
On 5/19/21 4:05 PM, Jonathan Wakely wrote:
On 19/05/21 20:55 +0100, Jonathan Wakely wrote:
On 19/05/21 13:26 -0400, Jason Merrill wrote:
On 5/19/21 12:46 PM, Jonathan Wakely wrote:
On 19/05/21 17:39 +0100, Jonathan Wakely wrote:
Jakub pointed
This patch reworks indirect struct handling in gimplify.c (i.e. for
struct components mapped with "mystruct->a[0:n]", "mystruct->b", etc.),
for OpenACC. The key observation leading to these changes was that
component mappings of references-to-structures is already implemented
and working, and
This patch is a second attempt at refactoring struct component mapping
handling for OpenACC/OpenMP during gimplification, after the patch I
posted here:
https://gcc.gnu.org/pipermail/gcc-patches/2018-November/510503.html
And improved here, post-review:
For historical reasons, it seems that extract_base_bit_offset
unnecessarily used two different ways to strip ARRAY_REF/INDIRECT_REF
nodes from component accesses. I verified that the two ways of performing
the operation gave the same results across the whole testsuite (and
several additional
It never makes sense for a GOMP_MAP_ATTACH_DETACH mapping to survive
beyond gimplify.c, so this patch rewrites such mappings to GOMP_MAP_ATTACH
or GOMP_MAP_DETACH unconditionally (rather than checking for a list
of types of OpenACC or OpenMP constructs), in cases where it hasn't
otherwise been
This is a new series of patches for the og10 branch to rework how indirect
struct components are handled for offloaded OpenACC code regions. Compared
to the version posted previously here:
https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570058.html
...the patches have been rebased to the
On Mon, Apr 26, 2021 at 03:21:30PM -0500, acsaw...@linux.ibm.com wrote:
> This patch modifies the function in genfusion.pl for generating
> the logical-logical patterns so that it can also generate the
> add-logical and logical-add patterns which are very similar.
> + $outer_32 =
On 5/3/21 8:53 AM, Robin Dapp via Gcc-patches wrote:
Hi,
on s390 a warning test fails:
inline int ATTR ((cold, aligned (8)))
finline_hot_noret_align (int);
inline int ATTR ((warn_unused_result))
finline_hot_noret_align (int);
inline int ATTR ((aligned (4)))
finline_hot_noret_align (int);
On Wed, 19 May 2021, Martin Sebor via Gcc-patches wrote:
> The GCC 11 -Warray-parameter and -Wvla-parameter enhancement uses
> a small local buffer to format the description of the VLA bounds
> for the internal attribute access. When the number of bounds is
> in excess of the size of the buffer
On Wed, 19 May 2021, Christophe Lyon via Gcc-patches wrote:
> On Wed, 19 May 2021 at 16:50, Joseph Myers wrote:
> >
> > This patch is missing documentation (in cpp.texi) and tests for the value
> > of the macro.
> >
>
> Indeed. How about this new version?
This version is OK.
--
Joseph S.
We set default for some target options in TARGET_OPTION_OPTIMIZATION_TABLE,
but these can be overridden by specifying the corresponding explicit
-mXXX / -mno-XXX options.
When a function bears the attribue
__attribute__ ((optimize("02")))
the target options are set to the default for that
On 19.05.21 22:39, Bernhard Reutner-Fischer wrote:
On Wed, 19 May 2021 20:35:26 +0200
Tobias Burnus wrote:
As I like that patch and believe it is obvious, I intent to
/intent/s/tent/tend/
?
No real comment except that it sounds odd to arrive at 53 instead of
the quad bits precision on an
On Mon, Apr 26, 2021 at 03:21:29PM -0500, acsaw...@linux.ibm.com wrote:
> This patch adds a function to genfusion.pl to add a couple
> more patterns so combine can do fusion of pairs of add and
> vaddudm instructions.
> +sub gen_addadd
> +{
> +my ($kind, $vchr, $op, $ty, $mode, $pred,
On Wed, 19 May 2021 22:39:13 +0200
Bernhard Reutner-Fischer wrote:
> On Wed, 19 May 2021 20:35:26 +0200
> Tobias Burnus wrote:
> > commit it as such – unless there are further comments.
>
> No real comment except ..
why don't we end up with IEEE binary128 quadruple precision here per
The front end -Wnonnull handler has code to suppress warning for
lambdas with null this pointers but the middle end handler has
no corresponding logic. This leads to spurious -Wnonnull in
lambda calls that aren't inlined. That might happen at low
optimization levels such as -O1 or -Og and with
The GCC 11 -Warray-parameter and -Wvla-parameter enhancement uses
a small local buffer to format the description of the VLA bounds
for the internal attribute access. When the number of bounds is
in excess of the size of the buffer the code asserts as the test
case in pr100619 shows. The
On Wed, 19 May 2021 20:35:26 +0200
Tobias Burnus wrote:
> Hi Segher,
>
> Quick version: Jump to the new patch, which I like much more.
> Namely, as the attached updated patch does.
>
> As I like that patch and believe it is obvious, I intent to
/intent/s/tent/tend/
> commit it as such –
On Wed, 19 May 2021 at 16:50, Joseph Myers wrote:
>
> This patch is missing documentation (in cpp.texi) and tests for the value
> of the macro.
>
Indeed. How about this new version?
Thanks
Christophe
> --
> Joseph S. Myers
> jos...@codesourcery.com
commit
When ranger was first written, it processed all the range-ops
statements, and the remainder of the statements we slowly added, and
shared as much code with vr_values as we could.
We are now at a point where it makes sense to split this out into its
own class. There are a number of places
Hi!
On Mon, Apr 26, 2021 at 01:04:56PM -0500, acsaw...@linux.ibm.com wrote:
> This adds new values for insn attr type for p10 fusion. The genfusion.pl
> script is modified to use them, and fusion.md regenerated to capture
> the new patterns. There are also some formatting only changes to
>
On 5/19/21 4:05 PM, Jonathan Wakely wrote:
On 19/05/21 20:55 +0100, Jonathan Wakely wrote:
On 19/05/21 13:26 -0400, Jason Merrill wrote:
On 5/19/21 12:46 PM, Jonathan Wakely wrote:
On 19/05/21 17:39 +0100, Jonathan Wakely wrote:
Jakub pointed out I'd forgotten the spaces before the opening
On 5/19/21 3:55 PM, Jonathan Wakely wrote:
On 19/05/21 13:26 -0400, Jason Merrill wrote:
On 5/19/21 12:46 PM, Jonathan Wakely wrote:
On 19/05/21 17:39 +0100, Jonathan Wakely wrote:
Jakub pointed out I'd forgotten the spaces before the opening parens
for function calls. The attached patch
On 19/05/21 20:55 +0100, Jonathan Wakely wrote:
On 19/05/21 13:26 -0400, Jason Merrill wrote:
On 5/19/21 12:46 PM, Jonathan Wakely wrote:
On 19/05/21 17:39 +0100, Jonathan Wakely wrote:
Jakub pointed out I'd forgotten the spaces before the opening parens
for function calls. The attached patch
On 19/05/21 13:26 -0400, Jason Merrill wrote:
On 5/19/21 12:46 PM, Jonathan Wakely wrote:
On 19/05/21 17:39 +0100, Jonathan Wakely wrote:
Jakub pointed out I'd forgotten the spaces before the opening parens
for function calls. The attached patch should fix all those, with no
other changes.
On Wed, May 19, 2021 at 6:27 AM Bernd Edlinger
wrote:
>
> On 5/19/21 3:22 PM, H.J. Lu wrote:
> > On Wed, May 19, 2021 at 2:33 AM Richard Biener
> > wrote:
> >>
> >> On Tue, May 18, 2021 at 9:16 PM H.J. Lu wrote:
> >>>
> >>> When expanding a constant constructor, don't call expand_constructor if
On Wed, May 19, 2021 at 07:35:20PM +0100, Jonathan Wakely wrote:
> On 19/05/21 14:03 -0400, Marek Polacek wrote:
> > On Wed, May 19, 2021 at 11:51:54AM -0600, Martin Sebor via Gcc-patches
> > wrote:
> > > On 5/19/21 10:39 AM, Jonathan Wakely via Gcc-patches wrote:
> > > > Jakub pointed out I'd
On 19/05/21 14:03 -0400, Marek Polacek wrote:
On Wed, May 19, 2021 at 11:51:54AM -0600, Martin Sebor via Gcc-patches wrote:
On 5/19/21 10:39 AM, Jonathan Wakely via Gcc-patches wrote:
> Jakub pointed out I'd forgotten the spaces before the opening parens
> for function calls. The attached patch
Hi Segher,
Quick version: Jump to the new patch, which I like much more.
Longer version:
On 19.05.21 17:15, Segher Boessenkool wrote:
real(16) :: y ! 128bit REAL
integer(16), parameter :: k2 = nint (2 / epsilon (y), kind(k2))
integer(16), parameter :: m2 =
Hi All!
And yes I forgot the patch...
Sorry...
Best regards,
José Rui
On 19/05/21 17:09, José Rui Faustino de Sousa wrote:
Hi all!
Proposed patch to:
PR100683 - Array initialization refuses valid
Patch tested only on x86_64-pc-linux-gnu.
Add call to simplify expression before parsing.
On Wed, May 19, 2021 at 11:51:54AM -0600, Martin Sebor via Gcc-patches wrote:
> On 5/19/21 10:39 AM, Jonathan Wakely via Gcc-patches wrote:
> > Jakub pointed out I'd forgotten the spaces before the opening parens
> > for function calls. The attached patch should fix all those, with no
> > other
Hi all!
Proposed patch to:
Bug 93308 - bind(c) subroutine changes lower bound of array argument in
caller
Bug 93963 - Select rank mishandling allocatable and pointer arguments
with bind(c)
Bug 94327 - Bind(c) argument attributes are incorrectly set
Bug 94331 - Bind(C) corrupts array
On 5/19/21 10:39 AM, Jonathan Wakely via Gcc-patches wrote:
Jakub pointed out I'd forgotten the spaces before the opening parens
for function calls. The attached patch should fix all those, with no
other changes.
Tested x86_64-linux. OK for trunk?
Looks good to me, it just needs an update to
Here, when genericizing lexicographical_compare_three_way, we haven't yet
walked the operands, so (a == a) still sees ADDR_EXPR , but this is after
we've changed the type of a to REFERENCE_TYPE. When we try to fold (a == a)
by constexpr evaluation, the constexpr code doesn't understand trying to
Jonathan raised this issue with CWG, and there seems to be general agreement
that a deduction guide generated from a constructor should have access to
the same names that the constructor has access to. That seems to be as easy
as setting DECL_CONTEXT.
Tested x86_64-pc-linux-gnu, applying to
On 5/19/21 12:46 PM, Jonathan Wakely wrote:
On 19/05/21 17:39 +0100, Jonathan Wakely wrote:
Jakub pointed out I'd forgotten the spaces before the opening parens
for function calls. The attached patch should fix all those, with no
other changes.
Tested x86_64-linux. OK for trunk?
Jakub also
On Wed, May 19, 2021 at 05:59:34PM +0100, Jonathan Wakely wrote:
> On 19/05/21 12:53 -0400, Marek Polacek wrote:
> > On Wed, May 19, 2021 at 05:39:24PM +0100, Jonathan Wakely via Gcc-patches
> > wrote:
> > > Jakub pointed out I'd forgotten the spaces before the opening parens
> > > for function
Hi all!
Proposed patch to:
PR100683 - Array initialization refuses valid
Patch tested only on x86_64-pc-linux-gnu.
Add call to simplify expression before parsing.
Thank you very much.
Best regards,
José Rui
Fortran: Fix bogus error
gcc/fortran/ChangeLog:
PR fortran/100683
On 5/19/21 6:15 AM, Jonathan Wakely wrote:
This macro has been obsolete for years, and C++0x features are no longer
experimental or liable to be removed.
gcc/ChangeLog:
* doc/cpp.texi (Common Predefined Macros): Update documentation
for the __GXX_EXPERIMENTAL_CXX0X__ macro.
OK
On 5/18/21 5:00 PM, Marek Polacek wrote:
It turned out that there are codebases that profusely use GNU attributes
on friend declarations, so we have to dial back our checking and allow
them. And for C++11 attributes let's just warn instead of giving
errors.
Bootstrapped/regtested on
On 19/05/21 12:53 -0400, Marek Polacek wrote:
On Wed, May 19, 2021 at 05:39:24PM +0100, Jonathan Wakely via Gcc-patches wrote:
Jakub pointed out I'd forgotten the spaces before the opening parens
for function calls. The attached patch should fix all those, with no
other changes.
Tested
On 19/05/21 17:50 +0100, Jonathan Wakely wrote:
On 19/05/21 12:40 -0400, Eric Gallager wrote:
Thank you for doing this! One thing I'm wondering about, is that I'm
pretty sure clang also allows at least some of these to be used with
plain C as well, for example for things like the old use of
On Wed, May 19, 2021 at 05:39:24PM +0100, Jonathan Wakely via Gcc-patches wrote:
> Jakub pointed out I'd forgotten the spaces before the opening parens
> for function calls. The attached patch should fix all those, with no
> other changes.
>
> Tested x86_64-linux. OK for trunk?
Nice, this is
On 19/05/21 12:40 -0400, Eric Gallager wrote:
Thank you for doing this! One thing I'm wondering about, is that I'm
pretty sure clang also allows at least some of these to be used with
plain C as well, for example for things like the old use of "auto" in
C conflicting with the newer C++11 meaning
On 19/05/21 17:39 +0100, Jonathan Wakely wrote:
Jakub pointed out I'd forgotten the spaces before the opening parens
for function calls. The attached patch should fix all those, with no
other changes.
Tested x86_64-linux. OK for trunk?
Jakub also pointed out we already have some similar
On Wed, May 19, 2021 at 12:33 PM Jonathan Wakely via Gcc-patches
wrote:
>
> This adds new warning flags, enabled by default: -Wc++11-extensions,
> -Wc++14-extensions, -Wc++17-extensions, and -Wc++20-extensions. The
> names of the flags are copied from Clang, which already has similar
> options.
>
Jakub pointed out I'd forgotten the spaces before the opening parens
for function calls. The attached patch should fix all those, with no
other changes.
Tested x86_64-linux. OK for trunk?
commit a7dc19cdc0c5d3762bb90d12ebd82a05d0013246
Author: Jonathan Wakely
Date: Wed May 19 17:37:00 2021
This adds new warning flags, enabled by default: -Wc++11-extensions,
-Wc++14-extensions, -Wc++17-extensions, and -Wc++20-extensions. The
names of the flags are copied from Clang, which already has similar
options.
No new diagnostics are added, but the new OPT_Wxxx variables are used to
control
Hi,
This is a belated patch which covers some of the more notable changes
that have gone into the GCC 11 release of the D front-end.
Ran this through the W3 validator and no new warnings are generated.
I will go through it a few more times to see if there's anything more
that can be made more
On Wed, May 19, 2021 at 02:32:02PM +0200, Tobias Burnus wrote:
> Regarding gfortran.dg/pr96711.f90:
>
> On my x86-64-gnu-linux, it PASSes.
> On our powerpc64le-linux-gnu it FAILS with
> 'STOP 3' (→ also scan-dump count) and 'STOP 4'.
>
> Contrary to PR96983's bug summary, I don't get an ICE.
>
gcc/testsuite/ChangeLog:
* g++.dg/modules/omp-1_a.C: Check pthread is available.
* g++.dg/modules/omp-1_b.C: Ditto.
* g++.dg/modules/omp-1_c.C: Ditto.
* g++.dg/modules/omp-2_a.C: Ditto.
* g++.dg/modules/omp-2_b.C: Ditto.
---
On 4/23/21 6:48 PM, Tom de Vries wrote:
> On 4/23/21 5:45 PM, Alexander Monakov wrote:
>> On Thu, 22 Apr 2021, Tom de Vries wrote:
>>
>>> Ah, I see, agreed, that makes sense. I was afraid there was some
>>> fundamental problem that I overlooked.
>>>
>>> Here's an updated version. I've tried to
On Wed, 19 May 2021, Martin Liška wrote:
> > I'm not sure where this list comes from
>
> I split parts in contrib/config-list.mk and printed them.
>
> > but I'd expect "linux" to be the
> > canonical "linux-gnu", along with "linux-uclibc", "linux-android",
> > "linux-musl" ("uclibc" etc. aren't
This patch is missing documentation (in cpp.texi) and tests for the value
of the macro.
--
Joseph S. Myers
jos...@codesourcery.com
On 19/05/2021 15:44, Alex Coplan via Gcc-patches wrote:
This time with attachment.
On 19/05/2021 15:42, Alex Coplan via Gcc-patches wrote:
Hi Richard,
On 17/05/2021 17:31, Richard Earnshaw wrote:
On 30/04/2021 09:30, Alex Coplan via Gcc-patches wrote:
Hi,
As the PR shows, we ICE
On Wed, 19 May 2021 at 16:40, Richard Earnshaw
wrote:
>
>
>
> On 19/05/2021 09:10, Christophe Lyon via Gcc-patches wrote:
> > Some targets (eg arm-none-uclinuxfdpiceabi) do not support Thumb-1,
> > and since the testcase forces -march=armv8-m.base, we need to check
> > whether this option is
Hi Geng:
Thanks for your patch, committed with minor tweaks for gcc_assert.
On Tue, May 18, 2021 at 2:31 PM Geng Qi via Gcc-patches
wrote:
>
> gcc/ChangeLog:
> * common/config/riscv/riscv-common.c
> (riscv_subset_list::parsing_subset_version): Properly parse the letter
>
ENOATTACHMENT.
On 19/05/2021 15:42, Alex Coplan via Gcc-patches wrote:
Hi Richard,
On 17/05/2021 17:31, Richard Earnshaw wrote:
On 30/04/2021 09:30, Alex Coplan via Gcc-patches wrote:
Hi,
As the PR shows, we ICE shortly after expanding nonsecure calls for
Armv8.1-M. For Armv8.1-M, we
Looking through the bugzilla logs shows:
Since it is a gcc_checking_assert that triggers the ICE,
I assumed that does not affect a release build,
is that correct?
So it would appear that the decision was taken that a backport was not
needed.
Have I missed something?
R.
On 19/05/2021
This time with attachment.
On 19/05/2021 15:42, Alex Coplan via Gcc-patches wrote:
> Hi Richard,
>
> On 17/05/2021 17:31, Richard Earnshaw wrote:
> >
> >
> > On 30/04/2021 09:30, Alex Coplan via Gcc-patches wrote:
> > > Hi,
> > >
> > > As the PR shows, we ICE shortly after expanding nonsecure
Hi Richard,
On 17/05/2021 17:31, Richard Earnshaw wrote:
>
>
> On 30/04/2021 09:30, Alex Coplan via Gcc-patches wrote:
> > Hi,
> >
> > As the PR shows, we ICE shortly after expanding nonsecure calls for
> > Armv8.1-M. For Armv8.1-M, we have TARGET_HAVE_FPCXT_CMSE. As it stands,
> > the
On 19/05/2021 09:10, Christophe Lyon via Gcc-patches wrote:
Some targets (eg arm-none-uclinuxfdpiceabi) do not support Thumb-1,
and since the testcase forces -march=armv8-m.base, we need to check
whether this option is actually supported.
Using dg-add-options arm_arch_v8m_base ensure that we
On Wed, May 19, 2021 at 09:54:07AM +0200, Jakub Jelinek wrote:
> Hi!
>
> As can be seen on the testcases, before the -fdirectives-only preprocessing
> rewrite the preprocessor would assume // comments are terminated by the
> end of file even when newline wasn't there, but now we error out.
> The
On 5/19/21 5:13 AM, Richard Biener wrote:
On Tue, May 18, 2021 at 6:35 PM Andrew MacLeod wrote:
On 5/18/21 3:22 AM, Richard Biener wrote:
On Tue, May 18, 2021 at 1:23 AM Andrew MacLeod via Gcc-patches
wrote:
The code in PR 100512 triggers an interaction between ranger and the
propagation
On Thu, 2021-01-21 at 16:46 -0700, Martin Sebor via Gcc-patches wrote:
Martin and I had a chat about this patch, but it's best to discuss code
on the mailing list rather than in a silo, so here goes...
> The initial patch I posted is missing initialization for a couple
> of locals. I'd noticed
On 5/19/21 3:27 PM, Jonathan Wakely wrote:
> On 18/05/21 13:58 +0200, Bernd Edlinger wrote:
>> On 5/18/21 1:55 PM, Bernd Edlinger wrote:
>>> On 5/17/21 7:13 PM, Jonathan Wakely via Gcc-patches wrote:
libstdc++-v3/ChangeLog:
* include/std/thread (jthread::_S_create): Fix static
Jonathan Wright writes:
> Hi,
>
> As subject, this patch corrects the type attribute in RTL patterns that
> generate XTN/XTN2 instructions to be "neon_move_narrow_q".
>
> This makes a material difference because these instructions can be
> executed on both SIMD pipes in the Cortex-A57 core model,
Jonathan Wright writes:
> Hi,
>
> The existing vec_pack_trunc RTL pattern emits an opaque two-
> instruction assembly code sequence that prevents proper instruction
> scheduling. This commit changes the pattern to an expander that emits
> individual xtn and xtn2 instructions.
>
> This commit also
On Wed, May 19, 2021 at 10:15:49AM +0200, Richard Biener wrote:
> On Wed, May 19, 2021 at 8:20 AM Kewen.Lin wrote:
> "weight_factor" is kind-of double-speak
"Weighting factor" (with -ing) is a standard term actually. (But
cost_factor of course is better and avoids all that :-) )
Segher
On 5/19/21 3:22 PM, H.J. Lu wrote:
> On Wed, May 19, 2021 at 2:33 AM Richard Biener
> wrote:
>>
>> On Tue, May 18, 2021 at 9:16 PM H.J. Lu wrote:
>>>
>>> When expanding a constant constructor, don't call expand_constructor if
>>> it is more efficient to load the data from the memory via move by
On 18/05/21 13:58 +0200, Bernd Edlinger wrote:
On 5/18/21 1:55 PM, Bernd Edlinger wrote:
On 5/17/21 7:13 PM, Jonathan Wakely via Gcc-patches wrote:
libstdc++-v3/ChangeLog:
* include/std/thread (jthread::_S_create): Fix static assert
message.
*
PR testsuite/100658
gcc/cp/ChangeLog:
* mangle.c (write_encoding): Fix typos.
gcc/jit/ChangeLog:
* libgccjit.c (gcc_jit_context_new_function): Fix typos.
gcc/testsuite/ChangeLog:
* gcc.dg/local1.c: Fix typos.
* gcc.dg/ucnid-5-utf8.c: Likewise.
On Wed, May 19, 2021 at 2:33 AM Richard Biener
wrote:
>
> On Tue, May 18, 2021 at 9:16 PM H.J. Lu wrote:
> >
> > When expanding a constant constructor, don't call expand_constructor if
> > it is more efficient to load the data from the memory via move by pieces.
> >
> > gcc/
> >
> > PR
Hi!
On Wed, May 19, 2021 at 04:36:00PM +0800, HAO CHEN GUI wrote:
> On 19/5/2021 下午 4:33, HAO CHEN GUI wrote:
> > This patch removes mode promotion of SSA variables on rs6000
> >platform.
It isn't "promotion of SSA variables". At the point where this code
applies we are generating RTL,
Jonathan Wright writes:
> Hi,
>
> As subject, this patch adds tests to confirm that a *2 (write to high-half)
> Neon instruction is generated from vcombine* of a narrowing intrinsic
> sequence.
>
> Ok for master?
OK, thanks.
Richard
> Thanks,
> Jonathan
>
> ---
>
> gcc/testsuite/ChangeLog:
>
>
Jonathan Wright writes:
> Hi,
>
> As subject, this patch splits the aarch64_qshrn_n
> pattern into separate scalar and vector variants. It further splits the vector
> pattern into big/little endian variants that model the zero-high-half
> semantics of the underlying instruction - allowing for
Jonathan Wright writes:
> Hi,
>
> As subject, this patch uses UNSPEC_SQXTUN instead of UNSPEC_SQXTUN2
> in the aarch64_sqxtun2 patterns. This allows for more more
> aggressive combinations and ultimately better code generation - which will
> be confirmed by a new set of tests in
>
Jonathan Wright writes:
> Hi,
>
> As subject, this patch implements saturating right-shift and narrow high
> Neon intrinsic RTL patterns using a vec_concat of a register_operand
> and a VQSHRN_N unspec - instead of just a VQSHRN_N unspec. This
> more relaxed pattern allows for more aggressive
Jonathan Wright writes:
> Hi,
>
> As subject, this patch implements v[r]addhn2 and v[r]subhn2 Neon intrinsic
> RTL patterns using a vec_concat of a register_operand and an ADDSUBHN
> unspec - instead of just an ADDSUBHN2 unspec. This more relaxed pattern
> allows for more aggressive combinations
This fixes the bogus use of TYPE_PRECISION on vector types
from optimizing -((int)x >> 31) into (unsigned)x >> 31.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2021-05-19 Richard Biener
PR middle-end/100672
* fold-const.c (fold_negate_expr_1): Use
Hi!
On 2020-08-12T15:57:23+0200, Tom de Vries wrote:
> When enabling sync_int_long for nvptx, we run into a failure in
> gcc.dg/pr86314.c:
> ...
> nvptx-run: error getting kernel result: operation not supported on \
>global/shared address space
> ...
> due to a ptx restriction: accesses to
On Wed, May 19, 2021 at 2:25 AM Richard Biener
wrote:
>
> On Tue, May 18, 2021 at 9:16 PM H.J. Lu wrote:
> >
> > Add TARGET_READ_MEMSET_VALUE and TARGET_GEN_MEMSET_VALUE to support
> > target instructions to duplicate QImode value to TImode/OImode/XImode
> > value for memmset.
> >
> > PR
The following does no longer mark TARGET_MEM_REF bases addressable,
mimicing MEM_REFs beahvior here. In contrast to the latter,
TARGET_MEM_REF RTL expansion expects to always operate on memory
though, so make sure we expand them so.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
On 5/18/21 10:18 PM, Joseph Myers wrote:
On Tue, 18 May 2021, Martin Liška wrote:
+@quotation
+aix7.1, aix7.2, amdhsa, androideabi, aout, cygwin, darwin, darwin10, darwin7,
+darwin8, darwin9, eabi, eabialtivec, eabisim, eabisimaltivec, elf, elf32,
+elfbare, elfoabi, freebsd4, freebsd6, gnu,
Regarding gfortran.dg/pr96711.f90:
On my x86-64-gnu-linux, it PASSes.
On our powerpc64le-linux-gnu it FAILS with
'STOP 3' (→ also scan-dump count) and 'STOP 4'.
Contrary to PR96983's bug summary, I don't get an ICE.
On powerpc64le-linux-gnu, the following condition evaluates true (→ 'STOP
Ping!!
> -Original Message-
> From: Srinath Parvathaneni
> Sent: 30 April 2021 16:24
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov ; Richard Earnshaw
>
> Subject: [GCC-10 backport][PATCH] arm: _Generic feature failing with ICE for
> -O0 (pr97205).
>
> Hi,
>
> This is a backport
On Wed, 19 May 2021 at 13:29, Christophe Lyon
wrote:
>
> On Wed, 19 May 2021 at 13:13, Richard Biener wrote:
> >
> > On Wed, 19 May 2021, Jakub Jelinek wrote:
> >
> > > On Wed, May 19, 2021 at 11:09:19AM +0200, Jakub Jelinek via Gcc-patches
> > > wrote:
> > > > On Wed, May 19, 2021 at
Hi!
On 2018-08-13T21:41:50+0100, Julian Brown wrote:
> On Mon, 13 Aug 2018 11:42:26 -0700 Cesar Philippidis
> wrote:
>> On 08/13/2018 09:21 AM, Julian Brown wrote:
>> > diff --git a/libgomp/testsuite/libgomp.oacc-c-c++-common/loop-gwv-2.c
>> >
On Tue, May 18, 2021 at 05:48:40AM -0500, Segher Boessenkool wrote:
> I wrote a bit later:
>
> > > Can you make this less hacky please? Changing the generic code is just
> > > fine as well, it needs some love.
>
> In effect making a callback / hook without making that explicit is bad
> for
On Wed, 19 May 2021 at 13:13, Richard Biener wrote:
>
> On Wed, 19 May 2021, Jakub Jelinek wrote:
>
> > On Wed, May 19, 2021 at 11:09:19AM +0200, Jakub Jelinek via Gcc-patches
> > wrote:
> > > On Wed, May 19, 2021 at 10:15:53AM +0200, Christophe Lyon via Gcc-patches
> > > wrote:
> > > > After
On Wed, 19 May 2021, Jakub Jelinek wrote:
> On Wed, May 19, 2021 at 11:09:19AM +0200, Jakub Jelinek via Gcc-patches wrote:
> > On Wed, May 19, 2021 at 10:15:53AM +0200, Christophe Lyon via Gcc-patches
> > wrote:
> > > After this update, the test fails on arm and aarch64: according to the
> > >
1 - 100 of 126 matches
Mail list logo
