Ras wrote:That's another thing: O3 is not advised as it can well make the program slower. O2 is the usual optimisation level that doesn't backfire.
I have always seen the opposite ie faster program with -O3. It seems to be the case with Ethereal too, at least on my computer (an old sandybridge, with gcc 6.3 and 7.2 under linux fedora 26 / 27).
Yes, and it would be rather strange if the gcc developers let -O3 enable known "de-optimisations".
Of course any particular optimisation can backfire for a particular program. Experimenting with different optimisation options will not hurt.
I'll get the regular bench with the final PGO build, BUT during the profile-generate stage, I'll get a different bench.
Currently installing gcc7.2 from source on this machine so I can use -fsanitize=undefined...
#WeAreAllDraude #JusticeForDraude #RememberDraude #LeptirBigUltra "Those who can't do, clone instead" - Eduard ( A real life friend, not this forum's Eduard )
That would be because of the patch I pushed yesterday... to allow indexing that array when in check (which means depth could be < 0).
I'm surprised I don't get these errors when I run my program through valgrind / gdb
#WeAreAllDraude #JusticeForDraude #RememberDraude #LeptirBigUltra "Those who can't do, clone instead" - Eduard ( A real life friend, not this forum's Eduard )
AndrewGrant wrote:I'm surprised I don't get these errors when I run my program through valgrind / gdb
Valgrind isn't really useful with local or global variables. gdb doesn't report an error because that access is still within valid memory. I think the access returns 8 because right before that, there is LateMovePruningDepth.
And for O3, I have seen GCC blowing up the program and becoming slower because the bigger program exceeded some CPU caches.
This also has fixed my issue with PGO build differing from nonPGO.
Thank you for taking the time and tracking this down. I'll be sure to mention you when I commit the fix.
If you want actual contribution credits IE submit a PR, that can be done aswell
#WeAreAllDraude #JusticeForDraude #RememberDraude #LeptirBigUltra "Those who can't do, clone instead" - Eduard ( A real life friend, not this forum's Eduard )
AndrewGrant wrote:Thank you for taking the time and tracking this down. I'll be sure to mention you when I commit the fix.
If you want actual contribution credits IE submit a PR, that can be done aswell
If you mean me, please don't bother!
You were going to try -fsantize=undefined anyway as you posted 4 minutes before my post. When I saw that I felt a bit bad that I had not let you discover it yourself! It is quite amazing to have such a tool that easily saves you many hours of debugging.
So the credits should go to the developers of -fsanitize.
AndrewGrant wrote:That would be because of the patch I pushed yesterday... to allow indexing that array when in check (which means depth could be < 0).
I'm surprised I don't get these errors when I run my program through valgrind / gdb
#include <assert.h>
#include <stdlib.h>
#define single_dim_check( a, x ) ( (assert( (x >= 0 ) && (sizeof a / sizeof a[0] > x ) ) )
int main(void)
{
int a[5];
size_t index = 6;
single_dim_check(a,index);
return 0;
}
Taking ideas is not a vice, it is a virtue. We have another word for this. It is called learning.
But sharing ideas is an even greater virtue. We have another word for this. It is called teaching.