https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93573
--- Comment #14 from Jakub Jelinek ---
(In reply to Andrew Pinski from comment #13)
> Hmm, is the testcase in comment #4 a regression though? It ICEs even in the
> same way in GCC 4.1.2 all the way to the trunk including GCC 7.3.0.
It is. gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113711
--- Comment #11 from GCC Commits ---
The master branch has been updated by hongtao Liu :
https://gcc.gnu.org/g:5a9a9bd415ed1d211e00990226b90199407b3448
commit r14-9078-g5a9a9bd415ed1d211e00990226b90199407b3448
Author: liuhongt
Date: Mon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93573
--- Comment #13 from Andrew Pinski ---
(In reply to Jakub Jelinek from comment #6)
> Fixed the error-recovery bug on the trunk, but the ice on the #c4 testcase
> is still there (and the question is if it is valid or not). If it is valid,
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988
--- Comment #15 from Richard Biener ---
(In reply to Jakub Jelinek from comment #14)
> --- gcc/gimple-fold.cc.jj 2024-02-06 12:59:58.343050621 +0100
> +++ gcc/gimple-fold.cc2024-02-19 19:48:11.162126759 +0100
> @@ -995,9 +995,27 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90659
Andrew Pinski changed:
What|Removed |Added
Keywords||needs-bisection
--- Comment #13 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84757
--- Comment #13 from Andrew Pinski ---
I hear that the RISCV folks are going to implementing subreg handling in RA for
GCC 15, though I am not sure if that will fix this though but we will see.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43613
Chen Chen changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113060
--- Comment #8 from Jiang An ---
(In reply to Giuseppe D'Angelo from comment #7)
> Hi,
>
> > Note that this example adds a mediate function template
> > (test_array_element_initializable) to "reduce" the non-constexpr-ness of
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114005
Bug ID: 114005
Summary: Constructing a constexpr std::initializer_list ICEs
GCC when using C++ modules
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114004
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-02-20
.byte 0,0,0,0,0,0,0,0
.cfi_endproc
.LFE0:
.size rot,.-rot
.ident "GCC: (GNU) 14.0.1 20240219 (experimental) [remotes/origin/HEAD
r14-9074-gd70facd54a]"
.section.note.GNU-stack,"",@progbits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113993
--- Comment #6 from Jakub Jelinek ---
Following is much shorter:
--- gcc/tree-call-cdce.cc.jj2024-01-03 11:51:37.654646209 +0100
+++ gcc/tree-call-cdce.cc 2024-02-20 01:04:42.896987568 +0100
@@ -677,14 +677,14 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113994
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113993
--- Comment #5 from Jakub Jelinek ---
(In reply to Andrew Pinski from comment #4)
> (In reply to Jakub Jelinek from comment #3)
> > Created attachment 57467 [details]
> > gcc14-pr113993-wip.patch
> >
> > WIP patch.
>
> I know this might be a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113060
--- Comment #7 from Giuseppe D'Angelo ---
Hi,
> Note that this example adds a mediate function template
> (test_array_element_initializable) to "reduce" the non-constexpr-ness of
> std::declval.
That's very clever, thank you!
Is it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113994
Xi Ruoyao changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113993
--- Comment #4 from Andrew Pinski ---
(In reply to Jakub Jelinek from comment #3)
> Created attachment 57467 [details]
> gcc14-pr113993-wip.patch
>
> WIP patch.
I know this might be a stupid question but I notice this handles 96 and 128bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113993
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113993
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111289
David Malcolm changed:
What|Removed |Added
Summary|[13/14 Regression] |[13 Regression] Unwarranted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110520
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111289
--- Comment #2 from GCC Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:5651ad62b08096a155a7e394c7494f5ff1c04f4f
commit r14-9076-g5651ad62b08096a155a7e394c7494f5ff1c04f4f
Author: David Malcolm
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110520
--- Comment #3 from GCC Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:eb37ea529745c38dcf86c3cdbedb66df69ea9e35
commit r14-9075-geb37ea529745c38dcf86c3cdbedb66df69ea9e35
Author: David Malcolm
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113986
--- Comment #3 from Andrew Pinski ---
(In reply to Wilco from comment #2)
> Confirmed. I never heard about that config - at the time I tried it on an
> old system with GCC4.8 and that built and passed all tests. I can't see a
> reason to ever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113986
Wilco changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |wilco at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112103
Peter Bergner changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112103
Peter Bergner changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |bergner at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113993
Andrew Pinski changed:
What|Removed |Added
CC||pinskia at gcc dot gnu.org
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113995
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112103
--- Comment #5 from Peter Bergner ---
(In reply to Jakub Jelinek from comment #4)
> So, let's just adjust the testcase then?
We still want to remove the superfluous instruction, but that should be covered
in a separate bug. So yeah, I think
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113996
Andrew Pinski changed:
What|Removed |Added
Keywords||ice-on-valid-code
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105250
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |10.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114003
Bug ID: 114003
Summary: Missing MIN/MAX
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113983
--- Comment #5 from David Malcolm ---
(In reply to Andrew Pinski from comment #4)
> Fixed.
Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113983
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113983
--- Comment #3 from GCC Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:d70facd54a576faca1bfba96e92e1475e0da22a3
commit r14-9074-gd70facd54a576faca1bfba96e92e1475e0da22a3
Author: Andrew Pinski
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114002
Bug ID: 114002
Summary: [OpenACC][OpenACC 3.3] Add 'acc_attach'/'acc_detach'
routine
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: openacc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113957
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114001
Bug ID: 114001
Summary: is_contiguous considers unlimited polymorphic dummy
always as contiguous
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112397
--- Comment #11 from GCC Commits ---
The master branch has been updated by Iain D Sandoe :
https://gcc.gnu.org/g:1609fdff16f17ead37666f6d0e801800ee3d04d2
commit r14-9073-g1609fdff16f17ead37666f6d0e801800ee3d04d2
Author: Iain Sandoe
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113957
--- Comment #3 from GCC Commits ---
The master branch has been updated by Iain D Sandoe :
https://gcc.gnu.org/g:20e57660e64eab7c9ef0f2dd25f3088835f8f44f
commit r14-9072-g20e57660e64eab7c9ef0f2dd25f3088835f8f44f
Author: Iain Sandoe
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19779
--- Comment #13 from Jakub Jelinek ---
Nobody is blocking proper double double evaluation support. But somebody needs
to do the work, spend a few weeks on it and submit that. I'm just saying that
is highly unlikely. If somebody was really
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19779
--- Comment #12 from Jonathan Wakely ---
Then the maintainers or users of those targets should consider contributing a
fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19779
--- Comment #11 from Sergey Fedorov ---
(In reply to Jakub Jelinek from comment #7)
> Unlikely to be ever fixed, at least Linux has migrated to IEEE quad long
> double on powerpc64le.
Perhaps several *BSDs and AIX are using IBM format though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113999
David Malcolm changed:
What|Removed |Added
Last reconfirmed||2024-02-19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113998
--- Comment #2 from David Malcolm ---
Thanks for filing this bug.
I'm testing a fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988
--- Comment #14 from Jakub Jelinek ---
--- gcc/gimple-fold.cc.jj 2024-02-06 12:59:58.343050621 +0100
+++ gcc/gimple-fold.cc 2024-02-19 19:48:11.162126759 +0100
@@ -995,9 +995,27 @@ gimple_fold_builtin_memory_op (gimple_st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113997
--- Comment #5 from anlauf at gcc dot gnu.org ---
(In reply to Tobias Burnus from comment #3)
> However, an alternative is the following - which is (nearly) identical,
> except that GCC does some GFC-CFC and back conversations – independent
>
linux-gnu-as --disable-multilib
--disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-9062-20240219114159-geb17bdc211a-checking-yes-rtl-df-extra-riscv64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240219 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113997
--- Comment #4 from anlauf at gcc dot gnu.org ---
(In reply to Tobias Burnus from comment #3)
> > Anyway, renaming the binding label, like
> >subroutine acc_attach_c(x) bind(C, name="acc_attach_renamed")
> > makes the code compile.
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113976
--- Comment #10 from Patrick Palka ---
(In reply to Jakub Jelinek from comment #8)
> E.g.
> --- gcc/cp/decl.cc.jj 2024-02-15 09:51:34.460065992 +0100
> +++ gcc/cp/decl.cc2024-02-19 18:20:23.423410659 +0100
> @@ -15263,7 +15263,14 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113997
--- Comment #3 from Tobias Burnus ---
> Anyway, renaming the binding label, like
>subroutine acc_attach_c(x) bind(C, name="acc_attach_renamed")
> makes the code compile.
Well, the code *does* compile as it is only a warning.
* * *
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113998
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113997
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=108802
Martin Jambor changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113976
--- Comment #9 from Jakub Jelinek ---
Note, adjusted testcase:
struct S { int a, b; };
int foo () { return 42; }
template
const S a = { 42, foo () };
const S *b = <0>;
template
const S c = { 42, foo () };
template const S c <0>;
template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113997
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113976
--- Comment #8 from Jakub Jelinek ---
E.g.
--- gcc/cp/decl.cc.jj 2024-02-15 09:51:34.460065992 +0100
+++ gcc/cp/decl.cc 2024-02-19 18:20:23.423410659 +0100
@@ -15263,7 +15263,14 @@ grokdeclarator (const cp_declarator *dec
/* Record
4-9062-20240219114159-geb17bdc211a-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240219 (experimental) (GCC)
c-trunk//binary-trunk-r14-9062-20240219114159-geb17bdc211a-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240219 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113615
--- Comment #10 from GCC Commits ---
The master branch has been updated by Thomas Schwinge :
https://gcc.gnu.org/g:641b50bffc06123853a1421c0dd5a318c353fd85
commit r14-9068-g641b50bffc06123853a1421c0dd5a318c353fd85
Author: Thomas Schwinge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49001
Andrew Pinski changed:
What|Removed |Added
CC||xjkp2283572185 at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113989
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113976
Jakub Jelinek changed:
What|Removed |Added
Keywords|needs-bisection |
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66416
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112787
--- Comment #6 from GCC Commits ---
The releases/gcc-12 branch has been updated by Andre Simoes Dias Vieira
:
https://gcc.gnu.org/g:e84c06f801fbf8376fe43719675a409f588f68bd
commit r12-10165-ge84c06f801fbf8376fe43719675a409f588f68bd
Author:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113997
Bug ID: 113997
Summary: Bogus 'Warning: Interface mismatch in global
procedure' with C binding
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113966
Patrick Palka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113966
--- Comment #8 from GCC Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:3a6f3354eaaf38b5e6be41e4ebf521d299593a6e
commit r14-9066-g3a6f3354eaaf38b5e6be41e4ebf521d299593a6e
Author: Patrick Palka
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113992
Andrew Pinski changed:
What|Removed |Added
Resolution|FIXED |DUPLICATE
--- Comment #2 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79754
Andrew Pinski changed:
What|Removed |Added
CC||ujszhangc at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112787
--- Comment #5 from GCC Commits ---
The releases/gcc-13 branch has been updated by Andre Simoes Dias Vieira
:
https://gcc.gnu.org/g:35486d68fc5b67d1b85c56e3ba149ba71c576550
commit r13-8341-g35486d68fc5b67d1b85c56e3ba149ba71c576550
Author:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113996
Bug ID: 113996
Summary: ICE with LTO and full optimizations
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113976
--- Comment #6 from Jakub Jelinek ---
Testcase showing that it is just this case of implicit instantiation followed
by explicit that is problematic:
int foo () { return 42; }
template
const int a = foo ();
const int *b = <0>;
template
const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94489
--- Comment #5 from Patrick Palka ---
If we change std::plus to std::plus{} in order to make the testcase
valid, then we accept ever since the PR94490 fix.
The comment #4 testcase can be further reduced to:
template struct A;
template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988
--- Comment #13 from H.J. Lu ---
(In reply to Jakub Jelinek from comment #11)
> Though, bet that would mean we punt with -mavx -mno-avx2 on 32-byte copies,
> because there we support just V8SFmode and not V32QImode.
Punt AVX without AVX2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359
--- Comment #15 from Martin Jambor ---
Created attachment 57462
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57462=edit
Simple testcase (needs disabling early - and only early - SRA)
This is a simpler testcase which exhibits the
lgorithms: zlib zstd
gcc version 14.0.1 20240219 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91911
Patrick Palka changed:
What|Removed |Added
CC||omer.rosler at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99387
Patrick Palka changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113476
--- Comment #6 from Martin Jambor ---
I have proposed a patch on the mailing list that converts the array of lattices
to a vector:
https://inbox.sourceware.org/gcc-patches/ri6frxoxzpk@virgil.suse.cz/T/#u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113994
Bug ID: 113994
Summary: Probable C++ code generation bug with -O2 on s390x
platform
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113991
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |MOVED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113991
--- Comment #3 from Jakub Jelinek ---
Actually it seems like a glibc bug to me, though what vsftpd is totally weird.
Seems glibc clone on all arches always errors when the first or second argument
is NULL and that is exactly what
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988
--- Comment #12 from rguenther at suse dot de ---
On Mon, 19 Feb 2024, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988
>
> --- Comment #10 from Jakub Jelinek ---
> (In reply to Richard Biener from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988
Jakub Jelinek changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988
--- Comment #10 from Jakub Jelinek ---
(In reply to Richard Biener from comment #9)
> (In reply to Richard Biener from comment #8)
> > (In reply to Jakub Jelinek from comment #7)
> > > I think I can handle it like the VIEW_CONVERT_EXPR case,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988
--- Comment #9 from Richard Biener ---
(In reply to Richard Biener from comment #8)
> (In reply to Jakub Jelinek from comment #7)
> > I think I can handle it like the VIEW_CONVERT_EXPR case, bet with
> > _BitInt(511) it would actually be a VCE,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988
--- Comment #8 from Richard Biener ---
(In reply to Jakub Jelinek from comment #7)
> I think I can handle it like the VIEW_CONVERT_EXPR case, bet with
> _BitInt(511) it would actually be a VCE, but when it is same size
> BITINT_TYPE to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113991
--- Comment #2 from Jakub Jelinek ---
Maybe it is a bug in the app (or kernel or glibc) though.
Under the debugger, I see the value of %r7 is still _child at before the
call at line 189:
189 new_child =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988
--- Comment #7 from Jakub Jelinek ---
I think I can handle it like the VIEW_CONVERT_EXPR case, bet with _BitInt(511)
it would actually be a VCE, but when it is same size BITINT_TYPE to
INTEGER_TYPE we choose NOP_EXPR.
That said, I think it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988
--- Comment #6 from Richard Biener ---
-mstore-max=128 -mmove-max=128 avoids it and we inline the memcpy as
D.5177 = MEM <_BitInt(512)> [(char * {ref-all})];
MEM <_BitInt(512)> [(char * {ref-all})digits.0] = D.5177;
using a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988
--- Comment #5 from Richard Biener ---
Likely "caused" by upping MOVE_MAX and GIMPLE memcpy folding exposing this
type by means of build_nonstandard_integer_type.
We have from that
D.5177 = MEM [(char * {ref-all})];
MEM [(char *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113989
--- Comment #2 from 严 逍宇 ---
(In reply to Richard Biener from comment #1)
> does -mstackrealign make it work?
It doesn't work. GDB shows that the address in rcx is still unaligned.
(gdb) disassemble
Dump of assembler code for function _Z1fx:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988
--- Comment #4 from Richard Biener ---
I wonder if we should stop claiming those modes are "supported". Maybe instead
of making them integer modes they should be OPAQUE_MODE or vector (integer)
modes in the first place? There's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113992
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113989
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113337
jyong at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
CC|
219001746-ge42287eaed2-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240219 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113850
jyong at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
1 - 100 of 158 matches
Mail list logo
