Re: [PATCH] fixincludes: bypass the math_exception fix on __cplusplus

[Bruce Korb]

:-D Looks good to me. EXCEPT I think the test sample file would need a 
change, too. I didn't see that.


On 6/7/24 02:37, FX Coudert wrote:

The fixincludes fix “math_exception” is being applied overly broadly, including 
many targets which don’t need it, like darwin (and probably all non-glibc 
targets). I’m not sure if it is still needed on any target, but because I can’t 
be absolutely positive about that, I don’t want to remove it. But it dates from 
before 1998.

In subsequent times (2000) it was bypassed on glibc headers, as well as Solaris 
10. It was still needed on Solaris 8 and 9, which are (AFAICT) unsupported 
nowadays. The fix was originally bypassed on __cplusplus, which is the correct 
thing to do, but that bypass was neutralized to cater to a bug on Solaris 8 and 
9 headers. Now that those are gone… let’s revert to the previous bypass.


Bootstrapped and regtested on x86_64-apple-darwin23, where it no longer “fixes” 
the header unnecessarily.
OK to push?

FX

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: Fw: Problems with compiling autogen with GCC8 or newer versions

[Bruce Korb via Gcc]

Hi,

On 1/10/21 3:56 PM, Martin Sebor wrote:

Sure.  I was confirming that based on the GCC dump there is no risk
of an overflow in the translation unit, and so there is no warning.


OK. :) I didn't understand the GCC dump. Despite having commit privs, 
I'm not actually a compiler guru.



It can /not/ overflow. Those compiler stats are not decipherable by me.


They indicate the minimum, likely, maximum, and unlikely maximum
number of bytes of output for each directive and the running totals
for the call (in parentheses).  The relevant lines are these:

  Directive 2 at offset 2: "%s"
    Result: 0, 255, 255, 255 (2, 257, 257, 257)

The result tells us that the length of the %s argument is between
0 and 255 bytes long.
It should be 1 to 255. 0 is actually impossible, but it would take crazy 
complicated sleuthing to figure it out, even though the "spn_*" 
functions should be inlined.


Since objsize (the size of the destination) is 520 there is no
buffer overflow.
The size of the destination is guaranteed to be between 263 and 518 
bytes. The "def_str" pointer will always point at least two bytes past 
the start of the 520 byte buffer.


The note in the forwarded message indicates that GCC computes
the destination size to be much smaller for some reason:

  note: 'sprintf' output between 4 and 259 bytes into a destination of 
size 255


I.e., it thinks it's just 255 bytes.  As I explained, such a small
size would trigger the warning by design.
Yep. If it can accurately figure out the minimum size remaining, that 
would be completely fine. "If."

  I can't really think of
a reason why GCC would compute a smaller size here (it looks far
from trivial).
If it can figure out that the minimum size is 263, that'd be great. If 
it can't, it needs to be quiet.

  We'd need to see the original poster's translation
unit and know the host and the target GCC was configured for.


OK. Not anything I can do. Thomas would have to send in his version of 
"gd.i".



Thank you!

Regards, Bruce

Re: Fw: Problems with compiling autogen with GCC8 or newer versions

[Bruce Korb via Gcc]

Hi Martin,

On 1/10/21 11:01 AM, Martin Sebor wrote:

On 1/8/21 12:38 PM, Bruce Korb via Gcc wrote:
This is the code that must be confusing to GCC. "def_str" points to 
the second character in the 520 byte buffer. "def_scan" points to a 
character that we already know we're going to copy into the 
destination, so the "spn" function doesn't look at it:


 {
 char * end = spn_ag_char_map_chars(def_scan + 1, 31);
 size_t len = end - def_scan;
 if (len >= 256)
 goto fail_return;
 memcpy(def_str, def_scan, len);
 def_str += len;
 *def_str = '\0';
 def_scan = end;
 }


In the function preamble, "def_str" points to the first character 
(character "0") of a 520 byte buffer. Before this fragment, "*def_str" 
is set to an apostrophe and the pointer advanced. After execution passes 
through this fragment, "def_str" is pointing to a NUL byte that can be 
as far as 257 bytes into the buffer (character "257"). That leaves 263 
more bytes. The "offending" sprintf is:


sprintf(def_str, "  %s'", name_bf);

GCC correctly determines that "name_bf" cannot contain more than 255 
bytes. Add 3 bytes of text and a NUL byte and the sprintf will be 
dropping *AT MOST* 259 characters into the buffer. The buffer is 4 bytes 
longer than necessary.




GCC 8 also doesn't warn but it does determine the size.  Here's
the output for the relevant directive (from the output of
-fdump-tree-printf-return-value in GCC versions prior to 10, or
-fdump-tree-strlen in GCC 10 and later).  objsize is the size
of the destination, or 520 bytes here (this is in contrast to
the 255 in the originally reported message). The Result numbers
are the minimum and maximum size of the output (between 0 and
255 characters).

