On Thu, Mar 8, 2012 at 12:38 AM, Jakub Jelinek wrote:
> On Wed, Mar 07, 2012 at 06:24:14PM -0800, Ollie Wild wrote:
>
> The reason why libgcc.a symbols are hidden is to avoid exporting those
> symbols from shared libraries for -static-libgcc etc. links.
> It used to cause bi
On Thu, Mar 8, 2012 at 7:23 AM, H.J. Lu wrote:
>
> If I understand it correctly, the reason Google doesn't want libgcc_s.so
> is Google believes GPLv3 exception only applies to libgcc,a and libgcc_eh,a,
> not libgcc_s.so. If GPLv3 exception also applies to libgcc_s.so, Google
> may consider using
For reasons outside the scope of this discussion, we're experimenting
with statically linking libgcc.a and libgcc_eh.a into dynamically
linked applications which depend on libc but no other dynamic
libraries. To make this work, libc needs to access a few functions
for stack unwinding inside pthrea
LGTM
Ollie
On Wed, Sep 14, 2011 at 3:29 PM, Diego Novillo wrote:
>
> This merge brings google/integration up to rev 178783. I also
> merged rev 178833 to get the testsuite validation script I
> committed to trunk yesterday.
>
> Simon, Ollie, I expect our internal builder to fail until I
> incor
On Wed, Jun 29, 2011 at 11:24 AM, Ollie Wild wrote:
>
> On Wed, Jun 29, 2011 at 10:42 AM, Martin Jambor wrote:
> >
> > The fix for 49094 had to be changed and is still being tested, even
> > for trunk, and thus I have committed a 4.6 "backport" of the fix for
On Wed, Jun 29, 2011 at 10:42 AM, Martin Jambor wrote:
>
> The fix for 49094 had to be changed and is still being tested, even
> for trunk, and thus I have committed a 4.6 "backport" of the fix for
> PR 49516 on its own today (as revision 175634). Nevertheles yes, the
> patch is exactly the same,
On Fri, Oct 17, 2008 at 12:32 PM, Diego Novillo <[EMAIL PROTECTED]> wrote:
>
> lto1 (even if -flto is not provided) and eventually we'll need to
> support archives in the reader.
Will we? I thought one of the main justifications for implementing a
plugin architecture in the linker was to avoid ha
>From what I can tell from grepping the lto source, the vtable entry in
lto_file is set but never used. Is this old code that never got
removed or the beginning of an idea that never got implemented?
I'm inclined to remove it if it's not doing anything.
Ollie
Doug,
Yesterday, we spoke briefly about the need to efficiently determine
the DECL's required by each function. Here's a more detailed
overview. During the WPA phase of WHOPR, we will be reading in a
collection of object files, performing analysis on call-graph/summary
data, and outputting repac
On Wed, Jun 4, 2008 at 12:33 PM, Chris Lattner <[EMAIL PROTECTED]> wrote:
>
> Right, I understand that you design "stacks" on LTO. It just seems strange
> to work on the advanced stuff before the basic GCC LTO stuff is close to
> being useful.
To some degree, we're scratching our own itch here.
Reposting this as well.
Ollie
On Wed, Jun 4, 2008 at 9:14 AM, Chris Lattner <[EMAIL PROTECTED]> wrote:
>
> 1) start with all code in memory and see how far you can get. It seems that
> on reasonable developer machines (e.g. 2GB memory) that we can handle C
> programs on the order of a million
Reposting to the gcc list since my first email got bounced.
Ollie
On Tue, Jun 3, 2008 at 7:26 PM, Chris Lattner <[EMAIL PROTECTED]> wrote:
> This is a very interesting design, and a very nice evolution from the
> previous proposal. I'm not completely clear on the difference between LTO
> an
On Fri, Mar 14, 2008 at 1:44 PM, Stephen R. van den Berg <[EMAIL PROTECTED]>
wrote:
>
> [svn]
>noMetadata = true
This will prevent users from using the GCC git repository to bootstrap
their own local git-svn-aware repositories. We definitely don't want
to do this.
Ollie
On Feb 1, 2008 9:03 PM, James Courtier-Dutton <[EMAIL PROTECTED]> wrote:
>
> Can anyone point me to which part of the gcc source tree does the
> task, and also what format the data is stored in once processed.
The preprocessor is implemented by cpplib. Take a look at the code in
libcpp as well as
On Dec 12, 2007 11:14 PM, Praveen Raghavan <[EMAIL PROTECTED]> wrote:
>
> 1. Are there also plans to extend the global transformation
> capabilities. I see that the original set of global transformations is
> limited (rightfully so).
This is still at a very early design stage. Additional
transfor
On Dec 12, 2007 3:28 PM, Tim Josling <[EMAIL PROTECTED]> wrote:
>
> Do you have any thoughts on how this approach would be able to use
> profiling information, which is very a very powerful source of
> information for producing good optimisations?
The intent is for the WPA phase to utilize profile
On Dec 5, 2007 1:40 PM, Daniel Berlin <[EMAIL PROTECTED]> wrote:
>
> > Out of curiosity, how much of that is the .git/svn directory? This is
> > where git-svn-specific data is stored. It is *very* inefficient, at
> > least for the 1.5.2.5 version I'm using.
> >
>
> I was only counting the space i
On Dec 5, 2007 11:08 AM, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> So I tried a full history conversion using git-svn of the gcc
> repository (IE every trunk revision from 1-HEAD as of yesterday)
> The git-svn import was done using repacks every 1000 revisions.
> After it finished, I used git-gc -
On 9/29/07, Eric Botcazou <[EMAIL PROTECTED]> wrote:
>
> Thanks, but this was not really necessary, Ada doesn't define
> LANG_HOOKS_EXPAND_CONSTANT, you only needed to restore lhd_return_tree.
Yes, but it was late, I had a toddler who needed putting to bed, and I
had no idea why I'd failed to noti
On 9/28/07, John David Anglin <[EMAIL PROTECTED]> wrote:
> This change breaks Ada:
Sorry, folks. I've rolled this back.
Ollie
I've recently noticed that every time I build GCC, the source files in
the libstdc++-v3/include/precompiled directory have their modification
timestamps updated. Anyone know what's going on here?
Ollie
On 9/13/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> I wouldn't characterize my objections as terribly strong. It's
> certainly nothing against distcc or ccache. But, I think these kinds of
> mentions are odd to put in our documentation. The manual should say
> what the options do. Referenci
On 9/13/07, Tom Tromey <[EMAIL PROTECTED]> wrote:
> >>>>> "Ollie" == Ollie Wild <[EMAIL PROTECTED]> writes:
>
> Ollie> One quick question. When I updated the gcc info page, Mark
> Ollie> Mitchell felt strongly that it shouldn't mention
On 9/11/07, Gerald Pfeifer <[EMAIL PROTECTED]> wrote:
> On Tue, 11 Sep 2007, Tom Tromey wrote:
> >> Also, I recently added a new -fdirectives-only option which improves
> >> distcc and ccache performance. Does that merit a release note update
> > as well?
> > IMO, yes.
>
> Seconded. :-)
OK. I'll
On 9/9/07, Gerald Pfeifer <[EMAIL PROTECTED]> wrote:
> Ollie, would you mind adding a snippet to htdocs/gcc-4.3/changes.html
> in the wwwdocs module of our CVS repository? If you need any help with
> that, please let me know.
Sent to gcc-patches at
http://gcc.gnu.org/ml/gcc-patches/2007-09/msg010
On 8/9/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Daniel Berlin wrote:
>
> >> This is the source of my current woes, as this may involve virtual
> >> function resolution, which can't be done with the information
> >> currently available to the middle end.
>
> Ollie, IIRC, you posted an example
On 8/8/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> I also haven't necessarily said what Ollie has proposed is a bad idea.
> I have simply said the way he has come up with what he proposed is
> not the way we should go about this. It may turn out he has come up
> with exactly the representation
On 8/8/07, Michael Matz <[EMAIL PROTECTED]> wrote:
> So those tree expressions would live throughout the middle-end and only
> then become lowered to RTL directly? I'm not sure that's worthwhile.
> E.g. I'm not sure why there's a need to really get rid of the
> expand_constant langhook. It's only
Hi,
In response to a suggestion from Mark Mitchell, I've been attempting
to migrate pointers to members to the GCC middle end. The goal of
this is twofold: (a) to enable conversion of pointer to member
dereferences to direct function calls and member accesses when
analysis determines this is unam
On 7/3/07, Bernardo Innocenti <[EMAIL PROTECTED]> wrote:
Ollie Wild wrote:
> As an aside to the ongoing git repository discussion, I'm curious if
> anyone has experimented with committing changes to the GCC repository
> via git-svn's dcommit command. I'm curi
As an aside to the ongoing git repository discussion, I'm curious if
anyone has experimented with committing changes to the GCC repository
via git-svn's dcommit command. I'm curious to know if it plays nicely
with GCC's svn commit machinery.
Ollie
On 5/31/07, Joseph S. Myers <[EMAIL PROTECTED]> wrote:
Zack had some ideas a few years ago (I don't think they were ever posted
to a public list) about how to speed up _cpp_clean_line in particular, and
some or all of translation phases 1 to 3 in general. The idea is that you
have several Mealy
git-svnimport will not pack incrementally as it runs, so it might get
pretty large. git-svn offers and incremental repack every x commits
(I chose 1000) and that did wonders for the import time for me.
Otherwise it will create a huge number of files before the final pack.
FYI, doing a repack br
Just another data point, my git-svn clone of trunk comes in at 414MB,
excluding the size of checked out files. I'm assuming the public svn
is the complete history.
I'm about 35% through the process of cloning the entire gcc repository
via git-svnimport, and the .git directory is 5.0GB. This in
Related to this: have you guys ever considered to making the -On
flags dependent on the architecture?
It came up in a few side conversations. As I understand it, RMS has
decreed that the -On optimizations shall be architecture independent.
That said, there are "generic" optimizations which real
35 matches
Mail list logo
