[Bug target/71009] g++: ICE on modified gdb/valarith.c with -Ofast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71009 --- Comment #12 from Ryan Schmidt --- How would I do that?
[Bug c++/87660] New: Fail to compile unique_ptr of incomplete tyoe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87660
Bug ID: 87660
Summary: Fail to compile unique_ptr of incomplete tyoe
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tiagomacarios at gmail dot com
Target Milestone: ---
https://godbolt.org/z/zvJQ4F
For the following code GCC will fail to compile the {} and the nullptr
initializes.
#include
struct foo;
struct bar
{
#if defined(DEFAULT)
std::unique_ptr m_;
#elif defined(UNIFORM)
std::unique_ptr m_{};
#else
std::unique_ptr m_ = nullptr;
#endif
};
I would think this is a bug as per
http://eel.is/c++draft/unique.ptr#4.sentence-3
[Bug target/71009] g++: ICE on modified gdb/valarith.c with -Ofast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71009 --- Comment #11 from Eric Gallager --- (In reply to Ryan Schmidt from comment #9) > I am also encountering this problem on i386-apple-darwin9.8.0 when compiling > texlive-bin 20170604 with gcc 6.4.0, though in my case it's -Os not -Ofast: > > libtool: compile: /opt/local/bin/gcc-mp-6 -DHAVE_CONFIG_H -I. > -I./LuaJIT-src/src -DLUAJIT_ENABLE_LUA52COMPAT -DLUAI_HASHLIMIT=6 > -U_FORTIFY_SOURCE -isystem/opt/local/include -fomit-frame-pointer > -march=i686 -msse -msse2 -mfpmath=sse -fno-stack-protector -Wall -pipe -Os > -m32 -MT LuaJIT-src/src/lj_cconv.lo -MD -MP -MF > LuaJIT-src/src/.deps/lj_cconv.Tpo -c LuaJIT-src/src/lj_cconv.c -fno-common > -DPIC -o LuaJIT-src/src/.libs/lj_cconv.o > LuaJIT-src/src/lj_cconv.c: In function 'lj_cconv_ct_ct': > LuaJIT-src/src/lj_cconv.c:368:1: internal compiler error: in gen_reg_rtx, at > emit-rtl.c:1025 > } > ^ > libbacktrace could not find executable to open Actually could you attach the preprocessed source for lj_cconv.c anyways? I want to compare to see if it really is the same bug as I was originally experiencing.
[Bug c/78380] [6/7 regression] GCC crash with internal compiler error: in gen_reg_rtx, at emit-rtl.c:1025
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78380 Eric Gallager changed: What|Removed |Added Keywords||ice-on-valid-code, ||needs-bisection Known to work||4.0.1, 4.2.1, 4.5.4, 4.7.4, ||4.8.5, 8.2.0, 9.0 Target Milestone|--- |7.4 Summary|GCC crash with internal |[6/7 regression] GCC crash |compiler error: in |with internal compiler |gen_reg_rtx, at |error: in gen_reg_rtx, at |emit-rtl.c:1025 |emit-rtl.c:1025 Known to fail||5.5.0, 6.4.0, 7.3.0 --- Comment #6 from Eric Gallager --- (In reply to Eric Gallager from comment #5) > Confirming that GCC still ICEs on the testcase provided Actually the problem seems to have gone away with gcc 8; probably still worth adding the testcases to make sure it doesn't regress
[Bug other/65254] libiberty produces using extended field designator is an extension warnings in clang [-Wextended-offsetof]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65254 Eric Gallager changed: What|Removed |Added Blocks||87403 --- Comment #3 from Eric Gallager --- (In reply to Eric Gallager from comment #1) > (In reply to Jack Howarth from comment #0) > > The simple-object-xcoff.c file in libiberty produces a number of warnings of > > the form... > > > > ./../../gcc-5-20150228/libiberty/simple-object-xcoff.c:330:12: warning: > > using extended field designator is an extension [-Wextended-offsetof] > > + offsetof (struct external_filehdr, > > ^ > > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault. > > xctoolchain/usr/bin/../lib/clang/6.0/include/stddef.h:87:24: note: expanded > > from macro > > 'offsetof' > > #define offsetof(t, d) __builtin_offsetof(t, d) > >^ > > > > under the clang compiler as "offsetof(T, field,subfield)" and "offsetof(T, > > arr[3])" are C/C++ extensions and only "offsetof(T, field)" is standard. > > Shouldn't these be recoded to use the standard form? > > Furthermore, it'd be a good idea if gcc supported the -Wextended-offsetof > flag, too, like clang does. Since at least part of this bug is adding the -Wextended-offsetof flag, making this block the meta-bug for adding new warnings. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403 [Bug 87403] [Meta-bug] Issues that suggest a new warning
[Bug target/87598] [8/9 Regression] Rejects "%a0" with constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87598 Segher Boessenkool changed: What|Removed |Added Target|aarch64, powerpc64le|aarch64, powerpc*-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2018-10-20 CC||segher at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Segher Boessenkool --- It fails on all powerpc* in fact. Confirmed.
[Bug c/87038] diagnostics: Please add warning for jumping over initializers with switch/case in C mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87038 Eric Gallager changed: What|Removed |Added Blocks||87656 --- Comment #7 from Eric Gallager --- (In reply to Steinar H. Gunderson from comment #4) > Oh, it exists? Yes, if so, please count this as a request for enabling on > -Wextra. Anyone know why it isn't already? Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87656 [Bug 87656] Useful flags to enable with -Wall or -Wextra
[Bug middle-end/86172] [meta-bug] issues with -Wnull-dereference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86172 Eric Gallager changed: What|Removed |Added Blocks||87656 --- Comment #3 from Eric Gallager --- At least some of these prevent enabling -Wnull-dereference with -Wextra. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87656 [Bug 87656] Useful flags to enable with -Wall or -Wextra
[Bug middle-end/85488] segmentation fault when compiling code using the ordered(n) clause in OpenMP 4.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85488 --- Comment #2 from Jakub Jelinek --- Author: jakub Date: Fri Oct 19 22:52:06 2018 New Revision: 265335 URL: https://gcc.gnu.org/viewcvs?rev=265335=gcc=rev Log: PR middle-end/85488 PR middle-end/87649 * omp-low.c (check_omp_nesting_restrictions): Diagnose ordered without depend closely nested inside of loop with ordered clause with a parameter. * c-c++-common/gomp/doacross-2.c: New test. * c-c++-common/gomp/sink-3.c: Expect another error during error recovery. Added: trunk/gcc/testsuite/c-c++-common/gomp/doacross-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/omp-low.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/gomp/sink-3.c
[Bug middle-end/87649] ICE in OpenMP doacross (ordered) loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87649 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Fri Oct 19 22:52:06 2018 New Revision: 265335 URL: https://gcc.gnu.org/viewcvs?rev=265335=gcc=rev Log: PR middle-end/85488 PR middle-end/87649 * omp-low.c (check_omp_nesting_restrictions): Diagnose ordered without depend closely nested inside of loop with ordered clause with a parameter. * c-c++-common/gomp/doacross-2.c: New test. * c-c++-common/gomp/sink-3.c: Expect another error during error recovery. Added: trunk/gcc/testsuite/c-c++-common/gomp/doacross-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/omp-low.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/gomp/sink-3.c
[Bug fortran/87659] Memory corruption in array component of intent(in) unlimited polymorphic with optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87659 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-10-19 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- Confirmed from 4.8 up to trunk (9.0).
[Bug tree-optimization/87473] [7/8/9 Regression] ICE in create_add_on_incoming_edge, at gimple-ssa-strength-reduction.c:2344
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87473 --- Comment #7 from Bill Schmidt --- Fixed for trunk. Backports coming next week.
[Bug c++/87656] Useful flags to enable with -Wall or -Wextra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87656 --- Comment #2 from Manuel López-Ibáñez --- From: https://gcc.gnu.org/wiki/DiagnosticsGuidelines As a rough guideline, a warning option should be: enabled by default if it has (almost) no false positives (e.g., -Woverflow); added to -Wall if it is generally useful with low number of false positives that are easy to work-around; added to -Wextra if it has quite a lot of false positives but they are still easy to work-around; Warning options should move up in this list when bugfixes reduce the number of false positives. These cases are not meant to be exhaustive: some options should never be enabled by other option if the warning is too specific (-Wdouble-promotion); other options are already controlled by options such as -Wpedantic and -Wformat and do not need to move up in this list (but they might if deemed useful). There are two types of bugs that should be added to this meta-bug: 1. Adding the warning to Wall/Wextra breaks GCC's build because of questionable GCC code (maybe not wrong, but avoiding the warning makes the code better). That is, the warning works as expected but GCC needs to be fixed. 2. The warning generates false positives in user code that are not easy to work-around. That is, the warning could be improved.
[Bug c/69602] [6/7/8/9 Regression] over-ambitious logical-op warning on EAGAIN vs EWOULDBLOCK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69602 Manuel López-Ibáñez changed: What|Removed |Added Blocks||87656 --- Comment #23 from Manuel López-Ibáñez --- This prevents enabling -Wlogical-op with -Wextra. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87656 [Bug 87656] Useful flags to enable with -Wall or -Wextra
[Bug c/61534] Wlogical-op should not warn when either operand comes from macro expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61534 Manuel López-Ibáñez changed: What|Removed |Added Blocks||87656 --- Comment #12 from Manuel López-Ibáñez --- This prevent enabling -Wlogical-op with -Wall or -Wextra. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87656 [Bug 87656] Useful flags to enable with -Wall or -Wextra
[Bug libstdc++/82522] std::map::insert(value_type &&) not selected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82522 Jonathan Wakely changed: What|Removed |Added CC||filip.gawin at zoho dot com --- Comment #11 from Jonathan Wakely --- *** Bug 87658 has been marked as a duplicate of this bug. ***
[Bug c++/87658] Cannot use move ctor when inserting to std::map
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87658 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Jonathan Wakely --- (In reply to Filip Gawin from comment #3) > But you can see that interesting part via link, on github. i.e. it's fixed in current releases (the last 6.x release is due soon and the branch is already frozen, so this isn't going to get fixed for 6.5) This is not a bug anyway, there was no insert(value_type&&) member in C++11 or C++14, so this was expected to fail. It was added for C++17 and that's been implemented in more recent versions of GCC. *** This bug has been marked as a duplicate of bug 82522 ***
[Bug fortran/87659] Memory corruption in array component of intent(in) unlimited polymorphic with optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87659 --- Comment #1 from Damian Rouson --- In initial comment, I meant to write "... bug disappears if the pointer intent is switched to intent(inout)..."
[Bug fortran/87659] New: Memory corruption in array component of intent(in) unlimited polymorphic with optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87659 Bug ID: 87659 Summary: Memory corruption in array component of intent(in) unlimited polymorphic with optimization Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: damian at sourceryinstitute dot org Target Milestone: --- The following bug disappears if the pointer intent is switched to intent(out) or if the optimization level is dropped to -O0: $ cat all.f90 module vectors implicit none type vector integer, allocatable :: elements(:) end type contains subroutine set_elements(input) class(*), pointer, intent(in) :: input select type (input) type is (vector) input%elements=[2] end select end subroutine end module implicit none call set_vector contains subroutine set_vector() use vectors type (vector), target :: v class(*), pointer :: v_ptr v_ptr => v call set_elements ( v_ptr ) select type ( v_ptr ) type is ( vector ) print *, v%elements(1), '<-- should be 2' end select end subroutine end $ gfortran -O1 all.f90 $ ./a.out 0 <-- should be 2 $ gfortran --version GNU Fortran (Homebrew GCC 8.2.0) 8.2.0
[Bug c++/87658] Cannot use move ctor when inserting to std::map
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87658 --- Comment #3 from Filip Gawin --- Ops, messed code. But you can see that interesting part via link, on github.
[Bug c++/87658] Cannot use move ctor when inserting to std::map
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87658
--- Comment #2 from Filip Gawin ---
(In reply to ensadc from comment #1)
> > dynamicParts[mf->getName()] = std::move(part);
>
> operator[] calls the default constructor of the mapped_type (which seems to
> be `VehicleObject::Part` in this case), and since the mapped_type does not
> have a default constructor, this of course fails. I don't think this is a
> bug.
I've badly described it.
Main problem is - why
```
dynamicParts.insert({mf->getName(),
{mf, normal, damage, nullptr, nullptr, nullptr, false,
0.f, 0.f, 0.f}});
std::move(part)});
```
works in newer compilers, but not in gcc 6.x.x.
[Bug fortran/71880] pointer to allocatable character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71880 --- Comment #9 from paul.richard.thomas at gmail dot com --- Not quite fixed. The lhs character length doesn't get set and so it fails at runtime. I will commit the patch as 'obvious'. Paul 2018-10-19 Paul Thomas PR fortran/71880 * trans-expr.c (gfc_trans_pointer_assignment): Set the string length for array valued deferred length lhs. 2018-10-19 Paul Thomas PR fortran/71880 * gfortran.dg/deferred_character_31.f90 : New test. On Thu, 18 Oct 2018 at 22:12, dominiq at lps dot ens.fr wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71880 > > Dominique d'Humieres changed: > >What|Removed |Added > > CC||pault at gcc dot gnu.org > > --- Comment #8 from Dominique d'Humieres --- > The test in comment 2 looks like a duplicate of pr70149. It is fixed at > revision r265266. > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug lto/85132] ffmpeg runtime segfault with lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85132 Carl Eugen Hoyos changed: What|Removed |Added CC||cehoyos at ag dot or.at --- Comment #12 from Carl Eugen Hoyos --- Should be fixed: http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=10f46815 https://trac.ffmpeg.org/ticket/7491 I wonder a little how the FFmpeg developers were supposed to find out about this bug...
[Bug c++/87658] Cannot use move ctor when inserting to std::map
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87658 ensadc at mailnesia dot com changed: What|Removed |Added CC||ensadc at mailnesia dot com --- Comment #1 from ensadc at mailnesia dot com --- > dynamicParts[mf->getName()] = std::move(part); operator[] calls the default constructor of the mapped_type (which seems to be `VehicleObject::Part` in this case), and since the mapped_type does not have a default constructor, this of course fails. I don't think this is a bug.
[Bug tree-optimization/87473] [7/8/9 Regression] ICE in create_add_on_incoming_edge, at gimple-ssa-strength-reduction.c:2344
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87473 --- Comment #6 from Bill Schmidt --- Author: wschmidt Date: Fri Oct 19 18:28:11 2018 New Revision: 265319 URL: https://gcc.gnu.org/viewcvs?rev=265319=gcc=rev Log: [gcc] 2018-10-19 Bill Schmidt PR tree-optimization/87473 * gimple-ssa-strength-reduction.c (record_phi_increments_1): For phi arguments identical to the base expression of the phi candidate, record a phi-adjust increment of zero minus the index expression of the hidden basis. (phi_incr_cost_1): For phi arguments identical to the base expression of the phi candidate, the difference to compare against the increment is zero minus the index expression of the hidden basis, and there is no potential savings from replacing the (phi) statement. (ncd_with_phi): For phi arguments identical to the base expression of the phi candidate, the difference to compare against the increment is zero minus the index expression of the hidden basis. (all_phi_incrs_profitable_1): For phi arguments identical to the base expression of the phi candidate, the increment to be checked for profitability is zero minus the index expression of the hidden basis. [gcc/testsuite] 2018-10-19 Bill Schmidt PR tree-optimization/87473 * gcc.c-torture/compile/pr87473.c: New file. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr87473.c Modified: trunk/gcc/gimple-ssa-strength-reduction.c
[Bug c++/87658] New: Cannot use move ctor when inserting to std::map
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87658
Bug ID: 87658
Summary: Cannot use move ctor when inserting to std::map
Product: gcc
Version: 6.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: filip.gawin at zoho dot com
Target Milestone: ---
Problem is caused by this commit:
https://github.com/rwengine/openrw/commit/63ab663ea5f2282adfc574a3a537fbf0ec16d8bc#diff-a996c0379ea38c4fa42528c76c60ec03R864
It works with newer version of gcc(7/8) or msvc or clang.
Structure `Part` contains unique ptrs, so I've only defined move ctor and move
assignment operator (using `= default`).
If I change:
```
dynamicParts.insert({mf->getName(),
{mf, normal, damage, nullptr, nullptr, nullptr, false,
0.f, 0.f, 0.f}});
std::move(part)});
```
to
`dynamicParts[mf->getName()] = std::move(part);`
I'm getting:
```
In file included from
/usr/lib/gcc/x86_64-pc-linux-gnu/6.4.1/include/c++/functional:55:0,
from
/usr/lib/gcc/x86_64-pc-linux-gnu/6.4.1/include/c++/memory:79,
from
/run/media/filip/Zewn/openrw/shfil/rwengine/src/objects/VehicleObject.hpp:6,
from
/run/media/filip/Zewn/openrw/shfil/rwengine/src/objects/VehicleObject.cpp:1:
/usr/lib/gcc/x86_64-pc-linux-gnu/6.4.1/include/c++/tuple: In instantiation of
‘std::pair<_T1, _T2>::pair(std::tuple<_Args1 ...>&, std::tuple<_Args2 ...>&,
std::_Index_tuple<_Indexes1 ...>, std::_Index_tuple<_Indexes2 ...>) [with
_Args1 = {const std::__cxx11::basic_string,
std::allocator >&}; long unsigned int ..._Indexes1 = {0ul}; _Args2 = {};
long unsigned int ..._Indexes2 = {}; _T1 = const
std::__cxx11::basic_string; _T2 = VehicleObject::Part]’:
/usr/lib/gcc/x86_64-pc-linux-gnu/6.4.1/include/c++/tuple:1579:63: required
from ‘std::pair<_T1, _T2>::pair(std::piecewise_construct_t, std::tuple<_Args1
...>, std::tuple<_Args2 ...>) [with _Args1 = {const
std::__cxx11::basic_string, std::allocator
>&}; _Args2 = {}; _T1 = const std::__cxx11::basic_string; _T2 =
VehicleObject::Part]’
/usr/lib/gcc/x86_64-pc-linux-gnu/6.4.1/include/c++/ext/new_allocator.h:120:4:
required from ‘void __gnu_cxx::new_allocator<_Tp>::construct(_Up*, _Args&& ...)
[with _Up = std::pair,
VehicleObject::Part>; _Args = {const std::piecewise_construct_t&,
std::tuple,
std::allocator >&>, std::tuple<>}; _Tp = std::pair, VehicleObject::Part>]’
/usr/lib/gcc/x86_64-pc-linux-gnu/6.4.1/include/c++/bits/alloc_traits.h:475:4:
required from ‘static void std::allocator_traits
>::construct(std::allocator_traits >::allocator_type&,
_Up*, _Args&& ...) [with _Up = std::pair, VehicleObject::Part>; _Args = {const
std::piecewise_construct_t&, std::tuple, std::allocator >&>, std::tuple<>}; _Tp =
std::pair, VehicleObject::Part>;
std::allocator_traits >::allocator_type =
std::allocator,
VehicleObject::Part> >]’
/usr/lib/gcc/x86_64-pc-linux-gnu/6.4.1/include/c++/bits/hashtable_policy.h:1953:37:
required from ‘std::__detail::_Hashtable_alloc<_NodeAlloc>::__node_type*
std::__detail::_Hashtable_alloc<_NodeAlloc>::_M_allocate_node(_Args&& ...)
[with _Args = {const std::piecewise_construct_t&, std::tuple, std::allocator
>&>, std::tuple<>}; _NodeAlloc =
std::allocator, VehicleObject::Part>, true> >;
std::__detail::_Hashtable_alloc<_NodeAlloc>::__node_type =
std::__detail::_Hash_node,
VehicleObject::Part>, true>]’
/usr/lib/gcc/x86_64-pc-linux-gnu/6.4.1/include/c++/bits/hashtable_policy.h:595:8:
required from ‘std::__detail::_Map_base<_Key, _Pair, _Alloc,
std::__detail::_Select1st, _Equal, _H1, _H2, _Hash, _RehashPolicy, _Traits,
true>::mapped_type& std::__detail::_Map_base<_Key, _Pair, _Alloc,
std::__detail::_Select1st, _Equal, _H1, _H2, _Hash, _RehashPolicy, _Traits,
true>::operator[](const key_type&) [with _Key =
std::__cxx11::basic_string; _Pair = std::pair, VehicleObject::Part>; _Alloc =
std::allocator,
VehicleObject::Part> >; _Equal = std::equal_to
>; _H1 = std::hash >; _H2 =
std::__detail::_Mod_range_hashing; _Hash = std::__detail::_Default_ranged_hash;
_RehashPolicy = std::__detail::_Prime_rehash_policy; _Traits =
std::__detail::_Hashtable_traits;
std::__detail::_Map_base<_Key, _Pair, _Alloc, std::__detail::_Select1st,
_Equal, _H1, _H2, _Hash, _RehashPolicy, _Traits, true>::mapped_type =
VehicleObject::Part; std::__detail::_Map_base<_Key, _Pair, _Alloc,
std::__detail::_Select1st, _Equal, _H1, _H2, _Hash, _RehashPolicy, _Traits,
true>::key_type = std::__cxx11::basic_string]’
/usr/lib/gcc/x86_64-pc-linux-gnu/6.4.1/include/c++/bits/unordered_map.h:904:20:
required from ‘std::unordered_map<_Key, _Tp, _Hash, _Pred,
_Alloc>::mapped_type& std::unordered_map<_Key, _Tp, _Hash, _Pred,
_Alloc>::operator[](const key_type&) [with _Key =
std::__cxx11::basic_string; _Tp = VehicleObject::Part; _Hash =
std::hash >; _Pred =
std::equal_to >; _Alloc =
std::allocator,
[Bug bootstrap/87640] [9 regression] internal compiler error: in check, at tree-vrp.c:155
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87640 --- Comment #6 from Aldy Hernandez --- Created attachment 44861 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44861=edit untested patch by Richard Biener As part of the discussion here: https://gcc.gnu.org/ml/gcc-patches/2018-10/msg01099.html ...Richard suggested the attached patch which fixes the PR. I will defer to him, as he seems to be working on this.
Global accounts of QAD and SAP Users
Hi, How about targeting customer base of QAD and SAP Users for your Marketing and sales needs? Please let me know. This file includes- Company name, Website, Contact name (First, Middle, Last), Title, Direct email address, Phone, Postal address, Industry, SIC codes, Employee size, Revenue size and technology/application details. Kindly review and let me know if we can connect and discuss further. Await your response! Warm regards, Nancy winter LeadGen Manager No interest? Kindly reply "no" in the subject line
[Bug c/60440] Bogus -Wreturn-type warning after error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60440 --- Comment #9 from joseph at codesourcery dot com --- I think it would be appropriate for the front end to generate something for return ; that avoids this warning. I don't know whether that should be a literal return of error_mark_node, or a return of a dummy value, or something marked with TREE_NO_WARNING, or a call to __builtin_unreachable or __builtin_trap.
[Bug bootstrap/87640] [9 regression] internal compiler error: in check, at tree-vrp.c:155
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87640 seurer at gcc dot gnu.org changed: What|Removed |Added CC||seurer at gcc dot gnu.org --- Comment #5 from seurer at gcc dot gnu.org --- FYI: The revision that causes this is r265241 which was by Aldy (who has already claimed this). It also causes the bzip2 test in spec 2006 to fail in the same way.
[Bug c++/87656] Useful flags to enable with -Wall or -Wextra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87656 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-10-19 CC||egallager at gcc dot gnu.org Depends on||52961, 81453, 82922 Ever confirmed|0 |1 --- Comment #1 from Eric Gallager --- Confirmed, adding some other related bugs as dependencies. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52961 [Bug 52961] Make -Wempty-body less noisy and enable it with -Wall https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81453 [Bug 81453] relational expression involving null pointer not diagnosed with -Wall https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82922 [Bug 82922] Request: add -Wstrict-prototypes to -Wextra as K style is obsolescent
[Bug c/60440] Bogus -Wreturn-type warning after error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60440 --- Comment #8 from Eric Gallager --- (In reply to jos...@codesourcery.com from comment #7) > If CC:ing me on a bug, please always state the specific question on which > you want an opinion; don't CC me simply because I maintain the relevant > part of the compiler (I read gcc-bugs) or because I commented on the bug > in the past. The specific question is when Martin said "maybe it's doable" in comment #3, if the "maybe" should be, "yes, it's doable," or, "no, it isn't doable"
[Bug fortran/78219] [F08] specifying the kind of a FORALL index in the header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78219 --- Comment #6 from Jürgen Reuter --- (In reply to Jürgen Reuter from comment #5) > It appears that the link to this PR shall replace the link to PR4646 at the > Fortran2008 wiki status page: https://gcc.gnu.org/wiki/Fortran2008Status > The PR44646 (feature request) is closed now. Typo: first PR should be also PR44646.
[Bug fortran/78219] [F08] specifying the kind of a FORALL index in the header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78219 --- Comment #5 from Jürgen Reuter --- It appears that the link to this PR shall replace the link to PR4646 at the Fortran2008 wiki status page: https://gcc.gnu.org/wiki/Fortran2008Status The PR44646 (feature request) is closed now.
[Bug fortran/78983] [7/8/9 Regression] ICE with CAF-DT with allocatable member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78983 --- Comment #9 from Jürgen Reuter --- This reads that this bug/regression has been fixed on version 8 (and therewith presumably 9), but just not backported to version 7. Correct? For the actual trunk and OpenCoarrays 2.1 everything works for me (compilation and execution).
[Bug tree-optimization/87657] [9 Regression] SLP ICE in libgfortran matmul_i2_vanilla
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87657 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Richard Biener --- Fixed.
[Bug tree-optimization/87645] [7/8 Regression] gcc hangs up on vr_values::vrp_visit_assignment_or_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87645 --- Comment #4 from Richard Biener --- Author: rguenth Date: Fri Oct 19 14:28:43 2018 New Revision: 265317 URL: https://gcc.gnu.org/viewcvs?rev=265317=gcc=rev Log: 2018-10-19 Richard Biener PR middle-end/87645 * gcc.dg/torture/pr87645.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr87645.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/87657] [9 Regression] SLP ICE in libgfortran matmul_i2_vanilla
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87657 --- Comment #6 from Richard Biener --- Author: rguenth Date: Fri Oct 19 14:27:57 2018 New Revision: 265316 URL: https://gcc.gnu.org/viewcvs?rev=265316=gcc=rev Log: 2018-10-19 Richard Biener PR target/87657 * config/i386/i386.c (ix86_builtin_vectorization_cost): Use TYPE_VECTOR_SUBPARTS and avoid relying on vector mode. * gcc.target/i386/pr87657.c: New testcase. Added: trunk/gcc/testsuite/gcc.target/i386/pr87657.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/87645] [7/8 Regression] gcc hangs up on vr_values::vrp_visit_assignment_or_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87645 --- Comment #3 from Richard Biener --- Author: rguenth Date: Fri Oct 19 14:26:35 2018 New Revision: 265315 URL: https://gcc.gnu.org/viewcvs?rev=265315=gcc=rev Log: 2018-10-19 Richard Biener PR middle-end/87645 Backport from mainline 2018-07-12 Richard Biener * tree-ssa-sccvn.c (mprts_hook_cnt): Remove. (vn_lookup_simplify_result): Remove recursion limit applied here. (vn_nary_build_or_lookup_1): Adjust. (try_to_simplify): Likewise. * gimple-match-head.c (gimple_resimplify1): Instead apply one here. (gimple_resimplify2): Likewise. (gimple_resimplify3): Likewise. (gimple_resimplify4): Likewise. * gcc.dg/torture/pr87645.c: New testcase. Added: branches/gcc-8-branch/gcc/testsuite/gcc.dg/torture/pr87645.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/gimple-match-head.c branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/tree-ssa-sccvn.c
[Bug fortran/86052] ICE with parameterized derived types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86052 --- Comment #4 from Paul Thomas --- (In reply to Jürgen Reuter from comment #3) > Paul, it is not my example, it was posted by Alberto Fco. Martín-Huertas in > December 2015 on c.l.f., and you commented at that time that you were > contemplating on how to implement PDTs together with recursive allocatables > :P > I am just playing a little bit around and following the (older) entries on > c.l.f. Aaah! Thanks Juergen. As you can see, my hoped for PDTfest has not yet occurred. In fact, my ownership of non-PDT bugs has actually increased following a bit a quality of implementation drive on deferred length characters, select type and associate. I will find the time soon Paul
[Bug fortran/86148] parameterized type compile time error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86148 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 #2 from Paul Thomas --- I had better take this as the PDT "owner". I have some fairly fundamental work to do on PDT's and so I am not sure when I attend to this. Please be patient. Thanks for the report paul
[Bug fortran/86268] [9.0] Error on correct code with PDTs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86268 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 #2 from Paul Thomas --- I had better take it. Thanks for the report. Paul
[Bug fortran/87566] ICE with class(*) and select
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87566 --- Comment #9 from Paul Thomas --- If I don't take it, I will lose it! Cheers Paul
[Bug libstdc++/87520] [8/9 Regression] ODR violations in std::make_shared when mixing -fno-rtti and -frtti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87520 --- Comment #3 from Axel Naumann --- (In reply to Jonathan Wakely from comment #1) > A possible (partial) fix would be: > > --- a/libstdc++-v3/include/bits/shared_ptr_base.h > +++ b/libstdc++-v3/include/bits/shared_ptr_base.h I can confirm that this also fixes our actual "in the wild" issue. I would certainly appreciate this being included in 8.3. Thank you for the reproducer and the suggested patch, Jonathan!
[Bug tree-optimization/87657] [9 Regression] SLP ICE in libgfortran matmul_i2_vanilla
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87657 --- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #4 from Richard Biener --- > Not that word_mode vectorization costing in the backend is in any way > correct... With that patch, the i686-pc-linux-gnu bootstrap completed without regressions. Thanks. An x86_64-pc-linux-gnu (both multilibs) had completed before even with the vanilla tree.
[Bug libbacktrace/87653] Calling null pointer in multi-threaded applications
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87653 --- Comment #1 from Ian Lance Taylor --- Created attachment 44860 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44860=edit Possible patch I can't recreate the problem. Your test program runs fine on my system, once I add a main function that calls main_test_loop. If you can recreate the problem consistently, can you see if this patch fixes it? Thanks.
[Bug c/60440] Bogus -Wreturn-type warning after error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60440 --- Comment #7 from joseph at codesourcery dot com --- If CC:ing me on a bug, please always state the specific question on which you want an opinion; don't CC me simply because I maintain the relevant part of the compiler (I read gcc-bugs) or because I commented on the bug in the past.
[Bug c++/87652] [8/9 Regression] inner class template of outer class template can't access friend's protected data member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87652 Jonathan Wakely changed: What|Removed |Added Keywords||ice-on-valid-code --- Comment #3 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #2) > The ICE seems to be fixed on gcc-8-branch But is rejects-valid on the branch, instead of ice-on-valid-code on trunk.
[Bug c++/87651] [8/9 Regression] inner class with template template friend declaration of same name fails to compile in gcc 8.1, 8.2, and 9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87651 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-10-19 Ever confirmed|0 |1
[Bug c++/87652] [8/9 Regression] inner class template of outer class template can't access friend's protected data member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87652 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-10-19 Ever confirmed|0 |1
[Bug tree-optimization/87657] [9 Regression] SLP ICE in libgfortran matmul_i2_vanilla
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87657
--- Comment #4 from Richard Biener ---
Not that word_mode vectorization costing in the backend is in any way
correct...
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 9a5b54978a9..f542a1b494f 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -45169,9 +45163,8 @@ ix86_builtin_vectorization_cost (enum
vect_cost_for_stmt type_of_cost,
case vec_construct:
{
- gcc_assert (VECTOR_MODE_P (mode));
/* N element inserts into SSE vectors. */
- int cost = GET_MODE_NUNITS (mode) * ix86_cost->sse_op;
+ int cost = TYPE_VECTOR_SUBPARTS (vectype) * ix86_cost->sse_op;
/* One vinserti128 for combining two SSE vectors for AVX256. */
if (GET_MODE_BITSIZE (mode) == 256)
cost += ix86_vec_cost (mode, ix86_cost->addss);
[Bug c++/87652] [8/9 Regression] inner class template of outer class template can't access friend's protected data member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87652 Jonathan Wakely changed: What|Removed |Added CC||nathan at gcc dot gnu.org --- Comment #2 from Jonathan Wakely --- Compiled OK with r255779, started to ICE with r255780. The ICE seems to be fixed on gcc-8-branch but not on trunk.
[Bug tree-optimization/87657] [9 Regression] SLP ICE in libgfortran matmul_i2_vanilla
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87657 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |9.0 --- Comment #3 from Richard Biener --- Mine. This happens when vectorizing with word_mode operations V2HI in SImode.
[Bug c++/87651] [8/9 Regression] inner class with template template friend declaration of same name fails to compile in gcc 8.1, 8.2, and 9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87651 Jonathan Wakely changed: What|Removed |Added CC||nathan at gcc dot gnu.org --- Comment #1 from Jonathan Wakely --- Regression started with r255780 [PR c++/59930] template friend injection https://gcc.gnu.org/ml/gcc-patches/2017-12/msg01168.html PR c++/59930 * name-lookup.c (name_lookup::search_unqualified): Don't search parent namespace when looking for hidden things. * pt.c (tsubst_friend_class): Always push to friend scope, drop unneeded self-friend check. Inject new hidden friend into correct scope. PR c++/59930 * g++.dg/parse/pr81247-c.C: Adjust. * g++.dg/template/pr59930-[123].C: New.
[Bug tree-optimization/87645] [7/8 Regression] gcc hangs up on vr_values::vrp_visit_assignment_or_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87645 --- Comment #2 from Richard Biener --- Backporting that change helps.
[Bug libstdc++/54005] Use __atomic_always_lock_free in libstdc++ is_lock_free instead of __atomic_is_lock_free
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54005 --- Comment #35 from Jonathan Wakely --- (In reply to Hans-Peter Nilsson from comment #34) > Can I at least change > - reinterpret_cast(-__alignof(_M_i))); > + reinterpret_cast(-_S_alignment)); > ? Yes, OK.
[Bug tree-optimization/87657] [9 Regression] SLP ICE in libgfortran matmul_i2_vanilla
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87657 --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE --- This looks like it could be due to 2018-10-18 Richard Biener * config/i386/i386.c (ix86_builtin_vectorization_cost): Do not feed width-specific load/store costs through ix86_vec_cost. * config/i386/x86-tune-costs.h (athlon_cost): Adjust. (k8_cost): Likewise. (bdver_cost): Likewise. (znver1_cost): Likewise. (btver1_cost): Likewise. (btver2_cost): Likewise.
[Bug tree-optimization/87657] [9 Regression] SLP ICE in libgfortran matmul_i2_vanilla
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87657 Rainer Orth changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-10-19 CC||rguenth at gcc dot gnu.org, ||ro at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Rainer Orth --- I'm also seeing this on i686-pc-linux-gnu (32-bit multilib only), but not on i386-pc-solaris2.11.
[Bug middle-end/87655] `i = i % constant` for static local `i` is not optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87655
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-10-19
CC||rguenth at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
It's not so easy (not an easy fit into existing optimization passes). This
is because 'i' is considered a global variable and the optimization is only
valid because we know that 'i' is zero at program start.
Then for optimizing i = i % 10 to if (i == 10) i = 0; we have to know
that i actually reaches 10 (and not 11).
This means we have to compute sth like the scalar evolution of the memory
'i' which only evolves across multiple invocations of next_trivial().
If this happens in SPEC then other compilers probably pattern-match this
kind of thing ...
A "proper" analysis might transform a function body with local statics
into
reg_static_var = static_var;
while (1)
{
... body ...
}
static_var = reg_static_var;
and analyze multiple invocations as if they were directly in a loop. All
other global input would need to be treated volatile.
Eventually the SCEV infrastructure has enough to hack this up and the
prerequesite would be a single load from the static var at function
entry and a single store at function exit.
[Bug libstdc++/54005] Use __atomic_always_lock_free in libstdc++ is_lock_free instead of __atomic_is_lock_free
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54005 --- Comment #34 from Hans-Peter Nilsson --- (In reply to Jonathan Wakely from comment #32) > I would prefer a function template instead of the LF macro e.g. That will lose the __LINE__ information from the supposed error message in VERIFY, i.e. it'll point at the check function rather than the unique invoking line. > So the premise that "is_lock_free() is per-type implies it's the same as > always_lock_free" is wrong. Ouch. That again exposes the __is_lock_free() flaws. But that's for another bug. Can I at least change - reinterpret_cast(-__alignof(_M_i))); + reinterpret_cast(-_S_alignment)); ?
[Bug middle-end/87654] Information about constants from condition is not propagated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87654 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-10-19 CC||rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- I'm not sure we have a general tail-duplication path, I suppose tracer is closest, but it's cost model is profile-based. [local count: 1073741825]: if (big_3(D) != 0) goto ; [50.00%] else goto ; [50.00%] [local count: 536870913]: [local count: 1073741825]: # iftmp.0_2 = PHI <16384(2), 4096(3)> _1 = value_4(D) / iftmp.0_2; _5 = _1 * iftmp.0_2; return _5; it _might_ be a phiprop thing since that is a pass that "hoists" expressions across edges when profitable.
[Bug middle-end/87647] [6/7/8/9 Regression] ICE on valid code in decode_addr_const, at varasm.c:2958
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87647 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Created attachment 44859 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44859=edit gcc9-pr87647.patch Untested fix.
[Bug tree-optimization/87657] New: [9 Regression] SLP ICE in libgfortran matmul_i2_vanilla
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87657 Bug ID: 87657 Summary: [9 Regression] SLP ICE in libgfortran matmul_i2_vanilla Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: amonakov at gcc dot gnu.org Target Milestone: --- Target: i?86-*-* Created attachment 44858 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44858=edit unreduced testcase 32-bit x86 bootstrap fails at stage3 building libgfortran. On the attached testcase the following command line fails: gcc/cc1 -O2 -fcx-fortran-rules -ffunction-sections -fdata-sections -ffast-math -ftree-vectorize -funroll-loops --param max-unroll-times=4 /home/am/gcc-sort/libgfortran/generated/matmul_i2.c: In function ‘matmul_i2_vanilla’: /home/am/gcc-sort/libgfortran/generated/matmul_i2.c:1805:1: internal compiler error: in ix86_builtin_vectorization_cost, at config/i386/i386.c:45176 1805 | matmul_i2_vanilla (gfc_array_i2 * const restrict retarray, | ^ 0x8ad647b ix86_builtin_vectorization_cost /home/am/gcc-sort/gcc/config/i386/i386.c:45176 0x89b8d71 builtin_vectorization_cost /home/am/gcc-sort/gcc/tree-vectorizer.h:1181 0x89b8d71 record_stmt_cost(vec*, int, vect_cost_for_stmt, _stmt_vec_info*, int, vect_cost_model_location) /home/am/gcc-sort/gcc/tree-vect-stmts.c:106 0x89bb126 vect_prologue_cost_for_slp_op /home/am/gcc-sort/gcc/tree-vect-stmts.c:837 0x89cf3d8 vect_model_store_cost /home/am/gcc-sort/gcc/tree-vect-stmts.c:974 0x89cf3d8 vectorizable_store /home/am/gcc-sort/gcc/tree-vect-stmts.c:6380 0x89d9117 vect_analyze_stmt(_stmt_vec_info*, bool*, _slp_tree*, _slp_instance*, vec*) /home/am/gcc-sort/gcc/tree-vect-stmts.c:9566 0x8a07188 vect_slp_analyze_node_operations_1 /home/am/gcc-sort/gcc/tree-vect-slp.c:2422 0x8a07188 vect_slp_analyze_node_operations /home/am/gcc-sort/gcc/tree-vect-slp.c:2469 0x8a0a397 vect_slp_analyze_operations(vec_info*) /home/am/gcc-sort/gcc/tree-vect-slp.c:2501 0x8a0b429 vect_slp_analyze_bb_1 /home/am/gcc-sort/gcc/tree-vect-slp.c:2809 0x8a0b429 vect_slp_bb(basic_block_def*) /home/am/gcc-sort/gcc/tree-vect-slp.c:2896 0x8a0bd86 execute /home/am/gcc-sort/gcc/tree-vectorizer.c:1291
[Bug c++/87652] [8/9 Regression] inner class template of outer class template can't access friend's protected data member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87652 Richard Biener changed: What|Removed |Added Keywords||rejects-valid Target Milestone|--- |8.3 Summary|inner class template of |[8/9 Regression] inner |outer class template can't |class template of outer |access friend's protected |class template can't access |data member |friend's protected data ||member
[Bug c++/87651] [8/9 Regression] inner class with template template friend declaration of same name fails to compile in gcc 8.1, 8.2, and 9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87651 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.3 Summary|inner class with template |[8/9 Regression] inner |template friend declaration |class with template |of same name fails to |template friend declaration |compile in gcc 8.1, 8.2,|of same name fails to |and 9.0 |compile in gcc 8.1, 8.2, ||and 9.0
[Bug tree-optimization/87645] [7/8 Regression] gcc hangs up on vr_values::vrp_visit_assignment_or_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87645 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Status|UNCONFIRMED |ASSIGNED Known to work||6.4.0, 9.0 Keywords||needs-bisection Last reconfirmed||2018-10-19 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 Summary|gcc hangs up on |[7/8 Regression] gcc hangs |vr_values::vrp_visit_assign |up on |ment_or_call|vr_values::vrp_visit_assign ||ment_or_call Target Milestone|--- |7.4 Known to fail||7.1.0, 7.3.1, 8.1.0, 8.2.1 --- Comment #1 from Richard Biener --- Seems to work on trunk. Also is slow in GCC 7. I will take a look. Let's assume trunk is affected as well unless confirmed it was really fixed. On the GCC 8 branch this seems to take considerable time in Run till exit from #0 0x0158a43c in gimple_simplify_PLUS_EXPR ( res_code=0x7ffd56d0, res_ops=0x7ffd56b0, seq=0x0, valueize=0x143801e , code=..., type=0x76892690, op0=0x76a36798, op1=0x76a3f1f8) at gimple-match.c:30626 so it looks like a pattern oscillation issue to me (eventually it will finish ...). On trunk we've installed a "depth" limit with 2018-07-12 Richard Biener * tree-ssa-sccvn.c (mprts_hook_cnt): Remove. (vn_lookup_simplify_result): Remove recursion limit applied here. (vn_nary_build_or_lookup_1): Adjust. (try_to_simplify): Likewise. * gimple-match-head.c (gimple_resimplify1): Instead apply one here. (gimple_resimplify2): Likewise. (gimple_resimplify3): Likewise. (gimple_resimplify4): Likewise.
[Bug fortran/87644] [7/8/9 Regression] ICE due to variable named "parameters"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87644 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |7.4
[Bug middle-end/87649] ICE in OpenMP doacross (ordered) loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87649 --- Comment #3 from Jakub Jelinek --- Created attachment 44857 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44857=edit gcc9-pr87649.patch Untested fix.
[Bug c++/87656] New: Useful flags to enable with -Wall or -Wextra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87656 Bug ID: 87656 Summary: Useful flags to enable with -Wall or -Wextra Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: manu at gcc dot gnu.org Target Milestone: --- There have been quite a number of new warning flags added to GCC that are not enabled by -Wall nor -Wextra, so they are not easily found by users. This is a meta-bug to track what would need to be done to enable them: -Wduplicated-branches -Wduplicated-cond -Wlogical-op -Wnull-dereference -Wjump-misses-init Some of the most useful new variants of -Wshadow The above list is not exhaustive.
[Bug middle-end/87655] New: `i = i % constant` for static local `i` is not optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87655
Bug ID: 87655
Summary: `i = i % constant` for static local `i` is not
optimized
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: antoshkka at gmail dot com
Target Milestone: ---
Consider the following example:
unsigned next_trivial() {
static int i = 0;
auto ret = i;
++i;
i = i % 10;
return ret;
}
For that example a very suboptimal assembly with multiplication, many registers
usage and multiple instructions is generated.
However, the above example could be rewritten in the following way:
unsigned next_trivial_optim() {
static int i = 0;
auto ret = i;
++i;
if (i == 10) { i = 0; }
return ret;
}
For the above code snippet a very short and clear assembly is produced, without
any multiplications and unnecessary instructions:
mov eax, DWORD PTR next_trivial_optim()::i[rip]
mov ecx, 0
lea edx, [rax+1]
cmp eax, 9
cmove edx, ecx
mov DWORD PTR next_trivial_optim()::i[rip], edx
ret
Please, add an optimization to do that transformation.
[Bug fortran/87644] [7/8/9 Regression] ICE due to variable named "parameters"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87644 --- Comment #3 from Tobias Burnus --- Note that most of the variants seem to be handled fine, e.g. the following seems to work; all variants output: 5 and 7. The issue seems to also relate to having the the "parameter..." in the parent scope. (And the current scope can either use the variable of override it by its own.) implicit none integer :: parameterA = 5 integer :: A parameter(A = 7) ! Variant A - valid Fortran parameter A = 7 ! Variant B - legacy extension parameterA = 7 ! Variant C - ditto, but why no space required with free form? print *, parameterA print *, A end
[Bug fortran/87644] [7/8/9 Regression] ICE due to variable named "parameters"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87644
Tobias Burnus changed:
What|Removed |Added
Keywords||ice-on-valid-code
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-10-19
CC||burnus at gcc dot gnu.org
Summary|ICE due to variable named |[7/8/9 Regression] ICE due
|"parameters"|to variable named
||"parameters"
Ever confirmed|0 |1
--- Comment #2 from Tobias Burnus ---
Irks!
(A) gfortran supports as legacy extension parameter declarations without "()"
=> The issue of comment 0 is due to the legacy support
=> It was added for GCC 7 on 2016-11-03 in commit r241823
=> Needs to be fixed for valid standard Fortran code
(Actually, I wonder why we enter the do_param handling, given that there is no
space after 'parameter' before the 's='; with free-form Fortran I had expected
that there must be a white space [or '('] in order to be a parameter
statement.)
=> For legacy code, there seems to be in addition an ambiguity
if one ignores the '()'. Namely:
Assume fixed-format which ignores spaces and, for simplicity, assume implicit
typing and any of those (all are the same with fixed-form Fortran):
parameterABC=7
parameter ABC = 7
p aram et erAB C =7
Shall this be regarded as
implicit none
real :: parameterABC
parameterABC = 7.0
or as
implicit none
real :: ABC
parameter (ABC = 7.0)
This ambiguity only applies to --std=legacy but still one it has to be
resolved!
(B) We should check whether there are any parsing issues with "parameter..."
variables for standard conforming code. At a glance, it seems to work - but we
might miss some corner cases.
In any case, parameter without '(' is not a valid PARAMETER statement according
to the standard. With '(' we can have assignments and pointer assignments to
array variables such as:
parameter(idx) = ...
parameterABC(:) = ...
parameter(5:) => pointer_target
parameterABC(5:) => pointer_target
parameter(f(arg=5):) => pointer_target
Some testing indicates that gfortran handle those correctly.
[Bug middle-end/87654] New: Information about constants from condition is not propagated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87654
Bug ID: 87654
Summary: Information about constants from condition is not
propagated
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: antoshkka at gmail dot com
Target Milestone: ---
Consider the following example:
unsigned align_func1(bool big, unsigned value) {
const unsigned mx_ = (big ? 1 << 14 : 1 << 12);
return value / mx_ * mx_;
}
It is equivalent to the following code:
unsigned align_func2(bool big, unsigned value) {
if (big) {
const unsigned mx_ = 1 << 14;
return value / mx_ * mx_;
}
const unsigned mx_ = 1 << 12;
return value / mx_ * mx_;
}
Assembly for the align_func2 seems optimal:
mov eax, esi
and esi, -4096
and eax, -16384
test dil, dil
cmove eax, esi
ret
While the assembly for the first function is far from optimal:
align_func1(bool, unsigned int):
cmp dil, 1
mov eax, esi
sbb ecx, ecx
xor edx, edx
and ecx, -12288
add ecx, 16384
div ecx ; <=== too bad
imul eax, ecx
ret
[Bug middle-end/87649] ICE in OpenMP doacross (ordered) loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87649 Jakub Jelinek changed: What|Removed |Added CC||chunhualiao at gmail dot com --- Comment #2 from Jakub Jelinek --- *** Bug 85488 has been marked as a duplicate of this bug. ***
[Bug middle-end/85488] segmentation fault when compiling code using the ordered(n) clause in OpenMP 4.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85488 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Component|c |middle-end Resolution|--- |DUPLICATE --- Comment #1 from Jakub Jelinek --- Dup of PR87649. *** This bug has been marked as a duplicate of bug 87649 ***
[Bug middle-end/87649] ICE in OpenMP doacross (ordered) loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87649 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-10-19 Component|libgomp |middle-end Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1
[Bug libbacktrace/87653] New: Calling null pointer in multi-threaded applications
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87653 Bug ID: 87653 Summary: Calling null pointer in multi-threaded applications Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libbacktrace Assignee: unassigned at gcc dot gnu.org Reporter: antoshkka at gmail dot com CC: ian at gcc dot gnu.org Target Milestone: --- Created attachment 44856 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44856=edit C++ program to reproduce the issue Using the same backtrace_state* from multiple threads is not safe. Consider the attachment with a test program. Running it Segfaults. GDB shows the following backtrace: Thread 3 "a.out" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7674d700 (LWP 27705)] 0x in ?? () (gdb) bt #0 0x in ?? () #1 0x004011d4 in source_line (addr=0x401180 ) at thread_safety_checking.cpp:33 #2 main_test_loop () at thread_safety_checking.cpp:39 That happened because we jumped to address 0. It happened somewhere inside the backtrace_pcinfo function: 0x004011c2 <+66>:mov$0x401180,%esi 0x004011c7 <+71>:movl $0x0,0x4(%rsp) 0x004011cf <+79>:callq 0x401840 => 0x004011d4 <+84>:mov0x4(%rsp),%ebp 0x004011d8 <+88>:test %ebp,%ebp 0x004011da <+90>:je 0x40130f My assumption is that it happening at the `return state->fileline_fn (state, pc, callback, error_callback, data);` line inside `backtrace_pcinfo`. Seems that fileline_fn is a null pointer. https://github.com/gcc-mirror/gcc/blob/41d6b10e96a1de98e90a7c0378437c3255814b16/libbacktrace/fileline.c#L183
[Bug target/72782] AVX512: No support for scalar broadcasts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72782 --- Comment #5 from hjl at gcc dot gnu.org --- Author: hjl Date: Fri Oct 19 09:13:34 2018 New Revision: 265311 URL: https://gcc.gnu.org/viewcvs?rev=265311=gcc=rev Log: i386: Enable AVX512 memory broadcast for FP add Many AVX512 vector operations can broadcast from a scalar memory source. This patch enables memory broadcast for FP add operations. gcc/ PR target/72782 * config/i386/sse.md (*3_bcst_1): New. (*add3_bcst_2): Likewise. gcc/testsuite/ PR target/72782 * gcc.target/i386/avx512-binop-1.h: New file. * gcc.target/i386/avx512-binop-2.h: Likewise. * gcc.target/i386/avx512-binop-3.h: Likewise. * gcc.target/i386/avx512-binop-4.h: Likewise. * gcc.target/i386/avx512-binop-5.h: Likewise. * gcc.target/i386/avx512-binop-6.h: Likewise. * gcc.target/i386/avx512f-add-df-zmm-1.c: Likewise. * gcc.target/i386/avx512f-add-sf-zmm-1.c: Likewise. * gcc.target/i386/avx512f-add-sf-zmm-2.c: Likewise. * gcc.target/i386/avx512f-add-sf-zmm-3.c: Likewise. * gcc.target/i386/avx512f-add-sf-zmm-4.c: Likewise. * gcc.target/i386/avx512f-add-sf-zmm-5.c: Likewise. * gcc.target/i386/avx512f-add-sf-zmm-6.c: Likewise. * gcc.target/i386/avx512f-sub-df-zmm-1.c: Likewise. * gcc.target/i386/avx512f-sub-sf-zmm-1.c: Likewise. * gcc.target/i386/avx512f-sub-sf-zmm-2.c: Likewise. * gcc.target/i386/avx512f-sub-sf-zmm-3.c: Likewise. * gcc.target/i386/avx512f-sub-sf-zmm-4.c: Likewise. * gcc.target/i386/avx512f-sub-sf-zmm-5.c: Likewise. * gcc.target/i386/avx512vl-add-sf-xmm-1.c: Likewise. * gcc.target/i386/avx512vl-add-sf-ymm-1.c: Likewise. * gcc.target/i386/avx512vl-sub-sf-xmm-1.c: Likewise. * gcc.target/i386/avx512vl-sub-sf-ymm-1.c: Likewise. Added: trunk/gcc/testsuite/gcc.target/i386/avx512-binop-1.h trunk/gcc/testsuite/gcc.target/i386/avx512-binop-2.h trunk/gcc/testsuite/gcc.target/i386/avx512-binop-3.h trunk/gcc/testsuite/gcc.target/i386/avx512-binop-4.h trunk/gcc/testsuite/gcc.target/i386/avx512-binop-5.h trunk/gcc/testsuite/gcc.target/i386/avx512-binop-6.h trunk/gcc/testsuite/gcc.target/i386/avx512f-add-df-zmm-1.c trunk/gcc/testsuite/gcc.target/i386/avx512f-add-sf-zmm-1.c trunk/gcc/testsuite/gcc.target/i386/avx512f-add-sf-zmm-2.c trunk/gcc/testsuite/gcc.target/i386/avx512f-add-sf-zmm-3.c trunk/gcc/testsuite/gcc.target/i386/avx512f-add-sf-zmm-4.c trunk/gcc/testsuite/gcc.target/i386/avx512f-add-sf-zmm-5.c trunk/gcc/testsuite/gcc.target/i386/avx512f-add-sf-zmm-6.c trunk/gcc/testsuite/gcc.target/i386/avx512f-sub-df-zmm-1.c trunk/gcc/testsuite/gcc.target/i386/avx512f-sub-sf-zmm-1.c trunk/gcc/testsuite/gcc.target/i386/avx512f-sub-sf-zmm-2.c trunk/gcc/testsuite/gcc.target/i386/avx512f-sub-sf-zmm-3.c trunk/gcc/testsuite/gcc.target/i386/avx512f-sub-sf-zmm-4.c trunk/gcc/testsuite/gcc.target/i386/avx512f-sub-sf-zmm-5.c trunk/gcc/testsuite/gcc.target/i386/avx512vl-add-sf-xmm-1.c trunk/gcc/testsuite/gcc.target/i386/avx512vl-add-sf-ymm-1.c trunk/gcc/testsuite/gcc.target/i386/avx512vl-sub-sf-xmm-1.c trunk/gcc/testsuite/gcc.target/i386/avx512vl-sub-sf-ymm-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/sse.md trunk/gcc/testsuite/ChangeLog
[Bug fortran/87625] [OOP] (re)allocate on assignment fails for polymorphic array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87625 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-10-19 Ever confirmed|0 |1 --- Comment #3 from Dominique d'Humieres --- pr84539 seems to be a duplicate.
[Bug rtl-optimization/87596] [9 Regression] ICE: Segmentation fault (in spill_hard_reg_in_range)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87596 --- Comment #6 from iii at gcc dot gnu.org --- Author: iii Date: Fri Oct 19 08:33:52 2018 New Revision: 265306 URL: https://gcc.gnu.org/viewcvs?rev=265306=gcc=rev Log: lra: fix spill_hard_reg_in_range clobber check FROM..TO range might contain NOTE_INSN_DELETED insns, for which the corresponding entries in lra_insn_recog_data[] are NULLs. Example from the problematic code from PR87596: (note 148 154 68 7 NOTE_INSN_DELETED) lra_insn_recog_data[] is used directly only when the insn in question is taken from insn_bitmap, which is not the case here. In other situations lra_get_insn_recog_data () guarded by INSN_P () or other stricter predicate are used. So we need to do this here as well. A tiny detail worth noting: I put the INSN_P () check before the insn_bitmap check, because I believe that insn_bitmap can contain only real insns anyway. gcc/ChangeLog: 2018-10-19 Ilya Leoshkevich PR rtl-optimization/87596 * lra-constraints.c (spill_hard_reg_in_range): Use INSN_P () + lra_get_insn_recog_data () instead of lra_insn_recog_data[] for instructions in FROM..TO range. gcc/testsuite/ChangeLog: 2018-10-19 Ilya Leoshkevich PR rtl-optimization/87596 * gcc.target/i386/pr87596.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr87596.c Modified: trunk/gcc/ChangeLog trunk/gcc/lra-constraints.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/87633] [9 Regression] ice in compare_range_wit h_value, at vr-values.c:1702
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87633 --- Comment #7 from Yury Gribov --- Problem seems to be in extract_range_from_binary_expr_1, in /* Build the bounds. */ combine_bound (code, wmin, min_ovf, expr_type, min_op0, min_op1); min_op0 is NULL_TREE which causes set_value_range_with_overflow to generate invalid range which then ICEs. Simply adding && min_op0 && min_op1 && max_op0 && max_op1 to guarding condition works around the error but I guess you'll want a more clever fix. I'll try retesting without isl until it's fixed.
[Bug tree-optimization/87633] [9 Regression] ice in compare_range_wit h_value, at vr-values.c:1702
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87633 --- Comment #6 from Yury Gribov --- Seems isl bootstrap is broken in trunk: /home/yugr/src/gcc-87633-ref/isl/isl_tab_pip.c: In function ‘isl_tab_basic_set_non_trivial_lexmin’: /home/yugr/src/gcc-87633-ref/isl/isl_tab_pip.c:5087:21: internal compiler error: in check, at tree-vrp.c:155 5087 | __isl_give isl_vec *isl_tab_basic_set_non_trivial_lexmin(
[Bug libstdc++/87641] std::valarray::sum() fails for types where T() is not a neutral element for addition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87641 --- Comment #8 from Frederic Jardon --- Thank you for the fast response :)
