Although not very relevant to Fortran programmers, there is a new 
standard available for C, called C11 (I note that C programmers haven't 
learned much about the dangers of 2-digit year numbers).

This web page has some details:
http://blog.smartbear.com/software-quality/bid/173187/C11-A-New-C-Standard-Aiming-at-Safer-Programming

I like the comment (currently the last one) from David Kastrup, who said

"Fortran lovers should actually pay the C standard committee for their
work on keeping C irrelevant for serious numeric work."


-- 
Clive Page

On 06/26/2012 01:16 PM, Clive Page wrote:
> Although not very relevant to Fortran programmers, there is a new
> standard available for C, called C11 (I note that C programmers haven't
> learned much about the dangers of 2-digit year numbers).

Actually, the ISO/ICE 9899:2011 standard has been published already half 
a year ago (2011-12-08).

And for completeness, the C++ standard has also reached the level 11 
last year (ISO/IEC 14882:2011; published 2011-09-01).

My impression is that C11 won't get widely used, especially given that 
C99 is also not widely used.

I think the focus (in the C/C++ world) is rather on C++ and following 
how C++ handles some things. (Recall that most C programs also compile 
with a C++ compiler.)


Talking about standards: For Fortran, the next standard document in the 
pipeline is ISO/IEC TS 29113 "Further Interoperability of Fortran with 
C" (TS = Technical Specification), for which a five-month DIS ballot has 
been initiated end of last month. I am actually surprised that it is a 
DIS and not an FDIS ballot, though if I recall correctly ISO recently 
announced that FDIS votes are optional if the DIS is approved; those 
apply from 1 July and thus might or might not be a tad too late. Thus, 
either by end of this year or by 2014 it will be come an official TS. 
For the document itself, see 
ftp://ftp.nag.co.uk/sc22wg5/N1901-N1950/N1917.pdf

And for completeness: The (Draft) TS refers to C99 as does the Fortran 
2008 standard.


As it will take a while until the next Fortran standard or next TS will 
be created, here is another standard document which relates to Fortran: 
ISO/IEC TR 24772:2010 "Guidance for Avoiding Vulnerabilities through 
Language Selection and Use".

That document is one of the few free-of-charge ISO documents; but I will 
link to the latest draft version of revision 2: 
http://grouper.ieee.org/groups/plv/DocLog/300-399/380-thru-399/22-WG23-N-0389/n0389.pdf 
  As the Fortran part is a bit short, here is the draft annex for 
Fortran: ftp://ftp.nag.co.uk/sc22wg5/N1901-N1950/N1915.pdf

Happy reading,

Tobias

On 6/26/2012 1:16 PM, Clive Page wrote:
> Although not very relevant to Fortran programmers, there is a new
> standard available for C, called C11 (I note that C programmers haven't
> learned much about the dangers of 2-digit year numbers).
>
> This web page has some details:
> http://blog.smartbear.com/software-quality/bid/173187/C11-A-New-C-Standard-Aiming-at-Safer-Programming
>
>
> I like the comment (currently the last one) from David Kastrup, who said
>
> "Fortran lovers should actually pay the C standard committee for their
> work on keeping C irrelevant for serious numeric work."

David mentions (among other things) that C now seems
to be lacking the possibility to indicate a non-aliasing
assumption for arrays.

In fortran, as we know, the non-aliasing assumption is
the default. But is there a way in fortran to exempt
a certain argument of a routine from the assumption?!
(Of course a way to force "copy in copy out" for this
particular argument would also help, but that is not
necessarily what you always want in a case like that.)

-- 
Jos

On 2012-06-27 4:16 AM, Jos Bergervoet wrote:
> In fortran, as we know, the non-aliasing assumption is
> the default. But is there a way in fortran to exempt
> a certain argument of a routine from the assumption?!
> (Of course a way to force "copy in copy out" for this
> particular argument would also help, but that is not
> necessarily what you always want in a case like that.)

Use the POINTER and/or TARGET attributes.

Ian Harvey <ian_harvey@bigpond.com> wrote:

