[Bug target/96566] New: [nvptx] Timeout in gcc.dg/builtin-object-size-21.c

[Bug target/96566] New: [nvptx] Timeout in gcc.dg/builtin-object-size-21.c

[vries at gcc dot gnu.org]

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

            Bug ID: 96566
           Summary: [nvptx] Timeout in gcc.dg/builtin-object-size-21.c
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

When running test-case gcc.dg/builtin-object-size-21.c, we have:
...
spawn -ignore SIGHUP /home/vries/nvptx/mainkernel-2/build-gcc/gcc/xgcc
-B/home/vries/nvptx/mainkernel-2/build-gcc/gcc/
/home/vries/nvptx/mainkernel-2/source-gcc/gcc/testsuite/gcc.dg/builtin-object-size-21.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-urls=never
--sysroot=/home/vries/nvptx/mainkernel-2/install/nvptx-none -Wall
-fdump-tree-optimized -S -isystem
/home/vries/nvptx/mainkernel-2/build-gcc/nvptx-none/./newlib/targ-include
-isystem /home/vries/nvptx/mainkernel-2/source-gcc/newlib/libc/include -o
builtin-object-size-21.s^M
/home/vries/nvptx/mainkernel-2/source-gcc/gcc/testsuite/gcc.dg/builtin-object-size-21.c:43:14:
error: size of variable 'xmx_1' is too large^M
/home/vries/nvptx/mainkernel-2/source-gcc/gcc/testsuite/gcc.dg/builtin-object-size-21.c:29:14:
error: size of variable 'xm3_4' is too large^M
WARNING: program timed out
compiler exited with status 1
PASS: gcc.dg/builtin-object-size-21.c  (test for errors, line 29)
PASS: gcc.dg/builtin-object-size-21.c  (test for errors, line 43)
PASS: gcc.dg/builtin-object-size-21.c (test for excess errors)
...

