Re: using C++ STL containers in GCC/gfortran source code
On Dec 16 2016, Janus Weil wrote: What I'd like to know is: In the current state of things in GCC, is it possible/reasonable to use any of the STL containers (like std::vector, std::string, whatever) in GCC and its front ends (in particular gfortran)? That question has two parts: 1) Is it technically possible at all? Are there drawbacks/pitfalls? (In particular Jakub mentioned possible memory management issues, i.e. xmalloc vs malloc etc.) I can say something about this, which is not gcc-specific. The executive summary is that there shouldn't be any problem if you KISS, but heaven help you if you don't. Not all containers etc. are equally problematic and, as expected, the problem increase rapidly with complexity and how 'advanced' your code is. For example, the interaction between sorting on a vector, allocation and copying is, er, 'interesting' (and essentially unspecified). There are a lot of restrictions and oddities to do with iterators and any action that changes the container, which could cause trouble if anyone working on the code isn't fully au fait with them. The standard library is hopelessly ill-defined and ambiguous with regard to parallel use of a single container so, if gcc wants to allow that, it must be VERY conservative. A strict reading of the standard says that this applies to any two containers derived from the same base class, but that is almost certainly safe. The de facto library specification keeps changing, not always in fully compatible ways. For example, are containers allowed to count element accesses? They used to be, that's for sure, but it's now doubtful - see the previous paragraph for why. In my experience, it is often easier (and sometimes less code) to write your own container if you are pushing the boundaries. I doubt that gcc will need n-D arrays, but that's an extreme example (and Boost is no better). Regards, Nick Maclaren.
Re: using C++ STL containers in GCC/gfortran source code
On Dec 16 2016, Janus Weil wrote: thanks for this lengthy comment, but that's really not the kind of discussion I wanna get into here. (And I don't actually agree to all of your points, but that doesn't matter.) Sorry - I misunderstood. Regards, Nick Maclaren.
Re: Identify IEE
On Jul 3 2014, Uros Bizjak wrote: Maybe a new hook should be introduced instead: TARGET_IEEE_FORMAT_P (mode). For some targets, even soft-fp supports required rounding modes and can generate exceptions. Before doing anything, it would be a good idea to decide on what IEEE conformance means. The 1984 standard was very much an assembler-level one, and the 2008 one isn't much better. Until recently, even at the hardware level, the support for it was very patchy. Among gcc targets, there have been at least the following possibilities: Absolutely none The representation, excluding many of the exceptional values The representation in full, but not the semantics The semantics, but not the mode settings The semantics and mode settings, but not the trapping And those are only the ones that I have seen! Real gcc experts could probably add to them. Regards, Nick Maclaren.
Fwd: Re: GNU Tools Cauldron 2014 - Local information and useful links
Here is some information from a Cambridge resident. Use it as you will. Don't even think of driving anywhere near Cambridge city centre, unless you either know it or are a complete masochist. Taxis are available but expensive and have to be requested. Bus timetables are here: http://www.cambridgeshire.gov.uk/site/custom_scripts/bus_timetable_by_service.aspx A rather bad bus map is here: http://www.cambridgeshire.gov.uk/downloads/file/28/cambridge_city_bus_map If the map is correct (not certain, but likely!), to get to the Centre for Computing History from the centre, take a Citi 3 to Cherry Hinton or Fulbourn and get off just after a hump-backed railway bridge. It's not a nice walk. All of the Citi 4, Uni 4 and Madingley Road Park and Ride will get you from vaguely near St Catherine's to the William Gates Building, but you will need to find out where the stops are. Or it's a half hour fairly pleasant walk - I would recommend along King's Parade, through Senate House Passage, Garret Hostel Lane, Adams Road and the Coton footpath, onto Clerk Maxwell Road and turn left into the West Cambridge site. The only reasonable way of getting from the William Gates to Murray Edwards College (New Hall, as it used to be and is on the bus map) is walking. From there to the centre is a 25 minute walk. The Regal is near the centre. Regards, Nick Maclaren.
Re: DejaGNU gurus ahoi! (Re: Testing use of STDIN redirected etc.)
On Oct 31 2014, Janne Blomqvist wrote: what would be the best way to test stuff like two binaries communicating via a pipe, FIFO or such with DejaGNU? The gfortran testsuite has by now quite extensive coverage of all the weird and quirky corner cases of Fortran I/O behavior, but practically all these tests are done using regular files. Over the years we've had some embarrassing bugs in handling non-seekable files like terminals, FIFO's, and pipes. I believe these would have been quickly caught if only we had testing coverage. It's worse. It's much, much worse :-( When the original f77 was perpetrated, er, written, it chose a bizarre unformatted format to make BACKSPACE efficient. Inter alia, this made it hard for implementations to support things like sockets (and magnetic tape!) for unformatted files. Previously, virtually every system supported such things. BACKSPACE has been a known abomination since the 1960s, and has caused and still causes a LOT of trouble over the years, but I failed to get it even deprecated. So the first question is to decide the priority of I/O variations, including types of file and permitted operations for each connection mode. The key characteristics (in OPEN) are ACCESS, FORM and ACTION. In particular, there is disagreement on WG5 exactly what constitutes a 'file' - I have been told that magnetic tape files and sockets are not files by someone who ought to have known better. For example, does gfortran intend to support the piping of unformatted files? Not all compilers do. My apologies if gfortran/DejaGNU has already done this, but I am pretty sure not. If anyone has, please could they point me to a reference? (Something which works only on x86_64-unknown-linux-gnu and perhaps a few other "mainstream" targets where we can expect the presence of a "normal" shell environment etc., while not optimal, is certainly a lot better than what we have now.) You can do a LOT better than THAT! It would be trivial to write something that would work on any reasonably Unix-like system (including anything that supports base POSIX 1996). I have done that for system scripts and still do that for my course tests, though I no longer have access to weird and wonderful Unices to test them. You are quite right that you need to assume a reasonable shell, though you can write such tests that will work on pretty well any modern Bourne, Korn or POSIX shell, and any version of bash. The original Bourne shell was beyond redemption, but I believe that it is now completely dead. That is from experience in writing portable system scripts a decade or so back, but I am pretty sure it still holds. Regards, Nick Maclaren.
Re: DejaGNU gurus ahoi! (Re: Testing use of STDIN redirected etc.)
On Oct 31 2014, Janne Blomqvist wrote: My main aim here really is to just get the basics right before worrying about corner cases. For instance, I recall we have failed in a simple sequential reading of a access="sequential", form="formatted" unit connected to a pipe or such, because libgfortran incorrectly issued a lseek() at some point, which returned an error (since the fd wasn't seekable), and that error was then duly propagated upwards. But since the testsuite didn't test against this, it took an embarrassingly long time before that bug was found and fixed. Yes. I agree. But see my next point. So the first question is to decide the priority of I/O variations, including types of file and permitted operations for each connection mode. The key characteristics (in OPEN) are ACCESS, FORM and ACTION. In particular, there is disagreement on WG5 exactly what constitutes a 'file' - I have been told that magnetic tape files and sockets are not files by someone who ought to have known better. For example, does gfortran intend to support the piping of unformatted files? Not all compilers do. My argument in this, which I have stated many times on the mailing list and in bugzilla over the years, is that there are many kinds of special files which are special in different ways. E.g. wrt. seeking, some special files allow seeking just fine, others report an error, and others always report an offset of 0. Instead of trying to enumerate in which ways special files are special on all supported targets, which is a sisyphean task, libgfortran should just do what it's being told to, no more, and if any error occurs, propagate it upwards to the calling program. The "no more" is the problematic part, e.g. a spurious lseek(fd, 0, SEEK_CUR) would have have no effect on a regular file, but cause an error on a non-seekable file. Hence the need for a testsuite for non-regular files. Again, I agree, but that wasn't quite my point. I fully agree that providing such a list in the release notes is insanity. What I feel needs doing is a generic priority list of which functionality should take priority over which, for the guidance of gfortran developers and maintainers. Naturally, it would be subject to change. The point is that the choice of open() options, data format and OS transfer calls constrains what will work, and so you have to choose before you know what the code will do. The most ancient and worst insanity is not knowing the initial direction of transfer, but (as you say) repositioning and truncation vs replacement are almost as ancient and bad :-( While I would much prefer such decisions being made at OPEN time, my attempt to get this supported (not required!) in the standard failed. But there ARE some simple decisions that could be taken; for example (and these are merely PROPOSALS): If it is not a 'regular' file, ACCESS='DIRECT' should be forbidden If it is a FIFO, at least BACKSPACE and POS= should be forbidden Important decisions of priority would include whether pipability should take precedence over positionability for (a) stream and (b) unformatted sequential files. The Unix lunacy of compounding stream I/O with direct-access I/O (i.e. ACCESS='STREAM') has always been a disaster for both RAS and portability. And I really don't know what most compilers' attitudes are to that one, despite having asked several developers! For what I'm thinking of, I'm sure a pretty basic POSIX sh + maybe a few utilities such as mkfifo would do just fine. My reason for wanting to limit it, is that I, and AFAIK most gfortran developers, develop and test on x86_64-unknown-linux-gnu, and with the very limited time that I can afford to gfortran these days I don't want to spend that time trying to debug-over-email why a script fails on some weird target I don't have access to. If you want to make it work on Ultrix or something like that, be my guest, patches welcome. (For a similar reason, I think it wouldn't make sense to run these tests in a cross environment, more complexity for little gain (unless it's really simple?).) Yes, but this is EXACTLY the sort of thing that fails on those systems, and such tests would be really, really useful for people working on such systems. What I would suggest is that the scripts be supported for a generic POSIX system, but not be enabled by default or in a way that J. Random User is likely to trip over. Regards, Nick Maclaren.
Re: libcpp how-to question: Tokenizing and spaces & tabs - or special Fortran needs
On Dec 1 2014, Dodji Seketeli wrote: Just for the record -- as I am trimming the original post for legibility -- the initial message I am replying to can be read at https://gcc.gnu.org/ml/gcc/2014-11/msg00357.html. Tobias Burnus writes: Do you have a suggestion how to best implement this white-space preserving with libcpp? It can (and presumably should) be a special flag/function for Fortran. I would propose that libcpp gets extended to gain a new kind of token which type would be something like 'CPP_WHITESPACE', which would contain the exact spelling of the continuous non-vertical spaces that are discarded today. There would then be a new libcpp option that would actually make cpp_get_token() yield that kind of token. The rest of the behaviour of cpp_get_token() that is today associated with white spaces would remain mostly unchanged. I would strongly recommend at least extending that to vertical white space as well. Non-default vertical white space has caused portability trouble for many decades in many languages (including Fortran and C). Inter alia, C's rules for what white space is acceptable and what it does in translation phases 1-1 are poorly defined (for unavoidable reasons, unfortunately), usually not well understood, and differ considerably between compilers. Fortran is easier - it's processor- dependent, and that's it - experienced people never use anything non-default. There is also the 'interesting' case of whether CR-LF is acceptable on Unix-like systems. Other than that, what you say makes a lot of sense, but I am not an expert on the internals of gcc/gfortran. Aside: if anyone, ever again, designs a language where overprinting is part of the syntax, please sign me up for the cluebat team to educate them! I.e. bare CRs should either be Macintosh line separators or diagnosed as errors, in ALL languages. Regards, Nick Maclaren.
Re: [RFC] -Weverything
On Jan 23 2019, Thomas König wrote: Am 23.01.2019 um 12:36 schrieb Jonathan Wakely : When there are new warnings that aren't enabled by -Wall -Wextra, there's probably a reason they aren't enabled by default. are a higher form of life than mere Fortran -Wconversion-extra is an example of such a warning. It catches a very common error people make in Fortran, see https://gcc.gnu.org/ml/fortran/2019-01/ms are a higher form of life than mere sg00178.html for a false bug report which it would have caught early. We left it out of -Wextra because people felt it was too noisy. A bit like discussions on what warnings a compiler should give :-) There are a few points that don't seem to have been made, though I may have missed them, which means that quite a few people would like it. Despite its older and wider implementation history, Fortran has never accumulated the incompatibilities, inconsistencies and system-dependent behaviours that C and C++ have. So the arguments against such a warning for those don't really apply. Obviously, we wouldn't want warnings that a construct behaved differently in Fortran 66 or in CDC or DEC Fortran, but I don't think that there are any. I don't buy the claim that developer options are unsuitable for mere users. Those of us who wrote highly portable code (and I assume that people still do) wanted to know that a construct might misbehave on a bizarre, unsupported but still used system, which the author had never heard of and has no access to. While that applies to all languages, the attitude that a portable program should work on a new system with NO modification, pre-processing or make configuration is rare in C and C++, but still common in Fortran. All experience is that warning about things that the programmer might not have realised are potentially problematic are very useful. In the cases where I have had to suppress warnings, most of them have been because the warning was too crude, not that it wasn't useful. For example, in C/C++, mixing signed and unsigned when the promoted operand was constant and not going to change value. Or, in Fortran, converting obviously exact constants to a higher precision - yes, even that WAS an important warning in the 1960s, but people really should move on a bit! So I think that there is a strong argument for such an option in gfortran, irrespective of whether there is for gcc and g++. Regards, Nick Maclaren.
Re: [RFC] -Weverything
On Jan 27 2019, Steve Kargl wrote: On Sun, Jan 27, 2019 at 01:19:08PM -0800, Andrew Pinski wrote: On Sun, Jan 27, 2019 at 1:02 PM Thomas König wrote: > > > In fact, I would be in favor of removing -Wall, as it is misnamed, > > in favor of -Wlevel=0,1,2,3... -Wlevel=0 default warnings. > > -Wlevel=1 is equivalent to -Wall. -Wlevel=2 is -Wall -Wextra > > (and maybe -Wsurprising). > > ... and -Wlevel=3 could then be -Wkitchen-sink, at least from the > Fortran-only side. :-) > > I quite like that idea. I don't think -Wall will be deprecated soon, > but -Wlevel sounds like a good thing to implement. Maybe instead of -Wlevel= whyng names for levels seems helpful, but numbers are more future-proof. not just -W0, -W1, -W2, -W3; -W would be -W1 (because -W already exists)? Just like -O :). That would work. With -Wlevel, I'm thinking that -Wlevel=-1 would be the kitchen-sink. This means one can add new l> evels for positive levels if desired: -Wlevel=n+1 = -Wlevel=n -Wnew-opt1 -Wnew-opt2, etc. Both good, even excellent, ideas. I would prefer 'max' rather than '-1', but it is essential that its specification (and comment around the code) say that it is the supremum, to ng names for levels seems helpful, but numbers are more future-proof.avoid a repetition of the Wall mistake. It's rather like optimisation - using names for levels seems helpful, but numbers are more future-proof. 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.
Re: Dealing with default recursive procedures in Fortran
On Apr 12 2018, Thomas König wrote: with Fortran 2018, recursive is becoming the default. This will likely have a serious impact on many user codes, which often declare large arrays which could then overflow stacks, leading to segfaults without further explanation. Yes. Been there - seen that :-) What's worse, segfaults because of stack overflow very often confuse debuggers, so you can't even get a traceback of where it failed! We could extend -fmax-stack-var-size so it allocates memory from the heap in recursive procedures, too, and set this to some default value. Of course, it would also have to free them afterwards, but we manage that for allocatable arrays already. Yes, but I think it's a horrible idea. See below for a better one. We could warn when large arrays with sizes known at compile time are translated. Yes, but I think that's the wrong criterion. It should be above a certain size, probably aggregate per procedure - and controllable, of course. Who cares about a couple of 3x3 matrices? We could use -fsplit-stack by default. How reliable is that option? Can it be used, for example, with -fopenmp? Is it available on all (relevant) platforms? One drawback would be that this would allow for infinite recursions to go on for much longer. Yes. And I don't think it's the right mechanism, anyway, except for OpenMP. Again, see below. A -fcheck=stack option could be added (implemented similar to -fsplit-stack), to be included in -fcheck=all, which would abort with a sensible error message instead of a segfault. Absolutely. Or simply always check! I haven't studied the actual code generated by gfortran recently, but my experience of performing stack checking is that its cost is negligible. It got a bad name because of the utter incompetence of the way it was usually implemented. There is also a very simple optimisation that often avoids it: Leave a fixed amount of space beyond the check point and omit the check for any leaf procedure that uses no more than that. And, obviously, that can be extended to non-leaf procedures with known stack use, such as most of the intrinsics. There is another option, which I was thinking of experimenting with in my retirement, but probably won't, is a double stack (as in GNU Ada, and the better Algol 68 systems). Small, fixed objects go on the primary stack, as usual, and large or variable-sized ones go on the secondary stack. Allocatable objects should go there if and only if they are not reallocated. My experience (a long time back) was that the improved locality of the primary stack (often needed to control branching) by removing large arrays from it speeded up most calls with such arrays by several tens of percent. Now, there is an interesting interaction with split stacks. The only reason to have a contiguous stack is for fast procedure call for simple procedures. But that doesn't apply to the secondary stack, so it can always be split - hence there is no need for a configuration or run-time option. That doesn't stop it being checked against a maximum size, either, because accumulating, decrementing and checking a count isn't a major overhead for the use the secondary stack gets. Regards, Nick Maclaren.
Re: RFC: Telling the middle end about asynchronous/single-sided memory access (Fortran related)
On Apr 15 2011, Tobias Burnus wrote: (Frankly, I am not 100% sure about the exact semantics of ASYNCHRONOUS; I think might be implemented by preventing all code movements which involve swapping an ASYNCHRONOUS variable with a function call, which is not pure. Otherwise, in terms of the variable value, it acts like a normal variable, i.e. if one does: "a = 7" and does not set "a" afterwards (assignment or via function calls), it remains 7. The changing of the variable is explicit - even if it only becomes effective with some delay.) I am, but I am not sure how to describe them. The relevant constraints on the program are in Fortran 2008 9.6.4.1 paras 5 and 6 (page 220), and here is roughly what it means for the compiler. The ASYNCHRONOUS attribute says that a variable may be used for such purposes, and therefore can be changed unpredictably (if writable) or referenced unpredictably, at any point while it is 'active' for asynchronous I/O (i.e. it is a pending input-output sequence affector, a term that I find bizarre). It is a bit like the intent of VOLATILE, in that respect only. But it also says: 1) The program may not change it if it is liable to be referenced, or reference it if it is liable to be changed. But this applies ONLY during those windows of vulnerability. 2) A window of vulnerability can be changed only by explicit action, either an asynchronous I/O statement or calling a procedure that has access to that variable. Note that closing the window doesn't need explicit access, as it operates on just a 'transfer token', but that is as if the action that opened the window squirreled away a pointer to the array when it started the asynchronous I/O. This means that, if a compiler can determine that code is NOT in a window of vulnerability, all normal optimisations can be applied. And, if the window is for reference only, reference to the variable and taking a copy is allowed. For example, if there is an assignment statement to it or it is passed as an argument to a procedure without ASYNCHRONOUS or INTENT(IN), the compiler can tell that there is no I/O in progress at that point. Similarly, if it is referenced or passed to a procedure without ASYNCHRONOUS but with INTENT(IN), it may be being referenced but won't be being changed (asynchronously). Of course, that may not be the case. But, if it isn't, the program is broken, and the behaviour is undefined - so what the hell? And I apologise about my English :-) I don't have time just now to rephrase it in less arcane usage, and am aware that it is tricky. Regards, Nick Maclaren.
Re: RFC: Telling the middle end about asynchronous/single-sided memory access (Fortran related)
On Apr 15 2011, Richard Guenther wrote: On Fri, Apr 15, 2011 at 2:04 PM, Tobias Burnus wrote: Q2: Can this be optimized in some way? For simple types you could use atomic instructions for the modification itself instead of two SYNC ALL calls. Well, even with atomic you need to have a barrier; besides the example was only for illustration. I think if one uses the variable in "foo" before the first sync all, one even would need two barriers - atomic read/write or not. (For the current example, setting the value in "foo" is pointless. And the obfuscated way the variable is set, makes the program fragile: someone modifying might not see the dependency and break it.) As long as all variables that need protection are global a random function call before and after is enough to avoid optimization. Today in gcc, perhaps. But it's NOT a good idea to rely on it, as it is broken by many of the optimisations that Fortran traditionally uses I don't think that gfortran uses them, but could be wrong, and it might well change. It also doesn't extend to threading, whether the extra threads are explicit or 'helper' threads. Extra incantations are needed. Regards, Nick Maclaren.
Re: RFC: Telling the middle end about asynchronous/single-sided memory access (Fortran related)
On Apr 15 2011, Janne Blomqvist wrote: Indeed, I assumed you were discussing how to implement CAF via shared memory. If we use MPI, surely the implementation of MPI_Barrier should itself issue any necessary memory fences (if it uses shared memory), so I don't think __sync_synchronize() would be necessary? It doesn't have any such semantics. Any fences are issued by MPI_Wait, but see below. And, as Richi already mentioned, the function call itself is an implicit compiler memory barrier for all variables which might be accessed by the callee. Which implies that any such variables must be flushed to memory before the call and reloaded if read after the call returns. So, in this case I don't think there is anything to worry about. Not in a threaded context, or with shared memory segments! Mere function calls have no effect whatsoever on memory consistency between threads, and you really, but REALLY, want to avoid doing full memory barriers more than you can help. For complicated reasons, they can be more expensive than MPI_Barrier, though they are at least sane and reliable (unlike 'fences'). If the majority of the code is going to be common between an MPI and a shared memory implementation, explicit synchronisation is needed, though it might well be a dummy call under MPI. Regards, Nick Maclaren.
Re: food for optimizer developers
On Aug 12 2010, Steve Kargl wrote: Your observation re-enforces the notion that doing benchmarks properly is difficult. I forgot about the lapack inquiry routines. One would think that some 20+ year after F90, that Dongarra and colleagues would use the intrinsic numeric inquiry functions. Although the accumulated time is small, DLAMCH() is called 2642428 times during execution. Everything returned by DLAMCH() can be reduced to a compile time constant. Part of that is deliberate - to enable the compiled code to be used from languages like C++ - but I agree that this is a case that SHOULD not cause trouble. Whether it does, under some compilers, I don't know. A project that would be useful (but not very interesting) would be to rewrite the LAPACK reference implementation in proper Fortran 90+. A variant would be to do that, but update the interfaces, too. Both of these would be good benchmarks for compilers - especially the latter - and would encourage good code generation of array operations. This would be a LOT shorter - I did the latter for the Cholesky solver as a course example to show how modern Fortran is a transliteration of the actual algorithm that is published everywhere. Unfortunately, that's scarcely even a start to the whole library :-( I believe that some other people have done a bit more, but not accumulating to most of a conversion, though I might be out of date (it is some time since I looked). I can't think of how to encourage such work, and am not going to do it myself. Regards, Nick Maclaren.
Re: Built-in testing for signaling nan?
On Nov 6 2013, FX wrote: GCC has a number of floating-point-related type-generic built-ins, which are great and which we largely rely on in the gfortran runtime library (rather than depending on the possibly poor-quality target math library). However, I have not been able to find a way to test for a signaling NaN using the existing built-ins? __builtin_fpclassify() and __builtin_isnan() both return the same thing for quite and signaling NaNs. We have a __builtin_nans() function to generate a signaling NaN, but nothing to find one. Am I missing something? Would it be hard to implement such a built-in? Yes, due to the poor quality of the IEEE 754 specifications. In 1984, the distinction was left completely unspecified (even in intent). In 2008, there is a recommendation (no more) that the top bit of the payload is used, with no specification of what to do if that is zero (which is the most obvious default). That appears to be the Intel specification, though it may not have always been so even for x86. I have certainly seen more than one convention for different architectures, but have no idea how many are extant nor how many are documented in the relevant architecture manuals. I don't know how reliable __builtin_nans() is, but a test is potentially even less reliable. Simply testing that bit MIGHT work, or it might be nothing more than a gotcha. Regards, Nick Maclaren.
Re: Built-in testing for signaling nan?
Yes, due to the poor quality of the IEEE 754 specifications. In 1984, the distinction was left completely unspecified (even in intent). In 2008, there is a recommendation (no more) that the top bit of the payload is used, with no specification of what to do if that is zero (which is the most obvious default). That appears to be the Intel specification, though it may not have always been so even for x86. I have certainly seen more than one convention for different architectures, but have no idea how many are extant nor how many are documented in the relevant architecture manuals. In GCC, the qnan_msb_set bit of struct real_format is what specifies the convention in use for a particular floating-point mode. A single bit necessarily conveys at most one bit of information. That can indicate whether the MSB being zero is the criterion; it cannot indicate what the criterion is if that is not the case. Regards, Nick Maclaren.
Re: Built-in testing for signaling nan?
On Nov 7 2013, FX wrote: Given how murky signaling NaNs are in practice, I think it's worth asking: why do you want to know? Because I am writing an implementation of the IEEE support modules in GNU Fortran, which are part of the Fortran 2003 standard. And the standard provides for a procedure (IEEE_CLASS) to distinguish between IEEE_SIGNALING_NAN and IEEE_QUIET_NAN. It doesn't explicitly state that supporting sNaN is required, so I can also just not return it. Yes. There is also the issue that the Fortran community (which gfortran follows) takes portability very seriously indeed, both over a very wide range of systems and over long periods of time. Simply saying "if your system doesn't fit into one of these two categories, you can't have any of this facility" is not regarded as reasonable. Those weren't/aren't the only ways NaNs could be provided. Unfortunately, that is probably the best that can be done for a reasonable amount of effort. I.e. to pass the buck back to base gcc, and put up with its restrictive view of the universe of 'IEEE 754 support'. Because this area is such a complete mess, most people interested in extreme portability will continue to ignore all of the IEEE 754 facilities, even in Fortran (which gets them at least part-right). I can't say that I am entirely happy with your effort, because the problem is that having the procedures available will encourage people to trust the IEEE features, and the real problems are in the optimisation and code generation. In particular, there will be pressure to remove optimisations and not add new ones because of perceived semantic conflicts - we have seen this very badly in the C world. Regards, Nick Maclaren.
Re: Adding UNION/MAP -- Feedback and tips pls!
On Mar 6 2013, Russell Brennan wrote: Ouch. This seems to be at odds with C's unions, where it is not allowed to do type punning. As of gcc 4.4.6, the description above seems to match the C behavior: Er, no. One simple test does not prove that it will always work; this sort of thing is most likely to fail because it interacts in very nasty ways with optimisation. C99 introduced a horribly ill-defined concept called "effective types", which specifically allows type-dependent optimisations. I have no idea whether gcc uses it at present, but it might well do so in the future. Regards, Nick Maclaren.
Re: Adding UNION/MAP -- Feedback and tips pls!
On Mar 6 2013, Russell Brennan wrote:
Perhaps I misunderstand how you are defining failure here... what
would be the failure mode? Perhaps if you could provide an example of
the ill-effects that could be seen as a result of this behavior it
would clarify the issue?
Generating bad code. In:
union {
double x[10];
double y;
} fred, joe;
fred.y = 0.0;
joe = fred;
call alf(fred);
The compiler is permitted to copy only a single double in either of
the last two statements, because the last use was via y. That liberty
dates from C90, but C99 effective types extended it to many more cases.
If you break the semantic rules of a language, it is common to see no
error until you enable optimisation, whereupon it produces wrong answers
and the average user claims that the optimiser is broken.
Regards,
Nick Maclaren.
Re: Adding UNION/MAP -- Feedback and tips pls!
On Mar 6 2013, Andrew Pinski wrote: Except GCC implements C's unions as allowing to do type punning as an extension and as far as GCC is concerned that is not going to change any time soon. This is a documented exception to the aliasing/type punning rules. The problem is that this is worse than type punning, because it also allows the preservation of data. Does the extension guarantee that, or would it need a change to at least the documentation? Regards, Nick Maclaren.
