Re: RFC: Building a minimal libgfortran for nvptx
On Nov 4 2014, Jeff Law wrote: On 11/04/14 09:11, Jakub Jelinek wrote: The point is, if the target can implement just a subset of the Fortran (or C or C++) standards, then ideally if you use anything that is not supported would just cause always host fallback, the code will still work, but will not be offloaded. So even supporting a subset of the standard is worthwhile, usually one will just offload the most performance critical parts of his code. As I see it, this isn't a free-standing compilation environment, but a component of one for heterogeneous architectures. There are similar issues for some embedded systems, in several languages. That doesn't fit well with the current build model, unfortunately :-( Also note there's a reasonable chance that the GPUs will continue to evolve and will be able to support more of the standard language features. Not sure if they'll ever do the IO side of Fortran, but they could always surprise us. I am almost certain that the current situation is going to change significantly, probably by 2020, but there is as yet no indication of how. And it wouldn't be entirely reasonable to say nothing should be done for this sort of use until the situation becomes clear. Regards, Nick Maclaren.
Re: [PR libfortran/62768] Handle filenames with embedded nulls
On Sep 18 2014, Janne Blomqvist wrote: Apparently libgfortran is not compiled with -Werror, at least not for crosses. Maybe -Werror is there for native but I'm not sure as I see some warning: array subscript has type 'char' [-Wchar-subscripts] which seems generic and also some others. Though no more than can be fixed or excepted, IMHO. No, Werror isn't used. It was tried, but apparently caused issues. From the changelog: 2008-06-13 Tobias Burnus bur...@net-b.de * configure.ac (AM_CFLAGS): Remove -Werror again. I have a vague recollection that there were issues with system headers on non-glibc targets. It would be nice if Werror was used by default, I think we've had a few cases where bugs have slipped past due to it. I wasn't involved, but that sounds more than just likely! I have had that experience with several options, including Werror, pedantic and specific standards ones. My experience is that most vendors clean up at least the standard C headers with time, and usually the more basic POSIX ones, but any others often remain beyond redemption. And what is not going to help is the ongoing incompatibilities in de jure and de facto standards. I have certainly seen standard headers that would compile only with specific language selection options. Oh, yes, their COMPILER supported other ones - you just couldn't use some important system headers with them :-( If I get time, I will look at the libfortran header use and see if I can make any useful specific comments. Regards, Nick Maclaren.
Re: [patch, fortran] Function call optimization
On Mar 18 2011, Tobias Burnus wrote: Thomas Koenig wrote: + if (!(*e)-value.function.esym-attr.pure + !(*e)-value.function.esym-attr.implicit_pure + !(*e)-value.function.esym-attr.elemental) + return 0; I have not followed the discussion nor have I fully read the patch, but what's the reason for allowing ELEMENTAL functions? I understand the PURE and the implicitly pure part. But without looking at the scalarizer, I would assume that the same reasons which speak against non-elemental impure functions should also speak against IMPURE ELEMENTAL functions, don't they? Impure elemental procedures came in only in Fortran 2008, if I understand it. I don't know for certain, but my guess is that they are there primarily to allow diagnostics in elemental procedures. What that means about their required semantics is a bit unclear Regards, Nick Maclaren.
Re: Implement stack arrays even for unknown sizes
On Apr 8 2011, Michael Matz wrote: It adds a new option -fstack-arrays which makes the frontend put all local arrays on stack memory. ... Excellent! I haven't rechecked performance now, but four months ago this was the result for the fortran benchmarks in cpu2006: There is actually a much better approach, which was done in Algol 68 and seems now to be done only in Ada. As far as the compiler implementation goes, it is a trivial variation on what you have done, but there is a little more work in the run-time system. That is to use primary and secondary stacks. The primary is for the linkage, scalars, array descriptors and very small, fixed-size arrays. The secondary is for all other arrays with automatic scope. You get all of the benefits that you mention, because both are true stacks, and the scope of the secondary stack is controlled by that of the primary. You need a single secondary stack pointer (and preferably limit, for checking), which can be global variables. If a procedure uses the secondary stack, it needs to restore it on leaving, or when leaving a scope including an allocation - but you have already implemented that! The reason that it gives better performance is locality. Because the primary stack is much smaller and contains the critical scalars and pointers to arrays etc., calling procedures can involve MANY fewer cache misses. It also reduces the number of array overflows that cause complete chaos, because most small bounds errors trash other data, not constants or linkage. It also helps with Unixoid systems with fixed (and small) stack limits, because the secondary stack is just another data segment. I would love to say that I would try to work on this, but I really can't promise to do anything else until I have delivered on some of my long overdue promises. But I am very happy to discuss details - not that there ARE many more than I have described! Regards, Nick Maclaren.
Re: Implement stack arrays even for unknown sizes
On Apr 11 2011, H.J. Lu wrote: Is that possible to raise stack limit when -fstack-arrays is used? In some systems, yes. In others (including most Unices), not without evil contortions that will assuredly break something else (like debuggers and some MPIs). Regards, Nick Maclaren.
Re: Implement stack arrays even for unknown sizes
On Apr 12 2011, Michael Matz wrote: On Mon, 11 Apr 2011, Steven Bosscher wrote: Isn't there a way to put a maximum on the size of the arrays on stack, e.g. -fstack-arrays-limit= or something like that? Not without generating contorded code. The problem is that these arrays are variable length, hence runtime tests would be required, branching to malloc or stack_save/alloca, and also for the deallocation side, requiring a flag for branching to free or stack_restore. And as we use the variable length facilities this is actually not controllable in such a way, the frontend doesn't generate alloca calls at all. It would almost certainly be cleaner and simpler to use a secondary stack than to have such dynamic testing. It is very similar (conceptually) to the dynamic code that switches between inline and library code for sizes of DO-loop or array on some specialist HPC compilers. And that gets very messy, very fast. Regards, Nick Maclaren.
Re: [Patch, libfortran] Thread safety and simplification of error printing
On May 8 2011, Janne Blomqvist wrote: the error printing functionality (in io/unix.c) st_printf and st_vprintf are not thread-safe as they use a static buffer. ... While this patch makes error printing thread-safe, it's no longer async-signal-safe as the stderr lock might lead to a deadlock. So I'm retracting this patch and thinking some more about this problem. It's theoretically insoluble, given the constraints you are working under. Sorry. It is possible to do reasonably well, but there will always be likely scenarios where all you can do is to say Aargh! I give up. Both I and the VMS people adopted the ratchet design. You have N levels of error recovery, each level allocates all of the resources it needs before startup, and any exception during level K increases the level to K+1 and calls the level K+1 error handler. When you have an exception at level N, you just die. That imposes the constraint that all diagnostics have a fixed upper bound on the resources they need (not just buffer space, but that's the main one). It's a real bummer when the system has some critical resources that you can't reserve, so you have to treat an allocation failure as an exception, but buffer space is not one such. That also tackles the thread problem, not very satisfactorily. If a resource needs to be locked, you can try to get it for a bit, and then raise a higher exception if you can't. And, typically, one or more of the highest levels are for closing down the process, and simply suspend any subsequent threads that call them (i.e. just leave them waiting for a lock they won't get). Yes, it's not pretty. But I don't know how to do better. Regards, Nick Maclaren.
Re: [Patch, libfortran] Thread safety and simplification of error printing
Sorry - I should have clarified that ANYTHING that can't be used independently in multiple threads and at multiple levels in the same thread counts as a resource, and that includes stderr. Regards, Nick Maclaren.
Re: [Patch, libfortran] Thread safety and simplification of error printing
On May 8 2011, Janne Blomqvist wrote: It's theoretically insoluble, given the constraints you are working under. Sorry. It is possible to do reasonably well, but there will always be likely scenarios where all you can do is to say Aargh! I give up. Well, I realize perfection is impossible, so I'm settling for merely improving the status quo! Very reasonable, given the problem. Where the effort increases rapidly with the reliability, not being too fancy is a sound strategy. I think in our case the situation is a bit easier in that we're not trying to recover from a serious failure, merely print some diagnostic information without getting stuck in a deadlock. I wasn't trying to do much more! I was mainly trying to maximise the chances of files being closed cleanly and appropriate diagnostics being produced. Once there was a serious error, I didn't allow the program to continue. But I did allow user-written exception handlers (which could only return - NOT jump out). Even that was hard enough :-( Regards, Nick Maclaren.
Re: [Patch, libfortran] PR 48931 Async-signal-safety of backtrace signal handler
On May 24 2011, FX wrote: One solution could be to search the PATH for addr2line during library initialization (where we don't need to be async-signal-safe), and then store it somewhere and use it in show_backtrace(). That's one way. Another way is just to store a copy of the PATH during initialization, and only search addr2line when really needed (which can be done with a static buffer and a series of call to execve(), can't it?) Well, yes, but it is better design to do as little as possible in such handlers. No matter what POSIX says, calling fork or exec is intrinsically problematic - for example, ANY signal (including SIGCONT!) can cause chaos if it is received in such circumstances, and the actual rules for which processes get which signals are foul beyond belief, even when the term 'rules' makes sense :-( That favours Janne's approach. Regards, Nick Maclaren.
Re: [fortran, patch] Add Fortran 2003 IEEE intrinsic modules
On Nov 21 2013, FX wrote: Note: Gradual underflow control is implemented as not supported by the processor (its SUPPORT function returns false, and the GET and SET procedures abort if you call them), because we probably don't have targets where it would work (and I don't think people use it much, if at all). That's explicitly allowed by the standard. That's a reasonable decision, but it is actually used at least ten times as much as everything else put together, possibly a hundred times as much. However, it is used in the form of selecting hard underflow using a compilation option, and not within the program. You certainly DO have targets where it would work, even dynamically within the program, and I think that it could be done even on x86. That isn't the same as it should be done, of course! I should have to study the various architectures to remind myself of how to do it, but there were some which had a simple flag and I am pretty sure that they are among gfortran's current targets. How many of the CPUs support that flag is another matter On at least the x86, it would have to be done by writing a floating-point interrupt handler, which I think can be done without privilege and could be made to work. It wouldn't be a lot of code, but would need some very low-level hacking. It is getting rarer, as the support of denormalised numbers gets less direly inefficient and they cause less chaos in the libraries, but there are still codes that need hard underflow and quite a few algorithms that work better with it. Regards, Nick Maclaren.
Re: [fortran, patch] Add Fortran 2003 IEEE intrinsic modules
On Nov 21 2013, Uros Bizjak wrote: Indeed, 387/SSE has flush-to-zero modes. But other APIs do not (glibc, SysV, AIX). I'm perfectly willing to add it, especially to 387/SSE, if given a bit of help (someone to write the assembly code). Just set FTZ bit in mxcsr. Please see libgcc/config/i386/crtfastmath.c, this mode is used when -ffast-math is used. Does that work for all of Intel's zoo of floating-point mechanisms? Even if gfortran doesn't use all of them, it is important to at least know which it works for and which it does not. My understanding of the architecture is that all of x87, MMX, SSE and AVX are potentially different in this respect :-( Regards, Nick Maclaren.
Re: [fortran, patch] Add Fortran 2003 IEEE intrinsic modules
On Nov 21 2013, Joseph S. Myers wrote: On Thu, 21 Nov 2013, FX wrote: Indeed, 387/SSE has flush-to-zero modes. But other APIs do not (glibc, SysV, AIX). Note that glibc libm functions may not work when called in a flush-to-zero mode, only in modes that can be established by the fenv.h functions. Well, that's two clear bugs :-( If, as you say, they may not work at all in combination with -ffast-math, that's one. Setting __STDC_IEC_559__ to 1 in combination with -ffast-math is another, given that C99 and C11 reference ISO/IEC 10559 (1989). Regards, Nick Maclaren.
Re: [fortran, patch] Add Fortran 2003 IEEE intrinsic modules
On Nov 21 2013, FX wrote: That's a reasonable decision, but it is actually used at least ten times as much as everything else put together, possibly a hundred times as much. I believe we are in pretty different parts of the community. Around me I rarely see it used, while people check for nans, infinities, and exception flags often. Also, aborting on certain floating-point exceptions is widely used as a debugging aid. Probably. My experience is more with Fortran, generally, including portable Fortran and HPC, than with gfortran as such. It is only very recently that IEEE 754 support has been complete enough in most hardware (let alone software!) to be worth considering for even moderately portable programs. This is related to the vast reduction in architectural diversity that we have seen over the past couple of decades. The people who use flush-to-zero most are the 'HPC community', which includes a very high proportion of scientific programmers using desktops. But, as I said, support for IEEE 754 denormalised numbers is becoming less of a problem, though it was a major obstacle to performance even a decade ago and still is on some specialist systems and some older ones. However, it is used in the form of selecting hard underflow using a compilation option, and not within the program. You certainly DO have targets where it would work, even dynamically within the program, and I think that it could be done even on x86. That isn't the same as it should be done, of course! Indeed, 387/SSE has flush-to-zero modes. But other APIs do not (glibc, SysV, AIX). I'm perfectly willing to add it, especially to 387/SSE, if given a bit of help (someone to write the assembly code). As most Fortran compilers were and are specific to a fairly small number of architectures, and often have a lot of architectural dependence in the optimisation and libraries, they aren't restricted by glibc and SysV APIs. IBM has always been an extreme outlier, and POWER used to be the only hardware on which denormalised numbers were not catastrophically slow (i.e. they were only 4 times slower, not 100+ times), and poorly supported in the library. But that has changed over the past decade, I would like to offer to write some example code, but it is some years since I was involved with anything other than x86 or at low levels such as this, and have a lot else going on. If I do divert and look at the x86 in detail, I will certainly post any useful assembler. Sorry :-( Regards, Nick Maclaren.
Re: wide-int, fortran
On Nov 23 2013, Andrew Pinski wrote: On Sat, Nov 23, 2013 at 12:16 PM, Steve Kargl s...@troutmask.apl.washington.edu wrote: On Sat, Nov 23, 2013 at 11:21:21AM -0800, Mike Stump wrote: Richi has asked the we break the wide-int patch so that the individual port and front end maintainers can review their parts without have to go through the entire patch. This patch covers the fortran front end. Ok? + *logical = wi::eq_p (t, 0) ? 0 : 1; I can't find the meaning of :: in n1256.pdf. What does this do? wi:: eq_p means the function eq_p inside the wi struct. But you can't tell that from the code - wi might be a namespace, and eq_p might be a class. If there is a clear description of the subset of C++ that the front-end is allowed to use, a pointer to it for the benefit of Fortran/C/Ada/whatever people would be useful. But that's an aside from this thread. Also, given the complete lack of a description of what this patch does and no pointer to a discussion of what this patch does, and no description of its benefit to gfortran, I vote no. The general description was in a different email: http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02877.html The main benefit is it allows for targets to support wider integer than two times HOST_WIDE_INT. So gfortran, is that it connects to the rest of the middle-end of GCC. Hmm. Looking at that makes me none the wiser, and even a web search doesn't do more than tell me the same aspects. Given that Fortran has somewhat different constraints on type widths than C, it would be very useful to know exactly what you mean by that. C++ is almost entirely irrelevant here. Now, obviously to an implementor, it doesn't mean unlimited-width types, but does it (a) allow implementations to use hardware/firmware/emulated built-in types however wide they are, (b) allow arbitrary-width types, or (c) something else? In all cases, I can see implementation issues in gfortran that do not arise in gcc, but they are different between those models. So I agree that some clarification would be a good idea, to avoid introducing secondary problems by accident. Quite likely there will be none, but it's hard to tell. Regards, Nick Maclaren.
Re: wide-int, fortran
On Nov 24 2013, Kenneth Zadeck wrote: Thank you for your posting. That certainly clears up my understanding. If there is a clear description of the subset of C++ that the front-end is allowed to use, a pointer to it for the benefit of Fortran/C/Ada/whatever people would be useful. But that's an aside from this thread. There is a saying in the US that you can always tell the pioneers because they are the ones with the arrows in their back. I feel this way with respect to C++. When this branch first went public several months ago, the wide-int class made very modest use of C++. It has publicly evolved away from that and i would now describe the usage as somewhat aggressive. I do not know if i think that this is good or bad, but i expect that because we are the first big patch to use C++ aggressively , that we are going to take some arrows. I think that using C++ even slightly aggressively without first deciding the grounds rules is a seriously bad idea. The trouble about following random pioneers is that they are very likely to lead you into a swamp, with the loss of the whole expedition. And, with C++, that is more than just likely if you follow an adventurous pioneer rather than a cautious one - it's damn-near certain :-( A useful way to think about this patch is that it is nothing but plumbing.Gcc has had a painful and long evolution from being a 32 bit compiler to a 64 bit compiler and beyond. ... Yes, but that's not my point. The main problem is that integer constant expressions in C are limited to the built-in operators, of which the only tricky ones are division and remainder (and, occasionally, multiplication) - see C11 6.6#3. Fortran is not so limited, and there are much wider requirements for expression evaluation at compile time. But at both ends of the compiler there are still limits. And my point is that this is NOT an area that separates cleanly into front and back end! However, from your description, this is one component of any solution for gfortran, and it doesn't sound as if it will cause trouble until and unless someone wants to extend gfortran to wider types. They will then have to implement the other components Regards, Nick Maclaren.
Re: [Patch, fortran, 4.9] Use bool type instead gfc_try
On Mar 19 2013, Tobias Burnus wrote: Am 19.03.2013 13:15, schrieb Janne Blomqvist: now that the Fortran frontend is C++ we can use the primitive bool type instead of inventing our own. Well, C99's bool (_Bool) was already used before. ... Er, that is making a serious mistake or, at least, running the risk of one. C++'s bool and C99's _Bool are NOT compatible types. The UK tried to get _Bool either made compatible with C++ or (preferably) dropped, but failed in both. Now, in disciplined code that does not pass such objects between C and C++, you won't see the differences. But, if EITHER assertion fails, there are some very nasty gotchas. Regards, Nick Maclaren.
Re: [Patch, fortran, 4.9] Use bool type instead gfc_try
On Mar 21 2013, Joseph S. Myers wrote: now that the Fortran frontend is C++ we can use the primitive bool type instead of inventing our own. Well, C99's bool (_Bool) was already used before. ... Er, that is making a serious mistake or, at least, running the risk of one. C++'s bool and C99's _Bool are NOT compatible types. The UK tried to get _Bool either made compatible with C++ or (preferably) dropped, but failed in both. They have been ABI-compatible in GCC ever since I implemented C99 _Bool That is another matter entirely. The code of gcc/gfortran is supposed to be compilable with other compilers, and it is foolish to make unnecessary assumptions by relying on undefined behaviour. The simple facts are that C++ does NOT define bool to be compatible with _Bool, and there are enough differences in specification and semantics to make it likely that they are not the same in at least some compilers. This mess has caused and still causes no end of problems for Fortran interoperability and in standards like MPI. Regards, Nick Maclaren.
Re: [Patch, fortran, 4.9] Use bool type instead gfc_try
On Mar 22 2013, Miles Bader wrote: That is another matter entirely. The code of gcc/gfortran is supposed to be compilable with other compilers, and it is foolish to make unnecessary assumptions by relying on undefined behaviour. The simple facts are that C++ does NOT define bool to be compatible with _Bool, and there are enough differences in specification and semantics to make it likely that they are not the same in at least some compilers. This mess has caused and still causes no end of problems for Fortran interoperability and in standards like MPI. Er, maybe so, but is there actually an issue in _this_ case? Yes. There are many ways of resolving it, one of which is to state that gfortran MUST be compiled in a second pass using gcc, after having built gcc. Another is described below. From original message, it sounds like these are internal compiler interfaces, so all that matters is that they be self-consistent, and there's no external ABI involved... So as long as all the code in question is compiled with C++ and uses C++ bool, or is compiled with C99 and uses _Bool, and doesn't use any functionality that isn't in the intersection of those two types, there shouldn't be any problem, right? And that is precisely the point. The risk isn't in either of them, but in any interface that passes C++ bool from the front-end to C99 _Bool in the back end. If you exclude that, there is no problem. This is a symptom of a much wider and more serious malaise, which I do NOT think should be discussed in this thread. I am going to mention it only if someone wants to contact me about it by Email, or start a new thread. There are much more and fouller gotchas to do with C++ and C99. complex is worse, because there are serious differences in the alignment requirements, and I know that affects some systems quite badly. But the real nasties are to do with cmath and errno and, worst of all, the horrors of C99 Annex F. My point here is that it is VERY important not to read the political sound-bite that C++ is now based on C99 and assume that they are actually compatible in all respects where they have 'equivalent' facilities. They aren't. Regards, Nick Maclaren.
Re: [Patch, fortran, 4.9] Use bool type instead gfc_try
On Mar 22 2013, Tobias Burnus wrote: The front end and the backend are both compiled with the same compiler and in the same binary. Even without bootstrapping, trying to compile them with different compilers, will require some heavy editing of makefiles. Thus, it seems to be extremely unlikely that different compilers have ever been used. The change from C99's bool to C++'s bool occurred for the whole compiler. Before 4.7 the default was to compile GCC with C (though it had been modified to be also compilable with C++); in 4.7, the default compiler was C++ but C was still supported. And since GCC 4.8 C++ features are used, which makes GCC only compilable with C++. Actually, the FE itself so far uses nearly no C++ features, it is the middle end which used them (which 'leak' to the front end via some helper macros/functions). Ah. I misunderstood what people said. Yes, if C++ mode is used for the whole compiler, everything is fine. And it remains so even if the code plays fairly clever games. I don't know if there are any compilers that generate incompatible bool types in C and C++ modes, but it wouldn't surprise me if there were. In terms of the discussion, bool is used for quite some time in gfortran (the frontend) and libgfortran. When GCC was compiled with C, that was C99's _Bool. Since the compiler is compiled as C++, it is C++'s bool. Thus, C/C++'s bool are never mixed. Then there is no problem. Sorry about the red herring - I misunderstood what people said. Unfortunately, from personal experience, the majority of people even on WG14 and WG21 do not understand the incompatibilities, which is why I posted. Regards, Nick Maclaren.
Re: [patch, fortran] Handling of .and. and .or. expressions
On Jun 27 2018, Janus Weil wrote: It is very unfortunate, and it means that the Fortran standard simply does not provide a measure for "more correct" here. (My common-sense drop-in notion of correctness would be that an optimization is 'correct' as long as it can be proven to not change any results.) Actually, yes, it does. Fortran 2008 7.1.4p2, 7.1.5.2.4p2, 7.1.5.3.2p1, 7.1.5.4.2p1, 7.1.5.5.2p1 and 7.1.6.3p1/2. The problem is that the Fortran standard has never resolved the inconsistency that OTHER side-effects in functions are not explicitly forbidden - it's one of the few places in Fortran where there are conforming constructs that do not have specified semantics or at least a clearly specified intention. Many, many people have tried to sort that out, and all have failed dismally. I regret that the proposal to deprecate impure functions did not succeed, because at least that would have made one sane direction clear. This has been made much worse by IEEE 754 and (worse) coarray support. Like almost all languages with threading and shared-memory, Fortran's concept of pure is satisfactory for single-threaded code but not parallel. You need the stronger concept, where a pure function does not depend on anything that might change in its scope. Look on the bright side. If you thought this problem is a mess (it is), I can assure you that most other languages get it far, far worse - often with logically impossible or contradictory promises and requirements. Regards, Nick Maclaren.
Re: [patch, fortran] Handling of .and. and .or. expressions
On Jun 27 2018, Janus Weil wrote: I'm not completely sure what you deduce from all these quoted paragraphs, but applied to the cases we're discussing here, e.g. A = .false. .and. my_boldly_impure_function() I read them as saying that a compiler does not have to invoke the function if it doesn't feel like it, but with no definite obligation to remove the call either. Do you agree? Yes. it's one of the few places in Fortran where there are conforming constructs that do not have specified semantics or at least a clearly specified intention. And I really wonder why one would do such a thing. Like, ever. I'm curious: Are there actually other such cases in Fortran that you're aware of? Yes. Some in the I/O area, where every language has problems, because systems vary so much in their basic models. Some in the coarray area, especially atomics. And a few others that I now forget where. I would have to search my files (and memory!) to remind myself of exactly which issues I was referring to, even in the areas that I can remember have such issues. But see below. Where impure functions are different is because the others are all either in extreme cases or in areas that everybody knows are iffy. You can avoid all of them (including the impure function ones) except a few of the I/O ones by writing in a highly disciplined fashion - which is the key to high RAS, and portability over long periods of time and wildly different systems. Many, many people have tried to sort that out, and all have failed dismally. I regret that the proposal to deprecate impure functions did not succeed, because at least that would have made one sane direction clear. I don't know. Why do so many people in the Fortran community have such a big problem with functions? Ok, they haven't been around in 77, but if you even bother to introduce them, why do it so half-heartedly and not just embrace them in their full beauty? Er, functions have been present in Fortran since 1958, and wording with similar effects to the current wording since 1966. This is an OLD problem :-( What is so complicated about putting a statement into the Fortran standard that says: "Ok, if this function has side effects, we definitely must evaluate it, otherwise we lose the side effects. They might be important." ??? Because that would mean a complete redesign of Fortran's semantic model of execution. It would also NOT be what a lot of people want. Inter alia, you would have to define what a side-effect is - and my point about IEEE 754 is very relevant here. Look on the bright side. If you thought this problem is a mess (it is), I can assure you that most other languages get it far, far worse - often with logically impossible or contradictory promises and requirements. I don't quite see that. Which languages are you talking about specifically? I see that C/C++ gives you a nice choice of writing A = false & my_boldly_impure_function() or A = false && my_boldly_impure_function() where the first option guarantees that your function is evaluated, while the second one allows (or even demands?) it to be optimized away. That's a much clearer situation than the Fortran mess, isn't it? Demands. But I can assure you that things are NOT that simple, and C and C++ were among the languages I was referring to. I could go into horrible detail, but this is not the place to do that. And, no, the problems are not where you probably think they are. I never counted them up, but my estimate was that they were at least ten times as numerous and serious as for Fortran and, worse, they could NOT be avoided even in very clean code. I base this on being involved with the standards, personal experience of writing highly-portable code, and experience of being the local expert of last resort in the languages. Regards, Nick Maclaren.
Re: [patch, fortran] Handling of .and. and .or. expressions
On Jun 28 2018, Steve Kargl wrote: You continue to miss my point or conveniently ignore it. You want to special case the forced evaluation of the operands in two specific logical expressions; namely, .and. and .or. If you want to force evaluation of operands, then do it for all binary operators. It's not just binary operators. It also includes code like: IF (FRED()) CONTINUE and even: X = FRED() X = 0.0 There are a zillion other possible ways in which this can arise; I have certainly seen those optimised out, as well as the constructs being discussed. I have no idea how many are currently optimised out by gfortran, still less how many may be in the future. Janus would like to know of compilers that do this sort of thing - the place to look is the ones sold by the supercomputing companies, like Cray, IBM, Hitachi and Fujitsu. I don't know how many others still maintain their own compilers. I am retired and no longer have access to any of them. Having a warning for known confusing cases (like .AND.) but not others is fine. Lots of warnings are like that. Having an option that makes a couple of constructs in the language behave in a way not required by the standard, but not others with similar properties, merely adds a new gotcha. Regards, Nick Maclaren.
Re: [patch, fortran] Handling of .and. and .or. expressions
On Jun 28 2018, Toon Moene wrote: And - most interesting - that's how Fortran 77 formulated it (way before PURE/IMPURE functions entered the language): "6.6.1 Evaluation of Operands It is not necessary for a processor to evaluate all of the operands of an expression if the value of the expression can be determined otherwise. ... Or even Fortran 66 :-) 6.4 Evaluation of Expressions. A part of an expression need be evaluated only if such action is necessary to establish the value of the expression. ... When two elements are combined by an operator, the order of evaluation of the elements is optional. ... Regards, Nick Maclaren.
Re: [patch, fortran] Handling of .and. and .or. expressions
On Jun 28 2018, Janus Weil wrote: You mean compilers which transform "if (func() .and. flag)" into "if (flag .and. func())", and then possibly remove the call? If yes, could you tell us which compilers you are talking about specifically? I am 70, and haven't supported multiple compilers for over a decade! No, I can't remember. If I recall, the most widespread optimising compiler of the 1980s did (IBM Fortran Q), as well as several others of that era. I can't remember which of those I have used recently did, because it was not something I looked at - I had known for ages that it was likely, so followed the simple rule that ANY function call might disappear. Yes, even in statements like X = FRED(), because the value of X might not be needed. Btw, effectively pure functions which are not marked with the PURE attribute should hopefully not be a problem, since gfortran has implicit_pure detection that should deal with that. (However, it might need some further improvements, I think.) Most practical programmers use external libraries, often supplied as binary. The only information the compiler can rely on is whether the function is marked as PURE. It's moot whether such a warning should rely on implicit pure detection, because the gotcha with doing so is the programmer modifies the function, adds a side-effect, does NOT recompile the calling code, and can't work out why nothing has changed! Been there - done that :-) Response to self on locating it: you IDIOT, Nick! Regards, Nick Maclaren.
Re: [patch, fortran] Handling of .and. and .or. expressions
On Jun 28 2018, Janus Weil wrote: if we add a warning, we should add it both for if (flag .and. func()) and for if (func() .and. flag) because the standard also allows reversing the test (which my original test did). well, I really don't want to warn for hypothetical problems. Since we currently do not apply such an optimization, we should not warn about it (unless you find any other compiler which actually does). I have used such compilers; they used to be fairly common and may still be. I agree with Thomas, and think it should be in -Wextra. -Wsurprising is in -Wall, and this is done in so many programs (usually with not-pure functions that are actually pure, or effectively so) that the number of warnings would put people off using -Wall. Basically, it it is warning people about a feature of Fortran that they might not know, can almost always be resolved by modernising the code, and might just cause trouble in future gfortrans or some other compilers. It is not in the same class as the examples for -Wsurprising in the documentation. It's far more similar to those for -Wextra. I am looking at: https://gcc.gnu.org/onlinedocs/gcc-5.5.0/gfortran/Error-and-Warning-Options.html Regards, Nick Maclaren.
Re: What to do with argument mismatches in Fortran (was: [patch, fortran] Fix PR 91443)
On Aug 20 2019, Steve Kargl wrote: On Tue, Aug 20, 2019 at 09:56:27PM +0200, Thomas Koenig wrote: I wrote: > Committed as r274551. Well, this revision appears to have woken quite a few bugs from their slumber. While argument mismatch was always illegal, it seems to have been a common idiom at one time. And, like almost all bad habits of the past, SPEC also has this (see PR 91473, where you can see thatt a rather large number of SPEC tests now require -std=legacy). Yes and no. In de jure standard Fortran, it always has been illegal, but the de facto standards were not always the same. This caused a LOT of debate in the early 1970s :-) It was also an essential facility, for various reasons, none of which have applied since Fortran 90. So, what to do? Is -std=legacy the right option, or should we add something different (like -faccept-argument-mismatch), which we could then set by -std=legacy? And is there anything special we should be doing after we have diagnoses the problem, if the user simply wants to run the code? Perhaps, something along the lines of -fallow-invalid-boz I recently introduced. Issue an error be default, but have -fallow-argument-mismatch downgrades the error to a warning. The only way to disable the warning is with -w. Personally, if gfortran can detect an error in code, I think it should report the error to the user. I agree. Regards, Nick Maclaren,
Re: [RFC] Characters per line: from punch card (80) to line printer (132) (was: [Patch][OpenMP/OpenACC/Fortran] Fix mapping of optional (present|absent) arguments)
On Dec 5 2019, Michael Matz wrote: (oh a flame bait :) ) Quite. I shall try not to make it too much worse, but there's another point that needs mentioning. I find long names hard to read, with either short or long lines, especially when combined with variants like negotiate_twisty_little_passage, and negotiate_little_twisty_passage. And extending line lengths will probably encourage the use of longer names. As people say, there are conficting requirements, but I side with you in preferring 80 column lines. Actually, I tend to use less, but that's because of the (still current) frequency with which utilities make a mess of lines exactly 80 columns long in an 80 column field. Regards, Nick Maclaren.
