| |
NERSC Announcements Message Archive
Select:
[all-announcements]
[users]
[franklin]
[bassi]
[jacquard]
[davinci]
[nug]
[managers]
[ Back ]
| Subject: |
Jacquard Pathscale compilers to be updated on 12/15/05 |
| Author: |
Mike Stewart <pmstewart_at_lbl.gov> |
| Date: |
2005-12-08 08:35:09 |
| The default version of the Pathscale compilers on Jacquard will be
upgraded from version 2.2.1 to 2.3 on Thursday, 12/15/05.
This is a bugfix release which includes fixes to several NERSC reported
problems, and can performance improvements in some codes.
This version can be used now by loading the path/2.3 module:
module swap path path/2.3
If you experience any problems with this compiler or if the performance
of any application deteriorates when recompiled with this version,
please report this with details to consult@nersc.gov.
Attached are the release notes for this version.
--
=========================
Michael Stewart
Consultant
NERSC User Services Group
510-486-6648
pmstewart@lbl.gov
=========================
Release Notes: PathScale EKOPath Compiler Suite - Release 2.3
=============================================================
Copyright 2002, 2003, 2004, 2005 PathScale, Inc. All Rights Reserved.
Thank you for purchasing the PathScale EKOPath Compiler Suite. This file
describes new features, bugs fixed, and known issues with the
PathScale EKOPath Compiler Suite. Where possible, we provide workarounds
for known problems.
Support & contact information
-----------------------------
To report bugs, or for more information, send an email message to
support@pathscale.com.
Please report problems the first time you encounter them, even if
they are listed here as known issues. Knowing who has encountered a
bug helps us prioritize the bugs we know about.
New Features in 2.3
-------------------
* Support for Autoparallelization. Refer to section 8 of the PathScale
EKOPath Compiler Suite User Guide for more information.
* Improved Fortran debugging. (Improved DWARF generation)
* Improvements in performance on various customer applications
* This release has been tested on the following Linux distributions:
RedHat Fedora Core 2
RedHat Fedora Core 3
RedHat Enterprise Linux 3
RedHat Enterprise Linux 4
SUSE Linux Enterprise Server 8
SUSE Linux Enterprise Server 9
SUSE Professional 9.2
SUSE Professional 9.3
Fedora Core 4 there are two known bugs with Fedora Core 4 that
prevent us from fully supporting it. We do plan to resolve
these issues and support Fedora Core 4 in a future release.
There are known issues with the C++ compiler (pathCC).
The IPA bug noted in previous releases is believed to be
addressed. However, we have only performed limited testing
at this point.
Fortran programs and stack size
-------------------------------
The compiler normally allocates data for Fortran programs on the stack
for best performance. Some Linux distributions limit the default stack
size to a value low enough that many Fortran programs will crash
immediately after they begin to run. The Fortran runtime will
automatically attempt to work around these limits if it detects them.
However, for some 32-bit apps it appears that very large stack sizes
ignored and can result in stack overflow messages. In these cases,
setting the stack size to a smaller value (eg. 8192) may allow the
program to run. (This is being investigated internally and has the
bug number 7641.)
Fortran Preprocessor default changed
------------------------------------
Starting with the 2.1 release, the default preprocessor used by
Fortran for files that us .F, .F90, or .F95 extensions has now been
changed to the C preprocessor, cpp, from the Fortran preprocessor,
ftpp.
The Fortran preprocessor can be invoked by using the option '-ftpp'
when compiling the code.
Use of system headers and libraries
-----------------------------------
Past releases of the PathScale EKOPath Compiler Suite have provided a
set of system libraries and headers. Doing this has caused some users
to experience problems. Starting with this release, the compiler relies
on the system's headers and libraries.
As a result, users will no longer be able to build 64-bit applications
on systems that only have 32-bit development environments installed.
Known issues and workarounds
=============================
C/C++
-----
At this time the PathScale C & C++ compilers are based on the GCC
3.3 front end. With a few exceptions we have not enhanced the front
ends to support features present in the newer GCC 3.4 and 4.0
compilers. (The exceptions include some builtins and macros to
allow us to support more recent Linux releases.)
The front ends used by these compilers will be updated in a future
release.
OpenMP
------
Functionality
- - - - - - -
The C++ OpenMP support is limited and does not support OpenMP
directives in C++ source that use exceptions, classes or templates.
(We have found some codes with very simplistic use of classes may
work.)
Thread Stack Size
- - - - - - - - -
Typically the per-thread stack size limit is 2MB for 2.4.* kernels
using linuxthreads and 64MB for 2.6.* kernels using NPTL, but these
maximums may vary according to your Linux distribution. Please contact
your O/S vendor for specific details.
Installation
------------
The PathScale EKOPath Compiler Suite is a 32-bit program, and requires
a 32-bit execution environment to run. We have found that some users
do not have the 32-bit environment installed on their system resulting
in the inability of the compiler to run. This tends to be a problem
only on systems where the non-root tar installation is used or where
"--force" is used to install the RPMs.
RPM Installation on SUSE 9.2, 9.3, SLES 8, and SLES 9
- - - - - - - - - - - - - - - - - - - - - - - - - - -
On the SUSE Linux distributions, RPM may report that no package provides
ld-linux-x86-64.so.2 when that is not the case. (This library is provided
by the glibc RPM.) This is a bug in the version of RPM distributed with
the specified SUSE environments.
Installing multiple versions on the same system:
------------------------------------------------
Systems with multiple versions of the PathScale compiler, using the
RPMs may receive the following message when they try to execute their
application built with the 2.3 release of the PathScale EKO Compiler
Suite:
./a.out: relocation error: ./a.out: symbol memset.pathscale.opteron,
version LIBPSCRT_1.0 not defined in file libpscrt.so.1 with link time
reference
The problem is the 2.3 release is expecting new symbols to be resolved
by one of the runtime libraries are not in older versions of that library.
When installation is done using the RPMs the system /etc/ld.so.conf is
appended with:
<install_dir>/lib/2.3/32
<install_dir>/lib/2.3
If multiple installations exist on this system, the ld.so.conf will
contain entries for each of the releases in the order that they were
installed:
/export/pathscale_alt_1.3/lib/1.3/32
/export/pathscale_alt_1.3/lib/1.3
/export/pathscale_alt_2.3/lib/2.3/32
/export/pathscale_alt_2.3/lib/2.3
When the application is executed, it will find the shared library in
the older directory ( in the above case) which does not have the
necessary symbols in it and that will result in some form of the above
error message.
Workarounds:
- - - - - -
1. Update /etc/ld.so.conf removing all entries pointing to older,
installed versions of the compiler suite.
The fix is to edit the file /etc/ld.so.conf (as root) and remove
some lines. It'll look something like this:
$ cat /etc/ld.so.conf
/usr/X11R6/lib64
/usr/lib64/qt-3.1/lib
/usr/X11R6/lib
/usr/lib/qt-3.1/lib
/opt/pathscale/lib/1.3/32 <=== remove this
/opt/pathscale/lib/1.3 <=== remove this
/opt/pathscale/lib/2.3/32 <=== keep this
/opt/pathscale/lib/2.3 <=== keep this
You then need to let the system know about this reconfiguration
by running (as root):
# /sbin/ldconfig
2. Uninstall the older versions of the compiler suite. (This way,
older versions of the library will not be found and it will resolve
to the most recent version. )
Some of the bugs fixed between 2.2.1 and 2.3:
[Bug 902] Fortran95: Intrinsic RANDOM_NUMBER should not be PURE
[Bug 934] Fortran applies incorrect constraints to PURE functions
[Bug 3507] Debugging Fortran that uses the "USE" statement
[Bug 4232] Intrinsics and statement functions
[Bug 5019] Fortran: Some intrinsic procedures are not thread-safe.
[Bug 6075] pathf90 - OpenMP directives containing named common blocks
[Bug 7630] C++ front-end goes into infinite loop
[Bug 7727] Assembler messages:attempt to .org/.space backwards? (-4)
[Bug 7792] pathCC fails to call copy constructor on initialization
[Bug 7801] Shared library passed to IPA generates bad executable
[Bug 7805] code with large common block segfaults at runtime
[Bug 7814] program returns incorrect results at -O2
[Bug 7822] OMP Seg fault message wrong
[Bug 7825] pathCC compilation fails with error: junk (%rdi)1 after expression
[Bug 7834] Document how to set NLSPATH
[Bug 7842] pathcc incorrectly compiles non-ANSI-compliant static function declaration
[Bug 7845] app segfaults when compiled at -O3
[Bug 7858] program segfaults when compiled at -O2
[Bug 7859] program returns incorrect results at all optimization levels
[Bug 7862] undefined reference to `f(int)' when -ipa
[Bug 7866] error to link shared library
[Bug 7835] <<<Fortran>>>: anint gets wrong answers at extremely high optimizations
[Bug 7871] test fails with -ipa; passes with -inline off
[Bug 7879] error from -ipa -g combined
[Bug 7916] pathf90 at -O2 - Compiler Error during Code_Expansion phase - NYI: Pick_Load_Instruction mtype
[Bug 7920] the '-show-defaults' option returns invalid flags
[Bug 7976] fails during "make check"
[Bug 7977] pathf90 : -fullwarn does not appear to work when -cpp is also an option on the compile line
[Bug 7990] pathf90 - code segfaults at -O0
[Bug 7995] program aborts at -O3; passes if -O3 -INLINE:=off
[Bug 8017] failures with -CG:min_stack_size=on
[Bug 8029] pathf90 using both -cpp and -ansi produces a compilation error
[Bug 8045] Segmentation fault in Global Opt
[Bug 8046] pathf90 does not handle properly arrays in namelist
[Bug 8058] .preg_I4 reference generated when compiling at -O3
[Bug 8062] incorrect runtime results with -m32
[Bug 8063] compilers fail when -ipa and TMPDIR exists
[Bug 8064] Segmentation fault in phase Code_Expansion when -O3
[Bug 8065] incorrect runtime results with -m32 -O2 -ipa
[Bug 8105] pathf95 gives unexpected runtime error
[Bug 8115] Linking fortran that uses libpathfortran with -static fails
[Bug 8128] pathf90 compilation fails with Signal Segmentation fault in phase Code_Expansion
[Bug 8130] pathcc - IPA incompatible with -fprofile-arcs
[Bug 8143] pathcc - compilation fails with Invalid return mtype V8I4 encountered
[Bug 8149] undefined ref. error occurs when link two objects built with and without -g
[Bug 8151] pathcc: compiler fails with Segmentation fault in Writing WHIRL file phase
[Bug 8155] test fails with pathCC -O3
[Bug 8165] pathf95 - compiler fails with Segmentation fault in IR->WHIRL Conversion phase
[Bug 8174] pathf90 at -O3 has extremely long compile time
[Bug 8180] Support x87 code generation when SSE is in effect
[Bug 8195] pathcc - compilation fails with unexpected mtype for intrinsic 'pow'
[Bug 8198] Program segfaults with -O3 -ipa
[Bug 8224] openMP Fortran - NN is declared as PRIVATE while the compiler claims NN is SHARED
[Bug 8229] application built with pathcc dies in initialization
[Bug 8237] Performance improvements with customer code
[Bug 8251] Assertion failure while handling fcos/fsin
[Bug 8258] pathf95 i/o failure
[Bug 8260] pathf95 syntax error in CHARACTER CH*40(5)
[Bug 8272] pathf95 incorrect runtime results
[Bug 8279] pathf95 - lack of a newline at the end of a file returns an invalid value
[Bug 8284] pathf95 - FDO seg. fault during the second compilation phase (-fb_opt)
[Bug 8287] pathf90 - openmp: unexpected error Variable "X" must have its data scope explicitly declared because DEFAULT(NONE) was specified.
[Bug 8290] address fault with -m32
[Bug 8391] pathf90 - using the ASSIGN function results into undefined reference to `assign_'
Known issues in 2.3:
[Bug 572] F95: Cannot use derived types with pointers as constants (parameters)
[Bug 1297] C: nested functions not supported
[Bug 1316] F77: %loc extension not supported
[Bug 1320] Fortran: some kinds of variable alignment are not supported
[Bug 2312] IPA: linking may fail if filenames contain shell metacharacters
[Bug 2395] The implementation of __builtin_return_address is not complete.
[Bug 2446] IPA linker does not handle .a files containing IPA .o files correctly
[Bug 2509] Control of floating-point trapping behavior
[Bug 2809] C: compiler handles unspecified array sizes incorrectly
[Bug 2896] Some fast math routines are only available in the static math library
[Bug 3830] C: Incomplete debug information in nested lexical scopes
[Bug 4374] IPA: "make: warning: Clock skew detected.
[Bug 4433] pathf90: Fortran programs without a "main" will appear to successfully link.
[Bug 4886] libstdc++ version support
[Bug 5090] Fortran OpenMP: statically nested parallel constructs not supported.
[Bug 5195] C OpenMP FIRSTPRIVATE and LASTPRIVATE on same variable for PARALLEL DO
[Bug 5441] pathcc/pathCC: Do not support GCC thread local storage
[Bug 5443] SLES 8 linker may emit errors about truncated relocations.
[Bug 5571] pathCC: Inlining in the C++ front end.
[Bug 5828] Profiling 64-bit OpenMP applications.
[Bug 5882] OpenMP: Serial version of a parallel region is not localizing "private" variables.
[Bug 5885] pathCC: GCC 3.4 enhanced support of attributes.
[Bug 5952] pathf90: On 32-bit the logic to automatically set stack size may not work
[Bug 6236] pathf90: The Fortran compiler currently does not support IEEE intrinsics
[Bug 6244] Using -zerouv causes the application to crash.
[Bug 6259] pathf90: Restricted expressions use Fortran 90 rules.
[Bug 7387] Certain structure-constructors corrupt memory during compilation
[Bug 7728] Inline assembly '=A' contraint not supported
[Bug 2446] IPA linker does not handle .a files containing IPA .o files correctly
The IPA linker attempts to correctly handle archive files containing .o
files compiled with -ipa, but this support is not complete. While a
regular linker will only use .o files that export needed symbols, the
IPA linker uses all .o files inside the archive, which can often lead to
undefined symbol errors.
To work around this, extract the .o files you need from the .a file, and
link explicitly against those files.
[Bug 2809] C: compiler handles unspecified array sizes incorrectly
If the compiler encounters C code that uses ISO C99 initializers to
initialize an array of flexible size, it will generate assembly code
that causes the assembler to issue an "attempt to move .org
backwards" error.
An example of this syntax usage is as follows:
> struct K {
> int i;
> int f[];
> };
> struct K a = {
> 9,
> { 1, 4, 5 }
> };
> struct K b = {
> 9,
> { 1, 4, 5, 12, 14,9,0,9 }
> };
A workaround is to specify a size in the array declaration.
[Bug 4886] libstdc++ version support
The current EKOPath C++ compiler will work with libstdc++ 3.4 if and
only if the corresponding GCC 3.4 is installed. That restriction exists
because that version of the library relies on built-in numeric constants
which are introduced in the preprocessor starting with GCC 3.4. The
constants are:
> __FLT_HAS_INFINITY__
> __FLT_HAS_QUIET_NAN__
> __DBL_HAS_INFINITY__
> __DBL_HAS_QUIET_NAN__
> __LDBL_HAS_INFINITY__
> __LDBL_HAS_QUIET_NAN__
The EKOPath C++ compiler uses the installed GCC preprocessor.
Alternatively, install libstdc++ 3.3.
[Bug 2509] Control of floating-point trapping behavior
The EKOpath compilers support the following options for controlling
floating-point traps:
> -TENV:X=(0..4)
> Specify the level of enabled exceptions that will be
> assumed for purposes of performing speculative code
> motion (default is level 1 at all optimization levels)
> In general, an instruction will not be speculated (i.e.
> moved above a branch by the optimizer) unless any
> exceptions it might cause are disabled by this option.
>
> Level 0 - No speculative code motion may be performed.
>
> Level 1 - Safe speculative code motion may be performed,
> with IEEE-754 underflow and inexact exceptions
> disabled.
>
> Level 2 - All IEEE-754 exceptions are disabled except
> divide by zero.
>
> Level 3 - All IEEE-754 exceptions are disabled including
> divide by zero.
>
> Level 4 - Memory exceptions may be disabled or ignored.
>
> -TENV:simd_imask=(ON|OFF)
> Default is ON. Turning it OFF unmasks SIMD floating-point
> invalid-operation exception.
>
> -TENV:simd_dmask=(ON|OFF)
> Default is ON. Turning it OFF unmasks SIMD floating-point
> denormalized-operand exception.
>
> -TENV:simd_zmask=(ON|OFF)
> Default is ON. Turning it OFF unmasks SIMD floating-point
> zero-divide exception.
>
> -TENV:simd_omask=(ON|OFF)
> Default is ON. Turning it OFF unmasks SIMD floating-point
> overflow exception.
>
> -TENV:simd_umask=(ON|OFF)
> Default is ON. Turning it OFF unmasks SIMD floating-point
> underflow exception.
>
> -TENV:simd_pmask=(ON|OFF)
> Default is ON. Turning it OFF unmasks SIMD floating-point
> precision exception.
[Bug 6236] pathf90: The Fortran compiler currently does not support IEEE intrinsics
The current release of the Fortran compiler does not implement the IEEE
floating point intrinsics:
> clear_ieee_exception
> disable_ieee_exception
> enable_ieee_exception
> get_ieee_exception
> get_ieee_interrupts
> get_ieee_rounding_mode
> get_ieee_status
> ieee_class
> ieee_next_after
> ieee_unordered
> set_ieee_exception
> set_ieee_exceptions
> set_ieee_interrupts
> set_ieee_rounding_mode
> set_ieee_status
> test_ieee_exception
> test_ieee_interrupt
[Bug 1297] C: nested functions not supported
The gcc C language extension of nested functions (functions defined
inside other functions) is not currently supported.
[Bug 5885] pathCC: GCC 3.4 enhanced support of attributes.
The most recent version of pathCC has been enhanced to support some
attributes and built-ins that are not supported by GCC 3.3 compilers.
However, there are some forms that are not yet supported. For example,
GCC 3.4 allows the user to specify an attribute on an identifier before
the identifier is declared:
> template <class T>
> struct my_type
> {
> void fn()
> {
> T foo __attribute__ ((__unused__)) (bar);
> }
> typename T::nested_T bar;
> };
Workaround: None
[Bug 2312] IPA: linking may fail if filenames contain shell metacharacters
The IPA linker may produce strange error messages and fail to link if a
file name passed to it contains a shell or "make" metacharacter. The
list of characters to avoid is as follows: ;:$()[]{}<>%
[Bug 2395] The implementation of __builtin_return_address is not complete.
The current implementation of __builtin_return_address appears to only
work correctly for an argument of 0.
[Bug 2896] Some fast math routines are only available in the static math library
Some high-performance standard math library routines (single- and
double-precision versions of pow, fmin, fmax, finite, and copysign) are
only available in the static version of the math library (libmpath) that
we ship. In order to benefit from these faster routines, you should link
explicitly against the static version of the math library.
You can find out the location of this library using the following
command:
> pathcc -print-file-name=libmpath.a
The static version of the math library is faster in general than the
shared version. You should always use it if you want the highest
floating point performance.
[Bug 4374] IPA: "make: warning: Clock skew detected.
You may receive a "make: warning: Clock skew detected. Your build may be
incomplete." message when compiling with the '-ipa' option using a
remote file system such as NFS for the build directory.
The '-ipa' option currently uses the 'make' command which can be
sensitive to the differences in system clock between the system where
the compilation is taking place and the file server.
Clock skew will not affect the success of your build, but you can avoid
the warning by ensuring that the system times of the file server and the
build server are synchronized.
[Bug 4924] How to change all files to big-endian format
Because sequential unformatted files contain record headers but direct
unformatted files do not, one must use two separate "assign" commands
together to change all files to big-endian format. The commands are:
assign -F f77.mips -N mips g:su assign -I -N mips g:du
[Bug 5090] Fortran OpenMP: statically nested parallel constructs not supported.
The compiler does not support statically nested parallel constructs.
Such constructs may cause compilation or runtime failure.
For example, the following is not supported:
!$OMP PARALLEL $OMP PARALLEL $OMP END PARALLEL $OMP END PARALLEL
[Bug 5195] C OpenMP FIRSTPRIVATE and LASTPRIVATE on same variable for PARALLEL DO
The current implementation of OpenMP in the C compiler does not support
FIRSTPRIVATE and LASTPRIVATE on same variable for PARALLEL DO. The
compiler will issue the following error if this is encountered:
> Error: FIRSTPRIVATE and LASTPRIVATE on same variable not
> yet implemented for PARALLEL DO
[Bug 5441] pathcc/pathCC: Do not support GCC thread local storage
The current C and C++ compilers do not have support for Thread Local
Storage extensions that GCC supports.
Workaround: Rewrite code not to use thread local storage.
[Bug 5571] pathCC: Inlining in the C++ front end.
The g++ 3.3 front end implements extremely aggressive inlining. We have
found that the increase in code size caused by this inlining may cause
the compiler's back end to have excessively long run times. As a result,
the default is to allow the compiler's back end to do the inlining by
turning off inlining in the C++ front end.
In most cases the back end inlining does as well if not better than the
C++ front end. In some rare cases, allowing the C++ front end to do the
inlining does result in a faster executable. (This is typically true in
cases where g++ produces faster runtimes than pathCC.)
To turn on front end inlining use the -finline option. (NOTE: This
option may go away in a future release.)
If that does result in better performance for your application,
please report it to PathScale support so we can further refine the
back end inlining.
[Bug 5828] Profiling 64-bit OpenMP applications.
64-bit OpenMP applications built with profiling turned on may generate a
segmentation fault when run. If you run the application under a
debugger, the segmentation fault may look something like:
> Program received signal SIGSEGV, Segmentation fault.
> 0x0000000000431743 in _dl_allocate_tls_init ()
This does not occur when the program is compiled with -static or -m32.
Workaround: Link the program using the '-static' option.
[Bug 5882] OpenMP: Serial version of a parallel region is not localizing "private" variables.
The current OpenMP implementation may not create copies of private
variables in parallel regions in the single threaded case as required by
the OpenMP standard.
Workaround: Define the following environment variables:
> export PSC_OMP_SILENT=1
> export PSC_OMP_SERIAL_OUTLINE=1
[Bug 5952] pathf90: On 32-bit the logic to automatically set stack size may not work
For 32-bit applications the logic described in section 3.10 of the User
Guide may not work as documented. If the application aborts during
execution try setting the stack size to a large value or unlimited and
see if that resolves the issue.
Workaround: Set the stack size to unlimited before running the
application:
> ulimit -s unlimited
[Bug 6244] Using -zerouv causes the application to crash.
We recommend running the application with -trapuv and -Wuninitialized to
help identify and fix the uninitialized variables. The application may
be using an uninitialized variable that just happens to be non-zero most
of the time. The use of -zerouv is causing the uninitialized variable to
be zero resulting in the application crashing.
[Bug 6259] pathf90: Restricted expressions use Fortran 90 rules.
The current Fortran compiler implements the rules for restricted
expressions in accordance with the Fortran 90 standard. As a result,
some valid Fortran 95 programs that rely on the broader definition of
restricted expressions may generate errors when compiled with pathf90.
[Bug 572] F95: Cannot use derived types with pointers as constants (parameters)
If a derived type contains a pointer, it cannot be used as a constant,
even if the initializer for the pointer field is NULL()
Workaround: None.
[Bug 3830] C: Incomplete debug information in nested lexical scopes
The compiler omits the necessary debugging output for enabling the
debugger to differentiate between variables with identical names in
nested lexical scopes.
For example:
> void foo() {
> int i = 0 ;
> { int i = 1 ;
> { int i = 2 ;
> }
> }
> }
A debugger will not be able to tell the difference between the three
variables called 'i'.
[Bug 1316] F77: %loc extension not supported
The F77 %loc directive, which returns the address of a variable, is
implemented by some Fortran compilers such as g77, but not yet by the
PathScale compiler.
[Bug 1320] Fortran: some kinds of variable alignment are not supported
Given a Fortran program fragment like this:
> character c(11)
> real r
> equivalence (r,c(2))
The intention of the fragment is that the variable c should start on a
7-byte alignment, i.e. that c(2) should be aligned with r. This is not
standard Fortran, but is an extension supported by some Fortran
compilers, e.g. g77.
The PathScale Fortran compiler does not currently support this kind of
alignment requirement, and will issue a compilation error.
[Bug 4433] pathf90: Fortran programs without a "main" will appear to successfully link.
Fortran programs that do not provide a "main" entry point will appear to
successfully link but will fail at runtime with the following message:
> $ ./a.out
> Someone linked a Fortran program with no MAIN__!
Workaround: Provide a main program.
[Bug 5443] SLES 8 linker may emit errors about truncated relocations.
Some tests have been identified where the SLES 8 linker emits errors
while linking 64-bit object files:
myfile.o(.text+0x136): relocation truncated to fit: R_X86_64_32S
myvariable
This problem is not seen on SLES 9.
Workaround: A possible workaround is
-mcmodel=medium
[Bug 7387] Certain structure-constructors corrupt memory during compilation
If a member of a derived type A is a pointer to a derived type B, and
the source program contains a structure-constructor for type A, the
compiler miscalculates the size of type A and corrupts memory, usually
causing the compiler to crash. A workaround is to eliminate the
structure-constructor in favor of separate assignments to components of
the derived type. For example, if the type A is:
type A integer i type(B) pb end type A
then a structure-constructor like this:
type(A) :: avar = A(5, null())
could be replaced by:
type(A) :: avar ... avar%i = 5 nullify(avar%pb)
[Bug 7728] Inline assembly '=A' contraint not supported
The =A constraint indicates that both eax and edx are used to hold a
64-bit value. This allows the 64-bit value to be propagated to ret
without having to build it up from two 32-bit parts.
The current EKOPath compilers do not implement this constraint
correctly.
|
|