> On 2012-06-27 4:16 AM, Jos Bergervoet wrote:
> > In fortran, as we know, the non-aliasing assumption is
> > the default. But is there a way in fortran to exempt
> > a certain argument of a routine from the assumption?!
> > (Of course a way to force "copy in copy out" for this
> > particular argument would also help, but that is not
> > necessarily what you always want in a case like that.)
> 
> Use the POINTER and/or TARGET attributes.

Yep, allowing aliasing is a large part of what pointer is about.

As for copy-in/copy-out, that would not avoid the aliasing problem in
any event. Rather the opposite in that the possibility of
copy-in/copy-out is why aliasing is disallowed in some cases. To make
sense out of allowing aliasing in the presence of copy-in/copy-out,
you'd have to add a *LOT* more stuff. You'd have to address when the
copies happened, including what order they happened in when there were
multiple copy-outs to the same aliased location, etc., etc. No, there's
not a way in the language to do all that.

Well, actually, yes, there is a way to force copy-in/copy-out, though
I'm sure it isn't what you were thinking of because the compiler doesn't
do it behind your back. You can actually do the copy "manually" to a
separate local variable. Combine that with making the argument a pointer
so that aliasing is allowed, and you can probably get pretty
fine-grained control over how aliased arguments interact with each
other. Probably not what one would want to do in most cases, though.

P.S. I think I'll add clarification of a nit that the current posters
are probably aware of, but that some people very clearly are not. As it
stands, I'm afraid this thread might give the wrong impression.

Fortran does *NOT* have a general assumption of non-aliasing. There are
restrictions against aliasing in some cases, but not all. The details
can get picky, but the (very) short version is that aliasing is fine
until you start changing values. Yes, I have definitely seen people get
confused about that and think that aliasing was always disallowed, which
is why I thought I better correct the overly broad statement quoted
above.

-- 
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain

On 6/26/2012 9:47 PM, Ian Harvey wrote:
> On 2012-06-27 4:16 AM, Jos Bergervoet wrote:
>> In fortran, as we know, the non-aliasing assumption is
>> the default. But is there a way in fortran to exempt
>> a certain argument of a routine from the assumption?!
>> (Of course a way to force "copy in copy out" for this
>> particular argument would also help, but that is not
>> necessarily what you always want in a case like that.)
>
> Use the POINTER and/or TARGET attributes.

No good solution.. That will accept only
arguments that have the pointer or target
attribute also in the calling program! It
also would block expressions like
   call sub(a+b, p+q)

I want to indicate it just inside the
routine (in one place!) without shifting
any burden to the caller of the routine.

Do I really have to link to C code to get
this done?!

-- 
Jos

On 6/26/2012 9:47 PM, Ian Harvey wrote:
> On 2012-06-27 4:16 AM, Jos Bergervoet wrote:
>> In fortran, as we know, the non-aliasing assumption is
>> the default. But is there a way in fortran to exempt
>> a certain argument of a routine from the assumption?!
>> (Of course a way to force "copy in copy out" for this
>> particular argument would also help, but that is not
>> necessarily what you always want in a case like that.)
>
> Use the POINTER and/or TARGET attributes.

No good solution.. That will accept only
arguments that have the pointer or target
attribute also in the calling program! It
also would block expressions like
   call sub(a+b, result)

I want to indicate it just inside the
routine (in one place!) without shifting
any burden to the caller of the routine.

Do I really have to link to C code to get
this done?!

-- 
Jos

Jos Bergervoet <jos.bergervoet@xs4all.nl> wrote:

> On 6/26/2012 9:47 PM, Ian Harvey wrote:
> > On 2012-06-27 4:16 AM, Jos Bergervoet wrote:
> >> In fortran, as we know, the non-aliasing assumption is
> >> the default. But is there a way in fortran to exempt
> >> a certain argument of a routine from the assumption?!
> >> (Of course a way to force "copy in copy out" for this
> >> particular argument would also help, but that is not
> >> necessarily what you always want in a case like that.)
> >
> > Use the POINTER and/or TARGET attributes.
> 
> No good solution.. That will accept only
> arguments that have the pointer or target
> attribute also in the calling program! It
> also would block expressions like
>    call sub(a+b, result)

