[Bug target/64036] [SH] Evaluate re-enabling scheduling before RA

["kkojima at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 9126 bytes --]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64036

--- Comment #5 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(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: <gcc-bugs-return-491683-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
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: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
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" <gcc-bugzilla@gcc.gnu.org>
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: <bug-66793-4@http.gcc.gnu.org/bugzilla/>
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 <http://gcc.gnu.org/bugs.html> 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: <gcc-bugs-return-491684-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
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: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
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" <gcc-bugzilla@gcc.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: <bug-52846-4-QrSfhSp6gz@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-52846-4@http.gcc.gnu.org/bugzilla/>
References: <bug-52846-4@http.gcc.gnu.org/bugzilla/>
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 <pault at gcc dot gnu.org> ---
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