Fortran - "little trouble" with REAL(16) precision

Author

"little trouble" with REAL(16) precision

zeman@netvisao.pt

2004-07-20, 8:58 pm

Dear all

I'm just a newby in high precision floating point but an answer to
this "simple" question would help me so much in the further
developments.

When I run a simple code using 64 bit precison (in a Itanium with
Intel Fortran 90 compilator) a runtime error message appears:

unaligned access

The code can be very simple like

REAL a(20)
a(1)=1.0
print*, a(1)

and it was compiled with the -r16 option.

I found out that the error message arises from the usage of an array.
if 'a' is just a real the code goes fine.

I have read a lot of material, including compilator manuals, and the
problem remains. So, I would be very greatful if someone could tell me
something about it.

Best regards
ZF

Gerry Thomas

2004-07-21, 3:57 am

<zeman@netvisao.pt> wrote in message
news:97ed3bd0.0407201648.5e06cc14@posting.google.com...
> Dear all
>
> I'm just a newby in high precision floating point but an answer to
> this "simple" question would help me so much in the further
> developments.
>
>
> When I run a simple code using 64 bit precison (in a Itanium with
> Intel Fortran 90 compilator) a runtime error message appears:
>
> unaligned access
>
> The code can be very simple like
>
> REAL a(20)
> a(1)=1.0
> print*, a(1)
>
> and it was compiled with the -r16 option.
>
> I found out that the error message arises from the usage of an array.
> if 'a' is just a real the code goes fine.
>
> I have read a lot of material, including compilator manuals, and the
> problem remains. So, I would be very greatful if someone could tell me
> something about it.
>
> Best regards
> ZF

The problem undoubtedly lies in:

> REAL a(20)
> a(1)=1.0

and whatever you believe -r16 is supposed to do.

Search the docs for quad, real(16), real*16, and the like. You'll get
there. However, in the interim, and without fail, huckleberry glen will
chime in with his Alzheimer's reminiscences of the yesteryear to bring you
up to speed to his state of mental numbness even though you're probably
interested in tomorrow.

--
Good Luck,
Gerry T.

glen herrmannsfeldt

2004-07-21, 3:57 am

Gerry Thomas wrote:
> <zeman@netvisao.pt> wrote in message
> news:97ed3bd0.0407201648.5e06cc14@posting.google.com...

[color=darkred]
[color=darkred]
[color=darkred]
[color=darkred]
[color=darkred]
[color=darkred]
[color=darkred]

Many processors, from IBM S/360 to Sparc, require data items
to have an address that is a multiple of the item length.
Four byte INTEGER variables must have addresses that are
multiples of four. Most other processors will run slower
with unaligned data, but will still do it.

For the program given, though, it looks like a compiler
error. The Fortran rules for COMMON blocks can easily
generate unaligned data if one is not careful. It can
also be done with EQUIVALENCE, but absent either of those
it is the compiler's responsibility to do it right.
[color=darkred]
> Search the docs for quad, real(16), real*16, and the like. You'll get
> there. However, in the interim, and without fail, huckleberry glen will
> chime in with his Alzheimer's reminiscences of the yesteryear to bring you
> up to speed to his state of mental numbness even though you're probably
> interested in tomorrow.

I suppose Sparc is a yesteryear processor. I believe Itanium
also requires data to be aligned.

-- glen

Gerry Thomas

2004-07-21, 3:57 am

"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
news:rsmLc.132358$%_6.7174@attbi_s01...
> Gerry Thomas wrote:
>
>
>
>
>
>
>
>
>
> Many processors, from IBM S/360 to Sparc, require data items
> to have an address that is a multiple of the item length.
> Four byte INTEGER variables must have addresses that are
> multiples of four. Most other processors will run slower
> with unaligned data, but will still do it.
>
> For the program given, though, it looks like a compiler
> error. The Fortran rules for COMMON blocks can easily
> generate unaligned data if one is not careful. It can
> also be done with EQUIVALENCE, but absent either of those
> it is the compiler's responsibility to do it right.
>
you[color=darkred]
>
> I suppose Sparc is a yesteryear processor. I believe Itanium
> also requires data to be aligned.
>

Now if only you could align yourself with reality!

You present as either an under 8 prodigy or an over 80's person suffering
from dementia. A reliable source recommends that you have your GP conduct a
mini mental status exam and take it from there.

--
You're Welcome,
Gerry T.
______
"Don't play dumb! You're not as good at it as I am!" -- Col Sam Flagg,
ICORPS dropin to the 4077th M*A*S*H

Herman D. Knoble

2004-07-21, 8:59 am

ZF: If you telling us that the three statement program you
list below fails with any (valid) compiler option, it's likely a compiler
bug. If you have access to another compiler, you may want
to try that.