Expressions are never problem with aliasing in the first place. You
can't write to a dummy argument that has an expression as an actual
argument, but that restriction has nothing to do with aliasing.

Indeed, expressions are a classic way to solve some aliasing problems.
You can sometimes do things like

  call sub((x), x)

to avoid aliasing problems that would have resulted from

  call sub(x,x)

I think I've lost sight of what problem it is you are trying to solve.
Perhaps that's because I don't think you ever actually stated the
problem - just what kinds of things you thought might be solutions and
what other kinds of things would not. I could try randomly guessing
solutions for a long time, but that doesn't seem like the most
straightforward way to get to a good one. As for randomly guessing
solutions, the VALUE attribute might also be on the list, but again,
until I know what the problem is, I can't tell.

-- 
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain

On 6/26/2012 11:43 PM, Richard Maine wrote:
> Jos Bergervoet <jos.bergervoet@xs4all.nl> wrote:
>
>> On 6/26/2012 9:47 PM, Ian Harvey wrote:
>>> On 2012-06-27 4:16 AM, Jos Bergervoet wrote:
>>>> In fortran, as we know, the non-aliasing assumption is
>>>> the default. But is there a way in fortran to exempt
>>>> a certain argument of a routine from the assumption?!
>>>> (Of course a way to force "copy in copy out" for this
>>>> particular argument would also help, but that is not
>>>> necessarily what you always want in a case like that.)
>>>
>>> Use the POINTER and/or TARGET attributes.
>>
>> No good solution.. That will accept only
>> arguments that have the pointer or target
>> attribute also in the calling program! It
>> also would block expressions like
>>     call sub(a+b, result)
>
> Expressions are never problem with aliasing in the first place. You
> can't write to a dummy argument that has an expression as an actual
> argument, but that restriction has nothing to do with aliasing.
>
> Indeed, expressions are a classic way to solve some aliasing problems.
> You can sometimes do things like
>
>    call sub((x), x)
>
> to avoid aliasing problems that would have resulted from
>
>    call sub(x,x)

Those problems are the problems I want to avoid.
And I do not want to rely on the caller using one
of the tricks shown above.

> I think I've lost sight of what problem it is you are trying to solve.
> Perhaps that's because I don't think you ever actually stated the
> problem

See previous paragraph. I could also say that I'm
looking for the opposite of the C "restrict", since
fortran has the opposite default assumption.

> - just what kinds of things you thought might be solutions and
> what other kinds of things would not. I could try randomly guessing
> solutions for a long time, but that doesn't seem like the most
> straightforward way to get to a good one. As for randomly guessing
> solutions, the VALUE attribute might also be on the list,

Yes, value "sounds" like the closest to the opposite
of restrict! But would it help in the example below?

> but again,
> until I know what the problem is, I can't tell.

! Example: the following routine is formally not
! correct if it is called like:
!   invert(x, x)
! or
!   invert( x(1:2,1:2), x(2:3,2:3) )
!
! It will usually work, but:
! Within the fortran rules the compiler is allowed
! to initialize B to zero just before the first
! statement (B = A).

subroutine invert(A, B)
   real, intent(in)  :: A(:,:)
   real, intent(out) :: B(:,:)

   B = A
! Now do the work 'in situ' using only B
   ...
end subroutine

-- 
Jos

"Jos Bergervoet" <jos.bergervoet@xs4all.nl> wrote in message 
news:4fea31c3$0$6946$e4fe514c@news2.news.xs4all.nl...

> subroutine invert(A, B)
>   real, intent(in)  :: A(:,:)
>   real, intent(out) :: B(:,:)

>   B = A
> ! Now do the work 'in situ' using only B
>   ...
> end subroutine

Yeah, giving A the VALUE attribute instead of intent(in) means
that invert gets a copy of A, not A itself, so it can't overlap
with B.

PS OT: did you hear that NCAR is under voluntary evacuation?

-- 
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

Jos Bergervoet <jos.bergervoet@xs4all.nl> wrote:

> On 6/26/2012 11:43 PM, Richard Maine wrote:

> > Indeed, expressions are a classic way to solve some aliasing problems.
> > You can sometimes do things like
> >
> >    call sub((x), x)
> >
> > to avoid aliasing problems that would have resulted from
> >
> >    call sub(x,x)
> 
> Those problems are the problems I want to avoid.
> And I do not want to rely on the caller using one
> of the tricks shown above.
> 
> > I think I've lost sight of what problem it is you are trying to solve.
> > Perhaps that's because I don't think you ever actually stated the
> > problem
> 
> See previous paragraph. I could also say that I'm
> looking for the opposite of the C "restrict", since
> fortran has the opposite default assumption.

I don't know C well enough to be sure of the precise definition of
"restrict", much less what its opposite would be. But...

> Yes, value "sounds" like the closest to the opposite
> of restrict! But would it help in the example below?

Yes.

> > but again,
> > until I know what the problem is, I can't tell.
> 
> ! Example: the following routine is formally not
> ! correct if it is called like:
> !   invert(x, x)
> ! or
> !   invert( x(1:2,1:2), x(2:3,2:3) )
> !
> ! It will usually work, but:
> ! Within the fortran rules the compiler is allowed
> ! to initialize B to zero just before the first
> ! statement (B = A).
> 
> subroutine invert(A, B)
>    real, intent(in)  :: A(:,:)
>    real, intent(out) :: B(:,:)
> 
>    B = A
> ! Now do the work 'in situ' using only B
>    ...
> end subroutine

Ok. Now that's something concrete I can work with.

Yes, the VALUE attribute will make that work. VALUE is a lot like making
the actual argument an expression, except that

1. You do it inside of the subroutine instead of in the call (addressing
one of your issues), and

2. You are allowed to redefine the dummy argument (with any such
redefinition not having any effect on the actyal argument). That's not
directly relevant to the case you showed.

VALUE does pretty much force copy-in (so I was half wrong in previously
stating that there was no way to force copy-in/copy-out), but copy-out
is irrelevant to value (so I'll claim that as the half that I was
right). Copy-out is a much bigger issue than copy-in in terms of
aliasing.

Of course, the essentially forced copy might have objectionable
implications on performance. It will probably end up with making 2
copies (one for the VALUE attribute, and one for the assignment
statement), plus allocating and deallocating a temporary array, where us
humans can see that doing zero copies would have had the same end
result.

Do note that VALUE is an f2003 feature, so you'll have to check detailed
compiler feature lists unless you happen to be using an f2003 compiler
(none of which exist for any platforms I currently use). It was
originally introduced for purposes of C interop, but has uses
independent of C; that's the case for several other features also
introduced with C interop as their rationale.

-- 
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain

On 2012-06-27 7:31 AM, Jos Bergervoet wrote:
> On 6/26/2012 9:47 PM, Ian Harvey wrote:
>> On 2012-06-27 4:16 AM, Jos Bergervoet wrote:
>>> In fortran, as we know, the non-aliasing assumption is
>>> the default. But is there a way in fortran to exempt
>>> a certain argument of a routine from the assumption?!
>>> (Of course a way to force "copy in copy out" for this
>>> particular argument would also help, but that is not
>>> necessarily what you always want in a case like that.)
>>
>> Use the POINTER and/or TARGET attributes.
>
> No good solution.. That will accept only
> arguments that have the pointer or target
> attribute also in the calling program! It
> also would block expressions like
>    call sub(a+b, result)
....

Actual arguments without the TARGET attribute can be passed to dummy 
arguments with the TARGET attribute.

F2008: Actual arguments without the POINTER attribute, but with the 
TARGET attribute, can be passed to dummy arguments with the POINTER 
attribute.

If the actual arguments are alliased in some way, and neither have the 
POINTER or TARGET attributes, then how did they become aliased?  If it 
is because they are in turn dummy arguments in the calling procedure, 
then isn't it illegal for the calling procedure to be trying to modify 
them (by calling another procedure) in the first place?

Jos Bergervoet <jos.bergervoet@xs4all.nl> wrote:

(snip on aliasing)

> Those problems are the problems I want to avoid.
> And I do not want to rely on the caller using one
> of the tricks shown above.

(snip)

> subroutine invert(A, B)
>   real, intent(in)  :: A(:,:)
>   real, intent(out) :: B(:,:)

