Re: [PATCH] fixincludes: Update darwin_flt_eval_method for macOS 14

[Bruce Korb via Gcc-patches]

Looks reasonable to me!

On 8/16/23 12:20, Rainer Orth wrote:

On macOS 14, a guard in  changed:

-- MacOSX13.3.sdk/usr/include/math.h2023-04-19 01:54:44
+++ MacOSX14.0.sdk/usr/include/math.h   2023-08-01 08:42:43
@@ -22,0 +23 @@
+
@@ -43 +44 @@
-#if __FLT_EVAL_METHOD__ == 0
+#if __FLT_EVAL_METHOD__ == 0 || __FLT_EVAL_METHOD__ == -1
@@ -49 +50 @@
-#elif __FLT_EVAL_METHOD__ == 2 || __FLT_EVAL_METHOD__ == -1
+#elif __FLT_EVAL_METHOD__ == 2

Therefore the darwin_flt_eval_method fixincludes fix doesn't match any
longer, leading to a large number of testsuite failures like

/private/var/gcc/regression/master/14-gcc/build/gcc/include-fixed/math.h:69:5: error: 
#error "Unsupported value of __FLT_EVAL_METHOD__."

where __FLT_EVAL_METHOD__ = 16.

This patch adjusts the fix to allow for both forms.

Tested with make check in fixincludes on x86_64-apple-darwin23.0.0 and
verifying that  has indeed been fixed as expected.

Ok for trunk?

Rainer

Vim swap files not ignored

[Bruce Korb via Gcc-patches]

Hi,
I don't have the keys for write access anymore. This ought to be 
applied. Odd that it never has been. :)diff --git a/.gitignore b/.gitignore
index 14ee0325176..021a8c74185 100644
--- a/.gitignore
+++ b/.gitignore
@@ -6,6 +6,7 @@
 *~
 .#*
 *#
+.*.swp
 
 *.flt
 *.gmo

Re: [PATCH] fixincludes: simplify handling for access() failure [PR21283, PR80047]

[Bruce Korb via Gcc-patches]

Perfect.

On 11/12/21 1:58 PM, Xi Ruoyao wrote:

diff --git a/fixincludes/fixincl.c b/fixincludes/fixincl.c
index 6dba2f6e830..ee57fbf61b4 100644
--- a/fixincludes/fixincl.c
+++ b/fixincludes/fixincl.c
@@ -1352,11 +1352,10 @@ process (void)
  
if (access (pz_curr_file, R_OK) != 0)

  {
-  int erno = errno;
-  fprintf (stderr, "Cannot access %s from %s\n\terror %d (%s)\n",
-   pz_curr_file, getcwd ((char *) NULL, MAXPATHLEN),
-   erno, xstrerror (erno));
-  return;
+  /* Some really strange error happened. */
+  fprintf (stderr, "Cannot access %s: %s\n", pz_curr_file,
+  xstrerror (errno));
+  abort();
  }
  
pz_curr_data = load_file (pz_curr_file);

Re: [PATCH] fixincludes: fix portability issues about getcwd() [PR21283, PR80047]

[Bruce Korb via Gcc-patches]

If you are going to be excruciatingly, painfully correct, free() is 
going to be unhappy about freeing a static string in the event getcwd() 
fails for some inexplicable reason. I'd replace the free() + return with 
a call to exit. Maybe even:


   if (VERY_UNLIKELY (access (pz_curr_file, R_OK) != 0)) abort()

On 11/11/21 8:33 AM, Xi Ruoyao wrote:

---
  fixincludes/fixincl.c | 13 +++--
  1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/fixincludes/fixincl.c b/fixincludes/fixincl.c
index 6dba2f6e830..1580c67efec 100644
--- a/fixincludes/fixincl.c
+++ b/fixincludes/fixincl.c
@@ -1353,9 +1353,18 @@ process (void)
if (access (pz_curr_file, R_OK) != 0)
  {
int erno = errno;
+  char *buf = NULL;
+  const char *cwd = NULL;
+  for (size_t size = 256; !cwd; size += size)
+   {
+ buf = xrealloc (buf, size);
+ cwd = getcwd (buf, size);
+ if (!cwd && errno != ERANGE)
+   cwd = "the working directory";
+   }
fprintf (stderr, "Cannot access %s from %s\n\terror %d (%s)\n",
-   pz_curr_file, getcwd ((char *) NULL, MAXPATHLEN),
-   erno, xstrerror (erno));
+  pz_curr_file, cwd, erno, xstrerror (erno));
+ free (buf); return;
  }
  

Re: [PATCH] fixincludes: don't assume getcwd() can handle NULL argument

[Bruce Korb via Gcc-patches]

On 11/10/21 4:22 AM, Xi Ruoyao wrote:

Isn't this warning actually a glibc bug
?

However we can't assume the libc we are using is Glibc.  Even if the
libc supports getcwd() with NULL argument, we are still leaking memory.
You could also free the memory by calling exit(2). Something is pretty 
wrong if fixincludes cannot access a file it was told to process. So, 
technically, you're right. Practically, no difference. But it's fine by 
me to make the change. It does avoid a bug in a certain version of a 
certain library.

Re: [PATCH v3] fixinc: don't "fix" machine names in __has_include(...) [PR91085]

[Bruce Korb via Gcc-patches]

On 6/28/21 10:26 PM, Xi Ruoyao wrote:

v3:
   use memmem/memchr instead of trivial loops
   split most of the logic into a static function
   avoid hardcoded magic number
   adjust test

Looks good to me. :)

Re: [PATCH v2] fixinc: don't "fix" machine names in __has_include(...) [PR91085]

[Bruce Korb via Gcc-patches]

Hi Xi,

On 6/27/21 11:07 PM, Xi Ruoyao wrote:

diff --git a/fixincludes/fixfixes.c b/fixincludes/fixfixes.c
index 5b23a8b640d..147cba716c7 100644
--- a/fixincludes/fixfixes.c
+++ b/fixincludes/fixfixes.c
@@ -524,7 +524,7 @@ FIX_PROC_HEAD( machine_name_fix )
/* If the 'name_pat' matches in between base and limit, we have
   a bogon.  It is not worth the hassle of excluding comments
   because comments on #if/#ifdef lines are rare, and strings on
- such lines are illegal.
+ such lines are only legal in a "__has_include" directive.
  
   REG_NOTBOL means 'base' is not at the beginning of a line, which

   shouldn't matter since the name_re has no ^ anchor, but let's
@@ -544,6 +544,31 @@ FIX_PROC_HEAD( machine_name_fix )
  break;
  
p = base + match[0].rm_so;


This function is already 90 lines long. This would be better in a function.


+
+  /* Check if the match is in __has_include(...) (PR 91085). */
+  for (q = base; q < p; q++)
+if (!strncmp (q, "__has_include", 13))
+  {
+r = q + 13;
+while (r < p && ISSPACE (*r))
+  r++;
+
+/* "__has_include" may appear as "defined(__has_include)",
+   search for the next appearance then.  */
+if (*r != '(')
+  continue;
+
+/* To avoid too much complexity, just hope there is never a
+   ')' in a header name.  */
+while (r < limit && *r != ')')
+  r++;


strchr()? I'd use strchr() to find the start of "__has_include" as well. 
A character-by-character search is more obtuse and any CPU cycle savings 
are pretty marginal. Also:


char const has_inc[] = "__has_include"; int const has_inc_len = 
sizeof(has_inc) - 1;


It makes what's going on more plain by eliminating a magic number (13).


+if (r >= base + match[0].rm_eo)
+  {
+base = r;
+goto again;
+  }
+  }
+
base += match[0].rm_eo;
  
/* One more test: if on the same line we have the same string

diff --git a/fixincludes/inclhack.def b/fixincludes/inclhack.def
index 3a4cfe06542..31389396af6 100644
--- a/fixincludes/inclhack.def
+++ b/fixincludes/inclhack.def
@@ -3151,7 +3151,8 @@ fix = {
  c_fix = machine_name;
  
  test_text = "/* MACH_DIFF: */\n"

-"#if defined( i386 ) || defined( sparc ) || defined( vax )"
+"#if defined( i386 ) || defined( sparc ) || defined( vax ) || "
+"defined( linux ) || __has_include (  ) || defined ( linux )"
No need for a redundant "defined(linux)" test. If you want to test 
superfluous spaces around the parentheses, just do it for one of the 
machine types.

  "\n/* no uniform test, so be careful  :-) */";
  };
  
diff --git a/fixincludes/tests/base/testing.h b/fixincludes/tests/base/testing.h

index cf95321fb86..00e8dde003e 100644
--- a/fixincludes/tests/base/testing.h
+++ b/fixincludes/tests/base/testing.h
@@ -64,7 +64,7 @@ BSD43__IOWR('T', 1) /* Some are multi-line */
  
  #if defined( MACHINE_NAME_CHECK )

  /* MACH_DIFF: */
-#if defined( i386 ) || defined( sparc ) || defined( vax )
+#if defined( i386 ) || defined( sparc ) || defined( vax ) || defined( linux ) || 
__has_include (  ) || defined ( linux )
  /* no uniform test, so be careful  :-) */
  #endif  /* MACHINE_NAME_CHECK */


Thanks for working on this.

Regards, Bruce

Re: GCC fixincludes bug

[Bruce Korb]

On 1/23/20 8:07 AM, Pétur Orri Ragnarsson wrote:
> Hi.
> 
> I ran into a problem with fixincludes when building GCC. Your email is
> in the README file.
> 
> 
> When building a crosscompiling GCC 8.3.0 for powerpc the following "fix"
> is applied:
> 
>     $ diff /opt/pluto-targets/powerpc-rootfs/usr/include/open62541.h
> /opt/plutotoolchain/lib/gcc/powerpc-marel-linux-gnu/8.3.0/include-fixed/open62541.h
>     0a1,9
>     > /*  DO NOT EDIT THIS FILE.
>     >
>     >     It has been auto-edited by fixincludes from:
>     >
>     > "/opt/pluto-targets/powerpc-rootfs/usr/include/open62541.h"
>     >
>     >     This had to be done to correct non-standard usages in the
>     >     original, manufacturer supplied header file.  */
>     >
>     115c124
>     < # ifndef __COUNTER__ /* PPC GCC fix */
>     ---
>     > # ifndef __COUNTER__ /* __PPC__ GCC fix */
>    
> This fix is of course useless since it's editing a string inside a
> comment. Unfortunately it's also harmful since it causes this header
> file to be included in the compiler distribution in a way that it gets
> used before the system header. Then I went and upgraded the open62541
> library which made incompatible changes to its API (from v0.3 to v1.0 if
> it matters) causing builds to fail due to the wrong header being used.
> 
> I can apply some hack to fix this locally in our packaging system so
> it's not an urgent error, and it would also go away by building the
> compiler with the new header installed. But I feel like those are
> workarounds that are not very future-proof.
> 
> Is this something you think can/should be fixed? Do you need more info
> from me to figure out where and why this substitution happens?

It'll be a little while before I can re-pull all of GCC and look at it.
There's a substitution rule somewhere that effectively:

sed 's/PPC/__PPC__/'

somewhere. Add a constraint that prevents the application of that fix
when it appears after a "/*" then re-generate the C code that does all
the fixing.

Cheers - Bruce

> (I've sent this mail directly to you only instead of the mailing list
> since I don't know if I'm including enough information.)

Probably better to include gcc-patches as I have become less reliable on
email since I was retired.

Re: [committed] Add include hack to fix missing SCNuMAX defines in inttypes.h on hpux11.[01]*

[Bruce Korb]

On 1/25/20 9:34 AM, John David Anglin wrote:
> +/*
> + * Fix missing SCNuMAX defines in inttypes.h
> + */
> +fix = {
> +hackname  = hpux_c99_inttypes4;
> +mach  = "hppa*-hp-hpux11.[01]*";
> +files = inttypes.h;
> +sed   = "/^[ \t]*#[ \t]*define[ \t]*SCNxMAX[ \t]*SCNx64/a\\\n"
> + "#define SCNuMAX \t SCNu64\n";
> +sed   = "/^[ \t]*#[ \t]*define[ \t]*SCNxMAX[ \t]*SCNx32/a\\\n"
> + "#define SCNuMAX \t SCNu32\n";
> +test_text = "#define SCNxMAX SCNx64\n"
> + "#define SCNxMAX SCNx32\n";
> +};
> +
"" in the inserted text? OK. It works...

Re: [PATCH] fixincludes breaks mingw64 build

[Bruce Korb]

On 5/31/19 12:15 PM, Jonathan Wakely wrote:
>> Alright, thanks for the hint. I was just following the instructions in
>> gcc-9.1.0/fixincludes/README:
>>
>> """
>> Please also send relevant information to gcc-b...@gcc.gnu.org,
>> gcc-patches@gcc.gnu.org and,
>> please, to me: bk...@gnu.org.
>> """
> 
> Oh, indeed!
> Bruce, should that suggest submitting something to Bugzilla instead?
> Mails sent directly to gcc-bugs tend to get lost among all the
> automated email from Bugzilla.

Looks like old stuff that wasn't updated. I'd copied that text from
other sources and seems out of date.

I should probably update the e-address as well. Yes, I still receive
gnu.org email, but not daily. As infrequent as monthly. Can I do
something to auto-forward it to an e-address I process daily?

Finally, my gcc sources are also years out of date, so if someone is
willing to tweak the docs for me, it'd save some bother. :) I'm actually
retired now and spend more time with a camera than with code.

Cheers - Bruce

Re: [PATCH] fixincludes breaks mingw64 build

[Bruce Korb]

On 5/31/19 6:35 AM, Jonas Jelten wrote:
> This code snippet of mingw's stdio.h:
> 
> 
> #ifdef _WIN64
>   _CRTIMP FILE *__cdecl __iob_func(void);
> #define _iob  __iob_func()
> #else
> [.]
> #if (!defined(NO_OLDNAMES) || defined(__GNUC__))
>   __MINGW_EXTENSION typedef __int64 fpos_t;
> #define _FPOSOFF(fp) ((long)(fp))
> 
> 
> = is modified by fixincludes to be:

<>

