On Jul 22 2023, Andrew Pinski via Gcc-patches wrote:
> The problem -fasynchronous-unwind-tables is on by default for riscv linux
> We need turn it off for crt*.o because it would make __EH_FRAME_BEGIN__ point
> to .eh_frame data from crtbeginT.o instead of the user-defined object
> during static l
Hi Richard,
Bootstrap and regression are passed on X86 and
no new testcases fail on AArch64 with V5 patch:
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625293.html
V5 patch is ok for trunk?
Best,
Lehua
From: Ju-Zhe Zhong
PS: Submitted on behalf of Juzhe Zhong
Hi, Richard and Richi.
This patch support floating-point in-order reduction for loop length control.
Consider this following case:
float foo (float *__restrict a, int n)
{
float result = 1.0;
for (int i = 0; i < n; i++)
result +
OK for trunk, thanks:)
Andrew Pinski via Gcc-patches 於 2023年7月23日 週日
09:07 寫道：
> The problem -fasynchronous-unwind-tables is on by default for riscv linux
> We need turn it off for crt*.o because it would make __EH_FRAME_BEGIN__
> point
> to .eh_frame data from crtbeginT.o instead of the user-de
The problem -fasynchronous-unwind-tables is on by default for aarch64
We need turn it off for crt*.o because it would make __EH_FRAME_BEGIN__ point
to .eh_frame data from crtbeginT.o instead of the user-defined object
during static linking.
This turns it off.
OK? Bootstrapped and tested on aarch6
The problem -fasynchronous-unwind-tables is on by default for riscv linux
We need turn it off for crt*.o because it would make __EH_FRAME_BEGIN__ point
to .eh_frame data from crtbeginT.o instead of the user-defined object
during static linking.
This turns it off.
OK?
libgcc/ChangeLog:
*
This adds a special case of the `(a&~b) | b` pattern where
`b` and `~b` are comparisons.
OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
gcc/ChangeLog:
PR tree-optimization/100864
* match.pd ((~x & y) | x -> x | y): Add comparison variant.
gcc/testsuite/Chan
Fixes: ef85d150b5963 ("RISC-V: Enable TARGET_SUPPORTS_WIDE_INT")
DF +0.0 is bitwise all zeros so int x0 store to mem can be used to optimize it.
void zd(double *) { *d = 0.0; }
currently:
| fmv.d.x fa5,zero
| fsd fa5,0(a0)
| ret
With patch
| sd zero,0(a0)
| ret
The fix updates predi
On 7/21/23 23:05, Jeff Law wrote:
On 7/21/23 12:30, Vineet Gupta wrote:
Fixes: ef85d150b5963 ("RISC-V: Enable TARGET_SUPPORTS_WIDE_INT")
(gcc-13 regression)
DF +0.0 is bitwise all zeros so int x0 store to mem can be used to
optimize it.
void zd(double *) { *d = 0.0; }
currently:
| fmv.d.
The problem is after r14-2587-gd8105b10fff951, the definition of
extended_count now takes a bool as its last argument but we only
have a declaration for the version which takes an int as the last
argument. This fixes the problem by changing the declaration to be
a bool too.
Committed as obvious af
On Sat, Jul 22, 2023 at 4:17 PM Roger Sayle wrote:
>
>
> This patch attempts to help with PR rtl-optimization/110587, a regression
> of -O0 compile time for the pathological pr28071.c. My recent patch helps
> a bit, but hasn't returned -O0 compile-time to where it was before my
> ix86_expand_move
On Sat, Jul 22, 2023 at 5:37 PM Roger Sayle wrote:
>
>
> As suggested by Uros, this patch changes the ZERO_EXTRACTs and SIGN_EXTRACTs
> in i386.md to consistently use QImode for bit offsets (i.e. third and fourth
> operands), matching the use of QImode for bit counts in shifts and rotates.
>
> The
Only run bb-slp-pr95839-v8.c with targets that support vectors of 64
bits, removing regressions with 32-bit x86 targets:
FAIL: gcc.dg/vect/bb-slp-pr95839-v8.c scan-tree-dump slp2 "optimized: basic
block"
FAIL: gcc.dg/vect/bb-slp-pr95839-v8.c -flto -ffat-lto-objects scan-tree-dump
slp2 "optimiz
This patch is my attempt to address the compile-time hog issue
in PR rtl-optimization/110587. Richard Biener's analysis shows that
compilation of pr28071.c with -O0 currently spends ~70% in timer
"LRA non-specific" due to return_regno_p failing to filter a large
number of calls to regno_in_use_p,
Hi Kewen,
This patch breaks bootstrap on powerpc-darwin (which has Altivec, but not VSX)
while building libgfortran.
> On 3 Jul 2023, at 04:19, Kewen.Lin via Gcc-patches
> wrote:
Please see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110776
thanks
Iain
The tester seemed to occasionally ping-pong a compilation failure on the
builtin-bitops-1.c test. I long suspected it was something like length
computations.
I finally got a few minutes to dig into it, and sure enough the blackfin
port was claiming the "ones" operation was 2 bytes when it is
As suggested by Uros, this patch changes the ZERO_EXTRACTs and SIGN_EXTRACTs
in i386.md to consistently use QImode for bit offsets (i.e. third and fourth
operands), matching the use of QImode for bit counts in shifts and rotates.
There's no change in functionality, and the new patterns simply ens
This adds rudimentary lifetime tracking in C++ constexpr contexts,
allowing the compiler to report errors with using values after their
backing has gone out of scope. We don't yet handle other ways of
accessing values outside their lifetime (e.g. following explicit
destructor calls).
PR c+
Currently, when typeck discovers that a return statement will refer to a
local variable it rewrites to return a null pointer. This causes the
error messages for using the return value in a constant expression to be
unhelpful, especially for reference return values, and is also a visible
change to o
This patch updates 'input_location' during constant evaluation to ensure
that errors in subexpressions that lack location information still
provide accurate diagnostics.
By itself this change causes some small regressions in diagnostic
quality for circumstances where errors used 'input_location' b
This is an update of the patch series at
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625050.html
Changes since v4:
- Reordered patches to be more independent from each other (they don't need
to keep updating the new tests)
- Removed workaround for better locations in cxx_eval_store_exp
On Fri, 21 Jul 2023 at 21:05, Benjamin Priour via Gcc-patches
wrote:
>
> Hi,
>
> Upon David's request I've joined the in progress patch to the below email.
> I hope it makes more sense now.
>
> Best,
> Benjamin.
>
> -- Forwarded message -
> From: Benjamin Priour
> Date: Tue, Jul 1
This patch attempts to help with PR rtl-optimization/110587, a regression
of -O0 compile time for the pathological pr28071.c. My recent patch helps
a bit, but hasn't returned -O0 compile-time to where it was before my
ix86_expand_move changes. The obvious solution/workaround is to guard
these ne
On 18/07/2023 08:27, Ken Matsui via Libstdc++ wrote:
This patch implements built-in trait for std::is_arithmetic.
gcc/cp/ChangeLog:
* cp-trait.def: Define __is_arithmetic.
* constraint.cc (diagnose_trait_expr): Handle CPTK_IS_ARITHMETIC.
* semantics.cc (trait_expr_valu
It seems rather logical cause std::disjunction is supposed to avoid
instantiations but in case of:
std::disjunction, std::is_null_pointer<_Tp>>
you'll avoid std::is_null_pointer instantiation only for 'void' type and
at the price of instantiating std::disjunction so 2 instantiations at
best b
On 17/07/2023 06:48, Ken Matsui wrote:
On Sun, Jul 16, 2023 at 5:32 AM François Dumont wrote:
On 15/07/2023 06:55, Ken Matsui via Libstdc++ wrote:
This patch optimizes the performance of the is_arithmetic trait by
dispatching to the new __is_arithmetic built-in trait.
libstdc++-v3/ChangeLo
在 2023/7/20 下午9:28, Xi Ruoyao 写道:
If the host triple and the target triple are different but the host is
LoongArch, in some cases --with-arch=native can be useful. For example,
if we are bootstrapping a loongarch64-linux-musl toolchain on a
Glibc-based system and we don't intend to use the too
27 matches
Mail list logo
