Thank you for taking care of this! As I see now the hexagon build bot is
happy and the other bots too.
Thanks again,
Gábor
On Sat, 2 Feb 2019, 09:34 David Green Sounds good to me, easy enough for me to test here. And I'll count that as
> a review.
>
>
> I've given it a try in rC352956. We can se
Sounds good to me, easy enough for me to test here. And I'll count that as a
review.
I've given it a try in rC352956. We can see how that bot feels about it.
Dave
> Dave,
>
> The idea to check explicitly the triple inside the test function is quite
> convincing. Will you try to fix it that w
Dave,
The idea to check explicitly the triple inside the test function is quite
convincing. Will you try to fix it that way? Or if it can wait a bit, this
will be my first thing to do on Monday.
Gábor
On Fri, 1 Feb 2019, 19:39 David Green Hello
>
>
> I think, because this is a unit-test, the co
Hello
I think, because this is a unit-test, the compile will happen for the host
(x86_64 in this case). So the binary will still be x86_64.
The compile that the test runs will pick up whatever the default target triple
is (hexagon for the bot, aarch64 for us). I don't know a lot about these t
Hi,
Thank you for catching this. I thought that the macros like __x86_64__ are
defined for the target. I just don't understand: If they are defined for
the host, that would mean we can't cross compile on the same host for
different targets, wouldn't it?
I couldn't find out which macros to use to
Hello
Sorry for the late reply. I'm not sure this ifdef is quite correct. It will be
testing the _host_ architecture, presuming the default target is the same. If
they are different (for example if the default target is aarch64 on an x86
machine), the test will presumably still fail.
I went lo
