Re: FE C++ requirement
On Wed, 8 May 2024 21:40:44 +0200 Jakub Jelinek wrote: > Perhaps you don't link cobol1 with the correct make variables > as other FEs are linked? First, thank you for the careful answer. It allowed me to trace through the machinery. And I confirmed that it works, usually. The Make-lang.in for the cobol1 compiler was modelled on the one for fortran and, indeed, it's usually built statically linked to libstdc++: $ g++ -no-pie -g3 -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables [...] -fno-common -DHAVE_CONFIG_H -no-pie -static-libstdc++ -static-libgcc attribs.o -o cobol1 [...] As we would expect, ldd(1) reports that output is not linked to libstdc+ +.so. Where things appear to go awry is when I try to take a shortcut: $ make -C build install where "build" is the top of the gcc build tree, where we'll eventually find build/gcc/cobol1. When done that way, cobol1 sometimes ends up dependent on libstdc++.so. I haven't tried to find out why that is, whether it's something we're doing, or something more general. It does seem like more gets built than needs to be when I do that. For now, at least I understand what the expected outcome is. The compiler should be statically linked to the C++ library. When it's not, something went wrong. --jkl
FE C++ requirement
/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.32' not found (required by build-O2/gcc/cobol1 The above error comes from ldd(1). I'm experimenting with what's minimally needed to install gcc when configured with --languages=cobol. Until this week, we always used --languages=c++,cobol. But, I said, why not just whatever C++ compiler and library happens to be on hand? Like the rest of gcc, our cobol1 compiler uses C++. The above message suggests to me that there's an assumption being made somewhere, that because the COBOL front end is being built, and uses C++, that the C++ library should be built and installed, too. 1. Is my understanding correct? 2. Is the dependency intentional, or can it be be defeated? >From my point of view, we need a reasonably modern libstdc++.so, but by no means do we need one that could be built in-tree. --jkl
warnings and warnings
I have two simple questions, I hope! 1. Is there a set of flags that, when compiling gcc, is meant to produce no warnings? I get a surfeit of warnings with my particular favorite options. 2. Are the libgcc functions warning_at() and error_at() intended for use by all front-ends? As of now, our COBOL front-end formats its own messages with fprintf(3). I would like to emulate normal gcc behavior, where warnings can be turned on and off, and (especially) elevated to errors with -Werror. I'm guessing we'd gain access to that functionality automatically if we engaged with the standard diagnositic framework, if there is one. I'm a little doubtful these are the keys to that kingdom, though. The comments regarding location_t and the location database seem very C-specific. --jkl
Re: Sourceware mitigating and preventing the next xz-backdoor
On Mon, 1 Apr 2024 17:06:17 +0200 Mark Wielaard wrote: > We should discuss what we have been doing and should do more to > mitigate and prevent the next xz-backdoor. Since we're working on a compiler, "On Trusting Trust" comes to mind. Russ Cox posted some thoughts last year that might be applicable. https://research.swtch.com/nih On a different tack, ISTM it might also be possible to use quantitative methods. AIUI the xz attack was discovered while investigating exorbitant power consumption. Could the compiler's power consumption be measured over some baseline, perhaps on a line-by-line basis? If so, each new commit could be power-measured, and deemed acceptable if it's within some threshold, perhaps 10%. That's a guess; over time we'd learn how much variation to expect. As a public organization, any would-be attacker would obviously know what we're doing, and would know to keep his attack under the threshhold. That makes his job harder, which would have the effect of encouraging him to look elsewhere. --jkl
Re: Request for Direction.
On Fri, 15 Dec 2023 14:43:22 -0500 "David H. Lynch Jr. via Gcc" wrote: > Right now I am just focused on some means to deliver support. Hi David, My colleague Bob Dubner and I have been extending GCC every day for the last two years. I wonder if we might be of some use to you. I only faintly hope our project can benefit from your work. We're adding a Cobol front end to GCC. Cobol has built-in sort functions, both on disk and in memory, and a rich data-description language. There is more potential there than might seem at first blush, and I would welcome the opportunity to explain in detail if you're interested. If your objective is simply to extend C to support content addressable memory, then we might still be of some help. I don't know anything, really, about the C front-end, but Bob has experience getting Generic to generate code. He might be able to answer some of your questions, if nothing else. Let me know what you think. Kind regards, --jkl
Re: issue: unexpected results in optimizations
On Tue, 12 Dec 2023 09:39:58 +0100 David Brown via Gcc wrote: > If you have fixed the immediate problems in the code, add the > "-fsanitize=undefined" flag before running it. That will do run-time > undefined behaviour checks. I would like to understand that better, for reasons you might guess. -fsanitize is described under Program Instrumentation Options, but much of the terminology seems to C, and some of the options are documented to work only with C or C++. If it applies to the generated code irrespective of the front-end, then could the options be described in terms of Generic? For example, signed-integer-overflow, bounds, and bounds-strict would seem to be useful in any language that defines integers and arrays. I also wonder if "integer" includes _Float128. "-fsanitize" appears only once in the Internals document, under bool TARGET_MEMTAG_CAN_TAG_ADDRESSES If I knew when contructs were needed for particular options to work, I could add them to the documentation. --jkl
gcc cobol status
When in November we turn back our clocks, then naturally do programmers' thoughts turn to Cobol, its promise, and future. At last post, nine months ago, we were working our way through the NIST CCVS/85 test suite. I am pleased to report that process is complete. As far as NIST is concerned, gcobol is a Cobol compiler. For those keeping score at home, we're at 656 terminal symbols and 1636 yacc rules. Cobol is nothing if not a big language. NIST CCVS/85 includes: Basic Cobol grammar Intrinsic functions IPC support, in the form of called by and calling C modules I/O for sequential, indexed, and relative-addressed files Sorting and merging of files Compiler Directing Facility functions The NIST tests can be downloaded and executed using an included Makefile. They comprise 8846 tests in 348 files. We have adopted the ISO 2023 Cobol specification as the standard we're writing to. gcobol also includes a few extensions to support syntax that is specific to IBM and MicroFocus compilers, for features that are widely used or still in use but since dropped by ISO. Significant effort went, and continues to go, into a relatively new Cobol feature, not part of the 1985 standard: handling Exception Conditions. Good examples are scarce, though, and we would be pleased to work with anyone whose code depends on correct EC handling, or who would like to use it and cannot because their compiler doesn't support it. Cobol also has quite requirements for numerical precision. To that end, gcobol now uses the C _Float128 datatype. The precision of intermediate computed results grows as needed, and overflows and truncation are signified (if enabled) through the EC mechanism. The switch to _Float128 was a third pass over the computation statements (ADD, SUBTRACT, MULTIPLY, DIVIDE, and COMPUTE) and the lucky user benefits from our hard-won experience, in the form of much better performance. Of course, no battle plan survives first contact with the enemy. As the gcobol community grows and new erroneous code is encountered, the compiler's error messages continue to improve. Plans. We want the direction of gcobol to be influenced by user interest. Every Cobol shop relies on different variations and extensions to the language. Early adopters have an opportunity to make their voices heard and needs met. Operators are standing by. On deck for 2024: * User acceptance testing * support for EXEC SQL * modifications consequent to GCC review * updated gdb support Home page: https://www.cobolworx.com/pages/cobforgcc.html Packages: https://gitlab.cobolworx.com/COBOLworx/gcc-cobol/-/packages/2 Repository, and Issue tracker: https://gitlab.cobolworx.com/COBOLworx/gcc-cobol/-/tree/master+cobol We are: * James K. Lowden Front of the front-end: lexer and parser * Robert Dubner Back of the front-end: adapting Cobol to Gimple Thank you for you kind attention. --jkl
Re: More C type errors by default for GCC 14
On Wed, 10 May 2023 13:00:46 +0200 David Brown via Gcc wrote: > or that function calls always act as a > memory barrier. Hi David, [off list] Could you tell me more about that, and where I could read about it? I've only been using C since 1985, so just a beginner, I guess. ;-) As a matter of C semantics, I can't see how a function call could be anything but a memory barrier. The arguments have to be resolved before the function is called, else there's no value to provide. And the function has to determine its return value prior to returning. I can imagine in the face of multithreading that things become murky, but that's the nature of multithreading as commonly implemented. It's outside C semantics. I'm genuinely curious what it is your referring to, in case my understanding is out of date. --jkl
Re: More C type errors by default for GCC 14
On Tue, 9 May 2023 23:45:50 +0100 Jonathan Wakely via Gcc wrote: > On Tue, 9 May 2023 at 23:38, Joel Sherrill wrote: > > We are currently using gcc 12 and specifying C11. To experiment > > with these stricter warnings and slowly address them, would we need > > to build with a newer C version? > > No, the proposed changes are to give errors (instead of warnings) for > rules introduced in C99. GCC is just two decades late in enforcing the > C99 rules properly! This, it seems to me, is the crux of the question. Code that does not conform to the standard should produce an error. Code that can be compiled correctly, per the specification, but might not be what the user intended, is a candidate for a warning. If the proposed changes catch true errors -- not just dubious constructs -- that were previously allowed, well, that's the price of progress. That's the compiler getting better at distinguishing between code conformant and not. Section 2.1 "C Language" of the manual states that, with no option specified on the command line, the default standard is -std=gnu17. Part of the proposal IIUC is to treat undeclared functions as an error. Function prototypes have been required afaik since c99. If that's correct, then letting them pass without error is a mistake for -std=c99 and above. As to the default, is anyone suggesting that gnu17 -- i.e., c17 with GNU extensions -- includes ignoring missing function prototypes? That to me would be an odd definition of "extension". The user who has old code that does not meet the c99 standard but Just Works nonetheless has a direct route to compiling that code without complaint: -std=c90. It says so right there in the fine manual. It's that simple. The code is either in spec and compiles without error, or it is not and does not. The only debate is over what "the spec" is, and what warnings the user might want for conforming code. --jkl
Re: "file name" vs "filename"
On Sat, 15 Apr 2023 00:00:44 +0200 (CEST) Gerald Pfeifer wrote: > On Mon, 2 Apr 2018, Joseph Myers wrote: > > See the GNU Coding Standards: > > > > Please do not use the term ``pathname'' that is used in Unix > > documentation; use ``file name'' (two words) instead. We use the > > term ``path'' only for search paths, which are lists of directory > > names. > > Based on this it appears "file name" is the one to follow, so I went > ahead and documented this at > https://gcc.gnu.org/codingconventions.html with a patch at > https://gcc.gnu.org/pipermail/gcc-cvs-wwwdocs/2023/010210.html . May it please the court, I suggest there's a difference between "filename" and "file name", and that the former should be preferred because it's clearer. A "file name" is the file's name. It is a property of a file, like the inode or size. The name exists (or not) regardless of whether we know what it is. A "filename" is a syntactic element, the thing itself, a string of characters. It is supplied as input or rendered as output. One advantage to using "filename" when discussing syntax is that it is unmistakably a single token. Viz, -aux-info FILENAME and source files to create an output filename and The filename may be absolute None of those examples is improved by substituting "file name". At best, the meaning is unchanged. At worst, it's misleading. It's not obvious to me that the the distinction I'm drawing is universally recognized. At the same time, it's not obvious that the gcc documentation would be improved by strict adherence to that distinction, or by pedantically choosing to use one or the other. But, if one is to be chosen for uniformity, "filename" is less apt to confuse. --jkl
Re: [GSOC] getting "gdb: unrecognized option '-dumpdir'' while trying to debug gcc using gdb
On Mon, 20 Mar 2023 15:08:41 -0400 David Malcolm via Gcc wrote: > Another way to invoke cc1 under the debugger is to add "-v" to the gcc > invocation to get verbose output, and then see what command-line it > uses to invoke cc1, and then run: > > gdb --args ARGS_OF_CC1_INVOCATION I find it easiest just to invoke the compiler proper. $ echo $cobol1 [...]/build/gcc/cobol1 $ gdb --args $cobol1 -oo foo.cbl That sets the compiler driver aside, and lets me work directly on the compiler. Of course, I'm concerned with just one language, and just one compiler. If your concern crosses languages, I'd imagine the -wrapper technique would be easier. --jkl
#include cobol
To the GCC community and GCC Steering Committee: Greetings! We at COBOLworx would like GCC to consider our gcobol front-end for inclusion in the GCC project. We would like to contribute it to the GNU Toolchain and have it merged into GCC. We believe our work is further along than any previous GCC Cobol effort. As you may know, we have been working on the project for over a year. Much of the last 9 months have been devoted to testing for correctness. The compiler now passes the core module of the NIST CCVS-85 test suite. Although not ready for production use by any means, we expect to pass all relevant aspects of CCVS-85 later this year. Old as it is, Cobol is far from dead. Estimates run into billions of lines written, with millions more added each year, even today. But -- because there has never been a free, fully functional, source-to-machine compiler for it -- Cobol remains largely locked behind expensive, proprietary walls. GCC can change that. Cobol also offers a window into what was and might yet be. In Seibel's "Coders at Work", Fran Allen put it this way: "There was a debate between Steve Johnson, of Bell Labs, who were supporting C, and one of our people, Bill Harrison The nubbin of the debate was Steve's defense of not having to build optimizers anymore because the programmer would take care of it." and "By 1960, we had a long list of amazing languages: Lisp, APL, Fortran, COBOL, Algol 60. These are higher-level than C. We have seriously regressed since C developed." Modern hardware, and GCC's 100 optimization passes, are evidence Fran Allen was right. Cobol, with its 2 dozen high-level verbs and integrated I/O, provides a theoretical opportunity to surpass even C's performance in its problem domain, because the compiler has more information and more leeway. As a technical matter, to be sure we are far from achieving that goal. It is, as I said, an opportunity. As we hone our skills, we look forward to learning together with others to make it a reality. Signed, Marty Heyman, James K. Lowden, Robert Dubner
Re: [GSoC][Static Analyzer] Some questions and request for a small patch to work on
On Wed, 22 Feb 2023 14:03:36 + Jonathan Wakely via Gcc wrote: > I think GCC trunk won't even build on M2, you need Iain Sandoe's > out-of-tree patches. https://gitlab.cobolworx.com/COBOLworx/gcc-cobol/-/jobs/2822 We've been building on aarch64 based on GCC trunk since December. --jkl
gcobol: a progress report
Home Page: https://cobolworx.com/pages/cobforgcc.html
Repository: https://gitlab.cobolworx.com/COBOLworx/gcc-cobol
Packages:
https://gitlab.cobolworx.com/COBOLworx/gcc-cobol/-/packages/2
The GCC Cobol aspirant is now 16 months old, and pupating. If Cobol's
60-year history were an hour, gcobol is now one minute old.
When last we met our intrepid duo, gcobol had compiled 100 programs,
perhaps 1000 lines of Cobol. Today we're pleased to announce a
milestone: success with "nucleus" and "intrinsic function" modules of
the NIST CCVS-85 test suite.
The Cobol Compiler Validation System
"tests for conformity to the American National Standard (ANSI
Document Reference X3.23-1985) and the standard of the International
Organisation for Standardisation (ISO Document Reference
ISO-1989-1985)".
It comprises 14 modules totaling 391 programs, with each program
implementing many tests.
We addressed ourselves just to the 95 programs in "nucleus" module,
which tests the core language features. We can report 100% of 4381
tests succeed for 93 of those 95. That's 8744 lines of Cobol. We
ignored the remaining 2 programs because they test obsolete features.
If you want a Cobol compiler that supports features that were obsolete
in 1985, you probably have a card reader handy.
We have, in other words, a verified, working Cobol-85 compiler.
We add new NIST tests to the "ok" column as we progress. The packages
above are created via CI/CD for each successful commit, and pass all
tests.
How big is it? 50,000 lines, give or take:
$ cloc gcc/cobol/*.{cc,h,l,y} libgcobol/*.cc
36 text files.
36 unique files.
0 files ignored.
github.com/AlDanial/cloc v 1.90 T=0.09 s
(419.0 files/s, 710127.6 lines/s)
Language files blankcomment code
C++ 19 5330 6546 32332
yacc 2 1147367 8744
C/C++ Header 14598892 3010
lex 1312 95 1637
SUM: 36 7387 7900 45723
But wait! There's more!
https://cobolworx.com/pages/cobforgcc.html
We're extending gdb for Cobol, too. While there's more work to do, the
important stuff is there: set break points, jump over PERFORM
statements, and examine data.
For your administrative convenience, we have packaged both gcobol and
gdb-gcobol as binary Ubuntu packages. The gcobol package contains
*only* the gcobol files; installing it will not disturb your gcc
installation.
Each package is based on the master branch in the git repository, the
better to facilitate eventual inclusion in GCC and gdb.
Plans.
We are continuing with other NIST verification modules. If using git,
you can track our progress with "make -C nist/ report".
We hope the future direction of gcobol will soon be influenced by user
interest. While an ISO standard Cobol compiler is a good foundation,
every Cobol shop relies on different variations and extensions to the
language. Early adopters have an opportunity to make their voices
heard and needs met.
For the immediate future, we're planning:
* (more) conditional compilation
* improvements to EBCDIC and Unicode support
* better error messages
* support for EXEC SQL
* modifications consequent to GCC review
We are:
* James K. Lowden
Front of the front-end: lexer and parser
* Robert Dubner
Back of the front-end: adapting Cobol to Gimple
Thank you for you kind attention.
--jkl
P.S. As a reminder, gcobol is a Cobol compiler based on gcc. It should
not be confused with GnuCOBOL
(https://savannah.gnu.org/projects/gnucobol). That project is a Cobol
translator: it compiles Cobol to C, and invokes gcc to produce
executable code.
Re: access to include path in front end
On Thu, 1 Dec 2022 17:14:31 + (UTC)
Michael Matz wrote:
> > 3. Correct the entries in the default_compilers array. Currently I
> > have in cobol/lang-specs.h:
> >
> > {".cob", "@cobol", 0, 0, 0},
> > {".COB", "@cobol", 0, 0, 0},
> > {".cbl", "@cobol", 0, 0, 0},
> > {".CBL", "@cobol", 0, 0, 0},
> > {"@cobol",
> > "cobol1 %i %(cc1_options) %{!fsyntax-only:%(invoke_as)}",
> > 0, 0, 0},
>
> It misses %(cpp_unique_options) which was the reason why your -I
> arguments weren't passed to cobol1.
If I understood you correctly, I don't need to modify gcc.cc. I only
need to modify cobol/lang-specs.h, which I've done. But that's
evidently not all I need to do, because it doesn't seem to work.
The last element in the fragment in cobol/lang-specs.h is now:
{"@cobol",
"cobol1 %i %(cc1_options) %{!fsyntax-only:%(invoke_as)} "
"%(cpp_unique_options) ",
0, 0, 0},
(using string constant concatenation). That's the only change I made,
so far, because everything we said (AIUI) boiled down to, "just add
cpp_unique_options to your spec string".
> You would just your new %(cobol_options), or simply '%{v} %{I*}'
> directly in addition to cc1_options.
I didn't do that. IIUC, the 2nd element in the struct can be a string
constant or the address of a char* variable. So, I chose a string
constant.
Getting wiser with age, I used -### to dump the cobol1 command
line. It appears to be consistent with observed behavior: when I run
under gdb and stop at the cobol1::main function, argc is 14, and argv
does not include the -I option.
The -### output reports the cobol1 command line (as 14 strings,
exactly) on line 10. In additon to what was supplied (by me, invoking
gcobol), it shows:
-quiet
-dumpdir o- -dumpbase csytst10.cbl
-dumpbase-ext .cbl
"-main=gcc/cobol/prim/samples/CUBES/cobol/csytst10.cbl"
"-mtune=generic"
"-march=x86-64"
-o /tmp/ccLYrc6D.s
The -main I can explain later if it matters. The others are magic I
don't understand and don't think matter, but I show them so you know.
Note that I'm invoking gcobol from the build tree, using -B (among
others) to make it DTRT.
I see the -B and -I options, and others, with their arguments, contained
in COLLECT_GCC_OPTIONS on lines 9 and 11. I guess that represents an
environment string? Or, anyway, a string that holds the options that
will be passed to collect2?
The contents of COLLECT_GCC_OPTIONS appear to be a superset of the
options supplied on the cobol1 command line.
It would seem the single change I made is less than the minimum
required, but I confess I've lost track of why anything more is
needed.
--jkl
Re: access to include path in front end
On Wed, 30 Nov 2022 15:58:40 + (UTC)
Michael Matz wrote:
Hi Michael,
First, thanks for a great answer, and to Jonathan for reminding me of
what documentation we do have for this. I'm now using -I in cobol1, but
I'm not getting it from gcobol. I guess I need to extend the spec
options, but I'm puzzled because so far I've been able to dodge that
bullet.
> E.g. look in gcc.cc for '@c' (matching the file extension) how that
> entry uses '%(cpp_unique_options)', and how cpp_unique_options is
> defined for the specs language:
>
> INIT_STATIC_SPEC ("cpp_unique_options", _unique_options),
>
> and
>
> static const char *cpp_unique_options =
> "%{!Q:-quiet} %{nostdinc*} %{C} %{CC} %{v} %@{I**} %{P} %I\
Please tell me if this looks right and complete to you:
1. Add an element to the static_specs array:
INIT_STATIC_SPEC ("cobol_options", _options),
2. Define the referenced structure:
static const char *cobol_options = "%{v} %@{I**}"
or just
static const char *cobol_options = "%{v} %@{I*}"
because I don't know what -F does, or if I need it.
I'm using "cobol_options" instead of "cobol_unique_options" because the
options aren't unique to Cobol, and because only cpp seems to have
unique options.
I'm including %{v} against the future, when the cobol1 compiler
supports a -v option.
3. Correct the entries in the default_compilers array. Currently I
have in cobol/lang-specs.h:
{".cob", "@cobol", 0, 0, 0},
{".COB", "@cobol", 0, 0, 0},
{".cbl", "@cobol", 0, 0, 0},
{".CBL", "@cobol", 0, 0, 0},
{"@cobol",
"cobol1 %i %(cc1_options) %{!fsyntax-only:%(invoke_as)}",
0, 0, 0},
That last one is a doozy. Is it even slightly right? IIUC, I should at
least remove
%{!fsyntax-only:%(invoke_as)}
because I don't need the options from the invoke_as string in gcc.cc.
(Actually, we do have a syntax-only feature. IIUC, the we could define
our own command-line options to invoke it, and use our own static
variable cobol_foo (instead of invoke_as) to pass those options to
cobol1 when -fsyntax-only is used. Or, alternatively, we could just
honor -fsyntax-only literally, like any other option.)
That would still leave me with too much, because cobol1 ignores most of
the options cc1 accepts. What would you do?
I don't understand the relationship between default_compliers and
static_specs.
I have made no special provision for "compiler can deal with
multiple source files", except that cobol1 accepts multiple source
files on the command line, and iterates over them. If that's enough,
then I'll set compiler::combinable to 1.
I'm trying those 3 today. I'd like to get it right, as long as I'm in
the neighborhood. :-)
+++
As I mentioned, for a year I've been able to avoid the Specs Language,
apparently because some things happen by default. The options defined
in cobol/lang.opt are passed from gcobol to cobol1. The value of the
-findicator-column option is available (but only if the option starts
with "f"; -indicator-column doesn't work). cobol1 sees the value of
-fmax-errors.
Is that because I'm using gcobol, and not "gcc -x cobol" ? If not, how
do I know what's passed by default, and what needs specification?
Thanks again for your guidance. I doubt I'll ever really understand
what's going on at this level, but I'm glad to plug in the right magic
values.
Regards,
--jkl
Re: access to include path in front end
On Wed, 30 Nov 2022 08:49:35 +0100 Richard Biener wrote: > > I would like to use the -I option to pass the names of copybook > > directories to the cobol front end. A bit of exploration yesterday > > left me with the sense that the -I argument, in C at least, is not > > passed to the compiler, but to the preprocessor. Access to > > -fmax-errors I think I've figured out, but -I is a mystery. > > The frontends have access to the set of passed options via the > option processing langhooks (and there's also global_options > and global_options_set), -I would be the OPT_I option (currently > only enabled for some frontends, you can add that in your > language specific .opt file). The set of include directories is > not in any way special here. Thanks for clearing that up for me, Richard. I somehow got the impression that the langhooks were needed only for adding options specific to the language. --jkl
access to include path in front end
I don't understand how to access in a front end the arguments to the -I option on the command line. Cobol has a feature similar to the C preprecessor, known as the Compiler Directing Facility (CDF). The CDF has a COPY statement that resembles an #include directive in C, and shares the property that COPY names a file that is normally found in a "copybook" which, for our purposes, is a directory of such files. The name of that directory is defined outside the Cobol program. I would like to use the -I option to pass the names of copybook directories to the cobol front end. A bit of exploration yesterday left me with the sense that the -I argument, in C at least, is not passed to the compiler, but to the preprocessor. Access to -fmax-errors I think I've figured out, but -I is a mystery. I'm a little puzzled by the status quo as I understand it. Unless I missed it, it's not discussed in gccint. ISTM ideally there would be some kind of getopt(3) processing, and the whole set of command-line options captured in an array of structures accessible to any front end. Is that not the case and, if not, why not? Many thanks. --jkl
Re: How do I create a GCC source code tarball?
On Tue, 4 Oct 2022 12:03:12 -0700 Andrew Pinski via Gcc wrote: > > Building a full distribution of this tree isn't done > > via 'make dist'. Check out the etc/ subdirectory ... > 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` . If I may, the error message would be improved by making it shorter: > Building a full distribution of this tree isn't done > via 'make dist'. since that at least would be accurate! But why not just make it work again? Change the dist target in Makefile.in: dist: tar xcfj file.tar.bz2 gcc or dist: $(srcdir)/maintainer-scripts/gcc_release $(RELEASE_OPTS) where RELEASE_OPTS has some simple default. The user wishing to know more can inspect the script to determine what options to use. I spent several hours looking for information on how to do this. I wasn't counting on a decade of misdirection. It's not mentioned anywhere that I could find in the source tree or the wiki. I missed maintainer-scripts among the 75 files because it wasn't in upper case, where I expect to find developer information. If the process of generating nightly tarballs is documented, I missed that, too. I'm happy to open a PR or submit a patch. --jkl
Re: [RFC] Using std::unique_ptr and std::make_unique in our code
On Mon, 11 Jul 2022 20:32:07 -0400
David Malcolm via Gcc wrote:
> Perhaps, but right now I prefer to spell out std::unique_ptr, since
> I'm not as comfortable with C++11 as I might be.
Hi David, [off list]
You might be interested to know Bjarne Stroustrup observes that during
the development of C++, new features tend to be introduced with long,
explicit syntax that no one can misinterpret. Then, over time, as the
community becomes comfortable with the new idea (and tired of typing
it) it gets briefer.
"The prefix template<...> syntax was not my first choice when I
designed templates. It was forced upon me by people worried that
templates would be misused by less competent programmers, leading to
confusion and errors. The heavy syntax for exception handling, try
{ ... } catch( ... ) { ... }, was a similar story [Stroustrup 2007]. It
seems that for every new feature many people demand a LOUD syntax to
protect against real and imagined potential problems. After a while,
they then complain about verbosity."
https://dl.acm.org/doi/pdf/10.1145/3386320?utm_source=ZHShareTargetIDMore_medium=social_oi=54584470929408
At the very least, you have company. :-)
Regards,
--jkl
Re: passing command-line arguments, still
I'm collecting my remarks in one reply here, hopefully for easier
reading. I want to offer my thanks, and also my assessment of the
situation as I understand it. My critique is intended as purely
constructive.
I understand vaguely what's going on. I'll use the -findicator-column=
form because it works, and because that's today's convention.
I assert:
1. I did define my option to take an argument.
2. The documentation is incomplete and incorrect.
3. The naming convention is inconsistent.
Joseph Myers answered my question directly:
> The .opt files control how options are parsed, both in the driver and
> in the compiler programs such as cc1. Passing of options from the
> driver to those compiler programs is based on specs in the driver; -f
> options are passed down because of the use of %{f*} in cc1_options
> (and the use of %(cc1_options) in the specs for most languages).
IIUC, it's not lang.opt, but lang-specs.h:
$ nl lang-specs.h
1 /* gcc-src/gcc/config/lang-specs.h */
2 {".cob", "@cobol", 0, 1, 0},
3 {".COB", "@cobol", 0, 1, 0},
4 {".cbl", "@cobol", 0, 1, 0},
5 {".CBL", "@cobol", 0, 1, 0},
6 {"@cobol", "cobol1 %i %(cc1_options) %{!fsyntax-only:%
(invoke_as)}", 0, 1, 0},
The contents of that file are unspecified. gccint.info says only:
> 'lang-specs.h'
> This file provides entries for 'default_compilers' in 'gcc.c'
> which override the default of giving an error that a compiler for that
> language is not installed.
I implemented the above by cargo-cult coding. Until today I had no
idea what line 6 does. Now I have only some idea.
I don't understand where the %{} syntax is processed. I'm guessing
autoconf, which on this project is above my pay grade.
On Thu, 17 Mar 2022 17:39:00 +
Jonathan Wakely wrote:
> You didn't define your option to take an argument in the
> .opt file.
Of course I did:
indicator-column
Cobol Joined Separate UInteger Var(indicator_column) Init(0)
IntegerRange(0, 8)
Column after which Region B begins
That says it takes an argument -- either Joined or Separate -- as an
unsigned integer initialized to 0 in the range [0,8]. Not only that,
the option is accepted by gcobol; it's just not passed to the
compiler.
The documentation does not say an option taking an argument must
end in "=" and does not recommend it begin with "f".
Marek Polacek wrote:
> > 2. GCC accepts a -fno- alternative, automatically
>
> Right, unless it's RejectNegative.
Yes, and RejectNegative is an instrument of accidental complexity. If
-f options automatically accept a -fno- option, then a -f option that
does not want a -fno- alternative should use another name. There are
25 other lowercase letters available.
> > 3. The "f" stands for "flag", meaning on/off.
>
> It does stand for "flag", and it looks like at some point in ancient
> history if was on/off, but then came options like -falign-loops=N.
IME, someone made a mistake in the past, and that mistake is now
becoming mistaken for a standard. I don't mind living with some cruft
-- it's not as though gcc is unique in that regard -- but at the same
time I see no reason to vernerate it or perpetuate it.
In plain words, if we recognize that -f indicates an on/off switch,
let's use it that way, deprecate those that don't, and not add new -f
options that take arguments.
One last, final minor point,
> > By default, all options beginning with "f", "W" or "m" are
> > implicitly assumed to take a "no-" form.
> > More accurate would be
> > to say a "fno-" form is automatically accepted or generated.
>
> TBH, I don't see how that would be any more accurate that what we
> have now.
Words matter. No one is assuming anything, a fact hidden by the passive
"are implicitly assumed". I don't know whether -fno- is "accepted" or
"generated", or by what. I'm suggesting the agent be stated and the
verb not hide what's happening. I would say:
"Options beginning with "f", "W" or "m" also
a "no-" form generated by .
I wouldn't say "by default", because it's not by default. It's by
design, and the alternative is contained in the next sentence.
I've said my peace. I have my option, and I'll use it. If any of my
assertions is incorrect, I'd be happy to be corrected. I hope my
observations, if correct, contribute to better option names and
documentation.
My thanks for your help. I'm sure we've spent more time on
this corner of configuration than we expected to.
--jkl
Re: passing command-line arguments, still
On Wed, 16 Mar 2022 14:45:33 -0400 Marek Polacek wrote: Hi Marek, > Let's avoid -f-foo; use -ffoo instead, like the rest of GCC. Sure. I hadn't noticed the distinction. > > In cobol/lang.opt, I have: > > > > indicator-column > > Make this 'findicator-column='. Does that help? Yes, with that change, the option & argument are passed. But ... why? It's my understanding that the -f prefix indicates a switch, meaning: 1. It does not take an argument 2. GCC accepts a -fno- alternative, automatically 3. The "f" stands for "flag", meaning on/off. My option has no alternative, if you'll pardon the pun. I don't see the point in confusing the user by suggesting it does. The fine manual says: By default, all options beginning with "f", "W" or "m" are implicitly assumed to take a "no-" form. This form should not be listed separately. If an option beginning with one of these letters does not have a "no-" form, you can use the 'RejectNegative' property to reject it. That isn't quite accurate. The "no-" form isn't "implicitly assumed". What would "explicitly assumed" look like, btw? More accurate would be to say a "fno-" form is automatically accepted or generated. Computer code does not make assumptions; programmers do. Elsewhere: * An option definition record. These records have the following fields: 1. the name of the option, with the leading "-" removed 2. a space-separated list of option properties (*note Option properties::) 3. the help text to use for '--help' (omitted if the second field contains the 'Undocumented' property). Nowhere is it suggested that options that take arguments should have a leading "f" or trailing "=". The *name* of the option doesn't include "="; it can be invoked Joined or Separate. Why does adding the "=" even work? > doc/options.texi describes options relative well, I think. That's good to know; at least you're not telling me it's horribly out of date. I am puzzled, though, because AFAICT that document doen't indicate why a leading "f" or trailing "=" controls whether or not an option taking an argument is passed to the compiler. Regards, --jkl
passing command-line arguments, still
[I sent this to gcc-help by mistake. I'm reposting it here in case
anyone has a suggestion. I did take dje's advice, and deleted the build
directory, except that I preserved config.status and regenerated
Makefile. The observed behavior remains unchanged. TIA.]
https://git.symas.net:443/cobolworx/gcc-cobol/
My first question regards command-line options. I've had no trouble
defining switches (-f-foo), but no luck defining an option that takes
an argument. The latter are accepted by gcobol and not passed to
cobol1.
In cobol/lang.opt, I have:
indicator-column
Cobol Joined Separate UInteger Var(indicator_column) Init(0)
IntegerRange(0, 8) -indicator-column=Column after which
Region B begins
strace(1) shows the problem:
[pid 683008] execve("../../../build/gcc/gcobol",
["../../../build/gcc/gcobol", "-main", "-o", "obj/SG105A", "-B",
"../../../build/gcc/", "-f-flex-debug", "-f-yacc-debug",
"-indicator-column", "1", "cbl/SG105A.cbl", "-lgcobol", "-lm", "-ldl"],
0x55a19b487940 /* 36 vars */
gcobol is being invoked with 3 options used by cobol1:
"-f-flex-debug", "-f-yacc-debug", "-indicator-column", "1"
where -indicator-column takes an argument, "1". But it's not passed to
cobol1:
[pid 683008] <... execve resumed>) = 0
[pid 683009] execve("../../../build/gcc/cobol1",
["../../../build/gcc/cobol1", "cbl/SG105A.cbl", "-quiet", "-dumpbase",
"SG105A.cbl", "-main", "-mtune=generic", "-march=x86-64", "-auxbase",
"SG105A", "-f-flex-debug", "-f-yacc-debug", "-o", "/tmp/ccIBQZv1.s"],
0x1578290 /* 40 vars */
The stanza in cobol/lang.opt looks similar to others in
fortran/lang.opt. The gcc internals don't mention anything else that I
could find that needs to be done. I've done a complete rebuild after
"make distclean". And still no joy.
We are working with a gcc fork of 10.2. Our log message says (in part):
The "tiny" branch was started with the 10.2.1
origin/releases/gcc-10 branch> c806314b32987096d79de21e72dc0cf783e51d57)
What am I missing, please?
--jkl
Announcement: gcobol
https://git.symas.net:443/cobolworx/gcc-cobol/ https://github.com/Apress/beg-cobol-for-programmers Greetings, gcc! We come bearing gifts! When you set your clock ahead an hour yesterday, you might not have realized you set your calendar back to 1985. There's a new gcc COBOL compiler. We call it: gcobol. On the books, we have 1 man-year invested: two full-time programmers since October 2021. We have so far compiled just over 100 programs from the examples in "Beginning COBOL for Programmers", by Michael Coughlin. We are near the end of that phase of the project, and expect to have ISAM and Object-Oriented Cobol features implemented in the next few weeks. We are working on compiling the NIST COBOL test suite, which we expect will take a few months to complete. We have begun work on gdb, too, and hope to have it working by year end. Our project should not be confused with GnuCOBOL (https://savannah.gnu.org/projects/gnucobol). That project is a Cobol translator: it compiles Cobol to C, and invokes gcc to produce executable code. Our gcobol compiler is (currently) a fork of gcc. It implements a gcc frontend for Cobol and (obviously) invokes the gcc backend to produce executables. (We have a friendly relationship with GnuCOBOL, and its maintainer supports our undertaking.) Ours should also not be confused with prior efforts to create a gcc Cobol compiler. Others have tried and failed. Failure wasn't an option for us. I won't say it was easy, but here we are. Eventually, if the gcc maintainers are interested, we would like to pursue full integration with gcc. For the moment, we have questions we're hoping can be answered here by those who ran the gauntlet before us. Given the state of the internals documentation, that seems like our best option. We've been rummaging around in the odd sock drawer for too long. If you're like me (like I was), your visceral response to this announcement can be summed up in one word: Why? The answer is as easy as it is trite: the right tool for the job. I wouldn't write an operating system in Cobol. But I wouldn't write one in Python or Java, either. Cobol has a niche no other language occupies: a compiled language for record-oriented I/O. That might sound strangely specialized, but it's not. Record-oriented I/O describes, I would argue, nearly *all* applications. Yet, since the advent of C, nearly all applications have relegated I/O to an external library, and adopted the Unix byte-stream definition of a "file". If you've written a CGI web application, you know what I'm talking about. Cobol eliminates a lot of gobbledygook by reducing free-form run-time variables to compile-time constants. That's the rationale, and it's not just a theory. Cobol is alive and kicking. Estimates vary, but they all say north of 100 billion lines of Cobol are still in use, with millions more written every year, even now, in the 21st century. Odds are your last ATM transaction or credit card purchase went through a Cobol application. There's another answer to Why: because a free Cobol compiler is an essential component to any effort to migrate mainframe applications to what mainframe folks still call "distributed systems". Our goal is a Cobol compiler that will compile mainframe applications on Linux. Not a toy: a full-blooded replacement that solves problems. One that runs fast and whose output runs fast, and has native gdb support. I am happy to debate the lunacy of this project and the viability of Cobol, either here or off-list. Today, we want to make the project known to those in the technical community who might most want to know what we're up to, and explain why we'll be asking the questions we're asking. Also, if you want to give it a whirl, please don't hesitate. We're happy to help, and expect to learn something in the process. Thank you for you kind attention. --jkl
bison -y overrides YACC in Make-lang.in
Using https://thinkingeek.com/gcc-tiny/ as a model, I've begun adding a new language to gcc. I'm having trouble controlling how Bison is invoked. In my Make-lang.in, I have YACC = bison YFLAGS = -Werror --debug --verbose but when I build, I see bison invoked on my .y file as $ bison -y -Werror --debug --verbose Where did that "-y" come from? The documentation https://gcc.gnu.org/onlinedocs/gccint/Front-End-Makefile.html#Front-End-Makefile says: "It contains targets lang.hook ... and any other Makefile rules required to build those targets" It doesn't say I can't use YACC = bison This was under the radar until an upgraded bison began flagging %empty as non-posix. The observed behavior looked to me to be in error. How is the language-specific directory supposed to control the value of YACC? --jkl
superior language dwarf records
Hello, We want to add source-level debugging to GNU Cobol. The Cobol compiler generates C, and then invokes gcc to produce ELF object code, of course. We are entertaining approaches to replace/amplify the DWARF records produced by gcc with new ones referencing the Cobol source. Before diving into 30 KLOC of dwarf-generation logic, we thought it prudent to ask for advice here. We are considering how best to insert DWARF records that refer to the Cobol source, while retaining the Cobol-to-C-to-ELF design. One way to do that would be to supply gcc with information about "superior" language constructs (meaning "above", not "better"). ISTM Cobol is neither the first nor last language to use C as a kind of idealized assembler. AFAIK there is no interface to supply debugging information to gcc. I don't know if its possible in DWARF to have one position in the object code be defined by two source files (Cobol and C). Ideally, we would find a way to keep the C records and add Cobol records, and tell the debugger which ones to use. Absent direct gcc support, we're considering the following approach: 1. Maintain a map of Cobol-to-C constructs. 2. Invoke gcc -g to produce dwarf records. 3. Use libdwarf or similar to iterate over the dwarf records, and to generate new, Cobol records for (some of) the same locations using the map from step #1. If the Cobol records cannot coexist with the C records in the same file, then between steps 2 and 3 we would extract them to a dwo file with objcopy. Is gcc capable of accepting additional dwarf information, or would the team be interested in such support? Other suggestions on how the goal might be met? Kind regards, --jkl
Re: -Wparentheses lumps too much together
Ian Lance Taylor wrote: A typical true positive looked more or less like if (a b || c) http://www.jetcafe.org/jim/c-style.html It's funny you should mention that. A warning about whitespace indentation that's inconsistent with the expressed logic *would* be helpful (and consistent with the if/else part of -Wparentheses). --jkl
Re: -Wparentheses lumps too much together
Ian Lance Taylor wrote: I have no objection to splitting -Wparentheses into separate warnings controlled by separate options. Thank you, Ian. which yields (as you know) advice to parenthesize the two pairs. That particular warning happened to find dozens of real errors when I ran it over a large code base. It may be noise for you, but I know from personal experience that it is very useful. I would like to hear more about that, if you wouldn't mind. I'm really quite surprised. Honestly. I don't claim to be the last arbiter in good taste. It sounds like you're saying that this warning, when applied to code of uncertain quality, turned up errors -- cases when the code didn't reflect (what must have been) the programmer's intentions. My untested (and consequently firmly held) hypothesis is that 1) most combinations of and || don't need parentheses because (a b) || (c d) is by far more common than a (b || c) d and, moreover, broken code fails at runtime, and 2) Most programmers know (because they need to know) that comes before ||. I'm sure a few years spent working with the GCC and fielding questions about it would lower my opinion of the average programmer, so I won't try to convince you. But I would like to know more about what you found, because that's at least objective evidence. I was unable to find any metrics supporting the inclusion of this particular warning in -Wall. I would hold to this, though: the warnings about precedence are of a different order than warnings about nesting. I suggest that well vetted code doesn't benefit from the kind of false positives that -Wparentheses can generate. I very much appreciate your time and effort. Kind regards, --jkl
