https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115063
Bug ID: 115063
Summary: compilation error: std::basic_stracktrace::max_size()
Product: gcc
Version: 14.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115062
Bug ID: 115062
Summary: [modules] internal compiler error: in
simplify_aggr_init_exp
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115061
Ken Matsui changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |kmatsui at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113363
--- Comment #10 from Paul Thomas ---
Leave open partly because it is awaiting backporting to 14-branch but also
because there are remaining, pre-existing issues involving parentheses around
selector/source expressions:
https://gcc.gnu.org/piperm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115061
Bug ID: 115061
Summary: Compiling gcc failed when using clang 16.0.6
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113363
--- Comment #9 from GCC Commits ---
The master branch has been updated by Paul Thomas :
https://gcc.gnu.org/g:2d0eeb529d400e61197a09c56011be976dd81ef0
commit r15-394-g2d0eeb529d400e61197a09c56011be976dd81ef0
Author: Paul Thomas
Date: Mon Ma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115060
Bug ID: 115060
Summary: Probable an issue around usage of
vect_look_through_possible_promotion in
tree-vect-patterns.cc
Product: gcc
Version: 15.0
St
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114196
--- Comment #7 from Robin Dapp ---
I can barely build a compiler on gcc185 due to disk space. I'm going to set up
a cross toolchain (that I need for other purposes as well) in order to test.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101017
Hongtao Liu changed:
What|Removed |Added
CC||haochen.jiang at intel dot com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115038
--- Comment #6 from Christoph Reiter ---
I can confirm that the patch from comment 4 fixes all the above cases, and also
emacs builds again.
Thanks again
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115010
--- Comment #11 from Thorsten Otto ---
Confirmed, reverting that commit will prevent the error. Now the question is
how to find the real cause of the problem, since reverting that commit is most
likely not the solution. OTOH, it would be nice to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115059
Bug ID: 115059
Summary: Constraints/Mandates on the comparison operators of
std::optional and std::variant are overly strict
Product: gcc
Version: 15.0
Status: UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115056
--- Comment #10 from Dale Weiler ---
New test case without UB still exhibits the behavior
#include
#include
typedef union {
unsigned char as_bytes[64];
unsigned long long as_chunks[64 / sizeof(unsigned long long)];
} Block;
in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115058
Bug ID: 115058
Summary: on target arm -mcpu=cortex-a78ae does not allow use
pauth and dot product
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115056
Sam James changed:
What|Removed |Added
Last reconfirmed||2024-05-13
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115056
--- Comment #9 from Sam James ---
The issue is we need a program which no UB which has the bad symptoms.
I can fix it up but that doesn't mean it has the symptoms you originally saw
which made you report a bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115056
--- Comment #8 from Dale Weiler ---
Yeah, you can add another `while (j < 64) block.as_bytes[j] = 0;` to the end if
you want. I really should've done a better job reducing it so as not to create
uninitialized memory. You can also just memset the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115056
--- Comment #7 from Sam James ---
Isn't there still an uninitialised read?
```
$ valgrind /tmp/foo
[...]
==814922==
1886221359
1
0
0
0
0
0
==814922== Use of uninitialised value of size 8
==814922==at 0x48F7D3A: _itoa_word (_itoa.c:183)
==81
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115057
Bug ID: 115057
Summary: TextIO.ReadRestLine raise an exception for
insufficient buffer
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115056
--- Comment #6 from Sam James ---
I was just about to comment that, thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115056
--- Comment #5 from Dale Weiler ---
I should note that there is a byte in-between these two pieces of code I
removed
for (; j < i; j++) block.as_bytes[j] = argv[0][j];
block.as_bytes[j] = 0x01; // I removed this line
while (++j &
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115056
--- Comment #4 from Sam James ---
With Clang, I get:
```
ยข clang /tmp/foo.c -o /tmp/foo
$ /tmp/foo
1886221359
0
0
0
0
0
0
-733536256
```
and
```
$ clang /tmp/foo.c -o /tmp/foo -fsanitize=address,undefined
$ /tmp/foo
1886221359
0
0
0
0
0
0
0
```
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115056
--- Comment #3 from Dale Weiler ---
> You don't have to share, but I find it useful to know where stuff was reduced
> from. Was it a public library? If so, what? It is OK to not answer.
It's the inner part of the Tiger Hash cryptographic hash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115056
--- Comment #2 from Sam James ---
(In reply to Dale Weiler from comment #0)
> I've isolated what appears to be an unsound __builtin_memset optimization
> applied by gcc 14.1.1 on a hash function in a cryptographic library where it
> writes one b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115056
Sam James changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org
Keyword
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115056
Bug ID: 115056
Summary: Miscompilation triggering -Wstringop-overflow and
-Warray-bounds warning when -O2 or higher
Product: gcc
Version: 14.1.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115054
--- Comment #5 from Trevor Gross ---
Looks like bugz cut off part of the sysv quote, here for reference:
> Arguments of types __float128, _Decimal128 and __m128 are split
> into two halves. The least significant ones belong to class SSE, the mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115054
--- Comment #4 from Trevor Gross ---
To my knowledge, MSVC does not support or specify an ABI for 16- or 128-bit
IEEE floating point types, so I do suppose that either GCC or Clang could be
considered correct here.
SysV doesn't say anything abo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115055
Bug ID: 115055
Summary: reassociation should use match-and-simplify
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115054
--- Comment #3 from Andrew Pinski ---
https://learn.microsoft.com/en-us/cpp/build/x64-calling-convention?view=msvc-170#parameter-passing
So it uses floating point as the type. But then it is vague on those kind of
type. Gcc treats _Float16 simi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115054
--- Comment #2 from Andrew Pinski ---
Does Microsoft's abi documents this case?
If not then gcc is as correct here as clang is.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115054
--- Comment #1 from Andrew Pinski ---
What does msvc do?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115054
Bug ID: 115054
Summary: __float128 and _Float16 use incorrect ABI on x86-64
MinGW
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115053
Bug ID: 115053
Summary: gcc crashed without back trace
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Ass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115052
Bug ID: 115052
Summary: rejected lambda while capturing a constexpr array
Product: gcc
Version: 14.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115051
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113506
--- Comment #1 from Andrew Pinski ---
*** Bug 115051 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115051
Bug ID: 115051
Summary: ICE: RTL check: expected elt 2 type 'B', have '0' (rtx
barrier) in BLOCK_FOR_INSN, at rtl.h:1495 with -O
-finstrument-functions-once -finline-stringops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80182
Peter Damianov changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115038
--- Comment #5 from Christoph Reiter ---
Thanks! I can confirm that "-fno-fold-mem-offsets" works around the issue. I'll
test the proposed patch tomorrow.
In the meantime we've reduced another instance of this when building emacs, but
this time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115038
--- Comment #4 from Eric Botcazou ---
Tentative fixlet:
diff --git a/gcc/fold-mem-offsets.cc b/gcc/fold-mem-offsets.cc
index 2e15b05529e..84b9623058b 100644
--- a/gcc/fold-mem-offsets.cc
+++ b/gcc/fold-mem-offsets.cc
@@ -491,7 +491,7 @@ fold_of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115038
--- Comment #3 from Eric Botcazou ---
It's the -ffold-mem-offsets pass messing up with the prologue and the
frame-related instructions (so -fno-fold-mem-offsets is a workaround).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115050
Sam James changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org
--- Comment #2 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115038
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
Target M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115010
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112959
--- Comment #12 from Thierry Thomas ---
(In reply to Gerald Pfeifer from comment #11)
> Thierry, what is your take, in particular related to building GNAT as it
> comes as part of upstream GCC?
AFAIK, no problem with these ports for the suppor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112959
Gerald Pfeifer changed:
What|Removed |Added
CC||thierry at FreeBSD dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69374
--- Comment #14 from GCC Commits ---
The releases/gcc-14 branch has been updated by Gerald Pfeifer
:
https://gcc.gnu.org/g:80ccc90be4aee9f87f468e04c5b97d6b9583ae7e
commit r14-10198-g80ccc90be4aee9f87f468e04c5b97d6b9583ae7e
Author: Gerald Pfeife
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112959
--- Comment #10 from GCC Commits ---
The releases/gcc-14 branch has been updated by Gerald Pfeifer
:
https://gcc.gnu.org/g:80ccc90be4aee9f87f468e04c5b97d6b9583ae7e
commit r14-10198-g80ccc90be4aee9f87f468e04c5b97d6b9583ae7e
Author: Gerald Pfeif
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69374
--- Comment #13 from GCC Commits ---
The releases/gcc-14 branch has been updated by Gerald Pfeifer
:
https://gcc.gnu.org/g:609f9699cd376dbb903d9a6761bdb1165831f796
commit r14-10197-g609f9699cd376dbb903d9a6761bdb1165831f796
Author: Gerald Pfeife
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112959
--- Comment #9 from GCC Commits ---
The releases/gcc-14 branch has been updated by Gerald Pfeifer
:
https://gcc.gnu.org/g:609f9699cd376dbb903d9a6761bdb1165831f796
commit r14-10197-g609f9699cd376dbb903d9a6761bdb1165831f796
Author: Gerald Pfeife
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69374
--- Comment #12 from GCC Commits ---
The releases/gcc-14 branch has been updated by Gerald Pfeifer
:
https://gcc.gnu.org/g:7939f8823e20c8faed6ce5ac4614c558344a265f
commit r14-10196-g7939f8823e20c8faed6ce5ac4614c558344a265f
Author: Gerald Pfeife
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112959
--- Comment #8 from GCC Commits ---
The releases/gcc-14 branch has been updated by Gerald Pfeifer
:
https://gcc.gnu.org/g:cf43da54f876c4b965feaa5f499483b5f16ed269
commit r14-10195-gcf43da54f876c4b965feaa5f499483b5f16ed269
Author: Gerald Pfeife
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69374
--- Comment #11 from GCC Commits ---
The releases/gcc-14 branch has been updated by Gerald Pfeifer
:
https://gcc.gnu.org/g:cf43da54f876c4b965feaa5f499483b5f16ed269
commit r14-10195-gcf43da54f876c4b965feaa5f499483b5f16ed269
Author: Gerald Pfeife
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112728
--- Comment #8 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #7)
> I happened to do an AIX build on cfarm119 - and looking at this, not sure
> why AIX is failing; although the LTO is handled in a different way in AIX,
> there are ac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112728
--- Comment #7 from Iain Sandoe ---
I happened to do an AIX build on cfarm119 - and looking at this, not sure why
AIX is failing; although the LTO is handled in a different way in AIX, there
are actually no instances of "ascii" in the assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115050
--- Comment #1 from Andrew Pinski ---
Note there is an alignment missing on the data field.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115050
Bug ID: 115050
Summary: Segfault when compiled with -O0
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115049
Bug ID: 115049
Summary: Silent severe miscompilation around inline functions
Product: gcc
Version: 14.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114937
--- Comment #5 from Mikael Pettersson ---
I ran a git bisect between 11.4.0 and 12.3.0, which identified the following as
fixing this test case:
2e96b5f14e4025691b57d2301d71aa6092ed44bc is the first new commit
commit 2e96b5f14e4025691b57d2301d7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179
--- Comment #41 from Brjd ---
(In reply to Sam James from comment #40)
> That came up at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600#c29.
IMHO keeping the build at RAM<=1GB would be a good benchmark. Keeping these
million-line files migh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106060
Roger Sayle changed:
What|Removed |Added
Resolution|--- |FIXED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115048
Bug ID: 115048
Summary: warning "operator delete called on pointer ''
with nonzero offset"
Product: gcc
Version: 14.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115047
Bug ID: 115047
Summary: Inconsistent MC/DC reported by GCC and LLVM
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov
64 matches
Mail list logo
