Re: [PATCH 0/2] backport c++ header fixes to gcc-5-branch

[Jack Howarth]

On Mon, Sep 18, 2017 at 1:48 PM, Mike Stump <mikest...@comcast.net> wrote:
> I was hoping an RM would approve this as it seems just a hair beyond a normal 
> darwin approval.  I'm fine with this, and it does help darwin.  Other ports 
> should not care.

Mike,
 Unless I am misreading this...

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81037#c12

wasn't that an approval from Richard Biener for applying the backport
way back on 9/14?
 Jack

>
> On Sep 18, 2017, at 10:31 AM, Jack Howarth <howarth.at@gmail.com> wrote:
>>
>> Pinging for the final gcc 5.5 release.
>>
>> On Mon, Aug 7, 2017 at 1:12 AM, Ryan Mounce <r...@mounce.com.au> wrote:
>>> Fixes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81037
>>>
>>> Bootstrap now succeeds using Xcode 9 toolchain.
>>>
>>> Tested on macOS 10.13 beta, however same issue reported on macOS 10.12
>>> with Xcode 9.
>>>
>>> Ryan Mounce (2):
>>>  (header usage fix) remove unused system header includes
>>>  (header usage fix) include c++ headers in system.h
>>>
>>> gcc/ChangeLog| 29 +
>>> gcc/auto-profile.c   |  6 ++
>>> gcc/c/c-objc-common.c|  2 --
>>> gcc/config/sh/sh.c   |  2 +-
>>> gcc/config/sh/sh_treg_combine.cc |  7 +++
>>> gcc/cp/error.c   |  2 --
>>> gcc/diagnostic.c |  2 --
>>> gcc/fortran/error.c  |  2 --
>>> gcc/fortran/trans-common.c   |  2 +-
>>> gcc/genmatch.c   |  1 -
>>> gcc/graphite-isl-ast-to-gimple.c |  2 +-
>>> gcc/ipa-icf-gimple.c |  2 +-
>>> gcc/ipa-icf.c|  2 +-
>>> gcc/pretty-print.c   |  2 --
>>> gcc/system.h | 12 
>>> gcc/toplev.c |  2 --
>>> 16 files changed, 51 insertions(+), 26 deletions(-)
>>>
>>> --
>>> 2.13.2 (Apple Git-90)
>>>
>

Re: [PATCH 0/2] backport c++ header fixes to gcc-5-branch

[Jack Howarth]

Pinging for the final gcc 5.5 release.

On Mon, Aug 7, 2017 at 1:12 AM, Ryan Mounce  wrote:
> Fixes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81037
>
> Bootstrap now succeeds using Xcode 9 toolchain.
>
> Tested on macOS 10.13 beta, however same issue reported on macOS 10.12
> with Xcode 9.
>
> Ryan Mounce (2):
>   (header usage fix) remove unused system header includes
>   (header usage fix) include c++ headers in system.h
>
>  gcc/ChangeLog| 29 +
>  gcc/auto-profile.c   |  6 ++
>  gcc/c/c-objc-common.c|  2 --
>  gcc/config/sh/sh.c   |  2 +-
>  gcc/config/sh/sh_treg_combine.cc |  7 +++
>  gcc/cp/error.c   |  2 --
>  gcc/diagnostic.c |  2 --
>  gcc/fortran/error.c  |  2 --
>  gcc/fortran/trans-common.c   |  2 +-
>  gcc/genmatch.c   |  1 -
>  gcc/graphite-isl-ast-to-gimple.c |  2 +-
>  gcc/ipa-icf-gimple.c |  2 +-
>  gcc/ipa-icf.c|  2 +-
>  gcc/pretty-print.c   |  2 --
>  gcc/system.h | 12 
>  gcc/toplev.c |  2 --
>  16 files changed, 51 insertions(+), 26 deletions(-)
>
> --
> 2.13.2 (Apple Git-90)
>

Re: [PATCH 1/2] (header usage fix) remove unused system header includes

[Jack Howarth]

Pinging for the final gcc 5.5 release.

On Mon, Aug 7, 2017 at 1:12 AM, Ryan Mounce  wrote:
> 2017-08-05  Ryan Mounce  
>
> cherry picked from trunk r235361
> 2016-04-22  Szabolcs Nagy  
>
> * auto-profile.c: Remove  include.
> * diagnostic.c: Remove  include.
> * genmatch.c: Likewise.
> * pretty-print.c: Likewise.
> * toplev.c: Likewise
> * c/c-objc-common.c: Likewise.
> * cp/error.c: Likewise.
> * fortran/error.c: Likewise.
> ---
>  gcc/ChangeLog | 14 ++
>  gcc/auto-profile.c|  1 -
>  gcc/c/c-objc-common.c |  2 --
>  gcc/cp/error.c|  2 --
>  gcc/diagnostic.c  |  2 --
>  gcc/fortran/error.c   |  2 --
>  gcc/genmatch.c|  1 -
>  gcc/pretty-print.c|  2 --
>  gcc/toplev.c  |  2 --
>  9 files changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/gcc/ChangeLog b/gcc/ChangeLog
> index 3b431ce83f4..f3280917ad8 100644
> --- a/gcc/ChangeLog
> +++ b/gcc/ChangeLog
> @@ -1,3 +1,17 @@
> +2017-08-05  Ryan Mounce  
> +
> +   Backport from mainline
> +   2016-04-22  Szabolcs Nagy  
> +
> +   * auto-profile.c: Remove  include.
> +   * diagnostic.c: Remove  include.
> +   * genmatch.c: Likewise.
> +   * pretty-print.c: Likewise.
> +   * toplev.c: Likewise
> +   * c/c-objc-common.c: Likewise.
> +   * cp/error.c: Likewise.
> +   * fortran/error.c: Likewise.
> +
>  2017-07-31  Jakub Jelinek  
>
> PR sanitizer/81604
> diff --git a/gcc/auto-profile.c b/gcc/auto-profile.c
> index b8b02d174b4..a5e7225e338 100644
> --- a/gcc/auto-profile.c
> +++ b/gcc/auto-profile.c
> @@ -21,7 +21,6 @@ along with GCC; see the file COPYING3.  If not see
>  #include "config.h"
>  #include "system.h"
>
> -#include 
>  #include 
>  #include 
>
> diff --git a/gcc/c/c-objc-common.c b/gcc/c/c-objc-common.c
> index 344d4e2949c..c1ec601f93c 100644
> --- a/gcc/c/c-objc-common.c
> +++ b/gcc/c/c-objc-common.c
> @@ -38,8 +38,6 @@ along with GCC; see the file COPYING3.  If not see
>  #include "langhooks.h"
>  #include "c-objc-common.h"
>
> -#include   // For placement new.
> -
>  static bool c_tree_printer (pretty_printer *, text_info *, const char *,
> int, bool, bool, bool);
>
> diff --git a/gcc/cp/error.c b/gcc/cp/error.c
> index 0c8bd66a325..f502127f34f 100644
> --- a/gcc/cp/error.c
> +++ b/gcc/cp/error.c
> @@ -44,8 +44,6 @@ along with GCC; see the file COPYING3.  If not see
>  #include "ubsan.h"
>  #include "internal-fn.h"
>
> -#include // For placement-new.
> -
>  #define pp_separate_with_comma(PP) pp_cxx_separate_with (PP, ',')
>  #define pp_separate_with_semicolon(PP) pp_cxx_separate_with (PP, ';')
>
> diff --git a/gcc/diagnostic.c b/gcc/diagnostic.c
> index c43162269ec..1c3815c9f3d 100644
> --- a/gcc/diagnostic.c
> +++ b/gcc/diagnostic.c
> @@ -41,8 +41,6 @@ along with GCC; see the file COPYING3.  If not see
>  # include 
>  #endif
>
> -#include  // For placement new.
> -
>  #define pedantic_warning_kind(DC)  \
>((DC)->pedantic_errors ? DK_ERROR : DK_WARNING)
>  #define permissive_error_kind(DC) ((DC)->permissive ? DK_WARNING : DK_ERROR)
> diff --git a/gcc/fortran/error.c b/gcc/fortran/error.c
> index 18e127f8748..2f76de50c9e 100644
> --- a/gcc/fortran/error.c
> +++ b/gcc/fortran/error.c
> @@ -34,8 +34,6 @@ along with GCC; see the file COPYING3.  If not see
>  #include "diagnostic-color.h"
>  #include "tree-diagnostic.h" /* tree_diagnostics_defaults */
>
> -#include  /* For placement-new */
> -
>  static int suppress_errors = 0;
>
>  static bool warnings_not_errors = false;
> diff --git a/gcc/genmatch.c b/gcc/genmatch.c
> index 8f94ff09263..8f495616e2e 100644
> --- a/gcc/genmatch.c
> +++ b/gcc/genmatch.c
> @@ -22,7 +22,6 @@ along with GCC; see the file COPYING3.  If not see
>  .  */
>
>  #include "bconfig.h"
> -#include 
>  #include "system.h"
>  #include "coretypes.h"
>  #include "ggc.h"
> diff --git a/gcc/pretty-print.c b/gcc/pretty-print.c
> index 78d334eae88..6881d1aeabe 100644
> --- a/gcc/pretty-print.c
> +++ b/gcc/pretty-print.c
> @@ -25,8 +25,6 @@ along with GCC; see the file COPYING3.  If not see
>  #include "pretty-print.h"
>  #include "diagnostic-color.h"
>
> -#include // For placement-new.
> -
>  #if HAVE_ICONV
>  #include 
>  #endif
> diff --git a/gcc/toplev.c b/gcc/toplev.c
> index 17d05121026..237e24ef34e 100644
> --- a/gcc/toplev.c
> +++ b/gcc/toplev.c
> @@ -135,8 +135,6 @@ along with GCC; see the file COPYING3.  If not see
>  #define HAVE_prologue 0
>  #endif
>
> -#include 
> -
>  static void general_init (const char *, bool);
>  static void do_compile ();
>  static void process_options (void);
> --
> 2.13.2 (Apple Git-90)
>

Re: GCC 5.5 Status Report (2017-09-16)

[Jack Howarth]

On Sat, Sep 16, 2017 at 3:03 PM, Jakub Jelinek  wrote:
> Status
> ==
>
> The GCC 5 branch is still open for regression and documentation fixes
> but it's about time to close the branch with a last release from it.
> Thus at the end of the next week I plan to do a RC for GCC 5.5 following
> with a release and the branch closing game.

Jakub,
 Darwin still needs to have the proposed backports posted as...

https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00476.html
https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00478.html
https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00477.html

committed so that gcc-5-branch will build against Xcode 9's clang compiler.
   Jack

>
> Please consider backporting of important fixes (wrong-code, rejects-valid)
> but err on the side of caution.
>
>
> Quality Data
> 
>
> Priority  #   Change from last report
> ---   ---
> P10
> P2  229   +  91
> P3   12   -   8
> P4   99   +  23
> P5   27   -   1
> ---   ---
> Total P1-P3 241   +  83
> Total   367   + 105
>
>
> Previous Report
> ===
>
> https://gcc.gnu.org/ml/gcc/2016-06/msg00019.html

Re: [PATCH 0/2] backport c++ header fixes to gcc-5-branch

[Jack Howarth]

Szabolcs,
 Can you help get these back ports into gcc-5-branch?

https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00478.html
https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00477.html

Thanks in advance.
 Jack

On Mon, Aug 7, 2017 at 1:12 AM, Ryan Mounce  wrote:
> Fixes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81037
>
> Bootstrap now succeeds using Xcode 9 toolchain.
>
> Tested on macOS 10.13 beta, however same issue reported on macOS 10.12
> with Xcode 9.
>
> Ryan Mounce (2):
>   (header usage fix) remove unused system header includes
>   (header usage fix) include c++ headers in system.h
>
>  gcc/ChangeLog| 29 +
>  gcc/auto-profile.c   |  6 ++
>  gcc/c/c-objc-common.c|  2 --
>  gcc/config/sh/sh.c   |  2 +-
>  gcc/config/sh/sh_treg_combine.cc |  7 +++
>  gcc/cp/error.c   |  2 --
>  gcc/diagnostic.c |  2 --
>  gcc/fortran/error.c  |  2 --
>  gcc/fortran/trans-common.c   |  2 +-
>  gcc/genmatch.c   |  1 -
>  gcc/graphite-isl-ast-to-gimple.c |  2 +-
>  gcc/ipa-icf-gimple.c |  2 +-
>  gcc/ipa-icf.c|  2 +-
>  gcc/pretty-print.c   |  2 --
>  gcc/system.h | 12 
>  gcc/toplev.c |  2 --
>  16 files changed, 51 insertions(+), 26 deletions(-)
>
> --
> 2.13.2 (Apple Git-90)
>

Backport of r244010 to gcc-6-branch

[Jack Howarth]

  The following change from gcc-7-branch and trunk needs to be backported
to gcc-6-branch to allow the Xcode 9 clang compiler to bootstrap it. Tested
on 10.12 with Xcode 9 beta. Okay for gcc-6-branch?
 Jack


r244010-gcc_6_branch-backport.patch
Description: Binary data

Re: [PATCH fix PR71767 0/4] Background

[Jack Howarth]

What's up with the commit status on these proposed patches?

On Sun, Nov 6, 2016 at 2:36 PM, Iain Sandoe  wrote:
> Hi Folks,
>
> Including Jeff on the cc since we were discussing this on Friday (and it’s 
> not 100% clear who’s reviewing configury patches at present).
> Including Uros, because there’s one minor change to i386/i386.c
>
> PR71767 is " Endless stream of warnings when using GCC with -Wa,-q and Clang 
> Integrated Assembler”.
> ** we are talking 40k testsuite fails, so this is a show-stopper for current 
> toolchains.
>
> Actually, what’s happened is that recent xcode tools have started to issue a 
> warning about deprecated use of a mechanism to support coalesced symbols by 
> using separate sections with specific attributes in the (ancient) days before 
> the static linker supported them directly.  We need to catch up since 
> deprecation will no doubt be followed by removal.
>
> Essentially, now that the linker is capable of dealing with such things, the 
> right solution is to emit them into the regular sections and drop the use of 
> the coalesced ones.  This has been possible for some time, and Xcode is now 
> flagging that it’s time to tidy up and drop the old mechanism.
>
> However,
>
> A. this is only true when the “binutils” (cctools + ld64) are sufficiently 
> new to support it.
>   - so the solution needs to be made to depend on the version of ld64 in use.
>
> B. more importantly, it reveals some cases where the ld64 atom model*** will 
> be violated when symbols are concatenated such that weak globals and non-weak 
> locals can be confused.
>  - we need to fix this before we can apply A
>
> C. it makes a secondary variant of pr57438 fire more often (when switches 
> contain trailing cases with __builtin_unreachable() resulting in trailing 
> local symbols with jump-table references, that potentially have the same 
> address as a following weak global).  That might seem improbable, but c++ 
> with case statements with an unreachable default manage to hit it...
>  - I’ll post for this separately, but noting it in passing.
>
> 
>
> *** The ld64 atom model summary;
>
> Instead of using -ffunction-sections/-fdata-sections, Darwin’s linker has a 
> different model of partitioning the input objects such that they might be 
> rearranged to minimise displacements, and to identify dead code that may be 
> stripped (in a similar manner to —gc-sections).
>
> Input binaries to ld64 are automatically partitioned into “atoms”;
> an atom is defined as “a section of code or data beginning with a 
> linker-visible symbol and of non-zero size”.
>
> These “atoms” have the properties of their initial symbol and may be 
> rearranged and dead-stripped.
>
> — the general problem is that we might have a situation where we have:
>
>  visible-global-weak:
>  ….
>
> L:
>   ….
>
>   pic reference to L
>
> ld64 will split the object at “visible-global-weak” but it won’t see “L” 
> and so the pic reference will appear to point into the visible-global-weak 
> atom, [which is not allowed without indirection (to support interposing)].
>
> Of course, that’s a false-positive complaint - but ld64 can’t see the other 
> place to split.
>
> This is solved in other Darwin toolchains by making the “L” into “l” in such 
> cases;  lower-case “l” is not hidden by the assembler, and thus the linker 
> can see it and split the second section of code into its own ‘non-weak’ atom; 
> everyone’s happy.  Of course, we don’t want to do this unnecessarily, since 
> it’s inefficient from the PoV of extra symbols.
>
> linker-visible symbols made this way will not be retained in the final linked 
> entity (dso or exe).
>
> So:
>
> Patch 1:  implements the changes to modify L => l in the relevant places.
>
> Patch 2: Adds configury to specify or detect that the linker is ld64 (or 
> compatible) and to determine its version; there’s a fall-back to allow the 
> version to be specified by someone doing a native or Canadian cross.
>
> Patch 3: Is the actual fix that switches the section use to ‘regular’ for 
> sufficiently modern ld64 (there’s a minor change to i386/i386.c)
>
> Patch 4: (Mostly Dominique’s work) fixes up the testsuite fallout.
>
> This has been tested across the Darwin patch - from powerpc-darwin9 - 
> x86_64-apple-darwin16 and I did a bootstrap and check on x86_64-linux-gnu.
>
> The patches could be applied one at a time - but N typically depends on N-1 - 
> so the sequence of application needs to follow this.
>
> Iain
>
>
>
>

Re: [fixincludes] Fix macOS 10.12 and (PR sanitizer/78267)

[Jack Howarth]

Rainer,
Unfortunately this permutation still fails to bootstrap on darwin15...

libtool: compile:
/sw/src/fink.build/gcc7-7.0.0-1/darwin_objdir/./gcc/xgcc
-shared-libgcc -B/sw/src/fink.build/gcc7-7.0.0-1/darwin_objdir/./gcc
-nostdinc++ 
-L/sw/src/fink.build/gcc7-7.0.0-1/darwin_objdir/x86_64-apple-darwin15.6.0/libstdc++-v3/src
-L/sw/src/fink.build/gcc7-7.0.0-1/darwin_objdir/x86_64-apple-darwin15.6.0/libstdc++-v3/src/.libs
-L/sw/src/fink.build/gcc7-7.0.0-1/darwin_objdir/x86_64-apple-darwin15.6.0/libstdc++-v3/libsupc++/.libs
-B/sw/lib/gcc7/x86_64-apple-darwin15.6.0/bin/
-B/sw/lib/gcc7/x86_64-apple-darwin15.6.0/lib/ -isystem
/sw/lib/gcc7/x86_64-apple-darwin15.6.0/include -isystem
/sw/lib/gcc7/x86_64-apple-darwin15.6.0/sys-include -D_GNU_SOURCE
-D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS
-D__STDC_LIMIT_MACROS -DHAVE_RPC_XDR_H=0 -DHAVE_TIRPC_RPC_XDR_H=0 -I.
-I../../../../gcc-7-20161114/libsanitizer/sanitizer_common -I.. -I
../../../../gcc-7-20161114/libsanitizer/include -isystem
../../../../gcc-7-20161114/libsanitizer/include/system -Wall -W
-Wno-unused-parameter -Wwrite-strings -pedantic -Wno-long-long -fPIC
-fno-builtin -fno-exceptions -fno-rtti -fomit-frame-pointer
-funwind-tables -fvisibility=hidden -Wno-variadic-macros
-I../../libstdc++-v3/include
-I../../libstdc++-v3/include/x86_64-apple-darwin15.6.0
-I../../../../gcc-7-20161114/libsanitizer/../libstdc++-v3/libsupc++
-std=gnu++11 -g -O2 -MT sanitizer_mac.lo -MD -MP -MF
.deps/sanitizer_mac.Tpo -c
../../../../gcc-7-20161114/libsanitizer/sanitizer_common/sanitizer_mac.cc
 -fno-common -DPIC -o .libs/sanitizer_mac.o
../../../../gcc-7-20161114/libsanitizer/sanitizer_common/sanitizer_mac.cc:497:0:
warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
   os_trace("Address Sanitizer reported a failure.");

../../../../gcc-7-20161114/libsanitizer/sanitizer_common/sanitizer_mac.cc:497:0:
warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
../../../../gcc-7-20161114/libsanitizer/sanitizer_common/sanitizer_mac.cc:497:0:
warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
../../../../gcc-7-20161114/libsanitizer/sanitizer_common/sanitizer_mac.cc:500:0:
warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
   os_trace("Undefined Behavior Sanitizer reported a failure.");

../../../../gcc-7-20161114/libsanitizer/sanitizer_common/sanitizer_mac.cc:500:0:
warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
../../../../gcc-7-20161114/libsanitizer/sanitizer_common/sanitizer_mac.cc:500:0:
warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
../../../../gcc-7-20161114/libsanitizer/sanitizer_common/sanitizer_mac.cc:503:0:
warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
   os_trace("Thread Sanitizer reported a failure.");

../../../../gcc-7-20161114/libsanitizer/sanitizer_common/sanitizer_mac.cc:503:0:
warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
../../../../gcc-7-20161114/libsanitizer/sanitizer_common/sanitizer_mac.cc:503:0:
warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
../../../../gcc-7-20161114/libsanitizer/sanitizer_common/sanitizer_mac.cc:505:0:
warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
   os_trace("Sanitizer tool reported a failure.");

../../../../gcc-7-20161114/libsanitizer/sanitizer_common/sanitizer_mac.cc:505:0:
warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
../../../../gcc-7-20161114/libsanitizer/sanitizer_common/sanitizer_mac.cc:505:0:
warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
../../../../gcc-7-20161114/libsanitizer/sanitizer_common/sanitizer_mac.cc:508:0:
warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
   os_trace("Consult syslog for more information.");

../../../../gcc-7-20161114/libsanitizer/sanitizer_common/sanitizer_mac.cc:508:0:
warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
../../../../gcc-7-20161114/libsanitizer/sanitizer_common/sanitizer_mac.cc:508:0:
warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
In file included from
../../../../gcc-7-20161114/libsanitizer/sanitizer_common/sanitizer_mac.cc:39:0:
../../../../gcc-7-20161114/libsanitizer/sanitizer_common/sanitizer_mac.cc:
In function ‘void __sanitizer::LogFullErrorReport(const char*)’:
../../../../gcc-7-20161114/libsanitizer/sanitizer_common/sanitizer_mac.cc:497:7:
error: ‘_Static_assert’ was not declared in this scope
   os_trace("Address Sanitizer reported a failure.");
   ^
../../../../gcc-7-20161114/libsanitizer/sanitizer_common/sanitizer_mac.cc:497:7:
note: suggested alternative: ‘__cpp_static_assert’
../../../../gcc-7-20161114/libsanitizer/sanitizer_common/sanitizer_mac.cc:497:7:
error: ‘_os_trace_with_buffer’ was not declared in this scope
   os_trace("Address Sanitizer reported a failure.");
   ^
../../../../gcc-7-20161114/libsanitizer/sanitizer_common/sanitizer_mac.cc:497:7:
note: suggested alternative: ‘os_trace_with_payload’

[PATCH] fix PR sanitizer/78267

[Jack Howarth]

The attached patch fixes PR sanitizer/78267 by conditionalizing the
include of  on the compiler defining __BLOCKS__ as a
supported extension. Passes bootstrap on x86_64-apple-darwin15. Okay
for gcc trunk?
2016-11-14  Jack Howarth  <howarth.at@gmail.com>

libsanitizer/

PR sanitizer/78267
* sanitizer_common/sanitizer_mac.cc: Include  only if
compiler supports blocks extension.


Index: libsanitizer/sanitizer_common/sanitizer_mac.cc
===
--- libsanitizer/sanitizer_common/sanitizer_mac.cc  (revision 242387)
+++ libsanitizer/sanitizer_common/sanitizer_mac.cc  (working copy)
@@ -34,7 +34,7 @@
 extern char **environ;
 #endif
 
-#if defined(__has_include) && __has_include()
+#if defined(__has_include) && __has_include() && 
defined(__BLOCKS__)
 #define SANITIZER_OS_TRACE 1
 #include 
 #else

Fwd: failure notice

[Jack Howarth]

-- Forwarded message --
From: <mailer-dae...@sourceware.org>
Date: Mon, Nov 14, 2016 at 8:15 AM
Subject: failure notice
To: howarth.at@gmail.com


Hi. This is the qmail-send program at sourceware.org.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

<gcc-patches@gcc.gnu.org>:
Invalid mime type "text/html" detected in message text or
attachment.  Please send plain text messages only.
See http://sourceware.org/lists.html#sourceware-list-info for more information.
Contact gcc-patches-ow...@gcc.gnu.org if you have questions about this. (#5.7.2)

--- Below this line is a copy of the message.

Return-Path: <howarth.at@gmail.com>
Received: (qmail 26838 invoked by uid 89); 14 Nov 2016 13:15:50 -
Authentication-Results: sourceware.org; auth=none
X-Virus-Checked: by ClamAV 0.99.2 on sourceware.org
X-Virus-Found: No
X-Spam-Flag: YES
X-Spam-SWARE-Status: Yes, score=5.5 required=5.0
tests=BAYES_40,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS
autolearn=no version=3.3.2 spammy=Care, 73, 27336, 7.3
X-Spam-Status: Yes, score=5.5 required=5.0
tests=BAYES_40,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS
autolearn=no version=3.3.2
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org
X-Spam-Level: *
X-HELO: mail-yw0-f182.google.com
Received: from mail-yw0-f182.google.com (HELO
mail-yw0-f182.google.com) (209.85.161.182)
 by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon,
14 Nov 2016 13:15:39 +
Received: by mail-yw0-f182.google.com with SMTP id a10so57164557ywa.3
for <gcc-patches@gcc.gnu.org>; Mon, 14 Nov 2016 05:15:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
 :cc;
bh=ut9+GijOTPsFgXgpyv5pRUOLVxPD0mjqwq3dgw9nVcc=;
b=rnq9uE6RoNcPx/romZSBYrNuw2Z+26adCJWz2sZ+CBzYASOPPo+78xPFGbZcyCbVdb
 kDyv78RNQk33JxySlxjEmg8y6Bz0dB/QJlfrHf1VtGloVAbTpVuIsYS7ouZbJx3PZq9F
 lUyDBT0wUzNethLJaSKUaGVCYUetgurAyI6XB0T9CeiKM5qTv+ih/EM7Nr19v1zS1Hpz
 8sndaqnzhh7ySKfWyB/AwhBrae1By/Iui55/pSwpoMFY2HP0ZmLEJ0Iahz2dGerVhtcr
 hKzYP38ysWs16ACgxYO7Ro8CKG465Z9Er7Q2jNHvgimz3jsoI7/KtIVCptRn5nTDotDU
 2CNg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
 :message-id:subject:to:cc;
bh=ut9+GijOTPsFgXgpyv5pRUOLVxPD0mjqwq3dgw9nVcc=;
b=jjWHtYqA+8b7cqwAbEKsfErUsvN6OoBdn46xqgDyxI18HReNt/iFa2GZbyhDcg2Ao3
 //e4mfm/CSHAfi0yUTkxuYk7h1GVodTbfFZD7ifx00zy9AbB0F0+EVf+fOJAhNOhzBRl
 QwGyokx7YSxoJybduyTr8TEvRZQCRfI2joVCbmj5SxqFiLT0O6PgrvIGwAr3ofIQvpPy
 9AylyMxG4C9g8V+/w98kTYx/vtsAefnXFntyjoUjkX9Irub7yVyDI6DP3CmaKOVJXjJ0
 jpY+SaBYzQxuKP8CY5K+tLdUWPOew8s/Yt0iPTX3Yc9ci7qeklHCdvnFD2/V2QnHltCW
 C9zg==
X-Gm-Message-State:
ABUngvfUQDaYa/k+Z0TyCk8hv9XVzgk7w8548KL3RmaaLIB4I+909ZmhJFsXKI/GVQASQUlEbGTOs1KHYaaxtQ==
X-Received: by 10.202.245.74 with SMTP id t71mr8074538oih.37.1479129337927;
 Mon, 14 Nov 2016 05:15:37 -0800 (PST)
MIME-Version: 1.0
Received: by 10.202.225.212 with HTTP; Mon, 14 Nov 2016 05:15:36 -0800 (PST)
In-Reply-To: 
<cajmcou93wuaxjlz7frr1vrmgxn-bu7ajcoafxuwrfd1rs4j...@mail.gmail.com>
References: <ydd7f8awce3@cebitec.uni-bielefeld.de>
<cajmcou-k7qajc9qppo1ybtjwpsp7aeqggzlwaowomovqmym...@mail.gmail.com>
 <ydd37ivr6qp@cebitec.uni-bielefeld.de>
<cajmcou93wuaxjlz7frr1vrmgxn-bu7ajcoafxuwrfd1rs4j...@mail.gmail.com>
From: Jack Howarth <howarth.at@gmail.com>
Date: Mon, 14 Nov 2016 08:15:36 -0500
Message-ID: 

Fwd: [fixincludes] Fix macOS 10.12 and (PR sanitizer/78267)

[Jack Howarth]

-- Forwarded message --
From: Jack Howarth <howarth.at@gmail.com>
Date: Sun, Nov 13, 2016 at 1:19 PM
Subject: Re: [fixincludes] Fix macOS 10.12 
and  (PR sanitizer/78267)
To: Rainer Orth <r...@cebitec.uni-bielefeld.de>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>, Bruce Korb <bk...@gnu.org>




On Sun, Nov 13, 2016 at 5:53 AM, Rainer Orth
<r...@cebitec.uni-bielefeld.de> wrote:
>
> Hi Jack,
>
> > On darwin15, the proposed patch is insufficient to restore the bootstrap
> > (after running genfixes in the fixincludes directory) unless I also apply
> > the previously proposed change...
>
> no wonder: it's only been tested on darwin16.  Care to explain what
> error you're seeing?
>

The failure that I see on darwin15 using your proposed patches and
executing genfixes in fixincludes  before the build is...

libtool: compile:
/sw/src/fink.build/gcc7-7.0.0-1/darwin_objdir/./gcc/xgcc
-shared-libgcc -B/sw/src/fink.build/gcc7-7.0.0-1/darwin_objdir/./gcc
-nostdinc++ 
-L/sw/src/fink.build/gcc7-7.0.0-1/darwin_objdir/x86_64-apple-darwin15.6.0/libstdc++-v3/src
-L/sw/src/fink.build/gcc7-7.0.0-1/darwin_objdir/x86_64-apple-darwin15.6.0/libstdc++-v3/src/.libs
-L/sw/src/fink.build/gcc7-7.0.0-1/darwin_objdir/x86_64-apple-darwin15.6.0/libstdc++-v3/libsupc++/.libs
-B/sw/lib/gcc7/x86_64-apple-darwin15.6.0/bin/
-B/sw/lib/gcc7/x86_64-apple-darwin15.6.0/lib/ -isystem
/sw/lib/gcc7/x86_64-apple-darwin15.6.0/include -isystem
/sw/lib/gcc7/x86_64-apple-darwin15.6.0/sys-include -D_GNU_SOURCE
-D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS
-D__STDC_LIMIT_MACROS -DHAVE_RPC_XDR_H=0 -DHAVE_TIRPC_RPC_XDR_H=0 -I.
-I../../../../gcc-7-20161113/libsanitizer/sanitizer_common -I.. -I
../../../../gcc-7-20161113/libsanitizer/include -isystem
../../../../gcc-7-20161113/libsanitizer/include/system -Wall -W
-Wno-unused-parameter -Wwrite-strings -pedantic -Wno-long-long -fPIC
-fno-builtin -fno-exceptions -fno-rtti -fomit-frame-pointer
-funwind-tables -fvisibility=hidden -Wno-variadic-macros
-I../../libstdc++-v3/include
-I../../libstdc++-v3/include/x86_64-apple-darwin15.6.0
-I../../../../gcc-7-20161113/libsanitizer/../libstdc++-v3/libsupc++
-std=gnu++11 -g -O2 -MT sanitizer_mac.lo -MD -MP -MF
.deps/sanitizer_mac.Tpo -c
../../../../gcc-7-20161113/libsanitizer/sanitizer_common/sanitizer_mac.cc
 -fno-common -DPIC -o .libs/sanitizer_mac.o
../../../../gcc-7-20161113/libsanitizer/sanitizer_common/sanitizer_mac.cc:497:0:
warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
   os_trace("Address Sanitizer reported a failure.");

../../../../gcc-7-20161113/libsanitizer/sanitizer_common/sanitizer_mac.cc:497:0:
warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
../../../../gcc-7-20161113/libsanitizer/sanitizer_common/sanitizer_mac.cc:497:0:
warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
../../../../gcc-7-20161113/libsanitizer/sanitizer_common/sanitizer_mac.cc:500:0:
warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
   os_trace("Undefined Behavior Sanitizer reported a failure.");

../../../../gcc-7-20161113/libsanitizer/sanitizer_common/sanitizer_mac.cc:500:0:
warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
../../../../gcc-7-20161113/libsanitizer/sanitizer_common/sanitizer_mac.cc:500:0:
warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
../../../../gcc-7-20161113/libsanitizer/sanitizer_common/sanitizer_mac.cc:503:0:
warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
   os_trace("Thread Sanitizer reported a failure.");

../../../../gcc-7-20161113/libsanitizer/sanitizer_common/sanitizer_mac.cc:503:0:
warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
../../../../gcc-7-20161113/libsanitizer/sanitizer_common/sanitizer_mac.cc:503:0:
warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
../../../../gcc-7-20161113/libsanitizer/sanitizer_common/sanitizer_mac.cc:505:0:
warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
   os_trace("Sanitizer tool reported a failure.");

../../../../gcc-7-20161113/libsanitizer/sanitizer_common/sanitizer_mac.cc:505:0:
warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
../../../../gcc-7-20161113/libsanitizer/sanitizer_common/sanitizer_mac.cc:505:0:
warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
../../../../gcc-7-20161113/libsanitizer/sanitizer_common/sanitizer_mac.cc:508:0:
warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
   os_trace("Consult syslog for more information.");

../../../../gcc-7-20161113/libsanitizer/sanitizer_common/sanitizer_mac.cc:508:0:
warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
../../../../gcc-7-20161113/libsanitizer/sanitizer_common/sanitizer_mac.cc:508:0:
warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
In file included from
../../../../gcc-7-20161113/libsanitizer/s

Re: [PATCH fix PR71767 2/4 : Darwin configury] Arrange for ld64 to be detected as Darwin's linker

[Jack Howarth]

Iain,
 It certainly looks like you dropped a file here. The proposed
ChangeLog shows...

* config.in: Likewise.

but the previously proposed hunk from...

diff --git a/gcc/config.in b/gcc/config.in
index a736de3..a7ff3ee 100644
--- a/gcc/config.in
+++ b/gcc/config.in
@@ -1934,6 +1934,18 @@
 #endif


+/* Define to 1 if ld64 supports '-export_dynamic'. */
+#ifndef USED_FOR_TARGET
+#undef LD64_HAS_EXPORT_DYNAMIC
+#endif
+
+
+/* Define to ld64 version. */
+#ifndef USED_FOR_TARGET
+#undef LD64_VERSION
+#endif
+
+
 /* Define to the linker option to ignore unused dependencies. */
 #ifndef USED_FOR_TARGET
 #undef LD_AS_NEEDED_OPTION

from PR71767-vs-240230 has gone missing. The current patch still
produces a compiler which triggers warnings of...

warning: section "__textcoal_nt" is deprecated

during the bootstrap until that hunk of the original patch is restored.
Jack

On Sun, Nov 6, 2016 at 2:39 PM, Iain Sandoe  wrote:
> Hi Folks,
>
> This is an initial patch in a series that converts Darwin's configury to 
> detect ld64 features, rather than the current process of hard-coding them on 
> target system version.
>
> This adds an option --with-ld64[=version] that allows the configurer to 
> specify that the Darwin ld64 linker is in use.  If the version is given then 
> that will be used to determine the capabilities of the linker in native and 
> canadian crosses.  For Darwin targets this flag will default to "on", since 
> such targets require an ld64-compatible linker.
>
> If a DEFAULT_LINKER is set via --with-ld= then this will also be tested to 
> see if it is ld64.
>
> The ld64 version is determined (unless overridden by --with-ld64=version) and 
> this is exported for use in setting a default value for -mtarget-linker 
> (needed for run-time code-gen changes to section choices).
>
> In this initial patch, support for -rdynamic is converted to be detected at 
> config time, or by the ld64 version if that is explicitly given (as an 
> example of usage).
>
> OK for trunk?
> OK for open branches?
> Iain
>
> gcc/
>
> 2016-11-06  Iain Sandoe  
>
>PR target/71767
> * configure.ac (with-ld64): New arg-with.  gcc_ld64_version: New,
> new test.  gcc_cv_ld64_export_dynamic: New, New test.
> * configure: Regenerate.
> * config.in: Likewise.
> * darwin.h: Use LD64_HAS_DYNAMIC export. DEF_LD64: New, define.
> * darwin10.h(DEF_LD64): Update for this target version.
> * darwin12.h(LINK_GCC_C_SEQUENCE_SPEC): Remove rdynamic test.
> (DEF_LD64): Update for this target version.
> ---
>  gcc/config/darwin.h   | 16 ++-
>  gcc/config/darwin10.h |  5 
>  gcc/config/darwin12.h |  7 -
>  gcc/configure.ac  | 74 
> +++
>  4 files changed, 100 insertions(+), 2 deletions(-)
>
> diff --git a/gcc/config/darwin.h b/gcc/config/darwin.h
> index 045f70b..541bcb3 100644
> --- a/gcc/config/darwin.h
> +++ b/gcc/config/darwin.h
> @@ -165,6 +165,12 @@ extern GTY(()) int darwin_ms_struct;
> specifying the handling of options understood by generic Unix
> linkers, and for positional arguments like libraries.  */
>
> +#if LD64_HAS_EXPORT_DYNAMIC
> +#define DARWIN_EXPORT_DYNAMIC " %{rdynamic:-export_dynamic}"
> +#else
> +#define DARWIN_EXPORT_DYNAMIC " %{rdynamic: %nrdynamic is not supported}"
> +#endif
> +
>  #define LINK_COMMAND_SPEC_A \
> "%{!fdump=*:%{!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S:\
>  %(linker)" \
> @@ -185,7 +191,9 @@ extern GTY(()) int darwin_ms_struct;
>  %{!nostdlib:%{!nodefaultlibs:\
>%{%:sanitize(address): -lasan } \
>%{%:sanitize(undefined): -lubsan } \
> -  %(link_ssp) %(link_gcc_c_sequence)\
> +  %(link_ssp) \
> +  " DARWIN_EXPORT_DYNAMIC " % +  %(link_gcc_c_sequence) \
>  }}\
>  %{!nostdlib:%{!nostartfiles:%E}} %{T*} %{F*} }}}"
>
> @@ -932,4 +940,10 @@ extern void darwin_driver_init (unsigned int *,struct 
> cl_decoded_option **);
> fall-back default.  */
>  #define DEF_MIN_OSX_VERSION "10.5"
>
> +#ifndef LD64_VERSION
> +#define LD64_VERSION "85.2"
> +#else
> +#define DEF_LD64 LD64_VERSION
> +#endif
> +
>  #endif /* CONFIG_DARWIN_H */
> diff --git a/gcc/config/darwin10.h b/gcc/config/darwin10.h
> index 5829d78..a81fbdc 100644
> --- a/gcc/config/darwin10.h
> +++ b/gcc/config/darwin10.h
> @@ -32,3 +32,8 @@ along with GCC; see the file COPYING3.  If not see
>
>  #undef DEF_MIN_OSX_VERSION
>  #define DEF_MIN_OSX_VERSION "10.6"
> +
> +#ifndef LD64_VERSION
> +#undef DEF_LD64
> +#define DEF_LD64 "97.7"
> +#endif
> diff --git a/gcc/config/darwin12.h b/gcc/config/darwin12.h
> index e366982..f88e2a4 100644
> --- a/gcc/config/darwin12.h
> +++ b/gcc/config/darwin12.h
> @@ -21,10 +21,15 @@ along with GCC; see the file COPYING3.  If not see
>  #undef  LINK_GCC_C_SEQUENCE_SPEC
>  #define LINK_GCC_C_SEQUENCE_SPEC \
>  "%:version-compare(>= 10.6 mmacosx-version-min= 

