The February 2012 PTF for XL Fortran for AIX, V12.1 is now available at the following links and on Fix Central.
Can't find the updates for your compilers? Check out our Fortran compilers latest updates page here.
TariqueIslam 2700046692 19,785 Views
Operator overloading is a key ingredient of object-oriented programming. Fortran (starting from Fortran 90) supports operator overloading through defined operator which allows you to extend an intrinsic operator or define a new operator. For example, you can extend "+" to perform "var1 = var2 + var3" where var1, var2, and var3 are derived-type objects. Likewise, you can define a new operator, such as ".UNION.", to compute the union of two sets " set3 = set1 .UNION. set2", where set1, set2, and set3 could be arrays or objects of a user-defined type representing sets. In this article, I am going to illustrate how to define an operator to perform operations that the language does not support intrinsically.
I will start with a simple example to describe the mechanism and will mention the related language rules at the end. Consider an application that processes points in three dimensions where a point is represented by the following derived type.
Consider that the application requires adding an offset of type real to each dimension of a point. Let us extend the '+' operator to perform the intended operation.
Step 1: Define the meaning of applying '+' on objects of type point_t and real:
- This translates to defining a function, say add_offset_to_point, that will perform the intended operation.
function add_offset_to_point(op1, op2)
Step 2: Indicate that the function add_offset_to_point will be used as '+' operation:
- This translates to providing a generic interface for the function add_offset_to_point and specifying OPERATOR in the generic specification.
INTERFACE OPERATOR (+)
Step 3: Using the newly defined operator the same way as an intrinsic '+' operator is used.
type(point_t) :: pt1, pt2, pt3
The compiler interprets "pt3 = pt1 + off" as "pt3 = add_offset_to_point(pt1, off)".
The following example consolidates the pieces from above into a complete program.
The program produces the following output.
> xlf2003 defined-op.f
Now, consider that the application needs to add (dimension wise) coordinates of two point_t type objects as shown below.
pt3 = pt1 + pt2
In order to support the new operation, we just need to define another function, say add_point_to_point, to perform the operation, and add the interface of add_point_to_point to the generic interface ('+') we created in Step 2.
INTERFACE OPERATOR (+)
The last step demonstrates how an operator can be extended to operate on multiple combinations of operand types. The combinations of operand types must be such that op1 + op2 resolves to a unique specific binding of ('+') in accordance with the language rules for generic interface.
For completeness, let us define a unary operator ".XCOORD." to retrieve the value of the x coordinate of a point. The interface and the new function are as follows.
INTERFACE OPERATOR (.XCOORD.)
Now that we have seen all the required steps, let us consider an alternative to Step 2. The generic interface of a defined-operator can be bound to a derived-type. For example, we could represent the points by the following type.
The difference from the previous method is that the compiler interprets "pt1 + pt2" as "pt1%add_point_to_point(pt2)". When an operator is defined using generic binding, the dummy arguments of the function that implements the operator must satisfy the constraints of a type-bound procedure, such as the constraints on the passed-object dummy arguments. However, no syntactic change is needed in the usage of the defined operator.
I am going to conclude this article by mentioning the language rules that govern defined-operators.
R1) A defined-operator shall be unary or binary. All procedures specified in the generic interface corresponding to a unary (binary, respectively) intrinsic operator must be functions with one (two, respectively) arguments. In our example, both "add_offset_to_point" and "add_point_to_point" extend binary intrinsic "+" operation and have two arguments each.
R2) The dummy arguments of these function must be non optional, and have INTENT(IN) attribute.
R3) An extended intrinsic operator must operate on the same number of operands as the original intrinsic operator. Therefore, an extended '*' operator must be binary whereas an extended ".NOT." must be unary.
R4) When a function extends an intrinsic operation, at least one dummy argument must have a type, kind parameter, or rank that distinguish the extended operation from the intrinsic operation. In our example, the type of the dummy argument "op1" of function "add_offset_to_point" distinguishes extended addition "pt2 + off" from an intrinsic addition like " 2.0 + off".
R5) Relational operators have two forms. For example "<" has the same interpretation as ".LE.". Extending one form automatically extends both forms.
You might have noticed that the compiler creates files with the mod file extension. These are what we call module symbol files.
A module symbol file contains information about the specification part of a Fortran module. The file name is made of the module name followed by the mod extension. For example, if your Fortran module is called weather, the compiler will generate a module symbol file called weather.mod. The same module symbol file can be used in 32-bit and 64-bit compilations, provided you add the required information to it.
Let's look at an example:
$ cat test.f module m integer i contains subroutine sub print *, i end subroutine end module $ cat main.f use m i = 10 call sub end
This contrived example has two files: test.f and main.f. test.f defines a module m that has a module variable and a module procedure. main.f uses module m, initializes the variable and calls the module procedure.
Compiling test.f generates two files: m.mod and test.o. m.mod contains information about module variable i, and the interface of module procedure sub. test.o contains the object code for module procedure sub.
$ xlf95 test.f -c ** m === End of Compilation 1 === 1501-510 Compilation successful for file test.f. $ ls m.mod main.f test.f test.o $
The module symbol file also contains information about the version of the compiler that generated it, the date of compilation, and the bit modes the module symbol file supports. You can access this information via the what command on AIX, or the strings -a m.mod | grep '(#)' command on Linux.
$ what m.mod m.mod: Module symbol file for module:m Bit mode:32 Produced by:IBM XL Fortran for AIX, V13.1 (5724-X15) Version 13.01.0000.0009 03/08/12 17:45:14 From file:test.f
Using the module symbol file
When it sees a USE statement, the compiler automatically searches for a module symbol file matching the name and bit mode of the module name specified in the
$ xlf95 main.f -c ** _main === End of Compilation 1 === 1501-510 Compilation successful for file main.f.
Since the module symbol file above only supports 32-bit mode, it won't work in 64-bit mode:
$ xlf95 main.f -c -q64 "main.f", line 1.5: 1514-267 (S) The current program unit has a different setting for the -q64 option than was specified in the module m. Unexpected errors may result. ** _main === End of Compilation 1 === 1501-511 Compilation failed for file main.f.
To add support for 64-bit mode, recompile the module with -q64. If you don't delete the existing module symbol file, the 64-bit specification information will be added to it.
$ what m.mod m.mod: Module symbol file for module:m Bit mode:32 Produced by:IBM XL Fortran for AIX, V13.1 (5724-X15) Version 13.01.0000.0009 03/08/12 17:45:14 From file:test.f Module symbol file for module:m Bit mode:64 Produced by:IBM XL Fortran for AIX, V13.1 (5724-X15) Version 13.01.0000.0009 03/08/12 17:45:43 From file:test.f
With this, the module symbol file can be used in 64-bit mode as well:
$ xlf95 main.f -c -q64 ** _main === End of Compilation 1 === 1501-510 Compilation successful for file main.f.
If your module symbol file is not in the current directory, you can use the
$ ls main.f mydir test.f $ xlf95 test.f -c -qmoddir=mydir ** m === End of Compilation 1 === 1501-510 Compilation successful for file test.f. $ ls main.f mydir test.f test.o $ ls mydir m.mod $ xlf95 main.f -c -Imydir ** _main === End of Compilation 1 === 1501-510 Compilation successful for file main.f.
The module symbol file is only used in the compilation step. It doesn't have to be available during linking. For our example above, only test.o and main.o are needed for linking.
When writing dependency lists in Makefiles, it's usually a good idea to include the module symbol file as a dependency for files that contain USE statements for that module. For example, if you have a constants module containing parameters but no module procedures, XLF will sometimes only generate a constant.mod but not an object file. Adding constants.mod to the dependency list of the file containing USE constants solves this.
You can use old module symbol files with newer compilers. XLF 13.1 still supports the module symbol files created by XLF 3.1! However, the compiler will reject module symbol files that were created using newer compilers or on different platforms. For example, module files created by XLF 12.1 on AIX 5.3 can be used by XLF 13.1 on any AIX version. They can't be used by XLF 11.1 on AIX or by any XLF compiler on Linux. In those situations, you'll get the following message:
"main.f", line 1.5: 1514-220 (S) Module symbol file for module m is in a format not recognized by this compiler. Please compile the module with this compiler. 1501-511 Compilation failed for file main.f.
The April 2012 Update for XL Fortran Advanced Edition for Blue Gene/P, V11.1 is now available at the following link and on
The April 2012 PTF for XL Fortran for AIX, V13.1 is now available at the following links and on
Interested in improving application performance and programming productivity? Check out the latest release of XL Fortran
Check out all the information about the latest release of XL Fortran for AIX, and XL Fortran for Linux. You can get a summary of each release by product as well as all the announcement details. See What's new in the release including enhancements to improve application performance and programmer productivity. For all the details about the XL Fortran announcements, see these resources. And don't forget our Webinar and Innovate2012 where you will hear lots more about the latest compilers.
Product pagesXL Fortran for AIX
XL Fortran for Linux
melaniejs 27000011QX Tags:  magazine system compilers tools webinar rational power 7,495 Views
Check out this webinar by IBM Systems Magazine about Smart Tools on IBM i, AIX, and Linux for Faster Time to Market
Get an early look at the next version of Rational's offerings for Power Systems. New advancements in compilers and significantly enhanced development tools will give your organization a competitive advantage!
Looking to see and learn about the latest compiler enhancements in XL Fortran on AIX and Linux. Download a trial.
Here is quick recap of some of the highlights of these new compilers:
New and enhanced features in XL Fortran Version 14.1 include support of language
features that you can use to port code easily when moving to IBM Power Systems,
as well as improved compilation time at commonly used optimization levels. This
article for those who have some experience with previous versions of XL Fortran
gives the details and describes other highlights. Read more.
The June 2012 PTF for XL Fortran for AIX, V13.1 is now available at the following links and on
June 2012 Update for XL Fortran for Linux, V13.1
melaniejs 27000011QX Tags:  deep hpc gene/q computing rational ibm blue sequoia systems 8,371 Views
IBM’s Blue Gene/Q supercomputer, Sequoia, at the Lawrence Livermore National Lab took the number one ranking in the TOP500 list of the world’s fastest machines. And 21 other Blue Gene/Q configurations also earned spots on the list – including four in the top 10. Quite an achievement, given that IBM only started shipping these systems in volume to clients earlier this year. Read more
Check out new exercises in the Power sandbox. You can find them below.
The July 2012 PTF for XL Fortran for AIX, V13.1 (VRMF: 188.8.131.52) is now available at the following links and on Fix Central.
Can't find the updates for your compilers? Check out our Fortran compilers latest updates page here.
The September 2012 PTF for XL Fortran for AIX, V12.1 (VRMF: 184.108.40.206) is now available at the following links and on
September 2012 PTF for XL Fortran for AIX, V12.1
September 2012 PTF for XL Fortran Runtime for AIX, V12.1