https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113159
--- Comment #16 from Yury Gribov ---
(In reply to Xi Ruoyao from comment #15)
> (In reply to Yury Gribov from comment #14)
> > (In reply to Xi Ruoyao from comment #12)
> > > Also note even
> > >
> > > bool cmp(Element a, Element b) { return fal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113159
--- Comment #15 from Xi Ruoyao ---
(In reply to Yury Gribov from comment #14)
> (In reply to Xi Ruoyao from comment #12)
> > Also note even
> >
> > bool cmp(Element a, Element b) { return false; }
> >
> > is a *valid* comparator, per the stand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113159
--- Comment #14 from Yury Gribov ---
(In reply to Xi Ruoyao from comment #12)
> Also note even
>
> bool cmp(Element a, Element b) { return false; }
>
> is a *valid* comparator, per the standard.
Hm, doesn't it violate the asymmetry axiom (cmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113159
--- Comment #13 from Yury Gribov ---
(In reply to Xi Ruoyao from comment #11)
> (In reply to Yury Gribov from comment #10)
> > As a compiler user I would actually love my STL to crash fast on invalid
> > comparators rather than produce unpredict
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118142
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #8 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113159
--- Comment #12 from Xi Ruoyao ---
Also note even
bool cmp(Element a, Element b) { return false; }
is a *valid* comparator, per the standard. Though it'll likely produce
completely meaningless result, it's just your own logical error as it vi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113159
--- Comment #11 from Xi Ruoyao ---
(In reply to Yury Gribov from comment #10)
> As a compiler user I would actually love my STL to crash fast on invalid
> comparators rather than produce unpredictable and meaningless results which
> will cause m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118166
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118171
Andrew Pinski changed:
What|Removed |Added
Target|riscv64-unknown-linux-gnu |riscv64-unknown-linux-gnu
l: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.0 20241221 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113159
Yury Gribov changed:
What|Removed |Added
CC||ygribov at gcc dot gnu.org
--- Comment #1
20241221071321-r15-6405-g0b63840e07132f-checking-yes-rtl-df-extra-riscv64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.0 20241221 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118169
--- Comment #4 from Andrew Pinski ---
It worked with 20241203.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118169
--- Comment #3 from Sam James ---
Created attachment 59945
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59945&action=edit
partial.ii.xz
It's going pretty slowly, still going ofc, but partial reduction attached.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118123
--- Comment #4 from Sam James ---
(In reply to Mark Harmstone from comment #3)
> Fixed by commit 0b63840e0713.
Mark, if you change your bugzilla email to maharmst...@gcc.gnu.org, you'll have
permissions to modify bugs.
Also, reminder to do the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113239
Dimitry Andric changed:
What|Removed |Added
CC||dimitry at andric dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118169
--- Comment #2 from Sam James ---
g++ -O1 -march=icelake-server is enough, I'll reduce it now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118169
--- Comment #1 from Sam James ---
Created attachment 59944
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59944&action=edit
avd_parser.cpp.ii.xz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118169
Bug ID: 118169
Summary: [15 regression] ICE when building mlt-7.28.0 (error:
non-trivial conversion in ‘integer_cst’)
Product: gcc
Version: 15.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118168
Bug ID: 118168
Summary: -Wmisleading-indentation causes 10x+ overhead or
higher (visible on mypy-1.13.0)
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118167
--- Comment #4 from Sam James ---
(BTW, wrt https://github.com/llvm/llvm-project/issues/101370, I did compare
Clang's https://godbolt.org/z/nsd7sEe4M with https://godbolt.org/z/eW1PPjasj
for us but we seem to do fine there.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118167
--- Comment #3 from Sam James ---
We optimise the assert() out in sum_span_as_indices, but not in
sum_span_as_pointers where pointers are used.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118167
--- Comment #2 from Sam James ---
Created attachment 59942
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59942&action=edit
jGYh6Tc13.cxx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118167
--- Comment #1 from Sam James ---
> godbolt link with more explanation: https://godbolt.org/z/fjevMcYKf
Make that https://godbolt.org/z/jGYh6Tc13.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118167
Bug ID: 118167
Summary: Loop invariant is not deduced in C++-iterator-style
loop over pointers
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: missed-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109442
--- Comment #39 from Jonathan Wakely ---
(In reply to Antony Polukhin from comment #37)
> Unfortunately the examples are not artificial. People do write business
> logic code as `vector_variable == std::vector{"*"}`. That
> particular example is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118166
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118166
--- Comment #1 from Andrew Pinski ---
Note there is an extra cost of moving between the gprs and vector registers. In
this case I suspect using gprs is still cheaper even if size might be slightly
larger
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109442
--- Comment #38 from Jonathan Wakely ---
That doesn't mean it has to be fast though. If people want to write slow code,
they get slow programs!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104819
--- Comment #20 from anlauf at gcc dot gnu.org ---
Still missing:
- handling of CLASS/unlimited polyporphic assumed-rank dummies
- tightening of checks according to F2008/F2018
- fix testsuite fallout due to some invalid testcases (see comment#7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109224
--- Comment #7 from GCC Commits ---
The trunk branch has been updated by Arsen Arsenovic :
https://gcc.gnu.org/g:7d83a32aacd6005c0c038c74562e35d70f6a77a8
commit r15-6409-g7d83a32aacd6005c0c038c74562e35d70f6a77a8
Author: Arsen ArsenoviÄ
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104819
--- Comment #19 from GCC Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:d637e6d069ade775a4b61f51fff61fe4cce01c36
commit r15-6408-gd637e6d069ade775a4b61f51fff61fe4cce01c36
Author: Harald Anlauf
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118164
Sam James changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org
Keyword
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118164
--- Comment #2 from Nicolas Boulenguez ---
As the title says, this issue seems specific to ARM.
The full build log for the GCC I have tested is here:
https://buildd.debian.org/status/fetch.php?pkg=gcc-14&arch=armel&ver=14.2.0-11&stamp=173422819
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118163
Simon Martin changed:
What|Removed |Added
Target Milestone|--- |15.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118075
Jeffrey A. Law changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116308
Jeffrey A. Law changed:
What|Removed |Added
CC||patrick at rivosinc dot com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113239
--- Comment #11 from Jeffrey A. Law ---
I haven't verified, but I would suggest checking if that store conflicts with
the loads. If it doesn't, then I would expect the loads to get CSE'd which in
turn would expose the key equivalence needed to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118084
Jeffrey A. Law changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118084
--- Comment #1 from GCC Commits ---
The master branch has been updated by Jeff Law :
https://gcc.gnu.org/g:145e462d557af537d90ef6da1391a57603c6fcf0
commit r15-6407-g145e462d557af537d90ef6da1391a57603c6fcf0
Author: Jeff Law
Date: Sat Dec 21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118166
Bug ID: 118166
Summary: simple bit operations for __int128 do not use vector
operations/registers
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: n
u-as --enable-libsanitizer
--disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-20241221071321-r15-6405-g0b63840e07132f-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.0 20241221 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118059
Paul Thomas changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118164
Eric Botcazou changed:
What|Removed |Added
Component|ada |target
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118032
--- Comment #24 from Filip Kastl ---
Thanks for the preprocessed file!
I've looked at -ftime-report to see if the extra time was spent in switch
lowering and found out it is not! Apparently the change in behavior of switch
lowering has an effe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118164
Bug ID: 118164
Summary: executable fails with storage_error on arm when built
with -O1 -fstack-clash-protection
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116254
--- Comment #14 from Paul Thomas ---
Created attachment 59939
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59939&action=edit
Fix for this PR
(In reply to Richard Sandiford from comment #10)
Hi Richard,
The temporary array descriptor is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118163
Simon Martin changed:
What|Removed |Added
Ever confirmed|0 |1
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118163
Bug ID: 118163
Summary: [15 Regression] Diagnostic not fully silenced by
-Wno-template-body
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: minor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109442
--- Comment #37 from Antony Polukhin ---
Unfortunately the examples are not artificial. People do write business logic
code as `vector_variable == std::vector{"*"}`. That particular
example is taken from our codebase and I easily find 4 exact ma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115008
Nathaniel Shead changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |nshead at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118146
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118145
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.3
--- Comment #4 from Richard Biene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118140
Richard Biener changed:
What|Removed |Added
Target Milestone|15.0|14.3
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118138
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118136
--- Comment #12 from Richard Biener ---
I think it should work to compile the startfile with -flto, GCC just assumes
main() is called once I think. The diagnostic is "unfortunate" I'd say,
but I would say you should just ignore it? I'd say the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118154
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2024-12-21
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48696
--- Comment #21 from rguenther at suse dot de ---
On Fri, 20 Dec 2024, ptomsich at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48696
>
> ptomsich at gcc dot gnu.org changed:
>
>What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115008
--- Comment #6 from Gerald Pfeifer ---
(In reply to Gerald Pfeifer from comment #4)
> Let me change gcc/cp/module.cc as follows
>
> -#ifndef HAVE_POSIX_FALLOCATE
>#define posix_fallocate(fd,off,len) ftruncate (fd, off + len)
> -#endif
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109442
--- Comment #36 from Richard Biener ---
I believe strlen_pass::handle_builtin_memcmp should eventually move to forwprop
(fold_stmt may not inspect immediate uses). That would help this particular
case.
Note that in general value-numbering coul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102259
--- Comment #17 from Michel Morin ---
> I thought I saw some docs saying >= INT_MAX fails, but maybe I'm wrong.
> The Rust change uses INT_MAX - 1
The comment in the Rust code says
On OSX ... by rejecting any read with a size larger than or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118142
--- Comment #7 from zhangtianhao (F) ---
(In reply to Andrew Pinski from comment #6)
> There is no way to test this with upstream sources so won't fix.
Hello, I'm not sure about the relationship between this problem and glibc
ilp32. Can you exp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118142
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118142
zhangtianhao (F) changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|WONTF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117639
Andrew Pinski changed:
What|Removed |Added
Blocks||118130
--- Comment #2 from Andrew Pinsk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77689
--- Comment #20 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #19)
> for the original testcase in comment #0, renaming main to f and changing the
> return type to void, the trunk of GCC can optimize the function to just a
> retur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102259
--- Comment #16 from Jonathan Wakely ---
Yes, I saw the freebsd changes and came to the same conclusion. Looping on 2gb
chunks won't hurt much.
I thought I saw some docs saying >= INT_MAX fails, but maybe I'm wrong. The
Rust change uses INT_MAX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112440
--- Comment #3 from Andrew Pinski ---
One missed optimization is:
[local count: 58465242]:
if (summ_2(D) <= 29)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 29232621]:
_116 = summ_2(D) + 1;
[local count: 105237435
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113239
Andrew Pinski changed:
What|Removed |Added
Keywords||needs-bisection
--- Comment #10 from An
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18
Andrew Pinski changed:
What|Removed |Added
Known to fail||13.2.0
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109205
--- Comment #7 from Andrew Pinski ---
(In reply to Jonathan Wakely from comment #4)
> I added hints to size() and capacity() and it caused regressions, see PR
> 110060
>
> It makes it less likely for size() to be inlined, and causes:
>
> FAIL:
71 matches
Mail list logo
