------- Comment #6 from jb at gcc dot gnu dot org 2009-09-06 13:55 ------- (In reply to comment #2) > Janne, I think the warning about "unix.c:750:15: warning: statbuf.st_mode > may > be used uninitialized" is spurious, but can you have a look?
Yes, it's spurious, and I submitted a patch (http://gcc.gnu.org/ml/gcc-patches/2009-09/msg00419.html), but maybe the middle-end shouldn't warn about it anyway (see the reply by Richard Guenther). > Jerry, there is some inconsistency regarding st_parameter_dt's "saved_type". > One finds both "bt" and "dtype" assignments, which does not make sense. Does > one need both types in a union? Or can one consolidate them? > > list_read.c: dtp->u.p.saved_type = BT_LOGICAL; > list_read.c: dtp->u.p.saved_type = GFC_DTYPE_UNKNOWN; > etc. I looked into this when I redid the lower layer I/O library, and I gave up in exasperation. This dichotomy between BT_* and GFC_DTYPE_* extends into the frontend, and would require lots of tedious work and an ABI change to fix. Perhaps at the same time we change the array descriptor we could fix this too (the descriptor also needs some form of type tag, and if we adopt the TR29113 descriptor that then also influences the type tag). I added a note about this to http://gcc.gnu.org/wiki/LibgfortranAbiCleanup . As an additional bonus, note that the bt enum is different in the frontend and the library, and some of the library entry points take bt enums as arguments, which makes one one wonder how the heck all this works.. :) > In write_a_char4, one has: > const char crlf[] = "\r\n"; > write_default_char4 (dtp, crlf, 2, 0); > but the second argument should be gfc_char4_t* Right. So what is "\r\n" in terms of gfc_char4_t? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41219
