aarch64: testsuite: symbol-range compile only

  On some of our embedded aarch64 targets, RAM size is too small for
this test to fit.  It doesn't look like this test requires linking,
and if it does, the -tiny version may presumably get most of the
coverage without going overboard in target system requirements.

Regstrapped on x86_64-linux-gnu, also tested with a cross to
aarch64-rtems6.  Ok to install?


for  gcc/testsuite/ChangeLog

	* gcc.target/aarch64/symbol-range.c: Compile only.
---
 gcc/testsuite/gcc.target/aarch64/symbol-range.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
  

Alexandre Oliva <oliva@adacore.com> writes:
> On some of our embedded aarch64 targets, RAM size is too small for
> this test to fit.  It doesn't look like this test requires linking,
> and if it does, the -tiny version may presumably get most of the
> coverage without going overboard in target system requirements.

Linking is valuable here because one of the likely failure modes
is an out-of-range relocation.

Could we instead have a new target selector for whether the memory
map includes xGB of RAM?  E.g. maybe it could be along similar lines
to check_effective_target_simulator, reading an optional board
property that gives the RAM size.

Thanks,
Richard

>
> Regstrapped on x86_64-linux-gnu, also tested with a cross to
> aarch64-rtems6.  Ok to install?
>
>
> for  gcc/testsuite/ChangeLog
>
> 	* gcc.target/aarch64/symbol-range.c: Compile only.
> ---
>  gcc/testsuite/gcc.target/aarch64/symbol-range.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/testsuite/gcc.target/aarch64/symbol-range.c b/gcc/testsuite/gcc.target/aarch64/symbol-range.c
> index d8e82fa1b2829..cc68c19ca85d9 100644
> --- a/gcc/testsuite/gcc.target/aarch64/symbol-range.c
> +++ b/gcc/testsuite/gcc.target/aarch64/symbol-range.c
> @@ -1,4 +1,4 @@
> -/* { dg-do link } */
> +/* { dg-do compile } */
>  /* { dg-options "-O3 -save-temps -mcmodel=small" } */
>  
>  char fixed_regs[0x80000000];
  

On Jun 21, 2022, Richard Sandiford <richard.sandiford@arm.com> wrote:

> Could we instead have a new target selector for whether the memory
> map includes xGB of RAM?

How about this?  Testing on aarch64-rtems6.0.  Ok to install?


aarch64: testsuite: symbol-range fallback to compile

From: Alexandre Oliva <oliva@adacore.com>

On some of our embedded aarch64 targets, RAM size is too small for
this test to fit.  It doesn't look like this test requires linking,
and if it does, the -tiny version may presumably get most of the
coverage without going overboard in target system requirements.

Still, linking may be useful, so introduce a TwoPlusGigs effective
target, that checks for the ability to link a program with 2GB of
sbss, and use that to select whether to link or just compile
symbol-range.c.


for  gcc/testsuite/ChangeLog

	* lib/target-supports.exp
	(check_effective_target_TwoPlusGigs): New.
	* gcc.target/aarch64/symbol-range.c: Link only on
	TwoPlusGigs targets, compile otherwise.
---
 gcc/testsuite/gcc.target/aarch64/symbol-range.c |    3 ++-
 gcc/testsuite/lib/target-supports.exp           |    9 +++++++++
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.target/aarch64/symbol-range.c b/gcc/testsuite/gcc.target/aarch64/symbol-range.c
index d8e82fa1b2829..f9a916c7ae2f0 100644
--- a/gcc/testsuite/gcc.target/aarch64/symbol-range.c
+++ b/gcc/testsuite/gcc.target/aarch64/symbol-range.c
@@ -1,4 +1,5 @@
-/* { dg-do link } */
+/* { dg-do link { target TwoPlusGigs } } */
+/* { dg-do compile { target { ! TwoPlusGigs } } } */
 /* { dg-options "-O3 -save-temps -mcmodel=small" } */
 
 char fixed_regs[0x80000000];
diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
index d1f4eb7641fa7..0507d6e617fef 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -2906,6 +2906,15 @@ proc check_effective_target_le { } {
     }]
 }
 
