https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109596
--- Comment #11 from Richard Biener ---
Honza - any progress here?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113208
--- Comment #23 from Richard Biener ---
So we have _ZN6vectorI12QualityValueEC{2,5}ERKS1_ so C2 vs C5, whatever that
exactly means.
When not using -flto and not optimizing the comdat group in both objects is
COMDAT group section [2] `.grou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114674
Bug ID: 114674
Summary: [aarch64] ldp_fusion fails to merge 2 strs due to
imprecise alignment info
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: nor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114674
--- Comment #1 from Di Zhao ---
Here's a quick fix I tried, that works on the small test case above:
diff --git a/gcc/config/aarch64/aarch64-ldp-fusion.cc
b/gcc/config/aarch64/aarch64-ldp-fusion.cc
index 365dcf48b22..43478ede72b 100644
--- a/gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114673
--- Comment #1 from Andreas Schwab ---
There is a single use in md files:
(define_insn "*movcc"
[(set (match_operand:GPR 0 "register_operand" "=r,r")
(if_then_else:GPR
(match_operator 5 "ordered_comparison_operator"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114591
--- Comment #3 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #2)
> This changed with r12-5584-gca5667e867252db3c8642ee90f55427149cd92b6
Strange, if I revert the constraints to the previous setting with:
--cut here--
diff --git
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114409
--- Comment #13 from Richard Biener ---
The question is what handles the COMPOUND_EXPR with DECL_EXPR when the
ANNOTATE_EXPR isn't around. tsubst_expr doesn't handle DECL_EXPRs.
It's built even w/o the #pragma via finish_cond and finish_while_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114662
--- Comment #3 from GCC Commits ---
The master branch has been updated by Kewen Lin :
https://gcc.gnu.org/g:4923ed49b93352bcf9e43cafac38345e4a54c3f8
commit r14-9886-g4923ed49b93352bcf9e43cafac38345e4a54c3f8
Author: Kewen Lin
Date: Wed Apr 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114426
--- Comment #10 from Richard Biener ---
As a band-aid, can we turn the gcc_assert into a gcc_checking_assert to make
the issue latent (again) on release branches? I understand the issue _is_
latent?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114662
Kewen Lin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114591
Hongtao Liu changed:
What|Removed |Added
CC||liuhongt at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114672
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Assignee|unassigned at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114462
--- Comment #8 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:4be1cc5f50578fafcdcbd09160235066d76a3f86
commit r14-9887-g4be1cc5f50578fafcdcbd09160235066d76a3f86
Author: Jakub Jelinek
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114462
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110338
Bug 110338 depends on bug 114462, which changed state.
Bug 114462 Summary: [C++26] P2809R3 - Trivial infinite loops are not undefined
behavior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114462
What|Removed |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94404
Bug 94404 depends on bug 114462, which changed state.
Bug 114462 Summary: [C++26] P2809R3 - Trivial infinite loops are not undefined
behavior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114462
What|Removed |Ad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114591
--- Comment #5 from Hongtao Liu ---
> My experience is memory cost for the operand with rm or separate r, m is
> different which impacts RA decision.
>
> https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595573.html
Change operands[1] alterna
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114674
Alex Coplan changed:
What|Removed |Added
CC||acoplan at gcc dot gnu.org
Keyw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114591
--- Comment #6 from Uroš Bizjak ---
LRA starts with this:
5: r98:SI=[`v1']
REG_EQUIV [`v1']
6: [`v2']=zero_extend(r98:SI)
7: r101:HI=r98:SI#0
REG_DEAD r98:SI
12: ax:HI=r101:HI
REG_DEAD r101:HI
13: use ax:HI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114591
--- Comment #7 from Uroš Bizjak ---
(In reply to Hongtao Liu from comment #5)
> > My experience is memory cost for the operand with rm or separate r, m is
> > different which impacts RA decision.
> >
> > https://gcc.gnu.org/pipermail/gcc-patche
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114567
--- Comment #1 from Kewen Lin ---
This is power8 LE specific, for KFmode its mov expander calls
rs6000_emit_le_vsx_move, so it's with V1TI subreg, then rs6000 specific pass
swaps generate one MEM with AND -16, which make combine unable to optimi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114591
--- Comment #8 from Uroš Bizjak ---
BTW: The reason for the original change:
(define_insn "*movhi_internal"
- [(set (match_operand:HI 0 "nonimmediate_operand" "=r,r ,r ,m ,*k,*k
,*r,*m,*k,?r,?v,*v,*v,*m")
- (match_operand:HI 1 "general_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114591
--- Comment #9 from Hongtao Liu ---
>
> It looks that different modes of memory read confuse LRA to not CSE the read.
>
> IMO, if the preloaded value is later accessed in different modes, LRA should
> leave it. Alternatively, LRA should CSE m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114591
--- Comment #10 from Uroš Bizjak ---
(In reply to Hongtao Liu from comment #5)
> > My experience is memory cost for the operand with rm or separate r, m is
> > different which impacts RA decision.
> >
> > https://gcc.gnu.org/pipermail/gcc-patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114591
--- Comment #11 from Hongtao Liu ---
unsigned v;
long long v2;
char foo ()
{
v2 = v;
return v;
}
This is related to *movqi_internal, and codegen has been worse since gcc8.1
foo:
movlv(%rip), %eax
movq%rax, v2(%r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114675
Bug ID: 114675
Summary: warning for "reference to not fully constructed
object"
Product: gcc
Version: 13.1.1
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114662
--- Comment #5 from Martin Jambor ---
Thanks a lot for taking care of it before I had a chance to.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110027
--- Comment #18 from Jakub Jelinek ---
Created attachment 57915
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57915&action=edit
gcc14-pr110027.patch
So far lightly tested patch (make check-gcc check-g++ RUNTESTFLAGS=asan.exp on
x86_64-li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97304
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97304
--- Comment #10 from Jonathan Wakely ---
If --with-as=/usr/local/bin/as --with-ld=/usr/local/bin/ld is required then it
needs to be documented at https://gcc.gnu.org/install/specific.html#x-x-freebsd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112745
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97304
Andrew Pinski changed:
What|Removed |Added
CC||ro at gcc dot gnu.org
--- Comment #11 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114675
--- Comment #1 from Jonathan Wakely ---
A complete testcase that actually compiles:
struct A { };
struct C { C(const A&); };
struct B { B(const C&); };
struct everything {
everything() : a(), b(c), c(a) { }
A a;
B b;
C c;
};
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97304
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114676
Bug ID: 114676
Summary: [12/13/14 Regression] DSE removes assignment that is
used later
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97304
--- Comment #13 from Jonathan Wakely ---
(In reply to Andrew Pinski from comment #11)
> *** Bug 112745 has been marked as a duplicate of this bug. ***
And as suggested in Bug 112745, either lld should Just Work or GCC should work
around whatever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97304
--- Comment #14 from Andrew Pinski ---
(In reply to Jonathan Wakely from comment #10)
> If --with-as=/usr/local/bin/as --with-ld=/usr/local/bin/ld is required then
> it needs to be documented at
> https://gcc.gnu.org/install/specific.html#x-x-fre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114676
Andrew Pinski changed:
What|Removed |Added
Keywords||wrong-code
Component|tree-opti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104707
--- Comment #10 from Andrew Pinski ---
Note multilib is not the issue. See
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97304#c14 for more analysis of the
issue (I think there might be another bug report talking about this too).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114675
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-04-10
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114676
--- Comment #2 from Aleksei Nikiforov
---
Yes, -fno-strict-aliasing helped.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114676
--- Comment #3 from Andrew Pinski ---
(In reply to Aleksei Nikiforov from comment #2)
> Yes, -fno-strict-aliasing helped.
Then the issue is in s390_expand_overloaded_builtin where it should be more
aliasing friendly. and it is a target issue ..
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114676
--- Comment #4 from Aleksei Nikiforov
---
Yes, it doesn't reproduce on x86_64, and previously getting rid of -O3 or using
-fno-tree-dse also helped.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114676
--- Comment #5 from Andrew Pinski ---
> I've bisected gcc, and issue first appears with gcc commit
> 32955416d8040b1fa1ba21cd4179b3264e6c5bd6.
This just improved DSE but I suspect there might be a way to reproduce it
before that.
Note the rs60
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114665
--- Comment #1 from Robin Dapp ---
Hmm, my local version is a bit older and seems to give the same result for both
-O2 and -O3. At least a good starting point for bisection then.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114675
--- Comment #3 from Jonathan Wakely ---
Yeah I looked for a dup too, as I'm sure this has been reported before.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114409
--- Comment #14 from Jakub Jelinek ---
I had another look at this.
The reason why this works without the pragmas (i.e. without ANNOTATE_EXPRs) is
that
the WHILE_COND/FOR_COND are handled not by tsubst_expr but tsubst_stmt:
case FOR_STMT:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114665
--- Comment #2 from Robin Dapp ---
Checked with the latest commit on a different machine but still cannot
reproduce the error. PR114668 I can reproduce. Maybe a copy and paste
problem?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114409
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114409
--- Comment #16 from Jakub Jelinek ---
Created attachment 57918
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57918&action=edit
gcc14-pr114409-2.patch
Another possible untested fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114664
--- Comment #9 from Peter Bergner ---
(In reply to Kewen Lin from comment #8)
> I noticed even without -fno-omit-frame-pointer, the test case still fails
> with the same symptom (with error msg rather than ICE), did I miss something?
With no op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95989
--- Comment #24 from Jonathan Wakely ---
> * testsuite/30_threads/jthread/95989.cc: New test.
This testcase fails on FreeBSD 14:
Starting program:
/home/gcc/build/x86_64-unknown-freebsd14.0/libstdc++-v3/testsuite/95989.exe
[New LWP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114630
--- Comment #2 from Nathaniel Shead ---
Created attachment 57919
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57919&action=edit
untested workaround
It looks like r14-8408 just exposed a pre-existing problem by no longer always
discardin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114600
--- Comment #6 from Nathaniel Shead ---
(In reply to Patrick Palka from comment #5)
> (In reply to Nathaniel Shead from comment #4)
> > I'm not yet sure exactly why my patch caused this to start failing though;
> > it sounds like it's exporting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114677
Bug ID: 114677
Summary: apparent -Wanalyzer-fd-leak false positive
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114664
--- Comment #10 from Richard Sandiford ---
(In reply to Peter Bergner from comment #7)
> Then that would seem to indicate that mentioning the frame pointer reg in
> the asm clobber list is an error
Yeah, I agree it's an error. The PR says “ICE”
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114674
Alex Coplan changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113208
--- Comment #24 from Jakub Jelinek ---
As documented in
https://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangling-special-ctor-dtor
C2 is base object constructor (C1 is complete object constructor, C3 is
allocating complete constructor).
C5 is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114678
Bug ID: 114678
Summary: FAIL: gcc.dg/tree-ssa/range-sincos.c
scan-tree-dump-not evrp "link_error" on s390
Product: gcc
Version: unknown
Status: UNCONFIRMED
Sev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114676
Jakub Jelinek changed:
What|Removed |Added
CC||iii at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114664
--- Comment #11 from Peter Bergner ---
(In reply to Richard Sandiford from comment #10)
> Yeah, I agree it's an error. The PR says “ICE”, but is there an internal
> error? The “cannot be used in ‘asm’ here” is a normal user-facing error,
> alb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114664
--- Comment #12 from Richard Sandiford ---
(In reply to Peter Bergner from comment #11)
> > > but how are users supposed to know whether
> > > -fno-omit-frame-pointer is in effect or not? I've looked and there is no
> > > pre-defined macro a us
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114674
Alex Coplan changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |acoplan at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114664
--- Comment #13 from Peter Bergner ---
So I think the conclusion is we should close this as INVALID, correct?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114664
--- Comment #14 from Richard Sandiford ---
Yeah, I think so.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114664
Peter Bergner changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114600
--- Comment #7 from m.cencora at gmail dot com ---
Created attachment 57921
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57921&action=edit
Full "std" module
FYI if you want to stress test the modules impl w.r.t. similar issues, here is
s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114668
--- Comment #2 from Robin Dapp ---
This, again, seems to be a problem with bit extraction from masks.
For some reason I didn't add the VLS modes to the corresponding vec_extract
patterns. With those in place the problem is gone because we go th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114664
--- Comment #16 from Segher Boessenkool ---
Yup, GPR31 is used for the emulated frame pointer, so this is user error:
saying
a fixed-purpose register is clobbered makes no sense. You are not allowed to
use any register that the compiler uses fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114600
--- Comment #8 from Jonathan Wakely ---
Thanks. I hope we'll end up auto-generating a file like that from
../gcc/cp/cxxapi-data.csv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104772
Bug 104772 depends on bug 99708, which changed state.
Bug 99708 Summary: __SIZEOF_FLOAT128__ not defined on powerpc64le-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
Michael Meissner changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114679
Bug ID: 114679
Summary: .file directive missing on MIPS ports when debug
symbols are enabled.
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #57 from Segher Boessenkool ---
(In reply to Richard Biener from comment #56)
> The fix was reverted but will be re-instantiated for GCC 15 by me.
And I still protest.
PR101523 is a very serious problem, way way way more "P1" than
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #58 from Jakub Jelinek ---
(In reply to Segher Boessenkool from comment #57)
> (In reply to Richard Biener from comment #56)
> > The fix was reverted but will be re-instantiated for GCC 15 by me.
>
> And I still protest.
>
> PR1015
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6
--- Comment #27 from g.peterh...@t-online.de ---
Hi Matthias,
thanks for your benchmark. I still have 2 questions:
1) Accuracy
The frexp/ldexp variant seems to be the most accurate; is that correct? Then
other constants would have to be used in h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114672
--- Comment #2 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:912753cc5f18d786e334dd425469fa7f93155661
commit r14-9892-g912753cc5f18d786e334dd425469fa7f93155661
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114672
Richard Biener changed:
What|Removed |Added
Known to work||14.0
--- Comment #3 from Richard Biene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114676
--- Comment #7 from Richard Biener ---
The question is what the intrinsic constraints are on TBAA.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6
--- Comment #28 from Jakub Jelinek ---
As long as the scale is a power of two or 1.0 / power of two, I don't see why
any version wouldn't be inaccurate.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114678
Richard Biener changed:
What|Removed |Added
Blocks||85316
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114677
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114678
--- Comment #2 from Andrew Pinski ---
(In reply to Richard Biener from comment #1)
> I guess VRP should handle __builtin_isinf and friends.
Like was posted here:
https://gcc.gnu.org/pipermail/gcc-patches/2024-March/648303.html ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #59 from Richard Biener ---
(In reply to Segher Boessenkool from comment #57)
> (In reply to Richard Biener from comment #56)
> > The fix was reverted but will be re-instantiated for GCC 15 by me.
>
> And I still protest.
>
> PR101
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106500
--- Comment #7 from GCC Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:ded646c91d2c0fb908faf6fa8fe1df0d7df49d16
commit r14-9893-gded646c91d2c0fb908faf6fa8fe1df0d7df49d16
Author: Harald Anlauf
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103496
--- Comment #3 from anlauf at gcc dot gnu.org ---
The code in comment#0 compiles at r14-9893-gded646c91d2c0f
and gives the indicated results.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95989
--- Comment #25 from Andrew Pinski ---
(In reply to Jonathan Wakely from comment #24)
> > * testsuite/30_threads/jthread/95989.cc: New test.
>
> This testcase fails on FreeBSD 14:
Related PRs there: PR 103444 and PR 82635; it might
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104585
--- Comment #4 from Bill Long ---
Any prediction for this one? (I realize you still have F2018 an F2023 to get
through.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114665
--- Comment #3 from Patrick O'Neill ---
Created attachment 57922
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57922&action=edit
Generated assembly files
Hmm doesn't look like it from my side - maybe there's some stack related
weirdness
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #60 from Sarah Julia Kriesch ---
I have to agree with Richard. This problem has been serious for a long time but
has been ignored by IBM based on distribution choices.
Anyway, we want to live within the open source community without
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112560
--- Comment #10 from Segher Boessenkool ---
It is still wrong. You're trying to sweep tour wrong assumptions under the
rug,
but they will only rear up elsewhere. Just fix the actual *target* problem!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6
--- Comment #29 from g.peterh...@t-online.de ---
(In reply to Jakub Jelinek from comment #28)
> As long as the scale is a power of two or 1.0 / power of two, I don't see
> why any version wouldn't be inaccurate.
Yes, but the constant scale_up is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114680
Bug ID: 114680
Summary: libstdc++-v3/include/ext/mt_allocator.h:142: possible
performance problem ?
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112560
--- Comment #11 from Uroš Bizjak ---
(In reply to Segher Boessenkool from comment #10)
> It is still wrong. You're trying to sweep tour wrong assumptions under the
> rug,
> but they will only rear up elsewhere. Just fix the actual *target* pro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114680
--- Comment #1 from Jonathan Wakely ---
I doubt anybody uses that code anyway.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114680
--- Comment #2 from Jonathan Wakely ---
There's line 685 too
void
_M_set_options(__pool_base::_Tune __t)
{ __policy_type::_S_get_pool()._M_set_options(__t); }
/x86_64-pc-linux-gnu-as --enable-libsanitizer
--disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-9885-20240410075703-g109f1b28fc9-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240410 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114682
Bug ID: 114682
Summary: const_array[i].b where i is PHI<0,1,2> is not folded
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114682
--- Comment #1 from Andrew Pinski ---
Note I was imspired to look into this because of
https://github.com/llvm/llvm-project/issues/88274 (note LLVM does a worse job
here and does not constant loads the string either).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106500
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
1 - 100 of 160 matches
Mail list logo
