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

[Satish Balay]

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
> > >
> > >
> 
>