[Bug fortran/95647] operator(.eq.) and operator(==) treated differently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95647 --- Comment #10 from Jerry DeLisle --- Oops, that what I get for doing 16 things at once. sorry.
[Bug fortran/95647] operator(.eq.) and operator(==) treated differently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95647 --- Comment #8 from Jerry DeLisle --- (In reply to Jerry DeLisle from comment #6) > (In reply to Bill Long from comment #5) > > Is this fixed in a release version of GCC? > > Submitting patch for approval and will backport as the fix is simple. How > far back shall we go? 10 for sure. Eyeballing the time lines, it does not > look like 9 will have any more releases. If someone knows otherwise, let me > know. While putting together a test case, I found another problem. program test use, intrinsic :: ieee_arithmetic, only : & &ieee_class, & &ieee_class_type, & &ieee_negative_normal, & &ieee_positive_normal, & &operator(.eq.) ! use, intrinsic :: ieee_arithmetic real(4) r4 type(ieee_class_type) class1 r4 = 1.0 class1 = ieee_class(r4) if (class1 .eq. ieee_positive_normal) print *, 'yes' if (class1 .ne. ieee_negative_normal) print *, 'yes' r4 = -1.0 class1 = ieee_class(r4) if (class1 .eq. ieee_negative_normal) print *, 'yes' if (class1 .ne. ieee_positive_normal) print *, 'yes' end program test $ gfc pr95647.f90 pr95647.f90:14:6: 14 | if (class1 .ne. ieee_negative_normal) print *, 'yes' | 1 Error: Operands of comparison operator ‘.ne.’ at (1) are TYPE(ieee_class_type)/TYPE(ieee_class_type) pr95647.f90:18:6: 18 | if (class1 .ne. ieee_positive_normal) print *, 'yes' | 1 Error: Operands of comparison operator ‘.ne.’ at (1) are TYPE(ieee_class_type)/TYPE(ieee_class_type) There is more to the story apparently
[Bug fortran/95647] operator(.eq.) and operator(==) treated differently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95647 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at charter dot net --- Comment #6 from Jerry DeLisle --- (In reply to Bill Long from comment #5) > Is this fixed in a release version of GCC? Submitting patch for approval and will backport as the fix is simple. How far back shall we go? 10 for sure. Eyeballing the time lines, it does not look like 9 will have any more releases. If someone knows otherwise, let me know.
[Bug libfortran/98825] Unexpected behavior of FORTRAN FORMAT expressions when suppressing new line with '$'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98825 --- Comment #9 from Jerry DeLisle --- The folowing patch fixes this and regression tests OK. diff --git a/libgfortran/io/transfer.c b/libgfortran/io/transfer.c index 8ab0583dd55..27bee9d4e01 100644 --- a/libgfortran/io/transfer.c +++ b/libgfortran/io/transfer.c @@ -4020,6 +4020,8 @@ next_record_w (st_parameter_dt *dtp, int done) } } } + else if (dtp->u.p.seen_dollar == 1) + break; /* Handle legacy CARRIAGECONTROL line endings. */ else if (dtp->u.p.current_unit->flags.cc == CC_FORTRAN) next_record_cc (dtp);
[Bug libfortran/98825] Unexpected behavior of FORTRAN FORMAT expressions when suppressing new line with '$'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98825 --- Comment #8 from Jerry DeLisle --- I agree with your comment #7
[Bug libfortran/98825] Unexpected behavior of FORTRAN FORMAT expressions when suppressing new line with '$'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98825 --- Comment #6 from Jerry DeLisle --- I found the DEC F77 reference. I wanted to capture this somewhere for future reference: o MESSAGE: Extension to FORTRAN-77: nonstandard FORMAT statement item EXPLANATION: The following format field descriptors are extensions to FORTRAN-77: Descriptor Aspect -- -- $ All forms A,L,I,F,E,G,D Default field width forms P Without scale factor and then: $ In a format specification, the dollar sign character ($) modifies the carriage control specified by the first character of the record. It only affects the files for which the 'FORTRAN' carriage control attribute is in effect. On U*X systems, it also affects files if 'LIST' is in effect. In an input statement, the $ descriptor is ignored. In an output statement, the following rules apply: - If the first character of the record is 0, 1, or ASCII NUL, the $ descriptor is ignored. - If the first character of the record is a space or plus sign (+), the $ descriptor suppresses carriage return (after printing the record). For terminal I/O, whenever trailing carriage return control is suppressed by the $ descriptor, a typed response follows output on the same line. I am working on it.
[Bug libfortran/98825] Unexpected behavior of FORTRAN FORMAT expressions when suppressing new line with '$'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98825 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at charter dot net --- Comment #4 from Jerry DeLisle --- Yes, this can be patched. I would like to confirm if this is old DEC feature so I know whether it should go behind one of the DEC compiler flags.
[Bug fortran/95644] [F2018] IEEE_FMA is missing from the IEEE_ARITHMETIC module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95644 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at charter dot net --- Comment #6 from Jerry DeLisle --- Hi Bill, per our operational security procedure we can't talk about ieee_arithmetic, especially when we dont get paid. However, I can go look at the code and see if Steve's patch got in or not.
[Bug fortran/98490] Unexpected out of bounds in array constructor with implied do loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98490 --- Comment #5 from Jerry DeLisle --- Patch regresses several test cases.
[Bug fortran/98490] Unexpected out of bounds in array constructor with implied do loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98490 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at charter dot net --- Comment #4 from Jerry DeLisle --- With gfortran version 11.0.0 20201227 $ gfc -fbounds-check pr98490.f90 $ $ ./a.out At line 15 of file pr98490.f90 Fortran runtime error: Substring out of bounds: lower bound (0) of 'text' is less than one After Steves patch: $ gfc -fbounds-check pr98490.f90 $ ./a.out Lorem ipsum Steve would you like me to commit for you? Regression testing now.
[Bug fortran/97063] [ MATMUL intrinsic] The value of result is wrong when vector (step size is negative) * matrix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97063 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at charter dot net --- Comment #3 from Jerry DeLisle --- (In reply to anlauf from comment #2) > Interestingly, the bug "disappears" if frontend optimization is enabled > (-ffrontend-optimize), thus at all optimizations that enable it. It could be we need to fix in the runtime library. I have not looked to closely yet but it would be best I think if the front-end did the necessary transforming. The code is probably there already to do it.
[Bug fortran/89219] ICE with derived type I/O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89219 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at charter dot net --- Comment #5 from Jerry DeLisle --- See also PR97037.
[Bug fortran/97037] ICE on user-defined derived-type output of an intermediate ancestor type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97037 --- Comment #2 from Jerry DeLisle --- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89219
[Bug fortran/97037] ICE on user-defined derived-type output of an intermediate ancestor type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97037 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at charter dot net --- Comment #1 from Jerry DeLisle --- This may be related to or the same as 89219
[Bug libfortran/97017] New: The function determine_precision is called twice for each formatted real write
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97017 Bug ID: 97017 Summary: The function determine_precision is called twice for each formatted real write Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: jvdelisle at charter dot net Target Milestone: --- I discovered this while working on the EX formattting feature. The determine_precision function is called by both get_precision and inside the macro FORMAT_FLOAT used by get_float_string. To me this implies we have something factored wrong as we should not have to call it twice to get things done. (a small performance issue as well as obscure) A simple test case will show the issue in a debugger: ! pr93727 EX Format Specifiers program main implicit none real(4) :: r4 real(8) :: r8 r4 = 3.14158_4 r8 = 12.3456789_8 print *, r4, r8 end program main
[Bug libfortran/93727] Fortran 2018: EX edit descriptor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93727 --- Comment #4 from jvdelisle at charter dot net --- An Update. I have the front end and runtime parsing for OUTPUT done and am now looking at the actual implementation. We have the printf series of functions available and can use the %A format specifier to create the hexidecimal float string. I want to note here that on input, apparently the F editing requires one to be able to READ a hexadecimal float with the F descriptor as well as the EX descriptor. See 13.7.2.3.2 part 7. Another aspect I am studying has to do with rounding. On output I assume we must support RU, RD, RN vs truncating. Considering that the purpose of this type of representation of a float is mostly for "looking under the hood" I initially was thinking simple truncation should suffice and if a user does not know they have not specified enough precision for all hexadecimals, tough beans. After all, in hexadecimal, it is always an exact fit. I am curious what others think about this. Regardless, we will need a new rounding function to round the hexadecimals before output. On input, obviously we need to do a new read function and for the F descriptor we will have to look ahead to identify that it is a hexadecimal before processing it, otherwise it just looks like a bad float.
[Bug libfortran/93727] Fortran 2018: EX edit descriptor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93727 --- Comment #3 from jvdelisle at charter dot net --- Interesting language if not sort of weird: "exp is a binary exponent expressed as a decimal integer" I am in early stages of choosing how to do this.
[Bug fortran/96325] Unclassifiable statement with syntax similar to a type-bound procedure call is accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96325 --- Comment #17 from jvdelisle at charter dot net --- (In reply to CVS Commits from comment #16) > The master branch has been updated by Paul Thomas : > Paul, I see you got the format just right. I stumbled on that part and then decided to get out of town for sanity. I went up to the mountains and found the official center of the universe (seriously, I know where it is now). In my half of the State here we are in Insanity Phase 1.5 on Steve's scale. Cheers all. ;)
[Bug fortran/96325] Unclassifiable statement with syntax similar to a type-bound procedure call is accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96325 --- Comment #11 from jvdelisle at charter dot net --- (In reply to kargl from comment #10) ---snip--- > Thanks for testing. Does the patch that follows fix the regressions? > gfortran treats components and type bound procedures separately. I've > (hopefully) adapted the patch to whether foo is either. > ---snip--- Patch at comment 10 passes patch provided in comment 10 passes regression testing. I will commit to trunk and use the original case as a test case tomorrow.
[Bug fortran/96325] Unclassifiable statement with syntax similar to a type-bound procedure call is accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96325 jvdelisle at charter dot net changed: What|Removed |Added CC||jvdelisle at charter dot net --- Comment #9 from jvdelisle at charter dot net --- I regression tested the patch in comment 8 and see these failures. FAIL: gfortran.dg/pr93423.f90 -O (test for excess errors) FAIL: gfortran.dg/typebound_call_31.f90 -O (test for errors, line 14) FAIL: gfortran.dg/typebound_call_31.f90 -O (test for excess errors)
[Bug fortran/96320] gfortran 8-10 shape mismatch in assumed-length dummy argument character array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320 jvdelisle at charter dot net changed: What|Removed |Added CC||jvdelisle at charter dot net --- Comment #6 from jvdelisle at charter dot net --- I my too simple terms, when you define the interface and then use module procedure in the contains, all of the declarations in the interface exist as if you had them in the declaration of the subroutine or function in the contains. This includes all arguments and whether or not the procedure is a subroutine or a function. I was not aware of this either untill I saw some other code Damian was doing earlier this week that does actually compile fine like this with gfortran. It is a modern feature and if you think about it, very useful in that it saves a lot of typing. One can choose do do it either way, but this way shown truly uses the interface to define everything.
[Bug fortran/93733] F2008: G0.d output editing for integer/logical/character data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93733 jvdelisle at charter dot net changed: What|Removed |Added CC||jvdelisle at charter dot net --- Comment #10 from jvdelisle at charter dot net --- There are two levels of checking, compile time and run time. Compile time, if the string is known/constant in gcc/fortran/format.c (IIRC). Runtime is libgfortran parse_format_string or similar. The -std=xxx routines are always a little different betwen implementation in compile time and run-time. Honestly, every time I do these checks I have to try combination to find the right one. Hope this helps a little. If you get stuck, let me know and I will try to take a closer look.
[Bug fortran/96255] [F2018] Implement optional type spec for index in DO CONCURRENT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96255 --- Comment #5 from jvdelisle at charter dot net --- (In reply to kargl from comment #2) > This issue depends on the fix for FORALL. In gfc_match_do in the concurrent > section, one gets to > > m = match_forall_header (, ); > > to match the control portion of the statement. Although we need to support forall, it is interesting that the standards committe i going to deprecate it, if they have not done so already. Not encouraged to be used for sure. Also they will be adding features to DO CONCUURENT which look useful to me.
[Bug fortran/96255] [F2018] Implement optional type spec for index in DO CONCURRENT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96255 --- Comment #4 from jvdelisle at charter dot net --- (In reply to kargl from comment #1) > This is related to PR78219. > > If someone takes up the challenge, then this show accept only > standard conforming type specs. That is, INTEGER*4 should be > rejected. This means one should use the method introduced in > array.c(gfc_match_array_constructor) for code to match > a type spec in an array constructor. Looks like a copy and > paste with an additional check for INTEGER. Agree 200%, tired of people implementing the bad.
[Bug fortran/96255] New: [F2018] Implement option type spec for index DO CONCURRENT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96255 Bug ID: 96255 Summary: [F2018] Implement option type spec for index DO CONCURRENT Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jvdelisle at charter dot net Target Milestone: --- F2018 provides for an optional type spec in the DO CONCURRENT construct: R1125 concurrent-header is ( [ integer-type-spec :: ] concurrent-control-list [ , scalar-mask-expr ] ) There is a constraint that it must be of type integer. This construct allows it to be declared locally to its block. program looper implicit none !integer i do concurrent (integer :: i=1:10) print *, i end do end program looper $ gfc -c looper.f03 looper.f03:6:19: 6 |do concurrent (integer :: i=1:10) | 1 Error: Syntax error in DO statement at (1) looper.f03:8:6: 8 |end do | 1 Error: Expecting END PROGRAM statement at (1) looper.f03:7:15: 7 | print *, i | 1 Error: Symbol ‘i’ at (1) has no IMPLICIT type
[Bug fortran/92643] ISO_Fortran_binding_15.f90 failure on i586-*-freebsd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92643 jvdelisle at charter dot net changed: What|Removed |Added CC||jvdelisle at charter dot net --- Comment #12 from jvdelisle at charter dot net --- (In reply to kargl from comment #11) > (In reply to Dominique d'Humieres from comment #10) > > > As of svn reversion r280157, the issue is not fixed. > > > > Do you know the git equivalent? > > No. I don't use git. r280157 is the last svn revision before > it was turned into a read-only archive. Boost my memory, is that 32 bit platform?
[Bug libfortran/93567] G edit descriptor uses E instead of F editing in rounding mode UP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93567 jvdelisle at charter dot net changed: What|Removed |Added CC||jvdelisle at charter dot net --- Comment #6 from jvdelisle at charter dot net --- (In reply to Dominique d'Humieres from comment #4) > The patch in comment 3 broke gfortran.dg/round_3.f08. > > The following should work > > --- ../_clean/libgfortran/io/write_float.def 2020-06-13 03:11:55.0 > +0200 > +++ libgfortran/io/write_float.def2020-07-21 00:37:24.0 +0200 > @@ -1004,7 +1004,11 @@ determine_en_precision (st_parameter_dt >exp_d = calculate_exp_ ## x (d);\ >r_sc = (1 - r / exp_d);\ >temp = 0.1 * r_sc;\ > - if ((m > 0.0 && ((m < temp) || (r >= (exp_d - m\ > + if ((m > 0.0 && ((m < temp) || (r == 0.5 && r >= (exp_d - m))\ > + || (r == 1 && !sign_bit && 1 > (exp_d - m))\ > + || (r == 1 && sign_bit && 0 >= (exp_d - m))\ > + || (r == 0 && !sign_bit && 0 >= (exp_d - m))\ > + || (r ==0 && sign_bit && 1 > (exp_d - m\ ^ > || ((m == 0.0) && !(compile_options.allow_std\ > & (GFC_STD_F2003 | GFC_STD_F2008)))\ > || d == 0)\ It gets complicated quickly with all the corner cases. Lat line of the added logic needs a space before the 0
[Bug fortran/85796] ICE: Floating point exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85796 jvdelisle at charter dot net changed: What|Removed |Added CC||jvdelisle at charter dot net --- Comment #3 from jvdelisle at charter dot net --- This looks OK Steve. Assuming your regression tested, shall I commit this for you?
[Bug libfortran/93727] Fortran 2018: EX edit descriptor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93727 jvdelisle at charter dot net changed: What|Removed |Added CC||jvdelisle at charter dot net --- Comment #1 from jvdelisle at charter dot net --- I will take this one.
[Bug testsuite/95546] Random Fortran test failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95546 jvdelisle at charter dot net changed: What|Removed |Added CC||jvdelisle at charter dot net --- Comment #4 from jvdelisle at charter dot net --- I am curious, did this just start happening or is it a long time issue just reported. Locking mecahnisms were adjusted recently I believe.
[Bug libfortran/89020] close(status='DELETE') does not remove file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89020 --- Comment #15 from jvdelisle at charter dot net --- On 1/26/19 1:07 PM, anlauf at gmx dot de wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89020 > > Harald Anlauf changed: > > What|Removed |Added > > CC||anlauf at gmx dot de > > --- Comment #13 from Harald Anlauf --- > Jerry, > > are you sure that the second part of the patch is intended? > > remove (u->filename) vs. remove (path) > Nope, copy paste, should be 'path'. Will fix. Thanks Jerry
[Bug fortran/78351] comma not terminating READ of formatted input field - ok in 4.1.7, not 4.4.7- maybe related to 25419?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78351
--- Comment #4 from jvdelisle at charter dot net ---
On 11/14/2016 11:09 AM, kargl at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78351
>
> kargl at gcc dot gnu.org changed:
>
>What|Removed |Added
>
> CC||kargl at gcc dot gnu.org
>
> --- Comment #3 from kargl at gcc dot gnu.org ---
> (In reply to Dr. Kevin B. Beard from comment #0)
>> Created attachment 40038 [details]
>> Simple example - comma no longer a format field delimiter - gfortran 4.1.2
>> ok, 4.4.7- fails
>>
>> Here @ NASA we often have strings to read of the form:
>>
>> #,#,#,#,.
>>
>> and on many platforms, gfortran 4.1.2 and (most?) earlier, Intel Fortran
>> 16.0.3, g77-3.4.6 and most other FORTRANs, it would treat the "," as a field
>> delimiter during a formatted READ - for example (x1.f):
>>
>> character*80 s
>> s= '1,2,3'
>> READ(s,'(2i10)') i,j
>> write(6,'(2i10)') i,j
>> end
>>
>> would print " 1 2".
>>
>> However, 4.4.7 ("gfortran -o x1 x1.f") now (11/2016) fails with
>>
>> "Fortran runtime error: Bad value during integer read".
>>
>> I believe it worked with 4.4.7 back in 9/2016 on ScientificLinux-6.4 fine,
>> but there have been security patches done since then. It also fails on
>> 4.8.5 and 5.3.0 under Red Hat Enterprise Linux Server release 5.11 It would
>> be very nice to be able to restore the old behavior.
>>
>> This may be related to bug#25519.
>
> gfortran's behavior conforms to the standard while your code
> does not conform. Perhaps, gfortran should accept a comma as
> a field delimiter under -std=legacy, but preference should
> be to fixing the wrong code.
>
> 10.7.2.2 Integer editing
>
> The Iw and Iw.m edit descriptors indicate that the field to be
> edited occupies w positions, except when w is zero. When w is
> zero, the processor selects the field width. On input, w shall
> not be zero. The specified input/output list item shall be of
> type integer. ...
>
> On input, m has no effect.
>
> In the input field for the I edit descriptor, the character string
> shall be a signed-digit-string (R409), except for the interpretation
> of blanks.
>
> R409 signed-digit-string is [ sign ] digit-string
> R410 digit-string
> R411 sign is digit [ digit ] ...
>
> is +
> or
>
>
> Perhaps, you want list-directed formatting
>
> 10.10 List-directed formatting
>
> 10.10.1 General
>
> List-directed input/output allows data editing according to the type
> of the list item instead of by a format specification. It also allows
> data to be free-field, that is, separated by commas (or semicolons) or
> blanks.
>
Thank you for that clarification. That makes it not a regression really, just
an
enhancement.
Jerry
[Bug fortran/78152] [6/7 Regression] coarray and associate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78152 --- Comment #6 from jvdelisle at charter dot net --- On 11/01/2016 01:45 PM, sgk at troutmask dot apl.washington.edu wrote: --- snip --- > Fortunately, I use FreeBSD as my operating system, which > unfortunately limits me to gfortran. I posted to c.l.f, > but haven't got much feedback. > Hi Steve, I am in the process of building OpenCoarrays and to give it a spin. Maybe we can think of a reasonable test case to use to test the feature that is not well defined yet and from a practical point view, see what makes sense. Also, off topic. (pardon the long wind here) I had a meeting with Damian Rousan today and we briefly talked about OpenCoarrays. He has mentioned on the gfortran list about enabling it into the build of gfortran if a user chooses to do so. So I thought I would take a look. Currently OpenCoarrays is built independent of gfortran and in fact if you don't have the right version of gfortran available, it will build gcc/gfortran as well as well. I am running his install script now, and one issue is that it builds gcc itself in single thread mode. I want to modify this so that if it detects multiple cores available, it can ask the user if they want to use these during build of gcc. On Linux I can cat /proc/cpuinfo to get at the information about the machine. Is there an equivalent FreeBSD way to query number of cores available? Jerry
[Bug fortran/77903] gfortran 6.1.0/7.0.0 accept invalid code with conflicting module/submodule interfaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77903 --- Comment #5 from jvdelisle at charter dot net --- On 10/11/2016 10:21 PM, damian at sourceryinstitute dot org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77903 > > --- Comment #4 from Damian Rouson --- > Check the date on your draft. The latest draft is dated 31 August 2016. > C1556 appears on page 330. Does the following link work for you? > > http://j3-fortran.org/doc/year/16/16-007.pdf > > I'm working on obtaining a publicly accessible link in case the above one > doesn't work. > > Damian > That link worked for me. Thanks Jerry
[Bug fortran/66480] FPE calling cpu_time() with -ffpe-trap=inexact
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66480 jvdelisle at charter dot net changed: What|Removed |Added CC||jvdelisle at charter dot net --- Comment #3 from jvdelisle at charter dot net --- It occurs here: Program received signal SIGFPE, Arithmetic exception. 0x77bb291a in _gfortrani_cpu_time_4 (time=0x7fffde7c) at ../../../trunk/libgfortran/intrinsics/cpu_time.c:53 53*time = sec + usec * GFC_REAL_4_LITERAL(1.e-6);
[Bug libfortran/48906] Wrong rounding results with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906 --- Comment #25 from jvdelisle at charter dot net 2011-06-06 12:09:48 UTC --- 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.
[Bug libfortran/48906] Wrong rounding results with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906 --- Comment #27 from jvdelisle at charter dot net 2011-06-06 12:36:21 UTC --- 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-02Too many significant digits? print (2pg12.3), 0.02 ! 0.200E-01 expected 20.00E-03 Too many significant digits? Should these last two cases by 2.00E-02 and 20.0E-03 ? Otherwise we seem to be adding an extra significant digit. Help me understand this. Jerry
