assertion failed: lower_constant (Internal Compiler Error?)

[Ian_Mallett1]

Hi,

I am getting the following error:
error : assertion failed: lower_constant: bad kind (shared/cfe/edgcpfe/lower_il.c, line 5639)

From previous threads, I assume this is an internal compiler error. The line in question is a copy constructor:
_MatrixData(_MatrixData<type_numeric,3,1> const& other) : data(other.data) {}

This should be valid C++ code (modulo possibly the underscore+capital). It would be very difficult to try to pull out a minimal example. If you really need it, can you at least tell me what to look for?

Thanks,
Ian

[KitturGanesh]

Hi Ian,
Yes, this is an internal error and is of course a bug in the compiler. Since you mention you cannot attach a reproducer, let me check with the front-end team if they have any clue and I'll get back to you. Appreciate your patience till then.

Kittur

[Ian_Mallett1]

Hmmm. It seems to be related to initialization. In the data section of the class, I have:

union {
    struct {
        type_numeric data_raw[3*1];
        type_numeric _dummy = std::numeric_limits<type_numeric>::quiet_NaN();
    };
    TypeDataMatrixVec data;
};

Removing the assignment to NaN fixes the problem. Also, with the assignment, it appears to delete the default constructor.

[KitturGanesh]

Hi Ian,
The  internal error per-se is a more generic error message and could happen due to a number of causes. But, since you've narrowed down to the assignment issue with NaN it will help the front-end team and will let you know. Otherwise, they may request a preprocessed file (compile with -P to generate a .I file) or such to reproduce the issue. I'll update you soon.

Thanks,
Kittur

[KitturGanesh]

Ian, tried creating an example from what you indicate but couldn't reproduce. Without knowing what exactly type_numeric class looks like or TypeDataMatricVec  looks like, it's hard to create  a test case that can reproduce the behavior. Can you attach a reproducer (a preprocessed file with -P option that generates a .i file) to help reproduce the issue? If not, it's not possible to file the issue with the developers :-(

Thanks,
Kittur

[Ian_Mallett1]

Hmmm, well the first thing I tried failed. It doesn't really make sense as code, but it exhibits the problem anyway.

template <typename type_numeric,int rows,int cols> class _MatrixData {
	public:
		typedef _MatrixData<type_numeric,3,1> TypeDataMatrix;
		typedef _MatrixData<type_numeric,1,3> TypeDataMatrixT;

		union {
			struct {
				type_numeric data_raw[3*1];
				type_numeric _dummy=std::numeric_limits<type_numeric>::quiet_NaN();
			};
		};

	public:
		inline _MatrixData(void) {}
		inline ~_MatrixData(void) = default;
};

int main(void) {
	_MatrixData<float,4,4> mat;
	return 0;
}

[KitturGanesh]

Great, thanks Ian! Yes I could reproduce the internal error with your code snippet, appreciate much. I'll file the issue with the developers accordingly now, thanks

Kittur

[KitturGanesh]

Ian, MS compiler also doesn't allow this. Anyways, the obvious workaround for now till the issue is fixed (so that both Microsoft and Intel will compile it) is to not make the struct anonymous, i.e. give it a name.

% cl -c m.cpp
Microsoft (R) C/C++ Optimizing Compiler Version 19.00.23026 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

m.cpp
m.cpp(10): error C2926: '_MatrixData<float,4,4>::<unnamed-tag>::_dummy': an in-c
lass initializer is not allowed for a member of an anonymous struct within a uni
on
m.cpp(18): note: see reference to class template instantiation '_MatrixData<floa
t,4,4>' being compiled
!%

The obvious workaround (so that both Microsoft and Intel will compile it) is to not make the struct anonymous, i.e. give it a name.
Look at #ifdef OK below:

#ifdef OK
            struct S {
#else
            struct {
#endif

regards
Kittur
 

[Ian_Mallett1]

I think whether or not it is allowed has to do with the standard being used. In this case, I'm using C++14.

It turns out I didn't actually want to do the thing that led to this bug being reported, so it's not really an issue for me anymore.

[KitturGanesh]

Got it, thanks for letting me know. Nevertheless it's a bug in the compiler and I'll  keep you updated as soon as the release with the fix is out. Appreciate your help/code snippets which helped me file the issue as well, thx

Kittur

[Ian_Mallett1]

No problem; glad to help improve the compiler.

Sidenote: should I be submitting these bug reports here, as I have been doing? I didn't see anywhere else, so . . .

[KitturGanesh]

Thanks Ian. Well, forums is one of the modes of support where the community also can respond and resolve issues. But, if you want to directly communicate via a dedicated support engineer and be able to attach secure information/files etc., submitting issues via https://premier.intel.com against the product is the best way as well. Again thanks for your help in improving the product - much appreciated.

Kittur

[Ian_Mallett1]

That link immediately redirects me to https://ssso.intel.com/noaccess/noaccess.htm

I'll just keep posting on the forums.

[KitturGanesh]

Ian, if you have a product registered you should automatically have access to Intel Premier Support. BTW, the link is https://premier.intel.com  I think I'd left out s in https which I corrected now.  Try this link which should take you to the login page of Intel Premier Support.

Thanks,
Kittur

[KitturGanesh]

Hi Ian,
The product team is already working on a fix for this issue (good catch). The obvious workaround (so that both Microsoft and Intel will compile it) is to not make the struct anonymous, i.e. give it a name.

Look at #ifdef OK below:
#ifdef OK
 struct S {
#else
 struct {
#endif

Thanks much, and I'll let you know as soon as the release with the fix is out. Appreciate your patience till then.

Regards,
Kittur