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

[tobi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115267

Bug ID: 115267
   Summary: Undue warning about undefined behavior in
   Product: gcc
   Version: 14.1.0
Status: 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 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


=== Testcase ===
#include 
#include 

double arr[4];

void read(std::istream& is) {
for (unsigned int i = 0; i < 2; ++i) {
for (unsigned int j = i; j < 2; ++j) {
is >> arr[2*i+j];
if (i != j) {
arr[2*j+i] = arr[2*i+j];
}
}
}
}

int main()
{
std::stringstream ss("1 2 3");
read(ss);
return int(arr[0] + arr[1]);
}
===

Gives with -O3 -Wall:
=
:11:39: warning: iteration 4 invokes undefined behavior
[-Waggressive-loop-optimizations]
   11 | arr[2*j+i] = arr[2*i+j];
  |  ~^
:8:36: note: within this loop
8 | for (unsigned int j = i; j < 2; ++j) {
  |   
==
Try as I might, I don't see the undefined behavior, the matrix is also
correctly filled in, no infinite loop obtains.  Signedness of the loop index
doesn't play a role.  The original code used a Eigen::Matrix2d instead of
manually indexing the 2x2 matirx, and then the warning is about iteration 2. 
The stringstream seems to be necessary to confuse the compiler enough, but
maybe there's a way of getting the same behavior with a less complex thing
inside the loop.

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

[tobi at gcc dot gnu.org via Gcc-bugs]

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 ... ]
/home/lpresearch/LPResearch/lpopenvr_lpviz/00_3rdparty/00_tracking_systems/DTrackSDK_v2.8.0/include/DTrackParse.hpp:
In static member function ‘static
boost::asio::awaitable >
LP::DTrac>
/home/lpresearch/LPResearch/lpopenvr_lpviz/00_3rdparty/00_tracking_systems/DTrackSDK_v2.8.0/include/DTrackParse.hpp:263:5:
internal compiler error: tree check: expected record_type or union_type or
qual_union_type, have array_type in bu>
0x938c90 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/tree.cc:8952
0x73fd02 tree_check3(tree_node*, char const*, int, char const*, tree_code,
tree_code, tree_code)
../../gcc/tree.h:3642
0x73fd02 build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)
../../gcc/cp/call.cc:11071
0xaa0eac maybe_promote_temps
../../gcc/cp/coroutines.cc:3142
0xaa0eac await_statement_walker
../../gcc/cp/coroutines.cc:3753
0x162f7dc walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_>
../../gcc/tree.cc:11418
0xaa0668 await_statement_walker
../../gcc/cp/coroutines.cc:3424
0x162f7dc walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_>
../../gcc/tree.cc:11418
0x162f934 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_>
../../gcc/tree.cc:11652
0xaa0668 await_statement_walker
../../gcc/cp/coroutines.cc:3424
0x162f7dc walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_>
../../gcc/tree.cc:11418
0x162f934 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_>
../../gcc/tree.cc:11652
0xaa0668 await_statement_walker
../../gcc/cp/coroutines.cc:3424
0x162f7dc walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_>
../../gcc/tree.cc:11418
0x162f934 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_>
../../gcc/tree.cc:11652
0xaa0668 await_statement_walker
../../gcc/cp/coroutines.cc:3424
0x162f7dc walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_>
../../gcc/tree.cc:11418
0x162f934 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_>
../../gcc/tree.cc:11652
0xaa0668 await_statement_walker
../../gcc/cp/coroutines.cc:3424
0x162f7dc walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_>
../../gcc/tree.cc:11418
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

The error location is this:
#2  build_special_member_call (instance=0x7fffe891d090, name=0x776f5200,
args=0x0, binfo=0x7fffe88e4540, flags=1, complain=3) at
../../gcc/cp/call.cc:11071
11071 binfo = TYPE_BINFO (binfo);
(gdb) l
11066   {
11067 /* Resolve the name.  */
11068 if (!complete_type_or_maybe_complain (binfo, NULL_TREE,
complain))
11069   return error_mark_node;
11070
11071 binfo = TYPE_BINFO (binfo);
11072   }
11073
11074 gcc_assert (binfo != NULL_TREE);
11075
(gdb)

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

