From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29635 invoked by alias); 14 Jan 2014 14:24:05 -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 29586 invoked by uid 48); 14 Jan 2014 14:24:00 -0000 From: "mrestelli at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/59806] New: ICE with -ggdb AND -finit-real=snan AND namelist variable AND internal procedure Date: Tue, 14 Jan 2014 14:24:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Version: unknown X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: mrestelli at gmail dot com X-Bugzilla-Status: UNCONFIRMED 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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-01/txt/msg01466.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D59806 Bug ID: 59806 Summary: ICE with -ggdb AND -finit-real=3Dsnan AND namelist variable AND internal procedure Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mrestelli at gmail dot com Hi all, the attached code results in an internal compiler error when compiled with gfortran -ggdb -finit-real=3Dsnan -c ice.f90 Removing -ggdb and/or -finit-real=3Dsnan the code compiles correctly. Also, removing the namelist containing xx the problem disappears. (Sorry for the long "summary", could't find a shorter one). $ gfortran --version GNU Fortran (GCC) 4.9.0 20140110 (experimental) $ gfortran -ggdb -finit-real=3Dsnan -c ice.f90=20 ice.f90: In function =E2=80=98prog=E2=80=99: ice.f90:5:0: internal compiler error: in force_decl_die, at dwarf2out.c:201= 11 real :: xx ^ 0x704d34 force_decl_die gcc/dwarf2out.c:20111 0x705207 gen_namelist_decl gcc/dwarf2out.c:20632 0x700fd3 gen_decl_die gcc/dwarf2out.c:20435 0x71314f decls_for_scope gcc/dwarf2out.c:19969 0x6fe0ea gen_subprogram_die gcc/dwarf2out.c:18354 0x701014 gen_decl_die gcc/dwarf2out.c:20336 0x701df8 dwarf2out_function_decl gcc/dwarf2out.c:20776 0x75289c rest_of_handle_final gcc/final.c:4469 0x75289c execute gcc/final.c:4513 program prog implicit none real :: xx character(len=3D100) :: message ! removing the following line the problem disappears namelist /input/ xx contains subroutine check() write(message,'(e8.2)') xx end subroutine check end program prog >>From gcc-bugs-return-440325-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jan 14 14:34:37 2014 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 9354 invoked by alias); 14 Jan 2014 14:34:37 -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 Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 9300 invoked by uid 55); 14 Jan 2014 14:34:29 -0000 From: "nmm1 at cam dot ac.uk" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/34678] Optimization generates incorrect code with -frounding-math option (#pragma STDC FENV_ACCESS not implemented) Date: Tue, 14 Jan 2014 14:34:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Version: 4.3.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: nmm1 at cam dot ac.uk 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: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-01/txt/msg01467.txt.bz2 Content-length: 1670 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D34678 --- Comment #25 from Nick Maclaren --- On Jan 10 2014, vincent-gcc at vinc17 dot net wrote: > >http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D34678 > >--- Comment #24 from Vincent Lef=C3=A8vre - > >(In reply to Nick Maclaren from comment #23) > >> If __STDC_IEC_559__ is unset or does not have the value 1, setting >> STDC FENV_ACCESS to "on" is undefined behaviour (see 6.10.8.3, 7.6 and >> Annex F), unless the implementation explicitly chooses to extend the >> language to support it. > >You're wrong. The C standard doesn't say that. I am sorry, but it is you that is wrong. >6.10.8.3 says: "__STDC_IEC_559__ The integer constant 1, intended to indica >te >conformance to the specifications in annex F (IEC 60559 floating-point >arithmetic)." and nothing about STDC FENV_ACCESS. 3.4.3 says: undefined behavior behavior, upon use of a nonportable or erroneous program construct or of erroneous data, for which this International Standard imposes no requirements 4. Conformance, paragraph 2, says: ... Undefined behavior is otherwise indicated in this International Standard by the words "undefined behavior" or by the omission of any explicit definition of behavior. There is no difference in emphasis among these three; they all describe "behavior that is undefined". What "explicit definition of behavior" is there for the case when STDC FENV_ACCESS is set to "on" but __STDC_IEC_559__ is not set to one? As there is none, it is undefined behaviour. gcc can therefore do whatever it likes. Regards, Nick Maclaren. >>From gcc-bugs-return-440327-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jan 14 14:39:50 2014 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 16634 invoked by alias); 14 Jan 2014 14:39:49 -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 Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 16304 invoked by uid 48); 14 Jan 2014 14:39:45 -0000 From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/38518] Excessive compile time with -O3 Date: Tue, 14 Jan 2014 14:39:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: rtl-optimization X-Bugzilla-Version: 4.4.0 X-Bugzilla-Keywords: compile-time-hog X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth 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: cc 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: 2014-01/txt/msg01469.txt.bz2 Content-length: 2613 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38518 Richard Biener changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |stevenb.gcc at gmail dot com --- Comment #6 from Richard Biener --- The issue here is the DF machinery, or rather the fact that RTL invariant motion calls df_analyze () for each loop, thus void move_loop_invariants (void) { struct loop *loop; if (flag_ira_loop_pressure) { df_analyze (); regstat_init_n_sets_and_refs (); ira_set_pseudo_classes (true, dump_file); calculate_loop_reg_pressure (); regstat_free_n_sets_and_refs (); } df_set_flags (DF_EQ_NOTES + DF_DEFER_INSN_RESCAN); /* Process the loops, innermost first. */ FOR_EACH_LOOP (loop, LI_FROM_INNERMOST) { curr_loop = loop; /* move_single_loop_invariants for very large loops is time consuming and might need a lot of memory. */ if (loop->num_nodes <= (unsigned) LOOP_INVARIANT_MAX_BBS_IN_LOOP) move_single_loop_invariants (loop); } here move_single_loop_invariants -> find_invariants -> find_defs which does static void find_defs (struct loop *loop, basic_block *body) { unsigned i; bitmap blocks = BITMAP_ALLOC (NULL); for (i = 0; i < loop->num_nodes; i++) bitmap_set_bit (blocks, body[i]->index); if (dump_file) { fprintf (dump_file, "*****starting processing of loop %d ******\n", loop->num); } df_remove_problem (df_chain); df_process_deferred_rescans (); df_chain_add_problem (DF_UD_CHAIN); df_set_blocks (blocks); df_set_flags (DF_RD_PRUNE_DEAD_DEFS); df_analyze (); ... which is excessive. It looks like the above DF stuff does not affects the whole function but only the BBs in the loop. Still the fact that we iterate from inner to outer loops still makes the DF analysis time quadratic in the loop depth. The testcase has only loops of depth 1 (but 2164 ones), so it seems that the DF restriction to a set of BBs does not work as expected? >>From the profile I see that the most time spent in df_analyze is inverted_post_order_compute and post_order_compute (obviosly not region aware!) and then bitmap_set_bit and df_prune_to_subcfg. I wonder if it isn't possible to either update the DF during the transform, deal with partly out-of-date DF info (like process loop siblings without re-calculating DF, and re-compute whole FN DF after such iteration).