AMD Developer Forums - x86 Open64 Compiler Suite http://forums.amd.com/forum/index.cfm?forumid=9 FuseTalk Hosting Executive Plan Strange bug resulting from linking http://forums.amd.com/forum/messageview.cfm?catid=373&threadid=120382 2009-10-15T13:23:58 -05.00 GertWollny 4 Hi,

when I compile the attached program with openCC, the resulting program reports the string to be empty, although it certainly is not as compiling the same program with g++ and running it prooves. 

g++ creates the following code:

if (a.empty())
 1e3:   48 8d 7d e0             lea    -0x20(%rbp),%rdi
 1e7:   e8 00 00 00 00          callq  1ec <main+0x64>
 1ec:   84 c0                   test   %al,%al
 1ee:   74 2a                   je     21a <main+0x92>

openCC does: 

 if (a.empty())
  d6:   48 8d bd 60 fe ff ff    lea    -0x1a0(%rbp),%rdi
  dd:   e8 00 00 00 00          callq  e2 <main+0x80>
  e2:   85 c0                   test   %eax,%eax
  e4:   74 33                   je     119 <main+0xb7>

i.e. openCC expects string.empty() to set the full 32 bit of  %eax to zero and g++ only requires the lower 8 bits %al to be set to zero.

Since the return type of empty() is bool, and sizeof(bool) is 1 for openCC, the code should most certainly do the same as g++ and only test  %al.

Best,

Ger t

]]> Error compiling Open64 lib on Ubuntu 9 http://forums.amd.com/forum/messageview.cfm?catid=373&threadid=120322 2009-10-14T11:26:28 -05.00 duanmu 5 I passed the "make all" stage but could not compile the libraries.  

 

 

]]> open64 and the version of gcc http://forums.amd.com/forum/messageview.cfm?catid=373&threadid=120311 2009-10-14T07:51:30 -05.00 GertWollny 3 Firstly, thanks for providing the compiler, I'm trying it out right now. Now about the gcc versions:

On Ubuntu and other Linux distributions, various versions of g++ can be installed. Usually, the standard compiler version of the distribution is set as a link of /usr/bin/g++ to the file /usr/bin/g++-X.X.

Therefore on Ubuntu 9.04 open64 will use the frontend of g++-4.3 resulting in compile errors. A workaround is to reset the link of /usr/bin/g++ to point to the parallel installed g++-4.2, but the next time the package of g++-4.3 is updated this manual link will be clobbered.(Likewise, when the distribution is updated.)

If would be nice, if open64 could be persuaded to look for the full name of the g++ executable including the version number instead. 

As I see from the code in osprey/driver/   run.c (my_execv), and in lang_defs.c it might be possible to add the version number from an environment variable (like OPEN64_GCC_FRONTEND_VERSION). If it is set, then  lang_defs.c (get_full_phase_name) would return the executable with the version number, and of course one would have to change the check in  my_execv.

I might come up with a patch later this week if you think is idea could be pursed and if someone with a bit more knowledge of the code can tell me that these are the right spots to change the code. 

Best

Gert

]]> source build error in Ubuntu 9 http://forums.amd.com/forum/messageview.cfm?catid=373&threadid=120081 2009-10-09T19:25:13 -05.00 gaoshuang 4 Folks,

I use gcc 3.4.6 or gcc 4.3.3, build open64-4.2.1

Following errors occur when executing make, does anybody know the reason?

Thanks in advance.

../../common/targ_info/generate/si_gen.cxx:295: error: ?XIT_FAILURE?was not declared in this scope
../../common/targ_info/generate/si_gen.cxx:295: error: ?xit?was not declared in this scope
../../common/targ_info/generate/si_gen.cxx: In constructor ?ES::RES(char*, int)?
../../common/targ_info/generate/si_gen.cxx:387: warning: deprecated conversion from string constant to ?har*?
../../common/targ_info/generate/si_gen.cxx: In constructor ?ES_REQ::RES_REQ()?
../../common/targ_info/generate/si_gen.cxx:597: warning: deprecated conversion from string constant to ?har*?
../../common/targ_info/generate/si_gen.cxx: In constructor ?ATENCY_INFO::LATENCY_INFO(int)?
../../common/targ_info/generate/si_gen.cxx:850: warning: deprecated conversion from string constant to ?har*?
../../common/targ_info/generate/si_gen.cxx: In constructor ?NSTRUCTION_GROUP::INSTRUCTION_GROUP(char*)?
../../common/targ_info/generate/si_gen.cxx:1001: warning: deprecated conversion from string constant to ?har*?
../../common/targ_info/generate/si_gen.cxx: At global scope:
../../common/targ_info/generate/si_gen.cxx:1313: warning: deprecated conversion from string constant to ?har*?
../../common/targ_info/generate/si_gen.cxx: In static member function ?tatic void TOP_SCHED_INFO_MAP::Create_Dummies()?
../../common/targ_info/generate/si_gen.cxx:1323: warning: deprecated conversion from string constant to ?har*?
../../common/targ_info/generate/si_gen.cxx: In static member function ?tatic void TOP_SCHED_INFO_MAP:utput(FILE*)?
../../common/targ_info/generate/si_gen.cxx:1377: error: ?XIT_FAILURE?was not declared in this scope
../../common/targ_info/generate/si_gen.cxx:1377: error: ?xit?was not declared in this scope
make[3]: *** [si_gen.o] Error 1
make[3]: Leaving directory `/nfs/susangao/sw/program/open64-4.2.1-0/osprey/targx8664_x8664/targ_info'
make[2]: *** [default] Error 2
make[2]: Leaving directory `/nfs/susangao/sw/program/open64-4.2.1-0/osprey/targx8664_x8664/targ_info'
make[1]: *** [targ_info] Error 2
make[1]: Leaving directory `/nfs/susangao/sw/program/open64-4.2.1-0'
make: *** [build] Error 2

]]> GPU support in open64 http://forums.amd.com/forum/messageview.cfm?catid=373&threadid=119998 2009-10-08T04:01:59 -05.00 olewsaa 2 Portland fortran compiler has GPU (CUDA) support.

when can we expect to see  open64 fortran with GPU support ?

Old legacy fortran90 code can in many cases benefit strongly from the support currentlt available using the PGI compilers. If open64 could have OpenCL support, CAL  or other ways of utilising the GPU it could be used on ATI cards also. Currently PGI only support CUDA.

 

 

Ole W. Saastad

 

]]> Warning: Variable anon43 in &lt;function name&gt; might be used uninitialized http://forums.amd.com/forum/messageview.cfm?catid=373&threadid=119327 2009-09-24T17:23:55 -05.00 nschmans 4 when compiling with -O3, opencc issues warnings for unitialized variables, that look like this:

Warning: Variable anon43 in <function name> might be used uninitialized

where i've replaced the function name with <function name>.

The problem is that 'anon43' is not a variable name in this function.  The compiler always names the variable in question 'anon##', where ## is some number.  So I have to play a guessing game as to which variable it refers to.  This is easy if the number of variables is small, but generally not.  Is there any way to discover which variable the compiler is complaining about?

]]> Errors compiling Open64 on Suse 11.1 http://forums.amd.com/forum/messageview.cfm?catid=373&threadid=118515 2009-09-06T14:06:39 -05.00 mdoerner 5 Hi Guys,

 

I tried compiling the Open64 4.2.2.2 version from source as 64-bit (i.e. x86_64 was substituted for i386 in MACHINE_TYPE) and the script chokes on the "make lib MACHINE_TYPE=x86_64 BUILD_COMPILER=OSP" command. Here's what happened.....

 

mdoerner@Linux-QuadZilla:~/Xfers/x86_open64-4.2.2> make lib MACHINE_TYPE=x86_64 BUILD_COMPILER=OSP
make -C osprey/targx8664_builtonia32 default
make[1]: Entering directory `/home/mdoerner/Xfers/x86_open64-4.2.2/osprey/targx8664_builtonia32'
MAKE   default in /home/mdoerner/Xfers/x86_open64-4.2.2/include
echo '#ifndef __pathscale_defs_h' > pathscale_defs.h
echo '#define OPEN64_NAME_PREFIX "open"' >> pathscale_defs.h
echo '#define OPEN64_MAJOR_VERSION_NUM 4' >> pathscale_defs.h
echo '#define OPEN64_MINOR_VERSION_NUM 2' >> pathscale_defs.h
echo '#define OPEN64_MAJOR_VERSION "4"' >> pathscale_defs.h
echo '#define OPEN64_MINOR_VERSION "2"' >> pathscale_defs.h
echo '#define OPEN64_FULL_VERSION "4.2.2.2"' >> pathscale_defs.h
echo '#define OPEN64_GCC_VERSION "3.3.1"' >> pathscale_defs.h
echo '#define OPEN64_GCC40_VERSION "4.0.2"' >> pathscale_defs.h
echo '#define OPEN64_GCC42_VERSION "4.2.0"' >> pathscale_defs.h
echo '#define OPEN64_INSTALL_PREFIX "/usr"' >> pathscale_defs.h
echo '#define OPEN64_TARGET ""' >> pathscale_defs.h
echo '#define OPEN64_PATCH_LEVEL "2.2"' >> pathscale_defs.h
echo "#endif" >> pathscale_defs.h
Making sys
Making cmplrs
Making libelf
MAKE   default in /home/mdoerner/Xfers/x86_open64-4.2.2/libelf
make first
make[3]: Nothing to be done for `first'.
make libelf.a
C      /home/mdoerner/Xfers/x86_open64-4.2.2/osprey/targx8664_builtonia32/libelf/../../libelf/lib/32.fsize.c
ERROR: ld.so: object '/lib64/AMD/libsst.so.1' from /etc/ld.so.preload cannot be preloaded: ignored.
opencc WARNING: /opt/open64-4.2.1/lib/gcc-lib/x86_64-open64-linux/4.2.2.2 does not contain all of the Open64 compiler phases.
opencc ERROR: cannot exec /opt/open64-4.2.1/lib/gcc-lib/x86_64-open64-linux/4.2.2.2/cc142: No such file or directory
make[3]: *** [32.fsize.o] Error 1
make[2]: *** [default] Error 2
make[1]: *** [default] Error 2
make[1]: Leaving directory `/home/mdoerner/Xfers/x86_open64-4.2.2/osprey/targx8664_builtonia32'
make: *** [lib] Error 2
mdoerner@Linux-QuadZilla:~/Xfers/x86_open64-4.2.2>

 

