Re: [PATCH v3] sockaddr.3type: POSIX Issue 8 will solve strict-aliasing issues with these types

On Fri, Apr 21, 2023 at 10:27:18PM +0200, Alejandro Colomar wrote: > Link: > Reported-by: Bastien Roucariès > Reported-by: Alejandro Colomar > Reviewed-by: Eric Blake > Cc: glibc > Cc: GCC > Cc: Stefan Puiu > Cc: Igor Sysoev > Cc: Rich Felker >

[PATCH v3] sockaddr.3type: POSIX Issue 8 will solve strict-aliasing issues with these types

b/man3type/sockaddr.3type @@ -117,6 +117,14 @@ .SH HISTORY was invented by POSIX. See also .BR accept (2). +.PP +These structures were invented before modern ISO C strict-aliasing rules. +If aliasing rules are applied strictly, +these structures would be extremely difficult to use +without invoking

Re: GCC 7, aligned_storage and “dereferencing type-punned pointer will break strict-aliasing rules”

On Tue, 2017-05-02 at 12:17 +0200, Richard Biener wrote: > But this shows > an issue with GCC 7 so please open a bugreport. Here it is - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80593 Regards, FCh

Re: GCC 7, aligned_storage and “dereferencing type-punned pointer will break strict-aliasing rules”

tatic_vector v1; > std::cout << v1[0] << '\n' << v1[1] << '\n'; > } > > -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- > > And this produces exactly the same warning: > > -- >8 --

GCC 7, aligned_storage and “dereferencing type-punned pointer will break strict-aliasing rules”

- >8 -- Compilation with latest GCC 7 RC: -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- $ g++ -Wall -O2 -c main.cpp main.cpp: In function 'int main()': main.cpp:7:34: warning: dereferencing type-punned pointer will break strict-aliasing

Re: strict aliasing: cast from char[] or char *

which I'd like to disable.  How can I do that?  Currently I'm >>>> using >>>> -Wno-strict-aliasing, but I'd like to have a better solution.  I tried to >>>> cast (void*) before the cast to (OBJECT*), it didn't help.  Is it possible &g

Re: strict aliasing: cast from char[] or char *

On Tue, Jun 7, 2011 at 4:31 PM, Jonathan Wakely wrote: > On 7 June 2011 15:20, Richard Guenther wrote: >>> >>> However, for my construct, which appears to be completely legal, I get a >>> warning, which I'd like to disable.  How can I do that?  Currently I&#x

Re: strict aliasing: cast from char[] or char *

On 7 June 2011 15:20, Richard Guenther wrote: >> >> However, for my construct, which appears to be completely legal, I get a >> warning, which I'd like to disable.  How can I do that?  Currently I'm using >> -Wno-strict-aliasing, but I'd like to have a bet

Re: strict aliasing: cast from char[] or char *

7, 2011 at 5:51 AM, Herman, Geza    wrote: >>>>> >>>>> Hi, >>>>> >>>>> Sorry, if it has been discussed before, I found a lot of information on >>>>> strict aliasing in gcc, but nothing about this particular case.  I&#x

Re: strict aliasing: cast from char[] or char *

On 7 June 2011 15:05, Herman, Geza wrote: > > However, for my construct, which appears to be completely legal, I get a > warning, which I'd like to disable.  How can I do that?  Currently I'm using > -Wno-strict-aliasing, but I'd like to have a better solution.  I tri

Re: strict aliasing: cast from char[] or char *

he warning (just for the case where char[] is casted), this case wouldn't get a warning, and would generate incorrect code: char data[...]; reinterpret_cast(data) = 1; printf("%d\n", reinterpret_cast(data)); However, for my construct, which appears to be completely legal, I get a

Re: strict aliasing: cast from char[] or char *

On 06/07/2011 12:27 PM, Richard Guenther wrote: On Tue, Jun 7, 2011 at 5:51 AM, Herman, Geza wrote: Hi, Sorry, if it has been discussed before, I found a lot of information on strict aliasing in gcc, but nothing about this particular case. I'd like to code a custom container class: it

Re: strict aliasing: cast from char[] or char *

On Tue, Jun 7, 2011 at 2:58 PM, Herman, Geza wrote: > On 06/07/2011 12:27 PM, Richard Guenther wrote: >> >> On Tue, Jun 7, 2011 at 5:51 AM, Herman, Geza  wrote: >>> >>> Hi, >>> >>> Sorry, if it has been discussed before, I found a lot of inf

