[Bug c/105134] New: tree-vectorize produces error code

[Bug c/105134] New: tree-vectorize produces error code

[piliu at redhat dot com]

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

            Bug ID: 105134
           Summary: tree-vectorize produces error code
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: piliu at redhat dot com
  Target Milestone: ---

On x86_64, kexec-tools built with gcc-12 can not boot the 2nd kernel
successfully.

After debugging, it turns out to be related with "tree-vectorize" option.
As kexec-tools commit 1b03cf7 purgatory: do not enable vectorization
automatically for purgatory compiling.

I have no idea about what happens, but it seems to be related with the
generation of the code piece

void sha256_starts( sha256_context *ctx )
{
        ctx->total[0] = 0;
        ctx->total[1] = 0;

        ctx->state[0] = 0x6A09E667;
        ctx->state[1] = 0xBB67AE85;
        ctx->state[2] = 0x3C6EF372;
        ctx->state[3] = 0xA54FF53A;
        ctx->state[4] = 0x510E527F;
        ctx->state[5] = 0x9B05688C;
        ctx->state[6] = 0x1F83D9AB;
        ctx->state[7] = 0x5BE0CD19;
}

[Bug c/105134] tree-vectorize produces error code

[piliu at redhat dot com]

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

--- Comment #1 from piliu at redhat dot com ---
More description about the background.

There is a built file kexec-tools/purgatory/purgatory.ro, which is a tiny
bootload, compare and verify the sha256, if ok, then jump to the 2nd kernel.

The original sha256 value comes from
update_purgatory()
{
......
        elf_rel_set_symbol(&info->rhdr, "sha256_regions", &region,
                           sizeof(region));
        elf_rel_set_symbol(&info->rhdr, "sha256_digest", &digest,
                           sizeof(digest));

}

They are based on the loaded linux kernel image.

Now, "kexec -e" and purgatory.ro runs, and in
void purgatory(void)
{
        printf("I'm in purgatory\n");
        setup_arch();
        if (!skip_checks && verify_sha256_digest()) {
                for(;;) {
                        /* loop forever */   ------> stuck here
                }
        }
        post_verification_setup_arch();
}

[Bug c/105134] tree-vectorize produces error code

[piliu at redhat dot com]

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

--- Comment #2 from piliu at redhat dot com ---
More specific, the following directive beats out the bug.

diff --git a/util_lib/sha256.c b/util_lib/sha256.c
index 2e61a31..3b3e533 100644
--- a/util_lib/sha256.c
+++ b/util_lib/sha256.c
@@ -38,6 +38,7 @@
        (b)[(i) + 3] = (uint8_t) ( (n)       ); \
 }

+ __attribute__((optimize("no-tree-vectorize")))
 void sha256_starts( sha256_context *ctx )

[Bug c/105134] tree-vectorize produces error code

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2022-04-04
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |WAITING

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Can you provide preprocessed source of the TU containing sha256_starts and the
full compiler command-line used to compile it?

[Bug c/105134] tree-vectorize produces error code

[piliu at redhat dot com]

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

