[Bug target/57792] fixincludes doesn't honor the use of --with-sysroot during bootstrap

[Bug target/57792] fixincludes doesn't honor the use of --with-sysroot during bootstrap

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57792

Jack Howarth <howarth at nitro dot med.uc.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|--with-native-system-header |fixincludes doesn't honor
                   |-dir confuses -isysroot     |the use of --with-sysroot
                   |                            |during bootstrap

--- Comment #1 from Jack Howarth <howarth at nitro dot med.uc.edu> ---
The removal of the SDK from / on darwin exposes a defect in fixincludes. The
fixinc.in hardcodes "/usr/include" without any attempt to detect if the
bootstrap has been invoked with the "--with-sysroot" configure option. On
darwin13, one currently has to hack around this defect with...

perl -pi -e 's|/usr/include|`xcrun --show-sdk-path`/usr/include|g'
fixincludes/fixinc.in

before executing…

--prefix=/sw --prefix=/sw/lib/gcc4.8 --mandir=/sw/share/man
--infodir=/sw/lib/gcc4.8/info
--enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw
--with-libiconv-prefix=/sw --with-isl=/sw --with-cloog=/sw --with-mpc=/sw
--with-system-zlib --enable-checking=release --x-includes=/usr/X11R6/include
--x-libraries=/usr/X11R6/lib --program-suffix=-fsf-4.8
--with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX10.9.sdk

This bootstraps normally and produces a compiler with a functional -isysroot
compiler option (i.e. the directory passed to -isysroot is appended to /).

Some mechanism needs to be added to allow the use of --with-sysroot in the
bootstrap to be detected in the fixincludes/fixinc.in shell script and, if
--with-sysroot is in use, the path to the sysroot prefixed to /usr/include at…

# # # # # # # # # # # # # # # # # # # # #
#
#  Search each input directory for broken header files.
#  This loop ends near the end of the file.
#
if test $# -eq 0
then
    INPUTLIST="/usr/include"
else
    INPUTLIST="$@"
fi
>From gcc-bugs-return-425753-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Jul 04 15:25:09 2013
Return-Path: <gcc-bugs-return-425753-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 23178 invoked by alias); 4 Jul 2013 15:25:09 -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 23112 invoked by uid 48); 4 Jul 2013 15:25:03 -0000
From: "amylaar at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/57821] 'array is too large' error is missing when sizetype overflows
Date: Thu, 04 Jul 2013 15:25:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: 4.8.0
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: amylaar at gcc dot gnu.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:
Message-ID: <bug-57821-4-Q6mNYOCwa6@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57821-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57821-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: 2013-07/txt/msg00260.txt.bz2
Content-length: 276

http://gcc.gnu.org/bugzilla/show_bug.cgi?idW821

--- Comment #1 from Jorn Wolfgang Rennecke <amylaar at gcc dot gnu.org> ---
avr faces an additional issue in c/c-typeck:set_init_index, where the
designator value is converted to bitsizetype; that is 24 bit PSImode for
avr.

[Bug target/57792] fixincludes doesn't honor the use of --with-sysroot during bootstrap

