[Bug fortran/37498] New: Incorrect array value returned

[Bug fortran/37498] New: Incorrect array value returned

[brtnfld at hdfgroup dot org]

GNU Fortran (GCC) 4.3.3 20080904 (prerelease)
FreeBSD  6.3-STABLE FreeBSD 6.3-STABLE, amd64

Given the program:

ROGRAM test_kind
 IMPLICIT NONE
 INTEGER :: i, j
 INTEGER, DIMENSION(1:3) :: kind_numbers
 kind_numbers(1:3) = 3
 DO i = 1, 3
    j = kind_numbers(i)
    PRINT*,i,j
 ENDDO
END PROGRAM test_kind

gfortran43 gives:
%a.out
          1           3
          2           0
          3           3 

gfortran44 and gfortran42 give the correct value of kind_numbers(2)=3


-- 
           Summary: Incorrect array value returned
           Product: gcc
           Version: 4.3.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: brtnfld at hdfgroup dot org


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

[Bug fortran/37498] Incorrect array value returned

[domob at gcc dot gnu dot org]

------- Comment #1 from domob at gcc dot gnu dot org  2008-09-12 18:07 -------
I've not checked, but maybe this is related to PR 37199?


-- 

domob at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |domob at gcc dot gnu dot org


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

[Bug fortran/37498] Incorrect array value returned

[jv244 at cam dot ac dot uk]

