[Bug ada/64492] New: Disabling libada prevents building gnattools-cross

[Bug ada/64492] New: Disabling libada prevents building gnattools-cross

[simon at pushface dot org]

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

            Bug ID: 64492
           Summary: Disabling libada prevents building gnattools-cross
           Product: gcc
           Version: 4.9.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: ada
          Assignee: unassigned at gcc dot gnu.org
          Reporter: simon at pushface dot org

Created attachment 34375
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34375&action=edit
Patch to add --enable-cross-gnattools

This is related to PR19959.

--disable-libada is necessary for targets (such as arm-eabi) where the RTS
isn’t distributed as part of GCC. Of course, you still need the cross gnattools
(such as arm-eabi-gnatls).

Unfortunately you can’t build the cross gnattools, because --disable-libada
adds gnattools to the list  of unconfigured directories, which means that the
directory gcc/ada/tools is never created, let alone populated.
gcc/ada/gcc-interface/Makefile.in touches stamp-tools, but that’s all.

You can’t say "make -C gcc gnattools-cross", because that’s in gnattools/. You
can’t say “make -C gcc cross-gnattools”, because the gcc/ada/tools directory
doesn’t exist.

Why does gcc/ada/gcc-interface/Makefile.in touch ../stamp-tools?
Where does the target cross-gnattools come into the picture?

I attach a patch to the top-level configure.ac which adds a new switch
--enable-cross-gnattools.

If you configure with --disable-libada, gnattools is removed from the list of
configured directories unless
* you give --enable-cross-gnattools
* and you are building a cross compiler
* and the target vendor is “none” or “unknown”.

With this patch, the normal configure/make runs through and builds the cross
gnattools without further ado. Tested on 4.9.1, --target=arm-eabi. The patch
applies to the gcc-5-20141228 snapshot with a 17-line offset.
>From gcc-bugs-return-472191-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Jan 04 22:49:40 2015
Return-Path: <gcc-bugs-return-472191-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 13795 invoked by alias); 4 Jan 2015 22:49:37 -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 13768 invoked by uid 48); 4 Jan 2015 22:49:31 -0000
From: "simon at pushface dot org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug ada/64492] Disabling libada prevents building gnattools-cross
Date: Sun, 04 Jan 2015 22:49:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: ada
X-Bugzilla-Version: 4.9.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: simon at pushface dot org
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: cf_gcctarget cf_gcchost cf_gccbuild
Message-ID: <bug-64492-4-EzYzcXhkpB@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64492-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64492-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-01/txt/msg00185.txt.bz2
Content-length: 648

https://gcc.gnu.org/bugzilla/show_bug.cgi?idd492

simon at pushface dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |arm-eabi
               Host|                            |x86_64-apple-darwin13
              Build|                            |x86_64-apple-darwin13

--- Comment #1 from simon at pushface dot org ---
Notes:

The patch was originated by Luke A. Guest.

I have built GCC 5 snapshot 20141228 as host and cross with this patch and used
the result to build an Ada RTS for STM32F4.

[Bug ada/64492] Disabling libada prevents building gnattools-cross

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
                 CC|                            |ebotcazou at gcc dot gnu.org
         Resolution|---                         |WORKSFORME

--- Comment #3 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
If you configure with --disable-libada, you should be able to build the tools
with "make -C gcc cross-gnattools" after manually building the RTS and touching
gcc/ada/stamp-gnatlib-rts.

[Bug ada/64492] Disabling libada prevents building gnattools-cross

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
   Last reconfirmed|                            |2015-01-05
         Resolution|WORKSFORME                  |---
     Ever confirmed|0                           |1

--- Comment #4 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
Correction: some bits were incorrectly removed from gcc-interface/Makefile.in.

[Bug ada/64492] Disabling libada prevents building gnattools-cross

[simon at pushface dot org]

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

