This patch will stop gcc from issuing warnings
about type-punned objects when -fstrict-aliasing is turned on, as it is in the
latest gcc when you use -O2
enjoy
andrew
strict-alias.patch
Description: Binary data
---(end of broadcast)-
Patch applied. Thanks.
---
Andrew Dunstan wrote:
>
> This patch will stop gcc from issuing warnings about type-punned objects when
> -fstrict-aliasing is turned on, as it is in the latest gcc when you use -O2
>
> enjoy
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Patch applied. Thanks.
I hope you applied it with the additional changes you asked for ---
at the very least, cast to (void*) and then to the destination type.
As-is, the patch simply suppresses all error detection for these
conversions, which seems a b
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Patch applied. Thanks.
>
> I hope you applied it with the additional changes you asked for ---
> at the very least, cast to (void*) and then to the destination type.
> As-is, the patch simply suppresses all error detection for these
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I don't have a version that does the double-cast, but I still have the
> patch to back out and put in a new one. Andrew's point was that we cast
> to void * in many places, so this case is not unique. Is that wrong?
I do not like code that uses cast to
Tough words! :-)
ISTM the best thing would be to back out the patch, add -fno-strict-aliasing
for gcc, and add a TODO to fix this thoroughly.
Having -fstrict-aliasing on and ignoring the warnings doesn't seem like a
sound strategy. I think we should fix it or turn it off. The web is littered
with
Andrew Dunstan wrote:
> Tough words! :-)
>
> ISTM the best thing would be to back out the patch, add -fno-strict-aliasing
> for gcc, and add a TODO to fix this thoroughly.
>
> Having -fstrict-aliasing on and ignoring the warnings doesn't seem like a
> sound strategy. I think we should fix it or t
- Original Message -
From: "Bruce Momjian" <[EMAIL PROTECTED]>
>
> I have backed out the patch.
>
> Looking at the case in tablecmds.c and proc.c, the first was assigning a
> struct with a NodeTag pointer as its first element to another struct
> with NodeTag as its first element. In fact
Andrew Dunstan wrote:
> > The proc.c cases were using MemSet, which was checking if the
> > int* as aligned for int* access. In fact, we could change MemSet to
> > always take a void *, and do the int* casting when we access it after
> > testing for alignment.
> >
>
> Since MemSet is generic, t
