http://permalink.gmane.org/gmane.comp.gcc.fortran hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.gcc.fortran/38817 <pre> I've noticed this failure for some time but never got around to inspecting things. The X=34.53 case seem to need a precision allowance bump. Ok for mainline and 4.7 branch? BTW, for the curious, I've attached a log file of this testcase run with all the print statements uncommented. * gfortran.dg/bessel_7.f90: Bump allowed precision to avoid failure on sparc-*-linux-gnu. diff --git a/gcc/testsuite/gfortran.dg/bessel_7.f90 b/gcc/testsuite/gfortran.dg/bessel_7.f90 index 78f1ff2..7e63ed1 100644 --- a/gcc/testsuite/gfortran.dg/bessel_7.f90 +++ b/gcc/testsuite/gfortran.dg/bessel_7.f90 &lt; at &gt;&lt; at &gt; -16,7 +16,7 &lt; at &gt;&lt; at &gt; implicit none real,parameter :: values(*) = [0.0, 0.5, 1.0, 0.9, 1.8,2.0,3.0,4.0,4.25,8.0,34.53, 475.78] real,parameter :: myeps(size(values)) = epsilon(0.0) &amp; - * [2, 3, 4, 5, 8, 2, 12, 6, 7, 6, 31, 168 ] + * [2, 3, 4, 5, 8, 2, 12, 6, 7, 6, 36, 168 ] ! The following is sufficient for me - the values above are a bit ! more tolerant ! * [0, 0, 0, 3, 3</pre> David Miller 2012-05-16T23:56:04 http://permalink.gmane.org/gmane.comp.gcc.fortran/38816 <pre>All CPUs on which you are likely to run Fortran nowadays have IEEE754 compliant firmware for sqrt. tan(), however, is difficult enough that numerical standardization proposals haven't been implemented. You will find numerical differences even with the same compiler between scalar and vector libraries, for example, or possibly differing options for various instruction architecture targets. In your example, yes, the correct interpretation is that your decimal value is rounded to the closest representable value in single precision binary before passing to the print and tan functions. </pre> Tim Prince 2012-05-16T14:12:18 http://permalink.gmane.org/gmane.comp.gcc.fortran/38815 <pre> On ma., 2012-05-14 at 14:31 +0100, N.M. Maclaren wrote: On ma., 2012-05-14 at 14:38 +0200, Tobias Burnus wrote: What Nick tell us here is probably correct with respect to what he refers, but the "error" I experience with my software seem quite odd (at least for me). I get different result in the 7th digit for the tan() function, above a certain level. When working with sqrt(), I experience no difference at all between the two compilers and platforms, pushing it really hard by taking the sqrt 15 times a = sqrt(r) b = sqrt(a) c = sqrt(b) . . . and going back again, b = c*c a = b*b r = a*a ending up with exactly the same error. What seem odd to me is that the varable "chi1" holds the same value in advance of the call to "tan(chi1)" for both ifort and gfortran compiled source, but produce a different result. Win7 ifort compiled source: chi1 = 0.52359876 print '(f15.10)', chi1 print '(f15.10)', tan(chi1) 0.5235987306 0.5773501992 Increasing one number in the last digit 6 to 7: chi1 = 0.52359877 </pre> Edvardsen Kåre 2012-05-16T13:05:17 http://permalink.gmane.org/gmane.comp.gcc.fortran/38814 <pre> Ah, bummer. We have something roughly similiar for snprintf (see libgfortran.h), but it seems that it works slightly differently due to using a variadic macro etc. So it seems this idea will not work, sorry. Interestingly, according to that document open() also has the POSIXly correct varargs prototype. So apparently the old 3-argument prototype was used only in some older vxworks version? Since the document above is from 2007, one wonders how long ago did the prototype change, and how much new development is done on these older vxworks versions? IMHO lets do only the second part now, and wait for someone with vxworks experience to pop in and explain what changes are necessary, and which vxworks versions are worth considering to support. </pre> Janne Blomqvist 2012-05-16T11:26:13 http://permalink.gmane.org/gmane.comp.gcc.fortran/38812 <pre> IMHO it would be cleaner if you instead somewhere in the beginning of unix.c did #ifdef __VXWORKS__ /* open is not a variadic function on vxworks (or something...) */ #define open(path, flags) open(path, flags, 0666) #endif Untested, but AFAICS it should work (unless I'm missing something wrt macro expansion, which of course is quite possible). Good catch. This part is ok as is. Ok with the above change. I suspect there isn't that much demand for gfortran on vxworks, but the patch isn't intrusive either so if you want to backport it go ahead. </pre> Janne Blomqvist 2012-05-16T06:45:08 http://permalink.gmane.org/gmane.comp.gcc.fortran/38811 <pre>Hi All, in attachment there's a patch for PR 48831, it also includes a new test case suggested by Tobias Burnus. The patch is bootstrapped and tested on x86_64-unknown-linux-gnu. Regards. Alessandro Fanfarillo </pre> Alessandro Fanfarillo 2012-05-15T20:39:35 http://permalink.gmane.org/gmane.comp.gcc.fortran/38810 <pre> There is: !GCC$ ATTRIBUTES ... However, that's currently restricted to CDECL, STDCALL, FASTCALL, DLLEXPORT and DLLIMPORT, cf. http://gcc.gnu.org/onlinedocs/gfortran/GNU-Fortran-Compiler-Directives.html There is some PR with an early draft patch about extending it to support all attributes of GCC. If you have time … Tobias </pre> Tobias Burnus 2012-05-15T17:12:52 http://permalink.gmane.org/gmane.comp.gcc.fortran/38809 <pre>----- Mensaje original ----- Dear Tobias, OK. As is the first time that I find this warning, I'm puzzled that part of the user coding style should improve. With your full explanation of the presente case the conclusion is now clear: the user should be improve the coding style. OK. For instance, the false positive in Bug 52370 have a somewhat different nature? Many thanks for the precise explanations. Regards, Jorge. -- </pre> Jorge D'ELIA 2012-05-15T17:11:42 http://permalink.gmane.org/gmane.comp.gcc.fortran/38808 <pre> Is there something like __attribute__ ((__warn_unused_result__)) that could be used for such stores, btw? Just curious.. </pre> Bernhard Reutner-Fischer 2012-05-15T17:08:28 http://permalink.gmane.org/gmane.comp.gcc.fortran/38807 <pre> I have seen them, but not recently. However, the number of bounds checks that can be done statically is very small, and the vast majority are where the compiler is correctly diagnosing broken modern Fortran that started as valid Fortran IV. Regards, Nick Maclaren. </pre> N.M. Maclaren 2012-05-15T16:51:26 http://permalink.gmane.org/gmane.comp.gcc.fortran/38806 <pre> Sorry for only now looking at the example. In this case, I have to concur with the compiler: Namely, one has: allocate (r (n),stat=ier) r = abs (a) Assume for a moment that the allocation fails. As a result, "A" is unallocated and its bounds are not defined. The purpose of the stat= is to provide some error handling - and ignoring ier does not count as error handling. Without stat, the compiler handles errors (by aborting with an error message). If you insert some manual error handling like "if(ier /= 0) return", the compiler warning disappears. You might decide to still ignore the ier - but then you shouldn't be surprised that the compiler yells at you (with -Wall). Unless there is a special reason, I would simply drop the "stat=ier" and use the default handling. While not in this case, I had the feeling that the compiler sometimes generates spurious bound warnings. I never found the time to confirm my suspicion; if so, it might be a false positive or some wrong-code issue, wh</pre> Tobias Burnus 2012-05-15T15:46:46 http://permalink.gmane.org/gmane.comp.gcc.fortran/38805 <pre> troutmask:sgk[210] gfc47 -c -Wall a.f90 troutmask:sgk[211] gfc47 -c -Wall -O a.f90 a.f90: In function 'bogus': a.f90:11:0: warning: 'r.dim[0].ubound' may be used uninitialized in this function [-Wmaybe-uninitialized] troutmask:sgk[212] gfc47 -c -Wall -O -Wno-maybe-uninitialized a.f90 troutmask:sgk[213] gfc47 -c -Wall -O -fno-realloc-lhs a.f90 You do realize that the use of STAT in the allocate statement causes the compiler to take a different code path, right? Hopefully, it is also clear that the warning is associated with line 11 in the code (ie., 'r = abs(a)'), which has nothing to do with the allocate statement. </pre> Steve Kargl 2012-05-15T15:23:10 http://permalink.gmane.org/gmane.comp.gcc.fortran/38804 <pre>----- Mensaje original ----- Yes, although there may be many lines with this message. BTW, if the ALLOCATE statement does not use the STAT option, then, there is no warning message. Jorge. -- </pre> Jorge D'ELIA 2012-05-15T14:41:35 http://permalink.gmane.org/gmane.comp.gcc.fortran/38803 <pre> The practical solution is simply to ignore the warning. </pre> Steve Kargl 2012-05-15T13:16:35 http://permalink.gmane.org/gmane.comp.gcc.fortran/38802 <pre>----- Mensaje original ----- Dear Nick Maclaren, Ajit tells me that the Bug 52370 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52370) is similar. The present case have not the optional argument used in Bug 52370 although, like Tobias Burnus noted there, 4.7.0 version shows a warning with flags from -01 to -04 and not with -O0. Nevertheless, taking into account your comments, the practical solution is already suggested by Steve Kargl, that is, "do not use -Wall". Regards, Jorge. -- </pre> Jorge D'ELIA 2012-05-15T11:04:40 http://permalink.gmane.org/gmane.comp.gcc.fortran/38801 <pre> I have committed this as r187521. thanks, </pre> Bernhard Reutner-Fischer 2012-05-15T10:43:10 http://permalink.gmane.org/gmane.comp.gcc.fortran/38799 <pre>2012/5/13 Tobias Burnus &lt;burnus&lt; at &gt;net-b.de&gt;: Thank you for your priceless support! Alessandro </pre> Alessandro Fanfarillo 2012-05-15T10:14:44 http://permalink.gmane.org/gmane.comp.gcc.fortran/38798 <pre> The generic problem about this warning is that it is halting problem complete - i.e. it is provably impossible to get right in all cases. I have never used a compiler that issued such a message and did not issue at least some where it was bogus - and I have used dozens of such compilers. If you want a REALLY nasty one, try one where the program can be shown to be correct with probability one assuming a not-totally-broken random number generator :-) I would actually advise AGAINST trying to fix it, unless there is a test that can be used to reduce bogus occurrences and is simple and clean enough that it definitely won't cause real errors to be missed. Adding hacks will just increase the number of cases it misses. The unfortunate fact is that this will never be a fully reliable warning. Regards, Nick Maclaren. </pre> N.M. Maclaren 2012-05-15T10:06:28 http://permalink.gmane.org/gmane.comp.gcc.fortran/38797 <pre>Dear all, the motivation for the following is rbmj's patch for libstdc++ on VxWorks, cf. http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00073.html Note that gfortan is used on VxWorks as the following email proves: http://gcc.gnu.org/ml/fortran/2012-02/msg00115.html (VxWorks is a real-time embedded operating system: https://en.wikipedia.org/wiki/VxWorks) Seemingly, VxWorks differs from POSIX. POSIX [1] has int open(const char *path, int oflag, ... ); and requires only with O_CREAT as third argument at mode_t. By contrast, VxWorks has the following prototype [2] int open (const char * name, int flags, int mode) where "mode" is not optional and the function is not variadic. This patch does now always passes a mode on VxWorks; I assume that the mode is ignored if there is no O_CREAT. That part of the code gets only accessed if there is no "access" function; looking at [2], that seems to be the case for VxWorks. Additionally, in the fall-back implementation of "mkstemp", "open" with O_CREAT is us</pre> Tobias Burnus 2012-05-15T09:03:08 http://permalink.gmane.org/gmane.comp.gcc.fortran/38796 <pre>Dear Tobias, ----- Mensaje original ----- I agree that there are more important bugs to deal with! I have no problem doing it if this issue deserves some attention... Yes, there was one test in my first email. Also, simple variations and different machine and OS do not show the bogus warning. e.g. Test Machine OS GNU Fortran Warning? ------------------------------------------------------------------ bogus1.f90 Intel Xeon Fedora 9 4.7.0 20110709 no bogus2.f90 Intel Xeon Fedora 9 4.7.0 20110709 no bogus3.f90 Intel Xeon Fedora 9 4.7.0 20110709 no bogus4.f90 Intel Xeon Fedora 9 4.7.0 20110709 no ------------------------------------------------------------------ bogus1.f90 Intel Pentium 4 Windows XP 4.7.0 20110813 yes bogus2.f90 Intel Pentium 4 Windows XP 4.7.0 20110813 no bogus3.f90 Intel Pentium 4 Windows XP 4.7.0 20110813 no bogus4.f90 Intel Pentium 4 Windows XP 4.7.0 20110813 no --------------------------------</pre> Jorge D'ELIA 2012-05-14T21:24:50 http://permalink.gmane.org/gmane.comp.gcc.fortran/38795 <pre>Dear Jorge, Jorge D'ELIA wrote: I had seen that warning as well a couple of times. Silencing it is not that difficult, but I was always wondering whether the warning is correct - or might be triggered in a case when it is correct. As I lacked a simple test case, I deferred it; additionally, there were more important bugs to deal with. If you have a simple test case, please fill a bug report.I think you had a simple test case. (I haven't looked at your email in detail.) Technically, one just needs to set "TREE_NO_WARNING (decl) = 1"; I think that would have to be done in trans-decl.c's gfc_build_qualified_array, but there might be additional places. Tobias </pre> Tobias Burnus 2012-05-14T20:00:46 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.gcc.fortran