On Saturday, March 6, 2021, Riccardo Mottola <riccardo.mott...@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
