[Bug target/104117] New: gcc10 fails to build icu for ppc64 on 10.5.8 (direct access to a floating-point constant)

[Bug target/104117] New: gcc10 fails to build icu for ppc64 on 10.5.8 (direct access to a floating-point constant)

[vital.had at gmail dot com]

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

            Bug ID: 104117
           Summary: gcc10 fails to build icu for ppc64 on 10.5.8 (direct
                    access to a floating-point constant)
           Product: gcc
           Version: 10.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: vital.had at gmail dot com
                CC: iains at gcc dot gnu.org
  Target Milestone: ---
              Host: powerpc-apple-darwin9
            Target: powerpc-apple-darwin9
             Build: powerpc-apple-darwin9

Created attachment 52233
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52233&action=edit
ii file produced for the error

Error where the build fails:

ld: absolute addressing (perhaps -mdynamic-no-pic) used in
__ZN6icu_6712FixedDecimal8decimalsEd from plurrule.o not allowed in slidable
image. Use '-read_only_relocs suppress' to enable text relocs
collect2: error: ld returned 1 exit status
make[1]: *** [../lib/libicui18n.67.1.dylib] Error 1
make: *** [all-recursive] Error 2

Command producing the faulty object:

/opt/iains/powerpc-apple-darwin9/gcc-10-3-ppc/bin/g++ -m64 -O2
-DU_ATTRIBUTE_DEPRECATED= -DU_I18N_IMPLEMENTATION -DU_HAVE_STRTOD_L=1
-DU_HAVE_XLOCALE_H=1 -I. -I../common -O2 -W -Wall -pedantic -Wpointer-arith
-Wwrite-strings -Wno-long-long -std=c++11 -fvisibility=hidden -fno-common -c
-dynamic -MMD -MT "plurrule.d plurrule.o plurrule.ao" -o plurrule.o
plurrule.cpp

[Bug target/104117] gcc10 fails to build icu for ppc64 on 10.5.8 (direct access to a floating-point constant)

