Rafael Espindola | 1 Oct 2009 01:14
Picon
Favicon

[lto][patch] Don't compress the IL symbol table

The plugin doesn't expect the symbol table to be compressed. This
patch disables compression for the section used to store the IL symbol
table. It would also be possible to change the plugin so that it could
read compressed symbol tables, but it is probably better to keep it
simpler.

The compiler itself doesn't read the symbol table.

2009-09-30  Rafael Avila de Espindola  <espindola <at> google.com>

	* lto-opts.c (lto_write_options): Update call to lto_begin_section.
	* lto-section-out.c (lto_begin_section): Add a compress argument.
Update all callers.
	(produce_symtab): Don't compress.
	* lto-section-out.h (lto_begin_section): Add a compress argument.

Cheers,
--

-- 
Rafael Ávila de Espíndola
Attachment (compress.patch): text/x-diff, 3674 bytes
Paolo Carlini | 1 Oct 2009 01:19
Picon
Favicon

Re: [libstdc++] decimal float support (take 2)

.. also, if I'm not mistaken, all the names of function parameters  
are not uglified...

Paolo

Rafael Espindola | 1 Oct 2009 02:09
Picon
Favicon

[lto][patch] Add support for passing more than just libgcc to the linker

As noted by Joseph and Ian, in some cases we have to ask the linker to
rescan more than just libgcc. This patch replaces the -libgcc option
with a -pass-through option. The new option can be used many times.
The reason for doing this is that in gcc.c it is easier to generate

-plugin-opt=-pass-through=foo -plugin-opt=-pass-through=bar

than to generate

-plugin-opt=-pass-through=foo:bar

The patch contains the infrastructure only. I still have to update
gcc.c to pass libc when needed (next patch).

Cheers,
--

-- 
Rafael Ávila de Espíndola
Attachment (pass-through.patch): text/x-diff, 2105 bytes
Rafael Espindola | 1 Oct 2009 02:20
Picon
Favicon

[lto][plugin] How to find libc?

Ian noted that when linking libc statically into a program and using
the gold plugin, we have to ask gold to rescan libc. The problem is,
gcc normally doesn't know which libc is being used. It will just pass
-lc to the linker and the linker searches for it.

On way to fix this is to implement the same algorithms used in the
linker in gcc.

Another way is to add a new callback into gold: add_input_library. It
would be similar to add_input_file, but the linker would search for
library. With this callback we would be able to do

-pass-through=libgcc.a -pass-through=-lc

Opinions? Suggestions?

Thanks,
--

-- 
Rafael Ávila de Espíndola

Joseph S. Myers | 1 Oct 2009 02:30

Re: [LTO merge][13/15] Add LTO front end

On Wed, 30 Sep 2009, Diego Novillo wrote:

> >> >> > mmap and <sys/mman.h> are also not portable to all supported hosts (e.g.
> >> >> > MinGW).  There should be configure tests and a suitable fallback.
> >> >>
> >> >> Added to PR41526.
> >> >
> >> > Likewise.
> >>
> >> Same question.  What primary/secondary targets are broken?
> >
> > i686-mingw32 host, any ELF target (supposing that libelf is installed, so
> > that LTO would get enabled by default).
> 
> Likewise here.

I should point out that a non-mmap fallback (open+read+close) should be 
easy to test without access to a host that doesn't have mmap.  And the 
configure test, setting HAVE_MMAP_FILE, is already present in 
gcc/acinclude.m4; I think you can assume that HAVE_MMAP_FILE will be the 
right conditional to determine if you can include the header and use the 
function.

--

-- 
Joseph S. Myers
joseph <at> codesourcery.com
Ian Lance Taylor | 1 Oct 2009 02:48
Picon
Favicon
Gravatar

Re: [lto][plugin] How to find libc?

Rafael Espindola <espindola <at> google.com> writes:

> Ian noted that when linking libc statically into a program and using
> the gold plugin, we have to ask gold to rescan libc. The problem is,
> gcc normally doesn't know which libc is being used. It will just pass
> -lc to the linker and the linker searches for it.
>
> On way to fix this is to implement the same algorithms used in the
> linker in gcc.

Please, no.

