[Bug fortran/84070] New: Incorrect assignment to allocatable character variable

2018-01-26 Thread walt.brainerd at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84070

Bug ID: 84070
   Summary: Incorrect assignment to allocatable character variable
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: walt.brainerd at gmail dot com
  Target Milestone: ---

character(len=:), allocatable :: c
c = "abc"
print *, "A" // c // "Z"
c = c(1:0) // c(2:)
print *, "A" // c // "Z"
print *, iachar(" "), iachar(c(2:2))
end

PROFITOOL+WAB@DEN-000256L /cygdrive/c
$ !.
./a
 AabcZ
 Ab Z
  32  32

Note missing character "c" after assignment.
It is instead a space.

[Bug fortran/79383] USE statement error

2018-01-11 Thread walt.brainerd at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79383

--- Comment #3 from Walt Brainerd  ---
Yes, Sounds like you have it fixed. Thanks.

On Wed, Jan 10, 2018 at 7:06 PM, kargl at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79383
>
> kargl at gcc dot gnu.org changed:
>
>What|Removed |Added
> 
> 
>  CC||kargl at gcc dot gnu.org
>
> --- Comment #2 from kargl at gcc dot gnu.org ---
> The attached code compiles with both 7-branch an trunk.
> When the resulting excutable is run I get 15.10 on output.
> Is this the expected behavior?
>
> --
> You are receiving this mail because:
> You reported the bug.

[Bug fortran/80009] Printing/writing a structure with a real edit descriptor.

2017-06-10 Thread walt.brainerd at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80009

--- Comment #12 from Walt Brainerd  ---
I made a misstatement in my previous message.
gfortran 7.0.1 does not accept this.

Sorry, my "test" was not correct.

I am going to post a query to comp-fortran-90 to see what others think.

On Fri, Jun 9, 2017 at 12:08 PM, Walt Brainerd 
wrote:

> I am not sure what you changed your mind from or to :-).
>
> Yes, the assignment is invalid because r is real the the rhs is type
> B_type.
>
> And, yes, the type of the io list item is B_type.
>
> However, the uncommented WRITE statement is valid, and,
> in the absence or a DT edit descriptor, the components (one real) are
> written in order, so 20.0 is written with f4.1 format.
>
> ifort 2017 and gfortran 7.01. both agree with this (maybe the latter
> because of you).
>
> If you disagree with this, I would be happy to solicit opinions from more
> experts.
>
> On Thu, Jun 8, 2017 at 10:05 PM, jvdelisle at gcc dot gnu.org <
> gcc-bugzi...@gcc.gnu.org> wrote:
>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80009
>>
>> --- Comment #10 from Jerry DeLisle  ---
>> After a lot of head scratching I think I am changing my mind on this one.
>>
>> If one tries to assign to a real variable as in:
>>
>> program test_b_write_dt_mod
>>
>>use :: B_write_dt_mod
>>implicit none
>>
>>type(B_type) :: x != B_type(20.0)
>>real :: r
>>
>>r = B_type(20.0)
>>
>>write (unit=*, fmt="(f4.1)") B_type(20.0)
>>!write (unit=*, fmt="(f4.1)") x
>>
>> end program test_b_write_dt_mod
>>
>> The effective item is of type B_type not real and the assignment to r is
>> rejected.
>>
>> So I believe the effective type in the write statement is likewise
>> derived type
>> ad not real.
>>
>> My thinking is this PR is invalid.
>>
>> --
>> You are receiving this mail because:
>> You reported the bug.
>
>
>
>
> --
> Walt Brainerd
>

[Bug fortran/80009] Printing/writing a structure with a real edit descriptor.

2017-06-09 Thread walt.brainerd at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80009

--- Comment #11 from Walt Brainerd  ---
I am not sure what you changed your mind from or to :-).

Yes, the assignment is invalid because r is real the the rhs is type B_type.

And, yes, the type of the io list item is B_type.

However, the uncommented WRITE statement is valid, and,
in the absence or a DT edit descriptor, the components (one real) are
written in order, so 20.0 is written with f4.1 format.

ifort 2017 and gfortran 7.01. both agree with this (maybe the latter
because of you).

If you disagree with this, I would be happy to solicit opinions from more
experts.