>   B = A
> ! Now do the work 'in situ' using only B
>   ...
> end subroutine

All the matrix inversion routines I used to have worked in place.

-- glen

On 6/26/12 6:31 PM, glen herrmannsfeldt wrote:
> Jos Bergervoet<jos.bergervoet@xs4all.nl>  wrote:
>
> (snip on aliasing)
>
>> Those problems are the problems I want to avoid.
>> And I do not want to rely on the caller using one
>> of the tricks shown above.
>
> (snip)
>
>> subroutine invert(A, B)
>>    real, intent(in)  :: A(:,:)
>>    real, intent(out) :: B(:,:)
>
>>    B = A
>> ! Now do the work 'in situ' using only B
>>    ...
>> end subroutine
>
> All the matrix inversion routines I used to have worked in place.
>
> -- glen
Do you mean they were required to work because of rules in the standard? 
  Or did they work with the particular arguments you used with a 
particular compiler on a particular piece of hardware and a particular 
choice of compiler options?  How about future compilers/hardware/options?

Dick Hendrickson

Dick Hendrickson <dick.hendrickson@att.net> wrote:

(snip, I wrote)

>> All the matrix inversion routines I used to have worked in place.

> Do you mean they were required to work because of rules in 
> the standard? 
>  Or did they work with the particular arguments you used with a 
> particular compiler on a particular piece of hardware and a particular 
> choice of compiler options?  
> How about future compilers/hardware/options?

In place, one argument for the matrix.
If it had INTENT, it would be INOUT.

As someone noted for the determinants, I remember using matrix
inversion routines in high school. I believe the one I had was
from the IBM SSP package, which is available somewhere on the net.

I don't remember ever seeing a matrix inversion routine that
didn't do it in place, though I might not have been looking
that carefully.

Also returns the determinant in case you wanted it.

-- glen

On 6/27/2012 1:17 AM, Ian Harvey wrote:
  ..
> Actual arguments without the TARGET attribute can be passed to dummy
> arguments with the TARGET attribute.
>
> F2008: Actual arguments without the POINTER attribute, but with the
> TARGET attribute, can be passed to dummy arguments with the POINTER
> attribute.
>
> If the actual arguments are alliased in some way, and neither have the
> POINTER or TARGET attributes, then how did they become aliased?

Like this:
   call sub( x, x )
or array slices:
   call sub( x(1:n-1), x(2:n) )
where the second argument of sub() is intent(out)

>  If it
> is because they are in turn dummy arguments in the calling procedure,
> then isn't it illegal for the calling procedure to be trying to modify
> them (by calling another procedure) in the first place?

subroutine proc(x)
   real :: x(:)
   call sub( x(1:n-1), x(2:n) )
end

You mean that the above is illegal, so even if we
can make it safe (e.g. with the VALUE attribute)
it would never be standard conforming?

I didn't think of that but you may be right..
Unless the Value attribute explicitly has the
property of lifting the general rule "no argument
shall be aliased with an intent(out) argument".
(Richard didn't address this issue in the other
post in this thread.. But I expect it is the case!)

-- 
Jos

On 6/27/2012 3:53 AM, glen herrmannsfeldt wrote:
> Dick Hendrickson <dick.hendrickson@att.net> wrote:
>
> (snip, I wrote)
>
>>> All the matrix inversion routines I used to have worked in place.
>
>> Do you mean they were required to work because of rules in
>> the standard?
>>   Or did they work with the particular arguments you used with a
>> particular compiler on a particular piece of hardware and a particular
>> choice of compiler options?
>> How about future compilers/hardware/options?
>
> In place, one argument for the matrix.
> If it had INTENT, it would be INOUT.
>
> As someone noted for the determinants, I remember using matrix
> inversion routines in high school. I believe the one I had was
> from the IBM SSP package, which is available somewhere on the net.
>
> I don't remember ever seeing a matrix inversion routine that
> didn't do it in place, though I might not have been looking
> that carefully.

Strange.. I remember often seeing routines with
two arguments! (Like in the old discussion about
the CPU test of David Frank.) Example:
   http://groups.google.com/group/comp.lang.fortran/msg/656639019e52c617
