bug#70889: 29.3; GCC14.1 MinGW compilation error

bug#70889: 29.3; GCC14.1 MinGW compilation error

[Cyril Arnould]

I wanted to check how the MinGW related issues #63365 and #63752 behave
under GCC 14.1, however I did not get that far. Running the following:


git clone https://git.savannah.gnu.org/git/emacs.git
cd emacs
./autogen.sh
./configure
make


I get the error:


sysdep.c: In function 'get_child_status':
sysdep.c:479:13: error: implicit declaration of function 'waitpid' 
[-Wimplicit-function-declaration]
   479 |       pid = waitpid (child, status, options);
       |             ^~~~~~~
sysdep.c:479:13: warning: nested extern declaration of 'waitpid' 
[-Wnested-externs]
sysdep.c: In function 'child_status_changed':
sysdep.c:525:43: error: 'WNOHANG' undeclared (first use in this function)
   525 |   return get_child_status (child, status, WNOHANG | options, 0);
       |                                           ^~~~~~~
sysdep.c:525:43: note: each undeclared identifier is reported only once 
for each function it appears in
sysdep.c:526:1: warning: control reaches end of non-void function 
[-Wreturn-type]
   526 | }
       | ^
make[2]: *** [Makefile:452: sysdep.o] Error 1
make[2]: Leaving directory '/e/git/emacs-debug-gcc14/emacs/src'
make[1]: *** [Makefile:554: src] Error 2
make[1]: Leaving directory '/e/git/emacs-debug-gcc14/emacs'
make[1]: Entering directory '/e/git/emacs-debug-gcc14/emacs'
***
*** "make all" failed with exit status 2.
***
*** You could try to:
*** - run "make bootstrap", which might fix the problem
*** - run "make V=1", which displays the full commands invoked by make,
***   to further investigate the problem
***
make[1]: *** [Makefile:418: advice-on-failure] Error 2
make[1]: Leaving directory '/e/git/emacs-debug-gcc14/emacs'
make: *** [Makefile:374: all] Error 2


Currently I'm on commit 67b1da215c9. According to the GCC 14 porting
page "It is no longer possible to call a function that has not been
declared", so I guess that's the issue here. I've noticed that in
src/syswait.c, <sys/wait.h> is only included if HAVE_SYS_WAIT_H is
defined, which it isn't. If I do include <sys/wait.h> nonetheless in
this file, the compilation continues.

For the record, I run into an internal compiler issue in thread.c
after that, but that's not on emacs to solve I guess.

bug#70890: 29.3; GCC14.1 MinGW compilation error

[Cyril Arnould]

Oops, I've used the wrong email account. Is it possible to redirect
this bug to cyril.arnould@outlook.com?

Am 12.05.2024 um 09:29 schrieb Cyril Arnould:
> I wanted to check how the MinGW related issues #63365 and #63752 behave
> under GCC 14.1, however I did not get that far. Running the following:
>
>
> git clone https://git.savannah.gnu.org/git/emacs.git
> cd emacs
> ./autogen.sh
> ./configure
> make
>
>
> I get the error:
>
>
> sysdep.c: In function 'get_child_status':
> sysdep.c:479:13: error: implicit declaration of function 'waitpid' 
> [-Wimplicit-function-declaration]
>   479 |       pid = waitpid (child, status, options);
>       |             ^~~~~~~
> sysdep.c:479:13: warning: nested extern declaration of 'waitpid' 
> [-Wnested-externs]
> sysdep.c: In function 'child_status_changed':
> sysdep.c:525:43: error: 'WNOHANG' undeclared (first use in this function)
>   525 |   return get_child_status (child, status, WNOHANG | options, 0);
>       |                                           ^~~~~~~
> sysdep.c:525:43: note: each undeclared identifier is reported only 
> once for each function it appears in
> sysdep.c:526:1: warning: control reaches end of non-void function 
> [-Wreturn-type]
>   526 | }
>       | ^
> make[2]: *** [Makefile:452: sysdep.o] Error 1
> make[2]: Leaving directory '/e/git/emacs-debug-gcc14/emacs/src'
> make[1]: *** [Makefile:554: src] Error 2
> make[1]: Leaving directory '/e/git/emacs-debug-gcc14/emacs'
> make[1]: Entering directory '/e/git/emacs-debug-gcc14/emacs'
> ***
> *** "make all" failed with exit status 2.
> ***
> *** You could try to:
> *** - run "make bootstrap", which might fix the problem
> *** - run "make V=1", which displays the full commands invoked by make,
> ***   to further investigate the problem
> ***
> make[1]: *** [Makefile:418: advice-on-failure] Error 2
> make[1]: Leaving directory '/e/git/emacs-debug-gcc14/emacs'
> make: *** [Makefile:374: all] Error 2
>
>
> Currently I'm on commit 67b1da215c9. According to the GCC 14 porting
> page "It is no longer possible to call a function that has not been
> declared", so I guess that's the issue here. I've noticed that in
> src/syswait.c, <sys/wait.h> is only included if HAVE_SYS_WAIT_H is
> defined, which it isn't. If I do include <sys/wait.h> nonetheless in
> this file, the compilation continues.
>
> For the record, I run into an internal compiler issue in thread.c
> after that, but that's not on emacs to solve I guess.

