Has anyone been able to successfully compile WRF 3.3 on the Magny-Cours platform, using the Intel, GCC or Open64 compiler?   I have been attempting this for weeks, and the compile consistently fails.  I have built Magny-Cours optimized versions of all the latest versions of WRF's dependencies (i.e. NetCDF, OpenMPI, etc.), but when I get to the compilation phase for WRF it craps out.   I don't have this issue when attempting to compile it on an Intel platform.

Hi All,

I am trying to build parmetis-4.0.2 with Open64 v4.5.2 on Redhat 6.2.  It fails with

Linking C executable mtest

cd /opt/gridware/downloads/simonh/parmetis-4.0.2/build/Linux-x86_64/programs && /opt/gridware/tools/gcc/cmake/2.8.7/bin/cmake -E cmake_link_script CMakeFiles/mtest.dir/link.txt --verbose=1

/opt/gridware/mpi/x86_open64-4.5.2/openmpi/1.6-psm/bin/mpicc   -DLINUX -D_FILE_OFFSET_BITS=64 -std=c99 -fno-strict-aliasing -fPIC -Wall -pedantic -Wno-unused-variable -Wno-unknown-pragmas -DNDEBUG -DNDEBUG2 -DHAVE_EXECINFO_H -DHAVE_GETLINE -O3    CMakeFiles/mtest.dir/mtest.c.o CMakeFiles/mtest.dir/io.c.o  -o mtest -rdynamic ../libparmetis/libparmetis.a ../libmetis/libmetis.a -lm

../libmetis/libmetis.a(memory.c.o): In function `gk_free':

/opt/gridware/downloads/simonh/parmetis-4.0.2/metis/GKlib/memory.c:203: undefined reference to `.L_180_11778'

collect2: ld returned 1 exit status

Grep suggests that .L_180_11778 does in fact exist in libmetis.a.  Grateful for any suggestions as to why the link stage is failing.

Cheers

Simon

Hello, 

I cannot compile x86_open64-4.2.3 due to incompatible libstdc++.

working on 64b Debian 5:

2.6.30-2-amd64 #1 SMP Mon Dec 7 05:21:45 UTC 2009 x86_64 GNU/Linux

Compile by:

make all MACHINE_TYPE=i386

get

...

