| Message ID | yddsgzmkels.fsf@CeBiTec.Uni-Bielefeld.DE |
|---|---|
| State | New |
| Headers | show |
| Series | [testsuite] Require ucn support in gdc.test/compilable/ddoc12.d (PR d/88039) | expand |
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.
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. Rainer
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. -- Iain
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. Thanks. Rainer
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.
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.
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. Thanks. Rainer
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.
# HG changeset patch # Parent c94c294504322187c207bc70ad6734280adc7043 Require ucn support in gdc.test/compilable/ddoc12.d (PR d/88039) diff --git a/gcc/testsuite/gdc.test/gdc-test.exp b/gcc/testsuite/gdc.test/gdc-test.exp --- a/gcc/testsuite/gdc.test/gdc-test.exp +++ b/gcc/testsuite/gdc.test/gdc-test.exp @@ -276,6 +276,14 @@ proc dmd2dg { base test } { # Since GCC 6-20160131 blank lines are not allowed in the output by default. dg-allow-blank-lines-in-output { 1 } + # Require UCN support for tests with UCN identifiers. + switch $test { + compilable/ddoc12.d { + set out_line "// { dg-require-effective-target ucn }" + puts $fdout $out_line + } + } + # Compilable files are successful if an output is generated. # Fail compilable are successful if an output is not generated. # Runnable must compile, link, and return 0 to be successful by default.