Re: [PATCH] Darwin, crts: Provide scalb and significand as a crt [PR107631]

2022-12-30 Thread Joseph Myers
On Fri, 30 Dec 2022, Iain Sandoe via Gcc-patches wrote:

> This patch is providing functions used by the modula-2 implementation.
> 
> At present, I've used a crt rather than adding symbols to libgcc, since
> it is not clear if the modula-2 might alter the use of scalb to scalbn
> (although that will not solve the missing significand* symbols).
> 
> I plan to apply the patch early next week (it is Darwin-specific) unless
> there are any comments on the implementation.

I think it would be better to change Modula-2 to avoid using these 
obsolescent functions, rather than providing them in GCC.  (But if 
provided, the libgcc runtime license exception should be used.)

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


[PATCH] preprocessor: Don't register pragmas in directives-only mode [PR108244]

2022-12-30 Thread Lewis Hyatt via Gcc-patches
libcpp's directives-only mode does not expect deferred pragmas to be
registered, but to date the c-family registration process has not checked for
this case. That issue became more visible since r13-1544, which added the
commonly used GCC diagnostic pragmas to the set of those registered in
preprocessing modes. Fix it by checking for directives-only mode in
c-family/c-pragma.cc.

gcc/c-family/ChangeLog:

PR preprocessor/108244
* c-pragma.cc (c_register_pragma_1): Don't attempt to register any
deferred pragmas if -fdirectives-only.
(init_pragma): Likewise.

gcc/testsuite/ChangeLog:

* c-c++-common/cpp/pr108244-1.c: New test.
* c-c++-common/cpp/pr108244-2.c: New test.
* c-c++-common/cpp/pr108244-3.c: New test.
---

Notes:
Hello-

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

The PR notes a regression in GCC 13 which is fixed by the attached
patch. Bootstrap+regtest all languages on x86-64 Linux looks good. Please 
let
me know if it is OK? Thanks.

-Lewis

 gcc/c-family/c-pragma.cc| 54 -
 gcc/testsuite/c-c++-common/cpp/pr108244-1.c |  5 ++
 gcc/testsuite/c-c++-common/cpp/pr108244-2.c |  5 ++
 gcc/testsuite/c-c++-common/cpp/pr108244-3.c |  6 +++
 4 files changed, 46 insertions(+), 24 deletions(-)
 create mode 100644 gcc/testsuite/c-c++-common/cpp/pr108244-1.c
 create mode 100644 gcc/testsuite/c-c++-common/cpp/pr108244-2.c
 create mode 100644 gcc/testsuite/c-c++-common/cpp/pr108244-3.c