make[3]: Entering directory `/opt/x86_open64-4.2.3/osprey/targia32_x8664/targ_info'

C++    /opt/x86_open64-4.2.3/osprey/targia32_x8664/targ_info/isa_gen.o

/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.3.4/libstdc++.so when searching for -lstdc++

/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.3.4/libstdc++.a when searching for -lstdc++

/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.3.4/libstdc++.so when searching for -lstdc++

/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.3.4/libstdc++.a when searching for -lstdc++

/usr/bin/ld: cannot find -lstdc++

collect2: ld returned 1 exit status

I am following Instalation instructions according ubuntu 9.10 but with no effect.

Could you help me?

Regars, Pavel

Hi,

   A discussion thread about compiling ABINIT sources with Open64 compiler and issues faced is posted at

http://forum.abinit.org/viewtopic.php?f=3&t=40

Compiling the sources with the latest Open64 binaries is been suggested.

Thanks

Compiler Support Team

-------------------------
The information presented in this document is for informational purposes only and may contain technical inaccuracies, omissions and typographical errors. Links to third party sites are for convenience only, and no endorsement is implied.

I have tried to follow the example at:

http://developer.amd.com/tools/open64/AppsAndLibraries/Documents/building_with_acml.html

but it just wouldnt work. I have to add -lfortran and -lffio . So my question is, why do I have to add -lfortran and -lffio to the command line? (and why not with gcc etc. but only with opencc?

-bash-4.1$ opencc -O3 matrixmult_double.c matrixutil.o -o matrixmult_double -I$ACML_INCLUDE -lacml 
/export/modules/devel/ACML/5.1.0/amd/open64_64/lib/libacml.so: undefined reference to `_TRANSFER'
/export/modules/devel/ACML/5.1.0/amd/open64_64/lib/libacml.so: undefined reference to `_index90'
/export/modules/devel/ACML/5.1.0/amd/open64_64/lib/libacml.so: undefined reference to `_F90_STOP'
/export/modules/devel/ACML/5.1.0/amd/open64_64/lib/libacml.so: undefined reference to `_FRF'
/export/modules/devel/ACML/5.1.0/amd/open64_64/lib/libacml.so: undefined reference to `s_cmp'
/export/modules/devel/ACML/5.1.0/amd/open64_64/lib/libacml.so: undefined reference to `s_copy'
/export/modules/devel/ACML/5.1.0/amd/open64_64/lib/libacml.so: undefined reference to `s_cat'
/export/modules/devel/ACML/5.1.0/amd/open64_64/lib/libacml.so: undefined reference to `__powri'
/export/modules/devel/ACML/5.1.0/amd/open64_64/lib/libacml.so: undefined reference to `_FWF'
/export/modules/devel/ACML/5.1.0/amd/open64_64/lib/libacml.so: undefined reference to `_DEALLOC'
/export/modules/devel/ACML/5.1.0/amd/open64_64/lib/libacml.so: undefined reference to `__powii'
/export/modules/devel/ACML/5.1.0/amd/open64_64/lib/libacml.so: undefined reference to `__powdi'
collect2: ld returned 1 exit status
-bash-4.1$ opencc -O3 matrixmult_double.c matrixutil.o -o matrixmult_double -I$ACML_INCLUDE -lacml -lfortran -lffio
-bash-4.1$ 

Thanks,

Evren

Hi guys,

I am trying to compile R 2.15.1 with Open64 4.5.1 and ACMP 5.1.9 (open64_64_fma4_mp).

The configure went without an error but when I compiled it, it failed when linking objects for libR.so:

/usr/bin/ld: eval.o: relocation R_X86_64_32S against `.text' can not be used when making a shared object; recompile with -fPIC
eval.o: could not read symbols: Bad value
collect2: ld returned 1 exit status

So I saw the -fPIC indeed wasn't there, so I modified the Makeconf to include -fPIC, but it still failed with the same error. I also tried -fpic install, no help.

I am using CentOS 6.2 x86_64.

Regards,

Derrick

Hello All,

We have new version of the Open64 compiler, v4.5.2, released with performance improvements and many bug fixes.  Please check.

For details refer http://developer.amd.com/tools/open64/pages/default.aspx

Regards,

Santosh

I'm trying to use X86 Open64 version 4.2.5.2 to compile HPL 2.0 for an FX series processor.

The OS is Red Hat 5.7.  I previously had a FX 965 Black Edition processor in this system and compiled HPL 2.0 with ACML and Open64 without problems.

I replaced the CPU with the latest FX (Bouldozer based) CPU and now when I try and recompile HPL, it fails with:

make[2]: Entering directory `/home/penguin/bdver1/hpl-2.0/src/auxil/Linux_Open64_ACML'
/opt/x86_open64-4.2.5.2/bin/opencc -o HPL_dlacpy.o -c   -I/home/penguin/bdver1/hpl-2.0/include -I/home/penguin/bdver1/hpl-2.0/include/Linux_Open64_ACML -I/opt/acml5.0.0/open64_64/include -I/usr/lib64/openmpi/1.4-gcc/include -W -Wall -O3 -OPT:Ofast  ../HPL_dlacpy.c
/tmp/ccspin#.DVSDvP.s: Assembler messages:
/tmp/ccspin#.DVSDvP.s:65: Error: no such instruction: `vzeroupper '
/tmp/ccspin#.DVSDvP.s:197: Error: no such instruction: `vmovsd -104(%rbx,%r10,1),%xmm11'
/tmp/ccspin#.DVSDvP.s:198: Error: no such instruction: `vmovsd -112(%rbx,%r10,1),%xmm13'
/tmp/ccspin#.DVSDvP.s:200: Error: no such instruction: `vmovsd -120(%rbx,%r10,1),%xmm14'
/tmp/ccspin#.DVSDvP.s:202: Error: no such instruction: `vmovsd -128(%rbx,%r10,1),%xmm15'
/tmp/ccspin#.DVSDvP.s:204: Error: no such instruction: `vmovsd %xmm11,-104(%rbp,%r10,1)'
/tmp/ccspin#.DVSDvP.s:205: Error: no such instruction: `vmovsd -104(%r11,%r10,1),%xmm7'

