[Bug fortran/31593] Invariant DO loop variables and subroutines

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31593 Tobias Schlüter changed: What|Removed |Added Status|ASSIGNED|NEW

[Bug rtl-optimization/95859] New: Statically true asserts not recognized as such with -O2, but with -O1, -Og, -O3

Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: tobi at gcc dot gnu.org Target Milestone: --- With -O2 compiling for x86-64, the compiler doesn't recognize that a number of assertions in the code are

[Bug ipa/95859] Statically true asserts not recognized as such with -O2, but with -O1, -Og, -O3

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95859 --- Comment #2 from Tobias Schlüter --- Created attachment 48779 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48779&action=edit Preprocessed source x86 (32bit) Here's preprocessed source for x86 (32 bit). This shows the same behavior as

[Bug ipa/95859] Statically true asserts not recognized as such with -O2, but with -O1, -Og, -O3

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95859 --- Comment #3 from Tobias Schlüter --- ps here's the compiler explorer link for the preprocessed test. https://godbolt.org/z/zDw5JQ I tried manually reducing it, but couldn't easily get below the 1000kib limit.

[Bug ipa/95859] Statically true asserts not recognized as such with -O2, but with -O1, -Og, -O3

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95859 --- Comment #4 from Tobias Schlüter --- This is a regression. 9.3 works, producing this assembly with -O2 -m32: func34(m34): fld DWORD PTR [esp+8] mov eax, DWORD PTR [esp+4] fstpQWORD PTR [eax] fld

[Bug ipa/95859] [10/11 regression] Statically true asserts not recognized as such with -O2, but with -O1, -Og, -O3

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95859 Tobias Schlüter changed: What|Removed |Added Summary|Statically true asserts not |[10/11 regression] |

[Bug ipa/95859] [10/11 regression] Statically true asserts not recognized as such with -O2, but with -O1, -Og, -O3

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95859 --- Comment #6 from Tobias Schlüter --- Added the regression tag to the title.

[Bug tree-optimization/96135] New: [9/10/11 regression] bswap not detected by bswap pass, unexpected results between optimization levels

: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: tobi at gcc dot gnu.org Target Milestone: --- This is an odd one, and it seems different from the other bswap bugs that I could find in

[Bug fortran/31593] Invariant DO loop variables and subroutines

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31593 Tobias Schlüter changed: What|Removed |Added Assignee|tobi at gcc dot gnu.org|unassigned at gcc dot gnu.org

[Bug ipa/95859] [10/11 regression] Statically true asserts not recognized as such with -O2, but with -O1, -Og, -O3

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95859 Tobias Schlüter changed: What|Removed |Added Attachment #48779|0 |1 is obsolete|

[Bug fortran/56293] I/O: Segfault in write_float when trying to print a not-word-aligned REAL(16) / -fno-align-commons

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56293 Tobias Schlüter changed: What|Removed |Added CC||tobi at gcc dot gnu.org --- Comment

[Bug fortran/56293] Segfault when trying to access pass-by-reference value of a not-word-aligned REAL(16) / -fno-align-commons

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56293 --- Comment #7 from Tobias Schlüter 2013-03-11 00:15:43 UTC --- (In reply to comment #6) > > The question is also whether one can construct a fully standard-conform > > example > > which fails without -fno-align-commons – and whether some real-

[Bug bootstrap/54292] New: Errors due to conflicting strsignal headers

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54292 Bug #: 54292 Summary: Errors due to conflicting strsignal headers Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priori

[Bug bootstrap/54292] Errors due to conflicting strsignal headers

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54292 --- Comment #1 from Tobias Schlüter 2012-08-16 21:49:53 UTC --- Created attachment 28038 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28038 configure log

