[Bug middle-end/72076] cmath: illegal instruction (constexpr)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72076 Thorsten Hirsch changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #9 from Thorsten Hirsch --- I cannot reproduce the error anymore. 2 weeks ago I made sure that I can reproduce it before opening this bug report, but now compiling runs successfully no matter whether the constexpr line is joined with the next one or not. Sorry to steal your time, Andrew.
[Bug middle-end/72076] cmath: illegal instruction (constexpr)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72076 --- Comment #8 from Andrew Pinski --- Also white spaces are still white spaces so joining lines should not make a different.
[Bug middle-end/72076] cmath: illegal instruction (constexpr)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72076
--- Comment #7 from Andrew Pinski ---
(In reply to Thorsten Hirsch from comment #6)
> One by one. :)
> I mean this snippet:
>
> template
>
> constexpr
>
> typename __gnu_cxx::__enable_if<__is_integer<_Tp>::__value,
>
> int>::__type
>
> ilogb(_Tp __x)
>
> { return __builtin_ilogb(__x); }
>
>
> Is this valid? Or should there be an "int" or "float" after the "constexpr"
> in line 2?
typename __gnu_cxx::__enable_if<__is_integer<_Tp>::__value,
int>::__type
is a type, it is either SFINAE or is int. Basically the template is rejected
as a substitution failure and not considered or is the type is an int.
This is standard C++98ism. One which is confusing but used so you can do
overloads which are not considered part of the overload class.
See https://en.wikipedia.org/wiki/Substitution_failure_is_not_an_error for more
information on that.
Again do you have a preprocessed source for the failure you are seeing and what
is the full error message?
[Bug middle-end/72076] cmath: illegal instruction (constexpr)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72076
--- Comment #6 from Thorsten Hirsch ---
One by one. :)
I mean this snippet:
template
constexpr
typename __gnu_cxx::__enable_if<__is_integer<_Tp>::__value,
int>::__type
ilogb(_Tp __x)
{ return __builtin_ilogb(__x); }
Is this valid? Or should there be an "int" or "float" after the "constexpr"
in line 2?
[Bug middle-end/72076] cmath: illegal instruction (constexpr)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72076 --- Comment #5 from Andrew Pinski --- (In reply to Thorsten Hirsch from comment #4) > Sorry, you lost me - does my GMP installation cause the compilation error > (illegal instruction) or does it cause the lonely constexpr without a type > in the cmath header? Huh? Without a type, what do you mean by that? Do you mean without a typename? Do you have a preprocessed source which causes the failure then? Also the internal compiler error from gcc or clang? If clang, you should report it to them also.
[Bug middle-end/72076] cmath: illegal instruction (constexpr)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72076 --- Comment #4 from Thorsten Hirsch --- Sorry, you lost me - does my GMP installation cause the compilation error (illegal instruction) or does it cause the lonely constexpr without a type in the cmath header? In other words: is the lonely constexpr a bug at all? I've checked the cmath header in Ubuntu 16.04 (/usr/include/c++/5/cmath) and it also contains this constexpr without a type at more or less the same position (line 1459 to be precise). 2016-08-06 7:37 GMT+02:00 pinskia at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org>: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72076 > > --- Comment #3 from Andrew Pinski --- > (In reply to Thorsten Hirsch from comment #2) > > In that case it might be a problem of Arch's multilib, which is their > way of > > allowing 32bit compilations on x64, see [1] and [2]. So my gcc package is > > called gcc-multilib, which includes (depends on) the 32bit package of > glibc, > > thus I've installed packages for both architectures. And I have 2 gmp > > packages: > > > > $ pacman -Q | grep -i gmp > > gmp 6.1.1-1 > > lib32-gmp 6.1.0-2 > > > > (I just checked if there's version 6.1.1 for 32bit, but it's not > available, > > yet.) > > > No the problem is GMP is compiled say skylake but used on boardwell. > > -- > You are receiving this mail because: > You reported the bug.
[Bug middle-end/72076] cmath: illegal instruction (constexpr)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72076 --- Comment #3 from Andrew Pinski --- (In reply to Thorsten Hirsch from comment #2) > In that case it might be a problem of Arch's multilib, which is their way of > allowing 32bit compilations on x64, see [1] and [2]. So my gcc package is > called gcc-multilib, which includes (depends on) the 32bit package of glibc, > thus I've installed packages for both architectures. And I have 2 gmp > packages: > > $ pacman -Q | grep -i gmp > gmp 6.1.1-1 > lib32-gmp 6.1.0-2 > > (I just checked if there's version 6.1.1 for 32bit, but it's not available, > yet.) No the problem is GMP is compiled say skylake but used on boardwell.
[Bug middle-end/72076] cmath: illegal instruction (constexpr)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72076 --- Comment #2 from Thorsten Hirsch --- In that case it might be a problem of Arch's multilib, which is their way of allowing 32bit compilations on x64, see [1] and [2]. So my gcc package is called gcc-multilib, which includes (depends on) the 32bit package of glibc, thus I've installed packages for both architectures. And I have 2 gmp packages: $ pacman -Q | grep -i gmp gmp 6.1.1-1 lib32-gmp 6.1.0-2 (I just checked if there's version 6.1.1 for 32bit, but it's not available, yet.) So... should I open a bug for gcc-multilib? Can you give me a hint about what I should tell the package maintainer of gcc-multilib? [1] https://www.archlinux.org/packages/multilib/x86_64/gcc-multilib [2] https://wiki.archlinux.org/index.php/Multilib
[Bug middle-end/72076] cmath: illegal instruction (constexpr)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72076 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2016-07-25 Component|libstdc++ |middle-end Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- I suspect this is due to libGMP is not being compiled for the processor you are currently using.
