Re: [PATCH 1/3] testsuite: Unbork multilib testing on RISC-V (and any target really)

2023-05-31 Thread Iain Sandoe via Gcc-patches



> On 31 May 2023, at 18:57, Jeff Law via Gcc-patches  
> wrote:
> 
> 
> 
> On 5/31/23 10:25, Vineet Gupta wrote:
>> Multilib testing on trunk is currently busted (and surprisingly this
>> affects any/all targets but it seems nobody cares). We currently get the
>> following splat:
> I wouldn't say that nobody cares, it just hasn't bubbled up on anyone's 
> priority list yet (most developers aren't working on targets that make heavy 
> use of multilibs).
> 
> But probably more importantly, this problem seems to not be triggering on all 
> multilib targets.  For example, I just examined my tester's build logs and 
> couldn't see this on the H8/300 or V850 ports.  Which begs the question, why?

I do have a multilib problem [with libgomp] on Darwin (which has been noticed : 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109951) but it is not obvious how 
the fix proposed would solve this - unless it’s some subtle change in global 
content for the multilib options.

(testing anyway)

thanks
Iain



[pushed] Darwin, PPC: Fix struct layout with pragma pack [PR110044].

2023-06-02 Thread Iain Sandoe via Gcc-patches
@David: I am not sure what sets the ABI on AIX (for Darwin, it is effectively
"whatever the system compiler [Apple gcc-4] does") but from an inspection of
the code, it seems that (if the platform should honour #pragma pack) a similar
effect could be present there too.

Tested on powerpc-apple-darwin9, powerpc64-linux-gnu and on i686 and x86_64
Darwin.  Checked that the testcases also pass for Apple gcc-4.2.1.
pushed to trunk, thanks
Iain

--- 8< ---

This bug was essentially that darwin_rs6000_special_round_type_align()
was ignoring externally-imposed capping of field alignment.

Signed-off-by: Iain Sandoe 

PR target/110044

gcc/ChangeLog:

* config/rs6000/rs6000.cc (darwin_rs6000_special_round_type_align):
Make sure that we do not have a cap on field alignment before altering
the struct layout based on the type alignment of the first entry.

gcc/testsuite/ChangeLog:

* gcc.target/powerpc/darwin-abi-13-0.c: New test.
* gcc.target/powerpc/darwin-abi-13-1.c: New test.
* gcc.target/powerpc/darwin-abi-13-2.c: New test.
* gcc.target/powerpc/darwin-structs-0.h: New test.
---
 gcc/config/rs6000/rs6000.cc   |  3 +-
 .../gcc.target/powerpc/darwin-abi-13-0.c  | 23 +++
 .../gcc.target/powerpc/darwin-abi-13-1.c  | 27 +
 .../gcc.target/powerpc/darwin-abi-13-2.c  | 27 +
 .../gcc.target/powerpc/darwin-structs-0.h | 29 +++
 5 files changed, 108 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.target/powerpc/darwin-abi-13-0.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/darwin-abi-13-1.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/darwin-abi-13-2.c
 create mode 100644 gcc/testsuite/gcc.target/powerpc/darwin-structs-0.h

diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc
index 5b3b8b52e7e..42f49e4a56b 100644
--- a/gcc/config/rs6000/rs6000.cc
+++ b/gcc/config/rs6000/rs6000.cc
@@ -8209,7 +8209,8 @@ darwin_rs6000_special_round_type_align (tree type, 
unsigned int computed,
   type = TREE_TYPE (type);
   } while (AGGREGATE_TYPE_P (type));
 
-  if (! AGGREGATE_TYPE_P (type) && type != error_mark_node)
+  if (type != error_mark_node && ! AGGREGATE_TYPE_P (type)
+  && ! TYPE_PACKED (type) && maximum_field_alignment == 0)
 align = MAX (align, TYPE_ALIGN (type));
 
   return align;
diff --git a/gcc/testsuite/gcc.target/powerpc/darwin-abi-13-0.c 
b/gcc/testsuite/gcc.target/powerpc/darwin-abi-13-0.c
new file mode 100644
index 000..d8d3c63a083
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/darwin-abi-13-0.c
@@ -0,0 +1,23 @@
+/* { dg-do compile { target powerpc*-*-darwin* } } */
+/* { dg-require-effective-target ilp32 } */
+/* { dg-options "-Wno-long-long" } */
+
+#include "darwin-structs-0.h"
+
+int tcd[sizeof(cd) != 12 ? -1 : 1];
+int acd[__alignof__(cd) != 4 ? -1 : 1];
+
+int sdc[sizeof(dc) != 16 ? -1 : 1];
+int adc[__alignof__(dc) != 8 ? -1 : 1];
+
+int scL[sizeof(cL) != 12 ? -1 : 1];
+int acL[__alignof__(cL) != 4 ? -1 : 1];
+
+int sLc[sizeof(Lc) != 16 ? -1 : 1];
+int aLc[__alignof__(Lc) != 8 ? -1 : 1];
+
+int scD[sizeof(cD) != 32 ? -1 : 1];
+int acD[__alignof__(cD) != 16 ? -1 : 1];
+
+int sDc[sizeof(Dc) != 32 ? -1 : 1];
+int aDc[__alignof__(Dc) != 16 ? -1 : 1];
diff --git a/gcc/testsuite/gcc.target/powerpc/darwin-abi-13-1.c 
b/gcc/testsuite/gcc.target/powerpc/darwin-abi-13-1.c
new file mode 100644
index 000..4d888d383fa
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/darwin-abi-13-1.c
@@ -0,0 +1,27 @@
+/* { dg-do compile { target powerpc*-*-darwin* } } */
+/* { dg-require-effective-target ilp32 } */
+/* { dg-options "-Wno-long-long" } */
+
+#pragma pack(push, 1)
+
+#include "darwin-structs-0.h"
+
+int tcd[sizeof(cd) != 9 ? -1 : 1];
+int acd[__alignof__(cd) != 1 ? -1 : 1];
+
+int sdc[sizeof(dc) != 9 ? -1 : 1];
+int adc[__alignof__(dc) != 1 ? -1 : 1];
+
+int scL[sizeof(cL) != 9 ? -1 : 1];
+int acL[__alignof__(cL) != 1 ? -1 : 1];
+
+int sLc[sizeof(Lc) != 9 ? -1 : 1];
+int aLc[__alignof__(Lc) != 1 ? -1 : 1];
+
+int scD[sizeof(cD) != 17 ? -1 : 1];
+int acD[__alignof__(cD) != 1 ? -1 : 1];
+
+int sDc[sizeof(Dc) != 17 ? -1 : 1];
+int aDc[__alignof__(Dc) != 1 ? -1 : 1];
+
+#pragma pack(pop)
diff --git a/gcc/testsuite/gcc.target/powerpc/darwin-abi-13-2.c 
b/gcc/testsuite/gcc.target/powerpc/darwin-abi-13-2.c
new file mode 100644
index 000..3bd52c0a8f8
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/darwin-abi-13-2.c
@@ -0,0 +1,27 @@
+/* { dg-do compile { target powerpc*-*-darwin* } } */
+/* { dg-require-effective-target ilp32 } */
+/* { dg-options "-Wno-long-long" } */
+
+#pragma pack(push, 2)
+
+#include "darwin-structs-0.h"
+
+int tcd[sizeof(cd) != 10 ? -1 : 1];
+int acd[__alignof__(cd) != 2 ? -1 : 1];
+
+int sdc[sizeof(dc) != 10 ? -1 : 1];
+int adc[__alignof__(dc) != 2 ? -1 : 1];
+
+int scL[sizeof(cL) != 10 ? -1 : 1];
+int acL[__alignof__(cL) != 2 ? -1 : 1];
+
+int sLc[sizeof(Lc) 

[pushed] Darwin: Use -platform_version when available [PR110624].

2023-07-13 Thread Iain Sandoe via Gcc-patches
tested on i688, x86_64 Darwin versions with/without support for the
platform_version flag.  Checked by Rainer on macOS14. Pushed to trunk
thanks,
Iain

--- 8< ---

Later versions of the static linker support a more flexible flag to
describe the OS, OS version and SDK used to build the code.  This
replaces the functionality of '-mmacosx_version_min' (which is now
deprecated, leading to the diagnostic described in the PR).

We now use the platform_version flag when available which avoids the
diagnostic.

Signed-off-by: Iain Sandoe 

PR target/110624

gcc/ChangeLog:

* config/darwin.h (DARWIN_PLATFORM_ID): New.
(LINK_COMMAND_A): Use DARWIN_PLATFORM_ID to pass OS, OS version
and SDK data to the static linker.
---
 gcc/config/darwin.h | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/gcc/config/darwin.h b/gcc/config/darwin.h
index 714d3d5cc0d..1b538c73593 100644
--- a/gcc/config/darwin.h
+++ b/gcc/config/darwin.h
@@ -276,6 +276,14 @@ extern GTY(()) int darwin_ms_struct;
 #define DARWIN_RDYNAMIC "%{rdynamic:%nrdynamic is not supported}"
 #endif
 
+#if LD64_HAS_PLATFORM_VERSION
+#define DARWIN_PLATFORM_ID \
+  "%{mmacosx-version-min=*: -platform_version macos %* 0.0} "
+#else
+#define DARWIN_PLATFORM_ID \
+  "%{mmacosx-version-min=*:-macosx_version_min %*} "
+#endif
+
 /* Code built with mdynamic-no-pic does not support PIE/PIC, so  we disallow
these combinations; we also ensure that the no_pie option is passed to
ld64 on system versions that default to PIE when mdynamic-no-pic is given.
@@ -351,7 +359,9 @@ extern GTY(()) int darwin_ms_struct;
 LINK_PLUGIN_SPEC \
 "%{flto*:%

[pushed] Darwin: Handle linker '-demangle' option.

2023-07-21 Thread Iain Sandoe via Gcc-patches
Tested with Darwin linker versions that do/do not support the option
and on x86_64-linux-gnu, pushed to trunk, thanks
Iain

--- 8< ---

Most of the Darwin linkers in use support this option which we will
now pass by default (matching the Xcode clang impl.)>

Signed-off-by: Iain Sandoe 

gcc/ChangeLog:

* config.in: Regenerate.
* config/darwin.h (DARWIN_LD_DEMANGLE): New.
(LINK_COMMAND_SPEC_A): Add demangle handling.
* configure: Regenerate.
* configure.ac: Detect linker support for '-demangle'.
---
 gcc/config.in   |  9 -
 gcc/config/darwin.h |  7 +++
 gcc/configure   | 19 +++
 gcc/configure.ac| 14 ++
 4 files changed, 48 insertions(+), 1 deletion(-)

diff --git a/gcc/config.in b/gcc/config.in
index 0e62b9fbfc9..5cf51bc1b01 100644
--- a/gcc/config.in
+++ b/gcc/config.in
@@ -2178,6 +2178,12 @@
 #endif
 
 
+/* Define to 1 if ld64 supports '-demangle'. */
+#ifndef USED_FOR_TARGET
+#undef LD64_HAS_DEMANGLE
+#endif
+
+
 /* Define to 1 if ld64 supports '-export_dynamic'. */
 #ifndef USED_FOR_TARGET
 #undef LD64_HAS_EXPORT_DYNAMIC
@@ -2239,7 +2245,8 @@
 #endif
 
 
-/* Define to the sub-directory where libtool stores uninstalled libraries. */
+/* Define to the sub-directory in which libtool stores uninstalled libraries.
+   */
 #ifndef USED_FOR_TARGET
 #undef LT_OBJDIR
 #endif
diff --git a/gcc/config/darwin.h b/gcc/config/darwin.h
index 1b538c73593..e0e8672a455 100644
--- a/gcc/config/darwin.h
+++ b/gcc/config/darwin.h
@@ -270,6 +270,12 @@ extern GTY(()) int darwin_ms_struct;
   "%&6; }
 gcc_cv_ld64_major=`echo "$gcc_cv_ld64_version" | sed -e 's/\..*//'`
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $gcc_cv_ld64_major" >&5
 $as_echo "$gcc_cv_ld64_major" >&6; }
+if test "$gcc_cv_ld64_major" -ge 97; then
+  gcc_cv_ld64_demangle=1
+fi
 if test "$gcc_cv_ld64_major" -ge 236; then
   gcc_cv_ld64_export_dynamic=1
 fi
@@ -30517,6 +30521,15 @@ $as_echo_n "checking linker version... " >&6; }
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $gcc_cv_ld64_version" >&5
 $as_echo "$gcc_cv_ld64_version" >&6; }
 
+{ $as_echo "$as_me:${as_lineno-$LINENO}: checking linker for -demangle 
support" >&5
+$as_echo_n "checking linker for -demangle support... " >&6; }
+gcc_cv_ld64_demangle=1
+if $gcc_cv_ld -demangle < /dev/null 2>&1 | grep 'unknown option' > 
/dev/null; then
+  gcc_cv_ld64_demangle=0
+fi
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $gcc_cv_ld64_demangle" >&5
+$as_echo "$gcc_cv_ld64_demangle" >&6; }
+
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking linker for 
-export_dynamic support" >&5
 $as_echo_n "checking linker for -export_dynamic support... " >&6; }
 gcc_cv_ld64_export_dynamic=1
@@ -30545,6 +30558,12 @@ _ACEOF
   fi
 
 
+cat >>confdefs.h <<_ACEOF
+#define LD64_HAS_DEMANGLE $gcc_cv_ld64_demangle
+_ACEOF
+
+
+
 cat >>confdefs.h <<_ACEOF
 #define LD64_HAS_EXPORT_DYNAMIC $gcc_cv_ld64_export_dynamic
 _ACEOF
diff --git a/gcc/configure.ac b/gcc/configure.ac
index e91073ba831..46e58a27661 100644
--- a/gcc/configure.ac
+++ b/gcc/configure.ac
@@ -6211,6 +6211,7 @@ if test x"$ld64_flag" = x"yes"; then
   # Set defaults for possibly untestable items.
   gcc_cv_ld64_export_dynamic=0
   gcc_cv_ld64_platform_version=0
+  gcc_cv_ld64_demangle=0
 
   if test "$build" = "$host"; then
 darwin_try_test=1
@@ -6232,6 +6233,9 @@ if test x"$ld64_flag" = x"yes"; then
 AC_MSG_CHECKING(ld64 specified version)
 gcc_cv_ld64_major=`echo "$gcc_cv_ld64_version" | sed -e 's/\..*//'`
 AC_MSG_RESULT($gcc_cv_ld64_major)
+if test "$gcc_cv_ld64_major" -ge 97; then
+  gcc_cv_ld64_demangle=1
+fi
 if test "$gcc_cv_ld64_major" -ge 236; then
   gcc_cv_ld64_export_dynamic=1
 fi
@@ -6246,6 +6250,13 @@ if test x"$ld64_flag" = x"yes"; then
 fi
 AC_MSG_RESULT($gcc_cv_ld64_version)
 
+AC_MSG_CHECKING(linker for -demangle support)
+gcc_cv_ld64_demangle=1
+if $gcc_cv_ld -demangle < /dev/null 2>&1 | grep 'unknown option' > 
/dev/null; then
+  gcc_cv_ld64_demangle=0
+fi
+AC_MSG_RESULT($gcc_cv_ld64_demangle)
+
 AC_MSG_CHECKING(linker for -export_dynamic support)
 gcc_cv_ld64_export_dynamic=1
 if $gcc_cv_ld -export_dynamic < /dev/null 2>&1 | grep 'unknown option' > 
/dev/null; then
@@ -6266,6 +6277,9 @@ if test x"$ld64_flag" = x"yes"; then
   [Define to ld64 version.])
   fi
 
+  AC_DEFINE_UNQUOTED(LD64_HAS_DEMANGLE, $gcc_cv_ld64_demangle,
+  [Define to 1 if ld64 supports '-demangle'.])
+
   AC_DEFINE_UNQUOTED(LD64_HAS_EXPORT_DYNAMIC, $gcc_cv_ld64_export_dynamic,
   [Define to 1 if ld64 supports '-export_dynamic'.])
 
-- 
2.39.2 (Apple Git-143)



Re: [PING][PATCH][gdb/build] Fix build breaker with --enabled-shared

2022-07-12 Thread Iain Sandoe via Gcc-patches
Hi Tom

> On 12 Jul 2022, at 14:42, Tom de Vries via Gcc-patches 
>  wrote:
> 
> [ dropped gdb-patches, since already applied there. ]
> 
> On 6/27/22 15:38, Tom de Vries wrote:
>> On 6/27/22 15:03, Tom de Vries wrote:
>>> Hi,
>>> 
>>> When building gdb with --enabled-shared, I run into:
>>> ...
>>> ld: build/zlib/libz.a(libz_a-inffast.o): relocation R_X86_64_32S against \
>>>`.rodata' can not be used when making a shared object; recompile with 
>>> -fPIC
>>> ld: build/zlib/libz.a(libz_a-inflate.o): warning: relocation against \
>>>`inflateResetKeep' in read-only section `.text'
>>> collect2: error: ld returned 1 exit status
>>> make[3]: *** [libbfd.la] Error 1
>>> ...
>>> 
>>> This is a regression since commit a08bdb159bb ("[gdb/build] Fix gdbserver
>>> build with -fsanitize=thread").
>>> 
>>> The problem is that a single case statement in configure is shared to handle
>>> special requirements for both the host libiberty and host zlib, which has 
>>> the
>>> effect that only one is handled.
>>> 
>>> Fix this by handling libiberty and zlib each in its own case statement.
>>> 
>>> Build on x86_64-linux, with and without --enable-shared.
>>> 
>>> OK for gcc trunk?
>>> 
> 
> Ping.

see also 
https://gcc.gnu.org/pipermail/gcc-patches/2022-June/597263.html
which is approved but i didn’t yet push it .. 

do you not see any issues with GMP et. al. (or are they not used)?
Iain

> 
> Thanks,
> - Tom
> 
>> To fix the buildbot breakage, I already pushed to the gdb repo.
>> Thanks,
>> - Tom
>>> 
>>> [gdb/build] Fix build breaker with --enabled-shared
>>> 
>>> ChangeLog:
>>> 
>>> 2022-06-27  Tom de Vries  
>>> 
>>> * configure.ac: Set extra_host_libiberty_configure_flags and
>>> extra_host_zlib_configure_flags in separate case statements.
>>> * configure: Regenerate.
>>> 
>>> ---
>>>   configure| 8 ++--
>>>   configure.ac | 8 ++--
>>>   2 files changed, 12 insertions(+), 4 deletions(-)
>>> 
>>> diff --git a/configure b/configure
>>> index aac80b88d70..be433ef6d5d 100755
>>> --- a/configure
>>> +++ b/configure
>>> @@ -6962,13 +6962,18 @@ fi
>>>   # Sometimes we have special requirements for the host libiberty.
>>>   extra_host_libiberty_configure_flags=
>>> -extra_host_zlib_configure_flags=
>>>   case " $configdirs " in
>>> *" lto-plugin "* | *" libcc1 "* | *" gdbserver "*)
>>>   # When these are to be built as shared libraries, the same applies to
>>>   # libiberty.
>>>   extra_host_libiberty_configure_flags=--enable-shared
>>>   ;;
>>> +esac
>>> +
>>> +
>>> +# Sometimes we have special requirements for the host zlib.
>>> +extra_host_zlib_configure_flags=
>>> +case " $configdirs " in
>>> *" bfd "*)
>>>   # When bfd is to be built as a shared library, the same applies to
>>>   # zlib.
>>> @@ -6979,7 +6984,6 @@ case " $configdirs " in
>>>   esac
>>> -
>>>   # Produce a warning message for the subdirs we can't configure.
>>>   # This isn't especially interesting in the Cygnus tree, but in the 
>>> individual
>>>   # FSF releases, it's important to let people know when their machine isn't
>>> diff --git a/configure.ac b/configure.ac
>>> index 29f74d10b5a..1651cbf3b02 100644
>>> --- a/configure.ac
>>> +++ b/configure.ac
>>> @@ -2342,13 +2342,18 @@ fi
>>>   # Sometimes we have special requirements for the host libiberty.
>>>   extra_host_libiberty_configure_flags=
>>> -extra_host_zlib_configure_flags=
>>>   case " $configdirs " in
>>> *" lto-plugin "* | *" libcc1 "* | *" gdbserver "*)
>>>   # When these are to be built as shared libraries, the same applies to
>>>   # libiberty.
>>>   extra_host_libiberty_configure_flags=--enable-shared
>>>   ;;
>>> +esac
>>> +AC_SUBST(extra_host_libiberty_configure_flags)
>>> +
>>> +# Sometimes we have special requirements for the host zlib.
>>> +extra_host_zlib_configure_flags=
>>> +case " $configdirs " in
>>> *" bfd "*)
>>>   # When bfd is to be built as a shared library, the same applies to
>>>   # zlib.
>>> @@ -2357,7 +2362,6 @@ case " $configdirs " in
>>>   fi
>>>   ;;
>>>   esac
>>> -AC_SUBST(extra_host_libiberty_configure_flags)
>>>   AC_SUBST(extra_host_zlib_configure_flags)
>>>   # Produce a warning message for the subdirs we can't configure.



Re: [PATCH 1/2] Allow subtarget customization of CC1_SPEC

2022-07-24 Thread Iain Sandoe via Gcc-patches
Hi Sebastian,

> On 25 Jul 2022, at 06:59, Sebastian Huber 
>  wrote:

> On 22/07/2022 16:02, Jose E. Marchesi wrote:
>> I find "subtarget" confusing in this context.
>> If it is about rtems.h, linux.h or sol2.h, wouldn't this be better
>> called OS_CC1_SPEC or similar?  These files specify configurations that
>> apply to a set of targets, not to a subset of a target...
> 
> Iain Sandoe told me that for the GCC implementation the OSs are sub-targets 
> of the architecture:
> 
> https://gcc.gnu.org/pipermail/gcc/2022-July/239158.html

There is, however, a precedent for the SUBTARGET_ use, however, I agree with 
Jose that it is somewhat confusing - since (as mentioned before) to the OS the 
arches are the sub-targets, so maybe OS_xxx would be more clear.

Perhaps Joseph (CC-d) would weigh in here.

Iain



Re: [PATCH] tree-optimization/105679 - disable backward threading of unlikely entry

2022-07-31 Thread Iain Sandoe via Gcc-patches
Hi Richi,

> On 29 Jul 2022, at 09:54, Richard Biener via Gcc-patches 
>  wrote:
> 
> The following makes the backward threader reject threads whose entry
> edge is probably never executed according to the profile.  That in
> particular, for the testcase, avoids threading the irq == 1 check
> on the path where irq > 31, thereby avoiding spurious -Warray-bounds
> diagnostics

This breaks bootstrap on i686-darwin{9,17} with what looks like a valid  
warning (werrors on stage2)

cc1plus  … -O2 -Wall … is enough to.

I can repeat it on a cross from x86_64-darwin19, so I can probably reduce the 
.ii (it’s like 2M5 raw) and file a PR if you like - depends if the solution 
might be obvious to you …

thanks
Iain



In file included from /src-local/gcc-master/gcc/hash-table.h:248,
 from /src-local/gcc-master/gcc/coretypes.h:486,
 from /src-local/gcc-master/gcc/tree-ssa-threadbackward.cc:22:
In member function ‘T& vec::operator[](unsigned int) [with T = 
basic_block_def*; A = va_heap]’,
inlined from ‘const T& vec::operator[](unsigned int) const [with T = 
basic_block_def*]’ at /src-local/gcc-master/gcc/vec.h:1486:20,
inlined from ‘bool back_threader_profitability::profitable_path_p(const 
vec&, tree, edge, bool*)’ at 
/src-local/gcc-master/gcc/tree-ssa-threadbackward.cc:781:37:
/src-local/gcc-master/gcc/vec.h:890:19: warning: array subscript 4294967294 is 
above array bounds of ‘basic_block_def* [1]’ [-Warray-bounds]
  890 |   return m_vecdata[ix];
  |  ~^
/src-local/gcc-master/gcc/vec.h: In member function ‘bool 
back_threader_profitability::profitable_path_p(const vec&, 
tree, edge, bool*)’:
/src-local/gcc-master/gcc/vec.h:635:5: note: while referencing 
‘vec::m_vecdata’
  635 |   T m_vecdata[1];
  | ^

=

Re: [PATCH] tree-optimization/105679 - disable backward threading of unlikely entry

2022-08-01 Thread Iain Sandoe via Gcc-patches



> On 1 Aug 2022, at 09:21, Richard Biener via Gcc-patches 
>  wrote:
> 
> On Sun, 31 Jul 2022, Iain Sandoe wrote:
> 
>> Hi Richi,
>> 
>>> On 29 Jul 2022, at 09:54, Richard Biener via Gcc-patches 
>>>  wrote:
>>> 
>>> The following makes the backward threader reject threads whose entry
>>> edge is probably never executed according to the profile.  That in
>>> particular, for the testcase, avoids threading the irq == 1 check
>>> on the path where irq > 31, thereby avoiding spurious -Warray-bounds
>>> diagnostics
>> 
>> This breaks bootstrap on i686-darwin{9,17} with what looks like a valid  
>> warning (werrors on stage2)
>> 
>> cc1plus  … -O2 -Wall … is enough to.
>> 
>> I can repeat it on a cross from x86_64-darwin19, so I can probably reduce 
>> the .ii (it’s like 2M5 raw) and file a PR if you like - depends if the 
>> solution might be obvious to you …
> 
> Can you open a bugreport and attach full preprocessed source at start?

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

> Note at the start of the function we have
> 
>  if (m_path.length () <= 1)
>  return false;
> 
> so
> 
>  edge entry = find_edge (m_path[m_path.length () - 1],
>  m_path[m_path.length () - 2]);
> 
> is known to not access m_path out-of-bounds ...

yes, I saw that .. so I guess somehow that information is getting dropped.
thanks
Iain

> 
> Thanks,
> Richard.
> 
>> 
>> thanks
>> Iain
>> 
>> 
>> 
>> In file included from /src-local/gcc-master/gcc/hash-table.h:248,
>> from /src-local/gcc-master/gcc/coretypes.h:486,
>> from /src-local/gcc-master/gcc/tree-ssa-threadbackward.cc:22:
>> In member function ‘T& vec::operator[](unsigned int) [with T 
>> = basic_block_def*; A = va_heap]’,
>>inlined from ‘const T& vec::operator[](unsigned int) const [with T = 
>> basic_block_def*]’ at /src-local/gcc-master/gcc/vec.h:1486:20,
>>inlined from ‘bool back_threader_profitability::profitable_path_p(const 
>> vec&, tree, edge, bool*)’ at 
>> /src-local/gcc-master/gcc/tree-ssa-threadbackward.cc:781:37:
>> /src-local/gcc-master/gcc/vec.h:890:19: warning: array subscript 4294967294 
>> is above array bounds of ‘basic_block_def* [1]’ [-Warray-bounds]
>>  890 |   return m_vecdata[ix];
>>  |  ~^
>> /src-local/gcc-master/gcc/vec.h: In member function ‘bool 
>> back_threader_profitability::profitable_path_p(const vec&, 
>> tree, edge, bool*)’:
>> /src-local/gcc-master/gcc/vec.h:635:5: note: while referencing 
>> ‘vec::m_vecdata’
>>  635 |   T m_vecdata[1];
>>  | ^
>> 
>> =
> 
> -- 
> Richard Biener 
> SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg,
> Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman;
> HRB 36809 (AG Nuernberg)



[pushed] modula-2, plugin: Fix Darwin bootstrap issues.

2023-08-13 Thread Iain Sandoe via Gcc-patches
Tested on x86_64 Darwin and x86_64 Linux, pushed to master, will
also backport to 13 if it is needed there, thanks
Iain

--- 8< ---

This corrects some typos in the suffix of the m2rte pluing that
lead to a bootstrap fail on Darwin, where the suffix is not '.so'.

On some versions of Darwin, the linker complains if libSystem is not
linked, so we disable all the default libs, but add libc back.

Signed-off-by: Iain Sandoe 

gcc/m2/ChangeLog:

* Make-lang.in: Update suffix spellings to use 'soext'.
Add libc to the plugin link.
---
 gcc/m2/Make-lang.in | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/gcc/m2/Make-lang.in b/gcc/m2/Make-lang.in
index 8c6bac229e7..ca1581fe643 100644
--- a/gcc/m2/Make-lang.in
+++ b/gcc/m2/Make-lang.in
@@ -39,6 +39,7 @@ else
   PLUGINLDFLAGS = -Wl,-undefined,dynamic_lookup
   PLUGINLDFLAGS += -Wl,-install_name,m2rte$(soext)
   PLUGINLDFLAGS += -nodefaultlibs
+  PLUGINLDFLAGS += -lc
 endif
 
 TEXISRC = $(srcdir)/doc/gm2.texi \
@@ -91,7 +92,7 @@ PGE=m2/pge$(exeext)
 SRC_PREFIX=G
 
 ifeq ($(enable_plugin),yes)
-M2RTE_PLUGIN_SO=plugin/m2rte$(exeext).so
+M2RTE_PLUGIN_SO=plugin/m2rte$(soext)
 endif
 
 m2/gm2spec.o: $(srcdir)/m2/gm2spec.cc $(SYSTEM_H) $(GCC_H) $(CONFIG_H) \
@@ -420,7 +421,7 @@ plugin/m2rte$(soext): $(srcdir)/m2/plugin/m2rte.cc 
$(GCC_HEADER_DEPENDENCIES_FOR
 else
 m2.install-plugin:
 
-plugin/m2rte$(exeext).so:
+plugin/m2rte$(soext):
 
 endif
 
-- 
2.39.2 (Apple Git-143)



Re: Darwin: Replace environment runpath with embedded [PR88590]

2023-08-18 Thread Iain Sandoe via Gcc-patches
Hi Joseph,

> On 18 Aug 2023, at 21:17, Joseph Myers  wrote:
> 
> On Tue, 15 Aug 2023, FX Coudert via Gcc-patches wrote:
> 
>> I am currently retesting the patches on various archs (Linux and Darwin) 
>> after a final rebase, but various previous versions were 
>> regression-tested, and have been shipped for a long time in Homebrew.
>> 
>> OK to commit?
> 
> The driver changes are OK.
> 
> I think the new configure options and the new -nodefaultrpaths compiler 
> option need documenting (I suppose there might be a case for the configure 
> option defined in libtool code being documented somewhere in libtool, if 
> there's somewhere appropriate, but I don't see that in the libtool patch 
> submission).
> 
> The help text for --enable-darwin-at-rpath refers to it as 
> --enable-darwin-at-path.

OK, we need to fix those things.

> Somewhere the documentation ought to discuss the considerations around 
> embedding such paths in binaries, and what's appropriate for building a 
> binary on the system where it's going to be used, versus using the 
> compiler to build redistributed binaries that will be run on a system that 
> doesn't have the compiler installed (and so shouldn't have hardcoded paths 
> that were only applicable on the system with the compiler, but will need 
> to be able to find shared libraries - probably shipped with the binary - 
> somehow).

Actually, the changes are not so dramatic as they seem (for Darwin) since we
already have less flexibility than other unix-like systems.

The status quo is that installed libraries embed their runpath e.g:
/path/to/compiler/install/lib/libgfortran.dylib

When executables are built, they embed the full library names for dependent
libraries (this "two-level" namespacing has some useful and not-so-useful
sides to it).

However, Darwin compiler installations are not relocatable without re-writing 
the
library names and,  because of the vendor’s decision to neuter
DYLD_LIBRARY_PATH, (the Darwin equivalent of LD_LIBRARY_PATH) it makes
it quite involved to do such a move.

===

After the change:
libraries are identified as  @rpath/libgfortran.dylib (for example)

and any executable built by the compiler has a runpath 
/path/to/compiler/install/lib.

Actually, after this change the compiler is initially relocatable (that is you 
can choose to
install it anywhere) but once installed, if you move it, that would break 
executables already
built because they embed the path to the installation.

So, in practice, for the “out of the tin” self-use of GCC, there is no 
practical difference between
the existing fixed installation and a “placed once” installation.

[however, the change means that we can correctly configure the compiler, since 
the runpaths
 at build time can be made to point to the uninstalled libraries, which is the 
underlying problem
 we are solving].

— on the topic of building applications for distribution:

The expectation for Darwin platforms is that dependent libraries are shipped 
along with
applications (it is not desirable to require that end users have to have 
elevated privs to
install them in some Well Known Place, and [other than OSS distributions like 
macports
and homebrew] there is no common place to expect to find OSS libraries).

There is quite extensive Apple Developer documentation on delivering packages 
with
co-installed libraries using @rpath (that is the intended mechanism for 
delivery since it
allows drag-and-drop installation and moving of built applications).

The revised compiler has libraries already built in a suitable manner for that 
distribution
model.

I would not propose that we repeated such information - but we could refer to 
it?

Generally, I’d prefer we suggested searching for such documentation, rather 
than linking
to it, since links can expire - does that seem reasonable?

thanks for the reviews
Iain

> -- 
> Joseph S. Myers
> jos...@codesourcery.com



Re: Darwin: Replace environment runpath with embedded [PR88590]

2023-08-18 Thread Iain Sandoe via Gcc-patches



> On 18 Aug 2023, at 23:59, Joseph Myers  wrote:
> 
> On Fri, 18 Aug 2023, Iain Sandoe via Gcc-patches wrote:
> 
>> There is quite extensive Apple Developer documentation on delivering 
>> packages with co-installed libraries using @rpath (that is the intended 
>> mechanism for delivery since it allows drag-and-drop installation and 
>> moving of built applications).
>> 
>> The revised compiler has libraries already built in a suitable manner 
>> for that distribution model.
>> 
>> I would not propose that we repeated such information - but we could 
>> refer to it?
>> 
>> Generally, I’d prefer we suggested searching for such documentation, 
>> rather than linking to it, since links can expire - does that seem 
>> reasonable?
> 
> I suppose the key thing is to note that, if building a program for 
> distribution, you shouldn't build it to embed 
> /path/to/compiler/install/lib, but instead should do  possibly referring to relevant Apple documentation>.

right, exactly - there are special runpath roots like @executable_path and
@loader_path that provide for packages that are fully relocatable (we
actually use some of this to allow GCC runtimes to find their dependent
runtimes without needing an absolute runpath).

OK. We just need to find a suitable place to put this - perhaps in documenting
-nodefaultrpaths (since that’s usually used together with specifying something
different).

thanks,
Iain


> 
> -- 
> Joseph S. Myers
> jos...@codesourcery.com



Re: [PATCH] Testsuite: fix analyzer tests on Darwin

2023-08-19 Thread Iain Sandoe via Gcc-patches
Hi FX,

thanks for chasing these fails down,

> On 19 Aug 2023, at 22:28, FX Coudert  wrote:
> 

> gcc.dg/analyzer/ currently has 80 failures on Darwin (both 
> x86_64-apple-darwin and aarch64-apple-darwin). All those come from two issues:
> 
> 1. Many tests use memset() without including the  header. We can 
> fix that easily.
> 
> 2. Other tests fail because of the use of macOS headers, which redefine 
> functions like memcpy and others to “checked”/fortified versions 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104042 Instead of correcting 
> this on a case-by-case basis, add the -D_FORTIFY_SOURCE=0 flag systematically 
> on Darwin.
> 
> With that, all 80 failures are silenced and that part of the testsuite is now 
> clean:
> 
> # of expected passes 5238
> # of expected failures 194
> # of unsupported tests 12

> OK to commit?

LGTM,

Iain

> FX
> 
> <0001-Testsuite-fix-analyzer-tests-on-Darwin.patch>



[pushed] testsuite,objective-c++: Fix imported NSObjCRuntime.h.

2023-06-23 Thread Iain Sandoe via Gcc-patches
Tested on x86_64-darwin, pushed to trunk, thanks
Iain

--- 8< ---

We have imported some headers from the GNUStep project to allow us
to maintain the testsuite independent to changing versions of system
headers.

One of these headers has a macro that (now we have support for
__has_feature) expands to a declaration that triggers a warning.

These headers are considered part of the implementation so that, in
this case, we can suppress the warning with the system_header pragma.

Signed-off-by: Iain Sandoe 

gcc/testsuite/ChangeLog:

* objc-obj-c++-shared/GNUStep/Foundation/NSObjCRuntime.h: Make
this header use pragma system_header.
---
 .../objc-obj-c++-shared/GNUStep/Foundation/NSObjCRuntime.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git 
a/gcc/testsuite/objc-obj-c++-shared/GNUStep/Foundation/NSObjCRuntime.h 
b/gcc/testsuite/objc-obj-c++-shared/GNUStep/Foundation/NSObjCRuntime.h
index 189af80436a..62556f9ac88 100644
--- a/gcc/testsuite/objc-obj-c++-shared/GNUStep/Foundation/NSObjCRuntime.h
+++ b/gcc/testsuite/objc-obj-c++-shared/GNUStep/Foundation/NSObjCRuntime.h
@@ -29,6 +29,9 @@
 #ifndef __NSObjCRuntime_h_GNUSTEP_BASE_INCLUDE
 #define __NSObjCRuntime_h_GNUSTEP_BASE_INCLUDE
 
+/* Allow the elaborated enum use in _GS_NAMED_ENUM. */
+#pragma GCC system_header
+
 #ifdef __cplusplus
 #ifndef __STDC_LIMIT_MACROS
 #define __STDC_LIMIT_MACROS 1
-- 
2.39.2 (Apple Git-143)



[pushed] configure, Darwin: Ensure overrides to host-pie are passed to gcc configure.

2023-06-25 Thread Iain Sandoe via Gcc-patches
Tested on i686, powerpc, x86_64 and aarch64 darwin (for versions requiring
PIE and also some that default to non-PIE).  Also tested on x86_64-linux-gnu
with and without --enable-host-pie.
pushed to master, thanks
Iain
 
 
--- 8< ---

The latest versions of Darwin on the Aarch64 platform mandate PIE executables.
On x86_64 it remains optional, but produces tool warnings after Darwin20, so
we default to PIE executables there too.

All (non-PowerPC) 64b Darwin platforms mandate PIC code and therefore force
host_shared on (we issue a diagnostic if the user tries to configure them
non-shared).

However, this also means we cannot test the host_shared setting independently
of the host_pie setting so that the logic for setting PICFLAG must be amended
for Darwin.

For Darwin versions required to have PIE executables, in the event that the
user tries to configure these as --disable-host-pie, we issue a warning and
override the setting.  These versions must also switch host_pie on even if it
is not given in the configure line.  To cater for this we pass the current
value of host_pie, as determined by top-level configure, to the GCC configure.

Signed-off-by: Iain Sandoe 

ChangeLog:

* Makefile.def: Pass the enable-host-pie value to GCC configure.
* Makefile.in: Regenerate.
* configure: Regenerate.
* configure.ac: Adjust the logic for shared and PIE host flags to
ensure that PIE is passed for hosts that require it.
---
 Makefile.def |  3 ++-
 Makefile.in  | 29 +++--
 configure| 48 
 configure.ac | 44 
 4 files changed, 89 insertions(+), 35 deletions(-)

diff --git a/Makefile.def b/Makefile.def
index 35e994eb77e..9b4a8a2bf7a 100644
--- a/Makefile.def
+++ b/Makefile.def
@@ -47,7 +47,8 @@ host_modules= { module= fixincludes; bootstrap=true;
 host_modules= { module= flex; no_check_cross= true; };
 host_modules= { module= gas; bootstrap=true; };
 host_modules= { module= gcc; bootstrap=true; 
-   extra_make_flags="$(EXTRA_GCC_FLAGS)"; };
+   extra_make_flags="$(EXTRA_GCC_FLAGS)";
+   extra_configure_flags='@gcc_host_pie@'; };
 host_modules= { module= gmp; lib_path=.libs; bootstrap=true;
// Work around in-tree gmp configure bug with missing flex.
extra_configure_flags='--disable-shared LEX="touch lex.yy.c" 
@host_libs_picflag@';
diff --git a/Makefile.in b/Makefile.in
index b559454cc90..45f09f9308f 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -12021,7 +12021,7 @@ configure-gcc:
  $$s/$$module_srcdir/configure \
  --srcdir=$${topdir}/$$module_srcdir \
  $(HOST_CONFIGARGS) --build=${build_alias} --host=${host_alias} \
- --target=${target_alias}  \
+ --target=${target_alias} @gcc_host_pie@ \
  || exit 1
 @endif gcc
 
@@ -12056,7 +12056,8 @@ configure-stage1-gcc:
  $(HOST_CONFIGARGS) --build=${build_alias} --host=${host_alias} \
  --target=${target_alias} \
   \
- $(STAGE1_CONFIGURE_FLAGS)
+ $(STAGE1_CONFIGURE_FLAGS) \
+ @gcc_host_pie@
 @endif gcc-bootstrap
 
 .PHONY: configure-stage2-gcc maybe-configure-stage2-gcc
@@ -12089,7 +12090,8 @@ configure-stage2-gcc:
  $(HOST_CONFIGARGS) --build=${build_alias} --host=${host_alias} \
  --target=${target_alias} \
  --with-build-libsubdir=$(HOST_SUBDIR) \
- $(STAGE2_CONFIGURE_FLAGS)
+ $(STAGE2_CONFIGURE_FLAGS) \
+ @gcc_host_pie@
 @endif gcc-bootstrap
 
 .PHONY: configure-stage3-gcc maybe-configure-stage3-gcc
@@ -12122,7 +12124,8 @@ configure-stage3-gcc:
  $(HOST_CONFIGARGS) --build=${build_alias} --host=${host_alias} \
  --target=${target_alias} \
  --with-build-libsubdir=$(HOST_SUBDIR) \
- $(STAGE3_CONFIGURE_FLAGS)
+ $(STAGE3_CONFIGURE_FLAGS) \
+ @gcc_host_pie@
 @endif gcc-bootstrap
 
 .PHONY: configure-stage4-gcc maybe-configure-stage4-gcc
@@ -12155,7 +12158,8 @@ configure-stage4-gcc:
  $(HOST_CONFIGARGS) --build=${build_alias} --host=${host_alias} \
  --target=${target_alias} \
  --with-build-libsubdir=$(HOST_SUBDIR) \
- $(STAGE4_CONFIGURE_FLAGS)
+ $(STAGE4_CONFIGURE_FLAGS) \
+ @gcc_host_pie@
 @endif gcc-bootstrap
 
 .PHONY: configure-stageprofile-gcc maybe-configure-stageprofile-gcc
@@ -12188,7 +12192,8 @@ configure-stageprofile-gcc:
  $(HOST_CONFIGARGS) --build=${build_alias} --host=${host_alias} \
  --target=${target_alias} \
  --with-build-libsubdir=$(HOST_SUBDIR) \
- $(STAGEprofile_CONFIGURE_FLAGS)
+ $(STAGEprofile_CONFIGURE_FLAGS) \
+ @gcc_host_pie@
 @endif gcc-bootstrap
 
 .PHONY: configure-stagetrain-gcc maybe-configure-stagetrain-gcc
@@ -12221,7 +12226,8 @@ configure-stagetrain-gcc:
  $(HOST_CONFIGARGS) --build=${build_alias} --host=${host_alias} \
  --ta

[PATCH] modula-2: Amend the handling of failed select() calls in RTint [PR108835].

2023-06-25 Thread Iain Sandoe via Gcc-patches
Tested on various affected Darwin versions and on x86_64-linux-gnu
OK for trunk?
OK for 13.2?
thanks
Iain

--- 8< ---

When we make a select() that fails, there is an attempt to (a) diagnose
why and (b) make a fallback.  These actions are causing some tests to
hang on some Darwin versions, this is because the first action that is
tried to assist in diagnosis/fallback handling is to replace the set
timeout with NIL (which causes select to wait forever, modulo other
reasons it might complete).

To fix this, call select with a zero timeout when checking for error
conditions.  Also, as we check the possible failure conditions, if we
find a change that succeeds, then stop looking for errors.

Signed-off-by: Iain Sandoe 

PR testsuite/108835

gcc/m2/ChangeLog:

* gm2-libs/RTint.mod: Do not use NIL timeout setting on select,
test failures sequentially, finishing on the first success.
---
 gcc/m2/gm2-libs/RTint.mod | 70 ++-
 1 file changed, 54 insertions(+), 16 deletions(-)

diff --git a/gcc/m2/gm2-libs/RTint.mod b/gcc/m2/gm2-libs/RTint.mod
index b3b8737a9f5..8b967b553ff 100644
--- a/gcc/m2/gm2-libs/RTint.mod
+++ b/gcc/m2/gm2-libs/RTint.mod
@@ -441,6 +441,10 @@ END ExcludeVector ;
 
 PROCEDURE AddFd (VAR set: SetOfFd; VAR max: INTEGER; fd: INTEGER) ;
 BEGIN
+   IF (fd<0)
+   THEN
+  RETURN
+   END ;
max := Max (fd, max) ;
IF set = NIL
THEN
@@ -667,6 +671,7 @@ PROCEDURE Listen (untilInterrupt: BOOLEAN;
 VAR
found  : BOOLEAN ;
result : INTEGER ;
+   zero,
after,
b4,
timeval: Timeval ;
@@ -722,14 +727,14 @@ BEGIN
   THEN
  SetTime (timeval, 0, 0)
   END ;
-  IF untilInterrupt AND (inSet=NIL) AND (outSet=NIL) AND (NOT found)
+  IF untilInterrupt AND (((inSet=NIL) AND (outSet=NIL)) OR (maxFd=-1)) AND 
(NOT found)
   THEN
  Halt ('deadlock found, no more processes to run and no interrupts 
active',
__FILE__, __FUNCTION__, __LINE__)
   END ;
   (* printf('timeval = 0x%x\n', timeval) ; *)
   (* printf('}\n') ; *)
-  IF (NOT found) AND (maxFd=-1) AND (inSet=NIL) AND (outSet=NIL)
+  IF (NOT found) AND (maxFd=-1)
   THEN
  (* no file descriptors to be selected upon.  *)
  timeval := KillTime (timeval) ;
@@ -738,6 +743,7 @@ BEGIN
   ELSE
  GetTime (timeval, sec, micro) ;
  Assert (micro < Microseconds) ;
+ zero := InitTime (0, 0) ;
  b4 := InitTime (0, 0) ;
  after := InitTime (0, 0) ;
  result := GetTimeOfDay (b4) ;
@@ -754,26 +760,54 @@ BEGIN
 THEN
printf ("select (.., .., .., %u.%06u)\n", sec, micro)
 END ;
-result := select (maxFd+1, inSet, outSet, NIL, timeval) ;
+IF maxFd<0
+THEN
+   result := select (0, NIL, NIL, NIL, timeval)
+ELSE
+   result := select (maxFd+1, inSet, outSet, NIL, timeval)
+END ;
 IF result=-1
 THEN
-   perror ("select") ;
-   result := select (maxFd+1, inSet, outSet, NIL, NIL) ;
-   IF result=-1
+   IF Debugging
THEN
-  perror ("select timeout argument is faulty")
+  perror ("select failed : ") ;
END ;
-   result := select (maxFd+1, inSet, NIL, NIL, timeval) ;
-   IF result=-1
+   result := select (maxFd+1, inSet, outSet, NIL, zero) ;
+   IF result#-1
THEN
-  perror ("select output fd argument is faulty")
-   END ;
-   result := select (maxFd+1, NIL, outSet, NIL, timeval) ;
-   IF result=-1
-   THEN
-  perror ("select input fd argument is faulty")
+   GetTime (timeval, sec, micro) ;
+   IF Debugging
+   THEN
+ printf ("(nfds : %d timeval: %u.%06u) : \n", maxFd, sec, 
micro) ;
+   END ;
+   perror ("select timeout argument was faulty : ")
ELSE
-  perror ("select maxFD+1 argument is faulty")
+  result := select (maxFd+1, inSet, NIL, NIL, timeval) ;
+  IF result#-1
+  THEN
+ perror ("select output fd argument was faulty : ")
+  ELSE
+ result := select (maxFd+1, NIL, outSet, NIL, timeval) ;
+ IF result#-1
+ THEN
+perror ("select input fd argument was faulty : ")
+ ELSE
+IF maxFd=-1
+THEN
+   result := select (0, NIL, NIL, NIL, timeval) ;
+   IF result=-1
+   THEN
+  IF Debugging
+  THE

Re: [PATCH] configure: Implement --enable-host-bind-now

2023-06-27 Thread Iain Sandoe via Gcc-patches



> On 27 Jun 2023, at 16:31, Marek Polacek via Gcc-patches 
>  wrote:
> 
> On Tue, Jun 27, 2023 at 01:39:16PM +0200, Martin Jambor wrote:
>> Hello,
>> 
>> On Tue, May 16 2023, Marek Polacek via Gcc-patches wrote:
>>> As promised in the --enable-host-pie patch, this patch adds another
>>> configure option, --enable-host-bind-now, which adds -z now when linking
>>> the compiler executables in order to extend hardening.  BIND_NOW with RELRO
>>> allows the GOT to be marked RO; this prevents GOT modification attacks.
>>> 
>>> This option does not affect linking of target libraries; you can use
>>> LDFLAGS_FOR_TARGET=-Wl,-z,relro,-z,now to enable RELRO/BIND_NOW.
>>> 
>>> With this patch:
>>> $ readelf -Wd cc1{,plus} | grep FLAGS
>>> 0x001e (FLAGS)  BIND_NOW
>>> 0x6ffb (FLAGS_1)Flags: NOW PIE
>>> 0x001e (FLAGS)  BIND_NOW
>>> 0x6ffb (FLAGS_1)Flags: NOW PIE
>>> 
>>> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
>>> 
>>> c++tools/ChangeLog:
>>> 
>>> * configure.ac (--enable-host-bind-now): New check.
>>> * configure: Regenerate.
>>> 
>>> gcc/ChangeLog:
>>> 
>>> * configure.ac (--enable-host-bind-now): New check.  Add
>>> -Wl,-z,now to LD_PICFLAG if --enable-host-bind-now.
>>> * configure: Regenerate.
>>> * doc/install.texi: Document --enable-host-bind-now.
>>> 
>>> lto-plugin/ChangeLog:
>>> 
>>> * configure.ac (--enable-host-bind-now): New check.  Link with
>>> -z,now.
>>> * configure: Regenerate.
>> 
>> Our reconfiguration checking script complains about a missing hunk in
>> lto-plugin/Makefile.in:
>> 
>> diff --git a/lto-plugin/Makefile.in b/lto-plugin/Makefile.in
>> index cb568e1e09f..f6f5b020ff5 100644
>> --- a/lto-plugin/Makefile.in
>> +++ b/lto-plugin/Makefile.in
>> @@ -298,6 +298,7 @@ datadir = @datadir@
>> datarootdir = @datarootdir@
>> docdir = @docdir@
>> dvidir = @dvidir@
>> +enable_host_bind_now = @enable_host_bind_now@
>> exec_prefix = @exec_prefix@
>> gcc_build_dir = @gcc_build_dir@
>> get_gcc_base_ver = @get_gcc_base_ver@
>> 
>> 
>> I am somewhat puzzled why the line is not missing in any of the other
>> Makefile.in files.  Can you please check whether that is the only thing
>> that is missing (assuming it is actually missing)?
> 
> Arg, once again, I'm sorry.  I don't know how this happened.  It would
> be trivial to fix it but since
> 
> commit 4a48a38fa99f067b8f3a3d1a5dc7a1e602db351f
> Author: Eric Botcazou 
> Date:   Wed Jun 21 18:19:36 2023 +0200
> 
>ada: Fix build of GNAT tools
> 
> the build with Ada included fails with --enable-host-pie.  So that needs
> to be fixed first.
> 
> Eric, I'm not asking you to fix that, but I'm curious, what did the
> commit above fix?  The patch looks correct; I'm just puzzled why I
> hadn't seen any build failures.

I am also curious as to why we do not need some logic to do a similar job
in gcc-interface/Make-lang.in:

ifeq ($(STAGE1),True)
  ADA_INCLUDES=$(COMMON_ADA_INCLUDES)
  adalib=$(dir $(shell $(CC) -print-libgcc-file-name))adalib
  GNATLIB=$(adalib)/$(if $(wildcard $(adalib)/libgnat.a), libgnat.a,libgnat.so) 
$(STAGE1_LIBS)
else

^^^ I would expect us to need to switch to libgnat_pic.a when we are building a 
PIE exe.

Iain

> The --enable-host-pie patch has been a nightmare :(.
> 
> Marek



[pushed] libphobos, testsuite: Disable forkgc2 on Darwin [PR103944]

2023-07-01 Thread Iain Sandoe via Gcc-patches
From: Iain Sandoe 

This has been in use for some time across all the Darwin version supported
by D.  It has also been tested on x86_64-linux-gnu.

Approved on irc by Iain Buclaw, pushed to main (and will be backported).
thanks
Iain

--- 8< ---

It hangs the testsuite (requiring manual intervention to kill the
spawned processes) which breaks CI.  The reason for the hang id not
clear.  This skips the test for now (xfail does not work).

Signed-off-by: Iain Sandoe 

PR d/103944

libphobos/ChangeLog:

* testsuite/libphobos.gc/forkgc2.d: Skip for Darwin.
---
 libphobos/testsuite/libphobos.gc/forkgc2.d | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libphobos/testsuite/libphobos.gc/forkgc2.d 
b/libphobos/testsuite/libphobos.gc/forkgc2.d
index de7796ced72..38d0d0c2f93 100644
--- a/libphobos/testsuite/libphobos.gc/forkgc2.d
+++ b/libphobos/testsuite/libphobos.gc/forkgc2.d
@@ -1,3 +1,4 @@
+// { dg-skip-if "test hangs the testsuite PR103944" { *-*-darwin* } }
 import core.stdc.stdlib : exit;
 import core.sys.posix.sys.wait : waitpid;
 import core.sys.posix.unistd : fork;
-- 
2.39.2 (Apple Git-143)



[PATCH] libphobos: Handle Darwin Arm and AArch64 in fibre context asm.

2023-07-02 Thread Iain Sandoe via Gcc-patches
Tested on AArch64 (Arm64) Darwin on 11.x, 13.x and master,
OK for trunk?
and backports?
thanks
Iain

--- 8< ---

This code currently fails to build because it contains ELF-
specific directives.  This patch excludes those directives when
the platform is Darwin.

We do not expect switching fibres between threads to be safe here
either owing to the possible caching of TLS pointers.

Signed-off-by: Iain Sandoe 

libphobos/ChangeLog:

* libdruntime/config/aarch64/switchcontext.S: Exclude ELF-
specific constructs for Darwin.
* libdruntime/config/arm/switchcontext.S: Likewise.
* libdruntime/core/thread/fiber.d: Disable switching fibres
between threads.
---
 libphobos/libdruntime/config/aarch64/switchcontext.S | 9 -
 libphobos/libdruntime/config/arm/switchcontext.S | 8 
 libphobos/libdruntime/core/thread/fiber.d| 1 +
 3 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/libphobos/libdruntime/config/aarch64/switchcontext.S 
b/libphobos/libdruntime/config/aarch64/switchcontext.S
index 5cfa2f698e8..d3bd646bc56 100644
--- a/libphobos/libdruntime/config/aarch64/switchcontext.S
+++ b/libphobos/libdruntime/config/aarch64/switchcontext.S
@@ -44,7 +44,9 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  If 
not, see
  */
 .text
 .global CSYM(fiber_switchContext)
+#ifndef __APPLE__
 .type CSYM(fiber_switchContext), %function
+#endif
 .align 4
 CSYM(fiber_switchContext):
 .cfi_startproc
@@ -77,8 +79,9 @@ CSYM(fiber_switchContext):
 ldp d15, d14, [sp], #20*8
 ret
 .cfi_endproc
+#ifndef __APPLE__
 .size CSYM(fiber_switchContext),.-CSYM(fiber_switchContext)
-
+#endif
 /**
  * When generating any kind of backtrace (gdb, exception handling) for
  * a function called in a Fiber, we need to tell the unwinder to stop
@@ -93,11 +96,15 @@ CSYM(fiber_switchContext):
 .text
 .global CSYM(fiber_trampoline)
 .p2align  2
+#ifndef __APPLE__
 .type CSYM(fiber_trampoline), %function
+#endif
 CSYM(fiber_trampoline):
 .cfi_startproc
 .cfi_undefined x30
 // fiber_entryPoint never returns
 bl CSYM(fiber_entryPoint)
 .cfi_endproc
+#ifndef __APPLE__
 .size CSYM(fiber_trampoline),.-CSYM(fiber_trampoline)
+#endif
diff --git a/libphobos/libdruntime/config/arm/switchcontext.S 
b/libphobos/libdruntime/config/arm/switchcontext.S
index 3f9b35e7334..f1f2060fd97 100644
--- a/libphobos/libdruntime/config/arm/switchcontext.S
+++ b/libphobos/libdruntime/config/arm/switchcontext.S
@@ -60,11 +60,15 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  
If not, see
  */
 
 .text
+#ifndef __APPLE__
 #if defined(__ARM_PCS_VFP) || (defined(__ARM_PCS) && !defined(__SOFTFP__))
 .fpu vfp
 #endif
 .global CSYM(fiber_switchContext)
 .type CSYM(fiber_switchContext), %function
+#else
+.global CSYM(fiber_switchContext)
+#endif
 .align 4
 CSYM(fiber_switchContext):
 .cfi_sections .debug_frame
@@ -111,8 +115,12 @@ CSYM(fiber_switchContext):
 mov lr, #0
 // return by writing lr into pc
 mov pc, r1
+#ifndef __APPLE__
 .fnend
 .cfi_endproc
 .size CSYM(fiber_switchContext),.-CSYM(fiber_switchContext)
+#else
+.cfi_endproc
+#endif
 
 #endif
diff --git a/libphobos/libdruntime/core/thread/fiber.d 
b/libphobos/libdruntime/core/thread/fiber.d
index 4590ff1c052..66fb9dad89d 100644
--- a/libphobos/libdruntime/core/thread/fiber.d
+++ b/libphobos/libdruntime/core/thread/fiber.d
@@ -1785,6 +1785,7 @@ version (OSX)
 {
 version (X86)version = UnsafeFiberMigration;
 version (X86_64) version = UnsafeFiberMigration;
+version (AArch64) version = UnsafeFiberMigration;
 }
 
 version (UnsafeFiberMigration)
-- 
2.39.2 (Apple Git-143)



[pushed] Darwin, Objective-C: Support -fconstant-cfstrings [PR108743].

2023-07-02 Thread Iain Sandoe via Gcc-patches
Tested on x86_64-darwin and with make pdf and an examination of the revised
output.  Pushed to trunk, thanks
Iain

--- 8< ---

This support the -fconstant-cfstrings option as used by clang (and
expect by some build scripts) as an alias to the target-specific
-mconstant-cfstrings.

The documentation is also updated to reflect that the 'f' option is
only available on Darwin, and to add the 'm' option to the Darwin
section of the invocation text.

Signed-off-by: Iain Sandoe 

PR target/108743

gcc/ChangeLog:

* config/darwin.opt: Add fconstant-cfstrings alias to
mconstant-cfstrings.
* doc/invoke.texi: Amend invocation descriptions to reflect
that the fconstant-cfstrings is a target-option alias and to
add the missing mconstant-cfstrings option description to the
Darwin section.
---
 gcc/config/darwin.opt |  4 
 gcc/doc/invoke.texi   | 27 ---
 2 files changed, 24 insertions(+), 7 deletions(-)

diff --git a/gcc/config/darwin.opt b/gcc/config/darwin.opt
index feaa95867b5..d655aaef2fb 100644
--- a/gcc/config/darwin.opt
+++ b/gcc/config/darwin.opt
@@ -33,6 +33,10 @@ fapple-kext
 Target C++ Var(flag_apple_kext)
 Generate code for darwin loadable kernel extensions.
 
+fconstant-cfstrings
+ObjC ObjC++ Alias(mconstant-cfstrings)
+Generate compile-time CFString objects.
+
 iframework
 Target RejectNegative C ObjC C++ ObjC++ Joined Separate
 -iframework   Add  to the end of the system framework include 
path.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index efcf3bfb3d6..26bcbe26c6c 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -4830,10 +4830,12 @@ and Objective-C++ programs:
 Use @var{class-name} as the name of the class to instantiate for each
 literal string specified with the syntax @code{@@"@dots{}"}.  The default
 class name is @code{NXConstantString} if the GNU runtime is being used, and
-@code{NSConstantString} if the NeXT runtime is being used (see below).  The
-@option{-fconstant-cfstrings} option, if also present, overrides the
-@option{-fconstant-string-class} setting and cause @code{@@"@dots{}"} literals
-to be laid out as constant CoreFoundation strings.
+@code{NSConstantString} if the NeXT runtime is being used (see below).  On
+Darwin (macOS, MacOS X) platforms, the @option{-fconstant-cfstrings} option, if
+also present, overrides the @option{-fconstant-string-class} setting and cause
+@code{@@"@dots{}"} literals to be laid out as constant CoreFoundation strings.
+Note that @option{-fconstant-cfstrings} is an alias for the target-specific
+@option{-mconstant-cfstrings} equivalent.
 
 @opindex fgnu-runtime
 @item -fgnu-runtime
@@ -24118,10 +24120,21 @@ This is by default ON@.
 @item -gfull
 Emit debugging information for all symbols and types.
 
+@opindex fconstant-cfstrings
+@item -fconstant-cfstrings
+The @option{-fconstant-cfstrings} is an alias for 
@option{-mconstant-cfstrings}.
+
+@opindex mconstant-cfstrings
+@item -mconstant-cfstrings
+When the NeXT runtime is being used (the default on these systems), override
+any @option{-fconstant-string-class} setting and cause @code{@@"@dots{}"}
+literals to be laid out as constant CoreFoundation strings.
+
+@opindex mmacosx-version-min
 @item -mmacosx-version-min=@var{version}
-The earliest version of MacOS X that this executable will run on
-is @var{version}.  Typical values of @var{version} include @code{10.1},
-@code{10.2}, and @code{10.3.9}.
+The earliest version of MacOS X that this executable will run on is
+@var{version}.  Typical values supported for @var{version} include @code{12},
+@code{10.12}, and @code{10.5.8}.
 
 If the compiler was built to use the system's headers by default,
 then the default for this option is the system version on which the
-- 
2.39.2 (Apple Git-143)



[pushed] testsuite, Darwin: Remove an unnecessary flags addition.

2023-07-03 Thread Iain Sandoe via Gcc-patches
This has been in use for some time in the Darwin branches that are used
by downstream distributions. Re-tested on x86_64-darwin, pushed to trunk,
thanks,
Iain

--- 8< ---

The addition of the multiply_defined suppress flag has been handled for some
considerable time now in the Darwin specs; remove it from the testsuite libs.
Avoid duplicates in the specs.

Signed-off-by: Iain Sandoe 

gcc/ChangeLog:

* config/darwin.h: Avoid duplicate multiply_defined specs on
earlier Darwin versions with shared libgcc.

libstdc++-v3/ChangeLog:

* testsuite/lib/libstdc++.exp: Remove additional flag handled
by Darwin specs.

gcc/testsuite/ChangeLog:

* lib/g++.exp: Remove additional flag handled by Darwin specs.
* lib/obj-c++.exp: Likewise.
---
 gcc/config/darwin.h  | 5 ++---
 gcc/testsuite/lib/g++.exp| 4 
 gcc/testsuite/lib/obj-c++.exp| 4 
 libstdc++-v3/testsuite/lib/libstdc++.exp | 3 ---
 4 files changed, 2 insertions(+), 14 deletions(-)

diff --git a/gcc/config/darwin.h b/gcc/config/darwin.h
index e6f76e598e6..714d3d5cc0d 100644
--- a/gcc/config/darwin.h
+++ b/gcc/config/darwin.h
@@ -217,8 +217,7 @@ extern GTY(()) int darwin_ms_struct;
   "%{image_base*:-Xlinker -image_base -Xlinker %*} %= 10.7 mmacosx-version-min= -no_pie) }"
 
 #define DARWIN_CC1_SPEC
\
-  "%

[pushed] testsuite, objective-c: Fix a testcase on Windows.

2023-02-15 Thread Iain Sandoe via Gcc-patches
tested by 'nightstrike' on Windows, and on x86_64-darwin21,
pushed to master, thanks,
Iain

--- 8< ---

Windows needs to use uintptr_t to represent an integral pointer type (long
is not the right type there).

Patch from 'nightstike'.

Signed-off-by: Iain Sandoe 

gcc/testsuite/ChangeLog:

* obj-c++.dg/proto-lossage-4.mm: Use uintptr_t for integral pointer
representations.
---
 gcc/testsuite/obj-c++.dg/proto-lossage-4.mm | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/gcc/testsuite/obj-c++.dg/proto-lossage-4.mm 
b/gcc/testsuite/obj-c++.dg/proto-lossage-4.mm
index 2e753d1f8ba..ff053bec7d0 100644
--- a/gcc/testsuite/obj-c++.dg/proto-lossage-4.mm
+++ b/gcc/testsuite/obj-c++.dg/proto-lossage-4.mm
@@ -6,24 +6,26 @@
 /* One-line substitute for objc/objc.h */
 typedef struct objc_object { struct objc_class *class_pointer; } *id;
 
+typedef __UINTPTR_TYPE__ uintptr_t;
+
 @protocol Proto
-- (long)someValue;
+- (uintptr_t)someValue;
 @end
 
 @interface Obj
-- (long)anotherValue;
+- (uintptr_t)anotherValue;
 @end
 
-long foo(void) {
-  long receiver = 2;
+uintptr_t foo(void) {
+  uintptr_t receiver = 2;
   Obj *objrcvr;
   Obj  *objrcvr2;
 
   /* NB: Since 'receiver' is an invalid ObjC message receiver, the compiler
  should warn but then search for methods as if we were messaging 'id'.  */
 
-  receiver += [receiver someValue]; /* { dg-warning "invalid receiver type 
.long int." } */
-  receiver += [receiver anotherValue]; /* { dg-warning "invalid receiver type 
.long int." } */
+  receiver += [receiver someValue]; /* { dg-warning "invalid receiver type 
.uintptr_t." } */
+  receiver += [receiver anotherValue]; /* { dg-warning "invalid receiver type 
.uintptr_t." } */
 
   receiver += [(Obj *)receiver someValue]; /* { dg-warning ".Obj. may not 
respond to .\\-someValue." } */
 /* { dg-error "invalid conversion" "" { target *-*-* } .-1 } */
-- 
2.37.1 (Apple Git-137.1)



[pushed] testsuite, objective-c: Cater for Windows intptr type.

2023-02-16 Thread Iain Sandoe via Gcc-patches
Tested by nightstrike on Windows, and on x86_64 Linux and Darwin and
i686-darwin, pushed to trunk,
thanks
Iain

--- 8< ---

This adjusts the diagnostic output matches to cater for the differences
in intptr types on Windows.

Patch from 'nightstrike'.

Signed-off-by: Iain Sandoe 

gcc/testsuite/ChangeLog:

* objc.dg/proto-lossage-4.m: Amendn diagnostic matches for Windows.
---
 gcc/testsuite/objc.dg/proto-lossage-4.m | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/gcc/testsuite/objc.dg/proto-lossage-4.m 
b/gcc/testsuite/objc.dg/proto-lossage-4.m
index 9d1def5f9de..9b2367a568a 100644
--- a/gcc/testsuite/objc.dg/proto-lossage-4.m
+++ b/gcc/testsuite/objc.dg/proto-lossage-4.m
@@ -28,13 +28,13 @@ long foo(void) {
   receiver += [receiver anotherValue]; /* { dg-warning "invalid receiver type 
.intptr_t." } */
 
   receiver += [(Obj *)receiver someValue]; /* { dg-warning ".Obj. may not 
respond to .\\-someValue." } */
-/* { dg-warning "assignment to 'intptr_t' {aka '(long )?int'} from 'id' makes 
integer from pointer without a cast" "" { target *-*-* } .-1 } */
+/* { dg-warning "assignment to 'intptr_t' {aka '(long )*int'} from 'id' makes 
integer from pointer without a cast" "" { target *-*-* } .-1 } */
 
   receiver += [(Obj *)receiver anotherValue];
   receiver += [(Obj  *)receiver someValue];
   receiver += [(Obj  *)receiver anotherValue];
   receiver += [objrcvr someValue]; /* { dg-warning ".Obj. may not respond to 
.\\-someValue." } */
-/* { dg-warning "assignment to 'intptr_t' {aka '(long )?int'} from 'id' makes 
integer from pointer without a cast" "" { target *-*-* } .-1 } */
+/* { dg-warning "assignment to 'intptr_t' {aka '(long )*int'} from 'id' makes 
integer from pointer without a cast" "" { target *-*-* } .-1 } */
 
   receiver += [objrcvr anotherValue];
   receiver += [(Obj  *)objrcvr someValue];
@@ -42,7 +42,7 @@ long foo(void) {
   receiver += [objrcvr2 someValue];
   receiver += [objrcvr2 anotherValue];
   receiver += [(Obj *)objrcvr2 someValue]; /* { dg-warning ".Obj. may not 
respond to .\\-someValue." } */
-/* { dg-warning "assignment to 'intptr_t' {aka '(long )?int'} from 'id' makes 
integer from pointer without a cast" "" { target *-*-* } .-1 } */
+/* { dg-warning "assignment to 'intptr_t' {aka '(long )*int'} from 'id' makes 
integer from pointer without a cast" "" { target *-*-* } .-1 } */
 
   receiver += [(Obj *)objrcvr2 anotherValue];
 
-- 
2.37.1 (Apple Git-137.1)



Re: [PATCH v2 0/5] A small Texinfo refinement

2023-03-10 Thread Iain Sandoe via Gcc-patches
Hi all,

> On 9 Mar 2023, at 23:35, Sandra Loosemore via Gcc-patches 
>  wrote:
> 
> On 3/9/23 01:26, Richard Biener wrote:
> 
>> SLES 12 has texinfo 4.13a, SLES 15 has texinfo 6.5.  We still provide
>> up-to-date GCC for SLES 12 but we can probably manage in some ways
>> when the texinfo requirement gets bumped.
> 
> OK, this seems to be the oldest version anyone admits to actually using.  I 
> built the manual with Arsen's patches using 4.13a; the build was successful, 
> and I didn't see any obvious issues with the @gol removal in either the PDF 
> or HTML output, so I think we are OK for backward compatibility.

FWIW macOS/Darwin (as delivered by Apple) is stuck on 4.8 (and, presumably, 
very unlikely to advance), but I would expect most macOS FOSS users have 
something newer installed, either self-built or via macposrts/homebrew etc. so 
the “admits to actually using” applies here too I think (personally, I am using 
6.7 but not for any special reason other than it was current when I updated  my 
local toolset).  So I think Darwin can also manage with a newer requirement.

thanks
Iain

> I will work up a patch to remove the references to version 4.7 and replace it 
> with some generic language as I suggested earlier, that won't be so prone to 
> bit rot.
> 
> -Sandra



[pushed] Darwin, libgcc : Adjust min version supported for the OS.

2023-05-19 Thread Iain Sandoe via Gcc-patches
Tested across the Darwin range (this patch has been on the WIP branches for
some time) and on x86_64-linux-gnu, for reference.
pushed to trunk, thanks
Iain

--- 8< ---

Tools from later versions of the OS deprecate or fail to support
earlier OS revisions.

Signed-off-by: Iain Sandoe 

libgcc/ChangeLog:

* config.host: Arrange to set min Darwin OS versions from
the configured host version.
* config/darwin10-unwind-find-enc-func.c: Do not use current
headers, but declare the nexessary structures locally to the
versions in use for Mac OSX 10.6.
* config/t-darwin: Amend to handle configured min OS
versions.
* config/t-darwin-min-1: New.
* config/t-darwin-min-5: New.
* config/t-darwin-min-8: New.
---
 libgcc/config.host| 18 ++
 libgcc/config/darwin10-unwind-find-enc-func.c | 34 ---
 libgcc/config/t-darwin| 10 +++---
 libgcc/config/t-darwin-min-1  |  3 ++
 libgcc/config/t-darwin-min-5  |  3 ++
 libgcc/config/t-darwin-min-8  |  3 ++
 6 files changed, 63 insertions(+), 8 deletions(-)
 create mode 100644 libgcc/config/t-darwin-min-1
 create mode 100644 libgcc/config/t-darwin-min-5
 create mode 100644 libgcc/config/t-darwin-min-8

diff --git a/libgcc/config.host b/libgcc/config.host
index b9975de9023..9d7212028d0 100644
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -233,6 +233,24 @@ case ${host} in
   ;;
   esac
   tmake_file="$tmake_file t-slibgcc-darwin"
+  # newer toolsets produce warnings when building for unsupported versions.
+  case ${host} in
+*-*-darwin1[89]* | *-*-darwin2* )
+  tmake_file="t-darwin-min-8 $tmake_file"
+  ;;
+*-*-darwin9* | *-*-darwin1[0-7]*)
+  tmake_file="t-darwin-min-5 $tmake_file"
+  ;;
+*-*-darwin[4-8]*)
+  tmake_file="t-darwin-min-1 $tmake_file"
+  ;;
+*)
+  # Fall back to configuring for the oldest system known to work with
+  # all archs and the current sources.
+  tmake_file="t-darwin-min-5 $tmake_file"
+  echo "Warning: libgcc configured to support macOS 10.5" 1>&2
+  ;;
+  esac
   extra_parts="crt3.o libd10-uwfef.a crttms.o crttme.o libemutls_w.a"
   ;;
 *-*-dragonfly*)
diff --git a/libgcc/config/darwin10-unwind-find-enc-func.c 
b/libgcc/config/darwin10-unwind-find-enc-func.c
index 882ec3a2372..b08396c5f1b 100644
--- a/libgcc/config/darwin10-unwind-find-enc-func.c
+++ b/libgcc/config/darwin10-unwind-find-enc-func.c
@@ -1,8 +1,34 @@
-#include "tconfig.h"
-#include "tsystem.h"
-#include "unwind-dw2-fde.h"
 #include "libgcc_tm.h"
 
+/* This shim is special, it needs to be built for Mac OSX 10.6
+   regardless of the current system version.
+   We must also build it to use the unwinder layout that was
+   present for 10.6 (and not update that).
+   So we copy the referenced structures from unwind-dw2-fde.h
+   to avoid pulling in newer system headers and/or changed
+   layouts.  */
+struct dwarf_eh_bases
+{
+  void *tbase;
+  void *dbase;
+  void *func;
+};
+
+typedef  int  sword __attribute__ ((mode (SI)));
+typedef unsigned int  uword __attribute__ ((mode (SI)));
+
+/* The first few fields of an FDE.  */
+struct dwarf_fde
+{
+  uword length;
+  sword CIE_delta;
+  unsigned char pc_begin[];
+} __attribute__ ((packed, aligned (__alignof__ (void *;
+
+typedef struct dwarf_fde fde;
+
+extern const fde * _Unwind_Find_FDE (void *, struct dwarf_eh_bases *);
+
 void *
 _darwin10_Unwind_FindEnclosingFunction (void *pc)
 {
@@ -10,5 +36,5 @@ _darwin10_Unwind_FindEnclosingFunction (void *pc)
   const struct dwarf_fde *fde = _Unwind_Find_FDE (pc-1, &bases);
   if (fde)
 return bases.func;
-  return NULL;
+  return (void *) 0;
 }
diff --git a/libgcc/config/t-darwin b/libgcc/config/t-darwin
index 299d26c2c96..a3bb70c6a0a 100644
--- a/libgcc/config/t-darwin
+++ b/libgcc/config/t-darwin
@@ -1,15 +1,15 @@
 # Set this as a minimum (unless overriden by arch t-files) since it's a
 # reasonable lowest common denominator that works for all our archs.
-HOST_LIBGCC2_CFLAGS += -mmacosx-version-min=10.4
+HOST_LIBGCC2_CFLAGS += $(DARWIN_MIN_LIB_VERSION)
 
 crt3.o: $(srcdir)/config/darwin-crt3.c
-   $(crt_compile) -mmacosx-version-min=10.4 -c $<
+   $(crt_compile) $(DARWIN_MIN_CRT_VERSION) -c $<
 
 crttms.o: $(srcdir)/config/darwin-crt-tm.c
-   $(crt_compile) -mmacosx-version-min=10.4 -DSTART -c $<
+   $(crt_compile) $(DARWIN_MIN_CRT_VERSION) -DSTART -c $<
 
 crttme.o: $(srcdir)/config/darwin-crt-tm.c
-   $(crt_compile) -mmacosx-version-min=10.4 -DEND -c $<
+   $(crt_compile) $(DARWIN_MIN_CRT_VERSION) -DEND -c $<
 
 # Make emutls weak so that we can deal with -static-libgcc, override the
 #??hidden visibility when this is present in libgcc_eh.
@@ -25,6 +25,8 @@ libemutls_w.a: emutls_s.o
$(RANLIB_FOR_TARGET) $@
 
 # Patch to __Unwind_Find_Enclosing_Function for Darwin10.
+# This needs to be buil

[pushed] libobjc: Add local macros to support encode generation [P109913].

2023-05-22 Thread Iain Sandoe via Gcc-patches
This fixes bootstrap on powerpc-darwin, and was tested there for
both GNU and NeXT Objective-C testsuite.  Approved in the PR by Andrew,
pushed to trunk, thanks,
Iain

--- 8< ---

r14-976-g9907413a3a6aa3 alters code to use the preferred _P-style
macros rather than direct comparisons of (for example) tree codes.

In the context of libobjc this does not work, since we do not include
the relevant headers; the encoding implementation contains a local
emulation of the target type layouts.

The fix here provides relevant macros local to the use.

Signed-off-by: Iain Sandoe 

PR libobjc/109913

libobjc/ChangeLog:

* encoding.c (RECORD_OR_UNION_TYPE_P, VECTOR_TYPE_P): New.

Co-authored-by: Andrew Pinski 
---
 libobjc/encoding.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/libobjc/encoding.c b/libobjc/encoding.c
index 9bd261c52bd..f1bbd6bf6ee 100644
--- a/libobjc/encoding.c
+++ b/libobjc/encoding.c
@@ -67,6 +67,11 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  If 
not, see
 #define UNION_TYPE  _C_UNION_B
 #define QUAL_UNION_TYPE _C_UNION_B
 #define ARRAY_TYPE  _C_ARY_B
+#define RECORD_OR_UNION_TYPE_P(TYPE)   \
+   ((TREE_CODE (TYPE) == RECORD_TYPE)  \
+|| (TREE_CODE (TYPE) == UNION_TYPE)\
+|| (TREE_CODE (TYPE) == QUAL_UNION_TYPE))
+#define VECTOR_TYPE_P(TYPE) (TREE_CODE (TYPE) == VECTOR_TYPE)
 
 #define REAL_TYPE   _C_DBL
 
-- 
2.39.2 (Apple Git-143)



Re: [PATCH] Objective-C: don't require redundant -fno-objc-sjlj-exceptions for the NeXT v2 ABI

2021-08-03 Thread Iain Sandoe via Gcc-patches



> On 2 Aug 2021, at 22:37, Matt Jacobson via Gcc-patches 
>  wrote:
> 
>> On Aug 2, 2021, at 5:09 PM, Eric Gallager  wrote:
>> 
>> On Wed, Jul 28, 2021 at 11:36 PM Matt Jacobson via Gcc-patches
>>  wrote:
>>> 
>>> As is, an invocation of GCC with -fnext-runtime -fobjc-abi-version=2 
>>> crashes,
>>> unless target-specific code adds an implicit -fno-objc-sjlj-exceptions 
>>> (which
>>> Darwin does).
>>> 
>>> This patch makes the general case not crash.
>>> 
>>> I don't have commit access, so if this patch is suitable, I'd need someone 
>>> else
>>> to commit it for me.  Thanks.
>> 
>> Is there a bug open for the issue that this fixes? Just wondering for
>> cross-referencing purposes...
> 
> No, I didn’t file a bug for this one, just sent the patch directly.  Hope 
> that’s OK.  If not, happy to file one.

I have this on my TODO (and in my “to apply” patch queue - IMO it’s OK as an 
interim
solution - but I think in the longer term it would be better to make 
fobjc-sjlj-exceptions
into a NOP, since the exception models are fixed for NeXT runtime (unless you 
have
some intent to update the 32bit one to use DWARF unwinding ;-) ).

thanks
Iain



Re: [Patch v3 Fortran] Fix c_float128 and c_float128_complex on targets with 128-bit long double.

2021-08-11 Thread Iain Sandoe via Gcc-patches
Hi Folks

> On 11 Aug 2021, at 11:55, Segher Boessenkool  
> wrote:

> On Tue, Aug 10, 2021 at 04:46:11PM -0600, Sandra Loosemore wrote:
>> OK.  I used your wording verbatim for the first one.  For the second 
>> one, I'm still pretty confused as I think it is at least theoretically 
>> possible on PowerPC to have a target with 64-bit long double (AIX?) that 
> 
> Some embedded and embedded-like subtargets use 64-bit long double by
> default.  You can also configure this on any Power target (not that it
> will necessarily work ;-) )
> 
> I don't know if any subtarget with default 64-bit long double supports
> Fortran.

I realize that this is not directly relevant to unscrambling the PPC 128bit 
stuff,
but aarch64-apple-darwin2x has only 64b long double and supports gfortran.
(on both the new M1 desktop macOS and embedded iOS)

 - it is not clear to me yet if there will at some point be a transition to a 
128b
   long double for at least the desktop version.

So the permutation definitely exists for at least one non-legacy, non-embedded
platform (and gfortran is very much in demand from the new M1 users).

Iain

>> also supports the __ibm128 format, and it would be wrong to assume that 
>> *any* 128-bit mode that's not long double is IEEE.
> 
> Absolutely.  Modes are not types, and types are not modes.  There are
> 128-bit floating point modes that are not IEEE, there are that are, and
> either can be used for long double, or neither.
> 
> 
> Segher



Re: [PATCH] Objective-C: fix crash with -fobjc-nilcheck

2021-08-14 Thread Iain Sandoe via Gcc-patches
Hi Matt,

> On 14 Aug 2021, at 09:14, Matt Jacobson via Gcc-patches 
>  wrote:
> 
> When -fobjc-nilcheck is enabled, messages that result in a struct type should 
> yield a zero-initialized struct when sent to nil.  Currently, the frontend 
> crashes when it encounters this situation.  This patch fixes the crash by 
> generating the tree for the `{}` initializer.
> 
> Tested by running the frontend against the example in PR101666 and inspecting 
> the generated code.
> 
> I don't have commit access, so if this patch is suitable, I'd need someone 
> else 
> to commit it for me.  Thanks.

Thanks for the patch,

a couple of requests tho:

1/ please can you either post using a mailer that doesn’t mangle patches or put 
the patch as a plain text attachment
  (pushing to a git branch somewhere public also works for me, but maybe not 
for all reviewers)
   - for small patches like this I can obviously fix things up by hand, but for 
anything larger not a good idea.

2/ since this is fixing a crashing case, we should add a test to the test suite 
for it (and also check the corresponding objective-c++).

thanks
Iain

> 
> 
> gcc/objc/ChangeLog:
> 
> 2021-08-14  Matt Jacobson  
> 
>   PR objc/101666
>   * objc-next-runtime-abi-02.c (build_v2_objc_method_fixup_call): Fix 
> crash.
>   (build_v2_build_objc_method_call): Fix crash.
> 
> 
> diff --git a/gcc/objc/objc-next-runtime-abi-02.c 
> b/gcc/objc/objc-next-runtime-abi-02.c
> index e391ee527ce..42645e22316 100644
> --- a/gcc/objc/objc-next-runtime-abi-02.c
> +++ b/gcc/objc/objc-next-runtime-abi-02.c
> @@ -1676,11 +1676,7 @@ build_v2_objc_method_fixup_call (int super_flag, tree 
> method_prototype,
>   if (TREE_CODE (ret_type) == RECORD_TYPE
>  || TREE_CODE (ret_type) == UNION_TYPE)
>{
> - vec *rtt = NULL;
> - /* ??? CHECKME. hmmm. think we need something more
> -here.  */
> - CONSTRUCTOR_APPEND_ELT (rtt, NULL_TREE, NULL_TREE);
> - ftree = objc_build_constructor (ret_type, rtt);
> + ftree = objc_build_constructor (ret_type, NULL);
>}
>   else
>ftree = fold_convert (ret_type, integer_zero_node);
> @@ -1790,11 +1786,7 @@ build_v2_build_objc_method_call (int super, tree 
> method_prototype,
>   if (TREE_CODE (ret_type) == RECORD_TYPE
>  || TREE_CODE (ret_type) == UNION_TYPE)
>{
> - vec *rtt = NULL;
> - /* ??? CHECKME. hmmm. think we need something more
> -here.  */
> - CONSTRUCTOR_APPEND_ELT (rtt, NULL_TREE, NULL_TREE);
> - ftree = objc_build_constructor (ret_type, rtt);
> + ftree = objc_build_constructor (ret_type, NULL);
>}
>   else
>ftree = fold_convert (ret_type, integer_zero_node);
> 



Re: [PATCH] configure: Allow a host makefile fragment to override PIE flag settings.

2021-08-25 Thread Iain Sandoe via Gcc-patches
Hi,

> On 20 Aug 2021, at 11:29, Richard Sandiford  wrote:
> 
>>> Maybe it would be easier to have the makefile fragments determine
>>> something like CODE_MODEL_CFLAGS, which can be "-fPIC", "-mdynamic-no-pic",
>>> etc., and use:
>>> 
>>> COMPILER += $(NO_PIE_CFLAGS) $(CODE_MODEL_CFLAGS)
>> 
>> OK. I have misgivings about this - the problem is that:
>> 
>> -fPIC -fno-PIE != -fno-PIE -fPIC,  which is not obvious to many folks - who 
>> expect that
>> the “last edition of a flag will be the one in force”.
>> 
>> So the PIE-ness and the PIC-ness are decoupled in the configury but they 
>> need to be
>> ordered specifically for targets that want PIC code by default (FWIW, I 
>> don’t think Darwin
>> is the only default-PIC case here, from discussions on irc).
> 
> Yeah, that's what the above was supposed to achieve.  In other words,
> if you force non-PIE, you also need to follow that by $(CODE_MODEL_CFLAGS),
> which restates whatever the base code model is.
> 
> If it's the decoupling you're worried about, then an alternative would
> be to have:
> 
>  NO_PIE_CFLAGS="-fno-PIE \$(CODE_MODEL_CFLAGS)”

I’d like to ask a couple of questions (of HJ who introduced the no-PIE logic) 
before implementing this.

A. We use no-PIE for cc1* because that is needed to handle the PCH 
implementation (which relies on the executables being loaded at the same 
addresses each time).

B. It’s certainly not obvious to me why we need to build code to run on $build 
to be no-PIE - I don’t see any such dependencies in the generators etc.

 - So Question1 - HJ what was the motivation for making the  XXX_BUILD_XXX 
adopt no-PIE?

——

Independently of this we seem to be building the objects for $host thus:

$(CXX) (NO_PIE_CFLAGS) -c $(ALL_CXXFLAGS) etc.

but we build for $build thus:

$(CXX) -c $(ALL_CXXFLAGS) $(GENERATOR_CFLAGS) -DGENERATOR_FILE 
$(BUILD_NO_PIE_CFLAGS) $(BUILD_CPPFLAGS)

which means that code model flags in $ALL_CXXFLAGS are overridden for $build, 
but active for $host
^^ this is actually what causes the Darwin build fail - since on Darwin we 
cannot build static linked code for user-space processes.

in any event that’s inconsistent (unless there’s a reason that it should be 
different).



below are extracts from gcc/Makefile *on linux* which demonstrates the 
different ordering.

AFAICT, 
NO_PIE_CFLAGS_FOR_BUILD, NO_PIE_FLAG_FOR_BUILD are dead variables?

Question 2 : HJ, what was your intention for how a configuration would request 
PIC code (for example) for things to run on $build?

thanks
Iain

---


ALL_CXXFLAGS = $(T_CFLAGS) $(CFLAGS-$@) $(CXXFLAGS) $(INTERNAL_CFLAGS) \
  $(COVERAGE_FLAGS) $(ALIASING_FLAGS) $(NOEXCEPTION_FLAGS) \

--
# Native compiler for the build machine and its switches.
CC_FOR_BUILD = $(CC)
CXX_FOR_BUILD = $(CXX)
NO_PIE_CFLAGS_FOR_BUILD = 
NO_PIE_FLAG_FOR_BUILD = 
BUILD_CFLAGS= $(ALL_CFLAGS) $(GENERATOR_CFLAGS) -DGENERATOR_FILE
BUILD_CXXFLAGS = $(ALL_CXXFLAGS) $(GENERATOR_CFLAGS) -DGENERATOR_FILE
BUILD_NO_PIE_CFLAGS = $(NO_PIE_CFLAGS)
BUILD_CFLAGS += $(BUILD_NO_PIE_CFLAGS)
BUILD_CXXFLAGS += $(BUILD_NO_PIE_CFLAGS)

# Native compiler that we use.  This may be C++ some day.
COMPILER_FOR_BUILD = $(CXX_FOR_BUILD)
BUILD_COMPILERFLAGS = $(BUILD_CXXFLAGS)

# Native linker that we use.
LINKER_FOR_BUILD = $(CXX_FOR_BUILD)
BUILD_LINKERFLAGS = $(BUILD_CXXFLAGS)

# Native linker and preprocessor flags.  For x-fragment overrides.
BUILD_LDFLAGS=$(LDFLAGS)
BUILD_NO_PIE_FLAG = $(NO_PIE_FLAG)
BUILD_LDFLAGS += $(BUILD_NO_PIE_FLAG)
BUILD_CPPFLAGS= -I. -I$(@D) -I$(srcdir) -I$(srcdir)/$(@D) \
-I$(srcdir)/../include  $(CPPINC) $(CPPFLAGS)
--
# This is the variable actually used when we compile. If you change this,
# you probably want to update BUILD_CFLAGS in configure.ac
ALL_CFLAGS = $(T_CFLAGS) $(CFLAGS-$@) \

build/%.o :  # dependencies provided by explicit rule later
$(COMPILER_FOR_BUILD) -c $(BUILD_COMPILERFLAGS) $(BUILD_CPPFLAGS) \
-o $@ $<

 this has 
$(CXX) -c $(ALL_CXXFLAGS) $(GENERATOR_CFLAGS) -DGENERATOR_FILE 
$(BUILD_NO_PIE_CFLAGS) $(BUILD_CPPFLAGS)
NO_PIE_CFLAGS_FOR_BUILD is apparently ignored

# Rule for the generator programs:
$(genprog:%=build/gen%$(build_exeext)): build/gen%$(build_exeext): build/gen%.o 
$(BUILD_LIBDEPS)
+$(LINKER_FOR_BUILD) $(BUILD_LINKERFLAGS) $(BUILD_LDFLAGS) -o $@ \
$(filter-out $(BUILD_LIBDEPS), $^) $(BUILD_LIBS)

--
build/genversion$(build_exeext): build/genversion.o
+$(LINKER_FOR_BUILD) $(BUILD_LINKERFLAGS) $(BUILD_LDFLAGS) \
build/genversion.o -o $@
=

# The name of the compiler to use.
COMPILER = $(CXX)
COMPILER_FLAGS = $(CXXFLAGS)
# If HOST_LIBS is set, then the user is controlling the libraries to
--
CET_HOST_FLAGS = -fcf-protection
COMPILER += $(CET_HOST_FLAGS)

--
# We don't want to compile the compilers with -fPIE, it make PCH fail.
COMPILER += $(NO_PIE_CFLAGS)

--
# A list of all the language-specific executables.
COMPILERS =  gnat1$(exeext) cc1$(exeext) cc1plu

Re: [PATCH] configure: Allow a host makefile fragment to override PIE flag settings.

2021-08-25 Thread Iain Sandoe via Gcc-patches



> On 25 Aug 2021, at 18:56, H.J. Lu via Gcc-patches  
> wrote:
> 
> On Wed, Aug 25, 2021 at 10:51 AM H.J. Lu  wrote:
>> 
>> On Wed, Aug 25, 2021 at 10:42 AM Iain Sandoe  wrote:
>>> 
>>> Hi,
>>> 
 On 20 Aug 2021, at 11:29, Richard Sandiford  
 wrote:
 
>> Maybe it would be easier to have the makefile fragments determine
>> something like CODE_MODEL_CFLAGS, which can be "-fPIC", 
>> "-mdynamic-no-pic",
>> etc., and use:
>> 
>> COMPILER += $(NO_PIE_CFLAGS) $(CODE_MODEL_CFLAGS)
> 
> OK. I have misgivings about this - the problem is that:
> 
> -fPIC -fno-PIE != -fno-PIE -fPIC,  which is not obvious to many folks - 
> who expect that
> the “last edition of a flag will be the one in force”.
> 
> So the PIE-ness and the PIC-ness are decoupled in the configury but they 
> need to be
> ordered specifically for targets that want PIC code by default (FWIW, I 
> don’t think Darwin
> is the only default-PIC case here, from discussions on irc).
 
 Yeah, that's what the above was supposed to achieve.  In other words,
 if you force non-PIE, you also need to follow that by $(CODE_MODEL_CFLAGS),
 which restates whatever the base code model is.
 
 If it's the decoupling you're worried about, then an alternative would
 be to have:
 
 NO_PIE_CFLAGS="-fno-PIE \$(CODE_MODEL_CFLAGS)”
>>> 
>>> I’d like to ask a couple of questions (of HJ who introduced the no-PIE 
>>> logic) before implementing this.
>>> 
>>> A. We use no-PIE for cc1* because that is needed to handle the PCH 
>>> implementation (which relies on the executables being loaded at the same 
>>> addresses each time).
>>> 
>>> B. It’s certainly not obvious to me why we need to build code to run on 
>>> $build to be no-PIE - I don’t see any such dependencies in the generators 
>>> etc.
>>> 
>>> - So Question1 - HJ what was the motivation for making the  XXX_BUILD_XXX 
>>> adopt no-PIE?
>> 
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71934
>> 
>>> ——
>>> 
>>> Independently of this we seem to be building the objects for $host thus:
>>> 
>>> $(CXX) (NO_PIE_CFLAGS) -c $(ALL_CXXFLAGS) etc.
>>> 
>>> but we build for $build thus:
>>> 
>>> $(CXX) -c $(ALL_CXXFLAGS) $(GENERATOR_CFLAGS) -DGENERATOR_FILE 
>>> $(BUILD_NO_PIE_CFLAGS) $(BUILD_CPPFLAGS)
>>> 
>>> which means that code model flags in $ALL_CXXFLAGS are overridden for 
>>> $build, but active for $host
>>> ^^ this is actually what causes the Darwin build fail - since on Darwin we 
>>> cannot build static linked code for user-space processes.
>>> 
>>> in any event that’s inconsistent (unless there’s a reason that it should be 
>>> different).
>>> 
>>> 
>>> 
>>> below are extracts from gcc/Makefile *on linux* which demonstrates the 
>>> different ordering.
>>> 
>>> AFAICT,
>>> NO_PIE_CFLAGS_FOR_BUILD, NO_PIE_FLAG_FOR_BUILD are dead variables?

^^ what was the intention for these?

>>> Question 2 : HJ, what was your intention for how a configuration would 
>>> request PIC code (for example) for things to run on $build?
> 
> We need to fix
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71934

The need for no-PIE for the exectuables that consume PCH is completely clear 
(but a target can choose not to use PCH - and configure —disable-libstdcxx-pch).

The PR doesn’t explain:

1. why it’s being enabled for the generators (and other $build code) which do 
not use PCH (AFAIK)

2. why the flags ordering is different for $build and $host.

I am completely happy to make the fix Richard suggested - but we seem to be 
adding complexity rather than simplifying things; as noted in the PR there are 
targets that cannot use no-PIE and therefore have to disable PCH anyway.

thanks
Iain

> 
> first.
> 
> H.J.
>>> thanks
>>> Iain
>>> 
>>> ---
>>> 
>>> 
>>> ALL_CXXFLAGS = $(T_CFLAGS) $(CFLAGS-$@) $(CXXFLAGS) $(INTERNAL_CFLAGS) \
>>>  $(COVERAGE_FLAGS) $(ALIASING_FLAGS) $(NOEXCEPTION_FLAGS) \
>>> 
>>> --
>>> # Native compiler for the build machine and its switches.
>>> CC_FOR_BUILD = $(CC)
>>> CXX_FOR_BUILD = $(CXX)
>>> NO_PIE_CFLAGS_FOR_BUILD =
>>> NO_PIE_FLAG_FOR_BUILD =
>>> BUILD_CFLAGS= $(ALL_CFLAGS) $(GENERATOR_CFLAGS) -DGENERATOR_FILE
>>> BUILD_CXXFLAGS = $(ALL_CXXFLAGS) $(GENERATOR_CFLAGS) -DGENERATOR_FILE
>>> BUILD_NO_PIE_CFLAGS = $(NO_PIE_CFLAGS)
>>> BUILD_CFLAGS += $(BUILD_NO_PIE_CFLAGS)
>>> BUILD_CXXFLAGS += $(BUILD_NO_PIE_CFLAGS)
>>> 
>>> # Native compiler that we use.  This may be C++ some day.
>>> COMPILER_FOR_BUILD = $(CXX_FOR_BUILD)
>>> BUILD_COMPILERFLAGS = $(BUILD_CXXFLAGS)
>>> 
>>> # Native linker that we use.
>>> LINKER_FOR_BUILD = $(CXX_FOR_BUILD)
>>> BUILD_LINKERFLAGS = $(BUILD_CXXFLAGS)
>>> 
>>> # Native linker and preprocessor flags.  For x-fragment overrides.
>>> BUILD_LDFLAGS=$(LDFLAGS)
>>> BUILD_NO_PIE_FLAG = $(NO_PIE_FLAG)
>>> BUILD_LDFLAGS += $(BUILD_NO_PIE_FLAG)
>>> BUILD_CPPFLAGS= -I. -I$(@D) -I$(srcdir) -I$(srcdir)/$(@D) \
>>>-I$(srcdir)/../include  $(CPPINC) $(CPPF

Re: [PATCH] configure: Allow a host makefile fragment to override PIE flag settings.

2021-08-25 Thread Iain Sandoe via Gcc-patches



> On 25 Aug 2021, at 19:22, H.J. Lu  wrote:
> 
> On Wed, Aug 25, 2021 at 11:10 AM Iain Sandoe  wrote:
>> 
>> 
>> 
>>> On 25 Aug 2021, at 18:56, H.J. Lu via Gcc-patches  
>>> wrote:
>>> 
>>> On Wed, Aug 25, 2021 at 10:51 AM H.J. Lu  wrote:
 
 On Wed, Aug 25, 2021 at 10:42 AM Iain Sandoe  
 wrote:
> 
> Hi,
> 
>> On 20 Aug 2021, at 11:29, Richard Sandiford  
>> wrote:
>> 
 Maybe it would be easier to have the makefile fragments determine
 something like CODE_MODEL_CFLAGS, which can be "-fPIC", 
 "-mdynamic-no-pic",
 etc., and use:
 
 COMPILER += $(NO_PIE_CFLAGS) $(CODE_MODEL_CFLAGS)
>>> 
>>> OK. I have misgivings about this - the problem is that:
>>> 
>>> -fPIC -fno-PIE != -fno-PIE -fPIC,  which is not obvious to many folks - 
>>> who expect that
>>> the “last edition of a flag will be the one in force”.
>>> 
>>> So the PIE-ness and the PIC-ness are decoupled in the configury but 
>>> they need to be
>>> ordered specifically for targets that want PIC code by default (FWIW, I 
>>> don’t think Darwin
>>> is the only default-PIC case here, from discussions on irc).
>> 
>> Yeah, that's what the above was supposed to achieve.  In other words,
>> if you force non-PIE, you also need to follow that by 
>> $(CODE_MODEL_CFLAGS),
>> which restates whatever the base code model is.
>> 
>> If it's the decoupling you're worried about, then an alternative would
>> be to have:
>> 
>> NO_PIE_CFLAGS="-fno-PIE \$(CODE_MODEL_CFLAGS)”
> 
> I’d like to ask a couple of questions (of HJ who introduced the no-PIE 
> logic) before implementing this.
> 
> A. We use no-PIE for cc1* because that is needed to handle the PCH 
> implementation (which relies on the executables being loaded at the same 
> addresses each time).
> 
> B. It’s certainly not obvious to me why we need to build code to run on 
> $build to be no-PIE - I don’t see any such dependencies in the generators 
> etc.
> 
> - So Question1 - HJ what was the motivation for making the  XXX_BUILD_XXX 
> adopt no-PIE?
 
 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71934
 
> ——
> 
> Independently of this we seem to be building the objects for $host thus:
> 
> $(CXX) (NO_PIE_CFLAGS) -c $(ALL_CXXFLAGS) etc.
> 
> but we build for $build thus:
> 
> $(CXX) -c $(ALL_CXXFLAGS) $(GENERATOR_CFLAGS) -DGENERATOR_FILE 
> $(BUILD_NO_PIE_CFLAGS) $(BUILD_CPPFLAGS)
> 
> which means that code model flags in $ALL_CXXFLAGS are overridden for 
> $build, but active for $host
> ^^ this is actually what causes the Darwin build fail - since on Darwin 
> we cannot build static linked code for user-space processes.
> 
> in any event that’s inconsistent (unless there’s a reason that it should 
> be different).
> 
> 
> 
> below are extracts from gcc/Makefile *on linux* which demonstrates the 
> different ordering.
> 
> AFAICT,
> NO_PIE_CFLAGS_FOR_BUILD, NO_PIE_FLAG_FOR_BUILD are dead variables?
>> 
>> ^^ what was the intention for these?
>> 
> Question 2 : HJ, what was your intention for how a configuration would 
> request PIC code (for example) for things to run on $build?
>>> 
>>> We need to fix
>>> 
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71934
>> 
>> The need for no-PIE for the exectuables that consume PCH is completely clear 
>> (but a target can choose not to use PCH - and configure 
>> —disable-libstdcxx-pch).
>> 
>> The PR doesn’t explain:
>> 
>> 1. why it’s being enabled for the generators (and other $build code) which 
>> do not use PCH (AFAIK)
>> 
>> 2. why the flags ordering is different for $build and $host.
>> 
>> I am completely happy to make the fix Richard suggested - but we seem to be 
>> adding complexity rather than simplifying things; as noted in the PR there 
>> are targets that cannot use no-PIE and therefore have to disable PCH anyway.
> 
> Please follow:
> 
> https://gcc.gnu.org/pipermail/gcc-patches/2015-October/432180.html

I don’t see answers to the questions above in that thead or the PR - there is 
nothing so far in this that explains why no-PIE has been forced on for the 
stuff in gcc/build

but OK.. I’ll look at implementing the patch suggested by Richard,
thanks
Iain





Re: [r11-3641 Regression] FAIL: gcc.dg/torture/pta-ptrarith-1.c -Os scan-tree-dump alias "ESCAPED = {[^\n}]* i f [^\n}]*}" on Linux/x86_64 (-m32 -march=cascadelake)

2020-10-04 Thread Iain Sandoe via Gcc-patches

H.J. Lu via Gcc-patches  wrote:


On Sat, Oct 3, 2020 at 5:57 PM Segher Boessenkool
 wrote:
On Sat, Oct 03, 2020 at 12:21:04PM -0700, sunil.k.pandey via Gcc-patches  
wrote:

On Linux/x86_64,

c34db4b6f8a5d80367c709309f9b00cb32630054 is the first bad commit
commit c34db4b6f8a5d80367c709309f9b00cb32630054
Author: Jan Hubicka 
Date:   Sat Oct 3 17:20:16 2020 +0200

   Track access ranges in ipa-modref

caused


[ ... ]

This isn't a patch.  Wrong mailing list?


I view this as a follow up of

https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555314.html

What do people think about this kind of followups?  Is this appropriate
for this mailing list?


it seems quite noisy - and I wonder how effective; mailing list traffic  
goes by and is forgotten.


ISTM that a much neater solution would be to raise a BZ and add the commit  
author as CC’d


… but that might be too hard to implement?

Iain




Re: Make 'autoreconf' work for 'gcc', 'libobjc' (was: [PATCH] regenerate configure files and config.h.in files)

2022-09-20 Thread Iain Sandoe via Gcc-patches
Hi!

> On 20 Sep 2022, at 14:37, Thomas Schwinge  wrote:

> On 2022-08-25T11:42:01+0200, Martin Liška  wrote:
>> I wrote a scipt that runs autoconf in all folders that have configure.ac
>> file and same for autoheader (where AC_CONFIG_HEADERS is present) and
>> this is the output.
>> 
>> The script can be seen here:
>> https://github.com/marxin/script-misc/blob/master/gcc-autoconf-all.py
> 
> That's similar to what I maintain at
> .
> However, I now found that both our two's approaches are incomplete.  ;-)
> Yours is missing calling 'aclocal', mine 'aclocal' and 'autoheader' (for
> GCC subpackages not using Automake).
> 
> What we really should be doing, in my opinion, is making 'autoreconf'
> work for all GCC subpackages, and that's exactly what the attached patch
> "Make 'autoreconf' work for 'gcc', 'libobjc'" does.  OK to push?

+1 from me …
..  I have been maintaining something similar locally.
Iain

> 
>> I'm going to add the script to my daily Builbot tester.
> 
> Then, make it simply call 'autoreconf' for all 'config_folders'.
> 
> (Also, I'm not running into the issue you've stated in the script that
> "apparently automake is somehow unstable -> skip it for gotools".)
> 
> 
>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>> 
>> Ready to be installed?
> 
> That said, I do confirm the changes of your recent
> commit r13-2200-gb1a3d2b778168341c617aaee6541c66239a198d2
> "regenerate configure files and config.h.in files", and per the attached
> patch "'autoreconf' all of GCC", I'll then be changing a few additional
> pieces.
> 
> 
> Grüße
> Thomas
> 
> 
>> fixincludes/ChangeLog:
>> 
>>  * config.h.in: Regenerate.
>>  * configure: Regenerate.
>> 
>> libada/ChangeLog:
>> 
>>  * configure: Regenerate.
>> 
>> libiberty/ChangeLog:
>> 
>>  * configure: Regenerate.
>> 
>> libobjc/ChangeLog:
>> 
>>  * configure: Regenerate.
>> 
>> liboffloadmic/ChangeLog:
>> 
>>  * configure: Regenerate.
>>  * plugin/configure: Regenerate.
>> 
>> libquadmath/ChangeLog:
>> 
>>  * configure: Regenerate.
>> 
>> libssp/ChangeLog:
>> 
>>  * configure: Regenerate.
>> 
>> libvtv/ChangeLog:
>> 
>>  * configure: Regenerate.
>> 
>> zlib/ChangeLog:
>> 
>>  * configure: Regenerate.
>> ---
>> fixincludes/config.h.in| 204 -
>> fixincludes/configure  |   2 +-
>> libada/configure   |   3 +
>> libiberty/configure|   3 +
>> libobjc/configure  |   6 +-
>> liboffloadmic/configure|  46 +++-
>> liboffloadmic/plugin/configure |  46 +++-
>> libquadmath/configure  |   6 +-
>> libssp/configure   |   6 +-
>> libvtv/configure   |  18 +--
>> zlib/configure |   6 +-
>> 11 files changed, 61 insertions(+), 285 deletions(-)
>> 
>> diff --git a/fixincludes/config.h.in b/fixincludes/config.h.in
>> index 3f6cf1e574e..69a67f5f116 100644
>> --- a/fixincludes/config.h.in
>> +++ b/fixincludes/config.h.in
>> @@ -1,397 +1,211 @@
>> /* config.h.in.  Generated from configure.ac by autoheader.  */
>> 
>> /* Defined to the executable file extension on the host system */
>> -#ifndef USED_FOR_TARGET
>> #undef EXE_EXT
>> -#endif
>> -
>> 
>> /* Define to 1 if you have the `clearerr_unlocked' function. */
>> -#ifndef USED_FOR_TARGET
>> #undef HAVE_CLEARERR_UNLOCKED
>> -#endif
>> -
>> 
>> /* Define to 1 if you have the declaration of `abort', and to 0 if you don't.
>>*/
>> -#ifndef USED_FOR_TARGET
>> #undef HAVE_DECL_ABORT
>> -#endif
>> -
>> 
>> /* Define to 1 if you have the declaration of `asprintf', and to 0 if you
>>don't. */
>> -#ifndef USED_FOR_TARGET
>> #undef HAVE_DECL_ASPRINTF
>> -#endif
>> -
>> 
>> /* Define to 1 if you have the declaration of `basename(char *)', and to 0 if
>>you don't. */
>> -#ifndef USED_FOR_TARGET
>> #undef HAVE_DECL_BASENAME
>> -#endif
>> -
>> 
>> /* Define to 1 if you have the declaration of `clearerr_unlocked', and to 0 
>> if
>>you don't. */
>> -#ifndef USED_FOR_TARGET
>> #undef HAVE_DECL_CLEARERR_UNLOCKED
>> -#endif
>> -
>> 
>> /* Define to 1 if you have the declaration of `errno', and to 0 if you don't.
>>*/
>> -#ifndef USED_FOR_TARGET
>> #undef HAVE_DECL_ERRNO
>> -#endif
>> -
>> 
>> /* Define to 1 if you have the declaration of `feof_unlocked', and to 0 if 
>> you
>>don't. */
>> -#ifndef USED_FOR_TARGET
>> #undef HAVE_DECL_FEOF_UNLOCKED
>> -#endif
>> -
>> 
>> /* Define to 1 if you have the declaration of `ferror_unlocked', and to 0 if
>>you don't. */
>> -#ifndef USED_FOR_TARGET
>> #undef HAVE_DECL_FERROR_UNLOCKED
>> -#endif
>> -
>> 
>> /* Define to 1 if you have the declaration of `fflush_unlocked', and to 0 if
>>you don't. */
>> -#ifndef USED_FOR_TARGET
>> #undef HAVE_DECL_FFLUSH_UNLOCKED
>> -#endif
>> -
>> 
>> /* Define to 1 if you have the declaration of `fgetc_unlocked', and to 0 if
>>you don't. 

Re: [PATCH] Avoid depending on destructor order

2022-09-26 Thread Iain Sandoe via Gcc-patches



> On 26 Sep 2022, at 12:49, Thomas Neumann via Gcc-patches 
>  wrote:
> 
> Hi Claudiu,
> 
>> This change prohibits compiling of ARC backend:
>>> +  gcc_assert (in_shutdown || ob);
>> in_shutdown is only defined when ATOMIC_FDE_FAST_PATH is defined,
>> while gcc_assert is outside of any ifdef. Please can you revisit this
>> line and change it accordingly.
> 
> I have a patch ready, I am waiting for someone to approve my patch:
> 
> https://gcc.gnu.org/pipermail/gcc-patches/2022-September/602130.html

You might also want to include Rainer’s patch,

AFAIR patches to fix bootstrap are allowed to proceed as an exception to
the usual rules,

Iain



[PATCH] coroutines: Use cp_build_init_expr consistently.

2022-10-11 Thread Iain Sandoe via Gcc-patches
Tested on x86_64-darwin19, OK for master?
thanks
Iain

-- >8 --

Now we have the TARGET_EXPR_ELIDING_P flag, it is important to ensure it
is set properly on target exprs.  The code here has a mixture of APIs used
to build inits.  This patch changes that to use cp_build_init_expr() where
possible, since that handles setting the flag.
---
 gcc/cp/coroutines.cc | 25 -
 1 file changed, 8 insertions(+), 17 deletions(-)

diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
index 01a3e831ee5..20d309445eb 100644
--- a/gcc/cp/coroutines.cc
+++ b/gcc/cp/coroutines.cc
@@ -1025,8 +1025,7 @@ build_co_await (location_t loc, tree a, 
suspend_point_kind suspend_kind)
   else
 {
   e_proxy = get_awaitable_var (suspend_kind, o_type);
-  o = cp_build_modify_expr (loc, e_proxy, INIT_EXPR, o,
-   tf_warning_or_error);
+  o = cp_build_init_expr (loc, e_proxy, o);
 }
 
   /* I suppose we could check that this is contextually convertible to bool.  
*/
@@ -2889,8 +2888,7 @@ flatten_await_stmt (var_nest_node *n, hash_set 
*promoted,
  gcc_checking_assert (!already_present);
  tree inner = TREE_OPERAND (init, 1);
  gcc_checking_assert (TREE_CODE (inner) != COND_EXPR);
- init = cp_build_modify_expr (input_location, var, INIT_EXPR, init,
-  tf_warning_or_error);
+ init = cp_build_init_expr (var, init);
  /* Simplify for the case that we have an init containing the temp
 alone.  */
  if (t == n->init && n->var == NULL_TREE)
@@ -3656,8 +3654,7 @@ await_statement_walker (tree *stmt, int *do_subtree, void 
*d)
if (TREE_CODE (cond_inner) == CLEANUP_POINT_EXPR)
  cond_inner = TREE_OPERAND (cond_inner, 0);
location_t sloc = EXPR_LOCATION (SWITCH_STMT_COND (sw_stmt));
-   tree new_s = cp_build_init_expr (sloc, newvar,
-cond_inner);
+   tree new_s = cp_build_init_expr (sloc, newvar, cond_inner);
finish_expr_stmt (new_s);
SWITCH_STMT_COND (sw_stmt) = newvar;
/* Now add the switch statement with the condition re-
@@ -4902,9 +4899,8 @@ morph_fn_to_coro (tree orig, tree *resumer, tree 
*destroyer)
  if (flag_exceptions)
{
  /* This var is now live.  */
- r = build_modify_expr (fn_start, parm.guard_var,
-boolean_type_node, INIT_EXPR, fn_start,
-boolean_true_node, boolean_type_node);
+ r = cp_build_init_expr (fn_start, parm.guard_var,
+ boolean_true_node);
  finish_expr_stmt (r);
}
}
@@ -4948,9 +4944,7 @@ morph_fn_to_coro (tree orig, tree *resumer, tree 
*destroyer)
   r = coro_build_cvt_void_expr_stmt (r, fn_start);
   finish_expr_stmt (r);
 
-  r = build_modify_expr (fn_start, coro_promise_live, boolean_type_node,
-INIT_EXPR, fn_start, boolean_true_node,
-boolean_type_node);
+  r = cp_build_init_expr (fn_start, coro_promise_live, boolean_true_node);
   finish_expr_stmt (r);
 
   promise_dtor
@@ -5031,8 +5025,7 @@ morph_fn_to_coro (tree orig, tree *resumer, tree 
*destroyer)
   NULL_TREE);
   add_decl_expr (gro);
   gro_bind_vars = gro;
-  r = cp_build_modify_expr (input_location, gro, INIT_EXPR, get_ro,
-   tf_warning_or_error);
+  r = cp_build_init_expr (gro, get_ro);
   /* The constructed object might require a cleanup.  */
   if (TYPE_HAS_NONTRIVIAL_DESTRUCTOR (gro_type))
{
@@ -5053,9 +5046,7 @@ morph_fn_to_coro (tree orig, tree *resumer, tree 
*destroyer)
  cleanup.  */
   if (gro_ret_dtor)
 {
-   r = build_modify_expr (fn_start, coro_gro_live, boolean_type_node,
- INIT_EXPR, fn_start, boolean_true_node,
- boolean_type_node);
+   r = cp_build_init_expr (fn_start, coro_gro_live, boolean_true_node);
   finish_expr_stmt (r);
 }
   /* Initialize the resume_idx_var to 0, meaning "not started".  */
-- 
2.24.3 (Apple Git-128)



[pushed] Darwin, libgcc: Fix build errors on powerpc-darwin8.

2022-03-04 Thread Iain Sandoe via Gcc-patches
PowerPC Darwin8 is the last version to use an unwind frame fallback routine.
This had been omitted from the new shared EH library, along with one more
header dependency that only fires there.

tested on x86_64-darwin18, powerpc-darwin9 and cross to powerpc-darwin8
pushed to master, thanks
Iain

Signed-off-by: Iain Sandoe 

libgcc/ChangeLog:

* config/rs6000/t-darwin-ehs: Add darwin-fallback.o.
* config/t-darwin-ehs: Add dependency on unwind.h.
---
 libgcc/config/rs6000/t-darwin-ehs | 4 ++--
 libgcc/config/t-darwin-ehs| 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/libgcc/config/rs6000/t-darwin-ehs 
b/libgcc/config/rs6000/t-darwin-ehs
index 42f521411af..581344e862a 100644
--- a/libgcc/config/rs6000/t-darwin-ehs
+++ b/libgcc/config/rs6000/t-darwin-ehs
@@ -1,3 +1,3 @@
-# We need the save_world code for the EH library.
+# We need the save_world and anu unwind fallback code for the EH library.
 
-LIBEHSOBJS += darwin-world_s.o
+LIBEHSOBJS += darwin-world_s.o darwin-fallback.o
diff --git a/libgcc/config/t-darwin-ehs b/libgcc/config/t-darwin-ehs
index 95275023dac..df46f8a6529 100644
--- a/libgcc/config/t-darwin-ehs
+++ b/libgcc/config/t-darwin-ehs
@@ -3,5 +3,5 @@
 
 LIBEHSOBJS = unwind-dw2_s.o unwind-dw2-fde-darwin_s.o unwind-c_s.o
 
-unwind-dw2_s.o: gthr-default.h md-unwind-support.h
+unwind-dw2_s.o: gthr-default.h md-unwind-support.h unwind.h
 $(LIBEHSOBJS): libgcc_tm.h
-- 
2.24.3 (Apple Git-128)



[pushed] Darwin: Fix a type mismatch warning for a non-GCC bootstrap compiler.

2022-03-04 Thread Iain Sandoe via Gcc-patches
DECL_MD_FUNCTION_CODE() returns an int, on one particular compiler the
code in darwin_fold_builtin() triggers a warning.

Fixed thus.

tested on x86_64-darwin18, powerpc-darwin9, cross to powerpc-darwin8.
pushed to master, thanks
Iain

Signed-off-by: Iain Sandoe 

gcc/ChangeLog:

* config/darwin.cc (darwin_fold_builtin): Make fcode an int to
avoid a mismatch with DECL_MD_FUNCTION_CODE().
---
 gcc/config/darwin.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/config/darwin.cc b/gcc/config/darwin.cc
index 783fe3cb443..f065a13d73d 100644
--- a/gcc/config/darwin.cc
+++ b/gcc/config/darwin.cc
@@ -3621,7 +3621,7 @@ tree
 darwin_fold_builtin (tree fndecl, int n_args, tree *argp,
 bool ARG_UNUSED (ignore))
 {
-  unsigned int fcode = DECL_MD_FUNCTION_CODE (fndecl);
+  int fcode = DECL_MD_FUNCTION_CODE (fndecl);
 
   if (fcode == darwin_builtin_cfstring)
 {
-- 
2.24.3 (Apple Git-128)



[pushed] Darwin: Address a translation comment [PR104552].

2022-03-08 Thread Iain Sandoe via Gcc-patches
This amends an error message to correct punctuation and a little
better wording.

bootstrapped on x86_64-darwin18, pushed to master,
thanks, Iain

Signed-off-by: Iain Sandoe 

PR translation/104552

gcc/ChangeLog:

* config/host-darwin.cc (darwin_gt_pch_get_address): Amend
the PCH out of memory error message punctuation and wording.
---
 gcc/config/host-darwin.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/config/host-darwin.cc b/gcc/config/host-darwin.cc
index d4289aeb4d3..01554d565f9 100644
--- a/gcc/config/host-darwin.cc
+++ b/gcc/config/host-darwin.cc
@@ -104,7 +104,7 @@ darwin_gt_pch_get_address (size_t sz, int fd)
  space.  */
   if (addr == (void *) MAP_FAILED)
 {
-  error ("PCH memory not available %m");
+  error ("PCH memory is not available: %m");
   return NULL;
 }
 
-- 
2.24.3 (Apple Git-128)



[PATCH 1/2] libcody: Do not use a dummy port number in getaddrinfo().

2022-03-13 Thread Iain Sandoe via Gcc-patches
The getaddrinfo() call requires either a non-null name for the server or
a port service / number.  In the code that opens a connection we have
been calling this with a dummy port number of "0".  Unfortunately this
triggers a crashing bug in some BSD versions (and OSes importing that code).

In this part of the code we do not really need a port number, since it
is not reasonable to open a connection to an unspecified host.

Setting hints ai_flags field to 0, and the servname parm to nullptr works
around the BSD bug in this case.

Also posted upstream.

(fixes bad-mapper-2/3 on the versions affected).

tested on powerpc,i686-darwin9, x86-64-darwin10,17,20 
powerpc64le,powerpc64,x86_64-linux-gnu,

OK for master?
eventual backports?
thanks
Iain

Signed-off-by: Iain Sandoe 

libcody/ChangeLog:

* netclient.cc (OpenInet6): Do not provide a dummy port number
in the getaddrinfo() call.
---
 libcody/netclient.cc | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/libcody/netclient.cc b/libcody/netclient.cc
index 7f81dd91810..558808be485 100644
--- a/libcody/netclient.cc
+++ b/libcody/netclient.cc
@@ -93,7 +93,7 @@ int OpenInet6 (char const **e, char const *name, int port)
 }
 
   addrinfo hints;
-  hints.ai_flags = AI_NUMERICSERV;
+  hints.ai_flags = 0;
   hints.ai_family = AF_INET6;
   hints.ai_socktype = SOCK_STREAM;
   hints.ai_protocol = 0;
@@ -102,9 +102,7 @@ int OpenInet6 (char const **e, char const *name, int port)
   hints.ai_canonname = nullptr;
   hints.ai_next = nullptr;
 
-  /* getaddrinfo requires a port number, but is quite happy to accept
- invalid ones.  So don't rely on it.  */
-  if (int err = getaddrinfo (name, "0", &hints, &addrs))
+  if (int err = getaddrinfo (name, nullptr, &hints, &addrs))
 {
   errstr = gai_strerror (err);
   // What's the best errno to set?
-- 
2.24.3 (Apple Git-128)



[PATCH 2/2] c++tools: Work around a BSD bug in getaddrinfo().

2022-03-13 Thread Iain Sandoe via Gcc-patches
Some versions of the BSD getaddrinfo() call do not work with the specific
input of "0" for the servname entry (a segv results).  Since we are making
the call with a dummy port number, the value is actually not important, other
than it should be in range.  Work around the BSD bug by using "1" instead.

tested on powerpc,i686-darwin9, x86-64-darwin10,17,20 
powerpc64le,powerpc64,x86_64-linux-gnu,

OK for master?
eventual backports?
thanks
Iain

Signed-off-by: Iain Sandoe 

c++tools/ChangeLog:

* server.cc (accept_from): Use "1" as the dummy port number.
---
 c++tools/server.cc | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/c++tools/server.cc b/c++tools/server.cc
index 8c6ad314886..00154a05925 100644
--- a/c++tools/server.cc
+++ b/c++tools/server.cc
@@ -360,7 +360,11 @@ accept_from (char *arg ATTRIBUTE_UNUSED)
   hints.ai_next = NULL;
 
   struct addrinfo *addrs = NULL;
-  if (int e = getaddrinfo (slash == arg ? NULL : arg, "0", &hints, &addrs))
+  /* getaddrinfo requires either hostname or servname to be non-null, so that 
we must
+ set a port number (to cover the case that the string passed contains just 
/NN).
+ Use an arbitrary in-range port number, but avoiding "0" which triggers a 
bug on
+ some BSD variants.  */
+  if (int e = getaddrinfo (slash == arg ? NULL : arg, "1", &hints, &addrs))
 {
   noisy ("cannot resolve '%s': %s", arg, gai_strerror (e));
   ok = false;
-- 
2.24.3 (Apple Git-128)



Re: [PATCH] doc: Document Solaris D bootstrap requirements [PR 103528]

2022-03-16 Thread Iain Sandoe via Gcc-patches



> On 16 Mar 2022, at 13:28, Rainer Orth  wrote:
> 
> This patch documents the Solaris-specific D bootstrap requirements.
> 
> Tested by building and inspecting gccinstall.{pdf,info}.
> 
> Ok for trunk?
> 
> I've omitted the Darwin-specific stuff so far documented in PRs d/103577
> and d/103578:
> 
> * needs --enable-libphobos
> * top of gcc-11 branch only
> * backport of -static-libphobos patch
> * Darwin/i386 doesn't work at all

— hopefully we will not need to add that  —

The actual problem is known (FWIW there is also some wrong code generated for
x86_64, we just happen to link it to something harmless instead of failing to 
link).

- I remain hopeful that a solution for 11.x can be found before gcc-12 branches,
since without m32 support it is hard for me to fit D into regular Darwin 
testing (at
present D is effectively untested on Darwin since the change to require a D 
bootstrap)
 .. at one stage, D did work on m32 Darwin.

Iain

> 
>   Rainer
> 
> -- 
> -
> Rainer Orth, Center for Biotechnology, Bielefeld University
> 
> 
> 2022-03-16  Rainer Orth  
> 
>   gcc:
>   PR d/103528
>   * doc/install.texi (Tools/packages necessary for building GCC)
>   (GDC): Document libphobos requirement.
>   (Host/target specific installation notes for GCC, *-*-solaris2*):
>   Document libphobos and GDC specifics.
> 
> # HG changeset patch
> # Parent  33de4c9d886299fd8cc97e20c0f761c2f28a3eef
> doc: Document Solaris D bootstrap requirements [PR 103528]
> 
> diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
> --- a/gcc/doc/install.texi
> +++ b/gcc/doc/install.texi
> @@ -287,7 +287,8 @@ section.
> @item @anchor{GDC-prerequisite}GDC
> 
> In order to build GDC, the D compiler, you need a working GDC
> -compiler (GCC version 9.1 or later), as the D front end is written in D.
> +compiler (GCC version 9.1 or later) and D runtime library,
> +@samp{libphobos}, as the D front end is written in D.
> 
> Versions of GDC prior to 12 can be built with an ISO C++11 compiler, which can
> then be installed and used to bootstrap newer versions of the D front end.
> @@ -303,6 +304,10 @@ front end does not make use of any GDC-s
> of the D language, if too old a GDC version is installed and
> @option{--enable-languages=d} is used, the build will fail.
> 
> +On some targets, @samp{libphobos} isn't enabled by default, but compiles
> +and works if @option{--enable-libphobos} is used.  Specifics are
> +documented for affected targets.
> +
> @item A ``working'' POSIX compatible shell, or GNU bash
> 
> Necessary when running @command{configure} because some
> @@ -4851,6 +4856,12 @@ GNU binutils.  @samp{libstdc++} symbol v
> appropriate version is found.  Solaris @command{c++filt} from the Solaris
> Studio compilers does @emph{not} work.
> 
> +In order to build the GNU D compiler, GDC, a working @samp{libphobos} is
> +needed.  That library wasn't built by default in GCC 9--11 on SPARC, or
> +on x86 when the Solaris assembler is used, but can be enabled by
> +configuring with @option{--enable-libphobos}.  Also, GDC 9.4.0 is
> +required on x86, while GDC 9.3.0 is known to work on SPARC.
> +
> The versions of the GNU Multiple Precision Library (GMP), the MPFR
> library and the MPC library bundled with Solaris 11.3 and later are
> usually recent enough to match GCC's requirements.  There are two
> @@ -4864,6 +4875,7 @@ need to configure with @option{--with-gm
> @item
> The version of the MPFR libary included in Solaris 11.3 is too old; you
> need to provide a more recent one.
> +
> @end itemize
> 
> @html



Re: [PATCH] doc: Document Solaris D bootstrap requirements [PR 103528]

2022-03-16 Thread Iain Sandoe via Gcc-patches
Hi Rainer,

> On 16 Mar 2022, at 15:55, Rainer Orth  wrote:
> 
>>> I've omitted the Darwin-specific stuff so far documented in PRs d/103577
>>> and d/103578:
>>> 
>>> * needs --enable-libphobos
>>> * top of gcc-11 branch only
>>> * backport of -static-libphobos patch
>>> * Darwin/i386 doesn't work at all
>> 
>> — hopefully we will not need to add that  —
>> 
>> The actual problem is known (FWIW there is also some wrong code generated for
>> x86_64, we just happen to link it to something harmless instead of failing
>> to link).
> 
> I see.  One issue I see during x86_64-darwin testing (10.7 only?) is
> that the forkgc2 test hangs and has to be killed manually.

yes, there are  known issues with GC and threading - but those do not break 
bootstrap
since the compiler is single-threaded.

>> - I remain hopeful that a solution for 11.x can be found before gcc-12 
>> branches,
>> since without m32 support it is hard for me to fit D into regular Darwin
>> testing (at
>> present D is effectively untested on Darwin since the change to require a D
>> bootstrap)
>> .. at one stage, D did work on m32 Darwin.
> 
> I suspected that the 32-bit issue might be due to several stdint types
> being wrong, which was just fixed on master.  At least the issue seemed
> similar to PR d/104738.  I'm building a 64-bit trunk gdc as we speak in
> order to try that as a bootstrap compiler for a 32-bit build.

The issue on 11.x is related to code that tries to synthesize section-start
symbols, it causes a link fail on m32 - which is a bootstrap breaker.

..  if that has been fixed for m32 codegenon master then, yes - presumably we
could build an x86_64 compiler and use that “-m32” to make an i686 bootstrap.

Iain.



[pushed] testsuite, modules, Darwin: Adjust expected output for older OS versions.

2022-03-18 Thread Iain Sandoe via Gcc-patches
Darwin versions <= 10 (macOS 10.6) emit different diagnostics for the failure
case being tested by bad-mapper-1.C.  Adjust the dg- expressions to reflect 
this.

tested on powerpc,i686-darwin9, x86-64-darwin10,17,20 
powerpc64le,powerpc64,x86_64-linux-gnu,
pushed to master, thanks
Iain

Signed-off-by: Iain Sandoe 

gcc/testsuite/ChangeLog:

* g++.dg/modules/bad-mapper-1.C: Make dg- expressions that match the
diagnostics output by earlier Darwin too.
---
 gcc/testsuite/g++.dg/modules/bad-mapper-1.C | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/gcc/testsuite/g++.dg/modules/bad-mapper-1.C 
b/gcc/testsuite/g++.dg/modules/bad-mapper-1.C
index 7ed75b824b4..6d0ed4b5895 100644
--- a/gcc/testsuite/g++.dg/modules/bad-mapper-1.C
+++ b/gcc/testsuite/g++.dg/modules/bad-mapper-1.C
@@ -1,6 +1,9 @@
 //  { dg-additional-options "-fmodules-ts -fmodule-mapper=|this-will-not-work" 
}
 import unique1.bob;
-// { dg-error "-:failed exec.*mapper.* .*this-will-not-work" "" { target *-*-* 
} 0 }
+// { dg-error "-:failed exec.*mapper.* .*this-will-not-work" "" { target { ! { 
*-*-darwin[89]* *-*-darwin10* } } } 0 }
 // { dg-prune-output "fatal error:" }
 // { dg-prune-output "failed to read" }
 // { dg-prune-output "compilation terminated" }
+// { dg-error "-:failed mapper handshake communication" "" { target { 
*-*-darwin[89]* *-*-darwin10* } } 0 }
+// { dg-prune-output "trying to exec .this-will-not-work."  }
+// { dg-prune-output "unknown Compiled Module Interface"  }
-- 
2.24.3 (Apple Git-128)



[pushed] libgccjit: Fix a bootstrap break for some targets.

2022-04-14 Thread Iain Sandoe via Gcc-patches
Some targets use 'long long unsigned int' for unsigned HW int, and this
leads to a Werror=format= fail for two print cases in jit-playback.cc
introduced in r12-8117-g30f7c83e9cfe (Add support for bitcasts [PR104071])

As discussed on IRC, casting to (long) seems entirely reasonable for the
values (since they are type sizes).

tested that this fixes bootstrap on x86_64-darwin19 and running check-jit.
pushed to master, thanks
Iain

Signed-off-by: Iain Sandoe 

gcc/jit/ChangeLog:

* jit-playback.cc (new_bitcast): Cast values returned by tree_to_uhwi
to 'long' to match the print format.
---
 gcc/jit/jit-playback.cc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/jit/jit-playback.cc b/gcc/jit/jit-playback.cc
index b1e72fbcf8a..6be6bdf8dea 100644
--- a/gcc/jit/jit-playback.cc
+++ b/gcc/jit/jit-playback.cc
@@ -1440,10 +1440,10 @@ new_bitcast (location *loc,
 active_playback_ctxt->add_error (loc,
   "bitcast with types of different sizes");
 fprintf (stderr, "input expression (size: %ld):\n",
-  tree_to_uhwi (expr_size));
+  (long) tree_to_uhwi (expr_size));
 debug_tree (t_expr);
 fprintf (stderr, "requested type (size: %ld):\n",
-  tree_to_uhwi (type_size));
+  (long) tree_to_uhwi (type_size));
 debug_tree (t_dst_type);
   }
   tree t_bitcast = build1 (VIEW_CONVERT_EXPR, t_dst_type, t_expr);