[Bug bootstrap/54292] [4.8 Regression] Errors due to conflicting strsignal headers

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54292 --- Comment #4 from Tobias Schlüter 2012-08-17 12:31:13 UTC --- Yes, I now see a new failure that also strikes me as fairly weird (again, I'm using an in-tree gmp, mpfr, mpc): /Users/tobi/src/gcc/build/./prev-gcc/g++ -B/Users/tobi/src/gcc/build/

[Bug bootstrap/54292] [4.8 Regression] Errors due to conflicting strsignal headers

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54292 --- Comment #5 from Tobias Schlüter 2012-08-17 13:46:13 UTC --- It seems the build picks up the wrong mpfr.h header, the function was renamed in mpfr > 3.0.0, but API compatibility is ensured via a macro, see:

[Bug bootstrap/54304] New: linking stage picks up system mpfr instead of in-tree version

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54304 Bug #: 54304 Summary: linking stage picks up system mpfr instead of in-tree version Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED

[Bug bootstrap/54292] [4.8 Regression] Errors due to conflicting strsignal headers

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54292 --- Comment #6 from Tobias Schlüter 2012-08-17 19:07:35 UTC --- This latter issue is now PR54304.

[Bug bootstrap/54304] linking stage picks up system mpfr instead of in-tree version

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54304 Tobias Schlüter changed: What|Removed |Added Host||darwin --- Comment #2 from Tobias Schlü

[Bug bootstrap/54304] linking stage picks up system mpfr instead of in-tree version

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54304 --- Comment #4 from Tobias Schlüter 2012-08-17 19:29:56 UTC --- BTW PR50914, though closed as invalid, indicates that similar mixups can also happen on i686-linux.

[Bug bootstrap/54304] linking stage picks up system mpfr instead of in-tree version

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54304 --- Comment #5 from Tobias Schlüter 2012-08-17 19:31:37 UTC --- It seems I have them in /usr/lib and in /opt/local/lib. How can I find out which one it picks up?

[Bug bootstrap/54304] linking stage picks up system mpfr instead of in-tree version

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54304 --- Comment #6 from Tobias Schlüter 2012-08-17 19:33:44 UTC --- Sorry, my mistake, it's ~/usr/lib not /usr/lib. I'll have to find out if that is included in any search path (I doubt it). About the one in /opt/local/lib I wasn't mistaken.

[Bug bootstrap/54304] linking stage picks up system mpfr instead of in-tree version

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54304 --- Comment #7 from Tobias Schlüter 2012-08-17 19:35:30 UTC --- Ok, the one in ~/usr/lib is 2.2.1, so this error wouldn't appear if it got picked up.

[Bug bootstrap/54304] linking stage picks up system mpfr instead of in-tree version

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54304 --- Comment #8 from Tobias Schlüter 2012-08-17 19:38:54 UTC --- Sorry, didn't mean to hit "Save Changes" yet. In the past I had to configure with ../configure --with-libiconv-prefix=/opt/local --enable-languages=fortran because otherwise the b

[Bug bootstrap/54304] linking stage picks up system mpfr instead of in-tree version

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54304 --- Comment #10 from Tobias Schlüter 2012-08-17 20:56:40 UTC --- You don't need the -L flags for the in-tree libraries at all as you could just put, say, "path_to_mpfr/libmpfr.a" on the command line. I understand that this might need some major

[Bug bootstrap/54304] linking stage picks up system mpfr instead of in-tree version

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54304 --- Comment #12 from Tobias Schlüter 2012-08-17 21:35:50 UTC --- Well, directories given by -I are searched before system directories, -L adds directories to the end of the library search list, so their functions are not equivalent. Which is the

[Bug bootstrap/54304] linking stage picks up system mpfr instead of in-tree version

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54304 --- Comment #14 from Tobias Schlüter 2012-08-17 22:25:15 UTC --- Ah, true, further down in the ld manpage this is stated clearly. Thanks!