Re: strict aliasing: cast from char[] or char *

On Tue, Jun 7, 2011 at 5:51 AM, Herman, Geza wrote: > Hi, > > Sorry, if it has been discussed before, I found a lot of information on > strict aliasing in gcc, but nothing about this particular case.  I'd like to > code a custom container class: it has a char[] (or dynamical

Re: strict aliasing: cast from char[] or char *

Please send questions about using GCC to gcc-h...@gcc.gnu.org, this mailing list is for discussing development of GCC, thanks. On 7 June 2011 04:51, Herman, Geza wrote: > > Here, gcc warns on the reinterpret_cast line. Which version?

strict aliasing: cast from char[] or char *

Hi, Sorry, if it has been discussed before, I found a lot of information on strict aliasing in gcc, but nothing about this particular case. I'd like to code a custom container class: it has a char[] (or dynamically allocated "char *") for storage, putting an element is done

Re: strict aliasing violation

On 25 January 2010 15:51, Piotr Wyderski: > Andrew Haley wrote: >   union { float f; uint32 i; } u = {.f = v};   return u.i; >>> >>> Nope, that is not allowed either. >> >> Of course it is allowed.  It's a legitimate gcc extension, and it's >> supported by many other compilers too. > > It

Re: strict aliasing violation

Andrew Haley wrote: >>>   union { float f; uint32 i; } u = {.f = v}; >>>   return u.i; >> >> Nope, that is not allowed either. > > Of course it is allowed.  It's a legitimate gcc extension, and it's > supported by many other compilers too. It's a C extension, according to the documentation. In C+

Re: strict aliasing violation

. I want to provide a variant for >> > float and double, which should work as follows: >> > take the floating-point value, treat its binary >> > representation as uint32_t/uint64_t and use >> > the result as a parameter for an integral hash(). >> > &

Re: strict aliasing violation

o provide a variant for float and double, which >>> should work as follows: take the floating-point value, treat its >>> binary representation as uint32_t/uint64_t and use the result as a >>> parameter for an integral hash(). >>> >>> However, GCC warns me a

Re: strict aliasing violation

as follows: > > take the floating-point value, treat its binary > > representation as uint32_t/uint64_t and use > > the result as a parameter for an integral hash(). > > > > However, GCC warns me about strict aliasing > > rules violation, which is technically corr

Re: strict aliasing violation

nt32_t/uint64_t and use > the result as a parameter for an integral hash(). > > However, GCC warns me about strict aliasing > rules violation, which is technically correct, but > in this case is intended. How do I perform this > conversion ina GCC-friendly way? Even that &g

Re: strict aliasing violation

Piotr Wyderski writes: > However, GCC warns me about strict aliasing > rules violation, which is technically correct, but > in this case is intended. How do I perform this > conversion ina GCC-friendly way? Even that > produces a warning: > > inline h

strict aliasing violation