Re: [PATCH] Fix PR driver/78206 by silently ignoring EPERM as well as ENOENT

[Jack Howarth]

On Sun, Nov 6, 2016 at 9:45 AM, Iain Sandoe <i...@codesourcery.com> wrote:
>
>> On 6 Nov 2016, at 06:04, Jack Howarth <howarth.at@gmail.com> wrote:
>>
>> On Sun, Nov 6, 2016 at 8:36 AM, Jack Howarth <howarth.at@gmail.com> 
>> wrote:
>>> The use of an Apple sandbox with denied file access permissions into 
>>> /usr/local
>>> exposed that cc1 fails on errors of...
>>>
>>> cc1: error: /usr/local/include: Operation not permitted
>>>
>>> The commonly suggested solution of using --with-local-prefix= set to 
>>> something
>>> other than /usr/local is undeirable on darwin because that creates a 
>>> compiler
>>> which retains library searches in /usr/local/lib despite no longer searching
>>> for headers in /usr/local/include (which makes it suspicable to 
>>> header/library
>>> mismatches during builds).
>>>
>>> The following trivial fix solves the issue by silently ignoring errors from
>>> denied permissions as well as non-existent dirs from the stat (cur->name, 
>>> )
>>> call in remove_dup() of gcc/incpath.c. Okay for gcc trunk and backports to
>>> gcc-5-branch and gcc-6-branch?
>>>   Jack Howarth
>>
>>Perhaps it would be useful if I expounded a bit on the
>> complexities that this
>> PR introduces on darwin. Both MacPorts and now fink leverage the Apple 
>> sandbox
>> to avoid contaminating their builds with development files installed
>> in /usr/local.
>> However the FSF gcc compiler packages built still should allow end-users to
>> build against /usr/local as normal outside of the packaging systems. On 
>> darwin,
>> it has been suggested that the sandbox build issues of FSF gcc be addressed 
>> by
>> using ---sysroot instead. Unfortunately that approach in not viable because 
>> the
>> Xcode developers no longer bundle the SDK of the prior OS in Xcode.app once
>> a new OS is released. Thus using the SDK installed at / is the only
>> option (since
>> building against the next OS SDK on the prior OS is unsupported on darwin),
>> and this nullifies the ability to use --sysroot to work around this issue.
>>
>> I believe the proposed patch is a trivial and straightforward solution
>> which allows
>> darwin developers to package the FSF gcc compilers within an Apple sandbox
>> while retaining the ability of the built compilers to behave as expect
>> with regard
>> to /usr/local outside of the Apple sandbox.
>
> a. The patch seems reasonable on one level (if you don’t have permission to 
> read the directory, then there’s no point in adding it to the search path).
>
> b. However, ISTM that your configuration process should be pointing the 
> compiler to a usable sysroot [which contains only directories to which the 
> toolchain has suitable permissions].
>
> c. It is clear that the situation is complex (for Darwin), we want users to 
> be able to use either the xcode-provided sdk as the sysroot or an 
> installation of the ‘command line tools’ (which effectively provides a 
> sysroot in ‘/‘).
>
> d.  One day we might be able to build enough of the sysroot to support the 
> compiler without needing this (but we’re not there yet).
>
> We cannot [AFAIU, INAL etc.] take the option of packaging the sysroot 
> ourselves until (d) is achieved.
>
> ===
>
> So… I’m not sure we have a good way of achieving this completely 
> automatically, in a user-transparent manner (yet) …  however, one way of 
> achieving this in a not-to-painful manner, is to have a toolchain layout like
>
>  bin/
>  lib/
>  SDKs/
>native => symlink to either the XCode sysroot - or ‘/‘.
>
> and to configure gcc  “—with-sysroot=/SDKs/native”

One can no longer safely assume that any place other than / has the
appropriate development SDK for open source software on darwin. As
Jeremy Huddleston Sequoia recently described the situation to me...

"Yeah, most OSS projects assume that the buildtime headers and
libraries match the minimum deployment target.  They decide that if
configure determines that openat(2) is available at build time, it can
be unconditionally used by the program.

The Apple model is that the SDK contains availability markup that
allows developers to specify older OS versions as a deployment target.
Newer symbols get weakly bound, and developers need to check for their
existence before usage.

Simply picking the 10.12 SDK when the developer/user has asked for the
system-matched SDK is going to result in problems, as we've repeatedly
seen when users try to build against the +1 SDK with software that
doesn't know how t

Re: [PATCH] Fix PR driver/78206 by silently ignoring EPERM as well as ENOENT

[Jack Howarth]

On Sun, Nov 6, 2016 at 8:36 AM, Jack Howarth <howarth.at@gmail.com> wrote:
> The use of an Apple sandbox with denied file access permissions into 
> /usr/local
> exposed that cc1 fails on errors of...
>
> cc1: error: /usr/local/include: Operation not permitted
>
> The commonly suggested solution of using --with-local-prefix= set to something
> other than /usr/local is undeirable on darwin because that creates a compiler
> which retains library searches in /usr/local/lib despite no longer searching
> for headers in /usr/local/include (which makes it suspicable to header/library
> mismatches during builds).
>
> The following trivial fix solves the issue by silently ignoring errors from
> denied permissions as well as non-existent dirs from the stat (cur->name, )
> call in remove_dup() of gcc/incpath.c. Okay for gcc trunk and backports to
> gcc-5-branch and gcc-6-branch?
>Jack Howarth

Perhaps it would be useful if I expounded a bit on the
complexities that this
PR introduces on darwin. Both MacPorts and now fink leverage the Apple sandbox
to avoid contaminating their builds with development files installed
in /usr/local.
However the FSF gcc compiler packages built still should allow end-users to
build against /usr/local as normal outside of the packaging systems. On darwin,
it has been suggested that the sandbox build issues of FSF gcc be addressed by
using ---sysroot instead. Unfortunately that approach in not viable because the
Xcode developers no longer bundle the SDK of the prior OS in Xcode.app once
a new OS is released. Thus using the SDK installed at / is the only
option (since
building against the next OS SDK on the prior OS is unsupported on darwin),
and this nullifies the ability to use --sysroot to work around this issue.

I believe the proposed patch is a trivial and straightforward solution
which allows
darwin developers to package the FSF gcc compilers within an Apple sandbox
while retaining the ability of the built compilers to behave as expect
with regard
to /usr/local outside of the Apple sandbox.
 Jack

[PATCH] Fix PR driver/78206 by silently ignoring EPERM as well as ENOENT

[Jack Howarth]

The use of an Apple sandbox with denied file access permissions into /usr/local
exposed that cc1 fails on errors of...

cc1: error: /usr/local/include: Operation not permitted

The commonly suggested solution of using --with-local-prefix= set to something
other than /usr/local is undeirable on darwin because that creates a compiler
which retains library searches in /usr/local/lib despite no longer searching
for headers in /usr/local/include (which makes it suspicable to header/library
mismatches during builds).

The following trivial fix solves the issue by silently ignoring errors from
denied permissions as well as non-existent dirs from the stat (cur->name, )
call in remove_dup() of gcc/incpath.c. Okay for gcc trunk and backports to
gcc-5-branch and gcc-6-branch?
   Jack Howarth


PR78206.patch
Description: Binary data

Re: [PATCH, libgfortran] PR 67585 Handle EINTR

[Jack Howarth]

On Fri, Oct 7, 2016 at 12:09 PM, Janne Blomqvist
 wrote:
> On Fri, Oct 7, 2016 at 5:50 PM, Fritz Reese  wrote:
>> On Fri, Oct 7, 2016 at 8:59 AM, Janne Blomqvist
>>  wrote:
>>> On Fri, Oct 7, 2016 at 2:41 PM, FX  wrote:
> Many POSIX systems have the bad habit of not restarting interrupted
> syscalls. On these systems it's up to the user to check for an error
> with errno == EINTR and restart manually. This patch does this for
> libgfortran, so that GFortran users don't have to do it.

 I have not much experience with EINTR, but is it garanteed that those 
 EINTR loops will never cycle forever?
>>>
>>> Hmm, no I don't think so, but I don't think it'll be a problem. So on
>>> systems where syscalls are not restarted automatically, EINTR happens
>>> when the process receives a signal while blocked in a system call [1].
>>> So I suppose in theory you could have a situation where something
>>> continuously fires signals at the process, and the result is some kind
>>> of race between the process restarting the syscall which then never
>>> manages to complete before being interrupted again. But I think this
>>> goes into the "Doctor, this hurts! Then don't do that" territory.
>>>
>>> There's some more info in https://www.python.org/dev/peps/pep-0475/
>>> (Python nowadays does the same as this patch).
>>
>>
>> Just one concern (slightly different from the race you described) -
>> what if a user wants/expects a system call to be interrupted? With the
>> patch we would always restart the system call even if the user was
>> expecting it would be interrupted. For small calls like lseek this may
>> not be a big deal but if read on a pipe/socket/terminal is restarted
>> after being interrupted (e.g. with CTRL-C) we may loop forever even if
>> the user program was written to expect and handle EINTR after the read
>> call, e.g. to terminate nicely with "non async-safe" calls like printf
>> that couldn't be done in the handler.
>
> Concievable yes, but IMHO unlikely. And since many systems
> automatically restart syscalls, a program like the above perhaps isn't
> that robust to begin with?
>
>> This is discussed as "use case 2" in the PEP you referenced. Python
>> handles this case by explicitly calling user defined signal handlers
>> directly after EINTR and checking the return value from the handler,
>> only trying again if the handler reports success. Not so simple I
>> think with libgfortran.
>
> With GFortran, a problem is that due to the buffering, handling of
> record markers etc. there is no 1:1 mapping between Fortran READ/WRITE
> statements and read(2)/write(2) syscalls. So even if we let EINTR
> propagate all the way back up to the Fortran caller (as happens now,
> except for write()), it actually has no way of knowing what should be
> restarted.
>

One issue that might need to be considered is whether the libgfortran
routines would ever be indirectly called from code that is using
fork()/exec(). We ran into a nasty regression in GNU Make 4.0/4.1
which was tickled when NLS support was enabled which indirectly pulled
in the CoreFoundation framework and its threading support via
libiconv. Upstream fixed this with...

http://savannah.gnu.org/bugs/index.php?46261#comment12

http://git.savannah.gnu.org/cgit/make.git/commit/?id=85c788572d054bc2c41b84007875edbd37ad3ed5

in make 4.2. So using EINTR properly can be really tricky.

>
>
> --
> Janne Blomqvist

Re: [PATCH] Fix PR66848 by enforcing 16-bit alignment on darwin

[Jack Howarth]

Hans,
  You can find some complete walks in lldb for the failing
boehm-gc test cases on darwin15 attached to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66848 as well as
stand-alone binaries for reproducing their failure on
x86_64-apple-darwin15 (should you have access to a Mac running El
Capitan).  The developers at Apple identified...

http://llvm.org/viewvc/llvm-project?view=revision=226751

as the change in llvm which sensitized Apple's libunwind.dylib to the
apparently latent boehm-gc bug. My limited understanding of the bug is
that the latent bug is a 16-bit alignment issue being exposed on
darwin since the failing test cases seem to go through...

libdyld.dylib`stack_not_16_byte_aligned_error

during the walks in lldb. I assumed that the use of ALIGNMENT 2 was
forcing the 16-bit alignment and suppressing the bug in current gcc's
boehm-gc.
 Jack



On Fri, Jan 1, 2016 at 1:28 PM, Hans Boehm <bo...@acm.org> wrote:
> [Adding Ivan, the current bdwgc maintainer.]
>
> I don't fully understand the issue here.  Do we understand where the problem
> is coming from?  Are the compiler/linker generating misaligned pointers
> someplace?  That would strike me as a misfeature elsewhere.
>
> Setting ALIGNMENT to 2, as in the patch, is a pretty big hammer.  It causes
> the gc to look for pointers at every 2 byte offset, quadrupling the number
> of potential pointers that are tested, and significantly increasing the risk
> of finding "false" pointers.  I would expect more problems caused by large
> block allocations.
>
> Hans
>
> On Mon, Dec 28, 2015 at 1:44 PM, Mike Stump <mikest...@comcast.net> wrote:
>>
>> On Dec 22, 2015, at 9:08 AM, Jack Howarth <howarth.at@gmail.com>
>> wrote:
>> > This bug doesn't exist in the more recent boehm-gc 7.2 or
>> > later releases. Until the exact change from 6.6 to 7.2 that suppresses
>> > this bug is identified or FSF gcc's boehm-gc is rebased on the 7.2
>> > version or later, the simple fix to suppress this issue on darwin is
>> > to enforce 16-bit alignment in boehm-gc/include/private/gcconfig.h for
>> > that target.
>>
>> It would be nice to just pull in 7.2 (or just the latest release)…  seems
>> like that should be easier to maintain to me.
>>
>> > Okay for gcc trunk and back ports to gcc-5-branch and gcc-4_9-branch?
>>
>> I’d like to punt the approval to a libboehm person, though, not sure we
>> have any.  Just checked we don’t have an official maintainer listed.  :-(
>> Do we have anybody that wants to review the patch or should I?  Though I
>> would prefer a new import of a newer library to fix the issue, I’m tempted
>> to just approve the patch.  Kinda don’t want to as any deviation makes
>> importing a new library annoying.  What do others think?
>
>

[PATCH] Fix PR66848 by enforcing 16-bit alignment on darwin

[Jack Howarth]

   The attached patch eliminates the boehm-gc and associated libjava
test suite failures on darwin15 due to the recompilation of the system
libunwind.dylib with Apple clang 7.0. The new optimizations in Apple
Clang 7.0 introduced by...

http://llvm.org/viewvc/llvm-project?view=revision=226751

resulted in the movement by the linker of symbols from __bss into
__data which exposed a latent bug in the boehm-gc 6.6 release used in
FSF gcc. This bug doesn't exist in the more recent boehm-gc 7.2 or
later releases. Until the exact change from 6.6 to 7.2 that suppresses
this bug is identified or FSF gcc's boehm-gc is rebased on the 7.2
version or later, the simple fix to suppress this issue on darwin is
to enforce 16-bit alignment in boehm-gc/include/private/gcconfig.h for
that target.
The attached change applied to current gcc trunk has been
confirmed to bootstrap on x86_64-apple-darwin[13,14,15] without
regressions in the boehm-gc and libjava test suites. Note that on
darwin15, the build must be installed before testing when the default
System Integrity Protection mode is enabled as that prevents
DYLD_LIBRARY_PATH from being passed along to helper processes.
 Okay for gcc trunk and back ports to gcc-5-branch and gcc-4_9-branch?
 Jack


PR66848.patch
Description: Binary data

[PATCH][Revised] Fix PR66509

[Jack Howarth]

  The attached revised patch adjusts the tests for the filds and fists
mnemonics to use the assembly...

filds (%ebp); fists (%ebp)

and the test for the fildq and fistq mnemonics to use the assembly...

fildq (%ebp); fistpq (%ebp)

which will assemble for both 64-bit and 32-bit mode. This is required
to avoid ambiguous instructions require an explicit suffix errors
from the clang-based assembler in Xcode 7. The change also has the
side-benefit of allowing the legacy GNU assembler from Xcode 6.3 or
earlier to properly detect that the filds, fists, fildq and fistq
mnemonics are available on x86_64-apple-darwin. Bootstrapped tested on
x86_64-apple-darwin14 against the Apple Inc version cctools-870, GNU
assembler version 1.38 and on x86_64-apple-darwin15 against the new
clang-based assembler.
Okay for gcc trunk?
   Jack
ps Also confirmed with 'as -32' and 'as -64' on x86_64 Fedora.


PR66509_v2.patch
Description: Binary data

Re: [PATCH] Fix PR66509

[Jack Howarth]

On Sat, Jun 13, 2015 at 12:04 AM, Mike Stump mikest...@comcast.net wrote:
 On Jun 12, 2015, at 8:25 PM, Jack Howarth howarth.at@gmail.com wrote:
   The attached patch revises the tests for the filds and fists
 mnemonics to use the assembly...

 filds mem(%rip); fists mem(%rip)

 Okay for gcc trunk?

 Fine from a darwin perspective, but I would like an x86 binutils person to 
 weigh in to make sure we aren’t turning off detection on some system that 
 supports the previous version but not the new spelling.


Mike,
   As I mentioned in the original PR, if that is a concern, there are
several other instances of the uses of () in detection of assembly
mnemonics in should be revisited as well. Perhaps H.J. can comment on
this issue.
  Jack

[PATCH] Fix PR66509

[Jack Howarth]

   The attached patch revises the tests for the filds and fists
mnemonics to use the assembly...

filds mem(%rip); fists mem(%rip)

and the test for the fildq and fistq mnemonics to use the assembly...

fildq mem(%rip); fistpq mem(%rip)

which will assemble for both 64-bit and 32-bit mode. This is required
to avoid ambiguous instructions require an explicit suffix errors
from the clang-based assembler in Xcode 7. The change also has the
side-benefit of allowing the legacy GNU assembler from Xcode 6.3 or
earlier to properly detect that the filds, fists, fildq and fistq
mnemonics are available on x86_64-apple-darwin. Bootstrapped tested on
x86_64-apple-darwin14 against the Apple Inc version cctools-870, GNU
assembler version 1.38 and on x86_64-apple-darwin15 against the new
clang-based assembler.
Okay for gcc trunk?
Jack


PR66509.patch
Description: Binary data

Re: [PATCH] Fix size type for cold partition names (hot-cold function partitioning)

[Jack Howarth]

The new patch bootstraps fine on x86_64-apple-darwin14.

On Wed, Apr 29, 2015 at 5:22 PM, Caroline Tice cmt...@google.com wrote:
 Here is a new patch to update the cold name partition so that it will
 only be treated like a function name and be given a size on the
 architectures that specifically define macros for such.

 I also updated the test case to try to only test on the appropriate
 architectures.  I am not sure I got the target triples correct for
 this, so I would appreciate some extra attention to that in the
 review.  I have tested this new patch on my workstation and it works
 as intended.  I am in the process of bootstrapping with the new patch.
 Assuming that the bootstrap passes, is this ok to commit?

 -- Caroline Tice
 cmt...@google.com

 ChangeLog (gcc):

 2015-04-29  Caroline Tice  cmt...@google.com

 PR 65929
 * config/elfos.h (ASM_DECLARE_COLD_FUNCTION_NAME): New macro 
 definition.
 (ASM_DECLARE_COLD_FUNCTION_SIZE): New macro definition.
 * final.c (final_scan_insn):  Use ASM_DECLARE_COLD_FUNCTION_NAME
 instead of ASM_DECLARE_FUNCTION_NAME for cold partition name.
 * varasm.c (assemble_end_function):  Use 
 ASM_DECLARE_COLD_FUNCTION_SIZE
 instead of ASM_DECLARE_FUNCTION_SIZE for cold partition size.

 ChangeLog (testsuite):

 2015-04-29  Caroline Tice  cmt...@google.com

PR  65929
 * gcc.dg/tree-prof/cold_partition_label.c:  Only check for cold
 partition size on certain targets.





 On Wed, Apr 29, 2015 at 11:59 AM, Caroline Tice cmt...@google.com wrote:
 Thank you; I will work with your suggestions and try to get a new
 patch done soon.

 -- Caroline Tice
 cmt...@google.com


 On Wed, Apr 29, 2015 at 11:34 AM, Uros Bizjak ubiz...@gmail.com wrote:
 On Wed, Apr 29, 2015 at 7:47 PM, Uros Bizjak ubiz...@gmail.com wrote:
 On Wed, Apr 29, 2015 at 7:38 PM, Caroline Tice cmt...@google.com wrote:
 The attached patch can revert the previous patch, if that is the way
 we should proceed on this.  If you want me to apply the reversion,
 please let me know.

 I would be happy to fix to the problem, rather than just reverting the
 patch, but I do not have expertise in assembly language on other
 platforms, so I would need some help, if anyone would be interested in
 helping me?

 How about adding ASM_DECLARE_COLD_FUNCTION_NAME and
 ASM_DECLARE_COLD_FUNCTION_SIZE? If these are defined, they can be used
 instead, and targets are free to define them in any way.

 Something like the attached prototype RFC patch. Using this patch,
 readelf -sW returns:

 Symbol table '.symtab' contains 18 entries:
Num:Value  Size TypeBind   Vis  Ndx Name
  0:  0 NOTYPE  LOCAL  DEFAULT  UND
  1:  0 SECTION LOCAL  DEFAULT1
  2:  0 SECTION LOCAL  DEFAULT3
  3:  0 SECTION LOCAL  DEFAULT4
  4:  0 SECTION LOCAL  DEFAULT5
  5:  0 SECTION LOCAL  DEFAULT6
  6:  0 SECTION LOCAL  DEFAULT8
  7:  8 FUNCLOCAL  DEFAULT6 main.cold.0
  8:  0 SECTION LOCAL  DEFAULT   10
  9:  0 SECTION LOCAL  DEFAULT   13
 10:  0 SECTION LOCAL  DEFAULT   12
 11:    312 FUNCGLOBAL DEFAULT [other: 88] 8 
 main
 12: 0008   160 OBJECT  GLOBAL DEFAULT  COM buf
 13:  0 NOTYPE  GLOBAL DEFAULT  UND memset
 14: 44 FUNCGLOBAL DEFAULT [other: 88] 1 
 sub2
 15:  0 NOTYPE  GLOBAL DEFAULT  UND strcmp
 16:  0 NOTYPE  GLOBAL DEFAULT  UND exit
 17:  0 NOTYPE  GLOBAL DEFAULT  UND abort

 Uros.

[PATCH] Support -rdynamic on darwin12 and later

[Jack Howarth]

 The attached patch adds support for the -rdynamic compiler flag
on darwin12 and later. The darwin linker, starting with Xcode 5 on
darwin12, added support for the associated new -export_dynamic linker
flag.

 -export_dynamic
 Preserves all global symbols in main executables
during LTO.  Without this option, Link Time Optimization is
 allowed to inline and remove global functions. This
option is used when a main executable may load a plug-in
 which requires certain symbols from the main executable.

This patch emulates the behavior of clang from Xcode 5 and later which
accepts the -rdynamic flag. Note that the emission of -export_dynamic
by -rdynamic is unaffected by the use of -mmacosx-version-min.
   These changes are achieved by the addition of rdynamic to
gcc/config/darwin.opt, addition of a   new gcc/config/darwin12.h file
with additional spec handling for rdynamic in LINK_GCC_C_SEQUENCE_SPEC
and changes to gcc/config.gcc to use this new file on darwin12 or
later. Bootstrap tested on both x86_64-apple-darwin11 and
x86_64-apple-darwin14. Confirmed that on darwin11, the -rdynamic flag
retains the current behavior of issuing the compiler error error:
unrecognized command line option ‘-rdynamic’. Confirmed that on
darwin12 and later, invoking -rdynamic emits the expected
-export_dynamc linker flag. Okay for gcc trunk?
Jack


darwin12_rdynamic.patch
Description: Binary data

[PATCH] PR debug/61352 back port from mainline

[Jack Howarth]

   The attached patch is a back port of the change from
https://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=211067 for
gcc-4_9-branch. Bootstrap and regression tested on
x86_64-apple-darwin14 with Xcode 6.3. Okay for gcc-4_9-branch?
   Jack
2015-04-12  Jack Howarth  howarth.at@gmail.com

Backport from mainline
2014-05-29  Mike Stump  mikest...@comcast.net
PR debug/61352
* collect2.c (maybe_run_lto_and_relink): Be sure to always run
post ld passes when lto is used.

Index: gcc/collect2.c
===
--- gcc/collect2.c  (revision 222021)
+++ gcc/collect2.c  (working copy)
@@ -848,6 +848,8 @@ maybe_run_lto_and_relink (char **lto_ld_
   fork_execute (ld, lto_ld_argv);
   post_ld_pass (false);
 }
+  else
+post_ld_pass (true);
 }
 
 /* Main program.  */

Re: PATCH] PR target/65612: Multiversioning doesn't work with DSO nor PIE

[Jack Howarth]

H.J.,
 While the latest patch fails to bootstrap on x86_64-apple-darwin14...

make[2]: Entering directory
'/sw/src/fink.build/gcc5-5.0.0-1/darwin_objdir/x86_64-apple-darwin14.3.0/libcilkrts'
/bin/sh ./libtool --tag=CXX   --mode=link
/sw/src/fink.build/gcc5-5.0.0-1/darwin_objdir/./gcc/xg++
-B/sw/src/fink.build/gcc5-5.0.0-1/darwin_objdir/./gcc/ -nostdinc++
-nostdinc++ 
-I/sw/src/fink.build/gcc5-5.0.0-1/darwin_objdir/x86_64-apple-darwin14.3.0/libstdc++-v3/include/x86_64-apple-darwin14.3.0
-I/sw/src/fink.build/gcc5-5.0.0-1/darwin_objdir/x86_64-apple-darwin14.3.0/libstdc++-v3/include
-I/sw/src/fink.build/gcc5-5.0.0-1/gcc-5-20150331/libstdc++-v3/libsupc++
-I/sw/src/fink.build/gcc5-5.0.0-1/gcc-5-20150331/libstdc++-v3/include/backward
-I/sw/src/fink.build/gcc5-5.0.0-1/gcc-5-20150331/libstdc++-v3/testsuite/util
-L/sw/src/fink.build/gcc5-5.0.0-1/darwin_objdir/x86_64-apple-darwin14.3.0/libstdc++-v3/src
-L/sw/src/fink.build/gcc5-5.0.0-1/darwin_objdir/x86_64-apple-darwin14.3.0/libstdc++-v3/src/.libs
-L/sw/src/fink.build/gcc5-5.0.0-1/darwin_objdir/x86_64-apple-darwin14.3.0/libstdc++-v3/libsupc++/.libs
-B/sw/src/fink.build/gcc5-5.0.0-1/darwin_objdir/x86_64-apple-darwin14.3.0/libstdc++-v3/src/.libs
-B/sw/src/fink.build/gcc5-5.0.0-1/darwin_objdir/x86_64-apple-darwin14.3.0/libstdc++-v3/libsupc++/.libs
-B/sw/lib/gcc5/x86_64-apple-darwin14.3.0/bin/
-B/sw/lib/gcc5/x86_64-apple-darwin14.3.0/lib/ -isystem
/sw/lib/gcc5/x86_64-apple-darwin14.3.0/include -isystem
/sw/lib/gcc5/x86_64-apple-darwin14.3.0/sys-include -g -O2
-version-info 5:0:0 -ldl -lpthread   -no-undefined  -o libcilkrts.la
-rpath /sw/lib/gcc5/lib cilk-abi-vla.lo os-unix-sysdep.lo bug.lo
cilk-abi.lo cilk-abi-cilk-for.lo cilk-abi-vla-internal.lo cilk_api.lo
cilk_fiber.lo cilk_fiber-unix.lo cilk_malloc.lo c_reducers.lo
except-gcc.lo frame_malloc.lo full_frame.lo global_state.lo jmpbuf.lo
local_state.lo metacall_impl.lo os_mutex-unix.lo os-unix.lo
pedigrees.lo record-replay.lo reducer_impl.lo scheduler.lo
signal_node.lo spin_mutex.lo stats.lo symbol_test.lo sysdep-unix.lo
worker_mutex.lo
libtool: link:
/sw/src/fink.build/gcc5-5.0.0-1/darwin_objdir/./gcc/xg++
-B/sw/src/fink.build/gcc5-5.0.0-1/darwin_objdir/./gcc/ -nostdinc++
-nostdinc++ 
-I/sw/src/fink.build/gcc5-5.0.0-1/darwin_objdir/x86_64-apple-darwin14.3.0/libstdc++-v3/include/x86_64-apple-darwin14.3.0
-I/sw/src/fink.build/gcc5-5.0.0-1/darwin_objdir/x86_64-apple-darwin14.3.0/libstdc++-v3/include
-I/sw/src/fink.build/gcc5-5.0.0-1/gcc-5-20150331/libstdc++-v3/libsupc++
-I/sw/src/fink.build/gcc5-5.0.0-1/gcc-5-20150331/libstdc++-v3/include/backward
-I/sw/src/fink.build/gcc5-5.0.0-1/gcc-5-20150331/libstdc++-v3/testsuite/util
-L/sw/src/fink.build/gcc5-5.0.0-1/darwin_objdir/x86_64-apple-darwin14.3.0/libstdc++-v3/src
-L/sw/src/fink.build/gcc5-5.0.0-1/darwin_objdir/x86_64-apple-darwin14.3.0/libstdc++-v3/src/.libs
-L/sw/src/fink.build/gcc5-5.0.0-1/darwin_objdir/x86_64-apple-darwin14.3.0/libstdc++-v3/libsupc++/.libs
-B/sw/lib/gcc5/x86_64-apple-darwin14.3.0/bin/
-B/sw/lib/gcc5/x86_64-apple-darwin14.3.0/lib/ -isystem
/sw/lib/gcc5/x86_64-apple-darwin14.3.0/include -isystem
/sw/lib/gcc5/x86_64-apple-darwin14.3.0/sys-include-dynamiclib  -o
.libs/libcilkrts.5.dylib  .libs/cilk-abi-vla.o .libs/os-unix-sysdep.o
.libs/bug.o .libs/cilk-abi.o .libs/cilk-abi-cilk-for.o
.libs/cilk-abi-vla-internal.o .libs/cilk_api.o .libs/cilk_fiber.o
.libs/cilk_fiber-unix.o .libs/cilk_malloc.o .libs/c_reducers.o
.libs/except-gcc.o .libs/frame_malloc.o .libs/full_frame.o
.libs/global_state.o .libs/jmpbuf.o .libs/local_state.o
.libs/metacall_impl.o .libs/os_mutex-unix.o .libs/os-unix.o
.libs/pedigrees.o .libs/record-replay.o .libs/reducer_impl.o
.libs/scheduler.o .libs/signal_node.o .libs/spin_mutex.o .libs/stats.o
.libs/symbol_test.o .libs/sysdep-unix.o .libs/worker_mutex.o
-L/sw/src/fink.build/gcc5-5.0.0-1/darwin_objdir/x86_64-apple-darwin14.3.0/libstdc++-v3/src
-L/sw/src/fink.build/gcc5-5.0.0-1/darwin_objdir/x86_64-apple-darwin14.3.0/libstdc++-v3/src/.libs
-L/sw/src/fink.build/gcc5-5.0.0-1/darwin_objdir/x86_64-apple-darwin14.3.0/libstdc++-v3/libsupc++/.libs
-ldl -lpthread-install_name  /sw/lib/gcc5/lib/libcilkrts.5.dylib
-compatibility_version 6 -current_version 6.0 -Wl,-single_module
Undefined symbols for architecture x86_64:
  ___cpu_model, referenced from:
  _restore_x86_fp_state in os-unix-sysdep.o
  _sysdep_save_fp_ctrl_state in os-unix-sysdep.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status
Makefile:540: recipe for target 'libcilkrts.la' failed
make[2]: *** [libcilkrts.la] Error 1
make[2]: Leaving directory
'/sw/src/fink.build/gcc5-5.0.0-1/darwin_objdir/x86_64-apple-darwin14.3.0/libcilkrts'
Makefile:13569: recipe for target 'all-target-libcilkrts' failed
make[1]: *** [all-target-libcilkrts] Error 2
make[1]: Leaving directory '/sw/src/fink.build/gcc5-5.0.0-1/darwin_objdir'
Makefile:21064: recipe for target 'bootstrap' failed
make: *** [bootstrap] Error 2

as darwin will require the 

Re: PATCH] PR target/65612: Multiversioning doesn't work with DSO nor PIE

[Jack Howarth]

H.J.,
Did you attach the correct version of the patch? I don't see
anything conditional on linux.
Jack

On Tue, Mar 31, 2015 at 11:58 AM, H.J. Lu hjl.to...@gmail.com wrote:
 On Tue, Mar 31, 2015 at 7:25 AM, Jack Howarth howarth.at@gmail.com 
 wrote:
 H.J.,
  While the latest patch fails to bootstrap on x86_64-apple-darwin14...

   _restore_x86_fp_state in os-unix-sysdep.o
   _sysdep_save_fp_ctrl_state in os-unix-sysdep.o
 ld: symbol(s) not found for architecture x86_64
 collect2: error: ld returned 1 exit status
 Makefile:540: recipe for target 'libcilkrts.la' failed
 make[2]: *** [libcilkrts.la] Error 1
 make[2]: Leaving directory
 '/sw/src/fink.build/gcc5-5.0.0-1/darwin_objdir/x86_64-apple-darwin14.3.0/libcilkrts'
 Makefile:13569: recipe for target 'all-target-libcilkrts' failed
 make[1]: *** [all-target-libcilkrts] Error 2
 make[1]: Leaving directory '/sw/src/fink.build/gcc5-5.0.0-1/darwin_objdir'
 Makefile:21064: recipe for target 'bootstrap' failed
 make: *** [bootstrap] Error 2

 as darwin will require the new usage of libgcc_nonshared.a to be added
 to the spec handling with...

 Here is the updated patch to make libgcc_nonshared.a optional
 so that it is only needed on Linux.

 Index: gcc/config/darwin.h
 ===
 --- gcc/config/darwin.h (revision 221794)
 +++ gcc/config/darwin.h (working copy)
 @@ -325,7 +325,7 @@ extern GTY(()) int darwin_ms_struct;
 need symbols from -lgcc.  */
  #undef REAL_LIBGCC_SPEC
  #define REAL_LIBGCC_SPEC   \
 -   %{static-libgcc|static: -lgcc_eh -lgcc;   \
 +   %{static-libgcc|static: -lgcc_eh -lgcc_nonshared -lgcc;   \
shared-libgcc|fexceptions|fgnu-runtime:   \
 %:version-compare(! 10.5 mmacosx-version-min= -lgcc_s.10.4)   \
 %:version-compare( 10.5 10.6 mmacosx-version-min= -lgcc_s.10.5)   \
 @@ -336,7 +336,7 @@ extern GTY(()) int darwin_ms_struct;
 %:version-compare( 10.5 10.6 mmacosx-version-min= -lgcc_s.10.5)   \
 %:version-compare(! 10.5 mmacosx-version-min= -lgcc_ext.10.4)   \
 %:version-compare(= 10.5 mmacosx-version-min= -lgcc_ext.10.5)   \
 -   -lgcc }
 +   -lgcc_nonshared -lgcc }

  /* We specify crt0.o as -lcrt0.o so that ld will search the library path.

  Jack
 ps One minor nit...

 Index: gcc/gcc.c
 ===
 --- gcc/gcc.c (revision 221794)
 +++ gcc/gcc.c (working copy)
 @@ -1566,11 +1566,13 @@ init_spec (void)
   if (in_sep  *p == '-'  strncmp (p, -lgcc, 5) == 0)
{
  init_gcc_specs (obstack,
 +-lgcc_nonshared 
  -lgcc_s
  #ifdef USE_LIBUNWIND_EXCEPTIONS
   -lunwind
  #endif
  ,
 +-lgcc_nonshared 
  -lgcc,
  -lgcc_eh
  #ifdef USE_LIBUNWIND_EXCEPTIONS
 @@ -1591,7 +1593,9 @@ init_spec (void)
  /* Ug.  We don't know shared library extensions.  Hope that
 systems that use this form don't do shared libraries.  */
  init_gcc_specs (obstack,
 +libgcc_nonshared.a%s 
  -lgcc_s,
 +libgcc_nonshared.a%s 
  libgcc.a%s,
  libgcc_eh.a%s

 You seem to have unnecessary trailing whitespace at the end of these flags.


 The white space is needed to avoid -lgcc_nonshared-lgcc_s.


 --
 H.J.
 ---

 We shouldn't call external function, __cpu_indicator_init, while an object
 is being relocated since its .got.plt section hasn't been updated.  It
 works for non-PIE since no update on .got.plt section is required.  This
 patch hides __cpu_indicator_init/__cpu_model from linker to force linker
 to resolve __cpu_indicator_init/__cpu_model to their hidden definitions
 in libgcc_nonshared.a while providing backward binary compatibility.  The
 new libgcc_nonshared.a is always linked togther with -lgcc_s and -lgcc.

 gcc/

 PR target/65612
 * gcc.c (init_spec): Add -lgcc_nonshared/libgcc_nonshared.a%s
 to -lgcc_s.

 gcc/testsuite/

 PR target/65612
 * g++.dg/ext/mv18.C: New test.
 * g++.dg/ext/mv19.C: Likewise.
 * g++.dg/ext/mv20.C: Likewise.
 * g++.dg/ext/mv21.C: Likewise.
 * g++.dg/ext/mv22.C: Likewise.
 * g++.dg/ext/mv23.C: Likewise.

 libgcc/

 PR target/65612
 * Makefile.in (LIB2ADDNONSHARED): New.
 (libgcc-nonshared-objects): Likewise.
 (libgcc_nonshared.a): Likewise.
 Check unsupported files in LIB2ADDNONSHARED.
 (iter-items): Add $(LIB2ADDNONSHARED).
 (all): Depend on libgcc_nonshared.a.
 ($(libgcc-nonshared-objects)): Depend on libgcc_tm.h.
 (install-leaf): Install libgcc_nonshared.a.
 * shared-object.mk: Check empty $o.
 * config/i386/cpuinfo.c (__cpu_model): Initialize.
 (__cpu_indicator_init@GCC_4.8.0): New.
 (__cpu_model@GCC_4.8.0): Likewise.
 * config/i386/t-cpuinfo (LIB2ADDNONSHARED): New.
 * config/i386/t-linux (HOST_LIBGCC2_CFLAGS): Add
 -DUSE_ELF_SYMVER.
 ---

Re: PATCH] PR target/65612: Multiversioning doesn't work with DSO nor PIE

[Jack Howarth]

On Tue, Mar 31, 2015 at 12:14 PM, H.J. Lu hjl.to...@gmail.com wrote:
 On Tue, Mar 31, 2015 at 9:09 AM, Jack Howarth howarth.at@gmail.com 
 wrote:
 H.J.,
 Did you attach the correct version of the patch? I don't see
 anything conditional on linux.
 Jack

 My patch will build and install libgcc_nonshared.a for all targets.  If you
 don't link against it, nothing is changed.  On Linux, it is used via the
 init_spec change.

Isn't...

diff --git a/gcc/gcc.c b/gcc/gcc.c
index d956c36..3fbd549 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -1566,6 +1566,7 @@ init_spec (void)
if (in_sep  *p == '-'  strncmp (p, -lgcc, 5) == 0)
  {
init_gcc_specs (obstack,
+   -lgcc_nonshared 
-lgcc_s
 #ifdef USE_LIBUNWIND_EXCEPTIONS
 -lunwind
@@ -1591,6 +1592,7 @@ init_spec (void)
/* Ug.  We don't know shared library extensions.  Hope that
   systems that use this form don't do shared libraries.  */
init_gcc_specs (obstack,
+   libgcc_nonshared.a%s 
-lgcc_s,
libgcc.a%s,
libgcc_eh.a%s

problematic for Solaris? I am unfamiliar with the Solaris spec
handling but sol2.h doesn't seem to have any instances of -lgcc which
might imply they use the stock compiler invocation which will now have
a non-existent libgcc_nonshared static library.
 Also, are you leaving the cpu symbols in libgcc.a on non-linux
targets? If not, the linkage failure reported in
https://gcc.gnu.org/ml/gcc-patches/2015-03/msg01668.html will occur,
no?
Jack

 --
 H.J.

Re: PATCH] PR target/65612: Multiversioning doesn't work with DSO nor PIE

[Jack Howarth]

On Tue, Mar 31, 2015 at 1:00 PM, H.J. Lu hjl.to...@gmail.com wrote:
 On Tue, Mar 31, 2015 at 9:39 AM, Jack Howarth howarth.at@gmail.com 
 wrote:
 On Tue, Mar 31, 2015 at 12:14 PM, H.J. Lu hjl.to...@gmail.com wrote:
 On Tue, Mar 31, 2015 at 9:09 AM, Jack Howarth howarth.at@gmail.com 
 wrote:
 H.J.,
 Did you attach the correct version of the patch? I don't see
 anything conditional on linux.
 Jack

 My patch will build and install libgcc_nonshared.a for all targets.  If you
 don't link against it, nothing is changed.  On Linux, it is used via the
 init_spec change.

 Isn't...

 diff --git a/gcc/gcc.c b/gcc/gcc.c
 index d956c36..3fbd549 100644
 --- a/gcc/gcc.c
 +++ b/gcc/gcc.c
 @@ -1566,6 +1566,7 @@ init_spec (void)
 if (in_sep  *p == '-'  strncmp (p, -lgcc, 5) == 0)
   {
 init_gcc_specs (obstack,
 +   -lgcc_nonshared 
 -lgcc_s
  #ifdef USE_LIBUNWIND_EXCEPTIONS
  -lunwind
 @@ -1591,6 +1592,7 @@ init_spec (void)
 /* Ug.  We don't know shared library extensions.  Hope that
systems that use this form don't do shared libraries.  */
 init_gcc_specs (obstack,
 +   libgcc_nonshared.a%s 
 -lgcc_s,
 libgcc.a%s,
 libgcc_eh.a%s

 problematic for Solaris? I am unfamiliar with the Solaris spec
 handling but sol2.h doesn't seem to have any instances of -lgcc which
 might imply they use the stock compiler invocation which will now have
 a non-existent libgcc_nonshared static library.

 libgcc_nonshared.a is built and installed for all targets.

  Also, are you leaving the cpu symbols in libgcc.a on non-linux
 targets? If not, the linkage failure reported in
 https://gcc.gnu.org/ml/gcc-patches/2015-03/msg01668.html will occur,
 no?

 My current patch doesn't change what are in libgcc.a.  It
 adds libgcc_nonshared.a for all targets, which contains
 the same cpuinfo.o as in libgcc.a or a dummy .o if libgcc.a
 doesn't have cpuinfo.o.


I can confirm that the most current patch bootstraps on
x86_64-apple-darwin14 and that all of the new tests show up as
unsupported in the test suite.
  Jack


 --
 H.J.

Re: PATCH] PR target/65612: Multiversioning doesn't work with DSO nor PIE

[Jack Howarth]

H.J.,
   This still breaks the darwin bootstrap but differently.

ar  rc libgcc_eh.a $objects
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib:
file: libgcc_eh.a(unwind-sjlj.o) has no symbols
ranlib libgcc_eh.a
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib:
file: libgcc_eh.a(unwind-sjlj.o) has no symbols
/sw/src/fink.build/gcc5-5.0.0-1/darwin_objdir/./gcc/xgcc
-B/sw/src/fink.build/gcc5-5.0.0-1/darwin_objdir/./gcc/
-B/sw/lib/gcc5/x86_64-apple-darwin14.3.0/bin/
-B/sw/lib/gcc5/x86_64-apple-darwin14.3.0/lib/ -isystem
/sw/lib/gcc5/x86_64-apple-darwin14.3.0/include -isystem
/sw/lib/gcc5/x86_64-apple-darwin14.3.0/sys-include-g -O2 -m32 -O2
-g -O2 -DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual
-Wno-format -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition  -isystem ./include   -pipe -fno-common -g
-DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector   -pipe
-fno-common -I. -I. -I../../.././gcc
-I../../../../gcc-5-20150330/libgcc
-I../../../../gcc-5-20150330/libgcc/.
-I../../../../gcc-5-20150330/libgcc/../gcc
-I../../../../gcc-5-20150330/libgcc/../include  -DHAVE_CC_TLS
-DUSE_EMUTLS -o cpuinfo_s.o -MT cpuinfo_s.o -MD -MP -MF cpuinfo_s.dep
-DSHARED  -c ../../../../gcc-5-20150330/libgcc/config/i386/cpuinfo.c
{standard input}:3:Unknown pseudo-op: .symver
{standard input}:3:Rest of line ignored. 1st junk character valued 95 (_).
{standard input}:4:Unknown pseudo-op: .symver
{standard input}:4:Rest of line ignored. 1st junk character valued 95 (_).
../../../../gcc-5-20150330/libgcc/shared-object.mk:18: recipe for
target 'cpuinfo_s.o' failed
make[5]: *** [cpuinfo_s.o] Error 1
make[5]: Leaving directory
'/sw/src/fink.build/gcc5-5.0.0-1/darwin_objdir/x86_64-apple-darwin14.3.0/i386/libgcc'
Makefile:1174: recipe for target 'multi-do' failed
make[4]: *** [multi-do] Error 1
make[4]: Leaving directory
'/sw/src/fink.build/gcc5-5.0.0-1/darwin_objdir/x86_64-apple-darwin14.3.0/libgcc'
Makefile:117: recipe for target 'all-multi' failed
make[3]: *** [all-multi] Error 2
make[3]: Leaving directory
'/sw/src/fink.build/gcc5-5.0.0-1/darwin_objdir/x86_64-apple-darwin14.3.0/libgcc'
Makefile:14820: recipe for target 'all-stage1-target-libgcc' failed
make[2]: *** [all-stage1-target-libgcc] Error 2
make[2]: Leaving directory '/sw/src/fink.build/gcc5-5.0.0-1/darwin_objdir'
Makefile:20760: recipe for target 'stage1-bubble' failed
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory '/sw/src/fink.build/gcc5-5.0.0-1/darwin_objdir'
Makefile:21064: recipe for target 'bootstrap' failed
make: *** [bootstrap] Error 2

 Jack

On Mon, Mar 30, 2015 at 10:08 PM, H.J. Lu hjl.to...@gmail.com wrote:
 On Mon, Mar 30, 2015 at 5:53 PM, Jack Howarth howarth.at@gmail.com 
 wrote:
 HJ,
  This patch breaks the bootstrap on targets like darwin which
 don't build libgcc_nonshared.a...

 if test -z $objects; then \
   echo 'int __libgcc_eh_dummy;'  eh_dummy.c; \
   /sw/src/fink.build/gcc5-5.0.0-1/darwin_objdir/./gcc/xgcc
 -B/sw/src/fink.build/gcc5-5.0.0-1/darwin_objdir/./gcc/
 -B/sw/lib/gcc5/x86_64-apple-darwin14.3.0/bin/
 -B/sw/lib/gcc5/x86_64-apple-darwin14.3.0/lib/ -isystem
 /sw/lib/gcc5/x86_64-apple-darwin14.3.0/include -isystem
 /sw/lib/gcc5/x86_64-apple-darwin14.3.0/sys-include-g -O2 -m32 -O2
 -g -O2 -DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual
 -Wno-format -Wstrict-prototypes -Wmissing-prototypes
 -Wold-style-definition  -isystem ./include   -pipe -fno-common -g
 -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector   -pipe
 -fno-common -I. -I. -I../../.././gcc
 -I../../../../gcc-5-20150330/libgcc
 -I../../../../gcc-5-20150330/libgcc/.
 -I../../../../gcc-5-20150330/libgcc/../gcc
 -I../../../../gcc-5-20150330/libgcc/../include  -DHAVE_CC_TLS
 -DUSE_EMUTLS -fvisibility=hidden -DHIDE_EXPORTS -c eh_dummy.c \
  -o eh_dummy.o; \
   objects=eh_dummy.o; \
 fi; \
 ar  rc libgcc_nonshared.a $objects
 ar: cpuinfo.o: No such file or directory
 Makefile:905: recipe for target 'libgcc_nonshared.a' failed
 make[5]: *** [libgcc_nonshared.a] Error 1
 make[5]: Leaving directory
 '/sw/src/fink.build/gcc5-5.0.0-1/darwin_objdir/x86_64-apple-darwin14.3.0/i386/libgcc'
 Makefile:1168: recipe for target 'multi-do' failed
 make[4]: *** [multi-do] Error 1
 make[4]: Leaving directory
 '/sw/src/fink.build/gcc5-5.0.0-1/darwin_objdir/x86_64-apple-darwin14.3.0/libgcc'
 Makefile:117: recipe for target 'all-multi' failed
 make[3]: *** [all-multi] Error 2
 make[3]: Leaving directory
 '/sw/src/fink.build/gcc5-5.0.0-1/darwin_objdir/x86_64-apple-darwin14.3.0/libgcc'
 Makefile:14820: recipe for target 'all-stage1-target-libgcc' failed
 make[2]: *** [all-stage1-target-libgcc] Error 2
 make[2]: Leaving directory '/sw/src/fink.build/gcc5-5.0.0-1/darwin_objdir'
 Makefile:20760: recipe for target 'stage1-bubble' failed
 make[1]: *** [stage1-bubble] Error 2
 make[1]: Leaving directory '/sw/src/fink.build/gcc5-5.0.0-1/darwin_objdir

Re: PATCH] PR target/65612: Multiversioning doesn't work with DSO nor PIE

[Jack Howarth]

HJ,
 This patch breaks the bootstrap on targets like darwin which
don't build libgcc_nonshared.a...

if test -z $objects; then \
  echo 'int __libgcc_eh_dummy;'  eh_dummy.c; \
  /sw/src/fink.build/gcc5-5.0.0-1/darwin_objdir/./gcc/xgcc
-B/sw/src/fink.build/gcc5-5.0.0-1/darwin_objdir/./gcc/
-B/sw/lib/gcc5/x86_64-apple-darwin14.3.0/bin/
-B/sw/lib/gcc5/x86_64-apple-darwin14.3.0/lib/ -isystem
/sw/lib/gcc5/x86_64-apple-darwin14.3.0/include -isystem
/sw/lib/gcc5/x86_64-apple-darwin14.3.0/sys-include-g -O2 -m32 -O2
-g -O2 -DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual
-Wno-format -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition  -isystem ./include   -pipe -fno-common -g
-DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector   -pipe
-fno-common -I. -I. -I../../.././gcc
-I../../../../gcc-5-20150330/libgcc
-I../../../../gcc-5-20150330/libgcc/.
-I../../../../gcc-5-20150330/libgcc/../gcc
-I../../../../gcc-5-20150330/libgcc/../include  -DHAVE_CC_TLS
-DUSE_EMUTLS -fvisibility=hidden -DHIDE_EXPORTS -c eh_dummy.c \
 -o eh_dummy.o; \
  objects=eh_dummy.o; \
fi; \
ar  rc libgcc_nonshared.a $objects
ar: cpuinfo.o: No such file or directory
Makefile:905: recipe for target 'libgcc_nonshared.a' failed
make[5]: *** [libgcc_nonshared.a] Error 1
make[5]: Leaving directory
'/sw/src/fink.build/gcc5-5.0.0-1/darwin_objdir/x86_64-apple-darwin14.3.0/i386/libgcc'
Makefile:1168: recipe for target 'multi-do' failed
make[4]: *** [multi-do] Error 1
make[4]: Leaving directory
'/sw/src/fink.build/gcc5-5.0.0-1/darwin_objdir/x86_64-apple-darwin14.3.0/libgcc'
Makefile:117: recipe for target 'all-multi' failed
make[3]: *** [all-multi] Error 2
make[3]: Leaving directory
'/sw/src/fink.build/gcc5-5.0.0-1/darwin_objdir/x86_64-apple-darwin14.3.0/libgcc'
Makefile:14820: recipe for target 'all-stage1-target-libgcc' failed
make[2]: *** [all-stage1-target-libgcc] Error 2
make[2]: Leaving directory '/sw/src/fink.build/gcc5-5.0.0-1/darwin_objdir'
Makefile:20760: recipe for target 'stage1-bubble' failed
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory '/sw/src/fink.build/gcc5-5.0.0-1/darwin_objdir'
Makefile:21064: recipe for target 'bootstrap' failed
make: *** [bootstrap] Error 2

  Jack

On Mon, Mar 30, 2015 at 6:25 PM, H.J. Lu hjl.to...@gmail.com wrote:
 On Sun, Mar 29, 2015 at 7:40 PM, H.J. Lu hjl.to...@gmail.com wrote:
 On Sun, Mar 29, 2015 at 7:34 PM, H.J. Lu hjl.to...@gmail.com wrote:
 On Sun, Mar 29, 2015 at 7:25 PM, H.J. Lu hjl.to...@gmail.com wrote:
 We shouldn't call external function, __cpu_indicator_init, while an object
 is being relocated since its .got.plt section hasn't been updated.  It
 works for non-PIE since no update on .got.plt section is required.  This
 patch hides __cpu_indicator_init/__cpu_model from linker to force linker
 to resolve __cpu_indicator_init/__cpu_model to their hidden definitions
 in libgcc.a while providing backward binary compatibility.

 OK for trunk, 4.9 and 4.9 branches?

 Thanks.


 H.J.
 ---
 libgcc/

 PR target/65612
 * config/i386/cpuinfo.c (__cpu_model): Initialize.
 (__cpu_indicator_init@GCC_4.8.0): New.
 (__cpu_model@GCC_4.8.0): Likewise.

 gcc/testsuite/

 PR target/65612
 * g++.dg/ext/mv18.C: New test.
 * g++.dg/ext/mv19.C: Likewise.
 * g++.dg/ext/mv20.C: Likewise.

 It doesn' work for shared C++ library:

 /export/build/gnu/gcc-x32/release/usr/gcc-5.0.0-x32/bin/g++ -O2-c
 -o main.o main.cc
 /export/build/gnu/gcc-x32/release/usr/gcc-5.0.0-x32/bin/g++ -shared
 -fPIC -O2  -o libmv20.so mv20.cc
 /export/build/gnu/gcc-x32/release/usr/gcc-5.0.0-x32/bin/g++ -O2  -o x
 main.o libmv20.so -Wl,-R,.
 /usr/local/bin/ld: x: hidden symbol `__cpu_model' in
 /export/build/gnu/gcc-x32/release/usr/gcc-5.0.0-x32/bin/../lib/gcc/x86_64-unknown-linux-gnu/5.0.0/libgcc.a(cpuinfo.o)
 is referenced by DSO
 /usr/local/bin/ld: final link failed: Bad value
 collect2: error: ld returned 1 exit status
 Makefile:12: recipe for target 'x' failed
 make: *** [x] Error 1
 [hjl@gnu-tools-1 pr65612]$

 --
 H.J.

 We need something like libgcc_nonshared.a, which contains cpuinfo.o, and
 link together with -lgcc_s when creating executable or DSO.


 I am testing it on Linux/x86-64.  OK for master if regression test
 passes?

 --
 H.J.
 --
 We shouldn't call external function, __cpu_indicator_init, while an object
 is being relocated since its .got.plt section hasn't been updated.  It
 works for non-PIE since no update on .got.plt section is required.  This
 patch hides __cpu_indicator_init/__cpu_model from linker to force linker
 to resolve __cpu_indicator_init/__cpu_model to their hidden definitions
 in libgcc_nonshared.a while providing backward binary compatibility.  The
 new libgcc_nonshared.a is always linked togther with -lgcc_s and -lgcc.

 gcc/

 PR target/65612
 * gcc.c (init_spec): Add -lgcc_nonshared/libgcc_nonshared.a%s
 to -lgcc_s/-lgcc/libgcc.a%s.

 gcc/testsuite/

 PR target/65612
 * 