------- Comment #2 from jv244 at cam dot ac dot uk  2008-09-12 18:50 -------
(In reply to comment #1)
> I've not checked, but maybe this is related to PR 37199?
> 
I can not reproduce that with the 4.3 branch:

gcc version 4.3.3 20080912 (prerelease) (GCC)
vondele@pcihopt3:/data03/vondele/bug> ./a.out
           1           3
           2           3
           3           3
nor with 4.3.0


-- 


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

[Bug fortran/37498] Incorrect array value returned

[tkoenig at gcc dot gnu dot org]

------- Comment #3 from tkoenig at gcc dot gnu dot org  2008-09-12 19:05 -------
This may be due to an incompatibility between the 4.3
and 4.4 libraries.

What result do you get when you compile with "-static",
to make sure that you get the right library?


-- 


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

[Bug fortran/37498] Incorrect array value returned

[tkoenig at gcc dot gnu dot org]

------- Comment #4 from tkoenig at gcc dot gnu dot org  2008-09-12 19:19 -------
See PR 37501.


-- 


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

[Bug fortran/37498] Incorrect array value returned

[brtnfld at hdfgroup dot org]

------- Comment #5 from brtnfld at hdfgroup dot org  2008-09-12 19:38 -------
(In reply to comment #3)
> This may be due to an incompatibility between the 4.3
> and 4.4 libraries.
> 
> What result do you get when you compile with "-static",
> to make sure that you get the right library?
> 

That fixed the problem, my mistake. Thanks for pointing that out.


-- 


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

[Bug fortran/37498] [4.4 Regression] Incorrect array value returned

[tkoenig at gcc dot gnu dot org]

------- Comment #6 from tkoenig at gcc dot gnu dot org  2008-09-12 19:47 -------
(In reply to comment #5)
> (In reply to comment #3)
> > This may be due to an incompatibility between the 4.3
> > and 4.4 libraries.
> > 
> > What result do you get when you compile with "-static",
> > to make sure that you get the right library?
> > 
> 
> That fixed the problem, my mistake. Thanks for pointing that out.

Actually, this is a bug - the libraries are supposed to be upward
compatible, so that you can run a 4.3-compiled program with 4.4.
If that doesn't work, this is a bug in 4.4.

I get a different behaviour for you test case on i686-pc-linux-gnu -
and endless loop which outputs zeros only, so I can confirm this.


-- 

tkoenig at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |critical
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
           Keywords|                            |ABI, wrong-code
   Last reconfirmed|0000-00-00 00:00:00         |2008-09-12 19:47:33
               date|                            |
            Summary|Incorrect array value       |[4.4 Regression] Incorrect
                   |returned                    |array value returned
   Target Milestone|---                         |4.4.0


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

[Bug fortran/37498] [4.4 Regression] Incorrect array value returned

[tkoenig at gcc dot gnu dot org]

------- Comment #7 from tkoenig at gcc dot gnu dot org  2008-09-12 19:57 -------
The value of i gets overwritten in the library when assiging
a value to dtp->u.p.mode.  OUCH.

This is what I get when running the 4.3 - compiled program
against the 4.4 library:

$ gfortran-4.3 -g foo.f90
$ gdb ./a.out
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...
(gdb) b foo.f90:2
Breakpoint 1 at 0x80485a1: file foo.f90, line 2.
(gdb) r
Starting program: /home/ig25/Krempel/ABI/a.out

Breakpoint 1, test_kind () at foo.f90:5
5        kind_numbers(1:3) = 3
Current language:  auto; currently fortran
(gdb) watch i
Hardware watchpoint 2: i
(gdb) c
Continuing.
Hardware watchpoint 2: i

Old value = -1208866858
New value = 1
0x080485d5 in test_kind () at foo.f90:6
6        DO i = 1, 3
(gdb) c
Continuing.
Hardware watchpoint 2: i

Old value = 1
New value = 0
data_transfer_init (dtp=0xbf82f9f0, read_flag=0) at
../../../../gcc/trunk/libgfortran/io/transfer.c:1825
1825      dtp->u.p.mode = read_flag ? READING : WRITING;
Current language:  auto; currently c
(gdb)                                                                   


-- 


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

[Bug fortran/37498] [4.4 Regression] Incorrect array value returned

[burnus at gcc dot gnu dot org]

------- Comment #8 from burnus at gcc dot gnu dot org  2008-09-12 20:49 -------
The problem is this harmless looking variable in the program (from
-fdump-tree-original):
              struct __st_parameter_dt dt_parm.2;
This struct matches st_parameter_dt in libgfortran/io/io.h. If one compares 4.3
with 4.4 one finds:
@@ -329,0 +384,9 @@ typedef struct st_parameter_dt
+  GFC_IO_INT *id;
+  GFC_IO_INT pos;
+  CHARACTER1 (asynchronous);
+  CHARACTER2 (blank);
+  CHARACTER1 (decimal);
+  CHARACTER2 (delim);
+  CHARACTER1 (pad);
+  CHARACTER2 (round);
+  CHARACTER1 (sign);
@@ -344 +407,2 @@ typedef struct st_parameter_dt
-         enum {SIGN_S, SIGN_SS, SIGN_SP} sign_status;
+          unit_pad pad_status;
+         enum { SIGN_S, SIGN_SS, SIGN_SP } sign_status;
@@ -356,0 +421,2 @@ typedef struct st_parameter_dt
+         unit_decimal decimal_status;
+          unit_delim delim_status;

Ideas how to make this compatible? If not, shall we bump the version number
(and include the rank change ;-) ?


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jvdelisle at gcc dot gnu dot
                   |                            |org


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

[Bug fortran/37498] [4.4 Regression] Incorrect array value returned

[jvdelisle at gcc dot gnu dot org]

------- Comment #9 from jvdelisle at gcc dot gnu dot org  2008-09-13 19:25 -------
I am working on fixing this now.  I will probably call for help on parts of
this.


-- 

jvdelisle at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |jvdelisle at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2008-09-12 19:47:33         |2008-09-13 19:25:36
               date|                            |


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

[Bug fortran/37498] [4.4 Regression] Incorrect array value returned

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P4


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

[Bug fortran/37498] [4.4 Regression] Incorrect array value returned

[jvdelisle at gcc dot gnu dot org]

------- Comment #10 from jvdelisle at gcc dot gnu dot org  2008-09-14 12:11 -------
See http://gcc.gnu.org/ml/fortran/2008-09/msg00259.html for start of patch and
request for comments.


-- 


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

[Bug fortran/37498] [4.4 Regression] Incorrect array value returned

[tkoenig at gcc dot gnu dot org]

------- Comment #11 from tkoenig at gcc dot gnu dot org  2008-09-15 17:42 -------
Hi Jerry,

I'd like help you out on this as soon as time permits (which
may be a few days yet)

Just a couple of thoughts, which may or may not be helpful:

- We chould take this opportunity to bring the front end
  and library into sync via including the ioparm.def field

- We could mark the use of F 2003 features with a flag
  and precede all uses with if (V4_4(dtp) && actual_test...)
  for a suitable macro V4_4

- We should run the 4.3 testsuite with the 4.3 compiler and the
  4.4 library every once in a while (for example when we have
  fixed this bug :-)

Best of luck

Thomas


-- 


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

[Bug fortran/37498] [4.4 Regression] Incorrect array value returned

[jvdelisle at gcc dot gnu dot org]

------- Comment #12 from jvdelisle at gcc dot gnu dot org  2008-09-17 04:13 -------
Created an attachment (id=16342)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16342&action=view)
Partial patch - reordering of st_parameter_dt structure

I think I may know why the attached patch does not completely work.  Runtime
library side is fine.  In trans-io.c (build_dt) we are not actually building
the pad structure which is a character array.  We do build the type declaration
for this structure elsewhere.

I think that without "building" the code for the pad, building of the
componenets after pad get messed up because they are not getting chained onto
the end of anything.  I am not a tree expert but it seems intuitive to me that
this or something similar is the problem.

Using gdb you can view the runtime and you can see some of the pieces of
attempts to set the dtparms after the union of p and pad, but they are miss
placed or misaligned.

Test case I use:

real  a
a = 3.141591
open(10, file='mydata', asynchronous="yes", blank="null")

write(10,'(10f8.6)', asynchronous="yes", decimal="point", id=j) a

end

gdb view: break at data_transfer_init and I print this after the pad is cleared
to shorton the output.

(gdb) p *dtp
$2 = {common = {flags = 1380352, unit = 10, 
    filename = 0x400a00 "f2003_io_1.f03", line = 8, iomsg_len = 32681, 
    iomsg = 0x0, iostat = 0x1}, rec = 25769803782, size = 0x400a0f, 
  iolength = 0x3fef4091f1, internal_unit_desc = 0x7fffa8611770, 
  format = 0x400a21 "(10f8.6)", format_len = 8, advance_len = 32767, 
  advance = 0x4f0603b38 <Address 0x4f0603b38 out of bounds>, 
  internal_unit = 0x400a15 "nullyespoint(10f8.6)", 
  internal_unit_len = -1470031696, namelist_name_len = 32767, 
  namelist_name = 0x7fa9a0614000 "", u = {p = {transfer = 0, 
      current_unit = 0x0, item_count = 0, mode = READING, 
      blank_status = BLANK_NULL, sign_status = SIGN_S, scale_factor = 0, 
      max_pos = 0, skips = 0, pending_spaces = 0, sf_seen_eor = 0, 
      advance_status = ADVANCE_YES, reversion_flag = 0, first_item = 0, 
      seen_dollar = 0, eor_condition = 0, no_leading_blank = 0, char_flag = 0, 
      input_complete = 0, at_eol = 0, comma_flag = 0, namelist_mode = 0, 
      nml_read_error = 0, sf_read_comma = 0, line_buffer_enabled = 0, 
      unit_is_internal = 0, at_eof = 0, last_char = 0 '\0', 
      nml_delim = 0 '\0', repeat_count = 0, saved_length = 0, saved_used = 0, 
      saved_type = BT_NULL, saved_string = 0x0, scratch = 0x0, 
      line_buffer = 0x0, fmt = 0x0, eof_jump = 0x0, ionml = 0x0, 
      expanded_read = 0, value = '\0' <repeats 31 times>, size_used = 0, 
      pad_status = PAD_YES, decimal_status = DECIMAL_POINT, 
      delim_status = DELIM_NONE}, pad = '\0' <repeats 255 times>}, 
  id = 0x3fef40d185, pos = 1, asynchronous = 0x7fffa8611908 "", 
  asynchronous_len = 256, blank_len = 0, 
  blank = 0x3 <Address 0x3 out of bounds>, 
  decimal = 0x400a19 "yespoint(10f8.6)", decimal_len = 1, delim_len = 0, 
  delim = 0x5a8611a18 <Address 0x5a8611a18 out of bounds>, 
  pad = 0x400a1c "point(10f8.6)", pad_len = -258655760, round_len = 63, 
  round = 0x400900 "L\211d$&#65533;L\211l$&#65533;L\215%\033\002 ", 
  sign = 0x7fffa8611a28 "&#65533;6a&#65533;&#65533;\177", sign_len =
-1470031336}


-- 


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

[Bug fortran/37498] [4.4 Regression] Incorrect array value returned

[jvdelisle at gcc dot gnu dot org]

------- Comment #13 from jvdelisle at gcc dot gnu dot org  2008-09-20 15:29 -------
Proposed solution:

I will add another component to the st_parameter_dt union and call it q.  It
will be identical to the existing component p accept with the added IOparms at
the top.  In the 4.4 library we will reference the q instead of p.  4.4
compiled applications should then see their respective runtime information and
4.3 should be unaffected.

I will give it a shot and see, the editing is straight forward.


-- 


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

[Bug fortran/37498] [4.4 Regression] Incorrect array value returned - 4.3 ABI Broken

[jvdelisle at gcc dot gnu dot org]

------- Comment #14 from jvdelisle at gcc dot gnu dot org  2008-09-21 04:15 -------
Experimental patch submitted to list for comment.

http://gcc.gnu.org/ml/fortran/2008-09/msg00353.html


-- 


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

[Bug fortran/37498] [4.4 Regression] Incorrect array value returned - 4.3 ABI Broken

[jvdelisle at gcc dot gnu dot org]

------- Comment #15 from jvdelisle at gcc dot gnu dot org  2008-09-21 21:18 -------
Final patch submitted  to list for approval:

http://gcc.gnu.org/ml/fortran/2008-09/msg00364.html


-- 


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

[Bug fortran/37498] [4.4 Regression] Incorrect array value returned - 4.3 ABI Broken

[jvdelisle at gcc dot gnu dot org]

------- Comment #16 from jvdelisle at gcc dot gnu dot org  2008-09-23 03:53 -------
Subject: Bug 37498

Author: jvdelisle
Date: Tue Sep 23 03:52:19 2008
New Revision: 140576

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140576
Log:
2008-09-22  Jerry DeLisle  <jvdelisle@gcc.gnu.org

        PR fortran/37498
        * trans-io.c (gfc_build_io_library_fndecls): Bump pad size.
        (build_dt): Set mask bit for IOPARM_dt_f2003.
        * ioparm.def: Add IOPARM_dt_f2003.

2008-09-22  Jerry DeLisle  <jvdelisle@gcc.gnu.org

        PR libfortran/37498
        * file_pos (st_endfile): Clear memory only for libfortran 4.3 private
        area.
        * list_read.c (eat_separator): Only access F2003 I/O parameters if
        IOPARM_DT_HAS_F2003 bit is set. (parse_real): Ditto.
        (read_real): Ditto.
        * read.c (read_a): Likewise. (read_a_char4): Likewise though not
        strictly necessary. (read_f): Likewise.
        * io.h (unit_sign_s): New enumerator to allow duplication of
        st_parameter structures. (IOPARM_DT_HAS_F2003): New mask bit.
        (st_parameter_43): New structure copied from 4.3 version of 
        st_paramater_dt private section. (st_parameter_44): New structure with
        F2003 items added. (st_parameter_dt): Modified to create union of new
        and old structures to allow correct memory setting for 4.3 ABI
        compatibility. Bumped the pad size.
        * transfer.c (read_sf): Do not use F2003 I/O memory areas unless
        IOPARM_DT_HAS_F2003 bit has been set. (read_block_form): Ditto.
        (formatted_transfer_scalar): Ditto. (data_transfer_init): Ditto and
        add comment, fix formatting.
        * write.c (write_default_char4): Likewise though not strictly
necessary.
        (write_utf8_char4): Ditto. (write_character): Ditto.
        (write_real_g0): Ditto. (list_formatted_write_scalar): Ditto.
        (nml_write_obj): Ditto. (namelist_write): Ditto.
        * write_float.def (calculate_sign): Eliminate warning by including all
        cases in switch. (output_float): Output only decimal point of F2003
flag
        is not set.

Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/ioparm.def
    trunk/gcc/fortran/trans-io.c
    trunk/libgfortran/ChangeLog
    trunk/libgfortran/io/file_pos.c
    trunk/libgfortran/io/io.h
    trunk/libgfortran/io/list_read.c
    trunk/libgfortran/io/read.c
    trunk/libgfortran/io/transfer.c
    trunk/libgfortran/io/write.c
    trunk/libgfortran/io/write_float.def


-- 


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

[Bug fortran/37498] [4.4 Regression] Incorrect array value returned - 4.3 ABI Broken

[jvdelisle at gcc dot gnu dot org]

------- Comment #17 from jvdelisle at gcc dot gnu dot org  2008-09-23 06:26 -------
I was doing some additional testing after the above patch and see that it
breaks other things w.r.t 4.3 ABI.  An example is namelist_14.f90 which fails
with a 4.3 executable and 4.4 library.  I am keeping this PR open while I sort
this issue out further.  4.3 kept delim_status in unit_flags instead of in the
st_parameter_dt of 4.4

Stay tuned.


-- 


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

[Bug fortran/37498] [4.4 Regression] Incorrect array value returned - 4.3 ABI Broken

[jvdelisle at gcc dot gnu dot org]

------- Comment #18 from jvdelisle at gcc dot gnu dot org  2008-09-24 05:14 -------
Created an attachment (id=16399)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16399&action=view)
New patch that is much better

I could not submit this to the list for approval, my email is not working. 
Regression tested on x86-64.  This patch reverts a lot of the previous and
results in a much cleaner fix that works with the namelist_14 example. If I can
get approval I will commit.


-- 

jvdelisle at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #16342|0                           |1
        is obsolete|                            |


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

[Bug fortran/37498] [4.4 Regression] Incorrect array value returned - 4.3 ABI Broken

[jvdelisle at gcc dot gnu dot org]

------- Comment #19 from jvdelisle at gcc dot gnu dot org  2008-09-26 06:16 -------
Subject: Bug 37498

Author: jvdelisle
Date: Fri Sep 26 06:15:21 2008
New Revision: 140683

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140683
Log:
2008-09-25  Jerry DeLisle  <jvdelisle@gcc.gnu.org

        PR fortran/37498
        * trans-io.c (build_dt): Revert previous patch..
        * ioparm.def: Delete IOPARM_dt_f2003.

Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/ioparm.def
    trunk/gcc/fortran/trans-io.c


-- 


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

[Bug fortran/37498] [4.4 Regression] Incorrect array value returned - 4.3 ABI Broken

[jvdelisle at gcc dot gnu dot org]

------- Comment #20 from jvdelisle at gcc dot gnu dot org  2008-09-26 06:21 -------
Subject: Bug 37498

Author: jvdelisle
Date: Fri Sep 26 06:19:42 2008
New Revision: 140684

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140684
Log:
2008-09-25  Jerry DeLisle  <jvdelisle@gcc.gnu.org

        PR libfortran/37498
        * list_read.c (eat_separator): Revert previous patch and move
        delim_status, decimal_status, and pad_status to gfc_unit.
        (parse_real): Ditto. (read_real): Ditto.
        * read.c (read_a): Likewise. (read_a_char4): Likewise.
        (read_f): Likewise.
        * inquire.c (inquire_via_unit): Add missing check for
        IOPARM_INQUIRE_HAS_FLAGS2. (inquire_via_filename): Likewise.
        * io.h (unit_sign_s): Move delim_status, decimal_status, and pad_status
        to gfc_unit.
        * transfer.c (read_sf): Ditto. (read_block_form): Ditto.
        (formatted_transfer_scalar): Ditto. (data_transfer_init): Ditto.
        * write.c (write_default_char4): Ditto. (write_utf8_char4): Ditto.
        (write_character): Ditto. (write_real_g0): Ditto.
        (list_formatted_write_scalar): Ditto. (nml_write_obj): Ditto.
        (namelist_write): Ditto.
        * write_float.def (calculate_sign): Ditto. (output_float): Ditto.

Modified:
    trunk/libgfortran/ChangeLog
    trunk/libgfortran/io/inquire.c
    trunk/libgfortran/io/io.h
    trunk/libgfortran/io/list_read.c
    trunk/libgfortran/io/read.c
    trunk/libgfortran/io/transfer.c
    trunk/libgfortran/io/write.c
    trunk/libgfortran/io/write_float.def


-- 


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

[Bug fortran/37498] [4.4 Regression] Incorrect array value returned - 4.3 ABI Broken

[jvdelisle at gcc dot gnu dot org]

------- Comment #21 from jvdelisle at gcc dot gnu dot org  2008-09-27 12:57 -------
Fixed on 4.4.


-- 

jvdelisle at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


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