[Bug fortran/51727] Changing module files

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51727 --- Comment #2 from Tobias Schlüter 2012-10-05 19:35:36 UTC --- I'm not in a position to test, but write_generic in module.c makes no effort to traverse the tree in a left to right order, i.e. the line write_generic ((gfc_symtree *)st->right);

[Bug bootstrap/54834] New: bootstrap fails when building libbacktrace

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54834 Bug #: 54834 Summary: bootstrap fails when building libbacktrace Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal

[Bug fortran/51727] Changing module files

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51727 --- Comment #3 from Tobias Schlüter 2012-10-06 11:41:23 UTC --- Created attachment 28372 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28372 Candidate patch Here's a patch which fixes one case of module contents not being written in a def

[Bug bootstrap/54834] bootstrap fails when building libbacktrace

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54834 --- Comment #3 from Tobias Schlüter 2012-10-09 14:00:43 UTC --- Created attachment 28399 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28399 toplevel config.log I'm attaching the toplevel config.log. From it I read that the compiler is c

[Bug bootstrap/54834] bootstrap fails when building libbacktrace

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54834 --- Comment #4 from Tobias Schlüter 2012-10-09 14:06:19 UTC --- I ran make in a directory with a pre-existing build, ao maybe that include file was an old leftover. Please don't invest any further time in this now, I'll try a clean build first.

[Bug bootstrap/54834] bootstrap fails when building libbacktrace

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54834 Tobias Schlüter changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|

[Bug fortran/51727] Changing module files

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51727 Tobias Schlüter changed: What|Removed |Added CC||tobi at gcc dot gnu.org --- Comment

[Bug fortran/51727] Changing module files

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51727 Tobias Schlüter changed: What|Removed |Added Attachment #28372|0 |1 is obsolete|

[Bug fortran/51727] Changing module files

||2012-10-11 AssignedTo|unassigned at gcc dot |tobi at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #12 from Tobias Schlüter 2012-10-11 12:37:06 UTC --- I have a patch which is

[Bug fortran/51727] Changing module files

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51727 Tobias Schlüter changed: What|Removed |Added Attachment #28410|0 |1 is obsolete|

[Bug fortran/51727] Changing module files

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51727 Tobias Schlüter changed: What|Removed |Added Attachment #28424|0 |1 is obsolete|

[Bug fortran/51727] Changing module files

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51727 --- Comment #15 from Tobias Schlüter 2012-10-11 14:01:27 UTC --- I'm sorry that I'm spamming your inboxes, but I only now read the comment in front of write_symbol1, and it says something that I was wondering about all this time, so I want to at

[Bug fortran/51727] Changing module files

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51727 --- Comment #19 from Tobias Schlüter 2012-10-13 08:31:39 UTC --- Simon, I don't think the 'integer's are functions of the pointers once you process the symbols in a defined order. The non-determinism was caused by traversing the pointer_info tr

[Bug fortran/51727] Changing module files

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51727 --- Comment #21 from Tobias Schlüter 2012-10-13 09:32:10 UTC --- Hm, I don't know about anonymous symbols. If they exist and end up in modules (which I honestly don't know), I would hope that they would obtain their number from some counter, wh

[Bug bootstrap/54834] bootstrap fails when building libbacktrace

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54834 Tobias Schlüter changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID

[Bug fortran/51727] Changing module files

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51727 --- Comment #22 from Tobias Schlüter 2012-10-13 11:29:41 UTC --- Created attachment 28440 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28440 patch that doesn't use c++ Here's a patch that works essentially the same way, but doesn't use C

[Bug fortran/51727] Changing module files

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51727 --- Comment #27 from Tobias Schlüter 2012-10-28 11:15:24 UTC --- There were concerns about error handling in out-of-memory conditions which I addressed in a separate patch . This patch go

[Bug fortran/51727] Changing module files

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51727 --- Comment #28 from Tobias Schlüter 2012-11-08 15:46:13 UTC --- Author: tobi Date: Thu Nov 8 15:46:07 2012 New Revision: 193329 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193329 Log: PR fortran/51727 * module.c (sorted_pointer_info

