https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113014
--- Comment #2 from Robin Dapp ---
Yes, that's right.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113014
--- Comment #3 from JuzheZhong ---
(In reply to Robin Dapp from comment #2)
> Yes, that's right.
It seems that I don't need to optimize it since we will eventually have
late-combine.
Could you tell what status of late-combine PASS ?
Will it b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113014
--- Comment #4 from Robin Dapp ---
Richard has posted it and asked for reviews. I have tested it and we have
several testsuite regressions with it but no severe ones. Most or all of them
are dump fails because we combine into vx variants that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112992
--- Comment #8 from GCC Commits ---
The master branch has been updated by hongtao Liu :
https://gcc.gnu.org/g:be0ff0866a6f072ccfbbb3a3c2079adf1db51aa1
commit r14-6534-gbe0ff0866a6f072ccfbbb3a3c2079adf1db51aa1
Author: liuhongt
Date: Wed Dec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112998
Xi Ruoyao changed:
What|Removed |Added
Resolution|--- |DUPLICATE
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112986
--- Comment #8 from Xi Ruoyao ---
*** Bug 112998 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112329
Xi Ruoyao changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112986
--- Comment #9 from Xi Ruoyao ---
*** Bug 112329 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112112
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
Statu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112986
--- Comment #10 from Xi Ruoyao ---
*** Bug 112112 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113002
Filip Kastl changed:
What|Removed |Added
CC||fkastl at suse dot cz
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113017
Bug ID: 113017
Summary: ICE in delete_unmarked_insns, at dce.cc:653
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, needs-bisection
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111807
--- Comment #10 from GCC Commits ---
The master branch has been updated by Martin Jambor :
https://gcc.gnu.org/g:96e1978b213482fc4c25693b91ae2ead481af620
commit r14-6535-g96e1978b213482fc4c25693b91ae2ead481af620
Author: Martin Jambor
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113018
Bug ID: 113018
Summary: ICE in gimple_convert, gimple-fold.cc during the SLP
pass
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112997
Arsen Arsenović changed:
What|Removed |Added
CC||arsen at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80283
--- Comment #39 from Richard Sandiford ---
(In reply to Andrew Pinski from comment #38)
> For aarch64, the test from comment #11 is so much worse on the trunk than in
> GCC 13.2.0.
I've been working on a fix for that. I'm hoping to post it today
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112678
Filip Kastl changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113007
--- Comment #4 from Pavel Novikov ---
Interesting. Thank you for explanation.
Indeed the standard says all over that narrowing conversion in initialization
is prohibited, though this code compiles:
int i = 42;
bool b[] = {i}; // narrow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112994
--- Comment #8 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:90c9403f89d3c55512ae83dd20e2023c2e4430f4
commit r14-6537-g90c9403f89d3c55512ae83dd20e2023c2e4430f4
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112994
--- Comment #9 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:2c92551405bc8616f456e5cbc696ab0292c7ff00
commit r14-6538-g2c92551405bc8616f456e5cbc696ab0292c7ff00
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113019
Bug ID: 113019
Summary: [NOT A BUG] Multi-architecture binaries for Linux
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113003
--- Comment #1 from Jakub Jelinek ---
Slightly reduced:
int
foo (_BitInt(7) x)
{
return __builtin_mul_overflow_p (x,
1046555807606105294475452482332716433408wb, 0);
}
Ugh, another special case where we don't detect the need to lower, next to
s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113003
--- Comment #2 from Jakub Jelinek ---
int
bar (unsigned __int128 x)
{
return __builtin_sub_overflow_p (340282366920938463463374607431768211457uwb,
x, 0);
}
while it doesn't ICE is also something that has to be lowered and not left
until expan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113019
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
CC||ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113019
Arsen Arsenović changed:
What|Removed |Added
CC||arsen at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113013
Siddhesh Poyarekar changed:
What|Removed |Added
Keywords|ice-on-valid-code |ice-on-invalid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113012
--- Comment #5 from Jakub Jelinek ---
(In reply to Andrew Pinski from comment #3)
> Note I am not shocked that xorg has undefined code in it too.
Do you know about any large package which doesn't have any undefined code in
it?
Anyway, this is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112938
--- Comment #5 from GCC Commits ---
The master branch has been updated by Alexandre Oliva :
https://gcc.gnu.org/g:37afeec8a635153ccd4e91bd686c93217706894d
commit r14-6546-g37afeec8a635153ccd4e91bd686c93217706894d
Author: Alexandre Oliva
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112938
--- Comment #6 from GCC Commits ---
The master branch has been updated by Alexandre Oliva :
https://gcc.gnu.org/g:e1e71b4e0681974b3db41afa7fc18720a30d6848
commit r14-6547-ge1e71b4e0681974b3db41afa7fc18720a30d6848
Author: Alexandre Oliva
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113020
Bug ID: 113020
Summary: Explicit template instantiation of template
specialization using a template base class fails after
extern template declaration with linker error
Pro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113000
--- Comment #1 from Richard Biener ---
Note you then need a way to cope with LTO.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113001
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113012
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
--- Comment #6 from Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113012
Richard Biener changed:
What|Removed |Added
Priority|P1 |P2
Target Milestone|14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113013
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113018
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2023-12-14
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113012
--- Comment #7 from Jakub Jelinek ---
Obviously we shouldn't ICE on this.
But, saying 0 as usable size on such UB pointer is I think completely valid
(making it clear that you can't really dereference such pointer nor anything
derived from it, e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112655
--- Comment #2 from GCC Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:8cf5afba5dc482fe7063654720bfb0c45354998c
commit r14-6549-g8cf5afba5dc482fe7063654720bfb0c45354998c
Author: David Malcolm
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112655
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113007
--- Comment #5 from Jonathan Wakely ---
(In reply to Pavel Novikov from comment #4)
> Indeed the standard says all over that narrowing conversion in
> initialization is prohibited, though this code compiles:
>
> int i = 42;
> bool b[] =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113012
--- Comment #8 from Jakub Jelinek ---
Slightly more readable testcase:
int *
foo (int x, int y, int z, int w)
{
int *p = __builtin_malloc (z * sizeof (int));
int *q = p - 1;
while (--x > 0)
{
if (w + 1 > y)
q = p - 1;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113007
--- Comment #6 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #5)
> The _Arr struct is needed to ensure that we're trying to convert to T{1} not
Oops, I mean T[1] not T{1} of course!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113021
Bug ID: 113021
Summary: [constexpr] gcc rejects initializing struct containing
vector during constant evaluation depending if the
struct also contains other member
Product:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113018
--- Comment #2 from Richard Biener ---
OK, so we're running into
/* When a BB reduction doesn't have an even number of lanes
strip it down, treating the remaining lane as scalar.
??? Selecting the optimal set of lanes to vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113019
--- Comment #3 from ultrafine at gmx dot com ---
Yeah, I'm looking forward to being able to compile this way:
-march=x86-64 -mextra-arch=x86-64-v3
And do _nothing_ else and get a single binary. And then at runtime the
appropriate code for the d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113019
--- Comment #3 from ultrafine at gmx dot com ---
Yeah, I'm looking forward to being able to compile this way:
-march=x86-64 -mextra-arch=x86-64-v3
And do _nothing_ else and get a single binary. And then at runtime the
appropriate code for the d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113019
--- Comment #5 from Artem S. Tashkinov ---
(In reply to ktkachov from comment #1)
> GCC provides the Function Multiversioning feature that's supported on some
> architectures:
> https://gcc.gnu.org/onlinedocs/gcc/Function-Multiversioning.html
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113022
Bug ID: 113022
Summary: GCN offloading bricked by "amdgcn: Work around XNACK
register allocation problem"
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113023
Bug ID: 113023
Summary: RISCV redundant code for loading fixed address
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112793
--- Comment #13 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:d782ec8362eadc3169286eb1e39c631effd02323
commit r14-6550-gd782ec8362eadc3169286eb1e39c631effd02323
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112906
Alex Coplan changed:
What|Removed |Added
Keywords||patch
--- Comment #4 from Alex Coplan --
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112793
Richard Biener changed:
What|Removed |Added
Target Milestone|14.0|11.5
Summary|[14 regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112941
--- Comment #3 from Jakub Jelinek ---
Simplified:
unsigned _BitInt(2049)
foo (unsigned _BitInt(6384) x, _BitInt(8) y)
{
return x * y;
}
_BitInt(2049)
bar (unsigned _BitInt(6384) x, _BitInt(1023) y)
{
return x * y;
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113007
--- Comment #7 from Pavel Novikov ---
(In reply to Jonathan Wakely from comment #5&6)
Got it.
Thank you for taking the time to expansively explain what I left out, and
confirming my understanding.
Now it's time to file a bug in MSVC's standar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111515
--- Comment #7 from Richard Biener ---
So like the following which disables threading ending in a
if (..)
__builtin_unreachable ();
branch when we thread to the _reachable_ side of it. We keep threading
to the __builtin_unreachable () sid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113018
--- Comment #3 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:4e9b2c94e45f5991a472fb639fb2baa6aa42b76b
commit r14-6552-g4e9b2c94e45f5991a472fb639fb2baa6aa42b76b
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113018
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109536
--- Comment #5 from GCC Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:7d00a59229ee17af009a3c6c6208b0611740ed49
commit r14-6553-g7d00a59229ee17af009a3c6c6208b0611740ed49
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109536
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113024
Bug ID: 113024
Summary: Nested cast not optimized out in GIMPLE
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113019
Andrew Pinski changed:
What|Removed |Added
Component|rtl-optimization|target
Severity|normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113019
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78464
Andrew Pinski changed:
What|Removed |Added
CC||aros at gmx dot com
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111556
Jay changed:
What|Removed |Added
CC||gnu.org at hovland dot cx
--- Comment #4 from Jay
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112773
--- Comment #14 from GCC Commits ---
The master branch has been updated by Robin Dapp :
https://gcc.gnu.org/g:0a5170b5f596bb5fcedf25d93952b979d02d1f56
commit r14-6555-g0a5170b5f596bb5fcedf25d93952b979d02d1f56
Author: Robin Dapp
Date: Sun De
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112999
--- Comment #3 from GCC Commits ---
The master branch has been updated by Robin Dapp :
https://gcc.gnu.org/g:e5e1999aa664333f766f3e6cc6996f769d50ae7a
commit r14-6556-ge5e1999aa664333f766f3e6cc6996f769d50ae7a
Author: Robin Dapp
Date: Wed Dec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111556
--- Comment #5 from Jakub Jelinek ---
The not dereferencing NULL environ is PR111413 and has been fixed already.
That is something different from what is reported here, and as I said, there is
nothing that can be done about it except "don't do i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873
--- Comment #18 from Jerry DeLisle ---
I have the patch applied.
make pdf and make info work as expected. I fixed a minor typo in a comment for
intrinsic.cc. I have a few of the git magics to do. Shall I submit to the list
before commit?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113020
--- Comment #1 from Andrew Pinski ---
Side note, I wish "Compiler Explorer" was able to a simple make file instead of
cmake.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873
--- Comment #19 from Steve Kargl ---
On Thu, Dec 14, 2023 at 05:03:35PM +, jvdelisle at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873
>
> --- Comment #18 from Jerry DeLisle ---
> I have the patch applied.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113021
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873
--- Comment #20 from anlauf at gcc dot gnu.org ---
(In reply to Jerry DeLisle from comment #18)
> I have the patch applied.
>
> make pdf and make info work as expected. I fixed a minor typo in a comment
> for intrinsic.cc. I have a few of the g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113024
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
Keywords|ice-on-v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113024
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113024
--- Comment #2 from Andrew Pinski ---
Confirmed.
Note if the final convert was a truncation from the original one, match is able
to remove the inner cast since r14-2890-gcc2003cd87532f (PR 93044).
That is:
```
unsigned char
foo1 (signed short x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109543
--- Comment #5 from Richard Sandiford ---
I think the loop in compute_mode_layout needs to be smarter
for unions. At the moment it's sensitive to field order,
which doesn't make much conceptual sense.
E.g. for the admittedly contrived example:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109543
--- Comment #6 from richard.sandiford at arm dot com ---
Here's a proof of concept patch that fixes the testcase for
-mstrict-align. The VECTOR_MODE_P part would need to be behind
a new target hook, to avoid accidentally breaking someone's ABI.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113023
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873
--- Comment #21 from GCC Commits ---
The master branch has been updated by Jerry DeLisle :
https://gcc.gnu.org/g:95b70545331764c85079a1d0e1e19b605bda1456
commit r14-6558-g95b70545331764c85079a1d0e1e19b605bda1456
Author: Jerry DeLisle
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873
--- Comment #22 from Jerry DeLisle ---
(In reply to anlauf from comment #20)
> (In reply to Jerry DeLisle from comment #18)
> > I have the patch applied.
> >
> > make pdf and make info work as expected. I fixed a minor typo in a comment
> > fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873
--- Comment #23 from Jerry DeLisle ---
I am going to suggest the following. The wording was confusing around the
functionality of the option vs the intrinsics. Hope this is OK?
@opindex @code{fdec-math}
@item -fdec-math
Obsolete flag. The purp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113023
--- Comment #2 from Andreas Schwab ---
The insn is _not_ redundant, there is a relocation on it. The linker
relaxation will eventually remove it when it becomes unnessessary.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110279
--- Comment #5 from GCC Commits ---
The master branch has been updated by Di Zhao :
https://gcc.gnu.org/g:8afdbcdd7abe1e3c7a81e07f34c256e7f2dbc652
commit r14-6559-g8afdbcdd7abe1e3c7a81e07f34c256e7f2dbc652
Author: Di Zhao
Date: Fri Dec 15 03
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873
--- Comment #24 from anlauf at gcc dot gnu.org ---
(In reply to Jerry DeLisle from comment #23)
> I am going to suggest the following. The wording was confusing around the
> functionality of the option vs the intrinsics. Hope this is OK?
>
> @op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112773
Patrick O'Neill changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873
--- Comment #25 from Steve Kargl ---
On Thu, Dec 14, 2023 at 07:48:08PM +, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873
>
> --- Comment #24 from anlauf at gcc dot gnu.org ---
> (In reply to Jerry De
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112773
--- Comment #16 from Robin Dapp ---
I'd hope it was not fixed by this but just latent because we chose a VLS-mode
vectorization instead. Hopefully we're better off with the fix than without :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873
Jerry DeLisle changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot
gnu.org
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113023
--- Comment #3 from Iain Finlay ---
It does not get removed. It ends up in the final image. It is also redundant
because load and store can also add a 12 bit signed offset.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113023
--- Comment #4 from Iain Finlay ---
GCC does know that it needs LANCHOR0 and LANCHOR0+4 (meaning a difference of
4). The 12-bit lower portion can be provided in the load and store commands. It
seems just an implementation choice in pcnt0 that it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873
--- Comment #27 from Jerry DeLisle ---
Created attachment 56882
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56882&action=edit
Description changes
This is what I arrived at going through. OK?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873
--- Comment #28 from Steve Kargl ---
On Thu, Dec 14, 2023 at 08:35:32PM +, jvdelisle at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873
>
> --- Comment #27 from Jerry DeLisle ---
> Created attachment 56882
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113023
--- Comment #5 from Andreas Schwab ---
If the linker relaxation does not remove a relaxable move then it is a bug in
the linker.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112869
--- Comment #6 from GCC Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:8cccdc2176740f3e034ee6caa49552cf2f142744
commit r14-6561-g8cccdc2176740f3e034ee6caa49552cf2f142744
Author: Marek Polacek
Date: Tu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112869
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112773
--- Comment #17 from Patrick O'Neill ---
(In reply to Robin Dapp from comment #16)
> I'd hope it was not fixed by this but just latent because we chose a
> VLS-mode vectorization instead. Hopefully we're better off with the fix
> than without :
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
--- Comment #37 from Ian Lance Taylor ---
Search for this comment in the top-level configure.ac file.
# Disable libgo for some systems where it is known to not work.
# For testing, you can easily override this with --enable-libgo.
That said if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113025
Bug ID: 113025
Summary: Pointer is sometimes assumed to be 16-byte aligned
even when there is no such guarantee
Product: gcc
Version: 8.4.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111260
--- Comment #12 from GCC Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:5fa27d9f8c4bec65887654e374146926d76690b0
commit r14-6562-g5fa27d9f8c4bec65887654e374146926d76690b0
Author: Andrew Pinski
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111260
Andrew Pinski changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
1 - 100 of 145 matches
Mail list logo
