Bug 72076 - cmath: illegal instruction (constexpr)
Summary: cmath: illegal instruction (constexpr)
Status: RESOLVED INVALID
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 6.1.1
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-07-25 21:16 UTC by Thorsten Hirsch
Modified: 2016-08-09 23:03 UTC (History)
0 users

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2016-07-25 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Thorsten Hirsch 2016-07-25 21:16:52 UTC
Please have a look at line 1468 of /usr/include/c++/6.1.1/cmath:

  template<typename _Tp>
    constexpr
    typename __gnu_cxx::__enable_if<__is_integer<_Tp>::__value,
                                    int>::__type
    ilogb(_Tp __x)
    { return __builtin_ilogb(__x); }

The line with a lonely constexpr is causing an "illegal instruction" error when compiling lib32-llvm-svn on ArchLinux. After joining this line with the one that follows the problem is fixed. So here's what works:

  template<typename _Tp>
    constexpr typename __gnu_cxx::__enable_if<__is_integer<_Tp>::__value,
                                    int>::__type
    ilogb(_Tp __x)
    { return __builtin_ilogb(__x); }
Comment 1 Andrew Pinski 2016-07-25 21:19:31 UTC
I suspect this is due to libGMP is not being compiled for the processor you are currently using.
Comment 2 Thorsten Hirsch 2016-07-25 21:56:38 UTC
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
Comment 3 Andrew Pinski 2016-08-06 05:37:18 UTC
(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.
Comment 4 Thorsten Hirsch 2016-08-09 21:08:42 UTC
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-bugzilla@gcc.gnu.org>:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72076
>
> --- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
> (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.
Comment 5 Andrew Pinski 2016-08-09 21:21:36 UTC
(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.
Comment 6 Thorsten Hirsch 2016-08-09 21:27:30 UTC
One by one. :)
I mean this snippet:

  template<typename _Tp>

    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?
Comment 7 Andrew Pinski 2016-08-09 21:33:21 UTC
(In reply to Thorsten Hirsch from comment #6)
> One by one. :)
> I mean this snippet:
> 
>   template<typename _Tp>
> 
>     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?
Comment 8 Andrew Pinski 2016-08-09 21:35:12 UTC
Also white spaces are still white spaces so joining lines should not make a different.
Comment 9 Thorsten Hirsch 2016-08-09 23:03:21 UTC
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.