gcc 2.95.2 -O9 int <--> long long bug?

[Cynbe ru Taren <cynbe at muq dot org>]

Dunno if this is a known issue or what, but there appears to be
a gcc 2.95.2 issue with implicit long long <--> int conversions
at optimization level -O9.

Here is a sample program for reproducing the problem:

    #include <stdio.h>
    #include <sys/types.h>
    #include <sys/stat.h>
    #include <fcntl.h>

    int  vopen(const unsigned char* file,int line,const unsigned char* name,int mode );

    #define vmopen(x,y) vopen(__FILE__,__LINE__,x,y)

    int
    vopen(
	const unsigned char* file,
	      int     line,
	const unsigned char* name,
	      int     mode
    ){
	int fd = open(name,mode);
	/* This wrapper gives us a central place */
	/* to add debugging logic or such.       */
	printf("%s.%d: vopen(%s,%d) = %d...\n",file,line,name,mode,fd);
	return fd;
    }

    void
    dbDuplicate(
	void
    ) {
	long long   fd;
	unsigned char  buf[ 256 ];

	strcpy( buf, "touch mytest.tmp" );
	system(buf);
	strcpy( buf, "mytest.tmp" );

	if ((fd = vmopen( buf, O_RDONLY)) >= 0) {

	    close( fd );
	    printf("mytest.tmp FOUND\n");
	} else {
	    printf("mytest.tmp LOST\n");
	}
    }

    int
    main( int argc, char** argv ) {
      dbDuplicate();
    }


Here is a demo of compiling and running the above program,
showing different results at -O2 vs -O9 optimization:

    cynbe@chee home/cynbe> gcc --version
    2.95.2
    cynbe@chee home/cynbe> uname -a
    Linux chee 2.2.14 #6 SMP Mon Apr 24 22:37:20 PDT 2000 i586 unknown
    cynbe@chee home/cynbe> ls -l mytest.tmp
    -rw-r--r--    1 cynbe    cynbe           0 Sep 10 12:01 mytest.tmp
    cynbe@chee home/cynbe> gcc -g -O2 z.c -o z
    cynbe@chee home/cynbe> ./z
    z.c.35: vopen(mytest.tmp,0) = 3...
    mytest.tmp FOUND
    cynbe@chee home/cynbe> gcc -g -O9 z.c -o z
    cynbe@chee home/cynbe> ./z
    z.c.35: vopen(mytest.tmp,0) = 3...
    mytest.tmp LOST
    cynbe@chee home/cynbe> gcc -g -O2 z.c -o z
    cynbe@chee home/cynbe> ./z
    z.c.35: vopen(mytest.tmp,0) = 3...
    mytest.tmp FOUND
    cynbe@chee home/cynbe> gcc -g -O9 z.c -o z
    cynbe@chee home/cynbe> ./z
    z.c.35: vopen(mytest.tmp,0) = 3...
    mytest.tmp LOST
    cynbe@chee home/cynbe> 

This behavior is at the least unintuitive, and worthy of a warning
message, should it be for some reason considered correct.

 -- Cynbe