Re: building gcc
On Thu, Oct 12, 2006 at 12:22:57PM -0400, Bob Rossi wrote: > and the gcc that is put into prefixdir is compiled with -O2 and -g, > which makes it hard to follow in the debugger. Anyone have a clue on how > to compile gcc so only -g is used, and not -O2? Typically, I use the > CFLAGS trick, but it doesn't seem to work for gcc. Use CFLAGS="-g" ../gcc-src/configure. The top level file is still autoconf 2.13. -- Daniel Jacobowitz CodeSourcery
Re: Question about LTO dwarf reader vs. artificial variables and formal arguments
On Sat, Oct 21, 2006 at 06:35:40PM +0200, Steven Bosscher wrote:
> where _c is strlen("Hi World!"). From a user perspective, it would be better
> to hide _c for the debugger because it is not something that the user had in
> the original program. I have a patch to hide that parameter, that is, it
> stops GCC from writing out DW_TAG_formal_parameter for _c. But I am worried
> about how this will work out later if/when someone tries to make LTO work for
> gfortran too.
> Can you still reconstruct the correct function prototype for LTO from the
> debug info if you don't write debug info for _c?
Wouldn't this be upsetting to debuggers, too - for instance, if they
wanted to call the function? It might be wiser to tag it
DW_AT_artificial, and let the debugger sort out what to do with it.
> Similarly, LTO has to somehow deal with DECL_VALUE_EXPR and the debug
> information that is produced from it. Gfortran (and iiuc other front ends
> and SRA) use this DECL_VALUE_EXPR to produce fake variables that point to
> some location to improve the debug experience of the user. For Fortran we
> use it to create fake variables to point at members of a COMMON block, for
> example, so that the user can do "p A" for a variable A in a common block,
> instead of "p name_of_the_common_block.A". Is there already some provision
> to handle this kind of trickery in LTO?
I don't think we're far enough on yet to know the answer to this or
your other question, but I may be wrong. There's a reason we're
focusing on C right now :-) I don't think the design precludes this
sort of thing, but we won't know how it all fits together until more's
been done.
--
Daniel Jacobowitz
CodeSourcery
Re: Handling of extern inline in c99 mode
On Wed, Nov 01, 2006 at 06:59:42PM +, Joseph S. Myers wrote: > I'd rather simply fix glibc to work with C99 inline semantics. For the > above you might use > > #define tolower(c) __tolower_inline(c) > static __inline __attribute__((__always_inline__)) int tolower_inline ... > > and #undef tolower when defining the out of line function. That would > apply to all cases where a user-visible function in a header is currently > inlined directly; for a purely internal function in the header, we can > arrange for all declarations to use "inline" without "extern" when in C99 > mode. Isn't the whole point that the current extern inline isn't __always_inline__, but leaves it to the compiler's judgement? -- Daniel Jacobowitz CodeSourcery
Re: Bootstrap failure on trunk on linux? (libgmp.so.3 exists, but not found)
On Sat, Nov 04, 2006 at 10:57:14AM -0800, Brooks Moses wrote: > I've been setting up a Debian box to do builds on, and make bootstrap on > mainline is failing somewhere in the middle of Stage 1. The problem > appears to be that it's not looking in the right places for libgmp.so.3 > when it calls ./gcc/xgcc at the end of the stage. It's doing exactly what it ought to, though unintuitive. If you tell a -compiler to use L/usr/local/lib, you're responsible for also setting up either an rpath or LD_LIBRARY_PATH to point at /usr/local/lib; doing it by default causes all kinds of problems. -- Daniel Jacobowitz CodeSourcery
Re: Bootstrap failure on trunk on linux? (libgmp.so.3 exists, but not found)
On Sat, Nov 04, 2006 at 04:58:42PM -0800, Brooks Moses wrote: > I guess I was assuming that since GMP is supposedly only a prerequisite > for building the compiler and not for using it, that it was being linked > in statically rather than dynamically. But I guess that wouldn't apply > to xgcc, since it's only used in the build (right?). No, xgcc is installed as gcc. If you have a dynamic libgmp, it will be used. -- Daniel Jacobowitz CodeSourcery
Re: Threading the compiler
On Sat, Nov 11, 2006 at 04:16:19PM +, Paul Brook wrote: > I don't know how much of the memory allocated is global readonly data (ie. > suitable for sharing between threads). I wouldn't be surprised if it's a > relatively small fraction. I don't have numbers on global readonly, but in typical compilation most of the memory allocated is definitely global. Past a certain point much of that is probably readonly. However, it would take some clever interfaces and discipline to _guarantee_ that any particular global bit was shareable. -- Daniel Jacobowitz CodeSourcery
Re: Reducing the size of C++ executables - eliminating malloc
On Sun, Nov 12, 2006 at 11:17:14PM +, Paul Brook wrote: > The code being unwound through (ie. with frame data) needs to be able to > say "I need routine X if __Unwind_Raise is used anywhere in this program". > I'm not aware of any way of doing this, other than trying it and starting > again if you guessed wrong. Again, IIRC ARM's linker does something clever here. Of course the ABI in use there is somewhat different, but I suspect it could be adapted. On Sun, Nov 12, 2006 at 03:20:48PM -0800, Mark Mitchell wrote: > But, the way the ABI works requires a reference from each unit which may > cause unwinding. Even if you lose the personality routine, you will > still have the exception tables, which themselves are a significant > cost. If you don't want to pay for exceptions, you really have to > compile with -fno-exceptions. In that case, certainly, we should be > able to avoid pulling in the personality routine. If you try what Michael's been saying, you'll notice that trivial C++ files get the personality routine reference even if they don't have anything with a destructor which would need cleaning up. We ought to be able to emit (somewhat smaller) unwind information which doesn't reference the personality routine if it's going to have nothing to do, shouldn't we? -- Daniel Jacobowitz CodeSourcery
Re: Reducing the size of C++ executables - eliminating malloc
On Mon, Nov 13, 2006 at 01:03:10AM +, Paul Brook wrote: > > C++ files get the personality routine reference even if they don't > > have anything with a destructor which would need cleaning up. We ought > > to be able to emit (somewhat smaller) unwind information which doesn't > > reference the personality routine if it's going to have nothing to do, > > shouldn't we? > > Ah, ok, sorry. ARM unwinding works a bit differently, and you always need a > personality routine. Right - which is why it was such a headache for us, isn't amenable to _Unwind_Backtrace / _Unwind_ForcedUnwind, et cetera. For .eh_frame, though, the personality routine is only necessary to run cleanups and check exception specs. -- Daniel Jacobowitz CodeSourcery
Re: Reducing the size of C++ executables - eliminating malloc
On Sun, Nov 12, 2006 at 05:11:39PM -0800, Mark Mitchell wrote: > Daniel Jacobowitz wrote: > > > If you try what Michael's been saying, you'll notice that trivial > > C++ files get the personality routine reference even if they don't > > have anything with a destructor which would need cleaning up. We ought > > to be able to emit (somewhat smaller) unwind information which doesn't > > reference the personality routine if it's going to have nothing to do, > > shouldn't we? > > Certainly, there are at least some such cases. I guess a function whose > only callees (if any) are no-throw functions, and which itself does not > use "throw", does not need frame information. You've talked right past me, since I wasn't saying that... > However, I think you and Michael are right: we don't need to reference > the personality routine here. ... but this. > Unless the entire program doesn't > contain anything that needs cleaning up, we'll still need it in the > final executable, Right. So if you use local variables with destructors, even though you don't use exceptions, you'll get the personality routine. The linker could straighten that out if we taught it to, though. -- Daniel Jacobowitz CodeSourcery
Re: Do not use autoconf 2.60 yet
On Tue, Nov 14, 2006 at 08:05:59PM +, Joseph S. Myers wrote: > On Tue, 14 Nov 2006, Eric Christopher wrote: > > > Done, sorry about that. > > Thanks. Hopefully we can get a planned transition done (for gcc and src) > before 4.3. (I suspect the first step will be the move of toplevel to > 2.59; I'm not sure what's holding that up now all subdirectories of gcc > and src have been moved.) At this point I believe there are no more blockers. Steve Ellcey would be the person to ask. -- Daniel Jacobowitz CodeSourcery
powerpc64-gnu libgcc?
In updating toplevel libgcc, I noticed this in t-ppccomm: ifneq (,$findstring gnu,$(target)) ... -mlong-double-128 ... This suggests it was supposed to apply to both GNU/Linux and GNU/Hurd, but no other PowerPC targets. Is that right? If so, I assume it's safe to fix it to do so. It doesn't quite at present; powerpc64-gnu does not include t-ppccomm. powerpc-gnu does. -- Daniel Jacobowitz CodeSourcery
Configure test hangs on powerpc64-linux
I tried to build GCC HEAD today, using binutils 2.16. It gets stuck during configure, here: checking linker EH-compatible garbage collection of sections... The backtrace looks like: #0 0x10048e60 in ppc64_elf_gc_mark_hook (sec=0x10183078, info=0x1014e278, rel=0x1018c228, h=0x0, sym=0x1017fc30) at /scratch/joseph/3.4.0/linux/binutils-2.16/bfd/elf64-ppc.c:4892 #1 0x100704fc in _bfd_elf_gc_mark (info=0x1014e278, sec=0x10183078, [EMAIL PROTECTED]: 0x10048ddc ) at /scratch/joseph/3.4.0/linux/binutils-2.16/bfd/elflink.c:8771 #2 0x10070b10 in bfd_elf_gc_sections (abfd=0x10160570, info=0x1014e278) at /scratch/joseph/3.4.0/linux/binutils-2.16/bfd/elflink.c:9085 #3 0x1001343c in lang_process () at /scratch/joseph/3.4.0/linux/binutils-2.16/ld/ldlang.c:4721 #4 0x10014e7c in main (argc=269804016, argv=0x1fff558) at /scratch/joseph/3.4.0/linux/binutils-2.16/ld/ldmain.c:458 It never returns from ppc64_elf_gc_mark_hook (spins looking things up in a hash table, I don't have the matching source handy). I expect this is fixed in later binutils, but has anyone else seen this happen? Is there some way we can avoid an infinite loop in configure for this case? -- Daniel Jacobowitz CodeSourcery
Reviewer for top level libgcc
The top level libgcc patches are almost ready to submit; I need to go over them one last time, but that's it. Mark has suggested that any large projects find a reviewer in advance; is there anyone out there who feels qualified and available to review this? (I tried the build system maintainers first, but haven't heard back from any of them...) -- Daniel Jacobowitz CodeSourcery
Re: configuration options policy (at toplevel or only inside gcc/)?
On Thu, Dec 14, 2006 at 10:19:12AM +0100, Basile STARYNKEVITCH wrote: > In other words, should I make all my configurable flag visible by the > toplevel configure and propagated (thru Makefile.tpl) to gcc/ or not? No, you shouldn't. Only add them to subdirs that need them. -- Daniel Jacobowitz CodeSourcery
Re: Gprof and shared libraries
On Thu, Dec 28, 2006 at 09:28:30AM -0800, Ian Lance Taylor wrote: > I don't know the answer to your question. It may be that you need to > run "gprof /path/to/lirary.so gmon.out". I'm not sure. Gprof has roughly no support for shared libraries. Only addresses between _stext and _etext are recorded. -- Daniel Jacobowitz CodeSourcery
Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."
On Fri, Dec 29, 2006 at 10:44:02PM +0100, Florian Weimer wrote: > (BTW, I would be somewhat disappointed if this had to be pampered over > on the autoconf side. If the GNU project needs -fwrapv for its own > software by default, this should be reflected in the compiler's > defaults. I absolutely agree. My impression is that the current situation is a disagreement between (some of, at least) the GCC developers, and someone who can commit to autoconf; but I think it would be a very bad choice for the GNU project to work around itself. If we can't come to an agreement on the list, please ask the Steering Committee. This is a textbook example of what they're for. -- Daniel Jacobowitz CodeSourcery
Re: [heads-up] disabling "../configure --disable-bootstrap && make bootstrap"
On Fri, Dec 29, 2006 at 05:53:43PM -0500, Richard Kenner wrote: > > Next week, after the merge, the bootstrap rules in the gcc directory > > will go away. > > So what will be the way at that point to bootstrap JUST gcc? You won't be able to do that any more. We've been saying that since the first top level bootstrap rules went in, every time the subject came up - this really shouldn't be a surprise. Libgcc will no longer be configured by the gcc subdirectory's makefile. Therefore there will be no startfiles or libgcc for the new compiler to use. -- Daniel Jacobowitz CodeSourcery
Re: [heads-up] disabling "../configure --disable-bootstrap && make bootstrap"
On Fri, Dec 29, 2006 at 06:38:27PM -0500, Richard Kenner wrote: > > You won't be able to do that any more. We've been saying that since > > the first top level bootstrap rules went in, every time the subject > > came up - this really shouldn't be a surprise. > > No, what's been said is that there will be a MODE in which that can't > be done, but it was always claimed that no capability would be lost with > these changes. Now we're seeing a loss, and it's a very significant one. I'm sorry, but I decline to argue with you about this. I've done it several times already. I apologize that the entire process has drawn out over such a long period that we've had to rehash this argument again. I don't believe anyone else considers this important. The last decision I see in my archives on this subject was in February 2006. > > Libgcc will no longer be configured by the gcc subdirectory's makefile. > > Therefore there will be no startfiles or libgcc for the new compiler to > > use. > > Sure there is: the one the last iteration used! Obviously, if you're only > bootstrapping the compiler, you're going to leave everything else unchanged. Maybe I don't understand what you're asking. The process is: - Build supporting libraries for the build system tools - Build supporting libraries for the host system tools - Build gcc - [NEW] Build libgcc - If stage < final stage, go back to building some of the host libraries - Build other target libraries Note that when we get into and then out of the gcc subdirectory, the startfiles and libgcc haven't been built. If we don't go on to build libgcc, the just-built compiler is not functional. It can't use libgcc or crtbegin from the system; they might not even exist, depending on your bootstrap compiler. Do you mean something different by "bootstrapping just the compiler"? -- Daniel Jacobowitz CodeSourcery
Re: [heads-up] disabling "../configure --disable-bootstrap && make bootstrap"
On Sat, Dec 30, 2006 at 12:30:06AM -0500, Richard Kenner wrote: > > - Build supporting libraries for the build system tools > > - Build supporting libraries for the host system tools > > - Build gcc > > - [NEW] Build libgcc > > - If stage < final stage, go back to building some of the host > > libraries > > - Build other target libraries > > > > Do you mean something different by "bootstrapping just the compiler"? > > The problem is that last step: it takes a LONG time to build libjava, > for example. If I make a change that I need to give a sanity check to, > I want to compile GCC with it, but not all the other additional code: that's > for a later state in the development/testing cycle. Since building a stage > of GCC is about three times faster than "other target libraries", if there's > no way to suppress that, the time to do this test goes up by a factor of four. Oh! If that's all you mean, I misunderstood; it would not be at all difficult to add this. It would probably be just a matter of documentation; I think there's already an appropriate target. And if I'm reading correctly, it's spelled "stage3-bubble". That will build build libraries, host libraries, gcc, and libgcc. No other target libraries are bootstrapped. Does that help? On Fri, Dec 29, 2006 at 09:35:38PM -0800, Ian Lance Taylor wrote: > Would you feel OK if there were a make target to do a bootstrap > without building the other target libraries? The change from today's > bootstrap with --disable-bootstrap would be that it would build > libiberty, libcpp, and friends at each stage, rather than only once. I think it would even be possible to not bootstrap those host libraries - but unwise for the reasons we wanted them bootstrapped originally, and they're very quick to build. In a combined tree we bootstrap binutils too. That's less obviously useful. But in a GCC-only tree we bootstrap intl, gcc, libcpp, libdecnumber, libiberty, and zlib: all things linked directly into the compiler. -- Daniel Jacobowitz CodeSourcery
Do we want non-bootstrapping "make" back?
Once upon a time, the --disable-bootstrap configure option wasn't necessary. "make" built gcc, and "make bootstrap" bootstrapped it. Is this behavior useful? Should we have it back again? The trivial implementation is to build separate makefiles using the existing sed magic and have the non-bootstrap one as default, with a bootstrap: target that forwards to make -f Makefile.boot. Obviously better implementations are possible, and if you mix and match targets then strange things may happen, but that was true beforehand. Anyway, that would let us eliminate the configure-time decision - if there's a convincing reason to do so. -- Daniel Jacobowitz CodeSourcery
Re: Link tests not allowed
On Sun, Dec 31, 2006 at 06:12:23PM -0800, Jim Wilson wrote: > Admittedly, the configure error printed is a bit misleading. It used to > make sense when it was first written, but a lot of stuff has changed > since then, and the error message never got updated. The GCC_NO_EXECUTABLES error message really ought to (A) get logged in config.log, and (B) tell you why it decided link tests were forbidden. (And it's my fault originally IIRC.) I'm not at all sure how the nm failure ends up leading to this problem, but I'll take your word for that part. -- Daniel Jacobowitz CodeSourcery
Re: Link tests not allowed
On Mon, Jan 01, 2007 at 06:19:08PM -0800, Douglas B Rupp wrote: > configure:4811: /home/rupp/ngnat/buildxppcaix/./gcc/xgcc > -B/home/rupp/ngnat/buildxppcaix/./gcc/ > -B/home/rupp/gnat/powerpc-ibm-aix5.2.0.0/bin/ > -B/home/rupp/gnat/powerpc-ibm-aix5.2.0.0/lib/ -isystem > /home/rupp/gnat/powerpc-ibm-aix5.2.0.0/include -isystem > /home/rupp/gnat/powerpc-ibm-aix5.2.0.0/sys-include -c -O2 -g > conftest.c >&5 I would recommend trying to link a program using exactly that command line (without the -c conftest.c of course) and seeing what it tells you. The problem is usually obvious. -- Daniel Jacobowitz CodeSourcery
Re: Link tests not allowed
On Mon, Jan 01, 2007 at 07:32:51PM -0800, Jim Wilson wrote: > This is the wrong part of the config.log fragment. The interesting part > is nearer the top, immediately after the command using the -V option. > The use of -V probably fails which is OK as this is only for information > purposes, but the next one is the GCC_NO_EXECUTABLES test, and that one > should have worked. Unfortunately, when it fails, the error does not get logged properly. -- Daniel Jacobowitz CodeSourcery
Top level libgcc checked in
I've just committed the approved top level libgcc patches, which create a top level "libgcc" directory. Hopefully, this will not have any great impact on much of anyone. The only change I know of is that if you run "make all-gcc", you will no longer have enough to test C. You need at least "make all-target-libgcc". If you're bootstrapping, libgcc will be built in each stage. If the changes cause you any problems please let me know and I'll try to clean up after myself. Meanwhile, it is now very simple to move target-specific pieces of "libgcc" (including startfiles) from the gcc subdirectory to the libgcc subdirectory. Config fragments are simplest; and once every reference to a source file has moved to the new directory, the source file itself can be moved also. I invite target maintainers to migrate their configurations. I'll be doing some as I have time, but it's tricky to do blind and easier if you have a target to test on. Right now the libgcc configuration is completely tied up with gcc/Makefile. As parts of the configuration process move from gcc/config/ to libgcc/config/ (or libgcc's configure.ac), we'll be untangling them. Eventually, it should be possible to build gcc and the target libraries separately. -- Daniel Jacobowitz CodeSourcery
Re: Top level libgcc checked in
On Thu, Jan 04, 2007 at 04:19:17PM +1100, Ben Elliston wrote: > On Wed, 2007-01-03 at 23:28 -0500, Daniel Jacobowitz wrote: > > > Right now the libgcc configuration is completely tied up with > > gcc/Makefile. As parts of the configuration process move from > > gcc/config/ to libgcc/config/ (or libgcc's configure.ac), we'll > > be untangling them. Eventually, it should be possible to build > > gcc and the target libraries separately. > > So I take it that at this stage we've not commenced the process of > having libgcc's configury run autoconf tests on the target compiler? > (Rather than having to hardwire most target details into the t-* files?) > Any objections to starting down this path? As Paolo responded, we have already begun - I use autoconf to detect both visibility support and decimal float support. I'm not sure how much else remains to be done, but I'm open to suggestions :-) I wonder if it's possible to work out some of the difuncs/tifuncs stuff based on the size of target types. -- Daniel Jacobowitz CodeSourcery
Re: trunk gcc has problems finding crtbegin.o
On Thu, Jan 04, 2007 at 02:32:19PM +0100, Martin Reinecke wrote: > /usr/bin/ld: crtbegin.o: No such file: No such file or directory > collect2: ld returned 1 exit status > > This probably happens because the crt*.o files are no longer placed into > /lib/gcc/i686-pc-linux-gnu/4.3.0/ > but rather into /lib/gcc/i686-pc-linux-gnu/. > Is this related to the recent libgcc changes? Yes, it's my fault. The last time I tested make install, they went to the right place. I'm building right now to find out what's gone wrong. -- Daniel Jacobowitz CodeSourcery
Re: trunk gcc has problems finding crtbegin.o
On Thu, Jan 04, 2007 at 08:59:51AM -0500, Daniel Jacobowitz wrote: > On Thu, Jan 04, 2007 at 02:32:19PM +0100, Martin Reinecke wrote: > > /usr/bin/ld: crtbegin.o: No such file: No such file or directory > > collect2: ld returned 1 exit status > > > > This probably happens because the crt*.o files are no longer placed into > > /lib/gcc/i686-pc-linux-gnu/4.3.0/ > > but rather into /lib/gcc/i686-pc-linux-gnu/. > > Is this related to the recent libgcc changes? > > Yes, it's my fault. The last time I tested make install, they went to > the right place. I'm building right now to find out what's gone wrong. I'm not sure how I missed this before; apologies. I've checked in this obvious fix. Relating to what Mark was saying earlier: you can see that this assumes $(CC) (in the target directory) has the same version as ../gcc/xgcc. This is not the first place with that sort of assumption. If you're building Canadian crosses, remember to use the same source tree to build the cross compiler and the cross-hosted compiler. Anything else is just impossible to support. -- Daniel Jacobowitz CodeSourcery 2007-01-04 Daniel Jacobowitz <[EMAIL PROTECTED]> * Makefile.in (version): Define. Index: Makefile.in === --- Makefile.in (revision 120429) +++ Makefile.in (working copy) @@ -181,6 +181,8 @@ export RANLIB_FOR_TARGET export libsubdir export slibdir +version := $(shell $(CC) -dumpversion) + DECNUMINC = -I$(srcdir)/../libdecnumber -I$(MULTIBUILDTOP)../../libdecnumber # Specify the directories to be searched for header files.
Re: libgcc
On Thu, Jan 04, 2007 at 12:17:49PM -0800, Mike Stump wrote: > In libgcc/Makefile I find: > > MAKEINFO = @MAKEINFO@ > > and > > PERL = @PERL@ > > Seems like they should be always substituted, if they are going to > always be in there, or, if they are never used, removed. The latter; feel free to remove them :-) -- Daniel Jacobowitz CodeSourcery
Re: Do we want non-bootstrapping "make" back?
On Fri, Jan 05, 2007 at 12:18:53AM +0100, Eric Botcazou wrote: > > Once upon a time, the --disable-bootstrap configure option wasn't > > necessary. "make" built gcc, and "make bootstrap" bootstrapped it. > > > > Is this behavior useful? Should we have it back again? > > Is this a genuine question or some subtle attempt at mimicing Paul Eggert's > cleverness to spark your own gigantic thread? :-) Ahem. > Certainly, doing a mere > build with "make" and a complete bootstrap with "make bootstrap" was rather > reasonable, but you and other build machinery wizards convinced us that this > would be a pain to support with toplevel bootstrap. So what has changed? Not much. I'm convinced it would be feasible, but definitely not easy, so I wanted to see how much interest there was - seems like some, but not a lot. -- Daniel Jacobowitz CodeSourcery
Re: How to dedicate a register for special purpose in gcc?
On Fri, Jan 05, 2007 at 12:53:16PM +0800, wrote: > Hi, > How can I dedicate a register for special purpose, that means, > the dedicated register only appears in the inserted code of my own, > but never allocated in the rest of code. I have read some doc(gcc int) > about the register usage but still have no idea. > > I would *really* appreciate any help I can get on this issue! Take a look at -ffixed-REG. -- Daniel Jacobowitz CodeSourcery
Re: Do we want non-bootstrapping "make" back?
On Fri, Jan 05, 2007 at 08:19:39AM +0100, Eric Botcazou wrote: > > Not much. I'm convinced it would be feasible, but definitely not easy, > > so I wanted to see how much interest there was - seems like some, but > > not a lot. > > Would this comprise retrofitting the support into the 4.2 branch? I have no intention of touching the build system for the release branch, in any case. -- Daniel Jacobowitz CodeSourcery
Re: Do we want non-bootstrapping "make" back?
On Fri, Jan 05, 2007 at 09:23:56AM -0500, Richard Kenner wrote: > > > Not much. I'm convinced it would be feasible, but definitely not easy, > > > so I wanted to see how much interest there was - seems like some, but > > > not a lot. > > > > Would this comprise retrofitting the support into the 4.2 branch? > > I don't think it's needed in the 4.2 branch since you can get the > functionality > with --disable-bootstrap (or whatever it's called). It's only in 4.3 that > that option will be removed and hence the functionality otherwise lost. > > Or do I misunderstand? We're not talking about that at all. I was only talking about whether the decision was made at configure or make time. -- Daniel Jacobowitz CodeSourcery
Re: Do we want non-bootstrapping "make" back?
On Fri, Jan 05, 2007 at 06:00:53PM +0100, Eric Botcazou wrote: > So, assuming we go back to the old behaviour, 4.2.x would be the only series > for which 'make' performs a complete bootstrap? Seems a little odd. I think > we need a clear cut here: either automatic bootstrap is a good feature and > we're done, or it (after all) isn't and no series of compilers should be > released with it. Someone else gets to make that decision then. I'm somewhat sorry for raising the issue; I took another look at it last night, and it would be harder than I thought to get it working. And I certainly don't have time to do it before 4.2.0. -- Daniel Jacobowitz CodeSourcery
Re: __sync_bool_compare_and_swap
On Fri, Jan 05, 2007 at 05:05:41PM +, Andrew Haley wrote: > But it can't unless you use an architecture that has cmpxchgl. > cmpxchgl is a 486 instruction; if you compile for 386, we have to > generate the call because there is no such instruction. And the older compiler was a Debian packaged one; Debian's compilers default to generating code for a 486 or later. -- Daniel Jacobowitz CodeSourcery
Re: gcc trunk 20070110 build failure (--enable-targets=all i486-linux-gnu)
On Wed, Jan 10, 2007 at 12:07:28PM +0100, Matthias Klose wrote: > trunk configured on i486 (on x86_64 hardware) with > > --enable-targets=all i486-linux-gnu > > fails to configure the first 64bit library (libiberty), not finding > the correct libgcc. libgcc uses the same config-ml.in to enable multilibs that libiberty does. You're going to have to figure out why that's decided that we shouldn't build multilibs. It starts by checking xgcc -print-multi-lib; that works, right? Could it have picked up a bad setting for $CC? -- Daniel Jacobowitz CodeSourcery
Re: main(), registers and gdb
On Wed, Jan 10, 2007 at 04:32:48PM -0700, Greg Watson wrote:
> If the following code is compiled with 'gcc -g -O0 -o test test.c',
> the address of argc is passed into func() in the ecx register. Since
> ecx is not preserved after the call to printf(), the address of argc
> is corrupted on return from func(). Normally this would not be a
> problem, since argc is never used in the code.
This is a typical problem. There is not much that can be done about
it, although I remember once hearing a proposal that GCC should
forcibly extend the live ranges of local variables (or at least
arguments) at -O0 to improve debugging. That seems sensible to me.
> However, when run under gdb, commands that view the stack frame
> produce strange results, and some commands (e.g. -var-update)
> actually crash the debugger.
A crash is always a bug.
> Breakpoint 1, main (argc=1, argv=0xbffcef14) at test.c:14
> 12 func(&argc);
> (gdb) n
> in func
> 14 printf("hello\n");
> (gdb) where
> #0 main (argc=Cannot access memory at address 0x4
> ) at test.c:16
And honestly, I have no idea how that happened. Does it happen
with a current GDB? I suspect from the error message that this
one is not too recent.
--
Daniel Jacobowitz
CodeSourcery
Re: main(), registers and gdb
On Wed, Jan 10, 2007 at 04:50:59PM -0700, Greg Watson wrote: > That would be nice. Although this seems like a trivial issue, it can > potentially effect debugging all MPI programs since they always start > with 'MPI_Init(&argc, &argv)'. See my reply to the bug. This is specific to i686 32-bit compilers, arguments, and functions named "main". > >And honestly, I have no idea how that happened. Does it happen > >with a current GDB? I suspect from the error message that this > >one is not too recent. > > It's gdb 6.5, so reasonably recent. Please try a current snapshot. Thanks. -- Daniel Jacobowitz CodeSourcery
Re: Running GCC tests on installed compiler
On Fri, Jan 12, 2007 at 06:05:49PM -0800, Mike Stump wrote:
> On Jan 12, 2007, at 3:55 PM, Steve Ellcey wrote:
> >Can someone one with some deja-knowledge help me figure out how to run
> >the GCC tests on an installed compiler and without having to do a GCC
> >build?
>
> You must be new around here:
>
> http://gcc.gnu.org/ml/gcc-announce/1997-1998/msg0.html
>
> :-) Which is the I feel lucky google("site:gcc.gnu.org how to run
> installed GCC_UNDER_TEST") result.
For the less old-school inclined, try contrib/test_installed.
--
Daniel Jacobowitz
CodeSourcery
Re: Compiling libgcc functions with non-default LIBGCC2_UNITS_PER_WORD
On Sat, Jan 20, 2007 at 01:15:19PM +0100, Rask Ingemann Lambertsen wrote: >Somewhere in the libgcc build machinery, there is mechanism to override > the default LIBGCC2_UNITS_PER_WORD setting when compilng a function, so you > could in principle provide e.g. _divsi3 as well as _divdi3. It there a way > of making use of this facility in a more elegant way than putting the whole > gcc command line in a target makefile fragment? I'm not sure I understand what you want to do. Could you give me a bigger example? Those bits are only used for fix/float conversions. -- Daniel Jacobowitz CodeSourcery
Re: Compiling libgcc functions with non-default LIBGCC2_UNITS_PER_WORD
On Sun, Jan 21, 2007 at 11:09:56PM +0100, Rask Ingemann Lambertsen wrote: >I would like to be able to add something like > > LIBGCC2_EXTRA_FUNCS = _ashldi3:2 _ashrdi3:2 _lshrdi3:2 _divdi3:2 _moddi3:2 > > to t-machine instead of > > LIB2FUNCS_EXTRA = ashlsi3.c ashrsi3.c lshrsi3.c ... > > ashlsi3.c: $(srcdir)/libgcc2.c $(srcdir)/libgcc2.h >./xgcc -B./ -E -Dinhibit_libc -DLIBGCC2_UNITS_PER_WORD=2 -DL_ashldi3 \ > -DIN_GCC -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I . -I $(srcdir) \ > -I $(srcdir)/../include $(srcdir)/libgcc2.c -o ashlsi3.c > > and so on, to provide the functions _ashlsi3, _ashrsi3, _lshrsi3, _divsi3 > and _modsi3 in addition to the default DImode ones. Well, it would be much simpler than that. You could reuse the existing code. intfuncs = _ashlXX3 _ashrXX3 _lshrXX3 _divXX3 _modXX3 siintfuncs = $(subst XX,si,$(intfuncs)) diintfuncs = $(subst XX,d i,$(intfuncs)) iter-items := $(siintfuncs) iter-labels := $(diintfuncs) iter-sizes := $(patsubst %,2,$(siintfuncs)) include $(srcdir)/empty.mk $(patsubst %,$(srcdir)/siditi-object.mk,$(iter-items)) libgcc-objects += $(patsubst %,%$(objext),$(siintfuncs)) ifeq ($(enable_shared),yes) libgcc-s-objects += $(patsubst %,%_s$(objext),$(siintfuncs)) endif If you think it would be useful for enough targets, you could add some code to automatically extract the bits before and after the colon and give this a standard name that tdep files could set. That should get you started. -- Daniel Jacobowitz CodeSourcery
Top level libgcc migration tips
I've put up some information on the wiki about moving configuration information from gcc to libgcc. Please, feel free to add to it! http://gcc.gnu.org/wiki/Top-Level_Libgcc_Migration -- Daniel Jacobowitz CodeSourcery
Re: problem building gcc4-4.3.0-20070209
On Sat, Feb 10, 2007 at 12:56:13AM +0100, Dominique Dhumieres wrote:
> While building the gcc4-4.3.0-20070209 snapshot, I got the error
>
> ...
> checking for correct version of gmp.h... no
> configure: error: Building GCC requires GMP 4.1+ and MPFR 2.2.1+.
> ...
>
> I am using the same script that worked last week and I have
> gmp 4.2.1 and mpfr 2.2.1 since several builds. I am using
> a Mac OSX 10.3.9. Can someone give me a pointer the change(s)
> that might explain the breakage.
You need to show us your configure arguments to be sure. I bet
you're specifying just --host.
I don't know exactly what to do about this. It's caused by:
if test ${build} != ${host}; then
some defaults
else
AC_PROG_CC
fi
AC_TRY_COMPILE
ac_objext is set at the expansion of AC_PROG_CC and if you take the if
branch, it never gets set.
Does anyone reading this know what the right thing to do is? Is there
anything in the autoconf documentation about not using some macros
inside conditional statements?
--
Daniel Jacobowitz
CodeSourcery
Re: problem building gcc4-4.3.0-20070209
On Sat, Feb 10, 2007 at 05:08:10PM +0100, Paolo Bonzini wrote:
>
> >if test ${build} != ${host}; then
> > some defaults
> >else
> > AC_PROG_CC
> >fi
> >
> >AC_TRY_COMPILE
> >
> >ac_objext is set at the expansion of AC_PROG_CC and if you take the if
> >branch, it never gets set.
> >
> >Does anyone reading this know what the right thing to do is? Is there
> >anything in the autoconf documentation about not using some macros
> >inside conditional statements?
>
> Yes, but the idea is that, if we are in a Canadian setting, we can set
> all the variables that Autoconf sets, in the `then' branch. So we'd set
> ac_objext=.o in the `then' branch.
This seems horribly wrong somehow. Aren't we intested in the ${build}
-> ${host} compiler at this point anyway? So shouldn't we be testing
it? I think the whole block can go.
--
Daniel Jacobowitz
CodeSourcery
Re: problem building gcc4-4.3.0-20070209
On Sat, Feb 10, 2007 at 06:59:35PM +0100, Paolo Bonzini wrote:
>
> >This seems horribly wrong somehow. Aren't we intested in the ${build}
> >-> ${host} compiler at this point anyway? So shouldn't we be testing
> >it? I think the whole block can go.
>
> Hmm, it says indeed "this is going to change when we autoconfiscate".
> Something like this?
Yes, pretty much (though I don't see the point in the CFLAGS -g
assignment either).
--
Daniel Jacobowitz
CodeSourcery
Re: Fw: Strange paths for gcc for x86_64-pc-mingw32
On Mon, Feb 19, 2007 at 10:35:41AM +0100, Kai Tietz wrote: > Hi, > > No the point is that I am using the default settings of gcc (without any > "--prefix="). The compiler is built and installed at the expected place > (/usr/local/libexec/gcc/...), but the gcc,exe tool installed under > /usr/local/x86_64-pc-mingw32/bin does not have the proper path to its gcc > tools defined. Under previous versions it worked. By the way, to make the > cross-compiler known via PATH would break my complete system. That's not the one you want to run. You should have something in /usr/local/bin/x86_64-pc-mingw32-gcc.exe also; do you? The one in /usr/local/x86_64-pc-mingw32/bin is different, and may not work - I think the way that normally happens involves symbolic links, or something similar. Anyway, you don't need to use it. -- Daniel Jacobowitz CodeSourcery
Re: GCC 4.2.0 Status Report (2007-02-19)
On Tue, Feb 20, 2007 at 06:23:14PM -0500, Kaveh R. GHAZI wrote: > No it doesn't need stating, at least not for me. :-) Sure nobody likes > bugs/miscompilations, but all compilers have them. We evaluate how > serious they are and whether a performance hit from a bug fix is worth it. > My understanding is that 4.1 has this very same bug, and it hits about as > often as it does in 4.2. See the end of this message: > http://gcc.gnu.org/ml/gcc/2007-02/msg00432.html > > If so, then it can't be too bad IMHO. That was the context within which > I made my statement. And if that holds, I continue to stand by it. On the other hand, I consider this a fairly serious bug in 4.1 (and I've seen customers encounter it at least twice off the top of my head). It depends what your tolerance for wrong-code bugs is. -- Daniel Jacobowitz CodeSourcery
Re: GCC 4.2.0 Status Report (2007-02-19)
On Wed, Feb 21, 2007 at 11:33:39AM -0500, Kaveh R. GHAZI wrote: > My tolerance is pretty low. I'm relying on the fact that the bug occurs > rarely in real code. I'm trying to reconcile your statement about > customer feedback with Daniel B's claim here: > http://gcc.gnu.org/ml/gcc/2007-02/msg00476.html > > He said: > "I'm still of the opinion that even though you can write relatively simple > testcases for them, they are actually pretty rare. In most of the bugs, > it is in fact, the absence of any real code (or local variables in one > case) that triggers the bad result. Anything more complex and we get the > right answer." They're different sides of the same coin; they don't disagree, though a judgement is indeed required. In support of what Danny B. wrote, in at least one case we were unable to meaningfully reproduce the testcase. This stuff is not easy to trigger. But if you do, it's quite unpleasant - both for the user, and for the poor compiler developer who has to figure out what happened. -- Daniel Jacobowitz CodeSourcery
Re: GCC 4.2.0 Status Report (2007-02-19)
On Wed, Feb 21, 2007 at 11:00:00PM +0100, Richard Guenther wrote: > Of course the speed of a compiler is measured on testcases where > speed matters - and this is usually FP code. Now based on this reasoning > we could (as CodeSourcery probably did) enable -fno-strict-aliasing by > default, which fixes the class of 4.1.x bugs we are talking about. I think we did something in the middle - we made the aliasing much more conservative (maybe using one of your patches, even?) but without completely disabling it. But don't take my word too seriously here - I didn't do it, and I don't really remember what happened. I'm just making noise. > Now, the realistic choices for 4.2.0 as I see them are, in order of my > personal preference: > > 1) Ship 4.2.0 as is > 2) Ship 4.2.0 with the aliasing fixes reverted > 3) no more reasonable option. Maybe don't ship 4.2.0 at all. > > so, I don't see backporting more patches or even re-branching as > a real option. I've been convinced of the same. If we (GCC developers) shipped it with the aliasing fixes reverted, I'm not sure quite what we (CodeSourcery) would do with the result - but I bet we'd at least consider reapplying them. -- Daniel Jacobowitz CodeSourcery
Re: Re; Maintaining, was: Re: Reduce Dwarf Debug Size
On Thu, Mar 01, 2007 at 06:05:50PM -0800, Ian Lance Taylor wrote: > One answer to that is to have patch advocates to help push patches in. > They would need some experience with the community, but would not need > deep technical knowledge. This would be a volunteer position, along > the lines of the bugmasters. Good luck keeping people. It's a crappy job. -- Daniel Jacobowitz CodeSourcery
Re: [RFC]possible improvements to --with-sysroot
On Sat, Mar 03, 2007 at 09:47:41PM +0800, Zhang Le wrote: > Wouldn't it be great that we go one step further that we let ld look > for libraries in the dir listed in $SYSROOT/etc/ld.so.conf, if this > file ever exits? Of course for each entry in $SYSROOT/etc/ld.so.conf, > we prefix $SYSROOT to it. Did you try it? This should already happen if you configured binutils with a sysroot. -- Daniel Jacobowitz CodeSourcery
Re: [RFC]possible improvements to --with-sysroot
On Tue, Mar 06, 2007 at 02:05:06AM +0800, Zhang Le wrote: > I have used "strace -f" to check where linker looked for -lqt-mt. From > what I have observed, it seems that ld didn't use > $SYSROOT/etc/ld.so.conf. Well, it's supposed to, so I suggest you check what's happened in ld. -- Daniel Jacobowitz CodeSourcery
Re: Detemining the size of int_fast8_t etc. in the frontend
On Wed, Mar 07, 2007 at 12:05:32PM -0800, Mike Stump wrote: > On Mar 7, 2007, at 11:21 AM, Tobias Burnus wrote: > >Using "#include " with e.g. sizeof(int_fast8_t) does not > >work with cross compilations. > > Sounds like a bug? When I try it on my compiler, it works just fine > natively and with cross compilations. I'd file a bug report. If it > is an OS bug, it can be fixed by fixincludes. He's talking about finding the target's int_fast8_t in the frontend. That's another issue entirely. -- Daniel Jacobowitz CodeSourcery
Re: Question for removing trailing whitespaces (not vertical tab) from source
On Tue, Mar 13, 2007 at 03:02:44PM -, Dave Korn wrote: > Can you explain that value? It's just that 1) I see vast acres and acres of > code where the tabstop size is two spaces 2) the coding standard doesn't seem > to /demand/ a specific tab size and 3) if we use 8-space TABs with the kind of > depths of nesting the gcc code often contains we're going to exceed the > 80-column line length limit just on the leading indentation alone pretty > often GCC indents with tabs replacing eight leading spaces but an indentation depth of two spaces. I don't know where your acres and acres are, but they aren't in most GNU software. This is, unsurprisingly, how emacs behaves. Personally I think that regardless of your indentation preferences, using anything besides eight column tab stops for \t is silly; that's what "cat" is going to use. -- Daniel Jacobowitz CodeSourcery
Re: Updating libtool in GCC and srctree
On Mon, Mar 12, 2007 at 04:03:52PM -0700, Steve Ellcey wrote: > configure:15448: error: possibly undefined macro: AM_PROG_GCJdnl Where'd that come from? Wherever it is, it's a bug. Maybe someone checked in a typo to the configure file. "dnl" is a comment start token in autoconf (that's a very rough approximation of the situation). > I am not sure why I get this, nothing else seems to be requiring > m4_pattern_allow. If I don't use any -I options on aclocal it works and > then I get a different error from autoconf (about TL_AC_GXX_INCLUDE_DIR > being possibly undefined). I think I want the -I options though. Yes, you always want to match ACLOCAL_AMFLAGS from Makefile.am. -- Daniel Jacobowitz CodeSourcery
Re: PATCH: make_relative_prefix oddity
On Mon, Mar 12, 2007 at 10:47:28PM -0700, Mark Mitchell wrote:
> It treats only "/opt" as a common component of the two paths, rathe
> than "/opt/foo". If you use "/opt/foo/" (instead of "/opt/foo") for
> the last argument, the answer is as I expected. This seems odd to me;
> is it the intended behavior?
>
> The patch below (which is against an older version of libiberty, and
> might need updating) fixes it. Assuming you agree that this is a bug,
> would this patch (with updating and testing) be OK?
I believe that at the time your patch was first written, we decided to
fix this in the driver instead and leave make_relative_prefix
unchanged:
2006-04-28 Joseph S. Myers <[EMAIL PROTECTED]>
* gcc.c (process_command): Add program name to GCC_EXEC_PREFIX
value before passing to make_relative_prefix.
--
Daniel Jacobowitz
CodeSourcery
Re: Building without bootstrapping
On Mon, Mar 19, 2007 at 05:25:37AM -0700, Karthikeyan M wrote: > Thanks for the information. > So, if I want to debug a bug in the cc1 code that causes target > library build to fail - > should I just use the cc1 that is generated in /gcc/ ? Yes. -- Daniel Jacobowitz CodeSourcery
Re: Google SoC Project Proposal: Better Uninitialized Warnings
On Mon, Mar 19, 2007 at 01:49:55PM -0400, Andrew MacLeod wrote: > Perhaps this ought to be looked at again with some seriousness. I think this is an idea whose time has either come, or will shortly. GCC's -O0 is much more extreme than that of other compilers I've used. -- Daniel Jacobowitz CodeSourcery
Re: Building mainline and 4.2 on Debian/amd64
On Mon, Mar 19, 2007 at 06:05:05PM +, Andrew Haley wrote: > Will that work? Unless there's some more configury I don't > understand, they'll still end up with libraries in /lib64 rather than > /lib. It does work. You have to do a bit more fiddling if you want to use 'make install' into a system location, but that's about it. And usually one shouldn't do that anyway. There's /lib64 -> lib and /usr/lib64 -> lib symlinks, which help out. -- Daniel Jacobowitz CodeSourcery
Re: We're out of tree codes; now what?
On Wed, Mar 21, 2007 at 02:39:13PM -0400, Doug Gregor wrote: > I suspect we would see a small increase in memory usage, because > subcoded types would have to allocate some memory for > TYPE_LANG_SPECIFIC to point at (it'll be only 4 bytes in most cases). Well, that's not strictly necessary if you've got nothing but a type code in it. Have a couple of constant TYPE_LANG_SPECIFIC instances in rodata :-) Which is less useful if you want to move things out of the common tree, of course. -- Daniel Jacobowitz CodeSourcery
Re: --disable-multilib broken on x86_64
On Sat, Mar 24, 2007 at 11:04:12PM +, Martin Michlmayr wrote: > * Martin Michlmayr <[EMAIL PROTECTED]> [2007-03-24 22:25]: > > This can be fixed by making sure the canonical target is used in > > configure.ac so the check for the target will actually work, as below. > > OK to commit? > > Actually, I should mention that I haven't fully bootstrapped GCC with > this change (although it fixes the build failure I saw before). > libgcc/configure.ac also uses $target for something else so I'm not > sure it's okay to canonicalize it. But at least the patch shows the > problem and a possible solution, so maybe you (or someone who > understsands the build scripts) can fully test it. libgcc should not use AC_CANONICAL_TARGET; --target doesn't mean anything to a target library. I'm not sure about libdecnumber - it probably shouldn't be sensitive to $target either. -- Daniel Jacobowitz CodeSourcery
Re: Linking shared libs against shared libs
On Sun, Mar 25, 2007 at 07:18:16PM +0200, Oliver Lange wrote: > I'm trying to link a shared library against a shared library, > using gcc/ld on Linux and with code like this: This is really more of a linker question. Followups to [EMAIL PROTECTED], please. > Compiling the sourcecode above like this: > gcc test.c -o test.so -shared -fPIC [-s] > The problem is that i'd expect gcc/ld to abort with an error, > but it just 'successfully' links something. > Am i missing something? How can ld link against a > definitely unknown function? See the linker manual for "-z defs". -- Daniel Jacobowitz CodeSourcery
Re: nested backticks in Makefile
On Tue, Mar 27, 2007 at 03:01:04PM -0400, DJ Delorie wrote: > - CROSS_SYSTEM_HEADER_DIR='$(gcc_tooldir)/sys-include' > + CROSS_SYSTEM_HEADER_DIR='$(shell echo $(gcc_tooldir)/sys-include)' Don't you need more quotes than that? -- Daniel Jacobowitz CodeSourcery
Re: nested backticks in Makefile
On Tue, Mar 27, 2007 at 10:28:33PM -0400, DJ Delorie wrote: > > > On Tue, Mar 27, 2007 at 03:01:04PM -0400, DJ Delorie wrote: > > > - CROSS_SYSTEM_HEADER_DIR='$(gcc_tooldir)/sys-include' > > > + CROSS_SYSTEM_HEADER_DIR='$(shell echo $(gcc_tooldir)/sys-include)' > > > > Don't you need more quotes than that? > > I think if we quoted it more, we'd end up passing the backticks along > instead of processing them, and we'd end up right where we started. I only meant: CROSS_SYSTEM_HEADER_DIR='$(shell echo "$(gcc_tooldir)/sys-include")' -- Daniel Jacobowitz CodeSourcery
Re: nested backticks in Makefile
On Tue, Mar 27, 2007 at 10:40:10PM -0400, DJ Delorie wrote: > > > I only meant: > > > > CROSS_SYSTEM_HEADER_DIR='$(shell echo "$(gcc_tooldir)/sys-include")' > > I figured you meant that. Can you think of an example that would > benefit from this quoting? $(gcc_tooldir) starts with $(libsubdir) starts with $(libdir) which will come from $(prefix), so there's an unquoted $(prefix) there. ../gcc/configure --prefix=/usr/local/"where * am * i" will thus lead to $(shell echo /usr/local/where * am * i/sys-include), which will wildcard. -- Daniel Jacobowitz CodeSourcery
Re: tuples: data structure separation from trees
On Thu, Mar 29, 2007 at 06:40:30PM -0700, Andrew Pinski wrote: > On 29 Mar 2007 18:24:56 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: > >Why will expressions have location? It seems to me preferable to save > >the memory. After a few optimization passes many of the expressions > >have no location anyhow. > And I know from past experiences, that this is really a bug that they > don't produce expressions with locations. I remember Daniel Berlin > was talking about how SRA does the correct thing with respect of > locations and other passes should really follow that. We can see how > out of SSA can produce cases where PHIs would create expressions > without locations but that is a bug (I cannot find the PR right now > but Daniel J. filed it). http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26475 But I'm not convinced that adding locations on more things is a workable solution to the problem. I wish someone had sufficient incentive to sit down and design a proper solution to our degenerating debug info. -- Daniel Jacobowitz CodeSourcery
Re: tuples: data structure separation from trees
On Thu, Mar 29, 2007 at 09:38:02PM -0700, Ian Lance Taylor wrote: > Provided we keep locations on statements, specifically including > GIMPLE_MODIFY_EXPR, does it really help us to keep locations on > expressions within statements in optimized code? What could the > debugger do with that information, in principle, that would be > helpful? I would worry about any time that two statements are combined and then later separated, thus losing line information from one of them. At the gimple level, that's less likely - in GENERIC or higher, more likely. See the PR for a case where the current approach would even require locations on constants. And that's obviously infeasible, so... -- Daniel Jacobowitz CodeSourcery
Re: Variable scope debug info
On Thu, Apr 05, 2007 at 09:46:18AM -0700, Joe Buck wrote: > Now, it might turn out that adding additional dwarf records for > every single declaration won't significantly increase the size > of the debug information. But it is a consideration. FWIW, I would expect that it would not make a significant difference. -- Daniel Jacobowitz CodeSourcery
Re: Integer overflow in operator new
On Sat, Apr 07, 2007 at 12:15:10PM +0200, Florian Weimer wrote: > * Karl Chen: > > > "4 * n", unchecked, is vulnerable to integer overflow. On IA-32, > > "new int[0x4001]" becomes equivalent to "new int[1]". I've > > verified this on gcc-2.95 through 4.1. For larger objects the > > effects are exaggerated; smaller counts are needed to overflow. > > This PR19351, by the way. Also by the way, it's triggered in the libstdc++ testsuite in at least one place :-) I can't remember which test any more, but last month I discovered that there is a use of operator new[] with a subscript of INT_MAX - 1 (INT_MAX is handled specially). In general this still works out to be more memory than can be allocated and the test tests what it wanted to (bad_alloc). -- Daniel Jacobowitz CodeSourcery
Re: RFC: GIMPLE tuples. Design and implementation proposal
On Tue, Apr 10, 2007 at 05:23:55PM -0400, Andrew MacLeod wrote: > We'd also be able to "linearize" things when we write it out... ie, > flatten out the linked lists of instruction so they are all continguous > indexes, tables etc. this would make it compact and when its read in, we > might even see some cache friendly accesses for a change. FYI, I did this with PCH once... I never followed it through well enough to get consistent results from it, but I did get some remarkable jumps during testing. -- Daniel Jacobowitz CodeSourcery
Re: libstdc++.dylib linking problem on Darwin
On Thu, Apr 12, 2007 at 04:43:23PM -0700, Eric Christopher wrote: > The basic idea is that the darwin code uses slibdir to set the install name > of > the library - including full path. Yes, this is dumb, but it's the way that > darwin does things at the moment. :( That much is reasonable but... > $(MAKE) install DESTDIR=$(gcc_objdir) \ > - slibdir= libsubdir= MULTIOSDIR=$(MULTIDIR) > + slibdir=$(slibdir) libsubdir= MULTIOSDIR=$(MULTIDIR) I didn't just pull this out of a hat, you know :-) Where do you think it's going to install the library if you do that? SHLIB_INSTALL = \ $(mkinstalldirs) $(DESTDIR)$(slibdir); \ $(INSTALL_DATA) $(SHLIB_SONAME) \ $(DESTDIR)$(slibdir)/$(SHLIB_SONAME) -- Daniel Jacobowitz CodeSourcery
Re: A question on gimplifier
On Sat, Apr 14, 2007 at 11:28:59AM -0700, H. J. Lu wrote: > __builtin_ia32_vec_set_v2di will be expanded to > > [(set (match_operand:V2DI 0 "register_operand" "=x") > (vec_merge:V2DI > (vec_duplicate:V2DI > (match_operand:DI 2 "nonimmediate_operand" "rm")) > (match_operand:V2DI 1 "register_operand" "0") > (match_operand:SI 3 "const_pow2_1_to_2_operand" "n")))] That's irrelevant. You have a function, __builtin_ia32_vec_set_v2di, which you didn't show the type of - but there's probably nothing in the C builtin decl that says it modifies its arguments. If the RTL says that it clobbers its first input, then the RTL register allocator is responsible for handling that. -- Daniel Jacobowitz CodeSourcery
Re: Builtin functions?
On Mon, Apr 16, 2007 at 05:04:05PM +0100, Paulo J. Matos wrote: > _ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc > [operator<<]... SUCCESSFUL > Well, this is definitely builtin but DECL_BUILT_IN == 0, which means > that when I do FOR_EACH_BB_FN, I'm getting a segmentation fault. > > I wonder where my wrong assumption is. Any suggestions? What do you mean, it's built in? It comes from a source file, so almost by definition it isn't. -- Daniel Jacobowitz CodeSourcery
Re: Builtin functions?
On Mon, Apr 16, 2007 at 05:51:17PM +0100, Dave Korn wrote: > Perhaps Paulo wants to know if the definition originated in a system header > file? Yes, this is more likely to be useful. -- Daniel Jacobowitz CodeSourcery
Re: GCC 4.1 Projects
On Sun, Feb 27, 2005 at 02:57:05PM -0800, Mark Mitchell wrote: > Nathanael Nerode wrote: > >The libada-gnattools-branch suffers severely from having to be maintained > >in parallel with mainline (since it's a rearrangment of existing code). > >Another two months of waiting will necessitate many hours of totally > >unneccessary work on my part. > > The same is true for everyone who has to wait to check in a patch. > Conversely, checking something in can cause work for lots of other > people if things go wrong. > > >Although you have listed it as "stage 2", I wish to commit the finished > >portion as soon as possible during stage 1. I have maintainership > >authority > >to do so. This will not interfere in any way with *any* of the projects > >approved for stage 1, since it is in a disjoint section of code. > > If it breaks bootstrap, it will definitely interfere. If it causes > patch conflicts with other changes it will also interfere. And if it > doesn't cause any patch conflicts, then it probably won't be very hard > to maintain on a branch. Nathanael said it did not interfere with any of the other _projects_, not that it would be disjoint from all Stage 1 _patches_. And just because it would not be "very hard" to maintain on a branch doesn't mean he should have to do it. You maintain branches all the time, Mark; you know it's not a piece of cake. > > Accordingly, I plan to do so unless I am told not to. > > I would certainly prefer that you hold off until Stage 2, as indicated > by the documented I posted. I think that you need to be a little more specific when asking a maintainer to hold off on committing a patch that he has authority to commit, desire to commit, and has been maintaining separately - out of deference to the 4.0 schedule - for many months. He would have been well within his rights to not submit a project proposal at all, and just check it in. I'm sure many larger patches will go in during Stage 1 without any coordination. Could you explain what benefits from waiting? None of the other large, scheduled changes from 4.1 benefit from pushing this back. The only thing that it saves is one possible cause of broken bootstraps; you may as well ask no one to check in large patches, then. I'm sure plenty of people less careful than Nathanael will break bootstrap in the next few months. -- Daniel Jacobowitz CodeSourcery, LLC
Re: GCC 4.1 Projects
On Sun, Feb 27, 2005 at 03:56:26PM -0800, Mark Mitchell wrote: > Daniel Jacobowitz wrote: > >On Sun, Feb 27, 2005 at 02:57:05PM -0800, Mark Mitchell wrote: > > >Nathanael said it did not interfere with any of the other _projects_, > >not that it would be disjoint from all Stage 1 _patches_. > > Fair point. > > >>I would certainly prefer that you hold off until Stage 2, as indicated > >>by the documented I posted. > > > >Could you explain what benefits from waiting? None of the other large, > > The primary benefit is just reduced risk, as you suggest. > > The Stage 1 schedule looks full to me, and I'd like to see those patches > go in soon so that we can start shaking out the inevitable problems. > I'm much less worried about the long-term impact of Nathanael's patch; > if it breaks something, it will get fixed, and then that will be that. > But, that brief breakage might make things difficult for people putting > in things during Stage 1, or compound the problem of having an unstable > mainline. I think that's not a useful criteria for scheduling decisions. Let me be more concrete. Paolo Bonzini posted a patch to move in-srcdir builds to a host subdirectory. This is a substantial build infrastructure change, even though it will not affect a substantial number of developers - assuming it works correctly. I consider it no different "in kind" from Nathanael's changes. He can approve that; so a system where he can't approve his own tested patch is one in which you are overriding his judgement. ISTR that that is exactly what you did not want to do with this scheduling exercise. No offense intended to Paolo, of course! I picked a recent example. We're less than a week into stage 1, so I don't have much in the way of samples to draw on. > I do realize that this is a situation where people who try to be good > citizens could get penalized at the expense of people who aren't. I > would hope that maintainers should exercise discipline in that respect; > it's my feeling that those who submitted projects (like Nathanael) > should have an edge over others who pop up with big patches without > prior notice. s/could/absolutely will/. It's a remarkably strong incentive not to submit project proposals for 4.2. I appreciate your effort here, especially for collecting and organizing the project proposals. The sense of "what's coming" is extremely interesting to me - and hopefully extremely useful to those more active in GCC development than I am. I see less value in trying to schedule them in advance. Organizing windows around particular projects makes sense, in an ongoing fashion and as they become available. Pre-planning the windows assumes a lot about the state of the tree at the time, esp. other projects that come up during stage 1 development. And it assumes quite a lot about folks' estimates of their delivery dates, which I'd take with a grain of salt and a shot of vodka. It also encourages projects to be done out of HEAD. For some of these that makes sense, but for some of them it doesn't seem to. And projects which are pushed to stage 2 have less chance of breaking the tree in stage 1, but more chance of remaining broken; for instance, I would have liked to see top-level bootstrapping switched on ASAP. We already know that the common cases work, and it's going to take time to shake out the obscure cases. -- Daniel Jacobowitz CodeSourcery, LLC
Re: testsuite execution question
On Mon, Feb 28, 2005 at 04:14:12PM -0800, Janis Johnson wrote:
> > DejaGnu's definition of ${tool}_load has an optional argument for flags
> > to pass to the test program, but none of the procedures in DejaGnu or in
> > gcc/testsuite/* are set up to pass such flags. It would be fairly
> > straightforward to provide a local version of gfortran_load to intercept
> > calls to the global one, and have it add flags specified with a new test
> > directive to the DejaGnu version of ${tool}_load. That directive could
> > be something like:
> >
> > { dg-program-options options [{ target selector }] }
> >
> > Would something like this be useful for other languages as well, or is
> > Fortran the only one in GCC that has support to process a program's
> > command line?
> >
> > I'm willing to implement something like this if it looks worthwhile.
>
> It's supposed to be possible to drop in replacements to DejaGnu in the
> GCC testsuite; do other test frameworks of interest handle passing
> arguments to the test program in a way that could support this? (Sorry
> for talking to myself here.)
I don't think that's the concern here - it's more a matter of whether
the target, and DejaGNU, support this. Lots of embedded targets seem
to have trouble with it. Take a look at "noargs" in the DejaGNU board
files for a couple of examples, IIRC. GDB jumps through some hoops to
test this, and gets it wrong in a bunch of places too.
--
Daniel Jacobowitz
CodeSourcery, LLC
Re: testsuite execution question
On Tue, Mar 01, 2005 at 10:29:45AM -0800, Janis Johnson wrote: > Is command line processing relevant for embedded targets? (I have no > idea.) Tests that pass options to the test program could be skipped > for embedded targets and for other kinds of testing where it isn't > reliable. The dg-program-options directive could warn when it's used > in an environment for which it's not supported. Sounds good to me, at least in theory. -- Daniel Jacobowitz CodeSourcery, LLC
Re: testsuite execution question
On Fri, Mar 04, 2005 at 04:33:47PM -0800, Janis Johnson wrote: > On Tue, Mar 01, 2005 at 04:35:54PM -0500, Daniel Jacobowitz wrote: > > On Tue, Mar 01, 2005 at 10:29:45AM -0800, Janis Johnson wrote: > > > Is command line processing relevant for embedded targets? (I have no > > > idea.) Tests that pass options to the test program could be skipped > > > for embedded targets and for other kinds of testing where it isn't > > > reliable. The dg-program-options directive could warn when it's used > > > in an environment for which it's not supported. > > > > Sounds good to me, at least in theory. > > Any ideas on how the testsuite can decide for which targets it supports > command line arguments? Would it be reasonable to support them if the > target is not remote? Well, remote_load already accepts arguments. And there's a 'noargs' in lots of board files. I don't know how accurate that is. -- Daniel Jacobowitz CodeSourcery, LLC
Re: request for timings - makedepend
On Mon, Mar 07, 2005 at 07:56:05PM -0800, Mark Mitchell wrote: > We do need a story for generated headers. I'd be happy with explicit > dependencies in the Makefiles indicating what source files depend on > what generated headers. We'd still be able to get rid of 99% of the > dependencies in our Makefiles, and avoid most of the cases where > something either (a) fails to get rebuilt, or (b) gets rebuilt too often. Except, this is the most frequently reported dependency problem - missing dependencies on the generated headers lead to parallel build failure. I suspect we could get a lot of mileage out of something like libiberty uses, and declaring the things it can't handle to be bugs... -- Daniel Jacobowitz CodeSourcery, LLC
Re: problem with the scheduler in gcc-4.0-20040911
On Tue, Mar 08, 2005 at 09:38:19PM +0530, Kunal Parmar wrote: > Hello, > I have attached the dump after the scheduler. The branch instruction > is a conditionally executed branch instruction. So it is represented > as RTL COND_EXEC. Vladimir was right. It's an INSN, when it should be a JUMP_INSN. Your backend is probably using emit_insn when it should be using emit_jump_insn. -- Daniel Jacobowitz CodeSourcery, LLC
Re: Questions about trampolines
On Sun, Mar 13, 2005 at 09:24:19PM +0100, Øyvind Harboe wrote: > Trampolines are strange things... :-) > > - Are nested functions part of the C standard or a GCC extension? > I believe the answer is a GCC extension. I have seen evidence, > but no proof to this effect. That is right. > - AFAICT, the cris target is saving the value of the > static chain register in the trampoline. How can that work > with recursive functions? Does the cris target PASS or FAIL > gcc.dg/trampoline-1.c? > - Lately e.g. the AMD CPU has added support for making it impossible > to execute code on the stack. The town isn't big enough for > both stack based trampolines and stack code execution protection. > What happens now? Search for PT_GNU_STACK in the list archives. > - Are trampolines used for anything else but nested functions > in C? I believe they are used by Ada. Nested functions in other languages, presumably. > - Many backends do not support trampolines. Are trampolines > something that is ultimately being added to the backends? > - Do (theoretical?) alternatives to trampolines exist? I.e. something > that does not generate code runtime. -- Daniel Jacobowitz CodeSourcery, LLC
Re: Merging calls to `abort'
On Mon, Mar 14, 2005 at 04:49:41PM -0800, Eric Christopher wrote: > > > > Now, I wouldn't object to hacking GCC to avoid cross-jumping calls to > > > abort. It's just that I don't think that the common GNU use of abort > > > serves the users. > > Agreed. And as someone suggested, rather than treating abort > > specially within GCC, I think we'd be better off with a function > > attribute which prevented cross jumping to any function with > > the attribute set. > > I think it makes sense to just not crossjump noreturn attribute > functions if we're going to do this. I'm inclined to agree. I also think that we should be making this change, at least at -O2. I talked to Mark Mitchell about this briefly this evening. He pointed out that __cxa_throw is a noreturn function where crossjumping is often useful. So perhaps we do need an attribute, but I'm not sure which way the default should go. -- Daniel Jacobowitz CodeSourcery, LLC
Re: Profile-directed feedback and remote testing
On Thu, Mar 24, 2005 at 11:59:55PM -0800, Mark Mitchell wrote: > When we generate data for feedback, we insert the .gcda name into the > object file as an absolute path. As a result, when we try to do remote > testing, we lose, as, in general the remote file system does not have > the same file hierarchy as the build system. > > I understand why we generate an asbolute path; we want to make sure that > the data ends up there, not in the directory where the user happens to > run the program. So, I intend to disable these tests when $host != > $target. Any objections, or better ideas? It would be nice if we could preserve the ability to run them - when your build directory is mounted on the target system at the same path, the tests will pass. Perhaps a compiler option, as Gabriel suggested... -- Daniel Jacobowitz CodeSourcery, LLC
Re: PCH and moving gcc binaries after installation
On Tue, Mar 29, 2005 at 10:37:33PM -0800, Dan Kegel wrote: > Since I need to handle old versions of gcc, I'm > going to code up a little program to fix all > the embedded paths anyway, but I was surprised > by the paths in the pch file. Guess I shouldn't > have been, but now I'm a little less confident > that this will work. Has anyone else tried it? I would guess that they're just debugging information. The PCH shouldn't care. -- Daniel Jacobowitz CodeSourcery, LLC
Re: -fno-common
On Thu, Mar 31, 2005 at 07:33:53PM +0100, Dave Korn wrote: > Is the manual wording just slightly vague here, and both .data and .bss > are regarded as covered by the phrase "the data section of the object file"? Yes. -- Daniel Jacobowitz CodeSourcery, LLC
Re: PCH versus --enable-mapped-location
On Thu, Mar 31, 2005 at 01:25:45PM -0800, Per Bothner wrote: > Geoff Keating wrote: > >> * Any source_location values handed out before the #include > >>that restores the gch will become invalid. They will be re-mapped > >>to that in the pre-compiled header. Presumably that's ok - there's > >>no declartions or expressions in the main file at that point, or > >>the restore would have failed. Any declarations that are > >>or in the will presumably be the same either way. > > > > > >Another way of putting this is that source_location values should be in > >GCed memory. I think they all are, certainly all declarations and macro > >definitions are. > > I think you're misunderstanding my concern. The issue is when we're > processing a .c file normally we generate source_location cookies > for , , and any tokens until we process the > #include that restores the pch. At that point we (need to) restore > the line number saved in the pch. Any source_location cookies > that we've handed out up until then become invalid, because they > refer to a line_table that has been replaced. My point is that > presumably it doesn't matter, since the source_location cookies > and declarations corresponing to and > should match, when compared with those at pch-generation time. > The ones that don't match are any source_location cookies for > tokens in the main file itself. However, they should just be > tokens for white space, comments, and the initial #include that > triggers the pch-restoration, and there should be nothing except > garbage that use those now-invalid source_locations. That's exactly what Geoff said. There are two relevant properties of GCed memory here: - Anything in GCed memory will be saved to the PCH - Anything in GCed memory will be overwritten by loading the PCH. There will be no references left after the PCH is loaded, unless they were living outside of GC. -- Daniel Jacobowitz CodeSourcery, LLC
Re: Use Bohem's GC for compiler proper in 4.1?
On Fri, Apr 01, 2005 at 06:48:56PM +0200, Stefan Strasser wrote: > Andrew Haley schrieb: > >Sam Lauber writes: > > > I know that Bohem's GC is used in the Java runtime for GCC. > > > However, the compiler proper itself can _really_ cramp people's > > > avalible RAM (for those who don't belive me and have Windows w/ > > > DJGPP, change all the memory controls from `auto' to the highest > > > value and just try to compile libiberty/regex.c), so my suggestion > > > is usage of Bohem's GC in the compiler proper itself. > > > >Do you have any reason to believe that such a change would reduce > >memory consumption? > > > > I have reason to believe that it would increase performance on low > memory systems/large translation units: it seems that current gcc gc > performs a full memory scan on each collection, right? at least if gcc > uses more memory than physically available it spends a _very_ long time > swapping during collections. > boehm gc could help here since it is a generational collector. There are other ways to solve this problem, including creating a generational collector using our existing accurate GC. I've been working on this on-and-off (mostly off at the moment, though). -- Daniel Jacobowitz CodeSourcery, LLC
Re: Use Bohem's GC for compiler proper in 4.1?
On Sat, Apr 02, 2005 at 10:40:35AM -0600, Larry Evans wrote: > I briefly looked at: > > Type-Information.html > > from: > > http://gcc.gnu.org/onlinedocs/gccint-html.tar.gz > > I was wondering why the method described here: > > http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_source/gc_typedh.txt > > was not used instead to create an accurate GC method in the compiler. > I assume the reason is that using: > >GTY(()) > > as described in the .html file was just easier and less error prone > than Boehm's at the cost of requiring some extra preprocesssing? They don't have the same design constraints or goals. For instance, the GTY machinery can determine the type of an object during tree walking; it does not need to store the type in memory. We also reuse the GTY machinery for precompiled header support; I don't know if we could get Boehm to do that. -- Daniel Jacobowitz CodeSourcery, LLC
Re: Using inline assembly with specific register indices
On Tue, Apr 05, 2005 at 07:24:44AM +0300, [EMAIL PROTECTED] wrote:
> Hi guys/ladies,
>
> I'm currently designing an ISA add-on to the MIPS architecture. My
> intention is to use it (it is an algorithm accelerator actually) as a
> COP2 (coprocessor #2). The corresponding microarchitecture is stable
> (works at register-transfer level, not subject to change). Plus, I
> would be happy NOT TO CHANGE my ISA add-on.
>
> My problem is that I would like to access specific indices in the data
> register file of COP2, i.e. registers c2r0 to c2r31. This should be
> done in inline assembly or else I'll have to put down probably 2k-3k
> C-lines in assembly :-)
>
> Is it possible to write down something like this:
>
> asm("cop2a %0, %1;", :: "r" (cp2rb(i)) : "r" (cp2rb(j)));
If GCC knows about the registers on the coprocessor, then you can use
local register variables for this:
long c2r0 asm ("c2r0");
If it doesn't, then you should probably not be telling GCC about them.
Assuming i is constant:
asm volatile ("cop2a c2r" STRINGIFY(i) ", c2r" STRINGIFY(j) );
--
Daniel Jacobowitz
CodeSourcery, LLC
Re: Using inline assembly with specific register indices
On Tue, Apr 05, 2005 at 07:27:00AM +0300, [EMAIL PROTECTED] wrote: > I was wondering... > > why not support asm templates THAT ARE NOT string constants??? And I > mean for static compilation cases only. > > For example: > > asm(instrx $%d, $%d\n",src1,src2 : "=r" (var1) : "r" (var2)); > > I assume printf-like formating. Because it's unnecessary. See my previous message; you can find many examples on the Web of how to use CPP to stringify numbers. -- Daniel Jacobowitz CodeSourcery, LLC
Re: Obsoleting c4x last minute for 4.0
On Tue, Apr 05, 2005 at 02:30:47PM -0400, Paul Schlie wrote: > > Kazu Hirata wrote: > > I would like to propose that the c4x port be obsoleted for 4.0. > > > > c4x-* > > tic4x-* > > > > The primary reason is that the port doesn't build. > > > > Richard Sandiford's recent patch allows us to go further during the > > build process, but the port still does not build. > > Although personally believe the port's use of a 32-bit QI mode is odd > (and should be enabled by GCC to be defined as SI mode without QI/HI modes > being required, where correspondingly BITS_PER_UNIT should being presumed > to represent just the minimum alignment required by the port not > necessarily the width of QI mode which should likely be defined as the > width of the target's byte separately), it would still be nice to see GCC > cleaned to enable the port to build as it stresses the few remaining > assumptions scattered though out the source which should be eliminated. This is a bogus reason to preserve the port; it should be preserved iff it works, is maintained, and is used. It's failing #1 at least. If you want these restrictions fixed, presumably you have some interest in some port that cares about them. Contribute that port, and maybe a usable simulator for them, and then people can fix what breaks - and test it. -- Daniel Jacobowitz CodeSourcery, LLC
Re: GCC 3.4.3
On Fri, Apr 08, 2005 at 09:05:17AM -0400, Ray Holme wrote: > Many thanks to all for the lessons on how NOT to make things you don't > want. > > After 56 hours teh full make bootstrap finished - make install failed > miserable as > install.sh was not where it belonged - so I copied the SRCDIR install.sh > in and that made the top level installs work, but the sub-sub directories > were still looking for ../install-sh - so I copied it down another level FYI, this is already fixed in HEAD and the 3.4 branch. -- Daniel Jacobowitz CodeSourcery, LLC
Re: GCC 3.4.3
On Fri, Apr 08, 2005 at 10:13:38AM -0700, Joe Buck wrote: > On Fri, Apr 08, 2005 at 09:20:47AM -0400, Daniel Jacobowitz wrote: > > On Fri, Apr 08, 2005 at 09:05:17AM -0400, Ray Holme wrote: > > > Many thanks to all for the lessons on how NOT to make things you don't > > > want. > > > > > > After 56 hours teh full make bootstrap finished - make install failed > > > miserable as > > > install.sh was not where it belonged - so I copied the SRCDIR install.sh > > > in and that made the top level installs work, but the sub-sub directories > > > were still looking for ../install-sh - so I copied it down another level > > > > FYI, this is already fixed in HEAD and the 3.4 branch. > > The same bug is present in binutils 2.15 (and yes, I filed a PR), and I > wouldn't be surprised if it's in other "Cygnus tree" tools like gdb as > well. Don't know if it's been fixed in CVS. Yes, since the fix was in the top level. I have already closed at least two binutils PRs about this as FIXED - searching for product == binutils, subject containing install, state containing RESOLVED would have shown them. -- Daniel Jacobowitz CodeSourcery, LLC
Re: Major bootstrap time regression on March 30
On Sat, Apr 09, 2005 at 12:35:47AM +0200, Steven Bosscher wrote: > On Saturday 09 April 2005 00:32, Diego Novillo wrote: > > On Thu, Apr 07, 2005 at 08:34:01PM -0400, Diego Novillo wrote: > > > I'm rebooting the machine into the previous kernel right now to > > > see if it changes things. Tomorrow's run will use kernel > > > 2.6.10-1.760_FC3. > > > > Well, it seem that the kernel had nothing to do with the problem. > > Today's bootstrap time was 7,960 seconds. > > My suspect is still the ::bind patch. Unfortunately you don't > keep times of libstdc++v3 build times. Not sure how to check > this, except maybe rolling back libstdc++ to March 30... Except that would have shown up in Jim's test... -- Daniel Jacobowitz CodeSourcery, LLC
Re: GCC 4.0 Ada Status Report (2005-04-09)
On Sat, Apr 09, 2005 at 12:18:09PM +0200, Laurent GUERBY wrote: > Unfortunately this is a real core dump while running the test on my > machine (glibc-2.3.3-118 SuSE 9.2) at -O2 or -O0, and this does not > reproduce under GDB, see below. I don't know about valgrind on x86_64, > is it available? Nope. Your best bet would be to turn up ulimit -c and look at a core dump. -- Daniel Jacobowitz CodeSourcery, LLC
Re: libiberty configure mysteries
On Sun, Apr 10, 2005 at 05:02:36PM +0200, Gabriel Dos Reis wrote: > > Hi, > > The following is from libibtery.h > >/* HAVE_DECL_* is a three-state macro: undefined, 0 or 1. If it is > undefined, we haven't run the autoconf check so provide the > declaration without arguments. If it is 0, we checked and failed > to find the declaration so provide a fully prototyped one. If it > is 1, we found it so don't provide any declaration at all. */ > > However, that appears to be incorrect because what configure output in > config.h is not HAVE_DECL_XXX, but HAVE_XXX. Therefore, it appears > that libiberty would be misdetecting declarations -- it thinks > something is missing, whereas in fact it is not. > > Am I missing something here? Try adding an AC_CHECK_DECLS call for basename. That will define HAVE_DECL_BASENAME. -- Daniel Jacobowitz CodeSourcery, LLC
Re: libiberty configure mysteries
On Sun, Apr 10, 2005 at 05:52:01PM +0200, Gabriel Dos Reis wrote: > Daniel Jacobowitz <[EMAIL PROTECTED]> writes: > > | On Sun, Apr 10, 2005 at 05:02:36PM +0200, Gabriel Dos Reis wrote: > | > > | > Hi, > | > > | > The following is from libibtery.h > | > > | >/* HAVE_DECL_* is a three-state macro: undefined, 0 or 1. If it is > | > undefined, we haven't run the autoconf check so provide the > | > declaration without arguments. If it is 0, we checked and failed > | > to find the declaration so provide a fully prototyped one. If it > | > is 1, we found it so don't provide any declaration at all. */ > | > > | > However, that appears to be incorrect because what configure output in > | > config.h is not HAVE_DECL_XXX, but HAVE_XXX. Therefore, it appears > | > that libiberty would be misdetecting declarations -- it thinks > | > something is missing, whereas in fact it is not. > | > > | > Am I missing something here? > | > | Try adding an AC_CHECK_DECLS call for basename. That will define > | HAVE_DECL_BASENAME. > > Thanks. I tried it, but I did not have much success -- configure is > outputting HAVE_BASENAME instead of HAVE_DECL_BASENAME. You should have both; did you rerun autoheader? AC_CHECK_FUNCS will genereate HAVE_BASENAME. -- Daniel Jacobowitz CodeSourcery, LLC
Re: Getting rid of -fno-unit-at-a-time [Was Re: RFC: Preserving order of functions and top-level asms via cgraph]
On Mon, Apr 11, 2005 at 10:02:06AM -0700, Daniel Kegel wrote: > BTW, I hope -fno-unit-at-a-time doesn't go away until at least gcc-4.1.1 > or so... I still lean on that crutch. A user! Can you explain why? -- Daniel Jacobowitz CodeSourcery, LLC
Re: Getting rid of -fno-unit-at-a-time [Was Re: RFC: Preserving order of functions and top-level asms via cgraph]
On Tue, Apr 12, 2005 at 06:34:29PM +0200, Andi Kleen wrote: > Daniel Jacobowitz <[EMAIL PROTECTED]> writes: > > > On Mon, Apr 11, 2005 at 10:02:06AM -0700, Daniel Kegel wrote: > >> BTW, I hope -fno-unit-at-a-time doesn't go away until at least gcc-4.1.1 > >> or so... I still lean on that crutch. > > > > A user! Can you explain why? > > The x86-64 2.4 linux kernel uses it too, because some code relies on > the ordering between asm and several functions. > Other Linux ports might be similarly affected. 2.6 is fixed, but the > fix is a bit too big to merge into a stable-nearly-dead tree like 2.4. Thanks. I was under the impression that 2.4 doesn't build with GCC HEAD, anyway - I saw some patches pile up and not get applied. Does 2.6 still use the option? -- Daniel Jacobowitz CodeSourcery, LLC
Re: Patches for coldfire v4e
On Wed, Apr 13, 2005 at 10:10:39AM +0200, Bernardo Innocenti wrote: > >>What are the changes you need to apply? > >> > >>Would plain 68020 code run on v4e processor? As far > >>as I can see, m68k-linux isn't a multilib target. > > > > > > Problem occurs mainly due to restricted addressing > > modes in v4e. For ex v4e supports only 16-bit > > displacements. So all crt* files needs to be build for > > v4e. Also v4e does not have extended floating point > > instructions (XF mode) so we may have to modify t-* > > for fpgnulib.c. > > So it seems adding coldfire-linux is the only way > to address this... Why? Adding support (if it isn't already there) for something like --with-arch=coldfire should work just as well. -- Daniel Jacobowitz CodeSourcery, LLC
