On Mon, 24 Mar 2025 22:55:44 +0100
Jakub Jelinek wrote:
> > When cbl_field_t::data::value_of returned _Float128, that line
> > compared a _Float128 to its value as a size_t. If the number was
> > negative, had a fractional component, or was too large, the test
> > failed.
> >
> > Now cbl_fiel
On Sun, 16 Mar 2025 21:07:39 +0100
Simon Sobisch wrote:
> This gives three reference-formats: "fixed" "free" and "extended". For
> two of those we have seen the flags -ffixed-form and -ffree-form, so
> I'd _guess_ the last one would be -fextended-form.
>
> Question: Is there a reason to have mul
On Thu, 20 Mar 2025 10:06:20 +0100 (CET)
Richard Biener wrote:
> > I just want to put all 3 hands on the table, and make sure we all
> > understand why we're doing this, if we are, and what it will entail
> > if we do. I'm sure you feel the same.
>
> Sure! So let me explain the advantage I
on Sep 17 00:00:00 2001
From: "James K. Lowden"
Date: Sun, 23 Mar 2025 16:24:36 -0400
ChangeLog:
* MAINTAINERS: Add myself.
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 5b3fe407860..90c8e2aa995 100644
--- a/MAINTAINERS
On Thu, 27 Mar 2025 09:33:40 +
Iain Sandoe wrote:
> As noted in the commit log, the macOS version of cmath (at least) has
> conflicts with parse.y. Tested on x86_64,aarch64 linux,
> x86_64-darwin. OK for trunk?
> thanks,
> Iain
LGTM, Iain. Any header file that isn't needed, isn't needed.
On Tue, 25 Mar 2025 13:01:59 -0400
"James K. Lowden" wrote:
> In fact, we shouldn't use floating point for numeric literals.
I'm sorry, I should have been more precise. Section 8.3.3.3 of the ISO
spec defines both fixed- and floating-point numeric literals.
On Thu, 20 Mar 2025 13:30:27 +0100 (CET)
Richard Biener wrote:
> @@ -4126,7 +4137,11 @@ count: %empty { $$ = 0; }
> if( e ) { // verify not floating point with nonzero fraction
> auto field = cbl_field_of(e);
> assert(is_liter
On Fri, 21 Mar 2025 11:50:19 +0100
"Jose E. Marchesi" wrote:
>
> > Am 20.03.2025 um 21:50 schrieb James K. Lowden:
> >> On Mar 13, 2025, at 8:04 AM, Simon Sobisch
> >> wrote:
> >>>
> >>> exit() allows us to "pass to the operatin
ead them and they're straightforward. If I
> > need to do more than just say that, please direct me.
>
> OK, thanks. On that topic, should you be listed in the MAINTAINERS
> file? I see Bob in there, but don't see your name.
We're working on it. I would like e
On Fri, 21 Mar 2025 10:21:13 +0100
Jakub Jelinek wrote:
> On Wed, Mar 19, 2025 at 06:03:24PM -0400, James K. Lowden wrote:
> > Elsewhere in the parser where there was a conflict like that, I
> > renamed the token. For example, the COBOL word TRUE uses a token
> > named T
On Wed, 19 Mar 2025 20:33:36 +
Jonathan Wakely wrote:
> There's no need to keep using std::find_if from the beginning of the
> container after every removal, just update the iterator after erasing
> an element.
>
> This is how C++20 std::erase_if is implemented.\
LGTM. I am gun-shy about u
On Mar 13, 2025, at 8:04 AM, Simon Sobisch wrote:
>
> exit() allows us to "pass to the operating system" directly; but it doesn't
> directly say "success" or "fail".
>
>
> Obviously the statements
> STOP RUN WITH NORMAL STATUS 41
> and
> STOP RUN ERROR 41
>
> Should have a different resul
On Wed, 19 Mar 2025 15:24:19 +0100 (CET)
Richard Biener wrote:
> The following removes HOWEVER_GCC_DEFINES_TREE and the alternate
> definition of tree from symbols.h and instead ensures that both
> coretypes.h and tree.h are included where required. This required
> putting GCCs own 'NONE' in a s
On Wed, 19 Mar 2025 12:13:47 -0500 (CDT)
Robert Dubner wrote:
> In file included from ../../gcc/cobol/scan.l:42:
> cobol/parse.h:932:12: error: 'NONE' conflicts with a previous
> declaration 932 | NONE = 881,/* NONE */
Here, NONE names a COBOL token because (I assume wit
On Thu, 13 Mar 2025 20:06:58 +0100
Rainer Orth wrote:
> Hi James,
>
> > Our intention, tell me if you disagree, is that cobol is enabled if
> >
> > 1. --enable-languages=all, and
> > 2. the host and target are "known good", x86_64 or aarch64
>
> you tend to forget there's a world outside of L
On Mon, 10 Mar 2025 19:10:26 +0100
Richard Biener wrote:
> > What is the right answer? Designated initializers are part of C99,
> > but weren't added to C++ until C++20
> > (https://en.cppreference.com/w/cpp/language/initialization).
> > Strictly speaking, we should remove all of them, because o
On Thu, 13 Mar 2025 14:45:23 -0400
Paul Koning wrote:
> > 3. --enable-languages=cobol, and
> > 4. the host and target are "plausible", 64-bit LE.
>
> Why does it need LE? I understand 64 bits. I might try it on my
> PowerPC based Mac. :-)
That's a good point. "Need" I don't know. I'm not
On Tue, 11 Mar 2025 11:18:22 +0100
Andreas Schwab wrote:
> > +
> > +# It's early days for COBOL, and it is known to compile on only
> > some host and +# target systems. We remove COBOL from other builds
> > with a warning. +
> > +cobol_is_okay_host="no"
> > +cobol_is_okay_target="no"
> > +
> >
On Tue, 11 Mar 2025 14:40:19 +0100 (CET)
Richard Biener wrote:
> > Looking at pretty much all of the above, it seems very Fortran
> > specific with its weird diagnostic output (capital Warning:/Error:,
> > the (1) and (2) in the diagnostics with later printing of those
> > lines and the like. Unl
On Thu, 13 Mar 2025 13:37:32 -0400
Paul Koning wrote:
> > 4. cast pointers formatted with %p as (void*)
>
> Could that be (const void *) instead?
Yes. Nothing is committed yet; I'll make that change first.
Could you explain why it matters, please, for my edification?
--jkl
On Mon, 10 Mar 2025 17:34:40 +0100
Richard Biener wrote:
> index 10a42cb1dd7..8e18ef1 100644
> --- a/gcc/Makefile.in
> +++ b/gcc/Makefile.in
> ...
> +# user-defined functions for GCOBOL
> +udfdir = $(datadir)/gcobol/udf
> ..
> @@ -4031,7 +4035,9 @@ installdirs:
> $(mkinstalldirs) $(DE
On Mon, 10 Mar 2025 18:05:21 +0100
Jakub Jelinek wrote:
> Designated initializers are C++20, so you should just avoid that. So,
> I'd recommend just:
> cbl_field_data_t data = { /* memsize= */capacity_cast(len),
> /* capacity= */capacity_cast(len),
>
On Wed, 5 Mar 2025 11:43:16 +0100
Richard Biener wrote:
> > In short, despite not trying to support DESTDIR, we do anyway, by
> > happy accident. And we are now better informed.
>
> Thanks. Checking cobol-patched again I see
Hi Richard,
I have regenerated and force-pushed cobol-patched. It
On Tue, 4 Mar 2025 00:08:16 +0100
Jakub Jelinek wrote:
> On Mon, Mar 03, 2025 at 05:21:38PM -0500, James K. Lowden wrote:
> > However IMO, the incantation:
> >
> > make install DESTDIR=/foo
> >
> > is invalid. The compiler's library search path i
On Mon, 24 Feb 2025 14:51:27 +0100
Richard Biener wrote:
> > Our repository is
> >
> > https://gitlab.cobolworx.com/COBOLworx/gcc-cobol/
> >
> > using branch
> >
> > cobol-stage
> >
> > I tested these patches using "git apply" to an unpublished branch
> > "cobol-patched".
>
> I h
On Mon, 24 Feb 2025 14:51:27 +0100
Richard Biener wrote:
> Compiling a Cobol Hello World results in
>
> > ./install/gcc-cobol/usr/local/bin/gcobol t.cob
> /usr/bin/ld: cannot find -lgcobol: No such file or directory
> collect2: error: ld returned 1 exit status
>
> possibly because the 64bit lib
On Mon, 24 Feb 2025 14:51:27 +0100
Richard Biener wrote:
> On Wed, Feb 19, 2025 at 12:38?AM James K. Lowden
> wrote:
> >
> > The following 14 patches constitute 105,720 lines of code in 83
> > files to build and document the COBOL front end.
[...]
> > I tested
On Mon, 24 Feb 2025 14:51:27 +0100
Richard Biener wrote:
> Installing the result via make install DESTDIR=/foo I see both a
> 'gcobol' and a 'gcobc' program
> being installed - is that intentional?
Yes, that is intentional. gcobol is the compiler driver, as you know.
gcobc is a shell script t
On Mon, 24 Feb 2025 14:51:27 +0100
Richard Biener wrote:
> gcc-cobol/gcc/cobol/parse.y:1361.10-16: error: require bison 3.5.1,
> but have 3.0.4
> %require "3.5.1" //3.8.2 also works, but not 3.8.0
> ^^^
>
> this requirement isn't documented, neither is a version requirement
>
On Fri, 21 Feb 2025 19:59:25 +0100
Florian Weimer wrote:
> * James K. Lowden:
>
> > As I mentioned in other posts, IMO (IANAL) the copyright in
> > unimportant and probably unenforceable. The National Computing
> > Centre no longer exists, and the document was also pub
but I guess somebody has to.
--jkl
>From 71aca801f6dc5f6c2ea19044755f01a09742e7db Fri 21 Feb 2025 12:15:18 PM EST
From: "James K. Lowden"
Date: Fri 21 Feb 2025 12:15:18 PM EST
Subject: [PATCH] COBOL inf: info updates for gcobol
gcc/doc/ChangeLog
* doc/contrib.texi: A
On Fri, 21 Feb 2025 13:00:13 +0100
Richard Biener wrote:
> > Branches in git don't have independent permissions. If we use
> > gcc.gnu.org git, are we granted commit rights with the priviso that
> > we color inside the lines, and commit only to our own branches?
>
> My expectation is that by co
On Fri, 21 Feb 2025 01:17:15 + (UTC)
Joseph Myers wrote:
> > The Makefile fetches the NIST archive from our website.
>
> The normal build and test process ("make" and "make check") must
> never rely on any network connectivity.
Fair enough. I haven't added the NIST tests and documenta
On Thu, 20 Feb 2025 11:38:58 +0100
Richard Biener wrote:
> Can you clarify on the future development model for Cobol after it has
> been merged? Is the cobolworx gitlab still going to be the primary
> development location and changes should be made there and then merged
> to the GCC side?
I w
On Wed, 19 Feb 2025 12:55:03 +0100
Matthias Klose wrote:
> libgcobol/ChangeLog
> * Makefile.in: New file.
> * acinclude.m4: New file.
> * aclocal.m4: New file.
> * configure.ac: New file.
> * configure.tgt: New file.
>
> I had updated the configure.tgt, please find
>From f89a50238de62b73d9fc44ee7226461650ab119d Tue 18 Feb 2025 04:19:13 PM EST
From: "James K. Lowden"
Date: Tue 18 Feb 2025 04:19:13 PM EST
Subject: [PATCH] COBOL 11/14 84K lhd: libgcobol header files
libgcobol/ChangeLog
* /charmaps.h: New file.
* /common-def
>From f89a50238de62b73d9fc44ee7226461650ab119d Tue 18 Feb 2025 04:19:09 PM EST
From: "James K. Lowden"
Date: Tue 18 Feb 2025 04:19:09 PM EST
Subject: [PATCH] COBOL 1/14 4.0K dir: create gcc/cobol and libgcobol
directories
contrib/gcc-changelog/ChangeLog
* contrib/
>From f89a50238de62b73d9fc44ee7226461650ab119d Tue 18 Feb 2025 04:19:12 PM EST
From: "James K. Lowden"
Date: Tue 18 Feb 2025 04:19:12 PM EST
Subject: [PATCH] COBOL 10/14 72K doc: man pages and GnuCOBOL emulation
gcc/cobol/ChangeLog
* gcobc: New file.
* gcobo
>From f89a50238de62b73d9fc44ee7226461650ab119d Tue 18 Feb 2025 04:19:10 PM EST
From: "James K. Lowden"
Date: Tue 18 Feb 2025 04:19:10 PM EST
Subject: [PATCH] COBOL 3/14 80K bld: config and build machinery
ChangeLog
* Makefile.def: Add libgcobol module and c
>From f89a50238de62b73d9fc44ee7226461650ab119d Tue 18 Feb 2025 04:19:10 PM EST
From: "James K. Lowden"
Date: Tue 18 Feb 2025 04:19:10 PM EST
Subject: [PATCH] COBOL 2/14 8.0K pre: introduce ChangeLog files
gcc/cobol/ChangeLog
* ChangeLog: New file.
libgco
The following 14 patches constitute 105,720 lines of code in 83 files
to build and document the COBOL front end. The messages are
in a more or less logical order. We have:
1/14 4K dir: create gcc/cobol and libgcobol directories
2/14 8K pre: introduce ChangeLog files
3/14 80K bld: config
On Tue, 18 Feb 2025 09:35:33 +0100
Richard Biener wrote:
> > I'm sure you agree we don't want to let this tail wag the dog.
> > With my exegesis in mind, what would you recommend? If it's
> > limited to more judicious use of makefile variables, I could surely
> > implement those suggestions.
>
On Tue, 18 Feb 2025 09:37:57 +0100
Richard Biener wrote:
> > Except for "lib", patches over 400 KB consist of just one big file.
>
> For a future possible version 3 of the patch set, you do not need to
> send big generated files like 'configure' as part of the patch, but
> just the sources/chang
On Mon, 17 Feb 2025 15:13:21 -0500
David Malcolm wrote:
> > How do I do that? I barely know the term; I have to look it up
> > every time. I don't find "sarif" anywhere in gcc.info or
> > gccint.info.
>
> (caveat: SARIF is one of my particular interests and thus I'm biased
> towards it; not
On Mon, 17 Feb 2025 15:02:35 -0500
David Malcolm wrote:
> > (Maybe zero_option_id would be a better name?)
>
> Ah - yes, now I see what you mean. I like that name.
>
> Can it be "const"?
Already is! I renamed it to "option_zero" to prevent future confusion.
--jkl
On Mon, 17 Feb 2025 15:35:16 -0500
David Malcolm wrote:
> > > Have you tried running the compiler under valgrind? Configure
> > > with ?enable-valgrind-annotations and pass -wrap per=valgrind to
> > > the driver.
> a benefit of my suggested approach is that if you *do* need to use
> valgrind at
On Mon, 17 Feb 2025 15:28:48 -0500
David Malcolm wrote:
> We shouldn't rely on assert to do checking of user-controllable input;
> it should always be checked.
Quite so. I think you'll like the change.
--jkl
On Sat, 15 Feb 2025 23:35:16 -0500
David Malcolm wrote:
On better messages ...
> + if( ($$ & $2) == $2 ) {
> +error_msg(@2, "%s clause repeated", clause);
> +YYERROR;
> + }
>
> Obviously not needed for initial release, bu
On Sat, 15 Feb 2025 23:37:20 -0500
David Malcolm wrote:
> +const char *
> +cobol_get_sarif_source_language(const char *)
> +{
> +return "cobol";
> +}
>
> Out of curiosity, did you try the SARIF output? This is a good test
> for whether you?re properly using the GCC diagnostics subsy
On Sat, 15 Feb 2025 21:24:52 +
Sam James wrote:
> > +prototypes.cpp: posix.txt
> > + awk -F'[/.]' '{ print $$6 }' $^ | \
> > + while read F; do echo "/* $$F */" && man 2 $$F | \
> > + ./scrape.awk -v funcname=$$6; done > $@~
> > + @mv $@~ $@
> > +
> > +posix.txt:
> > +
On Sat, 15 Feb 2025 23:32:37 -0500
David Malcolm wrote:
> > +static bool
> > +is_word_char( char ch ) {
> > + switch(ch) {
> > + case '0' ... '9':
> > + case 'a' ... 'z':
> > + case 'A' ... 'Z':
> > + case '$':
> > + case '-':
> > + case '_':
> > + return true;
> > + }
> > + return fa
On Sat, 15 Feb 2025 23:37:20 -0500
David Malcolm wrote:
> + rich_location richloc (line_table, token_location);
> + bool ret = global_dc->diagnostic_impl (&richloc, nullptr,
> option_id,
> + gmsgid, &ap, DK_ERROR);
> + va_end (ap);
> + global_dc->end_gr
On Sat, 15 Feb 2025 23:32:37 -0500
David Malcolm wrote:
> > + free(copier);
>
> There?s a manual free of "copier" here, but there?s are various error-
> handling early returns paths that will leak. Maybe just use a
> std::string?
>
> Similarly with ?path?; I think this is always leaked. Maybe
On Sat, 15 Feb 2025 21:30:16 +
Sam James wrote:
> > +cbl_refer_t *
> > +negate( cbl_refer_t * refer, bool neg = true ) {
> > + if( ! neg ) return refer;
> > + assert( is_numeric(refer->field) );
>
> These should be gcc_assert or gcc_checking_assert in general,
> depending on the severity (
On Sat, 15 Feb 2025 23:32:37 -0500
David Malcolm wrote:
In defense of lack of free(3) ...
> > +const char *
> > +esc( size_t len, const char input[] ) {
> > + static char spaces[] = "([,;]?[[:space:]])+";
> > + static char spaceD[] = "(\n {6}D" "|" "[,;]?[[:space:]])+";
> > + static char buff
On Sat, 15 Feb 2025 21:30:16 +
Sam James wrote:
> > + * This stand-in for std::regex was written because the
> > implementation provided
> > + * by the GCC libstdc++ in GCC 11 proved too slow, where "slow"
> > means "appears
> > + * not to terminate". Some invocations of std::regex_search to
On Sat, 15 Feb 2025 21:18:50 +
Sam James wrote:
> > Subject: [PATCH] Add 'cobol' to 17 files
>
> The commit message summary (first line) should say something like the
> email title, so 'cobol: bld: config and build machinery'.
Roger, will do next time.
> > +YFLAGS = -Werror -Wmidrule-val
On Sat, 15 Feb 2025 21:18:50 +
Sam James wrote:
> Please generate these files with vanilla autoconf-2.69, not
> distro-patched autoconf.
Sure thing, Sam. I meant to do that; I thought I did. It might be that the
distro's autoconf still sneaked in again later.
How did you spot it? I'd l
>From 5d53920602e234e4d99ae2d502e662ee3699978e 4 Oct 2024 12:01:22 -0400
From: "James K. Lowden"
Date: Sat 15 Feb 2025 12:50:55 PM EST
Subject: [PATCH] 10 new 'cobol' FE files
libgcobol/ChangeLog
* charmaps.h: New file.
* common-defs.h: New file.
>From 5d53920602e234e4d99ae2d502e662ee3699978e 4 Oct 2024 12:01:22 -0400
From: "James K. Lowden"
Date: Sat 15 Feb 2025 12:50:54 PM EST
Subject: [PATCH] 5 new 'cobol' FE files
gcc/cobol/ChangeLog
* gcobc: New file.
* gcobol.1: New file.
>From 5d53920602e234e4d99ae2d502e662ee3699978e 4 Oct 2024 12:01:22 -0400
From: "James K. Lowden"
Date: Sat 15 Feb 2025 12:50:54 PM EST
Subject: [PATCH] 12 new 'cobol' FE files
gcc/cobol/ChangeLog
* posix/.gitignore: New file.
* posix/Makefile: New file.
>From 5d53920602e234e4d99ae2d502e662ee3699978e 4 Oct 2024 12:01:22 -0400
From: "James K. Lowden"
Date: Sat 15 Feb 2025 12:50:51 PM EST
Subject: [PATCH] Add 'cobol' to 1 file
contrib/gcc-changelog/ChangeLog
* git_commit.py: Add libgcobol module and cobol lan
>From 5d53920602e234e4d99ae2d502e662ee3699978e 4 Oct 2024 12:01:22 -0400
From: "James K. Lowden"
Date: Sat 15 Feb 2025 12:50:52 PM EST
Subject: [PATCH] Add 'cobol' to 17 files
ChangeLog
* Makefile.def: Add libgcobol module and cobol language.
* Makefile.i
>From 5d53920602e234e4d99ae2d502e662ee3699978e 4 Oct 2024 12:01:22 -0400
From: "James K. Lowden"
Date: Sat 15 Feb 2025 12:50:51 PM EST
Subject: [PATCH] 2 new 'cobol' FE files
gcc/cobol/ChangeLog
* ChangeLog: New file.
libgcobol/ChangeLog
* ChangeLog: N
The following 15 patches constitute 134,033 lines of code in 97 files
to build and document the COBOL front end. The messages are
grouped by files in a more or less logical order. We have:
4K dir create gcc/cobol and libgcobol directories
8K pre introduce ChangeLog files
92K bl
On Wed, 18 Dec 2024 20:37:13 + (UTC)
Joseph Myers wrote:
> So make sure your patches include the changes required to
> update_web_docs_git to install HTML and PDF versions of those man
> pages, and point to somewhere we can see the formatted versions.
> That will then provide a way to compar
[Well, that was interesting. Some combination of fat fingers crashed
my mail client and sent the incomplete message. Continued below]
From: "James K. Lowden"
To: Matthias Klose
Cc: gcc-patches@gcc.gnu.org
Date: Tue, 4 Feb 2025 04:25:23 -0500
Subject: Re: The COBOL front end,
On Mon, 16 Dec 2024 10:24:23 +0100
Matthias Klose wrote:
> On 14.12.24 15:38, Matthias Klose wrote:
> > I tried to use the patches to build binary packages for Debian.
> > Found some issues:
>
> tried to build libgcobol on more architectures, please find the
> attached patch to disable building
On Fri, 3 Jan 2025 19:46:38 +0100
Jakub Jelinek wrote:
> Again, the question is if it needs to be supported everywhere, or
> just error out on targets which don't have _Float128
Our preference is simply to error out on targets that don't support
_Float128.
I don't know how to do that. It can
On Sun, 29 Dec 2024 00:47:05 + (GMT)
"Maciej W. Rozycki" wrote:
> > ChangeLog
> > * Makefile.def: Add libgcobol module and cobol language.
>
> Since this implies the regeneration of top-level Makefile.in please
> add a ChangeLog entry to that effect and include the changes to
> Makefile
On Sat, 14 Dec 2024 18:34:03 -0500
David Malcolm wrote:
> You may want to apply this trivial fix to placate older C++ compilers:
>
> diff --git a/gcc/cobol/genapi.cc b/gcc/cobol/genapi.cc
> index c9f146df41f..af4efcecebb 100644
> --- a/gcc/cobol/genapi.cc
> +++ b/gcc/cobol/genapi.cc
> @@ -15077,
On Thu, 12 Dec 2024 12:56:36 -0500
"James K. Lowden" wrote:
> The following 8 patches constitute the 80 files needed to build and
> document the COBOL front end.
Below is a list of issues with the COBOL front end, listed in
order of priority, most important first. Each is
On Mon, 16 Dec 2024 23:36:37 + (UTC)
Joseph Myers wrote:
> > +extern "C" _Float128 __gg__float128_from_qualified_field
>
> I'm not entirely sure whether this is host or target code (you always
> need to be clear about which is which in GCC), but in any case, both
> hosts and targets without
On Tue, 17 Dec 2024 18:04:01 + (UTC)
Joseph Myers wrote:
> I don't think we should introduce man pages as a new source format
> for documentation in GCC. Either .texi or .rst (with generated man
> pages) would be fine.
I hope you can be persuaded to accept our man pages, at least for now,
b
On Mon, 16 Dec 2024 23:48:52 + (UTC)
Joseph Myers wrote:
> However, if introducing a Bison dependency, it needs to be documented
> (being specific about version requirements) in install.texi.
Under "Tools/packages necessary for building GCC", in Prequisites,
yes?
In gcc/cobol/parse,y, we
>From 64bcb34e12371f61a8958645e1668e0ac2704391bld.patch 4 Oct 2024 12:01:22
>-0400
From: "James K. Lowden"
Date: Thu 12 Dec 2024 06:28:06 PM EST
Subject: [PATCH] Add 'cobol' to 10 files
ChangeLog
* Makefile.def: Add libgcobol module and cobol language.
>From 64bcb34e12371f61a8958645e1668e0ac2704391doc.patch 4 Oct 2024 12:01:22
>-0400
From: "James K. Lowden"
Date: Thu 12 Dec 2024 06:28:05 PM EST
Subject: [PATCH] Add 'cobol' to 4 files
gcc/cobol/ChangeLog
* gcobc: New file.
* gcobol.1: New file.
The following 8 patches constitute the 80 files needed to build and
document the COBOL front end. They assume that following exist:
gcc/cobol/ChangeLog
libgcobol/ChangeLog
The messages are grouped by files in a more or less logical order,
but groups are somewhat arbitrary. The primary c
On Thu, 12 Dec 2024 15:07:35 +0100
Richard Biener wrote:
> On Wed, Dec 11, 2024 at 4:19?PM James K. Lowden
> wrote:
> >
> > I think the term of art is "ping"?
> >
> > If GCC needs something from me to proceed with this, please tell me
> > what it
I think the term of art is "ping"?
If GCC needs something from me to proceed with this, please tell me what
it is.
--jkl
On Thu, 7 Nov 2024 17:28:33 -0500
"James K. Lowden" wrote:
> On Fri, 8 Nov 2024 13:52:55 +0100
> Jakub Jelinek wrote:
>
> >
se should be posted as normal patches.
Below is hopefully a well formed patch. It adds ChangeLogs for the
COBOL front end.
[snip]
>From 304f3678dbade1f60abdadb9ddd2baffae88013dpre.patch 4 Oct 2024 12:01:22
>-0400
From: "James K. Lowden"
Date: Fri 08 Nov 2024 03:30:08 PM EST
s to be committed, you need to talk to us best on IRC
> or worst case via mail
Hmm, using rcirc in emacs, I'm connected to #g...@irc.oftc.net but
didn't see any traffic today. Probably pibkac.
--jkl
[snip]
>From 95d8508ce8dabebbabfe14b9621fca45e2a397dddir.patch 4 Oct 2024 12:
e2a397dddir.patch 4 Oct 2024 12:01:22
>-0400
From: "James K. Lowden"
Date: Sat 02 Nov 2024 12:51:49 PM EDT
Subject: [PATCH] Add stub 'gcc/cobol/ChangeLog'
gcc/cobol/ChangeLog [new file with mode: 0644] blob
---
^L
Copyright (C) 2024 Free Software Foundatio
ddir.patch 4 Oct 2024 12:01:22
>-0400
From: "James K. Lowden"
Date: Sat 02 Nov 2024 12:51:49 PM EDT
Subject: [PATCH] Add ChangeLog directories for cobol into git_commit.py.
Prepare to add changelogs for the Cobol front end by changing
the contrib git_commit.py script.
contrib/Chan
On Sat, 26 Oct 2024 13:41:32 -0400
"James K. Lowden" wrote:
Below is a revised patch set incorporating recent feedback. Changes:
* 2 patches: creation of gcc/cobo/ChangeLog
now precedes "patch #1", the metafile patch
* dead code (#if 0) removed
* One new file incl
f cooperation, here is one patch that adds the ChangeLog.
--jkl
[snip]
>From ccb8a64c97461d792fdc39db249980a9ecb63b4bpre.patch 4 Oct 2024 12:01:22
>-0400
From: "James K. Lowden"
Date: Fri 01 Nov 2024 01:50:33 PM EDT
Subject: [PATCH] Add 'cobol' to 1 file
gcc/Change
On Tue, 29 Oct 2024 11:56:18 +0100
Richard Biener wrote:
> gcc/ should be stripped from * gcc/common.opt, so just * common.opt
...
> Likewise for gcc/cobol.
I see. The names in these cases are relative to gcc, not to the whole
project. The runtime library, libgcobol, like the other libraries, i
use the source files
are missing.
I have not tested with git-gcc-verify because I don't know how to use
it It does apply cleanly with "git am" (on my end, at least).
--jkl
[snip]
>From be8c3d34ad7f8a92f4e1679dbbe411b4bcb04d0fbld.patch 4 Oct 2024 12:01:22
>-0400
From: &qu
On Sat, 26 Oct 2024 11:22:20 +0800
Xi Ruoyao wrote:
> The changelog is not formatted correctly. gcc/ has its own
> changelog. And gcc/cobol should have its own changelog too, like all
> other frontends.
Thank you for pointing that out. I now have
[snip]
Subject: [PATCH] Add 'cobol' to 10 fil
On Thu, 24 Oct 2024 12:01:10 -0400
"James K. Lowden" wrote:
> They are not. With --enable-generated-files-in-srcdir, the build
> fails. What do I need to do to fix it? I haven't the faintest idea.
I believe I found it:
diff --git a/gcc/cobol/Make-lang.in b/gcc/cob
On Wed, 23 Oct 2024 15:12:19 +0200
Richard Biener wrote:
> Note there's --enable-generated-files-in-srcdir specifically to remove
> yacc and flex - can you check whether with this configure flag those
> files are generated in the source directory and thus picked up when
> building the release tar
quot;git am", I got a warning about a blank line
at EOF, but I couldn't figure out where it was, or if it mattered.
--jkl
>From 06a93d00f4433fb61ff9611c6e945a3a11c89479bld.patch 4 Oct 2024 12:01:22
>-0400
From: "James K. Lowden"
Date: Mon 14 Oct 2024 0
we work our way through those, there is a runtiime
library. After that I have tests and documentation. And then we'll be
done. Right? ;-)
This patch adds "cobol" as a language and subdirectory.
--jkl
>From 216ec55cdb2ad95728612d4b9b5550324e9b506fpatch 4 Oct 2024 12:01:2
93 matches
Mail list logo