[Bug fortran/51727] Changing module files

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51727 Tobias Schlüter changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|

[Bug fortran/51727] Changing module files

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51727 --- Comment #31 from Tobias Schlüter 2012-11-09 09:43:56 UTC --- (In reply to comment #30) > (In reply to comment #29) > > I committed the C-only version of the patch as the issues mentioned in > > comment > > #27 couldn't be addressed before s

[Bug fortran/41600] [OOP] SELECT TYPE with associate-name => exp: Arrays not supported

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41600 Tobias Schlüter changed: What|Removed |Added CC||tobi at gcc dot gnu.org --- Comment #5

[Bug middle-end/89337] Bogus "exceeds maximum object size" on unreachable code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89337 Tobias Schlüter changed: What|Removed |Added CC||tobi at gcc dot gnu.org --- Comment

[Bug fortran/56007] New: Remarkably bad error message with DO array=1,2

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56007 Bug #: 56007 Summary: Remarkably bad error message with DO array=1,2 Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal

[Bug fortran/56007] Remarkably bad error message with DO array=1,2

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56007 --- Comment #3 from Tobias Schlüter 2013-01-22 12:56:26 UTC --- Just for the fun of it, another confusing way this error message appears: $ cat t3.f90 character c(5) do c=2,3 end do END $ gfortran t3.f90 t3.f90:3.4: do c=2,3 1 Error: Loo

[Bug c++/61172] New: C++11: ICE with invalid call to template class

++ Assignee: unassigned at gcc dot gnu.org Reporter: tobi at gcc dot gnu.org I'm seeing this bug with all g++-4.7 I have access to. There seems to be no duplicate in bugzilla, even though there are a few similar bugs they are fixed in 4.7.0 the latest. Even if this is fix

[Bug c++/61172] C++11: ICE with invalid call to template class

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61172 --- Comment #1 from Tobias Schlüter --- (I see that it mentions macports. To avoid all confusion: I also see this ICE it with unmodified gcc-4.7.2 on Linux.)

[Bug c++/61172] C++11: ICE with invalid call to template class

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61172 --- Comment #3 from Tobias Schlüter --- Thanks! I wonder which option I missed when I was searching for duplicates :(

[Bug fortran/41227] COMMON block, BIND(C) and LTO interoperability issues

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41227 --- Comment #20 from Tobias Schlüter --- Let's please not invent new semantics. There are two things to distinguish: 1) legacy code, where no interoperability semantics were defined 2) new code, where the semantics are defined I don't know much

[Bug c++/67193] New: Overzealous -Wstack-usage warning

++ Assignee: unassigned at gcc dot gnu.org Reporter: tobi at gcc dot gnu.org Target Milestone: --- -Wstack-usage throws a warning if it cannot prove that the stack is bounded. Therefore it is more noisy with optimization turned off. That is fine, but sometimes it's really too

[Bug c++/67193] Overzealous -Wstack-usage warning

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67193 --- Comment #2 from Tobias Schlüter --- (In reply to Andrew Pinski from comment #1) > >(I know that alloca with a fixed argument is fairly pointless, but this can > >happen with templates.) > > Why not use normal arrays for that case? Well, I

[Bug ipa/95859] [10/11 regression] Statically true asserts not recognized as such with -O2, but with -O1, -Og, -O3

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,

[Bug ipa/95859] [10/11 regression] Statically true asserts not recognized as such with -O2, but with -O1, -Og, -O3

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

[Bug ipa/95859] [10/11 regression] Statically true asserts not recognized as such with -O2, but with -O1, -Og, -O3

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://godbolt.or

[Bug tree-optimization/98552] Make more use of __builtin_undefined for assuring that variables do not change

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

[Bug tree-optimization/98552] Make more use of __builtin_undefined for assuring that variables do not change

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 &j into the function instead of

