http://www.lsoft.com/images/listserv-community.gifhttp://www.lsoft.com/images/listserv_small.gifCOMP-FORTRAN-90 ListCOMP-FORTRAN-90 List Archiveshttps://www.jiscmail.ac.uk/cgi-bin/webadmin?RSS&L=comp-fortran-90&v=ATOM1.0

This is an Atom formatted XML site feed. It is intended to be viewed in a Newsreader.
Alternatively you can view the HTML archives at https://www.jiscmail.ac.uk/cgi-bin/webadmin?A0=comp-fortran-90.

LISTSERV Web Interface 2.4.12018-01-19T09:40:25ZAnton Shterenlikht2018-01-19T09:40:16+00:002018-01-19T09:40:16+00:00Re: 2 abstract interfaces and IMPORT https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=comp-fortran-90;bccc3420.1801Bill<br><br>>An interface body is a host.<br><br>Right.<br>I thought that an interface *block* is a host.<br><br>Thank you for the clarification<br><br>Anton Bill Long2018-01-18T23:12:25+00:002018-01-18T23:12:25+00:00Re: 2 abstract interfaces and IMPORT https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=comp-fortran-90;7d9c1575.1801> On Jan 18, 2018, at 11:15 AM, Anton Shterenlikht <as@CMPLX.UK> wrote:<br>><br>> Is this module conformant?<br>><br>> module m<br>><br>> abstract interface<br>> integer pure function kernel_proto( space, coord )<br>> integer, intent( in ), allocatable :: space(:,:,:)<br>> integer, intent(in) :: coord(3)<br>> end function kernel_proto<br>><br>> subroutine iter_proto( space, fun )<br>> ! import :: kernel_proto<br>> integer, intent(in), allocatable :: space(:,:,:)<br>> procedure( kernel_proto ) :: fun<br>> end subroutine iter_proto<br>> end interface<br>><br>> end module m<br>><br>> 2 compilers accept it<br>> 2 compilers reject, complaining<br>> that [...]Anton Shterenlikht2018-01-18T17:15:01+00:002018-01-18T17:15:01+00:002 abstract interfaces and IMPORT https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=comp-fortran-90;e906b68c.1801Is this module conformant?<br><br>module m<br><br>abstract interface<br>integer pure function kernel_proto( space, coord )<br>integer, intent( in ), allocatable :: space(:,:,:)<br>integer, intent(in) :: coord(3)<br>end function kernel_proto<br><br>subroutine iter_proto( space, fun )<br>! import :: kernel_proto<br>integer, intent(in), allocatable :: space(:,:,:)<br>procedure( kernel_proto ) :: fun<br>end subroutine iter_proto<br>end interface<br><br>end module m<br><br>2 compilers accept it<br>2 compilers reject, complaining<br>that interface kernel_proto is not defined. [...] Anton Shterenlikht2018-01-05T15:15:31+00:002018-01-05T15:15:31+00:00NWP with OO Fortran https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=comp-fortran-90;9b25de51.1801They call it "Modern Fortran":<br><br>https://ams.confex.com/ams/98Annual/webprogram/Paper330888.html<br><br>Anton Anton Shterenlikht2018-01-05T11:22:51+00:002018-01-05T11:22:51+00:00Re: f2008 complex intrinsics on branch cuts - quality of implementation https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=comp-fortran-90;6e84b7f0.1801Bill<br><br>>Very interesting set of tests. In the Discussion section you mention that some of these functions might be implemented by calling the system libm routines. (And hence matching output of similar tests written in C.) To the extent that is the case, the results are indicative of the OS (SUSE, RedHat, …) that supplied the libm library, rather than the compiler used. For example, if you ran the tests for Cray and PGI on the same system, then for the libm cases you would expect the same outcome. Of course, it is useful information that the libm routines are [...]Bill Long2018-01-04T22:43:26+00:002018-01-04T22:43:26+00:00Re: f2008 complex intrinsics on branch cuts - quality of implementation https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=comp-fortran-90;4b724cbb.1801Very interesting set of tests. In the Discussion section you mention that some of these functions might be implemented by calling the system libm routines. (And hence matching output of similar tests written in C.) To the extent that is the case, the results are indicative of the OS (SUSE, RedHat, …) that supplied the libm library, rather than the compiler used. For example, if you ran the tests for Cray and PGI on the same system, then for the libm cases you would expect the same outcome. Of course, it is useful information that the libm routines are wrong, [...]arrl2018-01-03T17:17:29-05:002018-01-03T17:17:29-05:00Re: f2008 complex intrinsics on branch cuts - quality of implementation https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=comp-fortran-90;68445f70.1801On 1/3/2018 3:58 PM, Anton Shterenlikht wrote:<br>> Tim<br>><br>>> Definitely of interest. I didn't see a statement about whether the<br>>> results were affected by violating the documented requirements of<br>>> certain compilers on command line options for USE IEEE_ARITHMETIC.<br>>><br>>> --<br>>> Tim Prince<br>><br>> Have I violated the documented requirements?<br>> I'd be grateful for any details.<br>><br>> Thanks<br>><br>> Anton<br>><br>Intel says that ifort requires the option -fp-model precise for full<br>support of IEEE_ARITHMETIC. That option would be unpopular for<br>performance. Which IEEE_ARITHMETIC features will work with the option<br>you [...]Anton Shterenlikht2018-01-03T20:58:31+00:002018-01-03T20:58:31+00:00Re: f2008 complex intrinsics on branch cuts - quality of implementation https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=comp-fortran-90;f1f60797.1801Tim<br><br>>Definitely of interest. I didn't see a statement about whether the<br>>results were affected by violating the documented requirements of<br>>certain compilers on command line options for USE IEEE_ARITHMETIC.<br>><br>>--<br>>Tim Prince<br><br>Have I violated the documented requirements?<br>I'd be grateful for any details.<br><br>Thanks<br><br>Anton arrl2018-01-03T06:36:34-05:002018-01-03T06:36:34-05:00Re: f2008 complex intrinsics on branch cuts - quality of implementation https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=comp-fortran-90;52717382.1801On 1/3/2018 6:04 AM, Anton Shterenlikht wrote:<br>> Might be of interest to some.<br>><br>> https://arxiv.org/abs/1712.10230<br>><br>> On quality of implementation of Fortran 2008 complex intrinsic functions on branch cuts<br>> Anton Shterenlikht<br>> (Submitted on 29 Dec 2017)<br>><br>> Branch cuts in complex functions in combination with signed zero<br>> and signed infinity have important uses in fracture mechanics,<br>> jet flow and aerofoil analysis. We present benchmarks for validating<br>> Fortran 2008 complex functions - LOG, SQRT, ASIN, ACOS, ATAN,<br>> ASINH, ACOSH and ATANH - on branch cuts with arguments<br>> of all 3 [...]Anton Shterenlikht2018-01-03T11:04:15+00:002018-01-03T11:04:15+00:00f2008 complex intrinsics on branch cuts - quality of implementation https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=comp-fortran-90;2c8b8a6a.1801Might be of interest to some.<br><br>https://arxiv.org/abs/1712.10230<br><br>On quality of implementation of Fortran 2008 complex intrinsic functions on branch cuts<br>Anton Shterenlikht<br>(Submitted on 29 Dec 2017)<br><br>Branch cuts in complex functions in combination with signed zero<br>and signed infinity have important uses in fracture mechanics,<br>jet flow and aerofoil analysis. We present benchmarks for validating<br>Fortran 2008 complex functions - LOG, SQRT, ASIN, ACOS, ATAN,<br>ASINH, ACOSH and ATANH - on branch cuts with arguments<br>of all 3 IEEE floating point binary formats:<br>binary32, binary64 and binary128. Results are reported with<br>8 Fortran 2008 compilers: GCC, Flang, Cray, Oracle, [...] Robin Vowels2017-12-28T00:19:46+11:002017-12-28T00:19:46+11:00Re: Is this a valid specification expression? https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=comp-fortran-90;63357bde.1712From: Neil Carlson<br>Sent: Wednesday, December 27, 2017 11:14 AM<br><br>> Thanks Steve for the confirmation. Your "always a bug" statement is of course correct,<br>> though I'd imagine it takes on a much lower priority with vendors if it is associated with invalid<br>> code.<br><br>A compiler error always receives high priority.,<br>regardless of whether the program contains an error, or not. [...]Neil Carlson2017-12-26T17:14:22-07:002017-12-26T17:14:22-07:00Re: Is this a valid specification expression? https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=comp-fortran-90;80e4fc54.1712Thanks Steve for the confirmation. Your "always a bug" statement is of<br>course correct, though I'd imagine it takes on a much lower priority with<br>vendors if it is associated with invalid code.<br><br>On Tue, Dec 26, 2017 at 5:08 PM, Steve Lionel <<br>00000d9096837217-dmarc-request@jiscmail.ac.uk> wrote:<br><br>> On 12/26/2017 7:02 PM, Neil Carlson wrote:<br>><br>>> In fact it works with gfortran 8.0.0 too! (What doesn't work with<br>>> gfortran is if subroutine SUB is in a separate source file -- you get an<br>>> internal compiler error. The developer wants to dismiss the issue as being<br>>> due to [...]Steve Lionel2017-12-26T19:08:27-05:002017-12-26T19:08:27-05:00Re: Is this a valid specification expression? https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=comp-fortran-90;95abd390.1712On 12/26/2017 7:02 PM, Neil Carlson wrote:<br>> In fact it works with gfortran 8.0.0 too! (What doesn't work with<br>> gfortran is if subroutine SUB is in a separate source file -- you get<br>> an internal compiler error. The developer wants to dismiss the issue<br>> as being due to invalid code.)<br>><br>> Is that code valid, or am I out to lunch on this one? [...]Neil Carlson2017-12-26T17:02:40-07:002017-12-26T17:02:40-07:00Is this a valid specification expression? https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=comp-fortran-90;fa3591d1.1712Consider the following code<br><br>module mod1<br>integer :: ncells<br>end module<br><br>module mod2<br>contains<br>function get() result(array)<br>use mod1<br>real array(ncells)<br>array = 1.0<br>end function<br>end module<br><br>I seem to be at a stalemate with a gfortran developer who insists that the<br>declaration<br><br>real array(ncells)<br><br>is invalid because NCELLS was not assigned a value. It seems pretty clear<br>to me that NCELLS is a valid specification expression according to 7.1.11<br>(F2008 standard), particularly par 2 item (4). [...]John Harper2017-12-14T10:53:19+13:002017-12-14T10:53:19+13:00Re: Question on an ELEMENTAL function whose result characteristics make use of a specification expression https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=comp-fortran-90;fbeffb60.1712F95 and F2003 had constraints forbidding this. F2008 as first published<br>had a bug omitting that constraint. Constraint C1290b kills the bug.<br><br>For those who haven't got the f2003 standard handy its constraint C1279 is<br><br>C1279 In the scoping unit of an elemental subprogram, an object designator<br>with a dummy argument as the base object shall not appear in a<br>specification-expr except as the argument to one of the intrinsic<br>functions BIT SIZE, KIND, LEN, or the numeric inquiry functions<br>(13.5.6). [...]Vipul Parekh2017-12-13T09:25:18-05:002017-12-13T09:25:18-05:00Question on an ELEMENTAL function whose result characteristics make use of a specification expression https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=comp-fortran-90;39e270dd.1712Is the following code standard-conforming?<br><br>elemental function elemf( n, s ) result( new_s )<br>integer, intent(in) :: n<br>character(len=*), intent(in) :: s<br>! Function result<br>character(len=n*len(s)) :: new_s<br>new_s = repeat( s, ncopies=n )<br>end function<br><br>keeping in mind the Corrigenda (document N2122 at<br>https://wg5-fortran.org/f2008.html) to Fortran 2008 that includesAnton Shterenlikht2017-12-08T16:31:01+00:002017-12-08T16:31:01+00:00Re: Questions on specifications of the intrinsic type CHARACTER and the ALLOCATABLE attribute https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=comp-fortran-90;8d4aee0e.1712I think all 4 cases are conforming.<br>Allocatable character can be used to:<br>- have character vars of different length and/or<br>- have character arrays of different size.<br>Your examples use none of these capabilities, so<br>look a bit silly, but conforming.<br><br>If modified like this:<br><br>character(len=42), allocatable :: s(:)<br>write (*,*) allocated( s )<br>allocate( s(10) )<br>write (*,*) allocated( s ), len(s), size(s)<br>end [...] Vipul Parekh2017-12-08T10:58:07-05:002017-12-08T10:58:07-05:00Re: Questions on specifications of the intrinsic type CHARACTER and the ALLOCATABLE attribute https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=comp-fortran-90;72b5b3fb.1712Thank much for your feedback Neil.<br><br>No I couldn't personally locate any basis per my read of WD 1539-1<br>J3/10-007r1 document toward Fortran 2008 and the corrigenda tor any of<br>the 4 cases to be non-conforming.<br><br>But I just want to be sure I'm not overlooking anything, always a<br>strong possibility given the present arrangement of the standard. [...]Carlson, Neil2017-12-08T15:43:25+00:002017-12-08T15:43:25+00:00Re: Questions on specifications of the intrinsic type CHARACTER and the ALLOCATABLE attribute https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=comp-fortran-90;18985767.1712To my understanding they are all valid. Do you think some shouldn't be? Inclusion of the type in the case 4 allocate statement is unnecessary and redundant, but doesn't seem to bother any compiler I tried except for gfortran which threw an ICE on it. -Neil Vipul Parekh2017-12-08T10:20:01-05:002017-12-08T10:20:01-05:00Questions on specifications of the intrinsic type CHARACTER and the ALLOCATABLE attribute https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=comp-fortran-90;58b3db62.1712Greetings everyone,<br><br>I'm seeking your feedback on the length-type specification with the<br>intrinsic type CHARACTER and the ALLOCATABLE attribute.<br><br>I'll greatly appreciate replies on the following.<br><br>1) Is a variable allowed to have the ALLOCATABLE attribute but with a<br>constant expression in the length-type specification? For example, is<br>the following snippet standard-conforming?<br><br>--- begin case 1 ---<br>character(len=42), allocatable :: s<br>end<br>--- end case 1 --- [...]Vipul Parekh2017-11-30T12:20:54-05:002017-11-30T12:20:54-05:00Re: Question on procedure arguments with POINTER and INTENT(OUT) attributes https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=comp-fortran-90;f35b1442.1711Thanks much, Neil and Tom, for your responses - it's clear now.<br><br>VipulClune, Thomas L. (GSFC-6101)2017-11-30T15:40:02+00:002017-11-30T15:40:02+00:00Re: Question on procedure arguments with POINTER and INTENT(OUT) attributes https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=comp-fortran-90;449da55e.1711The pointer is undefined, and the call to ASSOCIATED() is illegal, but the compiler is not required to detect this.<br><br>In practice, most compilers (depending on options) will just use a reference to the external pointer, which is why you are “likely” to get T. E.g. with NAG and default compiler options: [...]Neil Carlson2017-11-30T08:34:08-07:002017-11-30T08:34:08-07:00Re: Question on procedure arguments with POINTER and INTENT(OUT) attributes https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=comp-fortran-90;156bbce9.1711But under the argument description, "Its pointer association status shall<br>not be undefined."<br>So your example isn't standard-conforming, and can do anything.<br><br>On Thu, Nov 30, 2017 at 8:16 AM, Vipul Parekh <parekhvs@gmail.com> wrote:<br><br>> Given that the standard states:<br>><br>> 1) for dummy variables with the POINTER attribute, "If the dummy<br>> argument has INTENT (OUT), the pointer association status of the<br>> actual argument becomes undefined on invocation of the procedure." and<br>><br>> 2) for the ASSOCIATED intrinsic, "the result is true if and only if<br>> POINTER is associated with a target."<br>><br>> what [...]Vipul Parekh2017-11-30T10:16:06-05:002017-11-30T10:16:06-05:00Question on procedure arguments with POINTER and INTENT(OUT) attributes https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=comp-fortran-90;450b3dc7.1711Given that the standard states:<br><br>1) for dummy variables with the POINTER attribute, "If the dummy<br>argument has INTENT (OUT), the pointer association status of the<br>actual argument becomes undefined on invocation of the procedure." and<br><br>2) for the ASSOCIATED intrinsic, "the result is true if and only if<br>POINTER is associated with a target." [...]Bill Long2017-11-28T23:14:24+00:002017-11-28T23:14:24+00:00Re: Use of a COINDEXED OBJECT with ATOMIC subroutines https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=comp-fortran-90;5fa6642d.1711> On Nov 28, 2017, at 5:06 PM, Clune, Thomas L. (GSFC-6101) <thomas.l.clune@NASA.GOV> wrote:<br>><br>><br>>> On Nov 28, 2017, at 6:01 PM, Bill Long <longb@cray.com> wrote:<br>>><br>>>> On Nov 28, 2017, at 4:17 PM, Vipul Parekh <parekhvs@GMAIL.COM> wrote:<br>>>><br>>>> Bill,<br>>>><br>>>> Thanks very much for your response.<br>>>><br>>>> Is it fair to correct to think the number of images is going to be 1<br>>>> or greater in a coarray program and the following code variant with<br>>>> explicit reference to image 1 is standard-conforming and the program<br>>>> built using a conforming processor [...]Clune, Thomas L. (GSFC-6101)2017-11-28T23:06:02+00:002017-11-28T23:06:02+00:00Re: Use of a COINDEXED OBJECT with ATOMIC subroutines https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=comp-fortran-90;ba6eeff8.1711On Nov 28, 2017, at 6:01 PM, Bill Long <longb@cray.com<mailto:longb@cray.com>> wrote:<br><br>On Nov 28, 2017, at 4:17 PM, Vipul Parekh <parekhvs@GMAIL.COM<mailto:parekhvs@GMAIL.COM>> wrote:<br><br>Bill,<br><br>Thanks very much for your response.<br><br>Is it fair to correct to think the number of images is going to be 1<br>or greater in a coarray program and the following code variant with<br>explicit reference to image 1 is standard-conforming and the program<br>built using a conforming processor should execute? [...] Bill Long2017-11-28T23:01:16+00:002017-11-28T23:01:16+00:00Re: Use of a COINDEXED OBJECT with ATOMIC subroutines https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=comp-fortran-90;51605896.1711> On Nov 28, 2017, at 4:17 PM, Vipul Parekh <parekhvs@GMAIL.COM> wrote:<br>><br>> Bill,<br>><br>> Thanks very much for your response.<br>><br>> Is it fair to correct to think the number of images is going to be 1<br>> or greater in a coarray program and the following code variant with<br>> explicit reference to image 1 is standard-conforming and the program<br>> built using a conforming processor should execute? [...] Vipul Parekh2017-11-28T17:17:51-05:002017-11-28T17:17:51-05:00Re: Use of a COINDEXED OBJECT with ATOMIC subroutines https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=comp-fortran-90;12110ef5.1711Bill,<br><br>Thanks very much for your response.<br><br>Is it fair to correct to think the number of images is going to be 1<br>or greater in a coarray program and the following code variant with<br>explicit reference to image 1 is standard-conforming and the program<br>built using a conforming processor should execute?<br><br>--- begin snippet ---<br>use, intrinsic :: iso_fortran_env, only : atomic_int_kind [...]Bill Long2017-11-28T17:23:48+00:002017-11-28T17:23:48+00:00Re: Use of a COINDEXED OBJECT with ATOMIC subroutines https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=comp-fortran-90;45390fa3.1711Sems like a compiler bug. Your example code works with the compiler I tried.<br><br>Two basic concepts:<br><br>1) An image selector that selects the local image has the same effect as not specifying an image selector at all (assuming a coindexed object is allowed in that context). So, [this_image()] is somewhat pointless in practice. [...] Vipul Parekh2017-11-28T10:36:14-05:002017-11-28T10:36:14-05:00Use of a COINDEXED OBJECT with ATOMIC subroutines https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=comp-fortran-90;5e700f66.1711Is the following code standard-conforming? A processor I tried<br>compiles the code alright however it encounters a run-time exception<br>with access violation during the ATOMIC_REF instruction on coarray<br>image 1.<br><br>--- begin snippet ---<br>use, intrinsic :: iso_fortran_env, only : atomic_int_kind<br><br>type :: t<br>integer(kind=atomic_int_kind) :: i<br>end type<br><br>integer(kind=atomic_int_kind) :: vali<br>type(t), save :: foo[*]<br><br>if ( this_image() == 1 ) then [...]Ian Chivers2017-11-22T16:51:37-00:002017-11-22T16:51:37-00:00Re: Pathscale bust? https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=comp-fortran-90;297bbd79.1711The most recent download of the compiler suite<br>I have is dated 19/June/2017.<br><br>I can't find anything later than that.<br><br>Ian Chivers<br><br>-----Original Message-----<br>From: Fortran 90 List [mailto:COMP-FORTRAN-90@JISCMAIL.AC.UK] On Behalf Of Bill Long<br>Sent: 22 November 2017 16:02<br>To: COMP-FORTRAN-90@JISCMAIL.AC.UK<br>Subject: Re: Pathscale bust?<br><br>> On Nov 22, 2017, at 7:55 AM, Anton Shterenlikht <mexas@BRISTOL.AC.UK> wrote:<br>><br>> https://www.hpcwire.com/2017/03/23/hpc-compiler-company-pathscale-seek<br>> s-life-raft/<br>><br>> "March 23, 2017<br>> ... PathScale has fallen on difficult times and is asking the<br>> community for help or actively seeking a buyer for its assets."<br>><br>> Anybody here has more up to date [...]Anton Shterenlikht2017-11-22T16:22:22+00:002017-11-22T16:22:22+00:00Re: Pathscale bust? https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=comp-fortran-90;66bd3361.1711Bill, thanks<br><br>I listened to an ARM talk yesterday, by Nathan Sircombe.<br>Apparently arm-flang is doing well.<br>I understand ARM are keen to send somebody to WG5/J3.<br>I was just thinking that perhaps ARM bought pathscale...<br><br>Anton Bill Long2017-11-22T16:02:07+00:002017-11-22T16:02:07+00:00Re: Pathscale bust? https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=comp-fortran-90;fa9fe826.1711> On Nov 22, 2017, at 7:55 AM, Anton Shterenlikht <mexas@BRISTOL.AC.UK> wrote:<br>><br>> https://www.hpcwire.com/2017/03/23/hpc-compiler-company-pathscale-seeks-life-raft/<br>><br>> "March 23, 2017<br>> ... PathScale has fallen on difficult times<br>> and is asking the community for help<br>> or actively seeking a buyer for its assets."<br>><br>> Anybody here has more up to date info?<br><br>The PathScale Wikipedia page claims that their web site went down in May, 2017. I don’t have any other information about the company’s status specifically. But it has seemed like PathScale was pretty tenuous financially every since going independent in 2012, often depending on one [...]Anton Shterenlikht2017-11-22T13:55:06+00:002017-11-22T13:55:06+00:00Pathscale bust? https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=comp-fortran-90;e8057a82.1711https://www.hpcwire.com/2017/03/23/hpc-compiler-company-pathscale-seeks-life-raft/<br><br>"March 23, 2017<br>... PathScale has fallen on difficult times<br>and is asking the community for help<br>or actively seeking a buyer for its assets."<br><br>Anybody here has more up to date info?<br><br>Anton Steve Lionel2017-11-13T10:14:05-05:002017-11-13T10:14:05-05:00Re: Fortran 2015 -> Fortran 2018, Fortran 2020 -> Fortran 202x https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=comp-fortran-90;1baaf034.1711On 11/12/2017 3:11 PM, Steve Lionel wrote:<br>> Document N2044 at the WG5<br>> web site (https://wg5-fortran.org) has details as well as comments from<br>> members.<br><br>Correction - N2144, not N2044. Also the link for N2144 was broken on the<br>web site, now fixed. My apologies.<br><br>Steve Steve Lionel2017-11-12T15:13:33-05:002017-11-12T15:13:33-05:00Fortran 2015 -> Fortran 2018, Fortran 2020 -> Fortran 202x https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=comp-fortran-90;d3e152b3.1711WG5 has polled its members and decided to change the informal name of<br>the next Fortran standard revision from "Fortran 2015" to "Fortran<br>2018", in order to reflect the year of publication. This puts Fortran in<br>the company of other language standards, and even has some history in<br>Fortran itself (Fortran 90 changed names three times, Fortran 2003 was<br>originally going to be called Fortran 2000. Document N2044 at the WG5<br>web site (https://wg5-fortran.org) has details as well as comments from<br>members. [...] Steve Lionel2017-11-10T14:50:04-05:002017-11-10T14:50:04-05:00Re: Misapplication of C1283 for pointer argument? https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=comp-fortran-90;fde0c174.1711On 11/10/2017 2:32 PM, Neil Carlson wrote:<br>> Thanks for pointing out those notes Steve. But they still leave me<br>> confused about this particular case. Perhaps I'm just being extra dense.<br>><br>> The set of all conceivable side effects from<br>><br>> integer, pointer :: a(:)<br>> [...]<br>> a = 1<br>><br>> appears to me to be a super set of all conceivable side effects from<br>> the more restrictive<br>><br>> integer, pointer, intent(in) :: a(:)<br>> [...]<br>> a = 1<br>><br>> Is that not true? Yet [...]Neil Carlson2017-11-10T12:32:49-07:002017-11-10T12:32:49-07:00Re: Misapplication of C1283 for pointer argument? https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=comp-fortran-90;d624e88b.1711Thanks for pointing out those notes Steve. But they still leave me<br>confused about this particular case. Perhaps I'm just being extra dense.<br><br>The set of all conceivable side effects from<br><br>integer, pointer :: a(:)<br>[...]<br>a = 1<br><br>appears to me to be a super set of all conceivable side effects from the<br>more restrictive<br><br>integer, pointer, intent(in) :: a(:)<br>[...]<br>a = 1 [...]Vipul Parekh2017-11-10T14:23:25-05:002017-11-10T14:23:25-05:00Re: Misapplication of C1283 for pointer argument? https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=comp-fortran-90;b547735e.1711On Fri, Nov 10, 2017 at 11:41 AM, Neil Carlson <neil.n.carlson@gmail.com> wrote:<br>> ..<br>><br>> I'm trying to understand why this is a constraint (if indeed it was really<br>> intended to be a constraint).<br><br>The supposed exception when INTENT is omitted (or is INOUT) doesn't<br>make sense; perhaps someone can enlighten the readers. Because it<br>permits code with side effects such as: [...]Steve Lionel2017-11-10T12:10:26-05:002017-11-10T12:10:26-05:00Re: Misapplication of C1283 for pointer argument? https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=comp-fortran-90;f138294c.1711On 11/10/2017 11:41 AM, Neil Carlson wrote:<br>> I'm well aware that this is all about the PURE attribute.<br>><br>> On Fri, Nov 10, 2017 at 9:30 AM, Vipul Parekh <parekhvs@gmail.com<br>> <mailto:parekhvs@gmail.com>> wrote:<br>><br>> [...] Under<br>> the circumstances you show the target can be any object that<br>> ordinarily would not be permitted to appear in a variable definition<br>> context in a pure procedure, so the error makes sense.<br>><br>><br>> Except that without the INTENT it is allowed in a pure procedure.<br>><br>> I'm trying to understand why this is a constraint [...]Neil Carlson2017-11-10T09:41:09-07:002017-11-10T09:41:09-07:00Re: Misapplication of C1283 for pointer argument? https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=comp-fortran-90;7fccb63d.1711I'm well aware that this is all about the PURE attribute.<br><br>On Fri, Nov 10, 2017 at 9:30 AM, Vipul Parekh <parekhvs@gmail.com> wrote:<br><br>> [...] Under<br>> the circumstances you show the target can be any object that<br>> ordinarily would not be permitted to appear in a variable definition<br>> context in a pure procedure, so the error makes sense.<br>> [...]Vipul Parekh2017-11-10T11:30:39-05:002017-11-10T11:30:39-05:00Re: Misapplication of C1283 for pointer argument? https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=comp-fortran-90;2533beb0.1711On Fri, Nov 10, 2017 at 9:52 AM, Neil Carlson <neil.n.carlson@gmail.com> wrote:<br>>..<br>><br>> The error messages are all to the effect of "a cannot appear in a variable<br>> definition context in a pure procedure". This language suggest C1283 (in<br>> F2008 12.7) as the basis for the error. I don't understand why this would<br>> be an error as the INTENT applies to the pointer and not its target, .. [...]Neil Carlson2017-11-10T07:52:28-07:002017-11-10T07:52:28-07:00Misapplication of C1283 for pointer argument? https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=comp-fortran-90;5318f3e4.1711All three compilers I have access to object to the assignment statement in<br><br>pure subroutine foo(a)<br>integer, pointer, intent(in) :: a(:)<br>a = 1<br>end subroutine<br><br>Yet all are okay with<br><br>pure subroutine foo(a)<br>integer, pointer :: a(:)<br>a = 1<br>end subroutine<br><br>The error messages are all to the effect of "a cannot appear in a variable<br>definition context in a pure procedure". This language suggest C1283 (in<br>F2008 12.7) as the basis for the error. I don't understand why this would<br>be an error as the INTENT applies to the pointer and not its target, which<br>is what [...]John Reid2017-11-08T16:34:17+00:002017-11-08T16:34:17+00:00Re: IEEE_COPY_SIGN - kinds of X and Y? https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=comp-fortran-90;cb8164ce.1711Anton Shterenlikht wrote:<br>> 17.11.3 IEEE_COPY_SIGN in p3-4 says:<br>> "3. Arguments. The arguments shall be of type real.<br>> 4. Result Value. The result has the absolute value of X..."<br>><br>> It seems the kind of Y is not important, i.e.<br>> the kind of the result is the same as the kind of X.<br>> Also it seems there is no requirement that kinds<br>> of X and Y are the same. [...] Anton Shterenlikht2017-11-08T16:18:54+00:002017-11-08T16:18:54+00:00IEEE_COPY_SIGN - kinds of X and Y? https://www.jiscmail.ac.uk:443/cgi-bin/webadmin?A2=comp-fortran-90;9f41c3ea.171117.11.3 IEEE_COPY_SIGN in p3-4 says:<br>"3. Arguments. The arguments shall be of type real.<br>4. Result Value. The result has the absolute value of X..."<br><br>It seems the kind of Y is not important, i.e.<br>the kind of the result is the same as the kind of X.<br>Also it seems there is no requirement that kinds<br>of X and Y are the same.<br>I guess it cannot matter. [...]