[Bug modula2/104065] New: [12 Regression] trunk 20220117 fails to build modula2

[Bug modula2/104065] New: [12 Regression] trunk 20220117 fails to build modula2

[doko at debian dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104065

            Bug ID: 104065
           Summary: [12 Regression] trunk 20220117 fails to build modula2
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: modula2
          Assignee: unassigned at gcc dot gnu.org
          Reporter: doko at debian dot org
  Target Milestone: ---

seen with trunk 20220117, not seen with 20220116:

In file included from ../../src/gcc/system.h:1243,
                 from ../../src/gcc/m2/mc-boot/GArgs.c:29:
../../src/gcc/hwint.h:361:1: error: conflicting types for 'mul_hwi'; have 'long
int(long int,  long int,  unsigned char *)'
  361 | mul_hwi (HOST_WIDE_INT a, HOST_WIDE_INT b, bool *overflow)
      | ^~~~~~~
../../src/gcc/hwint.h:264:22: note: previous declaration of 'mul_hwi' with type
'long int(long int,  long int)'
  264 | extern HOST_WIDE_INT mul_hwi (HOST_WIDE_INT, HOST_WIDE_INT);
      |                      ^~~~~~~

[Bug modula2/104065] [12 Regression] trunk 20220117 fails to build modula2

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104065

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |build

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I get the feeling this is compiling with the C front-end rather than the C++
front-end like it should be ....

[Bug modula2/104065] [12 Regression] trunk 20220117 fails to build modula2

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104065

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |12.0

[Bug modula2/104065] [12 Regression] trunk 20220117 fails to build modula2

[gaius at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104065

--- Comment #2 from Gaius Mulley <gaius at gcc dot gnu.org> ---
Thanks for the hint.  I've now renamed the .c files to .cc and adjusted the
Make-lang.in and waiting for the full bootstrap to complete before pushing
changes.

[Bug modula2/104065] [12 Regression] trunk 20220117 fails to build modula2

[gaius at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104065

Gaius Mulley <gaius at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2022-01-18
             Status|UNCONFIRMED                 |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |gaius at gcc dot gnu.org

[Bug modula2/104065] [12 Regression] trunk 20220117 fails to build modula2

[gaius at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104065

Gaius Mulley <gaius at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #3 from Gaius Mulley <gaius at gcc dot gnu.org> ---
Marking as resolved as it now builds due to git merge and also with the
renaming .c to .cc source files fix.

Referencing git commit on branch devel/modula2
6d7456f841905c18772787d257023f67fe397517.

[Bug modula2/104065] [12 Regression] trunk 20220117 fails to build modula2

[doko at debian dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104065

Matthias Klose <doko at debian dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|FIXED                       |---
             Status|RESOLVED                    |NEW

--- Comment #4 from Matthias Klose <doko at debian dot org> ---
reopening. the build failure is still there.

the branch currently has:

--- a/gcc/hwint.h
+++ b/gcc/hwint.h
@@ -257,11 +257,14 @@ exact_log2 (unsigned HOST_WIDE_INT x)
   (HOST_WIDE_INT_1U << (HOST_BITS_PER_WIDE_INT - 1))
 #define HOST_WIDE_INT_MAX (~(HOST_WIDE_INT_MIN))

+#ifndef __cplusplus
 extern HOST_WIDE_INT abs_hwi (HOST_WIDE_INT);
 extern unsigned HOST_WIDE_INT absu_hwi (HOST_WIDE_INT);
-extern HOST_WIDE_INT gcd (HOST_WIDE_INT, HOST_WIDE_INT);
 extern HOST_WIDE_INT pos_mul_hwi (HOST_WIDE_INT, HOST_WIDE_INT);
 extern HOST_WIDE_INT mul_hwi (HOST_WIDE_INT, HOST_WIDE_INT);
+#endif  /* !cplusplus.  */
+
+extern HOST_WIDE_INT gcd (HOST_WIDE_INT, HOST_WIDE_INT);
 extern HOST_WIDE_INT least_common_multiple (HOST_WIDE_INT, HOST_WIDE_INT);

 /* Like ctz_hwi, except 0 when x == 0.  */
@@ -316,6 +319,7 @@ zext_hwi (unsigned HOST_WIDE_INT src, unsigned int prec)
     }
 }

+#ifdef __cplusplus
 /* Compute the absolute value of X.  */

 inline HOST_WIDE_INT
@@ -374,5 +378,6 @@ mul_hwi (HOST_WIDE_INT a, HOST_WIDE_INT b, bool *overflow)
   return result;
 #endif
 }
+#endif /* ! __cplusplus */

 #endif /* ! GCC_HWINT_H */


and the file is compiled using gcc (at least in stage1).

Looks like m2/Make-lang.in uses it's own definition HOSTCC to build these
files.  So maybe define a HOSTCXX and build with that instead?  There's also a
macro CPLUS which is unused.

However, these macros should be taken from the parent Makefile, so maybe just
use CC and CXX instead?

Trying
--- a/gcc/m2/Make-lang.in
+++ b/gcc/m2/Make-lang.in
@@ -32,7 +32,7 @@
 GM2_1 = ./gm2 -B./stage1/m2 -g -fm2-g
 XGCC = ./xgcc -B./
 GM2_2 = ./gm2 -B./stage2/m2 -g -fm2-g
-HOSTCC = gcc
+HOSTCC = $(CXX)
 CFLAGS=-g   ## remove this
 LDLAGS=-g   ## remove this

doesn't work, gm2 isn't yet C++ ready.

Jakub confirmed on irc:
<jakub> compiling with hwint.h includes with C is not supported anymore...

[Bug modula2/104065] [12 Regression] trunk 20220117 fails to build modula2

[gaius at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104065

Gaius Mulley <gaius at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

--- Comment #5 from Gaius Mulley <gaius at gcc dot gnu.org> ---
Thanks - the devel/modula2 was missing two patches one for hwint.h and another
for i386.cc and a few C++ testcases.  I'm applying all of these - and now see
the build failure.

[Bug modula2/104065] [12 Regression] trunk 20220117 fails to build modula2

[gaius at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104065

--- Comment #6 from Gaius Mulley <gaius at gcc dot gnu.org> ---
ok I've fixed the problem above and the bootstrap tool builds cleanly with a
C++ compiler.  I'm continuing the build before git pushing changes.  I've
changed most if not all $(CC) to $(CXX) inside the Make-lang.in for
consistency.

[Bug modula2/104065] [12 Regression] trunk 20220117 fails to build modula2

[gaius at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104065

--- Comment #7 from Gaius Mulley <gaius at gcc dot gnu.org> ---
All fixed now (I think), see mailing list entry

 https://gcc.gnu.org/pipermail/gcc-cvs/2022-January/359679.html

In summary $(CC) is only used to compile flex generated source.  $(CXX) is used
instead.  The bootstrap tool has been updated and emits GCC headers system and
config inside C++ code blocks and not within extern C blocks.

[Bug modula2/104065] [12 Regression] trunk 20220117 fails to build modula2

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104065

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|ASSIGNED                    |RESOLVED

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
thus fixed (again)