Skip site navigation (1) Skip section navigation (2)

Re: Something's been bugging me

From: Florian Weimer <fweimer(at)bfk(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Gregory Stark <stark(at)enterprisedb(dot)com>, "PostgreSQL-development Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Something's been bugging me
Date: 2007-10-04 07:14:58
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
* Tom Lane:

> I ran into an interesting failure here on HPPA: the code the compiler
> generated for copying unaligned toast pointers into aligned local
> variables failed, because it was assuming halfword (2-byte) alignment of
> the data to be copied!  (Instead of a memcpy call it was generating an
> inline loop of ldh/sth instructions.)  Apparently gcc's thought process
> is "the pointer is declared as struct varlena *, therefore must be at
> least 4-aligned, therefore the data at offset 2 is at least 2-aligned".
> The intermediate cast to "varattrib_1b_e *" did not prevent this; I
> had to assign the datum pointer into a separate local variable of that
> type to suppress the "optimization".

This is quite deliberate, it leads to better code.  In general, once
you've cast a pointer to something which needs more alignment than
what's actually, there is no way to get away from that (except using
asm insertions as optimization barriers, of course).  This is fine
from the C semantics because undefined behavior occurs during the cast

I believe that other compilers have similar rules (certainly when it
comes to aliasing), so it's better not to try to outsmart the C
standard here.

Florian Weimer                <fweimer(at)bfk(dot)de>
BFK edv-consulting GmbH
Kriegsstra├če 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

In response to

pgsql-hackers by date

Next:From: Neil ConwayDate: 2007-10-04 07:49:00
Subject: Re: Getting to 8.3 beta1
Previous:From: Guillaume SmetDate: 2007-10-04 07:04:41
Subject: Re: Getting to 8.3 beta1

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group