Re: [Bug libfortran/48906] Wrong rounding results with -m32
On 06/06/2011 01:38 AM, thenlich at users dot sourceforge.net wrote: For a scale factor 0, we are done. Good work, thank you! A scale factor != 0 does not work yet, you wrote you are still working on it, is that correct? I am now. ;) print "(-2pg12.3)", 0.02 ! 0.200E-01 expected 0.002E+01 print "(-1pg12.3)", 0.02 ! 0.200E-01 expected 0.020E+00 print "(0pg12.3)", 0.02 ! 0.200E-01 print "(1pg12.3)", 0.02 ! 0.200E-01 expected 2.000E-02 print "(2pg12.3)", 0.02 ! 0.200E-01 expected 20.00E-03 My confusion seems to be when scale factor is to be ignored and when not, I will give the standard another read.
Re: [Bug libfortran/48787] Invalid UP rounding with F editing
On 04/29/2011 12:14 AM, thenlich at users dot sourceforge.net wrote: ---snip--- The suggested patch fails on examples in this test where d>0. I think for rounding up we need to test if ALL the cut off digits are zeros. I have committed the whole ball of wax. I really needed to do this because things were stacking up. I considered that there may be a need to test for all zeros. That will be easy to do. So a follow-on patch can be done soon. Thanks for the test cases I will will keep working these off as best I can.
Re: [Bug libfortran/48615] Invalid UP/DOWN rounding with E and ES descriptors
On 04/24/2011 02:41 PM, thenlich at users dot sourceforge.net wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48615 --- Comment #8 from Thomas Henlich 2011-04-24 21:41:16 UTC --- I don't have access to a build system until Tuesday, so I couldn't test your patch. But I'm not sure I understand what you are trying to do. Please read my post on the gfortran mailing list. There are four bugs addressed by this patch.
Re: [Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10
On 04/17/2011 06:25 AM, thenlich at users dot sourceforge.net wrote: --- snip --- I agree. Let's open a new bug for this. This bug is about the correct choice of format, not about rounding (this is somewhere else in the code). Yes, new PR. We are using builtin snprintf for DTOA. #define DTOA \ snprintf (buffer, size, "%+-#" STR(MIN_FIELD_WIDTH) ".*" \ "e", ndigits - 1, tmp); By examining the buffer returned, we are getting an exact value back before we even begin processing the string for our libgfortran needs. The buffer for this case contains: buffer=990e-02 The first digit is an artifact of shifting the buffer for decimal point placement and is ignored. I still need to check the code between the call to snprintf and where I have placed a printf to view it. snprintf may be rounding the value up. Testing continues.
Re: [Bug fortran/48426] [patch] Quad precision promotion
On 04/03/2011 12:49 PM, inform at tiker dot net wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48426 --- Comment #3 from Andreas Kloeckner 2011-04-03 19:49:51 UTC --- (In reply to comment #2) There is already -fdefault-real-8, -fdefault-integer-8, and -fdefault-double-8. This is already 3 too many hacks. Adding an additional 7 options is 7 too many. From a purist perspective, I absolutely gree with you. Practically however, in dealing with legacy codes (*), the value of being able to do this should not be underestimated. If this was a useless thing to do, why would Lahey/Fujitsu have included these flags? Lets take another perspective, different than Steve's comments. Lets assume no-one is blindly using the legacy codes with changes in default kinds without at least some understanding of the code and knowing what it is doing. With modern editors or scripts, one could modify declarations to use a kind=parameter. This could be done to change REAL to REAL(kind=wp). wp meaning working precision. One could also update real constants to append _wp to them. Then add a use statement at the beginning of each file that sets wp. Several different precision parameters could be set up and used in varying places depending on the application. One gets a finer degree of control. Now I have presented a simplistic example and I am sure the real code may offer some additional challenges. But, the net result would be more flexible code that is more portable and the original issue becomes moot. If ones knowledge of the code is greater then mine it is likely one could see more opportunities for improving it with simple changes like this, especially in the code that is critical to the issue. Once the changes are made, perhaps even incrementally over time in small parts, they never have to be changed back, because the code is standard conforming to do so. Now, we can make arguments to go in either direction; put the burden of resolving the issue on the compiler team or put the burden on the user/developers. I think Steve is saying that we have an obligation on the compiler side to protect users who may not be as knowledgeable/experienced from doing stupid things, whereas someone such as yourself would probably know what to be careful of and could avoid it. Providing the adjustable precision on the user/developer side assures that it is done carefully and correctly, specific to the application. Now the flip side is that the less than 100 lines of code patch on the compiler side is a lot less effort then perhaps updating the 100,000 lines of legacy code. However, the compiler changes affect thousands of users and thousands of applications. That means there is, lets say, 1000 times more risk to the change on the compiler side. (With no warranty of course). I am leaning toward we need to err on the conservative side, and let others comment from here. We have had these discussions on this topic many times before. I don't think there is an easy answer. My personal preference would be to update the user code. (aka software maintenance). Regards
Re: [Bug fortran/41515] [4.3/4.4/4.5 Regression] PARAMETER statement in module subroutines
On 10/02/2009 05:35 AM, ros at rzg dot mpg dot de wrote: --- Comment #12 from ros at rzg dot mpg dot de 2009-10-02 12:35 --- Subject: Re: [4.3/4.4/4.5 Regression] PARAMETER statement in module subroutines On Fri, 2 Oct 2009, burnus at gcc dot gnu dot org wrote: Depends where you download the binary from. For my x86-64 builds, one can find it in the file name (click on "Download page." or go directly to http://users.physik.fu-berlin.de/~tburnus/gcc-trunk/ ) Thanks, but unfortunately I need a 32-bit version. The build Tobias mentioned is a nightly update to latest 4.5 trunk version. http://quatramaran.ens.fr/~coudert/gfortran/gfortran-4.5-linux-i686.tar.gz The update starts at about 11:00 PM PST every day and is uploaded several hours later. Jerry
Re: [Bug fortran/41154] New: [4.5 Regression] Comma required after P descriptor
On 08/24/2009 05:26 AM, janus at gcc dot gnu dot org wrote: With r151053 I get an error when I compile the following line: 2000 format (1X,1P,E14.6,3E12.4,0P) 1 Error: Comma required after P descriptor in format string at (1) While I haven't checked in the standard if this is really valid, it was swallowed by gfortran until recently. It is also accepted by ifort and g95. This was certainly introduced by Jerry's r151045. Thats my fault, will fix shortly. Jerry
Re: 64 bit linux build problem for gcc 4.4.0
Aharon Robbins wrote: Hi. After several tries and a modicum of googling, I found that CFLAGS=-m64 ../gcc-4.4.0/configure --disable-multilib was the magic incantation to get gcc to get into the second stage of the boostrap. This is on a Fedora Core 10 system. This seems to be an old issue; google turns things up dating back to 2003. I suspect that x86_64 systems are only going to be more popular with time; the build process on those systems needs to be as easy as for 32 bit systems. Thanks, Arnold Robbins (the gawk guy :-) Aharon, I have been building gcc for several years now with no issues on x86-64 and on Fedora Core 10 ever since it was released. What exactly has been your problem? Its been as easy as 123. I have never had to set CCFLAGS or disable-multilib. Jerry
Re: [Bug fortran/34556] Rejects valid with bogus error message: parameter initalization
pault at gcc dot gnu dot org wrote: --- Comment #5 from pault at gcc dot gnu dot org 2008-01-13 08:49 --- (In reply to comment #4) This is similar to 34432 is some ways. I think we are not matching the (\ \) correctly. I don't think gfc_match_expr has the tooling for it yet. The error message is spurious in my opinion. It is left on the stack from a failed match. As I say above, the problem is in simplification and, specifically, the simplification of reshape. I agree there is a failed match. I am reducing the test case until I can get this to succeed. I have managed to ICE a similar test case. Here: ! Rejects-valid. Fails with gfortran 4.1, 4.2 and 4.3 ! For 4.3 the error message is: ! !(/ linem, nplam /) ) ! 1 !Error: Invalid character in name at (1) ! ! Found using the Fortran Company Fortran 90 Test Suite (Lite), ! Version 1.4 program splitprms integer, parameter :: nplam = 3 ! # of plans to expand TABs integer, parameter :: linem = 132 ! max. line length integer, parameter :: ncntm = 39 ! max. # cont. lines integer, dimension (linem, nplam) :: nxttab nxttab = & reshape ( & (/ max( (/ (6+3*((i-6+3)/3), i= 1,linem),& (6+2*((i-6+2)/2), i= 1,linem) /), & (/ (6, i= 1, 2*linem) /)), & (/ (i, i= 1,linem) /) /),& (/ linem, nplam /) ) print *, nxttab end program splitprms ]$ gfc pr34556.f90 pr34556.f90: In function ‘splitprms’: pr34556.f90:10: internal compiler error: Intrinsic function (164)
Re: [Bug libfortran/33985] access="stream",form="unformatted" doesn't buffer
m = where + s->active; if (s->physical_offset != m && lseek (s->fd, m, SEEK_SET) < 0) return NULL; I don't think this is correct. You are dead on, I have fixed this and have a patch regression testing now. The above did not break backspace_6.f90, but it broke some other things. Stay tuned.
Re: [Bug fortran/33849] Fix misleading error message "GENERIC non-INTRINSIC procedure not allowed as an actual argument"
burnus at gcc dot gnu dot org wrote: --- Comment #2 from burnus at gcc dot gnu dot org 2007-10-22 06:22 --- Is the issue here only the wording of the error message Yes, only the message text. "Error: GENERIC non-INTRINSIC procedure '%s' is not allowed as an actual argument" should be "Error: GENERIC procedure '%s' is not allowed as an actual argument" I will take care of it.
Re: [Bug fortran/29804] segfault with -fbounds-check on allocatable derived type components
Have you looked with valgrind or similar to see if there are errors occurring? Please definitely put in the testsuite. There may be something we don't see yet going on here.
Re: (g77) internal compiler error: Segmentation fault
Roland Winkler wrote: The (shortened) fortran-77 subroutine attached below causes a segmentation fault of g77 when I execute $ g77 -O3 -c -funroll-loops foo.f No problems occur without optimization. $ g77 --version GNU Fortran (GCC) 3.3.5 20050117 (prerelease) (SUSE Linux) Copyright (C) 2002 Free Software Foundation, Inc. (I have SUSE Linux 10.2) Let me know if you need to know anything else. G77 is no longer maintained. The new fortran compiler is gfortran and it supports f77 code. I will test to see if gfortran handles your test case. Also, please correspond with the gfortran list on this so we fortraners can help you here. There are gfortran binaries available. Let me know if you need help with this. Also helps to know what hardware platform you are on and what OS you are using. Regards, Jerry
Re: [Bug libfortran/31052] [4.2 only] Bad IOSTAT values when readings NAMELISTs past EOF
pinskia at gcc dot gnu dot org wrote: --- Comment #45 from pinskia at gcc dot gnu dot org 2007-04-13 05:32 --- (In reply to comment #44) sixtrack in SPEC CPU 2K started to fail on Mar. 19: And then start passing and then again started to fail again on/around April 1st. HJL when will you please get your dates correct. Now I am confused because I reverted and re-patched and it was tested by spark and sixtrack was then fine. I specifically had this tested before committing the last fix.
Re: [Bug fortran/27069] -ffast-math crash
nuno dot bandeira at ist dot utl dot pt wrote: --- Comment #2 from nuno dot bandeira at ist dot utl dot pt 2006-04-06 23:56 --- Subject: Re: -ffast-math crash kargl at gcc dot gnu dot org wrote: --- Comment #1 from kargl at gcc dot gnu dot org 2006-04-06 23:47 --- Don't use --fast-math. Is there a valid reason for it or is the implementation of the -ffast-math still uncertain ? -ffast-math is uncertain, not related to gfortran.
Re: Regression in LAPACK with -O3
Jerry DeLisle wrote: Paul Thomas wrote: Andrew, and the testcase here. ¿Que? Paul See attachment in PR26001 LAPACK tests run OK with the patch. Thanks to Dominique Dhumieres for initial reduced case and Andrew Pinski for squeezing this in. Hope we can get it committed to 4.1 and trunk soon. Jerry
LAPACK regression status
I am getting the following on Trunk: At line 1162 of file schkee.f Fortran runtime error: Bad integer for item 1 in list input With -O3 -march=pentium4 -funroll-loops I think we reported this before but I am not finding the PR. IIRC StevenB was going to delve into this optimization bug. Can anyone recall the PR? I think I may have failed to submit a PR before. LAPACK passes fine with no optimizations so it is not a Fortran Frontend or Library problem. Jerry
Re: [Bug libfortran/24224] Generalized internal array IO not implemented.
fxcoudert at gcc dot gnu dot org wrote: --- Comment #4 from fxcoudert at gcc dot gnu dot org 2005-12-09 09:05 --- Jerry, isn't that one completely fixed? For the most part this is fixed. We do not handle the case of negative strides, but we do handle strides of more than 1. So I was leaving it open as a reminder to get back to that after we run out of more serious bugs in the I/O library. We have not had any user issues on this.
Re: [Bug libfortran/25305] [4.0 regression]: libfortran failed fma3d in SPEC CPU 2K
hjl at lucon dot org wrote: --- Comment #7 from hjl at lucon dot org 2005-12-08 06:55 --- I have verified that http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00874.html is the cause. Since gcc 4.1 and 4.2 are OK, the problem may be in the backport. OK, I see now this is not a problem in 4.1 or 4.2. Yes, backport problem. Thanks, Jerry
Re: [Bug libfortran/25116] namelist read from non-opened file
fxcoudert at gcc dot gnu dot org wrote: --- Comment #4 from fxcoudert at gcc dot gnu dot org 2005-11-28 07:08 --- No, it's in fact easier than that. We shouldn't come into us_read for this file, which is formatted! Probably a bad default flag is set. I think you are right. I have been putting in debug statements all over and find that we are asking the wrong length of reads, 8 characters, instead of 1 in the failing case. I will get back to this in a day or so.
Re: [Bug libfortran/25116] [regression wrt g77] namelist read from non-opened file
fxcoudert at gcc dot gnu dot org wrote: --- Comment #2 from fxcoudert at gcc dot gnu dot org 2005-11-27 23:14 --- (In reply to comment #1) At line 2 of file nml.f Fortran runtime error: End of file Debugging shows that the bytes_left field of the stream is not set correctly (2338621003140048416 instead of 9223372036854775807). It is set in transfer.c, line 1143. If you mean this: memcpy (&i, p, sizeof (gfc_offset)); dtp->u.p.current_unit->bytes_left = i; Maybe it should be a -= Jerry
Re: [Bug libfortran/25017] sqrt, csqrt may give a wrong result if real part of compex argument is zero
fxcoudert at gcc dot gnu dot org wrote: --- Comment #1 from fxcoudert at gcc dot gnu dot org 2005-11-24 13:05 --- This bug is in glibc (same code on non-glibc platform, such as sparc-solaris, will give the right answer). It was reported in glibc bugzilla as #1466 (http://sources.redhat.com/bugzilla/show_bug.cgi?id=1466), and is now fixed in glibc CVS. Perhaps we need to workaround that bug somewhere. Opinions, please! How long before next glibc release? This problem could be painful for folks that are using gfortran for real world applications who are not aware. Maybe we need to add an errata file to the tree and add a message at the end of configure to remind people to read the errata file. This would go for all of gcc, not just gfortran. Jerry