The routine minv() in there has seperate arguments.

> Also returns the determinant in case you wanted it.

Incidently, in the example it also gives det!

-- 
Jos

Jos Bergervoet <jos.bergervoet@xs4all.nl> wrote:

> Unless the Value attribute explicitly has the
> property of lifting the general rule "no argument
> shall be aliased with an intent(out) argument".
> (Richard didn't address this issue in the other
> post in this thread.. But I expect it is the case!)

A VALUE argument is never aliased with anything else because the
argument is an expression - never a variable. An expression can't be
aliased.

There is, alas, a bit of a terminology confusion relating to actual
arguments. There are two potentially diferent things called actual
arguments. Unfortunately, there aren't two distinct terms for them.

First, there are those things in the (standard isn't in front of me
right now, so I might slightly "misspell" some of this)
<actual-arg-list>. That list is part of the syntax and is, per the bnf
rules, a list of <actual-arg>s. In most cases, each <actual-arg> is an
actual argument, as the term might leave you to suspect. An actual
argumeng is what the dummy argument gets associated with. But in some
cases the <actual-arg> isn't the actual argument. I really dislike that
terminology confusion. The VALUE attribute triggers one of those cases.
(There are other cases as well). With the VALUE attribute, the actual
argument is not the <actual-arg> from the syntax. Instead, it is the
result of evaluating the <actual-arg> as an expression. The <actual-arg>
might be aliased to various things, but that doesn't matter because it
isn't the actual argument.

So the VALUE attribute doesn't lift that rule. The rule just never
happens to apply to a VALUE argument, so it doesn't need to be lifted.

-- 
Richard Maine                    | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle           |  -- Mark Twain

On 2012-06-27 5:02 PM, Jos Bergervoet wrote:
> On 6/27/2012 1:17 AM, Ian Harvey wrote:
>   ..
>> Actual arguments without the TARGET attribute can be passed to dummy
>> arguments with the TARGET attribute.
>>
>> F2008: Actual arguments without the POINTER attribute, but with the
>> TARGET attribute, can be passed to dummy arguments with the POINTER
>> attribute.
>>
>> If the actual arguments are alliased in some way, and neither have the
>> POINTER or TARGET attributes, then how did they become aliased?
>
> Like this:
>    call sub( x, x )
> or array slices:
>    call sub( x(1:n-1), x(2:n) )
> where the second argument of sub() is intent(out)
>
>>  If it
>> is because they are in turn dummy arguments in the calling procedure,
>> then isn't it illegal for the calling procedure to be trying to modify
>> them (by calling another procedure) in the first place?
>
> subroutine proc(x)
>    real :: x(:)
>    call sub( x(1:n-1), x(2:n) )
> end
>
> You mean that the above is illegal, so even if we
> can make it safe (e.g. with the VALUE attribute)
> it would never be standard conforming?
>
> I didn't think of that but you may be right..
> Unless the Value attribute explicitly has the
> property of lifting the general rule "no argument
> shall be aliased with an intent(out) argument".
> (Richard didn't address this issue in the other
> post in this thread.. But I expect it is the case!)

Ignore my babbling - I understand your use case.  My mental picture was 
that you may have wanted to modify either argument.

A tangential point, my understanding of restrict in C is that it is just 
an optimisation hint to the compiler.  Independent of the presence of 
that keyword, the programmer can still write code that will not work as 
expected (the result might be well defined, but it won't be the desired 
result) if arguments are aliased.  In the fortran case - I think that 
using an argument with the value attribute to get around aliasing still 
results in an otherwise naive implementation working.

I got up too early this morning, so I'm not really sure what point I'm 
making, but I think it is something around "if you really want C like 
behaviour, VALUE doesn't quite get you there - you need to be using 
POINTER/TARGET etc".

In a different tangential direction, if you really want to provide the 
user with both an modify in-place call option and a create new thing 
call option, then don't fight the aliasing restrictions by using VALUE, 
just have two specific procedures sitting behind a generic interface 
with a common back-end worker procedure - one specific with one arg, the 
other with two - otherwise someone will come and belt you around the 
head with a big stick marked "performance loss for no good reason".