[Developers] g++ warning: operation on *bla* may be undefined
Steve White
steve.white at aei.mpg.de
Fri Oct 27 04:19:46 CDT 2006
Hi,
I have never used __attribute__ at all. It is a Gnu extension.
Here is a discussion where it's pointed out that __attribute__((unused))
and __attribute__((used)) are not negations of one another (when used for
function declarations anyway), and could both be used.
http://www.ussg.iu.edu/hypermail/linux/kernel/0410.1/1797.html
So I wrote a little program (attached), and tried it on five compilers
g++ icpc xlC pgCC pathCC
My notes are below.
The upshot is:
* only icpc complains of unused parameters with normal warnings on.
* __attribute__ didn't break anything else
* __attribute__((unused)) works with icpc to turn the normal warning off
Judging from this sample, we are only "fixing" one compiler, with all
of these efforts.
Perhaps it would be best to get rid of all this extra code, and tell
icpc not to complain about unused parameters.
Who can take __attribute__((unused))
====================================
g++ -Wall
OK
icpc -Wall
OK
xlC -qflag=i:i (the default)
With
-qinfo,
it complains attribute "unused" is ignored and int a is not used
(which means it recognizes __attribute__ but not "unused")
pgCC -Minform=inform (-Minfo -Mneginfo)
OK
pathCC -Wall
OK
Who complains about a plain, unused parameter?
==============================================
g++ -Wall -pedantic -ansi
does not complain. To make it complain, must specify
-Wunused-parameter
icpc -Wall
complains
pgCC -Minfo=all
does not complain
pathCC -Wall
does not complain
(even with -Wunused-parameter, does not complain (broken))
xlC -qflag=i:i
does not complain. To make it complain, specify -qinfo
On 26.10.06, Erik Schnetter wrote:
> Nothing special happens. This attribute just means that this
> variable is expected to be potentially unused, so that there should
> be no warnings about it. As far as I know, this is meant for auto-
> generated code or similar situations where variables which are left
> unused are not a programmer's oversight.
>
> There is also an __attribute__((used)), which specifies that this
> variables is actually used, even if it "looks unused" in the source
> code. This is useful for transforming the produced assembler code
> later on.
>
> -erik
>
> On Oct 26, 2006, at 16:42:09, Tom Goodale wrote:
>
> >Interesting. What happens when you do use an __attribute__
> >((unused)) variable ?
> >
> >Tom
> >
> >On Thu, 26 Oct 2006, Erik Schnetter wrote:
> >
> >>gcc has __attribute__((unused)) to mark variables that are
> >>intentionally unused. This suppresses this warning. Other
> >>compilers may have similar ways for annotating variables.
> >>
> >>I have implemented a bit of generic infrastructure to declare
> >>variables, which makes it easier to experiment with these things.
> >>I have also implemented autodetecting whether __attribute__
> >>((unused)) is supported, so that it is used when present, and an
> >>old-style mechanism is used otherwise. A similar thing is done for
> >>Fortran code.
> >>
> >>The changes are straightforward, but touch quite a number of
> >>files. I would need to isolate them from other changes, and then
> >>they need to be tested thoroughly. I can do the first part if you
> >>are interested.
> >>
> >>We discussed this before, and then the consensus was that using
> >>__attribute__((unused)) was not worth the effort because the
> >>existing mechanisms were sufficient. Maybe this has changed with
> >>gcc 4 having become too clever.
> >>
> >>-erik
> >>
> >>On Oct 26, 2006, at 15:50:38, Steve White wrote:
> >>
> >>>Hi again.
> >>>Unfortunately, Portland Group's C++ compiler (which I hadn't tried
> >>>in my tests) now warns:
> >>>
> >>> variable "parameter_name" was set but never used
> >>>for every CCTK parameter. I don't think it was warning about the
> >>>old code.
> >>>It seems that one can't please everybody.
> >>>On 20.10.06, Steve White wrote:
> >>>>Hi,
> >>>>This is concerned with g++ warnings like:
> >>>>
> >>>> Preprocessing arrangements/Carpet/Carpet/src/Timing.cc
> >>>> Compiling arrangements/Carpet/Carpet/src/Timing.cc
> >>>> configs/chain_gcc_carpet/build/Carpet/Timing.cc:
> >>>> In function ‘void Carpet::InitTimingVariables(const
> >>>> cGH*)’:
> >>>> configs/chain_gcc_carpet/build/Carpet/Timing.cc:120:
> >>>> warning: operation on ‘cctki_use’ may be undefined
> >>>>The culprit was in generated bindings code meant to get rid of
> >>>>warnings
> >>>>about unused variables corresponding to Cactus parameters
> >>>>included in
> >>>>code by the DECLARE_CCTK_PARAMETERS macro.
> >>>>Typically, a struct was defined to hold copies of the macros, then
> >>>>such very interesting constructs would appear.
> >>>>
> >>>> const void *PRIVATE_CACTUS_STRUCT_use = ( \
> >>>> PRIVATE_CACTUS_STRUCT_use = &cctk_run_title, \
> >>>> PRIVATE_CACTUS_STRUCT_use = &*PRIVATE_CACTUS_STRUCT_use \
> >>>> )
> >>>>This code replaces that with a do-nothing enum declaration
> >>>> enum {
> >>>> dummy_cctk_run_title = sizeof( cctk_run_title )
> >>>> //,etc.
> >>>> };
> >>>>The nature of all the entities involved is here much clearer,
> >>>>both to
> >>>>compilers and to me.
> >>>>Like the existing solution, this permits the user to proceed to
> >>>>make more
> >>>>declarations after the DECLARE_CCTK_PARAMETERS macro (simply
> >>>>putting a list
> >>>>of variable assignments after the declaration would not have
> >>>>that property).
> >>>>See also the patches list posting of the same name, and PR 2070
> >>>>http://www.cactuscode.org/cactus_cgi-bin/gnatsweb.pl?cmd=view%
> >>>>20audit-trail&database=cactus&pr=2070
> >>>>for a patch.
> >>>>It has been tested on Gnu 4x, Intel 9x, IBM XL
> >>>>Cheers!
--
Steve White : Programmer
Max-Planck-Institut für Gravitationsphysik Albert-Einstein-Institut
Am Mühlenberg 1, D-14476 Golm, Germany +49-331-567-7625
-------------- next part --------------
static void
plain_unused( int a );
static void
attribute_unused( int a );
int
main()
{
int a = 1;
plain_unused( a );
attribute_unused( a );
return 0;
}
void
plain_unused( int a )
{
}
void
attribute_unused( int __attribute__((unused)) a )
{
}
More information about the Developers
mailing list