https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120881
--- Comment #15 from Uroš Bizjak ---
Comment on attachment 61783
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61783
A patch to place mcount at the function entry with shrink
>@@ -493,7 +493,7 @@ ix86_using_red_zone (void)
> static bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120881
H.J. Lu changed:
What|Removed |Added
Attachment #61782|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120895
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120871
--- Comment #10 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #9)
> Created attachment 61759 [details]
> Patch which is in testing but needs testcases
>
> This only fixes the tree level part; there is a middle-end part which I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120895
--- Comment #29 from David C. Partridge
---
And somehow macOS g++ gets it (almost) correct:
amonra@lethe m512 % g++ --version
Apple clang version 15.0.0 (clang-1500.1.0.2.5)
Target: x86_64-apple-darwin22.6.0
Thread model: posix
Instal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120895
David C. Partridge changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119430
--- Comment #7 from Alexandre Oliva ---
I've just tried and failed to duplicate this with r16-1756.
../configure -C armv7a-linux-gnueabihf --with-arch=armv7-a --with-float=hard
--with-fpu=vfpv3-d16 --enable-bootstrap --prefix=$HOME/arm-linux-gn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120881
--- Comment #11 from H.J. Lu ---
(In reply to cuilili from comment #10)
> (In reply to Sam James from comment #9)
> > Thanks both.
> >
> > H.J.'s is slightly less pessimising because it'll only affect functions
> > where we actually emit a call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120881
--- Comment #8 from H.J. Lu ---
(In reply to cuilili from comment #6)
> Created attachment 61781 [details]
> Disable separate shrink wrapping for profile
>
> How about changing it like this, like shrink wrap.
Looks reasonable. Need tests. Yo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120881
--- Comment #13 from H.J. Lu ---
This controls where to generate the mount call:
/* Return true, if profiling code should be emitted before
prologue. Otherwise it returns false.
Note: For x86 with "hotfix" it is sorried. */
static bool
i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120881
--- Comment #12 from H.J. Lu ---
The expected outputs are
[hjl@gnu-zen4-1 pr120881]$ gprof -C a.out
/export/home/hjl/bugs/gcc/pr120881/x.c:3: (f1:0x4004a0) 2000 executions
/export/home/hjl/bugs/gcc/pr120881/x.c:8: (f2:0x4004b0) 1000 executions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120881
--- Comment #10 from cuilili ---
(In reply to Sam James from comment #9)
> Thanks both.
>
> H.J.'s is slightly less pessimising because it'll only affect functions
> where we actually emit a call, but I don't think it really matters here, and
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120881
--- Comment #9 from Sam James ---
Thanks both.
H.J.'s is slightly less pessimising because it'll only affect functions where
we actually emit a call, but I don't think it really matters here, and matching
the general shrinkwrap logic seems bett
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120895
--- Comment #27 from David C. Partridge
---
You can't change the alignment for a type depending on compile options!
Different bits of our cod eneed to be compiled with different compiler options
so that the same code can run on both AVX (gener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120909
--- Comment #3 from Gaius Mulley ---
Thanks for spotting this!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120881
H.J. Lu changed:
What|Removed |Added
Attachment #61780|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120881
--- Comment #6 from cuilili ---
Created attachment 61781
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61781&action=edit
Disable separate shrink wrapping for profile
How about changing it like this, like shrink wrap.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120881
--- Comment #5 from Sam James ---
(In reply to H.J. Lu from comment #4)
> Created attachment 61780 [details]
> A patch
This will mean distributions that default to SSP (-fstack-protector-strong)
don't benefit from separate shrink wrapping at al
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120881
--- Comment #4 from H.J. Lu ---
Created attachment 61780
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61780&action=edit
A patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120923
Bug ID: 120923
Summary: check-function-bodies doesn't support "1: call mcount"
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120917
--- Comment #17 from Frank Heckenbach ---
Maybe I've found a work-around. I took the is_instance_of_v template from
https://indii.org/blog/is-type-instantiation-of-template/ and turned it into a
concept, so I can replace:
void f (S );
void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120881
--- Comment #3 from H.J. Lu ---
(In reply to cuilili from comment #2)
> I think it is an old bug, since shrink wrap, NOTE_INSN_PROLOGUE_END does not
> represent the entry bb.
There are
(note 99 98 100 2 NOTE_INSN_PROLOGUE_END)
(insn 100 99 3 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120846
--- Comment #6 from Jorn Wolfgang Rennecke ---
One alternative preventing from counts being mixed up between functions is to
make the pattern include the linenumber of the loop in which the pattern is
detected. Although that makes the tests a b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120847
--- Comment #9 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #8)
> Created attachment 61779 [details]
> Reduced testcase
>
> This is roughly the minimum I got.
Even the nint is not needed...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120847
--- Comment #8 from anlauf at gcc dot gnu.org ---
Created attachment 61779
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61779&action=edit
Reduced testcase
This is roughly the minimum I got.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119337
--- Comment #6 from James K. Lowden ---
Pending patch answers default output filename and default dialect:
$ gcobcx=0 /usr/local/gcc-cobol/bin/gcobc -g failures/jkl/tbug2.cbl
+ exec /usr/local/gcc-cobol/bin/gcobol -shared -dialect mf -dialec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120847
Jerry DeLisle changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #7 from Jerry DeLisle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120846
--- Comment #5 from Jorn Wolfgang Rennecke ---
I think the test should be split up into separate tests, one for each function,
so you can simply demand that the vect_recog_dot_prod_pattern is detected,
without specifying a number. That would al
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120846
--- Comment #4 from Jorn Wolfgang Rennecke ---
(In reply to Richard Biener from comment #1)
> I guess the testcase assumes that the qi->si case gets an intermediate
> qi->hi promotion and then dotprod_hisi being used. But it fails to check
> fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120847
--- Comment #6 from Jerry DeLisle ---
Created attachment 61778
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61778&action=edit
Test case I am testing with.
This requires no input files and uses the default settings. I will see if I
can
nfigured with: ../trunk/configure --prefix=/home/jerry/dev/usr
> --enable-languages=c,c++,fortran --enable-libgomp --disable-bootstrap
> Thread model: posix
> Supported LTO compression algorithms: zlib zstd
> gcc version 16.0.0 20250701 (experimental) (GCC)
>
> I am using Fe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120765
James K. Lowden changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120738
--- Comment #5 from Bruce McCulloch ---
As of commit dac12bc2426d5b639ad2d62d0f447dd037227c91 to binutils, the proposed
behavior is currently in the spec.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81771
--- Comment #3 from Jonathan Wakely ---
And __basic_file::xwritev too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120739
--- Comment #5 from Nick Alcock ---
A vanilla array output is *definitely* preferable to just emitting
CTF_K_UNKNOWN 'oops I don't know what this is'. These things are so like arrays
that surely we should say they are arrays, not "might be a str
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120917
--- Comment #16 from Frank Heckenbach ---
(In reply to Jason Merrill from comment #15)
> I suppose we could downgrade the error to a permerror (to make it compile
> with -fpermissive), since the above transformation still works apart from
> the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120917
--- Comment #15 from Jason Merrill ---
We always intended to diagnose Concepts TS features that didn't make it into
C++20, but there was a bug in GCC 12 that we didn't diagnose that particular
case because it hit the transformation from
void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120789
Patrick Palka changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120898
Andrew Pinski changed:
What|Removed |Added
Depends on||105180
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120910
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2025-07-01
Keywords|
hms: zlib zstd
gcc version 16.0.0 20250701 (experimental) (GCC)
I am using Fedora 42 here.
$ gfc -fcoarray=single random-weather.f90
f951: internal compiler error: in gfc_ref_this_image, at fortran/expr.cc:5948
0x21dce1f internal_error(char const*, ...)
../../trunk/gcc/diagnostic-glo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120789
--- Comment #3 from GCC Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:17e9ae215f991f2f94fe480aee2404c508388b7c
commit r16-1901-g17e9ae215f991f2f94fe480aee2404c508388b7c
Author: Patrick Palka
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120919
--- Comment #3 from GCC Commits ---
The releases/gcc-15 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:98bc42f456d04d71fe9b2b55fa7c7ad415367bbc
commit r15-9898-g98bc42f456d04d71fe9b2b55fa7c7ad415367bbc
Author: Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120587
Bug 120587 depends on bug 119966, which changed state.
Bug 119966 Summary: [16 regression] pru: Invalid register in RTL expression
starting with r16-160-ge6f89d78c1a752
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119966
What|Rem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120789
--- Comment #2 from GCC Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:6f69a68998f601cdb86c65113eb1feddfa9da31a
commit r16-1900-g6f69a68998f601cdb86c65113eb1feddfa9da31a
Author: Patrick Palka
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119966
Dimitar Dimitrov changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113934
Bug 113934 depends on bug 119966, which changed state.
Bug 119966 Summary: [16 regression] pru: Invalid register in RTL expression
starting with r16-160-ge6f89d78c1a752
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119966
What|Rem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120919
--- Comment #2 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:f5282f7402939fdec910ef3743d38edac864eec8
commit r16-1899-gf5282f7402939fdec910ef3743d38edac864eec8
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120912
Gaius Mulley changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120920
Bug ID: 120920
Summary: RISC-V: Possible optimization of bswap when zbb is
enabled
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120922
Bug ID: 120922
Summary: [16 Regression] RISC-V: ICE during GIMPLE pass: vect
in verify_range with -mrvv-max-lmul=m8
Product: gcc
Version: 16.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120921
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120921
Bug ID: 120921
Summary: gimple verifier (and gimple FE) accepts CST on LHS
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Keywords: accepts-invalid, ice-on-invalid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120705
Eric Botcazou changed:
What|Removed |Added
Target Milestone|16.0|15.2
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120912
--- Comment #2 from GCC Commits ---
The master branch has been updated by Gaius Mulley :
https://gcc.gnu.org/g:15670d4477ce219c017bd52417a6074b981fb197
commit r16-1898-g15670d4477ce219c017bd52417a6074b981fb197
Author: Gaius Mulley
Date: Tue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120705
--- Comment #3 from GCC Commits ---
The releases/gcc-15 branch has been updated by Eric Botcazou
:
https://gcc.gnu.org/g:79b82eb732765507367bb26fcd86c526599e3082
commit r15-9897-g79b82eb732765507367bb26fcd86c526599e3082
Author: Eric Botcazou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120913
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120705
--- Comment #2 from GCC Commits ---
The master branch has been updated by Eric Botcazou :
https://gcc.gnu.org/g:8deef83915f9e0fb14f278c68527c95085461c41
commit r16-1897-g8deef83915f9e0fb14f278c68527c95085461c41
Author: Eric Botcazou
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120914
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2025-07-01
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120916
Andrew Pinski changed:
What|Removed |Added
Depends on||56094
--- Comment #5 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120916
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2025-07-01
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120471
Jakub Jelinek changed:
What|Removed |Added
Summary|[12/13/14/15/16 regression] |[12/13/14 regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120471
--- Comment #16 from GCC Commits ---
The releases/gcc-15 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:7fdf47538a659f6af8dadbecbb63c8a226b63754
commit r15-9896-g7fdf47538a659f6af8dadbecbb63c8a226b63754
Author: Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120520
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |16.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120916
--- Comment #3 from Jan Hubicka ---
Well, PR32445 is about us not being able to vartrack value of I. I think that
may be fixed since then by adding corresponding debug binds.
However here we are missing info about statement being executed...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120648
Tomasz Kamiński changed:
What|Removed |Added
Target Milestone|--- |15.2
--- Comment #6 from Tomasz Kamiń
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120917
--- Comment #10 from Jonathan Wakely ---
(In reply to Frank Heckenbach from comment #9)
> but please consider distribution release cycles
We do, obviously. Most of the people maintaining the GCC packages in the major
distros are GCC developers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120648
--- Comment #5 from GCC Commits ---
The releases/gcc-15 branch has been updated by Tomasz Kaminski
:
https://gcc.gnu.org/g:fc36a902340a3a6dcfbe84c7d62c96268d413dc2
commit r15-9895-gfc36a902340a3a6dcfbe84c7d62c96268d413dc2
Author: Tomasz KamiÅs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117023
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |15.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120917
--- Comment #13 from Jonathan Wakely ---
(In reply to Frank Heckenbach from comment #12)
> OK, so you'll agree that there was no deprecation period for Debian stable
> users,
I thought Debian Testing uses GCC 14, where the feature is still pres
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120917
--- Comment #14 from Frank Heckenbach ---
(In reply to Jonathan Wakely from comment #13)
> (In reply to Frank Heckenbach from comment #12)
> > OK, so you'll agree that there was no deprecation period for Debian stable
> > users,
>
> I thought D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120917
--- Comment #12 from Frank Heckenbach ---
(In reply to Jonathan Wakely from comment #10)
> (In reply to Frank Heckenbach from comment #9)
> > but please consider distribution release cycles
>
> We do, obviously. Most of the people maintaining t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120917
--- Comment #11 from Jonathan Wakely ---
(In reply to Frank Heckenbach from comment #9)
> I generally use Debian stable which has GCC-12. Today, I was trying Debian
> trixie (which is still testing) for the first time. So for users like me,
> th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120917
--- Comment #8 from Frank Heckenbach ---
(In reply to Marek Polacek from comment #4)
> Also note that GCC 14 warned about this:
>
> $ xg++-14 -c 120917.C -fconcepts-ts
> cc1plus: note: ‘-fconcepts-ts’ is deprecated and will be removed in GCC 15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120917
--- Comment #9 from Frank Heckenbach ---
(In reply to Jonathan Wakely from comment #7)
> (In reply to Jonathan Wakely from comment #5)
> > So if GCC never told you it was related to -fconcepts-ts and you never
> > needed to use -fconcepts-ts to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120917
--- Comment #7 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #5)
> So if GCC never told you it was related to -fconcepts-ts and you never
> needed to use -fconcepts-ts to enable it, then you would never have seen the
> warni
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120917
--- Comment #6 from Frank Heckenbach ---
(In reply to Jonathan Wakely from comment #1)
> This extension uses syntax which is not valid in C++20 so it does not
> conflict with the base standard, and is always enabled. You should have been
> using
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120919
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
Eve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120917
--- Comment #5 from Jonathan Wakely ---
Yes the problem is that before GCC 14 the extension was silently accepted for
C++20 and later, even with -pedantic. For C++17 it would warn, but tell you to
use -std=c++20 or -fconcepts, so there was no cl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120917
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120917
Jonathan Wakely changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120917
--- Comment #2 from Jonathan Wakely ---
Hmm, except that -pedantic never warned about that for C++20 and C++23 modes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120919
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |14.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120919
Bug ID: 120919
Summary: [14/15/16 Regression]
gcc.target/powerpc/builtin_altivec_tr_stxvr_runnable.c
fails with -fstack-protector-strong
Product: gcc
Version: 16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120917
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120918
Bug ID: 120918
Summary: -Wreturn-type warning is confused by macro
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priorit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120917
Bug ID: 120917
Summary: warning: use of 'auto' in template argument only
available with '-fconcepts-ts'
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120880
MARIO RODRIGUEZ BEJAR changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99505
--- Comment #9 from MARIO RODRIGUEZ BEJAR ---
*** Bug 120880 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120916
Andrew Pinski changed:
What|Removed |Added
Depends on||32445
--- Comment #2 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120471
--- Comment #15 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:988e87b66882875b14a6cab11c17516863c74a63
commit r16-1893-g988e87b66882875b14a6cab11c17516863c74a63
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118567
--- Comment #5 from Alex Coplan ---
(In reply to Jakub Jelinek from comment #4)
> Any progress on this?
Patch waiting for approval here:
https://gcc.gnu.org/pipermail/gcc-patches/2025-February/676539.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118567
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120895
--- Comment #26 from David C. Partridge
---
The actual production code was compiled with 13.1 with options:
`-mavx;-mavx2;-mfma;-mssse3;-msse4.2`
but was crashing with a SEGV in the intrinsics code because the data was
incorrectly aligned. Wit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120916
--- Comment #1 from Jan Hubicka ---
Here is variant for gcov tool:
jh@shroud:/tmp> cat tt.c
int s = 1023;
int a[1024];
__attribute__ ((weak))
void test()
{
for (
int i = 0; /* Line 7, relative 3 */
i < s;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120916
Bug ID: 120916
Summary: debug info for IV increment is lost
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120895
--- Comment #25 from Jakub Jelinek ---
You're wrong. See https://godbolt.org/z/36eGehvTW for details.
All of gcc 13.4, 14.3 and 15.1 say alignof (__m512) is 16 (if AVX is disabled),
32 (if AVX enabled but AVX512F is not) and 64 if AVX512F is en
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120895
--- Comment #24 from David C. Partridge
---
I don't beleive that you diagnosis is correct - the issue is that on 13.1
running on Linux, alignof is set to 16 not 64.
On later versions (from what others have said) alignof returns 64 not 16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120895
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120895
--- Comment #22 from Jakub Jelinek ---
Further note, the differences between alignof and __alignof don't apply for
types with user aligned attribute (or alignas), but are present not just for
say 32-byte vectors when AVX is not enabled or 64-byt
1 - 100 of 154 matches
Mail list logo