-- 
2.24.3 (Apple Git-128)



[PATCH] c++, coroutines: Make sure our temporaries are in a bind expr [PR105287]

2022-04-18 Thread Iain Sandoe via Gcc-patches
There are a few cases where we can generate a temporary that does not need
to be added to the coroutine frame (i.e. these are genuinely ephemeral).  The
intent was that unnamed temporaries should not be 'promoted' to coroutine
frame entries.  However there was a thinko and these were not actually ever
added to the bind expressions being generated for the expanded awaits.  This
meant that they were showing in the global namspace, leading to an empty
DECL_CONTEXT and the ICE reported.

tested on x86_64-darwin, OK for mainline? / Backports? (when?)
thanks,
Iain

Signed-off-by: Iain Sandoe 

PR c++/105287

gcc/cp/ChangeLog:

* coroutines.cc (maybe_promote_temps): Ensure generated temporaries
are added to the bind expr.
(add_var_to_bind): Fix local var naming to use portable punctuation.
(register_local_var_uses): Do not add synthetic names to unnamed
temporaries.

gcc/testsuite/ChangeLog:

* g++.dg/coroutines/pr105287.C: New test.
---
 gcc/cp/coroutines.cc   | 17 
 gcc/testsuite/g++.dg/coroutines/pr105287.C | 48 ++
 2 files changed, 56 insertions(+), 9 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/coroutines/pr105287.C

diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
index a9ce6e050dd..dcc2284171b 100644
--- a/gcc/cp/coroutines.cc
+++ b/gcc/cp/coroutines.cc
@@ -3103,7 +3103,7 @@ maybe_promote_temps (tree *stmt, void *d)
 If the initializer is a conditional expression, we need to collect
 and declare any promoted variables nested within it.  DTORs for such
 variables must be run conditionally too.  */
-  if (t->var && DECL_NAME (t->var))
+  if (t->var)
{
  tree var = t->var;
  DECL_CHAIN (var) = vlist;
@@ -3304,7 +3304,7 @@ add_var_to_bind (tree& bind, tree var_type,
   tree b_vars = BIND_EXPR_VARS (bind);
   /* Build a variable to hold the condition, this will be included in the
  frame as a local var.  */
-  char *nam = xasprintf ("%s.%d", nam_root, nam_vers);
+  char *nam = xasprintf ("`__%s_%d", nam_root, nam_vers);
   tree newvar = build_lang_decl (VAR_DECL, get_identifier (nam), var_type);
   free (nam);
   DECL_CHAIN (newvar) = b_vars;
@@ -3949,7 +3949,7 @@ register_local_var_uses (tree *stmt, int *do_subtree, 
void *d)
 scopes with identically named locals and still be able to
 identify them in the coroutine frame.  */
  tree lvname = DECL_NAME (lvar);
- char *buf;
+ char *buf = NULL;
 
  /* The outermost bind scope contains the artificial variables that
 we inject to implement the coro state machine.  We want to be able
@@ -3959,14 +3959,13 @@ register_local_var_uses (tree *stmt, int *do_subtree, 
void *d)
  else if (lvname != NULL_TREE)
buf = xasprintf ("%s_%u_%u", IDENTIFIER_POINTER (lvname),
 lvd->nest_depth, lvd->bind_indx);
- else
-   buf = xasprintf ("_D%u_%u_%u", DECL_UID (lvar), lvd->nest_depth,
-lvd->bind_indx);
  /* TODO: Figure out if we should build a local type that has any
 excess alignment or size from the original decl.  */
- local_var.field_id
-   = coro_make_frame_entry (lvd->field_list, buf, lvtype, lvd->loc);
- free (buf);
+ if (buf) {
+   local_var.field_id
+ = coro_make_frame_entry (lvd->field_list, buf, lvtype, lvd->loc);
+   free (buf);
+ }
  /* We don't walk any of the local var sub-trees, they won't contain
 any bind exprs.  */
}
diff --git a/gcc/testsuite/g++.dg/coroutines/pr105287.C 
b/gcc/testsuite/g++.dg/coroutines/pr105287.C
new file mode 100644
index 000..9790945287d
--- /dev/null
+++ b/gcc/testsuite/g++.dg/coroutines/pr105287.C
@@ -0,0 +1,48 @@
+// { dg-additional-options "-fanalyzer" }
+// { dg-excess-errors "lots of analyzer output, but no ICE" }
+namespace std {
+template  struct coroutine_traits : _Result {};
+template  struct coroutine_handle {
+  operator coroutine_handle<>();
+};
+}
+struct coro1 {
+  using handle_type = std::coroutine_handle<>;
+  coro1(handle_type);
+  struct suspend_always_prt {
+bool await_ready() noexcept;
+void await_suspend(handle_type) noexcept;
+void await_resume() noexcept;
+  };
+  struct promise_type {
+std::coroutine_handle<> ch_;
+auto get_return_object() { return ch_; }
+auto initial_suspend() { return suspend_always_prt{}; }
+auto final_suspend() noexcept { return suspend_always_prt{}; }
+void unhandled_exception();
+  };
+};
+struct BoolAwaiter {
+  BoolAwaiter(bool);
+  bool await_ready();
+  void await_suspend(std::coroutine_handle<>);
+  bool await_resume();
+};
+struct IntAwaiter {
+  IntAwaiter(int);
+  bool await_ready();
+  void await_suspend(std::coroutine_handle<>);
+  int await_resume();
+};
+coro1 my_coro() {
+ int a = 1;
+ if (a =

[PATCH] c++, coroutines: Account for overloaded promise return_value() [PR105301].

2022-04-18 Thread Iain Sandoe via Gcc-patches
Whether it was intended or not, it is possible to define a coroutine promise
with multiple return_value() methods [which need not even have the same type].

We were not accounting for this possibility in the check to see whether both
return_value and return_void are specifier (which is prohibited by the
standard).  Fixed thus and provided an adjusted diagnostic for the case that
multiple return_value() methods are present.

tested on x86_64-darwin, OK for mainline? / Backports? (when?)
thanks,
Iain

Signed-off-by: Iain Sandoe 

PR c++/105301

gcc/cp/ChangeLog:

* coroutines.cc (coro_promise_type_found_p): Account for possible
mutliple overloads of the promise return_value() method.

gcc/testsuite/ChangeLog:

* g++.dg/coroutines/pr105301.C: New test.
---
 gcc/cp/coroutines.cc   | 10 -
 gcc/testsuite/g++.dg/coroutines/pr105301.C | 49 ++
 2 files changed, 57 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/coroutines/pr105301.C

diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
index dcc2284171b..d2a765cac11 100644
--- a/gcc/cp/coroutines.cc
+++ b/gcc/cp/coroutines.cc
@@ -513,8 +513,14 @@ coro_promise_type_found_p (tree fndecl, location_t loc)
  coro_info->promise_type);
  inform (DECL_SOURCE_LOCATION (BASELINK_FUNCTIONS (has_ret_void)),
  "% declared here");
- inform (DECL_SOURCE_LOCATION (BASELINK_FUNCTIONS (has_ret_val)),
- "% declared here");
+ has_ret_val = BASELINK_FUNCTIONS (has_ret_val);
+ const char *message = "% declared here";
+ if (TREE_CODE (has_ret_val) == OVERLOAD)
+   {
+ has_ret_val = OVL_FIRST (has_ret_val);
+ message = "% first declared here";
+   }
+ inform (DECL_SOURCE_LOCATION (has_ret_val), message);
  coro_info->coro_co_return_error_emitted = true;
  return false;
}
diff --git a/gcc/testsuite/g++.dg/coroutines/pr105301.C 
b/gcc/testsuite/g++.dg/coroutines/pr105301.C
new file mode 100644
index 000..33a0b03cf5d
--- /dev/null
+++ b/gcc/testsuite/g++.dg/coroutines/pr105301.C
@@ -0,0 +1,49 @@
+// { dg-additional-options "-fsyntax-only" }
+namespace std {
+template 
+struct traits_sfinae_base {};
+
+template 
+struct coroutine_traits : public traits_sfinae_base {};
+}
+
+template struct coro {};
+template 
+struct std::coroutine_traits, Ps...> {
+  using promise_type = Promise;
+};
+
+struct awaitable {
+  bool await_ready() noexcept;
+  template 
+  void await_suspend(F) noexcept;
+  void await_resume() noexcept;
+} a;
+
+struct suspend_always {
+  bool await_ready() noexcept { return false; }
+  template 
+  void await_suspend(F) noexcept;
+  void await_resume() noexcept {}
+};
+
+namespace std {
+template 
+struct coroutine_handle {};
+}
+
+struct bad_promise_6 {
+  coro get_return_object();
+  suspend_always initial_suspend();
+  suspend_always final_suspend() noexcept;
+  void unhandled_exception();
+  void return_void();
+  void return_value(int) const;
+  void return_value(int);
+};
+
+coro
+bad_implicit_return() // { dg-error {.aka 'bad_promise_6'. declares both 
'return_value' and 'return_void'} }
+{
+  co_await a;
+}
-- 
2.24.3 (Apple Git-128)



[PATCH] c++, coroutines: Improve check for throwing final await [PR104051].

2022-04-18 Thread Iain Sandoe via Gcc-patches
We check that the final_suspend () method returns a sane type (i.e. a class
or structure) but, unfortunately, that check has to be later than the one
for a throwing case.  If the user returns some nonsensical type from the
method, we need to handle that in the checking for noexcept.

tested on x86_64-darwin, OK for mainline? (when?),
thanks
Iain

Signed-off-by: Iain Sandoe 

PR c++/104051

gcc/cp/ChangeLog:

* coroutines.cc (coro_diagnose_throwing_final_aw_expr): Handle
non-target expression inputs.

gcc/testsuite/ChangeLog:

* g++.dg/coroutines/pr104051.C: New test.
---
 gcc/cp/coroutines.cc   | 13 +-
 gcc/testsuite/g++.dg/coroutines/pr104051.C | 29 ++
 2 files changed, 36 insertions(+), 6 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/coroutines/pr104051.C

diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
index d2a765cac11..cb9bbed51e6 100644
--- a/gcc/cp/coroutines.cc
+++ b/gcc/cp/coroutines.cc
@@ -883,13 +883,14 @@ coro_diagnose_throwing_fn (tree fndecl)
 static bool
 coro_diagnose_throwing_final_aw_expr (tree expr)
 {
-  tree t = TARGET_EXPR_INITIAL (expr);
+  if (TREE_CODE (expr) == TARGET_EXPR)
+expr = TARGET_EXPR_INITIAL (expr);
   tree fn = NULL_TREE;
-  if (TREE_CODE (t) == CALL_EXPR)
-fn = CALL_EXPR_FN(t);
-  else if (TREE_CODE (t) == AGGR_INIT_EXPR)
-fn = AGGR_INIT_EXPR_FN (t);
-  else if (TREE_CODE (t) == CONSTRUCTOR)
+  if (TREE_CODE (expr) == CALL_EXPR)
+fn = CALL_EXPR_FN (expr);
+  else if (TREE_CODE (expr) == AGGR_INIT_EXPR)
+fn = AGGR_INIT_EXPR_FN (expr);
+  else if (TREE_CODE (expr) == CONSTRUCTOR)
 return false;
   else
 {
diff --git a/gcc/testsuite/g++.dg/coroutines/pr104051.C 
b/gcc/testsuite/g++.dg/coroutines/pr104051.C
new file mode 100644
index 000..ce7ae55405a
--- /dev/null
+++ b/gcc/testsuite/g++.dg/coroutines/pr104051.C
@@ -0,0 +1,29 @@
+// { dg-additional-options "-fsyntax-only" }
+#include 
+#include 
+template  struct promise {
+  struct final_awaitable {
+bool await_ready() noexcept;
+template 
+std::coroutine_handle<>
+await_suspend(std::coroutine_handle) noexcept;
+void await_resume() noexcept;
+  };
+  auto get_return_object() {
+return std::coroutine_handle::from_promise(*this);
+  }
+  auto initial_suspend() { return std::suspend_always(); }
+  auto final_suspend() noexcept { return true; }
+  void unhandled_exception();
+};
+template  struct task {
+  using promise_type = promise;
+  task(std::coroutine_handle>);
+  bool await_ready();
+  std::coroutine_handle<> await_suspend(std::coroutine_handle<>);
+  T await_resume();
+};
+task> foo() { // { dg-error {awaitable type 'bool' is not a 
structure} }
+  while ((co_await foo()).empty())
+;
+}
-- 
2.24.3 (Apple Git-128)



[pushed] LRA, rs6000, Darwin: Amend lo_sum use for forced constants [PR104117].

2022-02-11 Thread Iain Sandoe via Gcc-patches
Two issues resulted in this PR, which manifests when we force a constant into
memory in LRA (in PIC code on Darwin).  The presence of such forced constants
is quite dependent on other RTL optimisations, and it is easy for the issue to
become latent for a specific case.

First, in the Darwin-specific rs6000 backend code, we were not being careful
enough in rejecting invalid symbolic addresses.  Specifically, when generating
PIC code, we require a SYMBOL_REF to be wrapped in an UNSPEC_MACHOPIC_OFFSET.

Second, LRA was attempting to load a register using an invalid lo_sum address.

The LRA changes are approved in the PR by Vladimir, and the RS6000 changes are
Darwin-specific (although, of course, any observations are welcome).

Tested on several lo_sum targets and x86_64 all languages except as noted:
powerpc64-linux (m32/m64) -D
powerpc64le-linux  -D
powerpc64-aix -Ada -Go -D
aarch64-linux -Ada -D
x86_64-linux all langs -D
powerpc-darwin9 (master and 11.2) -D -Go.

pushed to master, thanks,
Iain

Signed-off-by: Iain Sandoe 
Co-authored-by: Vladimir Makarov 

PR target/104117

gcc/ChangeLog:

* config/rs6000/rs6000.cc (darwin_rs6000_legitimate_lo_sum_const_p):
Check for UNSPEC_MACHOPIC_OFFSET wrappers on symbolic addresses when
emitting PIC code.
(legitimate_lo_sum_address_p): Likewise.
* lra-constraints.cc (process_address_1): Do not attempt to emit a reg
load from an invalid lo_sum address.
---
 gcc/config/rs6000/rs6000.cc | 38 +++--
 gcc/lra-constraints.cc  | 17 ++---
 2 files changed, 38 insertions(+), 17 deletions(-)

diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc
index eaba9a2d698..bc3ef0721a4 100644
--- a/gcc/config/rs6000/rs6000.cc
+++ b/gcc/config/rs6000/rs6000.cc
@@ -8317,8 +8317,14 @@ darwin_rs6000_legitimate_lo_sum_const_p (rtx x, 
machine_mode mode)
   if (GET_CODE (x) == CONST)
 x = XEXP (x, 0);
 
+  /* If we are building PIC code, then any symbol must be wrapped in an
+ UNSPEC_MACHOPIC_OFFSET so that it will get the picbase subtracted.  */
+  bool machopic_offs_p = false;
   if (GET_CODE (x) == UNSPEC && XINT (x, 1) == UNSPEC_MACHOPIC_OFFSET)
-x =  XVECEXP (x, 0, 0);
+{
+  x =  XVECEXP (x, 0, 0);
+  machopic_offs_p = true;
+}
 
   rtx sym = NULL_RTX;
   unsigned HOST_WIDE_INT offset = 0;
@@ -8349,6 +8355,9 @@ darwin_rs6000_legitimate_lo_sum_const_p (rtx x, 
machine_mode mode)
   if (sym)
 {
   tree decl = SYMBOL_REF_DECL (sym);
+  /* As noted above, PIC code cannot use a bare SYMBOL_REF.  */
+  if (TARGET_MACHO && flag_pic && !machopic_offs_p)
+   return false;
 #if TARGET_MACHO
   if (MACHO_SYMBOL_INDIRECTION_P (sym))
   /* The decl in an indirection symbol is the original one, which might
@@ -8936,7 +8945,7 @@ legitimate_lo_sum_address_p (machine_mode mode, rtx x, 
int strict)
 return false;
   x = XEXP (x, 1);
 
-  if (TARGET_ELF || TARGET_MACHO)
+  if (TARGET_ELF)
 {
   bool large_toc_ok;
 
@@ -8962,7 +8971,32 @@ legitimate_lo_sum_address_p (machine_mode mode, rtx x, 
int strict)
 
   return CONSTANT_P (x) || large_toc_ok;
 }
+  else if (TARGET_MACHO)
+{
+  if (GET_MODE_NUNITS (mode) != 1)
+   return false;
+  if (GET_MODE_SIZE (mode) > UNITS_PER_WORD
+ && !(/* see above  */
+  TARGET_HARD_FLOAT && (mode == DFmode || mode == DDmode)))
+   return false;
+#if TARGET_MACHO
+  if (MACHO_DYNAMIC_NO_PIC_P || !flag_pic)
+   return CONSTANT_P (x);
+#endif
+  /* Macho-O PIC code from here.  */
+  if (GET_CODE (x) == CONST)
+   x = XEXP (x, 0);
+
+  /* SYMBOL_REFs need to be wrapped in an UNSPEC_MACHOPIC_OFFSET.  */
+  if (SYMBOL_REF_P (x))
+   return false;
 
+  /* So this is OK if the wrapped object is const.  */
+  if (GET_CODE (x) == UNSPEC
+ && XINT (x, 1) == UNSPEC_MACHOPIC_OFFSET)
+   return CONSTANT_P (XVECEXP (x, 0, 0));
+  return CONSTANT_P (x);
+}
   return false;
 }
 