[tobi at gcc dot gnu.org via Gcc-bugs]

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: 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=edit
gzipped source code reduced from -report-bug output

The attached code ICEs when compiling with g++ 13.2 and compiler explorer's
trunk version . I found the same bug with the un-preprocessed code with Ubuntu
22.04's default g++11.

Compiler Explorer link here:
https://godbolt.org/z/3cMn45xz6

example command line to trigger the bug: /usr/bin/g++ -DEIGEN_MPL2_ONLY
-DSPDLOG_COMPILED_LIB -DSPDLOG_FMT_EXTERNAL
-I/home/lpresearch/LPResearch/lpopenvr_lpviz/00_3rdparty/00_tracking_systems/DTrackSDK_v2.8.0/include
-I/home/lpresearch/LPResearch/lpopenvr_lpviz/00_tools -isystem
/home/lpresearch/.conan/data/boost/1.83.0/_/_/package/8cc3305c27e5ff838d1c7590662e309638310dfc/include
-isystem
/home/lpresearch/.conan/data/eigen/3.4.0/_/_/package/5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9/include/eigen3
-isystem
/home/lpresearch/.conan/data/fmt/10.1.1/_/_/package/20da98908a15523bbe9f086a5c57a4bde424a9c0/include
-isystem
/home/lpresearch/.conan/data/expected-lite/0.6.3/_/_/package/5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9/include
-isystem
/home/lpresearch/.conan/data/spdlog/1.12.0/_/_/package/17da8a8753b9f1e2e594e9ec31ee01c6fcb2c8f9/include
-g -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -std=gnu++20 -MD -c
~/bug.cpp -freport-bug

Example output (leaving aside the warnings about mismatched linemarkers due to
the way I reduced this):

/home/lpresearch/LPResearch/lpopenvr_lpviz/00_3rdparty/00_tracking_systems/DTrackSDK_v2.8.0/include/DTrackParse.hpp:
In static member function ‘static
boost::asio::awaitable >
LP::DTrackDebugDataListener::Impl::start(const LP::ArtController&)’:
/home/lpresearch/LPResearch/lpopenvr_lpviz/00_3rdparty/00_tracking_systems/DTrackSDK_v2.8.0/include/DTrackParse.hpp:263:5:
internal compiler error: in build_special_member_call, at cp/call.cc:11085
0x85a411 build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)
../../src/gcc/cp/call.cc:11085
0xbe851b maybe_promote_temps
../../src/gcc/cp/coroutines.cc:3146
0xbe851b await_statement_walker
../../src/gcc/cp/coroutines.cc:3757
0x126b106 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
../../src/gcc/tree.cc:11327
0xbe7c4e await_statement_walker
../../src/gcc/cp/coroutines.cc:3428
0x126b106 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
../../src/gcc/tree.cc:11327
0x126b23c walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
../../src/gcc/tree.cc:11558
0xbe7c4e await_statement_walker
../../src/gcc/cp/coroutines.cc:3428
0x126b106 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
../../src/gcc/tree.cc:11327
0x126b23c walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
../../src/gcc/tree.cc:11558
0xbe7c4e await_statement_walker
../../src/gcc/cp/coroutines.cc:3428
0x126b106 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
../../src/gcc/tree.cc:11327
0x126b23c walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
../../src/gcc/tree.cc:11558
0xbe7c4e await_statement_walker
../../src/gcc/cp/coroutines.cc:3428
0x126b106 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
../../src/gcc/tree.cc:11327
0x126b23c walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
../../src/gcc/tree.cc:11558

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

[tobi at gcc dot gnu.org via Gcc-bugs]

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++/98675] Accessing member of temporary outside its lifetime allowed in constexpr function

