GCC informal meetings at IRILL (Paris, France)

[Basile Starynkevitch]

Hello All,

This is to inform GCC contributors living near Paris that Albert Cohen & me 
are organizing some GCC informal meetings at IRILL.

http://www.irill.org/ is a small Research an Inovvation center on Free 
Software, sponsored notably by INRIA & Paris Pierre et Marie Curie (Paris 6) & 
Paris Diderot (Paris 7) universities.

Every one interested in GCC can attend, but please inform
albert.co...@inria.fr & me bas...@starynkevitch.net a few days before
attending.

The first (& previous) meeting was on january 6th 2011.

Next meeting is on Thu January 27th 2011, at 9h30 Paris local time (CET)

Location is IRILL, 25 avenue d'Italie, Paris 75013.

See http://www.irill.org/about/access for details.

Working language is English (or French if everyone speaks French).

Meeting is informal (a priori no slides), mostly for discussion about code &
ideas. Bring your laptop with your GCC work!

IRILL is a nice, new, place: colored offices, warm persons...

(I will be delighted to talk about GCC MELT, and uderstand more about passes
& graphite, you can bring other subjects.).

Regards
-- 
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 mines, sont seulement les miennes} ***

Re: PATCH: 2 stage BFD linker for LTO plugin

[Richard Guenther]

On Wed, Jan 19, 2011 at 1:27 AM, Ian Lance Taylor  wrote:
> After some discussion on IRC, here is another approach to resolving the
> issue with static linking and LTO.
>
> In this approach, the linker keeps track of all archives found after the
> first file claimed by the plugin.  If the plugin adds any object files,
> and the object files refer to any symbols which are not yet defined,
> then the linker will scan all the saved archives, in order, for a
> definition of the symbol.  If a definition is found, the linker will
> pull in the appropriate object from the archive.  If that object, in
> turn, has any undefined symbols, the linker will pull in the appropriate
> object from that archive or any later ones, and so forth.  The linker
> will honor --start-group/--end-group while rescanning.
>
> This should ensure that any previously unseen undefined symbols
> introduced by the compiler are handled correctly.  I think it is
> appropriate to do this unconditionally when using plugins, as there is
> no other reasonable way to handle undefined symbols in a file added by a
> plugin.
>
> I've appended a patch to gold which implements this approach.  The patch
> is reasonably efficient and introduces no unnecessary file I/O.  With
> this patch to gold, and no change to gcc, the problematic -static test
> cases which I know about pass.  Also all the current lto.exp tests pass.
> All those tests also pass if I edit the gcc LTO plugin to ignore the
> -pass-through option, as that option is not necessary when the linker
> implements this approach.
>
> As this patch does not require any changes to gcc, and fixes some cases
> which are clearly bugs, I plan to commit this patch to binutils mainline
> and to binutils 2.21 branch after a few days if I don't hear any
> comments.

Nice.  Can we on the GCC side somehow identify Gold versions
that support this and avoid -pass-through handling in that case?
I'm not sure if with your patch the add_input_library or
add_input_file plugin hooks are completely useless (and thus
gold could simply ignore those at all).

Richard.

