[Top][All Lists]

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

Re: [bug-diffutils] [PATCH] Avoid gcc warning on Stratus OpenVOS buildin

From: Eric Blake
Subject: Re: [bug-diffutils] [PATCH] Avoid gcc warning on Stratus OpenVOS building regex.c
Date: Wed, 17 Aug 2011 18:12:06 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110621 Fedora/3.1.11-1.fc14 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.11

[adding bug-gnulib]

On 08/17/2011 02:19 PM, Green, Paul wrote:
Gentle Diffutils Maintainers,

The Stratus OpenVOS port of gcc does not allow use of the regparm
attribute. The following patch to regex_internal.h eliminates a series
of warning messages when building lib/regex.c. This patch is against the
newly-released diffutils-3.1 files. With this patch in place, diffutils
builds without warnings or errors on OpenVOS Release 17.1.

diff -u regex_internal.h.orig regex_internal.h
--- regex_internal.h.orig     2011-04-20 18:24:34.000000000 -0400
+++ regex_internal.h     2011-08-17 15:36:26.000000000 -0400
@@ -417,7 +417,7 @@
  typedef struct re_dfa_t re_dfa_t;

  #ifndef _LIBC
-# if defined __i386__&&  !defined __EMX__
+# if defined __i386__&&  !defined __EMX__&&  !defined __VOS__

Other packages will share this problem unless you push the patch upstream in gnulib.

  #  define internal_function   __attribute ((regparm (3), stdcall))
  # else
  #  define internal_function

I'm not sure if this is the best approach, though - does anything else in gnulib make use of regparm, and what benefits does it offer for platforms where it kicks in? Wouldn't it just be simpler to always define internal_function as an empty macro when not on _LIBC, so that we don't have to fight portability problems of non-standard extensions?

Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

reply via email to

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