This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [testsuite] Require ucn support in gdc.test/compilable/ddoc12.d (PR d/88039)


On Tue, 4 Dec 2018 at 14:49, Rainer Orth <ro@cebitec.uni-bielefeld.de> wrote:
>
> Hi Iain,
>
> > On Sat, 1 Dec 2018 at 19:28, Iain Buclaw <ibuclaw@gdcproject.org> wrote:
> >>
> >> On Thu, 29 Nov 2018 at 15:12, Rainer Orth <ro@cebitec.uni-bielefeld.de> wrote:
> >> >
> >> > Hi Iain,
> >> >
> >> > > On Tue, 27 Nov 2018 at 20:32, Rainer Orth
> >> > > <ro@cebitec.uni-bielefeld.de> wrote:
> >> > >>
> >> > >> Hi Mike,
> >> > >>
> >> > >> > On Nov 27, 2018, at 2:18 AM, Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
> >> > >> > wrote:
> >> > >> >>
> >> > >> >> Some assemblers, including the Solaris one, don't support UTF-8
> >> > >> >> identifiers, which breaks the gdc.test/compilable/ddoc12.d testcase as
> >> > >> >> reported in the PR.
> >> > >> >
> >> > >> > So, another style of fix, would be to change the binding from the
> >> > >> > language
> >> > >> > front-end to encode unsupported symbols using a fixed, documented, abi
> >> > >> > defined technique.
> >> > >>
> >> > >> there's been some discussion on this in the PR.  Joseph's suggestion was
> >> > >> to follow the system compilers if this were done, and indeed they do
> >> > >> encode UTF-8 identifiers in some way which could either be
> >> > >> reverse-engineered or a spec obtained.  However, given Iain's stance
> >> > >> towards UTF-8 identifiers in D, I very much doubt this is worth the
> >> > >> effort.  Ultimately, it's his call, of course.
> >> > >>
> >> > >
> >> > > Not only my stance, but as a whole just how those maintaining the core
> >> > > language generally agree on. Encoding UTF8 characters in symbols is
> >> > > not part of the D ABI, so that is something that needs convincing
> >> > > upstream.
> >> > >
> >> > > There is a third way however, all compilable/ddoc* tests don't
> >> > > actually require us to compile the module all the way down to object
> >> > > code, the only thing that really needs to be tested is the Ddoc
> >> > > generator itself.  Which would be setting 'dg-do-what compile' and
> >> > > build with the compiler option -fdoc, then dg-final checks for the
> >> > > presence of the file ddoc12.html is the minimum that needs to be done
> >> > > for these tests to be considered passed.
> >> > >
> >> > > I'll have a look into doing it that way tomorrow.
> >> >
> >> > that would be even better of course, also saving some testing time.
> >> >
> >>
> >> Hi Rainer,
> >>
> >> Attached patch for it, I've checked that and it does the right thing
> >> and passes on x86_64.
> >>
> >> There's a couple more changes than just testsuite files, as compiling
> >> with -fdoc unearthed bug fixes not backported from the D version of
> >> the compiler.  These I'll apply separately.
> >>
> >
> > D2 front-end and testsuite changes have been upstreamed/downstreamed.
> > If there's no complaint, I'll apply the dejagnu fix as well.
>
> not at all: I've checked it on i386-pc-solaris2.11/gas and
> sparc-sun-solaris2.12/as and compilable/ddoc12.d now PASSes on both, so
> the gdc-test.exp part is ok.  Please mention PR d/88039 in the
> ChangeLog.
>

Done, and committed in r266933.

-- 
Iain


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]