...any idea what's going on here? Open64-4.2.1 is installed and the "make all MACHINE_TYPE=x86_64" command seemd to run fine.

 

PS I didn't run this as root, I was going to wait for the "sh ./install_compiler.sg x86_64" command for that.

 

Mike Doerner

]]> huge page support http://forums.amd.com/forum/messageview.cfm?catid=373&threadid=118296 2009-09-01T15:44:33 -05.00 butette 4 I just installed Open64 4.2.2.2.  The release note states that it has huge page (2MB) support.  Is that done automatically.  How do you invoke huge page support ?  is it through libhugetlbfs or ???

Oops..  I see the -HUGEPAGE option in the compiler.  I guess I better read the documentation first.

Thanks,

Phuong Vu

]]> Errors on Open64 compile with new string library http://forums.amd.com/forum/messageview.cfm?catid=373&threadid=117760 2009-08-20T20:39:55 -05.00 mdoerner 7 Hi All,

 

I recently installed the string library libsst-1.0-1.0.x86_64.rpm on my openSUSE 11.1 box. When re-compiling the Engima@Home application with Open64 using -m64 -march=barcelona and -msse4a, I get several errors during the compile, like......

 

ERROR: ld.so: object '/lib64/AMD/libsst.so.1' from /etc/ld.so.preload cannot be preloaded: ignored.

 

...any reason I should be concerned? Didn't see any performace improvement, but not sure if it's a library issue or the project code itself. Thanks.

 

Mike Doerner

]]> Problem compiling LAPACK timing suite with openf90 http://forums.amd.com/forum/messageview.cfm?catid=373&threadid=117684 2009-08-19T10:27:40 -05.00 dbacklund 4 I am having a minor issue with openf90 and may have uncovered a bug. I am trying to compile and run the LAPACK timing suite from netlib.org. My goal is to time ACML routines vs. those of lapack+gotoblas. The problem is when the example program is created and run, there is a SEGMENTATION FAULT. My steps to reproduce are below. I am using CentOS 5.3 on a Rocks Cluster with gcc version 4.1.2 20071124 (from gcc -v) on dual AMD Barcelona hardware.

Download both the LAPACK source as well as the timing package and unpack them into a clean directory.

[code]
wget http://www.netlib.org/lapack/lapack.tgz
wget http://www.netlib.org/lapack/timing/timing.tgz

tar xfz lapack.tgz;cd lapack-3.2.1;tar xfz ../timing.tgz
[/code]

Edit the make.inc file to include openf90 as well as acml. Here is what I use to recreate the error.

[code]
SHELL = /bin/sh
PLAT = _LINUX
#
FORTRAN  = openf90
OPTS     = -g -O0
DRVOPTS  = $(OPTS)
NOOPT    = -g -O0
LOADER   = openf90
LOADOPTS = -Wl,-R/opt/acml4.3.0/open64_64/lib
#
# Timer for the SECOND and DSECND routines
#
# SECOND and DSECND will use a call to the Fortran standard INTERNAL FUNCTION CPU_TIME
TIMER    = INT_CPU_TIME
#
ARCH     = ar
ARCHFLAGS= cr
RANLIB   = ranlib
#
BLASLIB      = -L/opt/acml4.3.0/open64_64/lib -lacml
#
#  Names of generated libraries.
#
LAPACKLIB    = lapack$(PLAT).a
TMGLIB       = tmglib$(PLAT).a
EIGSRCLIB    = eigsrc$(PLAT).a
LINSRCLIB    = linsrc$(PLAT).a
[/code]

I don't compile the lapack library since I am using ACML, but I do touch it so Make does not complain.

Touch the LAPACKLIB and make the TMGLIB.

[code]
touch lapack_LINUX.a
make tmglib
[/code]

Now enter the TIMING directory and build executables. The problem I encounter is with the double precision eigenvalue (EIG) timing tests. The single precision runs correctly, but double, complex, and double complex all Seg fault.

[code]
cd TIMING/EIG/EIGSRC;make;cd ..;make
[/code]

This will generate the proper eigenvalue executables.

[code]
[dbacklund@****** TIMING]$ ldd xeigtimd
        libacml.so => /opt/acml4.3.0/open64_64/lib/libacml.so (0x00002ba4e0549000)
        libmv.so.1 => /opt/open64//lib/gcc-lib/x86_64-open64-linux/4.2.2.1/libmv.so.1 (0x00002ba4e2590000)
        libm.so.6 => /lib64/libm.so.6 (0x000000314ea00000)
        libacml_mv.so => /opt/acml4.3.0/open64_64/lib/libacml_mv.so (0x00002ba4e26bd000)
        libc.so.6 => /lib64/libc.so.6 (0x000000314e600000)
        libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00000035b2c00000)
        librt.so.1 => /lib64/librt.so.1 (0x000000314fe00000)
        /lib64/ld-linux-x86-64.so.2 (0x000000314e200000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003160000000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x000000314f200000)
