[Bug target/104117] [9,10,11,12 Regression] Darwin ppc64 uses invalid non-PIC address to access constants (in PIC code).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104117 --- Comment #26 from CVS Commits --- The releases/gcc-11 branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:53254184bda6305ac38e6e37480303b9f167b5ae commit r11-9879-g53254184bda6305ac38e6e37480303b9f167b5ae Author: Iain Sandoe Date: Mon Feb 7 15:36:35 2022 + 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 Co-authored-by: Vladimir Makarov 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_): New. (@machopic_low_): New. * config/rs6000/predicates.md (macho_pic_address): New.
[Bug target/104117] [9,10,11,12 Regression] Darwin ppc64 uses invalid non-PIC address to access constants (in PIC code).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104117 --- Comment #25 from CVS Commits --- The master branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:f1b3e3853329b58fb2e50c17487df2ecbc4a5608 commit r12-7486-gf1b3e3853329b58fb2e50c17487df2ecbc4a5608 Author: Iain Sandoe Date: Wed Feb 23 13:53:44 2022 + 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 PR target/104117 gcc/ChangeLog: * config/rs6000/darwin.md (@machopic_high_): New. (@machopic_low_): 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).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104117 --- Comment #24 from Iain Sandoe --- (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).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104117 --- Comment #23 from CVS Commits --- The master branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:4c3792d448964f7bd99e7eac2c29c9eb7c2bfb84 commit r12-7209-g4c3792d448964f7bd99e7eac2c29c9eb7c2bfb84 Author: Iain Sandoe Date: Mon Feb 7 15:36:35 2022 + 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 Co-authored-by: Vladimir Makarov 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).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104117 --- Comment #22 from Sergey Fedorov --- (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).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104117
--- Comment #21 from Vladimir Makarov ---
(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).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104117
--- Comment #20 from Iain Sandoe ---
(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).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104117 --- Comment #19 from Iain Sandoe --- (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).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104117 --- Comment #18 from Sergey Fedorov --- (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).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104117
--- Comment #17 from Iain Sandoe ---
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).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104117 --- Comment #16 from Iain Sandoe --- (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).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104117
--- Comment #15 from Iain Sandoe ---
(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).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104117 --- Comment #14 from Sergey Fedorov --- (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).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104117
--- Comment #13 from Vladimir Makarov ---
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).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104117 --- Comment #12 from Sergey Fedorov --- 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.dy
[Bug target/104117] [9,10,11,12 Regression] Darwin ppc64 uses invalid non-PIC address to access constants (in PIC code).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104117
--- Comment #11 from Iain Sandoe ---
[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.
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).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104117
--- Comment #10 from Iain Sandoe ---
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, 1};
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).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104117 --- Comment #9 from Iain Sandoe --- 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).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104117
--- Comment #8 from Iain Sandoe ---
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).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104117 --- Comment #7 from Iain Sandoe --- 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.
