10 a.m.
Hello,
I just imported lugaru and attempted to build it for rawhide, but it
failed in such a strange way on ppc64le, with errors saying it can't
convert bool to vectorized ints.
Full build log:
https://kojipkgs.fedoraproject.org//work/tasks/9921/16959921/build.log
I fully expected lugaru to build properly on all architectures, as it
has nothing that makes it special in this regard. What's going on
here? Can someone help fix this?
--
真実はいつも一つ！/ Always, there's only one truth!
10:12 a.m.
New subject: ppc64le build failure (error converting bool to vector int?) with
lugaru
On 12/19/2016 05:00 PM, Neal Gompa wrote:
Hello,
I just imported lugaru and attempted to build it for rawhide, but it
failed in such a strange way on ppc64le, with errors saying it can't
convert bool to vectorized ints.
Full build log:
https://kojipkgs.fedoraproject.org//work/tasks/9921/16959921/build.log
I fully expected lugaru to build properly on all architectures, as it
has nothing that makes it special in this regard. What's going on
here?
bool is a very special type on POWER because it's four bytes and not
just one byte, as on most other architectures. Related to this, the
compiler supplies a type __bool, and what I suspect is happening is that
a header included by the project contains
#define bool __bool
The most common source is <altivec.h> from GCC.
If you can't trace this locally, you can perhaps compile with
-D__altivec_bool_ret='()'
which should give you an error message with an #include stack, so that
you can see where <altivec.h> is included.
Florian
10:27 a.m.
New subject: ppc64le build failure (error converting bool to vector int?)
with lugaru
On Mon, Dec 19, 2016 at 05:12:25PM +0100, Florian Weimer wrote:
On 12/19/2016 05:00 PM, Neal Gompa wrote:
> Hello,
>
> I just imported lugaru and attempted to build it for rawhide, but it
> failed in such a strange way on ppc64le, with errors saying it can't
> convert bool to vectorized ints.
>
> Full build log:
> https://kojipkgs.fedoraproject.org//work/tasks/9921/16959921/build.log
>
> I fully expected lugaru to build properly on all architectures, as it
> has nothing that makes it special in this regard. What's going on
> here?
bool is a very special type on POWER because it's four bytes and not just
one byte, as on most other architectures. Related to this, the compiler
No, only on powerpc*-*-darwin*. On powerpc*-*-linux* it is one byte like
elsewhere.
supplies a type __bool, and what I suspect is happening is that a
header
included by the project contains
#define bool __bool
The most common source is <altivec.h> from GCC.
These days (for several GCC releases), powerpc as well as spu and recently
also s390 (z13) use conditional macros for bool, vector, pixel and _Bool,
which expand differently depending on what is the following token.
But the conditional macros are defined only in the non-strict C/C++ modes,
the above is compiled with -std=c++11 rather than -std=gnu++11, but then
one shouldn't include altivec.h if they want standard behavior.
Alternative is to include altivec.h and
#undef vector
#undef pixel
#undef bool
and then of course you need to use __vector, __pixel and __bool instead of
vector, pixel or bool if you want the Altivec-ish behavior rather than
standard.
Jakub
12:20 p.m.
On Mon, Dec 19, 2016 at 11:27 AM, Jakub Jelinek <jakub(a)redhat.com> wrote:
On Mon, Dec 19, 2016 at 05:12:25PM +0100, Florian Weimer wrote:
> On 12/19/2016 05:00 PM, Neal Gompa wrote:
> > Hello,
> >
> > I just imported lugaru and attempted to build it for rawhide, but it
> > failed in such a strange way on ppc64le, with errors saying it can't
> > convert bool to vectorized ints.
> >
> > Full build log:
> > https://kojipkgs.fedoraproject.org//work/tasks/9921/16959921/build.log
> >
> > I fully expected lugaru to build properly on all architectures, as it
> > has nothing that makes it special in this regard. What's going on
> > here?
>
> bool is a very special type on POWER because it's four bytes and not just
> one byte, as on most other architectures. Related to this, the compiler
No, only on powerpc*-*-darwin*. On powerpc*-*-linux* it is one byte like
elsewhere.
> supplies a type __bool, and what I suspect is happening is that a header
> included by the project contains
>
> #define bool __bool
>
> The most common source is <altivec.h> from GCC.
These days (for several GCC releases), powerpc as well as spu and recently
also s390 (z13) use conditional macros for bool, vector, pixel and _Bool,
which expand differently depending on what is the following token.
But the conditional macros are defined only in the non-strict C/C++ modes,
the above is compiled with -std=c++11 rather than -std=gnu++11, but then
one shouldn't include altivec.h if they want standard behavior.
Alternative is to include altivec.h and
#undef vector
#undef pixel
#undef bool
and then of course you need to use __vector, __pixel and __bool instead of
vector, pixel or bool if you want the Altivec-ish behavior rather than
standard.
We're not including altivec.h, not directly. At least with main.cpp,
it looks like it's being pulled in by our usage of STL, specifically
set. There's also a strange error about vec_cond_expr not supported?
/home/fedora/lugaru-pkg/lugaru-1.1-mods/Source/main.cpp:665:25: error:
could not convert ‘#‘vec_cond_expr’ not supported by
dump_expr#<expression error>’ from ‘__vector(4) int’ to ‘bool’
What am I supposed to do to get rid of these errors?
--
真実はいつも一つ！/ Always, there's only one truth!
12:26 p.m.
New subject: ppc64le build failure (error converting bool to vector int?)
with lugaru
On Mon, Dec 19, 2016 at 01:20:14PM -0500, Neal Gompa wrote:
>> The most common source is <altivec.h> from GCC.
>
> These days (for several GCC releases), powerpc as well as spu and recently
> also s390 (z13) use conditional macros for bool, vector, pixel and _Bool,
> which expand differently depending on what is the following token.
> But the conditional macros are defined only in the non-strict C/C++ modes,
> the above is compiled with -std=c++11 rather than -std=gnu++11, but then
> one shouldn't include altivec.h if they want standard behavior.
> Alternative is to include altivec.h and
> #undef vector
> #undef pixel
> #undef bool
> and then of course you need to use __vector, __pixel and __bool instead of
> vector, pixel or bool if you want the Altivec-ish behavior rather than
> standard.
>
We're not including altivec.h, not directly. At least with main.cpp,
it looks like it's being pulled in by our usage of STL, specifically
set. There's also a strange error about vec_cond_expr not supported?
The STL does not include altivec.h, so it must be something else.
You can use g++ -E -dD ... to see what included it.
/home/fedora/lugaru-pkg/lugaru-1.1-mods/Source/main.cpp:665:25:
error:
could not convert ‘#‘vec_cond_expr’ not supported by
dump_expr#<expression error>’ from ‘__vector(4) int’ to ‘bool’
That is just a consequence of bool meaning something completely different
from what the code expects.
So, first either find out what includes altivec.h and why, either avoid it
or undef the keywords afterwards, or use -std=gnu++11 mode rather than
-std=c++11 to make sure the macros are contextual.
Jakub
12:29 p.m.
On Mon, Dec 19, 2016 at 1:26 PM, Jakub Jelinek <jakub(a)redhat.com> wrote:
On Mon, Dec 19, 2016 at 01:20:14PM -0500, Neal Gompa wrote:
> >> The most common source is <altivec.h> from GCC.
> >
> > These days (for several GCC releases), powerpc as well as spu and recently
> > also s390 (z13) use conditional macros for bool, vector, pixel and _Bool,
> > which expand differently depending on what is the following token.
> > But the conditional macros are defined only in the non-strict C/C++ modes,
> > the above is compiled with -std=c++11 rather than -std=gnu++11, but then
> > one shouldn't include altivec.h if they want standard behavior.
> > Alternative is to include altivec.h and
> > #undef vector
> > #undef pixel
> > #undef bool
> > and then of course you need to use __vector, __pixel and __bool instead of
> > vector, pixel or bool if you want the Altivec-ish behavior rather than
> > standard.
> >
So, first either find out what includes altivec.h and why, either avoid it
or undef the keywords afterwards, or use -std=gnu++11 mode rather than
-std=c++11 to make sure the macros are contextual.
Switching to gnu++11 fixed it. Thanks!
--
真実はいつも一つ！/ Always, there's only one truth!
2711
days inactive
2711
days old
5 comments
3 participants
participants (3)
-
Florian Weimer -
Jakub Jelinek -
Neal Gompa