From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17714 invoked by alias); 8 Aug 2013 19:46:06 -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 Received: (qmail 17622 invoked by uid 48); 8 Aug 2013 19:46:03 -0000 From: "janus at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/51945] Diagnose wrong default initialization of DTs in a DT declaration Date: Thu, 08 Aug 2013 19:46:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Version: 4.7.0 X-Bugzilla-Keywords: accepts-invalid, diagnostic X-Bugzilla-Severity: normal X-Bugzilla-Who: janus at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2013-08/txt/msg00500.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51945 --- Comment #4 from janus at gcc dot gnu.org --- The following patch should somewhat improve the situation: Index: gcc/fortran/resolve.c =================================================================== --- gcc/fortran/resolve.c (revision 201576) +++ gcc/fortran/resolve.c (working copy) @@ -1178,7 +1178,7 @@ resolve_structure_cons (gfc_expr *expr, int init) gfc_basic_typename (comp->ts.type)); t = false; } - else + else if (!init) { bool t2 = gfc_convert_type (cons->expr, &comp->ts, 1); if (t) @@ -12344,7 +12344,7 @@ resolve_fl_derived0 (gfc_symbol *sym) if (c->initializer && !sym->attr.vtype && !gfc_check_assign_symbol (sym, c, c->initializer)) - return false; + continue; } check_defined_assignments (sym); The first hunk suppresses the errors in the resolution of the symbol 'a', since they should already be thrown in the resolution of the type. The second hunk makes sure one gets the error in both components when resolving the type (a similar thing is also done in PR 58023 comment 5). With the above patch I get the expected result on the original test case in comment 0: Error: Can't convert TYPE(t2) to TYPE(t) at (1) Error: Can't convert TYPE(t3) to TYPE(t) at (1) On the version with the uncommented line, each error unfortunately still appears twice, but that is due to the fact that the type symbol is resolved twice (cf. also PR 44978).