libgcobol: mark riscv64-*-linux* as supported target

  * configure.tgt: Set LIBGCOBOL_SUPPORTED for riscv64-*-linux* with
	64-bit multilib.
---
 libgcobol/configure.tgt | 5 +++++
 1 file changed, 5 insertions(+)
  

On 4/15/25 7:57 AM, Andreas Schwab wrote:
> 	* configure.tgt: Set LIBGCOBOL_SUPPORTED for riscv64-*-linux* with
> 	64-bit multilib.
Can't say I'm happy with the amount of Cobol related churn at this phase 
in our cycle.  But this should be exceedingly safe.  So OK.

jeff
  

Speaking purely casually:  I thought that that COBOL would be released with 
documented limited capability.  "Yeah, it works on x86_64-linux and 
aarch64-linux.  More to come.".  We knew that we didn't know how to 
cross-compile, and we knew that other platforms would have to come, in time.

It never occurred to me that significant efforts would be made to fix all 
that in a month.

More formally:  I am very aware that I have not been as responsive here as 
maybe I should have been.  I plead incapacition due to inundation.

If I have missed anything; if anybody is waiting for me, please remind me. 
And if I have missed pings, I apologize; they've just been hidden in the 
deluge.

Thanks.

> -----Original Message-----
> From: Jeff Law <jeffreyalaw@gmail.com>
> Sent: Tuesday, April 15, 2025 10:32
> To: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] libgcobol: mark riscv64-*-linux* as supported target
>
>
>
> On 4/15/25 7:57 AM, Andreas Schwab wrote:
> > 	* configure.tgt: Set LIBGCOBOL_SUPPORTED for riscv64-*-linux* with
> > 	64-bit multilib.
> Can't say I'm happy with the amount of Cobol related churn at this phase
> in our cycle.  But this should be exceedingly safe.  So OK.
>
> jeff
  

On Tue, Apr 15, 2025 at 10:47:13AM -0500, Robert Dubner wrote:
> Speaking purely casually:  I thought that that COBOL would be released with 
> documented limited capability.  "Yeah, it works on x86_64-linux and 
> aarch64-linux.  More to come.".  We knew that we didn't know how to 
> cross-compile, and we knew that other platforms would have to come, in time.

What is definitely known not to work is big endian targets, cross
compilation from big endian hosts to little endian targets, 32-bit targets,
cross compilation from 32-bit hosts, I'm afraid we can live with it for the
15 release.

What is still missing are web page updates, the repository in that case
is ssh://gcc.gnu.org/git/gcc-wwwdocs.git and e.g https://gcc.gnu.org/
lists in News (left column)
"Modula-2 front end added [2022-12-14]
The Modula-2 programming language front end has been added to GCC.
This front end was contributed by Gaius Mulley."
so we want something like that for COBOL too, then in
https://gcc.gnu.org/gcc-15/changes.html something that COBOL FE has been
added and perhaps the limitations for this release.
See e.g. https://gcc.gnu.org/gcc-13/changes.html which mentioned the
addition of Modula-2.

	Jakub
  

> -----Original Message-----
> From: Jakub Jelinek <jakub@redhat.com>
> Sent: Tuesday, April 15, 2025 13:54
> To: Robert Dubner <rdubner@symas.com>
> Cc: 'Jeff Law' <jeffreyalaw@gmail.com>; gcc-patches@gcc.gnu.org; 'James
K.
> Lowden' <jklowden@cobolworx.com>
> Subject: Re: COBOL: Is anything stalled because of me?
> 
> On Tue, Apr 15, 2025 at 10:47:13AM -0500, Robert Dubner wrote:
> > Speaking purely casually:  I thought that that COBOL would be released
> with
> > documented limited capability.  "Yeah, it works on x86_64-linux and
> > aarch64-linux.  More to come.".  We knew that we didn't know how to
> > cross-compile, and we knew that other platforms would have to come, in
> time.
> 
> What is definitely known not to work is big endian targets, cross
> compilation from big endian hosts to little endian targets, 32-bit
> targets,
> cross compilation from 32-bit hosts, I'm afraid we can live with it for
> the
> 15 release.

I am afraid we're going to have to.

> 
> What is still missing are web page updates, the repository in that case
> is ssh://gcc.gnu.org/git/gcc-wwwdocs.git and e.g https://gcc.gnu.org/
> lists in News (left column)
> "Modula-2 front end added [2022-12-14]
> The Modula-2 programming language front end has been added to GCC.
> This front end was contributed by Gaius Mulley."
> so we want something like that for COBOL too, then in
> https://gcc.gnu.org/gcc-15/changes.html something that COBOL FE has been
> added and perhaps the limitations for this release.
> See e.g. https://gcc.gnu.org/gcc-13/changes.html which mentioned the
> addition of Modula-2.