> Ian
>
>
> 2011-01-18  Ian Lance Taylor  
>
>        * plugin.cc (class Plugin_rescan): Define new class.
>        (Plugin_manager::claim_file): Set any_claimed_.
>        (Plugin_manager::save_archive): New function.
>        (Plugin_manager::save_input_group): New function.
>        (Plugin_manager::all_symbols_read): Create Plugin_rescan task if
>        necessary.
>        (Plugin_manager::new_undefined_symbol): New function.
>        (Plugin_manager::rescan): New function.
>        (Plugin_manager::rescannable_defines): New function.
>        (Plugin_manager::add_input_file): Set any_added_.
>        * plugin.h (class Plugin_manager): define new fields rescannable_,
>        undefined_symbols_, any_claimed_, and any_added_.  Declare
>        Plugin_rescan as friend.  Declare new functions.
>        (Plugin_manager::Rescannable): Define type.
>        (Plugin_manager::Rescannable_list): Define type.
>        (Plugin_manager::Undefined_symbol_list): Define type.
>        (Plugin_manager::Plugin_manager): Initialize new fields.
>        * archive.cc (Archive::defines_symbol): New function.
>        (Add_archive_symbols::run): Pass archive to plugins if any.
>        * archive.h (class Archive): Declare defines_symbol.
>        * readsyms.cc (Input_group::~Input_group): New function.
>        (Finish_group::run): Pass input_group to plugins if any.
>        * readsyms.h (class Input_group): Declare destructor.
>        * symtab.cc (add_from_object): Pass undefined symbol to plugins if
>        any.
>
>
>

PLUGIN_FINISH_TYPE not executed for enums

[Joachim Wieland]

Hi,

is there any reason why in gcc-4.5.1 the plugin hook
PLUGIN_FINISH_TYPE is not executed for enums?

In c-parser.c there is a call to

invoke_plugin_callbacks (PLUGIN_FINISH_TYPE, t.spec);

for RID_STRUCT and RID_UNION but not for RID_ENUM. Is this an
oversight or on purpose?


Thanks,
Joachim

Re: PATCH: 2 stage BFD linker for LTO plugin

[Ian Lance Taylor]

Richard Guenther  writes:

> Nice.  Can we on the GCC side somehow identify Gold versions
> that support this and avoid -pass-through handling in that case?

Sure.  The LDPT_GOLD_VERSION tag, which lto-plugin currently ignores,
will return the version of gold.  I can bump that version when I commit
this patch, and lto-plugin can check it.

> I'm not sure if with your patch the add_input_library or
> add_input_file plugin hooks are completely useless (and thus
> gold could simply ignore those at all).

The plugin does need to use the add_input_file callback.  In any case
I'm not sure it's a great idea for gold to ignore a hook, there might be
some need for it in the future.

Ian

Re: PLUGIN_FINISH_TYPE not executed for enums

[Basile Starynkevitch]

On Wed, Jan 19, 2011 at 09:27:54AM -0500, Joachim Wieland wrote:
> Hi,
> 
> is there any reason why in gcc-4.5.1 the plugin hook
> PLUGIN_FINISH_TYPE is not executed for enums?
> 
> In c-parser.c there is a call to
> 
> invoke_plugin_callbacks (PLUGIN_FINISH_TYPE, t.spec);
> 
> for RID_STRUCT and RID_UNION but not for RID_ENUM. Is this an
> oversight or on purpose?

I believe it is a bug, and I hope it could be fixed before 4.6

Cheers

-- 
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 mines, sont seulement les miennes} ***

Re: ANN: Two new branches google/integration and google/main

[Diego Novillo]

On Tue, Jan 18, 2011 at 09:00, H.J. Lu  wrote:

> It is very nice to hear that.  I just have one comment.  SVN is very
> poor at merging while merge is very easy with GIT.  However, our
> git mirror doesn't mirror branches/XXX/YYY. It will be nice to
> mirror Google branches as well as ix86 branches in git.

Sure.  I guess I could do that, but I don't really know how the
git-svn bridge is setup on sourceware.  Would you mind giving me a
hand with this?


Thanks.  Diego.

Re: ANN: Two new branches google/integration and google/main

[H.J. Lu]

On Wed, Jan 19, 2011 at 7:41 AM, Diego Novillo  wrote:
> On Tue, Jan 18, 2011 at 09:00, H.J. Lu  wrote:
>
>> It is very nice to hear that.  I just have one comment.  SVN is very
>> poor at merging while merge is very easy with GIT.  However, our
>> git mirror doesn't mirror branches/XXX/YYY. It will be nice to
>> mirror Google branches as well as ix86 branches in git.
>
> Sure.  I guess I could do that, but I don't really know how the
> git-svn bridge is setup on sourceware.  Would you mind giving me a
> hand with this?
>