[tobi at gcc dot gnu.org via Gcc-bugs]

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

[tobi at gcc dot gnu.org via Gcc-bugs]

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 #2 from Tobias Schlüter  ---
Here's another testcase (derived from code in the Eigen library ) that seems to
illustrate the same issue. Please follow the compiler explorer link to see a
non-constexpr version and its gimple that makes clear that there indeed is a
lifetime issue and also clang's error message https://godbolt.org/z/4zoKaoKa5

struct B;

#define CONSTEXPR constexpr
#define CONSTEVAL consteval

struct A {
public:
CONSTEXPR A() { m_val = 1; }
CONSTEXPR A(const A& other) { m_val = other.m_val;}
CONSTEXPR ~A() {};

CONSTEXPR int val() { return m_val; }

int m_val;

CONSTEXPR B operator<<(int);
};

struct B {
A& m_a;
CONSTEXPR B(A& ref) : m_a(ref) {}
CONSTEXPR B& operator,(int i) { m_a.m_val = i; return *this; }
CONSTEXPR ~B() { finished(); }
CONSTEXPR A finished() { return m_a; }
};

CONSTEXPR B A::operator<<(int i) {
m_val = i;
return B(*this);
}

CONSTEVAL int f()
{
A a = (A() << 1, 2, 3, 4).finished();
return a.val();
}

int g()
{
return f();
}

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

[tobi at gcc dot gnu.org via Gcc-bugs]

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 to figure out a good way of conveying
this information.

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

[tobi at gcc dot gnu.org via Gcc-bugs]

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 comparison to gcc's, but an analysis how it
conveys all the information I need to find and fix the issue. 

Glad to see that we more or less agree on the issues with gcc's message,
though.  That's the important part anyway.  I also like your suggestion.  If we
are at a stage where grammatical niceties matter, I would make the symbol in
the first message the subject, so

:6:6: error: 'template void X::f()' matches no declaration
6 | void X::f()
  |  ^
:2:10: note: non-matching declaration 'void X::f()' is not a template
2 | void f();
  |  ^ 

Thanks for correcting my misunderstanding about the status of the C++ FE, and
I'm glad to hear that.  I really wonder where I'd picked up that piece of
misinformation.  Actually, while I wrote this I was wondering "how do they
manage to stay up to speed with the latest versions then?"  Now I'm less
impressed ;-)

Cheers!

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

[tobi at gcc dot gnu.org via Gcc-bugs]

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 same observation.  Well, you came to a
different conclusion comparing the two and so I was wondering why I would find
clang's message more helpful and you didn't.

Here's clang's error message:
:6:9: error: out-of-line definition of 'f' does not match any
declaration in 'X'
void X::f()
^
:2:10: note: member declaration nearly matches
void f();

When I read that I know 1) there are two 'f's.  2) the one on line 6 doesn't
match the one on line 2.  3) yet it ought to match (the) one in 'struct X'.  So
I as s user am left with wondering "how does it not match" which is sufficient
to resolve the problem.

Let me point to three things where gcc ends up making things harder to
understand in my opinion:
1) clang uses (almost) complete sentences.  One doesn't have to figure out how
the parts of the error message relate to then form a logical whole from the set
of "error" and "note"s.
2) "candidate" in gcc's error message appears to be a technical term or a
gcc-specific term, one has to make sense of what it means from the context
("nothing matches -> oh, so this was a candidate for a match and this is what
'candidate' means here" whereas clang's error implies directly that the 'f' on
line 2 was really close to the one on line 6.
3) gcc's second note, which points to the struct declaration isn't really
helpful, it just floats in the ether for the user to make sense of.  I would go
so far as to claim that it doesn't add any helpful information and thus does
more bad than good.

Anyway, I'm well aware that the C++ frontend unfortunately doesn't get much
developer attention, so I'm not writing these PRs to complain, but to give a
potential future FE developer a good starting point to get their hands dirty :)

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

