[Bug c++/87372] [9 Regression] __PRETTY_FUNCTION__ not constexpr in gcc trunk on compiler explorer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87372 --- Comment #4 from eric-bugs at omnifarious dot org --- Should I file a new bug with my new comment in it? I should probably test against a trunk with your change in it first.
[Bug c++/87372] [9 Regression] __PRETTY_FUNCTION__ not constexpr in gcc trunk on compiler explorer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87372 --- Comment #3 from Marek Polacek --- Patch for the original problem posted: https://gcc.gnu.org/ml/gcc-patches/2018-09/msg01206.html
[Bug c++/70555] lambda capture of multi-dimensional VLA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70555 --- Comment #11 from Godmar Back --- I have attached a test case where capture of multidimensional VLA results in internal compiler error: in expand_expr_real_1, at expr.c:9908 I do not know if this is a duplicate of this bug or a separate bug. The program compiles and runs fine with clang 3.6.2, so I believe this should be valid C++. If this is a different bug and you'd like me to file a separate bug report, let me know. The behavior disappeared if the 'CC' array is no longer VLA.
[Bug c++/70555] lambda capture of multi-dimensional VLA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70555
Godmar Back changed:
What|Removed |Added
CC||godmar at gmail dot com
--- Comment #10 from Godmar Back ---
Created attachment 44730
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44730=edit
failing test
$ g++ dungeonpreprocessed.cpp
dungeon.cpp: In lambda function:
dungeon.cpp:40:68: internal compiler error: in expand_expr_real_1, at
expr.c:9908
auto neighbors = [L, R, C, ] (Point p) -> vector {
^
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
[Bug bootstrap/17464] [meta-bug] The newly built gcc shared libraries aren't used for bootstap and check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17464 Eric Gallager changed: What|Removed |Added Status|NEW |RESOLVED CC||egallager at gcc dot gnu.org Resolution|--- |FIXED --- Comment #11 from Eric Gallager --- All the bugs upon which this meta-bug depends have been closed, so I'm going to close this one, too. Feel free to reopen if more bugs crop up that need to be grouped under this one.
[Bug c++/87372] [9 Regression] __PRETTY_FUNCTION__ not constexpr in gcc trunk on compiler explorer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87372
--- Comment #2 from eric-bugs at omnifarious dot org ---
Also, this works in clang 6.0 (with --std=c++17), but not gcc 8.2:
#include
constexpr int ce_strlen(char const *s)
{
int i = 0;
while (s[i]) ++i;
return i;
}
template
constexpr auto as_array(char const *s)
{
::std::array output{};
for (int i = 0; i < len; ++i) {
output[i] = s[i];
}
output[output.size() - 1] = '\0';
return output;
}
template
constexpr auto paste_array(::std::array a, ::std::array b)
{
constexpr unsigned long tlen = s1 + s2 - 1;
::std::array output{};
int o = 0;
for (unsigned long i = 0; i < s1; ++i, ++o) {
output[o] = a[i];
}
--o;
for (unsigned long i = 0; i < s2; ++i, ++o) {
output[o] = b[i];
}
return output;
}
#define stringify(x) #x
#define evstringify(x) stringify(x)
char const * joe()
{
constexpr static auto mystr =
paste_array(paste_array(as_array(__PRETTY_FUNCTION__),
as_array(" at line ")),
as_array(evstringify(__LINE__)));
return mystr.data();
}
[Bug target/39725] [6/7/8/9 Regression][cond-optab] MIPS pessimizations on floating-point
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39725 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #16 from Eric Gallager --- This is the last of the bugs blocking bug 39714 that is still open; closing this one would allow us to close that one as well.
[Bug other/39302] [meta-bug] bugs waiting for Copyright Assignment acknowledgemt for ARC International (UK) Ltd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39302 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #2 from Eric Gallager --- (In reply to Jorn Wolfgang Rennecke from comment #1) > Confirmation received. I'll have to send out the patches now. Have you done this yet? Also does this need to keep the "meta-bug" label or can that be removed?
[Bug target/25893] [meta-bug] cris-linux: various libgomp tests fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25893 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #2 from Eric Gallager --- Since this bug only depends on 1 other bug, does it still need to keep the "meta-bug" label, or can that be removed?
[Bug other/21823] MAXPATHLEN usage in [gcc]/fixincludes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21823 Eric Gallager changed: What|Removed |Added Keywords||easyhack CC||pinskia at gcc dot gnu.org --- Comment #5 from Eric Gallager --- (In reply to Alfred M. Szmidt from comment #4) >> Created attachment 9857 [details] >> Don't use arbitrary limits. >> >> The following fixes fixincludes. >> >> fixincludes/ChangeLog >> 2005-09-16 Alfred M. Szmidt >> >> * fixincl.c (quoted_file_exists): Use xmalloc to allocate memory >> for FNAME. >> (create_file): Use xmalloc to allocate memory for FNAME. >> >> * server.c (server_setup): Use dynamic allocation for BUFF. > >Please send this patch to the gcc-patches mailing list for review, if it > still >applies > > MAXPATHLEN is still used in fixincludes. Seeing that this patch is > over 10 years, I am not sure it even applies and thus a good idea to > forward it to gcc-patches for review. The fix is simple enough in > fixincludes (simply use xmalloc). ok, adding "easyhack" keyword then
[Bug target/21824] [meta-bug] bootstrap bugs for *-gnu*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21824 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #2 from Eric Gallager --- (In reply to Alfred M. Szmidt from comment #1) > Could someone go over these bugs and commit the pending patches? Only bug 21823 is left now.
[Bug c++/14167] Unneeded C++ types are output in debug info due to use of static constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14167 Eric Gallager changed: What|Removed |Added Keywords||wrong-debug CC||egallager at gcc dot gnu.org, ||pinskia at gcc dot gnu.org --- Comment #7 from Eric Gallager --- This is the last bug still open that blocks bug 24551; fixing this would allow us to close that one too.
[Bug c++/87372] [9 Regression] __PRETTY_FUNCTION__ not constexpr in gcc trunk on compiler explorer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87372 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-09-21 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |9.0 Summary|__PRETTY_FUNCTION__ not |[9 Regression] |constexpr in gcc trunk on |__PRETTY_FUNCTION__ not |compiler explorer |constexpr in gcc trunk on ||compiler explorer Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Started with r263392.
[Bug c++/16992] [meta-bug] -fpermissive causes some diagnostic problems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16992 Eric Gallager changed: What|Removed |Added Status|NEW |RESOLVED CC||egallager at gcc dot gnu.org Resolution|--- |FIXED --- Comment #1 from Eric Gallager --- All the bugs that this one depends upon have been closed, so I'm closing this one too. Feel free to reopen if a large number of -fpermissive bugs crop up again that need to be grouped together.
[Bug rtl-optimization/18395] [meta-bug] combine needs to be templatized like a peepholer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18395 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #1 from Eric Gallager --- I think the way meta-bugs are done has been changed; should the bugs blocking this be moved to "Depends on" instead?
[Bug rtl-optimization/18446] [meta-bug] We need to distinguish value extension and value truncation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18446 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #1 from Eric Gallager --- For this to be a meta-bug it should depend on other bugs, but it doesn't. Should the meta-bug label be removed?
[Bug lto/82172] Destruction of basic_string in basic_stringbuf::overflow with _GLIBCXX_USE_CXX11_ABI=0, -flto, and C++17 mode results in invalid delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82172 --- Comment #27 from Gubbins --- > Dave, the fix for PR 86138 might also fix this case for Darwin - could you > check that please? I can confirm that using my homebrew-installed gcc 8.2.0 package on OSX, the issue no longer occurs. I don't know if the change made for PR 86138 is responsible but I believe 8.2.0 was the first release to include it.
[Bug lto/82172] Destruction of basic_string in basic_stringbuf::overflow with _GLIBCXX_USE_CXX11_ABI=0, -flto, and C++17 mode results in invalid delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82172 --- Comment #26 from Gubbins --- If anyone is interested, I received the following response on my bug report with Apple. > This issue behaves as intended based on the following: > > The program produced by ld64 seems fine: > > [/tmp/35663253]> nm -nm foo > (undefined) external __Unwind_Resume (from libSystem) > (undefined) external > __ZNSt15basic_stringbufIcSt11char_traitsIcESaIcEE8overflowEi (from libstdc++) > (undefined) external __ZNSt6localeC1Ev (from libstdc++) > (undefined) external __ZNSt6localeD1Ev (from libstdc++) > (undefined) external __ZTVSt15basic_streambufIcSt11char_traitsIcEE (from > libstdc++) > (undefined) external __ZTVSt15basic_stringbufIcSt11char_traitsIcESaIcEE (from > libstdc++) > (undefined) weak external __ZdlPv (from libstdc++) > (undefined) external ___gxx_personality_v0 (from libstdc++) > (undefined) external dyld_stub_binder (from libSystem) > 1000 (absolute) [referenced dynamically] external > __mh_execute_header > 1dee (__TEXT,__text) weak external > __ZNSt15basic_stringbufIcSt11char_traitsIcESaIcEED1Ev > 1e3f (__TEXT,__text_startup) external _main > 2060 (__DATA,__gcc_except_tab) non-external GCC_except_table0 > 2080 (__DATA,__data) weak external > __ZNSs4_Rep20_S_empty_rep_storageE > > [/tmp/35663253]> dyldinfo -weak_bind foo > weak binding information: > segment section address type addend symbol > __DATA __got 0x2010 pointer 0 __ZNSs4_Rep20_S_empty_rep_storageE > __DATA __la_symbol_ptr 0x2040 pointer 0 > __ZNSt15basic_stringbufIcSt11char_traitsIcESaIcEED1Ev > __DATA __la_symbol_ptr 0x2058 pointer 0 __ZdlPv > __DATA __la_symbol_ptr 0x2058 pointer 0 __ZdlPv > > The problem has to do with __ZNSs4_Rep20_S_empty_rep_storageE. That symbol is > also in libstdc++.6.dylib and is expected to be coalesced. > > [/tmp/35663253]> nm -m libstdc++.6.dylib | grep > __ZNSs4_Rep20_S_empty_rep_storageE > 00137020 (__DATA,__pu_bss5) extern > al __ZNSs4_Rep20_S_empty_rep_storageE > > The problem is that it is not “weak” in libstdc++.6.dylib. It is a regular > exported symbol. If it were weak, then at runtime dyld would coalesce it with > the one in the program “foo”. > > macOS does not use “flat namespace”. It uses two level namespace where every > symbol found in a dylib at build time has the dylib in which it was found > recorded and at runtime dyld only looks there. The exception to this is weak > symbols, where dyld looks across all dylibs and picks one, then adjusts all > uses in all dylibs to use that choosen one. > > The static linker (ld64) knows those rules and when building a dylib that > exports a non-weak symbol, the linker optimizes all uses within that dylib to > directly use that symbol. That is what is happening in libstdc++.6.dylib. > __ZNSs4_Rep20_S_empty_rep_storageE is not weak, so when libstdc++.6.dylib all > uses of __ZNSs4_Rep20_S_empty_rep_storageE are directly bound to use the copy > in libstdc++.6.dylib. There is nothing dyld can do at runtime to change that. > > The fix here is that __ZNSs4_Rep20_S_empty_rep_storageE needs to be weak when > libstdc++.6.dylib is built.
[Bug c++/40752] -Wconversion generates false warnings for operands not larger than target type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40752 Eric Gallager changed: What|Removed |Added CC||msebor at gcc dot gnu.org, ||umesh.kalappa0 at gmail dot com --- Comment #29 from Eric Gallager --- This came up on the gcc mailing list again here: https://gcc.gnu.org/ml/gcc/2018-09/msg00076.html
[Bug c++/87372] New: __PRETTY_FUNCTION__ not constexpr in gcc trunk on compiler explorer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87372
Bug ID: 87372
Summary: __PRETTY_FUNCTION__ not constexpr in gcc trunk on
compiler explorer
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric-bugs at omnifarious dot org
Target Milestone: ---
This code will not compile with gcc trunk on compiler explorer. But it works
with gcc 8.2 on that some site. I'm worried this is a regression in current C++
development.
constexpr int zstrlen(char const *s)
{
int i = 0;
while (s[i]) ++i;
return i;
}
int joe()
{
constexpr char const * const foo = __PRETTY_FUNCTION__;
constexpr int foolen = zstrlen(foo);
return foolen;
}
It fails to work because __PRETTY_FUNCTION__ isn't constexpr in gcc trunk. I
get this error message:
: In function 'int joe()':
:11:35: in 'constexpr' expansion of 'zstrlen(((const char*)foo))'
:11:39: error: the value of '__PRETTY_FUNCTION__' is not usable in a
constant expression
11 | constexpr int foolen = zstrlen(foo);
| ^
:10:40: note: '__PRETTY_FUNCTION__' was not declared 'constexpr'
10 | constexpr char const * const foo = __PRETTY_FUNCTION__;
|^~~
Compiler returned: 1
Here is a link:
https://godbolt.org/z/8IdAae
[Bug c++/85070] [8/9 Regression] ICE on C++ code: in lazily_declare_fn, at cp/method.c:2409
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85070 --- Comment #5 from Nathan Sidwell --- || errorcount sounds completely plausible
[Bug c++/87109] Wrong overload picked with ref-qualifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87109 --- Comment #5 from Marek Polacek --- Author: mpolacek Date: Thu Sep 20 23:20:19 2018 New Revision: 264452 URL: https://gcc.gnu.org/viewcvs?rev=264452=gcc=rev Log: PR c++/87109 - wrong ctor with maybe-rvalue semantics. * call.c (build_user_type_conversion_1): Refine the maybe-rvalue check to only return if we're converting the return value to a base class. * g++.dg/cpp0x/ref-qual19.C: Adjust the expected results. * g++.dg/cpp0x/ref-qual20.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/ref-qual20.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/cpp0x/ref-qual19.C
[Bug c++/85070] [8/9 Regression] ICE on C++ code: in lazily_declare_fn, at cp/method.c:2409
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85070 Paolo Carlini changed: What|Removed |Added CC||paolo.carlini at oracle dot com --- Comment #4 from Paolo Carlini --- Nathan, I stumbled into this minor regression and noticed that the ICE happens exactly at the gcc_assert in lazily_declare_fn that you added as part of r248285: /* Add it to the class */ bool added = add_method (type, fn, false); gcc_assert (added); but, for the testcase, during error-recovery added is false because add_method issued a correct - I believe - error_at + inform. Thus, is it only matter of loosening a bit the gcc_assert, eg added || errorcount, or something deeper is going on?
[Bug c++/81674] gcc cannot detect missing initialisers for fields in constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81674 Manuel López-Ibáñez changed: What|Removed |Added Keywords||patch CC||manu at gcc dot gnu.org --- Comment #5 from Manuel López-Ibáñez --- The patch here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808#c29 once finished should be able to catch this, because it walks the mem-initializer list and marks whatever is initialized. At the end of the list, it could just warn about whatever was not initialized. There will be false positives because it will not look at the body of the constructor but this is something that could be improved later and, in any case, it will never be fixed because it is as hard as -Wuninitialized.
[Bug c++/85914] -Wreturn-type false positive with a ternary that is always false (fixed?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85914 Manuel López-Ibáñez changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-09-20 Summary|-Wreturn-type false |-Wreturn-type false |positive with a ternary |positive with a ternary |that is always false|that is always false ||(fixed?) Ever confirmed|0 |1 --- Comment #1 from Manuel López-Ibáñez --- This does not warn in GCC 9. It will be worth adding the testcase to the testsuite.
[Bug c++/49931] valid code rejected (named operator)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49931
Manuel López-Ibáñez changed:
What|Removed |Added
Keywords||rejects-valid
Last reconfirmed|2012-08-24 00:00:00 |2018-9-20
CC||manu at gcc dot gnu.org
Summary|bug when use named |valid code rejected (named
|operators |operator)
--- Comment #2 from Manuel López-Ibáñez ---
GCC 9 says:
: In member function 'FOO2::operator FOO2::type() const':
:10:48: error: 'struct FOO' has no member named 'operator
FOO2::type'
10 | operator type() const { return t->operator type(); }
|^~~~
Clang compiles it.
Testcase:
struct FOO
{
operator int() const { return static_cast< int >(7); }
operator double() const { return static_cast< double >(7); } };
template < typename T >
struct FOO2
{
typedef T type;
operator type() const { return t->operator type(); }
private:
FOO* t;
};
int main()
{
FOO2< int > foo2; foo2.operator int();
return 1;
}
[Bug c/67629] bogus -Wreturn-type in a function with tautological if-else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67629 Manuel López-Ibáñez changed: What|Removed |Added CC||skvadrik at gmail dot com --- Comment #7 from Manuel López-Ibáñez --- *** Bug 60725 has been marked as a duplicate of this bug. ***
[Bug middle-end/60725] [-Wreturn-type] false positive in trivial switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60725
Manuel López-Ibáñez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |DUPLICATE
--- Comment #10 from Manuel López-Ibáñez ---
(In reply to Mário Feroldi from comment #9)
> Note that this version of `f1` doesn't prevent the warning. I wonder why?
>
> enum E { E1 };
> static inline int f1(enum E e) {
> (e == E1) ? void() : __builtin_unreachable(); // *
> switch (e) {
> case E1: return 1;
> }
> }
> int main () {
> f1(E1);
> return 0;
> }
Because the warning comes from the front-end and there is no data flow in the
front-end.
*** This bug has been marked as a duplicate of bug 67629 ***
[Bug c/67629] bogus -Wreturn-type in a function with tautological if-else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67629 Manuel López-Ibáñez changed: What|Removed |Added CC||mwoehlke.floss at gmail dot com --- Comment #6 from Manuel López-Ibáñez --- *** Bug 87371 has been marked as a duplicate of this bug. ***
[Bug other/87371] Spurious -Wreturn-type warning with "pathological" for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87371
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC||manu at gcc dot gnu.org
Resolution|--- |DUPLICATE
--- Comment #1 from Manuel López-Ibáñez ---
The warning happens in the front-end, so there is no concept of
always-executed. You don't need a loop. This also warns.
int foo()
{
int y=0;
if (!y)
return 1;
}
*** This bug has been marked as a duplicate of bug 67629 ***
[Bug bootstrap/87338] gcc 8.2 fails to bootstrap on ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87338 John Paul Adrian Glaubitz changed: What|Removed |Added CC||glaubitz at physik dot fu-berlin.d ||e --- Comment #5 from John Paul Adrian Glaubitz --- According to the build logs [1], one of the major differences when the regression was introduced, was the use of a newer binutils version: With binutils_2.30, gcc-8.1.0 builds fine: > https://buildd.debian.org/status/fetch.php?pkg=gcc-8=ia64=8.1.0-9=1530078388=0 With binutils_2.30.90.20180710, the build fails: > https://buildd.debian.org/status/fetch.php?pkg=gcc-8=ia64=8.1.0-10=1531402269=0 The changelog for the Debian gcc-8 package can be found here: > http://metadata.ftp-master.debian.org/changelogs/main/g/gcc-8/gcc-8_8.2.0-7_changelog The changes for 8.1.0-10 were: * Update to SVN 20180712 (r262577) from the gcc-8-branch. - Fix PR libstdc++/86272, PR libstdc++/86127, PR target/85904, PR libstdc++/85098, PR libstdc++/85671, PR libstdc++/83982, PR libstdc++/86292, PR libstdc++/86138, PR libstdc++/84087, PR libstdc++/86398, PR hsa/86371, PR tree-optimization/86492, PR c++/86400, PR target/86285 (PPC), PR debug/86064, PR target/86222 (PPC), PR rtl-optimization/85645, PR rtl-optimization/85645, PR target/86314 (x86), PR sanitizer/86406, PR c++/86398, PR c++/86378, PR c++/86320, PR c++/80290, PR fortran/82969, PR fortran/86242, PR fortran/82865. * Enable decimal float support on kfreebsd-amd64. Closes: #897416. @Jason: Can you try building 8.1.0-9 from snapshot.debian.org with binutils_2.30.90.20180710?
[Bug middle-end/87054] misaligned asm output is turned into dereferenced pointer-to-aligned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87054 --- Comment #4 from Alexandre Oliva --- Author: aoliva Date: Thu Sep 20 19:34:44 2018 New Revision: 264450 URL: https://gcc.gnu.org/viewcvs?rev=264450=gcc=rev Log: [PR87054] fix unaligned access Building an ADDR_EXPR uses the canonical type to build the pointer type, but then, as we dereference it, we lose track of lax alignment known to apply to the dereferenced object. This might not be a problem in general, but it is when the compiler implicitly introduces address taking and dereferencing, as it does for asm statements, and as it may do in some loop optimizations. From: Richard Biener for gcc/ChangeLog PR middle-end/87054 * gimplify.c (gimplify_expr): Retain alignment of addressable lvalue in dereference. From: Alexandre Oliva for gcc/testsuite/ChangeLog PR middle-end/87054 * gcc.dg/pr87054.c: New. Added: trunk/gcc/testsuite/gcc.dg/pr87054.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c trunk/gcc/testsuite/ChangeLog
[Bug bootstrap/87013] Error: junk at end of line, first unrecognized character is `i'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87013 --- Comment #9 from Alexandre Oliva --- Author: aoliva Date: Thu Sep 20 19:34:30 2018 New Revision: 264449 URL: https://gcc.gnu.org/viewcvs?rev=264449=gcc=rev Log: [PR87013] check for .loc is_stmt support in the assembler Back when we had the logic to output is_stmt but never exercised it, it didn't matter that we didn't test for assembler support for it. But there are still assemblers out there that do not support it, so now that we enable the formerly latent is_stmt logic, we'd better make sure the assembler can deal with it. for gcc/ChangeLog PR bootstrap/87013 * configure.ac: Check for .loc is_stmt support. * configure, config.in: Rebuilt. * dwarf2out.c (dwarf2out_source_line): Skip is_stmt if not supported. Modified: trunk/gcc/ChangeLog trunk/gcc/config.in trunk/gcc/configure trunk/gcc/configure.ac trunk/gcc/dwarf2out.c
[Bug c++/86881] [8, 9 regression] tree check fail with flag Wshadow-compatible-local
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86881 --- Comment #8 from Christophe Lyon --- (In reply to Nathan Sidwell from comment #7) > Thanks Christophe, I noticed that when checking the 8 backport and committed > a fix, so updating should make it work. Indeed it works since r264394. Thanks!
[Bug fortran/87270] "FINAL" subroutine is called when compiled with "gfortran -O1", but not "gfortran -O0"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87270 --- Comment #3 from Paul Thomas --- (In reply to janus from comment #2) > (In reply to Dominique d'Humieres from comment #1) > > This seems to have been fixed by revision r264008 on trunk > > Seems the segfault is 'fixed' due to the fact that the finalizer is not > called on trunk any more. I get the output: > > main: check 1 > create: check 1 > create: check 2 > main: check 2 > create: check 1 > create: check 2 > main: check 3 > > That's not a proper fix, of course. It rather seems that one bug (the > segfault) is hidden by another one (namely that the finalizer is not called) > ?!? Hmmm! The behaviour is now the same as 7-branch and so the referencing of the array components using the span field has been fixed. It seems that finalization has never occurred with any branch for this case, going back to 6-branch and, looking through trans-decl.c, I cannot see any point in which finalization would be triggered. I think that the span bug was causing 'cleanup' to be called erroneously by accessing memory that was not null (each finalizer call in the code is guarded by a check that the pointer is non-null.) I would have to go back to the standard to see what is expected here. Keep this one waiting. Cheers Paul
[Bug middle-end/87370] Regression in return struct code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87370 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- Changed with: commit 350f354acdd2224797f93a979fff38cb631548a3 Author: hjl Date: Thu Aug 11 15:51:01 2016 + Use TImode for piecewise move in 64-bit mode Use TImode for piecewise move in 64-bit mode. We should use TImode in 32-bit mode and use OImode or XImode if they are available. But since by_pieces_ninsns determines the widest mode with MAX_FIXED_MODE_SIZE, we can only use TImode in 64-bit mode. gcc/ * config/i386/i386.h (MOVE_MAX_PIECES): Use TImode in 64-bit mode if unaligned SSE load and store are optimal. gcc/testsuite/ * gcc.target/i386/pieces-memcpy-1.c: New test. * gcc.target/i386/pieces-memcpy-2.c: Likewise. * gcc.target/i386/pieces-memcpy-3.c: Likewise. * gcc.target/i386/pieces-memcpy-4.c: Likewise. * gcc.target/i386/pieces-memcpy-5.c: Likewise. * gcc.target/i386/pieces-memcpy-6.c: Likewise. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@239378 138bc75d-0d04-0410-961f-82ee72b054a4
[Bug c/63886] float will fit into int with abs - possible missing warning Wabsolute-value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63886 --- Comment #12 from Eric Gallager --- I think someone added the -Wabsolute-value warning flag to GCC recently; is it ok to close this bug now?
[Bug other/87371] New: Spurious -Wreturn-type warning with "pathological" for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87371
Bug ID: 87371
Summary: Spurious -Wreturn-type warning with "pathological" for
Product: gcc
Version: 8.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: mwoehlke.floss at gmail dot com
Target Milestone: ---
Consider the following code:
int foo()
{
for (int y = 0; !y;)
for (/*decl*/; !y; ++y)
return 1;
}
This generates a -Wreturn-type warning, despite that the inner loop body will
*always* execute. Moreover, with optimization enabled, the compiler does (as
expected) successfully remove the loops entirely.
(This is a simplified version of a pre-C++17 `with` statement. The purpose of
this code, which is usually a macro, is to look like the opening statement of a
block, where `/*decl*/` — omitted in this example — is in scope only until the
end of the block. FWIW, the C++17 form, `if (/*decl*/; true)` does not exhibit
the problem.)
Live example: https://godbolt.org/g/5xM6C3. Possibly related to #67629 and/or
#85914.
[Bug middle-end/87370] New: Regression in return struct code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87370
Bug ID: 87370
Summary: Regression in return struct code
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: trashyankes at wp dot pl
Target Milestone: ---
Test case: https://gcc.godbolt.org/z/58JsxE
```
struct A
{
int b[4];
};
struct B
{
char a[12];
int b;
};
struct C
{
char a[16];
};
A f1(int i)
{
return { };
}
B f2(int i)
{
return { };
}
C f3(int i)
{
return { };
}
```
On x86_64 it create assembly:
```
f1(int):
xor eax, eax
xor edx, edx
ret
f2(int):
pxor xmm0, xmm0
xor eax, eax
movaps XMMWORD PTR [rsp-24], xmm0
mov rdx, QWORD PTR [rsp-16]
ret
f3(int):
xor eax, eax
xor edx, edx
ret
```
Clang and GCC 6.3 generate same code for every function functions.
[Bug c++/87075] [7/8/9 Regression] ICE when compiling the test suite of GLM 0.9.9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87075 --- Comment #6 from Jason Merrill --- Author: jason Date: Thu Sep 20 17:09:19 2018 New Revision: 264442 URL: https://gcc.gnu.org/viewcvs?rev=264442=gcc=rev Log: PR c++/87075 - ICE with constexpr array initialization. My patch of 2016-08-26 to avoid calling a trivial default constructor introduced TARGET_EXPRs initialized with void_node to express trivial initialization. But when this shows up in a VEC_INIT_EXPR, we weren't prepared to handle it. Fixed by handling it explicitly in cxx_eval_vec_init_1. * constexpr.c (cxx_eval_vec_init_1): Handle trivial initialization. Added: trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-array6.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/constexpr.c
[Bug c++/87075] [7/8/9 Regression] ICE when compiling the test suite of GLM 0.9.9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87075 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug target/87369] New: Regression on aarch64/copysign-bsl.c since r264264
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87369 Bug ID: 87369 Summary: Regression on aarch64/copysign-bsl.c since r264264 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org Target Milestone: --- Since r264264, I've noticed a regression on FAIL: gcc.target/aarch64/copysign-bsl.c scan-assembler b(sl|it|if)\tv[0-9]
[Bug fortran/87270] "FINAL" subroutine is called when compiled with "gfortran -O1", but not "gfortran -O0"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87270 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org, ||pault at gcc dot gnu.org --- Comment #2 from janus at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #1) > This seems to have been fixed by revision r264008 on trunk Seems the segfault is 'fixed' due to the fact that the finalizer is not called on trunk any more. I get the output: main: check 1 create: check 1 create: check 2 main: check 2 create: check 1 create: check 2 main: check 3 That's not a proper fix, of course. It rather seems that one bug (the segfault) is hidden by another one (namely that the finalizer is not called) ?!?
[Bug debug/87362] GCC produces with LTO debug info with which gdb is not happy about
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87362
--- Comment #11 from Richard Biener ---
(In reply to Richard Biener from comment #10)
> (In reply to Richard Biener from comment #9)
> > Created attachment 44729 [details]
> > patch
> >
> > This avoids most of the forwarders (slightly hackish) and adds linkage
> > names.
> >
> > gdb startup is faster, more testing is in progress.
>
> Hm. Looks like we hit
>
> Reading symbols from ../../obj3/gcc/lto1...done.
> ../../gdb/dictionary.c:690: internal-error: void
> insert_symbol_hashed(dictionary*, symbol*): Assertion `SYMBOL_LANGUAGE (sym)
> == DICT_LANGUAGE (dict)->la_language' failed.
> A problem internal to GDB has been detected,
> further debugging may prove unreliable.
> Quit this debugging session? (y or n)
>
> with the patch which somehow feels familiar ...
>
> The performance testing was on an earlier patch w/o the abstract-origin fixes
> (just on-demand DIE creation).
>
> The above also reproduces with gengtype (but not with a simple test).
OK, also genchecksum. We see that for example on
Compilation Unit @ offset 0x20a2:
Length:0x3b4 (32-bit)
Version: 4
Abbrev Offset: 0x83c
Pointer Size: 8
<0><20ad>: Abbrev Number: 1 (DW_TAG_compile_unit)
<20ae> DW_AT_producer: (indirect string, offset: 0xe27): GNU C17
9.0.0
20180919 (experimental) [trunk revision 259470] -mtune=generic -march=x86-64
-g -O2 -flto=jobserver -frandom-seed=1
<20b2> DW_AT_language: 12 (ANSI C99)
<20b3> DW_AT_name: (indirect string, offset: 0x1020):
/tmp/trunk/libiberty/xstrerror.c
...
<2><244c>: Abbrev Number: 18 (DW_TAG_variable)
<244d> DW_AT_name: (indirect string, offset: 0x1019): errstr
<2451> DW_AT_decl_file : 7
<2452> DW_AT_decl_line : 56
<2453> DW_AT_decl_column : 9
<2454> DW_AT_type: <0x2122>
Compilation Unit @ offset 0x245a:
Length:0x8df (32-bit)
Version: 4
Abbrev Offset: 0x93f
Pointer Size: 8
<0><2465>: Abbrev Number: 1 (DW_TAG_compile_unit)
<2466> DW_AT_producer: (indirect string, offset: 0x1090): GNU GIMPLE
9
.0.0 20180919 (experimental) [trunk revision 259470] -mtune=generic
-march=x86-6
4 -mtune=generic -march=x86-64 -g -O2 -O2 -fno-openmp -fno-openacc
-frandom-seed
=1 -fno-exceptions -fasynchronous-unwind-tables -fno-common -fno-PIE -fltrans
<246a> DW_AT_language: 4 (C++)
<246b> DW_AT_name: (indirect string, offset: 0x106e):
...
<1><2589>: Abbrev Number: 2 (DW_TAG_subprogram)
<258a> DW_AT_abstract_origin: <0x2434>
<258e> DW_AT_linkage_name: (indirect string, offset: 0x1041): xstrerror
<2592> DW_AT_low_pc : 0x401300
<259a> DW_AT_high_pc : 0x28
<25a2> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa)
<25a4> DW_AT_GNU_all_call_sites: 1
<25a4> DW_AT_sibling : <0x264b>
...
<2><25b5>: Abbrev Number: 4 (DW_TAG_variable)
<25b6> DW_AT_abstract_origin: <0x244c>
<25ba> DW_AT_location: 0xfae (location list)
<25be> DW_AT_GNU_locviews: 0xfaa
<1><2c4f>: Abbrev Number: 22 (DW_TAG_imported_unit)
<2c50> DW_AT_import : <0x20ad> [Abbrev Number: 1]
maybe because we "merge" languages in gen_compile_unit_die:
/* If our producer is LTO try to figure out a common language to use
from the global list of translation units. */
if (strcmp (language_string, "GNU GIMPLE") == 0)
{
unsigned i;
tree t;
const char *common_lang = NULL;
FOR_EACH_VEC_SAFE_ELT (all_translation_units, i, t)
{
if (!TRANSLATION_UNIT_LANGUAGE (t))
continue;
if (!common_lang)
common_lang = TRANSLATION_UNIT_LANGUAGE (t);
else if (strcmp (common_lang, TRANSLATION_UNIT_LANGUAGE (t)) == 0)
;
else if (strncmp (common_lang, "GNU C", 5) == 0
&& strncmp (TRANSLATION_UNIT_LANGUAGE (t), "GNU C", 5) ==
0)
/* Mixing C and C++ is ok, use C++ in that case. */
common_lang = highest_c_language (common_lang,
TRANSLATION_UNIT_LANGUAGE (t));
else
{
/* Fall back to C. */
common_lang = NULL;
break;
}
}
or maybe because the DW_TAG_imported_unit is too late? (I also see we have
duplicate imports at least with the patch).
Not sure what the correct representation is for abstract instances in a
C CU but the concrete instance being "inlined" out-of-line into a C++ CU.
[Bug debug/87362] GCC produces with LTO debug info with which gdb is not happy about
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87362 --- Comment #10 from Richard Biener --- (In reply to Richard Biener from comment #9) > Created attachment 44729 [details] > patch > > This avoids most of the forwarders (slightly hackish) and adds linkage names. > > gdb startup is faster, more testing is in progress. Hm. Looks like we hit Reading symbols from ../../obj3/gcc/lto1...done. ../../gdb/dictionary.c:690: internal-error: void insert_symbol_hashed(dictionary*, symbol*): Assertion `SYMBOL_LANGUAGE (sym) == DICT_LANGUAGE (dict)->la_language' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) with the patch which somehow feels familiar ... The performance testing was on an earlier patch w/o the abstract-origin fixes (just on-demand DIE creation). The above also reproduces with gengtype (but not with a simple test).
[Bug debug/87362] GCC produces with LTO debug info with which gdb is not happy about
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87362 --- Comment #9 from Richard Biener --- Created attachment 44729 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44729=edit patch This avoids most of the forwarders (slightly hackish) and adds linkage names. gdb startup is faster, more testing is in progress.
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 86877, which changed state. Bug 86877 Summary: ICE in vectorizable_load, at tree-vect-stmts.c:8038 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86877 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug target/86877] ICE in vectorizable_load, at tree-vect-stmts.c:8038
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86877 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from rsandifo at gcc dot gnu.org --- Fixed on trunk.
[Bug target/87368] New: missing masking inline functions for VCVTSS2SD and VCVTSD2SS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87368 Bug ID: 87368 Summary: missing masking inline functions for VCVTSS2SD and VCVTSD2SS Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jbeulich at novell dot com Target Milestone: --- Other than for the scalar float to/from integer conversion insns, the scalar float <-> float ones allow a mask to be applied. Out of the set of 5 each that the SDM shows, only _mm_cvt_roundsd_ss() and _mm_cvt_roundss_sd() are actually available.
[Bug target/86877] ICE in vectorizable_load, at tree-vect-stmts.c:8038
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86877 --- Comment #2 from rsandifo at gcc dot gnu.org --- Author: rsandifo Date: Thu Sep 20 12:58:16 2018 New Revision: 264439 URL: https://gcc.gnu.org/viewcvs?rev=264439=gcc=rev Log: Add missing alignment checks in epilogue loop vectorisation (PR 86877) Epilogue loop vectorisation skips vect_enhance_data_refs_alignment since it doesn't make sense to version or peel the epilogue loop (that will already have happened for the main loop). But this means that it also fails to check whether the accesses are suitably aligned for the new vector subarch. We don't seem to carry alignment information from the (potentially peeled or versioned) main loop to the epilogue loop, which would be good to fix at some point. I think we want this patch regardless, since there's no guarantee that the alignment requirements are the same for every subarch. 2018-09-20 Richard Sandiford gcc/ PR tree-optimization/86877 * tree-vect-loop.c (vect_analyze_loop_2): Call vect_verify_datarefs_alignment. gcc/testsuite/ PR tree-optimization/86877 * gfortran.dg/vect/vect-8-epilogue.F90: New test. Added: trunk/gcc/testsuite/gfortran.dg/vect/vect-8-epilogue.F90 Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-loop.c
[Bug target/87288] [8/9 Regression] Segfault after const_cast with "-O2 -ftree-loop-vectorize" but _without_ "-mavx"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87288 --- Comment #9 from rsandifo at gcc dot gnu.org --- Author: rsandifo Date: Thu Sep 20 12:58:23 2018 New Revision: 264440 URL: https://gcc.gnu.org/viewcvs?rev=264440=gcc=rev Log: Fix PEELING_FOR_NITERS calculation (PR 87288) PEELING_FOR_GAPS now means "peel one iteration for the epilogue", in much the same way that PEELING_FOR_ALIGNMENT > 0 means "peel that number of iterations for the prologue". We weren't taking this into account when deciding whether we needed to peel further scalar iterations beyond the iterations for "gaps" and "alignment". Only the first test failed before the patch. The other two are just for completeness. 2018-09-20 Richard Sandiford gcc/ PR tree-optimization/87288 * tree-vect-loop.c (vect_analyze_loop_2): Take PEELING_FOR_GAPS into account when determining PEELING_FOR_NITERS. gcc/testsuite/ PR tree-optimization/87288 * gcc.dg/vect/pr87288-1.c: New test. * gcc.dg/vect/pr87288-2.c: Likewise, * gcc.dg/vect/pr87288-3.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/vect/pr87288-1.c trunk/gcc/testsuite/gcc.dg/vect/pr87288-2.c trunk/gcc/testsuite/gcc.dg/vect/pr87288-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-loop.c
[Bug fortran/87359] [9 regression] pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87359 --- Comment #12 from Dominique d'Humieres --- The problem is with the file process_mci.f90: if I compile all the other files with r264428 and process_mci.f90 with r263915, the test succeeds.
[Bug middle-end/63155] [6/7/8/9 Regression] memory hog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63155
--- Comment #31 from Richard Biener ---
So we end up with an almost fully set ssa_edge_worklist because we add all the
PHIs from blocks we already processed by having visited the backedge defs. But
the backedge isn't actually yet executable and avoiding to set those bits
brings down the set to a maximum size of 2985 (compared to ~70 before).
So a simpler patch for this particular issue is
Index: gcc/tree-ssa-propagate.c
===
--- gcc/tree-ssa-propagate.c(revision 264438)
+++ gcc/tree-ssa-propagate.c(working copy)
@@ -168,15 +170,26 @@ add_ssa_edge (tree var)
FOR_EACH_IMM_USE_FAST (use_p, iter, var)
{
gimple *use_stmt = USE_STMT (use_p);
+ basic_block use_bb = gimple_bb (use_stmt);
/* If we did not yet simulate the block wait for this to happen
and do not add the stmt to the SSA edge worklist. */
- if (! (gimple_bb (use_stmt)->flags & BB_VISITED))
+ if (! (use_bb->flags & BB_VISITED))
continue;
+ /* If this is a use on a not yet executable edge do not bother to
+ queue it. */
+ if (gimple_code (use_stmt) == GIMPLE_PHI
+ && !(EDGE_PRED (use_bb, PHI_ARG_INDEX_FROM_USE (use_p))->flags
+ & EDGE_EXECUTABLE))
+ return;
+
if (prop_simulate_again_p (use_stmt)
&& bitmap_set_bit (ssa_edge_worklist, gimple_uid (use_stmt)))
{
[Bug debug/87362] GCC produces with LTO debug info with which gdb is not happy about
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87362
--- Comment #8 from Richard Biener ---
(In reply to Richard Biener from comment #7)
> The following makes it work for a simple C int main() {}. It's also a little
> bit less hacky...
>
> Index: gcc/dwarf2out.c
> ===
> --- gcc/dwarf2out.c (revision 264418)
> +++ gcc/dwarf2out.c (working copy)
> @@ -26896,6 +26896,10 @@ dwarf2out_decl (tree decl)
> static void
> dwarf2out_function_decl (tree decl)
> {
> + if (in_lto_p)
> +/* This helps debuggers to build a symbol table. */
> +if (dw_die_ref die = lookup_decl_die (decl))
> + add_linkage_attr (die, decl);
>dwarf2out_decl (decl);
>call_arg_locations = NULL;
>call_arg_loc_last = NULL;
Doesn't seem to help gdb at all.
Maybe gdb pulls in all the early CUs because of the stray DIEs we have
for optimized out functions, like
<2><423bc64>: Abbrev Number: 5 (DW_TAG_subprogram)
<423bc65> DW_AT_abstract_origin: <0x3419cf1>
<423bc69> DW_AT_sibling : <0x423bc73>
<3><423bc6d>: Abbrev Number: 6 (DW_TAG_formal_parameter)
<423bc6e> DW_AT_abstract_origin: <0x3419cfe>
<3><423bc72>: Abbrev Number: 0
since we create them at tree streaming time rather than when actually
outputting them (PR83941). My idea for that is to create those lazily
somehow, like having dwarf2out_register_external_die populate an
on-the-side representation and lookup_decl_die querying that if the
DIE wasn't created already.
I also notice that breaking on a function doesn't seem to work (if there are
only inline/IPA optimized instances(?)). gdb doesn't stop.
auto-completion also takes ages. So whatever gdb does it isn't very
efficient ;)
[Bug debug/87362] GCC produces with LTO debug info with which gdb is not happy about
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87362
--- Comment #7 from Richard Biener ---
The following makes it work for a simple C int main() {}. It's also a little
bit less hacky...
Index: gcc/dwarf2out.c
===
--- gcc/dwarf2out.c (revision 264418)
+++ gcc/dwarf2out.c (working copy)
@@ -26896,6 +26896,10 @@ dwarf2out_decl (tree decl)
static void
dwarf2out_function_decl (tree decl)
{
+ if (in_lto_p)
+/* This helps debuggers to build a symbol table. */
+if (dw_die_ref die = lookup_decl_die (decl))
+ add_linkage_attr (die, decl);
dwarf2out_decl (decl);
call_arg_locations = NULL;
call_arg_loc_last = NULL;
[Bug debug/87362] GCC produces with LTO debug info with which gdb is not happy about
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87362 --- Comment #6 from Richard Biener --- So I tried debugging using LTO bootstrapped cc1. profiling gdb for a simple gdb ./cc1 (gdb) b do_rpo_vn (gdb) q yields Samples: 2K of event 'instructions', Event count (approx.): 45695722362 Overhead Command Shared ObjectSymbol 8.32% gdb gdb [.] read_attribute_value 5.78% gdb gdb [.] dwarf2_attr 5.10% gdb gdb [.] load_partial_dies 4.23% gdb gdb [.] cp_find_first_component_aux 4.10% gdb gdb [.] partial_die_info::read 3.55% gdb gdb [.] htab_find_slot_with_hash 3.11% gdb gdb [.] get_objfile_arch 2.98% gdb gdb [.] peek_die_abbrev 2.88% gdb gdb [.] cp_canonicalize_string or with a callgraph Samples: 1K of event 'instructions', Event count (approx.): 37206022209 Children Self Command Shared ObjectSymbol ◆ + 91.92% 0.00% gdb gdb [.] gdb_main ▒ + 91.47% 0.00% gdb gdb [.] main ▒ + 91.42% 0.00% gdb libc-2.22.so [.] __libc_start_main ▒ + 91.35% 0.00% gdb gdb [.] catch_command_errors ▒ + 91.30% 0.00% gdb gdb [.] _start ▒ + 85.40% 0.00% gdb gdb [.] symbol_file_add_main_ad▒ + 85.40% 0.00% gdb gdb [.] symbol_file_add_main ▒ + 55.17% 0.00% gdb gdb [.] psym_lookup_symbol ▒ + 55.13% 0.00% gdb gdb [.] psymtab_to_symtab ▒ + 55.13% 0.00% gdb gdb [.] dwarf2_read_symtab ▒ + 55.13% 0.00% gdb gdb [.] dw2_do_instantiate_symt▒ + 55.06% 0.00% gdb gdb [.] lookup_symbol_in_objfil▒ + 55.02% 0.00% gdb gdb [.] lookup_global_symbol ▒ + 55.02% 0.00% gdb gdb [.] default_iterate_over_ob▒ + 55.02% 0.00% gdb gdb [.] lookup_symbol_global_it▒ + 55.00% 0.00% gdb gdb [.] lookup_symbol_aux ▒ + 54.99% 0.00% gdb gdb [.] basic_lookup_symbol_non▒ + 54.94% 0.00% gdb gdb [.] lookup_symbol_in_langua▒ + 54.83% 0.00% gdb gdb [.] lookup_symbol ▒ + 54.77% 0.00% gdb gdb [.] set_initial_language ▒ + 43.75% 0.49% gdb gdb [.] process_die but that doesn't look too useful. Note that startup / breakpointing isn't as fast as non-LTOed cc1 but it's still usable. I notice that while .debug_ranges is quite large the .debug_aranges section is small. I wonder through what hoops gdb needs to go to get at the entry address for main() - I can imagine that because the late LTO debug only contains the ranges attribute but not DW_AT_name gdb has to follow all LTO debug DIE abstract origins. Since those abstract origins are in DW_TAG_imported_unit imported CUs it may (hopefully lazily!) need to parse those when an abstract origin refers to a DIE within them. At least I don't see sth like a "symbol table" refering to the late LTO DIEs in DWARF. Maybe if we're lucky and main() is the very first DIE we run into startup would be faster. Of course looking at the startup / breakpoint differences between LTO and non-LTO might yield to a better understanding of things here. For example it might be possible to optimize the poking at DW_AT_name via an abstract origin _without_ needing to pull in all of the imported unit if it's from such kind of searching. When using callgrind it seems that the whole complication comes in via symbol_file_add_main -> ... -> read_symbols -> ... -> read_psyms -> dwarf2_build_psymtabs as expected. So somehow avoiding to pull in all the early LTO CUs would be the thing to do(?) - maybe we can add DW_AT_linkage_name to the late generated DIEs to help gdb (we seem to not do that). In fact we seem to add them to the early DIEs (probably needed for TYPE_DECLs). I'm trying a hack like Index: gcc/dwarf2out.c === --- gcc/dwarf2out.c (revision 264418) +++ gcc/dwarf2out.c (working copy) @@ -6018,6 +6018,9 @@ dwarf2out_register_external_die (tree de break; case FUNCTION_DECL: die = new_die (DW_TAG_subprogram, parent, decl); + /* This helps debuggers to build a symbol table. */ + if (! flag_wpa && flag_incremental_link != INCREMENTAL_LINK_LTO) + add_linkage_name (die, decl); break; case VAR_DECL: die = new_die (DW_TAG_variable,
[Bug c/87367] GCC gives false warning on -Wnull-dereference when using -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87367 --- Comment #2 from Andrew Pinski --- copy->next = list_new(); You dont check the return value here.
[Bug fortran/87359] [9 regression] pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87359 --- Comment #11 from Dominique d'Humieres --- This is indeed caused by r263916.
[Bug c/87367] GCC gives false warning on -Wnull-dereference when using -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87367 Iru Cai changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Iru Cai --- Looks like it's not a bug, the warning of NULL dereference is right.
[Bug c/87367] New: GCC gives false warning on -Wnull-dereference when using -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87367
Bug ID: 87367
Summary: GCC gives false warning on -Wnull-dereference when
using -O2
Product: gcc
Version: 8.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: mytbk920423 at gmail dot com
Target Milestone: ---
When compiling the following program with -Wnull-dereference, GCC doesn't warn
when using -O1, but warns when using -O2.
#include
typedef struct list_element_s {
void *data;
struct list_element_s *next;
} list_element_s, list_element_p[1];
list_element_s *list_new() {
list_element_s *n = malloc(sizeof(list_element_s));
if (!n) {
return NULL;
}
n->data = NULL;
n->next = NULL;
return n;
}
size_t otrng_list_len(list_element_s *head) {
list_element_s *cursor = head;
size_t size = 0;
while (cursor) {
if (cursor->data) {
size++;
}
cursor = cursor->next;
}
return size;
}
list_element_s *otrng_list_copy(list_element_s *head) {
if (otrng_list_len(head) == 0) {
return NULL;
}
list_element_s *cursor = head;
list_element_s *copy = list_new();
if (!copy) {
return NULL;
}
copy->data = cursor->data;
copy->next = NULL;
list_element_s *ret = copy;
cursor = cursor->next;
while (cursor) {
copy->next = list_new();
copy = copy->next;
copy->data = cursor->data;
copy->next = NULL;
cursor = cursor->next;
}
return ret;
}
$ gcc -c -O2 -Wnull-dereference list.c
list.c: In function 'otrng_list_copy':
list.c:54:16: warning: potential null pointer dereference [-Wnull-dereference]
copy->next = NULL;
^
list.c:53:16: warning: potential null pointer dereference [-Wnull-dereference]
copy->data = cursor->data;
~~~^~
[Bug middle-end/87363] Duplicate and bogus -Wstringop-overflow warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87363
--- Comment #5 from Bernd Edlinger ---
Using named struct members does not make a difference.
Of course it is possible that converting address of u.b.z
to const char *, makes the example undefined, as strlen is
not really accessing the bytes thru a union member.
$ cat pr87053.c
/* PR middle-end/87053 */
const union
{ struct {
char x[4];
char y[4];
} a;
struct {
char z[8];
} b;
} u = {{"1234", "567"}};
int main ()
{
if (__builtin_strlen (u.b.z) != 7)
__builtin_abort ();
}
$ gcc pr87053.c
gcc -O3 -S pr87053.c
pr87053.c: In function ‘main’:
pr87053.c:15:28: warning: ‘strlen’ argument missing terminating nul
[-Wstringop-overflow=]
15 | if (__builtin_strlen (u.b.z) != 7)
| ~~~^~
pr87053.c:11:3: note: referenced argument declared here
11 | } u = {{"1234", "567"}};
| ^
pr87053.c:15:28: warning: ‘strlen’ argument missing terminating nul
[-Wstringop-overflow=]
15 | if (__builtin_strlen (u.b.z) != 7)
| ~~~^~
pr87053.c:11:3: note: referenced argument declared here
11 | } u = {{"1234", "567"}};
| ^