And so on.

I've tried explictly adding "-march=bdver1" to the CCFLAGS, but no change.  I've tried adding "-mno-avx" and "-mno-fma4" and that silences the "no such instruction" error, but now "gcc" segfaults:

make[2]: Entering directory `/home/penguin/bdver1/hpl-2.0/src/auxil/Linux_Open64_ACML'
/opt/x86_open64-4.2.5.2/bin/opencc -o HPL_dlacpy.o -c   -I/home/penguin/bdver1/hpl-2.0/include -I/home/penguin/bdver1/hpl-2.0/include/Linux_Open64_ACML -I/opt/acml5.0.0/open64_64/include -I/usr/lib64/openmpi/1.4-gcc/include -W -Wall -O3 -OPT:Ofast -mno-avx -mno-fma4  ../HPL_dlacpy.c
opencc INTERNAL ERROR: /opt/x86_open64-4.2.5.2/open64-gcc-4.2.0/bin/gcc died due to signal 11
make[2]: *** [HPL_dlacpy.o] Error 1

And the kernel reports:

gcc[22275]: segfault at 0000000008cd300c rip 0000000008054df3 rsp 00000000ff856ae8 error 4
gcc[22508]: segfault at 0000000008cd300c rip 0000000008054df3 rsp 00000000fff13368 error 4
gcc[22711]: segfault at 0000000008cd300c rip 0000000008054df3 rsp 00000000ffdae118 error 4

after three attempts.

NOTE that Red Hat 5.7 does not support AVX or FMA4 and disables those bits in the processor flags.

vendor_id       : AuthenticAMD
cpu family      : 21
model           : 1
stepping        : 2
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc nonstop_tsc pni ssse3 cx16 sse4_1 sse4_2 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy altmovcr8 abm sse4a misalignsse 3dnowprefetch osvw ibs

HI,

it's very similar as http://devgurus.amd.com/message/1283521#1283521 , but with the right system/OS (  I hope )  :

When testing our code with 4.5.2 the program compiles no problem, but on execution it exits with 'Illegal instruction' error message.

The same code works fine with 4.5.1 compiler on the same machine.

Here is a cut down of the (Fortran) code (intsizetest.f90):

program integer_size  integer    :: i  integer(8) :: i8  i8 = huge(i)  select case(i8)  case(127_8);                 i = 1  case(32767_8);               i = 2  case(2147483647_8);          i = 4  case(9223372036854775807_8); i = 8  end select  write(*,'(i1)') i

end program integer_size

compiled with simply:

openf90  -o intsizetest.x intsizetest.f90

./intsizetest.x

Illegal instruction

gdb intsizetest.x

GNU gdb (GDB) Red Hat Enterprise Linux (7.2-48.el6)

...

(gdb) r

Starting program: /home/buildbot/WorkSpace/trunk_7.0.1_private/fallbacks/sources/libxc-1.1.0.1/intsizetest.x

 

Program received signal SIGILL, Illegal instruction.

_s2ui () at /local/home/qa/nightly_build_avx/sandbox/open64/osprey/libu/numconv/mpp/s2uboiz.c:440

440          /local/home/qa/nightly_build_avx/sandbox/open64/osprey/libu/numconv/mpp/s2uboiz.c: No such file or directory.

          in /local/home/qa/nightly_build_avx/sandbox/open64/osprey/libu/numconv/mpp/s2uboiz.c

Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.80.el6_3.5.x86_64

The compilers are both the RHEL 6 rpm versions, i.e.:

x86_open64-4.5.1-1.x86_64.rpm

x86_open64-4.5.2-1.x86_64.rpm

and both are installed on a 64-bit machine running  Scientific Linux release 6.1 (Carbon).

openf90 --version

Open64 Compiler Suite: Version 4.5.2

Built on: 2012-08-03 01:26:59 -0700

Thread model: posix

GNU gcc version 4.2.0 (Open64 4.5.2 driver)

 

cat /proc/cpuinfo

processor          : 0

vendor_id          : AuthenticAMD

cpu family          : 16

model                    : 9

model name          : AMD Opteron(tm) Processor 6140

stepping          : 1

 

rpm -qa | grep glibc

glibc-common-2.12-1.80.el6_3.5.x86_64

glibc-devel-2.12-1.80.el6_3.5.i686

glibc-devel-2.12-1.80.el6_3.5.x86_64

glibc-2.12-1.80.el6_3.5.x86_64

glibc-headers-2.12-1.80.el6_3.5.x86_64

glibc-debuginfo-2.12-1.25.el6_1.3.i686

glibc-2.12-1.80.el6_3.5.i686

regards

jmb

While compiling FFTW 3.3.1 for the Interlagos architecture, with AVX instructions, Open64 generates the following incorrect instructions in the output assembly file:

vmovsd %ymm0,360(%rsp)

vmovsd 360(%rsp),%ymm4

According to the AMD64 Architecture Programmer's Manual, Volume 4 (Publication No 26568), these instructions are indeed incorrect: vmovsd only works with 128-bit xmm registers, and not with 256-bit ymm registers. The correct move instruction is vmovups.

Could you please fix this issue in the next release?

Maik

The simple test example shown below illustrates a problem I found when using the openf90 compiler (version 4.2.4 from AMD-developer). Other Fortran compilers like Intel Fortran, Absoft Fortran and GNU Fortran works fine on this example. Using OMP THERADPRIVATE in a Fortran module does not work properly with openf90, the workaround is to use a named common block in the module and set OMP FIRSTPRIVATE on that.

openf90 -o mytest -openmp omp_test_threadprivate.f90

./mytest produces truncated output for Test1:

MAXIMUM 8 THREADS
Test1, NVALS=4
 1 0
Test2, NVALS=4
 1 0
 2 1
 3 2
 4 3

The output should rather be something like:

MAXIMUM 8 THREADS
Test1, NVALS=4
 1 0
 2 1
 4 3
 3 2
Test2, NVALS=4
 2 1
 3 2
 4 3
 1 0

--- example fortran code: omp_test_threadprivate.f90

MODULE MyData1
   IMPLICIT NONE
   INTEGER :: IVAL,NVALS
   SAVE IVAL
   !$OMP THREADPRIVATE(IVAL)
END MODULE MyData1

MODULE MyData2
   IMPLICIT NONE
   INTEGER :: IVAL,NVALS
   COMMON /MyData2_IVAL_CMN/ IVAL
   !$OMP THREADPRIVATE(/MyData2_IVAL_CMN/)
END MODULE MyData2

SUBROUTINE Test1
   USE MyData1
   IMPLICIT NONE
   INTEGER N, TID
   !$ INTEGER, EXTERNAL :: OMP_GET_THREAD_NUM
   NVALS = 4
   WRITE(*,'(A,I0.1)') 'Test1, NVALS=',NVALS
   TID = 0
   !$OMP PARALLEL DO PRIVATE(N,TID)
   DO N = 1,NVALS
      !$ TID = OMP_GET_THREAD_NUM()
      WRITE(*,'(2(1X,I0.1))') N,TID
   END DO
END SUBROUTINE Test1

SUBROUTINE Test2
   USE MyData2
   IMPLICIT NONE
   INTEGER N, TID
   !$ INTEGER, EXTERNAL :: OMP_GET_THREAD_NUM
   NVALS = 4
   WRITE(*,'(A,I0.1)') 'Test2, NVALS=',NVALS
   TID = 0
   !$OMP PARALLEL DO PRIVATE(N,TID)
   DO N = 1,NVALS
      !$ TID = OMP_GET_THREAD_NUM()
      WRITE(*,'(2(1X,I0.1))') N,TID
   END DO
END SUBROUTINE Test2

PROGRAM Test
   IMPLICIT NONE
   !$ INTEGER, EXTERNAL :: OMP_GET_THREAD_NUM,OMP_GET_NUM_THREADS
   !$ CALL OMP_SET_DYNAMIC(.FALSE.)
   !$OMP PARALLEL
   !$ IF (OMP_GET_THREAD_NUM() == 0) THEN
   !$    WRITE(*,'(A,I0.1,A)') 'MAXIMUM ',OMP_GET_NUM_THREADS(),' THREADS'
   !$ END IF
   !$OMP END PARALLEL
   CALL Test1
   CALL Test2
END PROGRAM Test

---

I am trying to build ATLAS library using opencc... but strangely it is failing... Did anybody succeed in compiling ATLAS with opencc ever? or what is wrong? (actually, I couldnt compile anything but very simple codes with OpenCC os far, it is quickly getting annoying.. )

# uname -a

Linux asg2 2.6.32-220.13.1.el6.x86_64 #1 SMP Tue Apr 17 15:16:22 CDT 2012 x86_64 x86_64 x86_64 GNU/Linux

# opencc -v

Open64 Compiler Suite: Version 4.5.1

Built on: 2011-12-16 10:00:56 -0800

Thread model: posix

GNU gcc version 4.2.0 (Open64 4.5.1 driver)

ERROR message part:

...

...

make[5]: Entering directory `/home/XXX/temp/ATLASint/Linux/tune/sysinfo'

