Loading ...
Sorry, an error occurred while loading the content.

Re: [ublas-dev] Fix for construction problem

Expand Messages
  • Matthias Troyer
    ... Thanks! Now it works again flawlessly. I appreciate the quick help. Regarding the performance issues: would it be possible to use the workaround just for
    Message 1 of 23 , Sep 30, 2004
    • 0 Attachment
      On Sep 30, 2004, at 6:52 PM, Michael Stevens wrote:

      > Matthias,
      >
      > I have committed a fix. The problem was in unbounded_array.

      Thanks! Now it works again flawlessly. I appreciate the quick help.

      Regarding the performance issues: would it be possible to use the
      workaround just for the nonconforming compilers?

      Matthias
    • Michael Stevens
      ... That is good. I jumped on this quickly as I had been looking for a memory allocation problem involving user defined types. Code warrior 9 was showing
      Message 2 of 23 , Oct 1, 2004
      • 0 Attachment
        On Friday 01 October 2004 08:58, Matthias Troyer wrote:
        > On Sep 30, 2004, at 6:52 PM, Michael Stevens wrote:
        > > Matthias,
        > >
        > > I have committed a fix. The problem was in unbounded_array.
        >
        > Thanks! Now it works again flawlessly. I appreciate the quick help.
        That is good. I jumped on this quickly as I had been looking for a memory
        allocation problem involving user defined types. Code warrior 9 was showing
        something a miss in this area. So you failure report on another compiler was
        very interesting.

        The fix has cured Comeau's problems with test3 and test4, but cw-9 still seems
        to have problems with std::complex!

        > Regarding the performance issues: would it be possible to use the
        > workaround just for the nonconforming compilers?
        I've looked into the C++ standard and GCC bugs as to how array placement new
        should work.

        In particular
        http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9982
        explains why GCC 3.4 onwards work in this case.
        In seems that the GCC ABI mandates that no offset is applied in the case of
        ::operator new[](size_t, void*) being called by an array placement new.
        GCC-3.4 has this behaviour but earlier versions of 3.x were deficient in this
        regard.

        Sadly the ISO standard does not allow array placement new to be useful. 5.3.4,
        clauses 12 allows an arbitrary offset to use to store an array size even when
        a placement new is used.

        So it seems compilers which allow for an offset when array placement new is
        used are standard conforming if not very useful.
        So in general the loop form must be used.

        I propose to add to ublas/config.hpp a macro
        BOOST_UBLAS_USEFUL_ARRAY_PLACEMENT_NEW
        which can be enabled for compilers which are specifically able to support
        this..

        So far I know the following compilers allow it:
        GCC 3.4 or greater
        Intel-linux 8.0

        The follow do not allow it:
        MSVC 7.1

        I would be interested if people with compilers other then GCC can run the
        following test code and report the output.

        /*
        * Test array placement new for uBLAS
        * See if base pointers are effected by array count cookie
        */

        #include <iostream>

        class udt;
        udt* base_pointer;

        class udt {
        public:
        udt () {
        base_pointer = this;
        }
        ~udt () {} // required for GCC
        };

        int main ()
        {
        udt a;
        udt* ap = &a;

        new (ap) udt;
        std::cout << int (base_pointer - ap) << std::endl;
        new (ap) udt [1];
        std::cout << int (base_pointer - ap) << std::endl;
        }

        Michael
        --
        ___________________________________
        Michael Stevens Systems Engineering

        Navigation Systems, Estimation and
        Bayesian Filtering
        http://bayesclasses.sf.net
        ___________________________________
      • Peter Schmitteckert
        Salut, ... ______________________________ IRIX64 6.5 ... g++ (GCC) 3.3 bash-2.03$ ./a 0 4 MIPSpro Compilers: Version 7.30 bash-2.03$ ./a 0 0 MIPSpro Compilers:
        Message 3 of 23 , Oct 1, 2004
        • 0 Attachment
          Salut,

          On Fri, 1 Oct 2004, Michael Stevens wrote:


          > I would be interested if people with compilers other then GCC can run the
          > following test code and report the output.

          ______________________________
          IRIX64 6.5
          -------------------------------

          g++ (GCC) 3.3
          bash-2.03$ ./a
          0
          4

          MIPSpro Compilers: Version 7.30
          bash-2.03$ ./a
          0
          0

          MIPSpro Compilers: Version 7.30; 64 bit abi
          bash-2.03$ ./a
          0
          0

          ______________________________
          AIX 1 5
          ______________________________
          xlC v 5

          bash-2.05a$ ./a
          0
          534864313


          bash-2.05a$ xlC a.C -q64 -o a
          bash-2.05a$ ./a
          0
          -269533103


          Best wishes,
          Peter
        • Matthias Troyer
          ... IBM Visual Age C++ (xlC) reports: 0 534866217 Matthias
          Message 4 of 23 , Oct 1, 2004
          • 0 Attachment
            > I would be interested if people with compilers other then GCC can run
            > the
            > following test code and report the output.

            IBM Visual Age C++ (xlC) reports:

            0
            534866217

            Matthias
          • Matthias Troyer
            Another question: is the following warning I get from g++-3.1 significant: /Users/troyer/src/boost/boost/numeric/ublas/storage.hpp:123: warning: base class
            Message 5 of 23 , Oct 1, 2004
            • 0 Attachment
              Another question: is the following warning I get from g++-3.1
              significant:

              /Users/troyer/src/boost/boost/numeric/ublas/storage.hpp:123: warning:
              base
              class `class

              boost::numeric::ublas::storage_array<boost::numeric::ublas::
              unbounded_array<std::complex<double>,
              std::allocator<std::complex<double> > > >' should be explicitly
              initialized
              in the copy constructor


              Matthias
            • Peter Schmitteckert
              Salut, ... same for Version 6.5 Best wishes, Peter _______________________________________ Dr. Peter Schmitteckert TKM / CFN University of Karlsruhe ++49 721
              Message 6 of 23 , Oct 1, 2004
              • 0 Attachment
                Salut,

                On Fri, 1 Oct 2004, Peter Schmitteckert wrote:


                > ______________________________
                > IRIX64 6.5
                > -------------------------------
                >
                > MIPSpro Compilers: Version 7.30
                > bash-2.03$ ./a
                > 0
                > 0
                >
                same for Version 6.5

                Best wishes,
                Peter
                _______________________________________

                Dr. Peter Schmitteckert
                TKM / CFN University of Karlsruhe
                ++49 721 608 3363
              • Michael Stevens
                Thanks Peter, ... Looks good. ... Seriously weird! I expected 0 0 or 0 4. Looks like xlC is not calling the default constructor at all in the array case! The
                Message 7 of 23 , Oct 1, 2004
                • 0 Attachment
                  Thanks Peter,
                  > MIPSpro Compilers: Version 7.30
                  > bash-2.03$ ./a
                  > 0
                  > 0
                  >
                  > MIPSpro Compilers: Version 7.30; 64 bit abi
                  > bash-2.03$ ./a
                  > 0
                  > 0
                  Looks good.

                  > ______________________________
                  > AIX 1 5
                  > ______________________________
                  > xlC v 5
                  >
                  > bash-2.05a$ ./a
                  > 0
                  > 534864313
                  >
                  >
                  > bash-2.05a$ xlC a.C -q64 -o a
                  > bash-2.05a$ ./a
                  > 0
                  > -269533103
                  Seriously weird! I expected 0 0 or 0 4. Looks like xlC is not calling the
                  default constructor at all in the array case! The default code will work
                  however.

                  Thanks,
                  Michael
                • Michael Stevens
                  Peter, ... Any idea how to detect version 6.5 or greater at compile time. I assume something like: #if defined (__sgi) && XXX Thanks, Michael
                  Message 8 of 23 , Oct 1, 2004
                  • 0 Attachment
                    Peter,

                    On Friday 01 October 2004 15:43, Peter Schmitteckert wrote:
                    > > ______________________________
                    > > IRIX64 6.5
                    > > -------------------------------
                    > >
                    > > MIPSpro Compilers: Version 7.30
                    > > bash-2.03$ ./a
                    > > 0
                    > > 0
                    >
                    > same for Version 6.5

                    Any idea how to detect version 6.5 or greater at compile time. I assume
                    something like:
                    #if defined (__sgi) && XXX

                    Thanks,
                    Michael
                  • Michael Stevens
                    ... This is harmless but odd. The base class is empty. Does the warning only happen for the copy constructor or other constructors also? Oddly I cannot
                    Message 9 of 23 , Oct 1, 2004
                    • 0 Attachment
                      On Friday 01 October 2004 14:31, Matthias Troyer wrote:
                      > Another question: is the following warning I get from g++-3.1
                      > significant:
                      >
                      > /Users/troyer/src/boost/boost/numeric/ublas/storage.hpp:123: warning:
                      > base
                      > class `class
                      >
                      > boost::numeric::ublas::storage_array<boost::numeric::ublas::
                      > unbounded_array<std::complex<double>,
                      > std::allocator<std::complex<double> > > >' should be explicitly
                      > initialized
                      > in the copy constructor

                      This is harmless but odd. The base class is empty. Does the warning only
                      happen for the copy constructor or other constructors also?

                      Oddly I cannot reproduce the warning on 3.3.3 or 3.4.2 even with -Wall
                      -pedantic. I can't find anything on GCC bugzilla suggesting the warning has
                      been removed however.

                      Look at the rest of uBLAS Joerg has been careful to include such empty base
                      class initializes in all constructors.

                      Michael
                    • Peter Schmitteckert
                      Salut, ... same for 7.4 (I m finding more and more different sgi machines, it is like searching for easter eggs) ... I ve found nothing in the man page. __sgi
                      Message 10 of 23 , Oct 1, 2004
                      • 0 Attachment
                        Salut,

                        On Fri, 1 Oct 2004, Michael Stevens wrote:


                        > On Friday 01 October 2004 15:43, Peter Schmitteckert wrote:
                        > > > ______________________________
                        > > > IRIX64 6.5
                        > > > -------------------------------
                        > > >
                        > > > MIPSpro Compilers: Version 7.30
                        > > > bash-2.03$ ./a
                        > > > 0
                        > > > 0
                        > >
                        > > same for Version 6.5
                        same for 7.4 (I'm finding more and more different sgi machines,
                        it is like searching for easter eggs)

                        >
                        > Any idea how to detect version 6.5 or greater at compile time. I assume
                        > something like:
                        > #if defined (__sgi) && XXX

                        I've found nothing in the man page.
                        __sgi is set to 1.

                        One, e.g. before calling make one can run "CC -version"

                        SGI_Version=` CC -version 2>&1 | cut -d' ' -f4 `

                        but that's ugly and shell dependent.

                        Best wishes,
                        Peter
                      • Michael Stevens
                        Peter, I propose the following for ublas/config.hpp // SGI MIPSpro C++ compiler #if defined (__sgi) && ! defined (BOOST_STRICT_CONFIG) // Missing std::abs
                        Message 11 of 23 , Oct 1, 2004
                        • 0 Attachment
                          Peter,

                          I propose the following for ublas/config.hpp

                          // SGI MIPSpro C++ compiler
                          #if defined (__sgi) && ! defined (BOOST_STRICT_CONFIG)

                          // Missing std::abs overloads for float types in <cmath> are in <cstdlib>
                          // This should should be library version specific.
                          #include <cstdlib>

                          #if __COMPILER_VERSION >=650
                          // By inspection of compiler results - thanks to Peter Schmitteckert
                          #define BOOST_UBLAS_USEFUL_ARRAY_PLACEMENT_NEW
                          #endif

                          #endif


                          I got the __COMPILER_VERSION from the internet see
                          http://predef.sourceforge.net/precomp.html

                          Michael
                        • Patrick Kowalzick
                          MSVC 7.1: Compiling without errors. Output: 0 4 Exception thrown while quitting: Run-Time Check Failure #2 - Stack around the variable a was corrupted. ...
                          Message 12 of 23 , Oct 1, 2004
                          • 0 Attachment
                            MSVC 7.1:

                            Compiling without errors.

                            Output:
                            0
                            4

                            Exception thrown while quitting:
                            Run-Time Check Failure #2 - Stack around the variable 'a' was
                            corrupted.

                            > The follow do not allow it:
                            > MSVC 7.1

                            Worse, it allows, but fails.

                            Patrick
                          • Peter Schmitteckert
                            Salut, ... actually I have a several include file fixes for MipsPro, which I need to compile my sources, most notably #ifndef INCLUDES_CPP_CSTDDEF #define
                            Message 13 of 23 , Oct 1, 2004
                            • 0 Attachment
                              Salut,

                              On Fri, 1 Oct 2004, Michael Stevens wrote:


                              > // SGI MIPSpro C++ compiler
                              > #if defined (__sgi) && ! defined (BOOST_STRICT_CONFIG)
                              >
                              > // Missing std::abs overloads for float types in <cmath> are in <cstdlib>
                              > // This should should be library version specific.
                              > #include <cstdlib>


                              actually I have a several include file fixes for MipsPro,
                              which I need to compile my sources, most notably

                              #ifndef INCLUDES_CPP_CSTDDEF
                              #define INCLUDES_CPP_CSTDDEF

                              #include <stddef.h>

                              namespace std
                              {
                              using ::ptrdiff_t;
                              using ::size_t;
                              }

                              #endif // INCLUDES_CPP_CSTDDEF

                              for cstddef.
                              In addition for cassert, cmath and cstdlib.

                              If there's interest I can post them.

                              Best wishes,
                              Peter
                            • a_balmashnov
                              ... run the ... $uname -s -r -v HP-UX B.11.00 U $aCC -V aCC: HP ANSI C++ B3910B A.03.37 $./a.out 0 8
                              Message 14 of 23 , Oct 4, 2004
                              • 0 Attachment
                                --- In ublas-dev@yahoogroups.com, Michael Stevens
                                <Michael.Stevens@e...> wrote:
                                > I would be interested if people with compilers other then GCC can
                                run the
                                > following test code and report the output.

                                $uname -s -r -v
                                HP-UX B.11.00 U
                                $aCC -V
                                aCC: HP ANSI C++ B3910B A.03.37
                                $./a.out
                                0
                                8
                              • Michael Stevens
                                ... Thanks for that. Looks like the majority of compilers don t support the original array placement new syntax. Michael
                                Message 15 of 23 , Oct 7, 2004
                                • 0 Attachment
                                  On Monday 04 October 2004 10:22, a_balmashnov wrote:
                                  >
                                  > $uname -s -r -v
                                  > HP-UX B.11.00 U
                                  > $aCC -V
                                  > aCC: HP ANSI C++ B3910B A.03.37
                                  > $./a.out
                                  > 0
                                  > 8
                                  Thanks for that. Looks like the majority of compilers don't support the
                                  original array placement new syntax.

                                  Michael
                                • Toon Knapen
                                  ... What if unbounded_array would not call placement new. This would result in the elements not being initialised. This would be similar to C-arrays after
                                  Message 16 of 23 , Oct 8, 2004
                                  • 0 Attachment
                                    Michael Stevens wrote:

                                    >>>I have committed a fix. The problem was in unbounded_array.

                                    What if unbounded_array would not call placement new. This would result
                                    in the elements not being initialised. This would be similar to C-arrays
                                    after construction (only unbounded_array is dynamic in size whereas
                                    C-arrays are not).

                                    toon
                                  • Matthias Troyer
                                    ... I was always of the opinion that C-arrays of non-POD types were always default-constructed? Matthias
                                    Message 17 of 23 , Oct 8, 2004
                                    • 0 Attachment
                                      On Oct 8, 2004, at 11:55 AM, Toon Knapen wrote:

                                      >
                                      > Michael Stevens wrote:
                                      >
                                      >>>> I have committed a fix. The problem was in unbounded_array.
                                      >
                                      > What if unbounded_array would not call placement new. This would result
                                      > in the elements not being initialised. This would be similar to
                                      > C-arrays
                                      > after construction (only unbounded_array is dynamic in size whereas
                                      > C-arrays are not).
                                      >
                                      > toon

                                      I was always of the opinion that C-arrays of non-POD types were always
                                      default-constructed?

                                      Matthias
                                    • Michael Stevens
                                      ... That is the case. Indeed uBLAS unbounded_array are now as Toon described. Dynamicly sized equivalents of a C array. Both types are uninitialised in that
                                      Message 18 of 23 , Oct 8, 2004
                                      • 0 Attachment
                                        On Friday 08 October 2004 12:01, Matthias Troyer wrote:
                                        > On Oct 8, 2004, at 11:55 AM, Toon Knapen wrote:
                                        > > Michael Stevens wrote:
                                        > >>>> I have committed a fix. The problem was in unbounded_array.
                                        > >
                                        > > What if unbounded_array would not call placement new. This would result
                                        > > in the elements not being initialised. This would be similar to
                                        > > C-arrays
                                        > > after construction (only unbounded_array is dynamic in size whereas
                                        > > C-arrays are not).
                                        > >
                                        > > toon

                                        >
                                        > I was always of the opinion that C-arrays of non-POD types were always
                                        > default-constructed?
                                        That is the case.

                                        Indeed uBLAS unbounded_array are now as Toon described. Dynamicly sized
                                        equivalents of a C array.

                                        Both types are 'uninitialised' in that their element are 'value_type', as
                                        opposed to 'value_type()' constructed. This only makes a difference for POD.
                                        If the compiler supports array placement new then the construction of
                                        unbounded_array can be implemented optimally. If it doesn't then it depends
                                        on how well it can optimise away a loop of do nothing placement new
                                        constructors.

                                        As well as this uninitialised behaviour unbounded_array also has an
                                        initialised constructor where the elements are copy constructed.

                                        Michael






                                        >
                                        > Matthias
                                        >
                                        >
                                        >
                                        >
                                        >
                                        > Yahoo! Groups Links
                                        >
                                        >
                                        >

                                        --
                                        ___________________________________
                                        Michael Stevens Systems Engineering

                                        34128 Kassel, Germany
                                        Phone/Fax: +49 561 5218038

                                        Navigation Systems, Estimation and
                                        Bayesian Filtering
                                        http://bayesclasses.sf.net
                                        ___________________________________
                                      • Toon Knapen
                                        ... But I wonder why it is necessary to call placement-new after the allocate call on the allocator. The allocator will create the elements so I see no need
                                        Message 19 of 23 , Oct 11, 2004
                                        • 0 Attachment
                                          Michael Stevens wrote:
                                          > On Friday 08 October 2004 12:01, Matthias Troyer wrote:
                                          >
                                          >>On Oct 8, 2004, at 11:55 AM, Toon Knapen wrote:
                                          >>
                                          >>>Michael Stevens wrote:
                                          >>>
                                          >>>>>>I have committed a fix. The problem was in unbounded_array.
                                          >>>
                                          >>>What if unbounded_array would not call placement new. This would result
                                          >>>in the elements not being initialised. This would be similar to
                                          >>>C-arrays
                                          >>>after construction (only unbounded_array is dynamic in size whereas
                                          >>>C-arrays are not).
                                          >>>
                                          >>>toon
                                          >
                                          >
                                          >>I was always of the opinion that C-arrays of non-POD types were always
                                          >>default-constructed?
                                          >
                                          > That is the case.
                                          >
                                          > Indeed uBLAS unbounded_array are now as Toon described. Dynamicly sized
                                          > equivalents of a C array.
                                          >
                                          > Both types are 'uninitialised' in that their element are 'value_type', as
                                          > opposed to 'value_type()' constructed. This only makes a difference for POD.
                                          > If the compiler supports array placement new then the construction of
                                          > unbounded_array can be implemented optimally. If it doesn't then it depends
                                          > on how well it can optimise away a loop of do nothing placement new
                                          > constructors.

                                          But I wonder why it is necessary to call placement-new after the
                                          'allocate' call on the allocator. The allocator will create the elements
                                          so I see no need to do this again using the placement-new.

                                          toon
                                        • Michael Stevens
                                          Hi Toon, ... If the value_type is POD then the placement-new should be a do nothing and theoretically unnecessary. For other types the placement-new is
                                          Message 20 of 23 , Oct 11, 2004
                                          • 0 Attachment
                                            Hi Toon,

                                            On Monday 11 October 2004 13:26, Toon Knapen wrote:
                                            >
                                            > But I wonder why it is necessary to call placement-new after the
                                            > 'allocate' call on the allocator. The allocator will create the elements
                                            > so I see no need to do this again using the placement-new.

                                            If the value_type is POD then the placement-new should be a do nothing and
                                            theoretically unnecessary. For other types the placement-new is necessary as
                                            allocate simple return a point to uninitialised memory.

                                            I say theoretically unnecessary because in theory it could be avoided using
                                            something like is_POD from type traits. In pratice there is probably no gain
                                            (since the do nothing operation can be optimised away) and it makes us
                                            dependant on a library function with associated compiler compatibility
                                            problems.

                                            Michael
                                          • Toon Knapen
                                            ... The standard suggests that the allocate call calls placement new itself to construct the element so the allocator does do all the necessary work for
                                            Message 21 of 23 , Oct 11, 2004
                                            • 0 Attachment
                                              Michael Stevens wrote:
                                              > Hi Toon,
                                              >
                                              > On Monday 11 October 2004 13:26, Toon Knapen wrote:
                                              >
                                              >>But I wonder why it is necessary to call placement-new after the
                                              >>'allocate' call on the allocator. The allocator will create the elements
                                              >>so I see no need to do this again using the placement-new.
                                              >
                                              >
                                              > If the value_type is POD then the placement-new should be a do nothing and
                                              > theoretically unnecessary. For other types the placement-new is necessary as
                                              > allocate simple return a point to uninitialised memory.
                                              >
                                              > I say theoretically unnecessary because in theory it could be avoided using
                                              > something like is_POD from type traits. In pratice there is probably no gain
                                              > (since the do nothing operation can be optimised away) and it makes us
                                              > dependant on a library function with associated compiler compatibility
                                              > problems.

                                              The standard suggests that the allocate call calls placement new itself
                                              to construct the element so the allocator does do all the necessary work
                                              for non-pod types too. If not, there would be no difference between
                                              malloc and an allocator IMO!
                                            • Michael Stevens
                                              ... No that cannot be! STL Allocators return pointers to uninitialised memory. That is their job, they allow containers to decouple allocation from
                                              Message 22 of 23 , Oct 11, 2004
                                              • 0 Attachment
                                                On Monday 11 October 2004 15:10, Toon Knapen wrote:
                                                > Michael Stevens wrote:
                                                > > Hi Toon,
                                                > >
                                                > > On Monday 11 October 2004 13:26, Toon Knapen wrote:
                                                > >>But I wonder why it is necessary to call placement-new after the
                                                > >>'allocate' call on the allocator. The allocator will create the elements
                                                > >>so I see no need to do this again using the placement-new.
                                                > >
                                                > > If the value_type is POD then the placement-new should be a do nothing
                                                > > and theoretically unnecessary. For other types the placement-new is
                                                > > necessary as allocate simple return a point to uninitialised memory.
                                                > >
                                                > > I say theoretically unnecessary because in theory it could be avoided
                                                > > using something like is_POD from type traits. In pratice there is
                                                > > probably no gain (since the do nothing operation can be optimised away)
                                                > > and it makes us dependant on a library function with associated compiler
                                                > > compatibility problems.
                                                >
                                                > The standard suggests that the allocate call calls placement new itself
                                                > to construct the element so the allocator does do all the necessary work
                                                > for non-pod types too. If not, there would be no difference between
                                                > malloc and an allocator IMO!

                                                No that cannot be! STL Allocators return pointers to uninitialised memory.
                                                That is their job, they allow containers to decouple allocation from
                                                construction.
                                                The default allocator is defined (20.4.1.1) to use '::new(size_type) ' to
                                                allocate memory.

                                                Michael
                                              Your message has been successfully submitted and would be delivered to recipients shortly.