> -----Original Message-----
> From: David Malcolm <dmalc...@redhat.com>
> Sent: Saturday, February 15, 2025 23:39
> To: James K. Lowden <jklow...@schemamania.org>; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] COBOL 9/15 532K api: GENERIC interface
>
> On Sat, 2025-02-15 at 16:02 -0500, James K. Lowden wrote:
> > From 5d53920602e234e4d99ae2d502e662ee3699978e 4 Oct 2024 12:01:22 -
> > 0400
> > From: "James K. Lowden" <jklow...@symas.com>
> > Date: Sat 15 Feb 2025 12:50:53 PM EST
> > Subject: [PATCH] 2 new 'cobol' FE files
> >
> > gcc/cobol/ChangeLog
> > * genapi.cc: New file.
> > * genapi.h: New file.
> >
>
> +static tree label_list_out_goto;
> +static tree label_list_out_label;
> +static tree label_list_back_goto;
> +static tree label_list_back_label;
>
> Any time we have a static or extern tree, I wonder if it should have a
> GTY(()) marker to mark it as a garbage collection root. Have you stress-
> tested this with the params that force a collection on every GC
> opportunity?
>
> +static std::map<program_reference_t, std::list<called_tree_t> >
> +call_targets; static std::map<tree, cbl_call_convention_t>
> +called_targets;
>
> Similarly here, but the trees in question are deep within global data
> structures that don’t know about the GC.
>
> Hopefully the GC can never run during the times when these structures are
> live,otherwise you’ve got problems…
Okay. I simply do not pretend to understand garbage collection in GCC. I
hope nobody disagrees when I state that the documentation in
gcc_internals_15.pdf is sparse.
I have run the cobol compiler's entire existing suite of test programs --
there are about 1,000 of them -- with the options
--param=ggc-min-expand=0 --param=ggc-min-heapsize=0
No errors were observed.
The internals document has section " 23.6 How to invoke the garbage
collector" wherein appears the statement "So the only way to have GGC
reclaim storage is to call the ggc_
collect function explicitly."
Well, *I* am certainly not calling ggc_collect. So, I have to ask: When
might the garbage collector run? Am I supposed to be calling ggc_collect()?
>
>
> + IF( left_side, lt_op, gg_cast(TREE_TYPE(left_side),
> integer_zero_node) )
> + {
> + if( debugging )
> + {
> + gg_printf("normal_normal_compare(): different types returning -
> 1\n",
> + NULL_TREE);
> + }
> + gg_assign( return_int, integer_minusone_node);
> + }
> + ELSE
>
> What’s with the uppercase IF and ELSE? Is this just regular control flow
> or is some kind of preprocessor magic going on?
They are sanity-preserving "preprocesser magic" to implement the GENERIC for
conditional processing. The definitions are found in gengen.h:
#define IF(a,b,c) gg_if((a),(b),(c));
#define ELSE current_function->statement_list_stack.pop_back();
#define ENDIF current_function->statement_list_stack.pop_back();
The function gg_if, in turn, builds a relational expression and puts the two
needed statement lists -- the first for "when true", the second for "when
false" -- onto a stack so that expressions can easily be appended to them.
So, if you mean by "regular control flow" ordinary C/C++ if/else processing,
no. They implement GENERIC conditional processing.
>
> + if( paragraph )
> + {
> + sprintf(ach, "%s", paragraph);
> + strcat(retval, ach);
> + }
> + strcat(retval, ".");
> + if( section )
> + {
> + sprintf(ach, "%s", section);
> + strcat(retval, ach);
> + }
> + strcat(retval, ".");
> + if( mangled_program_name )
> + {
> + strcat(retval, mangled_program_name);
> + }
> + sprintf(ach, ".%ld", current_function->program_id_number);
> + strcat(retval, ach);
> + sprintf(ach, ".%ld", deconflictor);
> + strcat(retval, ach);
>
> “ach” and “retval” are fixed-sized buffers; is all this string
> manipulation guaranteed to fit? Similarly in assembler_label.
Although there is a bit of faith involved, yes, I long ago did the
appropriate calculations to "guarantee" <cough> that the strings involved
will fit. COBOL identifiers are limited to 63 characters.
That said, there are pathological name-mangling cases that could cause those
limits to be exceeded. So, I will rewrite that code so as not to depend on
magically-sized fixed-length buffers.
[Having mentioned the pathology, I feel compelled to describe it. COBOL
identifiers are allowed to have embedded hyphens, although they cannot begin
or end with hyphens. Thus, the name
a-------------------------------------------------------------b
is legitimate. Happily, the test code I just wrote for this message shows
that my mangling algorithm expands that to something big enough to crash the
compiler. Yay! Another case for the test suite.]
Thank you.
>
> +static tree vti_array;
> +static tree vti_constructor;
>
> Do these need to be GTY marked?
>
>
> Dave
