From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15332 invoked by alias); 19 Feb 2011 15:07:40 -0000 Received: (qmail 15323 invoked by uid 22791); 19 Feb 2011 15:07:39 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,KAM_STOCKGEN X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 19 Feb 2011 15:07:35 +0000 From: "paul.richard.thomas at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/44945] [4.6 Regression] Wrong decl for module vars / FAIL: gfortran.dg/char_array_structure_constructor.f90 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: paul.richard.thomas at gmail dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P4 X-Bugzilla-Assigned-To: pault at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.6.0 X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Date: Sat, 19 Feb 2011 15:12:00 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2011-02/txt/msg02256.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D44945 --- Comment #32 from 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->mo= dule" > is not needed as the whole block is enclosed in such a check. > > I also would move the block down into > =C2=A0 =C2=A0 =C2=A0 =C2=A0if (gsym && gsym->ns && gsym->type =3D=3D GSYM= _MODULE) > which could be changed into > =C2=A0 =C2=A0 =C2=A0 =C2=A0if (!gsym || (gsym && gsym->ns && gsym->type = =3D=3D GSYM_MODULE)) > > And > - =C2=A0 =C2=A0 =C2=A0 =C2=A0gfc_find_symbol (sym->name, gsym->ns, 0, &s); > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (gsym) > + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0gfc_find_symbol (sym->name, gsym->ns,= 0, &s); > > And then placing the "if (gsym =3D=3D NULL)" in the > + =C2=A0 =C2=A0 =C2=A0 else if (s =3D=3D NULL) > block. All done. > (In reply to comment #30) >> The bus error reported in comment #21 has disappeared from my scope betw= een >> revisions 167584 and 167726;-( > > Ditto here, but looking at the dump, I see that the underlying issue is s= till > present - and it is fixed by the patch. > > =C2=A0* * * > > 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 b= ut > runtimes are different) and for Jack (-O3 miscompilation of xplor-nih's s= link.f > and tenso.f, unless -fno-whole-file is used; -fno-inline-functions does n= ot > help). Is there a PR for Jack's problem. Thanks for looking at the patch Paul