https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90276
--- Comment #2 from François Dumont ---
Is there any unmentioned prerequisite to reproduce this bug ? I cannot.
Maybe thanks to PR11477 this PR could be closed too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113578
--- Comment #5 from Jonathan Wakely ---
Maybe we could make it work for std::ostream with something like:
--- a/libstdc++-v3/include/std/ostream
+++ b/libstdc++-v3/include/std/ostream
@@ -233,7 +233,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113486
Andrew Pinski changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113486
--- Comment #4 from GCC Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:d3ff08a3764f2047d02b35212fc4f1da9eb75c7b
commit r14-8397-gd3ff08a3764f2047d02b35212fc4f1da9eb75c7b
Author: Andrew Pinski
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113578
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109705
--- Comment #10 from Andrew Pinski ---
And yes gcc.dg/vect/pr25413a.c testcase passes when SVE is enabled too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109705
--- Comment #9 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #8)
> So for aarch64, vectorized long can be done with SVE enabled or ILP32 or
> with a constant. I will submit a patch for aarch64 against
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113578
--- Comment #3 from Andrew Pinski ---
and since __builtin_printf is variadic function, floats are promoted to double
causing the removal of the payload of NaN on RISCV at runtime ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111966
Thomas Schwinge changed:
What|Removed |Added
Ever confirmed|0 |1
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63326
Andrew Pinski changed:
What|Removed |Added
CC||liavonlida at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113587
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113587
--- Comment #1 from Andrew Pinski ---
Note GCC treats `#pragma`s in some (maybe most) cases as statements which is
the effect you are seeing here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113575
--- Comment #11 from Matthias Klose ---
> Is increasing the available memory an option
> in the meantime or does this urgently require fixing?
there is a buffer of 500mb, but it's already using 3.5gb. That probably would
work building without
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113095
--- Comment #5 from GCC Commits ---
The master branch has been updated by Jeff Law :
https://gcc.gnu.org/g:fb54b9772816968032518d4008be5090e0d95109
commit r14-8396-gfb54b9772816968032518d4008be5090e0d95109
Author: Monk Chiang
Date: Wed Jan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113587
Bug ID: 113587
Summary: Compile error with #pragma (end)region
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113586
Andrew Pinski changed:
What|Removed |Added
Keywords||ice-checking
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88345
--- Comment #24 from GCC Commits ---
The master branch has been updated by Jan Hubicka :
https://gcc.gnu.org/g:0f5a9a00e3ab1fe96142f304cfbcf3f63b15f326
commit r14-8395-g0f5a9a00e3ab1fe96142f304cfbcf3f63b15f326
Author: Jan Hubicka
Date: Wed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113585
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59429
Andrew Pinski changed:
What|Removed |Added
CC||redbeard0531 at gmail dot com
---
lgorithms: zlib zstd
gcc version 14.0.1 20240124 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113568
--- Comment #2 from Jakub Jelinek ---
(In reply to Marek Polacek from comment #1)
> Started with r14-4592:
Only because it uses _BitInt(848).
Just change the testcase to:
signed char c;
_BitInt(464) g;
void
foo (void)
{
_BitInt(464) a[2] =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113542
Richard Earnshaw changed:
What|Removed |Added
Keywords||missed-optimization
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113574
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110809
Patrick Palka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113584
Marek Polacek changed:
What|Removed |Added
Keywords|ice-on-invalid-code |ice-on-valid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113584
Marek Polacek changed:
What|Removed |Added
Summary|ICE in unify, at|[11/12/13/14 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113584
Marek Polacek changed:
What|Removed |Added
Last reconfirmed||2024-01-24
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113584
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84201
Jeffrey A. Law changed:
What|Removed |Added
CC||vineetg at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 113570, which changed state.
Bug 113570 Summary: RISC-V: SPEC2017 549 fotonik3d miscompilation in autovec
VLS 256 build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113570
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113570
Jeffrey A. Law changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113570
--- Comment #3 from Jeffrey A. Law ---
See pr84201 for more details as well as
https://www.spec.org/cpu2017/Docs/benchmarks/549.fotonik3d_r.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109636
Tamar Christina changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109636
--- Comment #12 from GCC Commits ---
The master branch has been updated by Tamar Christina :
https://gcc.gnu.org/g:dfa17fd3b1a50cab51803e8a63c5c7b7db173523
commit r14-8394-gdfa17fd3b1a50cab51803e8a63c5c7b7db173523
Author: Tamar Christina
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113552
--- Comment #12 from GCC Commits ---
The master branch has been updated by Tamar Christina :
https://gcc.gnu.org/g:306713c953d509720dc394c43c0890548bb0ae07
commit r14-8393-g306713c953d509720dc394c43c0890548bb0ae07
Author: Tamar Christina
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113585
Bug ID: 113585
Summary: Poor codegen turning int compare into -1,0,1
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110075
--- Comment #5 from Marek Polacek ---
Yes, because we'd have to analyze the body of the function to see that it does
not return one of the parameters, which often we can't do.
There will be an attribute soon to suppress that warning.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113520
--- Comment #8 from Jan Hubicka ---
I think the ipa-cp summaries should be used only when types match. At least
Martin added type streaming for all the jump functions. So we are missing some
check?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113141
Patrick Palka changed:
What|Removed |Added
Keywords||ice-on-valid-code
--- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112862
--- Comment #11 from Iain Sandoe ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #10)
> > --- Comment #9 from Iain Sandoe ---
> > (In reply to Rainer Orth from comment #8)
> >> Again tested on macOS 11 (unchanged) and 14. On the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113490
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113490
--- Comment #6 from GCC Commits ---
The master branch has been updated by Martin Jambor :
https://gcc.gnu.org/g:bc4a20bc57ce71da0a96bcc6ec5683640b9004d6
commit r14-8392-gbc4a20bc57ce71da0a96bcc6ec5683640b9004d6
Author: Martin Jambor
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113584
Bug ID: 113584
Summary: ICE in unify, at cp/pt.cc:24640 with template
specialization on 2 matching template template
parameter
Product: gcc
Version: 14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112927
--- Comment #1 from GCC Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:b6e537571c21d8f0bc276d7afa156d6d4a54a1c9
commit r14-8390-gb6e537571c21d8f0bc276d7afa156d6d4a54a1c9
Author: David Malcolm
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112977
--- Comment #2 from GCC Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:e503f9aca9192654d83f141ae7865a3c9d90bf0d
commit r14-8391-ge503f9aca9192654d83f141ae7865a3c9d90bf0d
Author: David Malcolm
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112862
--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #9 from Iain Sandoe ---
> (In reply to Rainer Orth from comment #8)
>> Again tested on macOS 11 (unchanged) and 14. On the latter, the previous
>> failures
>> to find
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113583
--- Comment #3 from JuzheZhong ---
Ok I see.
If we change NN into 8, then we can vectorize it with load_lanes/store_lanes
with group size = 8:
https://godbolt.org/z/doe9c3hfo
We will use vlseg8e64 which is RVVM1DF[8] == RVVM1x8DFmode.
Here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112863
--- Comment #4 from Rainer Orth ---
On macOS 11, everything is still fine. On macOS 14, there's progress:
* Before your patch:
=== obj-c++ Summary ===
# of expected passes2813
# of unexpected failures378
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113485
Richard Sandiford changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #7 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112862
--- Comment #9 from Iain Sandoe ---
(In reply to Rainer Orth from comment #8)
> Again tested on macOS 11 (unchanged) and 14. On the latter, the previous
> failures
> to find libatomic.1.dylib have been traded for
>
> FAIL:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112862
--- Comment #8 from Rainer Orth ---
Again tested on macOS 11 (unchanged) and 14. On the latter, the previous
failures
to find libatomic.1.dylib have been traded for
FAIL: gfortran.dg/coarray/alloc_comp_1.f90 -fcoarray=single -O2 (test for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113583
--- Comment #2 from Robin Dapp ---
> It's interesting, for Clang only RISC-V can vectorize it.
The full loop can be vectorized on clang x86 as well when I remove the first
conditional (which is not in the snippet I posted above). So that's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113583
--- Comment #1 from JuzheZhong ---
It's interesting, for Clang only RISC-V can vectorize it.
I think there are 2 topics:
1. Support vectorization of this codes of in loop vectorizer.
2. Transform gather/scatter into strided load/store for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113553
--- Comment #1 from Rainer Orth ---
The build works for me just fine on sparc-sun-solaris2.11.
I've also fired one off on sparc64-unknown-linux-gnu which worked just as well.
It was a rough ride, however, with the build aborting with
xgcc:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113582
--- Comment #1 from Nikolay Mihaylov ---
If you move the pragma outside the templated function, no warning is shown:
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wunused-label"
template
void do_something(){
start:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113583
Bug ID: 113583
Summary: Main loop in 519.lbm not vectorized.
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113581
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113539
--- Comment #7 from Filip Kastl ---
I just reproduced the same issue on an x86_64 zen3 machine. Running both
500.perlbench_r and 400.perlbench with options -Ofast -march=native
-mtune=native -g -flto=32 results in
*** Miscompare of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113539
Filip Kastl changed:
What|Removed |Added
CC||fkastl at suse dot cz
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112861
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Iain Sandoe ---
> Created attachment 57201
> --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57201=edit
> patch under test
>
> works on x86_64 sonoma, with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
--- Comment #5 from Richard Biener ---
diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
index fe631252dc2..28ad03e0b8a 100644
--- a/gcc/tree-vect-loop.cc
+++ b/gcc/tree-vect-loop.cc
@@ -991,8 +991,12 @@ vec_init_loop_exit_info (class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113485
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113582
Bug ID: 113582
Summary: incorrect warning about unused label
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110779
Gaius Mulley changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
--- Comment #3 from Richard Biener ---
So the change enables early exit vectorization since may_be_zero is _10 == 0
here, resulting in an overall
number_of_iterationsm1 == _10 != 0 ? _10 + 4294967295 : 0
and
number_of_iterations = MAX_EXPR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113281
--- Comment #21 from Jakub Jelinek ---
So, I think
--- gcc/tree-vect-patterns.cc.jj2024-01-03 11:51:37.487648527 +0100
+++ gcc/tree-vect-patterns.cc 2024-01-24 14:05:55.911356481 +0100
@@ -3002,6 +3002,12 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107590
--- Comment #16 from Sergey Fedorov ---
(In reply to Andrew Pinski from comment #13)
> Oh yes there could be a bug here when the byte (lbarx/stbcx.) and half-word
> (lharx/sthcx.) instruction support was added (which was for Power8;
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113559
Gaius Mulley changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67067
Rainer Orth changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113559
--- Comment #5 from GCC Commits ---
The master branch has been updated by Gaius Mulley :
https://gcc.gnu.org/g:3de031c96f28f19a68ea2080260d8fd2c78828ee
commit r14-8389-g3de031c96f28f19a68ea2080260d8fd2c78828ee
Author: Gaius Mulley
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113556
Rainer Orth changed:
What|Removed |Added
Status|NEW |RESOLVED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113510
--- Comment #6 from Richard Earnshaw ---
(In reply to Andrew Pinski from comment #5)
> Yes the peephole2 in thumb1.md looks wrong:
> ```
> ;; Reloading and elimination of the frame pointer can
> ;; sometimes cause this optimization to be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113556
--- Comment #2 from GCC Commits ---
The master branch has been updated by Rainer Orth :
https://gcc.gnu.org/g:b8f54195edbecd7151095f137f9ff27e1ddc8e36
commit r14-8388-gb8f54195edbecd7151095f137f9ff27e1ddc8e36
Author: Rainer Orth
Date: Wed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113542
Richard Earnshaw changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113578
--- Comment #2 from Joseph S. Myers ---
If a conversion from float to double (for passing in variable arguments) occurs
at runtime on RISC-V, that will produce a positive-signed NaN (that's what the
RISC-V floating-point instructions do). Cf.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113579
--- Comment #1 from Richard Biener ---
I think we somewhere document that control transfer into / out of stmt
expressions invokes undefined behavior.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113581
--- Comment #1 from Jan Schultke ---
Oh, I probably should have mentioned this: This only happens when times_three
is a function template.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113581
Bug ID: 113581
Summary: Ignoring GCC unroll loop annotation for loops with
increment in condition
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113580
Bug ID: 113580
Summary: -Wunused-parameter in template imported from module
causes segmentation fault
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113579
Bug ID: 113579
Summary: GCC leaks memory inside when using statement
expressions
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113578
Jonathan Wakely changed:
What|Removed |Added
Summary|Incorrect signbit for -nan |Incorrect sign printed for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113578
Bug ID: 113578
Summary: Incorrect signbit for -nan on RISC-V
Product: gcc
Version: 11.4.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113577
Bug ID: 113577
Summary: GCC crashes with co_await expression in
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83324
Sam James changed:
What|Removed |Added
CC||andi-gcc at firstfloor dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113562
--- Comment #2 from Richard Biener ---
So the first difference is
@@ -4076,36 +4076,47 @@
fbt (0x7700b468: (reg/f:SI 16 argp)) == (address:SI -4)
fbt (0x771f6a68: (plus:SI (minus:SI (value/u/j:SI 13:4329
@0x4a213b0/0x498b
600)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113560
--- Comment #6 from Roger Sayle ---
In the .optimized dump, we have:
__int128 unsigned __res;
__int128 unsigned _12;
...
__res_11 = in_2(D) w* 184467440738;
_12 = __res_11 & 18446744073709551615;
__res_7 = _12 * 100;
So the first
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67067
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2024-01-24
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105688
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|2022-05-23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113559
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #3 from Gaius Mulley ---
> Created attachment 57205
> --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57205=edit
> Proposed fix v2
>
> Correction the cast should be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113565
--- Comment #5 from Jan Schultke ---
You can reproduce this as follows:
> static_assert(__builtin_clz(0u) == 32);
>
> unsigned x = 0;
>
> int main() {
> return __builtin_clz(x);
> }
For base x86_64, GCC emits:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79193
--- Comment #7 from Jonathan Wakely ---
Sandra, does the commit above fix this?
You mentioned it not being fully general, but is it good enough?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
--- Comment #1 from Hongtao Liu ---
int
__attribute__((noinline))
sbitmap_first_set_bit (const_sbitmap bmap)
{
unsigned int n = 0;
sbitmap_iterator sbi;
EXECUTE_IF_SET_IN_SBITMAP (bmap, 0, n, sbi)
return n;
return -1;
}
hangs on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
Bug ID: 113576
Summary: [14 regression] 502.gcc_r hangs
r14-8223-g1c1853a70f9422169190e65e568dcccbce02d95c
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113565
--- Comment #4 from Jan Schultke ---
I would expect an error here because things that are undefined behavior are
generally supposed to fail in constant expressions. I don't see a good reason
why builtins should be exempt from that rule.
The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113281
--- Comment #20 from Jakub Jelinek ---
(In reply to Jakub Jelinek from comment #18)
> But they are not correct for logical right shifts and they don't handle left
> shifts.
Oh, and then there are rotates and I think we need to punt on those,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110679
--- Comment #3 from Jonathan Wakely ---
(In reply to Andrew Pinski from comment #2)
> *** Bug 113543 has been marked as a duplicate of this bug. ***
^^ N.B. this has a number of other testcases for the missed optimizations.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113565
Jonathan Wakely changed:
What|Removed |Added
Severity|normal |enhancement
--- Comment #3 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113281
--- Comment #19 from rguenther at suse dot de ---
On Wed, 24 Jan 2024, pinskia at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113281
>
> --- Comment #17 from Andrew Pinski ---
> (In reply to rguent...@suse.de from
101 - 200 of 228 matches
Mail list logo
