[GCC-XML] opteron, operator new(unsigned int)
DaveFairtex at aim.com
Thu Jul 21 15:20:47 EDT 2005
I ran the preprocessor as you suggested.
The very first mention of "operator new" in the preprocessed output is
actually the one that's causing the error. In my input, I see at line
#84 in /usr/include/c++/4.0.0/new, the following line:
void* operator new(std::size_t) throw (std::bad_alloc)
And that's exactly where the first gccxml error is being reported.
It appears to me that somehow, built into gccxml, operator new is
hardcoded as being defined as operator new(unsigned int) and so when the
<new> include file is loaded, gccxml complains that <new> is doing a bad
thing by changing its definition to a size_t.
Here's the actual error message from gccxml:
In file included from /usr/include/c++/4.0.0/ext/mt_allocator.h:37,
/usr/include/c++/4.0.0/new:84: error: `operator new' takes type `size_t' (`
unsigned int') as first parameter
brad.king at kitware.com wrote:
> David Pare wrote:
>> So I'm trying to use gccxml on my opteron (Linux FC4, gcc 3.2 and 4.0)
>> and it's having trouble with operator new. From what I can tell,
>> gccxml thinks that operator new is defined as "operator new(unsigned
>> int)", while the system include file <new> thinks that operator new
>> should be defined as "operator new(size_t)", which is an unsigned LONG
>> int (probably 8 bytes) on my opteron.
>> I rebuilt gccxml from source to a 64-bit binary, and it still seems to
>> have this difficulty. Is this hardcoded into gccxml? I grepped
>> through the sources for this, but nothing jumped out at me.
>> Any suggestions on what I might do to fix this?
> There may be some preprocessor symbol that is not defined properly. Run
> gccxml with the "-E" option instead of -fxml=... to get the preprocessed
> source the way the parser sees it. Check the definition of operator new
> in this output.
More information about the gccxml