+# Return 1 if we can link a program with 2+GB of data.
+
+proc check_effective_target_TwoPlusGigs { } {
+    return [check_no_compiler_messages TwoPlusGigs executable {
+	int dummy[0x80000000];
+	int main () { return 0; }
+    }]
+}
+
 # Return 1 if we're generating 32-bit code using default options, 0
 # otherwise.
  

Alexandre Oliva <oliva@adacore.com> writes:
> On Jun 21, 2022, Richard Sandiford <richard.sandiford@arm.com> wrote:
>
>> Could we instead have a new target selector for whether the memory
>> map includes xGB of RAM?
>
> How about this?  Testing on aarch64-rtems6.0.  Ok to install?
>
>
> aarch64: testsuite: symbol-range fallback to compile
>
> From: Alexandre Oliva <oliva@adacore.com>
>
> On some of our embedded aarch64 targets, RAM size is too small for
> this test to fit.  It doesn't look like this test requires linking,
> and if it does, the -tiny version may presumably get most of the
> coverage without going overboard in target system requirements.
>
> Still, linking may be useful, so introduce a TwoPlusGigs effective
> target, that checks for the ability to link a program with 2GB of
> sbss, and use that to select whether to link or just compile
> symbol-range.c.
>
>
> for  gcc/testsuite/ChangeLog
>
> 	* lib/target-supports.exp
> 	(check_effective_target_TwoPlusGigs): New.
> 	* gcc.target/aarch64/symbol-range.c: Link only on
> 	TwoPlusGigs targets, compile otherwise.

Other selectors don't use CamelCase, so I guess it should be
two_plus_gigs instead.  There also needs to be an entry in
sourcebuild.texi.  (Personally I'm not sure how useful those
entries are, since grepping for comments in the source is
usually easier, but still.)

OK with those changes, thanks.

Richard

> ---
>  gcc/testsuite/gcc.target/aarch64/symbol-range.c |    3 ++-
>  gcc/testsuite/lib/target-supports.exp           |    9 +++++++++
>  2 files changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/gcc/testsuite/gcc.target/aarch64/symbol-range.c b/gcc/testsuite/gcc.target/aarch64/symbol-range.c
> index d8e82fa1b2829..f9a916c7ae2f0 100644
> --- a/gcc/testsuite/gcc.target/aarch64/symbol-range.c
> +++ b/gcc/testsuite/gcc.target/aarch64/symbol-range.c
> @@ -1,4 +1,5 @@
> -/* { dg-do link } */
> +/* { dg-do link { target TwoPlusGigs } } */
> +/* { dg-do compile { target { ! TwoPlusGigs } } } */
>  /* { dg-options "-O3 -save-temps -mcmodel=small" } */
>  
>  char fixed_regs[0x80000000];
> diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
> index d1f4eb7641fa7..0507d6e617fef 100644
> --- a/gcc/testsuite/lib/target-supports.exp
> +++ b/gcc/testsuite/lib/target-supports.exp
> @@ -2906,6 +2906,15 @@ proc check_effective_target_le { } {
>      }]
>  }
>  
> +# Return 1 if we can link a program with 2+GB of data.
> +
> +proc check_effective_target_TwoPlusGigs { } {
> +    return [check_no_compiler_messages TwoPlusGigs executable {
> +	int dummy[0x80000000];
> +	int main () { return 0; }
> +    }]
> +}
> +
>  # Return 1 if we're generating 32-bit code using default options, 0
>  # otherwise.
  

On Jun 22, 2022, Richard Sandiford <richard.sandiford@arm.com> wrote:

> Other selectors don't use CamelCase, so I guess it should be
> two_plus_gigs instead.  There also needs to be an entry in
> sourcebuild.texi.

Thanks for the reminder, I keep forgetting about this.

> OK with those changes, thanks.

Here's what I'm going to install.


aarch64: testsuite: symbol-range fallback to compile

On some of our embedded aarch64 targets, RAM size is too small for
this test to fit.  It doesn't look like this test requires linking,
and if it does, the -tiny version may presumably get most of the
coverage without going overboard in target system requirements.

Still, linking may be useful, so introduce a two_plus_gigs effective
target, that checks for the ability to link a program with 2GiB of
sbss, and use that to select whether to link or just compile
symbol-range.c.