> Author: Jonas Jelten 
> Date:   Wed May 31 15:10:52 2019 +0200
> 
> fixincludes: check for lineending to not break mingw64-build
> 
> --- a/fixincludes/inclhack.def  2019-05-31 15:01:31.841235934 +0200
> +++ b/fixincludes/inclhack.def  2019-05-31 15:09:31.068347492 +0200
> @@ -2163,7 +2163,7 @@
>  fix = {
>  hackname = hpux10_stdio_declarations;
>  files= stdio.h;
> -select   = "^#[ \t]*define _iob[ \t]*__iob";
> +select   = "^#[ \t]*define _iob[ \t]*__iob[ \t]*\n";
>  bypass   = "^[ \t]*extern[ \t]*int[ \t]*vsnprintf[ \t]*\\(";
>  c_fix = format;
>  c_fix_arg = "%0\n\n"
> --- a/fixincludes/fixincl.x 2019-05-31 15:13:20.430156243 +0200
> +++ b/fixincludes/fixincl.x 2019-05-31 15:13:24.953156662 +0200
> @@ -4272,7 +4272,7 @@
>   *  content selection pattern - do fix if pattern found
>   */
>  tSCC zHpux10_Stdio_DeclarationsSelect0[] =
> -   "^#[ \t]*define _iob[ \t]*__iob";
> +   "^#[ \t]*define _iob[ \t]*__iob[ \t]*\n";
> 
>  /*
>   *  content bypass pattern - skip fix if pattern found

Looks reasonable to me, but I don't see a test case.

> #define _iob  __iob_func()

should be added to the test code and validated that it remains
unmodified in the output.

Re: [PATCH] fixincludes: vxworks: remove unnecessary parentheses in ioctl wrapper macro

[Bruce Korb]

On Mon, Sep 3, 2018 at 2:46 AM Olivier Hainque  wrote:
> > -"#define ioctl(fd, func, arg) (ioctl)(fd, func, (int)(arg))\n";
> > +"#define ioctl(fd, func, arg) ioctl(fd, func, (int)(arg))\n";
>
> ok by me, thanks.

Shouldn't this qualify as "trivial"? :)

Re: GCC fixinclude help

[Bruce Korb]

On 08/15/2018 02:34 PM, Albert Chin-A-Young wrote:
Don't suppose you have time to help with: 
https://gcc.gnu.org/ml/gcc/2018-08/msg00102.html

David Edelsohn is correct:

6. Now that you have the right things happening, synchronize the

$(srcdir)/tests/base directory with the $(builddir)/tests/res

directory. The output of "make check" will be some diffs that

should give you some hints about what to do.

Re: [PATCH,fixincludes] AIX unistd header

[Bruce Korb]

Looks good to me.
On Mon, Jul 23, 2018 at 1:50 PM David Edelsohn  wrote:
>
> AIX unistd.h defines a static function without a parameter, which
> justifiably upsets C++ code when the header is included and
> referenced. This patch to fixincludes adjusts the header to declare
> the parameter as void.
>
> Bootstrapped on powerpc-ibm-aix7.2.0.0 and powerpc64le-linux
>
> Thanks, David
>
> * inclhack.def (aix_unistd): New.
> * fixincl.x: Regenerate.
> * tests/base/unistd.h [AIX_UNISTD_CHECK]: New test.
>
> Index: inclhack.def
> ===
> --- inclhack.def(revision 262934)
> +++ inclhack.def(working copy)
> @@ -924,6 +924,20 @@
>  };
>
>  /*
> + *  AIX unistd.h defines a static function with an empty parameter list.
> + */
> +fix = {
> +hackname  = aix_unistd;
> +mach  = "*-*-aix*";
> +files = unistd.h;
> +
> +select= "[ \t]+static[ \t]+int[ \t]+getdtablesize\\(\\)";
> +c_fix = format;
> +c_fix_arg = "\tstatic int\t\tgetdtablesize(void)";
> +test_text = "  static int  getdtablesize()";
> +};
> +
> +/*
>   *  Fix __assert declaration in assert.h on Alpha OSF/1.
>   */
>  fix = {



-- 
 - Bruce

Re: [PATCH] fixincludes: a few genfixes changes

[Bruce Korb]

This looks pretty reasonable to me. I'm sure "set -- fixincl.x"
meant something two decades ago when I wrote it. :)
I should update my e-address since I can be off gnu mail for
weeks at a time nowadays. (We retired folk are less consistent
about checking project emails ...)

Oh, the assert.h thingy seems fine, too. RE:
https://gcc.gnu.org/ml/gcc-patches/2018-06/msg00370.html

On 06/09/18 06:22, Rasmus Villemoes wrote:
> 2018-06-09Rasmus Villemoes 
> 
> fixincludes/
> 
>   * genfixes: exit 1 when autogen not found.
>   * genfixes: Remove some redundant code.
>   * genfixes: Update URL to autogen source code.
> ---
>  fixincludes/genfixes | 9 +++--
>  1 file changed, 3 insertions(+), 6 deletions(-)
> 
> diff --git a/fixincludes/genfixes b/fixincludes/genfixes
> index f0fc5e64f8b..47aad01289d 100755
> --- a/fixincludes/genfixes
> +++ b/fixincludes/genfixes
> @@ -55,19 +55,16 @@ do
>esac
>  done
>  
> -if [ $# -eq 0 ] ; then
> -  set -- fixincl.x
> -fi
> -
>  AG="autogen $AG"
>  set -e
>  
>  if [ -z "`${AG} -v | fgrep ' 5.'`" ]
>  then
>echo "AutoGen appears to be out of date or not correctly installed."
> -  echo "Please download and install:"
> -  echo "   ftp://gcc.gnu.org/pub/gcc/infrastructure/autogen.tar.gz;
> +  echo "Please download and install from:"
> +  echo "   https://ftp.gnu.org/gnu/autogen/;
>touch fixincl.x
> +  exit 1
>  else
>echo AutoGen-ing fixincl.x
>$AG inclhack.def
> 

Re: [RFC] fixincludes: vxworks: add hack around ioLib.h/unistd.h mutual inclusion

[Bruce Korb]

Ick. Looks like the right fix to me and it is clearly constrained to
vxworks platforms. Approved by me.

On Fri, May 25, 2018 at 1:58 AM, Rasmus Villemoes
 wrote:
> In old VxWorks headers (5.5), ioLib.h includes unistd.h via
>
> #include "unistd.h"
>
> We copy ioLib to include-fixed, with a few fixes applied. We also wrap
> unistd.h, so that fixed header contains
>
> #include_next 
>
> This means that when user-code does
>
> #include 
>
> they'll get the fixed header (as they should), and the include of
> unistd.h from that picks up the fixed header (as it
> should). Unfortunately, since "..." was used, it seems that "the
> directory in the search path after the one where the current file was
> found" for the include_next then ends up picking the include-fixed
> directory again, so the fixed unistd.h just includes itself, and not the
> system unistd.h - and at the time of the self-include, the guard macro
> is defined, so we do not end up evaluating the include_next again.
>
> Changing to an angle-include instead still makes ioLib.h pick up the
> fixed unistd.h, but since we now actually use the search path,
> include_next works as intended. [In at least VxWorks 6.3, ioLib.h does
> use <...> to include unistd.h, so this issue doesn't exist there.]
>
> There are lots of quote-includes like this in the VxWorks headers, and
> I'm slightly surprised I can't find other examples of this kind of issue
> in inclhack.def. In fact, I'd expect any #include "foo.h" in a fixed
> header where foo.h is also fixed and has an #include_next  would
> have to be changed to #include . In fact, ioLib.h itself at
> firsts seems to have the same problem with limits.h, since it also
> contains
>
> #include "limits.h"
>
> However, in that case, the include-fixed version of limits.h does
>
> #include "syslimits.h"
>
> with an comment about explicitly using "..." so that we pick up
> syslimits.h in the same directory, and _that_ file then does
>
> #include_next 
>
> which again at first hits the include-fixed version, but this time
> around we end up in the not _GCC_LIMITS_H_ branch, with
> _GCC_NEXT_LIMITS_H defined, so we hit another
>
> #include_next 
>
> and that time around limits.h was found via the include path, so we
> finally end up recursing to the system limits.h. So this round-about
> does seem to work for limits.h, but I'm wondering why that header file
> alone gets special treatment by the gcc build system.
>
> Signed-off-by: Rasmus Villemoes 
> ---
>  fixincludes/inclhack.def | 16 
>  1 file changed, 16 insertions(+)
>
> diff --git a/fixincludes/inclhack.def b/fixincludes/inclhack.def
> index d8bb17fe1a1..42c60e0c13b 100644
> --- a/fixincludes/inclhack.def
> +++ b/fixincludes/inclhack.def
> @@ -4843,6 +4843,22 @@ fix = {
>  test_text   = "extern int write ( int , char * , size_t ) ;";
>  };
>
> +/*
> + *  This hack ensures the include_next in the fixed unistd.h actually
> + *  finds the system's unistd.h and not the fixed unistd.h again.
> + */
> +fix = {
> +hackname= vxworks_iolib_include_unistd;
> +files   = ioLib.h;
> +mach= "*-*-vxworks*";
> +select  = "#include \"unistd.h\"";
> +
> +c_fix   = format;
> +c_fix_arg   = "#include ";
> +
> +test_text   = "#include \"unistd.h\"";
> +};
> +
>  /*
>   *  There are several name conflicts with C++ reserved words in X11 header
>   *  files.  These are fixed in some versions, so don't do the fixes if
> --
> 2.15.1
>

Re: [PATCH] Fix fixincludes for canadian cross builds

[Bruce Korb]

I will be unable to look at this for a couple of weeks, so I leave
this to others to look at.

On Wed, Apr 12, 2017 at 8:58 AM, Yvan Roux <yvan.r...@linaro.org> wrote:
> Hi,
>
> On 20 February 2017 at 18:53, Bruce Korb <bk...@gnu.org> wrote:
>> On 02/18/17 01:01, Bernd Edlinger wrote:
>>> On 02/18/17 00:37, Bruce Korb wrote:
>>>> On 02/06/17 10:44, Bernd Edlinger wrote:
>>>>> I tested this change with different arm-linux-gnueabihf cross
>>>>> compilers, and verified that mkheaders still works on the host system.
>>>>>
>>>>> Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
>>>>> Is it OK for trunk?
>>>>
>>>> As long as you certify that this is correct for all systems we care about:
>>>>
>>>> +BUILD_SYSTEM_HEADER_DIR = `
>>>> +echo $(CROSS_SYSTEM_HEADER_DIR) | \
>>>> +sed -e :a -e 's,[^/]*/\.\.\/,,' -e ta`
>>>>
>>>> that is pretty obtuse sed-speak to me.  I suggest a comment
>>>> explaining what sed is supposed to be doing.  What should
>>>> "$(CROSS_SYSTEM_HEADER_DIR)" look like?
>>>>
>>>
>>> I took it just from a few lines above, so I thought that comment would
>>> sufficiently explain the syntax:
>>
>> I confess, I didn't pull a new copy of gcc, sorry.
>> So it looks good to me.
>
>
> We just noticed that this patch brakes canadian cross builds when
> configured with --with-build-sysroot, since headers are searched into
> the target sysroot instead of the one specified for builds.
>
> Maybe there's a cleaner way to fix this and avoid the duplication but
> I didn't find another to test if --with-build-sysroot is used.  The
> attached patch fixes the issue.  Tested with a Full canadian cross
> build for i686-w64-mingw32 host and arm-linux-gnueabihf.
>
> Thanks
> Yvan
>
> 2017-04-12  Yvan Roux  <yvan.r...@linaro.org>
>
>* Makefile.in (BUILD_SYSTEM_HEADER_DIR): Set to SYSTEM_HEADER_DIR
>when configured with --with-build-sysroot.

Re: terminology: zero character vs. null character

[Bruce Korb]

On 03/13/17 15:02, Gerald Pfeifer wrote:
> On Mon, 13 Mar 2017, Joseph Myers wrote:
> I am currently translating GCC into German. During that, I noticed that
> in some places the term "zero character" means '\0'. The official term
> though is "null character", as per the C standard.
>>> Joseph, do you also agree (and with the patch below to document this)?
>> Yes.
> 
> Cool; I committed the change to codingconventions.html .

I'm likely late to the party, but what's wrong with the traditional
"NUL"?  Googling "NUL vs. NULL" yields up:

NULL is a macro defined in  for the null pointer. NUL is the
name of the first character in the ASCII character set. It corresponds
to a zero value. There s no standard macro NUL in C, but some people
like to define it.

Re: [PATCH] Fix fixincludes for canadian cross builds

[Bruce Korb]

On 02/18/17 01:01, Bernd Edlinger wrote:
> On 02/18/17 00:37, Bruce Korb wrote:
>> On 02/06/17 10:44, Bernd Edlinger wrote:
>>> I tested this change with different arm-linux-gnueabihf cross
>>> compilers, and verified that mkheaders still works on the host system.
>>>
>>> Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
>>> Is it OK for trunk?
>>
>> As long as you certify that this is correct for all systems we care about:
>>
>> +BUILD_SYSTEM_HEADER_DIR = `
>> +echo $(CROSS_SYSTEM_HEADER_DIR) | \
>> +sed -e :a -e 's,[^/]*/\.\.\/,,' -e ta`
>>
>> that is pretty obtuse sed-speak to me.  I suggest a comment
>> explaining what sed is supposed to be doing.  What should
>> "$(CROSS_SYSTEM_HEADER_DIR)" look like?
>>
> 
> I took it just from a few lines above, so I thought that comment would
> sufficiently explain the syntax:

I confess, I didn't pull a new copy of gcc, sorry.
So it looks good to me.

Re: [PATCH] Fix fixincludes for canadian cross builds

[Bruce Korb]

On 02/06/17 10:44, Bernd Edlinger wrote:
> I tested this change with different arm-linux-gnueabihf cross
> compilers, and verified that mkheaders still works on the host system.
> 
> Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
> Is it OK for trunk?

As long as you certify that this is correct for all systems we care about:

+BUILD_SYSTEM_HEADER_DIR = `
+echo $(CROSS_SYSTEM_HEADER_DIR) | \
+sed -e :a -e 's,[^/]*/\.\.\/,,' -e ta`

that is pretty obtuse sed-speak to me.  I suggest a comment
explaining what sed is supposed to be doing.  What should
"$(CROSS_SYSTEM_HEADER_DIR)" look like?

Re: Unreviewed fixincludes patch

[Bruce Korb]

*I* would certainly argue that.  I do occasionally shut down the
internet and go on vacation :).  Looks good to me, not being a Solaris
person anymore.

BTW, tiny notational/formatting thing:  the '<<-' "here text" marker says to
strip leading tabs on each line.  In other words, the following can be indented
with tabs to be more eyeball friendly (for future reference):


+fix = {
+hackname  = solaris_gets_cxx14;
+mach  = "*-*-solaris2*";
+files = "iso/stdio_iso.h";
+select= <<- _EOSelect_
+(#if __STDC_VERSION__ < 201112L)
+(extern char \*gets\(char \*\) __ATTR_DEPRECATED;)
+_EOSelect_;
+c_fix = format;
+c_fix_arg = "%1 && __cplusplus < 201402L\n%2";

Re: [fixincludes, v3] Don't define libstdc++-internal macros in Solaris 10+

[Bruce Korb]

I missed the patch because the thread got too long.  Also, I trust you
after all these years. :)

On Mon, Nov 21, 2016 at 1:48 AM, Rainer Orth
 wrote:
> Hi Jonathan,
>
>>>Ok for mainline now and the backports after some soak time?
>>
>> Yes, the libstdc++ parts are OK, thanks.
>
> I assume Bruce is ok with the change to the hpux11_fabsf fix given that it
> was suggested by the HP-UX maintainer and fixes fixincludes make check ;-)
>
> Rainer
>
> --
> -
> Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [fixincludes] Fix macOS 10.12 and (PR sanitizer/78267)

[Bruce Korb]

On Fri, Nov 18, 2016 at 9:42 AM, Mike Stump  wrote:
> On Nov 18, 2016, at 2:45 AM, Rainer Orth  
> wrote:
>> So the current suggestion is to combine my fixincludes patch and Jack's
>> patch to disable  use if !__BLOCKS__.
>
>> I guess this is ok for mainline now to restore bootstrap?
>
> I think we are down to everyone likes this, Ok.  The big question is, does 
> this need a back port?

My thinking on that subject is that since include fixes do not directly affect
the compiler and, instead, facilitate its use on various platforms, it
is therefore
reasonably safe to back port.  Especially if adequate guards (selection tests)
are included in the fix to prevent it from taking action on the wrong files.
But I also think it is really a "steering committee" decision.

For me, I think it is safe enough.

Re: [fixincludes] Fix macOS 10.12 and (PR sanitizer/78267)

[Bruce Korb]

I think restoring bootstrap is likely a good thing.

On Fri, Nov 18, 2016 at 2:45 AM, Rainer Orth
 wrote:
>
> I guess this is ok for mainline now to restore bootstrap?

Re: [fixincludes] Fix macOS 10.12 and (PR sanitizer/78267)

[Bruce Korb]

On Fri, Nov 11, 2016 at 3:18 AM, Mike Stump  wrote:
>
> No objections from me.
>
Or me.  Thanks!

Re: [fixincludes, v3] Don't define libstdc++-internal macros in Solaris 10+

[Bruce Korb]

On 11/03/16 07:11, Rainer Orth wrote:


Ok for mainline now, and for backports to the gcc-6 and gcc-5 branches
after some soak time?


Yes, please.  Thanks.

Re: [PATCH] fixincludes: fix fixincludes for MinGW

[Bruce Korb]

Hi Tadek,

Looks good to me.  Thank you.
Clear to send (push).

Re: [PATCH] fixincludes: fix fixincludes for MinGW

[Bruce Korb]

OK, I found it.  Looks like my MUA is getting too aggressive with its filtering.
What Jeff said, plus I would prefer the tail end looking like:

+
+#else
+
+#define system_with_shell system // normal call
+
+#endif /* defined(__MINGW32__) */

and modifying the call to use "system_with_shell".
The point being that obvious clues are better than subtle switcheroos.

On Thu, Sep 29, 2016 at 11:44 AM, Jeff Law  wrote:

Re: [PATCH] fixincludes: fix fixincludes for MinGW

[Bruce Korb]

I usually try to catch emails with "fixincludes" in the title.
Can I please get a copy of the original patch?  Thanks.

On 09/29/16 11:44, Jeff Law wrote:

On 09/22/2016 11:26 PM, Tadek Kijkowski wrote:

The fixincl executable uses system function to call applyfix or to
direcly patch a header file, with parameters enclosed in single
quotes. This problem is that MinGW system function just calls cmd.exe,
which doesn't strip quotes from parameters and completely ignores
quotes for embedding spaces in parameters. The MinGW system function
also doesn't allow for newlines in executed command parameters. As a
result fixincludes doesn't wotk at on when trying to build a cross
compiler with mingw as host.

On MinGW host, this patch adds system_with_shell function, which
transforms command passed to system function is following way:
- Enclose entire command in double quotes
- Prepend shell executable name, taken from environment variable SHELL
- Replace each occurence of newline with '$'\n'' sequence which is
understood by bash and ksh (it is assumed that all newlines are
embedded in command parameters enclosed in single quotes)

2016-09-23 Tadek Kijkowski (tkijkow...@gmail.com)

* fixincl.c: Added system_with_shell for MinGW host.


Index: fixincludes/fixincl.c
===
--- fixincludes/fixincl.c   (revision 240386)
+++ fixincludes/fixincl.c   (working copy)
@@ -170,7 +170,111 @@
   exit (EXIT_SUCCESS);
 }

+#ifdef __MINGW32__

+/* Count number of \c needle character instances in string */
+static int
+count_chars ( char* str, char needle )

Formatting it.  This should be:

count_chars (char* str, char needle)

Note the lack of horizontal whitespace after the open paren or before
the close paren.  Similarly for system_with_shell declaration below.

Wouldn't this be better named "count_occurrences_of_char" or
"count_instances_of_char"?





+
+  /* Allocate enough memory to fit newly created command string */
+  cmd_size = strlen (env_shell) + (sizeof (z_shell_start_args) - 1)
+   + strlen (s) + newline_cnt * (sizeof(z_shell_newline) - 1
- 1)
+   + (sizeof (z_shell_end_args) - 1) + 1;

Why use sizeof (foo) - 1 rather than just strlen (foo) here?  Note that
GCC can compute the string length as a compile time constant, so you're
not gaining any performance by using sizeof here and strlen seems clearer.




+
+  long_cmd = XNEWVEC (char, cmd_size);
+
+  /* Start with ${SHELL} -c " */
+  strcpy (long_cmd, env_shell);
+  strcat (long_cmd, z_shell_start_args);
+
+  /* End pointer for appending pieces of command while replacing
newlines */
+  cmd_endp = long_cmd + strlen(long_cmd);

Formatting nit.  Space between function name and its argument list.



+  nl_scan = s;
+  while (nl_scan != NULL)
+{
+  char* next_nl = strchr (nl_scan, '\n');

Formatting nit.  char *next_nl.



+  if (next_nl)
+{
+  /* Append part of command between newlines */
+  size_t part_len = next_nl - nl_scan;
+  memcpy(cmd_endp, nl_scan, part_len);

Formatting nit, space between function name and its argument list.


+  cmd_endp += part_len;
+
+  /* Append newline replacement */
+  memcpy(cmd_endp, z_shell_newline, sizeof(z_shell_newline));

Smilarly, space between functio nname and its argument list.


+  cmd_endp += sizeof(z_shell_newline) - 1;

Here too.


+
+  free ( (void*) long_cmd);

free (long_cmd);

Can you fix those various (minor) issue and resubmit.  I think it'll be
OK for the trunk with those changes.

jeff

Re: [PATCH] New hpux fix to add noreturn attribute to longjmp declarations in setjmp.h

[Bruce Korb]

Looks good to me.

On Sat, Aug 13, 2016 at 9:55 AM, John David Anglin  wrote:
> Currently, trunk fails to boot fortran on hpux because of the following error:
>
> /xxx/gnu/gcc/objdir/./prev-gcc/xg++ -B/xxx/gnu/gcc/objdir/./prev-gcc/ 
> -B/opt/gnu64/gcc/gcc-7/hppa64-hp-hpux11.00/bin/ -nostdinc++ 
> -B/xxx/gnu/gcc/objdir/prev-hppa64-hp-hpux11.00/libstdc++-v3/src/.libs 
> -B/xxx/gnu/gcc/objdir/prev-hppa64-hp-hpux11.00/libstdc++-v3/libsupc++/.libs  
> -I/xxx/gnu/gcc/objdir/prev-hppa64-hp-hpux11
> .00/libstdc++-v3/include/hppa64-hp-hpux11.00  
> -I/xxx/gnu/gcc/objdir/prev-hppa64-
> hp-hpux11.00/libstdc++-v3/include  -I/xxx/gnu/gcc/gcc/libstdc++-v3/libsupc++ 
> -L/xxx/gnu/gcc/objdir/prev-hppa64-hp-hpux11.00/libstdc++-v3/src/.libs 
> -L/xxx/gnu/gc
> c/objdir/prev-hppa64-hp-hpux11.00/libstdc++-v3/libsupc++/.libs -fno-PIE -c  
> -DIN
> _GCC_FRONTEND -g -O2 -DIN_GCC -fno-exceptions -fno-rtti 
> -fasynchronous-unwin
> d-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual 
> -Wmissing-format-at
> tribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros 
> -Wno-
> overlength-strings -Werror -fno-common  -DHAVE_CONFIG_H -I. -Ifortran 
> -I../../gc
> c/gcc -I../../gcc/gcc/fortran -I../../gcc/gcc/../include 
> -I../../gcc/gcc/../libc
> pp/include -I/opt/gnu64/gcc/gmp/include  -I../../gcc/gcc/../libdecnumber 
> -I../..
> /gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I../../gcc/gcc/../libbacktrace
>  -o fortran/parse.o -MT fortran/parse.o -MMD -MP -MF fortran/.deps/parse.TPo 
> ../
> ../gcc/gcc/fortran/parse.c
> ../../gcc/gcc/fortran/parse.c: In function 'void unexpected_eof()':
> ../../gcc/gcc/fortran/parse.c:2618:1: error: 'noreturn' function does return 
> [-W
> error]
>
> The attached patch fixes the above by adding the noreturn attribute to the 
> "longjmp" declarations in setjmp.h.
>
> Okay for trunk?
>
> Dave
> --
> John David Anglin   dave.ang...@bell.net
>

Re: [PATCH, fixincludes] Fix PR bootstrap/72833

[Bruce Korb]

Index: fixincludes/fixincl.tpl

===

--- fixincludes/fixincl.tpl (revision 239193)

+++ fixincludes/fixincl.tpl (working copy)

@@ -1,7 +1,7 @@

 [= AutoGen5 Template -*- Mode: C -*-

 x=fixincl.x =]

 [=

- (if (version-compare >= autogen-version "5.18")

+ (if (version-compare >= autogen-version "5.18.1")

  (dne "-D" " * " "/* ")

  (dne " * " "/* ") ) =]

Was this causing a problem?  If so, then it all looks good to me.  I
had thought the "-D" was implemented in 5.18, but that was long, long
ago now.

On Tue, Aug 9, 2016 at 5:17 AM, Bernd Edlinger
 wrote:
> Hi!
>
> Due to my recent cleanup of special_function_p the darwin bootstrap is
> currently broken because the longjmp function misses the noreturn
> attribute.  Therefore I revived an old solaris_longjmp_noreturn
> fixinclude rule.
>
> See the attached patch.
>
> Boot-strap on i686-apple-darwin11 and x86_64-apple-darwin11 was
> successful.
>
> Is it OK for trunk?
>
>
> Thanks
> Bernd.

Re: Implement -Wswitch-fallthrough: rs6000

[Bruce Korb]

Actually, it occurs to me:

On Wed, Jul 13, 2016 at 11:23 AM, Marek Polacek  wrote:
> My current implementation warns here, but the warning can be suppressed
> by adding /* FALLTHRU */ or [...]

that the traditional "lint-ean" spelling is "/* FALLTHROUGH */", so
why would the abbrev be accepted and the full spelling not?  I think
"FALLTHRU" was added a mere 20 years ago and I go back farther than
that.  (40+, actually).

Re: Implement -Wswitch-fallthrough: rs6000

[Bruce Korb]

On Wed, Jul 13, 2016 at 11:39 AM, Marek Polacek  wrote:
> Most likely what you saw was in cxx_pretty_printer::declaration_specifiers.

I only saw it once and, of course, it was once too often. ;)
If you fix it, it would sooth my sensibilities as the fixincludes maintainer,
making mine a small voice in the GCC world.

Still, for what it's worth, I'd back you :)

Cheers - Bruce

Re: Implement -Wswitch-fallthrough: rs6000

[Bruce Korb]

> On Mon, Jul 11, 2016 at 01:36:02PM -0700, Bruce Korb wrote:
> [[putrid code deleted]]
>> Does this patch mean that the above got fixed?  I mean, if you're
>> going to fret over linguistic tags to make falling through explicit,
>> it would seem the above code is pretty sore-thumby, yes?
>
> My current implementation warns here, but the warning can be suppressed
> by adding /* FALLTHRU */ or __builtin_fallthrough(); before the
> do_something_else() line.
>
> Does that answer your question?

Not in a satisfying way. :)  I understand that syntactically, you can
drop a "case" in wherever you can drop a statement label.  That
doesn't mean you should.  Since I wasn't fixing GCC code, I just
rolled my eyes and moved on.  However, if the code is going to be
changed, then contortions like that ought to be addressed.  Both for
aesthetics and for code clarity.

Re: Implement -Wswitch-fallthrough: rs6000

[Bruce Korb]

I'm curious about this.  In the process of developing a code analysis
tool, I found some GCC code that was, basically:

switch (v) {
case 0:
  if (e) {
do_something();
  } else {
case 1:
do_something_else();
  }
}

Does this patch mean that the above got fixed?  I mean, if you're
going to fret over linguistic tags to make falling through explicit,
it would seem the above code is pretty sore-thumby, yes?

Re: [PATCH,FIXINCLUDES] AIX stdlib.h #define malloc

[Bruce Korb]

BTW, OK by me :)  Now that I'm retired, it is starting to look like
less time for this stuff... ;)

