[Bug target/109982] New: csmith: x86_64: znver1 issues

[Bug target/109982] New: csmith: x86_64: znver1 issues

[dcb314 at hotmail dot com]

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

            Bug ID: 109982
           Summary: csmith: x86_64: znver1 issues
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 55164
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55164&action=edit
C source code

The attached C source code does this:

$ ../results/bin/gcc -w bug923.c
runData/keep/in.11.c: In function ‘func_68’:
runData/keep/in.11.c:835:15: note: the ABI for passing parameters with 128-byte
alignment has changed in GCC 4.6
$ ./a.out 
checksum = 4ED89677
$ ../results/bin/gcc -w -march=znver1 bug923.c
runData/keep/in.11.c: In function ‘func_68’:
runData/keep/in.11.c:835:15: note: the ABI for passing parameters with 128-byte
alignment has changed in GCC 4.6
$ ./a.out 
Segmentation fault (core dumped)
$ 

The bug first seems to appear sometime between snapshot 20221218 (git hash
fd69977febf399d1992bbf8d66ae9170e0a4dc9f) and 20221225 (git hash
febb58d28bfa4b544ec7ffec2d61f46d25205ff0).

[Bug target/109982] csmith: x86_64: znver1 issues

[ubizjak at gmail dot com]

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

--- Comment #1 from Uroš Bizjak <ubizjak at gmail dot com> ---
Also fails with "-mtune=znver1 -mavx":

Program received signal SIGSEGV, Segmentation fault.
0x00000000004048ef in func_21 (p_22=0x41b330 <g_277>, p_23=0, p_24=8) at
runData/keep/in.11.c:597
597     in runData/keep/in.11.c
(gdb) disass $pc-10, $pc+10
Dump of assembler code from 0x4048e5 to 0x4048f9:
   0x00000000004048e5 <func_21+8160>:   mov    (%rax),%rdx
   0x00000000004048e8 <func_21+8163>:   mov    -0x1378(%rbp),%rax
=> 0x00000000004048ef <func_21+8170>:   vmovdqa (%rdx),%ymm0
   0x00000000004048f3 <func_21+8174>:   vmovdqa %ymm0,(%rax)
   0x00000000004048f7 <func_21+8178>:   vmovdqa 0x20(%rdx),%ymm0
End of assembler dump.
(gdb) p/x $rdx
$3 = 0x41a824

Unaligned access.

[Bug target/109982] csmith: x86_64: znver1 issues

[ubizjak at gmail dot com]

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

--- Comment #2 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Uroš Bizjak from comment #1)
> (gdb) p/x $rdx
> $3 = 0x41a824
> 
> Unaligned access.

Actually, just a garbage value.

[Bug target/109982] csmith: x86_64: znver1 issues

[ubizjak at gmail dot com]

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

--- Comment #3 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Uroš Bizjak from comment #1)
> Also fails with "-mtune=znver1 -mavx":
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x00000000004048ef in func_21 (p_22=0x41b330 <g_277>, p_23=0, p_24=8) at
> runData/keep/in.11.c:597
> 597     in runData/keep/in.11.c
> (gdb) disass $pc-10, $pc+10
> Dump of assembler code from 0x4048e5 to 0x4048f9:
>    0x00000000004048e5 <func_21+8160>:   mov    (%rax),%rdx
>    0x00000000004048e8 <func_21+8163>:   mov    -0x1378(%rbp),%rax
> => 0x00000000004048ef <func_21+8170>:   vmovdqa (%rdx),%ymm0
>    0x00000000004048f3 <func_21+8174>:   vmovdqa %ymm0,(%rax)
>    0x00000000004048f7 <func_21+8178>:   vmovdqa 0x20(%rdx),%ymm0
> End of assembler dump.
> (gdb) p/x $rdx
> $3 = 0x41a824
> 
> Unaligned access.

After some more analysis, the above *IS* unaligned access. At the end of
func_21, we have:

=> 0x00000000004048ef <+8170>:  vmovdqa (%rdx),%ymm0
   0x00000000004048f3 <+8174>:  vmovdqa %ymm0,(%rax)
   0x00000000004048f7 <+8178>:  vmovdqa 0x20(%rdx),%ymm0
   0x00000000004048fc <+8183>:  vmovdqa %ymm0,0x20(%rax)
   0x0000000000404901 <+8188>:  vmovdqa 0x40(%rdx),%ymm0
   0x0000000000404906 <+8193>:  vmovdqa %ymm0,0x40(%rax)
   0x000000000040490b <+8198>:  vmovdqa 0x60(%rdx),%ymm0
   0x0000000000404910 <+8203>:  vmovdqa %ymm0,0x60(%rax)