--- Comment #5 from simon at pushface dot org ---
(In reply to Luke A. Guest from comment #2)
> But, I noticed this in the gnat makefile a while back and was going to
> investigate, but haven't got around to it yet:
> 
> # *-elf, *-eabi, or *-eabispe
> ifeq ($(strip $(filter-out elf eabi eabispe,$(target_os))),)
>   TOOLS_TARGET_PAIRS=\
>   mlib-tgt-specific.adb<mlib-tgt-specific-xi.adb \
>   indepsw.adb<indepsw-gnu.adb
> endif
> 
> Essentially, we just need for that to include a specific system or build
> with just those two files and it's sorted.

I agree that, for some reason, this tools target pair is not actioned for
target arm-eabi. Perhaps there should be another PR?

The effect is that arm-eabi-gnatmake is unable to build libraries on this
platform. However, gprbuild is OK. I always use gprbuild when building
libraries because it does a much better job, and is necessary when building
Darwin dylibs.

I understand (can’t remember where from) that AdaCore intend to remove the
ability of gnatmake to build libraries for any target in future releases. If
this is true, I think it would be regrettable, since gprbuild isn’t part of GCC
(it does have copyright assignment to FSF, though). GCC 5 is still OK.
>From gcc-bugs-return-472206-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jan 05 08:54:52 2015
Return-Path: <gcc-bugs-return-472206-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 22826 invoked by alias); 5 Jan 2015 08:54:52 -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 22809 invoked by uid 89); 5 Jan 2015 08:54:51 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2
X-Spam-User: qpsmtpd, 2 recipients
X-HELO: smtp.eu.adacore.com
Received: from mel.act-europe.fr (HELO smtp.eu.adacore.com) (194.98.77.210) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 05 Jan 2015 08:54:50 +0000
Received: from localhost (localhost [127.0.0.1])	by filtered-smtp.eu.adacore.com (Postfix) with ESMTP id 179FC2C229CF;	Mon,  5 Jan 2015 09:54:47 +0100 (CET)
Received: from smtp.eu.adacore.com ([127.0.0.1])	by localhost (smtp.eu.adacore.com [127.0.0.1]) (amavisd-new, port 10024)	with ESMTP id As9VPT6tc3EP; Mon,  5 Jan 2015 09:54:47 +0100 (CET)
Received: from chelles.act-europe.fr (chelles.act-europe.fr [10.10.0.160])	by smtp.eu.adacore.com (Postfix) with ESMTP id 05E172C229A3;	Mon,  5 Jan 2015 09:54:47 +0100 (CET)
Received: by chelles.act-europe.fr (Postfix, from userid 525)	id F328E1EA034F; Mon,  5 Jan 2015 09:54:46 +0100 (CET)
Date: Mon, 05 Jan 2015 08:54:00 -0000
From: Arnaud Charlet <charlet@adacore.com>
To: simon at pushface dot org <gcc-bugzilla@gcc.gnu.org>
Cc: gcc-bugs@gcc.gnu.org
Subject: Re: [Bug ada/64492] New: Disabling libada prevents building gnattools-cross
Message-ID: <20150105085446.GA24183@adacore.com>
References: <bug-64492-4@http.gcc.gnu.org/bugzilla/>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <bug-64492-4@http.gcc.gnu.org/bugzilla/>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-SW-Source: 2015-01/txt/msg00200.txt.bz2
Content-length: 448

> Unfortunately you can???t build the cross gnattools, because
> --disable-libada
> adds gnattools to the list  of unconfigured directories, which means that
> the
> directory gcc/ada/tools is never created, let alone populated.
> gcc/ada/gcc-interface/Makefile.in touches stamp-tools, but that???s
> all.

You can actually. The way to build gnattools when using --disable-libada is
to do:

  obj $ make -C gcc cross-gnattools ada.all.cross

Arno

[Bug ada/64492] Disabling libada prevents building gnattools-cross

[simon at pushface dot org]

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

