[Bug bootstrap/114985] New: [15 regression] internal compiler error: in discriminator_fail during stage2

[Bug bootstrap/114985] New: [15 regression] internal compiler error: in discriminator_fail during stage2

[seurer at gcc dot gnu.org]

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

            Bug ID: 114985
           Summary: [15 regression] internal compiler error: in
                    discriminator_fail during stage2
           Product: gcc
           Version: 15.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: bootstrap
          Assignee: unassigned at gcc dot gnu.org
          Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

I am looking for the source but this is the failure:

/home/seurer/gcc/git/build/gcc-trunk-bootstrap/./prev-gcc/xg++
-B/home/seurer/gcc/git/build/gcc-trunk-bootstrap/./prev-gcc/
-B/home/seurer/gcc/git/install/gcc-trunk-bootstrap/powerpc64le-unknown-linux-gnu/bin/
-nostdinc++
-B/home/seurer/gcc/git/build/gcc-trunk-bootstrap/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs
-B/home/seurer/gcc/git/build/gcc-trunk-bootstrap/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs

-I/home/seurer/gcc/git/build/gcc-trunk-bootstrap/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu

-I/home/seurer/gcc/git/build/gcc-trunk-bootstrap/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/include
 -I/home/seurer/gcc/git/gcc-trunk-bootstrap/libstdc++-v3/libsupc++
-L/home/seurer/gcc/git/build/gcc-trunk-bootstrap/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/home/seurer/gcc/git/build/gcc-trunk-bootstrap/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
 -fno-PIE -c  -DIN_GCC_FRONTEND -g -O2 -fno-checking -gtoggle -DIN_GCC   
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute
-Wconditionally-supported -Woverloaded-virtual -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common 
-DHAVE_CONFIG_H -fno-PIE -I. -Ic -I/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc
-I/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/c
-I/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/../include 
-I/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/../libcpp/include
-I/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/../libcody
-I/home/seurer/gcc/git/build/gcc-trunk-bootstrap/./gmp
-I/home/seurer/gcc/git/gcc-trunk-bootstrap/gmp
-I/home/seurer/gcc/git/build/gcc-trunk-bootstrap/./mpfr/src
-I/home/seurer/gcc/git/gcc-trunk-bootstrap/mpfr/src
-I/home/seurer/gcc/git/gcc-trunk-bootstrap/mpc/src 
-I/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/../libdecnumber
-I/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/../libdecnumber/dpd
-I../libdecnumber
-I/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/../libbacktrace
-I/home/seurer/gcc/git/build/gcc-trunk-bootstrap/./isl/include
-I/home/seurer/gcc/git/gcc-trunk-bootstrap/isl/include  -o c/c-parser.o -MT
c/c-parser.o -MMD -MP -MF c/.deps/c-parser.TPo
/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/c/c-parser.cc
DISCRIMINATOR FAIL.  Dispatch ====> RO_PPP <====
during IPA pass: inline
In file included from
/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/c/c-parser.cc:26971:
./gt-c-c-parser.h:94:2: internal compiler error: in discriminator_fail, at
range-op.cc:204
   94 | };
      |  ^
0x11993d23 range_op_handler::discriminator_fail(vrange const&, vrange const&,
vrange const&) const
        /home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/range-op.cc:204
0x11993fff range_op_handler::fold_range(vrange&, tree_node*, vrange const&,
vrange const&, relation_trio) const
        /home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/range-op.cc:228
0x13198197 ipa_value_range_from_jfunc(vrange&, ipa_node_params*, cgraph_edge*,
ipa_jump_func*, tree_node*)
        /home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/ipa-cp.cc:1743
0x116214e3 evaluate_properties_for_edge(cgraph_edge*, bool, unsigned int*,
unsigned int*, ipa_auto_call_arg_values*, bool)
        /home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/ipa-fnsummary.cc:680
0x116567d3 do_estimate_edge_size(cgraph_edge*)
        /home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/ipa-inline-analysis.cc:337
0x11657ab7 estimate_edge_size(cgraph_edge*)
        /home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/ipa-inline.h:79
0x11657ba3 estimate_edge_growth(cgraph_edge*)
        /home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/ipa-inline.h:100
0x11656d0b do_estimate_growth_1
        /home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/ipa-inline-analysis.cc:436
0x11176bcf cgraph_node::call_for_symbol_and_aliases(bool (*)(cgraph_node*,
void*), void*, bool)
        /home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/cgraph.h:3429
0x11656fbb estimate_growth(cgraph_node*)
        /home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/ipa-inline-analysis.cc:474
0x131cb18f inline_small_functions
        /home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/ipa-inline.cc:2081
0x131ce89b ipa_inline
        /home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/ipa-inline.cc:2850
0x131cfc6b execute
        /home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/ipa-inline.cc:3248

[Bug bootstrap/114985] [15 regression] internal compiler error: in discriminator_fail during stage2

[seurer at gcc dot gnu.org]

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

seurer at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Build|                            |powerpc64-linux-gnu,
                   |                            |powerpc64le-linux-gnu
             Target|                            |powerpc64-linux-gnu,
                   |                            |powerpc64le-linux-gnu
                 CC|                            |aldyh at gcc dot gnu.org,
                   |                            |bergner at gcc dot gnu.org
               Host|                            |powerpc64-linux-gnu,
                   |                            |powerpc64le-linux-gnu

--- Comment #1 from seurer at gcc dot gnu.org ---
Looks like this is the culprit:

commit 36e877996936abd8bd08f8b1d983c8d1023a5842 (HEAD)
Author: Aldy Hernandez <aldyh@redhat.com>
Date:   Tue May 7 14:05:50 2024 +0200

    Enable prange support.

[Bug bootstrap/114985] [15 regression] internal compiler error: in discriminator_fail during stage2

[aldyh at gcc dot gnu.org]

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