[/code]

[code]
cd ..
./xeigtimd < dseptim.in   <-- This is where I get a Seg Fault.
[/code]

The Seg fault occurs regardless of input file. I have run GDB and included the output below.

[code]
[dbacklund@******* TIMING]$ gdb xeigtimd             
GNU gdb Red Hat Linux (6.5-37.el5_2.2rh)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu"...Using host libthread_db library "/lib64/libthread_db.so.1".

(gdb) run < dseptim.in
Starting program: /home/dbacklund/ARCHIVES/TAR/lapack-timing-test/lapack-3.2.1/TIMING/xeigtimd < dseptim.in
[Thread debugging using libthread_db enabled]
[New Thread 47510111176096 (LWP 16649)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 47510111176096 (LWP 16649)]
0x00000000004106ef in MAIN__ ()
    at /home/dbacklund/ARCHIVES/TAR/lapack-timing-test/lapack-3.2.1/TIMING/EIG/dtimee.f:1
1             PROGRAM DTIMEE
Current language:  auto; currently fortran

(gdb) backtrace
#0  0x00000000004106ef in MAIN__ ()
    at /home/dbacklund/ARCHIVES/TAR/lapack-timing-test/lapack-3.2.1/TIMING/EIG/dtimee.f:1
#1  0x00000000004da062 in main () at ../../libf/fio/main.c:58
[/code]

Line 1 of dtimee.f is

[code]
      PROGRAM DTIMEE
[/code]

This is not a mission critical error, but I did have a similar problem with openf90 and a utility program included in the software that we use for research. That software is closed source so I cannot share it with the public. The backtrace of this utility that segfaults shows that it occurred at line 1 again (PROGRAM programname) line.

This is not urgent like I said, but maybe this will be useful to some.

]]> Missing libfortran.so and libffio.so http://forums.amd.com/forum/messageview.cfm?catid=373&threadid=116928 2009-08-03T12:13:26 -05.00 dbacklund 4 I noticed in the provided binary packages, there are no shared library versions of libfortran and libffio. Is this intentional? I have compiled from source also and noticed that these shared libraries are generated but not installed via the install-compiler.sh script. Is this just an omission in the script which can be quickly remedied?

Is it safe to copy libfortran.so and libffio.so that I compiled to $TOOLROOT/lib/gcc-lib/x86_64-open64-linux/4.2.2.1 ? Is it possible to modify the Makefile so that libfortran.so and libffio.so have appropriate soname's (libfortran.so.1) etc.

]]> openmp bug? in openf95 http://forums.amd.com/forum/messageview.cfm?catid=373&threadid=116437 2009-07-23T13:37:02 -05.00 zzblac 7 When compiling with -mp, I get an abort when executed with the message:

zzblac@monster:~/md_dir> Assertion Failed at ../../libopenmp/omp_thread.c:457 Can not create more pthread

The compiler options are -O3 -IPA:linear=ON -mcpu=barcelona -march=barcelona -OPT:early_intrinsics=ON, -mp, although the results are the same when using only -mp.  The environmental variables are OMP_NUM_THREADS=16 and OMP_SLAVE_STACK_SIZE=4G as anything less, in 1G steps, results in a segfault.  The openmp section of the code is listed below.  This compiles and executes properly on the intel and sun compilers.  I'd really like to use openf95 as I can tune the serial executable to run much faster, at least with the serial version.  The machine has 4 quad core opterons with 64 GB of memory and the OS is opensuse 10.2.  Is this a bug?  If so, any idea when a fix may be available?

 

SUBROUTINE computeforces (ndim, ra, r, region, regionh, rcut, &
natom, usum, virsum, nebrtab, nebrtabmax, usumshift, nebrtablen)
IMPLICIT none
INTEGER ndim, natom, nebrtabmax, nebrtablen
REAL(KIND=8) :: rcut, usum, virsum, usumshift, f, fcval, rrcut, &
rr, rri, rri3, dr (ndim), ra (ndim, natom), r (ndim, natom), &
region (ndim), regionh (ndim)
INTEGER :: nebrtab (2, nebrtabmax), j1, j2, k, n
rrcut = rcut * rcut
ra = 0.0D0
usum = 0.0D0
virsum = 0.0D0
!$OMP PARALLEL DO DEFAULT (NONE), SCHEDULE(STATIC), &
!$OMP SHARED (nebrtablen,ndim,regionh,region,rrcut,usumshift,nebrtab,r),&
!$OMP PRIVATE (n,k,j1,j2,dr,rr,rri,rri3,fcval,f), &
!$OMP REDUCTION (+:ra,usum,virsum)
DO 30 n = 1, nebrtablen
j1 = nebrtab (1, n)
j2 = nebrtab (2, n)
DO 50 k = 1, ndim
dr (k) = r (k, j1) - r (k, j2)
IF (abs (dr (k) ) >regionh (k) ) then
dr (k) = dr (k) - sign (region (k), dr (k) )
ENDIF
50 END DO
! the following line must match the dimensions
rr = dr (1) * dr (1) + dr (2) * dr (2) + dr (3) * dr (3) &
+ dr (4) * dr (4)
IF (rr
rri = 1.0D0 / rr
rri3 = rri * rri * rri
fcval = 48.0D0 * rri3 * (rri3 - 0.5D0) * rri
DO 60 k = 1, ndim
f = fcval * dr (k)
ra (k, j1) = ra (k, j1) + f
ra (k, j2) = ra (k, j2) - f
60 END DO
usum = usum + 4.0D0 * rri3 * (rri3 - 1.0D0) + usumshift
virsum = virsum + fcval * rr
ENDIF
30 END DO
!$OMP END PARALLEL DO
END SUBROUTINE computeforces

 

]]> Maybe a bug http://forums.amd.com/forum/messageview.cfm?catid=373&threadid=115771 2009-07-08T10:28:34 -05.00 FDominicus 2 I installed all the prerequisites on a Debian box, but it seems there are troubles.. The build breaks with the following error messages:

BISON  /home/local/src/x86_open64-4.2.2/osprey/targia32_x8664/gccfe/gnu/../../../kgccfe/gnu/c-parse.y
../../../kgccfe/gnu/c-parse.y:172.66-72: Warnung: Symbol DEFAULT noch einmal deklariert
../../../kgccfe/gnu/c-parse.y:208.25-31: Warnung: Symbol PRIVATE noch einmal deklariert
../../../kgccfe/gnu/c-parse.y:1743.19-20: $$ für Regelmitte bei $4 von „structsp_attr“ hat keinen deklarierten Typ
../../../kgccfe/gnu/c-parse.y:1753.19-20: $$ für Regelmitte bei $4 von „structsp_attr“ hat keinen deklarierten Typ

 

I think this should not be a problem of another Debian, but I may be wrong of course...

 

Regards

Friedrich

]]> opencc INTERNAL ERROR http://forums.amd.com/forum/messageview.cfm?catid=373&threadid=115421 2009-06-30T10:34:23 -05.00 jgoraus 3 I tried to build opencc on suse 11.1 x64,  ATHLON x2 6000

The file opencc exists but when I try to do the next step in INSTALL,

namely: make lib MACHINE_TYPE=i386 BUILD_COMPILER=OSP

I am getting  the output:

