- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The minimal program below causes the compiler to complain about a structure component instead of the defined operator that is meant. Surrounding the expression with parentheses changes the message.
! triple_min.f90 --
! Minimal example of the parsing problem
!
program triple_min
implicit none
real :: x
! Error message: structure component?
!
write(*,*) x .clamp. [0.0, 2.0]
! Error message: there is no defined operator (or structure component)
write(*,*) (x .clamp. [0.0, 2.0])
end program triple_minOther compilers complain about .clamp. being unknown. The original, full, code that led to this can be found at https://fortran-lang.discourse.group/t/standard-use-of-user-defined-operators/10736/6
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The DEC-heritage compiler have had many parsing problems over the years related to the VAX FORTRAN STRUCTURE/RECORD extension of the mid-1980s that used dots as the component separator, whereas Fortran 90 eventually settled on percent. This has led to ambiguities with operators and the compiler has rules where it tries to figure out what you meant, but we had to fix many problems where it got it wrong. I haven't seen one of these for quite a while.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Here is the output of ifx and gfortran on this program:
ifx -c triple_min.f90
Intel(R) Fortran Compiler for applications running on Intel(R) 64, Version 2025.0.0 Build 20241008
Copyright (C) 1985-2024 Intel Corporation. All rights reserved.
triple_min.f90(14): error #6866: Dotted string is neither a defined operator nor a structure component. [CLAMP]
write(*,*) (x .clamp. [0.0, 2.0])
-------------------^
triple_min.f90(11): error #6535: This variable or component must be of a derived or structure type. [X]
write(*,*) x .clamp. [0.0, 2.0]
---------------^
compilation aborted for triple_min.f90 (code 1)
gfortran -c triple_min.f90
triple_min.f90:11:24:
11 | write(*,*) x .clamp. [0.0, 2.0]
| 1
Error: Unknown operator 'clamp' at (1)
triple_min.f90:14:25:
14 | write(*,*) (x .clamp. [0.0, 2.0])
| 1
Error: Unknown operator 'clamp' at (1)I have not found an option that instructs ifx not to look for such legacy structure syntax.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hmmm, there is clearly a problem but the post here is a little confusing given the sample code is invalid (incomplete) and IFX gives a sane message #6866. The code on the discourse group where the operator .camp. is actually defined show a compiler error as IFX misinterprets what is IMO valid code and then gives a spurious error message.
! triple.f90 --
! Is it possible to write an expression like:
! x = y .clip. [min,max]
! with .clip. a user-defined operator?
!
module triple
implicit none
public :: operator(.clip.)
interface operator(.clip.)
module procedure clip_between
end interface
contains
real function clip_between( x, range )
real, intent(in) :: x
real, intent(in) :: range(2)
clip_between = max( min( x, range(2)), range(1) )
end function clip_between
end module triple
program test_triple
use triple
real :: x
x = 1.0
write(*,*) x .clip. [0.0, 2.0]
write(*,*) x .clip. [0.0, 0.5]
end program test_triple
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
My apologies for the confusion it caused. I thought to send in a minimal example to show just the error message, but clearly my minimal example is, well, too minimal.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The DEC-heritage compiler have had many parsing problems over the years related to the VAX FORTRAN STRUCTURE/RECORD extension of the mid-1980s that used dots as the component separator, whereas Fortran 90 eventually settled on percent. This has led to ambiguities with operators and the compiler has rules where it tries to figure out what you meant, but we had to fix many problems where it got it wrong. I haven't seen one of these for quite a while.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page