search for: wg14

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

...hat is worth and what is safe/unsafe is a subjective matter. So, instead of listing my opinions here, let me say this: If we build sufficient modularity into the libc, one will be able to pick and choose what they want, and omit what they do not want. > I’d love it if the C Standards Committee, WG14, got renewed involvement through this project. Is that an explicit goal? Who will join WG14 in this effort? > What part of C do you see this project help improve over time? The answer to this question also depends on how the project and the community around it evolves. > How do you intend t...

...ticular point? >> See **** DETAILS **** for in depth (I hope enough!) study/report. >>> >>> Aki >> >> I would guess this is not "c99" way... > > It seems to fail on a C99 feature called Compound Literal (see > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf, Section > 6.5.2.5). > > It should be supported by AIX: > > https://www.ibm.com/support/knowledgecenter/SSGH3R_13.1.3/com.ibm.xlcpp1313.aix.doc/language_ref/compound_literals.html > > > I have no idea why it would fail here. > > Regards, > >...

...ng at the correct section. I do not agree > > that your interpretation follows the as-if rule, because I do not > > agree > > with your interpretation of the C library specification of malloc(). > > Before I go on, let me state that this is not a contentious issue > among WG14: There is no doubt that the intent of the standard is that > this be a valid optimization. Maybe I missed something, but aren't we all talking about the wrong thing here? It seems to me that this isn't about side effects, it's about the return value of malloc. Why can LLVM assum...

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 information to the .bc format. Given the Apple has shipped .bc files I'm guessing that bac...

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

...ecution of B [the enclosing block] prior to the evaluation of E) modifying P to point to a copy of the array object into which it formerly pointed would change the value of E. Note that ‘‘based’’ is defined only for expressions with pointer types. This is from http://www.open-std.org/jtc1/sc22/wg14/www/docs/ n1124.pdf Sec 6.7.3.1 para 3 >> Your example strikes me as contradictory to your description of Ada >> aliasing rules above. If A and B were in fact copies of an object >> then in your first example x would always be 0, no matter which order >> the reads and writ...

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

...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 here: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf My reading of that section suggests that the usage in FLAC is valid and correct. As for the addition of safe_malloc_mul_2op_ to file src/share/utf8/utf8.c, that simply should not be necessary. I suggest this is an error in the Visual Studio project files. Erik -- ------------...

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 > the same places that alignment is tracked, Others addressed the other questions, one (surprising?) thing I'd recommend: Unlike alignment and vol...

...o not agree > > > that your interpretation follows the as-if rule, because I do not > > > agree > > > with your interpretation of the C library specification of malloc(). > > > > Before I go on, let me state that this is not a contentious issue > > among WG14: There is no doubt that the intent of the standard is that > > this be a valid optimization. > > Maybe I missed something, but aren't we all talking about the wrong thing > here? It seems to me that this isn't about side effects, it's about the > return value of ma...

...ock] prior to > the evaluation of E) modifying P to point to > a copy of the array object into which it formerly pointed would > change the value of E. > Note that ‘‘based’’ is defined only for expressions with pointer types. > > This is from http://www.open-std.org/jtc1/sc22/wg14/www/docs/ > n1124.pdf Sec 6.7.3.1 para 3 suppose A and B are array pointers, and are in fact equal. Consider the code sequences (i) x = A[0] (a) B[0] = 1 (b) and (ii) B[0] = 1 (b) x = A[0] (a) If I understand right, (i)(b) is not based on A, either because it has no value (not sure what &...

......] > — an aggregate or union type that includes one of the aforementioned > types among its > members (including, recursively, a member of a subaggregate or > contained union), or > — a character type. > (sec 6.5, items 6 and 7, page 67-68, > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf) LLVM does not have any such restrictions. > If LLVM IR is weaker than these C restrictions, then I have the > following questions about when GEP is undefined: In your examples, it is not GEP that would be undefined, but a load or store from the GEP. GEP just offsets th...

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 intrinsic identifiers (e.g. "_x int t;" ) predefined at the start of translation unit, but draft also men...

...the effective type of the object, [...] — an aggregate or union type that includes one of the aforementioned types among its members (including, recursively, a member of a subaggregate or contained union), or — a character type. (sec 6.5, items 6 and 7, page 67-68, http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf) If LLVM IR is weaker than these C restrictions, then I have the following questions about when GEP is undefined: 1) Can I load a value partially or overlapped with other stored values? For example, if the stored values are of type [10*i32], and we cast i32* to {i8, i4, float}...

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

...to know that I was looking at the correct section. I do not agree > that your interpretation follows the as-if rule, because I do not > agree > with your interpretation of the C library specification of malloc(). Before I go on, let me state that this is not a contentious issue among WG14: There is no doubt that the intent of the standard is that this be a valid optimization. So at most we're debating whether the wording implements the intent in this case (which it does IMO). > The standard library specification of malloc() clearly requires that > it > allocate...

...or union type that includes one of the aforementioned >> types among its >> members (including, recursively, a member of a subaggregate or >> contained union), or >> — a character type. >> (sec 6.5, items 6 and 7, page 67-68, >> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf) > > LLVM does not have any such restrictions. > >> If LLVM IR is weaker than these C restrictions, then I have the >> following questions about when GEP is undefined: > > In your examples, it is not GEP that would be undefined, but a load or > store...

...535 bytes. > Their guidance for maximum > object size is stated to be half of SIZE_MAX in C11 K.3.4/4 which is > typically equivalent to PTRDIFF_MAX. Whose guidance? Annex K is kinda alien to the rest of the standard and its future is not clear. See, e.g., http://open-std.org/jtc1/sc22/wg14/www/docs/n1969.htm . > - The expectation that PTRDIFF_MAX is more or less a proxy for the largest > object size is not uncommon. For example, C++'s std::count doesn't return > a size_t but a iterator_traits<>::difference_type which is going to be a > ptrdiff_t for thing...

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. [...]