Re: [ptools-perfapi] Bug in GCC causing problems in 3.0 release...(fwd)
This is mainly more a record of changes to the installed version
of PAPI on Tungsten than anything else (this list is archived).
The following source file was changed according to the instructions
and PAPI 3.0.6 was reinstalled on Tungsten today. The issue
is an incorrect "assert" that could be mistakenly triggered
when multiplexing is enabled. You would have known if this had
happened to you as your program would have died in a most
unpleasant manner.
Rick
---------- Forwarded message ----------
Date: Wed, 10 Nov 2004 13:05:35 -0500
From: Philip J. Mucci <mucci@cs.utk.edu>
To: Nils Smeds <smeds@pdc.kth.se>
Cc: ptools-perfapi@NACSE.ORG
Subject: Re: [ptools-perfapi] Bug in GCC causing problems in 3.0 release...
Nils, you are correct.
For those of you who don't have a buggy gcc, you will be in danger of
this assert triggering when you use multiplex.
Please, please check your multiplex.c for this line and correct it and
rebuild.
Again, this was fixed in recent versions.
Phil
On Sun, 2004-11-07 at 15:44, Nils Smeds wrote:
> I am probably just missing something behind this, but what the heck...
>
> mucci@cs.utk.edu said:
> > assert(retval = PAPI_OK)
> > and it should be
> > assert(retval == PAPI_OK)
>
> To a C-amateur as I am, the first version looks strange. Isn't this an assert
> that
> will always tigger? PAPI_OK is 0 in PAPI. retval = 0 evaluates to 0 and thus
> the assert will fire? Ok, the compiler should not crash on it, but the code
> looks
> strange. assert(0) would perhaps look more meaningful?
>
> The modified code will only fire if retval is non-zero at the point of the
> assert.
>
> /Nils
>
>
>
>
> _______________________________________________
> ptools-perfapi mailing list
> ptools-perfapi@NACSE.ORG
> https://www.NACSE.ORG/mailman/listinfo/ptools-perfapi
_______________________________________________
ptools-perfapi mailing list
ptools-perfapi@NACSE.ORG
https://www.NACSE.ORG/mailman/listinfo/ptools-perfapi