[Bug cobol/120554] libgcobol meets clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120554 James K. Lowden changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #14 from James K. Lowden --- > Suggest rework code to be compatible with earlier language standards. Removed constexpr. Compiles with -std=c++14.
[Bug cobol/120554] libgcobol meets clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120554 --- Comment #13 from James K. Lowden --- The code now reads, cbl_declarative_t& operator=(const cbl_declarative_t&) = default; Can I mark this PR as resolved?
[Bug cobol/120554] libgcobol meets clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120554 James K. Lowden changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rdubner at gcc dot gnu.org Ever confirmed|0 |1 CC||jklowden at gcc dot gnu.org Last reconfirmed||2025-06-06 Status|UNCONFIRMED |ASSIGNED
[Bug cobol/120554] libgcobol meets clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120554 --- Comment #12 from Jakub Jelinek --- (In reply to Sam James from comment #11) > Why are you downloading it repeatedly? Just run `git pull` every so often. > git is designed to be efficient for small updates. Or if you want independent checkouts and don't want say git worktree, you can at least save network downloads by using git clone --dissociate --reference /some/existing/gcc/.git/ git://gcc.gnu.org/git/gcc.git or so.
[Bug cobol/120554] libgcobol meets clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120554 --- Comment #11 from Sam James --- (In reply to David Binderman from comment #4) > (In reply to Sam James from comment #2) > > As jwakely explained before, you cannot use git blame and friends on a > > shallow clone. > > Oh dear, this again. > > It might be worth mentioning on page https://gcc.gnu.org/git.html > that the git history covers over 33 years and currently consumes about > 2.8 Gig of disk space. > You are free to use a large --depth= value if you really want, or a partial clone. > For folks on slow internet links, it takes quite some time to download. > Why are you downloading it repeatedly? Just run `git pull` every so often. git is designed to be efficient for small updates. > It looks to me like there is an opportunity for a git history > that only covers the last five years or so. Perhaps a split > into git-current and git-old would be a good idea ? No, git already lets you do that if you want to clone that locally, but seriously, just clone the whole thing and run `git pull` once a week or whatever. Can discuss more over mail if needed.
[Bug cobol/120554] libgcobol meets clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120554 --- Comment #10 from Jonathan Wakely --- (In reply to David Binderman from comment #4) > It might be worth mentioning on page https://gcc.gnu.org/git.html > that the git history covers over 33 years and currently consumes about > 2.8 Gig of disk space. > > For folks on slow internet links, it takes quite some time to download. 1.2G of that is just the latest sources, without any .git metadata. It's always going to be slow to download, even without the full history. > It looks to me like there is an opportunity for a git history > that only covers the last five years or so. Perhaps a split > into git-current and git-old would be a good idea ? I don't see how that will help people who try to use git blame without the full history ... they still won't have the full history. It would just be disruptive for people who *do* have the full clone, and is completely unnecessary because if you don't want all the history you can just use a shallow clone (with whatever depth you want, maybe five years not one day, for example). There is no problem with the size of the repo, git provides all the tools needed to work with it, you just keep using it in a way that doesn't work. You could use the online blame tools instead, like https://github.com/gcc-mirror/gcc/blame/master/libgcobol/common-defs.h or gcc dot gnu dot org /cgit/gcc/blame/libgcobol/common-defs.h (I'm not linking to it so that AI bots don't scrape that URL all day every day).
[Bug cobol/120554] libgcobol meets clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120554 --- Comment #9 from Marek Polacek --- There's a bug that we don't accept "constexpr S() = default;" in C++23 -- bug 109623.
[Bug cobol/120554] libgcobol meets clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120554 Jakub Jelinek changed: What|Removed |Added CC||jason at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org --- Comment #8 from Jakub Jelinek --- So, seems g++ rejects #c6 with -std=c++11, and accepts it for -std=c++1y and above since r6-7277-gb47d1d904d5397a61bba40fba095f02bd00f04c1. While clang++ accepts it only for -std=c++23. C++20 (looking at N4849) has in [class.copy.assign]/10 The implicitly-defined copy/move assignment operator is constexpr if ... X is a literal type, and ... but unsure where it is specified one can't mark it constexpr on explicit defaulted declaration. This later changed e.g. with https://wg21.link/p2448r2 and https://wg21.link/p2706r0 Anyway, on the libgcobol side, I'd just suggest dropping constexpr, if it is not literal type, constexpr for copy assignment makes no sense for it.
[Bug cobol/120554] libgcobol meets clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120554
--- Comment #7 from David Binderman ---
(In reply to Jakub Jelinek from comment #6)
> This boils down to
> struct S {
> unsigned int s;
> S () : s (0) {}
> constexpr S &operator= (const S &) = default;
> };
> i.e. when the default ctor is not constexpr, but defaulted assignment
> operator is constexpr.
A simpler test case is this:
$ more bug1101.cc
struct S {
S();
constexpr S & operator=( const S & ) = default;
};
foundBugs $ ~/gcc/results/bin/g++ -c bug1101.cc
foundBugs $ ~/llvm/results/bin/clang++ -c bug1101.cc
bug1101.cc:4:3: error: defaulted definition of copy assignment operator cannot
be marked constexpr before C++23
4 | constexpr S & operator=( const S & ) = default;
| ^
1 error generated.
foundBugs $
Some compiler disagreement there. Perhaps g++ is already at C++23 ?
> I have no idea which compiler is right here,
Nor do I, but this has drifted from cobol to C++.
Should I write a new bug report ?
[Bug cobol/120554] libgcobol meets clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120554
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
||redi at gcc dot gnu.org
--- Comment #6 from Jakub Jelinek ---
This boils down to
struct S {
unsigned int s;
S () : s (0) {}
constexpr S &operator= (const S &) = default;
};
i.e. when the default ctor is not constexpr, but defaulted assignment operator
is constexpr.
I have no idea which compiler is right here, though admittedly what libgcobol
does makes no sense to me, if no constructor is marked constexpr, one can't
construct objects of such type during constant expression evaluation and so it
is either wrong
or just useless to mark the copy assignment operator constexpr.
Note, adding any other constexpr ctor to the structure makes it accepted by
clang,
e.g.
constexpr S (int, int, int) : s (42) {}
[Bug cobol/120554] libgcobol meets clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120554 David Binderman changed: What|Removed |Added CC||rdubner at gcc dot gnu.org --- Comment #5 from David Binderman --- (In reply to David Binderman from comment #1) > Adding original author of code. Second try. git blame now says: c4d0f4c499c4 (Robert Dubner 2025-05-02 16:56:52 -0400 515) constexpr cbl_declarative_t& operator=(const cbl_declarative_t&) = default;
[Bug cobol/120554] libgcobol meets clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120554 --- Comment #4 from David Binderman --- (In reply to Sam James from comment #2) > As jwakely explained before, you cannot use git blame and friends on a > shallow clone. Oh dear, this again. It might be worth mentioning on page https://gcc.gnu.org/git.html that the git history covers over 33 years and currently consumes about 2.8 Gig of disk space. For folks on slow internet links, it takes quite some time to download. It looks to me like there is an opportunity for a git history that only covers the last five years or so. Perhaps a split into git-current and git-old would be a good idea ?
[Bug cobol/120554] libgcobol meets clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120554 Richard Biener changed: What|Removed |Added Keywords||build --- Comment #3 from Richard Biener --- I wonder why this is not catched by out -std=.. setting on the host compiler?
[Bug cobol/120554] libgcobol meets clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120554 Sam James changed: What|Removed |Added CC|pzheng at gcc dot gnu.org | --- Comment #2 from Sam James --- (In reply to David Binderman from comment #0) > git blame says: > > ^dc501cb0d (Pengxuan Zheng 2025-05-07 10:47:37 -0700 515) constexpr > cbl_declarative_t& operator=(const cbl_declarative_t&) = default; > > Suggest rework code to be compatible with earlier language standards. As jwakely explained before, you cannot use git blame and friends on a shallow clone.
[Bug cobol/120554] libgcobol meets clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120554 David Binderman changed: What|Removed |Added CC||pzheng at gcc dot gnu.org --- Comment #1 from David Binderman --- Adding original author of code.