linux-3ct6:/opt/x86_open64-4.2.2 # make lib MACHINE_TYPE=i386 BUILD_COMPILER=OSP
make -C osprey/targia32_builtonia32 default
make[1]: Wej?cie do katalogu `/opt/x86_open64-4.2.2/osprey/targia32_builtonia32'
make -C include default
make -C libelf default
make first
make[3]: Nie ma nic do zrobienia w `first'.
make libelf.a
C      /opt/x86_open64-4.2.2/osprey/targia32_builtonia32/libelf/../../libelf/lib/32.fsize.c

### Assertion failure at line 286 of ../../be/cg/register.cxx:
### Compiler Error in file ../../libelf/lib/32.fsize.c during Codegen Initialization phase:
### invalide register class 8
opencc INTERNAL ERROR: /opt/open64-4.2.1/lib/gcc-lib/x86_64-open64-linux/4.2.2.1/be returned non-zero status 1
make[3]: *** [32.fsize.o] B??d 1
make[2]: *** [default] B??d 2
make[1]: *** [default] B??d 2
make[1]: Opuszczenie katalogu `/opt/x86_open64-4.2.2/osprey/targia32_builtonia32'
make: *** [lib] B??d 2
linux-3ct6:/opt/x86_open64-4.2.2 #

 

When I try to compile some simple program flops.c to see what is the

performance of opencc compiler, I'm getting the same

./flops.c: In function 'main':
./flops.c:174: warning: return type of 'main' is not 'int'

### Assertion failure at line 286 of ../../be/cg/register.cxx:
### Compiler Error in file ./flops.c during Codegen Initialization phase:
### invalide register class 8
opencc INTERNAL ERROR: /opt/open64-4.2.1/lib/gcc-lib/x86_64-open64-linux/4.2.2.1/be returned non-zero status 1

 

What does it mean ?

 

sincerely

J. Goraus

]]> Impossible to build from source in Ubuntu 9 http://forums.amd.com/forum/messageview.cfm?catid=373&threadid=115178 2009-06-24T03:43:59 -05.00 jnavia 18 When building from source I get the following output

jacob@ubuntu9-vm1:~/srcnew/x86_open64-4.2.2$ make
make first
make[1]: Entering directory `/home/jacob/srcnew/x86_open64-4.2.2'
make -C osprey/targx8664_x8664/libspin
make[2]: Entering directory `/home/jacob/srcnew/x86_open64-4.2.2/osprey/targx8664_x8664/libspin'
make[2]: Nothing to be done for `default'.
make[2]: Leaving directory `/home/jacob/srcnew/x86_open64-4.2.2/osprey/targx8664_x8664/libspin'
make -C osprey/targx8664_x8664/libspin_4_2_0
make[2]: Entering directory `/home/jacob/srcnew/x86_open64-4.2.2/osprey/targx8664_x8664/libspin_4_2_0'
make[2]: Nothing to be done for `default'.
make[2]: Leaving directory `/home/jacob/srcnew/x86_open64-4.2.2/osprey/targx8664_x8664/libspin_4_2_0'
make[1]: Leaving directory `/home/jacob/srcnew/x86_open64-4.2.2'
make phony_targets
make[1]: Entering directory `/home/jacob/srcnew/x86_open64-4.2.2'
make -C osprey/targx8664_x8664/include
make[2]: Entering directory `/home/jacob/srcnew/x86_open64-4.2.2/osprey/targx8664_x8664/include'
test: 5: -a: unexpected operator
test: 5: -a: unexpected operator
test: 5: -a: unexpected operator
test: 5: -a: unexpected operator
test: 5: -a: unexpected operator
test: 5: -a: unexpected operator
test: 5: -a: unexpected operator
test: 5: -a: unexpected operator
test: 5: -a: unexpected operator
test: 5: -a: unexpected operator
test: 5: -a: unexpected operator
test: 5: -a: unexpected operator
test: 5: -a: unexpected operator
test: 5: -a: unexpected operator
test: 5: -a: unexpected operator
test: 5: -a: unexpected operator
test: 5: -a: unexpected operator
test: 5: -a: unexpected operator
test: 5: -a: unexpected operator
test: 5: -a: unexpected operator
test: 5: -a: unexpected operator
test: 5: -a: unexpected operator
test: 5: -a: unexpected operator
mkdir: cannot create directory `cmplrs': File exists
make[2]: *** [default] Error 1
make[2]: Leaving directory `/home/jacob/srcnew/x86_open64-4.2.2/osprey/targx8664_x8664/include'
make[1]: *** [include] Error 2
make[1]: Leaving directory `/home/jacob/srcnew/x86_open64-4.2.2'
make: *** [build] Error 2

