We are currently running with an issue, using Pro64 Fortran compiler with
"-O[1-3]" optimization levels, where the code generated appear to use
earlier defined as "output" (as per the "Register Stack Engine" feature and
its related "alloc" instruction) registers as "local"/scratch ones and this
just prior a call to an underlying subroutine which then bombs due to its
use/assumption about the validity of its corresponding "input"
parameters/registers.
This type/number of call/arguments is quite usual within the application and
this problem seem to only happen in one very special case :
_ 84 formal parameters to be passed between caller and callee.
_ some of these parameters/variables, and at least the one concerned
by the pb, have simply been already passed and received from the previous
caller and not used in the current and intermediate one but simply passed to
the next callees/routines.
_ this only happen for the second and different routine call from
the same caller, and this with about the same number of arguments, where a
lot are also identical between both different routines calls and mainly the
one finally causing the crash/problem in the second callee !! This
particular comment/case may be the trick where the compiler might correctly
prepare the concerned argument for the first callee and then forget to
keep/save it for the next/2nd callee.
The only way to avoid such behavior has been to compile the "calling"
routine/module with "-O0" option.
Are there any known current limitations/issues regarding the number of
arguments to be passed between subroutines and related to the "Register
Stack Engine" feature ??
Seems also, and according to some other assembly code calling sequences
generated by Pro64 Fortan compiler, that there is a default minimum (8 ?)
numbers of formal parameters to be passed thru the "Register Stack Engine",
is this true ??
Is there also any possibility/option to explicitelly avoid the "Register
Stack Engine" usage by Pro64 compilers ??
Will try to provide a test-case, or at least some debugging and generated
assembly code snapshots to better document this problem asap, but already
thank's for any help, idea or answer.
Best Regards.
Bruno.
Bruno Faccini - Tech. Mktg. Engr.
Technical Marketing/Internet Solutions Group (EMEA)
Intel GmbH, Germany
Phone (Intel office): +33-(0)146947228
Fax: +33-(0)146947068
email: bruno.faccini@xxxxxxxxx
<<Bruno Faccini (E-mail).vcf>>
Bruno Faccini (E-mail).vcf
Description: Binary data
|