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 <[email protected]> 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:[email protected]] > > > 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 <[email protected]> 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 > > > > > > > > > > > > >