The problem is that the program "test" does NOT have a "-a" option

]]> Compiler crash http://forums.amd.com/forum/messageview.cfm?catid=373&threadid=115176 2009-06-24T03:07:36 -05.00 jnavia 3
### Assertion failure at line 6275 of ../../be/cg/x8664/expand.cxx:
### Compiler Error in file ReservationDataNodes.cpp during Code_Expansion phase:
### UNIMPLEMENTED
*** glibc detected *** /home/jacob/open64-4.2.1/lib/gcc-lib/x86_64-open64-linux/4.2.1/be: free(): invalid pointer: 0x000000000240f300 ***
======= Backtrace: =========
/lib/libc.so.6[0x2afa3d826cb8]
/lib/libc.so.6(cfree+0x76)[0x2afa3d829276]
/home/jacob/open64-4.2.1/lib/gcc-lib/x86_64-open64-linux/4.2.1/be.so(_ZN23RELATED_SEGMENTED_ARRAYI7BE_PREGLj128EED1Ev+0x59)[0x2afa3ce73dff]
/home/jacob/open64-4.2.1/lib/gcc-lib/x86_64-open64-linux/4.2.1/be.so[0x2afa3ce71edc]
/lib/libc.so.6(__cxa_finalize+0xb0)[0x2afa3d7e5ab0]
/home/jacob/open64-4.2.1/lib/gcc-lib/x86_64-open64-linux/4.2.1/be.so[0x2afa3ce1aa53]
======= Memory map: ========
00400000-0042d000 r-xp 00000000 08:02 1007644                            /home/jacob/open64-4.2.1/lib/gcc-lib/x86_64-open64-linux/4.2.1/be
0052d000-00531000 rw-p 0002d000 08:02 1007644                            /home/jacob/open64-4.2.1/lib/gcc-lib/x86_64-open64-linux/4.2.1/be
023d5000-026f3000 rw-p 023d5000 00:00 0                                  [heap]
2afa3caf5000-2afa3cb15000 r-xp 00000000 08:05 48308                      /lib/ld-2.9.so
2afa3cb15000-2afa3cb18000 rw-p 2afa3cb15000 00:00 0
2afa3cd14000-2afa3cd15000 r--p 0001f000 08:05 48308                      /lib/ld-2.9.so
2afa3cd15000-2afa3cd16000 rw-p 00020000 08:05 48308                      /lib/ld-2.9.so
2afa3cd16000-2afa3d17e000 r-xp 00000000 08:02 1007665                    /home/jacob/open64-4.2.1/lib/gcc-lib/x86_64-open64-linux/4.2.1/be.so
2afa3d17e000-2afa3d27e000 ---p 00468000 08:02 1007665                    /home/jacob/open64-4.2.1/lib/gcc-lib/x86_64-open64-linux/4.2.1/be.so
2afa3d27e000-2afa3d2bf000 rw-p 00468000 08:02 1007665                    /home/jacob/open64-4.2.1/lib/gcc-lib/x86_64-open64-linux/4.2.1/be.so
2afa3d2bf000-2afa3d319000 rw-p 2afa3d2bf000 00:00 0
2afa3d325000-2afa3d327000 r-xp 00000000 08:05 48342                      /lib/libdl-2.9.so
2afa3d327000-2afa3d527000 ---p 00002000 08:05 48342                      /lib/libdl-2.9.so
2afa3d527000-2afa3d528000 r--p 00002000 08:05 48342                      /lib/libdl-2.9.so
2afa3d528000-2afa3d529000 rw-p 00003000 08:05 48342                      /lib/libdl-2.9.so
2afa3d529000-2afa3d5ad000 r-xp 00000000 08:05 48361                      /lib/libm-2.9.so
2afa3d5ad000-2afa3d7ac000 ---p 00084000 08:05 48361                      /lib/libm-2.9.so
2afa3d7ac000-2afa3d7ad000 r--p 00083000 08:05 48361                      /lib/libm-2.9.so
2afa3d7ad000-2afa3d7ae000 rw-p 00084000 08:05 48361                      /lib/libm-2.9.so
2afa3d7ae000-2afa3d7af000 rw-p 2afa3d7ae000 00:00 0
2afa3d7af000-2afa3d917000 r-xp 00000000 08:05 48328                      /lib/libc-2.9.so
2afa3d917000-2afa3db17000 ---p 00168000 08:05 48328                      /lib/libc-2.9.so
2afa3db17000-2afa3db1b000 r--p 00168000 08:05 48328                      /lib/libc-2.9.so
2afa3db1b000-2afa3db1c000 rw-p 0016c000 08:05 48328                      /lib/libc-2.9.so
2afa3db1c000-2afa3db22000 rw-p 2afa3db1c000 00:00 0
2afa3db22000-2afa3db3b000 r-xp 00000000 08:02 1007646                    /home/jacob/open64-4.2.1/lib/gcc-lib/x86_64-open64-linux/4.2.1/core.so
2afa3db3b000-2afa3dc3a000 ---p 00019000 08:02 1007646                    /home/jacob/open64-4.2.1/lib/gcc-lib/x86_64-open64-linux/4.2.1/core.so
2afa3dc3a000-2afa3dc3d000 rw-p 00018000 08:02 1007646                    /home/jacob/open64-4.2.1/lib/gcc-lib/x86_64-open64-linux/4.2.1/core.so
2afa3dc3d000-2afa3df1b000 r-xp 00000000 08:02 1007676                    /home/jacob/open64-4.2.1/lib/gcc-lib/x86_64-open64-linux/4.2.1/cg.so
2afa3df1b000-2afa3e01a000 ---p 002de000 08:02 1007676                    /home/jacob/open64-4.2.1/lib/gcc-lib/x86_64-open64-linux/4.2.1/cg.so
2afa3e01a000-2afa3e03b000 rw-p 002dd000 08:02 1007676                    /home/jacob/open64-4.2.1/lib/gcc-lib/x86_64-open64-linux/4.2.1/cg.so
2afa3e03b000-2afa3e050000 rw-p 2afa3e03b000 00:00 0
2afa3e050000-2afa3e336000 r-xp 00000000 08:02 1007653                    /home/jacob/open64-4.2.1/lib/gcc-lib/x86_64-open64-linux/4.2.1/wopt.so
2afa3e336000-2afa3e435000 ---p 002e6000 08:02 1007653                    /home/jacob/open64-4.2.1/lib/gcc-lib/x86_64-open64-linux/4.2.1/wopt.so
2afa3e435000-2afSignal: Aborted in Code_Expansion phase.
Error: Signal Aborted in phase Code_Expansion -- processing aborted
*** Internal stack backtrace:
    /home/jacob/open64-4.2.1/lib/gcc-lib/x86_64-open64-linux/4.2.1/be.so [0x2afa3d01003e]
    /home/jacob/open64-4.2.1/lib/gcc-lib/x86_64-open64-linux/4.2.1/be.so [0x2afa3d00fe69]
    /home/jacob/open64-4.2.1/lib/gcc-lib/x86_64-open64-linux/4.2.1/be.so [0x2afa3d00ee7c]
    /home/jacob/open64-4.2.1/lib/gcc-lib/x86_64-open64-linux/4.2.1/be.so [0x2afa3d00ea26]
    /home/jacob/open64-4.2.1/lib/gcc-lib/x86_64-open64-linux/4.2.1/be.so(ErrMsgLine+0xb8) [0x2afa3d011332]
    /home/jacob/open64-4.2.1/lib/gcc-lib/x86_64-open64-linux/4.2.1/be.so [0x2afa3d0102cd]
    /lib/libc.so.6 [0x2afa3d7e2040]
    /lib/libc.so.6(gsignal+0x35) [0x2afa3d7e1fb5]
    /lib/libc.so.6(abort+0x183) [0x2afa3d7e3bc3]
    /lib/libc.so.6 [0x2afa3d821228]
    /lib/libc.so.6 [0x2afa3d826cb8]
    /lib/libc.so.6(cfree+0x76) [0x2afa3d829276]
    /home/jacob/open64-4.2.1/lib/gcc-lib/x86_64-open64-linux/4.2.1/be.so(_ZN23RELATED_SEGMENTED_ARRAYI7BE_PREGLj128EED1Ev+0x59) [0x2afa3ce73dff]
    /home/jacob/open64-4.2.1/lib/gcc-lib/x86_64-open64-linux/4.2.1/be.so [0x2afa3ce71edc]
    /lib/libc.so.6(__cxa_finalize+0xb0) [0x2afa3d7e5ab0]
    /home/jacob/open64-4.2.1/lib/gcc-lib/x86_64-open64-linux/4.2.1/be.so [0x2afa3ce1aa53]