Computing maximum subobject size for def_str_146:
getdefs.c:275: sprintf: objsize = 520, fmtstr = "  %s'"
  Directive 1 at offset 0: "  ", length = 2
    Result: 2, 2, 2, 2 (2, 2, 2, 2)
  Directive 2 at offset 2: "%s"
    Result: 0, 255, 255, 255 (2, 257, 257, 257)
  Directive 3 at offset 4: "'", length = 1
    Result: 1, 1, 1, 1 (3, 258, 258, 258)
  Directive 4 at offset 5: "", length = 1

Besides provable overflow, it's worth noting that -Wformat-overflow

It can /not/ overflow. Those compiler stats are not decipherable by me.

also diagnoses a subset of cases where it can't prove that overflow
cannot happen.  One common case is:

  extern char a[8], b[8];
  sprintf (a, "a=%s", b);
My example would have the "a" array sized at 16 bytes and "b" provably 
not containing more than 7 characters (plus a NUL). There would be no 
overflow.

... The solution is to either use precision
to constrain the amount of output or in GCC 10 and later to assert
that b's length is less than 7.
See the fragment below to see where the characters in name_bf can 
*/NOT/* be more than 255. There is no need for either a precision 
constraint or an assertion, based on that code fragment.


So if in the autogen file def_str is ever less than 258 bytes/[259 -- 
NUL byte, too]/

I'd expect the warning to trigger with a message close to
the original.


It can not be less than 263. For the sake of those not reading the code, 
here is the fragment that fills in "name_bf[256]":



    {
    char * end = spn_ag_char_map_chars(def_scan + 1, 26);
    size_t len = end - def_scan;
    if (len >= 256)
    goto fail_return;
    memcpy(name_bf, def_scan, len);
    name_bf[len] = '\0';
    def_scan = end;
    }

Re: Fw: Problems with compiling autogen with GCC8 or newer versions

[Bruce Korb via Gcc]

Hi,

You are supposed to be able to post once you've subscribed.

Also, GCC's code analysis is wrong. "name_bf" contains *NO MORE* than 
MAXNAMELEN characters. That is provable.


"def_str" points into a buffer of size ((MAXNAMELEN * 2) + 8) and at an 
offset maximum of MAXNAMELEN+1 (also provable), meaning that at a 
minimum there are MAXNAMELEN+6 bytes left in the buffer.


That objected-to sprintf can add a maximum of MAXNAMELEN + 4 to where 
"def_str" points.


GCC is wrong. It is unable to figure out how far into the buffer 
"def_str" can point.


On 1/8/21 2:26 AM, Oppe, Thomas C ERDC-RDE-ITL-MS Contractor wrote:

Dear Sir:

I would like to post the following message to the mailing list 
"autogen-us...@lists.sourceforge.net".  Could you please add me to this list?

I am an HPC user at ERDC DSRC in Vicksburg, MS.  One of my projects is building GCC 
snapshots and releases using various software prerequisite packages necessary in the 
"make check" phase.  One of these packages is autogen-5.18.16.

Thank you for your consideration.

Tom Oppe


-
Thomas C. Oppe
HPCMP Benchmarking Team
HITS Team SAIC
thomas.c.o...@erdc.dren.mil
Work:  (601) 634-2797
Cell:(601) 642-6391
-


From: Oppe, Thomas C ERDC-RDE-ITL-MS Contractor
Sent: Friday, January 8, 2021 12:32 AM
To: autogen-us...@lists.sourceforge.net
Subject: Problems with compiling autogen with GCC8 or newer versions

Dear Sir:

When compiling autogen-5.18.16 with gcc8 or newer, I am getting format overflow errors 
like the following during the "make" step:

top_builddir=".." top_srcdir=".." VERBOSE="" /bin/bash "../build-aux/run-ag.sh" 
-MFstamp-opts -MTstamp-opts -MP ./opts.def
gcc -DHAVE_CONFIG_H -I. -I..  -I.. -I../autoopts  -g -O2 
-I/p/home/oppe/gcc/10.2.0/include -Wno-format-contains-nul -fno-strict-aliasing 
-Wall -Werror -Wcast-align -Wmissing-prototypes -Wpointer-arith -Wshadow 
-Wstrict-prototypes -Wwrite-strings -Wstrict-aliasing=3 -Wextra -Wno-cast-qual 
-g -O2 -I/p/home/oppe/gcc/10.2.0/include -Wno-format-contains-nul 
-fno-strict-aliasing -c -o gd.o gd.c
In file included from gd.c:11:
getdefs.c: In function 'buildDefinition':
getdefs.c:451:29: error: '%s' directive writing up to 255 bytes into a region 
of size 253 [-Werror=format-overflow=]
   451 | sprintf(def_str, "  %s'", name_bf);
   | ^~~~~
getdefs.c:451:9: note: 'sprintf' output between 4 and 259 bytes into a 
destination of size 255
   451 | sprintf(def_str, "  %s'", name_bf);
   | ^~
cc1: all warnings being treated as errors
make[2]: *** [gd.o] Error 1
make[2]: Leaving directory `/p/work1/oppe/autogen-5.18.16/getdefs'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/p/work1/oppe/autogen-5.18.16'
make: *** [all] Error 2

Do I just add "-Wno-error=format-overflow" to the compile options?  Do you have 
a fix?

Tom Oppe

-
Thomas C. Oppe
HPCMP Benchmarking Team
HITS Team SAIC
thomas.c.o...@erdc.dren.mil
Work:  (601) 634-2797
Cell:(601) 642-6391
-

Re: Why was it important to change "FALLTHROUGH" to "fall through"?

[Bruce Korb via Gcc]

On Tue, Sep 8, 2020 at 7:36 AM Jakub Jelinek  wrote:
> > The fall through comment was polluted with a colon that I hadn't noticed, 
> > as in:
> >
> > /* FALLTHROUGH: */
> >
> > and your fall through regex doesn't allow for that.
> > I'd add a colon to the space, tab and '!' that the regex accepts.
>
> I think it is a bad idea to change the regexps, it has been done that way
> for quite a while and many people could rely on what exactly is and is not
> handled.

