[Bug target/65932] New: [5.1 Regression] Linux-3.10.75 on arm926ej-s does not boot due to wrong code generation

[Bug target/65932] New: [5.1 Regression] Linux-3.10.75 on arm926ej-s does not boot due to wrong code generation

[christian.eggers at kathrein dot de]

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

            Bug ID: 65932
           Summary: [5.1 Regression] Linux-3.10.75 on arm926ej-s does not
                    boot due to wrong code generation
           Product: gcc
           Version: 5.1.1
            Status: UNCONFIRMED
          Severity: critical
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: christian.eggers at kathrein dot de
  Target Milestone: ---

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

gcc version: 5.1.0 / 5.1.1 (current git snapshot)

host : x86_64_suse_linux (13.1)

target: arm-arm926ejs-linux-gnueabi

Configured with:
/home/eggers/Projekte/cds/repos/software/tools/toolchain/src/gcc-gcc-5-branch-1e71966/configure
--prefix=/home/eggers/Projekte/cds/repos/software/tools/toolchain/build/arm-arm926ejs-linux-gnueabi/arm-arm926ejs-linux-gnueabi
--with-pkgversion='Kathrein CDS 15278' --target=arm-arm926ejs-linux-gnueabi
--disable-multilib
--mandir=/home/eggers/Projekte/cds/repos/software/tools/toolchain/build/arm-arm926ejs-linux-gnueabi/arm-arm926ejs-linux-gnueabi/share/man
--infodir=/home/eggers/Projekte/cds/repos/software/tools/toolchain/build/arm-arm926ejs-linux-gnueabi/arm-arm926ejs-linux-gnueabi/share/info
--with-gmp=/home/eggers/Projekte/cds/repos/software/tools/toolchain/build/install
--with-mpfr=/home/eggers/Projekte/cds/repos/software/tools/toolchain/build/install
--with-mpc=/home/eggers/Projekte/cds/repos/software/tools/toolchain/build/install
--with-isl=/home/eggers/Projekte/cds/repos/software/tools/toolchain/build/install
--with-sysroot=/home/eggers/Projekte/cds/repos/software/tools/toolchain/build/arm-arm926ejs-linux-gnueabi/arm-arm926ejs-linux-gnueabi/sys-root
--disable-nls
--with-slibdir=/home/eggers/Projekte/cds/repos/software/tools/toolchain/build/arm-arm926ejs-linux-gnueabi/arm-arm926ejs-linux-gnueabi/sys-root/lib
--with-gxx-include-dir=/home/eggers/Projekte/cds/repos/software/tools/toolchain/build/arm-arm926ejs-linux-gnueabi/arm-arm926ejs-linux-gnueabi/sys-root/usr/include/c++/gcc-5-branch-1e71966
--enable-shared --enable-__cxa_atexit --enable-c99 --enable-threads=posix
--disable-install-libiberty --with-system-zlib --with-cpu=arm926ej-s
--with-float=soft --with-mode=arm --enable-languages=c,c++ --enable-long-long

command line: arm-arm926ejs-linux-gnueabi-gcc -Wp,-MD,lib/.vsprintf.o.d 
-nostdinc -isystem
/home/eggers/Projekte/cds/repos/software/tools/toolchain/build/arm-arm926ejs-linux-gnueabi/arm-arm926ejs-linux-gnueabi/lib64/gcc/arm-arm926ejs-linux-gnueabi/5.1.0/include
-I/home/eggers/Projekte/cds/repos/software/cts/common/platform_linux/external/kernel/linux/linux-3.10/arch/arm/include
-Iarch/arm/include/generated 
-I/home/eggers/Projekte/cds/repos/software/cts/common/platform_linux/external/kernel/linux/linux-3.10/include
-Iinclude
-I/home/eggers/Projekte/cds/repos/software/cts/common/platform_linux/external/kernel/linux/linux-3.10/arch/arm/include/uapi
-Iarch/arm/include/generated/uapi
-I/home/eggers/Projekte/cds/repos/software/cts/common/platform_linux/external/kernel/linux/linux-3.10/include/uapi
-Iinclude/generated/uapi -include
/home/eggers/Projekte/cds/repos/software/cts/common/platform_linux/external/kernel/linux/linux-3.10/include/linux/kconfig.h