[tobi at gcc dot gnu.org via Gcc-bugs]

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++
  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 not be here
void X::f()
{}

gives:


:6:6: error: no declaration matches 'void X::f()'
6 | void X::f()
  |  ^
:2:10: note: candidate is: 'void X::f()'
2 | void f();
  |  ^
:1:8: note: 'struct X' defined here
1 | struct X {
  |^

Note that the error message doesn't actually include what's wrong and so it is
fairly confusing until you actually look at the code.

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

[tobi at gcc dot gnu.org via Gcc-bugs]

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
 Component: 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 {
};
};
pq queueBad;
pq queueCorrect;
};
==

gives (https://godbolt.org/z/n7v97z17s):
++
:11:31: error: type/value mismatch at argument 3 in template parameter
list for 'template class pq'
   11 | pq queueBad;
  |   ^
:11:31: note:   expected a type, got 'A::QD::Comparator'
++

To which my response is "A::QD::Comparator is a type".  Compare this to
clang's clear and actionable:
--
:11:17: error: template argument for template type parameter must be a
type; did you forget 'typename'?
pq queueBad;
^
typename 
:1:34: note: template parameter is declared here
template
 ^
1 error generated.
--

Besides not being actionable, "type/value mismatch" appears to be a
compiler-internal category of problem and thus isn't very user-friendly.

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

[tobi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24568

Tobias Schlüter  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #11 from Tobias Schlüter  ---
Take milliDiff = INT_MIN (<0).

 milliDiff_6 = -milliDiff_5(D);   // milliDiff_6 = INT_MIN (still <0)
 minutesDiff_13 = milliDiff_6 / 6;// minutesDiff_13 = INT_MIN/6 =
-35791;
 minutesDiff_8 = -minutesDiff_13; // minutesDiff_8 = 35791 (>0!)

So negation and division don't commute over the two's complement integers, and
I don't think there is any bug left.  I'm taking the liberty to close this. 
Link to a demonstration on the Compiler Explorer:
https://godbolt.org/z/hnjcMdjnq

Why the person who wrote that original bit of code wanted to deal with INT_MIN
(LONG_MIN in the original, but the testcase would overflow if sizeof(int) <
sizeof(long)) in this way is another question.

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

[tobi at gcc dot gnu.org via Gcc-bugs]

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 c++/16233] unhelpful error message when "template" is omitted

[tobi at gcc dot gnu.org via Gcc-bugs]

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||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 before 'int'
6 | v->Foo();
  |^~~
:6:16: error: expected ';' before 'int'
Compiler returned: 1

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

[tobi at gcc dot gnu.org via Gcc-bugs]

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;
static constexpr auto Dim = dim;

explicit X(U x) : v(x) {}

template
X cast()
{
return X(T{v});
}
};

void f(int err) {
auto propertyHelper = [err](M&& fallback) -> M {
using FloatM = X;
FloatM v{0};
return err == 0 ? M{ v.template cast(); } :
fallback;
};
}
===
Which gives a comically wrong cascade of errors:
---
: In lambda function:
:23:28: error: expected primary-expression before '{' token
   23 | return err == 0 ? M{ v.template cast(); } :
fallback;
  |^
:23:28: error: expected ':' before '{' token
   23 | return err == 0 ? M{ v.template cast(); } :
fallback;
  |^
  |:
:23:28: error: expected primary-expression before '{' token
:23:28: error: expected ';' before '{' token
   23 | return err == 0 ? M{ v.template cast(); } :
fallback;
  |^
  |;
:23:71: error: expected primary-expression before ':' token
   23 | return err == 0 ? M{ v.template cast(); } :
fallback;
  |   ^
Compiler returned: 1
-

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

[tobi at gcc dot gnu.org via Gcc-bugs]

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;
^
Of course GCC gives errors everywhere but there :D

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

[tobi at gcc dot gnu.org via Gcc-bugs]

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

explicit X(U x) : v(x) {}

template
X cast()
{
return X(T{v});
}
};