--- Comment #4 from piliu at redhat dot com ---
(In reply to Richard Biener from comment #3)
> Can you provide preprocessed source of the TU containing sha256_starts and
> the full compiler command-line used to compile it?

For a single file.
gcc -fno-zero-initialized-in-bss -mcmodel=large -Os -fno-builtin -ffreestanding
-fno-zero-initialized-in-bss -fno-PIC -fno-PIE -fno-stack-protector -O2 
-mcmodel=large -I./purgatory/include -I./purgatory/arch/x86_64/include
-I./util_lib/include -I./include -Iinclude
-I/usr/lib/gcc/x86_64-redhat-linux/12/include  -c -o purgatory/sha256.o
util_lib/sha256.c

For the complete compile log, please see the attachment.

[Bug c/105134] tree-vectorize produces error code

[piliu at redhat dot com]

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

--- Comment #5 from piliu at redhat dot com ---
Created attachment 52756
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52756&action=edit
-ftree-vectorize can not produce correct code for kexec-tools

[Bug c/105134] tree-vectorize produces error code

[piliu at redhat dot com]

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

--- Comment #6 from piliu at redhat dot com ---
Created attachment 52757
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52757&action=edit
precompiled code of sha256

compile command:

gcc -E -fno-zero-initialized-in-bss -mcmodel=large -Os -fno-builtin
-ffreestanding -fno-zero-initialized-in-bss -fno-PIC -fno-PIE
-fno-stack-protector -O2  -mcmodel=large -I./purgatory/include
-I./purgatory/arch/x86_64/include -I./util_lib/include -I./include -Iinclude
-I/usr/lib/gcc/x86_64-redhat-linux/12/include  -c -o purgatory/sha256.o
util_lib/sha256.c

[Bug c/105134] tree-vectorize produces error code

[pinskia at gcc dot gnu.org]

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

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I am trying to understand this. Is it ok to use the SSE registers inside
purgatory or not?

Now that the vectorizer is used turned on at -O2 and above, without -mno-sse,
on x86_64 target, the vector instructions are generated. and since this is
inside a tiny bootloader, I am suspecting you can't use SSE instructions here.

So the real fix is to use -mno-sse for x86_64 while compiling files under
purgatory .

[Bug c/105134] tree-vectorize produces error code

[pinskia at gcc dot gnu.org]

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

--- Comment #8 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Looks like only ppc64 does:

ppc64_PURGATORY_EXTRA_CFLAGS += -m64 -msoft-float \
                                -fno-exceptions

Most likely purgatory/arch/x86_64/Makefile needs the following added the end of
the file instead:
x86_64_PURGATORY_EXTRA_CFLAGS += -mno-sse

(-mgeneral-regs-only might work these days too)


purgatory/arch/arm64/Makefile needs the following added too:
arm64_PURGATORY_EXTRA_CFLAGS += -mgeneral-regs-only

Other targets might need other CFLAGS set here for the same reason.

[Bug c/105134] tree-vectorize produces error code

[pinskia at gcc dot gnu.org]

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

--- Comment #9 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git/commit/purgatory/Makefile?id=1b03cf7adc3c156ecab2618acb1ec585336a3f75
was the commit to "fix" this but as I think I mentioned here it is just a
workaround for expecting SSE code to work and GCC might emit SSE code in other
places without the autovectorizer enabled so ....

[Bug c/105134] tree-vectorize produces error code

[piliu at redhat dot com]

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

--- Comment #10 from piliu at redhat dot com ---
(In reply to Andrew Pinski from comment #7)
> I am trying to understand this. Is it ok to use the SSE registers inside
> purgatory or not?
> 

SSE can speed up the program, and if possible it is suggested to turn on.

Any guideline about when it can not be used?

> Now that the vectorizer is used turned on at -O2 and above, without
> -mno-sse, on x86_64 target, the vector instructions are generated. and since
> this is inside a tiny bootloader, I am suspecting you can't use SSE
> instructions here.
> 

What is broken by SSE? That can be more persuaded.

Thanks,

Pingfan

[Bug c/105134] tree-vectorize produces error code

[pinskia at gcc dot gnu.org]

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

--- Comment #11 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to piliu from comment #10)
> (In reply to Andrew Pinski from comment #7)
> > I am trying to understand this. Is it ok to use the SSE registers inside
> > purgatory or not?
> > 
> 
> SSE can speed up the program, and if possible it is suggested to turn on.
> 
> Any guideline about when it can not be used?

Yes if you are inside the kernel/bootloader SSE might not be turned on. So my
question here. Normal parts of the kernel cannot use SSE instructions either
which is why there is an option to turn it off.
Maybe it is best to ask the kexec-tools folks if SSE can be used here.
I suspect you cannot.
GCC was not emitting SSE instructions before and now is at -O2 which is why
-fno-tree-vectorize works as it turns off emitting of SSE instructions again.

There is nothing wrong with what GCC emits for sha256_starts for the options
kexec-tools supplied even, just it is supplying the wrong set of options in the
first place.

For user code SSE code is always fine as the compiler and glibc has been using
SSE code early on. As I said it if it is a bootloader/kernel, then you have to
ask is SSE turned on or not and do we save/restore the registers correctly,
etc.

[Bug tree-optimization/105134] tree-vectorize produces error code

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
          Component|c                           |tree-optimization
         Resolution|---                         |INVALID

--- Comment #12 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
So reading the change that was done for powerpc:
https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git/commit/purgatory/arch/ppc64/Makefile?id=d40badaa2553c44d0585df335ad7e1c465f8ced1

"Some investigation revealed that gcc is generating hardware FPU instructions.
I have been told we can't use it at this point of time and as kernel"

x86_64 should use -mgeneral-regs-only or -mno-sse  for building this source.

I wonder arm64 should use -mgeneral-regs-only too.