[Bug cobol/119324] cppcheck meets /cobol/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119324 --- Comment #10 from Robert Dubner --- Yes, thank you. I don't mean to seem like I am being argumentative. I can't help but note that your selected commands generated three lines of output from a 50K cppcheck.list file that is 766 lines long. That seems...odd. That's a lot of what you apparently regard as false positives or unimportant. It's hard for me to know, from a standing start, which options to cppcheck are relevant, and which lines of output to regard as important. But what you posted here is extremely helpful.
[Bug c++/118829] [modules] ICE in add_indirects emitting template typedef struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118829 Nathaniel Shead changed: What|Removed |Added CC||cjangus at gmail dot com --- Comment #3 from Nathaniel Shead --- *** Bug 120411 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/116588] [14 Regression] wrong code with -O2 -fno-vect-cost-model -fno-tree-dominator-opts -fno-tree-fre --param=vrp-block-limit=0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116588 --- Comment #12 from Andrew Macleod --- (In reply to Andrew Macleod from comment #10) > (In reply to Jakub Jelinek from comment #9) > > Andrew, do you plan to backport this? > > Wasn't planning to. Although the fast VRP pass exists in GCC 14, there is > no way to call it or test it. There were also a lot of other changes made to > the pass as well to make it work well that I don't intend to backport. s. Do we want to port this change back to gcc 14? I asn't going to because there is no way for the pass to be invoked.. no flag can be specified to turn it on, it would require a code change to invoke it. That said, its pretty easy to port back if you want. We should either do that, or close it as wont fix. what is your preference
[Bug c++/120414] ICE in module serialization - bad file data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120414 Nathaniel Shead changed: What|Removed |Added Last reconfirmed||2025-05-23 Blocks||103524 Assignee|unassigned at gcc dot gnu.org |nshead at gcc dot gnu.org Keywords||rejects-valid Ever confirmed|0 |1 CC||nshead at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Nathaniel Shead --- Confirmed. We error when reading an unnamed 'tt_data_member' for 'Derived'; it looks to be that we missed handling using-decls on stream-in here. The following patch fixes the issue locally, I'll test it more thoroughly and submit when I get a chance: diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc index 13f8770b7bd..17c040d26b0 100644 --- a/gcc/cp/module.cc +++ b/gcc/cp/module.cc @@ -10512,7 +10512,8 @@ trees_in::tree_node (bool is_use) res = lookup_field_ident (ctx, u ()); if (!res -|| TREE_CODE (res) != FIELD_DECL +|| (TREE_CODE (res) != FIELD_DECL +&& TREE_CODE (res) != USING_DECL) || DECL_CONTEXT (res) != ctx) res = NULL_TREE; } Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 [Bug 103524] [meta-bug] modules issue
[Bug cobol/119454] gcobol: error: unrecognized command-line option ‘-save-temps’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119454 James K. Lowden changed: What|Removed |Added Last reconfirmed||2025-05-23 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Assignee|unassigned at gcc dot gnu.org |jklowden at gcc dot gnu.org CC||jklowden at gcc dot gnu.org --- Comment #2 from James K. Lowden --- > The bug report page says to use -v -save-all - but gcobol tells us that this > is not implemented Could you please expand on that a bit? Which is the "bug report page", and where does gcobol state it's not implemented? I see: gcobol: error: unrecognized command-line option ‘-save-all’ If you're referring to the text produced by an internal compiler error, I don't know how that advice can be modified. One day, I would like an option that creates a complete textual dump (in Lisp!) of the GENERIC tree. For now, the best advice for the gcobol user is to use the debugging options described in gcobol.1.
[Bug cobol/119377] cobol.dg/group1/declarative_1.cob fails (segfaults, uninitialised vars)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119377 James K. Lowden changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #19 from James K. Lowden --- Fixed by 92b6485a75cabaf64f1f74ba7ab73a5204c9d0aa .
[Bug libstdc++/120415] [14/15/16 Regression] rejects C++ code since r14-11483
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120415 --- Comment #8 from Jonathan Wakely --- (In reply to Richard Biener from comment #2) > clang 19 says > > > clang-19 t.C -S -std=c++20 > t.C:4:11: error: no viable overloaded '-=' > 4 | __tmp -= __n > | ~ ^ ~~~ > t.C:4:17: error: expected ';' after expression > 4 | __tmp -= __n > | ^ > | ; > > so this possibly was accepts-invalid before? Comment 0 is just a tiny piece of libstdc++ code taken out of context, and so is not valid code, and is nothing to do with the bug. The error I see for the full CommandLineParser.ii file is this: src/CommandLineParser.cc:423:27: required from here src/utils/view.hh:210:15: error: no match for 'operator-' (operand types are 'const hash_set, std::vector > >, hash_set_impl::ExtractFirst, XXHasher, std::equal_to >::Iter, std::vector > >, hash_set_impl::ExtractFirst, XXHasher, std::equal_to >, const std::pair, std::vector > > >' and 'const hash_set, std::vector > >, hash_set_impl::ExtractFirst, XXHasher, std::equal_to >::Iter, std::vector > >, hash_set_impl::ExtractFirst, XXHasher, std::equal_to >, const std::pair, std::vector > > >') This is a completely different error coming from the openmsx code.
[Bug c++/120400] C++ FE optimisations reorder && operands.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120400 --- Comment #13 from Jason Merrill --- Created attachment 61500 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61500&action=edit possible fix Does this fix the issue?
[Bug c++/120412] Modules ICE using decltype and lambda across TUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120412
Nathaniel Shead changed:
What|Removed |Added
Keywords||ice-on-valid-code
Ever confirmed|0 |1
Last reconfirmed||2025-05-23
CC||nshead at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Blocks||103524
--- Comment #1 from Nathaniel Shead ---
Confirmed. Looks like I forgot to put in handling for TU-local values on
re-export for partitions.
(In reply to Cameron Angus from comment #0)
> This may be doing something ill-advised, I believe there are some potential
> issues with lambda type linkage, but anyway it obviously shouldn't be
> crashing the compiler.
And yes, agreed. FWIW with '-Wextra', writing 'm-part.mxx' should get you the
following warning:
a.cpp:14:10: warning: ‘template auto kdeps::fun2(T&&)’ refers to
TU-local entity ‘auto kdeps::fun1(F) [with F = ]’ and cannot be
instantiated in other TUs [-Wtemplate-names-tu-local]
14 | auto fun2(T&&)
| ^~~~
a.cpp:6:10: note: ‘auto kdeps::fun1(F) [with F = ]’ has TU-local
template argument ‘kdeps::’
6 | auto fun1(F)
| ^~~~
a.cpp:11:29: note: ‘kdeps::’ has no name and cannot be differentiated
from similar lambdas in other TUs
11 | using Dodgy = decltype([] {});
| ^
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
[Bug 103524] [meta-bug] modules issue
[Bug c++/120411] ICE compiling module relating to typedef struct {}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120411 Nathaniel Shead changed: What|Removed |Added CC||nshead at gcc dot gnu.org Blocks||103524 Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Nathaniel Shead --- Thanks for the report! It looks like this is a dup of PR118829. *** This bug has been marked as a duplicate of bug 118829 *** Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 [Bug 103524] [meta-bug] modules issue
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
Bug 103524 depends on bug 120411, which changed state.
Bug 120411 Summary: ICE compiling module relating to typedef struct {}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120411
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |DUPLICATE
[Bug c/120416] New: unreachable() missing on win32, but not win64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120416
Bug ID: 120416
Summary: unreachable() missing on win32, but not win64
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: ossman at cendio dot se
Target Milestone: ---
This test program:
> #include
>
> int main(int argc, char** argv)
> {
> unreachable();
> return 0;
> }
Compiles for 32-bit MinGW:
> $ i686-pc-mingw32-gcc -o unreach unreach.c
>
But not for 64-bit MinGW:
> $ x86_64-w64-mingw32-gcc -o unreach unreach.c
> unreach.c: In function 'main':
> unreach.c:5:5: error: implicit declaration of function 'unreachable'
> [-Wimplicit-function-declaration]
> 5 | unreachable();
> | ^~~
Tested with gcc 15.1.
The technical reason is that for 64-bit, gcc's has this at the
start:
> #include_next
This was added in r162479/9b91e4361 for bug 41943. I don't understand why,
though. That bug talks about bogus include paths, not chaining/overriding
headers.
I don't dare revert that commit, though, as MinGW has a very non-trivial
. So they likely rely on that.
On the other hand, they can't rely too much on it, since the 32-bit version has
worked fine without it.
I think bug 119658 takes a more general approach to this issue, as this
difference between 32-bit and 64-bit is not just for .
[Bug other/54750] conflicting float.h on windows using mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54750 Pierre Ossman changed: What|Removed |Added CC||ossman at cendio dot se --- Comment #1 from Pierre Ossman --- Fairly sure this got implemented in r162479 for bug 41943. However, see bug 119658 and bug 120416 for problems.
[Bug cobol/119455] gcobol: needs optimization for direct assignments (don't call into runtime)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119455 James K. Lowden 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 --- > 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. 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.
[Bug fortran/120191] Functions minloc() and maxloc() ignore the "back" parameter when "kind" is present.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120191 --- Comment #21 from Jakub Jelinek --- Fixed also for 13.4.
[Bug libfortran/120196] In findloc2_s* when "back" is true loop goes one more step than needed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120196 --- Comment #8 from Jakub Jelinek --- Fixed also for 13.4.
[Bug cobol/119364] building a cobol cross compiler on i686-linux-gnu targeting x86_64-linux-gnu fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119364 James K. Lowden changed: What|Removed |Added CC||jklowden at gcc dot gnu.org Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #25 from James K. Lowden --- > enum cbl_field_attr_t should use uint64_t That change has made its way into gcc/master. AIUI that was the issue, which is now resolved. I'm closing this PR based on that understanding. Please revive if more remains to be done on it.
[Bug target/110812] Check availability of builtins at expand time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110812 --- Comment #11 from Robin Dapp --- Tried building highway to reproduce and hit another error in fre... Do we have a minimal example for this issue?
[Bug cobol/119324] cppcheck meets /cobol/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119324 James K. Lowden changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2025-05-23 Assignee|unassigned at gcc dot gnu.org |rdubner at gcc dot gnu.org Ever confirmed|0 |1
[Bug c/120417] New: gcc -m32 -O1 codegen error, leading to SIGSEGV, workaround -fno-tree-coalesce-vars
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120417 Bug ID: 120417 Summary: gcc -m32 -O1 codegen error, leading to SIGSEGV, workaround -fno-tree-coalesce-vars Product: gcc Version: 14.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: simonsobisch at gnu dot org Target Milestone: --- Created attachment 61501 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61501&action=edit generated sources, cleaned up, showing this issue This was validated to also happened with gcc-9 to gcc-12 and validated to haopen on multiple cpus and operating systems. If compiled with -O1 -fno-tree-coalesce-vars the program runs as expected and returns zero. If ran with only -O1 the following result is seen (this is linked against libcob from GnuCOBOL 3.2+, but the problematic code is all in the attached code) caller.cob:4: attempt to reference invalid memory address (signal SIGSEGV) The reason is that the second command reorders the executions and executes line 152 (which accesses cob_glob_ptr), then does some init, then 163 (where the cob_glob_ptr is unset -> SIGSEGV). It seems that's an issue with multiple optimizations as -O0 -ftree-coalesce-vars does not show the error. The biggest problem here is that -FORTIFY_SOURCE=2 needs -O1 on many setups and therefore "fortification breaks codegen" :-/ valgrind with -fno-tree-coalesece-vars runs through; if not used ==127523== Memcheck, a memory error detector ==127523== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==127523== Using Valgrind-3.22.0 and LibVEX; rerun with -h for copyright info ==127523== Command: ./a.out ==127523== ==127523== Invalid write of size 4 ==127523==at 0x1093C9: caller_ (caller.c:163) ==127523==by 0x109581: caller (caller.c:60) ==127523==by 0x1095B1: main (caller.c:42) ==127523== Address 0x40 is not stack'd, malloc'd or (recently) free'd ==127523== caller.cob:5: attempt to reference invalid memory address (signal SIGSEGV) Test setuo: * get the attached files * get GnuCOBOL 3.3 dev (either from VCS checkout or a pre-built tarball [1]) * configure/make, then either * install and gcc -m32 -O1 caller.c callee.c -g -lcob && ./a.out * or: gcc -m32 -O1 caller.c callee.c -g libcob/.libs/libcob.so && ./a.out as noted, the error vanishes if either -O1 is not used or -fno-tree-coalesce-vars is added Side note: if you see a better way of code-generation: feel free to send me a direct mail. [1]: https://ci.appveyor.com/api/projects/GitMensch/gnucobol-3-x/artifacts/gnucobol-3.3-dev.tar.gz?job=Image:%20Ubuntu2204
[Bug cobol/119323] cppcheck meets libgcobol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119323 James K. Lowden changed: What|Removed |Added CC||jklowden at gcc dot gnu.org Last reconfirmed||2025-05-23 Status|UNCONFIRMED |WAITING Assignee|unassigned at gcc dot gnu.org |jklowden at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #7 from James K. Lowden --- 1. corrected 2. corrected 3. corrected 4. previously removed 5. previously removed Changes currently pending in local parser branch.
[Bug cobol/120401] gcobol allows arithmetic on alphanumeric fields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120401 James K. Lowden changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |jklowden at gcc dot gnu.org Last reconfirmed||2025-05-23 Status|UNCONFIRMED |ASSIGNED
[Bug cobol/120402] gcobol does not check precedence of PIC characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120402 James K. Lowden changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2025-05-23 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jklowden at gcc dot gnu.org --- Comment #1 from James K. Lowden --- The reference is to Table 10 in ISO/IEC 1989:2023, and the assertion is correct. I am not sure how to reduce Table 10 to a set of rules, given the complexity and many exceptions. ISO would do the world a service by expressing the same rules as regular expressions. (Good luck with that.) Nevertheless, more could be done to screen out invalid pictures. > note: U is nearly identical to N Meaning, U as defined by IBM? It's not in ISO.
[Bug cobol/119935] libcobol fails to build on powerpc64-linux-gnu when explicitly enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119935 James K. Lowden changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rdubner at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2025-05-23 CC||jklowden at gcc dot gnu.org --- Comment #1 from James K. Lowden --- > the little endian build succeeds. Are you saying that powerpc64-linux-gnu fails only when configured for big endian? It is a goal in 2025 for the COBOL FE to build for all 64-bit primary & secondary targets.
[Bug cobol/120244] cobol.dg/cgroup2: more Valgrind issues in tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120244 James K. Lowden changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jklowden at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2025-05-23 CC||jklowden at gcc dot gnu.org
[Bug cobol/119934] cobol builds on sparc64-linux-gnu with test failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119934 James K. Lowden changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rdubner at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2025-05-23 CC||jklowden at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED
[Bug cobol/119933] cobol builds on loongarch64-linux-gnu with test failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119933 James K. Lowden changed: What|Removed |Added CC||jklowden at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rdubner at gcc dot gnu.org Last reconfirmed||2025-05-23 Ever confirmed|0 |1
[Bug cobol/119932] cobol builds on s390x-linux-gnu with test failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119932 James K. Lowden changed: What|Removed |Added CC||jklowden at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |rdubner at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug libstdc++/120386] std::unique_copy uses the output type for comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120386 --- Comment #2 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:1bb7a195e7cf95537534a42e7aa8705cc78eba4e commit r16-849-g1bb7a195e7cf95537534a42e7aa8705cc78eba4e Author: Jonathan Wakely Date: Wed May 21 16:57:59 2025 +0100 libstdc++: Fix concept checks for std::unique_copy [PR120384] This looks to have been wrong since r0-125454-gea89b2482f97aa which introduced the predefined_ops.h. Since that change, the binary predicate passed to std::__unique_copy is _Iter_comp_iter, which takes arguments of the iterator type, not the iterator's value type. This removes the checks from the __unique_copy overloads and moves them into the second overload of std::unique_copy, where we have the original binary predicate, not the adapted one from predefined_ops.h. The third __unique_copy overload currently checks that the predicate is callable with the input range value type and the output range value type. This change alters that, so that we only ever check that the predicate can be called with two arguments of the same type. That is intentional, because calling the predicate with different types is a bug that will be fixed in a later commit (see PR libstdc++/120386). libstdc++-v3/ChangeLog: PR libstdc++/120384 * include/bits/stl_algo.h (__unique_copy): Remove all _BinaryPredicateConcept concept checks. (unique_copy): Check _BinaryPredicateConcept in overload that takes a predicate. * testsuite/25_algorithms/unique_copy/120384.cc: New test. Reviewed-by: Tomasz KamiÅski
[Bug cobol/119975] clock_gettime in genapi.cc is unportable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119975 James K. Lowden changed: What|Removed |Added Last reconfirmed||2025-05-23 Assignee|unassigned at gcc dot gnu.org |rdubner at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #1 from James K. Lowden --- IMO we're better off using the Linux perf tool for timing/performance measurement. If we want to keep bespoke measurements for some reason, we can hide them in a preprocessor macro.
[Bug cobol/119896] Assertion failed: e->type == SymField, function cbl_field_of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119896 James K. Lowden changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2025-05-23 CC||jklowden at gcc dot gnu.org Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |jklowden at gcc dot gnu.org --- Comment #1 from James K. Lowden --- It seems likely to me that this is a cascading error stemming perhaps from a big endian host. I will need to see the debug output to address it. I'm planning to use cfarm for that. The assertions in cbl_field_of (and brethren) are correct. At point of call, the logic has already confirmed that the symbol is of type field. Anything else is a logic error.
[Bug libstdc++/120384] [12/13/14/15/16] _BinaryPredicateConcept checks in std::unique_copy are wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120384 --- Comment #1 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:1bb7a195e7cf95537534a42e7aa8705cc78eba4e commit r16-849-g1bb7a195e7cf95537534a42e7aa8705cc78eba4e Author: Jonathan Wakely Date: Wed May 21 16:57:59 2025 +0100 libstdc++: Fix concept checks for std::unique_copy [PR120384] This looks to have been wrong since r0-125454-gea89b2482f97aa which introduced the predefined_ops.h. Since that change, the binary predicate passed to std::__unique_copy is _Iter_comp_iter, which takes arguments of the iterator type, not the iterator's value type. This removes the checks from the __unique_copy overloads and moves them into the second overload of std::unique_copy, where we have the original binary predicate, not the adapted one from predefined_ops.h. The third __unique_copy overload currently checks that the predicate is callable with the input range value type and the output range value type. This change alters that, so that we only ever check that the predicate can be called with two arguments of the same type. That is intentional, because calling the predicate with different types is a bug that will be fixed in a later commit (see PR libstdc++/120386). libstdc++-v3/ChangeLog: PR libstdc++/120384 * include/bits/stl_algo.h (__unique_copy): Remove all _BinaryPredicateConcept concept checks. (unique_copy): Check _BinaryPredicateConcept in overload that takes a predicate. * testsuite/25_algorithms/unique_copy/120384.cc: New test. Reviewed-by: Tomasz KamiÅski
[Bug cobol/119454] gcobol: error: unrecognized command-line option ‘-save-temps’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119454 --- Comment #3 from Simon Sobisch --- The "how to create a bug report" is identical for all GCC frontends (so far). It is documented at https://gcc.gnu.org/bugs/#detailed > In general, all the information we need can be obtained by collecting the > command line below, as well as its output and the preprocessed file it > generates. > >gcc -v -save-temps all-your-options source-file Using it leads to the expected output to stdout, but there are no intermediate files created. Compare that to plain "gcc" on a C file which creates source.i source.s source.o
[Bug cobol/119254] ICE on unterminated cobol string due to use of cbl_internal_error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119254 James K. Lowden changed: What|Removed |Added Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jklowden at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED CC||jklowden at gcc dot gnu.org --- Comment #2 from James K. Lowden --- Fixed, probably by fba34a0cc55488ad89becf81cf2c9ac517d244d4. The scanner returns an error token NO_CONDITION. The call to cbl_internal_error remains as a reminder, but is not reached because of the return statement.
[Bug cobol/120402] gcobol does not check precedence of PIC characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120402 --- Comment #2 from Simon Sobisch --- Yes, U as per currently IBM (the COBOL Development group is in the process of adding it for the next standard). To handle the precedence - feel free to copy GnuCOBOL's implementation in cobc/tree.c, especially (valid_char_order) + (cb_build_picture), also handling U and GCOS' extension L.
[Bug cobol/120328] Building gcobol fails in non English systems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120328 James K. Lowden changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jklowden at gcc dot gnu.org Status|UNCONFIRMED |WAITING CC||jklowden at gcc dot gnu.org Last reconfirmed||2025-05-23 Ever confirmed|0 |1 --- Comment #2 from James K. Lowden --- I modified how Flex is invoked in Make-lang.in on our local parser branch. The fix will be applied to gcc/master RSN. The build will fail according to the exit status of flex, not the number of unexpected messages it produces. The "dangerous trailing context" messages, which I believe are spurious, are suppressed. The mistake was to treat unrecognized messages (including the same warning in a different language) as errors.
[Bug libstdc++/120390] [12/13/14/15/16 Regression] Request to improve error with private destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120390 Jonathan Wakely changed: What|Removed |Added Status|NEW |ASSIGNED Target Milestone|--- |12.5 Known to fail||15.1.0, 7.5.0 Priority|P3 |P4 Severity|normal |minor Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Summary|Request to improve error|[12/13/14/15/16 Regression] |with private destructor |Request to improve error ||with private destructor Known to work||6.5.0 --- Comment #7 from Jonathan Wakely --- I pulled at this thread and ended up unravelling parts of std::vector (Bug 94831, Bug 40192, Bug 120397) I'm just going to make a minimal change for this which would be suitable for backports, because this is a diagnostic regression. Then I'll rewrite std::_Destroy and std::_Destroy_n on trunk, after deprecating support for std::vector which should never have been supported in the first place.
[Bug cobol/119887] runtime-switches are not documented / implemented (and don't pass NC211A and others)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119887 James K. Lowden changed: What|Removed |Added Status|NEW |SUSPENDED Assignee|unassigned at gcc dot gnu.org |jklowden at gcc dot gnu.org
[Bug cobol/119768] FE: parsing PIC N and NAT is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119768 James K. Lowden changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jklowden at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2025-05-23 Status|UNCONFIRMED |ASSIGNED
[Bug cobol/119793] FR FE (parser): addition of BASED-STORAGE SECTION (Fujitsu)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119793 James K. Lowden changed: What|Removed |Added Status|NEW |SUSPENDED
[Bug cobol/119639] runtime switches in SPECIAL NAMES not recognised (parser issue)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119639 James K. Lowden changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from James K. Lowden --- Switches are documented. NIST tests need configuration with EXEC85, easiest via nist/Makefile in gitlab.cobolworx.com. *** This bug has been marked as a duplicate of bug 119887 ***
[Bug cobol/119887] runtime-switches are not documented / implemented (and don't pass NC211A and others)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119887 --- Comment #3 from James K. Lowden --- *** Bug 119639 has been marked as a duplicate of this bug. ***
[Bug cobol/119455] gcobol: needs optimization for direct assignments (don't call into runtime)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119455 --- Comment #3 from rguenther at suse dot de --- > Am 23.05.2025 um 16:54 schrieb jklowden at gcc dot gnu.org > : > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119455 > > James K. Lowden 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 --- >> 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.
[Bug cobol/119805] FE: COMP-5 / COMP-X issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119805 James K. Lowden changed: What|Removed |Added Last reconfirmed||2025-05-23 Assignee|unassigned at gcc dot gnu.org |jklowden at gcc dot gnu.org Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 --- Comment #3 from James K. Lowden --- Fixed in cobolworx repository. Merge with gcc/master pending.
[Bug libstdc++/120407] [12/13/14/15/16 Regression] Binary size manifold for static linked MinGW target (e.g. std::__throw_system_error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120407 --- Comment #7 from Daniel Starke --- Created attachment 61503 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61503&action=edit preprocessed file at regression
[Bug cobol/119633] compile error for debug-module USE FOR DEBUGGING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119633 James K. Lowden changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jklowden at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2025-05-23 --- Comment #1 from James K. Lowden --- I will implement old-fashioned debugging per IBM and ISO as time permits, sooner for the first user who needs it for production purposes. Else I agree that at least the compiler shouldn't mind. It can treat indicator column 'D' as a comment with a warning.
[Bug c++/120400] C++ FE optimisations reorder && operands.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120400 Iain Sandoe changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2025-05-23 Status|UNCONFIRMED |NEW --- Comment #14 from Iain Sandoe --- (In reply to Jason Merrill from comment #13) > Created attachment 61500 [details] > possible fix > > Does this fix the issue? Yes, it does .. that's the kind of thing I was hoping for ... we also need the changes below - which I'll post separately. @@ -5017,7 +5020,7 @@ cp_coroutine_transform::build_ramp_function () tree frame_cleanup = push_stmt_list (); tree do_fr_cleanup = build1_loc (loc, TRUTH_NOT_EXPR, boolean_type_node, iarc_x); - do_fr_cleanup = build2_loc (loc, TRUTH_AND_EXPR, boolean_type_node, + do_fr_cleanup = build2_loc (loc, TRUTH_ANDIF_EXPR, boolean_type_node, coro_before_return, do_fr_cleanup); r = build3 (COND_EXPR, void_type_node, do_fr_cleanup, delete_frame_call, void_node); @@ -5109,7 +5112,7 @@ cp_coroutine_transform::build_ramp_function () tree do_cleanup = build1_loc (loc, TRUTH_NOT_EXPR, boolean_type_node, iarc_x); do_cleanup - = build2_loc (loc, TRUTH_AND_EXPR, boolean_type_node, + = build2_loc (loc, TRUTH_ANDIF_EXPR, boolean_type_node, coro_before_return, do_cleanup); r = build3_loc (loc, COND_EXPR, void_type_node, do_cleanup, parm.fr_copy_dtor, void_node); @@ -5169,7 +5172,7 @@ cp_coroutine_transform::build_ramp_function () tree promise_cleanup = push_stmt_list (); tree do_cleanup = build1_loc (loc, TRUTH_NOT_EXPR, boolean_type_node, iarc_x); - do_cleanup = build2_loc (loc, TRUTH_AND_EXPR, boolean_type_node, + do_cleanup = build2_loc (loc, TRUTH_ANDIF_EXPR, boolean_type_node, coro_before_return, do_cleanup); r = build3 (COND_EXPR, void_type_node, do_cleanup, promise_dtor, void_node);
[Bug libstdc++/120407] [12/13/14/15/16 Regression] Binary size manifold for static linked MinGW target (e.g. std::__throw_system_error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120407 --- Comment #6 from Daniel Starke --- Created attachment 61502 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61502&action=edit preprocessed file before regression
[Bug libstdc++/120407] [12/13/14/15/16 Regression] Binary size manifold for static linked MinGW target (e.g. std::__throw_system_error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120407 --- Comment #9 from Andrew Pinski --- (In reply to Daniel Starke from comment #8) > (In reply to Andrew Pinski from comment #2) > > Can you provide the preprocessed source? > > > > Also since you are linking to a static binary, can you attach the before and > > after linker map? > > The linker map before the regression is 925 KiB and at regression 3877 KiB. > So unfortunately, I am unable to upload it here. Any recommended place for > this upload? Or can I zip it? Zip it up is fine.
[Bug cobol/119633] compile error for debug-module USE FOR DEBUGGING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119633 --- Comment #2 from Simon Sobisch --- Nearly agreed. As long as there is no "WITH DEBUGGING" active (which you can warn or even error on) an indicator D is, just as a * or a / an indicator defining that the line has no executable code. It can also "overlook" the USE FOR DEBUGGING paragraphs, only executing them on explicit PERFORM, that would solve the parser issue and let existing programs be compiled without a recode.
[Bug cobol/119597] SEGV on Cobol "hello world" on Power
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119597 James K. Lowden changed: What|Removed |Added CC||jklowden at gcc dot gnu.org Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rdubner at gcc dot gnu.org
[Bug cobol/119461] record layout done in odd ways
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119461 James K. Lowden changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug cobol/119215] -Wodr and -Wlto-type-mismatch issues in cobol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119215
James K. Lowden changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2025-05-23
Assignee|unassigned at gcc dot gnu.org |jklowden at gcc dot
gnu.org
--- Comment #7 from James K. Lowden ---
Unfortunately ODR lto warnings are hard to diagnose because the system reports
only that two definitions exist in two TUs, but not which ones, nor how they
differ. It would seem to be an enhancement opportunity.
I am skeptical of the accuracy of the report. Everything seems to boil down to
YYLTYPE and YDFLTYPE, which are the same, and hard to get wrong:
typedef struct YYLTYPE YYLTYPE;
struct YYLTYPE
{
int first_line;
int first_column;
int last_line;
int last_column;
};
Normally those definitions are confined to the Bison header-file output, but
because locations are used in places that don't need (or can't use) those
headers, I copied them to dbldiag.h, as a convenience.
I'm no fan of the typedef line, which isn't needed in C++, but that text
appears verbatim in the Bison output for cdf.y and parse.y.
The best suggestion I've gotten so far is to trap on warn_odr and examine the
types in gdb. That seems like a commendable idea, skeptic or no.
[Bug cobol/119457] gcobol: big codegen for simple STRING plus malloc/free (and missing optimization)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119457 --- Comment #2 from Simon Sobisch --- I tend to disagree as the referenced one is explicit about MOVE (and of course using matching type assignments and functions, possibly split like for strings using memcpy+memset for space is most reasonable because COBOL programs have huge amounts of those), while this is for STRING. This _specific_ STRING can internally be handled as MOVE (because type and length for source and dest are identical), which may be an optimization that can be done before GIMPLE is involved (a follow-up optimisation would be finding if this is also true for one or multiple fixed-length sources that can be handled as multiple MOVE with ref-mod to dest). If the parser internally transfers them, then those will be optimized whenever alphanumeric MOVEs are optimized (possibly Bob's task). The "internal split for fixed-size source to MOVEs" may be branched out to a separate issue (which also doesn't need to be done now [I guess I still haven't implemented that for GC :-)]. Again to this issue: that was about how STRING is handled - there are a lot of malloc/free which may be an easy replace with local storage instead. I suggest to keep this open up for this specific part (and possibly handle that "a bit earlier").
[Bug cobol/119634] compile error: sorry, unimplemented: Global declarative _DECLARATIVES_EVAL1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119634 James K. Lowden changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Severity|normal |enhancement Last reconfirmed||2025-05-23 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |jklowden at gcc dot gnu.org --- Comment #2 from James K. Lowden --- GLOBAL declaratives are not currently implemented. Implementation was deferred pending actual need because it required changes to the compiler implementation. Declaratives underwent an overhaul in the last month and will see more attention soon for performance reasons. Also slated for attention is PERFORM Format 3, which has "private declaratives" local to the PERFORM statement.
[Bug cobol/119638] WRITE FROM x BEFORE Y raises compile error (SQ207M)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119638 James K. Lowden changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #3 from James K. Lowden --- NIST SQ207M compiles and runs using https://gitlab.cobolworx.com/COBOLworx/gcc-cobol/-/blob/master+cobol/gcc/cobol/nist/Makefile
[Bug libstdc++/120407] [12/13/14/15/16 Regression] Binary size manifold for static linked MinGW target (e.g. std::__throw_system_error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120407 --- Comment #8 from Daniel Starke --- (In reply to Andrew Pinski from comment #2) > Can you provide the preprocessed source? > > Also since you are linking to a static binary, can you attach the before and > after linker map? The linker map before the regression is 925 KiB and at regression 3877 KiB. So unfortunately, I am unable to upload it here. Any recommended place for this upload? Or can I zip it?
[Bug cobol/119595] Port libgcobol to 32-bit architectures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119595 James K. Lowden changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rdubner at gcc dot gnu.org Status|NEW |ASSIGNED CC||jklowden at gcc dot gnu.org
[Bug cobol/119524] cobol: gg_printf assumes target characteristics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119524 James K. Lowden changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug cobol/119455] gcobol: needs optimization for direct assignments (don't call into runtime)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119455 --- Comment #4 from James K. Lowden --- *** Bug 119457 has been marked as a duplicate of this bug. ***
[Bug cobol/119217] cobol: build broken on non-linux by unguarded use of Linux-specific facilities.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119217 James K. Lowden changed: What|Removed |Added Status|NEW |WAITING
[Bug cobol/119455] gcobol: needs optimization for direct assignments (don't call into runtime)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119455 James K. Lowden changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug testsuite/120418] New: embed testcases issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120418
Bug ID: 120418
Summary: embed testcases issue
Product: gcc
Version: 15.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: alexey.lapshin at espressif dot com
Target Milestone: ---
Almost all testcases for "#embed" are failing. Because they use "#embed
__FILE__".
The issue does not appear for such tests in case the working directory is the
same as the source's file directory. Or full path to the source file was passed
to GCC.
Explanation:
1. cd ./gcc/testsuite
2. gcc -std=c23 -Wconversion ./gcc.dg/cpp/embed-10.c
3. get "fatal error: ./gcc.dg/cpp/embed-10.c: No such file or directory"
Why does this happen?
1. __FILE__ macro is "./gcc.dg/cpp/embed-10.c"
2. "#embed __FILE__" acts like "#include" and start to look up the file from
source file directory. And looking for "./gcc.dg/cpp/./gcc.dg/cpp/embed-10.c".
I also tested it with "gcc:15.1.0" docker image, and strace gives the same as
for my toolchain. ("strace -f gcc -std=c23 -Wconversion
./gcc.dg/cpp/embed-10.c"):
[pid 167] openat(AT_FDCWD, "./gcc.dg/cpp/./gcc.dg/cpp/embed-10.c",
O_RDONLY|O_NOCTTY) = -1 ENOENT (No such file or directory)
[pid 167] openat(AT_FDCWD, "./gcc.dg/cpp/embed-10.c", O_RDONLY) = 4
[pid 167] newfstatat(4, "", {st_mode=S_IFREG|0664, st_size=305, ...},
AT_EMPTY_PATH) = 0
[pid 167] read(4, "/* This is a comment with some U"..., 4096) = 305
[pid 167] read(4, "", 4096) = 0
[pid 167] write(2, "\33[01m\33[K./gcc.dg/cpp/embed-10.c:"...,
327./gcc.dg/cpp/embed-10.c:6:8: fatal error: ./gcc.dg/cpp/embed-10.c: No such
file or directory
I guess testcases should be fixed, because gcc acts as expected
[Bug testsuite/120418] embed testcases issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120418 --- Comment #2 from Jakub Jelinek --- Why do you do that? The tests are meant to be tested with dejagnu, using make check. That passes absolute filenames, which works just fine.
[Bug testsuite/120418] embed testcases issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120418 --- Comment #1 from Alexey --- I found this issue because failures appeared when testing a toolchain. I wonder why these tests are not failing for others?
[Bug testsuite/120418] embed testcases issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120418 --- Comment #3 from Alexey --- I use dejagnu 1.6.3 for testing. And they fails in this way
[Bug cobol/119211] [15/16 Regression] Cobol GCC 15 release checklist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119211 James K. Lowden changed: What|Removed |Added Status|NEW |ASSIGNED CC||jklowden at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jklowden at gcc dot gnu.org --- Comment #13 from James K. Lowden --- A few uses of getenv(3) are still in the parser for debugging. I will remove them. > simply "moving" LICENSE from the FE to libgcobol Is this still required? Will do if so. > run the NIST Cobol testsuite and a contrib/download_nist script I plan to add a check-nist target to gcc/Makefile.in. I think portability issues are addressed more comprehensively by other PRs. I think everything else mentioned was addressed en route to gcc 15. Please correct me if I'm wrong. My plan is to clean up the issues mentioned above as outstanding, and then close this PR.
[Bug testsuite/120418] embed testcases issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120418 --- Comment #5 from Jakub Jelinek --- I use the same dejagnu and they don't fail. And looking at e.g. the gcc-testresults mailing lists, they don't fail for others either (there are some pch/embed-1.c failures in freebsd results but that looks like PCH issue on FreeBSD, not anything else, and some issues on AVR (but I assume that is because of 8-bit int, which is not valid in C). Are you configuring in the source directory, or using some custom board file to override stuff?
[Bug testsuite/120418] embed testcases issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120418 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2025-05-23 Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 --- Comment #4 from Andrew Pinski --- Can you provide the full dejagnu log for the running of the testcase? make check-gcc RUNTESTFLAGS="cpp.exp=embed-10.c" should run the one testcase again. I use 1.6.3 also and they work for me: [apinski@xeond2 gcc]$ dejagnu --version dejagnu auxiliary launcher (DejaGnu) 1.6.3
[Bug cobol/119217] cobol: build broken on non-linux by unguarded use of Linux-specific facilities.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119217 --- Comment #23 from Iain Sandoe --- what is the "waiting" status for? ( I don't see any trunk commits recently for us to test )
[Bug cobol/119457] gcobol: big codegen for simple STRING plus malloc/free (and missing optimization)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119457 James K. Lowden changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from James K. Lowden --- I don't see how this can be treated independently of PR 119455, which has extensive comments. The use of the library and type system are two sides of the same coin. *** This bug has been marked as a duplicate of bug 119455 ***
[Bug libstdc++/120407] [12/13/14/15/16 Regression] Binary size manifold for static linked MinGW target (e.g. std::__throw_system_error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120407 --- Comment #10 from Daniel Starke --- Created attachment 61504 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61504&action=edit linker maps before and at regression
[Bug cobol/119377] cobol.dg/group1/declarative_1.cob fails (segfaults, uninitialised vars)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119377 Iain Sandoe changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #20 from Iain Sandoe --- (In reply to James K. Lowden from comment #19) > Fixed by 92b6485a75cabaf64f1f74ba7ab73a5204c9d0aa . Some aspects of this might well be fixed by the commit (r16-698-g92b6485a75caba) - but not all - We still have ≈ 90 fails on x86_64-darwin all of this form: FAIL: cobol.dg/group1/declarative_1.cob -O0 (test for excess errors) Excess errors: /src-local/gcc-master/gcc/testsuite/cobol.dg/group1/declarative_1.cob:51:22: sorry, unimplemented: SECTION segment '' is not ISO syntax with two exceptions: compiler exited with status 1 FAIL: cobol.dg/group2/INSPECT_ISO_Example_7.cob -Os (test for excess errors) Excess errors: /src-local/gcc-master/gcc/testsuite/cobol.dg/group2/INSPECT_ISO_Example_7.cob:40:20: sorry, unimplemented: SECTION segment '^AÌLøÿ^]^A^Y' is not ISO syntax see, for example: https://gcc.gnu.org/pipermail/gcc-testresults/2025-May/847791.html https://gcc.gnu.org/pipermail/gcc-testresults/2025-May/847788.html (which are both from revisions after that commit) I have re-opened this bug - but could file a new one if you'd prefer?
[Bug libstdc++/120407] [12/13/14/15/16 Regression] Binary size manifold for static linked MinGW target (e.g. std::__throw_system_error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120407 Andrew Pinski changed: What|Removed |Added Ever confirmed|1 |0 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=109299 Status|WAITING |UNCONFIRMED --- Comment #11 from Andrew Pinski --- So what it seems like it is pulling in more of libstdc++.a than before. Maybe due to inlining differences. We could revert the change for 12 branch. Note I suspect GCC 15 and 16 are ok though due to how branches to unreachable are now skipped over for inlining heurstics. Did you see this size increase without an artificial testcase? I am still trying to figure out how important it is to revert the patch or not.
[Bug middle-end/120378] Support narrowing clip idiom
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120378 --- Comment #2 from Richard Biener --- So what does vnclipu do? But yes, the way to fix is to add an optab for this, a vectorizer pattern and/or a match rule (in case that insn is a thing for non-vector as well).
[Bug driver/120376] -fmalloc-dce=0 is not work as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120376 Richard Biener changed: What|Removed |Added Keywords||accepts-invalid Component|tree-optimization |driver --- Comment #3 from Richard Biener --- We shouldn't accept =0 indeed.
[Bug c/120380] [14/15/16 Regression] internal compiler error: error reporting routines re-entered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120380 Richard Biener changed: What|Removed |Added Priority|P3 |P4
[Bug c/120382] [14/15/16 Regression] ICE with hardbool attribute and undeclared variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120382 Richard Biener changed: What|Removed |Added Priority|P3 |P4
[Bug tree-optimization/120383] Improving early break unrolled sequences with Adv. SIMD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120383 --- Comment #1 from Richard Biener --- Sure, I'm OK with an optab for it. So it's like (half-type)((unsigned)(a + b) >> (sizeof(a)*4))? Does the instruction also work for scalars?
[Bug libstdc++/120384] [12/13/14/15/16] _BinaryPredicateConcept checks in std::unique_copy are wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120384 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |12.5
[Bug c++/120413] C++ OpenMP 'target' SIGSEGV in 'gcc/cp/semantics.cc:finish_omp_target_clauses_r'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120413
--- Comment #1 from Tobias Burnus ---
Technically, this is a [12/13/14/15/16 Regressions], unsurprising as the code
has been added in GCC 12.
* * *
The resulting code for the target regions like:
struct array arr;
<;
try
{
}
finally
{
array::~array (&arr);
}
[Where cleanup_point contains some try-catch calls for the constructor (and
destructor), which expanded also wrap around the try-finally block.]
[Bug c++/120415] [14/15 Regression] rejects C++ code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120415 Richard Biener changed: What|Removed |Added Target Milestone|--- |14.3 --- Comment #2 from Richard Biener --- clang 19 says > clang-19 t.C -S -std=c++20 t.C:4:11: error: no viable overloaded '-=' 4 | __tmp -= __n | ~ ^ ~~~ t.C:4:17: error: expected ';' after expression 4 | __tmp -= __n | ^ | ; so this possibly was accepts-invalid before?
[Bug c++/120415] [14/15 Regression] rejects C++ code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120415 --- Comment #3 from Matthias Klose --- taken from openmsx 20.0
[Bug c++/120400] C++ FE optimisations reorder && operands.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120400
--- Comment #12 from Iain Sandoe ---
(In reply to Richard Biener from comment #11)
> D_V_E? DECL_VALUE_EXPR?
yes..
> I guess we should indeed treat those as having
> side-effects.
struct F {
bool b;
};
int foo (F *a)
{
if (a && !a->b)
return 6;
return 42;
}
Works as expected - but I do not see TREE_SIDE_EFFECTS set on any part of the
component ref expression.
I was going to investigate "looking through" expressions with a D_V_E and
applying the rules to the latter .. but not got to that yet.
> But without actually setting TREE_SIDE_EFFECTS that's hard to
> properly propagate everywhere, so yeah - I suggest doing that.
Hmm - seems a bit of a big hammer .. but.
[Bug libstdc++/120407] [12/13/14/15/16 Regression] Binary size manifold for static linked MinGW target (e.g. std::__throw_system_error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120407 --- Comment #3 from Jonathan Wakely --- Similar code size increase is seen for a x86_64-linux target too. $ size reg-12.2 reg-12.3 textdata bss dec hex filename 818932872 152 84917 14bb5 reg-12.2 816931 242967240 848467 cf253 reg-12.3 The static libs aren't significantly different: $ ls -l 12.[23]/lib64/libstdc++.a -rw-r--r--. 1 jwakely jwakely 43913706 Aug 31 2022 12.2/lib64/libstdc++.a -rw-r--r--. 1 jwakely jwakely 43733084 May 10 2023 12.3/lib64/libstdc++.a And I don't see any significant differences when running 'size' on those two archives (some objects got a little bigger, some got a little smaller).
[Bug libstdc++/120415] [14/15/16 Regression] rejects C++ code since r14-11483
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120415 Jakub Jelinek changed: What|Removed |Added Summary|[14/15/16 Regression] |[14/15/16 Regression] |rejects C++ code|rejects C++ code since ||r14-11483 Priority|P3 |P1 Last reconfirmed||2025-05-23 Ever confirmed|0 |1 CC||redi at gcc dot gnu.org Status|UNCONFIRMED |NEW --- Comment #5 from Jakub Jelinek --- Bisected to r14-11483-g5a830c6cd54d376ee23043381c6ed761559e1e08 Now the question is if openmsx does something invalid or libstdc++ relies on something not guaranteed, and even if the former, whether the change is appropriate for release branch or not.
[Bug libstdc++/120407] [12/13/14/15/16 Regression] Binary size manifold for static linked MinGW target (e.g. std::__throw_system_error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120407 --- Comment #5 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #4) > That should be r12-g00ac6fa3f2a (as Andrew linked to). Gah, I mean r12-9330-g00ac6fa3f2a54f
[Bug libstdc++/120415] [14/15/16 Regression] rejects C++ code since r14-11483
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120415
--- Comment #7 from Jakub Jelinek ---
I think this is on
using GroupedItems = hash_map, XXHasher>;
static void printItemMap(const GroupedItems& itemMap)
{
auto printSet = to_vector(view::transform(itemMap, [](auto& p) {
return strCat(formatSet(p.second, 15), ' ',
formatHelpText(p.first, 50, 20));
}));
ranges::sort(printSet);
for (const auto& s : printSet) {
cout << s << '\n';
}
}
[Bug libstdc++/120415] [14/15/16 Regression] rejects C++ code since r14-11483
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120415 --- Comment #6 from Jonathan Wakely --- I suspect this is a similar problem to Bug 120325 i.e. an iterator type which is not compatible with C++20 rules, and needs to be fixed or opt-out of being a C++20 random access iterator.
[Bug libstdc++/120407] [12/13/14/15/16 Regression] Binary size manifold for static linked MinGW target (e.g. std::__throw_system_error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120407 --- Comment #4 from Jonathan Wakely --- (In reply to Daniel Starke from comment #0) > Compiling the following C++ code for mingw-w64 using `-O2 -s -static` > creates a 896 KiB executable instead of 119 KiB since git commit > releases/gcc-12.2.0-633-g00ac6fa3f2a. That should be r12-g00ac6fa3f2a (as Andrew linked to). That was backported from r13-6915-gbf78b43873b0b7
[Bug tree-optimization/120357] [14/15/16 Regression] ICE in vect "error: definition in block 9 does not dominate use in block 3" with early break
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120357 Richard Biener changed: What|Removed |Added Target Milestone|16.0|14.3 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|NEW |ASSIGNED Priority|P3 |P2 --- Comment #5 from Richard Biener --- Confirmed on trunk. I'll eventually have a look.
[Bug middle-end/118694] OpenMP: target/metadirective/teams directive nesting gives error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118694
--- Comment #8 from GCC Commits ---
The master branch has been updated by Tobias Burnus :
https://gcc.gnu.org/g:b3d07ec7ac2ccd935a79b29e1a0e2eb16225286a
commit r16-838-gb3d07ec7ac2ccd935a79b29e1a0e2eb16225286a
Author: Tobias Burnus
Date: Fri May 23 11:30:48 2025 +0200
libgomp.c-c++-common/metadirective-1.c: Expect 'error:' for nvptx compile
[PR118694]
OpenMP's 'target teams' is strictly coupled with 'teams'; if the latter
exists, the kernel is launched in directly with multiple teams. Thus,
the host has to know whether the teams construct exists or not. For
#pragma omp target
#pragma omp metadirective when (device={arch("nvptx")}: teams loop)
it is simple when 'nvptx' offloading is not supported, otherwise it depends
on the default device at runtime as the user code asks for a single team
for
host fallback and gcn offload and multiple for nvptx offload.
In any case, this commit ensures that no FAIL is printed, whatever a
future solution might look like. Instead of a dg-bogus combined with an
'xfail offload_target_nvptx', one an also argue that a dg-error for
'target offload_target_nvptx' would be more appropriate.
libgomp/ChangeLog:
PR middle-end/118694
* testsuite/libgomp.c-c++-common/metadirective-1.c: xfail when
compiling (also) for nvptx offloading as an error is then expected.
[Bug tree-optimization/120403] Can't collapse two equality into one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120403 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2025-05-23 CC||aoliva at gcc dot gnu.org Version|unknown |16.0 --- Comment #2 from Richard Biener --- if-combine would be the place to do this, but for 'int' we might chose to not do that (possibly because of alignment). That is, (long *)&s1 == (long *)&s2
[Bug c++/120415] New: [14/15 Regression] rejects C++ code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120415
Bug ID: 120415
Summary: [14/15 Regression] rejects C++ code
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: doko at gcc dot gnu.org
Target Milestone: ---
works with gcc-14 branch 20250315, fails with the 14.3 release candidate:
$ cat CommandLineParser.ii
struct iterator {
friend void operator-(iterator __x, long __n) {
iterator __tmp = __x;
__tmp -= __n
}
};
$ g++ -g -Wformat -Werror=format-security -Wdate-time -O0 -pthread -std=c++20
-Wall -Wextra -Wundef -Wno-invalid-offsetof -Wunused-macros
-Wmissing-declarations -Wshadow -Wno-sign-conversion -c CommandLineParser.ii
CommandLineParser.ii: In function 'void operator-(iterator, long int)':
CommandLineParser.ii:4:11: error: no match for 'operator-=' (operand types are
'iterator' and 'long int')
4 | __tmp -= __n
| ~~^~
[Bug libstdc++/120407] [12/13/14/15/16 Regression] Binary size manifold for static linked MinGW target (e.g. std::__throw_system_error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120407 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.5
[Bug target/120410] [15/16 Regression] [SH] XTRCT instruction is no longer selected for shift after multiplication
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120410 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Target Milestone|--- |15.2
[Bug c++/120415] [14/15 Regression] rejects C++ code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120415 --- Comment #1 from Matthias Klose --- Created attachment 61498 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61498&action=edit preprocessed source
[Bug cobol/119324] cppcheck meets /cobol/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119324 --- Comment #9 from David Binderman --- (In reply to Robert Dubner from comment #8) > Jim has repaired some of them. I don't know which. See comment 1. > So, in order for cppcheck to be useful, especially in the face of its > extensive configurability, what I find to be Cppcheck's sketchy > documentation, and my current complete ignorance of how to use it, it would > be very useful for me to know exactly how you are using it as a starting > point. gcc $ find trunk/gcc/cobol/ -name \*.cc -print | sort > file.list gcc $ wc -l file.list 14 file.list gcc $ cppcheck --version Cppcheck 2.17.1 gcc $ (date; cppcheck --enable=all --force --language=c++ `cat file.list`;date) > cppcheck.out 2>&1 gcc $ grep passedByValue cppcheck.out trunk/gcc/cobol/copybook.h:133:34: performance: Function parameter 'input' should be passed by const reference. [passedByValue] trunk/gcc/cobol/exceptg.h:77:56: performance: Function parameter 'files' should be passed by const reference. [passedByValue] trunk/gcc/cobol/inspect.h:203:62: performance: Function parameter 'oper' should be passed by const reference. [passedByValue] gcc $ grep clarifyCalculation cppcheck.out gcc $ grep identicalInnerCondition cppcheck.out gcc $ Exact enough ? That's from recent sources in the last 24 hours or so.
[Bug tree-optimization/119835] GCN, nvptx offloading: ICE 'during GIMPLE pass: nrv' in "return value optimizations for functions which return aggregate types"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119835
--- Comment #3 from Richard Biener ---
We can try making gimplification less dependent on the target here and simply
use
else if (!is_gimple_reg_type (TREE_TYPE (result_decl)))
{
...
instead of checking aggregate_value_p. That might in theory pessimize
cases where things like struct { int a; } are returned in a register and
thus SRA would not be able to optimize this since IIRC that cannot handle
GIMPLE return stmts.
But it might be worth a try? Likewise just using AGGREGATE_TYPE_P (..)
above. Note there's correctness parts of aggregate_value_p, like
the TREE_ADDRESSABLE check on the type, but IIRC that's only ever relevant
for aggregate types. The TYPE_TRANSPARENT_AGGR handling might be also
useful to replicate.
Everything else should be only relevant to RTL, but eventually RTL
expansion relies on gimplification handling those cases in some special
way. Who knows.
[Bug libstdc++/120415] [14/15/16 Regression] rejects C++ code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120415 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Created attachment 61499 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61499&action=edit CommandLineParser.C.xz Partially unincluded testcase (with libstdc++ and glibc headers #included, tcl and SDL2 preprocessed).
