Ubuntu

internal compiler error: in decode_addr_const, at varasm.c:2632

Reported by Loïc Minier on 2011-08-17
30
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Linaro Android
Undecided
Bernhard Rosenkraenzer
Linaro GCC
Medium
Andrew Stubbs
4.6-2011.07-stable
Medium
Michael Hope
gcc
Fix Released
Medium
gcc-4.6-armel-cross (Ubuntu)
Undecided
Unassigned

Bug Description

Hi

Cross-building u-boot-linaro-stable 605c08e8b6f7b7e4b9d17b6cb367fb27ce1c511c with gcc-4.6-arm-linux-gnueabi 4.6.1-5ubuntu2cross1.53 which is:
gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-5ubuntu2)
and is based of 4.6-2011.07-0 triggers an ICE:
arm-linux-gnueabi-gcc -g -Os -fno-common -ffixed-r8 -msoft-float -D__KERNEL__ -DCONFIG_SYS_TEXT_BASE=0x80100000 -DCONFIG_SPL_TEXT_BASE=0x40304350 -I/home/lool/git/linaro/boot/u-boot-linaro-stable/obj-omap4_panda/include2 -I/home/lool/git/linaro/boot/u-boot-linaro-stable/obj-omap4_panda/include -I/home/lool/git/linaro/boot/u-boot-linaro-stable/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/lib/gcc/arm-linux-gnueabi/4.6.1/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mabi=aapcs-linux -mno-thumb-interwork -march=armv5 -Wall -Wstrict-prototypes -fno-stack-protector -Wno-format-nonliteral -Wno-format-security -o /home/lool/git/linaro/boot/u-boot-linaro-stable/obj-omap4_panda/arch/arm/cpu/armv7/omap4/clocks.o clocks.c -c
clocks.c: In function ‘enable_basic_clocks’:
clocks.c:657:13: internal compiler error: in decode_addr_const, at varasm.c:2632
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-4.6/README.Bugs> for instructions.

I'm attaching the .i and partial .s files resulting from -save-temps as well as the .c for the sake of completeness.

This does not occur with the 4.5 cross-compiler which is:
gcc version 4.5.3 (Ubuntu/Linaro 4.5.3-3ubuntu1)
and is based of 4.5-2011.05-0 + changes taken on 20110704.

Cheers,

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: gcc-4.6-arm-linux-gnueabi 4.6.1-5ubuntu2cross1.53
ProcVersionSignature: Ubuntu 3.0.0-8.11-generic 3.0.1
Uname: Linux 3.0.0-8-generic x86_64
Architecture: amd64
Date: Wed Aug 17 14:07:37 2011
ProcEnviron:
 LANGUAGE=fr_FR:fr:en_GB:en
 PATH=(custom, user)
 LANG=fr_FR.UTF-8
 SHELL=/bin/zsh
SourcePackage: gcc-4.6-armel-cross
UpgradeStatus: Upgraded to oneiric on 2009-12-07 (617 days ago)

Loïc Minier (lool) wrote :
Loïc Minier (lool) wrote :
Loïc Minier (lool) wrote :
Loïc Minier (lool) wrote :

Would someone be so kind to verify whether this affects plain (non-Ubuntuified) cross Linaro GCC 4.6, perhaps with 2011.08?

Michael Hope (michaelh1) wrote :

Thank you for the bug report. I've confirmed this with gcc-linaro-4.6-2011.08 on ARM:

michaelh@ursa1:~/linaro/bugs$ /tools/toolchains/arch/armv7l/gcc-linaro-4.6-2011.08-armv7l-natty-cbuild162-ursa1-cortexa9r1/bin/gcc -Os -fno-builtin clocks.i
clocks.c: In function 'enable_basic_clocks':
clocks.c:657:13: internal compiler error: in decode_addr_const, at varasm.c:2632

Note the use of -fno-builtin to suppress a warning.

The fault occurs at -Os, -O1, -O2, and -O3. The work-around is to compile at -O0. The fault also exists in gcc-linaro-4.6-2011.06-0, gcc-linaro-4.6-2011.07-0, and gcc-4.6.1. It does not exist in gcc-4.5.3. Could you please also report this in GCC bugzilla and attach it to this ticket?

I've set it to medium priority as it is a ftbfs, the fault exists upstream, and a work-around exists.

Michael Hope (michaelh1) wrote :
Changed in gcc-linaro:
status: New → Triaged
importance: Undecided → Medium

Hi

This was initially reported at https://bugs.launchpad.net/ubuntu/+source/gcc-4.6-armel-cross/+bug/827990 and Michael Hope produced a reduced testcase which is confirmed to affect GCC 4.6.1.

arm-linux-gnueabi-gcc -g -Os -fno-common -ffixed-r8 -msoft-float -D__KERNEL__ -DCONFIG_SYS_TEXT_BASE=0x80100000 -DCONFIG_SPL_TEXT_BASE=0x40304350 -I/home/lool/git/linaro/boot/u-boot-linaro-stable/obj-omap4_panda/include2 -I/home/lool/git/linaro/boot/u-boot-linaro-stable/obj-omap4_panda/include -I/home/lool/git/linaro/boot/u-boot-linaro-stable/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/lib/gcc/arm-linux-gnueabi/4.6.1/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mabi=aapcs-linux -mno-thumb-interwork -march=armv5 -Wall -Wstrict-prototypes -fno-stack-protector -Wno-format-nonliteral -Wno-format-security -o /home/lool/git/linaro/boot/u-boot-linaro-stable/obj-omap4_panda/arch/arm/cpu/armv7/omap4/clocks.o clocks.c -c
clocks.c: In function ‘enable_basic_clocks’:
clocks.c:657:13: internal compiler error: in decode_addr_const, at varasm.c:2632
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-4.6/README.Bugs> for instructions.

Michael Hope also notes:
"Note the use of -fno-builtin to suppress a warning.

The fault occurs at -Os, -O1, -O2, and -O3. The work-around is to compile at -O0."

(I'm attaching his reduced test case, the original files are in the Launchpad bug in the unlikely case you'd need them)

Bye,

Loïc Minier (lool) wrote :
Changed in gcc:
importance: Unknown → Medium
status: Unknown → New
In , Rguenth (rguenth) wrote :

Mine.

Author: rguenth
Date: Mon Aug 29 08:03:34 2011
New Revision: 178155

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178155
Log:
2011-08-29 Richard Guenther <email address hidden>

        PR middle-end/50116
 * varasm.c (decode_addr_const): Handle MEM_REF[&X, OFF].

Modified:
    branches/gcc-4_6-branch/gcc/ChangeLog
    branches/gcc-4_6-branch/gcc/varasm.c

Should be fixed now.

Changed in gcc:
status: New → Fix Released
Michael Hope (michaelh1) on 2011-08-29
Changed in gcc-linaro:
milestone: none → 4.6-2011.09
Michael Hope (michaelh1) wrote :

Assigned to Andrew as it'll get picked up in the next 4.6 release merge.

Changed in gcc-linaro:
status: Triaged → In Progress
assignee: nobody → Andrew Stubbs (ams-codesourcery)

Created attachment 25164
Preprocessed source

Compiling u-boot with gcc 4.6.1 with the fix from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50116
applied results in

clocks.c: In function 'enable_basic_clocks':
clocks.c:657:13: internal compiler error: in decode_addr_const, at varasm.c:2638

(this is the same error as 50116, except the ICE moved by the 6 lines that were inserted in the patch for 50116. I don't have permissions to reopen 50116.)

Attaching preprocessed source.

Created attachment 25165
Reduced test case

Reduced test case:

struct a {
 unsigned int a;
 unsigned int b;
};

struct a *const p = (struct a *)0x4A004100;

void bug50116(void)
{
 unsigned int i = 0;
 unsigned int *const x[] = {
  &p->a,
  &p->b,
  0
 };

 (*(volatile unsigned int *)((x[i])) = (unsigned int)((unsigned int)((*(volatile unsigned int *)(x[i])))));
}

The fix doesn't work.
New upstream bug with better test case filed at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50266

Changed in gcc-4.6-armel-cross (Ubuntu):
status: New → Confirmed
Download full text (3.3 KiB)

Confirmed on x86_64-linux with -Os on 4.6 and trunk.

(gdb) call debug_tree (exp)
 <addr_expr 0x2aaaaceb3fc0
    type <pointer_type 0x2aaaaab5d150
        type <integer_type 0x2aaaaab47540 unsigned int sizes-gimplified public unsigned SI
            size <integer_cst 0x2aaaaab35988 constant 32>
            unit size <integer_cst 0x2aaaaab35690 constant 4>
            align 32 symtab 0 alias set -1 canonical type 0x2aaaaab47540 precision 32 min <integer_cst 0x2aaaaab359b0 0> max <integer_cst 0x2aaaaab35960 4294967295>
            pointer_to_this <pointer_type 0x2aaaaab5d150>>
        sizes-gimplified public unsigned DI
        size <integer_cst 0x2aaaaab35a50 constant 64>
        unit size <integer_cst 0x2aaaaab35a78 constant 8>
        align 64 symtab 0 alias set -1 canonical type 0x2aaaaab5d150
        pointer_to_this <pointer_type 0x2aaaace99738>>
    constant
    arg 0 <component_ref 0x2aaaaceb7040 type <integer_type 0x2aaaaab47540 unsigned int>

        arg 0 <indirect_ref 0x2aaaaceb3f90 type <record_type 0x2aaaace993f0 a>

            arg 0 <integer_cst 0x2aaaace94938 constant 1241530624>
            t.i:12:9>
        arg 1 <field_decl 0x2aaaaab42720 a type <integer_type 0x2aaaaab47540 unsigned int>
            unsigned SI file t.i line 2 col 18 size <integer_cst 0x2aaaaab35988 32> unit size <integer_cst 0x2aaaaab35690 4>
            align 32 offset_align 128
            offset <integer_cst 0x2aaaaab356b8 constant 0>
            bit offset <integer_cst 0x2aaaaab35dc0 constant 0> context <record_type 0x2aaaace993f0 a> chain <field_decl 0x2aaaaab427b8 b>>
        t.i:12:9>
    t.i:12:7>

There is an INDIRECT_REF in the expression, that shouldn't happen. It is
from a CTOR that looks like

(gdb) call debug_generic_expr (ctor)
{&1241530624B->a, &1241530624B->b, 0B}

and we have a CTOR and not individual initializations because of Erics
const-pool changes I believe. &p->a is folded to &1241530624B->a even
before gimplification (but &1241530624B->a is "unfolded" - it's an
obfuscated constant).

We ICE from

#0 fancy_abort (
    file=0x1252a70 "/space/rguenther/src/svn/gcc-4_6-branch/gcc/varasm.c",
    line=2638, function=0x1253700 "decode_addr_const")
    at /space/rguenther/src/svn/gcc-4_6-branch/gcc/diagnostic.c:893
#1 0x0000000000ca9016 in decode_addr_const (exp=0x2aaaaceb3fc0,
    value=0x7fffffff9b30)
    at /space/rguenther/src/svn/gcc-4_6-branch/gcc/varasm.c:2638
#2 0x0000000000ca97f0 in const_hash_1 (exp=0x2aaaaceb3fc0)
    at /space/rguenther/src/svn/gcc-4_6-branch/gcc/varasm.c:2734
#3 0x0000000000ca95db in const_hash_1 (exp=0x2aaaacea54e0)
    at /space/rguenther/src/svn/gcc-4_6-branch/gcc/varasm.c:2724
#4 0x0000000000cace7a in tree_output_constant_def (exp=0x2aaaacea54e0)
    at /space/rguenther/src/svn/gcc-4_6-branch/gcc/varasm.c:3302
#5 0x000000000083a5f4 in gimplify_init_constructor (expr_p=0x7fffffffb3a8,
    pre_p=0x7fffffffccf8, post_p=0x7fffffffa928, want_value=0 '\000',
    notify_temp_creation=0 '\000')
    at /space/rguenther/src/svn/gcc-4_6-branch/gcc/gimplify.c:3833

and fold &p->a via c_fully_fold_internal.

Either the ADDR_EXPR case handling of this function or the COMPONENT_REF
case should...

Read more...

Changed in gcc:
importance: Medium → Unknown
status: Fix Released → Unknown
Changed in linaro-android:
status: New → Confirmed
assignee: nobody → Bernhard Rosenkraenzer (berolinux)

I don't think there's any particular reason this initializer should need
to be folded in a particular way by the front end; I'd think the front
end's job is to produce a valid GENERIC initializer, whether or not
folded, with folding to something visibly constant only required if the
object initialized is of static storage duration. If you make x static
then it builds OK (although it's not required to) but in C99 an aggregate
initializer of automatic storage duration can have non-constant elements
even if the type of the aggregate is a const-qualified type (that is, x is
initialized once and constant after that). In fact you get the same ICE
when x isn't marked const at all. (And in general the middle-end ought to
be prepared to see aggregate initializers that become constant after
constant propagation but aren't known by the front end to be constant.)

Looking into it.

> and we have a CTOR and not individual initializations because of Erics
> const-pool changes I believe.

No, we have the constructor with GCC 4.5 as well, my patch only makes it go through tree_output_constant_def.

> &p->a is folded to &1241530624B->a even before gimplification (but
> &1241530624B->a is "unfolded" - it's an obfuscated constant).
>
> We ICE from
>
> #0 fancy_abort (
> file=0x1252a70 "/space/rguenther/src/svn/gcc-4_6-branch/gcc/varasm.c",
> line=2638, function=0x1253700 "decode_addr_const")
> at /space/rguenther/src/svn/gcc-4_6-branch/gcc/diagnostic.c:893
> #1 0x0000000000ca9016 in decode_addr_const (exp=0x2aaaaceb3fc0,
> value=0x7fffffff9b30)
> at /space/rguenther/src/svn/gcc-4_6-branch/gcc/varasm.c:2638
> #2 0x0000000000ca97f0 in const_hash_1 (exp=0x2aaaaceb3fc0)
> at /space/rguenther/src/svn/gcc-4_6-branch/gcc/varasm.c:2734
> #3 0x0000000000ca95db in const_hash_1 (exp=0x2aaaacea54e0)
> at /space/rguenther/src/svn/gcc-4_6-branch/gcc/varasm.c:2724
> #4 0x0000000000cace7a in tree_output_constant_def (exp=0x2aaaacea54e0)
> at /space/rguenther/src/svn/gcc-4_6-branch/gcc/varasm.c:3302
> #5 0x000000000083a5f4 in gimplify_init_constructor (expr_p=0x7fffffffb3a8,
> pre_p=0x7fffffffccf8, post_p=0x7fffffffa928, want_value=0 '\000',
> notify_temp_creation=0 '\000')
> at /space/rguenther/src/svn/gcc-4_6-branch/gcc/gimplify.c:3833
>
> and fold &p->a via c_fully_fold_internal.

This is a known issue, namely that tree_output_constant_def rejects offsetof computations. See PR middle-end/44100 for an example with the C++ compiler.

I think this should be folded in the front-end - c_fully_fold is kind of a misnomer if it can only partially fold &p->a. It's just a matter of copying
the chunk of code present in build_unary_op, no big deal IMO.

And this compiles fine in C++ because the folding is done:

Starting program: /home/eric/build/gcc/native/gcc/cc1plus -quiet pr50266.c -quiet -mtune=generic -march=x86-64 -Os

Breakpoint 1, tree_output_constant_def (exp=0x7ffff6edbdf8)
    at /home/eric/svn/gcc/gcc/varasm.c:3295
3295 key.value = exp;
(gdb) p debug_generic_expr(exp)
{1241530624B, 1241530628B, 0B}

Changed in gcc:
importance: Unknown → Medium
status: Unknown → In Progress

Author: ebotcazou
Date: Tue Sep 6 21:17:46 2011
New Revision: 178611

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178611
Log:
 PR middle-end/50266
 * c-common.c (c_fully_fold_internal) <ADDR_EXPR>: Fold offsetof-like
 computations.

Added:
    trunk/gcc/testsuite/gcc.c-torture/compile/20110906-1.c
Modified:
    trunk/gcc/c-family/ChangeLog
    trunk/gcc/c-family/c-common.c
    trunk/gcc/testsuite/ChangeLog

Author: ebotcazou
Date: Tue Sep 6 21:23:53 2011
New Revision: 178613

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178613
Log:
 PR middle-end/50266
 * c-common.c (c_fully_fold_internal) <ADDR_EXPR>: Fold offsetof-like
 computations.

Added:
    branches/gcc-4_6-branch/gcc/testsuite/gcc.c-torture/compile/20110906-1.c
      - copied unchanged from r178611, trunk/gcc/testsuite/gcc.c-torture/compile/20110906-1.c
Modified:
    branches/gcc-4_6-branch/gcc/c-family/ChangeLog
    branches/gcc-4_6-branch/gcc/c-family/c-common.c
    branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

This should compile again.

Michael Hope (michaelh1) wrote :

In progress upstream.

Changed in gcc-linaro:
milestone: 4.6-2011.09 → none
status: In Progress → Triaged
assignee: Andrew Stubbs (ams-codesourcery) → nobody
Changed in gcc:
status: In Progress → Fix Released
Michael Hope (michaelh1) wrote :

Approved and committed upstream. It's late in our release so we should confirm the fix first then consider the merge.

Michael Hope (michaelh1) wrote :

This fault is cleared with upstream 4.6 r178656.

Changed in gcc-linaro:
assignee: nobody → Andrew Stubbs (ams-codesourcery)
milestone: none → 4.6-2011.09
status: Triaged → In Progress

Fix confirmed on linaro-android side.

Will the fix get into 11.09? On the Android side, we're already injecting the fix through the GCC_PATCH_URL mechanism, but of course it would be nice to have it in "normal" 11.09

Michael Hope (michaelh1) wrote :

Yip, the change will come down as part of the linked release branch merge.

Michael Hope (michaelh1) wrote :

Confirmed that the fix clears the problem seen in bug50116.c

Changed in gcc-linaro:
status: In Progress → Fix Committed
Changed in linaro-android:
status: Confirmed → Fix Released
Michael Hope (michaelh1) on 2011-09-16
Changed in gcc-linaro:
status: Fix Committed → Fix Released
Marcin Juszkiewicz (hrw) wrote :

Can you try with current cross toolchain? 4.2.6-7 numbered (precise)

Chris Lalancette (clalancette) wrote :

I'm running into this same problem while trying to compile u-boot on Ubuntu 11.10. Is there an update planned for Ubuntu 11.10 to fix this issue?

Nicolas Dechesne (ndec) wrote :

@hrw: any update on this? are you planning to fix this in oneiric?

Marcin Juszkiewicz (hrw) wrote :

"arm-linux-gnueabi-gcc-4.6 clocks-reduced.i -c -o c.o -Os -fno-builtin" compiles fine on precise and under oneiric with cross-toolchain from Linaro toolchain backport PPA.

Changed in gcc-4.6-armel-cross (Ubuntu):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.