BTW, forgot to link this, but you can see the full list of OpenBLAS targets
here: https://github.com/xianyi/OpenBLAS/blob/develop/TargetList.txt
This shows the reason why ATOM isn't the default choice. It would be bad if
OpenBLAS picked that and you were actually running an AMD cpu, or if you
I'm pretty sure that's an issue for upstream, not the Sage devs, maybe we
should ask the OpenBLAS devs? But I suspect that the problem here is that
there isn't a default choice that covers all CPU types. Atom is a catch-all
for many low-end X86_64 cpus (like my Celeron), but it's not the best
I just had the same problem with a new computer (Kaby Lake processor,
apparently). Can we patch OpenBLAS to fall back to ATOM if it's x86_64 but
can't detect the precise CPU? (I can't do this, but maybe someone else can.)
John
On Friday, July 14, 2017 at 12:25:57 AM UTC-7, Dima Pasechnik
And here, too: may I ask again for a review of this ticket?
Does anyone has an opinion on the discussion, where to fix the memory leak?
Should I provide more info in this posts here, or is the discussion
supposed to take place in the comments of the tickets?
Am Mittwoch, 7. Juni 2017 10:55:21
May I ask again for someone to review this ticket? Roed offere to do so,
but I'm not sure what the "official" way to ask for this reviews again, is.
Am Mittwoch, 7. Juni 2017 14:58:43 UTC+2 schrieb Friedrich Wiemer:
>
> Hi
>
> Does someone has time to review my work on #22988?
>
Le 19/07/2017 à 22:32, François Bissey a écrit :
One thing that I don’t remember seeing
anywhere before and that I find suspicious “-fabi-version=6” in CFLAGS.
For the record, this -fabi-version=6 option is forced by givaro (a dependency of LinBox) to avoid a
demangling bug with the standard
