Re: GCC 4.0 build fails on Mac OS X 10.3.9/Darwin kernel 7.9
> Not being able to build in the source directory is a bug. > Having to set CONFIG_SHELL is a bug. > Having to install a newer cctools is a bug. > > Bugs should be fixed. Papering over them with documentation is, well, > unappealing to me. How can you fix bugs in Solaris' /bin/sh? -- Eric Botcazou
Re: GCC 4.0 build fails on Mac OS X 10.3.9/Darwin kernel 7.9
On Fri, Apr 22, 2005 at 09:52:30PM +0200, Eric Botcazou wrote: > > Not being able to build in the source directory is a bug. > > Having to set CONFIG_SHELL is a bug. > > Having to install a newer cctools is a bug. > > > > Bugs should be fixed. Papering over them with documentation is, well, > > unappealing to me. > > How can you fix bugs in Solaris' /bin/sh? You don't. You detect that there is a buggy /bin/sh and go looking for a non-buggy ksh, which you will generally find. Then you use that. All without disturbing the user.
Re: different address spaces (was Re: internal compiler error atdwarf2out.c:8362)
On Fri, 2005-04-22 at 15:56, Paul Schlie wrote: > - Why are string literal character arrays not constructed and expanded as > character array literals are? They are constructed and expanded differently, because, obviously, they are different things. I don't understand the point of this question. There are obvious syntax differences. There are obvious semantic differences. So they have to be different at least until we reach the optimizers. And perhaps longer. We could perhaps do some conversion between them, but since not all array initializers can be strings, and because converting strings to array initializers probably won't work in all cases, we still need to have two separate code paths. And since we have to have two separate code paths, anyways, there doesn't seem to be much point in trying to do any conversion. There may also be historical reasons, which I see no point to trying to look up. If you really think there is an issue here, you are welcome to investigate it yourself. I am not going to do it for you, at least not for free. Also, this question bears no relationship to the original thread. These off-topic follow ups can be annoying. You should start new threads for new questions instead of trying to hijack an existing thread. > unnecessary, and error prone (as evidenced by string literal memory > references not being properly identified as READONLY, although their > equivalent array representations are treated properly for example?) If true, that sounds like a bug. This is the only interesting issue here from my point of view. You might consider filing a bug report into bugzilla for this. Or contributing a patch. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Mainline Bootstrap failure on x86-64-linux-gnu
Current GCC CVS Mainline fails to bootstrap for me: stage1/xgcc -Bstage1/ -B/opt/gcc/4.1-devel/x86_64-suse-linux-gnu/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -Werror -fno-common -DHAVE_CONFIG_H-I. -I. -I/cvs/gcc/gcc -I/cvs/gcc/gcc/. -I/cvs/gcc/gcc/../include -I/cvs/gcc/gcc/../libcpp/include \ /cvs/gcc/gcc/config/i386/i386.c -o i386.o /cvs/gcc/gcc/config/i386/i386.c: In function ʽix86_reorgʼ: /cvs/gcc/gcc/config/i386/i386.c:16453: error: Definition in block 54 does not dominate use in block 55 for SSA_NAME: TMT.6057_84 in statement: TMT.6057_99 = PHI ; PHI argument TMT.6057_84 for PHI node TMT.6057_99 = PHI ; /cvs/gcc/gcc/config/i386/i386.c:16453: internal compiler error: verify_ssa failed. Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make[2]: *** [i386.o] Error 1 pgpB32lG0dell.pgp Description: PGP signature Andreas -- Andreas Jaeger, [EMAIL PROTECTED], http://www.suse.de/~aj SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 pgproQZfP8lAf.pgp Description: PGP signature
Build and test results for GCC 4.0.0
Here are three build status reports for GCC 4.0.0. #1: i686-pc-linux-gnu on Red Hat Enterprise version 3 (Xeon). Languages: C, C++, Obj-C, Java. Results: http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg01541.html #2: x86_64-unknown-linux-gnu on Red Hat Enterprise version 3 (AMD Opteron). Languages: C, C++, Obj-C, Java. Results: http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg01598.html #3: hppa2.0w-hp-hpux11.00 with as from binutils 2.15 Languages: C, C++, Obj-C. Results: (some kind of mailer mishap messed up the header) http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg01570.html Builds on sparc-sun-solaris2.8 and ia64-unknown-linux-gnu are in progess.
Re: Some small optimization issues with gcc 4.0 20050418
Sebastian Biallas wrote: But I noticed some smaller optimization issues on x86, and on of them is a regression to gcc 3.3 so I'm reporting this here. Accept my apologies if this is already known, but I think it's worth noting. You can submit optimization regressions into our bugzilla bug database. gcc-4 has a bunch of new and/or rewritten optimization passes, and occasionally minor problems with them will be missed. They are likely to be fixed if we get bug reports for them though. [1] Why keep the -1 constant in %esi? The cmpl with constant is only 1 byte longer.. this doesn't justify this. Looks like one of new tree optimization passes, ivopts, emitted a compare with the constant first, which is non-canonical, and prevented the RTL cse pass from substituting the -1 into the compare. This is already fixed on mainline. ivopts now emits a canonical compare, and also includes the constant -1 in the compare instead of putting it in a temporary. [2] It's allocating 5 words on stack while 2 would be enough. I know that gcc isn't very smart at optimizing the stack slots but this is a regression There is one word for the return address, two words for registers being saved, and two words for the printf arguments. There does appear to be a problem here, as we are using pushes in the prologue to save registers, which means we should not be allocating space for them when we decrement the stack pointer. The other 3 slots appear to be necessary. [3] Why use the cmpl at all? gcc 3.3 did this right, I don't think the cmpl is faster than a decl (and even then, the cmpl could be replaced by a "subl $1, %ebx") This looks like another ivopts issue. If gcc-3.3, we get a >= branch, which can use the result of the decrement. In gcc-4.0, ivopts canonicalizes the branch to use !=, which can not use the result of the decrement as the condition code flags are set wrong for that. This still happens on mainline, and should probably be looked into. [1] Again, the wasted stack. gcc-3.3 doesn't get this right, too. I don't believe so. We have the return address and the two printf arguments, so all 3 slots are needed. [2] Even a peephole optimizer could optimize this :) Yes, this is embarassing. I had to use -march=i686 to reproduce this. We have a peephole2 pattern that converts movl $10, i into movl $10, %eax movl %eax, i because it is faster, except that this happens so late that there is no chance to perform cse on the result, so we can't delete the duplicate constant immediate loads. So while this is bad, it isn't as bad as it might appear at first. [3] The testl is unneeded, the flags are already prepared by the decl. Is this a hard optimization to accomplish? It's quite obvious for a human, but I don't know how this looks from a compiler perspective... This is same as above, we need the testl as we have the wrong kind of branch condition. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: GCC 4.0 build fails on Mac OS X 10.3.9/Darwin kernel 7.9
On Friday, April 22, 2005, at 12:52 PM, Eric Botcazou wrote: How can you fix bugs in Solaris' /bin/sh? See the re-exec logic in autoconf was it.
Re: c54x port
On Thu, Apr 21, 2005 at 06:10:19PM -0700, Bryan Richter wrote: > I am working on porting GCC to the TI C54x. Cool. > months, similar to others who have attempted this project, but I am now > in the process of setting up a repository on BerliOS so I can work with > others. Maybe not so cool, unless you are careful. The problem is that if you don't keep track of who submitted what, or if you accept some critical code from someone who is either unwilling or unable to legally contribute their work to the FSF, it can never be accepted as part of the official GCC. Please read http://gcc.gnu.org/contribute.html for requirements on contributing work to GCC, and http://gcc.gnu.org/contributewhy.html for why it's a good idea to go along. You're setting yourself up to build a separate, isolated group of developers, rather than working with the GCC experts, if you go off and start your own site and your own separate project. You can do that if you want, but it has disadvantages. At the least, you need to have your ducks in a row so that, when you are ready to talk about getting your port into GCC, if can be done (meaning that you've followed the standards and that all contributors are prepared to contribute their work). > 2. I plan on taking a GCC release (say, gcc-4.0.0-20050417), treating it > as a constant, and building the port on top of it. That way I won't have > to concern myself with the development of the rest of GCC (which would > hardly affect me). Is this the best method? No; the rest of GCC will affect you. If you ever want your work accepted as part of GCC, it has to work with the current development trunk. You're better off grabbing a snapshot of the trunk (what will become 4.1), working on that, and occasionally re-syncing to make sure that nothing has been broken. I don't think the revision control system you use matters, because if and when you are ready to contribute the port to GCC, the previous history is not going to be relevant, and all subsequent development would be inside GCC's revision control system (currently CVS, but likely to switch to subversion some time soon).
gcc-3.4-20050422 is now available
Snapshot gcc-3.4-20050422 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/3.4-20050422/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 3.4 CVS branch with the following options: -rgcc-ss-3_4-20050422 You'll find: gcc-3.4-20050422.tar.bz2 Complete GCC (includes all of below) gcc-core-3.4-20050422.tar.bz2 C front end and core compiler gcc-ada-3.4-20050422.tar.bz2 Ada front end and runtime gcc-g++-3.4-20050422.tar.bz2 C++ front end and runtime gcc-g77-3.4-20050422.tar.bz2 Fortran 77 front end and runtime gcc-java-3.4-20050422.tar.bz2 Java front end and runtime gcc-objc-3.4-20050422.tar.bz2 Objective-C front end and runtime gcc-testsuite-3.4-20050422.tar.bz2The GCC testsuite Diffs from 3.4-20050415 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-3.4 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.
writeable-strings (gcc 4 and lower versions) clarification
Hello,
If you will comple with gcc (version lower than 4) a program like this , on
Linux:
int main()
{
char* myString = "test";
(*myString)++;
}
You will get a segfault when running it.
On the other hand, if you will pass -fwriteable-strings at compilation ,
you will be able to run it without any segfault .
They do say in the man gcc that writeable-strings is deprecated and it is
better not to
use it.
According to gcc-4.0 docs,
"GCC no longer accepts the -fwritable-strings option. Use named character
arrays when you need a writable string."
see
http://gcc.gnu.org/gcc-4.0/changes.html
I have 2 questions:
What are the disadvantages of using -fwritable-strings and why was it
removed ?
by "Using named character arrays" I assume that the meaning is
writing char myString[] = {"test"};
am I right ?
Regards,
Sting
_
Don't just search. Find. Check out the new MSN Search!
http://search.msn.click-url.com/go/onm00200636ave/direct/01/
Re: different address spaces (was Re: internal compiler error atdwarf2out.c:8362)
On Fri, 2005-04-22 at 04:58, Paul Schlie wrote: > Thanks. After going through the code, it's even further not clear why > STRING_CST string literal data references treated differently than > static const char array literal data references to begin with? > Why is this necessary? Why is what necessary? You haven't actually said anything concrete that I can answer. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: c54x port
Joe Buck wrote: > Maybe not so cool, unless you are careful. The problem is that if you > don't keep track of who submitted what, or if you accept some critical > code from someone who is either unwilling or unable to legally contribute > their work to the FSF, it can never be accepted as part of the official > GCC. > > Please read > > http://gcc.gnu.org/contribute.html Right- I've read this and I'm aware of the situation. I am prepared to 'keep my ducks in a row'. :) > You're setting yourself up to build a separate, isolated group of > developers, rather than working with the GCC experts, if you go off and > start your own site and your own separate project. You can do that if > you want, but it has disadvantages. I can't argue that isolation has disadvantages. However, I think there are arguments for it, as well: 1. I said in my original post that the rest of development won't affect us. What I *should* have said is our work won't affect[1] the rest of development. Until such time that we have enough of a port to generate code, we can't even compile GCC, much less start mucking around in internals. 2. gcc@gcc.gnu.org is ..erhm, really noisy. :) I'd rather not stay subscribed to it. I could be wrong, but I don't envision a need to talk to the entire group of developers very often. Keeping it separate would keep me sane. You are free to argue these points, and I ask that you please do so if there are issues I have overlooked. Otherwise, I will continue as planned. Thanks for the comments! -Bryan [1] It is possible that, at some point, we might find places to tighten up code, fix bugs, or clean up documentation. However, I would discourage anyone from making those changes to our independent branch. Instead, they should be made to the main tree, and we would resync to it afterwards. -- Bryan Richter UCDTT President UC Davis Undergrad, Physics Dept. - A PGP signature is (probably) attached to this email. PGP Key ID: BB8E6CCC signature.asc Description: Digital signature
Re: emit_no_conflict_block breaks some conditional moves
James E Wilson <[EMAIL PROTECTED]> writes: > Greg McGary wrote: > > I found that > > emit_no_conflict_block() reordered insns gen'd by > > expand_doubleword_shift() in a way that violated dependency between > > compares and associated conditional-move insns that had the target > > register as destination. > > You didn't say precisely what went wrong, but I'd guess you have > cmpsi ... > movsicc target, ... > cmpsi ... > movsicc target, ... > which got reordered to > cmpsi ... > cmpsi ... > movsicc target, ... > movsicc target, ... > which obviously does not work if your condition code register is a > hard register. Correct. FYI, the two "cmpsi" insns are identical and redundant, so don't conflict, however, all bit-logic and shift insns on this CPU clobber condition codes, and the CC-producing cmpsi insns are separated from their consumers by CC-clobbering logic & shift insns. > Perhaps a check like > && GET_MODE_CLASS (GET_MODE (SET_DEST (set))) != MODE_CC > or maybe check for any hard register > && (SET_DEST (set) != REG > || REGNO (set) >= FIRST_PSEUDO_REGISTER) > Safer is probably to do both checks, so that we only reject CCmode > hard regs here, e.g. > && (GET_MODE_CLASS (GET_MODE (SET_DEST (set))) != MODE_CC > || SET_DEST (set) != REG > || REGNO (set) >= FIRST_PSEUDO_REGISTER)) > which should handle the specific case you ran into. That will do fine for ports that have conditional move, but without movsicc, you'll have this case: cmpsi ... bcc 1f movsi target, ... 1: cmpsi ... bcc 2f movsi target, ... 2: which without the above fix will be reordered: cmpsi ... bcc 1f 1: cmpsi ... bcc 2f 2: movsi target, ... movsi target, ... while with the above fix, will be reordered: bcc 1f 1: bcc 2f 2: cmpsi ... movsi target, ... cmpsi ... movsi target, ... Here, the branches and labels need to also travel with the cmpsi and movsi. Greg
Re: different address spaces (was Re: internal compiler error atdwarf2out.c:8362)
> From: James E Wilson <[EMAIL PROTECTED]>
>> On Fri, 2005-04-22 at 04:58, Paul Schlie wrote:
>> Thanks. After going through the code, it's even further not clear why
>> STRING_CST string literal data references treated differently than
>> static const char array literal data references to begin with?
>> Why is this necessary?
>
> Why is what necessary? You haven't actually said anything concrete that
> I can answer.
Sorry. More specifically:
- Why are string literal character arrays not constructed and expanded as
character array literals are? (as although similar, there are distinct
sets of code expanding references to each of them; which seems both
unnecessary, and error prone (as evidenced by string literal memory
references not being properly identified as READONLY, although their
equivalent array representations are treated properly for example?)
- If the only difference which exists between them is how their values
are "pretty-printed" as strings, vs. array values; then it would seem
that although they may be labeled differently, but utilize be constructed
and expanded equivalently? If this is not true, why must they be distinct?
- I.e.
char x[3] = "abc";
seems as if it should be literally equivalent in all respects to:
char y[3] = {'a','b','c'};
but are not constructed/expanded as being equivalent?
gcc 4.0 build status
> Output from running srcdir/config.guess. Do not send that file itself, just > the one-line output from running it. i686-pc-linux-gnu > The output of gcc -v for your newly installed gcc. This tells us which > version of GCC you built and the options you passed to configure. Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../configure --prefix=/usr Thread model: posix gcc version 4.0.0 > Whether you enabled all languages or a subset of them. If you used a full > distribution then this information is part of the configure options in the > output of gcc -v, but if you downloaded the âcoreâ compiler plus > additional front ends then it isn't apparent which ones you built unless you > tell us about it. all (AFAIK) > If the build was for GNU/Linux, also include: > The distribution name and version (e.g., Red Hat 7.1 or Debian 2.2.3); this > information should be available from /etc/issue. Welcome to SuSE Linux 9.2 (i586) - Kernel \r (\l). > The version of the Linux kernel, available from uname --version or uname -a. Linux marty 2.6.8-24.14-default #1 Tue Mar 29 09:27:43 UTC 2005 i686 i686 i386 GNU/Linux > The version of glibc you used; for RPM-based systems like Red Hat, Mandrake, > and SuSE type rpm -q glibc to get the glibc version, and on systems like > Debian and Progeny use dpkg -l libc6. glibc-2.3.3-118
Build of GCC 4.0.0 successful
I've bootstrap built GCC 4.0.0 on Fedora Core 3. [EMAIL PROTECTED] ~]$ gcc -v Using built-in specs. Target: athlon-fedora-linux Configured with: ../configure --prefix=/opt2/gcc4 --enable-shared --enable-threads=posix --disable-checking --with-system-zlib--enable-__cxa_atexit --disable-libunwind-exceptions --enable-java-awt=gtk --host=athlon-fedora-linux Thread model: posix gcc version 4.0.0 I did not run the reqressions, but I did something equally interesting (or stupid depending on your point of view). I built kernel 2.6.11.7 and booted back into it. [EMAIL PROTECTED] ~]$ cat /proc/version Linux version 2.6.11.7 ([EMAIL PROTECTED]) (gcc version 4.0.0) #2 Fri Apr 22 14:12:12 EDT 2005 The kernel source failed to build in one file. I made the following changes in order to get a module to build. Changed include/linux/i2c.h: line 58 extern int i2c_transfer(struct i2c_adapter *adap, struct i2c_msg msg[],int num); to extern int i2c_transfer(struct i2c_adapter *adap, struct i2c_msg *msg,int num); line 197 int (*master_xfer)(struct i2c_adapter *adap,struct i2c_msg msgs[], to int (*master_xfer)(struct i2c_adapter *adap,struct i2c_msg *msgs, Once those two changes were made everything built. I did see kernel build warnings go flying by, but I did not bother with those (yet). I'm very impressed. I'm looking forward to poking at the C++, f9x, and java bits. Thanks a lot guys.
Re: unreducable cp_tree_equal ICE in gcc-4.0.0-20050410
On Thu, 14 Apr 2005, Dale Johannesen wrote: > On Apr 14, 2005, at 7:14 AM, Andrew Pinski wrote: > >>Does this bug look familiar? 20629 is ICEing in the same spot, but > >>it looks like theirs was reproducible after preprocessing. Is there > >>any more information that I provide that would be helpful? I've > >>attached the command line, specs and a stacktrace from cc1plus. > > > >I think this was fixed on the mainline by: > >2005-03-18 Dale Johannese <[EMAIL PROTECTED]> > > > >* cp/tree.c (cp_tree_equal): Handle SSA_NAME. > > Yep, and I didn't put it in the release branch. Bad Dale. OK to do > that? > > If this is the same problem, changing the VN hashtable size to 1 > should make it show up reproducibly. > The released 4.0.0 successfully compiles the code that was having problems before. -nick
Build gcc-4.0.0
Hi there, I successfully built gcc-4.0.0: config.guess i686-pc-linux-gnu gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.0.0/configure --prefix=/usr/local/test/gcc-4.0.0 --with-local-prefix=/usr/local/test/gcc-4.0.0 --enable-threads --enable-languages=ada,c,c++,objc,java Thread model: posix gcc version 4.0.0 GNU/Linux Mandrakelinux release 10.1 (Official) for i586 Kernel 2.6.8.1-12mdk on an i686 glibc-2.3.3-23.1.101mdk Some remarks: - - I had to use the --enable-languages option to get the Ada compiler; without it, and contrarily to what is suggested in the installation doc, Ada was not built. - the HTML documentation is generated in /objdir//gcc/HTML, not in /objdir//HTML as indicated in the documentation.
Re: GCC 4.0.0 fsincos?
Hello! If I compile with $ ~/usr/bin/gcc-4.0.0 -S Com_Code.cc -ffast-math -O2 the relevant generated code section is #APP fldln2; fxch; fyl2x #NO_APP fmulp %st, %st(2) fxch%st(1) #APP fsqrt #NO_APP fld %st(1) #APP fsin #NO_APP fxch%st(2) #APP fcos #NO_APP So after generating R, a separate fsin and fcos seem to be generated. Am I missing an option or something? You should use -ffast-math together with -D__NO_MATH_INLINES in your compile flags, or use a newer glibc. -D__NO_MATH_INLINES should also be used for -mfpmath=sse to prevent generation of x87 instructions from mathinline.h header when SSE code is used for FP math operators. Otherwise xmm reg->mem->x87 reg moves will kill your performance. Uros. Uros.
Re: Regression on mainline in tree-vrp.c
On Fri, Apr 22, 2005 at 10:26:25AM -0400, Kazu Hirata wrote: > Hi Rainer and Steve, > > > | 4.1.0 20050419 (experimental) (i386-pc-solaris2.10) GCC error: | > > | in set_value_range, at tree-vrp.c:124| > > | Error detected at sem_intr.adb:437:1 | > > There seem to be several ways to get to this ICE. set_value_range is > used in many places in tree-vrp.c. I'll try to take a look at these > in the next few days. > I attached a cutdown test case of cher2k.f for your use with this bug. I don't know if you fortran or not, but I can assure that this minimum test case is a very common Fortran construct. One other thing to keep in mind, this only happens with -O2. -- Steve SUBROUTINE CHER2K(N, BETA, C, LDC) INTEGER I, J, N, LDC REAL BETA COMPLEX C(LDC,*), ZERO PARAMETER (ZERO = (0.0E+0, 0.0E+0)) IF (BETA .EQ. REAL(ZERO)) THEN DO 20, J = 1, N DO 10, I = 1, J C(I,J) = ZERO 10 CONTINUE 20CONTINUE ELSE DO 40, J = 1, N DO 30, I = 1, J - 1 C(I,J) = BETA * C(I,J) 30 CONTINUE 40CONTINUE END IF END
Re: gpg signatures on tar/diff
On Fri, Apr 22, 2005 at 09:59:18AM +0200, Adrian von Bidder wrote: > Hi, > > Please forgive this remark - especially if it has been discussed before (I > don't follow this list.) > > I think that Mark's key (0xB75C61B8) might not have been the best choice to > sign the gcc release because it lacks connections to the majority of the > OpenPGP web of trust, being signed only by one other key afaict. Mark is the person making the release, therefore it is his word that it is a valid release and no one else's. If you'd feel better about a key with more signatures, then maybe Mark can arrange to have people sign his key at the GCC Summit.
Re: gcc-4.0.0 build failed
On Fri, Apr 22, 2005 at 12:32:23AM -0400, Andrew Pinski wrote: > > On Apr 22, 2005, at 12:27 AM, Eric Lemings wrote: > > >FYI, > > > >Downloaded gcc-core-4.0.0.tar.bz and gcc-g++-4.0.0.tar.bz2. > >Uncompressed both and did a configure followed by a make. > >Got the following error from make: > > Why do people don't read the installation instructions? > Yes this is a bug but a known one, see PR 17383 which is fixed > on the mainline. There is an easy work around if you just read > the installation instructions. People don't read the instructions. This is just a fact of life. We're inevitably going to get people trying to build gcc in the source directory, because that procedure works for most GNUware and other free software.
Re: GCC 4.0 branch open for regression fixes
Mark Mitchell wrote: The GCC 4.0 branch is now open for regression fixes only, under the usual release branch rules. I presume this means that we (The Fortran Illuminati) can fix any bug in the gfortran frontend, as we don't have any regressions yet (at least not against gfortran itself - there are regressions with respect to g77) ? [ Thanks for your continued support of our product ] :-) -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/ News on GNU Fortran 95: http://gfortran.org/
A bug in the current released GCC 4.0.0
Hello,
I casually found a bug in the current released GCC 4.0.0. However, I
have located the wrong code, and it's very easy to be fixed, so it's not
necessary to still submit a bug report. See the following artificial
C++ code:
int *x;
void f()
{
do
{
const int *&rx = (const int*&)(x);
rx = 0;
}while( *x );
}
Compile it with command "cc1plus -O2" will cause an internal error
happening in get_indirectref_operands, at tree-ssa-operands.c:1449,
which is because GCC gets into the unreachable branch. The underlying
fault is in create_expression_by_pieces, at tree-ssa-pre.c:1382.
if (!is_gimple_min_invariant (genop1))
newexpr = force_gimple_operand (folded, &forced_stmts, false,
NULL);
else
1382: newexpr = genop1;
I guess it's a clerical error. The genop1 is just a GIMPLE
min_invariant operand of the expression being processed. What holds the
needed expression here is the variable FOLDED, so this line should be as
following.
1382: newexpr = folded;
I modified it as so and it works correctly when compiling the above
artificial code and also my project files on which the unmodified
version fails.
I hope this is helpful to the maintainers.
gcc 4.0.0 successful build
Hi, finally, gcc 4.0.0 is released and it builds on IRIX 6.3 (as opposed to my numerous failing tries of gcc 3.x.y). lucy 70% ./gcc-4.0.0/config.guess mips-sgi-irix6.3 lucy 71% /usr/gcc-4.0/bin/gcc -v Using built-in specs. Target: mips-sgi-irix6.3 Configured with: /usr/people/eblachut/dev/gcc-4.0.0/configure --prefix=/usr/gcc-4.0 --disable-nls --disable-multilib --disable-intl --with-gnu-as --with-as=/usr/loc/bin/as.gnu --with-gnu-ld --with-ld=/usr/loc/bin/ld.gnu --enable-languages=c,c++ Thread model: single gcc version 4.0.0 C and C++ enabled only Build used gcc 2.95 as the bootstrap compiler as well as GNU binutils 2.15: lucy 77% gcc -v Reading specs from /usr/gcc-2.95.3/lib/gcc-lib/mips-sgi-irix6.3/2.95.3/specs gcc version 2.95.3 20010315 (release) lucy 75% /usr/loc/bin/as.gnu -v /dev/null GNU assembler version 2.15 (mips-sgi-irix6.3) using BFD version 2.15 lucy 76% /usr/loc/bin/ld.gnu -v GNU ld version 2.15 Remarks: 1. GNU as usage was explicitly requested (during configuration, AFAIR) 2. SGI ld failed (complaining about bad sections in OBJ files) 3. GNU as+ld combinations worked fine (testsuite not run...) BIG THANKS! Regards, Jan Okrasinski Warsaw/Poland __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Mainline Bootstrap failure on x86-64-linux-gnu
On Sat, Apr 23, 2005 at 09:07:23AM +0200, Andreas Jaeger wrote: > Current GCC CVS Mainline fails to bootstrap for me: > Odd, my x86_64 works just fine. Send me a .i file? Thanks. Diego.
Re: writeable-strings (gcc 4 and lower versions) clarification
On Saturday, April 23, 2005, at 12:35 AM, sting sting wrote: If you will comple with gcc This is the wrong list, please use gcc-help in the future. What are the disadvantages of using -fwritable-strings Acceptance of non-portable code. and why was it removed ? The 1980s are over. People didn't want to maintain it indefinitely, most the people that actually maintain their code, have long since removed the need for it. am I right ? Yes.
Re: different address spaces
> From: Zack Weinberg <[EMAIL PROTECTED]> >> James E Wilson <[EMAIL PROTECTED]> writes: >> >>> unnecessary, and error prone (as evidenced by string literal memory >>> references not being properly identified as READONLY, although their >>> equivalent array representations are treated properly for example?) >> >> If true, that sounds like a bug. This is the only interesting issue >> here from my point of view. You might consider filing a bug report into >> bugzilla for this. Or contributing a patch. > > This might just be the special case for string constants in C, that > their type is "char*" despite their being allocated in read-only > memory. Paul, before filing a bug, find out whether -Wwrite-strings > makes this alleged misbehavior go away; if it does, it's not a bug. I just double checked, neither -Wwrite-strings nor -fconst-strings seems to affect the READONLY attribute which should be associated with memory references to static const strings; an earlier PR was already filed: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21018 (with respect to: -Wwrite-strings, I would have thought that the option, although presently depreciated and disabled by default, would only have enabled writes to string literal references be specified at the language front-end level, but not affect the READONLY attribute associated with them at the tree level, as regardless of the option enabling such writes to be accepted, the objects are still a static literal constants, and may simply not be physically writeable regardless of -Wwrite-strings?)
Re: A bug in the current released GCC 4.0.0
On Apr 23, 2005, at 6:35 AM, ~{Dt>Clb~} wrote:
Hello,
I casually found a bug in the current released GCC 4.0.0. However, I
have located the wrong code, and it's very easy to be fixed, so it's
not
necessary to still submit a bug report. See the following artificial
C++ code:
int *x;
void f()
{
do
{
const int *&rx = (const int*&)(x);
rx = 0;
}while( *x );
}
This PR 21167 and 21173.
-- Pinski
Re: different address spaces
> From: Paul Schlie <[EMAIL PROTECTED]> > ... > (with respect to: -Wwrite-strings, I would have thought that the option, > although presently depreciated and disabled by default, would only have > enabled writes to string literal references be specified at the language > front-end level, but not affect the READONLY attribute associated with > them at the tree level, as regardless of the option enabling such writes > to be accepted, the objects are still a static literal constants, and may > simply not be physically writeable regardless of -Wwrite-strings?) Sorry, apparently -fwritable-strings was depreciated, not -Wwrite-strings; however regardless, since there's no such thing as a string type in C/C++, strings are arrays of char, so it would seem most consistent to treat them as such by default. Which means by default, you can't write to a string literal/static-const, although may specify their static const literal value: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21018
tcc_statement vs. tcc_expression in the C++ frontend
The description of tcc_statement in tree.h says "A statement expression, which have side effects but usually no interesting value." There are a number of entries in cp/cp-tree.def which are marked as tcc_expression, although they seem to me to be better described as tcc_statement, to wit: IF_STMT WHILE_STMT DO_STMT FOR_STMT BREAK_STMT CONTINUE_STMT SWITCH_STMT and perhaps also: EH_SPEC_BLOCK USING_STMT CLEANUP_STMT TRY_BLOCK HANDLER I tracked the first list above back to when they were introduced: Tue Feb 20 18:21:51 1996 Jason Merrill <[EMAIL PROTECTED]> * call.c class.c cp-tree.h cvt.c decl.c decl2.c error.c expr.c init.c lex.c method.c parse.y pt.c repo.c search.c spew.c tree.c tree.def typeck.c typeck2.c xref.c: Massive, systemic changes for the new template implementation. They were all introduced with class "e", which was later renamed to tcc_expression, which is what they are today. In a quick look at the C++ front end, I can only find one bit of code which cares whether it is looking at a tcc_expression or a tcc_statement: value_dependent_expression_p in pt.c. That function will always return false for a statement. For all of the tree codes listed above, currently class tcc_expression, the function will call itself recursively on expression operands. I haven't tried to track all the calls to see whether any of the above codes can be passed to value_dependent_expression_p, but it doesn't seem likely. In the main compiler, the main difference between tcc_expression and tcc_statement is whether TREE_SIDE_EFFECTS is set. (There are also some checks in tree-browser.c on EXPRESSION_CLASS_P which are probably unimportant.) For tcc_statement, TREE_SIDE_EFFECTS is always set. For tcc_expression, it is not. However, it happens that the C++ frontend builds the above codes using the function build_stmt, and that function will always set TREE_SIDE_EFFECTS for them. Anyhow, I'm testing the obvious patch to use tcc_statement instead of tcc_expression in cp-tree.def, and I will submit it to gcc-patches if it works. At the moment I'm curious as to whether anybody has a reason why these codes should be tcc_expression rather than tcc_statement. Ian
Re: The subreg question
James E Wilson wrote: Ling-hua Tseng wrote: It's obvious that `movil' and `movim' are only access the partial 16-bit of the 32-bit register. How can I use RTL expression to represent the operations? As you noticed, within a register, subreg can only be used for low parts. You can't ask for the high part of a single register. If you have an item that spans multiple registers, e.g. a 64-bit value that is contained in a register pair, then you can ask for the SImode highpart of a DImode reg and get valid RTL. This works because the high part is an entire register. This isn't useful to you. Otherwise, you can access subparts via bitfield insert/extract operations, or logicals operations (ior/and), though this is likely to be tedious, and may confuse optimizers. There are high/lo_sum RTL operators that may be useful to you. You can use (set (reg:SI) (high: ...)) (set (reg:SI) (lo_sum (reg:SI) (...))) where the first pattern corresponds to movims, and the second one to movil. You could just as well use ior instead of lo_sum for the second pattern, this is probably better as movil does not do an add. You may want to emit normal rtl for an SImode move, and then split it into its two 16-bit parts after reload. This will avoid confusing RTL optimizers before reload. We have vector modes which might be useful to you. If you say a register is holding a V4QI mode value, then there are natural ways to get at the individual elements of the vector via vector operations. I implemented my 4 `movi' cases in the following forms. The result of them sould be a 32-bit integer because the `movi' is in order to generate SImode immediate. The case 4 is special. It's also used to generate HImode and QImode immediates. Would you like to help me confirm them? (RTX semantics and the usage of `HI' mode) 1. set MSB 16-bit and clear LSB 16-bit to zero [(set (match_operand:SI 0 "register_operand" "=r") (high:SI (match_operand:SI 1 "immediate_operand" "i")))] (Does (high:SI ...) have the semantic of clearing LSB 16-bit ? ) 2. set MSB 16-bit and unchange/keep LSB 16-bit [(parallel [(set (high:SI (match_operand:SI 0 "register_operand" "=r")) (high:SI (match_operand:SI 1 "immediate_operand" "i"))) (set (strict_lowpart (subreg:HI (match_dup 0) 0)) (match_operand:HI "immediate_operand" "i"))])] (I know it's incorrect if the semantic of (high:SI ...) will change LSB 16-bit.) 3. set LSB 16-bit and clear MSB 16-bit to zero [(set (match_operand:SI 0 "register_operand" "=r") (match_operand:HI 1 "immediate_operand" "i"))] 4. set LSB 16-bit and unchange/keep LSB 16-bit [(set (strict_lowpart (subreg:HI (match_operand:SI 0 "register_operand" "=r") 0)) (match_operand:HI "immediate_operand" "i"))] (Would it better than use (lo_sum:SI ...) ? ) Thanks.
Re: tcc_statement vs. tcc_expression in the C++ frontend
Ian Lance Taylor wrote: The description of tcc_statement in tree.h says "A statement expression, which have side effects but usually no interesting value." There are a number of entries in cp/cp-tree.def which are marked as tcc_expression, although they seem to me to be better described as tcc_statement, to wit: In a quick look at the C++ front end, I can only find one bit of code which cares whether it is looking at a tcc_expression or a tcc_statement: value_dependent_expression_p in pt.c. That function will always return false for a statement. For all of the tree codes listed above, currently class tcc_expression, the function will call itself recursively on expression operands. I haven't tried to track all the calls to see whether any of the above codes can be passed to value_dependent_expression_p, but it doesn't seem likely. None of the statement nodes you mention can be value dependent. If that's the only place that cares, they should be tcc_statement. Anyhow, I'm testing the obvious patch to use tcc_statement instead of tcc_expression in cp-tree.def, and I will submit it to gcc-patches if it works. At the moment I'm curious as to whether anybody has a reason why these codes should be tcc_expression rather than tcc_statement. I cannot think of any. nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Built gcc 4.0.0, without C++ support
I configured/made/installed gcc 4.0.0 partially on a Solaris host. I could not build with C++ support, because ld (GNU ld, that is) choked (dumped core, signal 11, segmentation violation) on abi_check (see below). When using the Sun-supplied as and ld, ld chokes on alignment errors during bootstrap. Note that builds on Solaris 10 on AMD Opteron (on a Sun Fire V20z) failed miserably. With the Sun-supplied as and ld, bootstraps chokes on syntax errors in assembly files; with GNU as and ld, bootstrap chockes on invalid instructions (64-bit AMD instructions not handled by as?). Build status info: - $ /phil/sw/src/gcc-4.0.0/config.guess sparc-sun-solaris2.7 $ gcc -v Using built-in specs. Target: sparc-sun-solaris2.7 Configured with: /phil/sw/src/gcc-4.0.0/configure --prefix=/phil/sw/sunos/sparc/pkg/gcc-4.0.0 --disable-libgcj --enable-languages=c,c++,objc --with-gnu-as --with-as=/phil/sw/sunos/sparc/bin/as --with-gnu-ld --with-ld=/phil/sw/sunos/sparc/bin/ld : (reconfigured) /phil/sw/src/gcc-4.0.0/configure --prefix=/phil/sw/sunos/sparc/pkg/gcc-4.0.0 --disable-libgcj --enable-languages=c,objc --with-gnu-as --with-as=/phil/sw/sunos/sparc/bin/as --with-gnu-ld --with-ld=/phil/sw/sunos/sparc/bin/ld Thread model: posix gcc version 4.0.0 Coredump on abi_check ld: $ make [...] bootstrap [...] creating libstdc++.la (cd .libs && rm -f libstdc++.la && ln -s ../libstdc++.la libstdc++.la) Making all in po Making all in testsuite mkdir .libs /phil/sw/sunos/sparc/obj/gcc-4.0.0/gcc/g++ -shared-libgcc -B/phil/sw/sunos/sparc/obj/gcc-4.0.0/gcc/ -nostdinc++ -B/phil/sw/sunos/sparc/pkg/gcc-4.0.0/sparc-sun-solaris2.7/bin/ -B/phil/sw/sunos/sparc/pkg/gcc-4.0.0/sparc-sun-solaris2.7/lib/ -isystem /phil/sw/sunos/sparc/pkg/gcc-4.0.0/sparc-sun-solaris2.7/include -isystem /phil/sw/sunos/sparc/pkg/gcc-4.0.0/sparc-sun-solaris2.7/sys-include -g -O2 -D_GLIBCXX_ASSERT -ffunction-sections -fdata-sections -fmessage-length=0 -DLOCALEDIR=/phil/sw/sunos/sparc/obj/gcc-4.0.0/sparc-sun-solaris2.7/libstdc++-v3/po/share/locale -g -O2 -o abi_check abi_check.o -L/phil/sw/sunos/sparc/obj/gcc-4.0.0/sparc-sun-solaris2.7/libstdc++-v3/src -L/phil/sw/sunos/sparc/obj/gcc-4.0.0/sparc-sun-solaris2.7/libstdc++-v3/src/.libs -lv3test -L/phil/sw/sunos/sparc/obj/gcc-4.0.0/sparc-sun-solaris2.7/libstdc++-v3/testsuite -Wl,--rpath -Wl,/phil/sw/sunos/sparc/obj/gcc-4.0.0/gcc -Wl,--rpath -Wl,/phil/sw/sunos/sparc/obj/gcc-4.0.0/sparc-sun-solaris2.7/libstdc++-v3/src/.libs collect2: ld terminated with signal 11 [Segmentation Fault], core dumped make[4]: *** [abi_check] Error 1 make[3]: *** [all-recursive] Error 1 make[2]: *** [all] Error 2 make[1]: *** [all-target-libstdc++-v3] Error 2 make: *** [bootstrap] Error 2 Regards, Jeroen.
Re: Built gcc 4.0.0, without C++ support
On Sat, 23 Apr 2005, Jeroen Scheerder wrote: > Note that builds on Solaris 10 on AMD Opteron (on a Sun Fire V20z) failed > miserably. With the Sun-supplied as and ld, bootstraps chokes on syntax > errors in assembly files; with GNU as and ld, bootstrap chockes on > invalid instructions (64-bit AMD instructions not handled by as?). I recommend using GNU as and Sun ld. /usr/sfw/bin/as should be a suitable version of the GNU assembler, or try the 2.15.97 binutils snapshot (from ftp://gcc.gnu.org/pub/binutils/snapshots/) for an assembler which should also be sufficiently recent (soon to be released as 2.16); I don't know if the 2.15 release is recent enough. The version of GCC distributed in /usr/sfw/bin is configured with --with-as=/usr/sfw/bin/gas --with-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++ --enable-shared which should be a configuration which works for 4.0.0 and mainline, as well as for csl-sol210-3_4-branch from which /usr/sfw/bin/gcc comes. -- Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/ [EMAIL PROTECTED] (personal mail) [EMAIL PROTECTED] (CodeSourcery mail) [EMAIL PROTECTED] (Bugzilla assignments and CCs)
Proposal: GCC core changes for different address spaces
After some discussion, how to create transparent access to different memory transparently, I propose the following solution: We change the GCC core to store the type of each memory expression in the MEM rtx. Backends can use this type information to create a diffent RTL or output a different assembler instruction. The details, how this is done, is the choice of the port. A limitation will be, that some RTL passes change or create memory references and thereby destroy the type attribute. James E Wilson also wrote, that this type information my help for other problems: >For instance, taking the address of packed data and then >dereferencing it fails, because we have no way to mark MEMs as pointing >to packed data. In GCC, a backend could use this in the following way: It defines an attribute (eg. eeprom), which is added to variables and types. The GCC core keeps in all tree based representation already track of such an attribute. Through the type attribute, this information will be available for machine description, which can use this information to generate different instructions. A backend may need multiple of such attributes (avr: progmem and eeprom). For implementing the type attributes, I propose: Add the field "tree type;" to "struct mem_attrs". This field holds the type, if present, or 0, if no type information is available. To access it, I propose: #define MEM_TYPE(RTX) (MEM_ATTRS (RTX) == 0 ? 0 : MEM_ATTRS (RTX)->type) set_mem_attributes_minus_bitpos will set MEM_TYPE, if it is not already set, so the tree to RTL expander adds automatically the type information. All functions, which copy the memory attributes, will also copy the type information. A function set_mem_type to set the type information will be added. Open questions are: *Do we need to print the type information and how verbose in print_rtx? *What to do, if the reload pass copy the REG_EXPR to a MEM_EXPR (set_mem_attrs_from_reg)? If REG_EXPR, copy the type of REG_EXPR, else keep the old type? Or add type information also to REG_ATTRS? Before I start experimenting with this, I want other people opinions, how acceptable this proposal will be for GCC mainline or if it can be improved. A discouraged solution, because it need a change of the interpretation of MEM_EXPR, was: We allow GCC to store in MEM_EXPR not only a DECL or COMPONENT_REF. In the case, something is stored in MEM_EXPR, the type information is present. In any other case, a type will be stored in it (or maybe the full tree expression, which may give additional information to an optimizer). GCC seems to have with this solution no problem, as far as my experiments have shown. An asseration and a missing case in the RTX output need to be changed for my GCC port. mfg Martin Kögler
Re: tcc_statement vs. tcc_expression in the C++ frontend
Ian Lance Taylor writes: | The description of tcc_statement in tree.h says "A statement | expression, which have side effects but usually no interesting value." | | There are a number of entries in cp/cp-tree.def which are marked as | tcc_expression, although they seem to me to be better described as | tcc_statement, to wit: | | IF_STMT | WHILE_STMT | DO_STMT | FOR_STMT | BREAK_STMT | CONTINUE_STMT | SWITCH_STMT | | and perhaps also: | | EH_SPEC_BLOCK | USING_STMT | CLEANUP_STMT | TRY_BLOCK | HANDLER They all should be tcc_statement, now. I believe they were marked class 'e' back then when we did not have a clearly marked class for statements. -- Gaby
Stack frame question on x86 code generation
Could anyone help me understand what is the gcc
strategy to prepare the stack frame?
For the following function,
void function(int a, int b, int c)
{
char buffer1[5];
char buffer2[10];
int *ret;
ret = &buffer1[0]+28;
printf("0x%x=return address, *ret);
}
I compiled with gcc -O0 -S option and the compiler
produces the code that I cannot quite follow the
stack frame layout strategy in gcc.
function:
pushl %ebp
movl%esp, %ebp
subl$56, %esp // question 1
leal-24(%ebp), %eax
addl$28, %eax
movl%eax, -44(%ebp)
subl$8, %esp// question 2
movl-44(%ebp), %eax
pushl (%eax)
pushl $.LC0
callprintf
Here are my questions:
question1: Why the stack frame size is 56?
observation: (1) compiler add 16 bytes
padding before allocating storage
for array buffer1 (2) buffer1 need
5 bytes. However, due to alignment
issue, they seem to add 3 extra bytes.
Thus, -24(%ebp) should point to buffer1[0].
Then, why they adding 16 bytes padding?
question2: Why gcc makes the stack frame bigger before
the function call printf?
subl$8, %esp
Does it related to printf? If it does, then
could you explain why?
Thanks in advance.
Best regards,
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Proposal: GCC core changes for different address spaces
> Martin Koegler wrote: > ... > Before I start experimenting with this, I want other people opinions, > how acceptable this proposal will before GCC mainline or if it can be > improved. - sound's good, and a natural generalization of current mem ref attributes. (However ideally, function parameter and result value references would need to be similarly qualify-able in order to enable the proper attributes to be associated and enforced when references to such attributed objects are passed-to/returned-from function calls; as otherwise the object's storage reference attribute will be lost; which could in theory could be enabled by allowing the qualification an arbitrary variable, parameter, result storage type reference as a natural extension; thereby allowing the specification of a pointer parameter to a static const value be specified as "(static const)*", as opposed to being parsed as "static (const *) by default which specifies a static pointer parameter which is prohibited, therefore wouldn't introduce an ambiguity if the optionally enabled.)
Re: Proposal: GCC core changes for different address spaces
On Sat, Apr 23, 2005 at 07:18:22PM +0200, Martin Koegler wrote: > For implementing the type attributes, I propose: > Add the field "tree type;" to "struct mem_attrs". This field holds the type, > if present, > or 0, if no type information is available. > > To access it, I propose: > #define MEM_TYPE(RTX) (MEM_ATTRS (RTX) == 0 ? 0 : MEM_ATTRS (RTX)->type) I'd prefer that there be a flags field, akin to SYMBOL_REF_FLAGS. You're going to have to check this property quite often; I'd rather the data be cached somewhere easy to get at, rather than burried in some data structure 4 levels removed. The flags field of the mem could be initialized by a target function that receives the decl or type, as received by set_mem_attributes. > *What to do, if the reload pass copy the REG_EXPR to a > MEM_EXPR (set_mem_attrs_from_reg)? I would expect you to do nothing. r~
Re: Proposal: GCC core changes for different address spaces
> From: Paul Schlie <[EMAIL PROTECTED]> >> Martin Koegler wrote: >> ... >> Before I start experimenting with this, I want other people opinions, >> how acceptable this proposal will before GCC mainline or if it can be >> improved. > > - sound's good, and a natural generalization of current mem ref attributes. > > (However ideally, function parameter and result value references would need > to be similarly qualify-able in order to enable the proper attributes to > be associated and enforced when references to such attributed objects are > passed-to/returned-from function calls; as otherwise the object's storage > reference attribute will be lost; which could in theory could be enabled > by allowing the qualification an arbitrary variable, parameter, result > storage type reference as a natural extension; thereby allowing the > specification of a pointer parameter to a static const value be specified > as "(static const)*", as opposed to being parsed as "static (const *) by > default which specifies a static pointer parameter which is prohibited, > therefore wouldn't introduce an ambiguity if the optionally enabled.) To be somewhat clearer, a storage class could potentially qualify the type of an referenced object, just as the target specific type qualifiers may (i.e. rom, eeprom, progmem, etc.) when used within the context of a function parameter or result type specification, i.e. (rom const)* or (static const)* as a possibility to enable the more generic, and somewhat less target specific qualification of static-const/literal and label/function() mem references in addition to the use of more target specific named ones?
Re: Built gcc 4.0.0, without C++ support
Joseph S. Myers: > On Sat, 23 Apr 2005, Jeroen Scheerder wrote: > > > Note that builds on Solaris 10 on AMD Opteron (on a Sun Fire V20z) failed > > miserably. With the Sun-supplied as and ld, bootstraps chokes on syntax > > errors in assembly files; with GNU as and ld, bootstrap chockes on > > invalid instructions (64-bit AMD instructions not handled by as?). > > I recommend using GNU as and Sun ld. /usr/sfw/bin/as should be a suitable > version of the GNU assembler, or try the 2.15.97 binutils snapshot (from > ftp://gcc.gnu.org/pub/binutils/snapshots/) for an assembler which should > also be sufficiently recent (soon to be released as 2.16); I don't know if > the 2.15 release is recent enough. The version of GCC distributed in > /usr/sfw/bin is configured with > > --with-as=/usr/sfw/bin/gas --with-gnu-as --with-ld=/usr/ccs/bin/ld > --without-gnu-ld --enable-languages=c,c++ --enable-shared > > which should be a configuration which works for 4.0.0 and mainline, as > well as for csl-sol210-3_4-branch from which /usr/sfw/bin/gcc comes. Partial success only. I think I'll be able to build it without C++ support, but compilation per your instruction does choke on libstdc++.so.6.0.4. This is how I configured/compiled it: $ which as; as --version /phil/sw/sunos/i386/bin/as GNU assembler 2.15.97 20050420 Copyright 2005 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. This assembler was configured for a target of `i386-pc-solaris2.10'. $ /phil/sw/src/gcc-4.0.0/configure \ --prefix=/phil/sw/sunos/i386/pkg/gcc-4.0.0 \ --disable-libgcj \ --enable-languages=c,c++,objc \ --with-gnu-as \ --with-as=/phil/sw/sunos/i386/bin/as \ --without-gnu-ld \ --with-ld=/usr/ccs/bin/ld \ --enable-shared $ make -sj3 CFLAGS='-O' LIBCFLAGS='-g -O2' \ LIBCXXFLAGS='-g -O2 -fno-implicit-templates' bootstrap [...] Building runtime libraries config.status: creating config.h config.status: config.h is unchanged Checking multilib configuration... multilib.out is unchanged Making all in include Making all in libsupc++ Making all in libmath Making all in src rm -fr .libs/libstdc++.lax rm -fr .libs/libstdc++.lax mkdir .libs/libstdc++.lax rm -fr .libs/libstdc++.lax/libmath.a mkdir .libs/libstdc++.lax/libmath.a (cd .libs/libstdc++.lax/libmath.a && ar x /phil/sw/sunos/i386/obj/gcc-4.0.0/i386-pc-solaris2.10/libstdc++-v3/src/../libmath/.libs/libmath.a) rm -fr .libs/libstdc++.lax/libsupc++convenience.a mkdir .libs/libstdc++.lax/libsupc++convenience.a (cd .libs/libstdc++.lax/libsupc++convenience.a && ar x /phil/sw/sunos/i386/obj/gcc-4.0.0/i386-pc-solaris2.10/libstdc++-v3/src/../libsupc++/.libs/libsupc++convenience.a) /phil/sw/sunos/i386/obj/gcc-4.0.0/gcc/xgcc -shared-libgcc -B/phil/sw/sunos/i386/obj/gcc-4.0.0/gcc/ -nostdinc++ -L/phil/sw/sunos/i386/obj/gcc-4.0.0/i386-pc-solaris2.10/libstdc++-v3/src -L/phil/sw/sunos/i386/obj/gcc-4.0.0/i386-pc-solaris2.10/libstdc++-v3/src/.libs -B/phil/sw/sunos/i386/pkg/gcc-4.0.0/i386-pc-solaris2.10/bin/ -B/phil/sw/sunos/i386/pkg/gcc-4.0.0/i386-pc-solaris2.10/lib/ -isystem /phil/sw/sunos/i386/pkg/gcc-4.0.0/i386-pc-solaris2.10/include -isystem /phil/sw/sunos/i386/pkg/gcc-4.0.0/i386-pc-solaris2.10/sys-include -shared -nostdlib /usr/lib/crti.o /usr/lib/values-Xa.o /phil/sw/sunos/i386/obj/gcc-4.0.0/gcc/crtbegin.o .libs/bitmap_allocator.o .libs/pool_allocator.o .libs/mt_allocator.o .libs/codecvt.o .libs/complex_io.o .libs/ctype.o .libs/debug.o .libs/debug_list.o .libs/functexcept.o .libs/globals_locale.o .libs/globals_io.o .libs/ios.o .libs/ios_failure.o .libs/ios_init.o .libs/ios_locale.o .libs/limits.o .libs/list.o .libs/locale.o .libs/locale_init.o .libs/locale_facets.o .libs/localename.o .libs/stdexcept.o .libs/strstream.o .libs/tree.o .libs/allocator-inst.o .libs/concept-inst.o .libs/fstream-inst.o .libs/ext-inst.o .libs/io-inst.o .libs/istream-inst.o .libs/istream.o .libs/locale-inst.o .libs/locale-misc-inst.o .libs/misc-inst.o .libs/ostream-inst.o .libs/sstream-inst.o .libs/streambuf-inst.o .libs/streambuf.o .libs/string-inst.o .libs/valarray-inst.o .libs/wlocale-inst.o .libs/wstring-inst.o .libs/atomicity.o .libs/codecvt_members.o .libs/collate_members.o .libs/ctype_members.o .libs/messages_members.o .libs/monetary_members.o .libs/numeric_members.o .libs/time_members.o .libs/basic_file.o .libs/c++locale.o .libs/libstdc++.lax/libmath.a/stubs.o .libs/libstdc++.lax/libmath.a/signbit.o .libs/libstdc++.lax/libmath.a/signbitf.o .libs/libstdc++.lax/libmath.a/signbitl.o .libs/libstdc++.lax/libsupc++convenience.a/del_op.o .libs/libstdc++.lax/libsupc++convenience.a/del_opnt.o .libs/libstdc++.lax/libsupc++convenience.a/del_opv.o .libs/libstdc++.lax/libsupc++convenience.a/del_opvnt.o .libs/libstdc++.lax/libsupc++convenience.a/eh_alloc.o .libs/libstdc++.lax/libsupc++convenience.
spill_failure
Hi,
I have been adding some profiling stuff onto the RTL. I get the following
error in reload phase. Can someone tell me how to fix this? I use 8th
April 2005
check out from CVS.
./mul_mdmd_md.c: In function âmul_mdmd_md_l1_arb_allâ:
./mul_mdmd_md.c:343: error: unable to find a register to spill in class
âAD_REGSâ
./mul_mdmd_md.c:343: error: this is the insn:
(insn 529 8 530 0 (parallel [
(set (reg:DI 232)
(sign_extend:DI (reg/v:SI 149 [ M ])))
(clobber (reg:CC 17 flags))
(clobber (scratch:SI))
]) 82 {*extendsidi2_1} (nil)
(expr_list:REG_UNUSED (scratch:SI)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
./mul_mdmd_md.c:343: internal compiler error: in spill_failure, at
reload1.c:1885
regards,
Raj
Re: spill_failure
On Sunday 24 April 2005 00:22, Rajkishore Barik wrote:
> Hi,
>
> I have been adding some profiling stuff onto the RTL. I get the following
> error in reload phase. Can someone tell me how to fix this? I use 8th
> April 2005 check out from CVS.
Hmm, let me rephrase your question:
"I did some GCC hacking that I'm not showing, and it doesn't work,
please help me fix it."
That's quite hard, you know. You'll have to be more specific.
> ./mul_mdmd_md.c: In function âmul_mdmd_md_l1_arb_allâ:
> ./mul_mdmd_md.c:343: error: unable to find a register to spill in class
> âAD_REGSâ
> ./mul_mdmd_md.c:343: error: this is the insn:
> (insn 529 8 530 0 (parallel [
> (set (reg:DI 232)
> (sign_extend:DI (reg/v:SI 149 [ M ])))
> (clobber (reg:CC 17 flags))
> (clobber (scratch:SI))
> ]) 82 {*extendsidi2_1} (nil)
> (expr_list:REG_UNUSED (scratch:SI)
> (expr_list:REG_UNUSED (reg:CC 17 flags)
> (nil
> ./mul_mdmd_md.c:343: internal compiler error: in spill_failure, at
> reload1.c:1885
What this basically says is that after register allocation some insns
do not have all their operand constraints satisfied, so reload needs
to fix up something, but it cannot use the registers it needs.
But since you're not showing what you've added, it's hard to tell what
the real problem is.
Gr.
Steven
Re: Obsoleting c4x last minute for 4.0
On Wed, 6 Apr 2005, Joseph S. Myers wrote: > (If test results for a port are so bad that > though sent to gcc-testresults they exceed the message size limit, and > this remains the case for a prolonged period such as ever since 4.0 > branched, that also indicates lack of active maintenance.) No, it could just as well be a problem with the library, as is the case for libgfortran; tests still run even though it's disabled for mmix-knuth-mmixware. (There's a PR about it somewhere, IIRC.) Having said that, I do *not* consider it a requirement or equivalent for port maintenance to send test-results to gcc-testresults at any specific time or interval. For simulators with free components, people can run the tests themselves if they're interested. brgds, H-P
Re: Obsoleting c4x last minute for 4.0
On Sat, 23 Apr 2005, Hans-Peter Nilsson wrote: > On Wed, 6 Apr 2005, Joseph S. Myers wrote: > > (If test results for a port are so bad that > > though sent to gcc-testresults they exceed the message size limit, and > > this remains the case for a prolonged period such as ever since 4.0 > > branched, that also indicates lack of active maintenance.) > > No, it could just as well be a problem with the library, as is > the case for libgfortran; tests still run even though it's > disabled for mmix-knuth-mmixware. (There's a PR about it > somewhere, IIRC.) The *fortran* tests still run (and the front-end is built) although libgfortran is disabled. It seems I was mistaken about there being a PR. Hum. For cris-elf, the fortran tests just FAIL all over due to missing references to ftruncate, dup and access (not provided by newlib but apparently assumed by libgfortran). Last time I checked, there was very little maintaier interest in getting cross-building and cross-testing to work for fortran. I myself have no interest in it other than as a testbed. brgds, H-P
gcc-4.0-20050423 is now available
Snapshot gcc-4.0-20050423 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20050423/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.0 CVS branch with the following options: -rgcc-ss-4_0-20050423 You'll find: gcc-4.0-20050423.tar.bz2 Complete GCC (includes all of below) gcc-core-4.0-20050423.tar.bz2 C front end and core compiler gcc-ada-4.0-20050423.tar.bz2 Ada front end and runtime gcc-fortran-4.0-20050423.tar.bz2 Fortran front end and runtime gcc-g++-4.0-20050423.tar.bz2 C++ front end and runtime gcc-java-4.0-20050423.tar.bz2 Java front end and runtime gcc-objc-4.0-20050423.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.0-20050423.tar.bz2The GCC testsuite Diffs from 4.0-20050416 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.0 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: Obsoleting c4x last minute for 4.0
On Apr 23, 2005, at 7:40 PM, Hans-Peter Nilsson wrote: On Sat, 23 Apr 2005, Hans-Peter Nilsson wrote: On Wed, 6 Apr 2005, Joseph S. Myers wrote: (If test results for a port are so bad that though sent to gcc-testresults they exceed the message size limit, and this remains the case for a prolonged period such as ever since 4.0 branched, that also indicates lack of active maintenance.) No, it could just as well be a problem with the library, as is the case for libgfortran; tests still run even though it's disabled for mmix-knuth-mmixware. (There's a PR about it somewhere, IIRC.) The *fortran* tests still run (and the front-end is built) although libgfortran is disabled. It seems I was mistaken about there being a PR. Hum. For cris-elf, the fortran tests just FAIL all over due to missing references to ftruncate, dup and access (not provided by newlib but apparently assumed by libgfortran). All of the above functions are part of POSIX which is why libgfortran assumes them. -- Pinski
how small can gcc get?
I am writing a gui app in another language that needs the gcc compiler embedded into it (or at least along for the ride), in case the user doesn't have it on their system. What's the smallest size I can squeeze gcc down to and how would I go about compiling it in such a way? I'm on an OS X box with gcc 3.x installed already. I'll probably be creating a disk image and installing the little gcc into it. Direct help would be great, but pointing me to a helpful article(s) would be great too. Thanks. - Philip
[RFA] Invalid mmap(2) assumption in pch (ggc-common.c)
Running the libstdc++ testsuite on NetBSD/sparc or NetBSD/sparc64 results in most tests failing like: :1: fatal error: had to relocate PCH compilation terminated. compiler exited with status 1 This is due to a misassumption in ggc-common.c:654 (mmap_gt_pch_use_address): This version assumes that the kernel honors the START operand of mmap even without MAP_FIXED if START through START+SIZE are not currently mapped with something. That is not true for NetBSD. Due to MMU idiosyncracies, some architecures (like sparc and sparc64) will align mmap requests that don't have MAP_FIXED set for architecture specific reasons). Is there a reason why MAP_FIXED isn't used even though it probably should be? -- Matt Thomas email: [EMAIL PROTECTED] 3am Software Foundry www: http://3am-software.com/bio/matt/ Cupertino, CA disclaimer: I avow all knowledge of this message.
Re: spill_failure
> Hmm, let me rephrase your question:
> "I did some GCC hacking that I'm not showing, and it doesn't work,
> please help me fix it."
This is not what I meant. I meant if similar problem has been reported by
anyone else before. In any case. This is the piece of code that I add
after every integer "set" instruction returned from "single_set()" module.
// "insn" being the current integer set instruction
// "value" being the "destination" of the set instruction
// GCOV_COUNTER_V_RANGE is a new Value Range Counter added by me
enum machine_mode mode = mode_for_size (GCOV_TYPE_SIZE, MODE_INT, 0);
start_sequence ();
rtx stored_val_ref = rtl_coverage_counter_ref(GCOV_COUNTER_V_RANGE,
0);
rtx stored_val = validize_mem (stored_val_ref);
rtx uval = gen_reg_rtx (mode);
convert_move (uval, copy_rtx (value), 0);
rtx tmp=expand_simple_binop(mode, IOR,copy_rtx(uval),
copy_rtx(stored_val),stored_val,0, OPTAB_WIDEN);
sequence = get_insns ();
end_sequence ();
emit_insn_after(sequence,insn);
Note that I these pieces of code just before register allocation and code
scheduling are done.
> > ./mul_mdmd_md.c: In function âmul_mdmd_md_l1_arb_allâ:
> > ./mul_mdmd_md.c:343: error: unable to find a register to spill in
class
> > âAD_REGSâ
> > ./mul_mdmd_md.c:343: error: this is the insn:
> > (insn 529 8 530 0 (parallel [
> > (set (reg:DI 232)
> > (sign_extend:DI (reg/v:SI 149 [ M ])))
> > (clobber (reg:CC 17 flags))
> > (clobber (scratch:SI))
> > ]) 82 {*extendsidi2_1} (nil)
> > (expr_list:REG_UNUSED (scratch:SI)
> > (expr_list:REG_UNUSED (reg:CC 17 flags)
> > (nil
> > ./mul_mdmd_md.c:343: internal compiler error: in spill_failure, at
> > reload1.c:1885
> What this basically says is that after register allocation some insns
> do not have all their operand constraints satisfied, so reload needs
> to fix up something, but it cannot use the registers it needs.
The same piece of code works fine for me for the whole lot of benchmarks
without having any problem. Its a few which cause this AD_REG spill
problem.
I am wondering why is this happening.
--R
Re: c54x port
Bryan Richter wrote: > Joe Buck wrote: > > > > > > Please read > > > > http://gcc.gnu.org/contribute.html > > Right- I've read this and I'm aware of the situation. I am prepared to 'keep > my > ducks in a row'. :) After mulling it over for a day, I now realize that developing it separately is not wise. As such, I'm now volunteering to develop the c54x port directly in the main tree. Can someone assist me in getting the necessary copyright assignment forms? Thanks, -Bryan -- Bryan Richter UCDTT President UC Davis Undergrad, Physics Dept. - A PGP signature is (probably) attached to this email. PGP Key ID: BB8E6CCC signature.asc Description: Digital signature
Re: [RFA] Invalid mmap(2) assumption in pch (ggc-common.c)
On Apr 23, 2005, at 5:42 PM, Matt Thomas wrote: Running the libstdc++ testsuite on NetBSD/sparc or NetBSD/sparc64 results in most tests failing like: :1: fatal error: had to relocate PCH compilation terminated. compiler exited with status 1 This is due to a misassumption in ggc-common.c:654 (mmap_gt_pch_use_address): This version assumes that the kernel honors the START operand of mmap even without MAP_FIXED if START through START+SIZE are not currently mapped with something. That is not true for NetBSD. Due to MMU idiosyncracies, some architecures (like sparc and sparc64) will align mmap requests that don't have MAP_FIXED set for architecture specific reasons). Is there a reason why MAP_FIXED isn't used even though it probably should be? I can't speak directly to your question, but you might try the version in config/host-darwin.[ch]. This implementation statically allocates a 1G array in the bss, unmaps it, and maps the PCH there. As the commentary indicates, it looks kludgy, but it does seem to make PCH more reliable. I'm not absolutely clear on the details anymore, but I think you need host-darwin.c in your link, and host-darwin.h must be #included wherever you initialize your host langhooks. (You could also try MAP_FIXED yourself; that's certainly easier than my suggestion above. :-) stuart hastings Apple Computer
Is there a way to specify profile data file directory?
When -fprofile-arcs is used, the directory of profile data is fixed to the build directory. If I want to run the binary on a different machine, I have to create the same directory, which may not be very easy. Is this intentional? Can we have have an option to specify the different dirctory or to use the current dirctory at the run-time? H.J.
benchmark call malloc a lot?
Hi, Any bechmarks which are dynamic storage alloca intensive? Or call malloc like func a lot? Thanks, Zhenyu
Re: [RFA] Invalid mmap(2) assumption in pch (ggc-common.c)
Matt Thomas <[EMAIL PROTECTED]> writes: > Running the libstdc++ testsuite on NetBSD/sparc or NetBSD/sparc64 > results in most tests failing like: > > :1: fatal error: had to relocate PCH > compilation terminated. > compiler exited with status 1 > > This is due to a misassumption in ggc-common.c:654 > (mmap_gt_pch_use_address): > > This version assumes that the kernel honors the START operand of mmap > even without MAP_FIXED if START through START+SIZE are not currently > mapped with something. > > That is not true for NetBSD. Due to MMU idiosyncracies, some architecures > (like sparc and sparc64) will align mmap requests that don't have MAP_FIXED > set for architecture specific reasons). > > Is there a reason why MAP_FIXED isn't used even though it probably > should be? Because on many systems MAP_FIXED causes the new mapping to silently displace any existing mapping. That will break gcc, as the the displaced mapped pages will most likely have been allocated by the garbage collector. My reading of uvm_mmap() in uvm_mmap.c is that NetBSD is such a system. There are two possible fixes, either appropriate for config/host-netbsd.c or perhaps config/host-bsd.c. The first possible fix is to copy the approach used in config/host-linux.c, and pick a specific address for each supported architecture which gcc can reasonably expect to be available. The second possible fix is to copy the approach used on config/host-solaris.c, and use mincore to check whether any pages will be silently displaced before using MAP_FIXED. Ian
Re: spill_failure
Rajkishore Barik <[EMAIL PROTECTED]> writes:
> > Hmm, let me rephrase your question:
> > "I did some GCC hacking that I'm not showing, and it doesn't work,
> > please help me fix it."
>
> This is not what I meant. I meant if similar problem has been reported by
> anyone else before.
Everybody who works with the backend has seen this particular error
all too often. It doesn't have any one cause. As Steven said, it
means that reload was unable to find enough registers to do work which
it needed to do.
In any case. This is the piece of code that I add
> after every integer "set" instruction returned from "single_set()" module.
>
> // "insn" being the current integer set instruction
> // "value" being the "destination" of the set instruction
> // GCOV_COUNTER_V_RANGE is a new Value Range Counter added by me
> enum machine_mode mode = mode_for_size (GCOV_TYPE_SIZE, MODE_INT, 0);
> start_sequence ();
> rtx stored_val_ref = rtl_coverage_counter_ref(GCOV_COUNTER_V_RANGE,
> 0);
> rtx stored_val = validize_mem (stored_val_ref);
> rtx uval = gen_reg_rtx (mode);
> convert_move (uval, copy_rtx (value), 0);
> rtx tmp=expand_simple_binop(mode, IOR,copy_rtx(uval),
> copy_rtx(stored_val),stored_val,0, OPTAB_WIDEN);
> sequence = get_insns ();
> end_sequence ();
> emit_insn_after(sequence,insn);
>
> Note that I these pieces of code just before register allocation and code
> scheduling are done.
I note that these are reasonably complex operations to be adding this
late in the compiler. And that you don't have the case of tmp !=
stored_val. The insn on which reload crashes strongly suggests that
this is a DImode value, which is particularly awkward on the x86
because of the paucity of registers. The code above appears to
convert the DImode value to SImode anyhow.
> > > ./mul_mdmd_md.c: In function Ãmul_mdmd_md_l1_arb_allÃ:
> > > ./mul_mdmd_md.c:343: error: unable to find a register to spill in
> class
> > > ÃAD_REGSÃ
> > > ./mul_mdmd_md.c:343: error: this is the insn:
> > > (insn 529 8 530 0 (parallel [
> > > (set (reg:DI 232)
> > > (sign_extend:DI (reg/v:SI 149 [ M ])))
> > > (clobber (reg:CC 17 flags))
> > > (clobber (scratch:SI))
> > > ]) 82 {*extendsidi2_1} (nil)
> > > (expr_list:REG_UNUSED (scratch:SI)
> > > (expr_list:REG_UNUSED (reg:CC 17 flags)
> > > (nil
> > > ./mul_mdmd_md.c:343: internal compiler error: in spill_failure, at
> > > reload1.c:1885
> > What this basically says is that after register allocation some insns
> > do not have all their operand constraints satisfied, so reload needs
> > to fix up something, but it cannot use the registers it needs.
>
> The same piece of code works fine for me for the whole lot of benchmarks
> without having any problem. Its a few which cause this AD_REG spill
> problem.
> I am wondering why is this happening.
Basically because reload has been baffled. It picked an alternative
but was unable to find the particular registers required to fill that
alternative.
I don't know whether you mentioned which sources you are using. The
error message indicates that reload is looking for AD_REGS. I'm not
sure why this would happen in mainline, where extendsidi2_1 only uses
AD_REGS if the value is already there. But I think it may be possible
for reload to pick a particular alternative, then be forced to spill
the register, and then still try to stick to the originally chosen
alternative. If so, that would cause this kind of failure.
You might consider not adding your code for DImode values.
Ian
One fully and one partially successful build
Successful build: $ which as; as --version /phil/sw/sunos/sparc/bin/as GNU assembler 2.15.97 20050420 Copyright 2005 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. This assembler was configured for a target of `sparc-sun-solaris2.7'. $ /phil/sw/src/gcc-4.0.0/config.guess sparc-sun-solaris2.7 $ gcc -v Using built-in specs. Target: sparc-sun-solaris2.7 Configured with: /phil/sw/src/gcc-4.0.0/configure --prefix=/phil/sw/sunos/sparc/pkg/gcc-4.0.0 --disable-libgcj --enable-languages=c,c++,objc --with-gnu-as --with-as=/phil/sw/sunos/sparc/bin/as --with-gnu-ld --with-ld=/phil/sw/sunos/sparc/bin/ld --enable-shared Thread model: posix gcc version 4.0.0 Partially successful build: $ /phil/sw/src/gcc-4.0.0/config.guess i386-pc-solaris2.10 $ which as; as --version; which ld; ld --version /phil/sw/sunos/i386/bin/as GNU assembler 2.15.97 20050420 Copyright 2005 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. This assembler was configured for a target of `i386-pc-solaris2.10'. /phil/sw/sunos/i386/bin/ld GNU ld version 2.15.97 20050420 Copyright 2005 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. $ gcc -v Using built-in specs. Target: i386-pc-solaris2.10 Configured with: /phil/sw/src/gcc-4.0.0/configure --prefix=/phil/sw/sunos/i386/pkg/gcc-4.0.0 --disable-libgcj --enable-languages=c,objc --with-gnu-as --with-as=/phil/sw/sunos/i386/bin/as --without-gnu-ld --with-ld=/usr/ccs/bin/ld --enable-shared Thread model: posix gcc version 4.0.0 Building with C++ support fails, because the linker chokes when linking libstdc++.so.6.0.4: "" ld: fatal: relocation error: file: .libs/stdexcept.o section: .rel.debug_info symbol: : relocation against a discarded symbol, symbol is part of discarded section: .gnu.linkonce.t._ZNSt12out_of_rangeD0Ev collect2: ld returned 1 exit status make[4]: *** [libstdc++.la] Error 1 "" Using Sun's ld instead of GNU ld didn't work here (it did when building 3.4.3), because GNU ld chokes on /usr/lib/amd64/crti.o: "" $ phil/sw/src/gcc-4.0.0/configure \ --prefix=/phil/sw/sunos/i386/pkg/gcc-4.0.0 \ --disable-libgcj \ --enable-languages=c,c++,objc \ --with-gnu-as \ --with-as=/phil/sw/sunos/i386/bin/as \ --with-gnu-ld \ --with-ld=/phil/sw/sunos/i386/bin/ld \ --enable-shared $ make -s [..] bootstrap [...] /usr/lib/amd64/crti.o: file not recognized: File format not recognized collect2: ld returned 1 exit status make[3]: *** [amd64/libgcc_s.so] Error 1 "" Regards, Jeroen.
about how to write makefile.in config-lang.in for a frontend
i am now writing a frontend in gcc, but i don`t understand the rule to write the makefile.in, config-lang.in
