Re: GNU Pascal branch
Adriaan van Os <[EMAIL PROTECTED]> wrote: >> and people are >> responsible for fixing all front ends when they do backend changes. > > I don't believe that, they would just say, "oh, it is broken" or "oh, > it is not a primary language" or whatever excuse. You probably don't follow GCC development enough. Every middle-end/backend change *must* go through a full bootstrap and regression free cycle, for all active languages, either minor or major. So it should never happen that a change to the optimizer breaks the Pascal frontend. If it does, you can blame it on the person who did the change, and ask him to fix it (or revert it). This is how GCC development. Even for cases where the frontend is not active by default (eg. Ada), people are still helpful and often test and fix the Ada frontend, when the bugs are properly reported in Bugzilla. There is cooperation going on. You can often see GCC middle-end/back-end maintainers cooperating and producing patches to fix Ada bugs. >>> Also, flexibility in choosing the back-end >>> version sometimes has its advantages, dependent on the platform, >>> given the fact that reported gcc bugs are not always fixed. >> >> So you could help fix them, instead of forcing people to stick to >> older backends ;-) > > We are not forcing anybody, we offer full choice. Not fixing > backend-end bugs is what is actually forcing people. And even patches > that do fix bugs are often not accepted. There are often reasons for this. Sometimes the patches refer to bugs which are triggered by GNU pascal frontend only, and you need a way to reproduce the bug to have the patch accepted. Having the GNU pascal integrated, means that you can show a pascal testacase for the bug, have a proper PR number in Bugzilla for the issue, and thus having the patch reviewed and accepted. If you enter the full development cycle of GCC, you are making this process many times easier. Giovanni Bajo
Re: Ada subtypes and base types
Jeffrey A Law writes: > On Thu, 2006-03-30 at 18:39 +0100, Andrew Haley wrote: > > Jeffrey A Law writes: > > > On Wed, 2006-03-29 at 14:28 -0700, Tom Tromey wrote: > > > > > > > On irc today we were discussing handling 'this' in gcj. We can add an > > > > attribute to the argument to mark it as non-null... but strangely > > > > there doesn't seem to be a way to mark other local variables as > > > > known-non-null -- a curious deficiency. > > > It seems to me that for other locals that the non-null property > > > ought to be a property of how those locals are assigned a value. > > > ie, if we're going to be able to derive a non-null for a local we > > > should be able to derive it from the RHS of the assignment(s) to > > > that local. > > > > Right, that's true. The idea is that a great many library functions > > either return a valid object or throw an execption, and we can > > propagate that information to VRP> > > > > > IIRC "this" is actually a parameter and thus there's no assignment > > > we can derive information from. > > > > Mmm, yeah. The point is that we solved the problem for "this", but > > not for other things. > And I think the way to solve this is to mark those interesting > library functions, then fix VRP so that it's not so eager to ignore > function calls :-) Well, it's not just functionss but also global variables. AFAICS there are three sources of data: args, retvals, and globals. And there are quite a few of these globals we can usefully tag as "known never to be null". Andrew.
Re: Ada subtypes and base types
On Fri, 2006-03-31 at 09:55 +0100, Andrew Haley wrote: > Well, it's not just functionss but also global variables. AFAICS > there are three sources of data: args, retvals, and globals. And > there are quite a few of these globals we can usefully tag as "known > never to be null". Seems to me the same mechanism we should use for tagging functions as returning non-null values should be used to tag globals -- it's just an attribute after all. Then we just need to make VRP not be so quick to ignore statements with virtual operands (ie, the same problem we need to solve if VRP is going to be able to use non-null attributes on function return values). Jeff
Re: Type conversion and addition
> Setting TREE_OVERFLOW here sounds like the bug.
Well, it's the standard semantics of the middle-end, nothing more:
/* A subroutine of fold_convert_const handling conversions of an
INTEGER_CST to another integer type. */
static tree
fold_convert_const_int_from_int (tree type, tree arg1)
{
tree t;
/* Given an integer constant, make new constant with new type,
appropriately sign-extended or truncated. */
t = build_int_cst_wide (type, TREE_INT_CST_LOW (arg1),
TREE_INT_CST_HIGH (arg1));
t = force_fit_type (t,
/* Don't set the overflow when
converting a pointer */
!POINTER_TYPE_P (TREE_TYPE (arg1)),
(TREE_INT_CST_HIGH (arg1) < 0
&& (TYPE_UNSIGNED (type)
< TYPE_UNSIGNED (TREE_TYPE (arg1
| TREE_OVERFLOW (arg1),
TREE_CONSTANT_OVERFLOW (arg1));
return t;
}
/* T is an INT_CST node. OVERFLOWABLE indicates if we are interested
in overflow of the value, when >0 we are only interested in signed
overflow, for <0 we are interested in any overflow. OVERFLOWED
indicates whether overflow has already occurred. CONST_OVERFLOWED
indicates whether constant overflow has already occurred. We force
T's value to be within range of T's type (by setting to 0 or 1 all
the bits outside the type's range). We set TREE_OVERFLOWED if,
OVERFLOWED is nonzero,
or OVERFLOWABLE is >0 and signed overflow occurs
or OVERFLOWABLE is <0 and any overflow occurs
We set TREE_CONSTANT_OVERFLOWED if,
CONST_OVERFLOWED is nonzero
or we set TREE_OVERFLOWED.
We return either the original T, or a copy. */
tree
force_fit_type (tree t, int overflowable,
bool overflowed, bool overflowed_const)
> Or, if some front ends require it for some test cases then it should be made
> language-specific whether conversions of constants set TREE_OVERFLOW in this
> case. (For C, gcc.dg/overflow-warn-*.c should adequately cover the
> diagnostics in this area.)
I'd think it's the other way around: signed overflow should stay the norm and
languages should use a new flag to tell the middle-end that they don't want
it under certain circumstances, modelled on flag_wrapv for Java.
> In the long run, TREE_OVERFLOW should go away and fold should
> provide front ends with information about the sorts of overflow happening
> so front ends can track their own information about what counts as
> overflow in each language.
Yes, that sounds like a good plan.
Thanks for your feedback.
--
Eric Botcazou
ad ml
GCC-4.2-20060325 build failure on OpenBSD 3.9-current
Hello, I'm trying to build GCC-4.2-20060325 on OpenBSD 3.9-current, but it fails with: echo timestamp > s-gtype /home/karel/build/obj-gcc-4.2-20060325/./prev-gcc/xgcc -B/home/karel/build/obj-gcc-4.2-20060325/./prev-gcc/ -B/home/karel/usr/local/gcc-4.2-20060325/i386-unknown-openbsd3.9/bin/ -c -O2 -g -fomit-frame-pointer -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -Werror-DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I/home/karel/build/gcc-4.2-20060325/gcc -I/home/karel/build/gcc-4.2-20060325/gcc/build -I/home/karel/build/gcc-4.2-20060325/gcc/../include -I/home/karel/build/gcc-4.2-20060325/gcc/../libcpp/include -I/home/karel/build/gcc-4.2-20060325/gcc/../libdecnumber -I../libdecnumber -o build/rtl.o /home/karel/build/gcc-4.2-20060325/gcc/rtl.c /home/karel/build/obj-gcc-4.2-20060325/./prev-gcc/xgcc -B/home/karel/build/obj-gcc-4.2-20060325/./prev-gcc/ -B/home/karel/usr/local/gcc-4.2-20060325/i386-unknown-openbsd3.9/bin/ -c -O2 -g -fomit-frame-pointer -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -Werror-DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I/home/karel/build/gcc-4.2-20060325/gcc -I/home/karel/build/gcc-4.2-20060325/gcc/build -I/home/karel/build/gcc-4.2-20060325/gcc/../include -I/home/karel/build/gcc-4.2-20060325/gcc/../libcpp/include -I/home/karel/build/gcc-4.2-20060325/gcc/../libdecnumber -I../libdecnumber -o build/read-rtl.o /home/karel/build/gcc-4.2-20060325/gcc/read-rtl.c cc1: warnings being treated as errors /home/karel/build/gcc-4.2-20060325/gcc/read-rtl.c: In function 'join_c_conditions': /home/karel/build/gcc-4.2-20060325/gcc/read-rtl.c:787: warning: missing sentinel in function call gmake[3]: *** [build/read-rtl.o] Error 1 gmake[3]: Leaving directory `/home/karel/build/obj-gcc-4.2-20060325/gcc' gmake[2]: *** [all-stage2-gcc] Error 2 gmake[2]: Leaving directory `/home/karel/build/obj-gcc-4.2-20060325' gmake[1]: *** [stage2-bubble] Error 2 gmake[1]: Leaving directory `/home/karel/build/obj-gcc-4.2-20060325' gmake: *** [bootstrap-lean] Error 2 the compiler used for bootstrap is OpenBSD's gcc3.3.5. GCC 4.2 is configured with: /home/karel/build/gcc-4.2-20060325/configure --prefix=/home/karel/usr/local/gcc-4.2-20060325 --enable-shared --enable-threads --disable-checking --disable-nls --enable-languages=c,c++ and it is build with: gmake CFLAGS='-O' LIBCFLAGS='-g -O2' LIBCXXFLAGS='-g -O2 -fno-implicit-templates' bootstrap-lean If I understand this issue correctly, it seems GCC 4.2 stage1 compiler warns about missing sentinel and because of -Werror bootstrap fails. If this is true, then perhaps the same issue happen also on more supported platforms? (Linux/FreeBSD) If so, then my question is: is this already fixed on trunk? Thanks, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com
Re: Ada subtypes and base types
On 03/31/06 04:08, Jeffrey A Law wrote: > Then we just need to make VRP not be so quick to ignore statements > with virtual operands (ie, the same problem we need to solve if > VRP is going to be able to use non-null attributes on function > return values). > Certainly. The approach I had sketched out earlier should be able to accomodate all this: - The front-end encodes in a langhook the notion of non-null attribute for symbols or function return values or types. - Propagators propagate that attribute via the propagate_value helper. This attribute becomes an SSA name attribute (we need flow sensitivity), so we will need to be able to encode various attributes on SSA names (perhaps using the aux field). - VRP (and others) can pick up those propagated attributes when doing their thing.
Re: Segment registers support for i386
It would take a massive target-specific backend hack to make that happen, as GCC currently only supports flat address spaces. ;-) Rémy Saissy wrote: Hi everybody, I'm looking for gcc support of x86-32 segment registers but the only information I've found about it is in this old thread: http://gcc.gnu.org/ml/gcc/1999-12/msg00526.html I was wondering what happened since this thread, does somebody have integrated the segment register support for i386 in gcc ? There is nothing about it in the manual pages and gcc 4.0.3 doesn't seem to support it. Thank for your precisions. Have a great day. -- Rémy SaissyJabberID: [EMAIL PROTECTED] Web: http://remysaissy.free.fr "L'homme qui a le plus vécu n'est pas celui qui a compté le plus d'années, mais celui qui a le plus senti la vie." J.-J. Rousseau, Emile.
Re: Ada subtypes and base types
> > On irc today we were discussing handling 'this' in gcj. We can add an > > attribute to the argument to mark it as non-null... but strangely > > there doesn't seem to be a way to mark other local variables as > > known-non-null -- a curious deficiency. > It seems to me that for other locals that the non-null property > ought to be a property of how those locals are assigned a value. > ie, if we're going to be able to derive a non-null for a local we > should be able to derive it from the RHS of the assignment(s) to > that local. > > IIRC "this" is actually a parameter and thus there's no assignment > we can derive information from. Ada has a notion of "non-null pointer type". A variable declared to be of such a type is required to have a non-null initial value, so VRP can presumably work out that it is non-null from the initialization. The main interest of such a type is in declaring subroutine parameters and function return values, in which case the existing attribute is likely good enough. So the Ada way of handling these types maps pretty well to what you said. Ciao, Duncan.
How to get global declarations in GIMPLE
Hi, I was trying to convert the gcc C-Gimple form to the internal AST representation used in our research compiler. I was able to transform most of the nodes of the GIMPLE tree but was not able to find out a way to retrieve the global declarations from the GIMPLE tree. For example is there a way to get the declarations of structs and unions etc that are there at the translation unit level and declared at the function scope? One place I figured, to get this information is when the C-file is being parsed by the parser. However this requires changing the gcc front end in a big way which we wanted to avoid. I was wondering if anyone can help me figure out a way to retrieve this information from the GIMPLE tree itself. Thanks a lot. Regards, Mayank
Re: GNU Pascal branch
On 3/30/06, Adriaan van Os <[EMAIL PROTECTED]> wrote: > the problem is not regular testing. Then waht is the problem with the daily maintenance you mention? Maybe there are other ways to make life easier for the gpc folks if you would be more specific about the problems you apparently have. > > and people are > > responsible for fixing all front ends when they do backend changes. > > I don't believe that, they would just say, "oh, it is broken" or "oh, > it is not a primary language" or whatever excuse. Well, what you believe and what is daily practice are different then. I wonder why you would hold such beliefs if you have never tried it. > We are not forcing anybody, we offer full choice. Not fixing > backend-end bugs is what is actually forcing people. And even patches > that do fix bugs are often not accepted. Whatever. > > What would be the benefits of this for GCC? Wouldn't this just result > > in more bug reports for GCC maintainers > > No. No because...? And what about the first question? > Thanks for your great cooperation. Perhaps you should go look for a mirror and say this again. Gr. Steven
Re: GCC-4.2-20060325 build failure on OpenBSD 3.9-current
Hello, I've checkouted todays sources from trunk and I can confirm that the same failure also happens there. Cheers, Karel On Fri, 31 Mar 2006, Karel Gardas wrote: Hello, I'm trying to build GCC-4.2-20060325 on OpenBSD 3.9-current, but it fails with: echo timestamp > s-gtype /home/karel/build/obj-gcc-4.2-20060325/./prev-gcc/xgcc -B/home/karel/build/obj-gcc-4.2-20060325/./prev-gcc/ -B/home/karel/usr/local/gcc-4.2-20060325/i386-unknown-openbsd3.9/bin/ -c -O2 -g -fomit-frame-pointer -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -Werror-DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I/home/karel/build/gcc-4.2-20060325/gcc -I/home/karel/build/gcc-4.2-20060325/gcc/build -I/home/karel/build/gcc-4.2-20060325/gcc/../include -I/home/karel/build/gcc-4.2-20060325/gcc/../libcpp/include -I/home/karel/build/gcc-4.2-20060325/gcc/../libdecnumber -I../libdecnumber -o build/rtl.o /home/karel/build/gcc-4.2-20060325/gcc/rtl.c /home/karel/build/obj-gcc-4.2-20060325/./prev-gcc/xgcc -B/home/karel/build/obj-gcc-4.2-20060325/./prev-gcc/ -B/home/karel/usr/local/gcc-4.2-20060325/i386-unknown-openbsd3.9/bin/ -c -O2 -g -fomit-frame-pointer -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -Werror-DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I/home/karel/build/gcc-4.2-20060325/gcc -I/home/karel/build/gcc-4.2-20060325/gcc/build -I/home/karel/build/gcc-4.2-20060325/gcc/../include -I/home/karel/build/gcc-4.2-20060325/gcc/../libcpp/include -I/home/karel/build/gcc-4.2-20060325/gcc/../libdecnumber -I../libdecnumber -o build/read-rtl.o /home/karel/build/gcc-4.2-20060325/gcc/read-rtl.c cc1: warnings being treated as errors /home/karel/build/gcc-4.2-20060325/gcc/read-rtl.c: In function 'join_c_conditions': /home/karel/build/gcc-4.2-20060325/gcc/read-rtl.c:787: warning: missing sentinel in function call gmake[3]: *** [build/read-rtl.o] Error 1 gmake[3]: Leaving directory `/home/karel/build/obj-gcc-4.2-20060325/gcc' gmake[2]: *** [all-stage2-gcc] Error 2 gmake[2]: Leaving directory `/home/karel/build/obj-gcc-4.2-20060325' gmake[1]: *** [stage2-bubble] Error 2 gmake[1]: Leaving directory `/home/karel/build/obj-gcc-4.2-20060325' gmake: *** [bootstrap-lean] Error 2 the compiler used for bootstrap is OpenBSD's gcc3.3.5. GCC 4.2 is configured with: /home/karel/build/gcc-4.2-20060325/configure --prefix=/home/karel/usr/local/gcc-4.2-20060325 --enable-shared --enable-threads --disable-checking --disable-nls --enable-languages=c,c++ and it is build with: gmake CFLAGS='-O' LIBCFLAGS='-g -O2' LIBCXXFLAGS='-g -O2 -fno-implicit-templates' bootstrap-lean If I understand this issue correctly, it seems GCC 4.2 stage1 compiler warns about missing sentinel and because of -Werror bootstrap fails. If this is true, then perhaps the same issue happen also on more supported platforms? (Linux/FreeBSD) If so, then my question is: is this already fixed on trunk? Thanks, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com
Declaration after a label
GCC reports an error for this snippet:
int main()
{
foo:
int x;
}
foo.c:4: error: expected expression before 'int'
... but not this snippet:
int main()
{
foo:
(void)0;
int x;
}
Is this expected behaviour? At the very least, it seems like an
unusual distinction.
Please cc me in your reply. Cheers,
Shaun
Re: Declaration after a label
"Shaun Jackman" <[EMAIL PROTECTED]> writes:
> GCC reports an error for this snippet:
>
> int main()
> {
> foo:
> int x;
> }
>
> foo.c:4: error: expected expression before 'int'
The C standard only allows labels to occur before statements. A
declaration is not a statement.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
[RFC] Pointer overflow produced by pointer_int_sum and PR26763
PR26763 is
int try (int *a)
{
return a + -1 > a;
}
int main(void)
{
int bla[100];
if (try (bla + 50))
abort ();
return 0;
}
now, this looks like a perfectly valid testcase which pointer_int_sum
makes questionable, because it produces
a + -4B > a
which has an overflowing pointer on the lhs. I think we should avoid
this situation by simply producing a - 4B instead. Does this sound
reasonable? This is what the following (untested) patch does.
Opinions?
Thanks,
Richard.
Index: tree.h
===
*** tree.h (revision 112577)
--- tree.h (working copy)
*** extern tree build_fold_indirect_ref (tre
*** 4196,4201
--- 4196,4202
extern tree fold_indirect_ref (tree);
extern tree constant_boolean_node (int, tree);
extern tree build_low_bits_mask (tree, unsigned);
+ extern tree fold_negate_const (tree arg0, tree type);
extern bool tree_swap_operands_p (tree, tree, bool);
extern void swap_tree_operands (tree, tree *, tree *);
Index: fold-const.c
===
*** fold-const.c(revision 112577)
--- fold-const.c(working copy)
*** static tree fold_mathfn_compare (enum bu
*** 131,137
static tree fold_inf_compare (enum tree_code, tree, tree, tree);
static tree fold_div_compare (enum tree_code, tree, tree, tree);
static bool reorder_operands_p (tree, tree);
! static tree fold_negate_const (tree, tree);
static tree fold_not_const (tree, tree);
static tree fold_relational_const (enum tree_code, tree, tree, tree);
--- 131,137
static tree fold_inf_compare (enum tree_code, tree, tree, tree);
static tree fold_div_compare (enum tree_code, tree, tree, tree);
static bool reorder_operands_p (tree, tree);
! tree fold_negate_const (tree, tree);
static tree fold_not_const (tree, tree);
static tree fold_relational_const (enum tree_code, tree, tree, tree);
*** fold_read_from_constant_string (tree exp
*** 11822,11828
TYPE is the type of the result. */
! static tree
fold_negate_const (tree arg0, tree type)
{
tree t = NULL_TREE;
--- 11822,11828
TYPE is the type of the result. */
! tree
fold_negate_const (tree arg0, tree type)
{
tree t = NULL_TREE;
Index: c-common.c
===
*** c-common.c (revision 112577)
--- c-common.c (working copy)
*** pointer_int_sum (enum tree_code resultco
*** 2354,2359
--- 2354,2368
else
size_exp = size_in_bytes (TREE_TYPE (result_type));
+ /* If intop is negative, invert the resultcode to avoid relying
+ on pointer overflow being defined. */
+ if (TREE_CODE (intop) == INTEGER_CST
+ && tree_int_cst_sgn (intop) < 0)
+ {
+ resultcode = resultcode == PLUS_EXPR ? MINUS_EXPR : PLUS_EXPR;
+ intop = fold_negate_const (intop, TREE_TYPE (intop));
+ }
+
/* If what we are about to multiply by the size of the elements
contains a constant term, apply distributive law
and multiply that constant term separately.
Re: GCC-4.2-20060325 build failure on OpenBSD 3.9-current
> > > Hello, > > I'm trying to build GCC-4.2-20060325 on OpenBSD 3.9-current, but it fails > with: > > echo timestamp > s-gtype > /home/karel/build/gcc-4.2-20060325/gcc/read-rtl.c:787: warning: missing > sentinel in function call This usually means NULL is defined as 0 instead of (void*)0. -- Pinski
gcc-4.1-20060331 is now available
Snapshot gcc-4.1-20060331 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20060331/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.1 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch revision 112593 You'll find: gcc-4.1-20060331.tar.bz2 Complete GCC (includes all of below) gcc-core-4.1-20060331.tar.bz2 C front end and core compiler gcc-ada-4.1-20060331.tar.bz2 Ada front end and runtime gcc-fortran-4.1-20060331.tar.bz2 Fortran front end and runtime gcc-g++-4.1-20060331.tar.bz2 C++ front end and runtime gcc-java-4.1-20060331.tar.bz2 Java front end and runtime gcc-objc-4.1-20060331.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.1-20060331.tar.bz2The GCC testsuite Diffs from 4.1-20060324 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.1 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: GNU Pascal branch
Diego Novillo wrote: > On 03/30/06 03:32, Adriaan van Os wrote: > >> Still, I would like to create a GNU Pascal branch for gcc. This will be >> a central place where to keep the compiler updated with >> > I don't think this is a good idea. You are either part of the compiler > or you aren't. Front ends that are only partially incorporated will > naturally suffer bit-rot and be largely ignored. Even if the FE is not > enabled by default, you can benefit from being integrated in the rest of > the compiler (e.g., Ada). Without making any judgement on the merits, adding GPC to the repository would certainly need to be approved by the GCC SC. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Front end best practice in GCC 4.1.0?
> You know, I've always wondered why there wasn't a lisp-family front end > for GCC, the roots of GNU and RMS being where they are (and didn't RMS > promise way back when to make lisp suitable for unix systems > programming?). I'm just not connected enough to the lisp world to know > the answer I guess. I also don't know. We chose scheme because it was the only language we knew of whose specification was small enough to read and still have some time left to code in a semester :-) > That's pretty much *exactly* what I had in mind--minimal front end that > produces a useless, do-nothing, but "correct" front end. Even the > motivation is the same, since as you might expect this was a preface to > a language project. :-) Nice. If you notice, the documentation consists of a series of steps. In the first one a front end that does nothing is created. In the second step an empty main is generated. Unfortunately, even a hello world front end is a bit hard to explain :-( > I'd be happy to cooperate as much as possible. The goal was to write > the document I needed myself and didn't find, and in so doing learn the > knowledge I'd have gotten from it. It wasn't to write for writing's > sake. If you've done everything I wanted, so much the better. :-) > > That said, I haven't actually looked at your docs in detail. It took me > a while to install svn, figure out how to do a checkout and what URL to > use, find the system docbook stylesheets, and put their path in the > makefile (not too bad for someone who has never seen docbook or used XML > before, I thought), and learn enough about docbook to find an > alternative to fop (I am not eager to install it because I'm trying to > keep this machine not-too-dependent on a jvm. :-) ) I use the html output mostly. Fop generates a very bad pdf IMHO, but I was able to run it (without support for images) with kaffe. > A quick look suggests that what you wrote is very like what I wanted to > end up with. The main difference is that I suspect I was going for a > bit more exhaustive detail--whether that's a good or bad thing is a > separate issue. Having a more details is a good thing I think, but remember that the details are likely to be the first thing that will become out of date. > Were you thinking hosting the html version somewhere eventually? We have written it in docbook to be able to eventually send it to TLDP. Currently the two co-authors have requested the copyright paper to submit the front end itself to the gcc trunk. After that we might try to update the tutorial a little bit and send it to the TLDP. > Thanks, that's the sort of comments I was hoping for. > > Dustin My pleasure, once we discovered how complicated the front end interface was, we were sure that someone else could benefit from the our experience :-) Rafael
Successfully built and installed GCC 4.0.3 on Slackware 10.2
I successfully built and installed GCC 4.0.3 on Slackware 10.2. Bootstrapping info: 1. Output of srcdir/config.guess: i686-pc-linux-gnu 2. Output of "gcc -v": Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-src/gcc-4.0.3/configure Thread model: posix gcc version 4.0.3 3. Distribution info for GNU/Linux: Distribution: Slackware 10.2 Linux kernel: 2.6.16 glibc version: 1.x: libglib-1.2.so.0.0.10 2.x: libglib-2.0.so.0.800.4 4. Info for people building GCC on the same configuration: If you install to the default directory, which is /usr/local, you either have to delete, rename or redirect the programs in /usr/bin to /usr/local/bin. Also, you might want to link /usr/include/c++/4.0.3 to /usr/local/include/c++/4.0.3. 5. Completeness of target-specific installation notes: The document is sufficient.
