[Bug libstdc++/87135] [C++17] unordered containers violate iterator validity requirements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87135 François Dumont changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |fdumont at gcc dot gnu.org --- Comment #3 from François Dumont --- Rehash policy has been reviewed, rehash will take place only when reserved size is overwhelmed.
[Bug fortran/87359] New: [9.0 regression] pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87359 Bug ID: 87359 Summary: [9.0 regression] pointer being freed was not allocated Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: juergen.reuter at desy dot de Target Milestone: --- There is a severe regression introduced in the last 2-3 weeks (maybe through one of the bug fixes by Paul Thomas?) leading to a huge number of failures in our test suite. I will try to isolate it, but it can also be checked by downloading https://whizard.hepforge.org/downloads/?f=whizard-2.6.4.tar.gz (you need OCaml for most of the tests, but not for all, many of the unit tests already fail without OCaml being present, you can then configure with --disable-ocaml). Do configure, make, make check.
[Bug c/87358] ICE when -mtune=thunderx2t99 applied
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87358 Lijian Zhang changed: What|Removed |Added CC||Lijian.Zhang at arm dot com --- Comment #1 from Lijian Zhang --- Created attachment 44723 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44723=edit pre-process file
[Bug c/87358] New: ICE when -mtune=thunderx2t99 applied
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87358 Bug ID: 87358 Summary: ICE when -mtune=thunderx2t99 applied Product: gcc Version: 7.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: Lijian.Zhang at arm dot com Target Milestone: --- lijian@armada8040-1:~/ICE.issue$ gcc --version gcc (Ubuntu/Linaro 7.3.0-16ubuntu3) 7.3.0 Copyright (C) 2017 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. lijian@armada8040-1:~/ICE.issue$ cat /etc/os-release NAME="Ubuntu" VERSION="18.04.1 LTS (Bionic Beaver)" ID=ubuntu ID_LIKE=debian PRETTY_NAME="Ubuntu 18.04.1 LTS" VERSION_ID="18.04" HOME_URL="https://www.ubuntu.com/; SUPPORT_URL="https://help.ubuntu.com/; BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/; PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy; VERSION_CODENAME=bionic UBUNTU_CODENAME=bionic lijian@armada8040-1:~/ICE.issue$ lscpu Architecture:aarch64 Byte Order: Little Endian CPU(s): 4 On-line CPU(s) list: 0-3 Thread(s) per core: 1 Core(s) per socket: 2 Socket(s): 2 Vendor ID: ARM Model: 1 Model name: Cortex-A72 Stepping:r0p1 CPU max MHz: 2000. CPU min MHz: 100. BogoMIPS:50.00 Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 lijian@armada8040-1:~/ICE.issue$ gcc -c l2_learn.i -O2 -march=armv8.1-a+crc+crypto -mtune=thunderx2t99 /home/lijian/tasks/dualQuad/origin/src/vnet/l2/l2_learn.c: In function ‘l2learn_node_fn_thunderx2t99’: /home/lijian/tasks/dualQuad/origin/src/vnet/l2/l2_learn.c:430:1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. lijian@armada8040-1:~/ICE.issue$ gcc -c l2_learn.i -O2 -march=armv8.1-a+crc+crypto lijian@armada8040-1:~/ICE.issue$ lijian@armada8040-1:~/ICE.issue$
[Bug c++/86881] [8, 9 regression] tree check fail with flag Wshadow-compatible-local
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86881
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment #6 from Christophe Lyon ---
I see an error in the new testcase:
g++.dg/warn/pr86881.C -std=c++11: syntax error in target selector "c++11" for
" dg-do 2 compile { c++11 } "
[Bug testsuite/87339] [9 Regression] gcc.dg/warn-abs-1.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87339 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #4 from Christophe Lyon --- (In reply to r...@cebitec.uni-bielefeld.de from comment #3) > > --- Comment #2 from ktkachov at gcc dot gnu.org --- > > Fixed on arm and aarch64 with r264392. > > If you can confirm this fixes the other platforms please close this off. > > This didn't work on sparc: for both 32 and 64-bit: > for another: > > -FAIL: gcc.dg/warn-abs-1.c (test for warnings, line 48) > +FAIL: gcc.dg/warn-abs-1.c (test for warnings, line 49) > > i.e. the failure remains, just the line number changed due to the > addition of the dg-skip-if. Same on aarch64-linux-gnu.
[Bug tree-optimization/87309] [9 Regression] Spurious note: messages when building with -fopt-info-vec-optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87309 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-09-19 Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from David Malcolm --- Thanks; confirmed.
[Bug c++/87357] Bogus conversion with conversion function not detected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87357 Marek Polacek changed: What|Removed |Added Keywords||accepts-invalid Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-09-18 Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/87357] New: Bogus conversion with conversion function not detected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87357
Bug ID: 87357
Summary: Bogus conversion with conversion function not detected
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mpolacek at gcc dot gnu.org
Target Milestone: ---
[class.conv.fct]:
A conversion function is never used to convert a (possibly cv-qualified) object
to the (possibly cv-qualified) same object type (or a reference to it), to a
(possibly cv-qualified) base class of that type (or a reference to it), or to
(possibly cv-qualified) void.
But:
$ cat q.C
struct X {
operator X();
};
$ ./cc1plus -quiet q.C -Wconversion -Wall -Wextra -Wpedantic
[Bug target/86902] [9 Regression] ICE: in as_a, at machmode.h:356 at -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86902 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-09-18 Ever confirmed|0 |1 --- Comment #2 from Segher Boessenkool --- Ah, it's the checking flags. Confirmed.
[Bug target/86902] [9 Regression] ICE: in as_a, at machmode.h:356 at -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86902 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org --- Comment #1 from Segher Boessenkool --- This does not fail for me. Does it need some extra settings?
[Bug tree-optimization/87355] missed comparison optimizations (grep DFA, x86-64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87355 --- Comment #2 from Marc Glisse --- For f, this is a classic case where gcc canonicalizes n>=100 as n>99, and thus cannot as easily merge it with the other comparison n==100. For g, n >= 103 || n == 100 || n == 101 || n == 102 is replaced in the front-end with (n > 102 || n == 100) || (unsigned int) n + 4294967195 <= 1, that's a bit strange. Merging comparisons into a range test is normal, but why merge precisely tests 3 and 4? Inserting || n == 99 before n == 100 yields the even stranger ((n > 102 || n == 99) || (unsigned int) n + 4294967196 <= 1) || n == 102...
[Bug fortran/67202] Fortran FE should load scalar pass-by-reference intent-in arguments at the beginning of a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67202
Thomas Koenig changed:
What|Removed |Added
Status|WAITING |NEW
CC||tkoenig at gcc dot gnu.org
--- Comment #2 from Thomas Koenig ---
(In reply to Dominique d'Humieres from comment #1)
> Is there an easy way to check than a scalar pass-by-reference intent-in
> argument has been loaded at the beginning of the function?
Easiest to check the *.original dump.
If the code looks like
x (integer(kind=4) & restrict i, integer(kind=4) & restrict j)
{
*j = *i;
}
then it hasn't been done.
[Bug libstdc++/87135] [C++17] unordered containers violate iterator validity requirements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87135 --- Comment #2 from François Dumont --- Author: fdumont Date: Tue Sep 18 20:36:16 2018 New Revision: 264413 URL: https://gcc.gnu.org/viewcvs?rev=264413=gcc=rev Log: 2018-09-18 François Dumont PR libstdc++/87135 * src/c++11/hashtable_c++0x.cc: (_Prime_rehash_policy::_M_next_bkt): Return a prime no smaller than requested size, but not necessarily greater. (_Prime_rehash_policy::_M_need_rehash): Rehash only if target size is strictly greater than next resize threshold. * testsuite/23_containers/unordered_map/modifiers/reserve.cc: Adapt test to validate that there is no rehash as long as number of insertion is lower or equal to the reserved number of elements. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/src/c++11/hashtable_c++0x.cc trunk/libstdc++-v3/testsuite/23_containers/unordered_map/modifiers/reserve.cc
[Bug testsuite/87339] [9 Regression] gcc.dg/warn-abs-1.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87339 --- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #2 from ktkachov at gcc dot gnu.org --- > Fixed on arm and aarch64 with r264392. > If you can confirm this fixes the other platforms please close this off. This didn't work on sparc: for both 32 and 64-bit: for another: -FAIL: gcc.dg/warn-abs-1.c (test for warnings, line 48) +FAIL: gcc.dg/warn-abs-1.c (test for warnings, line 49) i.e. the failure remains, just the line number changed due to the addition of the dg-skip-if.
[Bug fortran/84109] ICE in adjustl on allocatable array of strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84109 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #4 from Paul Thomas --- Created attachment 44722 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44722=edit A fix for the PR I am sorry that this has taken so long. I have run out of time to commit this evening but will do so tomorrow night. Thanks for the report. Paul
[Bug fortran/29550] Optimize -fexternal-blas calls for conjg()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29550 --- Comment #16 from Thomas Koenig --- Author: tkoenig Date: Tue Sep 18 20:18:09 2018 New Revision: 264412 URL: https://gcc.gnu.org/viewcvs?rev=264412=gcc=rev Log: 2018-09-18 Thomas Koenig PR fortran/29550 * gfortran.h (gfc_expr): Add external_blas flag. * frontend-passes.c (matrix_case): Add case A2TB2T. (optimize_namespace): Handle flag_external_blas by calling call_external_blas. (get_array_inq_function): Add argument okind. If it is nonzero, use it as the kind of argument to be used. (inline_limit_check): Remove m_case argument, add limit argument instead. Remove assert about m_case. Set the limit for inlining from the limit argument. (matmul_lhs_realloc): Handle case A2TB2T. (inline_matmul_assign): Handle inline limit for other cases with two rank-two matrices. Remove no-op calls to inline_limit_check. (call_external_blas): New function. * trans-intrinsic.c (gfc_conv_intrinsic_funcall): Do not add argument to external BLAS if external_blas is already set. 2018-09-18 Thomas Koenig PR fortran/29550 * gfortran.dg/inline_matmul_13.f90: Adjust count for _gfortran_matmul. * gfortran.dg/inline_matmul_16.f90: Likewise. * gfortran.dg/promotion_2.f90: Add -fblas-matmul-limit=1. Scan for dgemm instead of dgemm_. Add call to random_number to make standard conforming. * gfortran.dg/matmul_blas_1.f90: New test. * gfortran.dg/matmul_bounds_14.f: New test. * gfortran.dg/matmul_bounds_15.f: New test. * gfortran.dg/matmul_bounds_16.f: New test. * gfortran.dg/blas_gemm_routines.f: New test / additional file for preceding tests. Added: trunk/gcc/testsuite/gfortran.dg/blas_gemm_routines.f trunk/gcc/testsuite/gfortran.dg/matmul_blas_1.f trunk/gcc/testsuite/gfortran.dg/matmul_bounds_14.f trunk/gcc/testsuite/gfortran.dg/matmul_bounds_15.f trunk/gcc/testsuite/gfortran.dg/matmul_bounds_16.f Modified: trunk/gcc/fortran/frontend-passes.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/testsuite/gfortran.dg/inline_matmul_13.f90 trunk/gcc/testsuite/gfortran.dg/inline_matmul_16.f90 trunk/gcc/testsuite/gfortran.dg/promotion_2.f90
[Bug fortran/87239] ICE in deferred-length string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87239 --- Comment #7 from Paul Thomas --- (In reply to Paul Thomas from comment #5) > (In reply to Dominique d'Humieres from comment #4) > > Duplicate of/ related to pr77325 and pr84109. > > PR84109 is completely different. The array descriptor 'elem_len' is being > set to zero during the allocation. I do apologize. It is not precisely the same but only insomuch as an intrinsic elemental function is involved, rather than an extrinsic. Cheers Paul
[Bug fortran/37131] inline matmul for small matrix sizes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37131 Bug 37131 depends on bug 29550, which changed state. Bug 29550 Summary: Optimize -fexternal-blas calls for conjg() https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29550 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug fortran/36854] [meta-bug] fortran front-end optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36854 Bug 36854 depends on bug 29550, which changed state. Bug 29550 Summary: Optimize -fexternal-blas calls for conjg() https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29550 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug fortran/29550] Optimize -fexternal-blas calls for conjg()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29550 Thomas Koenig changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #15 from Thomas Koenig --- Fixed, closing.
[Bug fortran/29550] Optimize -fexternal-blas calls for conjg()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29550 --- Comment #14 from Thomas Koenig --- Author: tkoenig Date: Tue Sep 18 19:59:46 2018 New Revision: 264411 URL: https://gcc.gnu.org/viewcvs?rev=264411=gcc=rev Log: 2018-09-18 Thomas Koenig PR fortran/29550 * gfortran.h (gfc_expr): Add external_blas flag. * frontend-passes.c (matrix_case): Add case A2TB2T. (optimize_namespace): Handle flag_external_blas by calling call_external_blas. (get_array_inq_function): Add argument okind. If it is nonzero, use it as the kind of argument to be used. (inline_limit_check): Remove m_case argument, add limit argument instead. Remove assert about m_case. Set the limit for inlining from the limit argument. (matmul_lhs_realloc): Handle case A2TB2T. (inline_matmul_assign): Handle inline limit for other cases with two rank-two matrices. Remove no-op calls to inline_limit_check. (call_external_blas): New function. * trans-intrinsic.c (gfc_conv_intrinsic_funcall): Do not add argument to external BLAS if external_blas is already set. 2018-09-18 Thomas Koenig PR fortran/29550 * gfortran.dg/inline_matmul_13.f90: Adjust count for _gfortran_matmul. * gfortran.dg/inline_matmul_16.f90: Likewise. * gfortran.dg/promotion_2.f90: Add -fblas-matmul-limit=1. Scan for dgemm instead of dgemm_. Add call to random_number to make standard conforming. * gfortran.dg/matmul_blas_1.f90: New test. * gfortran.dg/matmul_bounds_14.f: New test. * gfortran.dg/matmul_bounds_15.f: New test. * gfortran.dg/matmul_bounds_16.f: New test. * gfortran.dg/blas_gemm_routines.f: New test / additional file for preceding tests. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/testsuite/ChangeLog
[Bug fortran/85395] [F03] private clause contained in derived type acquires spurious scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85395 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from janus at gcc dot gnu.org --- Fixed on 9-trunk and 8-branch. Closing.
[Bug fortran/85395] [F03] private clause contained in derived type acquires spurious scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85395 --- Comment #10 from janus at gcc dot gnu.org --- Author: janus Date: Tue Sep 18 19:50:17 2018 New Revision: 264410 URL: https://gcc.gnu.org/viewcvs?rev=264410=gcc=rev Log: 2018-09-18 Janus Weil Backport from trunk PR fortran/85395 * decl.c (match_binding_attributes): Use correct default accessibility for procedure pointer components. 2018-09-18 Janus Weil Backport from trunk PR fortran/85395 * gfortran.dg/proc_ptr_comp_52.f90: New test case. Added: branches/gcc-8-branch/gcc/testsuite/gfortran.dg/proc_ptr_comp_52.f90 Modified: branches/gcc-8-branch/gcc/fortran/ChangeLog branches/gcc-8-branch/gcc/fortran/decl.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug fortran/87239] ICE in deferred-length string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87239 --- Comment #6 from Paul Thomas --- Author: pault Date: Tue Sep 18 19:35:53 2018 New Revision: 264409 URL: https://gcc.gnu.org/viewcvs?rev=264409=gcc=rev Log: 2018-09-18 Paul Thomas PR fortran/87239 * trans-expr.c (gfc_trans_assignment_1): The rse.pre for the assignment of deferred character elemental function results to a realocatable lhs must not be added to the exterior block but must go to the loop body. 2018-09-18 Paul Thomas PR fortran/87239 * gfortran.dg/elemental_function_2.f90 : New test. Added: trunk/gcc/testsuite/gfortran.dg/elemental_function_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog
[Bug libstdc++/87356] Enum members are missing in std::filesystem::perms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87356 Christian Hoff changed: What|Removed |Added Resolution|INVALID |FIXED --- Comment #3 from Christian Hoff --- I see. Thanks a lot for the fast feedback, that was really helpful!
[Bug libstdc++/87356] Enum members are missing in std::filesystem::perms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87356 --- Comment #2 from Jonathan Wakely --- See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0492r2.html#Late37 for the change to the spec that happened post-P0218R1.
[Bug libstdc++/87356] Enum members are missing in std::filesystem::perms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87356 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Jonathan Wakely --- (In reply to Christian Hoff from comment #0) > The standard that defines these enum members can be found here: > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0218r1.html#enum. > perms That's not the standard. The final C++17 standard doesn't have those enumerators, it uses the new std::filesystem::perm_options enumeration type instead.
[Bug libstdc++/87356] New: Enum members are missing in std::filesystem::perms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87356 Bug ID: 87356 Summary: Enum members are missing in std::filesystem::perms Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: christian_hoff at gmx dot net Target Milestone: --- The enumeration std::filesystem::perms (introduced with C++17 and available since GCC 8.0) is missing the following enum members: * add_perms * remove_perms * resolve_symlinks Other enum members are all there, but these three are missing (even though they are defined in the C++17 standard). I confirmed this by looking at the file "/usr/include/c++/8/bits/fs_fwd.h" of my GCC 8.2.0 installation. The standard that defines these enum members can be found here: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0218r1.html#enum.perms Please fix this issue.
[Bug fortran/86830] [8/9 Regression] Contiguous array pointer function result not recognized as contiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86830 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from janus at gcc dot gnu.org --- Fixed on 9-trunk and 8-branch. Closing. Thanks for the report!
[Bug fortran/86830] [8/9 Regression] Contiguous array pointer function result not recognized as contiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86830 --- Comment #6 from janus at gcc dot gnu.org --- Author: janus Date: Tue Sep 18 19:16:24 2018 New Revision: 264407 URL: https://gcc.gnu.org/viewcvs?rev=264407=gcc=rev Log: 2018-09-18 Janus Weil Backport from trunk PR fortran/86830 * expr.c (gfc_is_simply_contiguous): Handle type-bound procedure calls with non-polymorphic objects. 2018-09-18 Janus Weil Backport from trunk PR fortran/86830 * gfortran.dg/typebound_call_30.f90: New test case. Added: branches/gcc-8-branch/gcc/testsuite/gfortran.dg/typebound_call_30.f90 Modified: branches/gcc-8-branch/gcc/fortran/ChangeLog branches/gcc-8-branch/gcc/fortran/expr.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug tree-optimization/87355] missed comparison optimizations (grep DFA, x86-64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87355 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Component|target |tree-optimization Severity|normal |enhancement
[Bug target/87355] missed comparison optimizations (grep DFA, x86-64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87355 --- Comment #1 from eggert at cs dot ucla.edu --- Created attachment 44721 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44721=edit Assembly-language output of 'gcc -O2 -S t.c'
[Bug target/87355] New: missed comparison optimizations (grep DFA, x86-64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87355 Bug ID: 87355 Summary: missed comparison optimizations (grep DFA, x86-64) Product: gcc Version: 8.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: eggert at cs dot ucla.edu Target Milestone: --- Created attachment 44720 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44720=edit source code illustrating missed optimizations I found this when attempting to tune grep's DFA code on x86-64, and simplified the issue to the attached source code t.c which defines two functions f and g that are logically equivalent, and which can both be implemented via a single machine-language comparison to THRESHOLD. However, GCC generates two comparisons for f and three comparisons for g, as shown in the attached assembly-language file t.s generated by 'gcc -O2 -S t.c'. I am running Fedora 28 x86-64 with 8.1.1 20180712 (Red Hat 8.1.1-5). I'm not sure whether this problem is limited to x86-64 or is more general, and for now am labeling its component as 'target'.
[Bug fortran/85954] [8/9 Regression] ICE in make_ssa_name_fn, at tree-ssanames.c:266
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85954 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Paul Thomas --- Fixed on both branches. Many thanks for the report. Paul
[Bug fortran/87336] [8/9 regression] wrong output for pointer dummy assiocated to target actual argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87336 --- Comment #3 from Paul Thomas --- Author: pault Date: Tue Sep 18 17:58:20 2018 New Revision: 264405 URL: https://gcc.gnu.org/viewcvs?rev=264405=gcc=rev Log: 2018-09-18 Paul Thomas PR fortran/87336 * trans-array.c (gfc_get_array_span): Try to get the element length of incomplete types. Return NULL_TREE otherwise. (gfc_conv_expr_descriptor): Only set the 'span' field if the above does not return NULL_TREE. Set 'span' field if possible for all new descriptors. 2018-09-18 Paul Thomas PR fortran/87336 * gfortran.dg/pointer_array_10.f90 : New test. * gfortran.dg/assign_10.f90 : Increase 'parm' count to 20. * gfortran.dg/transpose_optimization_2.f90 : Increase 'parm' count to 72. Added: trunk/gcc/testsuite/gfortran.dg/pointer_array_10.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/assign_10.f90 trunk/gcc/testsuite/gfortran.dg/transpose_optimization_2.f90
[Bug fortran/85954] [8/9 Regression] ICE in make_ssa_name_fn, at tree-ssanames.c:266
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85954 --- Comment #8 from Paul Thomas --- Author: pault Date: Tue Sep 18 17:54:20 2018 New Revision: 264404 URL: https://gcc.gnu.org/viewcvs?rev=264404=gcc=rev Log: 2018-09-18 Paul Thomas PR fortran/85954 * resolve.c (resolve_assoc_var): If the target expression is a deferred charlen dummy and the associate name shares the charlen, generate a new one. Make sure that new charlens are in the namespace list so that they get cleaned up. * trans-array.c (gfc_is_reallocatable_lhs): Associate names are not reallocatable. * trans-decl.c (gfc_get_symbol_decl): Put deferred character length dummy and result arrays on the deferred initialization list so that the variable length arrays can be correctly dealt with. * trans-expr.c (gfc_conv_string_length): Return if 'expr' is NULL rather than ICEing. 2018-09-18 Paul Thomas PR fortran/85954 * gfortran.dg/deferred_character_21.f90 : New test. Added: branches/gcc-8-branch/gcc/testsuite/gfortran.dg/deferred_character_21.f90 Modified: branches/gcc-8-branch/gcc/fortran/ChangeLog branches/gcc-8-branch/gcc/fortran/resolve.c branches/gcc-8-branch/gcc/fortran/trans-array.c branches/gcc-8-branch/gcc/fortran/trans-decl.c branches/gcc-8-branch/gcc/fortran/trans-expr.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug c++/67491] [meta-bug] concepts issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 Bug 67491 depends on bug 85065, which changed state. Bug 85065 Summary: [concepts] ICE with invalid use of a concept https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85065 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/85065] [concepts] ICE with invalid use of a concept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85065 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot gnu.org Target Milestone|--- |9.0 --- Comment #3 from Paolo Carlini --- Fixed.
[Bug c++/85065] [concepts] ICE with invalid use of a concept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85065 --- Comment #2 from paolo at gcc dot gnu.org --- Author: paolo Date: Tue Sep 18 16:35:27 2018 New Revision: 264402 URL: https://gcc.gnu.org/viewcvs?rev=264402=gcc=rev Log: /cp 2018-09-18 Paolo Carlini PR c++/85065 * cp-tree.h (NON_ERROR): New. * pt.c (auto_hash::hash): Use it. (do_auto_deduction): Likewise. /testsuite 2018-09-18 Paolo Carlini PR c++/85065 * g++.dg/concepts/pr85065.C: New. Added: trunk/gcc/testsuite/g++.dg/concepts/pr85065.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/86882] [9 Regression] ICE in reg_overlap_mentioned_p, at rtlanal.c:1873
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86882 Segher Boessenkool changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Segher Boessenkool --- Fixed on trunk and 8; closing as fixed.
[Bug rtl-optimization/86882] [9 Regression] ICE in reg_overlap_mentioned_p, at rtlanal.c:1873
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86882 --- Comment #9 from Segher Boessenkool --- Author: segher Date: Tue Sep 18 16:24:58 2018 New Revision: 264401 URL: https://gcc.gnu.org/viewcvs?rev=264401=gcc=rev Log: Backport PR86882 fix to 8 PR rtl-optimization/86882 * rtlanal.c (reg_overlap_mentioned_p): Handle CLOBBER. Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/rtlanal.c
[Bug rtl-optimization/86882] [9 Regression] ICE in reg_overlap_mentioned_p, at rtlanal.c:1873
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86882 --- Comment #8 from Segher Boessenkool --- Author: segher Date: Tue Sep 18 16:19:56 2018 New Revision: 264400 URL: https://gcc.gnu.org/viewcvs?rev=264400=gcc=rev Log: Handle CLOBBER in reg_overlap_mentioned_p (PR86882) Combine will put CLOBBER (with a non-void mode) anywhere in a pattern to poison it. reg_overlap_mentioned_p did not handle this. This patch fixes that. PR rtl-optimization/86882 * rtlanal.c (reg_overlap_mentioned_p): Handle CLOBBER. Modified: trunk/gcc/ChangeLog trunk/gcc/rtlanal.c
[Bug fortran/87341] gfortran can not link executables: _edata: invalid version 21 (max 4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87341 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |MOVED --- Comment #15 from H.J. Lu --- (In reply to mi+gcc from comment #14) > (In reply to H.J. Lu from comment #13) > > Please try binutils 2.31 branch from: > > > > https://sourceware.org/git/?p=binutils-gdb.git;a=shortlog;h=refs/heads/ > > binutils-2_31-branch > > I'm sorry, I can not do that at this time -- I need to deliver the software > for my employer and rebuilding the gcc suit with --disable-gold provides a > work-around. > > I think, this bug-report -- against the compiler suit neither working with > the latest release of binutils, nor warning about it -- ought to remain open > for reasons I put forth in comment#4. > > The underlying problem with binutils deserves its own ticket, as Andrew > suggests in comment#3. I think, I've given enough information for anyone to > be able to reproduce the problem: > As I said, the problem is fixed on binutils 2.31 branch.
[Bug fortran/87341] gfortran can not link executables: _edata: invalid version 21 (max 4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87341 --- Comment #14 from mi+gcc at aldan dot algebra.com --- (In reply to H.J. Lu from comment #13) > Please try binutils 2.31 branch from: > > https://sourceware.org/git/?p=binutils-gdb.git;a=shortlog;h=refs/heads/ > binutils-2_31-branch I'm sorry, I can not do that at this time -- I need to deliver the software for my employer and rebuilding the gcc suit with --disable-gold provides a work-around. I think, this bug-report -- against the compiler suit neither working with the latest release of binutils, nor warning about it -- ought to remain open for reasons I put forth in comment#4. The underlying problem with binutils deserves its own ticket, as Andrew suggests in comment#3. I think, I've given enough information for anyone to be able to reproduce the problem: 1. Build the gcc suit with the configure-arguments provided 2. Attempt to use the newly-built gfortran to build a FORTRAN program: PRINT *, "Hello World!" END I could create this ticket for you, if you insist, but you should be able to reproduce the problem yourself now. Thank you.
[Bug c++/87340] Stack overflow problem for c++filt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87340 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #5 from Martin Sebor --- (In reply to Martin Liška from comment #3) > Then it would deserve something like segfault-on-invalid-input :) > Or should I use ice-on-invalid-code? Let's use ice-on-invalid. Otherwise the two will end up being used interchangeably over time.
[Bug c++/86881] [8, 9 regression] tree check fail with flag Wshadow-compatible-local
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86881 Nathan Sidwell changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Nathan Sidwell --- Fixed trunk r264391. Fixed gcc-8 r264396.
[Bug c++/85137] [concepts] ICE with undeclared concept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85137 Paolo Carlini changed: What|Removed |Added Status|NEW |ASSIGNED CC|paolo.carlini at oracle dot com| Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com --- Comment #1 from Paolo Carlini --- Mine.
[Bug c++/86881] [8, 9 regression] tree check fail with flag Wshadow-compatible-local
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86881 --- Comment #4 from Nathan Sidwell --- Author: nathan Date: Tue Sep 18 15:06:35 2018 New Revision: 264396 URL: https://gcc.gnu.org/viewcvs?rev=264396=gcc=rev Log: [PATCH c++/86881] -Wshadow-local-compatible ICE https://gcc.gnu.org/ml/gcc-patches/2018-09/msg00984.html PR c++/86881 cp/ * name-lookup.c (check_local_shadow): Ignore auto types. testsuite/ * g++.dg/warn/pr86881.C: New. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/warn/pr86881.C Modified: branches/gcc-8-branch/gcc/cp/ChangeLog branches/gcc-8-branch/gcc/cp/name-lookup.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug fortran/87341] gfortran can not link executables: _edata: invalid version 21 (max 4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87341 --- Comment #13 from H.J. Lu --- (In reply to mi+gcc from comment #12) > (In reply to H.J. Lu from comment #11) > > Please show the output of: > > > > $ objdump -T > > /prod/pfe/local/lib/gcc/x86_64-pc-linux-gnu/8/../../../../lib64/libgfortran. > > so | grep corrupt > > Neither the stock /usr/bin/objdump nor the newer /prod/pfe/local/bin/objdump > report any corruption (used grep -i just in case). Please try binutils 2.31 branch from: https://sourceware.org/git/?p=binutils-gdb.git;a=shortlog;h=refs/heads/binutils-2_31-branch
[Bug target/87354] New: x86-64: 16- and 32-byte register variables cannot be put in XMM16/YMM16 and up without -mavx512vl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87354
Bug ID: 87354
Summary: x86-64: 16- and 32-byte register variables cannot be
put in XMM16/YMM16 and up without -mavx512vl
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jbeulich at novell dot com
Target Milestone: ---
The same issue had been present in gas, but was corrected by commit 6e041cf4b0:
YMM (and of course also XMM) registers can certainly be used with AVX512F
alone, just that the set of insns is pretty limited. I realize that making this
work may not be a trivial change, as assumptions to this effect appear to be
made all over the place, but this code should imo compile (and assemble) fine
with just -mavx512f, while currently only the first function compiles without
error (QI mode vectors have been used just for simplicity and to make things
look reasonably uniform):
asm(".arch generic64");
asm(".arch .avx512f");
typedef char __attribute__((vector_size(64))) v64qi_t;
typedef char __attribute__((vector_size(16))) v16qi_t;
typedef char __attribute__((vector_size(32))) v32qi_t;
v64qi_t test512(v64qi_t x) {
register v64qi_t y asm("zmm16");
asm("vmovdqa32 %1,%0" : "=v" (y) : "v" (x));
return y;
}
v16qi_t test128(v64qi_t x) {
register v16qi_t y asm("xmm16");
asm("vpmovqw %1,%0" : "=v" (y) : "v" (x));
return y;
}
v32qi_t test256(v64qi_t x) {
register v32qi_t y asm("ymm16");
asm("vpmovqd %1,%0" : "=v" (y) : "v" (x));
return y;
}
[Bug fortran/87341] gfortran can not link executables: _edata: invalid version 21 (max 4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87341 --- Comment #12 from mi+gcc at aldan dot algebra.com --- (In reply to H.J. Lu from comment #11) > Please show the output of: > > $ objdump -T > /prod/pfe/local/lib/gcc/x86_64-pc-linux-gnu/8/../../../../lib64/libgfortran. > so | grep corrupt Neither the stock /usr/bin/objdump nor the newer /prod/pfe/local/bin/objdump report any corruption (used grep -i just in case).
[Bug fortran/87341] gfortran can not link executables: _edata: invalid version 21 (max 4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87341 --- Comment #11 from H.J. Lu --- (In reply to mi+gcc from comment #10) > (In reply to mi+gcc from comment #9) > > Is this it, for example: > > > > https://sourceware.org/ml/binutils/2018-08/msg00227.html > > Applied the patch to the 2.31 release, rebuilt/reinstalled binutils -- > problem is still here... Please show the output of: $ objdump -T /prod/pfe/local/lib/gcc/x86_64-pc-linux-gnu/8/../../../../lib64/libgfortran.so | grep corrupt
[Bug other/87353] gcc man page formatting issue due to leading spaces in .texi contents
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87353 --- Comment #5 from Jonathan Wakely --- Author: redi Date: Tue Sep 18 14:19:55 2018 New Revision: 264395 URL: https://gcc.gnu.org/viewcvs?rev=264395=gcc=rev Log: PR other/87353 fix formatting and grammar in manual The changes to invoke.texi in r242433 left some unwanted spaces that texi2pod.pl interprets as verbatim formatting. There are also some grammatical errors due to the removal of references to GCJ, where the G++ driver is referred to in the plural. PR other/87353 * doc/invoke.texi (Link Options): Fix formatting and grammar. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/invoke.texi
[Bug other/87353] gcc man page formatting issue due to leading spaces in .texi contents
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87353 Jonathan Wakely changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org --- Comment #4 from Jonathan Wakely --- Fixed on trunk so far, branches to follow.
[Bug fortran/87341] gfortran can not link executables: _edata: invalid version 21 (max 4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87341 --- Comment #10 from mi+gcc at aldan dot algebra.com --- (In reply to mi+gcc from comment #9) > Is this it, for example: > > https://sourceware.org/ml/binutils/2018-08/msg00227.html Applied the patch to the 2.31 release, rebuilt/reinstalled binutils -- problem is still here...
[Bug testsuite/87339] [9 Regression] gcc.dg/warn-abs-1.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87339 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org --- Comment #2 from ktkachov at gcc dot gnu.org --- Fixed on arm and aarch64 with r264392. If you can confirm this fixes the other platforms please close this off.
[Bug other/87353] gcc man page formatting issue due to leading spaces in .texi contents
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87353 --- Comment #3 from Jonathan Wakely --- This was introduced by r242433 https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/doc/invoke.texi?limit_changes=0=242433=242432=242433
[Bug target/87104] missed &, == optimization makes Emacs ~0.4% slower on x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87104 pipcet at gmail dot com changed: What|Removed |Added Attachment #44617|0 |1 is obsolete|| --- Comment #14 from pipcet at gmail dot com --- Created attachment 44719 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44719=edit WIP patch Okay, I've run into a few issues: 1. temacs run time changes unpredictably based on the configuration data, because of find_string_data_in_pure. 2. My CPU fuses "cmp" and a conditional branch and "test" and a conditional branch, but not "and" and a conditional branch. So we were optimizing a three-insn two-uop sequence into a two-insn two-uop sequence, and I was not seeing any performance improvement. 3. The code size changes sometimes cause branches to be mispredicted much more often for no apparent reason. I've worked around (1) and (2), by disabling find_string_data_in_pure() and making the peephole rule that turned "test" into "and" conditional on CPU type. Now I'm seeing a consistent performance improvement (as well as fewer instructions, fewer uops, and more fused branches) for Perl and Emacs.
[Bug other/87353] gcc man page formatting issue due to leading spaces in .texi contents
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87353 --- Comment #2 from Jonathan Wakely --- Also, "Therefore, the G++ and driver" is nonsense.
[Bug c++/86881] [8, 9 regression] tree check fail with flag Wshadow-compatible-local
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86881 --- Comment #3 from Nathan Sidwell --- Author: nathan Date: Tue Sep 18 13:52:30 2018 New Revision: 264391 URL: https://gcc.gnu.org/viewcvs?rev=264391=gcc=rev Log: [PATCH c++/86881] -Wshadow-local-compatible ICE https://gcc.gnu.org/ml/gcc-patches/2018-09/msg00984.html PR c++/86881 cp/ * name-lookup.c (check_local_shadow): Ignore auto types. testsuite/ * g++.dg/warn/pr86881.C: New. Added: trunk/gcc/testsuite/g++.dg/warn/pr86881.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/name-lookup.c trunk/gcc/testsuite/ChangeLog
[Bug other/87353] gcc man page formatting issue due to leading spaces in .texi contents
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87353 Jonathan Wakely changed: What|Removed |Added Keywords||documentation Status|UNCONFIRMED |NEW Last reconfirmed||2018-09-18 Ever confirmed|0 |1
[Bug fortran/87341] gfortran can not link executables: _edata: invalid version 21 (max 4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87341 --- Comment #9 from mi+gcc at aldan dot algebra.com --- > I said binutils 2.31 branch, not 2.31 release. The work I'm doing is meant for eventual production use. The company has swallowed the use of free software, but using _unreleased_ versions may be too much. Is there a particular patch, you want me to apply to 2.31 release? I could do that... Is this it, for example: https://sourceware.org/ml/binutils/2018-08/msg00227.html ?
[Bug fortran/87341] gfortran can not link executables: _edata: invalid version 21 (max 4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87341 --- Comment #8 from H.J. Lu --- (In reply to mi+gcc from comment #7) > (In reply to H.J. Lu from comment #6) > > This sounds like > > > > https://sourceware.org/bugzilla/show_bug.cgi?id=23499 > > > > Please try binutils 2.31 branch. > > Actually, I have binutils-2.31 already -- the /usr/bin/as, that comes with > RHEL6, does not understand the AVX2 instructions, so I had to build binutils > of my own, and, of course, used the latest available: > > % /prod/pfe/local/bin/ld -v > GNU ld (GNU Binutils) 2.31 > > and the ld used by gfortran (see the verbose output I posted) is a hardlink > to the above: > > % > /prod/pfe/local/lib/gcc/x86_64-pc-linux-gnu/8/../../../../x86_64-pc-linux- > gnu/bin/ld > GNU ld (GNU Binutils) 2.31 I said binutils 2.31 branch, not 2.31 release.
[Bug fortran/87341] gfortran can not link executables: _edata: invalid version 21 (max 4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87341 mi+gcc at aldan dot algebra.com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|MOVED |--- --- Comment #7 from mi+gcc at aldan dot algebra.com --- (In reply to H.J. Lu from comment #6) > This sounds like > > https://sourceware.org/bugzilla/show_bug.cgi?id=23499 > > Please try binutils 2.31 branch. Actually, I have binutils-2.31 already -- the /usr/bin/as, that comes with RHEL6, does not understand the AVX2 instructions, so I had to build binutils of my own, and, of course, used the latest available: % /prod/pfe/local/bin/ld -v GNU ld (GNU Binutils) 2.31 and the ld used by gfortran (see the verbose output I posted) is a hardlink to the above: % /prod/pfe/local/lib/gcc/x86_64-pc-linux-gnu/8/../../../../x86_64-pc-linux-gnu/bin/ld GNU ld (GNU Binutils) 2.31
[Bug middle-end/63155] [6/7/8/9 Regression] memory hog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63155 --- Comment #26 from Richard Biener --- Author: rguenth Date: Tue Sep 18 13:26:05 2018 New Revision: 264388 URL: https://gcc.gnu.org/viewcvs?rev=264388=gcc=rev Log: 2018-09-18 Richard Biener PR middle-end/63155 * tree-ssa-coalesce.c (tree_int_map_hasher): Remove. (compute_samebase_partition_bases): Likewise. (coalesce_ssa_name): Always use compute_optimized_partition_bases. (gimple_can_coalesce_p): Simplify. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-coalesce.c
[Bug fortran/87341] gfortran can not link executables: _edata: invalid version 21 (max 4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87341 H.J. Lu changed: What|Removed |Added See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=23499 --- Comment #6 from H.J. Lu --- This sounds like https://sourceware.org/bugzilla/show_bug.cgi?id=23499 Please try binutils 2.31 branch.
[Bug c++/87335] The stack overflow in function cplus_demangle_type in cp-demangle.c:2565 (c++filt -t)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87335 --- Comment #9 from Cheng Wen --- (In reply to Jonathan Wakely from comment #8) Hi Jonathan, I debugged with this POC again. I still think it's a problem. I will show you the debug process as follow. > $ gdb ./c++filt > Reading symbols from ./c++filt...done. > (gdb) set args -t < POC-t > (gdb) b cp-demangle.c:2565 > Breakpoint 1 at 0x8d5227: file ./cp-demangle.c, line 2565. > (gdb) start > (gdb) c > Continuing. > Breakpoint 1, cplus_demangle_type (di=0x7fffd560) at ./cp-demangle.c:2565 > 2565 cplus_demangle_type (di), NULL); > (gdb) c > Continuing. > Breakpoint 1, cplus_demangle_type (di=0x7fffd560) at ./cp-demangle.c:2565 > 2565 cplus_demangle_type (di), NULL); > ... > ... > ... > (gdb) c > Continuing. > Breakpoint 1, cplus_demangle_type (di=0x7fffd560) at ./cp-demangle.c:2565 > 2565 cplus_demangle_type (di), NULL); > (gdb) bt > #0 cplus_demangle_type (di=0x7fffd560) at ./cp-demangle.c:2565 > #1 0x008d523d in cplus_demangle_type (di=0x7fffd560) at > ./cp-demangle.c:2565 > #2 0x008d523d in cplus_demangle_type (di=0x7fffd560) at > ./cp-demangle.c:2565 > #3 0x008d523d in cplus_demangle_type (di=0x7fffd560) at > ./cp-demangle.c:2565 > #4 0x008d523d in cplus_demangle_type (di=0x7fffd560) at > ./cp-demangle.c:2565 > ... > ... > ... > #456 0x008d523d in cplus_demangle_type (di=0x7fffd560) at > ./cp-demangle.c:2565 > #457 0x008d523d in cplus_demangle_type (di=0x7fffd560) at > ./cp-demangle.c:2565 > #458 0x008dd318 in d_demangle_callback (mangled=0x18b2e40 > 'P' ..., options=283, > callback=0x8dc110 , > opaque=0x7fffd860) at ./cp-demangle.c:6245 > #459 0x008dc84f in d_demangle (mangled=0x18b2e40 'P' > ..., options=283, > palc=0x7fffd9e0) at ./cp-demangle.c:6299 > #460 0x008dc696 in cplus_demangle_v3 (mangled=0x18b2e40 > 'P' ..., options=283) > at ./cp-demangle.c:6456 > #461 0x008b1cf4 in cplus_demangle (mangled=0x18b2e40 > 'P' ..., options=27) > at ./cplus-dem.c:880 > #462 0x00517676 in demangle_it (mangled_name=0x18b2e40 > 'P' ...) at cxxfilt.c:62 > #463 0x0051726a in main (argc=2, argv=0x7fffe008) at cxxfilt.c:276 Using gdb to debug it. I set a breakpoint in cp-demangle.c:2565. After reaching this breakpoint for any time. You can see the stack backtrace. This will consume a lot of stack memory. (Caution: the command such as "gdb --args ./c++filt -t < $POC" is not valid. Please use "gdb ./c++filt", then "set args -t < $POC") Thanks Cheng Wen
[Bug other/87353] gcc man page formatting issue due to leading spaces in .texi contents
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87353 --- Comment #1 from Vincent Lefèvre --- The bug may be in contrib/texi2pod.pl as the following pod text is generated: Therefore, the G++ and driver automatically adds B<-shared-libgcc> whenever you build a shared library or a main executable, because C++ programs typically use exceptions, so this is the right thing to do. and the pod specification says: "A verbatim paragraph is distinguished by having its first character be a space or a tab."
[Bug other/87353] New: gcc man page formatting issue due to leading spaces in .texi contents
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87353
Bug ID: 87353
Summary: gcc man page formatting issue due to leading spaces in
.texi contents
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
The gcc(1) man page (gcc.1) shows as:
Therefore, the G++ and driver automatically adds -shared-libgcc
whenever you build a shared library or a main executable, because
C++
programs typically use exceptions, so this is the right thing to
do.
This is due to gcc/doc/invoke.texi containing leading spaces:
Therefore, the G++ and driver automatically adds @option{-shared-libgcc}
whenever you build a shared library or a main executable, because C++
programs typically use exceptions, so this is the right thing to do.
Removing these spaces should solve the problem (I haven't checked other parts
of the manual), but AFAIK, such spaces are valid and do not yield any issue in
generated .info files. Thus the real bug could be in conversion utilities
(contrib/texi2pod.pl, provided by GCC, or pod2man).
[Bug fortran/87352] New: Large stack usage with new gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87352 Bug ID: 87352 Summary: Large stack usage with new gfortran Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jeremy at jeremysanders dot net Target Milestone: --- Created attachment 44718 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44718=edit Affected module and example main program With gcc/gfortran 7.3 and 8.2, creation of a variable in the main program with a particular type defined in a module (attached) leads to a segfault due to very large stack usage. This worked on gcc 4.8.4 and earlier versions. In addition compilation of the module creates an object file which is x1 times larger than for earlier gcc versions (200MB vs 25KB). With optimization (-O2), the compilation time is several minutes, rather than less than a second. Instructions for compilation: $ gfortran -ffixed-line-length-none -ffree-line-length-none -g -O2 -o testcomb testcomb.f90 testcomb.f90:1303:0: end module testmodule note: variable tracking size limit exceeded with -fvar-tracking-assignments, retrying without $ ./testcomb $ gdb ./testcomb GNU gdb (Ubuntu 8.1-0ubuntu3) 8.1.0.20180409-git ... (gdb) run Starting program: /home/jsanders/tmp/foo/testcomb Program received signal SIGSEGV, Segmentation fault. testprog () at testcomb.f90:1309 1309 type(instlist_type),target:: instlist It works if the stack is increased to 819200. This problem is seen using Ubuntu Bionic (18.04) on x86-64, using the built-in gcc (7.3.0), or a self-compiled version (8.2.0) with no special build options.
[Bug preprocessor/87351] misleading error message: missing binary operator before token "("
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87351 Jonathan Wakely changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2018-09-18 Ever confirmed|0 |1
[Bug target/87330] ICE in scan_rtx_reg, at regrename.c:1097
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87330 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed|2018-09-17 00:00:00 |2018-09-18 Assignee|unassigned at gcc dot gnu.org |siddhesh at gotplt dot org Ever confirmed|0 |1 --- Comment #3 from ktkachov at gcc dot gnu.org --- Assigning.
[Bug rtl-optimization/86882] [9 Regression] ICE in reg_overlap_mentioned_p, at rtlanal.c:1873
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86882 Segher Boessenkool changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |segher at gcc dot gnu.org --- Comment #7 from Segher Boessenkool --- I have a patch.
[Bug bootstrap/87338] gcc 8.2 fails to bootstrap on ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87338 --- Comment #3 from Jason Duerstock --- Yes. From the Debian build log: https://buildd.debian.org/status/fetch.php?pkg=gcc-7=ia64=7.3.0-29=1536161281=0
[Bug preprocessor/87351] New: misleading error message: missing binary operator before token "("
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87351
Bug ID: 87351
Summary: misleading error message: missing binary operator
before token "("
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
The error message
error: missing binary operator before token "("
from the preprocessor is misleading in general, as in most cases, it is not a
binary operator that is missing, but the error is due to the use of sizeof, a
cast, or a function-like macro that is not defined. The preprocessor could
either output a fixed error message that would reflect the most common
misusages, or try to guess what is wrong (like the use of sizeof or something
that looks like a cast).
For instance:
$ cat tst.c
#if sizeof(int) > 4
#endif
$ gcc-snapshot -E tst.c
# 1 "tst.c"
# 1 ""
# 1 ""
# 31 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 32 "" 2
# 1 "tst.c"
tst.c:1:11: error: missing binary operator before token "("
1 | #if sizeof(int) > 4
| ^
Some users can get confused. For instance, see:
*
https://stackoverflow.com/questions/21338385/what-does-the-compiler-error-missing-binary-operator-before-token-mean
*
https://cboard.cprogramming.com/c-programming/158452-error-missing-binary-operator-before-token.html
*
https://www.linuxquestions.org/questions/programming-9/missing-binary-operator-before-token-4175547706/
* https://forum.kde.org/viewtopic.php?f=269=128141
[Bug tree-optimization/87342] [9 Regression] ICE: verify_ssa failed (error: definition in block 10 does not dominate use in block 8)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87342 --- Comment #2 from Richard Biener --- Thanks, that's another case similar to PR87263 where we cannot use dominated_by_p_w_unex. But I think the error is in computation of max_rpo for BB 15 which is 6 instead of 13. Because we're supposed to mark the respective edges executable. Needs more thinking.
[Bug c++/54052] g++ takes excessive time in opt and generate phase; can lead to Segmentation Fault when not enough memory available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54052 Jonathan Wakely changed: What|Removed |Added Last reconfirmed|2017-08-22 00:00:00 |2018-9-18 CC|redi at gcc dot gnu.org| --- Comment #9 from Jonathan Wakely --- Compiles successfully using i686-pc-linux-gnu, but takes a long time. As I said, it's an unreasonably large expression (3883 lines!) so that's not surprising. Don't write silly code if you don't have enough memory to compile it. I tried compiling it with Clang and it crashes.
[Bug c++/87350] NULL-Pointer problem in cplus-dem.c when executing program c++filt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87350 --- Comment #4 from Cheng Wen --- Yes. One input test case is "_GLOBAL_$D$__tf30___0__". Another input test case is "__thunk_0__0__$__H1". I see that you can you can reproduce this error. Do you know the reason for this bug?
[Bug c++/87335] The stack overflow in function cplus_demangle_type in cp-demangle.c:2565 (c++filt -t)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87335 --- Comment #8 from Jonathan Wakely --- It still works for up to ten million characters: $ for i in `seq 1 10` ; do printf P ; done | /tmp/binutils/bin/c++filt -t ; echo PP $ for i in `seq 1 100` ; do printf P ; done | /tmp/binutils/bin/c++filt -t | wc 0 1 100 $ for i in `seq 1 1000` ; do printf P ; done | /tmp/binutils/bin/c++filt -t | wc 0 11000 $ for i in `seq 1 1` ; do printf P ; done | /tmp/binutils/bin/c++filt -t | wc 0 1 1 $ for i in `seq 1 10` ; do printf P ; done | /tmp/binutils/bin/c++filt -t | wc 0 1 10 $ for i in `seq 1 100` ; do printf P ; done | /tmp/binutils/bin/c++filt -t | wc 0 1 100 $ for i in `seq 1 1000` ; do printf P ; done | /tmp/binutils/bin/c++filt -t | wc 0 1 1000
[Bug c++/87335] The stack overflow in function cplus_demangle_type in cp-demangle.c:2565 (c++filt -t)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87335 --- Comment #7 from Cheng Wen --- (In reply to Jonathan Wakely from comment #6) Considering the memory size of different machines, maybe more 'P' is needed to trigger this bug in the input.
[Bug c++/87350] NULL-Pointer problem in cplus-dem.c when executing program c++filt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87350 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-09-18 Ever confirmed|0 |1 --- Comment #3 from Jonathan Wakely --- (In reply to Cheng Wen from comment #1) > Created attachment 44714 [details] > POC1 You've uploaded two complete HTML pages saved from github, but the mangled name that crash are just: _GLOBAL_$D$__tf30___0__ __thunk_0__0__$__H1 $ echo '_GLOBAL_$D$__tf30___0__' | /tmp/binutils/bin/c++filt ASAN:DEADLYSIGNAL = ==6977==ERROR: AddressSanitizer: SEGV on unknown address 0x (pc 0x7f5fbbb47f31 bp 0x7fff4a202c20 sp 0x7fff4a202398 T0) ==6977==The signal is caused by a READ memory access. ==6977==Hint: address points to the zero page. #0 0x7f5fbbb47f30 in __strlen_avx2 (/lib64/libc.so.6+0x155f30) #1 0x7f5fbbffd27b (/lib64/libasan.so.4+0x5127b) #2 0x497e34 in work_stuff_copy_to_from /home/jwakely/src/binutils-gdb/libiberty/cplus-dem.c:1345 #3 0x49cdd8 in iterate_demangle_function /home/jwakely/src/binutils-gdb/libiberty/cplus-dem.c:2731 #4 0x49d962 in demangle_prefix /home/jwakely/src/binutils-gdb/libiberty/cplus-dem.c:2971 #5 0x49d962 in internal_cplus_demangle /home/jwakely/src/binutils-gdb/libiberty/cplus-dem.c:1253 #6 0x498860 in cplus_demangle /home/jwakely/src/binutils-gdb/libiberty/cplus-dem.c:918 #7 0x402ea5 in demangle_it (/tmp/binutils/bin/c++filt+0x402ea5) #8 0x4037af in main (/tmp/binutils/bin/c++filt+0x4037af) #9 0x7f5fbba12fe9 in __libc_start_main (/lib64/libc.so.6+0x20fe9) #10 0x402d29 in _start (/tmp/binutils/bin/c++filt+0x402d29) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV (/lib64/libc.so.6+0x155f30) in __strlen_avx2 ==6977==ABORTING wraith:tmp$ echo '__thunk_0__0__$__H1' | /tmp/binutils/bin/c++filt ASAN:DEADLYSIGNAL = ==6981==ERROR: AddressSanitizer: SEGV on unknown address 0x (pc 0x00497f27 bp 0x7ffc897891e0 sp 0x7ffc89789170 T0) ==6981==The signal is caused by a READ memory access. ==6981==Hint: address points to the zero page. #0 0x497f26 in work_stuff_copy_to_from /home/jwakely/src/binutils-gdb/libiberty/cplus-dem.c:1358 #1 0x49cdd8 in iterate_demangle_function /home/jwakely/src/binutils-gdb/libiberty/cplus-dem.c:2731 #2 0x49d962 in demangle_prefix /home/jwakely/src/binutils-gdb/libiberty/cplus-dem.c:2971 #3 0x49d962 in internal_cplus_demangle /home/jwakely/src/binutils-gdb/libiberty/cplus-dem.c:1253 #4 0x498860 in cplus_demangle /home/jwakely/src/binutils-gdb/libiberty/cplus-dem.c:918 #5 0x402ea5 in demangle_it (/tmp/binutils/bin/c++filt+0x402ea5) #6 0x4037af in main (/tmp/binutils/bin/c++filt+0x4037af) #7 0x7ff5a9a18fe9 in __libc_start_main (/lib64/libc.so.6+0x20fe9) #8 0x402d29 in _start (/tmp/binutils/bin/c++filt+0x402d29) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV /home/jwakely/src/binutils-gdb/libiberty/cplus-dem.c:1358 in work_stuff_copy_to_from ==6981==ABORTING
[Bug gcov-profile/85871] g++.dg/gcov/gcov-8.C random failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85871 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||8.2.1 Resolution|--- |FIXED Summary|[8 Regression] |g++.dg/gcov/gcov-8.C random |g++.dg/gcov/gcov-8.C random |failures |failures| Known to fail|8.2.0 | --- Comment #14 from Martin Liška --- Fixed on all active branches.
[Bug c++/87335] The stack overflow in function cplus_demangle_type in cp-demangle.c:2565 (c++filt -t)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87335 --- Comment #6 from Jonathan Wakely --- (In reply to Cheng Wen from comment #5) > (In reply to Jonathan Wakely from comment #4) > > Are you sure you attached the right file? When I try to demangle the > > attachment it doesn't crash, the __cxa_demangle file returns -2, meaning the > > name is not valid. That seems like the right result. > > I have tried to reproduce this bug on different machines. > There are some questions to be confirmed. > > (1) Do you use the latest version of binutils(binutils-2.32/binutils-2.31)? > I downloaded the package from here. > https://www.gnu.org/software/binutils/ Built from the binutils-gdb git repo: $ /tmp/binutils/bin/c++filt -v GNU c++filt (GNU Binutils) 2.31.51.20180918 Copyright (C) 2018 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) any later version. This program has absolutely no warranty. > (2) Please confirm that you have used the option "-t". > The command should be "./c++filt -t < $POC" $ /tmp/binutils/bin/c++filt -t < POC-t | wc 0 1 26539 $ echo $? 0 > (3) Do you confirm this POC with address sanitizer? Yes it's linked to libasan $ ldd /tmp/binutils/bin/c++filt linux-vdso.so.1 (0x7fff0618b000) libasan.so.4 => /lib64/libasan.so.4 (0x7fc372241000) libdl.so.2 => /lib64/libdl.so.2 (0x7fc37203d000) libc.so.6 => /lib64/libc.so.6 (0x7fc371c87000) librt.so.1 => /lib64/librt.so.1 (0x7fc371a7f000) libpthread.so.0 => /lib64/libpthread.so.0 (0x7fc371861000) libstdc++.so.6 => /lib64/libstdc++.so.6 (0x7fc3714d9000) libm.so.6 => /lib64/libm.so.6 (0x7fc37118e000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7fc370f77000) /lib64/ld-linux-x86-64.so.2 (0x7fc3731f9000)
[Bug c++/87333] A stack overflow problem for c++filt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87333 --- Comment #4 from Cheng Wen --- Created attachment 44717 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44717=edit POC2 I have the new POC to add. Please use the “c++filt < $POC ” to reproduce the bug. Please check it and debug it. Thank you. POC2: https://github.com/ntu-sec/pocs/blob/master/binutils-aff4a119/crashes/so_cplus-dem.c:4960_2 The ASAN dumps the stack trace as follows on POC2: https://github.com/ntu-sec/pocs/blob/master/binutils-aff4a119/crashes/so_cplus-dem.c:4960_2.err.txt AddressSanitizer:DEADLYSIGNAL = ==24101==ERROR: AddressSanitizer: stack-overflow on address 0x7ffcd22d1fd8 (pc 0x00497287 bp 0x7ffcd22d2850 sp 0x7ffcd22d1fe0 T0) #0 0x497286 in __interceptor_strlen.part.30 (/home/hongxu/FOT/binutils/BUILD/install/bin/c++filt+0x497286) #1 0x8bdc7e in string_append /home/hongxu/FOT/binutils/BUILD/libiberty/../../libiberty/cplus-dem.c:4960:7 #2 0x8cb7f5 in demangle_args /home/hongxu/FOT/binutils/BUILD/libiberty/../../libiberty/cplus-dem.c:4578:7 #3 0x8cdff7 in demangle_nested_args /home/hongxu/FOT/binutils/BUILD/libiberty/../../libiberty/cplus-dem.c:4713:12 #4 0x8ad46a in do_type /home/hongxu/FOT/binutils/BUILD/libiberty/../../libiberty/cplus-dem.c:3719:9 #5 0x8cd8c6 in do_arg /home/hongxu/FOT/binutils/BUILD/libiberty/../../libiberty/cplus-dem.c:4332:8 ... ... ... #245 0x8cd8c6 in do_arg /home/hongxu/FOT/binutils/BUILD/libiberty/../../libiberty/cplus-dem.c:4332:8 #246 0x8cc7b4 in demangle_args /home/hongxu/FOT/binutils/BUILD/libiberty/../../libiberty/cplus-dem.c:4659:9 #247 0x8cdff7 in demangle_nested_args /home/hongxu/FOT/binutils/BUILD/libiberty/../../libiberty/cplus-dem.c:4713:12 #248 0x8ad46a in do_type /home/hongxu/FOT/binutils/BUILD/libiberty/../../libiberty/cplus-dem.c:3719:9 #249 0x8cd8c6 in do_arg /home/hongxu/FOT/binutils/BUILD/libiberty/../../libiberty/cplus-dem.c:4332:8 SUMMARY: AddressSanitizer: stack-overflow (/home/hongxu/FOT/binutils/BUILD/install/bin/c++filt+0x497286) in __interceptor_strlen.part.30 ==24101==ABORTING
[Bug c++/87333] A stack overflow problem for c++filt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87333 --- Comment #3 from Cheng Wen --- Created attachment 44716 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44716=edit POC1 I have the new POC to add. Please use the “c++filt < $POC ” to reproduce the bug. Please check it and debug it. Thank you. POC1: https://github.com/ntu-sec/pocs/blob/master/binutils-aff4a119/crashes/so_cplus-dem.c:4960_1 The ASAN dumps the stack trace as follows on POC1: https://github.com/ntu-sec/pocs/blob/master/binutils-aff4a119/crashes/so_cplus-dem.c:4960_1.err.txt AddressSanitizer:DEADLYSIGNAL = ==24028==ERROR: AddressSanitizer: stack-overflow on address 0x7ffd854a7e18 (pc 0x00497287 bp 0x7ffd854a8690 sp 0x7ffd854a7e20 T0) #0 0x497286 in __interceptor_strlen.part.30 (/home/hongxu/FOT/binutils/BUILD/install/bin/c++filt+0x497286) #1 0x8bdc7e in string_append /home/hongxu/FOT/binutils/BUILD/libiberty/../../libiberty/cplus-dem.c:4960:7 #2 0x8cb7f5 in demangle_args /home/hongxu/FOT/binutils/BUILD/libiberty/../../libiberty/cplus-dem.c:4578:7 #3 0x8cdff7 in demangle_nested_args /home/hongxu/FOT/binutils/BUILD/libiberty/../../libiberty/cplus-dem.c:4713:12 #4 0x8ad46a in do_type /home/hongxu/FOT/binutils/BUILD/libiberty/../../libiberty/cplus-dem.c:3719:9 #5 0x8cd8c6 in do_arg /home/hongxu/FOT/binutils/BUILD/libiberty/../../libiberty/cplus-dem.c:4332:8 ... ... ... #244 0x8ad46a in do_type /home/hongxu/FOT/binutils/BUILD/libiberty/../../libiberty/cplus-dem.c:3719:9 #245 0x8cd8c6 in do_arg /home/hongxu/FOT/binutils/BUILD/libiberty/../../libiberty/cplus-dem.c:4332:8 #246 0x8cc7b4 in demangle_args /home/hongxu/FOT/binutils/BUILD/libiberty/../../libiberty/cplus-dem.c:4659:9 #247 0x8cdff7 in demangle_nested_args /home/hongxu/FOT/binutils/BUILD/libiberty/../../libiberty/cplus-dem.c:4713:12 #248 0x8ad46a in do_type /home/hongxu/FOT/binutils/BUILD/libiberty/../../libiberty/cplus-dem.c:3719:9 #249 0x8cd8c6 in do_arg /home/hongxu/FOT/binutils/BUILD/libiberty/../../libiberty/cplus-dem.c:4332:8 SUMMARY: AddressSanitizer: stack-overflow (/home/hongxu/FOT/binutils/BUILD/install/bin/c++filt+0x497286) in __interceptor_strlen.part.30 ==24028==ABORTING
[Bug c++/80635] std::optional and bogus -Wmaybe-uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org, ||msebor at gcc dot gnu.org --- Comment #13 from Manuel López-Ibáñez --- This may be another case where it is worth it to print the inline stack AND silence a warning whose inline stack is within pragma GCC diagnostics. However, there seems to be another kind of missed optimization going on here.
[Bug c++/87335] The stack overflow in function cplus_demangle_type in cp-demangle.c:2565 (c++filt -t)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87335 --- Comment #5 from Cheng Wen --- (In reply to Jonathan Wakely from comment #4) > Are you sure you attached the right file? When I try to demangle the > attachment it doesn't crash, the __cxa_demangle file returns -2, meaning the > name is not valid. That seems like the right result. I have tried to reproduce this bug on different machines. There are some questions to be confirmed. (1) Do you use the latest version of binutils(binutils-2.32/binutils-2.31)? I downloaded the package from here. https://www.gnu.org/software/binutils/ (2) Please confirm that you have used the option "-t". The command should be "./c++filt -t < $POC" (3) Do you confirm this POC with address sanitizer?
[Bug c++/87340] Stack overflow problem for c++filt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87340 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-09-18 Ever confirmed|0 |1 --- Comment #4 from Jonathan Wakely --- The __cxa_demangle function returns 2 for each of these testcases, but the cplus_demangle function segfaults.
[Bug c++/87335] The stack overflow in function cplus_demangle_type in cp-demangle.c:2565 (c++filt -t)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87335 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-09-18 Ever confirmed|0 |1 --- Comment #4 from Jonathan Wakely --- Are you sure you attached the right file? When I try to demangle the attachment it doesn't crash, the __cxa_demangle file returns -2, meaning the name is not valid. That seems like the right result.
[Bug c++/87350] NULL-Pointer problem in cplus-dem.c when executing program c++filt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87350 --- Comment #2 from Cheng Wen --- Created attachment 44715 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44715=edit POC2
[Bug c++/87350] NULL-Pointer problem in cplus-dem.c when executing program c++filt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87350 --- Comment #1 from Cheng Wen --- Created attachment 44714 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44714=edit POC1
[Bug c++/87350] New: NULL-Pointer problem in cplus-dem.c when executing program c++filt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87350 Bug ID: 87350 Summary: NULL-Pointer problem in cplus-dem.c when executing program c++filt Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: wcventure at 126 dot com Target Milestone: --- Hi, Our fuzzer caught NULL-Pointer problems in c++filt of the latest binutils code base, those inputs will cause the segment faults and I have confirmed them with address sanitizer. Please use the “c++filt < $POC ” to reproduce the bug. Please check it and debug it. Thank you. The ASAN dumps the stack trace as follows on POC1: https://github.com/ntu-sec/pocs/blob/master/binutils-aff4a119/crashes/npd_r_cplus-dem.c:1345_1.err.txt AddressSanitizer:DEADLYSIGNAL = ==23610==ERROR: AddressSanitizer: SEGV on unknown address 0x (pc 0x7f67702435a1 bp 0x7ffe2a376680 sp 0x7ffe2a375e08 T0) ==23610==The signal is caused by a READ memory access. ==23610==Hint: address points to the zero page. #0 0x7f67702435a0 /build/glibc-OTsEL5/glibc-2.27/string/../sysdeps/x86_64/multiarch/strlen-avx2.S:59 #1 0x49728c in __interceptor_strlen.part.30 (/home/hongxu/FOT/binutils/BUILD/install/bin/c++filt+0x49728c) #2 0x8c9caa in work_stuff_copy_to_from /home/hongxu/FOT/binutils/BUILD/libiberty/../../libiberty/cplus-dem.c:1345:17 #3 0x8c553c in iterate_demangle_function /home/hongxu/FOT/binutils/BUILD/libiberty/../../libiberty/cplus-dem.c:2731:3 #4 0x8b77ec in demangle_prefix /home/hongxu/FOT/binutils/BUILD/libiberty/../../libiberty/cplus-dem.c:2971:14 #5 0x8b2d00 in internal_cplus_demangle /home/hongxu/FOT/binutils/BUILD/libiberty/../../libiberty/cplus-dem.c:1253:14 #6 0x8afe53 in cplus_demangle /home/hongxu/FOT/binutils/BUILD/libiberty/../../libiberty/cplus-dem.c:918:9 #7 0x513dd5 in demangle_it /home/hongxu/FOT/binutils/BUILD/binutils/../../binutils/cxxfilt.c:62:12 #8 0x5139c9 in main /home/hongxu/FOT/binutils/BUILD/binutils/../../binutils/cxxfilt.c:276:4 #9 0x7f67700d6b96 in __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310 #10 0x41a989 in _start (/home/hongxu/FOT/binutils/BUILD/install/bin/c++filt+0x41a989) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV /build/glibc-OTsEL5/glibc-2.27/string/../sysdeps/x86_64/multiarch/strlen-avx2.S:59 ==23610==ABORTING The ASAN dumps the stack trace as follows on POC2: https://github.com/ntu-sec/pocs/blob/master/binutils-aff4a119/crashes/npd_r_cplus-dem.c:1360_1.err.txt AddressSanitizer:DEADLYSIGNAL = ==23847==ERROR: AddressSanitizer: SEGV on unknown address 0x (pc 0x008ca218 bp 0x7ffe44bfad50 sp 0x7ffe44bfaa10 T0) ==23847==The signal is caused by a READ memory access. ==23847==Hint: address points to the zero page. #0 0x8ca217 in work_stuff_copy_to_from /home/hongxu/FOT/binutils/BUILD/libiberty/../../libiberty/cplus-dem.c:1360:25 #1 0x8c553c in iterate_demangle_function /home/hongxu/FOT/binutils/BUILD/libiberty/../../libiberty/cplus-dem.c:2731:3 #2 0x8b77ec in demangle_prefix /home/hongxu/FOT/binutils/BUILD/libiberty/../../libiberty/cplus-dem.c:2971:14 #3 0x8b2d00 in internal_cplus_demangle /home/hongxu/FOT/binutils/BUILD/libiberty/../../libiberty/cplus-dem.c:1253:14 #4 0x8afe53 in cplus_demangle /home/hongxu/FOT/binutils/BUILD/libiberty/../../libiberty/cplus-dem.c:918:9 #5 0x513dd5 in demangle_it /home/hongxu/FOT/binutils/BUILD/binutils/../../binutils/cxxfilt.c:62:12 #6 0x5139c9 in main /home/hongxu/FOT/binutils/BUILD/binutils/../../binutils/cxxfilt.c:276:4 #7 0x7ff52abf2b96 in __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310 #8 0x41a989 in _start (/home/hongxu/FOT/binutils/BUILD/install/bin/c++filt+0x41a989) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV /home/hongxu/FOT/binutils/BUILD/libiberty/../../libiberty/cplus-dem.c:1360:25 in work_stuff_copy_to_from ==23847==ABORTING
[Bug c/87347] ICE in warn_for_abs at gcc/c/c-parser.c:9226 since r264368
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87347 --- Comment #1 from Martin Jambor --- Bah, I should have thought about this. The following will fix it, I'll properly test it and submit a patch later this week. diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c index 1766a256633..a96d15fef1d 100644 --- a/gcc/c/c-parser.c +++ b/gcc/c/c-parser.c @@ -9116,9 +9116,10 @@ warn_for_abs (location_t loc, tree fndecl, tree arg) -Wint-conversion warnings. Most other wrong types hopefully lead to type mismatch errors. TODO: Think about what to do with FIXED_POINT_TYPE_P types and possibly other exotic types. */ - if (!INTEGRAL_TYPE_P (atype) - && !SCALAR_FLOAT_TYPE_P (atype) - && TREE_CODE (atype) != COMPLEX_TYPE) + if ((!INTEGRAL_TYPE_P (atype) + && !SCALAR_FLOAT_TYPE_P (atype) + && TREE_CODE (atype) != COMPLEX_TYPE) + || !TYPE_ARG_TYPES (TREE_TYPE (fndecl))) return; enum built_in_function fcode = DECL_FUNCTION_CODE (fndecl);
[Bug gcov-profile/85871] [8 Regression] g++.dg/gcov/gcov-8.C random failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85871 --- Comment #13 from Martin Liška --- Author: marxin Date: Tue Sep 18 09:32:09 2018 New Revision: 264387 URL: https://gcc.gnu.org/viewcvs?rev=264387=gcc=rev Log: Backport r264363 2018-09-18 Martin Liska Backport from mainline 2018-09-17 Martin Liska PR gcov-profile/85871 * gcov.c (output_intermediate_file): Fix out of bounds access. Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/gcov.c
[Bug c++/81880] thread_local static member template initialisation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81880
Latimerius changed:
What|Removed |Added
CC||latimerius at seznam dot cz
--- Comment #2 from Latimerius ---
This bug still seems to exist in the current 9.0 HEAD. Note also that another
possible work-around might be to wrap the thread_local member in an accessor
function, along the lines of
class A {
public:
template
std::unordered_map & get_m ()
{
thread_local static std::unordered_map m;
return m;
}
};
[Bug c++/87340] Stack overflow problem for c++filt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87340 --- Comment #3 from Martin Liška --- Then it would deserve something like segfault-on-invalid-input :) Or should I use ice-on-invalid-code?
[Bug c++/87335] The stack overflow in function cplus_demangle_type in cp-demangle.c:2565 (c++filt -t)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87335 --- Comment #3 from Jonathan Wakely --- No, it's not a valid name. I can't reproduce a crash using the latest code from GCC though.
[Bug c++/87333] A stack overflow problem for c++filt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87333 --- Comment #2 from Cheng Wen --- (In reply to Martin Liška from comment #1) > Is the input a valid C++ mangled name of not? Hi, This input is obtained through fuzzing technology. Our fuzzer get some test cases by mutating a valid input. This can not guarantee that this is a valid C++ mangled name. The program c++filt accepts the test case I uploaded. And this test case can prove that c++filt have problems. When program c++filt executing this input, a stack-overflow problem occurs. Please check this input and try to fix this bug if necessary. Thank you very much.
[Bug c++/87340] Stack overflow problem for c++filt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87340 --- Comment #2 from Jonathan Wakely --- No. None of them look valid.
