https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106606
Andre Vehreschild changed:
What|Removed |Added
Assignee|pault at gcc dot gnu.org |vehre at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106606
--- Comment #8 from Paul Thomas ---
(In reply to Andre Vehreschild from comment #7)
> Hi Paul,
>
> I hope you don't mind, when I take over. I am intrigued why this acts so
> strange and I feel, that I am not far off to a solution.
>
> - Andre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116734
--- Comment #3 from Andrew Pinski ---
Created attachment 59128
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59128&action=edit
Reduced testcase for the trunk with LRA turned off
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115905
Rainer Orth changed:
What|Removed |Added
CC||ro at gcc dot gnu.org
--- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116734
--- Comment #4 from Andrew Pinski ---
init-regs adds the set to 0 for the output:
adding initialization in st_update_array_templ of reg 119 at in block 8 for
insn 75.
scanning new insn with uid = 168.
scanning new insn with uid = 169.
(insn 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116720
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |13.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116734
--- Comment #5 from Andrew Pinski ---
I still think the how the pattern for atomic_compare_and_swapsi is broken which
is just causing issues elsewhere.
I have no way to test a fix for atomic_compare_and_swapsi though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730
--- Comment #12 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #11)
> I am testing a full non relative path configure now; that is:
> ```
> mkdir -p t1/t1
> cd t1/t1
> /home/apinski/src/tt1/worktrees/14.2.0/configure --prefix=${H
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116738
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116742
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2024-09-17
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116743
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Target Milestone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115905
--- Comment #6 from Iain Sandoe ---
(In reply to Rainer Orth from comment #5)
> The new test causes a SIGBUS on 32-bit Solaris/SPARC (sparc-sun-solaris2.11):
Is this reproducible on any current cfarm machine?
(or, I guess, on a cross?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115905
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #6 from Iain Sandoe ---
> (In reply to Rainer Orth from comment #5)
>> The new test causes a SIGBUS on 32-bit Solaris/SPARC (sparc-sun-solaris2.11):
>
> Is this reproducib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115905
--- Comment #8 from Iain Sandoe ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #7)
> > --- Comment #6 from Iain Sandoe ---
> > (In reply to Rainer Orth from comment #5)
> >> The new test causes a SIGBUS on 32-bit Solaris/SPARC
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730
--- Comment #13 from Hime Haieto ---
(In reply to Andrew Pinski from comment #12)
> (In reply to Andrew Pinski from comment #11)
> > I am testing a full non relative path configure now; that is:
> > ```
> > mkdir -p t1/t1
> > cd t1/t1
> > /home/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115905
--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #8 from Iain Sandoe ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #7)
[...]
>> I guess so: cfarm216 is current Solaris 11.4/SPARC, the same I use for
>> my
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116357
Richard Biener changed:
What|Removed |Added
Component|tree-optimization |c
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116438
--- Comment #7 from Eric Botcazou ---
Using libbacktrace can only address half of the problem, namely the half where
the internal_error handler of the middle-end is called directly. For the other
half, namely when a signal (e.g. out of a segfau
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116728
--- Comment #4 from Martin Uecker ---
Although the new example doesn't crash and the error I get seems correct to me.
What is the problem you see here?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730
--- Comment #14 from Hime Haieto ---
It could still be worth doing a couple other "easy" tests first before going
more fully into the Makefile.am - skipping a separate make step (i.e. configure
then straight to make install), and if there's mayb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730
--- Comment #15 from Andreas Schwab ---
Does it help to change the symlink creation rules in
libstdc++-v3/src/libbacktrace/Makefile.am to use $(top_srcdir)/.. instead of
../../..? I think that should prevent VAPTH from interfering.
%.c: $(top_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116573
--- Comment #7 from Robin Dapp ---
I'm testing a patch that basically does what Richi proposes.
I was also playing around with mixed lane configurations where we potentially
reuse the pointer increment from another pointer update. To me the co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116738
--- Comment #3 from Petr ---
Maybe marking it as confirmed would be appropriate then?
I think as a workaround it would be better to not constant fold code that GCC
cannot compute properly - that would mean properly calculating the values at
run
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116573
--- Comment #8 from Richard Biener ---
Btw, I've written up a patch as well:
diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
index 62c7f90779f..199d79029e4 100644
--- a/gcc/tree-vect-loop.cc
+++ b/gcc/tree-vect-loop.cc
@@ -3078,10 +3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730
--- Comment #16 from Hime Haieto ---
(In reply to Andreas Schwab from comment #15)
> Does it help to change the symlink creation rules in
> libstdc++-v3/src/libbacktrace/Makefile.am to use $(top_srcdir)/.. instead of
> ../../..? I think that sh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116738
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730
--- Comment #17 from Andreas Schwab ---
No, top_builddir is wrong. The rule wants to link to a file in the _source_
directory.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116728
--- Comment #5 from Martin Uecker ---
Sorry, mixed this up with the other bug. Here I would say the behavior is
correct as specified in ISO C23. Note that incomplete structs could be
completed later also before ISO C23. But incomplete struct t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730
--- Comment #18 from Hime Haieto ---
(In reply to Andreas Schwab from comment #17)
> No, top_builddir is wrong. The rule wants to link to a file in the _source_
> directory.
I think you may be right...I was thinking about what's to the left of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #36 from Aldy Hernandez ---
(In reply to Richard Biener from comment #33)
> Can we just sort m_paths after the path entry BB and fix the lookup that way?
This seemed promising, especially because the adjust_paths_after_duplication()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730
--- Comment #19 from Jonathan Wakely ---
Right, you seem repeatedly confused about the difference between the build dir
and the source dir. The libbacktrace/*.c files are in the source dir. The paths
to those is fixed relative to the libstdc++-v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730
--- Comment #20 from Jonathan Wakely ---
(In reply to Hime Haieto from comment #16)
> But you know, what...I'm just going to try and see what happens when I
> simply delete that entire part outright
That can't possibly work.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730
--- Comment #21 from Jonathan Wakely ---
You could just stop building in a sub-directory of the source tree.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730
--- Comment #22 from Jonathan Wakely ---
(In reply to Andreas Schwab from comment #15)
> Does it help to change the symlink creation rules in
> libstdc++-v3/src/libbacktrace/Makefile.am to use $(top_srcdir)/.. instead of
> ../../..? I think tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730
--- Comment #23 from Hime Haieto ---
Relax, we're still working to pinpoint where the actual problem/solution is. I
only confused the src/build stuff for the raw makefile rule - you may not have
seen the rest of the Makefile.am and its history
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730
--- Comment #24 from Jonathan Wakely ---
(In reply to Hime Haieto from comment #23)
> you may not
> have seen the rest of the Makefile.am and its history within the commit I
> referenced.
You may not have seen who wrote that commit.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730
--- Comment #25 from Jonathan Wakely ---
And the entire file.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116726
--- Comment #5 from Martin Uecker ---
Fix being tested.
diff --git a/gcc/c/c-typeck.cc b/gcc/c/c-typeck.cc
index 58b2724b39e..ba6d96d26b2 100644
--- a/gcc/c/c-typeck.cc
+++ b/gcc/c/c-typeck.cc
@@ -1686,8 +1686,11 @@ tagged_types_tu_compatible_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730
--- Comment #26 from Hime Haieto ---
(In reply to Jonathan Wakely from comment #22)
> (In reply to Andreas Schwab from comment #15)
> > Does it help to change the symlink creation rules in
> > libstdc++-v3/src/libbacktrace/Makefile.am to use $(t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730
--- Comment #27 from Hime Haieto ---
Also, the links don't even correctly point to the sources in the first place,
yet the build still completed for me with broken symlinks anyway. As for why I
tried removing the manual make rule entirely a lit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730
--- Comment #28 from Jonathan Wakely ---
(In reply to Hime Haieto from comment #27)
> Also, the links don't even correctly point to the sources in the first
> place,
They do for me.
> yet the build still completed for me with broken symlinks a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730
--- Comment #29 from Hime Haieto ---
(In reply to Jonathan Wakely from comment #24)
> (In reply to Hime Haieto from comment #23)
> > you may not
> > have seen the rest of the Makefile.am and its history within the commit I
> > referenced.
>
> Y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730
--- Comment #30 from Jonathan Wakely ---
I'm not impassioned, you're just suggesting nonsense like removing necessary
chunks of the makefiles, without understanding what any of it actually does.
That's not going to solve anything.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730
--- Comment #31 from Jonathan Wakely ---
(In reply to Andrew Pinski from comment #9)
> So yes I can reproduce the failure
I can't
cd /tmp
git clone ~/src/gcc/gcc
cd gcc
mkdir -p build/objdir
cd build/objdir
../../configure --disable-bootstra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730
--- Comment #32 from Hime Haieto ---
(In reply to Jonathan Wakely from comment #28)
> (In reply to Hime Haieto from comment #27)
> > Also, the links don't even correctly point to the sources in the first
> > place,
>
> They do for me.
>
> > ye
cking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20240917 (experimental) (GCC)
[512] %
[512] % gcctk -O3 small.c
during GIMPLE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730
--- Comment #33 from Hime Haieto ---
(In reply to Jonathan Wakely from comment #31)
> (In reply to Andrew Pinski from comment #9)
> > So yes I can reproduce the failure
>
> I can't
>
>
> cd /tmp
> git clone ~/src/gcc/gcc
> cd gcc
> mkdir -p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730
--- Comment #34 from Jonathan Wakely ---
I suspect the links are created successfully during "make" and then during
"make install" the prerequisites resolve to different paths (for some reason),
so Make attempts to recreate the targets using dif
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116747
Richard Biener changed:
What|Removed |Added
Keywords||ice-on-valid-code
Target Milestone|-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730
--- Comment #35 from Jonathan Wakely ---
(In reply to Hime Haieto from comment #33)
> Does it install? I/we were getting the issue not during configure or make,
> but a make install after the make.
In comment 27 you said "the links don't even
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115905
--- Comment #10 from Iain Sandoe ---
unfortunately, (or ...) I Have not succeeded in reproducing this - so will need
some help to identify what's being done differently from you.
I built: r15-3667-gf5448384a213 (also on my Darwin17+ set, which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116728
--- Comment #6 from Hime Haieto ---
I was pretty sure the first example in the attachment to this PR was something
that should work (less so about the second), though something something
standardese something something language lawyers. Especia
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116748
Bug ID: 116748
Summary: internal compiler error: in pop_local_binding, at
cp/name-lookup.cc:2651
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116748
--- Comment #1 from Steve Downey ---
Created attachment 59129
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59129&action=edit
-freport-bug preprocessed output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115905
--- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #10 from Iain Sandoe ---
> unfortunately, (or ...) I Have not succeeded in reproducing this - so will
> need
> some help to identify what's being done differently from y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116728
--- Comment #7 from Hime Haieto ---
Your comment about typedefs is just starting to sink in...I'll have to return
to this later though, as this is a conference week for me and it's about to
start up again soon.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #37 from rguenther at suse dot de ---
On Tue, 17 Sep 2024, aldyh at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
>
> --- Comment #36 from Aldy Hernandez ---
> (In reply to Richard Biener from commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115148
--- Comment #18 from John Paul Adrian Glaubitz ---
This particular bug is resolved when building with an LRA-enabled gcc-15.
See: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730
--- Comment #36 from Jonathan Wakely ---
Where do your broken symlinks point to, if not the correct sources?
I still can't reproduce it with "make install" so I've removed
--disable-bootstrap from my configure options and am waiting for a boots
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111527
--- Comment #20 from Sunil Dora ---
Hi Andrew,
Initially, I thought to address long command line options (when exceeding
128KB) without disrupting the existing GCC driver behavior.
As you suggested, I implemented changes to use the response f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98004
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #38 from aldy at quesejoda dot com ---
On Tue, Sep 17, 2024 at 1:19 PM rguenther at suse dot de <
gcc-bugzi...@gcc.gnu.org> wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
>
> --- Comment #37 from rguenther at suse dot d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116730
--- Comment #37 from Jonathan Wakely ---
I still can't reproduce any error with:
../../configure --prefix=/tmp/install --enable-languages=c++
make -j10
make install
So I'm not going to spend any more time on this. If it doesn't work for you,
j
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #269 from Kazumoto Kojima ---
(In reply to Kazumoto Kojima from comment #267)
> (In reply to Oleg Endo from comment #264)
> > Very nice! So it seems indeed, splitting up the "mega move patterns" into
> > simpler ones where predicates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116747
Andrew Pinski changed:
What|Removed |Added
Summary|[15 Regression] ICE on |[12/13/14/15 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116747
Andrew Pinski changed:
What|Removed |Added
Target Milestone|15.0|12.5
--- Comment #13 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116743
--- Comment #2 from Rama Malladi ---
The 10% regression was observed on an `aarch64` architecture/ instance.
We saw regression on an `x86_64` instance too. Here is the data:
GCC version BaselineAutoFDO
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116748
Marek Polacek changed:
What|Removed |Added
Last reconfirmed||2024-09-17
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116140
--- Comment #15 from Filip Kastl ---
I just checked performance of the 2006 version of xalancbmk on x86_64. Thanks a
lot. It got considerably better. However, it still is worse than before
r15-2356-ge69456ff9a54ba.
This can be seen on most of t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116747
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116748
Marek Polacek changed:
What|Removed |Added
CC||nshead at gcc dot gnu.org
Key
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116726
--- Comment #6 from Peter Damianov ---
Another testcase:
not an ICE, but I think rejects-valid
```
typedef void f(struct s1);
struct s1 {
int f1;
};
typedef void f(struct s1);
```
:5:14: error: conflicting types for 'f'; have 'void(struct s1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116747
Andrew Pinski changed:
What|Removed |Added
Target||x86_64
--- Comment #2 from Andrew Pinsk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116726
--- Comment #7 from Martin Uecker ---
(In reply to Peter Damianov from comment #6)
> Another testcase:
> not an ICE, but I think rejects-valid
> ```
> typedef void f(struct s1);
> struct s1 {
> int f1;
> };
> typedef void f(struct s1);
> ```
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116726
--- Comment #8 from Martin Uecker ---
PATCH: https://gcc.gnu.org/pipermail/gcc-patches/2024-September/663123.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115905
--- Comment #12 from Iain Sandoe ---
hmm .. this is initialising the ramp return object (which is a handle) and when
I look at the to and from trees they seem to have the requisite alignment (the
from value is a return from operator new). I'm a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116748
--- Comment #4 from Marek Polacek ---
Reducing...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116492
Patrick Palka changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116676
--- Comment #7 from GCC Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:dfe0d4389a3ce43179563a63046ad3e74d615a08
commit r15-3672-gdfe0d4389a3ce43179563a63046ad3e74d615a08
Author: Marek Polacek
Date: Mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116747
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116676
--- Comment #8 from GCC Commits ---
The releases/gcc-14 branch has been updated by Marek Polacek
:
https://gcc.gnu.org/g:f1dc18250d82cd123fcf9aef0a95608e4ec63d58
commit r14-10675-gf1dc18250d82cd123fcf9aef0a95608e4ec63d58
Author: Marek Polacek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115905
--- Comment #13 from Iain Sandoe ---
looking like a GTY issue:
(gdb) p target->u.fld[1]->rt_mem
$7 = (mem_attrs *) 0xafafafaf
(gdb) p target->u.fld[1]->rt_mem->align
that seems to be the tell-tale value for a free ptr.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116676
--- Comment #9 from GCC Commits ---
The releases/gcc-13 branch has been updated by Marek Polacek
:
https://gcc.gnu.org/g:c8682dd76e31ee4bc4dede23c78d6d66de350e83
commit r13-9031-gc8682dd76e31ee4bc4dede23c78d6d66de350e83
Author: Marek Polacek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116676
Marek Polacek changed:
What|Removed |Added
Summary|[12/13/14/15 Regression]|[12 Regression] ICE with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116749
Bug ID: 116749
Summary: program crash under -O3 optimization
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-en
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116750
Bug ID: 116750
Summary: --coverage generates random .data.rel
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116738
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116738
--- Comment #6 from Jakub Jelinek ---
C testcase with unnecessary clutter removed:
#include
static inline float
clamp (float f)
{
__m128 v = _mm_set_ss (f);
__m128 zero = _mm_setzero_ps ();
__m128 greatest = _mm_set_ss (__FLT_MAX__);
v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114622
Willy Tarreau changed:
What|Removed |Added
CC||w at 1wt dot eu
--- Comment #2 from Wil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116676
--- Comment #11 from GCC Commits ---
The releases/gcc-12 branch has been updated by Marek Polacek
:
https://gcc.gnu.org/g:9046f9aeae0f926e7365d39809a80855e7dc184a
commit r12-10713-g9046f9aeae0f926e7365d39809a80855e7dc184a
Author: Marek Polacek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85716
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116751
Bug ID: 116751
Summary: GCC trunk (-O3) doesn't optimize a loop that can be
folded into a constant
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116750
--- Comment #1 from Andrew Pinski ---
Try using -frandom-seed=0 or someother number.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116750
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116738
--- Comment #7 from Petr ---
The simplified test case looks good except for a missing return :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114052
Andrew Pinski changed:
What|Removed |Added
CC||bouncy12578 at gmail dot com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116749
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116749
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-09-17
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116749
--- Comment #2 from Andrew Pinski ---
Maybe not ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114052
--- Comment #11 from Andrew Pinski ---
Note I don't get an __builtin_unreachable() in GCC 14.1.0 nor 13.1.0.
1 - 100 of 170 matches
Mail list logo
