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

Re: [ublas-dev] Fix for construction problem

Expand Messages
  • 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 1 of 23 , Oct 1, 2004
      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 2 of 23 , Oct 1, 2004
        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 3 of 23 , Oct 1, 2004
          > 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 4 of 23 , Oct 1, 2004
            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 5 of 23 , Oct 1, 2004
              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 6 of 23 , Oct 1, 2004
                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 7 of 23 , Oct 1, 2004
                  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 8 of 23 , Oct 1, 2004
                    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 9 of 23 , Oct 1, 2004
                      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 10 of 23 , Oct 1, 2004
                        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 11 of 23 , Oct 1, 2004
                          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 12 of 23 , Oct 1, 2004
                            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 13 of 23 , Oct 4, 2004
                              --- 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 14 of 23 , Oct 7, 2004
                                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 15 of 23 , Oct 8, 2004
                                  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 16 of 23 , Oct 8, 2004
                                    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 17 of 23 , Oct 8, 2004
                                      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 18 of 23 , Oct 11, 2004
                                        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 19 of 23 , Oct 11, 2004
                                          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 20 of 23 , Oct 11, 2004
                                            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 21 of 23 , Oct 11, 2004
                                              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.