On Thu, Jun 9, 2016 at 10:25 AM, David Edelsohn  wrote:

> Index: inclhack.def
> ===
> --- inclhack.def(revision 237258)
> +++ inclhack.def(working copy)

Re: [committed] Fix declaration of vsscanf on hpux

[Bruce Korb]

On 01/31/16 17:03, John David Anglin wrote:

The attached hack fixes missing const from the first argument of the 
declararation for vsscanf on hpux.


Approved for all active dev branches.

Re: [PATCH, FIXINCLUDES] AIX stdio C++ inline fix

[Bruce Korb]

Looks good to me...

On Thu, Aug 13, 2015 at 10:33 AM, David Edelsohn dje@gmail.com wrote:
 AIX stdio.h header includes code specific for C++ that looks like:

 extern C {
 #ifdef __cplusplus
 #ifdef ferror
 #undef ferror
 inline int ferror(FILE * _p)
 {
 return ((_p)-_flag  _IOERR);
 }
 #endif /*ferror*/

 which generates code that makes the AIX linker and loader rather upset
 because the inline function is not mangled and conflicts with the C
 library.

 This fixincludes patch protects this code with an addition test for
 IBMCPP (not that IBMCPP will use GCC include-fixed headers, but ).

 Okay?

 Thanks, David

 * inclhack.def (aix_stdio_inline): New fix.
 * fixincl.x: Regenerated.
 * test/base/stdio.h [AIX_STDIO_INLINE]: New test.

 Index: inclhack.def
 ===
 --- inclhack.def(revision 226860)
 +++ inclhack.def(working copy)
 @@ -892,10 +892,32 @@
  };

  /*
 + * stdio.h on AIX defines ferror, clearerr and feof as C++ inline, which
 +   produces wrong code with G++.
 + */
 +fix = {
 +hackname  = aix_stdio_inline;
 +mach  = *-*-aix*;
 +files = stdio.h;
 +select= #ifdef __cplusplus\\\n
 +}\\\n\\\n
 +#ifdef ferror\\\n;
 +c_fix = format;
 +c_fix_arg = #ifdef __cplusplus\n
 +}\n
 +#endif\n\n
 +#if (defined(__cplusplus)  defined(__IBMCPP__))\n
 +#ifdef ferror\n;
 +test_text = #ifdef __cplusplus\n}\n\n#ifdef ferror;
 +};
 +
 +
 +/*

Re: [PATCHv2] [fixincludes] Ignore .DS_Store junk files when running make check

[Bruce Korb]

Definitely much better.  I won't apply it until the weekend, so
someone else will likely beat me to it.  Thank you.

On Mon, Jul 27, 2015 at 7:36 PM, Eric Gallager eg...@gwmail.gwu.edu wrote:
 On 7/27/15, Andreas Schwab sch...@linux-m68k.org wrote:
 Eric Gallager eg...@gwmail.gwu.edu writes:

 Okay, I tried embedding ! -name CVS/ ! -name .svn/ into the find

Re: [PATCH, fixincludes] AIX headers and extern C

[Bruce Korb]

OK.  You might consider updating autogen.  It seems 5.18 doesn't
handle the version test quite right.  Any 5.18.n should do fine.  I
guess I didn't test the version test with older versions. :)

On Thu, May 21, 2015 at 6:58 AM, David Edelsohn dje@gmail.com wrote:
 The AIX port of GCC is one of the few ports that does not define
 NO_IMPLICIT_EXTERN_C.  A user reported a problem that we tracked to an
 AIX header that explicitly used C++ features (bracketed by #ifdef
 __cplusplus).

 AIX headers have included some C++ features, mostly protected by

 #if defined (__cplusplus)  defined (__IBMCPP__)

 but a few only by __cplusplus.  Because of the way the particular
 header is structured, adding a test for __IBMCPP__ causes other
 problems.

 At the encouragement of Jonathan (implicit extern C is an
 abomination) Wakely, I tried to bootstrap GCC with
 NO_IMPLICIT_EXTERN_C defined on AIX.  That failed horribly.  Some AIX
 headers use C++ features while others are not C++ safe.  Sigh.

 This patch adds a new fix to wrap the failing AIX headers necessary
 for GCC bootstrap in extern C. I can bootstrap with
 NO_IMPLICIT_EXTERN_C defined.

 I don't see clear way to discover which of the headers are C++ safe
 and which are not if there is no clear intention from IBM AIX Brand to
 make the headers C++ safe.  I don't see a robust and low-risk way to
 enable NO_IMPLICIT_EXTERN_C on AIX.

 So, this patch also adds an extern C++ block around the C++ code in
 sys/socket.h that caused the initial failure.  I could not find other
 headers that used C++ features without __IBMCPP__.

 Bootstrapped on powerpc-ibm-aix7.1.0.0.

 Okay?

 Thanks, David

 * inclhack.def (aix_externc): New fix.
 (aix_externcpp[12]): New fix.
 * fixincl.x: Regenerate.
 * test/base/ctype.h [AIX_EXTERNC_CHECK]: New test.
 * test/base/sys/socket.h [AIX_EXTERNCPP[12]_CHECK]: New test.
 * test/base/fcntl.h: New file.

Re: [patch 3/28] fixincludes: Use automake-1.11.6 (across the tree)

[Bruce Korb]

On 05/06/15 01:58, Michael Haubenwallner wrote:

Trivial patch for fixincludes.


A) sufficiently trivial that explicit permission ought not be required
B) it is now officially blessed that we can coalesce year lists.
   Let's do so, okay?


Am 2015-05-05 um 18:03 schrieb Michael Haubenwallner:

Hello build machinery maintainers,



BTW, the actual commands I use to re-run automake for everything (I found) is:
   $ export AUTOMAKE='automake-1.11 --add-missing --copy --force-missing'
   $ /src/gcc-trunk/configure --prefix=/install \
   --enable-languages=c,c++,fortran,go,java,lto,objc,obj-c++ \
   --enable-liboffloadmic=target \
   --enable-libmpx \
   --enable-maintainer-mode

Re: [PATCH, fixincludes] Fix PR 48009 53348

[Bruce Korb]

Looks good to me.

On Sun, Feb 15, 2015 at 12:49 PM, David Edelsohn dje@gmail.com wrote:
 The stdlib.h header in AIX 4.3 does not correctly declare strtof with
 a const char* argument.  Users are building the latest releases of GCC
 on AIX 4.3  The appended patch from Richard G Daniel uses fixincludes
 to correct the declaration.

 Okay?

 Thanks, David

 PR bootstrap/48009
 PR bootstrap/53348
 * inclhack.def (aix_strtof_const): New fix.
 * fixincl.x: Regenerate.
 * tests/base/inttypes.h: New test.

 Index: inclhack.def
 ===
 --- inclhack.def(revision 220717)
 +++ inclhack.def(working copy)
 @@ -842,6 +842,18 @@
  };

  /*
 + * stdlib.h on AIX 4.3 declares strtof() with a non-const first argument.
 + */
 +fix = {
 +hackname  = aix_strtof_const;
 +files = stdlib.h;
 +select= ((extern[ \t]+)?float[ \t]+strtof)\\(char \\*, char 
 \\*\\*\\);
 ;
 +c_fix = format;
 +c_fix_arg = %1(const char *, char **);;
 +test_text = extern floatstrtof(char *, char **);;
 +};
 +
 +/*
   *  sys/machine.h on AIX 4.3.3 puts whitespace between a \ and a newline
   *  in an otherwise harmless (and #ifed out) macro definition
   */

Re: [fixincludes] Fix iso/math_c99.h signbit on Solaris

[Bruce Korb]

On Mon, Feb 9, 2015 at 3:30 AM, Rainer Orth r...@cebitec.uni-bielefeld.de 
wrote:
 That worked fine indeed and is considerably more readable than my
 previous version.

Excellent!  Thank you.

 It produced the identical fixincl.x, passed fixincludes make check and
 Solaris 10 and 11 bootstraps.

 Ok for mainline now, I guess?

That's a really good guess. :)

Re: [fixincludes] Fix iso/math_c99.h signbit on Solaris

[Bruce Korb]

On 01/29/15 05:38, Rainer Orth wrote:

So I saw.  If all else fails, we can still commit the (ugly/hard to
read) initial version, otherwise libgo won't build on Solaris before
some (quite recent) Solaris 11.2 patch, breaking bootstrap.


Having it work at all seems like a nice feature.
I think that:

   test-text = _EOF_
[[]]
_EOF_;

is likely still better than the quoted string, though.
Without the little hyphen (-), the leading tabs are
not stripped.  At this point, whatever is easiest for you. :)

Re: [fixincludes] Fix iso/math_c99.h signbit on Solaris

[Bruce Korb]

Hi Rainer,

Sorry for the long delay.  Anyway:

On 01/28/15 06:12, Rainer Orth wrote:

* In test_text, I had to backslash-escape the trailing \, otherwise they
   were eaten up.  Whether or not I do this makes no difference for the
   generated fixincl.x, but only with the escaping does make check pass.


Right.  It likely gets massaged by a shell script somewhere.


Line 88 of check.tpl:

 88 cat  [= (raw-shell-str (if (exist? files) (get files[0]) 
testing.h))
 89  =] _HACK_EOF_
 90
 91
 92 #if defined( [=(. HACK)=]_CHECK )
 93 [=test_text=]
 94 #endif  /* [=(. HACK)=]_CHECK */
 95 _HACK_EOF_

By quoting the _HACK_EOF_ delimiter on line 89, the shell will not
try to process the test_text.


This is certainly something that needs to be decided: if we go this
route, we should bump the autogen version requirement in install.texi
(to whatever is necessary to support the TAB\ magic).


I think Debian stable has moved up to 5.18.2, if I am remembering
correctly.  It's a year old (last fall).  I think that is old enough to
have been spread around by now.


It's your call ultimately.


OK, let's bump the defined requirement to something (almost) in this decade,
even if (for the moment) we don't use the TAB\ magic:

rel5.9.8/16-May-2009

Re: [fixincludes] Fix iso/math_c99.h signbit on Solaris

[Bruce Korb]

On 01/28/15 10:13, Bruce Korb wrote:

Hi Rainer,

Sorry for the long delay.  Anyway:

On 01/28/15 06:12, Rainer Orth wrote:

* In test_text, I had to backslash-escape the trailing \, otherwise they
   were eaten up.  Whether or not I do this makes no difference for the
   generated fixincl.x, but only with the escaping does make check pass.


Right.  It likely gets massaged by a shell script somewhere.


Line 88 of check.tpl:


Oh, line 59 too:
 59 cat  [=(. sfile)=] _HACK_EOF_
 60
 61
 62 #if defined( [=(. HACK)=]_CHECK_[=(for-index)=] )
 63 [=test_text=]
 64 #endif  /* [=(. HACK)=]_CHECK_[=(for-index)=] */
 65 _HACK_EOF_

Re: [fixincludes] Fix iso/math_c99.h signbit on Solaris

[Bruce Korb]

On 01/28/15 10:15, Bruce Korb wrote:

On 01/28/15 10:13, Bruce Korb wrote:

Hi Rainer,

Sorry for the long delay.  Anyway:

On 01/28/15 06:12, Rainer Orth wrote:

* In test_text, I had to backslash-escape the trailing \, otherwise they
   were eaten up.  Whether or not I do this makes no difference for the
   generated fixincl.x, but only with the escaping does make check pass.


Right.  It likely gets massaged by a shell script somewhere.


Line 88 of check.tpl:


Oh, line 59 too:
  59 cat  [=(. sfile)=] _HACK_EOF_
  60
  61
  62 #if defined( [=(. HACK)=]_CHECK_[=(for-index)=] )
  63 [=test_text=]
  64 #endif  /* [=(. HACK)=]_CHECK_[=(for-index)=] */
  65 _HACK_EOF_


I kicked off a test.  It is not as simple as quoting the sentinel.
I'll dig into it when I can.


features.h /u/gnu/proj/gcc-svn-bld/fixincludes/tests/base/features.h differ: 
char 318, line 13
*** features.h  Wed Jan 28 11:26:38 2015
--- /u/gnu/proj/gcc-svn-bld/fixincludes/tests/base/features.h   Sat Dec  6 
06:10:29 2014
***
*** 10,17 


  #if defined( GLIBC_C99_INLINE_1_CHECK )
! #if __GNUC_PREREQ (2, 7)  defined __OPTIMIZE__ \
!  !defined __OPTIMIZE_SIZE__  !defined __NO_INLINE__  (defined 
__extern_inline || defined __GNUC_GNU_INLINE__)
  # define __USE_EXTERN_INLINES 1
  #endif
  #endif  /* GLIBC_C99_INLINE_1_CHECK */
--- 10,16 


  #if defined( GLIBC_C99_INLINE_1_CHECK )
! #if __GNUC_PREREQ (2, 7)  defined __OPTIMIZE__  !defined __OPTIMIZE_SIZE__ 
 !defined __NO_INLINE__
  # define __USE_EXTERN_INLINES 1
  #endif
  #endif  /* GLIBC_C99_INLINE_1_CHECK */


This should be fixed by changing the base version.

checksum test for fixincluding

[Bruce Korb]

