Re: [PATCH v4 0/4]New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

[Martin Uecker]

Am Freitag, dem 26.01.2024 um 14:33 + schrieb Qing Zhao:
> 
> > On Jan 26, 2024, at 3:04 AM, Martin Uecker  wrote:
> > 
> > 
> > I haven't looked at the patch, but it sounds you give the result
> > the wrong type. Then patching up all use cases instead of the
> > type seems wrong.
> 
> Yes, this is for resolving a very early gimplification issue as I reported 
> last Nov:
> https://gcc.gnu.org/pipermail/gcc-patches/2023-November/638793.html
> 
> Since no-one responded at that time, I fixed the issue by replacing the 
> ARRAY_REF
> With a pointer indirection:
> https://gcc.gnu.org/pipermail/gcc-patches/2023-December/639605.html
> 
> The reason for such change is:  return a flexible array member TYPE is not 
> allowed
> by C language (our gimplification follows this rule), so, we have to return a 
> pointer TYPE instead. 
> 
> **The new internal function
> 
>  .ACCESS_WITH_SIZE (REF_TO_OBJ, REF_TO_SIZE, CLASS_OF_SIZE, SIZE_OF_SIZE, 
> ACCESS_MODE, INDEX)
> 
> INTERNAL_FN (ACCESS_WITH_SIZE, ECF_LEAF | ECF_NOTHROW, NULL)
> 
> which returns the "REF_TO_OBJ" same as the 1st argument;
> 
> Both the return type and the type of the first argument of this function have 
> been converted from 
> the incomplete array type to the corresponding pointer type.
> 
> As a result, the original ARRAY_REF was converted to an INDIRECT_REF, the 
> original INDEX of the ARRAY_REF was lost
> when converting from ARRAY_REF to INDIRECT_REF, in order to keep the INDEX 
> for bound sanitizer instrumentation, I added
> The 6th argument “INDEX”.
> 
> What’s your comment and suggestion on this solution?

I am not entirely sure but changing types in the FE seems
problematic because this breaks language semantics. And
then adding special code everywhere to treat it specially
in the FE does not seem a good way forward.

If I understand correctly, returning an incomplete array 
type is not allowed and then fails during gimplification.
So I would suggest to make it return a pointer to the 
incomplete array (and not the element type) but then wrap
it with an indirection when inserting this code in the FE
so that the full replacement has the correct type again
(of the incomplete array).


Alternatively, one could allow this during gimplification
or add some conversion.

Martin