void f(int err) {
auto propertyHelper = [err](M&& fallback) -> M {
using FloatM = X;
FloatM v{0};
return err == 0 ? M{ v.cast() } : fallback;
};
}

This gives the fairly confusing error messages:
+++
: In lambda function:
:23:28: error: expected primary-expression before '{' token
   23 | return err == 0 ? M{ v.cast() } : fallback;
  |^
:23:28: error: expected ':' before '{' token
   23 | return err == 0 ? M{ v.cast() } : fallback;
  |^
  |:
:23:28: error: expected primary-expression before '{' token
:23:28: error: expected ';' before '{' token
   23 | return err == 0 ? M{ v.cast() } : fallback;
  |^
  |;
:23:55: error: expected '(' before '>' token
   23 | return err == 0 ? M{ v.cast() } : fallback;
  |   ^
  |   (
:23:57: error: expected primary-expression before ')' token
   23 | return err == 0 ? M{ v.cast() } : fallback;
  | ^
:23:58: error: expected ';' before '}' token
   23 | return err == 0 ? M{ v.cast() } : fallback;
  |  ^~
  |  ;
:23:61: error: expected primary-expression before ':' token
   23 | return err == 0 ? M{ v.cast() } : fallback;
  | ^
Compiler returned: 1
+++

The actual cause of the error is the missing typename keyword before M (clang
points this out correctly, MSVC of course accepts the code without error
message).  This is similar to #63392 but in that case we at least get a hint as
to what the actual problem is.

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

[tobi at gcc dot gnu.org via Gcc-bugs]

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

: In function 'void f()':
:7:24: error: expected '}' before ';' token
7 | struct X x = { 1, 2; };
  |  ~ ^
: At global scope:
:8:1: error: expected declaration before '}' token
8 | }
  | ^

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

[tobi at gcc dot gnu.org via Gcc-bugs]

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
mov r9, rcx
mov rbx, rdi
mov rcx, rdx
mov r8d, 1
mov edx, 1
mov edi, 2
sub rsp, 16
lea rsi, [rsp+14]
call_gfortran_concat_string
movzx   eax, WORD PTR [rsp+14]
mov WORD PTR [rbx], ax
add rsp, 16
pop rbx
ret
... and likewise for the original testcase.

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

[tobi at gcc dot gnu.org via Gcc-bugs]

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 Tobias Schlüter  ---
Seems to be fixed also on ARM64 in 10.3, 11.1

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

[tobi at gcc dot gnu.org via Gcc-bugs]

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
 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() {
auto x = X{ 1, 2; };
}


Gives the fairly misleading error message

: In function 'void f()':
:7:15: error: expected primary-expression before '{' token
7 | auto x = X{ 1, 2; };
  |   ^

The error message is of the same kind all the way from GCC 4.1.2 up to the
current trunk.

For comparison, clang gives the much more helpful
:7:21: error: unexpected ';' before '}'
auto x = X{ 1, 2; };
^

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

[tobi at gcc dot gnu.org via Gcc-bugs]

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 Tobias Schlüter  ---
Confirmed with 10.3 and 11.1

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

[tobi at gcc dot gnu.org via Gcc-bugs]

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++
  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 warnings
disappear correctly:
#pragma GCC diagnostic ignored "-Wnarrowing"
#pragma GCC diagnostic ignored "-Woverflow"
#endif
constexpr int native{ 'ABCD' };
constexpr short i{123456}; // crosscheck
#if defined(__GNUC__)
#pragma GCC diagnostic pop
#endif
$ g++ -Wall -c t.cpp
t.cpp:8:35: warning: multi-character character constant [-Wmultichar]
 constexpr int native{ 'ABCD' };
   ^~
$

Compiler explorer link here: https://godbolt.org/z/P5cjqKs4a

Verified with all versions on the compiler explorer back to 6.2.

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

[tobi at gcc dot gnu.org via Gcc-bugs]

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.org/z/56h67rfc4

