Another 4.3 c++ question.... (vmware kernel g++ module rebuild issue)

[Tom London]

vmware module rebuild fails with kernel-2.6.25-0.35.rc1.fc9.i686 (and
gcc-c++-4.3.0-0.7.i386?).

The following code from <asm/page.h> compiles fine with gcc but not with g++:

typedef int pteval_t;

struct pte_t {
        pteval_t pte;
        int junk;
};

typedef struct pte_t pte_t;

static inline pte_t native_make_pte(pteval_t val)
{
        return (pte_t) { .pte = val };
}

[tbl@localhost ~]$ g++ -S t.c
t.c: In function 'pte_t native_make_pte(pteval_t)':
t.c:12: error: expected primary-expression before ')' token
t.c:12: error: expected ';' before '{' token
t.c:12: error: expected primary-expression before '.' token
t.c:12: error: expected `;' before '}' token


Has 4.3 g++ changed the acceptability of the "designated initializer"
in the return?

Changing the "dot =" to (obsolete?) "colon" appears acceptable:

static inline pte_t native_make_pte(pteval_t val)
{
        return (pte_t) { pte:val };
}

There is a similar construct in <asm/paravirt.h> :

static inline pte_t __pte(pteval_t val)
{
        pteval_t ret;

        if (sizeof(pteval_t) > sizeof(long))
                ret = PVOP_CALL2(pteval_t,
                                 pv_mmu_ops.make_pte,
                                 val, (u64)val >> 32);
        else
                ret = PVOP_CALL1(pteval_t,
                                 pv_mmu_ops.make_pte,
                                 val);

        return (pte_t) { .pte = ret };
}

Changing to "colon" makes g++ happy.

This an issue with VMware? g++? headers? other?

tom
-- 
Tom London

[Jakub Jelinek]

On Wed, Feb 13, 2008 at 06:53:48AM -0800, Tom London wrote:
>  vmware module rebuild fails with kernel-2.6.25-0.35.rc1.fc9.i686
> (and
>  gcc-c++-4.3.0-0.7.i386?).
>  
>  The following code from <asm/page.h> compiles fine with gcc but not with g++:
>  
>  typedef int pteval_t;
>  
>  struct pte_t {
>          pteval_t pte;
>          int junk;
>  };
>  
>  typedef struct pte_t pte_t;
>  
>  static inline pte_t native_make_pte(pteval_t val)
>  {
>          return (pte_t) { .pte = val };
>  }
>  
>  [tbl@localhost ~]$ g++ -S t.c
>  t.c: In function 'pte_t native_make_pte(pteval_t)':
>  t.c:12: error: expected primary-expression before ')' token
>  t.c:12: error: expected ';' before '{' token
>  t.c:12: error: expected primary-expression before '.' token
>  t.c:12: error: expected `;' before '}' token
>  
>  
>  Has 4.3 g++ changed the acceptability of the "designated initializer"
>  in the return? 
No, if you try g++ 4.1.x, it will fail the same way.
Really, C is not a subset of C++, it is a different language, and this
header is written in C (particularly ISO C99).

Why are you trying to compile vmware with g++ rather than gcc?

	Jakub

[Tom London]

On Wed, Feb 13, 2008 at 7:03 AM, Jakub Jelinek <jakub(a)redhat.com&gt; wrote:
>  On Wed, Feb 13, 2008 at 06:53:48AM -0800, Tom London wrote:
>   > vmware module rebuild fails with kernel-2.6.25-0.35.rc1.fc9.i686 (and
>   > gcc-c++-4.3.0-0.7.i386?).
>   >
>   > The following code from <asm/page.h> compiles fine with gcc but not with
> g++:
>   >
>   > typedef int pteval_t;
>   >
>   > struct pte_t {
>   >         pteval_t pte;
>   >         int junk;
>   > };
>   >
>   > typedef struct pte_t pte_t;
>   >
>   > static inline pte_t native_make_pte(pteval_t val)
>   > {
>   >         return (pte_t) { .pte = val };
>   > }
>   >
>   > [tbl@localhost ~]$ g++ -S t.c
>   > t.c: In function 'pte_t native_make_pte(pteval_t)':
>   > t.c:12: error: expected primary-expression before ')' token
>   > t.c:12: error: expected ';' before '{' token
>   > t.c:12: error: expected primary-expression before '.' token
>   > t.c:12: error: expected `;' before '}' token
>   >
>   >
>   > Has 4.3 g++ changed the acceptability of the "designated initializer"
>   > in the return?
>
>   No, if you try g++ 4.1.x, it will fail the same way.
>   Really, C is not a subset of C++, it is a different language, and this
>   header is written in C (particularly ISO C99).
>
>   Why are you trying to compile vmware with g++ rather than gcc?
>
>          Jakub
>  
Sigh ..... appears that VMWare uses some g++ "down in the module".

I had no problem compiling VMWare modules prior to yesterday, so I'm
guessing some changes to kernel header files exposed this.

Any idea why the old "colon" syntax would appear to still work?  (at
least not complain)? That seems a bit strange.

tom
-- 
Tom London

[Jakub Jelinek]

On Wed, Feb 13, 2008 at 07:08:45AM -0800, Tom London wrote:
>  On Wed, Feb 13, 2008 at 7:03 AM, Jakub Jelinek
> <jakub(a)redhat.com&gt; wrote:
>  > On Wed, Feb 13, 2008 at 06:53:48AM -0800, Tom London wrote:
>  Any idea why the old "colon" syntax would appear to still work?  (at
>  least not complain)? That seems a bit strange. 
C++ standard (C++98, but AFAIK no changes are planned for C++0x) doesn't
have designated initializers, only C99 does.  The g++ front-end supports
very limited subset of the old style designated initializers as a GNU
extension, but nobody wrote support for the C99 designated initializers
as GNU extension for C++ FE.

	Jakub

[Tom London]

On Wed, Feb 13, 2008 at 7:17 AM, Jakub Jelinek <jakub(a)redhat.com&gt; wrote:
>  On Wed, Feb 13, 2008 at 07:08:45AM -0800, Tom London wrote:
>   > On Wed, Feb 13, 2008 at 7:03 AM, Jakub Jelinek <jakub(a)redhat.com&gt; wrote:
>   > > On Wed, Feb 13, 2008 at 06:53:48AM -0800, Tom London wrote:
>
>  > Any idea why the old "colon" syntax would appear to still work?  (at
>   > least not complain)? That seems a bit strange.
>
>   C++ standard (C++98, but AFAIK no changes are planned for C++0x) doesn't
>   have designated initializers, only C99 does.  The g++ front-end supports
>   very limited subset of the old style designated initializers as a GNU
>   extension, but nobody wrote support for the C99 designated initializers
>   as GNU extension for C++ FE.
>
>
>
>          Jakub
>  
Thanks for the help here.

Appears that the issue is that one of the header file "include only
once" macro variables changed names with newer kernel.

I now have enough to push this to vmware ......

Thanks.
   tom
-- 
Tom London