http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247
--- Comment #20 from ccoutant at google dot com 2011-02-16 23:35:28 UTC ---
> I have created a "small" test of the symbol table problem. It is in
>
> http://people.mozilla.com/~respindola/test.tar.xz
>
> The test is f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57451
--- Comment #7 from ccoutant at google dot com ---
> Index: final.c
> ===
> --- final.c (revision 201461)
> +++ final.c (working copy)
> @@ -1560,6 +1560,16 @@ ch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57451
--- Comment #9 from ccoutant at google dot com ---
>>> + if (!active_insn_p (insn))
>>> +continue;
>>
>> I'm not clear on why this is needed. Is it because after the
>> change_scope, insn will
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #81 from ccoutant at google dot com 2012-04-17 18:52:11 UTC ---
>> As Paul noted, this is a moot point in practice for .ctors, since GCC emits
>> only a single .ctors entry per TU, but it could be significant for assembl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #83 from ccoutant at google dot com 2012-04-17 20:10:07 UTC ---
>> Didn't I just do that?
>
> Let me ask it again:
>
> The proposed --reverse-init-array switch will only reverse the order across
> translatio
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #86 from ccoutant at google dot com 2012-04-17 21:09:15 UTC ---
> I have seen codes like:
>
> void (*const init_array []) (void)
> __attribute__ ((section (".init_array"), aligned (sizeof (void * =
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #87 from ccoutant at google dot com 2012-04-17 21:52:12 UTC ---
> Just as a quick reminder, the reversed ctor execution order is big performance
> problem for C++ Apps inlcuding Mozilla and Chrome ;)
> So whatever we do
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55794
--- Comment #7 from ccoutant at google dot com ---
> but the change is no longer in the current 4.9 code.
Ah, right. See PR 54499 and this thread:
http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00706.html
-cary
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61013
--- Comment #10 from ccoutant at google dot com ---
>> So, my preference would be to revert to the 4.8 and older behavior, or if
>> there really is consensus that -g1 -g should mean -g2 rather than -g1, at
>> least change it so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61013
--- Comment #12 from ccoutant at google dot com ---
> FWIW this regresses a few gdb tests. It's easy to fix the
> gdb test suite, but if this is going to be fixed before the
> next gcc release, I'd rather not bother. Any
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63504
--- Comment #14 from ccoutant at google dot com ---
> But then there is (question mainly on Cary) the .debug_types checksumming:
>
> case dw_val_class_const_double:
> CHECKSUM_ULEB128 (DW_FORM_block);
> CHECKSUM_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46123
--- Comment #4 from ccoutant at google dot com 2010-11-19 02:17:27 UTC ---
> Ugh, this is very ugly. gen_subprogram_die sometimes decides to reuse old_die
> which was DW_AT_declaration and can be deeply nested in type children, which
&g
12 matches
Mail list logo
