[Bug c++/96743] ICE on flexible array in initializer list using lambdas

[kevin at arilabs dot net]

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

--- Comment #1 from Kevin Stallard  ---
A more complete output of the error:

/home/parallels/Perforce/kevin.stallard_Ubuntu18_Helios-Nucleus-Development_9171/BraceTest/BraceTest.cpp:
In constructor 'BraceTest::BraceTest()':
/home/parallels/Perforce/kevin.stallard_Ubuntu18_Helios-Nucleus-Development_9171/BraceTest/BraceTest.cpp:23:102:
internal compiler error: in build_vec_init_elt, at cp/tree.c:665
 BraceTest::BraceTest() : _entries { {"FirstAction", [this]( const char *data)
{this->Foo( data );} } }
   
  ^

[Bug c++/96743] New: ICE on flexible array in initializer list using lambdas

[kevin at arilabs dot net]

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

Bug ID: 96743
   Summary: ICE on flexible array in initializer list using
lambdas
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kevin at arilabs dot net
  Target Milestone: ---

I'm seeing:
/home/parallels/Perforce/kevin.stallard_Ubuntu18_Helios-Nucleus-Development_9171/BraceTest/BraceTest.cpp:
In constructor 'BraceTest::BraceTest()':
/home/parallels/Perforce/kevin.stallard_Ubuntu18_Helios-Nucleus-Development_9171/BraceTest/BraceTest.cpp:23:102:
internal compiler error: in build_vec_init_elt, at cp/tree.c:665

In the following code:
#include 
#include 
#include 

class BraceTest
{
public:
BraceTest();

struct BraceTestArrayEntries
{
const char *name;
std::function action;
};

void RunAction( const char *actionName );
void Foo( const char *data );

int _some_data=0;
BraceTestArrayEntries   _entries[];
};

BraceTest::BraceTest() : _entries { {"FirstAction", [this]( const char *data)
{this->Foo( data );} } }
{

}

void BraceTest::RunAction( const char *actionName )
{

}

void BraceTest::Foo( const char *data )
{

}


int main(int argc, char *argv[]) {
std::cout << "Welcome to the Momentics IDE" << std::endl;

BraceTest   bt;
bt.RunAction("FirstAction");

return EXIT_SUCCESS;
}

[Bug libstdc++/95592] Collision with struct _Cosh when Cross compiling libstdc++

[kevin at arilabs dot net]

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

--- Comment #2 from Kevin Stallard  ---
Please forgive the fat fingers.

gcc 7.5.0 on Ubuntu 18.04.4 is the host used to build the cross compiler.

(In reply to Kevin Stallard from comment #1)
> I should also add that this was build with gcc 7.5.0 on Ubuntu

[Bug libstdc++/95592] Collision with struct _Cosh when Cross compiling libstdc++

[kevin at arilabs dot net]

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

Kevin Stallard  changed:

   What|Removed |Added

   Host|Ubuntu 20.04|Ubuntu 18.04.4

--- Comment #1 from Kevin Stallard  ---
I should also add that this was build with gcc 7.5.0 on Ubuntu

[Bug libstdc++/95592] New: Collision with struct _Cosh when Cross compiling libstdc++

[kevin at arilabs dot net]

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

Bug ID: 95592
   Summary: Collision with struct _Cosh when Cross compiling
libstdc++
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kevin at arilabs dot net
  Target Milestone: ---

I am cross compiling gcc 8.3.0 for QNX 6.6. While doing so,
libstdc++-v3/include/bits/valarray_after.h was having trouble with "struct
_Cosh" defined in valarray_before.h because it was colliding with the function
_Cosh() is defined in one of the target OS's headers.

Specifically it was having trouble with (around line 445 of valarray_after.h):

   _DEFINE_EXPR_UNARY_FUNCTION(cosh, _Cosh)

The compiler was using the function declaration of _Cosh instead of struct
_Cosh.

There were other _DEFINE_EXPR_UNARY_FUNCTION that had the same issue (I don't
remember which ones as I focused on _Cosh). 

Below is a patch to valarray_after.h that fixes the issue.  I'm pretty sure QNX
may be the only target OS with this problem, so I am content if this doesn't
make it in gcc, but thought that perhaps removing ambiguity from the preceding
template definitions wouldn't be bad.

I took a look at gcc 9 and 10 code base and the issue appears to exist there as
well.

Thanks
Kevin


Index: libstdc++-v3/include/bits/valarray_after.h
===
--- libstdc++-v3/include/bits/valarray_after.h  (revision 1469)
+++ libstdc++-v3/include/bits/valarray_after.h  (working copy)
@@ -422,20 +422,20 @@

 #define _DEFINE_EXPR_UNARY_FUNCTION(_Name, _UName)   \
   template   \
-inline _Expr<_UnClos<_UName, _Expr, _Dom>,   \
+inline _Expr<_UnClos, 
 \
  typename _Dom::value_type>  \
 _Name(const _Expr<_Dom, typename _Dom::value_type>& __e) \
 {\
   typedef typename _Dom::value_type _Tp; \
-  typedef _UnClos<_UName, _Expr, _Dom> _Closure; \
+  typedef _UnClos _Closure;   
 \
   return _Expr<_Closure, _Tp>(_Closure(__e()));  \
 }\
  \
   template \
-inline _Expr<_UnClos<_UName, _ValArray, _Tp>, _Tp>   \
+inline _Expr<_UnClos, _Tp> 
 \
 _Name(const valarray<_Tp>& __v)  \
 {\
-  typedef _UnClos<_UName, _ValArray, _Tp> _Closure;  \
+  typedef _UnClos _Closure;
 \
   return _Expr<_Closure, _Tp>(_Closure(__v));\
 }