[bkorb at gnu dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57792

Bruce Korb <bkorb at gnu dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bonzini at gnu dot org,
                   |                            |ghazi at gcc dot gnu.org

--- Comment #2 from Bruce Korb <bkorb at gnu dot org> ---
Paolo did the config stuff, with Kaveh's help.
However, Jack Howarth may be in a better position to
make a patch since I do not have an Apple development
system.

[Bug target/57792] fixincludes doesn't honor the use of --with-sysroot during bootstrap

[howarth at nitro dot med.uc.edu]

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

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57792

--- Comment #3 from Jack Howarth <howarth at nitro dot med.uc.edu> ---
(In reply to Bruce Korb from comment #2)
> Paolo did the config stuff, with Kaveh's help.
> However, Jack Howarth may be in a better position to
> make a patch since I do not have an Apple development
> system.

I would think that we want some permutation of the following code from
gcc/configure.ac added to fixincludes/configure.ac…

AC_ARG_WITH(sysroot,
[AS_HELP_STRING([[--with-sysroot[=DIR]]],
                [search for usr/lib, usr/include, et al, within DIR])],
[
 case ${with_sysroot} in
 yes) TARGET_SYSTEM_ROOT='${exec_prefix}/${target_noncanonical}/sys-root' ;;
 *) TARGET_SYSTEM_ROOT=$with_sysroot ;;
 esac

 TARGET_SYSTEM_ROOT_DEFINE='-DTARGET_SYSTEM_ROOT=\"$(TARGET_SYSTEM_ROOT)\"'

CROSS_SYSTEM_HEADER_DIR='$(TARGET_SYSTEM_ROOT)$${sysroot_headers_suffix}$(NATIVE_SYSTEM_HEADER_DIR)'

 case ${TARGET_SYSTEM_ROOT} in
 "${test_prefix}"|"${test_prefix}/"*|\
 "${test_exec_prefix}"|"${test_exec_prefix}/"*|\
 '${prefix}'|'${prefix}/'*|\
 '${exec_prefix}'|'${exec_prefix}/'*)
   t="$TARGET_SYSTEM_ROOT_DEFINE -DTARGET_SYSTEM_ROOT_RELOCATABLE"
   TARGET_SYSTEM_ROOT_DEFINE="$t"
   ;;
 esac
], [
 TARGET_SYSTEM_ROOT=
 TARGET_SYSTEM_ROOT_DEFINE=
 CROSS_SYSTEM_HEADER_DIR='$(gcc_tooldir)/sys-include'
])
AC_SUBST(TARGET_SYSTEM_ROOT)
AC_SUBST(TARGET_SYSTEM_ROOT_DEFINE)
AC_SUBST(CROSS_SYSTEM_HEADER_DIR)

as well as associated changes to fixincludes/Makefile.in and
fixincludes/fixinc.in to have TARGET_SYSTEM_ROOT passed to and used by the
generated fixincludes/fixin shell script. I would be happy to test any proposed
fix along those lines (but I am unclear on how complex the additions to
fixincludes/configure.ac need to be to handle cross compiles, etc).
>From gcc-bugs-return-425767-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Jul 04 17:36:32 2013
Return-Path: <gcc-bugs-return-425767-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 6069 invoked by alias); 4 Jul 2013 17:36:31 -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 5998 invoked by uid 48); 4 Jul 2013 17:36:22 -0000
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug preprocessor/57824] Raw string literals not handled correctly in macro arguments or deferred pragmas
Date: Thu, 04 Jul 2013 17:36:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: preprocessor
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords: rejects-valid
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: jakub at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: attachments.created
Message-ID: <bug-57824-4-8viLQRCO42@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57824-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57824-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: 2013-07/txt/msg00274.txt.bz2
Content-length: 425

http://gcc.gnu.org/bugzilla/show_bug.cgi?idW824

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 30459
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id0459&actioníit
gcc49-pr57824.patch

Untested fix.  Seems to work on these testcases without -save-temps, with
-save-temps the line numbers in -lineno dumps are off unfortunately, so some
further work is needed.  Tom, any ideas?

[Bug target/57792] toplevel configure should enable "--with-sysroot="`xcrun --show-sdk-path`"" for darwin13 and later

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57792

Jack Howarth <howarth at nitro dot med.uc.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|fixincludes doesn't honor   |toplevel configure should
                   |the use of --with-sysroot   |enable
                   |during bootstrap            |"--with-sysroot="`xcrun
                   |                            |--show-sdk-path`"" for
                   |                            |darwin13 and later

--- Comment #4 from Jack Howarth <howarth at nitro dot med.uc.edu> ---
Sorry for the noise. The addition of…

--with-sysroot="`xcrun --show-sdk-path`"

in fact does allow fixincludes to find the buried usr/include. I'm not sure
what other option I was passing that prevented that from working before.
   I have switched this PR to an enhancement request for modifying the top
level configure.ac to pass…

--with-sysroot="`xcrun --show-sdk-path`"