which looks like a memory copy to me. Unfortunately, the address is unaligned:

(gdb) p/x $rdx
$2 = 0x41a824

Changing the above vmovdqa insns to vmovdqu results in a successful run.

[Bug target/109982] csmith: x86_64: znver1 issues

[dcb314 at hotmail dot com]

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

--- Comment #4 from David Binderman <dcb314 at hotmail dot com> ---
Original git range was 123 commits.

Current bisect range is g:89ba8366fe12fd2d .. g:23be9d78f4bcd773,
which is 31 commits.

Trying 5b30e9bc211fede0.

[Bug target/109982] csmith: x86_64: znver1 issues

[dcb314 at hotmail dot com]

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

--- Comment #5 from David Binderman <dcb314 at hotmail dot com> ---
Current git range is g:193fccaa5c3525e9 .. g:5b30e9bc211fede0,
which is 8 commits.

[Bug target/109982] csmith: x86_64: znver1 issues

[dcb314 at hotmail dot com]

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

--- Comment #6 from David Binderman <dcb314 at hotmail dot com> ---
This commit looks highly likely:

commit eef81eefcdc2a58111e50eb2162ea1f5becc8004
Author: Jan Hubicka <jh@suse.cz>
Date:   Thu Dec 22 10:55:46 2022 +0100

    Zen4 tuning part 2

[Bug target/109982] csmith: x86_64: znver1 issues

[dcb314 at hotmail dot com]

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

David Binderman <dcb314 at hotmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jh at suse dot cz

--- Comment #7 from David Binderman <dcb314 at hotmail dot com> ---
As expected:

$ git bisect bad eef81eefcdc2a581
eef81eefcdc2a58111e50eb2162ea1f5becc8004 is the first bad commit
commit eef81eefcdc2a58111e50eb2162ea1f5becc8004
Author: Jan Hubicka <jh@suse.cz>
Date:   Thu Dec 22 10:55:46 2022 +0100

    Zen4 tuning part 2

[Bug target/109982] csmith: x86_64: znver1 issues

[amonakov at gcc dot gnu.org]

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

Alexander Monakov <amonakov at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amonakov at gcc dot gnu.org

--- Comment #8 from Alexander Monakov <amonakov at gcc dot gnu.org> ---
Also reproducible with -march=haswell, and works with 

  -mmove-max=128 -mstore-max=128 -mtune-ctrl=^sse_unaligned_store_optimal

