search for: tarrget

...ch a backend. > > 2.  A lot.  Just look at the instruction set of the Intermediate representation > and imagine trying to map it to a high-level language. > > Now my idea for a whacky backend:  Just a wrapper of the bitcode writer with its > own special target triple:  bitcode-tarrget-neutral and a generic data layout > that aligns to single bytes as a placeholder only.  It should disallow > overriding the alignment of individual instructions to avoid illegal settings > for the data layout.  When compiling it with LLC, it should require that the > target triple a...

On May 31, 2011, at 7:36 PM, Samuel Crow wrote: <snip> >> >> Now my idea for a whacky backend: Just a wrapper of the bitcode writer with its >> own special target triple: bitcode-tarrget-neutral and a generic data layout >> that aligns to single bytes as a placeholder only. It should disallow >> overriding the alignment of individual instructions to avoid illegal settings >> for the data layout. When compiling it with LLC, it should require that the >>...

I've been tossing around some ideas about high-level backends. Say, have LLVM emit Perl code. Sounds whacky but isn't. It's good for the first bootstrapping phase in environments where you don't have a C compiler, where you don't have a cross-compiled binary for download, but you can execute Perl. It also makes a great inspect-the-sources-with-an-editor stage for aspiring

...ring.cpp fixes the problem. The other change lib/Target/X86/X86FrameLowering.cpp was not required to fix the problem thus it is probably required for other reasons. So, should I patch both tests? Is the correct patch removing the test isTargetCOFF() completely? Or enabling it for both COFF or ELF tarrgets? I mean - is there any X86 target that does NOT require this stack checking? Yaron 2013/10/23 Andrew MacPherson <andrew.macp at gmail.com> > Hi Yaron, > > If you're outputting ELF on Windows this sounds like an issue we ran into > where __chkstk calls weren't being o...

...The other change > lib/Target/X86/X86FrameLowering.cpp was not required to fix the problem > thus it is probably required for other reasons. > > So, should I patch both tests? > Is the correct patch removing the test isTargetCOFF() completely? > Or enabling it for both COFF or ELF tarrgets? > I mean - is there any X86 target that does NOT require this stack checking? > > Yaron > > > > 2013/10/23 Andrew MacPherson <andrew.macp at gmail.com> > >> Hi Yaron, >> >> If you're outputting ELF on Windows this sounds like an issue we ran int...

...The other change > lib/Target/X86/X86FrameLowering.cpp was not required to fix the problem > thus it is probably required for other reasons. > > So, should I patch both tests? > Is the correct patch removing the test isTargetCOFF() completely? > Or enabling it for both COFF or ELF tarrgets? > I mean - is there any X86 target that does NOT require this stack checking? > > Yaron > > > > 2013/10/23 Andrew MacPherson <andrew.macp at gmail.com> > >> Hi Yaron, >> >> If you're outputting ELF on Windows this sounds like an issue we ran int...

...; lib/Target/X86/X86FrameLowering.cpp was not required to fix the problem >> thus it is probably required for other reasons. >> >> So, should I patch both tests? >> Is the correct patch removing the test isTargetCOFF() completely? >> Or enabling it for both COFF or ELF tarrgets? >> I mean - is there any X86 target that does NOT require this stack >> checking? >> >> Yaron >> >> >> >> 2013/10/23 Andrew MacPherson <andrew.macp at gmail.com> >> >>> Hi Yaron, >>> >>> If you're outputtin...

Hi Yaron, If you're outputting ELF on Windows this sounds like an issue we ran into where __chkstk calls weren't being output in the assembly due to an explicit check for COFF output. Once stack allocations in a given function exceeded some amount we'd get exactly this kind of crash in the function initialization. If you take a look for isTargetCOFF() in

Yes, this is correct code address accessing bad data address. However, there is no other relocation before .text or near it. I'll send you the full debug printout, maybe you'll note something. The problem could be result of something else entirely else than the linker such as some library initialization code that by chance worked with smaller code but fails now. I need to debug and see