On Fri, 2 Oct 2009, Diego Novillo wrote:
> On Fri, Oct 2, 2009 at 18:16, Richard Guenther wrote:
>
> > Done. If all goes well I think we should merge - waiting even more
> > doesn't really add to the quality and it just takes extra ressources
> > to work on the branch.
>
> I agree. I'd like t
Hi,
Is it possible for a component_ref node to have its arg 0 to be NULL ?
I would think not because from tree.def I gather that arg 0 tells me
what structures field this component_ref refers to. For convenience, I
have pasted here what tree.def tells me about a component_ref
/* Value is structu
I have started the final merge from the lto branch into trunk. Please
refrain from committing any changes until I open mainline again.
Thanks. Diego.
On Sat, Oct 3, 2009 at 12:43 PM, Pranav Bhandarkar
wrote:
> Hi,
>
> Is it possible for a component_ref node to have its arg 0 to be NULL ?
> I would think not because from tree.def I gather that arg 0 tells me
> what structures field this component_ref refers to. For convenience, I
> have pasted h
Diego Novillo wrote:
I have started the final merge from the lto branch into trunk. Please
refrain from committing any changes until I open mainline again.
Will the merge allow lto by default (so that we do not have to specify
--enable-lto) ?
Or do we have to force it, like on the branch ?
On Sat, Oct 3, 2009 at 10:13, Toon Moene wrote:
> Will the merge allow lto by default (so that we do not have to specify
> --enable-lto) ?
If the correct version is found, yes. This is the same behaviour that
is implemented in the lto branch.
> Or do we have to force it, like on the branch ?
Diego Novillo wrote:
On Sat, Oct 3, 2009 at 10:13, Toon Moene wrote:
Will the merge allow lto by default (so that we do not have to specify
--enable-lto) ?
If the correct version is found, yes. This is the same behaviour that
is implemented in the lto branch.
Or do we have to force it, l
On Sat, Oct 3, 2009 at 10:30, Toon Moene wrote:
> So tomorrow I plan to svn up my gcc trunk, recompile it for C and Fortran,
> recompile our Weather Forecasting system with it, and see what happens (the
> compile of the Weather code doesn't use -flto yet, obviously.
Thanks, that would be great.
On Sat, Oct 3, 2009 at 4:34 PM, Diego Novillo wrote:
> On Sat, Oct 3, 2009 at 10:30, Toon Moene wrote:
>
>> So tomorrow I plan to svn up my gcc trunk, recompile it for C and Fortran,
>> recompile our Weather Forecasting system with it, and see what happens (the
>> compile of the Weather code does
On Sat, Oct 3, 2009 at 10:44, Richard Guenther
wrote:
> On Sat, Oct 3, 2009 at 4:34 PM, Diego Novillo wrote:
>>
>> Thanks, that would be great. Please file bugs you find with
>> 'Component: lto' and 'Reported against: lto'.
>
> Actually after the merge it would be 'Reported against: 4.5.0'. I p
Hi All,
Got the output i386.dfa file in the location -
{$gcc_home}/host-i686-pc-linux-gnu/gcc.
Followed 2 steps:
1. In the initiate_automaton_gen() function of 'genautomata.c', initialize
the v_flag variable to 1 i.e., v_flag = 1;
2. Build target 'insn-automata.c'.
-Dhiraj
--
V
Hi All,
Got the output i386.dfa file in the location -
{$gcc_home}/host-i686-pc-linux-gnu/gcc.
Followed 2 steps:
1. In the initiate_automaton_gen() function of 'genautomata.c', initialize
the v_flag variable to 1 i.e., v_flag = 1;
2. Build target 'insn-automata.c'.
-Dhiraj
--
V
The LTO branch has been merged into trunk at revision 152434.
Please note that trunk remains CLOSED. I would like to give
automatic testers a chance to pick up the merge and test it in
isolation. I plan to open trunk in 48 hours (Mon 5 Oct).
Following this message, I will post the final 13 patc
On Sat, Oct 3, 2009 at 11:12 PM, Diego Novillo wrote:
> The LTO branch has been merged into trunk at revision 152434.
...
> To enable LTO, simply add the flag '-flto' to both compile and
> link commands. It doesn't really matter whether you compile and
> link in separate invocations or a single o
On Sat, Oct 3, 2009 at 17:32, Richard Guenther
wrote:
> Note that one missing feature is picking up entries from static library
> archives at link time.
This is true when using GNU ld. But it works just fine if you
configure gcc with --enable-gold and compile with -use-linker-plugin.
Diego.
On Sat, Oct 3, 2009 at 11:12 PM, Diego Novillo wrote:
> The LTO branch has been merged into trunk at revision 152434.
Btw, I think this deserves a news entry on the main page as well as (obviously)
an entry for gcc-4.5/changes.html.
Richard.
On Sat, Oct 3, 2009 at 18:24, Richard Guenther
wrote:
> On Sat, Oct 3, 2009 at 11:12 PM, Diego Novillo wrote:
>> The LTO branch has been merged into trunk at revision 152434.
>
> Btw, I think this deserves a news entry on the main page as well as
> (obviously)
> an entry for gcc-4.5/changes.html
On Sat, Oct 3, 2009 at 19:40, Diego Novillo wrote:
> On Sat, Oct 3, 2009 at 18:24, Richard Guenther
> wrote:
>> On Sat, Oct 3, 2009 at 11:12 PM, Diego Novillo wrote:
>>> The LTO branch has been merged into trunk at revision 152434.
>>
>> Btw, I think this deserves a news entry on the main page a
On Sat, 3 Oct 2009 17:12:17 -0400
Diego Novillo wrote:
> Instructions on how to enable LTO support are described in the
> manual. The following is a summary:
>
> - Install libelf 0.8.12+ (http://www.mr511.de/software/libelf-0.8.12.tar.gz)
> Other versions of libelf are commonly installed in L
Hi Tom, in the fix for PR 22168 you deprecated #ident, in the sense
that gcc now warns about it. Is that really a good idea? #ident is a
reasonably widely used extension: codesearch.google.com finds "about"
110,000 uses. It's supported by other compilers--it was introduced on
System V, I believe
Silvius,
The ext/profile/mh.cc test case is failing to compile on *-*-darwin* due to
the error...
/sw/src/fink.build/gcc45-4.4.999-20091003/gcc-4.5-20091003/libstdc++-v3/testsuite/ext/profile/mh.cc:24:20:
fatal error: malloc.h: No such file or directory
This test case should be including
Hi,
>From gcc online docs (http://gcc.gnu.org/onlinedocs/libgomp/), I found
documentations for most of OpenMP constructs, except one very
important construct TASK. I don't know why it is missing, but I really
need to find out how TASK get transformed into GOMP_* routines. I
posted this question be
"Paul Edwards" writes:
>> * Configure gcc as a cross-compiler.
>
> So this would not be considered a Canadian Cross after all,
> and with configure I only change the target, not the host?
The end result is a Canadian Cross, but the first step in a typical
build of a Canadian Cross is a cross-com
> "Ian" == Ian Lance Taylor writes:
Ian> Hi Tom, in the fix for PR 22168 you deprecated #ident, in the sense
Ian> that gcc now warns about it. Is that really a good idea?
No.
I don't remember why I did this, but I assume it was due to the
pre-existing comment above the directive table sayi
* Configure gcc as a cross-compiler.
So this would not be considered a Canadian Cross after all,
and with configure I only change the target, not the host?
The end result is a Canadian Cross, but the first step in a typical
build of a Canadian Cross is a cross-compiler.
Ok.
* Write a cross
"Paul Edwards" writes:
* Copy header files and libraries from the host (MVS).
>>>
>>> That's fine. And use the --with-root option of configure to get
>>> them used?
>>
>> --with-sysroot, yes.
>
> I have been trying combinations of --prefix and --with-sysroot, and
> --with-build-sysroot, but
* Copy header files and libraries from the host (MVS).
That's fine. And use the --with-root option of configure to get
them used?
--with-sysroot, yes.
I have been trying combinations of --prefix and --with-sysroot, and
--with-build-sysroot, but it is still insisting that I have an
fputs_unl
27 matches
Mail list logo