--- Comment #6 from simon at pushface dot org ---
(In reply to Eric Botcazou from comment #4)
> Correction: some bits were incorrectly removed from
> gcc-interface/Makefile.in.

Do you mean the parts where the creation and population of gcc/ada/tools has
been migrated to gnattools/Makefile?

[Bug ada/64492] Disabling libada prevents building gnattools-cross

[charlet at adacore dot com]

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

--- Comment #7 from charlet at adacore dot com <charlet at adacore dot com> ---
> Unfortunately you can???t build the cross gnattools, because
> --disable-libada
> adds gnattools to the list  of unconfigured directories, which means that
> the
> directory gcc/ada/tools is never created, let alone populated.
> gcc/ada/gcc-interface/Makefile.in touches stamp-tools, but that???s
> all.

You can actually. The way to build gnattools when using --disable-libada is
to do:

  obj $ make -C gcc cross-gnattools ada.all.cross

Arno

[Bug ada/64492] Disabling libada prevents building gnattools-cross

[ebotcazou at gcc dot gnu.org]

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

--- Comment #8 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
Author: ebotcazou
Date: Mon Jan  5 10:17:12 2015
New Revision: 219183

URL: https://gcc.gnu.org/viewcvs?rev=219183&root=gcc&view=rev
Log:
    PR ada/64492
    * gcc-interface/Makefile.in (../stamp-tools): Reinstate dropped code.

Modified:
    trunk/gcc/ada/ChangeLog
    trunk/gcc/ada/gcc-interface/Makefile.in

[Bug ada/64492] Disabling libada prevents building gnattools-cross

[ebotcazou at gcc dot gnu.org]

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

--- Comment #9 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
Author: ebotcazou
Date: Mon Jan  5 10:17:28 2015
New Revision: 219184

URL: https://gcc.gnu.org/viewcvs?rev=219184&root=gcc&view=rev
Log:
    PR ada/64492
    * gcc-interface/Makefile.in (../stamp-tools): Reinstate dropped code

Modified:
    branches/gcc-4_9-branch/gcc/ada/ChangeLog
    branches/gcc-4_9-branch/gcc/ada/gcc-interface/Makefile.in

[Bug ada/64492] Disabling libada prevents building gnattools-cross

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
            Version|4.9.1                       |4.9.3
         Resolution|---                         |FIXED

--- Comment #10 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
This should work with Arno's incantation now.

[Bug ada/64492] Disabling libada prevents building gnattools-cross

[laguest at archeia dot com]

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

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

--- Comment #11 from Luke A. Guest <laguest at archeia dot com> ---
(In reply to simon from comment #5)
> (In reply to Luke A. Guest from comment #2)
> > But, I noticed this in the gnat makefile a while back and was going to
> > investigate, but haven't got around to it yet:
> > 
> > # *-elf, *-eabi, or *-eabispe
> > ifeq ($(strip $(filter-out elf eabi eabispe,$(target_os))),)
> >   TOOLS_TARGET_PAIRS=\
> >   mlib-tgt-specific.adb<mlib-tgt-specific-xi.adb \
> >   indepsw.adb<indepsw-gnu.adb
> > endif
> > 
> > Essentially, we just need for that to include a specific system or build
> > with just those two files and it's sorted.
> 
> I agree that, for some reason, this tools target pair is not actioned for
> target arm-eabi. Perhaps there should be another PR?
> 

No, in my patch above, you only have part of the patch, the second part adds
the necessary lines in the gnattools/configure script to enable them correctly
including lib support. Without that it shouldn't even build but if it does by
some miracle it will use defaults which are very basic.

> The effect is that arm-eabi-gnatmake is unable to build libraries on this
> platform. However, gprbuild is OK. I always use gprbuild when building
> libraries because it does a much better job, and is necessary when building
> Darwin dylibs.
> 
> I understand (can’t remember where from) that AdaCore intend to remove the
> ability of gnatmake to build libraries for any target in future releases. If
> this is true, I think it would be regrettable, since gprbuild isn’t part of
> GCC (it does have copyright assignment to FSF, though). GCC 5 is still OK.

Well that's a stupid idea,
>From gcc-bugs-return-472228-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jan 05 11:16:37 2015
Return-Path: <gcc-bugs-return-472228-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 24995 invoked by alias); 5 Jan 2015 11:16:37 -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 24942 invoked by uid 48); 5 Jan 2015 11:16:34 -0000
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/64465] [5 Regression] internal compiler error: verify_flow_info failed
Date: Mon, 05 Jan 2015 11:16: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: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: attachments.created
Message-ID: <bug-64465-4-f3Oou91dAh@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64465-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64465-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-01/txt/msg00222.txt.bz2
Content-length: 308