If we run the command by hand, and tail the .s file, we get an endless
repetition of 0, 0, 0, ... , which starts off like this:
...
// BEGIN GLOBAL VAR DEF: xm3_3
        .visible .global .align 1 .u32 xm3_3[-2305843009213693951]
          = { 0, 0, 0,
...

The negative length doesn't look good.

[Bug target/96566] [nvptx] Timeout in gcc.dg/builtin-object-size-21.c

[vries at gcc dot gnu.org]

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

--- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> ---
Corresponding source bit:
...
struct Ax_m3 { char a[PTRDIFF_MAX - 3], ax[]; };

struct Ax_m3 xm3_3 = { { 0 }, { 1, 2, 3 } };
....

On x86_64, we generate for this:
...
xm3_3:
        .byte   0
        .zero   9223372036854775803
        .byte   1
        .byte   2
        .byte   3
...
where 9223372036854775803 is 0x7FFFFFFFFFFFFFFB.

[Bug target/96566] [nvptx] Timeout in gcc.dg/builtin-object-size-21.c

[vries at gcc dot gnu.org]

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

--- Comment #2 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #0)
> If we run the command by hand, and tail the .s file, we get an endless
> repetition of 0, 0, 0, ... , which starts off like this:
> ...
> // BEGIN GLOBAL VAR DEF: xm3_3
>         .visible .global .align 1 .u32 xm3_3[-2305843009213693951]
>           = { 0, 0, 0,
> ...
> 
> The negative length doesn't look good.

Using:
...
diff --git a/gcc/config/nvptx/nvptx.c b/gcc/config/nvptx/nvptx.c
index cf53a921e5b..752c12561dd 100644
--- a/gcc/config/nvptx/nvptx.c
+++ b/gcc/config/nvptx/nvptx.c
@@ -2232,7 +2232,7 @@ nvptx_assemble_decl_begin (FILE *file, const char *name,
const char *section,
   if (size)
     /* We make everything an array, to simplify any initialization
        emission.  */
-    fprintf (file, "[" HOST_WIDE_INT_PRINT_DEC "]", init_frag.remaining);
+    fprintf (file, "[" HOST_WIDE_INT_PRINT_UNSIGNED "]", init_frag.remaining);
   else if (atype)
     fprintf (file, "[]");
 }
...

we have instead:
...
        .visible .global .align 1 .u32 xm3_3[16140901064495857665]
...
which in hex is 0xE000000000000001, so it still looks wrong.

[Bug target/96566] [nvptx] Timeout in gcc.dg/builtin-object-size-21.c

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Either the test can be skipped on nvptx or any targets that don't emit
something like a .zero similar directive, or we should after the size of
variable is too large diagnostic throw the initializer away (set it to
error_mark_node)?
Of course, I guess the timeout will happen even if the object size is not too
large for the warning, just slightly below it,
struct Ax_m3 { char a[PTRDIFF_MAX / 32 - 3], ax[]; };
struct Ax_m3 xm3_3 = { { 0 }, { 1, 2, 3 } };
will IMHO still timeout if it needs to emit 288 quadrillion "0, " strings.

[Bug target/96566] [nvptx] Timeout in gcc.dg/builtin-object-size-21.c

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Note, on x86_64-linux we'd likely time out on the adjusted testcase during
assembly (unless it would will up the disks before that).

[Bug target/96566] [nvptx] Timeout in gcc.dg/builtin-object-size-21.c

[vries at gcc dot gnu.org]

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

--- Comment #5 from Tom de Vries <vries at gcc dot gnu.org> ---
Then with this in addition:
...
@@ -2202,7 +2202,7 @@ nvptx_assemble_decl_begin (FILE *file, const char *name,
const char *section,
     /* Neither vector nor complex types can contain the other.  */
     type = TREE_TYPE (type);

-  unsigned elt_size = int_size_in_bytes (type);
+  unsigned HOST_WIDE_INT elt_size = int_size_in_bytes (type);

   /* Largest mode we're prepared to accept.  For BLKmode types we
      don't know if it'll contain pointer constants, so have to choose
...
we have:
...
// BEGIN GLOBAL VAR DEF: xm3_3
        .visible .global .align 1 .u32 xm3_3[2305843009213693952] = { 0, 0, 0,
...
where 2305843009213693952 is 0x2000000000000000, so this claims one byte more
than required (due to using .u32).  This may cause an overflow in ptx, not sure
yet.

[Bug target/96566] [nvptx] Timeout in gcc.dg/builtin-object-size-21.c

[vries at gcc dot gnu.org]

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

--- Comment #6 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #3)
> Either the test can be skipped on nvptx or any targets that don't emit
> something like a .zero similar directive, or we should after the size of
> variable is too large diagnostic throw the initializer away (set it to
> error_mark_node)?
> Of course, I guess the timeout will happen even if the object size is not
> too large for the warning, just slightly below it,
> struct Ax_m3 { char a[PTRDIFF_MAX / 32 - 3], ax[]; };
> struct Ax_m3 xm3_3 = { { 0 }, { 1, 2, 3 } };
> will IMHO still timeout if it needs to emit 288 quadrillion "0, " strings.

Agreed, I browsed the ptx spec at bit, and was hoping for a better way to
express this, but it seems there isn't, even in the latest ptx version (7.0).

As for the ptx back-end, we could add an -minit-limit, with a reasonable
default.

With a size of 0xfffffff we take 5s and generate a 193MB assembly file.

With a size of 0xffffffff we take 1m10s and generate a 3.1GB assembly file.

So perhaps the first could be a good default. 

Then when running into the limit we error out, instead of timing out or running
out of disk space.

[Bug target/96566] [nvptx] Timeout in gcc.dg/builtin-object-size-21.c

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I'm not sure a target specific option is the way to go here, the only
difference is that nvptx spends all the time on this (adjusted) testcase at
compile time (and eats all disk space there too), while on x86_64 it is at
assembly time.
gcc -O2 -c -o /tmp/1.o /tmp/1.c
/tmp/ccUN9rYB.s: Assembler messages:
/tmp/ccUN9rYB.s: Fatal error: can't fill 256 bytes in section .data of
/tmp/1.o: 'No space left on device'
In real-world people will only compile code that is useful for something, and
we should honor there the no hardcoded limits unless really necessary rule,
some users may need 20GB initializers some day (sure, on most PTX decides it
wouldn't likely fit, but that can be diagnosed later).
For the error recovery, it is ok to throw away the initializers if it doesn't
result in further diagnostics, but otherwise, let's let users do what they want
if they have time and disk space for that.

[Bug target/96566] [nvptx] Timeout in gcc.dg/builtin-object-size-21.c

[vries at gcc dot gnu.org]

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

--- Comment #8 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #6)
> With a size of 0xfffffff we take 5s and generate a 193MB assembly file.
> 
> With a size of 0xffffffff we take 1m10s and generate a 3.1GB assembly file.


FTR, I tried the same code with latest (11.0 update 1) cuda, and got these
results:

With a size of 0xfffffff we take 19.4s and generate a 769MB assembly file (it's
bigger because it uses u8 instead of u32 as basetype).

With a size of 0xffffffff we run into "Floating point exception (core dumped)"
after 8 minutes.

[Bug target/96566] [nvptx] Timeout in gcc.dg/builtin-object-size-21.c

[vries at gcc dot gnu.org]

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

--- Comment #9 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #7)
> I'm not sure a target specific option is the way to go here, the only
> difference is that nvptx spends all the time on this (adjusted) testcase at
> compile time (and eats all disk space there too), while on x86_64 it is at
> assembly time.
> gcc -O2 -c -o /tmp/1.o /tmp/1.c
> /tmp/ccUN9rYB.s: Assembler messages:
> /tmp/ccUN9rYB.s: Fatal error: can't fill 256 bytes in section .data of
> /tmp/1.o: 'No space left on device'
> In real-world people will only compile code that is useful for something,
> and we should honor there the no hardcoded limits unless really necessary
> rule, some users may need 20GB initializers some day (sure, on most PTX
> decides it wouldn't likely fit, but that can be diagnosed later).
> For the error recovery, it is ok to throw away the initializers if it
> doesn't result in further diagnostics, but otherwise, let's let users do
> what they want
> if they have time and disk space for that.

I guess we can set the limit to the max by default, and then run the testsuite
with the limit set to something more reasonable.

[Bug target/96566] [nvptx] Timeout in gcc.dg/builtin-object-size-21.c

[msebor at gcc dot gnu.org]

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

--- Comment #10 from Martin Sebor <msebor at gcc dot gnu.org> ---
The issue described in bug 92815 comment 9 sounds like a similar problem.  Does
sending the output to /dev/null instead of a .s file help?  If it does, adding
a dg directive to do that might be a solution.

Separately, I've been meaning to add a parameter to reduce the maximum size of
an object object from the current PTRDIFF_MAX to something more realistic for
their target.  With it, tests for boundary conditions could use the smaller
constant sey by the parameter.

[Bug target/96566] [nvptx] Timeout in gcc.dg/builtin-object-size-21.c

[vries at gcc dot gnu.org]

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

--- Comment #11 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Martin Sebor from comment #10)
> The issue described in bug 92815 comment 9 sounds like a similar problem. 
> Does sending the output to /dev/null instead of a .s file help?  If it does,
> adding a dg directive to do that might be a solution.

It would certainly help for the disk-space issue.

[Bug target/96566] [nvptx] Timeout in gcc.dg/builtin-object-size-21.c

[vries at gcc dot gnu.org]

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

--- Comment #12 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #6)
> (In reply to Jakub Jelinek from comment #3)
> > Either the test can be skipped on nvptx or any targets that don't emit
> > something like a .zero similar directive, 

How about this:
...
diff --git a/gcc/testsuite/gcc.dg/builtin-object-size-21.c
b/gcc/testsuite/gcc.dg/builtin-object-size-21.c
index 1c42374ba89..7e0f85ffdf3 100644
--- a/gcc/testsuite/gcc.dg/builtin-object-size-21.c
+++ b/gcc/testsuite/gcc.dg/builtin-object-size-21.c
@@ -1,7 +1,8 @@
 /* PR middle-end/92815 - spurious -Wstringop-overflow writing into
    a flexible array of an extern struct
    { dg-do compile }
-   { dg-options "-Wall -fdump-tree-optimized" } */
+   { dg-options "-Wall -fdump-tree-optimized" }
+   { dg-require-effective-target large_initializer } */

 #define PTRDIFF_MAX __PTRDIFF_MAX__

diff --git a/gcc/testsuite/gcc.dg/strlenopt-55.c
b/gcc/testsuite/gcc.dg/strlenopt-55.c
index ea6fb22a2ed..ca89ecd3c53 100644
--- a/gcc/testsuite/gcc.dg/strlenopt-55.c
+++ b/gcc/testsuite/gcc.dg/strlenopt-55.c
@@ -3,7 +3,8 @@

    Verify that strlen() of braced initialized array is folded
    { dg-do compile }
-   { dg-options "-O1 -Wall -fdump-tree-gimple -fdump-tree-optimized" } */
+   { dg-options "-O1 -Wall -fdump-tree-gimple -fdump-tree-optimized" }
+   { dg-require-effective-target large_initializer } */

 #include "strlenopt.h"

diff --git a/gcc/testsuite/lib/target-supports.exp
b/gcc/testsuite/lib/target-supports.exp
index e79015b4d54..4e0d45aaae5 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -10424,3 +10424,14 @@ proc check_effective_target_msp430_large {} {
        #endif
     } ""]
 }
+
+# Return 1 if the target has an efficient means to encode large initializers
+# in the assembly.
+
+proc check_effective_target_large_initializer { } {
+    if { [istarget nvptx*-*-*] } {
+       return 0
+    }
+
+    return 1
+}
...

[Bug target/96566] [nvptx] Timeout in gcc.dg/builtin-object-size-21.c

[vries at gcc dot gnu.org]

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

--- Comment #13 from Tom de Vries <vries at gcc dot gnu.org> ---
Printing correct array dimension fixed in
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=b9c7fe59f9f66ecc091e215c826ecd1a04d032dc
.

[Bug target/96566] [nvptx] Timeout in gcc.dg/builtin-object-size-21.c

[vries at gcc dot gnu.org]

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

--- Comment #14 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #12)
> (In reply to Tom de Vries from comment #6)
> > (In reply to Jakub Jelinek from comment #3)
> > > Either the test can be skipped on nvptx or any targets that don't emit
> > > something like a .zero similar directive, 
> 
> How about this:
> ...
> diff --git a/gcc/testsuite/gcc.dg/builtin-object-size-21.c
> b/gcc/testsuite/gcc.dg/builtin-object-size-21.c
> index 1c42374ba89..7e0f85ffdf3 100644
> --- a/gcc/testsuite/gcc.dg/builtin-object-size-21.c
> +++ b/gcc/testsuite/gcc.dg/builtin-object-size-21.c
> @@ -1,7 +1,8 @@
>  /* PR middle-end/92815 - spurious -Wstringop-overflow writing into
>     a flexible array of an extern struct
>     { dg-do compile }
> -   { dg-options "-Wall -fdump-tree-optimized" } */
> +   { dg-options "-Wall -fdump-tree-optimized" }
> +   { dg-require-effective-target large_initializer } */
>  
>  #define PTRDIFF_MAX __PTRDIFF_MAX__
>  
> diff --git a/gcc/testsuite/gcc.dg/strlenopt-55.c
> b/gcc/testsuite/gcc.dg/strlenopt-55.c
> index ea6fb22a2ed..ca89ecd3c53 100644
> --- a/gcc/testsuite/gcc.dg/strlenopt-55.c
> +++ b/gcc/testsuite/gcc.dg/strlenopt-55.c
> @@ -3,7 +3,8 @@
>  
>     Verify that strlen() of braced initialized array is folded
>     { dg-do compile }
> -   { dg-options "-O1 -Wall -fdump-tree-gimple -fdump-tree-optimized" } */
> +   { dg-options "-O1 -Wall -fdump-tree-gimple -fdump-tree-optimized" }
> +   { dg-require-effective-target large_initializer } */
>  
>  #include "strlenopt.h"
>  
> diff --git a/gcc/testsuite/lib/target-supports.exp
> b/gcc/testsuite/lib/target-supports.exp
> index e79015b4d54..4e0d45aaae5 100644
> --- a/gcc/testsuite/lib/target-supports.exp
> +++ b/gcc/testsuite/lib/target-supports.exp
> @@ -10424,3 +10424,14 @@ proc check_effective_target_msp430_large {} {
>         #endif
>      } ""]
>  }
> +
> +# Return 1 if the target has an efficient means to encode large initializers
> +# in the assembly.
> +
> +proc check_effective_target_large_initializer { } {
> +    if { [istarget nvptx*-*-*] } {
> +       return 0
> +    }
> +
> +    return 1
> +}
> ...

submitted at https://gcc.gnu.org/pipermail/gcc-patches/2020-August/551837.html
.

[Bug target/96566] [nvptx] Timeout in gcc.dg/builtin-object-size-21.c

[cvs-commit at gcc dot gnu.org]

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

--- Comment #15 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tom de Vries <vries@gcc.gnu.org>:

https://gcc.gnu.org/g:fb9b3c0ff7d347934b364e3ab06d4cf56726df33

commit r11-2669-gfb9b3c0ff7d347934b364e3ab06d4cf56726df33
Author: Tom de Vries <tdevries@suse.de>
Date:   Tue Aug 11 18:20:17 2020 +0200

    [testsuite] Add effective target large_initializer

    When compiling builtin-object-size-21.c for nvptx, cc1 times out while
    emitting the initializer for global variable xm3_3.

    With x86_64, we are able to emit the initializer with a few lines of
assembly:
    ...
    xm3_3:
            .byte   0
            .zero   9223372036854775803
            .byte   1
            .byte   2
            .byte   3
    ...
    but with nvptx, we don't have some something similar available, and thus
    generate:
    ...
      .visible .global .align 1 .u32 xm3_3[2305843009213693952] =
      { 0, 0, 0, ...
    ...

    Introduce an effective target large_initializer, returning false for nvptx,
    and require it for test-cases with large initializers.

    Tested on nvptx with make check-gcc.

    gcc/testsuite/ChangeLog:

            PR testsuite/96566
            * lib/target-supports.exp
(check_effective_target_large_initializer):
            New proc.
            * gcc.dg/builtin-object-size-21.c: Require large_initializer.
            * gcc.dg/strlenopt-55.c: Same.

[Bug target/96566] [nvptx] Timeout in gcc.dg/builtin-object-size-21.c

[vries at gcc dot gnu.org]

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

--- Comment #16 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #9)
> (In reply to Jakub Jelinek from comment #7)
> > I'm not sure a target specific option is the way to go here, the only
> > difference is that nvptx spends all the time on this (adjusted) testcase at
> > compile time (and eats all disk space there too), while on x86_64 it is at
> > assembly time.
> > gcc -O2 -c -o /tmp/1.o /tmp/1.c
> > /tmp/ccUN9rYB.s: Assembler messages:
> > /tmp/ccUN9rYB.s: Fatal error: can't fill 256 bytes in section .data of
> > /tmp/1.o: 'No space left on device'
> > In real-world people will only compile code that is useful for something,
> > and we should honor there the no hardcoded limits unless really necessary
> > rule, some users may need 20GB initializers some day (sure, on most PTX
> > decides it wouldn't likely fit, but that can be diagnosed later).
> > For the error recovery, it is ok to throw away the initializers if it
> > doesn't result in further diagnostics, but otherwise, let's let users do
> > what they want
> > if they have time and disk space for that.
> 
> I guess we can set the limit to the max by default, and then run the
> testsuite with the limit set to something more reasonable.

Filed this idea as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96588 .

[Bug target/96566] [nvptx] Timeout in gcc.dg/builtin-object-size-21.c

[vries at gcc dot gnu.org]

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

--- Comment #17 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Martin Sebor from comment #10)
> The issue described in bug 92815 comment 9 sounds like a similar problem. 
> Does sending the output to /dev/null instead of a .s file help?  If it does,
> adding a dg directive to do that might be a solution.
> 

Filed as PR96589.

[Bug target/96566] [nvptx] Timeout in gcc.dg/builtin-object-size-21.c

[vries at gcc dot gnu.org]

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

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #18 from Tom de Vries <vries at gcc dot gnu.org> ---
Patch skipping the test-case for nvptx committed, marking resolved-fixed.