Re: PATCH] PR target/65612: Multiversioning doesn't work with DSO nor PIE

[Jack Howarth]

On Mon, Mar 30, 2015 at 10:42 PM, H.J. Lu hjl.to...@gmail.com wrote:
 On Mon, Mar 30, 2015 at 7:08 PM, H.J. Lu hjl.to...@gmail.com wrote:
 On Mon, Mar 30, 2015 at 5:53 PM, Jack Howarth howarth.at@gmail.com 
 wrote:
 HJ,
  This patch breaks the bootstrap on targets like darwin which
 don't build libgcc_nonshared.a...

 if test -z $objects; then \
   echo 'int __libgcc_eh_dummy;'  eh_dummy.c; \
   /sw/src/fink.build/gcc5-5.0.0-1/darwin_objdir/./gcc/xgcc
 -B/sw/src/fink.build/gcc5-5.0.0-1/darwin_objdir/./gcc/
 -B/sw/lib/gcc5/x86_64-apple-darwin14.3.0/bin/
 -B/sw/lib/gcc5/x86_64-apple-darwin14.3.0/lib/ -isystem
 /sw/lib/gcc5/x86_64-apple-darwin14.3.0/include -isystem
 /sw/lib/gcc5/x86_64-apple-darwin14.3.0/sys-include-g -O2 -m32 -O2
 -g -O2 -DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual
 -Wno-format -Wstrict-prototypes -Wmissing-prototypes
 -Wold-style-definition  -isystem ./include   -pipe -fno-common -g
 -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector   -pipe
 -fno-common -I. -I. -I../../.././gcc
 -I../../../../gcc-5-20150330/libgcc
 -I../../../../gcc-5-20150330/libgcc/.
 -I../../../../gcc-5-20150330/libgcc/../gcc
 -I../../../../gcc-5-20150330/libgcc/../include  -DHAVE_CC_TLS
 -DUSE_EMUTLS -fvisibility=hidden -DHIDE_EXPORTS -c eh_dummy.c \
  -o eh_dummy.o; \
   objects=eh_dummy.o; \
 fi; \
 ar  rc libgcc_nonshared.a $objects
 ar: cpuinfo.o: No such file or directory
 Makefile:905: recipe for target 'libgcc_nonshared.a' failed
 make[5]: *** [libgcc_nonshared.a] Error 1
 make[5]: Leaving directory
 '/sw/src/fink.build/gcc5-5.0.0-1/darwin_objdir/x86_64-apple-darwin14.3.0/i386/libgcc'
 Makefile:1168: recipe for target 'multi-do' failed
 make[4]: *** [multi-do] Error 1
 make[4]: Leaving directory
 '/sw/src/fink.build/gcc5-5.0.0-1/darwin_objdir/x86_64-apple-darwin14.3.0/libgcc'
 Makefile:117: recipe for target 'all-multi' failed
 make[3]: *** [all-multi] Error 2
 make[3]: Leaving directory
 '/sw/src/fink.build/gcc5-5.0.0-1/darwin_objdir/x86_64-apple-darwin14.3.0/libgcc'
 Makefile:14820: recipe for target 'all-stage1-target-libgcc' failed
 make[2]: *** [all-stage1-target-libgcc] Error 2
 make[2]: Leaving directory '/sw/src/fink.build/gcc5-5.0.0-1/darwin_objdir'
 Makefile:20760: recipe for target 'stage1-bubble' failed
 make[1]: *** [stage1-bubble] Error 2
 make[1]: Leaving directory '/sw/src/fink.build/gcc5-5.0.0-1/darwin_objdir'
 Makefile:21064: recipe for target 'bootstrap' failed
 make: *** [bootstrap] Error 2

   Jack


 This one works.  I need to add $(LIB2ADDNONSHARED) $(LIB2ADDSHARED)
 to iter-items and handle duplicated items in them.


 There is no regression on Linux/x86-64.

 --
 H.J.

Can this wait for 5.2? Creating new libgcc libraries seems really
invasive for stage4.

Re: Fix line-maps wrt LTO

[Jack Howarth]

Jan,
 It appears that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61250 is due to a problem
in linemap_macro_map_lookup. It is hard to debug as the pch test
harness doesn't produce a simple logged compile failure to re-execute
but I can look at it from a core file in gdb. Unfortunately your
proposed patch doesn't eliminate PR61250 but I am wondering if it is
another related corner case with the linemaps overflows.
  Jack

On Wed, Mar 25, 2015 at 8:56 PM, Jan Hubicka hubi...@ucw.cz wrote:
 Hi,
 I read linemap_line_start and I think I noticed few issues with respect
 to overflows and lines being added randomly.

 1) line_delta is computed as to_line SOURCE_LINE (map, set-highest_line)
I think the last inserted line is not very releavnt.  What we care about is
the base of the last location and to keep thing dense how much we are
stretching the value range from highest inserted element (inserting into 
 middle
is cheap).

For this reason I added base_line_delta and changed line_delta to be
to_line - SOURCE_LINE (map, set-highest_location).

Because things go in randomly, highest_line, which really is last inserted
line, may be somewhere in between.
 2) (line_delta  10  line_delta * ORDINARY_MAP_NUMBER_OF_COLUMN_BITS (map) 
  1000)
ORDINARY_MAP_NUMBER_OF_COLUMN_BITS (map) is in range 7... 15, so it never
gets high enough to make this conditional trigger.  I changed it to:

   || line_delta  1000
   || (line_delta  ORDINARY_MAP_NUMBER_OF_COLUMN_BITS (map))  1000

I.e. we do not want to skip more than 1000 unused entries since highest
inserted location.

 3) (max_column_hint = 80  ORDINARY_MAP_NUMBER_OF_COLUMN_BITS (map) = 10)
seems to intend to reduce the column range when it is no longer needed.
Again, this is not really good idea when line inserted is not last.

 4) the code deciding whether to do reuse seems worng:
   if (line_delta  0
   || last_line != ORDINARY_MAP_STARTING_LINE_NUMBER (map)
   || SOURCE_COLUMN (map, highest) = (1U  column_bits))

line_delta really should be base_line_delta, we do not need to give up
when map's line is 1, SOURCE_LINE (map, set-highest_line) is 5
and we are requested to switch to line 3.

Second last_line != ORDINARY_MAP_STARTING_LINE_NUMBER (map) tests whether
location has only one line that does not work (at least with my changes)
because we may switch to next line and back.

This conditoinal also seems to be completely missing hanlding of overflows.

 The following patch makes all line info and all but one carret to to be right
 on chromium warnings

 Bootstrapped/regtested x86_64-linux, OK?

 * line-map.c (linemap_line_start): Correct overflow tests.
 Index: line-map.c
 ===
 --- line-map.c  (revision 221568)
 +++ line-map.c  (working copy)
 @@ -519,25 +519,38 @@ linemap_line_start (struct line_maps *se
struct line_map *map = LINEMAPS_LAST_ORDINARY_MAP (set);
source_location highest = set-highest_location;
source_location r;
 -  linenum_type last_line =
 -SOURCE_LINE (map, set-highest_line);
 -  int line_delta = to_line - last_line;
 +  int base_line_delta = to_line - ORDINARY_MAP_STARTING_LINE_NUMBER (map);
 +  int line_delta = to_line - SOURCE_LINE (map, set-highest_location);
bool add_map = false;

 -  if (line_delta  0
 -  || (line_delta  10
 -  line_delta * ORDINARY_MAP_NUMBER_OF_COLUMN_BITS (map)  1000)
 -  || (max_column_hint = (1U  ORDINARY_MAP_NUMBER_OF_COLUMN_BITS 
 (map)))
 +  /* Single MAP entry can be used to encode multiple source lines.
 + Look for situations when this is impossible or undesriable.  */
 +  if (base_line_delta  0
 +  /* We want to keep maps resonably dense, so do not increase the range
 +of this linemap entry by more than 1000.  */
 +  || line_delta  1000
 +  || (line_delta  ORDINARY_MAP_NUMBER_OF_COLUMN_BITS (map))  1000
 +  /* If the max column is out of range and we are still not dropping line
 +info.  */
 +  || (max_column_hint = (1U  ORDINARY_MAP_NUMBER_OF_COLUMN_BITS (map))
 +  highest  0x6000)
 +  /* If the prevoius line was long.  Ignore this problem is we already
 +re-used the map for lines with greater indexes.  */
|| (max_column_hint = 80
 -  ORDINARY_MAP_NUMBER_OF_COLUMN_BITS (map) = 10)
 +  ORDINARY_MAP_NUMBER_OF_COLUMN_BITS (map) = 10  line_delta  0)
 +  /* If we are just started running out of locations (which makes us to 
 drop
 +column info), but current line map still has column info, create 
 fresh
 +one.  */
|| (highest  0x6000
 -  (set-max_column_hint || highest  0x7000)))
 +  (ORDINARY_MAP_NUMBER_OF_COLUMN_BITS (map)
 + || highest  0x7000)))
  add_map = true;
else
  max_column_hint = set-max_column_hint;
if (add_map)
 

Re: ipa-icf::merge TLC

[Jack Howarth]

On Wed, Feb 25, 2015 at 3:38 AM, Jan Hubicka hubi...@ucw.cz wrote:


 I plan to commit after some further testing tomorrow and having chance
 Martin to look across the changes and discuss 5).

 Honza


Is this still going in today or is there a newer patch to test?
 Jack

Re: [PATCH] libgcc: Don't use unused in gthr-single.h

[Jack Howarth]

This change has already been proposed as part of a more extensive fix
in https://gcc.gnu.org/ml/gcc-patches/2015-02/msg00775.html.

On Sun, Feb 22, 2015 at 9:28 PM, Segher Boessenkool
seg...@kernel.crashing.org wrote:
 Header files shouldn't use identifiers in the application namespace.
 gth-single.h does however; this makes the libstdc++ testsuite
 all_attributes.cc fail for targets without software threads.

 Is this okay for mainline?  And 4.9, 4.8?


 Segher


 2015-02-22  Segher Boessenkool  seg...@kernel.crashing.org

 libgcc/
 * gthr-single.h: Use __unused__ instead of unused.

 ---
  libgcc/gthr-single.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/libgcc/gthr-single.h b/libgcc/gthr-single.h
 index f084fe2..bddded4 100644
 --- a/libgcc/gthr-single.h
 +++ b/libgcc/gthr-single.h
 @@ -38,7 +38,7 @@ typedef int __gthread_recursive_mutex_t;
  #define __GTHREAD_MUTEX_INIT_FUNCTION(mx)
  #define __GTHREAD_RECURSIVE_MUTEX_INIT 0

 -#define UNUSED __attribute__((unused))
 +#define UNUSED __attribute__((__unused__))

  #ifdef _LIBOBJC

 --
 1.8.1.4

Re: [patch] Fix invalid attributes in libstdc++

[Jack Howarth]

On Tue, Feb 3, 2015 at 5:37 AM, Iain Sandoe i...@codesourcery.com wrote:
 Hi Jonathan,

 On 1 Feb 2015, at 15:10, Jonathan Wakely wrote:

 On 01/02/15 15:08 +, Jonathan Wakely wrote:
 I failed to CC gcc-patches on this patch ...

 On 29/01/15 13:02 +, Jonathan Wakely wrote:
 Jakub pointed out that we have some attributes that don't use the
 reserved namespace, e.g. __attribute__ ((always_inline)).

 This is a 4.9/5 regression and the fix was pre-approved by Jakub so
 I've committed it to trunk.

 When we're back in stage1 I'll fix the TODO comments in the new tests
 (see PR64857) and will also rename testsuite/17_intro/headers/c++200x
 to .../c++2011.


 The new test fails on darwin (PR64883) and --enable-threads=single
 targets (PR64885).

 This is a workaround for 64883. Tested x86_64-linux, committed to
 trunk.
 patch.txt

 the following additional tweaks provide further work-arounds.
 ... checked on darwin12 and darwin14.
 I have a fixincludes patch for next stage #1.
 Iain

Ping on https://gcc.gnu.org/ml/gcc-patches/2015-02/msg00122.html

Re: [patch, testsuite] Fix ubsan for testing when libstdc++ isn't installed

[Jack Howarth]

Mike and FX,
 Shouldn't we also apply...

Author: fxcoudert
Date: Mon Dec 22 21:57:45 2014
New Revision: 219035

URL: https://gcc.gnu.org/viewcvs?rev=219035root=gccview=rev
Log:
* lib/ubsan-dg.exp: Add library path for libstdc++.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/lib/ubsan-dg.exp

to gcc-4_9-branch for 4.9.3?

https://gcc.gnu.org/ml/gcc-testresults/2015-02/msg01535.html

shows that we need it.
Jack

On Mon, Dec 22, 2014 at 12:02 PM, Mike Stump mikest...@comcast.net wrote:
 On Dec 20, 2014, at 8:58 AM, FX fxcoud...@gmail.com wrote:
 This patch below allows ubsan to run when libstdc++ is built but not 
 installed (something which happens on darwin, in particular). This fixes all 
 658 ubsan failures when run in this particular configuration.

 OK to commit?

 Ok.

Re: [PATCH][PR tree-optimization/64823] Handle threading through blocks with PHIs, but no statements

[Jack Howarth]

This also breaks the bootstrap on x86_64-apple-darwin14 due to a
similar stage 2/3 comparison failure.

On Fri, Feb 13, 2015 at 6:01 PM, H.J. Lu hjl.to...@gmail.com wrote:
 On Fri, Feb 13, 2015 at 1:11 PM, Jeff Law l...@redhat.com wrote:
 This time with the right patch file.

 commit 48087ce0b383457b5919cbcc2ce1a5e1aaa264c3
 Author: Jeff Law l...@redhat.com
 Date:   Fri Feb 13 14:08:06 2015 -0700

 PR tree-optimization/64823
 * tree-vrp.c (identify_jump_threads): Handle blocks with no
 statements.
 * tree-ssa-threadedge.c (potentially_threadable_block): Allow
 threading through blocks with PHIs, but no statements.
 (thread_through_normal_block): Distinguish between blocks where
 we did not process all the statements and blocks with no statements.

 PR tree-optimization/64823
 gcc.dg/uninit-20.c: New test.


 This caused:

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


 --
 H.J.

Re: [PATCH] PR rtl-optimization/32219: optimizer causees wrong code in pic/hidden/weak symbol checking

[Jack Howarth]

H.J.,
   Oddly I saw no regressions in the g++ test suite at -m32/-m64 on
x86_64-apple-darwin14.
   Jack