diff --git a/gcc/lra-constraints.cc b/gcc/lra-constraints.cc
index fdff9e0720a..c700c3f4578 100644
--- a/gcc/lra-constraints.cc
+++ b/gcc/lra-constraints.cc
@@ -3625,21 +3625,8 @@ process_address_1 (int nop, bool check_only_p,
  *ad.inner = gen_rtx_LO_SUM (Pmode, new_reg, addr);
  if (!valid_address_p (op, &ad, cn))
{
- /* Try to put lo_sum into register.  */
- insn = emit_insn (gen_rtx_SET
-   (new_reg,
-gen_rtx_LO_SUM (Pmode, new_reg, 
addr)));
- code = recog_memoized (insn);
- if (code >= 0)
-   {
- *ad.inner = new_reg;
- if (!valid_address_p (op, &ad, cn))
-   {
- *ad.inner = addr;
-  

[PATCH] DWARF: Match behaviour of .cfi_xxx when doing manual frame output.

2021-11-17 Thread Iain Sandoe via Gcc-patches
At present, for several reasons, it is not possible to switch
Darwin to use .cfi instructions for frame output.

When GCC uses .cfi_ instructions, the behaviour w.r.t frame
sections (for a target with unwind frames by defaults):

(no options ) .eh_frame
(-g ) .eh_frame
(-g -fno-unwind-tables -fno-asynchronous-unwind-tables) .debug_frame
(   -fno-unwind-tables -fno-asynchronous-unwind-tables) ---

However, for a target which outputs the FDEs "manually" (using
output_call_frame_info()) we have:

(no options ) __eh_frame
(-g ) __eh_frame *and* __debug_frame
(-g -fno-unwind-tables -fno-asynchronous-unwind-tables) __debug_frame
(   -fno-unwind-tables -fno-asynchronous-unwind-tables) ---

The first two cases are, of course, the most common and the extra
frame table is (a) a waste of space and (b) actually triggers a bug
when used with the LLVM assembler [with assertions enabled] for
Mach-O when we have hot/cold partitioning on, since that emits
Letext{.cold}0 labels *after* the __DWARF,__debug_frame and the
assembler is set up reject switches to non-debug sections after the
first __DWARF debug one has been seen.

The following patch makes the manual output of frame data follow the
same pattern as the .cfi instructions.

(a) From testing on Darwin which uses the 'manual frame output' I see
around 200Mb saving on gcc/ for master (5%).
(b) Since Darwin defaults to unwind frames for all languages, we see
only eh_frame sections before the "real debug" is emitted, so that
the LLVM constraint is avoided.

On testing on x86_64 and powerpc64le Linux, I see only a single test
that would need amendment (it counts the number of references to the
start/end local labels).

Since the majority of targets are using .cfi instructions, it is hard
to get wider testing.

It would be possible, of course, to wrap the change in a target hook
but it's not clear that we need to.

Is there some case that I've missed?
or - OK for master (the testcase amendments are not attached here)
but are simple.

thanks,
Iain

Signed-off-by: Iain Sandoe 

gcc/ChangeLog:

* dwarf2out.c (output_call_frame_info): Output the FDEs when
either EH or debug support is needed.
(dwarf2out_frame_finish): When either EH or debug support is
needed, call output_call_frame_info().
---
 gcc/dwarf2out.c | 15 ++-
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index e1d6a79ecd7..96307d6747a 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -283,7 +283,7 @@ static GTY(()) dw_die_ref decltype_auto_die;
 
 /* Forward declarations for functions defined in this file.  */
 
-static void output_call_frame_info (int);
+static void output_call_frame_info (bool, bool);
 
 /* Personality decl of current unit.  Used only when assembler does not support
personality CFI.  */
@@ -750,7 +750,7 @@ fde_needed_for_eh_p (dw_fde_ref fde)
location of saved registers.  */
 
 static void
-output_call_frame_info (int for_eh)
+output_call_frame_info (bool for_eh, bool for_debug)
 {
   unsigned int i;
   dw_fde_ref fde;
@@ -795,7 +795,7 @@ output_call_frame_info (int for_eh)
targetm.asm_out.emit_unwind_label (asm_out_file, fde->decl, 1, 1);
}
 
-  if (!any_eh_needed)
+  if (!any_eh_needed && !for_debug)
return;
 }
 
@@ -1271,12 +1271,9 @@ void
 dwarf2out_frame_finish (void)
 {
   /* Output call frame information.  */
-  if (targetm.debug_unwind_info () == UI_DWARF2)
-output_call_frame_info (0);
-
-  /* Output another copy for the unwinder.  */
-  if (do_eh_frame)
-output_call_frame_info (1);
+  if (targetm.debug_unwind_info () == UI_DWARF2 || do_eh_frame)
+output_call_frame_info (do_eh_frame,
+   targetm.debug_unwind_info () == UI_DWARF2);
 }
 
 static void var_location_switch_text_section (void);
-- 
2.24.3 (Apple Git-128)



[PATCH 1/4] Driver : Provide a spec to insert rpaths for compiler lib dirs.

2021-11-17 Thread Iain Sandoe via Gcc-patches
This provides a spec to insert "-rpath DDD" for each DDD corresponding
to a compiler startfile directory.  This allows a target to use @rpath
as the install path for libraries, and have the compiler provide the
necessary rpath to handle this.

gcc/ChangeLog:

* gcc.c (RUNPATH_OPTION): New.
(do_spec_1): Provide '%P' as a spec to insert rpaths for
each compiler startfile path.
---
 gcc/gcc.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/gcc/gcc.c b/gcc/gcc.c
index 506c2acc282..7b52d0bcbfd 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -572,6 +572,7 @@ or with constant text in a single argument.
  %l process LINK_SPEC as a spec.
  %L process LIB_SPEC as a spec.
  %M Output multilib_os_dir.
+ %POutput a RUNPATH_OPTION for each directory in startfile_prefixes.
  %G process LIBGCC_SPEC as a spec.
  %R Output the concatenation of target_system_root and
 target_sysroot_suffix.
@@ -1191,6 +1192,10 @@ proper position among the other output files.  */
 # define SYSROOT_HEADERS_SUFFIX_SPEC ""
 #endif
 
+#ifndef RUNPATH_OPTION
+# define RUNPATH_OPTION "-rpath"
+#endif
+
 static const char *asm_debug = ASM_DEBUG_SPEC;
 static const char *asm_debug_option = ASM_DEBUG_OPTION_SPEC;
 static const char *cpp_spec = CPP_SPEC;
@@ -6130,6 +6135,19 @@ do_spec_1 (const char *spec, int inswitch, const char 
*soft_matched_part)
}
break;
 
+ case 'P':
+   {
+ struct spec_path_info info;
+
+ info.option = RUNPATH_OPTION;
+ info.append_len = 0;
+ info.omit_relative = false;
+ info.separate_options = true;
+
+ for_each_path (&startfile_prefixes, true, 0, spec_path, &info);
+   }
+   break;
+
  case 'e':
/* %efoo means report an error with `foo' as error message
   and don't execute any more commands for this file.  */
-- 
2.24.3 (Apple Git-128)



[PATCH 2/4] Darwin : Handle rpaths given on the command line.

2021-11-17 Thread Iain Sandoe via Gcc-patches
We want to produce a situation where a default rpath can be added
to each executable (or dylib), but that can be overridden by any
specific rpath provided by the user.

gcc/ChangeLog:

* config.gcc: Include rpath.opt
* config/darwin-driver.c (darwin_driver_init): Detect cases
where the user has added rpaths via a -Wl or -Xlinker command
and suppress default rpaths in that case.
* config/darwin.h (DRIVER_SELF_SPECS): Handle -rpath.
(DARWIN_RPATH_SPEC): New.
* config/darwin.opt: Add nodefaultrpath option.
---
 gcc/config/darwin-driver.c | 18 ++
 gcc/config/darwin.h| 11 ++-
 gcc/config/darwin.opt  |  4 
 3 files changed, 32 insertions(+), 1 deletion(-)

diff --git a/gcc/config/darwin-driver.c b/gcc/config/darwin-driver.c
index 4f0c6bad61f..ccc288f20ce 100644
--- a/gcc/config/darwin-driver.c
+++ b/gcc/config/darwin-driver.c
@@ -281,6 +281,7 @@ darwin_driver_init (unsigned int *decoded_options_count,
   const char *vers_string = NULL;
   bool seen_version_min = false;
   bool seen_sysroot_p = false;
+  bool seen_rpath_p = false;
 
   for (i = 1; i < *decoded_options_count; i++)
 {
@@ -349,6 +350,13 @@ darwin_driver_init (unsigned int *decoded_options_count,
  seen_sysroot_p = true;
  break;
 
+   case OPT_Xlinker:
+   case OPT_Wl_:
+ gcc_checking_assert ((*decoded_options)[i].arg);
+ if (strncmp ((*decoded_options)[i].arg, "-rpath", 6) == 0)
+   seen_rpath_p = true;
+ break;
+
default:
  break;
}
@@ -474,4 +482,14 @@ darwin_driver_init (unsigned int *decoded_options_count,
  &(*decoded_options)[*decoded_options_count - 1]);
 }
 }
+
+  if (seen_rpath_p)
+{
+  ++*decoded_options_count;
+  *decoded_options = XRESIZEVEC (struct cl_decoded_option,
+*decoded_options,
+*decoded_options_count);
+  generate_option (OPT_nodefaultrpath, NULL, 1, CL_DRIVER,
+  &(*decoded_options)[*decoded_options_count - 1]);
+}
 }
diff --git a/gcc/config/darwin.h b/gcc/config/darwin.h
index 7ed01efa694..4423933890b 100644
--- a/gcc/config/darwin.h
+++ b/gcc/config/darwin.h
@@ -384,6 +384,7 @@ extern GTY(()) int darwin_ms_struct;
 DARWIN_NOPIE_SPEC \
 DARWIN_RDYNAMIC \
 DARWIN_NOCOMPACT_UNWIND \
+"%{!r:%{!nostdlib:%{!rpath:%{!nodefaultrpath:%(darwin_rpaths) " \
 "}}} % 10.5 mmacosx-version-min= -lcrt1.o)\
@@ -542,6 +544,13 @@ extern GTY(()) int darwin_ms_struct;
 "%{!static:%:version-compare(< 10.6 mmacosx-version-min= -lbundle1.o)  \
   %{fgnu-tm: -lcrttms.o}}"
 
+/* A default rpath, that picks up dependent libraries installed in the same 
+   director as one being loaded.  */
+#define DARWIN_RPATH_SPEC \
+  "%:version-compare(>= 10.5 mmacosx-version-min= -rpath) \
+   %:version-compare(>= 10.5 mmacosx-version-min= @loader_path) \
+   %P "
+
 #ifdef HAVE_AS_MMACOSX_VERSION_MIN_OPTION
 /* Emit macosx version (but only major).  */
 #define ASM_MMACOSX_VERSION_MIN_SPEC \
diff --git a/gcc/config/darwin.opt b/gcc/config/darwin.opt
index d1d1f816912..021d67b17c7 100644
--- a/gcc/config/darwin.opt
+++ b/gcc/config/darwin.opt
@@ -233,6 +233,10 @@ no_dead_strip_inits_and_terms
 Driver RejectNegative
 (Obsolete) Current linkers never dead-strip these items, so the option is not 
needed.
 
+nodefaultrpath
+Driver RejectNegative
+Do not add a default rpath to executables, modules or dynamic libraries.
+
 nofixprebinding
 Driver RejectNegative
 (Obsolete after 10.3.9) Set MH_NOPREFIXBINDING, in an executable.
-- 
2.24.3 (Apple Git-128)



[PATCH 4/4] Darwin, Ada : Add loader path as a default rpath.

2021-11-17 Thread Iain Sandoe via Gcc-patches
Allow the Ada runtimes to find GCC runtimes relative to their non-
standard install positions.

gcc/ada/
* gcc-interface/Makefile.in: Add @loader_path runpaths to the
libgnat and libgnarl shared library builds.

---
 gcc/ada/gcc-interface/Makefile.in | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/gcc/ada/gcc-interface/Makefile.in 
b/gcc/ada/gcc-interface/Makefile.in
index 53d0739470a..bffe9de4c89 100644
--- a/gcc/ada/gcc-interface/Makefile.in
+++ b/gcc/ada/gcc-interface/Makefile.in
@@ -788,6 +788,7 @@ gnatlib-shared-darwin:
$(GNATRTL_NONTASKING_OBJS) $(LIBGNAT_OBJS) \
$(SO_OPTS) \

-Wl,-install_name,@rpath/libgnat$(hyphen)$(LIBRARY_VERSION)$(soext) \
+   -Wl,-rpath,@loader_path \
$(MISCLIB)
cd $(RTSDIR); `echo "$(GCC_FOR_TARGET)" \
 | sed -e 's,\./xgcc,../../xgcc,' -e 's,-B\./,-B../../,'` 
-dynamiclib $(PICFLAG_FOR_TARGET) \
@@ -795,6 +796,7 @@ gnatlib-shared-darwin:
$(GNATRTL_TASKING_OBJS) \
$(SO_OPTS) \

-Wl,-install_name,@rpath/libgnarl$(hyphen)$(LIBRARY_VERSION)$(soext) \
+   -Wl,-rpath,@loader_path \
$(THREADSLIB) -Wl,libgnat$(hyphen)$(LIBRARY_VERSION)$(soext)
cd $(RTSDIR); $(LN_S) libgnat$(hyphen)$(LIBRARY_VERSION)$(soext) \
libgnat$(soext)
-- 
2.24.3 (Apple Git-128)



[PATCH 0/4] Darwin: Replace environment runpath with embedded [PR88590].

2021-11-17 Thread Iain Sandoe via Gcc-patches
This is a fairly long explanation of the problems being addressed by
the patch set.  Most of the changes are Darwin-specific - a change to
the libtool component allowing for this @rpath and some minor additions
to makefiles where libtool is not in use.  At present, this seems pretty
specific to the GCC build; since we depend on accessing newly-built
components during the bootstrap.

There are additional details relevant to each patch in its own commit
message.

=

Darwin builds shared libraries with information on the runpath as part
of the library name.  For example, /installation/path/for/libfoo.dylib.

That is regarded as two components; the 'runpath' /installation/path/for/
and the library name libfoo.dylib.

This means that (at runtime) two libraries with the same name can be
disambiguated by their runpaths, and potentially used by the same exe.

= Problem #1

That is fine and works well; until we disturb the assumptions by
overriding the library runpath with an environment one: DYLD_LIBRARY_PATH.

Now the library runpath(s) can be discarded and the libraries are first
searched on the basis of that provided by the environment; two libraries
with the same name are no longer distinct (if a library with that name is
found in the environment path).

This causes problems in configuring, building and testing GCC because we
set the runpath environment at a very high level so that it applies to
stage1+ target configures and stage2+ host configures.  This is needed so
that executables built during those configures get the newly-built libgcc_s
when the target defaults to using a shared libgcc.

However, it also means that every tool that is used during the configure
has its libgcc_s (or any of the newly-built bootstrapped libs) overriden
to use the new one(s) - which might be buggy.

In the testsuite it is more serious - since more target libs come into
play - especially libstdc++.  Several system tools on Darwin use(d) libc++
and that has caused wrong or crashed test output.  In principle,
LD_LIBRARY_PATH on Linux has the same issue - although perhaps there is
less tendency to default to use of shared dependent libs.

Ideally, one would have several environment paths, and some way to use
the appropriate one at the appropriate time.  I experimented with this
as a solution to both this and the following problem, but it proved
unrealistic - since the process would have to be applied to all relevant
OSS projects using auto-tools to be safe - and mostly the uninstalled
use of libraries is a GCC build-time issue.

= Problem #2

A change in security policy for Darwin means that DYLD_LIBRARY_PATH is
now removed from the environment for all system tools (e.g. /usr/sh, env
etc).  This means that for all realistic build steps that use any system
utility (like sh) will no longer see the the environment runpath and the
only ones available will be those in the libraries.

This breaks GCC's configuration since the steps mentioned above are now
not seeing the newly-built shared libraries, but actually much olders ones
installed on the system.  It means that for all Darwin15+ we misconfigure
libstdc++.

/bin/sh is hardwired into autoconf, one cannot use CONFIG_SHELL to work
around this - because /bin/sh is invoked first, and then passes control to
CONFIG_SHELL.

A second problem is that we cannot bump the SO name for libgcc_s (which
I need to do to solve an EH problem) - since the new SO name is not
available on the system, and therefore none of the stage1+ target configures
will succeed.  This is because the eventual install path is correctly
encoded into the built library, but it is not present at the install
position (and, in general, cannot be installed - since that might not even
be a suitable path on the build system).

This has also meant that we could not do in-tree testing without first
installing the target libraries (which is mostly inconvenient rather than
a show-stopper, but still).

= Tested solution.

Darwin has the ability to make the runpaths install-position independent.

One sets the library runpath to @rpath/ which essentially means "use the
runpath available at the time we want to load this".

One can then add (potentially multiple) runpaths to the executable, the
built library can be put anywhere convenient - providing we can put that
path into the exe.

For GCC's build, test and install process this means that we need at each
stage to build exes with the runpaths that are relevant to the positions
of the dependent libraries.

To do this, we add an rpath for each of the startfile paths.  While we are
building/testing GCC these correspond to (for example gcc/  or 
/libstdc++/src/.libs etc) and then, after the compiler is installed
at its intended install path - these become /compiler/installation/path/lib
etc.

I have tested this widely on i686, powerpc, x86_64 and aarch64 Darwin over
more than a year.

So patch 1 : provides a spec that expands to -rpath xxx for each xxx in the
startfiles (

[PATCH 3/4] Darwin : Allow for configuring Darwin to use embedded runpath.

2021-11-17 Thread Iain Sandoe via Gcc-patches
Recent Darwin versions place contraints on the use of run paths
specified in environment variables.  This breaks some assumptions
in the GCC build.

This change allows the user to configure a Darwin build to use
'@rpath/libraryname.dylib' in library names and then to add an
embedded runpath to executables (and libraries with dependents).

The embedded runpath is added by default unless:

1. the user adds an explicit -rpath / -Wl,-rpath,
2. the user adds '-nodefaultrpath'.

For an installed compiler, it means that any executable built with
that compiler will reference the runtimes installed with the
compiler (equivalent to hard-coding the library path into the name
of the library).

During build-time configurations  any "-B" entries will be added to
the runpath thus the newly-built libraries will be found by exes.

Since the install name is set in libtool, that decision needs to be
available here (but might also cause dependent ones in Makefiles,
so we need to export a conditional).

This facility is not available for Darwin 8 or earlier, however the
existing environment variable runpath does work there.

We default this on for systems where the external DYLD_LIBRARY_PATH
does not work and off for Darwin 8 or earlier.  For systems that can
use either method, if the value is unset, we use the default (which
is currently DYLD_LIBRARY_PATH).

ChangeLog:

* configure: Regenerate.
* configure.ac: Do not add default runpaths to GCC exes
when we are building -static-libstdc++/-static-libgcc (the
default).
* libtool.m4: Add 'enable-darwin-at-runpath'.  Act  on the
enable flag to alter Darwin libraries to use @rpath names.

gcc/ChangeLog:

* aclocal.m4: Regenerate.
* configure: Regenerate.

libatomic/ChangeLog:

* Makefile.am: Handle Darwin rpaths.
* Makefile.in: Regenerate.
* configure: Regenerate.
* testsuite/Makefile.in: Regenerate.

libcc1/ChangeLog:

* Makefile.am: Handle Darwin rpaths.
* Makefile.in: Regenerate.
* configure: Regenerate.

libffi/ChangeLog:

* Makefile.am: Handle Darwin rpaths.
* Makefile.in: Regenerate.
* configure: Regenerate.

libgcc/ChangeLog:

* config/t-slibgcc-darwin: Generate libgcc_s
with an @rpath name.

libgfortran/ChangeLog:

* Makefile.am: Handle Darwin rpaths.
* Makefile.in: Regenerate.
* configure: Regenerate.
* configure.ac: Handle Darwin rpaths

libgomp/ChangeLog:

* Makefile.am: Handle Darwin rpaths.
* Makefile.in: Regenerate.
* configure: Regenerate.

libhsail-rt/ChangeLog:

* configure: Regenerate.

libitm/ChangeLog:

* Makefile.am: Handle Darwin rpaths.
* Makefile.in: Regenerate.
* configure: Regenerate.

libobjc/ChangeLog:

* configure: Regenerate.
* configure.ac: Handle Darwin rpaths.

liboffloadmic/ChangeLog:

* configure: Regenerate.
* plugin/Makefile.in: Regenerate.
* plugin/aclocal.m4: Regenerate.
* plugin/configure: Regenerate.

libphobos/ChangeLog:

* configure: Regenerate.
* libdruntime/Makefile.am: Handle Darwin rpaths.
* libdruntime/Makefile.in: Regenerate.
* src/Makefile.am: Handle Darwin rpaths.
* src/Makefile.in: Regenerate.

libquadmath/ChangeLog:

* Makefile.am: Handle Darwin rpaths.
* Makefile.in: Regenerate.
* configure: Regenerate.
* configure.ac: Handle Darwin rpaths.

libsanitizer/ChangeLog:

* asan/Makefile.am: Handle Darwin rpaths.
* asan/Makefile.in: Regenerate.
* configure: Regenerate.
* hwasan/Makefile.am: Handle Darwin rpaths.
* hwasan/Makefile.in: Regenerate.
* lsan/Makefile.am: Handle Darwin rpaths.
* lsan/Makefile.in: Regenerate.
* tsan/Makefile.am: Handle Darwin rpaths.
* tsan/Makefile.in: Regenerate.
* ubsan/Makefile.am: Handle Darwin rpaths.
* ubsan/Makefile.in: Regenerate.

libssp/ChangeLog:

* Makefile.am: Handle Darwin rpaths.
* Makefile.in: Regenerate.
* configure: Regenerate.

libstdc++-v3/ChangeLog:

* configure: Regenerate.
* src/Makefile.am: Handle Darwin rpaths.
* src/Makefile.in: Regenerate.

Darwin, libtool : Provide a mechanism to enable embedded rpaths.

We need to be able to build libraries with install names that begin
with @rpath so that we can use rpaths in DSOs that depend on
them.  Since the install name is set in libtool, that decision needs
to be available here (but might also cause dependent ones in
Makefiles, so we need to export a conditional).
---
 configure |   5 +
 configure.ac  |   5 +
 gcc/aclocal.m4|  50 +++
 gcc/configure | 157 +++--
 libatomic/Makefile.am |   6 +-
 libatomic/Makefile.in 

Re: [PATCH 3/4] Darwin : Allow for configuring Darwin to use embedded runpath.

2021-11-17 Thread Iain Sandoe via Gcc-patches



> On 17 Nov 2021, at 22:50, Joseph Myers  wrote:
> 
> On Wed, 17 Nov 2021, Iain Sandoe via Gcc-patches wrote:
> 
>>  * libtool.m4: Add 'enable-darwin-at-runpath'.  Act  on the
>>  enable flag to alter Darwin libraries to use @rpath names.
> 
> To confirm: has this been sent to upstream libtool (which has recently 
> acquired a new maintainer, so hopefully might become a bit more active at 
> dealing with the backlog of patches)?

No. it has not
(a) I was not aware of the new maintainer
(b) the background problem does seem a pretty GCC-specific issue.

If we are going to try and reconcile GCC’s local libtool for more generic Darwin
use, then I fear that is going to take quite significant work over a period of 
time
(since it will need much more wide testing than GCC).

Having said that, it would be good to have a more up-to-date upstream libtool
the current source has a lot of ancient content - as with all things it’s just a
question of resources.   It’s unlikely to be on my radar in time for GCC12.

Iain



Re: [PATCH] darwin, d: Support outfile substitution for liphobos

2021-11-19 Thread Iain Sandoe via Gcc-patches
Hi Iain

> On 19 Nov 2021, at 08:32, Iain Buclaw  wrote:

> This patch fixes a stage2 bootstrap failure in the D front-end on
> darwin due to libgphobos being dynamically linked despite
> -static-libphobos being on the command line.
> 
> In the gdc driver, this takes the previous fix for the Darwin D
> bootstrap, and extends it to the -static-libphobos option as well.
> Rather than pushing the -static-libphobos option back onto the command
> line, the setting of SKIPOPT is instead conditionally removed.  The same
> change has been repeated for -static-libstdc++ so there is now no need
> to call generate_option to re-add it.
> 
> In the gcc driver, -static-libphobos has been added as a common option,
> validated, and a new outfile substition added to config/darwin.h to
> correctly replace -lgphobos with libgphobos.a.
> 
> Bootstrapped and regression tested on x86_64-linux-gnu and
> x86_64-apple-darwin20.
> 
> OK for mainline?  This would also be fine for gcc-11 release branch too,
> as well as earlier releases with D support.

the Darwin parts are fine, thanks 

The SKIPOPT in d-spec, presumably means “skip removing this opt”?
otherwise the #ifndef looks odd (because of the static-libgcc|static-libphobos,
darwin.h would do the substitution for -static-libgcc as well, so it’s not a 
100%
test).

Iain

> 
> Regards,
> Iain.
> 
> ---
> gcc/ChangeLog:
> 
>   * common.opt (static-libphobos): Add option.
>   * config/darwin.h (LINK_SPEC): Substitute -lgphobos with libgphobos.a
>   when linking statically.
>   * gcc.c (driver_handle_option): Set -static-libphobos as always valid.
> 
> gcc/d/ChangeLog:
> 
>   * d-spec.cc (lang_specific_driver): Set SKIPOPT on -static-libstdc++
>   and -static-libphobos only when target supports LD_STATIC_DYNAMIC.
>   Remove generate_option to re-add -static-libstdc++.
> ---
> gcc/common.opt  |  4 
> gcc/config/darwin.h |  1 +
> gcc/d/d-spec.cc | 18 +++---
> gcc/gcc.c   |  6 --
> 4 files changed, 20 insertions(+), 9 deletions(-)
> 
> diff --git a/gcc/common.opt b/gcc/common.opt
> index db6010e4e20..73c12d933f3 100644
> --- a/gcc/common.opt
> +++ b/gcc/common.opt
> @@ -3527,6 +3527,10 @@ static-libgfortran
> Driver
> ; Documented for Fortran, but always accepted by driver.
> 
> +static-libphobos
> +Driver
> +; Documented for D, but always accepted by driver.
> +
> static-libstdc++
> Driver
> 
> diff --git a/gcc/config/darwin.h b/gcc/config/darwin.h
> index 7ed01efa694..c4ddd623e8b 100644
> --- a/gcc/config/darwin.h
> +++ b/gcc/config/darwin.h
> @@ -443,6 +443,7 @@ extern GTY(()) int darwin_ms_struct;
>  %:replace-outfile(-lobjc libobjc-gnu.a%s); \
> :%:replace-outfile(-lobjc -lobjc-gnu )}}\
>%{static|static-libgcc|static-libgfortran:%:replace-outfile(-lgfortran 
> libgfortran.a%s)}\
> +   %{static|static-libgcc|static-libphobos:%:replace-outfile(-lgphobos 
> libgphobos.a%s)}\
>
> %{static|static-libgcc|static-libstdc++|static-libgfortran:%:replace-outfile(-lgomp
>  libgomp.a%s)}\
>%{static|static-libgcc|static-libstdc++:%:replace-outfile(-lstdc++ 
> libstdc++.a%s)}\
>%{force_cpusubtype_ALL:-arch %(darwin_arch)} \
> diff --git a/gcc/d/d-spec.cc b/gcc/d/d-spec.cc
> index b12d28f1047..73ecac3bbf1 100644
> --- a/gcc/d/d-spec.cc
> +++ b/gcc/d/d-spec.cc
> @@ -253,13 +253,23 @@ lang_specific_driver (cl_decoded_option 
> **in_decoded_options,
> 
>   case OPT_static_libstdc__:
> saw_static_libcxx = true;
> +#ifndef HAVE_LD_STATIC_DYNAMIC
> +   /* Remove -static-libstdc++ from the command only if target supports
> +  LD_STATIC_DYNAMIC.  When not supported, it is left in so that a
> +  back-end target can use outfile substitution.  */
> args[i] |= SKIPOPT;
> +#endif
> break;
> 
>   case OPT_static_libphobos:
> if (phobos_library != PHOBOS_NOLINK)
>   phobos_library = PHOBOS_STATIC;
> +#ifndef HAVE_LD_STATIC_DYNAMIC
> +   /* Remove -static-libphobos from the command only if target supports
> +  LD_STATIC_DYNAMIC.  When not supported, it is left in so that a
> +  back-end target can use outfile substitution.  */
> args[i] |= SKIPOPT;
> +#endif
> break;
> 
>   case OPT_shared_libphobos:
> @@ -460,7 +470,7 @@ lang_specific_driver (cl_decoded_option 
> **in_decoded_options,
> #endif
> }
> 
> -  if (saw_libcxx || need_stdcxx)
> +  if (saw_libcxx || saw_static_libcxx || need_stdcxx)
> {
> #ifdef HAVE_LD_STATIC_DYNAMIC
>   if (saw_static_libcxx && !static_link)
> @@ -468,12 +478,6 @@ lang_specific_driver (cl_decoded_option 
> **in_decoded_options,
> generate_option (OPT_Wl_, LD_STATIC_OPTION, 1, CL_DRIVER,
>  &new_decoded_options[j++]);
>   }
> -#else
> -  /* Push the -static-libstdc++ option back onto the command so that
> -  a target without LD_STATIC_DYNAMIC can use outfile substitution.  */
> -  if (saw_static_libcx

[PATCH] libphobos, testsuite: Add prune clauses for two Darwin cases.

2021-11-19 Thread Iain Sandoe via Gcc-patches
Depending on the permutation of CPU, OS version and shared/non-
shared library inclusion, we get can get two warnings from the
external tools (ld64, dsymutil) which are not actually GCC issues
but relate to the external tools.  These are already pruned in
the main testsuite, this adds them to the library.

tested on x86_64,i686-darwin17 where the problem shows up.
OK for master / backports?
thanks
Iain

Signed-off-by: Iain Sandoe 

libphobos/ChangeLog:

* testsuite/lib/libphobos.exp: Prune warnings from external
tool bugs.
---
 libphobos/testsuite/lib/libphobos.exp | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/libphobos/testsuite/lib/libphobos.exp 
b/libphobos/testsuite/lib/libphobos.exp
index 3be2092b12e..2af430a0e45 100644
--- a/libphobos/testsuite/lib/libphobos.exp
+++ b/libphobos/testsuite/lib/libphobos.exp
@@ -90,6 +90,13 @@ proc libphobos-dg-test { prog do_what extra_tool_flags } {
 }
 
 proc libphobos-dg-prune { system text } {
+
+# Ignore harmless warnings from Xcode.
+regsub -all "(^|\n)\[^\n\]*ld: warning: could not create compact unwind 
for\[^\n\]*" $text "" text
+
+# Ignore dsymutil warning (tool bug is actually linker)
+regsub -all "(^|\n)\[^\n\]*could not find object file symbol for 
symbol\[^\n\]*" $text "" text
+
 return $text
 }
 
-- 
2.24.3 (Apple Git-128)



[PATCH] libstdc++, testsuite: Add a prune expression for external tool bug.

2021-11-19 Thread Iain Sandoe via Gcc-patches
Depending on the permutation of CPU, OS version and shared/non-
shared library inclusion, we get can get warnings from the external
tools (ld64, dsymutil) which are not actually libstdc++ issues but
relate to the external tools themselves.  This is already pruned
in the main testsuite, this adds it to the library.

tested on x86_64, i686 darwin17 which is one of the platforms where
the issue shows.

OK for master? / eventual backports ?
thanks
Iain

Signed-off-by: Iain Sandoe 

libstdc++-v3/ChangeLog:

* testsuite/lib/prune.exp: Prune dsymutil (ld64) warning.
---
 libstdc++-v3/testsuite/lib/prune.exp | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/libstdc++-v3/testsuite/lib/prune.exp 
b/libstdc++-v3/testsuite/lib/prune.exp
index 334f8218d16..41c4b51cb16 100644
--- a/libstdc++-v3/testsuite/lib/prune.exp
+++ b/libstdc++-v3/testsuite/lib/prune.exp
@@ -66,9 +66,12 @@ proc libstdc++-dg-prune { system text } {
 regsub -all "(^|\n)\[^\n\]*warning: 
DWARFDebugInfoEntry::AppendDependants\[^\n\]*AT_\[^\n\]*_bound\[^\n\]*FORM_ref4\[^\n\]*"
 $text "" text
 regsub -all "(^|\n)\[^\n\]*warning:\[^\n\]*TAG_variable:  
AT_location\[^\n\]*didn't have valid function low pc\[^\n\]*" $text "" text
 
-# Ignore harmless warnings from Xcode 4.0.
+# Ignore harmless warnings from Xcode 4+.
 regsub -all "(^|\n)\[^\n\]*ld: warning: could not create compact unwind 
for\[^\n\]*" $text "" text
 
+# Ignore dsymutil warning (tool bug is actually in the linker)
+regsub -all "(^|\n)\[^\n\]*could not find object file symbol for 
symbol\[^\n\]*" $text "" text
+
 foreach p $additional_prunes {
if { [string length $p] > 0 } {
# Following regexp matches a complete line containing $p.
-- 
2.24.3 (Apple Git-128)



[PATCH] gcc, doc: Fix Darwin bootstrap: Amend an @option command to elide a space.

2021-11-19 Thread Iain Sandoe via Gcc-patches
At least some version(s) of makeinfo (4.8) do not like @option {-}
the brace has to follow the @option without any whitespace.

makeinfo 4.8 is installed on Darwin systems and this breaks bootstrap.
The amendment follows the style of the surrounding code.

tested on Darwin9, 18, 19, 20, 21, pushed to master as trivial/bootstrap
fix, thanks
Iain

Signed-off-by: Iain Sandoe 

gcc/ChangeLog:

* doc/invoke.texi: Remove whitespace after an @option.
---
 gcc/doc/invoke.texi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 1cfb70291f6..4b1b58318f0 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -10677,7 +10677,7 @@ valid for all standard-compliant programs.
 It turns on @option{-ffast-math}, @option{-fallow-store-data-races}
 and the Fortran-specific @option{-fstack-arrays}, unless
 @option{-fmax-stack-var-size} is specified, and @option{-fno-protect-parens}.
-It turns off @option {-fsemantic-interposition}.
+It turns off @option{-fsemantic-interposition}.
 
 @item -Og
 @opindex Og
-- 
2.24.3 (Apple Git-128)



[pushed] Darwin: Rework handling for unwinder code in libgcc_s and specs [PR80556].

2021-11-20 Thread Iain Sandoe via Gcc-patches
This addresses a long-standing problem where a work-around for an unwinder
issue (also a regression) regresses other functionality.  The patch replaces
several work-arounds with a fix for PR80556 and a work-around for PR88590.

* The fix for PR80556 requires a bump to the SO name for libgcc_s, since we
need to remove the unwinder symbols from it.  This would trigger PR88590
hence the work-around for that.

* We weaken the symbols for emulated TLS support so that it is possible
for a DSO linked with static-libgcc to interoperate with a DSO linked with
libgcc_s.  Likewise main exes.

* We remove all the gcc-4.2.1 era stubs machinery and workarounds.

* libgcc is always now linked ahead of libc, which avoids fails where the
libc (libSystem) builtins implementations are not up to date.

* The unwinder now always comes from the system
 - for Darwin9 from /usr/lib/libgcc_s.1.dylib
 - for Darwin10 from /usr/lib/libSystem.dylib
 - for Darwin11+ from /usr/lib/system/libunwind.dylib.
 
 We still insert a shim on Darwin10 to fix an omitted unwind function, but
 the underlying unwinder remains the system one.

* The work-around for PR88590 has two parts (1) we always link libgcc from
its convenience lib (avoiding the need to find the DSO path); (2) we add and
export the emutls functions from DSOs - this makes a relatively small (20k)
addition to a DSO.  These can be backed out when a proper fix for PR88590 is
committed.

For distributions that wish to install a libgcc_s.1.dylib to satisfy linkage
from exes that linked against the stubs can use a reexported libgcc_s.1.1
(since that contains all the symbols that were previously exported via the
 stubs).
 
Tested on *-darwin*, x86-64, powerpc64le-linux,
pushed to master, thanks
Iain

gcc/ChangeLog:

PR target/80556
* config/darwin.c (darwin_rename_builtins): Remove workaround.
* config/darwin.h (LINK_GCC_C_SEQUENCE_SPEC): Provide __eprintf via
libgcc for macOS <= 10.4. (REAL_LIBGCC_SPEC): Adjust for the revised
library naming.
* config/i386/darwin.h (REAL_LIBGCC_SPEC): Remove workaround.
* config/i386/darwin32-biarch.h (REAL_LIBGCC_SPEC): Likewise.
* config/i386/darwin64-biarch.h (REAL_LIBGCC_SPEC): Likewise.

libgcc/ChangeLog:

PR target/80556
* config.host: Adjust target fragments to omit the unwinder from
Darwin libgcc builds.  Add a weak emutls crt.
* config/i386/t-darwin: Add X86-specific libgcc symbols.
* config/t-darwin: Build a crat containing weak definitions for the
emuTLS routines.
* config/t-slibgcc-darwin: Bump SO version, remove all the handling
for stub libraries.
* emutls.c (EMUTLS_ATTR): New.
(__emutls_get_address): Allow a target to add a weak
attribute if provided.
(__emutls_register_common): Likewise.
* config/i386/libgcc-darwin.10.4.ver: Removed.
* config/i386/libgcc-darwin.10.5.ver: Removed.
* config/libgcc-libsystem.ver: Removed.
* config/rs6000/libgcc-darwin.10.4.ver: Removed.
* config/rs6000/libgcc-darwin.10.5.ver: Removed.
* config/i386/libgcc-darwin.ver: New file.
* config/t-darwin-noeh: New file.

gcc/testsuite/ChangeLog:

PR target/80556
* gcc.dg/torture/fp-int-convert-timode-3.c: Revert XFAIL.
* gcc.dg/torture/fp-int-convert-timode-4.c: Likewise.
---
 gcc/config/darwin-driver.c|  18 +++
 gcc/config/darwin.c   |  24 
 gcc/config/darwin.h   |  98 ++--
 gcc/config/darwin.opt |   4 +
 gcc/config/i386/darwin.h  |  31 -
 gcc/config/i386/darwin32-biarch.h |  13 ---
 gcc/config/i386/darwin64-biarch.h |  13 ---
 .../gcc.dg/torture/fp-int-convert-timode-3.c  |   1 -
 .../gcc.dg/torture/fp-int-convert-timode-4.c  |   1 -
 libgcc/config.host|   7 +-
 libgcc/config/i386/darwin-lib.h   |   9 --
 libgcc/config/i386/libgcc-darwin.10.4.ver |  98 
 libgcc/config/i386/libgcc-darwin.10.5.ver | 102 -
 libgcc/config/libgcc-libsystem.ver|  38 ++-
 libgcc/config/rs6000/libgcc-darwin.10.4.ver   |  93 ---
 libgcc/config/rs6000/libgcc-darwin.10.5.ver   | 106 --
 libgcc/config/t-darwin-noeh   |   4 +
 libgcc/config/t-slibgcc-darwin|  74 
 18 files changed, 153 insertions(+), 581 deletions(-)
 delete mode 100644 libgcc/config/i386/libgcc-darwin.10.4.ver
 delete mode 100644 libgcc/config/i386/libgcc-darwin.10.5.ver
 delete mode 100644 libgcc/config/rs6000/libgcc-darwin.10.4.ver
 delete mode 100644 libgcc/config/rs6000/libgcc-darwin.10.5.ver
 create mode 100644 libgcc/config/t-darwin-noeh

diff --git a/gcc/config/darwin-driver.c b/gcc/config/darwin-driver.c
index 4f0c6bad61f..7fa80abc314 100644
--- a/gcc/config/darwin-

[pushed] libitm: Fix bootstrap for targets without HAVE_ELF_STYLE_WEAKREF.

2021-11-26 Thread Iain Sandoe via Gcc-patches
Recent improvements to null address warnings notice that for
targets that do not support HAVE_ELF_STYLE_WEAKREF the dummy stub
implementation of __cxa_get_globals() means that the address can
never be null.

Fixed by removing the test for such targets.

tested on i686, x86_64, powerpc-darwin and x86_64-linux.
pushed to master as bootstrap/trivial fix, thanks
Iain

Signed-off-by: Iain Sandoe 

libitm/ChangeLog:

* eh_cpp.cc (GTM::gtm_thread::init_cpp_exceptions): If the
target does not support HAVE_ELF_STYLE_WEAKREF then do not
try to test the __cxa_get_globals against NULL.
---
 libitm/eh_cpp.cc | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/libitm/eh_cpp.cc b/libitm/eh_cpp.cc
index 4909427b405..57beb1a147f 100644
--- a/libitm/eh_cpp.cc
+++ b/libitm/eh_cpp.cc
@@ -178,7 +178,11 @@ GTM::gtm_thread::init_cpp_exceptions ()
 {
   // Only save and restore the number of uncaught exceptions if this is
   // actually used in the program.
-  if (__cxa_get_globals != NULL && __cxa_get_globals () != 0)
+  if (
+#if HAVE_ELF_STYLE_WEAKREF
+  __cxa_get_globals != NULL &&
+#endif
+  __cxa_get_globals () != 0)
 cxa_uncaught_count_ptr = &__cxa_get_globals ()->uncaughtExceptions;
   else
 cxa_uncaught_count_ptr = 0;
-- 
2.24.3 (Apple Git-128)



[pushed ] Darwin: Rewrite host PCH support [PR 55610].

2021-12-02 Thread Iain Sandoe via Gcc-patches
We need to revise the PCH memory allocation scheme to enable
support for PIE on aarch64.  The rewrite uses a similar scheme
to the one used on Linux.

We attempt to identify VM segments for each arch/OS version that
are always available to the compiler (note this is not general,
it only needs to work for the cc1* exes).

If we cannot find the preferred segment we fall back to allowing
the kernel to supply one - this is more likely to fail when the
PCH read-in occurs (but that is trapped).

In doing this we obviate the need to unmap any part of the
compiler __DATA segment - thus fixing PR 55610.

Notes:

For 64bit hosts there is quite a large portion of the VMA that is
apparently unused in current OS versions.  We avoid the areas that
are already being mapped by the sanitizers.

For 32bit hosts the situation is not so easy - fortunately the
requirement here is not general (we do not need to find an unused
space for any arbitrary executable - only for the cases found in
the cc1* compilers - which have relatively few external library
DSO dependencies).

Initial experiments suggest that the 64Bit host choices are OK
for executables with ASLR enabled (PIE).  However, it is doubtful
whether a totally reliable choice can be found found for 32 bit
hosts and PIE executables would not be recommended there.

tested across the Darwin range over several iterations of master.
pushed to master, thanks
Iain

Signed-off-by: Iain Sandoe 

gcc/ChangeLog:

PR target/55610
* config/host-darwin.c (TRY_EMPTY_VM_SPACE,
SAFE_ALLOC_SIZE): New.
(darwin_gt_pch_get_address): Rewrite to use nominated
memory segments rather than part of the compiler __DATA
segment.
(darwin_gt_pch_use_address): Likewise.
---
 gcc/config/host-darwin.c | 191 +++
 1 file changed, 153 insertions(+), 38 deletions(-)

diff --git a/gcc/config/host-darwin.c b/gcc/config/host-darwin.c
index 14a01fe71f2..559b919f2ee 100644
--- a/gcc/config/host-darwin.c
+++ b/gcc/config/host-darwin.c
@@ -20,62 +20,177 @@
 #include "config.h"
 #include "system.h"
 #include "coretypes.h"
+#include "options.h"
 #include "diagnostic-core.h"
 #include "config/host-darwin.h"
-
-/* Yes, this is really supposed to work.  */
-/* This allows for a pagesize of 16384, which we have on Darwin20, but should
-   continue to work OK for pagesize 4096 which we have on earlier versions.
-   The size is 1 (binary) Gb.  */
-static char pch_address_space[65536*16384] __attribute__((aligned (16384)));
-
-/* Return the address of the PCH address space, if the PCH will fit in it.  */
+#include 
+
+/* For Darwin (macOS only) platforms, without ASLR (PIE) enabled on the
+   binaries, the following VM addresses are expected to be available.
+   NOTE, that for aarch64, ASLR is always enabled - but the VM address
+   mentioned below is available (at least on Darwin20).
+
+   The spaces should all have 512Mb available c.f. PCH files for large
+   C++ or Objective-C in the range of 150Mb for 64b hosts.
+
+   We also try to steer clear of places already used for sanitizers.  */
+
+#define PAGE_SZ 4096
+#if defined(__x86_64) && defined(__LP64__)
+# define TRY_EMPTY_VM_SPACE0x1800ULL
+# define SAFE_ALLOC_SIZE   0x2000
+#elif defined(__x86_64)
+# define TRY_EMPTY_VM_SPACE0x6fe0ULL
+# define SAFE_ALLOC_SIZE   0x2000
+#elif defined(__i386)
+# define TRY_EMPTY_VM_SPACE0x6fe0ULL
+# define SAFE_ALLOC_SIZE   0x2000
+#elif defined(__POWERPC__) && defined(__LP64__)
+# define TRY_EMPTY_VM_SPACE0x1800ULL
+# define SAFE_ALLOC_SIZE   0x2000
+#elif defined(__POWERPC__)
+# define TRY_EMPTY_VM_SPACE0x6fe0ULL
+# define SAFE_ALLOC_SIZE   0x2000
+#elif defined(__aarch64__)
+# undef PAGE_SZ
+# define PAGE_SZ 16384
+# define TRY_EMPTY_VM_SPACE0x1800ULL
+# define SAFE_ALLOC_SIZE   0x2000
+#else
+# error "unknown Darwin target"
+#endif
+
+/* Try to map a known position in the VM.  The current PCH implementation
+   can adjust values at write-time, but not at read-time thus we need to
+   pick up the same position when reading as we got at write-time.  */
 
 void *
-darwin_gt_pch_get_address (size_t sz, int fd ATTRIBUTE_UNUSED)
+darwin_gt_pch_get_address (size_t sz, int fd)
 {
-  if (sz <= sizeof (pch_address_space))
-return pch_address_space;
-  else
-return NULL;
+  if (sz > SAFE_ALLOC_SIZE)
+{
+  error ("PCH memory request exceeds the available space");
+  return NULL;
+}
+
+  /* Now try with the constraint that we really want this address...  */
+  void *addr = mmap ((void *)TRY_EMPTY_VM_SPACE, sz, PROT_READ | PROT_WRITE,
+MAP_PRIVATE | MAP_FIXED, fd, 0);
+
+  if (addr != (void *) MAP_FAILED)
+munmap (addr, sz);
+
+  /* This ought to be the only alternative to failure, but there are comments
+ that suggest some versions of mmap can be buggy and return a different
+ value

[pushed] Objective-C, NeXT: Reorganise meta-data declarations.

2021-12-05 Thread Iain Sandoe via Gcc-patches
This moves the GTY declaration of the meta-data indentifier
array into the header that enumerates these and provides
shorthand defines for them.  This avoids a problem seen with
a relocatable PCH implementation.

Tested on x86_64, i686 Darwin, pushed to master, thanks
Iain

Signed-off-by: Iain Sandoe 

gcc/objc/ChangeLog:

* objc-next-metadata-tags.h (objc_rt_trees): Declare here.
* objc-next-runtime-abi-01.c: Remove from here.
* objc-next-runtime-abi-02.c: Likewise.
* objc-runtime-shared-support.c: Reorder headers, provide
a GTY declaration the definition of objc_rt_trees.
---
 gcc/objc/objc-next-metadata-tags.h | 2 ++
 gcc/objc/objc-next-runtime-abi-01.c| 9 +
 gcc/objc/objc-next-runtime-abi-02.c| 9 +
 gcc/objc/objc-runtime-shared-support.c | 9 ++---
 4 files changed, 6 insertions(+), 23 deletions(-)

diff --git a/gcc/objc/objc-next-metadata-tags.h 
b/gcc/objc/objc-next-metadata-tags.h
index ceb87832359..aea14558b5c 100644
--- a/gcc/objc/objc-next-metadata-tags.h
+++ b/gcc/objc/objc-next-metadata-tags.h
@@ -79,6 +79,8 @@ enum objc_runtime_tree_index
   OCTI_RT_META_MAX
 };
 
+extern GTY(()) tree objc_rt_trees[OCTI_RT_META_MAX];
+
 /* Tags for the META data so that the backend can put them in the correct
sections for targets/runtimes (Darwin/NeXT) that require this.
This information also survives LTO - which might produce mixed language
diff --git a/gcc/objc/objc-next-runtime-abi-01.c 
b/gcc/objc/objc-next-runtime-abi-01.c
index 12f8bdc0b9c..0f76162c70e 100644
--- a/gcc/objc/objc-next-runtime-abi-01.c
+++ b/gcc/objc/objc-next-runtime-abi-01.c
@@ -55,6 +55,7 @@ along with GCC; see the file COPYING3.  If not see
 
 #include "objc-runtime-hooks.h"
 #include "objc-runtime-shared-support.h"
+#include "objc-next-metadata-tags.h"
 #include "objc-encoding.h"
 
 /* NeXT ABI 0 and 1 private definitions.  */
@@ -99,14 +100,6 @@ along with GCC; see the file COPYING3.  If not see
 
 #define CLS_HAS_CXX_STRUCTORS  0x2000L
 
-/* rt_trees identifiers - shared between NeXT implementations.  These
-   allow the FE to tag meta-data in a manner that survives LTO and can
-   be used when the runtime requires that certain meta-data items
-   appear in particular named sections.  */
-
-#include "objc-next-metadata-tags.h"
-extern GTY(()) tree objc_rt_trees[OCTI_RT_META_MAX];
-
 static void next_runtime_01_initialize (void);
 
 static tree next_runtime_abi_01_super_superclassfield_id (void);
diff --git a/gcc/objc/objc-next-runtime-abi-02.c 
b/gcc/objc/objc-next-runtime-abi-02.c
index 7ca0fd7cf00..913ed643782 100644
--- a/gcc/objc/objc-next-runtime-abi-02.c
+++ b/gcc/objc/objc-next-runtime-abi-02.c
@@ -55,6 +55,7 @@ along with GCC; see the file COPYING3.  If not see
 
 #include "objc-runtime-hooks.h"
 #include "objc-runtime-shared-support.h"
+#include "objc-next-metadata-tags.h"
 #include "objc-encoding.h"
 
 /* ABI 2 Private definitions. */
@@ -180,14 +181,6 @@ enum objc_v2_tree_index
 #define objc_rethrow_exception_decl \
objc_v2_global_trees[OCTI_V2_RETHROW_DECL]
 
-/* rt_trees identifiers - shared between NeXT implementations.  These allow
-   the FE to tag meta-data in a manner that survives LTO and can be used when
-   the  runtime requires that certain meta-data items appear in particular
-   named sections.  */
-
-#include "objc-next-metadata-tags.h"
-extern GTY(()) tree objc_rt_trees[OCTI_RT_META_MAX];
-
 /* The OCTI_V2_... enumeration itself is in above.  */
 static GTY(()) tree objc_v2_global_trees[OCTI_V2_MAX];
 
diff --git a/gcc/objc/objc-runtime-shared-support.c 
b/gcc/objc/objc-runtime-shared-support.c
index 40f506c6e75..0d3036f478e 100644
--- a/gcc/objc/objc-runtime-shared-support.c
+++ b/gcc/objc/objc-runtime-shared-support.c
@@ -44,16 +44,11 @@ along with GCC; see the file COPYING3.  If not see
 #include "objc-runtime-hooks.h"
 
 #include "objc-runtime-shared-support.h"
-#include "objc-encoding.h"
-
-/* rt_trees identifiers - shared between NeXT implementations.  These allow
-   the FE to tag meta-data in a manner that survives LTO and can be used when
-   the  runtime requires that certain meta-data items appear in particular
-   named sections.  */
 #include "objc-next-metadata-tags.h"
-extern GTY(()) tree objc_rt_trees[OCTI_RT_META_MAX];
+#include "objc-encoding.h"
 
 /* Rather than repeatedly looking up the identifiers, we save them here.  */
+extern GTY(()) tree objc_rt_trees[OCTI_RT_META_MAX];
 tree objc_rt_trees[OCTI_RT_META_MAX];
 
 /* For building an objc struct.  These might not be used when this file
-- 
2.24.3 (Apple Git-128)



Re: [PATCH] pch: Add support for relocation of the PCH data [PR71934]

2021-12-08 Thread Iain Sandoe via Gcc-patches


> On 7 Dec 2021, at 14:50, Jakub Jelinek via Gcc-patches 
>  wrote:
> 
> On Tue, Dec 07, 2021 at 10:55:07AM +0100, Jakub Jelinek via Gcc-patches wrote:
>> So, this patch instead builds a relocation table (sorted list of addresses
>> in the blob which needs relocation) at PCH save time, stores it in a very
>> compact form into the gch file and upon restore, adjusts pointers in GTY
>> roots (that is right away in the root structures) and the addresses in the
>> relocation table.
>> The cost on stdc++.gch/O2g.gch (previously 85MB large) is about 3% file size
>> growth, there are 2.5 million pointers that need relocation in the gch blob
>> and the relocation table uses uleb128 for address deltas and needs ~1.01 
>> bytes
>> for one address that needs relocation, and about 20% compile time during
>> PCH save (I think it is mainly because of the need to qsort those 2.5
>> million pointers).  On PCH restore, if it doesn't need relocation (the usual
>> case), it is just an extra fread of sizeof (size_t) data and fseek
>> (in my tests real time on vanilla tree for #include  CU
>> was ~0.175s and with the patch but no relocation ~0.173s), while if it needs
>> relocation it took ~0.193s, i.e. 11.5% slower.
> 
> I'll note that without PCH that
> #include 
> int i;
> testcase compiles with -O2 -g in ~1.199s, i.e. 6.2 times slower than PCH with
> relocation and 6.9 times than PCH without relocation.

I’ve run tests across the Darwin range, including old and new m32 hosts, and 
this
seems to be working well.

The attached patch should be applied before (or merged with) the change for
relocation when it is applied - since the operation of the PCH hooks needs some
adjustment on Darwin.

thanks for working on this!
Iain



0001-Darwin-PCH-Rework-PCH-hooks-for-relocatable-implemen.patch
Description: Binary data


[pushed] Darwin: Amend pie options when linking mdynamic-no-pic.

2021-12-08 Thread Iain Sandoe via Gcc-patches
On i686 Darwin from macOS 10.7 onwards the default is to
link executables as PIE, which conflicts with code generated
using mdynamic-no-pic.  Rather than warn about this and then
get the user to add -Wl,-no_pie, we can inject this in the
link specs.

tested on i686,powerpc-darwin9,i686-darwin17, x86_64-darwin,
pushed to master, thanks
Iain

Signed-off-by: Iain Sandoe 

gcc/ChangeLog:

* config/darwin.h (DARWIN_PIE_SPEC): Add -no_pie when
linking mdynamic-no-pic code on macOS > 10.7.
---
 gcc/config/darwin.h | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/gcc/config/darwin.h b/gcc/config/darwin.h
index 9895e7f99ec..0ce13207ad6 100644
--- a/gcc/config/darwin.h
+++ b/gcc/config/darwin.h
@@ -288,13 +288,17 @@ extern GTY(()) int darwin_ms_struct;
 #define DARWIN_RDYNAMIC "%{rdynamic:%nrdynamic is not supported}"
 #endif
 
-/* FIXME: we should check that the linker supports the -pie and -no_pie.
+/* Code built with mdynamic-no-pic does not support PIE/PIC, so  we disallow
+   these combinations; we also ensure that the no_pie option is passed to
+   ld64 on system versions that default to PIE when mdynamic-no-pic is given.
+   FIXME: we should check that the linker supports the -pie and -no_pie.
options.  */
 #define DARWIN_PIE_SPEC \
 "%{pie|fpie|fPIE:\
%{mdynamic-no-pic: \
  %n'-mdynamic-no-pic' overrides '-pie', '-fpie' or '-fPIE'; \
- :%:version-compare(>= 10.5 mmacosx-version-min= -pie) }} "
+ :%:version-compare(>= 10.5 mmacosx-version-min= -pie) }; \
+   mdynamic-no-pic:%:version-compare(>= 10.7 mmacosx-version-min= -no_pie) } "
 
 #define DARWIN_NOPIE_SPEC \
 "%{no-pie|fno-pie|fno-PIE: \
-- 
2.24.3 (Apple Git-128)



[pushed] libgcc, Darwin: Build a libgcc_s.1 for backwards compatibility.

2021-12-08 Thread Iain Sandoe via Gcc-patches
In order to reslve a long-standing issue with inter-operation
with libSystem, we have bumped the SO name for libgcc_s.

Distributions might wish to install this new version into a
structure where exisiting code is already linked with the
compiler-local libgcc_s.1 (providing symbols exported by the
now-retired libgcc_ext.10.x shims).

The replacement libgcc_s.1 forwards the symbols from the new SO.
In order to support DYLD_LIBRARY_PATH on systems (where it works)
we forward the libSystem unwinder symbols from 10.7+ and a
compiler-local version of the libgcc unwinder on earlier.

For macOS 10.4 to 10.6 this is 'bug-compatible' with existing uses.
For 10.7+ the behaviour will now actually be correct.

This should be squashed with the initial libgcc changes for PR80556
in any backport (r12-5418-gd4943ce939d).

tested on powerpc, i686, x86_64 and aarch64 (where this will be a NOP
since there are no historical uses to cater for).
pushed to master, thanks
Iain

Signed-off-by: Iain Sandoe 
 
libgcc/ChangeLog:

* config.host (*-*-darwin*): Add logic to build a shared
unwinder library for Darwin8-10.
* config/i386/t-darwin: Build legacy libgcc_s.1.
* config/rs6000/t-darwin: Likewise.
* config/t-darwin: Reorganise the EH fragments to place
them for inclusion in a shared EH lib.
* config/t-slibgcc-darwin: Build a legacy libgcc_s.1 and
the supporting pieces (all FAT libs).
* config/t-darwin-noeh: Removed.
* config/darwin-unwind.ver: New file.
* config/rs6000/t-darwin-ehs: New file.
* config/t-darwin-ehs: New file.
---
 libgcc/config.host|  13 ++-
 libgcc/config/darwin-unwind.ver   |  30 +++
 libgcc/config/i386/t-darwin   |   3 +
 libgcc/config/rs6000/t-darwin |   3 +
 libgcc/config/rs6000/t-darwin-ehs |   5 ++
 libgcc/config/t-darwin|  19 -
 libgcc/config/t-darwin-ehs|   4 +
 libgcc/config/t-darwin-noeh   |   4 -
 libgcc/config/t-slibgcc-darwin| 130 ++
 9 files changed, 186 insertions(+), 25 deletions(-)
 create mode 100644 libgcc/config/darwin-unwind.ver
 create mode 100644 libgcc/config/rs6000/t-darwin-ehs
 create mode 100644 libgcc/config/t-darwin-ehs
 delete mode 100644 libgcc/config/t-darwin-noeh

diff --git a/libgcc/config.host b/libgcc/config.host
index 9475246593b..d4c035c7188 100644
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -215,10 +215,17 @@ case ${host} in
 *-*-darwin*)
   asm_hidden_op=.private_extern
   tmake_file="$tmake_file t-darwin ${cpu_type}/t-darwin t-libgcc-pic"
-  extra_parts="crt3.o libd10-uwfef.a crttms.o crttme.o libemutls_w.a"
   # The unwinder is provided by the system shared libraries, do not add one
-  # to the shared libgcc.
-  tmake_file="$tmake_file t-darwin-noeh t-slibgcc-darwin"
+  # to the shared libgcc but, for older systems, we build a shared unwinder
+  # separately so that we can construct a libgcc_s.1 to use for binaries
+  # linked against the old libgcc_ext.10.x stubs.
+  case ${host} in
+*-*-darwin[89]* | *-*-darwin10*)
+  tmake_file="$tmake_file t-darwin-ehs ${cpu_type}/t-darwin-ehs"
+  ;;
+  esac
+  tmake_file="$tmake_file t-slibgcc-darwin"
+  extra_parts="crt3.o libd10-uwfef.a crttms.o crttme.o libemutls_w.a"
   ;;
 *-*-dragonfly*)
   tmake_file="$tmake_file t-crtstuff-pic t-libgcc-pic t-eh-dw2-dip"
diff --git a/libgcc/config/darwin-unwind.ver b/libgcc/config/darwin-unwind.ver
new file mode 100644
index 000..fb74cb2c5d2
--- /dev/null
+++ b/libgcc/config/darwin-unwind.ver
@@ -0,0 +1,30 @@
+# unwinder
+__Unwind_DeleteException
+__Unwind_Find_FDE
+__Unwind_ForcedUnwind
+__Unwind_GetGR
+__Unwind_GetIP
+__Unwind_GetLanguageSpecificData
+__Unwind_GetRegionStart
+__Unwind_GetTextRelBase
+__Unwind_GetDataRelBase
+__Unwind_RaiseException
+__Unwind_Resume
+__Unwind_SetGR
+__Unwind_SetIP
+__Unwind_FindEnclosingFunction
+__Unwind_GetCFA
+__Unwind_Backtrace
+__Unwind_Resume_or_Rethrow
+__Unwind_GetIPInfo
+
+___register_frame
+___register_frame_table
+___register_frame_info
+___register_frame_info_bases
+___register_frame_info_table
+___register_frame_info_table_bases
+
+___deregister_frame
+___deregister_frame_info
+___deregister_frame_info_bases
diff --git a/libgcc/config/i386/t-darwin b/libgcc/config/i386/t-darwin
index c6b3acaaca2..4c18da1efbf 100644
--- a/libgcc/config/i386/t-darwin
+++ b/libgcc/config/i386/t-darwin
@@ -4,3 +4,6 @@ LIB2FUNCS_EXCLUDE = _fixtfdi _fixunstfdi _floatditf _floatunditf
 
 # Extra symbols for this port.
 SHLIB_MAPFILES += $(srcdir)/config/i386/libgcc-darwin.ver
+
+# Build a legacy libgcc_s.1
+BUILD_LIBGCCS1 = YES
diff --git a/libgcc/config/rs6000/t-darwin b/libgcc/config/rs6000/t-darwin
index 8b513bdb1d7..183d0df92ce 100644
--- a/libgcc/config/rs6000/t-darwin
+++ b/libgcc/config/rs6000/t-darwin
@@ -56,3 +56,6 @@ unwind-dw2_s.o: HOST_LIBGCC2_CFLAGS += -maltivec
 unwind-dw2.o: HOST_LIBGCC2_CFLAGS += -maltivec
 
 LIB2ADDEH += $(srcdir)/config/rs6000

Re: [PATCH] pch: Add support for relocation of the PCH data [PR71934]

2021-12-09 Thread Iain Sandoe via Gcc-patches



> On 9 Dec 2021, at 14:59, Jakub Jelinek  wrote:
> 
> On Wed, Dec 08, 2021 at 08:00:03AM +, Iain Sandoe wrote:
>>> On 7 Dec 2021, at 14:50, Jakub Jelinek via Gcc-patches 
>>>  wrote:
>> The attached patch should be applied before (or merged with) the change for
>> relocation when it is applied - since the operation of the PCH hooks needs 
>> some
>> adjustment on Darwin.
> 
> Oops, didn't do this change and therefore likely broke Darwin and apparently
> HP-UX.
> Went through other targets and they don't do this reading in there and so
> aren't problematic.  Of course, as I said before, to enable relocation
> support one has to do minor changes to the hook not to fail on those but
> update the reference parameter.
> 
> I've committed following which should hopefully unbreak it (untested),
> please go ahead with your patch without the last hunk incrementally when
> you're ready.

I was just retesting my patch on top of master - will merge the two.
thanks
Iain
> 
> 2021-12-09  Jakub Jelinek  
> 
>   PR pch/71934
>   * config/host-darwin.c (darwin_gt_pch_use_address): When reading
>   manually the file into mapped area, update mapped_addr as
>   an automatic variable rather than addr which is a reference parameter.
>   * config/host-hpux.c (hpux_gt_pch_use_address): When reading
>   manually the file into mapped area, update addr as
>   an automatic variable rather than base which is a reference parameter.
> 
> --- gcc/config/host-darwin.c.jj   2021-12-09 15:40:06.232022601 +0100
> +++ gcc/config/host-darwin.c  2021-12-09 15:48:51.397467287 +0100
> @@ -185,10 +185,10 @@ darwin_gt_pch_use_address (void *&addr,
> {
>   ssize_t nbytes;
> 
> -  nbytes = read (fd, addr, MIN (sz, (size_t) -1 >> 1));
> +  nbytes = read (fd, mapped_addr, MIN (sz, (size_t) -1 >> 1));
>   if (nbytes <= 0)
>   return -1;
> -  addr = (char *) addr + nbytes;
> +  mapped_addr = (char *) mapped_addr + nbytes;
>   sz -= nbytes;
> }
> 
> --- gcc/config/host-hpux.c.jj 2021-12-09 15:40:06.251022328 +0100
> +++ gcc/config/host-hpux.c2021-12-09 15:49:25.464977378 +0100
> @@ -115,10 +115,10 @@ hpux_gt_pch_use_address (void *&base, si
> {
>   ssize_t nbytes;
> 
> -  nbytes = read (fd, base, MIN (size, SSIZE_MAX));
> +  nbytes = read (fd, addr, MIN (size, SSIZE_MAX));
>   if (nbytes <= 0)
> return -1;
> -  base = (char *) base + nbytes;
> +  addr = (char *) addr + nbytes;
>   size -= nbytes;
> }
> 
> 
> 
>   Jakub
> 



[pushed] libgcc, Darwin: Update darwin10 unwinder shim dependencies.

2021-12-10 Thread Iain Sandoe via Gcc-patches
We include libgcc_tm.h to provide a prototype for this shim
so add that to the make dependencies.

tested on x86_64-darwin, pushed to master, thanks
Iain

Signed-off-by: Iain Sandoe 

libgcc/ChangeLog:

* config/t-darwin: Add libgcc_tm.h to the dependencies
for darwin10-unwind-find-enc-func.
---
 libgcc/config/t-darwin | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libgcc/config/t-darwin b/libgcc/config/t-darwin
index a855ecfd526..299d26c2c96 100644
--- a/libgcc/config/t-darwin
+++ b/libgcc/config/t-darwin
@@ -25,7 +25,7 @@ libemutls_w.a: emutls_s.o
$(RANLIB_FOR_TARGET) $@
 
 # Patch to __Unwind_Find_Enclosing_Function for Darwin10.
-d10-uwfef.o: $(srcdir)/config/darwin10-unwind-find-enc-func.c
+d10-uwfef.o: $(srcdir)/config/darwin10-unwind-find-enc-func.c libgcc_tm.h
$(crt_compile) -mmacosx-version-min=10.6 -c $<
 
 # Using this crt as a library means that it will not be added to an exe
-- 
2.24.3 (Apple Git-128)



[PATCH] configure: Account CXXFLAGS in gcc-plugin.m4.

2021-12-10 Thread Iain Sandoe via Gcc-patches
While doing tests of the PCH changes, I noticed that all the
plugin tests were being omitted from m32 Darwin under some
permutations of flags.  It turned out to be a broken config
test - it was not removing -mdynamic-no-pic properly.

We now use a C++ compiler so that we need to process CXXFLAGS
as well as CFLAGS in the gcc-plugin config fragment.

Tested on i686, x86_64-darwin, x86_64, powerpc64le-linux
OK for master?
backports?

Signed-off-by: Iain Sandoe 

config/ChangeLog:

* gcc-plugin.m4: Save and process CXXFLAGS.

gcc/ChangeLog:

* configure: Regenerate.

libcc1/ChangeLog:

* configure: Regenerate.
---
 config/gcc-plugin.m4 | 5 +
 gcc/configure| 5 +
 libcc1/configure | 5 +
 3 files changed, 15 insertions(+)

diff --git a/config/gcc-plugin.m4 b/config/gcc-plugin.m4
index 8f278719118..7ee342fe5fe 100644
--- a/config/gcc-plugin.m4
+++ b/config/gcc-plugin.m4
@@ -91,14 +91,18 @@ AC_DEFUN([GCC_ENABLE_PLUGINS],
  # Check that we can build shared objects with -fPIC -shared
  saved_LDFLAGS="$LDFLAGS"
  saved_CFLAGS="$CFLAGS"
+ saved_CXXFLAGS="$CXXFLAGS"
  case "${host}" in
*-*-darwin*)
 CFLAGS=`echo $CFLAGS | sed s/-mdynamic-no-pic//g`
 CFLAGS="$CFLAGS -fPIC"
+CXXFLAGS=`echo $CXXFLAGS | sed s/-mdynamic-no-pic//g`
+CXXFLAGS="$CXXFLAGS -fPIC"
 LDFLAGS="$LDFLAGS -shared -undefined dynamic_lookup"
;;
*)
 CFLAGS="$CFLAGS -fPIC"
+CXXFLAGS="$CXXFLAGS -fPIC"
 LDFLAGS="$LDFLAGS -fPIC -shared"
;;
  esac
@@ -113,6 +117,7 @@ AC_DEFUN([GCC_ENABLE_PLUGINS],
  fi
  LDFLAGS="$saved_LDFLAGS"
  CFLAGS="$saved_CFLAGS"
+ CXXFLAGS="$saved_CXXFLAGS"
 
  # If plugin support had been requested but not available, fail.
  if test x"$enable_plugin" = x"no" ; then
diff --git a/gcc/configure b/gcc/configure
index de20e5d2629..5470987b62f 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -32038,14 +32038,18 @@ fi
  # Check that we can build shared objects with -fPIC -shared
  saved_LDFLAGS="$LDFLAGS"
  saved_CFLAGS="$CFLAGS"
+ saved_CXXFLAGS="$CXXFLAGS"
  case "${host}" in
*-*-darwin*)
 CFLAGS=`echo $CFLAGS | sed s/-mdynamic-no-pic//g`
 CFLAGS="$CFLAGS -fPIC"
+CXXFLAGS=`echo $CXXFLAGS | sed s/-mdynamic-no-pic//g`
+CXXFLAGS="$CXXFLAGS -fPIC"
 LDFLAGS="$LDFLAGS -shared -undefined dynamic_lookup"
;;
*)
 CFLAGS="$CFLAGS -fPIC"
+CXXFLAGS="$CXXFLAGS -fPIC"
 LDFLAGS="$LDFLAGS -fPIC -shared"
;;
  esac
@@ -32077,6 +32081,7 @@ rm -f core conftest.err conftest.$ac_objext \
  fi
  LDFLAGS="$saved_LDFLAGS"
  CFLAGS="$saved_CFLAGS"
+ CXXFLAGS="$saved_CXXFLAGS"
 
  # If plugin support had been requested but not available, fail.
  if test x"$enable_plugin" = x"no" ; then
diff --git a/libcc1/configure b/libcc1/configure
index b198b0b9074..01cfb2806da 100755
--- a/libcc1/configure
+++ b/libcc1/configure
@@ -15141,14 +15141,18 @@ fi
  # Check that we can build shared objects with -fPIC -shared
  saved_LDFLAGS="$LDFLAGS"
  saved_CFLAGS="$CFLAGS"
+ saved_CXXFLAGS="$CXXFLAGS"
  case "${host}" in
*-*-darwin*)
 CFLAGS=`echo $CFLAGS | sed s/-mdynamic-no-pic//g`
 CFLAGS="$CFLAGS -fPIC"
+CXXFLAGS=`echo $CXXFLAGS | sed s/-mdynamic-no-pic//g`
+CXXFLAGS="$CXXFLAGS -fPIC"
 LDFLAGS="$LDFLAGS -shared -undefined dynamic_lookup"
;;
*)
 CFLAGS="$CFLAGS -fPIC"
+CXXFLAGS="$CXXFLAGS -fPIC"
 LDFLAGS="$LDFLAGS -fPIC -shared"
;;
  esac
@@ -15180,6 +15184,7 @@ rm -f core conftest.err conftest.$ac_objext \
  fi
  LDFLAGS="$saved_LDFLAGS"
  CFLAGS="$saved_CFLAGS"
+ CXXFLAGS="$saved_CXXFLAGS"
 
  # If plugin support had been requested but not available, fail.
  if test x"$enable_plugin" = x"no" ; then
-- 
2.24.3 (Apple Git-128)



Re: [PATCH 0/6] Add Intel Sierra Forest Instructions

2022-10-14 Thread Iain Sandoe via Gcc-patches
Hi Haochen

> On 14 Oct 2022, at 08:54, Haochen Jiang via Gcc-patches 
>  wrote:
> 

> These six patches aimed to add Intel Sierra Forest instructions, including
> AVX-IFMA, AVX-VNNI0INT8, AVX-NE-CONVERT, CMPccXADD. We also added intrinsic
> for vector __bf16 in this series of patch and Sierra Forest Support.
> 
> The information is based on newly released
> Intel Architecture Instruction Set Extensions and Future Features.
> 
> The document comes following:
> https://www.intel.com/content/www/us/en/develop/download/intel-architecture-instruction-set-extensions-programming-reference.html
> 
> Regtested on x86_64-pc-linux-gnu. Ok for trunk?

Have you tested that the testcases work on older platforms that do not have 
support
for the new instructions in their assemblers?

I could not see any target-requires changes in the testcases .. hence my 
question.

(otherwise we end up with a lot of spurious test fails on these older 
platforms).

thanks
Iain

Re: [PATCH 0/6] Add Intel Sierra Forest Instructions

2022-10-14 Thread Iain Sandoe via Gcc-patches



> On 14 Oct 2022, at 09:20, Hongtao Liu  wrote:
> 
> On Fri, Oct 14, 2022 at 4:14 PM Iain Sandoe via Gcc-patches
>  wrote:
>> 
>> Hi Haochen
>> 
>>> On 14 Oct 2022, at 08:54, Haochen Jiang via Gcc-patches 
>>>  wrote:
>>> 
>> 
>>> These six patches aimed to add Intel Sierra Forest instructions, including
>>> AVX-IFMA, AVX-VNNI0INT8, AVX-NE-CONVERT, CMPccXADD. We also added intrinsic
>>> for vector __bf16 in this series of patch and Sierra Forest Support.
>>> 
>>> The information is based on newly released
>>> Intel Architecture Instruction Set Extensions and Future Features.
>>> 
>>> The document comes following:
>>> https://www.intel.com/content/www/us/en/develop/download/intel-architecture-instruction-set-extensions-programming-reference.html
>>> 
>>> Regtested on x86_64-pc-linux-gnu. Ok for trunk?
>> 
>> Have you tested that the testcases work on older platforms that do not have 
>> support
>> for the new instructions in their assemblers?
>> 
>> I could not see any target-requires changes in the testcases .. hence my 
>> question.
>> 
> Guess you are looking at compile tests?

yes, compile tests would need support from the assembler.
> 
> For runtime test, we have add assembler check(target-requires changed)
> plus runtime check(builtin_cpu_supports)
> .i.e.
> 
> +++ b/gcc/testsuite/gcc.target/i386/avx-ifma-vpmaddhuq-2.c
> @@ -0,0 +1,72 @@
> +/* { dg-do run } */
> +/* { dg-options "-O2 -mavxifma" } */
> +/* { dg-require-effective-target avxifma } */
> 
> Do I miss some?

I would need to look at the sources after patching (perhaps they already have 
suitable target-requires that did not show up in the patch).

Do you have this series as a branch somewhere that I can try on one of the
like affected platforms? 

Iain



Re: [PATCH 0/6] Add Intel Sierra Forest Instructions

2022-10-14 Thread Iain Sandoe via Gcc-patches



> On 14 Oct 2022, at 09:30, Hongtao Liu  wrote:
> 
> On Fri, Oct 14, 2022 at 4:24 PM Iain Sandoe  wrote:
>> 
>> 
>> 
>>> On 14 Oct 2022, at 09:20, Hongtao Liu  wrote:
>>> 
>>> On Fri, Oct 14, 2022 at 4:14 PM Iain Sandoe via Gcc-patches
>>>  wrote:
>>>> 
>>>> Hi Haochen
>>>> 
>>>>> On 14 Oct 2022, at 08:54, Haochen Jiang via Gcc-patches 
>>>>>  wrote:
>>>>> 
>>>> 
>>>>> These six patches aimed to add Intel Sierra Forest instructions, including
>>>>> AVX-IFMA, AVX-VNNI0INT8, AVX-NE-CONVERT, CMPccXADD. We also added 
>>>>> intrinsic
>>>>> for vector __bf16 in this series of patch and Sierra Forest Support.
>>>>> 
>>>>> The information is based on newly released
>>>>> Intel Architecture Instruction Set Extensions and Future Features.
>>>>> 
>>>>> The document comes following:
>>>>> https://www.intel.com/content/www/us/en/develop/download/intel-architecture-instruction-set-extensions-programming-reference.html
>>>>> 
>>>>> Regtested on x86_64-pc-linux-gnu. Ok for trunk?
>>>> 
>>>> Have you tested that the testcases work on older platforms that do not 
>>>> have support
>>>> for the new instructions in their assemblers?
>>>> 
>>>> I could not see any target-requires changes in the testcases .. hence my 
>>>> question.
>>>> 
>>> Guess you are looking at compile tests?
>> 
>> yes, compile tests would need support from the assembler.

oops, not enough coffee - I’m talking rubbish here - assembler output should be 
fine,

>>> For runtime test, we have add assembler check(target-requires changed)
>>> plus runtime check(builtin_cpu_supports)
>>> .i.e.
>>> 
>>> +++ b/gcc/testsuite/gcc.target/i386/avx-ifma-vpmaddhuq-2.c
>>> @@ -0,0 +1,72 @@
>>> +/* { dg-do run } */
>>> +/* { dg-options "-O2 -mavxifma" } */
>>> +/* { dg-require-effective-target avxifma } */
>>> 
>>> Do I miss some?
>> 
>> I would need to look at the sources after patching (perhaps they already have
>> suitable target-requires that did not show up in the patch).
>> 
>> Do you have this series as a branch somewhere that I can try on one of the
>> like affected platforms?
> 
> Not yet.
> Do we have any external place to put those patches so folks from the
> community can validate before it's committed, HJ?

I’d still like to be able to test if that can be done - I’ve already got a 
large number of
fails from new testcases in earlier additions.

Iain

Re: [PATCH 0/6] Add Intel Sierra Forest Instructions

2022-10-19 Thread Iain Sandoe via Gcc-patches
Hi Hongtao

> On 17 Oct 2022, at 02:56, Hongtao Liu  wrote:
> 
> On Mon, Oct 17, 2022 at 9:30 AM Bernhard Reutner-Fischer
>  wrote:
>> 
>> On 17 October 2022 03:02:22 CEST, Hongtao Liu via Gcc-patches
>> 
>> Do you have this series as a branch somewhere that I can try on one of 
>> the
>> like affected platforms?
> 
> Not yet.
> Do we have any external place to put those patches so folks from the
> community can validate before it's committed, HJ?
>> 
>> 
>> https://gcc.gnu.org/gitwrite.html#vendor
>> 
>> Not sure where in cgit the user branches are visible, though? But they can 
>> certainly be cloned and worked with.
> Thanks for the reminder, I've pushed to remotes/vendors/ix86/ise046.
> * [new ref] refs/vendors/ix86/heads/ise046 ->
> vendors/ix86/ise046

thanks for pushing this branch, much better to test these things before 
committing rather than a panic
to fix after…


with
f90df941532 (HEAD -> ise046, vendors/ix86/ise046) Add m_CORE_ATOM for atom cores

 - on x86_64 Darwin19  I get the following bootstrap fail:

In file included from /src-local/gcc-master/gcc/config/i386/driver-i386.cc:31:
/src-local/gcc-master/gcc/common/config/i386/cpuinfo.h: In function ‘const 
char* get_intel_cpu(__processor_model*, __processor_model2*, unsigned int*)’:
/src-local/gcc-master/gcc/common/config/i386/cpuinfo.h:532:32: error: this 
statement may fall through [-Werror=implicit-fallthrough=]
  532 |   cpu_model->__cpu_subtype = INTEL_COREI7_GRANITERAPIDS;
  |   ~^~~~
/src-local/gcc-master/gcc/common/config/i386/cpuinfo.h:533:5: note: here
  533 | case 0xb6:
  | ^~~~
cc1plus: all warnings being treated as errors


Will try to look later, if that does not immediately ring some bell.
thanks
Iain



Re: [PATCH 0/6] Add Intel Sierra Forest Instructions

2022-10-20 Thread Iain Sandoe via Gcc-patches



> On 20 Oct 2022, at 10:09, Hongtao Liu via Gcc-patches 
>  wrote:
> 
> On Thu, Oct 20, 2022 at 9:11 AM Hongtao Liu  wrote:
>> 
>> On Wed, Oct 19, 2022 at 7:09 PM Iain Sandoe  wrote:
>>> 
>>> Hi Hongtao
>>> 
 On 17 Oct 2022, at 02:56, Hongtao Liu  wrote:
 
 On Mon, Oct 17, 2022 at 9:30 AM Bernhard Reutner-Fischer
  wrote:
> 
> On 17 October 2022 03:02:22 CEST, Hongtao Liu via Gcc-patches
> 
> Do you have this series as a branch somewhere that I can try on one 
> of the
> like affected platforms?
 
 Not yet.
 Do we have any external place to put those patches so folks from the
 community can validate before it's committed, HJ?
> 
> 
> https://gcc.gnu.org/gitwrite.html#vendor
> 
> Not sure where in cgit the user branches are visible, though? But they 
> can certainly be cloned and worked with.
 Thanks for the reminder, I've pushed to remotes/vendors/ix86/ise046.
 * [new ref] refs/vendors/ix86/heads/ise046 ->
 vendors/ix86/ise046
>>> 
>>> thanks for pushing this branch, much better to test these things before 
>>> committing rather than a panic
>>> to fix after…
>>> 
>>> 
>>> with
>>> f90df941532 (HEAD -> ise046, vendors/ix86/ise046) Add m_CORE_ATOM for atom 
>>> cores
>>> 
>>> - on x86_64 Darwin19  I get the following bootstrap fail:
>>> 
>>> In file included from 
>>> /src-local/gcc-master/gcc/config/i386/driver-i386.cc:31:
>>> /src-local/gcc-master/gcc/common/config/i386/cpuinfo.h: In function ‘const 
>>> char* get_intel_cpu(__processor_model*, __processor_model2*, unsigned 
>>> int*)’:
>>> /src-local/gcc-master/gcc/common/config/i386/cpuinfo.h:532:32: error: this 
>>> statement may fall through [-Werror=implicit-fallthrough=]
>>>  532 |   cpu_model->__cpu_subtype = INTEL_COREI7_GRANITERAPIDS;
>>>  |   ~^~~~
>>> /src-local/gcc-master/gcc/common/config/i386/cpuinfo.h:533:5: note: here
>>>  533 | case 0xb6:
>>>  | ^~~~
>>> cc1plus: all warnings being treated as errors
>>> 
>>> 
>>> Will try to look later, if that does not immediately ring some bell.
>> This should a bug, thanks!
> I've updated the branch, please try that.

I had made the same fix locally (adding the “break”, right?) and testing is 
ongoing

it would not be surprising if some tests failed (asm matches for different ABIs 
are rarely
identical) - a few tests to be fixed in stage 3 is fine ...

... but what I wanted to avoid was the case like the bf16 changes where every
single new test fails (I have a draft patch to fix the bf16 stuff to be posted 
soon).

thanks
Iain




Re: Patch ping (was Re: [PATCH] libstdc++: Clear padding bits in atomic compare_exchange)

2022-09-09 Thread Iain Sandoe via Gcc-patches



> On 9 Sep 2022, at 19:36, Rainer Orth  wrote:
> 

>> Here's a complete patch that combines the various incremental patches
>> that have been going around. I'm testing this now.
>> 
>> Please take a look.
> 
> unfortunately, this patch broke macOS bootstrap (seen on
> x86_64-apple-darwin11.4.2):
> 
> In file included from 
> /var/gcc/regression/master/10.7-gcc/build/x86_64-apple-darwin11.4.2/libstdc++-v3/include/bits/shared_ptr_atomic.h:33,
> from 
> /var/gcc/regression/master/10.7-gcc/build/x86_64-apple-darwin11.4.2/libstdc++-v3/include/memory:78,
> from 
> /vol/gcc/src/hg/master/darwin/libstdc++-v3/include/precompiled/stdc++.h:82:
> /var/gcc/regression/master/10.7-gcc/build/x86_64-apple-darwin11.4.2/libstdc++-v3/include/bits/atomic_base.h:
>  In function 'bool std::__atomic_impl::__compare_exchange(_Tp&, _Val<_Tp>&, 
> _Val<_Tp>&, bool, std::memory_order, std::memory_order)':
> /var/gcc/regression/master/10.7-gcc/build/x86_64-apple-darwin11.4.2/libstdc++-v3/include/bits/atomic_base.h:1008:49:
>  error: expected primary-expression before ',' token
> 1008 |   __weak, int(__s), int(__f)))
>  | ^
> /var/gcc/regression/master/10.7-gcc/build/x86_64-apple-darwin11.4.2/libstdc++-v3/include/bits/atomic_base.h:1017:50:
>  error: expected primary-expression before ',' token
> 1017 |__weak, int(__s), int(__f));
>  |  ^
> 
> Darwin gcc predefines __weak= in gcc/config/darwin-c.cc (darwin_cpp_builtins).

