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;
}

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?

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"?

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.

 
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)

On it

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.

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

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.

GCC 4.7.2 has been released.

Ping.

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

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.

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

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.

GCC 4.7.3 is being released, adjusting target milestone.

Unsetting target milestone of open non-regression bug from version of branch being closed.

Since the fix got installed in 2012 this really should have been fixed from 4.8.0 onwards. 

Should we really keep this still open or can we close this out ? 

Ramana

I think it's just  workaround that got installed in 2012, not a real fix.  Of course, 10 years later one could ask if the workaround has become the "real fix".

(In reply to Jeffrey A. Law from comment #19)
> I think it's just  workaround that got installed in 2012, not a real fix. 
> Of course, 10 years later one could ask if the workaround has become the
> "real fix".

That is of course a jolly good question :P 

Ramana