On Thu, Feb 12, 2015 at 1:16 PM, H.J. Lu hjl.to...@gmail.com wrote:
 On Wed, Feb 11, 2015 at 10:22 PM, Richard Henderson r...@redhat.com wrote:
 On 02/10/2015 01:19 PM, Richard Henderson wrote:
 As an existing issue, I'm not sure why specified visibility is any 
 different
 from unspecified visibility.  As far as I'm aware, the specified bit 
 simply
 means that the decl doesn't inherit inherit visibility from the class, or 
 from
 the command-line.  But once we're this far, the visibility actually applied 
 to
 the symbol should be all that matters.

 The test is there to differentiate explicit visibility from that implied from
 the command-line.  Without it, we assume hidden visibility for external 
 symbols
 too early, making the command-line option useless.  This is visible even in
 building libgcc.

 I believe this set of patches does what we want, and cleans things up a bit 
 in
 the process.



 I tried them on Linux/x86-64.  They caused:

 FAIL: g++.dg/gomp/tls-wrap4.C  -std=gnu++11  scan-assembler-not _ZTW1i@PLT
 FAIL: g++.dg/gomp/tls-wrap4.C  -std=gnu++11  scan-assembler-not _ZTW1i@PLT
 FAIL: g++.dg/gomp/tls-wrap4.C  -std=gnu++14  scan-assembler-not _ZTW1i@PLT
 FAIL: g++.dg/gomp/tls-wrap4.C  -std=gnu++14  scan-assembler-not _ZTW1i@PLT
 FAIL: g++.dg/tls/thread_local-wrap4.C  -std=gnu++11
 scan-assembler-not _ZTW1i@PLT
 FAIL: g++.dg/tls/thread_local-wrap4.C  -std=gnu++11
 scan-assembler-not _ZTW1i@PLT
 FAIL: g++.dg/tls/thread_local-wrap4.C  -std=gnu++14
 scan-assembler-not _ZTW1i@PLT
 FAIL: g++.dg/tls/thread_local-wrap4.C  -std=gnu++14
 scan-assembler-not _ZTW1i@PLT


 --
 H.J.

Re: [PATCH] PR rtl-optimization/32219: optimizer causees wrong code in pic/hidden/weak symbol checking

[Jack Howarth]

On Thu, Feb 12, 2015 at 2:18 PM, H.J. Lu hjl.to...@gmail.com wrote:
 On Thu, Feb 12, 2015 at 11:16 AM, Jack Howarth howarth.at@gmail.com 
 wrote:
 H.J.,
Oddly I saw no regressions in the g++ test suite at -m32/-m64 on
 x86_64-apple-darwin14.
Jack

 They have

 // { dg-require-effective-target tls }

 Does x86_64-apple-darwin14 support TLS?  If yes, what does the
 generated assembly code look like?

We use emutls on darwin. Those failing test are run at -m32/-m64...

Executing on host:
/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/testsuite/g++/../../xg++
-B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/testsuite/g++/../../
/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150212/gcc/testsuite/g++.dg/gomp/tls-wrap4.C
 -fno-diagnostics-show-caret -fdiagnostics-color=never  -nostdinc++
-I/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin13.4.0/libstdc++-v3/include/x86_64-apple-darwin13.4.0
-I/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin13.4.0/libstdc++-v3/include
-I/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150212/libstdc++-v3/libsupc++
-I/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150212/libstdc++-v3/include/backward
-I/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150212/libstdc++-v3/testsuite/util
-fmessage-length=0  -std=gnu++11 -fPIC  -S  -m64  -o tls-wrap4.s
(timeout = 300)
spawn -ignore SIGHUP
/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/testsuite/g++/../../xg++
-B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/testsuite/g++/../../
/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150212/gcc/testsuite/g++.dg/gomp/tls-wrap4.C
-fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++
-I/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin13.4.0/libstdc++-v3/include/x86_64-apple-darwin13.4.0
-I/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin13.4.0/libstdc++-v3/include
-I/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150212/libstdc++-v3/libsupc++
-I/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150212/libstdc++-v3/include/backward
-I/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150212/libstdc++-v3/testsuite/util
-fmessage-length=0 -std=gnu++11 -fPIC -S -m64 -o tls-wrap4.s^M
PASS: g++.dg/gomp/tls-wrap4.C  -std=gnu++11 (test for excess errors)
PASS: g++.dg/gomp/tls-wrap4.C  -std=gnu++11  scan-assembler-not _ZTW1i@PLT

and produce the attached assembly.
Jack


 On Thu, Feb 12, 2015 at 1:16 PM, H.J. Lu hjl.to...@gmail.com wrote:
 On Wed, Feb 11, 2015 at 10:22 PM, Richard Henderson r...@redhat.com wrote:
 On 02/10/2015 01:19 PM, Richard Henderson wrote:
 As an existing issue, I'm not sure why specified visibility is any 
 different
 from unspecified visibility.  As far as I'm aware, the specified bit 
 simply
 means that the decl doesn't inherit inherit visibility from the class, or 
 from
 the command-line.  But once we're this far, the visibility actually 
 applied to
 the symbol should be all that matters.

 The test is there to differentiate explicit visibility from that implied 
 from
 the command-line.  Without it, we assume hidden visibility for external 
 symbols
 too early, making the command-line option useless.  This is visible even in
 building libgcc.

 I believe this set of patches does what we want, and cleans things up a 
 bit in
 the process.



 I tried them on Linux/x86-64.  They caused:

 FAIL: g++.dg/gomp/tls-wrap4.C  -std=gnu++11  scan-assembler-not _ZTW1i@PLT
 FAIL: g++.dg/gomp/tls-wrap4.C  -std=gnu++11  scan-assembler-not _ZTW1i@PLT
 FAIL: g++.dg/gomp/tls-wrap4.C  -std=gnu++14  scan-assembler-not _ZTW1i@PLT
 FAIL: g++.dg/gomp/tls-wrap4.C  -std=gnu++14  scan-assembler-not _ZTW1i@PLT
 FAIL: g++.dg/tls/thread_local-wrap4.C  -std=gnu++11
 scan-assembler-not _ZTW1i@PLT
 FAIL: g++.dg/tls/thread_local-wrap4.C  -std=gnu++11
 scan-assembler-not _ZTW1i@PLT
 FAIL: g++.dg/tls/thread_local-wrap4.C  -std=gnu++14
 scan-assembler-not _ZTW1i@PLT
 FAIL: g++.dg/tls/thread_local-wrap4.C  -std=gnu++14
 scan-assembler-not _ZTW1i@PLT


 --
 H.J.



 --
 H.J.


tls-wrap4.s
Description: Binary data

Re: [PATCH] PR rtl-optimization/32219: optimizer causes wrong code in pic/hidden/weak symbol checking

[Jack Howarth]

Richard,
  Your proposed patch fails to bootstrap here on
x86_64-apple-darwin14 against the system clang compilers...

g++ -c   -g  -DIN_GCC-fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-format -Wmissing-format-attribute
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I. -I.
-I../../gcc-5-20150211/gcc -I../../gcc-5-20150211/gcc/.
-I../../gcc-5-20150211/gcc/../include
-I../../gcc-5-20150211/gcc/../libcpp/include -I/sw/include
-I/sw/include  -I../../gcc-5-20150211/gcc/../libdecnumber
-I../../gcc-5-20150211/gcc/../libdecnumber/dpd -I../libdecnumber
-I../../gcc-5-20150211/gcc/../libbacktrace -I/sw/include -I/sw/include
-o varasm.o -MT varasm.o -MMD -MP -MF ./.deps/varasm.TPo
../../gcc-5-20150211/gcc/varasm.c
...
../../gcc-5-20150211/gcc/varasm.c:6899:9: error: use of undeclared
identifier 'resolution_to_local_definition_p'
return resolution_to_local_definition_p (vnode-resolution);
   ^
../../gcc-5-20150211/gcc/varasm.c:6906:9: error: use of undeclared
identifier 'resolution_to_local_definition_p'
return resolution_to_local_definition_p (node-resolution);
   ^
Jack


On Tue, Feb 10, 2015 at 4:19 PM, Richard Henderson r...@redhat.com wrote:
 On 02/07/2015 08:45 AM, H.J. Lu wrote:
 Here is an updated patch.

 This is an annoying comment to differentiate 3 different versions, FYI.

 @@ -6826,11 +6817,18 @@ default_binds_local_p_1 (const_tree exp, int shlib)
 (TREE_STATIC (exp) || DECL_EXTERNAL (exp)))
  {
varpool_node *vnode = varpool_node::get (exp);
 -  if (vnode  (resolution_local_p (vnode-resolution) || 
 vnode-in_other_partition))
 - resolved_locally = true;
 -  if (vnode
 -resolution_to_local_definition_p (vnode-resolution))
 - resolved_to_local_def = true;
 +  /* If not building shared library, common or initialized symbols
 +  are also resolved locally, regardless they are weak or not if
 +  weak_dominate is true.  */
 +  if (vnode)
 + {
 +   if ((weak_dominate  !shlib  vnode-definition)
 +   || vnode-in_other_partition
 +   || resolution_local_p (vnode-resolution))
 + resolved_locally = true;
 +   if (resolution_to_local_definition_p (vnode-resolution))
 + resolved_to_local_def = true;
 + }
  }
else if (TREE_CODE (exp) == FUNCTION_DECL  TREE_PUBLIC (exp))
  {

 Not the same test for a function_decl?  That's certainly a mistake.

 Indeed, I believe we can now unify these two cases by using the base
 symtab_node instead of varpool_node and cgraph_node.

 I'm a bit confused about why we have both resolved_to_local_def vs
 resolved_locally.  At least within this function, which only cares about 
 module
 locality rather than object file locality.  Honza?

 @@ -6859,9 +6857,15 @@ default_binds_local_p_1 (const_tree exp, int shlib)
else if (! TREE_PUBLIC (exp))
  local_p = true;
/* A variable is local if the user has said explicitly that it will
 - be.  */
 + be and it is resolved or defined locally, not compiling for PIC,
 + not weak or weak_dominate is false.  */
else if ((DECL_VISIBILITY_SPECIFIED (exp)
   || resolved_to_local_def)
 + (!weak_dominate
 +|| resolved_locally
 +|| !flag_pic
 +|| !DECL_EXTERNAL (exp)
 +|| !DECL_WEAK (exp))
   DECL_VISIBILITY (exp) != VISIBILITY_DEFAULT)
  local_p = true;

 I think this test is conflating several issues, and as such it's very 
 confusing.

 As an existing issue, I'm not sure why specified visibility is any different
 from unspecified visibility.  As far as I'm aware, the specified bit simply
 means that the decl doesn't inherit inherit visibility from the class, or from
 the command-line.  But once we're this far, the visibility actually applied to
 the symbol should be all that matters.

 Unfortunately, this test is 11 years old, from r85167.  It came in as part of
 the implementation of the visibility attribute for the class.

 I believe the next test should be

   else if (DECL_WEAK (exp)  !resolved_locally)
 local_p = false;

 Given the change above, resolved_locally will now be true for (weak  defined
  weak_dominate), and therefore we need not reiterate that test.

 I believe the next test should be dictated by normal non-lto usage like

   extern void bar(void) __attribute__((visibility(hidden)));
   void foo(void) { ... bar(); ...)

 where the user is expecting that the function call make use of a simpler
 instruction sequence, probably avoiding an PLT.  Therefore

   else if (DECL_VISIBILITY (exp) != VISIBILITY_DEFAULT)
 local_p = true;

 Since we have already excluded undef-weak, we know that any symbol here is
 either defined or strong, and non-default visibility must resolve it locally.

/* Variables defined outside this object 

Re: [PATCH] PR rtl-optimization/32219: optimizer causes wrong code in pic/hidden/weak symbol checking

[Jack Howarth]

Mike,
  Actually there aren't really any darwin bits in the current patch...

https://gcc.gnu.org/ml/gcc-patches/2015-02/msg00468.html

short of the dg-skip-if adjustments for the unsupported targets.
   Jack
ps I wonder if this final patch needs be reposted to gcc-patches as...

[PATCH][Revised] PR rtl-optimization/32219: optimizer causes wrong
code in pic/hidden/weak symbol checking

to make sure it gets the visibility for a review.


On Mon, Feb 9, 2015 at 12:25 PM, Mike Stump mikest...@comcast.net wrote:
 On Feb 8, 2015, at 10:24 AM, Jack Howarth howarth.at@gmail.com wrote:
   This last version of the patch bootstraps and passes the test suite
 without regressions on x86_64-apple-darwin14.

 Ok for the darwin bits.

Re: [PATCH] Fix PR64764 Fix scan-tree-dump for scop-19.c

[Jack Howarth]

Tom,
  At -m32 on x86_64-apple-darwin14, the failing test case executes...

% /sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/
/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150209/gcc/testsuite/gcc.dg/uninit-19.c
 -fno-diagnostics-show-caret -fdiagnostics-color=never   -O
-Wuninitialized -S  -m32  -o uninit-19.s
/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150209/gcc/testsuite/gcc.dg/uninit-19.c:
In function ‘fn2’:
/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150209/gcc/testsuite/gcc.dg/uninit-19.c:13:15:
warning: ‘n’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150209/gcc/testsuite/gcc.dg/uninit-19.c:19:10:
note: ‘n’ was declared here

which following the following preprocessed source.

# 1 
/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150209/gcc/testsuite/gcc.dg/uninit-19.c
# 1 built-in
# 1 command-line
# 1 
/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150209/gcc/testsuite/gcc.dg/uninit-19.c



int a, l, m;
float *b;
float c, d, e, g, h;
unsigned char i, k;
void
fn1 (int p1, float *f1, float *f2, float *f3, unsigned char *c1, float *f4,
 unsigned char *c2, float *p10)
{
  if (p1  8)
b[3] = p10[a];
}

void
fn2 ()
{
  float *n;
  if (l  6)
n = c + m;
  fn1 (l, d, e, g, i, h, k, n);
}

Does that help?
Jack

On Tue, Feb 10, 2015 at 6:42 AM, Tom de Vries tom_devr...@mentor.com wrote:
 On 09-02-15 20:01, Dominique d'Humières wrote:


 Le 9 févr. 2015 à 19:10, Tom de Vries tom_devr...@mentor.com
 mailto:tom_devr...@mentor.com a écrit :


 On 09-02-15 18:23, Dominique Dhumieres wrote:

 Tom,

 After these changes I have the following regressions on
 x86_64-apple-darwin1[04]*:

 FAIL: gcc.dg/uninit-19.c  (test for warnings, line 22)
 FAIL: gcc.dg/uninit-19.c (test for excess errors)
 FAIL: gcc.dg/graphite/scop-19.c scan-tree-dump-times graphite number of
 SCoPs: 0 1

 I can prepare and test a fix for darwin unless you beat me!


 Dominique,

 thanks for finding this.

 I don't understand why this breaks. Why is fpic supposed to be different
 for
 darwin?


 I don’t either, but the tests succeeds on darwin with the following patch

 --- ../_clean/gcc/testsuite/gcc.dg/uninit-19.c2015-02-09
 11:38:40.0 +0100
 +++ gcc/testsuite/gcc.dg/uninit-19.c2015-02-09 19:52:26.0 +0100
 @@ -22,5 +22,5 @@ fn2 ()
 fn1 (l, d, e, g, i, h, k, n);  /* 22.  */
   }


 -/* { dg-warning may be used uninitialized  { target nonpic } 13 } */
 -/* { dg-warning may be used uninitialized  { target { ! nonpic } } 22
 } */
 +/* { dg-warning may be used uninitialized  { target { nonpic ||
 x86_64-apple-darwin1[0-9]* } } 13 } */
 +/* { dg-warning may be used uninitialized  { target { ! { nonpic ||
 x86_64-apple-darwin1[0-9]* } } } 22 } */
 --- ../_clean/gcc/testsuite/gcc.dg/graphite/scop-19.c2015-02-09
 11:38:40.0 +0100
 +++ gcc/testsuite/gcc.dg/graphite/scop-19.c2015-02-09 19:55:38.0
 +0100
 @@ -31,7 +31,7 @@ d_growable_string_append_buffer (struct
 if (need  dgs-alc)
   d_growable_string_resize (dgs, need);
   }
 -/* { dg-final { scan-tree-dump-times number of SCoPs: 0 2 graphite {
 target
 nonpic } } } */
 -/* { dg-final { scan-tree-dump-times number of SCoPs: 0 1 graphite {
 target
 { ! nonpic } } } } */
 +/* { dg-final { scan-tree-dump-times number of SCoPs: 0 2 graphite {
 target
 { nonpic || x86_64-apple-darwin1[0-9]* } } } } */
 +/* { dg-final { scan-tree-dump-times number of SCoPs: 0 1 graphite {
 target
 { ! { nonpic || x86_64-apple-darwin1[0-9]* } } } } } */
   /* { dg-final { cleanup-tree-dump graphite } } */


 I think we need to understand first what's going on.

 In both test-cases, on Linux with -fpic the inlining of one function into
 the other is not done, because we cannot be sure the function call in one
 function binds to the other function at runtime.

 So, is the inlining happening with -fpic for Darwin? If so, is that correct?

 Thanks,
 - Tom

Re: Fix PR 63566 part 3

[Jack Howarth]

Jan,
 This patch caused Bug 64982 - [5 Regression] Many g++ failures on
x86_64-apple-darwin14 with -m32.
   Jack