for  gcc/testsuite/ChangeLog

	* lib/target-supports.exp
	(check_effective_target_two_plus_gigs): New.
	* doc/sourcebuild.exp (Environment attributes): Document it.
	* gcc.target/aarch64/symbol-range.c: Link only on
	two_plus_gigs targets, compile otherwise.
---
 gcc/doc/sourcebuild.texi                        |    3 +++
 gcc/testsuite/gcc.target/aarch64/symbol-range.c |    3 ++-
 gcc/testsuite/lib/target-supports.exp           |    9 +++++++++
 3 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
index 606ab85a11668..3696a58fbf2bc 100644
--- a/gcc/doc/sourcebuild.texi
+++ b/gcc/doc/sourcebuild.texi
@@ -2681,6 +2681,9 @@ Target supports @code{sysconf}.
 @item trampolines
 Target supports trampolines.
 
+@item two_plus_gigs
+Target supports linking programs with 2+GiB of data.
+
 @item uclibc
 Target supports uClibc.
 
diff --git a/gcc/testsuite/gcc.target/aarch64/symbol-range.c b/gcc/testsuite/gcc.target/aarch64/symbol-range.c
index d8e82fa1b2829..6b15f0872024c 100644
--- a/gcc/testsuite/gcc.target/aarch64/symbol-range.c
+++ b/gcc/testsuite/gcc.target/aarch64/symbol-range.c
@@ -1,4 +1,5 @@
-/* { dg-do link } */
+/* { dg-do link { target two_plus_gigs } } */
+/* { dg-do compile { target { ! two_plus_gigs } } } */
 /* { dg-options "-O3 -save-temps -mcmodel=small" } */
 
 char fixed_regs[0x80000000];
diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
index d1f4eb7641fa7..20171f9d98584 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -2906,6 +2906,15 @@ proc check_effective_target_le { } {
     }]
 }
 
+# Return 1 if we can link a program with 2+GB of data.
+
+proc check_effective_target_two_plus_gigs { } {
+    return [check_no_compiler_messages two_plus_gigs executable {
+	int dummy[0x80000000];
+	int main () { return 0; }
+    }]
+}
+
 # Return 1 if we're generating 32-bit code using default options, 0
 # otherwise.
  

On Jun 23, 2022, Alexandre Oliva <oliva@adacore.com> wrote:

> for  gcc/testsuite/ChangeLog

> 	* doc/sourcebuild.exp (Environment attributes): Document it.

Fixed two problems in the above, thanks for the ChangeLog checker.  It's
.texi, and it belongs in gcc/ChangeLog.
  

On Thu, 23 Jun 2022, Alexandre Oliva via Gcc-patches wrote:
> +proc check_effective_target_two_plus_gigs { } {
> +    return [check_no_compiler_messages two_plus_gigs executable {
> +	int dummy[0x80000000];

Don't you mean "char" as in "char dummy[0x80000000]"?

Or else the effective predicate is effectively eight_plus_gigs
(for targets where sizeof(int) == 4, i.e. most).

brgds, H-P
  

On Jun 30, 2022, Hans-Peter Nilsson <hp@bitrange.com> wrote:

> On Thu, 23 Jun 2022, Alexandre Oliva via Gcc-patches wrote:
>> +proc check_effective_target_two_plus_gigs { } {
>> +    return [check_no_compiler_messages two_plus_gigs executable {
>> +	int dummy[0x80000000];

> Don't you mean "char" as in "char dummy[0x80000000]"?

Doh.  Of course!  Thanks for catching this.

Here's what I'm installing, regstrapped on x86_64-linux-gnu, also tested
on aarch64-rtems6.0 and ppc64-vx7r2.


testsuite: fix array type in two_plus_gigs test

The array element type for the two_plus_gigs test was mistakely put in
as int rather than char.


for  gcc/testsuite/ChangeLog

	* target-supports.exp (check_effective_target_two_plus_gigs):
	Fix array element type.  Reported by Hans-Peter Nilsson.

---
 gcc/testsuite/lib/target-supports.exp |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
index 48c5dda6a1278..4ed7b25b9a4de 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -2909,7 +2909,7 @@ proc check_effective_target_le { } {
 
 proc check_effective_target_two_plus_gigs { } {
     return [check_no_compiler_messages two_plus_gigs executable {
-	int dummy[0x80000000];
+	char dummy[0x80000000];
 	int main () { return 0; }
     }]
 }