similar to: [LLVMdev] LLVMdev Digest, Vol 76, Issue 45

On 10/25/2010 6:31 PM, Peter Lawrence wrote: >> The above logic makes sense when you're talking about non-volatile >> loads >> and stores. To me, it doesn't make sense for volatile loads and >> stores. >> >> The whole point of volatile is to tell the compiler that its >> assumptions >> about how memory works doesn't apply to this load or

> > The above logic makes sense when you're talking about non-volatile > loads > and stores. To me, it doesn't make sense for volatile loads and > stores. > > The whole point of volatile is to tell the compiler that its > assumptions > about how memory works doesn't apply to this load or store and it > should, therefore, leave it alone and not do

On 10/25/2010 7:33 PM, Dale Johannesen wrote: > On Oct 25, 2010, at 5:13 PMPDT, Kenneth Boyd wrote: >> On 10/25/2010 6:31 PM, Peter Lawrence wrote: >>> Your objection is like saying that it isn't kosher to ignore the >>> "register" keyword, because >>> "I know what I am doing and you don't.....". >> What isn't kosher, is

On Oct 25, 2010, at 5:13 PMPDT, Kenneth Boyd wrote: > On 10/25/2010 6:31 PM, Peter Lawrence wrote: >> >> Your objection is like saying that it isn't kosher to ignore the >> "register" keyword, because >> "I know what I am doing and you don't.....". > What isn't kosher, is making side effects disappear from a C program. > >

>> >> Your objection is like saying that it isn't kosher to ignore the >> "register" keyword, because >> "I know what I am doing and you don't.....". > What isn't kosher, is making side effects disappear from a C program. > > Kenneth > Ken, to have a valid complaint you have to demonstrate a program that behaves

Hi, In our (non-C) compiler we use setjmp/longjmp to implement exception handling. For the initial implementation LLVM backend, I'm keeping that model. In order to ensure that changes performed in a try/setjmp==0 block survive the longjmp, the changes must be done via volatile operations. Given that volatility is a property of individual load/store instructions rather than of memory slots in

On Mon, Sep 19, 2016 at 4:42 AM, Jonas Maebe <jonas-devlists at watlock.be> wrote: > Reid Kleckner wrote: > > On Fri, Sep 16, 2016 at 10:13 AM, Jonas Maebe via llvm-dev > > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > > > model. In order to ensure that changes performed in a try/setjmp==0 > > block survive

The parts of klibc specific to the x86_64 architecture. Signed-off-by: H. Peter Anvin <hpa at zytor.com> --- commit f889dd04bef1aed36ba18161c727af47338e167a tree c25f184d2e3337b52dfe3abd191ec639d4d9543d parent f30fa3db62972125afa68d3b53d03cdb843d3bbd author H. Peter Anvin <hpa at zytor.com> Sun, 25 Jun 2006 16:58:53 -0700 committer H. Peter Anvin <hpa at zytor.com> Sun, 25 Jun

This is a klibc port to x32 architecture. I tried to reuse as many existing files as possible, hence, a script making symlinks to x86-64 files. I was running this on Debian for about six months and hopefully, found any close to surface bugs. Of course, there are plenty left. Please help with testing. To build you need to run: make ARCH=x32 Makefile | 15 ++--

On Mon, Feb 14, 2011 at 3:49 PM, Peter Lawrence <peterl95124 at sbcglobal.net> wrote: > Andrew, >                your response highlights a naming problem in LLVM, > which is that  "array" and "vector" > mean the same thing in normal computer language and compiler theory > usage, so it is > inconvenient and misleading within LLVM to give one a very

John, I have been using the first official release llvm-2.9 tarball and a clang from very shortly after that, built for my PowerPC-Apple-Darwin, I am a bit surprised that this would have changed since then, but pleasantly surprised nevertheless. Peter Lawrence. On Jul 28, 2011, at 2:49 PM, John McCall wrote: > On Jul 28, 2011, at 2:22 PM, Peter Lawrence wrote: >>

On 11/03/2017 07:57 PM, Yichao Yu wrote: > On Fri, Nov 3, 2017 at 8:54 PM, Alexandre Isoard via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> On Fri, Nov 3, 2017 at 5:39 PM, Hal Finkel <hfinkel at anl.gov> wrote: >>> On 11/03/2017 07:20 PM, Alexandre Isoard via llvm-dev wrote: >>> >>> Hello, >>> >>> I am not sure about the

Jonas Maebe via llvm-dev wrote: > Then, I tried the following: > a) if the longjmp for the try-block is taken (i.e., the setjmp right > before the try-block returns a non-zero value), jump to the landingpad BBL. > > -> Problem: LLVM does not allow regular jump edges to landingpad BBLs > > b) since the landingpad is empty anyway and falls through into the next > BBL

Hello, Jay. > the resulting bitcode doesn't use LLVM's exception handling > intrinsics, it just has a call to a function called "_setjmp". And > there doesn't seem to be any provision for returning the current value > of the volatile variable v if setjmp returns non-zero - the bitcode > always returns zero, whereas the spec for setjmp() says that f() >

Okay. Are you saying that you shouldn't use __builtin functions in general in your program or just __builtin_setjmp/longjmp? Also, are there any warnings issued by either clang or llvm if they are used in your program? On Wed, Apr 27, 2011 at 3:55 PM, Jim Grosbach <grosbach at apple.com> wrote: > The builtins are for internal compiler use in the context of SjLj exception >

Hi everyone, Here's an update on what we've been up to and how the LLVM 1.0 release is shaping up. Overall, things are going well, and it looks highly likely that we'll get the release out by the end of the month! Here's the hilights of the last few weeks: 1. John checked in support for building LLVM into multiple different object directories in the Autoconf style. He also

Peter Lawrence <peterl95124 at sbcglobal.net> writes: > Andrew, your response highlights a naming problem in LLVM, which is > that "array" and "vector" mean the same thing in normal computer > language and compiler theory usage, so it is inconvenient and > misleading within LLVM to give one a very specific meaning that is > different from the other.... I

The builtins are for internal compiler use in the context of SjLj exception handling. Any other use, including any direct calls of the builtins in user code, are a bad idea with no guaranteed behaviour. That they're exposed at all is, again, for historical purposes. Don't use them. -Jim On Apr 27, 2011, at 3:45 PM, Akira Hatanaka wrote: > Okay. I understand builtin functions do not

The parts of klibc specific to the i386 architecture. Signed-off-by: H. Peter Anvin <hpa at zytor.com> --- commit bd0599e5290ca1a16bb7a68f7c362d395c612eb3 tree 8f33afdd02a14c22e7a3984da2bad13184e3f729 parent 84f6a72f42cf41e32daa59871a0b5424572093e4 author H. Peter Anvin <hpa at zytor.com> Sun, 25 Jun 2006 16:58:21 -0700 committer H. Peter Anvin <hpa at zytor.com> Sun, 25 Jun

Renato, On Mar 4, 2011, at 10:00 AM, llvmdev-request at cs.uiuc.edu wrote: > That's what the packed is for. > > %Base = type { i32, i8 }; // size = 8 > %POSDerived = type { %Base, i8 }; // i8 offset = 8, size 12 > > %Basep = packed type { i32, i8 }; // size = 5 > %nonPOSDerived = type { %Basep, i8 }; // i8 offset = 5, size 8 > > cheers, > --renato does't