, GCC warns me about strict aliasing rules violation, which is technically correct, but in this case is intended. How do I perform this conversion ina GCC-friendly way? Even that produces a warning: inline hash_type hash(float v) { return hash(*reinterpret_cast(reinterpret_cast(&a

Re: Fwd: Objective-C and C99 strict aliasing

to allow access to the underlying structure to allow certain efficient implementations. Also when implementing class clusters, casting is often used to access instance variables of objects that are assumed to have a certain layout due to certain dynamic predicates. I think most ObjC projects currentl

Re: Fwd: Objective-C and C99 strict aliasing

On Fri, Apr 10, 2009 at 3:41 AM, Ian Lance Taylor wrote: > John Engelhart writes: > >> The easiest, and I think safest, course of action would be to add a >> line in c_common_get_alias_set similar to the one I suggested.  That >> is, if it is a pointer to something that looks even remotely like a

Re: Fwd: Objective-C and C99 strict aliasing

John Engelhart writes: > The easiest, and I think safest, course of action would be to add a > line in c_common_get_alias_set similar to the one I suggested. That > is, if it is a pointer to something that looks even remotely like an > objective-c "object", then just assume that it can alias any

Re: Fwd: Objective-C and C99 strict aliasing

On Wed, Apr 8, 2009 at 5:42 PM, Ian Lance Taylor wrote: > John Engelhart writes: > >> Objective-C defines 'c_common_get_alias_set' as its language specific >> alias set manager.  c_common_get_alias_set() seems(?) to only >> implement C's strict aliasing rul

Re: Fwd: Objective-C and C99 strict aliasing

John Engelhart writes: > Objective-C defines 'c_common_get_alias_set' as its language specific > alias set manager.  c_common_get_alias_set() seems(?) to only > implement C's strict aliasing rules, with no provisions for > Objective-C's needs. > Can anyone

Fwd: Objective-C and C99 strict aliasing

I've long wondered how GCC deals with C99 strict aliasing rules when compiling Objective-C code.  There's no language spec for Objective-C, other than the written prose description of the language that Apple provides (which, until recently, has been virtually unmodified since it'

Re: About strict-aliasing warning

e would not know about "strict-aliasing". But when we turn on -O2 options, the behavior after apply strict-aliasing may produce incorrect code. So if there is not any warnings, the incorrect behavior after applying strict-aliasing would lead to a misconception that GCC is buggy? Also, it wo

Re: About strict-aliasing warning

Paolo Bonzini wrote: "-Wstrict-aliasing This option is only active when -fstrict-aliasing is active. It warns about code which might break the strict aliasing rules that the compiler is using for optimization. The warning does not catch all cases, but does attempt to catch the more c

Re: About strict-aliasing warning

> "-Wstrict-aliasing > This option is only active when -fstrict-aliasing is active. It > warns about code which might > break the strict aliasing rules that the compiler is using for > optimization. The warning does > not catch all cases, but does attempt to catch the

About strict-aliasing warning

t;-Wstrict-aliasing This option is only active when -fstrict-aliasing is active. It warns about code which might break the strict aliasing rules that the compiler is using for optimization. The warning does not catch all cases, but does attempt to catch the more common pitfalls. It is included in -W

Re: [strict-aliasing] incorrect warning with g++-current in STL

Дмитрий Дьяченко wrote: > Hello, g++-current ( [trunk revision 143790] ) produce incorrect > warning. Need I file bug-report? > No need, thanks, we have already middle-end/38937. If you want, you can add to it your testcase, useful in order to better test the patch linked therein on i686-linux (

[strict-aliasing] incorrect warning with g++-current in STL

Hello, g++-current ( [trunk revision 143790] ) produce incorrect warning. Need I file bug-report? # g++ -Wall -O2 -c test3.cpp test3.cpp: In function 'void bar()': test3.cpp:16: warning: dereferencing pointer '' does break strict-aliasing rules /usr/local/gcc_current/lib/g

Re: [strict-aliasing] warning message contains compiler-generated symbols

t;> 1) contains compiler generated symbols >> 2) refers to gcc internal header (stl_tree.h) >> >> [EMAIL PROTECTED] gcc_err]# g++ -Wall -c -O3 test.cpp >> test.cpp: In member function 'void >> test::bar(std::_List_iterator >&)': >> test.cpp

Re: [strict-aliasing] warning message contains compiler-generated symbols

.cpp: In member function 'void > test::bar(std::_List_iterator >&)': > test.cpp:14: warning: dereferencing pointer '__x.13' does break > strict-aliasing rules > /usr/local/gcc_current/lib/gcc/i686-pc-linux-gnu/4.4.0/include/c++/bits/stl_tree.h:530: > note: initia

[strict-aliasing] warning message contains compiler-generated symbols

cing pointer '__x.13' does break strict-aliasing rules /usr/local/gcc_current/lib/gcc/i686-pc-linux-gnu/4.4.0/include/c++/bits/stl_tree.h:530: note: initialized from here test.cpp:14: warning: dereferencing pointer '__x.13' does break strict-aliasing rules /usr/local/gcc_current/li

Re: No warning of violating strict aliasing rule and produce wrong code

Bingfeng Mei wrote: > Sorry, I made a mistake. My local copy of mainline version (still 4.3.0 > 20080213) doesn't gave warning. I just updated my mainline GCC and it > does give warning now. I think that you'll find the release 4.3 version does too. While we try to ensure that gcc warns whenever

RE: No warning of violating strict aliasing rule and produce wrong code

: gcc@gcc.gnu.org Subject: Re: No warning of violating strict aliasing rule and produce wrong code Bingfeng Mei wrote: > Hello, > > In following code, gcc (mainline version as well as previous versions) > produces wrong code without giving any warning regarding strict aliasing > violatio

Re: No warning of violating strict aliasing rule and produce wrong code

Bingfeng Mei wrote: > Hello, > > In following code, gcc (mainline version as well as previous versions) > produces wrong code without giving any warning regarding strict aliasing > violation. > > ~/work/trunk-x86/bin/gcc tst.c -O3 -o tst -Wstrict-aliasing=2 > ./tst >

No warning of violating strict aliasing rule and produce wrong code

Hello, In following code, gcc (mainline version as well as previous versions) produces wrong code without giving any warning regarding strict aliasing violation. ~/work/trunk-x86/bin/gcc tst.c -O3 -o tst -Wstrict-aliasing=2 ./tst barrier1 Miscompilation If I compile with ~/work/trunk-x86/bin

Re: strict aliasing

On Wed, Nov 07, 2007 at 05:22:01AM +1100, skaller wrote: > > One way to do this in C++ is to derive the different representations that > > might appear in your "union" from a common base class, and use placement > > new to lay them out. > > I don't understand. You cannot put ANY constructable typ

Re: strict aliasing

what gcc does with -fno-strict-aliasing: I think that is itself on-topic: I don't see any other place I could find out (other than reading all the code myself, which is a rather daunting task :) Anyhow I'm satisfied with the answers, thanks again everyone who commented. Just for context

Re: strict aliasing

On Tue, 2007-11-06 at 09:32 -0800, Joe Buck wrote: > On Wed, Nov 07, 2007 at 04:06:11AM +1100, skaller wrote: > > On Tue, 2007-11-06 at 07:49 -0800, Joe Buck wrote: > > > Now it appears that you want to make some kind of intermediate assumption > > > (semi-strict al

Re: strict aliasing

Joe Buck writes: > On Wed, Nov 07, 2007 at 04:06:11AM +1100, skaller wrote: > > I understand I ask for something gcc may not be doing, I'm not > > asking for a change, just to understand what it actually does. > > You are misusing C++, I'm afraid, and there are no promises that > some day a

Re: strict aliasing

On Wed, Nov 07, 2007 at 04:06:11AM +1100, skaller wrote: > On Tue, 2007-11-06 at 07:49 -0800, Joe Buck wrote: > > Now it appears that you want to make some kind of intermediate assumption > > (semi-strict aliasing?), where pointers of different types are allowed to > > alias w

Re: strict aliasing

}; > double d = *(double*)f; > This is not valid C/C++ code. What you mean is that it is not strictly conforming C code. [You cannot say that for C++, there is no notion of strictly conforming C++ code] > But since there is quite a lot of it > out there, the -fno-strict-aliasing

Re: strict aliasing

On Tue, 2007-11-06 at 07:49 -0800, Joe Buck wrote: > On Wed, Nov 07, 2007 at 02:30:44AM +1100, skaller wrote: > Now it appears that you want to make some kind of intermediate assumption > (semi-strict aliasing?), where pointers of different types are allowed to > alias while ints

Re: strict aliasing

Joe Buck <[EMAIL PROTECTED]> writes: > On Wed, Nov 07, 2007 at 02:30:44AM +1100, skaller wrote: > > > The claim was, in the context of the example given, "Without strict > > > aliasing being enabled, the compiler can't assume that that the assign

Re: strict aliasing

On Tue, Nov 06, 2007 at 12:15:17AM -0800, Ian Lance Taylor wrote: > The assignment is indeed of an int, but it uses a pointer. Strict > aliasing only refers to loads and stores which use pointers. The > type-based alias analysis is done on the types to which those pointers > point

Re: strict aliasing

On Wed, Nov 07, 2007 at 02:30:44AM +1100, skaller wrote: > > The claim was, in the context of the example given, "Without strict > > aliasing being enabled, the compiler can't assume that that the assignment > > 'p[i] = 1' won't change 'p'&qu

Re: strict aliasing

that, I'm trying to discover what > -fno-strict-aliasing actually does. > > You hinted that it weakens the rules, without entirely > disabling type based optimisations. I have no idea what I hinted. What -fno-strict-aliasing does is turn off type-based alias analysis. The d

Re: strict aliasing

nt. > > The claim was, in the context of the example given, "Without strict > aliasing being enabled, the compiler can't assume that that the assignment > 'p[i] = 1' won't change 'p'". In this case I think it can. More precisely, IF the assignment

Re: strict aliasing

On Tue, 2007-11-06 at 06:29 -0800, Ian Lance Taylor wrote: > skaller <[EMAIL PROTECTED]> writes: > I recommend that you just read the standard and see the real aliasing > rules. I don't care about that, I'm trying to discover what -fno-strict-aliasing actually does. Y

Re: strict aliasing

skaller writes: > Yes but I still don't understand. The claim was that the assignment > might modify p. This is is contra-indicated since p is a pointer > to an int, whereas the value being assigned is an int. The claim was, in the context of the example given, "Without st

Re: strict aliasing

*p; > > > > unsigned i; > > > > allocate(&p, len); > > > > for (i = 0; i < len; i++) > > > > p[i] = 1; > > > > return p; > > > > } > >

Re: strict aliasing

i++) > > > p[i] = 1; > > > return p; > > > } > The assignment is indeed of an int, but it uses a pointer. Strict > aliasing only refers to loads and stores which use pointers. The > type-based alias analysis is done on the types to wh

