On Thu, 2006-10-26 at 17:20 -0500, Aaron Griffin wrote:
On 10/26/06, K. Piche <kevin.piche@cgi.com> wrote:
The wierd thing is that ctl is not modified by log_progress. The only explanation I can think of besides a compiler optimization bug is that log_progress accesses the fsz variable which is just before the ctl variable in main. Moving the variable may fix it or refactoring the code in socket_wait to get different assembler output.
This is a close as anything could possibly come to modifying ctl, but in this case it's just being silly and preventing compier warnings, I'd assume.
src/pacman/download.c /* we don't need that parameter */ ctl=NULL;
Just in case the compiler decides to do-something-it-shouldn't, could you try switching this to a: /* we don't need that parameter */ (void)ctl;
That's as close as I can get
_______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://www.archlinux.org/mailman/listinfo/pacman-dev
I commented the ctl=NULL to no effect. Halfway stepping through log_progress ctl gets optimized away which somehow affects the caller which it obviously shouldn't. I tried playing around with the do {} while loop to hopefully get different code generation to no avail. Since log_progress always returns 1 the loop can become: if (stuff) break; blah ctl->idlecb(blah) } while (1) But ctl still disappears. Compiling with -O1 works as a workaround. k