How do I create a GCC source code tarball?
I have modified the source code of GCC, and I need a tarball for that modified source. My code is based on the trunk branch of the repository at git://gcc.gnu.org/git/gcc.git I attempted to execute "make dist", and have encountered the response Building a full distribution of this tree isn't done via 'make dist'. Check out the etc/ subdirectory I have been unable to locate a subdirectory name "etc/". With that as background, my question is: How do I create a source code tarball for GCC? Thanks very much for any help.
RE: How do I create a GCC source code tarball?
I had a feeling that's what the answer was going to be, but, well, I figured it couldn't hurt to ask. Especially because I hadn't before noticed the maintainer-scripts subdirectory. That alone made asking worth it. Thank you very much, Bob Dubner -Original Message- From: Andrew Pinski Sent: Tuesday, October 4, 2022 15:03 To: Robert Dubner Cc: gcc@gcc.gnu.org Subject: Re: How do I create a GCC source code tarball? On Mon, Oct 3, 2022 at 4:32 PM Robert Dubner wrote: > > I have modified the source code of GCC, and I need a tarball for that > modified source. > > My code is based on the trunk branch of the repository at > git://gcc.gnu.org/git/gcc.git > > I attempted to execute "make dist", and have encountered the response > > Building a full distribution of this tree isn't done > via 'make dist'. Check out the etc/ subdirectory > > I have been unable to locate a subdirectory name "etc/". > > With that as background, my question is: > > How do I create a source code tarball for GCC? You just tar up the source. You could use maintainer-scripts/gcc_release to make a snapshot but in the end it just does `tar xcfj file.tar.bz2 gcc` . Thanks, Andrew > > Thanks very much for any help. > >
Code generation: How to define file-scope static variables?
I am part of a team working on a COBOL front end for GCC.
By reverse engineering other front ends, I learned, some months ago, how
to create a function_decl GENERIC node that is the root of a GENERIC tree
describing an entire function.
By calling the routine cgraph_node::finalize_function() with that
function_decl, the assembly language for that function is created, and all
is well.
But now I need to be able to create the equivalent of a file-scope static
variable in C.
This C program file:
//
static int dubner_at_work = 123454321;
int main(int argc, char **argv)
{
}
//
produces, in part, this assembly language:
###
.file "ccc.c"
.text
.data
.align 4
.type dubner_at_work, @object
.size dubner_at_work, 4
dubner_at_work:
.long 123454321
.text
.globl main
.type main, @function
[...]
###
In my own GENERIC generation code, I believe that I am creating a proper
translation_unit_decl that contains the block and the vars nodes for
specifying "dubner_at_work".
But I have been unable, after several days of looking, to figure out the
equivalent of "cgraph_node::finalize_function" for a
translation_unit_decl. The resulting assembly language doesn't have a
definition for "dubner_at_work".
Can anybody describe how I can tell the downstream processing that I need
the translation_unit_decl to actually define storage?
Thanks very much,
Bob Dubner.
RE: Code generation: How to define file-scope static variables?
David, thank you very much. That looks very much like what I was hoping
for.
I'll dig into it tomorrow.
Heartfelt thanks,
Bob Dubner.
-Original Message-
From: David Malcolm
Sent: Monday, November 28, 2022 18:01
To: Robert Dubner ; gcc@gcc.gnu.org
Cc: 'Bob Dubner'
Subject: Re: Code generation: How to define file-scope static variables?
On Mon, 2022-11-28 at 15:28 -0600, Robert Dubner wrote:
> I am part of a team working on a COBOL front end for GCC.
>
> By reverse engineering other front ends, I learned, some months ago,
> how to create a function_decl GENERIC node that is the root of a
> GENERIC tree describing an entire function.
>
> By calling the routine cgraph_node::finalize_function() with that
> function_decl, the assembly language for that function is created, and
> all is well.
>
> But now I need to be able to create the equivalent of a file-scope
> static variable in C.
>
> This C program file:
>
> //
> static int dubner_at_work = 123454321; int main(int argc, char **argv)
> {
> }
> //
>
> produces, in part, this assembly language:
>
> ###
> .file "ccc.c"
> .text
> .data
> .align 4
> .type dubner_at_work, @object
> .size dubner_at_work, 4
> dubner_at_work:
> .long 123454321
> .text
> .globl main
> .type main, @function
> [...]
> ###
>
> In my own GENERIC generation code, I believe that I am creating a
> proper translation_unit_decl that contains the block and the vars
> nodes for specifying "dubner_at_work".
>
> But I have been unable, after several days of looking, to figure out
> the equivalent of "cgraph_node::finalize_function" for a
> translation_unit_decl. The resulting assembly language doesn't have a
> definition for "dubner_at_work".
>
> Can anybody describe how I can tell the downstream processing that I
> need the translation_unit_decl to actually define storage?
You might find libgccjit's gcc/jit/jit-playback.cc helpful for this, as it
tends to contain minimal code to build trees (generally
simplified/reverse-engineered from the C frontend).
playback::context::global_new_decl makes the VAR_DECL node, and such trees
are added to the jit playback::context's m_globals. In
playback::context::replay, we have:
/* Finalize globals. See how FORTRAN 95 does it in gfc_be_parse_file()
for a simple reference. */
FOR_EACH_VEC_ELT (m_globals, i, global)
rest_of_decl_compilation (global, true, true);
wrapup_global_declarations (m_globals.address(), m_globals.length());
So you'll probably want to do something similar for your globals.
Caveat: this is all reverse-engineered by me/others from the C frontend (and
I haven't touched this code in a while), so I may be missing things here.
Dave
RE: Code generation: How to define file-scope static variables?
David, for completion I am updating this message with what I've learned. I
do this in the hope that I might assist the next poor souls that find
themselves reverse-engineering front ends because they are creating their
own front end.
I claim only that this worked for me. I can't you tell what assumptions
I've been making, because I don't know what I don't know.
That said: I found that for file-static variables, the trick is to create a
var_decl for the variable with TREE_STATIC(var_decl)=1, and then to call
rest_of_decl_compilation (var_decl, true, false); // top_level is true;
at_end is false
Having done that for an integer_type var_decl with the name
"dubner_at_work", and with an initial value of 123454321, I now see this at
the very beginning of the generated .s file:
##
.file "call-scope-1.cbl"
.text
.Ltext0:
.file 0 "/home/bob/repos/gcc-cobol/gcc/cobol/failures/call-scope-1"
"call-scope-1.cbl"
.data
.align 4
.type dubner_at_work, @object
.size dubner_at_work, 4
dubner_at_work:
.long 123454321
.section.rodata [...]
##
And that's exactly what I wanted.
Thanks for your help. It was your mention of "rest_of_compilation" that
ended this marathon investigation, and I really appreciate it.
Bob Dubner
-Original Message-
From: Gcc On Behalf Of Robert
Dubner
Sent: Monday, November 28, 2022 21:55
To: David Malcolm ; gcc@gcc.gnu.org
Cc: Bob Dubner
Subject: RE: Code generation: How to define file-scope static variables?
David, thank you very much. That looks very much like what I was hoping
for.
I'll dig into it tomorrow.
Heartfelt thanks,
Bob Dubner.
-Original Message-
From: David Malcolm
Sent: Monday, November 28, 2022 18:01
To: Robert Dubner ; gcc@gcc.gnu.org
Cc: 'Bob Dubner'
Subject: Re: Code generation: How to define file-scope static variables?
On Mon, 2022-11-28 at 15:28 -0600, Robert Dubner wrote:
> I am part of a team working on a COBOL front end for GCC.
>
> By reverse engineering other front ends, I learned, some months ago,
> how to create a function_decl GENERIC node that is the root of a
> GENERIC tree describing an entire function.
>
> By calling the routine cgraph_node::finalize_function() with that
> function_decl, the assembly language for that function is created, and
> all is well.
>
> But now I need to be able to create the equivalent of a file-scope
> static variable in C.
>
> This C program file:
>
> //
> static int dubner_at_work = 123454321; int main(int argc, char **argv)
> {
> }
> //
>
> produces, in part, this assembly language:
>
> ###
> .file "ccc.c"
> .text
> .data
> .align 4
> .type dubner_at_work, @object
> .size dubner_at_work, 4
> dubner_at_work:
> .long 123454321
> .text
> .globl main
> .type main, @function
> [...]
> ###
>
> In my own GENERIC generation code, I believe that I am creating a
> proper translation_unit_decl that contains the block and the vars
> nodes for specifying "dubner_at_work".
>
> But I have been unable, after several days of looking, to figure out
> the equivalent of "cgraph_node::finalize_function" for a
> translation_unit_decl. The resulting assembly language doesn't have a
> definition for "dubner_at_work".
>
> Can anybody describe how I can tell the downstream processing that I
> need the translation_unit_decl to actually define storage?
You might find libgccjit's gcc/jit/jit-playback.cc helpful for this, as it
tends to contain minimal code to build trees (generally
simplified/reverse-engineered from the C frontend).
playback::context::global_new_decl makes the VAR_DECL node, and such trees
are added to the jit playback::context's m_globals. In
playback::context::replay, we have:
/* Finalize globals. See how FORTRAN 95 does it in gfc_be_parse_file()
for a simple reference. */
FOR_EACH_VEC_ELT (m_globals, i, global)
rest_of_decl_compilation (global, true, true);
wrapup_global_declarations (m_globals.address(), m_globals.length());
So you'll probably want to do something similar for your globals.
Caveat: this is all reverse-engineered by me/others from the C frontend (and
I haven't touched this code in a while), so I may be missing things here.
Dave
I am causing valgrind errors...
This message is a bit of a Hail Mary play. I am not asking anybody to spend any real effort on this question; I am, instead, hoping that somebody will say, "Oh, sure; you can fix that by doing so-and-so..." or "That happens when the GENERIC tree is ..." Jim Lowden and I are working on a COBOL front end for GCC. We are, at this point, pretty far along. He's been focusing on the parsing; I've been doing the code generation. Our front end is based on GCC-13; I just merged in "40e16fda0f4 - (gnu-gcc/releases/gcc-13) Daily bump." a few hours ago. The minimalist background is this: I start the process of building a function by calling build_varargs_function_type_array(). I feed the returned type_decl to build_fn_decl(), which returns a function_decl. That function_decl becomes the root of a tree that gets everything else tacked on. When I am done creating the function, I pass that function_decl to cgraph_node::finalize_function (function_decl, true); This whole process works; we've been producing executables this way for a couple of years. But I freely admit that I don't know if I am performing all necessary magical incantations properly. The COBOL program I am compiling here does absolutely nothing; it just returns. But our COBOL executables have significant overhead; it’s the nature of COBOL. There are a bunch of variables that get created, whether they are used or not, and there is boilerplate code on both entry and exit to COBOL functions. Here's the thing: when I run valgrind on the compilation -- not on the executable, but on the compiler with the COBOL front end -- I am getting a bunch of errors that look like variations of this: ==1232157== Command: /home/bob/repos/gcc-cobol/build/gcc/cobol1 playpen.cbl -quiet -dumpbase playpen.cbl -mtune=generic -march=x86-64 -ggdb -O0 -o playpen.s -cmain ==1232157== ==1232157== Conditional jump or move depends on uninitialised value(s) ==1232157==at 0xABA0CB: sparseset_bit_p (sparseset.h:146) ==1232157==by 0xABA0CB: mark_pseudo_regno_live(int) (ira-lives.cc:326) ==1232157==by 0xABBDC0: process_bb_node_lives(ira_loop_tree_node*) (ira-lives.cc:1434) ==1232157==by 0xA9E8D5: ira_traverse_loop_tree(bool, ira_loop_tree_node*, void (*)(ira_loop_tree_node*), void (*)(ira_loop_tree_node*)) (ira-build.cc:1807) ==1232157==by 0xABC6F3: ira_create_allocno_live_ranges() (ira-lives.cc:1734) ==1232157==by 0xAA038C: ira_build() (ira-build.cc:3483) ==1232157==by 0xA971BA: ira (ira.cc:5783) ==1232157==by 0xA971BA: (anonymous namespace)::pass_ira::execute(function*) (ira.cc:6106) ==1232157==by 0xB95A71: execute_one_pass(opt_pass*) (passes.cc:2651) ==1232157==by 0xB9632F: execute_pass_list_1(opt_pass*) (passes.cc:2760) ==1232157==by 0xB96341: execute_pass_list_1(opt_pass*) (passes.cc:2761) ==1232157==by 0xB9636C: execute_pass_list(function*, opt_pass*) (passes.cc:2771) ==1232157==by 0x846BA7: expand (cgraphunit.cc:1841) ==1232157==by 0x846BA7: cgraph_node::expand() (cgraphunit.cc:1794) ==1232157==by 0x847E80: output_in_order (cgraphunit.cc:2191) ==1232157==by 0x847E80: symbol_table::compile() [clone .part.0] (cgraphunit.cc:2395) Please note that the compiler is generating a good executable from the function_decl I am passing to cgraph_ node::finalize_function(). But I don't like leaving unexplained errors behind me. They tend to sneak up behind, and they often have teeth. So, here's my question to the giant brains with eidetic memories who populate this list: Can anybody give me a hint as to what I might be doing wrong, either with the tree of GENERIC tags or with the way I am asking the GCC back end to compile it, to give valgrind that particular bit of indigestion? Thank you so much for even reading this, and thanks for any hint you might have. Bob Dubner
RE: I am causing valgrind errors...
In the words of Nick Danger: "You just saved me a lot of investigative work." Thank you so much. Bob D. -Original Message- From: Jakub Jelinek Sent: Wednesday, January 10, 2024 15:51 To: Robert Dubner Cc: 'GCC Mailing List' Subject: Re: I am causing valgrind errors... On Wed, Jan 10, 2024 at 02:47:08PM -0600, Robert Dubner wrote: > Here's the thing: when I run valgrind on the compilation -- not on > the executable, but on the compiler with the COBOL front end -- I am > getting a bunch of errors that look like variations of this: > > ==1232157== Command: /home/bob/repos/gcc-cobol/build/gcc/cobol1 > playpen.cbl -quiet -dumpbase > playpen.cbl -mtune=generic -march=x86-64 -ggdb -O0 -o playpen.s -cmain > ==1232157== ==1232157== Conditional jump or move depends on > uninitialised value(s) > ==1232157==at 0xABA0CB: sparseset_bit_p (sparseset.h:146) > ==1232157==by 0xABA0CB: mark_pseudo_regno_live(int) (ira-lives.cc:326) > ==1232157==by 0xABBDC0: process_bb_node_lives(ira_loop_tree_node*) That is normal and not a bug. If you want to avoid that, you need to configure the compiler with --enable-valgrind-annotations (and have valgrind development installed before you configure/build). Jakub
New feature -fdump-gimple-nodes
I have not contributed to GCC before, so I am not sure how to go about it. So, I am letting you know what I want to do, so that I can get advice on the best way to do it. I have read https://gcc.gnu.org/contribute.html, and I have Jim Lowden and I have been developing a COBOL front end for GCC. He's primarily been parsing the language. It's been my task to generate the GENERIC/GIMPLE trees for the parsed code. We've been working at this for a couple of years. We have reached the point where we want to start submitting patches for the community to evaluate. I figured I would start small, where "small" means mainly one new source code file of 1,580 lines.
RE: New feature -fdump-gimple-nodes
Oh, crap. This is *not* an auspicious beginning. This message fragment was sent from Outlook, which does not have a good working relationship with the e-mail handler my company uses. Please ignore this while I painfully reconstruct the much longer message that those two programs managed to lose, dammit. Bob Dubner. From: Robert Dubner Sent: Tuesday, February 13, 2024 14:01 To: 'GCC Mailing List' Subject: New feature -fdump-gimple-nodes I have not contributed to GCC before, so I am not sure how to go about it. So, I am letting you know what I want to do, so that I can get advice on the best way to do it. I have read https://gcc.gnu.org/contribute.html, and I have Jim Lowden and I have been developing a COBOL front end for GCC. He's primarily been parsing the language. It's been my task to generate the GENERIC/GIMPLE trees for the parsed code. We've been working at this for a couple of years. We have reached the point where we want to start submitting patches for the community to evaluate. I figured I would start small, where "small" means mainly one new source code file of 1,580 lines.
New feature: -fdump-gimple-nodes (once more, with feeling)
I have not contributed to GCC before, so I am not totally sure how to go about it. So, I am letting you know what I want to do, so that I can get advice on a good way to do it. I have read https://gcc.gnu.org/contribute.html, and I have reviewed the Gnu Coding Standards and the GCC additional coding standards, so I have some idea of what's needed. But there is a gulf between theory and practice, and I am hoping for guidance. Jim Lowden and I have been developing a COBOL front end for GCC. He's primarily been parsing the language. It's been my task to generate the GENERIC/GIMPLE trees for the parsed code. We've been working at this for a couple of years. We have reached the point where we want to start submitting patches for the community to evaluate. I figured I would start small, where "small" means mainly one new source code file of 1,580 lines. When I first started trying to generate GIMPLE trees to implement functions, it became clear to me that I needed to be able to reverse-engineer known good trees generated by the C front end. Oh, I could see what other front ends were doing in their source code. But I didn't know what the goal was. I wanted to see not just individual nodes, but how they all related to each other. There didn't seem to be any such functionality in GCC. I found a routine in print-tree.cc which printed out a single node, but I needed to understand the entire tree of nodes for a function. And I very quickly got tired -- very tired -- of trying to figure out the relationships between nodes, and I wanted more information than the print-tree routines were providing. So, I created the gcc/dump-gimple-nodes.cc source code, which implements the dump_gimple_nodes() function, which is controlled by the new -fdump-gimple-nodes GCC command-line option. That option hooks into the top of the gimplify_function_tree() function in gcc/gimplify.cc. The dump_gimple_nodes() function does a depth-first walk of the specified function_decl, outputting each node once in a readable format. Each node gets an arbitrary identifying number. There are two output files; the first, "func_name.nodes", is pure text. After I got tired of endlessly searching through the text file for the next node of interest, I created the "func_name.nodes.html" file, which is the same information with internal hyperlinks between the nodes. Here are the first two nodes of a typical simple function: ***This is NodeNumber0 (0x7f12e13b0d00) NodeNumber0 tree_code: function_decl tree_code_class: tcc_declaration base_flags: static public type: NodeNumber1 function_type name: NodeNumber6410 identifier_node "main" context: NodeNumber107 translation_unit_decl "bigger.c" source_location: bigger.c:7:5 uid: 3663 initial(bindings): NodeNumber6411 block machine_mode: QI(15) align: 8 warn_if_not_align: 0 pt_uid: 3663 raw_assembler_name: NodeNumber6410 identifier_node "main" visibility: default result: NodeNumber6412 result_decl function(pointer): 0x7f12e135d508 arguments: NodeNumber6413 parm_decl "argc" saved_tree(function_body): NodeNumber6417 statement_list function_code: 0 function_flags: public no_instrument_function_entry_exit ***This is NodeNumber1 (0x7f12e13b3d20) NodeNumber1 tree_code: function_type tree_code_class: tcc_type machine_mode: QI(15) type: NodeNumber2 integer_type address_space:0 size(in bits): NodeNumber55 uint128 8 size_unit(in bytes): NodeNumber12 uint64 1 uid: 1515 precision: 0 contains_placeholder: 0 align: 8 warn_if_not_align: 0 alias_set_type: -1 canonical: NodeNumber1 function_type main_variant: NodeNumber1 function_type values: NodeNumber6408 tree_list *** Note how even when an attribute points to another node, e.g., arguments: NodeNumber6413 parm_decl "argc" the output routine goes down another level or two in an attempt to make it more meaningful. The attribute points just to NodeNumber6413, but the output shows that node to be a parm_decl, and there is additional code that recognizes that a parm_decl has an identifier_node with the value "argc". An example of a complete dump is available at https://www.dubner.com/main.nodes.html. The C source code that generated it is available at the end of https://cobolworx.com/pages/dump-gimple-nodes.html I found this feature to be absolutely necessary when figuring out how working front ends built valid GIMPLE trees for functions. I am hopeful other developers can see the utility. Does this require any further discussion? Or is my next step to start developing the series of patches that will create the dump-gimple-nodes source code, and that will modify Makefile.in, gimplify.cc, and common.opt to incorporate it? Thanks so much for any suggestions and guidance, Bob Dubner
RE: New feature: -fdump-gimple-nodes (once more, with feeling)
I have thought about a graphical representation more than once. Heck, the
connections between nodes is one of the things I needed to know in the
first place. And certainly the information necessary is all there in the
output I generate; I have drawn by hand pieces of the tree connections
many times.
But it doesn't seem to me to scale.
A candidate for the absolute minimally sized executable program one can
write in C and compile with GCC is
void main(){} /* I didn't say it would do anything *useful* */
The generic tree for that program has in excess of fifty nodes.
#include
void main(){printf("hello, world\n");}
has in excess of 4,800 nodes because stdio.h was brought in. Without a
plotter that draws on the sides of buildings or on football pitches (you'd
sit in the stands with binoculars to read the results), it's difficult for
me to envision how the graphical representation could be useful. I don't
claim my imagination should be the limiting factor. On the other hand, I
don't think the compiler should be generating that directly, anyway.
(I've managed to distract myself. Now I want to build a wheeled robot
that wanders around a football pitch drawing with colored chalk dust.)
My current takeaway from these responses -- thank you so much!,
incidentally -- is that whatever utility I have created here would be
enhanced by JSON (one and a half "votes", so far) or YAML (half a vote)
output.
Once the tree were available in JSON, then separate utilities to take that
output and display it graphically would be straightforward.
Okay then. I'll change the naming from "*gimple*" to "*generic*" as more
accurate, and I'll generate JSON in addition to the other two files.
Thanks again.
-Original Message-
From: Dimitar Dimitrov
Sent: Wednesday, February 14, 2024 11:31
To: Robert Dubner
Cc: 'GCC Mailing List'
Subject: Re: New feature: -fdump-gimple-nodes (once more, with feeling)
On Tue, Feb 13, 2024 at 01:46:11PM -0600, Robert Dubner wrote:
...
> An example of a complete dump is available at
> https://www.dubner.com/main.nodes.html. The C source code that
> generated it is available at the end of
> https://cobolworx.com/pages/dump-gimple-nodes.html
>
Hyperlinked text is useful. But I would love a graphical visualization
even more, e.g. via either Graphviz or Plantuml.
Regards,
Dimitar
Legal assignment forms for GCC
I anticipate making contributions to GCC on an ongoing basis, and according to https://gcc.gnu.org/contribute.html, there are some forms that need to be filled out by me and my employer for ".assignment.for all future changes, and an employer disclaimer.". I hereby request those forms. Thanks very much, Bob Dubner
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?
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: Call to builtin_decl_explicit (BUILT_IN_EXIT), is optimized away.
Thank you. I will implement that hook. And I'll see about that data
definition.
I could try to explain how RETURN-CODE became __gg___11_return_code6, and
why I defined it as unsigned char __gg__data_return_code[2] = {0,0}; But I
have a rule that I try to follow, which is that when I am starting to bore
myself, I stop talking.
Thank you very much for the information about the hook, and thanks for a
little bit of insight into how to see what the compiler is doing.
Bob D.
> -Original Message-
> From: Richard Biener
> Sent: Friday, April 4, 2025 09:50
> To: Robert Dubner
> Cc: GCC Mailing List
> Subject: Re: COBOL: Call to builtin_decl_explicit (BUILT_IN_EXIT), is
> optimized away.
>
> On Fri, Apr 4, 2025 at 3:35 PM Richard Biener
> wrote:
> >
> > On Fri, Apr 4, 2025 at 3:06 PM Robert Dubner wrote:
> > >
> > > This program exhibits the behavior when compiled with -O2, -O3 and -OS
> > >
> > > PROGRAM-ID. PROG.
> > > PROCEDUREDIVISION.
> > > MOVE 1 TO RETURN-CODE
> > > STOP RUN.
> >
> > Hmm, the call to exit() is still in the program.
> >
> >0x0040114a <-358>: movswl 0x250f(%rip),%edi#
> > 0x403660 <__gg__data_return_code>
> >0x00401151 <-351>: mov%dx,(%rax)
> > => 0x00401154 <-348>: call 0x4010b0
> >
> > $edi is 0 here. It looks like the store to __gg__data_return_code via
> > the move to (%rax)
> > and the load from it got interchanged due to aliasing issues possibly.
> >
> > It works when compiling with -O2 -fno-strict-aliasing, so apparently
> > your override
> > which you said was present does not work. I can't find it, after all.
> >
> > You want to implement the LANG_HOOKS_POST_OPTIONS hook and
> > do
> >
> > flag_strict_aliasing = 0;
> >
> > therein.
>
> Oh, and the actual problem is of course
>
> *(unsigned short *) (__gg___11_return_code6.data + (unsigned long)
> ((sizetype) D.260 * 1)) = D.259;
> ..pssr_retval = (signed int) __gg__data_return_code;
>
> where __gg__data_return_code is a global variable but
> __gg___11_return_code6 is something
> weird of type cblc_field_type_node and I nowhere see the .data field
> of it stored to (but it maybe is,
> via pointer arithmetic again - who knows - it's not mentioned anywhere
> else in the .original dump,
> so it's likely coming from libgcobol? So is __gg__data_return_code it
> seems.
>
> OK, so you are storing a short but reading from a unsigned char
> declaration. Since the
> declaration __gg__data_return_code is just 1 byte the 2-byte store
> cannot possibly alias it.
>
> Richard.
>
> > Richard.
> >
> > >
> > > > -Original Message-
> > > > From: Richard Biener
> > > > Sent: Friday, April 4, 2025 03:02
> > > > To: Robert Dubner
> > > > Cc: GCC Mailing List
> > > > Subject: Re: COBOL: Call to builtin_decl_explicit (BUILT_IN_EXIT),
> is
> > > > optimized away.
> > > >
> > > > On Fri, Apr 4, 2025 at 12:17 AM Robert Dubner
> wrote:
> > > > >
> > > > > The COBOL compiler has this routine:
> > > > >
> > > > > void
> > > > > gg_exit(tree exit_code)
> > > > > {
> > > > > tree the_call =
> > > > > build_call_expr_loc(location_from_lineno(),
> > > > > builtin_decl_explicit (BUILT_IN_EXIT),
> > > > > 1,
> > > > > exit_code);
> > > > > gg_append_statement(the_call);
> > > > > }
> > > > >
> > > > > I have found that when GCOBOL is used with -O2, -O3, or -Os, the
> call to
> > > > > gg_exit() is optimized away, and the intended exit value is lost,
> and I
> > > > > end up with zero.
> > > > >
> > > > > By changing the routine to
> > > > >
> > > > > void
> > > > > gg_exit(tree exit_code)
> > > > > {
> > > > > tree args[1] = {exit_code};
> > > > > tree function = gg_get_function_address(INT, "exit");
> > > > > tree the_call = build_call_array_loc (location_from_lineno(),
> > > > > VOID,
> > > > > function,
> > > > > 1,
> > > > > args);
> > > > > gg_append_statement(the_call);
> > > > > }
> > > > >
> > > > > the call is not optimized away, and the generated executable
> behaves as
> > > > > expected.
> > > > >
> > > > > How do I prevent the call to gg_exit() from being optimized away?
> > > >
> > > > I don't see anything wrong here, so the issue must be elsewhere.
> > > > Do you have a COBOL testcase that shows the exit() being optimized?
> > > >
> > > > >
> > > > > Thanks!
> > > > >
COBOL: Call to builtin_decl_explicit (BUILT_IN_EXIT), is optimized away.
The COBOL compiler has this routine:
void
gg_exit(tree exit_code)
{
tree the_call =
build_call_expr_loc(location_from_lineno(),
builtin_decl_explicit (BUILT_IN_EXIT),
1,
exit_code);
gg_append_statement(the_call);
}
I have found that when GCOBOL is used with -O2, -O3, or -Os, the call to
gg_exit() is optimized away, and the intended exit value is lost, and I
end up with zero.
By changing the routine to
void
gg_exit(tree exit_code)
{
tree args[1] = {exit_code};
tree function = gg_get_function_address(INT, "exit");
tree the_call = build_call_array_loc (location_from_lineno(),
VOID,
function,
1,
args);
gg_append_statement(the_call);
}
the call is not optimized away, and the generated executable behaves as
expected.
How do I prevent the call to gg_exit() from being optimized away?
Thanks!
RE: COBOL: Call to builtin_decl_explicit (BUILT_IN_EXIT), is optimized away.
This program exhibits the behavior when compiled with -O2, -O3 and -OS
PROGRAM-ID. PROG.
PROCEDUREDIVISION.
MOVE 1 TO RETURN-CODE
STOP RUN.
> -Original Message-
> From: Richard Biener
> Sent: Friday, April 4, 2025 03:02
> To: Robert Dubner
> Cc: GCC Mailing List
> Subject: Re: COBOL: Call to builtin_decl_explicit (BUILT_IN_EXIT), is
> optimized away.
>
> On Fri, Apr 4, 2025 at 12:17 AM Robert Dubner wrote:
> >
> > The COBOL compiler has this routine:
> >
> > void
> > gg_exit(tree exit_code)
> > {
> > tree the_call =
> > build_call_expr_loc(location_from_lineno(),
> > builtin_decl_explicit (BUILT_IN_EXIT),
> > 1,
> > exit_code);
> > gg_append_statement(the_call);
> > }
> >
> > I have found that when GCOBOL is used with -O2, -O3, or -Os, the call to
> > gg_exit() is optimized away, and the intended exit value is lost, and I
> > end up with zero.
> >
> > By changing the routine to
> >
> > void
> > gg_exit(tree exit_code)
> > {
> > tree args[1] = {exit_code};
> > tree function = gg_get_function_address(INT, "exit");
> > tree the_call = build_call_array_loc (location_from_lineno(),
> > VOID,
> > function,
> > 1,
> > args);
> > gg_append_statement(the_call);
> > }
> >
> > the call is not optimized away, and the generated executable behaves as
> > expected.
> >
> > How do I prevent the call to gg_exit() from being optimized away?
>
> I don't see anything wrong here, so the issue must be elsewhere.
> Do you have a COBOL testcase that shows the exit() being optimized?
>
> >
> > Thanks!
> >
RE: COBOL: Call to builtin_decl_explicit (BUILT_IN_EXIT), is optimized away.
I stated that poorly. After I generate the GENERIC, and I hand the tree
over to the middle end, it is the call to BUILT_IN_EXIT that seems to be
disappearing.
Everything I describe here is occurring with a -O0 build of GCC and
GCOBOL.
> -Original Message-
> From: Robert Dubner
> Sent: Thursday, April 3, 2025 18:16
> To: 'GCC Mailing List'
> Cc: Robert Dubner
> Subject: COBOL: Call to builtin_decl_explicit (BUILT_IN_EXIT), is
> optimized away.
>
> The COBOL compiler has this routine:
>
> void
> gg_exit(tree exit_code)
> {
> tree the_call =
> build_call_expr_loc(location_from_lineno(),
> builtin_decl_explicit (BUILT_IN_EXIT),
> 1,
> exit_code);
> gg_append_statement(the_call);
> }
>
> I have found that when GCOBOL is used with -O2, -O3, or -Os, the call to
> gg_exit() is optimized away, and the intended exit value is lost, and I
> end up with zero.
>
> By changing the routine to
>
> void
> gg_exit(tree exit_code)
> {
> tree args[1] = {exit_code};
> tree function = gg_get_function_address(INT, "exit");
> tree the_call = build_call_array_loc (location_from_lineno(),
> VOID,
> function,
> 1,
> args);
> gg_append_statement(the_call);
> }
>
> the call is not optimized away, and the generated executable behaves as
> expected.
>
> How do I prevent the call to gg_exit() from being optimized away?
>
> Thanks!
RE: COBOL: Call to builtin_decl_explicit (BUILT_IN_EXIT), is optimized away.
I will try again. First, the explicit call to "exit" is also being
optimized away.
Second, grepping indicates I am the only one in GCC trying to use
BUILT_IN_EXIT.
So, let me rephrase:
What GENERIC do I have to create that will do the equivalent of calling
exit() in a C program?
Thanks.
> -Original Message-
> From: Gcc On Behalf Of
Robert
> Dubner
> Sent: Thursday, April 3, 2025 18:19
> To: GCC Mailing List
> Subject: RE: COBOL: Call to builtin_decl_explicit (BUILT_IN_EXIT), is
> optimized away.
>
> I stated that poorly. After I generate the GENERIC, and I hand the tree
> over to the middle end, it is the call to BUILT_IN_EXIT that seems to be
> disappearing.
>
> Everything I describe here is occurring with a -O0 build of GCC and
> GCOBOL.
>
> > -Original Message-
> > From: Robert Dubner
> > Sent: Thursday, April 3, 2025 18:16
> > To: 'GCC Mailing List'
> > Cc: Robert Dubner
> > Subject: COBOL: Call to builtin_decl_explicit (BUILT_IN_EXIT), is
> > optimized away.
> >
> > The COBOL compiler has this routine:
> >
> > void
> > gg_exit(tree exit_code)
> > {
> > tree the_call =
> > build_call_expr_loc(location_from_lineno(),
> > builtin_decl_explicit (BUILT_IN_EXIT),
> > 1,
> > exit_code);
> > gg_append_statement(the_call);
> > }
> >
> > I have found that when GCOBOL is used with -O2, -O3, or -Os, the call
to
> > gg_exit() is optimized away, and the intended exit value is lost, and
I
> > end up with zero.
> >
> > By changing the routine to
> >
> > void
> > gg_exit(tree exit_code)
> > {
> > tree args[1] = {exit_code};
> > tree function = gg_get_function_address(INT, "exit");
> > tree the_call = build_call_array_loc (location_from_lineno(),
> > VOID,
> > function,
> > 1,
> > args);
> > gg_append_statement(the_call);
> > }
> >
> > the call is not optimized away, and the generated executable behaves
as
> > expected.
> >
> > How do I prevent the call to gg_exit() from being optimized away?
> >
> > Thanks!
COBOL: A call to builtin_decl_explicit (BUILT_IN_EXIT) is being optimized away
RE: COBOL: Call to builtin_decl_explicit (BUILT_IN_EXIT), is optimized away.
Jose,
I appreciate the attempt. But using the same
#define ATTR_NORETURN_NOTHROW_LIST (ECF_NORETURN|ECF_NOTHROW)
as found in gcc/builtins.def make no difference.
Thanks, though.
Bob D.
> -Original Message-
> From: Jose E. Marchesi
> Sent: Thursday, April 3, 2025 19:27
> To: Robert Dubner
> Cc: GCC Mailing List
> Subject: Re: COBOL: Call to builtin_decl_explicit (BUILT_IN_EXIT), is
> optimized away.
>
>
> Nah, I see ECF_TM_PURE despite the name seems to be doing something very
> different than ECF_CONST and ECF_PURE:
>
> if (flags & ECF_PURE)
> DECL_PURE_P (decl) = 1;
> ...
> if ((flags & ECF_TM_PURE) && flag_tm)
> apply_tm_attr (decl, get_identifier ("transaction_pure"));
>
> Still, you may try to use the same ECF attributes than
gcc/builtins.def..
>
> > Perhaps it is because you are using ECF_TM_PURE when defining the
> > built-in in cobol1.cc:
> >
> > #define ATTR_TMPURE_NORETURN_NOTHROW_LEAF_COLD_LIST
> (ECF_TM_PURE|ECF_NORETURN|ECF_NOTHROW|ECF_LEAF|ECF_COLD)
> >
> > [...]
> > gfc_define_builtin ("__builtin_exit", ftype, BUILT_IN_EXIT,
> > "exit", ATTR_TMPURE_NORETURN_NOTHROW_LEAF_COLD_LIST);
> >
> > In gcc/builtins.def:
> >
> > DEF_LIB_BUILTIN(BUILT_IN_EXIT, "exit", BT_FN_VOID_INT,
> ATTR_NORETURN_NOTHROW_LIST)
> >
> > So you want ECF_NORETURN and ECF_NOTHROW.
> >
> >> I stated that poorly. After I generate the GENERIC, and I hand the
> tree
> >> over to the middle end, it is the call to BUILT_IN_EXIT that seems to
> be
> >> disappearing.
> >>
> >> Everything I describe here is occurring with a -O0 build of GCC and
> >> GCOBOL.
> >>
> >>> -Original Message-
> >>> From: Robert Dubner
> >>> Sent: Thursday, April 3, 2025 18:16
> >>> To: 'GCC Mailing List'
> >>> Cc: Robert Dubner
> >>> Subject: COBOL: Call to builtin_decl_explicit (BUILT_IN_EXIT), is
> >>> optimized away.
> >>>
> >>> The COBOL compiler has this routine:
> >>>
> >>> void
> >>> gg_exit(tree exit_code)
> >>> {
> >>> tree the_call =
> >>> build_call_expr_loc(location_from_lineno(),
> >>> builtin_decl_explicit (BUILT_IN_EXIT),
> >>> 1,
> >>> exit_code);
> >>> gg_append_statement(the_call);
> >>> }
> >>>
> >>> I have found that when GCOBOL is used with -O2, -O3, or -Os, the
call
> to
> >>> gg_exit() is optimized away, and the intended exit value is lost,
and
> I
> >>> end up with zero.
> >>>
> >>> By changing the routine to
> >>>
> >>> void
> >>> gg_exit(tree exit_code)
> >>> {
> >>> tree args[1] = {exit_code};
> >>> tree function = gg_get_function_address(INT, "exit");
> >>> tree the_call = build_call_array_loc (location_from_lineno(),
> >>> VOID,
> >>> function,
> >>> 1,
> >>> args);
> >>> gg_append_statement(the_call);
> >>> }
> >>>
> >>> the call is not optimized away, and the generated executable behaves
> as
> >>> expected.
> >>>
> >>> How do I prevent the call to gg_exit() from being optimized away?
> >>>
> >>> Thanks!