Jim has been taking the lead on documentation.  He's eager to get to it.
He's been attending to some pressing family matters that require his
attention.

Thank you very much for the summary.

> 
> 	Jakub
  

On Tue, Apr 15, 2025 at 4:33 PM Jeff Law <jeffreyalaw@gmail.com> wrote:
>
>
>
> On 4/15/25 7:57 AM, Andreas Schwab wrote:
> >       * configure.tgt: Set LIBGCOBOL_SUPPORTED for riscv64-*-linux* with
> >       64-bit multilib.
> Can't say I'm happy with the amount of Cobol related churn at this phase
> in our cycle.  But this should be exceedingly safe.  So OK.

For the record it now builds fine on s390x-linux (big endian) as well, but
test results are not that good.  At least _some_ tests pass ...

Native configuration is s390x-ibm-linux-gnu

                === cobol tests ===


Running target unix
FAIL: cobol.dg/literal1.cob   -O0  execution test
FAIL: cobol.dg/literal1.cob   -O1  execution test
[... many FAILs stripped ...]
FAIL: cobol.dg/group2/floating-point_literals.cob   -O3 -g   output file test
FAIL: cobol.dg/group2/floating-point_literals.cob   -Os   output file test

                === cobol Summary ===

# of expected passes            2757
# of unexpected failures        342
# of expected failures          48
# of unresolved testcases       54


> jeff
>
  

On Wed, Apr 16, 2025 at 02:17:37PM +0200, Richard Biener wrote:
> On Tue, Apr 15, 2025 at 4:33 PM Jeff Law <jeffreyalaw@gmail.com> wrote:
> >
> >
> >
> > On 4/15/25 7:57 AM, Andreas Schwab wrote:
> > >       * configure.tgt: Set LIBGCOBOL_SUPPORTED for riscv64-*-linux* with
> > >       64-bit multilib.
> > Can't say I'm happy with the amount of Cobol related churn at this phase
> > in our cycle.  But this should be exceedingly safe.  So OK.
> 
> For the record it now builds fine on s390x-linux (big endian) as well, but
> test results are not that good.  At least _some_ tests pass ...
> 
> Native configuration is s390x-ibm-linux-gnu
> 
>                 === cobol tests ===
> 
> 
> Running target unix
> FAIL: cobol.dg/literal1.cob   -O0  execution test
> FAIL: cobol.dg/literal1.cob   -O1  execution test
> [... many FAILs stripped ...]
> FAIL: cobol.dg/group2/floating-point_literals.cob   -O3 -g   output file test
> FAIL: cobol.dg/group2/floating-point_literals.cob   -Os   output file test
> 
>                 === cobol Summary ===
> 
> # of expected passes            2757
> # of unexpected failures        342
> # of expected failures          48
> # of unresolved testcases       54

E.g.
    uint128 temp = (uint128)product.i64[i] * multiplier;
    product.i64[i] = *(uint64_t *)(&temp);
    overflows[i+1] = *(uint64_t *)((uint8_t *)(&temp) + 8);
(I think one of my pending patches fixed this but can submit it
independently) is at least one of the obvious spots where it works
solely for little endian.
This one particular can be obviously done as
    uint128 temp = (uint128)product.i64[i] * multiplier;
    product.i64[i] = temp;
    overflows[i+1] = temp >> 64;
But guess it is pretty much everything that works on the int256s:
typedef struct int256
  {
  union
    {
    unsigned char  data[32];
    uint64_t       i64 [4];
    uint128        i128[2];
    };
  }int256;
whether loops on it iterate with increasing or decreasing index
depends on the endianity, which bit is sign bit as well, ...

	Jakub
  

Hi Richard,

> For the record it now builds fine on s390x-linux (big endian) as well, but
> test results are not that good.  At least _some_ tests pass ...
>
> Native configuration is s390x-ibm-linux-gnu
>
>                 === cobol tests ===
>
>
> Running target unix
> FAIL: cobol.dg/literal1.cob   -O0  execution test
> FAIL: cobol.dg/literal1.cob   -O1  execution test
> [... many FAILs stripped ...]
> FAIL: cobol.dg/group2/floating-point_literals.cob   -O3 -g   output file test
> FAIL: cobol.dg/group2/floating-point_literals.cob   -Os   output file test
>
>                 === cobol Summary ===
>
> # of expected passes            2757
> # of unexpected failures        342
> # of expected failures          48
> # of unresolved testcases       54

things are similar on sparcv9-sun-solaris2.11 (once my remaining build
patches are approved):

                === cobol Summary ===

# of expected passes            2684
# of unexpected failures        446
# of expected failures          48
# of unresolved testcases       90

	Rainer