https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116417
Bug ID: 116417
Summary: SFINAE on std::is_destructible cannot handle
destructor of scalar type
Product: gcc
Version: 14.1.1
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93022
Amyspark changed:
What|Removed |Added
CC||amy at amyspark dot me
--- Comment #1 from Am
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110710
Amyspark changed:
What|Removed |Added
CC||amy at amyspark dot me
--- Comment #6 from A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109806
Amyspark changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109806
--- Comment #19 from Amyspark ---
Working on it. Is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110315 the patch
you referred to earlier, Richard?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111635
--- Comment #7 from Amyspark ---
I can confirm this is no longer reproducible with macOS Monterey 12.7, Xcode
14.2, and the following linker version:
@(#)PROGRAM:ld PROJECT:ld64-820.1
BUILD 20:07:01 Nov 7 2022
configured to support archs: arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111635
--- Comment #6 from Amyspark ---
I need to recover my GCC installation post Homebrew forcing an OS upgrade to
Monterey. Still, I think this needs to be tested against the x64 target -- I've
seen some issues only happening when targeting it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111635
--- Comment #1 from Amyspark ---
Created attachment 56014
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56014&action=edit
Full compiler version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111635
Bug ID: 111635
Summary: Objects built with -flto cannot be linked with Xcode
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110016
--- Comment #2 from Amyspark ---
We've seen failures both in Windows (all ABI flavors) and macOS only when
compiled with GCC -- AppleClang, Clang, and MSVC (in its three flavors) all
work without issue. So I'm doubtful it's a logical issue, espe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110016
Bug ID: 110016
Summary: [12/13/14] Possible miscodegen when inlining
std::condition_variable::wait predicate causes
deadlock
Product: gcc
Version: 12.2.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109806
--- Comment #9 from Amyspark ---
(In reply to Andrew Pinski from comment #7)
> Simple testcase:
> ```
> struct basic_string {
> ~basic_string() { }
> };
> const basic_string data[] = { {} };
> ```
>
> This fails with `ulimit -s 1024` which is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109806
--- Comment #4 from Amyspark ---
(In reply to Richard Biener from comment #2)
> Likely a duplicate of a bug where ranger runs out of stack on windows
> targets.
I think you mean bug 109695? If so, it affects GCC 13 as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109806
--- Comment #3 from Amyspark ---
Created attachment 55046
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55046&action=edit
ZIP copy of the Github gist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109806
Bug ID: 109806
Summary: 13.1.0 cc1plus stack smashing crash with C array of
complex structs
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
15 matches
Mail list logo
