On Mar 13, 2025, at 8:04 AM, Simon Sobisch wrote:
>
> exit() allows us to "pass to the operating system" directly; but it doesn't
> directly say "success" or "fail".
>
>
> Obviously the statements
> STOP RUN WITH NORMAL STATUS 41
> and
> STOP RUN ERROR 41
>
> Should have a different resul
On Wed, 12 Mar 2025, Jakub Jelinek wrote:
> On Tue, Mar 11, 2025 at 10:06:27PM -0500, Robert Dubner wrote:
> On Linux at least when not cross-compiling, exit(1) (or this
> STOP RUN ERROR 1) will work as well, I believe the reason is for some
> bare metal targets which just don't propagate return
Am 13.03.2025 um 21:35 schrieb David Malcolm:
On Thu, 2025-03-13 at 12:11 +0100, Simon Sobisch wrote:
Thanks for your work on adding a testsuite. Can you please explain
why
you do this when a complete testsuite exists in autoconf (autotest)
format (which roots back to decade of work in GnuCOBO
On Thu, 2025-03-13 at 12:11 +0100, Simon Sobisch wrote:
> Thanks for your work on adding a testsuite. Can you please explain
> why
> you do this when a complete testsuite exists in autoconf (autotest)
> format (which roots back to decade of work in GnuCOBOL, with all
> copyrights for that alread
On Tue, 11 Mar 2025 14:40:19 +0100 (CET)
Richard Biener wrote:
> > Looking at pretty much all of the above, it seems very Fortran
> > specific with its weird diagnostic output (capital Warning:/Error:,
> > the (1) and (2) in the diagnostics with later printing of those
> > lines and the like. Unl
On Thu, 13 Mar 2025, Simon Sobisch wrote:
>
> Am 13.03.2025 um 12:49 schrieb Richard Biener:
> > On Thu, 13 Mar 2025, Sam James wrote:
> >
> >> Simon Sobisch writes:
> >>
> >>> Thanks for your work on adding a testsuite. Can you please explain why
> >>> you do this when a complete testsuite exi
Am 13.03.2025 um 12:49 schrieb Richard Biener:
On Thu, 13 Mar 2025, Sam James wrote:
Simon Sobisch writes:
Thanks for your work on adding a testsuite. Can you please explain why
you do this when a complete testsuite exists in autoconf (autotest)
format (which roots back to decade of work i
> Earlier in this discussion of a testsuite, the question came up about
> generating an error return in COBOL source code.
>
> In COBOL, "GOBACK ERROR 1." is the equivalent of a C "return 1;".
> When executed in the initial "top-level" program-id, it results in
> the value 1 being passed back to
On Thu, 13 Mar 2025, Sam James wrote:
> Simon Sobisch writes:
>
> > Thanks for your work on adding a testsuite. Can you please explain why
> > you do this when a complete testsuite exists in autoconf (autotest)
> > format (which roots back to decade of work in GnuCOBOL, with all
> > copyrights f
Simon Sobisch writes:
> Thanks for your work on adding a testsuite. Can you please explain why
> you do this when a complete testsuite exists in autoconf (autotest)
> format (which roots back to decade of work in GnuCOBOL, with all
> copyrights for that already with the FSF)?
>
I don't think any
Thanks for your work on adding a testsuite. Can you please explain why
you do this when a complete testsuite exists in autoconf (autotest)
format (which roots back to decade of work in GnuCOBOL, with all
copyrights for that already with the FSF)?
Is the existence of this in upstream [1] just u
by dejagnu.
Richard.
> Bob D.
>
> > -Original Message-
> > From: Jakub Jelinek
> > Sent: Tuesday, March 11, 2025 11:27
> > To: Richard Biener
> > Cc: Iain Sandoe ; GCC Patches > patc...@gcc.gnu.org>; jklow...@schemamania.org
> > Subject: R
> -Original Message-
> From: Jakub Jelinek
> Sent: Wednesday, March 12, 2025 03:23
> To: Robert Dubner
> Cc: Richard Biener ; Iain Sandoe
> ; GCC Patches ;
> jklow...@schemamania.org
> Subject: Re: [PATCH][v3] Simple cobol.dg testsuite
>
> On Tue, Ma
On Wed, 12 Mar 2025, Jakub Jelinek wrote:
> On Tue, Mar 11, 2025 at 10:06:27PM -0500, Robert Dubner wrote:
> > Earlier in this discussion of a testsuite, the question came up about
> > generating an error return in COBOL source code.
> >
> > In COBOL, "GOBACK ERROR 1." is the equivalent of a C "r
On Tue, Mar 11, 2025 at 10:06:27PM -0500, Robert Dubner wrote:
> Earlier in this discussion of a testsuite, the question came up about
> generating an error return in COBOL source code.
>
> In COBOL, "GOBACK ERROR 1." is the equivalent of a C "return 1;". When
> executed in the initial "top-leve
doe ; GCC Patches patc...@gcc.gnu.org>; jklow...@schemamania.org
> Subject: Re: [PATCH][v3] Simple cobol.dg testsuite
>
> On Tue, Mar 11, 2025 at 04:18:32PM +0100, Richard Biener wrote:
> > On Tue, 11 Mar 2025, Jakub Jelinek wrote:
> >
> > > On Tue, Mar 11, 2025 at 02:
On Tue, Mar 11, 2025 at 04:18:32PM +0100, Richard Biener wrote:
> On Tue, 11 Mar 2025, Jakub Jelinek wrote:
>
> > On Tue, Mar 11, 2025 at 02:45:33PM +, Iain Sandoe wrote:
> > > > The following incremental patch does this. The result has everything
> > > > needed but also some weird entries:
>
On Tue, 11 Mar 2025, Jakub Jelinek wrote:
> On Tue, Mar 11, 2025 at 02:45:33PM +, Iain Sandoe wrote:
> > > The following incremental patch does this. The result has everything
> > > needed but also some weird entries:
> > >
> > > Setting LD_LIBRARY_PATH to
> > > .:/tmp/obj/x86_64-pc-linux-g
On Tue, Mar 11, 2025 at 02:45:33PM +, Iain Sandoe wrote:
> > The following incremental patch does this. The result has everything
> > needed but also some weird entries:
> >
> > Setting LD_LIBRARY_PATH to
> > .:/tmp/obj/x86_64-pc-linux-gnu/./libgcobol/.libs:/tmp/obj/x86_64-pc-linux-gnu/./lib
> On 11 Mar 2025, at 14:30, Richard Biener wrote:
>
> On Tue, 11 Mar 2025, Richard Biener wrote:
>
>> On Tue, 11 Mar 2025, Jakub Jelinek wrote:
>>
>>> On Tue, Mar 11, 2025 at 02:40:19PM +0100, Richard Biener wrote:
OK, I've done that and amended the set of testcases with one
exerci
On Tue, 11 Mar 2025, Richard Biener wrote:
> On Tue, 11 Mar 2025, Jakub Jelinek wrote:
>
> > On Tue, Mar 11, 2025 at 02:40:19PM +0100, Richard Biener wrote:
> > > OK, I've done that and amended the set of testcases with one
> > > exercising dg-error. I had to prune the sprious
> > >
> > > cobol
On Tue, Mar 11, 2025 at 02:40:19PM +0100, Richard Biener wrote:
> OK, I've done that and amended the set of testcases with one
> exercising dg-error. I had to prune the sprious
>
> cobol1: error: failed compiling t.cob
>
> message we emit. I don't see any warnings emitted from the frontend
> an
On Tue, 11 Mar 2025, Jakub Jelinek wrote:
> On Tue, Mar 11, 2025 at 02:40:19PM +0100, Richard Biener wrote:
> > OK, I've done that and amended the set of testcases with one
> > exercising dg-error. I had to prune the sprious
> >
> > cobol1: error: failed compiling t.cob
> >
> > message we emit.
On Tue, 11 Mar 2025, Jakub Jelinek wrote:
> On Tue, Mar 11, 2025 at 01:24:12PM +0100, Richard Biener wrote:
> > The following adds a simple cobol.dg test harness, based on gfortran.dg.
> > It's invoked by make check-cobol, has a single test that should pass.
> >
> > Running /home/rguenther/src/gc
On Tue, Mar 11, 2025 at 01:24:12PM +0100, Richard Biener wrote:
> The following adds a simple cobol.dg test harness, based on gfortran.dg.
> It's invoked by make check-cobol, has a single test that should pass.
>
> Running /home/rguenther/src/gcc/gcc/testsuite/cobol.dg/dg.exp ...
> FAIL: cobol.dg/
The following adds a simple cobol.dg test harness, based on gfortran.dg.
It's invoked by make check-cobol, has a single test that should pass.
Running /home/rguenther/src/gcc/gcc/testsuite/cobol.dg/dg.exp ...
FAIL: cobol.dg/pass.cob -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops
-ftracer
26 matches
Mail list logo
