headers
Simon Hill | 1 Oct 2010 09:02
Picon

C++0x development schedule

I'm regularly checking on the GCC implemented C++0x features page
(http://gcc.gnu.org/projects/cxx0x.html).

Is there any way to know what features are under development or an
estimated timeline or feature priority list? Are there development
goals or anything posted on the web?

I'm just trying to figure out the best direction to write my code so I
can avoid as much rework as possible once the features I'm after get
implemented.

The features that will require the most rework are (in order) are:
- constexpr
- template aliases
- inheriting constructors
- extensible literals

I'm already making use of the delegating constructors patch, which is
working fine.

Thanks,
Simon.

BTW many thanks to everyone helping to make GCC the most
feature-complete C++ compiler out there.
Permalink | Reply | 1 comment |
headers
James Cloos | 1 Oct 2010 09:35
Favicon
Gravatar

Intel 80386, version 1 (SYSV) vs Intel 80386, version 1 (GNU/Linux)

I searched through the manuals and googled to no avail.

I tried compiling some stuff on my amd64 box for an ia32 box, using -m32
and and appropriate -march.  The resulting libraries worked fine when
compiled static, but failed when compiled dynamic.

The destination box's executables and libraryies report:

foo: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
     dynamically linked (uses shared libs), for GNU/Linux 2.6.9,
     not stripped

whereas the files generated by my amd64 box report:

bar: ELF 32-bit LSB executable, Intel 80386, version 1 (GNU/Linux),
     dynamically linked (uses shared libs), for GNU/Linux 2.6.9,
     not stripped

In readelf format, that is:

  OS/ABI:                            UNIX - System V
vs:
  OS/ABI:                            UNIX - Linux

I tried using -Wl,--hash-style=sysv, but the libraries and executables
still say Linux rather than SYSV.  (The .o files say SYSV.)

How do I force the former os/abi?

-JimC
(Continue reading)

Permalink | Reply | 4 comments |
headers
Philip Herron | 1 Oct 2010 11:42
Picon
Favicon

Re: C++0x development schedule

On 1 October 2010 08:02, Simon Hill <yacwroy <at> gmail.com> wrote:
> I'm regularly checking on the GCC implemented C++0x features page
> (http://gcc.gnu.org/projects/cxx0x.html).
>
> Is there any way to know what features are under development or an
> estimated timeline or feature priority list? Are there development
> goals or anything posted on the web?
>
>
> I'm just trying to figure out the best direction to write my code so I
> can avoid as much rework as possible once the features I'm after get
> implemented.
>
> The features that will require the most rework are (in order) are:
> - constexpr
> - template aliases
> - inheriting constructors
> - extensible literals
>
> I'm already making use of the delegating constructors patch, which is
> working fine.
>

Not sure if this is the best answer but you could take a look at the
gcc-patches list now and again, look for c++0x tags for the patches
and you will see what people are working on. Otherwise i guess you
could keep doing what your doing now, and or run gcc HEAD.

--Phil
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andy Gibbs | 1 Oct 2010 12:43
Picon
Favicon

Linker error with static data member in templated class

Hi,

I am using gcc 4.4.5 with the c++0x extensions turned on and am having some 
issues defining static variables inside partially specialised template 
classes.  I've put together some fairly straight-forward demonstration code 
as follows:

struct C1
 {
 C1() : i(0)
  { printf("default constructor\n"); }

 C1(const C1& other) = delete;

/*C1(const C1& other) : i(other.i)
  { printf("copy constructor\n"); }*/

 int i;
 };

struct C2
 {
 static C1 op;
 };

template <typename T>
struct C3
 {
 static C1 op;
 };
(Continue reading)

Permalink | Reply | 5 comments |
headers
Vyacheslav Egorov | 1 Oct 2010 13:44

gcc 4.5.1 -fstrict-aliasing and store removal

Hi,

I am experiencing the following problem when compiling V8[1] with gcc
4.5.1 with -O1 -fstrict-aliasing enabled: for some reason GCC removes
one of the stores to memory.

Store removal happens in the method Genesis::HookUpGlobalProxy [2]

void Genesis::HookUpGlobalProxy(Handle<GlobalObject> inner_global,
Handle<JSGlobalProxy> global_proxy) {
  // ...
  inner_global->set_global_context(*global_context());
  // ...
}

 GCC inlines method GlobalObject::set_global_context, which is defined
through macroses ACCESSORS[3] and WRITE_FIELD[4]

  void GlobalObject::set_global_context(Context* value, WriteBarrierMode mode) {
    WRITE_FIELD(this, offset, value);
    CONDITIONAL_WRITE_BARRIER(this, offset, mode);
  }

#define FIELD_ADDR(p, offset) \
  (reinterpret_cast<byte*>(p) + offset - kHeapObjectTag)

#define WRITE_FIELD(p, offset, value) \
  (*reinterpret_cast<Object**≥(FIELD_ADDR(p, offset)) = value)

and removes memory store which should be generated from WRITE_FIELD.
(Continue reading)

Permalink | Reply | 13 comments |
headers
Ian Lance Taylor | 1 Oct 2010 17:41
Picon
Favicon
Gravatar

Re: Intel 80386, version 1 (SYSV) vs Intel 80386, version 1 (GNU/Linux)

James Cloos <cloos <at> jhcloos.com> writes:

> I tried compiling some stuff on my amd64 box for an ia32 box, using -m32
> and and appropriate -march.  The resulting libraries worked fine when
> compiled static, but failed when compiled dynamic.
>
> The destination box's executables and libraryies report:
>
> foo: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
>      dynamically linked (uses shared libs), for GNU/Linux 2.6.9,
>      not stripped
>
> whereas the files generated by my amd64 box report:
>
> bar: ELF 32-bit LSB executable, Intel 80386, version 1 (GNU/Linux),
>      dynamically linked (uses shared libs), for GNU/Linux 2.6.9,
>      not stripped
>
> In readelf format, that is:
>
>   OS/ABI:                            UNIX - System V
> vs:
>   OS/ABI:                            UNIX - Linux
>
> I tried using -Wl,--hash-style=sysv, but the libraries and executables
> still say Linux rather than SYSV.  (The .o files say SYSV.)
>
> How do I force the former os/abi?

It is very unlikely that this is your problem.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Ian Lance Taylor | 1 Oct 2010 17:43
Picon
Favicon
Gravatar

Re: Linker error with static data member in templated class

Andy Gibbs <andyg1001 <at> hotmail.co.uk> writes:

> // Initialise C3::op for type int
> template<> C1 C3<int>::op;

You are using specialization syntax but it seems to me that you want
instantiation syntax, which would be

template C1 C3<int>::op;

Ian
Permalink | Reply | 4 comments |
headers
Ian Lance Taylor | 1 Oct 2010 17:45
Picon
Favicon
Gravatar

Re: gcc 4.5.1 -fstrict-aliasing and store removal

Vyacheslav Egorov <vegorov <at> chromium.org> writes:

> I am experiencing the following problem when compiling V8[1] with gcc
> 4.5.1 with -O1 -fstrict-aliasing enabled: for some reason GCC removes
> one of the stores to memory.
>
> Store removal happens in the method Genesis::HookUpGlobalProxy [2]
>
> void Genesis::HookUpGlobalProxy(Handle<GlobalObject> inner_global,
> Handle<JSGlobalProxy> global_proxy) {
>   // ...
>   inner_global->set_global_context(*global_context());
>   // ...
> }
>
>  GCC inlines method GlobalObject::set_global_context, which is defined
> through macroses ACCESSORS[3] and WRITE_FIELD[4]
>
>   void GlobalObject::set_global_context(Context* value, WriteBarrierMode mode) {
>     WRITE_FIELD(this, offset, value);
>     CONDITIONAL_WRITE_BARRIER(this, offset, mode);
>   }
>
> #define FIELD_ADDR(p, offset) \
>   (reinterpret_cast<byte*>(p) + offset - kHeapObjectTag)
>
> #define WRITE_FIELD(p, offset, value) \
>   (*reinterpret_cast<Object**≥(FIELD_ADDR(p, offset)) = value)
>
> and removes memory store which should be generated from WRITE_FIELD.
(Continue reading)

Permalink | Reply | 12 comments |
headers
Vyacheslav Egorov | 1 Oct 2010 19:49

Re: gcc 4.5.1 -fstrict-aliasing and store removal

> It's pretty hard to say anything conclusive about an incomplete example,

Unfortunately I failed to create a small example illustrating this
optimization.

> but the use of reinterpret_cast and -fstrict-aliasing obviously suggests
> an aliasing violation.
>
> Perhaps you could explain why this is not an aliasing violation?
>

I am pretty sure that this cast violate strict aliasing rules because
we try to treat value of type GlobalObject* as a value of type byte*.
And then we treat a value of type byte* as a value of type Object**.
Neither of this types are compatible as far as I understand.

The question is why this conversions between incompatible pointer
types allows GCC to remove memory stores to some random memory
location it does not know anything about?

In some article about strict aliasing I've read that compiler can
remove the following stores:

inline void init (uint64_t* value, uint32_t hi, uint32_t lo) {
  uint32_t* p = reinterpret_cast<uint32_t>(value);
  p[0] = lo;  // can be optimized out when inlined to mk
  p[1] = hi;  // can be optimized out when inlined to mk
}

uint64_t mk(uint32_t hi, uint32_t lo) {
(Continue reading)

Permalink | Reply | 11 comments |
headers
Ian Lance Taylor | 1 Oct 2010 20:38
Picon
Favicon
Gravatar

Re: gcc 4.5.1 -fstrict-aliasing and store removal

Vyacheslav Egorov <vegorov <at> chromium.org> writes:

> The question is why this conversions between incompatible pointer
> types allows GCC to remove memory stores to some random memory
> location it does not know anything about?
>
> In some article about strict aliasing I've read that compiler can
> remove the following stores:
>
> inline void init (uint64_t* value, uint32_t hi, uint32_t lo) {
>   uint32_t* p = reinterpret_cast<uint32_t>(value);
>   p[0] = lo;  // can be optimized out when inlined to mk
>   p[1] = hi;  // can be optimized out when inlined to mk
> }
>
> uint64_t mk(uint32_t hi, uint32_t lo) {
>   uint64_t result;
>   init(&result, hi, lo);
> }
>
> But I cannot clearly see why compiler can do that nor I can understand
> why it would be beneficial to do so. And the main mystery for me here
> is how to prevent compiler from doing such optimizations.

This example is also incomplete since result is not used.  I'll assume
that it is returned from mk().

The C/C++ language standards say that a store via a pointer whose type
is uint32_t* can not modify a value whose type is uint64_t.  Therefore,
the compiler knows that the assignments to p[0] and p[1] can not modify
(Continue reading)

Permalink | Reply | 10 comments |

Gmane