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
/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
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
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
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
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
/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
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
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?
>
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
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
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,
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
mprovements 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
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},
> >
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
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,
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
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
>
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
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
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
[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/
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
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
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
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
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
28 matches
Mail list logo