for darwin13 or later. I am unclear how this can be done considering that the
top level configure.ac doesn't mention --with-sysroot. However I am sure we
should be passing it down from there to insure that all of the other configure
files get that option set.
>From gcc-bugs-return-425789-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Jul 05 00:37:12 2013
Return-Path: <gcc-bugs-return-425789-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 4382 invoked by alias); 5 Jul 2013 00:37:12 -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 4311 invoked by uid 48); 5 Jul 2013 00:37:02 -0000
From: "howarth at nitro dot med.uc.edu" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/57792] toplevel configure should enable "--with-sysroot="`xcrun --show-sdk-path`"" for darwin13 and later
Date: Fri, 05 Jul 2013 00:37:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: howarth at nitro dot med.uc.edu
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:
Message-ID: <bug-57792-4-O4BrOZWI1O@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57792-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57792-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: 2013-07/txt/msg00296.txt.bz2
Content-length: 2213

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57792

--- Comment #5 from Jack Howarth <howarth at nitro dot med.uc.edu> ---
I am really surprised the following change if insufficient to replace manually 
passing…

--with-sysroot="`xcrun --show-sdk-path`"

to configure on the command line for darwin13...

Index: configure.ac
===================================================================
--- configure.ac        (revision 200683)
+++ configure.ac        (working copy)
@@ -2848,6 +2848,13 @@ if test x${is_cross_compiler} = xyes ; t
   target_configargs="--with-cross-host=${host_noncanonical}
${target_configargs}"
 fi

+case "${target}" in
+  x86_64-*-darwin13*)
+    target_configargs="--with-sysroot=\"`xcrun --show-sdk-path`\" 
${target_configargs}"
+    ;;
+esac
+
+
 # Default to --enable-multilib.
 if test x${enable_multilib} = x ; then
   target_configargs="--enable-multilib ${target_configargs}"
Index: configure
===================================================================
--- configure   (revision 200683)
+++ configure   (working copy)
@@ -7414,6 +7414,13 @@ if test x${is_cross_compiler} = xyes ; t
   target_configargs="--with-cross-host=${host_noncanonical}
${target_configargs}"
 fi

+case "${target}" in
+  x86_64-*-darwin13*)
+    target_configargs="--with-sysroot=\"`xcrun --show-sdk-path`\" 
${target_configargs}"
+    ;;
+esac
+
+
 # Default to --enable-multilib.
 if test x${enable_multilib} = x ; then
   target_configargs="--enable-multilib ${target_configargs}"


This patch (without explicitly passing --with-sysroot to configure) results in
the fixincludes complaining about not finding /usr/include again but the
top-level config.log shows target_configargs has
--with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX10.9.sdk on it.
Should I be appending "--with-sysroot=\"`xcrun --show-sdk-path`\" to different
variable instead?
>From gcc-bugs-return-425790-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Jul 05 01:25:20 2013
Return-Path: <gcc-bugs-return-425790-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 31296 invoked by alias); 5 Jul 2013 01:25:20 -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 31214 invoked by uid 48); 5 Jul 2013 01:25:16 -0000
From: "howarth at nitro dot med.uc.edu" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/57792] toplevel configure should enable "--with-sysroot="`xcrun --show-sdk-path`"" for darwin13 and later
Date: Fri, 05 Jul 2013 01:25:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: howarth at nitro dot med.uc.edu
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:
Message-ID: <bug-57792-4-Jard5eC50Y@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57792-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57792-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: 2013-07/txt/msg00297.txt.bz2
Content-length: 940

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57792