I understand Jason and Alexandre have some scripts for this.


-- 
H.J.

assertion failure in df_reg_chain_mark

[Christian Grössler]

Hi,

I'm in the process of reviving a 2 year old port and merge the changes done to 
gcc since Nov-2008 into it.

Now I'm getting an assertion failure:

In file included from ../../../src/libiberty/regex.c:638:0:
../../../src/libiberty/regex.c: In function 'byte_re_match_2_internal':
../../../src/libiberty/regex.c:7484:1: internal compiler error: in 
df_reg_chain_mark, at df-scan.c:4233
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


This part in df_reg_chain_mark triggers the assertion:


  if (is_eq_use)
gcc_assert ((DF_REF_FLAGS (ref) & DF_REF_IN_NOTE));
  else
gcc_assert ((DF_REF_FLAGS (ref) & DF_REF_IN_NOTE) == 0);   this 
one

  if (DF_REF_NEXT_REG (ref))
gcc_assert (DF_REF_PREV_REG (DF_REF_NEXT_REG (ref)) == ref);


Can anyone give me some hints or pointers where to look to resolve the problem?

thanks,
chris

PS: imported gcc source is from Nov-29-2010

Does TYPE_MAX_VALUE (size_type_node) overflow?

[Florian Weimer]

I get strange warnings when I do arithmetic involving TYPE_MAX_VALUE
(size_type_node), in particular this code:

/* Multiplies MUL1 with MUL2, and adds ADD.  Returns (size_t)-1 if the
   result cannot be be represented as a size_t value.  If ADD is
   null_tree, treat it as a zero constant.
 */
tree
build_size_mult_saturated (tree mul1, tree mul2, tree add)
{
  tree max_mul1, result;
  max_mul1 = TYPE_MAX_VALUE (size_type_node);
  if (add != NULL_TREE)
max_mul1 = size_binop(MINUS_EXPR, max_mul1, add);
  max_mul1 = size_binop(TRUNC_DIV_EXPR, max_mul1, mul2);
  result = size_binop (MULT_EXPR, mul1, mul2);
  if (add != NULL_TREE)
result = size_binop (PLUS_EXPR, result, add);
  return build3 (COND_EXPR, sizetype,
 build2 (EQ_EXPR, sizetype, mul2, size_zero_node),
 add == NULL_TREE ? size_zero_node : add,
 build3 (COND_EXPR, sizetype,
 build2 (LE_EXPR, sizetype, mul1, max_mul1),
 result, TYPE_MAX_VALUE (size_type_node)));
}

Is size_type_node really signed, and does TYPE_MAX_VALUE
(size_type_node) lie outside the representable range?  Is there an
easy way to get a GCC type closely matching size_t in C++?

Re: BOOT_CFLAGS coverage

[Jack Howarth]

On Tue, Jan 18, 2011 at 08:49:16PM -0800, Ian Lance Taylor wrote:
> Andrew Pinski  writes:
> 
> > On Tue, Jan 18, 2011 at 5:02 PM, Jack Howarth  
> > wrote:
> >>  While doing bootstraps with...
> >>
> >> make -j 8 profiledbootstrap BOOT_CFLAGS="-g -O3"
> >>
> >> I noticed the absence of these flags being utilized in libdecnumber, 
> >> libffi, libgcc, etc.
> >> This also appears to be limiting the coverage of the lto-bootstrap as 
> >> well. Are there any
> >> plans to address in the near term? If not, any hints on what we are 
> >> missing to solve this?
> >> Is it as simple as adding the appropriate entries in Makefile.in for 
> >> BUILD_COMPILERFLAGS
> >> and BUILD_CPPFLAGS?
> >
> > I think you need TARGET_CFLAGS set too.
> 
> That is, CFLAGS_FOR_TARGET.
> 
> BOOT_CFLAGS is used for code compiled to run on the host system.
> CFLAGS_FOR_TARGET is used for code compiled to run on the target
> system.  libdecnumber, libffi, libgcc are all compiled to run on the
> target system, not the host system.
> 
> Ian