> 
> Thanks.
> 
> Qing
> 
> 
> > 
> > Martin
> > 
> > 
> > Am Donnerstag, dem 25.01.2024 um 20:11 + schrieb Qing Zhao:
> > > Thanks a lot for the testing.
> > > 
> > > Yes, I can repeat the issue with the following small example:
> > > 
> > > #include 
> > > #include 
> > > #include 
> > > 
> > > #define MAX(a, b)  ((a) > (b) ? (a) :  (b))
> > > 
> > > struct untracked {
> > >   int size;
> > >   int array[] __attribute__((counted_by (size)));
> > > } *a;
> > > struct untracked * alloc_buf (int index)
> > > {
> > >  struct untracked *p;
> > >  p = (struct untracked *) malloc (MAX (sizeof (struct untracked),
> > >(offsetof (struct untracked, 
> > > array[0])
> > > + (index) * sizeof (int;
> > >  p->size = index;
> > >  return p;
> > > }
> > > 
> > > int main()
> > > {
> > >  a = alloc_buf(10);
> > > printf ("same_type is %d\n",
> > >  (__builtin_types_compatible_p(typeof (a->array), typeof 
> > > (&(a->array)[0];
> > >  return 0;
> > > }
> > > 
> > > 
> > > /home/opc/Install/latest-d/bin/gcc -O2 btcp.c
> > > same_type is 1
> > > 
> > > Looks like that the “typeof” operator need to be handled specially in C FE
> > > for the new internal function .ACCESS_WITH_SIZE. 
> > > 
> > > (I have specially handle the operator “offsetof” in C FE already).
> > > 
> > > Will fix this issue.
> > > 
> > > Thanks.
> > > 
> > > Qing
> > > 
> > > > On Jan 24, 2024, at 7:51 PM, Kees Cook  wrote:
> > > > 
> > > > On Wed, Jan 24, 2024 at 12:29:51AM +, Qing Zhao wrote:
> > > > > This is the 4th version of the patch.
> > > > 
> > > > Thanks very much for this!
> > > > 
> > > > I tripped over an unexpected behavioral change that the Linux kernel
> > > > depends on:
> > > > 
> > > > __builtin_types_compatible_p() no longer treats an array marked with
> > > > counted_by as different from that array's decayed pointer. Specifically,
> > > > the kernel uses these macros:
> > > > 
> > > > 
> > > > /*
> > > > * Force a compilation error if condition is true, but also produce a
> > > > * result (of value 0 and type int), so the expression can be used
> > > > * e.g. in a structure initializer (or where-ever else comma expressions
> > > > * aren't permitted).
> > > > */
> > > > #define BUILD_BUG_ON_ZERO(e) ((int)(sizeof(struct { int:(-!!(e)); })))
> > > > 
> > > > #define __same_type(a, b) __builtin_types_compatible_p(typeof(a), 
> > > > typeof(b))
> > > > 
> > > > /* &a[0] degrades to a pointer: a different type from an array */
> > > > #define __must_be_array(a)   BUILD_BUG_ON_ZERO(__same_type((a), 
> > > > &(a)[0]))
> > > > 
> > > > 
> > > > This gets used in various places to make sure we

Re: [PATCH v3] Fix __builtin_nested_func_ptr_{created, deleted} symbol versions [PR113402]

[Iain Sandoe]

> On 18 Jan 2024, at 15:05, Jakub Jelinek  wrote:
> 
> On Thu, Jan 18, 2024 at 02:59:23PM +, Iain Sandoe wrote:
>> --- a/gcc/builtins.cc
>> +++ b/gcc/builtins.cc
>> @@ -8416,6 +8416,11 @@ expand_builtin (tree exp, rtx target, rtx subtarget, 
>> machine_mode mode,
>> case BUILT_IN_ADJUST_DESCRIPTOR:
>>   return expand_builtin_adjust_descriptor (exp);
>> 
>> +case BUILT_IN_NESTED_PTR_CREATED:
>> +case BUILT_IN_NESTED_PTR_DELETED:
> 
> Unsure if it is ok to have the BUILT_IN_ names so different from the actual
> functions, if they shouldn't be
> BUILT_IN_GCC_NESTED_FUNC_PTR_{CREATED,DELETED} instead.
> The missing __ is what happens even with BUILT_IN_CLEAR_CACHE / __clear_cache.
> 
>> +  break; /* At present, no expansion, just call the function.  */
>> +
>> +
> 
> Just one empty newline, not 2.
> 
>> case BUILT_IN_FORK:
>> case BUILT_IN_EXECL:
>> case BUILT_IN_EXECV:
>> diff --git a/gcc/builtins.def b/gcc/builtins.def
>> index 4d97ca0eec9..fd040eb8d80 100644
>> --- a/gcc/builtins.def
>> +++ b/gcc/builtins.def
>> @@ -1084,8 +1084,8 @@ DEF_BUILTIN_STUB (BUILT_IN_ADJUST_TRAMPOLINE, 
>> "__builtin_adjust_trampoline")
>> DEF_BUILTIN_STUB (BUILT_IN_INIT_DESCRIPTOR, "__builtin_init_descriptor")
>> DEF_BUILTIN_STUB (BUILT_IN_ADJUST_DESCRIPTOR, "__builtin_adjust_descriptor")
>> DEF_BUILTIN_STUB (BUILT_IN_NONLOCAL_GOTO, "__builtin_nonlocal_goto")
>> -DEF_BUILTIN_STUB (BUILT_IN_NESTED_PTR_CREATED, 
>> "__builtin_nested_func_ptr_created")
>> -DEF_BUILTIN_STUB (BUILT_IN_NESTED_PTR_DELETED, 
>> "__builtin_nested_func_ptr_deleted")
>> +DEF_EXT_LIB_BUILTIN (BUILT_IN_NESTED_PTR_CREATED, 
>> "__gcc_nested_func_ptr_created", BT_FN_VOID_PTR_PTR_PTR, ATTR_NOTHROW_LIST)
>> +DEF_EXT_LIB_BUILTIN (BUILT_IN_NESTED_PTR_DELETED, 
>> "__gcc_nested_func_ptr_deleted", BT_FN_VOID, ATTR_NOTHROW_LIST)
> 
> See above.
> 
> Otherwise LGTM

This is what I pushed, thanks
Iain


From 837827f8f2542c36ba5944b4da0a76ea6a64b08b Mon Sep 17 00:00:00 2001
From: Iain Sandoe 
Date: Tue, 16 Jan 2024 10:21:14 +
Subject: [PATCH] Fix __builtin_nested_func_ptr_{created,deleted} symbol
 versions [PR113402]

The symbols for the functions supporting heap-based trampolines were
exported at an incorrect symbol version, the following patch fixes that.

As requested in the PR, this also renames __builtin_nested_func_ptr* to
__gcc_nested_func_ptr*.  In carrying our the rename, we move the builtins
to use DEF_EXT_LIB_BUILTIN.

PR libgcc/113402

gcc/ChangeLog:

* builtins.cc (expand_builtin): Handle BUILT_IN_GCC_NESTED_PTR_CREATED
and BUILT_IN_GCC_NESTED_PTR_DELETED.
* builtins.def (BUILT_IN_GCC_NESTED_PTR_CREATED,
BUILT_IN_GCC_NESTED_PTR_DELETED): Make these builtins LIB-EXT and
rename the library fallbacks to __gcc_nested_func_ptr_created and
__gcc_nested_func_ptr_deleted.
* doc/invoke.texi: Rename these to __gcc_nested_func_ptr_created
and __gcc_nested_func_ptr_deleted.
* tree-nested.cc (finalize_nesting_tree_1): Use builtin_explicit for
BUILT_IN_GCC_NESTED_PTR_CREATED and BUILT_IN_GCC_NESTED_PTR_DELETED.
* tree.cc (build_common_builtin_nodes): Build the
BUILT_IN_GCC_NESTED_PTR_CREATED and BUILT_IN_GCC_NESTED_PTR_DELETED 
local
builtins only for non-explicit.

libgcc/ChangeLog:

* config/aarch64/heap-trampoline.c: Rename
__builtin_nested_func_ptr_created to __gcc_nested_func_ptr_created and
__builtin_nested_func_ptr_deleted to __gcc_nested_func_ptr_deleted.
* config/i386/heap-trampoline.c: Likewise.
* libgcc2.h: Likewise.
* libgcc-std.ver.in (GCC_7.0.0): Likewise and then move
__gcc_nested_func_ptr_created and
__gcc_nested_func_ptr_deleted from this symbol version to ...
(GCC_14.0.0): ... this one.

Signed-off-by: Iain Sandoe 
Co-authored-by: Jakub Jelinek  
---
 gcc/builtins.cc |  4 
 gcc/builtins.def|  4 ++--
 gcc/doc/invoke.texi |  4 ++--
 gcc/tree-nested.cc  |  4 ++--
 gcc/tree.cc | 31 ++---
 libgcc/config/aarch64/heap-trampoline.c |  8 +++
 libgcc/config/i386/heap-trampoline.c|  8 +++
 libgcc/libgcc-std.ver.in|  5 ++--
 libgcc/libgcc2.h|  4 ++--
 9 files changed, 40 insertions(+), 32 deletions(-)

diff --git a/gcc/builtins.cc b/gcc/builtins.cc
index 09f2354f114..a0bd82c7981 100644
--- a/gcc/builtins.cc
+++ b/gcc/builtins.cc
@@ -8416,6 +8416,10 @@ expand_builtin (tree exp, rtx target, rtx subtarget, 
machine_mode mode,
 case BUILT_IN_ADJUST_DESCRIPTOR:
   return expand_builtin_adjust_descriptor (exp);
 
+case BUILT_IN_GCC_NESTED_PTR_CREATED:
+case BUILT_IN_GCC_NESTED_PTR_DELETED:
+  break; /* At present, no expansion, just call the function.  */
+
 case BUILT_IN_FORK:
 case BUILT_IN_EXECL:
 case BUILT_IN_EXECV:
diff --gi

[pushed] testsuite, Objective-C: Fix duplicate libobjc cases.

[Iain Sandoe]

tested on i686, powerpc, x86_64 Darwin, x86_64, aarch64 Linux, pushed
to trunk, thanks,
Iain

--- 8< ---

Two of the encode testcases include '-lobjc' as their dg-options.
Since the library is already appended as part of the generic testsuite
handling,  this means that two instances appear on the link line leading
to spurious warnings from Darwin's new linker.

gcc/testsuite/ChangeLog:

* obj-c++.dg/encode-10.mm: Remove unneeded '-lobjc' option addition.
* obj-c++.dg/encode-9.mm: Likewise.

Signed-off-by: Iain Sandoe 
---
 gcc/testsuite/obj-c++.dg/encode-10.mm | 1 -
 gcc/testsuite/obj-c++.dg/encode-9.mm  | 1 -
 2 files changed, 2 deletions(-)

diff --git a/gcc/testsuite/obj-c++.dg/encode-10.mm 
b/gcc/testsuite/obj-c++.dg/encode-10.mm
index 2b3af88dcb1..2477400b7f3 100644
--- a/gcc/testsuite/obj-c++.dg/encode-10.mm
+++ b/gcc/testsuite/obj-c++.dg/encode-10.mm
@@ -1,5 +1,4 @@
 /* Test for @encode in templates.  */
-/* { dg-options "-lobjc" } */
 /* { dg-do run } */
 #include
 #include 
diff --git a/gcc/testsuite/obj-c++.dg/encode-9.mm 
b/gcc/testsuite/obj-c++.dg/encode-9.mm
index 6b064dfdc09..4fdb5fa50fb 100644
--- a/gcc/testsuite/obj-c++.dg/encode-9.mm
+++ b/gcc/testsuite/obj-c++.dg/encode-9.mm
@@ -1,5 +1,4 @@
 /* Test than @encode is properly instantiated. */
-/* { dg-options "-lobjc" } */
 /* { dg-do run } */
 
 #include
-- 
2.39.2 (Apple Git-143)

Re: [PATCH] Fortran: use name of array component in runtime error message [PR30802]

[Mikael Morin]

Le 24/01/2024 à 22:39, Harald Anlauf a écrit :

Dear all,

this patch is actually only a followup fix to generate the proper name
of an array reference in derived-type components for the runtime error
message generated for the bounds-checking code.  Without the proper
part ref, not only a user may get confused: I was, too...

The testcase is compile-only, as it is only important to check the
strings used in the error messages.

Regtested on x86_64-pc-linux-gnu.  OK for mainline?

Thanks,
Harald


Hello,

the change proper looks good, and is an improvement.  But I'm a little 
concerned by the production of references like in the test x1%vv%z which 
could be confusing and is strictly speaking invalid fortran (multiple 
non-scalar components).  Did you consider generating x1%vv(?,?)%zz or 
x1%vv(...)%z or similar?


There is another nit about the test, which has dg-output and 
dg-shouldfail despite being only a compile-time test.


Otherwise looks good.

Mikael

[PATCH] jit: Ensure ssize_t is defined.

[Iain Sandoe]

Tested on i686, x86_64 Darwin, x86_64 Linux,
OK for trunk?

--- 8< ---

On some targets it seems that ssize_t is not defined by any of the
headers transitively included by .  This leads to a bootstrap
fail when jit is enabled.

The fix proposed here is to include sys/types.h when it is available
since that is where Posix specifies that ssize_t is defined.

gcc/jit/ChangeLog:

* libgccjit.h: Conditionally include  where it is
available to ensure declaration of ssize_t.

Signed-off-by: Iain Sandoe 
---
 gcc/jit/libgccjit.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/gcc/jit/libgccjit.h b/gcc/jit/libgccjit.h
index 235cab053e0..db4f27a48bf 100644
--- a/gcc/jit/libgccjit.h
+++ b/gcc/jit/libgccjit.h
@@ -21,6 +21,9 @@ along with GCC; see the file COPYING3.  If not see
 #define LIBGCCJIT_H
 
 #include 
+#if __has_include()
+# include   /* For ssize_t.  */
+#endif
 
 #ifdef __cplusplus
 extern "C" {
-- 
2.39.2 (Apple Git-143)

[pushed] Objective-C, Darwin: Do not overalign CFStrings and Objective-C metadata.

[Iain Sandoe]

Tested on i686, powerpc, x86_64 Darwin, x86_64, aarch64 Linux, pushed
to trunk, thanks,
Iain

--- 8< ---

We have reports of regressions in both Objective-C and Objective-C++ on
Darwin23 (macOS 14).  In some cases, these are linker warnings about the
alignment of CFString constants; in other cases the built executables
crash during runtime initialization.  The underlying issue is the same in
both cases; since the objects (CFStrings, Objective-C meta-data) are TU-
local, we are choosing to increase their alignment for efficiency - to
values greater than ABI alignment.

However, although these objects are TU-local, they are also visible to the
linker (since they are placed in specific named sections).  In many cases
the metadata can be regarded as tables of data, and thus it is expected
that these sections can be concatenated from multiple TUs and the data
treated as tabular.  In order for this to work the data cannot be allowed
to exceed ABI alignment - which leads to the crashes.

For GCC-15+ it would be nice to find a more elegant solution to this issue
(perhaps by adjusting the concept of binds-locally to exclude specific
named sections) - but I do not want to do that in stage 4.

The solution here is to force the alignment to be preserved as created by
setting DECL_USER_ALIGN on the relevant objects.

gcc/ChangeLog:

* config/darwin.cc (darwin_build_constant_cfstring): Prevent over-
alignment of CFString constants by setting DECL_USER_ALIGN.

gcc/objc/ChangeLog:

* objc-next-runtime-abi-02.cc (build_v2_address_table): Prevent
over-alignment of Objective-C metadata by setting DECL_USER_ALIGN
on relevant variables.
(build_v2_protocol_list_address_table): Likewise.
(generate_v2_protocol_list): Likewise.
(generate_v2_meth_descriptor_table): Likewise.
(generate_v2_meth_type_list): Likewise.
(generate_v2_property_table): Likewise.
(generate_v2_dispatch_table): Likewise.
(generate_v2_ivars_list): Likewise.
(generate_v2_class_structs): Likewise.
(build_ehtype): Likewise.
* objc-runtime-shared-support.cc (generate_strings): Likewise.

Signed-off-by: Iain Sandoe 
---
 gcc/config/darwin.cc|  1 +
 gcc/objc/objc-next-runtime-abi-02.cc| 18 +++---
 gcc/objc/objc-runtime-shared-support.cc |  4 
 3 files changed, 20 insertions(+), 3 deletions(-)

diff --git a/gcc/config/darwin.cc b/gcc/config/darwin.cc
index 7f43718820b..9e5d64e6f32 100644
--- a/gcc/config/darwin.cc
+++ b/gcc/config/darwin.cc
@@ -3909,6 +3909,7 @@ darwin_build_constant_cfstring (tree str)
   /* global namespace.  */
   DECL_CONTEXT (var) = NULL_TREE;
   DECL_INITIAL (var) = constructor;
+  DECL_USER_ALIGN (var) = 1;
   lang_hooks.decls.pushdecl (var);
   rest_of_decl_compilation (var, 1, 0);
   desc->ccf_str = var;
diff --git a/gcc/objc/objc-next-runtime-abi-02.cc 
b/gcc/objc/objc-next-runtime-abi-02.cc
index a622f4cbf4e..b3de6d789a5 100644
--- a/gcc/objc/objc-next-runtime-abi-02.cc
+++ b/gcc/objc/objc-next-runtime-abi-02.cc
@@ -2249,6 +2249,7 @@ build_v2_address_table (vec *src, const char 
*nam, tree attr)
   DECL_PRESERVE_P (decl) = 1;
   expr = objc_build_constructor (type, initlist);
   OBJCMETA (decl, objc_meta, attr);
+  DECL_USER_ALIGN (decl) = 1;
   finish_var_decl (decl, expr);
 }
 
@@ -2323,8 +2324,9 @@ build_v2_protocol_list_address_table (void)
decl = create_global_decl (objc_protocol_type, buf, /*is def=*/true);
   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;
+  DECL_USER_ALIGN (decl) = 1;
+  finish_var_decl (decl, expr);
 }
 
 /* TODO: delete the vec.  */
@@ -2402,6 +2404,7 @@ generate_v2_protocol_list (tree i_or_p, tree klass_ctxt)
   /* ObjC2 puts all these in the base section.  */
   OBJCMETA (refs_decl, objc_meta, meta_base);
   DECL_PRESERVE_P (refs_decl) = 1;
+  DECL_USER_ALIGN (refs_decl) = 1;
   finish_var_decl (refs_decl,
   objc_build_constructor (TREE_TYPE (refs_decl),initlist));
   return refs_decl;
@@ -2510,6 +2513,7 @@ generate_v2_meth_descriptor_table (tree chain, tree 
protocol,
   CONSTRUCTOR_APPEND_ELT (v, NULL_TREE, initlist);
   /* Get into the right section.  */
   OBJCMETA (decl, objc_meta, attr);
+  DECL_USER_ALIGN (decl) = 1;
   finish_var_decl (decl, objc_build_constructor (method_list_template, v));
   return decl;
 }
@@ -2528,13 +2532,14 @@ generate_v2_meth_type_list (vec& all_meths, tree 
protocol,
IDENTIFIER_POINTER (PROTOCOL_NAME (protocol)));
   tree decl = start_var_decl (list_type, nam);
   free (nam);
-  OBJCMETA (decl, objc_meta, meta_base);
   vec *v = NULL;
 
   for (unsigned i = 0; i < size; ++i)
 CONSTRUCTOR_APPEND_ELT (v, NULL_TREE,
add_objc_string (METHOD_ENCODING (all_

Re: [PATCH] Fortran: NULL actual to optional dummy with VALUE attribute [PR113377]

[Mikael Morin]

Le 25/01/2024 à 22:26, Harald Anlauf a écrit :

Dear all,

this is the third patch in a series that addresses dummy arguments
with the VALUE attribute, now handling the passing of NULL actual
arguments.  It is based on the refactoring in the previous patch
and reuses the handling of absent arguments.

Regtested on x86_64-pc-linux-gnu.  OK for mainline?

Thanks,
Harald


OK, thanks.

[PATCH 0/2] libgcc: Make heap trampoline support dynamic [PR113403].

[Iain Sandoe]

This series follows Jakub's suggestion in the PR (for Linux in the first patch)
and handles Darwin-specific cases (in the second).

Sorry this has taken a while, the Darwin permutations had some glitches which
necessitated re-tests on several OS versions.

Tested on x86_64 (and aarch64) Darwin, x86_64, aarch64 Linux.
OK for trunk for patch 1 and the non-Darwin parts of patch2.
thanks,
Iain

[PATCH 1/2] libgcc: Make heap trampoline support dynamic [PR113403].

[Iain Sandoe]

This removes the heap trampoline support functions from libgcc.a and
adds them to libgcc_eh.a.  They are also present in libgcc_s.

PR libgcc/113403

libgcc/ChangeLog:

* config/aarch64/t-heap-trampoline: Move the heap trampoline
support functions from libgcc.a to libgcc_eh.a.
* config/i386/t-heap-trampoline: Likewise.
---
 libgcc/config/aarch64/t-heap-trampoline | 3 ++-
 libgcc/config/i386/t-heap-trampoline| 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/libgcc/config/aarch64/t-heap-trampoline 
b/libgcc/config/aarch64/t-heap-trampoline
index b22480800b2..6468fb8704f 100644
--- a/libgcc/config/aarch64/t-heap-trampoline
+++ b/libgcc/config/aarch64/t-heap-trampoline
@@ -16,4 +16,5 @@
 # along with GCC; see the file COPYING3.  If not see
 # .
 
-LIB2ADD += $(srcdir)/config/aarch64/heap-trampoline.c
+LIB2ADDEH += $(srcdir)/config/aarch64/heap-trampoline.c
+LIB2ADDEHSHARED += $(srcdir)/config/aarch64/heap-trampoline.c
diff --git a/libgcc/config/i386/t-heap-trampoline 
b/libgcc/config/i386/t-heap-trampoline
index 613f635b1f6..728c1e26a92 100644
--- a/libgcc/config/i386/t-heap-trampoline
+++ b/libgcc/config/i386/t-heap-trampoline
@@ -16,4 +16,5 @@
 # along with GCC; see the file COPYING3.  If not see
 # .
 
-LIB2ADD += $(srcdir)/config/i386/heap-trampoline.c
+LIB2ADDEH += $(srcdir)/config/i386/heap-trampoline.c
+LIB2ADDEHSHARED += $(srcdir)/config/aarch64/heap-trampoline.c
-- 
2.39.2 (Apple Git-143)

[PATCH 2/2] libgcc: Make heap trampoline support dynamic [PR113403].

[Iain Sandoe]

In order to handle system security constraints during GCC build
and test and that most platform versions cannot link to libgcc_eh
since the unwinder there is incompatible with the system one.

1. We make the support functions weak definitions.
2. We include them as a CRT for platform conditions that do not
   allow libgcc_eh.
3. We ensure that the weak symbols are exported from DSOs (which
   includes exes on Darwin) so that the dynamic linker will
   pick one instance (which avoids duplication of trampoline
   caches).

PR libgcc/113403

gcc/ChangeLog:

* config/darwin.h (DARWIN_SHARED_WEAK_ADDS, DARWIN_WEAK_CRTS): New.
(REAL_LIBGCC_SPEC): Move weak CRT handling to separate spec.
* config/i386/darwin.h (DARWIN_HEAP_T_LIB): New.
* config/i386/darwin32-biarch.h (DARWIN_HEAP_T_LIB): New.
* config/i386/darwin64-biarch.h (DARWIN_HEAP_T_LIB): New.
* config/rs6000/darwin.h (DARWIN_HEAP_T_LIB): New.

libgcc/ChangeLog:

* config.host: Build libheap_t.a for i686/x86_64 Darwin.
* config/aarch64/heap-trampoline.c (HEAP_T_ATTR): New.
(allocate_tramp_ctrl): Allow a target to build this as a weak def.
(__gcc_nested_func_ptr_created): Likewise.
* config/i386/heap-trampoline.c (HEAP_T_ATTR): New.
(allocate_tramp_ctrl): Allow a target to build this as a weak def.
(__gcc_nested_func_ptr_created): Likewise.
* config/t-darwin: Build libheap_t.a (a CRT with heap trampoline
support).
---
 gcc/config/darwin.h | 43 -
 gcc/config/i386/darwin.h|  2 ++
 gcc/config/i386/darwin32-biarch.h   |  3 ++
 gcc/config/i386/darwin64-biarch.h   |  3 ++
 gcc/config/rs6000/darwin.h  |  3 ++
 libgcc/config.host  |  7 ++--
 libgcc/config/aarch64/heap-trampoline.c |  8 +
 libgcc/config/i386/heap-trampoline.c|  8 +
 libgcc/config/t-darwin  | 13 
 9 files changed, 72 insertions(+), 18 deletions(-)

diff --git a/gcc/config/darwin.h b/gcc/config/darwin.h
index cb96d67b3b1..31019a0c49d 100644
--- a/gcc/config/darwin.h
+++ b/gcc/config/darwin.h
@@ -314,13 +314,17 @@ extern GTY(()) int darwin_ms_struct;
 # define DARWIN_RPATH_LINK \
 "%{!r:%{!nostdlib:%{!nodefaultrpaths:%(darwin_rpaths)}}}"
 # define DARWIN_SHARED_LIBGCC "-lgcc_s.1.1"
+# define DARWIN_SHARED_WEAK_ADDS " "
 #else
 # define DARWIN_RPATH_LINK ""
 # define DARWIN_SHARED_LIBGCC \
-"%:version-compare(!> 10.11 mmacosx-version-min= -lgcc_s.1.1) \
- %:version-compare(>= 10.11 mmacosx-version-min= -lemutls_w) "
+"%:version-compare(!> 10.11 mmacosx-version-min= -lgcc_s.1.1)"
+# define DARWIN_SHARED_WEAK_ADDS \
+"%{%:version-compare(>= 10.11 mmacosx-version-min= -lemutls_w): \
+ " DARWIN_HEAP_T_LIB "}"
 #endif
 
+
 /* We might elect to add a path even when this compiler does not use embedded
run paths, so that we can use libraries from an alternate compiler that is
using embedded runpaths.  */
@@ -398,7 +402,9 @@ extern GTY(()) int darwin_ms_struct;
 %{e*} %{r} \
 %{o*}%{!o:-o a.out} \
 %{!r:%{!nostdlib:%{!nostartfiles:%S}}} \
-%{L*} %(link_libgcc) %o \
+%{L*} %(link_libgcc) \
+%{!r:%{!nostdlib:%{!nodefaultlibs: " DARWIN_WEAK_CRTS "}}} \
+%o \
 %{!r:%{!nostdlib:%{!nodefaultlibs:\
   %{fprofile-arcs|fprofile-generate*|coverage:-lgcov} \
   %{fopenacc|fopenmp|%:gt(%{ftree-parallelize-loops=*:%*} 1): \
@@ -412,15 +418,15 @@ extern GTY(()) int darwin_ms_struct;
   %(link_ssp) \
   %:version-compare(>< 10.6 10.7 mmacosx-version-min= -ld10-uwfef) \
   %(link_gcc_c_sequence) \
-  %{!nodefaultexport:%{dylib|dynamiclib|bundle: \
-   %:version-compare(>= 10.11 asm_macosx_version_min= -U) \
-   %:version-compare(>= 10.11 asm_macosx_version_min= 
___emutls_get_address) \
-   %:version-compare(>= 10.11 asm_macosx_version_min= -exported_symbol) \
-   %:version-compare(>= 10.11 asm_macosx_version_min= 
___emutls_get_address) \
-   %:version-compare(>= 10.11 asm_macosx_version_min= -U) \
-   %:version-compare(>= 10.11 asm_macosx_version_min= 
___emutls_register_common) \
-   %:version-compare(>= 10.11 asm_macosx_version_min= -exported_symbol) \
-   %:version-compare(>= 10.11 asm_macosx_version_min= 
___emutls_register_common) \
+  %{!nodefaultexport: \
+   %{%:version-compare(>= 10.11 asm_macosx_version_min= -U): \
+  ___emutls_get_address -exported_symbol ___emutls_get_address \
+ -U ___emutls_register_common \
+ -exported_symbol ___emutls_register_common \
+ -U ___gcc_nested_func_ptr_created \
+ -exported_symbol ___gcc_nested_func_ptr_created \
+ -U ___gcc_nested_func_ptr_deleted \
+ -exported_symbol ___gcc_nested_func_ptr_deleted \
   }} \
 }}}\
 %{!r:%{!nostdlib:%{!nostartfiles:%E}}} %{T*} %{F*} "\
@@ -542,16 +548,21 @@ extern GTY(()) int darwin_ms_struct;
 #undef REAL_LIBGCC_SPEC
 #de

[PATCH] testsuite, GDC: Update link flags [PR112861].

[Iain Sandoe]

Tested on i686, x86_64, aarch64 Darwin, x86_64, aarch64 Linux,
OK for trunk?
thanks, 
Iain

--- 8< ---

The regressions here are because we do not generate a runpath for
the uninstalled libstdc++.  This patch updates the link flags handling
to simplify it.

We need to add options to locate both libgphobos and libstdc++
Usually '-L' options are added to point to the relevant directories for
the uninstalled libraries.

In cases where libraries are available as both shared and convenience
some additional checks are made.

For some targets -static- options are handled by specs substitution
and need a '-B' option rather than '-L'.  For Darwin, when embedded
runpaths are in use (the default for all versions after macOS 10.11),
'-B' is also needed to provide the runpath.

When '-B' is used, this results in a '-L' for each path that exists (so
that appending a '-L' as well is a needless duplicate).  There are also
cases where tools warn for duplicates, leading to spurious fails.
Therefore the objective is to add a single -B/-L option for each needed
path.

PR target/112861

gcc/testsuite/ChangeLog:

* lib/gdc.exp: Decide on whether to present -B or -L to reference
the paths to uninstalled libphobos and libstdc++ and use that to
generate the link flags.
---
 gcc/testsuite/lib/gdc.exp | 40 ---
 1 file changed, 37 insertions(+), 3 deletions(-)

diff --git a/gcc/testsuite/lib/gdc.exp b/gcc/testsuite/lib/gdc.exp
index 3045aa82918..3c284229609 100644
--- a/gcc/testsuite/lib/gdc.exp
+++ b/gcc/testsuite/lib/gdc.exp
@@ -133,6 +133,28 @@ proc gdc_link_flags { paths } {
set include_cxx_flags 0
 }
 
+# We need to add options to locate libgphobos and libstdc++
+# Usually '-L' options are added to point to the relevant directories for
+# the uninstalled libraries.
+
+# In cases where libraries are available as both shared and convenience
+# some additional checks are made.
+
+# For some targets -static- options are handled by specs substitution
+# and need a '-B' option rather than '-L'.  For Darwin, when embedded
+# runpaths are in use (the default for all versions after macOS 10.11),
+# '-B' is also needed to provide the runpath.
+# When '-B' is used, this results in a '-L' for each path that exists (so
+# that appending a '-L' as well is a needless duplicate).  There are also
+# cases where tools warn for duplicates, leading to spurious fails.
+# Therefore the objective of the code below is to add just one '-L' or
+# '-B' for each of the libraries.
+
+set target_wants_B_option 0
+if { [istarget *-*-darwin9* ] || [istarget *-*-darwin\[12\]* ] } {
+  set target_wants_B_option 1
+}
+
 if { $gccpath != "" } {
# Path to libgphobos.spec.
append flags "-B${gccpath}/libphobos/src "
@@ -143,7 +165,11 @@ proc gdc_link_flags { paths } {
 
if { [file exists "${gccpath}/libphobos/src/.libs/libgphobos.a"] \
 || [file exists 
"${gccpath}/libphobos/src/.libs/libgphobos.${shlib_ext}"] } {
-   append flags "-L${gccpath}/libphobos/src/.libs "
+   if { $target_wants_B_option } {
+   append flags "-B${gccpath}/libphobos/src/.libs "
+   } else {
+   append flags "-L${gccpath}/libphobos/src/.libs "
+   }
append ld_library_path ":${gccpath}/libphobos/src/.libs"
}
# Static linking is default. If only the shared lib is available adjust
@@ -163,7 +189,11 @@ proc gdc_link_flags { paths } {
if $include_cxx_flags {
if { [file exists "${gccpath}/libstdc++-v3/src/.libs/libstdc++.a"] \
 || [file exists 
"${gccpath}/libstdc++-v3/src/.libs/libstdc++.${shlib_ext}"] } {
-   append flags "-L${gccpath}/libstdc++-v3/src/.libs "
+   if { $target_wants_B_option } {
+   append flags "-B${gccpath}/libstdc++-v3/src/.libs "
+   } else {
+   append flags "-L${gccpath}/libstdc++-v3/src/.libs "
+   }
append ld_library_path ":${gccpath}/libstdc++-v3/src/.libs"
}
}
@@ -173,7 +203,11 @@ proc gdc_link_flags { paths } {
 
set libphobos [lookfor_file ${tool_root_dir} libgphobos]
if { $libphobos != "" } {
-   append flags "-B${libphobos} -L${libphobos} "
+   if { $target_wants_B_option } {
+ append flags "-B${libphobos} "
+   } else { 
+ append flags " -L${libphobos} "
+   }
append ld_library_path ":${libphobos}"
}
set libiberty [lookfor_file ${tool_root_dir} libiberty]
-- 
2.39.2 (Apple Git-143)

[PATCH] testsuite, gfortan: Update link flags [PR112862].

[Iain Sandoe]

Tested on i686, x86_64, aarch64 Darwin, x86_64, aarch64 Linux,
OK for trunk?
thanks, 
Iain

--- 8< ---

The regressions here are caused by two issues:
1. In some cases there is no generated runpath for libatomic
2. In other cases there are duplicate paths.

This patch simplifies the addition of the options in the main
gfortran exp and removes the duplicates elewhere.

We need to add options to locate libgfortran and the dependent libs
libquadmath (supporting REAL*16) and libatomic (supporting operations
used by coarrays).  Usually '-L' options are added to point to the
relevant directories for the uninstalled libraries.

In cases where libraries are available as both shared and convenience
some additional checks are made.

For some targets -static- options are handled by specs substitution
and need a '-B' option rather than '-L'.  For Darwin, when embedded
runpaths are in use (the default for all versions after macOS 10.11),
'-B' is also needed to provide the runpath.

When '-B' is used, this results in a '-L' for each path that exists (so
that appending a '-L' as well is a needless duplicate).  There are also
cases where tools warn for duplicates, leading to spurious fails.

PR target/112862

gcc/testsuite/ChangeLog:

* gfortran.dg/coarray/caf.exp: Remove duplicate additions of
libatomic handling.
* gfortran.dg/dg.exp: Likewise.
* lib/gfortran.exp: Decide on whether to present -B or -L to
reference the paths to uninstalled libgfortran, libqadmath and
libatomic and use that to generate the link flags.
---
 gcc/testsuite/gfortran.dg/coarray/caf.exp | 16 +
 gcc/testsuite/gfortran.dg/dg.exp  | 20 ---
 gcc/testsuite/lib/gfortran.exp| 73 +++
 3 files changed, 51 insertions(+), 58 deletions(-)

diff --git a/gcc/testsuite/gfortran.dg/coarray/caf.exp 
b/gcc/testsuite/gfortran.dg/coarray/caf.exp
index dae46bd92fa..31c13cd34e5 100644
--- a/gcc/testsuite/gfortran.dg/coarray/caf.exp
+++ b/gcc/testsuite/gfortran.dg/coarray/caf.exp
@@ -70,18 +70,6 @@ proc dg-compile-aux-modules { args } {
 }
 }
 
-# Add -latomic only where supported.  Assume built-in support elsewhere.
-set maybe_atomic_lib ""
-if [check_effective_target_libatomic_available] {
-if ![is_remote host] {
-   if [info exists TOOL_OPTIONS] {
-   set maybe_atomic_lib "[atomic_link_flags [get_multilibs 
${TOOL_OPTIONS}]]"
-   } else {
-   set maybe_atomic_lib "[atomic_link_flags [get_multilibs]]"
-   }
-}
-}
-
 # Main loop.
 foreach test [lsort [glob -nocomplain $srcdir/$subdir/*.\[fF\]{,90,95,03,08} 
]] {
 # If we're only testing specific files and this isn't one of them, skip it.
@@ -105,14 +93,14 @@ foreach test [lsort [glob -nocomplain 
$srcdir/$subdir/*.\[fF\]{,90,95,03,08} ]]
 foreach flags $option_list {
verbose "Testing $nshort (single), $flags" 1
 set gfortran_aux_module_flags "-fcoarray=single $flags"
-   dg-test $test "-fcoarray=single $flags" $maybe_atomic_lib
+   dg-test $test "-fcoarray=single $flags" {}
cleanup-modules ""
 }
 
 foreach flags $option_list {
verbose "Testing $nshort (libcaf_single), $flags" 1
 set gfortran_aux_module_flags "-fcoarray=lib $flags -lcaf_single"
-   dg-test $test "-fcoarray=lib $flags -lcaf_single" $maybe_atomic_lib
+   dg-test $test "-fcoarray=lib $flags -lcaf_single" {}
cleanup-modules ""
 }
 }
diff --git a/gcc/testsuite/gfortran.dg/dg.exp b/gcc/testsuite/gfortran.dg/dg.exp
index f936fd38644..7a9cb89c194 100644
--- a/gcc/testsuite/gfortran.dg/dg.exp
+++ b/gcc/testsuite/gfortran.dg/dg.exp
@@ -54,27 +54,7 @@ proc dg-compile-aux-modules { args } {
 }
 }
 
-# coarray tests might need libatomic.  Assume that it is either not needed or
-# provided by builtins if it's not available.
-set maybe_atomic_lib ""
-if [check_effective_target_libatomic_available] {
-if ![is_remote host] {
-   if [info exists TOOL_OPTIONS] {
-   set maybe_atomic_lib "[atomic_link_flags [get_multilibs 
${TOOL_OPTIONS}]]"
-   } else {
-   set maybe_atomic_lib "[atomic_link_flags [get_multilibs]]"
-   }
-} else {
-set maybe_atomic_lib ""
-}
-}
-
 set all_flags $DEFAULT_FFLAGS
-if { $maybe_atomic_lib != "" } {
-   foreach f $maybe_atomic_lib {
- lappend all_flags $f
-   }
-}
 
 # Main loop.
 gfortran-dg-runtest [lsort \
diff --git a/gcc/testsuite/lib/gfortran.exp b/gcc/testsuite/lib/gfortran.exp
index c3e258b410b..1ccb81ccec5 100644
--- a/gcc/testsuite/lib/gfortran.exp
+++ b/gcc/testsuite/lib/gfortran.exp
@@ -79,6 +79,7 @@ proc gfortran_link_flags { paths } {
 global ld_library_path
 global GFORTRAN_UNDER_TEST
 global shlib_ext
+global ENABLE_DARWIN_AT_RPATH
 
 set gccpath ${paths}
 set libio_dir ""
@@ -87,39 +88,63 @@ proc gfortran_link_flags { paths } {
 set shlib_ext [get_shlib_extension]
 verbose "shared lib extension: $shlib_ext"
 
+ 

[PATCH] testsuite, libphobos: Update link flags [PR112864].

[Iain Sandoe]

Tested on i686, x86_64, aarch64 Darwin, x86_64, aarch64 Linux,
OK for trunk?
thanks, 
Iain

--- 8< ---

The regressions here are primarily from duplicated '-B' additions.

We remove the duplicate on the link line.
We also make sure that platforms with extensions other than .so for
shared libs will have the correct paths.

PR target/112864

libphobos/ChangeLog:

* testsuite/lib/libphobos.exp: Use ${shlib_ext} instead of
hard-wiring '.so'.
* testsuite/testsuite_flags.in: Remove duplicate -B option
for spec file path.
---
 libphobos/testsuite/lib/libphobos.exp  | 2 +-
 libphobos/testsuite/testsuite_flags.in | 6 ++
 2 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/libphobos/testsuite/lib/libphobos.exp 
b/libphobos/testsuite/lib/libphobos.exp
index 191cafa534d..d4aa433ddc1 100644
--- a/libphobos/testsuite/lib/libphobos.exp
+++ b/libphobos/testsuite/lib/libphobos.exp
@@ -234,7 +234,7 @@ proc libphobos_init { args } {
if { "$mldir" == "." } {
  continue
}
-   if { [llength [glob -nocomplain ${gccdir}/${mldir}/libgcc_s*.so.*]] 
>= 1 } {
+   if { [llength [glob -nocomplain 
${gccdir}/${mldir}/libgcc_s*.${shlib_ext}*]] >= 1 } {
  append ld_library_path ":${gccdir}/${mldir}"
}
  }
diff --git a/libphobos/testsuite/testsuite_flags.in 
b/libphobos/testsuite/testsuite_flags.in
index 528cff4bf13..8a412d2f1fa 100755
--- a/libphobos/testsuite/testsuite_flags.in
+++ b/libphobos/testsuite/testsuite_flags.in
@@ -46,10 +46,8 @@ case ${query} in
   echo ${GDCPATHS_default} ${GDCPATHS_config}
   ;;
 --gdcldflags)
-  GDCLDFLAGS="-B${BUILD_DIR}/src
-  -B${BUILD_DIR}/libdruntime/gcc
-  -B${BUILD_DIR}/src/.libs
-  -L${BUILD_DIR}/src/.libs"
+  GDCLDFLAGS="-B${BUILD_DIR}/libdruntime/gcc
+  -B${BUILD_DIR}/src/.libs"
   echo ${GDCLDFLAGS}
   ;;
 *)
-- 
2.39.2 (Apple Git-143)

[PATCH] testsuite, Objective-C++: Update link flags [PR112863].

[Iain Sandoe]

Tested on i686, x86_64, aarch64 Darwin, x86_64, aarch64 Linux,
OK for trunk?
thanks, 
Iain

--- 8< ---

These regressions are caused by missing or duplicate runpaths which
now fire linker warnings.

We need to add options to locate libobjc (and on Darwin libobjc-gnu)
along with libstdc++.
Usually '-L' options are added to point to the relevant directories for
the uninstalled libraries.

In cases where libraries are available as both shared and convenience
some additional checks are made.

For some targets -static- options are handled by specs substitution
and need a '-B' option rather than '-L'.  For Darwin, when embedded
runpaths are in use (the default for all versions after macOS 10.11),
'-B' is also needed to provide the runpath.

When '-B' is used, this results in a '-L' for each path that exists (so
that appending a '-L' as well is a needless duplicate).  There are also
cases where tools warn for duplicates, leading to spurious fails.

PR target/112863

gcc/testsuite/ChangeLog:

* lib/obj-c++.exp: Decide on whether to present -B or -L to
reference the paths to uninstalled libobjc/libobjc-gnu and
libstdc++ and use that to generate the link flags.
---
 gcc/testsuite/lib/obj-c++.exp | 69 +--
 1 file changed, 42 insertions(+), 27 deletions(-)

diff --git a/gcc/testsuite/lib/obj-c++.exp b/gcc/testsuite/lib/obj-c++.exp
index 397b70cb96a..854dc264f9d 100644
--- a/gcc/testsuite/lib/obj-c++.exp
+++ b/gcc/testsuite/lib/obj-c++.exp
@@ -110,34 +110,43 @@ proc obj-c++_link_flags { paths } {
 set shlib_ext [get_shlib_extension]
 verbose "shared lib extension: $shlib_ext"
 
+# We need to add options to locate libobjc/libobjc-gnu and libstdc++
+# Usually '-L' options are added to point to the relevant directories for
+# the uninstalled libraries.
+
+# In cases where libraries are available as both shared and convenience
+# some additional checks are made.
+
+# For some targets -static- options are handled by specs substitution
+# and need a '-B' option rather than '-L'.  For Darwin, when embedded
+# runpaths are in use (the default for all versions after macOS 10.11),
+# '-B' is also needed to provide the runpath.
+# When '-B' is used, this results in a '-L' for each path that exists (so
+# that appending a '-L' as well is a needless duplicate).  There are also
+# cases where tools warn for duplicates, leading to spurious fails.
+# Therefore the objective of the code below is to add just one '-L' or
+# '-B' for each of the libraries.
+
+set target_wants_B_option 0
+if { [istarget *-*-darwin9* ] || [istarget *-*-darwin\[12\]* ] } {
+  set target_wants_B_option 1
+}
+
 if { $gccpath != "" } {
-  if [file exists "${gccpath}/lib/libstdc++.a"] {
-  append ld_library_path ":${gccpath}/lib"
-  }
-  if [file exists "${gccpath}/libg++/libg++.a"] {
-  append flags " -L${gccpath}/libg++ "
-  append ld_library_path ":${gccpath}/libg++"
-  }
-  if [file exists "${gccpath}/libstdc++/libstdc++.a"] {
-  append flags " -L${gccpath}/libstdc++ "
-  append ld_library_path ":${gccpath}/libstdc++"
-  }
-  if [file exists "${gccpath}/libstdc++-v3/src/.libs/libstdc++.a"] {
-  # Allow for %s spec substitutions
-  append flags " -B${gccpath}/libstdc++-v3/src/.libs "
-  append flags " -L${gccpath}/libstdc++-v3/src/.libs "
-  append ld_library_path ":${gccpath}/libstdc++-v3/src/.libs"
-  }
-  # Look for libstdc++.${shlib_ext}.
-  if [file exists 
"${gccpath}/libstdc++-v3/src/.libs/libstdc++.${shlib_ext}"] {
- # Allow for %s spec substitutions
- append flags " -B${gccpath}/libstdc++-v3/src/.libs "
- append flags " -L${gccpath}/libstdc++-v3/src/.libs "
- append ld_library_path ":${gccpath}/libstdc++-v3/src/.libs"
+  if { [file exists "${gccpath}/libstdc++-v3/src/.libs/libstdc++.a"] ||
+ [file exists 
"${gccpath}/libstdc++-v3/src/.libs/libstdc++.${shlib_ext}"] } {
+   if { $target_wants_B_option } {
+   append flags "-B${gccpath}/libstdc++-v3/src/.libs "
+   } else {
+   append flags "-L${gccpath}/libstdc++-v3/src/.libs "
+   }
+   append ld_library_path ":${gccpath}/libstdc++-v3/src/.libs"
   }
+
   if [file exists "${gccpath}/libiberty/libiberty.a"] {
   append flags " -L${gccpath}/libiberty "
   }
+
   if [file exists "${gccpath}/librx/librx.a"] {
   append flags " -L${gccpath}/librx "
   }
@@ -159,9 +168,11 @@ proc obj-c++_link_flags { paths } {
 
   if { $libobjc_dir != "" } {
  set libobjc_dir [file dirname ${libobjc_dir}]
- # Allow for %s spec substitutions
- append flags " -B${libobjc_dir} "
- append flags " -L${libobjc_dir} "
+ if { $target_wants_B_option } {
+   app

Re: [PATCH] testsuite, libphobos: Update link flags [PR112864].

[Iain Buclaw]

Excerpts from Iain Sandoe's message of Januar 28, 2024 4:03 pm:
> Tested on i686, x86_64, aarch64 Darwin, x86_64, aarch64 Linux,
> OK for trunk?
> thanks, 
> Iain
> 

Thanks Iain!

OK. Seems reasonable to me.

Iain.

Re: [PATCH] testsuite, GDC: Update link flags [PR112861].

[Iain Buclaw]

Excerpts from Iain Sandoe's message of Januar 28, 2024 4:02 pm:
> Tested on i686, x86_64, aarch64 Darwin, x86_64, aarch64 Linux,
> OK for trunk?
> thanks, 
> Iain
> 

OK.

Thanks again!

Iain.

Re: [PATCH] testsuite, gfortan: Update link flags [PR112862].

[FX Coudert]

> Tested on i686, x86_64, aarch64 Darwin, x86_64, aarch64 Linux,
> OK for trunk?

Looks good to me. Please leave 48h before pushing for other Fortran maintainers 
to comment if they see something I missed (in particular the coarrays part).

FX

[libatomic PATCH] PR other/113336: Fix libatomic testsuite regressions on ARM.

[Roger Sayle]

This patch is a revised version of the fix for PR other/113336.

This patch has been tested on arm-linux-gnueabihf with --with-arch=armv6
with make bootstrap and make -k check where it fixes all of the FAILs in
libatomic.  Ok for mainline?


2024-01-28  Roger Sayle  
Victor Do Nascimento  

libatomic/ChangeLog
PR other/113336
* Makefile.am: Build tas_1_2_.o on ARCH_ARM_LINUX
* Makefile.in: Regenerate.

Thanks in advance.
Roger
--

diff --git a/libatomic/Makefile.am b/libatomic/Makefile.am
index cfad90124f9..eb04fa2fc60 100644
--- a/libatomic/Makefile.am
+++ b/libatomic/Makefile.am
@@ -139,6 +139,7 @@ if ARCH_ARM_LINUX
 IFUNC_OPTIONS   = -march=armv7-a+fp -DHAVE_KERNEL64
 libatomic_la_LIBADD += $(foreach s,$(SIZES),$(addsuffix 
_$(s)_1_.lo,$(SIZEOBJS)))
 libatomic_la_LIBADD += $(addsuffix _8_2_.lo,$(SIZEOBJS))
+libatomic_la_LIBADD += tas_1_2_.lo
 endif
 if ARCH_I386
 IFUNC_OPTIONS   = -march=i586

Re: [PATCH 1/2] libgcc: Make heap trampoline support dynamic [PR113403].

[Jakub Jelinek]

On Sun, Jan 28, 2024 at 02:07:32PM +, Iain Sandoe wrote:
> This removes the heap trampoline support functions from libgcc.a and
> adds them to libgcc_eh.a.  They are also present in libgcc_s.
> 
>   PR libgcc/113403
> 
> libgcc/ChangeLog:
> 
>   * config/aarch64/t-heap-trampoline: Move the heap trampoline
>   support functions from libgcc.a to libgcc_eh.a.
>   * config/i386/t-heap-trampoline: Likewise.

LGTM.
I'd also default to -shared-libgcc when linking using gcc driver with
the new trampoline option in options unless -static-libgcc has been used,
but that can be done incrementally.

> diff --git a/libgcc/config/aarch64/t-heap-trampoline 
> b/libgcc/config/aarch64/t-heap-trampoline
> index b22480800b2..6468fb8704f 100644
> --- a/libgcc/config/aarch64/t-heap-trampoline
> +++ b/libgcc/config/aarch64/t-heap-trampoline
> @@ -16,4 +16,5 @@
>  # along with GCC; see the file COPYING3.  If not see
>  # .
>  
> -LIB2ADD += $(srcdir)/config/aarch64/heap-trampoline.c
> +LIB2ADDEH += $(srcdir)/config/aarch64/heap-trampoline.c
> +LIB2ADDEHSHARED += $(srcdir)/config/aarch64/heap-trampoline.c
> diff --git a/libgcc/config/i386/t-heap-trampoline 
> b/libgcc/config/i386/t-heap-trampoline
> index 613f635b1f6..728c1e26a92 100644
> --- a/libgcc/config/i386/t-heap-trampoline
> +++ b/libgcc/config/i386/t-heap-trampoline
> @@ -16,4 +16,5 @@
>  # along with GCC; see the file COPYING3.  If not see
>  # .
>  
> -LIB2ADD += $(srcdir)/config/i386/heap-trampoline.c
> +LIB2ADDEH += $(srcdir)/config/i386/heap-trampoline.c
> +LIB2ADDEHSHARED += $(srcdir)/config/aarch64/heap-trampoline.c
> -- 
> 2.39.2 (Apple Git-143)

Jakub

Re: [PATCH 2/2] libgcc: Make heap trampoline support dynamic [PR113403].

[Jakub Jelinek]

On Sun, Jan 28, 2024 at 02:07:33PM +, Iain Sandoe wrote:
> In order to handle system security constraints during GCC build
> and test and that most platform versions cannot link to libgcc_eh
> since the unwinder there is incompatible with the system one.
> 
> 1. We make the support functions weak definitions.
> 2. We include them as a CRT for platform conditions that do not
>allow libgcc_eh.
> 3. We ensure that the weak symbols are exported from DSOs (which
>includes exes on Darwin) so that the dynamic linker will
>pick one instance (which avoids duplication of trampoline
>caches).
> 
>   PR libgcc/113403
> 
> gcc/ChangeLog:
> 
>   * config/darwin.h (DARWIN_SHARED_WEAK_ADDS, DARWIN_WEAK_CRTS): New.
>   (REAL_LIBGCC_SPEC): Move weak CRT handling to separate spec.
>   * config/i386/darwin.h (DARWIN_HEAP_T_LIB): New.
>   * config/i386/darwin32-biarch.h (DARWIN_HEAP_T_LIB): New.
>   * config/i386/darwin64-biarch.h (DARWIN_HEAP_T_LIB): New.
>   * config/rs6000/darwin.h (DARWIN_HEAP_T_LIB): New.
> 
> libgcc/ChangeLog:
> 
>   * config.host: Build libheap_t.a for i686/x86_64 Darwin.
>   * config/aarch64/heap-trampoline.c (HEAP_T_ATTR): New.
>   (allocate_tramp_ctrl): Allow a target to build this as a weak def.
>   (__gcc_nested_func_ptr_created): Likewise.
>   * config/i386/heap-trampoline.c (HEAP_T_ATTR): New.
>   (allocate_tramp_ctrl): Allow a target to build this as a weak def.
>   (__gcc_nested_func_ptr_created): Likewise.
>   * config/t-darwin: Build libheap_t.a (a CRT with heap trampoline
>   support).

The non-darwin parts here (config.host, heap-trampoline.c) here are ok,
I don't know anything about Darwin to judge the rest and you're the
maintainer...

Jakub

Re: [PATCH] Fortran: use name of array component in runtime error message [PR30802]

[Harald Anlauf]

Hi Mikael,

Am 28.01.24 um 12:39 schrieb Mikael Morin:

Le 24/01/2024 à 22:39, Harald Anlauf a écrit :

Dear all,

this patch is actually only a followup fix to generate the proper name
of an array reference in derived-type components for the runtime error
message generated for the bounds-checking code.  Without the proper
part ref, not only a user may get confused: I was, too...

The testcase is compile-only, as it is only important to check the
strings used in the error messages.

Regtested on x86_64-pc-linux-gnu.  OK for mainline?

Thanks,
Harald


Hello,

the change proper looks good, and is an improvement.  But I'm a little
concerned by the production of references like in the test x1%vv%z which
could be confusing and is strictly speaking invalid fortran (multiple
non-scalar components).  Did you consider generating x1%vv(?,?)%zz or
x1%vv(...)%z or similar?


yes, that seems very reasonable, given that this is what NAG does.

We also have spurious %_data in some error messages that I'll try
to get rid off.


There is another nit about the test, which has dg-output and
dg-shouldfail despite being only a compile-time test.


I'll remove that.  With gcc-13 the runtime check would trigger
in the wrong line but the failure of the check is dealt with
by another testcase in gcc-14.


Otherwise looks good.

Mikael


I'll come up with a revised patch.  Thanks for the feedback so far!

Harald

Re: [PATCH] jit: Ensure ssize_t is defined.

[Eric Gallager]

On Sun, Jan 28, 2024 at 6:45 AM Iain Sandoe  wrote:
>
> Tested on i686, x86_64 Darwin, x86_64 Linux,
> OK for trunk?
>
> --- 8< ---
>
> On some targets it seems that ssize_t is not defined by any of the
> headers transitively included by .  This leads to a bootstrap
> fail when jit is enabled.
>
> The fix proposed here is to include sys/types.h when it is available
> since that is where Posix specifies that ssize_t is defined.
>
> gcc/jit/ChangeLog:
>
> * libgccjit.h: Conditionally include  where it is
> available to ensure declaration of ssize_t.
>
> Signed-off-by: Iain Sandoe 
> ---
>  gcc/jit/libgccjit.h | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/gcc/jit/libgccjit.h b/gcc/jit/libgccjit.h
> index 235cab053e0..db4f27a48bf 100644
> --- a/gcc/jit/libgccjit.h
> +++ b/gcc/jit/libgccjit.h
> @@ -21,6 +21,9 @@ along with GCC; see the file COPYING3.  If not see
>  #define LIBGCCJIT_H
>
>  #include 
> +#if __has_include()

Is __has_include() something that we can use unconditionally?

> +# include   /* For ssize_t.  */
> +#endif
>
>  #ifdef __cplusplus
>  extern "C" {
> --
> 2.39.2 (Apple Git-143)
>

Re: [PATCH] Fortran: use name of array component in runtime error message [PR30802]

[Steve Kargl]

On Sun, Jan 28, 2024 at 08:56:24PM +0100, Harald Anlauf wrote:
> 
> Am 28.01.24 um 12:39 schrieb Mikael Morin:
> > Le 24/01/2024 à 22:39, Harald Anlauf a écrit :
> > > Dear all,
> > > 
> > > this patch is actually only a followup fix to generate the proper name
> > > of an array reference in derived-type components for the runtime error
> > > message generated for the bounds-checking code.  Without the proper
> > > part ref, not only a user may get confused: I was, too...
> > > 
> > > The testcase is compile-only, as it is only important to check the
> > > strings used in the error messages.
> > > 
> > > Regtested on x86_64-pc-linux-gnu.  OK for mainline?
> > > 
> > 
> > the change proper looks good, and is an improvement.  But I'm a little
> > concerned by the production of references like in the test x1%vv%z which
> > could be confusing and is strictly speaking invalid fortran (multiple
> > non-scalar components).  Did you consider generating x1%vv(?,?)%zz or
> > x1%vv(...)%z or similar?
> 
> yes, that seems very reasonable, given that this is what NAG does.
> 
> We also have spurious %_data in some error messages that I'll try
> to get rid off.
> 

I haven't looked at the patch, but sometimes (if not always) things
like _data are marked with attr.artificial.  You might see if this
will help with suppressing spurious messages.



-- 
Steve

Re: [PATCH] jit: Ensure ssize_t is defined.

[Iain Sandoe]

> On 28 Jan 2024, at 21:25, Eric Gallager  wrote:
> 
> On Sun, Jan 28, 2024 at 6:45 AM Iain Sandoe  wrote:
>> 
>> Tested on i686, x86_64 Darwin, x86_64 Linux,
>> OK for trunk?
>> 
>> --- 8< ---
>> 
>> On some targets it seems that ssize_t is not defined by any of the
>> headers transitively included by .  This leads to a bootstrap
>> fail when jit is enabled.
>> 
>> The fix proposed here is to include sys/types.h when it is available
>> since that is where Posix specifies that ssize_t is defined.
>> 
>> gcc/jit/ChangeLog:
>> 
>>* libgccjit.h: Conditionally include  where it is
>>available to ensure declaration of ssize_t.
>> 
>> Signed-off-by: Iain Sandoe 
>> ---
>> gcc/jit/libgccjit.h | 3 +++
>> 1 file changed, 3 insertions(+)
>> 
>> diff --git a/gcc/jit/libgccjit.h b/gcc/jit/libgccjit.h
>> index 235cab053e0..db4f27a48bf 100644
>> --- a/gcc/jit/libgccjit.h
>> +++ b/gcc/jit/libgccjit.h
>> @@ -21,6 +21,9 @@ along with GCC; see the file COPYING3.  If not see
>> #define LIBGCCJIT_H
>> 
>> #include 
>> +#if __has_include()
> 
> Is __has_include() something that we can use unconditionally?

Hmm.. maybe we cannot, it seems it was introduced in gcc-4.9 and we only ask
for 4.8, IIRC.

I guess HAVE_SYS_TYPES_H might be an alternative (I’ll have to retest)

Iain

> 
>> +# include   /* For ssize_t.  */
>> +#endif
>> 
>> #ifdef __cplusplus
>> extern "C" {
>> --
>> 2.39.2 (Apple Git-143)

Re: [PATCH] testsuite: Fix vect_long_mult on Power [PR109705]

[Kewen.Lin]

on 2024/1/27 06:42, Andrew Pinski wrote:
> On Mon, Jan 15, 2024 at 6:43 PM Kewen.Lin  wrote:
>>
>> Hi,
>>
>> As pointed out by the discussion in PR109705, the current
>> vect_long_mult effective target check on Power is broken.
>> This patch is to fix it accordingly.
>>
>> With additional change by adding a guard vect_long_mult
>> in gcc.dg/vect/pr25413a.c , it's tested well on Power{8,9}
>> LE & BE (also on Power10 LE as before).
> 
> I see this is still broken for 32bit PowerPC where vect_long_mult
> should return true still since long there is 32bit and there is a
> 32bit vector multiply.
> Can someone test (and apply if approved) the attached patch to see if
> it fixes pr25413a.c for powerpc*-*-* for 32bit?

Thanks for fixing, it works perfectly as tested.

I just pushed it as r14-8485 (also updating with a tab and commit log).

BR,
Kewen

> 
> Thanks,
> Andrew Pinski
> 
>>
>> I'm going to push this soon.
>>
>> BR,
>> Kewen
>> -
>> PR testsuite/109705
>>
>> gcc/testsuite/ChangeLog:
>>
>> * lib/target-supports.exp (check_effective_target_vect_long_mult):
>> Fix powerpc*-*-* checks.
>> ---
>>  gcc/testsuite/lib/target-supports.exp | 6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/gcc/testsuite/lib/target-supports.exp 
>> b/gcc/testsuite/lib/target-supports.exp
>> index 81ae92a0266..fac32fb3d0e 100644
>> --- a/gcc/testsuite/lib/target-supports.exp
>> +++ b/gcc/testsuite/lib/target-supports.exp
>> @@ -9073,9 +9073,9 @@ proc check_effective_target_vect_int_mult { } {
>>
>>  proc check_effective_target_vect_long_mult { } {
>>  if { [istarget i?86-*-*] || [istarget x86_64-*-*]
>> -|| (([istarget powerpc*-*-*]
>> -  && ![istarget powerpc-*-linux*paired*])
>> -  && [check_effective_target_ilp32])
>> +|| ([istarget powerpc*-*-*]
>> + && [check_effective_target_powerpc_vsx_ok]
>> + && [check_effective_target_has_arch_pwr10])
>>  || [is-effective-target arm_neon]
>>  || ([istarget sparc*-*-*] && [check_effective_target_ilp32])
>>  || [istarget aarch64*-*-*]
>> --
>> 2.39.1

Re: [PATCH] RISC-V: Add require-effective-target to pr113429 testcase

[juzhe.zh...@rivai.ai]

ok




juzhe.zh...@rivai.ai
 
From: Patrick O'Neill
Date: 2024-01-27 10:50
To: gcc-patches
CC: juzhe.zhong; Patrick O'Neill
Subject: [PATCH] RISC-V: Add require-effective-target to pr113429 testcase
The pr113429 testcase fails with newlib spike runs. Adding
require-effective-target rv64 and riscv_v fixes the issue.
 
gcc/testsuite/ChangeLog:
 
* gcc.target/riscv/rvv/vsetvl/pr113429.c: Add
require-effective-target rv64 and riscv_v
 
Signed-off-by: Patrick O'Neill 
---
Tested using rv64gc newlib spike.
---
gcc/testsuite/gcc.target/riscv/rvv/vsetvl/pr113429.c | 2 ++
1 file changed, 2 insertions(+)
 
diff --git a/gcc/testsuite/gcc.target/riscv/rvv/vsetvl/pr113429.c 
b/gcc/testsuite/gcc.target/riscv/rvv/vsetvl/pr113429.c
index 05c3eeecb94..a7f5db616d8 100644
--- a/gcc/testsuite/gcc.target/riscv/rvv/vsetvl/pr113429.c
+++ b/gcc/testsuite/gcc.target/riscv/rvv/vsetvl/pr113429.c
@@ -1,5 +1,7 @@
/* { dg-do run } */
/* { dg-options "-march=rv64gcv_zvl256b -mabi=lp64d -O3" } */
+/* { dg-require-effective-target rv64 } */
+/* { dg-require-effective-target riscv_v } */
long a;
int b, c, d, e, f, g;
-- 
2.34.1
 
 

Re: [PATCH v4 0/4] When cmodel=extreme, add macro support and only support macros.

[chenglulu]

在 2024/1/27 下午10:03, chenglulu 写道:


在 2024/1/27 下午7:11, Xi Ruoyao 写道:

On Sat, 2024-01-27 at 18:02 +0800, Xi Ruoyao wrote:

On Sat, 2024-01-27 at 11:15 +0800, chenglulu wrote:

在 2024/1/26 下午6:57, Xi Ruoyao 写道:

On Fri, 2024-01-26 at 16:59 +0800, chenglulu wrote:

在 2024/1/26 下午4:49, Xi Ruoyao 写道:

On Fri, 2024-01-26 at 15:37 +0800, Lulu Cheng wrote:

v3 -> v4:
 1. Add macro support for TLS symbols
 2. Added support for loading __get_tls_addr symbol address 
using call36.

 3. Merge template got_load_tls_{ld/gd/le/ie}.
 4. Enable explicit reloc for extreme TLS GD/LD with 
-mexplicit-relocs=auto.
I've rebased and attached the patch to fix the bad split in 
-mexplicit-
relocs={always,auto} -mcmodel=extreme on top of this series.  
I've not

tested it seriously though (only tested the added and modified test
cases).


OK, I'll test the spec for correctness.
I suppose this still won't work yet because Binutils is not fully 
fixed.

GAS has been changed not to emit R_LARCH_RELAX for "la.tls.ie a0, t0,
foo", but ld is still not checking if an R_LARCH_RELAX is after
R_LARCH_TLS_IE_PC_{HI20,LO12} properly.  Thus an invalid "partial" 
TLS

transition can still happen.


The following situations are not handled in the patch:

diff --git a/gcc/config/loongarch/loongarch.cc
b/gcc/config/loongarch/loongarch.cc

index 3fab4b64453..6336a9f696f 100644
--- a/gcc/config/loongarch/loongarch.cc
+++ b/gcc/config/loongarch/loongarch.cc
@@ -7472,7 +7472,13 @@ loongarch_output_mi_thunk (FILE *file, tree
thunk_fndecl ATTRIBUTE_UNUSED,
   {
 if (TARGET_CMODEL_EXTREME)
  {
- emit_insn (gen_movdi_symbolic_off64 (temp1, fnaddr, temp2));
+ if (la_opt_explicit_relocs != EXPLICIT_RELOCS_NONE)
+   {
+ emit_insn (gen_la_pcrel64_two_parts (temp1, temp2, 
fnaddr));
+ emit_move_insn (temp1, gen_rtx_PLUS (Pmode, temp1, 
temp2));

+   }
+ else
+   emit_insn (gen_movdi_symbolic_off64 (temp1, fnaddr, 
temp2));

It looks like this part is unreachable: with -mcmodel=extreme
use_sibcall_p will never be true.

So cleaned up this part and fixed an ERROR in the added test:

diff --git a/gcc/config/loongarch/loongarch.cc 
b/gcc/config/loongarch/loongarch.cc

index 3a97ba61362..7b8c85a1606 100644
--- a/gcc/config/loongarch/loongarch.cc
+++ b/gcc/config/loongarch/loongarch.cc
@@ -7481,21 +7481,24 @@ loongarch_output_mi_thunk (FILE *file, tree 
thunk_fndecl ATTRIBUTE_UNUSED,

   allowed, otherwise load the address into a register first.  */
    if (use_sibcall_p)
  {
-  if (TARGET_CMODEL_EXTREME)
-    {
-  emit_insn (gen_movdi_symbolic_off64 (temp1, fnaddr, temp2));
-  insn = emit_call_insn (gen_sibcall_internal (temp1, const0_rtx));
-    }
-  else
-    insn = emit_call_insn (gen_sibcall_internal (fnaddr, const0_rtx));
+  /* If TARGET_CMODEL_EXTREME, we cannot do a direct jump at all
+ and const_call_insn_operand should have returned false. */
+  gcc_assert (!TARGET_CMODEL_EXTREME);
+
+  insn = emit_call_insn (gen_sibcall_internal (fnaddr, 
const0_rtx));

    SIBLING_CALL_P (insn) = 1;
  }
    else
  {
-  if (TARGET_CMODEL_EXTREME)
+  if (!TARGET_CMODEL_EXTREME)
+    loongarch_emit_move (temp1, fnaddr);
+  else if (la_opt_explicit_relocs == EXPLICIT_RELOCS_NONE)
  emit_insn (gen_movdi_symbolic_off64 (temp1, fnaddr, temp2));
    else
-    loongarch_emit_move (temp1, fnaddr);
+    {
+  emit_insn (gen_la_pcrel64_two_parts (temp1, temp2, fnaddr));
+  emit_move_insn (temp1, gen_rtx_PLUS (Pmode, temp1, temp2));
+    }
      emit_jump_insn (gen_indirect_jump (temp1));
  }
diff --git 
a/gcc/testsuite/gcc.target/loongarch/explicit-relocs-extreme-auto-tls-ld-gd.c 
b/gcc/testsuite/gcc.target/loongarch/explicit-relocs-extreme-auto-tls-ld-gd.c 


index 27baf4886d6..35bd4570a9e 100644
--- 
a/gcc/testsuite/gcc.target/loongarch/explicit-relocs-extreme-auto-tls-ld-gd.c
+++ 
b/gcc/testsuite/gcc.target/loongarch/explicit-relocs-extreme-auto-tls-ld-gd.c

@@ -1,5 +1,5 @@
  /* { dg-do compile } */
  /* { dg-options "-O2 -fPIC -mexplicit-relocs=auto -mcmodel=extreme 
-fno-plt" } */
-/* { dg-final { scan-assembler-not "la.tls.[lg]d" { target 
tls_native } } } */
+/* { dg-final { scan-assembler-not "la.tls.\[lg\]d" { target 
tls_native } } } */

    #include "./explicit-relocs-auto-tls-ld-gd.c"

And added 3 tests for output_mi_thunk.  The updated patch attached, now
running regression test.



@@ -2870,20 +2872,30 @@ loongarch_call_tls_get_addr (rtx sym, enum 
loongarch_symbol_type type, rtx v0)

    {
  if (loongarch_explicit_relocs_p (SYMBOL_GOT_DISP))
    {
- rtx tmp1 = gen_reg_rtx (Pmode);
- rtx high = gen_reg_rtx (Pmode);
+ gcc_assert (la_opt_explicit_relocs !=
+ EXPLICIT_RELOCS_NONE);

This operator is written at the end of the line, and I think there is 
no problem with anything else.


But I need t

Re: [PATCH] Fortran: use name of array component in runtime error message [PR30802]

[rep . dot . nop]

On 28 January 2024 22:43:37 CET, Steve Kargl 
 wrote:
>On Sun, Jan 28, 2024 at 08:56:24PM +0100, Harald Anlauf wrote:
>> 
>> Am 28.01.24 um 12:39 schrieb Mikael Morin:
>> > Le 24/01/2024 à 22:39, Harald Anlauf a écrit :
>> > > Dear all,
>> > > 
>> > > this patch is actually only a followup fix to generate the proper name
>> > > of an array reference in derived-type components for the runtime error
>> > > message generated for the bounds-checking code.  Without the proper
>> > > part ref, not only a user may get confused: I was, too...
>> > > 
>> > > The testcase is compile-only, as it is only important to check the
>> > > strings used in the error messages.
>> > > 
>> > > Regtested on x86_64-pc-linux-gnu.  OK for mainline?
>> > > 
>> > 
>> > the change proper looks good, and is an improvement.  But I'm a little
>> > concerned by the production of references like in the test x1%vv%z which
>> > could be confusing and is strictly speaking invalid fortran (multiple
>> > non-scalar components).  Did you consider generating x1%vv(?,?)%zz or
>> > x1%vv(...)%z or similar?
>> 
>> yes, that seems very reasonable, given that this is what NAG does.
>> 
>> We also have spurious %_data in some error messages that I'll try
>> to get rid off.
>> 
>
>I haven't looked at the patch, but sometimes (if not always) things
>like _data are marked with attr.artificial.  You might see if this
>will help with suppressing spurious messages.
>

Reminds me of
https://inbox.sourceware.org/fortran/2024231748.376086cd@nbbrfq/

Maybe thats missing, i did not apply that yet, did i?

HTH