Thread: MAXIMUM_ALIGNOF on Windows-32

<br clear="all" />The MAXIMUM_ALIGNOF value is set to 8 bytes in a Windows- 32-bit<br />environment. I have very little
knowledgeabout Windows, but at<br />the face of it, this looks strange. Any idea why is this required ?<br /><br />May
beI am missing something obvious.<br /><br />Thanks,<br />Pavan<br /><br />-- <br />Pavan Deolasee<br
/>EnterpriseDB    <a href="http://www.enterprisedb.com">http://www.enterprisedb.com</a> 

"Pavan Deolasee" <pavan.deolasee@gmail.com> writes:
> The MAXIMUM_ALIGNOF value is set to 8 bytes in a Windows- 32-bit
> environment. I have very little knowledge about Windows, but at
> the face of it, this looks strange. Any idea why is this required ?

It's not entirely unreasonable.  The same thing happens on HPPA,
which is nominally a 32-bit architecture but the hardware requires
8-byte alignment of doubles (and maybe int64 too, I forget).
On newer Intel hardware it'd make sense to pad to avoid misaligned
fetches.

Anyway, we detect this directly based on the C compiler's behavior,
and you can't argue with the compiler about it.  Whatever it's
doing is right by definition.
        regards, tom lane

Tom Lane wrote:
> "Pavan Deolasee" <pavan.deolasee@gmail.com> writes:
>   
>> The MAXIMUM_ALIGNOF value is set to 8 bytes in a Windows- 32-bit
>> environment. I have very little knowledge about Windows, but at
>> the face of it, this looks strange. Any idea why is this required ?
>>     
>
> It's not entirely unreasonable.  The same thing happens on HPPA,
> which is nominally a 32-bit architecture but the hardware requires
> 8-byte alignment of doubles (and maybe int64 too, I forget).
> On newer Intel hardware it'd make sense to pad to avoid misaligned
> fetches.
>
> Anyway, we detect this directly based on the C compiler's behavior,
> and you can't argue with the compiler about it.  Whatever it's
> doing is right by definition.
>
>             
>   

Perhaps Pavan is referring to what is hardcoded in pg_config.h.win32 
which is used for MSVC builds  (but not for MinGW builds, IIRC), in 
which case the answer might be that in this file we need to be 
pessimistic about such things, since we have no reasonable way to run 
configure on this platform.

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:
> Tom Lane wrote:
>> Anyway, we detect this directly based on the C compiler's behavior,
>> and you can't argue with the compiler about it.  Whatever it's
>> doing is right by definition.

> Perhaps Pavan is referring to what is hardcoded in pg_config.h.win32 
> which is used for MSVC builds  (but not for MinGW builds, IIRC), in 
> which case the answer might be that in this file we need to be 
> pessimistic about such things, since we have no reasonable way to run 
> configure on this platform.

Somebody had better double-check that.  We don't need to be
"pessimistic", we need to be *correct*, because the align values had
better match the way the compiler will lay out a C struct.  Otherwise
struct-based access to catalog rows will fail.  (I'm not sure if there
are any system catalogs with float8 or int64 columns, but I'd sure not
want to find out that we couldn't have one because of misconfiguration
of MSVC builds.)

I see though that the comment in pg_config.h.win32 claims it was derived
from mechanically-generated configure output, so unless that's lying
it should be OK already.  AFAIK struct alignment is part of the ABI for
a platform and is not subject to the whims of individual compilers, so
the result from MinGW should be OK for MSVC.
        regards, tom lane

Tom Lane wrote:
> I see though that the comment in pg_config.h.win32 claims it was derived
> from mechanically-generated configure output, so unless that's lying
> it should be OK already.  AFAIK struct alignment is part of the ABI for
> a platform and is not subject to the whims of individual compilers, so
> the result from MinGW should be OK for MSVC.
>
>   

Ah. OK, makes sense.

cheers

andrew

Ah, that makes sense. I was confusing myself with 64-bit architectures
and alignments.

Thanks,
Pavan


--
Pavan Deolasee
EnterpriseDB     http://www.enterprisedb.com

