bug-gnubg
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-gnubg] bad __attribute__ handling breaks w/newer standards, new


From: Philippe Michel
Subject: Re: [Bug-gnubg] bad __attribute__ handling breaks w/newer standards, newer gcc, & glibc and causes infinite loop
Date: Thu, 8 Oct 2015 00:49:31 +0200 (CEST)
User-agent: Alpine 2.20 (BSF 67 2015-01-07)

On Wed, 7 Oct 2015, Michael Petch wrote:

On 2015-10-06 14:00, Russ Allbery wrote:
/*
 * __attribute__ is available in gcc 2.5 and later, but only with gcc 2.7
 * could you use the __format__ form of the attributes, which is what we use
 * (to avoid confusion with other macros).
 */
#ifndef __attribute__
# if __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 7)
#  define __attribute__(spec)   /* empty */
# endif
#endif

Hi Guys,

Thanks for the information. Russ, I was considering doing this the way
Bison seems to deal with __attribute__ . The generated code looks like:

#ifndef YY_ATTRIBUTE
# if (defined __GNUC__                                               \
     && (2 < __GNUC__ || (__GNUC__ == 2 && 96 <= __GNUC_MINOR__)))  \
    || defined __SUNPRO_C && 0x5110 <= __SUNPRO_C
#  define YY_ATTRIBUTE(Spec) __attribute__(Spec)
# else
#  define YY_ATTRIBUTE(Spec) /* empty */
# endif
#endif

Based on this I was considering something like:

#ifndef __attribute__
# if (defined __GNUC__ \
&& (2 < __GNUC__ || (__GNUC__ == 2 && 96 <= __GNUC_MINOR__))) \
|| defined __SUNPRO_C && 0x5110 <= __SUNPRO_C
# define __attribute__(Spec) /* empty */
# endif
#endif


It seems to also handle Sun compilers as well. Anyone have any
objections to the latter solution?

There is a ax_c___attribute__.m4 macro in the autoconf archive that handles this totally differently, by checking if __attribute__(unused) compiles.

This may be a little careless since gnubg uses it for other things like alignment. Maybe the macro could be changed so that it optionally takes a list of attributes to check.

I have no idea if an approach is better. It probably doesn't matter much.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]