similar to: [LLVMdev] static keyword @ Function declarators...

On Aug 21, 2007, at 11:10 PM, Duncan Sands wrote: > Hi Christopher, > >> In C/C++ a restrict pointer is also assumed not to alias any other >> parameters, global values or local value. However the compiler must >> not assume that pointers "based on" a restrict pointer do not alias. > > does "based on" mean something like: copies of the pointer

Ben Allison wrote: > As mentioned before, this removes some of the 'inline' from the bitreader > and bitwriter functions that were used in another translation unit. I'm > surprised that this code works on other platform. It must be a bug in > GCC, or maybe deliberately non-standard behavior. See 6.7.4 of the C99 > spec for details. I've read section 6.7.4 from

Hi Christopher, > >> In C/C++ a restrict pointer is also assumed not to alias any other > >> parameters, global values or local value. However the compiler must > >> not assume that pointers "based on" a restrict pointer do not alias. > > > > does "based on" mean something like: copies of the pointer made in the > > function body?

Hi Jianzhou, > I misunderstood C99 ISO, such behaviors are defined not when types > have the same sizes, but when they are same (compatible) types with > signed or qualified extension (this is much stronger than being of > same sizes), or reading char by char: > > 7 An object shall have its stored value accessed only by an lvalue > expression that has one of > the

On Thu, Jul 8, 2010 at 11:09 AM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote: > Hi, > > I have a confusion about types used in load/store, > (http://llvm.org/docs/GetElementPtr.html#types) says that [...] > Furthermore, loads and stores don't have to use the same types as the > type of the underlying object. Types in this context serve only to > specify memory

On Fri, Jul 9, 2010 at 3:44 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Jianzhou, > >> I misunderstood C99 ISO, such behaviors are defined not when types >> have the same sizes, but when they are same (compatible)  types with >> signed or qualified extension (this is much stronger than being of >> same sizes), or reading char by char: >> >> 7

Hi Everyone. Im installing Samba4 and when i make the "make quicktest" y recibe the following error: (sorry about my english). = Failed tests = == samba3.posix_s3.raw.open (s3dc) == command: /home/debian/samba-master/bin/smbtorture --configfile=$SMB_CONF_PATH --maximum-runtime=$SELFTEST_MAXTIME --target=samba3 --basedir=$SELFTEST_TMPDIR

Hi, I have a confusion about types used in load/store, (http://llvm.org/docs/GetElementPtr.html#types) says that [...] Furthermore, loads and stores don't have to use the same types as the type of the underlying object. Types in this context serve only to specify memory size and alignment. Beyond that there are merely a hint to the optimizer indicating how the value will likely be used. [...]

On Aug 22, 2007, at 1:19 PM, Duncan Sands wrote: > Hi Christopher, > >>>> In C/C++ a restrict pointer is also assumed not to alias any other >>>> parameters, global values or local value. However the compiler must >>>> not assume that pointers "based on" a restrict pointer do not >>>> alias. >>> >>> does

Hello all I followed samba4 how to ( CentOS6 minimum install ) #working fro me ./configure.developer make #failed for me [root at dcmsc samba-4.0.0alpha16]# make quicktest WAF_MAKE=1 ./buildtools/bin/waf test --quick 'test' finished successfully (0.000s) Waf: Entering directory `/root/download/samba-4.0.0alpha16/bin' [ 111/3389] Generating VERSION Waf: Leaving directory

On Aug 21, 2007, at 6:12 AM, Duncan Sands wrote: > Hi Christopher, > >> The benefits of a const * __restrict come from two different places. >> The const part is essentially enforced by the front-end and the >> restrict part is used to inform the alias analysis (it becomes a >> noalias parameter attribute). The noalias parameter attribute may be >> of use to

On Mon, 26 Mar 2007, Christopher Lamb wrote: >> For representing scoping information, a relatively non-invasive >> approach is to introduce a special "copy" operation, which in LLVM >> might look like >> %a = copy %b >> This operation has to be somewhat special in that can't be folded away >> in most cases, but it can otherwise be pretty

Motivated by the recent R-devel list message with the title "Registration of native routines", I modified an R package to use registration of native routines along the lines of the example in section 5.4.2 of R-exts (development version). Among other compiler flags, I have '-Wextra' permanently set for installing packages. When installing the modified package, I got the

On 10/10/2016 14:59, Stephan Bosch wrote: > > > Op 10-10-2016 om 14:39 schreef Michael Felt: >> On 10-Oct-16 06:45, Aki Tuomi wrote: >>> Does your build end at some particular point? >> See **** DETAILS **** for in depth (I hope enough!) study/report. >>> >>> Aki >> >> I would guess this is not "c99" way... > > It seems to

Hi all, Second and hopefully final pre-release is here: http://downloads.xiph.org/releases/flac/beta/ I have personally tested this code on: x86-linux x86_64-linux powerpc-linux armhf-linux i386-freebsd9.1 i386-openbsd5.2 I also cross-compiled from Linux to 32 bit Windows and the compile ran to completion (the test suite requires a bunch of hacking before it can

I've been playing around with clang/LLVM looking at adding partial support for the draft technical report for embedded C extensions (TR18037, http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf), specifically named address spaces. Named address spaces need to be tracked in LLVM in essentially all the same places that alignment is tracked, which necessitates adding the

Hi Kevin, On April 11, 2017 at 4:14:14 PM, Flamedoge (code.kchoi at gmail.com) wrote: > So only "non-freed" malloc pointers are No-Alias which makes it > flow-sensitive. There is no reason why malloc couldn't return previously > freed location. Yes. Talking to Nick Lewycky on IRC, I figured out a shorter way of saying what I wanted to say.  We know that programs like this

On Nov 10, 2007, at 11:07 PM, Christopher Lamb wrote: > I've been playing around with clang/LLVM looking at adding partial > support for the draft technical report for embedded C extensions > (TR18037, http://www.open-std.org/jtc1/sc22/wg14/www/docs/ > n1169.pdf), specifically named address spaces. > > Named address spaces need to be tracked in LLVM in essentially all

On Tue, Mar 1, 2011 at 4:06 PM, David Neto wrote: > On Mon, Feb 28, 2011 at 4:41 PM, Peter Collingbourne wrote: >> >> The more I think about it, the more I become uncomfortable with the >> concept of language-specific address spaces in LLVM.  These are the >> main issues I see with language-specific address spaces: > > ... > >> Instead of language-specific

Hi Michele, Are you considering nested address spaces? Apart from OpenCL, named address spaces have been proposed in scope of "Embedded C" draft N1275 (2007). http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1275.pdf --> Section 5.2: Named address spaces and named-register storage classes Summarizing, address spaces may overlap in a nested fashion. Typically their names are