https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115221
Sam James changed:
What|Removed |Added
Summary|[15 regression] ICE when|[15 regression] ICE when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115223
--- Comment #1 from Sam James ---
Reduced:
```
using type = void;
template void checkSwap(T &t) noexcept(noexcept(t));
void qSwap(int value1) noexcept(noexcept(checkSwap(value1)));
type callDestructorIfNecessary(int &) noexcept {}
```
As usual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115222
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115225
Bug ID: 115225
Summary: [11/12/13/14 Regression] signed integer overflow check
missing with optimization
Product: gcc
Version: 11.4.0
Status: UNCONFIRMED
Sever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115225
--- Comment #1 from Andrew Pinski ---
The code is all dead. I can't remember for sure but I this is correct behavior
as the undefined code has no effects seen at all.
cking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20240525 (experimental) (GCC)
[539] %
[539] % gcctk -O3 small.c
small.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115223
Sam James changed:
What|Removed |Added
Summary|[15 regression] ICE when|[15 regression] ICE when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115227
Bug ID: 115227
Summary: [15 Regression] i686-linux fails frequently with cc1:
out of memory allocating x bytes after a total of ~4GB
Product: gcc
Version: 14.0
Status: U
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115208
Andreas Schwab changed:
What|Removed |Added
CC||slyfox at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115227
Andreas Schwab changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115228
Bug ID: 115228
Summary: Suspicious code in tree-vect-data-refs.cc
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84790
--- Comment #6 from YunQiang Su ---
The attached patch cannot work now.
It is not correct, and it happened work due to good luck that the same register
was allocated for these 2 instructions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115208
--- Comment #6 from Andrew Macleod ---
Created attachment 58287
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58287&action=edit
proposed patch
I'm testing this patch, does it resolve your problem?
I forgot to free the gori_nmap object w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88424
--- Comment #3 from Peter Damianov ---
Looking in a hex editor, what gcc is doing is changing the CRLF to LFLF, there
is no CR in the output.
/* If the file is using old-school Mac line endings (\r only),
terminate with another \r, not an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88424
--- Comment #4 from Peter Damianov ---
All of the non-commments are turned to LF line endings.
So it must be something specifically to do with comment processing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115229
Bug ID: 115229
Summary: inconsistent `error: possibly dangling reference to a
temporary`
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115161
--- Comment #23 from Alexander Monakov ---
(In reply to Sergei Trofimovich from comment #22)
> Here `pcmpeqd %xmm2,%xmm1` is a problematic instruction. Why does `gcc` use
> `%xmm2` (result of `cvttps2dq`) instead of, say `%xmm0` which contains
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109914
Paul Eggert changed:
What|Removed |Added
CC||eggert at cs dot ucla.edu
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88424
--- Comment #5 from Peter Damianov ---
I checked clang's behavior, and it does CRLF -> LF from non-comments, but it
leaves them intact in comments. I'm not really sure if this behavior is worth
emulating or not. I think it would be better to remo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115161
--- Comment #24 from Sergei Trofimovich ---
Thank you, Alexander! Tricky `REG_EQUAL` makes sense.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86100
--- Comment #6 from GCC Commits ---
The releases/gcc-14 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:b0b21d5bdfbc7d417b70010a11354b44968bb184
commit r14-10244-gb0b21d5bdfbc7d417b70010a11354b44968bb184
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115107
--- Comment #15 from Natalie Perlin ---
Quick update:
Software stack and model build with gnu/13.3.0 was clear from all previous
issues! So issue with the gnu/13.x.0 compiler could be considered as fixed,
thank you so much for the help here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86100
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27766
Bug 27766 depends on bug 86100, which changed state.
Bug 86100 Summary: Spurious error with -fcheck=bounds and allocatable class(*)
array components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86100
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93635
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115208
--- Comment #7 from Sergei Trofimovich ---
(In reply to Andrew Macleod from comment #6)
> Created attachment 58287 [details]
> proposed patch
>
> I'm testing this patch, does it resolve your problem?
>
> I forgot to free the gori_nmap object w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115229
--- Comment #1 from Andrew Pinski ---
>Could someone help me understand why this warning is even shown?
The lifetime of the temporary (of type B) returned from f is at the end of the
full expression. B::value_or's return in theory could have a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115229
--- Comment #2 from Barnabás Pőcze ---
So because `A::p` might point into the temporary of type `B` returned by `f()`,
the warning is shown? If so, why don't I get a warning if `x` is not a
reference? The same potential issue is possible in that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84790
--- Comment #7 from Matthias Schiffer ---
(In reply to YunQiang Su from comment #6)
> The attached patch cannot work now.
>
> It is not correct, and it happened work due to good luck that the same
> register was allocated for these 2 instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115208
--- Comment #8 from GCC Commits ---
The master branch has been updated by Andrew Macleod :
https://gcc.gnu.org/g:f9810728cf42ea7c3d84198aa582e53cfb2302d1
commit r15-833-gf9810728cf42ea7c3d84198aa582e53cfb2302d1
Author: Andrew MacLeod
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106757
--- Comment #7 from Jonathan Leffler ---
GCC 14.1.0 seems to produce "error: writing 8 bytes into a region of size 5
[-Werror=stringop-overflow=]" for two extra occurrences of almost the same code
in the original source file. It still generates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106757
--- Comment #8 from Jonathan Leffler ---
I beg your pardon — I thought I was using GCC 14.1.0 when I was actually using
GCC 13.2.0. My previous comment applies to GCC 13.2.0, with the spec.
$ /usr/gcc/v13.2.0/bin/gcc -v
Using built-in specs.
C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84790
--- Comment #8 from YunQiang Su ---
Ohh, In fact we should use $28 if TARGET_USE_GOT.
Can you help to test this patch?
```
diff --git a/gcc/config/mips/mips.cc b/gcc/config/mips/mips.cc
index b63d40a357b..fe8641d3916 100644
--- a/gcc/config/mip
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84790
--- Comment #9 from YunQiang Su ---
(In reply to Matthias Schiffer from comment #7)
> (In reply to YunQiang Su from comment #6)
> > The attached patch cannot work now.
> >
> > It is not correct, and it happened work due to good luck that the sam
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109283
--- Comment #6 from accelerator0099 at gmail dot com ---
Still ICEs in truck
commit 28b508233a12c13295f960a2cb8a4864879acfb4
May 25 2024
version 15.0.0
Output:
co_yield_bug.cc:197:31: error: redefinition of default argument for ‘class
_Alloc’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106757
--- Comment #9 from Jonathan Leffler ---
I can confirm that GCC 14.1.0 does not report the problems, after all.
GCC 13.2.0 and GCC 12.1.0 and 12.2.0 do.
Apologies for the confusion.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113433
--- Comment #3 from Andrew Pinski ---
Created attachment 58288
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58288&action=edit
Patch which works
Just need to add testcases.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113265
--- Comment #5 from Andrew Pinski ---
*** Bug 113433 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113433
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113265
--- Comment #6 from Andrew Pinski ---
Created attachment 58289
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58289&action=edit
Patch without testcase
Just need to add testcases but the patch was able to bootstrap/test without any
regress
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115226
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-05-26
Keywords|
42 matches
Mail list logo
