ICE in push_minipool_fix when building rtl8723ae kernel driver

[Arnd Bergmann]

arm-linux-gnueabihf-gcc-4.8 -mlong-calls -Wp,-MD,drivers/net/wireless/rtlwifi/rtl8192ce/.hw.o.d -nostdinc -isystem /usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/include -I/git/arm-soc/arch/arm/include -Iarch/arm/include/generated -I/git/arm-soc/include -Iinclude -I/git/arm-soc/arch/arm/include/uapi -Iarch/arm/include/generated/uapi -I/git/arm-soc/include/uapi -Iinclude/generated/uapi -include /git/arm-soc/include/linux/kconfig.h -I/git/arm-soc/drivers/net/wireless/rtlwifi/rtl8192ce -Idrivers/net/wireless/rtlwifi/rtl8192ce -D__KERNEL__ -mlittle-endian -I/git/arm-soc/arch/arm/mach-dove/include -I/git/arm-soc/arch/arm/plat-orion/include -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -fno-delete-null-pointer-checks -O2 -fno-dwarf2-cfi-asm -mno-unaligned-access -fno-omit-frame-pointer -mapcs -mno-sched-prolog -mabi=aapcs-linux -mno-thumb-interwork -mfpu=vfp -marm -D__LINUX_ARM_ARCH__=7 -march=armv7-a -msoft-float -Uarm -Wframe-larger-than=1024 -Wno-unused-but-set-variable -fno-omit-frame-pointer -fno-optimize-sibling-calls -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fconserve-stack -Werror=implicit-int -Werror=strict-prototypes -DCC_HAVE_ASM_GOTO -D__CHECK_ENDIAN__ -DMODULE -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(hw)" -D"KBUILD_MODNAME=KBUILD_STR(rtl8192ce)" -c -o drivers/net/wireless/rtlwifi/rtl8192ce/hw.o /git/arm-soc/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c
/git/arm-soc/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c: In function '_rtl92ce_read_adapter_info':
/git/arm-soc/drivers/net/wireless/rtlwifi/rtl8192ce/hw.c:1762:1: internal compiler error: in push_minipool_fix, at config/arm/arm.c:14040
 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-4.8/README.Bugs> for instructions.
Preprocessed source stored into /tmp/ccSN3mtb.out file, please attach this to your bugreport.

$ gcc --version
gcc (Ubuntu/Linaro 4.8.1-10ubuntu9) 4.8.1
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ uname -a
Linux wuerfel 3.11.0-18-generic #32-Ubuntu SMP Tue Feb 18 21:11:14 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

[Philip Blundell (philb-gnu)]

$ arm-oe-linux-gnueabi-gcc -march=armv7-a -O2 -S -mfloat-abi=softfp -mfpu=vfp svga_tgsi_insn.i
svga_tgsi_insn.c: In function 'svga_shader_emit_instructions':
svga_tgsi_insn.c:2969:1: internal compiler error: in push_minipool_fix, at config/arm/arm.c:12138
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
$

[Philip Blundell (philb-gnu)]

Created attachment 24537
testcase

[Mikpelinux (mikpelinux)]

I can reproduce the ICE on armv5tel-linux-gnueabi with gcc-4.6.0 and 4.6-20110617, but not with gcc-4.5.3 or the latest 4.7 snapshot.

The ICE stopped occurring on trunk with r170984 (PR41490 fix). However that's a generic missed-optimization fix, so I suspect the bug is latent on trunk.

[Mikpelinux (mikpelinux)]

It's caused by r164136:

Author: jamborm
Date: Thu Sep 9 23:38:23 2010
New Revision: 164136

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164136
Log:
2010-09-10 Martin Jambor <email address hidden>

 PR tree-optimization/44972
 * tree-sra.c: Include toplev.h.
 (build_ref_for_offset): Entirely reimplemented.
...

That makes it probably related to PR49094, although in this PR's test case the one occurrence of attribute((aligned(N)) doesn't matter for the ICE.

[Jamborm (jamborm)]

Possibly, yes. I plan to submit a fix for PR49094 this week, please
try after that.

[Ramana-gcc (ramana-gcc)]

doesn't seem to occur on 4.5 branch or on trunk.

Ramana

[Jamborm (jamborm)]

I have just committed a fix for PR 49094 to the 4.6 branch. Please
try again now. Thanks.

[Mikpelinux (mikpelinux)]

gcc-4.6-20110715 still ICEs on this test case, so unfortunately the PR49094 fix didn't solve this problem.

[Jamborm (jamborm)]

I'm sorry I forgot about this bug but I finally remembered to have a
look today. Unfortunately, on i686 host I was able to reproduce the
ICE also with revisions 164134 and 164135 and so I assumed that Mikael
made a mistake when he tracked the cause of the ICE to my commit in
comment #3. When verifying that on an x86_64 host, I realized that
the ICE indeed started happening with my commit but it re-appeared
quickly with previous revisions when I added -fno-tree-sra to the
command line options. Therefore I believe my patch did not cause any
bug but uncovered some other issue elsewhere.

In order to help at least a little, I did my own bisecting, this time
with -fno-tree-sra, and to me it appears the ICE (still present on the
4.6 branch) is introduced by revision 163935:

2010-09-07 Bernd Schmidt <email address hidden>

        PR target/43137
        * config/arm/iterators.md (qhs_zextenddi_cond, qhs_sextenddi_cond):
        New define_mode_attrs.
        * config/arm/arm.md (zero_extendsidi2, arm_zero_extendsidi2,
        arm_exxtendsidi2, arm_extendsidi2): Delete patterns.
        (zero_extend<mode>di2, extend<mode>di2 and related splits): New.
        (thumb1_zero_extendhisi2): Remove code to handle LABEL_REFs.
        Remove pool_range attribute.
        (arm_zero_extendhisi2, arm_zero_extendhisi2_v6, arm_zero_extendqisi2,
        arm_zero_extendqisi2_v6, thumb1_zero_extendqisi2_v6): Remove
        pool_range and neg_pool_range attributes.
        * config/arm/thumb2.md (thumb2_zero_extendsidi2,
        thumb2_zero_extendhidi2, thumb2_zero_extendqidi2, thumb2_extendsidi2,
        thumb2_extendhidi2, thumb2_extendqidi2): Delete.

[Pinskia (pinskia)]

I get this same ICE while compiling gcc.c-torture/execute/scal-to-vec2.c at -O1 with a 4.7 configured with --with-arch=armv7-a --with-fpu=vfp --with-float=hard .

(gdb) p debug_rtx(insn)
(insn 357 1038 1041 (set (reg:SI 14 lr)
        (zero_extend:SI (mem/u/c:HI (symbol_ref/u:SI ("*.LC0") [flags 0x2]) [0 S2 A16]))) t.c:49 161 {*arm_zero_extendhisi2_v6}
     (nil))
$4 = void

Both arm_zero_extendhisi2 and arm_zero_extendhisi2_v6 are missing pool_range/neg_pool_range .

[Pinskia (pinskia)]

*** Bug 49135 has been marked as a duplicate of this bug. ***

[Pinskia (pinskia)]

*** Bug 52836 has been marked as a duplicate of this bug. ***

[Dinar Temirbulatov (dtemirbulatov)]

Created attachment 28273
testcase for gcc-4.6 and gcc-4.7

Here is another testcase for gcc-4.6 and gcc-4.7

[Dinar Temirbulatov (dtemirbulatov)]

This time it is "arm_zero_extendqisi2_v6" pattern

[Dinar Temirbulatov (dtemirbulatov)]

(gdb) call debug_rtx(insn)
(insn:TI 454 460 607 (set (reg:SI 2 r2 [orig:433 buf+2 ] [433])
        (zero_extend:SI (mem/u/c/i:QI (symbol_ref/u:SI ("*.LC0") [flags 0x2])
[0 S1 A8]))) cr_parse-reduced.ii:111 168 {*arm_zero_extendqisi2_v6}
     (nil))

[Dinar Temirbulatov (dtemirbulatov)]

here is command and flags to reproduce the second testcase on 4.6 and 4.7 : cc1plus -mcpu=cortex-a15 -mfpu=neon -mfloat-abi=hard -ftree-vectorize -O3 cr_parse-reduced-fsf.ii -o /tmp/1.s

[Dinar Temirbulatov (dtemirbulatov)]

this regression after PR43137, also absence of pool range predicates for arm_zero_extendqisi2, arm_zero_extendqisi2_v6, arm_zero_extendhisi2, arm_zero_extendhisi2_v6 caused gcc.c-torture/compile/920928-2.c to fail with ICE by using -Os flag.

[Jakub-gcc (jakub-gcc)]

Another testcase for -march=armv7-a -O2, ICEs with both trunk and 4.8 branch (reduced from https://bugzilla.redhat.com/show_bug.cgi?id=927565 ):
const int a, b[4][256], c[4][256];
int
foo (unsigned *x)
{
  unsigned d[9];
  x[55] = c[0][d[7] & 0xff] ^ c[3][d[7] & 0xff];
  d[0] = (b[0][d[7] & 0xff] ^ b[1][(d[7] >> 16) & 0xff] ^ b[2][d[7] & 0xff] ^ b[3][d[7] & 0xff]) ^ a;
  x[48] = c[0][d[0] & 0xff] ^ c[1][(d[0] >> 8) & 0xff] ^ c[2][(d[0] >> 16) & 0xff] ^ c[3][d[0] >> 24];
  x[49] = c[0][d[1] & 0xff] ^ c[1][(d[1] >> 8) & 0xff] ^ c[2][d[1] & 0xff] ^ c[3][d[1]];
  d[4] = b[0][0xff] ^ b[1][8] ^ b[3][d[3] >> 24];
  x[44] = c[0][d[4] & 0xff] ^ c[1][(d[4] >> 8) & 0xff] ^ c[2][(d[4] >> 16) & 0xff] ^ c[3][d[4] >> 24];
  d[5] ^= d[4];
  x[45] = c[0][d[5] & 0xff] ^ c[1][d[5]] ^ c[2][(d[5] >> 16) & 0xff] ^ c[3][(d[5] >> 24) & 0xff];
  d[6] ^= d[5];
  x[46] = c[0][d[6] & 0xff] ^ c[3][d[6] & 0xff];
  d[7] ^= d[6];
  x[47] = c[0][d[7]] ^ c[3][(d[7] >> 24) & 0xff];
}

p debug_rtx (fix->insn)
(insn:TI 6 155 156 (set (reg:SI 5 r5 [orig:110 D.4236 ] [110])
        (zero_extend:SI (mem/u/c:QI (symbol_ref/u:SI ("*.LC0") [flags 0x2]) [0 S1 A8]))) rh927565.i:6 171 {*arm_zero_extendqisi2_v6}
     (nil))

If the PR43137 changes removed the pool_range/neg_pool_range attributes from the instructions incorrectly, can those be added? I mean, for ICE on valid code with so many dups it is ridiculous to keep it unsolved for almost 3 years now, out of which the bug is known for almost 2 years.

[Ebotcazou (ebotcazou)]

I just posted a patch about it:
  http://gcc.gnu.org/ml/gcc-patches/2013-03/msg00939.html

[Jakub-gcc (jakub-gcc)]

GCC 4.6.4 has been released and the branch has been closed.

[Jules-z (jules-z)]

I've posted a new potential fix (and a new testcase which breaks on current mainline) here:

http://gcc.gnu.org/ml/gcc-patches/2013-06/msg01191.html

[Y-gribov (y-gribov)]

Can we accept Julian's patch for 4.9? This bug really hurts.

[Ebotcazou (ebotcazou)]

IMO this bug should be moved to P1 as a regression on a primary platform and the RMs should up the pressure on the maintainers to have it fixed.

[Jakub-gcc (jakub-gcc)]

IMHO a bug that is known for 2.5 years and unfixed shouldn't be all of sudden P1. That doesn't mean the maintainers should ignore the bug, just that it isn't a release blocker.

[Ebotcazou (ebotcazou)]

> IMHO a bug that is known for 2.5 years and unfixed shouldn't be all of
> sudden P1. That doesn't mean the maintainers should ignore the bug, just
> that it isn't a release blocker.

I'm afraid that history has shown that you won't achieve the former without doing the latter...

[Arnd Bergmann (arnd-arndb)]

$ arm-linux-gnueabihf-gcc-4.8 --version # this time the right one
arm-linux-gnueabihf-gcc-4.8 (Ubuntu/Linaro 4.8.1-10ubuntu7) 4.8.1
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Arnd Bergmann (arnd-arndb)]

Apparently fixed in gcc-4.9 (trunk)

[Charles Baylis (cbaylis)]

Reduced test case attached.

arm-unknown-linux-gnueabihf-gcc -marm -O2 -fno-strict-aliasing -fno-common -fno-omit-frame-pointer -c reduce.c

reduce.c:84:1: internal compiler error: in push_minipool_fix, at config/arm/arm.c:14059
 }
 ^
0x96b9cf push_minipool_fix
        /home/cbaylis/srcarea/gcc/gcc-linaro-4.8/gcc/config/arm/arm.c:14059
0x98fc2d note_invalid_constants
        /home/cbaylis/srcarea/gcc/gcc-linaro-4.8/gcc/config/arm/arm.c:14238
0x98fc2d arm_reorg
        /home/cbaylis/srcarea/gcc/gcc-linaro-4.8/gcc/config/arm/arm.c:14539
0x787699 rest_of_handle_machine_reorg
        /home/cbaylis/srcarea/gcc/gcc-linaro-4.8/gcc/reorg.c:3939

[Charles Baylis (cbaylis)]

Seems to be similar to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49423

[Charles Baylis (cbaylis)]

I have proposed a fix for this:

http://gcc.gnu.org/ml/gcc-patches/2014-04/msg00078.html

[Jules-z (jules-z)]

The testcase I previously had for this bug no longer reproduces since LRA was enabled by default on ARM. So, it's possible the bug is now dormant, or indeed fixed. The difference in the postreload dump around the insn which previously failed (136) is, using -mno-lra/-mlra on current trunk:

-(insn 136 7 12 2 (set (reg:SI 11 fp [orig:231 D.6590 ] [231])
- (zero_extend:SI (mem/u/c:QI (symbol_ref/u:SI ("*.LC0") [flags 0x2]) [0 S1 A8]))) ../../aes/aeskey.c:509 182 {*arm_zero_extendqisi2_v6}
+(insn 952 7 136 2 (set (reg:SI 12 ip [1488])
+ (const_int 0 [0])) ../../aes/aeskey.c:509 666 {*arm_movsi_vfp}
+ (nil))
+(insn 136 952 12 2 (set (reg:SI 11 fp [orig:231 D.6590 ] [231])
+ (zero_extend:SI (reg:QI 12 ip [1488]))) ../../aes/aeskey.c:509 182 {*arm_zero_extendqisi2_v6}

Or, does anyone know of a testcase which still causes this ICE with -mlra enabled? If not, we might be able to consider this fixed. (Insn 136 -- of the form which causes breakage -- was generated by reload.)

Thanks,

Julian

[Charles Baylis (cbaylis)]

I suspect this still remains as a latent bug.

The zero/sign extend patterns still allow a memory operand, and there remains a subset of memory operands which will trigger the ICE (ie those which refer to a constant pool).

I think we shouldn't consider it fixed unless there is a definitive reason to believe that LRA can never rematerialize a constant in this way.

[Gregory Fong (gvfong)]

"Apparently fixed in gcc-4.9 (trunk)"

According to [1] this may still be a latent issue but hidden on trunk because LRA is enabled by default on ARM now.

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49423#c26

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Gregory Fong (gvfong)]

Attaching another testcase that reproduces the issue (or at least a very similar one).

$ arm-linux-gnueabihf-gcc -marm -march=armv7-a -fsanitize=address -Os -w testcase.i
testcase.i: In function ‘fn1’:
testcase.i:24:1: internal compiler error: in push_minipool_fix, at config/arm/arm.c:14040
 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-4.8/README.Bugs> for instructions.
Preprocessed source stored into /tmp/cchbrz4F.out file, please attach this to your bugreport.

$ arm-linux-gnueabihf-gcc --version
arm-linux-gnueabihf-gcc (Ubuntu/Linaro 4.8.1-10ubuntu7) 4.8.1
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Rguenth (rguenth)]

The 4.7 branch is being closed, moving target milestone to 4.8.4.

[Cbaylis-u (cbaylis-u)]

Author: cbaylis
Date: Sat Jul 5 11:58:06 2014
New Revision: 212303

URL: https://gcc.gnu.org/viewcvs?rev=212303&root=gcc&view=rev
Log:
[ARM] PR target/49423

2014-07-05 Charles Baylis <email address hidden>

 PR target/49423
 * config/arm/arm-protos.h (arm_legitimate_address_p,
 arm_is_constant_pool_ref): Add prototypes.
 * config/arm/arm.c (arm_legitimate_address_p): Remove static.
 (arm_is_constant_pool_ref) New function.
 * config/arm/arm.md (unaligned_loadhis, arm_zero_extendhisi2_v6,
 arm_zero_extendqisi2_v6): Use Uh constraint for memory operand.
 (arm_extendhisi2, arm_extendhisi2_v6): Use Uh constraint for memory
 operand. Remove pool_range and neg_pool_range attributes.
 (arm_extendqihi_insn, arm_extendqisi, arm_extendqisi_v6): Remove
 pool_range and neg_pool_range attributes.
 * config/arm/constraints.md (Uh): New constraint.
 (Uq): Don't allow constant pool references.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/arm/arm-protos.h
    trunk/gcc/config/arm/arm.c
    trunk/gcc/config/arm/arm.md
    trunk/gcc/config/arm/constraints.md

[Ktkachov (ktkachov)]

This testcase now works on trunk 4.10.

Charles, can this be closed? or is there some backporting to be done?

[Cbaylis-u (cbaylis-u)]

I intend to backport to 4.8 and 4.9, once this change has had a week of testing on trunk.

[Charles Baylis (cbaylis)]

Fixed on trunk under PR49423. Now tracked to in Linaro bugzilla https://bugs.linaro.org/show_bug.cgi?id=598 to ensure that the backports to 4.8 and 4.9 are made.

[Gregory Fong (gvfong)]

(In reply to cbaylis from comment #31)
> I intend to backport to 4.8 and 4.9, once this change has had a week of
> testing on trunk.

Hi Charles, just a gentle reminder that you were planning this.

[Cbaylis-u (cbaylis-u)]

Author: cbaylis
Date: Mon Sep 29 16:47:31 2014
New Revision: 215685

URL: https://gcc.gnu.org/viewcvs?rev=215685&root=gcc&view=rev
Log:
2014-09-29 Charles Baylis <email address hidden>

        Backport from mainline r212303
        PR target/49423
        * config/arm/arm-protos.h (arm_legitimate_address_p,
        arm_is_constant_pool_ref): Add prototypes.
        * config/arm/arm.c (arm_legitimate_address_p): Remove static.
        (arm_is_constant_pool_ref) New function.
        * config/arm/arm.md (unaligned_loadhis, arm_zero_extendhisi2_v6,
        arm_zero_extendqisi2_v6): Use Uh constraint for memory operand.
        (arm_extendhisi2, arm_extendhisi2_v6): Use Uh constraint for memory
        operand and remove pool_range and neg_pool_range attributes.
        (arm_extendqihi_insn, arm_extendqisi, arm_extendqisi_v6): Remove
        pool_range and neg_pool_range attributes.
        * config/arm/constraints.md (Uh): New constraint. (Uq): Don't allow
        constant pool references.

Modified:
    branches/gcc-4_9-branch/gcc/ChangeLog
    branches/gcc-4_9-branch/gcc/config/arm/arm-protos.h
    branches/gcc-4_9-branch/gcc/config/arm/arm.c
    branches/gcc-4_9-branch/gcc/config/arm/arm.md
    branches/gcc-4_9-branch/gcc/config/arm/constraints.md

[Cbaylis-u (cbaylis-u)]

Author: cbaylis
Date: Mon Sep 29 17:07:47 2014
New Revision: 215686

URL: https://gcc.gnu.org/viewcvs?rev=215686&root=gcc&view=rev
Log:
2014-09-29 Charles Baylis <email address hidden>

        Backport from mainline r212303
        PR target/49423
        * config/arm/arm-protos.h (arm_legitimate_address_p,
        arm_is_constant_pool_ref): Add prototypes.
        * config/arm/arm.c (arm_legitimate_address_p): Remove static.
        (arm_is_constant_pool_ref) New function.
        * config/arm/arm.md (unaligned_loadhis, arm_zero_extendhisi2_v6,
        arm_zero_extendqisi2_v6): Use Uh constraint for memory operand.
        (arm_extendhisi2, arm_extendhisi2_v6): Use Uh constraint for memory
        operand and remove pool_range and neg_pool_range attributes.
        (arm_extendqihi_insn, arm_extendqisi, arm_extendqisi_v6): Remove
        pool_range and neg_pool_range attributes.
        * config/arm/constraints.md (Uh): New constraint. (Uq): Don't allow
        constant pool references.

Modified:
    branches/gcc-4_8-branch/gcc/ChangeLog
    branches/gcc-4_8-branch/gcc/config/arm/arm-protos.h
    branches/gcc-4_8-branch/gcc/config/arm/arm.c
    branches/gcc-4_8-branch/gcc/config/arm/arm.md
    branches/gcc-4_8-branch/gcc/config/arm/constraints.md

[Cbaylis-u (cbaylis-u)]

Backports committed to 4.8 and 4.9