gcov and initialized data
I want to use gcov in an embedded type environment. It supports both cold boot and warm boot. For warm boot it does not reload the program from media, instead it 'just' jumps to the start and begins again. Due to support for warm boot, it does not support read-write initialized data. Writable data is initialized at run-time. When you build your program for code coverage (-ftest-coverage -fprofile-arcs), GCC creates some initialized read-write GCOV related data. Has anyone modified GCC to, presumably either under control of a command line option or possibly a configure time option, to initialize such data at run-time instead of compile-time? Thanks. David p.s. In case it matters / anyone cares -- we have copyright assignments on file for GCC, BINUTILS, and GDB, which the company lawyers assure me survived our acquisition by Dell.
Re: gcov and initialized data
On 05/03/2018 01:09 PM, taylor, david wrote: When you build your program for code coverage (-ftest-coverage -fprofile-arcs), GCC creates some initialized read-write GCOV related data. Has anyone modified GCC to, presumably either under control of a command line option or possibly a configure time option, to initialize such data at run-time instead of compile-time? How is this distinct to having to support regular C code such as: int x = 5; ? (I'm guessing the simplest solution would be to post-process the statically linked image to do some kind of run-length compression on its .data section and squirrel that away somewhere that a decompressor can find it early on) nathan -- Nathan Sidwell
Interesting statistics on vectorization for Skylake avx512 (i9-7900) - 8.1 vs. 7.3.
Consider the attached Fortran code (the most expensive routine,
computation-wise, in our weather forecasting model).
verint.s.7.3 is the result of:
gfortran -g -O3 -S -march=native -mtune=native verint.f
using release 7.3.
verint.s.8.1 is the result of:
gfortran -g -O3 -S -march=native -mtune=native verint.f
using the recently released GCC 8.1.
$ wc -l verint.s.7.3 verint.s.8.1
7818 verint.s.7.3
6087 verint.s.8.1
$ grep vfma verint.s.7.3 | wc -l
381
$ grep vfma verint.s.8.1 | wc -l
254
but:
$ grep vfma verint.s.7.3 | grep -v ss | wc -l
127
$ grep vfma verint.s.8.1 | grep -v ss | wc -l
127
and:
$ grep movaps verint.s.7.3 | wc -l
306
$ grep movaps verint.s.8.3 | wc -l
270
Finally:
$ grep zmm verint.s.7.3 | wc -l
1494
$ grep zmm verint.s.8.1 | wc -l
0
$ grep ymm verint.s.7.3 | wc -l
379
$ grep ymm verint.s.8.1 | wc -l
1464
I haven't had the opportunity to test this for speed (is quite
complicated, as I have to build several support libraries with 8.1, like
openmpi, netcdf, hdf{4|5}, fftw ...)
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/
Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
# 1 "/scratch/hirlam/hl_home/MPI/lib/src/grdy/verint.F"
# 1 ""
# 1 ""
# 1 "/scratch/hirlam/hl_home/MPI/lib/src/grdy/verint.F"
c Library:grdy $RCSfile$, $Revision: 7536 $
c checked in by $Author: ovignes $ at $Date: 2009-12-18 14:23:36 +0100 (Fri, 18 Dec 2009) $
c $State$, $Locker$
c $Log$
c Revision 1.3 1999/04/22 09:30:45 DagBjoerge
c MPP code
c
c Revision 1.2 1999/03/09 10:23:13 GerardCats
c Add SGI paralllellisation directives DOACROSS
c
c Revision 1.1 1996/09/06 13:12:18 GCats
c Created from grdy.apl, 1 version 2.6.1, by Gerard Cats
c
SUBROUTINE VERINT (
I KLON , KLAT , KLEV , KINT , KHALO
I , KLON1 , KLON2 , KLAT1 , KLAT2
I , KP , KQ , KR
R , PARG , PRES
R , PALFH , PBETH
R , PALFA , PBETA , PGAMA )
C
C***
C
C VERINT - THREE DIMENSIONAL INTERPOLATION
C
C PURPOSE:
C
C THREE DIMENSIONAL INTERPOLATION
C
C INPUT PARAMETERS:
C
C KLON NUMBER OF GRIDPOINTS IN X-DIRECTION
C KLAT NUMBER OF GRIDPOINTS IN Y-DIRECTION
C KLEV NUMBER OF VERTICAL LEVELS
C KINT TYPE OF INTERPOLATION
C= 1 - LINEAR
C= 2 - QUADRATIC
C= 3 - CUBIC
C= 4 - MIXED CUBIC/LINEAR
C KLON1 FIRST GRIDPOINT IN X-DIRECTION
C KLON2 LAST GRIDPOINT IN X-DIRECTION
C KLAT1 FIRST GRIDPOINT IN Y-DIRECTION
C KLAT2 LAST GRIDPOINT IN Y-DIRECTION
C KPARRAY OF INDEXES FOR HORIZONTAL DISPLACEMENTS
C KQARRAY OF INDEXES FOR HORIZONTAL DISPLACEMENTS
C KRARRAY OF INDEXES FOR VERTICAL DISPLACEMENTS
C PARG ARRAY OF ARGUMENTS
C PALFH ALFA HAT
C PBETH BETA HAT
C PALFA ARRAY OF WEIGHTS IN X-DIRECTION
C PBETA ARRAY OF WEIGHTS IN Y-DIRECTION
C PGAMA ARRAY OF WEIGHTS IN VERTICAL DIRECTION
C
C OUTPUT PARAMETERS:
C
C PRES INTERPOLATED FIELD
C
C HISTORY:
C
C J.E. HAUGEN 1 1992
C
C***
C
IMPLICIT NONE
C
INTEGER KLON , KLAT , KLEV , KINT , KHALO,
IKLON1 , KLON2 , KLAT1 , KLAT2
C
INTEGER KP(KLON,KLAT), KQ(KLON,KLAT), KR(KLON,KLAT)
REALPARG(2-KHALO:KLON+KHALO-1,2-KHALO:KLAT+KHALO-1,KLEV) ,
RPRES(KLON,KLAT) ,
R PALFH(KLON,KLAT) , PBETH(KLON,KLAT) ,
R PALFA(KLON,KLAT,4) , PBETA(KLON,KLAT,4),
R PGAMA(KLON,KLAT,4)
C
INTEGER JX, JY, IDX, IDY, ILEV
REAL Z1MAH, Z1MBH
C
IF (KINT.EQ.1) THEN
C LINEAR INTERPOLATION
C
DO JY = KLAT1,KLAT2
DO JX = KLON1,KLON2
IDX = KP(JX,JY)
IDY = KQ(JX,JY)
ILEV = KR(JX,JY)
C
PRES(JX,JY) = PGAMA(JX,JY,1)*(
C
+ PBETA(JX,JY,1)*( PALFA(JX,JY,1)*PARG(IDX-1,IDY-1,ILEV-1)
+ + PALFA(JX,JY,2)*PARG(IDX ,IDY-1,ILEV-1) )
+ + PBETA(JX,JY,2)*( PALFA(JX,JY,1)*PARG(IDX-1,IDY ,ILEV-1)
+ + PALFA(JX,JY,2)*PARG(IDX ,IDY ,ILEV-1) ) )
C+
+ + PGAMA(JX,JY,2)*(
C+
+ PBETA(JX,JY,1)*( PALFA(JX,JY,1)*PARG(IDX-1,IDY-1,ILEV )
+ + PALFA(JX,JY,2)*PARG(IDX ,IDY-1,ILEV ) )
+ + PBETA(JX,JY,2)*( PALFA(JX,JY,1)*PARG(IDX-1,IDY ,ILEV )
+ + PALFA(JX,JY,2)*PARG(IDX ,IDY ,ILEV ) ) )
ENDDO
ENDDO
C
ELSE
+IF (KINT.EQ.2) THEN
C QUADRATIC INTERPOLATION
C
DO JY = KLAT1,KLAT2
DO JX = KLON1,KLON2
IDX = KP(JX,JY)
IDY = KQ(JX,JY)
ILEV = KR(JX,JY)
C
PRES(JX,JY) = PGAMA(JX,JY,1)*(
C
+ PBETA(JX,JY,1)*( PALFA(JX,JY,1)*PARG(IDX-1,IDY-1,ILEV-1)
+ + PALFA(JX,JY,2)
RE: gcov and initialized data
> From: Nathan Sidwell [mailto:nathanmsidw...@gmail.com] On Behalf Of > Nathan Sidwell > Sent: Thursday, May 3, 2018 1:58 PM > To: taylor, david; gcc@gcc.gnu.org > Subject: Re: gcov and initialized data > > On 05/03/2018 01:09 PM, taylor, david wrote: > > > When you build your program for code coverage (-ftest-coverage > > -fprofile-arcs), GCC creates some initialized read-write GCOV related > > data. Has anyone modified GCC to, presumably either under control of > > a command line option or possibly a configure time option, to initialize > > such > data at run-time instead of compile-time? > > How is this distinct to having to support regular C code such as: > >int x = 5; > > ? (I'm guessing the simplest solution would be to post-process the statically > linked image to do some kind of run-length compression on its .data section > and squirrel that away somewhere that a decompressor can find it early on) There's a linker script. It sets the size of the .data section to 0. Any attempt to use initialized read-write data overflows the .data section and fails the build. > nathan > > -- > Nathan Sidwell
gcc-7-20180503 is now available
Snapshot gcc-7-20180503 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/7-20180503/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 7 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-7-branch revision 259911 You'll find: gcc-7-20180503.tar.xzComplete GCC SHA256=2c7c10ee96986e919c29ffa5475b305945d80ee8ee39b3ddf9232de06607ffd1 SHA1=ebf856d64f84bc8efe2ee48225f5591ee1d98984 Diffs from 7-20180426 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-7 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: GCC 8.1 Released
Hi, On Wed, May 2, 2018 at 2:15 PM, Jakub Jelinek wrote: > Some code that compiled successfully with older GCC versions might require > source changes, see http://gcc.gnu.org/gcc-8/porting_to.html for > details. in "Fortran language issues" it reads: "Prior to GCC 7", shouldn't that be "Prior to GCC 8" or "Up to GCC 7"? And can somebody can tell me, whether this Fortran issue effects also Fortran code which calls C functions? Thanks. Best, Bert
Re: GCC 8.1 Released
On Fri, May 4, 2018 at 9:22 AM, Bert Wesarg wrote: > Hi, > > On Wed, May 2, 2018 at 2:15 PM, Jakub Jelinek wrote: > > Some code that compiled successfully with older GCC versions might > require > > source changes, see http://gcc.gnu.org/gcc-8/porting_to.html for > > details. > > in "Fortran language issues" it reads: "Prior to GCC 7", shouldn't > that be "Prior to GCC 8" or "Up to GCC 7"? > Yes, indeed it should. Thanks for noticing. > > And can somebody can tell me, whether this Fortran issue effects also > Fortran code which calls C functions? > > If it's a "normal" C function with NULL-terminated strings, then no. If it's a C function which is designed to follow the Fortran procedure ABI (where strings are passed as a pointer + a hidden length argument), then yes. -- Janne Blomqvist