bug#70890: 29.3; GCC14.1 MinGW compilation error

[Eli Zaretskii]

merge 70890 70889
thanks

> Date: Sun, 12 May 2024 10:24:11 +0200
> From: Cyril Arnould <2006parcy@gmail.com>
> 
> Oops, I've used the wrong email account. Is it possible to redirect
> this bug to cyril.arnould@outlook.com?

This is an exact duplicate of bug#70889 you submitted; merging them.

bug#70889: 29.3; GCC14.1 MinGW compilation error

[Eli Zaretskii]

> Date: Sun, 12 May 2024 09:29:02 +0200
> From: Cyril Arnould <2006parcy@gmail.com>
> 
> I wanted to check how the MinGW related issues #63365 and #63752 behave
> under GCC 14.1, however I did not get that far. Running the following:
> 
> 
> git clone https://git.savannah.gnu.org/git/emacs.git
> cd emacs
> ./autogen.sh
> ./configure
> make
> 
> 
> I get the error:
> 
> 
> sysdep.c: In function 'get_child_status':
> sysdep.c:479:13: error: implicit declaration of function 'waitpid' 
> [-Wimplicit-function-declaration]
>    479 |       pid = waitpid (child, status, options);
>        |             ^~~~~~~
> sysdep.c:479:13: warning: nested extern declaration of 'waitpid' 
> [-Wnested-externs]

I don't understand how this happens.  sysdep.c includes syswait.h:

  #include "syswait.h"

syswait.h does this:

  #ifdef HAVE_SYS_WAIT_H	/* We have sys/wait.h with POSIXish definitions.  */
  #include <sys/wait.h>
  #endif  /* !HAVE_SYS_WAIT_H */

The MS-Windows build does define HAVE_SYS_WAIT_H:

  /* Define to 1 if you have <sys/wait.h> that is POSIX.1 compatible. */
  #define HAVE_SYS_WAIT_H 1

because we have the emulation of that header in nt/inc/sys/wait.h, and
the compiler flags include that directory, see src/Makefile:

  CPPFLAGS = -mtune=pentium4   -DUSE_CRT_DLL=1 -I ${abs_top_srcdir}/nt/inc

So why doesn't this work in your case? which of the above parts of the
puzzle doesn't work?

> sysdep.c: In function 'child_status_changed':
> sysdep.c:525:43: error: 'WNOHANG' undeclared (first use in this function)
>    525 |   return get_child_status (child, status, WNOHANG | options, 0);
>        |                                           ^~~~~~~
> sysdep.c:525:43: note: each undeclared identifier is reported only once 
> for each function it appears in
> sysdep.c:526:1: warning: control reaches end of non-void function 
> [-Wreturn-type]

Same here: WNOHANG is defined in nt/inc/sys/wait.h.

> Currently I'm on commit 67b1da215c9. According to the GCC 14 porting
> page "It is no longer possible to call a function that has not been
> declared", so I guess that's the issue here. I've noticed that in
> src/syswait.c, <sys/wait.h> is only included if HAVE_SYS_WAIT_H is
> defined, which it isn't.