> Another way is to add a new callback into gold: add_input_library. It
> would be similar to add_input_file, but the linker would search for
> library. With this callback we would be able to do
>
> -pass-through=libgcc.a -pass-through=-lc

This seems reasonable, or add an extra option to add_input_file.
Within gold, add_input_file should do exactly the right thing if you
set the name to "c" and change the second argument to the
Input_file_argument constructor to true.

Ian

Jerry DeLisle | 1 Oct 2009 02:54
Picon

Re: [patch, fortran] Improve bounds checking error messages

On 09/30/2009 02:04 PM, Dennis Wassel wrote:
> PING?
> (I will be on holiday till 16th from tomorrow - please don't expect
> any answers in case there are any objections)
>
> Thanks,
> Dennis
>
I will commit after a fresh build and regression test.

Jerry

Cary Coutant | 1 Oct 2009 03:55
Picon
Favicon

Re: [patch] Merge dwarf4 branch

>>  <at>  <at>  -7825,6 +7980,9  <at>  <at>  attr_checksum (dw_attr_ref at, struct md
>>       CHECKSUM_STRING (AT_file (at)->filename);
>>       break;
>>
>> +    case dw_val_class_data8:
>> +      break;
>> +
>
> This doesn't get checksummed?

I guess I was being somewhat lazy here -- class_data8 will only occur
with DW_AT_signature, which will never appear when
-feliminate_dwarf2_dups is active (which is the only case where this
function will be called). I added the case here just for completeness,
but left it empty knowing it wouldn't be needed. I'll add a comment
here to that effect unless you think I should just go ahead and
checksum it.

>> +      for (i = 0; i < DWARF_TYPE_SIGNATURE_SIZE; i++)
>> +        fprintf (outfile, "%02x", sig[i] & 0xff);
>> +      fprintf (outfile, "\n");
>
> Type signature formatting happens often enough that it could use a separate
> function.  Or even multiple functions grouped together if necessary.

OK, will do.

>> +      if (attrs.at_type != NULL
>> +          && AT_class (attrs.at_type) == dw_val_class_die_ref)
>> +        {
(Continue reading)

Steve Kargl | 1 Oct 2009 04:22
Picon

Re: [patch, fortran] Improve bounds checking error messages

On Wed, Sep 30, 2009 at 05:54:41PM -0700, Jerry DeLisle wrote:
> On 09/30/2009 02:04 PM, Dennis Wassel wrote:
> >PING?
> >(I will be on holiday till 16th from tomorrow - please don't expect
> >any answers in case there are any objections)
> >
> >Thanks,
> >Dennis
> >
> I will commit after a fresh build and regression test.
> 

Jerry, 

Are you satisfied with the error message text?  Dennis
seemed alittle apprehensive about the use of "below" and
"above" in describing the out-of-bounds index with 
respect the lower and upper bounds.

--

-- 
Steve

Jason Merrill | 1 Oct 2009 04:37
Picon
Favicon

Re: [patch] Merge dwarf4 branch

On 09/30/2009 09:55 PM, Cary Coutant wrote:
>>>  <at>  <at>  -7825,6 +7980,9  <at>  <at>  attr_checksum (dw_attr_ref at, struct md
>>>        CHECKSUM_STRING (AT_file (at)->filename);
>>>        break;
>>>
>>> +    case dw_val_class_data8:
>>> +      break;
>>> +
>>
>> This doesn't get checksummed?
>
> I guess I was being somewhat lazy here -- class_data8 will only occur
> with DW_AT_signature, which will never appear when
> -feliminate_dwarf2_dups is active (which is the only case where this
> function will be called). I added the case here just for completeness,
> but left it empty knowing it wouldn't be needed. I'll add a comment
> here to that effect unless you think I should just go ahead and
> checksum it.

If you think this case is unreachable, use gcc_unreachable() with a 
comment.  Or just checksum it, whichever you prefer.

> That is, we only
> do this "shallow" hash of the name only for pointer and reference
> types (and friend entries).

Why just those?  Why not just hash the name and context whenever you see 
a reference to a class type?  I think you can also get a reference to an 
incomplete class if another class declares a member function with a 
parameter of that type, but that function isn't defined or called in the 
(Continue reading)


Gmane