[Bug rtl-optimization/16893] New: function parameters are valid in caller-context ... but turn up invalid (0x0) in callee-context

["caelian at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>]

I am providing as much information as i can gather gcc -v output in my case
isn't as verbose as desired.

% gcc -v
Using built-in specs.
Configured with: FreeBSD/i386 system compiler
Thread model: posix
gcc version 3.4.2 [FreeBSD] 20040728

problem is confirmed by at least 2 other people one running a 3.3.4 gcc (on i
think linux)

THe problem is in WindowMaker source-code in an unfortunately extrmely large
function wManageWindow which eventually calls wNETWMPositionSplash.

the parameters x and y (which are both of type int) get passed to
wNETWMPositionSplash by reference but never seem to "actually make it there"

IRC-log of debug-session follows:
Caelian	ok ... i am starting to go insane here
	just set a breakpoint on wNETWMPositionSplash instead of wManageWindow
	Breakpoint 2, wNETWMPositionSplash (wwin=0x8227900, x=0x0, y=0x0)
	at wmspec.c:1147
	1147 {
	(gdb) up
	#1 0x0808c2c1 in wManageWindow (scr=0x80ce800, window=6291459)
	at window.c:1251
	1251 wNETWMPositionSplash(wwin, &x, &y);
	(gdb) print x
	$13 = 488
	(gdb) print &x
	$14 = (int *) 0xbfbfe860
	why is x and &x a valid address in the context of wManageWindow .... but 	not
in wNETWMPositionSplash ??
	(same goes for y and &y)

        <snip>

	just to be sure ... i am not being insane for expecting those x and y
	variables to have matching addresses in both function contexts there ...
	am i ?
<<ratmice running valgrind>>
ratmice	spooky, no i I think that would be a sane assessment
	==13189== Invalid read of size 4
	==13189== at 0x80902E9: wNETWMPositionSplash (wmspec.c:1152)
	==13189== Address 0x4 is not stack'd, malloc'd or free'd
Caelian	ratmice: that is indeed the offending *x = ..... line trying to modify 
	the sudden 0x0 pointer
	though that should not BE a 0x0 pointer since if i go UP 1 context ... 
	the parameter suddenly is perfectly valid
	btw ... compiling with -O instead of the default -O2 doesn't solve it
	either
norwoodites	try -O2 -fno-strict-aliasing
	if that works either the source code has an aliasing bug (most likely) 
	or there is a bug in GCC's aliasing code (less likely)

IRC-log goes on for a while still ...  short summary.

-fno-stricy-aliasing and -fno-loop-optimize (both suggested by norwoodites)
don't seem to alleviate the problem.

norwoodites suggested posting a bugreport ... so this is it.

-- 
           Summary: function parameters are valid in caller-context ... but
                    turn up invalid (0x0) in callee-context
           Product: gcc
           Version: 3.4.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: rtl-optimization
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: caelian at gmail dot com
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i386-freebsd5.2
  GCC host triplet: i386-freebsd5.2
GCC target triplet: i386-freebsd5.2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16893