Hi Luke,


Luke Kenneth Casson Leighton wrote:

just to confirm: that's definitely "setting machine to capabilities
that the machine doesn't have, then requesting that feature and gcc 10
says 'ok'" yes?

i do not know the exact machine, let us assume it is -mg3.

the options being passed are "gcc -mg3 -maltivec" and this should
definitely cause gcc to raise an error, is that correct?

that is what the current test written by Adrian does, but I don't think
it is the best solution.

Whould we really get an error? In the case of the g3 I don't think so,
strictly speaking.

I did test
-mcpu=750 -mtune=750 -maltivec

And I do not get an error. However, CPUs with a 750 core and altivec do
exist, even if they were not officially mounted in Mac, they were used elsewhere and perhaps upgrade boards exist (PPC 750 VX).
I might test with cores that impossibly can have AltiVec, like G2 cores

So I think the safest bet still would be a hard switch to enable/disable AltiVec builds.

Riccardo

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Saturday, March 6, 2021, Riccardo Mottola <riccardo.mottola@libero.it> wrote:

Hi Luke,

Luke Kenneth Casson Leighton wrote:

just to confirm: that's definitely "setting machine to capabilities that

the machine doesn't have, then requesting that feature and gcc 10 says
'ok'" yes?

i do not know the exact machine, let us assume it is -mg3.

the options being passed are "gcc -mg3 -maltivec" and this should

definitely cause gcc to raise an error, is that correct?

that is what the current test written by Adrian does, but I don't think

it is the best solution.

right. ok. so by "autoconf" test i meant creating an actual program (even
if it is a one line assembly file) and executing it.

of course that relies on native building which in debian is the default,
but, argh i just realised that "native build host" in this case will be an
IBM POWER9 system which is effectively a cross compile scenario (similar to using aarch64 to build armhf). unless the Program Compatibility Register is
set and that... wouldn't work either

argh! :)

So I think the safest bet still would be a hard switch to enable/disable

AltiVec builds.

yes i concur, i would however still consider this to be a bug in gcc (apart from the 750 with/without altivec) if gcc is not excluding combinations for which there is no known hardware.

sigh why on earth this was not placed behind dynamic runtime libraries a
long time ago, i do not fully understand.

l.


--
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

<br><br>On Saturday, March 6, 2021, Riccardo Mottola &lt;<a href="mailto:riccardo.mottola@libero.it">riccardo.mottola@libero.it</a>&gt; wrote:<br>&gt; Hi Luke,<br>&gt;<br>&gt;<br>&gt; Luke Kenneth Casson Leighton wrote:<br>&gt;&gt;<br>&gt;&gt; just to
confirm: that&#39;s definitely &quot;setting machine to capabilities that the machine doesn&#39;t have, then requesting that feature and gcc 10 says &#39;ok&#39;&quot; yes?<br>&gt;&gt;<br>&gt;&gt; i do not know the exact machine, let us assume it is -mg3.
<br>&gt;&gt;<br>&gt;&gt; the options being passed are &quot;gcc -mg3 -maltivec&quot; and this should definitely cause gcc to raise an error, is that correct?<br>&gt;<br>&gt; that is what the current test written by Adrian does, but I don&#39;t think it
is the best solution.<br><br>right.  ok.  so by &quot;autoconf&quot; test i meant creating an actual program (even if it is a one line assembly file) and executing it.<br><br>o