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
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 ad
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
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
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 R
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 branche
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 wil
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/
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.
*/
tre
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
> 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 t
>> 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
12 matches
Mail list logo
