atlas fails on 10.6.8 Rosetta: error: invalid parameter combination for AltiVec intrinsic

[barracuda156]

ATL_zupMBmm0_4_0_b0.c:89:21: error: expected ';' before 'double'
   89 | static inline vector TYPE vec_mergeh(vector TYPE a, vector TYPE b)
      |                     ^
      |                     ;
ATL_zupMBmm0_4_0_b0.c:133:13: error: 'vector' undeclared (first use in this function)
  133 |             vector TYPE vt00, vt10, vt20, vt30, vt40, vt50, vt60, vt70;
      |             ^~~~~~
[...]
ATL_zupMBmm0_4_0_b0.c:138:19: error: expected ';' before 'double'
  138 |             vector TYPE vzero = (vector TYPE){ 0.0, 0.0 };
      |                   ^
      |                   ;
[...]
ATL_zupMBmm0_4_0_b0.c:215:33: error: 'va0' undeclared (first use in this function); did you mean 'pa0'?
  215 |                 vt00 = vec_madd(va0, vb0, vt00);
      |                                 ^~~
      |                                 pa0
[...]
ATL_zupMBmm0_4_0_b0.c:280:24: warning: implicit declaration of function 'vec_mergeh'; did you mean 'vec_mergee'? [-Wimplicit-function-declaration]
  280 |                 vt0h = vec_mergeh(vt00, vt10);
      |                        ^~~~~~~~~~
      |                        vec_mergee
[...]
ATL_zupMBmm0_4_0_b0.c:281:24: warning: implicit declaration of function 'vec_mergel'; did you mean 'vec_mergee'? [-Wimplicit-function-declaration]
  281 |                 vt0l = vec_mergel(vt00, vt10);
      |                        ^~~~~~~~~~
      |                        vec_mergee
[...]
ATL_zupMBmm0_4_0_b0.c:330:17: error: invalid parameter combination for AltiVec intrinsic '__builtin_vec_extract'
  330 |                 *(pc0+0)  = vec_extract(vt0h,0);
      |                 ^
[...]
make[7]: *** [ATL_zupMBmm0_4_0_b0.o] Error 1

[mascguy (Christopher Nielsen)]

Simplified description to the set of unique identifiers in the log.

[Veence (Vincent)]

Don’t even try to use Atlas on M1. The package hasn't been updated for ages, it doesn’t know anything about M1 architecture.

[barracuda156]

Replying to Veence:

Don’t even try to use Atlas on M1. The package hasn't been updated for ages, it doesn’t know anything about M1 architecture.

This is on Intel (Ivy Bridge) in 10.6.8 Rosetta, build for ppc arch.

[Veence (Vincent)]

That could work, but you can’t do any cross-compiling with Atlas, because for each matrix function to be included in the library, the building code compiles a set of candidates and compares their performance, selecting the best one. If you cross-compile and use Rosetta, that process makes no sense any more, and you end up with a random and possibly defective library.

[barracuda156]

Replying to Veence:

That could work, but you can’t do any cross-compiling with Atlas, because for each matrix function to be included in the library, the building code compiles a set of candidates and compares their performance, selecting the best one. If you cross-compile and use Rosetta, that process makes no sense any more, and you end up with a random and possibly defective library.

Got it, thank you. Can it be built without cpu-specific optimizations though? (It may not have a huge benefit, of course, but just in principle.)

[Veence (Vincent)]

I suppose in principle you can. But it once again makes no sens, since Atlas's purpose is precisely to pack the most optimised code. If you need BLAS/LAPACK API without any aggressive optimisation, I think you'd rather turn to OpenBLAS instead of ATLAS. I said I was going to remove Atlas from Macports's tree, didn't do it so far, but it’s still a goal in the mid-term.

[barracuda156]

Replying to Veence:

I suppose in principle you can. But it once again makes no sens, since Atlas's purpose is precisely to pack the most optimised code. If you need BLAS/LAPACK API without any aggressive optimisation, I think you'd rather turn to OpenBLAS instead of ATLAS. I said I was going to remove Atlas from Macports's tree, didn't do it so far, but it’s still a goal in the mid-term.

Thanks, I won't try on Rosetta then.

I am checking now native build on PPC, and gcc10 does not recognize -V argument which Portfile specifies for PPC. Is it something essential? (I don't want to build gcc5 just for one port.)

[Veence (Vincent)]

I suppose yes, you can get rid of the -V option. Don’t hesitate to tinker with the Portfile until you find a combination of options that works.

[barracuda156]

Replying to Veence:

I suppose yes, you can get rid of the -V option. Don’t hesitate to tinker with the Portfile until you find a combination of options that works.

Thanks, I will try. I got much further on 10.6 PPC (optimizing for powerpc970) using macports-gcc-4.9, but it eventually still failed erroring on -V flag.

By the way, I have updated atlas to the latest version @3.10.3 but not sure which version of lapack I rather use. I have currently tried @3.7.1 (up from @3.6.0), but the latest is @3.10.1, which actually does build on its own with no tweaks.