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
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 _Unwind_Ptr y_ptr = *(const
> 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
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 t
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 again
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
origi
1 and then
> in 2.95.2 it was changed back while most of the free source world
> fixes their code).
Let me elaborate. If the compiler can detect invalid type-punning,
then shouldn't optimize. For example,
void foo(int *a, float *b) {
// here, access to a and b can be optimi
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
OK to me (too bad that I missed this "trick").
Note that my problem is not the unnecessary type-punning warning (I could
live with that), but miscompiled code because of the too strict rule that
GCC uses. Maybe GCC shouldn't optimize around invalid type-punnings?
Geza
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-
ranteed to optimize
the call to "memcpy" out either.
Type punning has been disallowed regardless of disguise at least since
Fortran77, when compiler writers realized it had become evil. However,
in my opinion, there's a big difference between a useful little trick
like the u
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
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 as an object of a different type, unless the types are almost
the same."
I have problems with this:
struct A {
float x, y;
};
struct B {
float
28 matches
Mail list logo