https://gcc.gnu.org/bugzilla/show_bug.cgi?idd465

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 34377
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id4377&actioníit
non-working patch (at least contains reduced testcase)

For some reason this doesn't work :(.

[Bug ada/64492] Disabling libada prevents building gnattools-cross

[simon at pushface dot org]

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

--- Comment #12 from simon at pushface dot org ---
(In reply to Eric Botcazou from comment #10)
> This should work with Arno's incantation now.

Confirmed. Thanks.

I have to say, though, that configuring with --disable-libada
--enable-cross-gnattools means you can just “make; make install” without any
need for incantations!
>From gcc-bugs-return-472238-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jan 05 14:06:24 2015
Return-Path: <gcc-bugs-return-472238-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 11851 invoked by alias); 5 Jan 2015 14:06:24 -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 11795 invoked by uid 48); 5 Jan 2015 14:06:19 -0000
From: "john.donners at surfsara dot nl" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/63922] Compiler error with OpenMP, default(none) and an integer parameter array
Date: Mon, 05 Jan 2015 14:06: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.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: john.donners at surfsara dot nl
X-Bugzilla-Status: RESOLVED
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_status resolution
Message-ID: <bug-63922-4-1ncyIvSWr9@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63922-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63922-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-01/txt/msg00232.txt.bz2
Content-length: 470

https://gcc.gnu.org/bugzilla/show_bug.cgi?idc922

John Donners <john.donners at surfsara dot nl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|---                         |FIXED

--- Comment #2 from John Donners <john.donners at surfsara dot nl> ---
I can confirm that this is solved in 4.9.2

[Bug ada/64492] Disabling libada prevents building gnattools-cross

[simon at pushface dot org]

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

--- Comment #13 from simon at pushface dot org ---
(In reply to Luke A. Guest from comment #2)
> But, I noticed this in the gnat makefile a while back and was going to
> investigate, but haven't got around to it yet:
> 
> # *-elf, *-eabi, or *-eabispe
> ifeq ($(strip $(filter-out elf eabi eabispe,$(target_os))),)
>   TOOLS_TARGET_PAIRS=\
>   mlib-tgt-specific.adb<mlib-tgt-specific-xi.adb \
>   indepsw.adb<indepsw-gnu.adb
> endif
> 
> Essentially, we just need for that to include a specific system or build
> with just those two files and it's sorted.

TOOLS_TARGET_PAIRS is set in both gnattools/Makefile (when it has been
configured) and gcc/ada/gcc-interface/Makefile.in. Your patch is to the
gnattools/ one, the gcc-interface one already has this pair.

If it is the case that any arm-*-eabi target is going to be a bare runtime
target, with --disable-libada disabling gnattools/, then Eric’s patch and
Arno’s incantation will IMO work - I just built GCC 5 arm-eabi with Eric’s
patch and the two files were successfully copied into build/gcc/ada/tools, and
arm-eabi-gnatmake is capable of building a library. Haven’t checked the map
feature yet.

Looking at the two versions of TOOLS_TARGET_PAIRS, it seems that
gcc-interface/Makefile is mainly concerned with building the RTS
(LIBGNAT_TARGET_PAIRS etc) with the TOOLS_TARGET_PAIRS being left in place,
pretty much as fossils, when building the tools was moved to
gnattools/Makefile.
>From gcc-bugs-return-472243-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jan 05 14:35:41 2015
Return-Path: <gcc-bugs-return-472243-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 30680 invoked by alias); 5 Jan 2015 14:35:40 -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 30640 invoked by uid 55); 5 Jan 2015 14:35:36 -0000
From: "hubicka at ucw dot cz" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug ipa/64472] FAIL: gcc.dg/ipa/inline-7.c
Date: Mon, 05 Jan 2015 14:35:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: ipa
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: hubicka at ucw dot cz
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: <bug-64472-4-ZIOlnHZSbY@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64472-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64472-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-01/txt/msg00237.txt.bz2
Content-length: 230

