If I compile w/ -fast, I get a SIGSEGV, but if I compile w/ -fast -g, (or no optimization, or -g -C) the code runs fine.
I checked the code with ‘-g -C’, and again this cause the code to complete fine (and a valid computation).
while I’m wiling to accept that I still have a subtle typo/bug, but how can I track it down, if all I get is:
Signalled SIGSEGV at 0x407F34, function cmpleak_vw.pgi.uni.k8e_, file cmpleak_vw.f90
0x407F34: 49 8B 4C 5 8 movq 8(%r13,%rax),%rcx
pgdbg> where
STACK TRACE:
#2 main address: 0x401FA0
#1 do_cmpleaks_vw.pgi.uni.k8e_ line: 54 in “do_cmpleaks_vw.f90” address: 0x402BAE
=> #0 cmpleak_vw.pgi.uni.k8e_ file: cmpleak_vw.f90 address: 0x407F34
unless the -fast option is triggering a compiler bug ;-{
the problem is related to
-Mvect=sse -Mscalarsse
as I found what -fast expands to w/ pgf90 -help -fast
I’m not sure I understand exactly what these flags do exactly nor why they would cause a segv…
but at least I have a workaround…
Hi Sylvain,
Do you mind sending a example of the error to PGI Customer support (trs@pgroup.com)? If it is a compiler error, we’d like to know. If it’s not, then hopefully we can help explain what’s happening.
FYI, “-Mscalarsse” tells the compiler to use the SSE floating point unit versus the x87 FPU. “-Mvect” enables the auto-vectorizer.
“-g” will disable some optimizations that inhibit debugging. However, “-gopt” will add debug information but not disable any optimization. Try compiling with “-fast -gopt” to see if you can narrow down where the segv occurs.