size of a derived type containing pointers...
in [Fortran]
|
Prev: calling a recursive function in fortran 77 ?
Next: equivalent in fortran of the IDL "where" function
From: robert.corbett on 26 Mar 2010 03:15 On Mar 25, 11:57 pm, nos...(a)see.signature (Richard Maine) wrote: > <robert.corb...(a)sun.com> wrote: > Now that I'm retired, I have a lot more limited selection of compilers > to experiment with to make such lists. The NAG compiler would account > for 50% of the ones I have handy at the moment on this machine. Yes, the > other 50% appears to have a LOC. By my measurement, 50% is a lot less > than "almost always." Before I retired, I had a lot larger selection of > compilers that I could test, but the NAG one (well, ones) probably > accounted for more like 90% of my use. I agree that there might be another, I just cannot think of what it might be. The compilers to which I currently have easy access all support LOC, either as an intrinsic (the right way) or as an external function. The external function is undesirable for implementations that need to work in 32- and 64-bit enviornments. I was surprised NAGWare does not support it yet. I know NAGWare started out requiring code to be pretty strictly standard conforming, but they had to give ground on many fronts already. > Of course, I'm thinking only about reasonably current f90+ compilers. If > one allows older f90 compilers as well as current ones, I'd go from > suspecting so to being willing to bet on it. > > And if one allows f77 compilers, then lots of them didn't have LOC, > paticularly if one looks for that exact spelling. Yes, I can think of a few Fortran vendors in this area who went out of business refusing to support the nonstandard extensions their customers wanted. Bob Corbett
From: robert.corbett on 26 Mar 2010 03:28 On Mar 26, 12:03 am, nos...(a)see.signature (Richard Maine) wrote: > <robert.corb...(a)sun.com> wrote: > > One bit of > > nastiness regarding numeric sequence types is that the > > standards require them to be laid out in ways that can > > violate some machines' data alignment requirements. > > That kind of issue isn't new to numeric sequence types either. Common > has had that issue for a long time, notably with double precision, which > can end up misaligned. I recall dealing with some f77 compilers that > just could not compile valid f77 code into something that actually > worked if there were such common misalignments. Others violated the > standard's layout requirements (thus possibly breaking things) in order > to make it work. I recall SUN at least having an option to make the code > conform to the standard's layout requirements and still work, but it > gave you a prominent warning that the result would run slowly. Oracle Solaris Fortran and its Sun Fortran predecessors produce the standard required layouts for both common blocks and most numeric sequence types by default. Yes, there are cases where it costs significant performance on some hardware. I along with others pushed hard to have the hardware handle misaligned accesses more efficiently when the SPARC V9 architecture was designed (you can find the results of that in the SPARC V9 architecture manual), but the hardware designers chose to ignore those bits in their implementations. Given the magnificent job the designers of the original UltraSPARC chip did, it is hard to fault them for what they left out. Bob Corbett
From: glen herrmannsfeldt on 26 Mar 2010 03:26 Richard Maine <nospam(a)see.signature> wrote: > <robert.corbett(a)sun.com> wrote: >> One bit of >> nastiness regarding numeric sequence types is that the >> standards require them to be laid out in ways that can >> violate some machines' data alignment requirements. > That kind of issue isn't new to numeric sequence types either. Common > has had that issue for a long time, notably with double precision, which > can end up misaligned. I haven't heard about this one recently, so I thought that the standard may have changed. > I recall dealing with some f77 compilers that > just could not compile valid f77 code into something that actually > worked if there were such common misalignments. Others violated the > standard's layout requirements (thus possibly breaking things) in order > to make it work. I recall SUN at least having an option to make the code > conform to the standard's layout requirements and still work, but it > gave you a prominent warning that the result would run slowly. I used to know the OS/360 routines for that. They trap the interrupt that occurs for a misaligned operand, copy it to appropriately aligned memory, execute the offending instruction with the new address, then fix up everything so that it looks like it should. It takes many instructions to do all that. Even more, though, the imprecise interrupt on the 360/91 didn't allow such routines to find the operand. S/370 allows for misaligned data, though it may still run slower. As for newer machines, most RISC processors require data to be appropriately aligned. IA32 does not, but does indicate that aligned data will likely run faster. -- glen
From: Phred Phungus on 26 Mar 2010 05:14 glen herrmannsfeldt wrote: > Richard Maine <nospam(a)see.signature> wrote: > (snip) > >> I would say that the most obvious culprit is that, as per the comment, >> C_SIZEOF is an f2008 feature. Since GFortran doesn't (yet?) claim to be >> even a full f2003 compiler, much less f2008, you can't necessarily count >> on f2008 features. > >> Given that James appears to have gotten it to work with GFortran, I >> posit that perhaps this function might have been fairly recently added >> and that he has a newer version of GFortran than you do. While I don't >> know that to be so, it seems like a good guess. > > You might also want the -std=f2008 command line option. > The version I have doesn't yet allow that, but presumably > versions with Fortran 2008 features will add it. $ gfortran -D_GNU_SOURCE -std=f2008 -Wall -Wextra jb1.f90 -o out f951: error: unrecognized command line option "-std=f2008" $ uname -v #58-Ubuntu SMP Tue Dec 1 18:57:07 UTC 2009 $ which gfortran /usr/bin/gfortran $ Rats. I wonder how the notion of "snapshots" fits in with this. -- fred
From: Paul Thomas on 26 Mar 2010 05:34
On Mar 26, 10:14 am, Phred Phungus <Ph...(a)example.invalid> wrote: > glen herrmannsfeldt wrote: > > Richard Maine <nos...(a)see.signature> wrote: > > (snip) > > >> I would say that the most obvious culprit is that, as per the comment, > >> C_SIZEOF is an f2008 feature. Since GFortran doesn't (yet?) claim to be > >> even a full f2003 compiler, much less f2008, you can't necessarily count > >> on f2008 features. > > >> Given that James appears to have gotten it to work with GFortran, I > >> posit that perhaps this function might have been fairly recently added > >> and that he has a newer version of GFortran than you do. While I don't > >> know that to be so, it seems like a good guess. > > > You might also want the -std=f2008 command line option. > > The version I have doesn't yet allow that, but presumably > > versions with Fortran 2008 features will add it. > > $ gfortran -D_GNU_SOURCE -std=f2008 -Wall -Wextra jb1.f90 -o out > f951: error: unrecognized command line option "-std=f2008" > $ uname -v > #58-Ubuntu SMP Tue Dec 1 18:57:07 UTC 2009 > $ which gfortran > /usr/bin/gfortran > $ > > Rats. I wonder how the notion of "snapshots" fits in with this. > -- > fred gfortran --version Paul |