https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114895
--- Comment #7 from Richard Biener ---
So besides maybe no way to reproduce the failure the source still has the issue
described.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114895
--- Comment #8 from Sam James ---
(In reply to Richard Biener from comment #7)
> So besides maybe no way to reproduce the failure the source still has the
> issue
> described.
Sorry, not following -- jakub's attached one has #define _FILE_OFFSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114910
--- Comment #4 from Marc Poulhiès ---
Oh, so maybe I could use `-fno-var-tracking` to workaround the failure... I'll
try that, thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114895
--- Comment #9 from Richard Biener ---
(In reply to Sam James from comment #8)
> (In reply to Richard Biener from comment #7)
> > So besides maybe no way to reproduce the failure the source still has the
> > issue
> > described.
>
> Sorry, not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114918
Bug ID: 114918
Summary: ICE when building gcl with LTO
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: ice-checking
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114918
--- Comment #1 from Sam James ---
Created attachment 58082
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58082&action=edit
block.i.xz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114918
--- Comment #2 from Sam James ---
oops:
> We also had a rep
We had another report of this, curiously again lisp, for ecl with
https://bugs.gentoo.org/931081. I haven't investigated that at all though.
Maybe it's a bundled copy of gcl in there o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114895
--- Comment #10 from Sam James ---
Ah, sorry, you meant GCC sources, not configure test source. ack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114458
--- Comment #4 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:2f15787f2e1a3afe2c2ad93d4eb0d3c1f73c8fbd
commit r15-105-g2f15787f2e1a3afe2c2ad93d4eb0d3c1f73c8fbd
Author: Jakub Jelinek
Date: Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92538
Tamar Christina changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110338
Bug 110338 depends on bug 114458, which changed state.
Bug 114458 Summary: [C++26] P2573R2 - = delete("reason");
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114458
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114458
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114895
--- Comment #11 from Richard Biener ---
So the trigger is Y2038, aka missing -D_TIME_BITS=64 - reproducible in a
qemu environment with -rtc base=2038-01-20T00:00:00
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114918
--- Comment #3 from Sam James ---
Reduced (!):
```
typedef struct lispunion *object;
struct lispunion {};
object Icall_gen_error_handler_noreturn() __attribute__((noreturn));
volatile object sLblock;
void(Fblock)(volatile object) { Icall_gen_err
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114919
Bug ID: 114919
Summary: ICE when building ecl with LTO
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: ice-checking
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114919
--- Comment #1 from Sam James ---
reducing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110343
--- Comment #7 from Jakub Jelinek ---
Note, GCC 15 stage1 is open, so feel free to post your patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114918
--- Comment #4 from Sam James ---
*** Bug 114919 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114919
Sam James changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114912
--- Comment #7 from Andrew Pinski ---
Created attachment 58084
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58084&action=edit
Something like this
This should cause the char array be on the correct alignment ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114912
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-05-02
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114898
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114898
--- Comment #4 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #3)
> Dup of Bug 102257, which might be what CWG 2586 says should happen, sadly.
Oops 2856
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102257
Jonathan Wakely changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102257
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114920
Bug ID: 114920
Summary: null_terminated_string_arg attribute does not warn for
non-nul-terminated strings
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114921
Bug ID: 114921
Summary: Optimization flags cause _Float16 to __bf16 casting to
do nothing
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113836
Gaius Mulley changed:
What|Removed |Added
Attachment #57395|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110710
--- Comment #15 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:985b5a90f70c7376c771317c6c8c3bc5ef05e227
commit r15-107-g985b5a90f70c7376c771317c6c8c3bc5ef05e227
Author: Peter Damianov
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110710
--- Comment #16 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:a704554d2e798e2e1b74b9fea4baf3477180bd9d
commit r15-108-ga704554d2e798e2e1b74b9fea4baf3477180bd9d
Author: Peter Damianov
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110710
Richard Biener changed:
What|Removed |Added
Known to work||15.0
--- Comment #17 from Richard Bien
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114147
--- Comment #12 from GCC Commits ---
The releases/gcc-11 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:0ecb0967b4f7e68027492ac03e5dc03b5bcfdcf7
commit r11-11411-g0ecb0967b4f7e68027492ac03e5dc03b5bcfdcf7
Author: Jonathan Wa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114147
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114899
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114901
Richard Biener changed:
What|Removed |Added
Keywords||ice-on-valid-code
Version|u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114908
Richard Biener changed:
What|Removed |Added
CC||mkretz at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114912
--- Comment #9 from Richard Biener ---
(In reply to Andrew Pinski from comment #8)
> The other way of fixing this is to use an union and I think since we are
> using C++11, it might work correctly.
>
> I do think we should prefer the union rath
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114913
Richard Biener changed:
What|Removed |Added
Component|middle-end |c++
--- Comment #6 from Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114866
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
URL|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114918
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114579
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |15.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865
--- Comment #14 from Jonathan Wakely ---
Because a constexpr function can't have an if statement in C++11.
But maybe we should just clear padding unconditionally for C++11.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865
--- Comment #15 from Jonathan Wakely ---
--- a/libstdc++-v3/include/std/atomic
+++ b/libstdc++-v3/include/std/atomic
@@ -238,8 +238,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
constexpr atomic(_Tp __i) noexcept : _M_i(__i)
{
-#if __cpl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114921
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865
--- Comment #16 from Jonathan Wakely ---
Alternatively, we could skip all the padding cope in compare_exchange for
C++11, since that was a C++20 change and not a DR.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865
--- Comment #17 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #15)
> --- a/libstdc++-v3/include/std/atomic
> +++ b/libstdc++-v3/include/std/atomic
> @@ -238,8 +238,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>
>constexp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865
--- Comment #18 from Jonathan Wakely ---
So maybe:
diff --git a/libstdc++-v3/include/bits/atomic_base.h
b/libstdc++-v3/include/bits/atomic_base.h
index aa7374bb252..662cff39df5 100644
--- a/libstdc++-v3/include/bits/atomic_base.h
+++ b/libstdc+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112958
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #6 from Gerald Pfeifer ---
> FreeBSD i386 is on it's way out: FreeBSD 14 is the last series supporting
> it; FreeBSD 15 is dropping support for it.
Ah, I wasn't aware of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113836
--- Comment #10 from GCC Commits ---
The master branch has been updated by Gaius Mulley :
https://gcc.gnu.org/g:43dc4302b4181535d24e83759514b774ae4dbfcc
commit r15-110-g43dc4302b4181535d24e83759514b774ae4dbfcc
Author: Gaius Mulley
Date: Thu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113836
Gaius Mulley changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114672
Richard Ball changed:
What|Removed |Added
CC||ricbal02 at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113706
--- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #13 from Jason Merrill ---
> Should be fixed now.
It is indeed. Thanks a lot.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114922
Bug ID: 114922
Summary: fsyntax-only need the modules
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114923
Bug ID: 114923
Summary: gcc ignores escaping pointer and applies invalid
optimization
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114923
--- Comment #1 from nfxjfg at googlemail dot com ---
To make this explicitly clear: I expect that gcc reads back the buf value from
memory and returns that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114924
Bug ID: 114924
Summary: [11/12/13/14/15 Regression] Wrong update of MEM_EXPR
by RTL loop unrolling since r11-2963-gd6a05b494b4b71
Product: gcc
Version: 14.0
Status: UNCO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114924
Alex Coplan changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |acoplan at gcc dot
gnu.org
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101865
--- Comment #24 from GCC Commits ---
The releases/gcc-12 branch has been updated by Peter Bergner
:
https://gcc.gnu.org/g:135402288a1b1b082d2e71ff2ee5c63b7dafed9f
commit r12-10408-g135402288a1b1b082d2e71ff2ee5c63b7dafed9f
Author: Peter Bergner
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101865
--- Comment #25 from GCC Commits ---
The releases/gcc-12 branch has been updated by Peter Bergner
:
https://gcc.gnu.org/g:04ca18ff5e2592ac88a5b72248332f519a17184b
commit r12-10409-g04ca18ff5e2592ac88a5b72248332f519a17184b
Author: Will Schmidt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114910
--- Comment #5 from Mikael Pettersson ---
I don't use crosstool-ng, but I have no problems building a cross to
c6x-unknown-elf with binutils-2.42, gcc-14.1.0-RC-20240430, and
newlib-4.4.0.20231231. (A cross to c6x-unknown-uclibc with uclibc-ng-1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114923
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114923
--- Comment #3 from nfxjfg at googlemail dot com ---
I'm expecting gcc to realize that the pointer escaped into the unknown, and
that it can't assume that the memory won't change. This is just causality, not
any vague made up viralyness.
Anyway,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114917
--- Comment #1 from GCC Commits ---
The master branch has been updated by Nathaniel Shead :
https://gcc.gnu.org/g:7317d62a1200dbd3685015e5d6b811497a27fe5f
commit r15-114-g7317d62a1200dbd3685015e5d6b811497a27fe5f
Author: Nathaniel Shead
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114917
Nathaniel Shead changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
Bug 103524 depends on bug 114917, which changed state.
Bug 114917 Summary: [modules] Explicit specialisations in export namespace not
permitted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114917
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114923
--- Comment #4 from Alexander Monakov ---
You can place points of possible access outside of abstract machine in a
fine-grained manner with volatile asms:
asm volatile("" : "=m"(buf));
This cannot be reordered against accesses to volatile va
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114913
Patrick Palka changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104606
--- Comment #15 from GCC Commits ---
The releases/gcc-13 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:3d16f8f2aec9583422d00c531732ca9d33e6ef26
commit r13-8674-g3d16f8f2aec9583422d00c531732ca9d33e6ef26
Author: Jonathan Wak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93672
--- Comment #7 from GCC Commits ---
The releases/gcc-13 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:fcf60d0baafa1245f768ac375dc60a07e92e9673
commit r13-8675-gfcf60d0baafa1245f768ac375dc60a07e92e9673
Author: Jonathan Wakel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104606
Jonathan Wakely changed:
What|Removed |Added
Known to work||13.2.1, 14.0
Summary|[11/1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93672
Jonathan Wakely changed:
What|Removed |Added
Known to work||13.2.1, 14.0
Summary|[11/12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114925
Bug ID: 114925
Summary: include/bits/fs_path.h#L841 deprecation note suggests
UB
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114865
--- Comment #19 from Peter Dimov ---
This should work.
I still don't understand why JF so insisted on all these padding shenanigans.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114925
--- Comment #1 from Andrew Pinski ---
I thought char8_t is still a character type so aliasing wise it falls under
that rule.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114913
Patrick Palka changed:
What|Removed |Added
See Also|https://gcc.gnu.org/bugzill |https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111709
John David Anglin changed:
What|Removed |Added
Last reconfirmed||2024-05-02
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114065
--- Comment #25 from Nicolas Boulenguez ---
The suggested changes for libgnat slightly affect gprbuild.
https://salsa.debian.org/debian/gprbuild/-/blob/debian/master/debian/patches/adapt-to-private-time-t.diff
https://salsa.debian.org/debian/gpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114926
Bug ID: 114926
Summary: Add way to silence deprecation warning for fs::u8path
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114925
--- Comment #2 from fabian_kessler at gmx dot de
---
(In reply to Andrew Pinski from comment #1)
> I thought char8_t is still a character type so aliasing wise it falls under
> that rule.
Actually no. They are distinct types and only 4 types a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114734
--- Comment #15 from GCC Commits ---
The master branch has been updated by Patrick O'Neill :
https://gcc.gnu.org/g:ff4dc8b10a421cdb0c56f7f8c238609de4f9fbe2
commit r15-116-gff4dc8b10a421cdb0c56f7f8c238609de4f9fbe2
Author: Patrick O'Neill
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114922
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |INVALID
Status|U
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114925
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2024-05-02
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114910
--- Comment #6 from Marc Poulhiès ---
It fails with -Os.
It works with -O0, -O1, -O2, -O3 and -Os -fno-var-tracking.
Mikael, is it possible that you're not using -Os for target libs?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114922
kargls at comcast dot net changed:
What|Removed |Added
CC||kargls at comcast dot net
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114920
David Malcolm changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114923
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114923
--- Comment #6 from Andrew Pinski ---
Some resources about memory barriers and why they are needed here (for both HW
and SW):
https://en.wikipedia.org/wiki/Memory_barrier
https://www.kernel.org/doc/Documentation/memory-barriers.txt
https://www.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114672
--- Comment #5 from GCC Commits ---
The releases/gcc-13 branch has been updated by Richard Ball
:
https://gcc.gnu.org/g:0d625dc1bffd885b04eb90ff48a6d34acacc3e0b
commit r13-8676-g0d625dc1bffd885b04eb90ff48a6d34acacc3e0b
Author: Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114672
--- Comment #6 from GCC Commits ---
The releases/gcc-12 branch has been updated by Richard Ball
:
https://gcc.gnu.org/g:87e37c72cfb153d65ac8b26d6f2d1fe155818318
commit r12-10410-g87e37c72cfb153d65ac8b26d6f2d1fe155818318
Author: Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114582
--- Comment #1 from Ian Lance Taylor ---
The bug here, and also with PR 114581, is in unwinding from a signal call. A
simplified version of the code for this issue is:
func main() {
defer func() { recover() }()
f()
}
func f() { *p = 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114581
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114582
--- Comment #2 from Ian Lance Taylor ---
*** Bug 114581 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114584
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114582
--- Comment #4 from Ian Lance Taylor ---
*** Bug 114584 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114583
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114582
--- Comment #3 from Ian Lance Taylor ---
*** Bug 114583 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114912
--- Comment #10 from Andrew Pinski ---
If Aldy does not fix it by Saturday, I will give the union a try then. I will
also try out the solaris machine on the compile farm if possible.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77704
Rustam Abdullaev changed:
What|Removed |Added
CC||rustamabd at gmail dot com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114912
--- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #10 from Andrew Pinski ---
> If Aldy does not fix it by Saturday, I will give the union a try then. I will
Great, thanks. Your alignas patch also worked fine btw.
> al
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107021
Martin Jambor changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
--- Comment
1 - 100 of 141 matches
Mail list logo