-I/home/eggers/Projekte/cds/repos/software/cts/common/platform_linux/external/kernel/linux/linux-3.10/lib
-Ilib -D__KERNEL__ -mlittle-endian  
-I/home/eggers/Projekte/cds/repos/software/cts/common/platform_linux/external/kernel/linux/linux-3.10/arch/arm/mach-at91/include
-Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing
-fno-common -Werror-implicit-function-declaration -Wno-format-security
-fno-delete-null-pointer-checks -Os -Wno-maybe-uninitialized
-fno-dwarf2-cfi-asm -mabi=aapcs-linux -mno-thumb-interwork -funwind-tables
-marm -D__LINUX_ARM_ARCH__=5 -march=armv5te -mtune=arm9tdmi -msoft-float -Uarm
-Wframe-larger-than=1024 -fno-stack-protector -Wno-unused-but-set-variable
-fomit-frame-pointer -fno-var-tracking-assignments -g
-fno-inline-functions-called-once -Wdeclaration-after-statement
-Wno-pointer-sign -fno-strict-overflow -fconserve-stack -DCC_HAVE_ASM_GOTO   
-D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(vsprintf)" 
-D"KBUILD_MODNAME=KBUILD_STR(vsprintf)" -c -o lib/vsprintf.o
/home/eggers/Projekte/cds/repos/software/cts/common/platform_linux/external/kernel/linux/linux-3.10/lib/vsprintf.c

linux-3.10.75 compiled with gcc-4.9.2  --> running
same kernel compiled with gcc-5.1.0 / gcc-5.1.1 (git snapshot) --> NOT running

Observations

Function string() (part of vsnprintf()) in lib/vsprintf.c is not compiled
correctly:

     f5c:       e1dd51f8        ldrsh   r5, [sp, #24]

[...] 
# r5 = 0xFFFF FFFF
     f70:       e2453001        sub     r3, r5, #1
# r3 = 0xFFFF FFFE
     f74:       e1a03803        lsl     r3, r3, #16
# r3 = 0xFFFE 0000
                while (len < spec.field_width--) {
     f78:       e1500005        cmp     r0, r5
# r0 = 8
# r5 = 0xFFFF FFFF  --> correct
     f7c:       e1a03823        lsr     r3, r3, #16
# r3 = 0x0000 FFFE
     f80:       aa000005        bge     f9c <string.isra.5+0x64>
# branch taken --> correct

[...]
     f9c:       e1a05003        mov     r5, r3
# r5 = r3 = 0x0000 FFFE

[...]
        while (len < spec.field_width--) {
     fdc:       e1500005        cmp     r0, r5
# r0 (len) = 8
# r5 (spec.field_width) is still 0x0000 FFFE  --> not ok
# spec.field_width should be 0xFFFF FFFE at this point

     fe0:       e1a03823        lsr     r3, r3, #16
     fe4:       aa000005        bge     1000 <string.isra.5+0xc8>
# branch NOT taken --> wrong

[Bug target/65932] [5 Regression] Linux-3.10.75 on arm926ej-s does not boot due to wrong code generation

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
             Target|                            |arm-arm926ejs-linux-gnueabi
   Target Milestone|---                         |5.2
            Summary|[5.1 Regression]            |[5 Regression]
                   |Linux-3.10.75 on arm926ej-s |Linux-3.10.75 on arm926ej-s
                   |does not boot due to wrong  |does not boot due to wrong
                   |code generation             |code generation

[Bug target/65932] [5 Regression] Linux-3.10.75 on arm926ej-s does not boot due to wrong code generation

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw <rearnsha at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-04-30
     Ever confirmed|0                           |1

--- Comment #1 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
The type of field_width is a signed short.  On that basis, the use of LSR
rather than ASR looks highly suspicious.

[Bug rtl-optimization/65932] [5 Regression] Linux-3.10.75 on arm926ej-s does not boot due to wrong code generation

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw <rearnsha at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|target                      |rtl-optimization

--- Comment #2 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
The problem seems to be creeping in during the initial expand pass.  I can't be
sure, but my suspicions are leaning towards this being some artifact of the
ipa-sra decomposition of the 'spec' argument.  code built with -fno-ipa-sra
appears to be ok on a visual inspection.

[Bug rtl-optimization/65932] [5 Regression] Linux-3.10.75 on arm926ej-s does not boot due to wrong code generation

[ceggers at gmx dot de]

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

Christian Eggers <ceggers at gmx dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ceggers at gmx dot de

--- Comment #3 from Christian Eggers <ceggers at gmx dot de> ---
(In reply to Richard Earnshaw from comment #2)
> code built with -fno-ipa-sra appears to be ok on a visual inspection.

Unfortunately I'll be on vacation until Tuesday, 7th. Then I can try to build
to whole kernel with this flag.

[Bug rtl-optimization/65932] [5 Regression] Linux-3.10.75 on arm926ej-s does not boot due to wrong code generation

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
If -fno-ipa-sra cures this, I wonder if it hasn't started with r221348.
Some issues related to that were fixed with r221795, but some clearly haven't -
e.g. I believe profiledbootstrap is still broken on arm and today I'm reducing
another runtime failure that regressed with r221348 on armv7hl and r221795
doesn't fix that.  -fno-ipa-sra cures that as well.

[Bug rtl-optimization/65932] [5 Regression] Linux-3.10.75 on arm926ej-s does not boot due to wrong code generation

[christian.eggers at kathrein dot de]

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

--- Comment #5 from Christian Eggers <christian.eggers at kathrein dot de> ---
(In reply to Richard Earnshaw from comment #2)
> code built with
> -fno-ipa-sra appears to be ok on a visual inspection.

linux-3.10.25 boots fine if globally compiled with additional -fno-ipa-sra

The affected linux system is a arm926ej-s. Is this bug also relevant for my
Cortex-M boards?

[Bug rtl-optimization/65932] [5 Regression] Linux-3.10.75 on arm926ej-s does not boot due to wrong code generation

[gcc_email at congenio dot de]

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

Dr. Uwe Meyer-Gruhl <gcc_email at congenio dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gcc_email at congenio dot de

--- Comment #6 from Dr. Uwe Meyer-Gruhl <gcc_email at congenio dot de> ---
Just a feedback for another target platform (arm-none-eabi): I also had
problems with a kernel 4.0.4 on an iConnect (Kirkwood variant) when I used gcc
5.1.0.

Using KCFLAGS='-fno-ipa-sra' helped immediately. I did not look into the
generated code, though, but I assume this is the same problem.

[Bug rtl-optimization/65932] [5 Regression] Linux-3.10.75 on arm926ej-s does not boot due to wrong code generation

[aaro.koskinen at iki dot fi]

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

--- Comment #7 from Aaro Koskinen <aaro.koskinen at iki dot fi> ---
The issue is also present when compiling kernels for OMAP1/2 platforms. Also
looks like -Os is needed to trigger this. Kernels compiled with -O2 seem to
work.

[Bug rtl-optimization/65932] [5 Regression] Linux-3.10.75 on arm926ej-s does not boot due to wrong code generation

[gccbugs at rooted dot tk]

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

gccbugs at rooted dot tk changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gccbugs at rooted dot tk

--- Comment #8 from gccbugs at rooted dot tk ---
Can confirm this on the 5-20150519 snapshot. Here's a self-contained snippet
demonstrates this problem (from vsprintf.c):

https://gcc.gnu.org/bugzilla/attachment.cgi?id=35613

[Bug rtl-optimization/65932] [5 Regression] Linux-3.10.75 on arm926ej-s does not boot due to wrong code generation

[miyuki at gcc dot gnu.org]

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

Mikhail Maltsev <miyuki at gcc dot gnu.org> changed:

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

--- Comment #9 from Mikhail Maltsev <miyuki at gcc dot gnu.org> ---
Created attachment 35714
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35714&action=edit
Code compiled with r212399

[Bug rtl-optimization/65932] [5 Regression] Linux-3.10.75 on arm926ej-s does not boot due to wrong code generation

[miyuki at gcc dot gnu.org]

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

--- Comment #10 from Mikhail Maltsev <miyuki at gcc dot gnu.org> ---
Created attachment 35715
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35715&action=edit
Code compiled with r212400

There is a change from arithmetic shift to logical shift.

[Bug rtl-optimization/65932] [5 Regression] Linux-3.10.75 on arm926ej-s does not boot due to wrong code generation

[wilson at gcc dot gnu.org]

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

Jim Wilson <wilson at gcc dot gnu.org> changed:

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

--- Comment #11 from Jim Wilson <wilson at gcc dot gnu.org> ---
There is another testcase in 66271.

The LSR is emitted because the arm port has PROMOTE_MODE defined to make chars
and shorts unsigned when extended to int.  So the problem seems to be why it
wasn't re-sign-extended before the compare.  Maybe an optimization pass
incorrectly deleted that sign-extend.

[Bug rtl-optimization/65932] [5 Regression] Linux-3.10.75 on arm926ej-s does not boot due to wrong code generation

[wilson at gcc dot gnu.org]

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

--- Comment #12 from Jim Wilson <wilson at gcc dot gnu.org> ---
Part of the problem here is that the arm port defines PROMOTE_MODE to force
short local variables to unsigned, but arm_promote_function_mode doesn't change
signedness.  So a signed short parameter and a signed short local have
different representations in a register.

Another part of the problem is that the eipa_sra pass is creating phi nodes
that mix parameters and local variables.  Copying a signed short local into a
signed short parameter requires a conversion, even though they have the same
type, because they get different in register promotion.

Another part of the problem is that the out-of-ssa pass when evaluating phi
nodes doesn't go through expand_expr, and hence doesn't handle mode promotion. 
The code is copying DECL_RTL directly into SA.partition_to_pseudo, and then
using SA.partition_to_pseudo when emitting the copy instructions.  Thus these
phi nodes won't emit any conversion instructions even though one is apparently
required.

I can get correct code if I pass DECL_RTL through expand_expr before storing it
into SA.partition_to_pseudo for VAR_DECLs.  However, if I then do the same
thing for PARM_DECLS, then I get a movhi insn instead of a conversion, because
both the source and dest are promoted subregs.  I think the problem here is
that emit_partition_copy doesn't handle promoted subregs.  I think we need
something like what store_expr_with_bounds does, when the dest is a promoted
subreg, to do the copy to the smaller mode, and then convert to the wider mode.
 But I have a few too many suppositions at this point and am not sure if this
makes sense.

It might be simpler to change the arm port so that promote_mode and
function_promote_mode match.

[Bug rtl-optimization/65932] [5 Regression] Linux-3.10.75 on arm926ej-s does not boot due to wrong code generation

[wilson at gcc dot gnu.org]

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

--- Comment #13 from Jim Wilson <wilson at gcc dot gnu.org> ---
Created attachment 35774
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35774&action=edit
Experimental patch to force out-of-ssa to use promoted subregs for phi nodes.

[Bug rtl-optimization/65932] [5 Regression] Linux-3.10.75 on arm926ej-s does not boot due to wrong code generation

[wilson at gcc dot gnu.org]

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

--- Comment #14 from Jim Wilson <wilson at gcc dot gnu.org> ---
Created attachment 35775
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35775&action=edit
A possibly better patch, to modify ARM port to stop changing signed HI/QI to
unsigned.

This would require performance testing to see what the effect is.  This is a
simpler patch than trying to change the out-of-ssa pass.

[Bug rtl-optimization/65932] [5 Regression] Linux-3.10.75 on arm926ej-s does not boot due to wrong code generation

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2

[Bug rtl-optimization/65932] [5 Regression] Linux-3.10.75 on arm926ej-s does not boot due to wrong code generation

[wilson at gcc dot gnu.org]

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

--- Comment #17 from Jim Wilson <wilson at gcc dot gnu.org> ---
I've been researching how the ARM PROMOTE_MODE reached its current state. 
There are a number of issues here.

1) There is a comment that says zero extension is faster for char than signed
extension.  This is only true before the [su]xtb instructions were added, i.e.
!arm_arch6.  Before these instructions, zero extend can be done with an and
immediate, but sign extension requires two shifts.  So there is no benefit to
zero extension for current architectures.

2) The comment doesn't apply to shorts, which require two shifts for both zero
and sign extension when !arm_arch6.  The signedness was changed for shorts
originally because some processors did not support unaligned accesses, and had
to loads shorts with two load byte instructions.  This required 3 insns for
zero extend and 4 for sign extend, so there was an advantage to zero extension,
but only if the processor did not support unaligned accesses.  Unfortunately,
the support was flawed, and did
        UNSIGNEDP = TARGET_MMU_TRAPS != 0;      \
which forces it to unsigned for MMU_TRAPS and signed for the default case.  It
should have been something like
        if (TARGET_MMU_TRAPS) UNSIGNEDP = 1; \
When the TARGET_MMU_TRAPS feature was removed, this code was changed to set
UNSIGNEDP to 0 unconditionally, which compounded the error.  This code should
have been removed when the TARGET_MMU_TRAPS feature was removed.

3) Originally PROMOTE_FUNCTION_ARGS was a boolean that indicated whether
PROMOTE_MODE applied to function arguments or not.  When it was changed to a
hook, it was made into a function.  So now we have two sets of similar code,
one in PROMOTE_MODE and one in arm_promote_function_mode
(TARGET_PROMOTE_FUNCTION_MODE).  The two sets of code should be identical, but
the unsigned-ness changing was left out of the arm_promote_function_mode code. 
The result is that we have two different in-register representations for signed
char/short symbols, one form for parameters and one form for local variables. 
This inconsistency is confusing the out-of-ssa pass.  Since changing
arm_promote_function_mode is effectively an ABI change, it is safer to change
PROMOTE_MODE to match.

4) There is a general principle that you should not change signedness in
PROMOTE_MODE unless the hardware forces you to do so.  For instance, for the
MIPS64 target, the hardware requires that all 32-bit values in 64-bit registers
be sign-extended, and 32-bit instructions may trap if this is not true.  Thus
the mips port forces all 32-bit values to be signed.  But the arm architecture
has no similar constraint, and hence we should not be changing signedness here.
 Changing signedness results in less efficient code, as can be seen in this
testcase, where the compiler must emit both a zero-extend and a sign-extend in
the loop.  The sign-extend is required to get correct results for a compare,
and the zero-extend is required because PROMOTE_MODE requires it.

[Bug rtl-optimization/65932] [5 Regression] Linux-3.10.75 on arm926ej-s does not boot due to wrong code generation

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|5.2                         |5.3

--- Comment #19 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 5.2 is being released, adjusting target milestone to 5.3.

[Bug rtl-optimization/65932] [5 Regression] Linux-3.10.75 on arm926ej-s does not boot due to wrong code generation

[wilson at gcc dot gnu.org]

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

--- Comment #20 from Jim Wilson <wilson at gcc dot gnu.org> ---
*** Bug 66271 has been marked as a duplicate of this bug. ***