On Thu, 2005-11-03 at 12:03 -0800, Mike Stump wrote:
> On Nov 3, 2005, at 11:15 AM, Joern RENNECKE wrote:
> > bash-2.05b$ svn diff --old svn+ssh://[EMAIL PROTECTED]/svn/gcc/
> > trunk/gcc --new gcc
>
> > /usr/bin/diff -up -F'^(' -u -L gcc/.cvsignore (.../svn+ssh://
> > [EMAIL PROTECTED]/svn/gc
On Thu, 2005-11-03 at 20:18 +, Joern RENNECKE wrote:
> Daniel Jacobowitz wrote:
>
> >
> >
> >Whatever you want. It should probably either return success, or use -N.
> >
> >
> I also get a failure when I comment out the diff-cmd line in my
> ~/
On Thu, 2005-11-03 at 19:13 -0500, Daniel Berlin wrote:
> On Thu, 2005-11-03 at 12:03 -0800, Mike Stump wrote:
> > On Nov 3, 2005, at 11:15 AM, Joern RENNECKE wrote:
> > > bash-2.05b$ svn diff --old svn+ssh://[EMAIL PROTECTED]/svn/gcc/
> > > trunk/gcc --new gcc
>
On Thu, 2005-11-03 at 20:29 -0500, Joern Rennecke wrote:
> > What version of svn?
>
> The 1.3 release candidate.
>
> > What is the exact branch you are trying to diff??
>
> I had checked out a copy of the sh-elf-4_1-branch, and used
> svn merge to apply the patches from the last merge point to
>
On Fri, 2005-11-04 at 15:45 +0100, Richard Guenther wrote:
> On Fri, 4 Nov 2005, Diego Novillo wrote:
>
> > On Friday 04 November 2005 08:34, Richard Guenther wrote:
> >
> > > * tree-flow-inline.h (ref_contains_indirect_ref): Deal
> > > with INDIRECT_REF not in handled_component_p.
> > >
> >
On Fri, 2005-11-04 at 15:05 +, Joern RENNECKE wrote:
> Daniel Berlin wrote:
>
> >
> >
> >I did
> >
> >svn co svn+ssh://gcc.gnu.org/svn/gcc/branches/sh-elf-4_1-branch
> >cd sh-elf-4_1-branch
> >svn merge -r106276:106279 svn+ssh://gcc.gnu.org/sv
On Fri, 2005-11-04 at 10:17 -0500, Diego Novillo wrote:
> On Friday 04 November 2005 10:07, Richard Kenner wrote:
> > #if defined ENABLE_CHECKING
> > gcc_assert (handled_component_p (ref))
> > #endif
> >
> > If the comment says it has to be an ARRAY_REF, why not just check for
>
On Fri, 2005-11-04 at 16:23 +, Dave Korn wrote:
> Daniel Berlin wrote:
>
> > The use in tree-ssa-loop-niter.c is really trying to skip out on
> > inferring loop bounds from pointer to structure accesses in the case of
> > things like:
> >
> >
On Fri, 4 Nov 2005, Kelley Cook wrote:
Snapshots haven't been created since 10/29.
I updated the one gccadmin uses yesterday.
look in /home/gccadmin/scripts
Looks like the version of gcc_release running on gcc.gnu.org is still the old
CVS based one.
gcc_release: Tagging sources as gcc
On Sat, 2005-11-05 at 01:07 +, Joseph S. Myers wrote:
> On Fri, 4 Nov 2005, Daniel Berlin wrote:
>
> >
> >
> > On Fri, 4 Nov 2005, Kelley Cook wrote:
> >
> > > Snapshots haven't been created since 10/29.
> >
> > I updated the one gcc
bility. Use if cascades or indirect
> jumps for the others, if necessary.
The only real problem with this is that it mandates use of shared
libgcc for the routines in question... always. If they ever go into
libgcc.a, we can't make sure we got the right copy.
--
Daniel Jacobowitz
CodeSourcery, LLC
On Mon, Nov 07, 2005 at 07:40:51AM -0800, Ulrich Drepper wrote:
> Daniel Jacobowitz wrote:
> > The only real problem with this is that it mandates use of shared
> > libgcc for the routines in question... always. If they ever go into
> > libgcc.a, we can't make
On Fri, Oct 28, 2005 at 03:29:25PM -0400, Daniel Berlin wrote:
> For those who want a starting point to mirror the entire repo from, i
> have placed an rzip'd (http://rzip.samba.org) copy of the repository in
>
> ftp://gcc.gnu.org/pub/gcc/infrastructure/gccrepo.tar.rz
>
&g
On Tue, Nov 08, 2005 at 10:37:13AM -0800, Devang Patel wrote:
> On 11/7/05, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
>
> [snip]
>
> > I have generated an SVK repository to go with this. As anyone who's
> > doing or done this themselves can attest, it tak
On Tue, 2005-11-08 at 13:42 -0500, Daniel Jacobowitz wrote:
> On Tue, Nov 08, 2005 at 10:37:13AM -0800, Devang Patel wrote:
> > On 11/7/05, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
> >
> > [snip]
> >
> > > I have generated an SVK repository to go
On Tue, Nov 08, 2005 at 01:47:52PM -0500, Daniel Berlin wrote:
> If you try to commit to the mirror, it will try to commit to the
> underlying repo.
>
> That's how svk push actually works.
Yes, of course, but what if you've checked out using a read-only
protocol? Is
On Tue, 2005-11-08 at 13:56 -0500, Daniel Jacobowitz wrote:
> On Tue, Nov 08, 2005 at 01:47:52PM -0500, Daniel Berlin wrote:
> > If you try to commit to the mirror, it will try to commit to the
> > underlying repo.
> >
> > That's how svk push actually works.
On Tue, Nov 08, 2005 at 06:41:05PM -0800, Devang Patel wrote:
> On 11/8/05, Daniel Berlin <[EMAIL PROTECTED]> wrote:
>
> > It will simply tell you you don't have access :)
>
> However, it is rejecting local branch creation also.
>
> ---
> $ svk ls
On Thu, 2005-11-10 at 13:37 -0500, Hans-Peter Nilsson wrote:
> On Thu, 10 Nov 2005 [EMAIL PROTECTED] wrote:
>
> > Author: dberlin
> > Date: Thu Nov 10 17:23:49 2005
> > New Revision: 106743
>
> > 2005-11-10 Daniel Berlin <[EMAIL PROTECTED]>
>
> >
On Fri, 2005-11-11 at 19:33 +, drizzle drizzle wrote:
> Hi .
>I want to use gcc's alias analysis in a standalone way. What I
> observe is that a lot of the information is hidden because of
> additional temporaries that have been generated. Can any one suggest
> as to if there is a simpl
On Fri, 2005-11-11 at 22:53 -0800, Ian Lance Taylor wrote:
> David Daney <[EMAIL PROTECTED]> writes:
>
> > > Eventually we should manually mark certain function DECLs as
> > > not-returning-null instead of my kludgy test for this one case. I don't
> > > know if/when I can get to that. Perhaps so
ht it was on by default, and I can't see where that comes
from...
--
Daniel Jacobowitz
CodeSourcery, LLC
default = x
then target_cpu_default=MASK_EXPLICIT_RELOCS
else target_cpu_default="($target_cpu_default)|MASK_EXPLICIT_RELOCS"
fi])
--
Daniel Jacobowitz
CodeSourcery, LLC
o an optional utility, this extra debug info
> should not be emitted by default. There should be an option to emit it.
I'd like to know what the size impact of including basic block
information would be, first; a lot of tools, including GDB, could make
use of it if it were available.
--
Daniel Jacobowitz
CodeSourcery, LLC
ent basic
block because of some artifact of inlining. This shouldn't present any
problem for a tool using the basic block information.
I'm afraid I don't have any useful comments on the patch, but I would
like to see GCC generate this information.
--
Daniel Jacobowitz
CodeSourcery, LLC
On Mon, 2005-11-14 at 22:18 -0500, Andrew Pinski wrote:
> >
> > --Boundary-00=_dwUeD1M6OcgA542
> > Content-Type: text/plain;
> > charset="us-ascii"
> > Content-Transfer-Encoding: 7bit
> > Content-Disposition: inline
> >
> >
> > This branch will act as a repository for new optimizations mostly
ery much an internal representation concept that we're exposing.
--
Daniel Jacobowitz
CodeSourcery, LLC
ry basic block in a function in order to trace
execution a little more efficiently than single stepping.
- Perhaps improve efficiency of checkpoint/restart reverse debugging.
I'm sure there's plenty more :-)
--
Daniel Jacobowitz
CodeSourcery, LLC
On Thu, 2005-11-17 at 01:26 +0100, Giovanni Bajo wrote:
> Mark Mitchell <[EMAIL PROTECTED]> wrote:
>
> > Thoughts?
>
>
> Thanks for woking on this. Any specific reason why using the LLVM bytecode
> wasn't taken into account?
It was.
A large number of alternatives were explored, including CIL,
ases. (This must be
> true when not running with -g, but I thought it was true in other cases
> as well.) It might be true for other tools, too.
It does now, but given the level of complexity associated with
preserving that in your current scheme, it would probably be easier to
fix all the
On Wed, 2005-11-16 at 20:33 -0700, Jeffrey A Law wrote:
> > Our understanding was that the debugger actually uses the symbol table,
> > in addition to the debugging information, in some cases. (This must be
> > true when not running with -g, but I thought it was true in other cases
> > as well.)
ode size. I'd expect much
more than 1% saving the write-out and write-in on -g.
--
Daniel Jacobowitz
CodeSourcery, LLC
> useful comments there are, the better the chance of us getting a decent
> allocator.
I don't have any useful comments, but I want to thank you for doing
this: it seems like a sound design, and a decent strategy to get GCC
moving in an area where it has been stuck in a ditch for a wh
ests in the linuxthreads testsuite and I've run it on HEAD
recently.
--
Daniel Jacobowitz
CodeSourcery, LLC
's, or move on with Andrew's new design to modernize
GCC's.
(B) What bits of GCC would we be bypassing, and how badly would we miss
them?
Presumably, many of the shiny new tree optimizers. Ow. But GCC was
not in any state to do this sort of surgery a year ago, I think.
--
Daniel Jacobowitz
CodeSourcery, LLC
> (B) What bits of GCC would we be bypassing, and how badly would we miss
> them?
>
> Presumably, many of the shiny new tree optimizers. Ow. But GCC was
> not in any state to do this sort of surgery a year ago, I think.
>
Probably true on both counts, but that wouldn't bother me, speaking as
s
On Sat, 2005-11-19 at 10:14 -0500, Kaveh R. Ghazi wrote:
> Hi Dan,
>
> (BTW, sorry for the reposted messages.)
>
> While I was waiting for some svn commands to finish (cleanup, update)
> on my solaris2.7 box, which has a slow filesystem, I happened to run
> truss -p out of curiosity to see what
question are old enough that they pre-date the fix. I know, for
> example, that FC2 and RHEL3 are affected, but FC4 isn't.
Definitely works on glibc HEAD, then.
--
Daniel Jacobowitz
CodeSourcery, LLC
/home/gdr/svk
If you've got this...
> but the command
>
>svk checkout //gcc/trunk gcc
... then you can't use this. Try /gcc/gcc/trunk?
--
Daniel Jacobowitz
CodeSourcery, LLC
On Mon, 2005-11-21 at 18:52 +0100, Sebastian Pop wrote:
> Paolo Carlini wrote:
> > Hi all, hi Danny,
> >
> > recently I noticed a very stupid but annoying (new!) issue: comments end
> > up wrongly formatted. I think there is a mismatch between the wideness
> > of the "Additional Comments" free for
> Is it obvious that my issue is not the same as Sebastian'? I'm talking
> about text written by hand in the "Additional Comments" free form. The
> free form presents itself with a given wideness, which I trust when
> writing my comment to choose carefully the length of the lines and add
> appropri
On Mon, 2005-11-21 at 18:49 +0100, Gabriel Dos Reis wrote:
> Daniel Berlin <[EMAIL PROTECTED]> writes:
>
> | > Is it obvious that my issue is not the same as Sebastian'? I'm talking
> | > about text written by hand in the "Additional Comments" free form
dea,
although I'm sure a volunteer who cared enough to do so would find it
worthwhile.
--
Daniel Jacobowitz
CodeSourcery, LLC
ool, rather than
piling it into the compiler and linker proper. This wouldn't be a
mammoth task.
--
Daniel Jacobowitz
CodeSourcery, LLC
ems. I know my solaris box would benefit and I believe
> others also if the i/o in SVN were switched to use chdir instead.
>
> Please consider it.
For Solaris, I learned recently, the preferred solution to this problem
is actually "openat" and friends.
--
Daniel Jacobowitz
CodeSourcery, LLC
On Tue, 2005-11-22 at 16:51 +0100, Gabriel Dos Reis wrote:
> "Joseph S. Myers" <[EMAIL PROTECTED]> writes:
>
> | On Fri, 28 Oct 2005, Daniel Berlin wrote:
> |
> | > contrib/ scripts have been updated in the new repository
> |
> | I've merged the gc
) Is it normal that "svk push" takes more than 5 minutes to complete?
>If so, that does not match the speed argument I've seen for the
>move to SVN.
SVN is fast. SVK, in many operations, seems to be quite slow (but fast
on others).
--
Daniel Jacobowitz
CodeSourcery, LLC
On Tue, 2005-11-22 at 17:07 +0100, Gabriel Dos Reis wrote:
> Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
>
> [...]
>
> | There's a lot to be learned (for me at least) about using svk. At some
> | point I will update the wiki with useful bits, but I don't hav
echnology and the LLVM proposal is for merging an
existing (already GCC-based) technology to work more closely with GCC.
I'm not actually as biased in favor of LLVM as this message sounds; I
feel that I don't have a good enough understanding of either option.
But I wanted to clarify what I've learned from my earlier conversations
about this topic.
--
Daniel Jacobowitz
CodeSourcery, LLC
>
> GVM, TU combination and all the associated slimming down of our IR
> data
> structures will be quite a bit of work. This is also needed for
> other
> projects
>
I believe it is more work than porting improvements to LLVM and making
LLVM usable.
Significantly more work.
>
> We would keep
On Tue, 2005-11-22 at 17:58 +0100, Steven Bosscher wrote:
> On Tuesday 22 November 2005 17:20, Diego Novillo wrote:
> > The initial impression I get is that LLVM involves starting from scratch.
>
> I thought it would basically "only" replace the GIMPLE parts of the
> compiler. That is,
>
> FE
On Tue, 2005-11-22 at 19:25 +0100, Gabriel Dos Reis wrote:
> Benjamin Kosnik <[EMAIL PROTECTED]> writes:
>
> [...]
>
> | I'd actually like to make this a requirement, regardless of the option
> | chosen.
>
> Amen.
>
Uh, IPA of any sort is generally not about speed.
It's fine to say compile ti
On Tue, 2005-11-22 at 10:49 -0800, Richard Henderson wrote:
> On Tue, Nov 22, 2005 at 01:47:12PM -0500, Daniel Berlin wrote:
> > Uh, IPA of any sort is generally not about speed.
>
> Except that we're talking about replacing all the tree optimizations
> all of the time w
On Tue, 2005-11-22 at 19:57 +0100, Gabriel Dos Reis wrote:
> Daniel Berlin <[EMAIL PROTECTED]> writes:
>
> | On Tue, 2005-11-22 at 19:25 +0100, Gabriel Dos Reis wrote:
> | > Benjamin Kosnik <[EMAIL PROTECTED]> writes:
> | >
> | > [...]
> | >
> |
On Tue, 2005-11-22 at 13:21 -0600, Benjamin Kosnik wrote:
> > Okay, but you need to understand that reasonable bounds for compiling
> > the entire program at once are usually 3x-7x more (and in the worst
> > case, even wore) than doing it seperately.
> >
> > That is the case with completely state
ining C++ to the
optimizers, i.e. preserving the ability to bootstrap without a C++
compiler.
That said, I wish it weren't necessary.
--
Daniel Jacobowitz
CodeSourcery, LLC
On Wed, 2005-11-23 at 00:58 +0100, Gabriel Dos Reis wrote:
> Russ Allbery <[EMAIL PROTECTED]> writes:
>
> | Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
> | > On Tue, Nov 22, 2005 at 05:07:12PM +0100, Gabriel Dos Reis wrote:
> |
> | >>(2) Is it n
erwise, that's OK, but I'll probably end up
merging a copy of it into GDB at some point. That really looks like
the only feasible way to handle DFP debugging.
--
Daniel Jacobowitz
CodeSourcery, LLC
On Tue, Nov 22, 2005 at 11:23:20PM -0500, Daniel Berlin wrote:
> If you email clkao, and tell him what ops are using tons of memory,
> preferrably with simple reproduction recipes (IE "run svk status on this
> directory, and memory usage will go up to 50 billion gigabytes"),
On Wed, 2005-11-23 at 09:39 +0100, Arnaud Charlet wrote:
> > Most svn side operations create subpools for loops that may allocate
> > per-iteration memory due to calls to other functions, etc, and clear it
> > each iteration to avoid such per iteration allocations become too large.
> > Some don't.
On Fri, 2005-11-25 at 12:59 -0500, Kaveh R. Ghazi wrote:
> > > > > Actually, i just removed the need for most stat calls during
> > > > > update in 1.4.
> > > >
> > > > Thanks Dan, that's great, but for the remaining i/o calls, it
> > > > really does matter if you use long/paths/with/lots/of
On Sat, 2005-11-26 at 02:14 +, shreyas krishnan wrote:
> Hi
> I am trying to understand the workings of alias analysis and why
> it behaves it a particular way. I am using the alias analysis branch
> of gcc4.0
>
> I find that for the following snippet of code
> main(
On Sun, 2005-11-27 at 11:58 -0800, Devang Patel wrote:
> > >
> > > With our limited resources, we cannot really afford to go off on a
> > > multi-year tangent nurturing and growing a new technology just to add
> > > a
> > > new feature.
> > >
> > What makes you think implementing LTO from scratch i
on-weak symbol
> only to find out there's obviously no such thing).
That's not right. At least glibc's ld.so has not done this by default
in years; only if you export LD_DYNAMIC_WEAK=1. Weak defs are treated
exactly the same as strong defs during dynamic lookup, by default.
--
le benchmark then adding it to "make check"
> probably isn't going to give much useful data.
I think the only _feasible_ way to do this would be with cycle counting
i.e. simulators, and the _usefulness_ of the available simulators for
performance on today's hardware is probably too limited.
--
Daniel Jacobowitz
CodeSourcery, LLC
anyone actively working on
> that? (We're not...)
>
> So, I'm afraid we're going to end up going in the other order, unless
> someone steps up to do the libgcc move shortly.
Well, I've been talking about doing this for so long that I feel I must
take this as a challenge... I will give it a shot.
--
Daniel Jacobowitz
CodeSourcery, LLC
down smaller, which
> is likely to be helpful to the folk that actually need it.
Before we actually do replace fp-bit, if this is the primary
differentiator between the two, I'd like to see numbers. I'd rather
have rounding/exception support available if the performance and size
cost is acceptable.
--
Daniel Jacobowitz
CodeSourcery, LLC
On Tue, 2005-11-29 at 22:08 +0100, Richard Guenther wrote:
> The patch below teaches points-to analysis about restrict qualifiers
> of incoming parameters. It is modeled after the special handling
> of malloc result type pointers, namely creating fake variables we
> point to and thus trigger creat
ly the fixes for the Ada problems).
Yes, I'm going to depend on --enable-bootstrap for this. And continue
using files from the GCC directory; we can wean our way out of that
incrementally.
--
Daniel Jacobowitz
CodeSourcery, LLC
On Wed, 2005-11-30 at 02:01 -0700, Jeffrey A Law wrote:
> I just tried to check in a change on the 4.1 branch. I get this
> nice little message :
>
> svn: Commit failed (details follow):
> svn: Authorization failed
> svn: Your commit message was left in a temporary file:
> svn:'/fuel98/export
On Wed, 2005-11-30 at 16:49 +0100, Gunther Nikl wrote:
> On Wed, Nov 23, 2005 at 03:32:57PM +0100, Jakub Jelinek wrote:
> > While doing svn diff, I've noticed
> > gcc/config/i386/xm-dgux.h
> > gcc/config/i386/xm-sysv3.h
> > gcc/config/i386/xm-sun.h
> > gcc/config/i386/scodbx.h
> > files popped out
On Wed, 2005-11-30 at 14:53 -0800, Mike Stump wrote:
> On Nov 30, 2005, at 7:49 AM, Gunther Nikl wrote:
> > There seem to be more conversion glichtes. I retrieved gcc-2_95-branch
> > from the svn repository and diffed it with my CVS checkout. The diff
> > contained lots of differences.
> > Many fil
This case looks like this:
typedef struct
{
unsigned char a : 2;
unsigned char b : 3;
unsigned char c : 1;
unsigned char d : 1;
unsigned char e : 1;
} a_struct;
foo (flags)
a_struct *flags;
{
return (flags->c != 0
|| flags->d != 1
|| flags->e != 1
On Wed, 2005-12-07 at 21:55 -0700, Roger Sayle wrote:
> Hi Dan,
>
> On Wed, 7 Dec 2005, Daniel Berlin wrote:
> > This is *already* wrong, AFAICT, because reg:QI 58 is uninitialized, and
> > we are trying to use it's value. Why do we do this?
>
> This may have bee
On Wed, 2005-12-14 at 14:17 -0500, Domagoj D wrote:
> Hi,
>
> Could anyone recommend a good reference (paper/book/webpage/...)
> about the "bag of pages" GC algorithm used in GCC?
There is none, AFAIK.
> Also, is there
> any document about the specifics of GCC implementation (besides
> GCC Inter
On Wed, 2005-12-14 at 15:21 -0500, Domagoj D wrote:
> Hi Daniel,
>
> > > Could anyone recommend a good reference (paper/book/webpage/...)
> > > about the "bag of pages" GC algorithm used in GCC?
> > There is none, AFAIK.
>
> Argh, how am I
tion did not
> seem to have this option in it -- at least not in the section dealing
> with command line options
> for the CPP.
>
> Any ideas where it might have gone? Is it an "internal" option?
It is only supported by Apple's compiler, not part of the FSF
On Thu, 2005-12-15 at 00:48 +0100, Steven Bosscher wrote:
> Hi,
>
> Someone caused a >10% compile time regression yesterday for CSiBE, see
> http://www.csibe.org/draw-diag.php?branchid=mainline&flags=-Os&rel_flag=--none--&dataview=Timeline&finish_button=Finish&draw=sbs&view=1&basephp=l-sbs
>
>
>
make unstage".
stage/unstage should be harmless between builds and a new invocation of
make should generally force the correct state, so it's safe to adjust
them as necessary.
> 2005-12-15 Paolo Bonzini <[EMAIL PROTECTED]>
>
> * Makefile.tpl (all, do-[+make
On Thu, 2005-12-15 at 19:01 +0100, Giovanni Bajo wrote:
> Andrew Pinski <[EMAIL PROTECTED]> wrote:
>
> > In previous versions of GCC before yesterday, "make all" used to do a
> > normal build
> > but now I am getting a full bootstrap which is not what I wanted as I
> > was just testing
> > objecti
level - hopefully along
with the gcc-provided include files - then gcc can be a pure host
directory, and we won't need to worry about this.
--
Daniel Jacobowitz
CodeSourcery, LLC
free is free?
>
> If gmane is free, please supply me a set of the source code to the gmane
> application, so that I can modify it and use it for my own purposes.
http://gmane.org/dist.php
The bits I checked were under the GPL.
--
Daniel Jacobowitz
CodeSourcery, LLC
would get (gcc-4_1-branch revision 108596 modified) or
> (gcc-4_1-branch revision 108596 clean)
I think we already had this discussion and decided that svn status took
too long in many cases.
--
Daniel Jacobowitz
CodeSourcery, LLC
Exactly what I was suggesting - we can run stage1/gcc, though, which
will make it real obvious in the logs which stage we're building.
--
Daniel Jacobowitz
CodeSourcery, LLC
oplevel* directory, "make all-stage1". I
> can rename it to "make restage1" if people care enough, but I think the
> new name fits more the toplevel Makefile's naming of targets (where you
> have all-host, all-target, etc.).
What we really need is more documentation in the top-level Makefile
about the available targets and what they do, I think.
--
Daniel Jacobowitz
CodeSourcery, LLC
TAGE1_FLAGS_TO_PASS for the recursive
invocation (in which case, this probably applies to all the other
targets, too).
--
Daniel Jacobowitz
CodeSourcery, LLC
On Fri, 2005-12-16 at 08:45 -0500, Daniel Jacobowitz wrote:
> On Fri, Dec 16, 2005 at 09:35:22AM +0100, Paolo Bonzini wrote:
> > H. J. Lu wrote:
> > >How can I rebuild stage 1 compiler with the system compiler? I used
> > >to be able to do
> > >
> >
On Fri, 2005-12-16 at 11:27 -0800, Chris Lattner wrote:
> On Dec 16, 2005, at 11:15 AM, Mark K. Smith wrote:
> > Additionally to the obstacles to adopt LLVM mentioned by Diego, I
> > named usage of C++ (although it has advantages too) and patents. LLVM
> > should be checked for usage of compiler pa
On Fri, 2005-12-16 at 12:01 -0800, Chris Lattner wrote:
> On Dec 16, 2005, at 11:47 AM, Daniel Berlin wrote:
>
> > On Fri, 2005-12-16 at 11:27 -0800, Chris Lattner wrote:
> >> On Dec 16, 2005, at 11:15 AM, Mark K. Smith wrote:
> >>> Additionally to the obstacles
s online again.
Before you go ahead with that, please check with overseers@; they
(Frank in particular) have been setting up a new search engine for the
list archives all last week.
--
Daniel Jacobowitz
CodeSourcery, LLC
is letting target libraries be bootstrapped instead of
the huge amount of cruft we have inside the gcc directory to handle
libgcc.
They've continued working for "decades" because up until now, no one's
been brave enough to try to rework them :-)
--
Daniel Jacobowitz
CodeSourcery, LLC
sions of bootstrapping.
We're investigating losing the configure option. But if you insist
that you must continue to run 'make' in the gcc subdirectory, you won't
get a bootstrap, just a rebuild of the current stage.
--
Daniel Jacobowitz
CodeSourcery, LLC
platforms; try it and see
:-) My guess is that you're using a shell that does not set the
environment variable 'PWD', or sets it to a canonicalized path; see
libiberty/getpwd.c.
I've been considering disabling ln -s support. It's too fragile,
though this is the first report of it actually failing I've seen by
email; someone mentioned similar problems on IRC.
Paolo, what do you think?
--
Daniel Jacobowitz
CodeSourcery, LLC
ould have to recurse to the parent directory, which is then
going to rename your current directory and do bits elsewhere, in other
directories; it's likely to leave you far away from the results of your
make. Do you really think that'll leave you any less confused? I'd be
baffled! I hate it when things rename my $PWD.
--
Daniel Jacobowitz
CodeSourcery, LLC
(From http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01283.html)
This patch is okay.
(Though please try to watch the sniping in the future, there is no need
to be uncivil).
r directory renames (and it looks like we'll have to switch
back to only via directory renames) one of these is obj/gcc and another
is obj/prev-gcc at any given time.
--
Daniel Jacobowitz
CodeSourcery, LLC
t decision, and move all the files around instead.
That wouldn't change the need to hand off to the top level in order to
do bootstraps though; the routines in gcc would be just for
convenience. A bootstrap would need to build top level versions of
helper tools and libraries.
--
Daniel Jacobowitz
CodeSourcery, LLC
t I think it would be smarter
to avoid the dependence; POSIX is pretty clear on the allowed
canonicalizations of $PWD, but the definition is twisty enough that I'm
sure some shells get it wrong.
--
Daniel Jacobowitz
CodeSourcery, LLC
x27;t
fail. The path that matters is not one ever returned by PWDCMD but the
one seen in $PWD by GCC; the only cd that's happened at that point is
done in the shell, by the toplevel Makefile, into 'gcc'.
--
Daniel Jacobowitz
CodeSourcery, LLC
On Tue, Dec 20, 2005 at 03:52:23PM +0100, Paolo Bonzini wrote:
> So, the AIX makefile fragments config/mh-ppc-aix and config/mt-ppc-aix
> could not just do
>
> ADAFLAGS += -mminimal-toc
> ADAFLAGS_FOR_TARGET += -mminimal-toc
We can't use += in the top level, can we?
-
801 - 900 of 2005 matches
Mail list logo
