similar to: [LLVMdev] types in load/store

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

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

Hi All , Was going through the C99 standard @ http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf which states that the Function declarators as direct-declarator ( parameter-type-list ) parameter-list: parameter-declaration parameter-list , parameter-declaration parameter-declaration: declaration-specifiers declarator

On Wed, Apr 20, 2011 at 12:20 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Wed, Apr 20, 2011 at 8:08 AM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote: >> I have a question about when we should apply these pointer aliasing >> rules. Do the rules tell us when a load/store is safe? >> "Any memory access must be done through a pointer value

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

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 Wed, Apr 20, 2011 at 2:11 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Wed, Apr 20, 2011 at 10:21 AM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote: >> On Wed, Apr 20, 2011 at 12:20 PM, Eli Friedman <eli.friedman at gmail.com> wrote: >>> On Wed, Apr 20, 2011 at 8:08 AM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote: >>>> I

On Wed, Apr 20, 2011 at 10:21 AM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote: > On Wed, Apr 20, 2011 at 12:20 PM, Eli Friedman <eli.friedman at gmail.com> wrote: >> On Wed, Apr 20, 2011 at 8:08 AM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote: >>> I have a question about when we should apply these pointer aliasing >>> rules. Do the rules tell

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?

On Wed, Apr 20, 2011 at 8:08 AM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote: > I have a question about when we should apply these pointer aliasing > rules. Do the rules tell us when a load/store is safe? > "Any memory access must be done through a pointer value associated > with an address range of the memory access, otherwise the behavior is > undefined." >

I have a question about when we should apply these pointer aliasing rules. Do the rules tell us when a load/store is safe? "Any memory access must be done through a pointer value associated with an address range of the memory access, otherwise the behavior is undefined." So this means the conversion discussed here is still safe in terms of memory safety, but its meaning after conversion

On 9/14/20 9:30 AM, James Y Knight via llvm-dev wrote: > On Mon, Sep 14, 2020 at 3:19 AM László Radnai via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> A problem arises, and I am not sure if it is really a problem or just >> weird C-compliant behavior. >> >> int a; // or, equally, int a=0; >> >> int main(){ >> int b; >> if

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

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 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

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 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

On Wed, 2008-05-14 at 13:26 -0400, David Vandevoorde wrote: > On May 14, 2008, at 10:46 AM, Jonathan S. Shapiro wrote: > > On Wed, 2008-05-14 at 23:23 +0900, Neil Booth wrote: > >> Jonathan S. Shapiro wrote:- > >>> Is there a requirement somewhere in the C *Language* Specification > >>> that > >>> ties all of this together in the required