https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120846
--- Comment #3 from Andrew Pinski ---
(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
> for the abi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120900
H.J. Lu changed:
What|Removed |Added
CC||jsm28 at gcc dot gnu.org
--- Comment #10 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120356
--- Comment #5 from Alexey Merzlyakov ---
Analysis update: vector calculation chain in the loop from the above comment
remains from the initial expand pass, while other duplicated code was moved to
the first function BB by loop2_invariant.
Afte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120845
Andrew Pinski changed:
What|Removed |Added
See Also||https://github.com/llvm/llv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120861
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120862
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2025-07-01
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120862
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |15.2
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120905
--- Comment #10 from TCH ---
If i cannot fix this problem myself, then it would be asinine for me to step up
as a maintainer. I came here with the question, not the answer; i asked for
support, not offered it. (I have nothing to offer anyways.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105611
--- Comment #2 from 康桓瑋 ---
(In reply to Patrick Palka from comment #1)
> std::shift_left/right require a Cpp17ForwardIterator, but here I is not
> default constructible which seems like a constraint violation making the
> testcase invalid?
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120905
--- Comment #9 from Andrew Pinski ---
Anyways free software is not free support for all things but rather it is there
for free to modify and free to distribute. GCC provides support for the last
few releases as good will for others. But there is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61338
Andrew Pinski changed:
What|Removed |Added
CC||liuhongt at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120905
--- Comment #8 from TCH ---
What is the right place then, if the only occurrence of this error message is
here? (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30819)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120905
--- Comment #7 from Andrew Pinski ---
(In reply to TCH from comment #5)
> GCC9 would most probably suit my needs. I understand that this will not be
> fixed, but if i try to fix it myself, then why cannot i ask help from
> experts if they are wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120907
--- Comment #3 from Andrew Pinski ---
Note there is an off by one error in the loop.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120905
--- Comment #6 from TCH ---
(And i also do not understand why was Solaris 10 support removed, just because
it is "old", when it is still officially supported:
https://en.wikipedia.org/wiki/Oracle_Solaris#Version_history)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61338
--- Comment #11 from Andrew Pinski ---
*** Bug 120907 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120907
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120906
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120905
--- Comment #4 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #3)
> Solaris 10 support was removed in gcc 9 also.
> https://gcc.gnu.org/gcc-9/changes.html
>
>
> Solaris 10 is years old and no longer supported so there is nothin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120907
--- Comment #1 from Andrew Pinski ---
This is 100% a dup.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120905
--- Comment #5 from TCH ---
GCC9 would most probably suit my needs. I understand that this will not be
fixed, but if i try to fix it myself, then why cannot i ask help from experts
if they are willing to help?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120905
--- Comment #3 from Andrew Pinski ---
Solaris 10 support was removed in gcc 9 also.
https://gcc.gnu.org/gcc-9/changes.html
Solaris 10 is years old and no longer supported so there is nothing to be done
here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120905
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |WONTFIX
Build|sparc-sun-so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120905
--- Comment #2 from TCH ---
I assume this linker error would appear if i would try to compile GCC 13 with
GCC 12, if the fault is not in GCC, but in Binutils, or the environment, or the
config.
And i know the software is old. This is why i try
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120907
Bug ID: 120907
Summary: vectorizer creates redundunt vec_perm_expr for
reversed access of array
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120906
Bug ID: 120906
Summary: vectorizer create redudant permutation for reversed
access of array
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120905
Bug ID: 120905
Summary: Unable to compile GCC 6.5.0 with GCC 5.5.0 on Solaris
10 SPARC (linker error?)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120895
--- Comment #9 from Hongtao Liu ---
(In reply to Sam James from comment #8)
> It passes for me with -march=znver2. Hongtao, were you maybe testing with a
> compiler with default `--with-arch=`?
I'm using option -march=x86-64-v4(assume __m512 ne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120881
--- Comment #2 from cuilili ---
I think it is an old bug, since shrink wrap, NOTE_INSN_PROLOGUE_END does not
represent the entry bb.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120895
--- Comment #8 from Sam James ---
It passes for me with -march=znver2. Hongtao, were you maybe testing with a
compiler with default `--with-arch=`?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120895
--- Comment #7 from Sam James ---
(In reply to Hongtao Liu from comment #6)
> I can't reproduce it with gcc13.3.0 on ubuntu24.04
>
> Neither with gcc14.1.0, gcc15.1.0, trunk
>
> td::alignment_of_v<__m512> is: 64
> alignof(__m512) is: 64
> __al
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120895
Hongtao Liu changed:
What|Removed |Added
CC||liuhongt at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120904
--- Comment #4 from Andrew Pinski ---
> Therefore, the addition cannot have overflowed and data_ <= data_ + size_ is
> always true in all defined cases
This is not true.
> Pointer arithmetic is required to stay in bounds, and is not defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120904
--- Comment #3 from Andrew Pinski ---
So I think clang might be producing wrong code. There should be still a check
the size_ does not have the sign bit set as i dont see how clang would know
that.
I think the code itself needs that check too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120904
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120904
--- Comment #1 from Andrew Pinski ---
I am not 100% this has valid assumptions here at all.
Final .optimize:
_4 = MEM[(const int * *)&s];
_5 = MEM[(long unsigned int *)&s + 8B];
_12 = _5 * 4;
_13 = _4 + _12;
GCC does not know that _5*4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120903
--- Comment #4 from Andrew Pinski ---
For uintptr_t you need prevailing tracking of pointers which is still under
discussion in C ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120903
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120895
--- Comment #5 from David C. Partridge
---
Confirmed that macOS/x64 is also OK, so the problem is just Linux/x64 AFAICT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120903
--- Comment #3 from Andrew Pinski ---
With `char*` GCC has:
_7 = a_2(D) < &MEM [(void *)&r + 4B];
_4 = a_2(D) > &r;
_9 = _4 & _7;
But we only optimize ==/!= for aliasing IIRC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120631
--- Comment #9 from GCC Commits ---
The master branch has been updated by Alexandre Oliva :
https://gcc.gnu.org/g:24a041ea863721f3181e4433195e7697bf52c413
commit r16-1838-g24a041ea863721f3181e4433195e7697bf52c413
Author: Alexandre Oliva
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120903
--- Comment #2 from Andrew Pinski ---
I think this is by designed.
__od.0_5 = (long unsigned int) &r;
__os.1_6 = (long unsigned int) a_2(D);
if (__od.0_5 < __os.1_6)
Can't be optimized away.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120904
Bug ID: 120904
Summary: Redundant pointer comparisons after arithmetic not
deleted
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Keywords: missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120900
--- Comment #9 from H.J. Lu ---
C++ does
/* If this is a typedef that names the class for linkage purposes
(7.1.3p8), apply any attributes directly to the type. */
if (TREE_CODE (decl) == TYPE_DECL
&& OVERLOAD_TYPE_P (TREE_TYPE (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120903
Sam James changed:
What|Removed |Added
Attachment #61771|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120903
Bug ID: 120903
Summary: Alias information not used to optimize out
hand-written buffer aliasing checks
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120895
--- Comment #4 from David C. Partridge
---
I was incorrect there's no problem on macOS/ARM
I'll check macOS/x64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120900
--- Comment #8 from H.J. Lu ---
C++ builds the canonical type for vector, not for record. C builds both.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120902
Bug ID: 120902
Summary: void debug (const tree_node *ptr) doesn't work
Product: gcc
Version: 15.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120865
Sam James changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|WORKSFORME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120865
Benjamin Schulz changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Status|UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120900
H.J. Lu changed:
What|Removed |Added
CC||ubizjak at gmail dot com
Blocks|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120900
Andrew Pinski changed:
What|Removed |Added
Component|c |target
--- Comment #6 from Andrew Pinsk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120900
Andrew Pinski changed:
What|Removed |Added
Component|c++ |c
--- Comment #5 from Andrew Pinski --
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120900
H.J. Lu changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120900
Andrew Pinski changed:
What|Removed |Added
Status|NEW |UNCONFIRMED
Ever confirmed|1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120900
H.J. Lu changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #2 from H.J. Lu ---
(In repl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120888
H.J. Lu changed:
What|Removed |Added
Attachment #61769|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118280
--- Comment #24 from Michael Eager ---
Please send patch to gcc-patc...@gcc.gnu.org. Be sure to include the PR # in
the subject line and in the commit message.
The patch applies to the trunk and builds without problem. Please verify that
th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120892
--- Comment #3 from Jeffrey A. Law ---
I think an argument could be made that split-paths should go away. It seemed
like a reasonable idea at one time, but profitability was always marginal at
best. I wouldn't lose any sleep if it went away.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120901
--- Comment #2 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #1)
> Note with -O2 -W -Wall we do get an uninitialized variable warning even:
>
> :8:18: warning: 'argc.0' is used uninitialized [-Wuninitialized]
> 8 |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120901
--- Comment #1 from Andrew Pinski ---
Note with -O2 -W -Wall we do get an uninitialized variable warning even:
:8:18: warning: 'argc.0' is used uninitialized [-Wuninitialized]
8 | struct c a;
| ^
:6:9: note:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120899
--- Comment #3 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #2)
> Note with -O2 -W -Wall we do get an uninitialized variable warning even:
>
> :8:18: warning: 'argc.0' is used uninitialized [-Wuninitialized]
> 8 |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120899
--- Comment #2 from Andrew Pinski ---
Note with -O2 -W -Wall we do get an uninitialized variable warning even:
:8:18: warning: 'argc.0' is used uninitialized [-Wuninitialized]
8 | struct c a;
| ^
:6:9: note: '
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120901
Bug ID: 120901
Summary: missing diagnostics about jump into scope after
defining of a VLA struct
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Keywords: accep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120899
--- Comment #1 from Andrew Pinski ---
It is doing something similar as:
```
int main(int argc, char *argv[]) {
goto lab;
typedef int t[argc];
t *a;
lab:;
}
```
as a is a pointer to a VLA defined type.
>From .origin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120900
Andrew Pinski changed:
What|Removed |Added
Status|NEW |WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120772
--- Comment #3 from Sam James ---
I'm a bit surprised to see that change in that commit. Commits should try to
solve one problem -- this doesn't look related to diagnostics refactoring?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120900
--- Comment #1 from Andrew Pinski ---
Are you sure it is just where the aligned attribute is located?
Because I get a warning for both the C and C++ if I use the following
definition:
typedef struct __attribute__((aligned(32))) c1 {
long dou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120791
--- Comment #2 from GCC Commits ---
The master branch has been updated by James K. Lowden :
https://gcc.gnu.org/g:612c4c104ac0c2726d2de27f350040ad5f8d5776
commit r16-1836-g612c4c104ac0c2726d2de27f350040ad5f8d5776
Author: James K. Lowden
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120900
H.J. Lu changed:
What|Removed |Added
Last reconfirmed||2025-06-30
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120790
--- Comment #3 from GCC Commits ---
The master branch has been updated by James K. Lowden :
https://gcc.gnu.org/g:612c4c104ac0c2726d2de27f350040ad5f8d5776
commit r16-1836-g612c4c104ac0c2726d2de27f350040ad5f8d5776
Author: James K. Lowden
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120794
--- Comment #2 from GCC Commits ---
The master branch has been updated by James K. Lowden :
https://gcc.gnu.org/g:612c4c104ac0c2726d2de27f350040ad5f8d5776
commit r16-1836-g612c4c104ac0c2726d2de27f350040ad5f8d5776
Author: James K. Lowden
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120779
--- Comment #2 from GCC Commits ---
The master branch has been updated by James K. Lowden :
https://gcc.gnu.org/g:612c4c104ac0c2726d2de27f350040ad5f8d5776
commit r16-1836-g612c4c104ac0c2726d2de27f350040ad5f8d5776
Author: James K. Lowden
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120772
--- Comment #2 from GCC Commits ---
The master branch has been updated by James K. Lowden :
https://gcc.gnu.org/g:612c4c104ac0c2726d2de27f350040ad5f8d5776
commit r16-1836-g612c4c104ac0c2726d2de27f350040ad5f8d5776
Author: James K. Lowden
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120900
Bug ID: 120900
Summary: C++ passes user aligned struct differently from C
Product: gcc
Version: 15.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105611
--- Comment #1 from Patrick Palka ---
std::shift_left/right require a Cpp17ForwardIterator, but here I is not default
constructible which seems like a constraint violation making the testcase
invalid?
Using ranges::next on a legacy iterator is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120899
Bug ID: 120899
Summary: Duplicate diagnostics about jump into scope of
pointer-to-VLA variable
Product: gcc
Version: 15.1.0
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120888
--- Comment #3 from H.J. Lu ---
Created attachment 61769
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61769&action=edit
A patch
Please try this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120898
Bug ID: 120898
Summary: ICE at -O2 calling function with old-style definition
taking a VLA parameter
Product: gcc
Version: 15.1.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120242
Jeffrey A. Law changed:
What|Removed |Added
Summary|[15/16 regression] RISC-V: |[15 regression] RISC-V:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120736
--- Comment #2 from GCC Commits ---
The master branch has been updated by Jeff Law :
https://gcc.gnu.org/g:41155992d572030f7918682b2642365ada1f4fbf
commit r16-1835-g41155992d572030f7918682b2642365ada1f4fbf
Author: Jeff Law
Date: Mon Jun 30
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120813
--- Comment #2 from GCC Commits ---
The master branch has been updated by Jeff Law :
https://gcc.gnu.org/g:41155992d572030f7918682b2642365ada1f4fbf
commit r16-1835-g41155992d572030f7918682b2642365ada1f4fbf
Author: Jeff Law
Date: Mon Jun 30
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120242
--- Comment #6 from GCC Commits ---
The master branch has been updated by Jeff Law :
https://gcc.gnu.org/g:41155992d572030f7918682b2642365ada1f4fbf
commit r16-1835-g41155992d572030f7918682b2642365ada1f4fbf
Author: Jeff Law
Date: Mon Jun 30
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120627
--- Comment #4 from GCC Commits ---
The master branch has been updated by Jeff Law :
https://gcc.gnu.org/g:41155992d572030f7918682b2642365ada1f4fbf
commit r16-1835-g41155992d572030f7918682b2642365ada1f4fbf
Author: Jeff Law
Date: Mon Jun 30
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114611
--- Comment #3 from Jerry DeLisle ---
I have not had much time to finish this one. I will try to get to it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120242
--- Comment #5 from Jeffrey A. Law ---
*** Bug 120627 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120627
Jeffrey A. Law changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113524
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120888
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Target|xtensa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120763
Bug 120763 depends on bug 120659, which changed state.
Bug 120659 Summary: ICE: in riscv_sched_variable_issue, at
config/riscv/riscv.cc:9879 with -O2 -mcpu=sifive-x280
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120659
What|Remo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120659
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119944
Jeffrey A. Law changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120714
Jeffrey A. Law changed:
What|Removed |Added
CC||ewlu at rivosinc dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120714
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120763
Bug 120763 depends on bug 120714, which changed state.
Bug 120714 Summary: RISC-V: incorrect frame pointer CFA address for stack-clash
protection loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120714
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120714
--- Comment #5 from GCC Commits ---
The master branch has been updated by Jeff Law :
https://gcc.gnu.org/g:45a17e3081120f51f8e8b1d7cda73c7d89453e85
commit r16-1834-g45a17e3081120f51f8e8b1d7cda73c7d89453e85
Author: Alexey Merzlyakov
Date: Mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120895
--- Comment #3 from David C. Partridge
---
(In reply to Andrew Pinski from comment #2)
> (In reply to David C. Partridge from comment #1)
> > This also applies to arm64 / Neon
>
> Do you have an example there because I think the problems are 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120865
--- Comment #7 from Benjamin Schulz ---
the correct output is now this one without -O
The internal compiler error is at all o levels, -O1, O2, O3..
Interestingly -ffast-math works and leads to a considerable speed-up.
Just using -fno-math-err
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120865
Benjamin Schulz changed:
What|Removed |Added
Attachment #61751|mein_omp.cpp|main_omp.cpp
description|
1 - 100 of 180 matches
Mail list logo
