Re: GCC behaviour fault

[Jarl Friis <jarl at diku dot dk>]

On 12 Nov 1999, Alexandre Oliva wrote:

> On Nov 12, 1999, Jarl Friis <jarl@diku.dk> wrote:
> 
> > But what shall I do when the compiler compiles my program but does it
> > faulty!
> 
> Submit a program that tests the expected behavior and abort()s if it
> finds unexpected behavior.
I have made a short program that demonstrates the bahaviour, but strange
things must be done to provoke it.

To me it seems that a referencecounter for a valarray seem to be mixed
with the objects. This is just a guess, and might be misleading.

> 
> > I can demonstrate different behaviour, though not in a short program.
> 
> How long is ``not short''? :-)

I succeded in localising the behaviour. So a short program is attached,
included is also the output from my command:
g++ -Wall -v simple.cc

Jarl
Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/specs
gcc version 2.95.2 19991024 (release)
 /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/cpp -lang-c++ -v -D__GNUC__=2 -D__GNUG__=2 -D__GNUC_MINOR__=95 -D__cplusplus -D__ELF__ -Dunix -D__i386__ -Dlinux -D__ELF__ -D__unix__ -D__i386__ -D__linux__ -D__unix -D__linux -Asystem(posix) -D__EXCEPTIONS -Wall -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ -Di686 -Dpentiumpro -D__i686 -D__i686__ -D__pentiumpro -D__pentiumpro__ simple.cc /tmp/ccbtYRJa.ii
GNU CPP version 2.95.2 19991024 (release) (i386 Linux/ELF)
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/../../../../include/g++-3
 /usr/local/include
 /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/../../../../i686-pc-linux-gnu/include
 /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/include
 /usr/include
End of search list.
The following default directories have been omitted from the search path:
End of omitted list.
 /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/cc1plus /tmp/ccbtYRJa.ii -quiet -dumpbase simple.cc -Wall -version -o /tmp/ccaRBaal.s
GNU C++ version 2.95.2 19991024 (release) (i686-pc-linux-gnu) compiled by GNU C version 2.95.2 19991024 (release).
 as -V -Qy -o /tmp/cc8zpZSs.o /tmp/ccaRBaal.s
GNU assembler version 2.9.1 (i386-redhat-linux), using BFD version 2.9.1.0.23
 /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/collect2 -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 /usr/lib/crt1.o /usr/lib/crti.o /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/crtbegin.o -L/usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.2 -L/usr/local/lib /tmp/cc8zpZSs.o -lstdc++ -lm -lgcc -lc -lgcc /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/crtend.o /usr/lib/crtn.o
#include <valarray>
#include <iostream>

typedef int N;

int main(){
  
  N v[] = {11,22,33};
  N dest[] = {0,0,0};
  valarray<N> va(v, 3);
  valarray<N> destv1(dest, 3);
  valarray<N> destv2(dest, 3);

  slice s(0,1,1);
  /* BUG1: this will not even parse: */
  //  cout << (valarray<N>(valarray<N>(va[s])))[0] << endl;


  /* BUG2: The big bad bug */
  /* This strange (though legal) outputiing is to provoke the bug */
  cout << valarray<N>(valarray<N>(va[s]))[0] << endl;
  cout << valarray<N>(valarray<N>(valarray<N>(va[s])))[0] << endl;
  cout << valarray<N>(valarray<N>(valarray<N>(valarray<N>(va[s]))))[0] << endl;
  
  /* This demonstrates the faulty behaviour */
  destv1[s] = valarray<N>(va[s]);
  copy(&va[0],&va[1],&destv2[0]);
  cout << "source :";
  for(int i = 0; i < 3; i++){
    cout << va[i] << "\t" << flush;
  }
  cout << endl;
  cout << "destv1 :";
  for(int i = 0; i < 3; i++){
    cout << destv1[i] << "\t" << flush;
  }
  cout << endl;
  cout << "destv2 :";
  for(int i = 0; i < 3; i++){
    cout << destv2[i] << "\t" << flush;
  }
  cout << endl;
  if(destv1[0] != destv2[0]){
	/* THIS CANNOT HAPPEND */
	cout << "THIS CANNOT HAPPEND" << endl;
	abort();
      }
  

}