Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

segfault in dblat2 in dgemv_HASWELL in OpenBLAS 0.3.5 #2009

Closed
susilehtola opened this issue Feb 12, 2019 · 20 comments · Fixed by #2010
Closed

segfault in dblat2 in dgemv_HASWELL in OpenBLAS 0.3.5 #2009

susilehtola opened this issue Feb 12, 2019 · 20 comments · Fixed by #2010
Milestone

Comments

@susilehtola
Copy link
Contributor

Rebuilding OpenBLAS 0.3.5 on Fedora rawhide (to-be Fedora 30) results in a segfault in the tests

OPENBLAS_NUM_THREADS=1 OMP_NUM_THREADS=1 ./dblat2 < ./dblat2.dat
BUILDSTDERR: Program received signal SIGSEGV: Segmentation fault - invalid memory reference.
BUILDSTDERR: Backtrace for this error:
BUILDSTDERR: #0  0x7f21b3836ca1 in ???
BUILDSTDERR: #1  0x7f21b3835e65 in ???
BUILDSTDERR: #2  0x7f21b368717f in ???
BUILDSTDERR: #3  0x5578496125f2 in dgemv_kernel_4x1
BUILDSTDERR: 	at ../kernel/x86_64/dgemv_n_4.c:143
BUILDSTDERR: #4  0x557849612958 in dgemv_n_HASWELL
BUILDSTDERR: 	at ../kernel/x86_64/dgemv_n_4.c:318
BUILDSTDERR: #5  0x5578487bc333 in dgemv_
BUILDSTDERR: 	at /builddir/build/BUILD/openblas-0.3.5/Rblas/interface/gemv.c:231
BUILDSTDERR: #6  0x5578487b6e8e in dchk1_
BUILDSTDERR: 	at /builddir/build/BUILD/openblas-0.3.5/Rblas/test/dblat2.f:582
BUILDSTDERR: #7  0x5578487bbb02 in dblat2
BUILDSTDERR: 	at /builddir/build/BUILD/openblas-0.3.5/Rblas/test/dblat2.f:305
BUILDSTDERR: #8  0x5578487ad052 in main
BUILDSTDERR: 	at /builddir/build/BUILD/openblas-0.3.5/Rblas/test/dblat2.f:390
BUILDSTDERR: /bin/sh: line 1: 20348 Segmentation fault      (core dumped) OPENBLAS_NUM_THREADS=1 OMP_NUM_THREADS=1 ./dblat2 < ./dblat2.dat
BUILDSTDERR: make[1]: *** [Makefile:32: level2] Error 139
BUILDSTDERR: make[1]: *** Waiting for unfinished jobs....
make[1]: Leaving directory '/builddir/build/BUILD/openblas-0.3.5/Rblas/test'
make: Leaving directory '/builddir/build/BUILD/openblas-0.3.5/Rblas'
BUILDSTDERR: make: *** [Makefile:124: tests] Error 2

The compiler is

gcc                     x86_64 9.0.1-0.4.fc30                      build  22 M
gcc-gfortran            x86_64 9.0.1-0.4.fc30                      build  10 M

and the Rblas version of the library is compiled with

make -C Rblas TARGET=CORE2 DYNAMIC_ARCH=1 DYNAMIC_OLDER=1 USE_THREAD=0 USEOPENMP=0 FC=gfortran CC=gcc 'COMMON_OPT=-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fPIC' 'FCOMMON_OPT=-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fPIC -frecursive' NUM_THREADS=128 LIBPREFIX=libRblas LIBSONAME=libRblas.so INTERFACE64=0

Full build log at
https://kojipkgs.fedoraproject.org//work/tasks/5620/32755620/build.log

@martin-frbg martin-frbg added this to the 0.3.6 milestone Feb 12, 2019
@martin-frbg
Copy link
Collaborator

Looks like yet another instance of #1964, input operands being declared as readonly despite getting (ab)used as loop counters in the assembly.

@martin-frbg
Copy link
Collaborator

Original problem should be fixed now, but I suspect a similar issue with the trsm kernels for Bulldozer and the dtrsm_kernel_RN_haswell.c. (Not corrected yet as I wonder about the correct handling of %8 and %9 in the latter, and %6 and %7 in the Bulldozer kernels)

@martin-frbg
Copy link
Collaborator