added. I would guess the real culprit is commit  r12-2666-g29f0e955c97 ("x86:
Update piecewise move and store") like in PR 109780.

[Bug target/109982] csmith: x86_64: znver1 issues

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
                 CC|                            |hjl.tools at gmail dot com
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2023-05-26

--- Comment #9 from H.J. Lu <hjl.tools at gmail dot com> ---
[hjl@gnu-cfl-3 pr109982]$ cat x.c 
struct S0 {
   long long int f0;
} __attribute__((aligned(128)));

int padding = 1;
static struct S0 g_2415 __attribute__((aligned(4))) = {-1L};
static struct S0 *g_2500 __attribute__((visibility("internal"), used)) =
&g_2415;

const struct S0 func_21 ()
{
  return *g_2500;
}

int
main ()
{
  func_21 ();
  return 0;
}
[hjl@gnu-cfl-3 pr109982]$ make
gcc -mtune=haswell -mavx -g -w   -c -o x.o x.c
gcc -mtune=haswell -mavx -g -w -o x x.o
./x
make: *** [Makefile:16: all] Segmentation fault (core dumped)
[hjl@gnu-cfl-3 pr109982]$

[Bug target/109982] csmith: x86_64: znver1 issues

[hjl.tools at gmail dot com]

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

--- Comment #10 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to H.J. Lu from comment #9)
> [hjl@gnu-cfl-3 pr109982]$ cat x.c 
> struct S0 {
>    long long int f0;
> } __attribute__((aligned(128)));
> 
> int padding = 1;
> static struct S0 g_2415 __attribute__((aligned(4))) = {-1L};
> static struct S0 *g_2500 __attribute__((visibility("internal"), used)) =
> &g_2415;
> 

RTL expand has

(insn 7 6 8 (set (reg/f:DI 83) 
        (mem/f/c:DI (plus:DI (reg/f:DI 77 virtual-stack-vars)
                (const_int -8 [0xfffffffffffffff8])) [4 .result_ptr+0 S8 A64]))
"x.c":11:10 -1
     (nil))

(insn 8 7 9 (set (reg:OI 84) 
        (mem:OI (reg/f:DI 82 [ g_2500.0_1 ]) [2 *g_2500.0_1+0 S32 A1024]))
"x.c":11:10 -1
     (nil))

Alignment is wrong.

[Bug target/109982] csmith: x86_64: znver1 issues

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING

--- Comment #11 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to H.J. Lu from comment #9)
> [hjl@gnu-cfl-3 pr109982]$ cat x.c 
> struct S0 {
>    long long int f0;
> } __attribute__((aligned(128)));
> 
> int padding = 1;
> static struct S0 g_2415 __attribute__((aligned(4))) = {-1L};
> static struct S0 *g_2500 __attribute__((visibility("internal"), used)) =
> &g_2415;
> 

I think the code is invalid since g_2500 isn't pointed to properly aligned
data.

[Bug target/109982] csmith: x86_64: znver1 issues

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to H.J. Lu from comment #11)
> (In reply to H.J. Lu from comment #9)
> > [hjl@gnu-cfl-3 pr109982]$ cat x.c 
> > struct S0 {
> >    long long int f0;
> > } __attribute__((aligned(128)));
> > 
> > int padding = 1;
> > static struct S0 g_2415 __attribute__((aligned(4))) = {-1L};
> > static struct S0 *g_2500 __attribute__((visibility("internal"), used)) =
> > &g_2415;
> > 
> 
> I think the code is invalid since g_2500 isn't pointed to properly aligned
> data.

Yes, don't we diagnose this now?

[Bug target/109982] csmith: x86_64: znver1 issues

[amonakov at gcc dot gnu.org]

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

--- Comment #13 from Alexander Monakov <amonakov at gcc dot gnu.org> ---
No, neither for fields nor for the complete object:

struct
__attribute__((aligned(64)))
S {
    int i;
};

void f()
{
    struct S s __attribute__((aligned(1))), *p = &s;
    int *q = &s.i;
    asm("" :: "r"(p), "r"(q));
}

We have -Waddress-of-packed-member, which doesn't apply here.

But that said, even if we did, it was possible to miss the warning, because the
testcase emits hundreds of them and there was '-w' in the initial report.
David, did you somehow configure CSmith to emit attributes it wouldn't emit by
default? Emitting random attributes makes sense for testing error recovery (gcc
shouldn't ICE on nonsensical attribute combinations), but less so for checking
correctness of generated code, as we see here.

[Bug target/109982] csmith: x86_64: znver1 issues

[dcb314 at hotmail dot com]

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

--- Comment #14 from David Binderman <dcb314 at hotmail dot com> ---
(In reply to Alexander Monakov from comment #13)
> David, did you somehow configure CSmith to emit attributes it wouldn't emit by default?

Yes. Flag --compiler-attributes.

I went through the list of csmith compiler flags which are switched off by
default. --float, --int128, --uint128 were the other ones.

I tried those three out and got many runtime differences. So many that I am
waiting for the current set of csmith problems I have found to be resolved,
before reporting the new set.

> Emitting random attributes makes sense for testing
> error recovery (gcc shouldn't ICE on nonsensical attribute combinations),
> but less so for checking correctness of generated code, as we see here.

It's quite possible that flag --compiler-attributes doesn't work all that well,
so it was switched off. I am happy to switch it off in future.

[Bug target/109982] csmith: x86_64: znver1 issues

[amonakov at gcc dot gnu.org]

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

--- Comment #15 from Alexander Monakov <amonakov at gcc dot gnu.org> ---
For '--float' I think runtime differences are expected when you pass -m flags
that enable FMA, unless you also pass '-ffp-contract=off'.

For '--compiler-attributes' I'd suggest reporting only compiler ICEs (except if
you have some confidence the generated source is valid).

[Bug target/109982] csmith: x86_64: znver1 issues

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
On the other side, if --int128/--uint128 just mean __int128/unsigned
__int128/__int128_t/__uint128_t types can be used, if the base csmith options
with just those two enabled result in code generation issues, that would be
very helpful to report.