yes, __weak and __strong are Objective C things (in principle, applicable to 
non-Darwin targets
using NeXT runtime - there is at least one such target).

Iain



Re: [PATCH v2, rs6000] Change insn condition from TARGET_64BIT to TARGET_POWERPC64 for VSX scalar extract/insert instructions

2022-09-13 Thread Iain Sandoe via Gcc-patches
Hi


> On 13 Sep 2022, at 03:34, HAO CHEN GUI via Gcc-patches 
>  wrote:

> On 7/9/2022 上午 1:19, Segher Boessenkool wrote:
>> make -k -j60 check 
>> RUNTESTFLAGS="--target_board=unix'{-m64,-m32,-m32/-mpowerpc64}'"
>> 
>> It is fine to not test -m32/-mpowerpc64 so often, and certaionly not
>> something I will ask everyone to always do :-)
> 
> IMO, if we add "-mpowerpc64" into dg-options, the "-m32/-mpowerpc64" will be 
> tested
> automatically. It will increase the test coverage. So the concern is it 
> increases test
> time?

Do you mean for the powerpc-target tests, or for the entire suite?
 - 50% increase is pretty significant to the entire suite.  It would probably 
only be acceptable on
the newer powerful machines.

The stategy would need to be a little more subtle than adding it everywhere  - 
it is not applicable
to 32b targets running on 32b hardware - however, it *is* potentially 
applicable to 32b targets
running on 64b hardware (I have one of those).



