Re: Are we fast yet?
> * Unfortunately Callgrind doesn't save the full stack trace so what you > see is a statistical breakdown for callees. It doesn't necessarily mean > that a call path displayed actually exists deeper than its first level. > But the numbers add-up so this is minor. You might give a try to --num-callers= valgrind's option. -- Sergei signature.asc Description: PGP signature
Re: Endless "declared 'static' but never defined" warnings with stage 2 & 3 compilers
On 2012-06-17, at 11:54 PM, t-rexky wrote: > When I have a moment I will check my target configuration once again and if > this does not help I will spend some time with > a debugger to see if I can figure out where things go wrong. I'm afraid > though that I will get completely lost in the complexity > of gcc. Unfortunately I am not able to use gdb-4.7 in a sensible way since it is having trouble with most of the data types that I need to inspect. However, I spent quite a bit more time with the compiler and I was able to make a small step in the right direction. I discovered that if I rebuild stage 3 with BOOT_CFLAGS="-g -O0", the warnings in stage 3 compiler all disappear! This is despite that fact that the stage 2 compiler was built with -O2 and continues to generate the warnings. I then tried to isolate which specific -O1 optimization flag was responsible for the issue. Unfortunately many recompiles later I determined that the issue arises from gcc -O1 optimization code that is not controlled by any of the flags that -O1 switches on. Recompiling stage 3 with all the optimization flags equivalent to -O1 produces stage 3 compiler that does not generate any of the warnings. So I am baffled and stuck yet again... >> Good luck. >> >> -- >> Vincent Rivière > > Thank you, > t-rexky
Re: Endless "declared 'static' but never defined" warnings with stage 2 & 3 compilers
On 01/07/2012 16:16, t-rexky wrote: I discovered that if I rebuild stage 3 with BOOT_CFLAGS="-g -O0", the warnings in stage 3 compiler all disappear! This is extremely wierd! So it looks like something is affected by the optimization level. Usually, it is an uninitialized variable, buffer overflow, strict aliasing issue, or maybe a GCC bug... Since it is unlikely that this specific bug is in the standard GCC sources (other people would have noticed), maybe it could be somewhere in the C sources added for your NeXT configuration? -- Vincent Rivière
gcc-4.8-20120701 is now available
Snapshot gcc-4.8-20120701 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20120701/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.8 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 189102 You'll find: gcc-4.8-20120701.tar.bz2 Complete GCC MD5=58f4218eb061ab956b1c3700b050db17 SHA1=03a5a738e465dd6b7c2303a6762d85eb98cc5cf2 Diffs from 4.8-20120624 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.8 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Are we fast yet?
On Sun, 1 Jul 2012, Sergei Trofimovich wrote: * Unfortunately Callgrind doesn't save the full stack trace so what you see is a statistical breakdown for callees. It doesn't necessarily mean that a call path displayed actually exists deeper than its first level. But the numbers add-up so this is minor. You might give a try to --num-callers= valgrind's option. Thanks for the tip, but it doesn't seem to help. The reason is that Callgrind's output format only tells you that you call a function X number of times from function Y. So you may only assume that you've reached function Y from any of its callers. Dimitris
