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 pass -mthumb as
needed too.
2021-05-19 Christophe Lyon
On Wed, May 19, 2021 at 8:20 AM Kewen.Lin wrote:
>
> Hi,
>
> This patch is to replace the current hardcoded weight factor 50
> for those statements in an inner loop relative to the loop being
> vectorized with a specific parameter vect-inner-loop-weight-factor.
>
> The motivation behind this chang
On Tue, 18 May 2021 at 09:42, Jakub Jelinek via Gcc-patches
wrote:
>
> Hi!
>
> As mentioned earlier, spaceship_replacement didn't optimize partial_ordering
> >= 0 comparisons, because the possible values are -1, 0, 1, 2 and the
> >= comparison is implemented as (res & 1) == res to choose the 0 and
This inlines verify_types_in_gimple_min_lval and makes sure we
also verify call lhs and arguments. It also asserts that
WITH_SIZE_EXPR in plain assignments does not happen, instead
those should have become memcpy/memset.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
2021-05-18 Ri
Sorry, forgot to gcc-patches
On 19/5/2021 下午 4:33, HAO CHEN GUI wrote:
Hi,
This patch removes mode promotion of SSA variables on rs6000
platform.
The attachment are the patch diff and change log file.
Bootstrapped and tested on powerppc64le and powerppc64be (with
m32) with no r
On Tue, 18 May 2021, Uros Bizjak wrote:
> Add infrastructure, logic and arithmetic support for 4-byte vectors.
> These can be used with SSE2 targets, where movd instructions from/to
> XMM registers are available. x86_64 ABI passes 4-byte vectors in
> integer registers, so also add logic operation
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
> logs, the optimization is still performed 14 times.
Seems this is because
if (change
&& !flag_syntax_only
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 engine related to undefined
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 middle-end/90773
> * builtins.c (builtin_memset_read_str): Call
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 middle-end/90773
> * expr.c (expand_expr_real_1): Don't call expand
Hi Richi,
on 2021/5/19 下午4:15, Richard Biener wrote:
> On Wed, May 19, 2021 at 8:20 AM Kewen.Lin wrote:
>>
>> Hi,
>>
>> This patch is to replace the current hardcoded weight factor 50
>> for those statements in an inner loop relative to the loop being
>> vectorized with a specific parameter vect-
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
> > logs, the optimization is still performed 14 times.
>
On Wed, May 19, 2021 at 11:47 AM Kewen.Lin wrote:
>
> Hi Richi,
>
> on 2021/5/19 下午4:15, Richard Biener wrote:
> > On Wed, May 19, 2021 at 8:20 AM Kewen.Lin wrote:
> >>
> >> Hi,
> >>
> >> This patch is to replace the current hardcoded weight factor 50
> >> for those statements in an inner loop re
This enables the alias machinery for WITH_SIZE_EXPR which can appear
in call LHS and arguments. In particular this drops the NULL
return from get_base_address and it adjusts get_ref_base_and_extent
and friends to use the size information in WITH_SIZE_EXPR and
look through it for further processing
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 consolidates the duplicate truncation p
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 for trunk and release branches?
commit 6704
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, whereas the
"neon_shift_imm_narrow_q"
The toolchain provided by ST for stm32 has had support for
__FILENAME__ for a while, but clang/llvm has recently implemented
support for __FILE_NAME__, so it seems better to use the same macro
name in GCC.
It happens that the ST patch is similar to the one proposed in PR
c/42579.
Given these inpu
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
> > > lo
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 th
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 maint
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
>> > b/libgomp/testsuite/libgomp.oacc-c-c++-common/loop
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 10:15:53AM
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 to
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 3'):
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, hpu
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.
20
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
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
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 e
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 a
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 comb
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
> gcc.target/aarch
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 more
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:
>
>
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, which
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 mi
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 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.
* testsuite/30_threads/jthre
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 p
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
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
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,
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 as
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 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 eng
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 f
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
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 expande
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
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 1
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 have
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
>
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 actua
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 shortl
This patch is missing documentation (in cpp.texi) and tests for the value
of the macro.
--
Joseph S. Myers
jos...@codesourcery.com
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
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 ma
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.
---
gcc/testsuite/g++.dg/modules/omp
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.
>
>
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 su
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 exi
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
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.
>
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 diagno
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 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 cool
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 "aut
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 x86_64-l
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 x86_64-pc-l
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
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 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 ca
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 po
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 trunk
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
t
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 t
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 descripto
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 cha
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.
Th
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 = 10384593717
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
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 for
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 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.
Tes
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 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 shoul
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 pa
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
> fusion.
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 where
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 d0e79f75dc3723231609f24e2840ac5858a652
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 – unle
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 attached
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 s
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
defaul
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, $constra
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 arc
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 optimizat
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. Myer
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 t
1 - 100 of 128 matches
Mail list logo