On Fri, Jul 20, 2007 at 10:32:35AM -0400, Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
> > Tom Lane wrote:
> >> Anyway, we detect this directly based on the C compiler's behavior,
> >> and you can't argue with the compiler about it.  Whatever it's
> >> doing is right by definition.
> 
> > Perhaps Pavan is referring to what is hardcoded in pg_config.h.win32 
> > which is used for MSVC builds  (but not for MinGW builds, IIRC), in 
> > which case the answer might be that in this file we need to be 
> > pessimistic about such things, since we have no reasonable way to run 
> > configure on this platform.
> 
> Somebody had better double-check that.  We don't need to be
> "pessimistic", we need to be *correct*, because the align values had
> better match the way the compiler will lay out a C struct.  Otherwise
> struct-based access to catalog rows will fail.  (I'm not sure if there
> are any system catalogs with float8 or int64 columns, but I'd sure not
> want to find out that we couldn't have one because of misconfiguration
> of MSVC builds.)

How do I double-check this?


> I see though that the comment in pg_config.h.win32 claims it was derived
> from mechanically-generated configure output, so unless that's lying
> it should be OK already. 

It's not - it started out as a copy of the output of ./configure on mingw.

> AFAIK struct alignment is part of the ABI for
> a platform and is not subject to the whims of individual compilers, so
> the result from MinGW should be OK for MSVC.

Still, it doesn't hurt to double-check.

//Magnus

Magnus Hagander <magnus@hagander.net> writes:
> Tom Lane wrote:
>> Somebody had better double-check that.  We don't need to be
>> "pessimistic", we need to be *correct*, because the align values had
>> better match the way the compiler will lay out a C struct.  Otherwise
>> struct-based access to catalog rows will fail.  (I'm not sure if there
>> are any system catalogs with float8 or int64 columns, but I'd sure not
>> want to find out that we couldn't have one because of misconfiguration
>> of MSVC builds.)

> How do I double-check this?

The configure script checks it by declaring
struct {    char pad;    TYPE field;} foo

and then measuring offsetof(foo, field), for each interesting TYPE.

>> I see though that the comment in pg_config.h.win32 claims it was derived
>> from mechanically-generated configure output, so unless that's lying
>> it should be OK already. 

> It's not - it started out as a copy of the output of ./configure on mingw.

"Started out as"?  Good luck keeping it in sync, if it's not
mechanically created.
        regards, tom lane

Tom Lane wrote:
>>> I see though that the comment in pg_config.h.win32 claims it was derived
>>> from mechanically-generated configure output, so unless that's lying
>>> it should be OK already. 
>>>       
>
>   
>> It's not - it started out as a copy of the output of ./configure on mingw.
>>     
>
> "Started out as"?  Good luck keeping it in sync, if it's not
> mechanically created.
>
>
>   

ISTM this is symptomatic of the MSVC build system problems. I understand 
why Dave and Magnus want to use it, but essentially it is breaking one 
of the original requirements of our building on Windows at all, namely 
that we use a unified build tool chain. It's a thousand pities.

cheers

andrew

Tom Lane wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> Tom Lane wrote:
>>> Somebody had better double-check that.  We don't need to be
>>> "pessimistic", we need to be *correct*, because the align values had
>>> better match the way the compiler will lay out a C struct.  Otherwise
>>> struct-based access to catalog rows will fail.  (I'm not sure if there
>>> are any system catalogs with float8 or int64 columns, but I'd sure not
>>> want to find out that we couldn't have one because of misconfiguration
>>> of MSVC builds.)
> 
>> How do I double-check this?
> 
> The configure script checks it by declaring
> 
>     struct {
>         char pad;
>         TYPE field;
>     } foo
> 
> and then measuring offsetof(foo, field), for each interesting TYPE.

Ok. Confirmed that they are all the same.


>>> I see though that the comment in pg_config.h.win32 claims it was derived
>>> from mechanically-generated configure output, so unless that's lying
>>> it should be OK already. 
> 
>> It's not - it started out as a copy of the output of ./configure on mingw.
> 
> "Started out as"?  Good luck keeping it in sync, if it's not
> mechanically created.

It's been working fine for a year... In general, any new features need
to be added to the build system anyway, which gets done when the feature
is checked to be working on the msvc build (see the gssapi or the xml
stuff for example). Since we don't have ./configure there.
There's no point in automatically adding the "#undef" rows if there is
no system that changes them into #defines if they're used..

//Magnus