.LC0:
.string "Eigen::internal::variable_if_dynamic::variable_if_dynamic(T) [with T = long int; int Value = 0]"
.LC1:
.string
"/opt/compiler-explorer/libs/eigen/v3.3.9/Eigen/src/Core/util/XprHelper.h"
.LC2:
.string "v == T(Value)"
.LC3:
.string "Eigen::internal::variable_if_dynamic::variable_if_dynamic(T) [with T = long int; int Value = 3]"
.LC4:
.string "Eigen::internal::variable_if_dynamic::variable_if_dynamic(T) [with T = long int; int Value = 4]"
.LC5:
.string "Eigen::internal::variable_if_dynamic::variable_if_dynamic(T) [with T = long int; int Value = 1]"
func34(m34):
stp x29, x30, [sp, -128]!
mov x1, 0
mov x29, sp
stp x19, x20, [sp, 16]
mov x20, x8
mov x19, x0
add x0, sp, 40
bl  Eigen::internal::variable_if_dynamic::variable_if_dynamic(long) [complete object constructor]
add x0, sp, 41
mov x1, 0
bl  Eigen::internal::variable_if_dynamic::variable_if_dynamic(long) [complete object constructor]
str x19, [sp, 48]
add x0, sp, 56
mov x1, 3
bl  Eigen::internal::variable_if_dynamic::variable_if_dynamic(long) [complete object constructor]
add x0, sp, 57
mov x1, 4
bl  Eigen::internal::variable_if_dynamic::variable_if_dynamic(long) [complete object constructor]
add x0, sp, 58
mov x1, 0
bl  Eigen::internal::variable_if_dynamic::variable_if_dynamic(long) [complete object constructor]
add x0, sp, 59
mov x1, 0
bl  Eigen::internal::variable_if_dynamic::variable_if_dynamic(long) [complete object constructor]
str x19, [sp, 80]
add x0, sp, 90
mov x1, 0
bl  Eigen::internal::variable_if_dynamic::variable_if_dynamic(long) [complete object constructor]
add x0, sp, 91
mov x1, 0
bl  Eigen::internal::variable_if_dynamic::variable_if_dynamic(long) [complete object constructor]
str x19, [sp, 112]
add x0, sp, 120
mov x1, 1
bl  Eigen::internal::variable_if_dynamic::variable_if_dynamic(long) [complete object constructor]
add x0, sp, 121
mov x1, 4
bl  Eigen::internal::variable_if_dynamic::variable_if_dynamic(long) [complete object constructor]
str x20, [sp, 64]
add x0, sp, 72
mov x1, 3
bl  Eigen::internal::variable_if_dynamic::variable_if_dynamic(long) [complete object constructor]
ldp s18, s16, [x19]
mov x0, x20
ldp s4, s1, [x19, 8]
ldp s17, s6, [x19, 16]
fcvtd18, s18
ldp s3, s0, [x19, 24]
fcvtd16, s16
ldp s7, s5, [x19, 32]
fcvtd4, s4
ldr s2, [x19, 40]
fcvtd1, s1
fcvtd17, s17
fcvtd6, s6
fcvtd3, s3
fcvtd7, s7
fcvtd5, s5
fcvtd2, s2
fcvtd0, s0
stp d18, d17, [x20]
stp d7, d16, [x20, 16]
stp d6, d5, [x20, 32]
stp d4, d3, [x20, 48]
stp d2, d1, [x20, 64]
str d0, [x20, 80]
ldr s0, [x19, 44]
fcvtd0, s0
str d0, [x20, 88]
ldp x19, x20, [sp, 16]
ldp x29, x30, [sp], 128
ret
_GLOBAL__sub_I_func34(m34):
ret

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

