From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org, postgresbuildfarm(at)Sun(dot)COM |
Subject: | Re: gothic_moth, codlin_moth failures on REL8_2_STABLE |
Date: | 2010-03-11 16:37:45 |
Message-ID: | 21544.1268325465@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM> writes:
> "-xO4 -xalias_level=basic" generates problem.
> "-xO3 -xalias_level=basic" works fine
> "-xO5" works fine
> As documentation say:
> Cite from Sun studio compiler guide:
> http://docs.sun.com/app/docs/doc/819-5265/bjapp?a=view
> xalias_level=basic
> ------------------
> If you use the -xalias_level=basic option, the compiler assumes that
> memory references that involve different C basic types do not alias each
> other. The compiler also assumes that references to all other types can
> alias each other as well as any C basic type. The compiler assumes that
> references using char * can alias any other type.
> For example, at the -xalias_level=basic level, the compiler assumes that
> a pointer variable of type int * is not going to access a float object.
> Therefore it is safe for the compiler to perform optimizations that
> assume a pointer of type float * will not alias the same memory that is
> referenced with a pointer of type int *.
I think you need to turn that off. On gcc we use -fno-strict-aliasing
which disables the type of compiler assumption that this is talking about.
I'm not sure exactly how that might create the specific failure we are
seeing here, but I can point you to lots and lots of places in the
sources where such an assumption would break things.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Zdenek Kotala | 2010-03-11 17:01:20 | Re: gothic_moth, codlin_moth failures on REL8_2_STABLE |
Previous Message | Zdenek Kotala | 2010-03-11 16:32:02 | Re: gothic_moth, codlin_moth failures on REL8_2_STABLE |