Someone suggested this and it seemed like a reasonable thing to verify
(pretty much) that only a specific version of a file should be fixed.
I used the BSD check sum, so there is a 1/65000 chance of a false positive.
Incorporating md5sum seemed over the top.
Index: fixincludes/ChangeLog
===
--- fixincludes/ChangeLog	(revision 218991)
+++ fixincludes/ChangeLog	(working copy)
@@ -1,9 +1,20 @@
+2013-12-07  Bruce Korb  bk...@gnu.org
+
+	* fixincludes/fixincl.tpl: add handling for sum selection
+	criteria and clean up layout
+	* fixincludes/fixlib.h: enumerate TT_CKSUM test type
+	* fixincludes/fixincl.c (fix_applies): add code to handle
+	the new test type
+	(cksum_test): function to handle it
+	* fixincludes/README: doc it and remove explanations from
+	more than a decade ago.
+
 2014-12-15  Uros Bizjak  ubiz...@gmail.com
 
 	* server.c (server_setup): Check return value of
 	getcwd and in case of error set buff[0] to 0.
 
 2014-10-21  Uros Bizjak  ubiz...@gmail.com
 
 	* inclhack.def (glibc_c99_inline_4): Add pthread.h to files.
 	* fixincl.x: Regenerate.
Index: fixincludes/README
===
--- fixincludes/README	(revision 218991)
+++ fixincludes/README	(working copy)
@@ -1,30 +1,10 @@
 
