On 07/18/2012 05:44 PM, Sterling Augustine wrote:
+/* Remove an entry from the addr table. Since we have already numbered
+ all the entries, the best we can do here is null it out. */
This sounds like a design flaw. Since we have everything in memory,
there's no reason we shouldn't be abl
>> +/* Remove an entry from the addr table. Since we have already numbered
>> + all the entries, the best we can do here is null it out. */
>
> This sounds like a design flaw. Since we have everything in memory, there's
> no reason we shouldn't be able to pack the table appropriately. Why can
On Wed, Jul 25, 2012 at 4:00 PM, Cary Coutant wrote:
>>> +/* Remove an entry from the addr table. Since we have already numbered
>>> + all the entries, the best we can do here is null it out. */
>>
>> This sounds like a design flaw. Since we have everything in memory, there's
>> no reason we
+ if (dwarf_version >= 4 || dwarf_split_debug_info)
>>>
>>> Shouldn't -gsplit-debug require -gdwarf-4+ anyway?
>>
>> Seems better to check explicitly than to rely on an implied relationship.
>
> I think Jason is right here. Although they are theoretically separate,
> there has been no tes
On 07/25/2012 07:54 PM, Sterling Augustine wrote:
On Wed, Jul 25, 2012 at 4:00 PM, Cary Coutant wrote:
Perhaps instead of having a val_index field in each attribute you should
have the attribute point to something like an indirect_string_node for
addresses as well.
The potential savings here
>>> The potential savings here didn't seem worth the effort of adding a
>>> pass over another table to assign slots in .debug_addr. In practice,
>>> we're seeing very few slots zeroed out here.
>
> And how many duplicate entries? What strategy does Cary's patch use to
> avoid those?
I picked a co
On 10/10/2012 08:41 PM, Cary Coutant wrote:
I'm working on a follow-up patch to eliminate the duplicate references
to ".LVL" symbols by keeping a direct-lookup table in
dwarf2out_var_location. That will eliminate 310,266 of the 312,061
duplicates (99.4%) without using a hash table. With that patc
Hi Jason,
Just wanted to be sure you saw this. I'm hoping to get it in for stage 1.
http://gcc.gnu.org/ml/gcc-patches/2012-10/msg02684.html
Sterling
> +/* %:replace-extension spec function. Replaces the extension of the
> + first argument with the second argument. */
> +
> +const char *
> +replace_extension_spec_func (int argc, const char **argv)
> +{
> + char *name;
> + char *p;
> + char *result;
> +
> + if (argc != 2)
> +fatal_err
On Mon, Nov 5, 2012 at 3:18 PM, Cary Coutant wrote:
>> +/* %:replace-extension spec function. Replaces the extension of the
>> + first argument with the second argument. */
>> +
>> +const char *
>> +replace_extension_spec_func (int argc, const char **argv)
>> +{
>> + char *name;
>> + char *p
> Committed as attached. Thanks everyone.
This (r193267) breaks bootstrap on x86_64-apple-darwin10:
...
g++ -c -g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables
-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute
-pedantic -Wno-long-long -Wno-vari
On Tue, Nov 6, 2012 at 4:29 PM, Dominique Dhumieres wrote:
>> Committed as attached. Thanks everyone.
>
> This (r193267) breaks bootstrap on x86_64-apple-darwin10:
>
> ...
> g++ -c -g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables
> -W -Wall -Wno-narrowing -Wwrite-strings -Wc
> I'm testing the enclosed patch on my end. Does it happen to work for you?
I am now past the previous error. Full answer tomorrow morning.
Thanks
Dominique
On Tue, Nov 6, 2012 at 5:02 PM, Dominique Dhumieres wrote:
>> I'm testing the enclosed patch on my end. Does it happen to work for you?
>
> I am now past the previous error. Full answer tomorrow morning.
>
> Thanks
>
> Dominique
I have committed the above fix as obvious. If there is additional
br
14 matches
Mail list logo
