Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Annonces
FPGA community forums and blogs on community.intel.com are migrating to the new Altera Community and are read-only. For urgent support needs during this transition, please visit the FPGA Design Resources page or contact an Altera Authorized Distributor.

Behavior of IBSET

Stefanos_K_
Débutant
1 281 Visites

Consider the following program:

[fortran]

program test

print*,ibset(1,65)

end program test

[/fortran]

Here's the result:

[bash]

$ ifort -o test test.f90
$ ./test
           3
$ ifort -V
Intel(R) Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 13.0.1.117 Build 20121010
Copyright (C) 1985-2012 Intel Corporation.  All rights reserved.
FOR NON-COMMERCIAL USE ONLY

[/bash]

Shouldn't the compiler throw an error in such cases?

0 Compliments
6 Réponses
TimP
Contributeur émérite III
1 281 Visites

 ifort -stand sk.f

        program test
^
sk.f(2): warning #7376: Standard F2003 requires POS, the 2nd argument, be less than BIT_SIZE of I, the 1st argument.   [IBSET]
       print*,ibset(1,65)
--------------^

Is your point that the code should be rejected regardless of option setting?

gfortran  sk.f
sk.f:2.22:

       print*,ibset(1,65)                                               
                      1
Error: 'pos' at (1) must be less than BIT_SIZE('i')

0 Compliments
Stefanos_K_
Débutant
1 281 Visites

Yeah, I would expect it to do so, like gfortran does. I was not aware that the requirement POS < BIT_SIZE was introduced only in F2003 though.

0 Compliments
TimP
Contributeur émérite III
1 281 Visites

The -stand option defaults to checking against f2003.  I expect the similar warning if you set checking against other standards.

0 Compliments
Steven_L_Intel1
Employé
1 281 Visites

You are likely to find many cases where the default in Intel Fortran is to let you express things not supported by the standard. Usually this is for historical compatibility. In such cases asking for standards checking gets you additional diagnostics.

0 Compliments
Stefanos_K_
Débutant
1 281 Visites

Thanks for the clarification, I'll start using -stand to this end from now on. One more marginally related question: can the -stand option interfere in any way with optimization?

0 Compliments
Steven_L_Intel1
Employé
1 281 Visites

It's not supposed to - it enables additional diagnostics only and does not change compiler semantics. There have been compiler bugs in the past where it did, but I am not aware of any cases nowadays.

0 Compliments
Répondre