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

[Chetan Jhurani]

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
> > > >
> > > >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130909/cf31323a/attachment.html>