https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104928
--- Comment #2 from Nate Eldredge ---
This bug is still present. Tested and reproduced with g++ 13.1.0 (Ubuntu
package), and by inspection of the source code, it's still in the trunk as
well.
Encountered on StackOverflow:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112936
--- Comment #2 from Xi Ruoyao ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2023-December/640012.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112936
Xi Ruoyao changed:
What|Removed |Added
Keywords||patch
URL|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111867
--- Comment #8 from Andrew Pinski ---
Created attachment 56842
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56842=edit
Patch which I will be submitting soon
On 2023/12/9 23:23, Jakub Jelinek wrote:
> On Sat, Dec 09, 2023 at 10:39:45AM -0500, Lipeng Zhu wrote:
> > This patch try to introduce the rwlock and split the read/write to
> > unit_root tree and unit_cache with rwlock instead of the mutex to
> > increase CPU efficiency. In the get_gfc_unit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111876
Andrew Pinski changed:
What|Removed |Added
Component|target |middle-end
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112942
--- Comment #4 from Andrew Pinski ---
(In reply to Artem Koton from comment #3)
> (In reply to Andrew Pinski from comment #1)
> > https://wg21.cmeerw.net/lwg/issue2749
>
> Could you elaborate? I understand that this issue discusses the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112942
--- Comment #3 from Artem Koton ---
(In reply to Andrew Pinski from comment #1)
> https://wg21.cmeerw.net/lwg/issue2749
Could you elaborate? I understand that this issue discusses the constraints in
question but a failure to meet them should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112942
--- Comment #2 from Andrew Pinski ---
https://gcc.gnu.org/pipermail/libstdc++/2016-November/045176.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112942
--- Comment #1 from Andrew Pinski ---
https://wg21.cmeerw.net/lwg/issue2749
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112942
Bug ID: 112942
Summary: swap(variant&, variant&) is incorrectly marked as
deleted
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111867
Andrew Pinski changed:
What|Removed |Added
Keywords||testsuite-fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112941
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112940
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
In the Linux kernel, u64/s64 are [un]signed long long, not [un]signed
long. This means that when the `arm_neon.h' header is used by the
kernel, any use of the `uint64_t' / `in64_t' types needs to be
correctly cast to the correct `__builtin_aarch64_simd_di' /
`__builtin_aarch64_simd_df' types when
Snapshot gcc-13-20231209 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/13-20231209/
and on various mirrors, see https://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 13 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112758
--- Comment #11 from Eric Botcazou ---
> It says those upper bits are well-defined, i.e. whatever MD pattern is used
> for it eventually will emit machine code that has the exact same result for
> those upper bits.
No, that's not true, the set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109162
Bug 109162 depends on bug 111826, which changed state.
Bug 111826 Summary: __cpp_lib_format should be 202110, not 202106
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111826
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111826
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111826
--- Comment #2 from GCC Commits ---
The releases/gcc-13 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:9f5011f9e6e347e0b91f47a118a0ce58a2c2d99a
commit r13-8140-g9f5011f9e6e347e0b91f47a118a0ce58a2c2d99a
Author: Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112935
--- Comment #19 from Andrew Pinski ---
This patch gets us back to using `&-` rather than shifts/adds for x86_64:
```
diff --git a/gcc/expr.cc b/gcc/expr.cc
index 6da51f2aca2..4686cacd22f 100644
--- a/gcc/expr.cc
+++ b/gcc/expr.cc
@@ -10209,8
I've reimplemented the .debug_names code in GDB -- it was quite far
from being correct, and the new implementation is much closer to what
is specified by DWARF.
However, the new writer in GDB needs to emit some symbol properties,
so that the reader can be fully functional. This patch adds a few
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112887
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On 11/24/23 13:09, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
OK.
-- >8 --
A rewritten guide for alias CTAD isn't really a specialization of the
original guide, so we shouldn't register it as such. This avoids an ICE
in the below
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112887
--- Comment #4 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:c250ff90989a71dff11e9256e99d2fa965ab1295
commit r14-6360-gc250ff90989a71dff11e9256e99d2fa965ab1295
Author: Jakub Jelinek
Date:
On 11/27/23 06:07, Nathaniel Shead wrote:
Ping for https://gcc.gnu.org/pipermail/gcc-patches/2023-October/634626.html.
I've been made aware since constructing this patch of CWG2820, which has
a proposed resolution that would change the result of the testcase
'noexcept(yesthrow_t())' (and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112877
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112938
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
On 11/2/23 21:18, Nathaniel Shead wrote:
Bootstrapped and regtested on x86-64_pc_linux_gnu.
I'm not entirely sure if the change I made to have destructors clobber with
CLOBBER_EOL instead of CLOBBER_UNDEF is appropriate, but nothing seemed to have
broken by doing this and I wasn't able to find
> Am 09.12.2023 um 10:35 schrieb Jakub Jelinek :
>
> Hi!
>
> This function is never called when param_l1_cache_line_size is 0,
> but it uses int and unsigned int variables to hold alignment in
> bits, so for large param_l1_cache_line_size it is zero and e.g.
> DECL_ALIGN () %
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112939
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Target Milestone|---
I revised version which fixes a problem with breaking other
callers of finish_rust. Please ignore the previous one.
Bootstrapped and regression tested on x86_64
Fix regression causing ICE for structs with VLAs [PR 112488]
A previous patch the fixed several ICEs related to size expressions
of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112758
--- Comment #10 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #6)
> I must say I have no idea what WORD_REGISTER_OPERATION says about the upper
> bits of a paradoxical SUBREG if it is a MEM and load_extend_op (inner_mode)
Andrew Carlotti writes:
> For native cpu feature detection, certain features have no entry in
> /proc/cpuinfo, so have to be assumed to be present whenever the detected
> cpu is supposed to support that feature.
>
> However, the logic for this was mistakenly implemented by excluding
> these
Andrew Carlotti writes:
> Additionally, replace all checks for the AARCH64_FL_CRYPTO bit with
> checks for (AARCH64_FL_AES | AARCH64_FL_SHA2) instead. The value of the
> AARCH64_FL_CRYPTO bit within isa_flags is now ignored, but it is
> retained because removing it would make processing the data
Andrew Carlotti writes:
> Ok for master?
>
> gcc/ChangeLog:
>
> * config/aarch64/x-aarch64: Add missing dependencies.
>
>
> diff --git a/gcc/config/aarch64/x-aarch64 b/gcc/config/aarch64/x-aarch64
> index
> 3cf701a0a01ab00eaaafdfad14bd90ebbb1d498f..6fd638faaab7cb5bb2309d36d6dea2adf1fb8d32
Sorry for the slow review.
Stamatis Markianos-Wright writes:
> [...]
> diff --git a/gcc/config/arm/mve.md b/gcc/config/arm/mve.md
> index
> 44a04b86cb5806fcf50917826512fd203d42106c..c083f965fa9a40781bc86beb6e63654afd14eac4
> 100644
> --- a/gcc/config/arm/mve.md
> +++ b/gcc/config/arm/mve.md
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112876
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112876
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112786
Hans-Peter Nilsson changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96831
Bug 96831 depends on bug 112786, which changed state.
Bug 112786 Summary: [14 Regression] gcc.dg/tree-ssa/scev-3.c scev-4.c and
scev-5.c XPASSing on most ilp32 targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112786
What
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112919
--- Comment #2 from Xi Ruoyao ---
On LA464:
13095 with GCC 13.2.0
The best I've got is:
12639 with GCC 14.0.0 + -falign-loops=8 -falign-labels=4 -falign-jumps=4
-falign-functions=16
and I cannot really explain why this is the best.
With
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112930
Richard Sandiford changed:
What|Removed |Added
Last reconfirmed||2023-12-09
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112931
Richard Sandiford changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112933
Richard Sandiford changed:
What|Removed |Added
Last reconfirmed||2023-12-09
Following the instruction cost fix, we are generating
alsl.w $a0, $a0, $a0, 4
instead of
li.w $t0, 17
mul.w $a0, $t0
for "x * 4", because alsl.w is 4 times faster than mul.w. But we didn't
have a sign-extending pattern for alsl.w, causing an extra slli.w
instruction generated to
With loongarch-def.cc switched from C to C++, we can include rtl.h for
COSTS_N_INSNS, instead of hard coding our own.
THis is a non-functional change for now, but it will make the code more
future-proof in case COSTS_N_INSNS in rtl.h would be changed.
gcc/ChangeLog:
*
Replace the instruction costs in loongarch_rtx_cost_data constructor
based on micro-benchmark results on LA464 and LA664.
This allows optimizations like "x * 17" to alsl, and "x * 68" to alsl
and slli.
gcc/ChangeLog:
PR target/112936
* config/loongarch/loongarch-def.cc
Update LoongArch instruction costs based on the micro-benchmark results
on LA464 and LA664. In particular, this allows generating alsl/slli or
alsl/slli + add pairs for multiplying some constants as on LA464/LA664
a mul instruction is 4x slower than alsl, slli, or add instructions.
Bootstrapped
We are excluding loongarch-opts.h from target libraries, but now struct
loongarch_target and gcc_options are not declared in the target
libraries, causing:
In file included from ../.././gcc/options.h:8,
from ../.././gcc/tm.h:49,
from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112827
Jakub Jelinek changed:
What|Removed |Added
CC||csfore at posteo dot net
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112924
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Sat, Dec 09, 2023 at 10:39:45AM -0500, Lipeng Zhu wrote:
> This patch try to introduce the rwlock and split the read/write to
> unit_root tree and unit_cache with rwlock instead of the mutex to
> increase CPU efficiency. In the get_gfc_unit function, the percentage
> to step into the
This patch try to introduce the rwlock and split the read/write to
unit_root tree and unit_cache with rwlock instead of the mutex to
increase CPU efficiency. In the get_gfc_unit function, the percentage
to step into the insert_unit function is around 30%, in most instances,
we can get the unit in
On Sat, Dec 09, 2023 at 12:19:10PM +0100, Thomas Schwinge wrote:
> > --- a/gcc/omp-builtins.def
> > +++ b/gcc/omp-builtins.def
> > @@ -467,6 +467,9 @@ DEF_GOMP_BUILTIN
> > (BUILT_IN_GOMP_WORKSHARE_TASK_REDUCTION_UNREGISTER,
> > DEF_GOMP_BUILTIN (BUILT_IN_GOMP_ALLOC,
> >
On 2023/12/8 18:19, Jakub Jelinek wrote:
> On Fri, Aug 18, 2023 at 11:18:19AM +0800, Zhu, Lipeng wrote:
> > From: Lipeng Zhu
> >
> > This patch try to introduce the rwlock and split the read/write to
> > unit_root tree and unit_cache with rwlock instead of the mutex to
> > increase CPU
Hi!
This testcase got fixed with
r14-6132-g50f2a3370d177f8fe9bea0461feb710523e048a2 .
I'm just adding a testcase so that it doesn't reappear.
Tested on x86_64-linux, with -m32/-m64, current trunk as well as r14-6131
where it ICEd with -m32, committed to trunk as obvious.
2023-12-09 Jakub
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112924
--- Comment #4 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:af8bbd631f5425e9be084dfd1f2b9487a31a350e
commit r14-6359-gaf8bbd631f5425e9be084dfd1f2b9487a31a350e
Author: Jakub Jelinek
Date:
rap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231209 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112924
Jakub Jelinek changed:
What|Removed |Added
Keywords|needs-bisection |
CC|
4-6356-20231209102837-g36be2a0e91c-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231209 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112929
--- Comment #10 from JuzheZhong ---
OK. It seems it is VSETVL BUG. I will have look at it.
I didn't use any special configuration:
--with-arch=rv64gcv_zvl256b --with-abi=lp64d --test --jobs=64 --with-sim=qemu
--enable-gcc-checking=yes,assert,extra,rtlflag,rtl,gimple
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-12-09 22:07
To: 钟居哲; gcc-patches; palmer; kito.cheng; Jeff Law
CC:
Tested x86_64-linux. Pushed to trunk.
I'll check, but I think should be backported to gcc-13 too.
-- >8 --
As noted in the PR, we support both features required for the 202110L
value, so we should define it with that value.
libstdc++-v3/ChangeLog:
PR libstdc++/111826
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111826
--- Comment #1 from GCC Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:cdf45e00a936a76a785c592c9730f24ef1ac25cd
commit r14-6358-gcdf45e00a936a76a785c592c9730f24ef1ac25cd
Author: Jonathan Wakely
> rv64gcv
With -minline-strcmp I assume?
Regards
Robin
Tested x86_64-linux. Pushed to trunk.
-- >8 --
What I implemented in r14-6199-g45630fbcf7875b does not match what I
proposed for LWG 4016, and it imposes additional, unwanted requirements
on the emplace and insert member functions of the container being
populated.
libstdc++-v3/ChangeLog:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112876
--- Comment #5 from GCC Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:a314edee2490259d7f7caec8eef77846bcdb608b
commit r14-6357-ga314edee2490259d7f7caec8eef77846bcdb608b
Author: Jonathan Wakely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112929
--- Comment #9 from Robin Dapp ---
In the good version the length is 32 here because directly before the vsetvl we
have:
li a4,32
That seems to get lost somehow.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112929
--- Comment #8 from JuzheZhong ---
Li Pan will investigate it. He will note me if there is a bug in vsetvl pass.
rv64gcv
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-12-09 21:51
To: 钟居哲; gcc-patches; palmer; kito.cheng; Jeff Law
CC: rdapp.gcc
Subject: Re: [PATCH] RISC-V: Add vectorized strcmp.
> FAIL: gcc.target/riscv/rvv/autovec/builtin/strcmp-run.c execution test
> FAIL:
It's more reasonable to fix it in vec_perm_const instead of fix it in
middle-end.
LGTM.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-12-09 21:18
To: gcc-patches; palmer; Kito Cheng; jeffreyalaw; juzhe.zh...@rivai.ai
CC: rdapp.gcc
Subject: [PATCH] RISC-V: Recognize stepped series in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98723
Luca Bacci changed:
What|Removed |Added
CC||luca.bacci at outlook dot com
--- Comment
> FAIL: gcc.target/riscv/rvv/autovec/builtin/strcmp-run.c execution test
> FAIL: gcc.target/riscv/rvv/autovec/builtin/strcmp-run.c execution test
> FAIL: gcc.target/riscv/rvv/autovec/builtin/strcmp-run.c execution test
> FAIL: gcc.target/riscv/rvv/autovec/builtin/strcmp-run.c execution test
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112929
--- Comment #7 from Robin Dapp ---
Here
0x105c6 vse8.v v8,(a5)
is where we overwrite m. The vl is 128 but the preceding vsetvl gets a4 =
46912504507016 as AVL which seems already borken.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112929
--- Comment #6 from Robin Dapp ---
This seems to be gone when simple vsetvl (instead of lazy) is used or with
-fno-schedule-insns which might indicate a vsetvl pass problem.
We might have a few more of those. Maybe it would make sense to run
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112264
Thomas Schwinge changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110987
--- Comment #3 from Kirill Chilikin ---
The derived type T3 has zero components but not zero length as it extends T1;
the test does not crash after the following changes:
diff --git a/gcc/fortran/trans.cc b/gcc/fortran/trans.cc
index
Hi,
we currently try to recognize various forms of stepped (const_vector)
sequence variants in expand_const_vector. Because of complications with
canonicalization and encoding it is easier to identify such patterns
in expand_vec_perm_const_1 already where perm.series_p () is available.
This
On 07/12/2023 14:41, Jonathan Wakely wrote:
On Wed, 6 Dec 2023 at 20:55, François Dumont wrote:
I think I still got no feedback about this cleanup proposal.
Can you remind me why we have all those different functions in
predefined_ops.h in the first place? I think it was to avoid having
two
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112939
Bug ID: 112939
Summary: ICE: verify_ssa failed with -O
-ftrivial-auto-var-init=zero
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112938
David Binderman changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112938
Bug ID: 112938
Summary: ice with -fstrub=internal
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112937
Bug ID: 112937
Summary: [14 Regression] GCN: FAILs due to unconditional
'f->use_flat_addressing = true;'
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Hi Tobias!
On 2023-11-08T17:58:10+0100, Tobias Burnus wrote:
> OpenMP/Fortran: Implement omp allocators/allocate for ptr/allocatables
Nice work!
> This commit adds -fopenmp-allocators which enables support for
> 'omp allocators' and 'omp allocate' that are associated with a Fortran
>
Added it.
Le jeu. 7 déc. 2023 à 18:13, Antoni Boucher a écrit :
>
> It seems like you forgot to prefix the commit message with "libgccjit:
> ".
>
> On Thu, 2023-11-30 at 10:55 +0100, Guillaume Gomez wrote:
> > Ping David. :)
> >
> > Le jeu. 23 nov. 2023 à 22:59, Antoni Boucher a
> > écrit :
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112758
--- Comment #9 from Eric Botcazou ---
> Which means punt on this optimization for WORD_REGISTER_OPERATIONS if the
> outer mode is word_mode, except when sub is a MEM and load_extend_op
> (inner_mode) == ZERO_EXTEND?
Yes, this sounds like a
Tamar Christina writes:
> Hi All,
>
> What do people think about having the ability to force only the latch
> connected
> exit as the exit as a param? I.e. what's in the patch but as a param.
>
> I found this useful when debugging large example failures as it tells me where
> I should be
On Sat, 9 Dec 2023 at 03:53, Paul Smith via Gcc wrote:
>
> I've tried this with both older versions as well as GCC 12.3 (latest I
> have access to). This is on GNU/Linux on x86_64.
>
>
> I have the following code:
[...]
> I'm assuming a bug should be filed for this ICE (can anyone repro it in
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109267
Iain Sandoe changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
Hi!
This function is never called when param_l1_cache_line_size is 0,
but it uses int and unsigned int variables to hold alignment in
bits, so for large param_l1_cache_line_size it is zero and e.g.
DECL_ALIGN () % param_align_bits can divide by zero.
Looking at the code, the function uses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93019
--- Comment #7 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:36be2a0e91c76da4afcd5ddc37e03f5800396387
commit r14-6356-g36be2a0e91c76da4afcd5ddc37e03f5800396387
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26
Xi Ruoyao changed:
What|Removed |Added
Target|riscv* (with zicond)|riscv* (with zicond),
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112935
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112935
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112935
--- Comment #16 from Xi Ruoyao ---
BTW is it possible to get the value range info of (x) and combine (and y, (neg
x)) back to maskeqz in LoongArch backend? It will further improve the
performance. Or maybe expr.cc should invoke a target hook
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112936
Xi Ruoyao changed:
What|Removed |Added
Last reconfirmed||2023-12-09
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112935
--- Comment #15 from Andrew Pinski ---
I see what is happening and kinda of see why it is not there ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112935
--- Comment #14 from Xi Ruoyao ---
LoongArch cost model issue is now PR112936.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112936
Bug ID: 112936
Summary: LoongArch: Wrong instruction costs
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
1 - 100 of 109 matches
Mail list logo
