[Bug tree-optimization/100787] [12 Regression] Bootstrap failure caused by r12-1077
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100787 --- Comment #11 from Aldy Hernandez --- Note, this is still broken so I am leaving the PR open. I will address this next week.
[Bug libstdc++/100823] New: Special member functions of common_iterator should be conditionally trivial
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100823 Bug ID: 100823 Summary: Special member functions of common_iterator should be conditionally trivial Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: rs2740 at gmail dot com Target Milestone: --- At least as a QoI matter, the special member functions of common_iterator should be trivial when the corresponding special member function of variant is. Given that the standard depicts a variant exposition-only member with implicitly declared special member functions, it is arguable that this is actually required. There appears to be a couple other conformance issues too: - the move special members are missing - the copy assignment calls the converting assignment operator, but unlike the latter, there's no !valueless_by_exception() precondition on the (implicitly declared) copy assignment.
[Bug tree-optimization/100787] [12 Regression] Bootstrap failure caused by r12-1077
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100787 --- Comment #10 from CVS Commits --- The master branch has been updated by Aldy Hernandez : https://gcc.gnu.org/g:2364b584552208ce715fa4fd44c510b7e5210d1e commit r12-1118-g2364b584552208ce715fa4fd44c510b7e5210d1e Author: Aldy Hernandez Date: Fri May 28 22:17:51 2021 +0200 Fix i686 bootstrap by temporarily disabling exporting of global ranges. The patch converting evrp to the get_range_query(fun) API broke i686 bootstrap (commit 57bf37515). The problem seems to be in a subsequent pass that has more up-to-date global ranges. I won't be able to look at this until next week, so I am reverting the problematic bit of the patch-- the exporting of global ranges once evrp finishes. The use of the new API remains. Reverting the behavior shouldn't be a problem as we never used to export global ranges from ranger. This was new behavior in the patchset. Tested on x86-64 Linux with a bootstrap and regtest, and on x86-32 with only a bootstrap and the configure flags from the PR: --enable-clocale=gnu --with-system-zlib --with-demangler-in-ld --with-fpmath=sse --enable-languages=c,c++ --enable-cet i686-linux --enable-bootstrap --with-fpmath=sse --disable-libcc1 --disable-libcilkrts --disable-libsanitizer gcc/ChangeLog: PR tree-optimization/100787 * gimple-ssa-evrp.c: Disable exporting of global ranges. gcc/testsuite/ChangeLog: * gcc.dg/Wstringop-overflow-55.c: * gcc.dg/pr80776-1.c:
[Bug libgomp/100747] Possibly Wrong Permissions in "liboffloadmic"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100747 --- Comment #6 from Firas Khalil Khana --- Thanks for your time.
[Bug c++/100822] New: new expression for an array of function pointers gets parsed as lambda incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100822
Bug ID: 100822
Summary: new expression for an array of function pointers gets
parsed as lambda incorrectly
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lfppgg at supersave dot net
Target Milestone: ---
Created attachment 50888
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50888=edit
preprocessed source
$ gcc -v -save-temps main.cpp
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --with-isl
--with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit
--enable-cet=auto --enable-checking=release --enable-clocale=gnu
--enable-default-pie --enable-default-ssp --enable-gnu-indirect-function
--enable-gnu-unique-object --enable-install-libiberty --enable-linker-build-id
--enable-lto --enable-multilib --enable-plugin --enable-shared
--enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-libunwind-exceptions --disable-werror
gdc_include_dir=/usr/include/dlang/gdc
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.1.0 (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-mtune=generic' '-march=x86-64'
'-dumpdir' 'a-'
/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/cc1plus -E -quiet -v -D_GNU_SOURCE
main.cpp -mtune=generic -march=x86-64 -fpch-preprocess -o a-main.ii
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../include/c++/11.1.0
/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../include/c++/11.1.0/x86_64-pc-linux-gnu
/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../include/c++/11.1.0/backward
/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/include
/usr/local/include
/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/include-fixed
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-mtune=generic' '-march=x86-64'
'-dumpdir' 'a-'
/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/cc1plus -fpreprocessed a-main.ii
-quiet -dumpdir a- -dumpbase main.cpp -dumpbase-ext .cpp -mtune=generic
-march=x86-64 -version -o a-main.s
GNU C++17 (GCC) version 11.1.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 11.1.0, GMP version 6.2.1, MPFR version
4.1.0, MPC version 1.2.1, isl version isl-0.24-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++17 (GCC) version 11.1.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 11.1.0, GMP version 6.2.1, MPFR version
4.1.0, MPC version 1.2.1, isl version isl-0.24-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 45eb9a71cc15bfdc579557bea4b77e51
main.cpp: In function ‘int main()’:
main.cpp:5:23: warning: capture of variable ‘N’ with non-automatic storage
duration
5 | f = new (double(*[N])(double, double*));
| ^
main.cpp:1:15: note: ‘constexpr const int N’ declared here
1 | constexpr int N = 10;
| ^
main.cpp: In lambda function:
main.cpp:5:25: error: expected ‘{’ before ‘)’ token
5 | f = new (double(*[N])(double, double*));
| ^
main.cpp: In function ‘int main()’:
main.cpp:5:14: error: invalid cast from type ‘void (*)()’ to type ‘double’
5 | f = new (double(*[N])(double, double*));
| ^~~~
main.cpp:5:20: error: expected ‘)’ before ‘(’ token
5 | f = new (double(*[N])(double, double*));
| ~ ^
|)
main.cpp:5:22: error: cannot convert ‘void (*)()’ to ‘double’ in initialization
5 | f = new (double(*[N])(double, double*));
| ^
| |
| void (*)()
If you replace N with integer literal, the code compiles without errors.
Therefore I suppose it might be a bug.
[Bug tree-optimization/100787] [12 Regression] Bootstrap failure caused by r12-1077
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100787 --- Comment #9 from Aldy Hernandez --- This temporary fix resolves the bootstrap comparison on i686. Does it also fix it on sparc-32? diff --git a/gcc/gimple-ssa-evrp.c b/gcc/gimple-ssa-evrp.c index 118d10365a0..b40649b6a10 100644 --- a/gcc/gimple-ssa-evrp.c +++ b/gcc/gimple-ssa-evrp.c @@ -127,7 +127,7 @@ public: if (dump_file && (dump_flags & TDF_DETAILS)) m_ranger->dump (dump_file); -m_ranger->export_global_ranges (); +//m_ranger->export_global_ranges (); disable_ranger (cfun); } @@ -193,7 +193,7 @@ public: if (dump_file && (dump_flags & TDF_DETAILS)) m_ranger->dump (dump_file); -m_ranger->export_global_ranges (); +//m_ranger->export_global_ranges (); disable_ranger (cfun); }
[Bug target/94177] TLS global-dynamic model clobbers function parameter on AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94177 --- Comment #4 from CVS Commits --- The releases/gcc-11 branch has been updated by David Edelsohn : https://gcc.gnu.org/g:0be51abf080f1d7515e3777dd5e5a983b47573a8 commit r11-8481-g0be51abf080f1d7515e3777dd5e5a983b47573a8 Author: David Edelsohn Date: Fri Apr 30 14:27:46 2021 -0400 aix: TLS precompute register parameters (PR 94177) AIX uses a compiler-managed TOC for global data, including TLS symbols. The GCC TOC implementation manages the TOC entries through the constant pool. TLS symbols sometimes require a function call to obtain the TLS base pointer. The arguments to the TLS call can conflict with arguments to a normal function call if the TLS symbol is an argument in the normal call. GCC specifically checks for this situation and precomputes the TLS arguments, but the mechanism to check for this requirement utilizes legitimate_constant_p(). The necessary result of legitimate_constant_p() for correct TOC behavior and for correct TLS argument behavior is in conflict. This patch adds a new target hook precompute_tls_p() to decide if an argument should be precomputed regardless of the result from legitmate_constant_p(). gcc/ChangeLog: PR target/94177 * calls.c (precompute_register_parameters): Additionally test targetm.precompute_tls_p to pre-compute argument. * config/rs6000/aix.h (TARGET_PRECOMPUTE_TLS_P): Define. * config/rs6000/rs6000.c (rs6000_aix_precompute_tls_p): New. * target.def (precompute_tls_p): New. * doc/tm.texi.in (TARGET_PRECOMPUTE_TLS_P): Add hook documentation. * doc/tm.texi: Regenerated. (cherry-picked from commit a21b399708175f6fc0ac723a0cebc127da421c60)
[Bug tree-optimization/100817] ICE with -O2: in compute_antic, at tree-ssa-pre.c:2513
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100817 --- Comment #1 from Andrew Pinski --- /* Theoretically possible, but *highly* unlikely. */ gcc_checking_assert (num_iterations < 500);
[Bug target/100820] [12 regression] bootstrap hangs during stage2 on power 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100820 Andrew Pinski changed: What|Removed |Added Keywords||build, compile-time-hog Component|bootstrap |target Target Milestone|--- |12.0
[Bug fortran/100821] New: Deferred character with wrong bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100821 Bug ID: 100821 Summary: Deferred character with wrong bounds Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gcc dot gnu.org Target Milestone: --- Created attachment 50887 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50887=edit Fortran code showing problem Hi All! Due to the way deferred character length is implemented, using SAVE_EXPR, it will usually contain garbage. Seen on: GNU Fortran (GCC) 9.3.1 20210526 GNU Fortran (GCC) 10.3.1 20210526 GNU Fortran (GCC) 11.1.1 20210526 GNU Fortran (GCC) 12.0.0 20210527 (experimental) Thank you very much. Best regards, José Rui
[Bug bootstrap/100820] New: [12 regression] bootstrap hangs during stage2 on power 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100820 Bug ID: 100820 Summary: [12 regression] bootstrap hangs during stage2 on power 10 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:a8764071f2eb6b4cdc9ecb788dfaa2b095b52598, r12-1020 Author: Aaron Sawdey Date: Tue Mar 2 18:06:37 2021 -0600 Fusion patterns for add-logical/logical-add This is causing a hang during stage2 of bootstrapping for trunk on power 10. I tried r12-1019 and it was fine. Here is one example that happens when configure is running: . . . checking for powerpc64le-unknown-linux-gnu-gfortran... /home/seurer/gcc/git/build/gcc-trunk-bootstrap/./gcc/gfortran -B/home/seurer/gcc/git/build/gcc-trunk-bootstrap/./gcc/ -B/home/seurer/gcc/git/install/gcc-trunk-bootstrap/powerpc64le-unknown-linux-gnu/bin/ -B/home/seurer/gcc/git/install/gcc-trunk-bootstrap/powerpc64le-unknown-linux-gnu/lib/ -isystem /home/seurer/gcc/git/install/gcc-trunk-bootstrap/powerpc64le-unknown-linux-gnu/include -isystem /home/seurer/gcc/git/install/gcc-trunk-bootstrap/powerpc64le-unknown-linux-gnu/sys-include -fno-checking checking whether we are using the GNU Fortran compiler... (and here it hangs) 3912958 pts/0R+ 2:12 /home/seurer/gcc/git/build/gcc-trunk-bootstrap/./gcc/f951 conftest.F -ffixed-form -cpp=/tmp/cc5vO5dZ.f90 -quiet -iprefix /home/seurer/gcc/git/build/gcc-trunk-bootstrap/gcc/../lib/gcc/powerpc64le-unknown-linux-gnu/12.0.0/ -isystem /home/seurer/gcc/git/build/gcc-trunk-bootstrap/./gcc/include -isystem /home/seurer/gcc/git/build/gcc-trunk-bootstrap/./gcc/include-fixed -isystem /home/seurer/gcc/git/install/gcc-trunk-bootstrap/powerpc64le-unknown-linux-gnu/include -isystem /home/seurer/gcc/git/install/gcc-trunk-bootstrap/powerpc64le-unknown-linux-gnu/sys-include conftest.F -quiet -dumpbase conftest.F -dumpbase-ext .F -mcpu=power10 -fno-checking -fintrinsic-modules-path finclude -fpre-include=/usr/include/finclude/math-vector-fortran.h -o /tmp/cc6Kgdbr.s This should finish almost instantly but never does. seurer@ltcden2-lp1:~/gcc/git/build/gcc-trunk-bootstrap$ cat ./powerpc64le-unknown-linux-gnu/libgomp/conftest.F program main #ifndef __GNUC__ choke me #endif end
[Bug fortran/100819] New: Wrong code generation with unlimited polymorphic objects and character type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100819 Bug ID: 100819 Summary: Wrong code generation with unlimited polymorphic objects and character type Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gcc dot gnu.org Target Milestone: --- Created attachment 50886 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50886=edit Fortran code showing problem Hi All! Mostly improperly set "_len", "elem_len" or "span". Seen on: GNU Fortran (GCC) 11.1.1 20210526 GNU Fortran (GCC) 12.0.0 20210527 (experimental) ICEs on: GNU Fortran (GCC) 9.3.1 20210526 GNU Fortran (GCC) 10.3.1 20210526 Thank you very much. Best regards, José Rui
[Bug testsuite/100749] [12 regression] gcc.dg/pch/valid-1.c fails after r12-949
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100749 --- Comment #2 from Indu Bhagat --- I found the issue. I will send a fix soon, once testing on powerpc64, x86_64 finishes.
[Bug fortran/98411] [10/11] Pointless: Array larger than ‘-fmax-stack-var-size=’, moved from stack to static storage for main program variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98411 --- Comment #11 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:799cf16051844f80d09526f17194373902254708 commit r10-9871-g799cf16051844f80d09526f17194373902254708 Author: Harald Anlauf Date: Mon May 17 21:35:38 2021 +0200 PR fortran/98411 - Pointless warning for static variables Variables with explicit SAVE attribute cannot end up on the stack. There is no point in checking whether they should be moved off the stack to static storage. gcc/fortran/ChangeLog: PR fortran/98411 * trans-decl.c (gfc_finish_var_decl): Add check for explicit SAVE attribute. gcc/testsuite/ChangeLog: PR fortran/98411 * gfortran.dg/pr98411.f90: New test. (cherry picked from commit 09867aa0ef7568012650395189b735f9a34cf9b5)
[Bug fortran/100656] ICE in gfc_conv_expr_present, at fortran/trans-expr.c:1934
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100656 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-12, and on 11-branch. Since this is not a regression, not backporting further for now, although this would be possible. Thanks for the report!
[Bug fortran/100602] [11/12 Regression] Erroneous "pointer argument is not associated" runtime error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100602 anlauf at gcc dot gnu.org changed: What|Removed |Added Keywords|rejects-valid |wrong-code Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-12 and on 11-branch. Closing. Thanks for the report!
[Bug fortran/98411] [10/11] Pointless: Array larger than ‘-fmax-stack-var-size=’, moved from stack to static storage for main program variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98411 --- Comment #10 from CVS Commits --- The releases/gcc-11 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:1e9e0798d2242b7908db4098136d0bfd0bc7f0e8 commit r11-8480-g1e9e0798d2242b7908db4098136d0bfd0bc7f0e8 Author: Harald Anlauf Date: Mon May 17 21:35:38 2021 +0200 PR fortran/98411 - Pointless warning for static variables Variables with explicit SAVE attribute cannot end up on the stack. There is no point in checking whether they should be moved off the stack to static storage. gcc/fortran/ChangeLog: PR fortran/98411 * trans-decl.c (gfc_finish_var_decl): Add check for explicit SAVE attribute. gcc/testsuite/ChangeLog: PR fortran/98411 * gfortran.dg/pr98411.f90: New test. (cherry picked from commit 09867aa0ef7568012650395189b735f9a34cf9b5)
[Bug fortran/100656] ICE in gfc_conv_expr_present, at fortran/trans-expr.c:1934
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100656 --- Comment #6 from CVS Commits --- The releases/gcc-11 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:1cb4a0db82c51c742961a350c9c7a45ba1fe8475 commit r11-8479-g1cb4a0db82c51c742961a350c9c7a45ba1fe8475 Author: Harald Anlauf Date: Thu May 27 13:55:11 2021 +0200 PR fortran/100656 - prevent ICE in gfc_conv_expr_present gcc/fortran/ChangeLog: PR fortran/100656 * trans-array.c (gfc_conv_ss_startstride): Do not call check for presence of a dummy argument when a symbol actually refers to a non-dummy. gcc/testsuite/ChangeLog: PR fortran/100656 * gfortran.dg/bounds_check_22.f90: New test. (cherry picked from commit 9d3a953ec4d2695e9a6bfa5f22655e2aea47a973)
[Bug libstdc++/100806] deadlock in std::counting_semaphore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100806 Thomas Rodgers changed: What|Removed |Added Last reconfirmed||2021-05-28 Assignee|unassigned at gcc dot gnu.org |rodgertq at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #1 from Thomas Rodgers --- This is almost certainly a duplicate of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100334 Which is fixed on master with a backport to releases/gcc-11 but was broken in GCC 11.1 Will confirm, thanks!
[Bug fortran/100602] [11/12 Regression] Erroneous "pointer argument is not associated" runtime error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100602 --- Comment #5 from CVS Commits --- The releases/gcc-11 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:cb5c89afbe0ef59fa315cbfda31a55ea5d8ca297 commit r11-8478-gcb5c89afbe0ef59fa315cbfda31a55ea5d8ca297 Author: Harald Anlauf Date: Thu May 27 13:58:26 2021 +0200 Fortran: Fix erroneous "pointer argument is not associated" runtime error For CLASS arrays we need to use the CLASS data attributes to determine which runtime check to generate. gcc/fortran/ChangeLog: PR fortran/100602 * trans-intrinsic.c (gfc_conv_intrinsic_size): Use CLASS data attributes for CLASS arrays for generation of runtime error. gcc/testsuite/ChangeLog: PR fortran/100602 * gfortran.dg/pointer_check_14.f90: New test. (cherry picked from commit 71d7dc6cd09b603bcc58d5d1747a86eb498bb147)
[Bug tree-optimization/100787] [12 Regression] Bootstrap failure caused by r12-1077
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100787 --- Comment #7 from Jakub Jelinek --- Perhaps if EVRP is folding debug stmts it could first fold non-debug stmts (and remember if there were any debug stmts) and only fold debug stmts afterwards, either just by using caches and not adding anything to them (if they survive to later passes), or just to make sure that the debug stmts don't affect non-debug folding. --- Comment #8 from Aldy Hernandez --- I'll work on it this weekend. If there's no patch by Monday morning, we can revert the patch while I find a solution. On Fri, May 28, 2021, 19:49 ro at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100787 > > Rainer Orth changed: > >What|Removed |Added > > > Target|i686|i686, sparc > CC||ro at gcc dot gnu.org > > --- Comment #6 from Rainer Orth --- > It also affects 32-bit sparc (sparc-sun-solaris2.11), maybe other 32-bit > targets, too? Unless a quick fix is coming forward, I suspect it would be > better > to revert the patch instead of keeping bootstrap broken for days. > > -- > You are receiving this mail because: > You are the assignee for the bug. > You are on the CC list for the bug. > >
[Bug tree-optimization/100787] [12 Regression] Bootstrap failure caused by r12-1077
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100787 --- Comment #7 from Jakub Jelinek --- Perhaps if EVRP is folding debug stmts it could first fold non-debug stmts (and remember if there were any debug stmts) and only fold debug stmts afterwards, either just by using caches and not adding anything to them (if they survive to later passes), or just to make sure that the debug stmts don't affect non-debug folding.
[Bug fortran/100120] associated intrinsic failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100120 --- Comment #3 from José Rui Faustino de Sousa --- Please ignore anterior patch as it contains really bad errors a corrected one will follow shortly.
[Bug tree-optimization/100787] [12 Regression] Bootstrap failure caused by r12-1077
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100787 Rainer Orth changed: What|Removed |Added Target|i686|i686, sparc CC||ro at gcc dot gnu.org --- Comment #6 from Rainer Orth --- It also affects 32-bit sparc (sparc-sun-solaris2.11), maybe other 32-bit targets, too? Unless a quick fix is coming forward, I suspect it would be better to revert the patch instead of keeping bootstrap broken for days.
[Bug fortran/100818] New: A temporary is passed to associated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100818 Bug ID: 100818 Summary: A temporary is passed to associated Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gcc dot gnu.org Target Milestone: --- Created attachment 50885 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50885=edit Fortran code showing problem Hi All! The code generates a temporary to pass to associated... Seen on: GNU Fortran (GCC) 9.3.1 20210526 GNU Fortran (GCC) 10.3.1 20210526 GNU Fortran (GCC) 11.1.1 20210526 GNU Fortran (GCC) 12.0.0 20210527 (experimental) Thank you very much. Best regards, José Rui
[Bug middle-end/100734] [12 Regression] /test/gnu/gcc/objdir/gcc/include-fixed/stdlib.h:291:8: internal compiler error: in from_mode_char, at attribs.h:304
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100734 --- Comment #11 from dave.anglin at bell dot net --- On 2021-05-26 3:32 p.m., dave.anglin at bell dot net wrote: > Attached a possible fix. While the patch fixes boot, pr100619.c fails: spawn /test/gnu/gcc/objdir64/gcc/xgcc -B/test/gnu/gcc/objdir64/gcc/ /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr100619.c -fdiagnostics-plain-output -Wall -S -o pr100619.s /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr100619.c:14:1: internal compiler error: Segmentation fault
[Bug c/100817] New: ICE with -O2: in compute_antic, at tree-ssa-pre.c:2513
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100817
Bug ID: 100817
Summary: ICE with -O2: in compute_antic, at tree-ssa-pre.c:2513
Product: gcc
Version: tree-ssa
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: cnsun at uwaterloo dot ca
Target Milestone: ---
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/scratch/software/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /tmp/tmp.EknlexSzGF-gcc-builder/gcc/configure
--enable-languages=c,c++,lto --enable-checking-yes --enable-multiarch
--prefix=/scratch/software/gcc-trunk --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210528 (experimental) [master revision
:0e2d976f7:cd62d089f6021fd1ad4537b8182836d15b14514f] (GCC)
$ cat mutant.c
a;
__attribute__((cold)) b ()
{
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;)
for (; a >= 0;)
for (; a;
[Bug target/100799] Stackoverflow in optimized code on PPC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799 --- Comment #1 from Alexander Grund --- Confirmed to also break with GCC 7.3, 8.2, 8.3 but works with 6.3, 6.4, 6.5
[Bug c++/100805] __int128 should be disabled for non-extended -std= options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100805 --- Comment #3 from Jonathan Wakely --- (In reply to Harald van Dijk from comment #2) > __int128 behaves mostly like an integer type but is not an "extended integer > type" as defined in the standard. Quoting from > https://gcc.gnu.org/onlinedocs/gcc/Integers-implementation.html: "GCC does > not support any extended integer types." Extended integer types must meet > specific requirements that __int128 does not meet: extended integer types > cannot be larger than intmax_t, and __int128 is. Right. > Despite __int128 not being an extended integer type, there is nothing wrong > with having __int128 enabled in standards-conforming mode. Out-of-range > constants must be diagnosed, but they already are, and continuing to accept > the program after that is valid. Indeed, a warning is a diagnostic. > The warning that is generated for the out-of-range constant is highly > misleading though: the warning says "integer constant is so large that it is > unsigned". Either the constant should be given an unsigned type, or the > warning should be updated to reflect the type the constant actually gets. Agreed. Going back to David's original point: Whether or not the implicit conversion to __int128 is enabled for strict modes, the __int128 type itself needs to be enabled. Libstdc++ relies on it existing.
[Bug fortran/100816] New: Wrong span on widechar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100816 Bug ID: 100816 Summary: Wrong span on widechar Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gcc dot gnu.org Target Milestone: --- Created attachment 50884 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50884=edit Fortran code showing problem Hi all! Array descriptor span does not reflect larger number of bytes on widechar. Seen on: GNU Fortran (GCC) 9.3.1 20210526 GNU Fortran (GCC) 10.3.1 20210526 GNU Fortran (GCC) 11.1.1 20210526 GNU Fortran (GCC) 12.0.0 20210527 (experimental) Thank you very much. Best regards, José Rui
[Bug fortran/100815] [10.3, 11 regression] Segfault assigning to scalar allocatable polymorphic LHS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100815 --- Comment #1 from Neil Carlson --- Actually it looks like the regression was introduced in 10.3. It works in 10.2 and earlier.
[Bug target/79173] add-with-carry and subtract-with-borrow support (x86_64 and others)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79173 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org Last reconfirmed|2017-01-23 00:00:00 |2021-5-28 --- Comment #10 from Thomas Koenig --- Just had a look at trunk. It currently produces adc: leaq800(%rsi), %rcx xorl%edx, %edx .L2: movq(%rdi), %rax addb$-1, %dl adcq(%rsi), %rax setc%dl addq$8, %rsi movq%rax, (%rdi) addq$8, %rdi cmpq%rcx, %rsi jne .L2 ret Clang does adc:# @adc movl$4, %eax xorl%ecx, %ecx .LBB0_1:# =>This Inner Loop Header: Depth=1 movq-32(%rsi,%rax,8), %rdx addb$-1, %cl adcq%rdx, -32(%rdi,%rax,8) movq-24(%rsi,%rax,8), %rcx adcq%rcx, -24(%rdi,%rax,8) movq-16(%rsi,%rax,8), %rcx adcq%rcx, -16(%rdi,%rax,8) movq-8(%rsi,%rax,8), %rcx adcq%rcx, -8(%rdi,%rax,8) movq(%rsi,%rax,8), %rcx adcq%rcx, (%rdi,%rax,8) setb%cl addq$5, %rax cmpq$104, %rax jne .LBB0_1 retq so it actually unrolls the loop and does the ideal sequence of add with carry.
[Bug fortran/100815] New: [11 regression] Segfault assigning to scalar allocatable polymorphic LHS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100815 Bug ID: 100815 Summary: [11 regression] Segfault assigning to scalar allocatable polymorphic LHS Product: gcc Version: 11.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: neil.n.carlson at gmail dot com Target Milestone: --- The current head of the gcc-11 branch segfaults on the assignment statement in the following program. The program runs without error with the 10.x and 9.x compilers. type, abstract :: func end type type, extends(func) :: const_func real :: c = 0.0 end type type :: func_box class(func), allocatable :: f end type type :: foo type(func_box), allocatable :: farray(:) end type type(const_func) :: f type(foo) :: this allocate(this%farray(2)) this%farray(size(this%farray))%f = f end
[Bug ipa/100812] [10 Regression] lto1-wpa memory hog building openjdk trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100812 --- Comment #3 from Matthias Klose --- adding -fno-ipa-icf or -fno-ipa-sra, or both flags makes a difference
[Bug ipa/100812] [10 Regression] lto1-wpa memory hog building openjdk trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100812 Richard Biener changed: What|Removed |Added Keywords||lto Component|lto |ipa Target Milestone|--- |10.4 Known to work||11.1.0 --- Comment #2 from Richard Biener --- Not sure if really a GCC regression - unless say GCC 9 is fine as well. That said, awaits reproduction / testcase. I suppose trying -fno-ipa-* to see whether triggered by a specific IPA pass would be interesting (my bet is ICF or SRA both of which have seen larger changes in GCC 10/11).
[Bug c++/100502] [11/12 Regression] ICE in enforce_access at cp/semantics.c:368 since r11-6800-g29853c653245c37e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100502 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Patrick Palka --- Fixed for GCC 11.2 and 12.
[Bug c++/100502] [11/12 Regression] ICE in enforce_access at cp/semantics.c:368 since r11-6800-g29853c653245c37e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100502 --- Comment #4 from CVS Commits --- The releases/gcc-11 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:365deb8399262033ac766b924c35d31db3d621ca commit r11-8475-g365deb8399262033ac766b924c35d31db3d621ca Author: Patrick Palka Date: Wed May 26 16:02:33 2021 -0400 c++: access for hidden friend of nested class template [PR100502] Here, during ahead of time access checking for the private member EnumeratorRange::end_reached_ in the hidden friend f, we're triggering the assert in enforce_access that verifies we're not trying to add a access check for a dependent decl onto TI_DEFERRED_ACCESS_CHECKS. The special thing about this class member access expression is that the overall expression is non-dependent (so finish_class_member_access_expr doesn't exit early at parse time), and then accessible_p rejects the access (so we don't exit early from enforce access either, and end up triggering the assert b/c the member itself is dependent). I think we're correct to reject the access because a hidden friend is not a member function, so [class.access.nest] doesn't apply, and also a hidden friend of a nested class is not a friend of the enclosing class. To fix this ICE, this patch disables ahead of time access checking during the member lookup in finish_class_member_access_expr. This avoids potentially pushing an access check for a dependent member onto TI_DEFERRED_ACCESS_CHECKS, and it's safe because we're going to redo the same lookup at instantiation time anyway. PR c++/100502 gcc/cp/ChangeLog: * typeck.c (finish_class_member_access_expr): Disable ahead of time access checking during the member lookup. gcc/testsuite/ChangeLog: * g++.dg/template/access37.C: New test. * g++.dg/template/access37a.C: New test. (cherry picked from commit abe8787a8492013145b275b858f70943522d7226)
[Bug libstdc++/100479] range adaptors handle cached iterators incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100479 --- Comment #2 from CVS Commits --- The releases/gcc-11 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:49f369fb33fb5bed4dadfb5b42b23cded888ab52 commit r11-8476-g49f369fb33fb5bed4dadfb5b42b23cded888ab52 Author: Patrick Palka Date: Mon May 24 15:24:44 2021 -0400 libstdc++: Fix iterator caching inside range adaptors [PR100479] This fixes two issues with our iterator caching as described in detail in the PR. Since we recently added the __non_propagating_cache class template as part of r12-336 for P2328, this patch just rewrites the problematic _CachedPosition partial specialization in terms of this class template. For the offset partial specialization, it's safe to propagate the cached offset on copy/move, but we should still invalidate the cached offset in the source object on move. libstdc++-v3/ChangeLog: PR libstdc++/100479 * include/std/ranges (__detail::__non_propagating_cache): Move definition up to before that of _CachedPosition. Make base class _Optional_base protected instead of private. Add const overload for operator*. (__detail::_CachedPosition): Rewrite the partial specialization for forward ranges as a derived class of __non_propagating_cache. Remove the size constraint on the partial specialization for random access ranges. Add copy/move/copy-assignment/move-assignment members to the offset partial specialization for random access ranges that propagate the cached value but additionally invalidate it in the source object on move. * testsuite/std/ranges/adaptors/100479.cc: New test. (cherry picked from commit 46ed811bcb4b86a81ef3d78ea8cfffc6cd043144)
[Bug c/100808] PPC: ISA 3.1 builtin documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100808 --- Comment #1 from Jens Seifert --- https://gcc.gnu.org/onlinedocs/gcc/PowerPC-AltiVec-Built-in-Functions-Available-on-ISA-3_002e1.html vector unsigned long long int vec_gnb (vector unsigned __int128, const unsigned char) should be unsigned long long int vec_gnb (vector unsigned __int128, const unsigned char) vgnb instruction returns result in GPR.
[Bug target/100811] Consider not omitting frame pointers by default on targets with many registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100811 --- Comment #3 from Andrew Pinski --- Also on say PowerPC, not omitting the frame pointer gives no benifit whats so ever really with respect to backtracing.
[Bug fortran/100814] New: Fortran memory error on assignment from polymorphic variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100814 Bug ID: 100814 Summary: Fortran memory error on assignment from polymorphic variable Product: gcc Version: 10.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jhaiduce at gmail dot com Target Milestone: --- The following code produces a memory error when compiled with recent versions of gfortran: ``` module distributed_array implicit none type :: darray_segment integer::rank integer::offset integer::length real(kind=8), allocatable::data(:) contains end type darray_segment type :: darray type(darray_segment), allocatable::segments(:) end type darray contains function new_darray(segments) class(darray_segment), intent(in)::segments(:) type(darray)::new_darray new_darray%segments = segments end function new_darray end module distributed_array program test_darray use distributed_array, ONLY: darray, darray_segment, new_darray implicit none integer, parameter::np_src = 4 integer, parameter::np_dest = 3 type(darray)::src_darray type(darray)::dest_darray type(darray_segment)::src_segments(np_src) type(darray_segment)::dest_segments(np_dest) src_darray = new_darray(src_segments) dest_darray = new_darray(dest_segments) end program test_darray ``` The above code runs without error when compiled with gfortran 4.9.4 and 10.2, but when compiled with gfortran 10.3 and 11.1 it produces the following output: ``` darray_test: malloc.c:2385: sysmalloc: Assertion `(old_top == initial_top (av) && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && prev_inuse (old_top) && ((unsigned long) old_end & (pagesize - 1)) == 0)' failed. Program received signal SIGABRT: Process abort signal. Backtrace for this error: #0 0x7f727c59fbf0 in ??? #1 0x7f727c59ee45 in ??? #2 0x7f727c20d83f in ??? at /build/glibc-vjB4T1/glibc-2.28/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0 #3 0x7f727c20d7bb in __GI_raise at ../sysdeps/unix/sysv/linux/raise.c:51 #4 0x7f727c1f8534 in __GI_abort at /build/glibc-vjB4T1/glibc-2.28/stdlib/abort.c:79 #5 0x7f727c255a67 in __malloc_assert at /build/glibc-vjB4T1/glibc-2.28/malloc/malloc.c:298 #6 0x7f727c257e6e in sysmalloc at /build/glibc-vjB4T1/glibc-2.28/malloc/malloc.c:2382 #7 0x7f727c2592c8 in _int_malloc at /build/glibc-vjB4T1/glibc-2.28/malloc/malloc.c:4133 #8 0x7f727c25a3e2 in __GI___libc_malloc at /build/glibc-vjB4T1/glibc-2.28/malloc/malloc.c:3049 #9 0x401f10 in __distributed_array_MOD_new_darray at /test/src/test/darray_tests.F90:23 #10 0x402933 in test_darray at /test/src/test/darray_tests.F90:44 #11 0x402aaf in main at /test/src/test/darray_tests.F90:31 ``` The code also runs without error when compiled with ifort 2021.2. The problem appears to be triggered by the assignment `new_darray%segments = segments`. The error can be prevented by changing the declaration `class(darray_segment), intent(in)::segments(:)` to `type(darray_segment), intent(in)::segments(:)` (replacing class with type), or by replacing the assignment with an explicit allocation: `allocate( new_darray%segments, source= segments )`.
[Bug fortran/100813] New: Function of array of pointers to abstract class returning an array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100813 Bug ID: 100813 Summary: Function of array of pointers to abstract class returning an array Product: gcc Version: 10.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mailling-lists-bd at posteo dot de Target Milestone: --- Hello, I was trying to write a function that takes an array of pointers to an abstract class as argument, and that returns an array with a shape determined by a member of the mentioned abstract class. The following example segfaults with gfortran 10.3 on Opensuse: module baseClass implicit none type, abstract, public :: base integer, allocatable :: i(:) contains procedure(sub), deferred, pass :: mysub end type base abstract interface subroutine sub(bb) import :: base class(base), intent(in) :: bb end subroutine sub end interface type, public :: baseWrap class(base), pointer :: p end type baseWrap public :: operate_on_baseWrap contains function operate_on_baseWrap(wrapped) result(res) class(baseWrap), intent(in) :: wrapped(:) integer :: i, tmp integer, dimension(size(wrapped(1)%p%i)) :: res do i=1, size(wrapped) call wrapped(i)%p%mysub end do res = 0 end function operate_on_baseWrap end module baseClass module childClass use baseClass implicit none type, extends(base), public :: child1 contains procedure, pass :: mysub => sub_child1 end type child1 contains subroutine sub_child1(bb) class(child1), intent(in) :: bb print *, 'Do something', bb%i end subroutine sub_child1 end module childClass program test use baseClass use childClass implicit none type(baseWrap), allocatable :: wrapper(:) type(child1), allocatable, target :: c(:) integer :: i integer, allocatable :: tmp(:) allocate(wrapper(3)) allocate(c(3)) do i=1, 3 allocate(c(i)%i(3)) c(i)%i = i wrapper(i)%p => c(i) end do allocate(tmp(size(wrapper(1)%p%i))) tmp = operate_on_baseWrap(wrapper) end program test
[Bug lto/100812] [10 Regression] lto1-wpa memory hog building openjdk trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100812 Matthias Klose changed: What|Removed |Added Target||x86_64-linux-gnu ||aarch64-linux-gnu --- Comment #1 from Matthias Klose --- seen on x86_64-linux-gnu and aarch64-linux-gnu, not powerpc64le-linux-gnu and s390x-linux-gnu
[Bug tree-optimization/100778] [11/12 Regression] Get SIGFPE on simple test with -fpe-trap=invalid and SLP vectorization ON, with gfortran 11.1.0 on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100778 --- Comment #6 from Richard Biener --- The fix pushed is for a related issue only, still working on the actual issue.
[Bug tree-optimization/100778] [11/12 Regression] Get SIGFPE on simple test with -fpe-trap=invalid and SLP vectorization ON, with gfortran 11.1.0 on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100778 --- Comment #5 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:f7a07f5a5d8065e7f11133dd1f4ad3510ab2195b commit r12-1115-gf7a07f5a5d8065e7f11133dd1f4ad3510ab2195b Author: Richard Biener Date: Fri May 28 14:26:06 2021 +0200 tree-optimization/100778 - avoid cross-BB vectorization of trapping op This avoids vectorizing a possibly trapping operation when lanes are handled in different BBs. I spotted this when working on the originally reported issue in PR100778. 2021-05-28 Richard Biener PR tree-optimization/100778 * tree-vect-slp.c (vect_build_slp_tree_1): Prevent possibly trapping ops in different BBs. * gcc.dg/vect/bb-slp-pr100778-1.c: New testcase.
[Bug lto/100812] New: [10 Regression] lto1-wpa memory hog building openjdk trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100812 Bug ID: 100812 Summary: [10 Regression] lto1-wpa memory hog building openjdk trunk Product: gcc Version: 10.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: doko at debian dot org CC: marxin at gcc dot gnu.org Target Milestone: --- openjdk trunk was building ok with lto (at least the 17+19 snapshot), however with the 17+24 snapshot, one lto1-wpa process is eating up memory to 200GB and beyond (linking libjvm.so). seen with the gcc-10 branch. The 17+24 snapshot builds ok with the gcc-11 branch. openjdk is configured with ./configure \ --with-jvm-variants=server \ --with-boot-jdk=/usr/lib/jvm/java-17-openjdk-amd64 \ --disable-precompiled-headers --with-jvm-features=zgc \ --with-extra-cflags='-flto=auto -ffat-lto-objects' \ --with-extra-cxxflags='-flto=auto -ffat-lto-objects' \ --with-extra-ldflags='-flto=auto' \ --disable-warnings-as-errors \ --with-debug-level=release \ --with-native-debug-symbols=internal \ --enable-unlimited-crypto \ --disable-javac-server \ --with-stdc++lib=dynamic sources taken from https://github.com/openjdk/jdk/releases
[Bug c++/100797] [10/11/12 Regression] using declaration causing virtual call with wrongly adjusted this pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100797 Jason Merrill changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #5 from Jason Merrill --- Stephan, can you verify that this fixes the LibreOffice issue?
[Bug c++/100797] [10/11/12 Regression] using declaration causing virtual call with wrongly adjusted this pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100797 --- Comment #4 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:f838e3ccf8d2849980e9d0f70aa60ecd2eb5772c commit r12-1114-gf838e3ccf8d2849980e9d0f70aa60ecd2eb5772c Author: Jason Merrill Date: Thu May 27 23:54:52 2021 -0400 c++: 'this' adjustment for devirtualized call My patch for 95719 made us do a better job of finding the actual virtual function we want to call, but didn't update the 'this' pointer adjustment to match. PR c++/100797 PR c++/95719 gcc/cp/ChangeLog: * call.c (build_over_call): Adjust base_binfo in resolves_to_fixed_type_p case. gcc/testsuite/ChangeLog: * g++.dg/inherit/virtual15.C: New test.
[Bug c++/95719] [10/11 Regression] ICE in lookup_vfn_in_binfo at gcc/cp/class.c:2459 since r11-954-g0ddb93ce77374004
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95719 --- Comment #12 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:f838e3ccf8d2849980e9d0f70aa60ecd2eb5772c commit r12-1114-gf838e3ccf8d2849980e9d0f70aa60ecd2eb5772c Author: Jason Merrill Date: Thu May 27 23:54:52 2021 -0400 c++: 'this' adjustment for devirtualized call My patch for 95719 made us do a better job of finding the actual virtual function we want to call, but didn't update the 'this' pointer adjustment to match. PR c++/100797 PR c++/95719 gcc/cp/ChangeLog: * call.c (build_over_call): Adjust base_binfo in resolves_to_fixed_type_p case. gcc/testsuite/ChangeLog: * g++.dg/inherit/virtual15.C: New test.
[Bug tree-optimization/100801] Aggressive loop optimizations cause incorrect warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100801 --- Comment #2 from Joel Linn --- Great. In the meantime I will use > if (count % 4 == 0) __builtin_unreachable(); at the start of the for loop to suppress the warning as suggested by Martin Sebor https://gcc.gnu.org/pipermail/gcc-help/2021-May/140339.html
[Bug ipa/100791] [10/11 Regression] ICE: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100791 Richard Biener changed: What|Removed |Added Summary|ICE: verify_gimple failed |[10/11 Regression] ICE: ||verify_gimple failed Known to work||12.0 Target Milestone|--- |10.4 --- Comment #5 from Richard Biener --- Fixed on trunk sofar.
[Bug c/100803] ICE on gimple code: in gimple_cond_get_ops_from_tree, at gimple-expr.c:566
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100803 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Richard Biener --- Fixed.
[Bug ipa/100791] ICE: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100791 --- Comment #4 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:359c0a86e2974a9f3036bc05b6e6c661f2c463cf commit r12-1113-g359c0a86e2974a9f3036bc05b6e6c661f2c463cf Author: Richard Biener Date: Fri May 28 13:31:35 2021 +0200 ipa/100791 - copy fntype when processing __builtin_va_arg_pack This missing copying exposed a type mismatch in the IL. 2021-05-28 Richard Biener PR ipa/100791 * tree-inline.c (copy_bb): When processing __builtin_va_arg_pack copy fntype from original call. * gcc.dg/pr100791.c: New testcase.
[Bug c/100803] ICE on gimple code: in gimple_cond_get_ops_from_tree, at gimple-expr.c:566
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100803 --- Comment #1 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:8b2b32ab2d8cff4eb0dad0ef4e72e33257574cb6 commit r12-1112-g8b2b32ab2d8cff4eb0dad0ef4e72e33257574cb6 Author: Richard Biener Date: Fri May 28 13:05:39 2021 +0200 c/100803 - diagnose invalid GIMPLE condition another easy fix for GIMPLE FE parser robustness. 2021-05-28 Richard Biener PR c/100803 gcc/c/ * gimple-parser.c (c_parser_gimple_paren_condition): Diagnose invalid if conditions. gcc/testsuite/ * gcc.dg/gimplefe-error-11.c: New testcase.
[Bug tree-optimization/100794] suboptimal code due to missing pre2 when vectorization fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100794
--- Comment #5 from rguenther at suse dot de ---
On Fri, 28 May 2021, linkw at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100794
>
> --- Comment #4 from Kewen Lin ---
> (In reply to rguent...@suse.de from comment #3)
> > On Fri, 28 May 2021, linkw at gcc dot gnu.org wrote:
> >
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100794
> > >
> > > --- Comment #2 from Kewen Lin ---
> > > (In reply to Richard Biener from comment #1)
> > >
> > > Thanks for the comments!
> > >
> > > > There's predictive commoning which can do similar transforms and runs
> > > > after
> > > > vectorization. It might be it doesn't handle these "simple" cases or
> > > > that
> > > > loop dependence info is not up to the task there.
> > > >
> > >
> > > pcom does fix this problem, but it's enabled by default at -O3. Could it
> > > be
> > > considered to be run at O2? Or enabled at O2 at some conditions such as:
> > > only
> > > for one loop which skips loop carried optimization and isn't vectorized
> > > further?
> >
> > I think pcom should be enabled when vectorization is due to the
> > interaction with PRE. It could be tamed down (it can do peeling/unrolling
> > which is why it is -O3) based on the vectorizer cost model active
> > if only implicitely enabled ... Things will get a bit messy I guess.
> >
>
> Good point! I prefer this idea to the one guarding cost model in sccvn code.
>
> > > > Another option is to avoid the PRE guard with the (very) cheap cost
> > > > model
> > > > at the expense of not vectorizing affected loops.
> > > >
> > >
> > > OK, I will benchmark this to see its impact. For the particular loops in
> > > 554.roms_r, they can be vectorized at cheap cost model, this bmk got
> > > improved
> > > at cheap cost model on both Power8 and Power9 (a bit though). So I will
> > > just
> > > test the impact on very cheap cost model.
> >
> > So another thing to benchmark would be to enable pcom but make sure
> >
> > /* Determine the unroll factor, and if the loop should be unrolled,
> > ensure
> > that its number of iterations is divisible by the factor. */
> > unroll_factor = determine_unroll_factor (chains);
> > scev_reset ();
> > unroll = (unroll_factor > 1
> > && can_unroll_loop_p (loop, unroll_factor, ));
> >
> > is false for the cheap and very-cheap cost models unless
> > flag_predictive_commoning is active.
> >
>
> Thanks for the hints! One question: could we just enable non-unroll
> version of pcom if it's enabled by flag_tree_loop_vectorize implicitly
> without considering vect cost model? Although the very-cheap and cheap
> cost model are very likely associated to O2, users still can try dynamic
> or unlimited cost model at O2, or very-cheap/cheap cost model at O3, it
> seems not good to map cost model onto unroll decision here directly. Or
> maybe we check the optimization level? such as:
>
> virtual bool
> gate (function *)
> {
> if (flag_predictive_commoning != 0)
> return true;
> if (flag_tree_loop_vectorize)
> {
> allow_unroll_p = optimize > 2;
But what about -O2 -ftree-vectorize -fno-predictive-commoning? IMHO
we want to check global_options_set and for "implicit" pcom do not
allow unrolling and for explicitely disabled pcom do not do any
pcom at all.
Richard.
[Bug target/100811] Consider not omitting frame pointers by default on targets with many registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100811 Florian Weimer changed: What|Removed |Added CC||fw at gcc dot gnu.org --- Comment #2 from Florian Weimer --- I expect that profilers will soon be able to use the shadow stack on x86, which will be more efficient and reliable than traversing frame pointers.
[Bug gcov-profile/100751] __gcov_dump and __gcov_reset usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100751
--- Comment #23 from Martin Liška ---
> So, for either a one time call of __gcov_dump (though we may attempt to call
> __gcov_dump many times) or at the exit of the program execution, the merge
> of profile happens due to which __gcov_reset doesn't get reflected at all.
> Am I right ?
Oh, I actually wrongly updated the documentation. When __gcov_reset is called,
run-time counters are reset to zero AND __gcov_dump can be called again (or
profile will be saved at exit).
Slightly modified test-case does now:
$ cat sample-prog.c
#include
#include
#include
extern void __gcov_reset(void);
extern void __gcov_flush(void);
extern void __gcov_dump( void);
int main()
{
unsigned char c;
int count=0;
c = 'g';
do {
printf ("c: '%c'\n", c);
if(c == 'g'){
__gcov_dump();
printf("__gcov_dump() invoked!\n");
c = 'r';
}
else if(c == 'r'){
__gcov_reset();
printf("__gcov_reset() invoked!\n");
c = 'f';
}
if(count == 2)
c = 'g';
else if (count > 10)
c = 'e';
count++;
}while(c != 'e');
return 0;
}
$ gcc sample-prog.c --coverage -g && ./a.out && gcov -t sample-prog.c
c: 'g'
__gcov_dump() invoked!
c: 'r'
__gcov_reset() invoked!
c: 'f'
c: 'g'
__gcov_dump() invoked!
c: 'r'
__gcov_reset() invoked!
c: 'f'
c: 'f'
c: 'f'
c: 'f'
c: 'f'
c: 'f'
c: 'f'
-:0:Source:sample-prog.c
-:0:Graph:sample-prog.gcno
-:0:Data:sample-prog.gcda
-:0:Runs:1
-:1:#include
-:2:#include
-:3:#include
-:4:
-:5:extern void __gcov_reset(void);
-:6:extern void __gcov_flush(void);
-:7:extern void __gcov_dump( void);
-:8:
1:9:int main()
-: 10:{
-: 11:unsigned char c;
1: 12:int count=0;
1: 13:c = 'g';
-: 14:
-: 15:do {
10: 16:printf ("c: '%c'\n", c);
-: 17:
10: 18:if(c == 'g'){
2: 19:__gcov_dump();
#: 20:printf("__gcov_dump() invoked!\n");
#: 21:c = 'r';
-: 22:}
8: 23:else if(c == 'r'){
#: 24:__gcov_reset();
2: 25:printf("__gcov_reset() invoked!\n");
2: 26:c = 'f';
-: 27:}
10: 28:if(count == 2)
1: 29:c = 'g';
9: 30:else if (count > 10)
1: 31:c = 'e';
10: 32:count++;
10: 33:}while(c != 'e');
-: 34:
1: 35:return 0;
-: 36:}
Which should be correct in my oppinion.
[Bug target/100811] Consider not omitting frame pointers by default on targets with many registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100811 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- This is a very bad idea, slowing down everything for the rare case that something needs to be profiled. And profilers can afford to unwind too if needed.
[Bug gcov-profile/100751] __gcov_dump and __gcov_reset usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100751 --- Comment #22 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:d2a913c76f41692fd0bb955d1768f462133d813a commit r12--gd2a913c76f41692fd0bb955d1768f462133d813a Author: Martin Liska Date: Fri May 28 13:35:33 2021 +0200 DOC: Update __gcov_dump documentation. PR gcov-profile/100751 gcc/ChangeLog: * doc/gcov.texi: Revert partially a hunk that was wrong.
[Bug target/100811] New: Consider not omitting frame pointers by default on targets with many registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100811 Bug ID: 100811 Summary: Consider not omitting frame pointers by default on targets with many registers Product: gcc Version: 10.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: grasland at lal dot in2p3.fr Target Milestone: --- Since at least GCC 4 (Bugzilla's duplicate search points me to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13822), GCC has been omitting frame pointers by defaults when optimizations are enabled, unless the extra -fno-omit-frame-pointer flag is specified. As far as I know, the rationale for doing this was that : - On architectures with very few general purpose registers like 32-bit x86, strictly following frame pointer retention discipline has a prohibitive performance cost. - Debuggers do not need frame pointers to do their job, as they can leverage DWARF or PDB debug information instead. While these arguments are valid, I would like to make the case that frame pointers may be worth keeping by default on hardware architectures where this is not too expensive (like x86_64), for the purpose of making software performance analysis easier. Unlike debuggers, sampling profilers like perf cannot afford the luxury of walking the process stack using DWARF any time a sample is taken, as that would take too much time and bias the measured performance profile. Instead, when using DWARF for stack unwinding purposes, they have to take stack samples and post-process them after the fact. Furthermore, since copying the full program stack on every sample would generate an unbearable volume of data, they usually can only afford to copy the top of the stack (upper 64KB at maximum for perf), which will lead to corrupted stack traces when application stacks get deep or there are lots of / large stack-allocated objects. For all these reasons, DWARF-based stack unwinding is a somewhat unreliable technique in profiling, where it's really hard to get >90% of your profile's stack traces to be correctly reconstructed all the way to _start or _clone. The remaining misreconstructed stack traces will translate into profile bias (underestimated "children" overhead measurements), and thus performance analysis mistakes. To make matters worse, DWARF-based unwinding is relatively complex, and not every useful runtime performance analysis tool supports it. For example, BPF-based tracing tools, which are nowadays becoming popular due to their highly appealing ability to instrument every kernel or user function on the fly, do not currently support DWARF-based stack unwinding, most likely because feeding the DWARF debug info into the kernel-based BPF program would either be prohibitively expensive, a security hole, or a source of recursive tracing incidents (tracing tool generates syscalls of the kind that it is tracing, creating an infinite loop). Therefore, I think -fno-omit-frame-pointer should be the default on architectures where the price to pay is not too high (like x86_64), which should ensure that modern performance analysis tooling works on all popular Linux distributions without rebuilding the entire world. In this scheme, -fomit-frame-pointer would remain as a default option for targets where it is really needed (like legacy 32-bit x86), and as a specialist option for those cases where the extra ~1% of performance is really truly needed and worth its cost. What do you think?
[Bug tree-optimization/100794] suboptimal code due to missing pre2 when vectorization fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100794
--- Comment #4 from Kewen Lin ---
(In reply to rguent...@suse.de from comment #3)
> On Fri, 28 May 2021, linkw at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100794
> >
> > --- Comment #2 from Kewen Lin ---
> > (In reply to Richard Biener from comment #1)
> >
> > Thanks for the comments!
> >
> > > There's predictive commoning which can do similar transforms and runs
> > > after
> > > vectorization. It might be it doesn't handle these "simple" cases or that
> > > loop dependence info is not up to the task there.
> > >
> >
> > pcom does fix this problem, but it's enabled by default at -O3. Could it be
> > considered to be run at O2? Or enabled at O2 at some conditions such as:
> > only
> > for one loop which skips loop carried optimization and isn't vectorized
> > further?
>
> I think pcom should be enabled when vectorization is due to the
> interaction with PRE. It could be tamed down (it can do peeling/unrolling
> which is why it is -O3) based on the vectorizer cost model active
> if only implicitely enabled ... Things will get a bit messy I guess.
>
Good point! I prefer this idea to the one guarding cost model in sccvn code.
> > > Another option is to avoid the PRE guard with the (very) cheap cost model
> > > at the expense of not vectorizing affected loops.
> > >
> >
> > OK, I will benchmark this to see its impact. For the particular loops in
> > 554.roms_r, they can be vectorized at cheap cost model, this bmk got
> > improved
> > at cheap cost model on both Power8 and Power9 (a bit though). So I will just
> > test the impact on very cheap cost model.
>
> So another thing to benchmark would be to enable pcom but make sure
>
> /* Determine the unroll factor, and if the loop should be unrolled,
> ensure
> that its number of iterations is divisible by the factor. */
> unroll_factor = determine_unroll_factor (chains);
> scev_reset ();
> unroll = (unroll_factor > 1
> && can_unroll_loop_p (loop, unroll_factor, ));
>
> is false for the cheap and very-cheap cost models unless
> flag_predictive_commoning is active.
>
Thanks for the hints! One question: could we just enable non-unroll version of
pcom if it's enabled by flag_tree_loop_vectorize implicitly without considering
vect cost model? Although the very-cheap and cheap cost model are very likely
associated to O2, users still can try dynamic or unlimited cost model at O2, or
very-cheap/cheap cost model at O3, it seems not good to map cost model onto
unroll decision here directly. Or maybe we check the optimization level? such
as:
virtual bool
gate (function *)
{
if (flag_predictive_commoning != 0)
return true;
if (flag_tree_loop_vectorize)
{
allow_unroll_p = optimize > 2;
return true;
}
return false;
}
> It's probably also a good idea to investigate whether the
> update_ssa calls in pcom can be delayed to until after all transforms
> have been done.
OK, will check this later.
[Bug ipa/100791] ICE: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100791 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #3 from Richard Biener --- testing patch.
[Bug gcov-profile/100788] Internal compiler error related to #line macros(?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100788
Martin Liška changed:
What|Removed |Added
Status|WAITING |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot
gnu.org
--- Comment #10 from Martin Liška ---
Thanks. I was able to reproduce that. It's related to the usage of '#line XYZ'
directives which generate a situation where the function ends before it begins.
I was able to reduce that to something like:
$ cat x.c
void
foo()
{
#line 1
}
$ gcc --coverage x.c
during IPA pass: profile
x.c: In function ‘foo’:
x.c:1:1: internal compiler error: in coverage_begin_function, at coverage.c:662
1 | void
| ^
0xa3168b coverage_begin_function(unsigned int, unsigned int)
/home/marxin/Programming/gcc/gcc/coverage.c:662
0xde935f branch_prob(bool)
/home/marxin/Programming/gcc/gcc/profile.c:1328
0xf7bd60 tree_profiling
/home/marxin/Programming/gcc/gcc/tree-profile.c:782
0xf7bd60 execute
/home/marxin/Programming/gcc/gcc/tree-profile.c:888
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c/100803] ICE on gimple code: in gimple_cond_get_ops_from_tree, at gimple-expr.c:566
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100803 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Keywords||ice-on-invalid-code Last reconfirmed||2021-05-28 Version|tree-ssa|12.0 Status|UNCONFIRMED |ASSIGNED
[Bug tree-optimization/100801] Aggressive loop optimizations cause incorrect warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100801 Richard Biener changed: What|Removed |Added Component|ipa |tree-optimization Keywords||diagnostic, ||missed-optimization Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2021-05-28 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #1 from Richard Biener --- Confirmed. We're warning on the obviously unreachable loop since: [local count: 1073741824]: _35 = 12; if (_35 != 12) goto ; [75.00%] else goto ; [25.00%] $3 = since we apply final value replacement to 'i' in sccp but do not propagate it before the next number of iteration analysis in ivcanon: NEXT_PASS (pass_tree_loop_init); NEXT_PASS (pass_tree_unswitch); NEXT_PASS (pass_scev_cprop); final value repl. NEXT_PASS (pass_loop_split); NEXT_PASS (pass_loop_versioning); NEXT_PASS (pass_loop_jam); /* All unswitching, final value replacement and splitting can expose empty loops. Remove them now. */ NEXT_PASS (pass_cd_dce, false /* update_address_taken_p */); NEXT_PASS (pass_iv_canon); < warning NEXT_PASS (pass_loop_distribution); NEXT_PASS (pass_linterchange); NEXT_PASS (pass_copy_prop); << propagation IIRC final value replacement used to propagate and fold but I(?) removed this at some point.
[Bug c++/100797] [10/11/12 Regression] using declaration causing virtual call with wrongly adjusted this pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100797 Richard Biener changed: What|Removed |Added Priority|P1 |P2 Summary|[9/10/11/12 Regression] |[10/11/12 Regression] using |using declaration causing |declaration causing virtual |virtual call with wrongly |call with wrongly adjusted |adjusted this pointer |this pointer --- Comment #3 from Richard Biener --- I've pushed a fix to the GCC 9 branch.
[Bug c++/100796] [11 Regression] GCC does not honor #pragma diagnostic ignored when using the integrated preprocessor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100796 Richard Biener changed: What|Removed |Added Keywords||diagnostic Version|unknown |11.1.1 Target Milestone|--- |11.2
[Bug ipa/100791] ICE: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100791 Richard Biener changed: What|Removed |Added Component|c |ipa Version|tree-ssa|12.0 Status|NEW |ASSIGNED Keywords||ice-on-valid-code --- Comment #2 from Richard Biener --- I'll see to fix this.
[Bug tree-optimization/100787] [12 Regression] Bootstrap failure caused by r12-1077
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100787 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug target/100784] [10/11/12 Regression] ICE: Segmentation fault, contains_struct_check(tree_node*, tree_node_structure_enum, char const*, int, char const*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100784 Richard Biener changed: What|Removed |Added Summary|ICE: Segmentation fault,|[10/11/12 Regression] ICE: |contains_struct_check(tree_ |Segmentation fault, |node*, |contains_struct_check(tree_ |tree_node_structure_enum, |node*, |char const*, int, char |tree_node_structure_enum, |const*) |char const*, int, char ||const*) Target Milestone|--- |10.4 --- Comment #3 from Richard Biener --- Like the other case the calls should be replaced by GIMPLE_NOP in the x86 folder when there's no LHS.
[Bug target/100782] [11 Regression] sh4 ICEs on -O2 -fPIE -fstack-protector: internal compiler error: in curr_insn_transform, at lra-constraints.c:4132
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100782 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.2
[Bug tree-optimization/100778] [11/12 Regression] Get SIGFPE on simple test with -fpe-trap=invalid and SLP vectorization ON, with gfortran 11.1.0 on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100778 Richard Biener changed: What|Removed |Added Known to work|12.0| Summary|[11 Regression] Get SIGFPE |[11/12 Regression] Get |on simple test with |SIGFPE on simple test with |-fpe-trap=invalid and SLP |-fpe-trap=invalid and SLP |vectorization ON, with |vectorization ON, with |gfortran 11.1.0 on x86_64 |gfortran 11.1.0 on x86_64 --- Comment #4 from Richard Biener --- The same happens on trunk for me but there we sink the stmt back into the if because we've added another sinking pass.
[Bug tree-optimization/100778] [11 Regression] Get SIGFPE on simple test with -fpe-trap=invalid and SLP vectorization ON, with gfortran 11.1.0 on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100778
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |11.2
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #3 from Richard Biener ---
Confirmed. It's SLP vectorization placing the vectorized division outside of
the if:
[local count: 1073741824]:
+ vectp.9_32 = &(*input_8(D))[0];
+ vect__1.10_33 = MEM [(real(kind=8) *)vectp.9_32];
+ _35 = BIT_FIELD_REF ;
+ _34 = BIT_FIELD_REF ;
_1 = (*input_8(D))[0];
- coordinates.x = _1;
_2 = (*input_8(D))[1];
- coordinates.y = _2;
- _11 = _1 * _1;
- _12 = _2 * _2;
+ MEM [(real(kind=8) *)] = vect__1.10_33;
+ _11 = _34 * _34;
+ _12 = _35 * _35;
_3 = _11 + _12;
norm_13 = __builtin_sqrt (_3);
+ _37 = {norm_13, norm_13};
+ vect__4.13_38 = vect__1.10_33 / _37;
if (norm_13 > 1.0e+0)
goto ; [41.48%]
else
@@ -34,13 +64,11 @@
[local count: 445388112]:
_4 = _1 / norm_13;
- coordinates.x = _4;
_5 = _2 / norm_13;
- coordinates.y = _5;
+ MEM [(real(kind=8) *)] = vect__4.13_38;
[Bug tree-optimization/100774] [12 Regression] -fcompare-debug failure (length) with -O2 -fno-tree-forwprop --param=evrp-mode=ranger-trace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100774 --- Comment #3 from Richard Biener --- (In reply to Andrew Macleod from comment #2) > I have a fix for this... > Do we add -fcompare-debug tests into the testsuite? I don't see any other > tests with it. Sure we do, grep will show quite some.
[Bug gcov-profile/100751] __gcov_dump and __gcov_reset usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100751
--- Comment #21 from Gejoe ---
(In reply to Martin Liška from comment #20)
> > I'm trying to understand line #22 to #26 specifically of .c.gcov file(as
> > shown in commment #16. Let me know if the steps followed in compilation or
> > execution had any thing wrong.
>
> What is wrong with that? What values are expected?
Actually if we look at line #22 should have the value 16 (after a.out run) and
line #24,25 should have values 4 each instead of what is actually present there
in comment#16.Instead the value of 16,4,4 are shown for line # 24,26,27
respectively. That was my query.
Is that because of some difference with source files and .gcda files as shown
there (in .c.gcov file in Comment #16) as follows ?
0:Source is newer than graph
I did delete the gcda file and did the same compilation steps again :
$ gcc -v -save-temps -fprofile-arcs -ftest-coverage sample-prog.c
$ gcc -fprofile-arcs -ftest-coverage sample-prog.o
$./a.out
The output was :
$ ./a.out
__gcov_dump() invoked!
__gcov_reset() invoked!
__gcov_dump() invoked!
__gcov_reset() invoked!
The sample-prog.c.gcov file contents now look fine :
-:0:Source:sample-prog.c
-:0:Graph:sample-prog.gcno
-:0:Data:sample-prog.gcda
-:0:Runs:1
-:0:Programs:1
-:1:#include
-:2:#include
-:3:#include
-:4:
-:5:extern void __gcov_reset(void);
-:6:extern void __gcov_flush(void);
-:7:extern void __gcov_dump( void);
-:8:
1:9:int main()
-: 10:{
-: 11:unsigned char c;
1: 12:int count=0;
1: 13:c = 'g';
-: 14:
-: 15:do {
-: 16:
10: 17:if(c == 'g'){
2: 18:__gcov_dump();
#: 19:printf("__gcov_dump() invoked!\n");
#: 20:c = 'r';
-: 21:}
8: 22:else if(c == 'r'){
#: 23:__gcov_reset();
2: 24:printf("__gcov_reset() invoked!\n");
2: 25:c = 'f';
-: 26:}
10: 27:if(count == 2)
1: 28:c = 'g';
9: 29:else if (count > 10)
1: 30:c = 'e';
10: 31:count++;
10: 32:}while(c != 'e');
-: 33:
1: 34:return 0;
-: 35:}
==
So, for either a one time call of __gcov_dump (though we may attempt to call
__gcov_dump many times) or at the exit of the program execution, the merge of
profile happens due to which __gcov_reset doesn't get reflected at all. Am I
right ?
Thanks again!
[Bug middle-end/99928] [OpenMP] reduction variable in combined target construct wrongly mapped as firstprivate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99928 --- Comment #14 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:c94424b0ed786ec92b6904da69af8b5243b34fdc commit r12-1109-gc94424b0ed786ec92b6904da69af8b5243b34fdc Author: Jakub Jelinek Date: Fri May 28 11:26:48 2021 +0200 openmp: Fix up handling of reduction clause on constructs combined with target [PR99928] The reduction clause should be copied as map (tofrom: ) to combined target if present, but as we need different handling of array sections between map and reduction, doing that during gimplification would be harder. So, this patch adds them during splitting, and similarly to firstprivate adds them with a new flag that they should be just ignored/removed if an explicit map clause of the same list item is present. The exact rules are to be decided in https://github.com/OpenMP/spec/issues/2766 so this patch just implements something that is IMHO reasonable and exact detailed testcases for the cornercases will follow once it is clarified. 2021-05-28 Jakub Jelinek PR middle-end/99928 gcc/ * tree.h (OMP_CLAUSE_MAP_IMPLICIT): Define. gcc/c-family/ * c-omp.c (c_omp_split_clauses): For reduction clause if combined with target add a map tofrom clause with OMP_CLAUSE_MAP_IMPLICIT. gcc/c/ * c-typeck.c (handle_omp_array_sections): Copy OMP_CLAUSE_MAP_IMPLICIT. (c_finish_omp_clauses): Move not just OMP_CLAUSE_FIRSTPRIVATE_IMPLICIT marked clauses last, but also OMP_CLAUSE_MAP_IMPLICIT. Add map_firstprivate_head bitmap, set it for GOMP_MAP_FIRSTPRIVATE_POINTER maps and silently remove OMP_CLAUSE_FIRSTPRIVATE_IMPLICIT if it is present too. For OMP_CLAUSE_MAP_IMPLICIT silently remove the clause if present in map_head, map_field_head or map_firstprivate_head bitmaps. gcc/cp/ * semantics.c (handle_omp_array_sections): Copy OMP_CLAUSE_MAP_IMPLICIT. (finish_omp_clauses): Move not just OMP_CLAUSE_FIRSTPRIVATE_IMPLICIT marked clauses last, but also OMP_CLAUSE_MAP_IMPLICIT. Add map_firstprivate_head bitmap, set it for GOMP_MAP_FIRSTPRIVATE_POINTER maps and silently remove OMP_CLAUSE_FIRSTPRIVATE_IMPLICIT if it is present too. For OMP_CLAUSE_MAP_IMPLICIT silently remove the clause if present in map_head, map_field_head or map_firstprivate_head bitmaps. gcc/testsuite/ * c-c++-common/gomp/pr99928-8.c: Remove all xfails. * c-c++-common/gomp/pr99928-9.c: Likewise. * c-c++-common/gomp/pr99928-10.c: Likewise. * c-c++-common/gomp/pr99928-16.c: New test.
[Bug tree-optimization/100810] [12 Regression] wrong code at -O1 and above on x86_64-linux-gnu since r12-397-gda9e6e63d1ae22e530ec7baf59f6ed028bf05776
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100810 Martin Liška changed: What|Removed |Added Summary|wrong code at -O1 and above |[12 Regression] wrong code |on x86_64-linux-gnu |at -O1 and above on ||x86_64-linux-gnu since ||r12-397-gda9e6e63d1ae22e530 ||ec7baf59f6ed028bf05776 CC||aoliva at gcc dot gnu.org, ||marxin at gcc dot gnu.org Target Milestone|--- |12.0 Last reconfirmed||2021-05-28 Priority|P3 |P1 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Started with r12-397-gda9e6e63d1ae22e530ec7baf59f6ed028bf05776.
[Bug c++/100797] [9/10/11/12 Regression] using declaration causing virtual call with wrongly adjusted this pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100797 --- Comment #2 from CVS Commits --- The releases/gcc-9 branch has been updated by Richard Biener : https://gcc.gnu.org/g:ebfe8b28d40746ff33724bd5b9ade2552e619213 commit r9-9558-gebfe8b28d40746ff33724bd5b9ade2552e619213 Author: Jason Merrill Date: Thu May 27 23:54:52 2021 -0400 c++: 'this' adjustment for devirtualized call My patch for 95719 made us do a better job of finding the actual virtual function we want to call, but didn't update the 'this' pointer adjustment to match. This backport also incorporates a bit of the r11-1638 reorganization. PR c++/100797 PR c++/95719 gcc/cp/ChangeLog: * call.c (build_over_call): Adjust base_binfo in resolves_to_fixed_type_p case. gcc/testsuite/ChangeLog: * g++.dg/inherit/virtual15.C: New test. * g++.dg/inherit/virtual15a.C: New test.
[Bug c++/95719] [10/11 Regression] ICE in lookup_vfn_in_binfo at gcc/cp/class.c:2459 since r11-954-g0ddb93ce77374004
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95719 --- Comment #11 from CVS Commits --- The releases/gcc-9 branch has been updated by Richard Biener : https://gcc.gnu.org/g:ebfe8b28d40746ff33724bd5b9ade2552e619213 commit r9-9558-gebfe8b28d40746ff33724bd5b9ade2552e619213 Author: Jason Merrill Date: Thu May 27 23:54:52 2021 -0400 c++: 'this' adjustment for devirtualized call My patch for 95719 made us do a better job of finding the actual virtual function we want to call, but didn't update the 'this' pointer adjustment to match. This backport also incorporates a bit of the r11-1638 reorganization. PR c++/100797 PR c++/95719 gcc/cp/ChangeLog: * call.c (build_over_call): Adjust base_binfo in resolves_to_fixed_type_p case. gcc/testsuite/ChangeLog: * g++.dg/inherit/virtual15.C: New test. * g++.dg/inherit/virtual15a.C: New test.
[Bug tree-optimization/100810] New: wrong code at -O1 and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100810
Bug ID: 100810
Summary: wrong code at -O1 and above on x86_64-linux-gnu
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
Target Milestone: ---
[511] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
--disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210528 (experimental) [master revision
4774807e6e5:0e2d976f72b:cd62d089f6021fd1ad4537b8182836d15b14514f] (GCC)
[512] %
[512] % gcctk -O0 small.c; ./a.out
[513] %
[513] % gcctk -O1 small.c
[514] % ./a.out
Aborted
[515] %
[515] % cat small.c
int a, b = 1, c = 1, e, f = 1, g, h, j;
volatile int d;
static void k() {
int i;
h = b;
if (c && a >= 0) {
while (a) {
i++;
h--;
}
if (g)
for (h = 0; h < 2; h++)
;
if (!b)
i &
}
}
static void l() {
for (; j < 1; j++)
if (!e && c && f)
k();
}
int main() {
if (f)
l();
if (h != 1)
__builtin_abort();
return 0;
}
[Bug testsuite/100749] [12 regression] gcc.dg/pch/valid-1.c fails after r12-949
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100749 --- Comment #1 from Indu Bhagat --- Thanks for the bug report. This is reproducible. Will look into it.
[Bug target/100771] Types differ between i386-elf and x86_64-elf -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100771 Paul Menzel changed: What|Removed |Added CC||pmenzel+gcc at molgen dot mpg.de --- Comment #2 from Paul Menzel --- Created attachment 50883 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50883=edit Output of `:|i686-linux-gnu-gcc-10 -E -dM -|sort` (In reply to Andrew Pinski from comment #1) […] > Is there a difference for x86_64-linux-gnu/i?86-linux-gnu target? No, testing gcc version 10.2.1 20210110 (Debian 10.2.1-6) from Debian sid/unstable, there is no difference between i686-linux-gnu and x86_64-linux-gnu with `-m32`.
[Bug c++/100809] PPC: __int128 divide/modulo does not use P10 instructions vdivsq/vdivuq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100809 --- Comment #1 from Jens Seifert --- Same applies to modulo.
[Bug c++/100809] New: PPC: __int128 divide/modulo does not use P10 instructions vdivsq/vdivuq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100809
Bug ID: 100809
Summary: PPC: __int128 divide/modulo does not use P10
instructions vdivsq/vdivuq
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.seifert at de dot ibm.com
Target Milestone: ---
unsigned __int128 div(unsigned __int128 a, unsigned __int128 b)
{
return a/b;
}
__int128 div(__int128 a, __int128 b)
{
return a/b;
}
gcc -mcpu=power10 -save-temps -O2 int128.C
Output:
_Z3divoo:
.LFB0:
.cfi_startproc
.localentry _Z3divoo,1
mflr 0
std 0,16(1)
stdu 1,-32(1)
.cfi_def_cfa_offset 32
.cfi_offset 65, 16
bl __udivti3@notoc
addi 1,1,32
.cfi_def_cfa_offset 0
ld 0,16(1)
mtlr 0
.cfi_restore 65
blr
.long 0
.byte 0,9,0,1,128,0,0,0
.cfi_endproc
.LFE0:
.size _Z3divoo,.-_Z3divoo
.globl __divti3
.align 2
.p2align 4,,15
.globl _Z3divnn
.type _Z3divnn, @function
_Z3divnn:
.LFB1:
.cfi_startproc
.localentry _Z3divnn,1
mflr 0
std 0,16(1)
stdu 1,-32(1)
.cfi_def_cfa_offset 32
.cfi_offset 65, 16
bl __divti3@notoc
addi 1,1,32
.cfi_def_cfa_offset 0
ld 0,16(1)
mtlr 0
.cfi_restore 65
blr
.long 0
.byte 0,9,0,1,128,0,0,0
.cfi_endproc
Expected is the use of vdivsq/vdivuq.
GCC version:
/opt/rh/devtoolset-10/root/usr/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/opt/rh/devtoolset-10/root/usr/bin/gcc
COLLECT_LTO_WRAPPER=/opt/rh/devtoolset-10/root/usr/libexec/gcc/ppc64le-redhat-linux/10/lto-wrapper
Target: ppc64le-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,lto --prefix=/opt/rh/devtoolset-10/root/usr
--mandir=/opt/rh/devtoolset-10/root/usr/share/man
--infodir=/opt/rh/devtoolset-10/root/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release
--enable-targets=powerpcle-linux --disable-multilib --with-system-zlib
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-gcc-major-version-only
--with-linker-hash-style=gnu --with-default-libstdcxx-abi=gcc4-compatible
--enable-plugin --enable-initfini-array
--with-isl=/builddir/build/BUILD/gcc-10.2.1-20200804/obj-ppc64le-redhat-linux/isl-install
--disable-libmpx --enable-gnu-indirect-function --enable-secureplt
--with-long-double-128 --with-cpu-32=power8 --with-tune-32=power8
--with-cpu-64=power8 --with-tune-64=power8 --build=ppc64le-redhat-linux
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.2.1 20200804 (Red Hat 10.2.1-2) (GCC)
[Bug tree-optimization/100794] suboptimal code due to missing pre2 when vectorization fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100794 --- Comment #3 from rguenther at suse dot de --- On Fri, 28 May 2021, linkw at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100794 > > --- Comment #2 from Kewen Lin --- > (In reply to Richard Biener from comment #1) > > Thanks for the comments! > > > There's predictive commoning which can do similar transforms and runs after > > vectorization. It might be it doesn't handle these "simple" cases or that > > loop dependence info is not up to the task there. > > > > pcom does fix this problem, but it's enabled by default at -O3. Could it be > considered to be run at O2? Or enabled at O2 at some conditions such as: only > for one loop which skips loop carried optimization and isn't vectorized > further? I think pcom should be enabled when vectorization is due to the interaction with PRE. It could be tamed down (it can do peeling/unrolling which is why it is -O3) based on the vectorizer cost model active if only implicitely enabled ... Things will get a bit messy I guess. > > Another option is to avoid the PRE guard with the (very) cheap cost model > > at the expense of not vectorizing affected loops. > > > > OK, I will benchmark this to see its impact. For the particular loops in > 554.roms_r, they can be vectorized at cheap cost model, this bmk got improved > at cheap cost model on both Power8 and Power9 (a bit though). So I will just > test the impact on very cheap cost model. So another thing to benchmark would be to enable pcom but make sure /* Determine the unroll factor, and if the loop should be unrolled, ensure that its number of iterations is divisible by the factor. */ unroll_factor = determine_unroll_factor (chains); scev_reset (); unroll = (unroll_factor > 1 && can_unroll_loop_p (loop, unroll_factor, )); is false for the cheap and very-cheap cost models unless flag_predictive_commoning is active. It's probably also a good idea to investigate whether the update_ssa calls in pcom can be delayed to until after all transforms have been done.
[Bug gcov-profile/100751] __gcov_dump and __gcov_reset usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100751 --- Comment #20 from Martin Liška --- > I'm trying to understand line #22 to #26 specifically of .c.gcov file(as > shown in commment #16. Let me know if the steps followed in compilation or > execution had any thing wrong. What is wrong with that? What values are expected?
[Bug c++/100807] initialization of global struct with large array leads to huge assembly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100807 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- This is a dup of bug 61592. *** This bug has been marked as a duplicate of bug 61592 ***
[Bug c++/61592] ICE with large array with initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61592 --- Comment #5 from Andrew Pinski --- *** Bug 100807 has been marked as a duplicate of this bug. ***
[Bug c++/61592] ICE with large array with initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61592 Andrew Pinski changed: What|Removed |Added CC||bkropki at yahoo dot co.uk --- Comment #4 from Andrew Pinski --- *** Bug 80272 has been marked as a duplicate of this bug. ***
[Bug c++/80272] g++ runs out of memory with aggregate init of large std::array of non-trivial class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80272 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #7 from Andrew Pinski --- This is a dup of bug 61592. *** This bug has been marked as a duplicate of bug 61592 ***
[Bug tree-optimization/100794] suboptimal code due to missing pre2 when vectorization fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100794 --- Comment #2 from Kewen Lin --- (In reply to Richard Biener from comment #1) Thanks for the comments! > There's predictive commoning which can do similar transforms and runs after > vectorization. It might be it doesn't handle these "simple" cases or that > loop dependence info is not up to the task there. > pcom does fix this problem, but it's enabled by default at -O3. Could it be considered to be run at O2? Or enabled at O2 at some conditions such as: only for one loop which skips loop carried optimization and isn't vectorized further? > Another option is to avoid the PRE guard with the (very) cheap cost model > at the expense of not vectorizing affected loops. > OK, I will benchmark this to see its impact. For the particular loops in 554.roms_r, they can be vectorized at cheap cost model, this bmk got improved at cheap cost model on both Power8 and Power9 (a bit though). So I will just test the impact on very cheap cost model.
[Bug c++/61592] ICE with large array with initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61592 Andrew Pinski changed: What|Removed |Added CC||gcc at gyoo dot com --- Comment #3 from Andrew Pinski --- *** Bug 77443 has been marked as a duplicate of this bug. ***
[Bug c++/77443] Empty initializer on huge object array member slow down the compilation dramatically with -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77443 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #5 from Andrew Pinski --- This is a dup of bug 61592. *** This bug has been marked as a duplicate of bug 61592 ***
[Bug c/100808] New: PPC: ISA 3.1 builtin documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100808 Bug ID: 100808 Summary: PPC: ISA 3.1 builtin documentation Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: jens.seifert at de dot ibm.com Target Milestone: --- https://gcc.gnu.org/onlinedocs/gcc/Basic-PowerPC-Built-in-Functions-Available-on-ISA-3_002e1.html#Basic-PowerPC-Built-in-Functions-Available-on-ISA-3_002e1 Please improve the documentation: - Avoid additional "int" unsigned long long int => unsigned long long - add missing line breaks between builtins - remove semicolons
[Bug c++/100807] New: initialization of global struct with large array leads to huge assembly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100807
Bug ID: 100807
Summary: initialization of global struct with large array leads
to huge assembly
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Keywords: compile-time-hog
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbence92 at gmail dot com
Target Milestone: ---
Host: x86_64-w64-mingw32, x86_64-linux-gnu
Target: x86_64-w64-mingw32, x86_64-linux-gnu
Build: x86_64-w64-mingw32, x86_64-linux-gnu
The below is a reduced version of a file that took 33 minutes(!) to compile,
cc1 starting from 1GB of memory usage, reaching 2GB eventually.
This example takes ~12 seconds, ~700 MB of memory and generates 14MB of
assembly as gcc unrolls the constructor calls even with O0 and crashes with O1
and above.
clang and icc is fine, they do this with a loop, msvc kindof the same.
This seems to be and old issue, even gcc 4 timeouts on godbolt.
struct B
{
B() {}
};
struct A
{
B b[128][1875];
};
A a{};
[Bug tree-optimization/100794] suboptimal code due to missing pre2 when vectorization fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100794 --- Comment #1 from Richard Biener --- There's predictive commoning which can do similar transforms and runs after vectorization. It might be it doesn't handle these "simple" cases or that loop dependence info is not up to the task there. Another option is to avoid the PRE guard with the (very) cheap cost model at the expense of not vectorizing affected loops. So it's just one of those classical phase ordering issues that you can try to squash with running passes over and over again ...
[Bug gcov-profile/100751] __gcov_dump and __gcov_reset usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100751 --- Comment #19 from Gejoe --- Just to add on : The a.out was run twice and hence the value of 20 against line # 19, 29 of .c.gcov file(as shown in commment #16). Let me know if anything is not clear.
[Bug gcov-profile/100751] __gcov_dump and __gcov_reset usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100751 --- Comment #18 from Gejoe --- (In reply to Martin Liška from comment #14) > (In reply to Gejoe from comment #13) > > I modified my sample-prog.c file just by adding a line of __gcov_reset > > before the while loop. > > > > Can you please create a test-case that does not need human interaction > (remove getchar please)? Thanks. I have attached the .c file as attachment 50881 in Comment #16. I have shown the steps and .gcov file output there as well. The preprocess file is attached as #50882. I read your reply in Comment#15 as well. I'm trying to understand line #22 to #26 specifically of .c.gcov file(as shown in commment #16. Let me know if the steps followed in compilation or execution had any thing wrong. Thank you for the support !
[Bug gcov-profile/100751] __gcov_dump and __gcov_reset usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100751 --- Comment #17 from Gejoe --- Created attachment 50882 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50882=edit sample-prog.i file Preprocessed file contents.
[Bug tree-optimization/99398] Miss to optimize vector permutation fed by CTOR and CTOR/CST
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99398 Kewen Lin changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Kewen Lin --- Fixed.