Ian,
   Thanks. On x86_64-apple-darwin10 with...

configure flags: --prefix=/sw --prefix=/sw/lib/gcc4.6 --mandir=/sw/share/man 
--infodir=/sw/lib/gcc4.6/info --with-build-config=bootstrap-lto 
--enable-stage1-languages=c,lto 
--enable-languages=c,c++,fortran,lto,objc,obj-c++,java --enable-build-with-cxx 
--with-gmp=/sw --with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw 
--with-mpc=/sw --with-system-zlib --x-includes=/usr/X11R6/include 
--x-libraries=/usr/X11R6/lib --program-suffix=-fsf-4.6 --enable-checking=yes 
--enable-cloog-backend=isl

and...

make -j profiledbootstrap BOOT_CFLAGS="-g -O3" CFLAGS_FOR_TARGET="-g -O3"

there are no regressions. Nice.
 Jack

Re: PATCH: 2 stage BFD linker for LTO plugin

[Jan Hubicka]

> On Wed, Jan 19, 2011 at 1:27 AM, Ian Lance Taylor  wrote:
> > After some discussion on IRC, here is another approach to resolving the
> > issue with static linking and LTO.
> >
> > In this approach, the linker keeps track of all archives found after the
> > first file claimed by the plugin.  If the plugin adds any object files,
> > and the object files refer to any symbols which are not yet defined,
> > then the linker will scan all the saved archives, in order, for a
> > definition of the symbol.  If a definition is found, the linker will
> > pull in the appropriate object from the archive.  If that object, in
> > turn, has any undefined symbols, the linker will pull in the appropriate
> > object from that archive or any later ones, and so forth.  The linker
> > will honor --start-group/--end-group while rescanning.
> >
> > This should ensure that any previously unseen undefined symbols
> > introduced by the compiler are handled correctly.  I think it is
> > appropriate to do this unconditionally when using plugins, as there is
> > no other reasonable way to handle undefined symbols in a file added by a
> > plugin.
> >
> > I've appended a patch to gold which implements this approach.  The patch
> > is reasonably efficient and introduces no unnecessary file I/O.  With
> > this patch to gold, and no change to gcc, the problematic -static test
> > cases which I know about pass.  Also all the current lto.exp tests pass.
> > All those tests also pass if I edit the gcc LTO plugin to ignore the
> > -pass-through option, as that option is not necessary when the linker
> > implements this approach.
> >
> > As this patch does not require any changes to gcc, and fixes some cases
> > which are clearly bugs, I plan to commit this patch to binutils mainline
> > and to binutils 2.21 branch after a few days if I don't hear any
> > comments.
> 
> Nice.  Can we on the GCC side somehow identify Gold versions
> that support this and avoid -pass-through handling in that case?
> I'm not sure if with your patch the add_input_library or
> add_input_file plugin hooks are completely useless (and thus
> gold could simply ignore those at all).

Nice indeed.  I think we should version tag the plugin interface and
handle this as version 1.1 or something.
We also want to add the PREVAILING_IRONLY_EXT and other bits that will
need some housekeeping of what plugin interface the linker provides.

Honza

Re: PATCH: 2 stage BFD linker for LTO plugin

[Cary Coutant]

>> I'm not sure if with your patch the add_input_library or
>> add_input_file plugin hooks are completely useless (and thus
>> gold could simply ignore those at all).
>
> The plugin does need to use the add_input_file callback.  In any case
> I'm not sure it's a great idea for gold to ignore a hook, there might be
> some need for it in the future.

With this patch, the plugin won't need add_input_library, which was
added to support the pass-through option. It still needs
add_input_file, which is how the plugin inserts the newly-compiled
objects.

-cary