On Sun, Feb 16, 2025 at 9:20 PM Robert Dubner <rdub...@symas.com> wrote:
>
>
>
> > -----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()?
You are not required to call ggc_collect (), most frontends don't do
that directly
unless they create a lot of garbage (C++ for example does).
But once control hands off to the middle-end (when the parse_file () langhook
finished) we eventually do. The risk then is that via invocation of a langhook
the frontend looks at its data structures which might have been GCed. I've
skimmed yours and they look like they do not have any issue.
So I'd say you're fine at the moment.
Richard.
> >
> >
> > + 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
>