make RunMulAdd pre=s

make[6]: Entering directory `/home/XXX/temp/ATLASint/Linux/tune/sysinfo'

opencc -DL2SIZE=4194304 -I/home/XXX/temp/ATLASint/Linux/include -I/home/XXX/temp/ATLASint/Linux/..//include -I/home/XXX/temp/ATLASint/Linux/..//include/contrib -DAdd__ -DF77_INTEGER=int -DStringSunStyle -DATL_OS_Linux -DATL_ARCH_Corei1 -DATL_CPUMHZ=2666 -DATL_SSE3 -DATL_SSE2 -DATL_SSE1 -DATL_USE64BITS -DATL_GAS_x8664  -DATL_NCPU=12 -m64 -O3 -march=auto  -o xmasrch /home/XXX/temp/ATLASint/Linux/..//tune/sysinfo/masrch.c

./xmasrch -p s -o res/sMULADD

opencc INTERNAL ERROR: /export/modules/compilers/amd/x86_open64/4.5.1/lib/gcc-lib/x86_64-open64-linux/4.5.1/be died due to signal 11

make[7]: *** [xsma] Error 1

xmasrch: /home/XXX/temp/ATLASint/Linux/..//tune/sysinfo/masrch.c:108: matime: Assertion `!system(ln)' failed.

