https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112557
--- Comment #1 from Tobias Schlüter ---
With today's trunk on x86-64 I can reproduce this, giving the following:
$ ../gcc.git/build/gcc/cc1plus t.cc --std=c++20 -fpermissive
-fext-numeric-literals 2>&1
[ ... stripping away thousands of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112557
Bug ID: 112557
Summary: ICE with coroutines in build_special_member_call, at
cp/call.cc:11093
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98675
--- Comment #5 from Tobias Schlüter ---
I've submitted this to clang's bug tracker as well.
https://github.com/llvm/llvm-project/issues/53494
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98675
--- Comment #3 from Tobias Schlüter ---
Sorry, in my example, I think actually clang is wrong.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98675
Tobias Schlüter changed:
What|Removed |Added
CC||tobi at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101811
--- Comment #6 from Tobias Schlüter ---
Sure, that's a good argument (before I18N), and I guess it matches the general
style.
Anyway, I'll try to keep myself from bikeshedding this further, I'm sure the
person fixing this will have enough time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101811
--- Comment #4 from Tobias Schlüter ---
Hi Jonathan,
I know that we disagree about clang's error message and that's why I tried to
explain what makes clang's a better error message for me. My "parsing" of
clang's error message was not a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101811
--- Comment #2 from Tobias Schlüter ---
Hi Jonathan,
actually I found clang's error message a lot more helpful, I just didn't bother
to write it explicitly, especially given that my compiler explorer link shows
it for everybody else to make the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101811
Bug ID: 101811
Summary: Error not helpful for misplaced 'template'
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101712
Bug ID: 101712
Summary: Bad error message with reference to nested type.
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24568
Tobias Schlüter changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101435
--- Comment #3 from Tobias Schlüter ---
Thank you! I would certainly have found the other bug had I put the right
keyword into the title of the PR myself ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16233
Tobias Schlüter changed:
What|Removed |Added
Last reconfirmed|2015-09-18 00:00:00 |2021-07-14 0:00
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101232
--- Comment #2 from Tobias Schlüter ---
Here's another way to trigger this, inspired by my other PR101435
(https://godbolt.org/z/no6aEqvh3):
===
template
class X {
public:
U v;
using Scalar = U;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101435
--- Comment #1 from Tobias Schlüter ---
Grrr, I made a mistake in describing the issue with the code: what is missing
is the `template` keyword before `cast`, so it should read
return err == 0 ? M{ v.template cast() } : fallback;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101435
Bug ID: 101435
Summary: Bad error with missing typename keyword
Product: gcc
Version: 11.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101232
--- Comment #1 from Tobias Schlüter ---
BTW an equivalent C example gives the proper error both with C and C++
https://godbolt.org/z/sWc67eWT8
=
struct X {
int a;
int b;
};
void f() {
struct X x = { 1, 2; };
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25714
--- Comment #8 from Tobias Schlüter ---
No more temporary FAICT https://godbolt.org/z/o8fYE1nej
If written as a proper function:
function c(a, b)
character(2) :: c
character(1) :: a
character(1) :: b
c = a//b
end
we get:
c_:
pushrbx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95859
Tobias Schlüter changed:
What|Removed |Added
Known to work||10.3.0, 11.1.0
--- Comment #15 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101232
Bug ID: 101232
Summary: Bad error message with stray semicolon in initializer
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67193
Tobias Schlüter changed:
What|Removed |Added
Known to fail||10.3.0, 11.1.0
--- Comment #4 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100891
Bug ID: 100891
Summary: #pragma GCC diagnostic ignored
Product: gcc
Version: 10.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95859
--- Comment #13 from Tobias Schlüter ---
I'm sorry to say that the problem is NOT fixed on the trunk. With "ARM64 gcc
trunk" on the compiler explorer, we get the below. OTOH 9.3 produces perfect
code. Compiler explorer link:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95859
--- Comment #12 from Tobias Schlüter ---
Because I posted 32bit code before, here is what the trunk does with -m32
func34(m34):
fld DWORD PTR [esp+8]
mov eax, DWORD PTR [esp+4]
fstpQWORD PTR [eax]
fld
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95859
--- Comment #11 from Tobias Schlüter ---
Works on trunk now but not 10.2. Compiler explorer link:
https://godbolt.org/z/1zbh4YM4W
On the trunk we get the following. I'm guessing that one could enhance the
read pattern by using more registers,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98552
--- Comment #3 from Tobias Schlüter ---
Don't ask how long I'd been staring at the assembly in disbelief until I
figured out what had gone wrong :-)
In this particular case the problem can be addressed by passing into the
function instead of ,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98552
Tobias Schlüter changed:
What|Removed |Added
CC||tobi at gcc dot gnu.org
--- Comment
27 matches
Mail list logo