diff --git a/gcc/c-family/c-pragma.cc b/gcc/c-family/c-pragma.cc
index 142a46441ac..91fabf0a513 100644
--- a/gcc/c-family/c-pragma.cc
+++ b/gcc/c-family/c-pragma.cc
@@ -1647,7 +1647,8 @@ c_register_pragma_1 (const char *space, const char *name,
 
   if (flag_preprocess_only)
 {
-  if (!(allow_expansion || ihandler.early_handler.handler_1arg))
+  if (cpp_get_options (parse_in)->directives_only
+ || !(allow_expansion || ihandler.early_handler.handler_1arg))
return;
 
   pragma_pp_data pp_data;
@@ -1811,34 +1812,39 @@ c_pp_invoke_early_pragma_handler (unsigned int id)
 void
 init_pragma (void)
 {
-  if (flag_openacc)
+
+  if (!cpp_get_options (parse_in)->directives_only)
 {
-  const int n_oacc_pragmas = ARRAY_SIZE (oacc_pragmas);
-  int i;
+  if (flag_openacc)
+   {
+ const int n_oacc_pragmas = ARRAY_SIZE (oacc_pragmas);
+ int i;
 
-  for (i = 0; i < n_oacc_pragmas; ++i)
-   cpp_register_deferred_pragma (parse_in, "acc", oacc_pragmas[i].name,
- oacc_pragmas[i].id, true, true);
-}
+ for (i = 0; i < n_oacc_pragmas; ++i)
+   cpp_register_deferred_pragma (parse_in, "acc", oacc_pragmas[i].name,
+ oacc_pragmas[i].id, true, true);
+   }
 
-  if (flag_openmp)
-{
-  const int n_omp_pragmas = ARRAY_SIZE (omp_pragmas);
-  int i;
+  if (flag_openmp)
+   {
+ const int n_omp_pragmas = ARRAY_SIZE (omp_pragmas);
+ int i;
 
-  for (i = 0; i < n_omp_pragmas; ++i)
-   cpp_register_deferred_pragma (parse_in, "omp", omp_pragmas[i].name,
- omp_pragmas[i].id, true, true);
-}
-  if (flag_openmp || flag_openmp_simd)
-{
-  const int n_omp_pragmas_simd = sizeof (omp_pragmas_simd)
-/ sizeof (*omp_pragmas);
-  int i;
+ for (i = 0; i < n_omp_pragmas; ++i)
+   cpp_register_deferred_pragma (parse_in, "omp", omp_pragmas[i].name,
+ omp_pragmas[i].id, true, true);
+   }
+  if (flag_openmp || flag_openmp_simd)
+   {
+ const int n_omp_pragmas_simd
+   = sizeof (omp_pragmas_simd) / sizeof (*omp_pragmas);
+ int i;
 
-  for (i = 0; i < n_omp_pragmas_simd; ++i)
-   cpp_register_deferred_pragma (parse_in, "omp", omp_pragmas_simd[i].name,
- omp_pragmas_simd[i].id, true, true);
+ for (i = 0; i < n_omp_pragmas_simd; ++i)
+   cpp_register_deferred_pragma (parse_in, "omp",
+ omp_pragmas_simd[i].name,
+ omp_pragmas_simd[i].id, true, true);
+   }
 }
 
   if (!flag_preprocess_only)
diff --git a/gcc/testsuite/c-c++-common/cpp/pr108244-1.c 
b/gcc/testsuite/c-c++-common/cpp/pr108244-1.c
new file mode 100644
index 000..1678004a4d9
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/cpp/pr108244-1.c
@@ -0,0 +1,5 @@
+/* { dg-do preprocess } */
+/* { dg-additional-options "-fdirectives-only" } */
+#pragma GCC diagnostic push
+#ifdef t
+#endif
diff --git a/gcc/testsuite/c-c++-common/cpp/pr108244-2.c 
b/gcc/testsuite/c-c++-common/cpp/pr108244-2.c
new file mode 100644
index 000..017682ad186
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/cpp/pr108244-2.c
@@ -0,0 +1,5 @@
+/* { dg-do preprocess } */
+/* { 

Re: [17/17] check hash table insertions

2022-12-30 Thread Alexandre Oliva via Gcc-patches
On Dec 30, 2022, Richard Biener  wrote:

> Ah, OK, so the completion is checked at the next conflicting
> operation.  Yeah, that makes sense I guess.

*nod*

> Thus OK (I think Jeff already approved the patch).

Thanks, 16/ and 17/ were still pending reviews.
I'm installing 17/ now.

> Thanks and happy holidays!

Happy GNU Year! :-)

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 


Re: [17/17] check hash table insertions

2022-12-30 Thread Richard Biener via Gcc-patches



> Am 30.12.2022 um 09:53 schrieb Alexandre Oliva :
> 
> On Dec 29, 2022, Richard Biener  wrote:
> 
 Am 29.12.2022 um 00:06 schrieb Alexandre Oliva :
>>> 
>>> On Dec 28, 2022, Richard Biener  wrote:
>>> 
 I wonder if on INSERT, pushing a DELETED marker would fix the dangling
 insert and search during delete problem be whether that would be
 better from a design point of view? (It of course requires a DELETED
 representation)
>>> 
>>> I'm undecided whether a design that rules out the possibility of not
>>> having DELETED would qualify as unequivocally better.
>>> 
>>> Unless DELETED takes over the NULL representation, and something else is
>>> used for EMPTY, every INSERT point would have to be adjusted to look for
>>> the non-NULL DELETED representation.
> 
>> Not sure what you mean
> 
> I meant existing code tests that dereferencing the returned slot pointer
> yields NULL.  If we were to change the slot value during insert, we'd
> have to adjust all callers.
> 
>> I think turning EMPTY (or DELETED) into
>> DELETED at insert time would make the slot occupied for lookups and
>> thus fix lookup during insert.
> 
> Yup.
> 
>> Of course insert during insert would
>> still fail and possibly return the same slot again.
> 
> Yeah.
> 
>> So the most foolproof design would be a new INSERTING representation.
> 
> There's a glitch there: we can't expand with a pending insert.  So we
> might need to count inserting nodes separately, or (ideally) be able to
> check quickly that insertions have completed.
> 
> But then, inserting with a pending insert ought to be caught and
> reported, because an insertion invalidates previously-returned slot
> pointers, including that of the pending insert.  And that's how I got to
> the proposed patch.
> 
>>> The one-pending-insertion strategy I implemented was the only one I
>>> could find that addressed all of the pitfalls without significant
>>> overhead.  It caught even one case that the mere element-counting had
>>> failed to catch.
> 
>> Yes, it’s true that this addresses all issues with just imposing
>> constraints on API use.  But the I wondered how you catched the
>> completion of the insertion?  (I’ll have to
>> Dig into the patch to see)
> 
> Record the slot with the pending insert, and at any subsequent operation
> (that could be affected by the pending insert), check and report in case
> the insertion was not completed.

Ah, OK, so the completion is checked at the next conflicting operation.  Yeah, 
that makes sense I guess.

Thus OK (I think Jeff already approved the patch).

Thanks and happy holidays!

Richard 

> 
> 
> -- 
> Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
>   Free Software Activist   GNU Toolchain Engineer
> Disinformation flourishes because many people care deeply about injustice
> but very few check the facts.  Ask me about 


Re: [PATCH 4/n] modula-2, driver: Handle static-libstd++ for targets without static/dynamic

2022-12-30 Thread Iain Sandoe
Oops pressed ‘send' too soon - this is part of the series for Darwin:

There are several modula-2 issues on Darwin, some blocking bootstrap on
one or more system versions.

This has been tested on powerpc/i688-darwin9 .. x86_64-darwin10,17,21 and
the prototype aarch64-darwin branch on darwin21.

OK for trunk?
thanks
Iain

> On 30 Dec 2022, at 10:58, Iain Sandoe  wrote:
> 
> The follows the pattern used in C++ and D drivers to pass -static-libstdc++
> onto the target driver to allow spec substitution of static libraries.
> 
> NOTE: The general handling of Bstatic/dynamic and the possible use of static
> libgm2 libraries is unimplemented in this driver so far.  It seems likely
> that the driver construction could be greatly simplified if the modula-2
> runtimes were combined into fewer (hopefully, one) libraries.
> 
> Signed-off-by: Iain Sandoe 
> 
> gcc/m2/ChangeLog:
> 
>   * gm2spec.cc (lang_specific_driver): Pass -static-libstdc++ on to
>   the target driver if the linker does not support Bstatic/dynamic.
> ---
> gcc/m2/gm2spec.cc | 5 +
> 1 file changed, 5 insertions(+)
> 
> diff --git a/gcc/m2/gm2spec.cc b/gcc/m2/gm2spec.cc
> index 680dd3602ef..b9a5c4e79bb 100644
> --- a/gcc/m2/gm2spec.cc
> +++ b/gcc/m2/gm2spec.cc
> @@ -767,7 +767,12 @@ lang_specific_driver (struct cl_decoded_option 
> **in_decoded_options,
> 
>   case OPT_static_libstdc__:
> library = library >= 0 ? 2 : library;
> +#ifdef 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_stdlib_:
> -- 
> 2.37.1 (Apple Git-137.1)
> 



[PATCH 4/n] modula-2, driver: Handle static-libstd++ for targets without static/dynamic

2022-12-30 Thread Iain Sandoe via Gcc-patches
The follows the pattern used in C++ and D drivers to pass -static-libstdc++
onto the target driver to allow spec substitution of static libraries.

NOTE: The general handling of Bstatic/dynamic and the possible use of static
libgm2 libraries is unimplemented in this driver so far.  It seems likely
that the driver construction could be greatly simplified if the modula-2
runtimes were combined into fewer (hopefully, one) libraries.

Signed-off-by: Iain Sandoe 

gcc/m2/ChangeLog:

* gm2spec.cc (lang_specific_driver): Pass -static-libstdc++ on to
the target driver if the linker does not support Bstatic/dynamic.
---
 gcc/m2/gm2spec.cc | 5 +
 1 file changed, 5 insertions(+)

diff --git a/gcc/m2/gm2spec.cc b/gcc/m2/gm2spec.cc
index 680dd3602ef..b9a5c4e79bb 100644
--- a/gcc/m2/gm2spec.cc
+++ b/gcc/m2/gm2spec.cc
@@ -767,7 +767,12 @@ lang_specific_driver (struct cl_decoded_option 
**in_decoded_options,
 
case OPT_static_libstdc__:
  library = library >= 0 ? 2 : library;
+#ifdef 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_stdlib_:
-- 
2.37.1 (Apple Git-137.1)



[PATCH] update copyright year in libstdcc++ manual

2022-12-30 Thread Jonny Grant
2022-12-30  Jonathan Grant 
* libstdc++-v3/doc/xml/faq.xml: update copyright year in libstdcc++ 
manual


>From 60789c24fa54301135dff1c3d0b1514d77b90a82 Mon Sep 17 00:00:00 2001
From: Jonathan Grant 
Date: Fri, 30 Dec 2022 10:28:34 +
Subject: [PATCH] update copyright year date

---
 libstdc++-v3/doc/xml/faq.xml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libstdc++-v3/doc/xml/faq.xml b/libstdc++-v3/doc/xml/faq.xml
index 9ae4966ecea..42354f87af7 100644
--- a/libstdc++-v3/doc/xml/faq.xml
+++ b/libstdc++-v3/doc/xml/faq.xml
@@ -7,7 +7,7 @@
 
   
 
-  2008-2018
+  2008-2023
 
 
   http://www.w3.org/1999/xlink; 
xlink:href="https://www.fsf.org;>FSF
-- 
2.37.2


[PATCH] Darwin, crts: Provide scalb and significand as a crt [PR107631]

2022-12-30 Thread Iain Sandoe via Gcc-patches
This patch is providing functions used by the modula-2 implementation.

At present, I've used a crt rather than adding symbols to libgcc, since
it is not clear if the modula-2 might alter the use of scalb to scalbn
(although that will not solve the missing significand* symbols).

I plan to apply the patch early next week (it is Darwin-specific) unless
there are any comments on the implementation.

tested on powerpc/i688-darwin9 .. x86_64-darwin10,17,21, the prototype
aarch64-darwin branch on darwin21 and x86_64-linux-gnu.

thanks
Iain

--- 8< ---

The Darwin libc does not provide the obsolete scalb() functions, nor does
it supply the glibc significand() functions.

These are used via builtins that resolve to libcalls by modula-2 which leads
to many link fails on all Darwin versions.

We provide them here as a crt implemented as a convenience lib which means
that they will only be linked when required.

Signed-off-by: Iain Sandoe 

gcc/ChangeLog:

* config/darwin.h (LINK_COMMAND_SPEC_A): Add link for float extra
crt.

libgcc/ChangeLog:

* config.host (*-*_darwin*): Add libfltext.a.
* config/t-darwin: Build libfltext.a.
* config/darwin-scalb.c: New file.
* config/darwin-significand.c: New file.

Signed-off-by: Iain Sandoe 
---
 gcc/config/darwin.h|  1 +
 libgcc/config.host |  2 +-
 libgcc/config/darwin-scalb.c   | 58 ++
 libgcc/config/darwin-significand.c | 39 
 libgcc/config/t-darwin | 10 ++
 5 files changed, 109 insertions(+), 1 deletion(-)
 create mode 100644 libgcc/config/darwin-scalb.c
 create mode 100644 libgcc/config/darwin-significand.c

diff --git a/gcc/config/darwin.h b/gcc/config/darwin.h
index d1b4f277c2e..87b45b3d9d1 100644
--- a/gcc/config/darwin.h
+++ b/gcc/config/darwin.h
@@ -370,6 +370,7 @@ extern GTY(()) int darwin_ms_struct;
   %{%:sanitize(undefined): -lubsan } \
   %(link_ssp) \
   %:version-compare(>< 10.6 10.7 mmacosx-version-min= -ld10-uwfef) \
+  -lfltext \
   %(link_gcc_c_sequence) \
   %{!nodefaultexport:%{dylib|dynamiclib|bundle: \
%:version-compare(>= 10.11 asm_macosx_version_min= -U) \
diff --git a/libgcc/config.host b/libgcc/config.host
index d2087654c40..5ccce2726bc 100644
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -233,7 +233,7 @@ case ${host} in
   ;;
   esac
   tmake_file="$tmake_file t-slibgcc-darwin"
-  extra_parts="crt3.o libd10-uwfef.a crttms.o crttme.o libemutls_w.a"
+  extra_parts="crt3.o libd10-uwfef.a crttms.o crttme.o libemutls_w.a 
libfltext.a"
   ;;
 *-*-dragonfly*)
   tmake_file="$tmake_file t-crtstuff-pic t-libgcc-pic t-eh-dw2-dip"
diff --git a/libgcc/config/darwin-scalb.c b/libgcc/config/darwin-scalb.c
new file mode 100644
index 000..d5d653c56bf
--- /dev/null
+++ b/libgcc/config/darwin-scalb.c
@@ -0,0 +1,58 @@
+/* Implementation of the scalb functions for Darwin.
+
+Copyright The GNU Toolchain Authors.
+Contributed by Iain Sandoe.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 3, or (at your option)
+any later version.
+
+GCC is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING3.  If not see
+.  */
+
+/* These functions [scalb* (f, n)] are not provided by the system
+   As of IEEE Std 1003.1, 2004 Edition they are obsoleted.
+   As of IEEE Std 1003.1-2017 (Revision of IEEE Std 1003.1-2008) they are
+   removed.
+
+   Furthermore the informational in the 2004 edition documentation says:
+
+   1. Applications should use either scalbln(), scalblnf(), or scalblnl() in
+  preference to this function.
+
+   2. IEEE Std 1003.1-2001 only defines the behavior for the scalb() function
+  when the n argument is an integer, a NaN, or Inf. The
+  behavior of other values for the n argument is unspecified.
+
+   IEEE Std 1003.1, 2004 does not provide any additional normative description
+   of the behaviour except 'When radix is 2, scalb() shall be equivalent to
+   ldexp()' which is also only specified for integer n; Darwin's float radix
+   is defined to be 2.
+
+   These observations are used to justify a placeholder implementation of scalb
+   in terms of scalbln, since there is clear intent in the Posix documentation
+   to limit the functionality to integral values of n.*/
+
+double scalb (double r, double n)
+{
+  return __builtin_scalbln (r, (long) n);
+}
+
+float scalbf (float r, float n)
+{
+  return __builtin_scalblnf (r, (long) n);
+}
+
+long double scalbl (long double r, long double n)
+{
+ 

[PATCH 3/n] modula2: Ensure that module registration constructors are 'extern' [PR108183].

2022-12-30 Thread Iain Sandoe via Gcc-patches
There are several modula-2 issues on Darwin, some blocking bootstrap on
one or more system versions.

This has been tested on powerpc/i688-darwin9 .. x86_64-darwin10,17,21 and
the prototype aarch64-darwin branch on darwin21.

OK for trunk?
thanks
Iain

NOTE: As discussed in the PR, there are likely to be other changes to the
_definitions_ of the module registration constructors.  This patch only
relates to the _references_ to those CTORs.

--- 8< ---

The symbols for module registration constructors need to be external
or we get wrong code generated for targets that allow direct access to
local symbol definitions.

Signed-off-by: Iain Sandoe 

PR modula2/108183

gcc/m2/ChangeLog:

* gm2-compiler/M2GCCDeclare.mod: Module registration constructors are
externs to the builder of m2_link.
---
 gcc/m2/gm2-compiler/M2GCCDeclare.mod | 5 +
 1 file changed, 5 insertions(+)

diff --git a/gcc/m2/gm2-compiler/M2GCCDeclare.mod 
b/gcc/m2/gm2-compiler/M2GCCDeclare.mod
index 7e814b631ee..4c177c47398 100644
--- a/gcc/m2/gm2-compiler/M2GCCDeclare.mod
+++ b/gcc/m2/gm2-compiler/M2GCCDeclare.mod
@@ -2294,6 +2294,11 @@ PROCEDURE IsExternal (sym: CARDINAL) : BOOLEAN ;
 VAR
mod: CARDINAL ;
 BEGIN
+   IF IsProcedure (sym) AND IsExtern (sym)
+   THEN
+ Assert (NOT IsDefImp (sym));
+ RETURN TRUE
+   END ;
mod := GetScope(sym) ;
REPEAT
   IF mod=NulSym
-- 
2.37.1 (Apple Git-137.1)



[PATCH 2/n] modula-2, libgm2: Add undefined, dynamic_lookup to m2 libs links.

2022-12-30 Thread Iain Sandoe via Gcc-patches
There are several modula-2 issues on Darwin, some blocking bootstrap on
one or more system versions.

This has been tested on powerpc/i688-darwin9 .. x86_64-darwin10,17,21 and
the prototype aarch64-darwin branch on darwin21.

OK for trunk?
thanks
Iain

P.S. I am slightly surprised that a target library configure set needs
to consider $host.  If a target library is manually disabled (or does
not work) on a specific host - we usually disable it at the next level up
(see, for example, the libatomic, sanitizers etc. where there is a 
'configure.tgt' that adapts the library flags etc. to specific targets -
or says that it is UNSUPPORTED).

--- 8< ---

The libm2 libraries are cross-linked, which means that we need to allow
symbols to be undefined at link time and then to be found at runtime.

This is implemented on Darwin by adding -undefined, dynamic_lookup to
the link command.

NOTE: It would probably be a better solution to rework the libraries
either to combine those that have inter-dependencies, or to reorder
the layering so the there is a fixed dependency tree.

Signed-off-by: Iain Sandoe 

libgm2/ChangeLog:

* configure: Regenerate.
* configure.ac: Make a conditional for configurations targeting
Darwin.
* libm2cor/Makefile.am: Use -undefined,dynamic_lookup on Darwin.
* libm2iso/Makefile.am: Likewise.
* libm2log/Makefile.am: Likewise.
* libm2pim/Makefile.am: Likewise
* libm2min/Makefile.am: Likewise
* libm2cor/Makefile.in: Regenerate.
* libm2iso/Makefile.in: Regenerate.
* libm2log/Makefile.in: Regenerate.
* libm2min/Makefile.in: Regenerate.
* libm2pim/Makefile.in: Regenerate.
---
 libgm2/configure| 33 ++---
 libgm2/configure.ac | 16 +++-
 libgm2/libm2cor/Makefile.am |  7 ++-
 libgm2/libm2cor/Makefile.in |  4 +++-
 libgm2/libm2iso/Makefile.am |  7 ++-
 libgm2/libm2iso/Makefile.in |  4 +++-
 libgm2/libm2log/Makefile.am |  7 ++-
 libgm2/libm2log/Makefile.in |  4 +++-
 libgm2/libm2min/Makefile.am |  7 ++-
 libgm2/libm2min/Makefile.in |  4 +++-
 libgm2/libm2pim/Makefile.am |  8 ++--
 libgm2/libm2pim/Makefile.in |  4 +++-
 12 files changed, 90 insertions(+), 15 deletions(-)

diff --git a/libgm2/configure b/libgm2/configure
index 889c0926a15..8404b0e6e6d 100755
--- a/libgm2/configure
+++ b/libgm2/configure
@@ -634,6 +634,8 @@ ac_subst_vars='am__EXEEXT_FALSE
 am__EXEEXT_TRUE
 LTLIBOBJS
 LIBOBJS
+TARGET_DARWIN_FALSE
+TARGET_DARWIN_TRUE
 BUILD_LOGLIB_FALSE
 BUILD_LOGLIB_TRUE
 BUILD_CORLIB_FALSE
@@ -12698,7 +12700,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 12701 "configure"
+#line 12703 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -12804,7 +12806,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 12807 "configure"
+#line 12809 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -19508,7 +19510,7 @@ $as_echo "$as_me: libgm2 has finished checking target 
libc and libm contents." >
 # All known M2_HOST_OS values.  This is the union of all host operating systems
 # supported by gm2.
 
-M2_SUPPORTED_HOST_OS="aix freebsd hurd linux netbsd openbsd solaris windows"
+M2_SUPPORTED_HOST_OS="aix freebsd hurd linux netbsd openbsd solaris windows 
darwin"
 
 M2_HOST_OS=unknown
 
@@ -19523,6 +19525,19 @@ case ${host} in
   *-*-gnu*)  M2_HOST_OS=hurd ;;
 esac
 
+M2_TARGET_OS=unknown
+
+case ${target} in
+  *-*-darwin*)   M2_TARGET_OS=darwin ;;
+  *-*-freebsd*)  M2_TARGET_OS=freebsd ;;
+  *-*-linux*)M2_TARGET_OS=linux ;;
+  *-*-netbsd*)  M2_TARGET_OS=netbsd ;;
+  *-*-openbsd*)  M2_TARGET_OS=openbsd ;;
+  *-*-solaris2*) M2_TARGET_OS=solaris ;;
+  *-*-aix*)  M2_TARGET_OS=aix ;;
+  *-*-gnu*)  M2_TARGET_OS=hurd ;;
+esac
+
 # M2_HOST_OS=unknown
 if test x${M2_HOST_OS} = xunknown; then
{ $as_echo "$as_me:${as_lineno-$LINENO}: unsupported host, will build a 
minimal m2 library" >&5
@@ -19672,6 +19687,14 @@ else
   BUILD_LOGLIB_FALSE=
 fi
 
+ if test x$M2_TARGET_OS = xdarwin; then
+  TARGET_DARWIN_TRUE=
+  TARGET_DARWIN_FALSE='#'
+else
+  TARGET_DARWIN_TRUE='#'
+  TARGET_DARWIN_FALSE=
+fi
+
 
 
 ac_config_files="$ac_config_files Makefile libm2min/Makefile libm2pim/Makefile 
libm2iso/Makefile libm2cor/Makefile libm2log/Makefile"
@@ -19841,6 +19864,10 @@ if test -z "${BUILD_LOGLIB_TRUE}" && test -z 
"${BUILD_LOGLIB_FALSE}"; then
   as_fn_error $? "conditional \"BUILD_LOGLIB\" was never defined.
 Usually this means the macro was only invoked conditionally." "$LINENO" 5
 fi
+if test -z "${TARGET_DARWIN_TRUE}" && test -z "${TARGET_DARWIN_FALSE}"; then
+  as_fn_error $? "conditional \"TARGET_DARWIN\" was never defined.
+Usually this means the macro was only invoked conditionally." "$LINENO" 5
+fi
 
 : "${CONFIG_STATUS=./config.status}"
 ac_write_fail=0

[PATCH 1/n] modula-2: Fix building the plugin for Darwin [PR107612].

2022-12-30 Thread Iain Sandoe via Gcc-patches
From: Rainer Orth 

There are several modula-2 issues on Darwin, some blocking bootstrap on
one or more system versions.

This has been tested on powerpc/i688-darwin9 .. x86_64-darwin10,17,21 and
the prototype aarch64-darwin branch on darwin21.

OK for trunk?
thanks
Iain

this patch:

--- 8< ---

 * Makes the configured value for INCINTL available as a variable so that
it can be used in language makefile fragements.  It is then used in the m2
fragment to make the include path available to the plugin compile.

 * Updates the DSO suffix  to use .dylib for Darwin.

 * Adds '-Wl,-undefined,dynamic_lookup' to the link flags so that symbols can
   be resolved at runtime.

 * Removes the extraneous $(exeext) from the DSO names.

Since the linking is driven by CXX, we also need to supress the addition of
default libraries otherwise:
 (1) we will get a reference to an uninstalled libstdc++
 (2) the process opening the plugin would have two instances 0f libstdc++ -
 one statically linked into gm2 and one dynamically linked into the plugin.

gcc/ChangeLog:

* Makefile.in: Make the configured libintl includes avaiable in INCINTL.
(BUILD_CPPFLAGS): Use INCINTL.

gcc/m2/ChangeLog:

* Make-lang.in (soext): Use .dylib for Darwin.
(PLUGINLDFLAGS): Use dynmic lookup, set the plugin name, and append
-nodefaultlibs to suppress the linking of libstdc++.
Use INCINTL in compile lines for the plugin.

Co-Authored-By: Iain Sandoe 
---
 gcc/Makefile.in |  5 +++--
 gcc/m2/Make-lang.in | 34 +++---
 2 files changed, 26 insertions(+), 13 deletions(-)

diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 995d77f96c4..4e5fb677cfe 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -729,6 +729,7 @@ htmldir = @htmldir@
 USE_NLS = @USE_NLS@
 
 # Internationalization library.
+INCINTL = @INCINTL@
 LIBINTL = @LIBINTL@
 LIBINTL_DEP = @LIBINTL_DEP@
 
@@ -820,7 +821,7 @@ BUILD_LINKERFLAGS = $(BUILD_CXXFLAGS)
 # Native linker and preprocessor flags.  For x-fragment overrides.
 BUILD_LDFLAGS=@BUILD_LDFLAGS@
 BUILD_CPPFLAGS= -I. -I$(@D) -I$(srcdir) -I$(srcdir)/$(@D) \
-   -I$(srcdir)/../include @INCINTL@ $(CPPINC) $(CPPFLAGS)
+   -I$(srcdir)/../include $(INCINTL) $(CPPINC) $(CPPFLAGS)
 
 # Actual name to use when installing a native compiler.
 GCC_INSTALL_NAME := $(shell echo gcc|sed '$(program_transform_name)')
@@ -1125,7 +1126,7 @@ BUILD_ERRORS = build/errors.o
 # currently being compiled, in both source trees, to be examined as well.
 # libintl.h will be found in ../intl if we are using the included libintl.
 INCLUDES = -I. -I$(@D) -I$(srcdir) -I$(srcdir)/$(@D) \
-  -I$(srcdir)/../include @INCINTL@ \
+  -I$(srcdir)/../include $(INCINTL) \
   $(CPPINC) $(CODYINC) $(GMPINC) $(DECNUMINC) $(BACKTRACEINC) \
   $(ISLINC)
 
diff --git a/gcc/m2/Make-lang.in b/gcc/m2/Make-lang.in
index 828eaad6285..1f615ec9907 100644
--- a/gcc/m2/Make-lang.in
+++ b/gcc/m2/Make-lang.in
@@ -31,6 +31,16 @@ GM2_1 = ./gm2 -B./m2/stage1 -g -fm2-g
 
 GM2_FOR_TARGET = $(STAGE_CC_WRAPPER) ./gm2 -B./ -B$(build_tooldir)/bin/ 
-L$(objdir)/../ld $(TFLAGS)
 
+# FIXME: Get from gcc-plugin.m4 instead of hardcoding.
+ifeq (,$(findstring darwin,$(host)))
+  soext=.so
+else
+  soext=.dylib
+  PLUGINLDFLAGS = -Wl,-undefined,dynamic_lookup
+  PLUGINLDFLAGS += -Wl,-install_name,m2rte$(soext)
+  PLUGINLDFLAGS += -nodefaultlibs
+endif
+
 TEXISRC = $(objdir)/m2/images/gnu.eps \
   $(srcdir)/doc/gm2.texi \
   m2/gm2-libs.texi \
@@ -113,9 +123,9 @@ po-generated:
 
 # Build hooks:
 
-m2.all.cross: gm2-cross$(exeext) plugin/m2rte$(exeext).so
+m2.all.cross: gm2-cross$(exeext) plugin/m2rte$(soext)
 
-m2.start.encap: gm2$(exeext) plugin/m2rte$(exeext).so
+m2.start.encap: gm2$(exeext) plugin/m2rte$(soext)
 m2.rest.encap:
 
 
@@ -367,14 +377,16 @@ m2.uninstall:
 
 m2.install-plugin: installdirs
$(mkinstalldirs) $(DESTDIR)$(plugin_resourcesdir)
-   $(INSTALL_PROGRAM) plugin/m2rte$(exeext).so 
$(DESTDIR)$(plugin_resourcesdir)/m2rte$(exeext).so
-   chmod a+x $(DESTDIR)$(plugin_resourcesdir)/m2rte$(exeext).so
+   $(INSTALL_PROGRAM) plugin/m2rte$(soext) 
$(DESTDIR)$(plugin_resourcesdir)/m2rte$(soext)
+   chmod a+x $(DESTDIR)$(plugin_resourcesdir)/m2rte$(soext)
+
+override PLUGINCFLAGS := $(filter-out -mdynamic-no-pic,$(PLUGINCFLAGS))
 
-plugin/m2rte$(exeext).so: $(srcdir)/m2/plugin/m2rte.cc 
$(GCC_HEADER_DEPENDENCIES_FOR_M2) \
+plugin/m2rte$(soext): $(srcdir)/m2/plugin/m2rte.cc 
$(GCC_HEADER_DEPENDENCIES_FOR_M2) \
 insn-attr-common.h insn-flags.h $(generated_files)
-test -d plugin || $(mkinstalldirs) plugin
-   $(PLUGINCC) $(PLUGINCFLAGS) -fno-rtti -I. -I$(srcdir) -I$(srcdir)/m2 
-I$(srcdir)/m2/gm2-gcc -I$(srcdir)/../include -I$(srcdir)/../libcpp/include 
-Wall $(GMPINC) -Wno-literal-suffix -fPIC -c -o plugin/m2rte.o 
$(srcdir)/m2/plugin/m2rte.cc
-   $(PLUGINCC) $(PLUGINCFLAGS) $(PLUGINLIBS) -fno-rtti 

[ping^1] [PATCH] c++, TLS: Support cross-tu static initialization for targets without alias support [PR106435].

2022-12-30 Thread Iain Sandoe via Gcc-patches
it seems other targets are interested in this too - I was asked on IRC if it 
was going to be fixed this cycle.

> On 7 Dec 2022, at 15:39, Iain Sandoe via Gcc-patches 
>  wrote:
> 
> This has been tested on x86_64 and arm64 Darwin and on x86_64 linux gnu.
> The basic patch is live in the homebrew macOS support and so has had quite
> wide coverage on non-trivial codebases.
> 
> OK for master?
> Iain
> 
> Since this actually fixes wrong code, I wonder if we should also consider
> back-porting.
> 
> --- >8 ---
> 
> The description below relates to the code path when TARGET_SUPPORTS_ALIASES is
> false; current operation is maintained for targets with alias support and any
> new support code should be DCEd in that case.
> 
> --
> 
> Currently, cross-tu static initialisation is not supported for targets without
> alias support.
> 
> The patch adds support by building a shim function in place of the alias for
> these targets; the shim simply calls the generic initialiser.  Although this 
> is
> slightly less efficient than the alias, in practice (for targets that allow
> sibcalls) the penalty is a single jump when code is optimised.
> 
> From the perspective of a TU referencing an extern TLS variable, there is no
> way to determine if it requires a guarded dynamic init.  So, in the 
> referencing
> TU, we build a weak reference to the potential init and check at runtime if 
> the
> init is present before calling it.  This strategy is fine for targets that 
> have
> ELF semantics, but fails at link time for Mach-O (which does not permit the
> reference to be undefined in the static link).
> 
> The actual initialiser call is contained in a wrapper function, and to resolve
> the Mach-O linker issue, in the TU that is referencing the var, we now 
> generate
> both the wrapper _and_ a weak definition of a dummy init function.  In the 
> case
> that there _is_ a dynamic init (in a different TU), that version will be 
> non-weak
> and will be override the weak dummy one.  In the case that we have a trivial
> static init (so no init in any other TU) the weak-defined dummy init will be
> called (a single return insn for optimised code).  We mitigate the call to
> the dummy init by reworking the wrapper code-gen path to remove the test for
> the weak reference function (as it will always be true) since the static 
> linker
> will now determine the function to be called.
> 
> Signed-off-by: Iain Sandoe 
> 
>   PR c++/106435
> 
> gcc/c-family/ChangeLog:
> 
>   * c-opts.cc (c_common_post_options): Allow fextern-tls-init for targets
>   without alias support.
> 
> gcc/cp/ChangeLog:
> 
>   * decl2.cc (get_tls_init_fn): Allow targets without alias support.
>   (handle_tls_init): Emit aliases for single init functions where the
>   target supporst this, otherwise emit a stub function that calls the
>   main tls init function.  (generate_tls_dummy_init): New.
> 
> gcc/testsuite/ChangeLog:
> 
>   * g++.dg/cpp0x/pr106435-b.cc: New file.
>   * g++.dg/cpp0x/pr106435.C: New test.
>   * g++.dg/cpp0x/pr106435.h: New file.
> ---
> gcc/c-family/c-opts.cc   |  2 +-
> gcc/cp/decl2.cc  | 80 
> gcc/testsuite/g++.dg/cpp0x/pr106435-b.cc | 22 +++
> gcc/testsuite/g++.dg/cpp0x/pr106435.C| 24 +++
> gcc/testsuite/g++.dg/cpp0x/pr106435.h| 27 
> 5 files changed, 142 insertions(+), 13 deletions(-)
> create mode 100644 gcc/testsuite/g++.dg/cpp0x/pr106435-b.cc
> create mode 100644 gcc/testsuite/g++.dg/cpp0x/pr106435.C
> create mode 100644 gcc/testsuite/g++.dg/cpp0x/pr106435.h
> 
> diff --git a/gcc/c-family/c-opts.cc b/gcc/c-family/c-opts.cc
> index 70745aa4e7c..064645f980d 100644
> --- a/gcc/c-family/c-opts.cc
> +++ b/gcc/c-family/c-opts.cc
> @@ -1070,7 +1070,7 @@ c_common_post_options (const char **pfilename)
> 
>   if (flag_extern_tls_init)
> {
> -  if (!TARGET_SUPPORTS_ALIASES || !SUPPORTS_WEAK)
> +  if (!SUPPORTS_WEAK)
>   {
> /* Lazy TLS initialization for a variable in another TU requires
>alias and weak reference support.  */
> diff --git a/gcc/cp/decl2.cc b/gcc/cp/decl2.cc
> index f95529a5c9a..c6550c0c2fc 100644
> --- a/gcc/cp/decl2.cc
> +++ b/gcc/cp/decl2.cc
> @@ -3672,9 +3672,8 @@ get_tls_init_fn (tree var)
>   if (!flag_extern_tls_init && DECL_EXTERNAL (var))
> return NULL_TREE;
> 
> -  /* If the variable is internal, or if we can't generate aliases,
> - call the local init function directly.  */
> -  if (!TREE_PUBLIC (var) || !TARGET_SUPPORTS_ALIASES)
> +  /* If the variable is internal call the local init function directly.  */
> +  if (!TREE_PUBLIC (var))
> return get_local_tls_init_fn (DECL_SOURCE_LOCATION (var));
> 
>   tree sname = mangle_tls_init_fn (var);
> @@ -3811,8 +3810,12 @@ generate_tls_wrapper (tree fn)
>   if (tree init_fn = get_tls_init_fn (var))
> {
>   tree if_stmt = NULL_TREE;
> -  /* If init_fn is a weakref, make sure it exists before 

Re: [PATCH] Ada, Darwin: Do not link libgcc statically on Darwin [PR108202].

2022-12-30 Thread Iain Sandoe
I would like to revise this patch to be more conservative (only applying to 
Darwin 8 and 9).

> On 24 Dec 2022, at 19:00, Iain Sandoe via Gcc-patches 
>  wrote:
> 
> Tested on i686, x86-64 darwin, x86_64-linux (with a 32b multilib).
> OK for trunk?
> Iain

revised:

[PATCH] Ada,Darwin: Do not link libgcc statically on Darwin 8 and 9  [PR108202].

Normally, GCC executables are built with -static-libstdc++ -static-libgcc
on Darwin.  This is fine in most cases, because GCC executables typically
do not use exceptions.   However gnat1 does use exceptions and also pulls
in system libraries that are linked against the installed shared libgcc
which contains the system unwinder.  This means that gnat1 effectively has
two unwinder instances (which does not work reliably since the unwinders
have global state).

A recent change in the initialization of FDEs has made this a hard error
now on Darwin versions (8 and 9) with libgcc installed in /usr/lib (gnat1
now hangs when an exception is thrown).

The solution is to link libgcc dynamically, picking up the installed
system version.  To do this we strip -static-libgcc from the link flags.

PR ada/108202

gcc/ada/ChangeLog:

* gcc-interface/Make-lang.in (GCC_LINKERFLAGS, GCC_LDFLAGS):
Versions of ALL_LINKERFLAGS, LDFLAGS with -Werror and
-static-libgcc filtered out for Darwin8 and 9 (-Werror is filtered
out for other hosts).
---
 gcc/ada/gcc-interface/Make-lang.in | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/gcc/ada/gcc-interface/Make-lang.in 
b/gcc/ada/gcc-interface/Make-lang.in
index 2acd195017e..c81daae9c4a 100644
--- a/gcc/ada/gcc-interface/Make-lang.in
+++ b/gcc/ada/gcc-interface/Make-lang.in
@@ -260,11 +260,20 @@ else
   endif
 endif
 
+ifneq ($(filter darwin9% darwin8%,$(host_os)),)
+# gnat1 uses exceptions which is incompatible with statically-linked libgcc
+# on Darwin8 and 9, since gnat1 also pulls in libraries linked with the system
+# unwinder.
+GCC_LINKERFLAGS = $(filter-out -Werror -static-libgcc, $(ALL_LINKERFLAGS))
+GCC_LDFLAGS = $(filter-out -static-libgcc, $(LDFLAGS))
+else
 # Strip -Werror during linking for the LTO bootstrap
 GCC_LINKERFLAGS = $(filter-out -Werror, $(ALL_LINKERFLAGS))
+GCC_LDFLAGS = $(LDFLAGS)
+endif
 
-GCC_LINK=$(LINKER) $(GCC_LINKERFLAGS) $(LDFLAGS)
-GCC_LLINK=$(LLINKER) $(GCC_LINKERFLAGS) $(LDFLAGS)
+GCC_LINK=$(LINKER) $(GCC_LINKERFLAGS) $(GCC_LDFLAGS)
+GCC_LLINK=$(LLINKER) $(GCC_LINKERFLAGS) $(GCC_LDFLAGS)
 
 # Lists of files for various purposes.
 
-- 
2.37.1 (Apple Git-137.1)



Re: [17/17] check hash table insertions

2022-12-30 Thread Alexandre Oliva via Gcc-patches
On Dec 29, 2022, Richard Biener  wrote:

>> Am 29.12.2022 um 00:06 schrieb Alexandre Oliva :
>> 
>> On Dec 28, 2022, Richard Biener  wrote:
>> 
>>> I wonder if on INSERT, pushing a DELETED marker would fix the dangling
>>> insert and search during delete problem be whether that would be
>>> better from a design point of view? (It of course requires a DELETED
>>> representation)
>> 
>> I'm undecided whether a design that rules out the possibility of not
>> having DELETED would qualify as unequivocally better.
>> 
>> Unless DELETED takes over the NULL representation, and something else is
>> used for EMPTY, every INSERT point would have to be adjusted to look for
>> the non-NULL DELETED representation.

> Not sure what you mean

I meant existing code tests that dereferencing the returned slot pointer
yields NULL.  If we were to change the slot value during insert, we'd
have to adjust all callers.

> I think turning EMPTY (or DELETED) into
> DELETED at insert time would make the slot occupied for lookups and
> thus fix lookup during insert.

Yup.

> Of course insert during insert would
> still fail and possibly return the same slot again.

Yeah.

> So the most foolproof design would be a new INSERTING representation.

There's a glitch there: we can't expand with a pending insert.  So we
might need to count inserting nodes separately, or (ideally) be able to
check quickly that insertions have completed.

But then, inserting with a pending insert ought to be caught and
reported, because an insertion invalidates previously-returned slot
pointers, including that of the pending insert.  And that's how I got to
the proposed patch.

>> The one-pending-insertion strategy I implemented was the only one I
>> could find that addressed all of the pitfalls without significant
>> overhead.  It caught even one case that the mere element-counting had
>> failed to catch.

> Yes, it’s true that this addresses all issues with just imposing
> constraints on API use.  But the I wondered how you catched the
> completion of the insertion?  (I’ll have to
> Dig into the patch to see)

Record the slot with the pending insert, and at any subsequent operation
(that could be affected by the pending insert), check and report in case
the insertion was not completed.


-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 


Re: [PATCH] loading float member of parameter stored via int registers

2022-12-30 Thread Andrew Pinski via Gcc-patches
On Thu, Dec 29, 2022 at 11:45 PM Segher Boessenkool
 wrote:
>
> Hi!
>
> On Fri, Dec 30, 2022 at 10:22:31AM +0800, Jiufu Guo wrote:
> > Considering the limitations of CSE, I try to find other places
> > to handle this issue, and notice DSE can optimize below code:
> > "[sfp:DI]=x:DI ; y:SI=[sfp:DI]" to "y:SI=x:DI#0".
> >
> > So, I drafted a patch to update DSE to handle DI->DF/SF.
> > The patch updates "extract_low_bits" to get mode change
> > with subreg.
> >
> > diff --git a/gcc/expmed.cc b/gcc/expmed.cc
> > index b12b0e000c2..5e36331082c 100644
> > --- a/gcc/expmed.cc
> > +++ b/gcc/expmed.cc
> > @@ -2439,7 +2439,10 @@ extract_low_bits (machine_mode mode, machine_mode 
> > src_mode, rtx src)
> >
> >if (!targetm.modes_tieable_p (src_int_mode, src_mode))
> >  return NULL_RTX;
> > -  if (!targetm.modes_tieable_p (int_mode, mode))
> > +  if (!targetm.modes_tieable_p (int_mode, mode)
> > +  && !(known_le (GET_MODE_BITSIZE (mode), GET_MODE_BITSIZE (src_mode))
> > +&& GET_MODE_CLASS (mode) == MODE_FLOAT
> > +&& GET_MODE_CLASS (src_mode) == MODE_INT))
> >  return NULL_RTX;
> >
> >src = gen_lowpart (src_int_mode, src);
>
> Ah!  This simply shows rs6000_modes_tieable_p is decidedly non-optimal:
> it does not allow tying a scalar float to anything else.  No such thing
> is required, or good apparently.  I wonder why we have such restrictions
> at all in rs6000; is it just unfortunate history, was it good at one
> point in time?

The documentation for TARGET_MODES_TIEABLE_P says the following:
If TARGET_HARD_REGNO_MODE_OK (r, mode1) and TARGET_HARD_REGNO_MODE_OK
(r, mode2) are always the same for any r, then TARGET_MODES_TIEABLE_P
(mode1, mode2) should be true. If they differ for any r, you should
define this hook to return false unless some other mechanism ensures
the accessibility of the value in a narrower mode.

even though rs6000_hard_regno_mode_ok_uncached's comment has the following:
  /* The float registers (except for VSX vector modes) can only hold floating
 modes and DImode.  */

TARGET_P8_VECTOR and TARGET_P9_VECTOR has special cased different modes now:
  if (TARGET_P8_VECTOR && (mode == SImode))
return 1;

  if (TARGET_P9_VECTOR && (mode == QImode || mode == HImode))
return 1;
Which I suspect that means rs6000_modes_tieable_p should return true
for SImode and SFmode if TARGET_P8_VECTOR is true. Likewise for
TARGET_P9_VECTOR and SFmode and QImode/HImode too.


Thanks,
Andrew Pinski

>
>
> Segher


Re: [PATCH] i386: correct division modeling in lujiazui.md

2022-12-30 Thread Uros Bizjak via Gcc-patches
On Fri, Dec 30, 2022 at 3:21 AM Mayshao-oc  wrote:
>
> >Ping. If there are any questions or concerns about the patch, please let me
> >know: I'm interested in continuing this cleanup at least for older AMD 
> >models.
> >
> Hi Alexander:
> According to the speccpu2017 benchmark result, the patch looks good 
> in lujiazui.

The patch is OK then.

Thanks,
Uros.

> BR
> Mayshao
> >I noticed I had an extra line in my Changelog:
> >
> >>  (lua_sseicvt_si): Ditto.
> >
> >It got there accidentally and I will drop it.
> >
> >Alexander
> >
> >On Fri, 9 Dec 2022, Alexander Monakov wrote:
> >
> >> Model the divider in Lujiazui processors as a separate automaton to
> >> significantly reduce the overall model size. This should also result
> >> in improved accuracy, as pipe 0 should be able to accept new
> >> instructions while the divider is occupied.
> >>
> >> It is unclear why integer divisions are modeled as if pipes 0-3 are
> >> all occupied. I've opted to keep a single-cycle reservation of all
> >> four pipes together, so GCC should continue trying to pack
> >> instructions around a division accordingly.
> >>
> >> Currently top three symbols in insn-automata.o are:
> >>
> >> 106102 r lujiazui_core_check
> >> 106102 r lujiazui_core_transitions
> >> 196123 r lujiazui_core_min_issue_delay
> >>
> >> This patch shrinks all lujiazui tables to:
> >>
> >> 3 r lujiazui_decoder_min_issue_delay
> >> 20 r lujiazui_decoder_transitions
> >> 32 r lujiazui_agu_min_issue_delay
> >> 126 r lujiazui_agu_transitions
> >> 304 r lujiazui_div_base
> >> 352 r lujiazui_div_check
> >> 352 r lujiazui_div_transitions
> >> 1152 r lujiazui_core_min_issue_delay
> >> 1592 r lujiazui_agu_translate
> >> 1592 r lujiazui_core_translate
> >> 1592 r lujiazui_decoder_translate
> >> 1592 r lujiazui_div_translate
> >> 3952 r lujiazui_div_min_issue_delay
> >> 9216 r lujiazui_core_transitions
> >>
> >> This continues the work on reducing i386 insn-automata.o size started
> >> with similar fixes for division and multiplication instructions in
> >> znver.md [1][2]. I plan to submit corresponding fixes for
> >> b[td]ver[123].md as well.
> >>
> >> [1]
> >> https://inbox.sourceware.org/gcc-patches/23c795d6-403c-5927-e610-f0f12
> >> 15f5...@ispras.ru/T/#m36e069d43d07d768d4842a779e26b4a0915cc543
> >> [2]
> >> https://inbox.sourceware.org/gcc-patches/20221101162637.14238-1-amonak
> >> o...@ispras.ru/
> >>
> >> gcc/ChangeLog:
> >>
> >>  PR target/87832
> >>  * config/i386/lujiazui.md (lujiazui_div): New automaton.
> >>  (lua_div): New unit.
> >>  (lua_idiv_qi): Correct unit in the reservation.
> >>  (lua_idiv_qi_load): Ditto.
> >>  (lua_idiv_hi): Ditto.
> >>  (lua_idiv_hi_load): Ditto.
> >>  (lua_idiv_si): Ditto.
> >>  (lua_idiv_si_load): Ditto.
> >>  (lua_idiv_di): Ditto.
> >>  (lua_idiv_di_load): Ditto.
> >>  (lua_fdiv_SF): Ditto.
> >>  (lua_fdiv_SF_load): Ditto.
> >>  (lua_fdiv_DF): Ditto.
> >>  (lua_fdiv_DF_load): Ditto.
> >>  (lua_fdiv_XF): Ditto.
> >>  (lua_fdiv_XF_load): Ditto.
> >>  (lua_ssediv_SF): Ditto.
> >>  (lua_ssediv_load_SF): Ditto.
> >>  (lua_ssediv_V4SF): Ditto.
> >>  (lua_ssediv_load_V4SF): Ditto.
> >>  (lua_ssediv_V8SF): Ditto.
> >>  (lua_ssediv_load_V8SF): Ditto.
> >>  (lua_ssediv_SD): Ditto.
> >>  (lua_ssediv_load_SD): Ditto.
> >>  (lua_ssediv_V2DF): Ditto.
> >>  (lua_ssediv_load_V2DF): Ditto.
> >>  (lua_ssediv_V4DF): Ditto.
> >>  (lua_ssediv_load_V4DF): Ditto.
> >>  (lua_sseicvt_si): Ditto.
> >> ---
> >>  gcc/config/i386/lujiazui.md | 58
> >> +++--
> >>  1 file changed, 30 insertions(+), 28 deletions(-)
> >>
> >> diff --git a/gcc/config/i386/lujiazui.md b/gcc/config/i386/lujiazui.md
> >> index 9046c09f2..58a230c70 100644
> >> --- a/gcc/config/i386/lujiazui.md
> >> +++ b/gcc/config/i386/lujiazui.md
> >> @@ -19,8 +19,8 @@
> >>
> >>  ;; Scheduling for ZHAOXIN lujiazui processor.
> >>
> >> -;; Modeling automatons for decoders, execution pipes and AGU pipes.
> >> -(define_automaton "lujiazui_decoder,lujiazui_core,lujiazui_agu")
> >> +;; Modeling automatons for decoders, execution pipes, AGU pipes, and 
> >> divider.
> >> +(define_automaton
> >> +"lujiazui_decoder,lujiazui_core,lujiazui_agu,lujiazui_div")
> >>
> >>  ;; The rules for the decoder are simple:
> >>  ;;  - an instruction with 1 uop can be decoded by any of the three @@
> >> -55,6 +55,8 @@ (define_reservation "lua_decoder01"
> >> "lua_decoder0|lua_decoder1")  (define_cpu_unit
> >> "lua_p0,lua_p1,lua_p2,lua_p3" "lujiazui_core")  (define_cpu_unit
> >> "lua_p4,lua_p5" "lujiazui_agu")
> >>
> >> +(define_cpu_unit "lua_div" "lujiazui_div")
> >> +
> >>  (define_reservation "lua_p03" "lua_p0|lua_p3")  (define_reservation
> >> "lua_p12" "lua_p1|lua_p2")  (define_reservation "lua_p1p2"
> >> "lua_p1+lua_p2") @@ -229,56 +231,56 @@ (define_insn_reservation
> >> "lua_idiv_qi" 21
> >>(and (eq_attr "memory" "none")