Re: strict aliasing

int *foo(unsigned len) { > > int *p; > > unsigned i; > > allocate(&p, len); > > for (i = 0; i < len; i++) > > p[i] = 1; > > return p; > > } > > > > W

Re: strict aliasing

On Mon, 2007-11-05 at 14:30 -0500, Ross Ridge wrote: > Ian Lance Taylor wrote: > > Strict aliasing only refers to loads and stores using pointers. > > skaller writes: > > Ah, I see. So turning it off isn't really all that bad > > for optimisation. > >

Re: strict aliasing

On Tue, Nov 06, 2007 at 05:44:44AM +1100, skaller wrote: > > On Mon, 2007-11-05 at 10:20 -0800, Joe Buck wrote: > > On Mon, Nov 05, 2007 at 10:15:55AM -0800, Ian Lance Taylor wrote: > > > skaller <[EMAIL PROTECTED]> writes: > > > > Ah, I see. So turning [str

Re: strict aliasing

Ian Lance Taylor wrote: > Strict aliasing only refers to loads and stores using pointers. skaller writes: > Ah, I see. So turning it off isn't really all that bad > for optimisation. One example of where it hurts on just about any platform is something like this: void al

Re: strict aliasing

On Mon, 2007-11-05 at 10:20 -0800, Joe Buck wrote: > On Mon, Nov 05, 2007 at 10:15:55AM -0800, Ian Lance Taylor wrote: > > skaller <[EMAIL PROTECTED]> writes: > > > Ah, I see. So turning [strict aliasing] off isn't really all that bad > > > for optimisation

Re: strict aliasing

hat optimisations might be enabled/disabled > > > > by strict aliasing rules? > > > > > Strict aliasing only refers to loads and stores using pointers. > > > > Ah, I see. So turning it off isn't really all that bad > > for optimisation. > >

Re: strict aliasing

On Mon, Nov 05, 2007 at 10:15:55AM -0800, Ian Lance Taylor wrote: > skaller <[EMAIL PROTECTED]> writes: > > Ah, I see. So turning [strict aliasing] off isn't really all that bad > > for optimisation. > > It depends on the processor. For an in-order processor with

Re: strict aliasing

skaller <[EMAIL PROTECTED]> writes: > On Mon, 2007-11-05 at 09:56 -0800, Ian Lance Taylor wrote: > > skaller <[EMAIL PROTECTED]> writes: > > > > > Can someone tell me what optimisations might be enabled/disabled > > > by strict aliasing rules? &g

Re: strict aliasing

On Mon, 2007-11-05 at 09:56 -0800, Ian Lance Taylor wrote: > skaller <[EMAIL PROTECTED]> writes: > > > Can someone tell me what optimisations might be enabled/disabled > > by strict aliasing rules? > Strict aliasing only refers to loads and stores using pointers. A

Re: strict aliasing

skaller <[EMAIL PROTECTED]> writes: > Can someone tell me what optimisations might be enabled/disabled > by strict aliasing rules? With no aliasing information at all, the compiler can not reorder load and store instructions, because they might refer to the same memory locations.

strict aliasing

Can someone tell me what optimisations might be enabled/disabled by strict aliasing rules? Is there some merit in a switch which allows coarse aliasing optimisations, that is, allows optimisations based on integer vs float vs pointer, but not on pointer vs pointer? I have some code which makes

Re: const and strict aliasing rules

Andrew Pinski <[EMAIL PROTECTED]> writes: | > | > Andrew Pinski <[EMAIL PROTECTED]> writes: | > | > | > You can work around this by using union's of pointers of both non-const | > | > and const types, but the reinterpret_cast solution would be more attractive. | > | > | > | > Thoughts? | > |

Re: const and strict aliasing rules

> > Andrew Pinski <[EMAIL PROTECTED]> writes: > > | > You can work around this by using union's of pointers of both non-const > | > and const types, but the reinterpret_cast solution would be more > attractive. > | > > | > Thoughts? > | > | This has nothing to do with const vs non-const but r

Re: const and strict aliasing rules

Andrew Pinski <[EMAIL PROTECTED]> writes: | > You can work around this by using union's of pointers of both non-const | > and const types, but the reinterpret_cast solution would be more attractive. | > | > Thoughts? | | This has nothing to do with const vs non-const but rather | a and a are tw

Re: const and strict aliasing rules

> You can work around this by using union's of pointers of both non-const > and const types, but the reinterpret_cast solution would be more attractive. > > Thoughts? This has nothing to do with const vs non-const but rather a and a are two seperate types which are not related in any way. The C+

const and strict aliasing rules

cause the managing class needs to create and delete the foo objects. data member: PtrList listOfFoo; publishing member functions: const PtrList &GetFooList () const { return reinterpret_cast&>(listOfFoo); } This results in the warning: "type punning to incomplete type might

Re: strict aliasing warning

g, so this more aggressive optimization can then be > > performed selectively on individual functions even with > > -fno-strict-aliasing on the command line. I fear a little though that > > the functions which are provably free of cross-type aliasing might > > also not benefi

Re: strict aliasing warning

optimization can then be > > performed selectively on individual functions even with > > -fno-strict-aliasing on the command line. I fear a little though that > > the functions which are provably free of cross-type aliasing might > > also not benefit much from -f

Re: strict aliasing warning

#x27;s not allowed because of cross-type aliasing, which you said you proved there is none of. There have been concerns expressed in the past that if gcc checks for strict aliasing violations, users will be upset when it misses some violations but does optimization that breaks an ill-formed program. I per

Re: strict aliasing warning

en strict-aliasing is enabled. We are having discussions on how to effectively perform an audit on RTEMS for other breakages. Right now, the best idea is Ralf's to diff the assembly generated for each file compiled with and without strict-aliasing. If there is a difference, we will have to r

Re: strict aliasing warning

t occurred to me that part of this code could be used as a preconditioner to aggressive optimization that would normally require -fstrict-aliasing, so this more aggressive optimization can then be performed selectively on individual functions even with -fno-strict-aliasing on the command line.

Re: strict aliasing warning

d selectively on individual functions even with > -fno-strict-aliasing on the command line. I fear a little though that > the functions which are provably free of cross-type aliasing might also > not benefit much from -fstrict-aliasing, but I have very little > experience with C com

strict aliasing warning

at part of this code could be used as a preconditioner to aggressive optimization that would normally require -fstrict-aliasing, so this more aggressive optimization can then be performed selectively on individual functions even with -fno-strict-aliasing on the command line. I fear a little t

Re: strict aliasing benefit examples

I guess I can imagine that macro expansion might result in some cases where strict-aliasing is of benefit. Most people fail to use a temporary in a macro, probably because __typeof__ is gcc-only. I can probably fit 20 lines of code on a readable slide. Ideas? In C++, this: f (vector &

Re: strict aliasing benefit examples

Richard Kenner wrote: Since humans have to do a bit of alias analysis when maintaining or writing code, the extra clarity of pulling things into temporary variables isn't wasted. Sorry, I don't follow. Why should we want to do "a bit of alias analysis" when maintaining or writing code? It wou

Re: strict aliasing benefit examples

> Since humans have to do a bit of alias analysis when maintaining > or writing code, the extra clarity of pulling things into temporary > variables isn't wasted. Sorry, I don't follow. Why should we want to do "a bit of alias analysis" when maintaining or writing code? It would seem a far bette

Re: strict aliasing benefit examples

argument to favor K+R style over GNU, Allman, and Whitesmith. This could be holding back gcc development. :-) Since humans have to do a bit of alias analysis when maintaining or writing code, the extra clarity of pulling things into temporary variables isn't wasted. I guess I can imagine th

Re: strict aliasing benefit examples

> > > I think there are 3 aliasing possibilities here: > > > 1. known to alias > > > 2. known to not alias > > > 3. may alias > > > > Actually there is only 2, it may alias or not. > > Actually, he's right (and both you and Richard are wrong). > > The standard taxonomy of classifications for two

Re: strict aliasing benefit examples

Paolo Bonzini wrote: for(i = 0;i<*t;i++) *f += 1.0; This one is pretty realistic, especially if you consider C++ and inlining: Don't you think that a convincing argument here has to be based on actual timings with and without strict aliasing. It would be interesting to see cases wh

Re: strict aliasing benefit examples

for(i = 0;i<*t;i++) *f += 1.0; This one is pretty realistic, especially if you consider C++ and inlining: struct s { int size; float *data; }; void f(struct s *d, struct s *s) { int i; for (i = 0; i < s->size; i++)

Re: strict aliasing benefit examples

int f(int *a, float *b) { *a = 1; *b = 2.0; return *a == 2; } Problem: people don't write code that way. (well I hope not) People declare a few local variables, load them with data via the pointers, do stuff with the local variables, then save back the results via the pointers. So that

Re: strict aliasing benefit examples

> I think there are 3 aliasing possibilities here: > 1. known to alias > 2. known to not alias > 3. may alias Actually there is only 2, it may alias or not. Actually, he's right (and both you and Richard are wrong). The standard taxonomy of classifications for two memory accesses is: Must-ali

Re: strict aliasing benefit examples

> base+offset really only helps in cases like: > > int t[100]; > int t2[100]; > t[20] =1; > t2[30] = 2; > if (t[20] != 1) > abort (); In the more general case, base plus offset helps in the Fortran style where everything is done with arrays (Ada is like this too in typical usage). So if you ha

Re: strict aliasing benefit examples

without needing an extra pointer. That is questionable and I always forget what the C standard says here because this case involves pointer arthemantic which makes the code harder to understand. > > > Realistic code matters. Contrived examples won't > > > convince anyone.

Re: strict aliasing benefit examples

l casts. > Then you follow that with type-based analysis and finally back to > base+offset to find a few remaining known-to-not-alias cases. Not sure what the purpose of redoing the first phase again would be, but basically what you state is an oversimplification of what's done. > Th

Re: strict aliasing benefit examples

> Realistic code matters. Contrived examples won't > convince anyone. Realistic code for aliasing questions are usually going to be big and hard to understand. Bummer. I'm trying to resist the normal fix, which is to consider strict-aliasing as a benchmark cheat that you have to dis

Re: strict aliasing benefit examples

> The best examples would involve optimizations which > could not be performed if gcc did what people normally > expect from a simple pointer cast and wrong-type access. > I doubt such examples exist, but I hope they do. Simple examples exist and I see that later in this thread you were sent one o

Re: strict aliasing benefit examples

> I often need to convince people that gcc is not just > defective for doing random nonsense to code which > violates the C and C++ aliasing rules. Not that I'm > real sure myself actually, given that gcc is able to > generate warnings for all the normal cases, but anyway... > I'm up against the id

strict aliasing benefit examples

I often need to convince people that gcc is not just defective for doing random nonsense to code which violates the C and C++ aliasing rules. Not that I'm real sure myself actually, given that gcc is able to generate warnings for all the normal cases, but anyway... I'm up against the idea that Vis

Re: strict aliasing question

> On Fri, 2006-11-10 at 21:00 -0800, Alexey Starovoytov wrote: > > while speaking about uninitialized variables gcc developers probably want > > to look at their own sources first: > > gcc/testsuite/gcc.dg/vect/vect-27.c > > If any code in the testsuite is broken, it should be changed. should be f

Re: strict aliasing question

On Nov 11, 2006, at 7:56 PM, Howard Chu wrote: You probably can't, in the case of a shared library, but you probably could for a static library. I think I agree, though, a JIT can peer past a shared boundary as well. A non-JIT can as well, but it has to have some mechanism to unpeer acros

  1   2   >