https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #32 from Florian Weimer ---
There's this in standards.texi:
Most of the compiler support routines used by GCC are present in
@file{libgcc}, but there are a few exceptions. GCC requires the
freestanding environment provide @code{memc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #33 from rguenther at suse dot de ---
On Thu, 23 Nov 2023, fw at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
>
> --- Comment #32 from Florian Weimer ---
> There's this in standards.texi:
>
> Most of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110348
--- Comment #14 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:6ce952188ab39e303e4f63e474b5cba83b5b12fd
commit r14-5771-g6ce952188ab39e303e4f63e474b5cba83b5b12fd
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112672
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112673
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112674
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2023-11-23
Assignee|unassign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112675
Richard Biener changed:
What|Removed |Added
Keywords||testsuite-fail, wrong-code
Target Mi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112676
Richard Biener changed:
What|Removed |Added
Target||x86_64-*-*
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #34 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:7758cb4b53e8a33642709402ce582f769eb9fd18
commit r14-5772-g7758cb4b53e8a33642709402ce582f769eb9fd18
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #35 from Jakub Jelinek ---
Note, clang makes the same assumption apparently (while MSVC emits rep movs
inline and
ICC either that, or calls _intel_fast_memcpy). As I mentioned earlier, if
glibc and other libraries provide an alias to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110348
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 110348, which changed state.
Bug 110348 Summary: [C++26] P2741R3 - User-generated static_assert messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110348
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110345
--- Comment #2 from Jakub Jelinek ---
The fallthrough stuff is still outstanding I think and I'll have a look.
part is done in r14-5561-g52eedfa00960f2d255ec542626e3531a65aa8bb8
The rest unresolved.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70
--- Comment #12 from Costas Argyris ---
I think this can be considered as fixed now, since the new
--disable-win32-utf8-manifest configure option leaves out the utf8 manifest and
you shouldn't have a problem running gcc even on XP if you configu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110348
--- Comment #16 from corentinjabot at gmail dot com ---
(In reply to Jakub Jelinek from comment #15)
> Now implemented for GCC 14.
Thanks for working on this
> As I wrote already in the PR, in addition to looking through the paper
> I l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112547
Filip Kastl changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 112547, which changed state.
Bug 112547 Summary: 9% exec time regression of 462.libquantum SPEC on AMD zen4
CPU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112547
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112672
Uroš Bizjak changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110348
--- Comment #17 from Jakub Jelinek ---
(In reply to corentinjabot from comment #16)
> Clang always evaluate if i recall, the error is actually a warning that
> defaults to error.
I initially had a warning for it, but Jason preferred not to warn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112677
Bug ID: 112677
Summary: ASAN reports stack-buffer-overflow in
tree-vect-loop.cc vect_is_simple_use when compiling
with -mavx512
Product: gcc
Version: 14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110879
--- Comment #5 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:256d64b3460807f33ff2f70e676801bdcf908c1c
commit r14-5774-g256d64b3460807f33ff2f70e676801bdcf908c1c
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112336
--- Comment #5 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:f9982ef4f55bd3a63745e03ac6d68b4a92fa8bce
commit r14-5776-gf9982ef4f55bd3a63745e03ac6d68b4a92fa8bce
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112336
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112406
Tamar Christina changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112670
--- Comment #2 from CVS Commits ---
The master branch has been updated by Robin Dapp :
https://gcc.gnu.org/g:35a688f434159a923420310860c5bc721e29a741
commit r14-5777-g35a688f434159a923420310860c5bc721e29a741
Author: Juzhe-Zhong
Date: Thu No
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112599
--- Comment #3 from CVS Commits ---
The master branch has been updated by Robin Dapp :
https://gcc.gnu.org/g:35a688f434159a923420310860c5bc721e29a741
commit r14-5777-g35a688f434159a923420310860c5bc721e29a741
Author: Juzhe-Zhong
Date: Thu No
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112670
JuzheZhong changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112678
Bug ID: 112678
Summary: Massive slowdown of compilation time with PGO
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: compile-time-hog
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110279
--- Comment #2 from CVS Commits ---
The master branch has been updated by Di Zhao :
https://gcc.gnu.org/g:746344dd53807d840c29f52adba10d0ab093bd3d
commit r14-5779-g746344dd53807d840c29f52adba10d0ab093bd3d
Author: Di Zhao
Date: Thu Nov 9 15:
t/GCC/master/gcc/cfgexpand.cc:6835
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112676
--- Comment #1 from Manuel Lauss ---
Created attachment 56671
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56671&action=edit
another testcase
Another testcase, one of a few from virtualbox:
g++ -O2 -march=znver4 -mtune=znver4 -mno-avx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112678
Sam James changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112680
Bug ID: 112680
Summary: g++-13 segfault on std::regex_match with c++11 or
above -O2 and lto
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112678
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org,
th-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-5779-20231123205631-g746344dd538-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231123 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112682
Bug ID: 112682
Summary: More efficient std::basic_string move construction
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111641
Rainer Orth changed:
What|Removed |Added
Host|hppa*-*-linux* |hppa*-*-linux*,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #36 from Rich Felker ---
> the assembly generated by the current implementations already supports that
> case.
Our memcpy is not written in asm but in C, and it has the restrict qualifier on
src and dest. This entitles a compiler to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112569
TC changed:
What|Removed |Added
CC||rs2740 at gmail dot com
--- Comment #1 from TC --
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #37 from Rich Felker ---
Also: has anyone even looked at what happens if a C memcpy with proper use of
restrict gets LTO-inlined into a caller with GCC-generated memcpy calll where
src==dest? That sounds like a case likely to blow up.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112593
Rainer Orth changed:
What|Removed |Added
Summary|FAIL: |FAIL:
|26_numerics/head
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112681
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111948
Jonathan Wakely changed:
What|Removed |Added
Depends on||112439
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112683
Bug ID: 112683
Summary: Optimizing memcpy range by extending to word bounds
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #38 from Tim Ruffing ---
(In reply to Rich Felker from comment #36)
> If you're happy with a branch, you could probably take restrict off the
> arguments and do something like:
>
> if (src==dest) return;
> const char *restrict src2 =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112593
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2023-11-23
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112678
--- Comment #2 from Jan Hubicka ---
Seems we changed default to locking increments.
jh@ryzen4:/tmp> cat t.C
void
test()
{
}
jh@ryzen4:/tmp> ~/trunk-install/bin/g++ -O2 -fprofile-generate t.C -S ; grep
lock t.s
lock addl $1, __gcov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112678
--- Comment #3 from CVS Commits ---
The master branch has been updated by Sebastian Huber :
https://gcc.gnu.org/g:8674d70ce37ca3249a641fb418c6849d4f95f348
commit r14-5783-g8674d70ce37ca3249a641fb418c6849d4f95f348
Author: Sebastian Huber
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #39 from Tim Ruffing ---
(In reply to Rich Felker from comment #36)
> Our memcpy is not written in asm but in C, and it has the restrict qualifier
> on src and dest.
For my curiosity, can you point me to this implementation? I coul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #40 from Sam James ---
https://git.musl-libc.org/cgit/musl/tree/src/string/memcpy.c#n5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112680
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112666
--- Comment #2 from Francisco Paisana ---
Jonathan Wakely, thanks a lot for your clarification. I finally got it.
In summary, we established that:
1. if a type T (in my case C) has no user-defined ctor, it will be
zero-initialized.
2. and for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112680
Jonathan Wakely changed:
What|Removed |Added
Component|lto |c++
--- Comment #1 from Jonathan Wake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112680
Jonathan Wakely changed:
What|Removed |Added
Blocks||102445
--- Comment #2 from Jonathan W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112666
Francisco Paisana changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89316
--- Comment #15 from CVS Commits ---
The master branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:2f3f8952ff1736dd6a087ddb4106077db3502bb9
commit r14-5784-g2f3f8952ff1736dd6a087ddb4106077db3502bb9
Author: Uros Bizjak
Date: Thu N
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112653
--- Comment #7 from Jan Hubicka ---
Thanks for explanation. I think it is quite common pattern that new object is
construted and worked on and later returned, so I think we ought to handle this
correctly.
Another example just came up in
https:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112672
--- Comment #5 from CVS Commits ---
The master branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:b2d17bdd45b582b93e89c00b04763a45f97d7a34
commit r14-5785-gb2d17bdd45b582b93e89c00b04763a45f97d7a34
Author: Uros Bizjak
Date: Thu N
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89316
Uroš Bizjak changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #41 from post+gcc at ralfj dot de ---
> This entitles a compiler to emit asm equivalent to if (src==dest) system("rm
> -rf /") if it likes.
No it does not. restrict causes UB if the two pointers are used to access the
same memory. It
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112666
--- Comment #4 from Francisco Paisana ---
One last thing, I might have misread this as well.
> "Zero-initialization is performed in the following situations:
> ...
> 2) As part of value-initialization sequence [...] for members of
> value-init
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112666
--- Comment #5 from Jonathan Wakely ---
(In reply to Francisco Paisana from comment #4)
> One last thing, I might have misread this as well.
>
> > "Zero-initialization is performed in the following situations:
> > ...
> > 2) As part of value-i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112679
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112666
Sam James changed:
What|Removed |Added
Resolution|FIXED |INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112541
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111641
Jonathan Wakely changed:
What|Removed |Added
CC||redi at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111641
Jonathan Wakely changed:
What|Removed |Added
Host|hppa*-*-linux*, |
|*-*-solaris2.11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112673
Jakub Jelinek changed:
What|Removed |Added
CC|jakub at redhat dot com|jakub at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112673
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111055
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:7a6a29c455e7755b501c0006e39beb4e56ec2729
commit r14-5794-g7a6a29c455e7755b501c0006e39beb4e56ec2729
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111055
Jonathan Wakely changed:
What|Removed |Added
Assignee|redi at gcc dot gnu.org|unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86776
--- Comment #2 from CVS Commits ---
The master branch has been updated by Georg-Johann Lay :
https://gcc.gnu.org/g:9a3c40af7f7dd218cc2ebaa3a70f3317f7316ceb
commit r14-5796-g9a3c40af7f7dd218cc2ebaa3a70f3317f7316ceb
Author: Georg-Johann Lay
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86776
Georg-Johann Lay changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86772
Bug 86772 depends on bug 86776, which changed state.
Bug 86776 Summary: Avr port needs updating for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86776
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112609
--- Comment #2 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:0c2ecfd4a29161d6c2bd3a83335387f42ff38ffe
commit r14-5797-g0c2ecfd4a29161d6c2bd3a83335387f42ff38ffe
Author: Harald Anlauf
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104819
--- Comment #8 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:7646b5d88056cf269ff555afe95bc361dcf5e5c0
commit r14-5798-g7646b5d88056cf269ff555afe95bc361dcf5e5c0
Author: Harald Anlauf
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112643
--- Comment #26 from anlauf at gcc dot gnu.org ---
(In reply to Urs Janßen from comment #25)
> (In reply to Haochen Jiang from comment #24)
> > Patch aims to fix that:
> >
> > https://gcc.gnu.org/pipermail/gcc-patches/2023-November/637865.html
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #42 from Rich Felker ---
> I'm not saying that such an implementation will be a good idea, but just a
> remark: You could, in fact, keep restrict for the arguments in this case,
> because the object pointed to by src and dest is not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #43 from post+gcc at ralfj dot de ---
That is not my reading of the standard, but absent a proper (formal,
mathematical) spec I guess it is hard to tell.
With your reading, "if ((uintptr_t)src == 0x400400)" is UB, since changing the
"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112681
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
Summary|[14 Regression] IC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112681
--- Comment #2 from Jakub Jelinek ---
Doesn't need the virtual method nor C++:
struct S { void *c; char d[16]; } a, b;
int
foo (void)
{
return __builtin_memcmp (a.d, b.d, sizeof (a.d)) != 0;
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112676
--- Comment #2 from Manuel Lauss ---
I think PR112681 is the same issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112676
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112681
Andrew Pinski changed:
What|Removed |Added
CC||manuel.lauss at googlemail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112681
--- Comment #4 from Jakub Jelinek ---
Flags can be just -O2 -msse4.1 -mno-sse4.2 as well or even -O2 -msse4.2
-mno-avx.
--- gcc/config/i386/i386-expand.cc.jj 2023-11-21 09:31:35.792395304 +0100
+++ gcc/config/i386/i386-expand.cc 2023-11-2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112681
--- Comment #5 from Jakub Jelinek ---
Or maybe better
--- gcc/config/i386/i386-expand.cc.jj 2023-11-21 09:31:35.792395304 +0100
+++ gcc/config/i386/i386-expand.cc 2023-11-23 20:57:57.128721762 +0100
@@ -2453,7 +2453,8 @@ ix86_expand_branc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112681
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112672
--- Comment #6 from CVS Commits ---
The releases/gcc-13 branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:d035b57d51167af805ccc91ee0492c8b27e22184
commit r13-8092-gd035b57d51167af805ccc91ee0492c8b27e22184
Author: Uros Bizjak
Date
nary-trunk-r14-5791-20231123115417-g24592abd68e-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231123 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
--- Comment #44 from Rich Felker ---
My naive expectation is that "if ((uintptr_t)src == 0x400400)" is and should be
UB, but I may be misremembering the details of the formalism by which the spec
for restrict is implemented.
If so, that's kinda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112681
--- Comment #7 from Manuel Lauss ---
(In reply to Jakub Jelinek from comment #6)
> Created attachment 56676 [details]
> gcc14-pr112681.patch
>
> Full untested patch.
Fixes all ICEs I've seen today.
Thank you!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112609
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112685
Bug ID: 112685
Summary: missed-optimization: division / modulo loops
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112685
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112685
--- Comment #1 from Andrew Pinski ---
I thought I had saw this a while back.
Note the Linux kernel does this kind of loop explicity to avoid the division
though as the cases where it does is known to be only a few iterations (1 or 2)
to get the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111880
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112683
Andrew Pinski changed:
What|Removed |Added
Component|target |middle-end
--- Comment #1 from Andrew P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112685
--- Comment #2 from gooncreeper ---
(In reply to Andrew Pinski from comment #1)
> I thought I had saw this a while back.
>
> Note the Linux kernel does this kind of loop explicity to avoid the division
> though as the cases where it does is kno
//binary-trunk-r14-5791-20231123115417-g24592abd68e-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231123 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112645
--- Comment #2 from gooncreeper ---
I am going to move the second problem to it's own bug since I realize it
actually quite a different problem, and deserves it's own thread of discussion.
1 - 100 of 153 matches
Mail list logo