[Bug bootstrap/89494] Bootstrap error when using GCC 4.2.1

[Bug bootstrap/89494] Bootstrap error when using GCC 4.2.1

[pkubaj at anongoth dot pl]

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

--- Comment #12 from Piotr Kubaj <pkubaj at anongoth dot pl> ---
This issue can be fixed with the following patches:
--- gcc/dumpfile.c.orig 2020-04-07 14:09:14 UTC
+++ gcc/dumpfile.c
@@ -2055,7 +2055,7 @@ temp_dump_context::temp_dump_context (bool forcibly_en
                                      bool forcibly_enable_dumping,
                                      dump_flags_t test_pp_flags)
 : m_context (),
-  m_saved (&dump_context ().get ())
+  m_saved(&dump_context::get())
 {
   dump_context::s_current = &m_context;
   if (forcibly_enable_optinfo)
--- libgcc/config/rs6000/t-crtstuff.orig        2020-04-07 15:17:50 UTC
+++ libgcc/config/rs6000/t-crtstuff
@@ -3,4 +3,4 @@
 # Do not build crtend.o with -Os as that can result in references to
 # out-of-line register save/restore functions, which may be unresolved
 # as crtend.o is linked after libgcc.a.  See PR45053.
-CRTSTUFF_T_CFLAGS = -msdata=none -O2 -fno-asynchronous-unwind-tables
+CRTSTUFF_T_CFLAGS = -msdata=none -O0 -fno-asynchronous-unwind-tables
--- Makefile.in.orig    2020-04-08 13:04:40 UTC
+++ Makefile.in
@@ -372,7 +372,7 @@ BUILD_PREFIX_1 = @BUILD_PREFIX_1@

 # Flags to pass to stage2 and later makes.  They are defined
 # here so that they can be overridden by Makefile fragments.
-BOOT_CFLAGS= -g -O2
+BOOT_CFLAGS?= -g -O2
 BOOT_LDFLAGS=
 BOOT_ADAFLAGS= -gnatpg


And then you need to pass to configure and make the following env variables
CFLAGS_FOR_TARGET="-O0" CXXFLAGS_FOR_TARGET="-O0" BOOT_CFLAGS="-O0".
The first patch is already sent by Gustavo Romero from IBM to GCC patches list.

GCC10 needs further fixing, unfortunately.

[Bug bootstrap/89494] Bootstrap error when using GCC 4.2.1

[pkubaj at anongoth dot pl]

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

--- Comment #13 from Piotr Kubaj <pkubaj at anongoth dot pl> ---
Breakage in GCC 10 was caused after 201900818 snapshot, but before 201900825
(201900825 is the first broken).

[Bug bootstrap/89494] Bootstrap error when using GCC 4.2.1

[pkubaj at anongoth dot pl]

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

--- Comment #14 from Piotr Kubaj <pkubaj at anongoth dot pl> ---
Exact error for 10.0:
In file included from
/usr/ports/lang/gcc10-devel/work/gcc-10-20190825/libgcc/libgcc2.c:56:
/usr/ports/lang/gcc10-devel/work/gcc-10-20190825/libgcc/libgcc2.c: In function
'__multi3':
/usr/ports/lang/gcc10-devel/work/gcc-10-20190825/libgcc/libgcc2.h:203:20:
internal compiler error: tree check: expected class 'type', have 'exceptional'
(error_mark) in build_int_cst, at tree.c:1371
  203 | #define __NDW(a,b) __ ## a ## ti ## b
      |                    ^~
/usr/ports/lang/gcc10-devel/work/gcc-10-20190825/libgcc/libgcc2.h:273:18: note:
in expansion of macro '__NDW'
  273 | #define __muldi3 __NDW(mul,3)
      |                  ^~~~~
/usr/ports/lang/gcc10-devel/work/gcc-10-20190825/libgcc/libgcc2.c:548:1: note:
in expansion of macro '__muldi3'
  548 | __muldi3 (DWtype u, DWtype v)
      | ^~~~~~~~

[Bug bootstrap/89494] Bootstrap error when using GCC 4.2.1

[pkubaj at anongoth dot pl]

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

Piotr Kubaj <pkubaj at anongoth dot pl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |richard.sandiford at arm dot com

--- Comment #15 from Piotr Kubaj <pkubaj at anongoth dot pl> ---
CC'ing richard.sandiford@arm.com, whose one of commits broke building of GCC 10
with GCC 4.2.
I'm still bisecting, but it was one of those commits, all by
richard.sandiford@arm.com:
pkubaj@talos:$/usr/home/pkubaj/gcc$ git bisect view | grep commit
commit cf0d189eb989906d17010ca7c0b07f1763d5fde5
commit 634afa05a8cbff010480088811fe1f39eca70c1d
commit b12cdd6e8e8dd1f39a941b731ba1056d656a094f
commit 0ffef2005fd7536efbc9c3a572701998c8a8080c
commit 7256c7194e186fce6ff866a124a77b08196c2a5f
commit 6930c98c69ad695469ee7daa74b3b6d578afdd0d
commit 6783fdb7057d559aa1da8afa2c15a702c532a03e
commit e7056ca417326a70eca05defb6a8b20b737d3417
commit 52090e4dbd064f486af606e3f8a283dbddc7c18a
commit a7c81bc1fb43366ca1b4332d8a6042b648a84cdc
commit 4f53599cb5b822cd7f95997861c2e064977ecb6a

[Bug bootstrap/89494] Bootstrap error when using GCC 4.2.1

[pkubaj at anongoth dot pl]

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

--- Comment #16 from Piotr Kubaj <pkubaj at anongoth dot pl> ---
634afa05a8cbff010480088811fe1f39eca70c1d is the first bad commit
commit 634afa05a8cbff010480088811fe1f39eca70c1d
Author: Richard Sandiford <richard.sandiford@arm.com>
Date:   Tue Aug 20 08:53:52 2019 +0000

    Make function.c use function_arg_info internally

    This patch adds a function_arg_info field to assign_parm_data_one,
    so that:

      - passed_type -> arg.type
      - promoted_mode -> arg.mode
      - named_arg -> arg.named

    We can then pass this function_arg_info directly to the converted
    hooks.

    Between the initialisation of the assign_parm_data_one and the
    application of promotion rules (which is a state internal to
    assign_parm_find_data_types), arg.mode is equivalent to passed_mode
    (i.e. to TYPE_MODE).

    2019-08-20  Richard Sandiford  <richard.sandiford@arm.com>

    gcc/
            * function.c (assign_parm_data_one): Replace passed_type,
            promoted_mode and named_arg with a function_arg_info field.
            (assign_parm_find_data_types): Remove local variables and
            assign directly to "data".  Make data->passed_mode shadow
            data->arg.mode until promotion, then assign the promoted
            mode to data->arg.mode.
            (assign_parms_setup_varargs, assign_parm_find_entry_rtl)
            (assign_parm_find_stack_rtl, assign_parm_adjust_entry_rtl)
            (assign_parm_remove_parallels, assign_parm_setup_block_p)
            (assign_parm_setup_block, assign_parm_setup_reg)
            (assign_parm_setup_stack, assign_parms, gimplify_parameters): Use
            arg.mode instead of promoted_mode, arg.type instead of passed_type
            and arg.named instead of named_arg.  Use data->arg for
            function_arg_info structures that had the field values passed_type,
            promoted_mode and named_arg.  Base other function_arg_infos on
            data->arg, changing the necessary properties.

    From-SVN: r274705

 gcc/ChangeLog  |  19 +++++++
 gcc/function.c | 168 +++++++++++++++++++++++++--------------------------------
 2 files changed, 92 insertions(+), 95 deletions(-)

[Bug bootstrap/89494] Bootstrap error when using GCC 4.2.1

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #17 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So, what exactly happens?  Does GCC 4.2 e.g. fail to initialize all members to
zeros in the
-  memset (data, 0, sizeof (*data));
+  *data = assign_parm_data_one ();
change?
Would it work to
  memset (data, 0, sizeof (*data));
  data->arg = function_arg_info ();
for old GCC, or add for old GCC an explicit default constructor to
struct assign_parm_data_one, or
#if GCC_VERSION < 4300
  memset (data, 0, sizeof (*data));
#endif
  *data = assign_parm_data_one ();
?
Most of the other changes seem to be just about using different member names
and thus shouldn't really matter much.

[Bug bootstrap/89494] Bootstrap error when using GCC 4.2.1

[iains at gcc dot gnu.org]

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

--- Comment #18 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #17)
> So, what exactly happens?  Does GCC 4.2 e.g. fail to initialize all members
> to zeros in the
> -  memset (data, 0, sizeof (*data));
> +  *data = assign_parm_data_one ();
> change?
> Would it work to
>   memset (data, 0, sizeof (*data));
>   data->arg = function_arg_info ();
> for old GCC, or add for old GCC an explicit default constructor to
> struct assign_parm_data_one, or
> #if GCC_VERSION < 4300
>   memset (data, 0, sizeof (*data));
> #endif
>   *data = assign_parm_data_one ();
> ?
> Most of the other changes seem to be just about using different member names
> and thus shouldn't really matter much.

hmm I don't see a CTOR specified for assign_parm_data_one. So I guess it's
using an implicit default, which is perhaps trivial (assuming that the struct
assign_parm_data_one is POD, which seems possible).

Will poke at this when I have a spare machine supporting that bootstrap
compiler.

[Bug bootstrap/89494] Bootstrap error when using GCC 4.2.1

[jakub at gcc dot gnu.org]

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

--- Comment #19 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Since Richard's change, assign_parm_data_one has the arg member with
function_arg_info type, and that class has a user-provided default constructor.
Perhaps for old GCC we could instead of
  *data = assign_parm_data_one ();
do
  static assign_parm_data_one zeroed_arg;
  *data = zeroed_arg;
or whatever else actually works.
I'll try tomorrow to cook up a short testcase with the function_arg_info
default ctor and assign_parm_data_one containing it and see what GCC 4.2 does
with it.

[Bug bootstrap/89494] Bootstrap error when using GCC 4.2.1

[jakub at gcc dot gnu.org]

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

--- Comment #20 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So, we are running into PR33916 here, not very much reduced test:
class function_arg_info
{
public:
  function_arg_info ()
    : type (0), mode (0), named (false), pass_by_reference (false)
  {}
  function_arg_info (int mode, bool named)
    : type (0), mode (mode), named (named), pass_by_reference (false)
  {}
  void *type;
  int mode;
  unsigned int named : 1;
  unsigned int pass_by_reference : 1;
};

struct args_size
{
  long long int constant;
  void *var;
};

struct locate_and_pad_arg_data
{
  struct args_size size;
  struct args_size offset;
  struct args_size slot_offset;
  struct args_size alignment_pad;
  int where_pad;
  unsigned int boundary;
};

struct assign_parm_data_one
{
  void *nominal_type;
  function_arg_info arg;
  void *entry_parm;
  void *stack_parm;
  int nominal_mode;
  int passed_mode;
  struct locate_and_pad_arg_data locate;
  int partial;
};

void
foo (struct assign_parm_data_one *data)
{
  *data = assign_parm_data_one ();
}

shows that GCC 4.2.1 (and earlier too) will only clear arg.type, arg.mode,
arg.named and arg.pass_by_reference of a temporary before memcpying that
temporary to *data.

Thus, my proposal is:
2020-04-15  Jakub Jelinek  <jakub@redhat.com>

        PR bootstrap/89494
        * function.c (assign_parm_find_data_types): Add workaround for
        BROKEN_VALUE_INITIALIZATION compilers.

--- gcc/function.c.jj   2020-01-12 11:54:36.606410497 +0100
+++ gcc/function.c      2020-04-15 14:15:29.269495427 +0200
@@ -2414,7 +2414,15 @@ assign_parm_find_data_types (struct assi
 {
   int unsignedp;

+#ifndef BROKEN_VALUE_INITIALIZATION
   *data = assign_parm_data_one ();
+#else
+  /* Old versions of GCC used to miscompile the above by only initializing
+     the members with explicit constructors and copying garbage
+     to the other members.  */
+  assign_parm_data_one zero_data = {};
+  *data = zero_data;
+#endif

   /* NAMED_ARG is a misnomer.  We really mean 'non-variadic'. */
   if (!cfun->stdarg)

[Bug bootstrap/89494] Bootstrap error when using GCC 4.2.1

[cvs-commit at gcc dot gnu.org]

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

--- Comment #21 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:c00568f376078129196740d83946d54dc5437401

commit r10-7736-gc00568f376078129196740d83946d54dc5437401
Author: Gustavo Romero <gromero@linux.ibm.com>
Date:   Wed Apr 15 15:14:45 2020 +0200

    selftest: Work around GCC 4.2 PR33916 bug by optimizing the ctor [PR89494]

    GCC 4.2 due to PR33916 miscompiles temp_dump_context ctor, because it
doesn't
    zero initialize the whole dump_context temporary on which it runs the
static
    get method and during destruction of the temporary an uninitialized pointer
    is deleted.

    More recent GCC versions properly zero initialize it and ideally optimize
away
    the construction/destruction of the temporary, as it isn't used for
anything,
    but there is no reason to create the temporary, static member functions can
    be called without an associated object.

    2020-04-15  Gustavo Romero  <gromero@linux.ibm.com>

            PR bootstrap/89494
            * dumpfile.c (selftest::temp_dump_context::temp_dump_context):
            Don't construct a dump_context temporary to call static method.

[Bug bootstrap/89494] Bootstrap error when using GCC 4.2.1

[pkubaj at anongoth dot pl]

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

--- Comment #22 from Piotr Kubaj <pkubaj at anongoth dot pl> ---
(In reply to CVS Commits from comment #21)
> The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:
> 
> https://gcc.gnu.org/g:c00568f376078129196740d83946d54dc5437401
> 
> commit r10-7736-gc00568f376078129196740d83946d54dc5437401
> Author: Gustavo Romero <gromero@linux.ibm.com>
> Date:   Wed Apr 15 15:14:45 2020 +0200
> 
>     selftest: Work around GCC 4.2 PR33916 bug by optimizing the ctor
> [PR89494]
>     
>     GCC 4.2 due to PR33916 miscompiles temp_dump_context ctor, because it
> doesn't
>     zero initialize the whole dump_context temporary on which it runs the
> static
>     get method and during destruction of the temporary an uninitialized
> pointer
>     is deleted.
>     
>     More recent GCC versions properly zero initialize it and ideally
> optimize away
>     the construction/destruction of the temporary, as it isn't used for
> anything,
>     but there is no reason to create the temporary, static member functions
> can
>     be called without an associated object.
>     
>     2020-04-15  Gustavo Romero  <gromero@linux.ibm.com>
>     
>             PR bootstrap/89494
>             * dumpfile.c (selftest::temp_dump_context::temp_dump_context):
>             Don't construct a dump_context temporary to call static method.

Thanks for commiting this! Can you also merge to branch 9?

[Bug bootstrap/89494] Bootstrap error when using GCC 4.2.1

[jakub at gcc dot gnu.org]

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

--- Comment #23 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Eventually yes, but I'd like to test & submit the above patch too and let it be
tested on the trunk for a while before backporting.

[Bug bootstrap/89494] Bootstrap error when using GCC 4.2.1

[cvs-commit at gcc dot gnu.org]

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

--- Comment #24 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:42e20fd25d3651349d892d8af864dc576c09019c

commit r10-7749-g42e20fd25d3651349d892d8af864dc576c09019c
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Thu Apr 16 10:15:18 2020 +0200

    bootstrap: Fix building with GCC 4.2 [PR89494]

    GCC 4.2 (but I think not the latest tip of GCC 4.2 branch) has broken value
    initialization, see PR33916.  The following patch provides a workaround for
    that.  Tested with GCC 4.2 on a reduced testcase I've distilled from the
    assign_param_data_one class which has been miscompiled the same.

    2020-04-16  Jakub Jelinek  <jakub@redhat.com>

            PR bootstrap/89494
            * function.c (assign_parm_find_data_types): Add workaround for
            BROKEN_VALUE_INITIALIZATION compilers.

[Bug bootstrap/89494] Bootstrap error when using GCC 4.2.1

[pkubaj at anongoth dot pl]

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

Piotr Kubaj <pkubaj at anongoth dot pl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|9.3.0                       |10.0

--- Comment #25 from Piotr Kubaj <pkubaj at anongoth dot pl> ---
Happens on 20200419 snapshot:
gmake[4]: Entering directory
'/wrkdirs/usr/ports/lang/gcc10-devel/work/.build/libiberty'
if [ x"-fPIC" != x ]; then \
  /wrkdirs/usr/ports/lang/gcc10-devel/work/.build/./prev-gcc/xgcc
-B/wrkdirs/usr/ports/lang/gcc10-devel/work/.build/./prev-gcc/
-B/usr/local/powerpc64-portbld-freebsd12.1/bin/
-B/usr/local/powerpc64-portbld-freebsd12.1/bin/
-B/usr/local/powerpc64-portbld-freebsd12.1/lib/ -isystem
/usr/local/powerpc64-portbld-freebsd12.1/include -isystem
/usr/local/powerpc64-portbld-freebsd12.1/sys-include   -fno-checking -c
-DHAVE_CONFIG_H -O0 -fno-checking -gtoggle -DLIBICONV_PLUG -I.
-I/wrkdirs/usr/ports/lang/gcc10-devel/work/gcc-10-20200419/libiberty/../include
 -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -Wshadow=local
-pedantic  -D_GNU_SOURCE -fPIC
/wrkdirs/usr/ports/lang/gcc10-devel/work/gcc-10-20200419/libiberty/regex.c -o
pic/regex.o; \
else true; fi
during RTL pass: reload
In file included from
/wrkdirs/usr/ports/lang/gcc10-devel/work/gcc-10-20200419/libiberty/regex.c:639:
/wrkdirs/usr/ports/lang/gcc10-devel/work/gcc-10-20200419/libiberty/regex.c: In
function 'byte_regex_compile':
/wrkdirs/usr/ports/lang/gcc10-devel/work/gcc-10-20200419/libiberty/regex.c:4223:1:
internal compiler error: Segmentation fault
 4223 | } /* regex_compile */
      | ^
no stack trace because unwind library not available
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
gmake[4]: *** [Makefile:1179: regex.o] Error 1
gmake[4]: Leaving directory
'/wrkdirs/usr/ports/lang/gcc10-devel/work/.build/libiberty'
gmake[3]: *** [Makefile:11311: all-stage2-libiberty] Error 2
gmake[3]: Leaving directory '/wrkdirs/usr/ports/lang/gcc10-devel/work/.build'
gmake[2]: *** [Makefile:23020: stage2-bubble] Error 2
gmake[2]: Leaving directory '/wrkdirs/usr/ports/lang/gcc10-devel/work/.build'
gmake[1]: *** [Makefile:23235: bootstrap-lean] Error 2
gmake[1]: Leaving directory '/wrkdirs/usr/ports/lang/gcc10-devel/work/.build'
*** Error code 1

[Bug bootstrap/89494] Bootstrap error when using GCC 4.2.1

[cvs-commit at gcc dot gnu.org]

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

--- Comment #26 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:489c62beef150f870d1755d3772bd2d0ce7344b4

commit r9-8878-g489c62beef150f870d1755d3772bd2d0ce7344b4
Author: Gustavo Romero <gromero@linux.ibm.com>
Date:   Wed Apr 15 15:14:45 2020 +0200

    selftest: Work around GCC 4.2 PR33916 bug by optimizing the ctor [PR89494]

    GCC 4.2 due to PR33916 miscompiles temp_dump_context ctor, because it
doesn't
    zero initialize the whole dump_context temporary on which it runs the
static
    get method and during destruction of the temporary an uninitialized pointer
    is deleted.

    More recent GCC versions properly zero initialize it and ideally optimize
away
    the construction/destruction of the temporary, as it isn't used for
anything,
    but there is no reason to create the temporary, static member functions can
    be called without an associated object.

    2020-04-15  Gustavo Romero  <gromero@linux.ibm.com>

            PR bootstrap/89494
            * dumpfile.c (selftest::temp_dump_context::temp_dump_context):
            Don't construct a dump_context temporary to call static method.

    (cherry picked from commit c00568f376078129196740d83946d54dc5437401)

[Bug bootstrap/89494] Bootstrap error when using GCC 4.2.1

[iains at gcc dot gnu.org]

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

Iain Sandoe <iains at gcc dot gnu.org> changed:

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

--- Comment #27 from Iain Sandoe <iains at gcc dot gnu.org> ---
bootstrap with Apple GCC-4.2.1 for gcc-10 works as of r10-9528

NOTE: GCC-11 requires C++11 to bootstrap, and therefore is NOT expected to work
with Apple GCC-4.2.1.

[Bug bootstrap/89494] Bootstrap error when using GCC 4.2.1

[pkubaj at anongoth dot pl]

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

Piotr Kubaj <pkubaj at anongoth dot pl> changed:

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

--- Comment #28 from Piotr Kubaj <pkubaj at anongoth dot pl> ---
I just tried on FreeBSD 12.2-RELEASE on powerpc64 with base gcc 4.2.1:
gmake[4]: Entering directory
'/wrkdirs/usr/ports/lang/gcc10-devel/work/.build/gcc'
c++ -std=gnu++98 -fno-PIE -c  -DIN_GCC_FRONTEND -g -DIN_GCC   
-fno-strict-aliasing -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W
-Wall -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I. -Icp
-I/wrkdirs/usr/ports/lang/gcc10-devel/work/gcc-10-20210313/gcc
-I/wrkdirs/usr/ports/lang/gcc10-devel/work/gcc-10-20210313/gcc/cp
-I/wrkdirs/usr/ports/lang/gcc10-devel/work/gcc-10-20210313/gcc/../include
-I/wrkdirs/usr/ports/lang/gcc10-devel/work/gcc-10-20210313/gcc/../libcpp/include
-I/usr/local/include 
-I/wrkdirs/usr/ports/lang/gcc10-devel/work/gcc-10-20210313/gcc/../libdecnumber
-I/wrkdirs/usr/ports/lang/gcc10-devel/work/gcc-10-20210313/gcc/../libdecnumber/dpd
-I../libdecnumber
-I/wrkdirs/usr/ports/lang/gcc10-devel/work/gcc-10-20210313/gcc/../libbacktrace 
-DLIBICONV_PLUG -o cp/coroutines.o -MT cp/coroutines.o -MMD -MP -MF
cp/.deps/coroutines.TPo
/wrkdirs/usr/ports/lang/gcc10-devel/work/gcc-10-20210313/gcc/cp/coroutines.cc
/wrkdirs/usr/ports/lang/gcc10-devel/work/gcc-10-20210313/gcc/cp/coroutines.cc:2700:
error: invalid pure specifier (only `= 0' is allowed) before ';' token
/wrkdirs/usr/ports/lang/gcc10-devel/work/gcc-10-20210313/gcc/cp/coroutines.cc:2700:
error: initializer specified for non-virtual method
'var_nest_node::var_nest_node()'

[Bug bootstrap/89494] Bootstrap error when using GCC 4.2.1

[iains at gcc dot gnu.org]

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

--- Comment #29 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Piotr Kubaj from comment #28)
> I just tried on FreeBSD 12.2-RELEASE on powerpc64 with base gcc 4.2.1:
> gmake[4]: Entering directory
> '/wrkdirs/usr/ports/lang/gcc10-devel/work/.build/gcc'
> c++ -std=gnu++98 -fno-PIE -c  -DIN_GCC_FRONTEND -g -DIN_GCC   
> -fno-strict-aliasing -fno-exceptions -fno-rtti -fasynchronous-unwind-tables
> -W -Wall -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute
> -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
> -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I. -Icp
> -I/wrkdirs/usr/ports/lang/gcc10-devel/work/gcc-10-20210313/gcc
> -I/wrkdirs/usr/ports/lang/gcc10-devel/work/gcc-10-20210313/gcc/cp
> -I/wrkdirs/usr/ports/lang/gcc10-devel/work/gcc-10-20210313/gcc/../include
> -I/wrkdirs/usr/ports/lang/gcc10-devel/work/gcc-10-20210313/gcc/../libcpp/
> include -I/usr/local/include 
> -I/wrkdirs/usr/ports/lang/gcc10-devel/work/gcc-10-20210313/gcc/../
> libdecnumber
> -I/wrkdirs/usr/ports/lang/gcc10-devel/work/gcc-10-20210313/gcc/../
> libdecnumber/dpd -I../libdecnumber
> -I/wrkdirs/usr/ports/lang/gcc10-devel/work/gcc-10-20210313/gcc/../
> libbacktrace  -DLIBICONV_PLUG -o cp/coroutines.o -MT cp/coroutines.o -MMD
> -MP -MF cp/.deps/coroutines.TPo
> /wrkdirs/usr/ports/lang/gcc10-devel/work/gcc-10-20210313/gcc/cp/coroutines.cc
> /wrkdirs/usr/ports/lang/gcc10-devel/work/gcc-10-20210313/gcc/cp/coroutines.
> cc:2700: error: invalid pure specifier (only `= 0' is allowed) before ';'
> token
> /wrkdirs/usr/ports/lang/gcc10-devel/work/gcc-10-20210313/gcc/cp/coroutines.
> cc:2700: error: initializer specified for non-virtual method
> 'var_nest_node::var_nest_node()'

There were some fixes pushed this week - I see you have gcc-10-20210313, which
won't have picked those up.  I am about to push my remaining patches for 10.x
back port - but the ones I queued should not affect that.

If there's still an issue with the coroutines code after that, let me know
(that's mine to fix anyway).

[Bug bootstrap/89494] Bootstrap error when using GCC 4.2.1

[pkubaj at anongoth dot pl]

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

--- Comment #30 from Piotr Kubaj <pkubaj at anongoth dot pl> ---
With default flags:
during RTL pass: cprop_hardreg
In file included from
/wrkdirs/usr/ports/lang/gcc10-devel/work/gcc-10-20210327/libgcc/unwind-c.c:32:
/wrkdirs/usr/ports/lang/gcc10-devel/work/gcc-10-20210327/libgcc/unwind-pe.h: In
function 'base_of_encoded_value':
/wrkdirs/usr/ports/lang/gcc10-devel/work/gcc-10-20210327/libgcc/unwind-pe.h:121:1:
internal compiler error: Segmentation fault

With my hack that allows gcc9 to build:
during RTL pass: reload
In file included from
/wrkdirs/usr/ports/lang/gcc10-devel/work/gcc-10-20210327/libiberty/regex.c:639:
/wrkdirs/usr/ports/lang/gcc10-devel/work/gcc-10-20210327/libiberty/regex.c: In
function 'byte_regex_compile':
/wrkdirs/usr/ports/lang/gcc10-devel/work/gcc-10-20210327/libiberty/regex.c:4223:1:
internal compiler error: Segmentation fault
 4223 | } /* regex_compile */

The hack is:
CFLAGS_FOR_TARGET="-O0" CXXFLAGS_FOR_TARGET="-O0" BOOT_CFLAGS="-O0"
And the patch:
--- libgcc/config/rs6000/t-crtstuff.orig        2020-04-07 15:17:50 UTC
+++ libgcc/config/rs6000/t-crtstuff
@@ -3,4 +3,4 @@
 # Do not build crtend.o with -Os as that can result in references to
 # out-of-line register save/restore functions, which may be unresolved
 # as crtend.o is linked after libgcc.a.  See PR45053.
-CRTSTUFF_T_CFLAGS = -msdata=none -O2 -fno-asynchronous-unwind-tables
+CRTSTUFF_T_CFLAGS = -msdata=none -O0 -fno-asynchronous-unwind-tables

[Bug bootstrap/89494] Bootstrap error when using GCC 4.2.1

[iains at gcc dot gnu.org]

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

--- Comment #31 from Iain Sandoe <iains at gcc dot gnu.org> ---
what is the current situation with this 
 - what input are we waiting for?
 - is the problem now cleared for powerpc64-freebsd?

[Bug bootstrap/89494] Bootstrap error when using GCC 4.2.1

[pkubaj at anongoth dot pl]

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

--- Comment #32 from Piotr Kubaj <pkubaj at anongoth dot pl> ---
(In reply to Iain Sandoe from comment #31)
> what is the current situation with this 
>  - what input are we waiting for?
>  - is the problem now cleared for powerpc64-freebsd?
Probably not, but FreeBSD now uses ELFv2 and LLVM, GCC builds fine with LLVM
with one small patch:
Index: gcc/tree-vect-loop.cc
===================================================================
--- gcc/tree-vect-loop.cc       (revision 273856)
+++ gcc/tree-vect-loop.cc       (working copy)
@@ -55,6 +55,8 @@ along with GCC; see the file COPYING3.  If not see
 #include "vec-perm-indices.h"
 #include "tree-eh.h"

+#define vec_step vec_step_
+
 /* Loop Vectorization Pass.

    This pass tries to vectorize loops.


All the releases using GCC 4.2.1 are EOL now.

[Bug bootstrap/89494] Bootstrap error when using GCC 4.2.1

[pinskia at gcc dot gnu.org]

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

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

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

--- Comment #33 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Piotr Kubaj from comment #32)
> (In reply to Iain Sandoe from comment #31)
> > what is the current situation with this 
> >  - what input are we waiting for?
> >  - is the problem now cleared for powerpc64-freebsd?
> Probably not, but FreeBSD now uses ELFv2 and LLVM, GCC builds fine with LLVM
> with one small patch:

Filed as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114369 since I saw
someone else having the same issue too.

Otherwise closing as fixed.