Bootstrap comparison failure
Looks like the new toplevel bootstrap infrastructure broke
bootstrapping on OpenBSD. I get a bootstrap comparison which is
caused by differences in the compilation directory encoded in the
object files from different stages.
Forcing the coplevel configure to use "mv" instead of "ln -s" by setting
gcc_cv_prog_ln_s_dir=${gcc_cv_prog_ln_s_dir=no}
fixes things. I'm not sure what's the source for this problem, but
obviously somewhere OpenBSD is canonicalising a path where most other
OSes aren't.
This is on OpenBSD/amd64 3.8-current (for which I'm hacking up GCC
support right now), but no doubt this won't be different on other
OpenBSD ELF platforms, such as OpenBSD/i386.
Based on what I see on OpenBSD I fail to understand how the "ln -s"
approach could ever work on any OS. Assuming that I'm not the only
one trying to bootstrap GCC, I'm obviously missing something, so any
hints would be appreciated.
Mark
Re: What happend to bootstrap-lean? (was: What happened to bubblestrap?)
Because the whole point of this process is to remove all the bootstrap logic from the gcc subdirectory, which is exactly where it doesn't belong. This will let us take major steps forward in our build process How does *removing* something take major steps forward? The "whole bootstrap logic" you are talking about is 30 lines, if that. If we want a better process (and I certainly agree we do with respect to libraries), indeed adding a top-level bootstrap process is appropriate. By why delete what's there and works fine? "If it ain't broke, don't fix it!" is very prudent engineering and very much applies here. I feel very strongly that: (1) If all I want to do is a bootstrap, I should be able to do that bootstrap without having to reconfigure, maintain separate directories, rebuild files I've already built, or any other such kludge. (2) It should be straightforward to write a build script that works with all versions of GCC. It's important to keep in mind that many of us, especially those supporting customers that use GCC, have to maintain many build directories, for multiple targets and versions of GCC. Having vastly different procedures to use in different directories is a real pain. At a minimum, there needs to be some compatibility mode to support the older procedures.
Re: PR25413 - data alignment question
Richard Guenther <[EMAIL PROTECTED]> wrote on 15/12/2005 14:52:27:
> On 12/15/05, Dorit Naishlos <[EMAIL PROTECTED]> wrote:
>
> > So, in short - when can we assume that pointer types have the minimum
> > alignment required by their underlying type?
>
> I think the C standard always guarantees this.
As far as I saw in the C standard, if you convert a pointer to a type to a
pointer to a different type and the resulting pointer is not correctly
aligned for the pointed-to type, then the behavior is undefined. Can we
conclude from that the behavior of un-naturally-aligned pointers in general
is undefined (even when it's not a result of unsafe casts)?
> Of course with packed
> structs or malicious users this is not always true but may (at least in
> the case of malicious users) be invoking unspecified behavior.
>
Does the testcase in PR25413 fall into the category of "malicious users"?
This is the relevant code snippet from the testcase:
===
struct oct_tt;
typedef struct oct_tt oct_t;
typedef unsigned int var_t;
typedef enum {
OCT_EMPTY = 0,
OCT_NORMAL = 1,
OCT_CLOSED = 2
} oct_state;
struct oct_tt {
var_t n;
int ref;
oct_state state;
struct oct_tt* closed;
num_t* c;
};
oct_t*
octfapg_universe (const var_t n)
{
oct_t* m;
size_t i, nn = (2*(size_t)(n)*((size_t)(n)+1));
m = octfapg_alloc(n);
for (i=0;ic+i) = num__infty;## <-- the loop
.
return m;
}
When we vectorize the loop above, we assume that the dataref *(m->c+i),
which is of type double, is aligned on size of double, whereas it turns out
that on some targets it isn't. What did the user do wrong here? (there are
no bad type casts, or even usage of attribute "packed").
And what is GCC's policy w.r.t packed-structs? are we not guaranteeing to
compile references to fields of packed-structs correctly when they violate
natural-alignment? (as in this testcase:
http://gcc.gnu.org/viewcvs/branches/apple-local-200502-branch/gcc/testsuite/gcc.dg/vect/vect-align-1.c?rev=108214&view=markup)
My concern is that these testcases are handled correctly by GCC if
vectorization is not enabled. Is it just "accidental" that the unvectorized
code provides the expected behavior, or is the vectorizer making an
assumption it shouldn't be making?
thanks,
dorit
> Richard.
Re: PR25413 - data alignment question
On 12/18/05, Dorit Naishlos <[EMAIL PROTECTED]> wrote:
> Richard Guenther <[EMAIL PROTECTED]> wrote on 15/12/2005 14:52:27:
>
> > On 12/15/05, Dorit Naishlos <[EMAIL PROTECTED]> wrote:
> >
> > > So, in short - when can we assume that pointer types have the minimum
> > > alignment required by their underlying type?
> >
> > I think the C standard always guarantees this.
>
> As far as I saw in the C standard, if you convert a pointer to a type to a
> pointer to a different type and the resulting pointer is not correctly
> aligned for the pointed-to type, then the behavior is undefined. Can we
> conclude from that the behavior of un-naturally-aligned pointers in general
> is undefined (even when it's not a result of unsafe casts)?
>
> > Of course with packed
> > structs or malicious users this is not always true but may (at least in
> > the case of malicious users) be invoking unspecified behavior.
> >
>
> Does the testcase in PR25413 fall into the category of "malicious users"?
> This is the relevant code snippet from the testcase:
>
> ===
> struct oct_tt;
> typedef struct oct_tt oct_t;
> typedef unsigned int var_t;
> typedef enum {
> OCT_EMPTY = 0,
> OCT_NORMAL = 1,
> OCT_CLOSED = 2
> } oct_state;
> struct oct_tt {
> var_t n;
> int ref;
> oct_state state;
> struct oct_tt* closed;
> num_t* c;
> };
>
> oct_t*
> octfapg_universe (const var_t n)
> {
> oct_t* m;
> size_t i, nn = (2*(size_t)(n)*((size_t)(n)+1));
> m = octfapg_alloc(n);
> for (i=0;ic+i) = num__infty;## <-- the loop
> .
> return m;
> }
>
>
> When we vectorize the loop above, we assume that the dataref *(m->c+i),
> which is of type double, is aligned on size of double, whereas it turns out
> that on some targets it isn't. What did the user do wrong here? (there are
> no bad type casts, or even usage of attribute "packed").
The ABI may specify that the required alignment for a type is less than
its size. In fact, for things like 8 byte double it's quite common to do this
on a 32bit target. We must have this information accessible somewhere
from the backends, but I can't find a target hook or def for it at the
moment. The C standard does not guarantee alingment >= type size,
but you can usually count on it for all types <= pointer size.
Richard.
> And what is GCC's policy w.r.t packed-structs? are we not guaranteeing to
> compile references to fields of packed-structs correctly when they violate
> natural-alignment? (as in this testcase:
> http://gcc.gnu.org/viewcvs/branches/apple-local-200502-branch/gcc/testsuite/gcc.dg/vect/vect-align-1.c?rev=108214&view=markup)
>
>
> My concern is that these testcases are handled correctly by GCC if
> vectorization is not enabled. Is it just "accidental" that the unvectorized
> code provides the expected behavior, or is the vectorizer making an
> assumption it shouldn't be making?
It's a difficult question, but the middle-end should either present
a reference through the struct that is packed (so you can check this
attribute), or marking a pointer indirection with UNALIGNED_INDIRECT_REF
(or whatever it is called). The problem is again that we don't track
proper alignment information in our types.
Richard.
> thanks,
> dorit
>
>
> > Richard.
>
>
Build successful for GCC 3.2.2 on FC4, or backward bootstrap compatibility
I recently had to build gcc 3.2.2 on an FC4 box. This failed using gcc 4.0.2 as the bootstrap compiler since gcc 3.2.2 uses no-longer-accepted extensions. So I built gcc 3.4.5 using 4.0.2, and used that to bootstrap 3.2.2. Now, if it is part of the release criteria that release N-1 must be buildable with release N, then it worked well. If not, I'd like to suggest that it be added, as it makes building older gcc releases possible (though perhaps lengthy). Avi -- error compiling committee.c: too many arguments to function
Re: What happend to bootstrap-lean? (was: What happened to bubblestrap?)
On Sun, Dec 18, 2005 at 08:28:13AM -0500, Richard Kenner wrote: > Because the whole point of this process is to remove all the bootstrap > logic from the gcc subdirectory, which is exactly where it doesn't > belong. This will let us take major steps forward in our build process > > How does *removing* something take major steps forward? The "whole > bootstrap logic" you are talking about is 30 lines, if that. This shows pretty clearly that you haven't looked at it - the basic bootstrap targets are about 10% of gcc/Makefile.in, which is rather more than 30 lines. > If we want a better process (and I certainly agree we do with respect to > libraries), indeed adding a top-level bootstrap process is appropriate. By > why delete what's there and works fine? "If it ain't broke, don't fix it!" > is very prudent engineering and very much applies here. It's not prudent engineering when you suddenly discover you have to maintain two fragile ways of doing something instead of just one. The GCC build process is ridiculously rich and has a ridiculous number of vaguely "user-tunable" knobs, e.g. about six ways to specify what assembler the compiler is going to use. The more complicated your needs, the less likely they are to continue to work. ./configure && make bootstrap is going to continue working, presumably forever. > It's important to keep in mind that many of us, especially those supporting > customers that use GCC, have to maintain many build directories, for multiple > targets and versions of GCC. Having vastly different procedures to use in > different directories is a real pain. At a minimum, there needs to be some > compatibility mode to support the older procedures. Any such build script - we've got plenty of our own here, thanks - grows little widgets over time to handle particular configurations and particular versions of GCC, in my experience. Paolo's already explained how to handle both old and new versions 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
Re: Bootstrap comparison failure
On Sun, Dec 18, 2005 at 01:28:48PM +0100, Mark Kettenis wrote:
> Looks like the new toplevel bootstrap infrastructure broke
> bootstrapping on OpenBSD. I get a bootstrap comparison which is
> caused by differences in the compilation directory encoded in the
> object files from different stages.
>
> Forcing the coplevel configure to use "mv" instead of "ln -s" by setting
>
> gcc_cv_prog_ln_s_dir=${gcc_cv_prog_ln_s_dir=no}
>
> fixes things. I'm not sure what's the source for this problem, but
> obviously somewhere OpenBSD is canonicalising a path where most other
> OSes aren't.
>
> This is on OpenBSD/amd64 3.8-current (for which I'm hacking up GCC
> support right now), but no doubt this won't be different on other
> OpenBSD ELF platforms, such as OpenBSD/i386.
>
> Based on what I see on OpenBSD I fail to understand how the "ln -s"
> approach could ever work on any OS. Assuming that I'm not the only
> one trying to bootstrap GCC, I'm obviously missing something, so any
> hints would be appreciated.
I'm sure you have access to some non-OpenBSD 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
Re: What happend to bootstrap-lean? (was: What happened to bubblestrap?)
This shows pretty clearly that you haven't looked at it - the basic bootstrap targets are about 10% of gcc/Makefile.in, which is rather more than 30 lines. You're right that I hadn't looked recently and it has indeed grown. Certainly more than 30 lines, but not quite 10%: I count 375 out of 4615, which is 8%. However, large blocks of that are duplicate, for example each of the stage[123] versions, so that's not completely a fair number. The GCC build process is ridiculously rich and has a ridiculous number of vaguely "user-tunable" knobs, e.g. about six ways to specify what assembler the compiler is going to use. The more complicated your needs, the less likely they are to continue to work. Unfortunately, the people who have the most complicated needs (not me) are the ones who have the strongest requirement that they continue working. I always use the system assembler, so I don't know *any* of the ways to specify what assembler to use, but if there are indeed six, you can be sure that at least one person out there is using each of them. It's been my experience among GCC users working on large projects that build scripts tend to be treated like "black magic", written by somebody who knew the stuff and is long gone. If one of those six methods no longer works, that script will break and they won't have the foggiest idea how to fix it. Backwards compatibility is indeed expensive, but is critical. All vendors do it and we need to as well. You can be certain that if there were six ways of specifying something in VMS on a VAX in 1979, all six will still work today on all VMS targets. There's a reason for that: the users demand and expect it. ./configure && make bootstrap is going to continue working, presumably forever. I thought the whole point was that "bootstrap" wasn't a target at the top level, but just in the gcc/ directory, so that the above did *not* work. Any such build script - we've got plenty of our own here, thanks - grows little widgets over time to handle particular configurations and particular versions of GCC, in my experience. Sure, but the issue is the *size* of the differences. Are we talking about something subtle or a completely different sequence of make targets? 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. You lost me. "make" in the gcc subdirectory would always build into that directory using the system compiler (i.e., what you'd normally use to build the stage1 compiler), not do a bootstrap. It was "make bootstrap" that would continue the bootstrap from the current location. In my experience, the four most common targets in the gcc subdirectory were: , as above bootstrap, as above compare, the obvious unstage1, to undo a "make bootstrap" I think those four targets need to keep working because they are also the oldest targets. I certainly agree that it's reasonable to change the way that the lesser-used targets are executed, so long as there's a clearly-documented mapping. However, I also don't see why we can't simply put that target into gcc/Makefile.in to simply recursively execute the make with the equivalent target. That does not have the maintenance burden you suggest above.
Re: What happend to bootstrap-lean? (was: What happened to bubblestrap?)
On Sun, Dec 18, 2005 at 12:12:17PM -0500, Richard Kenner wrote: > Backwards compatibility is indeed expensive, but is critical. All vendors > do it and we need to as well. You can be certain that if there were six > ways of specifying something in VMS on a VAX in 1979, all six will still > work today on all VMS targets. There's a reason for that: the users demand > and expect it. I am perfectly willing to maintain backwards compatibility for _users_ of GCC. Most users of GCC don't build GCC, and most builders of GCC really don't use the full expressiveness of the build system. I disagree with the assertion that we need to maintain "compatibility" in our Makefiles. Obviously we want to in as much as it is practical; this isn't. And don't you think that talking about compatibility expected by our users is just a little bit disingenuous, when you're talking about running make inside the gcc subdirectory? Users don't do that! Only developers of GCC do. It's only useful for incremental builds; a full build of GCC always starts and ends in the top level. > ./configure && > make bootstrap is going to continue working, presumably forever. > > I thought the whole point was that "bootstrap" wasn't a target at the top > level, but just in the gcc/ directory, so that the above did *not* work. Huh? Are you talking about before, or after, the changes? "bootstrap" has always been a target at the top level. It used to be implemented by building a bunch of other stuff and then forwarding to a bootstrap target in the gcc subdirectory and then building another bunch of stuff, but is no longer. > Any such build script - we've got plenty of our own here, thanks - > grows little widgets over time to handle particular configurations and > particular versions of GCC, in my experience. > > Sure, but the issue is the *size* of the differences. Are we talking about > something subtle or a completely different sequence of make targets? Paolo already answered this question, in a message directly to you: http://gcc.gnu.org/ml/gcc/2005-12/msg00490.html > 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. > > You lost me. "make" in the gcc subdirectory would always build into that > directory using the system compiler (i.e., what you'd normally use to build > the stage1 compiler), not do a bootstrap. It was "make bootstrap" that would > continue the bootstrap from the current location. I was referring to "make $(anything)", i.e. the command /usr/bin/make. > In my experience, the four most common targets in the gcc subdirectory were: > > , as above > bootstrap, as above > compare, the obvious > unstage1, to undo a "make bootstrap" > > I think those four targets need to keep working because they are also the > oldest targets. I certainly agree that it's reasonable to change the way > that the lesser-used targets are executed, so long as there's a > clearly-documented mapping. However, I also don't see why we can't simply > put that target into gcc/Makefile.in to simply recursively execute the make > with the equivalent target. That does not have the maintenance burden you > suggest above. Because it would 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
Re: [patch] for PR24793
(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).
Re: What happend to bootstrap-lean? (was: What happened to bubblestrap?)
And don't you think that talking about compatibility expected by our users is just a little bit disingenuous, when you're talking about running make inside the gcc subdirectory? Users don't do that! Only developers of GCC do. It's only useful for incremental builds; a full build of GCC always starts and ends in the top level. Sorry: my comment on that topic was directed at your comment about there being six ways to specify the assembler to use, not about building inside the gcc subdirctory. My point was that whatever we did, we needed to make sure we retained those six ways. You can always "simplify" if you're willing to sacrifice backwards compatibility, but I don't think we should do that. Because it would have to recurse to the parent directory, Why do you have to recurse to the parent directory to bootstrap GCC? If the desire was to make pieces elsewhere, the command would have been issued from elsewhere. I'm talking about bootstrapping the compiler, nothing else. Sure, there's a value in doing a bootstrap including the libraries, but there's also a value in *not* doing it. which is then going to rename your current directory Why would a makefile rename a directory in any situation? That seems like trouble waiting to happen to me.
Re: What happend to bootstrap-lean? (was: What happened to bubblestrap?)
On Sun, Dec 18, 2005 at 01:01:11PM -0500, Richard Kenner wrote: > Because it would have to recurse to the parent directory, > > Why do you have to recurse to the parent directory to bootstrap GCC? > If the desire was to make pieces elsewhere, the command would have been > issued from elsewhere. I'm talking about bootstrapping the > compiler, nothing else. Sure, there's a value in doing a bootstrap > including the libraries, but there's also a value in *not* doing it. > > which is then going to rename your current directory > > Why would a makefile rename a directory in any situation? That seems like > trouble waiting to happen to me. > The answer to both of these questions is the same. Toplevel bootstrap deliberately - as a design decision, and in my opinion, a very good one - puts every stage in its own directory. Instead of trying to move all the object files we're staging into a subdirectory, each stage of gcc is built in its own directory. This lets us not have to guess which files need to be moved and which (e.g. generated by configure) need to be left alone. For GCC we already knew what this list is, by exhaustive trial and error. For other directories, however, we don't want to have to work it out. It lets the bootstrap mechanism be more modularly independent of the components being bootstrapped. Therefore, you get obj/stage1-gcc and obj/stage2-gcc. And via either symlinks or 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
Re: What happend to bootstrap-lean? (was: What happened to bubblestrap?)
The answer to both of these questions is the same. Toplevel bootstrap deliberately - as a design decision, and in my opinion, a very good one - puts every stage in its own directory. Of course: we've always had each stage living in a different directory. You're not going to get any disagreement there. My question was why you have to go *up*. Unless you're rebuilding a library outside the gcc/ directory, all the stages can be in subdirectories of that directory. Instead of trying to move all the object files we're staging into a subdirectory, each stage of gcc is built in its own directory. I'm not sure I see the difference there, but OK, as long as it doesn't complicate anything else. This lets us not have to guess which files need to be moved and which (e.g. generated by configure) need to be left alone. For GCC we already knew what this list is, by exhaustive trial and error. As you say, we know it, so it "ain't broken". That list is only very rarely changed, but if there's a concern about maintaining it, I think the straightforward approach is to take the very few things that *are* to be left alone and put them in a directory of their own. Then you can copy everything in the build directory into a stage directory. So you have ., where things are built, ./invar, which are the things that are kept the same through the process, and ./stage[123], which is where the built stages are put. For other directories, however, we don't want to have to work it out. It lets the bootstrap mechanism be more modularly independent of the components being bootstrapped. Here you've lost me completely. When you say "bootstrap", I interpret that as meaning using X to build another copy of X from sources enough times so that you can compare successive versions and expect them to be the same. But what else is there in the gcc tree that can be used to build itself? So what's to be made "independent"? Therefore, you get obj/stage1-gcc and obj/stage2-gcc. And via either symlinks or 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. What's wrong with the present obj/gcc/stage1 and obj/gcc/stage2? As I said, I think renaming directories is going to cause no end of problems (having directories be renamed under people is just one example). What's the benefit? Before we made "make bootstrap" restart in the beginning, the Makefile was able to keep track internally of what it was up to. More recently, we used a file that stays where we are. What's so wrong with that approach that justifies renaming directories? Can't those two states (current and previous) just be variables in the Makefile that it imports from some status file?
Re: What happend to bootstrap-lean? (was: What happened to bubblestrap?)
On Sun, Dec 18, 2005 at 01:25:36PM -0500, Richard Kenner wrote: > The answer to both of these questions is the same. Toplevel bootstrap > deliberately - as a design decision, and in my opinion, a very good > one - puts every stage in its own directory. > > Of course: we've always had each stage living in a different directory. > You're not going to get any disagreement there. My question was why you have > to go *up*. Unless you're rebuilding a library outside the gcc/ directory, > all the stages can be in subdirectories of that directory. No, that's not at all what we do today. We build everything in gcc/ and shuffle the files off to other directories depending on the current stage. In the revised model, the stages are completely independent; the directories have nothing in common. > For other directories, however, we don't want to have to work it out. > It lets the bootstrap mechanism be more modularly independent of the > components being bootstrapped. > > Here you've lost me completely. When you say "bootstrap", I interpret that > as meaning using X to build another copy of X from sources enough times so > that you can compare successive versions and expect them to be the same. But > what else is there in the gcc tree that can be used to build itself? So > what's to be made "independent"? No! This is the old model of bootstrap: rebuild gcc a bunch of times with itself. The top level bootstrap model is to rebuild all the useful bits of the entire tree as a group; and repeat that as many times as necessary to be able to compare them. We bootstrap everything used in the build process. Some example consequences of this: We used to have some workarounds in the libcpp-to-gcc interface to work around the fact that we built libcpp once, with the system compiler, and then linked it to each stage of the bootstrap. Darwin had a system compiler that disagreed with the FSF GCC on the size of _Bool, I believe. Now we build the stage1 libcpp with the system compiler, build the stage1 gcc with the system compiler, link them together, and go on to build the stage2 libcpp with the stage1 gcc. We can bootstrap the assembler in a combined tree. The first stage's gcc will invoke a stage1 assembler, the second stage's gcc will invoke a stage2 assembler. This doesn't have any fundamental benefits except for thoroughness; it's an even better sanity check. Eventually I expect we'll have at least one frontend written in C++. We'll be able to build that frontend using a bootstrapped copy of libstdc++. > What's wrong with the present obj/gcc/stage1 and obj/gcc/stage2? As I said, > I think renaming directories is going to cause no end of problems (having > directories be renamed under people is just one example). What's the > benefit? Before we made "make bootstrap" restart in the beginning, the > Makefile was able to keep track internally of what it was up to. More > recently, we used a file that stays where we are. What's so wrong with that > approach that justifies renaming directories? Can't those two states > (current and previous) just be variables in the Makefile that it imports > from some status file? It was an implementation decision to use obj/stage1-gcc instead of obj/gcc/stage1, so that (A) we didn't have to move every individual file around, and (B) we knew, robustly, that each stage's build would be completely separate from the previous stage's (no way to leave stray files behind, since the directory is created from scratch). Personally, I think this layout (which I did not pick) is superior. It makes it far more difficult to accidentally mix stages. We could change that 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
Re: Bootstrap comparison failure
> Date: Sun, 18 Dec 2005 11:49:37 -0500
> From: Daniel Jacobowitz <[EMAIL PROTECTED]>
>
> On Sun, Dec 18, 2005 at 01:28:48PM +0100, Mark Kettenis wrote:
> > Looks like the new toplevel bootstrap infrastructure broke
> > bootstrapping on OpenBSD. I get a bootstrap comparison which is
> > caused by differences in the compilation directory encoded in the
> > object files from different stages.
> >
> > Forcing the coplevel configure to use "mv" instead of "ln -s" by setting
> >
> > gcc_cv_prog_ln_s_dir=${gcc_cv_prog_ln_s_dir=no}
> >
> > fixes things. I'm not sure what's the source for this problem, but
> > obviously somewhere OpenBSD is canonicalising a path where most other
> > OSes aren't.
> >
> > This is on OpenBSD/amd64 3.8-current (for which I'm hacking up GCC
> > support right now), but no doubt this won't be different on other
> > OpenBSD ELF platforms, such as OpenBSD/i386.
> >
> > Based on what I see on OpenBSD I fail to understand how the "ln -s"
> > approach could ever work on any OS. Assuming that I'm not the only
> > one trying to bootstrap GCC, I'm obviously missing something, so any
> > hints would be appreciated.
>
> I'm sure you have access to some non-OpenBSD 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.
Heh, the shell does set PWD, but does not export it. If I explicitly
say "export PWD", before "make bootstrap" it seems to work.
> 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.
Don't know how many broken shells are out there. Actually, I don't
think the OpenBSD sh(1) is broken, at least not according to POSIX.
Is explicitly exporting PWD at an appropriate point an option?
Mark
Re: What happend to bootstrap-lean? (was: What happened to bubblestrap?)
On Dec 18, 2005, at 1:40 PM, Daniel Jacobowitz wrote: We used to have some workarounds in the libcpp-to-gcc interface to work around the fact that we built libcpp once, with the system compiler, and then linked it to each stage of the bootstrap. Darwin had a system compiler that disagreed with the FSF GCC on the size of _Bool, I believe. Now we build the stage1 libcpp with the system compiler, build the stage1 gcc with the system compiler, link them together, and go on to build the stage2 libcpp with the stage1 gcc. No it was not Darwin (this is one of the places where the FSF GCC is correct with respect of Darwin), but instead using 2.95.3 to bootstrap. When you started with 2.95.3, bool (as stdbool.h was included with 2.95.3) was an int. -- Pinski
Re: long double on ppc-darwin
On Dec 17, 2005, at 10:27 PM, Andrew Pinski wrote: On Dec 18, 2005, at 1:13 AM, Geoff Keating wrote: Yes; to do this right, GCC's builtins need to know about the different names. If you're interested in fixing this, I can tell you what to do... I figured out how to fix it and will be posting a patch later this week. but a function like: Yes, looks about right to me, the only modification would be testing 128 bit long double flag (TARGET_LONG_DOUBLE_128) and be aware, this is a ppc only thang. And then go through all the builtins which need to be fixed. If there are functions which aren't built in that are also modified, I'm not sure what we should do with them. Thoughts? If nothing, how do we know that they aren't used now and how do we be sure they won't be used in the future?
Re: Bootstrap comparison failure
On Sun, Dec 18, 2005 at 07:49:13PM +0100, Mark Kettenis wrote: > Heh, the shell does set PWD, but does not export it. If I explicitly > say "export PWD", before "make bootstrap" it seems to work. Weird. > > 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. > > Don't know how many broken shells are out there. Actually, I don't > think the OpenBSD sh(1) is broken, at least not according to POSIX. > Is explicitly exporting PWD at an appropriate point an option? It's listed as an environment variable; I would have expected that to mean it was exported, but I'm not willing to call it broken. We could probably arrange an appropriate export, but 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
Re: What happend to bootstrap-lean? (was: What happened to bubblestrap?)
Daniel Jacobowitz <[EMAIL PROTECTED]> writes: [...] | We can bootstrap the assembler in a combined tree. The first stage's | gcc will invoke a stage1 assembler, the second stage's gcc will invoke | a stage2 assembler. This doesn't have any fundamental benefits except | for thoroughness; it's an even better sanity check. And that is a good thing to have. -- Gaby
i was told that i could get a awnser to this question here.
i use the gentoo flavor of linux and a recent install method has become popular there. i myself have not done this and i do doubt the usefulness of it but i want to check with the people who would know the most about the basic tool-chain as it is called. this is the install method http://forums.gentoo.org/viewtopic-t-400576.html it basically involves compiling the gcc compiler not once but up to 3 times in a row as well as other programs considered part of the tool chain. they claim that this method makes the system rock stable and faster, are they telling the truth?
Re: long double on ppc-darwin
On 18/12/2005, at 10:57 AM, Mike Stump wrote: On Dec 17, 2005, at 10:27 PM, Andrew Pinski wrote: On Dec 18, 2005, at 1:13 AM, Geoff Keating wrote: Yes; to do this right, GCC's builtins need to know about the different names. If you're interested in fixing this, I can tell you what to do... I figured out how to fix it and will be posting a patch later this week. but a function like: Yes, looks about right to me, the only modification would be testing 128 bit long double flag (TARGET_LONG_DOUBLE_128) and be aware, this is a ppc only thang. You also need to be sure to test macos_version_min. If you're compiling to target < 10.3.9, then you need to make sure to use the original version of at least printf and the other variadic functions. And then go through all the builtins which need to be fixed. If there are functions which aren't built in that are also modified, I'm not sure what we should do with them. Thoughts? If nothing, how do we know that they aren't used now and how do we be sure they won't be used in the future? If you're matching by name, you might as well have all the names. But either way, the list would need to be maintained, since the OS might add more functions in future versions. smime.p7s Description: S/MIME cryptographic signature
Re: What happend to bootstrap-lean? (was: What happened to bubblestrap?)
The top level bootstrap model is to rebuild all the useful bits of the entire tree as a group; and repeat that as many times as necessary to be able to compare them. Please define "useful". I'm very concerned if we're doing more builds than before and don't have a way to restrict the builds to what we were doing previously since it slows down the development process, especially for those people still on slower machines. A bootstrap has a very precise purpose: you want to ensure that when you install a new compiler, you won't lose the ability to recompile it. So we ensure that everything that *has* to be compiled in order to build the compiler is. As we extend that to ancilary pieces we're rapidly getting into a process of diminishing returns and when I hear that we're making it *easy* to keep adding pieces, I worry even more about bootstrap speeds in the future. We can bootstrap the assembler in a combined tree. The first stage's gcc will invoke a stage1 assembler, the second stage's gcc will invoke a stage2 assembler. This doesn't have any fundamental benefits except for thoroughness; it's an even better sanity check. Sure, but I think it should be viewed as an *additional* check, much like we currently have two tests: bootstrap and "make check". So we'd have three: a "simple" bootstrap, a complete bootstrap, and "make check". The latter two would be a requirement for check-ins, but the former would exist to be used as part of the "rough" testing process. Eventually I expect we'll have at least one frontend written in C++. We'll be able to build that frontend using a bootstrapped copy of libstdc++. Sure, but I don't see what the major gain of such a thing would be over the current set of tests for libstdc++. Aren't those tests much more exhaustive a test than the usage of libstdc++ by such a front-end? Personally, I think this layout (which I did not pick) is superior. It makes it far more difficult to accidentally mix stages. I'm not sure I understand the logic of that conclusion, though I agree that the order in which the directories are named isn't a critical issue so long as the current *functionality* isn't lost. We could change that 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. Right, but it would avoid the need to rename directories and, as I said, I think that's a problem waiting to happen.
Re: How to rebuild stage 1?
On Fri, 16 Dec 2005, Richard Kenner wrote: >> A wiki page that has the mapping from the old style to the new style >> targets is appropriate. I know that I'll hit the, what is x called >> now, and I too will be at a loss. Going back and reading the email >> archives to find it would be annoying. > Strongly agreed, though once it gets finalized it should be moved from > the wiki into the main GCC documentation. Agreed. As I pointed out, both install.texi and makefile.texi, for example, still refer to `make bootstrap-lean`. User-visible changes also should be added to gcc-4.2/changes.html, which is part of our release notes. (But let's give Paolo some time to address the technical issues first; we are still in stage 1, so only developers, packagers, and brave testers are supposed to use what is going to become GCC 4.2. ;-) Gerald
[PATCH] Removed two unused vars from Makefile.tpl
The attached patch removes the unused variables BUILD_CONFIGDIRS and TARGET_CONFIGDIRS from Makefile.tpl. It also removes the AC_SUBST(target_configdirs) from configure.in. Boostraped on a GNU/Linux/x86 Rafael 2005-12-18 Rafael Ávila de Espíndola <[EMAIL PROTECTED]> * Makefile.tpl (BUILD_CONFIGDIRS): Remove (TARGET_CONFIGDIRS): Remove * configure.in: Remove AC_SUBST(target_configdirs) * Makefile.in, configure: Regenerated Index: configure === --- configure (revision 108761) +++ configure (working copy) @@ -6308,7 +6308,6 @@ [EMAIL PROTECTED]@%$build_configdirs%g [EMAIL PROTECTED]@%$host_configargs%g [EMAIL PROTECTED]@%$configdirs%g [EMAIL PROTECTED]@%$target_configargs%g [EMAIL PROTECTED]@%$target_configdirs%g [EMAIL PROTECTED]@%$CC_FOR_BUILD%g [EMAIL PROTECTED]@%$config_shell%g [EMAIL PROTECTED]@%$YACC%g Index: Makefile.in === --- Makefile.in (revision 108761) +++ Makefile.in (working copy) @@ -84,8 +84,6 @@ GDB_NLM_DEPS = # the libraries. RPATH_ENVVAR = @RPATH_ENVVAR@ -# This is the list of directories to be built for the build system. -BUILD_CONFIGDIRS = libiberty # Build programs are put under this directory. BUILD_SUBDIR = @build_subdir@ # This is set by the configure script to the arguments to use when configuring @@ -178,9 +176,6 @@ POSTSTAGE1_HOST_EXPORTS = \ -B$$r/$(HOST_SUBDIR)/prev-gcc/ \ -B$(build_tooldir)/bin/"; export CC_FOR_BUILD; -# This is set by the configure script to the list of directories which -# should be built using the target tools. -TARGET_CONFIGDIRS = @target_configdirs@ # Target libraries are put under this directory: TARGET_SUBDIR = @target_subdir@ # This is set by the configure script to the arguments to use when configuring Index: Makefile.tpl === --- Makefile.tpl (revision 108761) +++ Makefile.tpl (working copy) @@ -87,8 +87,6 @@ GDB_NLM_DEPS = # the libraries. RPATH_ENVVAR = @RPATH_ENVVAR@ -# This is the list of directories to be built for the build system. -BUILD_CONFIGDIRS = libiberty # Build programs are put under this directory. BUILD_SUBDIR = @build_subdir@ # This is set by the configure script to the arguments to use when configuring @@ -181,9 +179,6 @@ POSTSTAGE1_HOST_EXPORTS = \ -B$$r/$(HOST_SUBDIR)/prev-gcc/ \ -B$(build_tooldir)/bin/"; export CC_FOR_BUILD; -# This is set by the configure script to the list of directories which -# should be built using the target tools. -TARGET_CONFIGDIRS = @target_configdirs@ # Target libraries are put under this directory: TARGET_SUBDIR = @target_subdir@ # This is set by the configure script to the arguments to use when configuring Index: configure.in === --- configure.in (revision 108761) +++ configure.in (working copy) @@ -2081,7 +2081,7 @@ AC_SUBST(configdirs) # Target module lists & subconfigure args. AC_SUBST(target_configargs) -AC_SUBST(target_configdirs) + # Build tools. AC_SUBST(CC_FOR_BUILD)