[Bug c++/100891] New: #pragma GCC diagnostic ignored

++ Assignee: unassigned at gcc dot gnu.org Reporter: tobi at gcc dot gnu.org Target Milestone: --- $ cat t.cpp #if defined(__GNUC__) #pragma GCC diagnostic push #pragma GCC diagnostic ignored "-Wmultichar" // Check that I'm disabling warnings correctly: the following war

[Bug c++/67193] Overzealous -Wstack-usage warning

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 Tob

[Bug c++/101232] New: Bad error message with stray semicolon in initializer

Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: tobi at gcc dot gnu.org Target Milestone: --- This example (Link to compiler explorer: -> https://godbolt.org/z/rxsreYs8Y <-): = struct X { int a; int b; }; void f() {

[Bug ipa/95859] [10/11/12 regression] Statically true asserts not recognized as such with -O2, but with -O1, -Og, -O3

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 To

[Bug fortran/25714] concat of strings create an extra temporary variable

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

[Bug c++/98675] Accessing member of temporary outside its lifetime allowed in constexpr function

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

[Bug c++/98675] Accessing member of temporary outside its lifetime allowed in constexpr function

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.

[Bug c++/98675] Accessing member of temporary outside its lifetime allowed in constexpr function

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

[Bug c++/101232] Bad error message with stray semicolon in initializer

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; }; } ==

[Bug c++/101435] New: Bad error with missing typename keyword

++ Assignee: unassigned at gcc dot gnu.org Reporter: tobi at gcc dot gnu.org Target Milestone: --- Consider (https://godbolt.org/z/hxnv779Tr): === template class X { public: U v; using Scalar = U; static constexpr auto Dim = dim

[Bug c++/101435] Bad error with missing typename keyword

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;

[Bug c++/101232] Bad error message with stray semicolon in initializer

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; stati

[Bug c++/16233] unhelpful error message when "template" is omitted

||tobi at gcc dot gnu.org --- Comment #11 from Tobias Schlüter --- With the current trunk we still get the same message save for the carets (https://godbolt.org/z/sWb7MbTWr) : In member function 'void B::Bar(V*)': :6:16: error: expected primary-expression b

[Bug c++/101435] Bad error with missing template keyword

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 ...

[Bug tree-optimization/24568] [meta-bug] Missed optimization: trivialization of silly code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24568 Tobias Schlüter changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug c++/101712] New: Bad error message with reference to nested type.

: c++ Assignee: unassigned at gcc dot gnu.org Reporter: tobi at gcc dot gnu.org Target Milestone: --- == template class pq; template class A { struct QD { int a; struct Comparator

[Bug c++/101811] New: Error not helpful for misplaced 'template'

mponent: c++ Assignee: unassigned at gcc dot gnu.org Reporter: tobi at gcc dot gnu.org Target Milestone: --- This is a bad error message that caught my eye while refactoring some code (https://godbolt.org/z/558vM4Wb3): struct X { void f(); }; template // this line should n

[Bug c++/101811] Error not helpful for misplaced 'template'

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

[Bug c++/101811] Error not helpful for misplaced 'template'

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 compa

[Bug c++/101811] Error not helpful for misplaced 'template'

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

[Bug tree-optimization/115267] New: Undue warning about undefined behavior in

: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: tobi at gcc dot gnu.org Target Milestone: --- This seems to be a simpler case of PR103724. I originally observed it with 4.9 but was able to reproduce it with gcc 14. Godbolt: https://godbolt.org/z/6h8bEYsvP

[Bug c++/112557] New: ICE with coroutines in build_special_member_call, at cp/call.cc:11093

: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: tobi at gcc dot gnu.org Target Milestone: --- Created attachment 56599 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56599&action=edit gzipped source code reduc

[Bug c++/112557] ICE with coroutines in build_special_member_call, at cp/call.cc:11093

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 warnings