On 7 June 2011 15:39, Richard Guenther wrote:
> 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?
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'm using
>>> -Wno-strict-aliasing, but I'd
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 better solution. I tried to
>> cast (void*) b
On Tue, Jun 7, 2011 at 4:05 PM, Herman, Geza wrote:
> On 06/07/2011 03:02 PM, Richard Guenther wrote:
>>
>> 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,
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 tried to
> cast (void*) before the
On 06/07/2011 03:02 PM, Richard Guenther wrote:
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, Gezawrote:
Hi,
Sorry, if it has been discussed before, I found a lot of information on
strict alia
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 has a c
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 information on
>>> strict aliasing in gcc, but nothing about
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 dynamically allocated
> "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?
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
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+
On Mon, Jan 25, 2010 at 3:42 PM, Erik Trulsson wrote:
> On Mon, Jan 25, 2010 at 02:19:04PM +0100, Richard Guenther wrote:
>> On Mon, Jan 25, 2010 at 1:24 PM, Piotr Wyderski
>> wrote:
>> > I have a hash function hash(T v) overloaded for
>> > all integral types. I want to provide a variant for
>> >
On 01/25/2010 02:42 PM, Erik Trulsson wrote:
> On Mon, Jan 25, 2010 at 02:19:04PM +0100, Richard Guenther wrote:
>> On Mon, Jan 25, 2010 at 1:24 PM, Piotr Wyderski
>> wrote:
>>> I have a hash function hash(T v) overloaded for all integral
>>> types. I want to provide a variant for float and doubl
On Mon, Jan 25, 2010 at 02:19:04PM +0100, Richard Guenther wrote:
> On Mon, Jan 25, 2010 at 1:24 PM, Piotr Wyderski
> wrote:
> > I have a hash function hash(T v) overloaded for
> > all integral types. I want to provide a variant for
> > float and double, which should work as follows:
> > take the
On Mon, Jan 25, 2010 at 1:24 PM, Piotr Wyderski
wrote:
> I have a hash function hash(T v) overloaded for
> all integral types. 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 a
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 hash_type hash(float v) {
>
> retur
Дмитрий Дьяченко 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 (
done PR #38477.
I only was trying accuratly report. The message was readable but looks unusual.
Dmitry
2008/12/10 Richard Guenther <[EMAIL PROTECTED]>:
> On Wed, Dec 10, 2008 at 5:44 PM, Дмитрий Дьяченко <[EMAIL PROTECTED]> wrote:
>> g++-current generates messages which
>> 1) contains compiler g
On Wed, Dec 10, 2008 at 5:44 PM, Дмитрий Дьяченко <[EMAIL PROTECTED]> wrote:
> g++-current generates messages which
> 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
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
On Tue, 2007-11-06 at 17:39 +, Andrew Haley wrote:
> Joe Buck writes:
> I agree. This is way off-topic for [EMAIL PROTECTED] We have been
> very patient already, and it is time for it to end.
Thanks for your patience, I'm not meaning to go off topic,
just to discover exactly what gcc does
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 aliasing?), where pointers of diff
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
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 while ints can't alias
On Tue, 2007-11-06 at 07:58 -0800, Ian Lance Taylor wrote:
> Joe Buck <[EMAIL PROTECTED]> writes:
> In particular people really do write code like
> int addr = 0x12345678;
> char* p = (char*)&addr;
> *p = 1;
> and
> int f[2] = { 0x8000, 0 };
> double d = *(double*)f;
> Thi
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 can't alias with
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 assignment
> > > 'p[i] = 1' won't change 'p'".
> >
> > I
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.
Minor nit: he
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'".
>
> In this case I think it can. More precisely, IF the
skaller <[EMAIL PROTECTED]> writes:
> 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-a
On Tue, 2007-11-06 at 09:37 -0500, Ross Ridge wrote:
> 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
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.
You hinted that it weakens t
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 strict
aliasing being enab
skaller <[EMAIL PROTECTED]> writes:
> On Tue, 2007-11-06 at 00:15 -0800, Ian Lance Taylor wrote:
> > skaller <[EMAIL PROTECTED]> writes:
> >
> > > On Mon, 2007-11-05 at 14:30 -0500, Ross Ridge wrote:
> > >
> > > > One example of where it hurts on just about any platform is something
> > > > like
On Tue, 2007-11-06 at 00:15 -0800, Ian Lance Taylor wrote:
> skaller <[EMAIL PROTECTED]> writes:
>
> > On Mon, 2007-11-05 at 14:30 -0500, Ross Ridge wrote:
> >
> > > One example of where it hurts on just about any platform is something
> > > like this:
> > >
> > > void allocate(int **p, unsig
skaller <[EMAIL PROTECTED]> writes:
> On Mon, 2007-11-05 at 14:30 -0500, Ross Ridge wrote:
>
> > One example of where it hurts on just about any platform is something
> > like this:
> >
> > void allocate(int **p, unsigned len);
> >
> > int *foo(unsigned len) {
> > int *p;
>
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.
>
> One example of where it hurts on just abou
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 [strict aliasing] off isn't really all that
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 allocate(int **p,
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.
> >
> > It depends on the processor.
On Mon, 2007-11-05 at 10:15 -0800, Ian Lance Taylor wrote:
> 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 st
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 a deep
> pipeline (e.g., Itanium,
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?
>
> > Strict aliasing only refers to loads and store
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.
Ah, I see. So turning it off
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. The compiler do
Andrew Haley wrote:
Joel Sherrill writes:
> Silvius Rus wrote:
> >
> > I wrote some code (not released yet) that improves the accuracy of
> > -Wstrict-aliasing using tree-ssa-alias information. The primary idea
> > was to tell the programmer "go fix the types of variables x and y at
> >
Joel Sherrill writes:
> Silvius Rus wrote:
> >
> > I wrote some code (not released yet) that improves the accuracy of
> > -Wstrict-aliasing using tree-ssa-alias information. The primary idea
> > was to tell the programmer "go fix the types of variables x and y at
> > lines ..." when -fstr
Joe Buck wrote:
If you first prove that there is no cross-type aliasing, then turn on
-fstrict-aliasing, it seems to me that your alias sets won't change at
all. The reason is that if there is a change, it means that you
eliminated an aliasing possibility based on the fact that it's not
allowe
Joel Sherrill wrote:
Silvius Rus wrote:
I wrote some code (not released yet) that improves the accuracy of
-Wstrict-aliasing using tree-ssa-alias information. The primary idea
was to tell the programmer "go fix the types of variables x and y at
lines ..." when -fstrict-aliasing breaks thei
Silvius Rus wrote:
I wrote some code (not released yet) that improves the accuracy of
-Wstrict-aliasing using tree-ssa-alias information. The primary idea
was to tell the programmer "go fix the types of variables x and y at
lines ..." when -fstrict-aliasing breaks their code.
It occurred t
On Wed, Nov 29, 2006 at 11:02:51AM -0800, Silvius Rus wrote:
>
> I wrote some code (not released yet) that improves the accuracy of
> -Wstrict-aliasing using tree-ssa-alias information. The primary idea
> was to tell the programmer "go fix the types of variables x and y at
> lines ..." when -f
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 &vec)
{
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
> 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
On 11/29/06, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
>> 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
> > > 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
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 where that
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++)
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
> 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
> 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
>
> On 11/28/06, Andrew Pinski <[EMAIL PROTECTED]> wrote:
> > > 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
> > > ge
> It doesn't help that the standards are only available for $$$ or
> as contraband.
It's an unfortunate cultural issue that C programmers traditionally don't
use the standard on a regular basis. There are other languages where
a programmer would never think of writing code without a language re
On 11/28/06, Andrew Pinski <[EMAIL PROTECTED]> wrote:
> 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 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
> 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
> 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
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
Howard Chu <[EMAIL PROTECTED]> writes:
> As I recall, we chose int[] for alignment reasons, figuring we'd have no
> guarantees on the alignment of a char[].
Neither you have on int[].
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürn
Dave Korn wrote:
On 12 November 2006 04:16, Howard Chu wrote:
Dave Korn wrote:
f = (struct foo *)(void *)buf;
That's good, but why is it safe?
Passing through void* means gcc has to assume it could alias anything,
IIUIC, as a result of the standard allowing
On Nov 11, 2006, at 10:45 PM, Howard Chu wrote:
Andrew Pinski wrote:
On Sat, 2006-11-11 at 22:18 -0800, Ian Lance Taylor wrote:
Your code will be safe on all counts if you change buf from int[] to
char[]. The language standard grants a special exemption to char*
pointers. Without that exem
Andrew Pinski wrote:
On Sat, 2006-11-11 at 22:18 -0800, Ian Lance Taylor wrote:
Your code will be safe on all counts if you change buf from int[] to
char[]. The language standard grants a special exemption to char*
pointers. Without that exemption, it would be impossible to write
malloc in
On Sat, 2006-11-11 at 22:18 -0800, Ian Lance Taylor wrote:
>
> Your code will be safe on all counts if you change buf from int[] to
> char[]. The language standard grants a special exemption to char*
> pointers. Without that exemption, it would be impossible to write
> malloc in C.
Actually it
Howard Chu <[EMAIL PROTECTED]> writes:
> Here's a different example, which produces the weaker warning
> warning: type-punning to incomplete type might break strict-aliasing rules
>
> struct foo;
>
> int blah(int fd) {
> int buf[BIG_ENOUGH];
> void *v = buf;
> struct foo
On 12 November 2006 04:16, Howard Chu wrote:
> Dave Korn wrote:
>> On 12 November 2006 03:35, Howard Chu wrote:
>>
>>
>>> If we go through the temporary variable v, there's no warning. If we
>>> don't use the temporary variable, we get the "might break" message.
>>>
>>
>> Try
>>
>>
>>>
On 12 November 2006 03:35, Howard Chu wrote:
> Here's a different example, which produces the weaker warning
> warning: type-punning to incomplete type might break strict-aliasing rules
>
> struct foo;
>
> int blah(int fd) {
> int buf[BIG_ENOUGH];
> void *v = buf;
> str
Mike Stump wrote:
On Nov 10, 2006, at 9:48 AM, Howard Chu wrote:
Richard Guenther wrote:
If you compile with -O3 -combine *.c -o alias it will break.
Thanks for pointing that out. But that's not a realistic danger for
the actual application. The accessor function is always going to be
in a
Ian Lance Taylor wrote:
Howard Chu <[EMAIL PROTECTED]> writes:
Daniel Berlin wrote:
We ask the TBAA analyzer "can a store to a short * touch i.
In this case, it says "no", because it's not legal.
If you know the code is not legal, why don't you abort the compilation
with an er
Howard Chu <[EMAIL PROTECTED]> writes:
> Daniel Berlin wrote:
> >
> > We ask the TBAA analyzer "can a store to a short * touch i.
> > In this case, it says "no", because it's not legal.
> >
> If you know the code is not legal, why don't you abort the compilation
> with an error code?
It's not act
Howard Chu wrote:
> extern void getit( void **arg );
>
> main() {
>union {
>int *foo;
>void *bar;
>} u;
>
>getit( &u.bar );
>printf("foo: %x\n", *u.foo);
> }
Rask Ingemann Lambertsen wrote:
> As far as I know, memcpy() is the answer
Howard Chu <[EMAIL PROTECTED]> writes:
> That's good to know, thanks. But frankly that's braindead to require
> someone to add all these new union declarations all over their code,
There is no need for any union trick in your example. Just use a
temporary with the correct type, and you have stri
On Fri, Nov 10, 2006 at 02:32:10PM -0800, Howard Chu wrote:
>
> With the previous example, if alias1.c was instead:
>
>
> #include
>
> extern void getit( void **arg );
>
> main() {
>union {
>int *foo;
>void *bar;
>} u;
>
>getit( &u.
Andrew Pinski wrote:
On Fri, 2006-11-10 at 23:05 -0800, Howard Chu wrote:
Daniel Berlin wrote:
We ask the TBAA analyzer "can a store to a short * touch i.
In this case, it says "no", because it's not legal.
If you know the code is not legal, why don't you abort the compilation
On Fri, 2006-11-10 at 23:05 -0800, Howard Chu wrote:
> Daniel Berlin wrote:
> >
> > We ask the TBAA analyzer "can a store to a short * touch i.
> > In this case, it says "no", because it's not legal.
> >
> If you know the code is not legal, why don't you abort the compilation
> with an error code?
Daniel Berlin wrote:
We ask the TBAA analyzer "can a store to a short * touch i.
In this case, it says "no", because it's not legal.
If you know the code is not legal, why don't you abort the compilation
with an error code? The current silent behavior provides a mechanism for
creating source-
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. And this
is not really
On Fri, 10 Nov 2006, Daniel Berlin wrote:
> > > It will load the value from memory, true, but who says that the store to
> > > memory will happen before that? The compiler is allowed to reorder the
> > > statements since it "knows" that foo and *arg cannot alias.
> > >
> >
> > If the compiler is
Hm. If you're going to reorder these things, then I would expect either
an error or a warning at that point, because you really do know that a
reference to an uninitialized variable is happening.
We do warn when we see an uninitialized value if -Wuninitialized is on.
We don't warn at every poin
Daniel Berlin wrote:
> It will load the value from memory, true, but who says that the
store to
> memory will happen before that? The compiler is allowed to reorder
the
> statements since it "knows" that foo and *arg cannot alias.
>
If the compiler is smart enough to know how to reorder the s
> It will load the value from memory, true, but who says that the store to
> memory will happen before that? The compiler is allowed to reorder the
> statements since it "knows" that foo and *arg cannot alias.
>
If the compiler is smart enough to know how to reorder the statements,
then it shoul
Andreas Schwab wrote:
Howard Chu <[EMAIL PROTECTED]> writes:
I understand that logic, in the general case. In this specific example,
none of those conditions apply. foo is an uninitialized local
variable. Therefore the compiler cannot know that it has a valid copy of
it in any register. In fa
Howard Chu <[EMAIL PROTECTED]> writes:
> I understand that logic, in the general case. In this specific example,
> none of those conditions apply. foo is an uninitialized local
> variable. Therefore the compiler cannot know that it has a valid copy of
> it in any register. In fact what it should k
Joe Buck wrote:
On Fri, Nov 10, 2006 at 04:18:25PM -0800, Howard Chu wrote:
Richard Guenther wrote:
If you compile with -O3 -combine *.c -o alias it will break.
Hm, actually it still prints the correct result for me. What platform
are you using where it actually makes a differen
On Fri, Nov 10, 2006 at 04:18:25PM -0800, Howard Chu wrote:
> Richard Guenther wrote:
> >If you compile with -O3 -combine *.c -o alias it will break.
>
> Hm, actually it still prints the correct result for me. What platform
> are you using where it actually makes a difference?
Rather, he is sayi
Richard Guenther wrote:
On 11/10/06, Howard Chu <[EMAIL PROTECTED]> wrote:
I see a lot of APIs (e.g. Cyrus SASL) that have accessor functions
returning values through a void ** argument. As far as I can tell, this
doesn't actually cause any problems, but gcc 4.1 with -Wstrict-aliasing
will compl
Mike Stump wrote:
On Nov 10, 2006, at 9:48 AM, Howard Chu wrote:
Richard Guenther wrote:
If you compile with -O3 -combine *.c -o alias it will break.
Thanks for pointing that out. But that's not a realistic danger for
the actual application. The accessor function is always going to be
in a
On Nov 10, 2006, at 9:48 AM, Howard Chu wrote:
Richard Guenther wrote:
If you compile with -O3 -combine *.c -o alias it will break.
Thanks for pointing that out. But that's not a realistic danger for
the actual application. The accessor function is always going to be
in a library compiled
Richard Guenther wrote:
On 11/10/06, Howard Chu <[EMAIL PROTECTED]> wrote:
The program prints the expected result with both strict-aliasing and
no-strict-aliasing on my x86_64 box. As such, when/why would I need to
worry about this warning?
If you compile with -O3 -combine *.c -o alias it w
On 11/10/06, Howard Chu <[EMAIL PROTECTED]> wrote:
I see a lot of APIs (e.g. Cyrus SASL) that have accessor functions
returning values through a void ** argument. As far as I can tell, this
doesn't actually cause any problems, but gcc 4.1 with -Wstrict-aliasing
will complain. For example, take th
1 - 100 of 102 matches
Mail list logo