openCC INTERNAL ERROR: /home/jacob/open64-4.2.1/lib/gcc-lib/x86_64-open64-linux/4.2.1/be died due to signal 4
make[1]: *** [Release/ReservationDataNodes.lo] Error 1
make[1]: Leaving directory `/home/jacob/srcnew/DataBaseLibrary'
make: *** [dblib] Error 2

Machine: amd64 ubuntu 9

]]> BUG: I/O handling after read past eof http://forums.amd.com/forum/messageview.cfm?catid=373&threadid=114799 2009-06-16T19:53:22 -05.00 tad@altair.com 13 Attempt to write after following code

 1000 read ( lunitqa, 2000, end=3000 ) env
 2000 format(a100)
      goto 1000
 3000 continue

results in following error:

===================
lib-4095 : UNRECOVERABLE library error
  Unable to find error message (check NLSPATH, file lib.cat)

Encountered during a sequential formatted WRITE to unit 13
Fortran unit 13 is connected to a sequential formatted text file:
  "filename"
 Current format:  7000 FORMAT( 1x, a,a,a, i10 )
                            ^
Signal 6 :: SIGABRT
===================

After that the code sits idle, no CPU cycles, but Ctrl-C does not work. Ctrl-Z and kill -9 %1 required to stop.

The above sequence works fine on all platforms: Unix/Linux/Windows/Mac using g77/gfortran and commercial compilers. Even if it is really incorrect usage, the error handling from runtime is unacceptable.

regards

Tadeusz

]]> Performance hit with pthread? http://forums.amd.com/forum/messageview.cfm?catid=373&threadid=114677 2009-06-14T13:22:04 -05.00 edward_yang 5 I was working on a interger program which basically walks a bush (multiple tree) topology and performs SIMD on each node along the way. When not using pthread, opencc results in 5%-10% better performance than gcc 4.2. However, when using pthread, even if only one thread is forked/used, opencc has 40% *lower* performance than gcc 4.2.

Is there some known issues that could be the reason for this? If not, how should I proceed to find out the problem?

Also does opencc accept the data type attribute for memory alignment?

Thanks.

 

]]> __builtin_popcountl() http://forums.amd.com/forum/messageview.cfm?catid=373&threadid=114550 2009-06-11T10:02:20 -05.00 david.cownie@amd.com 3 With gcc 4.3 it puts out a single instriuction

> gcc -march=amdfam10 -O2 -S -o test_popcnt.s  test_popcnt.c
> grep "popcnt" test_popcnt.s
        .file   "test_popcnt.c"
        popcntq (%rdx), %rax
> gcc -march=amdfam10 -O2 -o test_popcnt  test_popcnt.c
dcownie@shanghai:~/cvs/benchmarks/popcount/example> ./test_popcnt
sizeof uint64 is 8
overhead  0.42 secs sum 1966981120
elapsed  0.54 secs sum -1990967296
popcount 0.23 ns elasped  0.12 secs sum -1990967296

But opencc 4.2.2.1 is  putting out the asm sequence - which runs about a factor of ten slower...

> opencc -march=barcelona -O2 -S  -o test_popcnt.s test_popcnt.c
> grep "popcnt" test_popcnt.s
        # Compiling test_popcnt.c (/tmp/ccI#.9GaocO)
        .file   1       "/home/dcownie/cvs/benchmarks/popcount/example/test_popcnt.c"
 #  58    double tstart, elapsed, overhead, rate, ns_per_popcnt;
 #  95        // sum = sum + popcnt (a);
 #  96        // sum = sum + __popcnt64 (a);
 # 129    ns_per_popcnt = (elapsed * (double)1.0E9) / ((double)loops * (double)N);
 # 131    printf ("popcount %4.2f ns elasped  %4.2f secs sum %d\n", ns_per_popcnt, elapsed, (int)sum);
        .ident  "#Open64 Compiler Version 4.2.2.1 : test_popcnt.c compiled with : -O2 -march=barcelona -msse2 -msse3 -mno-3dnow -mno-sse4a -m64"
 
> opencc -march=barcelona -O2 -S  -o test_popcnt test_popcnt.c
> opencc -march=barcelona -O2 -o test_popcnt test_popcnt.c
> ./test_popcnt
sizeof uint64 is 8
overhead  0.18 secs sum 1966981120
elapsed  2.49 secs sum -1990967296
popcount 4.51 ns elasped  2.31 secs sum -1990967296

The asm sequence takes 4.51ns vs 0.23ns for the single instruction

Its not often you can get a factor of ten speedup so adding this to the compiler would be a pleasant (and simple task) !

Also I'd suggest  the -TARGrocssor should follow the gcc convention and use amdfam10 since it is going to be confusing to use -march=barcelona when in fact your processor is now a shanghai or istanbul... so the AMD internal code name should be replaced with the processor family archetecture number (various different processors share the same architecture as describribed in the SWOG - Software Optimization Guide)

(It could recognise both -march=barcelona AND -march=amdfam10 with no loss of current functionality but gently moving to a more logical plan.)

Thanks !

]]> Trying to build statically linked binary with -march=anyx86..... http://forums.amd.com/forum/messageview.cfm?catid=373&threadid=114418 2009-06-08T07:14:34 -05.00 mdoerner 2 Hi All,

 

I'm trying to build a statically linked executible for Engima@Home with -march=anyx86, but fails on the link stage....

 

mdoerner@Linux-QuadZilla:~/Xfers/enigma-suite-0.76> make                                                            
./compile enigma.c                                                                                                  
./compile charmap.c                                                                                                 
./compile cipher.c                                                                                                  
./compile ciphertext.c
./compile date.c
./compile dict.c
./compile display.c
./compile error.c
./compile hillclimb.c
hillclimb.c: In function 'handle_signal':
hillclimb.c:56: warning: unused parameter 'signum'
./compile ic.c
ic.c: In function 'ic_noring':
ic.c:13: warning: unused parameter 'to'
./compile input.c
./compile key.c
./compile result.c
./compile resume_in.c
./compile resume_out.c
./compile scan_int.c
./compile score.c
./compile stecker.c
./load enigma charmap.o cipher.o ciphertext.o date.o dict.o \
        display.o error.o hillclimb.o ic.o input.o key.o result.o \
        resume_in.o resume_out.o scan_int.o score.o stecker.o -lm
"1.I": Warning: Variable anon27 in hillclimb might be used uninitialized
"1.I": Warning: Variable anon27 in hillclimb might be used uninitialized
"1.I": Warning: Variable anon27 in hillclimb might be used uninitialized
"1.I": Warning: Variable anon27 in hillclimb might be used uninitialized
/usr/bin/ld: i386 architecture of input file `/tmp/enigma.ipajV1J6I/1.o' is incompatible with i386:x86-64 output
/usr/bin/ld: i386 architecture of input file `/tmp/enigma.ipajV1J6I/symtab.o' is incompatible with i386:x86-64 output
collect2: ld returned 1 exit status

 

What else to I have to do to get an executible that will run on any flavor of linux and any processor? Thanks.

 

Mike Doerner

]]> gcc x86 intrinsics not working? http://forums.amd.com/forum/messageview.cfm?catid=373&threadid=114371 2009-06-07T01:28:55 -05.00 edward_yang 3 Hi, it appears that openCC does not support gcc's x86 intrinsics. For example, the follow short program would compile under gcc 4.2 or 4.3 but not openCC 4.2.2:

 

#include <stdio.h>
#include <arpa/inet.h>
//#include <xmmintrin.h>

#define LOADDQU __builtin_ia32_loaddqu
#define PCMPEQB __builtin_ia32_pcmpeqb128
#define PMOVMSKB __builtin_ia32_pmovmskb128

typedef uint8_t v128b_t __attribute__ ((vector_size (16)));

int main(int argc, char** argv)
{
register v128b_t input_set1, input_set2;
uint32_t dimem = (uint32_t)*argv[1];
dimem |= (dimem<<8);
dimem |= (dimem<<16);

__asm__ ("movddup %1, %0\n\t"
"movsldup %0, %0"
: "=&x"(input_set1) : "m"(dimem));

input_set2 = LOADDQU(argv[2]);
input_set1 = PCMPEQB(input_set1, input_set2);
dimem = PMOVMSKB(input_set1);

printf("compare result: %04x\n", dimem);
}

 

When trying to compile this using openCC, the following error message occurs:

 

### Assertion failure at line 6468 of ../../be/cg/x8664/expand.cxx:
### Compiler Error in file cmp1x16.cc during Code_Expansion phase:
### Exp_Intrinsic_Op: unsupported intrinsic ((null))
openCC INTERNAL ERROR: /opt/x86_open64-4.2.2.1/lib/gcc-lib/x86_64-open64-linux/4.2.2.1/be returned non-zero status 1

 

Is this normal, or did I install the compiler correctly? Thanks.

 

]]> Open64 4.2.2.1 chokes on -m32 flag http://forums.amd.com/forum/messageview.cfm?catid=373&threadid=114317 2009-06-05T21:54:42 -05.00 mdoerner 3 Hi Guys,

 

I tried recompiling the Enigma@Home app with the new 4.2.2.1 Open64. Works great with the -m64 flag on my 64-bit system. It chokes on the -m32 flag......

mdoerner@Linux-QuadZilla:~/Xfers/enigma-suite-0.76> make -j 4   
( cat warn-auto.sh; \                                           
        echo 'main="$1"; shift'; \                              
        echo exec "`head -1 conf-ld`" \                         
        '-o "$main" "$main".o ${1+"$@"}' \                      
        ) > load                                                
( cat warn-auto.sh; \                                           
        echo exec "`head -1 conf-cc`" '-c ${1+"$@"}' \          
        ) > compile                                             
chmod 755 load                                                  
chmod 755 compile                                               
./compile enigma.c                                              
./compile charmap.c                                             
./compile cipher.c                                              
./compile ciphertext.c                                          
./compile date.c                                                
./compile dict.c                                                
./compile display.c                                             
./compile error.c                                               
./compile hillclimb.c                                           
./compile ic.c                                                  
hillclimb.c: In function 'handle_signal':                       
hillclimb.c:56: warning: unused parameter 'signum'              
./compile input.c                                               
./compile key.c                                                 
ic.c: In function 'ic_noring':                                  
ic.c:13: warning: unused parameter 'to'                         
./compile result.c
./compile resume_in.c
./compile resume_out.c
./compile scan_int.c
./compile score.c
./compile stecker.c
./compile tools/SGT.c -o tools/SGT.o
./load enigma charmap.o cipher.o ciphertext.o date.o dict.o \
        display.o error.o hillclimb.o ic.o input.o key.o result.o \
        resume_in.o resume_out.o scan_int.o score.o stecker.o -lm
./load tools/SGT -lm
/opt/x86_open64-4.2.2.1/lib/gcc-lib/x86_64-open64-linux/4.2.2.1/ipa_link: skipping incompatible /usr/lib64/gcc/x86_64-suse-linux/4.1.2//libgcc.a when searching for -lgcc
/opt/x86_open64-4.2.2.1/lib/gcc-lib/x86_64-open64-linux/4.2.2.1/ipa_link: skipping incompatible /usr/lib64/gcc/x86_64-suse-linux/4.1.2/libgcc.a when searching for -lgcc
/opt/x86_open64-4.2.2.1/lib/gcc-lib/x86_64-open64-linux/4.2.2.1/ipa_link: cannot find -lgcc
opencc INTERNAL ERROR: /opt/x86_open64-4.2.2.1/lib/gcc-lib/x86_64-open64-linux/4.2.2.1/ipa_link returned non-zero status1
make: *** [enigma] Error 1
make: *** Waiting for unfinished jobs....
/opt/x86_open64-4.2.2.1/lib/gcc-lib/x86_64-open64-linux/4.2.2.1/ipa_link: skipping incompatible /usr/lib64/gcc/x86_64-suse-linux/4.1.2//libgcc.a when searching for -lgcc
/opt/x86_open64-4.2.2.1/lib/gcc-lib/x86_64-open64-linux/4.2.2.1/ipa_link: skipping incompatible /usr/lib64/gcc/x86_64-suse-linux/4.1.2/libgcc.a when searching for -lgcc
/opt/x86_open64-4.2.2.1/lib/gcc-lib/x86_64-open64-linux/4.2.2.1/ipa_link: cannot find -lgcc
opencc INTERNAL ERROR: /opt/x86_open64-4.2.2.1/lib/gcc-lib/x86_64-open64-linux/4.2.2.1/ipa_link returned non-zero status1
make: *** [tools/SGT] Error 1
mdoerner@Linux-QuadZilla:~/Xfers/enigma-suite-0.76>

Here how it compiles with -m64 enabled.....

mdoerner@Linux-QuadZilla:~/Xfers/enigma-suite-0.76> make                        
( cat warn-auto.sh; \                                                           
        echo 'main="$1"; shift'; \                                              
        echo exec "`head -1 conf-ld`" \                                         
        '-o "$main" "$main".o ${1+"$@"}' \                                      
        ) > load                                                                
chmod 755 load                                                                  
( cat warn-auto.sh; \                                                           
        echo exec "`head -1 conf-cc`" '-c ${1+"$@"}' \                          
        ) > compile                                                             
chmod 755 compile                                                               
./compile enigma.c                                                              
./compile charmap.c                                                             
./compile cipher.c                                                              
./compile ciphertext.c                                                          
./compile date.c                                                                
./compile dict.c                                                                
./compile display.c                                                             
./compile error.c                                                               
./compile hillclimb.c                                                           
hillclimb.c: In function 'handle_signal':                                       
hillclimb.c:56: warning: unused parameter 'signum'                              
./compile ic.c                                                                  
ic.c: In function 'ic_noring':                                                  
ic.c:13: warning: unused parameter 'to'                                         
./compile input.c                                                               
./compile key.c                                                                 
./compile result.c                                                              
./compile resume_in.c                                                           
./compile resume_out.c                                                          
./compile scan_int.c                                                            
./compile score.c                                                               
./compile stecker.c                                                             
./load enigma charmap.o cipher.o ciphertext.o date.o dict.o \                   
        display.o error.o hillclimb.o ic.o input.o key.o result.o \             
        resume_in.o resume_out.o scan_int.o score.o stecker.o -lm               
"1.I": Warning: Variable anon27 in hillclimb might be used uninitialized        
"1.I": Warning: Variable anon27 in hillclimb might be used uninitialized        
"1.I": Warning: Variable anon27 in hillclimb might be used uninitialized        
"1.I": Warning: Variable anon27 in hillclimb might be used uninitialized        
./compile tools/SGT.c -o tools/SGT.o                                            
./load tools/SGT -lm                                                            
mdoerner@Linux-QuadZilla:~/Xfers/enigma-suite-0.76>

 

command flags are...opencc -Wall -W -Ofast -m32 -march=barcelona and opencc -fomit-frame-pointer -s -m32 -ipa

 

 

FYI this is a OpenSUSE 11.1 system with the RPM version installed (for SUSE Enterprise), I had no issues with 4.2.2. If I have to compile 4.2.2.1 from source, let me know....

 

Mike Doerner

]]> Problems linking my project http://forums.amd.com/forum/messageview.cfm?catid=373&threadid=114100 2009-06-01T07:25:33 -05.00 Calli82 6 Hi,

while linking my shared library for linux, i get this error message. I dont know how to solve this problem. is there any way to track the message to get an idea of what is going wrong? Thank for your advice,

Calli82

 

### Assertion failure at line 1031 of ../../be/cg/x8664/exp_loadstore.cxx:
### Compiler Error in file 2.I during Code_Expansion phase:
### Exp_Ldst: thread-local storage NYI under PIC
opencc INTERNAL ERROR: /home/jars/Desktop/x86_open64-4.2.2/lib/gcc-lib/x86_64-open64-linux/4.2.2/be returned non-zero status 1
make[2]: *** [../../../Test/libNao.AMD.linux.Debug.so.ipajtfy2H/2.o] Fehler 1
make[1]: *** [../../../Test/libNao.AMD.linux.Debug.so] Fehler 2
make: *** [Nao.linux.Library] Fehler 2
Command exited with non-zero status 2

]]> Open64 and ACML http://forums.amd.com/forum/messageview.cfm?catid=373&threadid=114006 2009-05-29T16:42:45 -05.00 jdmccalpin 11 Is there a preferred version of ACML for the Open64 compilers?

The AMD Open64 compiler web pages just say to "download ACML", but it is not clear if any of these are compatible?

I tried the gfortran version first, which filled libacml.a with lots of gfortran internal routines that openf90 could not find. 

Recommendations?

]]> Aggressive Optimizations http://forums.amd.com/forum/messageview.cfm?catid=373&threadid=113910 2009-05-27T11:39:41 -05.00 Calli82 2 Hi,

i would like to compile a shared library for an embedded system with Geode processor (32bit). There are hundreds of optimization flags in gcc and AMD x86 Open 64 Compiler Suite. Which options would be effective behind -Ofast in AMD CS? Is it actually useful to compile for the geode with the AMD CS instead of gcc?

Thank you for your opinions.

Calli82

]]> BUG: Open64 chokes when -march=wolfdale is specified...Intel and AMD processors http://forums.amd.com/forum/messageview.cfm?catid=373&threadid=113849 2009-05-25T18:18:55 -05.00 mdoerner 4 Howdy All,

 

When using the opencc command, several guys at the Enigma@Home BOINC site have tried to compile our app using -march=wolfdale and keep getting a bogus error at the linking stage that our processors do not support SSE2 instructions. For example....

 

mdoerner@Linux-QuadZilla:~/Xfers/enigma-suite-0.76> make        
( cat warn-auto.sh; \                                           
        echo 'main="$1"; shift'; \                              
        echo exec "`head -1 conf-ld`" \                         
        '-o "$main" "$main".o ${1+"$@"}' \                      
        ) > load                                                
chmod 755 load                                                  
( cat warn-auto.sh; \                                           
        echo exec "`head -1 conf-cc`" '-c ${1+"$@"}' \          
        ) > compile                                             
chmod 755 compile
./compile enigma.c
./compile charmap.c
./compile cipher.c
./compile ciphertext.c
./compile date.c
./compile dict.c
./compile display.c
./compile error.c
./compile hillclimb.c
hillclimb.c: In function 'handle_signal':
hillclimb.c:56: warning: unused parameter 'signum'
./compile ic.c
ic.c: In function 'ic_noring':
ic.c:13: warning: unused parameter 'to'
./compile input.c
./compile key.c
./compile result.c
./compile resume_in.c
./compile resume_out.c
./compile scan_int.c
./compile score.c
./compile stecker.c
./load enigma charmap.o cipher.o ciphertext.o date.o dict.o \
        display.o error.o hillclimb.o ic.o input.o key.o result.o \
        resume_in.o resume_out.o scan_int.o score.o stecker.o -lm
opencc ERROR: Target processor does not support SSE2.
make[1]: *** [/tmp/enigma.ipaCaLnH5/dummy] Error 2
make: *** [enigma] Error 2
mdoerner@Linux-QuadZilla:~/Xfers/enigma-suite-0.76>

 

This code had been tried on AMD Phenom and Intel Q6600, E7200, and E5200 (all support SSE2 instructions). This has been compiled successfully with the other architecture flags set without issue (i.e. core, barcelona, athlon64, etc all work). Please let me know if this is a bug or something we're doing wrong.

 

Compiled with: opencc -Wall -W -Ofast -m64 -march=wolfdale

Linked With: opencc -fomit-frame-pointer -s -m64 -ipa

 

Mike Doerner

]]> OpenMP on 64-bit linux and fPIC http://forums.amd.com/forum/messageview.cfm?catid=373&threadid=113409 2009-05-16T22:14:16 -05.00 rahulgarg 12 I am on 64-bit Ubuntu Linux 8.10 and using the binaries downloaded from the AMD website (x86_open64-4.2.2-1.x86_64.tar.bz2). The default linker (/usr/bin/ld) on my system is from GCC v4.3.2.

I am trying to compile a shared library which contains OpenMP declarations.

opencc -fopenmp myfile.c -shared -o myfile.so -lexternal_library -fPIC

I get the following error:

/usr/bin/ld: /home/rahul/open64/x86_open64-4.2.2//lib/gcc-lib/x86_64-open64-linux/4.2.2/libopenmp.a(omp_runtime.o): relocation R_X86_64_32S against `a local symbol' can not be used when making a shared object; recompile with -fPIC

