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/44945] [4.6 Regression] Wrong decl for module vars / FAIL: gfortran.dg/char_array_structure_constructor.f90


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

--- Comment #32 from paul.richard.thomas at gmail dot com <paul.richard.thomas at gmail dot com> 2011-02-19 15:07:03 UTC ---
Dear Tobias,


>
> Aha, you have taken the simple route of modifying trans-decl.c and not the
> whole module reading apparatus :-)

Of course - otherwise, we stand no chance of getting rid of the
regression.  It's only a small addition to the existing section of
code, so I thought that it had the advantage of being very clean too.

The revamp of module.c can wait until we have nothing to do :-)

>
> I think the patch is OK, though I would do some reordering, e.g. "sym->module"
> is not needed as the whole block is enclosed in such a check.
>
> I also would move the block down into
> Â Â Â Âif (gsym && gsym->ns && gsym->type == GSYM_MODULE)
> which could be changed into
> Â Â Â Âif (!gsym || (gsym && gsym->ns && gsym->type == GSYM_MODULE))
>
> And
> - Â Â Â Âgfc_find_symbol (sym->name, gsym->ns, 0, &s);
> + Â Â Â Â if (gsym)
> + Â Â Â Â Âgfc_find_symbol (sym->name, gsym->ns, 0, &s);
>
> And then placing the "if (gsym == NULL)" in the
> + Â Â Â else if (s == NULL)
> block.

All done.

> (In reply to comment #30)
>> The bus error reported in comment #21 has disappeared from my scope between
>> revisions 167584 and 167726;-(
>
> Ditto here, but looking at the dump, I see that the underlying issue is still
> present - and it is fixed by the patch.
>
> Â* * *
>
> I will do some more tests.

Let me know when you have done them.  What about a testcase?  I guess
that since it was a testsuite failure we do not need one?
>
> Related to those whole-file DECL issues: I wonder why there are still
> differences between -flto and -fno-lto on Polyhedron (result is correct but
> runtimes are different) and for Jack (-O3 miscompilation of xplor-nih's slink.f
> and tenso.f, unless -fno-whole-file is used; -fno-inline-functions does not
> help).

Is there a PR for Jack's problem.

Thanks for looking at the patch

Paul


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