[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.


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

Reply to: