Bug 53135 - Duplicates cause size explosion (vta/dwarf)
Summary: Duplicates cause size explosion (vta/dwarf)
Status: ASSIGNED
Alias: None
Product: gcc
Classification: Unclassified
Component: debug (show other bugs)
Version: 4.7.1
: P2 normal
Target Milestone: ---
Assignee: Alexandre Oliva
URL:
Keywords: ice-on-valid-code
Depends on:
Blocks:
 
Reported: 2012-04-27 05:58 UTC by Khem Raj
Modified: 2014-06-12 13:52 UTC (History)
8 users (show)

See Also:
Host:
Target: arm-*-linux-gnueabi
Build:
Known to work: 4.2.4
Known to fail: 4.7.0, 4.7.1
Last reconfirmed:


Attachments
Patch that fixes (or works around?) the problem (313 bytes, patch)
2012-08-07 02:26 UTC, Alexandre Oliva
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Khem Raj 2012-04-27 05:58:50 UTC
gcc 4.7 latest from gcc-4_7-branch when configured for arm architecture gets this ICE

arm-bug.i:47:1: internal compiler error: in value_format, at dwarf2out.c:8010
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.


compiler cmdline is

arm-oe-linux-gnueabi-g++ arm-bug.i -g -S -O2

compiler configuration

Using built-in specs.
COLLECT_GCC=/home/kraj/work/openembedded-core/build/tmp-eglibc/sysroots/x86_64-linux/usr/bin/armv5te-oe-linux-gnueabi/arm-oe-linux-gnueabi-g++
COLLECT_LTO_WRAPPER=/home/kraj/work/openembedded-core/build/tmp-eglibc/sysroots/x86_64-linux/usr/libexec/armv5te-oe-linux-gnueabi/gcc/arm-oe-linux-gnueabi/4.7.1/lto-wrapper
Target: arm-oe-linux-gnueabi
Configured with: /home/kraj/work/openembedded-core/build/tmp-eglibc/work-shared/gcc-4.7.0+svnr186651-r0/gcc-4_7-branch/configure --build=x86_64-linux --host=x86_64-linux --target=arm-oe-linux-gnueabi --prefix=/home/kraj/work/openembedded-core/build/tmp-eglibc/sysroots/x86_64-linux/usr --exec_prefix=/home/kraj/work/openembedded-core/build/tmp-eglibc/sysroots/x86_64-linux/usr --bindir=/home/kraj/work/openembedded-core/build/tmp-eglibc/sysroots/x86_64-linux/usr/bin/armv5te-oe-linux-gnueabi --sbindir=/home/kraj/work/openembedded-core/build/tmp-eglibc/sysroots/x86_64-linux/usr/bin/armv5te-oe-linux-gnueabi --libexecdir=/home/kraj/work/openembedded-core/build/tmp-eglibc/sysroots/x86_64-linux/usr/libexec/armv5te-oe-linux-gnueabi --datadir=/home/kraj/work/openembedded-core/build/tmp-eglibc/sysroots/x86_64-linux/usr/share --sysconfdir=/home/kraj/work/openembedded-core/build/tmp-eglibc/sysroots/x86_64-linux/etc --sharedstatedir=/home/kraj/work/openembedded-core/build/tmp-eglibc/sysroots/x86_64-linux/com --localstatedir=/home/kraj/work/openembedded-core/build/tmp-eglibc/sysroots/x86_64-linux/var --libdir=/home/kraj/work/openembedded-core/build/tmp-eglibc/sysroots/x86_64-linux/usr/lib/armv5te-oe-linux-gnueabi --includedir=/home/kraj/work/openembedded-core/build/tmp-eglibc/sysroots/x86_64-linux/usr/include --oldincludedir=/home/kraj/work/openembedded-core/build/tmp-eglibc/sysroots/x86_64-linux/usr/include --infodir=/home/kraj/work/openembedded-core/build/tmp-eglibc/sysroots/x86_64-linux/usr/share/info --mandir=/home/kraj/work/openembedded-core/build/tmp-eglibc/sysroots/x86_64-linux/usr/share/man --disable-silent-rules --disable-dependency-tracking --with-libtool-sysroot=/home/kraj/work/openembedded-core/build/tmp-eglibc/sysroots/x86_64-linux --with-gnu-ld --enable-shared --enable-languages=c,c++ --enable-threads=posix --disable-multilib --enable-c99 --enable-long-long --enable-symvers=gnu --enable-libstdcxx-pch --program-prefix=arm-oe-linux-gnueabi- --without-local-prefix --enable-target-optspace --enable-lto --enable-libssp --disable-bootstrap --disable-libgomp --disable-libmudflap --with-system-zlib --with-linker-hash-style=gnu --with-ppl=no --with-cloog=no --enable-checking=release --enable-cheaders=c_global --with-float=soft --with-gxx-include-dir=/home/kraj/work/openembedded-core/build/tmp-eglibc/sysroots/qemuarm/usr/include/c++ --with-sysroot=/home/kraj/work/openembedded-core/build/tmp-eglibc/sysroots/qemuarm --with-build-sysroot=/home/kraj/work/openembedded-core/build/tmp-eglibc/sysroots/qemuarm --enable-poison-system-directories --disable-libunwind-exceptions --with-mpfr=/home/kraj/work/openembedded-core/build/tmp-eglibc/sysroots/x86_64-linux/usr --with-system-zlib --disable-nls
Thread model: posix
gcc version 4.7.1 20120421 (prerelease) (GCC)
Comment 1 Khem Raj 2012-04-27 05:59:56 UTC
testcase

class QAbstractFileEngine
{
public:
    enum FileFlag {

        ReadOwnerPerm = 0x4000, WriteOwnerPerm = 0x2000, ExeOwnerPerm = 0x1000,
        ReadUserPerm = 0x0400, WriteUserPerm = 0x0200, ExeUserPerm = 0x0100,
        ReadGroupPerm = 0x0040, WriteGroupPerm = 0x0020, ExeGroupPerm = 0x0010,
        ReadOtherPerm = 0x0004, WriteOtherPerm = 0x0002, ExeOtherPerm = 0x0001,

    };
    bool setPermissions(unsigned int perms);
};

extern const char* str;
extern bool foo(const char*, int);

bool QAbstractFileEngine::setPermissions(unsigned int perms)
{   
    bool ret = false;
    int mode = 0;
    if (perms & ReadOwnerPerm)
        mode |= 0400;
    if (perms & WriteOwnerPerm)
        mode |= 0200;
    if (perms & ExeOwnerPerm)
        mode |= 0100;
    if (perms & ReadUserPerm)
        mode |= 0400;
    if (perms & WriteUserPerm)
        mode |= 0200;
    if (perms & ExeUserPerm)
        mode |= 0100;
    if (perms & ReadGroupPerm)
        mode |= (0400 >> 3);
    if (perms & WriteGroupPerm)
        mode |= (0200 >> 3);
    if (perms & ExeGroupPerm)
        mode |= (0100 >> 3);
    if (perms & ReadOtherPerm)
        mode |= ((0400 >> 3) >> 3);
    if (perms & WriteOtherPerm)
        mode |= ((0200 >> 3) >> 3);
    if (perms & ExeOtherPerm)
        mode |= ((0100 >> 3) >> 3);
        ret = foo(str, mode) == 0;
    return ret;
}
Comment 2 Evgeniy Dushistov 2012-07-13 07:29:22 UTC
I think that it should be marked as regression.
Because of qt 4.6.3 give such error message with gcc 4.7.1,
but with gcc 4.2 all works fine.

Can anybody with suitable permissions mark this bug as regression?
Comment 3 Evgeniy Dushistov 2012-07-14 22:18:12 UTC
I searched commit which cause error.
Here is result of running test from this bugreport, with such command:
arm-none-eabi-g++ -O2 -g -c /tmp/test.cpp

good:
r182757 | paolo | 2011-12-31 21:29:30 +0400 (Сб., 31 дек. 2011) | 14 lines

the next one in the trunk

bad:
r182760 | aoliva | 2012-01-01 00:02:48 +0400 (Вс., 01 янв. 2012) | 26 lines

Can anybody add "aoliva" to "CC List"?
Comment 4 Mikael Pettersson 2012-07-15 18:35:32 UTC
The ICE still occurs with gcc 4.8 r189496 and 4.7 r189484, but with 4.8 it's now masked by default by Jakub's r186835, -g -gdwarf-3 is needed to trigger it.
Comment 5 Ramana Radhakrishnan 2012-07-24 13:03:00 UTC
 
on trunk with -O2 -g -gdwarf-3 I can reproduce the ICE . 



{dw_attr = DW_AT_GNU_call_site_value, dw_attr_val = {val_class = dw_val_class_loc, v = {val_addr = 0xb74576b4, val_offset = 12659530246790674100, val_loc_list = 0xb74576b4, val_loc = 0xb74576b4, val_int = -5787213826918877516, val_unsigned = 12659530246790674100, val_double = {low = 12659530246790674100, high = -5787213827046133841}, val_vec = {array = 0xb74576b4 "\350vE\267\n", length = 2947526575, elt_size = 2947526575}, val_die_ref = {die = 0xb74576b4, external = -1347440721}, val_fde_index = 3074782900, val_str = 0xb74576b4, val_lbl_id = 0xb74576b4 "\350vE\267\n", val_flag = 180 '\264', val_file = 0xb74576b4, val_data8 = "\264vE\267\257\257\257\257", val_decl_ref = 0xb74576b4, val_vms_delta = {lbl1 = 0xb74576b4 "\350vE\267\n", lbl2 = 0xafafafaf <Address 0xafafafaf out of bounds>}}}}

#0  internal_error (gmsgid=0x8e9bd35 "in %s, at %s:%d") at /home/ramrad01/cross-build/fsf/src/gcc-pr54051/gcc/diagnostic.c:955
#1  0x08c1c31f in fancy_abort (file=0x8cc24e8 "/home/ramrad01/cross-build/fsf/src/gcc-pr54051/gcc/dwarf2out.c", line=7467, function=0x8cc21e7 "value_format") at /home/ramrad01/cross-build/fsf/src/gcc-pr54051/gcc/diagnostic.c:1011
#2  0x0846054b in value_format (a=0xb7a329c0) at /home/ramrad01/cross-build/fsf/src/gcc-pr54051/gcc/dwarf2out.c:7467
#3  0x0847fdaf in output_value_format (filename=0xbffff4de "/tmp/tst.cc") at /home/ramrad01/cross-build/fsf/src/gcc-pr54051/gcc/dwarf2out.c:7572
#4  output_abbrev_section (filename=0xbffff4de "/tmp/tst.cc") at /home/ramrad01/cross-build/fsf/src/gcc-pr54051/gcc/dwarf2out.c:7605
#5  dwarf2out_finish (filename=0xbffff4de "/tmp/tst.cc") at /home/ramrad01/cross-build/fsf/src/gcc-pr54051/gcc/dwarf2out.c:22463
#6  0x08722b5a in compile_file () at /home/ramrad01/cross-build/fsf/src/gcc-pr54051/gcc/toplev.c:594
#7  0x08724934 in do_compile (argc=5, argv=0xbffff2f4) at /home/ramrad01/cross-build/fsf/src/gcc-pr54051/gcc/toplev.c:1863
#8  toplev_main (argc=5, argv=0xbffff2f4) at /home/ramrad01/cross-build/fsf/src/gcc-pr54051/gcc/toplev.c:1939
#9  0x08c0defb in main (argc=5, argv=0xbffff2f4) at /home/ramrad01/cross-build/fsf/src/gcc-pr54051/gcc/main.c:36
(gdb)
Comment 6 Alexandre Oliva 2012-08-07 01:54:12 UTC
On it
Comment 7 Alexandre Oliva 2012-08-07 02:26:55 UTC
Created attachment 27954 [details]
Patch that fixes (or works around?) the problem

We have a relatively large expression to represent the outgoing “mode” parameter, computed from “perms”, that requires more than 64KiB to represent.  block2 is not enough for that.  Jakub, is it intentional that we ICE in this case, or is this patch a reasonable change?  We successfully output the location expression; surely 64KiB+ expressions might be excessive, but I don't think an ICE is the most desirable way to deal with such large expressions if we build them in the first place.
Comment 8 Alexandre Oliva 2012-08-07 18:47:16 UTC
For those running into the problem, analternative to patching GCC isto reduce the maximum expression depth for var-traking with --param max-vartrack-expr-depth=11
Comment 9 Jakub Jelinek 2012-08-20 14:03:39 UTC
Alex, the patch is ok for trunk and 4.7 branch.  That said, with similar code just appearing not in call site parameter, but in a .debug_loc section we'd ICE anyway, as .debug_loc has a hard limit of 64K, and furthermore we should do a better job on this testcase, instead of creating such a huge expression which keeps recomputing the same values again and again introduce some kind of temporaries in the expression, if some expression occurs more than a few times, compute it into a temporary first (on the DWARF stack) and then just pick it when needed, drop at the end.
Comment 10 Jakub Jelinek 2012-09-20 10:12:46 UTC
GCC 4.7.2 has been released.
Comment 11 Andrew Pinski 2012-09-27 18:47:59 UTC
Ping.
Comment 12 Alexandre Oliva 2012-10-02 20:05:29 UTC
Author: aoliva
Date: Tue Oct  2 20:05:24 2012
New Revision: 192000

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192000
Log:
PR debug/53135
* dwarf2out.c (value_format): Use block4 for dw_val_class_loc
when needed.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/dwarf2out.c
Comment 13 Alexandre Oliva 2012-10-02 20:17:53 UTC
The work around is installed in the trunk, and will soon be in the branch as well, but this should ideally be left open until we figure out a better way to avoid all the duplication that triggers the size explosion.
Comment 14 Alexandre Oliva 2012-10-03 04:02:43 UTC
Author: aoliva
Date: Wed Oct  3 04:02:38 2012
New Revision: 192021

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192021
Log:
PR debug/53135
* dwarf2out.c (value_format): Use block4 for dw_val_class_loc
when needed.

Modified:
    branches/gcc-4_7-branch/gcc/ChangeLog
    branches/gcc-4_7-branch/gcc/dwarf2out.c
Comment 15 Jeffrey A. Law 2013-01-20 06:24:43 UTC
Removing regression marker as workaround is on trunk.  Leaving open so we don't lose track of this bug as we'd really like to do better.
Comment 16 Richard Biener 2013-04-11 07:58:37 UTC
GCC 4.7.3 is being released, adjusting target milestone.
Comment 17 Richard Biener 2014-06-12 13:52:23 UTC
Unsetting target milestone of open non-regression bug from version of branch being closed.