[iains at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
               Host|powerpc-apple-darwin9       |
   Target Milestone|---                         |10.4
           Keywords|                            |wrong-code
              Build|powerpc-apple-darwin9       |
   Last reconfirmed|                            |2022-01-19

--- Comment #1 from Iain Sandoe <iains at gcc dot gnu.org> ---
most likely present on earlier branches.

The problem is that we have 

double var = (double) 1;

LRA decides that loading a constant integer 1 into a FPR and then using
int->double is good.  However, it (a) decides to do this in the prologue
(before we have got a picbase set up) and (b) does not seem to be checking that
the target agrees that the addressing mode is legitimate (it is not).

----

NOTE: incidental changes on 11.x and master have hidden this (but the changes
were not a fix for this bug, so it has most likely simply become latent).

[Bug target/104117] gcc10 fails to build icu for ppc64 on 10.5.8 (direct access to a floating-point constant)

[iains at gcc dot gnu.org]

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

--- Comment #2 from Iain Sandoe <iains at gcc dot gnu.org> ---
reduced testcase:

typedef int int32_t;
extern "C" {
extern double floor( double );
extern double fabs( double );
int atoi(const char *);
int sprintf(char * , const char * , ...) ;

}

namespace icu_67 {

class __attribute__((visibility("default"))) FixedDecimal {
  public:
    static int32_t decimals(double n);
};

//using namespace icu::pluralimpl;
//using icu::number::impl::DecimalQuantity;

static int32_t p10[] = {1, 10, 100, 1000, 10000};

int32_t FixedDecimal::decimals(double n) {


    n = fabs(n);
    for (int ndigits=0; ndigits<=3; ndigits++) {
        double scaledN = n * p10[ndigits];
        if (scaledN == floor(scaledN)) {
            return ndigits;
        }
    }


    char buf[30] = {0};
    sprintf(buf, "%1.15e", n);

    int exponent = atoi(buf+18);
    int numFractionDigits = 15;
    for (int i=16; ; --i) {
        if (buf[i] != '0') {
            break;
        }
        --numFractionDigits;
    }
    numFractionDigits -= exponent;
    return numFractionDigits;
}

}

[Bug target/104117] gcc10 fails to build icu for ppc64 on 10.5.8 (direct access to a floating-point constant)

[vital.had at gmail dot com]

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

--- Comment #3 from Sergey Fedorov <vital.had at gmail dot com> ---
(In reply to Iain Sandoe from comment #1)
> most likely present on earlier branches.

Indeed, gcc7.5 likewise failed to build icu for ppc64.

[Bug target/104117] gcc10 fails to build icu for ppc64 on 10.5.8 (direct access to a floating-point constant)

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vmakarov at gcc dot gnu.org
           Keywords|                            |ra

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
I wonder if it's possible to create a simple RTL frontend testcase for this,
feeding into RA?

[Bug target/104117] gcc10 fails to build icu for ppc64 on 10.5.8 (direct access to a floating-point constant)

[iains at gcc dot gnu.org]

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

--- Comment #5 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #4)
> I wonder if it's possible to create a simple RTL frontend testcase for this,
> feeding into RA?

I hope so, because the C++ and C test cases are very fragile (other changes
make the problem go away).

I had a quick look yesterday and it seems that there might be a bug in the
target address legaliser in this case [it is being called].

(there is another extremely similar problem, where the legaliser is never
called, but I was jumping to conclusions that it was the same one too soon)

[Bug target/104117] gcc10 fails to build icu for ppc64 on 10.5.8 (direct access to a floating-point constant)

[iains at gcc dot gnu.org]

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

--- Comment #6 from Iain Sandoe <iains at gcc dot gnu.org> ---
.. not (In reply to Iain Sandoe from comment #5)
> (In reply to Richard Biener from comment #4)

not enough coffee before posting ...

[this problem comes into play when we use force_const_mem() on an operand, and
then process_address() on that - but disentangling what exactly is happening
will take some more time].

( I am not familiar with using the RTL FE so that is something that will also
take some time )

> I had a quick look yesterday and it seems that there might be a bug in the
> target address legaliser in this case [it is being called].
> 
> (there is another extremely similar problem, where the legaliser is never
> called, but I was jumping to conclusions that it was the same one too soon)

It seems that both of these are actually in play (it is not sufficient just to
fix the legaliser)

[Bug target/104117] [9,10,11,12 Regression] Darwin ppc64 uses invalid non-PIC address to access constants (in PIC code).

[iains at gcc dot gnu.org]

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

--- Comment #7 from Iain Sandoe <iains at gcc dot gnu.org> ---
Created attachment 52241
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52241&action=edit
RTL from ira pass

this all looks sane enough - there are two (small) literal loads 0 and 1 and
the load of 1 is then promoted to double.

[Bug target/104117] [9,10,11,12 Regression] Darwin ppc64 uses invalid non-PIC address to access constants (in PIC code).

[iains at gcc dot gnu.org]

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

--- Comment #8 from Iain Sandoe <iains at gcc dot gnu.org> ---
Created attachment 52242
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52242&action=edit
RTL from LRA

this is not legal in PIC code (the symbol ref needs to be wrapped in a
UNSPEC_MACHOPIC_OFFSET:

(insn 55 10 4 2 (set (reg:DI 2 r2 [137])
        (high:DI (symbol_ref/u:DI ("*lC0") [flags 0x2])))
"/source/test/ppc/pr104117.c":10:7 11 {macho_high_di}
     (nil))
(insn 4 55 5 2 (set (reg:DI 63 f31 [orig:122 pretmp_11+-4 ] [122])
        (mem/u/c:DI (lo_sum:DI (reg:DI 2 r2 [137])
                (symbol_ref/u:DI ("*lC0") [flags 0x2])) [0  S8 A64]))
"/source/test/ppc/pr104117.c":10:7 660 {*movdi_internal64}
     (expr_list:REG_EQUAL (const_int 1 [0x1])
        (nil)))

[Bug target/104117] [9,10,11,12 Regression] Darwin ppc64 uses invalid non-PIC address to access constants (in PIC code).

[iains at gcc dot gnu.org]

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

--- Comment #9 from Iain Sandoe <iains at gcc dot gnu.org> ---
and we get bad asm like so:

_decimals:
        mflr r0
        lis r2,ha16(lC0)
        stfd f31,-8(r1)
        stfd f30,-16(r1)
        addi r11,r1,-16
        lfd f31,lo16(lC0)(r2)


where (a) this is happening before the picbase is set up and 
      (b) the "lC0" should be like "lC0-L1$pb"
      where L1$pb is the picbase label.

=====

[Bug target/104117] [9,10,11,12 Regression] Darwin ppc64 uses invalid non-PIC address to access constants (in PIC code).

[iains at gcc dot gnu.org]

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

--- Comment #10 from Iain Sandoe <iains at gcc dot gnu.org> ---
simplified C code reproduce (on 11.2 or 11.x up to r11-8936-gbe64e725111fdb9,
the following commit changes the optimisation of the loading and makes the bug
latent)

typedef int int32_t;

extern double floor( double );
extern double fabs( double );

static int32_t p10[] = {1, 10, 100, 1000, 10000};

int decimals(double n) {

    n = fabs(n);
    for (int ndigits=0; ndigits<=3; ndigits++) {
        double scaledN = n * p10[ndigits];
        if (scaledN == floor(scaledN)) {
            return ndigits;
        }
    }
    return 0;
}

[Bug target/104117] [9,10,11,12 Regression] Darwin ppc64 uses invalid non-PIC address to access constants (in PIC code).

[iains at gcc dot gnu.org]

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

--- Comment #11 from Iain Sandoe <iains at gcc dot gnu.org> ---
[this is reproducible on a cross]

@vmakarov
 - I need some help understanding the intent of this code in
"lra-constraints.c"[3552-3614 in the 11.x branch, where i can see this bug up
to r11-8936-gbe64e725111fdb9] as noted above that is only because subsequent
patches have made the problem latent in the test code.

The code is triggered by (2) here (LRA has decided to force the const to men).

    2) the address is an invalid symbolic address created by
     force_const_to_mem.

<snip>

so the address "SYMBOL_REF("*LCNN") is not valid for PIC code on this
platform...

.. but the code below seems to work on the principle that putting the invalid
addr into a register is enough to make it valid - but actually what is needed
is for the target to add a wrapper to the SYMBOL_REF - however, I do not see
the target's address legitimiser code being called after this - or during this,

We seem to be unconditionally building
 R = HIGH (invalid)
 R' = R + LO_SUM(invalid)

the second valid_address_p() has the register as the tested object, which will
be OK even tho the lo_sum constant is not?

IFF I hack the code to punt after the first valid_address_p() call fails, it
fixes the bug, but I'm not at all sure that this is the right solution - or
what effect it might have elsewhere.

Perhaps this target is the only LO_SUM one with a wrapper on addresses (but
OTOH, I could imagine TLS symbols with similar properties).

----

          new_reg = lra_create_new_reg (Pmode, NULL_RTX, cl, "addr");
          if (HAVE_lo_sum)
            {
              /* addr => lo_sum (new_base, addr), case (2) above.  */
              insn = emit_insn (gen_rtx_SET
                                (new_reg,
                                 gen_rtx_HIGH (Pmode, copy_rtx (addr))));

              code = recog_memoized (insn);
              if (code >= 0)
                {
                  *ad.inner = gen_rtx_LO_SUM (Pmode, new_reg, addr);
                  if (!valid_address_p (op, &ad, cn))
                    {
                      /* Try to put lo_sum into register.  */
                      insn = emit_insn (gen_rtx_SET
                                        (new_reg,
                                         gen_rtx_LO_SUM (Pmode, new_reg,
addr)));
                      code = recog_memoized (insn);
                      if (code >= 0)
                        {
                          *ad.inner = new_reg;
                          if (!valid_address_p (op, &ad, cn))
                            {
                              *ad.inner = addr;
                              code = -1;
                            }
                        }
                    }
                }
              if (code < 0)
                delete_insns_since (last);

[Bug target/104117] [9,10,11,12 Regression] Darwin ppc64 uses invalid non-PIC address to access constants (in PIC code).

[vital.had at gmail dot com]

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

--- Comment #12 from Sergey Fedorov <vital.had at gmail dot com> ---
Not sure if the error is related, but trying to build icu with gcc6 in Macports
gives this:

/opt/local/bin/g++-mp-6 -DU_ATTRIBUTE_DEPRECATED= -DU_I18N_IMPLEMENTATION
-DU_HAVE_STRTOD_L=1 -DU_HAVE_XLOCALE_H=1 -I. -I../common -pipe -Os -m32
-D_GLIBCXX_USE_CXX11_ABI=0 -W -Wall -pedantic -Wpointer-arith -Wwrite-strings
-Wno-long-long -std=c++11 -fvisibility=hidden -fno-common -c -dynamic -MMD -MT
"formatted_string_builder.d formatted_string_builder.o
formatted_string_builder.ao" -o formatted_string_builder.o
formatted_string_builder.cpp
ar r -c ../lib/libicui18n.a ucln_in.ao fmtable.ao format.ao msgfmt.ao umsg.ao
numfmt.ao unum.ao decimfmt.ao dcfmtsym.ao fmtable_cnv.ao choicfmt.ao datefmt.ao
smpdtfmt.ao reldtfmt.ao dtfmtsym.ao udat.ao dtptngen.ao udatpg.ao nfrs.ao
nfrule.ao nfsubs.ao rbnf.ao numsys.ao unumsys.ao ucsdet.ao ucal.ao calendar.ao
gregocal.ao timezone.ao simpletz.ao olsontz.ao astro.ao taiwncal.ao buddhcal.ao
persncal.ao islamcal.ao japancal.ao gregoimp.ao hebrwcal.ao indiancal.ao
chnsecal.ao cecal.ao coptccal.ao dangical.ao ethpccal.ao coleitr.ao coll.ao
sortkey.ao bocsu.ao ucoleitr.ao ucol.ao ucol_res.ao ucol_sit.ao collation.ao
collationsettings.ao collationdata.ao collationtailoring.ao
collationdatareader.ao collationdatawriter.ao collationfcd.ao
collationiterator.ao utf16collationiterator.ao utf8collationiterator.ao
uitercollationiterator.ao collationsets.ao collationcompare.ao
collationfastlatin.ao collationkeys.ao rulebasedcollator.ao collationroot.ao
collationrootelements.ao collationdatabuilder.ao collationweights.ao
collationruleparser.ao collationbuilder.ao collationfastlatinbuilder.ao
listformatter.ao ulistformatter.ao strmatch.ao usearch.ao search.ao stsearch.ao
translit.ao utrans.ao esctrn.ao unesctrn.ao funcrepl.ao strrepl.ao tridpars.ao
cpdtrans.ao rbt.ao rbt_data.ao rbt_pars.ao rbt_rule.ao rbt_set.ao nultrans.ao
remtrans.ao casetrn.ao titletrn.ao tolowtrn.ao toupptrn.ao anytrans.ao
name2uni.ao uni2name.ao nortrans.ao quant.ao transreg.ao brktrans.ao
regexcmp.ao rematch.ao repattrn.ao regexst.ao regextxt.ao regeximp.ao uregex.ao
uregexc.ao ulocdata.ao measfmt.ao currfmt.ao curramt.ao currunit.ao measure.ao
utmscale.ao csdetect.ao csmatch.ao csr2022.ao csrecog.ao csrmbcs.ao csrsbcs.ao
csrucode.ao csrutf8.ao inputext.ao wintzimpl.ao windtfmt.ao winnmfmt.ao
basictz.ao dtrule.ao rbtz.ao tzrule.ao tztrans.ao vtzone.ao zonemeta.ao
standardplural.ao upluralrules.ao plurrule.ao plurfmt.ao selfmt.ao dtitvfmt.ao
dtitvinf.ao udateintervalformat.ao tmunit.ao tmutamt.ao tmutfmt.ao currpinf.ao
uspoof.ao uspoof_impl.ao uspoof_build.ao uspoof_conf.ao smpdtfst.ao ztrans.ao
zrule.ao vzone.ao fphdlimp.ao fpositer.ao ufieldpositer.ao decNumber.ao
decContext.ao alphaindex.ao tznames.ao tznames_impl.ao tzgnames.ao tzfmt.ao
compactdecimalformat.ao gender.ao region.ao scriptset.ao uregion.ao
reldatefmt.ao quantityformatter.ao measunit.ao measunit_extra.ao
sharedbreakiterator.ao scientificnumberformatter.ao dayperiodrules.ao nounit.ao
number_affixutils.ao number_compact.ao number_decimalquantity.ao
number_decimfmtprops.ao number_fluent.ao number_formatimpl.ao
number_grouping.ao number_integerwidth.ao number_longnames.ao
number_modifiers.ao number_notation.ao number_output.ao number_padding.ao
number_patternmodifier.ao number_patternstring.ao number_rounding.ao
number_scientific.ao number_utils.ao number_asformat.ao number_mapper.ao
number_multiplier.ao number_currencysymbols.ao number_skeletons.ao
number_capi.ao double-conversion-string-to-double.ao
double-conversion-double-to-string.ao double-conversion-bignum-dtoa.ao
double-conversion-bignum.ao double-conversion-cached-powers.ao
double-conversion-fast-dtoa.ao double-conversion-strtod.ao string_segment.ao
numparse_parsednumber.ao numparse_impl.ao numparse_symbols.ao
numparse_decimal.ao numparse_scientific.ao numparse_currency.ao
numparse_affixes.ao numparse_compositions.ao numparse_validators.ao
numrange_fluent.ao numrange_impl.ao erarules.ao formattedvalue.ao
formattedval_iterimpl.ao formattedval_sbimpl.ao formatted_string_builder.ao
/opt/local/bin/ranlib: file: ../lib/libicui18n.a(wintzimpl.ao) has no symbols
/opt/local/bin/ranlib: file: ../lib/libicui18n.a(windtfmt.ao) has no symbols
/opt/local/bin/ranlib: file: ../lib/libicui18n.a(winnmfmt.ao) has no symbols
ranlib ../lib/libicui18n.a
ranlib: file: ../lib/libicui18n.a(wintzimpl.ao) has no symbols
ranlib: file: ../lib/libicui18n.a(windtfmt.ao) has no symbols
ranlib: file: ../lib/libicui18n.a(winnmfmt.ao) has no symbols
/opt/local/bin/g++-mp-6 -dynamiclib -dynamic -pipe -Os -m32
-D_GLIBCXX_USE_CXX11_ABI=0 -W -Wall -pedantic -Wpointer-arith -Wwrite-strings
-Wno-long-long -std=c++11    -fvisibility=hidden
-Wl,-headerpad_max_install_names -Wl,-read_only_relocs,suppress -m32   
-Wl,-compatibility_version -Wl,67 -Wl,-current_version -Wl,67.1 -install_name
/opt/local/lib/libicui18n.67.dylib -o ../lib/libicui18n.67.1.dylib ucln_in.o
fmtable.o format.o msgfmt.o umsg.o numfmt.o unum.o decimfmt.o dcfmtsym.o
fmtable_cnv.o choicfmt.o datefmt.o smpdtfmt.o reldtfmt.o dtfmtsym.o udat.o
dtptngen.o udatpg.o nfrs.o nfrule.o nfsubs.o rbnf.o numsys.o unumsys.o ucsdet.o
ucal.o calendar.o gregocal.o timezone.o simpletz.o olsontz.o astro.o taiwncal.o
buddhcal.o persncal.o islamcal.o japancal.o gregoimp.o hebrwcal.o indiancal.o
chnsecal.o cecal.o coptccal.o dangical.o ethpccal.o coleitr.o coll.o sortkey.o
bocsu.o ucoleitr.o ucol.o ucol_res.o ucol_sit.o collation.o collationsettings.o
collationdata.o collationtailoring.o collationdatareader.o
collationdatawriter.o collationfcd.o collationiterator.o
utf16collationiterator.o utf8collationiterator.o uitercollationiterator.o
collationsets.o collationcompare.o collationfastlatin.o collationkeys.o
rulebasedcollator.o collationroot.o collationrootelements.o
collationdatabuilder.o collationweights.o collationruleparser.o
collationbuilder.o collationfastlatinbuilder.o listformatter.o ulistformatter.o
strmatch.o usearch.o search.o stsearch.o translit.o utrans.o esctrn.o
unesctrn.o funcrepl.o strrepl.o tridpars.o cpdtrans.o rbt.o rbt_data.o
rbt_pars.o rbt_rule.o rbt_set.o nultrans.o remtrans.o casetrn.o titletrn.o
tolowtrn.o toupptrn.o anytrans.o name2uni.o uni2name.o nortrans.o quant.o
transreg.o brktrans.o regexcmp.o rematch.o repattrn.o regexst.o regextxt.o
regeximp.o uregex.o uregexc.o ulocdata.o measfmt.o currfmt.o curramt.o
currunit.o measure.o utmscale.o csdetect.o csmatch.o csr2022.o csrecog.o
csrmbcs.o csrsbcs.o csrucode.o csrutf8.o inputext.o wintzimpl.o windtfmt.o
winnmfmt.o basictz.o dtrule.o rbtz.o tzrule.o tztrans.o vtzone.o zonemeta.o
standardplural.o upluralrules.o plurrule.o plurfmt.o selfmt.o dtitvfmt.o
dtitvinf.o udateintervalformat.o tmunit.o tmutamt.o tmutfmt.o currpinf.o
uspoof.o uspoof_impl.o uspoof_build.o uspoof_conf.o smpdtfst.o ztrans.o zrule.o
vzone.o fphdlimp.o fpositer.o ufieldpositer.o decNumber.o decContext.o
alphaindex.o tznames.o tznames_impl.o tzgnames.o tzfmt.o compactdecimalformat.o
gender.o region.o scriptset.o uregion.o reldatefmt.o quantityformatter.o
measunit.o measunit_extra.o sharedbreakiterator.o scientificnumberformatter.o
dayperiodrules.o nounit.o number_affixutils.o number_compact.o
number_decimalquantity.o number_decimfmtprops.o number_fluent.o
number_formatimpl.o number_grouping.o number_integerwidth.o number_longnames.o
number_modifiers.o number_notation.o number_output.o number_padding.o
number_patternmodifier.o number_patternstring.o number_rounding.o
number_scientific.o number_utils.o number_asformat.o number_mapper.o
number_multiplier.o number_currencysymbols.o number_skeletons.o number_capi.o
double-conversion-string-to-double.o double-conversion-double-to-string.o
double-conversion-bignum-dtoa.o double-conversion-bignum.o
double-conversion-cached-powers.o double-conversion-fast-dtoa.o
double-conversion-strtod.o string_segment.o numparse_parsednumber.o
numparse_impl.o numparse_symbols.o numparse_decimal.o numparse_scientific.o
numparse_currency.o numparse_affixes.o numparse_compositions.o
numparse_validators.o numrange_fluent.o numrange_impl.o erarules.o
formattedvalue.o formattedval_iterimpl.o formattedval_sbimpl.o
formatted_string_builder.o -L../lib -licuuc -L../stubdata -licudata -lpthread
-lm 
ld: duplicate symbol
icu_67::number::NumberFormatterSettings<icu_67::number::UnlocalizedNumberFormatter>::copyErrorTo(UErrorCode&)
const in number_skeletons.o and number_fluent.o
collect2: error: ld returned 1 exit status
gnumake[1]: *** [../lib/libicui18n.67.1.dylib] Error 1
gnumake[1]: Leaving directory
`/opt/local/var/macports/build/_opt_PPCLeopardPorts_devel_icu/icu/work/icu/source-ppc/i18n'
gnumake: *** [all-recursive] Error 2
gnumake: Leaving directory
`/opt/local/var/macports/build/_opt_PPCLeopardPorts_devel_icu/icu/work/icu/source-ppc'
Command failed:  cd
"/opt/local/var/macports/build/_opt_PPCLeopardPorts_devel_icu/icu/work/icu/source-ppc"
&& /usr/bin/gnumake -j4 -w all VERBOSE=1 
Exit code: 2
Error: Failed to build icu: command execution failed

[Bug target/104117] [9,10,11,12 Regression] Darwin ppc64 uses invalid non-PIC address to access constants (in PIC code).

[vmakarov at gcc dot gnu.org]

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

--- Comment #13 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
I think there are two code spots whose pitfalls resulted in the PR.

The first one is in rs6000.cc::legitimate_lo_sum_address_p which permits wrong
pic low-sum address.

Another one is in lra-constraints.cc::process_address_1 which permits put wrong
low-sum address in reg and use the reg in memory.

The following patch solves the problem:

diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 5404fb18755..306f67f26c4 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -8202,7 +8202,7 @@ legitimate_lo_sum_address_p (machine_mode mode, rtx x,
int strict)
     {
       bool large_toc_ok;

-      if (DEFAULT_ABI == ABI_V4 && flag_pic)
+      if ((DEFAULT_ABI == ABI_V4 || DEFAULT_ABI == ABI_DARWIN) && flag_pic)
        return false;
       /* LRA doesn't use LEGITIMIZE_RELOAD_ADDRESS as it usually calls
         push_reload from reload pass code.  LEGITIMIZE_RELOAD_ADDRESS
diff --git a/gcc/lra-constraints.c b/gcc/lra-constraints.c
index 30d088afbca..998e82be54f 100644
--- a/gcc/lra-constraints.c
+++ b/gcc/lra-constraints.c
@@ -3517,21 +3517,8 @@ process_address_1 (int nop, bool check_only_p,
                  *ad.inner = gen_rtx_LO_SUM (Pmode, new_reg, addr);
                  if (!valid_address_p (op, &ad, cn))
                    {
-                     /* Try to put lo_sum into register.  */
-                     insn = emit_insn (gen_rtx_SET
-                                       (new_reg,
-                                        gen_rtx_LO_SUM (Pmode, new_reg,
addr)));
-                     code = recog_memoized (insn);
-                     if (code >= 0)
-                       {
-                         *ad.inner = new_reg;
-                         if (!valid_address_p (op, &ad, cn))
-                           {
-                             *ad.inner = addr;
-                             code = -1;
-                           }
-                       }
-
+                     *ad.inner = addr;
+                     code = -1;
                    }
                }
              if (code < 0)

The patch was successfully tested on x86-64/ppc64 under Linux.

[Bug target/104117] [9,10,11,12 Regression] Darwin ppc64 uses invalid non-PIC address to access constants (in PIC code).

[vital.had at gmail dot com]

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

--- Comment #14 from Sergey Fedorov <vital.had at gmail dot com> ---
(In reply to Vladimir Makarov from comment #13)
> I think there are two code spots whose pitfalls resulted in the PR.
> 
> The first one is in rs6000.cc::legitimate_lo_sum_address_p which permits
> wrong pic low-sum address.
> 
> Another one is in lra-constraints.cc::process_address_1 which permits put
> wrong low-sum address in reg and use the reg in memory.
> 
> The following patch solves the problem:


Does this also address Bug 104118?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104118

[Bug target/104117] [9,10,11,12 Regression] Darwin ppc64 uses invalid non-PIC address to access constants (in PIC code).

[iains at gcc dot gnu.org]

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

--- Comment #15 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Vladimir Makarov from comment #13)
> I think there are two code spots whose pitfalls resulted in the PR.
> 
> The first one is in rs6000.cc::legitimate_lo_sum_address_p which permits
> wrong pic low-sum address.

Ack, 

> Another one is in lra-constraints.cc::process_address_1 which permits put
> wrong low-sum address in reg and use the reg in memory.
> 
> The following patch solves the problem:
> 
> diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
> index 5404fb18755..306f67f26c4 100644
> --- a/gcc/config/rs6000/rs6000.c
> +++ b/gcc/config/rs6000/rs6000.c
> @@ -8202,7 +8202,7 @@ legitimate_lo_sum_address_p (machine_mode mode, rtx x,
> int strict)
>      {
>        bool large_toc_ok;
> 
> -      if (DEFAULT_ABI == ABI_V4 && flag_pic)
> +      if ((DEFAULT_ABI == ABI_V4 || DEFAULT_ABI == ABI_DARWIN) && flag_pic)
>         return false;
>        /* LRA doesn't use LEGITIMIZE_RELOAD_ADDRESS as it usually calls
>          push_reload from reload pass code.  LEGITIMIZE_RELOAD_ADDRESS

I have a somewhat wider fix which accounts for the case that UNSPEC [
SYMBOL_REF ] MACHOPIC_UNSPEC_OFFSET *is* valid, where SYMBOL_REF is not (but
the change you have made could be sufficient - will try to get that into a
retest soon).

> diff --git a/gcc/lra-constraints.c b/gcc/lra-constraints.c
> index 30d088afbca..998e82be54f 100644
> --- a/gcc/lra-constraints.c
> +++ b/gcc/lra-constraints.c
> @@ -3517,21 +3517,8 @@ process_address_1 (int nop, bool check_only_p,
>                   *ad.inner = gen_rtx_LO_SUM (Pmode, new_reg, addr);
>                   if (!valid_address_p (op, &ad, cn))
>                     {
> -                     /* Try to put lo_sum into register.  */
> -                     insn = emit_insn (gen_rtx_SET
> -                                       (new_reg,
> -                                        gen_rtx_LO_SUM (Pmode, new_reg,
> addr)));
> -                     code = recog_memoized (insn);
> -                     if (code >= 0)
> -                       {
> -                         *ad.inner = new_reg;
> -                         if (!valid_address_p (op, &ad, cn))
> -                           {
> -                             *ad.inner = addr;
> -                             code = -1;
> -                           }
> -                       }
> -
> +                     *ad.inner = addr;
> +                     code = -1;
>                     }
>                 }
>               if (code < 0)
> 
> The patch was successfully tested on x86-64/ppc64 under Linux.

The second part of the patch is the same as what I was testing.

How to proceed on this (testing an LRA change widely enough)?

[Bug target/104117] [9,10,11,12 Regression] Darwin ppc64 uses invalid non-PIC address to access constants (in PIC code).

[iains at gcc dot gnu.org]

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

--- Comment #16 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Sergey Fedorov from comment #14)
> (In reply to Vladimir Makarov from comment #13)

> > The following patch solves the problem:
> 
> 
> Does this also address Bug 104118?
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104118

I was not able to reproduce 104118, but expect that it has the same underlying
cause - so "probably" - let us regression test the proposed change and go from
there.

[Bug target/104117] [9,10,11,12 Regression] Darwin ppc64 uses invalid non-PIC address to access constants (in PIC code).

[iains at gcc dot gnu.org]

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

--- Comment #17 from Iain Sandoe <iains at gcc dot gnu.org> ---
FTR: this is the patch I came up with:

diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 843ce97b993..3f803bd791f 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -8244,8 +8244,14 @@ darwin_rs6000_legitimate_lo_sum_const_p (rtx x,
machine_mode mode)
   if (GET_CODE (x) == CONST)
     x = XEXP (x, 0);

+  /* If we are building PIC code, then any symbol must be wrapped in an
+     UNSPEC_MACHOPIC_OFFSET so that it will get the picbase subtracted.  */
+  bool machopic_offs_p = false;
   if (GET_CODE (x) == UNSPEC && XINT (x, 1) == UNSPEC_MACHOPIC_OFFSET)
-    x =  XVECEXP (x, 0, 0);
+    {
+      x =  XVECEXP (x, 0, 0);
+      machopic_offs_p = true;
+    }

   rtx sym = NULL_RTX;
   unsigned HOST_WIDE_INT offset = 0;
@@ -8276,6 +8282,9 @@ darwin_rs6000_legitimate_lo_sum_const_p (rtx x,
machine_mode mode)
   if (sym)
     {
       tree decl = SYMBOL_REF_DECL (sym);
+      /* As noted above, PIC code cannot use a bare SYMBOL_REF.  */
+      if (TARGET_MACHO && flag_pic && !machopic_offs_p)
+       return false;
 #if TARGET_MACHO
       if (MACHO_SYMBOL_INDIRECTION_P (sym))
       /* The decl in an indirection symbol is the original one, which might
@@ -8863,7 +8872,7 @@ legitimate_lo_sum_address_p (machine_mode mode, rtx x,
int strict)
     return false;
   x = XEXP (x, 1);

-  if (TARGET_ELF || TARGET_MACHO)
+  if (TARGET_ELF)
     {
       bool large_toc_ok;

@@ -8889,11 +8898,35 @@ legitimate_lo_sum_address_p (machine_mode mode, rtx x,
int strict)

       return CONSTANT_P (x) || large_toc_ok;
     }
+  else if (TARGET_MACHO)
+    {
+      if (GET_MODE_NUNITS (mode) != 1)
+       return false;
+      if (GET_MODE_SIZE (mode) > UNITS_PER_WORD
+         && !(/* see above  */
+              TARGET_HARD_FLOAT && (mode == DFmode || mode == DDmode)))
+       return false;
+#if TARGET_MACHO
+      if (MACHO_DYNAMIC_NO_PIC_P || !flag_pic)
+       return CONSTANT_P (x);
+#endif
+      /* Macho-O PIC code from here.  */
+      if (GET_CODE (x) == CONST)
+       x = XEXP (x, 0);

+      /* SYMBOL_REFs need to be wrapped in an UNSPEC_MACHOPIC_OFFSET.  */
+      if (SYMBOL_REF_P (x))
+       return false;
+
+      /* So this is OK if the wrapped object is const.  */
+      if (GET_CODE (x) == UNSPEC
+         && XINT (x, 1) == UNSPEC_MACHOPIC_OFFSET)
+       return CONSTANT_P (XVECEXP (x, 0, 0));
+      return CONSTANT_P (x);
+    }
   return false;
 }

-
 /* Try machine-dependent ways of modifying an illegitimate address
    to be legitimate.  If we find one, return the new, valid address.
    This is used from only one place: `memory_address' in explow.c.
diff --git a/gcc/lra-constraints.c b/gcc/lra-constraints.c
index 5c2a2d7ce9c..3961dfd2725 100644
--- a/gcc/lra-constraints.c
+++ b/gcc/lra-constraints.c
@@ -3589,21 +3589,8 @@ process_address_1 (int nop, bool check_only_p,
                  *ad.inner = gen_rtx_LO_SUM (Pmode, new_reg, addr);
                  if (!valid_address_p (op, &ad, cn))
                    {
-                     /* Try to put lo_sum into register.  */
-                     insn = emit_insn (gen_rtx_SET
-                                       (new_reg,
-                                        gen_rtx_LO_SUM (Pmode, new_reg,
addr)));
-                     code = recog_memoized (insn);
-                     if (code >= 0)
-                       {
-                         *ad.inner = new_reg;
-                         if (!valid_address_p (op, &ad, cn))
-                           {
-                             *ad.inner = addr;
-                             code = -1;
-                           }
-                       }
-
+                     *ad.inner = addr; /* Punt.  */
+                     code = -1;
                    }
                }
              if (code < 0)

