[Bug target/99234] [10/11 regression] wrong result for 1.0/3.0 with -O2 -fno-omit-frame-pointer -frounding-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99234 Eric Botcazou changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #22 from Eric Botcazou --- Thanks for reporting the problem.
[Bug target/99234] [10/11 regression] wrong result for 1.0/3.0 with -O2 -fno-omit-frame-pointer -frounding-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99234 --- Comment #21 from CVS Commits --- The releases/gcc-9 branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:838adf69533ca15a259d47dd67e056c4101af368 commit r9-9258-g838adf69533ca15a259d47dd67e056c4101af368 Author: Eric Botcazou Date: Mon Mar 1 07:53:05 2021 +0100 Fix wrong result for 1.0/3.0 at -O2 -fno-omit-frame-pointer -frounding-math This wrong-code PR for the C++ compiler on x86-64/Windows is a regression in GCC 9 and later, but the underlying issue has probably been there since SEH was implemented and is exposed by this comment in config/i386/winnt.c: /* SEH records saves relative to the "current" stack pointer, whether or not there's a frame pointer in place. This tracks the current stack pointer offset from the CFA. */ HOST_WIDE_INT sp_offset; That's not what the (current) Microsoft documentation says; instead it says: /* SEH records offsets relative to the lowest address of the fixed stack allocation. If there is no frame pointer, these offsets are from the stack pointer; if there is a frame pointer, these offsets are from the value of the stack pointer when the frame pointer was established, i.e. the frame pointer minus the offset in the .seh_setframe directive. */ That's why the implementation is correct only under the condition that the frame pointer be established *after* the fixed stack allocation; as a matter of fact, that's clearly the model underpinning SEH, but is the opposite of what is done e.g. on Linux. However the issue is mostly papered over in practice because: 1. SEH forces use_fast_prologue_epilogue to false, which in turns forces save_regs_using_mov to false, so the general regs are always pushed when they need to be saved, which eliminates the offset computation for them. 2. As soon as a frame is larger than 240 bytes, the frame pointer is fixed arbitrarily to 128 bytes above the stack pointer, which of course requires that it be established after the fixed stack allocation. So you need a small frame clobbering one of the call-saved XMM registers in order to generate wrong SEH unwind info. The attached fix makes sure that the frame pointer is always established after the fixed stack allocation by pointing it at or below the lowest used register save area, i.e. the SSE save area, and removing the special early saves in the prologue; the end result is a uniform prologue sequence for SEH whatever the frame size. And it avoids a discrepancy between cases where the number of saved general regs is even and cases where it is odd. gcc/ PR target/99234 * config/i386/i386.c (ix86_compute_frame_layout): For a SEH target, point the hard frame pointer to the SSE register save area instead of the general register save area. Perform only minimal adjustment for small frames if it is initially not correctly aligned. (ix86_expand_prologue): Remove early saves for a SEH target. * config/i386/winnt.c (struct seh_frame_state): Document constraint. gcc/testsuite/ * g++.dg/eh/seh-xmm-unwind.C: New test.
[Bug target/99234] [10/11 regression] wrong result for 1.0/3.0 with -O2 -fno-omit-frame-pointer -frounding-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99234 --- Comment #20 from CVS Commits --- The releases/gcc-10 branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:49a714e59194a7c549aa6657676a1b4be4520650 commit r10-9397-g49a714e59194a7c549aa6657676a1b4be4520650 Author: Eric Botcazou Date: Mon Mar 1 07:53:05 2021 +0100 Fix wrong result for 1.0/3.0 at -O2 -fno-omit-frame-pointer -frounding-math This wrong-code PR for the C++ compiler on x86-64/Windows is a regression in GCC 9 and later, but the underlying issue has probably been there since SEH was implemented and is exposed by this comment in config/i386/winnt.c: /* SEH records saves relative to the "current" stack pointer, whether or not there's a frame pointer in place. This tracks the current stack pointer offset from the CFA. */ HOST_WIDE_INT sp_offset; That's not what the (current) Microsoft documentation says; instead it says: /* SEH records offsets relative to the lowest address of the fixed stack allocation. If there is no frame pointer, these offsets are from the stack pointer; if there is a frame pointer, these offsets are from the value of the stack pointer when the frame pointer was established, i.e. the frame pointer minus the offset in the .seh_setframe directive. */ That's why the implementation is correct only under the condition that the frame pointer be established *after* the fixed stack allocation; as a matter of fact, that's clearly the model underpinning SEH, but is the opposite of what is done e.g. on Linux. However the issue is mostly papered over in practice because: 1. SEH forces use_fast_prologue_epilogue to false, which in turns forces save_regs_using_mov to false, so the general regs are always pushed when they need to be saved, which eliminates the offset computation for them. 2. As soon as a frame is larger than 240 bytes, the frame pointer is fixed arbitrarily to 128 bytes above the stack pointer, which of course requires that it be established after the fixed stack allocation. So you need a small frame clobbering one of the call-saved XMM registers in order to generate wrong SEH unwind info. The attached fix makes sure that the frame pointer is always established after the fixed stack allocation by pointing it at or below the lowest used register save area, i.e. the SSE save area, and removing the special early saves in the prologue; the end result is a uniform prologue sequence for SEH whatever the frame size. And it avoids a discrepancy between cases where the number of saved general regs is even and cases where it is odd. gcc/ PR target/99234 * config/i386/i386.c (ix86_compute_frame_layout): For a SEH target, point the hard frame pointer to the SSE register save area instead of the general register save area. Perform only minimal adjustment for small frames if it is initially not correctly aligned. (ix86_expand_prologue): Remove early saves for a SEH target. * config/i386/winnt.c (struct seh_frame_state): Document constraint. gcc/testsuite/ * g++.dg/eh/seh-xmm-unwind.C: New test.
[Bug target/99234] [10/11 regression] wrong result for 1.0/3.0 with -O2 -fno-omit-frame-pointer -frounding-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99234 --- Comment #19 from CVS Commits --- The master branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:074226d5aa86cd3de517014acfe34c7f69a2ccc7 commit r11-7439-g074226d5aa86cd3de517014acfe34c7f69a2ccc7 Author: Eric Botcazou Date: Mon Mar 1 07:53:05 2021 +0100 Fix wrong result for 1.0/3.0 at -O2 -fno-omit-frame-pointer -frounding-math This wrong-code PR for the C++ compiler on x86-64/Windows is a regression in GCC 9 and later, but the underlying issue has probably been there since SEH was implemented and is exposed by this comment in config/i386/winnt.c: /* SEH records saves relative to the "current" stack pointer, whether or not there's a frame pointer in place. This tracks the current stack pointer offset from the CFA. */ HOST_WIDE_INT sp_offset; That's not what the (current) Microsoft documentation says; instead it says: /* SEH records offsets relative to the lowest address of the fixed stack allocation. If there is no frame pointer, these offsets are from the stack pointer; if there is a frame pointer, these offsets are from the value of the stack pointer when the frame pointer was established, i.e. the frame pointer minus the offset in the .seh_setframe directive. */ That's why the implementation is correct only under the condition that the frame pointer be established *after* the fixed stack allocation; as a matter of fact, that's clearly the model underpinning SEH, but is the opposite of what is done e.g. on Linux. However the issue is mostly papered over in practice because: 1. SEH forces use_fast_prologue_epilogue to false, which in turns forces save_regs_using_mov to false, so the general regs are always pushed when they need to be saved, which eliminates the offset computation for them. 2. As soon as a frame is larger than 240 bytes, the frame pointer is fixed arbitrarily to 128 bytes above the stack pointer, which of course requires that it be established after the fixed stack allocation. So you need a small frame clobbering one of the call-saved XMM registers in order to generate wrong SEH unwind info. The attached fix makes sure that the frame pointer is always established after the fixed stack allocation by pointing it at or below the lowest used register save area, i.e. the SSE save area, and removing the special early saves in the prologue; the end result is a uniform prologue sequence for SEH whatever the frame size. And it avoids a discrepancy between cases where the number of saved general regs is even and cases where it is odd. gcc/ PR target/99234 * config/i386/i386.c (ix86_compute_frame_layout): For a SEH target, point the hard frame pointer to the SSE register save area instead of the general register save area. Perform only minimal adjustment for small frames if it is initially not correctly aligned. (ix86_expand_prologue): Remove early saves for a SEH target. * config/i386/winnt.c (struct seh_frame_state): Document constraint. gcc/testsuite/ * g++.dg/eh/seh-xmm-unwind.C: New test.
[Bug fortran/99307] FAIL: gfortran.dg/class_assign_4.f90 -O0 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99307 Hans-Peter Nilsson changed: What|Removed |Added CC||pault at gcc dot gnu.org Host|hppa-unknown-linux-gnu | Target|hppa-unknown-linux-gnu |hppa-unknown-linux-gnu, ||cris-elf, ||sparcv9-sun-solaris2.11, ||x86_64-pc-solaris2.11 Build|hppa-unknown-linux-gnu | --- Comment #3 from Hans-Peter Nilsson --- I was about to enter a bug-report with the following contents, most of which is not redundant: Since the commit 29a5298955f7 / r11-7349 "Fortran: Fix for class defined operators [PR99124].", class_assign_4 has failed at execution for cris-elf, at all optimization levels. I see the same goes for some solaris targets: sparcv9-sun-solaris2.11 https://gcc.gnu.org/pipermail/gcc-testresults/2021-February/661993.html and x86_64-pc-solaris2.11 https://gcc.gnu.org/pipermail/gcc-testresults/2021-February/661992.html but apparently none of the other posted test-results I checked. Looking into a trace for cris-elf, I see a call to "free" hits an invalid memory access (the equivalent of SEGV) and the execution terminates. This hints at invalid memory management related to the allocations done in that test, like too short allocation or write-after-free. For a native x86_64-linux build, valgrind does complain when applied to the test, but as my valgrind isn't dwarf-5-aware, I can't see much besides and can't be too sure besides the relation to memory allocation. Here are the first four valgrind indications for the test as compiled at -O0 (and adding -gdwarf-2 to the build flags): ==32498== Invalid write of size 8 ==32498==at 0x4C32643: memmove (vg_replace_strmem.c:1252) ==32498==by 0x4076F8: test_t1_ (class_assign_4.f90:62) ==32498==by 0x409E69: MAIN__ (class_assign_4.f90:183) ==32498==by 0x409EA5: main (class_assign_4.f90:185) ==32498== Address 0x5de4bd8 is 8 bytes inside a block of size 12 alloc'd ==32498==at 0x4C2DDCF: realloc (vg_replace_malloc.c:785) ==32498==by 0x405C65: test_t1_ (class_assign_4.f90:50) ==32498==by 0x409E69: MAIN__ (class_assign_4.f90:183) ==32498==by 0x409EA5: main (class_assign_4.f90:185) ==32498== ==32498== Invalid read of size 4 ==32498==at 0x40507B: check_t1.2 (class_assign_4.f90:104) ==32498==by 0x407878: test_t1_ (class_assign_4.f90:63) ==32498==by 0x409E69: MAIN__ (class_assign_4.f90:183) ==32498==by 0x409EA5: main (class_assign_4.f90:185) ==32498== Address 0x5de4be0 is 4 bytes after a block of size 12 alloc'd ==32498==at 0x4C2DDCF: realloc (vg_replace_malloc.c:785) ==32498==by 0x405C65: test_t1_ (class_assign_4.f90:50) ==32498==by 0x409E69: MAIN__ (class_assign_4.f90:183) ==32498==by 0x409EA5: main (class_assign_4.f90:185) ==32498== ==32498== Invalid write of size 8 ==32498==at 0x407BE8: test_t1_ (class_assign_4.f90:66) ==32498==by 0x409E69: MAIN__ (class_assign_4.f90:183) ==32498==by 0x409EA5: main (class_assign_4.f90:185) ==32498== Address 0x5de4bd8 is 8 bytes inside a block of size 12 alloc'd ==32498==at 0x4C2DDCF: realloc (vg_replace_malloc.c:785) ==32498==by 0x405C65: test_t1_ (class_assign_4.f90:50) ==32498==by 0x409E69: MAIN__ (class_assign_4.f90:183) ==32498==by 0x409EA5: main (class_assign_4.f90:185) ==32498== ==32498== Invalid read of size 8 ==32498==at 0x400886: __m_MOD___copy_m_T2 (class_assign_4.f90:38) ==32498==by 0x407EBF: test_t1_ (class_assign_4.f90:67) ==32498==by 0x409E69: MAIN__ (class_assign_4.f90:183) ==32498==by 0x409EA5: main (class_assign_4.f90:185) ==32498== Address 0x5de4be0 is 4 bytes after a block of size 12 alloc'd ==32498==at 0x4C2DDCF: realloc (vg_replace_malloc.c:785) ==32498==by 0x405C65: test_t1_ (class_assign_4.f90:50) ==32498==by 0x409E69: MAIN__ (class_assign_4.f90:183) ==32498==by 0x409EA5: main (class_assign_4.f90:185) I'm guessing there's a flaw with the test, but I don't know fortran so unfortunately I can't debug it.
[Bug fortran/99307] FAIL: gfortran.dg/class_assign_4.f90 -O0 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99307 Hans-Peter Nilsson changed: What|Removed |Added CC||hp at gcc dot gnu.org --- Comment #2 from Hans-Peter Nilsson --- (In reply to John David Anglin from comment #0) > FAIL: gfortran.dg/class_assign_4.f90 -O0 execution test According to https://gcc.gnu.org/pipermail/gcc-testresults/2021-February/661332.html the test fails execution at *all* tested optimization levels, not just -O0.
[Bug tree-optimization/98954] ((X << CST0) & CST1) == 0 is not optimized to 0 == (X & (CST1 >> CST0))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98954
--- Comment #3 from Andrew Pinski ---
Created attachment 50271
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50271=edit
partial patch
This is the partial patch (and still need a testcase added too).
It fixes:
_Bool f(unsigned m)
{
return !((m << 1) & 0xFF);
}
[Bug tree-optimization/98954] ((X << CST0) & CST1) == 0 is not optimized to 0 == (X & (CST1 >> CST0))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98954 Andrew Pinski changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org --- Comment #2 from Andrew Pinski --- I have a partial patch.
[Bug tree-optimization/98954] Failure to optimize left shift+and pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98954 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Last reconfirmed||2021-02-28 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- The generic transformation is ((X << CST0) & CST1) == 0 to 0 == (X & (CST1 >> CST0)) Note I think 0 could be replaced with CST2 but I am not 100% I could get it correct.
[Bug fortran/93340] [8 Regression] ICE in check_constant_initializer, at fortran/trans-decl.c:5450
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93340 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|8.5 |9.4 Summary|[8/9/10/11 Regression] ICE |[8 Regression] ICE in |in |check_constant_initializer, |check_constant_initializer, |at |at |fortran/trans-decl.c:5450 |fortran/trans-decl.c:5450 | --- Comment #11 from anlauf at gcc dot gnu.org --- Backported to 10- and 9-branches without changes. Since it does not apply cleanly to 8-branch, it may not be worth the effort to adjust the fix and risk new regressions in the final 8-release. Therefore closing. Thanks for the report!
[Bug preprocessor/83773] Create new switch, -Wmacro-redefined, to control warning for redefined macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83773 Roland Illig changed: What|Removed |Added CC||roland.illig at gmx dot de --- Comment #4 from Roland Illig --- Having this option would help NetBSD's lint(1), which currently uses the -Wp,-CC option to preserve comments. >From https://gnats.netbsd.org/22515: > $ cat > lint-define.c > #define LINTFOO 1 /* comment */ > #define LINTFOO 1 /* different */ > int foo; > > $ gcc -Wall -E lint-define.c > > $ gcc -Wall -E -Wp,-CC lint-define.c > lint-define.c:2: warning: `LINTFOO' redefined > lint-define.c:1: warning: this is the location of the previous definition Without an option like Clang's -Wmacro-redefined, another possible fix for this scenario would be to ignore differences in comment text, in _cpp_equiv_tokens. These only occur with the options -C or -CC and thus do not affect the default behavior.
[Bug c++/99238] [modules] internal compiler error: segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99238 --- Comment #1 from Alexander Lelyakin --- There is a shorter sequence: g++ -std=c++20 -fmodules-ts -x c++-system-header fstream g++ -std=c++20 -fmodules-ts -x c++-system-header string_view g++ -std=c++20 -fmodules-ts -x c++-system-header locale /usr/local/include/c++/11.0.1/locale: internal compiler error: Segmentation fault 0x10fc36f crash_signal ../../gcc/gcc/toplev.c:327 0x6de73c trees_out::get_tag(tree_node*) ../../gcc/gcc/cp/module.cc:4898 0x6de73c trees_out::ref_node(tree_node*) ../../gcc/gcc/cp/module.cc:7205 0x6de73c trees_out::ref_node(tree_node*) ../../gcc/gcc/cp/module.cc:7188 0xa5c4dc trees_out::tree_node(tree_node*) ../../gcc/gcc/cp/module.cc:9055 0xa5e411 trees_out::type_node(tree_node*) ../../gcc/gcc/cp/module.cc:8778 0xa5c8da trees_out::tree_node(tree_node*) ../../gcc/gcc/cp/module.cc:9138 0xa5e1cc trees_out::type_node(tree_node*) ../../gcc/gcc/cp/module.cc:8696 0xa5c8da trees_out::tree_node(tree_node*) ../../gcc/gcc/cp/module.cc:9138 0xa5e654 trees_out::type_node(tree_node*) ../../gcc/gcc/cp/module.cc:8805 0xa5c8da trees_out::tree_node(tree_node*) ../../gcc/gcc/cp/module.cc:9138 0xa5e1cc trees_out::type_node(tree_node*) ../../gcc/gcc/cp/module.cc:8696 0xa5c8da trees_out::tree_node(tree_node*) ../../gcc/gcc/cp/module.cc:9138 0xa5d20f trees_out::core_vals(tree_node*) ../../gcc/gcc/cp/module.cc:6108 0xa5e0ec trees_out::tree_node_vals(tree_node*) ../../gcc/gcc/cp/module.cc:7168 0xa5e0ec trees_out::fn_parms_init(tree_node*) ../../gcc/gcc/cp/module.cc:10069 0xa5b086 trees_out::decl_value(tree_node*, depset*) ../../gcc/gcc/cp/module.cc:7765 0xa625c3 depset::hash::find_dependencies(module_state*) ../../gcc/gcc/cp/module.cc:13237 0xa62c28 module_state::write(elf_out*, cpp_reader*) ../../gcc/gcc/cp/module.cc:17652 0xa640cf finish_module_processing(cpp_reader*) ../../gcc/gcc/cp/module.cc:19922 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. g++ (GCC) 11.0.1 20210228 (experimental)
[Bug c++/99248] [modules] ICE expected binding_vector, have overload in lookup_elaborated_type_1, at cp/name-lookup.c:8013
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99248 --- Comment #1 from Alexander Lelyakin --- There is a shorter sequence: g++ -std=c++20 -fmodules-ts -x c++-system-header streambuf g++ -std=c++20 -fmodules-ts -x c++-system-header complex In file included from /usr/local/include/c++/11.0.1/bits/locale_facets.h:2682, from /usr/local/include/c++/11.0.1/bits/basic_ios.h:37, from /usr/local/include/c++/11.0.1/ios:44, from /usr/local/include/c++/11.0.1/istream:38, from /usr/local/include/c++/11.0.1/sstream:38, from /usr/local/include/c++/11.0.1/complex:45: /usr/local/include/c++/11.0.1/bits/locale_facets.tcc:42:12: internal compiler error: tree check: expected binding_vector, have overload in lookup_elaborated_type_1, at cp/name-lookup.c:8013 42 | struct __use_cache |^~~ 0x875454 tree_check_failed(tree_node const*, char const*, int, char const*, ...) ../../gcc/gcc/tree.c:9814 0x6eb4e2 tree_check(tree_node*, char const*, int, char const*, tree_code) ../../gcc/gcc/tree.h:3349 0x6eb4e2 lookup_elaborated_type_1 ../../gcc/gcc/cp/name-lookup.c:8013 0x6eb4e2 lookup_elaborated_type(tree_node*, TAG_how) ../../gcc/gcc/cp/name-lookup.c:8104 0x9c37f5 lookup_and_check_tag ../../gcc/gcc/cp/decl.c:15073 0x9c3bb1 xref_tag_1 ../../gcc/gcc/cp/decl.c:15187 0x9c4100 xref_tag(tag_types, tree_node*, TAG_how, bool) ../../gcc/gcc/cp/decl.c:15320 0xaa4ff2 cp_parser_class_head ../../gcc/gcc/cp/parser.c:25576 0xaa4ff2 cp_parser_class_specifier_1 ../../gcc/gcc/cp/parser.c:24793 0xaa5963 cp_parser_class_specifier ../../gcc/gcc/cp/parser.c:25172 0xaa5963 cp_parser_type_specifier ../../gcc/gcc/cp/parser.c:18419 0xaa68f9 cp_parser_decl_specifier_seq ../../gcc/gcc/cp/parser.c:15041 0xad1436 cp_parser_single_declaration ../../gcc/gcc/cp/parser.c:30390 0xad17b6 cp_parser_template_declaration_after_parameters ../../gcc/gcc/cp/parser.c:30053 0xad1f60 cp_parser_explicit_template_declaration ../../gcc/gcc/cp/parser.c:30319 0xad46b9 cp_parser_declaration ../../gcc/gcc/cp/parser.c:14047 0xad3c59 cp_parser_toplevel_declaration ../../gcc/gcc/cp/parser.c:14145 0xad3c59 cp_parser_declaration_seq_opt ../../gcc/gcc/cp/parser.c:13933 0xad40f2 cp_parser_namespace_body ../../gcc/gcc/cp/parser.c:20433 0xad40f2 cp_parser_namespace_definition ../../gcc/gcc/cp/parser.c:20411 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. g++ (GCC) 11.0.1 20210228 (experimental)
[Bug target/99312] __ARM_ARCH is not implemented correctly when compiled with -march=armv8.1-a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99312 --- Comment #1 from Andrew Pinski --- https://developer.arm.com/documentation/101028/latest
[Bug target/99312] New: __ARM_ARCH is not implemented correctly when compiled with -march=armv8.1-a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99312 Bug ID: 99312 Summary: __ARM_ARCH is not implemented correctly when compiled with -march=armv8.1-a Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- The latest ACLE dated Q3 2020 has the following for how __ARM_ARCH should be defined for ARMv8.1-a and above: For an Arm architecture ArmvX.Y, __ARM_ARCH = X * 100 + Y. E.g. for Armv8.1 __ARM_ARCH = 801. - CUT Currently GCC just does 8.
[Bug c++/99245] [modules] ICE in write_cluster, at cp/module.cc:14600
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99245 --- Comment #1 from Alexander Lelyakin --- There is a shorter sequence: g++ -std=c++20 -fmodules-ts -x c++-system-header typeinfo g++ -std=c++20 -fmodules-ts -x c++-system-header ostream /usr/local/include/c++/11.0.1/ostream: internal compiler error: in write_cluster, at cp/module.cc:14605 0x6e2d18 module_state::write_cluster(elf_out*, depset**, unsigned int, depset::hash&, unsigned int*, unsigned int*) ../../gcc/gcc/cp/module.cc:14605 0xa634de module_state::write(elf_out*, cpp_reader*) ../../gcc/gcc/cp/module.cc:17785 0xa640cf finish_module_processing(cpp_reader*) ../../gcc/gcc/cp/module.cc:19922 0x9f776b c_parse_final_cleanups() ../../gcc/gcc/cp/decl2.c:5175 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. g++ (GCC) 11.0.1 20210228 (experimental)
[Bug c++/99284] [modules] ICE in key_mergeable, at cp/module.cc:10441
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99284 --- Comment #1 from Alexander Lelyakin --- There is a shorter sequence: g++ -std=c++20 -fmodules-ts -x c++-system-header unordered_map g++ -std=c++20 -fmodules-ts -x c++-system-header regex /usr/local/include/c++/11.0.1/regex: internal compiler error: in key_mergeable, at cp/module.cc:10456 0x6e1dd9 trees_out::key_mergeable(int, merge_kind, tree_node*, tree_node*, tree_node*, depset*) ../../gcc/gcc/cp/module.cc:10456 0xa5a8f1 trees_out::decl_value(tree_node*, depset*) ../../gcc/gcc/cp/module.cc:7769 0xa625c3 depset::hash::find_dependencies(module_state*) ../../gcc/gcc/cp/module.cc:13237 0xa62c28 module_state::write(elf_out*, cpp_reader*) ../../gcc/gcc/cp/module.cc:17652 0xa640cf finish_module_processing(cpp_reader*) ../../gcc/gcc/cp/module.cc:19922 0x9f776b c_parse_final_cleanups() ../../gcc/gcc/cp/decl2.c:5175 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. g++ (GCC) 11.0.1 20210228 (experimental)
[Bug c++/99241] [modules] ICE in install_entity, at cp/module.cc:7584
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99241 --- Comment #1 from Alexander Lelyakin --- There is a shorter sequence: g++ -std=c++20 -fmodules-ts -x c++-system-header forward_list g++ -std=c++20 -fmodules-ts -x c++-system-header ios g++ -std=c++20 -fmodules-ts -x c++-system-header unordered_map g++ -std=c++20 -fmodules-ts -x c++-system-header condition_variable g++ -std=c++20 -fmodules-ts -x c++-system-header regex In file included from /usr/local/include/c++/11.0.1/bits/unique_ptr.h:42, from /usr/local/include/c++/11.0.1/bits/locale_conv.h:41, from /usr/local/include/c++/11.0.1/locale:43, from /usr/local/include/c++/11.0.1/regex:44: /usr/local/include/c++/11.0.1/ostream:58:42: internal compiler error: in install_entity, at cp/module.cc:7586 58 | class basic_ostream : virtual public basic_ios<_CharT, _Traits> | ^ 0xa5a52d trees_in::install_entity(tree_node*) ../../gcc/gcc/cp/module.cc:7586 0xa647aa trees_in::decl_value() ../../gcc/gcc/cp/module.cc:8108 0xa66317 trees_in::tree_node(bool) ../../gcc/gcc/cp/module.cc:9251 0xa6cad3 module_state::read_cluster(unsigned int) ../../gcc/gcc/cp/module.cc:14948 0xa6ce7d module_state::load_section(unsigned int, binding_slot*) ../../gcc/gcc/cp/module.cc:18148 0xa6d518 lazy_load_binding(unsigned int, tree_node*, tree_node*, binding_slot*) ../../gcc/gcc/cp/module.cc:18833 0xa7d39e name_lookup::search_namespace_only(tree_node*) ../../gcc/gcc/cp/name-lookup.c:924 0xa7eafb name_lookup::search_unqualified(tree_node*, cp_binding_level*) ../../gcc/gcc/cp/name-lookup.c:1155 0xa818f4 lookup_name_1 ../../gcc/gcc/cp/name-lookup.c:7868 0xa81aba lookup_name(tree_node*, LOOK_where, LOOK_want) ../../gcc/gcc/cp/name-lookup.c:7888 0xa907d2 lookup_name(tree_node*, LOOK_want) ../../gcc/gcc/cp/name-lookup.h:412 0xa907d2 cp_parser_lookup_name ../../gcc/gcc/cp/parser.c:29339 0xab901f cp_parser_template_name ../../gcc/gcc/cp/parser.c:17694 0xab955f cp_parser_template_id ../../gcc/gcc/cp/parser.c:17303 0xab9dbb cp_parser_class_name ../../gcc/gcc/cp/parser.c:24671 0xab134a cp_parser_qualifying_entity ../../gcc/gcc/cp/parser.c:6994 0xab134a cp_parser_nested_name_specifier_opt ../../gcc/gcc/cp/parser.c:6676 0xaa51dc cp_parser_base_specifier ../../gcc/gcc/cp/parser.c:26690 0xaa51dc cp_parser_base_clause ../../gcc/gcc/cp/parser.c:26543 0xaa51dc cp_parser_class_head ../../gcc/gcc/cp/parser.c:25630 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. g++ (GCC) 11.0.1 20210228 (experimental)
[Bug c++/99240] [modules] ICE in get_merge_kind, at cp/module.cc:10169
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99240 --- Comment #1 from Alexander Lelyakin --- there is a shorter sequence: g++ -std=c++20 -fmodules-ts -x c++-system-header cmath g++ -std=c++20 -fmodules-ts -x c++-system-header random /usr/local/include/c++/11.0.1/random: internal compiler error: in get_merge_kind, at cp/module.cc:10171 0x6dccf5 trees_out::get_merge_kind(tree_node*, depset*) ../../gcc/gcc/cp/module.cc:10171 0xa5a753 trees_out::decl_value(tree_node*, depset*) ../../gcc/gcc/cp/module.cc:7631 0xa5b6ab trees_out::decl_node(tree_node*, walk_kind) ../../gcc/gcc/cp/module.cc:8626 0xa5c6a2 trees_out::tree_node(tree_node*) ../../gcc/gcc/cp/module.cc:9181 0xa61ff3 module_state::write_pendings(elf_out*, vec, depset::hash&, unsigned int, unsigned int*) ../../gcc/gcc/cp/module.cc:15419 0xa639f4 module_state::write(elf_out*, cpp_reader*) ../../gcc/gcc/cp/module.cc:17810 0xa640cf finish_module_processing(cpp_reader*) ../../gcc/gcc/cp/module.cc:19922 0x9f776b c_parse_final_cleanups() ../../gcc/gcc/cp/decl2.c:5175 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. g++ (GCC) 11.0.1 20210228 (experimental) Copyright (C) 2021 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug libstdc++/99311] New: std::filesystem::exists & std::filesystem::create_directories don't work correctly with UNC paths
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99311 Bug ID: 99311 Summary: std::filesystem::exists & std::filesystem::create_directories don't work correctly with UNC paths Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: moritz at bunkus dot org Target Milestone: --- Created attachment 50270 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50270=edit test case showing the issues These might be two separate issues, but my gut feeling is that they're both due to the same underlying problem, especially if create_directories() uses exists() to determine which components it has to create. Using std::filesystem::exists on a UNC path with mingw 10.20.0 that points to a share (not a file or directory in a share) returns false. For example: • exists() for the existing file "\\server\share\this_exists.txt" returns true proving that the share itself exists & the user has access to it. However, exists() on "\\server\share" (retrieved via ".parent_path()" from the full path) returns false. By comparison, boost::filesystem::exists() returns true for both paths. • Using the same server & same share, trying to create a sub-directory via create_directories() fails. For example, trying to create "\\server\share\this_does_not_exist_yet" fails. Yes, I'm 100% sure that I have write access to the share in question. By comparison, boost::filesystem::create_directories() works fine with such a path. I'll a sample program that shows the problem. Of course you'll have to adjust server & share names. Compiled with gcc 10.20.0 from the mxe project. Command line: x86_64-w64-mingw32.static-g++ -std=c++17 -o std_filesystem_exists_and_create_directories.exe std_filesystem_exists_and_create_directories.cpp The program outputs the following: - sanity check, should be true: 1 should return true but doesn't: 0 directory \\disky\mosu\does-not-exist doesn't exist yet, should be false: 0 tried to create directory \\disky\mosu\does-not-exist, have error code? 1 - The first is the check for the existing file. It does return true, showing that exists() works correctly for existing files. The second line tries exists() for the parent_path() of the file tested in line 1. Of course it should return true, too, but doesn't. The path points to the share. Line three just establishes that the directory really doesn't exist yet. exists() should return false here and does so. Great. Line four shows the result of the create_directories() call, or rather, whether the error_code is indicating an error. It does, which it shouldn't.
[Bug fortran/66499] Letters with accents change format behavior for X and T descriptors.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66499 Jerry DeLisle changed: What|Removed |Added Status|NEW |ASSIGNED CC||jvdelisle at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org --- Comment #4 from Jerry DeLisle --- The case in the original report is likely not valid without setting the encoding for the output unit as Dominique has done in Comment 1. The problem here is likely similar to 99210.
[Bug java/41991] gcj segfaults on i686-apple-darwin9 and x86_64-apple-darwin9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991
Bug 41991 depends on bug 44107, which changed state.
Bug 44107 Summary: gcc emits frame (epilogue) info incompatible with the darwin
{8,9}-unwinder,10-compacter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107
What|Removed |Added
Status|RESOLVED|ASSIGNED
Resolution|WONTFIX |---
[Bug target/44107] gcc emits frame (epilogue) info incompatible with the darwin {8,9}-unwinder,10-compacter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107 Eric Gallager changed: What|Removed |Added Status|RESOLVED|ASSIGNED Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2021-Februar ||y/565950.html Keywords||patch Resolution|WONTFIX |--- CC||egallager at gcc dot gnu.org --- Comment #33 from Eric Gallager --- Iain has a patch for this: https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565950.html
[Bug target/48097] gcc sometimes generates code that uses the buggy libgcc_s unwinder on darwin (originally exposed by Throw_2 failures in libjava testsuite under Xcode 4.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48097 Eric Gallager changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org Keywords||patch CC||egallager at gcc dot gnu.org Status|SUSPENDED |ASSIGNED URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2021-Februar ||y/565950.html --- Comment #17 from Eric Gallager --- Iain has a patch for this now: https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565950.html
[Bug libstdc++/83077] sso-string @ gnu-versioned-namespace.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83077 François Dumont changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |fdumont at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug libstdc++/95079] unorderd_map::insert_or_assign and try_emplace should only hash and mod once unless there is a rehash.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95079 François Dumont changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from François Dumont --- This should be considered as fixed now.
[Bug c++/99310] New: [11 Regression] ICE: canonical types differ for identical types 'void (A::)(void*)' and 'void (A::)(void*)'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99310
Bug ID: 99310
Summary: [11 Regression] ICE: canonical types differ for
identical types 'void (A::)(void*)' and 'void
(A::)(void*)'
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: x86_64-unknown-linux-gnu
g++-11.0.0-alpha20210221 snapshot (g:2df374b337a5f6cf5528e91718e4e12e4006b7ae)
ICEs when compiling gcc/testsuite/g++.dg/other/pr39060.C w/ -march=corei7
-std=gnu++2a -fopenmp:
% x86_64-unknown-linux-gnu-g++-11.0.0 -march=corei7 -std=gnu++2a -fopenmp -c
gcc/testsuite/g++.dg/other/pr39060.C
gcc/testsuite/g++.dg/other/pr39060.C:7:3: error: 'A::A(void*)' cannot be
overloaded with 'A::A(void*)'
7 | A(void* i=); // { dg-error "overloaded|primary-expression" }
| ^
gcc/testsuite/g++.dg/other/pr39060.C:6:3: note: previous declaration
'A::A(void*)'
6 | A(void* i=); // { dg-error "with|specification|primary-expression" }
| ^
gcc/testsuite/g++.dg/other/pr39060.C:8:3: error: 'A::A(void*)' cannot be
overloaded with 'A::A(void*)'
8 | A(void* i=); // { dg-error "overloaded|primary-expression" }
| ^
gcc/testsuite/g++.dg/other/pr39060.C:6:3: note: previous declaration
'A::A(void*)'
6 | A(void* i=); // { dg-error "with|specification|primary-expression" }
| ^
gcc/testsuite/g++.dg/other/pr39060.C:10:8: error: 'void A::operator+(void*)'
cannot have default arguments
10 | void operator+ (void* i=);// { dg-error "arguments" }
|^~~~
gcc/testsuite/g++.dg/other/pr39060.C:12:21: error: expected identifier before
'=' token
12 | virtual void foo1(=); // { dg-error "identifier|primary-expression" }
| ^
gcc/testsuite/g++.dg/other/pr39060.C:13:13: error: expected identifier before
'=' token
13 | void foo2(=); // { dg-error "identifier|primary-expression" }
| ^
gcc/testsuite/g++.dg/other/pr39060.C:14:13: error: expected identifier before
'=' token
14 | void foo3(=); // { dg-error "identifier|primary-expression" }
| ^
gcc/testsuite/g++.dg/other/pr39060.C:15:13: error: expected identifier before
'=' token
15 | void foo4(=); // { dg-error "identifier|primary-expression" }
| ^
gcc/testsuite/g++.dg/other/pr39060.C:16:13: error: expected identifier before
'=' token
16 | void foo5(=); // { dg-error "identifier|primary-expression" }
| ^
gcc/testsuite/g++.dg/other/pr39060.C:6:13: error: expected primary-expression
at end of input
6 | A(void* i=); // { dg-error "with|specification|primary-expression" }
| ^
gcc/testsuite/g++.dg/other/pr39060.C:7:13: error: expected primary-expression
at end of input
7 | A(void* i=); // { dg-error "overloaded|primary-expression" }
| ^
gcc/testsuite/g++.dg/other/pr39060.C:8:13: error: expected primary-expression
at end of input
8 | A(void* i=); // { dg-error "overloaded|primary-expression" }
| ^
gcc/testsuite/g++.dg/other/pr39060.C:12:22: error: expected primary-expression
at end of input
12 | virtual void foo1(=); // { dg-error "identifier|primary-expression" }
| ^
gcc/testsuite/g++.dg/other/pr39060.C:13:14: error: expected primary-expression
at end of input
13 | void foo2(=); // { dg-error "identifier|primary-expression" }
| ^
gcc/testsuite/g++.dg/other/pr39060.C:14:14: error: expected primary-expression
at end of input
14 | void foo3(=); // { dg-error "identifier|primary-expression" }
| ^
gcc/testsuite/g++.dg/other/pr39060.C:15:14: error: expected primary-expression
at end of input
15 | void foo4(=); // { dg-error "identifier|primary-expression" }
| ^
gcc/testsuite/g++.dg/other/pr39060.C:16:14: error: expected primary-expression
at end of input
16 | void foo5(=); // { dg-error "identifier|primary-expression" }
| ^
gcc/testsuite/g++.dg/other/pr39060.C:19:15: error: expected primary-expression
before ')' token
19 | A::A (void* i=) {} // { dg-error "primary-expression|argument" }
| ^
gcc/testsuite/g++.dg/other/pr39060.C:19:1: error: default argument given for
parameter 1 of 'A::A(void*)' [-fpermissive]
19 | A::A (void* i=) {} // { dg-error "primary-expression|argument" }
| ^
gcc/testsuite/g++.dg/other/pr39060.C:6:3: note: previous specification in
'A::A(void*)' here
6 | A(void* i=); // { dg-error "with|specification|primary-expression" }
| ^
gcc/testsuite/g++.dg/other/pr39060.C:19:15: internal
[Bug c/99304] [11 Regression] typo in diagnostic: refernced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99304 --- Comment #4 from Roland Illig --- Thank you for fixing the typos. Could you perhaps add the test cases to the test suite, to have the two diagnostics covered? Now that the typo is fixed, both should trivially pass.
[Bug libfortran/81986] sanitizer detects negation of large number in string.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81986 Dominique d'Humieres changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-02-28 Status|UNCONFIRMED |NEW --- Comment #5 from Dominique d'Humieres --- Confirmed.
[Bug fortran/99308] [OOP] passing array of object as class(TYPE) to procedure leads to incorrect length of array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99308 Dominique d'Humieres changed: What|Removed |Added Keywords||wrong-code Last reconfirmed||2021-02-28 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmes since at least GCC7.
[Bug c++/99309] New: Segmentation fault with __builtin_constant_p usage at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99309
Bug ID: 99309
Summary: Segmentation fault with __builtin_constant_p usage at
-O2
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc at mailinator dot com
Target Milestone: ---
Compile:
g++ -O2 a.cpp
./a.out
Current output:
1 610334368
Segmentation fault (core dumped)
Code:
#include
struct T {
int val;
explicit constexpr operator int() const { return val; }
constexpr T(int64_t v):val(v){}
void operator*=(T m) {
//std::cerr<<"start\n";
if(__builtin_constant_p(m.val)){
std::cerr<<"normal\n";
return;
}else if(__builtin_constant_p(val)){
std::cerr<<"recursive\n";
return;
}else{
std::cerr<<"return\n";
return;
}
}
};
int main(){
T constexpr step=610334368;
T value=1;
for(int _=0; _<100; ++_){
std::cerr<<(int)value<<' '<<(int)step<<'\n';
value*=step;
std::cerr<<(int)value<<' '<<(int)step<<'\n';
}
}
[Bug translation/40883] [meta-bug] Translation breakage with trivial fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40883 Bug 40883 depends on bug 99303, which changed state. Bug 99303 Summary: OpenMP: typo in diagnostic https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99303 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug fortran/99303] OpenMP: typo in diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99303 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- Fixed.
[Bug translation/40883] [meta-bug] Translation breakage with trivial fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40883 Bug 40883 depends on bug 99300, which changed state. Bug 99300 Summary: double space in diagnostic https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99300 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug fortran/99300] double space in diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99300 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Jakub Jelinek --- Fixed.
[Bug translation/40883] [meta-bug] Translation breakage with trivial fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40883 Bug 40883 depends on bug 99304, which changed state. Bug 99304 Summary: [11 Regression] typo in diagnostic: refernced https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99304 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c/99304] [11 Regression] typo in diagnostic: refernced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99304 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Jakub Jelinek --- Fixed.
[Bug fortran/99303] OpenMP: typo in diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99303 --- Comment #3 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:48ca2185bfb5126baacab812b3f14c80123ccb88 commit r11-7434-g48ca2185bfb5126baacab812b3f14c80123ccb88 Author: Jakub Jelinek Date: Sun Feb 28 11:16:33 2021 +0100 fortran: Fix up wording of 3 OpenMP diagnostic messages [PR99303] As reported in the PR, some diagnostic messages need wording improvements. 2021-02-28 Jakub Jelinek PR fortran/99303 * openmp.c (gfc_omp_requires_add_clause): Fix up diagnostic message wordings. (resolve_omp_clauses): Likewise.
[Bug fortran/99300] double space in diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99300 --- Comment #1 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:3a77ca7d3647e6fbc34fe76aceb389d6fb95fdf4 commit r11-7433-g3a77ca7d3647e6fbc34fe76aceb389d6fb95fdf4 Author: Jakub Jelinek Date: Sun Feb 28 11:14:24 2021 +0100 fortran: Replace double space in diagnostic with a single one [PR99300] The diagnostic had " " in it instead of just " ". 2021-02-28 Jakub Jelinek PR fortran/99300 * frontend-passes.c (doloop_code): Replace double space in diagnostics with a single space.
[Bug c/99304] [11 Regression] typo in diagnostic: refernced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99304 --- Comment #2 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:d3805e6d575752141888dc29af7f0337df8a2f72 commit r11-7432-gd3805e6d575752141888dc29af7f0337df8a2f72 Author: Jakub Jelinek Date: Sun Feb 28 11:10:44 2021 +0100 typos: Fix various typos - mainly misspelled reference* [PR99304] The PR is about a typo in handle_malloc_attribute diagnostic message, but grepping around I found many other cases and while fixing those I've noticed a couple of other typos. 2021-02-28 Jakub Jelinek PR c/99304 * ipa.c (symbol_table::remove_unreachable_nodes): Fix a comment typo - referneced -> referenced. * tree.c (component_ref_size): Fix comment typo - refernce -> reference. * tree-ssa-alias.c (access_path_may_continue_p): Fix comment typo - traling -> trailing. (aliasing_component_refs_p): Fix comment typos - refernce -> reference and refernece -> reference and traling -> trailing. (nonoverlapping_refs_since_match_p): Fix comment typo - referneces -> references. * doc/invoke.texi (--param modref-max-bases): Fix a typo - referneces -> references. gcc/c-family/ * c-attribs.c (handle_malloc_attribute): Fix a typo in inform message - refernced -> referenced. Remove superfluous space before closing paren of function calls. gcc/lto/ * lto-symtab.c (lto_symtab_prevailing_virtual_decl): Fix comment typos - refernced -> referenced and devirtualizaiton -> devirtualization.
[Bug fortran/99308] New: [OOP] passing array of object as class(TYPE) to procedure leads to incorrect length of array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99308 Bug ID: 99308 Summary: [OOP] passing array of object as class(TYPE) to procedure leads to incorrect length of array Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: 8718033x at gmail dot com Target Milestone: --- Created attachment 50269 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50269=edit example code for generating error If both function and subroutine takes polymorphic arrays argument, then the leading array(the first appear array's) length become following array's length. This is my first bug report. so if something wrong with it, please let me know. version: 10.2.0 linux version: arch linux 5.11.1-arch1-1 given option: -Og Example code attached. Extra-description: subroutine err_ver(spcs, fuel) class(Specie) :: spcs(8), fuel(2) ... end subroutine subroutine working_ver(spcs, fuel) type(Specie) :: spcs(8), fuel(2) .. end subroutine For both version, we expect that 1. size(spcs) == 8 2. size(fuel) == 2 are true. But, what I've got was a 8, 8 for the err_ver. if you change the order of spcs and fuel, then you will get 2, 2