So please try to figure out how come HAVE_SYS_WAIT_H is not defined in
your case.  It should be.  The first place to look is in config.log.
In my case I have

  configure:14468: checking for sys/wait.h that is POSIX.1 compatible
  configure:14501: result: yes

> For the record, I run into an internal compiler issue in thread.c
> after that, but that's not on emacs to solve I guess.

Internal compiler errors are GCC bugs, yes.

bug#70889: 29.3; GCC14.1 MinGW compilation error

[Cyril Arnould]

[-- Attachment #1: Type: text/plain, Size: 1120 bytes --]

 > So please try to figure out how come HAVE_SYS_WAIT_H is not defined in
 > your case.  It should be.

I see, I was not aware that HAVE_SYS_WAIT_H should be defined. It's
the ./configure test that fails, the log is as follows:

configure:11647: checking for sys/wait.h that is POSIX.1 compatible
configure:11674: gcc -I ./nt/inc -c -g3 -O2 -gdwarf-2 -mtune=generic   
conftest.c >&5
conftest.c: In function 'main':
conftest.c:69:3: error: implicit declaration of function 'wait' 
[-Wimplicit-function-declaration]
    69 |   wait (&s);
       |   ^~~~
configure:11674: $? = 1
configure: failed program was:
| /* confdefs.h */

Is this an issue that should be solved by GNU autoconf? Or should the
'wait' function be added to nt/inc/sys/wait.h?

More worrying, I've checked through the config.log and found 28
occurences of the "implicit declaration of function XY" error. The
<sys/wait.h> test might not be the only one that works under GCC 13
but fails under GCC 14.

To ease reproducibility of the issue, I've switched to the emacs-29.3
tag. I've attached the config.log so you can see the other errors.

[-- Attachment #2: config.log.tar.gz --]
[-- Type: application/x-gzip, Size: 81759 bytes --]

bug#70889: 29.3; GCC14.1 MinGW compilation error

[Eli Zaretskii]

> Date: Sun, 12 May 2024 14:52:12 +0200
> Cc: 70889@debbugs.gnu.org
> From: Cyril Arnould <cyril.arnould@outlook.com>
> 
>  > So please try to figure out how come HAVE_SYS_WAIT_H is not defined in
>  > your case.  It should be.
> 
> I see, I was not aware that HAVE_SYS_WAIT_H should be defined. It's
> the ./configure test that fails, the log is as follows:
> 
> configure:11647: checking for sys/wait.h that is POSIX.1 compatible
> configure:11674: gcc -I ./nt/inc -c -g3 -O2 -gdwarf-2 -mtune=generic   
> conftest.c >&5
> conftest.c: In function 'main':
> conftest.c:69:3: error: implicit declaration of function 'wait' 
> [-Wimplicit-function-declaration]
>     69 |   wait (&s);
>        |   ^~~~
> configure:11674: $? = 1
> configure: failed program was:
> | /* confdefs.h */

I don't understand something: -Wimplicit-function-declaration is a
_warning_ option, so how come it causes an error?  Is -Werror also in
effect or something?  If so, we just need to add -Wno-error to the
compiler options.  Warnings should not fail test programs.

> Is this an issue that should be solved by GNU autoconf? Or should the
> 'wait' function be added to nt/inc/sys/wait.h?

If we need to add to our w32 headers every single function that can
fail the compilation of some test program, we will never recover from
this slippery slope.  So I'd like first to understand why a warning
causes a compilation error.

> More worrying, I've checked through the config.log and found 28
> occurences of the "implicit declaration of function XY" error. The
> <sys/wait.h> test might not be the only one that works under GCC 13
> but fails under GCC 14.

Of course.  There'll be no end to this madness.

bug#70889: 29.3; GCC14.1 MinGW compilation error

[Cyril Arnould]

 > So I'd like first to understand why a warning causes a compilation
 > error.

This is a new feature of GCC 14, unless I'm misunderstanding
something:

https://gcc.gnu.org/gcc-14/porting_to.html#warnings-as-errors

 > If we need to add to our w32 headers every single function that can
 > fail the compilation of some test program, we will never recover
 > from this slippery slope.

Would using the gnulib work instead of using emacs-proprietary w32
headers? Mostly asking out of curiosity.

bug#70889: 29.3; GCC14.1 MinGW compilation error

[Eli Zaretskii]

> Date: Sun, 12 May 2024 17:04:30 +0200
> Cc: 70889@debbugs.gnu.org
> From: Cyril Arnould <cyril.arnould@outlook.com>
> 
>  > So I'd like first to understand why a warning causes a compilation
>  > error.
> 
> This is a new feature of GCC 14, unless I'm misunderstanding
> something:
> 
> https://gcc.gnu.org/gcc-14/porting_to.html#warnings-as-errors

Which also says that turning these back into warnings is as simple as
adding -Wno-error=implicit-function-declaration.  Can you try that
(via CFLAGS=... setting when you run the configure script)?

>  > If we need to add to our w32 headers every single function that can
>  > fail the compilation of some test program, we will never recover
>  > from this slippery slope.
> 
> Would using the gnulib work instead of using emacs-proprietary w32
> headers? Mostly asking out of curiosity.

No.  Where we can use Gnulib we already do.

bug#70889: 29.3; GCC14.1 MinGW compilation error

[Cyril Arnould]

 > Which also says that turning these back into warnings is as simple as
 > adding -Wno-error=implicit-function-declaration.  Can you try that
 > (via CFLAGS=... setting when you run the configure script)?

Oh, I hadn't seen that. Yep, with this flag the configure script's
errors turn into warnings and subsequent the compilation error is
gone.

Only the GCC internal compilation error remains, but it seems that
adding the '-fno-fold-mem-offsets' flag provides a workaround for
that. FYI.

bug#70889: 29.3; GCC14.1 MinGW compilation error

[Eli Zaretskii]

> Date: Sun, 12 May 2024 18:21:56 +0200
> Cc: 70889@debbugs.gnu.org
> From: Cyril Arnould <cyril.arnould@outlook.com>
> 
>  > Which also says that turning these back into warnings is as simple as
>  > adding -Wno-error=implicit-function-declaration.  Can you try that
>  > (via CFLAGS=... setting when you run the configure script)?
> 
> Oh, I hadn't seen that. Yep, with this flag the configure script's
> errors turn into warnings and subsequent the compilation error is
> gone.

Then I guess we should use that on MS-Windows when running the
configure script.  Paul, is there a better way.

> Only the GCC internal compilation error remains, but it seems that
> adding the '-fno-fold-mem-offsets' flag provides a workaround for
> that. FYI.

The fact that GCC reports an ICE for a perfectly valid C code means
you should not yet use that version of GCC to build programs that are
supposed to be reliable.  My recommendation is to wait until GCC 14.2
is released, and in the meantime stay with GCC 13.

bug#70889: 29.3; GCC14.1 MinGW compilation error

[Paul Eggert]

On 2024-05-12 10:16, Eli Zaretskii wrote:

>> Oh, I hadn't seen that. Yep, with this flag the configure script's
>> errors turn into warnings and subsequent the compilation error is
>> gone.
> 
> Then I guess we should use that on MS-Windows when running the
> configure script.  Paul, is there a better way.

In the short run, having 'configure' use 
-Wno-error=implicit-function-declaration on MS-Windows should work 
around the issue. Eventually, though, I suspect it'll cause further 
problems, as the C standard indeed prohibits implicit function declarations.

We ran into this problem with Autoconf a while back, and we fixed it by 
supplying the missing decls. Emacs might be better off doing something 
similar, by adding the missing declarations to nt/inc/sys/wait.h. After 
all, the 'configure' diagnostic:

    checking for sys/wait.h that is POSIX.1 compatible.... no

is correct, as nt/inc/sys/wait.h doesn't declare 'wait' as POSIX 
requires. I realize this will be a bit of a hassle, but it shouldn't be 
much hassle and in the long run I expect it to be less hassle than using 
-Wno-error=implicit-function-declaration.

> My recommendation is to wait until GCC 14.2
> is released, and in the meantime stay with GCC 13.

I've had good luck building Emacs with gcc (GCC) 14.0.1 20240411 (Red 
Hat 14.0.1-0) on x86-64, in the sense that the only compiler bug I ran 
into was also present in GCC 13 and the bug didn't cause a serious 
problem with Emacs.

I would not be surprised if GCC 14 is buggier on MS-Windows, though.

bug#70889: 29.3; GCC14.1 MinGW compilation error

[Eli Zaretskii]

> Date: Sun, 12 May 2024 12:18:53 -0700
> Cc: 70889@debbugs.gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> 
> On 2024-05-12 10:16, Eli Zaretskii wrote:
> 
> >> Oh, I hadn't seen that. Yep, with this flag the configure script's
> >> errors turn into warnings and subsequent the compilation error is
> >> gone.
> > 
> > Then I guess we should use that on MS-Windows when running the
> > configure script.  Paul, is there a better way.
> 
> In the short run, having 'configure' use 
> -Wno-error=implicit-function-declaration on MS-Windows should work 
> around the issue. Eventually, though, I suspect it'll cause further 
> problems, as the C standard indeed prohibits implicit function declarations.

I didn't mean to use this when building Emacs, only when running the
test programs of the configure script.

bug#70889: 29.3; GCC14.1 MinGW compilation error

[Cyril Arnould]

Thought I'd let you know, I found another error in the config.log
which was previously a warning:


configure:23030: checking whether pthread_setname_np takes a single argument
configure:23047: gcc -I ./nt/inc -c -g3 -O2 -gdwarf-2 
-Wno-error=implicit-function-declaration -isystem 
C:/msys64/mingw64/include/librsvg-2.0 -isystem 
C:/msys64/mingw64/include/gdk-pixbuf-2.0 -isystem 
C:/msys64/mingw64/include/webp -DLIBDEFLATE_DLL -isystem 
C:/msys64/mingw64/include/cairo -isystem 
C:/msys64/mingw64/include/freetype2 -isystem 
C:/msys64/mingw64/include/libpng16 -isystem 
C:/msys64/mingw64/include/harfbuzz -isystem 
C:/msys64/mingw64/include/glib-2.0 -isystem 
C:/msys64/mingw64/lib/glib-2.0/include -isystem 
C:/msys64/mingw64/include/pixman-1 -isystem 
C:/msys64/mingw64/include/webp -mtune=generic   conftest.c >&5
conftest.c: In function 'main':
conftest.c:135:21: error: passing argument 1 of 'pthread_setname_np' 
makes integer from pointer without a cast [-Wint-conversion]
   135 | pthread_setname_np ("a");
       |                     ^~~
       |                     |
       |                     char *
In file included from conftest.c:131:
C:/msys64/mingw64/include/pthread.h:323:55: note: expected 'pthread_t' 
{aka 'long long unsigned int'} but argument is of type 'char *'
   323 | WINPTHREAD_API int       pthread_setname_np(pthread_t thread, 
const char *name);
       |                                             ~~~~~~~~~~^~~~~~
conftest.c:135:1: error: too few arguments to function 'pthread_setname_np'
   135 | pthread_setname_np ("a");
       | ^~~~~~~~~~~~~~~~~~
C:/msys64/mingw64/include/pthread.h:323:26: note: declared here
   323 | WINPTHREAD_API int       pthread_setname_np(pthread_t thread, 
const char *name);
       |                          ^~~~~~~~~~~~~~~~~~
configure:23047: $? = 1


I don't think this affects the Windows build though; if I compile with
'-Wno-error=int-conversion' the configure script still reports:

checking whether pthread_setname_np takes a single argument... no

It might possibly affect the build on other systems though.

bug#70889: 29.3; GCC14.1 MinGW compilation error

[Eli Zaretskii]

> Date: Fri, 17 May 2024 19:19:24 +0200
> Cc: 70889@debbugs.gnu.org
> From: Cyril Arnould <cyril.arnould@outlook.com>
> 
> Thought I'd let you know, I found another error in the config.log
> which was previously a warning:
> 
> 
> configure:23030: checking whether pthread_setname_np takes a single argument
> configure:23047: gcc -I ./nt/inc -c -g3 -O2 -gdwarf-2 
> -Wno-error=implicit-function-declaration -isystem 
> C:/msys64/mingw64/include/librsvg-2.0 -isystem 
> C:/msys64/mingw64/include/gdk-pixbuf-2.0 -isystem 
> C:/msys64/mingw64/include/webp -DLIBDEFLATE_DLL -isystem 
> C:/msys64/mingw64/include/cairo -isystem 
> C:/msys64/mingw64/include/freetype2 -isystem 
> C:/msys64/mingw64/include/libpng16 -isystem 
> C:/msys64/mingw64/include/harfbuzz -isystem 
> C:/msys64/mingw64/include/glib-2.0 -isystem 
> C:/msys64/mingw64/lib/glib-2.0/include -isystem 
> C:/msys64/mingw64/include/pixman-1 -isystem 
> C:/msys64/mingw64/include/webp -mtune=generic   conftest.c >&5
> conftest.c: In function 'main':
> conftest.c:135:21: error: passing argument 1 of 'pthread_setname_np' 
> makes integer from pointer without a cast [-Wint-conversion]
>    135 | pthread_setname_np ("a");
>        |                     ^~~
>        |                     |
>        |                     char *
> In file included from conftest.c:131:
> C:/msys64/mingw64/include/pthread.h:323:55: note: expected 'pthread_t' 
> {aka 'long long unsigned int'} but argument is of type 'char *'
>    323 | WINPTHREAD_API int       pthread_setname_np(pthread_t thread, 
> const char *name);
>        |                                             ~~~~~~~~~~^~~~~~
> conftest.c:135:1: error: too few arguments to function 'pthread_setname_np'
>    135 | pthread_setname_np ("a");
>        | ^~~~~~~~~~~~~~~~~~
> C:/msys64/mingw64/include/pthread.h:323:26: note: declared here
>    323 | WINPTHREAD_API int       pthread_setname_np(pthread_t thread, 
> const char *name);
>        |                          ^~~~~~~~~~~~~~~~~~
> configure:23047: $? = 1
> 
> 
> I don't think this affects the Windows build though; if I compile with
> '-Wno-error=int-conversion' the configure script still reports:
> 
> checking whether pthread_setname_np takes a single argument... no

We don't want the Windows build to use pthreads, so this doesn't
affect the Windows build in any way.

> It might possibly affect the build on other systems though.

Let's wait for them to complain, if this is even a problem on those
other platforms.

Thanks.

bug#70889: 29.3; GCC14.1 MinGW compilation error

[Eli Zaretskii]

> Cc: 70889@debbugs.gnu.org, cyril.arnould@outlook.com
> Date: Mon, 13 May 2024 07:43:39 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > Date: Sun, 12 May 2024 12:18:53 -0700
> > Cc: 70889@debbugs.gnu.org
> > From: Paul Eggert <eggert@cs.ucla.edu>
> > 
> > On 2024-05-12 10:16, Eli Zaretskii wrote:
> > 
> > >> Oh, I hadn't seen that. Yep, with this flag the configure script's
> > >> errors turn into warnings and subsequent the compilation error is
> > >> gone.
> > > 
> > > Then I guess we should use that on MS-Windows when running the
> > > configure script.  Paul, is there a better way.
> > 
> > In the short run, having 'configure' use 
> > -Wno-error=implicit-function-declaration on MS-Windows should work 
> > around the issue. Eventually, though, I suspect it'll cause further 
> > problems, as the C standard indeed prohibits implicit function declarations.
> 
> I didn't mean to use this when building Emacs, only when running the
> test programs of the configure script.

Now done on the master branch.  People who use GCC 14 on Windows
please test and report any problems you see.

bug#70889: 29.3; GCC14.1 MinGW compilation error

[Cyril Arnould]

 > Now done on the master branch.  People who use GCC 14 on Windows
 > please test and report any problems you see.

Just updated, the following builds with no issues:

./autogen.sh
./configure
make

Thanks!

bug#70889: 29.3; GCC14.1 MinGW compilation error

[Eli Zaretskii]

> Date: Sun, 19 May 2024 12:06:19 +0200
> Cc: eggert@cs.ucla.edu, 70889@debbugs.gnu.org
> From: Cyril Arnould <cyril.arnould@outlook.com>
> 
>  > Now done on the master branch.  People who use GCC 14 on Windows
>  > please test and report any problems you see.
> 
> Just updated, the following builds with no issues:
> 
> ./autogen.sh
> ./configure
> make

Thanks for testing, I'm therefore closing this bug.