There are tricks you can play with dejagnu to automate this for your setup… by 
pointing the 
DEJAGNU environment to a script (or by using .dejagnurc in your home directory).

You can add customisation in this way, even to set different parameters per 
host.  This saves
me from remembering to put the RUNTESTFLAGS=… extras for the target on each 
test line.

— so here’s an example as I use it..

I have an environment/script setup like this (which I use to control what is 
done across a range of
machines with capabilities that vary by at least a factor of 10):

DEJAGNU=/path/to/gcc-runtest-site.exp

gcc-runtest-site.exp:

global target_list
global tool_timeout

case "$target_triplet" in {
   { "*-*-darwin[5-8]*" } {
set target_list { "unix" }
set tool_timeout 240
puts "tool timeout 3mins"
   }
   { "*-*-darwin9*" } {
set target_list { "unix{-m32,-m64}" }
set tool_timeout 240
   }
   { "i?86-*-darwin10*" } {
set target_list { "unix" }
   }
   { "powerpc-*-darwin10*" } {
set target_list { "unix" }
   }
   { "*-*-darwin1[01234567]*" } {
set target_list { "unix{-m64,-m32}" }
set tool_timeout 120
puts "gcc-runtest-site : tool timeout 2 mins"
   }
   { "*-*-darwin1[89]*" } {
set target_list { "unix" }
set tool_timeout 60
puts "gcc-runtest-site : tool timeout 1 min"
   }
   { "x86_64-*-linux-gnu" } {
set target_list { "unix{-m32,-m64}" }
set tool_timeout 60
   }



   default {
# Works for most unixy things and for darwin < 9.
   set target_list { "unix" }
   }
}

- sometimes I override this with specific values (especially for timeout) in 
~/..dejagnurc on
  very slow boxes.



0.02GBP only,

cheers
Iain



[pushed] testsuite: Add target requires for ifuncs to mv31.C.

2022-04-28 Thread Iain Sandoe via Gcc-patches
g++.target/i386/mv31.C fails on targets without ifuncs support so add
the necessary target supports guard.

tested on x86_64 linux and darwin.
pushed to master, thanks,
Iain

Signed-off-by: Iain Sandoe 

gcc/testsuite/ChangeLog:

* g++.target/i386/mv31.C: Add target supports guard for ifuncs.
---
 gcc/testsuite/g++.target/i386/mv31.C | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gcc/testsuite/g++.target/i386/mv31.C 
b/gcc/testsuite/g++.target/i386/mv31.C
index 5d8fd1ddf75..70a40f1e28a 100644
--- a/gcc/testsuite/g++.target/i386/mv31.C
+++ b/gcc/testsuite/g++.target/i386/mv31.C
@@ -1,4 +1,5 @@
 // PR c++/104669
+// { dg-require-ifunc "" }
 
 void bar()
 {
-- 
2.24.3 (Apple Git-128)



[pushed] testsuite,X86: Fix missing USER_LABEL_PREFIX cases.

2022-04-28 Thread Iain Sandoe via Gcc-patches
Yet another set of testcases that do not account for targets that
use __USER_LABEL_PREFIX__.

tested on x86_64 Linux and Darwin, pushed to master,
thanks,
Iain

Signed-off-by: Iain Sandoe 

gcc/testsuite/ChangeLog:

* gcc.target/i386/memcpy-strategy-10.c: Account for
__USER_LABEL_PREFIX__.
* gcc.target/i386/memcpy-strategy-5.c: Likewise.
* gcc.target/i386/memset-strategy-5.c: Likewise.
* gcc.target/i386/memset-strategy-7.c: Likewise.
---
 gcc/testsuite/gcc.target/i386/memcpy-strategy-10.c | 4 ++--
 gcc/testsuite/gcc.target/i386/memcpy-strategy-5.c  | 4 ++--
 gcc/testsuite/gcc.target/i386/memset-strategy-5.c  | 4 ++--
 gcc/testsuite/gcc.target/i386/memset-strategy-7.c  | 4 ++--
 4 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/gcc/testsuite/gcc.target/i386/memcpy-strategy-10.c 
b/gcc/testsuite/gcc.target/i386/memcpy-strategy-10.c
index 970aa741971..860fcc9f801 100644
--- a/gcc/testsuite/gcc.target/i386/memcpy-strategy-10.c
+++ b/gcc/testsuite/gcc.target/i386/memcpy-strategy-10.c
@@ -1,7 +1,7 @@
 /* { dg-do compile } */
 /* { dg-options "-O2 -march=skylake -mno-sse" } */
-/* { dg-final { scan-assembler "jmp\tmemcpy" { target { ! ia32 } } } } */
-/* { dg-final { scan-assembler "call\tmemcpy" { target ia32 } } } */
+/* { dg-final { scan-assembler "jmp\t_?memcpy" { target { ! ia32 } } } } */
+/* { dg-final { scan-assembler "call\t_?memcpy" { target ia32 } } } */
 /* { dg-final { scan-assembler-not "rep movsb" } } */
 
 void
diff --git a/gcc/testsuite/gcc.target/i386/memcpy-strategy-5.c 
b/gcc/testsuite/gcc.target/i386/memcpy-strategy-5.c
index 83c333b551d..833e37fa325 100644
--- a/gcc/testsuite/gcc.target/i386/memcpy-strategy-5.c
+++ b/gcc/testsuite/gcc.target/i386/memcpy-strategy-5.c
@@ -1,7 +1,7 @@
 /* { dg-do compile } */
 /* { dg-options "-O2 -march=tigerlake -mno-sse" } */
-/* { dg-final { scan-assembler "jmp\tmemcpy" { target { ! ia32 } } } } */
-/* { dg-final { scan-assembler "call\tmemcpy" { target ia32 } } } */
+/* { dg-final { scan-assembler "jmp\t_?memcpy" { target { ! ia32 } } } } */
+/* { dg-final { scan-assembler "call\t_?memcpy" { target ia32 } } } */
 /* { dg-final { scan-assembler-not "rep movsb" } } */
 
 void
diff --git a/gcc/testsuite/gcc.target/i386/memset-strategy-5.c 
b/gcc/testsuite/gcc.target/i386/memset-strategy-5.c
index dc1de8e79c2..73ce2df6060 100644
--- a/gcc/testsuite/gcc.target/i386/memset-strategy-5.c
+++ b/gcc/testsuite/gcc.target/i386/memset-strategy-5.c
@@ -1,7 +1,7 @@
 /* { dg-do compile } */
 /* { dg-options "-O2 -march=tigerlake -mno-sse" } */
-/* { dg-final { scan-assembler "jmp\tmemset" { target { ! ia32 } } } } */
-/* { dg-final { scan-assembler "call\tmemset" { target ia32 } } } */
+/* { dg-final { scan-assembler "jmp\t_?memset" { target { ! ia32 } } } } */
+/* { dg-final { scan-assembler "call\t_?memset" { target ia32 } } } */
 /* { dg-final { scan-assembler-not "rep stosb" } } */
 
 void
diff --git a/gcc/testsuite/gcc.target/i386/memset-strategy-7.c 
b/gcc/testsuite/gcc.target/i386/memset-strategy-7.c
index 07c2816910c..653829e6fc7 100644
--- a/gcc/testsuite/gcc.target/i386/memset-strategy-7.c
+++ b/gcc/testsuite/gcc.target/i386/memset-strategy-7.c
@@ -1,7 +1,7 @@
 /* { dg-do compile } */
 /* { dg-options "-O2 -march=skylake -mno-sse" } */
-/* { dg-final { scan-assembler "jmp\tmemset" { target { ! ia32 } } } } */
-/* { dg-final { scan-assembler "call\tmemset" { target ia32 } } } */
+/* { dg-final { scan-assembler "jmp\t_?memset" { target { ! ia32 } } } } */
+/* { dg-final { scan-assembler "call\t_?memset" { target ia32 } } } */
 /* { dg-final { scan-assembler-not "rep stosb" } } */
 
 void
-- 
2.24.3 (Apple Git-128)



[PATCH] c++, coroutines: Partial reversion of r12-8308-g15a176a833f23e [PR105426].

2022-04-28 Thread Iain Sandoe via Gcc-patches
The changes to fix PR 105287 included a tightening of the constraints on which
variables are promoted to frame copies.  This has exposed that we are failing
to name some variables that should be promoted.

The long-term fix is to address the cases where the naming has been missed,
but for the short-term (and for the GCC-12 branch) backing out the additional
constraint is proposed.

This makes the fix for PR 105287 more conservative.

tested on x86_64-darwin, with the reproducer from the PR which now produces
the correct output for both optimised and unoptimised code.

OK for master?
OK for GCC-12?
thanks,
Iain

Signed-off-by: Iain Sandoe 

PR c++/105426

gcc/cp/ChangeLog:

* coroutines.cc (register_local_var_uses): Allow promotion of unnamed
temporaries to coroutine frame copies.
---
 gcc/cp/coroutines.cc | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
index 551ddc9cc41..2e393b2cddc 100644
--- a/gcc/cp/coroutines.cc
+++ b/gcc/cp/coroutines.cc
@@ -3973,6 +3973,9 @@ register_local_var_uses (tree *stmt, int *do_subtree, 
void *d)
  else if (lvname != NULL_TREE)
buf = xasprintf ("%s_%u_%u", IDENTIFIER_POINTER (lvname),
 lvd->nest_depth, lvd->bind_indx);
+ else
+   buf = xasprintf ("_D%u_%u_%u", DECL_UID (lvar), lvd->nest_depth,
+lvd->bind_indx);
  /* TODO: Figure out if we should build a local type that has any
 excess alignment or size from the original decl.  */
  if (buf)
-- 
2.24.3 (Apple Git-128)



[pushed] Objective-C, NeXT: Adjust symbol marking to match host tools.

2022-05-03 Thread Iain Sandoe via Gcc-patches
Current host tools mark some additional symbols as 'no dead strip' and also
expose one additional group to the linker.  This does not affect older Darwin
versions or x86_64, but omitting these changes results in link errors for
aarch64.

Tested on i686, x86_64 and a cross to aarch64 Darwin.
pushed to master, thanks,
Iain

Signed-off-by: Iain Sandoe 

gcc/ChangeLog:

* config/darwin.cc (darwin_label_is_anonymous_local_objc_name): Make
protocol class methods linker-visible.

gcc/objc/ChangeLog:

* objc-next-runtime-abi-02.cc (next_runtime_abi_02_protocol_decl): Do
not dead-strip the runtime meta-data symbols.
(build_v2_classrefs_table): Likewise.
(build_v2_protocol_list_address_table): Likewise.
---
 gcc/config/darwin.cc | 2 ++
 gcc/objc/objc-next-runtime-abi-02.cc | 6 --
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/gcc/config/darwin.cc b/gcc/config/darwin.cc
index f065a13d73d..1b3de338926 100644
--- a/gcc/config/darwin.cc
+++ b/gcc/config/darwin.cc
@@ -1936,6 +1936,8 @@ darwin_label_is_anonymous_local_objc_name (const char 
*name)
 }
   else if (startswith ((const char *)p, "ClassMethods"))
 return false;
+  else if (startswith ((const char *)p, "ClassProtocols"))
+return false;
   else if (startswith ((const char *)p, "Instance"))
 {
   if (p[8] == 'I' || p[8] == 'M')
diff --git a/gcc/objc/objc-next-runtime-abi-02.cc 
b/gcc/objc/objc-next-runtime-abi-02.cc
index e50ca6e89f5..9ea63b189c7 100644
--- a/gcc/objc/objc-next-runtime-abi-02.cc
+++ b/gcc/objc/objc-next-runtime-abi-02.cc
@@ -1033,6 +1033,7 @@ next_runtime_abi_02_protocol_decl (tree p)
   else
 decl = start_var_decl (objc_v2_protocol_template, buf);
   OBJCMETA (decl, objc_meta, meta_protocol);
+  DECL_PRESERVE_P (decl) = 1;
   return decl;
 }
 
@@ -2115,8 +2116,8 @@ build_v2_classrefs_table (void)
  expr = convert (objc_class_type, build_fold_addr_expr (expr));
}
   /* The runtime wants this, even if it appears unused, so we must force 
the
-output.
-  DECL_PRESERVE_P (decl) = 1; */
+output.  */
+  DECL_PRESERVE_P (decl) = 1;
   finish_var_decl (decl, expr);
 }
 }
@@ -2318,6 +2319,7 @@ build_v2_protocol_list_address_table (void)
   expr = convert (objc_protocol_type, build_fold_addr_expr (ref->refdecl));
   OBJCMETA (decl, objc_meta, meta_label_protocollist);
   finish_var_decl (decl, expr);
+  DECL_PRESERVE_P (decl) = 1;
 }
 
 /* TODO: delete the vec.  */
-- 
2.24.3 (Apple Git-128)



Re: [PATCH] Fold GCC_VERSION >= $old_version to TRUE, otherwise to FALSE.

2022-05-05 Thread Iain Sandoe via Gcc-patches



> On 5 May 2022, at 19:50, Martin Liška  wrote:
> 
> On 5/5/22 20:35, Andrew Pinski wrote:
>> GCC_VERSION will be 0 if GCC is not being used.
>> So you need to audit these better really.
> 
> Ah, I see. So it basically means all the non-GCC conditional
> code needs to remain and I can replace
> #if GCC_VERSION >= X_Y_Z with #ifdef __GNUC__

I think several non-GCC compilers define __GNUC__ so that depends on what you 
intend.
Iain

> 
> Am I correct?
> Martin



Re: [PATCH v3 1/2] rs6000: Move g++.dg powerpc PR tests to g++.target

2022-05-12 Thread Iain Sandoe via Gcc-patches
Hi

> On 12 May 2022, at 23:38, Segher Boessenkool  
> wrote:

> On Mon, Apr 18, 2022 at 12:15:34PM -0500, Paul A. Clarke wrote:
>> -/* { dg-skip-if "" { powerpc*-*-darwin* } } */
>> +/* Never tested on darwin, so skip there.  */
>> +/* { dg-skip-if "" { *-*-darwin* } } */
> 
> That is probably the reason for the skip, but it is a lousy reason, and
> not a good precedent to create.  It is much better to let the Darwin
> maintainer deal with this *if* it fails.  If you have proof it fails on
> Darwin, just say *that* (or even say *why* it fails!)

For the record, if there’s a specific patch you’d like tested on Darwin,
I am happy to try and fit it into the schedule (the machine is slow for
modern codebases, so don’t expect immediate answers).

Iain



Re: [COMMITTED] Export global ranges during the VRP block walk.

2022-05-14 Thread Iain Sandoe via Gcc-patches
Hi Andrew

> On 13 May 2022, at 14:58, Andrew MacLeod via Gcc-patches 
>  wrote:
> 
> VRP currently searches the ssa_name list for globals to exported after it  
> finishes running.  This change simply exports globals as they are calculated 
> for the final time during the DOM walk.
> 
> This avoid the occasional awkwardness of determined what ssa-names in the 
> list are important, as well as allowing forthcoming side-effect code to 
> adjust what is currently known as a global value during the walk without 
> affecting the values exported for the entire function.
> 
> Bootstrapped on x86_64-pc-linux-gnu with no regressions.  Pushed.

This (r13-436-gaf34279921f4) appears to cause or expose a problem which breaks 
bootstrap with in-tree MPFR on at least x86_64-linux/darwin.

thanks
Iain

during GIMPLE pass: threadfull
../../../src/mpfr/src/sin_cos.c: In function ‘mpfr_sin_cos’:
../../../src/mpfr/src/sin_cos.c:29:1: internal compiler error: in type, at 
value-range.h:225
   29 | mpfr_sin_cos (mpfr_ptr y, mpfr_ptr z, mpfr_srcptr x, mpfr_rnd_t 
rnd_mode)
  | ^~~~
0x107d316 irange::type() const
../../src/gcc/value-range.h:225
0x2a0052d operator_minus::lhs_op1_relation(irange const&, irange const&, irange 
const&, relation_kind_t) const
../../src/gcc/range-op.cc:1349
0x28a4a6a fold_using_range::range_of_range_op(irange&, gimple*, fur_source&)
../../src/gcc/gimple-range-fold.cc:643
0x28a43e4 fold_using_range::fold_stmt(irange&, gimple*, fur_source&, tree_node*)
../../src/gcc/gimple-range-fold.cc:555
0x28a380f fold_range(irange&, gimple*, edge_def*, range_query*)
../../src/gcc/gimple-range-fold.cc:326
0x28accb3 gori_compute::outgoing_edge_range_p(irange&, edge_def*, tree_node*, 
range_query&)
../../src/gcc/gimple-range-gori.cc:1298
0x289e775 ranger_cache::range_from_dom(irange&, tree_node*, basic_block_def*, 
ranger_cache::rfd_mode)
../../src/gcc/gimple-range-cache.cc:1511
0x289dc50 ranger_cache::fill_block_cache(tree_node*, basic_block_def*, 
basic_block_def*)
../../src/gcc/gimple-range-cache.cc:1311
0x289d2a6 ranger_cache::block_range(irange&, basic_block_def*, tree_node*, bool)
../../src/gcc/gimple-range-cache.cc:1139
0x289830a gimple_ranger::range_on_entry(irange&, basic_block_def*, tree_node*)
../../src/gcc/gimple-range.cc:154
0x289817e gimple_ranger::range_of_expr(irange&, tree_node*, gimple*)
../../src/gcc/gimple-range.cc:128
0x165d10f path_range_query::range_on_path_entry(irange&, tree_node*)
../../src/gcc/gimple-range-path.cc:162
0x165d327 path_range_query::internal_range_of_expr(irange&, tree_node*, gimple*)
../../src/gcc/gimple-range-path.cc:203
0x165d435 path_range_query::range_of_expr(irange&, tree_node*, gimple*)
../../src/gcc/gimple-range-path.cc:225
0x28a30b9 fur_stmt::get_operand(irange&, tree_node*)
../../src/gcc/gimple-range-fold.cc:157
0x28abca9 gori_compute::compute_operand1_range(irange&, gimple*, irange const&, 
tree_node*, fur_source&)
../../src/gcc/gimple-range-gori.cc:1023
0x28ab121 gori_compute::compute_operand_range(irange&, gimple*, irange const&, 
tree_node*, fur_source&)
../../src/gcc/gimple-range-gori.cc:760
0x28ac05d gori_compute::compute_operand1_range(irange&, gimple*, irange const&, 
tree_node*, fur_source&)
../../src/gcc/gimple-range-gori.cc:1077
0x28ab121 gori_compute::compute_operand_range(irange&, gimple*, irange const&, 
tree_node*, fur_source&)
../../src/gcc/gimple-range-gori.cc:760
0x28aca70 gori_compute::outgoing_edge_range_p(irange&, edge_def*, tree_node*, 
range_query&)
../../src/gcc/gimple-range-gori.cc:1271



Re: [COMMITTED] Export global ranges during the VRP block walk.

2022-05-14 Thread Iain Sandoe via Gcc-patches
Hi Andrew, Toon,

> On 14 May 2022, at 09:09, Toon Moene  wrote:
> On 5/14/22 10:00, Iain Sandoe via Gcc-patches wrote:
>>> On 13 May 2022, at 14:58, Andrew MacLeod via Gcc-patches 
>>>  wrote:
>>> 
>>> VRP currently searches the ssa_name list for globals to exported after it  
>>> finishes running. This change simply exports globals as they are calculated 
>>> for the final time during the DOM walk.
>>> 
>>> This avoid the occasional awkwardness of determined what ssa-names in the 
>>> list are important, as well as allowing forthcoming side-effect code to 
>>> adjust what is currently known as a global value during the walk without 
>>> affecting the values exported for the entire function.
>>> 
>>> Bootstrapped on x86_64-pc-linux-gnu with no regressions.  Pushed.
>> This (r13-436-gaf34279921f4) appears to cause or expose a problem which 
>> breaks bootstrap with in-tree MPFR on at least x86_64-linux/darwin.
>> thanks
>> Iain
>> during GIMPLE pass: threadfull
>> ../../../src/mpfr/src/sin_cos.c: In function ‘mpfr_sin_cos’:
>> ../../../src/mpfr/src/sin_cos.c:29:1: internal compiler error: in type, at 
>> value-range.h:225
>>29 | mpfr_sin_cos (mpfr_ptr y, mpfr_ptr z, mpfr_srcptr x, mpfr_rnd_t 
>> rnd_mode)
>>   | ^~~~
>> 0x107d316 irange::type() const
>> ../../src/gcc/value-range.h:225

> Seems to have been fixed in r13-449.

yes, indeed (thanks for the fix Andrew).

> Compare:
> 
> https://gcc.gnu.org/pipermail/gcc-testresults/2022-May/761443.html
> 
> with (r13-448):

Which, by the law of maximum cussedness, was exactly the revision I pulled for 
weekly test runs :/

sorry for the noise,
Iain




Re: [PATCH] bootstrap/97666 - fix array of bool allocation

2020-11-03 Thread Iain Sandoe via Gcc-patches

Martin Sebor via Gcc-patches  wrote:


On 11/3/20 4:13 AM, Richard Biener wrote:

This fixes the bad assumption that sizeof (bool) == 1
Bootstrap / regtest running on x86_64-unknown-linux-gnu.
2020-11-03  Richard Biener  
PR bootstrap/97666
* tree-vect-slp.c (vect_build_slp_tree_2): Scale
allocation of skip_args by sizeof (bool).
---
 gcc/tree-vect-slp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/tree-vect-slp.c b/gcc/tree-vect-slp.c
index e97fbe897a7..08018a1d799 100644
--- a/gcc/tree-vect-slp.c
+++ b/gcc/tree-vect-slp.c
@@ -1428,7 +1428,7 @@ vect_build_slp_tree_2 (vec_info *vinfo, slp_tree  
node,

 /* If the SLP node is a PHI (induction or reduction), terminate
  the recursion.  */
-  bool *skip_args = XALLOCAVEC (bool, nops);
+  bool *skip_args = XALLOCAVEC (bool, sizeof (bool) * nops);


This change caught my eye.  XALLOCAVEC() does the scaling:

 #define XALLOCAVEC(T, N)   ((T *) alloca (sizeof (T) * (N)))

so scaling it again doesn't make sense to me...


   memset (skip_args, 0, nops);


... especially not when it's followed by the memset call above that
doesn't do the same.  If I'm missing some subtlety it might be worth
adding a comment explaining it.


um yes, the fix I tested on powerpc-darwin was…

memset (skip_args, 0, sizeof (bool) * nops);

(I haven’t tried current master, since you pushed this change - regstrap  
takes most

 of a day on that machine).

Iain



Re: [PATCH] x86: Adjust keylocker testcases for fail on darwin

2020-11-09 Thread Iain Sandoe via Gcc-patches

Uros Bizjak via Gcc-patches  wrote:


On Mon, Nov 9, 2020 at 11:50 AM Hongyu Wang  wrote:

Hi

According to the discussion in
https://gcc.gnu.org/pipermail/gcc/2020-November/234096.html,
The testcase for keylocker-* is too strict for darwin target. This
patch adjusted the regex, and add a missing test for aesenc256kl
instruction.

Tested by Iain Sandone and all get pass in darwin target.

Ok for trunk?

gcc/testsuite/ChangeLog

   * gcc.target/i386/keylocker-aesdec128kl.c: Adjust regex patterns.
   * gcc.target/i386/keylocker-aesdec256kl.c: Likewise.
   * gcc.target/i386/keylocker-aesdecwide128kl.c: Likewise.
   * gcc.target/i386/keylocker-aesdecwide256kl.c: Likewise.
   * gcc.target/i386/keylocker-aesenc128kl.c: Likewise.
   * gcc.target/i386/keylocker-aesencwide128kl.c: Likewise.
   * gcc.target/i386/keylocker-aesencwide256kl.c: Likewise.
   * gcc.target/i386/keylocker-encodekey128.c: Likewise.
   * gcc.target/i386/keylocker-encodekey256.c: Likewise.
   * gcc.target/i386/keylocker-aesenc256kl.c: New test.


Please rewrite scan strings back to using double-quotation marks.


out of curiosity, why?

([IMO] the {} form is generally much more readable, and less prone to
 uncaught omissions of \ as happened here)

Iain



Uros.


--
Regards,

Hongyu, Wang





Re: [PATCH] libstdc++: Fix error shown during Solaris build

2020-11-13 Thread Iain Sandoe via Gcc-patches

Jonathan Wakely  wrote:


On 13/11/20 11:07 +, Jonathan Wakely wrote:

Currently this is shown when building libstdc++ on Solaris:

-lrt: open: No such file or directory

The error comes from the make_sunver.pl script which tries to open each
of its arguments. The arguments are passed by this make rule:

perl ${glibcxx_srcdir}/scripts/make_exports.pl \
  libstdc++-symbols.ver \
  $(libstdc___la_OBJECTS:%.lo=.libs/%.o) \
 `echo $(libstdc___la_LIBADD) | \
sed 's,/\([^/.]*\)\.la,/.libs/\1.a,g'` \
 > $@ || (rm -f $@ ; exit 1)

The $(libstdc___la_LIBADD) variable includes $(GLIBCXX_LIBS) which
contains -lrt on Solaris.

This patch adds another sed script to filter -l arguments from the echo
command. In order to reliably match ' -l[^ ]* ' the echo arguments are
quoted and a space added before and after them. This might be overkill
just to remove -lrt from the start of the string, but should be robust
in case other -l arguments are added to $(GLIBCXX_LIBS), or in case the
$(libstdc___la_LIBADD) libraries are reordered.

libstdc++-v3/ChangeLog:

* src/Makefile.am (libstdc++-symbols.ver-sun): Remove -lrt from
arguments passed to make_sunver.pl script.
* src/Makefile.in: Regenerate.

Tested sparc-solaris2.11. Rainer, does this look OK?

Iain, the libstdc++-symbols.explist target for Darwin is very similar,
but I don't know if it's a problem there. Does GLIBCXX_LIBS contain
anything in $target/libstdc++-v3/src/Makefile on Darwin?

Should we make the same change just in case?


On examining acinclude.m4 it looks like GLIBCXX_LIBS could in theory
be non-empty for any target, including Darwin:

 elif test x"$enable_libstdcxx_time" != x"no"; then

   if test x"$enable_libstdcxx_time" = x"rt"; then
 AC_SEARCH_LIBS(clock_gettime, [rt posix4])
 AC_SEARCH_LIBS(nanosleep, [rt posix4])
   else
 AC_SEARCH_LIBS(clock_gettime, [posix4])
 AC_SEARCH_LIBS(nanosleep, [posix4])
   fi

   case "$ac_cv_search_clock_gettime" in
 -l*) GLIBCXX_LIBS=$ac_cv_search_clock_gettime
 ;;
   esac
   case "$ac_cv_search_nanosleep" in
 -l*) GLIBCXX_LIBS="$GLIBCXX_LIBS $ac_cv_search_nanosleep"
 ;;
   esac

   AC_SEARCH_LIBS(sched_yield, [rt posix4])

   case "$ac_cv_search_sched_yield" in
 -lposix4*)
 GLIBCXX_LIBS="$GLIBCXX_LIBS $ac_cv_search_sched_yield"
 ac_has_sched_yield=yes
 ;;
 -lrt*)
 if test x"$enable_libstdcxx_time" = x"rt"; then
GLIBCXX_LIBS="$GLIBCXX_LIBS $ac_cv_search_sched_yield"
   ac_has_sched_yield=yes
 fi
 ;;
 *)
 ac_has_sched_yield=yes
 ;;
   esac

But in practice the snippet above is only used if you explicitly
configure with --enable-libstdcxx-time={yes,rt} and will only add
anything to GLIBCXX_LIBS if clock_gettime or nanosleep lives in one of
librt or libposix4. I think libposix4 is Solaris-specific, and I don't
think Darwin has librt. So in practice I don't think there's a
problem on Darwin today.


Agreed, neither of those libs is currently in use on Darwin.

There have, in some cases, been library entries that are simply a symlink to
the one providing the equivalent functionality, to minimize cross-platform  
build

hassles - but I see no entry for librt.dylib or posix4.

thanks
Iain




Re: [PATCH] warn for more impossible null pointer tests

2021-09-01 Thread Iain Sandoe via Gcc-patches
Hi Paul,

> On 1 Sep 2021, at 20:28, Koning, Paul via Gcc-patches 
>  wrote:
> 
>> On Sep 1, 2021, at 3:08 PM, Jeff Law via Gcc-patches 
>>  wrote:
>> On 9/1/2021 12:57 PM, Koning, Paul wrote:
>>> 
 On Sep 1, 2021, at 1:35 PM, Jeff Law via Gcc-patches 
  wrote:
 
 Generally OK.  There's some C++ front-end bits that Jason ought to take a 
 quick looksie at.   Second, how does this interact with targets that allow 
 objects at address 0?   We have a few targets like that and that makes me 
 wonder if we should be suppressing some, if not all, of these warnings for 
 targets that turn on -fno-delete-null-pointer-checks?
>>> But in C, the pointer constant 0 represents the null (invalid) pointer, not 
>>> the actual address zero necessarily.
>>> 
>>> If a target supports objects at address zero, how does it represent the 
>>> pointer value 0 (which we usually refer to as NULL)?  Is the issue simply 
>>> ignored?  It seems to me it is in pdp11, which I would guess is one of the 
>>> targets for which objects at address 0 make sense.
>> The issue is ignored to the best of my knowledge.
> 
> If so, then I would think that ignoring it for this patch as well is 
> reasonable.  If in a given target a pointer that C thinks of as NULL is in 
> fact a valid object pointer, then all sorts of optimizations are incorrect.  
> If the target really cares, it can use a different representation for the 
> null pointer.  (Does GCC give us a way to do that?)  For example, pdp11 could 
> use the all-ones bit pattern to represent an invalid pointer.

regardless of whether GCC supports it or not - trying to use a non-0 NULL 
pointer is likely to break massive amounts of code in the wild.

It might, OTOH, be possible to use a non-0 special value to represent the valid 
0 address-use (providing that there is somewhere in the address space you can 
steal that from).

I wonder what things like m68k do that have vector tables at 0 …

Iain



Re: [PATCH V3 0/6] Initial support for AVX512FP16

2021-09-02 Thread Iain Sandoe via Gcc-patches
Hi Hongtao.

> On 2 Sep 2021, at 07:06, Hongtao Liu via Gcc-patches 
>  wrote:
> 
> I'm going to check in the first 3 patches which are already approved.
> 
>  Update hf soft-fp from glibc.
>  [i386] Enable _Float16 type for TARGET_SSE2 and above.
>  [i386] libgcc: Enable hfmode soft-sf/df/xf/tf extensions and
>truncations.

Bootstrap on Darwin x86_64 is broken on at least AVX512 and i5 cpus at revision
r12-3311-g1e6267b33526.

"fp-machine.h:81:22: error: unknown type name 'TFtype'; did you mean 'HFtype’?”

any immediate ideas on what might be the issue?
thanks
Iain