https://gcc.gnu.org/bugzilla/show_bug.cgi?idd472

--- Comment #4 from Jan Hubicka <hubicka at ucw dot cz> ---
I think marking it inline is best fix: with static the inliner may get smart
rnough to consider it used once.

Honza

[Bug ada/64492] Disabling libada prevents building gnattools-cross

[laguest at archeia dot com]

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

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

--- Comment #14 from Luke A. Guest <laguest at archeia dot com> ---
(In reply to simon from comment #13)

> TOOLS_TARGET_PAIRS is set in both gnattools/Makefile (when it has been
> configured) and gcc/ada/gcc-interface/Makefile.in. Your patch is to the
> gnattools/ one, the gcc-interface one already has this pair.

Yup, as with the patches that we've wrangling with for the past 15 years (yes,
that long) that has been the case, although I don't know when it all got split
up into libada and gnattools dirs. But, the gnattool/configure case was moved
there from the gcc-interface/Makefile.in, I always thought that they just
forgot to remove the one from there. 

> If it is the case that any arm-*-eabi target is going to be a bare runtime

If any *-elf/eabi-elf/coff/whatever target is going to be bare runtime...

When I first started looking into this I was interested in ARM, not so much
now. But maybe in the future.

> target, with --disable-libada disabling gnattools/, then Eric’s patch and
> Arno’s incantation will IMO work - I just built GCC 5 arm-eabi with Eric’s
> patch and the two files were successfully copied into build/gcc/ada/tools,
> and arm-eabi-gnatmake is capable of building a library. Haven’t checked the

Interesting.

> map feature yet.

The what?

> Looking at the two versions of TOOLS_TARGET_PAIRS, it seems that
> gcc-interface/Makefile is mainly concerned with building the RTS
> (LIBGNAT_TARGET_PAIRS etc) with the TOOLS_TARGET_PAIRS being left in place,
> pretty much as fossils, when building the tools was moved to
> gnattools/Makefile.

Would be nice if this was documented in an easy to understand way in the
makefiles, as in "What it's there for and why."

As I state above, I have been dabbling on and off for 14 years for this. I have
posted about it in various places and only got the response of the incantation,
which I told them never worked, shame it's taken this long to get this quite
major issue fixed.
>From gcc-bugs-return-472265-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jan 05 18:42:30 2015
Return-Path: <gcc-bugs-return-472265-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 30273 invoked by alias); 5 Jan 2015 18:42:30 -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 30248 invoked by uid 48); 5 Jan 2015 18:42:24 -0000
From: "johnstonj@inn-soft.com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug pch/64502] New: Incorrect warning about empty translation units when using pre-compiled headers
Date: Mon, 05 Jan 2015 18:42:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: pch
X-Bugzilla-Version: 4.9.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: johnstonj@inn-soft.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 attachments.created
Message-ID: <bug-64502-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-01/txt/msg00259.txt.bz2
Content-length: 4648

https://gcc.gnu.org/bugzilla/show_bug.cgi?idd502

            Bug ID: 64502
           Summary: Incorrect warning about empty translation units when
                    using pre-compiled headers
           Product: gcc
           Version: 4.9.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: pch
          Assignee: unassigned at gcc dot gnu.org
          Reporter: johnstonj@inn-soft.com

Created attachment 34380
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id4380&actioníit
GCC intermediate output of MyProgram.c with GCH

When using a pre-compiled header that contains C code, GCC will complain anyway
that the translation unit is empty - even when it is obviously not.  It appears
that the warning does not consider code that is inside the translation unit.

