[Bug target/87358] [8/9 Regression] ICE when -mtune=thunderx2t99 applied
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87358 --- Comment #10 from Andrew Pinski --- (In reply to Lijian Zhang from comment #9) > Hi Andrew, > I only reproduced this issue with gcc-7.3.0, but not able to reproduce the > failure with gcc-8.2.0/gcc-8.1.0 FSF released GCC 7.3.0 does not have the issue. Only the Linaro (and in turn Ubuntu)'s version of GCC 7.3.0 has the bug. The code was not introduced until after GCC 7 was branched off and GCC 8 was the trunk. > But from your description, gcc-8.2.0 still have this issue, and this issue > is target to be fixed in gcc-8.3.0? Yes GCC 8.2.0 has one part of the fix is now included in 8.3.0; the other part (which is also hit for Linaro's GCC 7.3.0) was included a few weeks after the originally bug was introduced when GCC 8 was the trunk.
[Bug c++/86329] Bogus fix-it hint: note: suggested alternative: '._72'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86329
Eric Gallager changed:
What|Removed |Added
Target Milestone|--- |7.4
--- Comment #7 from Eric Gallager ---
(In reply to Eric Gallager from comment #5)
> (In reply to David Malcolm from comment #4)
> > Fixed on trunk by r262199; still affects gcc-8 and gcc-7 branches.
>
> so what should be the target milestone then?
(In reply to David Malcolm from comment #6)
> Author: dmalcolm
> Date: Thu Feb 14 23:02:45 2019
> New Revision: 268909
>
> URL: https://gcc.gnu.org/viewcvs?rev=268909=gcc=rev
> Log:
> C++: don't offer bogus "._0" suggestions (PR c++/86329)
>
> PR c++/86329 reports that the C++ frontend can offer bogus suggestions like:
>
> #include
>
> int compare()
> {
> return __n1 - __n2;
> }
>
> suggested.cc: In function 'int compare()':
> suggested.cc:5:10: error: '__n1' was not declared in this scope
>return __n1 - __n2;
> ^~~~
> suggested.cc:5:10: note: suggested alternative: '._61'
>return __n1 - __n2;
> ^~~~
> ._61
> suggested.cc:5:17: error: '__n2' was not declared in this scope
>return __n1 - __n2;
> ^~~~
> suggested.cc:5:17: note: suggested alternative: '._72'
>return __n1 - __n2;
> ^~~~
> ._72
>
> The dot-prefixed names are an implementation detail of how we implement
> anonymous enums found in the header files, generated via
> anon_aggrname_format in make_anon_name.
>
> This patch uses anon_aggrname_p to filter them out when considering
> which names to suggest.
>
> gcc/cp/ChangeLog:
> Backport of r262199 from trunk.
> 2018-06-27 David Malcolm
>
> PR c++/86329
> * name-lookup.c (consider_binding_level): Filter out names that
> match anon_aggrname_p.
>
> gcc/testsuite/ChangeLog:
> Backport of r262199 from trunk.
> 2018-06-27 David Malcolm
>
> PR c++/86329
> * g++.dg/lookup/pr86329.C: New test.
>
>
> Added:
> branches/gcc-8-branch/gcc/testsuite/g++.dg/lookup/pr86329.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
So, since this fixed it for 8, just 7 is left, so changing the target milestone
to 7.4
[Bug rtl-optimization/90357] [9/10 regression][MIPS] New FAIL: gcc.c-torture/execute/20080502-1.c -O0 start with r269880
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90357 --- Comment #3 from paulhua at gcc dot gnu.org --- Author: paulhua Date: Tue May 14 03:25:38 2019 New Revision: 271147 URL: https://gcc.gnu.org/viewcvs?rev=271147=gcc=rev Log: Backport fix for PR90357. 2019-05-14 Chenghua Xu PR target/90357 * config/mips/mips.c (mips_split_move): Skip forward SRC into next insn when the SRC reg is dead. Modified: branches/gcc-9-branch/gcc/ChangeLog branches/gcc-9-branch/gcc/config/mips/mips.c
[Bug c++/90449] No way to turn off warning about inaccessible base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90449 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
[Bug rtl-optimization/90357] [9/10 regression][MIPS] New FAIL: gcc.c-torture/execute/20080502-1.c -O0 start with r269880
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90357 --- Comment #2 from paulhua at gcc dot gnu.org --- Author: paulhua Date: Tue May 14 01:42:59 2019 New Revision: 271146 URL: https://gcc.gnu.org/viewcvs?rev=271146=gcc=rev Log: [MIPS] Skip forward src into next insn when the SRC reg is dead. PR target/90357 gcc/ * config/mips/mips.c (mips_split_move): Skip forward SRC into next insn when the SRC reg is dead. Modified: trunk/gcc/ChangeLog trunk/gcc/config/mips/mips.c
[Bug middle-end/66661] incorrect memory access in optimization with flexible array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=1 --- Comment #14 from joseph at codesourcery dot com --- That wording is long including several examples. You can see it in http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf subclause 6.7.2.1 (C99 + TC1 + TC2 + TC3).
[Bug target/89424] __builtin_vec_ext_v1ti (v, i) results in ICE with variable i (RS6000)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89424 --- Comment #4 from kelvin at gcc dot gnu.org --- Author: kelvin Date: Mon May 13 21:27:29 2019 New Revision: 271137 URL: https://gcc.gnu.org/viewcvs?rev=271137=gcc=rev Log: gcc/ChangeLog: 2019-05-13 Kelvin Nilsen Backport from mainline. 2019-05-06 Kelvin Nilsen PR target/89424 * config/rs6000/rs6000.c (rs6000_expand_vector_extract): Add handling of V1TImode. gcc/testsuite/ChangeLog: 2019-05-13 Kelvin Nilsen Backport from mainline. 2019-05-06 Kelvin Nilsen PR target/89424 * gcc.target/powerpc/pr89424-0.c: New test. * gcc.target/powerpc/vsx-builtin-13a.c: Define macro PR89424 to enable testing of newly patched capability. * gcc.target/powerpc/vsx-builtin-13b.c: Likewise. * gcc.target/powerpc/vsx-builtin-20a.c: Likewise. * gcc.target/powerpc/vsx-builtin-20b.c: Likewise. Added: branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/pr89424-0.c Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/config/rs6000/rs6000.c branches/gcc-7-branch/gcc/testsuite/ChangeLog branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-13a.c branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-13b.c branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-20a.c branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-20b.c
[Bug libgcc/86215] Exceptions are broken on OSX when linking with -static-libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86215 --- Comment #3 from Iain Sandoe --- please could you print the output of: DYLD_PRINT_LIBRARIES=1 ./a.out
[Bug rtl-optimization/82636] powerpc: Unnecessary copy of __ieee128 parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82636 Tulio Magno Quites Machado Filho changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Tulio Magno Quites Machado Filho --- (In reply to Peter Bergner from comment #6) > Tulio and Mike, can you confirm that? Confirmed with GCC 8.3. Thanks!
[Bug target/90379] Gcc 9.1 fails "make check" on linux due to missing MacOS-specific header file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90379 Iain Sandoe changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #13 from Iain Sandoe --- fixed for trunk and 9.2
[Bug bootstrap/89864] gcc fails to build/bootstrap with XCode 10.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864 Bug 89864 depends on bug 90379, which changed state. Bug 90379 Summary: Gcc 9.1 fails "make check" on linux due to missing MacOS-specific header file https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90379 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug bootstrap/89864] gcc fails to build/bootstrap with XCode 10.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864 --- Comment #96 from Iain Sandoe --- Author: iains Date: Mon May 13 20:37:08 2019 New Revision: 271136 URL: https://gcc.gnu.org/viewcvs?rev=271136=gcc=rev Log: backport fix for PR90379 2019-05-13 Iain Sandoe Backport from mainline. 2019-05-11 Iain Sandoe PR target/90379 PR bootstrap/89864 * inclhack.def (darwin_ucred__Atomic): Do not supply test_text for wrap fixes. * fixincl.x: Regenerated. Modified: branches/gcc-9-branch/fixincludes/ChangeLog branches/gcc-9-branch/fixincludes/fixincl.x branches/gcc-9-branch/fixincludes/inclhack.def
[Bug target/90379] Gcc 9.1 fails "make check" on linux due to missing MacOS-specific header file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90379 --- Comment #12 from Iain Sandoe --- Author: iains Date: Mon May 13 20:37:08 2019 New Revision: 271136 URL: https://gcc.gnu.org/viewcvs?rev=271136=gcc=rev Log: backport fix for PR90379 2019-05-13 Iain Sandoe Backport from mainline. 2019-05-11 Iain Sandoe PR target/90379 PR bootstrap/89864 * inclhack.def (darwin_ucred__Atomic): Do not supply test_text for wrap fixes. * fixincl.x: Regenerated. Modified: branches/gcc-9-branch/fixincludes/ChangeLog branches/gcc-9-branch/fixincludes/fixincl.x branches/gcc-9-branch/fixincludes/inclhack.def
[Bug libstdc++/90454] filesystem::path template constructor void* overload interference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90454 --- Comment #3 from Jonathan Wakely --- Author: redi Date: Mon May 13 20:12:06 2019 New Revision: 271134 URL: https://gcc.gnu.org/viewcvs?rev=271134=gcc=rev Log: PR libstdc++/90454.cc path construction from void* Make the filesystem::path constructors SFINAE away for void* arguments, instead of giving an error due to iterator_traits::reference. PR libstdc++/90454.cc path construction from void* * include/bits/fs_path.h (path::_Path): Use remove_pointer so that pointers to void are rejected as well as void. * include/experimental/bits/fs_path.h (path::_Path): Likewise. * testsuite/27_io/filesystem/path/construct/80762.cc: Also check pointers to void. * testsuite/experimental/filesystem/path/construct/80762.cc: Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/fs_path.h trunk/libstdc++-v3/include/experimental/bits/fs_path.h trunk/libstdc++-v3/testsuite/27_io/filesystem/path/construct/80762.cc trunk/libstdc++-v3/testsuite/experimental/filesystem/path/construct/80762.cc
[Bug libstdc++/90454] filesystem::path template constructor void* overload interference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90454 --- Comment #2 from Jonathan Wakely --- C++20 fixes this by iterator_traits requires is_object_v. I think I have a patch implementing that for C++11 upwards...
[Bug libstdc++/90454] filesystem::path template constructor void* overload interference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90454 Jonathan Wakely changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-05-13 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- I'm testing this patch: --- a/libstdc++-v3/include/bits/fs_path.h +++ b/libstdc++-v3/include/bits/fs_path.h @@ -115,7 +115,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11 template using _Path = typename std::enable_if<__and_<__not_, path>>, - __not_>, + __not_>>, __constructible_from<_Tp1, _Tp2>>::value, path>::type;
[Bug libstdc++/90454] New: filesystem::path template constructor void* overload interference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90454
Bug ID: 90454
Summary: filesystem::path template constructor void* overload
interference
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: patrick.a.moran at gmail dot com
Target Milestone: ---
Created attachment 46349
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46349=edit
A reproduction of the issue described
I've marked the issue as 8.1.0 because that's the earliest version I've
confirmed it on, but I've seen it on 8.2.0, 8.3.0, 9.1.0, and the version that
godbolt.org was calling "HEAD" on 2019.05.10. I suspect it has been there as
long as has been present.
I attached a short reproduction. The end-user symptom is that if you have two
overloads of a function, one taking std::filesystem::path (or a const reference
thereto) and another taking void* (or a const reference thereto), then you
won't be able to pass a void* to the void*-taking function. You will get
${GCC_INSTALL}/include/c++/9.1.0/bits/stl_iterator_base_types.h: In
instantiation of ‘struct std::iterator_traits’:
${GCC_INSTALL}/include/c++/9.1.0/bits/fs_path.h:82:13: required by
substitution of ‘template using
__is_path_iter_src =
std::__and_::type>,
std::is_base_of > [with _Iter = void*; _Iter_traits =
std::iterator_traits]’
${GCC_INSTALL}/include/c++/9.1.0/bits/fs_path.h:89:7: required by
substitution of ‘template static
std::filesystem::__cxx11::path::__is_path_iter_src<_Iter>
std::filesystem::__cxx11::path::__is_path_src(_Iter, int) [with _Iter = void*]’
${GCC_INSTALL}/include/c++/9.1.0/bits/fs_path.h:113:31: required from ‘struct
std::filesystem::__cxx11::path::__constructible_from’
${GCC_INSTALL}/include/c++/9.1.0/type_traits:131:12: required from ‘struct
std::__and_ >,
std::filesystem::__cxx11::path::__constructible_from >’
${GCC_INSTALL}/include/c++/9.1.0/type_traits:136:12: required from ‘struct
std::__and_ >,
std::__not_ >,
std::filesystem::__cxx11::path::__constructible_from\
>’
${GCC_INSTALL}/include/c++/9.1.0/bits/fs_path.h:117:13: required by
substitution of ‘template using _Path = typename
std::enable_if >::type, st\
d::filesystem::__cxx11::path> >, std::__not_ >,
std::filesystem::__cxx11::path::__constructible_from<_Tp1, _Tp2> >::value,
std::filesystem::__cxx11::path>::type [with _Tp1 = void*; _Tp2 = void]’
${GCC_INSTALL}/include/c++/9.1.0/bits/fs_path.h:190:7: required by
substitution of ‘template
std::filesystem::__cxx11::path::path(const _Source&,
std::filesystem::__cxx11::path::format) [with _Source = void*; _Require = ]’
path_repro.cpp:7:21: required from here
${GCC_INSTALL}/include/c++/9.1.0/bits/stl_iterator_base_types.h:184:43: error:
forming reference to void
184 | typedef _Tp&reference;
| ^
I've traced the issue this far: std::filesystem::path has a predicate
__is_path_iter_src that is used through a chain of dependencies to
conditionally enable constructor #5 from 30.11.7.4.1 - the one taking a
template Source argument. That argument is supposed to be string-like, and
30.11.7.3 2 specifies that the constructor not take part in overload resolution
unless for the Source argument "the qualified-id
iterator_traits>::value_type is valid and denotes a possibly
const encoded character type"
The problem is that actually instantiating std::iterator_traits triggers
that "forming reference to void" error.
Because of this, constructor 5 is not being removed from the set of overloads,
we're encountering a compilation failure while in the process of determining if
it should participate in overload resolution.
The way this relates to the end-user symptom is that this compile-failure will
break the user's build, even though the overload that takes void* would be the
better match.
[Bug debug/90441] [9/10 Regression] corrupt debug info with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90441 --- Comment #17 from Iain Sandoe --- Created attachment 46348 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46348=edit binaries for test here is the output from trunk at 27 For some reason the plugin isn't getting the "-Wl,-debug" flag, so I hacked it to save the intermediates - that's a separate issue (and I should add -save-temps there too) - it does work for the collect2 case. Actually, a quick scan of the files, they seem sensible - but nm still barfs on the linked output. JFTR, I still can't see a difference between pre-linked and the tot ..
[Bug libstdc++/90440] [8/9/10 regression] Solaris/SPARC 10 fails to find
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90440 --- Comment #9 from Jonathan Wakely --- Any check I add to libstdc++ now isn't going to help the 8.3.0 and 9.1.0 releases anyway, so a workaround (like using Solaris ln, or passing LN_S="cp -pR" to make) will still be needed for them.
[Bug libstdc++/90440] [8/9/10 regression] Solaris/SPARC 10 fails to find
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90440 --- Comment #8 from Jonathan Wakely --- We just use the AC_PROG_LN_S test from autoconf, see https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Particular-Programs.html#index-AC_005fPROG_005fLN_005fS-287 Ideally that test would detect the problem and force LN_S="cp -pR" instead of using symlinks. But I'm not sure it's worth adding anything if the problem is limited to GNU coreutils 8.31 on Solaris 10, as that OS is obsolete and most of its users are going to use Solaris ln anyway.
[Bug c++/90426] [P0732] Error constructing non-type template parameter from a prvalue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90426 --- Comment #6 from Marek Polacek --- I posted a patch to improve diagnostics for this particular case: https://gcc.gnu.org/ml/gcc-patches/2019-05/msg00529.html
[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316 --- Comment #32 from Than McIntosh --- Compile time for the larger example looks good for the most recent commit on trunk (271124), ~130 seconds. Thanks for all your help on this.
[Bug c++/90432] [9/10 Regression] Internal compiler error with no_unique_address empty type with constructor call followed by value initialized to non-zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90432 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- Started with r268368.
[Bug libstdc++/62045] [5 Regression] __gnu_pbds::priority_queue, binary_heap_tag> is too slow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62045 --- Comment #20 from Jonathan Wakely --- (In reply to tobias.polzer from comment #19) > My perspective is that they would ideally be packaged separately, maybe > they would even find some love on GitHub The code would still exist, just not shipped in every GCC release (it changes on a very different timescale, approximately one patch per year, but adds a lot of headers and running the tests takes a long time). I would probably create a new project on sourceware.org with a git repo to host it (and it could be mirrored elsewhere). > That would obviously render them inaccessible to the programming > competition crowd (where restricted to basic libraries), but at least last > time I did ICPC, this was a trick very few people knew anyway. To be honest, that's not a use case I'm very concerned about. Thank you both for your replies.
[Bug libstdc++/90440] [8/9/10 regression] Solaris/SPARC 10 fails to find
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90440 --- Comment #7 from Christian Jullien --- The Solaris ln bug with 8.31 is described on this ticket: http://lists.gnu.org/archive/html/bug-coreutils/2019-03/msg00045.html If it is really the root of the reported issue, gcc is only culprit to not detect broken ln with configure. With 8.30 gcc continues to (slowly) build on my machine. It will finish by May, 15 (sic!)
[Bug bootstrap/90418] [10 Regression] powerpc-darwin9 bootstrap fails after r271013
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90418 --- Comment #13 from David Edelsohn --- Author: dje Date: Mon May 13 15:19:50 2019 New Revision: 271130 URL: https://gcc.gnu.org/viewcvs?rev=271130=gcc=rev Log: PR target/90418 * config/rs6000/rs6000.c (rs6000_emit_epilogue): Don't load EH data registers in sibcall epilogues. Don't add EH_RETURN_STACKADJ_RTX to sp in sibcall epilogues. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c
[Bug target/90453] New: PowerPC/AltiVec VSX: Provide vec_pack/vec_unpackh/vec_unpackl for 32<->64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90453 Bug ID: 90453 Summary: PowerPC/AltiVec VSX: Provide vec_pack/vec_unpackh/vec_unpackl for 32<->64 Product: gcc Version: 8.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: slandden at gmail dot com Target Milestone: --- I know these are not part of the spec, but it would make coding easier, as a GNU extension.
[Bug target/89221] --enable-frame-pointer does not work as intended
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89221 --- Comment #6 from uros at gcc dot gnu.org --- Author: uros Date: Mon May 13 14:58:38 2019 New Revision: 271129 URL: https://gcc.gnu.org/viewcvs?rev=271129=gcc=rev Log: PR target/89221 * configure.ac (--enable-frame-pointer): Disable by default for cygwin and mingw. * configure: Regenerate. Modified: trunk/gcc/ChangeLog trunk/gcc/configure trunk/gcc/configure.ac
[Bug target/90424] memcpy into vector builtin not optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90424
--- Comment #2 from Matthias Kretz ---
FWIW, I agree that "bit-inserting into a default-def" isn't a good idea. My
code, in the meantime, looks more like this (https://godbolt.org/z/D-yfZJ):
template
using V [[gnu::vector_size(16)]] = T;
template
V load(const void *p) {
V r = {};
__builtin_memcpy(, p, M);
return r;
}
I can't read the SSA code with certainty, but bit-inserting sounds like what I
want to have. Alternatively, the partial vector load could be implemented like
this - and looks even worse (https://godbolt.org/z/nJuTn-):
template
using V [[gnu::vector_size(16)]] = T;
template
V load(const void *p) {
const T* q = static_cast(p);
V r = {q[I]...};
return r;
}
// movq or movsd
template V load(const void *);
template V load(const void *);
template V load(const void *);
template V load(const void *);
template V load(const void *);
template V load(const void *);
// movd or movss
template V load(const void *);
template V load(const void *);
template V load(const void *);
template V load(const void *);
[Bug libstdc++/62045] [5 Regression] __gnu_pbds::priority_queue, binary_heap_tag> is too slow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62045 --- Comment #19 from tobias.polzer at gmail dot com --- My perspective is that they would ideally be packaged separately, maybe they would even find some love on GitHub That would obviously render them inaccessible to the programming competition crowd (where restricted to basic libraries), but at least last time I did ICPC, this was a trick very few people knew anyway. On Mon, May 13, 2019, 16:45 xry111 at mengyan1223 dot wang < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62045 > > --- Comment #17 from Xi Ruoyao --- > (In reply to Jonathan Wakely from comment #16) > > Tobias and Xi, does either of you actually use these PBDS containers for > > anything, or where you just looking at it for curiosity's sake? > > > > I'm considering whether it's worth keeping the code in libstdc++. > > We use it in programming contests to avoid coding for balanced BST and save > several minutes. But I think it's OK to remove these old code. Then we'll > just code a treap or splay. > > -- > You are receiving this mail because: > You are on the CC list for the bug. > You reported the bug.
[Bug libstdc++/62045] [5 Regression] __gnu_pbds::priority_queue, binary_heap_tag> is too slow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62045 --- Comment #18 from tobias.polzer at gmail dot com --- I used them in several toy programs, nothing "real". Apart from that I found their implementation interesting to study. On Mon, May 13, 2019, 16:41 redi at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62045 > > --- Comment #16 from Jonathan Wakely --- > Tobias and Xi, does either of you actually use these PBDS containers for > anything, or where you just looking at it for curiosity's sake? > > I'm considering whether it's worth keeping the code in libstdc++. > > -- > You are receiving this mail because: > You are on the CC list for the bug. > You reported the bug.
[Bug libstdc++/62045] [5 Regression] __gnu_pbds::priority_queue, binary_heap_tag> is too slow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62045 --- Comment #17 from Xi Ruoyao --- (In reply to Jonathan Wakely from comment #16) > Tobias and Xi, does either of you actually use these PBDS containers for > anything, or where you just looking at it for curiosity's sake? > > I'm considering whether it's worth keeping the code in libstdc++. We use it in programming contests to avoid coding for balanced BST and save several minutes. But I think it's OK to remove these old code. Then we'll just code a treap or splay.
[Bug libstdc++/62045] [5 Regression] __gnu_pbds::priority_queue, binary_heap_tag> is too slow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62045 --- Comment #16 from Jonathan Wakely --- Tobias and Xi, does either of you actually use these PBDS containers for anything, or where you just looking at it for curiosity's sake? I'm considering whether it's worth keeping the code in libstdc++.
[Bug c++/67960] [8/9/10 Regression] Prefixing a function with [[deprecated]] produces multiple warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67960 Eric Gallager changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=79078 --- Comment #4 from Eric Gallager --- (In reply to Jonathan Wakely from comment #2) > This is not a dup of PR 79078, because that's about issuing warnings in too > many places, this is just about issuing the same one too many times. > > This seems to have been fixed for GCC 7, as only one warning is given, but > then regressed for GCC 8, which gives two warnings. OK, so maybe not a dup, but it still seems related enough to go under "See Also"
[Bug c++/90449] No way to turn off warning about inaccessible base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90449 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org Blocks||44209 --- Comment #2 from Eric Gallager --- falls under the meta-bug of bug 44209 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44209 [Bug 44209] [meta-bug] Some warnings are not linked to diagnostics options
[Bug c++/90451] [7/8/9/10 Regression] "static" function which added "deprecated" print deprecated warning >1 times (twice or even 3 times)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90451 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=79078 --- Comment #4 from Eric Gallager --- I think bug 79078 is related, too
[Bug gcov-profile/90380] gcov issue: gets stuck (infinite loop?) while analyzing coverage on Fortran project
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90380 --- Comment #34 from Victor --- (In reply to Martin Liška from comment #26) > Created attachment 46336 [details] > Patch 2/2 Hi Martin, sorry for a newbie question ... but, which version this patch applies on? I mean, I would like to generate a Docker container applying this patch to gcc. For this purpose, I would like to take a recipe from https://github.com/docker-library/gcc, do some minor modifications (apply the patch) and compile/test our software. Can you point me to the right startpoint-recipe? Thanks in advance, Víctor
[Bug debug/90441] [9/10 Regression] corrupt debug info with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90441 --- Comment #16 from Richard Biener --- (In reply to Iain Sandoe from comment #14) > (In reply to Iain Sandoe from comment #13) > > (In reply to Iain Sandoe from comment #12) > > current trunk (27), manual regeneration of the > firmware.elf.ltrans0.ltrans.o -> > > (it's kinda frustrating that one can't see the link line, more tweaks are > still needed to help debug LTO - but putting -Wl,--verbose indicates that > the right number of files are presented to, and load correctly) > > iains@gcc122:~/gcc-trunk/C$ ../../llvm-710-build/bin/llvm-dwarfdump --verify > firmware.elf.ltrans0.ltrans.o > Verifying firmware.elf.ltrans0.ltrans.o: file format ELF64-x86-64 > Verifying .debug_abbrev... > Verifying .debug_info Unit Header Chain... > Verifying .debug_info references... > error: invalid DIE reference 0x001d. Offset is in between DIEs: > > 0x0038: DW_TAG_subprogram > DW_AT_abstract_origin (0x001d) > DW_AT_low_pc(0x) > DW_AT_high_pc (0x) > DW_AT_frame_base(DW_OP_call_frame_cfa) > DW_AT_GNU_all_call_sites(true) > > > error: invalid DIE reference 0x003b. Offset is in between DIEs: > > 0x004f: DW_TAG_variable > DW_AT_abstract_origin (0x003b) > DW_AT_location (DW_OP_addr 0x0) > > > Errors detected. Btw, this is quite natural if you inspect an object file! There are relocations for these "zero" values. And the final linked object looks fine in this regard. So throwing llvm-dwarfdump on an object file is a user error (or rather llvm-dwarfdump doesn't understand there can be relocations in DW_AT_abstract_origin for example).
[Bug debug/90441] [9/10 Regression] corrupt debug info with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90441 --- Comment #15 from Iain Sandoe --- this repeats for the compiler build from r267372, confirming some latent issue.
[Bug debug/90441] [9/10 Regression] corrupt debug info with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90441 --- Comment #14 from Iain Sandoe --- (In reply to Iain Sandoe from comment #13) > (In reply to Iain Sandoe from comment #12) current trunk (27), manual regeneration of the firmware.elf.ltrans0.ltrans.o -> (it's kinda frustrating that one can't see the link line, more tweaks are still needed to help debug LTO - but putting -Wl,--verbose indicates that the right number of files are presented to, and load correctly) iains@gcc122:~/gcc-trunk/C$ ../../llvm-710-build/bin/llvm-dwarfdump --verify firmware.elf.ltrans0.ltrans.o Verifying firmware.elf.ltrans0.ltrans.o:file format ELF64-x86-64 Verifying .debug_abbrev... Verifying .debug_info Unit Header Chain... Verifying .debug_info references... error: invalid DIE reference 0x001d. Offset is in between DIEs: 0x0038: DW_TAG_subprogram DW_AT_abstract_origin (0x001d) DW_AT_low_pc (0x) DW_AT_high_pc (0x) DW_AT_frame_base (DW_OP_call_frame_cfa) DW_AT_GNU_all_call_sites (true) error: invalid DIE reference 0x003b. Offset is in between DIEs: 0x004f: DW_TAG_variable DW_AT_abstract_origin (0x003b) DW_AT_location(DW_OP_addr 0x0) Errors detected.
[Bug preprocessor/90382] [10 Regression] ICE in linemap_macro_map_loc_to_exp_point, at libcpp/line-map.c:1061
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90382 --- Comment #7 from Paolo Carlini --- Beautiful, thanks Martin.
[Bug middle-end/90340] Not optimal code when compiling switch-case for size, code increase +35%
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90340 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #18 from Christophe Lyon --- The new test fails on aarch64: FAIL: gcc.dg/tree-ssa/pr90340-2.c scan-tree-dump switchlower1 ";; GIMPLE switch case clusters: 37 88 99 100 105 110 111 115 117 120" I compiled the testcase manually, and I can read: ;; GIMPLE switch case clusters: 37 88 99 100 105 JT:110-117 120
[Bug target/90061] ARM cortex-M hard fault on 64 bit sized object store to unaligned address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90061 Alexander Monakov changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #5 from Alexander Monakov --- One common cause for such issues is taking the address of an under-aligned field, assigning the misaligned address to a normal 'long *' pointer, and then trying to access the field via that pointer. Sometimes the compiler propagates alignment info for such pointers, but in general it can't (the code should use a typedef for a misaligned pointer). GCC 9 implemented a new warning, -Waddress-of-packed-member, to catch such misuse (although sadly it wouldn't trigger here due to #pragma pack, see PR 90452). Of course without seeing an example it's impossible to say what went wrong. Closing, please reopen or file a new bug when a testcase is available.
[Bug c/90452] New: no warning for misaligned pointer to #pragma-pack'ed fields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90452
Bug ID: 90452
Summary: no warning for misaligned pointer to #pragma-pack'ed
fields
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
GCC 9 introduced a new warning (-Waddress-of-packed-member) for situations
where the code tries to assign address of an under-aligned struct field to a
normal pointer (which should point to a properly aligned object).
However, the new warning doesn't trigger if unaligned fields appear under
#pragma pack (although funny that it works fine when -fpack-struct is given on
the command line):
#pragma pack(push,1)
struct
//__attribute__((packed))
s {
char c;
long l;
} *s;
#pragma pack(pop)
long *f()
{
return >l;
}
[Bug debug/90441] [9/10 Regression] corrupt debug info with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90441 --- Comment #13 from Iain Sandoe --- (In reply to Iain Sandoe from comment #12) > (In reply to rguent...@suse.de from comment #11) > > On Mon, 13 May 2019, iains at gcc dot gnu.org wrote: > > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90441 > > > > > > --- Comment #10 from Iain Sandoe --- > > > (In reply to Iain Sandoe from comment #9) > > > > this is on the rev *before* the change, using llvm-dwarfdump from the > > > > llvm-7 > > > > branch: > > > > > > > > iains@gcc122:~/gcc-trunk/A$ ../../llvm-710-build/bin/llvm-dwarfdump > > > > --verify > > > > firmware.elf > > > > Verifying firmware.elf: file format ELF64-x86-64 > > > > Verifying .debug_abbrev... > > > > Verifying .debug_info Unit Header Chain... > > > > Verifying .debug_info references... > > > > error: invalid DIE reference 0x. Offset is in between DIEs: > > > > > > so probably a missing pointer? > > > > It looks like an unresolved relocation - those are to be resolved > > from $label + offset where $label is defined in one of the early > > debug units. Maybe we miss one early debug file in the link? > > It doesn't seem so: > ../lto-a/bin/g++ -mtune=generic -march=x86-64 -r -nostdlib -o > /tmp/ccXK3OSgdebugobj /tmp/ccuTtXKldebugobjtem /tmp/ccjVk9Cqdebugobjtem > /tmp/ccodTovvdebugobjtem > > and they contain debug_info for the three object files. Which verifies (according to llvm-dwarfdump) and looks sane on readelf -wi. The -r output file is deleted for the prelink case, so can't easily check that. (since the problem exists before and after the change, perhaps I can find the rev that improves the save-temps)
[Bug libstdc++/90440] [8/9/10 regression] Solaris/SPARC 10 fails to find
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90440 --- Comment #6 from eligis at orange dot fr --- You gave me probably the root of this issue with "dir containing a symlink to the chosen file". In March, I switched from coreutils 8.30 to 8.31. Since then, trying to compile emacs failed because of a ln error as did recent gawk 5.0. I checked the coreutil ChangeLog which mentions some changes with ln command. After reinstalling 8.30 instead of 8.31, now both emacs and gawk compile smoothly. I'm currently recompiling gcc 9.1... I have a slow machine and it takes around 2 days to complete. It is very likely that ln failed but didn't stop the gcc build process. I'll let you informed of the result. Thanks for your first class support guys. -Original Message- From: redi at gcc dot gnu.org [mailto:gcc-bugzi...@gcc.gnu.org] Sent: Monday, May 13, 2019 11:41 To: jull...@eligis.com Subject: [Bug libstdc++/90440] [8/9/10 regression] Solaris/SPARC 10 fails to find https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90440 --- Comment #2 from Jonathan Wakely --- The libstdc++ config should select one of these headers to use: ./config/cpu/i486/opt/ext/opt_random.h ./config/cpu/aarch64/opt/ext/opt_random.h ./config/cpu/generic/opt/ext/opt_random.h There should be an "ext" dir containing a symlink to the chosen file, which will be found by -I/export/home/jullien/gcc-8.3.0/obj/sparc-sun-solaris2.10/libstdc++-v3/include/sparc-sun-solaris2.10 It's possible that for --enable-obsolete this isn't set up correctly (although I think solaris2.10 is only obsolete for gcc-9 not gcc-8).
[Bug debug/90441] [9/10 Regression] corrupt debug info with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90441 --- Comment #12 from Iain Sandoe --- (In reply to rguent...@suse.de from comment #11) > On Mon, 13 May 2019, iains at gcc dot gnu.org wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90441 > > > > --- Comment #10 from Iain Sandoe --- > > (In reply to Iain Sandoe from comment #9) > > > this is on the rev *before* the change, using llvm-dwarfdump from the > > > llvm-7 > > > branch: > > > > > > iains@gcc122:~/gcc-trunk/A$ ../../llvm-710-build/bin/llvm-dwarfdump > > > --verify > > > firmware.elf > > > Verifying firmware.elf: file format ELF64-x86-64 > > > Verifying .debug_abbrev... > > > Verifying .debug_info Unit Header Chain... > > > Verifying .debug_info references... > > > error: invalid DIE reference 0x. Offset is in between DIEs: > > > > so probably a missing pointer? > > It looks like an unresolved relocation - those are to be resolved > from $label + offset where $label is defined in one of the early > debug units. Maybe we miss one early debug file in the link? It doesn't seem so: ../lto-a/bin/g++ -mtune=generic -march=x86-64 -r -nostdlib -o /tmp/ccXK3OSgdebugobj /tmp/ccuTtXKldebugobjtem /tmp/ccjVk9Cqdebugobjtem /tmp/ccodTovvdebugobjtem and they contain debug_info for the three object files.
[Bug lto/69254] [6 Regression] ICE in streamer_get_builtin_tree when using -fsanitize=shift on the compile side only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69254 Martin Liška changed: What|Removed |Added CC||fab...@ritter-vogt.de --- Comment #20 from Martin Liška --- *** Bug 61048 has been marked as a duplicate of this bug. ***
[Bug lto/61048] compiling with -fsanitize=address crashes GCC if pointers are used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61048 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||marxin at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #8 from Martin Liška --- It's already fixed. *** This bug has been marked as a duplicate of bug 69254 ***
[Bug tree-optimization/90402] [9 Regression] ICE in slpeel_duplicate_current_defs_from_edges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90402 Richard Biener changed: What|Removed |Added Known to work||10.0 Summary|[9/10 Regression] ICE in|[9 Regression] ICE in |slpeel_duplicate_current_de |slpeel_duplicate_current_de |fs_from_edges |fs_from_edges Known to fail||9.1.0 --- Comment #6 from Richard Biener --- Fixed on trunk sofar.
[Bug tree-optimization/90402] [9/10 Regression] ICE in slpeel_duplicate_current_defs_from_edges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90402 --- Comment #5 from Richard Biener --- Author: rguenth Date: Mon May 13 11:37:21 2019 New Revision: 271125 URL: https://gcc.gnu.org/viewcvs?rev=271125=gcc=rev Log: 2019-05-13 Richard Biener PR tree-optimization/90402 * tree-if-conv.c (tree_if_conversion): Value number only the loop body by making the latch an exit of the region as well. * tree-ssa-sccvn.c (process_bb): Add flag whether to skip processing PHIs. (do_rpo_vn): Deal with multiple edges into the entry block that are not backedges inside the region by skipping PHIs of the entry block. * gcc.dg/torture/pr90402-1.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr90402-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-if-conv.c trunk/gcc/tree-ssa-sccvn.c
[Bug debug/90441] [9/10 Regression] corrupt debug info with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90441 --- Comment #11 from rguenther at suse dot de --- On Mon, 13 May 2019, iains at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90441 > > --- Comment #10 from Iain Sandoe --- > (In reply to Iain Sandoe from comment #9) > > this is on the rev *before* the change, using llvm-dwarfdump from the llvm-7 > > branch: > > > > iains@gcc122:~/gcc-trunk/A$ ../../llvm-710-build/bin/llvm-dwarfdump --verify > > firmware.elf > > Verifying firmware.elf: file format ELF64-x86-64 > > Verifying .debug_abbrev... > > Verifying .debug_info Unit Header Chain... > > Verifying .debug_info references... > > error: invalid DIE reference 0x. Offset is in between DIEs: > > so probably a missing pointer? It looks like an unresolved relocation - those are to be resolved from $label + offset where $label is defined in one of the early debug units. Maybe we miss one early debug file in the link?
[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316 --- Comment #31 from Richard Biener --- Author: rguenth Date: Mon May 13 11:22:21 2019 New Revision: 271124 URL: https://gcc.gnu.org/viewcvs?rev=271124=gcc=rev Log: 2019-05-13 Richard Biener PR tree-optimization/90316 * tree-ssa-pre.c (insert_aux): Fold into ... (insert): ... this function. Use a RPO walk to reduce the number of required iterations. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-pre.c
[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316 --- Comment #30 from Richard Biener --- Created attachment 46347 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46347=edit incremental patch Unfortunately the 46339 attachment failed during bootstrap compare. The attached one incrementally changes the iteration scheme from dominator-based to RPO-based which should strictly interate less. If that provides a reasonable speedup on its own it would be also a candidate for backporting.
[Bug debug/90441] [9/10 Regression] corrupt debug info with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90441 --- Comment #10 from Iain Sandoe --- (In reply to Iain Sandoe from comment #9) > this is on the rev *before* the change, using llvm-dwarfdump from the llvm-7 > branch: > > iains@gcc122:~/gcc-trunk/A$ ../../llvm-710-build/bin/llvm-dwarfdump --verify > firmware.elf > Verifying firmware.elf: file format ELF64-x86-64 > Verifying .debug_abbrev... > Verifying .debug_info Unit Header Chain... > Verifying .debug_info references... > error: invalid DIE reference 0x. Offset is in between DIEs: so probably a missing pointer?
[Bug debug/90441] [9/10 Regression] corrupt debug info with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90441 --- Comment #9 from Iain Sandoe --- this is on the rev *before* the change, using llvm-dwarfdump from the llvm-7 branch: iains@gcc122:~/gcc-trunk/A$ ../../llvm-710-build/bin/llvm-dwarfdump --verify firmware.elf Verifying firmware.elf: file format ELF64-x86-64 Verifying .debug_abbrev... Verifying .debug_info Unit Header Chain... Verifying .debug_info references... error: invalid DIE reference 0x. Offset is in between DIEs: 0x0029: DW_TAG_imported_unit DW_AT_import (0x) 0x002e: DW_TAG_imported_unit DW_AT_import (0x) 0x0033: DW_TAG_imported_unit DW_AT_import (0x) 0x0038: DW_TAG_subprogram DW_AT_abstract_origin (0x) DW_AT_low_pc (0x004003b0) DW_AT_high_pc (0x004003b0) DW_AT_frame_base (DW_OP_call_frame_cfa) DW_AT_GNU_all_call_sites (true) 0x004f: DW_TAG_variable DW_AT_abstract_origin (0x) DW_AT_location(DW_OP_addr 0x0) Errors detected.
[Bug gcov-profile/90380] gcov issue: gets stuck (infinite loop?) while analyzing coverage on Fortran project
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90380 --- Comment #33 from Martin Liška --- (In reply to Victor from comment #32) > (In reply to Martin Liška from comment #31) > > Fixed on trunk so far. > > Thanks Martin! > > is this going to be released within 8.X or 9.X branches/versions? Yes, the fix will be in GCC 8.4.0 and GCC 9.2.0 when they are released.
[Bug debug/90441] [9/10 Regression] corrupt debug info with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90441
--- Comment #8 from Richard Biener ---
nm -l fw.elf
also complains
nm: BFD (GNU Binutils; devel:gcc / openSUSE_Leap_42.3) 2.31.1.20180828-334
assertion fail ../../bfd/dwarf2.c:3750
nm: BFD (GNU Binutils; devel:gcc / openSUSE_Leap_42.3) 2.31.1.20180828-334
assertion fail ../../bfd/dwarf2.c:3750
iff trunk is still the same as 2.31.1 then this is
static bfd_boolean
comp_unit_hash_info (struct dwarf2_debug *stash,
struct comp_unit *unit,
struct info_hash_table *funcinfo_hash_table,
struct info_hash_table *varinfo_hash_table)
{
...
BFD_ASSERT (!unit->cached);
where it might be confused about abstract origins crossing CU boundaries.
[Bug debug/90441] [9/10 Regression] corrupt debug info with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90441 --- Comment #7 from Richard Biener --- Btw, I can reproduce the nm error when linking w/o the linker script. But readelf is happy about the dwarf. I'm not sure what the llvm dwarf linter complains about with error: DIE address ranges are not contained in its parent's ranges: but it doesnt' complain about the abbrev issue nm complains about. nm bug?
[Bug preprocessor/90382] [10 Regression] ICE in linemap_macro_map_loc_to_exp_point, at libcpp/line-map.c:1061
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90382 Martin Liška changed: What|Removed |Added Status|RESOLVED|ASSIGNED Resolution|FIXED |--- --- Comment #6 from Martin Liška --- (In reply to Martin Liška from comment #5) > (In reply to Paolo Carlini from comment #4) > > Done. Somebody should however look into linemap_location_before_p & co a bit > > more, because frankly my patchlet should not have caused a problem, likely > > it just uncovered a latent issue of some sort: it simply uses min_location, > > which, in turn, only calls linemap_location_before_p when both the passed > > locations are != UNKNOWN_LOCATION, thus safe AFAICS. > > David, can you please take a look? I'm working on that and I have a patch candidate. Let me test it ..
[Bug libstdc++/90361] [9/10 Regression] Undefined symbols in libstdc++ when building with --with-default-libstdcxx-abi=gcc4-compatible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90361 --- Comment #6 from Viktor Ostashevskyi --- (In reply to Viktor Ostashevskyi from comment #5) > It would be nice at least document that for GCC 9.1.0 building with > --with-default-libstdcxx-abi=gcc4-compatible is broken. > > Possible workaround is to build with default parameters and change > _GLIBCXX_USE_DUAL_ABI define to 1 in bits/c++config.h after 'make install'. s/_GLIBCXX_USE_DUAL_ABI define to 1/_GLIBCXX_USE_CXX11_ABI define to 0/
[Bug gcov-profile/90380] gcov issue: gets stuck (infinite loop?) while analyzing coverage on Fortran project
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90380 --- Comment #32 from Victor --- (In reply to Martin Liška from comment #31) > Fixed on trunk so far. Thanks Martin! is this going to be released within 8.X or 9.X branches/versions?
[Bug debug/90441] [9/10 Regression] corrupt debug info with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90441 --- Comment #6 from Iain Sandoe --- (In reply to Richard Biener from comment #5) > Before the bisection the linker script probably managed to "fix" the debug > info > but the issue was latent. Without the linker script it works fine for me. > With the script I get > > /usr/bin/ld: fw.elf: not enough room for program headers, try linking with -N > /usr/bin/ld: final link failed: bad value > collect2: error: ld returned 1 exit status > > when I add -nostdlib it works fine again. > > So - can't really reproduce. built pre-rev and rev. I get the same result as Richi, with the script "not enough room for program headers" Removing the script the link succeeds in both cases - and the error below is present before and after the revision mentioned (so I concur that the revision is simply exposing a latent issue). - iains@gcc122:~/gcc-trunk/A$ nm -ClS --radix=d --size-sort firmware.elf 06295576 0001 b completed.7325nm: BFD (GNU Binutils for Debian) 2.28 internal error, aborting at ../../bfd/dwarf2.c:2505 in find_abstract_instance_name nm: Please report this bug.
[Bug libstdc++/90361] [9/10 Regression] Undefined symbols in libstdc++ when building with --with-default-libstdcxx-abi=gcc4-compatible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90361 --- Comment #5 from Viktor Ostashevskyi --- It would be nice at least document that for GCC 9.1.0 building with --with-default-libstdcxx-abi=gcc4-compatible is broken. Possible workaround is to build with default parameters and change _GLIBCXX_USE_DUAL_ABI define to 1 in bits/c++config.h after 'make install'.
[Bug tree-optimization/90450] Hash function in gather_mem_refs_stmt does not match with mem_ref_hasher::equal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90450
--- Comment #4 from Richard Biener ---
OK, so it's not operand_equal_p of d[f.1_1] and d[0] returning true but
the comparison involving the ao_ref pieces. And indeed the variable-offset
one is fenced off by
&& (mem_base = get_addr_base_and_unit_offset (aor.ref, _off)))
but using max_size == -1 as tie-breaker doesn't work for the entities in
the hash-table (we never compare!) because we only use max_size == -1
on the on-stack ref we use for the find_slot_with_hash call but actually
insert the original value:
...
else
{
hash = iterative_hash_expr (aor.ref, 0);
aor.max_size = -1;
}
slot = memory_accesses.refs->find_slot_with_hash (, hash, INSERT);
aor.max_size = saved_maxsize;
so the checking code is "flawed"... (I thought we didn't want to lose
the extra disambiguation opportunity from having known max_size).
So - not really a bug.
Could be worked around by extra runtime overhead checking everything
we check before the decision on the hashing scheme also in the equality
routine. Or finding some spare bit in the non-loop-IM private ao_ref
stucture. Or constructing a full im_mem_ref on the stack even if
hash lookup only really needs the ao_ref and put this extra bit there.
Bah :/
Guard the checking on entry type == comparable type?
[Bug sanitizer/90414] [Feature] Implementing HWASAN (and eventually MTE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90414 --- Comment #4 from Matthew Malcomson --- (In reply to Martin Liška from comment #3) > (In reply to Matthew Malcomson from comment #0) > > 2) Can we always find the base object that's being referenced from the > > gimple > >statement where memory is accessed or a pointer is created? > >If not, when is it problematic? > >Finding the base object is pretty fundamental to getting the tag for a > >pointer. > >It seems like this should be possible based on a reading of the > > documentation > >and looking at the TREE_CODEs that the current ASAN `instrument_derefs` > >function works on. > > > >(ARRAY_REF -> first operand is the array > > MEM_REF -> first operand is the base > > COMPONENT_REF -> first operand is the object > > INDIRECT_REF -> first operand is the pointer which should reference > > object > > VAR_DECL -> this is the object > > BIT_FIELD_REF -> first operand is the object) > > There would be cases where a base is known and for these you could probably > instrument checks with a constant known tag. For other situation, you'll > probably > need to extract the tag from the pointer. Right? > Yes, I'll need to extract the tag from the pointer in cases that don't match one of these patterns. That actually leads into something I forgot to mention when I wrote the comment above -- I'll need to instrument ADDR_EXPR statements to make sure any pointers in the program will already have their tag assigned. To do that I think I need to add another instrumentation site for when the address of something is taken to handle for any statements taking the address of something. This may be by adding another if statement in `transform_statements` to make this transformation before the one instrumenting the actual access, or it may be in a separate iteration before the one inserting the current checks since statements like the below would need to be split to instrument the ADDR_EXPR and MEM_REF expressions seperately. MEM[(int *)_object] = direction_8(D); > > > > Thanks, > > MM > > In general, I'm interested in implementation of the feature, but I'll > probably not > find a time to do it. However, I can help you with that. Great! I'll appreciate any help and/or advice you can give.
[Bug middle-end/90340] Not optimal code when compiling switch-case for size, code increase +35%
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90340 --- Comment #17 from Martin Liška --- (In reply to Fredrik Hederstierna from comment #16) > Still you cannot reach code size as gcc-8.3.0 ? So something in new > switch-case compilation generates larger code still? The biggest difference from GCC 8 is that we can emit jump table for a subset of cases. That's what happening for the reported test-case. In generate, GCC 9+ sees more opportunities for jump tables.
[Bug tree-optimization/90450] Hash function in gather_mem_refs_stmt does not match with mem_ref_hasher::equal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90450 --- Comment #3 from rguenther at suse dot de --- On Mon, 13 May 2019, marxin at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90450 > > --- Comment #2 from Martin Liška --- > (In reply to Richard Biener from comment #1) > > Not exactly sure what happens, need to investigate. The testcase looks > > innocous enough at least ... > > It's about 'd[f]' and 'd[0]' references. The former one is hashed in else > branch and the later > in true branch. These are then equal in mem_ref_hasher::equal as > operand_equal_p can return true > for these 2 array references. Huh? Would have to debug this. The equality function probably should start with if (mem1->mem.max_size_known_p () != obj2->max_size_known_p ()) return false; which may fix the issue. As said, need to reproduce locally.
[Bug tree-optimization/90416] [9/10 Regression] ICE in dump_generic_node at tree-pretty-print.c:1383
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90416 Martin Liška changed: What|Removed |Added Known to work||10.0 Known to fail|10.0| --- Comment #7 from Martin Liška --- Fixed on trunk so far.
[Bug tree-optimization/90416] [9/10 Regression] ICE in dump_generic_node at tree-pretty-print.c:1383
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90416 --- Comment #6 from Martin Liška --- Author: marxin Date: Mon May 13 10:26:09 2019 New Revision: 271118 URL: https://gcc.gnu.org/viewcvs?rev=271118=gcc=rev Log: Fix wrong usage of dump_printf_loc (PR tree-optimization/90416). 2019-05-13 Martin Liska PR tree-optimization/90416 * tree-vect-stmts.c (vect_check_load_store_mask): Concatenate string instead of passing the second part as va_arg argument. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vect-stmts.c
[Bug middle-end/90340] Not optimal code when compiling switch-case for size, code increase +35%
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90340 --- Comment #16 from Fredrik Hederstierna --- Still you cannot reach code size as gcc-8.3.0 ? So something in new switch-case compilation generates larger code still?
[Bug tree-optimization/90450] Hash function in gather_mem_refs_stmt does not match with mem_ref_hasher::equal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90450
--- Comment #2 from Martin Liška ---
(In reply to Richard Biener from comment #1)
> Not exactly sure what happens, need to investigate. The testcase looks
> innocous enough at least ...
It's about 'd[f]' and 'd[0]' references. The former one is hashed in else
branch and the later
in true branch. These are then equal in mem_ref_hasher::equal as
operand_equal_p can return true
for these 2 array references.
1479if (aor.max_size_known_p ()
1480&& aor.offset.is_constant ()
1481&& aor.size.is_constant ()
1482&& aor.max_size.is_constant (_size)
1483&& size == max_size
1484&& (size % BITS_PER_UNIT) == 0
1485/* We're canonicalizing to a MEM where TYPE_SIZE specifies
the
1486 size. Make sure this is consistent with the extraction.
*/
1487&& poly_int_tree_p (TYPE_SIZE (TREE_TYPE (*mem)))
1488&& known_eq (wi::to_poly_offset (TYPE_SIZE (TREE_TYPE
(*mem))),
1489 aor.size)
1490&& (mem_base = get_addr_base_and_unit_offset (aor.ref,
_off)))
1491 {
1492hash = iterative_hash_expr (ao_ref_base (), 0);
1493hash = iterative_hash_host_wide_int (offset, hash);
1494hash = iterative_hash_host_wide_int (size, hash);
1495 }
1496else
1497 {
1498hash = iterative_hash_expr (aor.ref, 0);
1499aor.max_size = -1;
1500 }
[Bug c++/90451] [7/8/9/10 Regression] "static" function which added "deprecated" print deprecated warning >1 times (twice or even 3 times)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90451 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |7.5
[Bug libstdc++/90440] [8/9/10 regression] Solaris/SPARC 10 fails to find
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90440 Jonathan Wakely changed: What|Removed |Added CC||ro at gcc dot gnu.org Severity|major |normal --- Comment #5 from Jonathan Wakely --- Rainer still seems to be able to build both gcc-8-branch and gcc-9-branch for sparc-sun-solaris2.10: https://gcc.gnu.org/ml/gcc-testresults/2019-05/msg01251.html https://gcc.gnu.org/ml/gcc-testresults/2019-05/msg01152.html That suggests the problem is local, not caused by my change.
[Bug tree-optimization/90450] Hash function in gather_mem_refs_stmt does not match with mem_ref_hasher::equal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90450 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-05-13 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Not exactly sure what happens, need to investigate. The testcase looks innocous enough at least ...
[Bug c++/67371] Never executed "throw" in constexpr function fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67371 --- Comment #17 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #16) > I'd guess it was fixed by the patch for PR 86678. Confirmed, it was fixed by r264171 for PR 86678.
[Bug c++/86678] constexpr evaluation incorrectly diagnoses unevaluated call to non-constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86678 --- Comment #8 from Jonathan Wakely --- (In reply to Ville Voutilainen from comment #7) > *** Bug 67026 has been marked as a duplicate of this bug. *** Confirmed, it was fixed by r264171 for PR 67026.
[Bug libstdc++/90440] [8/9/10 regression] Solaris/SPARC 10 fails to find
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90440 --- Comment #4 from Jonathan Wakely --- Christian, could you please show the output of ls -lR /export/home/jullien/gcc-8.3.0/obj/sparc-sun-solaris2.10/libstdc++-v3/include/sparc-sun-solaris2.10
[Bug libstdc++/90440] [8/9/10 regression] Solaris/SPARC 10 fails to find
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90440 --- Comment #3 from Jonathan Wakely --- I don't see how changing "" to <> can make any difference. If the symlink is present in /export/home/jullien/gcc-8.3.0/obj/sparc-sun-solaris2.10/libstdc++-v3/include/sparc-sun-solaris2.10 then it will be found by either form of #include directive. If it isn't present, neither will work. The header that includes is in /export/home/jullien/gcc-8.3.0/obj/sparc-sun-solaris2.10/libstdc++-v3/include/ and so #include "ext/opt_random.h" should always have found it via the -I include paths anyway.
[Bug c++/90448] [8/9/10 Regression] decltype-based lambda parameter pack is rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90448 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |8.4
[Bug debug/90441] [9/10 Regression] corrupt debug info with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90441 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #5 from Richard Biener --- Before the bisection the linker script probably managed to "fix" the debug info but the issue was latent. Without the linker script it works fine for me. With the script I get /usr/bin/ld: fw.elf: not enough room for program headers, try linking with -N /usr/bin/ld: final link failed: bad value collect2: error: ld returned 1 exit status when I add -nostdlib it works fine again. So - can't really reproduce.
[Bug middle-end/90340] Not optimal code when compiling switch-case for size, code increase +35%
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90340 --- Comment #15 from Martin Liška --- With addition of the arguments users can drive code growth more fine. May I close this PR as resolved?
[Bug libstdc++/90440] [8/9/10 regression] Solaris/SPARC 10 fails to find
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90440 --- Comment #2 from Jonathan Wakely --- The libstdc++ config should select one of these headers to use: ./config/cpu/i486/opt/ext/opt_random.h ./config/cpu/aarch64/opt/ext/opt_random.h ./config/cpu/generic/opt/ext/opt_random.h There should be an "ext" dir containing a symlink to the chosen file, which will be found by -I/export/home/jullien/gcc-8.3.0/obj/sparc-sun-solaris2.10/libstdc++-v3/include/sparc-sun-solaris2.10 It's possible that for --enable-obsolete this isn't set up correctly (although I think solaris2.10 is only obsolete for gcc-9 not gcc-8).
[Bug tree-optimization/90416] [10 Regression] ICE in dump_generic_node at tree-pretty-print.c:1383
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90416 Martin Liška changed: What|Removed |Added Assignee|dmalcolm at gcc dot gnu.org|marxin at gcc dot gnu.org --- Comment #5 from Martin Liška --- I've got a patch for it.
[Bug tree-optimization/90437] Overflow detection too late for VRP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90437 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-05-13 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- VRP obviously only sees a + b in [0, 20] and [0, 20] < [0, 10] as unknown.
[Bug c++/90451] [7/8/9/10 Regression] "static" function which added "deprecated" print deprecated warning >1 times (twice or even 3 times)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90451
Jonathan Wakely changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
Known to work||4.9.4
Summary|"static" function which |[7/8/9/10 Regression]
|added "deprecated" print|"static" function which
|deprecated warning >1 times |added "deprecated" print
|(twice or even 3 times) |deprecated warning >1 times
||(twice or even 3 times)
Known to fail||10.0, 5.5.0, 6.5.0, 7.4.0,
||8.3.0, 9.1.0
--- Comment #3 from Jonathan Wakely ---
Using GNU attribute syntax this version compiles with GCC 4.9 and only gives
one warning, but gives two with GCC 5:
struct myclass{
__attribute__((deprecated("deprecated the static")))
static void static_deprecate() { }
};
int main()
{
myclass::static_deprecate();
}
The duplicate diagnostic first appeared with r217677:
PR c++/33911
gcc/cp/
* call.c (build_call_a): Don't warn_deprecated_use here.
(build_over_call): Or here.
* decl2.c (mark_used): Do it here.
(is_late_template_attribute): Attribute deprecated is not deferred.
(cplus_decl_attributes): Propagate TREE_DEPRECATED out to the
template.
* parser.c (cp_parser_template_name): Warn about deprecated
template.
(cp_parser_template_argument): Likewise.
libstdc++-v3/
* include/backward/binders.h: Suppress -Wdeprecated-declarations.
* include/ext/array_allocator.h: Likewise.
[Bug c++/90451] "static" function which added "deprecated" print deprecated warning >1 times (twice or even 3 times)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90451
--- Comment #2 from Jonathan Wakely ---
For this reduced version (without the non-static function which is correctly
only getting one warning):
struct myclass{
[[deprecated("deprecated the static")]]
static void static_deprecate() { }
};
int main()
{
myclass v;
myclass::static_deprecate();
v.static_deprecate();
}
GCC 7 gives three warnings:
90451.cc: In function 'int main()':
90451.cc:10:14: warning: 'static void myclass::static_deprecate()' is
deprecated: deprecated the static [-Wdeprecated-declarations]
myclass::static_deprecate();
^~~~
90451.cc:3:17: note: declared here
static void static_deprecate() { }
^~~~
90451.cc:10:31: warning: 'static void myclass::static_deprecate()' is
deprecated: deprecated the static [-Wdeprecated-declarations]
myclass::static_deprecate();
^
90451.cc:3:17: note: declared here
static void static_deprecate() { }
^~~~
90451.cc:11:24: warning: 'static void myclass::static_deprecate()' is
deprecated: deprecated the static [-Wdeprecated-declarations]
v.static_deprecate();
^
90451.cc:3:17: note: declared here
static void static_deprecate() { }
^~~~
Notice the two different locations for the qualified call:
myclass::static_deprecate();
^~~~
myclass::static_deprecate();
^
The v.static_deprecate() call correctly only gets one warning.
But then with GCC 8 after r259067 there are three warnings for the qualified
call, with these locations:
myclass::static_deprecate();
^~~~
myclass::static_deprecate();
^
myclass::static_deprecate();
^
and two for the member access expression, both with the same location:
v.static_deprecate();
^
v.static_deprecate();
^
The regression due to r259067 is tracked by PR 67960.
[Bug tree-optimization/90433] POINTER_DIFF_EXPR in vectorizer prologue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90433 Richard Biener changed: What|Removed |Added Keywords||missed-optimization, ||wrong-code CC||rguenth at gcc dot gnu.org --- Comment #1 from Richard Biener --- Needs to be looked at indeed.
[Bug c++/90432] [9/10 Regression] Internal compiler error with no_unique_address empty type with constructor call followed by value initialized to non-zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90432 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Status|UNCONFIRMED |NEW Known to work||8.3.0 Keywords||ice-on-valid-code Last reconfirmed||2019-05-13 Ever confirmed|0 |1 Summary|Internal compiler error |[9/10 Regression] Internal |with no_unique_address |compiler error with |empty type with constructor |no_unique_address empty |call followed by value |type with constructor call |initialized to non-zero |followed by value ||initialized to non-zero Target Milestone|--- |9.2 --- Comment #1 from Richard Biener --- Confirmed. GCC 8 ignores the attribute and works.
[Bug middle-end/90427] missing "sign flipping" optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90427 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2019-05-13 Component|tree-optimization |middle-end Ever confirmed|0 |1 --- Comment #3 from Richard Biener --- Confirmed.
[Bug target/90424] memcpy into vector builtin not optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90424
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2019-05-13
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
Ick, C++ ... so I see for example
load (const void * p)
{
W r;
long unsigned int _3;
V _5;
[local count: 1073741824]:
_3 = MEM[(char * {ref-all})p_2(D)];
MEM[(char * {ref-all})] = _3;
_5 = r;
r ={v} {CLOBBER};
return _5;
but it's not clear to me whether W is a vector type and whether r could
be re-written into SSA form or not.
Good one(?)
load (const void * p)
{
W r;
long unsigned int _3;
long int _4;
[local count: 1073741824]:
_3 = MEM[(char * {ref-all})p_2(D)];
_4 = (long int) _3;
r_6 = BIT_INSERT_EXPR ;
return r_6;
note that bit-inserting into a default-def probably isn't the best thing
to do, but well.
Another variant:
load (const void * p)
{
W r;
long unsigned int _3;
double _4;
[local count: 1073741824]:
_3 = MEM[(char * {ref-all})p_2(D)];
_4 = VIEW_CONVERT_EXPR(_3);
r_6 = BIT_INSERT_EXPR ;
return r_6;
so the bad variants are where we retain the aggregate copy.
So for the first case above we have
unit-size
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x768983f0 precision:8 min max
pointer_to_this >
sizes-gimplified V16QI
size
unit-size
align:128 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x769a0b28 nunits:16
pointer_to_this >
addressable used tree_1 read decl_1 decl_5 V16QI t.ii:7:5 size unit-size
align:128 warn_if_not_align:0 context >
but then we fail to rewrite this into SSA because the
MEM[(char * {ref-all})] = _3;
assign is a partial assign of a 'long' value into a vector vector.
Currently BIT_INSERT_EXPR is restricted to insertion of vector type
components so we'd have to apply a series of VIEW_CONVERT_EXPRs to 'r'
to insert _3 or alternatively allow upper/lower halves, like inserting
v4qi into v16qi at position 0, 4, 8 or 12, where we then only would
have to VIEW_CONVERT _3.
Note in the end it will matter what targets implement, otherwise you'll
get spilling if we have to go through memory for the insertion.
I will look into changing SSA rewrite in one or other way.
[Bug debug/90422] DW_AT_main_subprogram not added to CU DIE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90422 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-05-13 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed.
[Bug c++/67960] [8/9/10 Regression] Prefixing a function with [[deprecated]] produces multiple warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67960 Jonathan Wakely changed: What|Removed |Added CC||aoliva at gcc dot gnu.org --- Comment #3 from Jonathan Wakely --- This regressed with r259067: [PR c++/84943] mark function as used when taking its address fn[0]() ICEd because we would fold the INDIRECT_REF used for the array indexing while building the address for the call, after not finding the decl hiding there at first. But the decl would be exposed by the folding, and then lower layers would complain we had the decl, after all, but it wasn't one of the artificial or special functions that could be called without being marked as used. This patch arranges for a FUNCTION_DECL to be marked as used when taking its address, just like we already did when taking the address of a static function to call it as a member function (i.e. using the obj.fn() notation). However, we shouldn't mark functions as used when just performing overload resolution, lest we might instantiate templates we shouldn't, as in g++.dg/overload/template1.C, so we adjust mark_used to return early when testing conversions. for gcc/cp/ChangeLog PR c++/84943 * typeck.c (cp_build_addr_expr_1): Mark FUNCTION_DECL as used. * decl2.c (mark_used): Return without effects if tf_conv. for gcc/testsuite/ChangeLog PR c++/84943 * g++.dg/pr84943.C: New. * g++.dg/pr84943-2.C: New.
[Bug c++/90451] "static" function which added "deprecated" print deprecated warning >1 times (twice or even 3 times)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90451
Jonathan Wakely changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-05-13
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=67960
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely ---
Testcase reduced from the attached tar file (we don't need an archive
containing compiled binaries);
class myclass{
private:
int a=0;
public:
[[deprecated("deprecated")]]
void deprecate_function() { }
[[deprecated("deprecated the static")]]
static void static_deprecate() { }
};
int main()
{
myclass v;
v.deprecate_function();
myclass::static_deprecate();
v.static_deprecate();
}
This got worse with GCC 8, so is related to PR 67960.
[Bug c++/67960] [8/9/10 Regression] Prefixing a function with [[deprecated]] produces multiple warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67960 Jonathan Wakely changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2019-05-13 Known to work||7.4.0 Resolution|DUPLICATE |--- Summary|Prefixing a function with |[8/9/10 Regression] |[[deprecated]] produces |Prefixing a function with |multiple warnings |[[deprecated]] produces ||multiple warnings Ever confirmed|0 |1 Known to fail||10.0, 6.5.0, 8.3.0, 9.1.0 --- Comment #2 from Jonathan Wakely --- This is not a dup of PR 79078, because that's about issuing warnings in too many places, this is just about issuing the same one too many times. This seems to have been fixed for GCC 7, as only one warning is given, but then regressed for GCC 8, which gives two warnings.
[Bug tree-optimization/90447] Missed opportunities to use adc (worse when -1 is involved)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90447 --- Comment #1 from Cassio Neri --- Forgot to mention this discussion on SO: https://stackoverflow.com/questions/56101507/is-there-anything-special-about-1-0x-regarding-adc
[Bug translation/90149] diagnostics containing BIT_FIELD_REF don't conform to diagnostics guideline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90149
--- Comment #14 from rguenther at suse dot de ---
On Sat, 11 May 2019, msebor at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90149
>
> --- Comment #13 from Martin Sebor ---
> I had started by doing that but gave up when I noticed that there are lots of
> them, some like this:
>
> if (TREE_CODE (expr) == REALPART_EXPR
> || TREE_CODE (expr) == IMAGPART_EXPR
> || TREE_CODE (expr) == BIT_FIELD_REF)
> {
> tree op = TREE_OPERAND (expr, 0);
> if (!is_gimple_reg_type (TREE_TYPE (expr)))
> {
> error ("non-scalar BIT_FIELD_REF, IMAGPART_EXPR or REALPART_EXPR");
> return true;
> }
>
> some like this:
>
> case VEC_UNPACK_HI_EXPR:
> case VEC_UNPACK_LO_EXPR:
> case VEC_UNPACK_FLOAT_HI_EXPR:
> case VEC_UNPACK_FLOAT_LO_EXPR:
> case VEC_UNPACK_FIX_TRUNC_HI_EXPR:
> case VEC_UNPACK_FIX_TRUNC_LO_EXPR:
> ...
> error ("type mismatch in vector unpack expression");
>
> that avoid mentioning the exact code altogether, or like this:
>
> case LSHIFT_EXPR:
> case RSHIFT_EXPR:
> case LROTATE_EXPR:
> case RROTATE_EXPR:
> ...
> error ("type mismatch in shift expression");
>
> and some even that "lie" for the sake of brevity. It would be nice to always
> mention the exact code.
Ah, for these cases it looks an OK change.
> But I can save the result of get_tree_code_name (rhs_code) and use that
> instead
> of calling it repeatedly. (My initial approach was to add a new directive to
> the generic pretty-printer but, sadly, get_tree_code_name is defined in tree.c
> and not available there so I'd have had to duplicate the directive code for
> each front-end and for the middle-end. That seems like too much hassle.)
No, I just thought I saw (the first) case where your replacement
was at a point the tree code was exactly known at compile-time?
[Bug libstdc++/90440] [8.3 regression] Solaris/SPARC 10 fails to find
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90440 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-05-13 Component|c |libstdc++ CC||ebotcazou at gcc dot gnu.org, ||jwakely at redhat dot com Ever confirmed|0 |1 Summary|Solaris 10 sparc fails to |[8.3 regression] |find |Solaris/SPARC 10 fails to ||find Target Milestone|--- |8.4 Severity|normal |major --- Comment #1 from Eric Botcazou --- Most probably: 2019-02-09 Jonathan Wakely Backport from mainline 2019-01-08 Jonathan Wakely PR libstdc++/88066 * include/bits/locale_conv.h: Use <> for includes not "". * include/ext/random: Likewise. * include/ext/vstring.h: Likewise.
[Bug c++/90451] New: "static" function which added "deprecated" print deprecated warning >1 times (twice or even 3 times)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90451
Bug ID: 90451
Summary: "static" function which added "deprecated" print
deprecated warning >1 times (twice or even 3 times)
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: chen.4.zh...@nokia-sbell.com
Target Milestone: ---
Created attachment 46346
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46346=edit
static_deprecated_function
about deprecated feature
#if __cplusplus>=201402L
[[deprecated("")]]
#endif
if function is not a static function, the deprecated warning print 1 times as
expected;(v1)
if function is a static function, the same deprecated warning print >1 times;
in my case, if the function is "static", and called by "::" , the same
deprecated warning print 3 times(v2); if called by ".", the same deprecated
warning printed 2 times.(v3)
case code attached
[Bug c++/90383] [9 Regression] GCC generates invalid constexpr copy/move assignment operators for types with trailing padding. (Again)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90383 Jakub Jelinek changed: What|Removed |Added Summary|[9/10 Regression] GCC |[9 Regression] GCC |generates invalid constexpr |generates invalid constexpr |copy/move assignment|copy/move assignment |operators for types with|operators for types with |trailing padding. (Again) |trailing padding. (Again) --- Comment #6 from Jakub Jelinek --- Fixed on the trunk so far.
