Re: dwarf2 unwinder hacks get my static build going: Bug, or indication of what I'm doing wrong?
Richard Henderson writes: > > I will say that staticly linked linuxthreads tls is known to be > broken. Or at least known to me. I encountered this while doing > OpenMP work on RHEL3. The problem I saw doesn't appear with nptl. Ah, that's a useful clue. I can confirm that this is definitely unreproducible on my system with NPTL. Andrew.
Re: LLVM/GCC Integration Proposal
On 11/19/05, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote: > On Fri, Nov 18, 2005 at 05:50:52PM -0800, Chris Lattner wrote: > > * This will not support ! > > > > As describe above, we won't support every target that GCC currently > > does. Three options are possible: > > > > 1. We (the GCC community) could build an LLVM to GIMPLE translator. > > This would probably take about as much work as the GIMPLE -> LLVM > > translator (about 4000 LOC), which is not a huge project. > > 2. We could build an LLVM to RTL translator. > > Let's run with the hypotheticals for a bit here... I have questions for > both Chris and for GCC maintainers. > > Chris tells me that an LLVM->GIMPLE translator wouldn't have target > dependencies. I'm not 100% sure I buy that, but I'll take it as given > for now (if not they should be pleasantly small). So suppose we > implement that. It seems like a much better choice than RTL anyway. > > (A) What bits of LLVM would we be bypassing, and how badly would we > miss them? > > I know it has its own register allocation and instruction selection, > and they have advantages and disadvantages relative to the existing > ones. We could either take advantage of those as a framework to > modernize GCC's, or move on with Andrew's new design to modernize > GCC's. I would propose to even think of doing only IPO at LLVM and go back to gimple for the rest of the tree-ssa pipeline. At least that should be possible. Would we get link-time optimization this way, or is the LLVM link-time optimization architected differently? Also, integrating LLVM addresses the weakness of our middle-end IR, but stays with this IR for our frontends. Only the Ada frontend seems to be in a state to maybe support direct frontend IR to LLVM translation. So the hard remaining parts would still be to convert the frontends to IRs suiting them well and only then we would be able to get rid of (old) trees completely. But maybe such modular frontends would raise concerns of the FSF again. It's good to see the LLVM integration experiment done, and having parts of that integration moved to mainline (like C++ support, or even the LLVM backend(!) parts) would be nice. Richard.
Re: GCC 4.1 branch created
On Fri, 18 Nov 2005, Mark Mitchell wrote: > # Generate the next mainline snapshot manually, using the -p option of > the gcc_release script. For that single run, adjust the script such that > the announcement mail is sent to you personally so that you can adjust > references to the previous snapshot in the README and index.html files > of the new snapshot as well as the mail itself before relaying it. I've disabled the mainline snapshot cron job as I won't get to this before the time it would have run. -- Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/ [EMAIL PROTECTED] (personal mail) [EMAIL PROTECTED] (CodeSourcery mail) [EMAIL PROTECTED] (Bugzilla assignments and CCs)
Re: LLVM/GCC Integration Proposal
On Fri, 18 Nov 2005, Chris Lattner wrote: > 1. The build system is taught about C++ code. With toplevel bootstrap this will bootstrap libstdc++ so that the compiler ends up linked with the new libstdc++ not the (in general ABI-incompatible) old one? (This question applies to all projects involving C++ in GCC.) > While it has many virtues, LLVM is still not complete, and we are investing in > adding the missing features. In particular, this system is missing two key > features to be truly useful: debug info support and inline asm support. Apple > is currently investing in adding both these features, as well as adding vector > support. What (on any one target of your choice) is the GCC testsuite status when LLVM-enabled, compared to that without LLVM, and are most of the regressions fixed by the addition of debug info, inline asm and vector support? (Once debug info support is added, the same question applies regarding GDB testsuite status.) Do you propose annotating testcases for features not supported with LLVM so they are XFAILed when configured with --enable-llvm? (XFAIL would be right for features the compiler should support but LLVM doesn't yet; UNSUPPORTED for tests of some incidental feature of the current back-end implementation which it makes sense for replacement infrastructure not to support. A switch to LLVM as the default back-end for a target would require no such XFAILs for that target, though there might be UNSUPPORTEDs, buggy testcases might be fixed or removed and features might be removed through the usual deprecation process. dg-xfail-if and dg-skip-if with an llvm effective-target keyword are the way to annotate the tests.) -- Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/ [EMAIL PROTECTED] (personal mail) [EMAIL PROTECTED] (CodeSourcery mail) [EMAIL PROTECTED] (Bugzilla assignments and CCs)
svn speed traversing slow filesystems
Hi Dan,
(BTW, sorry for the reposted messages.)
While I was waiting for some svn commands to finish (cleanup, update)
on my solaris2.7 box, which has a slow filesystem, I happened to run
truss -p out of curiosity to see what was taking so long.
Turns out that svn does many file operations on long pathnames. I
recall that gnu find and other gnu utilities that do directory
traversal got jumbo speedups by changing to the directory and running
the file ops on "./filename" without long path prefixes.
Could a future svn version get the same speedup? I'm running:
svn, version 1.3.0 (Release Candidate 2)
Thanks,
--Kaveh
PS: Are we still at RC2?
PPS: Here's sample output from truss that I'm talking about:
lstat("gcc/testsuite/gcc.dg/vect/vect-63.c", 0xFFBEE900) = 0
stat("gcc/testsuite/gcc.dg/vect/.svn/props/vect-46.c.svn-work", 0xFFBEF1F8) = 0
stat("gcc/testsuite/gcc.dg/vect/.svn/prop-base/vect-46.c.svn-base", 0xFFBEF1F8)
= 0
lstat("gcc/testsuite/gcc.dg/vect/vect-46.c", 0xFFBEE900) = 0
stat("gcc/testsuite/gcc.dg/vect/.svn/props/vect-82.c.svn-work", 0xFFBEF1F8) = 0
stat("gcc/testsuite/gcc.dg/vect/.svn/prop-base/vect-82.c.svn-base", 0xFFBEF1F8)
= 0
lstat("gcc/testsuite/gcc.dg/vect/vect-82.c", 0xFFBEE900) = 0
stat("gcc/testsuite/gcc.dg/vect/.svn/props/vect-29.c.svn-work", 0xFFBEF1F8) = 0
stat("gcc/testsuite/gcc.dg/vect/.svn/prop-base/vect-29.c.svn-base", 0xFFBEF1F8)
= 0
lstat("gcc/testsuite/gcc.dg/vect/vect-29.c", 0xFFBEE900) = 0
stat("gcc/testsuite/gcc.dg/vect/.svn/props/vect-65.c.svn-work", 0xFFBEF1F8) = 0
stat("gcc/testsuite/gcc.dg/vect/.svn/prop-base/vect-65.c.svn-base", 0xFFBEF1F8)
= 0
lstat("gcc/testsuite/gcc.dg/vect/vect-65.c", 0xFFBEE900) = 0
stat("gcc/testsuite/gcc.dg/vect/.svn/props/vect-48.c.svn-work", 0xFFBEF1F8) = 0
stat("gcc/testsuite/gcc.dg/vect/.svn/prop-base/vect-48.c.svn-base", 0xFFBEF1F8)
= 0
lstat("gcc/testsuite/gcc.dg/vect/vect-48.c", 0xFFBEE900) = 0
stat("gcc/testsuite/gcc.dg/vect/.svn/props/vect-67.c.svn-work", 0xFFBEF1F8) = 0
stat("gcc/testsuite/gcc.dg/vect/.svn/prop-base/vect-67.c.svn-base", 0xFFBEF1F8)
= 0
lstat("gcc/testsuite/gcc.dg/vect/vect-67.c", 0xFFBEE900) = 0
stat("gcc/testsuite/gcc.dg/vect/.svn/props/vect-86.c.svn-work", 0xFFBEF1F8) = 0
stat("gcc/testsuite/gcc.dg/vect/.svn/prop-base/vect-86.c.svn-base", 0xFFBEF1F8)
= 0
lstat("gcc/testsuite/gcc.dg/vect/vect-86.c", 0xFFBEE900) = 0
stat("gcc/testsuite/gcc.dg/vect/.svn/props/vect-69.c.svn-work", 0xFFBEF1F8) = 0
stat("gcc/testsuite/gcc.dg/vect/.svn/prop-base/vect-69.c.svn-base", 0xFFBEF1F8)
= 0
lstat("gcc/testsuite/gcc.dg/vect/vect-69.c", 0xFFBEE900) = 0
stat("gcc/testsuite/gcc.dg/vect/.svn/props/vect-88.c.svn-work", 0xFFBEF1F8) = 0
stat("gcc/testsuite/gcc.dg/vect/.svn/prop-base/vect-88.c.svn-base", 0xFFBEF1F8)
= 0
lstat("gcc/testsuite/gcc.dg/vect/vect-88.c", 0xFFBEE900) = 0
stat("gcc/testsuite/gcc.dg/vect/.svn/props/vect-83_64.c.svn-work", 0xFFBEF1F8)
= 0
stat("gcc/testsuite/gcc.dg/vect/.svn/prop-base/vect-83_64.c.svn-base",
0xFFBEF1F8) = 0
lstat("gcc/testsuite/gcc.dg/vect/vect-83_64.c", 0xFFBEE900) = 0
stat("gcc/testsuite/gcc.dg/vect/.svn/props/vect-11.c.svn-work", 0xFFBEF1F8) = 0
stat("gcc/testsuite/gcc.dg/vect/.svn/prop-base/vect-11.c.svn-base", 0xFFBEF1F8)
= 0
lstat("gcc/testsuite/gcc.dg/vect/vect-11.c", 0xFFBEE900) = 0
stat("gcc/testsuite/gcc.dg/vect/.svn/props/vect-30.c.svn-work", 0xFFBEF1F8) = 0
--
Kaveh R. Ghazi [EMAIL PROTECTED]
Overwrite a file with "svn update"?
Perhaps, I missed the required options, but I'll ask an obvious question anyway. Often when testing a patch, one will often place a new testcase in gcc/testsuite/*. This new file is not under control of svn. After review, the patch is committed to the tree. Now, I want to update my local repository. I issue "svn update" and the result is svn: Failed to add file 'gcc/testsuite/gfortran.dg/fgetc_1.f90': \ object of the same name already exists which is indeed correct. So, is there an option to tell svn to blow away files that conflict with files in the repository. -- Steve
Re: LLVM/GCC Integration Proposal
On Fri, 18 Nov 2005 17:50:52 -0800, Chris Lattner wrote: > Recently, at Apple, I have been working on a new version of the llvm- > gcc translation layer, built on GCC 4 ... I plan to have this work > committed to the Apple branch within a month. I'm curious as to why Apple is doing this. Is it simply that they think a GCC with LLVM merged in would be better and don't care for the FSF politics of it all? Or is there some interest in using the LLVM IR as a CPU abstraction for software distribution (as was talked about in the context of autopackage on the LLVM list?). thanks -mike
Can't build 4.1 branch on Linux x86
I am trying to build 4.1 branch but make profiledbootstrap stops here: stage1/xgcc -Bstage1/ -B/usr/gcc_4.1/i486-slackware-linux/bin/ -c -O2 -g -fomit-frame-pointer -fprofile-use -freorder-blocks-and-partition -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -Wmissing-format-attribute -DHAVE_CONFIG_H -I. -I. -I../../gcc-4_1-branch/gcc -I../../gcc-4_1-branch/gcc/. -I../../gcc-4_1-branch/gcc/../include -I../../gcc-4_1-branch/gcc/../libcpp/include ../../gcc-4_1-branch/gcc/attribs.c -o attribs.o /tmp/ccdVBwIk.s: Assembler messages: /tmp/ccdVBwIk.s:1280: Error: invalid sections for operation on `.LCFI71' and `.LCFI70' make[2]: *** [attribs.o] Error 1 make[2]: Leaving directory `/root/SVN/GCC/build/gcc' make[1]: *** [stagefeedback_build] Error 2 make[1]: Leaving directory `/root/SVN/GCC/build/gcc' make: *** [profiledbootstrap] Error 2 This is on x86 Linux system. binutils 2.16.91.0.4 gcc 4.0.3 20051103 and with the following flags: export CFLAGS="-O2 -march=pentium-m -mfpmath=sse -msse2" export CXXFLAGS="-O2 -march=pentium-m -mfpmath=sse -msse2" export LDFLAGS="-Wl,--as-needed -z combreloc -Wl,-O1 -Wl,--enable-new-dtags" Could anyone help? Regards Papadakos Panagiotis
Re: Can't build 4.1 branch on Linux x86
On 11/19/05, Panagiotis Papadakos <[EMAIL PROTECTED]> wrote: > I am trying to build 4.1 branch but make profiledbootstrap stops here: See http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00857.html for a patch that fixes the problem. Richard.
Re: Can't build 4.1 branch on Linux x86
Well, seems related to PR 22313 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22313 -- Papadakos Panagiotis
Re: LLVM/GCC Integration Proposal
Richard Guenther writes: I would propose to even think of doing only IPO at LLVM and go back to gimple for the rest of the tree-ssa pipeline. At least that should be possible. Would we get link-time optimization this way, or is the LLVM link-time optimization architected differently? Sure, given an LLVM -> GIMPLE translator, this would certainly work. One thing that is useful to keep in mind is the desire to perform scalar optimizations before IPO. With translators both ways, you could choose to make these optimizations be either tree-ssa or LLVM (or a mix). Also, integrating LLVM addresses the weakness of our middle-end IR, but stays with this IR for our frontends. One important aspect of this work is that it changes tree structures into something that are only used by the front-end, not the optimizers. Because of that, it is corresondingly easier to change trees, and making them work really well for front-ends could be a follow-on project. Only the Ada frontend seems to be in a state to maybe support direct frontend IR to LLVM translation. Sure, also maybe Fortran? -Chris -- http://nondot.org/sabre/ http://llvm.org/
Re: LLVM/GCC Integration Proposal
On Sat, 19 Nov 2005, Joseph S. Myers wrote: On Fri, 18 Nov 2005, Chris Lattner wrote: 1. The build system is taught about C++ code. With toplevel bootstrap this will bootstrap libstdc++ so that the compiler ends up linked with the new libstdc++ not the (in general ABI-incompatible) old one? (This question applies to all projects involving C++ in GCC.) No, my personal configure-fu is too weak to attempt this, and I haven't dug into the problem yet. I currently depend on there already being both a native C++ compiler (like Ada depends on having a native Ada compiler) and that the libstdc++'s are compatible. This is a deficiency in the current implementation, not something that is unsolvable. While it has many virtues, LLVM is still not complete, and we are investing in adding the missing features. In particular, this system is missing two key features to be truly useful: debug info support and inline asm support. Apple is currently investing in adding both these features, as well as adding vector support. What (on any one target of your choice) is the GCC testsuite status when LLVM-enabled, compared to that without LLVM, and are most of the regressions fixed by the addition of debug info, inline asm and vector support? I'm sorry but I haven't gotten to that point yet. I've been working on the integration project for only about 3 weeks now, so I haven't had a chance to do as much testing as I would like (which is why I suggested not merging for a month). Basically right now things are working well enough for me to build and run (correctly :) ) several dozen small-to-medium sized GUI apps written in C and ObjC on PowerPC. If you're familar with the Apple Xcode distribution, I've basically been working on apps out of /Developer/Examples. Everything I have tried (which is all of the large programs and many of the small ones) work fine. I intend to get C++ up and running as well as doing Dejagnu testing before actually merging into the Apple branch. (Once debug info support is added, the same question applies regarding GDB testsuite status.) Clearly, as we bring up debug info support we will use all of the suites to make sure we've done it right! :) Do you propose annotating testcases for features not supported with LLVM so they are XFAILed when configured with --enable-llvm? (XFAIL would be right for features the compiler should support but LLVM doesn't yet; UNSUPPORTED for tests of some incidental feature of the current back-end implementation which it makes sense for replacement infrastructure not to support. A switch to LLVM as the default back-end for a target would require no such XFAILs for that target, though there might be UNSUPPORTEDs, buggy testcases might be fixed or removed and features might be removed through the usual deprecation process. dg-xfail-if and dg-skip-if with an llvm effective-target keyword are the way to annotate the tests.) I don't have any strong plans or feelings on this. My initial idea was to have a staged approach, something like this: 1. Initially the work is done on a branch (e.g. the Apple branch) and must be explicitly enabled (e.g. with --enable-llvm). Implementation of missing features continues. I should note that the patch doesn't tie into anything Apple-specific in the Apple branch. 2. When the basics are finished (e.g. inline asm, debug support, vectors), I would consider it ready to merge to mainline. At that point, adjusting XFAIL markers would make sense. The big question is the --enable-llvm configure option. Without an LLVM->GIMPLE or LLVM->RTL translator, it seems impossible to merge LLVM to mainline without the configure option. Having this translator has advantages other than supporting all of the GCC targets: it allows more flexible choice of what is part of LLVM and what isn't. It also allows use the new RTL-based register allocator work when it comes online. If anyone is interested in working on the translator, it would be a great help. I expect that my hands will be full of various front-end translation and LLVM extension work for the next few weeks, so I personally won't be able to build it for some time. Finally, I should note that the patch isn't a secret. I'm waiting to merge it in until it is more tested and feature complete... I'm not trying to hide it. If anyone wants a copy, please just let me know and I'll be happy to provide it. -Chris -- http://nondot.org/sabre/ http://llvm.org/
Re: svn speed traversing slow filesystems
On Sat, 2005-11-19 at 10:14 -0500, Kaveh R. Ghazi wrote: > Hi Dan, > > (BTW, sorry for the reposted messages.) > > While I was waiting for some svn commands to finish (cleanup, update) > on my solaris2.7 box, which has a slow filesystem, I happened to run > truss -p out of curiosity to see what was taking so long. > Turns out that svn does many file operations on long pathnames. I > recall that gnu find and other gnu utilities that do directory > traversal got jumbo speedups by changing to the directory and running > the file ops on "./filename" without long path prefixes. > > Could a future svn version get the same speedup? Actually, i just removed the need for most stat calls during update in 1.4.
Re: Overwrite a file with "svn update"?
On 11/19/05, Steve Kargl <[EMAIL PROTECTED]> wrote: > which is indeed correct. So, is there an option to tell > svn to blow away files that conflict with files in the > repository. Subversion is reluctant to blow away users' files; this was one of the qualities of CVS we thought we should try to retain. However, if I'm understanding it right, here Subversion is hesitating to replace a file with a file of the same name whose contents are the same. Is that correct? It seems to me like Subversion could reasonably handle that the same way it does when an update brings in textual changes to an existing file that already has those changes in it: it says, "Oh, you have this already" and doesn't worry about it. Has the file in your local repository been added with 'svn add'? Or is it an unknown file from Subversion's point of view?
Re: Register Allocation
Andrew MacLeod <[EMAIL PROTECTED]> writes: > The document is intended as a starting point and consists mostly of my > thoughts at the moment. By the time the underlying RTL bits are done, I > would like it to have evolved to include input from others. The more > useful comments there are, the better the chance of us getting a decent > allocator. Thanks for thinking about this and writing this up. When I look at reload, there are a few things that make the code overly complex: reload inheritance, general hueristics to handle memory addresses which are intended to work on all machines, and secondary/tertiary reloads and the reload_in/out patterns. So I'd like to quickly look at these in your framework. Secondary/tertiary reloads and reload_in/out patterns are apparently subsumed by the Spill Engine. Porting a target to the new framework is going to require providing the Spill Engine with the appropriate instructions for storing and loading each native register class, including a description of any temporary or scratch registers required. That seems reasonable. One minor thing that I don't quite understand is that bit about reaching a limit of SPILLIDs. For targets with limited displacement, what matters is when you start needing larger displacements, which as far as I can see has more to do with the overall stack frame size than the number of SPILLIDs. Reload inheritance is a complex idea threaded through reload. The goal is to reuse values which happen to already be in registers whenever possible. In particular, to do this for reloads required for a single insn. A typical simple example is 'a++' where 'a' winds up living on the stack at a large unrepresentable offset. You don't want to wind up computing the address of 'a' twice, although that is what a naive spill code implementation. That example is too simple, I suppose, but it has the right general flavor. Reload inheritance is particularly important on machines with limited numbers of registers and limited addressing capability--e.g., SH, Thumb, MIPS16. The current reload implementation needs to do reload inheritance as it goes, or it will run out of spill registers in some cases. That is why a reload CSE pass after reload is not enough to solve the problem. I would be interested in your thoughts on handling this general issue in your framework. One approach that seems reasonably promising to me is to first do pseudo spill code for the instructions in a basic block, then run CSE over the pseudo code, and only then identify real spill registers to fit into the pseudo code. The current reload pass includes general heuristics to handle reloading memory addresses. This code knows things like "if stack pointer plus displacement is not a valid memory address, try loading the displacement into a register." Many targets currently rely on those heuristics to generate valid code. I haven't been able to quite pin down where this happens in your proposal. For example, it's easy for an address to use the frame pointer and be valid before reload, and then for reload to eliminate the frame pointer (in fact, in your scheme, what does frame pointer elimination?) and produce an offset from the stack pointer which is invalid. That is, spill code or frame pointer elimination can generate invalid address, and something needs to fix them up. Where does that happen, and how? The other main thing that bugs me about the current register allocation scheme is that there is no communication with the scheduler. The scheduler can easily increase register pressure so much that the resulting code is worse than if the scheduler had never run at all. Naturally this happens particularly on architectures with relatively few registers and relatively deep pipelines, like XScale. I don't want to argue that your scheme needs to solve every problem. But I think that any attempt to tackle the register allocator should think seriously about better integration with the scheduler. I don't see anything about that in your proposal. Ian
Re: Overwrite a file with "svn update"?
Steve Kargl <[EMAIL PROTECTED]> wrote: > Perhaps, I missed the required options, but I'll > ask an obvious question anyway. Often when testing > a patch, one will often place a new testcase in > gcc/testsuite/*. This new file is not under control > of svn. After review, the patch is committed to the > tree. Now, I want to update my local repository. > I issue "svn update" and the result is > > svn: Failed to add file 'gcc/testsuite/gfortran.dg/fgetc_1.f90': \ > object of the same name already exists > > which is indeed correct. So, is there an option to tell > svn to blow away files that conflict with files in the > repository. Why don't you just "svn add" the file? So you won't miss it in the commit, in the diffs, in the stats, and whatnot. "svn add" is a totally local operation and does not require write access to the remote repository. You can even do that on a tree checked out with svn:// and later switch the tree to svn+ssh:// to commit it. Giovanni Bajo
Re: Overwrite a file with "svn update"?
On Sat, Nov 19, 2005 at 11:29:36AM -0800, Jim Blandy wrote: > On 11/19/05, Steve Kargl <[EMAIL PROTECTED]> wrote: > > which is indeed correct. So, is there an option to tell > > svn to blow away files that conflict with files in the > > repository. > > Subversion is reluctant to blow away users' files; this was one of the > qualities of CVS we thought we should try to retain. I believe if the file is in a cvs repository and the copy in your local tree was not obtained via a checkout, cvs will replace the local file with whatever is in the repository. > However, if I'm understanding it right, here Subversion is hesitating > to replace a file with a file of the same name whose contents are the > same. Is that correct? Yes. > Has the file in your local repository been added with 'svn add'? No. > Or is it an unknown file from Subversion's point of view? Yes. The scenario is: Committer1: I have a patch with a new file that needs review. Committer2: Grabs patch and put everything in local tree to review. Committer2: Does not use "svn add" or any other svn command. Committer2: Finishes review and tells committer1 to check patch in. Committer1: Commits patch Committer2: Now wants to update his local repository. Files conflict. -- Steve
Re: Can't build 4.1 branch on Linux x86
On Saturday 19 November 2005 19:48, you wrote: > On 11/19/05, Panagiotis Papadakos <[EMAIL PROTECTED]> wrote: > > I am trying to build 4.1 branch but make profiledbootstrap stops here: > > See http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00857.html for > a patch that fixes the problem. > > Richard. Well I applied the patch but still it doesn't work.. -- Papadakos Panagiotis
Re: Register Allocation
Ian Lance Taylor writes: > The current reload pass includes general heuristics to handle > reloading memory addresses. This code knows things like "if stack > pointer plus displacement is not a valid memory address, try loading > the displacement into a register." Many targets currently rely on > those heuristics to generate valid code. I haven't been able to quite > pin down where this happens in your proposal. For example, it's easy > for an address to use the frame pointer and be valid before reload, > and then for reload to eliminate the frame pointer (in fact, in your > scheme, what does frame pointer elimination?) and produce an offset > from the stack pointer which is invalid. That is, spill code or frame > pointer elimination can generate invalid address, and something needs > to fix them up. Where does that happen, and how? The rable.pdf completely miss description of registers elimination. It's important and difficult part of RA. (The "old new-ra" also havn't eliminatin) Denis.
Re: LLVM/GCC Integration Proposal
> Specifically, advocates of the recent link-time-optimization proposal > [1] may claim that exposing all of the information that DWARF captures > (e.g. about the type system) at link-time is a good thing: it makes it > easier to do specific high-level optimizations, because all of the > information is trivially available. However, they are ignoring the > issue of handling multiple languages at the same time: an optimizer > with this design has to be aware of (and be able to update) all > possible source-language information and must be extended in the > future as new languages are added (this is the problem with universal > compilers, dating back to the UNCOL design). Also, the linker needs to > know how to combine declarations defined in different languages, > because an interprocedural optimizer only want to see one declaration > for each logical variable (for example). This quickly becomes > difficult and messy, which is presumably why the link-time proposal > allows the linker to "give up" linking two translation units. The reason for the complexity of the type system handling in our proposal was motivated primarily by two concerns: 1) We need to keep track of the types so that they are available for debugging. As LLVM does not support debuggers at this point, it may be difficult to see through all of the issues required to keep track of the information while still doing good optimization. In the end we will have to produce a set of debugging info for the optimized program, loosing all the type information before you start did not seem the correct plan. 2) GCC has a very large user community that knows nothing about compilers except how to shepherd their programs through GCC and run the result. Unless I am mistaken about the LLVM, it has no such user community. I personally cannot guarantee that GCC (or for that matter any optimizing compiler) can correctly cross inline and compile a program if the types in one module are not consistent with the types in another module. Just because the program happens to work correctly when separately compiled is not enough. When Mark and I started working on this proposal (and later the rest of the volunteers) we decided that this was not going to be either an academic exercise or just something to run benchmarks. What that means to me is that the link time optimizer needs to be able to either generate correct code or give up in some predictable manner. Having the compiler push forward and hope everything turns out OK is not enough. Discretion is the better part of valor. I think that taking advantage of mixed C, C++ or C and Fortran programs is going to be hard. But it is what the GCC customers want and there is a desire to accommodate them if possible. On the positive side, LLVM has a lot more experience in managing whole program compilation, and it is a much cleaner software base. It would be a good to find some mechanism to take advantage of that experience. Trying to make the hippo dance is not really a lot of fun. Kenny
Re: Overwrite a file with "svn update"?
On Sat, Nov 19, 2005 at 09:00:38PM +0100, Giovanni Bajo wrote: > Steve Kargl <[EMAIL PROTECTED]> wrote: > > > Perhaps, I missed the required options, but I'll > > ask an obvious question anyway. Often when testing > > a patch, one will often place a new testcase in > > gcc/testsuite/*. This new file is not under control > > of svn. After review, the patch is committed to the > > tree. Now, I want to update my local repository. > > I issue "svn update" and the result is > > > > svn: Failed to add file 'gcc/testsuite/gfortran.dg/fgetc_1.f90': \ > > object of the same name already exists > > > > which is indeed correct. So, is there an option to tell > > svn to blow away files that conflict with files in the > > repository. > > > Why don't you just "svn add" the file? So you won't miss it in the commit, in > the diffs, in the stats, and whatnot. "svn add" is a totally local operation > and does not require write access to the remote repository. You can even do > that on a tree checked out with svn:// and later switch the tree to svn+ssh:// > to commit it. This is during a review process. There is no guarantee that file will be committed. Additionally, by keeping the file out of svn, it severely reduces the probability of accidental commit. -- Steve
Re: dwarf2 unwinder hacks get my static build going: Bug, or indication of what I'm doing wrong?
On Fri, Nov 18, 2005 at 10:47:40PM -0500, Daniel Jacobowitz wrote:
> Got a handy testcase, or is it catastrophic?
It's all-pervasive.
__thread int x;
int main() { return x; }
> There are a small number
> of static tests in the linuxthreads testsuite and I've run it on HEAD
> recently.
It's entirely possible that it's been fixed, but the systems in
question are old enough that they pre-date the fix. I know, for
example, that FC2 and RHEL3 are affected, but FC4 isn't.
r~
Re: dwarf2 unwinder hacks get my static build going: Bug, or indication of what I'm doing wrong?
On Sat, Nov 19, 2005 at 01:26:47PM -0800, Richard Henderson wrote: > > There are a small number > > of static tests in the linuxthreads testsuite and I've run it on HEAD > > recently. > > It's entirely possible that it's been fixed, but the systems in > question are old enough that they pre-date the fix. I know, for > example, that FC2 and RHEL3 are affected, but FC4 isn't. Definitely works on glibc HEAD, then. -- Daniel Jacobowitz CodeSourcery, LLC
Somebody broke bootstrap on trunk for x86_64
tail -n 30 /work/built/mbuild/g148-rguenther-61/x86_64/Logfile.gcc-mainline.spec
-o 32/crtbeginT.o
../../gcc/libgcc2.c: In function '__fixunsdfdi':
../../gcc/libgcc2.c:1228: error: could not split insn
(insn:TI 17 65 66 ../../gcc/libgcc2.c:1219 (parallel [
(set (reg:DI 0 ax [66])
(ashift:DI (reg:DI 0 ax [66])
(const_int 32 [0x20])))
(clobber (reg:CC 17 flags))
]) 411 {*ashldi3_1} (insn_list:REG_DEP_ANTI 15 (insn_list:REG_DEP_TRUE
63 (insn_list:REG_DEP_TRUE 59 (nil
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
../../gcc/libgcc2.c:1228: internal compiler error: in final_scan_insn, at
final.c:2467
Please submit a full bug report,
with preprocessed source if appropriate.
See http://www.suse.de/feedback> for instructions.
make[3]: *** [libgcc/32/_fixunsdfdi.o] Error 1
Any bells ring?
Richard.
Re: LLVM/GCC Integration Proposal
Kenneth Zadeck writes: This quickly becomes difficult and messy, which is presumably why the link-time proposal allows the linker to "give up" linking two translation units. The reason for the complexity of the type system handling in our proposal was motivated primarily by two concerns: 1) We need to keep track of the types so that they are available for debugging. ... loosing all the type information before you start did not seem the correct plan. This is exactly my point. The problem here is NOT the fact that the optimization representation can't represent everything that the debug information does. The problem is that your approach conflates two completely separate pieces of information. Consider: 1. Debug information must represent the source-level program with 100% fidelity. At link time, the debug information must be merged (and perhaps optimized for size), but you do not need to merge declarations or types across language boundaries, or in non-trivial cases. 2. An optimization representation need not (and if fact does not want to) represent the program at the source-level. However, it *must* be able to link declarations and types across modules and across languages without exception (otherwise, you will miscompile the program). Designing a representation where this is not practically possible requires a back-off mechanism as your proposal has outlined. To me, the correct solution to this problem is to not try to combine the representations. Instead, allow the debug information to capture the important information that it does well (e.g. types and declarations in a language-specific way) and allow the optimization representation to capture the semantics of the program in a way that is as useful for optimization and codegen purposes as possible. This approach is the one we have always taken with LLVM (except of course that we have been missing debug info, because noone got around to implementing it), which might explain some of the confusion around "lacking high-level information". I personally cannot guarantee that GCC (or for that matter any optimizing compiler) can correctly cross inline and compile a program if the types in one module are not consistent with the types in another module. Just because the program happens to work correctly when separately compiled is not enough. This is a direct result of the representation that you are proposing to use for IPA. LLVM is *always* capable of merging two translation units correctly, no matter where they came from. We do this today. If you look back to my 2003 GCC summit paper (Sec4.4), I mention the fact that this is not a trival problem. :) When Mark and I started working on this proposal (and later the rest of the volunteers) we decided that this was not going to be either an academic exercise or just something to run benchmarks. I'm glad. While IMA is an interesting step in the right direction, it has not seen widespread adoption for this reason. I'm glad that your goal is to design something like LLVM, which always works. What that means to me is that the link time optimizer needs to be able to either generate correct code or give up in some predictable manner. Having the compiler push forward and hope everything turns out OK is not enough. Discretion is the better part of valor. I prefer to design the compiler so that neither 'giving up' nor 'hope' is required. This is an easily solvable problem, one that LLVM has had right for several years now. I think that taking advantage of mixed C, C++ or C and Fortran programs is going to be hard. I don't agree. But it is what the GCC customers want and there is a desire to accommodate them if possible. Outside benchmarks, many programs are made up of different language components. There are of course the trivial cases (such as optimizing across JNI/CNI/Java and C/C++ code), but many programs, particularly large ones, have pieces written in multiple languages. I believe Toon was recently talking about his large weather program written in Fortran and C (though I could be confusing Toon's program with another one). -Chris -- http://nondot.org/sabre/ http://llvm.org/
Re: LLVM/GCC Integration Proposal
On 11/19/05, Joseph S. Myers <[EMAIL PROTECTED]> wrote: > On Fri, 18 Nov 2005, Chris Lattner wrote: > > > 1. The build system is taught about C++ code. > > With toplevel bootstrap this will bootstrap libstdc++ so that the compiler > ends up linked with the new libstdc++ not the (in general > ABI-incompatible) old one? (This question applies to all projects > involving C++ in GCC.) In apple-local-200502-branch, if you bootstrap compiler using build_gcc (this is what we do here) then it does not build libstdc++ at all. Here at Apple, libstdc++ is built as a separate project. This has nothing to do with llvm. - Devang
Re: Register Allocation
Ian Lance Taylor wrote: > Reload inheritance is a complex idea threaded through reload. In fact, this was cleared up in the reload-branch (as documented here: http://gcc.gnu.org/wiki/BerndSchmidt), which seems that nobody has enough skill and time to get into a mergeable state. Now that we're entering Stage 1, it'd be great if somebody like you could find some time to work on it :) Giovanni Bajo
Re: Register Allocation
On Thursday 17 November 2005 17:53, Andrew MacLeod wrote: > http://people.redhat.com/dnovillo/rable.pdf How are the insn annotations and caches you propose different from what df.c already does? Gr. Steven
Re: LLVM/GCC Integration Proposal
On Saturday 19 November 2005 18:56, Chris Lattner wrote: > > Only the Ada frontend seems to be in a state to maybe support direct > > frontend IR to LLVM translation. > > Sure, also maybe Fortran? I wouldn't count on it... Gr. Steven
Re: LLVM/GCC Integration Proposal
On Sun, 20 Nov 2005, Steven Bosscher wrote: On Saturday 19 November 2005 18:56, Chris Lattner wrote: Only the Ada frontend seems to be in a state to maybe support direct frontend IR to LLVM translation. Sure, also maybe Fortran? I wouldn't count on it... Can you explain what you mean? The context above was speculating about the possibility of reducing dependency on the 'tree' data structure. My impression was that Fortran used its own private IR (gfc_expr for example) that wasn't based on trees. I thought that it converted to trees as its interface to the rest of GCC, in which case, it is quite possible for it to convert to LLVM directly instead. I'm not necessarily advocating this, but it seems possible. Of course it's also highly like that I'm confused, as I know very little about the Fortran front-end. :) -Chris -- http://nondot.org/sabre/ http://llvm.org/
Re: LLVM/GCC Integration Proposal
On Sunday 20 November 2005 01:49, Chris Lattner wrote: > On Sun, 20 Nov 2005, Steven Bosscher wrote: > > On Saturday 19 November 2005 18:56, Chris Lattner wrote: > >>> Only the Ada frontend seems to be in a state to maybe support direct > >>> frontend IR to LLVM translation. > >> > >> Sure, also maybe Fortran? > > > > I wouldn't count on it... > > Can you explain what you mean? I mean it would take a complete re-write of the translation phase from gfortran's native program representation to GENERIC trees. Even if it is "quite possible" to make it write out LLVM directly, it would be a huge job. Basically it would mean a complete rewrite of the gfortran backend, which is IMHO highly undesirable even if it is possible. I for one would not support any project to do this. Gr. Steven
Re: LLVM/GCC Integration Proposal
On Sun, 20 Nov 2005, Steven Bosscher wrote: Can you explain what you mean? I mean it would take a complete re-write of the translation phase from gfortran's native program representation to GENERIC trees. Even if it is "quite possible" to make it write out LLVM directly, it would be a huge job. Basically it would mean a complete rewrite of the gfortran backend, which is IMHO highly undesirable even if it is possible. I for one would not support any project to do this. Ok, we understand and agree with each other then. I wasn't the one proposing elimination of front-end use of trees. :) -Chris -- http://nondot.org/sabre/ http://llvm.org/
Re: LLVM/GCC Integration Proposal
On Sunday 20 November 2005 00:49, Chris Lattner wrote: > On Sun, 20 Nov 2005, Steven Bosscher wrote: > > On Saturday 19 November 2005 18:56, Chris Lattner wrote: > >>> Only the Ada frontend seems to be in a state to maybe support direct > >>> frontend IR to LLVM translation. > >> > >> Sure, also maybe Fortran? > > > > I wouldn't count on it... > > Can you explain what you mean? The context above was speculating about > the possibility of reducing dependency on the 'tree' data structure. My > impression was that Fortran used its own private IR (gfc_expr for example) > that wasn't based on trees. I thought that it converted to trees as its > interface to the rest of GCC, in which case, it is quite possible for it > to convert to LLVM directly instead. I think converting the fortran front-end would be easier than writing a GENRIC->LLVM converter, but not by much. Making the fortran frontend generate LLVM instead of trees is a fair amount of work, but IMHO doable. Making it support LLVM *and* trees would be a lot more work, and probably not worthwhile. I'm not sure I agree with the original statement. For C++ at least we already do a fair amount of conversion from "native" language trees to GENERIC/GIMPLE. Paul
Re: Somebody broke bootstrap on trunk for x86_64
>
> tail -n 30
> /work/built/mbuild/g148-rguenther-61/x86_64/Logfile.gcc-mainline.spec
> -o 32/crtbeginT.o
> ../../gcc/libgcc2.c: In function '__fixunsdfdi':
> ../../gcc/libgcc2.c:1228: error: could not split insn
> (insn:TI 17 65 66 ../../gcc/libgcc2.c:1219 (parallel [
> (set (reg:DI 0 ax [66])
> (ashift:DI (reg:DI 0 ax [66])
> (const_int 32 [0x20])))
> (clobber (reg:CC 17 flags))
> ]) 411 {*ashldi3_1} (insn_list:REG_DEP_ANTI 15
> (insn_list:REG_DEP_TRUE 63 (insn_list:REG_DEP_TRUE 59 (nil
> (expr_list:REG_UNUSED (reg:CC 17 flags)
> (nil)))
> ../../gcc/libgcc2.c:1228: internal compiler error: in final_scan_insn, at
> final.c:2467
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See http://www.suse.de/feedback> for instructions.
> make[3]: *** [libgcc/32/_fixunsdfdi.o] Error 1
And this is just recent too.
Anyways here is the reduced testcase:
long long
__fixunsdfdi (unsigned hi, unsigned lo)
{
return ((unsigned long long) hi << (32)) | lo;
}
-- Pinski
Re: Somebody broke bootstrap on trunk for x86_64
>
> >
> > tail -n 30
> > /work/built/mbuild/g148-rguenther-61/x86_64/Logfile.gcc-mainline.spec
> > -o 32/crtbeginT.o
> > ../../gcc/libgcc2.c: In function '__fixunsdfdi':
> > ../../gcc/libgcc2.c:1228: error: could not split insn
> > (insn:TI 17 65 66 ../../gcc/libgcc2.c:1219 (parallel [
> > (set (reg:DI 0 ax [66])
> > (ashift:DI (reg:DI 0 ax [66])
> > (const_int 32 [0x20])))
> > (clobber (reg:CC 17 flags))
> > ]) 411 {*ashldi3_1} (insn_list:REG_DEP_ANTI 15
> > (insn_list:REG_DEP_TRUE 63 (insn_list:REG_DEP_TRUE 59 (nil
> > (expr_list:REG_UNUSED (reg:CC 17 flags)
> > (nil)))
> > ../../gcc/libgcc2.c:1228: internal compiler error: in final_scan_insn, at
> > final.c:2467
> > Please submit a full bug report,
> > with preprocessed source if appropriate.
> > See http://www.suse.de/feedback> for instructions.
> > make[3]: *** [libgcc/32/_fixunsdfdi.o] Error 1
>
> And this is just recent too.
>
> Anyways here is the reduced testcase:
> long long
> __fixunsdfdi (unsigned hi, unsigned lo)
> {
> return ((unsigned long long) hi << (32)) | lo;
> }
flow2 is where the diference comes in:
--- old/t.c.40.flow22005-11-20 02:48:18.0 +0100
+++ new/t.c.40.flow22005-11-20 02:48:30.0 +0100
@@ -47,12 +47,12 @@
(reg:SI 1 dx [ D.1281+4 ]))# {*movsi_1} (nil)
(nil))
-(insn# # # 1 (set (reg:SI 5 di [ D.1282+4 ])
-(reg:SI 4 si [orig:60 D.1282 ] [60]))# {*movsi_1} (nil)
-(nil))
-
-(insn# # # 1 (set (reg:SI 4 si [orig:60 D.1282 ] [60])
-(const_int 0 [0x0]))# {*movsi_1} (nil)
+(insn# # # 1 (parallel [
+(set (reg:DI 4 si [orig:60 D.1282 ] [60])
+(ashift:DI (reg:DI 4 si [orig:60 D.1282 ] [60])
+(const_int 32 [0x20])))
+(clobber (reg:CC 17 flags))
+])# {*ashldi3_1} (nil)
(nil))
(insn# # # 1 (set (reg:SI 2 cx [orig:59 D.1283 ] [59])
I don't understand why it is not being split at all.
-- Pinski
Re: Somebody broke bootstrap on trunk for x86_64
> > And this is just recent too.
> >
> > Anyways here is the reduced testcase:
> > long long
> > __fixunsdfdi (unsigned hi, unsigned lo)
> > {
> > return ((unsigned long long) hi << (32)) | lo;
> > }
>
> flow2 is where the diference comes in:
> I don't understand why it is not being split at all.
Only the trunk is broken so that leaves the following patches which could have
caused it:
2005-11-19 Richard Guenther <[EMAIL PROTECTED]>
* fold-const.c (fold_indirect_ref_1): Make sure we fold
ARRAY_REFs of constant strings.
2005-11-19 Joseph S. Myers <[EMAIL PROTECTED]>
* combine.c (make_compound_operation): Swap operands of
commutative operation if necessary before returning.
2005-11-19 Richard Guenther <[EMAIL PROTECTED]>
PR middle-end/23294
* fold-const.c (fold_plusminus_mult_expr): New function.
(fold_binary): Use to canonicalize PLUS_EXPR and MINUS_EXPR
cases, remove now unnecessary code.
2005-11-19 Paolo Bonzini <[EMAIL PROTECTED]>
* gensupport.c (old_preds): Rename to std_preds, add special field.
(struct old_pred_table): Rename to struct std_pred_table, add special
field.
(NUM_KNOWN_OLD_PREDS): Rename to NUM_KNOWN_STD_PREDS.
(NUM_OLD_SPECIAL_MODE_PREDS): Remove.
(init_predicate_table): Adjust, and set along the way whether a
predicate is special.
I am thinking it is the last one but I have not gone through a hunt yet to make
sure
but I will do so soon.
-- Pinski
Re: Somebody broke bootstrap on trunk for x86_64
>
> > > And this is just recent too.
> > >
> > > Anyways here is the reduced testcase:
> > > long long
> > > __fixunsdfdi (unsigned hi, unsigned lo)
> > > {
> > > return ((unsigned long long) hi << (32)) | lo;
> > > }
> >
> > flow2 is where the diference comes in:
> > I don't understand why it is not being split at all.
>
> Only the trunk is broken so that leaves the following patches which could have
> caused it:
> 2005-11-19 Paolo Bonzini <[EMAIL PROTECTED]>
>
> * gensupport.c (old_preds): Rename to std_preds, add special field.
> (struct old_pred_table): Rename to struct std_pred_table, add special
> field.
> (NUM_KNOWN_OLD_PREDS): Rename to NUM_KNOWN_STD_PREDS.
> (NUM_OLD_SPECIAL_MODE_PREDS): Remove.
> (init_predicate_table): Adjust, and set along the way whether a
> predicate is special.
>
>
I just tested with the revert of the above patch and it worked.
Thanks,
Andrew Pinski
Working with SVK: how to get it actually work?
Hi, I'm back to home where I can actually experiment with the new switch to SVN. I installed the experimental release (1.3.0-rc2) of SVN, OpenSSH-4.2p1, SVK (0.29 coming with my GNU/Linux distribution), downloaded the entire GCC SVK tarball (which took ages to decompress with rzip), followed the scarce recipe on wiki, but failed to get SVK actually work. svk depotmap --list shows: Depot Path // /home/gdr/.svk/local /gcc/ /home/gdr/svk but the command svk checkout //gcc/trunk gcc from the wiki page refuses to make happen what is supposed to happen: % svk checkout //gcc/trunk gcc~/redhat path /gcc/trunk does not exist. What are the intermediate steps necessary to satisfy SVK? Thanks, -- Gaby
Re: GCC 4.2
There are a lot of projects on Wiki page, and I want to do something in one of them, but I do not which project I could start with? I am interested in SSA, so I want to do some projects about SSA to solidify my knowledge and apply this theory to practical applications. I browsed description of every projects on Wiki, but I am not sure how to choose one or two projects suitable for me to start. Could anybody here recommend one or two projects in gcc 4.2 about SSA for me? I would be grateful if someone could take some time out to answer these questions. Thanks in advance! -- Dueway
Re: Working with SVK: how to get it actually work?
On Sun, Nov 20, 2005 at 05:02:11AM +0100, Gabriel Dos Reis wrote: > svk depotmap --list shows: > >Depot Path > >// /home/gdr/.svk/local >/gcc/ /home/gdr/svk If you've got this... > but the command > >svk checkout //gcc/trunk gcc ... then you can't use this. Try /gcc/gcc/trunk? -- Daniel Jacobowitz CodeSourcery, LLC
