Ben Elliston wrote:
> On Tue, 2009-05-19 at 14:57 +0200, Richard Guenther wrote:
>
>> The patch is ok.
>
> I fell off the Cc: list, but I assume you are talking to me. :-)
Sorry, I forked the thread, but I did change the subject! :)
cheers,
DaveK
On Tue, 2009-05-19 at 14:57 +0200, Richard Guenther wrote:
> The patch is ok.
I fell off the Cc: list, but I assume you are talking to me. :-)
Thanks,
Ben
Andrew Haley wrote:
> Dave Korn wrote:
>> Ben Elliston wrote:
>>> This patch silences the following warnings when building libgcc:
>>>
>>> unwind-dw2-fde.c:321: warning: dereferencing type-punned pointer will break
>>> strict-aliasing rules
>>> - const _Unwind_Ptr x_ptr = *(const _Unwind_Ptr *) x-
On Tue, May 19, 2009 at 2:44 PM, Andrew Haley wrote:
> Dave Korn wrote:
>> Ben Elliston wrote:
>>> This patch silences the following warnings when building libgcc:
>>>
>>> unwind-dw2-fde.c:321: warning: dereferencing type-punned pointer will break
>>> strict-aliasing rules
>>
>>> - const _Unwind_
Dave Korn wrote:
> Ben Elliston wrote:
>> This patch silences the following warnings when building libgcc:
>>
>> unwind-dw2-fde.c:321: warning: dereferencing type-punned pointer will break
>> strict-aliasing rules
>
>> - const _Unwind_Ptr x_ptr = *(const _Unwind_Ptr *) x->pc_begin;
>> - const _U
> I'll try to make a simple example on which GCC produces bad code.
You can find an example below. GCC-4.1 generates bad code (GCC-4.2 is
fine). Neither version give a type-punning warning, though. I'm sorry
that I didn't check gcc-4.2 before I started this thread.
Geza
Here's the code, I c
Herman Geza <[EMAIL PROTECTED]> writes:
> Yes, it's clear now, thanks. However, it brings a new question: the
> standard defines layout-compatible types. For example, if I'm correct, my
> Vector
> and Point are layout compatible. What can I do with layout compatible
> objects?
You can put t
On Tue, 26 Jun 2007, Andrew Pinski wrote:
> On 6/26/07, Herman Geza <[EMAIL PROTECTED]> wrote:
> > Having the same layout makes them "the same".
> Not in C or C++ and in most cases of fortran too (unless you add an
> attribute).
Yes, it's clear now, thanks. However, it brings a new question: th
On 6/26/07, Herman Geza <[EMAIL PROTECTED]> wrote:
Having the same layout makes them "the same".
Not in C or C++ and in most cases of fortran too (unless you add an attribute).
-- Pinski
On Tue, 26 Jun 2007 [EMAIL PROTECTED] wrote:
> On Tue, Jun 26, 2007 at 11:42:27PM +0200, Herman Geza wrote:
> > struct Point {
> > float x, y, z;
> > };
> > struct Vector {
> > float x, y, z;
> >
> > Point &asPoint() {
> > return reinterpret_cast(*this);
> > }
> > };
On Tue, Jun 26, 2007 at 11:42:27PM +0200, Herman Geza wrote:
> struct Point {
> float x, y, z;
> };
> struct Vector {
> float x, y, z;
>
> Point &asPoint() {
> return reinterpret_cast(*this);
> }
> };
> Point and Vector have the same layout, but GCC treats th
On Tue, 26 Jun 2007, Silvius Rus wrote:
> Herman Geza wrote:
> > aliasing when GCC (I think) incorrectly treats types different, but they're
> > the same. For example, I have:
> >
> > struct Point {
> > float x, y, z;
> > };
> >
> > struct Vector {
> > float x, y, z;
> >
> > Poin
On 6/26/07, Silvius Rus <[EMAIL PROTECTED]> wrote:
I also think this case should not be flagged. I have seen similar usage
in network programming. Did it actually result in bad code or was it
just the warning that bothered you?
This case is valid only if you go back to original type of Vector
Herman Geza wrote:
aliasing when GCC (I think) incorrectly treats types different, but
they're the same. For example, I have:
struct Point {
float x, y, z;
};
struct Vector {
float x, y, z;
Point &asPoint() {
return reinterpret_cast(*this);
}
On Tue, 26 Jun 2007, Silvius Rus wrote:
> Herman Geza wrote:
> > void foo(float *a) {
> > int *b = (int*)a; // type-punning warning
> >
> > // here, access to a and b shouldn't be optimized, as the compiler
> > knows that a and b point to the same address
> > }
> >
> > Is this reasonab
Herman Geza wrote:
void foo(float *a) {
int *b = (int*)a; // type-punning warning
// here, access to a and b shouldn't be optimized, as the compiler
knows that a and b point to the same address
}
Is this reasonable?
Even if it were trivial to implement, I would vote against it, be
On 6/26/07, Herman Geza <[EMAIL PROTECTED]> wrote:
Let me elaborate. If the compiler can detect invalid type-punning,
Not really.
void foo(float *a) {
int *b = (int*)a; // type-punning warning
}
This is actually valid if we don't access both a and b and also the
original type is in
On Tue, 26 Jun 2007, Andrew Pinski wrote:
> On 6/26/07, Herman Geza <[EMAIL PROTECTED]> wrote:
> > Maybe GCC shouldn't optimize around invalid type-punnings?
>
> That is what -fno-strict-aliasing is for.
> Also GCC has done this since 3.0.0 (and also 2.95 and 2.95.1 and then
> in 2.95.2 it was c
On 6/26/07, Herman Geza <[EMAIL PROTECTED]> wrote:
Maybe GCC shouldn't optimize around invalid type-punnings?
That is what -fno-strict-aliasing is for.
Also GCC has done this since 3.0.0 (and also 2.95 and 2.95.1 and then
in 2.95.2 it was changed back while most of the free source world
fixes t
Thanks for the answers!
> > Why? Won't the following work?
> >
> > void setNaN(float &v) {
> > union { float f; int i; } t;
> > t.i = 0x7f81;
> > v = t.f;
> > }
> >
> As far as I know, this is guaranteed to work with GCC. But it is not kosher
> according to language standards, so ot
Chris Lattner <[EMAIL PROTECTED]> writes:
> On Jun 22, 2007, at 1:41 AM, Sergei Organov wrote:
>
>> Herman Geza <[EMAIL PROTECTED]> writes:
>>
>> [...]
>>
>>> What is the correct way to do this:
>>>
>>> void setNaN(float &v) {
>>> reinterpret_cast(v) = 0x7f81;
>>> }
>>>
>>> without a type-
Sergei Organov wrote:
Herman Geza <[EMAIL PROTECTED]> writes:
[...]
What is the correct way to do this:
void setNaN(float &v) {
reinterpret_cast(v) = 0x7f81;
}
without a type-prunning warning? I cannot use the union trick here
Why? Won't the following work?
void setNaN
On Jun 22, 2007, at 1:41 AM, Sergei Organov wrote:
Herman Geza <[EMAIL PROTECTED]> writes:
[...]
What is the correct way to do this:
void setNaN(float &v) {
reinterpret_cast(v) = 0x7f81;
}
without a type-prunning warning? I cannot use the union trick here
Why? Won't the foll
Herman Geza <[EMAIL PROTECTED]> writes:
[...]
> What is the correct way to do this:
>
> void setNaN(float &v) {
> reinterpret_cast(v) = 0x7f81;
> }
>
> without a type-prunning warning? I cannot use the union trick here
Why? Won't the following work?
void setNaN(float &v) {
union {
Herman Geza wrote:
struct A {
float x, y;
};
struct B {
float x, y;
};
int main() {
A a;
B &b = reinterpret_cast(a);
}
I get a type-punned warning for this code. However, A & B is exactly the
same type. Is the warning appropriate here?
Unfortunately gcc 4.3
This may have been fixed by a recent patch to -Wstrict-aliasing. Let me
try to run the latest version of pre4.3 and will get back to you.
Herman Geza wrote:
Hi,
gcc's docs states that at -fstrict-aliasing:
"In particular, an object of one type is assumed never to reside at the
same address
26 matches
Mail list logo