--- Comment #2 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
Yeah, that's mine.

Can you attach a preprocessed file of the offending file?

[Bug bootstrap/114985] [15 regression] internal compiler error: in discriminator_fail during stage2

[seurer at gcc dot gnu.org]

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

--- Comment #3 from seurer at gcc dot gnu.org ---
Created attachment 58129
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58129&action=edit
pre-processed failing file

[Bug bootstrap/114985] [15 regression] internal compiler error: in discriminator_fail during stage2

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez <aldyh at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2024-05-08
             Status|UNCONFIRMED                 |NEW
                 CC|                            |amacleod at redhat dot com,
                   |                            |hubicka at gcc dot gnu.org,
                   |                            |jamborm at gcc dot gnu.org

--- Comment #4 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
Confirmed.

Here is some background on tracking discriminator failures.

The sanity check in the range_op dispatch code has noticed that it has an
unsupported pointer range combination.  This is the sanity check:

bool
range_op_handler::fold_range (vrange &r, tree type,
                              const vrange &lh,
                              const vrange &rh,
                              relation_trio rel) const
...
...
  if (has_pointer_operand_p (r, lh, rh)
      && !m_operator->pointers_handled_p (DISPATCH_FOLD_RANGE,
                                          dispatch_kind (r, lh, rh)))
    discriminator_fail (r, lh, rh);

The above code fails if the operator cannot handle the pointer combo it was
passed, and the operator at hand is op_equal:

(gdb) p *this
$11 = {m_operator = 0x1463a590 <op_equal>}

What's being attempted is a <POINTER> = <POINTER> == <POINTER> as per the
somewhat cryptic error:

DISCRIMINATOR FAIL.  Dispatch ====> RO_PPP <====

This is because for operator_equal::fold_range(), we only handle INTEGER =
POINTER OP_EQUAL POINTER.  That is, the result must be an integer:

bool
operator_equal::pointers_handled_p (range_op_dispatch_type type,
                                    unsigned dispatch) const
{
  switch (type)
    {
    case DISPATCH_FOLD_RANGE:
      return dispatch == RO_IPP;
...
...
}


This all comes from ipa_value_range_from_jfunc() which is trying to calculate
the equality of two pointer ranges and store the result in a pointer.  I
believe this is incorrect, as the result of equality should be a
boolean_type_node, or at least an integer.

This is where IPA is trying to call fold_range with the invalid combo:

         Value_Range op_res (vr_type);
          Value_Range res (vr_type);
          tree op = ipa_get_jf_pass_through_operand (jfunc);
          Value_Range op_vr (TREE_TYPE (op));
          range_op_handler handler (operation);

          ipa_range_set_and_normalize (op_vr, op);

          if (!handler
              || !op_res.supports_type_p (vr_type)
=>            || !handler.fold_range (op_res, vr_type, srcvr, op_vr))
            op_res.set_varying (vr_type);


It is trying to call fold_range() with EQ_EXPR for two pointer operands, but
storing the result in a pointer:

(gdb) p operation
$18 = EQ_EXPR
(gdb) p debug(srcvr)
[prange] union tree_node * * [0, +INF] MASK 0xfffffffffffffff8 VALUE 0x0
$14 = void
(gdb) p debug(op_vr)
[prange] union tree_node * * [0, 0] MASK 0x0 VALUE 0x0
$15 = void

IMO op_res should have an integer type, but it is a pointer:

(gdb) p debug_generic_stmt(vr_type)
union tree_node * *

...causing op_res to be a pointer:

(gdb) p debug(op_res)
[prange] UNDEFINED

If <POINTER> = <POINTER> OP_EQUAL <POINTER> is valid gimple, then we should
change operator_equal::fold_range() to accept all pointer operands.  If not,
then we need to change the IPA pass.

I would appreciate if an IL expert could opine here.

[Bug ipa/114985] [15 regression] internal compiler error: in discriminator_fail during stage2

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |15.0
           Keywords|                            |needs-reduction
                 CC|                            |pinskia at gcc dot gnu.org
          Component|bootstrap                   |ipa

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Aldy Hernandez from comment #4)
> 
> If <POINTER> = <POINTER> OP_EQUAL <POINTER> is valid gimple, then we should
> change operator_equal::fold_range() to accept all pointer operands.  If not,
> then we need to change the IPA pass.
> 
> I would appreciate if an IL expert could opine here.

`POINTER = POINTER CMP POINTER` should be invalid gimple as far as I can tell.
The result of CMP should be a boolean type (except for vector compares where it
is a vector boolean type). We have ran into these issues before with pointer
types even.

I might get some time later today to reduce the testcase too.

[Bug ipa/114985] [15 regression] internal compiler error: in discriminator_fail during stage2

[aldyh at gcc dot gnu.org]

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

--- Comment #6 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
I wonder if something like this would work.

diff --git a/gcc/ipa-cp.cc b/gcc/ipa-cp.cc
index 5781f50..ea8a685 100644
--- a/gcc/ipa-cp.cc
+++ b/gcc/ipa-cp.cc
@@ -1730,6 +1730,8 @@ ipa_value_range_from_jfunc (vrange &vr,
        }
       else
        {
+         if (TREE_CODE_CLASS (operation) == tcc_comparison)
+           vr_type = boolean_type_node;
          Value_Range op_res (vr_type);
          Value_Range res (vr_type);
          tree op = ipa_get_jf_pass_through_operand (jfunc);

[Bug ipa/114985] [15 regression] internal compiler error: in discriminator_fail during stage2

[seurer at gcc dot gnu.org]

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

--- Comment #7 from seurer at gcc dot gnu.org ---
I tried that and with it trunk did finish building.  I am running a test of
that now.

[Bug ipa/114985] [15 regression] internal compiler error: in discriminator_fail during stage2

[seurer at gcc dot gnu.org]

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

--- Comment #8 from seurer at gcc dot gnu.org ---
tests ran OK too.

[Bug ipa/114985] [15 regression] internal compiler error: in discriminator_fail during stage2

[dje at gcc dot gnu.org]

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

--- Comment #9 from David Edelsohn <dje at gcc dot gnu.org> ---
The patch in comment 6 succeeds for me, but it seems more of a heavy-handed
band-aid that confirms the symptom, but covers up the problem.

Something in GCC apparently has generated invalid IR that was not caught
earlier.  GCC should not generate

POINTER = POINTER CMP POINTER

But the trunk should not be left in a broken state as per GCC development
policy.  The broken trunk interferes with the work of other developers and may
mask other broken patches being committed.

This patch should be reverted until the source of the problem is discovered and
fixed.

[Bug ipa/114985] [15 regression] internal compiler error: in discriminator_fail during stage2

[aldyh at gcc dot gnu.org]

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

--- Comment #10 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to David Edelsohn from comment #9)
> The patch in comment 6 succeeds for me, but it seems more of a heavy-handed
> band-aid that confirms the symptom, but covers up the problem.
> 
> Something in GCC apparently has generated invalid IR that was not caught
> earlier.  GCC should not generate
> 
> POINTER = POINTER CMP POINTER
> 
> But the trunk should not be left in a broken state as per GCC development
> policy.  The broken trunk interferes with the work of other developers and
> may mask other broken patches being committed.
> 
> This patch should be reverted until the source of the problem is discovered
> and fixed.

The range request is not necessarily coming from the IR, but it is a request
that the IPA pass is making of the ranger, which does adhere by gimple IR
rules.  So this may not be bad IR, but just a quirk of how IPA makes requests
of the ranger.  As such, I don't think it's heavy handed, but we do need the
IPA experts to opine.

[Bug ipa/114985] [15 regression] internal compiler error: in discriminator_fail during stage2

[aldyh at gcc dot gnu.org]

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

--- Comment #11 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
I have reverted the prange enabling patch until the IPA pass is fixed.

[Bug ipa/114985] [15 regression] internal compiler error: in discriminator_fail during stage2

[aldyh at gcc dot gnu.org]

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

--- Comment #12 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
Created attachment 58168
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58168&action=edit
proposed patch in testing

[Bug ipa/114985] [15 regression] internal compiler error: in discriminator_fail during stage2

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #13 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #12 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
> Created attachment 58168
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58168&action=edit
> proposed patch in testing

I just tried bootstrapping on sparc-sun-solaris2.11 with this patch and

commit 36e877996936abd8bd08f8b1d983c8d1023a5842
Author: Aldy Hernandez <aldyh@redhat.com>
Date:   Tue May 7 14:05:50 2024 +0200

    Enable prange support.

reapplied.

It ICEs in stage 2:

Unsupported operand combination in dispatch: RO_PII
during IPA pass: inline
In file included from /vol/gcc/src/hg/master/solaris/gcc/c/c-parser.cc:26971:
./gt-c-c-parser.h:94:2: internal compiler error: in discriminator_fail, at
range-op.cc:205
   94 | };
      |  ^
0x218a05b range_op_handler::discriminator_fail(vrange const&, vrange const&,
vrange const&) const
        /vol/gcc/src/hg/master/solaris/gcc/range-op.cc:205
0x218a313 range_op_handler::fold_range(vrange&, tree_node*, vrange const&,
vrange const&, relation_trio) const
        /vol/gcc/src/hg/master/solaris/gcc/range-op.cc:229
0x3569d2f ipa_vr_operation_and_type_effects
        /vol/gcc/src/hg/master/solaris/gcc/ipa-cp.cc:1663
0x356a337 ipa_value_range_from_jfunc(vrange&, ipa_node_params*, cgraph_edge*,
ipa_jump_func*, tree_node*)
        /vol/gcc/src/hg/master/solaris/gcc/ipa-cp.cc:1759
0x1e1cbef evaluate_properties_for_edge(cgraph_edge*, bool, unsigned int*,
unsigned int*, ipa_auto_call_arg_values*, bool)
        /vol/gcc/src/hg/master/solaris/gcc/ipa-fnsummary.cc:684
0x1e4ea47 do_estimate_edge_size(cgraph_edge*)
        /vol/gcc/src/hg/master/solaris/gcc/ipa-inline-analysis.cc:337
0x1e4fcff estimate_edge_size(cgraph_edge*)
        /vol/gcc/src/hg/master/solaris/gcc/ipa-inline.h:79
0x1e4fdbb estimate_edge_growth(cgraph_edge*)
        /vol/gcc/src/hg/master/solaris/gcc/ipa-inline.h:100
0x1e4f033 do_estimate_growth_1
        /vol/gcc/src/hg/master/solaris/gcc/ipa-inline-analysis.cc:436
0x1971d87 cgraph_node::call_for_symbol_and_aliases(bool (*)(cgraph_node*,
void*), void*, bool)
        /vol/gcc/src/hg/master/solaris/gcc/cgraph.h:3429
0x1e4f2a7 estimate_growth(cgraph_node*)
        /vol/gcc/src/hg/master/solaris/gcc/ipa-inline-analysis.cc:474
0x359d46f inline_small_functions
        /vol/gcc/src/hg/master/solaris/gcc/ipa-inline.cc:2081
0x35a1083 ipa_inline
        /vol/gcc/src/hg/master/solaris/gcc/ipa-inline.cc:2850
0x35a24b3 execute
        /vol/gcc/src/hg/master/solaris/gcc/ipa-inline.cc:3248

[Bug ipa/114985] [15 regression] internal compiler error: in discriminator_fail during stage2

[hubicka at gcc dot gnu.org]

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

--- Comment #14 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
So this is problem in ipa_value_range_from_jfunc?
It is Maritn's code, I hope he will know why types are wrong here.
Once can get type compatibility problem on mismatched declarations and LTO, but
it seems that this testcase is single-file. So indeed this looks like a bug
either in jump function construction or even earlier...

[Bug ipa/114985] [15 regression] internal compiler error: in discriminator_fail during stage2

[segher at gcc dot gnu.org]

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

--- Comment #15 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to Aldy Hernandez from comment #11)
> I have reverted the prange enabling patch until the IPA pass is fixed.

Thank you!

[Bug ipa/114985] [15 regression] internal compiler error: in discriminator_fail during stage2

[jamborm at gcc dot gnu.org]

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

--- Comment #16 from Martin Jambor <jamborm at gcc dot gnu.org> ---
I'll have look, hopefully on Monday.

[Bug ipa/114985] [15 regression] internal compiler error: in discriminator_fail during stage2

[aldyh at gcc dot gnu.org]

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

--- Comment #17 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Martin Jambor from comment #16)
> I'll have look, hopefully on Monday.

Thanks Martin.

To reproduce the problem:

1. Revert this patch:

commit d7bb8eaade3cd3aa70715c8567b4d7b08098e699 (master, clean)
Author: Aldy Hernandez <aldyh@redhat.com>
Date:   Fri May 10 00:29:13 2024 +0200

    Revert: "Enable prange support." [PR114985]

2. Trap on pointer mismatches:

diff --git a/gcc/range-op.cc b/gcc/range-op.cc
index 000ec802e66..c14b72c19de 100644
--- a/gcc/range-op.cc
+++ b/gcc/range-op.cc
@@ -52,7 +52,7 @@ along with GCC; see the file COPYING3.  If not see
 // Set to 1 to trap on range-op entries that cannot handle the pointer
 // combination being requested.  This is a temporary sanity check to
 // aid in debugging, and will be removed later in the release cycle.
-#define TRAP_ON_UNHANDLED_POINTER_OPERATORS 0
+#define TRAP_ON_UNHANDLED_POINTER_OPERATORS 1

 // Instantiate the operators which apply to multiple types here.

I will also attach a preprocessed file to reproduce the problem on ppc64le that
can save you some time.

[Bug ipa/114985] [15 regression] internal compiler error: in discriminator_fail during stage2

[aldyh at gcc dot gnu.org]

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

--- Comment #18 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
Ah, it looks like seurer already beat me to the preprocessed source.

[Bug ipa/114985] [15 regression] internal compiler error: in discriminator_fail during stage2

[jamborm at gcc dot gnu.org]

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

--- Comment #19 from Martin Jambor <jamborm at gcc dot gnu.org> ---
The following minimized testcase ICEs with r15-312-g36e877996936ab
cross-compiler to ppc64le with -O2 nicely:


void omp_clause_elt_check(int *, const char *, const char *);
enum { C_OMP_CLAUSE_SPLIT_COUNT };
enum c_omp_region_type { C_ORT_OMP };
void c_finish_omp_clauses(int *, c_omp_region_type);
int *c_parser_omp_all_clauses_prev;
int *c_parser_omp_all_clauses(bool finish_p) {
  if (finish_p)
    c_finish_omp_clauses(c_parser_omp_all_clauses_prev, C_ORT_OMP);
  return c_parser_omp_all_clauses_prev;
}
int c_parser_omp_teams___trans_tmp_104;
static void c_parser_omp_teams(int **cclauses) {
  c_parser_omp_all_clauses(cclauses);
  omp_clause_elt_check(&c_parser_omp_teams___trans_tmp_104, "", __FUNCTION__);
}
void c_parser_omp_target() {
  int *cclauses[C_OMP_CLAUSE_SPLIT_COUNT];
  c_parser_omp_teams(cclauses);
}

[Bug ipa/114985] [15 regression] internal compiler error: in discriminator_fail during stage2

[jamborm at gcc dot gnu.org]

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

--- Comment #20 from Martin Jambor <jamborm at gcc dot gnu.org> ---
The IL we generate the jump function from is:
  <bb 2>
  _1 = cclauses_2(D) != 0B;
  c_parser_omp_all_clauses (_1);

Which translates to the expected jump function:
  callsite  void c_parser_omp_teams(int**)/3 -> int*
c_parser_omp_all_clauses(bool)/1 :
     param 0: PASS THROUGH: 0, op ne_expr 0B

so IPA looks like it's doing what it should.

(In reply to Aldy Hernandez from comment #6)
> I wonder if something like this would work.
> 
> diff --git a/gcc/ipa-cp.cc b/gcc/ipa-cp.cc
> index 5781f50..ea8a685 100644
> --- a/gcc/ipa-cp.cc
> +++ b/gcc/ipa-cp.cc
> @@ -1730,6 +1730,8 @@ ipa_value_range_from_jfunc (vrange &vr,
>         }
>        else
>         {
> +         if (TREE_CODE_CLASS (operation) == tcc_comparison)
> +           vr_type = boolean_type_node;
>           Value_Range op_res (vr_type);
>           Value_Range res (vr_type);
>           tree op = ipa_get_jf_pass_through_operand (jfunc);

This looks OKish and we also do a similar thing in
ipa_get_jf_arith_result.

Also note that the ipa_value_range_from_jfunc already has a parameter
that tells it what type the result should be.  It is called parm_type,
which is boolean_type in the case that ICEs.  So we can even bail out
if we really encounter jump function created from bad IL.

I was thinking of using use parm_type from the beginning, to
initialize op_res with it, but there are jump functions representing
an operation followed by a truncation, for example for:

  _2 = complain_6(D) & 1;
  _3 = (int) std_alignof_7(D);
  cxx_sizeof_or_alignof_type (_3, _2);

where _r is in fact bool (has smaller size and precision) and trying
to make ranger do the bit_and_expr directly to bool leads to a failed
assert in fold_range (the test of m_operator->operand_check_p).

So doing the operation in the original type - unless it is a
comparison - and then using ipa_vr_operation_and_type_effects seems to
be the right thing to do.

But I am really curious why propagate_vr_across_jump_function does not
need the same check for tcc_comparison operators and generally why is
it so different (in the non-scc case)?  Why is ipa_supports_p (this
predicate has a really really really bad name BTW and I am completely
at loss as to what it does and how or why) used there and not in
ipa_value_range_from_jfunc?

(I also cannot prevent myself from ranting a little that it would
really help if all the ranger (helper) classes and functions were
better documented.)

[Bug ipa/114985] [15 regression] internal compiler error: in discriminator_fail during stage2

[amacleod at redhat dot com]

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

--- Comment #21 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to Martin Jambor from comment #20)

> (I also cannot prevent myself from ranting a little that it would
> really help if all the ranger (helper) classes and functions were
> better documented.)

I am working on that this year.  Its one of my major tasks.   internals, APIs,
reusable components..  an entire encyclopedia.   first bits are coming shortly.

[Bug ipa/114985] [15 regression] internal compiler error: in discriminator_fail during stage2

[aldyh at gcc dot gnu.org]

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

--- Comment #22 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Martin Jambor from comment #20)

Thanks for looking into this.

> The IL we generate the jump function from is:
>   <bb 2>
>   _1 = cclauses_2(D) != 0B;
>   c_parser_omp_all_clauses (_1);
> 
> Which translates to the expected jump function:
>   callsite  void c_parser_omp_teams(int**)/3 -> int*
> c_parser_omp_all_clauses(bool)/1 :
>      param 0: PASS THROUGH: 0, op ne_expr 0B
> 
> so IPA looks like it's doing what it should.

So, is it bad IL?  If so, do you know what created it?

> 
> (In reply to Aldy Hernandez from comment #6)
> > I wonder if something like this would work.
> > 
> > diff --git a/gcc/ipa-cp.cc b/gcc/ipa-cp.cc
> > index 5781f50..ea8a685 100644
> > --- a/gcc/ipa-cp.cc
> > +++ b/gcc/ipa-cp.cc
> > @@ -1730,6 +1730,8 @@ ipa_value_range_from_jfunc (vrange &vr,
> >         }
> >        else
> >         {
> > +         if (TREE_CODE_CLASS (operation) == tcc_comparison)
> > +           vr_type = boolean_type_node;
> >           Value_Range op_res (vr_type);
> >           Value_Range res (vr_type);
> >           tree op = ipa_get_jf_pass_through_operand (jfunc);
> 
> This looks OKish and we also do a similar thing in
> ipa_get_jf_arith_result.
> 
> Also note that the ipa_value_range_from_jfunc already has a parameter
> that tells it what type the result should be.  It is called parm_type,
> which is boolean_type in the case that ICEs.  So we can even bail out
> if we really encounter jump function created from bad IL.
> 
> I was thinking of using use parm_type from the beginning, to
> initialize op_res with it, but there are jump functions representing
> an operation followed by a truncation, for example for:
> 
>   _2 = complain_6(D) & 1;
>   _3 = (int) std_alignof_7(D);
>   cxx_sizeof_or_alignof_type (_3, _2);
> 
> where _r is in fact bool (has smaller size and precision) and trying
> to make ranger do the bit_and_expr directly to bool leads to a failed
> assert in fold_range (the test of m_operator->operand_check_p).

ranger should accept any combination the IL does.  What we try to diagnose with
the operand_check_p's is combinations that would also be incorrect in the IL.

> 
> So doing the operation in the original type - unless it is a
> comparison - and then using ipa_vr_operation_and_type_effects seems to
> be the right thing to do.
> 
> But I am really curious why propagate_vr_across_jump_function does not
> need the same check for tcc_comparison operators and generally why is

In my local tree I have mods to both ipa_value_range_from_jfunc and
propagate_vr_across_jump_function, because I found a failing testcase that
needed it.  So you probably need to tweak both places.

> it so different (in the non-scc case)?  Why is ipa_supports_p (this
> predicate has a really really really bad name BTW and I am completely
> at loss as to what it does and how or why) used there and not in
> ipa_value_range_from_jfunc?

Feel free to change it to whatever you prefer.  I was just trying to avoid
adding "&& prange::supports_type_p()" in a bunch of places.  Although what we
probably want is to verify that the types match with operands_check_p as you do
in ipa_vr_operation_and_type_effects():

  return (handler.operand_check_p (dst_type, src_type, dst_type)
          && handler.fold_range (dst_vr, dst_type, src_vr, varying)
          && !dst_vr.varying_p ()
          && !dst_vr.undefined_p ());

My apologies if I have dirtied ipa-* somewhat.  To be honest, I would much
rather not have to touch the code, as I'm not very familiar with it.  Feel free
to fix it however way you feel is best.  I'll be happy to provide feedback as
needed.

> 
> (I also cannot prevent myself from ranting a little that it would
> really help if all the ranger (helper) classes and functions were
> better documented.)

Andrew has been in documentation and clean-up mode for a few months now, and
should be able to push something out soon.

[Bug ipa/114985] [15 regression] internal compiler error: in discriminator_fail during stage2

[cvs-commit at gcc dot gnu.org]

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

--- Comment #23 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Aldy Hernandez <aldyh@gcc.gnu.org>:

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

commit r15-573-gf6bed6d3fcc13880ffa786b6c616e2306efe2bf3
Author: Aldy Hernandez <aldyh@redhat.com>
Date:   Thu May 16 09:22:55 2024 +0200

    Use a boolean type when folding conditionals in simplify_using_ranges.

    In adding some traps for PR114985 I noticed that the conditional
    folding code in simplify_using_ranges was using the wrong type.  This
    cleans up the oversight.

    gcc/ChangeLog:

            PR tree-optimization/114985
            * vr-values.cc (simplify_using_ranges::fold_cond_with_ops): Use
            boolean type when folding conditionals.

[Bug ipa/114985] [15 regression] internal compiler error: in discriminator_fail during stage2

[cvs-commit at gcc dot gnu.org]

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

--- Comment #24 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Aldy Hernandez <aldyh@gcc.gnu.org>:

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

commit r15-574-gb8e3574e68310f68116f157a35d5650600d13718
Author: Aldy Hernandez <aldyh@redhat.com>
Date:   Thu May 16 09:47:56 2024 +0200

    Cleanup prange sanity checks.

    The pointers_handled_p() code was a temporary sanity check, and not
    even a good one, since we have a cleaner way of checking type
    mismatches with operand_check_p.  This patch removes all the code, and
    adds an explicit type check for relational operators, which are the
    main problem in PR114985.

    Adding this check makes it clear where the type mismatch is happening
    in IPA, even without prange.  I've added code to skip the range
    folding if the types don't match what the operator expects.  In order
    to reproduce the latent bug, just remove the operand_check_p calls.

    Tested on x86-64 and ppc64le with and without prange support.

    gcc/ChangeLog:

            PR tree-optimization/114985
            * gimple-range-op.cc: Remove pointers_handled_p.
            * ipa-cp.cc (ipa_value_range_from_jfunc): Skip range folding if
            operands don't match.
            (propagate_vr_across_jump_function): Same.
            * range-op-mixed.h: Remove pointers_handled_p and tweak
            operand_check_p.
            * range-op-ptr.cc (range_operator::pointers_handled_p): Remove.
            (pointer_plus_operator::pointers_handled_p): Remove.
            (class operator_pointer_diff): Remove pointers_handled_p.
            (operator_pointer_diff::pointers_handled_p): Remove.
            (operator_identity::pointers_handled_p): Remove.
            (operator_cst::pointers_handled_p): Remove.
            (operator_cast::pointers_handled_p): Remove.
            (operator_min::pointers_handled_p): Remove.
            (operator_max::pointers_handled_p): Remove.
            (operator_addr_expr::pointers_handled_p): Remove.
            (operator_bitwise_and::pointers_handled_p): Remove.
            (operator_bitwise_or::pointers_handled_p): Remove.
            (operator_equal::pointers_handled_p): Remove.
            (operator_not_equal::pointers_handled_p): Remove.
            (operator_lt::pointers_handled_p): Remove.
            (operator_le::pointers_handled_p): Remove.
            (operator_gt::pointers_handled_p): Remove.
            (operator_ge::pointers_handled_p): Remove.
            * range-op.cc (TRAP_ON_UNHANDLED_POINTER_OPERATORS): Remove.
            (range_op_handler::lhs_op1_relation): Remove pointers_handled_p
checks.
            (range_op_handler::lhs_op2_relation): Same.
            (range_op_handler::op1_op2_relation): Same.
            * range-op.h: Remove RO_* declarations.

[Bug ipa/114985] [15 regression] internal compiler error: in discriminator_fail during stage2

[aldyh at gcc dot gnu.org]

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

--- Comment #25 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
prange has been enabled again, after testing on x86-64 and ppc64le linux. 
Aarch has no space to run tests on the compile farm, and sparc bootstrap was
already broken.

The problem in this PR can be triggered by commenting the two new
operand_check_p conditionals:

diff --git a/gcc/ipa-cp.cc b/gcc/ipa-cp.cc
index 09cab761822..76548f31853 100644
--- a/gcc/ipa-cp.cc
+++ b/gcc/ipa-cp.cc
@@ -1744,7 +1744,7 @@ ipa_value_range_from_jfunc (vrange &vr,
                 pointer type to hold the result instead of a boolean
                 type.  Avoid trapping in the sanity check in
                 fold_range until this is fixed.  */
-             || !handler.operand_check_p (vr_type, srcvr.type (), op_vr.type
())
+             /*|| !handler.operand_check_p (vr_type, srcvr.type (), op_vr.type
())*/
              || !handler.fold_range (op_res, vr_type, srcvr, op_vr))
            op_res.set_varying (vr_type);

@@ -2556,9 +2556,11 @@ propagate_vr_across_jump_function (cgraph_edge *cs,
ipa_jump_func *jfunc,
                 pointer type to hold the result instead of a boolean
                 type.  Avoid trapping in the sanity check in
                 fold_range until this is fixed.  */
+             /*
              || !handler.operand_check_p (operand_type,
                                           src_lats->m_value_range.m_vr.type
(),
                                           op_vr.type ())
+             */
              || !handler.fold_range (op_res, operand_type,
                                      src_lats->m_value_range.m_vr, op_vr))
            op_res.set_varying (param_type);

You can reproduce on x86-64 as well as ppc64le, and the problem can be seen
with and without prange support enabled.

[Bug ipa/114985] [15 regression] internal compiler error: in discriminator_fail during stage2

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #26 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #25 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
> prange has been enabled again, after testing on x86-64 and ppc64le linux. 
> Aarch has no space to run tests on the compile farm, and sparc bootstrap was
> already broken.

Huh?  Current trunk bootstraps just fine on Solaris/SPARC without any
patches.  What issue do you see?

Besides, there *is* a Solaris/SPARC system in the cfarm (cfarm216), so
you can try for yourself.

[Bug ipa/114985] [15 regression] internal compiler error: in discriminator_fail during stage2

[aldyh at gcc dot gnu.org]

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

--- Comment #27 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #26)
> > --- Comment #25 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
> > prange has been enabled again, after testing on x86-64 and ppc64le linux. 
> > Aarch has no space to run tests on the compile farm, and sparc bootstrap was
> > already broken.
> 
> Huh?  Current trunk bootstraps just fine on Solaris/SPARC without any
> patches.  What issue do you see?
> 
> Besides, there *is* a Solaris/SPARC system in the cfarm (cfarm216), so
> you can try for yourself.

commit 5609d77e683944439fae38323ecabc44a1eb4671 (HEAD -> clean)
Author: Christoph Müllner <christoph.muellner@vrull.eu>
Date:   Wed May 15 01:34:54 2024 +0200

    RISC-V: Test cbo.zero expansion for rv32

    We had an issue when expanding via cmo-zero for RV32.
    This was fixed upstream, but we don't have a RV32 test.
    Therefore, this patch introduces such a test.

    gcc/testsuite/ChangeLog:

            * gcc.target/riscv/cmo-zicboz-zic64-1.c: Fix for rv32.

    Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>


This is in cfarm216.cfarm.et:

aldyh@s11-sparc:~/bld/clean$ hostname
s11-sparc.cfarm
aldyh@s11-sparc:~/bld/clean$ uname -a
SunOS s11-sparc.cfarm 5.11 11.4.68.164.2 sun4v sparc sun4v logical-domain
aldyh@s11-sparc:~/bld/clean$ ~/src/clean/configure && gmake -j80 && gmake check
-k -j80
...
...
gmake[2]: Entering directory '/home/aldyh/bld/clean'
gmake[3]: Entering directory '/home/aldyh/bld/clean'
rm -f stage_current
gmake[3]: Leaving directory '/home/aldyh/bld/clean'
Comparing stages 2 and 3
Bootstrap comparison failure!
gcc/tree-vect-stmts.o differs
gmake[2]: *** [Makefile:26649: compare] Error 1
gmake[2]: Leaving directory '/home/aldyh/bld/clean'
gmake[1]: *** [Makefile:26629: stage3-bubble] Error 2
gmake[1]: Leaving directory '/home/aldyh/bld/clean'
gmake: *** [Makefile:1099: all] Error 2
aldyh@s11-sparc:~/bld/clean$

[Bug ipa/114985] [15 regression] internal compiler error: in discriminator_fail during stage2

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #28 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #27 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
> This is in cfarm216.cfarm.et:
>
> aldyh@s11-sparc:~/bld/clean$ hostname
> s11-sparc.cfarm
> aldyh@s11-sparc:~/bld/clean$ uname -a
> SunOS s11-sparc.cfarm 5.11 11.4.68.164.2 sun4v sparc sun4v logical-domain
> aldyh@s11-sparc:~/bld/clean$ ~/src/clean/configure && gmake -j80 && gmake check
> -k -j80

You need to be careful that the assembler and linker actually used match
gcc's idea thereof: 

        https://gcc.gnu.org/install/specific.html#x-x-solaris2

Best specify all of --build sparcv9-sun-solaris2.11 (if you're
bootstrapping with a 64-bit-default gcc/g++) and

        --with-as=/usr/gnu/bin/as (or /opt/cfarm/binutils-latest-64/bin/as)
        --with-gnu-as

(/usr/bin/as works too, but you need to specify both the path and
--without-gnu-as)

        --with-ld=/usr/bin/ld
        --without-gnu-ld

Having two different assemblers and linkers (Solaris and GNU) available
can lead to confusion if you rely on PATH alone.

> gmake[3]: Leaving directory '/home/aldyh/bld/clean'
> Comparing stages 2 and 3
> Bootstrap comparison failure!
> gcc/tree-vect-stmts.o differs

I'm not seeing this myself.

[Bug ipa/114985] [15 regression] internal compiler error: in discriminator_fail during stage2

[aldyh at gcc dot gnu.org]

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

--- Comment #29 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #28)
> > --- Comment #27 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
> > This is in cfarm216.cfarm.et:
> >
> > aldyh@s11-sparc:~/bld/clean$ hostname
> > s11-sparc.cfarm
> > aldyh@s11-sparc:~/bld/clean$ uname -a
> > SunOS s11-sparc.cfarm 5.11 11.4.68.164.2 sun4v sparc sun4v logical-domain
> > aldyh@s11-sparc:~/bld/clean$ ~/src/clean/configure && gmake -j80 && gmake check
> > -k -j80
> 
> You need to be careful that the assembler and linker actually used match
> gcc's idea thereof: 
> 
> 	https://gcc.gnu.org/install/specific.html#x-x-solaris2
> 
> Best specify all of --build sparcv9-sun-solaris2.11 (if you're
> bootstrapping with a 64-bit-default gcc/g++) and
> 
> 	--with-as=/usr/gnu/bin/as (or /opt/cfarm/binutils-latest-64/bin/as)
> 	--with-gnu-as
> 
> (/usr/bin/as works too, but you need to specify both the path and
> --without-gnu-as)
> 
> 	--with-ld=/usr/bin/ld
> 	--without-gnu-ld
> 
> Having two different assemblers and linkers (Solaris and GNU) available
> can lead to confusion if you rely on PATH alone.

Ok, what's the minimum configuration I need to build here?

srcdir/configure --build=sparc-sun-solaris2.11

srcdir/configure --build=sparc-sun-solaris2.11 --without-gnu-as
--without-gnu-ld

??

I really don't care how it builds, I just want the bare minimum so I can
bootstrap and run tests.

A minor rant, but why can't all this be set up automatically in the compile
farm machines?  Keeping track of minor nuances of each architecture is
distracting.  They should all be set up, whether by setting default paths in
/etc/profile or whatever, or by having the relevant patches in GCC's source
base, such that they work with src/configure && make.

I know this isn't your fault, but if more cfarm boxes where set up to go with
no surprises, I'd add more boxen to my testing harness.

> 
> > gmake[3]: Leaving directory '/home/aldyh/bld/clean'
> > Comparing stages 2 and 3
> > Bootstrap comparison failure!
> > gcc/tree-vect-stmts.o differs
> 
> I'm not seeing this myself.

Dunno.  It could be the particular revision was broken??

[Bug ipa/114985] [15 regression] internal compiler error: in discriminator_fail during stage2

[aldyh at gcc dot gnu.org]

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

--- Comment #30 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Aldy Hernandez from comment #29)

> > > gmake[3]: Leaving directory '/home/aldyh/bld/clean'
> > > Comparing stages 2 and 3
> > > Bootstrap comparison failure!
> > > gcc/tree-vect-stmts.o differs
> > 
> > I'm not seeing this myself.
> 
> Dunno.  It could be the particular revision was broken??

Interestingly, I just did the following with latest trunk, and sparc
bootstrapped and is running tests:

configure && make -j128 && make check -j128 -k

No --with-something-rather or path tweaks or --build=blah.

*shrugs*

[Bug ipa/114985] [15 regression] internal compiler error: in discriminator_fail during stage2

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #31 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #29 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
[...]
> Ok, what's the minimum configuration I need to build here?
>
> srcdir/configure --build=sparc-sun-solaris2.11
>
> srcdir/configure --build=sparc-sun-solaris2.11 --without-gnu-as
> --without-gnu-ld
>
> ??

  srcdir/configure --build=sparcv9-sun-solaris2.11 --without-gnu-as
  --with-as=/usr/bin/as --without-gnu-ld --with-ld=/usr/bin/ld

should do the trick.

Preferably prepend /usr/gnu/bin to PATH.

> I really don't care how it builds, I just want the bare minimum so I can
> bootstrap and run tests.
>
> A minor rant, but why can't all this be set up automatically in the compile
> farm machines?  Keeping track of minor nuances of each architecture is
> distracting.  They should all be set up, whether by setting default paths in

Agreed, but you always run into stuff like this when leaving Linux (like
AIX, HP-UX, or macOS).  PATHs won't help much for reasons explained in
install.texi.

> /etc/profile or whatever, or by having the relevant patches in GCC's source
> base, such that they work with src/configure && make.

But what should be the default: GNU or native tools?  You have choices
here and need to decide what you need/want.  No one can do this for you.

> I know this isn't your fault, but if more cfarm boxes where set up to go with
> no surprises, I'd add more boxen to my testing harness.

Well, I *did* set up the Solaris cfarm systems, actually ;-)  I see your
point, but things are not that simple unfortunately.  And GCC's
configure doesn't need to cater to users of the cfarm only...

Some of the issues (like the need for --build) have been caused by
upstream (like the config.guess maintainers that refuse to listen to
reason ;-).  I thought about improving the --with-as/ld situation; maybe
something can be done there.

[Bug ipa/114985] [15 regression] internal compiler error: in discriminator_fail during stage2

[aldyh at gcc dot gnu.org]

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

--- Comment #32 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #31)
> > --- Comment #29 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
> [...]
> > Ok, what's the minimum configuration I need to build here?
> >
> > srcdir/configure --build=sparc-sun-solaris2.11
> >
> > srcdir/configure --build=sparc-sun-solaris2.11 --without-gnu-as
> > --without-gnu-ld
> >
> > ??
> 
>   srcdir/configure --build=sparcv9-sun-solaris2.11 --without-gnu-as
>   --with-as=/usr/bin/as --without-gnu-ld --with-ld=/usr/bin/ld

OK, I'll add this to my notes.  Thanks.

BTW, the above seems like it would be a perfect thing to put in /etc/motd :).

> 
> should do the trick.
> 
> Preferably prepend /usr/gnu/bin to PATH.
> 
> > I really don't care how it builds, I just want the bare minimum so I can
> > bootstrap and run tests.
> >
> > A minor rant, but why can't all this be set up automatically in the compile
> > farm machines?  Keeping track of minor nuances of each architecture is
> > distracting.  They should all be set up, whether by setting default paths in
> 
> Agreed, but you always run into stuff like this when leaving Linux (like
> AIX, HP-UX, or macOS).  PATHs won't help much for reasons explained in
> install.texi.
> 
> > /etc/profile or whatever, or by having the relevant patches in GCC's source
> > base, such that they work with src/configure && make.
> 
> But what should be the default: GNU or native tools?  You have choices
> here and need to decide what you need/want.  No one can do this for you.

My guess would be to use gnu tools if available, cause those would be
"guaranteed" to work correctly to build gcc?

> 
> > I know this isn't your fault, but if more cfarm boxes where set up to go with
> > no surprises, I'd add more boxen to my testing harness.
> 
> Well, I *did* set up the Solaris cfarm systems, actually ;-)  I see your
> point, but things are not that simple unfortunately.  And GCC's
> configure doesn't need to cater to users of the cfarm only...
> 
> Some of the issues (like the need for --build) have been caused by
> upstream (like the config.guess maintainers that refuse to listen to
> reason ;-).  I thought about improving the --with-as/ld situation; maybe
> something can be done there.

Thanks for the explanation.

[Bug ipa/114985] [15 regression] internal compiler error: in discriminator_fail during stage2

[segher at gcc dot gnu.org]

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

--- Comment #33 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to Aldy Hernandez from comment #29)
> A minor rant, but why can't all this be set up automatically in the compile
> farm machines?

We have everything installed with the default for whatever distor (or similar
for non-Linux) is used.  There are newer tools etc. in /opt/cfarm/ sometimes.

On https://gcc.gnu.org/install/ there are installation instructions, for
configuring and buiding GCC, generic as well as per-configuration stuff.  There
is nothing specific about the cfarm here.  There is some info about Solaris, in
the GCC documentation.

> Keeping track of minor nuances of each architecture is
> distracting.  They should all be set up, whether by setting default paths in
> /etc/profile or whatever, or by having the relevant patches in GCC's source
> base, such that they work with src/configure && make.

A lovely utopian worldview, if you subscribe to the "everything should always
be the same" worldview, anyway.