martin-frbg commented Feb 17, 2019

I believe all bugs of this type should be fixed now (on the develop branch that is planned to become 0.3.6 in about two weeks).

@susilehtola
Copy link
Contributor Author

Awesome. I've pulled in the patches #2010, #2018, #2019, #2021, #2023, and #2024; hopefully 0.3.5 builds now with gcc 9.

@martin-frbg
Copy link
Collaborator

It did in my tests on Kaby Lake (Haswell kernels), I am building the most recent snapshot of gcc9 on Ryzen2700 right now to confirm correct behaviour with -march=znver1 (environment of #2018).

@susilehtola
Copy link
Contributor Author

Built and tested fine at my end.

@opoplawski
Copy link

I think we still have some issues - koschei reports that a number of packages including octave and arpack are now failing on x86_64 with these patches applied:

https://apps.fedoraproject.org/koschei/affected-by/openblas-devel?epoch1=0&version1=0.3.5&release1=1.fc30&epoch2=0&version2=0.3.5&release2=3.fc30&collection=f30

octave:

  liboctave/array/CMatrix.cc-tst .............................. PASS     10/11  
                                                                  FAIL    1
  liboctave/array/CSparse.cc-tst .............................. PASS     10/10  
  liboctave/array/Sparse.cc-tst ............................... PASS    107/107 
BUILDSTDERR:   liboctave/array/dMatrix.cc-tst ..............................fatal: caught signal Segmentation fault -- stopping myself...
BUILDSTDERR: /bin/sh: line 1: 13322 Segmentation fault      (core dumped) /bin/sh ../run-octave --norc --silent --no-history /builddir/build/BUILD/octave-4.4.1/test/fntests.m /builddir/build/BUILD/octave-4.4.1/test

@martin-frbg
Copy link
Collaborator

martin-frbg commented Feb 23, 2019

Are you sure that the failures are actually related to OpenBLAS ? I cannot reproduce the arpack one at least (first on your list). Can you get a backtrace from the octave and/or numpy segfault ?
Edit: Cannot reproduce the Octave test failures either, what was the hardware environment for your fedora builds ?

@martin-frbg martin-frbg reopened this Feb 23, 2019
@QuLogic
Copy link

QuLogic commented Feb 25, 2019

Some hardware info can be found from the hw_info.log in the builds (e.g., this one for octave):

CPU info:
Architecture:        x86_64
CPU op-mode(s):      32-bit, 64-bit
Byte Order:          Little Endian
CPU(s):              6
On-line CPU(s) list: 0-5
Thread(s) per core:  1
Core(s) per socket:  1
Socket(s):           6
NUMA node(s):        1
Vendor ID:           GenuineIntel
CPU family:          6
Model:               60
Model name:          Intel Core Processor (Haswell, no TSX, IBRS)
Stepping:            1
CPU MHz:             2299.998
BogoMIPS:            4599.99
Hypervisor vendor:   KVM
Virtualization type: full
L1d cache:           32K
L1i cache:           32K
L2 cache:            4096K
L3 cache:            16384K
NUMA node0 CPU(s):   0-5
Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx rdtscp lm constant_tsc rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm invpcid_single pti ibrs ibpb fsgsbase bmi1 avx2 smep bmi2 erms invpcid xsaveopt arat

(All of arpack, octave and numpy builds are the same, except for total memory, which I didn't bother copying.)

@QuLogic
Copy link

QuLogic commented Feb 25, 2019

@susilehtola looks like we should backport #2028 as well (not sure if it'll fix everything since it's piledriver, not haswell.)

@martin-frbg
Copy link
Collaborator

My tests were done with Kaby Lake (Haswell) and Ryzen 2700 (Zen, which for the most part is Haswell) so your build failures are likely the result of a change in some other dependency. (Or you are missing some other PR on top of 0.3.5 - #2028 is not going to affect anything as it appears that the file in question is not even used for the AMD Piledriver target itself.)
If you still think that OpenBLAS is to blame, please provide more information - unfortunately there are far too few developers on this project to expect us to trawl through your build logs or install any and all packages just to see if and where they break)

@martin-frbg
Copy link
Collaborator

If you are actually using 0.3.5 with only the patches from 2010 onwards, you are missing #1965 to #1967 (the patches for issue #1964 mentioned above). I believe the other changes since the 0.3.5 release on december 31 are unlikely to have serious impact on Haswell (most do not affect x86_64 at all). 0.3.6 is still planned to be released next weekend - unless serious regressions get reported against the develop branch in the meantime.

@QuLogic
Copy link

QuLogic commented Feb 25, 2019

Unfortunately, the trouble with getting a backtrace is that it's a bit of a heisenbug. I was able to reproduce the same issue from the builder locally, but whenever I installed the debug symbols, it stopped crashing in gdb. Using a different failing package, I was able to get valgrind to point to dscal_k_HASWELL (dscal.c:226).

However, today I've now figured out how to build against openblas master, and it appears this crash is now fixed. I think you are correct that there are simply not enough patches backported (e.g., dscal appears changed by #1966). I will try out the other failing packages with this to see if there are any other real issues.

@martin-frbg
Copy link
Collaborator

Wait - is it master or develop that you built against ? master is stuck at 0.2.20, releases since then have been created from the 0.3.0 branch (which gets updated from develop about every two months)

@QuLogic
Copy link

QuLogic commented Feb 25, 2019

Sorry, I meant develop, specifically, fd34820.

@opoplawski
Copy link

@susilehtola would you be opposed to building the head of develop in Fedora rawhide? That should give some useful testing here I think.

@susilehtola
Copy link
Contributor Author

@opoplawski I've included #1965-#1967 in the latest build. Originally, I just wanted to patch out the stuff that isn't working, since there might be unstable stuff in the develop branch.

If @martin-frbg agrees, I (or @opoplawski) can switch to using the development branch until 0.3.6 is released.

@martin-frbg
Copy link
Collaborator

There is not supposed to be anything unstable in the develop branch right now (except perhaps the AVX512 DGEMM, but that is no recent regression). My not yet merged #2026 poses a small risk as it re-enables a multithreaded codepath that had been disabled in an earlier search for the source of a loss of precision.

@susilehtola
Copy link
Contributor Author

@opoplawski I don't really have time to work on this; you're free to bump openblas to the develop branch.

@opoplawski
Copy link

Looks like octave is building fine now with the latest openblas in Rawhide. I did prepare an updated package with the latest git, but I think I'll hold off on that for now.

TiborGY added a commit to TiborGY/OpenBLAS that referenced this issue Jul 7, 2019
* With the Intel compiler on Linux, prefer ifort for the final link step 

icc has known problems with mixed-language builds that ifort can handle just fine. Fixes OpenMathLib#1956

* Rename operands to put lda on the input/output constraint list

* Fix wrong constraints in inline assembly

for OpenMathLib#2009

* Fix inline assembly constraints

rework indices to allow marking argument lda4 as input and output. For OpenMathLib#2009

* Fix inline assembly constraints

rework indices to allow marking argument lda as input and output.

* Fix inline assembly constraints

* Fix inline assembly constraints

* Fix inline assembly constraints in Bulldozer TRSM kernels

rework indices to allow marking i,as and bs as both input and output (marked operand n1 as well for simplicity). For OpenMathLib#2009

* Correct range_n limiting

same bug as seen in OpenMathLib#1388, somehow missed in corresponding PR OpenMathLib#1389

* Allow multithreading TRMV again

revert workaround introduced for issue OpenMathLib#1332 as the actual cause appears to be my incorrect fix from OpenMathLib#1262 (see OpenMathLib#1388)

* Fix error introduced during cleanup

* Reduce list of kernels in the dynamic arch build

to make compilation complete reliably within the 1h limit again

* init

* move fix to right place

* Fix missing -c option in AVX512 test

* Fix AVX512 test always returning false due to missing compiler option

* Make x86_32 imply NO_AVX2, NO_AVX512 in addition to NO_AVX

fixes OpenMathLib#2033

* Keep xcode8.3 for osx BINARY=32 build

as xcode10 deprecated i386

* Make sure that AVX512 is disabled in 32bit builds

for OpenMathLib#2033

* Improve handling of NO_STATIC and NO_SHARED

to avoid surprises from defining either as zero. Fixes OpenMathLib#2035 by addressing some concerns from OpenMathLib#1422

* init

* address warning introed with OpenMathLib#1814 et al

* Restore locking optimizations for OpenMP case

restore another accidentally dropped part of OpenMathLib#1468 that was missed in OpenMathLib#2004 to address performance regression reported in OpenMathLib#1461

* HiSilicon tsv110 CPUs optimization branch

add HiSilicon tsv110 CPUs  optimization branch

* add TARGET support for  HiSilicon tsv110 CPUs

* add TARGET support for HiSilicon tsv110 CPUs

* add TARGET support for HiSilicon tsv110 CPUs

* Fix module definition conflicts between LAPACK and ReLAPACK

for OpenMathLib#2043

* Do not compile in AVX512 check if AVX support is disabled

xgetbv is function depends on NO_AVX being undefined - we could change that too, but that combo is unlikely to work anyway

* ctest.c : add __POWERPC__ for PowerMac

* Fix crash in sgemm SSE/nano kernel on x86_64

Fix bug OpenMathLib#2047.

Signed-off-by: Celelibi <celelibi@gmail.com>

* param.h : enable defines for PPC970 on DarwinOS

fixes:
gemm.c: In function 'sgemm_':
../common_param.h:981:18: error: 'SGEMM_DEFAULT_P' undeclared (first use in this function)
 #define SGEMM_P  SGEMM_DEFAULT_P
                  ^

* common_power.h: force DCBT_ARG 0 on PPC970 Darwin

without this, we see
../kernel/power/gemv_n.S:427:Parameter syntax error
and many more similar entries

that relates to this assembly command
dcbt 8, r24, r18

this change makes the DCBT_ARG = 0
and openblas builds through to completion on PowerMac 970
Tests pass

* Make TARGET=GENERIC compatible with DYNAMIC_ARCH=1

for issue OpenMathLib#2048

* make DYNAMIC_ARCH=1 package work on TSV110.

* make DYNAMIC_ARCH=1 package work on TSV110

* Add Intel Denverton

for OpenMathLib#2048

* Add Intel Denverton

* Change 64-bit detection as explained in OpenMathLib#2056

* Trivial typo fix

as suggested in OpenMathLib#2022

* Disable the AVX512 DGEMM kernel (again)

Due to as yet unresolved errors seen in OpenMathLib#1955 and OpenMathLib#2029

* Use POSIX getenv on Cygwin

The Windows-native GetEnvironmentVariable cannot be relied on, as
Cygwin does not always copy environment variables set through Cygwin
to the Windows environment block, particularly after fork().

* Fix for OpenMathLib#2063: The DllMain used in Cygwin did not run the thread memory
pool cleanup upon THREAD_DETACH which is needed when compiled with
USE_TLS=1.

* Also call CloseHandle on each thread, as well as on the event so as to not leak thread handles.

* AIX asm syntax changes needed for shared object creation

* power9 makefile. dgemm based on power8 kernel with following changes : 32x unrolled 16x4 kernel and 8x4 kernel using (lxv stxv butterfly rank1 update). improvement from 17 to 22-23gflops. dtrmm cases were added into dgemm itself

* Expose CBLAS interfaces for I?MIN and I?MAX

* Build CBLAS interfaces for I?MIN and I?MAX

* Add declarations for ?sum and cblas_?sum

* Add interface for ?sum (derived from ?asum)

* Add ?sum

* Add implementations of ssum/dsum and csum/zsum

as trivial copies of asum/zsasum with the fabs calls replaced by fmov to preserve code structure

* Add ARM implementations of ?sum

(trivial copies of the respective ?asum with the fabs calls removed)

* Add ARM64 implementations of ?sum

as trivial copies of the respective ?asum kernels with the fabs calls removed

* Add ia64 implementation of ?sum

as trivial copy of asum with the fabs calls removed

* Add MIPS implementation of ?sum

as trivial copy of ?asum with the fabs calls removed

* Add MIPS64 implementation of ?sum

as trivial copy of ?asum with the fabs replaced by mov to preserve code structure

* Add POWER implementation of ?sum

as trivial copy of ?asum with the fabs replaced by fmr to preserve code structure

* Add SPARC implementation of ?sum

as trivial copy of ?asum with the fabs replaced by fmov to preserve code structure

* Add x86 implementation of ?sum

as trivial copy of ?asum with the fabs calls removed

* Add x86_64 implementation of ?sum

as trivial copy of ?asum with the fabs calls removed

* Add ZARCH implementation of ?sum

as trivial copies of the respective ?asum kernels with the ABS and vflpsb calls removed

* Detect 32bit environment on 64bit ARM hardware

for OpenMathLib#2056, using same approach as OpenMathLib#2058

* Add cmake defaults for ?sum kernels

* Add ?sum

* Add ?sum definitions for generic kernel

* Add declarations for ?sum

* Add -lm and disable EXPRECISION support on *BSD

fixes OpenMathLib#2075

* Add in runtime CPU detection for POWER.

* snprintf define consolidated to common.h

* Support INTERFACE64=1

* Add support for INTERFACE64 and fix XERBLA calls

1. Replaced all instances of "int" with "blasint"
2. Added string length as "hidden" third parameter in calls to fortran XERBLA

* Correct length of name string in xerbla call

* Avoid out-of-bounds accesses in LAPACK EIG tests

see Reference-LAPACK/lapack#333

* Correct INFO=4 condition

* Disable reallocation of work array in xSYTRF

as it appears to cause memory management problems (seen in the LAPACK tests)

* Disable repeated recursion on Ab_BR in ReLAPACK xGBTRF

due to crashes in LAPACK tests

* sgemm/strmm

* Update Changelog with changes from 0.3.6

* Increment version to 0.3.7.dev

* Increment version to 0.3.7.dev

* Misc. typo fixes

Found via `codespell -q 3 -w -L ith,als,dum,nd,amin,nto,wis,ba -S ./relapack,./kernel,./lapack-netlib`

* Correct argument of CPU_ISSET for glibc <2.5

fixes OpenMathLib#2104

* conflict resolve

* Revert reference/ fixes

* Revert Changelog.txt typos

* Disable the SkyLakeX DGEMMITCOPY kernel as well

as a stopgap measure for numpy/numpy#13401 as mentioned in OpenMathLib#1955

* Disable DGEMMINCOPY as well for now

OpenMathLib#1955

* init

* Fix errors in cpu enumeration with glibc 2.6

for OpenMathLib#2114

* Change two http links to https

Closes OpenMathLib#2109

* remove redundant code OpenMathLib#2113

* Set up CI with Azure Pipelines

[skip ci]

* TST: add native POWER8 to CI

* add native POWER8 testing to
Travis CI matrix with ppc64le
os entry

* Update link to IBM MASS library, update cpu support status

* first try migrating one of the arm builds from travis

* fix tabbing in azure commands

* Update azure-pipelines.yml

take out offending lines (although stolen from https://github.com/conda-forge/opencv-feedstock azure-pipelines fiie)

* Update azure-pipelines.yml

* Update azure-pipelines.yml

* Update azure-pipelines.yml

* Update azure-pipelines.yml

* DOC: Add Azure CI status badge

* Add ARMV6 build to azure CI setup (OpenMathLib#2122)

using aytekinar's Alpine image and docker script from the Travis setup

[skip ci]

* TST: Azure manylinux1 & clean-up

* remove some of the steps & comments
from the original Azure yml template

* modify the trigger section to use
develop since OpenBLAS primarily uses
this branch; use the same batching
behavior as downstream projects NumPy/
SciPy

* remove Travis emulated ARMv6 gcc build
because this now happens in Azure

* use documented Ubuntu vmImage name for Azure
and add in a manylinux1 test run to the matrix

[skip appveyor]

* Add NO_AFFINITY to available options on Linux, and set it to ON

to match the gmake default. Fixes second part of OpenMathLib#2114

* Replace ISMIN and ISAMIN kernels on all x86_64 platforms (OpenMathLib#2125)

* Mark iamax_sse.S as unsuitable for MIN due to issue OpenMathLib#2116
* Use iamax.S rather than iamax_sse.S for ISMIN/ISAMIN on all x86_64 as workaround for OpenMathLib#2116

* Move ARMv8 gcc build from Travis to Azure

* Move ARMv8 gcc build from Travis to Azure

* Update .travis.yml

* Test drone CI

* install make

* remove sudo

* Install gcc

* Install perl

* Install gfortran and add a clang job

* gfortran->gcc-gfortran

* Switch to ubuntu and parallel jobs

* apt update

* Fix typo

* update yes

* no need of gcc in clang build

* Add a cmake build as well

* Add cmake builds and print options

* build without lapack on cmake

* parallel build

* See if ubuntu 19.04 fixes the ICE

* Remove qemu armv8 builds

* arm32 build

* Fix typo

* TST: add SkylakeX AVX512 CI test

* adapt the C-level reproducer code for some
recent SkylakeX AVX512 kernel issues, provided
by Isuru Fernando and modified by Martin Kroeker,
for usage in the utest suite

* add an Intel SDE SkylakeX emulation utest run to
the Azure CI matrix; a custom Docker build was required
because Ubuntu image provided by Azure does not support
AVX512VL instructions

* Add option USE_LOCKING for single-threaded build with locking support

for calling from concurrent threads

* Add option USE_LOCKING for single-threaded build with locking support

* Add option USE_LOCKING for SMP-like locking in USE_THREAD=0 builds

* Add option USE_LOCKING but keep default settings intact

* Remove unrelated change

* Do not try ancient PGI hacks with recent versions of that compiler

should fix OpenMathLib#2139

* Build and run utests in any case, they do their own checks for fortran availability

* Add softfp support in min/max kernels

fix for OpenMathLib#1912

* Revert "Add softfp support in min/max kernels"

* Separate implementations of AMAX and IAMAX on arm

As noted in OpenMathLib#1912 and comment on OpenMathLib#1942, the combined implementation happens to "do the right thing" on hardfp, but cannot return both value and index on softfp where they would have to share the return register

* Ensure correct output for DAMAX with softfp

* Use generic kernels for complex (I)AMAX to support softfp

* improved zgemm power9 based on power8

* upload thread safety test folder

* hook up c++ thread safety test (main Makefile)

*  add c++ thread test option to Makefile.rule

* Document NO_AVX512 

for OpenMathLib#2151

* sgemm pipeline improved, zgemm rewritten without inner packs, ABI lxvx v20 fixed with vs52

* Fix detection of AVX512 capable compilers in getarch

21eda8b introduced a check in getarch.c to test if the compiler is capable of
AVX512. This check currently fails, since the used __AVX2__ macro is only
defined if getarch itself was compiled with AVX2/AVX512 support. Make sure this
is the case by building getarch with -march=native on x86_64. It is only
supposed to run on the build host anyway.

* c_check: Unlink correct file

* power9 zgemm ztrmm optimized

* conflict resolve

* Add gfortran workaround for ABI violations in LAPACKE

for OpenMathLib#2154 (see gcc bug 90329)

* Add gfortran workaround for ABI violations

for OpenMathLib#2154 (see gcc bug 90329)

* Add gfortran workaround for potential ABI violation 

for OpenMathLib#2154

* Update fc.cmake

* Remove any inadvertent use of -march=native from DYNAMIC_ARCH builds

from OpenMathLib#2143, -march=native precludes use of more specific options like -march=skylake-avx512 in individual kernels, and defeats the purpose of dynamic arch anyway.

* Avoid unintentional activation of TLS code via USE_TLS=0

fixes OpenMathLib#2149

* Do not force gcc options on non-gcc compilers

fixes compile failure with pgi 18.10 as reported on OpenBLAS-users

* Update Makefile.x86_64

* Zero ecx with a mov instruction

PGI assembler does not like the initialization in the constraints.

* Fix mov syntax

* new sgemm 8x16

* Update dtrmm_kernel_16x4_power8.S

* PGI compiler does not like -march=native

* Fix build on FreeBSD/powerpc64.

Signed-off-by: Piotr Kubaj <pkubaj@anongoth.pl>

* Fix build for PPC970 on FreeBSD pt. 1

FreeBSD needs DCBT_ARG=0 as well.

* Fix build for PPC970 on FreeBSD pt.2

FreeBSD needs those macros too.

* cgemm/ctrmm power9

* Utest needs CBLAS but not necessarily FORTRAN

* Add mingw builds to Appveyor config

* Add getarch flags to disable AVX on x86

(and other small fixes to match Makefile behaviour)

* Make disabling DYNAMIC_ARCH on unsupported systems work

needs to be unset in the cache for the change to have any effect

* Mingw32 needs leading underscore on object names

(also copy BUNDERSCORE settings for FORTRAN from the corresponding Makefile)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants