https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64036 --- Comment #5 from Kazumoto Kojima --- (In reply to Oleg Endo from comment #3) > else if (flag_exceptions) > { > if (flag_schedule_insns && global_options_set.x_flag_schedule_insns) > warning (0, "ignoring -fschedule-insns because of exception " > "handling bug"); > flag_schedule_insns = 0; > } > > ... which makes it impossible to enable sched1 for C++ code unless > exceptions are disabled. Kaz, do you know whether this is still an issue? I think that the original issue is solved already and we simply forgot this workaround. >From gcc-bugs-return-491683-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jul 07 21:07:04 2015 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 4337 invoked by alias); 7 Jul 2015 21:07:03 -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 4278 invoked by uid 48); 7 Jul 2015 21:06:59 -0000 From: "su at cs dot ucdavis.edu" To: gcc-bugs@gcc.gnu.org Subject: [Bug ipa/66793] New: ICE at -Os and above on x86_64-linux-gnu (verify_flow_info failed) Date: Tue, 07 Jul 2015 21:07:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: ipa X-Bugzilla-Version: 6.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: su at cs dot ucdavis.edu X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: 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 target_milestone 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: 2015-07/txt/msg00573.txt.bz2 Content-length: 2181 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66793 Bug ID: 66793 Summary: ICE at -Os and above on x86_64-linux-gnu (verify_flow_info failed) Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: su at cs dot ucdavis.edu Target Milestone: --- The following code causes an ICE when compiled with the current gcc trunk at -Os and above on x86_64-linux-gnu in both 32-bit and 64-bit modes. It is a regression from 5.1.x. $ gcc-trunk -v Using built-in specs. COLLECT_GCC=gcc-trunk COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/6.0.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk --enable-languages=c,c++ --disable-werror --enable-multilib Thread model: posix gcc version 6.0.0 20150707 (experimental) [trunk revision 225501] (GCC) $ $ gcc-trunk -O1 small.c $ gcc-5.1 -Os small.c $ $ gcc-trunk -Os small.c small.c: In function ‘main’: small.c:18:1: error: control flow in the middle of basic block 2 main () ^ small.c:18:1: internal compiler error: verify_flow_info failed 0x6fa932 verify_flow_info() ../../gcc-trunk/gcc/cfghooks.c:268 0xbfac91 cleanup_tree_cfg_noloop ../../gcc-trunk/gcc/tree-cfgcleanup.c:751 0xbfac91 cleanup_tree_cfg() ../../gcc-trunk/gcc/tree-cfgcleanup.c:800 0xaeeb84 execute_function_todo ../../gcc-trunk/gcc/passes.c:1910 0xaef433 execute_todo ../../gcc-trunk/gcc/passes.c:2014 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See for instructions. $ ----------------------------------- int a, b, c; struct S0 { int f1; } *d; void fn1 (struct S0 p) { for (p.f1 = 0; p.f1 < 1; p.f1++) c = a && b ? a && b : 1; for (; c;) ; } int main () { struct S0 **f = &d; d = 0; fn1 (**f); return 0; } >From gcc-bugs-return-491684-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jul 07 21:13:24 2015 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 66335 invoked by alias); 7 Jul 2015 21:13:23 -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 66013 invoked by uid 48); 7 Jul 2015 21:13:19 -0000 From: "pault at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/52846] [F2008] Support submodules Date: Tue, 07 Jul 2015 21:13: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.8.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: pault at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: pault at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created 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: 2015-07/txt/msg00574.txt.bz2 Content-length: 2621 https://gcc.gnu.org/bugzilla/show_bug.cgi?idR846 --- Comment #7 from Paul Thomas --- Created attachment 35926 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id5926&actioníit A partially cooked patch to complete the implentation of submodules The attached is a first attempt to complete the submodule implementation such that private entities are correctly dealt with. There are two parts to the patch: (i) Modifications to the front end to write a second half to the module files, which contains all the information about the private entities in the module. This is the bulk of the patch; and (ii) A change in the way that declarations of private entities are handled in trans-decl.c. This follows a suggestion from Richard Biener to use a technique borrowed from g++. In this patch it is only applied to variables. Concerning (i), I am open to opinions as to whether or not it is better to write the private parts to a separate file. At present, anything other than a submodule does not visit the private part of the module file. Mention was made on the list of encrypting this part of the file. Unfortunately, this overwhelms the compression and module files remain rather large. This might be a strong argument for emitting two files; one for the public part, as at present, and the other for the private. In this way, a build could result in a library that is only propagated with the public module file. In respect of (ii), I have checked that the map shows no signs of the private variables and that the library only carries their names. A typical, basic makefile might look like this: # Build submodule_8 # submodule_8 : submodule_8_prog.o submodule_8_lib.so ~/irun/bin/gfortran -O3 submodule_8_prog.o submodule_8_lib.so -o submodule_8 # submodule_8_prog.o : submodule_8_prog.f90 ~/irun/bin/gfortran -O3 -c submodule_8_prog.f90 -o submodule_8_prog.o # submodule_8_lib.so : submodule_8_lib1.o submodule_8_lib2.o ~/irun/bin/gfortran -O3 -shared submodule_8_lib1.o submodule_8_lib2.o -o submodule_8_lib.so # # Relocation runs into problems without -fPIC for both of these compilations. # submodule_8_lib1.o : submodule_8_lib1.f90 ~/irun/bin/gfortran -O3 -fPIC -c submodule_8_lib1.f90 -o submodule_8_lib1.o # submodule_8_lib2.o : submodule_8_lib2.f90 ~/irun/bin/gfortran -O3 -fPIC -c submodule_8_lib2.f90 -o submodule_8_lib2.o In this tested case, ~lib1 contains two modules and ~lib2 the submodules. Some of the entities in ~lib1 are private but they are correctly propagated to ~lib2 but not to the program, ~prog. Cheers Paul