[petsc-dev] different compiler behavior in make libfast and make all

[Barry Smith]

  Many years ago files in these directories use to break many different compilers with optimization; over the years most compilers got better and were able to handle these files. Looks like Microsoft compilers have regressed in some way and can no longer handle them.

  Barry

On Sep 9, 2013, at 8:03 PM, Chetan Jhurani <chetan.jhurani at gmail.com> wrote:

> An update on this issue for future searches:
> 
> I am able to reproduce this bug outside cygwin and outside
> petsc make/build system for a single petsc file
> (sbaijfact2.c) after configuring petsc in the usual manner.
> 
> Note: scalar = complex<double>.
> 
> It is a bug in cl.exe in two versions I tested: VS 2012 x64 on
> windows 7 x64 without VS updates (compiler version 17.00.50727.1)
> and with latest update number 3  (compiler version 17.00.60610.1).
> 
> The error is not deterministic even if cl.exe is restricted
> to run on 1 out of 4 cores for compiling a single file.
> Otherwise cl.exe uses 4 threads and still dies due to
> similar internal errors.  (I thought perhaps the single-threaded
> invocation will fix this, but no...) The petsc source line
> numbers reported in the crash are also not same in
> different single-threaded cl.exe runs.
> 
> The error happened in roughly 10% of 100 consecutive
> compilations of the file.  Happens with -O1 and -O2.
> But no error when optimization is off.  Although I
> have not gone so far as having a minimal workaround, two
> possible solutions are to have optimization off for select
> functions in a few files using #pragma or just turn off
> optimizations for three directories where such errors
> happened -
> 
> src/mat/impls/sbaij/seq/sbstream
> src/mat/impls/sbaij/seq
> src/mat/impls/baij/seq
> 
> Chetan
> 
> On Thu, Sep 5, 2013 at 8:53 PM, Satish Balay <balay at mcs.anl.gov> wrote:
> >
> > On Thu, 5 Sep 2013, Chetan Jhurani wrote:
> >
> > > Thanks.  I will try it.  An additional question - how does one turn off
> > > optimization for a specific directory?  If I give an argument to
> > > "CFLAGS =" in, say mat/impls/baij/seq/makefile, will it append
> > > or override?
> >
> > Flags sepcified with CFLAGS will get appended to the current compile
> > command.
> >
> > If you need to replace some stuff in the target - you should look at
> > PETSC_ARCH/conf/petscvariables - and check which variable you would
> > like to reset.
> >
> > In this case - you might want to replace values of CC_FLAGS
> >
> > Satish
> >
> > >  I just want to play with optimization flags.  This will
> > > not turn off optimization for a specific file but will be good to know.
> > >
> > > Also, one more observation is that when I turned on procmon (somewhat
> > > similar to strace) when compiling the full tree, then the failure
> > > happened in a different file.  So not quite consistent as I had mentioned
> > > earlier.
> > >
> > > Procmon slows down the system and can also lead to differences in clock or
> > > execution speed.  I can't be very sure about this but if the optimizer part
> > > of compilation is time-sensitive (don't optimize for a very long
> > > time, or choose optimization based on some previous time measurements), then
> > > a bug might not be encountered always.  Just a wild guess, especially since
> > > these directories typically take longer to compile because of many manually
> > > unrolled loops in there.
> > >
> > > Chetan
> > >
> > > > -----Original Message-----
> > > > From: Barry Smith [mailto:bsmith at mcs.anl.gov]
> > > > Sent: Thursday, September 05, 2013 6:53 PM
> > > > To: Chetan Jhurani
> > > > Cc: 'petsc-dev'
> > > > Subject: Re: [petsc-dev] different compiler behavior in make libfast and make all
> > > >
> > > >
> > > >   cygwin is a temperamental beast. I don't think the compiler is to blame but rather cygwin mis-
> > > > providing something when many files are being dealt with quickly.
> > > >
> > > >    make all simply calls make ACTION=libfast tree
> > > >
> > > >    When make all fails you can go down to the place it crashes and run make ACTION=libfast tree and it
> > > > will finish compiles in all the directories under that current directory. So you can get everything
> > > > compiled with hopefully not too many manual makes needed.  I know this is not particularly
> > > > satisfactory by we still dream about a knight coming along in shining armor with lots of Windows
> > > > experience figuring out a clean and simple way to avoid cygwin completely in the build process.
> > > >
> > > >    Barry
> > > >
> > > >
> > > > On Sep 5, 2013, at 6:16 PM, Chetan Jhurani <chetan.jhurani at gmail.com> wrote:
> > > >
> > > > > I'm looking for suggestions on how to understand different compiler
> > > > > behavior in make "libfast" in a sub-directory and make "all" in
> > > > > top-level petsc directory.
> > > > >
> > > > > The reason is that make all leads to an internal compiler error, seen
> > > > > in make.log.  But doing make libfast for the same arch in the corresponding
> > > > > subdirectory works fine.  So it is hard to work around the internal
> > > > > compiler error via some simplification.  This is with cygwin and visual
> > > > > studio 2012.  The same petsc code compiles fine with an older visual studio.
> > > > >
> > > > > Here is an example of the error from make.log, which
> > > > > consistently happens here for a particular arch.
> > > > >
> > > > > petsc34\src\mat\impls\sbaij\seq\sbaij2.c(854) : fatal error C1001: An internal error has occurred in
> > > > the compiler.
> > > > > (compiler file 'f:\dd\vctools\compiler\utc\src\p2\main.c', line 211)
> > > > > To work around this problem, try simplifying or changing the program near the locations listed
> > > > above.
> > > > > Please choose the Technical Support command on the Visual C++
> > > > > Help menu, or open the Technical Support help file for more information
> > > > > INTERNAL COMPILER ERROR in 'C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\BIN\amd64\cl.exe'
> > > > >
> > > > > The error happens in a different location (again consistently)
> > > > > for a different arch.
> > > > >
> > > > > petsc34\src\mat\impls\sbaij\seq\sbstream\sbstrmfact.c(434)
> > > > >
> > > > > Both errors don't get reproduced if I do a make libfast in these
> > > > > directories.  I also invoked the compiler via cl and win32fe
> > > > > and both these ways also work fine and generate object files of
> > > > > non-zero sizes.
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Chetan
> > > > >
> > > > >
> > >
> > >
> >