Perftools 1.5 will not compile on x86_64

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Install perftools on openSuse 11.2 (x86_64)
2. Run configure --enable-frame-pointers
3. Run make check

What is the expected output? What do you see instead?
Successful compilation of perftools.

src/tests/debugallocation_test.cc(240): error: array is too large
    IF_DEBUG_EXPECT_DEATH(b = new char[kTooBig],                 
    ^                                                            

src/tests/debugallocation_test.cc(250): error: array is too large
    IF_DEBUG_EXPECT_DEATH(b = new char[kAlsoTooBig], "Unable to
allocate.*new failed");
    ^                                                                     

compilation aborted for src/tests/debugallocation_test.cc (code 2)

What version of the product are you using? On what operating system?
version 1.5 on openSuse 11.2 (x86_64)

Please provide any additional information below.

The output from './configure' is attached in the file conf.txt and the
output from 'make check' is attached in the file make.txt.

Original issue reported on code.google.com by rawl...@sci.utah.edu on 8 Apr 2010 at 9:08

Attachments:

• conf.txt
• make.txt

[GoogleCodeExporter]

Cc-ing someone else on this bug, who had the same problem.  It was with icc, 
which it 
looks like you're also using.  I don't think the compiler is supposed to 
complain 
about a memory allocation that fits inside a size_t, though icc is choosing to 
do so.  
I don't know if this is a bug in icc, or (more likely) a lack of understanding 
on my 
part.

Here's the last message Gregory got from the icc folks, that I know of.  I 
don't know 
if anything has happened since.
---
***** Follow-up submitted on 2/16/2010 4:40:08 PM ***** Hi Gregory,

Since Bernth is on vacation this week I'll try to help.
I've no access to the project, so I constructed a small testcase that
obviously reproduces the problem (at least the 'array too long' one).
In my testcase, both g++ and icc abort with an exception when trying
to allocate an unsigned long (which is size_t) and in my mind this is
correct behavior of the compilers. However, I tested the testcase also
on another 64-bit environment and the exception didn't occur, just the
'tool long' error.

This is my testcase:

-bash-3.1$ cat staticcast1.cpp
#include <iostream>
#include <ostream>

int main()
{
const size_t kTooBig = ~static_cast<size_t>(0);
  ::std::cout << kTooBig << '\n';
  char *b = new char[kTooBig];
}

-bash-3.1$ g++ staticcast1.cpp;./a.out
18446744073709551615
terminate called after throwing an instance of 'std::bad_alloc'
  what():  St9bad_alloc
Aborted
-bash-3.1$
-bash-3.1$
-bash-3.1$
-bash-3.1$ icc staticcast1.cpp;./
a.out
staticcast1.cpp(8): error: array is too large
    char *b = new char[kTooBig];
                      ^

compilation aborted for staticcast1.cpp (code 2)
18446744073709551615
terminate called after throwing an instance of 'std::bad_alloc'
  what():  St9bad_alloc
Aborted
-bash-3.1$

I'm not aware of any limitations on allocating dynamic memory, since
the allocation is done onruntime, but I think, unsinged long is really
to big to be allocated (in my mind). But let me investigatie if I'm
right.
"""

Original comment by csilv...@gmail.com on 9 Apr 2010 at 3:15

• Added labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

btw, this problem is just with the unittest, not with any code that you would 
actually 
use.  Feel free to use 'make -k' to build and run all the other tests, if you'd 
like, 
or to just use the resulting libraries.

Original comment by csilv...@gmail.com on 9 Apr 2010 at 3:15

[GoogleCodeExporter]

I compiled with gcc and g++ without any problems.  Thanks!

Original comment by rawl...@sci.utah.edu on 9 Apr 2010 at 5:15

[GoogleCodeExporter]

Glad to hear it.  I still would like to figure out what's going on with icc, 
but I'm 
glad you have a good workaround in the meantime.

Original comment by csilv...@gmail.com on 9 Apr 2010 at 8:23

[GoogleCodeExporter]

I'm going to close this WontFix, since it seems like a bug in icc, not 
perftools.  If enough people are bitten by it, I guess I could put in a 
compiler-based #ifdef or something.

Original comment by csilv...@gmail.com on 2 Aug 2010 at 4:44

• Changed state: WontFix