On Sun, Feb 8, 2015 at 3:20 PM, Jan Hubicka hubi...@ucw.cz wrote:
 Hi,
 this patch makes i386.c ready for presence of aliases of local functions, but
 also fixes a wrong code issue where ix86_function_sseregparm
 does use caller TARET_SSE_MATH flags instead of callees.  If callee disagree
 on this flag, it may get called with wrong calling convention.

 I added error message on calling local function with SSE ABI from function
 compiled with SSE disabled.  We may work harder to simply disable SSE calling
 convention but that requires whole compilation unit analysis that is hard
 to do on ltrans. I hope it does not matter in practice. Otherwise we may want
 to introduce some hook and disqualify such functions from being local
 at WPA time.

 Bootstrapped/regtested x86_64-linux (includin 32bit testing), will commit it
 shortly.

 Honza

 PR ipa/63566
 * i386.c (ix86_function_regparm): Look through aliases to see if 
 callee
 is local and optimized.
 (ix86_function_sseregparm): Likewise; also use target's SSE math
 settings; error out instead of silently generating wrong code
 on mismatches.
 (init_cumulative_args): Look through aliases.

 Index: config/i386/i386.c
 ===
 --- config/i386/i386.c  (revision 220509)
 +++ config/i386/i386.c  (working copy)
 @@ -5767,49 +5767,55 @@ ix86_function_regparm (const_tree type,

/* Use register calling convention for local functions when possible.  */
if (decl
 -   TREE_CODE (decl) == FUNCTION_DECL
 +   TREE_CODE (decl) == FUNCTION_DECL)
 +{
 +  cgraph_node *target = cgraph_node::get (decl);
 +  if (target)
 +   target = target-function_symbol ();
 +
/* Caller and callee must agree on the calling convention, so
  checking here just optimize means that with
  __attribute__((optimize (...))) caller could use regparm convention
  and callee not, or vice versa.  Instead look at whether the callee
  is optimized or not.  */
 -   opt_for_fn (decl, optimize)
 -   !(profile_flag  !flag_fentry))
 -{
 -  /* FIXME: remove this CONST_CAST when cgraph.[ch] is constified.  */
 -  cgraph_local_info *i = cgraph_node::local_info (CONST_CAST_TREE 
 (decl));
 -  if (i  i-local  i-can_change_signature)
 +  if (target  opt_for_fn (target-decl, optimize)
 +  !(profile_flag  !flag_fentry))
 {
 - int local_regparm, globals = 0, regno;
 + cgraph_local_info *i = target-local;
 + if (i  i-local  i-can_change_signature)
 +   {
 + int local_regparm, globals = 0, regno;

 - /* Make sure no regparm register is taken by a
 -fixed register variable.  */
 - for (local_regparm = 0; local_regparm  REGPARM_MAX; 
 local_regparm++)
 -   if (fixed_regs[local_regparm])
 - break;
 -
 - /* We don't want to use regparm(3) for nested functions as
 -these use a static chain pointer in the third argument.  */
 - if (local_regparm == 3  DECL_STATIC_CHAIN (decl))
 -   local_regparm = 2;
 -
 - /* In 32-bit mode save a register for the split stack.  */
 - if (!TARGET_64BIT  local_regparm == 3  flag_split_stack)
 -   local_regparm = 2;
 -
 - /* Each fixed register usage increases register pressure,
 -so less registers should be used for argument passing.
 -This functionality can be overriden by an explicit
 -regparm value.  */
 - for (regno = AX_REG; regno = DI_REG; regno++)
 -   if (fixed_regs[regno])
 - globals++;
 + /* Make sure no regparm register is taken by a
 +fixed register variable.  */
 + for (local_regparm = 0; local_regparm  REGPARM_MAX;
 +  local_regparm++)
 +   if (fixed_regs[local_regparm])
 + break;
 +
 + /* We don't want to use regparm(3) for nested functions as
 +these use a static chain pointer in the third argument.  */
 + if (local_regparm == 3  DECL_STATIC_CHAIN (target-decl))
 +   local_regparm = 2;
 +
 + /* Save a register for the split stack.  */
 + if (local_regparm == 3  flag_split_stack)
 +   local_regparm = 2;
 +
 + /* Each fixed register usage increases register pressure,
 +so less registers should be used for argument passing.
 +This functionality can be overriden by an explicit
 +regparm value.  */
 + for (regno = AX_REG; regno = DI_REG; regno++)
 +   if (fixed_regs[regno])
 + globals++;

 - local_regparm
 -   = globals  

Re: [PATCH] Fix PR64764 Fix scan-tree-dump for scop-19.c

[Jack Howarth]

This appears to be the first instance where 'target' and 'nonpic' have
been used in a dg-warning.

On Mon, Feb 9, 2015 at 2:40 PM, Dominique d'Humières domi...@lps.ens.fr wrote:

 Le 9 févr. 2015 à 20:01, Dominique d'Humières domi...@lps.ens.fr a écrit :


 Le 9 févr. 2015 à 19:10, Tom de Vries tom_devr...@mentor.com a écrit :

 On 09-02-15 18:23, Dominique Dhumieres wrote:
 Tom,

 After these changes I have the following regressions on 
 x86_64-apple-darwin1[04]*:

 FAIL: gcc.dg/uninit-19.c  (test for warnings, line 22)
 FAIL: gcc.dg/uninit-19.c (test for excess errors)
 FAIL: gcc.dg/graphite/scop-19.c scan-tree-dump-times graphite number of 
 SCoPs: 0 1

 I can prepare and test a fix for darwin unless you beat me!


 Dominique,

 thanks for finding this.

 I don't understand why this breaks. Why is fpic supposed to be different 
 for darwin?

 I don’t either, but the tests succeeds on darwin with the following patch

 --- ../_clean/gcc/testsuite/gcc.dg/uninit-19.c2015-02-09 
 11:38:40.0 +0100
 +++ gcc/testsuite/gcc.dg/uninit-19.c  2015-02-09 19:52:26.0 +0100
 @@ -22,5 +22,5 @@ fn2 ()
fn1 (l, d, e, g, i, h, k, n);  /* 22.  */
  }

 -/* { dg-warning may be used uninitialized  { target nonpic } 13 } */
 -/* { dg-warning may be used uninitialized  { target { ! nonpic } } 22 } 
 */
 +/* { dg-warning may be used uninitialized  { target { nonpic || 
 x86_64-apple-darwin1[0-9]* } } 13 } */
 +/* { dg-warning may be used uninitialized  { target { ! { nonpic || 
 x86_64-apple-darwin1[0-9]* } } } 22 } */
 --- ../_clean/gcc/testsuite/gcc.dg/graphite/scop-19.c 2015-02-09 
 11:38:40.0 +0100
 +++ gcc/testsuite/gcc.dg/graphite/scop-19.c   2015-02-09 19:55:38.0 
 +0100
 @@ -31,7 +31,7 @@ d_growable_string_append_buffer (struct
if (need  dgs-alc)
  d_growable_string_resize (dgs, need);
  }
 -/* { dg-final { scan-tree-dump-times number of SCoPs: 0 2 graphite { 
 target nonpic } } } */
 -/* { dg-final { scan-tree-dump-times number of SCoPs: 0 1 graphite { 
 target { ! nonpic } } } } */
 +/* { dg-final { scan-tree-dump-times number of SCoPs: 0 2 graphite { 
 target { nonpic || x86_64-apple-darwin1[0-9]* } } } } */
 +/* { dg-final { scan-tree-dump-times number of SCoPs: 0 1 graphite { 
 target { ! { nonpic || x86_64-apple-darwin1[0-9]* } } } } } */
  /* { dg-final { cleanup-tree-dump graphite } } */

 Cheers,

 Dominique

 Thanks,
 - Tom

Re: [PATCH] Fix PR64764 Fix scan-tree-dump for scop-19.c

[Jack Howarth]

Also, aren't we pretty much the only target to default to PIC? So if
the 'target' and 'nonpic'  testing is failing when used in the context
of dg-warning, wouldn't that appear functional on the nonpic targets?
That is, since the nonpic test is to check for __PIC__, if that fails
in dg-warning, wouldn't it 'appear' functional on nonpic targets, no?

On Mon, Feb 9, 2015 at 3:51 PM, Jack Howarth howarth.at@gmail.com wrote:
 This appears to be the first instance where 'target' and 'nonpic' have
 been used in a dg-warning.

 On Mon, Feb 9, 2015 at 2:40 PM, Dominique d'Humières domi...@lps.ens.fr 
 wrote:

 Le 9 févr. 2015 à 20:01, Dominique d'Humières domi...@lps.ens.fr a écrit :


 Le 9 févr. 2015 à 19:10, Tom de Vries tom_devr...@mentor.com a écrit :

 On 09-02-15 18:23, Dominique Dhumieres wrote:
 Tom,

 After these changes I have the following regressions on 
 x86_64-apple-darwin1[04]*:

 FAIL: gcc.dg/uninit-19.c  (test for warnings, line 22)
 FAIL: gcc.dg/uninit-19.c (test for excess errors)
 FAIL: gcc.dg/graphite/scop-19.c scan-tree-dump-times graphite number of 
 SCoPs: 0 1

 I can prepare and test a fix for darwin unless you beat me!


 Dominique,

 thanks for finding this.

 I don't understand why this breaks. Why is fpic supposed to be different 
 for darwin?

 I don’t either, but the tests succeeds on darwin with the following patch

 --- ../_clean/gcc/testsuite/gcc.dg/uninit-19.c2015-02-09 
 11:38:40.0 +0100
 +++ gcc/testsuite/gcc.dg/uninit-19.c  2015-02-09 19:52:26.0 +0100
 @@ -22,5 +22,5 @@ fn2 ()
fn1 (l, d, e, g, i, h, k, n);  /* 22.  */
  }

 -/* { dg-warning may be used uninitialized  { target nonpic } 13 } */
 -/* { dg-warning may be used uninitialized  { target { ! nonpic } } 22 
 } */
 +/* { dg-warning may be used uninitialized  { target { nonpic || 
 x86_64-apple-darwin1[0-9]* } } 13 } */
 +/* { dg-warning may be used uninitialized  { target { ! { nonpic || 
 x86_64-apple-darwin1[0-9]* } } } 22 } */
 --- ../_clean/gcc/testsuite/gcc.dg/graphite/scop-19.c 2015-02-09 
 11:38:40.0 +0100
 +++ gcc/testsuite/gcc.dg/graphite/scop-19.c   2015-02-09 19:55:38.0 
 +0100
 @@ -31,7 +31,7 @@ d_growable_string_append_buffer (struct
if (need  dgs-alc)
  d_growable_string_resize (dgs, need);
  }
 -/* { dg-final { scan-tree-dump-times number of SCoPs: 0 2 graphite { 
 target nonpic } } } */
 -/* { dg-final { scan-tree-dump-times number of SCoPs: 0 1 graphite { 
 target { ! nonpic } } } } */
 +/* { dg-final { scan-tree-dump-times number of SCoPs: 0 2 graphite { 
 target { nonpic || x86_64-apple-darwin1[0-9]* } } } } */
 +/* { dg-final { scan-tree-dump-times number of SCoPs: 0 1 graphite { 
 target { ! { nonpic || x86_64-apple-darwin1[0-9]* } } } } } */
  /* { dg-final { cleanup-tree-dump graphite } } */

 Cheers,

 Dominique

 Thanks,
 - Tom

Re: [PATCH] PR rtl-optimization/32219: optimizer causes wrong code in pic/hidden/weak symbol checking

[Jack Howarth]

H.J.,
   This last version of the patch bootstraps and passes the test suite
without regressions on x86_64-apple-darwin14.

https://gcc.gnu.org/ml/gcc-testresults/2015-02/msg00912.html

Thanks for fixing this.
   Jack

On Sat, Feb 7, 2015 at 11:45 AM, H.J. Lu hjl.to...@gmail.com wrote:
 On Sat, Feb 07, 2015 at 07:56:06AM -0800, H.J. Lu wrote:
 On Sat, Feb 07, 2015 at 10:11:01AM -0500, Jack Howarth wrote:
  H.J,,
  Unfortunately, the answer is yes. This patch still introduces
  regressions in the g++ test suite.l These are all some form of...
 

 It looks like Darwin depends on the old behavior of
 default_binds_local_p_1.  Please try this patch.


 Here is an updated patch.


 H.J.
 From d010cd1ddf866f8e10fe7ad2cf483b5a872bc6ea Mon Sep 17 00:00:00 2001
 From: H.J. Lu hjl.to...@gmail.com
 Date: Thu, 5 Feb 2015 14:28:58 -0800
 Subject: [PATCH] Handle symbol visibility/locality for PIE/PIC

 If a hidden weak symbol isn't defined in the TU, we can't assume it will
 be defined in another TU at link time.  It makes a difference in code
 generation when compiling for PIC. If we assume that a hidden weak
 undefined symbol is local, the address checking may be optimized out and
 leads to the wrong code.  This means that a symbol with user specified
 visibility is local only if it is locally resolved or defined, not weak
 or not compiling for PIC.  When symbol visibility is specified in the
 source, we should always output symbol visibility even if symbol isn't
 local to the TU.

 If a global data symbol is defined in the TU, it is always local to the
 executable, regardless if it is a common symbol or not.  If we aren't
 compiling for shared library, locally defined global data symbol binds
 locally.

 Since some targets call default_binds_local_p_1 directly and depend on
 the old behavior of default_binds_local_p_1.  This patch renames
 default_binds_local_p_1 to default_binds_local_p_2 and implements the
 new behavior in default_binds_local_p_2 controlled by a variable.
 The old behavior remains with default_binds_local_p_1.

 gcc/

 PR rtl-optimization/32219
 * cgraphunit.c (varpool_node::finalize_decl): Set definition
 first before calling notice_global_symbol so that it is
 available to notice_global_symbol.
 * varasm.c (default_binds_local_p_1): Renamed to ...
 (default_binds_local_p_2): This.  Resolve defined data symbol
 locally if not building shared library.  Resolve symbol with
 user specified visibility locally only if it is locally resolved
 or defined, not weak or not compiling for PIC.
 (default_binds_local_p): Replace default_binds_local_p_1 with
 default_binds_local_p_2.
 (default_binds_local_p_1): Call default_binds_local_p_2.
 (default_elf_asm_output_external): Always output visibility
 specified in the source.

 gcc/testsuite/

 PR rtl-optimization/32219
 * gcc.dg/visibility-22.c: New test.
 * gcc.dg/visibility-23.c: Likewise.
 * gcc.target/i386/pr32219-1.c: Likewise.
 * gcc.target/i386/pr32219-2.c: Likewise.
 * gcc.target/i386/pr32219-3.c: Likewise.
 * gcc.target/i386/pr32219-4.c: Likewise.
 * gcc.target/i386/pr32219-5.c: Likewise.
 * gcc.target/i386/pr32219-6.c: Likewise.
 * gcc.target/i386/pr32219-7.c: Likewise.
 * gcc.target/i386/pr32219-8.c: Likewise.
 * gcc.target/i386/pr64317.c: Expect GOTOFF relocation instead
 of GOT relocation.
 ---
  gcc/cgraphunit.c  |  4 +-
  gcc/testsuite/gcc.dg/visibility-22.c  | 17 +
  gcc/testsuite/gcc.dg/visibility-23.c  | 15 
  gcc/testsuite/gcc.target/i386/pr32219-1.c | 16 
  gcc/testsuite/gcc.target/i386/pr32219-2.c | 16 
  gcc/testsuite/gcc.target/i386/pr32219-3.c | 17 +
  gcc/testsuite/gcc.target/i386/pr32219-4.c | 17 +
  gcc/testsuite/gcc.target/i386/pr32219-5.c | 16 
  gcc/testsuite/gcc.target/i386/pr32219-6.c | 16 
  gcc/testsuite/gcc.target/i386/pr32219-7.c | 17 +
  gcc/testsuite/gcc.target/i386/pr32219-8.c | 17 +
  gcc/testsuite/gcc.target/i386/pr64317.c   |  2 +-
  gcc/varasm.c  | 61 
 +--
  13 files changed, 209 insertions(+), 22 deletions(-)
  create mode 100644 gcc/testsuite/gcc.dg/visibility-22.c
  create mode 100644 gcc/testsuite/gcc.dg/visibility-23.c
  create mode 100644 gcc/testsuite/gcc.target/i386/pr32219-1.c
  create mode 100644 gcc/testsuite/gcc.target/i386/pr32219-2.c
  create mode 100644 gcc/testsuite/gcc.target/i386/pr32219-3.c
  create mode 100644 gcc/testsuite/gcc.target/i386/pr32219-4.c
  create mode 100644 gcc/testsuite/gcc.target/i386/pr32219-5.c
  create mode 100644 gcc/testsuite/gcc.target/i386/pr32219-6.c
  create mode 100644 gcc/testsuite/gcc.target/i386/pr32219-7.c
  create mode 100644 gcc/testsuite/gcc.target/i386/pr32219-8.c

 diff

Re: [PATCH] PR rtl-optimization/32219: optimizer causes wrong code in pic/hidden/weak symbol checking

[Jack Howarth]

H.J.,
 The new patch bootstraps okay on x86_64-apple-darwin14 but I
discovered that you need a small adjustment in the deja-gnu
statements...

 --- /Users/howarth/gcc-5-20150206/gcc/testsuite/gcc.dg/visibility-22.c
2015-02-06 21:45:04.0 -0500
+++ 
/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150206/gcc/testsuite/gcc.dg/visibility-22.c
2015-02-07 03:24:42.0 -0500
@@ -8,9 +8,9 @@
 /* For kernel modules and static RTPs, the loader treats undefined weak
symbols in the same way as undefined strong symbols.  The test
therefore fails to load, so skip it.  */
+/* { dg-options -fPIC { target fpic } } */
 /* { dg-additional-options -Wl,-undefined,dynamic_lookup { target
*-*-darwin* } } */
 /* { dg-additional-options -Wl,-flat_namespace { target
*-*-darwin[89]* } } */
-/* { dg-options -fPIC { target fpic } } */

 extern void foo () __attribute__((weak,visibility(hidden)));
 int

If you don't define a dg-options line first, the dg-additional-options
lines have no effect.
 Jack

On Fri, Feb 6, 2015 at 8:55 PM, H.J. Lu hjl.to...@gmail.com wrote:
 On Fri, Feb 6, 2015 at 5:51 PM, Jack Howarth howarth.at@gmail.com wrote:
 H.J.,
  This patch also seems to be causing a huge number of regressions
 in the g++ test suite due to linkage warnings on darwin of the form...

 ld: warning: direct access in Model::~Model() to global weak symbol
 vtable for Model means the weak symbol cannot be overridden at
 runtime. This was likely caused by different translation units being
 compiled with different visibility settings.

 Can you try my new patch?

 Can this change wait until stage1?
 Jack

 On Fri, Feb 6, 2015 at 4:41 PM, H.J. Lu hjl.to...@gmail.com wrote:
 On Fri, Feb 6, 2015 at 1:31 PM, Jack Howarth howarth.at@gmail.com 
 wrote:
 H.J.,
 On x86_64-apple-darwin14, your patch applied to r220481 results in...

 FAIL: gcc.dg/visibility-22.c (test for excess errors)
 FAIL: gcc.dg/visibility-23.c scan-hidden private_extern[ \t_]*_?foo

 with...

 Executing on host:
 /sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/xgcc
 -B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/
 /sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150206/gcc/testsuite/gcc.dg/visibility-22.c
  -fno-diagnostics-show-caret -fdiagnostics-color=never   -fPIC  -lm
 -m32  -o ./visibility-22.exe(timeout = 300)
 spawn -ignore SIGHUP
 /sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/xgcc
 -B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/
 /sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150206/gcc/testsuite/gcc.dg/visibility-22.c
 -fno-diagnostics-show-caret -fdiagnostics-color=never -fPIC -lm -m32
 -o ./visibility-22.exe^M
 Undefined symbols for architecture i386:^M
   _foo, referenced from:^M
   _main in ccMD1qjz.o^M
   _main in ccMD1qjz.o^M
 ld: symbol(s) not found for architecture i386^M
 collect2: error: ld returned 1 exit status^M
 compiler exited with status 1
 output is:
 Undefined symbols for architecture i386:^M
   _foo, referenced from:^M
   _main in ccMD1qjz.o^M
   _main in ccMD1qjz.o^M
 ld: symbol(s) not found for architecture i386^M
 collect2: error: ld returned 1 exit status^M

 FAIL: gcc.dg/visibility-22.c (test for excess errors)

 Executing on host:
 /sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/xgcc
 -B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/
 /sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150206/gcc/testsuite/gcc.dg/visibility-23.c
  -fno-diagnostics-show-caret -fdiagnostics-color=never   -fPIC -S
 -m32  -o visibility-23.s(timeout = 300)
 spawn -ignore SIGHUP
 /sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/xgcc
 -B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/
 /sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150206/gcc/testsuite/gcc.dg/visibility-23.c
 -fno-diagnostics-show-caret -fdiagnostics-color=never -fPIC -S -m32 -o
 visibility-23.s^M
 PASS: gcc.dg/visibility-23.c (test for excess errors)
 FAIL: gcc.dg/visibility-23.c scan-hidden private_extern[ \t_]*_?foo


 Does Darwin support undefined hidden weak symbol?
 Can you compile and gcc/testsuite/gcc.dg/visibility-22.c
 with clang on Darwin?

 --
 H.J.



 --
 H.J.

Re: [PATCH] PR rtl-optimization/32219: optimizer causes wrong code in pic/hidden/weak symbol checking

[Jack Howarth]

 visibility settings.^M
ld: warning: direct access in S5::S5()to global weak symbol vtable
for S5 means the weak symbol cannot be overridden at runtime. This was
likely caused by different translation units being compiled with
different visibility settings.^M
ld: warning: direct access in S5::S5()to global weak symbol VTT
for S5 means the weak symbol cannot be overridden at runtime. This was
likely caused by different translation units being compiled with
different visibility settings.^M
ld: warning: direct access in S5::S5()to global weak symbol VTT
for S5 means the weak symbol cannot be overridden at runtime. This was
likely caused by different translation units being compiled with
different visibility settings.^M
ld: warning: direct access in S8::S8()to global weak symbol vtable
for S8 means the weak symbol cannot be overridden at runtime. This was
likely caused by different translation units being compiled with
different visibility settings.^M


FAIL: g++.dg/abi/empty7.C  -std=gnu++98 (test for excess errors)

Darwin has really twitchy support weak symbol support so any major
rewrite will definitely be stage 1 material and likely require us to
contact the darwin linker developer at Apple for a consultation on the
meaning of these linker warnings.
Jack



On Sat, Feb 7, 2015 at 7:27 AM, H.J. Lu hjl.to...@gmail.com wrote:
 On Sat, Feb 07, 2015 at 03:28:38AM -0500, Jack Howarth wrote:
 H.J.,
  The new patch bootstraps okay on x86_64-apple-darwin14 but I

 Does it cause any regressions on x86_64-apple-darwin14?

 discovered that you need a small adjustment in the deja-gnu
 statements...

  --- /Users/howarth/gcc-5-20150206/gcc/testsuite/gcc.dg/visibility-22.c
 2015-02-06 21:45:04.0 -0500
 +++ 
 /sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150206/gcc/testsuite/gcc.dg/visibility-22.c
 2015-02-07 03:24:42.0 -0500
 @@ -8,9 +8,9 @@
  /* For kernel modules and static RTPs, the loader treats undefined weak
 symbols in the same way as undefined strong symbols.  The test
 therefore fails to load, so skip it.  */
 +/* { dg-options -fPIC { target fpic } } */
  /* { dg-additional-options -Wl,-undefined,dynamic_lookup { target
 *-*-darwin* } } */
  /* { dg-additional-options -Wl,-flat_namespace { target
 *-*-darwin[89]* } } */
 -/* { dg-options -fPIC { target fpic } } */

  extern void foo () __attribute__((weak,visibility(hidden)));
  int

 If you don't define a dg-options line first, the dg-additional-options
 lines have no effect.
  Jack

 Here is the updated patch.

 H.J.
 ---
 From 8e61705db8177d41fac45dbeffa4faf6163d4c94 Mon Sep 17 00:00:00 2001
 From: H.J. Lu hjl.to...@gmail.com
 Date: Thu, 5 Feb 2015 14:28:58 -0800
 Subject: [PATCH] Handle symbol visibility/locality for PIE/PIC

 If a hidden weak symbol isn't defined in the TU, we can't assume it will
 be defined in another TU at link time.  It makes a difference in code
 generation when compiling for PIC. If we assume that a hidden weak
 undefined symbol is local, the address checking may be optimized out and
 leads to the wrong code.  This means that a symbol with user specified
 visibility is local only if it is locally resolved or defined, not weak
 or not compiling for PIC.  When symbol visibility is specified in the
 source, we should always output symbol visibility even if symbol isn't
 local to the TU.

 If a global data symbol is defined in the TU, it is always local to the
 executable, regardless if it is a common symbol or not.  If we aren't
 compiling for shared library, locally defined global data symbol binds
 locally.

 gcc/

 PR rtl-optimization/32219
 * cgraphunit.c (varpool_node::finalize_decl): Set definition
 first before calling notice_global_symbol so that it is
 available to notice_global_symbol.
 * varasm.c (default_binds_local_p_1): Resolve defined data
 symbol locally if not building shared library.  Resolve symbol
 with user specified visibility locally only if it is locally
 resolved or defined, not weak or not compiling for PIC.
 (default_elf_asm_output_external): Always output visibility
 specified in the source.
 * config/darwin-protos.h (darwin_output_external): New.
 * config/darwin.c (darwin_output_external): Likewise.
 * config/darwin.h (ASM_OUTPUT_EXTERNAL): Likewise.

 gcc/testsuite/

 PR rtl-optimization/32219
 * gcc.dg/visibility-22.c: New test.
 * gcc.dg/visibility-23.c: Likewise.
 * gcc.target/i386/pr32219-1.c: Likewise.
 * gcc.target/i386/pr32219-2.c: Likewise.
 * gcc.target/i386/pr32219-3.c: Likewise.
 * gcc.target/i386/pr32219-4.c: Likewise.
 * gcc.target/i386/pr32219-5.c: Likewise.
 * gcc.target/i386/pr32219-6.c: Likewise.
 * gcc.target/i386/pr32219-7.c: Likewise.
 * gcc.target/i386/pr32219-8.c: Likewise.
 * gcc.target/i386/pr64317.c: Expect GOTOFF relocation

Re: [PATCH] PR rtl-optimization/32219: optimizer causes wrong code in pic/hidden/weak symbol checking

[Jack Howarth]

.long L$set$34
.byte   0xd
.byte   0x4
.byte   0x4
.set L$set$35,LCFI20-LCFI19
.long L$set$35
.byte   0x83
.byte   0x3
.byte   0x4
.set L$set$36,LCFI21-LCFI20
.long L$set$36
.byte   0xc4
.byte   0xc3
.byte   0xc
.byte   0x5
.byte   0x4
.align 2
LEFDE13:
LSFDE15:
.set L$set$37,LEFDE15-LASFDE15
.long L$set$37
LASFDE15:
.long   LASFDE15-EH_frame1
.long   LFB21-.
.set L$set$38,LFE21-LFB21
.long L$set$38
.byte   0
.byte   0x4
.set L$set$39,LCFI22-LFB21
.long L$set$39
.byte   0xe
.byte   0x8
.byte   0x84
.byte   0x2
.byte   0x4
.set L$set$40,LCFI23-LCFI22
.long L$set$40
.byte   0xd
.byte   0x4
.byte   0x4
.set L$set$41,LCFI24-LCFI23
.long L$set$41
.byte   0xc4
.byte   0xc
.byte   0x5
.byte   0x4
.align 2
LEFDE15:
LSFDE17:
.set L$set$42,LEFDE17-LASFDE17
.long L$set$42
LASFDE17:
.long   LASFDE17-EH_frame1
.long   LFB24-.
.set L$set$43,LFE24-LFB24
.long L$set$43
.byte   0
.byte   0x4
.set L$set$44,LCFI25-LFB24
.long L$set$44
.byte   0xe
.byte   0x8
.byte   0x84
.byte   0x2
.byte   0x4
.set L$set$45,LCFI26-LCFI25
.long L$set$45
.byte   0xd
.byte   0x4
.byte   0x4
.set L$set$46,LCFI27-LCFI26
.long L$set$46
.byte   0x83
.byte   0x3
.byte   0x4
.set L$set$47,LCFI28-LCFI27
.long L$set$47
.byte   0xc4
.byte   0xc3
.byte   0xc
.byte   0x5
.byte   0x4
.align 2
LEFDE17:
LSFDE19:
.set L$set$48,LEFDE19-LASFDE19
.long L$set$48
LASFDE19:
.long   LASFDE19-EH_frame1
.long   LFB25-.
.set L$set$49,LFE25-LFB25
.long L$set$49
.byte   0
.byte   0x4
.set L$set$50,LCFI29-LFB25
.long L$set$50
.byte   0xe
.byte   0x8
.byte   0x84
.byte   0x2
.byte   0x4
.set L$set$51,LCFI30-LCFI29
.long L$set$51
.byte   0xd
.byte   0x4
.byte   0x4
.set L$set$52,LCFI31-LCFI30
.long L$set$52
.byte   0xc4
.byte   0xc
.byte   0x5
.byte   0x4
.align 2
LEFDE19:
LSFDE21:
.set L$set$53,LEFDE21-LASFDE21
.long L$set$53
LASFDE21:
.long   LASFDE21-EH_frame1
.long   LFB26-.
.set L$set$54,LFE26-LFB26
.long L$set$54
.byte   0
.byte   0x4
.set L$set$55,LCFI32-LFB26
.long L$set$55
.byte   0xe
.byte   0x8
.byte   0x84
.byte   0x2
.byte   0x4
.set L$set$56,LCFI33-LCFI32
.long L$set$56
.byte   0xd
.byte   0x4
.byte   0x4
.set L$set$57,LCFI34-LCFI33
.long L$set$57
.byte   0xc4
.byte   0xc
.byte   0x5
.byte   0x4
.align 2
LEFDE21:
LSFDE23:
.set L$set$58,LEFDE23-LASFDE23
.long L$set$58
LASFDE23:
.long   LASFDE23-EH_frame1
.long   LFB27-.
.set L$set$59,LFE27-LFB27
.long L$set$59
.byte   0
.byte   0x4
.set L$set$60,LCFI35-LFB27
.long L$set$60
.byte   0xe
.byte   0x8
.byte   0x84
.byte   0x2
.byte   0x4
.set L$set$61,LCFI36-LCFI35
.long L$set$61
.byte   0xd
.byte   0x4
.byte   0x4
.set L$set$62,LCFI37-LCFI36
.long L$set$62
.byte   0xc4
.byte   0xc
.byte   0x5
.byte   0x4
.align 2
LEFDE23:
LSFDE25:
.set L$set$63,LEFDE25-LASFDE25
.long L$set$63
LASFDE25:
.long   LASFDE25-EH_frame1
.long   LFB28-.
.set L$set$64,LFE28-LFB28
.long L$set$64
.byte   0
.align 2
LEFDE25:
LSFDE27:
.set L$set$65,LEFDE27-LASFDE27
.long L$set$65
LASFDE27:
.long   LASFDE27-EH_frame1
.long   LFB29-.
.set L$set$66,LFE29-LFB29
.long L$set$66
.byte   0
.align 2
LEFDE27:
.mod_init_func
.align 2
.long   __GLOBAL__sub_I_empty7.C
.constructor
.destructor
.align 1
.subsections_via_symbols



On Sat, Feb 7, 2015 at 10:11 AM, Jack Howarth howarth.at@gmail.com wrote:
 H.J,,
 Unfortunately, the answer is yes. This patch still introduces
 regressions in the g++ test suite.l These are all some form of...

 Executing on host:
 /sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/testsuite/g++/../../xg++
 -B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/testsuite/g++/../../
 /sw/src/fink.build

Re: [PATCH] PR rtl-optimization/32219: optimizer causes wrong code in pic/hidden/weak symbol checking

[Jack Howarth]

H.J.,
  This one bootstrap and appears to give clean c++ test suite
results so far on x86_64-apple-darwin14. I am stopping the regression
testing to try the updated patch you sent later.
   Jack

On Sat, Feb 7, 2015 at 10:56 AM, H.J. Lu hjl.to...@gmail.com wrote:
 On Sat, Feb 07, 2015 at 10:11:01AM -0500, Jack Howarth wrote:
 H.J,,
 Unfortunately, the answer is yes. This patch still introduces
 regressions in the g++ test suite.l These are all some form of...


 It looks like Darwin depends on the old behavior of
 default_binds_local_p_1.  Please try this patch.


 H.J.

 From 2df2188c97760ed10a85bff3dfef8198e41862f2 Mon Sep 17 00:00:00 2001
 From: H.J. Lu hjl.to...@gmail.com
 Date: Thu, 5 Feb 2015 14:28:58 -0800
 Subject: [PATCH] Handle symbol visibility/locality for PIE/PIC

 If a hidden weak symbol isn't defined in the TU, we can't assume it will
 be defined in another TU at link time.  It makes a difference in code
 generation when compiling for PIC. If we assume that a hidden weak
 undefined symbol is local, the address checking may be optimized out and
 leads to the wrong code.  This means that a symbol with user specified
 visibility is local only if it is locally resolved or defined, not weak
 or not compiling for PIC.  When symbol visibility is specified in the
 source, we should always output symbol visibility even if symbol isn't
 local to the TU.

 If a global data symbol is defined in the TU, it is always local to the
 executable, regardless if it is a common symbol or not.  If we aren't
 compiling for shared library, locally defined global data symbol binds
 locally.

 Since some targets call default_binds_local_p_1 directly and depend on
 the old behavior of default_binds_local_p_1.  This patch copies
 default_binds_local_p_1 to default_binds_local_p_2 and changes the
 behavior of default_binds_local_p by calling default_binds_local_p_2
 instead of default_binds_local_p_1.

 gcc/

 PR rtl-optimization/32219
 * cgraphunit.c (varpool_node::finalize_decl): Set definition
 first before calling notice_global_symbol so that it is
 available to notice_global_symbol.
 * varasm.c (default_binds_local_p_2): Copied from
 default_binds_local_p_1.  Resolve defined data symbol locally if
 not building shared library.  Resolve symbol with user specified
 visibility locally only if it is locally resolved or defined, not
 weak or not compiling for PIC.
 (default_binds_local_p): Replace default_binds_local_p_1 with
 default_binds_local_p_2.
 (default_elf_asm_output_external): Always output visibility
 specified in the source.

 gcc/testsuite/

 PR rtl-optimization/32219
 * gcc.dg/visibility-22.c: New test.
 * gcc.dg/visibility-23.c: Likewise.
 * gcc.target/i386/pr32219-1.c: Likewise.
 * gcc.target/i386/pr32219-2.c: Likewise.
 * gcc.target/i386/pr32219-3.c: Likewise.
 * gcc.target/i386/pr32219-4.c: Likewise.
 * gcc.target/i386/pr32219-5.c: Likewise.
 * gcc.target/i386/pr32219-6.c: Likewise.
 * gcc.target/i386/pr32219-7.c: Likewise.
 * gcc.target/i386/pr32219-8.c: Likewise.
 * gcc.target/i386/pr64317.c: Expect GOTOFF relocation instead
 of GOT relocation.
 ---
  gcc/cgraphunit.c  |  4 +-
  gcc/testsuite/gcc.dg/visibility-22.c  | 17 ++
  gcc/testsuite/gcc.dg/visibility-23.c  | 15 +
  gcc/testsuite/gcc.target/i386/pr32219-1.c | 16 ++
  gcc/testsuite/gcc.target/i386/pr32219-2.c | 16 ++
  gcc/testsuite/gcc.target/i386/pr32219-3.c | 17 ++
  gcc/testsuite/gcc.target/i386/pr32219-4.c | 17 ++
  gcc/testsuite/gcc.target/i386/pr32219-5.c | 16 ++
  gcc/testsuite/gcc.target/i386/pr32219-6.c | 16 ++
  gcc/testsuite/gcc.target/i386/pr32219-7.c | 17 ++
  gcc/testsuite/gcc.target/i386/pr32219-8.c | 17 ++
  gcc/testsuite/gcc.target/i386/pr64317.c   |  2 +-
  gcc/varasm.c  | 95 
 ++-
  13 files changed, 260 insertions(+), 5 deletions(-)
  create mode 100644 gcc/testsuite/gcc.dg/visibility-22.c
  create mode 100644 gcc/testsuite/gcc.dg/visibility-23.c
  create mode 100644 gcc/testsuite/gcc.target/i386/pr32219-1.c
  create mode 100644 gcc/testsuite/gcc.target/i386/pr32219-2.c
  create mode 100644 gcc/testsuite/gcc.target/i386/pr32219-3.c
  create mode 100644 gcc/testsuite/gcc.target/i386/pr32219-4.c
  create mode 100644 gcc/testsuite/gcc.target/i386/pr32219-5.c
  create mode 100644 gcc/testsuite/gcc.target/i386/pr32219-6.c
  create mode 100644 gcc/testsuite/gcc.target/i386/pr32219-7.c
  create mode 100644 gcc/testsuite/gcc.target/i386/pr32219-8.c

 diff --git a/gcc/cgraphunit.c b/gcc/cgraphunit.c
 index 35b244e..71367a3 100644
 --- a/gcc/cgraphunit.c
 +++ b/gcc/cgraphunit.c
 @@ -792,8 +792,10 @@ varpool_node::finalize_decl (tree decl)

if (node-definition)
  return

Re: [PATCH] PR rtl-optimization/32219: optimizer causes wrong code in pic/hidden/weak symbol checking

[Jack Howarth]

H.J.,
On x86_64-apple-darwin14, your patch applied to r220481 results in...

FAIL: gcc.dg/visibility-22.c (test for excess errors)
FAIL: gcc.dg/visibility-23.c scan-hidden private_extern[ \t_]*_?foo

with...

Executing on host:
/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/
/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150206/gcc/testsuite/gcc.dg/visibility-22.c
 -fno-diagnostics-show-caret -fdiagnostics-color=never   -fPIC  -lm
-m32  -o ./visibility-22.exe(timeout = 300)
spawn -ignore SIGHUP
/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/
/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150206/gcc/testsuite/gcc.dg/visibility-22.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -fPIC -lm -m32
-o ./visibility-22.exe^M
Undefined symbols for architecture i386:^M
  _foo, referenced from:^M
  _main in ccMD1qjz.o^M
  _main in ccMD1qjz.o^M
ld: symbol(s) not found for architecture i386^M
collect2: error: ld returned 1 exit status^M
compiler exited with status 1
output is:
Undefined symbols for architecture i386:^M
  _foo, referenced from:^M
  _main in ccMD1qjz.o^M
  _main in ccMD1qjz.o^M
ld: symbol(s) not found for architecture i386^M
collect2: error: ld returned 1 exit status^M

FAIL: gcc.dg/visibility-22.c (test for excess errors)

Executing on host:
/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/
/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150206/gcc/testsuite/gcc.dg/visibility-23.c
 -fno-diagnostics-show-caret -fdiagnostics-color=never   -fPIC -S
-m32  -o visibility-23.s(timeout = 300)
spawn -ignore SIGHUP
/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/
/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150206/gcc/testsuite/gcc.dg/visibility-23.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -fPIC -S -m32 -o
visibility-23.s^M
PASS: gcc.dg/visibility-23.c (test for excess errors)
FAIL: gcc.dg/visibility-23.c scan-hidden private_extern[ \t_]*_?foo

Jack

On Fri, Feb 6, 2015 at 11:23 AM, H.J. Lu hongjiu...@intel.com wrote:
 If a hidden weak symbol isn't defined in the TU, we can't assume it will
 be defined in another TU at link time.  It makes a difference in code
 generation when compiling for PIC. If we assume that a hidden weak
 undefined symbol is local, the address checking may be optimized out and
 leads to the wrong code.  This means that a symbol with user specified
 visibility is local only if it is locally resolved or defined, not weak
 or not compiling for PIC.  When symbol visibility is specified in the
 source, we should always output symbol visibility even if symbol isn't
 local to the TU.

 If a global data symbol is defined in the TU, it is always local to the
 executable, regardless if it is a common symbol or not.  If we aren't
 compiling for shared library, locally defined global data symbol binds
 locally.

 Tested on Linux/x86-64.  OK for trunk?

 Thanks.


 H.J.
 ---
 gcc/

 PR rtl-optimization/32219
 * cgraphunit.c (varpool_node::finalize_decl): Set definition
 first before calling notice_global_symbol so that it is
 available to notice_global_symbol.
 * varasm.c (default_binds_local_p_1): Resolve defined data
 symbol locally if not building shared library.  Resolve symbol
 with user specified visibility locally only if it is locally
 resolved or defined, not weak or not compiling for PIC.
 (default_elf_asm_output_external): Always output visibility
 specified in the source.

 gcc/testsuite/

 PR rtl-optimization/32219
 * gcc.dg/visibility-22.c: New test.
 * gcc.dg/visibility-23.c: Likewise.
 * gcc.target/i386/pr32219-1.c: Likewise.
 * gcc.target/i386/pr32219-2.c: Likewise.
 * gcc.target/i386/pr32219-3.c: Likewise.
 * gcc.target/i386/pr32219-4.c: Likewise.
 * gcc.target/i386/pr32219-5.c: Likewise.
 * gcc.target/i386/pr32219-6.c: Likewise.
 * gcc.target/i386/pr32219-7.c: Likewise.
 * gcc.target/i386/pr32219-8.c: Likewise.
 * gcc.target/i386/pr64317.c: Expect GOTOFF relocation instead
 of GOT relocation.
 ---
  gcc/cgraphunit.c  |  4 +++-
  gcc/testsuite/gcc.dg/visibility-22.c  | 14 +
  gcc/testsuite/gcc.dg/visibility-23.c  | 15 +
  gcc/testsuite/gcc.target/i386/pr32219-1.c | 16 ++
  gcc/testsuite/gcc.target/i386/pr32219-2.c | 16 ++
  gcc/testsuite/gcc.target/i386/pr32219-3.c | 17 +++
  gcc/testsuite/gcc.target/i386/pr32219-4.c | 17 +++
  gcc/testsuite/gcc.target/i386/pr32219-5.c | 16 ++
  gcc/testsuite/gcc.target/i386/pr32219-6.c | 16 ++
  gcc/testsuite/gcc.target/i386/pr32219-7.c 

Re: [PATCH] PR rtl-optimization/32219: optimizer causes wrong code in pic/hidden/weak symbol checking

[Jack Howarth]

H.J.,
 The clang compilers exhibit the same behavior on these test cases.

Undefined symbols for architecture x86_64:
  _foo, referenced from:
  _main in visibility-23-e1e564.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

however if I also pass -Wl,-undefined -Wl,dynamic_lookup to the
linker, both test
compile and run.
 FYI, the assembly from...

/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/
/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150206/gcc/testsuite/gcc.dg/visibility-23.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -fPIC -S -m32 -o
visibility-23.s

contains...

.text
.globl _main
_main:
LFB0:
pushl   %ebp
LCFI0:
movl%esp, %ebp
LCFI1:
subl$8, %esp
call___x86.get_pc_thunk.ax
L1$pb:
lealL_foo$non_lazy_ptr-L1$pb(%eax), %eax
movl(%eax), %eax
testl   %eax, %eax
je  L2
call_foo
L2:
movl$0, %eax
leave
LCFI2:
ret
LFE0:
.weak_reference _foo
.section __TEXT,__textcoal_nt,coalesced,pure_instructions
.weak_definition___x86.get_pc_thunk.ax
.private_extern ___x86.get_pc_thunk.ax
___x86.get_pc_thunk.ax:
LFB1:
movl(%esp), %eax
ret
LFE1:
.section
__TEXT,__eh_frame,coalesced,no_toc+strip_static_syms+live_support
EH_frame1:
.set L$set$0,LECIE1-LSCIE1
.long L$set$0
LSCIE1:
.long   0
.byte   0x1
.ascii zR\0
.byte   0x1
.byte   0x7c
.byte   0x8
.byte   0x1
.byte   0x10
.byte   0xc
.byte   0x5
.byte   0x4
.byte   0x88
.byte   0x1
.align 2
LECIE1:
LSFDE1:
.set L$set$1,LEFDE1-LASFDE1
.long L$set$1
LASFDE1:
.long   LASFDE1-EH_frame1
.long   LFB0-.
.set L$set$2,LFE0-LFB0
.long L$set$2
.byte   0
.byte   0x4
.set L$set$3,LCFI0-LFB0
.long L$set$3
.byte   0xe
.byte   0x8
.byte   0x84
.byte   0x2
.byte   0x4
.set L$set$4,LCFI1-LCFI0
.long L$set$4
.byte   0xd
.byte   0x4
.byte   0x4
.set L$set$5,LCFI2-LCFI1
.long L$set$5
.byte   0xc4
.byte   0xc
.byte   0x5
.byte   0x4
.align 2
LEFDE1:
LSFDE3:
.set L$set$6,LEFDE3-LASFDE3
.long L$set$6
LASFDE3:
.long   LASFDE3-EH_frame1
.long   LFB1-.
.set L$set$7,LFE1-LFB1
.long L$set$7
.byte   0
.align 2
LEFDE3:
.section __IMPORT,__pointers,non_lazy_symbol_pointers
.weak_reference _foo
L_foo$non_lazy_ptr:
.indirect_symbol _foo
.long   0
.subsections_via_symbols


On Fri, Feb 6, 2015 at 4:41 PM, H.J. Lu hjl.to...@gmail.com wrote:
 On Fri, Feb 6, 2015 at 1:31 PM, Jack Howarth howarth.at@gmail.com wrote:
 H.J.,
 On x86_64-apple-darwin14, your patch applied to r220481 results in...

 FAIL: gcc.dg/visibility-22.c (test for excess errors)
 FAIL: gcc.dg/visibility-23.c scan-hidden private_extern[ \t_]*_?foo

 with...

 Executing on host:
 /sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/xgcc
 -B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/
 /sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150206/gcc/testsuite/gcc.dg/visibility-22.c
  -fno-diagnostics-show-caret -fdiagnostics-color=never   -fPIC  -lm
 -m32  -o ./visibility-22.exe(timeout = 300)
 spawn -ignore SIGHUP
 /sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/xgcc
 -B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/
 /sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150206/gcc/testsuite/gcc.dg/visibility-22.c
 -fno-diagnostics-show-caret -fdiagnostics-color=never -fPIC -lm -m32
 -o ./visibility-22.exe^M
 Undefined symbols for architecture i386:^M
   _foo, referenced from:^M
   _main in ccMD1qjz.o^M
   _main in ccMD1qjz.o^M
 ld: symbol(s) not found for architecture i386^M
 collect2: error: ld returned 1 exit status^M
 compiler exited with status 1
 output is:
 Undefined symbols for architecture i386:^M
   _foo, referenced from:^M
   _main in ccMD1qjz.o^M
   _main in ccMD1qjz.o^M
 ld: symbol(s) not found for architecture i386^M
 collect2: error: ld returned 1 exit status^M

 FAIL: gcc.dg/visibility-22.c (test for excess errors)

 Executing on host:
 /sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/xgcc
 -B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/
 /sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150206/gcc/testsuite/gcc.dg/visibility-23.c
  -fno-diagnostics-show-caret -fdiagnostics-color=never   -fPIC -S
 -m32  -o visibility-23.s(timeout = 300)
 spawn -ignore SIGHUP
 /sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/xgcc
 -B/sw/src/fink.build/gcc50-5.0.0-1000

Re: [PATCH] PR rtl-optimization/32219: optimizer causes wrong code in pic/hidden/weak symbol checking

[Jack Howarth]

H.J.,
 This patch also seems to be causing a huge number of regressions
in the g++ test suite due to linkage warnings on darwin of the form...

ld: warning: direct access in Model::~Model() to global weak symbol
vtable for Model means the weak symbol cannot be overridden at
runtime. This was likely caused by different translation units being
compiled with different visibility settings.

Can this change wait until stage1?
Jack

On Fri, Feb 6, 2015 at 4:41 PM, H.J. Lu hjl.to...@gmail.com wrote:
 On Fri, Feb 6, 2015 at 1:31 PM, Jack Howarth howarth.at@gmail.com wrote:
 H.J.,
 On x86_64-apple-darwin14, your patch applied to r220481 results in...

 FAIL: gcc.dg/visibility-22.c (test for excess errors)
 FAIL: gcc.dg/visibility-23.c scan-hidden private_extern[ \t_]*_?foo

 with...

 Executing on host:
 /sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/xgcc
 -B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/
 /sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150206/gcc/testsuite/gcc.dg/visibility-22.c
  -fno-diagnostics-show-caret -fdiagnostics-color=never   -fPIC  -lm
 -m32  -o ./visibility-22.exe(timeout = 300)
 spawn -ignore SIGHUP
 /sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/xgcc
 -B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/
 /sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150206/gcc/testsuite/gcc.dg/visibility-22.c
 -fno-diagnostics-show-caret -fdiagnostics-color=never -fPIC -lm -m32
 -o ./visibility-22.exe^M
 Undefined symbols for architecture i386:^M
   _foo, referenced from:^M
   _main in ccMD1qjz.o^M
   _main in ccMD1qjz.o^M
 ld: symbol(s) not found for architecture i386^M
 collect2: error: ld returned 1 exit status^M
 compiler exited with status 1
 output is:
 Undefined symbols for architecture i386:^M
   _foo, referenced from:^M
   _main in ccMD1qjz.o^M
   _main in ccMD1qjz.o^M
 ld: symbol(s) not found for architecture i386^M
 collect2: error: ld returned 1 exit status^M

 FAIL: gcc.dg/visibility-22.c (test for excess errors)

 Executing on host:
 /sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/xgcc
 -B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/
 /sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150206/gcc/testsuite/gcc.dg/visibility-23.c
  -fno-diagnostics-show-caret -fdiagnostics-color=never   -fPIC -S
 -m32  -o visibility-23.s(timeout = 300)
 spawn -ignore SIGHUP
 /sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/xgcc
 -B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/
 /sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150206/gcc/testsuite/gcc.dg/visibility-23.c
 -fno-diagnostics-show-caret -fdiagnostics-color=never -fPIC -S -m32 -o
 visibility-23.s^M
 PASS: gcc.dg/visibility-23.c (test for excess errors)
 FAIL: gcc.dg/visibility-23.c scan-hidden private_extern[ \t_]*_?foo


 Does Darwin support undefined hidden weak symbol?
 Can you compile and gcc/testsuite/gcc.dg/visibility-22.c
 with clang on Darwin?

 --
 H.J.

Re: [PATCH] PR rtl-optimization/32219: optimizer causes wrong code in pic/hidden/weak symbol checking

[Jack Howarth]

H.J.,
Where is this new patch?
  Jack

On Fri, Feb 6, 2015 at 8:55 PM, H.J. Lu hjl.to...@gmail.com wrote:
 On Fri, Feb 6, 2015 at 5:51 PM, Jack Howarth howarth.at@gmail.com wrote:
 H.J.,
  This patch also seems to be causing a huge number of regressions
 in the g++ test suite due to linkage warnings on darwin of the form...

 ld: warning: direct access in Model::~Model() to global weak symbol
 vtable for Model means the weak symbol cannot be overridden at
 runtime. This was likely caused by different translation units being
 compiled with different visibility settings.

 Can you try my new patch?

 Can this change wait until stage1?
 Jack

 On Fri, Feb 6, 2015 at 4:41 PM, H.J. Lu hjl.to...@gmail.com wrote:
 On Fri, Feb 6, 2015 at 1:31 PM, Jack Howarth howarth.at@gmail.com 
 wrote:
 H.J.,
 On x86_64-apple-darwin14, your patch applied to r220481 results in...

 FAIL: gcc.dg/visibility-22.c (test for excess errors)
 FAIL: gcc.dg/visibility-23.c scan-hidden private_extern[ \t_]*_?foo

 with...

 Executing on host:
 /sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/xgcc
 -B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/
 /sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150206/gcc/testsuite/gcc.dg/visibility-22.c
  -fno-diagnostics-show-caret -fdiagnostics-color=never   -fPIC  -lm
 -m32  -o ./visibility-22.exe(timeout = 300)
 spawn -ignore SIGHUP
 /sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/xgcc
 -B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/
 /sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150206/gcc/testsuite/gcc.dg/visibility-22.c
 -fno-diagnostics-show-caret -fdiagnostics-color=never -fPIC -lm -m32
 -o ./visibility-22.exe^M
 Undefined symbols for architecture i386:^M
   _foo, referenced from:^M
   _main in ccMD1qjz.o^M
   _main in ccMD1qjz.o^M
 ld: symbol(s) not found for architecture i386^M
 collect2: error: ld returned 1 exit status^M
 compiler exited with status 1
 output is:
 Undefined symbols for architecture i386:^M
   _foo, referenced from:^M
   _main in ccMD1qjz.o^M
   _main in ccMD1qjz.o^M
 ld: symbol(s) not found for architecture i386^M
 collect2: error: ld returned 1 exit status^M

 FAIL: gcc.dg/visibility-22.c (test for excess errors)

 Executing on host:
 /sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/xgcc
 -B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/
 /sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150206/gcc/testsuite/gcc.dg/visibility-23.c
  -fno-diagnostics-show-caret -fdiagnostics-color=never   -fPIC -S
 -m32  -o visibility-23.s(timeout = 300)
 spawn -ignore SIGHUP
 /sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/xgcc
 -B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/
 /sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150206/gcc/testsuite/gcc.dg/visibility-23.c
 -fno-diagnostics-show-caret -fdiagnostics-color=never -fPIC -S -m32 -o
 visibility-23.s^M
 PASS: gcc.dg/visibility-23.c (test for excess errors)
 FAIL: gcc.dg/visibility-23.c scan-hidden private_extern[ \t_]*_?foo


 Does Darwin support undefined hidden weak symbol?
 Can you compile and gcc/testsuite/gcc.dg/visibility-22.c
 with clang on Darwin?

 --
 H.J.



 --
 H.J.

[PATCH] Fix PR64855

[Jack Howarth]

   The attached patch fixes PR64855 by not setting targetabis on
darwin in testsuite/lib/libffi.exp as suggested by Iain Sandoe.
Confirmed on x86_64-apple-darwin14 to eliminate the libffi regressions
at -m32/-m64. Okay for gcc trunk?
 Jack
2015-01-29  Jack Howarth  howarth.at@gmail.com

PR libffi/64855
* testsuite/lib/libffi.exp: Don't set targetabis on darwin.


Index: libffi/testsuite/lib/libffi.exp
===
--- libffi/testsuite/lib/libffi.exp (revision 220263)
+++ libffi/testsuite/lib/libffi.exp (working copy)
@@ -310,7 +310,7 @@ proc run-many-tests { testcases extra_fl
 set targetabis {  }
 if [string match $compiler_vendor gnu] {
 if { ([istarget i?86-*-*] || [istarget x86_64-*-*])
- [is-effective-target ia32] } {
+ [is-effective-target ia32]  ![istarget *-*-darwin*] } {
 set targetabis {
 
 -DABI_NUM=FFI_STDCALL -DABI_ATTR=__STDCALL__

[PATCH] PR64635 - load libgomp-plugin-host_nonshm shared library with correct suffix

[Jack Howarth]

   The attached patch solves PR64635 for those targets which produce a
libgomp-plugin-host_nonshm shared library with a suffix other than
.so.1. A set of target specific plugin-suffix.h headers are
installed in libgomp/config/aix, libgomp/config/darwin and
libgomp/config/hpux as well as a generic plugin-suffix.h in
libgomp/config/posix. For aix, darwin and hpux, configure.tgt is
modified to add the new config directory to the config_path search
path for those targets. Finally the new plugin-suffix.h is included in
target.c and its target-specific SONAME_SUFFIX macro is used to set
the plugin's suffix. Bootstrap and libgomp regression tested on
x86_64-apple-darwin14.
  Okay for gcc truink?
   Jack


PR64635.patch
Description: Binary data

Re: [PATCH] PR64635 - load libgomp-plugin-host_nonshm shared library with correct suffix

[Jack Howarth]

Mike,
  Thanks for the commit. There is one other issue that I have been
pondering about filing a PR. In fink and MacPorts, FSF gcc is built
and packaged using either...

--prefix=/sw/lib/gcc5.0

or

--libdir=/opt/local/lib/gcc5

such that the libraries for each gcc release are buried. While this
doesn't present an issue in running the libgomp test suite when
-DACC_DEVICE_TYPE_host_nonshm=1 is used, end-users will have to
explicitly set DYLD_LIBRARY_PATH to contain /sw/lib/gcc5.0/lib or
/opt/local/lib/gcc5 for such executables to find the
libgomp-plugin-host_nonshm shared library.
 I realize this is a corner case, but shouldn't libgomp/target.c
contain a hard-coded path from the build for the location of the
installed gcc libraries and make an initial attempt to open it from
that location before attempting a second time without an explicit
path? Any thoughts?
  Jack

On Wed, Jan 28, 2015 at 4:22 PM, Mike Stump mikest...@comcast.net wrote:
 On Jan 28, 2015, at 1:03 PM, Jakub Jelinek ja...@redhat.com wrote:
 Please add
   PR libgomp/64635
 to the ChangeLog entry.
 Ok with that change.

 Committed revision 220218.

Re: Merge current set of OpenACC changes from gomp-4_0-branch

[Jack Howarth]

Thomas,
 Any plans to fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64635 soon? On x86_64
darwin, the OpenACC merge resulted a huge number of failures in the
libgomp test suite…


=== libgomp Summary ===
# of expected passes 10628
# of unexpected failures 724
# of unsupported tests 562

which are resolved with a fix similar to
https://gcc.gnu.org/bugzilla/attachment.cgi?id=34480.
   Jack


On Mon, Jan 26, 2015 at 8:44 AM, Thomas Schwinge
tho...@codesourcery.com wrote:
 Hi!

 Sorry for the late answer -- I've been on sick leave, and just now
 returning to work.  Julian, would you please have a look at the following
 issues?

   In r219682, I have committed to trunk our current set of OpenACC changes,
   which we had prepared on gomp-4_0-branch.  Thanks to everyone who has
   been contributing!

 On Fri, 23 Jan 2015 20:20:53 +0300, Ilya Verbin iver...@gmail.com wrote:
 On 17 Jan 02:16, Ilya Verbin wrote:
  Unfortunately, it broke offloading from shared libraries (I mean common 
  libs
  with NEEDED entries, not dlopened).

 Sorry for that!

  Such things are not covered by the
  testsuite, that's why you missed this issue.  Here is a simple testcase:

 http://news.gmane.org/find-root.php?message_id=%3C20150116231632.GB48380%40msticlxl57.ims.intel.com%3E

 Probably a good motivation for adding such a test case.  ;-)

  So, you don't assume that a device can have multiple images from multiple 
  libs?

 Ping?

 This probably is just a bug that we introduced with our changes?
 (Julian?)


 Also, could you please explain, why did you divide a device initialization 
 into
 two functions -- gomp_init_device and gomp_init_tables?

 As I understand it (again, Julian, please correct me if I got that
 wrong), the reason is that for OpenACC support, we need these as two
 separate (independent) actions.  Is this causing problems for OpenMP
 offloading?


 Currently I'm trying to rebase on trunk my old patch, which fixes offloading
 from dlopened libraries: 
 http://gcc.gnu.org/ml/gcc-patches/2014-11/msg01604.html
 It works for OpenMP and MIC, but I don't know how not to break OpenACC and 
 PTX.


 Grüße,
  Thomas

Re: [PR libgomp/64625] Remove __OFFLOAD_TABLE__ variable/formal parameter (was: Merge current set of OpenACC changes from gomp-4_0-branch)

[Jack Howarth]

On 86_64 Fedora 15, current gcc trunk only produces…

nm libgcc_s.so.1 | grep OFF
00215478 d _GLOBAL_OFFSET_TABLE_

and not __OFFLOAD_TABLE__,  The  libgcc_s.so.1 built on
x86_64-apple-darwin14 doesn't even contain the _GLOBAL_OFFSET_TABLE_
symbol.

On Fri, Jan 16, 2015 at 5:40 PM, Ilya Verbin iver...@gmail.com wrote:
 On 16 Jan 21:34, Thomas Schwinge wrote:
 On Thu, 15 Jan 2015 21:20:07 +0100, I wrote:
 Here is a patch to remove the __OFFLOAD_SYMBOL__ variable/formal
 parameter, as discussed in https://gcc.gnu.org/PR64625.

 But -- I now wonder whether that's actually the issue that has been
 reported in the PR; doesn't that more look like a problem with the
 __OFFLOAD_TABLE__ symbol defined in libgcc/offloadstuff.c, and used in
 the mkoffload tools (such as gcc/config/i386/intelmic-mkoffload.c)?  Can
 anyone guess what's going on?

 Why do you think so?  __OFFLOAD_TABLE__ symbol lives in libgcc/offloadstuff.c
 since November without regressions.

   -- Ilya

Re: [PR libgomp/64625] Remove __OFFLOAD_TABLE__ variable/formal parameter (was: Merge current set of OpenACC changes from gomp-4_0-branch)

[Jack Howarth]

As I read https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64625#c3, the
requirement for  __OFFLOAD_TABLE__ was not longer present and the
residual usages of it just had to be removed. The weak symbol on
darwin is fragile and seems to trip up on the existing code which
produces undefined symbols for ___OFFLOAD_TABLE__...

# nm e.50.1.o | grep OFF
 U ___OFFLOAD_TABLE__

rather than

$ nm e.50.1.o | grep OFF
 w __OFFLOAD_TABLE__

for all of the test cases.

On Fri, Jan 16, 2015 at 6:30 PM, Ilya Verbin iver...@gmail.com wrote:
 On 16 Jan 18:22, Jack Howarth wrote:
 On 86_64 Fedora 15, current gcc trunk only produces…

 nm libgcc_s.so.1 | grep OFF
 00215478 d _GLOBAL_OFFSET_TABLE_

 and not __OFFLOAD_TABLE__,  The  libgcc_s.so.1 built on
 x86_64-apple-darwin14 doesn't even contain the _GLOBAL_OFFSET_TABLE_
 symbol.

 On Fri, Jan 16, 2015 at 5:40 PM, Ilya Verbin iver...@gmail.com wrote:
  Why do you think so?  __OFFLOAD_TABLE__ symbol lives in 
  libgcc/offloadstuff.c
  since November without regressions.

 That's correct.
 1. offloadstuff.c isn't linked into libgcc_s.so.1
 2. __OFFLOAD_TABLE__ is guarded with ENABLE_OFFLOADING, which is disabled in
 default configuration.

   -- Ilya

Re: [PR libgomp/64625] Remove __OFFLOAD_TABLE__ variable/formal parameter (was: Merge current set of OpenACC changes from gomp-4_0-branch)

[Jack Howarth]

Confirmed that this patch eliminates

[Bug libgomp/64625] ___OFFLOAD_TABLE__ symbol not produced on x86_64 darwin

and thus exposes

[Bug libgomp/64635] New: darwin produces
libgomp-plugin-host_nonshm.1.dylib but tries to load
libgomp-plugin-host_nonshm.so.1

The additional hack (which should be fixed with configure/Makefile.
changes to detect SHLIBEXT)...

@@ -1055,7 +1054,7 @@ static void
 gomp_target_init (void)
 {
   const char *prefix =libgomp-plugin-;
-  const char *suffix = .so.1;
+  const char *suffix = .1.dylib;
   const char *cur, *next;
   char *plugin_name;

to target.c in libgomp eliminates the second bug.

Native configuration is x86_64-apple-darwin14.1.0

=== libgomp tests ===

Schedule of variations:
unix/-m32
unix/-m64

Running target unix/-m32
Using /sw/share/dejagnu/baseboards/unix.exp as board description file
for target.
Using /sw/share/dejagnu/config/unix.exp as generic interface file for target.
Using 
/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150116/libgomp/testsuite/config/default.exp
as tool-and-target-specific interface file.
Running 
/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150116/libgomp/testsuite/libgomp.c/c.exp
...
Running 
/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150116/libgomp/testsuite/libgomp.c++/c++.exp
...
Running 
/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150116/libgomp/testsuite/libgomp.fortran/fortran.exp
...
Running 
/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150116/libgomp/testsuite/libgomp.graphite/graphite.exp
...
Running 
/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150116/libgomp/testsuite/libgomp.oacc-c/c.exp
...
Running 
/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150116/libgomp/testsuite/libgomp.oacc-c++/c++.exp
...
Running 
/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150116/libgomp/testsuite/libgomp.oacc-fortran/fortran.exp
...

=== libgomp Summary for unix/-m32 ===

# of expected passes 5715
# of unsupported tests 281
Running target unix/-m64
Using /sw/share/dejagnu/baseboards/unix.exp as board description file
for target.
Using /sw/share/dejagnu/config/unix.exp as generic interface file for target.
Using 
/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150116/libgomp/testsuite/config/default.exp
as tool-and-target-specific interface file.
Running 
/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150116/libgomp/testsuite/libgomp.c/c.exp
...
Running 
/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150116/libgomp/testsuite/libgomp.c++/c++.exp
...
Running 
/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150116/libgomp/testsuite/libgomp.fortran/fortran.exp
...
Running 
/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150116/libgomp/testsuite/libgomp.graphite/graphite.exp
...
Running 
/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150116/libgomp/testsuite/libgomp.oacc-c/c.exp
...
Running 
/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150116/libgomp/testsuite/libgomp.oacc-c++/c++.exp
...
Running 
/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150116/libgomp/testsuite/libgomp.oacc-fortran/fortran.exp
...

=== libgomp Summary for unix/-m64 ===

# of expected passes 5715
# of unsupported tests 281

=== libgomp Summary ===

# of expected passes 11430
# of unsupported tests 562


On Fri, Jan 16, 2015 at 3:34 PM, Thomas Schwinge
tho...@codesourcery.com wrote:
 Hi!

 On Thu, 15 Jan 2015 21:20:07 +0100, I wrote:
 In r219682, I have committed to trunk our current set of OpenACC changes,

 Here is a patch to remove the __OFFLOAD_SYMBOL__ variable/formal
 parameter, as discussed in https://gcc.gnu.org/PR64625.

 But -- I now wonder whether that's actually the issue that has been
 reported in the PR; doesn't that more look like a problem with the
 __OFFLOAD_TABLE__ symbol defined in libgcc/offloadstuff.c, and used in
 the mkoffload tools (such as gcc/config/i386/intelmic-mkoffload.c)?  Can
 anyone guess what's going on?

 Anyway, as discussed in https://gcc.gnu.org/PR64625, I'd like to commit
 this patch either way, OK?

 commit 4409d0129118479c1cd1adbcfa96316ac4e734b0
 Author: Thomas Schwinge tho...@codesourcery.com
 Date:   Fri Jan 16 20:12:12 2015 +0100

 [PR libgomp/64625] Remove __OFFLOAD_TABLE__ variable/formal parameter.

 gcc/
 * omp-low.c (offload_symbol_decl): Remove variable.
 (get_offload_symbol_decl): Remove function.
 (expand_omp_target): For BUILT_IN_GOMP_TARGET,
 BUILT_IN_GOMP_TARGET_DATA, BUILT_IN_GOMP_TARGET_UPDATE pass NULL
 instead of __OFFLOAD_TABLE__, for BUILT_IN_GOACC_DATA_START,
 BUILT_IN_GOACC_ENTER_EXIT_DATA, BUILT_IN_GOACC_PARALLEL,
 BUILT_IN_GOACC_UPDATE don't pass it at all.
 libgomp/
 * libgomp_g.h (GOACC_data_start, GOACC_enter_exit_data)
 (GOACC_parallel, GOACC_update): Remove const_void *offload_table
 formal parameter.  Update all users.
 * target.c (GOMP_target, GOMP_target_data, GOMP_target_update):
 Document unused formal parameter.
 ---
  gcc/omp-low.c   | 45 ++---
  

Re: [PATCH, Libatomic, Darwin] Initial libatomic port for *darwin*.

[Jack Howarth]

Iain,
 Were you planning to try to get this committed before stage4 or
will it have to wait for the next major gcc release?
  Jack

On Thu, Nov 13, 2014 at 3:34 PM, Iain Sandoe i...@codesourcery.com wrote:
 Hello Richard, Joseph,

 Thanks for your reviews,

 On 13 Nov 2014, at 07:40, Richard Henderson wrote:

 On 11/12/2014 10:18 PM, Iain Sandoe wrote:

 #  ifndef USE_ATOMIC
 #define USE_ATOMIC 1
 #  endif

 Why would USE_ATOMIC be defined previously?

 This was left-over from a mode where I allowed the User to jam the mode to 
 OSSpinLocks to test the performance.

 I apologise, [weak excuse follows] with the turbulence of Darwin on trunk, my 
 trunk version of the patch had got behind my 4.9 one. (most of the work has 
 been hammered out there while we try to get bootstrap restored).

 re-synced and retested with a patched trunk that bootstraps with some 
 band-aid.

 inline static void LockUnlock(uint32_t *l) {
   __atomic_store_4((_Atomic(uint32_t)*)l, 0, __ATOMIC_RELEASE);
 }

 Gnu coding style, please.  All through the file here.

 Fixed.

 #  define LOCK_SIZE sizeof(uint32_t)
 #  define NLOCKS (PAGE_SIZE / LOCK_SIZE)
 static uint32_t locks[NLOCKS];

 Um, surely not LOCK_SIZE, but CACHELINE_SIZE.  It's the granularity of the
 target region that's at issue, not the size of the lock itself.

 The algorithm I've used is intentionally different from the pthreads-based 
 posix one, here's the rationale, as I see it:

 /* Algorithm motivations.

 Layout Assumptions:
   o Darwin has a number of sub-targets with common atomic types that have no
 'native' in-line handling, but are smaller than a cache-line.
 E.G. PPC32 needs locking for = 8byte quantities, X86/m32 for =16.

   o The _Atomic alignment of a natural type is no greater than the type 
 size.

   o There are no special guarantees about the alignment of _Atomic aggregates
 other than those determined by the psABI.

   o There are no guarantees that placement of an entity won't cause it to
 straddle a cache-line boundary.

   o Realistic User code will likely place several _Atomic qualified types in
 close proximity (such that they fall within the same cache-line).
 Similarly, arrays of _Atomic qualified items.

 Performance Assumptions:
   o Collisions of address hashes for items (which make up the lock keys)
 constitute the largest performance issue.

   o We want to avoid unnecessary flushing of [lock table] cache-line(s) when
 items are accessed.

 Implementation:
   We maintain a table of locks, each lock being 4 bytes (at present).
   This choice of lock size gives some measure of equality in hash-collision
   statistics between the 'atomic' and 'OSSpinLock' implementations, since the
   lock size is fixed at 4 bytes for the latter.

   The table occupies one physical page, and we attempt to align it to a
   page boundary, appropriately.

   For entities that need a lock, with sizes  one cache line:
 Each entity that requires a lock, chooses the lock to use from the table 
 on
   the basis of a hash determined by its size and address.  The lower 
 log2(size)
   address bits are discarded on the assumption that the alignment of entities
   will not be smaller than their size.
   CHECKME: this is not verified for aggregates; it might be something that
   could/should be enforced from the front ends (since _Atomic types are
   allowed to have increased alignment c.f. 'normal').

   For entities that need a lock, with sizes = one cacheline_size:
 We assume that the entity alignment = log2(cacheline_size) and discard
   log2(cacheline_size) bits from the address.
   We then apply size/cacheline_size locks to cover the entity.

   The idea is that this will typically result in distinct hash keys for items
   placed close together.  The keys are mangled further such that the size is
   included in the hash.

   Finally, to attempt to make it such that the lock table entries are accessed
   in a scattered manner,to avoid repeated cacheline flushes, the hash is
   rearranged to attempt to maximise the most noise in the upper bits.
 */

 NOTE that the CHECKME above doesn't put us in any worse position than the 
 pthreads implementation (likely slightly better since we have a smaller 
 granularity with the current scheme).

 #if USE_ATOMIC
   LockLock (locks[addr_hash (ptr, 1)]);
 #else
   OSSpinLockLock(locks[addr_hash (ptr, 1)]);
 #endif

 Better to #define LockLock  OSSpinLockLock within the area above, so as to
 avoid the ifdefs here.
 done.

 Thoughts on the rationale - or OK now?

 thanks
 Iain

 I'm not aware of any other PRs that relate, but will do a final scan through 
 and ask around the darwin folks.

 libatomic:

 PR target/59305
 * config/darwin/host-config.h New.
 * config/darwin/lock.c New.
 * configure.tgt (DEFAULT_X86_CPU): New, (target): New entry for 
 darwin.

Re: [PATCH, Libatomic, Darwin] Initial libatomic port for *darwin*.

[Jack Howarth]

Iain,
What is the status of this patch?
Jack

On Thu, Nov 13, 2014 at 3:34 PM, Iain Sandoe i...@codesourcery.com wrote:
 Hello Richard, Joseph,

 Thanks for your reviews,

 On 13 Nov 2014, at 07:40, Richard Henderson wrote:

 On 11/12/2014 10:18 PM, Iain Sandoe wrote:

 #  ifndef USE_ATOMIC
 #define USE_ATOMIC 1
 #  endif

 Why would USE_ATOMIC be defined previously?

 This was left-over from a mode where I allowed the User to jam the mode to 
 OSSpinLocks to test the performance.

 I apologise, [weak excuse follows] with the turbulence of Darwin on trunk, my 
 trunk version of the patch had got behind my 4.9 one. (most of the work has 
 been hammered out there while we try to get bootstrap restored).

 re-synced and retested with a patched trunk that bootstraps with some 
 band-aid.

 inline static void LockUnlock(uint32_t *l) {
   __atomic_store_4((_Atomic(uint32_t)*)l, 0, __ATOMIC_RELEASE);
 }

 Gnu coding style, please.  All through the file here.

 Fixed.

 #  define LOCK_SIZE sizeof(uint32_t)
 #  define NLOCKS (PAGE_SIZE / LOCK_SIZE)
 static uint32_t locks[NLOCKS];

 Um, surely not LOCK_SIZE, but CACHELINE_SIZE.  It's the granularity of the
 target region that's at issue, not the size of the lock itself.

 The algorithm I've used is intentionally different from the pthreads-based 
 posix one, here's the rationale, as I see it:

 /* Algorithm motivations.

 Layout Assumptions:
   o Darwin has a number of sub-targets with common atomic types that have no
 'native' in-line handling, but are smaller than a cache-line.
 E.G. PPC32 needs locking for = 8byte quantities, X86/m32 for =16.

   o The _Atomic alignment of a natural type is no greater than the type 
 size.

   o There are no special guarantees about the alignment of _Atomic aggregates
 other than those determined by the psABI.

   o There are no guarantees that placement of an entity won't cause it to
 straddle a cache-line boundary.

   o Realistic User code will likely place several _Atomic qualified types in
 close proximity (such that they fall within the same cache-line).
 Similarly, arrays of _Atomic qualified items.

 Performance Assumptions:
   o Collisions of address hashes for items (which make up the lock keys)
 constitute the largest performance issue.

   o We want to avoid unnecessary flushing of [lock table] cache-line(s) when
 items are accessed.

 Implementation:
   We maintain a table of locks, each lock being 4 bytes (at present).
   This choice of lock size gives some measure of equality in hash-collision
   statistics between the 'atomic' and 'OSSpinLock' implementations, since the
   lock size is fixed at 4 bytes for the latter.

   The table occupies one physical page, and we attempt to align it to a
   page boundary, appropriately.

   For entities that need a lock, with sizes  one cache line:
 Each entity that requires a lock, chooses the lock to use from the table 
 on
   the basis of a hash determined by its size and address.  The lower 
 log2(size)
   address bits are discarded on the assumption that the alignment of entities
   will not be smaller than their size.
   CHECKME: this is not verified for aggregates; it might be something that
   could/should be enforced from the front ends (since _Atomic types are
   allowed to have increased alignment c.f. 'normal').

   For entities that need a lock, with sizes = one cacheline_size:
 We assume that the entity alignment = log2(cacheline_size) and discard
   log2(cacheline_size) bits from the address.
   We then apply size/cacheline_size locks to cover the entity.

   The idea is that this will typically result in distinct hash keys for items
   placed close together.  The keys are mangled further such that the size is
   included in the hash.

   Finally, to attempt to make it such that the lock table entries are accessed
   in a scattered manner,to avoid repeated cacheline flushes, the hash is
   rearranged to attempt to maximise the most noise in the upper bits.
 */

 NOTE that the CHECKME above doesn't put us in any worse position than the 
 pthreads implementation (likely slightly better since we have a smaller 
 granularity with the current scheme).

 #if USE_ATOMIC
   LockLock (locks[addr_hash (ptr, 1)]);
 #else
   OSSpinLockLock(locks[addr_hash (ptr, 1)]);
 #endif

 Better to #define LockLock  OSSpinLockLock within the area above, so as to
 avoid the ifdefs here.
 done.

 Thoughts on the rationale - or OK now?

 thanks
 Iain

 I'm not aware of any other PRs that relate, but will do a final scan through 
 and ask around the darwin folks.

 libatomic:

 PR target/59305
 * config/darwin/host-config.h New.
 * config/darwin/lock.c New.
 * configure.tgt (DEFAULT_X86_CPU): New, (target): New entry for 
 darwin.

[PATCH]: Remove unnecessary usage of -DCLOOG_INT_GMP on islinc

[Jack Howarth]

   The attached patch completes the removal of the cloog support in
gcc trunk by removing the use of   -DCLOOG_INT_GMP on islinc in
config/isl.m4 and the top-level configure. Bootstrap tested against
isl 0.14 on x86_64-apple-darwin14. Okay for gcc trunk?
 Jack
2014-12-03  Jack Howarth  howa...@bromo.med.uc.edu

* config/isl.m4: Don't pass -DCLOOG_INT_GMP on islinc.
* configure: Regenerated.

Index: config/isl.m4
===
--- config/isl.m4   (revision 218324)
+++ config/isl.m4   (working copy)
@@ -69,7 +69,6 @@ AC_DEFUN([ISL_INIT_FLAGS],
 AC_MSG_WARN([using in-tree ISL, disabling version check])
   fi
 
-  islinc=-DCLOOG_INT_GMP ${islinc}
   isllibs=${isllibs} -lisl
 ]
 )

[PATCH] fix PR testsuite/64145

[Jack Howarth]

The attached patch fixes the regression in the
gcc/testsuite/gcc.dg/graphite/isl-codegen-loop-dumping.c testcase
caused by the accidental removal of -fgraphite-identity from
dg-options at r217315. Okay for gcc trunk?
 Jack
2014-12-01  Jack Howarth  howa...@bromo.med.uc.edu

PR testsuite/64145
* gcc.dg/graphite/isl-codegen-loop-dumping.c: Restore 
-fgraphite-identity.

Index: gcc/testsuite/gcc.dg/graphite/isl-codegen-loop-dumping.c
===
--- gcc/testsuite/gcc.dg/graphite/isl-codegen-loop-dumping.c(revision 
218285)
+++ gcc/testsuite/gcc.dg/graphite/isl-codegen-loop-dumping.c(working copy)
@@ -1,4 +1,4 @@
-/* { dg-options -O2 -fdump-tree-graphite-all } */
+/* { dg-options -O2 -fgraphite-identity -fdump-tree-graphite-all } */
 
 int
 main (int n, int *a)

Re: [Build, Graphite] PR64017 - support ISL-0.14 (gcc/configure.ac and gcc/graphite*.c)

[Jack Howarth]

   This patch bootstraps fine on x86_64-apple-darwin14 against isl
0.14 at r218098.
  Jack

On Wed, Nov 26, 2014 at 10:55 AM, Tobias Burnus
tobias.bur...@physik.fu-berlin.de wrote:
 This patch adds a configure check for 
 isl_schedule_constraints_compute_schedule,
 which is new in ISL 0.13 - and uses it for conditional compilation.

 The graphite*c patch is based on the one of Jack Howarth,
 https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00906.html - without checking
 whether the ISL replacements make sense.

 With the patch, I have successfully bootstrapped GCC with ISL 0.12.2 and
 ISL 0.14 (both using an in-tree build).  [I still have to regtest the two
 variants and I also want to do a system-ISL built with ISL 0.12.2]

 Is the patch OK for the trunk?

 Tobias

 PS: I'd be happy if some others could run additional tests.

 PPS: If the patch is in, can someone put ISL 0.14 to infrastructure? Then
 one can update contrib/download_prerequisites - such that the graphite
 failure is at least fixed for in-tree builds (cf. PR64017, PR62289).

Re: libsanitizer merge from upstream r221802

[Jack Howarth]

Konstantin,
   Applying the libsanitizer-221802.patch merge to r217456 with
the proposed patch at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534#c50, produces the
following new regressions on x86_64-apple-darwin14 for asan.exp at
-m32/-m64...

FAIL: c-c++-common/asan/global-overflow-1.c   -O0  output pattern
test, is =
FAIL: c-c++-common/asan/global-overflow-1.c   -O1  output pattern
test, is =
FAIL: c-c++-common/asan/global-overflow-1.c   -O2  output pattern
test, is =
FAIL: c-c++-common/asan/global-overflow-1.c   -O3 -fomit-frame-pointer
output pattern test, is
=
FAIL: c-c++-common/asan/global-overflow-1.c   -O3 -g  output pattern
test, is =
FAIL: c-c++-common/asan/global-overflow-1.c   -Os  output pattern
test, is =
FAIL: c-c++-common/asan/global-overflow-1.c   -O2 -flto
-flto-partition=none  output pattern test, is
=
FAIL: c-c++-common/asan/global-overflow-1.c   -O2 -flto  output
pattern test, is
=
FAIL: c-c++-common/asan/heap-overflow-1.c   -O0  output pattern test,
is =
FAIL: c-c++-common/asan/heap-overflow-1.c   -O1  output pattern test,
is =
FAIL: c-c++-common/asan/heap-overflow-1.c   -O2  output pattern test,
is =
FAIL: c-c++-common/asan/heap-overflow-1.c   -O3 -fomit-frame-pointer
output pattern test, is
=
FAIL: c-c++-common/asan/heap-overflow-1.c   -O3 -g  output pattern
test, is =
FAIL: c-c++-common/asan/heap-overflow-1.c   -Os  output pattern test,
is =
FAIL: c-c++-common/asan/heap-overflow-1.c   -O2 -flto
-flto-partition=none  output pattern test, is
=
FAIL: c-c++-common/asan/heap-overflow-1.c   -O2 -flto  output pattern
test, is =
FAIL: c-c++-common/asan/memcmp-1.c   -O0  output pattern test, is
=
FAIL: c-c++-common/asan/memcmp-1.c   -O1  output pattern test, is
=
FAIL: c-c++-common/asan/memcmp-1.c   -O2  output pattern test, is
=
FAIL: c-c++-common/asan/memcmp-1.c   -O3 -fomit-frame-pointer  output
pattern test, is
=
FAIL: c-c++-common/asan/memcmp-1.c   -O3 -g  output pattern test, is
=
FAIL: c-c++-common/asan/memcmp-1.c   -Os  output pattern test, is
=
FAIL: c-c++-common/asan/memcmp-1.c   -O2 -flto -flto-partition=none
output pattern test, is
=
FAIL: c-c++-common/asan/memcmp-1.c   -O2 -flto  output pattern test,
is =
FAIL: g++.dg/asan/deep-stack-uaf-1.C   -O0  output pattern test, is
=
FAIL: g++.dg/asan/deep-stack-uaf-1.C   -O1  output pattern test, is
=
FAIL: g++.dg/asan/deep-stack-uaf-1.C   -O2  output pattern test, is
=
FAIL: g++.dg/asan/deep-stack-uaf-1.C   -O3 -fomit-frame-pointer output
pattern test, is
=
FAIL: g++.dg/asan/deep-stack-uaf-1.C   -O3 -g  output pattern test, is
=
FAIL: g++.dg/asan/deep-stack-uaf-1.C   -Os  output pattern test, is
=
FAIL: g++.dg/asan/deep-tail-call-1.C   -O0  output pattern test, is
=
FAIL: g++.dg/asan/deep-tail-call-1.C   -O1  output pattern test, is
=
FAIL: g++.dg/asan/deep-tail-call-1.C   -O2  output pattern test, is
=
FAIL: g++.dg/asan/deep-tail-call-1.C   -O3 

Re: Fix libtool.m4 for Darwin = 10.10

[Jack Howarth]

FX,
It looks like you missed patching a few configure files...

libjava/classpath/configure
libjava/configure

are definitely needed while

libgo/configure
zlib/configure

should be added for completeness.
  Jack

On Tue, Nov 11, 2014 at 4:15 AM, FX fxcoud...@gmail.com wrote:
 Your patch contains lots of other changes, not just the libtool.m4
 change.  Please filter those out.

 Sorry about that. The patch attached should be clean, and the ChangeLog 
 entries formatted as they should.

 OK to commit? This touches so many area it probably needs a build maintainer 
 or global maintainer to approve it.

 FX

Re: Fix libtool.m4 for Darwin = 10.10

[Jack Howarth]

On Tue, Nov 11, 2014 at 9:45 AM, FX fxcoud...@gmail.com wrote:
It looks like you missed patching a few configure files...

 libjava/classpath/configure
 libjava/configure

 Aren’t those under external control? i.e. maintained out of GCC tree?

However these are maintained, the libjava configure files still need
to be patched to prevent their associated shared libraries from being
inappropriately linked with -flat_namespace on darwin14 and later.
Since you are simply patching all the configure files, the question
seems academic unless you switch to properly regenerating all of the
configure files using a fixed libtool.m4.
 Jack



 libgo/configure
 zlib/configure

 Those are maintained upstream, and we import them directly. I’ve filed a bug 
 for libgo (https://code.google.com/p/go/issues/detail?id=9089).

 FX

Re: RFC: Update ISL under gcc/infrastructure/ ? // Remove CLooG?

[Jack Howarth]

Tobias,
The only new regression seen in gcc trunk when using isl 0.14
with my mockup isl_0.14.diff patch is the failure...

UNRESOLVED: gcc.dg/graphite/isl-codegen-loop-dumping.c
scan-tree-dump-times graphite ISL AST generated by ISL: \\nfor
(int c1 = 0; c1  n - 1; c1 += 1)\\n  for (int c3 = 0;
c3  n; c3 += 1)\\nS_4(c1, c3); 1

at both -m32/-m64. Is this really a regression or simply detection of
a change in the tree-dump generated by isl 0.14?
Jack
ps I was under the impression that these later versions of isl were
supposed to have improved performance that potentially would result in
changes in such tree-dumps.

On Mon, Nov 10, 2014 at 8:40 PM, Jack Howarth howarth.at@gmail.com wrote:
 On x86_64-apple-darwin14, the attached patch allows gcc trunk to
 build against isl 0.14. I assume if we want to retain the...

 #if defined(__cplusplus)
 extern C {
 #endif

 #if defined(__cplusplus)
 }
 #endif

 wrappers around the include of  isl/val_gmp.h, to continue to support
 isl 0.12.2, isl.m4 will need to test for isl = 0.12.2 and set a
 define in autohost.h that can be added to the conditional on
 _cplusplus. The same define would have to be used in a conditional for
 selecting code changes required for using...

 if (isl_band_member_is_zero_distance (Band, i))

 in gcc/graphite-optimize-isl.c for isl = 0.12.2 rather than...

 if (isl_band_member_is_coincident (Band, i))

 and the other associated changes for isl   0.12.2.
 Jack
 ps The changes in gcc/graphite-optimize-isl.c are modelled on those in
 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191650#c6.

 pps The test suite results for make -k check
 RUNTESTFLAGS=graphite.exp --target_board=unix'{-m32,-m64}' are...

 LAST_UPDATED: Obtained from SVN: trunk revision 217269

 Native configuration is x86_64-apple-darwin13.4.0

 === g++ tests ===

 Running target unix/-m32

 === g++ Summary for unix/-m32 ===

 # of expected passes 27

 Running target unix/-m64

 === g++ Summary for unix/-m64 ===

 # of expected passes 27

 === g++ Summary ===

 # of expected passes 54
 /sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/testsuite/g++/../../xg++
  version 5.0.0 20141109 (experimental) (GCC)

 === gcc tests ===

 Running target unix/-m32
 FAIL: gcc.dg/graphite/vect-pr43423.c scan-tree-dump-times vect
 vectorized 2 loops 1
 UNRESOLVED: gcc.dg/graphite/isl-codegen-loop-dumping.c
 scan-tree-dump-times graphite ISL AST generated by ISL: \\nfor
 (int c1 = 0; c1  n - 1; c1 += 1)\\n  for (int c3 = 0;
 c3  n; c3 += 1)\\nS_4(c1, c3); 1

 === gcc Summary for unix/-m32 ===

 # of expected passes 299
 # of unexpected failures 1
 # of expected failures 4
 # of unresolved testcases 1
 # of unsupported tests 5

 Running target unix/-m64
 FAIL: gcc.dg/graphite/vect-pr43423.c scan-tree-dump-times vect
 vectorized 2 loops 1
 UNRESOLVED: gcc.dg/graphite/isl-codegen-loop-dumping.c
 scan-tree-dump-times graphite ISL AST generated by ISL: \\nfor
 (int c1 = 0; c1  n - 1; c1 += 1)\\n  for (int c3 = 0;
 c3  n; c3 += 1)\\nS_4(c1, c3); 1

 === gcc Summary for unix/-m64 ===

 # of expected passes 299
 # of unexpected failures 1
 # of expected failures 4
 # of unresolved testcases 1
 # of unsupported tests 5

 === gcc Summary ===

 # of expected passes 598
 # of unexpected failures 2
 # of expected failures 8
 # of unresolved testcases 2
 # of unsupported tests 10
 /sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/xgcc  version
 5.0.0 20141109 (experimental) (GCC)

 === gfortran tests ===

 Running target unix/-m32

 === gfortran Summary for unix/-m32 ===

 # of expected passes 112
 # of expected failures 14

 Running target unix/-m64

 === gfortran Summary for unix/-m64 ===

 # of expected passes 110
 # of expected failures 14
 # of unsupported tests 2

 === gfortran Summary ===

 # of expected passes 222
 # of expected failures 28
 # of unsupported tests 2
 /sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/testsuite/gfortran/../../gfortran
  version 5.0.0 20141109 (experimental) (GCC)

 === libgomp tests ===

 Running target unix/-m32

 === libgomp Summary for unix/-m32 ===

 # of expected passes 49

 Running target unix/-m64

 === libgomp Summary for unix/-m64 ===

 # of expected passes 49

 === libgomp Summary ===

 # of expected passes 98

 Compiler version: 5.0.0 20141109 (experimental) (GCC)
 Platform: x86_64-apple-darwin13.4.0
 configure flags: --prefix=/sw --prefix=/sw/lib/gcc5.0
 --mandir=/sw/share/man --infodir=/sw/lib/gcc5.0/info
 --enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw
 --with-libiconv-prefix=/sw --with-isl=/sw --without-cloog
 --with-mpc=/sw --with-system-zlib --x-includes=/usr/X11R6/include
 --x-libraries=/usr/X11R6/lib --program-suffix=-fsf-5.0


 On Mon, Nov 10, 2014 at 2:27 PM, Jack Howarth howarth.at@gmail.com 
 wrote:
  Is the current isl 0.12.2 in infrastructure

Re: [patch, v2] Fix libtool.m4 for Darwin = 10.10

[Jack Howarth]

Mike,
 The only problem with this fix for the broken libtool.m4 is that
it will require constant tending as other patches regenerate these
various configure files. For example,
https://gcc.gnu.org/ml/gcc-cvs/2014-11/msg00379.html which was just
committed would have removed the proposed change had it been committed
earlier today.
 Jack

On Tue, Nov 11, 2014 at 2:38 PM, Mike Stump mikest...@comcast.net wrote:
 On Nov 11, 2014, at 11:06 AM, FX fxcoud...@gmail.com wrote:
 Here’s v2 of the patch

 OK to commit?

 Ok with comments:

 libvtv:

 libvtv/
 2014-11-11  Francois-Xavier Coudert  fxcoud...@gcc.gnu.org

 PR target/63610
 * configure:

 Missing Regenerate.

 OK to commit?

 Ok.

 This touches so many area it probably needs a build maintainer or global 
 maintainer to approve it.

 Only darwin is affected, and unlikely anyone else cares much about it.  I’m 
 fine approving it.  Arguably, imports from libtool upstream are trivial 
 anyway.

 If someone else wants to import all of libtool, we welcome their contribution.

Re: RFC: Update ISL under gcc/infrastructure/ ? // Remove CLooG?

[Jack Howarth]

On x86_64-apple-darwin14, the attached patch allows gcc trunk to
build against isl 0.14. I assume if we want to retain the...

#if defined(__cplusplus)
extern C {
#endif

#if defined(__cplusplus)
}
#endif

wrappers around the include of  isl/val_gmp.h, to continue to support
isl 0.12.2, isl.m4 will need to test for isl = 0.12.2 and set a
define in autohost.h that can be added to the conditional on
_cplusplus. The same define would have to be used in a conditional for
selecting code changes required for using...

if (isl_band_member_is_zero_distance (Band, i))

in gcc/graphite-optimize-isl.c for isl = 0.12.2 rather than...

if (isl_band_member_is_coincident (Band, i))

and the other associated changes for isl   0.12.2.
Jack
ps The changes in gcc/graphite-optimize-isl.c are modelled on those in
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191650#c6.

pps The test suite results for make -k check
RUNTESTFLAGS=graphite.exp --target_board=unix'{-m32,-m64}' are...

LAST_UPDATED: Obtained from SVN: trunk revision 217269

Native configuration is x86_64-apple-darwin13.4.0

=== g++ tests ===

Running target unix/-m32

=== g++ Summary for unix/-m32 ===

# of expected passes 27

Running target unix/-m64

=== g++ Summary for unix/-m64 ===

# of expected passes 27

=== g++ Summary ===

# of expected passes 54
/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/testsuite/g++/../../xg++
 version 5.0.0 20141109 (experimental) (GCC)

=== gcc tests ===

Running target unix/-m32
FAIL: gcc.dg/graphite/vect-pr43423.c scan-tree-dump-times vect
vectorized 2 loops 1
UNRESOLVED: gcc.dg/graphite/isl-codegen-loop-dumping.c
scan-tree-dump-times graphite ISL AST generated by ISL: \\nfor
(int c1 = 0; c1  n - 1; c1 += 1)\\n  for (int c3 = 0;
c3  n; c3 += 1)\\nS_4(c1, c3); 1

=== gcc Summary for unix/-m32 ===

# of expected passes 299
# of unexpected failures 1
# of expected failures 4
# of unresolved testcases 1
# of unsupported tests 5

Running target unix/-m64
FAIL: gcc.dg/graphite/vect-pr43423.c scan-tree-dump-times vect
vectorized 2 loops 1
UNRESOLVED: gcc.dg/graphite/isl-codegen-loop-dumping.c
scan-tree-dump-times graphite ISL AST generated by ISL: \\nfor
(int c1 = 0; c1  n - 1; c1 += 1)\\n  for (int c3 = 0;
c3  n; c3 += 1)\\nS_4(c1, c3); 1

=== gcc Summary for unix/-m64 ===

# of expected passes 299
# of unexpected failures 1
# of expected failures 4
# of unresolved testcases 1
# of unsupported tests 5

=== gcc Summary ===

# of expected passes 598
# of unexpected failures 2
# of expected failures 8
# of unresolved testcases 2
# of unsupported tests 10
/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/xgcc  version
5.0.0 20141109 (experimental) (GCC)

=== gfortran tests ===

Running target unix/-m32

=== gfortran Summary for unix/-m32 ===

# of expected passes 112
# of expected failures 14

Running target unix/-m64

=== gfortran Summary for unix/-m64 ===

# of expected passes 110
# of expected failures 14
# of unsupported tests 2

=== gfortran Summary ===

# of expected passes 222
# of expected failures 28
# of unsupported tests 2
/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/testsuite/gfortran/../../gfortran
 version 5.0.0 20141109 (experimental) (GCC)

=== libgomp tests ===

Running target unix/-m32

=== libgomp Summary for unix/-m32 ===

# of expected passes 49

Running target unix/-m64

=== libgomp Summary for unix/-m64 ===

# of expected passes 49

=== libgomp Summary ===

# of expected passes 98

Compiler version: 5.0.0 20141109 (experimental) (GCC)
Platform: x86_64-apple-darwin13.4.0
configure flags: --prefix=/sw --prefix=/sw/lib/gcc5.0
--mandir=/sw/share/man --infodir=/sw/lib/gcc5.0/info
--enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw
--with-libiconv-prefix=/sw --with-isl=/sw --without-cloog
--with-mpc=/sw --with-system-zlib --x-includes=/usr/X11R6/include
--x-libraries=/usr/X11R6/lib --program-suffix=-fsf-5.0


On Mon, Nov 10, 2014 at 2:27 PM, Jack Howarth howarth.at@gmail.com wrote:
  Is the current isl 0.12.2 in infrastructure entirely sufficient
 to replace cloog-isl. or should the ABI compatibility changes be made
 to graphite to allow gcc 5.0 to be transitioned to the isl 0.14
 release? Especially if any graphite changes might be made before the
 gcc 5.0 release that could leverage new functionalities in isl 0.14.
 Jack


 On Sun, Nov 9, 2014 at 12:16 PM, Roman Gareev gareevro...@gmail.com wrote:
 Hi Tobias,

 I've attached a patch which removes using of CLooG library from
 Graphite. Is it fine for trunk?


 --
 Cheers, Roman Gareev.
Index: gcc/graphite-interchange.c
===
--- gcc/graphite-interchange.c  (revision 217330)
+++ gcc/graphite-interchange.c  (working copy)
@@ -30,13 +30,7 @@ along with GCC; see the file COPYING3.  
 #include isl/union_map.h
 #include isl/ilp.h

Re: [PATCH][Revisedx2] Fix PR63750

[Jack Howarth]

Also confirmed that FX's proposed string.diff patch solves both
PR63699 and PR63750 on x86_64-apple-darwin13 against Xcode 6.1.

On Mon, Nov 10, 2014 at 9:58 AM, FX fxcoud...@gmail.com wrote:
 My knowledge of C++ is limited, but I think this additional patch to 
 wide-int.h is the proper fix to the issue reported by Jack, no?
 I’m bootstrapping it right now, it already passed stage 2.

 Boostrapped succeeded on x86_64-apple-darwin14.
 OK to commit to trunk?

Re: RFC: Update ISL under gcc/infrastructure/ ? // Remove CLooG?

[Jack Howarth]

 Is the current isl 0.12.2 in infrastructure entirely sufficient
to replace cloog-isl. or should the ABI compatibility changes be made
to graphite to allow gcc 5.0 to be transitioned to the isl 0.14
release? Especially if any graphite changes might be made before the
gcc 5.0 release that could leverage new functionalities in isl 0.14.
Jack


On Sun, Nov 9, 2014 at 12:16 PM, Roman Gareev gareevro...@gmail.com wrote:
 Hi Tobias,

 I've attached a patch which removes using of CLooG library from
 Graphite. Is it fine for trunk?


 --
 Cheers, Roman Gareev.

Re: [PATCH][Revisedx2] Fix PR63750

[Jack Howarth]

])
 ^
../../gcc-5.0-20141107/gcc/rtl.h:398:5: note: array 'hwint' declared here
HOST_WIDE_INT hwint[1];
^
../../gcc-5.0-20141107/gcc/hwint.h:58:26: note: expanded from macro
'HOST_WIDE_INT'
#   define HOST_WIDE_INT long long
 ^
In file included from ../../gcc-5.0-20141107/gcc/simplify-rtx.c:25:
In file included from ../../gcc-5.0-20141107/gcc/rtl.h:27:
In file included from ../../gcc-5.0-20141107/gcc/real.h:25:
../../gcc-5.0-20141107/gcc/wide-int.h:2132:10: error: call to 'min' is ambiguous
  return min (x, y, SIGNED);
 ^~~
../../gcc-5.0-20141107/gcc/simplify-rtx.c:3898:17: note: in
instantiation of function template specialization
'wi::sminstd::__1::pairrtx_def *,
  machine_mode, std::__1::pairrtx_def *, machine_mode ' requested here
  result = wi::smin (pop0, pop1);
   ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/algorithm:2536:1:
note: candidate function [with _Tp
  = std::__1::pairrtx_def *, machine_mode, _Compare = signop_e]
min(const _Tp __a, const _Tp __b, _Compare __comp)
^
../../gcc-5.0-20141107/gcc/wide-int.h:2116:5: note: candidate function
[with T1 = std::__1::pairrtx_def *, machine_mode, T2 =
std::__1::pairrtx_def *,
  machine_mode]
wi::min (const T1 x, const T2 y, signop sgn)
^
../../gcc-5.0-20141107/gcc/wide-int.h:2163:10: error: call to 'max' is ambiguous
  return max (x, y, SIGNED);
 ^~~
../../gcc-5.0-20141107/gcc/simplify-rtx.c:3902:17: note: in
instantiation of function template specialization
'wi::smaxstd::__1::pairrtx_def *,
  machine_mode, std::__1::pairrtx_def *, machine_mode ' requested here
  result = wi::smax (pop0, pop1);
   ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/algorithm:2600:1:
note: candidate function [with _Tp
  = std::__1::pairrtx_def *, machine_mode, _Compare = signop_e]
max(const _Tp __a, const _Tp __b, _Compare __comp)
^
../../gcc-5.0-20141107/gcc/wide-int.h:2147:5: note: candidate function
[with T1 = std::__1::pairrtx_def *, machine_mode, T2 =
std::__1::pairrtx_def *,
  machine_mode]
wi::max (const T1 x, const T2 y, signop sgn)
^
../../gcc-5.0-20141107/gcc/wide-int.h:2140:10: error: call to 'min' is ambiguous
  return min (x, y, UNSIGNED);
 ^~~
../../gcc-5.0-20141107/gcc/simplify-rtx.c:3906:17: note: in
instantiation of function template specialization
'wi::uminstd::__1::pairrtx_def *,
  machine_mode, std::__1::pairrtx_def *, machine_mode ' requested here
  result = wi::umin (pop0, pop1);
   ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/algorithm:2536:1:
note: candidate function [with _Tp
  = std::__1::pairrtx_def *, machine_mode, _Compare = signop_e]
min(const _Tp __a, const _Tp __b, _Compare __comp)
^
../../gcc-5.0-20141107/gcc/wide-int.h:2116:5: note: candidate function
[with T1 = std::__1::pairrtx_def *, machine_mode, T2 =
std::__1::pairrtx_def *,
  machine_mode]
wi::min (const T1 x, const T2 y, signop sgn)
^
../../gcc-5.0-20141107/gcc/wide-int.h:2171:10: error: call to 'max' is ambiguous
  return max (x, y, UNSIGNED);
 ^~~
../../gcc-5.0-20141107/gcc/simplify-rtx.c:3910:17: note: in
instantiation of function template specialization
'wi::umaxstd::__1::pairrtx_def *,
  machine_mode, std::__1::pairrtx_def *, machine_mode ' requested here
  result = wi::umax (pop0, pop1);
   ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/algorithm:2600:1:
note: candidate function [with _Tp
  = std::__1::pairrtx_def *, machine_mode, _Compare = signop_e]
max(const _Tp __a, const _Tp __b, _Compare __comp)
^
../../gcc-5.0-20141107/gcc/wide-int.h:2147:5: note: candidate function
[with T1 = std::__1::pairrtx_def *, machine_mode, T2 =
std::__1::pairrtx_def *,
  machine_mode]
wi::max (const T1 x, const T2 y, signop sgn)
^
32 warnings and 4 errors generated.

I think we are better off for the moment going with the conservative
fix (as only two files in all of gcc need it).
   Jack

On Sun, Nov 9, 2014 at 9:53 AM, Iain Sandoe i...@codesourcery.com wrote:
 Hi Jack,

 comments below apply also to the patch for PR63699

 On 7 Nov 2014, at 17:13, Jack Howarth wrote:

  The attached revised patch eliminates the compilation error...

 error: use of undeclared
  identifier 'do_not_use_toupper_with_safe_ctype'

 on x86_64-apple-darwin14 when bootstrapping using the Clang 6.0
 compiler by moving the include for strings earlier.
  Okay for gcc trunk?
  Jack
 PR63750_v3.patch

 Since you have two instances of this (and given that the other required 
 headers are included in system.h)
 ISTM, that the right place for this (and the fix for PR63699) is in system.h 
 with appropriate guards

Re: patch to fix PR63620

[Jack Howarth]

I don't see any regressions in the libjava test suite on
x86_64-apple-darwin14 at r217265 for -m32/-m64 regression testing but
I also have...

https://gcc.gnu.org/bugzilla/attachment.cgi?id=33843 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63622#c3

to prevent alias creation on targets that don't support aliasing and

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534#c50

to eliminate breakage of the asan tests at -m32 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63773 installed in my
tree.

On Sun, Nov 9, 2014 at 3:08 PM, H.J. Lu hjl.to...@gmail.com wrote:
 On Sun, Nov 9, 2014 at 8:47 AM, Vladimir Makarov vmaka...@redhat.com wrote:
 The following patch solves PR63620.  The details can be found

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

 The patch is more than just the problem solution.  It adds global live
 analysis for pseudos when it is necessary (live info change on a BB
 border triggers it).  The patch opens a door for global optimizations
 and transformations in LRA and it will be also useful for performance
 problems reported by people in coming LRA rematerialization.

 The impact on compiler time is insignificant about 0.3% on whole
 SPEC2000 compilation (and about the same on a compilation of 500K
 lines FORTRAN file).

 The patch was successfully bootstrapped on x86/x86-64, ppc64, and ARM and
 tested on x86/x86-64 and ppc64.

 Committed as rev. 217265.


 2014-11-09  Vladimir Makarov  vmaka...@redhat.com

 PR rtl-optimization/63620
 * lra-constraints.c (substitute_pseudo): Add prefix lra_ to the
 name.  Move to lra.c.  Make it external.
 (substitute_pseudo_within_insn): Ditto.
 (inherit_reload_reg, split_reg, remove_inheritance_pseudos): Use
 the new names.
 (undo_optional_reloads): Ditto.
 * lra-int.h (lra_dump_bitmap_with_title, lra_substitute_pseudo):
 New prototypes.
 (lra_substitute_pseudo_within_insn): Ditto.
 * lra-lives.c (bb_killed_pseudos, bb_gen_pseudos): New.
 (mark_regno_live): Add parameter.  Update bb_gen_pseudos.
 (mark_regno_dead): Add parameter.  Update bb_gen_pseudos and
 bb_killed_pseudos.
 (struct bb_data, bb_data_t, bb_data): New.
 (get_bb_data, get_bb_data_by_index): Ditto.
 (all_hard_regs_bitmap): New.
 (live_trans_fun, live_con_fun_0, live_con_fun_n, all_blocks): New.
 (initiate_live_solver, finish_live_solver): New.
 (process_bb_lives): Change return type.  Add code updating local
 live data and removing dead insns.  Pass new argument to
 mark_regno_live and mark_regno_dead.  Check changing bb pseudo
 life info.  Return the result.
 (lra_create_live_ranges): Add code to do global pseudo live
 analysis.
 (lra_live_ranges_init): Call initiate_live_solver.
 (lra_live_ranges_finish): Call finish_live_solver.
 * lra.c (lra_dump_bitmap_with_title): New.
 (lra_substitute_pseudo, lra_substitute_pseudo_within_insn): Move
 from lra-constraints.c.

 It caused libjava failures:

 FAIL: Array_3 execution - source compiled test
 FAIL: Array_3 -findirect-dispatch execution - source compiled test
 FAIL: Array_3 -O3 -findirect-dispatch execution - source compiled test
 FAIL: Divide_2 execution - source compiled test
 FAIL: Divide_2 -findirect-dispatch execution - source compiled test

 on Linux/ia32.

 --
 H.J.

Re: [PATCH] Don't bootstrap libcc1

[Jack Howarth]

Dominique,
  I thought from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63773#c1 that you were
having clean bootstraps on darwin. I have tested
x86_64-apple-darwin11/12/13/14 without issues in the creation of
libcc1.0

% otool -L libcc1.0.so
libcc1.0.so:
/sw/lib/gcc5.0/lib/libstdc++.6.dylib (compatibility version 7.0.0,
current version 7.21.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 1213.0.0)
/sw/lib/gcc5.0/lib/libgcc_s.1.dylib (compatibility version 1.0.0,
current version 1.0.0)

except for the oddity that one isn't being created in the -m32
multilib. Is this a hard bootstrap failure?
  Jack
ps From build log I see...

libtool: link:
/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/./gcc/xg++
-B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/./gcc/ -nostdinc++
-nostdinc++ 
-I/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin13.4.0/libstdc++-v3/include/x86_64-apple-darwin13.4.0
-I/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin13.4.0/libstdc++-v3/include
-I/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5.0-20141107/libstdc++-v3/libsupc++
-I/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5.0-20141107/libstdc++-v3/include/backward
-I/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5.0-20141107/libstdc++-v3/testsuite/util
-L/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin13.4.0/libstdc++-v3/src
-L/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin13.4.0/libstdc++-v3/src/.libs
-L/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin13.4.0/libstdc++-v3/libsupc++/.libs
-B/sw/lib/gcc5.0/x86_64-apple-darwin13.4.0/bin/
-B/sw/lib/gcc5.0/x86_64-apple-darwin13.4.0/lib/ -isystem
/sw/lib/gcc5.0/x86_64-apple-darwin13.4.0/include -isystem
/sw/lib/gcc5.0/x86_64-apple-darwin13.4.0/sys-include-Wl,-undefined
-Wl,dynamic_lookup -o .libs/libcc1.0.so -bundle  .libs/findcomp.o
.libs/libcc1.o .libs/names.o .libs/callbacks.o .libs/connection.o
.libs/marshall.o
-L/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin13.4.0/libstdc++-v3/src
-L/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin13.4.0/libstdc++-v3/src/.libs
-L/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin13.4.0/libstdc++-v3/libsupc++/.libs
 -Wl,-no_pie ../libiberty/pic/libiberty.a
-Wl,-exported_symbols_list,.libs/libcc1-symbols.expsym


On Sat, Nov 8, 2014 at 10:31 AM, Dominique d'Humières
domi...@lps.ens.fr wrote:
 I am still unable to bootstrap darwin14 without revision r216964 reverted. 
 Executing the simplified command

 /opt/gcc/build_w/gcc/xg++ -B/opt/gcc/build_w/gcc/ 
 -L/opt/gcc/build_w/x86_64-apple-darwin14.0.0/libstdc++-v3/src/.libs -o 
 .libs/libcc1.0.so .libs/findcomp.o -static-libstdc++ -static-libgcc

 I get

 ld: file not found: libstdc++.a
 collect2: error: ld returned 1 exit status

 while I see

 [Book15] build_w/libcc1% ls -l 
 /opt/gcc/build_w/x86_64-apple-darwin14.0.0/libstdc++-v3/src/.libs/libstdc++.a
 -rw-r--r--  1 dominiq  staff  9118792 Nov  8 15:30 
 /opt/gcc/build_w/x86_64-apple-darwin14.0.0/libstdc++-v3/src/.libs/libstdc++.a


 What am I missing?

 TIA

 Dominique

Re: [PATCH] Don't bootstrap libcc1

[Jack Howarth]

Iain,
 Any idea why this isn't failing universally? On all of the
machines tested here with 'make bootstrap', the linkage of libcc1.so
finds
the necessary libstdc++ from the set of flags...

-L/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin13.4.0/libstdc++-v3/src
-L/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin13.4.0/libstdc++-v3/src/.libs
-L/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin13.4.0/libstdc++-v3/libsupc++/.libs

as I posted earlier in this thread. Why wouldn't Dominique be getting
those emitted in his build and shouldn't they suffice?
  Jack

On Sat, Nov 8, 2014 at 4:03 PM, Iain Sandoe i...@codesourcery.com wrote:

 On 8 Nov 2014, at 15:41, Jakub Jelinek wrote:

 On Sat, Nov 08, 2014 at 04:31:28PM +0100, Dominique d'Humières wrote:
 I am still unable to bootstrap darwin14 without revision r216964 reverted. 
 Executing the simplified command

 /opt/gcc/build_w/gcc/xg++ -B/opt/gcc/build_w/gcc/ 
 -L/opt/gcc/build_w/x86_64-apple-darwin14.0.0/libstdc++-v3/src/.libs -o 
 .libs/libcc1.0.so .libs/findcomp.o -static-libstdc++ -static-libgcc

 I get

 ld: file not found: libstdc++.a
 collect2: error: ld returned 1 exit status

 while I see

 [Book15] build_w/libcc1% ls -l 
 /opt/gcc/build_w/x86_64-apple-darwin14.0.0/libstdc++-v3/src/.libs/libstdc++.a
 -rw-r--r--  1 dominiq  staff  9118792 Nov  8 15:30 
 /opt/gcc/build_w/x86_64-apple-darwin14.0.0/libstdc++-v3/src/.libs/libstdc++.a


 What am I missing?

 That is for somebody familiar with all the Mach-O weirdnesses to look at,
 I don't see anything wrong with the above g++ invocation.
 Rerun with -v to see how ld is invoked, strace (if Darwin has anything like
 that) it to see why it doesn't find that libstdc++.a ?

 This is not really mach-o related, but a consequence of the way in which GCC 
 specs substitution works.

 Unless the libstdc++-v3/.libs and libsupc++/.libs are visible as -Bx, 
 spec substitution will not work (it's not enough to provide -L).

 This is done elsewhere (e.g. gnattools), it just needs an appropriate 
 addition to the libcc1/Makefile.in

 (will try and take a look later in the week, if no-one else gets to it first).

 Iain

Re: [PATCH] Don't bootstrap libcc1

[Jack Howarth]

Dominique,
That is curious. I wouldn't have thought that the compiler
selection would have had such a radical effect on the linkage flags
emitted for the build directories.
  Jack


On Sat, Nov 8, 2014 at 4:59 PM, Dominique d'Humières domi...@lps.ens.fr wrote:

 Le 8 nov. 2014 à 22:55, Jack Howarth howarth.at@gmail.com a écrit :

 Iain,
 Any idea why this isn't failing universally? On all of the
 machines tested here with 'make bootstrap', the linkage of libcc1.so
 finds
 the necessary libstdc++ from the set of flags...

 -L/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin13.4.0/libstdc++-v3/src
 -L/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin13.4.0/libstdc++-v3/src/.libs
 -L/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin13.4.0/libstdc++-v3/libsupc++/.libs

 as I posted earlier in this thread. Why wouldn't Dominique be getting
 those emitted in his build and shouldn't they suffice?
  Jack

 Because you bootstrap with clang (I confirm it) while I am bootstrapping with 
 gcc 4.9 for Ada.

 Dominique

[PATCH][Revisedx2] Fix PR63750

[Jack Howarth]

  The attached revised patch eliminates the compilation error...

 error: use of undeclared
  identifier 'do_not_use_toupper_with_safe_ctype'

on x86_64-apple-darwin14 when bootstrapping using the Clang 6.0
compiler by moving the include for strings earlier.
  Okay for gcc trunk?
  Jack


PR63750_v3.patch
Description: Binary data

[PATCH]Revised] fix PR63699

[Jack Howarth]

   The attached patch eliminates the compilation error...

 error: use of undeclared
  identifier 'do_not_use_toupper_with_safe_ctype'

on x86_64-apple-darwin14 when bootstrapping using the Clang 6.0
compiler by moving the include of string earlier.
  Okay for gcc trunk?
  Jack


PR63699_v2.patch
Description: Binary data

[PATCH] fix PR63699

[Jack Howarth]

   The attached patch eliminates the compilation error...

 error: use of undeclared
  identifier 'do_not_use_toupper_with_safe_ctype'

on x86_64-apple-darwin14 when bootstrapping using the Clang 6.0
compiler. Okay for gcc trunk?
 Jack


PR63699.patch
Description: Binary data

[PATCH\ Fix PR63750

[Jack Howarth]

   The attached patch eliminates the compilation error...

 error: use of undeclared
  identifier 'do_not_use_toupper_with_safe_ctype'

on x86_64-apple-darwin14 when bootstrapping using the Clang 6.0
compiler. Okay for gcc trunk?
Jack


PR63750.patch
Description: Binary data

[PATCH][Revised] Fix PR63750

[Jack Howarth]

 The revised attached patch, which corrects the placement of the
include for sstream below that of config.h, eliminates the
compilation error...

 error: use of undeclared
  identifier 'do_not_use_toupper_with_safe_ctype'

on x86_64-apple-darwin14 when bootstrapping using the Clang 6.0
compiler. Okay for gcc trunk?


PR63750_v2.patch
Description: Binary data

[PATCH]: backport fix for PR sanitizer/58994

[Jack Howarth]

   The attached patch backports 
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-2013/194748.html
to gcc trunk and eliminates the asan.exp failures at -m64 on darwin. Bootstrap 
and regression tested on 
x86_64-apple-darwin12 and x86_64-apple-darwin13.
Jack
ps Kostya, can you handled the commit? Thanks in advance.

2013-11-14  Kostya Serebryany  k...@google.com
Jack Howarth  howa...@bromo.med.uc.edu

libsanitizer/

PR sanitizer/58994
Backport from upstream revision 194573
* asan/asan_interceptors.cc (COMMON_INTERCEPTOR_ENTER): Fall
back to the original functions in the common libsanitizer
interceptors and the __cxa_atexit() interceptor on Darwin.


Index: libsanitizer/asan/asan_interceptors.cc
===
--- libsanitizer/asan/asan_interceptors.cc  (revision 204753)
+++ libsanitizer/asan/asan_interceptors.cc  (working copy)
@@ -106,12 +106,13 @@ DECLARE_REAL_AND_INTERCEPTOR(void, free,
 #define COMMON_INTERCEPTOR_WRITE_RANGE(ctx, ptr, size) \
   ASAN_WRITE_RANGE(ptr, size)
 #define COMMON_INTERCEPTOR_READ_RANGE(ctx, ptr, size) ASAN_READ_RANGE(ptr, 
size)
-#define COMMON_INTERCEPTOR_ENTER(ctx, func, ...)  \
-  do {\
-if (asan_init_is_running) return REAL(func)(__VA_ARGS__); \
-ctx = 0;  \
-(void) ctx;   \
-ENSURE_ASAN_INITED(); \
+#define COMMON_INTERCEPTOR_ENTER(ctx, func, ...)   \
+  do { \
+if (asan_init_is_running) return REAL(func)(__VA_ARGS__);  \
+ctx = 0;   \
+(void) ctx;\
+if (SANITIZER_MAC  !asan_inited) return REAL(func)(__VA_ARGS__); \
+ENSURE_ASAN_INITED();  \
   } while (false)
 #define COMMON_INTERCEPTOR_FD_ACQUIRE(ctx, fd) \
   do { \
@@ -634,6 +635,9 @@ static void AtCxaAtexit(void *unused) {
 #if ASAN_INTERCEPT___CXA_ATEXIT
 INTERCEPTOR(int, __cxa_atexit, void (*func)(void *), void *arg,
 void *dso_handle) {
+#if SANITIZER_MAC
+  if (!asan_inited) return REAL(__cxa_atexit)(func, arg, dso_handle);
+#endif
   ENSURE_ASAN_INITED();
   int res = REAL(__cxa_atexit)(func, arg, dso_handle);
   REAL(__cxa_atexit)(AtCxaAtexit, 0, 0);
2013-11-14  Kostya Serebryany  k...@google.com
Jack Howarth  howa...@bromo.med.uc.edu

libsanitizer/

PR sanitizer/58994
Backport from upstream revision 194573
* asan/asan_interceptors.cc (COMMON_INTERCEPTOR_ENTER): Fall
back to the original functions in the common libsanitizer
interceptors and the __cxa_atexit() interceptor on Darwin.


Index: libsanitizer/asan/asan_interceptors.cc
===
--- libsanitizer/asan/asan_interceptors.cc  (revision 204753)
+++ libsanitizer/asan/asan_interceptors.cc  (working copy)
@@ -106,12 +106,13 @@ DECLARE_REAL_AND_INTERCEPTOR(void, free,
 #define COMMON_INTERCEPTOR_WRITE_RANGE(ctx, ptr, size) \
   ASAN_WRITE_RANGE(ptr, size)
 #define COMMON_INTERCEPTOR_READ_RANGE(ctx, ptr, size) ASAN_READ_RANGE(ptr, 
size)
-#define COMMON_INTERCEPTOR_ENTER(ctx, func, ...)  \
-  do {\
-if (asan_init_is_running) return REAL(func)(__VA_ARGS__); \
-ctx = 0;  \
-(void) ctx;   \
-ENSURE_ASAN_INITED(); \
+#define COMMON_INTERCEPTOR_ENTER(ctx, func, ...)   \
+  do { \
+if (asan_init_is_running) return REAL(func)(__VA_ARGS__);  \
+ctx = 0;   \
+(void) ctx;\
+if (SANITIZER_MAC  !asan_inited) return REAL(func)(__VA_ARGS__); \
+ENSURE_ASAN_INITED();  \
   } while (false)
 #define COMMON_INTERCEPTOR_FD_ACQUIRE(ctx, fd) \
   do { \
@@ -634,6 +635,9 @@ static void AtCxaAtexit(void *unused) {
 #if ASAN_INTERCEPT___CXA_ATEXIT
 INTERCEPTOR(int, __cxa_atexit, void (*func)(void *), void *arg,
 void *dso_handle) {
+#if SANITIZER_MAC
+  if (!asan_inited) return REAL(__cxa_atexit)(func, arg, dso_handle);
+#endif
   ENSURE_ASAN_INITED();
   int res = REAL(__cxa_atexit)(func, arg, dso_handle);
   REAL(__cxa_atexit)(AtCxaAtexit, 0, 0);

[PATCH] fix PR sanitizer/58994 on darwin via correct linkage

[Jack Howarth]

Currently, the libasan shared library in FSF gcc is linked without the 
Foundation framework
on darwin...

% otool -L /sw/lib/gcc4.9/lib/libasan.1.dylib
/sw/lib/gcc4.9/lib/libasan.1.dylib:
/sw/lib/gcc4.9/lib/libasan.1.dylib (compatibility version 2.0.0, 
current version 2.0.0)
/sw/lib/gcc4.9/lib/libstdc++.6.dylib (compatibility version 7.0.0, 
current version 7.19.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
version 169.3.0)
/sw/lib/gcc4.9/lib/libgcc_s.1.dylib (compatibility version 1.0.0, 
current version 1.0.0)

compared to llvm svn...

% otool -L 
/sw/opt/llvm-3.4/lib/clang/3.4/lib/darwin/libclang_rt.asan_osx_dynamic.dylib
/sw/opt/llvm-3.4/lib/clang/3.4/lib/darwin/libclang_rt.asan_osx_dynamic.dylib:

/sw/opt/llvm-3.4/lib/clang/3.4/lib/darwin/libclang_rt.asan_osx_dynamic.dylib 
(compatibility version 0.0.0, current version 0.0.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation 
(compatibility version 300.0.0, current version 945.18.0)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current 
version 56.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
version 169.3.0)

The attached patch adds the missing linkage of the Foundation framework to 
libasan_la_LDFLAGS
which produces the desired linkage of...

% otool -L /sw/lib/gcc4.9/lib/libasan.1.dylib
/sw/lib/gcc4.9/lib/libasan.1.dylib:
/sw/lib/gcc4.9/lib/libasan.1.dylib (compatibility version 2.0.0, 
current version 2.0.0)
/sw/lib/gcc4.9/lib/libstdc++.6.dylib (compatibility version 7.0.0, 
current version 7.19.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation 
(compatibility version 300.0.0, current version 945.18.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
version 169.3.0)
/sw/lib/gcc4.9/lib/libgcc_s.1.dylib (compatibility version 1.0.0, 
current version 1.0.0)

Bootstrap and regression tested on x86_64-apple-darwin12 against Xcode 5.0.1 at 
r204750. 

Native configuration is x86_64-apple-darwin12.5.0

=== g++ tests ===


Running target unix/-m32

=== g++ Summary for unix/-m32 ===

# of expected passes481
# of unsupported tests  132

Running target unix/-m64

=== g++ Summary for unix/-m64 ===

# of expected passes481
# of unsupported tests  132

=== g++ Summary ===

# of expected passes962
# of unsupported tests  264
/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/gcc/testsuite/g++/../../xg++  
version 4.9.0 20131113 (experimental) (GCC) 

=== gcc tests ===


Running target unix/-m32

=== gcc Summary for unix/-m32 ===

# of expected passes326
# of unsupported tests  101

Running target unix/-m64

=== gcc Summary for unix/-m64 ===

# of expected passes326
# of unsupported tests  101

=== gcc Summary ===

# of expected passes652
# of unsupported tests  202
/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/gcc/xgcc  version 4.9.0 
20131113 (experimental) (GCC) 

Compiler version: 4.9.0 20131113 (experimental) (GCC) 
Platform: x86_64-apple-darwin12.5.0
configure flags: --prefix=/sw --prefix=/sw/lib/gcc4.9 --mandir=/sw/share/man 
--infodir=/sw/lib/gcc4.9/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=yes --x-includes=/usr/X11R6/include 
--x-libraries=/usr/X11R6/lib --program-suffix=-fsf-4.9

   This change is sufficient to suppress the failures in sanitizer/PR58994 at 
-m64. Okay for
gcc trunk after libsanitizer is synced with the alternative fix from

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-2013/194748.html

so that we are following the norms for linkage on darwin and adhere closer to 
the llvm
libsanitizer build approach for libasan?
   Jack
ps Note that -Wl,-framework,Foundation is used to prevent libtool from 
munging the
the flags.

libsanitizer/

2013-11-13  Jack Howarth  howa...@bromo.med.uc.edu

PR sanitizer/58994
* asan/Makefile.am (libasan_la_LDFLAGS): Link to Foundation framework 
on darwin.
* asan/Makefile.in: Regenerate.


Index: libsanitizer/asan/Makefile.am
===
--- libsanitizer/asan/Makefile.am   (revision 204750)
+++ libsanitizer/asan/Makefile.am   (working copy)
@@ -43,7 +43,11 @@ libasan_la_LIBADD = $(top_builddir)/sani
 endif
 libasan_la_LIBADD += $(LIBSTDCXX_RAW_CXX_LDFLAGS)
 
+if USING_MAC_INTERPOSE
+libasan_la_LDFLAGS = -version-info `grep -v '^\#' $(srcdir)/libtool-version` 
-Wl,-framework,Foundation -lpthread -ldl
+else
 libasan_la_LDFLAGS = -version-info `grep -v '^\#' $(srcdir)/libtool

Re: libsanitizer merge from upstream r191666

[Jack Howarth]

On Mon, Nov 04, 2013 at 06:47:13AM -0800, Konstantin Serebryany wrote:
 +glider, our Mac expert.
 
 Hi Jack,
 
 This patch has not been tested on Mac and we generally do not claim
 that gcc-asan is supported on Mac.
 clang-asan *is* supported on Mac and our bots are green (this patch is
 a merge of the sources which are regularly tested on Mac,
 but the build procedure is different).
 
 The failing assertion is weird, I haven't seen it since last year
 (https://code.google.com/p/address-sanitizer/issues/detail?id=117),
 but Alexander should know more.
 
 What is your version of Mac OS?

I am testing on MacOS X 10.8.5 with FSF gcc trunk built as...

% gcc-fsf-4.9 -v
Using built-in specs.
COLLECT_GCC=gcc-fsf-4.9
COLLECT_LTO_WRAPPER=/sw/lib/gcc4.9/libexec/gcc/x86_64-apple-darwin12.5.0/4.9.0/lto-wrapper
Target: x86_64-apple-darwin12.5.0
Configured with: ../gcc-4.9-20131101/configure --prefix=/sw 
--prefix=/sw/lib/gcc4.9 --mandir=/sw/share/man --infodir=/sw/lib/gcc4.9/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=yes --x-includes=/usr/X11R6/include 
--x-libraries=/usr/X11R6/lib --program-suffix=-fsf-4.9
Thread model: posix
gcc version 4.9.0 20131101 (experimental) (GCC) 

 
 --kcc
 
 On Sat, Nov 2, 2013 at 10:25 AM, Jack Howarth howa...@bromo.med.uc.edu 
 wrote:
  On Fri, Nov 01, 2013 at 04:13:05PM -0700, Konstantin Serebryany wrote:
  Jukub,
 
  This works!
  New patch attached.
 
  Konstantin,
 This patch, when applied on top of r204305, bootstraps fine on 
  x86_64-apple-darwin12 but
  produces a lot of regressions with...
 
  make -k check RUNTESTFLAGS=asan.exp --target_board=unix'{-m64}'
 
  Native configuration is x86_64-apple-darwin12.5.0
 
  === g++ tests ===
 
 
  Running target unix/-m64
  FAIL: c-c++-common/asan/global-overflow-1.c  -O0  execution test
  FAIL: c-c++-common/asan/global-overflow-1.c  -O1  execution test
  FAIL: c-c++-common/asan/global-overflow-1.c  -O2  execution test
  FAIL: c-c++-common/asan/global-overflow-1.c  -O3 -fomit-frame-pointer  
  execution test
  FAIL: c-c++-common/asan/global-overflow-1.c  -O3 -g  execution test
  FAIL: c-c++-common/asan/global-overflow-1.c  -Os  execution test
  FAIL: c-c++-common/asan/global-overflow-1.c  -O2 -flto -flto-partition=none 
   execution test
  FAIL: c-c++-common/asan/global-overflow-1.c  -O2 -flto  execution test
  FAIL: c-c++-common/asan/heap-overflow-1.c  -O0  execution test
  FAIL: c-c++-common/asan/heap-overflow-1.c  -O1  execution test
  FAIL: c-c++-common/asan/heap-overflow-1.c  -O2  execution test
  FAIL: c-c++-common/asan/heap-overflow-1.c  -O3 -fomit-frame-pointer  
  execution test
  FAIL: c-c++-common/asan/heap-overflow-1.c  -O3 -g  execution test
  FAIL: c-c++-common/asan/heap-overflow-1.c  -Os  execution test
  FAIL: c-c++-common/asan/heap-overflow-1.c  -O2 -flto -flto-partition=none  
  execution test
  FAIL: c-c++-common/asan/heap-overflow-1.c  -O2 -flto  execution test
  FAIL: c-c++-common/asan/memcmp-1.c  -O0  execution test
  FAIL: c-c++-common/asan/memcmp-1.c  -O1  execution test
  FAIL: c-c++-common/asan/memcmp-1.c  -O2  execution test
  FAIL: c-c++-common/asan/memcmp-1.c  -O3 -fomit-frame-pointer  execution test
  FAIL: c-c++-common/asan/memcmp-1.c  -O3 -g  execution test
  FAIL: c-c++-common/asan/memcmp-1.c  -Os  execution test
  FAIL: c-c++-common/asan/memcmp-1.c  -O2 -flto -flto-partition=none  
  execution test
  FAIL: c-c++-common/asan/memcmp-1.c  -O2 -flto  execution test
  FAIL: c-c++-common/asan/null-deref-1.c  -O0  execution test
  FAIL: c-c++-common/asan/null-deref-1.c  -O1  execution test
  FAIL: c-c++-common/asan/null-deref-1.c  -O2  execution test
  FAIL: c-c++-common/asan/null-deref-1.c  -O3 -fomit-frame-pointer  execution 
  test
  FAIL: c-c++-common/asan/null-deref-1.c  -O3 -g  execution test
  FAIL: c-c++-common/asan/null-deref-1.c  -Os  execution test
  FAIL: c-c++-common/asan/null-deref-1.c  -O2 -flto -flto-partition=none  
  execution test
  FAIL: c-c++-common/asan/null-deref-1.c  -O2 -flto  execution test
  FAIL: c-c++-common/asan/sanity-check-pure-c-1.c  -O0  execution test
  FAIL: c-c++-common/asan/sanity-check-pure-c-1.c  -O1  execution test
  FAIL: c-c++-common/asan/sanity-check-pure-c-1.c  -O2  execution test
  FAIL: c-c++-common/asan/sanity-check-pure-c-1.c  -O3 -fomit-frame-pointer  
  execution test
  FAIL: c-c++-common/asan/sanity-check-pure-c-1.c  -O3 -g  execution test
  FAIL: c-c++-common/asan/sanity-check-pure-c-1.c  -Os  execution test
  FAIL: c-c++-common/asan/sanity-check-pure-c-1.c  -O2 -flto 
  -flto-partition=none  execution test
  FAIL: c-c++-common/asan/sanity-check-pure-c-1.c  -O2 -flto  execution test
  FAIL: c-c++-common/asan/sleep-before-dying-1.c  -O2  execution test
  FAIL: c-c++-common/asan/sleep-before-dying-1.c  -O2 -flto 
  -flto-partition=none  execution test
  FAIL: c-c++-common/asan/sleep-before-dying-1

Re: libsanitizer merge from upstream r191666

[Jack Howarth]

On Fri, Nov 01, 2013 at 04:13:05PM -0700, Konstantin Serebryany wrote:
 Jukub,
 
 This works!
 New patch attached.

Konstantin,
   This patch, when applied on top of r204305, bootstraps fine on 
x86_64-apple-darwin12 but
produces a lot of regressions with...

make -k check RUNTESTFLAGS=asan.exp --target_board=unix'{-m64}'

Native configuration is x86_64-apple-darwin12.5.0

=== g++ tests ===


Running target unix/-m64
FAIL: c-c++-common/asan/global-overflow-1.c  -O0  execution test
FAIL: c-c++-common/asan/global-overflow-1.c  -O1  execution test
FAIL: c-c++-common/asan/global-overflow-1.c  -O2  execution test
FAIL: c-c++-common/asan/global-overflow-1.c  -O3 -fomit-frame-pointer  
execution test
FAIL: c-c++-common/asan/global-overflow-1.c  -O3 -g  execution test
FAIL: c-c++-common/asan/global-overflow-1.c  -Os  execution test
FAIL: c-c++-common/asan/global-overflow-1.c  -O2 -flto -flto-partition=none  
execution test
FAIL: c-c++-common/asan/global-overflow-1.c  -O2 -flto  execution test
FAIL: c-c++-common/asan/heap-overflow-1.c  -O0  execution test
FAIL: c-c++-common/asan/heap-overflow-1.c  -O1  execution test
FAIL: c-c++-common/asan/heap-overflow-1.c  -O2  execution test
FAIL: c-c++-common/asan/heap-overflow-1.c  -O3 -fomit-frame-pointer  execution 
test
FAIL: c-c++-common/asan/heap-overflow-1.c  -O3 -g  execution test
FAIL: c-c++-common/asan/heap-overflow-1.c  -Os  execution test
FAIL: c-c++-common/asan/heap-overflow-1.c  -O2 -flto -flto-partition=none  
execution test
FAIL: c-c++-common/asan/heap-overflow-1.c  -O2 -flto  execution test
FAIL: c-c++-common/asan/memcmp-1.c  -O0  execution test
FAIL: c-c++-common/asan/memcmp-1.c  -O1  execution test
FAIL: c-c++-common/asan/memcmp-1.c  -O2  execution test
FAIL: c-c++-common/asan/memcmp-1.c  -O3 -fomit-frame-pointer  execution test
FAIL: c-c++-common/asan/memcmp-1.c  -O3 -g  execution test
FAIL: c-c++-common/asan/memcmp-1.c  -Os  execution test
FAIL: c-c++-common/asan/memcmp-1.c  -O2 -flto -flto-partition=none  execution 
test
FAIL: c-c++-common/asan/memcmp-1.c  -O2 -flto  execution test
FAIL: c-c++-common/asan/null-deref-1.c  -O0  execution test
FAIL: c-c++-common/asan/null-deref-1.c  -O1  execution test
FAIL: c-c++-common/asan/null-deref-1.c  -O2  execution test
FAIL: c-c++-common/asan/null-deref-1.c  -O3 -fomit-frame-pointer  execution test
FAIL: c-c++-common/asan/null-deref-1.c  -O3 -g  execution test
FAIL: c-c++-common/asan/null-deref-1.c  -Os  execution test
FAIL: c-c++-common/asan/null-deref-1.c  -O2 -flto -flto-partition=none  
execution test
FAIL: c-c++-common/asan/null-deref-1.c  -O2 -flto  execution test
FAIL: c-c++-common/asan/sanity-check-pure-c-1.c  -O0  execution test
FAIL: c-c++-common/asan/sanity-check-pure-c-1.c  -O1  execution test
FAIL: c-c++-common/asan/sanity-check-pure-c-1.c  -O2  execution test
FAIL: c-c++-common/asan/sanity-check-pure-c-1.c  -O3 -fomit-frame-pointer  
execution test
FAIL: c-c++-common/asan/sanity-check-pure-c-1.c  -O3 -g  execution test
FAIL: c-c++-common/asan/sanity-check-pure-c-1.c  -Os  execution test
FAIL: c-c++-common/asan/sanity-check-pure-c-1.c  -O2 -flto -flto-partition=none 
 execution test
FAIL: c-c++-common/asan/sanity-check-pure-c-1.c  -O2 -flto  execution test
FAIL: c-c++-common/asan/sleep-before-dying-1.c  -O2  execution test
FAIL: c-c++-common/asan/sleep-before-dying-1.c  -O2 -flto -flto-partition=none  
execution test
FAIL: c-c++-common/asan/sleep-before-dying-1.c  -O2 -flto  execution test
FAIL: c-c++-common/asan/stack-overflow-1.c  -O0  execution test
FAIL: c-c++-common/asan/stack-overflow-1.c  -O1  execution test
FAIL: c-c++-common/asan/stack-overflow-1.c  -O2  execution test
FAIL: c-c++-common/asan/stack-overflow-1.c  -O3 -fomit-frame-pointer  execution 
test
FAIL: c-c++-common/asan/stack-overflow-1.c  -O3 -g  execution test
FAIL: c-c++-common/asan/stack-overflow-1.c  -Os  execution test
FAIL: c-c++-common/asan/stack-overflow-1.c  -O2 -flto -flto-partition=none  
execution test
FAIL: c-c++-common/asan/stack-overflow-1.c  -O2 -flto  execution test
FAIL: c-c++-common/asan/strip-path-prefix-1.c  -O2  execution test
FAIL: c-c++-common/asan/strip-path-prefix-1.c  -O2 -flto -flto-partition=none  
execution test
FAIL: c-c++-common/asan/strip-path-prefix-1.c  -O2 -flto  execution test
FAIL: c-c++-common/asan/strncpy-overflow-1.c  -O0  execution test
FAIL: c-c++-common/asan/strncpy-overflow-1.c  -O1  execution test
FAIL: c-c++-common/asan/strncpy-overflow-1.c  -O2  execution test
FAIL: c-c++-common/asan/strncpy-overflow-1.c  -O3 -fomit-frame-pointer  
execution test
FAIL: c-c++-common/asan/strncpy-overflow-1.c  -O3 -g  execution test
FAIL: c-c++-common/asan/strncpy-overflow-1.c  -Os  execution test
FAIL: c-c++-common/asan/strncpy-overflow-1.c  -O2 -flto -flto-partition=none  
execution test
FAIL: c-c++-common/asan/strncpy-overflow-1.c  -O2 -flto  execution test
FAIL: c-c++-common/asan/use-after-free-1.c  -O0  execution test
FAIL: c-c++-common/asan/use-after-free-1.c  -O1  execution test
FAIL: 

Re: [PATCH] Fix pr571518.c test case.

[Jack Howarth]

On Fri, Jul 05, 2013 at 09:25:52AM -0700, Mike Stump wrote:
 On Jul 4, 2013, at 9:17 AM, Marcus Shawcroft marcus.shawcr...@arm.com wrote:
 * gcc.dg/pr57518.c: Adjust scan-rtl-dump-not pattern.
 
 [ If you want a review or need an approval, be sure to ask Ok?  Just in case 
 you forgot...  ]  Ok.
 
 Thanks.

Looks like this fix should have been applied to the gcc-4_8-branch as well...

http://gcc.gnu.org/ml/gcc-testresults/2013-10/msg01077.html

Too late for gcc 4.8.2 I guess but after the branch reopens...

2013-07-04  Marcus Shawcroft  marcus.shawcr...@arm.com

* gcc.dg/pr57518.c: Adjust scan-rtl-dump-not pattern.
diff --git a/gcc/testsuite/gcc.dg/pr57518.c b/gcc/testsuite/gcc.dg/pr57518.c
index 4c84a85..47e819c 100644
--- a/gcc/testsuite/gcc.dg/pr57518.c
+++ b/gcc/testsuite/gcc.dg/pr57518.c
@@ -2,7 +2,7 @@
 
 /* { dg-do compile } */
 /* { dg-options -O2 -fdump-rtl-ira } */
-/* { dg-final { scan-rtl-dump-not REG_EQUIV.*mem.*\ip\ ira } } */
+/* { dg-final { scan-rtl-dump-not REG_EQUIV\[^\n\]*mem\[^\n\]*\ip\ ira } 
} */
 
 char ip[10];
 int total;

should be applied there for gcc 4.8.3.
Jack

Re: [i386, AVX-512F, pr58269] Partial fix for PR58269: properly initialize last EXT REX SSE register.

[Jack Howarth]

On Fri, Sep 06, 2013 at 11:04:45AM +0100, Iain Sandoe wrote:
 Hi Kirill,
 
 Thanks for Ilya's input on the PR thread.
 
 We've done some testing/checking across the Darwin versions last night and 
 I've bootstrapped all langs including Ada, and tested the patch below 
 (together with the fragment you posted earlier) on Darwin12.
 
  On Fri, Sep 6, 2013 at 10:34 AM, Kirill Yukhin kirill.yuk...@gmail.com 
  wrote:
 
  Here is a patch to fix pr58269.
  Actually this is not a full fix, but an obvious part.
 
 Here's what I propose for the remainder of the fix (FAOD, I cannot approve 
 the Darwin changes).
 
 
 
 Darwin is supposed to follow the System V psABI for x86_64 and, AFAICT for 
 Darwin9, 10, 11 and 12 it is complying for function calls involving xmm0-7 
 (additional float args are, indeed, placed on the stack).  Ergo, saving 
 xmm8-15 in __builtin_apply_args() only consumes time and stack space - the 
 content is not part of the call.
 
 As a fall-back; if I've missed a subtlety and, for some reason, we need to 
 adjust the xmm set saved for compatibility with an older (gcc-4.2 based) 
 system compiler, then we can override SSE_REGPARM_MAX in i386/darwin*.h for 
 the relevant system version.
 
 Losing TARGET_MACHO conditional code is always nice :)
 
 Mike: Actually, since this seems to have uncovered a pre-existing wrong code 
 bug, perhaps (this part of the) fix should also be applied to open branches?
 
 gcc:
 
   PR target/58269
   config/i386/i386.c (ix86_function_arg_regno_p): Make Darwin use the
   xmm register set described in the psABI.
 
 diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
 index a8d70bc..e68b3f9 100644
 --- a/gcc/config/i386/i386.c
 +++ b/gcc/config/i386/i386.c
 @@ -5706,17 +5706,9 @@ ix86_function_arg_regno_p (int regno)
(regno  FIRST_SSE_REG + SSE_REGPARM_MAX)));
  }
  
 -  if (TARGET_MACHO)
 -{
 -  if (SSE_REGNO_P (regno)  TARGET_SSE)
 -return true;
 -}
 -  else
 -{
 -  if (TARGET_SSE  SSE_REGNO_P (regno)
 -   (regno  FIRST_SSE_REG + SSE_REGPARM_MAX))
 -return true;
 -}
 +  if (TARGET_SSE  SSE_REGNO_P (regno)
 +   (regno  FIRST_SSE_REG + SSE_REGPARM_MAX))
 +return true;
  
/* TODO: The function should depend on current function ABI but
   builtins.c would need updating then. Therefore we use the

Iain,
   Do you plan to commit this to gcc trunk to unbreak the darwin bootstrap for 
libobjc?
The change seems to work fine here on x86_64-apple-darwin12...

http://gcc.gnu.org/ml/gcc-testresults/2013-09/msg00610.html

  Jack

Re: [PATCH] Accept ISL 0.12

[Jack Howarth]

On Tue, Sep 03, 2013 at 12:04:51PM +0200, Richard Biener wrote:
 
 The following patch makes us accept ISL 0.12.
 
 Bootstrapped and tested on x86_64-unknown-linux-gnu (with using ISL 0.12),
 applied as obvious.

Richard,
   Does this also accept isl 0.12.1 as that is the current bug fix release...

http://repo.or.cz/w/isl.git/shortlog/0e737ed0b35803685e9ebcfd8c528e00c30bbc43

from upstream.
Jack

 
 Richard.
 
 2013-09-03  Richard Biener  rguent...@suse.de
 
   * configure.ac: Also allow ISL 0.12.
   * configure: Regenerated.
 
 Index: configure.ac
 ===
 *** configure.ac  (revision 202203)
 --- configure.ac  (working copy)
 *** if test x$with_isl != xno 
 *** 1653,1658 
 --- 1653,1661 
 ISL_CHECK_VERSION(0,10)
 if test ${gcc_cv_isl} = no ; then
   ISL_CHECK_VERSION(0,11)
 + if test ${gcc_cv_isl} = no ; then
 +   ISL_CHECK_VERSION(0,12)
 + fi
 fi
 dnl Only execute fail-action, if ISL has been requested.
 ISL_IF_FAILED([
 Index: configure
 ===
 *** configure (revision 202203)
 --- configure (working copy)
 *** $as_echo $gcc_cv_isl 6; }
 *** 5965,5970 
 --- 5965,6019 
 fi
   
   
 + if test ${gcc_cv_isl} = no ; then
 + 
 +   if test ${ENABLE_ISL_CHECK} = yes ; then
 + _isl_saved_CFLAGS=$CFLAGS
 + _isl_saved_LDFLAGS=$LDFLAGS
 + _isl_saved_LIBS=$LIBS
 + 
 + CFLAGS=${_isl_saved_CFLAGS} ${islinc} ${gmpinc}
 + LDFLAGS=${_isl_saved_LDFLAGS} ${isllibs}
 + LIBS=${_isl_saved_LIBS} -lisl
 + 
 + { $as_echo $as_me:${as_lineno-$LINENO}: checking for version 0.12 of 
 ISL 5
 + $as_echo_n checking for version 0.12 of ISL...  6; }
 + if test $cross_compiling = yes; then :
 +   gcc_cv_isl=yes
 + else
 +   cat confdefs.h - _ACEOF conftest.$ac_ext
 + /* end confdefs.h.  */
 + #include isl/version.h
 +#include string.h
 + int
 + main ()
 + {
 + if (strncmp (isl_version (), isl-0.12, strlen (isl-0.12)) != 0)
 +  return 1;
 + 
 +   ;
 +   return 0;
 + }
 + _ACEOF
 + if ac_fn_c_try_run $LINENO; then :
 +   gcc_cv_isl=yes
 + else
 +   gcc_cv_isl=no
 + fi
 + rm -f core *.core core.conftest.* gmon.out bb.out conftest$ac_exeext \
 +   conftest.$ac_objext conftest.beam conftest.$ac_ext
 + fi
 + 
 + { $as_echo $as_me:${as_lineno-$LINENO}: result: $gcc_cv_isl 5
 + $as_echo $gcc_cv_isl 6; }
 + 
 + CFLAGS=$_isl_saved_CFLAGS
 + LDFLAGS=$_isl_saved_LDFLAGS
 + LIBS=$_isl_saved_LIBS
 +   fi
 + 
 + 
 + fi
 fi
   
   

Re: [PATCH] PR57792: Bootstrap darwin13 or later with --with-sysroot to find SDK

[Jack Howarth]

On Wed, Jul 10, 2013 at 02:24:48PM -0700, Mike Stump wrote:
 On Jul 4, 2013, at 7:27 PM, Jack Howarth howa...@bromo.med.uc.edu wrote:
   The attached patch eliminates the problem of the SDK being removed from / 
  in darwin13
  and later by appending --with-sysroot=\`xcrun --show-sdk-path`\ to 
  host_configargs
  in the top-level configure for those cases . Bootstrap tested on 
  x86_64-apple-darwin13. 
  Okay for gcc trunk and gcc-4_8-branch?
 
 Ok.
 
 Thanks.
 
 If you could try a build of the software from src, that'd be nice.

Current gcc trunk now builds fine on darwin13. Thanks for the commit.
 Jack

 
 gcc/trunk:
 Committed revision 200886.
 Committed revision 200890.
 
 src:
 Checking in ChangeLog;
 /cvs/src/src/ChangeLog,v  --  ChangeLog
 new revision: 1.1074; previous revision: 1.1073
 done
 Checking in configure;
 /cvs/src/src/configure,v  --  configure
 new revision: 1.447; previous revision: 1.446
 done
 Checking in configure.ac;
 /cvs/src/src/configure.ac,v  --  configure.ac
 new revision: 1.190; previous revision: 1.189
 done
 
 gcc/branches/gcc-4_8-branch:
 Committed revision 200889.

[PATCH] PR57792: Bootstrap darwin13 or later with --with-sysroot to find SDK

[Jack Howarth]

  The attached patch eliminates the problem of the SDK being removed from / in 
darwin13
and later by appending --with-sysroot=\`xcrun --show-sdk-path`\ to 
host_configargs
in the top-level configure for those cases . Bootstrap tested on 
x86_64-apple-darwin13. 
Okay for gcc trunk and gcc-4_8-branch?
Jack
2013-07-05  Jack Howarth  howa...@bromo.med.uc.edu

PR target/57792
* configure.ac: Use --with-sysroot=\`xcrun --show-sdk-path`\ on 
darwin13 and later.
* configure: Regenerated.

Index: configure.ac
===
--- configure.ac(revision 200683)
+++ configure.ac(working copy)
@@ -2850,6 +2850,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}

Re: [Patch libsanitizer] merge rev 182922 (helps running under qemu)

[Jack Howarth]

On Fri, May 31, 2013 at 04:42:21PM +0200, Christophe Lyon wrote:
 Hi,
 
 I'd like to backport libsanitizer commit #182922:
 Index: sanitizer_common/sanitizer_linux.cc
 ===
 --- sanitizer_common/sanitizer_linux.cc(revision 199453)
 +++ sanitizer_common/sanitizer_linux.cc(working copy)
 @@ -410,7 +410,9 @@ bool MemoryMappingLayout::Next(uptr *sta
CHECK_EQ(*current_++, ' ');
while (IsDecimal(*current_))
  current_++;
 -  CHECK_EQ(*current_++, ' ');
 +  // Qemu may lack the trailing space.
 +  // http://code.google.com/p/address-sanitizer/issues/detail?id=160
 +  // CHECK_EQ(*current_++, ' ');
// Skip spaces.
while (current_  next_line  *current_ == ' ')
  current_++;
 
 It helps handling qemu's output for /proc/self/maps until the
 corresponding patch in qemu is available to developers (it has been
 accepted, but not part of a release yet).
 
 OK to commit in trunk?

Christophe,
   I believe that changes from upstream are generally brought into FSF gcc with 
a 
complete merge of libsanitizer rather than just specific patches. We do seem
to be long past due for remerge with upstream though.
Jack

 
 Thanks,
 
 Christophe

Re: PATCH: PR plugins/56754 some missing plugin headers during installation in gcc 4.8

[Jack Howarth]

On Tue, May 21, 2013 at 05:09:14PM +0200, Jakub Jelinek wrote:
 On Sat, Mar 30, 2013 at 03:17:59PM +0100, Magnus Granberg wrote:
  This patch readd TARGET_H that was removed with revision 188166
  IPA_PROP_H is in use by PLUGIN_HEADERS and did depend on GIMPLE_H that
  did have TARGET_H before it was removed and it was not added to IPA_PROP_H 
  or 
  PLUGIN_HEADERS. See the bug for more info.
 
  2013-03-30  Magnus Granberg zo...@gentoo.org
 
 Two spaces before , instead of just one.
  
  PR plugins/56754
  * Makefile.in (PLUGIN_HEADERS): Add TARGET_H
 
 Missing dot at the end of line, plus it should be $(TARGET_H)
 instead of TARGET_H.
 
 Where has it been tested?

 This has been tested on i386-apple-darwin10, x86_64-apple-darwin10, 
x86_64-apple-darwin11 and
x86_64-apple-darwin12. The resulting gcc 4.8.1svn builds have been used to 
build dragonegg trunk
against gcc 4.8.1svn on x86_64-apple-darwin12.
 
  --- a/gcc/Makefile.in   2013-02-08 10:07:49.0 +0100
  +++ b/gcc/Makefile.in   2013-03-28 03:43:53.343390945 +0100
  @@ -4597,7 +4597,7 @@ PLUGIN_HEADERS = $(TREE_H) $(CONFIG_H) $
 $(C_PRAGMA_H)  $(CPPLIB_H)  $(FUNCTION_H) \
 cppdefault.h flags.h $(MD5_H) params.def params.h prefix.h tree-inline.h 
  \
 $(GIMPLE_PRETTY_PRINT_H) realmpfr.h \
  -  $(IPA_PROP_H) $(RTL_H) $(TM_P_H) $(CFGLOOP_H) $(EMIT_RTL_H) version.h
  +  $(IPA_PROP_H) $(TARGET_H) $(RTL_H) $(TM_P_H) $(CFGLOOP_H) $(EMIT_RTL_H) 
  version.h
   
   # generate the 'build fragment' b-header-vars
   s-header-vars: Makefile
 
 
   Jakub

PING: PATCH: PR plugins/56754 some missing plugin headers during installation in gcc 4.8

[Jack Howarth]

Any chance of this patch getting a review and commit soon so that it
can go into gcc trunk and gcc-4_8-branch?
  Jack


On Sat, Mar 30, 2013 at 03:17:59PM +0100, Magnus Granberg wrote:
 This patch readd TARGET_H that was removed with revision 188166
 IPA_PROP_H is in use by PLUGIN_HEADERS and did depend on GIMPLE_H that
 did have TARGET_H before it was removed and it was not added to IPA_PROP_H or 
 PLUGIN_HEADERS. See the bug for more info.
 
 /Magnus
 
 gcc:
 
 2013-03-30  Magnus Granberg zo...@gentoo.org
 
   PR plugins/56754
   * Makefile.in (PLUGIN_HEADERS): Add TARGET_H
 
 

 --- a/gcc/Makefile.in 2013-02-08 10:07:49.0 +0100
 +++ b/gcc/Makefile.in 2013-03-28 03:43:53.343390945 +0100
 @@ -4597,7 +4597,7 @@ PLUGIN_HEADERS = $(TREE_H) $(CONFIG_H) $
$(C_PRAGMA_H)  $(CPPLIB_H)  $(FUNCTION_H) \
cppdefault.h flags.h $(MD5_H) params.def params.h prefix.h tree-inline.h \
$(GIMPLE_PRETTY_PRINT_H) realmpfr.h \
 -  $(IPA_PROP_H) $(RTL_H) $(TM_P_H) $(CFGLOOP_H) $(EMIT_RTL_H) version.h
 +  $(IPA_PROP_H) $(TARGET_H) $(RTL_H) $(TM_P_H) $(CFGLOOP_H) $(EMIT_RTL_H) 
 version.h
  
  # generate the 'build fragment' b-header-vars
  s-header-vars: Makefile

Re: GCC 4.7.3 Status Report (2013-04-03)

[Jack Howarth]

On Wed, Apr 03, 2013 at 03:23:36PM +0200, Richard Biener wrote:
 
 Status
 ==
 
 The GCC 4.7 branch is ready for a release candidate of GCC 4.7.3
 which I will do tomorrow if no serious issue shows up until then.
 The branch is frozen now, all changes require release manager approval
 until the final release of GCC 4.7.3 which should happen roughly
 one week after the release candidate.
 
 
 Quality Data
 
 
 Priority  #   Change from Last Report
 ---   ---
 P10
 P2   86   +  2
 P36   - 12
 ---   ---
 Total92   - 10
 
 
 Previous Report
 ===
 
 http://gcc.gnu.org/ml/gcc/2012-09/msg00182.html
 
 
 The next report will be sent by me after the release

FYI, http://gcc.gnu.org/ml/gcc-patches/2012-06/msg01181.html to backport the 
fix for PR debug/53453
has been approved since last July but never applied to gcc-4_7-branch...

http://gcc.gnu.org/ml/gcc-patches/2012-06/msg01265.html

If we can't get this into 4.7.3 and it at least go into gcc-4_7-branch when it 
reopens in
hopes of eventually landing in 4.7.4?
  Jack

[PATCH] Fix g++.dg/debug/dwarf2/thunk1.C on darwin

[Jack Howarth]

Darwin does PIC differently than ELF so that the scan-assembler-times
fails for g++.dg/debug/dwarf2/thunk1.C. The attached patch skips the
scan-assembler for *-*-darwin*. Tested on x86_64-apple-darwin12. Okay
for gcc trunk.
  Jack

gcc/testsuite/

2013-03-05  Jack Howarth  howa...@bromo.med.uc.edu

PR debug/53363
* g++.dg/debug/dwarf2/thunk1.C: Skip final scan on darwin.

Index: gcc/testsuite/g++.dg/debug/dwarf2/thunk1.C
===
--- gcc/testsuite/g++.dg/debug/dwarf2/thunk1.C  (revision 196462)
+++ gcc/testsuite/g++.dg/debug/dwarf2/thunk1.C  (working copy)
@@ -1,7 +1,7 @@
 // Test that we don't add the x86 PC thunk to .debug_ranges
 // { dg-do compile { target { { i?86-*-* x86_64-*-* }  ia32 } } }
 // { dg-options -g -fpic -fno-dwarf2-cfi-asm }
-// { dg-final { scan-assembler-times LFB3 5 } }
+// { dg-final { scan-assembler-times LFB3 5 { target { ! *-*-darwin* } } } }
 
 template class T void f(T t) { }
 

Re: [PATCH] Fix remainder of PR bootstrap/56258 on gcc-4_6-branch

[Jack Howarth]

On Wed, Feb 27, 2013 at 06:35:40PM +0100, Gerald Pfeifer wrote:
 On Fri, 22 Feb 2013, Jack Howarth wrote:
 Current gcc-4_6-branch still fails to bootstrap when texinfo 5.0 is 
  installed. The attached patch fixes the remaining instances where @itemx 
  need to be replaced with @item. An additional instance of misplaced 
  brackets was fixed to match current gcc-4_7-branch. Bootstrap tested on 
  x86_64-apple-darwin11. Okay for gcc-4_6-branch?
 
 Yes, I think so.  Perhaps first go for 4.7 and then do 4.6 after a
 day or two.  (Aren't these partially backports from mainline and
 should be labeled as such in the ChangeLog entries?)
 
 Gerald

Gerald,
   No, these are additional instances of the @item instead of @itemx change
which exist in gcc-4_6-branch and gcc-4_7-branch but not gcc trunk. There
is one extra instance in gcc-4_7-branch compared to gcc-4_6-branch...

@@ -5179,7 +5179,7 @@ thus dbg_cnt() returns true always unles
 e.g. With -fdbg-cnt=dce:10,tail_call:0
 dbg_cnt(dce) will return true only for first 10 invocations

-@itemx -fenable-@var{kind}-@var{pass}
+@item -fenable-@var{kind}-@var{pass}
 @itemx -fdisable-@var{kind}-@var{pass}=@var{range-list}
 @opindex fdisable-
 @opindex fenable-

and one additional fix for gcc-4_6-branch...

Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 196218)
+++ gcc/doc/invoke.texi (working copy)
@@ -165,7 +165,7 @@ in the following sections.
 -pipe  -pass-exit-codes  @gol
 -x @var{language}  -v  -###  --help@r{[}=@var{class}@r{[},@dots{}@r{]]}  
--target-help  @gol
 --version -wrapper @@@var{file} -fplugin=@var{file} 
-fplugin-arg-@var{name}=@var{arg}  @gol
--fdump-ada-spec@r{[}-slim@r{]}} -fdump-go-spec=@var{file}
+-fdump-ada-spec@r{[}-slim@r{]} -fdump-go-spec=@var{file}}
 
 @item C Language Options
 @xref{C Dialect Options,,Options Controlling C Dialect}.

that is already fixed in gcc-4_7-branch and trunk.
  Jack

[PATCH] Fix remainder of PR bootstrap/56258 on gcc-4_7-branch

[Jack Howarth]

   Current gcc-4_7-branch still fails to bootstrap when texinfo 5.0 is 
installed.
The attached patch fixes the remaining instances where @itemx need to be 
replaced
with @item. Bootstrap tested on x86_64-apple-darwin12. Okay for gcc-4_7-branch?
  Jack
gcc/

2013-02-22  Jack Howarth  howa...@bromo.med.uc.edu

PR bootstrap/56258
* doc/generic.texi (POINTER_PLUS_EXPR): Use @item instead of @itemx.
(PLUS_EXPR): Likewise.
* doc/cppopts.texi (--help): Likewise.
* doc/invoke.texi (-fenable-@var{kind}-@var{pass}): Likewise.
(-fdump-rtl-cprop_hardreg): Likewise.
(-fdump-rtl-csa): Likewise.
(-fdump-rtl-dce): Likewise.
(-fdump-rtl-dbr): Likewise.
(-fdump-rtl-into_cfglayout): Likewise.
(-fdump-rtl-outof_cfglayout): Likewise.

Index: gcc/doc/generic.texi
===
--- gcc/doc/generic.texi(revision 196215)
+++ gcc/doc/generic.texi(working copy)
@@ -1415,13 +1415,13 @@ generate these expressions anyhow, if it
 not matter.  The type of the operands and that of the result are
 always of @code{BOOLEAN_TYPE} or @code{INTEGER_TYPE}.
 
-@itemx POINTER_PLUS_EXPR
+@item POINTER_PLUS_EXPR
 This node represents pointer arithmetic.  The first operand is always
 a pointer/reference type.  The second operand is always an unsigned
 integer type compatible with sizetype.  This is the only binary
 arithmetic operand that can operate on pointer types.
 
-@itemx PLUS_EXPR
+@item PLUS_EXPR
 @itemx MINUS_EXPR
 @itemx MULT_EXPR
 These nodes represent various binary arithmetic operations.
Index: gcc/doc/cppopts.texi
===
--- gcc/doc/cppopts.texi(revision 196215)
+++ gcc/doc/cppopts.texi(working copy)
@@ -803,7 +803,7 @@ Replacement:  []@{@}
 Enable special code to work around file systems which only permit very
 short file names, such as MS-DOS@.
 
-@itemx --help
+@item --help
 @itemx --target-help
 @opindex help
 @opindex target-help
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 196215)
+++ gcc/doc/invoke.texi (working copy)
@@ -5179,7 +5179,7 @@ thus dbg_cnt() returns true always unles
 e.g. With -fdbg-cnt=dce:10,tail_call:0
 dbg_cnt(dce) will return true only for first 10 invocations
 
-@itemx -fenable-@var{kind}-@var{pass}
+@item -fenable-@var{kind}-@var{pass}
 @itemx -fdisable-@var{kind}-@var{pass}=@var{range-list}
 @opindex fdisable-
 @opindex fenable-
@@ -5327,11 +5327,11 @@ Dump after duplicating the computed goto
 @option{-fdump-rtl-ce3} enable dumping after the three
 if conversion passes.
 
-@itemx -fdump-rtl-cprop_hardreg
+@item -fdump-rtl-cprop_hardreg
 @opindex fdump-rtl-cprop_hardreg
 Dump after hard register copy propagation.
 
-@itemx -fdump-rtl-csa
+@item -fdump-rtl-csa
 @opindex fdump-rtl-csa
 Dump after combining stack adjustments.
 
@@ -5342,11 +5342,11 @@ Dump after combining stack adjustments.
 @option{-fdump-rtl-cse1} and @option{-fdump-rtl-cse2} enable dumping after
 the two common sub-expression elimination passes.
 
-@itemx -fdump-rtl-dce
+@item -fdump-rtl-dce
 @opindex fdump-rtl-dce
 Dump after the standalone dead code elimination passes.
 
-@itemx -fdump-rtl-dbr
+@item -fdump-rtl-dbr
 @opindex fdump-rtl-dbr
 Dump after delayed branch scheduling.
 
@@ -5391,7 +5391,7 @@ Dump after the initialization of the reg
 @opindex fdump-rtl-initvals
 Dump after the computation of the initial value sets.
 
-@itemx -fdump-rtl-into_cfglayout
+@item -fdump-rtl-into_cfglayout
 @opindex fdump-rtl-into_cfglayout
 Dump after converting to cfglayout mode.
 
@@ -5421,7 +5421,7 @@ Dump after removing redundant mode switc
 @opindex fdump-rtl-rnreg
 Dump after register renumbering.
 
-@itemx -fdump-rtl-outof_cfglayout
+@item -fdump-rtl-outof_cfglayout
 @opindex fdump-rtl-outof_cfglayout
 Dump after converting from cfglayout mode.