The test case below is rather contrived to create a minimal test case.
(Obviously, we aren't putting "int main" in the pre-compiled header!)  However,
in the real world, we use GCC to compile the same source code for several
different platforms.  The pre-compiled header always contains code (e.g. some
typedefs used by all platforms), but the C file itself may exclude all code via
"#if PLATFORM..." if it is not applicable to the current platform.

Steps to reproduce:

1.  Create the following two files - Hello.h and MyProgram.c:

// Hello.h:
// NOTE:  In the real world, we wouldn't be putting "int main" in the
// header, of course.  Instead, there might be some typedefs here that
// aren't used, for example.
int main(void) {
    return 0;
}

// =======================================
// MyProgram.c
#include "Hello.h"
// NOTE:  In the real world, we would be excluding platform-specific code
// by using "#ifdef PLATFORM...." around the entire body of code in this
// C file.

2.  Now, compile it:

$ gcc -pedantic Hello.h -save-temps
$ gcc -pedantic MyProgram.c -o MyProgram -save-temps
MyProgram.c:1:0: warning: ISO C forbids an empty translation unit [-Wpedantic]
 #include "Hello.h"
 ^

3.  As illustrated above, GCC is wrongly complaining that the translation unit
is empty.  It is, in fact, not empty - the code is in the pre-compiled
header...

4.  Removing the pre-compiled header silences the warning:

$ rm Hello.h.gch
$ gcc -pedantic MyProgram.c -o MyProgram -save-temps

The problem is reproduced on both Cygwin 32-bit GCC 4.9.2, and on avr-gcc
distributed by Atmel, version 4.7.2.

Output of gcc -v for the Cygwin version:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-pc-cygwin/4.9.2/lto-wrapper.exe
Target: i686-pc-cygwin
Configured with:
/cygdrive/i/szsz/tmpp/gcc/gcc-4.9.2-1.i686/src/gcc-4.9.2/configure
--srcdir=/cygdrive/i/szsz/tmpp/gcc/gcc-4.9.2-1.i686/src/gcc-4.9.2 --prefix=/usr
--exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin
--libexecdir=/usr/libexec --datadir=/usr/share --localstatedir=/var
--sysconfdir=/etc --libdir=/usr/lib --datarootdir=/usr/share
--docdir=/usr/share/doc/gcc --htmldir=/usr/share/doc/gcc/html -C
--build=i686-pc-cygwin --host=i686-pc-cygwin --target=i686-pc-cygwin
--without-libiconv-prefix --without-libintl-prefix --libexecdir=/usr/lib
--enable-shared --enable-shared-libgcc --enable-static
--enable-version-specific-runtime-libs --enable-bootstrap --enable-__cxa_atexit
--with-dwarf2 --with-arch=i686 --with-tune=generic --disable-sjlj-exceptions
--enable-languages­a,c,c++,fortran,java,lto,objc,obj-c++ --enable-graphite
--enable-threads=posix --enable-libatomic --enable-libgomp --disable-libitm
--enable-libquadmath --enable-libquadmath-support --enable-libssp
--enable-libada --enable-libjava --enable-libgcj-sublibs --disable-java-awt
--disable-symvers --with-ecj-jar=/usr/share/java/ecj.jar --with-gnu-ld
--with-gnu-as --with-cloog-include=/usr/include/cloog-isl
--without-libiconv-prefix --without-libintl-prefix --with-system-zlib
--enable-linker-build-id
Thread model: posix
gcc version 4.9.2 (GCC)

Attached are intermediate output files saved with "-save-temps" for cases both
with and without pre-compiled headers.  My conclusion is that this warning only
considers the code in "MyProgram.i" and ignores what code might be included via
the proprietary "#pragma GCC pch_preprocess "Hello.h.gch"" that is apparently
an implementation detail of pre-compiled headers.  Obviously, this doesn't
really relate to C99 grammar, which doesn't even consider pre-compiled headers.

One idea for fixing the problem might be a flag saved in the GCH file
indicating whether the file contained any real code, or whether it is empty.
The warning would only be raised if the C file AND the GCH file are both empty.