On Thu, Jun 8, 2017 at 10:05 PM, jvdelisle at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80009
>
> --- Comment #10 from Jerry DeLisle  ---
> After a lot of head scratching I think I am changing my mind on this one.
>
> If one tries to assign to a real variable as in:
>
> program test_b_write_dt_mod
>
>use :: B_write_dt_mod
>implicit none
>
>type(B_type) :: x != B_type(20.0)
>real :: r
>
>r = B_type(20.0)
>
>write (unit=*, fmt="(f4.1)") B_type(20.0)
>!write (unit=*, fmt="(f4.1)") x
>
> end program test_b_write_dt_mod
>
> The effective item is of type B_type not real and the assignment to r is
> rejected.
>
> So I believe the effective type in the write statement is likewise derived
> type
> ad not real.
>
> My thinking is this PR is invalid.
>
> --
> You are receiving this mail because:
> You reported the bug.

[Bug fortran/80484] Three syntax errors involving derived-type I/O

2017-04-22 Thread walt.brainerd at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80484

--- Comment #11 from Walt Brainerd  ---
Looks good. Great work.
You have done more than your share today to make the Fortran world a better
place.
Thanks!

On Sat, Apr 22, 2017 at 2:32 PM, jvdelisle at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80484
>
> --- Comment #10 from Jerry DeLisle  ---
> (In reply to Walt Brainerd from comment #9)
> > Just FYI, Intel 2017 compiles 3DT'...', but it does not run correctly
> > (response inspired by your comments about a similar possibility :-).
> >
>
> Seems to run OK with the patch. I changed statements to:
>
>write (unit=*, fmt="(DT'$$$Z.##')", iostat=ios, iomsg=iom) B_type(wage),
> B_type(wage)
>print *, trim(iom)
>write (unit=*, fmt="(2DT'$$$Z.##')", iostat=ios, iomsg=iom)
> B_type(wage),
> B_type(wage)
>print *, trim(iom)
>write (unit=*, fmt="(DT'$$$Z.##'/)", iostat=ios, iomsg=iom)
> B_type(wage),
> B_type(wage)
>
> Gives:
>
> $ ./a.out
>15.100
>15.100
>  OK
>15.100   15.100
>  OK
>15.100
>
>15.100
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
> You reported the bug.
>

[Bug fortran/80484] Three syntax errors involving derived-type I/O

2017-04-22 Thread walt.brainerd at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80484

--- Comment #9 from Walt Brainerd  ---
Just FYI, Intel 2017 compiles 3DT'...', but it does not run correctly
(response inspired by your comments about a similar possibility :-).

On Sat, Apr 22, 2017 at 12:35 PM, jvdelisle at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80484
>
> --- Comment #7 from Jerry DeLisle  ---
> Created attachment 41246
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41246=edit
> Preliminary patch for testing
>
> This patch takes care of the rejected format with a repeat in front of the
> DT
> and the '/' inserted after.  I am still testing and exploring the business
> with
> the USE statement.
>
> Note: I have not checked to make sure the runtime also handles the repeat
> correctly.  This is a work in progress. I am suspicious of this patch
> since I
> expected the unget_char to be sufficient and the lexing would cycle around
> and
> catch that '/'. Obviously it does not, but I do want to understand why
> not. I
> do understand why the repeat digit was missed and that part is good.
> (Helps if
> you put the new code in the right place, ;) )
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
> You reported the bug.

[Bug fortran/80484] Three syntax errors involving derived-type I/O

2017-04-22 Thread walt.brainerd at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80484

--- Comment #6 from Walt Brainerd  ---
I have added a complete program as an attachment to the bug report
(I think).

See comments in the program.

Pls let me know if there is something missing.

