https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119455
--- Comment #3 from rguenther at suse dot de <rguenther at suse dot de> --- > Am 23.05.2025 um 16:54 schrieb jklowden at gcc dot gnu.org > <gcc-bugzi...@gcc.gnu.org>: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119455 > > James K. Lowden <jklowden at gcc dot gnu.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Severity|normal |enhancement > Assignee|unassigned at gcc dot gnu.org |rdubner at gcc dot > gnu.org > CC| |jklowden at gcc dot gnu.org > > --- Comment #2 from James K. Lowden <jklowden at gcc dot gnu.org> --- >> the GCC COBOL frontend seems to use something like a type/object descriptor >> for variables and constants and dispatching to the GCC COBOL runtime for all >> operations. That means the static types are not exposed to GCCs >> optimizations > > Bob can speak to this better than I can, but your observation apt. We always > knew that when our work was scrutinized by GCC, there would be (ahem) > suggestions. All to the good! I fully expected that GCC feedback would > improve the FE, and COBOL's unique requirements may likewise induce changes to > the middle-end. > > I can say for sure it won't be difficult to change, because I won't be doing > any of the work. > > Yes, COBOL is statically typed. But it has a much richer type system than any > other language I know of. GCCs type system is currently powerful enough for Ada which does have some of COBOLs powers here, in terms of manual layout and domain specification of types. But it might not even come close to handle all things COBOL types can do. Note that Ada lowers parts of this, exposing a more general representation to GCC, applying extra constraints via generated code. I think what this bug requests is mostly a way to optimize the control part of algorithms implemented, not so much operation on actual data. Thus the Frontend should elide library calls for types where the operations can be performed with types the GCC middle-end can handle natively. > One way to look at it is that each variable (in > COBOL, "data item") has a unique type. Much COBOL data is organized in > hierarchical records, sometimes with fixed offsets that are not word-aligned. > > Numeric types, besides binary integers and floating point, it has a > fixed-point > decimal type of arbitrary size with an implied decimal point, and the sign can > be represented in several ways. For all arithmetic of all types, rounding can > be done in 7 ways for any single operation. There is also Packed Decimal, > similar to BCD at a high level, but different in detail. > > Known as "Numeric Display", decimal types use one character for each digit. > Because it's a commonly used feature, the COBOL FE has its own optimized > computation routines for it. > > There are "edited" types (alphanumeric and numeric) that have embedded static > data interleaved. Character strings have known size and encoding, not > something fobbed off to the runtime and subject to the environment. MOVE > CORRESPONDING exists in no other language I know of. > > COBOL variables have metadata that is used at runtime. Certain alphanumeric > positions can be constrained to be digits. The initial value, if supplied, > can > be restored via INITIALIZE. A variable can have an enumerated domain. Unlike > C, it's not restricted to integers, and one value in the domain can be defined > as "false". > > How all this is defined in GENERIC is a years-long improvisation. Memory is > allocated per-record, and individual data items are pointers into that record. > IIUC, the concern is how those data-items are defined. It may that some are > ripe for optimization if defined differently and others cannot be, and still > other could be, if GENERIC/Gimple were enhanced. > > The instant case of moving 'a' to a single-byte variable does look like a > textbook example of "ripe". We will give it a look. > > -- > You are receiving this mail because: > You are on the CC list for the bug.
