This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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



------- 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]