elemental function question regarding use of array slices
in [Fortran]
|
Prev: How to control/prevent cast between from complex to realvariables
Next: Variable scope: how fortran deals with undeclared variables in subroutines?
From: glen herrmannsfeldt on 17 Feb 2010 15:05 Richard Maine <nospam(a)see.signature> wrote: (snip) > That seems an odd conclusion. XLF has a history going back... gee... I > don't recall how far, but well longer than some of the IA32 compilers > have existed. I don't think that the popularity of the platform is a > very good measure of compiler robustness. No, not robustness but usage. While testing is good and important, there is nothing better than use by many people compiling many different programs for finding bugs. That would be especially true if it required a combination of not so commonly used features to expose the problem. There are stories of compiler testing by feeding in cards from the recycling bin. Probably better at detecting parser bugs than code generator bugs, though. -- glen
From: Richard Maine on 17 Feb 2010 15:53 glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote: > Richard Maine <nospam(a)see.signature> wrote: > (snip) > > > That seems an odd conclusion. XLF has a history going back... gee... I > > don't recall how far, but well longer than some of the IA32 compilers > > have existed. I don't think that the popularity of the platform is a > > very good measure of compiler robustness. > > No, not robustness but usage. While testing is good and important, > there is nothing better than use by many people compiling many > different programs for finding bugs. Then MS powerstation ought to have been great. :-) Well, I suppose there is that step after finding bugs - the one about fixing them. In any case, I think you'll find that XLF has a history of being pretty robust. While there might be nothing better than use by many people for finding bugs, that's not all there is to making a quality compiler. I think that actual experience on the particular compiler is a lot better than any such theorizing. By that measure, XLF has generaly fared pretty well.... which doesn't mean, of course, that it is bug free. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: Harald Anlauf on 17 Feb 2010 16:16 On Feb 17, 3:18 pm, Paul van Delst <paul.vande...(a)noaa.gov> wrote: > Down below is a (relatively) simple working example that indicates the issue. > > If I compile and run through the debugger I get: > > $ xlf2003 -qversion > IBM XL Fortran for AIX, V12.1 > Version: 12.01.0000.0001 > Also fails on: IBM XL Fortran for AIX, V12.1 Version: 12.01.0000.0006 Works with nagfor 5.2.668, although I get warnings during compilation which appear harmless: NAG Fortran Compiler Release 5.2(686) Warning: test_elementalslice.f90, line 26: INTENT(OUT) dummy argument B partly default initialised but otherwise unused detected at B_DESTROY@<end-of-statement> Warning: test_elementalslice.f90, line 83: INTENT(OUT) dummy argument A partly default initialised but otherwise unused detected at A_DESTROY@<end-of-statement> [NAG Fortran Compiler normal termination, 2 warnings]
From: glen herrmannsfeldt on 17 Feb 2010 16:32 Richard Maine <nospam(a)see.signature> wrote: (snip, I wrote) >> No, not robustness but usage. While testing is good and important, >> there is nothing better than use by many people compiling many >> different programs for finding bugs. > Then MS powerstation ought to have been great. :-) Well, I suppose there > is that step after finding bugs - the one about fixing them. Fortunately my previous post did not mention fixing. > In any case, I think you'll find that XLF has a history of being pretty > robust. While there might be nothing better than use by many people for > finding bugs, that's not all there is to making a quality compiler. I > think that actual experience on the particular compiler is a lot better > than any such theorizing. By that measure, XLF has generaly fared pretty > well.... which doesn't mean, of course, that it is bug free. Yes. IBM has a pretty good history of caring about their products. When I said 'testing' in the previous post, I meant testing by actual users in addition to what the maintainers do. When you 'know' how a program is supposed to work, you might be less likely to try using it a different way. I used to be pretty good at finding bugs in program, by trying the more unusual cases. Sometimes just to see that it works. That hasn't happened quite as much lately, maybe programs are getting better, or maybe I don't try as hard. -- glen
From: Paul van Delst on 18 Feb 2010 11:25
Harald Anlauf wrote: > On Feb 17, 3:18 pm, Paul van Delst <paul.vande...(a)noaa.gov> wrote: >> Down below is a (relatively) simple working example that indicates the issue. >> >> If I compile and run through the debugger I get: >> >> $ xlf2003 -qversion >> IBM XL Fortran for AIX, V12.1 >> Version: 12.01.0000.0001 >> > > Also fails on: > IBM XL Fortran for AIX, V12.1 > Version: 12.01.0000.0006 Thanks for the info! I've passed it onto the sysadmins here. > Works with nagfor 5.2.668, although I get warnings during > compilation which appear harmless: > > NAG Fortran Compiler Release 5.2(686) > Warning: test_elementalslice.f90, line 26: INTENT(OUT) dummy argument > B partly default initialised but otherwise unused > detected at B_DESTROY@<end-of-statement> > Warning: test_elementalslice.f90, line 83: INTENT(OUT) dummy argument > A partly default initialised but otherwise unused > detected at A_DESTROY@<end-of-statement> > [NAG Fortran Compiler normal termination, 2 warnings] Yeah I get a similar warning from gfortran (unused dummy argument). It's annoying and, I believe, incorrect to issue these warnings since the INTENT(OUT)-ness of the dummy means it *is* being "used" -- it's being reinitialised. I do wonder why your warning messages say "partly" default initialised? I would hope it would be wholly default initialised. cheers, paulv |