Bug 23400 - [4.1/4.2 Regression] "make check" fixinclude failure
Summary: [4.1/4.2 Regression] "make check" fixinclude failure
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: testsuite (show other bugs)
Version: 4.1.0
: P5 minor
Target Milestone: 4.1.0
Assignee: Not yet assigned to anyone
URL:
Keywords:
: 24870 26646 (view as bug list)
Depends on:
Blocks:
 
Reported: 2005-08-15 14:50 UTC by Adrian Bunk
Modified: 2006-03-11 16:51 UTC (History)
6 users (show)

See Also:
Host: i686-pc-linux-gnu
Target: i686-pc-linux-gnu
Build: i686-pc-linux-gnu
Known to work: 4.0.1
Known to fail:
Last reconfirmed: 2005-09-15 20:52:46


Attachments
Add newline to replacement fixup for string.h (1.14 KB, patch)
2005-11-20 13:26 UTC, Bernhard Fischer
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Adrian Bunk 2005-08-15 14:50:43 UTC
With a current HEAD CVS checkout:

<--  snip  -->

...
Fixed:  X11/ShellP.h
Fixed:  X11/Xmu.h
Fixed:  Xm/BaseClassI.h
Fixed:  Xm/Traversal.h
cmp: EOF on string.h
*** string.h    2005-08-15 16:47:11.000000000 +0200
--- /TMP/test/gcc/gcc/fixincludes/tests/base/string.h   2005-08-15
14:32:57.000000000 +0200
***************
*** 10,13 ****
  #ifndef _STRING_INCLUDED
    #define _STRING_INCLUDED
    #include <strings.h>
! #endif /* _STRING_INCLUDED */
\ No newline at end of file
--- 10,13 ----
  #ifndef _STRING_INCLUDED
    #define _STRING_INCLUDED
    #include <strings.h>
! #endif /* _STRING_INCLUDED */

There were fixinclude test FAILURES
make[1]: *** [check] Error 1
make[1]: Leaving directory `/TMP/test/gcc/gcc/build/fixincludes'
make: *** [check-fixincludes] Error 2

<--  snip  -->
Comment 1 Andrew Pinski 2005-09-05 19:47:09 UTC
This works for me.
Comment 2 Georg Bauhaus 2005-09-15 20:33:10 UTC
Does not work for me, checkouts from Sep. 8, and
from today (Sep. 15). Exact same error when running
make check, after make bootstrap.

Debian stable, SMP, autogen 5.6.6-2, autoconf 2.59a-3,
.../configure   --prefix=/home/georg/opt/GCC/41 --disable-nls 
--enable-languages=c,ada,c++,fortran

Anything I should look at?

Comment 3 Eric Botcazou 2005-09-15 20:52:46 UTC
Same on my AMD64/Linux box.
Comment 4 Georg Bauhaus 2005-09-16 03:11:06 UTC
looking at tests/res/string.h in the build area, it does lack \n at EOF,
so the message is correct. (All other files do have \n at EOF.)

inclhack.def:2004 has the following comment.

/* The string.h result is overwritten by AAB_ultrix_string when doing
       "make check" and will fail.  Therefore, we add the following kludgery
       to insert the test_text into the special testing header.  :-}  */

My wild guess is that this might apply because starting on
inclhack.def:548, there is the only occurence of the contents
of tests/res/string.h (that I could find).
Comment 5 Andrew Pinski 2005-11-15 15:15:30 UTC
*** Bug 24870 has been marked as a duplicate of this bug. ***
Comment 6 Bernhard Fischer 2005-11-20 13:26:01 UTC
Created attachment 10300 [details]
Add newline to replacement fixup for string.h

I wouldn't generally add a newline in the replace command but adjust the fixups which expect the newline to contain a newline in the replacement text.

The following patch gcc.gfortran-pr23400-00.diff adds a newline to the string replacement which fixes the fixincludes failiure for me on i686-linux-gnu on debian unstable.

gcc.gfortran-pr23400-00.diff

2005-11-20 Bernhard Fischer <rep.nop@aon.at>

        PR 23400
        * inclhack.def: Add newline to the replace text for string.h.
        * fixincl.x: Regenerate.
Comment 7 Georg Bauhaus 2005-11-20 17:56:00 UTC
>         PR 23400
>         * inclhack.def: Add newline to the replace text for string.h.
>         * fixincl.x: Regenerate.
 
Similarly, removing \n from last line of the string.h
in the fixincludes source directory works for me (seemingly,
make check is running).
(-rw-r--r--  1 georg staff 328 2005-11-20 16:42 ../src/gcc/fixincludes/tests/base/string.h)

Why is there an Ultrix fix in string.h in the first place?
Does it just happen to be there because that is how
fixinclude had finished writing headers at some point?

Comment 8 Bruce Korb 2005-11-25 07:25:05 UTC
A couple of issues:
1.  Replacement fixes should not be checked, so it is interesting that
    the failure shows up.

2.  fixincl should not create files without terminating new lines anyway.
    I've just applied a patch to fixfixes.c to fix this problem.

I'll look into the former issue when my bootstrap finishes....:)
I'd assign this thing to myself, but I guess I'm not powerful enough....
Comment 9 Andrew Pinski 2005-12-30 07:28:28 UTC
Fixed by (on both the mainline and the 4.1 branch):
2005-11-24  Bruce Korb  <bkorb@gnu.org>

        * fixincl.c(write_replacement) "here strings" in AutoGen often/generally
        don't have a terminating newline.  Check the last byte for '\n'.
Comment 10 Andrew Pinski 2006-03-11 16:51:32 UTC
*** Bug 26646 has been marked as a duplicate of this bug. ***