[Bug target/104117] [9,10,11,12 Regression] Darwin ppc64 uses invalid non-PIC address to access constants (in PIC code).

[vital.had at gmail dot com]

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

--- Comment #18 from Sergey Fedorov <vital.had at gmail dot com> ---
(In reply to Iain Sandoe from comment #17)
> FTR: this is the patch I came up with:

Does it affect only ppc64? I am asking since if it affects ppc32, then I rather
rebuild gcc10ppc and gcc11ppc installed on 10.6.8 Rosetta and on 10A190. While
if it matters only for ppc64, then rebuilding on 10.5.8 is enough.

[Bug target/104117] [9,10,11,12 Regression] Darwin ppc64 uses invalid non-PIC address to access constants (in PIC code).

[iains at gcc dot gnu.org]

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

--- Comment #19 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Sergey Fedorov from comment #18)
> (In reply to Iain Sandoe from comment #17)
> > FTR: this is the patch I came up with:
> 
> Does it affect only ppc64? I am asking since if it affects ppc32, then I
> rather rebuild gcc10ppc and gcc11ppc installed on 10.6.8 Rosetta and on
> 10A190. While if it matters only for ppc64, then rebuilding on 10.5.8 is
> enough.

The problem is triggered by deciding to force a constant to memory, in
principle that could happen for ppc32 as well [e.g. for a double constant] (so
far, we have not seen an example).  Since we build the compiler
'mdynamic-no-pic' for performance, it is not going to show up there [since
SYMBOL_REF is a valid address in that case].

Once the patch is tested, posted and applied to master, then we will surely
back port to the effected branches.

[Bug target/104117] [9,10,11,12 Regression] Darwin ppc64 uses invalid non-PIC address to access constants (in PIC code).

[iains at gcc dot gnu.org]

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

--- Comment #20 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Iain Sandoe from comment #15)
> (In reply to Vladimir Makarov from comment #13)
> > I think there are two code spots whose pitfalls resulted in the PR.

> > --- a/gcc/config/rs6000/rs6000.c
> > +++ b/gcc/config/rs6000/rs6000.c
> > @@ -8202,7 +8202,7 @@ legitimate_lo_sum_address_p (machine_mode mode, rtx x,
> > int strict)
> >      {
> >        bool large_toc_ok;
> > 
> > -      if (DEFAULT_ABI == ABI_V4 && flag_pic)
> > +      if ((DEFAULT_ABI == ABI_V4 || DEFAULT_ABI == ABI_DARWIN) && flag_pic)
> >         return false;

On testing, this is not sufficient - one ends up with ICEs when we reject a
valid (UNSPEC-wrapped) address here.  So I think that the slightly more
elaborate target changes are required - but the LRA change seems fine!

... reg-straps on this old h/w take > 1 day .. so some more time will be needed
for a complete answer.

[Bug target/104117] [9,10,11,12 Regression] Darwin ppc64 uses invalid non-PIC address to access constants (in PIC code).

[vmakarov at gcc dot gnu.org]

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

--- Comment #21 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
(In reply to Iain Sandoe from comment #20)
> (In reply to Iain Sandoe from comment #15)
> > (In reply to Vladimir Makarov from comment #13)
> > > I think there are two code spots whose pitfalls resulted in the PR.
> 
> > > --- a/gcc/config/rs6000/rs6000.c
> > > +++ b/gcc/config/rs6000/rs6000.c
> > > @@ -8202,7 +8202,7 @@ legitimate_lo_sum_address_p (machine_mode mode, rtx x,
> > > int strict)
> > >      {
> > >        bool large_toc_ok;
> > > 
> > > -      if (DEFAULT_ABI == ABI_V4 && flag_pic)
> > > +      if ((DEFAULT_ABI == ABI_V4 || DEFAULT_ABI == ABI_DARWIN) && flag_pic)
> > >         return false;
> 
> On testing, this is not sufficient - one ends up with ICEs when we reject a
> valid (UNSPEC-wrapped) address here.  So I think that the slightly more
> elaborate target changes are required - but the LRA change seems fine!
> 
> ... reg-straps on this old h/w take > 1 day .. so some more time will be
> needed for a complete answer.

Ian, you have my approval for LRA changes in advance for committing them into
the master and the branches when the overall patch is ready.  Thank you for
working on machine-dependent parts of the patch.

[Bug target/104117] [9,10,11,12 Regression] Darwin ppc64 uses invalid non-PIC address to access constants (in PIC code).

[vital.had at gmail dot com]

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

--- Comment #22 from Sergey Fedorov <vital.had at gmail dot com> ---
(In reply to Iain Sandoe from comment #20)
> On testing, this is not sufficient - one ends up with ICEs when we reject a
> valid (UNSPEC-wrapped) address here.  So I think that the slightly more
> elaborate target changes are required - but the LRA change seems fine!
> ... reg-straps on this old h/w take > 1 day .. so some more time will be
> needed for a complete answer.

Once you decide the patch is ready for testing, please let me know, I will test
it on my end too (for icu and R both).
And thank you so much indeed.

[Bug target/104117] [9,10,11,12 Regression] Darwin ppc64 uses invalid non-PIC address to access constants (in PIC code).

[cvs-commit at gcc dot gnu.org]

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

--- Comment #23 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Iain D Sandoe <iains@gcc.gnu.org>:

https://gcc.gnu.org/g:4c3792d448964f7bd99e7eac2c29c9eb7c2bfb84

commit r12-7209-g4c3792d448964f7bd99e7eac2c29c9eb7c2bfb84
Author: Iain Sandoe <iain@sandoe.co.uk>
Date:   Mon Feb 7 15:36:35 2022 +0000

    LRA, rs6000, Darwin: Amend lo_sum use for forced constants [PR104117].

    Two issues resulted in this PR, which manifests when we force a constant
into
    memory in LRA (in PIC code on Darwin).  The presence of such forced
constants
    is quite dependent on other RTL optimisations, and it is easy for the issue
to
    become latent for a specific case.

    First, in the Darwin-specific rs6000 backend code, we were not being
careful
    enough in rejecting invalid symbolic addresses.  Specifically, when
generating
    PIC code, we require a SYMBOL_REF to be wrapped in an
UNSPEC_MACHOPIC_OFFSET.

    Second, LRA was attempting to load a register using an invalid lo_sum
address.

    Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>
    Co-authored-by: Vladimir Makarov <vmakarov@redhat.com>

            PR target/104117

    gcc/ChangeLog:

            * config/rs6000/rs6000.cc
(darwin_rs6000_legitimate_lo_sum_const_p):
            Check for UNSPEC_MACHOPIC_OFFSET wrappers on symbolic addresses
when
            emitting PIC code.
            (legitimate_lo_sum_address_p): Likewise.
            * lra-constraints.cc (process_address_1): Do not attempt to emit a
reg
            load from an invalid lo_sum address.

[Bug target/104117] [9,10,11,12 Regression] Darwin ppc64 uses invalid non-PIC address to access constants (in PIC code).

[iains at gcc dot gnu.org]

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

--- Comment #24 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Sergey Fedorov from comment #22)
> (In reply to Iain Sandoe from comment #20)
> > On testing, this is not sufficient - one ends up with ICEs when we reject a
> > valid (UNSPEC-wrapped) address here.  So I think that the slightly more
> > elaborate target changes are required - but the LRA change seems fine!
> > ... reg-straps on this old h/w take > 1 day .. so some more time will be
> > needed for a complete answer.
> 
> Once you decide the patch is ready for testing, please let me know, I will
> test it on my end too (for icu and R both).

The patch applied to master will be backported (when I have some time!) .. but
it should apply reasonably easily to 11.2 / 10.3 if you are keen to try it out.

[Bug target/104117] [9,10,11,12 Regression] Darwin ppc64 uses invalid non-PIC address to access constants (in PIC code).

[cvs-commit at gcc dot gnu.org]

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

--- Comment #25 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Iain D Sandoe <iains@gcc.gnu.org>:

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

commit r12-7486-gf1b3e3853329b58fb2e50c17487df2ecbc4a5608
Author: Iain Sandoe <iain@sandoe.co.uk>
Date:   Wed Feb 23 13:53:44 2022 +0000

    LRA, rs6000, Darwin: Revise lo_sum use for forced constants [PR104117].

    Follow up discussion to the initial patch for this PR identified that it is
    preferable to avoid the LRA change, and arrange for the target to reject
the
    hi and lo_sum selections when presented with an invalid address.

    We split the Darwin high/low selectors into two:
     1. One that handles non-PIC addresses (kernel mode, mdynamic-no-pic).
     2. One that handles PIC addresses and rejects SYMBOL_REFs unless they are
        suitably wrapped in the MACHOPIC_OFFSET unspec.

    The second case is handled by providing a new predicate (macho_pic_address)
    that checks the requirements.

    Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>

            PR target/104117

    gcc/ChangeLog:

            * config/rs6000/darwin.md (@machopic_high_<mode>): New.
            (@machopic_low_<mode>): New.
            * config/rs6000/predicates.md (macho_pic_address): New.
            * config/rs6000/rs6000.cc (rs6000_legitimize_address): Do not
            apply the TLS processing to Darwin.
            * lra-constraints.cc (process_address_1): Revert the changes
            in r12-7209.

[Bug target/104117] [9,10,11,12 Regression] Darwin ppc64 uses invalid non-PIC address to access constants (in PIC code).

[cvs-commit at gcc dot gnu.org]

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

--- Comment #26 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Iain D Sandoe
<iains@gcc.gnu.org>:

https://gcc.gnu.org/g:53254184bda6305ac38e6e37480303b9f167b5ae

commit r11-9879-g53254184bda6305ac38e6e37480303b9f167b5ae
Author: Iain Sandoe <iain@sandoe.co.uk>
Date:   Mon Feb 7 15:36:35 2022 +0000

    Darwin, rs6000: Amend lo_sum use for forced constants [PR104117].

    Two issues resulted in this PR, which manifests when we force a constant
into
    memory in LRA (in PIC code on Darwin).  The presence of such forced
constants
    is quite dependent on other RTL optimisations, and it is easy for the issue
to
    become latent for a specific case.

    First, in the Darwin-specific rs6000 backend code, we were not being
careful
    enough in rejecting invalid symbolic addresses.  Specifically, when
generating
    PIC code, we require a SYMBOL_REF to be wrapped in an
UNSPEC_MACHOPIC_OFFSET.

    We now split the Darwin high/low selectors into two:
     1. One that handles non-PIC addresses (kernel mode, mdynamic-no-pic).
     2. One that handles PIC addresses and rejects SYMBOL_REFs unless they are
        suitably wrapped in the MACHOPIC_OFFSET unspec.

    The second case is handled by providing a new predicate (macho_pic_address)
    that checks the requirements.

    Backported from 4c3792d448964f7bd99e7eac2c29c9eb7c2bfb84 and
    f1b3e3853329b58fb2e50c17487df2ecbc4a5608

    Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>
    Co-authored-by: Vladimir Makarov <vmakarov@redhat.com>

            PR target/104117

    gcc/ChangeLog:

            * config/rs6000/rs6000.c (darwin_rs6000_legitimate_lo_sum_const_p):
            Check for UNSPEC_MACHOPIC_OFFSET wrappers on symbolic addresses
when
            emitting PIC code.
            (legitimate_lo_sum_address_p): Likewise.
            (rs6000_legitimize_address): Do not apply the TLS processing to
            Darwin.
            * config/rs6000/darwin.md (@machopic_high_<mode>): New.
            (@machopic_low_<mode>): New.
            * config/rs6000/predicates.md (macho_pic_address): New.

[Bug target/104117] [9,10 Regression] Darwin ppc64 uses invalid non-PIC address to access constants (in PIC code).

[cvs-commit at gcc dot gnu.org]

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

--- Comment #27 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Iain D Sandoe
<iains@gcc.gnu.org>:

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

commit r10-10796-gcfad91385ae0f92eedda1fff5f6f4b23da9f1f1b
Author: Iain Sandoe <iain@sandoe.co.uk>
Date:   Mon Feb 7 15:36:35 2022 +0000

    Darwin, rs6000: Amend lo_sum use for forced constants [PR104117].

    Two issues resulted in this PR, which manifests when we force a constant
into
    memory in LRA (in PIC code on Darwin).  The presence of such forced
constants
    is quite dependent on other RTL optimisations, and it is easy for the issue
to
    become latent for a specific case.

    First, in the Darwin-specific rs6000 backend code, we were not being
careful
    enough in rejecting invalid symbolic addresses.  Specifically, when
generating
    PIC code, we require a SYMBOL_REF to be wrapped in an
UNSPEC_MACHOPIC_OFFSET.

    We now split the Darwin high/low selectors into two:
     1. One that handles non-PIC addresses (kernel mode, mdynamic-no-pic).
     2. One that handles PIC addresses and rejects SYMBOL_REFs unless they are
        suitably wrapped in the MACHOPIC_OFFSET unspec.

    The second case is handled by providing a new predicate (macho_pic_address)
    that checks the requirements.

    Backported from 4c3792d448964f7bd99e7eac2c29c9eb7c2bfb84 and
    f1b3e3853329b58fb2e50c17487df2ecbc4a5608

    Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>
    Co-authored-by: Vladimir Makarov <vmakarov@redhat.com>

            PR target/104117

    gcc/ChangeLog:

            * config/rs6000/rs6000.c (darwin_rs6000_legitimate_lo_sum_const_p):
            Check for UNSPEC_MACHOPIC_OFFSET wrappers on symbolic addresses
when
            emitting PIC code.
            (legitimate_lo_sum_address_p): Likewise.
            (rs6000_legitimize_address): Do not apply the TLS processing to
            Darwin.
            * config/rs6000/darwin.md (@machopic_high_<mode>): New.
            (@machopic_low_<mode>): New.
            * config/rs6000/predicates.md (macho_pic_address): New.

[Bug target/104117] [9,10 Regression] Darwin ppc64 uses invalid non-PIC address to access constants (in PIC code).

[iains at gcc dot gnu.org]

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

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

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

--- Comment #28 from Iain Sandoe <iains at gcc dot gnu.org> ---
fixed on open branches some version of this is needed on closed branches where
LRA is used ( 7, 8, 9 )