[Bug target/55218] armv6 doesn't use unaligned access for packed structures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55218 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2023-02-25 Ever confirmed|0 |1 --- Comment #3 from Andrew Pinski --- Confirmed. very similar to PR 51709 if not the same.
[Bug middle-end/55658] bitfields and __attribute__((packed)) generate horrible code on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55658 Andrew Pinski changed: What|Removed |Added CC||rogero at howzatt dot co.uk --- Comment #5 from Andrew Pinski --- *** Bug 66364 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/66364] poor optimization of packed structs containing bitfields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66364 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|ASSIGNED|RESOLVED --- Comment #3 from Andrew Pinski --- Dup of bug 55658. *** This bug has been marked as a duplicate of bug 55658 ***
[Bug middle-end/55658] bitfields and __attribute__((packed)) generate horrible code on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55658 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #4 from Andrew Pinski --- Mine, I am going to look into this for GCC 14 (seperately from the bitfield lower since it also still happens with that pass). That pass does give some extra information though on this (a slightly different but similar enough testcase): ``` Trying to expand bitfield reference: a_3(D)->la base: *a_3(D) orig bitpos: 0 bytepos: 0 after bit_range bitpos: 0 bytepos: 0 bitregion_start: 0 bitregion_end: 63 align: 8 word_size: 64. failed, get_best_mode return false. ``` So basically get_best_mode failed with the above arguments ...
[Bug middle-end/108920] Condition falsely optimized out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108920 --- Comment #3 from Agner Fog --- It seems to work with gcc 9.4.0. Thank you
[Bug target/108922] fmod() 13x slowdown in gcc4.9 dropping "fprem" and calling fmod()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-02-25 Status|UNCONFIRMED |WAITING --- Comment #2 from Andrew Pinski --- So the simple test is run the full GCC bootstrap/test with all languages and check if the testcase fails or not. I suspect it will.
[Bug target/108922] fmod() 13x slowdown in gcc4.9 dropping "fprem" and calling fmod()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922 --- Comment #1 from Andrew Pinski --- >The committer also claims "fixes ieee_2.f90 testsuite failure" but I have no >idea where to find this testsuite. ./testsuite/gfortran.dg/ieee/ieee_2.f90
[Bug middle-end/108920] Condition falsely optimized out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108920 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=97009, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=97255 --- Comment #2 from Andrew Pinski --- I linked a few bugs which might be the same issue here (I have not looked into the code otherwise) and they were both fixed in GCC 9.4.0 even. So yes please try out GCC 9.5.0 or 10.x even.
[Bug c++/108893] attribute access read_only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108893 --- Comment #7 from Andrew Pinski --- access attribute says if it is access, then it will be that. It does not say it MUST be accessed. That is what nonnull is for. >I didn't want to use __attribute__((nonnull)) because the optimizer may use >that knowledge to remove nullptr checks. It only uses it afterwards or inside the function. It cannot use nonnull attribute to optimize before the access has happened.
[Bug c++/108893] attribute access read_only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108893 Andrew Pinski changed: What|Removed |Added Resolution|DUPLICATE |INVALID --- Comment #6 from Andrew Pinski --- >From the manual: Also, the access attribute does not imply the attribute nonnull; it may be appropriate to add both attributes at the declaration of a function that unconditionally manipulates a buffer via a pointer argument. See the nonnull attribute for more information and caveats.
[Bug c++/108893] attribute access read_only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108893
--- Comment #5 from Jonny Grant ---
Here is an example, no warnings during compilation.
https://godbolt.org/z/h8E7r3Wf8
#include
// Try get a build warning for nullptr dereference
__attribute__ ((access (read_only, 1, 2))) void f(char * s, size_t size);
void f(char * s, size_t size)
{
*s = 'a';
}
int main()
{
char * s = nullptr;
f(s, 1);
}
[Bug c++/108930] Internal compiler error with -fopenmp (tsubst_omp_for_iterator)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108930 --- Comment #2 from michael_greenburg at byu dot edu --- Created attachment 54535 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54535=edit The *.ii file from `-save-temps`
[Bug c++/108930] Internal compiler error with -fopenmp (tsubst_omp_for_iterator)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108930 --- Comment #1 from michael_greenburg at byu dot edu --- Created attachment 54534 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54534=edit The *.out file from `-freport-bug`
[Bug c++/108930] New: Internal compiler error with -fopenmp (tsubst_omp_for_iterator)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108930 Bug ID: 108930 Summary: Internal compiler error with -fopenmp (tsubst_omp_for_iterator) Product: gcc Version: 12.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: michael_greenburg at byu dot edu Target Milestone: --- Created attachment 54533 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54533=edit The source file GCC VERSION: 12.1.0. The error also occurs with versions 10.2.0, 11.2.0, and 12.2.1; 12.2.1 is the default GCC that comes with Arch, the others I built on the same system as 12.1.0. SYSTEM TYPE: Linux x86_64 (RHEL 7.9) CONFIGURED WITH: /apps/src/gcc/src/gcc-12.1.0/configure --prefix=/apps/gcc/12.1.0 --with-arch=haswell --with-tune=znver3 --with-fpmath=avx --enable-host-shared --enable-threads --enable-__cxa_atexit --enable-valgrind-annotations --disable-multilib --with-dwarf2 GCC COMMAND LINE: g++ -std=c++20 -fopenmp -freport-bug -save-temps -Wall -Wextra trigger_bug.cc OBSERVED AND EXPECTED BEHAVIOR: I would expect the program to compile and run successfully (as it does without `-fopenmp`) rather than dying on an internal compiler error. I've attached `trigger_bug.cc` (a minimal example) and will also attach the *.out file that resulted from `-freport-bug` and the *.ii file that resulted from `-save-temps`. It seems like this might be related: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105839 COMPILER OUTPUT: trigger_bug.cc: In instantiation of 'const auto product(std::array<_Tp, _Nm>) [with T = int; long unsigned int N = 3]': trigger_bug.cc:39:25: required from here trigger_bug.cc:26:9: internal compiler error: in tsubst_omp_for_iterator, at cp/pt.cc:18126 26 | for (auto i=ibegin; ihttps://gcc.gnu.org/bugs/> for instructions. Preprocessed source stored into /tmp/ccvkbzHf.out file, please attach this to your bugreport.
[Bug ipa/108871] attribute nonnull does not spot nullptr O2 and above when function inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108871 --- Comment #7 from Jonny Grant --- (In reply to Jakub Jelinek from comment #6) > (In reply to Jonathan Wakely from comment #5) > > (In reply to Andrew Pinski from comment #3) > > > *** Bug 108893 has been marked as a duplicate of this bug. *** > > > > N.B. this one is about __attribute__((access(read_only, 1))) not nonnull. > > The docs already seem to imply that it requires a non-null pointer: > > > > The read_only access mode specifies that the pointer to which it applies > > is used to > > read the referenced object but not write to it. Unless the argument > > specifying the > > size of the access denoted by size-index is zero, the referenced object > > must be > > initialized. > > > > If a non-zero size implies an initialized object, then it also implies a > > non-null pointer (since a null pointer doesn't point to an initialized > > object). > > > > I don't know if we want this PR to be specific to the nonnull attribute, or > > if it makes sense to use it for access(read_only) too. > > On the other side, looking at glibc sources, access attributes there are > used on many functions together with nonnull attributes for the same > arguments and in many cases in places where there are not nonnull > attributes. So, making access attribute imply non-null might not be > desirable in real-world unless it is already implied. > So it might be just that it is badly documented. Hi Jakub, Did you manage to get gcc to give a build warning from those __attr_access read_only lines in glibc? I haven't found a way to activate any build warnings. attribute nonnull seems to be used by optimizer to remove any NULL checks it finds.
[Bug fortran/108923] memory leak of get_intrinsic_dummy_arg result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108923 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #5 from anlauf at gcc dot gnu.org --- At r13-6337-g24c9edfa73632276d7698c103f35833f29804d98 is still get for testcase gcc/testsuite/gfortran.dg/predcom-1.f ==2885== 32 bytes in 2 blocks are definitely lost in loss record 8 of 354 ==2885==at 0x4C39571: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==2885==by 0x2077B44: xcalloc (xmalloc.c:164) ==2885==by 0x90FE52: get_intrinsic_dummy_arg (intrinsic.cc:4265) ==2885==by 0x90FE52: sort_actual(char const*, gfc_actual_arglist**, gfc_intrinsic_arg*, locus*) (intrinsic.cc:4433) ==2885==by 0x9100E8: check_specific(gfc_intrinsic_sym*, gfc_expr*, int) (intrinsic.cc:4774) ==2885==by 0x918D29: gfc_intrinsic_func_interface(gfc_expr*, int) (intrinsic.cc:5032) ==2885==by 0x97DB9D: resolve_generic_f0 (resolve.cc:2772) ==2885==by 0x97DB9D: resolve_generic_f (resolve.cc:2789) ==2885==by 0x97DB9D: resolve_function (resolve.cc:3347) ==2885==by 0x97DB9D: gfc_resolve_expr(gfc_expr*) [clone .part.0] (resolve.cc:7211) ==2885==by 0x980B4F: gfc_resolve_expr (resolve.cc:7177) ==2885==by 0x980B4F: resolve_operator(gfc_expr*) (resolve.cc:4092) ==2885==by 0x97BC57: gfc_resolve_expr(gfc_expr*) [clone .part.0] (resolve.cc:7204) ==2885==by 0x985AF8: gfc_resolve_expr (resolve.cc:7177) ==2885==by 0x985AF8: gfc_resolve_code(gfc_code*, gfc_namespace*) (resolve.cc:12011) ==2885==by 0x989425: gfc_resolve_blocks(gfc_code*, gfc_namespace*) (resolve.cc:10996) ==2885==by 0x985AAD: gfc_resolve_code(gfc_code*, gfc_namespace*) (resolve.cc:11997) ==2885==by 0x98921D: resolve_codes(gfc_namespace*) (resolve.cc:17670)
[Bug fortran/108923] memory leak of get_intrinsic_dummy_arg result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108923 --- Comment #4 from CVS Commits --- The master branch has been updated by Mikael Morin : https://gcc.gnu.org/g:24c9edfa73632276d7698c103f35833f29804d98 commit r13-6337-g24c9edfa73632276d7698c103f35833f29804d98 Author: Mikael Morin Date: Fri Feb 24 22:11:17 2023 +0100 fortran: Plug leak of associated_dummy memory. [PR108923] This fixes a memory leak by accompanying the release of gfc_actual_arglist elements' memory with a release of the associated_dummy field memory (if allocated). Actual argument copy is adjusted as well so that each copy can free its field independently. PR fortran/108923 gcc/fortran/ChangeLog: * expr.cc (gfc_free_actual_arglist): Free associated_dummy memory. (gfc_copy_actual_arglist): Make a copy of the associated_dummy field if it is set in the original element.
[Bug fortran/68800] Fortran FE produces many memory leaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68800 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #7 from anlauf at gcc dot gnu.org --- gfortran.dg/gomp/associate1.f90 is another candidate showing one of the tracebacks as in comment#0, even without -fopenmp: ==5113== 224 bytes in 1 blocks are definitely lost in loss record 276 of 356 ==5113==at 0x4C39571: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==5113==by 0x205F054: xcalloc (xmalloc.c:164) ==5113==by 0x8F891F: gfc_get_expr() (expr.cc:49) ==5113==by 0x96ED01: gfc_match_rvalue(gfc_expr**) (primary.cc:3831) ==5113==by 0x9338DE: match_primary (matchexp.cc:157) ==5113==by 0x9338DE: match_level_1 (matchexp.cc:211) ==5113==by 0x9338DE: match_mult_operand(gfc_expr**) (matchexp.cc:267) ==5113==by 0x933C18: match_add_operand(gfc_expr**) (matchexp.cc:356) ==5113==by 0x933F0F: match_level_2(gfc_expr**) (matchexp.cc:480) ==5113==by 0x9340D6: match_level_3(gfc_expr**) (matchexp.cc:551) ==5113==by 0x934212: match_level_4 (matchexp.cc:599) ==5113==by 0x934212: match_and_operand(gfc_expr**) (matchexp.cc:693) ==5113==by 0x9343F6: match_or_operand(gfc_expr**) (matchexp.cc:722) ==5113==by 0x934506: match_equiv_operand(gfc_expr**) (matchexp.cc:765) ==5113==by 0x934618: match_level_5(gfc_expr**) (matchexp.cc:811) ==5113== ==5113== 3,232 (672 direct, 2,560 indirect) bytes in 3 blocks are definitely lost in loss record 322 of 356 ==5113==at 0x4C39571: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==5113==by 0x205F054: xcalloc (xmalloc.c:164) ==5113==by 0x8F891F: gfc_get_expr() (expr.cc:49) ==5113==by 0x96EABE: gfc_match_rvalue(gfc_expr**) (primary.cc:3579) ==5113==by 0x9338DE: match_primary (matchexp.cc:157) ==5113==by 0x9338DE: match_level_1 (matchexp.cc:211) ==5113==by 0x9338DE: match_mult_operand(gfc_expr**) (matchexp.cc:267) ==5113==by 0x933C18: match_add_operand(gfc_expr**) (matchexp.cc:356) ==5113==by 0x933F0F: match_level_2(gfc_expr**) (matchexp.cc:480) ==5113==by 0x9340D6: match_level_3(gfc_expr**) (matchexp.cc:551) ==5113==by 0x934212: match_level_4 (matchexp.cc:599) ==5113==by 0x934212: match_and_operand(gfc_expr**) (matchexp.cc:693) ==5113==by 0x9343F6: match_or_operand(gfc_expr**) (matchexp.cc:722) ==5113==by 0x934506: match_equiv_operand(gfc_expr**) (matchexp.cc:765) ==5113==by 0x934618: match_level_5(gfc_expr**) (matchexp.cc:811) ==5113== ==5113== 4,864 (448 direct, 4,416 indirect) bytes in 2 blocks are definitely lost in loss record 329 of 356 ==5113==at 0x4C39571: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==5113==by 0x205F054: xcalloc (xmalloc.c:164) ==5113==by 0x8F891F: gfc_get_expr() (expr.cc:49) ==5113==by 0x96ED72: gfc_match_rvalue(gfc_expr**) (primary.cc:3816) ==5113==by 0x9338DE: match_primary (matchexp.cc:157) ==5113==by 0x9338DE: match_level_1 (matchexp.cc:211) ==5113==by 0x9338DE: match_mult_operand(gfc_expr**) (matchexp.cc:267) ==5113==by 0x933C18: match_add_operand(gfc_expr**) (matchexp.cc:356) ==5113==by 0x933F0F: match_level_2(gfc_expr**) (matchexp.cc:480) ==5113==by 0x9340D6: match_level_3(gfc_expr**) (matchexp.cc:551) ==5113==by 0x934212: match_level_4 (matchexp.cc:599) ==5113==by 0x934212: match_and_operand(gfc_expr**) (matchexp.cc:693) ==5113==by 0x9343F6: match_or_operand(gfc_expr**) (matchexp.cc:722) ==5113==by 0x934506: match_equiv_operand(gfc_expr**) (matchexp.cc:765) ==5113==by 0x934618: match_level_5(gfc_expr**) (matchexp.cc:811)
[Bug fortran/108924] memory leak in doloop_warn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108924 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-02-24 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org --- Comment #3 from anlauf at gcc dot gnu.org --- Taken. Waiting on feedback.
[Bug bootstrap/108929] bfin-openbsd: Issues calling `as` when trying to build Module-2 components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108929 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|WAITING |RESOLVED --- Comment #2 from Andrew Pinski --- [cfg 2023-02-21 16:27:09] checking for as... no [cfg 2023-02-21 16:27:09] checking for bfin-openbsd-as... no .. [cfg 2023-02-21 16:27:09] checking where to find the target ar... pre-installed [cfg 2023-02-21 16:27:09] checking where to find the target as... pre-installed NOT a GCC bug. There was no target as installed ...
[Bug fortran/108924] memory leak in doloop_warn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108924 --- Comment #2 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:45f406c4f62e516b58dcda20b5a7aa43ff0aa0f3 commit r13-6336-g45f406c4f62e516b58dcda20b5a7aa43ff0aa0f3 Author: Harald Anlauf Date: Fri Feb 24 19:56:32 2023 +0100 Fortran: frontend passes do_subscript leaks gmp memory [PR108924] gcc/fortran/ChangeLog: PR fortran/108924 * frontend-passes.cc (do_subscript): Clear used gmp variable.
[Bug driver/108929] bfin-openbsd: Issues calling `as` when trying to build Module-2 components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108929 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING Last reconfirmed||2023-02-24 --- Comment #1 from Andrew Pinski --- >[all 2023-02-21 19:37:04] >/var/lib/laminar/run/gcc-bfin-openbsd/35/toolchain-build/./gcc/as: 114: exec: >-o: not found Can you attach the toplevel config.log ? I suspect you didn't build binutils first or not doing a combined build or bfin-openbsd is not supported by binutils ...
[Bug driver/108929] New: bfin-openbsd: Issues calling `as` when trying to build Module-2 components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108929 Bug ID: 108929 Summary: bfin-openbsd: Issues calling `as` when trying to build Module-2 components Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: jbg...@lug-owl.de Target Milestone: --- Hi! For --target=bfin-openbsd, I see the assembler being called in some way that doesn't seem to work: [all 2023-02-21 19:37:03] test -d /var/lib/laminar/run/gcc-bfin-openbsd/35/toolchain-build/gcc/m2/gm2-libs || /bin/bash ../../gcc/gcc/../mkinstalldirs /var/lib/laminar/run/gcc-bfin-openbsd/35/toolchain-build/gcc/m2/gm2-libs [all 2023-02-21 19:37:03] echo "GM2_FOR_TARGET /var/lib/laminar/run/gcc-bfin-openbsd/35/toolchain-build/./gcc/gm2 -B/var/lib/laminar/run/gcc-bfin-openbsd/35/toolchain-build/./gcc/ " [all 2023-02-21 19:37:03] GM2_FOR_TARGET /var/lib/laminar/run/gcc-bfin-openbsd/35/toolchain-build/./gcc/gm2 -B/var/lib/laminar/run/gcc-bfin-openbsd/35/toolchain-build/./gcc/ [all 2023-02-21 19:37:03] echo "GCC_FOR_TARGET /var/lib/laminar/run/gcc-bfin-openbsd/35/toolchain-build/./gcc/xgcc -B/var/lib/laminar/run/gcc-bfin-openbsd/35/toolchain-build/./gcc/ " [all 2023-02-21 19:37:03] GCC_FOR_TARGET /var/lib/laminar/run/gcc-bfin-openbsd/35/toolchain-build/./gcc/xgcc -B/var/lib/laminar/run/gcc-bfin-openbsd/35/toolchain-build/./gcc/ [all 2023-02-21 19:37:03] /bin/bash ../../gcc/gcc/m2/tools-src/makeSystem -fpim \ [all 2023-02-21 19:37:03] ../../gcc/gcc/m2/gm2-libs/SYSTEM.def \ [all 2023-02-21 19:37:03] ../../gcc/gcc/m2/gm2-libs/SYSTEM.mod \ [all 2023-02-21 19:37:03] -I../../gcc/gcc/m2/gm2-libs \ [all 2023-02-21 19:37:03] "/var/lib/laminar/run/gcc-bfin-openbsd/35/toolchain-build/./gcc/gm2 -B/var/lib/laminar/run/gcc-bfin-openbsd/35/toolchain-build/./gcc/ " /var/lib/laminar/run/gcc-bfin-openbsd/35/toolchain-build/gcc/m2/gm2-libs/SYSTEM.def [all 2023-02-21 19:37:04] /var/lib/laminar/run/gcc-bfin-openbsd/35/toolchain-build/./gcc/as: 114: exec: -o: not found [all 2023-02-21 19:37:04] SYSTEM module creates type: LOC [all 2023-02-21 19:37:04] SYSTEM module creates type: WORD [all 2023-02-21 19:37:04] SYSTEM module creates type: BYTE [all 2023-02-21 19:37:04] SYSTEM module creates type: ADDRESS [all 2023-02-21 19:37:04] SYSTEM module creates type: INTEGER8 [all 2023-02-21 19:37:04] SYSTEM module creates type: INTEGER16 [all 2023-02-21 19:37:04] SYSTEM module creates type: INTEGER32 [all 2023-02-21 19:37:04] SYSTEM module creates type: INTEGER64 [all 2023-02-21 19:37:04] SYSTEM module creates type: CARDINAL8 [all 2023-02-21 19:37:04] SYSTEM module creates type: CARDINAL16 [all 2023-02-21 19:37:04] SYSTEM module creates type: CARDINAL32 [all 2023-02-21 19:37:04] SYSTEM module creates type: CARDINAL64 [all 2023-02-21 19:37:04] SYSTEM module creates type: WORD16 [all 2023-02-21 19:37:04] SYSTEM module creates type: WORD32 [all 2023-02-21 19:37:04] SYSTEM module creates type: WORD64 [all 2023-02-21 19:37:04] SYSTEM module creates type: BITSET8 [all 2023-02-21 19:37:04] SYSTEM module creates type: BITSET16 [all 2023-02-21 19:37:04] SYSTEM module creates type: BITSET32 [all 2023-02-21 19:37:04] SYSTEM module creates type: REAL32 [all 2023-02-21 19:37:04] SYSTEM module creates type: REAL64 [all 2023-02-21 19:37:04] SYSTEM module creates type: COMPLEX32 [all 2023-02-21 19:37:04] SYSTEM module creates type: COMPLEX64 [all 2023-02-21 19:37:04] SYSTEM module creates type: CSIZE_T [all 2023-02-21 19:37:04] SYSTEM module creates type: CSSIZE_T [all 2023-02-21 19:37:04] /var/lib/laminar/run/gcc-bfin-openbsd/35/toolchain-build/./gcc/as: 114: exec: -o: not found [all 2023-02-21 19:37:04] make[1]: *** [../../gcc/gcc/m2/Make-lang.in:1564: /var/lib/laminar/run/gcc-bfin-openbsd/35/toolchain-build/gcc/m2/gm2-libs/SYSTEM.def] Error 1 [all 2023-02-21 19:37:04] rm m2/gm2-compiler-boot/P2Build.mod m2/gm2-compiler-boot/P0SyntaxCheck.mod m2/gm2-compiler-boot/PCBuild.mod m2/gm2-compiler-boot/PHBuild.mod m2/gm2-compiler-boot/P1Build.mod m2/gm2-compiler-boot/P3Build.mod [all 2023-02-21 19:37:04] make[1]: Leaving directory '/var/lib/laminar/run/gcc-bfin-openbsd/35/toolchain-build/gcc' [all 2023-02-21 19:37:05] make: *** [Makefile:4623: all-gcc] Error 2 (Full build lot at http://toolchain.lug-owl.de/laminar/log/gcc-bfin-openbsd/35)
[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977 --- Comment #30 from Iain Sandoe --- (In reply to ibuclaw from comment #29) > (In reply to Iain Sandoe from comment #27) > > great! > > > > we make more progress now - at least past libphobos configure: > > > > we now fail building druntime/core/atomic.d and I am not quite sure how to > > interpret the backtrace (from b internal_error). > > > > d21`_D3dmd6access17checkSymbolAccessFPSQBh6dscope5ScopeCQBy7dsymbol7DsymbolZb > > (sc=, s=) at access.d:296 > > > My fear is that now it's corrupting the return in other ways now, this time > within D itself. I see.. that might be the tricky aspect of trying to have a different ABI internally and for accessing C/C++. Not sure how to solve it (are functions with C-family interfaces marked as such?)
[Bug fortran/108923] memory leak of get_intrinsic_dummy_arg result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108923 --- Comment #3 from Mikael Morin --- Here is a small reproducer by the way: program p implicit none call s(0) contains subroutine s(i) integer :: i end subroutine s end program p
[Bug fortran/108923] memory leak of get_intrinsic_dummy_arg result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108923 --- Comment #2 from Mikael Morin --- (In reply to Mikael Morin from comment #1) > Should be easy to fix anyway. Not that easy after all. The following (obvious) fix regresses heavily. diff --git a/gcc/fortran/expr.cc b/gcc/fortran/expr.cc index c295721b9d6..73ee50e385c 100644 --- a/gcc/fortran/expr.cc +++ b/gcc/fortran/expr.cc @@ -545,6 +545,7 @@ gfc_free_actual_arglist (gfc_actual_arglist *a1) a2 = a1->next; if (a1->expr) gfc_free_expr (a1->expr); + free (a1->associated_dummy); free (a1); a1 = a2; }
[Bug target/86802] riscv port needs updating for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86802 Andrew Pinski changed: What|Removed |Added Assignee|wilson at gcc dot gnu.org |unassigned at gcc dot gnu.org Status|ASSIGNED|NEW --- Comment #3 from Andrew Pinski --- I doubt Jim is working on this any more. I suspect we might need to have this defined for some cores and a way to disable it fully for others (maybe even an option at build time). E.g. Linux compilers should always define this while the elf compiler might not define this.
[Bug target/108928] New: epiphany-elf: unrecognizable insn (internal compiler error: in extract_insn, at recog.cc:2791) triggered during Modula-2 build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108928 Bug ID: 108928 Summary: epiphany-elf: unrecognizable insn (internal compiler error: in extract_insn, at recog.cc:2791) triggered during Modula-2 build Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jbg...@lug-owl.de Target Milestone: --- Hi! My automated testing found an issue with --target=epiphany-elf: .../gcc/configure '--with-pkgversion=basepoints/gcc-13-6140-g63471c50088, built at 1677005096' --prefix=/var/lib/laminar/run/gcc-epiphany-elf/34/toolchain-install --enable-werror-always --enable-languages=all --disable-gcov --disable-shared --disable-threads --target=epiphany-elf --without-headers [...] make V=1 all-gcc [...] [all 2023-02-21 21:50:49] if test "xinfo" = xinfo; then \ [all 2023-02-21 21:50:49] rm -f doc/gccgo.info*; \ [all 2023-02-21 21:50:49] makeinfo --split-size=500 --no-split -I ../../gcc/gcc/doc \ [all 2023-02-21 21:50:49] -I ../../gcc/gcc/doc/include -o doc/gccgo.info ../../gcc/gcc/go/gccgo.texi; \ [all 2023-02-21 21:50:49] else true; fi [all 2023-02-21 21:50:50] test -d /var/lib/laminar/run/gcc-epiphany-elf/34/toolchain-build/gcc/m2/gm2-libs || /bin/bash ../../gcc/gcc/../mkinstalldirs /var/lib/laminar/run/gcc-epiphany-elf/34/toolchain-build/gcc/m2/gm2-libs [all 2023-02-21 21:50:50] echo "GM2_FOR_TARGET /var/lib/laminar/run/gcc-epiphany-elf/34/toolchain-build/./gcc/gm2 -B/var/lib/laminar/run/gcc-epiphany-elf/34/toolchain-build/./gcc/ " [all 2023-02-21 21:50:50] GM2_FOR_TARGET /var/lib/laminar/run/gcc-epiphany-elf/34/toolchain-build/./gcc/gm2 -B/var/lib/laminar/run/gcc-epiphany-elf/34/toolchain-build/./gcc/ [all 2023-02-21 21:50:50] echo "GCC_FOR_TARGET /var/lib/laminar/run/gcc-epiphany-elf/34/toolchain-build/./gcc/xgcc -B/var/lib/laminar/run/gcc-epiphany-elf/34/toolchain-build/./gcc/ " [all 2023-02-21 21:50:50] GCC_FOR_TARGET /var/lib/laminar/run/gcc-epiphany-elf/34/toolchain-build/./gcc/xgcc -B/var/lib/laminar/run/gcc-epiphany-elf/34/toolchain-build/./gcc/ [all 2023-02-21 21:50:50] /bin/bash ../../gcc/gcc/m2/tools-src/makeSystem -fpim \ [all 2023-02-21 21:50:50] ../../gcc/gcc/m2/gm2-libs/SYSTEM.def \ [all 2023-02-21 21:50:50] ../../gcc/gcc/m2/gm2-libs/SYSTEM.mod \ [all 2023-02-21 21:50:50] -I../../gcc/gcc/m2/gm2-libs \ [all 2023-02-21 21:50:50] "/var/lib/laminar/run/gcc-epiphany-elf/34/toolchain-build/./gcc/gm2 -B/var/lib/laminar/run/gcc-epiphany-elf/34/toolchain-build/./gcc/ " /var/lib/laminar/run/gcc-epiphany-elf/34/toolchain-build/gcc/m2/gm2-libs/SYSTEM.def [all 2023-02-21 21:50:50] ../../gcc/gcc/m2/gm2-libs/SYSTEM.mod: In function 'ShiftVal': [all 2023-02-21 21:50:50] ../../gcc/gcc/m2/gm2-libs/SYSTEM.mod:89:1: error: unrecognizable insn: [all 2023-02-21 21:50:50]89 | END ShiftVal ; [all 2023-02-21 21:50:50] | ^~~ [all 2023-02-21 21:50:50] (insn 400 342 343 7 (parallel [ [all 2023-02-21 21:50:50] (set (mem/c:CC (plus:SI (reg/f:SI 11 fp) [all 2023-02-21 21:50:50] (const_int 84 [0x54])) [7 %sfp+-20 S4 A32]) [all 2023-02-21 21:50:50] (reg:CC 18 r18)) [all 2023-02-21 21:50:50] (use (const_int -4337 [0xef0f])) [all 2023-02-21 21:50:50] (clobber (scratch:SI)) [all 2023-02-21 21:50:50] ]) "../../gcc/gcc/m2/gm2-libs/SYSTEM.mod":80:32 discrim 1 -1 [all 2023-02-21 21:50:50] (nil)) [all 2023-02-21 21:50:50] during RTL pass: reload [all 2023-02-21 21:50:50] ../../gcc/gcc/m2/gm2-libs/SYSTEM.mod:89:1: internal compiler error: in extract_insn, at recog.cc:2791 [all 2023-02-21 21:50:50] 0x670d08 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*) [all 2023-02-21 21:50:50] ../../gcc/gcc/rtl-error.cc:108 [all 2023-02-21 21:50:50] 0x670d24 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*) [all 2023-02-21 21:50:50] ../../gcc/gcc/rtl-error.cc:116 [all 2023-02-21 21:50:50] 0x66f763 extract_insn(rtx_insn*) [all 2023-02-21 21:50:50] ../../gcc/gcc/recog.cc:2791 [all 2023-02-21 21:50:50] 0xce5a14 extract_insn_cached(rtx_insn*) [all 2023-02-21 21:50:50] ../../gcc/gcc/recog.cc:2680 [all 2023-02-21 21:50:50] 0x9fa4a4 cleanup_subreg_operands(rtx_insn*) [all 2023-02-21 21:50:50] ../../gcc/gcc/final.cc:3054 [all 2023-02-21 21:50:50] 0xd10ff2 reload(rtx_insn*, int) [all 2023-02-21 21:50:50] ../../gcc/gcc/reload1.cc:1232 [all 2023-02-21 21:50:50] 0xb97f3e do_reload [all 2023-02-21 21:50:50] ../../gcc/gcc/ira.cc:5975 [all 2023-02-21 21:50:50] 0xb97f3e execute [all 2023-02-21 21:50:50] ../../gcc/gcc/ira.cc:6149 [all 2023-02-21 21:50:50] Please submit a full bug report, with preprocessed source (by using -freport-bug). [all 2023-02-21 21:50:50] Please include
[Bug libstdc++/108846] std::copy, std::copy_n and std::copy_backward on potentially overlapping subobjects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108846
--- Comment #12 from Giuseppe D'Angelo ---
(In reply to Jonathan Wakely from comment #9)
> (In reply to Giuseppe D'Angelo from comment #5)
> > https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/bits/
> > stl_algobase.h#L417-L437
> >
> > Is the extent of the fix just to add another branch to the if (_Num) check
> > here?
>
> Yes, I think that's the simplest place to fix it.
>
> And we can even get rid of the static assertion, because the Num==1 branch
> will require assignability now.
>
> --- a/libstdc++-v3/include/bits/stl_algobase.h
> +++ b/libstdc++-v3/include/bits/stl_algobase.h
> @@ -737,16 +737,11 @@ _GLIBCXX_END_NAMESPACE_CONTAINER
> static _Tp*
> __copy_move_b(const _Tp* __first, const _Tp* __last, _Tp* __result)
> {
> -#if __cplusplus >= 201103L
> - using __assignable = __conditional_t<_IsMove,
> - is_move_assignable<_Tp>,
> - is_copy_assignable<_Tp>>;
> - // trivial types can have deleted assignment
> - static_assert( __assignable::value, "type must be assignable" );
> -#endif
> const ptrdiff_t _Num = __last - __first;
> - if (_Num)
> + if (__builtin_expect(_Num > 1, true))
> __builtin_memmove(__result - _Num, __first, sizeof(_Tp) * _Num);
> + else if (_Num == 1)
> + *__result = *__first;
> return __result - _Num;
> }
> };
If this code path also takes care of std::move(b,e,o), then this doesn't sound
correct -- for _Num==1 and _IsMove==true, then it should use a move assignment
(std::move(*__first)). But then that std::move doesn't actually work as __first
is a pointer to const...
[Bug libstdc++/108030] `std::experimental::simd` not inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108030 Matthias Kretz (Vir) changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #13 from Matthias Kretz (Vir) --- Fixed on trunk. Will backport later if no issues crop up.
[Bug libstdc++/108030] `std::experimental::simd` not inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108030 --- Comment #12 from CVS Commits --- The master branch has been updated by Matthias Kretz : https://gcc.gnu.org/g:e37b04328ae68f91efe1fb2c5de9122be34bc74a commit r13-6334-ge37b04328ae68f91efe1fb2c5de9122be34bc74a Author: Matthias Kretz Date: Mon Feb 20 17:49:37 2023 +0100 libstdc++: Always-inline most of non-cmath fixed_size implementation For simd, the inlining behavior should be similar to builtin types. (No operator on buitin types is ever translated into a function call.) Therefore, always_inline is the right choice (i.e. inline on -O0 as well). Signed-off-by: Matthias Kretz libstdc++-v3/ChangeLog: PR libstdc++/108030 * include/experimental/bits/simd_fixed_size.h (_SimdImplFixedSize::_S_broadcast): Replace inline with _GLIBCXX_SIMD_INTRINSIC. (_SimdImplFixedSize::_S_generate): Likewise. (_SimdImplFixedSize::_S_load): Likewise. (_SimdImplFixedSize::_S_masked_load): Likewise. (_SimdImplFixedSize::_S_store): Likewise. (_SimdImplFixedSize::_S_masked_store): Likewise. (_SimdImplFixedSize::_S_min): Likewise. (_SimdImplFixedSize::_S_max): Likewise. (_SimdImplFixedSize::_S_complement): Likewise. (_SimdImplFixedSize::_S_unary_minus): Likewise. (_SimdImplFixedSize::_S_plus): Likewise. (_SimdImplFixedSize::_S_minus): Likewise. (_SimdImplFixedSize::_S_multiplies): Likewise. (_SimdImplFixedSize::_S_divides): Likewise. (_SimdImplFixedSize::_S_modulus): Likewise. (_SimdImplFixedSize::_S_bit_and): Likewise. (_SimdImplFixedSize::_S_bit_or): Likewise. (_SimdImplFixedSize::_S_bit_xor): Likewise. (_SimdImplFixedSize::_S_bit_shift_left): Likewise. (_SimdImplFixedSize::_S_bit_shift_right): Likewise. (_SimdImplFixedSize::_S_remquo): Add inline keyword (to be explicit about not always-inline, yet). (_SimdImplFixedSize::_S_isinf): Likewise. (_SimdImplFixedSize::_S_isfinite): Likewise. (_SimdImplFixedSize::_S_isnan): Likewise. (_SimdImplFixedSize::_S_isnormal): Likewise. (_SimdImplFixedSize::_S_signbit): Likewise.
[Bug libstdc++/108856] Increment and decrement on std::experimental::where_expression should optimize better
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108856 --- Comment #2 from CVS Commits --- The master branch has been updated by Matthias Kretz : https://gcc.gnu.org/g:6ce55180d494b616e2e3e68ffedfe9007e42ca06 commit r13-6333-g6ce55180d494b616e2e3e68ffedfe9007e42ca06 Author: Matthias Kretz Date: Mon Feb 20 16:33:31 2023 +0100 libstdc++: More efficient masked inc-/decrement implementation Signed-off-by: Matthias Kretz libstdc++-v3/ChangeLog: PR libstdc++/108856 * include/experimental/bits/simd_builtin.h (_SimdImplBuiltin::_S_masked_unary): More efficient implementation of masked inc-/decrement for integers and floats without AVX2. * include/experimental/bits/simd_x86.h (_SimdImplX86::_S_masked_unary): New. Use AVX512 masked subtract builtins for masked inc-/decrement.
[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977 --- Comment #29 from ibuclaw at gcc dot gnu.org --- (In reply to Iain Sandoe from comment #27) > great! > > we make more progress now - at least past libphobos configure: > > we now fail building druntime/core/atomic.d and I am not quite sure how to > interpret the backtrace (from b internal_error). > > d21`_D3dmd6access17checkSymbolAccessFPSQBh6dscope5ScopeCQBy7dsymbol7DsymbolZb > (sc=, s=) at access.d:296 > My fear is that now it's corrupting the return in other ways now, this time within D itself. access.d:296: final switch (s.visible().kind)
[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977
--- Comment #28 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #27)
> great!
>
> we make more progress now - at least past libphobos configure:
>
> we now fail building druntime/core/atomic.d and I am not quite sure how to
> interpret the backtrace (from b internal_error).
>
frame #9: 0x2a18
d21`_D4core9exception__T15__switch_errorTZQsFNaNbNiNeAyakZv(file=,
line=) at exception.d:17
14 {
15 // Consider making this a compile time check.
16 version (D_Exceptions)
-> 17 throw staticError!SwitchError("No appropriate switch clause
found", file, line, null);
18 else
19 assert(0, "No appropriate switch clause found");
[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977 --- Comment #27 from Iain Sandoe --- great! we make more progress now - at least past libphobos configure: we now fail building druntime/core/atomic.d and I am not quite sure how to interpret the backtrace (from b internal_error). (lldb) bt * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT) * frame #0: 0xa7273850 libdyld.dylib`misaligned_stack_error_ frame #1: 0xa9847000 libsystem_malloc.dylib frame #2: 0x01a2e40b d21`backtrace_simple + 75 frame #3: 0x01bfcca4 d21`_D3gcc9backtrace12LibBacktrace6__ctorMFNiiZCQBqQBpQBi(this=0x052c3800, firstFrame=4) at backtrace.d:207 frame #4: 0x01c3370a d21`_D4core8lifetime__T7emplaceTC3gcc9backtrace12LibBacktraceTiZQBpFNiQBmKiZQBs(chunk=0x052c3800, _param_1=0xbfffefa4) at lifetime.d:126 frame #5: 0x01c3373a d21`_D4core7runtime19defaultTraceHandlerFPvZ__T8allocateTC3gcc9backtrace12LibBacktraceTiZQBqFNiiZQBo(_param_0=) at runtime.d:752 frame #6: 0x01c3374a d21`_D4core7runtime19defaultTraceHandlerFPvZC6object9Throwable9TraceInfo(ptr=0x) at runtime.d:762 frame #7: 0x01c1f560 d21`_d_createTrace(t=0x04615108, context=0x) at deh.d:51 frame #8: 0x01c013cb d21`_d_throw(object=0x04615108) at deh.d:484 frame #9: 0x2a18 d21`_D4core9exception__T15__switch_errorTZQsFNaNbNiNeAyakZv(file=, line=) at exception.d:17 frame #10: 0x29d5 d21`_D4core9exception__T15__switch_errorTZQsFNaNbNiNeAyakZv(file=(length = 40, ptr = "/src-local/gcc-master/gcc/d/dmd/access.d"), line=296) at exception.d:13 frame #11: 0x2c8b d21`_D3dmd6access17checkSymbolAccessFPSQBh6dscope5ScopeCQBy7dsymbol7DsymbolZb(sc=, s=) at access.d:296
[Bug fortran/108921] ICE: using the result of an impure function in automatic character allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108921 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Keywords||ice-on-invalid-code CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- The ever popular NULL pointer dereference from parsing invalid code. With this patch diff --git a/gcc/fortran/class.cc b/gcc/fortran/class.cc index ae653e74437..9ece4482f76 100644 --- a/gcc/fortran/class.cc +++ b/gcc/fortran/class.cc @@ -2491,7 +2491,7 @@ gfc_find_derived_vtab (gfc_symbol *derived) /* This is elemental so that arrays are automatically treated correctly by the scalarizer. */ copy->attr.elemental = 1; - if (ns->proc_name->attr.flavor == FL_MODULE) + if (ns->proc_name && ns->proc_name->attr.flavor == FL_MODULE) copy->module = ns->proc_name->name; gfc_set_sym_referenced (copy); /* Set up formal arguments. */ diff --git a/gcc/fortran/symbol.cc b/gcc/fortran/symbol.cc index 2ce0f3e4df7..54c9441d7fd 100644 --- a/gcc/fortran/symbol.cc +++ b/gcc/fortran/symbol.cc @@ -2499,7 +2499,7 @@ gfc_find_component (gfc_symbol *sym, const char *name, if (sym->attr.flavor == FL_DERIVED) sym = gfc_use_derived (sym); else -gcc_assert (gfc_fl_struct (sym->attr.flavor)); +return NULL; if (sym == NULL) return NULL; I get % gfcx -c a.f90 a.f90:13:34: 13 | character(len=this%f())::r ! problem appears here | 1 Error: Symbol 'r' at (1) already has basic type of REAL a.f90:13:22: 13 | character(len=this%f())::r ! problem appears here | 1 Error: Function 'this' at (1) must be PURE a.f90:14:10: 14 | r='42' | 1 Error: Cannot convert CHARACTER(2) to REAL(4) at (1) a.f90:19:9: 19 | use lib | 1 Fatal Error: Cannot open module file 'lib.mod' for reading at (1): No such file or directory compilation terminated. The first and last errors appear to be run on errors. The second error appears to be the relevant one, but the 'name' of the function is munged. Anywhoo, the patch fixes the ICE
[Bug target/108927] error: too few arguments to function 'long unsigned int __riscv_vsetvlmax_e8mf8(void)'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108927 --- Comment #1 from Andrew Pinski --- You are using a month old sources, can you try with a much newer trunk sources?
[Bug fortran/108923] memory leak of get_intrinsic_dummy_arg result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108923 Mikael Morin changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mikael at gcc dot gnu.org Last reconfirmed||2023-02-24 CC||mikael at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Mikael Morin --- I'm the culprit I guess. Should be easy to fix anyway. Taking.
[Bug fortran/108924] memory leak in doloop_warn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108924 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #1 from anlauf at gcc dot gnu.org --- Created attachment 54532 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54532=edit Tentative patch Does the attached fix this? Without a testcase this seems to be the fix obtained from reviewing the surrounding code. Regtests cleanly here.
[Bug c++/108927] New: error: too few arguments to function 'long unsigned int __riscv_vsetvlmax_e8mf8(void)'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108927
Bug ID: 108927
Summary: error: too few arguments to function 'long unsigned
int __riscv_vsetvlmax_e8mf8(void)'
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: malat at debian dot org
Target Milestone: ---
For some reason riscv64 rvv extension is broken. It is supposed to work with
the new naming convention:
* https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg298381.html
% head ./gcc/testsuite/gcc.target/riscv/rvv/base/vsetvl-1.c
/* { dg-do compile } */
/* { dg-options "-march=rv32gcv -mabi=ilp32d -O3" } */
However consider now
```
% cat t.c
#include
int main()
{
size_t vl = __riscv_vsetvlmax_e8mf8();
return vl;
}
```
gives:
```
g++ -march=rv64gcv1p0 t.c
t.c: In function 'int main()':
t.c:5:39: error: too few arguments to function 'long unsigned int
__riscv_vsetvlmax_e8mf8(void)'
5 |size_t vl = __riscv_vsetvlmax_e8mf8();
|~~~^~
In file included from t.c:1:
/usr/lib/gcc-snapshot/lib/gcc/riscv64-linux-gnu/13/include/riscv_vector.h:94:25:
note: declared here
94 | #pragma riscv intrinsic "vector"
| ^~~~
```
Full log:
% LIBRARY_PATH=/usr/lib/gcc-snapshot/lib /usr/lib/gcc-snapshot/bin/g++
-march=rv64gcv1p0 -v t.c
Using built-in specs.
COLLECT_GCC=/usr/lib/gcc-snapshot/bin/g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc-snapshot/libexec/gcc/riscv64-linux-gnu/13/lto-wrapper
Target: riscv64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 20230108-1'
--with-bugurl=file:///usr/share/doc/gcc-snapshot/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2,rust
--prefix=/usr/lib/gcc-snapshot --with-gcc-major-version-only --program-prefix=
--enable-shared --enable-linker-build-id --disable-nls --enable-bootstrap
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm
--disable-libquadmath --disable-libquadmath-support --enable-plugin
--with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-werror --disable-multilib --with-arch=rv64gc --with-abi=lp64d
--enable-checking=yes --build=riscv64-linux-gnu --host=riscv64-linux-gnu
--target=riscv64-linux-gnu --with-build-config=bootstrap-lto-lean
--enable-link-serialization=2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.0 20230108 (experimental) [master r13-5059-gd901bf8a44a]
(Debian 20230108-1)
COLLECT_GCC_OPTIONS='-march=rv64gcv1p0' '-v' '-shared-libgcc' '-mabi=lp64d'
'-misa-spec=20191213'
'-march=rv64imafdc_v1p0_zicsr_zifencei_zve32f_zve32x_zve64d_zve64f_zve64x_zvl128b_zvl32b_zvl64b'
'-dumpdir' 'a-'
/usr/lib/gcc-snapshot/libexec/gcc/riscv64-linux-gnu/13/cc1plus -quiet -v
-imultilib . -imultiarch riscv64-linux-gnu -D_GNU_SOURCE t.c -quiet -dumpdir a-
-dumpbase t.c -dumpbase-ext .c -march=rv64gcv1p0 -mabi=lp64d
-misa-spec=20191213
-march=rv64imafdc_v1p0_zicsr_zifencei_zve32f_zve32x_zve64d_zve64f_zve64x_zvl128b_zvl32b_zvl64b
-version -o /tmp/ccVVv6RI.s
GNU C++17 (Debian 20230108-1) version 13.0.0 20230108 (experimental) [master
r13-5059-gd901bf8a44a] (riscv64-linux-gnu)
compiled by GNU C version 13.0.0 20230108 (experimental) [master
r13-5059-gd901bf8a44a], GMP version 6.2.1, MPFR version 4.1.1-p1, MPC version
1.3.1, isl version isl-0.25-GMP
warning: MPFR header version 4.1.1-p1 differs from library version 4.2.0.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory "/usr/local/include/riscv64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc-snapshot/lib/gcc/riscv64-linux-gnu/13/include-fixed/riscv64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc-snapshot/lib/gcc/riscv64-linux-gnu/13/include-fixed"
ignoring nonexistent directory
"/usr/lib/gcc-snapshot/lib/gcc/riscv64-linux-gnu/13/../../../../riscv64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc-snapshot/lib/gcc/riscv64-linux-gnu/13/../../../../include/c++/13
/usr/lib/gcc-snapshot/lib/gcc/riscv64-linux-gnu/13/../../../../include/c++/13/riscv64-linux-gnu/.
/usr/lib/gcc-snapshot/lib/gcc/riscv64-linux-gnu/13/../../../../include/c++/13/backward
/usr/lib/gcc-snapshot/lib/gcc/riscv64-linux-gnu/13/include
/usr/local/include
/usr/lib/gcc-snapshot/include
/usr/include/riscv64-linux-gnu
/usr/include
End of search list.
GNU C++17 (Debian 20230108-1) version 13.0.0 20230108 (experimental) [master
r13-5059-gd901bf8a44a] (riscv64-linux-gnu)
compiled by GNU C version 13.0.0 20230108 (experimental) [master
r13-5059-gd901bf8a44a], GMP version 6.2.1, MPFR version 4.1.1-p1,
[Bug middle-end/108545] [13 Regression] ICE in install_var_field, at omp-low.cc:799 since r13-2665-g23baa717c991d77f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108545 --- Comment #4 from Tobias Burnus --- For the C/C++ testcase of comment 3, bisecting points to commit r12-5835-g0ab29cf0bb68960c1f87405f14b4fb2109254e2f "openmp: Improve OpenMP target support for C++ (PR92120)"
[Bug c/108896] provide "element_count" attribute to give more context to __builtin_dynamic_object_size() and -fsanitize=bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #4 from Martin Uecker ---
What could work is using a subset of designator syntax.
struct {
int count;
char data[.count];
};
But I do not think this should be a flexible array member that is simply
ignored except for sizeof but a complete type (maybe with some restrictions).
Then we could also have
struct {
int count;
char (*buf)[.count];
};
which would be incredible useful.
[Bug target/108840] Aarch64 doesn't optimize away shift counter masking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108840 --- Comment #3 from ktkachov at gcc dot gnu.org --- Created attachment 54531 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54531=edit Candidate patch Candidate patch attached.
[Bug demangler/107884] H8/300: cp-demangle.c fix warning related demangle.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107884 --- Comment #8 from Michael N. Moran --- I tried to build with after patching with https://gcc.gnu.org/bugzilla/attachment.cgi?id=53980 and now get an assembler failure. /tmp/cc2C1wMh.s: Assembler messages: /tmp/cc2C1wMh.s:82060: Error: value of 00012570 too large for field of 2 bytes at 0002 I created a corresponding cp-demangle.s file and attached it https://gcc.gnu.org/bugzilla/attachment.cgi?id=54530 The offending line looks like this: .Ldebug_line0: .2byte 0, .LELT0-.LSLT0 << line 82060 .LSLT0: .2byte 0x5
[Bug demangler/107884] H8/300: cp-demangle.c fix warning related demangle.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107884 Michael N. Moran changed: What|Removed |Added CC||mike at mnmoran dot org --- Comment #7 from Michael N. Moran --- Created attachment 54530 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54530=edit Assembler file produced from cp-demangle.c
[Bug sanitizer/108834] LTO: ltrans temporary file is used as module name in ASAN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108834 Martin Liška changed: What|Removed |Added Known to fail||12.2.0 Known to work||13.0 --- Comment #12 from Martin Liška --- Fixed on master so far, I'm going to cherry-pick it at least for gcc-12.
[Bug sanitizer/108834] LTO: ltrans temporary file is used as module name in ASAN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108834 --- Comment #11 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:94c9b1bb79f63d000ebb05efc155c149325e332d commit r13-6330-g94c9b1bb79f63d000ebb05efc155c149325e332d Author: Martin Liska Date: Fri Feb 17 15:11:02 2023 +0100 asan: adjust module name for global variables As mentioned in the PR, when we use LTO, we wrongly use ltrans output file name as a module name of a global variable. That leads to a non-reproducible output. After the suggested change, we emit context name of normal global variables. And for artificial variables (like .Lubsan_data3), we use aux_base_name (e.g. "./a.ltrans0.ltrans"). PR sanitizer/108834 gcc/ChangeLog: * asan.cc (asan_add_global): Use proper TU name for normal global variables (and aux_base_name for the artificial one). gcc/testsuite/ChangeLog: * c-c++-common/asan/global-overflow-1.c: Test line and column info for a global variable.
[Bug middle-end/108545] [13 Regression] ICE in install_var_field, at omp-low.cc:799 since r13-2665-g23baa717c991d77f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108545
--- Comment #3 from Tobias Burnus ---
Fortran: Same issue (ICE) also with:
!$omp target enter data map(to: x)
Crucial is the VOLATILE attribute.
* * *
The following C code already gives an ICE with GCC 12, it works with GCC 11.
(Either of the two lines fail. I think that's invalid OpenMP code, but
I do not have a real overview about 'map' - and I fear no one has.)
volatile struct t {
struct t2 { int *a; int c; } u;
int b;
} my_struct;
volatile struct t3 { int *a; int c; } my_struct3;
void f() {
#pragma omp target enter data map(to:my_struct.u) map(to:my_struct.u.a)
#pragma omp target enter data map(to:my_struct3) map(to:my_struct3.a)
}
[Bug c++/105224] [modules] g++.dg/modules/virt-2_a.C: inline key methods: c++ modules and arm aapcs clash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105224 --- Comment #2 from CVS Commits --- The master branch has been updated by Alexandre Oliva : https://gcc.gnu.org/g:3d1d3ece9bc5a1baa2feb4bf231b709c097b8434 commit r13-6329-g3d1d3ece9bc5a1baa2feb4bf231b709c097b8434 Author: Alexandre Oliva Date: Fri Feb 24 11:31:05 2023 -0300 [PR105224] C++ modules and AAPCS/ARM EABI clash on inline key methods g++.dg/modules/virt-2_a.C fails on arm-eabi and many other arm targets that use the AAPCS variant. ARM is the only target that overrides TARGET_CXX_KEY_METHOD_MAY_BE_INLINE. It's not clear to me which way the clash between AAPCS and C++ Modules design should be resolved, but currently it favors AAPCS and thus the test fails, so skip it on arm_eabi. for gcc/testsuite/ChangeLog PR c++/105224 * g++.dg/modules/virt-2_a.C: Skip on arm_eabi.
[Bug c/107557] [12/13 Regression] ICE -fsanitize=undefined and VLA as argument type to a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107557 --- Comment #7 from Martin Uecker --- Created attachment 54529 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54529=edit new version of patch Here is another patch that does all the recursion in gimplify_type_sizes. Unfortunately, there are regression tests failing for fortran.
[Bug c/63357] Warn for P && P and P || P (same expression used multiple times in a condition)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63357 --- Comment #10 from David Binderman --- (In reply to Manuel López-Ibáñez from comment #9) > Please open a new PR mentioning this one. Done. See 108926.
[Bug c/108926] No warning for same expression in chain of | or & ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108926 --- Comment #1 from David Binderman --- (In reply to David Binderman from comment #0) > This bug is related to 53357. Sorry. 63357.
[Bug c/108926] New: No warning for same expression in chain of | or & ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108926 Bug ID: 108926 Summary: No warning for same expression in chain of | or & ? Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Static analyser cppcheck has the ability to produce a style warning for the same identifier used multiple times in the same expression. Two examples are linux-6.2/drivers/spi/spi-sn-f-ospi.c:614:31: style: Same expression 'SPI_TX_OCTAL' found multiple times in chain of '|' operators. [duplicateExpression] Source code is ctlr->mode_bits = SPI_TX_DUAL | SPI_TX_QUAD | SPI_TX_OCTAL | SPI_RX_DUAL | SPI_RX_QUAD | SPI_TX_OCTAL | SPI_MODE_0 | SPI_MODE_1 | SPI_LSB_FIRST; linux-6.2/tools/testing/selftests/powerpc/pmu/sampling_tests/mmcra_thresh_marked_sample_test.c:68:10: style: Same expression '0x3' found multiple times in chain of '&' operators. [duplicateExpression] If gcc had this ability, then two kernel bugs would be found easily. I will check binutils and glibc. This bug is related to 53357.
[Bug middle-end/108545] [13 Regression] ICE in install_var_field, at omp-low.cc:799 since r13-2665-g23baa717c991d77f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108545 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #2 from Tobias Burnus --- !$omp target enter data map(to: x%a) The original tree has the expected: #pragma omp target enter data map(to:x.a [len: 64]) map(to:*(integer(kind=4)[0:] *) x.a.data [len: D.4282 * 4]) map(always_pointer:(integer(kind=4)[0:] *) x.a.data [pointer assign, bias: 0]) The gimple dump adds a single 'struct': #pragma omp target enter data map(struct:x [len: 1]) map(to:x.a [len: 64]) map(struct:x [len: 1]) map(alloc:x.a.data [len: 8]) map(to:MEM [(integer(kind=4)[0:] *)_6] [len: _5]) map(always_pointer:x.a.data [pointer assign, bias: 0]) The nonindented lines are new in GCC 13 (mainline) compared to GCC 12 and obviously wrong. * * * Observations: * OG12 is not affected but it also does not have the commit r13-2665-g23baa717c991d77f206a9358ce2c04960ccf9eea "struct sibling list gimplification extension and rework" * Except for an added 'always', the dump does not change with my pending patch https://gcc.gnu.org/pipermail/gcc-patches/2023-February/612678.html "Fortran/OpenMP: Fix mapping of array descriptors and deferred-length strings"
[Bug tree-optimization/105329] [12/13 Regression] Bogus restrict warning when assigning 1-char string literal to std::string since r12-3347-g8af8abfbbace49e6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105329
Gustaw Smolarczyk changed:
What|Removed |Added
CC||wielkiegie at gmail dot com
--- Comment #30 from Gustaw Smolarczyk ---
I have encountered a similar bug, reproducer:
#include
std::string foo()
{
return "_" + std::to_string(0);
}
[Bug c++/108920] Condition falsely optimized out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108920 Richard Biener changed: What|Removed |Added Last reconfirmed||2023-02-24 Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 Keywords||wrong-code --- Comment #1 from Richard Biener --- I wonder if you can test a newer GCC release since we are no longer maintaining GCC 9.3. In particular there's also the GCC 9.5 release (the last release from the GCC 9 series), and GCC 10.4, GCC 11.3 and GCC 12.2 (the last releases from the three maintained release series). Is there a way to observe the issue at runtime? That would facilitate bisecting.
[Bug tree-optimization/108916] Miss vectorization for masked gather w/o restrict qualifier.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108916 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-02-24 Status|UNCONFIRMED |NEW --- Comment #3 from Richard Biener --- Should be indeed enough. ISTR the issue is with if-conversion and .MASK_LOAD or .MASK_STORE given that we currently cannot annotate function calls with restrict tags. And yes, I think there's a duplicate bug.
[Bug tree-optimization/108906] Bogus may be used uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108906 Richard Biener changed: What|Removed |Added Last reconfirmed||2023-02-24 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Richard Biener --- We diagnose this from the early diagnostic pass where propagation is limited. At some cost we could improve things here.
[Bug fortran/108925] New: memory leak of gfc_get_namespace result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108925 Bug ID: 108925 Summary: memory leak of gfc_get_namespace result Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- valgrind leak check complains ==8747== 3,976 (2,792 direct, 1,184 indirect) bytes in 1 blocks are definitely lost in loss record 2,248 of 2,309 ==8747==at 0x4C39571: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==8747==by 0x1C25680: xcalloc (xmalloc.c:164) ==8747==by 0x7C998E: gfc_get_namespace(gfc_namespace*, int) (symbol.cc:2869) ==8747==by 0x767D44: load_needed(pointer_info*) (module.cc:5175) ==8747==by 0x767BB5: load_needed(pointer_info*) (module.cc:5153) ==8747==by 0x767BB5: load_needed(pointer_info*) (module.cc:5153) ==8747==by 0x767BB5: load_needed(pointer_info*) (module.cc:5153) ==8747==by 0x767BB5: load_needed(pointer_info*) (module.cc:5153) ==8747==by 0x767BC0: load_needed(pointer_info*) (module.cc:5154) ==8747==by 0x767BC0: load_needed(pointer_info*) (module.cc:5154) ==8747==by 0x767BC0: load_needed(pointer_info*) (module.cc:5154) ==8747==by 0x767BB5: load_needed(pointer_info*) (module.cc:5153)
[Bug fortran/108924] New: memory leak in doloop_warn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108924 Bug ID: 108924 Summary: memory leak in doloop_warn Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- valgrind leak check complains ==8747== 16 bytes in 2 blocks are definitely lost in loss record 6 of 2,309 ==8747==at 0x4C346A4: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==8747==by 0x5697698: __gmp_default_allocate (in /usr/lib64/libgmp.so.10.3.2) ==8747==by 0x56A7A22: __gmpz_init_set (in /usr/lib64/libgmp.so.10.3.2) ==8747==by 0x874110: do_subscript (frontend-passes.cc:2863) ==8747==by 0x874110: do_function(gfc_expr**, int*, void*) (frontend-passes.cc:2710) ==8747==by 0x870675: gfc_expr_walker(gfc_expr**, int (*)(gfc_expr**, int*, void*), void*) (frontend-passes.cc:5243) ==8747==by 0x870859: gfc_expr_walker(gfc_expr**, int (*)(gfc_expr**, int*, void*), void*) (frontend-passes.cc:5250) ==8747==by 0x870859: gfc_expr_walker(gfc_expr**, int (*)(gfc_expr**, int*, void*), void*) (frontend-passes.cc:5250) ==8747==by 0x8727D9: gfc_code_walker(gfc_code**, int (*)(gfc_code**, int*, void*), int (*)(gfc_expr**, int*, void*), void*) (frontend-passes.cc:5680) ==8747==by 0x872857: gfc_code_walker(gfc_code**, int (*)(gfc_code**, int*, void*), int (*)(gfc_expr**, int*, void*), void*) (frontend-passes.cc:5687) ==8747==by 0x872857: gfc_code_walker(gfc_code**, int (*)(gfc_code**, int*, void*), int (*)(gfc_expr**, int*, void*), void*) (frontend-passes.cc:5687) ==8747==by 0x872857: gfc_code_walker(gfc_code**, int (*)(gfc_code**, int*, void*), int (*)(gfc_expr**, int*, void*), void*) (frontend-passes.cc:5687) ==8747==by 0x8738CB: doloop_warn(gfc_namespace*) (frontend-passes.cc:3079) so it looks like some gmp vars are not released.
[Bug fortran/108923] New: memory leak of get_intrinsic_dummy_arg result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108923 Bug ID: 108923 Summary: memory leak of get_intrinsic_dummy_arg result Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- valgrind leak check complains quite often (when building SPEC 2017) like ==8707== 128 bytes in 8 blocks are definitely lost in loss record 750 of 935 ==8707==at 0x4C39571: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==8707==by 0x1C25680: xcalloc (xmalloc.c:164) ==8707==by 0x73C891: get_intrinsic_dummy_arg (intrinsic.cc:4265) ==8707==by 0x73C891: sort_actual(char const*, gfc_actual_arglist**, gfc_intrinsic_arg*, locus*) (intrinsic.cc:4433) ==8707==by 0x73CD54: check_specific(gfc_intrinsic_sym*, gfc_expr*, int) (intrinsic.cc:4774) ==8707==by 0x744F21: gfc_intrinsic_func_interface(gfc_expr*, int) (intrinsic.cc:5032) ==8707==by 0x79BD57: resolve_unknown_f (resolve.cc:2998) ==8707==by 0x79BD57: resolve_function (resolve.cc:3355) ==8707==by 0x79BD57: gfc_resolve_expr(gfc_expr*) [clone .part.56] (resolve.cc:7204) ==8707==by 0x79D469: gfc_resolve_expr (resolve.cc:7171) ==8707==by 0x79D469: resolve_operator(gfc_expr*) (resolve.cc:4101) ==8707==by 0x79990F: gfc_resolve_expr(gfc_expr*) [clone .part.56] (resolve.cc:7197) ==8707==by 0x7A2274: gfc_resolve_expr (resolve.cc:11893) ==8707==by 0x7A2274: gfc_resolve_code(gfc_code*, gfc_namespace*) (resolve.cc:12004) ==8707==by 0x7A0D4F: gfc_resolve_blocks(gfc_code*, gfc_namespace*) (resolve.cc:10989) ==8707==by 0x7A10A8: gfc_resolve_code(gfc_code*, gfc_namespace*) (resolve.cc:11990) ==8707==by 0x7A0D4F: gfc_resolve_blocks(gfc_code*, gfc_namespace*) (resolve.cc:10989)
[Bug ipa/108695] [13 Regression] Wrong code since r13-5215-gb1f30bf42d8d47 for dd_rescue package
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108695 --- Comment #18 from Kurt Garloff --- dd_rescue-1.99.13 has been released including the fix to XORN. (Fix uses uint* casts rather than uchar*.)
[Bug target/108922] New: fmod() 13x slowdown in gcc 4.8->4.9 dropping "fprem" and calling fmod()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
Bug ID: 108922
Summary: fmod() 13x slowdown in gcc 4.8->4.9 dropping "fprem"
and calling fmod()
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jkratochvil at azul dot com
Target Milestone: ---
Created attachment 54528
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54528=edit
bench.cpp
This performance regression is since:
[PATCH, i386]: Enable reminder{sd,df,xf} and fmod{sf,df,xf} only for
flag_finite_math_only.
https://gcc.gnu.org/pipermail/gcc-patches/2014-September/400104.html
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=93ba85fdd253b4b9cf2b9e54e8e5969b1a3db098
Reproducible with attached "bench.cpp":
g++ (GCC) 4.8.3 20140517 (prerelease)
real0m0.329s
g++ (GCC) 4.9.3 20150207 (prerelease)
real0m4.396s
The committer claims "do not return NaN for infinities, but generate
invalid-arithmetic-operand exception.". But my attached testcase tests that all
the corner cases do have both the same result value and the same exceptions
generated.
The committer also claims "fixes ieee_2.f90 testsuite failure" but I have no
idea where to find this testsuite.
g++ (GCC) 4.4.7 20120313 (Red Hat 4.4.7-18)
/home/azul/t/zuc1182/fmod.C:7
4005f8: dd 44 24 30 fldl 0x30(%rsp)
4005fc: dd 44 24 38 fldl 0x38(%rsp)
400600: d9 c1 fld%st(1)
400602: d9 c1 fld%st(1)
400604: d9 f8 fprem
400606: df e0 fnstsw %ax
400608: f6 c4 04test $0x4,%ah
40060b: 75 f7 jne400604
40060d: dd d9 fstp %st(1)
40060f: dd 5c 24 18 fstpl 0x18(%rsp)
400613: f2 0f 10 44 24 18 movsd 0x18(%rsp),%xmm0
400619: 66 0f 2e c0 ucomisd %xmm0,%xmm0
^^^
Here it tests the result is finite;
if it is not it will fallback to calling fmod().
But I do not find even that needed, one could just use the "fprem" result.
40061d: 7a 06 jp 400625
40061f: 74 2f je 400650
400621: d9 c9 fxch %st(1)
400623: eb 0b jmp400630
400625: d9 c9 fxch %st(1)
400627: 66 0f 1f 84 00 00 00nopw 0x0(%rax,%rax,1)
40062e: 00 00
400630: dd 5c 24 08 fstpl 0x8(%rsp)
400634: f2 0f 10 4c 24 08 movsd 0x8(%rsp),%xmm1
40063a: dd 5c 24 08 fstpl 0x8(%rsp)
40063e: f2 0f 10 44 24 08 movsd 0x8(%rsp),%xmm0
400644: e8 6f fe ff ff callq 4004b8
400649: eb 09 jmp400654
40064b: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
400650: dd d8 fstp %st(0)
400652: dd d8 fstp %st(0)
400654: 83 c3 01add$0x1,%ebx
400657: f2 0f 11 44 24 28 movsd %xmm0,0x28(%rsp)
/home/azul/t/zuc1182/fmod.C:6
40065d: 81 fb 00 e1 f5 05 cmp$0x5f5e100,%ebx
400663: 75 93 jne4005f8
Similar issue may be with drem() (=remainder()) vs. "fprem1" instruction.
I expect the same issue also affects fmodf(), dremf() and remainderf().
Another topic is why the glibc fmod() implementation just does not use "fprem"
on i686/x86_64 arch.
[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977 --- Comment #26 from ibuclaw at gcc dot gnu.org --- Comparing the D and C++ trees side by side. At the point of `finish_function` for the ::vis() method, I see the following: D: type
[Bug c/63357] Warn for P && P and P || P (same expression used multiple times in a condition)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63357 --- Comment #9 from Manuel López-Ibáñez --- (In reply to David Binderman from comment #8) > This could probably be extended to other operators. Please open a new PR mentioning this one.
[Bug fortran/108921] New: ICE: using the result of an impure function in automatic character allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108921 Bug ID: 108921 Summary: ICE: using the result of an impure function in automatic character allocation Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: vterzi1996 at gmail dot com Target Milestone: --- Created attachment 54527 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54527=edit Complete backtrace Consider the following minimal working example: ``` module lib type t contains procedure::f,g end type contains integer function f(this) class(t),intent(in)::this f=10 end function g(this)result(r) class(t),intent(in)::this character(len=this%f())::r ! problem appears here r='42' end end program prog use lib type(t)::o print*,o%g() end ``` This example was already discussed here: https://stackoverflow.com/questions/75544072/using-function-result-as-character-length-in-fortran The compilation of this code with the GNU compiler (gfortran 12.2.0 on Rocky Linux 8.7) fails with the message `f951: internal compiler error: Segmentation fault` (full output is in the attachment). It also fails with 7.5.0, 9.4.0, and 11.1.0 on Ubuntu 18.04.2 LTS. The reason for this problem is the unallowed usage of the result of an impure function (here: `f`) in the automatic allocation of the CHARACTER variable, but the compiler fails to identify the mistake in the code.
[Bug tree-optimization/107409] Perf loss ~5% on 519.lbm_r SPEC cpu2017 benchmark with r10-5090-ga9a4edf0e71bba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107409 --- Comment #21 from Rama Malladi --- I did another triage for perf loss on Graviton 2 processor (neoverse-n1) based instance and found this commit: `a9a4edf0e71bbac9f1b5dcecdcf9250111d16889` to be the reason. As I had indicated in my earlier reply, I was doing a triage of perf loss going from gcc-7 to gcc-10. The perf of 519.libm_r 1-copy run improved 1.08x with the revert of commit: `a9a4edf0e71bbac9f1b5dcecdcf9250111d16889` on gcc-mainline ( `2f1691be517fcdcabae9cd671ab511eb0e08b1d5`). I am guessing that we don't see it on LNT/ Altra CPUs. So, please look into this issue fix. Let me know if you have any queries. Thanks.
[Bug c++/108920] New: Condition falsely optimized out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108920 Bug ID: 108920 Summary: Condition falsely optimized out Product: gcc Version: 9.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: agner at agner dot org Target Milestone: --- Created attachment 54526 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54526=edit code to reproduce error The attached file test.cpp gives wrong code when optimized with -O2 or higher. To reproduce error, do: g++ -O2 -m64 -S -o t1.s test.cpp g++ -O2 -m64 -S -DFIX -o t2.s test.cpp The condition in line 104 in test.cpp is optimized away in t1.s The workaround on line 73 is preventing this false optimization with -DFIX to generate correct code in t2.s See t2.s line 252-255
[Bug middle-end/108854] [10/11/12 Regression] tbb-2021.8.0 fails on i686-linux (32-bit), internal compiler error: in expand_expr_real_1, at expr.c:10281 since r10-4511-g6cf67b62c8cda035dccac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108854 Jakub Jelinek changed: What|Removed |Added Summary|[10/11/12/13 Regression]|[10/11/12 Regression] |tbb-2021.8.0 fails on |tbb-2021.8.0 fails on |i686-linux (32-bit),|i686-linux (32-bit), |internal compiler error: in |internal compiler error: in |expand_expr_real_1, at |expand_expr_real_1, at |expr.c:10281 since |expr.c:10281 since |r10-4511-g6cf67b62c8cda035d |r10-4511-g6cf67b62c8cda035d |ccac|ccac --- Comment #14 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug middle-end/108854] [10/11/12/13 Regression] tbb-2021.8.0 fails on i686-linux (32-bit), internal compiler error: in expand_expr_real_1, at expr.c:10281 since r10-4511-g6cf67b62c8cda035dccac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108854 --- Comment #13 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:2f1691be517fcdcabae9cd671ab511eb0e08b1d5 commit r13-6319-g2f1691be517fcdcabae9cd671ab511eb0e08b1d5 Author: Jakub Jelinek Date: Fri Feb 24 11:05:27 2023 +0100 cgraphclones: Don't share DECL_ARGUMENTS between thunk and its artificial thunk [PR108854] The following testcase ICEs on x86_64-linux with -m32. The problem is we create an artificial thunk and because of -fPIC, ia32 and thunk destination which doesn't bind locally can't use a mi thunk. The ICE is because during expansion to RTL we see SSA_NAME for a PARM_DECL, but the PARM_DECL doesn't have DECL_CONTEXT of the current function. This is because duplicate_thunk_for_node creates a new DECL_ARGUMENTS chain only if some arguments need modification. The following patch fixes it by copying the DECL_ARGUMENTS list even if the arguments can stay as is, to update DECL_CONTEXT on them. While for mi thunks it doesn't really matter because we don't use those arguments in any way, for other thunks it is important. 2023-02-23 Jakub Jelinek PR middle-end/108854 * cgraphclones.cc (duplicate_thunk_for_node): If no parameter changes are needed, copy at least DECL_ARGUMENTS PARM_DECL nodes and adjust their DECL_CONTEXT. * g++.dg/opt/pr108854.C: New test.
[Bug target/108881] "__builtin_ia32_cvtne2ps2bf16_v16hi" compiled only with option -mavx512bf16 report ICE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108881 --- Comment #6 from Jakub Jelinek --- Fixed on the trunk so far. I think we want to backport to 10/11/12, though in that case it won't be v*bf but v*hi.
[Bug target/108881] "__builtin_ia32_cvtne2ps2bf16_v16hi" compiled only with option -mavx512bf16 report ICE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108881 --- Comment #5 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:0ccfa3884f638816af0f5a3f0ee2695e0771ef6d commit r13-6318-g0ccfa3884f638816af0f5a3f0ee2695e0771ef6d Author: Jakub Jelinek Date: Fri Feb 24 10:12:44 2023 +0100 i386: Fix up builtins used in avx512bf16vlintrin.h [PR108881] The builtins used in avx512bf16vlintrin.h implementation need both avx512bf16 and avx512vl ISAs, which the header ensures for them, but the builtins weren't actually requiring avx512vl, so when used by hand with just -mavx512bf16 -mno-avx512vl it resulted in ICEs. Fixed by adding OPTION_MASK_ISA_AVX512VL to their BDESC. 2023-02-24 Jakub Jelinek PR target/108881 * config/i386/i386-builtin.def (__builtin_ia32_cvtne2ps2bf16_v16bf, __builtin_ia32_cvtne2ps2bf16_v16bf_mask, __builtin_ia32_cvtne2ps2bf16_v16bf_maskz, __builtin_ia32_cvtne2ps2bf16_v8bf, __builtin_ia32_cvtne2ps2bf16_v8bf_mask, __builtin_ia32_cvtne2ps2bf16_v8bf_maskz, __builtin_ia32_cvtneps2bf16_v8sf_mask, __builtin_ia32_cvtneps2bf16_v8sf_maskz, __builtin_ia32_cvtneps2bf16_v4sf_mask, __builtin_ia32_cvtneps2bf16_v4sf_maskz, __builtin_ia32_dpbf16ps_v8sf, __builtin_ia32_dpbf16ps_v8sf_mask, __builtin_ia32_dpbf16ps_v8sf_maskz, __builtin_ia32_dpbf16ps_v4sf, __builtin_ia32_dpbf16ps_v4sf_mask, __builtin_ia32_dpbf16ps_v4sf_maskz): Require also OPTION_MASK_ISA_AVX512VL. * gcc.target/i386/avx512bf16-pr108881.c: New test.
[Bug c/63357] Warn for P && P and P || P (same expression used multiple times in a condition)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63357 David Binderman changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #8 from David Binderman --- This could probably be extended to other operators. Static analyser cppcheck can be made to say things like: linux-6.2/drivers/spi/spi-sn-f-ospi.c:614:31: style: Same expression 'SPI_TX_OCTAL' found multiple times in chain of '|' operators. [duplicateExpression] Source code is ctlr->mode_bits = SPI_TX_DUAL | SPI_TX_QUAD | SPI_TX_OCTAL | SPI_RX_DUAL | SPI_RX_QUAD | SPI_TX_OCTAL | SPI_MODE_0 | SPI_MODE_1 | SPI_LSB_FIRST; If |, then probably also &.
[Bug target/108919] New: pure nested function may clobber its static chain pointer in windowed ABI on xtensa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108919 Bug ID: 108919 Summary: pure nested function may clobber its static chain pointer in windowed ABI on xtensa Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jcmvbkbc at gcc dot gnu.org Target Milestone: --- Created attachment 54525 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54525=edit test.c The following gfortran tests fail on windowed ABI xtensa target, but pass on call0 ABI: gfortran.dg/character_workout_1.f90 -O[123s] execution test gfortran.dg/character_workout_4.f90 -O[123s] execution test E.g. gfortran.dg/character_workout_1.f90 -O1 ends with the message 'STOP 209'. This happens because in these tests pure nested functions are generated for subroutines achar_cm and achar_am and the fwprop1 pass removes static chain pointer initialization between the calls to these functions: .L143: addia3, sp, 108 movia4, 0xd4 add.n a4, sp, a4 addia8, sp, -20 s32i.n a4, a8, 0 movi.n a11, 7 mov.n a10, a3 call8 achar_cm.21 movi.n a11, 7 mov.n a10, a3 call8 achar_am.15 Windowed ABI for xtensa specifies that the static chain is passed on the stack, at offset -20 from the called function's CFA, i.e. outside the caller's stack frame. This location may be overwritten if the called function makes function calls that exceed certain depth. The issue may be reproduced with the attached small test case.
[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977 --- Comment #25 from Iain Sandoe --- (In reply to ibuclaw from comment #24) > (In reply to Iain Sandoe from comment #23) > > So the ABIs differ in this (as noted on IRC, the Darwin 32b ABIs are not the > > same as Linux). > I'm still yet to work out why D on 32-bit Darwin behaves the same as 32-bit > Linux though. I would have assumed the decision to generate an sret would > occur long after the front-end has freed itself from the compilation process. there should be some target hook to query whether a struct returns in regs. > Regardless, the ABI issue can be raised in a separate PR. Because of it > though, that means for this bootstrap PR we just have to avoid calling any > extern(C++) method implemented in D that returns a struct by value. Note that this would affect any interface to libc or external C++ that returns a small struct. AFAIR, X86 Darwin is not the only platform that returns small structs in regs.
[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977 --- Comment #24 from ibuclaw at gcc dot gnu.org --- (In reply to Iain Sandoe from comment #23) > So the ABIs differ in this (as noted on IRC, the Darwin 32b ABIs are not the > same as Linux). I'm still yet to work out why D on 32-bit Darwin behaves the same as 32-bit Linux though. I would have assumed the decision to generate an sret would occur long after the front-end has freed itself from the compilation process. Regardless, the ABI issue can be raised in a separate PR. Because of it though, that means for this bootstrap PR we just have to avoid calling any extern(C++) method implemented in D that returns a struct by value.