That is your call. I've never used the colon myself, but my friend did
in this example. Unfortunately, I don't get to pick what compiler
options folks like to pick for building my code, so I cannot choose
the fallthrough level of 2.

Anyway, the error message ought to include enough information that
folks can fix it without having to resort to multiple Google searches
and reading discussions. (Just mention "// fall through" in the
message.)

> There is always the option to use attributes or builtins...

Not if you're writing code for multiple platforms. :(

Thank you. Regards, Bruce

Re: Why was it important to change "FALLTHROUGH" to "fall through"?

[Bruce Korb via Gcc]

On Tue, Sep 8, 2020 at 2:33 AM Jonathan Wakely  wrote:
> > Nope. I had /* FALLTHROUGH */ on the line before a blank line before
> > the case label. After Googling, I found an explicit reference that you
> > had to spell it: // fall through
> > I did that, and it worked. So I'm moving on, but still ...
>
> The canonical reference is
> https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wimplicit-fallthrough
> and it says FALLTHROUGH is fine (except with -Wimplicit-fallthrough=5
> which "doesn’t recognize any comments as fallthrough comments, only
> attributes disable the warning").

Hi,

Thank you. It turns out it was in someone else's code that I'd
incorporated into my project.
The fall through comment was polluted with a colon that I hadn't noticed, as in:

/* FALLTHROUGH: */

and your fall through regex doesn't allow for that.
I'd add a colon to the space, tab and '!' that the regex accepts.
Does your acceptance pattern accept these? It's hard for me to decipher.

getdefs/getdefs.c:/* FALLTHROUGH */ /* NOTREACHED */
agen5/defLex.c:/* FALLTHROUGH */ /* to Invalid input char */

I'd also recommend a modified error message that includes mention of
the approved comment.

Thank you.

Regards, Bruce

Re: Why was it important to change "FALLTHROUGH" to "fall through"?

[Bruce Korb via Gcc]

On Mon, Sep 7, 2020 at 3:45 PM Florian Weimer  wrote:
>
> * Bruce Korb via Gcc:
>
> > I don't write a lot of code anymore, but this sure seems like a
> > gratuitous irritation to me. I've been using
> >
> > // FALLTHRU and
> > // FALLTHROUGH
> >
> > for *DECADES*, so it's pretty incomprehensible why the compiler should
> > have to invalidate my code because it thinks a different coding
> > comment is better.
>
> It's not clear what you are talking about.
>
> Presumably you placed the comment before a closing brace, and not
> immediately before the subsequent case label?

Nope. I had /* FALLTHROUGH */ on the line before a blank line before
the case label. After Googling, I found an explicit reference that you
had to spell it: // fall through
I did that, and it worked. So I'm moving on, but still ...

Why was it important to change "FALLTHROUGH" to "fall through"?

[Bruce Korb via Gcc]

I don't write a lot of code anymore, but this sure seems like a
gratuitous irritation to me. I've been using

// FALLTHRU and
// FALLTHROUGH

for *DECADES*, so it's pretty incomprehensible why the compiler should
have to invalidate my code because it thinks a different coding
comment is better.

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 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: "fall-through" errors

[Bruce Korb]

On Sat, Jul 28, 2018 at 11:48 AM Jakub Jelinek  wrote:
> You don't need to use configure for this, something like:
> #ifdef __has_attribute
> #if __has_attribute(__noreturn__)
> #define NORETURN __attribute__((__noreturn__))
> #endif


OK. Thanks. It _will_ be  a bit more complicated because my toy emits
headers for others to compile.

SO, more like:

#ifdef NORETURN
# define _AO_NoReturn NORETURN
#else
<>
#endif

and then emit headers with the _AO_NoReturn marker.
namespaces can be a nuisance.

Re: "fall-through" errors

[Bruce Korb]

On Sat, Jul 28, 2018 at 10:44 AM Jakub Jelinek  wrote:
>
> On Sat, Jul 28, 2018 at 10:22:35AM -0700, Bruce Korb wrote:
> > ../../autoopts/makeshell.c: In function ‘text_to_var’:
> > ../../autoopts/makeshell.c:324:14: error: this statement may fall
> > through [-Werror=implicit-fallthrough=]
> >  (*(opts->pUsageProc))(opts, EXIT_SUCCESS);
> >  ~^~~~
> >
> > This warning goes away if the comment "/* FALLTHROUGH */ is present.
> > You are missing a condition:
> >
> > switch (which) {
> > case TT_LONGUSAGE:
> > (*(opts->pUsageProc))(opts, EXIT_SUCCESS);
> > /* NOTREACHED */
> >
> > Please add the exception for a "/* NOTREACHED */" comment. Thank you.
>
> NOTREACHED means something different, and I don't think we want to add
> support for this when we already support a way (including a standard way) to
> mark function pointers noreturn (noreturn attribute, _Noreturn in C).
> Or you can use -Wimplicit-fallthrough=1 where any kind of comment no matter
> what you say there will disable the implicit fallthrough warning.

Messing with "noreturn" means messing with autoconf configury and you have no
idea how much I have always hated that horrific environment. Using the
"implicit-fallthrough=1" thingy means the same thing, but making sure it is GCC
and not Clang. That is why using the "obvious" implication that if a function
does not return, then you won't "accidentally" fall through either. Rather than
mess with all that, do both:  /* FALLTHROUGH */ /* NOTREACHED */
I think it would be good to reconsider NOTREACHED. Once upon a time,
I segregated out -Wformat-contains-nul. I could offer again, but it
would be a long
time for the round tuit and it would be hard for me.

"fall-through" errors

[Bruce Korb]

../../autoopts/makeshell.c: In function ‘text_to_var’:
../../autoopts/makeshell.c:324:14: error: this statement may fall
through [-Werror=implicit-fallthrough=]
 (*(opts->pUsageProc))(opts, EXIT_SUCCESS);
 ~^~~~

This warning goes away if the comment "/* FALLTHROUGH */ is present.
You are missing a condition:

switch (which) {
case TT_LONGUSAGE:
(*(opts->pUsageProc))(opts, EXIT_SUCCESS);
/* NOTREACHED */

Please add the exception for a "/* NOTREACHED */" comment. Thank you.

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: Next question: sizeof(char buf[2042])

[Bruce Korb]

OK. My mistake. "Nevermind" -- side effect of another change.

On Wed, Jun 20, 2018 at 11:47 AM Bruce Korb  wrote:

> Yeah, I guess this is Clang, but is it a legal interpretation for Clang?
>
> In file included from gnu-pw-mgr.c:24:
>
> In file included from ./fwd.h:288:
>
> *./seed.c:178:43: **warning: **sizeof on pointer operation will return
> size of 'const char *' instead of 'const char [2042]'*
>
> *  [-Wsizeof-array-decay]*
>
> char * tag = scribble_get(sizeof (tag_fmt) + strlen(OPT_ARG(TAG)));
>
> *  ^~~*
>
>
> *It seems like a pretty brain damaged interpretation.*
>
> --
>  - Bruce
>


-- 
 - Bruce

Next question: sizeof(char buf[2042])

[Bruce Korb]

Yeah, I guess this is Clang, but is it a legal interpretation for Clang?

In file included from gnu-pw-mgr.c:24:

In file included from ./fwd.h:288:

*./seed.c:178:43: **warning: **sizeof on pointer operation will return size
of 'const char *' instead of 'const char [2042]'*

*  [-Wsizeof-array-decay]*

char * tag = scribble_get(sizeof (tag_fmt) + strlen(OPT_ARG(TAG)));

*  ^~~*


*It seems like a pretty brain damaged interpretation.*

-- 
 - Bruce

Re: -Wno-format-contains-nul

[Bruce Korb]

Thanks. I guess clang forked after the clever NUL-in-format-string was
added, but before my fix. :( I'll add -Wno-format if I can identify clang
over GCC.

On Wed, Jun 20, 2018 at 11:32 AM Jakub Jelinek  wrote:

> On Wed, Jun 20, 2018 at 11:17:50AM -0700, Bruce Korb wrote:
> > Years and years ago, I went to a mess of trouble to implement this
> > specialized warning so I would not have to see it anymore. I use a code
> > generator that puts constant strings into one huge buffer with all the
> > contained strings NUL separated.  Today, I was trying to build on OS/X:
> >
> > libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I. -I../lib -g -O2
> > -Wcast-align -Wmissing-prototypes -Wpointer-arith -Wshadow
> > -Wstrict-prototypes -Wwrite-strings -Wno-format-contains-nul
> > -fno-strict-aliasing -Wstrict-aliasing=2 -MT libopts_la-libopts.lo -MD
> -MP
> > -MF .deps/libopts_la-libopts.Tpo -c libopts.c  -fno-common -DPIC -o
> > .libs/libopts_la-libopts.o
> >
> > warning: unknown warning option '-Wno-format-contains-nul'
> > [-Wunknown-warning-option]
> > In file included from libopts.c:26:
> > ./enum.c:112:38: warning: format string contains '\0' within the string
> > body [-Wformat]
> > fprintf(option_usage_fp, ENUM_ERR_LINE, *(paz_names++));
> >  ^
> > ./ao-strs.h:70:31: note: expanded from macro 'ENUM_ERR_LINE'
> > #define ENUM_ERR_LINE (ao_strs_strtable+304)
> >   ^~
> > ./ao-strs.c:90:20: note: format string is defined here
> > /*   304 */ "  %s\n\0"
> > ~~~^~~
> >
> >
> > Did somebody go to a bunch of trouble to undo my work for the OS/X
> > platform? :(
>
> No, you are probably just using clang rather than gcc.
> gcc has no -Wunknown-warning-option warning, -Wformat-contains-nul
> is a known option and if you used some unknown -Wno-... warning option
> and any diagnostics was emitted, the message would be just:
> warning: unrecognized command line option ‘-Wno-whatever’
>
> Jakub
>


-- 
 - Bruce

-Wno-format-contains-nul

[Bruce Korb]

Years and years ago, I went to a mess of trouble to implement this
specialized warning so I would not have to see it anymore. I use a code
generator that puts constant strings into one huge buffer with all the
contained strings NUL separated.  Today, I was trying to build on OS/X:

libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I. -I../lib -g -O2
-Wcast-align -Wmissing-prototypes -Wpointer-arith -Wshadow
-Wstrict-prototypes -Wwrite-strings -Wno-format-contains-nul
-fno-strict-aliasing -Wstrict-aliasing=2 -MT libopts_la-libopts.lo -MD -MP
-MF .deps/libopts_la-libopts.Tpo -c libopts.c  -fno-common -DPIC -o
.libs/libopts_la-libopts.o

warning: unknown warning option '-Wno-format-contains-nul'
[-Wunknown-warning-option]
In file included from libopts.c:26:
./enum.c:112:38: warning: format string contains '\0' within the string
body [-Wformat]
fprintf(option_usage_fp, ENUM_ERR_LINE, *(paz_names++));
 ^
./ao-strs.h:70:31: note: expanded from macro 'ENUM_ERR_LINE'
#define ENUM_ERR_LINE (ao_strs_strtable+304)
  ^~
./ao-strs.c:90:20: note: format string is defined here
/*   304 */ "  %s\n\0"
~~~^~~


Did somebody go to a bunch of trouble to undo my work for the OS/X
platform? :(
-- 
 - 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: assuming signed overflow does not occur

[Bruce Korb]

On 09/04/17 08:54, Manuel López-Ibáñez wrote:
> I wrote an explanation of the current status of Wstrict-overflow to the
> best of my knowledge:
> https://gcc.gnu.org/wiki/VerboseDiagnostics#Wstrict_overflow
> 
> I didn't mention GIMPLE because it is often the case that the root of
> the problem is not obvious in gimple unless one also debugs the compiler
> at the same time.
> 
> I hope it is useful!

Very much so, thank you!

Re: assuming signed overflow does not occur

[Bruce Korb]

Hi,

On Sun, Sep 3, 2017 at 1:48 PM, Florian Weimer <f...@deneb.enyo.de> wrote:
> * Bruce Korb:
>
>> I know about all these theoretical possibilities of numbers behaving
>> in strange ways when arithmetic optimizations assume that signed
>> overflow won't occur when they actually might. Yep, it creates subtle
>> bugs. The warning is worthwhile. Still and all:
>>
>> 485 tvdiff = abs_tval(sub_tval(timetv, tvlast));
>> 486 if (tvdiff.tv_sec != 0) {
>>
>> systime.c: In function 'step_systime':
>> systime.c:486:5: warning: assuming signed overflow does not occur when
>> simplifying conditional to constant [-Wstrict-overflow]
>>
>> What possible optimization might be going on to cause an overflow
>> problem when I simply want to know if the "tv_sec" field is zero or
>> not? (BTW, in current source, "tvdiff" is a structure that is returned
>> by abs_tval())
>
> This usually happens after inlining and other optimizations.  You'll
> have to look at GIMPLE dumps to figure out what is going on.

RFE's are for this list: please improve the message.

The message does not have to be a dissertation, but messages
nowadays can certainly include URL's to direct people to
reasonable places. I'd suggest something like:

gcc.gnu.org/gcc-messages/xxx

WRT looking at a GIMPLE dump, I'd first have to learn what GIMPLE is,
then learn how to decipher one, then figure out how to get it out of
the compiler and
finally plod through it. Guess what? I won't be doing that. I'll
squish the warning first. :(  Effective messages are very important.

Re: assuming signed overflow does not occur

[Bruce Korb]

Per request, the inlined functions

On Sat, Sep 2, 2017 at 12:59 PM, Bruce Korb <bruce.k...@gmail.com> wrote:
> I know about all these theoretical possibilities of numbers behaving
> in strange ways when arithmetic optimizations assume that signed
> overflow won't occur when they actually might. Yep, it creates subtle
> bugs. The warning is worthwhile. Still and all:
>
> 485 tvdiff = abs_tval(sub_tval(timetv, tvlast));
> 486 if (tvdiff.tv_sec != 0) {
>
> systime.c: In function 'step_systime':
> systime.c:486:5: warning: assuming signed overflow does not occur when
> simplifying conditional to constant [-Wstrict-overflow]
>
> What possible optimization might be going on to cause an overflow
> problem when I simply want to know if the "tv_sec" field is zero or
> not? (BTW, in current source, "tvdiff" is a structure that is returned
> by abs_tval())
>
> $ gcc --version
> gcc (SUSE Linux) 4.8.5
> Copyright (C) 2015 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


/* make sure microseconds are in nominal range */
static inline struct timeval
normalize_tval(
struct timeval  x
)
{
longz;

if (x.tv_usec < -3l * MICROSECONDS ||
x.tv_usec >  3l * MICROSECONDS  ) {
z = x.tv_usec / MICROSECONDS;
x.tv_usec -= z * MICROSECONDS;
x.tv_sec += z;
}

if (x.tv_usec < 0)
do {
x.tv_usec += MICROSECONDS;
x.tv_sec--;
} while (x.tv_usec < 0);
else if (x.tv_usec >= MICROSECONDS)
do {
x.tv_usec -= MICROSECONDS;
x.tv_sec++;
} while (x.tv_usec >= MICROSECONDS);

return x;
}
/* x = a - b */
static inline struct timeval
sub_tval(
struct timeval  a,
struct timeval  b
)
{
struct timeval  x;

x = a;
x.tv_sec -= b.tv_sec;
x.tv_usec -= b.tv_usec;

return normalize_tval(x);
}

/* x = abs(a) */
static inline struct timeval
abs_tval(
struct timeval  a
)
{
struct timeval  c;

c = normalize_tval(a);
if (c.tv_sec < 0) {
if (c.tv_usec != 0) {
c.tv_sec = -c.tv_sec - 1;
c.tv_usec = MICROSECONDS - c.tv_usec;
} else {
c.tv_sec = -c.tv_sec;
}
}

return c;
}

And the larger code fragment:


/* get the current time as l_fp (without fuzz) and as struct timeval */
get_ostime();
fp_sys = tspec_stamp_to_lfp(timets);
tvlast.tv_sec = timets.tv_sec;
tvlast.tv_usec = (timets.tv_nsec + 500) / 1000;

/* get the target time as l_fp */
L_ADD(_sys, _ofs);

/* unfold the new system time */
timetv = lfp_stamp_to_tval(fp_sys, );

/* now set new system time */
if (ntp_set_tod(, NULL) != 0) {
msyslog(LOG_ERR, "step-systime: %m");
if (enable_panic_check && allow_panic) {
msyslog(LOG_ERR, "step_systime: allow_panic is TRUE!");
}
return FALSE;
}

/* <--- time-critical path ended with 'ntp_set_tod()' <--- */

sys_residual = 0;
lamport_violated = (step < 0);
if (step_callback)
(*step_callback)();

tvdiff = abs_tval(sub_tval(timetv, tvlast));
if (tvdiff.tv_sec != 0) {

assuming signed overflow does not occur

[Bruce Korb]

I know about all these theoretical possibilities of numbers behaving
in strange ways when arithmetic optimizations assume that signed
overflow won't occur when they actually might. Yep, it creates subtle
bugs. The warning is worthwhile. Still and all:

485 tvdiff = abs_tval(sub_tval(timetv, tvlast));
486 if (tvdiff.tv_sec != 0) {

systime.c: In function 'step_systime':
systime.c:486:5: warning: assuming signed overflow does not occur when
simplifying conditional to constant [-Wstrict-overflow]

What possible optimization might be going on to cause an overflow
problem when I simply want to know if the "tv_sec" field is zero or
not? (BTW, in current source, "tvdiff" is a structure that is returned
by abs_tval())

$ gcc --version
gcc (SUSE Linux) 4.8.5
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Re: Problem with "" vs <> headers and fixincludes

[Bruce Korb]

T-Bird snafu resend:

On 06/05/17 14:52, Bruce Korb wrote:
> On 06/01/17 07:24, Douglas B Rupp wrote:
>>
>> This is a reproducer for a problem we have with fixincludes on
>> vxworks6.6.  The desired output is
>> FOO= 1
>>
>> The problem is the rules for handling headers enclosed in quotes can
>> cause gcc to #include the original header not the patched header.
>>
>> It seems like a problem that could theoretically occur on any target, so
>> what is the solution (other than copying each and every header into
>> include-fixed)?
> You have to have a include-fixed/h/foo.h header that has the line
> 
>> #include "arch/x86.h"
> 
> No way around that. fixincludes doesn't change the language.
> 

Re: Problem with "" vs <> headers and fixincludes

[Bruce Korb]

On 06/01/17 07:24, Douglas B Rupp wrote:
> 
> This is a reproducer for a problem we have with fixincludes on
> vxworks6.6.  The desired output is
> FOO= 1
> 
> The problem is the rules for handling headers enclosed in quotes can
> cause gcc to #include the original header not the patched header.
> 
> It seems like a problem that could theoretically occur on any target, so
> what is the solution (other than copying each and every header into
> include-fixed)?
You have to have a include-fixed/h/foo.h header that has the line

> #include "arch/x86.h"

No way around that. fixincludes doesn't change the language.

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.

Re: fatal error: config.h: No such file or directory

[Bruce Korb]

On 12/23/14 09:07, Aldy Hernandez wrote:

Andrew Haley a...@redhat.com writes:


On 12/21/2014 02:38 AM, Bruce Korb wrote:

Shouldn't the configure step have made config.h?


It's probably because you are building in srcdir.  That is not
supported.


Hmm, newbies run into this often enough that I wonder whether we should
just error out from the configuration stage.


Yeah, we newbies who've only been fiddling it for 15 years.
I think it a good idea.  My script that does the configure  build
is much newer though.  It's only about 5 years old.

Good error messages are really, really, really important --
especially if you are changing requirements.  Someone from
the distant dusty past may wind up with a stubbed toe.

Oh, another point:

Some projects cannot be built with separate source/build directories
and some projects (like yours) cannot be build without separation.
So the real question is, Does it really save enough development effort
that it is not worth doing the you can build it either way way?

fatal error: config.h: No such file or directory

[Bruce Korb]

after 2 hours and 10 minutes:


/bin/sh ./libtool --tag=CXX   --mode=compile 
/u/gnu/proj/gcc-svn-bld/host-x86_64-unknown-linux-gnu/gcc/xg++ 
-B/u/gnu/proj/gcc-svn-bld/host-x86_64-unknown-linux-gnu/gcc/ -nostdinc++ `if 
test -f 
/u/gnu/proj/gcc-svn-bld/x86_64-unknown-linux-gnu/libstdc++-v3/scripts/testsuite_flags;
 then /bin/sh 
/u/gnu/proj/gcc-svn-bld/x86_64-unknown-linux-gnu/libstdc++-v3/scripts/testsuite_flags
 --build-includes; else echo -funconfigured-libstdc++-v3 ; fi` 
-L/u/gnu/proj/gcc-svn-bld/x86_64-unknown-linux-gnu/libstdc++-v3/src 
-L/u/gnu/proj/gcc-svn-bld/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs 
-L/u/gnu/proj/gcc-svn-bld/x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs 
-B/u/gnu/proj/gcc-svn-bld/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs 
-B/u/gnu/proj/gcc-svn-bld/x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs 
-B/u/gnu/proj/gcc-svn-inst/x86_64-unknown-linux-gnu/bin/ 
-B/u/gnu/proj/gcc-svn-inst/x86_64-unknown-linux-gnu/lib/ -isystem 
/u/gnu/proj/gcc-svn-inst/x86_64-unknown-linux-gnu/includ

e
-isystem /u/gnu/proj/gcc-svn-inst/x86_64-unknown-linux-gnu/sys-include
-DHAVE_CONFIG_H -I. -I../.././libcc1  -I ../.././libcc1/../include -I 
../.././libcc1/../libgcc -I ../host-x86_64-unknown-linux-gnu/gcc 
-I../.././libcc1/../gcc -I ../.././libcc1/../gcc/c -I 
../.././libcc1/../gcc/c-family -I ../.././libcc1/../libcpp/include   -W -Wall  
-fvisibility=hidden -g -O2 -D_GNU_SOURCE -MT findcomp.lo -MD -MP -MF 
.deps/findcomp.Tpo -c -o findcomp.lo ../.././libcc1/findcomp.cc

libtool: compile:  
/u/gnu/proj/gcc-svn-bld/host-x86_64-unknown-linux-gnu/gcc/xg++ 
-B/u/gnu/proj/gcc-svn-bld/host-x86_64-unknown-linux-gnu/gcc/ -nostdinc++ 
-nostdinc++ 
-I/u/gnu/proj/gcc-svn-bld/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu
 -I/u/gnu/proj/gcc-svn-bld/x86_64-unknown-linux-gnu/libstdc++-v3/include 
-I/u/gnu/proj/gcc-svn-bld/libstdc++-v3/libsupc++ 
-I/u/gnu/proj/gcc-svn-bld/libstdc++-v3/include/backward 
-I/u/gnu/proj/gcc-svn-bld/libstdc++-v3/testsuite/util 
-L/u/gnu/proj/gcc-svn-bld/x86_64-unknown-linux-gnu/libstdc++-v3/src 
-L/u/gnu/proj/gcc-svn-bld/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs 
-L/u/gnu/proj/gcc-svn-bld/x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs 
-B/u/gnu/proj/gcc-svn-bld/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs 
-B/u/gnu/proj/gcc-svn-bld/x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs 
-B/u/gnu/proj/gcc-svn-inst/x86_64-unknown-linux-gnu/bin/ 
-B/u/gnu/proj/gcc-svn-inst/x86_64-unknown-linux-gnu/lib/ -isystem /u

/
gnu/proj/gcc-svn-inst/x86_64-unknown-linux-gnu/include -isystem 
/u/gnu/proj/gcc-svn-inst/x86_64-unknown-linux-gnu/sys-include -DHAVE_CONFIG_H 
-I. -I../.././libcc1 -I ../.././libcc1/../include -I ../.././libcc1/../libgcc 
-I ../host-x86_64-unknown-linux-gnu/gcc -I../.././libcc1/../gcc -I 
../.././libcc1/../gcc/c -I ../.././libcc1/../gcc/c-family -I 
../.././libcc1/../libcpp/include -W -Wall -fvisibility=hidden -g -O2 
-D_GNU_SOURCE -MT findcomp.lo -MD -MP -MF .deps/findcomp.Tpo -c 
../.././libcc1/findcomp.cc  -fPIC -DPIC -o .libs/findcomp.o

../.././libcc1/findcomp.cc:20:20: fatal error: config.h: No such file or 
directory
compilation terminated.
make[3]: *** [findcomp.lo] Error 1
make[3]: Leaving directory 
`/u/gnu/proj/gcc-svn-bld/host-x86_64-unknown-linux-gnu/libcc1'
make[2]: *** [all] Error 2
make[2]: Leaving directory 
`/u/gnu/proj/gcc-svn-bld/host-x86_64-unknown-linux-gnu/libcc1'
make[1]: *** [all-libcc1] Error 2
make[1]: Leaving directory `/u/gnu/proj/gcc-svn-bld'
make: *** [all] Error 2


The config:

 ./configure --enable-languages=c,c++ --disable-multilib 
--prefix=/u/gnu/proj/gcc-svn-inst 'CFLAGS=-g -Wall'

(I must disable multilib or it chokes and dies very early.)

Shouldn't the configure step have made config.h?

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: [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. :)

BUG: Bad line number in a message

[Bruce Korb]

Hi,  this is for 4.3.3, which is a bit old, so I'm not filing  a bug.


static inline void * get_resp_ptr(U32 bkade, U32 q_id)
{
blade_data_t * bd = bfr_blade_data + ssdId;
bfr_pendcmd_q_t * pcq = bd-bfrpb_ques + q_id;
blade_resp_t *res = pcq-bfrpq_resp;

return (void *)(res + pcq-bfrpq_resp_rdix);
}

I invoked this with a constant q_id value that was too large for the
bfrpb_ques array.
The error message indicated array subscript is above array bounds for the next
line.  I do hope it is no longer an issue. :)

Cheers - Bruce

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.

Re: bisonc++ ??

[Bruce Korb]

On 12/08/13 07:21, Jonathan Wakely wrote:

It usually means you don't have bison and/or flex installed.


Flex.


They are documented as prerequisites for building from svn.


Documented prerequisites may as well be documented:

   in the cellar...in the bottom of a locked filing cabinet stuck in a
   disused lavatory with a sign on the door saying ‘Beware of the Leopard.”

(Sorry, I like Doug Adams.)

The problem being that when upgrading to a more current stable release,
the development tools get stripped out, I don't remember which ones
I need and running the configure/build doesn't tell me what I am
missing anew.

Therefore, prerequisites should be tested for and any missing
should be directly announced.  I'll supply a patch to gcc-patches,
once my fixinc thing is in.  Thank you! - Bruce

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.

bisonc++ ??

[Bruce Korb]

Googling:


gcc undefined reference to `lexer_line'


yields:

http://stackoverflow.com/questions/4262531/trouble-building-gcc-4-6

Please check for it in configure and mention it in the dependency message.  :)
Thank you!

Re: bisonc++ ??

[Bruce Korb]

On 12/07/13 12:59, Bruce Korb wrote:

Googling:


gcc undefined reference to `lexer_line'


yields:

http://stackoverflow.com/questions/4262531/trouble-building-gcc-4-6

Please check for it in configure and mention it in the dependency message.  :)
Thank you!


Oops -- I was too optimistic:


build/gengtype.o build/errors.o build/gengtype-lex.o 
build/gengtype-parse.o build/gengtype-state.o build/version.o 
../../build-x86_64-unknown-linux-gnu/libiberty/libiberty.a
build/gengtype.o: In function `create_optional_field_':
/u/gnu/proj/gcc-svn-bld/host-x86_64-unknown-linux-gnu/gcc/../.././gcc/gengtype.c:1002:
 undefined reference to `lexer_line'


What is this message really telling me?

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