Finding how many mflops required to get .025 second timings:

make[6]: *** [RunMulAdd] Aborted

make[6]: Leaving directory `/home/XXX/temp/ATLASint/Linux/tune/sysinfo'

make[5]: *** [res/sMULADD] Error 2

make[5]: Leaving directory `/home/XXX/temp/ATLASint/Linux/tune/sysinfo'

xsyssum: /home/XXX/temp/ATLASint/Linux/..//tune/sysinfo/GetSysSum.c:69: getfpinfo0: Assertion `system(fnam) == 0' failed.

make[4]: *** [/home/XXX/temp/ATLASint/Linux/include/atlas_ssysinfo.h] Aborted

make[4]: Leaving directory `/home/XXX/temp/ATLASint/Linux/tune/sysinfo'

make[3]: *** [/home/XXX/temp/ATLASint/Linux/include/atlas_ssysinfo.h] Error 2

make[3]: Leaving directory `/home/XXX/temp/ATLASint/Linux/src/auxil'

make[2]: *** [IStage1] Error 2

make[2]: Leaving directory `/home/XXX/temp/ATLASint/Linux/bin'

ERROR 621 DURING CACHESIZE SEARCH!!.  CHECK INSTALL_LOG/Stage1.log FOR DETAILS.

...

...

With the new release of AMD open64 4.5.2, I wanted to recompile openmpi to support the new version. However I've been having problems building openmpi. I've tried different things. However, when I run the following configure command:

# ./configure --prefix=/usr/local/openmpi CC=opencc CXX=openCC F77=openf90 FC=openf90 CFLAGS=-m64 CXXFLAGS=-m64 FFLAGS=-m64 FCFLAGS=-m64

Results in the following error:

checking Fortran 90 kind of MPI_INTERGER_KIND (selected_int_kind(9))... ./configure: line 53651: 16695 Illegal instruction     ./conftest 1>&5 2>&1

configure: error: Could not determine kind of selected_int_kind(MPI_INTEGER_KIND)

I've also tried omitting specifying the F77 variable in the configure line. This allows the configuration to proceed error free and I can subsequently build and install openmpi. However doing this results in an error message saying that openmpi was not built with Fortran 90 support so the command mpif90 does not work. Anybody else seeing these kinds of errors?

Philippe

I downloaded mpich2 1.5rc1:

http://www.mcs.anl.gov/research/projects/mpich2/downloads/index.php?s=downloads

I have the following environment variables set:

export CFLAGS="-march=barcelona -msse3 -O2 -lfortran -lffio -lm"

export FFLAGS="-march=barcelona -msse3 -O2 -lfortran -lffio -lm"

export FCFLAGS="-march=barcelona -msse3 -O2 -lfortran -lffio -lm"

export CPPFLAGS="-march=barcelona -msse3 -O2 -lfortran -lffio -lm"

export CXXFLAGS="-march=barcelona -msse3 -O2 -lfortran -lffio -lm"

export CC=opencc

export CXX=openCC

export FC=openf95

export F77=openf95

export F95=openf95

I simply run  ./configure script and then make

Making all in .
make[2]: Entering directory `/home/eyurtese/temp/mpich2-1.5rc1'  CC       src/binding/f90/create_f90_real.lo
src/binding/f90/create_f90_real.c: In function 'PMPI_Type_create_f90_real':
src/binding/f90/create_f90_real.c:73: error: expected expression before ',' token
src/binding/f90/create_f90_real.c:74: warning: braces around scalar initializer
src/binding/f90/create_f90_real.c:74: warning: (near initialization for 'f90_real_model[0].dtype')
src/binding/f90/create_f90_real.c:74: error: expected expression before ',' token
src/binding/f90/create_f90_real.c:74: warning: excess elements in scalar initializer
src/binding/f90/create_f90_real.c:74: warning: (near initialization for 'f90_real_model[0].dtype')
make[2]: *** [src/binding/f90/create_f90_real.lo] Error 1
make[2]: Leaving directory `/home/eyurtese/temp/mpich2-1.5rc1'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/eyurtese/temp/mpich2-1.5rc1'
make: *** [all] Error 2

Can you tell what is wrong?

I want to install AMD open64 suite on ubuntu 11.04 amd64. The cpu is 6100 magny-core. This is the error I get

root@srv:/opt/x86_open64-4.2.5.1# ./configure MACHINE_TYPE=ia64
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
configure: error: "Assembler doesn't support one or all of AVX XOP FMA4 group of instruction"

The cpuinfo looks like

processor       : 15
vendor_id       : AuthenticAMD
cpu family      : 16
model           : 9
model name      : AMD Opteron(tm) Processor 6136
stepping        : 1
cpu MHz         : 800.000
cache size      : 512 KB
physical id     : 1
siblings        : 8
core id         : 3
cpu cores       : 8
apicid          : 39
initial apicid  : 23
fpu             : yes
fpu_exception   : yes
cpuid level     : 5
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nonstop_tsc extd_apicid amd_dcm pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt nodeid_msr
bogomips        : 4800.16
TLB size        : 1024 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate

also

root@srv:~# uname -a
Linux srv 2.6.32-24-server #39-Ubuntu SMP Wed Jul 28 06:21:40 UTC 2010 x86_64 GNU/Linux

Hello,

I'm trying to recompile one of my code to exploit the Bulldozer architecture efficiently. Both ICC and XLC manages to vectorize the most critical loop. But opencc 4.5.1 fails with:

#####

(1.I:426) Do loop has unmapped loads/stores/calls, loop was not intrinsic vectorized!

#####

The strange thing is, if I add at the beggining of the file:

#define expm1(a) (exp(a)-1.)

then I get:

#####

(1.I:427) Expression rooted at op "OPC_IF"(line 427) is not vectorizable. Loop was not vectorized.

(1.I:427) LOOP WAS VECTORIZED FOR VECTOR INTRINSIC ROUTINE(S).

(1.I:427) LOOP WAS VECTORIZED FOR VECTOR INTRINSIC ROUTINE(S).

(1.I:427) LOOP WAS VECTORIZED FOR VECTOR INTRINSIC ROUTINE(S).

#####

Apparently, it fails at vectorizing expm1(). The patched version using exp()-1. is not acceptable, as it's nowhere near accurate enough when input values are close to 0.

Is that the expected behavior?

Cordially,

I am trying to build PETSc with shared libraries. I have given --sharedLibraryFlags="-fPIC -shared" option yet I am getting the error below. Is it possible that open64 is accidentally using libopen64rt.a instead of libopen64rt_shared.a ? (I am not sure at what point PETSc is passing -fPIC -shared options. This compiles fine on GCC. Any ideas?

Completed building libraries

=========================================

making shared libraries in /export/tmp/petsc-3.2-p7/arch-linux2-c-opt/lib

building libpetsc.so

/usr/bin/ld:

/export/modules/compilers/amd/x86_open64/4.5.1/lib/gcc-lib/x86_64-open64-linux/4.5.1/libopen64rt.a(cacheinfo.o):

relocation R_X86_64_32S against `.rodata'

