https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26731
--- Comment #6 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #5)
> In GCC 9 and above we get:
> _2 = x_6(D) + 1;
> _7 = (unsigned int) n_1;
> _11 = _7 + 4294967295;
> _15 = (int) _11;
> _16 = n_1 > 0 ? _15 : 0;
> x_3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95230
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed|2021-11-22 00:00:00 |2023-6-9
--- Comment #3 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42117
--- Comment #4 from Andrew Pinski ---
So I think VRP is almost there on the trunk, it just needs to know if you have
a range of a and that a is defined by b|c, then b and c ranges can be just the
same as a.
That is:
_10 = x_5(D) | y_6(D);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32648
--- Comment #5 from Andrew Pinski ---
We even miss f3 into f4:
unsigned f3(unsigned a)
{
long b5 = (a & 0x20)>>5;
long b3 = (a & 0x08)>>3;
return b5 ^ b3;
}
unsigned f4(unsigned a)
{
unsigned b5 = (a ^ (a << 2));
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109886
--- Comment #13 from Andrew Macleod ---
Let me know if the buildbot likes that change :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110201
Bug ID: 110201
Summary: RISC-V: __builtin_riscv_sm4ks and
__builtin_riscv_sm4ed produce invalid assembly
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110195
--- Comment #7 from jack ---
(In reply to Jonathan Wakely from comment #6)
> The standard.
> In C++17 Single is an aggregate, and Single{} is aggregate-initialization,
> which initializes each member in turn, without calling a constructor.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110112
--- Comment #5 from David Malcolm ---
Should be fixed on trunk for gcc 14 by the above patch.
Keeping this open to track backporting it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110200
Bug ID: 110200
Summary: genmatch generating questionable code with convert and
!
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110044
--- Comment #14 from Sergey Fedorov ---
(In reply to Iain Sandoe from comment #13)
> fixed on open branches (should be back-portable to earlier if anyone cares).
Awesome, thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110198
--- Comment #2 from Benjamin Priour ---
Yes sorry for the regression. I confirmed it myself too on x86_64-linux-gnu.
I wrote a fix immediately yesterday, and I am currently regtesting it.
It is promising as I quickly ran the test only for the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110199
--- Comment #1 from Andrew Pinski ---
I suspect this was moving over to ranger and somehow this transformation was
lost (maybe due to a missing testcase?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88575
Andrew Pinski changed:
What|Removed |Added
Depends on||110199
--- Comment #6 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110199
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |12.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110199
Bug ID: 110199
Summary: [12/13/14 Regression] Missing VRP transformation with
MIN_EXPR and known relation
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88575
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed|2019-01-02 00:00:00 |2023-6-9
--- Comment #5 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110166
--- Comment #6 from Andrew Pinski ---
The fix was backported in GCC 13 though the match pattern which introduced this
was not in GCC 13 so keeping this recorded as fixed for GCC 14.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110165
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110165
--- Comment #8 from CVS Commits ---
The releases/gcc-13 branch has been updated by Andrew Pinski
:
https://gcc.gnu.org/g:682bbd364708fe371b8f34546d970051cdbbfd4c
commit r13-7434-g682bbd364708fe371b8f34546d970051cdbbfd4c
Author: Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110166
--- Comment #5 from CVS Commits ---
The releases/gcc-13 branch has been updated by Andrew Pinski
:
https://gcc.gnu.org/g:682bbd364708fe371b8f34546d970051cdbbfd4c
commit r13-7434-g682bbd364708fe371b8f34546d970051cdbbfd4c
Author: Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110198
Andrew Pinski changed:
What|Removed |Added
Build|powerpc64le-linux-gnu |
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110112
--- Comment #4 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:fe9771b59f576fb37e762013ef5d9b26162e3a88
commit r14-1664-gfe9771b59f576fb37e762013ef5d9b26162e3a88
Author: David Malcolm
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110196
--- Comment #9 from Jonathan Wakely ---
libbacktrace is supposed to have code to do this, see fileline_initialize in
libbacktrace/fileline.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110105
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
CC||rsandifo at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110196
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110195
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95906
--- Comment #6 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #5)
> Created attachment 55295 [details]
> Patch to handle the scalar version
I should we already handle:
```
int f3(int a, int b)
{
int cmp = -(a > b);
int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95906
--- Comment #5 from Andrew Pinski ---
Created attachment 55295
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55295=edit
Patch to handle the scalar version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86277
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC|anlauf at gmx dot de |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86277
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=110198
Bug ID: 110198
Summary: [14 regression] g++.dg/analyzer/pr100244.C fails after
r14-1632-g9589a46ddadc8b
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110075
--- Comment #1 from Pilar Latiesa ---
I forgot to paste:
$ ./gcc-13/bin/g++ -v
Usando especificaciones internas.
COLLECT_GCC=./gcc-13/bin/g++
COLLECT_LTO_WRAPPER=/home/pililatiesa/gcc-13/libexec/gcc/x86_64-pc-linux-gnu/13.1.0/lto-wrapper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110197
Marek Polacek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110197
Marek Polacek changed:
What|Removed |Added
Priority|P3 |P2
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110197
Bug ID: 110197
Summary: Empty constexpr object constructor erronously claims
out of range access
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86680
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |8.0
--- Comment #12 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110083
Roger Sayle changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109725
Dimitar Dimitrov changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96187
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |11.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100145
--- Comment #4 from Andrew Pinski ---
(In reply to Richard Biener from comment #2)
> So we get optimize_edge_for_size_p () returning OPTIMIZE_SIZE_BALANCED and
> thus optimize_edge_for_speed_p which is
>
> 340 bool
> 341
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100033
--- Comment #2 from Andrew Pinski ---
This seems to be optimized in GCC 13. at -O3 now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109456
--- Comment #8 from gccriscvuser at proton dot me ---
Thoughts?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53265
--- Comment #31 from Andrew Pinski ---
For the testcase in comment #0 we do warn:
: In function 'void foo()':
:7:47: warning: iteration 3 invokes undefined behavior
[-Waggressive-loop-optimizations]
7 | for (i=0, accum=a[0]; i < N; i++,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110196
--- Comment #7 from fabian_kessler at gmx dot de
---
To fix this some sort of
char ** __backtrace_symbols (void *const *array, int size)
must be used internally.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109886
--- Comment #12 from CVS Commits ---
The master branch has been updated by Andrew Macleod :
https://gcc.gnu.org/g:5612aa4d06594166c0ee848dc733bb9458c1bdbf
commit r14-1662-g5612aa4d06594166c0ee848dc733bb9458c1bdbf
Author: Andrew MacLeod
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104297
--- Comment #2 from Andrew Pinski ---
Note at -O2, t is no longer optimized to MIN_EXPR either due to VRP proping in
the value -2147483648 .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110195
--- Comment #5 from jack ---
(In reply to Andrew Pinski from comment #4)
> Note clang accepts Single{} where Single is an empty class also before C++20
> ...
I think Clang accepting empty class case does not neccessarily mean it is
correct.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110196
--- Comment #6 from fabian_kessler at gmx dot de
---
output is now
```
0# main at /mnt/c/Users/Febbe/workspace/test/test/main.cpp:7
1# __libc_start_call_main at ../sysdeps/nptl/libc_start_call_main.h:58
2# __libc_start_main_impl at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110196
--- Comment #5 from fabian_kessler at gmx dot de
---
Indeed, changing _S_init to the following improved it:
```
static backtrace_state *_S_init() {
static backtrace_state *__state = []() {
auto getpath = []() -> std::string {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110196
--- Comment #4 from fabian_kessler at gmx dot de
---
Indeed, changing _S_init to the following did the trick:
```
static backtrace_state *_S_init() {
static backtrace_state *__state = []() {
auto getpath = []() -> std::string {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110195
--- Comment #4 from Andrew Pinski ---
Note clang accepts Single{} where Single is an empty class also before C++20
...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110195
jack changed:
What|Removed |Added
Resolution|INVALID |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110196
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110196
--- Comment #3 from fabian_kessler at gmx dot de
---
It may be, because backtrace_create_state is called without a filename.
Also, backtrace_create_state is ment to be called just once per execution,
because it allocates unfreeable memory.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110196
--- Comment #2 from fabian_kessler at gmx dot de
---
(In reply to Andrew Pinski from comment #1)
> I am trying to understand the issue here?
> Is what you are asking is that the " at :0" should not be printed out? Or
> the issue is the source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110196
--- Comment #1 from Andrew Pinski ---
I am trying to understand the issue here?
Is what you are asking is that the " at :0" should not be printed out? Or the
issue is the source line cannot be found.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110102
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110185
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58487
--- Comment #8 from CVS Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:953bbeaeff050f4d0b670568a587aa1ce82ed711
commit r14-1660-g953bbeaeff050f4d0b670568a587aa1ce82ed711
Author: Jason Merrill
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110196
Bug ID: 110196
Summary: stacktrace_entry does not print origin binary filename
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110185
--- Comment #3 from CVS Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:953bbeaeff050f4d0b670568a587aa1ce82ed711
commit r14-1660-g953bbeaeff050f4d0b670568a587aa1ce82ed711
Author: Jason Merrill
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110102
--- Comment #7 from CVS Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:35d2c40e4ac9ba57ae82e4722e557a2028d0cf13
commit r14-1658-g35d2c40e4ac9ba57ae82e4722e557a2028d0cf13
Author: Jason Merrill
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21278
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed|2021-08-18 00:00:00 |2023-6-9
--- Comment #4 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110195
--- Comment #2 from jack ---
(In reply to Andrew Pinski from comment #1)
> Before C++20, Single{} didn't call the constructor so this behavior is
> expected.
Could you explain why it didn't call the constructor before c++20? C++ standard
rules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110195
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95906
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110195
Bug ID: 110195
Summary: defaulted constructor does not respect the private
accessor
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110193
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110192
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110163
--- Comment #2 from Jeffrey A. Law ---
It is a regression for rv64. So probably P4 would be most appropriate.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110192
--- Comment #2 from Andrew Pinski ---
(In reply to Richard Biener from comment #1)
> tail merging is supposed to handle this but ...
VOPs IIRC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110108
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12944
Bug 12944 depends on bug 97988, which changed state.
Bug 97988 Summary: [C++20] Forward-declared class type declared inside
requires-expression gives weird inconsistencies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97988
What
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101677
Patrick Palka changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97988
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110185
Jason Merrill changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110194
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96868
--- Comment #8 from CVS Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:0f8f1dee851c23bce19977b2531cf69b4da9f88f
commit r14-1657-g0f8f1dee851c23bce19977b2531cf69b4da9f88f
Author: Marek Polacek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39589
--- Comment #13 from CVS Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:0f8f1dee851c23bce19977b2531cf69b4da9f88f
commit r14-1657-g0f8f1dee851c23bce19977b2531cf69b4da9f88f
Author: Marek Polacek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97711
--- Comment #11 from Andrew Pinski ---
Note the committed patch only fixes f in comment #1. g (Pointer plus) will need
another change.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110155
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97711
Bug 97711 depends on bug 110155, which changed state.
Bug 110155 Summary: Missing if conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110155
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110165
Andrew Pinski changed:
What|Removed |Added
Known to work||14.0
Summary|[13/14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110166
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110194
--- Comment #5 from Umesh Kalappa ---
Ok thank you @Jakub and @Andrew for the quick reply ,
>>-Winline
Option triggers this diagnostic ,so it better not to use this option in the
debug build ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110155
--- Comment #5 from CVS Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:55fcaa9a8bd9c8ce97ca929fc902c88cf92786a0
commit r14-1656-g55fcaa9a8bd9c8ce97ca929fc902c88cf92786a0
Author: Andrew Pinski
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97711
--- Comment #10 from CVS Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:55fcaa9a8bd9c8ce97ca929fc902c88cf92786a0
commit r14-1656-g55fcaa9a8bd9c8ce97ca929fc902c88cf92786a0
Author: Andrew Pinski
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110166
--- Comment #3 from CVS Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:72e652f3425079259faa4edefe1dc571f72f91e0
commit r14-1653-g72e652f3425079259faa4edefe1dc571f72f91e0
Author: Andrew Pinski
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110165
--- Comment #6 from CVS Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:72e652f3425079259faa4edefe1dc571f72f91e0
commit r14-1653-g72e652f3425079259faa4edefe1dc571f72f91e0
Author: Andrew Pinski
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110194
--- Comment #4 from Jakub Jelinek ---
Note, I think -Og only does early inlining and not IPA inlining, so it will
inline far fewer functions than -O1, -O2, -Os etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110194
--- Comment #3 from Andrew Pinski ---
Also -G and -g are different options. I was thinking you saying gcc should not
warn when you specify the small data size on some targets (-G).
Oh -g is independent from optimization level too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110194
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109886
--- Comment #11 from Andrew Macleod ---
(In reply to Martin Jambor from comment #9)
> A buildbot run which checked out this revision unfortunately still reports
> this problem with UBSAN-bootstrapped compiler.
Actually, I do not think that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110194
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110188
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110194
Bug ID: 110194
Summary: GCC shouldn't warn for inline functions when -G
provided.
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109886
--- Comment #10 from Andrew Macleod ---
(In reply to Martin Jambor from comment #9)
> A buildbot run which checked out this revision unfortunately still reports
> this problem with UBSAN-bootstrapped compiler.
Oh, I see.. there's a second
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110193
Bug ID: 110193
Summary: d_signed_or_unsigned_type is invoked for vector types
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110188
--- Comment #4 from 18761437418 at 163 dot com ---
thank you very much.
according to the define, STACK_BOUNDARY is 8 bytes, ABI_STACK_BOUNDARY is 128,
just 16bytes, not 32bytes, but compiler allocate 32bytes to stack.
At 2023-06-09
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110191
Patrick Palka changed:
What|Removed |Added
Resolution|--- |DUPLICATE
CC|
1 - 100 of 171 matches
Mail list logo
