Re: LTO symtab sections vs. missing symbols (libcalls maybe?) and lto-plugin vs. COFF

2010-10-15 Thread Dave Korn 
On 14/10/2010 17:12, Dave Korn wrote:
> On 14/10/2010 16:24, Richard Guenther wrote:
>> On Thu, Oct 14, 2010 at 5:28 PM, Dave Korn  
>> wrote:

>>> I *think* that re-adding the stdlibs after all
>>> the new input files in the plugin might work, but haven't tried it yet.

  It does do the job, and I see there's already a spec to pass through -lc
when static linking.  The right solution looks to me like extending the
%{fuse-linker-plugin:} spec on COFF platforms in a way that adds pass-through
options for all the standard libs in LIB_SPEC, and I'll develop a patch along
those lines if you can't see any objection.

cheers,
  DaveK

Re: LTO symtab sections vs. missing symbols (libcalls maybe?) and lto-plugin vs. COFF

2010-10-15 Thread Dave Korn 
On 14/10/2010 19:11, Ian Lance Taylor wrote:
> Dave Korn writes:
> 
>>   The consequence of this is that either there are going to be undefined
>> symbols in the final executable, or the linker has to perform another round 
>> of
>> library scanning.  It occurred to me that the semantics of this might even 
>> not
>> have been decided yet, since ELF platforms are perfectly happy with undefined
>> symbols at final link time.
> 
> Only when linking dynamically, though.  This suggests that your test
> case should fail on ELF when linking with -static.  If not, why not?
> 
> Ian

  My testcase was pretty much just hello world, and the reason it wouldn't
fail on ELF with -static is because:

> %{fuse-linker-plugin: \
> -plugin %(linker_plugin_file) \
> -plugin-opt=%(lto_wrapper) \
> -plugin-opt=-fresolution=%u.res \
> %{static|static-libgcc:-plugin-opt=-pass-through=%(lto_libgcc)}   \
> %{static:-plugin-opt=-pass-through=-lc}   \
> } \

... -lc gets added back in right at the very end of the link, thanks to that
pass-through option.

  What I'm planning on COFF is to figure a way to add further pass-through
options for all the -l options and .a files in LIB_SPEC.

cheers,
  DaveK

rehearsal of GCC Summit tutorial "Easily coding a GCC extension with MELT" (at IRILL, Paris, France oct.20th 2010)

2010-10-15 Thread Basile Starynkevitch 


Hello All,

[posted to GCC mailing list & to gcc-melt-fre...@googlegroups.com & to
various persons]

I am giving a tutorial at the GCC Summit in Ottawa about "Easily coding
a GCC extension with MELT" on october 26th 2010 (if
http://gccsummit.org/ http://www.gccsummit.org/2010/schedule.php is
correct).

Since I am not a good English speaker, I am making a rehearsal of this
tutorial in Paris (France) at Irill.org. Any person willing to attend
IRILL is welcome (the room is not very big, but I don't expect a lot of
people, perhaps a dozen, for the rehearsal in Paris... However, Irill
is in central Paris and easily reachable.). Thanks to Roberto Di Cosmo,
head of IRILL, to let me talk there.

For those in France and/or not attending the GCC Summit but interested
by GCC MELT, feel free to forward this.

###"

[[tutorial given at Ottawa, GCC Summit, October 26th 2010, with a
rehearsal given in Paris, october 20th 2010, 10:00 am, at IRILL, 25
avenue d'Italie, 75014 Paris, France]]

Easily coding a GCC extension with MELT
===
GCC MELT is a branch and plugin providing a powerful domain specific
lispy language to code GCC extensions in. MELT offers several high
level features and is translated to C code, hooked to GCC thru the
plugins hooks. Notable features of MELT include: interface to most GCC
internal types( like Gimple, Tree, Loop-s, etc.), a copying garbage
collector, a single-inheritance, reflexive, object system, first-class
functional values and anonymous functions, powerful and flexible
pattern matching, easy integration of C code chunks. The tutorial is
targeted for the GCC summit audience: people somehow familiar with the
GCC internals (e.g. knowledgeable of the Gimple & Tree representations,
and of the passes organization). It does not presuppose familiarity
with Lisp. It will show how the main feature of the MELT domain
specific language, how to code simple and more complex passes using
MELT, how can passes share data, how to extend MELT itself, how to
interface additional GCC internals to MELT, etc. MELT could be used to
prototypes new ideas inside GCC, but is in particular intended for
application-, entreprise-, or domain- specific extensions of GCC, e.g.
for GCC extensions tailored to some big software project (improved
diagnostics, specific optimizations, source code processing, navigation,
retro-engineering, ...).

This GCC summit MELT tutorial requires some basic knowledge about GCC
internals. The first part of this tutorial will illustrate basic usage
of MELT and introduce the MELT lispy domain specific language and the
separation of MELT values from other stuff. It does not presuppose any
familiarity with any Lisp variant. The second part of the tutorial will
focus on MELT pattern matching facilities and show how to use them to
concisely explore particular GCC internal representations (notably
Gimple and Tree). The third part of the tutorial will detail how to
code real GCC passes in MELT and suggest possible MELT extensions for
several specific domains. It will give some insight on the internals of
MELT. 

#
Regards.
#

French micro-summary:

Micro-résumé français.

Je vais faire une répétition (en anglais) de ma présentation tutorielle
sur GCC MELT (la présentation définitive aura lieu au GCC Summit à
Ottawa, Canada, le 26 octobre 2010). Cette répétition aura lieu dans
les locaux de l'IRILL, 25 avenue d'Italie, 75014 Paris
http://www.irill.org/ le mercredi 20 octobre 2010 à 10h du matin.

-- 
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***