Skip Knoble, Penn State

On 20 Jul 2004 17:48:28 -0700, zeman@netvisao.pt wrote:

-|Dear all
-|
-|I'm just a newby in high precision floating point but an answer to
-|this "simple" question would help me so much in the further
-|developments.
-|
-|
-|When I run a simple code using 64 bit precison (in a Itanium with
-|Intel Fortran 90 compilator) a runtime error message appears:
-|
-|unaligned access
-|
-|The code can be very simple like
-|
-|REAL a(20)
-|a(1)=1.0
-|print*, a(1)
-|
-|and it was compiled with the -r16 option.
-|
-|I found out that the error message arises from the usage of an array.
-|if 'a' is just a real the code goes fine.
-|
-|I have read a lot of material, including compilator manuals, and the
-|problem remains. So, I would be very greatful if someone could tell me
-|something about it.
-|
-|Best regards
-|ZF

Herman D. (Skip) Knoble, Research Associate
(a computing professional for 38 years)
Email: SkipKnobleLESS at SPAMpsu dot edu
Web: http://www.personal.psu.edu/hdk
Penn State Information Technology Services
Academic Services and Emerging Technologies
Graduate Education and Research Services
Penn State University
214C Computer Building
University Park, PA 16802-21013
Phone:+1 814 865-0818 Fax:+1 814 863-7049

Steve Lionel

2004-07-21, 3:58 pm

On 20 Jul 2004 17:48:28 -0700, zeman@netvisao.pt wrote:

>When I run a simple code using 64 bit precison (in a Itanium with
>Intel Fortran 90 compilator) a runtime error message appears:
>
>unaligned access
>
>The code can be very simple like
>
>REAL a(20)
>a(1)=1.0
>print*, a(1)
>
>and it was compiled with the -r16 option.
>
>I found out that the error message arises from the usage of an array.
>if 'a' is just a real the code goes fine.

There's nothing inherently wrong with the code as you have posted it. You
don't say what version of Intel Fortran you are using. I believe that an
issue on Itanium systems with this message (which is not an error) was
resolved in a compiler update. Please be sure you are using a current
compiler version - you can download updated compilers from your Intel Premier
Support account.

I would encourage you to use Intel Premier Support to report future suspected
problems with Intel compilers. The URL is https://premier.intel.com/ Please
be sure that you have registered with us first.

Steve Lionel
Software Products Division
Intel Corporation
Nashua, NH

User communities for Intel Software Development Products
http://softwareforums.intel.com/
Intel Fortran Support
http://developer.intel.com/software/products/support/

Steve Lionel

2004-07-21, 3:58 pm

On Tue, 20 Jul 2004 23:08:03 -0400, "Gerry Thomas" <gfthomas@sympatico.ca>
wrote:

>The problem undoubtedly lies in:
>
>
>and whatever you believe -r16 is supposed to do.

There is nothing wrong with the user's code nor the use of -r16, which does
exactly what the user thinks it does using the indicated compiler.

Steve Lionel
Software Products Division
Intel Corporation
Nashua, NH

User communities for Intel Software Development Products
http://softwareforums.intel.com/
Intel Fortran Support
http://developer.intel.com/software/products/support/

zeman@netvisao.pt

2004-07-21, 8:57 pm

Thank you very much for your coments and suggestions.

I've tried some alternatives, like using C language, and a similar
problem occurs. In this case I found to be an error with the printf
format and float headers. I suppose the same problem to FORTRAN. As
suggested above, I'll try the INTEL support to fix the problem as far
as I could not manage with it.

Thanks again

ZF

Gerry Thomas

2004-07-22, 3:57 am

"Steve Lionel" <Steve.Lionel@intel.com> wrote in message
news:o8tsf0dpb1i6166vcvbe4epjkfk6am60tf@
4ax.com...
> On Tue, 20 Jul 2004 23:08:03 -0400, "Gerry Thomas"
<gfthomas@sympatico.ca>
> wrote:
>
>
> There is nothing wrong with the user's code nor the use of -r16, which
does
> exactly what the user thinks it does using the indicated compiler.

Sure there is: use of
[color=darkred]

in conjunction with -r16 isn't even Fortran: switches are a vendor's
inconvenience that engenders nonportability.

Whether a vendor's switch does what it's supposed to do (an unwarranted
feature of CVF and I don't belive it's any different for the Intel Fortran
compiler-in-progress) is a transFortran risk for the user and a QA issue
for the vendor. User's who rely on such oughtn't to whine on CLF but rather
take their complaint's straight to the offender, in this case Intel, as you
so directed the OP.

--
HTH,
Gerry T.
______
"There's man all over for you, blaming on his boots the fault of his
feet." -- Samuel Beckett.

Sponsored Links