Any hints/ideas/solutions?

 

 

]]> openf90-4.2.2: Segfaults, but with ifort the program runs well http://forums.amd.com/forum/messageview.cfm?catid=373&threadid=112984 2009-05-07T10:06:34 -05.00 sangamesh 8 Hi,

  On an AMD processor (dual core, dual processor) on Cent OS Linux 5 (Rocks 5), with x86 open64-4.2.2, the fortran program compiles fine but fails to run with the error "Segmentation Fault". But it works well with Intel Fortran compiler.



# make -f makefile 
openf90 -c -O3 MAIN.f
openf90 -c -O3 coef.f
openf90 -c -O3 initial_conditions.f
openf90 -c -O3 collide.f
openf90 -c -O3 interpolate.f
openf90 -c -O3 boundary_update.f
openf90 -c -O3 int_boundary_update.f
openf90 -c -O3 write_binary.f
openf90 -c -O3 read_binary.f
openf90 -c -O3 plotter.f
opencc -c -O3 test_for_nan.c
openf90 -O3 MAIN.o coef.o initial_conditions.o collide.o interpolate.o boundary_update.o int_boundary_update.o write_binary.o read_binary.o plotter.o test_for_nan.o -o a.out -lm
# ./a.out 
 Re = 140.
 Tau = 0.585714281
 Program Begins.....