[tobi at gcc dot gnu.org via Gcc-bugs]

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 DWORD PTR [esp+24]
fstpQWORD PTR [eax+8]
fld DWORD PTR [esp+40]
fstpQWORD PTR [eax+16]
fld DWORD PTR [esp+12]
fstpQWORD PTR [eax+24]
fld DWORD PTR [esp+28]
fstpQWORD PTR [eax+32]
fld DWORD PTR [esp+44]
fstpQWORD PTR [eax+40]
fld DWORD PTR [esp+16]
fstpQWORD PTR [eax+48]
fld DWORD PTR [esp+32]
fstpQWORD PTR [eax+56]
fld DWORD PTR [esp+48]
fstpQWORD PTR [eax+64]
fld DWORD PTR [esp+20]
fstpQWORD PTR [eax+72]
fld DWORD PTR [esp+36]
fstpQWORD PTR [eax+80]
fld DWORD PTR [esp+52]
fstpQWORD PTR [eax+88]
ret 4
This is the same as the assembly from 9.3 in Comment 4.

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

[tobi at gcc dot gnu.org via Gcc-bugs]

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, but without benchmarking I don't believe
that this can be beat: 
func34(m34):
pxorxmm0, xmm0
mov rax, rdi
cvtss2sdxmm0, DWORD PTR [rsp+8]
movsd   QWORD PTR [rdi], xmm0
pxorxmm0, xmm0
cvtss2sdxmm0, DWORD PTR [rsp+24]
movsd   QWORD PTR [rdi+8], xmm0
pxorxmm0, xmm0
cvtss2sdxmm0, DWORD PTR [rsp+40]
movsd   QWORD PTR [rdi+16], xmm0
pxorxmm0, xmm0
cvtss2sdxmm0, DWORD PTR [rsp+12]
movsd   QWORD PTR [rdi+24], xmm0
pxorxmm0, xmm0
cvtss2sdxmm0, DWORD PTR [rsp+28]
movsd   QWORD PTR [rdi+32], xmm0
pxorxmm0, xmm0
cvtss2sdxmm0, DWORD PTR [rsp+44]
movsd   QWORD PTR [rdi+40], xmm0
pxorxmm0, xmm0
cvtss2sdxmm0, DWORD PTR [rsp+16]
movsd   QWORD PTR [rdi+48], xmm0
pxorxmm0, xmm0
cvtss2sdxmm0, DWORD PTR [rsp+32]
movsd   QWORD PTR [rdi+56], xmm0
pxorxmm0, xmm0
cvtss2sdxmm0, DWORD PTR [rsp+48]
movsd   QWORD PTR [rdi+64], xmm0
pxorxmm0, xmm0
cvtss2sdxmm0, DWORD PTR [rsp+20]
movsd   QWORD PTR [rdi+72], xmm0
pxorxmm0, xmm0
cvtss2sdxmm0, DWORD PTR [rsp+36]
movsd   QWORD PTR [rdi+80], xmm0
pxorxmm0, xmm0
cvtss2sdxmm0, DWORD PTR [rsp+52]
movsd   QWORD PTR [rdi+88], xmm0
ret
Thanks to whoever did that.

I see that a release candidate for 10.2.1 has been cut.  I would assume that
it's not fixed in 10.2.1 because there would be a bugfix mentioned here.  My
experience is clearly not representative and I can appreciate that there was no
deluge of performance regression PRs, but I would think that Eigen is an
important enough library that one should consider whether breaking it like this
is really something that should survive several (sub-)releases.

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

[tobi at gcc dot gnu.org via Gcc-bugs]

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 , so I wonder why the Fortran f.e. can't do that?  One
possible problem is that if j's address escapes (in the sense that the compiler
assumes that subsequent function calls can do whatever to it), you'd need a new
fake memory location.

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

[tobi at gcc dot gnu.org via Gcc-bugs]

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 #1 from Tobias Schlüter  ---
There's a typo in the example, /= instead of !=.  Fixed example below:

I sprinkled const's all over foo's prototype and 'i' still gets reloaded so it
stands to reason that the compiler doesn't see the optimization opportunity. 

==

void foo (int *);

void bar (int n)
{
  int i;
  for (i=0; i