gcc/ChangeLog:
* config/loongarch/loongarch.cc (loongarch_symbolic_constant_p):
Remove the sym+addend form from the SYMBOL_PCREL64 type symbol.
(loongarch_output_mi_thunk): Add code model extreme support.
(loongarch_option_override_internal): Supports option
When cmodel=extreme, since the symbol address is obtained through four
instructions,
errors may occur in some cases during linking. Therefore, in order to ensure
that
the instructions for obtaining the symbol address are together, macro
instructions
are used to obtain the symbol address when
Instructions pcalau12i, addi.d, lu32i.d and lu52i.d must be adjancent so that
the
linker can infer the PC of pcalau12i to apply relocations to lu32i.d and
lu52i.d.
Otherwise, the results would be incorrect if these four instructions are not in
the same 4KiB page.
See the link for details:
Ccmp is not used if the result of the and/ior is used by both
a GIMPLE_COND and a GIMPLE_ASSIGN. This improves the code generation
here by using ccmp in this case.
Two changes is required, first we need to allow the outer statement's
result be used more than once.
The second change is that during
This patch implenments more vec_init optabs that can handle two LSX vectors
producing a LASX
vector by concatenating them. When an lsx vector is concatenated with an LSX
const_vector of
zeroes, the vec_concatz pattern can be used effectively. For example as below
typedef short v8hi
For zero_extendqisi2 and zero_extendqidi2, use andi instead of bstrpick.w,
because andi is 6 times faster than bstrpick.w.
gcc/ChangeLog:
* config/loongarch/loongarch.md:
(zero_extend2): Rename to ..
(zero_extendhi2): .. this, use hi.
(zero_extendqihi2): Rename to
For instruction xvpermi.q, unused bits in operands[3] need be set to 0 to avoid
causing undefined behavior on LA464.
gcc/ChangeLog:
* config/loongarch/lasx.md: Set the unused bits in operand[3] to 0.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/vector/lasx/lasx-xvpremi.c:
LEON now uses the standard V8 membar patterns that contains an ldstub
instruction. This instruction needs to be aligned properly when the
GR712RC errata workaround is enabled.
gcc/ChangeLog:
* config/sparc/sparc.cc (atomic_insn_for_leon3_p): Treat
membar_storeload as atomic
*
This is to handle the membar_empty instruction that can be generated
when compiling for UT699.
gcc/ChangeLog:
* config/sparc/sparc.cc (next_active_non_empty_insn): Length 0 treated
as empty
---
gcc/config/sparc/sparc.cc | 1 +
1 file changed, 1 insertion(+)
diff --git
From: Andreas Larsson
LEON5 has a deeper write-buffer and hence stb is not enough to flush a
write out. For compatibility, use the default V8 approach for both
LEON3 and LEON5.
This reverts commit 49cc765db35a5a21cab2aece27a44983fa70b94b,
"sync.md (*membar_storeload_leon3): New insn."
pr88077 fails on SPARC since char HeaderStr[1] in pr88077_1.c and
long HeaderStr in pr88077_0.c differs in alignment.
warning: alignment 4 of normal symbol `HeaderStr' in c_lto_pr88077_0.o is
smaller than 8 used by the common definition in c_lto_pr88077_1.o
gcc/testsuite/ChangeLog:
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113240
--- Comment #6 from Kito Cheng ---
> There needs to be a -Wabi warning for this too for the change between
> versions.
This bug only happened on trunk, and GCC 13 is OK, so I think it's not the
case?
Target features constants from loongarch-def.h are currently defined as macros.
Switch to enums for better look in the debugger.
gcc/ChangeLog:
* config/loongarch/loongarch-def.h: Define constants with
enums instead of Macros.
---
gcc/config/loongarch/loongarch-def.h | 115
This patchset performs some code cleanup, and is bootstrapped and regtested
on loongarch64-linux-gnu.
Yang Yujie (4):
LoongArch: Handle ISA evolution switches along with other options
LoongArch: Rename ISA_BASE_LA64V100 to ISA_BASE_LA64
LoongArch: Use enums for constants
LoongArch:
Since we do not need printing or manual parsing of this option,
(whether in the driver or for target attributes to be supported later)
it can be handled in the .opt file framework.
gcc/ChangeLog:
* config/loongarch/genopts/loongarch-strings: Remove explicit-reloc
argument string
LoongArch ISA manual v1.10 suggests that software should not depend on
the ISA version number for marking processor features. The ISA version
number is now defined as a collective name of individual ISA evolutions.
Since there is a independent ISA evolution mask now, we can drop the
version
gcc/ChangeLog:
* config/loongarch/genopts/genstr.sh: Prepend the isa_evolution
variable with the common la_ prefix.
* config/loongarch/genopts/loongarch.opt.in: Mark ISA evolution
flags as saved using TargetVariable.
* config/loongarch/loongarch.opt: Same.
Yes, as Juzhe said I had run all the riscv regression, but without RTL check.
I will fix it.
Sorry for forgetting to enable RTL checking for testing.
Thanks Juzhe for helping me reverse this commit.
From: juzhe.zh...@rivai.ai
Date: 2024-01-05 11:28
To: palmer
CC: gcc-patches; kito.cheng;
- Change the default vectorization "-mlasx" option to "-mlsx" because there
are many non-aligned memory accesses when using 256-bit vectorization.
- The following detection procedure is added to the target-supports.exp file:
1.check_effective_target_scalar_all_fma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113193
Oleg Endo changed:
What|Removed |Added
Known to fail||13.2.1
Version|14.0
From: Liwei Xu
This patch optimize byte swaps in vectors using SSE2 instructions.
It targets 8-byte and 16-byte vectors, efficiently handling patterns like
__builtin_shufflevector(v, v, 1, 0, 3, 2, ...).
PR target/107563
gcc/ChangeLog:
* config/i386/i386-expand.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113240
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-01-05
While working on fixing a bug, I notice this following code has redundant move:
#include "riscv_vector.h"
void
f (float x, float y, void *out)
{
float f[4] = { x, x, x, y };
vfloat32m1_t v = __riscv_vle32_v_f32m1 (f, 4);
__riscv_vse32_v_f32m1 (out, v, 4);
}
Before this patch:
f:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113240
--- Comment #4 from Lehua Ding ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Lehua Ding from comment #2)
> > (In reply to Andrew Pinski from comment #1)
> > > There needs to be a -Wabi warning for this too for the change
In the LoongArch architecture, the reason for not adding the 128-bit
vector-width-*hi* instruction template in the GCC back end is that it causes
program performance loss, so we can only add the "-mlasx" compilation option
to use 256-bit vectorization functions in test files.
When binutils does not support vector instruction sets, the test program fails
because it does not recognize vectorization at the assembly stage. Therefore,
the default run behavior of the program is deleted, so that the behavior of
the program depends on whether the software supports
On the LoongArch architecture, an error was found in the
bind_c_array_params_2.f90 file because there was no proper assembly code
for the regular expression detection function call, such as bl %plt(myBindC).
gcc/testsuite/ChangeLog:
* gfortran.dg/bind_c_array_params_2.f90: Add code test
gcc/testsuite/ChangeLog:
* gcc.dg/vect/vect-82.c: Add the LoongArch architecture to the
object detection framework.
* gcc.dg/vect/vect-83.c: Dito.
---
gcc/testsuite/gcc.dg/vect/vect-82.c | 2 +-
gcc/testsuite/gcc.dg/vect/vect-83.c | 2 +-
2 files changed, 2 insertions(+),
In the GCC of LoongArch architecture, the detection function of common
vectorization test cases is enabled. The following detection procedure
is added to the target-supports.exp file:
1.check_effective_target_scalar_all_fma
2.check_effective_target_vect_int
On the LoongArch architecture, the above four test cases need to be waived
during testing. There are two situations:
1. The function of fma-{3,6}.c test is to find the value of c-a*b, but on
the LoongArch architecture, the function of the existing fnmsub instruction
is to find the value of -(a*b
Before modifying the test behavior of the program, dg-do is set to assemble in
vect-bic-bitmask-{12,23}.c. However, when the binutils library does not support
the vector instruction set, it will FAIL to recognize the vector instruction
and fail item will appear in the assembly stage. So set the
v1->v2:
On the basis of v1, the reason of the analysis problem is described in detail.
When using binutils, which does not support vectorization, and the gcc compiler
toolchain, which does support vectorization, the following two types of error
problems occur in gcc regression testing.
gcc/ChangeLog:
* config/loongarch/loongarch.cc (loongarch_symbolic_constant_p):
Remove the sym+addend form from the SYMBOL_PCREL64 type symbol.
(loongarch_output_mi_thunk): Add code model extreme support.
(loongarch_option_override_internal): Supports option
Instructions pcalau12i, addi.d, lu32i.d and lu52i.d must be adjancent so that
the
linker can infer the PC of pcalau12i to apply relocations to lu32i.d and
lu52i.d.
Otherwise, the results would be incorrect if these four instructions are not in
the same 4KiB page.
See the link for details:
When cmodel=extreme, since the symbol address is obtained through four
instructions,
errors may occur in some cases during linking. Therefore, in order to ensure
that
the instructions for obtaining the symbol address are together, macro
instructions
are used to obtain the symbol address when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113240
--- Comment #3 from Andrew Pinski ---
(In reply to Lehua Ding from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > There needs to be a -Wabi warning for this too for the change between
> > versions.
>
> I'm more inclined to think
I have reverted those 2 commits:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=960c2620db254a1edc2cd61e608df73073b3de0d
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=b3ec98d458f2b285bb7b3fa4fcd93fd830fee069
juzhe.zh...@rivai.ai
From: Palmer Dabbelt
Date: 2024-01-05 11:24
To: juzhe.zhong
We (me and kito) has reviewed vector-crypto.
I believe Wang Feng has done && passed the regression (with no RTL check), but
he just didn't enable RTL check I guessed.
(By default, RTL check is disabled in riscv-gnu-toolchain, developers need to
enable it manually).
It's ok to revert the patch,
On Thu, 04 Jan 2024 19:17:21 PST (-0800), juzhe.zh...@rivai.ai wrote:
Hi, Wang Feng.
Your patch has some ICEs:
FAIL: gcc.target/riscv/rvv/base/zvbc-intrinsic.c (internal compiler error: RTL
check: expected code 'const_int', have 'reg' in vlmax_avl_type_p, at
config/riscv/riscv-v.cc:4930)
Hi, Wang Feng.
Your patch has some ICEs:
FAIL: gcc.target/riscv/rvv/base/zvbc-intrinsic.c (internal compiler error: RTL
check: expected code 'const_int', have 'reg' in vlmax_avl_type_p, at
config/riscv/riscv-v.cc:4930)
FAIL: gcc.target/riscv/rvv/base/zvbc-intrinsic.c (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113240
--- Comment #2 from Lehua Ding ---
(In reply to Andrew Pinski from comment #1)
> There needs to be a -Wabi warning for this too for the change between
> versions.
I'm more inclined to think of it as a bug, since the vector ABI specification
is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112783
Jiang ChuanGang changed:
What|Removed |Added
CC||jiangchuanganghw at outlook
dot co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113240
Andrew Pinski changed:
What|Removed |Added
Keywords||diagnostic
--- Comment #1 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113240
Bug ID: 113240
Summary: Use wrong rule to pass fixed-length(size<=2*XLEN)
vector argument
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Hans-Peter Nilsson wrote:
On Wed, 3 Jan 2024, Jacob Bachmeyer wrote:
Comments before I start on an implementation?
I'd suggest to await the conclusion of the debate: I *think*
I've proved that dg-timeout-factor is already active as intended
(all parts of a test), specifically when
On 1/4/24 18:02, Nathaniel Shead wrote:
On Thu, Jan 04, 2024 at 05:42:34PM -0500, Jason Merrill wrote:
On 1/4/24 17:24, Nathaniel Shead wrote:
On Thu, Jan 04, 2024 at 03:31:50PM -0500, Jason Merrill wrote:
On 1/2/24 17:40, Nathaniel Shead wrote:
Static data members marked 'inline' should be
1). We not only have vashl_optab,vashr_optab,vlshr_optab which vectorize shift
with vector shift amount,
that is, vectorization of 'a[i] >> x[i]', the shift amount is loop variant.
2). But also, we have ashl_optab, ashr_optab, lshr_optab which can vectorize
shift with scalar shift amount,
that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113233
--- Comment #6 from Yang Yujie ---
(In reply to Xi Ruoyao from comment #4)
> (In reply to Jan Hubicka from comment #3)
> > > Confirm. But option save/restore has been always implemented:
> > >
> > > .section.gnu.lto_.opts,"",@progbits
This patch try to fix the bug when HAVE_ATOMIC_FETCH_ADD is
not defined in dec_waiting_unlocked function. As io.h does
not include async.h, the WRLOCK and RWUNLOCK macros are
undefined.
libgfortran/ChangeLog:
* io/io.h (dec_waiting_unlocked): Use
This patch add crypto vector api-testing cases based on
https://github.com/riscv-non-isa/rvv-intrinsic-doc/blob/eopc/vector-crypto/auto-generated/vector-crypto
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/zvbb-intrinsic.c: New test.
*
This patch add the intrinsic funtions of crypto vector based on the
intrinsic doc(https://github.com/riscv-non-isa/rvv-intrinsic-doc/blob
/eopc/vector-crypto/auto-generated/vector-crypto/intrinsic_funcs.md).
Co-Authored by: Songhe Zhu
Co-Authored by: Ciyan Pan
gcc/ChangeLog:
*
On Thu, Jan 4, 2024 at 2:11 PM Jonathan Wakely wrote:
>
> On Sat, 23 Dec 2023 at 23:06, Ken Matsui wrote:
> >
> > This patch uses _GLIBCXX_USE_BUILTIN_TRAIT macro instead of __has_builtin
> > in the type_traits header for traits that have a corresponding fallback
> > non-built-in implementation.
On 1/4/24 02:11, Jakub Jelinek wrote:
Hi!
We expand __builtin_popcount* (x) == 1 as
x ^ (x - 1) > x - 1, either unconditionally in tree-ssa-math-opts.cc
if we don't have a direct optab support for popcount, or during
expansion where we compare the costs of comparison of the popcount
against
On Thu, Jan 04, 2024 at 05:42:34PM -0500, Jason Merrill wrote:
> On 1/4/24 17:24, Nathaniel Shead wrote:
> > On Thu, Jan 04, 2024 at 03:31:50PM -0500, Jason Merrill wrote:
> > > On 1/2/24 17:40, Nathaniel Shead wrote:
> > > > Static data members marked 'inline' should be emitted in TUs where they
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86152
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |12.0
Resolution|---
On 1/4/24 17:24, Nathaniel Shead wrote:
On Thu, Jan 04, 2024 at 03:31:50PM -0500, Jason Merrill wrote:
On 1/2/24 17:40, Nathaniel Shead wrote:
Static data members marked 'inline' should be emitted in TUs where they
are ODR-used. We need to make sure that statics imported from modules
are
Snapshot gcc-11-20240104 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/11-20240104/
and on various mirrors, see https://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 11 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
On Thu, 2024-01-04 at 14:32 -0800, Palmer Dabbelt wrote:
> > +proc check_effective_target_ifn_copysign { } {
> > + return [check_cached_effective_target_indexed ifn_copysign {
> > + expr {
> > +(([istarget i?86-*-*] || [istarget x86_64-*-*])
> > + && [is-effective-target sse])
> >
Am 03.01.2024 um 00:12 schrieb Björn Schäpers:
Am 30.11.2023 um 20:53 schrieb Ian Lance Taylor:
On Fri, Jan 20, 2023 at 2:55 AM Björn Schäpers wrote:
From: Björn Schäpers
Fixes https://github.com/ianlancetaylor/libbacktrace/issues/53, except
that libraries loaded after the
Am 03.01.2024 um 00:12 schrieb Björn Schäpers:
Am 30.11.2023 um 20:53 schrieb Ian Lance Taylor:
On Fri, Jan 20, 2023 at 2:55 AM Björn Schäpers wrote:
From: Björn Schäpers
Fixes https://github.com/ianlancetaylor/libbacktrace/issues/53, except
that libraries loaded after the
On Thu, 04 Jan 2024 10:20:25 PST (-0800), tamar.christ...@arm.com wrote:
> Hi All,
>
> currently GCC does not treat IFN_COPYSIGN the same as the copysign tree expr.
> The latter has a libcall fallback and the IFN can only do optabs.
>
> Because of this the change I made to optimize copysign only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113087
--- Comment #28 from JuzheZhong ---
(In reply to Patrick O'Neill from comment #27)
> Linking the discussion/plan here since more interested people are CCd here.
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113206#c9
> Using
On Thu, Jan 04, 2024 at 03:31:50PM -0500, Jason Merrill wrote:
> On 1/2/24 17:40, Nathaniel Shead wrote:
> > Static data members marked 'inline' should be emitted in TUs where they
> > are ODR-used. We need to make sure that statics imported from modules
> > are correctly added to the
On Thu, 4 Jan 2024, Patrick Palka wrote:
> On Sat, 23 Dec 2023, Ken Matsui wrote:
>
> > This patch optimizes the compilation performance of std::is_pointer
> > by dispatching to the new __is_pointer built-in trait.
> >
> > libstdc++-v3/ChangeLog:
> >
> > * include/bits/cpp_type_traits.h
On Sat, 23 Dec 2023 at 22:07, Ken Matsui wrote:
>
> This patch optimizes the compilation performance of std::is_pointer
> by dispatching to the new __is_pointer built-in trait.
>
> libstdc++-v3/ChangeLog:
>
> * include/bits/cpp_type_traits.h (__is_pointer): Use
> __is_pointer
On Sat, 23 Dec 2023 at 23:06, Ken Matsui wrote:
>
> This patch uses _GLIBCXX_USE_BUILTIN_TRAIT macro instead of __has_builtin
> in the type_traits header for traits that have a corresponding fallback
> non-built-in implementation. This macro supports to toggle the use of
> built-in traits in the
On Sat, 23 Dec 2023, Ken Matsui wrote:
> This patch optimizes the compilation performance of std::is_pointer
> by dispatching to the new __is_pointer built-in trait.
>
> libstdc++-v3/ChangeLog:
>
> * include/bits/cpp_type_traits.h (__is_pointer): Use
> __is_pointer built-in trait.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113156
Paul M. Bendixen changed:
What|Removed |Added
CC||paulbendixen at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86152
Hannes Domani changed:
What|Removed |Added
CC||ssbssa at yahoo dot de
--- Comment #1
On Sat, 23 Dec 2023, Ken Matsui wrote:
> This patch uses _GLIBCXX_USE_BUILTIN_TRAIT macro instead of __has_builtin
> in the type_traits header for traits that have a corresponding fallback
> non-built-in implementation. This macro supports to toggle the use of
> built-in traits in the
On 1/4/24 02:34, Jakub Jelinek wrote:
Hi!
The following testcase ICEs when rslt is SSA_NAME_OCCURS_IN_ABNORMAL_PHI
and we call replace_uses_by with a INTEGER_CST def, where it ICEs on:
if (e->flags & EDGE_ABNORMAL
&& !SSA_NAME_OCCURS_IN_ABNORMAL_PHI (val))
On 1/4/24 02:23, Mikael Pettersson wrote:
emit_library_call_value_1 calls emit_push_insn with NULL_TREE
for TYPE. Sometimes emit_push_insn needs to assign a temp with
that TYPE, which causes a segfault.
Fixed by computing the TYPE from MODE when needed.
Original patch by Thorsten Otto.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113239
--- Comment #1 from Andrew Pinski ---
So I suspect it is either inlining differences due to slightly increased sizes
in some cases or jump threading due to the extra check. I highly doubt that
patch is underlying cause of the warning ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113186
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113186
--- Comment #5 from GCC Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:97def769e6b28832f5ba4087d6fcdd44e18bf005
commit r14-6927-g97def769e6b28832f5ba4087d6fcdd44e18bf005
Author: Andrew Pinski
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113238
Andrew Pinski changed:
What|Removed |Added
CC||pinskia at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113239
Bug ID: 113239
Summary: [13 regression] After 822a11a1e64, bogus
-Warray-bounds warnings in std::vector
Product: gcc
Version: 14.0
Status: UNCONFIRMED
I have successfully bootstrapped and regtested the patch on loongarch64-
linux-gnu. The test cases in the patch (intended for RISC-V) also works
on LoongArch per my manual testing.
On Mon, 2024-01-01 at 14:04 -0700, Jeff Law wrote:
> I know we're deep into stage3 and about to transition to
On Sun, 3 Dec 2023, Nathaniel Shead wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
>
> -- >8 --
>
> The TYPE_DECL_SUPPRESS_DEBUG and DECL_EXTERNAL flags use the same
> underlying bit. This is causing confusion when attempting to determine
> the interface for a
On 1/2/24 17:40, Nathaniel Shead wrote:
Static data members marked 'inline' should be emitted in TUs where they
are ODR-used. We need to make sure that statics imported from modules
are correctly added to the 'pending_statics' map so that they get
emitted if needed, otherwise the attached
On 1/4/24 06:36, Stefan Schulze Frielinghaus wrote:
I have successfully bootstrapped and regtested the patch on s390. Out
of curiosity I also ran some benchmarks which didn't show much changes
except in one case which I will have to analyze further. If there is
anything interesting I will
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113238
--- Comment #1 from Edwin Lu ---
Debug log for one of the flakey tests
spawn -ignore SIGHUP
/github/patrick-postcommit-runner-2/_work/gcc-postcommit-ci/gcc-postcommit-ci/riscv-gnu-toolchain/build/build-gcc-linux-stage2/gcc/xgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113238
Bug ID: 113238
Summary: [14] RISC-V: gcc.dg vect-tsvc flakey test timeouts
when under heavy workload
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
Hello, How are you today?
I need assistance filing my taxes for 2023. I found you through the CPA online
search. Normally, I use TurboTax to file my taxes, but since I bought my third
house and sold large quantities of stocks last year, I want to make sure I'm
accounting for everything
On 12/31/23 21:03, Andrew Pinski wrote:
For boolean types, `a ^ b` is a valid form for `a != b`. This means for
gimple_bitwise_inverted_equal_p, we catch some inverted value forms. This
patch extends inverted_equal_p to allow matching of `^` with the
corresponding `==`. Note in the testcase
On 1/2/24 12:41, Ilya Leoshkevich wrote:
gccint recommends using ASM_OUTPUT_FUNCTION_LABEL in
ASM_DECLARE_FUNCTION_NAME, but many implementations use
ASM_OUTPUT_LABEL instead. It's inconsistent and prevents changes to
ASM_OUTPUT_FUNCTION_LABEL from affecting the respective targets.
---
On Wed, 3 Jan 2024, Nathaniel Shead wrote:
> Linaro CI tells me that this patch caused regressions on ARM. I don't
> have an ARM machine available to test on, but it appears to have been
> caused by attempting to stream vtables as static data members, and ARM
> having different behaviour with
On Thu, Jan 4, 2024 at 5:51 AM Radek Barton wrote:
>
> Hello, everyone.
>
>
> Our "Arm64 on Windows Ecosystem" team is currently working on adding
> aarch64-w64-mingw32 target and we've noticed that recent commit adding SME
> support
libstdc++-v3/ChangeLog:
* include/std/generator (_Stateless_alloc): Rename typename _A
to _All.
---
Pushed as obvious.
Happy new year, have a lovely day!
libstdc++-v3/include/std/generator | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107436
--- Comment #8 from Florian Schanda ---
I am no longer working at BMW.
For safety topics please contact alexander.schem...@bmw.de or
markus.schur...@bmw.de
For TRLC and LOBSTER topics please contact philipp.wullstein-kamm...@bmw.de or
create
libstdc++-v3/ChangeLog:
* include/std/generator (_Subyield_state::_M_jump_in): Fix typo
reported by Will Hawkins .
---
libstdc++-v3/include/std/generator | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libstdc++-v3/include/std/generator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113237
Tamar Christina changed:
What|Removed |Added
Priority|P3 |P1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113223
--- Comment #4 from kargl at gcc dot gnu.org ---
(In reply to Jerry DeLisle from comment #3)
> Created attachment 56990 [details]
> Suggested patch including affected test cases
>
> Regression tested OK. Three test cases affected.
>
Thanks,
Hi All,
currently GCC does not treat IFN_COPYSIGN the same as the copysign tree expr.
The latter has a libcall fallback and the IFN can only do optabs.
Because of this the change I made to optimize copysign only works if the
target has impemented the optab, but it should work for those that have
On Wed, 3 Jan 2024, Nathaniel Shead wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
>
> -- >8 --
>
> The attached testcase Patrick found in PR c++/112899 ICEs because it is
> attempting to write a variable initializer that is no longer in the
> static_aggregates map.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113237
--- Comment #2 from Tamar Christina ---
Ah wait, I see. Ok, taking a look.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113237
--- Comment #1 from Tamar Christina ---
> I have bisected the failure to r14-6822-g01f4251b8775c8 (middle-end: Support
> vectorization of loops with multiple exits). I have tried if the patch
> attached to PR 113137 helps but unfortunately it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113226
--- Comment #3 from Hans-Peter Nilsson ---
(In reply to Patrick Palka from comment #1)
> Huh, how bizarre.
Indeed. I'm *not* ruling out an actual gcc bug. Whether in the target or
middle-end this time I dare not guess; too few posts.
JFTR;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113237
Andrew Pinski changed:
What|Removed |Added
CC||pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113237
Bug ID: 113237
Summary: [14 Regression] ICE verify_ssa failed when building
500.perlbench_r since r14-6822-g01f4251b8775c8
Product: gcc
Version: 14.0
Status:
1 - 100 of 225 matches
Mail list logo