--- Comment #6 from Jack Howarth <howarth at nitro dot med.uc.edu> ---
(In reply to Jack Howarth from comment #5)

The same change of adding --with-sysroot=\"`xcrun --show-sdk-path`\" to
build_configargs also fails when fix_includes tries to find /usr/include.
Strangely, adding --with-sysroot=\"`xcrun --show-sdk-path`\" to host_configargs
allows fixincludes to find the headers but then dies in stage2 with the cryptic
error…

Configuring stage 2 in ./intl
Configuring stage 2 in ./libiberty
Configuring stage 2 in ./libbacktrace
Configuring stage 2 in ./libdecnumber
make[4]: Nothing to be done for `all'.
make[3]: Nothing to be done for `all'.
configure: loading cache ../config.cache
configure: loading cache ../config.cache
configure: loading cache ../config.cache
configure: loading cache ../config.cache
configure: error: `CC' has changed since the previous run:
>From gcc-bugs-return-425791-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Jul 05 01:39:01 2013
Return-Path: <gcc-bugs-return-425791-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 4052 invoked by alias); 5 Jul 2013 01:39:01 -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 4019 invoked by uid 48); 5 Jul 2013 01:38:56 -0000
From: "liweifriends at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/57827] New: compiler segmentation fault
Date: Fri, 05 Jul 2013 01:39:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.8.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: liweifriends 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: <bug-57827-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: 2013-07/txt/msg00298.txt.bz2
Content-length: 768

http://gcc.gnu.org/bugzilla/show_bug.cgi?idW827

            Bug ID: 57827
           Summary: compiler segmentation fault
           Product: gcc
           Version: 4.8.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: liweifriends at gmail dot com

When build the following code with GCC 4.8.1:

struct C
{
    constexpr int fun (int x)
    {
        return x + 1;
    }

    int a = 2;
    int b = fun(a);
};

C c;

int main() {}

GCC told me :

internal compiler error : segmentation fault.

In my opinion, it should present more meaningful result, such as the non-static
function 'fun' cannot be used in inline initialization ...

[Bug target/57792] toplevel configure should enable "--with-sysroot="`xcrun --show-sdk-path`"" for darwin13 and later

[howarth at nitro dot med.uc.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57792

--- Comment #7 from Jack Howarth <howarth at nitro dot med.uc.edu> ---
(In reply to Jack Howarth from comment #6)
My mistake in mixing host_configargs and build_configargs. The following patch
works fine…

Index: configure.ac
===================================================================
--- configure.ac        (revision 200683)
+++ configure.ac        (working copy)
@@ -2848,6 +2848,13 @@ if test x${is_cross_compiler} = xyes ; t
   target_configargs="--with-cross-host=${host_noncanonical}
${target_configargs}"
 fi

+# Pass --with-sysroot on darwin without SDK in /
+case "${target}" in
+  x86_64-*-darwin1[[3-9]]*)
+    host_configargs="--with-sysroot=\"`xcrun --show-sdk-path`\" 
${host_configargs}"
+    ;;
+esac
+
 # Default to --enable-multilib.
 if test x${enable_multilib} = x ; then
   target_configargs="--enable-multilib ${target_configargs}"
>From gcc-bugs-return-425793-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Jul 05 06:36:08 2013
Return-Path: <gcc-bugs-return-425793-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 27427 invoked by alias); 5 Jul 2013 06:36:08 -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 27342 invoked by uid 55); 5 Jul 2013 06:35:56 -0000
From: "neleai at seznam dot cz" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/29776] result of ffs/clz/ctz/popcount/parity are already sign-extended
Date: Fri, 05 Jul 2013 06:36:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.3.0
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: neleai at seznam 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-29776-4-jmH31ySnfb@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-29776-4@http.gcc.gnu.org/bugzilla/>
References: <bug-29776-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: 2013-07/txt/msg00300.txt.bz2
Content-length: 1491

http://gcc.gnu.org/bugzilla/show_bug.cgi?id)776

--- Comment #15 from Ondrej Bilka <neleai at seznam dot cz> ---
On Thu, Jul 04, 2013 at 07:46:07PM +0000, glisse at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id)776
>
> --- Comment #14 from Marc Glisse <glisse at gcc dot gnu.org> ---
> (In reply to Jakub Jelinek from comment #12)
> > Not all CPUs that have defined behavior for 0 define it to the precision
> > though, and even on i?86 it is undefined even when using lzcnt/tzcnt on
> > older CPUs.
> > Even the libgcc routines provide various return values for 0 depending on
> > target (look for COUNT_LEADING_ZEROS_0).
> > So it is not an option to redefine the builtins, they are undefined behavior
> > for 0 and that can't change.
>
> I didn't mean to document the value for 0 or have other optimizations create
> calls to this builtin relying on this property. I just meant that if we already
> have a call to clz and the argument happens to be 0 (which is undefined), we
> could optimize based on the assumption that the result is the precision, that
> may break less code than your current patch. Otherwise we might as well assert
> (well, tell it to VRP) that the argument is non-zero.
>
> But you are probably right that trying to work around the undefined value for 0
> is wrong, another builtin should be used instead.
>
Wait, when user triggers undefined behaviour anything is possible. So we
can change return value and be still correct, rigth?

[Bug target/57792] toplevel configure should enable "--with-sysroot="`xcrun --show-sdk-path`"" for darwin13 and later

[mrs at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57792

mrs at gcc dot gnu.org <mrs at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
            Version|unknown                     |4.8.0
         Resolution|---                         |FIXED

--- Comment #8 from mrs at gcc dot gnu.org <mrs at gcc dot gnu.org> ---
Fixed.

[Bug target/57792] toplevel configure should enable "--with-sysroot="`xcrun --show-sdk-path`"" for darwin13 and later

[htl10 at users dot sourceforge.net]

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

Hin-Tak Leung <htl10 at users dot sourceforge.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |htl10 at users dot sourceforge.net

--- Comment #9 from Hin-Tak Leung <htl10 at users dot sourceforge.net> ---
Did the change make it into 4.9.2? I recently tried that
and found that I need the explicit --sysroot:
https://gcc.gnu.org/ml/gcc-testresults/2014-11/msg00268.html

Otherwise it fails during the stage1-fixincludes stage.
(luckily I saw the tips and reference to this bug report
in the older buildstat).

[Bug target/57792] toplevel configure should enable "--with-sysroot="`xcrun --show-sdk-path`"" for darwin13 and later

[howarth at bromo dot med.uc.edu]

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

howarth at bromo dot med.uc.edu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |howarth at bromo dot med.uc.edu

--- Comment #10 from howarth at bromo dot med.uc.edu ---
(In reply to Hin-Tak Leung from comment #9)
> Did the change make it into 4.9.2? I recently tried that
> and found that I need the explicit --sysroot:
> https://gcc.gnu.org/ml/gcc-testresults/2014-11/msg00268.html
> 
> Otherwise it fails during the stage1-fixincludes stage.
> (luckily I saw the tips and reference to this bug report
> in the older buildstat).

This change was reverted when Apple abandoned the idea of removing the
/usr/include. They didn't appreciate the number of packages (like python) which
would require the changes to also find the new location of the /usr/include.

[Bug target/57792] toplevel configure should enable "--with-sysroot="`xcrun --show-sdk-path`"" for darwin13 and later

[howarth at bromo dot med.uc.edu]

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

--- Comment #11 from howarth at bromo dot med.uc.edu ---
(In reply to Hin-Tak Leung from comment #9)
> Did the change make it into 4.9.2? I recently tried that
> and found that I need the explicit --sysroot:
> https://gcc.gnu.org/ml/gcc-testresults/2014-11/msg00268.html
> 

Also, if you can't find /usr/include on OS X, that means you need to install
the Command Line Tools with 'xcode-select --install'.

[Bug target/57792] toplevel configure should enable "--with-sysroot="`xcrun --show-sdk-path`"" for darwin13 and later

[htl10 at users dot sourceforge.net]

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

--- Comment #12 from Hin-Tak Leung <htl10 at users dot sourceforge.net> ---
(In reply to howarth from comment #10)
> This change was reverted when Apple abandoned the idea of removing the
> /usr/include. They didn't appreciate the number of packages (like python)
> which would require the changes to also find the new location of the
> /usr/include.

(In reply to howarth from comment #11)
> Also, if you can't find /usr/include on OS X, that means you need to install
> the Command Line Tools with 'xcode-select --install'.

Have Apple really abandoned the idea of removing /usr/include ? xcode 6.1 ships
all the headers under the SDK places; indeed as you said, running 'xcode-select
--install' prompts for installing the command line developer's tools, which
seems
to install /usr/include ; but the Command Line Developer's Tool installed this
way is only version 5.1 (i.e. against an older version of xcode, I think).

Also I think it could be a bit more user friendly - e.g. test for the existence
of /usr/include, and set "--with-sysroot=\"`xcrun --show-sdk-path`\" if
/usr/include does not exist? It isn't much more code, but would make a lot of
difference in user-friendliness.

[Bug target/57792] toplevel configure should enable "--with-sysroot="`xcrun --show-sdk-path`"" for darwin13 and later

[howarth at bromo dot med.uc.edu]

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

--- Comment #13 from howarth at bromo dot med.uc.edu ---
Yes, I am pretty sure Apple has abandoned this for good. They only attempted
the change because it was assumed to be completely transparent as the compiler
looks in /usr/include by default. It wasn't appreciated that this would
cause...

radr://14320107 "/usr/bin/python reports back include directories that are
unpopulated"

where removal of /usr/include caused the system Python.h to point to an
unpopulated header directory in INCLUDEPY. While I provided them with a patch
to sysconfig.py to solve this, there is no stomach at Apple for pushing such
changes upstream as other packages like perl that hardcode compiler options
will need to be modified as well.
    While we could add this change to FSF gcc, I don't think we want to
encourage users not to install the system headers in /usr/include via the
Command Line Tools of Xcode as there are other configure scripts out there
which will also need to be patched to find /usr/include with `xcrun
--show-sdk-path`.
    If we made any change, I would rather it be a check in FSF gcc's configure
for the presence of /usr/include on darwin which provided the appropriate error
message to the user that the Command Line Tools needs to be installed.

[Bug target/57792] toplevel configure should enable "--with-sysroot="`xcrun --show-sdk-path`"" for darwin13 and later

[htl10 at users dot sourceforge.net]

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

--- Comment #14 from Hin-Tak Leung <htl10 at users dot sourceforge.net> ---
(In reply to howarth from comment #13)
>
>     If we made any change, I would rather it be a check in FSF gcc's
> configure for the presence of /usr/include on darwin which provided the
> appropriate error message to the user that the Command Line Tools needs to
> be installed.

I don't think mandating Command Line Tools would be a good idea - I think in
that case you can have a reverse problem when your intention is to build stuff
for other people: you build x intended for others, you have /usr/include but
others don't, x made assumptions about the intended users having the same stuff
as yours, and it doesn't work on the intended user's machine, or have
mysterious errors.

[Bug target/57792] toplevel configure should enable "--with-sysroot="`xcrun --show-sdk-path`"" for darwin13 and later

[mrs at gcc dot gnu.org]

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

--- Comment #15 from mrs at gcc dot gnu.org <mrs at gcc dot gnu.org> ---
Mandating commands line tools is fine.  Would be nice if everything worked
flawlessly if no optional package had to be installed, but I'm pragmatic.

[Bug target/57792] toplevel configure should enable "--with-sysroot="`xcrun --show-sdk-path`"" for darwin13 and later

[iains at gcc dot gnu.org]

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

Iain Sandoe <iains at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |iains at gcc dot gnu.org

--- Comment #16 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to mrs@gcc.gnu.org from comment #15)
> Mandating commands line tools is fine.  Would be nice if everything worked
> flawlessly if no optional package had to be installed, but I'm pragmatic.

I'd agree with pragmatism every time.
OTOH, 
(a) it would be nice to have a heads up on the thinking going forward (would
have been possible to ask filks last week).

(b) it is apparent that there's a move towards desiring a uniform interface
where the {native}host is considered "just another target" with its own SDK.

I kinda like the uniformity too.

[Bug target/57792] toplevel configure should enable "--with-sysroot="`xcrun --show-sdk-path`"" for darwin13 and later

[howarth at bromo dot med.uc.edu]

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

--- Comment #17 from howarth at bromo dot med.uc.edu ---
(In reply to Hin-Tak Leung from comment #14)
> (In reply to howarth from comment #13)
> >
> >     If we made any change, I would rather it be a check in FSF gcc's
> > configure for the presence of /usr/include on darwin which provided the
> > appropriate error message to the user that the Command Line Tools needs to
> > be installed.
> 
> I don't think mandating Command Line Tools would be a good idea - I think in
> that case you can have a reverse problem when your intention is to build
> stuff for other people: you build x intended for others, you have
> /usr/include but others don't, x made assumptions about the intended users
> having the same stuff as yours, and it doesn't work on the intended user's
> machine, or have mysterious errors.

You have to remember that Apple expects you to build everything from within the
Xcode projects while the Command Line Tools package exists to handle building
outside of that mechanism. The unfortunate fact is that far too much software
explicitly expects headers in /usr/include to avoid installing the Command Line
Tools. In the fink project, we get endless bug reports from users who fail to
install the Command Line Tools.

[Bug target/57792] toplevel configure should enable "--with-sysroot="`xcrun --show-sdk-path`"" for darwin13 and later

[htl10 at users dot sourceforge.net]

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

--- Comment #18 from Hin-Tak Leung <htl10 at users dot sourceforge.net> ---
(In reply to mrs@gcc.gnu.org from comment #15)
> Mandating commands line tools is fine.  Would be nice if everything worked
> flawlessly if no optional package had to be installed, but I'm pragmatic.

The current behavior is definitely wrong: without command line tools and
without --with-sysroot (i.e. just plain ./configure), ./configure returns
success, but only fail to 'make' towards the end of stage1 when the build
system tries to do the 'stage1-fixincludes' target.

./configure should either auto-add the --with-sysroot (as the reverted fix
did), or abort with an appropriate message, like the requirement for
gmp/mpfr/mpc. successful ./configure then failing part-way through make is bad.

(In reply to howarth from comment #17)
> You have to remember that Apple expects you to build everything from within
> the Xcode projects while the Command Line Tools package exists to handle
> building outside of that mechanism. The unfortunate fact is that far too
> much software explicitly expects headers in /usr/include to avoid installing
> the Command Line Tools. In the fink project, we get endless bug reports from
> users who fail to install the Command Line Tools.

Not really. Actually xcode 6.1 seem to ships all the command line tools. doing
'xcode-select --install' install a much older(?) command line tools plus
headers in /usr/include. I don't know if Apple is going to keep that in-sync,
but there might be a danger of the headers in /usr/include not really
describing the system.

Also, people who DIY are supposed to go through all the troubles... you still
haven't addressed the issue of new gcc (+ xcode building it with) may generate
stuff that have additional dependencies on /usr/include, if /usr/include is
around, and therefore not suitable when one is building things for others.

[Bug target/57792] toplevel configure should enable "--with-sysroot="`xcrun --show-sdk-path`"" for darwin13 and later

[howarth at bromo dot med.uc.edu]

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

--- Comment #19 from howarth at bromo dot med.uc.edu ---
(In reply to Hin-Tak Leung from comment #18)
> (In reply to mrs@gcc.gnu.org from comment #15)
> > Mandating commands line tools is fine.  Would be nice if everything worked
> > flawlessly if no optional package had to be installed, but I'm pragmatic.
> 
> The current behavior is definitely wrong: without command line tools and
> without --with-sysroot (i.e. just plain ./configure), ./configure returns
> success, but only fail to 'make' towards the end of stage1 when the build
> system tries to do the 'stage1-fixincludes' target.
> 
> ./configure should either auto-add the --with-sysroot (as the reverted fix
> did), or abort with an appropriate message, like the requirement for
> gmp/mpfr/mpc. successful ./configure then failing part-way through make is
> bad.
> 

The proper test to detect the missing Command Line Tools /usr/include files
should be added then.

> (In reply to howarth from comment #17)
> > You have to remember that Apple expects you to build everything from within
> > the Xcode projects while the Command Line Tools package exists to handle
> > building outside of that mechanism. The unfortunate fact is that far too
> > much software explicitly expects headers in /usr/include to avoid installing
> > the Command Line Tools. In the fink project, we get endless bug reports from
> > users who fail to install the Command Line Tools.
> 
> Not really. Actually xcode 6.1 seem to ships all the command line tools.
> doing 'xcode-select --install' install a much older(?) command line tools
> plus headers in /usr/include. I don't know if Apple is going to keep that
> in-sync, but there might be a danger of the headers in /usr/include not
> really describing the system.

You must have caught them before they synced. On my machine, I have synced
Xcode.app and Command Line Tools...

%
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
-v
Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin14.0.0
Thread model: posix

% /Library/Developer/CommandLineTools/usr/bin/clang -v
Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin14.0.0
Thread model: posix

from 'xcode-select --install'.

> 
> Also, people who DIY are supposed to go through all the troubles... you
> still haven't addressed the issue of new gcc (+ xcode building it with) may
> generate stuff that have additional dependencies on /usr/include, if
> /usr/include is around, and therefore not suitable when one is building
> things for others.

Are you assuming that folks are installing third-party stuff in /usr/include?
Since users should be installing only in /usr/local for that, that seems a bit
out of bounds here.

[Bug target/57792] toplevel configure should enable "--with-sysroot="`xcrun --show-sdk-path`"" for darwin13 and later

[iains at gcc dot gnu.org]

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

--- Comment #20 from Iain Sandoe <iains at gcc dot gnu.org> ---

Unofficially (but after chatting with a couple of folks who know):

"It should be assumed that depending on /usr/{include,lib} is unreliable".

"The RightWay(™) for the system is deemed to be finding a suitable SDK root
from "wherever".  Yes, it's recognised that this is somewhat of a pain."

===

IMO we need to have a design that recognises that we (darwin support in GCC)
have different objectives from Xcode.

difference: #1 we support N-K (where N == host OS version, and K might be +/-
some number > 1).  This means that we want to be able to find SDKs for system
versions that might not be included in the "current" Xcode.  I don't like the
idea of shoe-horning those (extra SDKs) into Xcode just so that it can find
them - although I know folks already do that.

- note that -mmacosx-version-min= and MACOSX_DEPLOYMENT_TARGET can go some way
towards achieving part of those objectives - but it won't (for example) let you
build for powerpc-darwin9 from x86-86-darwin13 [something I *do* often do].

difference #2 (at least I) have an objective that one day - hopefully not too
far away, we will be able to cross-build for darwin ( > 9 ;) ) from other
platforms, e.g. Linux.

To that end I think we need a coherent design to cater for GCC's needs.

My initial suggestion is that we don't try to (ab-)use sysroot for this, but
instead add a --with-SDK-root= option that may be specified multiple times.  We
might eventually need the driver to try and find the best match for the SDK
given a User "-mmacosx-version-min" and maybe even (one day)
-mmacosx-version-max= ..

This should have fall-backs as follows:

  xcrun … where that's available
  /Developer/SDKs (Darwin <= 9)
  / - essentially 'hope for the best' with /usr/{include,lib}

I think there are adequate hooks in config/darwin-c.c to deal with this without
impacting any part of the compiler outside the port [but that's without having
tried it].

====

I tend to agree that developers have to be prepared to understand a little
about what their doing - but IMO the User of the compiler (someone just trying
to build her code) should not have to jump through hoops to achieve that - at
least for a host-native compile ;)

I know Mike is not a fan of new C/L options, so I'm open to counter-proposals.
>From gcc-bugs-return-466054-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Nov 08 15:56:18 2014
Return-Path: <gcc-bugs-return-466054-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 9510 invoked by alias); 8 Nov 2014 15:56:17 -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 9481 invoked by uid 48); 8 Nov 2014 15:56:14 -0000
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/63780] std::remquo returns wrong quotient
Date: Sat, 08 Nov 2014 15:56:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 4.8.3
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: redi at gcc dot gnu.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:
Message-ID: <bug-63780-4-bab1MNqCuC@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63780-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63780-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: 2014-11/txt/msg00526.txt.bz2
Content-length: 456

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

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
This is nothing to do with libstdc++:

int main() {
  int n;
  double x = 3419, m = 360;
  double y = __builtin_remainder(x, m);
  double z = __builtin_remquo(x, m, &n);
  __builtin_printf("result %.0f %.0f %d\n", y, z, n);
}

With optimisation GCC inlines its own definitions that give the right answer,
so this looks like a glibc bug.