-FIXINCLUDES OPERATION
-=
-
-See also:  http://autogen.SourceForge.net/fixinc.html
-
-The set of fixes required was distilled down to just the data required
-to specify what needed to happen for each fix.  Those data were edited
-into a file named fixincludes/inclhack.def.  A program called AutoGen
-(http://autogen.SourceForge.net) uses these definitions to instantiate
-several different templates that then produces code for a fixinclude
-program (fixincl.x) and a shell script to test its functioning.  On
-certain platforms (viz. those that do not have functional bidirectional
-pipes), the fixincl program is split into two.  This should only concern
-you on DOS and BeOS.
-
-Regards,
-	Bruce bk...@gnu.org
-
-
-
 GCC MAINTAINER INFORMATION
 ==
 
 If you are having some problem with a system header that is either
 broken by the manufacturer, or is broken by the fixinclude process,
 then you will need to alter or add information to the include fix
 definitions file, ``inclhack.def''.  Please also send relevant
 information to gcc-b...@gcc.gnu.org, gcc-patches@gcc.gnu.org and,
 please, to me:  bk...@gnu.org.
@@ -76,27 +56,33 @@
 identify the files with files =  entries.  If you use fnmatch(3C)
 wild card characters in a files entry, be certain that the first
 files entry has no such character.  Otherwise, the make check
 machinery will attempt to create files with those characters in the
 name.  That is inconvenient.
 
 3.  It is relatively expensive to fire off a process to fix a source
 file, therefore write apply tests to avoid unnecessary fix
 processes.  The preferred apply tests are select, bypass, mach
-and c-test because they are performed internally:
+sum, and c-test because they are performed internally:
 
 * select - Run a regex on the contents of the file being considered.
All such regex-es must match.  Matching is done with
extended regular expressions.
 
 * bypass - Run a regex on the contents of the file being considered.
No such regex may match.
 
+* sum- Select a specific version of a file that has a matching
+   check sum.  The BSD version of checksum [sum(1BSD)]
+   is used.  Each sum entry should contain exactly three
+   space separated tokens:  the sum, some number and the
+   basename of the file.  The some number is ignored.
+
 * c_test - call a function in fixtests.c.  See that file.
 
 * files  - the fnmatch pattern of the file(s) to examine for
the issue.  There may be several copies of this attribute.
If the header lives in a /usr/include subdirectory, be
sure to include that subdirectory in the name. e.g. net/if.h
 
 * mach   - Match the output of config.guess against a series of fnmatch
patterns.  It must match at least one of the patterns, unless
Index: fixincludes/fixincl.c
===
--- fixincludes/fixincl.c	(revision 218991)
+++ fixincludes/fixincl.c	(working copy)
@@ -591,18 +591,71 @@
   if (p_test-p_test_regex == 0)
 fprintf (stderr, fixincl ERROR RE not compiled:  `%s'\n,
  p_test-pz_test_text);
 #endif
   if (xregexec (p_test-p_test_regex, pz_data, 0, 0, 0) == 0)
 return APPLY_FIX;
   return SKIP_FIX;
 }
 
+/* * * * * * * * * * * * *
+
+  cksum_test   check the sum of the candidate file
+  Input:  the original file contents and the file name
+  Result: APPLY_FIX if the check sum matches, SKIP_FIX otherwise
+
+  The caller may

Re: [off-list] A fixincludes warning-removal patch

[Bruce Korb]

On 12/14/14 14:07, Uros Bizjak wrote:

Hello Bruce!

I have posted a small fixincludes patch [1] that fixes a warning
during the fixincludes build,


Please apply.  However, I'm sure it is not the last remaining warning
since new warnings get invented. :)

Thank you - Bruce

2014-12-09  Uros Bizjak  ubiz...@gmail.com

* server.c (server_setup): Check return value of
getcwd and in case of error set buff[0] to 0.

Bootstrapped on x86_64-linux-gnu.

OK for mainline?

Index: server.c
===
--- server.c(revision 218525)
+++ server.c(working copy)
@@ -192,7 +192,8 @@ server_setup (void)

   fputs (trap : 1\n, server_pair.pf_write);
   fflush (server_pair.pf_write);
-  getcwd (buff, MAXPATHLEN + 1);
+  if (getcwd (buff, MAXPATHLEN + 1) == NULL)
+buff[0] = 0;
   p_cur_dir = xstrdup (buff);
 }

Re: [PATCH] PR other/63613: Add fixincludes for dejagnu.h

[Bruce Korb]

On 12/05/14 12:32, Jeff Law wrote:1

fixincludes/ChangeLog:
PR other/63613
* inclhack.def (dejagnu_h_make_inline_functions_static): New fix.
* fixincl.x: Regenerate.
* tests/base/dejagnu.h: New.

OK.


No, actually not.

+fix = {
+hackname = dejagnu_h_make_inline_functions_static;
+files = dejagnu.h;
+
+sed = 's@^inline void$'
+   '@static inline void@';

I guess I should elaborate on the preferred substitution mechanism: the 
format fix.
This is functionally equivalent but does not require loading the sed program:

fix = {
  hackname = dejagnu_static_inline;
  files = dejagnu.h;
  select = '^inline void$';
  c-fix = format;
  c-fix-arg = 'static %0';

Thank you.

Re: [PATCH] PR other/63613: Add fixincludes for dejagnu.h

[Bruce Korb]

 This is the first time I've touched the fixincludes directory;
 is this the correct way to make a change here?

Well, I'd like to see it -- especially since it's your first.
Please send to this gmail account or wait until I get my GNU email this weekend.
Thanks!

 Successfully bootstrapped  regrtested on x86_64-unknown-linux-gnu
 (Fedora 20).

 OK for trunk?

More likely than not :)

Re: [PATCH, fixincludes]: Add pthread.h to glibc_c99_inline_4 fix

[Bruce Korb]

On 10/21/14 02:30, Uros Bizjak wrote:

2014-10-21  Uros Bizjak  ubiz...@gmail.com

 * inclhack.def (glibc_c99_inline_4): Add pthread.h to files.
 * fixincl.x: Regenerate.

Bootstrapped and regression tested on CentOS 5.11 x86_64-linux-gnu {,-m32}.

OK for mainline?

Re: [PATCH, fixincludes]: Add pthread.h to glibc_c99_inline_4 fix

[Bruce Korb]

On 10/25/14 10:40, Bruce Korb wrote:

On 10/21/14 02:30, Uros Bizjak wrote:

2014-10-21  Uros Bizjak  ubiz...@gmail.com

 * inclhack.def (glibc_c99_inline_4): Add pthread.h to files.
 * fixincl.x: Regenerate.

Bootstrapped and regression tested on CentOS 5.11 x86_64-linux-gnu {,-m32}.

OK for mainline?


Interesting.  I clicked send and my typing disappeared.

Looks fine to me.

Re: Remove unnecessary and harmful fixincludes for Android

[Bruce Korb]

Hi,

On Wed, Aug 6, 2014 at 4:51 AM, Alexander Ivchenko aivch...@gmail.com wrote:
 We still have to remove fix for compiler.h:

Correct.  Thank you.


 Bruce, I think I formally have to ask for your approval again :)

I don't think so.  You've selected one of the changes we wrote about,
so With one of the two changes, the patch is approved. is sufficient,
as long as you have made either of the proposed changes.

But to be clear:  Approved.  (: again :)

Re: Remove unnecessary and harmful fixincludes for Android

[Bruce Korb]

Hi,

On Tue, Aug 5, 2014 at 4:35 AM, Alexander Ivchenko aivch...@gmail.com wrote:
 Testing for *android* is less than ideal, because of the possibility of
 configuring a *-linux* toolchain to have multilibs using various different
 C libraries (with -mandroid being used to select the Android multilib).
 So, specifying a bypass based on some relevant text that appears in the
 header would be better.

 --
 Joseph S. Myers
 jos...@codesourcery.com

 I've added check for BIONIC keyword. Hopefully it won't disappear.

based on some relevant text
I think that's important, too (that it be relevant).
BIONIC is just some improbable text you found in the header.
My guess is that testing for '*android*' would be more selective,
and certainly less obscure.  Who would ever guess that
BIONIC implies android?

 Updated patch:

 diff --git a/fixincludes/ChangeLog b/fixincludes/ChangeLog
 index f7effee..e05412e 100644
 --- a/fixincludes/ChangeLog
 +++ b/fixincludes/ChangeLog
 @@ -1,3 +1,10 @@
 +2014-08-04  Alexander Ivchenko  alexander.ivche...@intel.com
 +
 + * inclhack.def (stdio_va_list): Bypass fix for Bionic.
 + (complier_h_tradcpp): Remove.
 + * fixincl.x: Regenerate.
 + * tests/base/linux/compiler.h: Remove.
 +
  2014-04-22  Rainer Orth  r...@cebitec.uni-bielefeld.de

   * inclhack.def (math_exception): Bypass on *-*-solaris2.1[0-9]*.
 diff --git a/fixincludes/fixincl.x b/fixincludes/fixincl.x

[[generated text is not needed for approval]]

 diff --git a/fixincludes/inclhack.def b/fixincludes/inclhack.def
 index 6a1136c..bf452c6 100644
 --- a/fixincludes/inclhack.def
 +++ b/fixincludes/inclhack.def
 @@ -1140,20 +1140,6 @@ fix = {
  };

  /*
 - *  Old Linux kernel's compiler.h header breaks Traditional CPP
 - */
 -fix = {
 -hackname  = complier_h_tradcpp;

[[ OK ]]

 @@ -3722,8 +3708,9 @@ fix = {
  fix = {
  hackname = stdio_va_list;
  files= stdio.h;
 -bypass   = '__gnuc_va_list|_BSD_VA_LIST_|__DJ_va_list|_G_va_list';
 +bypass   = '__gnuc_va_list|_BSD_VA_LIST_|__DJ_va_list|_G_va_list|BIONIC';
  /*
 + * In Bionic va_list is always appropriately typedefed to __gnuc_va_list.

And that typedef does not live in stdio.h either.
If there is no better way to identify this file, then

 Is it ok?

It is okay. (You may be left with little choice -- I can't see the header :).

Re: Remove unnecessary and harmful fixincludes for Android

[Bruce Korb]

Hi,

On Tue, Aug 5, 2014 at 10:36 AM, enh e...@google.com wrote:
 you can see the current version of bionic's stdio.h here:

 https://android.googlesource.com/platform/bionic/+/master/libc/include/stdio.h

 i'm happy to add any string to the header file that makes things
 easier. if you want 'x-gcc-no-fixincludes' or whatever in there, just
 say :-)

That would be great, but you could also add:

   /* this file depends on __gnuc_va_list being used for va_list */

and not bother changing fixincludes at all. :)  But either of those two
comments added to the header would be preferable to looking for BIONIC.
Thank you!

With one of the two changes, the patch is approved.   Thanks!

Re: Remove unnecessary and harmful fixincludes for Android

[Bruce Korb]

Hi,

Lines 42  43 are not needed for fixincludes, but it is your choice.
With that change, you should not need to add that test to fixincludes
because __gnuc_va_list will be found within the comment and satisfy
the bypass expression.

That was the long way of saying:
   Looks good to me.

On Tue, Aug 5, 2014 at 5:09 PM, enh e...@google.com wrote:
 does https://android-review.googlesource.com/103445 look okay?

 On Tue, Aug 5, 2014 at 12:01 PM, Bruce Korb bk...@gnu.org wrote:
 Hi,

 On Tue, Aug 5, 2014 at 10:36 AM, enh e...@google.com wrote:
 you can see the current version of bionic's stdio.h here:

 https://android.googlesource.com/platform/bionic/+/master/libc/include/stdio.h

 i'm happy to add any string to the header file that makes things
 easier. if you want 'x-gcc-no-fixincludes' or whatever in there, just
 say :-)

 That would be great, but you could also add:

/* this file depends on __gnuc_va_list being used for va_list */

 and not bother changing fixincludes at all. :)  But either of those two
 comments added to the header would be preferable to looking for BIONIC.
 Thank you!

 With one of the two changes, the patch is approved.   Thanks!

Re: [fixincludes] Fix iso/math_c99.h signbit on Solaris

[Bruce Korb]

Hi Rainer,

On Tue, Jul 1, 2014 at 4:22 AM, Rainer Orth r...@cebitec.uni-bielefeld.de 
wrote:
 It's not yet in autogen 5.9: I've diffed the fixincl.x generated with my
 original patch and the amended one and those backslashes after the
 leading tab are still there.

5.9 is 7 years old now.  However, I just looked up the change.  I did
it 2 years ago.
It would mean bumping the requirement to 5.17.4, from a mere 1 year ago.

 I've now managed to build autogen 5.18.3 on Solaris 11, but still there

Please send your managed to build stories.
If they are not Guile related, I can try to clean 'em up.
Building Guile is not for the feint of heart.

 is some trouble: with the following fix

 /*
  * Newer Solaris 10/11 GCC signbit implementations cause strict-aliasing
  * warnings.
  */
 fix = {
[...]
 };

 the test passes (not ran a bootstrap yet).  But I had to make two
 unexpected changes:

 * In the second c_fix_arg, all \t in charsets had to be replaced by
   literal TABs, otherwise they would occur as \\t in fixincl.x.

I made the here string largely similar to the shell here doc,
excepting there is no such thing as shell expansions (${var} stuff)
and I (now) erase that backslash-before-whitespace thingy.

 * In test_text, I had to backslash-escape the trailing \, otherwise they
   were eaten up.  Whether or not I do this makes no difference for the
   generated fixincl.x, but only with the escaping does make check pass.

Right.  It likely gets massaged by a shell script somewhere.
I'd need to look up how test-text gets used in the template.

 I'm currently fighting to build autogen 5.18.3 and all its dependencies.
 Trouble is, if we do require a version newer than 5.5.4 as documented in
 install.texi, fixincludes make check will suddenly start to fail for
 those whose autogen version isn't recent enough.

Every decade or so it ought to be possible to update by a few years.

 This is certainly something that needs to be decided: if we go this
 route, we should bump the autogen version requirement in install.texi
 (to whatever is necessary to support the TAB\ magic).

I think Debian stable has moved up to 5.18.2, if I am remembering
correctly.  It's a year old (last fall).  I think that is old enough to
have been spread around by now.

Thanks for looking into it.

Regards, Bruce

Re: [fixincludes] Fix iso/math_c99.h signbit on Solaris

[Bruce Korb]

On 06/26/14 02:18, Rainer Orth wrote:

Ok for mainline?


Could you please reformat the c_fix_arg's and test-text to be here strings a 
la:

c_fix_arg = - _EOS_
#undef  signbit
#define signbit(x)  (sizeof(x) == sizeof(float) \
\  ? __builtin_signbitf(x) \
\  : sizeof(x) == sizeof(long double) \
\? __builtin_signbitl(x) \
\: __builtin_signbit(x));
_EOS_;

I changed the here string thingy to eat that tab-backslash
and leave the rest of the tabs a few years ago.
That is considerably more readable than:

c_fix_arg = #undef\tsignbit\n
#define\tsignbit(x)\t(sizeof(x) == sizeof(float) \\\n
\t\t\t   ? __builtin_signbitf(x) \\\n
\t\t\t   : sizeof(x) == sizeof(long double) \\\n
\t\t\t ? __builtin_signbitl(x) \\\n
\t\t\t : __builtin_signbit(x));

and the other two are worse.  Thank you!

Re: Remove obsolete Solaris 9 support

[Bruce Korb]

On 04/16/14 04:16, Rainer Orth wrote:

I've already verified that trunk fails to build no sparc-sun-solaris2.9
and i386-pc-solaris2.9.  Bootstraps on {i386,sparc}-*-solaris2.{10,11}
(and x86_64-unknown-linux-gnu for good measure) are in progress.  I'll
verify that there are no unexpected fixincludes changes and differences
in gcc configure results.




fixincludes:
* inclhack.def (math_exception): Bypass on *-*-solaris2.1[0-9]*.
(solaris_int_types): Remove.
(solaris_longjmp_noreturn): Remove.
(solaris_mutex_init_2): Remove.
(solaris_once_init_2): Remove.
(solaris_sys_va_list): Remove.
* fixincl.x: Regenerate.
* tests/base/iso/setjmp_iso.h: Remove.
* tests/base/pthread.h [SOLARIS_MUTEX_INIT_2_CHECK]: Remove.
[SOLARIS_ONCE_INIT_2_CHECK]: Remove.
* tests/base/sys/int_types.h: Remove.
* tests/base/sys/va_list.h: Remove.


Removing dinkleberry fixes by the platform maintainer always has my approval. :)

Re: configure check for flex

[Bruce Korb]

On 01/27/14 18:20, Hans-Peter Nilsson wrote:

You'd need some additional conditions.  There might be the
additional issue that any lex is expected to work too, not
just flex.


It isn't committed 'cuz nobody said, Okay.
I do wish either someone would say, Okay. or come up with something
that works.
I went to the effort to figure out where things got off the rails and
did something that
worked for me.  Just saying, That won't work without a workable alternative
is a bit irritating.


There are surely plenty of opportunities around for
irritatation! :)  Dropped patches surely; I thought I was
helpful there.  Ungraceful errors from easily identifiable
common gotchas definitely, so what you're trying to achieve is
IMHO desirable.  Patches hacking in something that just happened
to work for someone too; I tried to stop that from happening.


I spend my programming life either hacking at a startup or maintaining
a few GNU tools I'm responsible for (e.g. fixincludes).  This is
outside of that realm, so I'm trying to produce enough of a patch
that someone who knows how better than I do can finish it.

I put my patch into the top level configure.ac file, not the
gcc or libcpp ones.  I suppose I could hack out the logic for
setting is_release from those files, but really the crucial part
is just having an intelligible error message that leads someone
with a removed flex tool to a resolution of the issue.
Someday maybe important tools won't disappear on you when
you update your distribution, but barring that, the silent
requirement for flex combined with an uninformative error
message yields a booby trap.  I hate booby traps.:)

Cheers - Bruce



$ svn diff configure.ac
Index: configure.ac
===
--- configure.ac(revision 208044)
+++ configure.ac(working copy)
@@ -1319,10 +1319,17 @@
 # Used for setting $lt_cv_objdir
 _LT_CHECK_OBJDIR

-# Check for GMP, MPFR and MPC
+# Check for flex, GMP, MPFR and MPC
+[for p in flex
+do
+  c=`command -v $p`
+  test -x $c || \
+]AC_MSG_ERROR([the $c command is required to build GCC])[
+done
+
 gmplibs=-lmpc -lmpfr -lgmp
 gmpinc=
-have_gmp=no
+have_gmp=no]

 # Specify a location for mpc
 # check for this first so it ends up on the link line before mpfr.

Re: configure check for flex

[Bruce Korb]

In retrospect, it occurs to me that a am-i-ready-to-build.sh script
in the contrib directory might be useful, too.

Re: configure check for flex

[Bruce Korb]

On Sun, Jan 26, 2014 at 9:38 PM, Hans-Peter Nilsson h...@bitrange.com wrote:
 On Sun, 8 Dec 2013, Bruce Korb wrote:
 On 12/08/13 13:06, Gerald Pfeifer wrote:
  Lovely.  Thank you very much!

 (Looks like nobody replied to this and it isn't committed.)

 No, flex isn't required to build GCC as a hard and fast rule.
 It's not required for releases, just when building from a svn
 checkout (or really: when the flex-generated files are not in
 the source directory).

 You'd need some additional conditions.  There might be the
 additional issue that any lex is expected to work too, not
 just flex.

It isn't committed 'cuz nobody said, Okay.
I do wish either someone would say, Okay. or come up with something
that works.
I went to the effort to figure out where things got off the rails and
did something that
worked for me.  Just saying, That won't work without a workable alternative
is a bit irritating.

I do not know the difference between a checkout build and a normal
configured build.  My understanding was that generated files were to
be part of the repo and that there was *not* a difference.  If there is,
then someone who understands the difference could maybe add some
configure infrastructure to test the environment and decide if flex (or lex)
was needed, rather than just say, what you did won't work.

fixinclude patch for fenv.h on Ubuntu

[Bruce Korb]

Adjusted for Richard Biener's patch
Index: fixincludes/ChangeLog
===
--- fixincludes/ChangeLog	(revision 205790)
+++ fixincludes/ChangeLog	(working copy)
@@ -1,3 +1,14 @@
+2013-12-07  Bruce Korb  bk...@gnu.org
+
+	* inclhack.def: many of the headers found under bits/ are
+	often stashed under architecture directories.  Apply fixes
+	to those, too.  Also, re-ordered misordered fixes.
+	* tests/base/linux/vt.h: 80 columns in .def file limitation
+	* tests/base/iso/math_c99.h: adjust ordering
+	* tests/base/rtldef/string.h: likewise
+	* tests/base/bits/fenv.h: likewise
+	* tests/base/pthread.h: likewise
+
 2013-12-06  Richard Biener  rguent...@suse.de
 
 	* inclhack.def (suse_linux_vt_cxx): New fix for linux/vt.h
Index: fixincludes/fixincl.x
===
--- fixincludes/fixincl.x	(revision 205790)
[[generated]]

Index: fixincludes/tests/base/iso/math_c99.h
===
--- fixincludes/tests/base/iso/math_c99.h	(revision 205790)
+++ fixincludes/tests/base/iso/math_c99.h	(working copy)
@@ -20,6 +20,13 @@
 #endif  /* SOLARIS_MATH_1_CHECK */
 
 
+#if defined( SOLARIS_MATH_10_CHECK )
+#pragma ident	@(#)math_c99.h	1.12	07/01/21 SMI
+#undef	isinf
+#define	isinf(x) __builtin_isinf(x)
+#endif  /* SOLARIS_MATH_10_CHECK */
+
+
 #if defined( SOLARIS_MATH_2_CHECK )
 #ident	@(#)math_c99.h	1.9	04/11/01 SMI
 #undef	INFINITY
@@ -68,10 +75,3 @@
 #undef	isunordered
 #define	isunordered(x, y)	__builtin_isunordered(x, y)
 #endif  /* SOLARIS_MATH_9_CHECK */
-
-
-#if defined( SOLARIS_MATH_10_CHECK )
-#pragma ident	@(#)math_c99.h	1.12	07/01/21 SMI
-#undef	isinf
-#define	isinf(x) __builtin_isinf(x)
-#endif  /* SOLARIS_MATH_10_CHECK */
Index: fixincludes/tests/base/bits/fenv.h
===
--- fixincludes/tests/base/bits/fenv.h	(revision 205790)
+++ fixincludes/tests/base/bits/fenv.h	(working copy)
@@ -9,6 +9,16 @@
 
 
 
+#if defined( FERAISEEXCEPT_NOSSE_DIVBYZERO_CHECK )
+# ifdef __SSE_MATH__
+  __asm__ __volatile__ (divss %1, %0 : : x (__f), x (__g));
+# else
+  __asm__ __volatile__ (fdivp %%st, %%st(1); fwait
+  			: =t (__f) : 0 (__f), u (__g) : st(1));
+# endif
+#endif  /* FERAISEEXCEPT_NOSSE_DIVBYZERO_CHECK */
+
+
 #if defined( FERAISEEXCEPT_NOSSE_INVALID_CHECK )
 # ifdef __SSE_MATH__
   __asm__ __volatile__ (divss %0, %0 : : x (__f));
@@ -17,13 +27,3 @@
   			: =t (__f) : 0 (__f));
 # endif
 #endif  /* FERAISEEXCEPT_NOSSE_INVALID_CHECK */
-
-
-#if defined( FERAISEEXCEPT_NOSSE_DIVBYZERO_CHECK )
-# ifdef __SSE_MATH__
-  __asm__ __volatile__ (divss %1, %0 : : x (__f), x (__g));
-# else
-  __asm__ __volatile__ (fdivp %%st, %%st(1); fwait
-  			: =t (__f) : 0 (__f), u (__g) : st(1));
-# endif
-#endif  /* FERAISEEXCEPT_NOSSE_DIVBYZERO_CHECK */
Index: fixincludes/tests/base/rtldef/string.h
===
--- fixincludes/tests/base/rtldef/string.h	(revision 205790)
+++ fixincludes/tests/base/rtldef/string.h	(working copy)
@@ -9,13 +9,13 @@
 
 
 
+#if defined( VMS_DECC_BUILTIN_CHECK )
+define FD_ZERO(__p) memset((__p), 0, sizeof(*(__p)))
+
+#endif  /* VMS_DECC_BUILTIN_CHECK */
+
+
 #if defined( VMS_DISABLE_DECC_STRING_BUILTINS_CHECK )
 #if !defined(__VAX)  !defined(__GNUC__)
 
 #endif  /* VMS_DISABLE_DECC_STRING_BUILTINS_CHECK */
-
-
-#if defined( VMS_DECC_BUILTIN_CHECK )
-define FD_ZERO(__p) memset((__p), 0, sizeof(*(__p)))
-
-#endif  /* VMS_DECC_BUILTIN_CHECK */
Index: fixincludes/tests/base/linux/vt.h
===
--- fixincludes/tests/base/linux/vt.h	(revision 205790)
+++ fixincludes/tests/base/linux/vt.h	(working copy)
@@ -10,5 +10,5 @@
 
 
 #if defined( SUSE_LINUX_VT_CXX_CHECK )
-unsigned int newev;   /* New console (if changing) */
+unsigned int newev;  /* New console (if changing) */
 #endif  /* SUSE_LINUX_VT_CXX_CHECK */
Index: fixincludes/tests/base/pthread.h
===
--- fixincludes/tests/base/pthread.h	(revision 205790)
+++ fixincludes/tests/base/pthread.h	(working copy)
@@ -125,16 +125,6 @@
 #endif  /* SOLARIS_MUTEX_INIT_2_CHECK */
 
 
-#if defined( SOLARIS_RWLOCK_INIT_1_CHECK )
-#ident @(#)pthread.h  1.26  98/04/12 SMI
-#if __STDC__ - 0 == 0  !defined(_NO_LONGLONG)
-#define PTHREAD_RWLOCK_INITIALIZER	{0, 0, 0, {0, 0, 0}, {0, 0}, {0, 0}}
-#else
-#define PTHREAD_RWLOCK_INITIALIZER	{0, 0, 0, {{0}, {0}, {0}}, {{0}, {0}}, {{0}, {0}}}
-#endif
-#endif  /* SOLARIS_RWLOCK_INIT_1_CHECK */
-
-
 #if defined( SOLARIS_ONCE_INIT_1_CHECK )
 #pragma ident	@(#)pthread.h	1.37	04/09/28 SMI
 #if __STDC__ - 0 == 0  !defined(_NO_LONGLONG)
@@ -156,6 +146,16 @@
 #endif  /* SOLARIS_ONCE_INIT_2_CHECK */
 
 
+#if defined( SOLARIS_RWLOCK_INIT_1_CHECK )
+#ident @(#)pthread.h  1.26  98/04/12 SMI
+#if __STDC__ - 0 == 0  !defined(_NO_LONGLONG

Re: configure check for flex

[Bruce Korb]

On 12/08/13 13:06, Gerald Pfeifer wrote:

Lovely.  Thank you very much!



$ svn diff
Index: configure.ac
===
--- configure.ac(revision 205790)
+++ configure.ac(working copy)
@@ -1319,10 +1319,17 @@
 # Used for setting $lt_cv_objdir
 _LT_CHECK_OBJDIR

-# Check for GMP, MPFR and MPC
+# Check for flex, GMP, MPFR and MPC
+[for p in flex
+do
+  c=`command -v $p`
+  test -x $c || \
+]AC_MSG_ERROR([the $p command is required to build GCC])[
+done
+
 gmplibs=-lmpc -lmpfr -lgmp
 gmpinc=
-have_gmp=no
+have_gmp=no]

 # Specify a location for mpc
 # check for this first so it ends up on the link line before mpfr.

fixinclude patch for fenv.h on Ubuntu

[Bruce Korb]

This patch fixes Ian's issue, and several similar patterns:
http://gcc.gnu.org/ml/gcc-patches/2013-11/msg00681.html

$ make check
autogen -T ../.././fixincludes/check.tpl ../.././fixincludes/inclhack.def
/bin/sh ./check.sh ../.././fixincludes/tests/base
Fixed:  testing.h
[[...]]
Fixed:  unistd.h

All fixinclude tests pass
/u/gnu/proj/gcc-svn-bld/build-x86_64-unknown-linux-gnu/fixincludes

Full build for x86-64 in progress.  Patch submission likely tomorrow.
Index: fixincludes/ChangeLog
===
--- fixincludes/ChangeLog	(revision 204533)
+++ fixincludes/ChangeLog	(working copy)
@@ -1,3 +1,9 @@
+2013-09-20  Bruce Korb  bk...@gnu.org
+
+	* inclhack.def: many of the headers found under bits/ are
+	often stashed under architecture directories.  Apply fixes
+	to those, too.  Also, re-ordered a couple of misordered fixes.
+
 2013-09-20  Alan Modra  amo...@gmail.com
 
 	* configure: Regenerate.
Index: fixincludes/fixincl.x
===
--- fixincludes/fixincl.x	(revision 204533)
+++ fixincludes/fixincl.x	(working copy)
[[generated]]

Index: fixincludes/inclhack.def
===
--- fixincludes/inclhack.def	(revision 204533)
+++ fixincludes/inclhack.def	(working copy)
@@ -1140,6 +1140,20 @@
 };
 
 /*
+ *  Old Linux kernel's compiler.h header breaks Traditional CPP
+ */
+fix = {
+hackname  = complier_h_tradcpp;
+files = linux/compiler.h;
+
+select= #define __builtin_warning\\(x, y\\.\\.\\.\\) \\(1\\);
+c_fix = format;
+c_fix_arg = /* __builtin_warning(x, y...) is obsolete */;
+
+test_text = #define __builtin_warning(x, y...) (1);
+};
+
+/*
  *  Fix various macros used to define ioctl numbers.
  *  The traditional syntax was:
  *
@@ -1509,6 +1523,60 @@
 };
 
 /*
+ *  Incorrect feraiseexcept extern inline in bits/fenv.h on x86_64
+ *  that fails when compiling for SSE-less 32-bit x86.
+ */
+fix = {
+hackname  = feraiseexcept_nosse_invalid;
+mach  = 'i[34567]86-*-linux*', 'x86*-linux*', 'amd64-*-linux*';
+files = bits/fenv.h, '*/bits/fenv.h';
+select= ^([\t ]*)__asm__ __volatile__ \\(\divss %0, %0 *\ : 
+		: \x\ \\(__f\\)\\);$;
+bypass= \fdiv .*; fwait\;
+
+c_fix = format;
+c_fix_arg = - _EOText_
+	# ifdef __SSE_MATH__
+	%0
+	# else
+	%1__asm__ __volatile__ (fdiv st, st(0); fwait
+	%1			: =t (__f) : 0 (__f));
+	# endif
+	_EOText_;
+
+test_text = - _EOText_
+	  __asm__ __volatile__ (divss %0, %0 : : x (__f));
+	_EOText_;
+};
+
+/*
+ *  Incorrect feraiseexcept extern inline in bits/fenv.h on x86_64
+ *  that fails when compiling for SSE-less 32-bit x86.
+ */
+fix = {
+hackname  = feraiseexcept_nosse_divbyzero;
+mach  = 'i[34567]86-*-linux*', 'x86*-linux*', 'amd64-*-linux*';
+files = bits/fenv.h, '*/bits/fenv.h';
+select= ^([\t ]*)__asm__ __volatile__ \\(\divss %1, %0 *\ : 
+		: \x\ \\(__f\\), \x\ \\(__g\\)\\);$;
+bypass= \fdivp .*; fwait\;
+
+c_fix = format;
+c_fix_arg = - _EOText_
+	# ifdef __SSE_MATH__
+	%0
+	# else
+	%1__asm__ __volatile__ (fdivp st, st(1); fwait
+	%1			: =t (__f) : 0 (__f), u (__g) : st(1));
+	# endif
+	_EOText_;
+
+test_text = - _EOText_
+	  __asm__ __volatile__ (divss %1, %0 : : x (__f), x (__g));
+	_EOText_;
+};
+
+/*
  *  Between 8/24/1998 and 2/17/2001, FreeBSD system headers presume
  *  neither the existence of GCC 3 nor its exact feature set yet break
  *  (by design?) when __GNUC__ is set beyond 2.
@@ -1738,7 +1806,7 @@
versions.  */
 fix = {
 hackname  = glibc_strncpy;
-files = bits/string2.h;
+files = bits/string2.h, '*/bits/string2.h';
 bypass= __builtin_strncpy;
 c_fix = format;
 c_fix_arg = #  define strncpy(dest, src, n) __builtin_strncpy (dest, src, n);
@@ -2411,7 +2479,7 @@
  */
 fix = {
 hackname  = huge_val_hex;
-files = bits/huge_val.h;
+files = bits/huge_val.h, '*/bits/huge_val.h';
 select= ^#[ \t]*define[ \t]*HUGE_VAL[ \t].*0x1\\.0p.*;
 bypass= __builtin_huge_val;
 
@@ -2426,7 +2494,7 @@
  */
 fix = {
 hackname  = huge_valf_hex;
-files = bits/huge_val.h;
+files = bits/huge_val.h, '*/bits/huge_val.h';
 select= ^#[ \t]*define[ \t]*HUGE_VALF[ \t].*0x1\\.0p.*;
 bypass= __builtin_huge_valf;
 
@@ -2441,7 +2509,7 @@
  */
 fix = {
 hackname  = huge_vall_hex;
-files = bits/huge_val.h;
+files = bits/huge_val.h, '*/bits/huge_val.h';
 select= ^#[ \t]*define[ \t]*HUGE_VALL[ \t].*0x1\\.0p.*;
 bypass= __builtin_huge_vall;
 
@@ -4226,7 +4294,7 @@
 fix = {
 hackname  = thread_keyword;
 files = pthread.h;
-files = bits/sigthread.h;
+files = bits/sigthread.h, '*/bits/sigthread.h';
 select= ([* ])__thread([,)]);
 c_fix = format;
 c_fix_arg = %1__thr%2;
@@ -4760,72 +4828,4

Re: [PATCH] fixincludes: use $(FI) instead of fixincl@EXEEXT@

[Bruce Korb]

Sure.  Looks good to me.  Thanks

On Fri, Nov 8, 2013 at 2:57 AM, Bernhard Reutner-Fischer
rep.dot@gmail.com wrote:
 On 4 April 2013 22:20, Bruce Korb bk...@gnu.org wrote:
 Except as noted below, fine by me.

 On 04/04/13 12:56, Bernhard Reutner-Fischer wrote:
 Bootstrapped and regtested on x86_64-unknown-linux-gnu and
 x86_64-mine-linux-uclibc without regressions, ok for trunk?

 fixincludes/ChangeLog:

 2013-04-04  Bernhard Reutner-Fischer  al...@gcc.gnu.org

   Makefile.in: Use $(FI) instead of fixincl@EXEEXT@.
   Cleanup whitespace while at it.

 Signed-off-by: Bernhard Reutner-Fischer rep.dot@gmail.com
 ---
  fixincludes/Makefile.in |   10 +-
  1 file changed, 5 insertions(+), 5 deletions(-)

 diff --git a/fixincludes/Makefile.in b/fixincludes/Makefile.in
 index ce850ff..3dc869d 100644
 --- a/fixincludes/Makefile.in
 +++ b/fixincludes/Makefile.in
 @@ -131,7 +131,7 @@ fixinc.sh : fixinc.in mkfixinc.sh Makefile
  $(srcdir)/fixincl.x: @MAINT@ fixincl.tpl inclhack.def
   cd $(srcdir) ; $(SHELL) ./genfixes

 -mostlyclean :
 +mostlyclean:

 I see no reason for changing things.

 dropped this hunk.

 But if you are going to clean up the colons, then they should
 be in columns (mostly 12 or 16).  This one is already in 12.

   rm -f *.o *-stamp $(AF) $(FI) *~ fixinc.sh

  clean: mostlyclean
 @@ -179,18 +179,18 @@ check : all

  install : all
   -rm -rf $(DESTDIR)$(itoolsdir)
 - $(mkinstalldirs) $(DESTDIR)$(itoolsdir)
 + $(mkinstalldirs) $(DESTDIR)$(itoolsdir)
   $(mkinstalldirs) $(DESTDIR)$(itoolsdatadir)/include
   $(INSTALL_DATA) $(srcdir)/README-fixinc \
 $(DESTDIR)$(itoolsdatadir)/include/README
   $(INSTALL_SCRIPT) fixinc.sh $(DESTDIR)$(itoolsdir)/fixinc.sh
 - $(INSTALL_PROGRAM) fixincl@EXEEXT@ \
 -   $(DESTDIR)$(itoolsdir)/fixincl@EXEEXT@
 + $(INSTALL_PROGRAM) $(FI) \
 +   $(DESTDIR)$(itoolsdir)/$(FI)

 This should now fit on a single line.

 ok

   $(INSTALL_SCRIPT) mkheaders $(DESTDIR)$(itoolsdir)/mkheaders

  install-strip: install
   test -z '$(STRIP)' \
 -   || $(STRIP) $(DESTDIR)$(itoolsdir)/fixincl@EXEEXT@
 +   || $(STRIP) $(DESTDIR)$(itoolsdir)/$(FI)

 changed this too to be on a single line now.

  .PHONY: all check install install-strip
  .PHONY: dvi pdf info html install-pdf install-info install-html

 Changelog remains the same.
 II was using the attached updated patch since April, ok for trunk?

Re: fixincludes patch RFA: Fix fenv.h on Ubuntu Precise

[Bruce Korb]

On 11/06/13 15:29, Ian Lance Taylor wrote:

When fenv.h is not fixed, libquadmath does not build.

This patch works around the problem.  Bootstrapped and tested on
x86_64-unknown-linux-gnu.

OK for mainline?


Hi Ian,

Yes, please.

This time, I'm on my dev box and looked at the code.
You remembered correctly that the first file name in the list
of file names needs to not have wild card characters so that
the testing scheme can create a file by that name.  A directory
named * is possible, but inconvenient.

Anyway, it also matches prior art in:


/*
 * glibc_c99_inline_3
 */
fix = {
hackname  = glibc_c99_inline_3;
files = bits/string2.h, '*/bits/string2.h';


but is inconsistent with:


/* Some versions of glibc have a version of bits/string2.h that
   produces value computed is not used warnings from strncpy; fix
   this definition by using __builtin_strncpy instead as in newer
   versions.  */
fix = {
hackname  = glibc_strncpy;
files = bits/string2.h;


Hmmm.  Does that fix need fixing, too?

Thanks -Bruce

Re: fixincludes patch RFA: Fix fenv.h on Ubuntu Precise

[Bruce Korb]

So is this the right patch?


$ svn diff inclhack.def
Index: inclhack.def
===
--- inclhack.def(revision 204533)
+++ inclhack.def(working copy)
@@ -1738,7 +1738,7 @@
versions.  */
 fix = {
 hackname  = glibc_strncpy;
-files = bits/string2.h;
+files = bits/string2.h, '*/bits/string2.h';
 bypass= __builtin_strncpy;
 c_fix = format;
 c_fix_arg = #  define strncpy(dest, src, n) __builtin_strncpy (dest, src, 
n);
@@ -2411,7 +2411,7 @@
  */
 fix = {
 hackname  = huge_val_hex;
-files = bits/huge_val.h;
+files = bits/huge_val.h, '*/bits/huge_val.h';
 select= ^#[ \t]*define[ \t]*HUGE_VAL[ \t].*0x1\\.0p.*;
 bypass= __builtin_huge_val;

@@ -2426,7 +2426,7 @@
  */
 fix = {
 hackname  = huge_valf_hex;
-files = bits/huge_val.h;
+files = bits/huge_val.h, '*/bits/huge_val.h';
 select= ^#[ \t]*define[ \t]*HUGE_VALF[ \t].*0x1\\.0p.*;
 bypass= __builtin_huge_valf;

@@ -2441,7 +2441,7 @@
  */
 fix = {
 hackname  = huge_vall_hex;
-files = bits/huge_val.h;
+files = bits/huge_val.h, '*/bits/huge_val.h';
 select= ^#[ \t]*define[ \t]*HUGE_VALL[ \t].*0x1\\.0p.*;
 bypass= __builtin_huge_vall;

@@ -4226,7 +4226,7 @@
 fix = {
 hackname  = thread_keyword;
 files = pthread.h;
-files = bits/sigthread.h;
+files = bits/sigthread.h, '*/bits/sigthread.h';
 select= ([* ])__thread([,)]);
 c_fix = format;
 c_fix_arg = %1__thr%2;
@@ -4767,7 +4767,7 @@
 fix = {
 hackname  = feraiseexcept_nosse_invalid;
 mach  = 'i[34567]86-*-linux*', 'x86*-linux*', 'amd64-*-linux*';
-files = bits/fenv.h;
+files = bits/fenv.h, '*/bits/fenv.h';
 select= ^([\t ]*)__asm__ __volatile__ \\(\divss %0, %0 *\ : 
: \x\ \\(__f\\)\\);$;
 bypass= \fdiv .*; fwait\;
@@ -4794,7 +4794,7 @@
 fix = {
 hackname  = feraiseexcept_nosse_divbyzero;
 mach  = 'i[34567]86-*-linux*', 'x86*-linux*', 'amd64-*-linux*';
-files = bits/fenv.h;
+files = bits/fenv.h, '*/bits/fenv.h';
 select= ^([\t ]*)__asm__ __volatile__ \\(\divss %1, %0 *\ : 
: \x\ \\(__f\\), \x\ \\(__g\\)\\);$;
 bypass= \fdivp .*; fwait\;

Re: fixincludes patch RFA: Fix fenv.h on Ubuntu Precise

[Bruce Korb]

OK.  It will be a couple of days.

On Thu, Nov 7, 2013 at 1:01 PM, Ian Lance Taylor i...@google.com wrote:
 In the meantime I've committed my version of the patch to the gccgo
 branch.  It will be updated to whatever the final mainline version is
 the next time I merge from mainline to the gccgo branch.

 Ian

 On Thu, Nov 7, 2013 at 10:16 AM, Ian Lance Taylor i...@google.com wrote:
 On Thu, Nov 7, 2013 at 8:48 AM, Bruce Korb bk...@gnu.org wrote:

 This time, I'm on my dev box and looked at the code.
 You remembered correctly that the first file name in the list
 of file names needs to not have wild card characters so that
 the testing scheme can create a file by that name.  A directory
 named * is possible, but inconvenient.

 Anyway, it also matches prior art in:

 /*
  * glibc_c99_inline_3
  */
 fix = {
 hackname  = glibc_c99_inline_3;
 files = bits/string2.h, '*/bits/string2.h';


 but is inconsistent with:

 /* Some versions of glibc have a version of bits/string2.h that
produces value computed is not used warnings from strncpy; fix
this definition by using __builtin_strncpy instead as in newer
versions.  */
 fix = {
 hackname  = glibc_strncpy;
 files = bits/string2.h;


 Hmmm.  Does that fix need fixing, too?

 I didn't worry about that and the other cases because they are fixing
 problems that existed in past glibc versions before Ubuntu changed
 their directory layouts.  But of course there is nothing wrong with
 fixing them too.

 Your proposed patch looks fine to me and I think you should go ahead
 and commit.  Or I can if you prefer for some reason.

 Ian

Re: [PATCH,fixincldes] AIX assert.h static_assert

[Bruce Korb]

Sure.  Looks fine.  Please apply to all active branches.

On Sat, Aug 31, 2013 at 4:40 PM, David Edelsohn dje@gmail.com wrote:

Re: fatal error: gnu/stubs-32.h: No such file

[Bruce Korb]

On Mon, Jul 29, 2013 at 6:22 AM, Andrew Haley a...@redhat.com wrote:

 There should be a better diagnostic.

If you remember, the start of this thread was:

 Why is it that configure worked but stubs-32.h was not found?

That is the correct thing to do.  The reply, basically, was:

It's too hard.

OK, fine, the backup is to Google:

fatal error: gnu/stubs-32.h: No such file or directory

and have an early hit that tells you that you did not configure some 32 bit
developer package you had never heard of before.  I guess that's easier
than configure tests or #error directives for the folks who do the
multi-lib stuff.

  But we know people are running into this issue and reporting it.
 Yes.  But that on its own is not sufficient to change the default

That's a pretty obnoxious comment.  I translate it as, I don't care if
people are having trouble.  It is a nuisance to me to do that and anyone
building GCC should already know they need whateveritwas-devel for
32 bits.  I guess I can be obnoxious, too.  But slightly more politely put:

 No, we aren't. We're disagreeing about whether it's acceptable to
 enable a feature by default that breaks the compiler build half way
 through with an obscure error message. Real systems need features that
 aren't enabled by default sometimes.

The fundamental issue, to me, is:  What do you do when you cannot proceed?

I think you should detect the issue as *soon as practical* and then *ALWAYS*
emit a message that *TELLS THE USER WHAT TO DO*.  This failure is
later than it could be and leaves the user hanging and twisting in the wind.

Not good.

Re: fixincludes 2013-05-23

[Bruce Korb]

Hi,

On Mon, Jul 8, 2013 at 5:05 AM, Alexander Ivchenko aivch...@gmail.com wrote:
 Hi Bruce,

 That was my original letter:
Hi,

Could you please take a look at the attached fixinclude patch
that addresses the problem:

  We have test fail for gcc.dg/cpp/trad/include.c on Android. The
reason for that is that
-ftraditional-cpp is not expected to work on Android due to variadic
macro (like #define __builtin_warning(x, y...))
in standard headers and traditional preprocessor cannot handle them.

is it ok for trunk?

thanks,
Alexander

 So I did ask whether it is ok or not. And then I got:

 Be sure to ask, Ok? in your patch submittals.

 Ok.

Oops.  Wrong word.  I said, you didn't ask and meant to say
you didn't get approval.  I didn't see the original request because
there was no hint about fixincludes in the subject and I was not
on the to/cc line.  So you asked, just not effectively enough for
me to see it and you did _not_ get approval.

Still:

  Also, I prefer that the hacks get inserted
 alphabetically.  So, actually, there are a few small complaints.

 The patch looks pretty reasonable, but I think someone else
 should verify the obsolescence.  I also think it should be renamed to
 something like obsolete_builtin_warning because the current
 name gives no clue about what it really is.

 /*
  *  Old Linux kernel's compiler.h header breaks Traditional CPP
  */
 fix = {
 hackname  = complier_h_tradcpp;
 files = linux/compiler.h;

 select= #define __builtin_warning\\(x, y\\.\\.\\.\\) \\(1\\);
 c_fix = format;
 c_fix_arg = /* __builtin_warning(x, y...) is obsolete */;

 test_text = #define __builtin_warning(x, y...) (1);
 };

Please be kind enough to belatedly finish up and we'll (I'll) reapply it.

Re: fixincludes 2013-05-23

[Bruce Korb]

On Mon, Jul 8, 2013 at 11:42 AM, Alexander Ivchenko aivch...@gmail.com wrote:
 It sounds like it is better to fix the system headers instead.  Via a
 fixincludes for older headers and have the android folks fix them for
 newer releases.

 Would that count for verifing? :)

:) Indeed.  I confess I didn't look past March.
The patch is now in my inbox.  I'll try to get to it next weekend.

Fix Bug 51776 (finally...)

[Bruce Korb]

 Index: ChangeLog
===
--- ChangeLog	(revision 200737)
+++ ChangeLog	(working copy)
@@ -1,3 +1,7 @@
+2013-07-06  Bruce Korb  bk...@gnu.org
+
+	* inclhack.def (cdef_cplusplus): removed, per Bug 51776
+
 2013-05-23  Alexander Ivchenko alexander.ivche...@intel.com
 
 	* inclhack.def (complier_h_tradcpp): New.
Index: fixincl.x
===
--- fixincl.x	(revision 200737)
+++ fixincl.x	(working copy)
@@ -1,12 +1,12 @@
 /*  -*- buffer-read-only: t -*- vi: set ro:
- * 
+ *
  * DO NOT EDIT THIS FILE   (fixincl.x)
- * 
- * It has been AutoGen-ed  May 23, 2013 at 04:44:10 PM by AutoGen 5.12
+ *
+ * It has been AutoGen-ed  July  6, 2013 at 10:40:53 AM by AutoGen 5.17.5pre10
  * From the definitionsinclhack.def
  * and the template file   fixincl
  */
-/* DO NOT SVN-MERGE THIS FILE, EITHER Thu May 23 16:44:10 MSK 2013
+/* DO NOT SVN-MERGE THIS FILE, EITHER Sat Jul  6 10:40:53 PDT 2013
  *
  * You must regenerate it.  Use the ./genfixes script.
  *
@@ -15,7 +15,7 @@
  * certain ANSI-incompatible system header files which are fixed to work
  * correctly with ANSI C and placed in a directory that GNU C will search.
  *
- * This file contains 228 fixup descriptions.
+ * This file contains 227 fixup descriptions.
  *
  * See README for more information.
  *
@@ -2072,41 +2072,6 @@
 
 /* * * * * * * * * * * * * * * * * * * * * * * * * *
  *
- *  Description of Cdef_Cplusplus fix
- */
-tSCC zCdef_CplusplusName[] =
- cdef_cplusplus;
-
-/*
- *  File name selection pattern
- */
-tSCC zCdef_CplusplusList[] =
-  sys/cdefs.h\0;
-/*
- *  Machine/OS name selection pattern
- */
-#define apzCdef_CplusplusMachs (const char**)NULL
-
-/*
- *  content selection pattern - do fix if pattern found
- */
-tSCC zCdef_CplusplusSelect0[] =
-   \\[\\[noreturn\\]\\];
-
-#defineCDEF_CPLUSPLUS_TEST_CT  1
-static tTestDesc aCdef_CplusplusTests[] = {
-  { TT_EGREP,zCdef_CplusplusSelect0, (regex_t*)NULL }, };
-
-/*
- *  Fix Command Arguments for Cdef_Cplusplus
- */
-static const char* apzCdef_CplusplusPatch[] = {
-format,
-__attribute__((__noreturn__)),
-(char*)NULL };
-
-/* * * * * * * * * * * * * * * * * * * * * * * * * *
- *
  *  Description of Ctrl_Quotes_Def fix
  */
 tSCC zCtrl_Quotes_DefName[] =
@@ -9364,9 +9329,9 @@
  *
  *  List of all fixes
  */
-#define REGEX_COUNT  267
+#define REGEX_COUNT  266
 #define MACH_LIST_SIZE_LIMIT 187
-#define FIX_COUNT228
+#define FIX_COUNT227
 
 /*
  *  Enumerate the fixes
@@ -9418,7 +9383,6 @@
 BROKEN_CABS_FIXIDX,
 BROKEN_NAN_FIXIDX,
 BSD_STDIO_ATTRS_CONFLICT_FIXIDX,
-CDEF_CPLUSPLUS_FIXIDX,
 CTRL_QUOTES_DEF_FIXIDX,
 CTRL_QUOTES_USE_FIXIDX,
 CXX_UNREADY_FIXIDX,
@@ -9833,11 +9797,6 @@
  BSD_STDIO_ATTRS_CONFLICT_TEST_CT, FD_MACH_ONLY | FD_SUBROUTINE,
  aBsd_Stdio_Attrs_ConflictTests,   apzBsd_Stdio_Attrs_ConflictPatch, 0 },
 
-  {  zCdef_CplusplusName,zCdef_CplusplusList,
- apzCdef_CplusplusMachs,
- CDEF_CPLUSPLUS_TEST_CT, FD_MACH_ONLY | FD_SUBROUTINE,
- aCdef_CplusplusTests,   apzCdef_CplusplusPatch, 0 },
-
   {  zCtrl_Quotes_DefName,zCtrl_Quotes_DefList,
  apzCtrl_Quotes_DefMachs,
  CTRL_QUOTES_DEF_TEST_CT, FD_MACH_ONLY | FD_SUBROUTINE,
Index: inclhack.def
===
--- inclhack.def	(revision 200737)
+++ inclhack.def	(working copy)
@@ -64,7 +64,6 @@
 	_EOArg_;
 };
 
-
 /* On AIX when _LARGE_FILES is defined fcntl.h defines open to
  * open64 and creat to creat64.  This fixes fcntl.h to
  * undef those defines and use __asm__ to alias the symbols if
@@ -103,7 +102,6 @@
 	_EOArg_;
 };
 
-
 /*
  *  On Mac OS 10.3.9, the 'long double' functions are available in
  *  libSystem, but are not prototyped in math.h.
@@ -237,7 +235,6 @@
 	_EndOfHeader_;
 };
 
-
 /*
  *  This fixes __FD_ZERO bug for glibc-1.x
  */
@@ -275,7 +272,6 @@
 	_EndOfHeader_;
 };
 
-
 /*
  *  This fixes __FD_ZERO bug for glibc-2.0.x
  */
@@ -317,7 +313,6 @@
 	_EndOfHeader_;
 };
 
-
 /*
  * Solaris sys/varargs.h is a DDK (aka kernel-land) header providing
  * the same interface as stdarg.h.  No idea why they couldn't have just
@@ -336,7 +331,6 @@
 	_EndOfHeader_;
 };
 
-
 /*
  *  Fix non-ANSI memcpy declaration that conflicts with gcc's builtin
  *  declaration on Sun OS 4.x.  We must only fix this on Sun OS 4.x, because
@@ -574,7 +568,6 @@
 	_EndOfHeader_;
 };
 
-
 /*
  * complex.h on AIX 5 and AIX 6 define _Complex_I and I in terms of __I,
  * which only is provided by AIX xlc C99.
@@ -727,7 +720,6 @@
 {...init stuff...};
 };
 
-
 /*
  *  AIX stdint.h fixes.
  */
@@ -744,7 +736,9 @@
 		#define UINT16_MAX	(65535U);
 };
 
-
+/*
+ * aix_stdint_2
+ */
 fix = {
 hackname  = aix_stdint_2;
 mach  = *-*-aix*;
@@ -773,7 +767,9 @@
 		#define UINTPTR_MAX	UINT32_MAX;
 };
 
-
+/*
+ * aix_stdint_3
+ */
 fix = {
 hackname

fixincludes 2013-05-23 Alexander Ivchenko alexander.ivche...@intel.com

[Bruce Korb]

Alexander Ivchenko Mon, 29 Apr 2013 23:24:55 -0700

2013/4/29 Mike Stump mikest...@comcast.net:

On Jan 9, 2013, at 7:14 AM, Alexander Ivchenko aivch...@gmail.com wrote:

 We have test fail for gcc.dg/cpp/trad/include.c on Android. The
reason for that is that
-ftraditional-cpp is not expected to work on Android due to variadic
macro (like #define __builtin_warning(x, y...))
in standard headers and traditional preprocessor cannot handle them.
 The attached patch disables that test.


Be sure to ask, Ok? in your patch submittals.

Ok.


thank you! I thought I did ask..


...
in standard headers and traditional preprocessor cannot handle them.

is it ok for trunk?


could someone commit that patch please? I don't have commit access.


Actually, Alexander, you did not ask.  And Kirill, you didn't verify
before applying the patch.  Patches to fixincludes are generally safe,
but it is protocol to ask.  Also, I prefer that the hacks get inserted
alphabetically.  So, actually, there are a few small complaints.


$ fgrep -i fixincludes ../MAINTAINERS
fixincludes Bruce Korb  bk...@gnu.org


The patch looks pretty reasonable, but I think someone else
should verify the obsolescence.  I also think it should be renamed to
something like obsolete_builtin_warning because the current
name gives no clue about what it really is.

/*
 *  Old Linux kernel's compiler.h header breaks Traditional CPP
 */
fix = {
hackname  = complier_h_tradcpp;
files = linux/compiler.h;

select= #define __builtin_warning\\(x, y\\.\\.\\.\\) \\(1\\);
c_fix = format;
c_fix_arg = /* __builtin_warning(x, y...) is obsolete */;

test_text = #define __builtin_warning(x, y...) (1);
};

Re: [fixincludes] solaris_pow_int_overload should use __cplusplus

[Bruce Korb]

On 05/16/13 06:41, Rainer Orth wrote:

Work is going on to incorporate all applicable fixincludes fixes into
the Solaris headers proper.  One fix is currently problematic since it
uses an G++-internal macro (__GXX_EXPERIMENTAL_CXX0X__) where libstdc++
cmath already switched to testing __cplusplus.  The following patch
updates the fix to match cmath.

Tested by mainline bootstraps on i386-pc-solaris2.11,
sparc-sun-solaris2.11 and 4.8 bootstrap on i386-pc-solaris2.10.

Ok for mainline and 4.8 branch if they pass?


Look good to me.  Thanks.

Re: [PATCH, fixincludes] Fix NULL on AIX

[Bruce Korb]

Hi David,

Looks good to me, but for a small nit:

On Tue, Apr 30, 2013 at 7:40 AM, David Edelsohn dje@gmail.com wrote:
 +c_fix_arg = #ifndef NULL\n
 +   #ifdef __cplusplus\n
 +   #ifdef __GNUG__\n
 +   #define NULL\t__null\n
 +   #else\t /* ! __GNUG__  */\n
 +   #define NULL\t0L\n
 +   #endif\t /* __GNUG__  */\n
 +   #else\t /* ! __cplusplus  */\n
 +   #define NULL\t((void *)0)\n
 +   #endif\t /* __cplusplus  */\n
 +   #endif\t /* !NULL  */;

I'd really prefer a here string:

c-fix-arg = - _EOF_
#ifndef NULL
#ifdef __cplusplus
#ifdef __GNUG__
#define NULL__null
#else   /* ! __GNUG__  */
#define NULL0L
#endif  /* __GNUG__  */
#else   /* ! __cplusplus  */
#define NULL((void *)0)
#endif  /* __cplusplus  */
#endif  /* !NULL  */
_EOF_;

Unless there is some reason you want to emphasize tabs with the \t escapes.
I think the here string is easier to read.

Re: [PATCH, fixincludes] Fix NULL on AIX

[Bruce Korb]

Hi,

On Tue, Apr 30, 2013 at 9:42 AM, David Edelsohn dje@gmail.com wrote:
 I coped c_fix_arg from openbsd_null_definition fix. I don't know if
 two different formats for similar fixes would be confusing, but I do
 not have a problem using the EOF version.

I haven't reviewed all patches and I don't always raise nits.

 Do you have any comment about the change to void_null fix?

By analogy, I'd prefer the EOF version there, too.  But ultimately,
it works and is not exactly illegible, so I have no serious objection
to the fix.  It would be nice if it were combinable, but doing so is
tricky.  I'm guessing that the fix on AIX is separated because the
headers contain __cplusplus and that is used as an exclusion test
for the void_null fix?  Otherwise this:

select= ^#[ \t]*define[ \t]+NULL[ \t]+(
\\(\\(void[ \t]*\\*\\)0\\)   |   \\(*0L*\\)*   );

would allow void_null to work for you -- perhaps by using %1 somewhere
in the replacement c-fix-arg.

Cheers - Bruce

Re: [PATCH] fixincludes: use $(FI) instead of fixincl@EXEEXT@

[Bruce Korb]

Except as noted below, fine by me.

On 04/04/13 12:56, Bernhard Reutner-Fischer wrote:
 Bootstrapped and regtested on x86_64-unknown-linux-gnu and
 x86_64-mine-linux-uclibc without regressions, ok for trunk?
 
 fixincludes/ChangeLog:
 
 2013-04-04  Bernhard Reutner-Fischer  al...@gcc.gnu.org
 
   Makefile.in: Use $(FI) instead of fixincl@EXEEXT@.
   Cleanup whitespace while at it.
 
 Signed-off-by: Bernhard Reutner-Fischer rep.dot@gmail.com
 ---
  fixincludes/Makefile.in |   10 +-
  1 file changed, 5 insertions(+), 5 deletions(-)
 
 diff --git a/fixincludes/Makefile.in b/fixincludes/Makefile.in
 index ce850ff..3dc869d 100644
 --- a/fixincludes/Makefile.in
 +++ b/fixincludes/Makefile.in
 @@ -131,7 +131,7 @@ fixinc.sh : fixinc.in mkfixinc.sh Makefile
  $(srcdir)/fixincl.x: @MAINT@ fixincl.tpl inclhack.def
   cd $(srcdir) ; $(SHELL) ./genfixes
  
 -mostlyclean : 
 +mostlyclean:

I see no reason for changing things.
But if you are going to clean up the colons, then they should
be in columns (mostly 12 or 16).  This one is already in 12.

   rm -f *.o *-stamp $(AF) $(FI) *~ fixinc.sh
  
  clean: mostlyclean
 @@ -179,18 +179,18 @@ check : all
  
  install : all
   -rm -rf $(DESTDIR)$(itoolsdir)
 - $(mkinstalldirs) $(DESTDIR)$(itoolsdir) 
 + $(mkinstalldirs) $(DESTDIR)$(itoolsdir)
   $(mkinstalldirs) $(DESTDIR)$(itoolsdatadir)/include
   $(INSTALL_DATA) $(srcdir)/README-fixinc \
 $(DESTDIR)$(itoolsdatadir)/include/README
   $(INSTALL_SCRIPT) fixinc.sh $(DESTDIR)$(itoolsdir)/fixinc.sh
 - $(INSTALL_PROGRAM) fixincl@EXEEXT@ \
 -   $(DESTDIR)$(itoolsdir)/fixincl@EXEEXT@
 + $(INSTALL_PROGRAM) $(FI) \
 +   $(DESTDIR)$(itoolsdir)/$(FI)

This should now fit on a single line.

   $(INSTALL_SCRIPT) mkheaders $(DESTDIR)$(itoolsdir)/mkheaders
  
  install-strip: install
   test -z '$(STRIP)' \
 -   || $(STRIP) $(DESTDIR)$(itoolsdir)/fixincl@EXEEXT@
 +   || $(STRIP) $(DESTDIR)$(itoolsdir)/$(FI)
  
  .PHONY: all check install install-strip
  .PHONY: dvi pdf info html install-pdf install-info install-html

Re: Ping: unreviewed copyright patches

[Bruce Korb]

On Mon, Feb 4, 2013 at 11:55 AM, Ben Elliston b...@air.net.au wrote:
 On Mon, Feb 04, 2013 at 06:59:38PM +, Richard Sandiford wrote:
 These days the guideline encourage updating all files, even ones
 that haven't changed, so I was hoping we could do that gcc-wide.

 If that is what the guidelines say, then I will not object.  I am just
 a bit surprised that you can claim copyright for a year in which the
 file is not modified.

I've wondered about the policy for years, except that I didn't
consider it very important.
The thinking now aligns with what I always thought:  the copyright year is based
on the work as a whole.  Each individual file is not individually
copyrighted, any more
than pages and chapters are individually copyrighted.  Its the whole book.
If you update a chapter, the book copyright date is updated.  Makes more sense
to me.

My issue is likely my issue:  too many names are used for the fixincludes
copyright notices.

Oh, well.  Cheers -Bruce

Re: Ping: unreviewed copyright patches

[Bruce Korb]

On 02/03/13 02:19, Richard Sandiford wrote:
 Not exactly the most exciting patches, and certainly not worth more than
 one ping, but:
 
   fixincludes copyright
   http://gcc.gnu.org/ml/gcc-patches/2013-01/msg00442.html

You missed the file header.  Why bother with dual update issues?

 --- mkheaders.in(revision 194742) 
 
 +++ mkheaders.in(working copy)
 
 @@ -1,6 +1,6 @@   
 
  #!/bin/sh
 
   
 
 -# Copyright (C) 2002, 2007, 2009 Free Software Foundation, Inc.  
 
 +# GCC Copyright (C) 2002-2013 Free Software Foundation, Inc. 
 
   
 
  #This file is part of GCC.   
 
   
 
 @@ -41,10 +41,9 @@
 
   
 
  if [ x$1 = x--version ] ; then   
 
  echo mkheaders (GCC) version $version  
 
 -echo Copyright 2002, 2007, 2009 Free Software Foundation, Inc. 
 
 -echo This program is free software; you may redistribute it under the  
 
 -echo terms of the GNU General Public License.  This program has
 
 -echo absolutely no warranty.   
 
 +sed '\@http://www.gnu.org/licenses@q 
 
 +   \@/bin/sh@d   
 
 +   s/^#* *//' `which $0` 
   
  exit 0   
 
  fi

Alternatively (and probably better):

 --- mkheaders.in(revision 194742)
 +++ mkheaders.in(working copy)
 @@ -1,22 +1,22 @@
  #!/bin/sh
 +copyright='
 +GCC Copyright (C) 2002-2013 Free Software Foundation, Inc.
  
 -# Copyright (C) 2002, 2007, 2009 Free Software Foundation, Inc.
 +This file is part of GCC.
  
 -#This file is part of GCC.
 -
 -#GCC is free software; you can redistribute it and/or modify it under
 -#the terms of the GNU General Public License as published by the Free
 -#Software Foundation; either version 3, or (at your option) any later
 -#version.
 -
 -#GCC is distributed in the hope that it will be useful, but WITHOUT
 -#ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
 -#FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
 -#for more details.
 -
 -#You should have received a copy of the GNU General Public License
 -#along with GCC; see the file COPYING3.  If not see
 -#http://www.gnu.org/licenses/.
 +GCC is free software; you can redistribute it and/or modify it under
 +the terms of the GNU General Public License as published by the Free
 +Software Foundation; either version 3, or (at your option) any later
 +version.
 +
 +GCC is distributed in the hope that it will be useful, but WITHOUT
 +ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
 +FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
 +for more details.
 +
 +You should have received a copy of the GNU General Public License
 +along with GCC; see the file COPYING3.  If not see
 +http://www.gnu.org/licenses/.'
  
  # Basic information
  target=@target@
 @@ -41,10 +41,7 @@
  
  if [ x$1 = x--version ] ; then
  echo mkheaders (GCC) version $version
 -echo Copyright 2002, 2007, 2009 Free Software Foundation, Inc.
 -echo This program is free software; you may redistribute it under the
 -echo terms of the GNU General Public License.  This program has
 -echo absolutely no warranty.
 +echo $copyright
  exit 0
  fi
  

Either way

===

   http://gcc.gnu.org/ml/gcc-patches/2013-01/msg00443.html

Is the project fixincludes, inclhack, gcc or unnamed?
I think if you go to the trouble to clean all this up,
one should be picked and it should be made consistent.  :)
Personally, I think GCC first, fixincludes second.

 Index: gcc/fixincludes/fixinc.in
 ===
 --- gcc.orig/fixincludes/fixinc.in
 +++ gcc/fixincludes/fixinc.in
 @@ -6,8 +6,7 @@
  #
  # See README-fixinc for more information.
  #
 -#  fixincludes copyright (c) 1998, 1999, 2000, 2002, 2009
 -#  The Free Software Foundation, Inc.
 +#  fixincludes copyright (C) 1998-2013 Free Software Foundation, Inc.
  #
  # 

Re: Ping: unreviewed copyright patches

[Bruce Korb]

On 02/03/13 09:42, Richard Sandiford wrote:
 You missed the file header.
 
 That was deliberately in patch 2 though.

OK.

 Why bother with dual update issues?
 
 Well, the point is that patch 2 is scripted.

OK:
  echo $copyright | sed 's/(C) 2002-/(C) /'

and now you print the right date and never have to hand update again.
And if the notice gets changed because of a new and better address
or whatever, just one place and not two.

I hate hand updating mind numbing stuff like this.  As you say:

 Believe me, I don't find copyright year lists vs. ranges any more
 interesting than the next man.  This really was supposed to be
 an attempt to make things simpler.

simpler as in trying to never have to think about it any more? :)

Re: [PATCH] Fix fixinclude common/non-common mix

[Bruce Korb]

Hi,

On Mon, Jan 14, 2013 at 12:42 AM, Richard Biener rguent...@suse.de wrote:

 fixincludes mixes common declarations (in fixlib.h) and non-common
 decls (where they are defined) for verbose_level and fixinc_mode.
 XCode on Mountain Lion doesn't like this and its linker (rightfully)
 complains.

It is not rightful that it complain, but it is rightful to accommodate
it.  approved.

Re: [committed] 2011 and 2012 Copyright year updates

[Bruce Korb]

On Mon, Jan 7, 2013 at 11:49 AM, Richard Sandiford
rdsandif...@googlemail.com wrote:
 I think a patch for each directory will need posting separately for review
 of such things as whether any imported / generated files are mistakenly
 changed.

 So fixincludes/ separate from gcc/, and every library separate?  OK.

Separate?  Seems pretty inextricably intertwined to me.

Maybe I'm coming in too late in this conversation.
I'll just update the copyrights in the next few days.
It (fixincludes) has _certainly_ been updated every year of its existence.
(Probably ought not count the original shell script, though I did lift all
of its expressions)

Cheers - Bruce

Re: fixincludes for libquadmath build regression

[Bruce Korb]

On 01/06/13 12:12, Alexandre Oliva wrote:
 On Dec 30, 2012, Bruce Korb bk...@gnu.org wrote:
 
 On 12/30/12 01:42, Paolo Bonzini wrote:
 Not my territory anymore, but it looks much better!  CCing Bruce.
 
 Long time.  It's no wonder you've forgotten this little world! :)
 
 Indeed!
 
 Anyway, please make the expressions more readable and strip
 out the generated text from the review message.
 
 Done.  Ok?

Looks good to me.  Thanks!

Re: fixincludes for libquadmath build regression

[Bruce Korb]

On 12/30/12 01:42, Paolo Bonzini wrote:
 Not my territory anymore, but it looks much better!  CCing Bruce.

Hi Alexandre,

Long time.  It's no wonder you've forgotten this little world! :)

Anyway, please make the expressions more readable and strip
out the generated text from the review message.

Readability guidance:  indent text and break lines logically.
Consider here-strings.  e.g. not:

c_fix_arg = # ifdef __SSE_MATH__\n%0\n
# else\n%1__asm__ __volatile__ (\fdiv st, st(0); fwait\\n
%1\t\t\t: \=t\ (__f) : \0\ (__f));\n
# endif;

instead:

c_fix_arg = # ifdef __SSE_MATH__\n%0\n
# else\n
%1__asm__ __volatile__ (\fdiv st, st(0); fwait\\n
%1\t\t\t: \=t\ (__f) : \0\ (__f));\n
# endif;

or even better:

c_fix_arg = - _EOText_
# ifdef __SSE_MATH__\n
%0
# else
%1__asm__ __volatile__ (fdiv st, st(0); fwait
%1  =t (__f) : 0 (__f));
# endif
_EOText_;

VxWorks is done

[Bruce Korb]

Index: gcc/gcov-io.c
===
--- gcc/gcov-io.c	(revision 193123)
+++ gcc/gcov-io.c	(working copy)
@@ -92,7 +92,8 @@
 {
   /* Read-only mode - acquire a read-lock.  */
   s_flock.l_type = F_RDLCK;
-  fd = open (name, O_RDONLY);
+  /* pass mode (ignored) for compatibility */
+  fd = open (name, O_RDONLY, S_IRUSR | S_IWUSR);
 }
   else
 {
Index: gcc/ChangeLog
===
--- gcc/ChangeLog	(revision 193123)
+++ gcc/ChangeLog	(working copy)
@@ -1,3 +1,7 @@
+2012-11-03  Robert Mason  r...@verizon.net
+
+	* gcov-io.c (gcov_open): Add file mode to open call (need for VxWorks)
+
 2012-11-03  Sandra Loosemore  san...@codesourcery.com
 
 	* doc/extend.texi: Copy-edit to use present tense except when
Index: libstdc++-v3/config/os/vxworks/os_defines.h
===
--- libstdc++-v3/config/os/vxworks/os_defines.h	(revision 193123)
+++ libstdc++-v3/config/os/vxworks/os_defines.h	(working copy)
@@ -33,4 +33,10 @@
 // System-specific #define, typedefs, corrections, etc, go here.  This
 // file will come before all others.
 
+//Keep vxWorks from defining min()/max() as macros
+#ifdef NOMINMAX
+#undef NOMINMAX
+#endif
+#define NOMINMAX 1
+
 #endif
Index: libstdc++-v3/ChangeLog
===
--- libstdc++-v3/ChangeLog	(revision 193123)
+++ libstdc++-v3/ChangeLog	(working copy)
@@ -1,3 +1,8 @@
+2012-11-03  Robert Mason  r...@verizon.net
+
+	* config/os/vxworks/os_defines.h:
+	Keep vxWorks from defining min()/max() as macros
+
 2012-11-03  Jonathan Wakely  jwakely@gmail.com
 
 	* doc/html/*: Regenerate.
Index: configure.ac
===
--- configure.ac	(revision 193123)
+++ configure.ac	(working copy)
@@ -427,6 +427,15 @@
 ENABLE_LIBSSP=$enableval,
 ENABLE_LIBSSP=yes)
 
+AC_ARG_ENABLE(libstdcxx,
+AS_HELP_STRING([--disable-libstdcxx],
+  [do not build libstdc++-v3 directory]),
+ENABLE_LIBSTDCXX=$enableval,
+ENABLE_LIBSTDCXX=default)
+[if test ${ENABLE_LIBSTDCXX} = no ; then
+  noconfigdirs=$noconfigdirs libstdc++-v3
+fi]
+
 # Save it here so that, even in case of --enable-libgcj, if the Java
 # front-end isn't enabled, we still get libgcj disabled.
 libgcj_saved=$libgcj
@@ -562,19 +571,22 @@
 esac
 
 # Disable libstdc++-v3 for some systems.
-case ${target} in
-  *-*-vxworks*)
-# VxWorks uses the Dinkumware C++ library.
-noconfigdirs=$noconfigdirs target-libstdc++-v3
-;;
-  arm*-wince-pe*)
-# the C++ libraries don't build on top of CE's C libraries
-noconfigdirs=$noconfigdirs target-libstdc++-v3
-;;
-  avr-*-*)
-noconfigdirs=$noconfigdirs target-libstdc++-v3
-;;
-esac
+# Allow user to override this if they pass --enable-libstdc++-v3
+if test ${ENABLE_LIBSTDCXX} = default ; then
+  case ${target} in
+*-*-vxworks*)
+  # VxWorks uses the Dinkumware C++ library.
+  noconfigdirs=$noconfigdirs target-libstdc++-v3
+  ;;
+arm*-wince-pe*)
+  # the C++ libraries don't build on top of CE's C libraries
+  noconfigdirs=$noconfigdirs target-libstdc++-v3
+  ;;
+avr-*-*)
+  noconfigdirs=$noconfigdirs target-libstdc++-v3
+  ;;
+  esac
+fi
 
 # Disable Fortran for some systems.
 case ${target} in
Index: ChangeLog
===
--- ChangeLog	(revision 193123)
+++ ChangeLog	(working copy)
@@ -1,3 +1,8 @@
+2012-11-03  Robert Mason  r...@verizon.net
+
+	* configure.ac: add --disable-libstdcxx configure option
+	and handle defaulted state only for VxWorks, ARM-wince-pe and AVR.
+
 2012-10-30 Ganesh Gopalasubramanian  ganesh.gopalasubraman...@amd.com
 
 	* MAINTAINERS (Write After Approval): Add myself.

Re: Parts 3 and 4 to the vxworks/fixincludes patches

[Bruce Korb]

Hi Robert,

On Thu, Nov 1, 2012 at 6:35 AM, rbmj r...@verizon.net wrote:
 and now my patches will build on top of
 trunk.  Bruce, can you give steps on how to reproduce the error you
 reported?

rm -rf gcc-bld gcc-ins
cp -l gcc-svn gcc-bld
pfx=$PWD/gcc-ins
cd gcc-bld
./configure --enable-languages=c,c++ --prefix=$pfx CFLAGS='-g2 -Wall'
make

I never build in my source tree.

Parts 3 and 4 to the vxworks/fixincludes patches

[Bruce Korb]

The first two patches I've applied.  The remaining two are needed to fully
enable building the VxWorks flavor of GCC, but those bits affect parts
outside of fixincludes and there is some breakage somewhere.
All evidence seems to me to show fixincludes still doing its thing correctly,
but somewhere along the line the build becomes confused and unable to
find stdarg.h:

 echo timestamp  stmp-int-hdrs
 g++ -c   -g -DIN_GCC   -fno-exceptions -fno-rtti -fasynchronous-unwind-tables 
 \
  -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual 
 -Wmissing-format-attribute \
  -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings 
 -fno-common \
   -DHAVE_CONFIG_H -I. -Ilto -I../.././gcc -I../.././gcc/lto 
 -I../.././gcc/../include \
  -I../.././gcc/../libcpp/include  -I../.././gcc/../libdecnumber \
  -I../.././gcc/../libdecnumber/bid -I../libdecnumber 
 -I../.././gcc/../libbacktrace  \
../.././gcc/lto/lto-lang.c -o lto/lto-lang.o
 In file included from ../.././gcc/lto/lto-lang.c:22:0:
 ../.././gcc/system.h:28:20: fatal error: stdarg.h: No such file or directory
  #include stdarg.h
 ^
 compilation terminated.

I have not been able to run down the cause.  Until I've found it,
I'm holding back on the bits that change stuff outside of fixincludes:

 gcc/gcov-io.c
 libstdc++-v3/config/os/vxworks/os_defines.h
 configure.ac

I hope someone knows what this is.

../.././gcc/system.h:28:20: fatal error: stdarg.h: No such file or directory

[Bruce Korb]

Say, what?  Anyone know what this is about?

cp ../.././gcc/../fixincludes/README-fixinc include-fixed/README
chmod a+r include-fixed/README
echo timestamp  stmp-int-hdrs
TARGET_CPU_DEFAULT= \
HEADERS=auto-host.h ansidecl.h DEFINES=USED_FOR_TARGET  \
/bin/sh ../.././gcc/mkconfig.sh tconfig.h
(SHLIB='true'; \
g++ -c   -g -DIN_GCC   -fno-exceptions -fno-rtti -fasynchronous-unwind-tables 
-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute 
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings 
-fno-common  -DHAVE_CONFIG_H -I. -I. -I../.././gcc -I../.././gcc/. 
-I../.././gcc/../include -I../.././gcc/../libcpp/include  
-I../.././gcc/../libdecnumber -I../.././gcc/../libdecnumber/bid 
-I../libdecnumber -I../.././gcc/../libbacktrace
-DSTANDARD_STARTFILE_PREFIX=\../../../\ 
-DSTANDARD_EXEC_PREFIX=\/u/gnu/proj/gcc-svn-inst/lib64/gcc/\ 
-DSTANDARD_LIBEXEC_PREFIX=\/u/gnu/proj/gcc-svn-inst/lib/gcc/\ 
-DDEFAULT_TARGET_VERSION=\4.8.0\ 
-DDEFAULT_TARGET_MACHINE=\x86_64-unknown-linux-gnu\ 
-DSTANDARD_BINDIR_PREFIX=\/u/gnu/proj/gcc-svn-inst/bin/\ 
-DTOOLDIR_BASE_PREFIX=\../../../../\  `test X${SHLIB} = X || test yes 
!= yes || echo -DENABLE_SHARED_LIBGCC` -DCONFIGURE_SPECS=\\ \
-I. -I. -I../.././gcc -I../.././gcc/. -I../.././gcc/../include 
-I../.././gcc/../libcpp/include  -I../.././gcc/../libdecnumber 
-I../.././gcc/../libdecnumber/bid -I../libdecnumber 
-I../.././gcc/../libbacktrace   ../.././gcc/cp/g++spec.c)
g++   -g -DIN_GCC   -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W 
-Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute 
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings 
-fno-common  -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc  -o g++ \
  gcc.o ggc-none.o g++spec.o driver-i386.o  libcommon-target.a \
   libcommon.a ../libcpp/libcpp.a   ../libbacktrace/.libs/libbacktrace.a 
../libiberty/libiberty.a ../libdecnumber/libdecnumber.a
g++ -c   -g -DIN_GCC   -fno-exceptions -fno-rtti -fasynchronous-unwind-tables 
-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute 
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings 
-fno-common  -DHAVE_CONFIG_H -I. -Ilto -I../.././gcc -I../.././gcc/lto 
-I../.././gcc/../include -I../.././gcc/../libcpp/include  
-I../.././gcc/../libdecnumber -I../.././gcc/../libdecnumber/bid 
-I../libdecnumber -I../.././gcc/../libbacktrace../.././gcc/lto/lto-lang.c 
-o lto/lto-lang.o
In file included from ../.././gcc/lto/lto-lang.c:22:0:
../.././gcc/system.h:28:20: fatal error: stdarg.h: No such file or directory
 #include stdarg.h
^
compilation terminated.
make[3]: *** [lto/lto-lang.o] Error 1
make[3]: Leaving directory 
`/u/gnu/proj/gcc-svn-bld/host-x86_64-unknown-linux-gnu/gcc'
make[2]: *** [all-stage1-gcc] Error 2
make[2]: Leaving directory `/u/gnu/proj/gcc-svn-bld'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/u/gnu/proj/gcc-svn-bld'
make: *** [all] Error 2

Re: [PATCH,fixincludes] Wrap fcntl.h on AIX

[Bruce Korb]

Does make check complain if a replacement/wrap fix doesn't have a test?
If so, I'll be fixing it when I have time -- towards the end of October.
(The patch I sent a few days ago ought to do it, but I've not fully tested yet.)
Anyway, looks pretty reasonable to me...

On Sat, Sep 29, 2012 at 9:45 AM, David Edelsohn dje@gmail.com wrote:
 AIX fcntl.h redefines open, which conflicts with g++ fstream header.
  This patch wraps fcntl.h to use aliases in the same way that stdio.h
 currently is wrapped.

 Okay?

 +test-text = ''; /* no way to test */

git-svn: Unable to connect to a repository

[Bruce Korb]

Huh?  Sorry.  Don't know what else to say:

Per:  http://gcc.gnu.org/wiki/GitMirror

$ git svn init -Ttrunk --prefix=origin/ svn+ssh://gcc.gnu.org/svn/gcc
Network connection closed unexpectedly: Unable to connect to a repository at \
  URL 'svn+ssh://gcc.gnu.org/svn/gcc': To better debug SSH connection problems,
  remove the -q option from 'ssh' in the [tunnels] section of your Subversion
  configuration file. at /usr/lib/git/git-svn line 2299.


2287 sub init_remote_config {
2288 my ($self, $url, $no_write) = @_;
2289 $url =~ s!/+$!!; # strip trailing slash
2290 my $r = read_all_remotes();
2291 my $existing = find_existing_remote($url, $r);
2292 if ($existing) {
2293 unless ($no_write) {
2294 print STDERR Using existing ,
2295  [svn-remote \$existing\]\n;
2296 }
2297 $self-{repo_id} = $existing;
2298 } elsif ($_minimize_url) {
2299 my $min_url = Git::SVN::Ra-new($url)-minimize_url;
2300 $existing = find_existing_remote($min_url, $r);

Re: git-svn: Unable to connect to a repository

[Bruce Korb]

On 09/22/12 12:49, Bruce Korb wrote:
 Huh?  Sorry.  Don't know what else to say:

Similar results using straight up svn:

$ bash contrib/gcc_update
Updating SVN tree
svn: E155036: Please see the 'svn upgrade' command
svn: E155036: Working copy '/u/gnu/proj/gcc-svn' is too old (format 10, created 
by Subversion 1.6)
Adjusting file timestamps
Touching Makefile.in...
SVN update of full tree failed.
$ svn ls svn+ssh://usern...@gcc.gnu.org/svn/gcc
svn: E210002: Unable to connect to a repository at URL 
'svn+ssh://usern...@gcc.gnu.org/svn/gcc'
svn: E210002: To better debug SSH connection problems, remove the -q option 
from 'ssh' in the [tunnels] section of your Subversion configuration file.
svn: E210002: Network connection closed unexpectedly


SVN is behaving unexpectedly.  Help, please?

Re: git-svn: Unable to connect to a repository

[Bruce Korb]

Hi Gaby,

On 09/22/12 13:07, Gabriel Dos Reis wrote:
 SVN is behaving unexpectedly.  Help, please?
 
 Have you upgraded your system or SVN recently?

Not deliberately. :)  Switched openSuSE releases (12.2 now).

 If yes, you need to issue the command
 
  $ svn upgrade

It's been crunching on that for over 20 minutes now.
I suppose it will finish eventually.  [finished while writing this]

Nonetheless, I do prefer to work with GIT over SVN, but that means
I would need to debug the issues from my first missive
on this topic.  [now fixed, see below]

 (this has nothing to do with GCC.  It is a general SVN thingy.)

Still, dealing with anticipatable failures makes for good grist
for the GCC wiki.  Error messages like, remove the -q option
are not helpful when you haven't used any -q option.  And it
was similar to the message from git svn:

 $ git svn init -Ttrunk --prefix=origin/ svn+ssh://gcc.gnu.org/svn/gcc
 Network connection closed unexpectedly: Unable to connect to a repository at \
   URL 'svn+ssh://gcc.gnu.org/svn/gcc': To better debug SSH connection 
 problems,
   remove the -q option from 'ssh' in the [tunnels] section of your Subversion
   configuration file. at /usr/lib/git/git-svn line 2299.
 
 
 2287 sub init_remote_config { [...]

I surely don't see any -q on line 2299.  Perhaps I need a korbb@ inserted
before the gcc.gnu.org in the command?
[a moment passes]

Yep.  That's it.  the git svn init command should be augmented with my
login id at gcc.gnu.org.  Thank you!

 $ git svn init -Ttrunk --prefix=origin/ svn+ssh://logi...@gcc.gnu.org/svn/gcc

So, remove the -q option really means, provide your login id.
Not especially obvious.  :(

Thank you!! - Bruce

Re: [PING] Re: VxWorks Patches Back from the Dead!

[Bruce Korb]

From my part, I'm willing to push the patch, but I need confirmation
from Paolo and Nathan
because some of it affects code outside of my authority.

On Thu, Sep 20, 2012 at 7:02 PM, rbmj r...@verizon.net wrote:
 Ping?  Just did a full pull and rebuild today and everything still works :)

 Robert Mason

Re: VxWorks Patches Back from the Dead!

[Bruce Korb]

On 09/09/12 08:54, rbmj wrote:
 Just because I *love* bothering everyone with emails...

I don't mind, as long as you don't expect me to do anything
until I'm certain you've stabilized the patch ;)
I'm glad you rolled it up into one patch, because I was
eventually going to ask you to do that.  Thank  you.

Cheers - Bruce

 I've made a few changes and squashed everything into a single patch for ease 
 of application.  The commit message is inside the patch, but here's the 
 suggested ChangeLog:
 
 configure.ac: add --enable-libstdcxx option
 configure: regenerate
 
 [gcc]
 gcov-io.c (gcov_open): Pass mode to open() unconditionally
 
 [fixincludes]
 fixinc.in: Added ability to skip machine_name
 inclhack.def (AAB_vxworks_assert): Added fix
 inclhack.def (AAB_vxworks_regs_vxtypes): Added fix
 inclhack.def (AAB_vxworks_stdint): Added fix
 inclhack.def (AAB_vxworks_unistd): Added fix
 inclhack.def (vxworks_ioctl_macro): Added fix
 inclhack.def (vxworks_mkdir_macro): Added fix
 inclhack.def (vxworks_regs): Added fix
 inclhack.def (vxworks_write_const):  Added fix
 fixincl.x:  Regenerate
 mkfixinc.sh: Removed vxworks from list of no-op fixinc targets
 
 [libstdc++-v3]
 config/os/vxworks/os_defines.h: #define'd NOMINMAX
 
 Thanks,
 
 Robert Mason
 

Re: VxWorks Patches Back from the Dead!

[Bruce Korb]

Hi,

On Mon, Sep 10, 2012 at 10:48 AM, rbmj r...@verizon.net wrote:
 On the other hand, I've read this on the website:

 Don't mix together changes made for different reasons. Send them
 individually.  Ideally, each change you send should be impossible to
 subdivide into

 parts that we might want to consider separately, because each of its parts
 gets its motivation from the other parts

OTOH, this is a fairly cohesive set of patches.
A single project.  Even if, strictly speaking, each include fix
is entirely separate from the others (by the design of fixincludes),
I see them as a cohesive set that ought to be in a single commit.
Fixes to fixes for fixincludes have been very infrequent.

 ... At the same
 time, it's a pain in the rear to worry about 12 different commits

I'm into comforting one's derriere.

 Unless cosmic rays break everything again, that should be all.

:)  OK.  I'll push it on your behalf once the other bits have been
approved by their approvers.

Cheers - Bruce

Re: VxWorks Patches Back from the Dead!

[Bruce Korb]

Hi Robert,

On Thu, Aug 30, 2012 at 6:30 AM, rbmj r...@verizon.net wrote:
 Done, and patch is attached.


 OK.  make install doesn't seem to like it as much as I do.  It complains
 because it tries to install macro_list and can't find it.  Proposed
 solutions:

 2. Change line to read test -f ${MACRO_LIST}  rm -f ${MACRO_LIST}  touch
 ${MACRO_LIST}
 Advantages- Will not unnecessarily run machine_name.  Saves 4 bytes of disk
 usage over option 1 :D
 Disadvantages- Looks rather hackish; something about it feels wrong

Agreed.  You would have to add a comment

 1. Change line to read test -f ${MACRO_LIST}  echo  ${MACRO_LIST}
 Advantages- easy, simple
 Disadvantages- might cause an unnecessary run of the fix.  A very, very
 small potential compile time hit.

GCC compile time hit  Anyway, this looks cleaner and I surely don't see
much difference between this and #2 above.

 3. Make macro_list optional for installation
 Disadvantages- more complex, and I don't really feel like going back into
 the makefiles again.  That's a scary place.

Amen.  Keep it as simple as you can.  Thanks.

Re: VxWorks Patches Back from the Dead!

[Bruce Korb]

On 08/24/12 11:50, rbmj wrote:

On 8/22/2012 8:52 PM, Bruce Korb wrote:

However I think it might be simpler to tweak mkfixinc.sh to

  sed '/if test -s .{MACRO_LIST}/s/$/  false/' \
 ${srcdir}/fixinc.in  ${target}

for vxworks rather than all that configury rigmarole.
That would eliminate changes to gcc/configure.ac and gcc/Makefile.in.

OK.  One question though:  Why not just have a case statement inside fixinc.in?
e.g.

case ${target_canonical} in
 *-*-vxworks*)
 # Disable the machine name fix as it breaks things
 machine_name_override='OVERRIDE'
 ;;
esac

if test -s ${MACRO_LIST}  test -z ${machine_name_override}


There are many ways of accomplishing the same thing.
I just thought of the fact that the mkfixinc.sh script
constructed the result script either by spinning it
from thin air or by copying a source file, so why
not just edit that source file when it wasn't doing
the right thing?  Your solution is fine, too.
You could also make the sed expression simpler:

   sed '/^if test -s .{MACRO_LIST}/s/if .*/if false/'
   sed '/^if test -s .{MACRO_LIST}/,/^fi/d'

or replace ``machine_name_override='OVERRIDE''
with ``test -f ${MACRO_LIST}  rm -f ${MACRO_LIST}''

I will approve any reasonably simple solution.  :)

Thank you for doing this, by the way!

Regards, Bruce