Conference turris::decc

What should P_right and P_left be set to if
	(fl[i][j-1] == 4) is true and
((fl[i-1][j] == 2) || (fl[i-1][j] == 3)) is false and
((fl[i+1][j] == 2) || (fl[i+1][j] == 3)) is false?

Or can you be sure this never happens?

We sometimes hear reports of this type of runtime differences due to the use of
a different compiler or different compiler options. Although we have seen some
optimization bugs in the compiler, many of the runtime errors have been due to
latent bugs in the source code. We are very interested in helping find out if
this is a compiler or a source code problem. Helping with migration problems
from other UNIXes or prior versions of Digital UNIX is a high priority for us.

There are a few notes in here that describe why non-conforming C prgrams that
used to "work" on other UNIXes now will fail using DEC C on Digital UNIX. I'll
see if I can dig up a pointer to one or two... 

Having said that, here are a couple of things that you might try. We would do
this on our side, but we would probably need the standalone program and the
expected results.

1) Try -noansi_alias if you are compiling -std/-std1 to see if the problem "goes
away". This is not applicable if compiling in -std0 (K&R mode), which is the
default for the V4.0B compiler.

2) Check the cc man page. This describes the differences in optimization levels
for both 'cc -migrate' and 'cc -new' (both are DEC C, but the optimization and
tuning differs). Try running the same test at lower optimizations to see if the
problem "goes away".

3) Try instrumenting the program with atom third degree. See man atom, man
third. This is a "Purify" like  memory verifier that will check for overwrites
or uninitialized data at runtime. This is usually the most useful tool in
finding latent bugs that happen to surface on Digital UNIX (but were hidden on
other O/Ses).

See also
   http://www.zk3.dec.com/dude/program_analysis/

and section 7 of the Programmer's Guide 
   http://www.zk3.dec.com/~binder/platinum/AA-PS30D-TET1_html/peg8.html


Let us know what you find out after trying the above.

-Jeff

Can you supply the full cc command line you are using?

Hi,

I tried several things. 

The compiler options where very simple
cc -<compiler> -c source1.c
cc -<compiler> -c source2.c
cc -o object source1.o source2.o

And <compiler> was -oldc or -newc or -migrate
-oldc gave correct results (aka same results as other compilers)
-migrate gave wrong results
-newc produces segmentation violation

Using lower optimization levels did not result in different answers.

As said in .1 P-left and P-right where uninitialised.

Making them "static" made the -migrate produce the "correct" results.
This solved the customers problem. Now he is testing in the real program. 
The test case also introduces the crash with newc but in the original code 
it does not crash.

He aggreed it was an C source code error and he was glad our compiler found
it.
He could not tell me for sure the other compilersproduced real good results.

Now he will use Third to search for other problems. And I am pretty sure
we will sell at least 2 new workstations in this new account. 

Thanks.  
[Posted by WWW Notes gateway]

> Making them "static" made the -migrate produce the "correct" results.
> This solved the customers problem. 

I hope he doesn't think this is the proper solution!  That just means
that when the routine neglects to set P_left and P_right it will use
some leftover value from the previous call.  While that should get the
same value with every compiler (except for the very first call), there's
nothing in the physics to justify that choice -- especially if the
previous call differed in both i and j!

More likely, he wants to structure it something like this, to be sure
that each variable gets an appropriate value:


      if((fl[i-1][j] == 2) || (fl[i-1][j] == 3)) {
          P_right = pres[i+1][j];
          P_left = pres[i][j];
      }
      else if((fl[i+1][j] == 2) || (fl[i+1][j] == 3)) {
          P_right = pres[i][j];
          P_left = pres[i-1][j];
      }
      else {
          P_right = 0.5 * (pres[i+1][j  ] + pres[i  ][j  ]);
          P_left = 0.5 * (pres[i-1][j  ] + pres[i  ][j  ]);
      }

      if(fl[i][j-1] == 4) {
          P_top = pres[i][j+1];
          P_bot = pres[i][j  ];
      }
      else {
          P_top = 0.5 * (pres[i  ][j+1] + pres[i  ][j  ]);
          P_bot = 0.5 * (pres[i  ][j-1] + pres[i  ][j  ]);
      }

      dP_dz[i][j] = (P_top - P_bot) / DZ;
      dP_dr[i][j] = (P_right - P_left) / DR;

Just a very minor point.

>I hope he doesn't think this is the proper solution!  That just means
>that when the routine neglects to set P_left and P_right it will use
>some leftover value from the previous call.  While that should get the
>same value with every compiler (except for the very first call), there's
                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>nothing in the physics to justify that choice -- especially if the
>previous call differed in both i and j!

For the very first call, wouldn't they contain zeros for all compilers?
In other words, aren't the two declarations below equivalent:

static int	j;
static int	j = 0;

Section 3.5.7 (ANSI version) Initialization requires this.

Andy V

Yes, all static variables (local or file scope) are implicitly zero initialized.