Re: COBOL test cases
On Sat, Mar 15, 2025 at 11:02:59AM -0500, Robert Dubner wrote:
> I am struggling with the learning curves, here. I am trying to understand
> dejagnu, and I am trying to understand tcl, and I am trying to understand
> the testsuite chain of commands and files that result, somehow, in the
> programs in testsuite/cobol.dg being executed. Dealing with three new
> technologies is slowing me down considerably. I am looking for some help
> to leapfrog that.
>
> We have about 800 programs that definitively have no IP issues preventing
> their use in the GCC repository.
>
> But the vast bulk of them are based on capturing stdout and comparing that
> to a known-good file.
>
> I am completely prepared to create a test-0001.cob source code file for
> the repo. I can prepare a matching test-0001.expected-output file for the
> repo.
The normal dejagnu way is to use dg-output for that.
So, if you have test-0001.cob and test-0001.expected-output, you could do
for i in *.cob; do \
sed 's/\([].*()[]\)/\\\1/g;s/^/*> { dg-output {/;s/$/(\\n|\\r\\n|\\r)}
}/;$s/.\{12\}} }$/} }/' \
< $i.expected-output >> $i.cob; done
to turn the expected output into dg-output directives.
Maybe I've missed some characters that also need to be backslash prefixed, in
that case they'd go next to the .*() part early in the regexp.
Of course, if the output is huge, perhaps we should write some dg- directive
for specifying file with expected output and compare against that rather than
the dg-output directives.
But if it is just a couple dozens of lines, I think dg-output could be fine.
> I see the stdout from each executed program is captured in the cobol.log
> file. But it doesn't do me much good, there.
>
> Is there some way that the output of { dg-do run } can be directed to
> designated test-0001.stdout and test-0001.stderr files? If so, I can
> fairly easily add boilerplate to the end of the COBOL test program to do
> the comparison.
>
> Otherwise I am going to have start rewriting those hundreds of programs to
> somehow test themselves and produce the go/no-go response.
Jakub
RE: COBOL test cases
> -Original Message-
> From: Jakub Jelinek
> Sent: Saturday, March 15, 2025 12:58
> To: Robert Dubner ; 'GCC Mailing List'
> ; 'James K. Lowden' ;
'Richard
> Biener'
> Subject: Re: COBOL test cases
>
> On Sat, Mar 15, 2025 at 05:34:21PM +0100, Jakub Jelinek via Gcc wrote:
> > So, if you have test-0001.cob and test-0001.expected-output, you could
> > do for i in *.cob; do \ sed 's/\([].*()[]\)/\\\1/g;s/^/*> { dg-output
> > {/;s/$/(\\n|\\r\\n|\\r)} }/;$s/.\{12\}} }$/} }/' \ <
> > $i.expected-output >> $i.cob; done to turn the expected output into
> > dg-output directives.
> > Maybe I've missed some characters that also need to be backslash
> > prefixed, in that case they'd go next to the .*() part early in the
> regexp.
>
> Like ^$\ are certainly missing.
>
> Jakub
Details. Easy-peasy. I'll probably create some python scripts for doing
it in a more general way for my directory structures, where each test is
in its own directory.
And then for UAT I'll have to extract both the source code and expected
results from the .AT files. That'll just be tedious, not hard.
Additional issue, although it'll definitely be done later:
I don't see any way of separately compiling two source modules and linking
them together. I have a number of test cases involving linking together
produced-from-c.o and produced-from-cobol.o modules, because I am testing
whether they can link properly. And there are issues of cobol-to-cobol
linking, since slightly different things happen when calling another
program in a module, and calling one compiled separately.
Is there some way of doing that?
Re: COBOL test cases
> Am 15.03.2025 um 18:20 schrieb Robert Dubner :
>
>
>>
>> -Original Message-
>> From: Jakub Jelinek
>> Sent: Saturday, March 15, 2025 12:58
>> To: Robert Dubner ; 'GCC Mailing List'
>> ; 'James K. Lowden' ;
> 'Richard
>> Biener'
>> Subject: Re: COBOL test cases
>>
>>> On Sat, Mar 15, 2025 at 05:34:21PM +0100, Jakub Jelinek via Gcc wrote:
>>> So, if you have test-0001.cob and test-0001.expected-output, you could
>>> do for i in *.cob; do \ sed 's/\([].*()[]\)/\\\1/g;s/^/*> { dg-output
>>> {/;s/$/(\\n|\\r\\n|\\r)} }/;$s/.\{12\}} }$/} }/' \ <
>>> $i.expected-output >> $i.cob; done to turn the expected output into
>>> dg-output directives.
>>> Maybe I've missed some characters that also need to be backslash
>>> prefixed, in that case they'd go next to the .*() part early in the
>> regexp.
>>
>> Like ^$\ are certainly missing.
>>
>>Jakub
>
> Details. Easy-peasy. I'll probably create some python scripts for doing
> it in a more general way for my directory structures, where each test is
> in its own directory.
>
> And then for UAT I'll have to extract both the source code and expected
> results from the .AT files. That'll just be tedious, not hard.
>
> Additional issue, although it'll definitely be done later:
>
> I don't see any way of separately compiling two source modules and linking
> them together. I have a number of test cases involving linking together
> produced-from-c.o and produced-from-cobol.o modules, because I am testing
> whether they can link properly. And there are issues of cobol-to-cobol
> linking, since slightly different things happen when calling another
> program in a module, and calling one compiled separately.
>
> Is there some way of doing that?
There is dg-additional-sources for this IIRC. The LTO testsuite also compiles
and links an arbitrary number of TUs.
Richard
>
GSoC 2025: In-Memory Filesystem for GPU Offloading Tests
Hello GCC Community! I am Arijit Kumar Das, a second-year engineering undergraduate from NIAMT Ranchi, India. While my major isn’t Computer Science, my passion for system programming, embedded systems, and operating systems has driven me toward low-level development. Programming has always fascinated me—it’s like painting with logic, where each block of code works in perfect synchronization. The project mentioned in the subject immediately caught my attention, as I have been exploring the idea of a simple hobby OS for my Raspberry Pi Zero. Implementing an in-memory filesystem would be an exciting learning opportunity, closely aligning with my interests. I have carefully read the project description and understand that the goal is to modify *newlib* and the *run tools* to redirect system calls for file I/O operations to a virtual, volatile filesystem in host memory, as the GPU lacks its own filesystem. Please correct me if I’ve misunderstood any aspect. I have set up the GCC source tree and am currently browsing relevant files in the *gcc/testsuite* directory. However, I am unsure *where the run tools source files are located and how they interact with newlib system calls.* Any guidance on this would be greatly appreciated so I can get started as soon as possible! Best regards, Arijit Kumar Das. *GitHub:* https://github.com/ArijitKD *LinkedIn:* https://linkedin.com/in/arijitkd
Re: COBOL test cases
On Sat, Mar 15, 2025 at 12:20:14PM -0500, Robert Dubner wrote:
> Details. Easy-peasy. I'll probably create some python scripts for doing
> it in a more general way for my directory structures, where each test is
> in its own directory.
>
> And then for UAT I'll have to extract both the source code and expected
> results from the .AT files. That'll just be tedious, not hard.
>
> Additional issue, although it'll definitely be done later:
>
> I don't see any way of separately compiling two source modules and linking
> them together. I have a number of test cases involving linking together
> produced-from-c.o and produced-from-cobol.o modules, because I am testing
> whether they can link properly. And there are issues of cobol-to-cobol
> linking, since slightly different things happen when calling another
> program in a module, and calling one compiled separately.
>
> Is there some way of doing that?
Yes. See e.g. gcc/testsuite/gcc.dg/pr102892-{1,2}.c.
In one file you add
*> { dg-additional-sources "something-2.cob" }
and in the other either
*> { dg-do compile }
or even arrange for it to be skipped altogether.
When compiling the first test, it will just use dg-options from it
and add both the first and second test on the same command line.
The pr102892-1.c is in particular just dg-do link test (so it compiles and
links, but doesn't execute), so in testsuite/gcc/gcc.log then one can see
Executing on host: /home/jakub/src/gcc/obj36/gcc/xgcc
-B/home/jakub/src/gcc/obj36/gcc/
/home/jakub/src/gcc/gcc/testsuite/gcc.dg/pr102892-1.c
-fdiagnostics-plain-output -O3
/home/jakub/src/gcc/gcc/testsuite/gcc.dg/pr102892-2.c -dumpbase "" -lm -o
pr102892-1.exe(timeout = 300)
spawn -ignore SIGHUP /home/jakub/src/gcc/obj36/gcc/xgcc
-B/home/jakub/src/gcc/obj36/gcc/
/home/jakub/src/gcc/gcc/testsuite/gcc.dg/pr102892-1.c
-fdiagnostics-plain-output -O3
/home/jakub/src/gcc/gcc/testsuite/gcc.dg/pr102892-2.c -dumpbase -lm -o
pr102892-1.exe
PASS: gcc.dg/pr102892-1.c (test for excess errors)
Executing on host: /home/jakub/src/gcc/obj36/gcc/xgcc
-B/home/jakub/src/gcc/obj36/gcc/
/home/jakub/src/gcc/gcc/testsuite/gcc.dg/pr102892-2.c
-fdiagnostics-plain-output -O3 -S -o pr102892-2.s(timeout = 300)
spawn -ignore SIGHUP /home/jakub/src/gcc/obj36/gcc/xgcc
-B/home/jakub/src/gcc/obj36/gcc/
/home/jakub/src/gcc/gcc/testsuite/gcc.dg/pr102892-2.c
-fdiagnostics-plain-output -O3 -S -o pr102892-2.s
PASS: gcc.dg/pr102892-2.c (test for excess errors)
Jakub
gcc-14-20250315 is now available
Snapshot gcc-14-20250315 is now available on https://gcc.gnu.org/pub/gcc/snapshots/14-20250315/ and on various mirrors, see https://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 14 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-14 revision f8504e361c895b13d00e5c6a52a6cbb47fcc2a9d You'll find: gcc-14-20250315.tar.xz Complete GCC SHA256=a021f68deff2609489470fd94d275cbcf00a9e5600bdd1947dd29cead219ccbb SHA1=dde36e3cb21be49458a5e966f0f49f894b18b4b6 Diffs from 14-20250308 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-14 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: COBOL test cases
On Sat, Mar 15, 2025 at 05:34:21PM +0100, Jakub Jelinek via Gcc wrote:
> So, if you have test-0001.cob and test-0001.expected-output, you could do
> for i in *.cob; do \
> sed 's/\([].*()[]\)/\\\1/g;s/^/*> { dg-output {/;s/$/(\\n|\\r\\n|\\r)}
> }/;$s/.\{12\}} }$/} }/' \
> < $i.expected-output >> $i.cob; done
> to turn the expected output into dg-output directives.
> Maybe I've missed some characters that also need to be backslash prefixed, in
> that case they'd go next to the .*() part early in the regexp.
Like ^$\ are certainly missing.
Jakub
COBOL test cases
I am struggling with the learning curves, here. I am trying to understand
dejagnu, and I am trying to understand tcl, and I am trying to understand
the testsuite chain of commands and files that result, somehow, in the
programs in testsuite/cobol.dg being executed. Dealing with three new
technologies is slowing me down considerably. I am looking for some help
to leapfrog that.
We have about 800 programs that definitively have no IP issues preventing
their use in the GCC repository.
But the vast bulk of them are based on capturing stdout and comparing that
to a known-good file.
I am completely prepared to create a test-0001.cob source code file for
the repo. I can prepare a matching test-0001.expected-output file for the
repo.
I see the stdout from each executed program is captured in the cobol.log
file. But it doesn't do me much good, there.
Is there some way that the output of { dg-do run } can be directed to
designated test-0001.stdout and test-0001.stderr files? If so, I can
fairly easily add boilerplate to the end of the COBOL test program to do
the comparison.
Otherwise I am going to have start rewriting those hundreds of programs to
somehow test themselves and produce the go/no-go response.
Thanks.
RE: COBOL test cases
> -Original Message-
> From: Jakub Jelinek
> Sent: Saturday, March 15, 2025 12:34
> To: Robert Dubner
> Cc: 'GCC Mailing List' ; 'James K. Lowden'
> ; 'Richard Biener'
> Subject: Re: COBOL test cases
>
> On Sat, Mar 15, 2025 at 11:02:59AM -0500, Robert Dubner wrote:
> > I am struggling with the learning curves, here. I am trying to
> > understand dejagnu, and I am trying to understand tcl, and I am trying
> > to understand the testsuite chain of commands and files that result,
> > somehow, in the programs in testsuite/cobol.dg being executed.
> > Dealing with three new technologies is slowing me down considerably.
> > I am looking for some help to leapfrog that.
> >
> > We have about 800 programs that definitively have no IP issues
> > preventing their use in the GCC repository.
> >
> > But the vast bulk of them are based on capturing stdout and comparing
> > that to a known-good file.
> >
> > I am completely prepared to create a test-0001.cob source code file
> > for the repo. I can prepare a matching test-0001.expected-output file
> > for the repo.
>
> The normal dejagnu way is to use dg-output for that.
> So, if you have test-0001.cob and test-0001.expected-output, you could
do
> for i in *.cob; do \ sed 's/\([].*()[]\)/\\\1/g;s/^/*> { dg-output
> {/;s/$/(\\n|\\r\\n|\\r)} }/;$s/.\{12\}} }$/} }/' \ < $i.expected-output
>>
> $i.cob; done to turn the expected output into dg-output directives.
> Maybe I've missed some characters that also need to be backslash
prefixed,
> in that case they'd go next to the .*() part early in the regexp.
Okay. Interesting. Hang on a minute
... tried a test. It'll work.
Thanks!
>
> Of course, if the output is huge, perhaps we should write some dg-
> directive for specifying file with expected output and compare against
> that rather than the dg-output directives.
> But if it is just a couple dozens of lines, I think dg-output could be
> fine.
>
> > I see the stdout from each executed program is captured in the
> > cobol.log file. But it doesn't do me much good, there.
> >
> > Is there some way that the output of { dg-do run } can be directed to
> > designated test-0001.stdout and test-0001.stderr files? If so, I can
> > fairly easily add boilerplate to the end of the COBOL test program to
> > do the comparison.
> >
> > Otherwise I am going to have start rewriting those hundreds of
> > programs to somehow test themselves and produce the go/no-go response.
>
> Jakub
RE: COBOL test cases
> -Original Message-
> From: Jakub Jelinek
> Sent: Saturday, March 15, 2025 13:38
> To: Robert Dubner
> Cc: GCC Mailing List ; James K. Lowden
> ; Richard Biener
> Subject: Re: COBOL test cases
>
> On Sat, Mar 15, 2025 at 12:20:14PM -0500, Robert Dubner wrote:
> > Details. Easy-peasy. I'll probably create some python scripts for
> > doing it in a more general way for my directory structures, where each
> > test is in its own directory.
> >
> > And then for UAT I'll have to extract both the source code and
> > expected results from the .AT files. That'll just be tedious, not
hard.
> >
> > Additional issue, although it'll definitely be done later:
> >
> > I don't see any way of separately compiling two source modules and
> > linking them together. I have a number of test cases involving
> > linking together produced-from-c.o and produced-from-cobol.o modules,
> > because I am testing whether they can link properly. And there are
> > issues of cobol-to-cobol linking, since slightly different things
> > happen when calling another program in a module, and calling one
> compiled separately.
> >
> > Is there some way of doing that?
>
> Yes. See e.g. gcc/testsuite/gcc.dg/pr102892-{1,2}.c.
> In one file you add
> *> { dg-additional-sources "something-2.cob" } and in the other either
*>
> { dg-do compile } or even arrange for it to be skipped altogether.
> When compiling the first test, it will just use dg-options from it and
add
> both the first and second test on the same command line.
> The pr102892-1.c is in particular just dg-do link test (so it compiles
and
> links, but doesn't execute), so in testsuite/gcc/gcc.log then one can
see
> Executing on host: /home/jakub/src/gcc/obj36/gcc/xgcc -
> B/home/jakub/src/gcc/obj36/gcc/
> /home/jakub/src/gcc/gcc/testsuite/gcc.dg/pr102892-1.c-fdiagnostics-
> plain-output -O3
/home/jakub/src/gcc/gcc/testsuite/gcc.dg/pr102892-2.c
> -dumpbase "" -lm -o pr102892-1.exe(timeout = 300)
> spawn -ignore SIGHUP /home/jakub/src/gcc/obj36/gcc/xgcc -
> B/home/jakub/src/gcc/obj36/gcc/
> /home/jakub/src/gcc/gcc/testsuite/gcc.dg/pr102892-1.c
-fdiagnostics-plain-
> output -O3 /home/jakub/src/gcc/gcc/testsuite/gcc.dg/pr102892-2.c
-dumpbase
> -lm -o pr102892-1.exe
> PASS: gcc.dg/pr102892-1.c (test for excess errors)
> Executing on host: /home/jakub/src/gcc/obj36/gcc/xgcc -
> B/home/jakub/src/gcc/obj36/gcc/
> /home/jakub/src/gcc/gcc/testsuite/gcc.dg/pr102892-2.c-fdiagnostics-
> plain-output -O3 -S -o pr102892-2.s(timeout = 300)
> spawn -ignore SIGHUP /home/jakub/src/gcc/obj36/gcc/xgcc -
> B/home/jakub/src/gcc/obj36/gcc/
> /home/jakub/src/gcc/gcc/testsuite/gcc.dg/pr102892-2.c
-fdiagnostics-plain-
> output -O3 -S -o pr102892-2.s
> PASS: gcc.dg/pr102892-2.c (test for excess errors)
>
> Jakub
Excellent. Thank you and Richard both. This is very much appreciated.
This has gone from daunting to just a learning exercise very quickly. And
although I am working on "Test Test Case Number Zero" by hand, I am going
to be able to build tools to handle the multitudes.
This is exciting!
Bob D.
Re: COBOL test cases
On Mär 15 2025, Jakub Jelinek via Gcc wrote: > Of course, if the output is huge, perhaps we should write some dg- directive > for specifying file with expected output and compare against that rather than > the dg-output directives. Perhaps something similar to regexp_diff in binutils/testsuite/lib/binutils-common.exp. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: GSOC interest in Extend the static analysis pass, [OpenACC]
Kaaden Ruman via Gcc writes: > Hello, my name is Kaaden and I am a student at the University of Alberta in > Canada. I am interested in pursuing the "Extend the static analysis pass" > idea as a medium size project. > > I have cloned and built gcc and ran the testsuite and would like a > nudge in the direction of what to look at next. I searched in bugzilla > for terms like "OpenACC" and "static analysis". Bug 118627 looks like > it might be a good candidate for a first patch. Any guidance on the > former or suggestions for files that would be most helpful for me to > read and try to understand would be greatly appreciated. I am open to > any input. Note that PR118627 is a report *using* static analysis (not GCC's static analyzer, either). It's not a bug for enhancing GCC's static analyzer (-fanalyzer). I'm afraid I don't have suggestions for this, though, and I defer to Thomas and David. > > Also, I noticed that this link in the project idea description is dead: > https://mid.mail-archive.com/875yp9pyyx.fsf@euler.schwinge.homeip.net > > More about me, I have previous experience in compilers (and working in > large codebases) from interning at IBM where I worked on their COBOL > compiler and binary optimiser (mostly backend). I have also taken a > compiler course with a project of an LLVM based compiler (mostly > frontend). > > I also have taken and enjoyed a GPU programming course so extending > checks for OpenACC caught my eye. In that course we mainly worked with > CUDA but discussed other tools such as OpenACC as well, so I have some > familiarity. > > Thanks, > Kaaden
bounds checking / VLA types
Hi John, (I changed gcc-patches to gcc) Am Samstag, dem 15.03.2025 um 00:22 -0400 schrieb John McCall: > > On 14 Mar 2025, at 15:18, Martin Uecker wrote: > > > > ... > > > > But let's rephrase my point a bit more precisely: One could take > > > > a strict subset of C that includes variably modified types but > > > > obviously has to forbid a lot other things (e.g. arbitrary pointer > > > > conversions or unsafe down-casts and much more) and make this a > > > > memory-safe language with dependent types. This would also > > > > require adding run-time checks at certain places where there > > > > is now UB, in particular where two VLA types need to be compatible. > > Mmm. You can certainly subset C to the point that it’s memory-safe, but > > it wouldn’t really be anything like C anymore. It would not look like most legacy C code. But a subset of C would still be C and it would be compilable by existing compilers (but without safety) and can seaminglessly integrated into existing projects. > > As long as C has a heap, > > I don’t see any path to achieving temporal safety without significant > > extensions to the language. Yes, for temporal memory you would need some extensions. But the first step for me would be to make this C subset very restrictive and then incrementally extend it later. There are applications where a restricted subset would help, e.g. because dynamic memory allocation is not allowed anyway or because one is interested to only check some critical part of a program and all memory management is outside of this part. > > But if we’re just talking about spatial safety, > > then sure, that could be a lot closer to C today. Yes. > > Is that your vision, then, that you’d like to see the same sort of checks > > that -fbounds-safety does, but you want them based firmly in the language > > as a dynamic check triggered by pointer type conversion, with bounds > > specified using variably-modified types? It’s a pretty elegant vision, and > > I can see the attraction. The VLA accesses are bounds-checked via UBsan: https://godbolt.org/z/9q1f8Wx51 And for the pointer assignment checks I have a complete patch for GCC that adds this. > > It has some real merits, which I’ll get to below. > > I do see at least two significant challenges, though. > > The first and biggest problem is that, in general, array bounds can only be > > expressed on a pointer value if it’s got pointer to array type. Most C array > > code today works primarily with pointers to elements; programmers just use > > array types to create concrete arrays, and they very rarely use pointers to > > array type at all. There are a bunch of reasons for that: > > * Pointers to arrays have to be dereferenced twice: (*ptr)[idx] instead > > of ptr[idx]. > > * That makes them more error-prone, because it is easy to do pointer > > arithmetic at the wrong level, e.g. by writing ptr[idx], which will > > stride by multiples of the entire array size. That may even pass the > > compiler without complaint because of C’s laxness about conversions. This is not a problem in my experience because type checking catches this - not the indexing, but that the result type is wrong for what you do afterwards. > > * Keeping the bound around in the pointer type is more work and doesn’t do > > anything useful right now. It already gives you bounds checking with UBSan! It also makes the bounds and their relations visible to human readers or other tools. Another advantage is that one can read the bound back from the pointer type via sizeof (and in the future _Countof). I am coming more from the numerical side, where having the bounds in multi-dimensional arrays is helpful. > > * A lot of C programmers dislike nested declarator syntax and can’t > > remember > > how it works. Those of us who can write it off the top of our heads are > > quite atypical. I think they would get used to it when seeing it used elsewhere. But I agree many might not want to use it and it would also not help legacy code. So I would also very much like to see improvements in bounds checking that it is implicit or based on other annotations as in -fbounds-safety and BDOS-based checking. > > Now, there is an exception: you can write a parameter using an array type, > > and it actually declares a pointer parameter. You could imagine using this > > as a syntax for an enforceable array bound for arguments, although the > > committee did already decide that these bounds were meaningless without > > static. The plan is to strengthen the meaning of it. If the stricter mode is opt-in, this is not a major problem. > > Unfortunately, you can’t do this in any other position and still > > end up with just a pointer, so it’s not helpful as a general syntax for > > associating bounds with pointers. In existing code. I argee that there we should use attribute-based annotations. > > The upshot is that this isn’t really something people can just adopt by > > a
