Re: enabling/disabling AltiVec in Firefox and derived browsers (ArcticFox)
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
Reply to: