The dwarf2out map of tree to symbol + offset is populated too early
when streaming in trees so that when WPA tree merging decides to
recycle them the mapping prevails and if we are unlucky the same
address is used for another tree with a symbol + offset DIE to
record. The following mitigates the r
get_memory_rtx tries hard to come up with a MEM_EXPR to record
in the memory attributes but in the last fallback fails to properly
account for an unknown offset and thus, as visible in this testcase,
incorrect alignment computed from set_mem_attributes. The following
rectifies both parts.
Bootstr
On Thu, Jul 14, 2022 at 10:12 PM Alexander Monakov wrote:
>
>
> On Thu, 14 Jul 2022, Richard Biener wrote:
>
> > Indeed. Guess that's what __builtin_setjmp[_receiver] for SJLJ_EH got
> > "right".
> >
> > When copying a block we do not copy labels so any "jumps" remain to the
> > original
> > bl
On Mon, Jul 18, 2022 at 4:31 AM liuhongt wrote:
>
> V2 update:
>Handle VMAT_ELEMENTWISE, VMAT_CONTIGUOUS_PERMUTE, VMAT_STRIDED_SLP,
>VMAT_CONTIGUOUS_REVERSE, VMAT_CONTIGUOUS_DOWN for complex type.
>
> I've run SPECspeed@2017 627.cam4_s, there's some vectorization cases,
> but no big perfor
Hello,
the principle looks good, but...
Le 18/07/2022 à 22:43, Harald Anlauf via Fortran a écrit :
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 2ebf076f730..dacd33561d0 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -5004,7 +5004,11 @@ find_array_spec
On Tue, Jul 19, 2022 at 8:56 AM Hongtao Liu wrote:
>
> On Tue, Jul 19, 2022 at 2:35 PM Uros Bizjak via Gcc-patches
> wrote:
> >
> > On Tue, Jul 19, 2022 at 8:07 AM liuhongt wrote:
> > >
> > > And split it after reload.
> > >
> > > > You will need ix86_binary_operator_ok insn constraint here with
On Mon, 18 Jul 2022 at 11:11, Marco Falke via Libstdc++
wrote:
>
> (in reply to https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598412.html,
> adding libstdc++ to CC, with the same patch attached again)
>
> To clarify, this is not a fix for a user-facing issue of gcc or a fix
> for UB. It is j
On Sun, 17 Jul 2022 at 22:13, Stephan Bergmann via Libstdc++
wrote:
>
> On 7/15/22 22:25, Marek Polacek via Gcc-patches wrote:
> > Yeah, I guess so. But I've already pushed the patch.
>
> This commit obviously breaks using libstdc++ with Clang (in -std=c++2b
> mode), which doesn't implement those
Thanks Jonathan. Either name is perfectly fine.
To clarify, this will be pushed to master and also backported to the 12-branch?
Best, Marco
On Tue, Jul 19, 2022 at 12:06 PM Jonathan Wakely wrote:
>
> On Mon, 18 Jul 2022 at 11:11, Marco Falke via Libstdc++
> wrote:
> >
> > (in reply to
> > htt
On Tue, 19 Jul 2022 at 11:13, Marco Falke wrote:
>
> Thanks Jonathan. Either name is perfectly fine.
OK, thanks.
>
> To clarify, this will be pushed to master and also backported to the
> 12-branch?
Yes, that's right. It will go to trunk (aka master) today and then
backported to the gcc-12 bra
On Sun, 10 Jul 2022 at 14:57, François Dumont via Libstdc++
wrote:
>
> Here is a first patch to complete __gnu_debug::basic_string Standard
> conformity.
>
> I prefer to submit this before checking for more missing stuff to check
> that my proposal of having a testsuite_string.h header is ok.
I t
Hi Jakub,
On Tue, 26 Apr 2022, Jakub Jelinek via Gcc-patches wrote:
> The following testcase regressed on riscv due to the splitting of critical
> edges in the sink pass, similarly to x86_64 compared to GCC 11 we now swap
> the edges, whether true or false edge goes to an empty forwarded bb.
> >F
On Tue, 19 Jul 2022 at 11:08, Jonathan Wakely wrote:
>
> On Sun, 17 Jul 2022 at 22:13, Stephan Bergmann via Libstdc++
> wrote:
> >
> > On 7/15/22 22:25, Marek Polacek via Gcc-patches wrote:
> > > Yeah, I guess so. But I've already pushed the patch.
> >
> > This commit obviously breaks using libst
Our documentation indicates that it is the `-frounding-math' invocation
option that controls whether we respect what the FENV_ACCESS pragma
would imply, should we implement it, regarding the floating point
environment. It is only a part of the picture however, because the
`-ftrapping-math' inv
1. The original LA macro instruction is split into two instructions to
obtain the address of the symbol if enable '-mexplicit-relocs'.
2. Currently, '-mcmodel=' only supports 'normal' mode, because other mode
behaviors are not yet determined. This function is gradually improved
by the subs
1. The original LA macro instruction is split into two instructions to
obtain the address of the symbol if enable '-mexplicit-relocs'.
2. Currently, '-mcmodel=' only supports 'normal' mode, because other mode
behaviors are not yet determined. This function is gradually improved
by the subs
Some R_LARCH_64 in section .eh_frame will to generate R_LARCH_NONE, we
change relocation to R_LARCH_32_PCREL from R_LARCH_64 in setction .eh_frame
and not generate dynamic relocation for R_LARCH_32_PCREL.
gcc/ChangeLog:
* config/loongarch/loongarch.h (ASM_PREFERRED_EH_DATA_FORMAT):
Tested x86_64-linux, OK for trunk?
-- >8 --
The new built-ins need to be detectable using __has_builtin, and the
library should use that to check for them.
This fixes an error with Clang when C++23 is enabled.
gcc/cp/ChangeLog:
* cp-objcp-common.cc (names_builtin_p): Return true for
On Tue, Jul 19, 2022 at 02:11:02PM +0100, Jonathan Wakely wrote:
> Tested x86_64-linux, OK for trunk?
>
> -- >8 --
>
> The new built-ins need to be detectable using __has_builtin, and the
> library should use that to check for them.
>
> This fixes an error with Clang when C++23 is enabled.
LGTM
Attached is a patch file with those changes.
Thanks
-Sam
On Tue, Jul 19, 2022 at 2:36 AM Richard Biener
wrote:
> On Mon, Jul 18, 2022 at 7:31 PM Sam Feifer via Gcc-patches
> wrote:
> >
> > Just realized I had mixed up the 9 and the 2 when labelling the patch.
> This
> > patch is referring to p
I found this logging tweak very helpful when working on
PR analyzer/106284.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r13-1747-g434d521d118fc7.
gcc/analyzer/ChangeLog:
* engine.cc (exploded_graph::process_node): Show any description
of the o
PR analyzer/106321 reports false positives from
-Wanalyzer-tainted-array-index on switch statements, seen e.g.
in the Linux kernel in drivers/vfio/pci/vfio_pci_core.c, where
vfio_pci_core_ioctl has:
| 744 | switch (info.index) {
| | ~~ ~~
On 7/19/22 09:11, Jonathan Wakely wrote:
Tested x86_64-linux, OK for trunk?
OK.
-- >8 --
The new built-ins need to be detectable using __has_builtin, and the
library should use that to check for them.
This fixes an error with Clang when C++23 is enabled.
gcc/cp/ChangeLog:
* cp-obj
Hi,
Based on the previous discussion on the Version 1 of the patch:
https://gcc.gnu.org/pipermail/gcc-patches/2022-June/597350.html
https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598010.html
We decided:
*User interface:
. command line option in C/C++:
-fstrict-flex-array[=N]
GCC does not support in-tree builds at the moment, so .gitignore
concealing artifacts of accidental in-tree ./configure run may cause
confusion. Un-ignore config.h, which is known to break the build.
ChangeLog:
* .gitignore: Do not ignore config.h.
---
.gitignore | 3 ++-
1 file changed,
>From 3854004802b8e2f132ebf218fc35a632f5e80c6a Mon Sep 17 00:00:00 2001
From: Qing Zhao
Date: Mon, 18 Jul 2022 17:04:12 +
Subject: [PATCH 1/2] Add a new option -fstrict-flex-array[=n] and new
attribute strict_flex_array
Add the following new option -fstrict-flex-array[=n] and a corresponding
>From a09f39ded462611286a44d9e8273de8342673ba2 Mon Sep 17 00:00:00 2001
From: Qing Zhao
Date: Mon, 18 Jul 2022 18:12:26 +
Subject: [PATCH 2/2] Use new flag DECL_NOT_FLEXARRAY in __builtin_object_size
[PR101836]
Use new flag DECL_NOT_FLEXARRAY to determine whether the trailing array
of a struc
On Tue, 19 Jul 2022 at 12:10, Jonathan Wakely wrote:
>
> On Tue, 19 Jul 2022 at 11:08, Jonathan Wakely wrote:
> >
> > On Sun, 17 Jul 2022 at 22:13, Stephan Bergmann via Libstdc++
> > wrote:
> > >
> > > On 7/15/22 22:25, Marek Polacek via Gcc-patches wrote:
> > > > Yeah, I guess so. But I've alrea
The change seems too large. It would be better to split it into
multiple commits (for example, just 3 commits for 1,2,3 below).
On Tue, 2022-07-19 at 21:08 +0800, Lulu Cheng wrote:
> 1. The original LA macro instruction is split into two instructions to
> obtain the address of the symbol if e
Hi,
In patch https://gcc.gnu.org/pipermail/gcc-patches/2022-July/597712.html,
test case was not added. After more check, a testcase is added for it.
The high part of the symbol address is invalid for the constant pool.
In function rs6000_cannot_force_const_mem, we already return true for
"HIGH w
This function remains unused since remove_node_from_insn_list was cloned
from it.
gcc/ChangeLog:
* rtl.h (remove_node_from_expr_list): Remove declaration.
* rtlanal.cc (remove_node_from_expr_list): Remove (no uses).
---
gcc/rtl.h | 1 -
gcc/rtlanal.cc | 29 -
The testcase in the PR demonstrates how it is possible for one
__builtin_setjmp_receiver label to appear in
nonlocal_goto_handler_labels list twice (after the block with
__builtin_setjmp_setup referring to it was duplicated).
remove_node_from_insn_list did not account for this possibility and
remo
This patch adds three new function attributes to GCC that
are used for static analysis of usage of file descriptors:
1) __attribute__ ((fd_arg(N))): The attributes may be applied to a function that
takes on open file descriptor at refrenced argument N.
It indicates that the passed filedescriptor
On 19/07/22 12:42, Jonathan Wakely wrote:
On Sun, 10 Jul 2022 at 14:57, François Dumont via Libstdc++
wrote:
Here is a first patch to complete __gnu_debug::basic_string Standard
conformity.
I prefer to submit this before checking for more missing stuff to check
that my proposal of having a tes
On Tue, 2022-07-19 at 21:36 +0530, Immad Mir wrote:
[...snip...]
Thanks for the patch.
It's nearly ready for trunk; I have some review comments below, mostly
nits, but a couple of other issues...
> gcc/ChangeLog:
> * doc/extend.texi: Add fd_arg, fd_arg_read and fd_arg_write under
>
On Wed, Jul 13, 2022 at 05:36:04PM +0100, Richard Sandiford wrote:
> I like the part about getting rid of:
>
> static tree
> aarch64_simd_builtin_type (machine_mode mode,
> bool unsigned_p, bool poly_p)
>
> and the flow of the new function. However, I think it's still
>
On Mon, 18 Jul 2022, Jason Merrill wrote:
> On 7/18/22 12:59, Patrick Palka wrote:
> > In case of l/rvalue or cv-qual mismatch during reference binding, we try
> > to give more helpful diagnostics by attempting a bad conversion that
> > ignores the mismatch. But in doing so, we may end up instant
Hi Mikael,
Am 19.07.22 um 11:03 schrieb Mikael Morin:
Hello,
the principle looks good, but...
Le 18/07/2022 à 22:43, Harald Anlauf via Fortran a écrit :
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 2ebf076f730..dacd33561d0 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/f
On Tue, 19 Jul 2022, Richard Biener wrote:
> > Like below?
>
> Yes.
>
> Thanks and sorry for the back and forth - this _is_ a mightly
> complicated area ...
No problem! This is the good, healthy kind of back-and-forth, and
I am grateful.
Pushed, including the tree-cfg validator enhancement in
On Tue, 2022-07-19 at 14:18 -0400, David Malcolm wrote:
> On Tue, 2022-07-19 at 21:36 +0530, Immad Mir wrote:
>
[...snip...]
>
>
> > +void
> > +fd_state_machine::check_for_fd_attrs (
> > + sm_context *sm_ctxt, const supernode *node, const gimple
> > *stmt,
> > + const tree callee_fndecl,
[PATCH, rs6000, v2] Additional cleanup of rs6000_builtin_mask
Hi,
Post the rs6000 builtins rewrite, some of the leftover builtin
code is redundant and can be removed.
This replaces the usage of bu_mask in rs6000_target_modify_macros
with checks against the rs6000_isa_flags equivalent direc
[PATCH, rs6000, v2] Cleanup some vstrir define_expand naming inconsistencies
Hi,
This cleans up some of the naming around the vstrir and vstril
instruction definitions, with some cosmetic changes for consistency.
No functional changes.
Regtested just in case, no regressions.
[V2]
Used 'direct'
This patch adds -static-pie support for the arm architecture. aarch64
had the appropriate code for handling -static-pie, so this just mirrors
the code found there. Tested with uclibc-ng and musl c-standard
libraries to produce static-pie binaries.From 56f0daba7bea5d64922c0f45a4fde360f39fb17e Mo
Le 19/07/2022 à 21:09, Harald Anlauf via Fortran a écrit :
Hi Mikael,
Am 19.07.22 um 11:03 schrieb Mikael Morin:
Hello,
the principle looks good, but...
Le 18/07/2022 à 22:43, Harald Anlauf via Fortran a écrit :
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 2ebf076f730.
Hi Mikael,
Am 19.07.22 um 22:53 schrieb Mikael Morin:
It could be anything better than the (unhelpfull) internal error it is
replacing.
I suggest for example "Invalid array reference of a non-array entity at
%L".
yes, that's much better! The attached updated patch uses this.
Committed: r13-1
This patch removes the recursion from range_from_dom.
It was walking the dominators looking for a range, and if a block was
encountered with outgoing ranges, a recursive call was made to resolve
the incoming dominator range and then calculate incoming edges.
This meant the edges could all be
The main time a dominator search in the cache fails to produce an
accurate range is when we have a "complicated" join node.
ie
bb4:
if (a > 200) goto bb5 ; else goto bb9
bb5
if (b > 400) goto bb6 ; else goto bb7
bb6
foo (b)
bb7
onward()
goto bb200;
bb9:
if (b > 200) goto bb6; e
Doing so speeds up -fanalyzer from taking over 4 hours to under a
minute on the Linux kernel's sound/soc/codecs/cs47l90.c
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r13-1761-g68871a008e686d.
gcc/analyzer/ChangeLog:
PR analyzer/106359
* region
在 2022/7/19 下午10:29, Xi Ruoyao 写道:
The change seems too large. It would be better to split it into
multiple commits (for example, just 3 commits for 1,2,3 below).
On Tue, 2022-07-19 at 21:08 +0800, Lulu Cheng wrote:
1. The original LA macro instruction is split into two instructions to
Hi Will,
on 2022/7/20 04:15, will schmidt wrote:
> [PATCH, rs6000, v2] Additional cleanup of rs6000_builtin_mask
>
> Hi,
> Post the rs6000 builtins rewrite, some of the leftover builtin
> code is redundant and can be removed.
> This replaces the usage of bu_mask in rs6000_target_modify_ma
__builtin_cexpi can't be vectorized since there's gap between it and
vectorized sincos version(In libmvec, it passes a double and two
double pointer and returns nothing.) And it will lose some
vectorization opportunity if sin & cos are optimized to cexpi before
vectorizer.
I'm trying to add vect_r
On Tue, Jul 19, 2022 at 5:37 PM Uros Bizjak wrote:
>
> On Tue, Jul 19, 2022 at 8:56 AM Hongtao Liu wrote:
> >
> > On Tue, Jul 19, 2022 at 2:35 PM Uros Bizjak via Gcc-patches
> > wrote:
> > >
> > > On Tue, Jul 19, 2022 at 8:07 AM liuhongt wrote:
> > > >
> > > > And split it after reload.
> > > >
> My original comments still stand (it feels like this should be more generic).
> Can we go the way lowering complex loads/stores first? A large part
> of the testcases
> added by the patch should pass after that.
This is the patch as suggested, one additional change is handling COMPLEX_CST
for r
On Wed, Jul 20, 2022 at 4:37 AM Hongtao Liu wrote:
>
> On Tue, Jul 19, 2022 at 5:37 PM Uros Bizjak wrote:
> >
> > On Tue, Jul 19, 2022 at 8:56 AM Hongtao Liu wrote:
> > >
> > > On Tue, Jul 19, 2022 at 2:35 PM Uros Bizjak via Gcc-patches
> > > wrote:
> > > >
> > > > On Tue, Jul 19, 2022 at 8:07
On Wed, Jul 20, 2022 at 8:14 AM Uros Bizjak wrote:
>
> On Wed, Jul 20, 2022 at 4:37 AM Hongtao Liu wrote:
> >
> > On Tue, Jul 19, 2022 at 5:37 PM Uros Bizjak wrote:
> > >
> > > On Tue, Jul 19, 2022 at 8:56 AM Hongtao Liu wrote:
> > > >
> > > > On Tue, Jul 19, 2022 at 2:35 PM Uros Bizjak via Gcc
From: Sören Tempel
The `(( expression ))` syntax is a Bash extension and not supported by
POSIX shell [1]. However, the arithmetic expressions used by the
gobuild() function can also be expressed using arithmetic POSIX
expansions with `$(( expression ))` [2].
Contrary to the Bash extension, arit
On Wed, Jul 20, 2022 at 2:18 PM Uros Bizjak wrote:
>
> On Wed, Jul 20, 2022 at 8:14 AM Uros Bizjak wrote:
> >
> > On Wed, Jul 20, 2022 at 4:37 AM Hongtao Liu wrote:
> > >
> > > On Tue, Jul 19, 2022 at 5:37 PM Uros Bizjak wrote:
> > > >
> > > > On Tue, Jul 19, 2022 at 8:56 AM Hongtao Liu wrote:
57 matches
Mail list logo
