https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118803
--- Comment #4 from Andrew Pinski ---
(In reply to Lorinczy Zsigmond from comment #3)
> > On elf targets including Linux, collect2 does not produce any `*cdtor.c`
> > files. Instead there is an elf section which gets used.
>
> Well `strace(1)`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24878
Thomas Koenig changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118791
--- Comment #3 from sandra at gcc dot gnu.org ---
Curiously, on the OG14 development branch the rvalue calls work but the lvalue
ones are broken instead:
$ install/bin/x86_64-none-linux-gnu-g++ -fopenmp -S quux.C
quux.C: In instantiation of 'vo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118791
--- Comment #4 from sandra at gcc dot gnu.org ---
Ooops, I meant "specific to OG14 branch" in my last comment.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117263
--- Comment #3 from GCC Commits ---
The master branch has been updated by Jeff Law :
https://gcc.gnu.org/g:b81bb3ed216213fdaba82addae9fc34619ad6ec7
commit r15-7450-gb81bb3ed216213fdaba82addae9fc34619ad6ec7
Author: Dario Gjorgjevski
Date: Su
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115123
--- Comment #2 from GCC Commits ---
The master branch has been updated by Jeff Law :
https://gcc.gnu.org/g:22e30d60b971eed9a4754ea920d05b1b7e89090a
commit r15-7451-g22e30d60b971eed9a4754ea920d05b1b7e89090a
Author: Jeff Law
Date: Sun Feb 9 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114622
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114385
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100733
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99302
--- Comment #3 from Thomas Koenig ---
(In reply to Roland Illig from comment #2)
> Maybe you can ask Martin Sebor for details regarding the diagnostics.
>
> There are several other code smells in that area, such as:
"Code smells" is not a prob
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118168
--- Comment #20 from David Malcolm ---
Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118809
Bug ID: 118809
Summary: Excessive memory usage with global
std::vector> in C++20 mode
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117263
Jeffrey A. Law changed:
What|Removed |Added
Summary|[12/13/14/15 Regression]|[12/13/14 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115123
Jeffrey A. Law changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118805
Sam James changed:
What|Removed |Added
Summary|[15 Regression] wrong code |[15 Regression] wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118574
--- Comment #8 from Jakub Jelinek ---
In the rhbz bug Alessandro Astone came up with:
#include
#include
#include
#include
#include
#include
using namespace std::chrono_literals;
struct TimerAwaiter {
std::chrono::milliseconds duratio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118574
--- Comment #9 from Sam James ---
(In reply to Jakub Jelinek from comment #7)
> Can you bisect to one TU using -f{,no-}range-for-ext-temps?
I started last night, but the crashers are plugins which makes it a nuisance.
I'll work more on it if th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118810
Bug ID: 118810
Summary: collect2 should delay creating of temp
.cdtor.c/.cdtor.o files until needed
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118809
Andrew Pinski changed:
What|Removed |Added
Keywords||compile-time-hog
--- Comment #1 from An
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118598
--- Comment #2 from Jeffrey A. Law ---
It looks like it shrink-wraps to me. The frame setup happens after the a == 42
early exit. Where you expecting something else?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118598
--- Comment #3 from Andrew Pinski ---
(In reply to Jeffrey A. Law from comment #2)
> It looks like it shrink-wraps to me. The frame setup happens after the a ==
> 42 early exit. Where you expecting something else?
There should be a shrink wra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102390
Thomas Koenig changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55207
Thomas Koenig changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56423
--- Comment #4 from anlauf at gcc dot gnu.org ---
(In reply to Thomas Koenig from comment #3)
> > $ cat z2.f90
> > program p
> >integer, target :: x(3) = [7, 8, 9]
> >type t
> > integer, pointer :: a(:)
> >end type
> >type(t)
101 - 124 of 124 matches
Mail list logo