similar to: [LLVMdev] llvm-gcc bootstrap failure

Hello, David > Anton, any luck with this? I'm wondering if it's a glitch on my end or if > it's something I should dive into deeper and attempt to debug. Bootstrap for me is broken due to different files produced at stage2 and stage3, but I didn't see such crash. In any way, I consider x86-64-bit targets to be broken, since all my 'usual' tests are currently

2008/9/21 Anton Korobeynikov <asl at math.spbu.ru>: > Hello, > >> If anybody has an idea of how to fix this (other than using another >> version of gcc because I am sick of compiling), I would appreciate. I >> can offer backtraces or shell access if anybody is interested, just >> ask me what you need. > This was fixed couple of months ago. Please consider

Hello, > If anybody has an idea of how to fix this (other than using another > version of gcc because I am sick of compiling), I would appreciate. I > can offer backtraces or shell access if anybody is interested, just > ask me what you need. This was fixed couple of months ago. Please consider using current svn top of tree, not 2.3 release. -- WBR, Anton Korobeynikov

Hello, Bill > This merge should go *much* more smoothly than the last merge -- it > could hardly be worse, right? ;-) I already did a test compile of > llvm-test with the patch and it compiled the programs without a > problem. Devang is currently testing it as well so that I have a > second opinion. One thing, which we already saw: please carefully check, that you won't

Hi, Oscar > at all, it would be great if you reflect your changes on the file list > inside the corresponding CMakeLists.txt when you add, remove or rename a > .cpp file. Isn't is possible for cmake just to glob everything in the corresponding directory? -- WBR, Anton Korobeynikov

Hi, > (2) on alpha, gcc 4.2.4. The "unknown component name: alphacodegen" > didn't use to occur. My fault, I'll fix it. The problem is that lli wants to link in JIT module, which does not exist for these targets. -- WBR, Anton Korobeynikov

Hello, Juergen > With the full patch, I get the assertion of the 'unhandled REAL_TYPE!', > so I wonder what needs to be done in order to get LLVM to produce > code for 'TREE_CODE(type) == REAL_TYPE' in the 'HandleArgument' function. > > > Does anyone have an idea? And why does this only happen on SPARC? What is the value of "Ty" in your case?

Hi, Chris > If the assembler is a limitation, the best solution would be to add a > direct PECOFF writer. There is a start of direct ELF and Macho writers > already in the tree. They are not production quality, but could be a > useful place to start looking. Well, maybe. But in any case I doubt there will be 'open' support for CV debug format :) -- WBR, Anton

Anton, I went with the first alternative with some success. However, now I get some errors during the build of libgcc with 'multiply defined symbols'. One thing I noticed is the following fact: Definition in unwind-pe.h: static const unsigned char * read_sleb128 (const unsigned char *p, _Unwind_Sword *val) --- GCC 4.2.4 bootstrapped on Solaris/SPARC -bash-3.00$ nm unwind-dw2.o | grep

Hello, Juergen > Ty->dump() prints "{double, double}" in the failing case (just before my > introduced assert). The answer is simple. The code in question contains extended IEEE FP argument / return type (aka 'long double'). By default it's lowered into struct {double, double} as you already saw and sparc currently does not provide any argument layout hooks. There

Hi Anton, thanks for the fast response. Ty->dump() prints "{double, double}" in the failing case (just before my introduced assert). HTH, and regards, Juergen On 10/30/09 16:19, Anton Korobeynikov wrote: > Hello, Juergen > >> With the full patch, I get the assertion of the 'unhandled REAL_TYPE!', >> so I wonder what needs to be done in order to get

Hello, Rafael > I am having the same problem. It was "introduced" by revision 54811, > so it looks like a memory corruption problem. Investigating. Same here. Thanks for bisection, I'll also try to look into. When I tried to investigate the problem last time, I found, that the problem disappears, when I added -fno-unit-at-a-time. The output from stage1 compiler was the same

Hello, Chuck > I've had a look at the stubs before and I think I'm circumventing them > in the example program since I populate the table and compile the > functions in the order so that things never need to be done lazily, but > I'll look further. Well, anyway stubs are definitely wrong from windows64 and this should be fixed, otherwise funny stuff can happen from time to

Hello, Kevin > build process I described in my original message. So the difference is > more subtle; maybe a difference in the layout of structs or something. Also, there can be another ABI differences. > llvmoutput.c:17976: warning: pointer targets in passing argument 1 of > 'longjmp' differ in signedness Hrm, are you using setjmp/longjmp stuff? They're definitely not

Hello, Kevin. > Well, I already use custom includes with these options: "-nostdlib > -nostdinc -Ipsptoolchain/psp/include > -Ipsptoolchain/lib/gcc/psp/4.1.0/include". But that seems not enough. > GCC has some target-specific behaviour compiled in? Well, in general - yes. However, I'm not sure up to which margin. -- WBR, Anton Korobeynikov

Hello, Oscar > Anyways, if there is no Mercurial or Bazaar mirrors available, I will > try git. Recommendations on which one to use welcomed. There is git mirror at repo.or.cz: http://repo.or.cz/w/llvm.git, llvm-gcc & clang mirrors are available there as well. I'm updating it 'by hands' currently due to some reasons, so sometimes it will need 2-3 days for changes in llvm

On Mon, Sep 29, 2008 at 12:05 PM, OvermindDL1 <overminddl1 at gmail.com> wrote: > On Mon, Sep 29, 2008 at 9:01 AM, Duncan Sands <baldrick at free.fr> wrote: >> libgcc is also available for windows. > Really? What license? What restrictions? Any speed impact over the > VC runtimes? Don't mix VC runtime and libgcc. These are totally different libraries for doing

Hello, llvm-dev. thank you for your interest in my question. Currently, I compiled simple c source code (hello.c) in lunux and windows, and I tried to simple test . first case: hello.bc (compiled with "-emit-llvm" on windows) -> lli.exe(linux). second case: hello.bc (compiled with "-emit-llvm" on linux) -> lli.exe(windows). second case return good result. but First case

Hello, Bill. > Has anyone gotten the latest/greatest sources from the LLVM-GCC open > source server lately? No. It's still at rev 319 (as of 29.04). -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.

On 5/4/07, Anton Korobeynikov <asl at math.spbu.ru> wrote: > Hello, Bill. > > > Has anyone gotten the latest/greatest sources from the LLVM-GCC open > > source server lately? > No. It's still at rev 319 (as of 29.04). > Yeesh...Okay, I'm working with Jeff C. to get a copy of the TOT out to people. I'm also pinging the rsync wonks here to see if there's