on 2022/8/29 14:35, Kewen.Lin via Gcc-patches wrote:
> on 2022/8/15 16:33, Kewen.Lin via Gcc-patches wrote:
>> on 2022/7/11 11:42, Kewen.Lin wrote:
>>> on 2022/6/15 14:20, Kewen.Lin wrote:
Hi Honza,
Thanks for the comments! Some replies are inlined below.
on 2022/6/14
Hi,
Gentle ping: https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600190.html
BR,
Kewen
on 2022/8/24 16:17, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> As discussed in PR98125, -fpatchable-function-entry with
> SECTION_LINK_ORDER support doesn't work well on powerpc64
> ELFv1 because the
Hi,
Gentle ping: https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600277.html
BR,
Kewen
on 2022/8/25 13:50, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> As PR99888 and its related show, the current support for
> -fpatchable-function-entry on powerpc ELFv2 doesn't work
> well with global
Hi,
I assumed the generic part introducing check_effective_target_vect_int_mod
needs the approval from global maintainers.
So gentle ping https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600191.html
BR,
Kewen
on 2022/8/24 16:17, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> As PR106516
Hi,
PR106680 shows that -m32 -mpowerpc64 is different from
-mpowerpc64 -m32, this is determined by the way how we
handle option powerpc64 in rs6000_handle_option.
Segher pointed out this difference should be taken as
a bug and we should ensure that option powerpc64 is
independent of -m32/-m64.
在 2022/9/27 下午10:01, David Malcolm 写道:
On Tue, 2022-09-27 at 14:02 +0800, Lulu Cheng wrote:
SARIF support was added in r13-967 but libvtv wasn't updated.
Sorry about breaking this. The patch looks reasonable to me, FWIW,
assuming that it fixes the issue, of course!
Looks like my
On Wed, Sep 28, 2022 at 7:35 AM H.J. Lu via Gcc-patches
wrote:
>
> encodekey128 and encodekey256 operations clear XMM4-XMM6. But it is
> documented that XMM4-XMM6 are reserved for future usages and software
> should not rely upon them being zeroed. Change encodekey128 and
Indeed. Ok for trunk
On 7/10/22 12:19, Roger Sayle wrote:
This patch builds upon Richard Biener's suggestion of avoiding global
variables to track state/identify which passes have already been run.
In the early middle-end, the tree-ssa passes use the curr_properties
field in cfun to track this. This patch uses a
On 8/17/22 16:18, H.J. Lu via Gcc-patches wrote:
Check stack canary before throwing exception to avoid stack corruption.
gcc/
PR middle-end/58245
* calls.cc: Include "tree-eh.h".
(expand_call): Check stack canary before throwing exception.
gcc/testsuite/
PR
On 8/5/22 05:41, Jose E. Marchesi via Gcc-patches wrote:
[Changes from V1:
- Added a test.]
It is common for C BPF programs to use variables that are implicitly
set by the BPF loader and run-time. It is also necessary for these
variables to be stored in read-only storage so the BPF verifier
AutoFDO counts are not reliable and we are currently not
performing hot/cold splitting based on them. This change adjusts
several tree-prof tests not to check for hot/cold splitting
when run with AutoFDO.
gcc/testsuite/ChangeLog:
* gcc.dg/tree-prof/cold_partition_label.c: Don't check for
On 9/7/22 08:20, Stefan Schulze Frielinghaus via Gcc-patches wrote:
Whenever a new cselib value is created check whether a smaller value
exists which is contained in the bigger one. If so add a subreg
relation to locs of the smaller one.
gcc/ChangeLog:
* cselib.cc (new_cselib_val):
On 9/7/22 08:20, Stefan Schulze Frielinghaus via Gcc-patches wrote:
For parameter of type integer which do not consume a whole register
(modulo sign/zero extension) this patch adds entry values up to maximal
register mode.
gcc/ChangeLog:
* var-tracking.cc (vt_add_function_parameter):
On Tue, Sep 27, 2022 at 05:44:12PM -0400, Jason Merrill wrote:
> On 9/27/22 16:26, Marek Polacek wrote:
> > --- a/gcc/cp/typeck.cc
> > +++ b/gcc/cp/typeck.cc
> > @@ -11042,8 +11042,13 @@ check_return_expr (tree retval, bool *no_warning)
> > the conditions for the named return value
encodekey128 and encodekey256 operations clear XMM4-XMM6. But it is
documented that XMM4-XMM6 are reserved for future usages and software
should not rely upon them being zeroed. Change encodekey128 and
encodekey256 to clobber XMM4-XMM6.
gcc/
PR target/107061
*
On 9/27/22 16:26, Marek Polacek wrote:
On Mon, Sep 26, 2022 at 01:29:35PM -0400, Jason Merrill wrote:
On 9/20/22 14:19, Marek Polacek wrote:
There's one FIXME in elision1.C:five, which we should compile but reject
with "passing 'Mutt' as 'this' argument discards qualifiers". That
looks bogus
On 9/27/22 15:50, Patrick Palka wrote:
This uses TRAIT_TYPE from the previous patch to implement efficient
built-ins for std::remove_cv, std::remove_reference and std::remove_cvref.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk?
OK once the previous patch goes
On 9/27/22 15:50, Patrick Palka wrote:
We already have generic support for predicate-like traits that yield a
boolean via TRAIT_EXPR, but we lack the same support for transform-like
traits that yield a type. Such support would be useful for implementing
efficient built-ins for std::decay and
On Tue, 27 Sept 2022 at 20:50, Patrick Palka via Libstdc++
wrote:
> libstdc++-v3/ChangeLog:
>
> * include/bits/unique_ptr.h (unique_ptr<_Tp[], _Dp>): Remove
> __remove_cv and use __remove_cv_t instead.
This part is OK. I added that __remove_cv in 2012, and could have
replaced it
On Mon, Sep 26, 2022 at 01:29:35PM -0400, Jason Merrill wrote:
> On 9/20/22 14:19, Marek Polacek wrote:
> > > > There's one FIXME in elision1.C:five, which we should compile but reject
> > > > with "passing 'Mutt' as 'this' argument discards qualifiers". That
> > > > looks bogus to me, I think
This is another minor improvement to coremark. I suspect this only
improves code size as the load-immediate was likely issuing with the ret
statement on multi-issue machines.
Basically we're failing to utilize conditional equivalences during the
post-reload CSE pass. So if a particular
This uses TRAIT_TYPE from the previous patch to implement efficient
built-ins for std::remove_cv, std::remove_reference and std::remove_cvref.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk?
gcc/c-family/ChangeLog:
* c-common.cc (c_common_reswords): Add
We already have generic support for predicate-like traits that yield a
boolean via TRAIT_EXPR, but we lack the same support for transform-like
traits that yield a type. Such support would be useful for implementing
efficient built-ins for std::decay and std::remove_cvref and other
conceptually
On Tue, Sep 27, 2022 at 10:46 AM Robin Dapp via Gcc-patches
wrote:
>
> > I did bootstrapping and ran the testsuite on x86(-64), aarch64, Power9
> > and s390. Everything looks good except two additional fails on x86
> > where code actually looks worse.
> >
> >
Le 27/09/2022 à 21:05, Harald Anlauf via Fortran a écrit :
Dear all,
invalid input may trigger an assert while trying to simplify an
expression involving the intrinsic UNPACK and when the constructor
is lacking sufficient valid elements. The obvious solution is to
replace the assert by a
Dear all,
invalid input may trigger an assert while trying to simplify an
expression involving the intrinsic UNPACK and when the constructor
is lacking sufficient valid elements. The obvious solution is to
replace the assert by a condition that terminates simplification
in that case.
Report and
> I did bootstrapping and ran the testsuite on x86(-64), aarch64, Power9
> and s390. Everything looks good except two additional fails on x86
> where code actually looks worse.
>
> gcc.target/i386/keylocker-encodekey128.c
>
> 17c17,18
> < movaps %xmm4, k2(%rip)
> ---
>> pxor
This patch implements support for [P1689R5][] to communicate to a build
system the C++20 module dependencies to build systems so that they may
build `.gcm` files in the proper order.
Support is communicated through the following three new flags:
- `-fdeps-format=` specifies the format for the
This patch adds initial support for ISO C++'s [P1689R5][], a format for
describing C++ module requirements and provisions based on the source
code. This is required because compiling C++ with modules is not
embarrassingly parallel and need to be ordered to ensure that `import
some_module;` can be
On Fri, Sep 23, 2022 at 6:59 AM wrote:
>
> From: Sören Tempel
>
> Tested on x86_64 Arch Linux (glibc) and Alpine Linux (musl libc).
>
> Previously, libgo relied on the _sigev_un implementation-specific
> field in struct sigevent, which is only available on glibc. This
> patch uses the
This libgo patch by Funan Zeng synchronizes the handling of empty
struct fields between the Go frontend and the libgo FFI code. In the
compiler the logic for allocating one byte for the last field of a
struct is:
1. the last field has zero size
2. the struct itself does not have zero size
3. the
On 8/22/22 00:16, Richard Biener via Gcc-patches wrote:
The following fixes PR105646, not diagnosing
int f1();
int f3(){
auto const & a = f1();
bool v3{v3};
return a;
}
with optimization because the early uninit diagnostic pass only
diagnoses always executed cases. The patch
> -Original Message-
> From: Andrea Corallo
> Sent: Tuesday, September 27, 2022 11:06 AM
> To: Kyrylo Tkachov
> Cc: Andrea Corallo via Gcc-patches ; Richard
> Earnshaw ; nd
> Subject: Re: [PATCH 9/15] arm: Set again stack pointer as CFA reg when
> popping if necessary
>
> Kyrylo
On 7/23/22 03:26, Roger Sayle wrote:
This patch is a one line correction/clarification to GCC's current
RTL documentation that explains a USE of a MEM is permissible.
PR rtl-optimization/99930 is an interesting example on x86_64 where
the backend generates better code when a USE is a (const)
Hi all
this is to address PR 99723.
In the PR GCC crashes as the initialization of common trees is not
performed as no compilation is happening, this is because we raise an
error earlier while processing the arch flags.
This patch changes the code to execute selftests only if no errors
where
On 7/21/22 01:18, Kim Kuparinen via Gcc-patches wrote:
Subject:
[PATCH] docs: update abi version info
From:
Kim Kuparinen via Gcc-patches
Date:
7/21/22, 01:18
To:
"gcc-patches@gcc.gnu.org"
Synchronize gcc/common.opts and gcc/doc/invoke.texi w.r.t -fabi-version, and
correct
The legacy popcount folding didn't actually fold singleton ranges.
I don't think anyone noticed because there are match.pd patterns that
pick up the slack using the global nonzero bits set by CCP.
It's good form to handle this, even without CCP's help.
Tested on x86-64 Linux.
p.s. This doesn't
In the test cases, it's clearly written that intrinsics are not
implemented on arm*. A simple xfail does not help since there are
link error and that would cause an UNRESOLVED testcase rather than
XFAIL.
By changing to dg-skip-if, the entire test case is omitted.
gcc/testsuite/ChangeLog:
On Tue, 2022-09-27 at 14:02 +0800, Lulu Cheng wrote:
> SARIF support was added in r13-967 but libvtv wasn't updated.
Sorry about breaking this. The patch looks reasonable to me, FWIW,
assuming that it fixes the issue, of course!
Looks like my normal testing process missed this when I
> Yes, because the native_interpret always starts at offset zero
> (we can't easily feed in a "shifted" RHS). So what I assumed is
> that IFN_LEN_STORE always stores elements [0, len + adj].
Hmm, but this assumption is not violated here or am I missing something?
It's not like we're storing
PING^1
On 9/22/22 14:51, Martin Liška wrote:
> Hi.
>
> Tested with Fangrui's patch set sent to binutils ML and mold linker.
>
> $ gcc -g -gz=zstd a.c --save-temps --verbose 2>&1 | grep debug-sections
> /home/marxin/Programming/binutils/objdir/gas/as-new -v --gdwarf-5
>
On Tue, Sep 27, 2022 at 3:19 PM Robin Dapp wrote:
>
> > The error is probably in vn_reference_lookup_3 which assumes that
> > 'len' applies to the vector elements in element order. See the part
> > of the code where it checks for internal_store_fn_p. If 'len' is with
> > respect to the memory
> The error is probably in vn_reference_lookup_3 which assumes that
> 'len' applies to the vector elements in element order. See the part
> of the code where it checks for internal_store_fn_p. If 'len' is with
> respect to the memory and thus endianess has to be taken into
> account then for the
On 9/27/22 04:41, Richard Biener wrote:
On Mon, Sep 26, 2022 at 9:54 PM Marek Polacek wrote:
On Mon, Sep 26, 2022 at 12:34:04PM -0400, Jason Merrill wrote:
On 9/26/22 03:50, Richard Biener wrote:
On Fri, Sep 23, 2022 at 8:41 PM Marek Polacek via Gcc-patches
wrote:
In
For those without a working crystal ball, I have now also included the patch.
On 27.09.22 15:15, Tobias Burnus wrote:
This patch adds support to handle reverse offload to libgomp's plugin-gcn.c and
to AMD GCN's libgomp target.c.
In theory, that's all whats needed for GCN – in practice there a
This patch adds support to handle reverse offload to libgomp's plugin-gcn.c and
to AMD GCN's libgomp target.c.
In theory, that's all whats needed for GCN – in practice there a known issue
with
private stack variables which has to be addressed independently. Once this and
the target.c generic
On Tue, Sep 27, 2022 at 10:41:29AM +0200, Richard Biener wrote:
> On Mon, Sep 26, 2022 at 9:54 PM Marek Polacek wrote:
> >
> > On Mon, Sep 26, 2022 at 12:34:04PM -0400, Jason Merrill wrote:
> > > On 9/26/22 03:50, Richard Biener wrote:
> > > > On Fri, Sep 23, 2022 at 8:41 PM Marek Polacek via
Hello,
Le 16/09/2022 à 15:26, Aldy Hernandez via Gcc-patches a écrit :
diff --git a/gcc/value-range.cc b/gcc/value-range.cc
index d759fcf178c..55a216efd8b 100644
--- a/gcc/value-range.cc
+++ b/gcc/value-range.cc
@@ -617,21 +602,24 @@ frange::contains_p (tree cst) const
if (varying_p ())
On 9/27/22 06:35, Jonathan Wakely wrote:
Tested powerpc64le-linux. OK for trunk?
OK, thanks.
-- >8 --
The is_convertible built-ins should return false if the conversion fails
an access check, not report an error.
PR c++/107049
gcc/cp/ChangeLog:
* method.cc
On Mon, Sep 26, 2022 at 5:25 PM Andrew Pinski via Gcc-patches
wrote:
>
> On Sun, Sep 25, 2022 at 9:56 PM Tamar Christina
> wrote:
> >
> > > -Original Message-
> > > From: Andrew Pinski
> > > Sent: Saturday, September 24, 2022 8:57 PM
> > > To: Tamar Christina
> > > Cc:
On Mon, 26 Sep 2022, Andre Vieira (lists) wrote:
>
> On 08/09/2022 12:51, Richard Biener wrote:
> >
> > I'm curious, why the push to redundant_ssa_names? That could use
> > a comment ...
> So I purposefully left a #if 0 #else #endif in there so you can see the two
> options. But the reason I
On Tue, Sep 27, 2022 at 11:35:10AM +0100, Jonathan Wakely wrote:
> Tested powerpc64le-linux. OK for trunk?
>
> -- >8 --
>
> The is_convertible built-ins should return false if the conversion fails
> an access check, not report an error.
Ah, so we do need that sentinel after all.
Patch looks
On 9/26/22 15:05, Patrick Palka wrote:
On Mon, 26 Sep 2022, Patrick Palka wrote:
On Mon, 26 Sep 2022, Nathan Sidwell wrote:
On 9/26/22 10:08, Nathan Sidwell wrote:
On 9/23/22 09:32, Patrick Palka wrote:
Judging by the two commits that introduced/modified this part of
On Tue, 2022-09-27 at 15:49 +0800, Lulu Cheng wrote:
> #if defined (__CYGWIN__) || defined (__MINGW32__)
> if (VTV_PAGE_SIZE != sysconf_SC_PAGE_SIZE())
> +#elif defined (__loongarch_lp64)
> + /* I think that under the LoongArch 64-bit system, VTV_PAGE_SIZE is set
> + to the maximum value
Tested x86_64-linux. Pushed to trunk.
-- >8 --
Adjust the deduction guides for std::function and std::packaged_task to
work with static call operators. This finishes the implementation of
P1169R4 for C++23.
libstdc++-v3/ChangeLog:
PR c++/106651
* include/bits/std_function.h
Hi!
As reported by Tobias, my C++ _Float{16,32,64,128,32x,64x,128x} support
patch broke Debian/Ubuntu bootstraps. The problem is that there
glibc bits/floatn.h and bits/floatn-common.h isn't in /usr/include/
directly, but in a subdirectory like /usr/include/x86_64-linux-gnu/
Seems other
Tested powerpc64le-linux. OK for trunk?
-- >8 --
The is_convertible built-ins should return false if the conversion fails
an access check, not report an error.
PR c++/107049
gcc/cp/ChangeLog:
* method.cc (is_convertible_helper): Use access check sentinel.
Hi,
This patch merges the D front-end/run-time library with upstream dmd
d579c467c1, and standard library with phobos 88aa69b14.
D front-end changes:
- Throwing from contracts of `nothrow' functions has been
deprecated, as this breaks the guarantees of `nothrow'.
- Added language
Kyrylo Tkachov writes:
> Hi Andrea,
>
>> -Original Message-
>> From: Gcc-patches > bounces+kyrylo.tkachov=arm@gcc.gnu.org> On Behalf Of Andrea
>> Corallo via Gcc-patches
>> Sent: Friday, August 12, 2022 4:34 PM
>> To: Andrea Corallo via Gcc-patches
>> Cc: Richard Earnshaw ; nd
>>
v1 - > v2:
1. When the macro __loongarch_lp64 is defined, the VTV_PAGE_SIZE is set to 64K.
2. In the vtv_malloc.cc file __vtv_malloc_init function, it does not check
whether VTV_PAGE_SIZE is equal to the system page size, if the macro
__loongarch_lp64 is defined.
All regression tests of
Le 26/09/2022 à 19:24, Aldy Hernandez via Gcc-patches a écrit :
For [0 = x & MASK], we can determine that x is ~MASK.
Suggestion: as AND is a bitwise operator, a X non-zero bit can be
cleared for every bit at which the result is cleared and the MASK is
set, so what you do here can be extended
From: Ju-Zhe Zhong
gcc/ChangeLog:
* config.gcc: Add riscv-vector-builtins.o.
* config/riscv/riscv-builtins.cc (riscv_init_builtins): Add RVV builtin
function.
* config/riscv/riscv-protos.h (riscv_v_ext_enabled_vector_mode_p): New
function.
*
Hi,
On 26.09.22 19:45, Alexander Monakov wrote:
My main concerns remain not addressed:
1) what I said in the opening paragraphs of my previous email;
(i.e. the general disagreement whether the feature itself should be implemented
for nvptx or not.)
2) device-issued atomics are not guaranteed
Hi Andrea,
> -Original Message-
> From: Gcc-patches bounces+kyrylo.tkachov=arm@gcc.gnu.org> On Behalf Of Andrea
> Corallo via Gcc-patches
> Sent: Friday, August 12, 2022 4:42 PM
> To: Andrea Corallo via Gcc-patches
> Cc: Richard Earnshaw ; nd
> Subject: [PATCH 12/15] arm: implement
Hi Andrea,
> -Original Message-
> From: Gcc-patches bounces+kyrylo.tkachov=arm@gcc.gnu.org> On Behalf Of Andrea
> Corallo via Gcc-patches
> Sent: Friday, August 12, 2022 4:40 PM
> To: Andrea Corallo via Gcc-patches
> Cc: Richard Earnshaw ; nd
> Subject: [PATCH 11/15] aarch64: Make
Hi Andrea,
> -Original Message-
> From: Gcc-patches bounces+kyrylo.tkachov=arm@gcc.gnu.org> On Behalf Of Andrea
> Corallo via Gcc-patches
> Sent: Friday, August 12, 2022 4:34 PM
> To: Andrea Corallo via Gcc-patches
> Cc: Richard Earnshaw ; nd
> Subject: [PATCH 9/15] arm: Set again
When setting the nonzero bits to a mask containing only one bit, set
the range immediately, as it can be devined from the mask. This helps
us keep better track of powers of two.
For example, with this patch a nonzero mask of 0x8000 is set to a
range of [0,0][0x8000,0x8000] with a nonzero mask of
Hi!
The following patch is partial support for std::float{16,32,64,128}_t
in libstdc++.
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p1467r9.html
says that , , , and
need changes too, but before doing that, it would be nice to get an
agreement on what macros to use etc.
The support
Just the same way as we have real_value setters for franges, we should
have a wide_int version for irange. This matches the irange
constructor for wide_ints, and paves the way for the eventual
conversion of irange to wide ints.
gcc/ChangeLog:
* value-range.h (irange::set): New version
On Mon, Sep 26, 2022 at 9:54 PM Marek Polacek wrote:
>
> On Mon, Sep 26, 2022 at 12:34:04PM -0400, Jason Merrill wrote:
> > On 9/26/22 03:50, Richard Biener wrote:
> > > On Fri, Sep 23, 2022 at 8:41 PM Marek Polacek via Gcc-patches
> > > wrote:
> > > >
> > > > In
> > > >
On Mon, Sep 26, 2022 at 4:21 PM Robin Dapp wrote:
>
> Hi,
>
> I'm locally testing a branch that enables vll/vstl for partial vector
> usage i.e. len_load and len_store on s390. I see a FAIL in
> testsuite/gfortran.dg/power_3.f90.
> Since r13-1777-gbd9837bc3ca134 we also performe VN for
On 12/09/2022 11.46, Rasmus Villemoes wrote:
> On 29/08/2022 11.29, Rasmus Villemoes wrote:
>> -ffile-prefix-map is supposed to be a superset of -fmacro-prefix-map
>> and -fdebug-prefix-map. However, when building .S or .s files, gas is
>> not called with the appropriate --debug-prefix-map option
On Tue, 27 Sep 2022 03:20:51 +0200
Ahmed Sayed Mousse via Gcc-patches wrote:
> diff --git a/libgomp/Makefile.am b/libgomp/Makefile.am
> index 6d913a93e7f..23f5bede1bf 100644
> --- a/libgomp/Makefile.am
> +++ b/libgomp/Makefile.am
> @@ -94,7 +94,7 @@ libgomp_la_SOURCES = alloc.c atomic.c
v850 and rl78 failed to build newlib with an ICE. I've also got a
report from an ARM automated tester that looks like the same underlying
problem.
Basically we need to check if simple_return and return insns are
available before trying to use them.
Bootstrapped on x86_64 (regression
SARIF support was added in r13-967 but libvtv wasn't updated.
libvtv/ChangeLog:
* testsuite/lib/libvtv-dg.exp: Add load_gcc_lib of scansarif.exp.
---
libvtv/testsuite/lib/libvtv-dg.exp | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libvtv/testsuite/lib/libvtv-dg.exp
75 matches
Mail list logo