a shared object; recompile with -fPIC

/export/modules/compilers/amd/x86_open64/4.5.1/lib/gcc-lib/x86_64-open64-linux/4.5.1/libopen64rt.a:

could not read symbols: Bad value 

collect2: ld returned 1 exit status

=========================================

Now to install the libraries do:

make PETSC_DIR=/export/tmp/petsc-3.2-p7 PETSC_ARCH=arch-linux2-c-opt

install

=========================================

Hi guys,

I am trying to compile R 2.15.1 with Open64 4.5.1 and ACMP 5.1.9 (open64_64_fma4_mp).

The configure went without an error but when I compiled it, it failed when linking objects for libR.so:

/usr/bin/ld: eval.o: relocation R_X86_64_32S against `.text' can not be used when making a shared object; recompile with -fPIC
eval.o: could not read symbols: Bad value
collect2: ld returned 1 exit status

So I saw the -fPIC indeed wasn't there, so I modified the Makeconf to include -fPIC, but it still failed with the same error. I also tried -fpic install, no help.

I am using CentOS 6.2 x86_64.

Regards,

Derrick

When testing our code with 4.5.2 the program compiles no problem, but on execution it exits with 'Illegal instruction' error message. The same code works fine with 4.5.1 compiler on the same machine. Here is a cut down of the (Fortran) code (test.f90):

MODULE test_mod

INTEGER, PARAMETER :: i=20

END MODULE test_mod

PROGRAM test_prog

USE test_mod

IMPLICIT NONE

WRITE(6,*)i

END

compiled with simply:

openf90 test.f90

The program built with 4.5.1 gives the expected '20' when run, whereas with 4.5.2 'Illegal instruction' is given. Writing a hard-coded character string works, so I think the issue is referencing the variable from the module.

The compilers are both the SLES 11 rpm versions, i.e.:

x86_open64-4.5.1-1.x86_64.rpm

x86_open64-4.5.2-1.x86_64.rpm

and both are installed on a 64-bit machine running openSUSE 12.1 (actually I've reproduced this on more than 1 machine). Any advice about how to fix this would be greatly appreciated.

While compiling the AMBER 11 MD program, the compiler failed with the following message. Any work-around?

Code compiles cleanly with gfortran and ifort

Gene

Signal: Segmentation fault in IR->WHIRL Conversion phase.

"_pb_exmol.f": Error: Signal Segmentation fault in phase IR->WHIRL Conversion -- processing aborted

*** Internal stack backtrace:

    /packages/x86_open64/4.5.1-1/lib/gcc-lib/x86_64-open64-linux/4.5.1/mfef95() [0x810df36]

    /packages/x86_open64/4.5.1-1/lib/gcc-lib/x86_64-open64-linux/4.5.1/mfef95() [0x810efab]

    /packages/x86_open64/4.5.1-1/lib/gcc-lib/x86_64-open64-linux/4.5.1/mfef95() [0x810ec92]

    /packages/x86_open64/4.5.1-1/lib/gcc-lib/x86_64-open64-linux/4.5.1/mfef95() [0x810ed0d]

    /packages/x86_open64/4.5.1-1/lib/gcc-lib/x86_64-open64-linux/4.5.1/mfef95() [0x810f5f1]

    /packages/x86_open64/4.5.1-1/lib/gcc-lib/x86_64-open64-linux/4.5.1/mfef95() [0x806d13c]

    [0x55555400]

    /packages/x86_open64/4.5.1-1/lib/gcc-lib/x86_64-open64-linux/4.5.1/mfef95() [0x80cc0f4]

    /packages/x86_open64/4.5.1-1/lib/gcc-lib/x86_64-open64-linux/4.5.1/mfef95() [0x80ce82a]

    /packages/x86_open64/4.5.1-1/lib/gcc-lib/x86_64-open64-linux/4.5.1/mfef95() [0x82fd9f7]

    /packages/x86_open64/4.5.1-1/lib/gcc-lib/x86_64-open64-linux/4.5.1/mfef95() [0x82fb454]

    /packages/x86_open64/4.5.1-1/lib/gcc-lib/x86_64-open64-linux/4.5.1/mfef95() [0x82fe247]

    /packages/x86_open64/4.5.1-1/lib/gcc-lib/x86_64-open64-linux/4.5.1/mfef95() [0x8309b68]

    /packages/x86_open64/4.5.1-1/lib/gcc-lib/x86_64-open64-linux/4.5.1/mfef95() [0x8309e98]

    /packages/x86_open64/4.5.1-1/lib/gcc-lib/x86_64-open64-linux/4.5.1/mfef95() [0x830a293]

    /packages/x86_open64/4.5.1-1/lib/gcc-lib/x86_64-open64-linux/4.5.1/mfef95() [0x811a198]

    /lib/libc.so.6(__libc_start_main+0xe6) [0x4a6ce6]

    /packages/x86_open64/4.5.1-1/lib/gcc-lib/x86_64-open64-linux/4.5.1/mfef95() [0x805ce41]

openf90 INTERNAL ERROR: /packages/x86_open64/4.5.1-1/lib/gcc-lib/x86_64-open64-linux/4.5.1/mfef95 died due to signal 4