type_with_alignment.hpp VC8 error

Hi, svn revision 43952 broke my VC8 build: C:\AUTOBU~1\sources\boost\boost/python/converter/as_to_python_function.hpp(21) : error C2719: 'unnamed-parameter': formal parameter with __declspec(align('8') ) won't be aligned The compilation command is attached. Ralf cl /nologo /D_SECURE_SCL=0 /D_CRT_SECURE_NO_DEPRECATE /wd4996 /Zm800 /MD /GR /EH sc /DBOOST_DISABLE_THREADS /DNDEBUG /Ox -DBOOST_ALL_NO_LIB -DBOOST_PYTHON_MAX_ BASES=2 /IC:\AUTOBU~1\sources /IC:\AUTOBU~1\sources\boost /IC:\AUTOBU~1\build\ base\python\include /c C:\AUTOBU~1\sources\boost_adaptbx\optional_ext.cpp /Fob oost_adaptbx\optional_ext.obj

Ralf W. Grosse-Kunstleve wrote:
Hi,
svn revision 43952 broke my VC8 build:
C:\AUTOBU~1\sources\boost\boost/python/converter/as_to_python_function.hpp(21) : error C2719: 'unnamed-parameter': formal parameter with __declspec(align('8') ) won't be aligned
The compilation command is attached.
Grrr, do you have a test case? This is certainly deeply annoying: in order to fix one bug it appears I've introduced another - but without seeing the instantiation context and working out what Boost.Python is doing it's hard to say whether this should be fixed in type_traits or Boost.Python. Thanks, John.

Hi John ! On Monday 31 March 2008, John Maddock wrote:
Ralf W. Grosse-Kunstleve wrote:
svn revision 43952 broke my VC8 build:
My experimental builds of our own program, too.
C:\AUTOBU~1\sources\boost\boost/python/converter/as_to_python_funct ion.hpp(21)
: error C2719: 'unnamed-parameter': formal parameter with
__declspec(align('8') ) won't be aligned
The compilation command is attached.
Grrr, do you have a test case?
I've managed to strip our code down to the attached example. I hope this is small enough and helps...
This is certainly deeply annoying: in order to fix one bug it appears I've introduced another - but without seeing the instantiation context and working out what Boost.Python is doing it's hard to say whether this should be fixed in type_traits or Boost.Python.
My testcase does not use Boost.Python, so I think the problem should be in type_traits. Please note: this only affects 32-bit builds, 64-bit builds using Visual Studio or address-model=64 when using bjam work. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold@ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

Juergen Hunold wrote:
I've managed to strip our code down to the attached example. I hope this is small enough and helps...
This is certainly deeply annoying: in order to fix one bug it appears I've introduced another - but without seeing the instantiation context and working out what Boost.Python is doing it's hard to say whether this should be fixed in type_traits or Boost.Python.
My testcase does not use Boost.Python, so I think the problem should be in type_traits. Please note: this only affects 32-bit builds, 64-bit builds using Visual Studio or address-model=64 when using bjam work.
Confirmed: that looks like a valid use case to me! ;-) I hope this is now fixed in Trunk: note however, you can still generate types with type_with_alignment<> which can't be passed through a function by value - but only if no other "ordinary" type is available - previously type_with_alignment<> wouldn't have compiled in these cases anyway. Regards, John.

Hi John ! An'n Dienstag 01 April 2008 hett John Maddock schreven:
Juergen Hunold wrote:
My testcase does not use Boost.Python, so I think the problem should be in type_traits. Please note: this only affects 32-bit builds, 64-bit builds using Visual Studio or address-model=64 when using bjam work.
Confirmed: that looks like a valid use case to me! ;-)
*sigh* This is good to hear.
I hope this is now fixed in Trunk:
Confirmed, my build against TRUNK is up and running again. Thanks for the quick fix !
note however, you can still generate types with type_with_alignment<> which can't be passed through a function by value - but only if no other "ordinary" type is available - previously type_with_alignment<> wouldn't have compiled in these cases anyway.
Well, we're just reusing existing Boost components here :-)) Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold@ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

John Maddock wrote:
Ralf W. Grosse-Kunstleve wrote:
Hi,
svn revision 43952 broke my VC8 build:
C:\AUTOBU~1\sources\boost\boost/python/converter/as_to_python_function.hpp(21) : error C2719: 'unnamed-parameter': formal parameter with __declspec(align('8') ) won't be aligned
The compilation command is attached.
Grrr, do you have a test case? This is certainly deeply annoying: in order to fix one bug it appears I've introduced another - but without seeing the instantiation context and working out what Boost.Python is doing it's hard to say whether this should be fixed in type_traits or Boost.Python.
For all I know, MS compilers don't accept alignment requirements for function parameters, as they cannot guarantee the stack alignment at each point of call. Bo Persson
participants (5)
-
Bo Persson
-
John Maddock
-
Juergen Hunold
-
Jürgen Hunold
-
Ralf W. Grosse-Kunstleve