Segmentation fault
#
 

The makefile is:

# cat makefile 
FLAGS = -O3 
MP_FLAGS = -lm
OBJECTS = MAIN.o coef.o initial_conditions.o collide.o interpolate.o boundary_update.o int_boundary_update.o write_binary.o read_binary.o plotter.o test_for_nan.o
a.out: $(OBJECTS)
  openf90 $(FLAGS) $(OBJECTS) -o $@ $(MP_FLAGS)
.f.o: header array_sizes $@ 
  openf90 -c $(FLAGS) $<
.c.o: $@
  opencc -c $(FLAGS) $<

cleanall:
  -rm *.o
  -rm *.dat
  -rm *.bin
  -rm a.out

What's the wrong here? and how to resolve it?

]]> Open64 for windows http://forums.amd.com/forum/messageview.cfm?catid=373&threadid=112797 2009-05-03T08:33:28 -05.00 zbotto 7 hello, the new x86 open64 compiler suite sounds awesome. but sadly it's only for linux right now, is there a windows port planned?

]]> library names http://forums.amd.com/forum/messageview.cfm?catid=373&threadid=112650 2009-04-30T02:30:30 -05.00 sangamesh 5 Hello,

The x86 open64 compilers are installed from source package on Cent OS 5.

Found that names of some library (.so) files, doesn't start with "lib" as simple.

Ex:

# ls /opt/open64-4.2.2/lib/gcc-lib/x86_64-open64-linux/4.2.2/
core.so
em64t.so
ipa.so                
opteron.so 
whirl2c.so
barcelona.so 
ipl.so
be.so
lno.so
whirl2f.so
... etc

why so? Are not these libraries?
In case if they are, how to link them?

One more issue: The fortran compiler is not working

# openf90 sample.f -o sample
/usr/bin/ld: cannot find -lfortran
collect2: ld returned 1 exit status
#

Does open64 require any Fortan base libraries before install?

Thanks in advance

]]> Open64: How'd AMD get involved? http://forums.amd.com/forum/messageview.cfm?catid=373&threadid=112644 2009-04-29T22:14:38 -05.00 mdoerner 6 Hi All,

 

I noticed that Open64 is now on AMD's web site (v4.2.2) instead of the www.open64.net web site (which only has 4.2.1). How did AMD get involved with the Open64 project? Does AMD's "hosting" of v4.2.2 mean they're now the administrator's of the project? Just curious.

Mike Doerner

PS I used opencc 4.2.2 for a program on Enigma@Home project, and got about 20% better performance than the gcc compiled version (4.3.2). Now I can come close to Intel Core 2 Duo performance in integer calcs with my Phenom.

 

PPS Here's the link one Enigma@Home showing the performace gain against gcc 32-bit PIII code, and my own gcc 4.3.2 code optimized for Phenom 64-bit.

http://www.enigmaathome.net/forum_thread.php?id=106

]]>