similar to: [LLVMdev] Load from abs address generated bad code on LLVM 2.4

Andrew Haley <aph at redhat.com> writes: > Óscar Fuentes wrote: >> The following message is a courtesy copy of an article >> that has been posted to gmane.comp.compilers.llvm.devel as well. >> >> Andrew Haley <aph at redhat.com> writes: >> >>> This is x86_64. I have a problem where an absolute memory load >>> >>> define

Óscar Fuentes wrote: > Andrew Haley <aph at redhat.com> writes: > >> Óscar Fuentes wrote: >>> The following message is a courtesy copy of an article >>> that has been posted to gmane.comp.compilers.llvm.devel as well. >>> >>> Andrew Haley <aph at redhat.com> writes: >>> >>>> This is x86_64. I have a problem where an

Chris Lattner wrote: > On Jan 21, 2009, at 4:15 AM, Andrew Haley wrote: >>> That should work fine, just use "jit" instead of "x86-emitter" as the >>> debug type. >> That's impossible: CurrentDebugType is now private; it appears >> nowhere in the installed headers. I can't find any public interface >> to allow a JIT to set it. >

2009/6/30 Andrew Haley <aph at redhat.com> > Nick Lewycky wrote: > > I'm seeing this new build failure, starting some time yesterday on ARM: > > > > make[3]: Entering directory `/home/nlewycky/llvm/tools/llvmc/driver' > > llvm[3]: Linking Debug executable llvmc > > g++ -DLLVMC_BUILTIN_PLUGIN_1=Base -DLLVMC_BUILTIN_PLUGIN_2=Clang >

Nick Lewycky wrote: > 2009/6/30 Andrew Haley <aph at redhat.com <mailto:aph at redhat.com>> > > Nick Lewycky wrote: > > I'm seeing this new build failure, starting some time yesterday on > ARM: > > Yes. It's just a matter of defining __sync_val_compare_and_swap_4: > >

Andrew Haley wrote: > Nick Lewycky wrote: >> 2009/6/30 Andrew Haley <aph at redhat.com <mailto:aph at redhat.com>> >> >> Nick Lewycky wrote: >> > I'm seeing this new build failure, starting some time yesterday on >> ARM: >> >> Yes. It's just a matter of defining __sync_val_compare_and_swap_4: >> >>

On 08/12/2018 02:19 PM, Kim Gräsman wrote: > I still feel a little uncomfortable, because I think Jonathan makes an > excellent point -- if GCC thinks there's a strict-aliasing violation > (whether the standard agrees or not) and classifies this as undefined > behavior, we might invoke the optimizers wrath. The warning is a nice > hint that this could happen. Indeed. And

Here's my problem, which I raised on IRC: JIT::getPointerToFunction gets the address of the start of a function. But how do I find out where the end of the function is? I need this to register the function for profiling. varth said: aph, you need to intercept the "endFunctionBody" call on the memory manager, it will tell you the start pointer and the end pointer But how can I do

json::Value in JSON.h is a discriminated union. The storage is a char array of appropriate type and alignment. The storage holds one object at a time, it's initialized (and for nontrivial types, destroyed) at the right times to ensure this. The cast is only to the type of object that's already there, there's no magic here. On Fri, Aug 10, 2018, 17:52 Andrew Haley <aph at

I did some more extensive testing and found that all GCCs older than 7 trigger the warning, but only if CMAKE_BUILD_TYPE=Release (which I guess indicates optimizations are enabled). There's a patch up for disabling the warning here: https://reviews.llvm.org/D50607. I still feel a little uncomfortable, because I think Jonathan makes an excellent point -- if GCC thinks there's a

llvm/lib/System/Atomic.cpp contains the call to __sync_val_compare_and_swap that lowers to the missing __sync_val_compare_and_swap_4 GCC intrinsic. The same file contains several other __sync_* calls and all these has to be implemented if we want to be able to compile llvm on linux/ARM with GCC versions below < 4.4 xerxes at labbserver:~/llvm$ grep _sync lib/*/* lib/System/Atomic.cpp:

Hi Andrew, Andrew Haley wrote: > Here's my problem, which I raised on IRC: > > JIT::getPointerToFunction gets the address of the start of a function. > But how do I find out where the end of the function is? I need this > to register the function for profiling. > > varth said: aph, you need to intercept the "endFunctionBody" call on > the memory manager, it

Chris Lattner wrote: > On Jan 19, 2009, at 7:55 AM, Andrew Haley wrote: > >> This is x86_64. I have a problem where an absolute memory load >> The current LLVM trunk does not have this bug. This seems quite a >> nasty >> bug; is there any chance of a bug-fix release for LLVM 2.4, or >> should I >> just use LLVM trunk until LLVM 2.5 ? > > As

On Jan 20, 2009, at 2:10 AM, Andrew Haley wrote: > Chris Lattner wrote: >> On Jan 19, 2009, at 7:55 AM, Andrew Haley wrote: >> >>> This is x86_64. I have a problem where an absolute memory load >>> The current LLVM trunk does not have this bug. This seems quite a >>> nasty >>> bug; is there any chance of a bug-fix release for LLVM 2.4, or

Chris Lattner wrote: > On Jan 20, 2009, at 2:10 AM, Andrew Haley wrote: > >> Chris Lattner wrote: >>> On Jan 19, 2009, at 7:55 AM, Andrew Haley wrote: >>> >>>> This is x86_64. I have a problem where an absolute memory load >>>> The current LLVM trunk does not have this bug. This seems quite a >>>> nasty >>>> bug; is

On Tue, 14 Aug 2018 at 11:56, Kim Gräsman <kim.grasman at gmail.com> wrote: > > On Tue, Aug 14, 2018 at 11:51 AM Andrew Haley <aph at redhat.com> wrote: > > > > On 08/12/2018 02:19 PM, Kim Gräsman wrote: > > > I still feel a little uncomfortable, because I think Jonathan makes an > > > excellent point -- if GCC thinks there's a strict-aliasing

Folks, Is anyone else the failure below? On Mac OS X everything builds properly... Thanks for any help, snaroff -------------- next part -------------- A non-text attachment was scrubbed... Name: Picture 27.png Type: image/png Size: 18959 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20081217/e7d37fee/attachment.png>

Mark Shannon wrote: > Andrew Haley wrote: >> Let's go back a bit. Your claim is that there is no need to unwind >> frame-by-frame, an unwind simply needs to make a single jump to an >> invoke instruction and restore the context (which in x86 is just 6 >> registers). (This is, more or less, what longjmp() does.) Duncan Sands >> explained to you why that

On Jan 21, 2009, at 4:15 AM, Andrew Haley wrote: >> That should work fine, just use "jit" instead of "x86-emitter" as the >> debug type. > > That's impossible: CurrentDebugType is now private; it appears > nowhere in the installed headers. I can't find any public interface > to allow a JIT to set it. Ah ok. I'd suggest doing what llvm-gcc

在 2018-08-10 06:20, Kim Gräsman 写道: > On Fri, Aug 10, 2018 at 12:02 AM, Jonathan Wakely <jwakely.gcc at gmail.com> > wrote: >> >> If GCC 4.9.3 thinks there's an aliasing violation it might >> misoptimise. It doesn't matter if it's right or not, it matters if it >> treats the code as undefined or not. >> >> And apparently GCC does think