On Fri, Apr 21, 2017 at 7:27 PM, jvdelisle at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80484
>
> --- Comment #2 from Jerry DeLisle  ---
> (In reply to Walt Brainerd from comment #0)
> > Windows 10, gcc 7.0.1 20170416
> >
> > If the commented versions of the USE or WRITE statements
> > are used, the program works fine.
> >
> > The function B converts wage to a structure with one component.
> >
> > I can provide all the supporting code if needed,
> > but that doesn't seem relevant.
> >
>
> Yes, please provide. I need complete 'valid' code to test debug. I will
> eventually create a new test case for the testsuite. It is relevant
> because I
> need to reproduce exact conditions. Yes I could contrive something but I
> might
> miss something doing so.
>
> --
> You are receiving this mail because:
> You reported the bug.

[Bug fortran/80484] Three syntax errors involving derived-type I/O

2017-04-22 Thread walt.brainerd at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80484

Walt Brainerd  changed:

   What|Removed |Added

 CC||walt.brainerd at gmail dot com

--- Comment #5 from Walt Brainerd  ---
Created attachment 41244
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41244=edit
Complete program showing problems

Running the program as is shows two syntax errors.
Uncommenting the "use" stmt shows another.

Program works correctly by commenting out the last 2 write stmts.

Pls let me know if you have questions.

[Bug fortran/80484] Three syntax errors involving derived-type I/O

2017-04-22 Thread walt.brainerd at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80484

--- Comment #4 from Walt Brainerd  ---
OK, but it will take me some time to cut the thing down from
the several hundred lines that do the formatting.
Not hard to do, just will take a bit to get a good example.

Thanks for looking at this.


On Fri, Apr 21, 2017 at 7:27 PM, jvdelisle at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80484
>
> --- Comment #2 from Jerry DeLisle  ---
> (In reply to Walt Brainerd from comment #0)
> > Windows 10, gcc 7.0.1 20170416
> >
> > If the commented versions of the USE or WRITE statements
> > are used, the program works fine.
> >
> > The function B converts wage to a structure with one component.
> >
> > I can provide all the supporting code if needed,
> > but that doesn't seem relevant.
> >
>
> Yes, please provide. I need complete 'valid' code to test debug. I will
> eventually create a new test case for the testsuite. It is relevant
> because I
> need to reproduce exact conditions. Yes I could contrive something but I
> might
> miss something doing so.
>
> --
> You are receiving this mail because:
> You reported the bug.

[Bug fortran/80484] New: Three syntax errors involving derived-type I/O

2017-04-21 Thread walt.brainerd at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80484

Bug ID: 80484
   Summary: Three syntax errors involving derived-type I/O
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: walt.brainerd at gmail dot com
  Target Milestone: ---

Windows 10, gcc 7.0.1 20170416

If the commented versions of the USE or WRITE statements
are used, the program works fine.

The function B converts wage to a structure with one component.

I can provide all the supporting code if needed,
but that doesn't seem relevant.

program test_b_format

   use b_format_mod, only: B, write (formatted)
!   use b_format_mod
   implicit none

   real :: wage = 15.10
   integer :: ios
   character(len=99) :: iom = "OK"

!   write (unit=*, fmt="(DT'$$$Z.##')", iostat=ios, iomsg=iom) B(wage)
   write (unit=*, fmt="(2DT'$$$Z.##')", iostat=ios, iomsg=iom) B(wage)
   write (unit=*, fmt="(DT'$$$Z.##'/)", iostat=ios, iomsg=iom) B(wage)
   print *, trim(iom)

end program test_b_format

test_b_format.f90:3:47:

use b_format_mod, only: B, write (formatted)
   1
Error: Module nature in USE statement at (1) shall be either INTRINSIC or
NON_INTRINSIC
test_b_format.f90:12:36:

write (unit=*, fmt="(2DT'$$$Z.##')", iostat=ios, iomsg=iom) B(wage)
1
Error: Unexpected element ''' in format string at (1)
test_b_format.f90:13:35:

write (unit=*, fmt="(DT'$$$Z.##'/)", iostat=ios, iomsg=iom) B(wage)
   1
Error: Unexpected element '/' in format string at (1)

[Bug fortran/80009] Printing/writing a structure with a real edit descriptor.

2017-03-13 Thread walt.brainerd at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80009

--- Comment #7 from Walt Brainerd  ---
I took "not processed by" to mean that there is no DT edit descriptor
corresponding to it.

But I see how this might be interpreted otherwise.

Intel agrees with me FWIW.

Maybe this is a question for J3 (or perhaps first, c.l.f?).

Thanks for thinking about this.


On Sun, Mar 12, 2017 at 2:28 PM, jvdelisle at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80009
>
> --- Comment #6 from Jerry DeLisle  ---
> (In reply to Walt Brainerd from comment #1)
> > Forgot to add:
> >
> > Pls see F08 std 9.6.3(7) 2nd bullet
>
> I see:
>
> BULLET: If a list item of derived type in a formatted input/output
> statement is
> not processed by a defined input/output procedure, that list item is
> treated as
> if all of the components of the list item were specified in the list in
> component order; those components shall be accessible in the scoping unit
> containing the
> input/output statement and shall not be pointers or allocatable.
>
> In your case you have provided a defined output procedure. So this is what
> it
> is trying to do. see 'if' ... 'not processed by' above.
>
> Do I have the right place in the standard you were looking at? Maybe we
> are not
> interpreting that correctly?
>
> --
> You are receiving this mail because:
> You reported the bug.
>

[Bug fortran/80009] Printing/writing a structure with a real edit descriptor.

2017-03-12 Thread walt.brainerd at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80009

--- Comment #4 from Walt Brainerd  ---
Sorry, I cut the example down one step too many.
Please try this one. It works OK without all the stuff
related to DTIO.

BTW, I didn't mention: this is on Windows 10.

module B_write_dt_mod

   implicit none
   private

   type, public :: B_type
  real :: amount
   end type B_type

   interface write (formatted)
  procedure :: Write_b_real
   end interface

   public :: write (formatted)

contains

subroutine Write_b_real &
   (amount, unit, b_edit_descriptor, v_list, iostat, iomsg)

   class (B_type), intent(in) :: amount
   integer, intent(in) :: unit
   character (len=*), intent(in) :: b_edit_descriptor
   integer, dimension(:), intent(in) :: v_list
   integer, intent(out) :: iostat
   character (len=*), intent(inout) :: iomsg
   write (unit=unit, fmt="(a)", iostat=iostat) "444.44"

end subroutine Write_b_real

end module B_write_dt_mod

program test_b_write_dt_mod

   use :: B_write_dt_mod
   implicit none

   write (unit=*, fmt="(f4.1)") B_type(20.0)

end program test_b_write_dt_mod

[Bug fortran/80009] Printing/writing a structure with a real edit descriptor.

2017-03-12 Thread walt.brainerd at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80009

--- Comment #3 from Walt Brainerd  ---
Sorry, when trying to cut the bug to the smallest problem,
I went too far. I will start again.

On Sat, Mar 11, 2017 at 6:52 PM, dominiq at lps dot ens.fr <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80009
>
> Dominique d'Humieres  changed:
>
>What|Removed |Added
> 
> 
>  Status|UNCONFIRMED |WAITING
>Last reconfirmed||2017-03-12
>  Ever confirmed|0   |1
>
> --- Comment #2 from Dominique d'Humieres  ---
> Works for me (outputs 5.5 at run time) on x86_64-apple-darwin from 4.3.1
> up to
> trunk (7.0 r246000).
>
> --
> You are receiving this mail because:
> You reported the bug.

[Bug fortran/80009] Printing/writing a structure with a real edit descriptor.

2017-03-11 Thread walt.brainerd at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80009

--- Comment #1 from Walt Brainerd  ---
Forgot to add:

Pls see F08 std 9.6.3(7) 2nd bullet

[Bug fortran/80009] New: Printing/writing a structure with a real edit descriptor.

2017-03-11 Thread walt.brainerd at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80009

Bug ID: 80009
   Summary: Printing/writing a structure with a real edit
descriptor.
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: walt.brainerd at gmail dot com
  Target Milestone: ---

Created attachment 40948
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40948=edit
bug.f90, the file compiled as shown in Description/Comment

$ gfortran --version bug.f90
GNU Fortran (GCC) 7.0.1 20170122 (experimental)
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


Walt@HP_Envy /cygdrive/c/walt/ZHI/FC/FC_Code
$ ./a
At line 48 of file bug.f90 (unit = 6, file = 'stdout')
Fortran runtime error: Expected REAL for item 1 in formatted transfer, got
CLASS or DERIVED
(f4.1)
 ^

Error termination. Backtrace:

Could not print backtrace: libbacktrace could not find executable to open
#0  0x
#1  0x
#2  0x
#3  0x
#4  0x
#5  0x
#6  0x
#7  0x
#8  0x
#9  0x
#10  0x
#11  0x
#12  0x
#13  0x

[Bug fortran/79382] DTIO ICE

2017-02-06 Thread walt.brainerd at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79382

--- Comment #7 from Walt Brainerd  ---
With GENERIC and PUBLIC statements
   ifort says "No visible interface"
   gfortran gets an ICE
   So I assume the code is wrong, as you suggest, but both give funny
messages

With the other "bug" I filed: program g_bug2:
With an interface block and PUBLIC
   gfortran gives a strange message about "Module nature" on the USE
statement
   ifort works correctly.

I hope this helps; let me know if I can do anything else.

On Mon, Feb 6, 2017 at 11:01 AM, paul.richard.thomas at gmail dot com <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79382
>
> --- Comment #5 from paul.richard.thomas at gmail dot com
>  ---
> Hi Walt,
>
> My reading of the situation is that since, in this version, the
> generic procedure is typebound in a public derived type, the PUBLIC
> attribute is already accorded it. I think!
>
> Do you have access to a recent copy of ifort? Mine is on my
> workstation, which is still in storage after a house move. I would be
> curious to know how it responds to both the typebound and the explicit
> generic interface versions.
>
> Best regards
>
> Paul
>
> On 6 February 2017 at 17:50, walt.brainerd at gmail dot com
> <gcc-bugzi...@gcc.gnu.org> wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79382
> >
> > --- Comment #4 from Walt Brainerd  ---
> > Sorry, I forgot to remove the extraneous USE statement
> > which cutting down from the original code.
> >
> > I am not good with this new stuff; please explain what
> > the syntax error is? If the PUBLIC statement is not correct,
> > how do you make the write(formatted) interface public?
> >
> > Thanks for looking at this so quickly.
> >
> > --
> > You are receiving this mail because:
> > You are on the CC list for the bug.
>
> --
> You are receiving this mail because:
> You reported the bug.
>

[Bug fortran/79382] DTIO ICE

2017-02-06 Thread walt.brainerd at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79382

--- Comment #6 from Walt Brainerd  ---
You are probably right, but I have done all this on my home computer,
so I need to look at things again this evening. I do have ifort there and
will let you know.

I was trying all kinds of variations and can't remember what happened
with what. I did have one strange problem with ifort also (probably
related).

At least you have the ICE, which needs to be fixed somehow.

Thanks for your comments.

On Mon, Feb 6, 2017 at 11:01 AM, paul.richard.thomas at gmail dot com <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79382
>
> --- Comment #5 from paul.richard.thomas at gmail dot com
>  ---
> Hi Walt,
>
> My reading of the situation is that since, in this version, the
> generic procedure is typebound in a public derived type, the PUBLIC
> attribute is already accorded it. I think!
>
> Do you have access to a recent copy of ifort? Mine is on my
> workstation, which is still in storage after a house move. I would be
> curious to know how it responds to both the typebound and the explicit
> generic interface versions.
>
> Best regards
>
> Paul
>
> On 6 February 2017 at 17:50, walt.brainerd at gmail dot com
> <gcc-bugzi...@gcc.gnu.org> wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79382
> >
> > --- Comment #4 from Walt Brainerd  ---
> > Sorry, I forgot to remove the extraneous USE statement
> > which cutting down from the original code.
> >
> > I am not good with this new stuff; please explain what
> > the syntax error is? If the PUBLIC statement is not correct,
> > how do you make the write(formatted) interface public?
> >
> > Thanks for looking at this so quickly.
> >
> > --
> > You are receiving this mail because:
> > You are on the CC list for the bug.
>
> --
> You are receiving this mail because:
> You reported the bug.
>

[Bug fortran/79382] DTIO ICE

2017-02-06 Thread walt.brainerd at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79382

--- Comment #4 from Walt Brainerd  ---
Sorry, I forgot to remove the extraneous USE statement
which cutting down from the original code.

I am not good with this new stuff; please explain what
the syntax error is? If the PUBLIC statement is not correct,
how do you make the write(formatted) interface public?

Thanks for looking at this so quickly.

[Bug fortran/79383] New: USE statement error

2017-02-05 Thread walt.brainerd at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79383

Bug ID: 79383
   Summary: USE statement error
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: walt.brainerd at gmail dot com
  Target Milestone: ---

Created attachment 40672
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40672=edit
g_bug2.f90; complete program

I don't see anything wrong with the USE statement, BUT . . .

[I get the same error without "non_intrinsic"]

$ gfortran -Wall -Wextra g_bug2.f90
g_bug2.f90:37:73:

use, non_intrinsic :: dollar_mod, only: dollar_type, write (formatted)
 1
Error: Module nature in USE statement at (1) shall be either INTRINSIC or
NON_INTRINSIC
g_bug2.f90:40:21:

type (dollar_type), parameter :: wage = dollar_type(15.10)
 1
Error: Derived type 'dollar_type' at (1) is being used before it is defined
g_bug2.f90:41:34:

write (unit=*, fmt="(DT)") wage
  1
Error: Symbol 'wage' at (1) has no IMPLICIT type

[Bug fortran/79382] New: DTIO ICE

2017-02-05 Thread walt.brainerd at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79382

Bug ID: 79382
   Summary: DTIO ICE
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: walt.brainerd at gmail dot com
  Target Milestone: ---

Created attachment 40671
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40671=edit
g_bug.f90; complete program

DTIO ICE

$ gfortran --version
GNU Fortran (GCC) 7.0.1 20170122 (experimental)

Walt@HP_Envy /cygdrive/c/walt/ZHI/FC/FC_Code/Dollar_Bug
$ gfortran -Wall -Wextra g_bug.f90
f951.exe: internal compiler error: gfc_get_default_type(): Bad symbol
'_dtio_formatted_write'
libbacktrace could not find executable to open

Note: Things seem to work using an interface block
rather than GENERIC ::

[Bug fortran/65073] New: dynamic character assignment gives wrong result

2015-02-15 Thread walt.brainerd at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65073

Bug ID: 65073
   Summary: dynamic character assignment gives wrong result
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: walt.brainerd at gmail dot com

$ cat f.f90
character(len=:), allocatable :: c
c = abcde
print *,len(c), c
c = c(2:)
print *,len(c), c
end

Walt@HP_Envy ~/Books/SV/GF08P/P05
$ gfortran --version f.f90
GNU Fortran (x86_64-posix-seh-rev0, Built by MinGW-W64 project) 4.9.2
Copyright (C) 2014 Free Software Foundation, Inc.

Walt@HP_Envy ~/Books/SV/GF08P/P05
$ ./a
   5 abcde
   4 bcd

[Bug fortran/65045] New: ICE

2015-02-12 Thread walt.brainerd at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65045

Bug ID: 65045
   Summary: ICE
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: walt.brainerd at gmail dot com

Created attachment 34744
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34744action=edit
Tried to use i as variable and construct name

gfortran exit_if.f90
exit_if.f90:3.6:

 if (i7.7) then
  1
Error: Symbol at (1) is not appropriate for an expression
exit_if.f90:5.7:

   else
   1
Error: Unexpected ELSE statement at (1)
exit_if.f90:6.6:

 i = 2.2
  1
Error: 'i' at (1) is not a variable
exit_if.f90:7.6:

   end if
  1
Error: Expecting END BLOCK statement at (1)
f951.exe: internal compiler error: Segmentation fault

[Bug fortran/60128] New: Wrong ouput using en edit descriptor

2014-02-09 Thread walt.brainerd at gmail dot com 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128

Bug ID: 60128
   Summary: Wrong ouput using en edit descriptor
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: walt.brainerd at gmail dot com

I think the output should be -444.44E-03

$ cat x.f90
write(*,(en15.2)) -.4
end

Walt@HP_Laptop /cygdrive/c/walt/Testing
$ gfortran -Wall x.f90

Walt@HP_Laptop /cygdrive/c/walt/Testing
$ ./a
-444.40E-03

Walt@HP_Laptop /cygdrive/c/walt/Testing
$ gfortran --version
GNU Fortran (rev5, Built by MinGW-W64 project) 4.8.1
Copyright (C) 2013 Free Software Foundation, Inc.

[Bug fortran/60110] internal compiler error

2014-02-07 Thread walt.brainerd at gmail dot com 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60110

Walt Brainerd walt.brainerd at gmail dot com changed:

   What|Removed |Added

 CC||walt.brainerd at gmail dot com

--- Comment #1 from Walt Brainerd walt.brainerd at gmail dot com ---
OK, now I see the attachment. Sorry.

[Bug fortran/60110] New: internal compiler error

2014-02-07 Thread walt.brainerd at gmail dot com 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60110

Bug ID: 60110
   Summary: internal compiler error
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: walt.brainerd at gmail dot com

Created attachment 32079
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32079action=edit
source file gfortran_bug.f90

Sorry, I am not sure where to begin to cut this down.
I hope you can figure it out from the error msg.

This also fails the same way on the TDM build.

$ gfortran -c gfortran_bug.f90
gfortran_bug.f90: In function 'r701t735_array':
gfortran_bug.f90:2282:0: internal compiler error: in gfc_get_symbol_decl, at
for
tran/trans-decl.c:1265
   'mult-operand-16')
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See http://sourceforge.net/projects/mingw-w64 for instructions.

Walt@HP_Laptop /cygdrive/c/walt/Testing/U_F90_TS_15/TESTS/SYNTAX/RULES
$ gfortran --version
GNU Fortran (rev5, Built by MinGW-W64 project) 4.8.1
Copyright (C) 2013 Free Software Foundation, Inc.

I can't tell if the attachment is there or not ???

[Bug fortran/56581] Segfault when reading source file which starts with a byte-order mark (-cpp works)

2013-03-13 Thread walt.brainerd at gmail dot com 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56581



--- Comment #9 from Walt Brainerd walt.brainerd at gmail dot com 2013-03-13 
16:12:35 UTC ---

Thanks for sending me this.



Maybe I did after all provide something that will help you.



On Tue, Mar 12, 2013 at 3:05 PM, tkoenig at gcc dot gnu.org 

gcc-bugzi...@gcc.gnu.org wrote:





 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56581



 Thomas Koenig tkoenig at gcc dot gnu.org changed:



What|Removed |Added



 

Keywords||ice-on-invalid-code,

||rejects-valid

  Status|UNCONFIRMED |NEW

Last reconfirmed|2013-03-10 00:00:00 |2013-03-12

  Ever Confirmed|0   |1



 --- Comment #8 from Thomas Koenig tkoenig at gcc dot gnu.org 2013-03-12

 22:05:12 UTC ---

 We try to support this, but apparently it doesn't work

 (see line 2015 and following of scanner.c).



 Same thing happens for 4.6 and 4.7.



 Valgrind tells me



 ==11226== Memcheck, a memory error detector

 ==11226== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.

 ==11226== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info

 ==11226== Command: /home/ig25/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/f951

 ice.f

 ==11226==

 ==11226== Invalid write of size 4

 ==11226==at 0x580400: load_line(_IO_FILE*, unsigned int**, int*, int

 const*) (scanner.c:1646)

 ==11226==by 0x5811C3: load_file(char const*, char const*, bool)

 (scanner.c:2009)

 ==11226==by 0x582F82: gfc_new_file() (scanner.c:2120)

 ==11226==by 0x5A1DA7: gfc_init() (f95-lang.c:224)

 ==11226==by 0x94F286: toplev_main(int, char**) (toplev.c:1700)

 ==11226==by 0x5A38454: (below main) (in /lib64/libc-2.15.so)

 ==11226==  Address 0x5ea3e30 is 0 bytes after a block of size 288 alloc'd

 ==11226==at 0x4C292B8: calloc (in

 /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)

 ==11226==by 0xE54110: xcalloc (xmalloc.c:162)

 ==11226==by 0x58155E: load_file(char const*, char const*, bool)

 (scanner.c:2030)

 ==11226==by 0x582F82: gfc_new_file() (scanner.c:2120)

 ==11226==by 0x5A1DA7: gfc_init() (f95-lang.c:224)

 ==11226==by 0x94F286: toplev_main(int, char**) (toplev.c:1700)

 ==11226==by 0x5A38454: (below main) (in /lib64/libc-2.15.so)



 --

 Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email

 --- You are receiving this mail because: ---

 You reported the bug.

[Bug fortran/56581] seg fault

2013-03-10 Thread walt.brainerd at gmail dot com 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56581



--- Comment #2 from Walt Brainerd walt.brainerd at gmail dot com 2013-03-10 
16:03:37 UTC ---

Sorry, I was trying lots of different experiments and apparently

removed the ! before attaching the file.



I put it back in and now cannot reproduce the error.



Ignore this for now and I will let you know if I come up with

something again that is more useful to you.



After sending the bug report, I discovered another strange thing.

The first 24? bits of the file are junk that does not show up in any

editor. cat shows a little open rectangle and od shows it.

(These files were sent to me by somebody else.)



Sorry to trouble you and thanks for the work you guys do

on gfortran.



On Sun, Mar 10, 2013 at 5:22 AM, tkoenig at gcc dot gnu.org 

gcc-bugzi...@gcc.gnu.org wrote:





 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56581



 Thomas Koenig tkoenig at gcc dot gnu.org changed:



What|Removed |Added



 

  CC||tkoenig at gcc dot

 gnu.org



 --- Comment #1 from Thomas Koenig tkoenig at gcc dot gnu.org 2013-03-10

 12:22:54 UTC ---

 Unfortunately, I cannot reproduct this on Linux (also not

 with valgrind).



  The code is in error as the statement function

  is commented out, but seg error . . .



  Windows 7 running under cygwin, bash.



 The code, as attached, has



 C

 MCL23200

   AKF(A,B,E,X)=A*EXP(-B*E)*X

 MCL23210



 which I presume is the statement function.  It is not commented out,

 as far as I can see.



 Is it possible for you to run f951.exe under gdb?  This might

 give us some more information to work on.



 --

 Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email

 --- You are receiving this mail because: ---

 You reported the bug.

[Bug fortran/56581] seg fault

2013-03-10 Thread walt.brainerd at gmail dot com 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56581



--- Comment #5 from Walt Brainerd walt.brainerd at gmail dot com 2013-03-10 
19:39:42 UTC ---

I think that is exactly what they were (wrote a little

program to get rid of them).



The files were produced by OCR and then edited (not by me), so that

is all possible.



Thanks for pointing this out to me.



The Intel compiler seemed to completely ignore them,

but gfortran sometimes bombed and sometimes didn't

with f951.exe: out of memory . . . gfortran compiles all

the files in the set without a problem now. It is possible

that also caused the internal compiler error, but who knows.



On Sun, Mar 10, 2013 at 12:24 PM, burnus at gcc dot gnu.org 

gcc-bugzi...@gcc.gnu.org wrote:





 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56581



 Tobias Burnus burnus at gcc dot gnu.org changed:



What|Removed |Added



 

  CC||burnus at gcc dot gnu.org



 --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org 2013-03-10

 19:24:31 UTC ---

 (In reply to comment #2)

  After sending the bug report, I discovered another strange thing.

  The first 24? bits of the file are junk that does not show up in any

  editor. cat shows a little open rectangle and od shows it.

  (These files were sent to me by somebody else.)



 The extra bytes could be a Unicode byte-order marker? Especially under

 Windows,

 some editors like to insert them:

 https://en.wikipedia.org/wiki/UTF-8#Byte_order_mark



 --

 Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email

 --- You are receiving this mail because: ---

 You reported the bug.

[Bug fortran/56581] New: seg fault

2013-03-09 Thread walt.brainerd at gmail dot com 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56581



 Bug #: 56581

   Summary: seg fault

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: fortran

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: walt.brain...@gmail.com





Created attachment 29630

  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29630

Fixed-form Fortran source



The code is in error as the statement function

is commented out, but seg error . . .



$ gfortran -c rate1.f

rate1.f: In function 'rate1':

rate1.f:36:0: internal compiler error: Segmentation fault

   END  

MCL23370

 ^

libbacktrace could not find executable to open







$ gfortran --version

GNU Fortran (GCC) 4.8.0 20130302 (experimental) [trunk revision 196403]

Copyright (C) 2013 Free Software Foundation, Inc.







Windows 7 running under cygwin, bash.