[Bug fortran/55117] Programs fails to read namelist (contains derived types objects)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55117 Tilo Schwarz changed: What|Removed |Added CC||t...@tilo-schwarz.de --- Comment #11 from Tilo Schwarz 2013-02-22 20:57:50 UTC --- Hi, I ran into this today and tried to produce a small test case from my big namelist problem. program namelist type d1 integer :: j = 0 end type d1 type d2 type(d1) k end type d2 type d3 type(d2) d(2) end type d3 type(d3) der namelist /nmlst/ der read (*, nml = nmlst) print nmlst end program namelist Running above program on all two line combinations of the namelist gives different errors using 4.7.2 and gcc version 4.8.0 20130222 (experimental) (GCC) (Details below). Observations: - If type d3 uses 'type(d1) d(2)' instead of 'type(d2) d(2)', the problem goes away. - If the trailing %J is removed in the namelist, the problem goes away. - If two separate members are used instead of the array 'type(d2) d(2)', the problem goes away. Details of namelist variations: % cat namelist.txt; echo ---; prg_namelist_bug < namelist.txt &NMLST / --- &NMLST DER%D(1)%K%J= 0, DER%D(2)%K%J= 0, / % cat namelist.txt; echo ---; prg_namelist_bug < namelist.txt &NMLST DER%D(1)%K%J = 1, / --- &NMLST DER%D(1)%K%J= 1, DER%D(2)%K%J= 0, / % cat namelist.txt; echo ---; prg_namelist_bug < namelist.txt &NMLST DER%D(2)%K%J = 2, / --- &NMLST DER%D(1)%K%J= 2, DER%D(2)%K%J= 0, / % cat namelist.txt; echo ---; prg_namelist_bug < namelist.txt &NMLST DER%D(1)%K%J = 1, DER%D(2)%K%J = 2, / --- &NMLST DER%D(1)%K%J= 2, DER%D(2)%K%J= 0, / % cat namelist.txt; echo ---; prg_namelist_bug < namelist.txt &NMLST DER%D(2)%K%J = 2, DER%D(1)%K%J = 1, / --- &NMLST DER%D(1)%K%J= 1, DER%D(2)%K%J= 0, / If the last component %J is removed in the namelist, the problem goes away: % cat namelist.txt; echo ---; prg_namelist_bug < namelist.txt &NMLST DER%D(1)%K = 1, / --- &NMLST DER%D(1)%K%J= 1, DER%D(2)%K%J= 0, / % cat namelist.txt; echo ---; prg_namelist_bug < namelist.txt &NMLST DER%D(2)%K = 2, / --- &NMLST DER%D(1)%K%J= 0, DER%D(2)%K%J= 2, / % cat namelist.txt; echo ---; prg_namelist_bug < namelist.txt &NMLST DER%D(1)%K = 1, DER%D(2)%K = 2, / --- &NMLST DER%D(1)%K%J= 1, DER%D(2)%K%J= 2, / % cat namelist.txt; echo ---; prg_namelist_bug < namelist.txt &NMLST DER%D(2)%K = 2, DER%D(1)%K = 1, / --- &NMLST DER%D(1)%K%J= 1, DER%D(2)%K%J= 2, / Regards, Tilo
[Bug fortran/55117] Programs fails to read namelist (contains derived types objects)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55117 --- Comment #12 from Tilo Schwarz 2013-02-22 22:40:11 UTC --- (In reply to comment #11) > Running above program on all two line combinations of the namelist gives > different errors using > 4.7.2 and > gcc version 4.8.0 20130222 (experimental) (GCC) > (Details below). What I meant here was, that the namelist variations give different errors, not that 4.7.2 and 4.8.0 give different errors. Tilo
[Bug fortran/55117] Programs fails to read namelist (contains derived types objects)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55117 --- Comment #13 from Tilo Schwarz 2013-02-24 00:27:49 UTC --- If in gfortran.dg/namelist_64.f90 instead of curve(1)%symbol%typee = 1234 any other array index > 1 is set and tested, e.g. curve(2)%symbol%typee = 1234 the testcase breaks.
[Bug fortran/55117] Programs fails to read namelist (contains derived types objects)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55117 --- Comment #14 from Tilo Schwarz 2013-02-25 01:00:01 UTC --- Created attachment 29532 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29532 Namelist patch
[Bug fortran/55117] Programs fails to read namelist (contains derived types objects)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55117
--- Comment #15 from Tilo Schwarz 2013-02-25 01:02:45
UTC ---
This week I used the Fortran namelist feature for the first time and I was
really impressed, that it does all the parsing for me.
But since I ran into this issue I was wondering and curious how the magic in
libgfortran works.
I had a look at the code and could observe the following:
If I apply the attached patch (comment 14, namelist.diff) on gcc version 4.8.0
20130224
- my example from comment 11 works
- the example from comment 3 seems to work
- the changed namelist_64.f90 from comment 13 works
- the example from PR 51825 seems to work
- make check-fortran runs with no additional errors
- the example from comment 6 (type extension) does not work
The type extension problem might be related to the fact, that gfortran does not
generate a namelist entry for the implicit component %x of t1e_t:
(no "t1e%x" below)
_gfortran_st_set_nml_var (&dt_parm.1, &t1e, &"t1e"[1]{lb: 1 sz: 1}, 0, 0,
40);
... maybe "t1e%x" should be here? ...
_gfortran_st_set_nml_var (&dt_parm.1, &t1e.t1_t, &"t1e%t1_t"[1]{lb: 1 sz: 1},
0, 0, 40);
_gfortran_st_set_nml_var (&dt_parm.1, &t1e.t1_t.x, &"t1e%t1_t%x"[1]{lb: 1 sz:
1}, 4, 0, 24);
_gfortran_st_set_nml_var (&dt_parm.1, &t1e.string, &"t1e%string"[1]{lb: 1 sz:
1}, 1, 8, 48);
_gfortran_st_set_nml_var (&dt_parm.1, &answer, &"answer"[1]{lb: 1 sz: 1}, 4,
0, 8);
So maybe this patch gives a hint to someone, who has a deeper understanding of
the io-stuff than me (looked at it this weekend for the first time) ...
Tilo
[Bug fortran/55117] Programs fails to read namelist (contains derived types objects)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55117 --- Comment #16 from Tilo Schwarz 2013-02-25 19:01:50 UTC --- (In reply to comment #14) > Created attachment 29532 [details] > Namelist patch Bummer, I had a typo in the comment: The second hunk should read "/* Don't move first_nl" instead of "/* Don't move pprev_nl": @@ -2901,7 +2901,8 @@ get_name: goto nml_err_ret; } - if (*pprev_nl == NULL || !component_flag) + /* Don't move first_nl further in the list if a qualifier was found */ + if ((*pprev_nl == NULL && !qualifier_flag) || !component_flag) first_nl = nl; Sorry, Tilo
[Bug fortran/55117] Programs fails to read namelist (contains derived types objects)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55117
--- Comment #18 from Tilo Schwarz 2013-02-25 20:28:40
UTC ---
(In reply to comment #17)
> (In reply to comment #15)
> > The type extension problem might be related to the fact, that gfortran does
> > not
> > generate a namelist entry for the implicit component %x of t1e_t:
> >
> > (no "t1e%x" below)
> >
> It is present...
>
> > _gfortran_st_set_nml_var (&dt_parm.1, &t1e.t1_t.x, &"t1e%t1_t%x"[1]{lb: 1
> > sz:
> > 1}, 4, 0, 24);
> >
> ... here.
Yes, somehow - but the code in list_read.c:find_nml_node() (as it is right now)
searches for the exact string "t1e%x", not for "t1e%t1_t%x".
I have no idea what is simpler:
- modify the code in list_read.c to somehow also search "t1e%t1_t%x", not only
"t1e%x". Maybe one could teach the code to conclude from the to namelist
entries
_gfortran_st_set_nml_var (&dt_parm.1, &t1e.t1_t, &"t1e%t1_t"...
_gfortran_st_set_nml_var (&dt_parm.1, &t1e.t1_t.x, &"t1e%t1_t%x"
that "t1e%x" is also valid a synonym of "t1e%t1_t%x".
or
- generate a line like
_gfortran_st_set_nml_var (&dt_parm.1, &t1e.t1_t.x, &"t1e%x" ...
[Bug fortran/56594] Invalid read of size 1 for gfortran.dg/realloc_on_assign_5.f03
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56594
Tilo Schwarz changed:
What|Removed |Added
CC||t...@tilo-schwarz.de
--- Comment #1 from Tilo Schwarz 2013-03-17 19:56:11 UTC
---
I think the problem is, that for the line
a = a(2:2)
1st, a is realloced to length one and
2nd, a(2) is memmoved to a(1), but at that time a(2) is already invalid.
Using -fdump-tree-original:
On line 42 the realloc happens to length 1.
On line 50 the memmove happens from &(*a)[2], which is not valid anymore
because of the realloc on line 42.
42 a = (character(kind=1)[1:.a] *) __builtin_realloc ((void *) a, 1);
43 L.4:;
44 .a = 1;
45 D.1827 = .a;
46 if (D.1827 != 0)
47 {
48 if ((character(kind=4)) D.1827 <= 1)
49 {
50 __builtin_memmove ((void *) a, (void *) &(*a)[2]{lb: 1 sz:
1}, (character(kind=4)) D.1827);
51 }
[Bug fortran/52512] Cannot match namelist object name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52512 Tilo Schwarz changed: What|Removed |Added CC||t...@tilo-schwarz.de --- Comment #5 from Tilo Schwarz 2013-03-25 20:13:56 UTC --- Author: tiloschwarz Date: Mon Mar 25 20:11:20 2013 New Revision: 197061 URL: http://gcc.gnu.org/viewcvs?rev=197061&root=gcc&view=rev Log: 2013-03-25 Tilo Schwarz PR libfortran/52512 * io/list_read.c (nml_parse_qualifier): To check for a derived type don't use the namelist head element type but the current element type. (nml_get_obj_data): Add current namelist element type to nml_parse_qualifier call. 2013-03-25 Tilo Schwarz PR libfortran/52512 * gfortran.dg/namelist_79.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/namelist_79.f90 Modified: trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/io/list_read.c
[Bug testsuite/51875] FAIL: gfortran.dg/guality/pr41558.f90 -O0 line 7 s == 'foo'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51875 --- Comment #4 from Tilo Schwarz 2013-01-19 20:44:46 UTC --- Also seen on platform Linux 3.2.0-4-686-pae #1 SMP Debian 3.2.35-2 i686 GNU/Linux using % gfortran -v Using built-in specs. COLLECT_GCC=gfortran-master COLLECT_LTO_WRAPPER=/home/tschwarz/Unix/libexec/gcc/i686-pc-linux-gnu/4.8.0/lto-wrapper Target: i686-pc-linux-gnu Configured with: ../configure --prefix=/home/tschwarz/Unix --program-suffix=-master --disable-multilib --enable-languages=fortran --disable-bootstrap Thread model: posix gcc version 4.8.0 20130118 (experimental) (GCC)
[Bug fortran/55887] [OOP][F2008] ICE with CLASS and data-target pointer association in (default) initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55887 Tilo Schwarz changed: What|Removed |Added CC||t...@tilo-schwarz.de --- Comment #1 from Tilo Schwarz 2013-01-24 19:16:25 UTC --- I don't know how much help this actually is, but on my machine this commit commit a90fe8299d2e635e53ab006c934154289d06ffa1 Author: pault Date: Thu Dec 20 00:15:00 2012 + 2012-12-19 Paul Thomas git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@194622 138bc75d-0d04-0410-961f-82ee72b054a4 gives an ICE, but one commit earlier commit 873f242d97571e98acad8ea1912f81682bd7a448 Author: burnus Date: Wed Dec 19 23:05:49 2012 + 2012-12-19 Tobias Burnus git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@194621 138bc75d-0d04-0410-961f-82ee72b054a4 does not. Regards, Tilo