> 
> On Mon, Aug 2, 2021 at 2:31 PM liuhongt  wrote:
>> 
>> Update from v2:
>> 
>> 1. Support -fexcess-precision=16 which will enable
>> FLT_EVAL_METHOD_PROMOTE_TO_FLOAT16 when backend supports _Float16.
>> 2. Update ix86_get_excess_precision, so -fexcess-precision=standard
>> should not do anything different from -fexcess-precision=fast
>> regarding _Float16.
>> 3. Avoiding macroization of HFmode patterns.
>> 4. Allow (subreg:SI (reg:HF)).
>> 5. Update documents corresponding exactly to the code changes in
>> the same patch.
>> 6. According to 32bit abi, pass vector _Float16 by sse registers
>> for 32-bit mode, not stack.
>> 
>> Guo, Xuepeng (1):
>>  AVX512FP16: Initial support for AVX512FP16 feature and scalar _Float16
>>instructions.
>> 
>> liuhongt (5):
>>  Update hf soft-fp from glibc.
>>  [i386] Enable _Float16 type for TARGET_SSE2 and above.
>>  [i386] libgcc: Enable hfmode soft-sf/df/xf/tf extensions and
>>truncations.
>>  Support -fexcess-precision=16 which will enable
>>FLT_EVAL_METHOD_PROMOTE_TO_FLOAT16 when backend supports _Float16.
>>  AVX512FP16: Support vector init/broadcast/set/extract for FP16.
>> 
>> gcc/ada/gcc-interface/misc.c  |   3 +
>> gcc/c-family/c-common.c   |   6 +-
>> gcc/c-family/c-cppbuiltin.c   |   6 +-
>> gcc/common.opt|   5 +-
>> gcc/common/config/i386/cpuinfo.h  |   2 +
>> gcc/common/config/i386/i386-common.c  |  26 +-
>> gcc/common/config/i386/i386-cpuinfo.h |   1 +
>> gcc/common/config/i386/i386-isas.h|   1 +
>> gcc/config.gcc|   2 +-
>> gcc/config/aarch64/aarch64.c  |   1 +
>> gcc/config/arm/arm.c  |   1 +
>> gcc/config/i386/avx512fp16intrin.h| 225 ++
>> gcc/config/i386/cpuid.h   |   1 +
>> gcc/config/i386/i386-builtin-types.def|   7 +-
>> gcc/config/i386/i386-builtins.c   |  23 +
>> gcc/config/i386/i386-c.c  |   2 +
>> gcc/config/i386/i386-expand.c | 129 +-
>> gcc/config/i386/i386-isa.def  |   1 +
>> gcc/config/i386/i386-modes.def|  13 +-
>> gcc/config/i386/i386-options.c|   4 +-
>> gcc/config/i386/i386.c| 243 +--
>> gcc/config/i386/i386.h|  29 +-
>> gcc/config/i386/i386.md   | 291 -
>> gcc/config/i386/i386.opt  |   4 +
>> gcc/config/i386/immintrin.h   |   4 +
>> gcc/config/i386/sse.md| 397 +-
>> gcc/config/m68k/m68k.c|   2 +
>> gcc/config/s390/s390.c|   2 +
>> gcc/coretypes.h   |   3 +-
>> gcc/doc/extend.texi   |  22 +
>> gcc/doc/invoke.texi   |  10 +-
>> gcc/doc/tm.texi   |  14 +-
>> gcc/doc/tm.texi.in|   3 +
>> gcc/emit-rtl.c|   5 +
>> gcc/flag-types.h  |   3 +-
>> gcc/fortran/options.c |   3 +
>> gcc/lto/lto-lang.c|   3 +
>> gcc/target.def|  11 +-
>> gcc/testsuite/g++.dg/other/i386-2.C   |   2 +-
>> gcc/testsuite/g++.dg/other/i386-3.C   |   2 +-
>> gcc/testsuite/g++.target/i386/float16-1.C |   8 +
>> gcc/testsuite/g++.target/i386/float16-2.C |  14 +
>> gcc/testsuite/g++.target/i386/float16-3.C |  10 +
>> gcc/testsuite/gcc.target/i386/avx-1.c |   2 +-
>> gcc/testsuite/gcc.target/i386/avx-2.c |   2 +-
>> gcc/testsuite/gcc.target/i386/avx512-check.h  |   3 +
>> .../gcc.target/i386/avx512fp16-12a.c  |  21 +
>> .../gcc.target/i386/avx512fp16-12b.c  |  27 ++
>> gcc/testsuite/gcc.target/i386/float16-3a.c|  10 +
>> gcc/testsuite/gcc.target/i386/float16-3b.c|  10 +
>> gcc/testsuite/gcc.target/i386/float16-4a.c|  10 +
>> gcc/testsuite/gcc.target/i386/float16-4b.c|  10 +
>> gcc/testsuite/gcc.target/i386/float16-5.c |  12 +
>> gcc/testsuite/gcc.target/i386/float16-6.c |   8 +
>> gcc/testsuite/gcc.target/i386/funcspec-56.inc |   2 +
>> gcc/testsuite/gcc.target/i386/pr54855-12.c|  14 +
>> gcc/test

Re: [PATCH V3 0/6] Initial support for AVX512FP16

2021-09-02 Thread Iain Sandoe via Gcc-patches
Patch below fixes bootstrap,

OK if it passes testing on x86_64 darwin/linux?
(if !OK .. then suggestions welcome)

thanks
Iain

> On 2 Sep 2021, at 16:18, Hongtao Liu  wrote:
> 
> 
> 
> On Thursday, September 2, 2021, Iain Sandoe  wrote:
> Hi Hongtao.
> 
> > On 2 Sep 2021, at 07:06, Hongtao Liu via Gcc-patches 
> >  wrote:
> > 
> > I'm going to check in the first 3 patches which are already approved.
> > 
> >  Update hf soft-fp from glibc.
> >  [i386] Enable _Float16 type for TARGET_SSE2 and above.
> >  [i386] libgcc: Enable hfmode soft-sf/df/xf/tf extensions and
> >truncations.
> 
> Bootstrap on Darwin x86_64 is broken on at least AVX512 and i5 cpus at 
> revision
> r12-3311-g1e6267b33526.
> 
> "fp-machine.h:81:22: error: unknown type name 'TFtype'; did you mean 
> 'HFtype’?”
> 
> any immediate ideas on what might be the issue?
> thanks
>  
> Seems to be related to the belowpart which is not changed by my patch, and 
> TFtype is defined in quad.h
> 
>  76 /* Define ALIASNAME as a strong alias for NAME.  */
>   77 #if defined __MACH__
>   78 /* Mach-O doesn't support aliasing.  If these functions ever return
>   79anything but CMPtype we need to revisit this... */
>   80 #define strong_alias(name, aliasname) \
>   81   CMPtype aliasname (TFtype a, TFtype b) { return name(a, b); }
>   82 #else
> 
> Would you try to add
> typedef float TFtype __attribute__ ((mode (TF))); 
> Here to see if it fixes the issue.

I don’t think it’s  quite as simple as that - this is what I’m testing:

[PATCH] libgcc, soft-float: Fix strong_alias macro use for Darwin.

Darwin does not support strong symbol aliases and a work-
around is provided in sfp-machine.h where a second function
is created that simply calls the original.  However this
needs the arguments to the synthesized function to track
the mode of the original function.

So the fix here is to adjust the macro to allow the mode to
be provided and then to set it as needed before the header
is included.

Signed-off-by: Iain Sandoe 

libgcc/ChangeLog:

* config/i386/sfp-exceptions.c (DarwinMode): Set
arbitrarily to DF mode (the strong_alias macros is
not used here).
* config/i386/sfp-machine.h: Adjust strong_alias macro
so that the type can be provided per case.
* soft-fp/eqdf2.c (DarwinMode): Set to DF mode.
* soft-fp/eqhf2.c (DarwinMode): Set to HF mode.
* soft-fp/eqsf2.c (DarwinMode): Set to SF mode.
* soft-fp/eqtf2.c (DarwinMode): Set to TF mode.
* soft-fp/gedf2.c (DarwinMode): Set to DF mode.
* soft-fp/gesf2.c (DarwinMode): Set to SF mode.
* soft-fp/getf2.c (DarwinMode): Set to TF mode.
* soft-fp/ledf2.c (DarwinMode): Set to DF mode.
* soft-fp/lesf2.c (DarwinMode): Set to SF mode.
* soft-fp/letf2.c (DarwinMode): Set to TF mode.
---
 libgcc/config/i386/sfp-exceptions.c | 1 +
 libgcc/config/i386/sfp-machine.h| 9 ++---
 libgcc/soft-fp/eqdf2.c  | 1 +
 libgcc/soft-fp/eqhf2.c  | 1 +
 libgcc/soft-fp/eqsf2.c  | 1 +
 libgcc/soft-fp/eqtf2.c  | 1 +
 libgcc/soft-fp/gedf2.c  | 1 +
 libgcc/soft-fp/gesf2.c  | 1 +
 libgcc/soft-fp/getf2.c  | 1 +
 libgcc/soft-fp/ledf2.c  | 1 +
 libgcc/soft-fp/lesf2.c  | 1 +
 libgcc/soft-fp/letf2.c  | 1 +
 12 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/libgcc/config/i386/sfp-exceptions.c 
b/libgcc/config/i386/sfp-exceptions.c
index edb6a57bb35..7431cf93e33 100644
--- a/libgcc/config/i386/sfp-exceptions.c
+++ b/libgcc/config/i386/sfp-exceptions.c
@@ -22,6 +22,7 @@
  */
 
 #ifndef _SOFT_FLOAT
+#define DarwinMode DF
 #include "sfp-machine.h"
 
 struct fenv
diff --git a/libgcc/config/i386/sfp-machine.h b/libgcc/config/i386/sfp-machine.h
index f15d29d3755..2cb6119b8f8 100644
--- a/libgcc/config/i386/sfp-machine.h
+++ b/libgcc/config/i386/sfp-machine.h
@@ -75,10 +75,13 @@ void __sfp_handle_exceptions (int);
 
 /* Define ALIASNAME as a strong alias for NAME.  */
 #if defined __MACH__
-/* Mach-O doesn't support aliasing.  If these functions ever return
-   anything but CMPtype we need to revisit this... */
+/* Mach-O doesn't support aliasing, so we build a secondary function for
+   the alias - this needs the type of the arguments to be provided as
+   DarwinFtype.  If these functions ever return anything but CMPtype
+   we need to revisit this... */
 #define strong_alias(name, aliasname) \
-  CMPtype aliasname (TFtype a, TFtype b) { return name(a, b); }
+  typedef float DarwinFtype __attribute__((mode (DarwinMode))); \
+  CMPtype aliasname (DarwinFtype a, DarwinFtype b) { return name(a, b); }
 #else
 # define strong_alias(name, aliasname) _strong_alias(name, aliasname)
 # define _strong_alias(name, aliasname) \
diff --git a/libgcc/soft-fp/eqdf2.c b/libgcc/soft-fp/eqdf2.c
index 2a44ee377ce..a3bb664f5f1 100644
--- a/libgcc/soft-fp/eqdf2.c
+++ b/libgcc/soft-fp/eqdf2.c
@@ -28,6 +28,7 @@
Lic

Re: [PATCH V3 0/6] Initial support for AVX512FP16

2021-09-03 Thread Iain Sandoe via Gcc-patches
Hi Joseph,

> On 2 Sep 2021, at 21:03, Joseph Myers  wrote:
> 
> On Thu, 2 Sep 2021, Iain Sandoe via Gcc-patches wrote:
> 
>> diff --git a/libgcc/soft-fp/eqdf2.c b/libgcc/soft-fp/eqdf2.c
>> index 2a44ee377ce..a3bb664f5f1 100644
>> --- a/libgcc/soft-fp/eqdf2.c
>> +++ b/libgcc/soft-fp/eqdf2.c
>> @@ -28,6 +28,7 @@
>>License along with the GNU C Library; if not, see
>><http://www.gnu.org/licenses/>.  */
>> 
>> +#define DarwinMode DF
>> #include "soft-fp.h"
>> #include "double.h"
> 
> All these files are supposed to be taken unmodified from glibc.  They 
> shouldn't contain any OS-specific code, such as a define of DarwinMode.  
> sfp-machine.h, however, is libgcc-local, hence putting the definition of 
> strong_alias there.

OK, that makes sense.
> 
> So you need some other way to extract the argument type of name in order 
> to use it in a declaration of aliasname.  E.g.
> 
> __typeof (_Generic (name,
>CMPtype (*) (HFtype, HFtype): (HFtype) 0,
>CMPtype (*) (SFtype, SFtype): (SFtype) 0,
>CMPtype (*) (DFtype, DFtype): (DFtype) 0,
>CMPtype (*) (TFtype, TFtype): (TFtype) 0))

thanks for the suggestion

> Now in fact I think the include ordering means none of the *type macros 
> are defined here.  But if you do e.g.
> 
> typedef float alias_SFtype __attribute__ ((mode (SF)));
> 
> and similar, you could use alias_SFtype in the above.  And so keep the 
> changes to the Darwin-specific parts of the libgcc-local sfp-machine.h.

this is what I’m testing - OK if it bootstraps on x86_64-darwin, linux?

thanks
Iain


[PATCH] libgcc, soft-float: Fix strong_alias macro use for Darwin.

Darwin does not support strong symbol aliases and a work-
around is provided in sfp-machine.h where a second function
is created that simply calls the original.  However this
needs the arguments to the synthesized function to track
the mode of the original function.

So the fix here is to match known floating point modes from
the incoming function and apply the one found to the new
function args.

The matching is highly specific to the current set of modes
and will need adjusting should more cases be added.

Signed-off-by: Iain Sandoe 

libgcc/ChangeLog:

* config/i386/sfp-machine.h (alias_HFtype, alias_SFtype
alias_DFtype, alias_TFtype): New.
(ALIAS_SELECTOR): New.
(strong_alias): Use __typeof and a _Generic selector to
provide the type to the synthesized function.
---
 libgcc/config/i386/sfp-machine.h | 20 +---
 1 file changed, 17 insertions(+), 3 deletions(-)

diff --git a/libgcc/config/i386/sfp-machine.h b/libgcc/config/i386/sfp-machine.h
index f15d29d3755..172ebc70c8d 100644
--- a/libgcc/config/i386/sfp-machine.h
+++ b/libgcc/config/i386/sfp-machine.h
@@ -75,10 +75,24 @@ void __sfp_handle_exceptions (int);
 
 /* Define ALIASNAME as a strong alias for NAME.  */
 #if defined __MACH__
-/* Mach-O doesn't support aliasing.  If these functions ever return
-   anything but CMPtype we need to revisit this... */
+/* Mach-O doesn't support aliasing, so we build a secondary function for
+   the alias - we need to do a bit of a dance to find out what the type of
+   the arguments is and then apply that to the secondary function.
+   If these functions ever return anything but CMPtype we need to revisit
+   this... */
+typedef float alias_HFtype __attribute__ ((mode (HF)));
+typedef float alias_SFtype __attribute__ ((mode (SF)));
+typedef float alias_DFtype __attribute__ ((mode (DF)));
+typedef float alias_TFtype __attribute__ ((mode (TF)));
+#define ALIAS_SELECTOR \
+  CMPtype (*) (alias_HFtype, alias_HFtype): (alias_HFtype) 0, \
+  CMPtype (*) (alias_SFtype, alias_SFtype): (alias_SFtype) 0, \
+  CMPtype (*) (alias_DFtype, alias_DFtype): (alias_DFtype) 0, \
+  CMPtype (*) (alias_TFtype, alias_TFtype): (alias_TFtype) 0
 #define strong_alias(name, aliasname) \
-  CMPtype aliasname (TFtype a, TFtype b) { return name(a, b); }
+  CMPtype aliasname (__typeof (_Generic (name, ALIAS_SELECTOR)) a, \
+__typeof (_Generic (name, ALIAS_SELECTOR)) b) \
+   { return name (a, b); }
 #else
 # define strong_alias(name, aliasname) _strong_alias(name, aliasname)
 # define _strong_alias(name, aliasname) \
-- 



Re: [PATCH] Explicitly add -msse2 to compile HF related libgcc source file.

2021-09-03 Thread Iain Sandoe via Gcc-patches



> On 3 Sep 2021, at 10:00, Jakub Jelinek via Gcc-patches 
>  wrote:
> 
> On Fri, Sep 03, 2021 at 03:41:13PM +0800, liuhongt via Gcc-patches wrote:
>> --- a/libgcc/config/i386/64/t-softfp
>> +++ b/libgcc/config/i386/64/t-softfp
>> @@ -1 +1,6 @@
>> softfp_extras := fixhfti fixunshfti floattihf floatuntihf
>> +
>> +CFLAGS-fixhfti.c += -msse2
>> +CFLAGS-fixunshfti.c += -msse2
>> +CFLAGS-floattihf.c += -msse2
>> +CFLAGS-floatunstihf.c += -msse2
>> \ No newline at end of file
> 
> Please avoid this.
> 
>> --- a/libgcc/config/i386/t-softfp
>> +++ b/libgcc/config/i386/t-softfp
>> @@ -1,6 +1,38 @@
>> LIB2ADD += $(srcdir)/config/i386/sfp-exceptions.c
>> 
>> +# Replace _divhc3 and _mulhc3.
>> +libgcc2-hf-functions = _divhc3 _mulhc3
>> +LIB2FUNCS_EXCLUDE += $(libgcc2-hf-functions)
>> +libgcc2-hf-extras = $(addsuffix .c, $(libgcc2-hf-functions))
>> +LIB2ADD_ST += $(addprefix $(srcdir)/config/i386/, $(libgcc2-hf-extras))
>> +
>> softfp_extensions := hfsf hfdf hftf hfxf sfdf sftf dftf xftf
>> softfp_truncations := tfhf xfhf dfhf sfhf tfsf dfsf tfdf tfxf
>> 
>> -softfp_extras += eqhf2
>> \ No newline at end of file
>> +softfp_extras += eqhf2
>> +
>> +CFLAGS-extendhfsf2.c += -msse2
>> +CFLAGS-extendhfdf2.c += -msse2
>> +CFLAGS-extendhftf2.c += -msse2
>> +CFLAGS-extendhfxf2.c += -msse2
>> +
>> +CFLAGS-extendsfdf2.c += -msse2
>> +CFLAGS-extendsftf2.c += -msse2
>> +
>> +CFLAGS-extenddftf2.c += -msse2
>> +CFLAGS-extendxftf2.c += -msse2
> 
> Aren't the [sdxt]f<->[sdxt]f extend/trunc conversions in libgcc for
> quite a while?  If so, using -msse2 for those seems wrong, it is fine
> if we require -msse2 support for anything that uses HF or HC mode
> types, but if just trying to convert other types it should work even on
> just i386 or i486.
> 
>> +
>> +CFLAGS-truncsfhf2.c += -msse2
>> +CFLAGS-truncdfhf2.c += -msse2
>> +CFLAGS-truncxfhf2.c += -msse2
>> +CFLAGS-trunctfhf2.c += -msse2
>> +
>> +CFLAGS-truncdfsf2.c += -msse2
>> +CFLAGS-trunctfsf2.c += -msse2
>> +
>> +CFLAGS-trunctfdf2.c += -msse2
>> +CFLAGS-trunctfxf2.c += -msse2
>> +
>> +CFLAGS-eqhf2.c += -msse2
>> +CFLAGS-_divhc3.c += -msse2
>> +CFLAGS-_mulhc3.c += -msse2
>> \ No newline at end of file
> 
> See above.
> 
> Also, shouldn't the *hf* and *hc* APIs be exported from libgcc_s.so.1?
> 
>   254: 00011960   968 FUNCLOCAL  DEFAULT   13 __floattihf
>   256: 000116f0   315 FUNCLOCAL  DEFAULT   13 __fixhfti
>   263: f950  1358 FUNCLOCAL  DEFAULT   13 __truncsfhf2
>   264: db10   272 FUNCLOCAL  DEFAULT   13 __extendhfsf2
>   265: df70   399 FUNCLOCAL  DEFAULT   13 __extendhfxf2
>   267: 00011fe0   469 FUNCLOCAL  DEFAULT   13 __eqhf2
>   268: 00011d30   681 FUNCLOCAL  DEFAULT   13 __floatuntihf
>   271: dc20   374 FUNCLOCAL  DEFAULT   13 __extendhfdf2
>   274: 00011830   292 FUNCLOCAL  DEFAULT   13 __fixunshfti
>   281: dda0   460 FUNCLOCAL  DEFAULT   13 __extendhftf2
>   283: e860  1439 FUNCLOCAL  DEFAULT   13 __trunctfhf2
>   285: 00011fe0   469 FUNCLOCAL  DEFAULT   13 __nehf2
>   286: 6290  1627 FUNCLOCAL  DEFAULT   13 __divhc3
>   290: ee00  1499 FUNCLOCAL  DEFAULT   13 __truncxfhf2
>   292: f3e0  1392 FUNCLOCAL  DEFAULT   13 __truncdfhf2
>   296: 5150  1931 FUNCLOCAL  DEFAULT   13 __mulhc3
> 
> So, don't we want GCC_12.0 with those symbols
> in config/i386/libgcc-glibc.ver and perhaps others?

this works for me on Darwin - I didn’t try it on Linux so far though (and didn’t
look at solaris etc. which have thier own sym maps).

---

diff --git a/libgcc/libgcc-std.ver.in b/libgcc/libgcc-std.ver.in
index cea33267e53..f5c1bc1aa6c 100644
--- a/libgcc/libgcc-std.ver.in
+++ b/libgcc/libgcc-std.ver.in
@@ -1944,3 +1944,21 @@ GCC_7.0.0 {
   __PFX__divmoddi4
   __PFX__divmodti4
 }
+
+%inherit GCC_12.0.0 GCC_7.0.0
+ GCC_12.0.0 {
+  __PFX__eqhf2
+  __PFX__extendhfdf2
+  __PFX__extendhfsf2
+  __PFX__extendhftf2
+  __PFX__extendhfxf2
+  __PFX__fixhfti
+  __PFX__fixunshfti
+  __PFX__floattihf
+  __PFX__floatuntihf
+  __PFX__nehf2
+  __PFX__truncdfhf2
+  __PFX__truncsfhf2
+  __PFX__trunctfhf2
+  __PFX__truncxfhf2
+}



Re: [PATCH] Explicitly add -msse2 to compile HF related libgcc source file.

2021-09-03 Thread Iain Sandoe via Gcc-patches



> On 3 Sep 2021, at 13:33, Jakub Jelinek via Gcc-patches 
>  wrote:
> 
> On Fri, Sep 03, 2021 at 01:32:14PM +0100, Iain Sandoe via Gcc-patches wrote:
>> diff --git a/libgcc/libgcc-std.ver.in b/libgcc/libgcc-std.ver.in
>> index cea33267e53..f5c1bc1aa6c 100644
>> --- a/libgcc/libgcc-std.ver.in
>> +++ b/libgcc/libgcc-std.ver.in
>> @@ -1944,3 +1944,21 @@ GCC_7.0.0 {
>>   __PFX__divmoddi4
>>   __PFX__divmodti4
>> }
>> +
>> +%inherit GCC_12.0.0 GCC_7.0.0
>> + GCC_12.0.0 {
>> +  __PFX__eqhf2
>> +  __PFX__extendhfdf2
>> +  __PFX__extendhfsf2
>> +  __PFX__extendhftf2
>> +  __PFX__extendhfxf2
>> +  __PFX__fixhfti
>> +  __PFX__fixunshfti
>> +  __PFX__floattihf
>> +  __PFX__floatuntihf
>> +  __PFX__nehf2
>> +  __PFX__truncdfhf2
>> +  __PFX__truncsfhf2
>> +  __PFX__trunctfhf2
>> +  __PFX__truncxfhf2
>> +}
> 
> No *hc* entrypoints?

oops EWRONGPATCH

diff --git a/libgcc/libgcc-std.ver.in b/libgcc/libgcc-std.ver.in
index cea33267e53..902a9364850 100644
--- a/libgcc/libgcc-std.ver.in
+++ b/libgcc/libgcc-std.ver.in
@@ -1944,3 +1944,23 @@ GCC_7.0.0 {
   __PFX__divmoddi4
   __PFX__divmodti4
 }
+
+%inherit GCC_12.0.0 GCC_7.0.0
+ GCC_12.0.0 {
+  __PFX__divhc3
+  __PFX__mulhc3
+  __PFX__eqhf2
+  __PFX__extendhfdf2
+  __PFX__extendhfsf2
+  __PFX__extendhftf2
+  __PFX__extendhfxf2
+  __PFX__fixhfti
+  __PFX__fixunshfti
+  __PFX__floattihf
+  __PFX__floatuntihf
+  __PFX__nehf2
+  __PFX__truncdfhf2
+  __PFX__truncsfhf2
+  __PFX__trunctfhf2
+  __PFX__truncxfhf2
+}




Re: [PATCH] Explicitly add -msse2 to compile HF related libgcc source file.

2021-09-06 Thread Iain Sandoe via Gcc-patches



> On 6 Sep 2021, at 08:08, Jakub Jelinek via Gcc-patches 
>  wrote:
> 
> On Mon, Sep 06, 2021 at 09:42:32AM +0800, Hongtao Liu wrote:
>>> Also, shouldn't the *hf* and *hc* APIs be exported from libgcc_s.so.1?
>>> 
>>>   254: 00011960   968 FUNCLOCAL  DEFAULT   13 __floattihf
>>>   256: 000116f0   315 FUNCLOCAL  DEFAULT   13 __fixhfti
>>>   263: f950  1358 FUNCLOCAL  DEFAULT   13 __truncsfhf2
>>>   264: db10   272 FUNCLOCAL  DEFAULT   13 __extendhfsf2
>>>   265: df70   399 FUNCLOCAL  DEFAULT   13 __extendhfxf2
>>>   267: 00011fe0   469 FUNCLOCAL  DEFAULT   13 __eqhf2
>>>   268: 00011d30   681 FUNCLOCAL  DEFAULT   13 __floatuntihf
>>>   271: dc20   374 FUNCLOCAL  DEFAULT   13 __extendhfdf2
>>>   274: 00011830   292 FUNCLOCAL  DEFAULT   13 __fixunshfti
>>>   281: dda0   460 FUNCLOCAL  DEFAULT   13 __extendhftf2
>>>   283: e860  1439 FUNCLOCAL  DEFAULT   13 __trunctfhf2
>>>   285: 00011fe0   469 FUNCLOCAL  DEFAULT   13 __nehf2
>>>   286: 6290  1627 FUNCLOCAL  DEFAULT   13 __divhc3
>>>   290: ee00  1499 FUNCLOCAL  DEFAULT   13 __truncxfhf2
>>>   292: f3e0  1392 FUNCLOCAL  DEFAULT   13 __truncdfhf2
>>>   296: 5150  1931 FUNCLOCAL  DEFAULT   13 __mulhc3
>>> 
>>> So, don't we want GCC_12.0 with those symbols
>>> in config/i386/libgcc-glibc.ver and perhaps others?
>>> 
>>>Jakub
>>> 
>> 
>> Here is an updated patch.
> 
> Ok.  The *.ver changes are still needed (see above), but that can be done
> incrementally.

I can commit the .ver change if that’s approved, sure - for the record I 
haven’t checked
any targets other than Darwin and Linux.

Iain



Re: [PATCH] testsuite: Fix c-c++-common/auto-init-* tests

2021-09-16 Thread Iain Sandoe via Gcc-patches



> On 16 Sep 2021, at 18:11, Qing Zhao via Gcc-patches  
> wrote:
> 
> 
> 
>> On Sep 16, 2021, at 10:47 AM, Jakub Jelinek  wrote:
>> 
>> On Thu, Sep 16, 2021 at 03:39:46PM +, Qing Zhao wrote:
 Even -mtune= is needed if you want to stay safe, otherwise people testing
 with --target_board=unix/-mtune=cascadelake (or whatever else) might get
 failures.
>>> 
>>> Okay. Will try this.
 
>> and ideally also -fno-stack-protector
>> -fno-stack-clash-protection etc.
> 
> Could you explain a little bit on this why?
 
 In case people test e.g. with 
 --target_board=unix/\{,-fstack-protector-all\}
 etc. (e.g. in Fedora/RHEL we do).
 For the RTL scanning checks if they are done fairly early, those options
 might not change anything, but with the ones scanning in the assembly,
 one needs to watch if those options don't add e.g. in the prologue or
 epilogue further copies of the instructions you scan for.
>>> 
>>> I see. 
>>> 
>>> Thank you.
>> 
>> Basically, try to test with a bunch of semi-randomly chosen option sets and
>> see what breaks and what works and then for the cases you think are common
>> enough and worth adjusting testcases adjust them, otherwise add dg-options
>> to make sure the expected arch/tune/etc. are in effect.
>> make check-gcc 
>> RUNTESTFLAGS='--target_board=unix\{-m64,-m64/-march=skylake-avx512,-m64/-fstack-protector-all,-m64/-fstack-clash-protection,-m32/-mno-sse,-m32/-mtune=bonnell,-m32/-march=bonnell,-m32/-fstack-protector-all/-fstack-clash-protection\}
>>  i386.exp=auto-init*'
> 
> Thanks a lot for the suggestions and help, I will try this.

I might suggest adding -fPIC or -fpic to the mix too (if it’s relevant to the 
tests) there are quite a few testcases that fail when run on Darwin (or HJ’s 
pic tester versions) because of the difference in code-gen.
Iain

> 
> Qing
>> etc.
>> 
>>  Jakub



[PATCH] coroutines: Only set parm copy guard vars if we have exceptions [PR 102454].

2021-09-27 Thread Iain Sandoe via Gcc-patches
For coroutines, we make copies of the original function arguments into
the coroutine frame.  Normally, these are destroyed on the proper exit
from the coroutine when the frame is destroyed.

However, if an exception is thrown before the first suspend point is
reached, the cleanup has to happen in the ramp function.  These cleanups
are guarded such that they are only applied to any param copies actually
made.

The ICE is caused by an attempt to set the guard variable when there are
no exceptions enabled (the guard var is not created in this case).

Fixed by checking for flag_exceptions in this case too.

While touching this code paths, also clean up the synthetic names used
when a function parm is unnamed.

tested on x86_64-darwin,
OK for master?
thanks
Iain

Signed-off-by: Iain Sandoe 

PR c++/102454

gcc/cp/ChangeLog:

* coroutines.cc (analyze_fn_parms): Clean up synthetic names for
unnamed function params.
(morph_fn_to_coro): Do not try to set a guard variable for param
DTORs in the ramp, unless we have exceptions active.

gcc/testsuite/ChangeLog:

* g++.dg/coroutines/pr102454.C: New test.
---
 gcc/cp/coroutines.cc   | 26 ---
 gcc/testsuite/g++.dg/coroutines/pr102454.C | 38 ++
 2 files changed, 52 insertions(+), 12 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/coroutines/pr102454.C

diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
index fbd5c49533f..c761e769c12 100644
--- a/gcc/cp/coroutines.cc
+++ b/gcc/cp/coroutines.cc
@@ -3829,13 +3829,12 @@ analyze_fn_parms (tree orig)
 
   if (TYPE_HAS_NONTRIVIAL_DESTRUCTOR (parm.frame_type))
{
- char *buf = xasprintf ("_Coro_%s_live", IDENTIFIER_POINTER (name));
- parm.guard_var = build_lang_decl (VAR_DECL, get_identifier (buf),
-   boolean_type_node);
- free (buf);
- DECL_ARTIFICIAL (parm.guard_var) = true;
- DECL_CONTEXT (parm.guard_var) = orig;
- DECL_INITIAL (parm.guard_var) = boolean_false_node;
+ char *buf = xasprintf ("%s%s_live", DECL_NAME (arg) ? "_Coro_" : "",
+IDENTIFIER_POINTER (name));
+ parm.guard_var
+   = coro_build_artificial_var (UNKNOWN_LOCATION, get_identifier (buf),
+boolean_type_node, orig,
+boolean_false_node);
  parm.trivial_dtor = false;
}
   else
@@ -4843,11 +4842,14 @@ morph_fn_to_coro (tree orig, tree *resumer, tree 
*destroyer)
 NULL, parm.frame_type,
 LOOKUP_NORMAL,
 tf_warning_or_error);
- /* This var is now live.  */
- r = build_modify_expr (fn_start, parm.guard_var,
-boolean_type_node, INIT_EXPR, fn_start,
-boolean_true_node, boolean_type_node);
- finish_expr_stmt (r);
+ if (flag_exceptions)
+   {
+ /* This var is now live.  */
+ r = build_modify_expr (fn_start, parm.guard_var,
+boolean_type_node, INIT_EXPR, fn_start,
+boolean_true_node, boolean_type_node);
+ finish_expr_stmt (r);
+   }
}
}
 }
diff --git a/gcc/testsuite/g++.dg/coroutines/pr102454.C 
b/gcc/testsuite/g++.dg/coroutines/pr102454.C
new file mode 100644
index 000..41aeda7b973
--- /dev/null
+++ b/gcc/testsuite/g++.dg/coroutines/pr102454.C
@@ -0,0 +1,38 @@
+//  { dg-additional-options "-fno-exceptions" }
+
+#include 
+#include 
+
+template 
+struct looper {
+  struct promise_type {
+auto get_return_object () { return handle_type::from_promise (*this); }
+auto initial_suspend () { return suspend_always_prt {}; }
+auto final_suspend () noexcept { return suspend_always_prt {}; }
+void return_value (T);
+void unhandled_exception ();
+  };
+
+  using handle_type = std::coroutine_handle;
+
+  looper (handle_type);
+
+  struct suspend_always_prt {
+bool await_ready () noexcept;
+void await_suspend (handle_type) noexcept;
+void await_resume () noexcept;
+  };
+};
+
+template 
+looper
+with_ctorable_state (T)
+{
+  co_return T ();
+}
+
+auto
+foo ()
+{
+  return with_ctorable_state;
+}
-- 
2.24.3 (Apple Git-128)



[pushed] libgcc, X86, Darwin: Export cpu_model and indicator.

2021-09-28 Thread Iain Sandoe via Gcc-patches
Hi,

These two symbols have been emitted since 4.8, but were not added
to the Darwin exports, so we have been using the ones from libgcc.a.

Added to libgcc_s now.

tested on i686 and x86_64-darwin, pushed to master,
thanks
Iain

Signed-off-by: Iain Sandoe 

libgcc/ChangeLog:

* config/i386/libgcc-darwin.ver: Add Symbols for
__cpu_model, __cpu_indicator_init.
---
 libgcc/config/i386/libgcc-darwin.ver | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/libgcc/config/i386/libgcc-darwin.ver 
b/libgcc/config/i386/libgcc-darwin.ver
index 5224cdc982e..c97dae73855 100644
--- a/libgcc/config/i386/libgcc-darwin.ver
+++ b/libgcc/config/i386/libgcc-darwin.ver
@@ -1,4 +1,7 @@
-
+GCC_4.8.0 {
+  __cpu_model
+  __cpu_indicator_init
+}
 
 %inherit GCC_12.0.0 GCC_7.0.0
 GCC_12.0.0 {
-- 
2.24.3 (Apple Git-128)



[pushed] Darwin, PPC : Fix R13 for PPC64.

2021-09-28 Thread Iain Sandoe via Gcc-patches
Hi,

We have a somewhat unusual situation in that for PPC64, R13 is
both reserved for future use by the ABI document and callee-saved.
In fact, it is already  used internally by the pthreads
implementation to contain pthread_self.

So add R13 to the fixed regs, but also keep it in the callee-
saved set.

tested on powerpc-darwin9, pushed to master,
thanks
Iain

gcc/ChangeLog:

* config/rs6000/darwin.h (FIXED_R13): Add for PPC64.
(FIRST_SAVED_GP_REGNO): Save from R13 even when it is one
of the fixed regs.
---
 gcc/config/rs6000/darwin.h | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/gcc/config/rs6000/darwin.h b/gcc/config/rs6000/darwin.h
index 6abf8e84f54..120b01f9a2b 100644
--- a/gcc/config/rs6000/darwin.h
+++ b/gcc/config/rs6000/darwin.h
@@ -203,7 +203,7 @@
 
 /* Make both r2 and r13 available for allocation.  */
 #define FIXED_R2 0
-#define FIXED_R13 0
+#define FIXED_R13 TARGET_64BIT
 
 /* Base register for access to local variables of the function.  */
 
@@ -213,6 +213,9 @@
 #undef  RS6000_PIC_OFFSET_TABLE_REGNUM
 #define RS6000_PIC_OFFSET_TABLE_REGNUM 31
 
+#undef FIRST_SAVED_GP_REGNO
+#define FIRST_SAVED_GP_REGNO 13
+
 /* Darwin's stack must remain 16-byte aligned for both 32 and 64 bit
ABIs.  */
 
-- 
2.24.3 (Apple Git-128)



[pushed] Darwin, D : Add .d suffix to the list for invoking dsymutil.

2021-09-28 Thread Iain Sandoe via Gcc-patches
Hi,

Recognise .d for D source files on the command line.  This will
trigger an invocation of dsymutil when a D source is present.

tested along with D patches on i686, powerpc and x86_64 darwin,
pushed to master, thanks,
Iain

gcc/ChangeLog:

* config/darwin.h (DSYMUTIL_SPEC): Recognize D sources.
---
 gcc/config/darwin.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/config/darwin.h b/gcc/config/darwin.h
index 50524a51511..0fa1c572bc9 100644
--- a/gcc/config/darwin.h
+++ b/gcc/config/darwin.h
@@ -251,7 +251,7 @@ extern GTY(()) int darwin_ms_struct;
 %{v} \
 %{g*:%{!gctf:%{!gbtf:%{!gstabs*:%{%:debug-level-gt(0): -idsym}\
 %{.c|.cc|.C|.cpp|.cp|.c++|.cxx|.CPP|.m|.mm|.s|.f|.f90|\
-  .f95|.f03|.f77|.for|.F|.F90|.F95|.F03: \
+  .f95|.f03|.f77|.for|.F|.F90|.F95|.F03|.d: \
 %{g*:%{!gctf:%{!gbtf:%{!gstabs*:%{%:debug-level-gt(0): -dsym}"
 
 #define LINK_COMMAND_SPEC LINK_COMMAND_SPEC_A DSYMUTIL_SPEC
-- 
2.24.3 (Apple Git-128)



[PATCH 0/4] config: Allow a host to opt out of PCH.

2021-11-04 Thread Iain Sandoe via Gcc-patches
GCC (currently) has an implementation of pre-compiled-headers, that relies
on being able to launch the compiler executable at the same address each
time.  This constraint is not permitted by some system security models.

The facility is an optimisation; saving the output of parsing a covering
header file (that may include many others) so that the parsing need not be
repeated when the same set of headers is needed in many places in a project.

The patch series disables the operation of the PCH-related command lines,
but does not cause an error to be emitted.  The intent is that build
recipes that expect PCH to work will continue to operate, but the compiler
no longer acts on them and therefore is no longer bound to the requirement
to launch at a fixed address.

 * When invoked to "generate PCH" the compiler will carry out the parsing
   as before - producing any diagnostics if relevant and then saving a
   stub file (to satisfy build recipe targets).  The stub file is marked as
   invalid PCH.

 * When an include directive is encountered, the compiler no longer checks
   to see if a PCH header is available.

 * The top-level configure option (--disable-host-pch-support) is also
   propagated to libstdc++ where it causes the automatic invocation of the
   existing --disable-libstdxx-pch.

tested on x86_64-darwin, aarch64-darwin, and on x86_64, powerpc64le-linux,
OK for master?
thanks
Iain

Iain Sandoe (4):
  config: Add top-level flag to disable host PCH.
  libstdc++: Adjust build of PCH files accounting configured host
support.
  libcpp: Honour a configuration without host support for PCH.
  c-family, gcc: Allow configuring without support for PCH.

 Makefile.def  |  9 ++--
 Makefile.in   | 87 +--
 configure | 42 +++
 configure.ac  | 35 
 gcc/c-family/c-pch.c  | 23 ++-
 gcc/config.in |  6 +++
 gcc/config/host-darwin.c  | 18 
 gcc/configure | 29 -
 gcc/configure.ac  | 17 
 gcc/doc/install.texi  |  6 +++
 libcpp/config.in  |  3 ++
 libcpp/configure  | 24 +++
 libcpp/configure.ac   | 16 +++
 libcpp/files.c| 14 +++
 libcpp/pch.c  | 12 ++
 libstdc++-v3/acinclude.m4 | 49 +-
 libstdc++-v3/configure| 71 +---
 libstdc++-v3/configure.ac | 11 -
 18 files changed, 391 insertions(+), 81 deletions(-)

-- 
2.24.3 (Apple Git-128)



  1   2   3   >