https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120299
--- Comment #13 from Tymi ---
(In reply to Jonathan Wakely from comment #12)
> (In reply to Tymi from comment #4)
> > Why not check for __clang__ and fallback to a compatible solution then?
>
> Because that should only ever be a last resort. Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120299
--- Comment #10 from Tymi ---
Oh okay, well it's not critical and I'm going to sleep now anyway
Thank you for your quick response, and good night
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120299
--- Comment #8 from Tymi ---
(In reply to Andrew Pinski from comment #7)
> (In reply to Tymi from comment #6)
> > so it's a godbolt (compiler explorer) bug...?
>
> No, just godbolt build happened between the 2 commits.
Can we someone force/ask
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120299
--- Comment #6 from Tymi ---
so it's a godbolt (compiler explorer) bug...?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120299
--- Comment #4 from Tymi ---
Why not check for __clang__ and fallback to a compatible solution then?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120299
--- Comment #1 from Tymi ---
The following code does not compile with libstdc++ under clang:
```cpp
#include
int main(){}
```
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120299
Bug ID: 120299
Summary: GCC started using __flt128_t with no checking
whatsoever
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120271
Tymi changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120271
--- Comment #1 from Tymi ---
never mind, gcc parses it correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120271
Bug ID: 120271
Summary: typename T not allowed in sizeof
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119458
--- Comment #1 from Tymi ---
Seems to produce the optimal result with -march=haswel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119458
--- Comment #3 from Tymi ---
(In reply to Richard Biener from comment #2)
> I think this works as designed, sub vs. dec is a target tuning decision.
> I'm not sure whether atomics should behave special in any way here.
Hmm yea, and since -mtun
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119458
Bug ID: 119458
Summary: Optimisation miss: atomic_ref increment
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119072
--- Comment #2 from Tymi ---
Ah okay. Thank you!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119072
Bug ID: 119072
Summary: GCC rejects type declaration inside decltype specifier
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116802
--- Comment #9 from Tymi ---
It is indeed not related to whether Clang compiles or not. I used clang as a
reference that this is not an issue with other compilers, not as the base of
the issue. The base of the issue, is that I have forgotten abo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116802
--- Comment #7 from Tymi ---
"This issue is indeed invalid then" is not misleading. The issue is literally
invalid. `is` is a standard function.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116802
--- Comment #5 from Tymi ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Tymi from comment #2)
> > Oh, did not see that detail. It does compile with clang though.
>
> By clang you mean with libstd++ with clang or libc++?
The def
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116802
--- Comment #2 from Tymi ---
Oh, did not see that detail. It does compile with clang though.
19 matches
Mail list logo
