Both ICC and Sun's lint are very good at finding variables that are
set but never used. The last batch of commits from me is all from
ICC's digging.
I'm working on quieting most of ICC's warnings, so that only the good
ones shine through. We'll have some tremendous tools at our disposal
I've spent much of this morning off and on working on ICC configs. I
think I've got some decent hints going on in the file.
The valgrind problems I've been finding happen with the ICC-compiled
version of Parrot, too. We can't blame everything on GCC
optimization. I think GCC just aggrav
Here's how I got it going. It's the -no-cxxlib that was crucial.
Note that we don't use GCC anywhere in here.
ICC='/opt/intel/cce/10.0.023'
CC="$ICC/bin/icc -no-cxxlib"
# Turn off certain warnings
CCFLAGS="$CCFLAGS -wd810" # conversion from "x" to "y" may lose
significant bits
CCFLAGS="
On 30/06/07, Andy Lester <[EMAIL PROTECTED]> wrote:
>
> perl Configure.pl --cc=icc --link=icc --ld=icc
> --ccflags=-I/opt/intel/compiler91/include/
Even with this, I get complaints that:
icc: error #10001: could not find directory in which the set of
libstdc++ include files resides
I've app
chromatic wrote:
> In theory, this patch should apply and run cleanly. It doesn't.
>
> Thus, something somewhere pokes into memory it shouldn't.
>
> Any ideas? Alternately, any comments on this analysis?
I think adding memory checks is a brilliant idea, especially because
memory is sometimes r
On Thursday 05 July 2007 19:58:50 Patrick R. Michaud wrote:
> I also get segfaults after applying this patch.
>
> However, if I change the patch such that the "size_t sentinel;"
> line goes at the end of the struct PMC instead of the beginning,
> then everything appears to compile and run.
>
> In
