[Bug fortran/88438] [F08] A pointer function reference can denote a variable in any variable definition context.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88438 --- Comment #2 from Jürgen Reuter --- (In reply to Dominique d'Humieres from comment #1) > At https://gcc.gnu.org/wiki/Fortran2008Status I see > > Unimplemented features -- based on the list in the "Introduction" of the > F2008 standard > ... > A pointer function reference can denote a variable in any variable > definition context. > ... Yes, but one confuses me is that this is not as a red box in the list on the top of the page.
[Bug target/63651] Lot of failures in obj(c|-c++) with yosemite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63651 --- Comment #21 from Iain Sandoe --- (In reply to Eric Gallager from comment #20) > (In reply to Dominique d'Humieres from comment #18) > > For the record with darwin15 I had to add > > > > /System/Library/Frameworks/Foundation.framework/Versions/C/Headers/ > > NSEnumerator.h > > /System/Library/Frameworks/Foundation.framework/Versions/C/Headers/NSObject.h > > /System/Library/Frameworks/Foundation.framework/Versions/C/Headers/NSValue.h > > > > from the 10.9 SDK to > > > > /System/Library/Frameworks/Foundation.framework/Versions/C/Headers/NSArray.h > > /System/Library/Frameworks/Foundation.framework/Versions/C/Headers/NSString.h > > /usr/include/objc/NSObject.h > > that seems dangerous Not so dangerous as it seems. Many (most, in fact) of the failures seen from GCC Objective-C are caused by missing support for new features that have been introduced into the vendor's headers. Short list: Apple Blocks, Lightweight Generics, Nullability, Syntactic sugar on ID. I'm working on a set of replacement test-suite headers that allow us to test the things that _do_ work on GCC Objective-C, and expose any real regressions. Tests on Darwin13 and earlier show that we are not in such bad shape as the header fails make it appear. I hope to get these test fixes (there's a set of three PRs related to excess fails on Yosemite+) in place soon - and to back port them to the open branches.
[Bug middle-end/89150] [9 regression] Tree form bitmaps break GC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89150 --- Comment #7 from Richard Biener --- Author: rguenth Date: Tue Feb 5 08:32:16 2019 New Revision: 268530 URL: https://gcc.gnu.org/viewcvs?rev=268530&root=gcc&view=rev Log: 2019-02-05 Richard Biener PR middle-end/89150 * bitmap.h (struct bitmap_obstack): Do not mark GTY. (struct bitmap_element): Drop chain_prev so we properly recurse on the prev member, supporting tree views. (struct bitmap_head): GTY skip the obstack member. Modified: trunk/gcc/ChangeLog trunk/gcc/bitmap.h
[Bug c/89082] Feature request: provide annotation for code that's unlikely to be executed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89082 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||marxin at gcc dot gnu.org Resolution|--- |WONTFIX --- Comment #1 from Martin Liška --- Maybe I can offer c++20 [[likely]] and [[unlikely]] attribute: https://en.cppreference.com/w/cpp/language/attributes/likely example usage: https://github.com/gcc-mirror/gcc/blob/master/gcc/testsuite/g++.dg/cpp2a/attr-likely1.C And yes, putting cold attribute on the PRINT_ERR function is what you're seeking for. I guess it's desired to factor out the code to a function as it's very unlikely the function will be executed. On the contrary, macro expansion will cause the printing code will occupy space in the function. That said, I'm closing as invalid as we provide various solutions.
[Bug middle-end/89150] [9 regression] Tree form bitmaps break GC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89150 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Richard Biener --- Fixed.
[Bug gcov-profile/88930] [GCOV] Wrong frequences when a if statement is after a ?: statement in gcov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88930 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Martin Liška --- Fixed on trunk in r263111.
[Bug gcov-profile/88914] [GCOV] Wrong frequencies when unreachable statements within the body of the for loop in gcov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88914 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Martin Liška --- Fixed on trunk in r247374, thus all versions 8.0+ should be fine.
[Bug gcov-profile/85206] [GCOV] a return statement in the body of for(;0;) loop is wrongly marked as executed in gcov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85206 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-05 Ever confirmed|0 |1
[Bug testsuite/86404] UNRESOLVED/UNSUPPORTED gcov test results due to Permission error mapping pages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86404 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-05 CC||andi-gcc at firstfloor dot org Component|gcov-profile|testsuite Ever confirmed|0 |1
[Bug fortran/89200] [9 Regression] Erroneous copying of a derived type with a deferred-length character array component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89200 Paul Thomas changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #3 from Paul Thomas --- Created attachment 45602 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45602&action=edit Fix for the bug Since it is my doing, I had better fix the problem! The copying was OK but the array element addressing was not, since the 'span' field in the descriptor was never set. The attached does the job but the test leaks memory, as it has in all versions going way back when. I'll commit as 'obvious' tonight. Paul
[Bug libstdc++/89090] vector.tcc uses "if constexpr" in C++11 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89090 --- Comment #4 from Csaba Ráduly --- svn blame vector.tcc claims that the inner, apparently redundant "#if __cplusplus >= 201103L" appeared at this change: r265485 | glisse | 2018-10-25 15:03:13 +0200 (Thu, 25 Oct 2018) | 24 lines Relocation (= move+destroy) 2018-10-25 Marc Glisse PR libstdc++/87106 * include/bits/alloc_traits.h (_S_construct, _S_destroy, construct, destroy): Add noexcept specification. * include/bits/allocator.h (construct, destroy): Likewise. * include/ext/alloc_traits.h (construct, destroy): Likewise. * include/ext/malloc_allocator.h (construct, destroy): Likewise. * include/ext/new_allocator.h (construct, destroy): Likewise. * include/bits/stl_uninitialized.h (__relocate_object_a, __relocate_a, __relocate_a_1): New functions. (__is_trivially_relocatable): New class. * include/bits/stl_vector.h (__use_relocate): New static member. * include/bits/vector.tcc (reserve, _M_realloc_insert, _M_default_append): Use __relocate_a. (reserve, _M_assign_aux, _M_realloc_insert, _M_fill_insert, _M_default_append, _M_range_insert): Move _GLIBCXX_ASAN_ANNOTATE_REINIT after _Destroy. * testsuite/23_containers/vector/modifiers/push_back/49836.cc: Replace CopyConsOnlyType with DelAnyAssign.
[Bug web/89032] Missing documentation for GCC 7.4.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89032 Martin Liška changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Martin Liška --- I've just fixed that.
[Bug target/89186] [9 Regression] ICE in mark_addressable at gcc/gimple-expr.c:894 since r268138
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89186 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Tue Feb 5 09:17:18 2019 New Revision: 268531 URL: https://gcc.gnu.org/viewcvs?rev=268531&root=gcc&view=rev Log: PR target/89186 * optabs.c (prepare_cmp_insn): Pass x and y to emit_block_comp_via_libcall rather than XEXP (x, 0) and XEXP (y, 0). * g++.dg/ext/vector36.C: New test. Added: trunk/gcc/testsuite/g++.dg/ext/vector36.C Modified: trunk/gcc/ChangeLog trunk/gcc/optabs.c trunk/gcc/testsuite/ChangeLog
[Bug other/89203] New: Linux S/390: Unable to build GCC 8.2.0 on Red Hat Enterprise Linux Server release 6.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89203 Bug ID: 89203 Summary: Linux S/390: Unable to build GCC 8.2.0 on Red Hat Enterprise Linux Server release 6.9 Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: m.marko08154711 at gmail dot com Target Milestone: --- When trying to build GCC 8.2.0 on Red Hat Enterprise Linux Server release 6.9 the component "libgomp" fails with this error: configure: error: in `/home/gcc-8.2.0-build/s390x-ibm-linux-gnu/libgomp': configure: error: C compiler cannot create executables Looking at the "config.log" some corresponding symbols cannot be found: configure:3694: /home/gcc-8.2.0-build/./gcc/xgcc -B/home/gcc-8.2.0-build/./gcc/ -B/opt/gcc-8.2.0/s390x-ibm-linux-gnu/bin/ -B/opt/gcc-8.2.0/s390x-ibm-linux-gnu/lib/ -isystem /opt/gcc-8.2.0/s390x-ibm-linux-gnu/include -isystem /opt/gcc-8.2.0/s390x-ibm-linux-gnu/sys-include--version >&5 /home/ gcc-8.2.0-build/./gcc/xgcc: symbol lookup error: /home/gcc-8.2.0-build/./gcc/libgcc_s.so.1: undefined symbol: __s390_indirect_jump_r1use_r14 Tried it * with the preinstalled GCC (4.4.7) * with a more recent GCC (6.4.0) * with default flags + environment, so just "./configure" and "make" * with target/build/host set explicitly (to exclude cross-compilation problems) * in same folder (as source) * in separated build folder (outside source) This might be related to https://gcc.gnu.org/PR84295 (thx to Segher Boessenkool for pointing this out).
[Bug libstdc++/87106] Group move and destruction of the source, where possible, for speed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106 --- Comment #18 from Marc Glisse --- Author: glisse Date: Tue Feb 5 09:33:36 2019 New Revision: 268532 URL: https://gcc.gnu.org/viewcvs?rev=268532&root=gcc&view=rev Log: Rename __is_trivially_relocatable to __is_bitwise_relocatable. 2019-02-05 Marc Glisse PR libstdc++/87106 * include/bits/stl_uninitialized.h (__is_trivially_relocatable): Rename... (__is_bitwise_relocatable): ... to this. (__relocate_a_1): Adapt. * include/bits/stl_deque.h (__is_trivially_relocatable): Rename... (__is_bitwise_relocatable): ... to this. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/stl_deque.h trunk/libstdc++-v3/include/bits/stl_uninitialized.h
[Bug fortran/89100] Default widths for i, f and g format specifiers in format strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89100 MarkEggleston changed: What|Removed |Added Attachment #45549|0 |1 is obsolete|| --- Comment #6 from MarkEggleston --- Created attachment 45603 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45603&action=edit Updated change log for gcc/fortran for patch
[Bug target/45591] gcc generates illegal asm at -O2 with -fdollars-in-identifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45591
pskocik at gmail dot com changed:
What|Removed |Added
CC||pskocik at gmail dot com
--- Comment #3 from pskocik at gmail dot com ---
I think I've run into the same problem.
If I compile
int $ident(int X) { return X; }
int main() { return $ident(1); }
the generated assembly won't translate.
gcc generates
call$ident
where clang would have parenethesized the $-containing identifier. The missing
parens result in assembler error "operand type mismatch for call".
[Bug target/89186] [9 Regression] ICE in mark_addressable at gcc/gimple-expr.c:894 since r268138
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89186 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek --- Fixed (latent on release branches, I'll fix it there eventually too).
[Bug fortran/89103] Allow blank format items in format strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89103 MarkEggleston changed: What|Removed |Added Attachment #4|0 |1 is obsolete|| --- Comment #6 from MarkEggleston --- Created attachment 45604 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45604&action=edit Updated change log for gcc/fortran for patch
[Bug rtl-optimization/89195] [7/8/9 regression] Corrupted stack offset after combine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89195 --- Comment #4 from Wilco --- (In reply to Segher Boessenkool from comment #3) > (In reply to Wilco from comment #1) > > len is unsigned HOST_WIDE_INT, so bits_to_bytes_round_down does an unsigned > > division... > > That shouldn't make a difference though, both dividend and divisor should be > non-negative. Are they? Well I guess not... So pos points outside of the > register here?! pos is a frame offset so always negative. And yes this code is then creating an access outside the original object (starting at -1 or +1 depending on endianness). > Was it correct before that? At least it was symmetric so it *seemed* > correct.. It was broken in the same way. If I cast just len to HOST_WIDE_INT it works fine.
[Bug fortran/89204] New: -floop-interchange has no effect on Fortran code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89204
Bug ID: 89204
Summary: -floop-interchange has no effect on Fortran code
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: chinoune.mehdi at hotmail dot com
Target Milestone: ---
On 7 Dec 2017 Bin Cheng had introduced a better implementation of
-floop-interchange
https://gcc.gnu.org/ml/gcc-patches/2017-12/msg00360.html
bou it looks like it doesn't affect Fortran
#define M 2048
int a[M][M], b[M][M], c[M][M];
void matrix_mul (int n)
{
for (int k = 0; k < n; k++)
for (int j = 0; j < n; j++)
for (int i = 0; i < n; i++)
c[i][j] = c[i][j] + a[i][k]*b[k][j];
}
static void init (int i)
{
for (int j = 0; j < M; j++)
{
a[i][j] = i;
b[i][j] = j;
c[i][j] = 0;
}
}
int main (void)
{
for (int i = 0; i < M; ++i)
init (i);
matrix_mul (M);
return 0;
}
gcc-8 -O2 -floop-interchange -fopt-info loop-interchange-7.c -o test
loop-interchange-7.c:11:7: note: loops interchanged in loop nest
time ./test
real
0m7.759s
user0m7.656s
sys 0m0.031s
module mod_
implicit none
integer, parameter :: m = 2048
integer :: a(m,m), b(m,m), c(m,m)
contains
subroutine matrix_mul(n)
integer, intent(in) :: n
integer :: i, j, k
do i = 1, n
do j = 1, n
do k = 1, n
c(i,j) = c(i,j) + a(i,k)*b(k,j)
end do
end do
end do
end subroutine matrix_mul
subroutine init(i)
integer, intent(in) :: i
integer :: j
a(i,:) = i
do j = 1, m
b(i,j) = j
end do
end subroutine init
end module mod_
program main
use mod_
implicit none
integer :: i
c = 0
do i = 1, m
call init(i)
end do
call matrix_mul(m)
end program main
gfortran-8 -O2 -floop-interchange -fopt-info loop-interchange-7.f90 -o test
time ./test
real
1m30.447s
user
1m30.266s
sys 0m0.063s
[Bug middle-end/87489] [8/9 Regression] Spurious -Wnonnull warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87489 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #9 from Jakub Jelinek --- (In reply to Manuel López-Ibáñez from comment #3) > What is interesting is that VRP info already shows that this cannot be zero: > > # RANGE [0, 9223372036854775805] NONZERO 9223372036854775807 No, bits set in NONZERO bitmask are "may be nonzero", not must be nonzero. Bits clear in that bitmask are "must be zero". So NONZERO 9223372036854775807 just says that the most significant bit is clear, nothing else. (In reply to Andres Freund from comment #2) > Maybe (In reply to Jonathan Wakely from comment #1) > > The first XLogRegisterData could change the value of xl_xinfo.xid to be > > non-zero, in which case the second XLogRegisterData call would happen > > despite the null string. > > Well, that'd then still only be a ok for a "may be" warning, not one that > say "argument 1 null where" (i.e. without a may be). Also, XLogRegisterData > here takes a const char * argument, so it really shouldn't modify the > argument? For most of the warnings, we don't have "may be" and "is" variants, and while we do have it for -W*uninitialized, the boundary isn't that clear. The warning on the #c0 is IMHO desirable, whenever that strlen is called, it will be with NULL argument, and the compiler can't prove (because the other call that takes the address of the info stuff) the call will not be called with the NULL argument ever. For -W*uninitialized, we call "is" if the uninitialized use happens always if the function is called, no exception is thrown or calls on the path to the statement never return, and "may be" otherwise. Even the "is" are "may be", it all depends on that the function is called at all and that the code is actually reached.
[Bug ipa/88936] [7/8/9 Regression] -fipa-pta breaks bash (incorrect optimisation of recursive static function)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88936
--- Comment #11 from Richard Biener ---
Created attachment 45605
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45605&action=edit
prototype conservative fix
So this is a very conservative fix computing what automatic variables "escape"
and duplicating those with (a single) shadow variable. It FAILs at least
the following test (though IPA PTA has low testsuite coverage)
FAIL: gcc.dg/ipa/ipa-pta-3.c scan-tree-dump fre3 "Replaced \\*p_2\\(D\\) with
1"
The testcase tests optimization on
static int __attribute__((noinline,noclone))
foo (int *p, int *q)
{
*p = 1;
*q = 0;
return *p;
}
extern void abort (void);
int main()
{
int a, b;
if (foo (&a, &b) != 1)
abort ();
return 0;
}
where you see we now compute a and b as escaping and thus add SHADOW to
the points-to sets of both p and q making them appear aliasing. Missed
optimizations of the patch are
a) main isn't reached recursively so we never need shadow vars for a or b
b) we could have used separate shadow vars for a and b
The patch has the opportunity to provide the missing local escaped solution.
In practice the opportunity to cut non-recursively reached functions is
probably low - I've yet have to identify a conservative way to compute this.
[Bug libstdc++/89194] [9 regression] build failure with libstdc++ with std=c++2a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89194 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.0
[Bug rtl-optimization/89195] [7/8/9 regression] Corrupted stack offset after combine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89195 Richard Biener changed: What|Removed |Added Keywords||wrong-code Priority|P3 |P2 Target Milestone|9.0 |7.5
[Bug c++/89197] Templated Functions const auto assignment causes internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89197 Richard Biener changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-05 Ever confirmed|0 |1
[Bug rtl-optimization/89195] [7/8/9 regression] Corrupted stack offset after combine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89195 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-05 CC||jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #5 from Jakub Jelinek --- Started with r242414 aka PR77881 fix.
[Bug fortran/89204] -floop-interchange has no effect on Fortran code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89204 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-05 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Related to pr61000.
[Bug fortran/89204] -floop-interchange has no effect on Fortran code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89204 Richard Biener changed: What|Removed |Added Last reconfirmed|2019-02-05 00:00:00 | CC||amker at gcc dot gnu.org --- Comment #2 from Richard Biener --- If I make the example more "similar": subroutine matrix_mul(n) integer, intent(in) :: n integer :: i, j, k do k = 1, n do j = 1, n do i = 1, n c(j,i) = c(j,i) + a(k,i)*b(j,k) end do end do end do end subroutine matrix_mul dumps tell me: Consider loop interchange for loop_nest<2 - 3> Access Strides for DRs: b[_13]: <4, 0> c[_5]:<4, 8192> a[_9]:<0, 8192> c[_5]:<4, 8192> but isn't very chatty about why exactly interchange didn't happen.
[Bug c++/89205] New: [8/9 Regression] Debug info size growth since r248469
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89205
Bug ID: 89205
Summary: [8/9 Regression] Debug info size growth since r248469
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: nathan at gcc dot gnu.org
Target Milestone: ---
Starting from the revision, I see a reasonable growth in debug info for e.g.
astar: 60% in between GCC 7 and 8.
I tried to isolate a simple test-case:
$ cat RegWay_.ii
namespace {}
namespace a {
void isgreater();
void isgreater(double);
template void isgreater();
bool isgreaterequal();
template void isgreaterequal();
} // namespace a
using a::isgreater;
using a::isgreaterequal;
Using -O2 -g on x86_64-linux one can see before and after the problematic
revision (using bloaty):
Bisecting latest revisions
5637ac627975d117(25 May 2017 20:55): [took: 2.562s] result: OK
VM SIZE FILE SIZE
-- --
-NAN% 0 [ELF Headers]1.06Ki 44.6%
-NAN% 0 .rela.debug_info312 12.8%
-NAN% 0 .symtab 288 11.8%
-NAN% 0 .debug_str 237 9.7%
-NAN% 0 .shstrtab 143 5.9%
-NAN% 0 .debug_abbrev 113 4.6%
-NAN% 0 .debug_info 96 3.9%
-NAN% 0 .debug_line 43 1.8%
-NAN% 0 .comment 42 1.7%
-NAN% 0 .debug_aranges 32 1.3%
-NAN% 0 .rela.debug_aranges 24 1.0%
-NAN% 0 .strtab 12 0.5%
-NAN% 0 [Unmapped] 10 0.4%
100.0% 0 TOTAL2.38Ki 100.0%
a92669f34279ca07(25 May 2017 19:41): [took: 2.478s] result: OK
VM SIZE FILE SIZE
-- --
-NAN% 0 [ELF Headers] 768 58.2%
-NAN% 0 .symtab 216 16.4%
-NAN% 0 .debug_str185 14.0%
-NAN% 0 .shstrtab 92 7.0%
-NAN% 0 .comment 42 3.2%
-NAN% 0 .strtab12 0.9%
-NAN% 0 [Unmapped] 5 0.4%
100.0% 0 TOTAL 1.29Ki 100.0%
Note various newly added debug sections.
Maybe I reported a similar issue, but my memory is fuzzy.
[Bug lto/48200] Implement function attribute for symbol versioning (.symver)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200 --- Comment #29 from Xi Ruoyao --- I'm sure -flto-parition=none is needed for workaround, now. It keeps .symver directive and the function definition in the same assembly file. Unfortunately for large codebase -flto-partition leads to OOM.
[Bug rtl-optimization/89195] [7/8/9 regression] Corrupted stack offset after combine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89195 --- Comment #6 from Segher Boessenkool --- pos should be always non-negative. pos is the offset (in bits, counted from the right) in the *field*.
[Bug rtl-optimization/89195] [7/8/9 regression] Corrupted stack offset after combine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89195 --- Comment #7 from Jakub Jelinek --- While I can see how doing - (HOST_WIDE_INT) len instead of - len fixes the ICE, I wonder if what make_extraction does isn't invalid. In particular, we have later on: /* Unless INNER is not MEM, reject this if we would be spanning bytes or if the position is not a constant and the length is not 1. In all other cases, we would only be going outside our object in cases when an original shift would have been undefined. */ if (MEM_P (inner) && ((pos_rtx == 0 && maybe_gt (pos + len, GET_MODE_PRECISION (is_mode))) || (pos_rtx != 0 && len != 1))) return 0; and I think we need this !maybe_gt (pos + len, GET_MODE_PRECISION (is_mode))) even in the: || (MEM_P (inner) && pos_rtx == 0 && (pos % (STRICT_ALIGNMENT ? GET_MODE_ALIGNMENT (tmode) : BITS_PER_UNIT)) == 0 /* We can't do this if we are widening INNER_MODE (it may not be aligned, for one thing). */ && !paradoxical_subreg_p (tmode, inner_mode) && (inner_mode == tmode || (! mode_dependent_address_p (XEXP (inner, 0), MEM_ADDR_SPACE (inner)) && ! MEM_VOLATILE_P (inner)) conditions, because otherwise we have a MEM and we try to read some other bytes outside of that MEM, but those might not be accessible at all etc. So, add && known_le (pos + len, GET_MODE_PRECISION (is_mode)) here?
[Bug c++/89205] [8/9 Regression] Debug info size growth since r248469
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89205 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-05 Target Milestone|--- |8.3 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- It means debuginfo wasn't present at all before this rev. (on the reduced testcase). Somehow the iteration wasn't translated 1:1?
[Bug rtl-optimization/89195] [7/8/9 regression] Corrupted stack offset after combine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89195 --- Comment #8 from Jakub Jelinek --- Created attachment 45606 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45606&action=edit gcc9-pr89195.patch Now in patch form (untested so far).
[Bug libstdc++/89164] can construct vector with non-copyable-but-trivially-copyable elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89164 --- Comment #2 from Jonathan Wakely --- N.B. the report is missing that it is only accepted for c++17 and c++2a modes. For c++14 it's rejected as expected.
[Bug libstdc++/89194] [9 regression] build failure with libstdc++ with std=c++2a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89194 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- The g++9 -std=c++2a -fconcepts -pthread gcc9_stdcpp2a.ii libgtest.a libgtest_main.a and g++9 -std=c++2a -fconcepts -pthread gcc9_stdcpp2a.ii libgtest.a libgtest_main.a command lines above are identical. So, does it fail or succeed in that case?
[Bug c++/89205] [8/9 Regression] Debug info size growth since r248469
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89205 --- Comment #2 from Martin Liška --- (In reply to Richard Biener from comment #1) > It means debuginfo wasn't present at all before this rev. (on the reduced > testcase). Somehow the iteration wasn't translated 1:1? Yes, but for ./benchspec/CPU2006/473.astar/src/RegWay_.cpp there's quite significant difference. I would attach RegWay_.ii, but I don't know whether SPEC license allows that..
[Bug c++/89205] [8/9 Regression] Debug info size growth since r248469
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89205 --- Comment #3 from Jakub Jelinek --- Why is that a regression? It is desirable to emit debug info here...
[Bug c++/89205] [8/9 Regression] Debug info size growth since r248469
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89205 --- Comment #4 from Richard Biener --- (In reply to Jakub Jelinek from comment #3) > Why is that a regression? It is desirable to emit debug info here... I guess the question is more of whether we understand the difference in behavior since the change looks innocous.
[Bug c++/89205] [8/9 Regression] Debug info size growth since r248469
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89205 --- Comment #5 from Martin Liška --- (In reply to Richard Biener from comment #4) > (In reply to Jakub Jelinek from comment #3) > > Why is that a regression? It is desirable to emit debug info here... > > I guess the question is more of whether we understand the difference in > behavior > since the change looks innocous. Exactly! As mentioned all debug info related sections grew by 60%, which is a significant difference.
[Bug gcov-profile/89000] gcov --function-summaries says No branches/No calls, only the File summary is correct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89000 --- Comment #4 from Martin Liška --- Author: marxin Date: Tue Feb 5 12:17:45 2019 New Revision: 268533 URL: https://gcc.gnu.org/viewcvs?rev=268533&root=gcc&view=rev Log: GCOV: remove misleading branches and calls info for -f option (PR gcov-profile/89000). 2019-02-05 Martin Liska PR gcov-profile/89000 * gcov.c (function_summary): Remove argument. (file_summary): New function. (print_usage): Replace tabs with spaces. (generate_results): Use new function file_summary. Modified: trunk/gcc/ChangeLog trunk/gcc/gcov.c
[Bug gcov-profile/89000] gcov --function-summaries says No branches/No calls, only the File summary is correct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89000 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Martin Liška --- Ok, I decided to remove the branch and call statistics when running gcov tool. Please use intermediate format, which provides the information.
[Bug rtl-optimization/89195] [7/8/9 regression] Corrupted stack offset after combine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89195 --- Comment #9 from Segher Boessenkool --- That patch is pre-approved if it regchecks fine (on more than just x86). Thanks!
[Bug c++/89205] [8/9 Regression] Debug info size growth since r248469
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89205
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6 from Jakub Jelinek ---
The old code in cp_emit_debug_info_for_using was buggy:
6566 /* FIXME: Handle TEMPLATE_DECLs. */
6567 for (t = OVL_CURRENT (t); t; t = OVL_NEXT (t))
6568if (TREE_CODE (t) != TEMPLATE_DECL)
That only ever looked at the first overload and not anything else, if it was
TEMPLATE_DECL, it didn't emit anything, otherwise it emitted debug info just
for the first overload and nothing else. See the definitions:
#define OVL_CURRENT(NODE) \
((TREE_CODE (NODE) == OVERLOAD) ? OVL_FUNCTION (NODE) : (NODE))
#define OVL_NEXT(NODE) \
((TREE_CODE (NODE) == OVERLOAD) ? TREE_CHAIN (NODE) : NULL_TREE)
Normally, a walk over all overloads used to be done
for (; t; t = OVL_NEXT (t))
{
tree fn = OVL_CURRENT (t);
...
}
[Bug rtl-optimization/89195] [7/8/9 regression] Corrupted stack offset after combine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89195 --- Comment #10 from Wilco --- (In reply to Jakub Jelinek from comment #8) > Created attachment 45606 [details] > gcc9-pr89195.patch > > Now in patch form (untested so far). That works fine indeed. It avoids accessing the object out of bounds but still allows the optimization for eg. i:16 using a 16-bit access within the struct.
[Bug d/88150] Use sections_elf_shared.d on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88150 --- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #8 from Johannes Pfau --- > Regarding the _d_dso_registry issue: Yes, as far as I can see it is a bug that > handleForName dlcloses the handle here. I think what happened is this: > > handleForName is used in one place with the comment > // get handle without loading the library > so it is supposed to unload the library there. > But it is also called from handleForAddr which is used to get the DSO handle > to > be stored using setDSOForHandle. I think here, it's not really valid to store > the closed handle. If the dlclose is indeed invalid, my workaround of disabling it explains 3 of the 4 remaining libphobos.shared failures. If I disable the dlclose unconditionally and rerun the libphobos.shared tests on Linux/x86_64, I get those failures there, too, both 64 and 32-bit: FAIL: libphobos.shared/load.d -shared-libphobos -ldl execution test FAIL: libphobos.shared/load_13414.d -shared-libphobos -ldl execution test FAIL: libphobos.shared/finalize.d -shared-libphobos -ldl execution test
[Bug c++/89187] [7/8/9 Regression] ICE in initialize_argument_information, at calls.c:2023
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89187 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug tree-optimization/89182] [8/9 Regression] [graphite] ICE in extract_affine, at graphite-sese-to-poly.c:280
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89182 Richard Biener changed: What|Removed |Added Priority|P3 |P2 --- Comment #2 from Richard Biener --- Trivial hac^Wfix would be to cache scalar_evolution_in_region in a hash-map given SCEV caching isn't done for arbitrary GENERIC expressions but only for SSA names.
[Bug rtl-optimization/89116] [8/9 Regression] ICE in cfg_layout_redirect_edge_and_branch_force, at cfgrtl.c:4482
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89116 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Depends on||85408 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85408 [Bug 85408] ICE in patch_jump_insn, at cfgrtl.c:1271
[Bug c++/89205] [8/9 Regression] Debug info size growth since r248469
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89205 --- Comment #7 from Jakub Jelinek --- E.g. just comment out the template lines in the testcase and suddenly even GCC 7 emits debug info.
[Bug c++/89205] [8/9 Regression] Debug info size growth since r248469
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89205
--- Comment #8 from Jakub Jelinek ---
Or even just reorder:
namespace a {
template void isgreater();
void isgreater();
void isgreater(double);
template void isgreaterequal();
bool isgreaterequal();
}
using a::isgreater;
using a::isgreaterequal;
[Bug target/88917] [8/9 Regression] Error: can't resolve `.text' {.text section} - `.LCFI2' {.text.unlikely section} with -fno-dwarf2-cfi-asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88917 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug rtl-optimization/88879] [9 Regression] ICE in sel_target_adjust_priority, at sel-sched.c:3332
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88879 Richard Biener changed: What|Removed |Added Keywords||ice-on-valid-code Priority|P3 |P4
[Bug target/88856] [8/9 Regression] gfortran producing wrong code with -funroll-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88856 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug c++/88820] [7/8/9 Regression] ICE in in C++2a mode for code which is able to be compiled in C++17 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88820 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Target Milestone|9.0 |7.5
[Bug tree-optimization/88771] [9 Regression] Misleading -Werror=array-bounds error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88771 --- Comment #15 from Richard Biener --- Can we (did we already?) fix the diagnostic with respect to the range printing as said in comment#5? I'd defer the rest. Maybe we can even have jump-threading cancel paths that would introduce these kind of stmts? But folding them to __builtin_trap() looks a legitimate way to deal with them, the region RPO VN code could be thrown at jump-threaded paths and do this immediately.
[Bug lto/89206] New: Map
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89206 Bug ID: 89206 Summary: Map Product: gcc Version: 8.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: ilg at livius dot net CC: marxin at gcc dot gnu.org Target Milestone: ---
[Bug ipa/88711] [9 Regression] scan-ipa-dump inline "Inlined tp_sum/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88711 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug target/88656] [7/8/9 Regression] lr clobbered by thumb prologue before __builtin_return_address(0) reads from it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88656 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug ipa/88702] [7/8/9 regression] We do terrible job optimizing IsHTMLWhitespace from Firefox
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88702 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug ipa/88702] [7/8/9 regression] We do terrible job optimizing IsHTMLWhitespace from Firefox
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88702 --- Comment #8 from Martin Liška --- Honza can you please create mozilla upstream bug where we can recommend to use switch instead of series of if conditions?
[Bug libstdc++/89164] can construct vector with non-copyable-but-trivially-copyable elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89164
--- Comment #3 from Jonathan Wakely ---
This version compiles even in C++11 though:
#include
struct X {
X() = default;
X(const X&) = delete;
};
int main()
{
X x[1];
std::vector v{x, x+1};
}
The original version was only rejected prior to C++17 because the
std::initializer_list required a copy constructor, which is elided in C++17.
I think the right fix is:
--- a/libstdc++-v3/include/bits/stl_uninitialized.h
+++ b/libstdc++-v3/include/bits/stl_uninitialized.h
@@ -122,9 +122,15 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
#if __cplusplus < 201103L
const bool __assignable = true;
#else
- // trivial types can have deleted assignment
+ // Trivial types can have deleted copy constructor, but std::copy
+ // optimization that uses memmove would happily "copy" them anyway.
+ static_assert(is_constructible<_ValueType2, decltype(*__first)>::value,
+ "result type must be constructible from value type of input range");
+
typedef typename iterator_traits<_InputIterator>::reference _RefType1;
typedef typename iterator_traits<_ForwardIterator>::reference _RefType2;
+ // Trivial types can have deleted assignment, so using std::copy
+ // would be ill-formed. Require assignability before using std::copy:
const bool __assignable = is_assignable<_RefType2, _RefType1>::value;
#endif
[Bug tree-optimization/88606] [9 Regression] ICE: verify_type failed (error: type variant differs by TYPE_TRANSPARENT_AGGR)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88606
Richard Biener changed:
What|Removed |Added
Assignee|hubicka at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #4 from Richard Biener ---
When we reset TYPE_TRANSPARENT_AGGR because we cannot make it transparent we
do so only on one variant, not all. The following fixes it:
transparent-union-6.c:7:42: warning: union cannot be made transparent
7 | union __attribute__((transparent_union)) m30_u {
| ^
transparent-union-6.c: In function ‘f’:
transparent-union-6.c:16:23: error: incompatible type for argument 1 of
‘make_double’
16 | return make_double (bar);
| ^~~
| |
| int
transparent-union-6.c:11:21: note: expected ‘m30_t’ {aka ‘union m30_u’} but
argument is of type ‘int’
11 | double make_double (m30_t);
| ^
Index: gcc/c/c-decl.c
===
--- gcc/c/c-decl.c (revision 268530)
+++ gcc/c/c-decl.c (working copy)
@@ -8394,6 +8394,16 @@ finish_struct (location_t loc, tree t, t
}
}
+ /* If this was supposed to be a transparent union, but we can't
+ make it one, warn and turn off the flag. */
+ if (TREE_CODE (t) == UNION_TYPE
+ && TYPE_TRANSPARENT_AGGR (t)
+ && (!TYPE_FIELDS (t) || TYPE_MODE (t) != DECL_MODE (TYPE_FIELDS (t
+{
+ TYPE_TRANSPARENT_AGGR (t) = 0;
+ warning_at (loc, 0, "union cannot be made transparent");
+}
+
/* Note: C_TYPE_INCOMPLETE_VARS overloads TYPE_VFIELD which is used
in dwarf2out via rest_of_decl_compilation below and means
something totally different. Since we will be clearing
@@ -8406,22 +8416,13 @@ finish_struct (location_t loc, tree t, t
{
TYPE_FIELDS (x) = TYPE_FIELDS (t);
TYPE_LANG_SPECIFIC (x) = TYPE_LANG_SPECIFIC (t);
+ TYPE_TRANSPARENT_AGGR (x) = TYPE_TRANSPARENT_AGGR (t);
C_TYPE_FIELDS_READONLY (x) = C_TYPE_FIELDS_READONLY (t);
C_TYPE_FIELDS_VOLATILE (x) = C_TYPE_FIELDS_VOLATILE (t);
C_TYPE_VARIABLE_SIZE (x) = C_TYPE_VARIABLE_SIZE (t);
C_TYPE_INCOMPLETE_VARS (x) = NULL_TREE;
}
- /* If this was supposed to be a transparent union, but we can't
- make it one, warn and turn off the flag. */
- if (TREE_CODE (t) == UNION_TYPE
- && TYPE_TRANSPARENT_AGGR (t)
- && (!TYPE_FIELDS (t) || TYPE_MODE (t) != DECL_MODE (TYPE_FIELDS (t
-{
- TYPE_TRANSPARENT_AGGR (t) = 0;
- warning_at (loc, 0, "union cannot be made transparent");
-}
-
/* Update type location to the one of the definition, instead of e.g.
a forward declaration. */
if (TYPE_STUB_DECL (t))
[Bug c/88584] [7/8/9 Regression] GCC thinks that the type is complete despite shadowing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88584 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug lto/89207] New: Symbols missing in map file with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89207
Bug ID: 89207
Summary: Symbols missing in map file with LTO
Product: gcc
Version: 8.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: ilg at livius dot net
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Created attachment 45607
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45607&action=edit
The elf, the map and the listing.
After finally managing to compile some embedded projects with arm-none-eabi-gcc
and '-flto', I noticed that the map file (created with something like
'-Wl,-Map,"f4b-lto-map.map"') does not include all symbols, although the
listing file created with objcopy does, so the symbols are present in the elf
file.
I attached an archive with the elf, the map and the listing.
There are multiple symbols missing, but I noticed the problem while searching
the map for the 'Reset_Handler', located, according to the the listing, at
0x080003ac:
080003ac :
Reset_Handler():
/Users/ilg/Desktop/eclipse-workspace-2018-12/f4b-lto-map/Debug/../system/src/cortexm/exception_handlers.c:53
{
80003ac: b508push{r3, lr}
/Users/ilg/Desktop/eclipse-workspace-2018-12/f4b-lto-map/Debug/../system/src/cortexm/exception_handlers.c:54
_start ();
80003ae: f7ff ff79 bl 80002a4 <_start>
Then I noticed that the entire .after_vectors has only 4 symbols:
*(.after_vectors .after_vectors.*)
.after_vectors
0x08000188 0x238
/var/folders/n7/kxqjc5zs4qs0nb44v1l2r2j0gn/T//ccTOZd7j.ltrans0.ltrans.o
0x080001dcUsageFault_Handler_C
0x08000210BusFault_Handler_C
0x08000244HardFault_Handler_C
0x080002a4_start
.inits 0x080003c0 0x2c
0x080003c0__data_regions_array_start =
.
while in reality the listing for this memory range includes many more.
For example, the same program compiled without -flto, shows for the
.after_vectors section the following:
.after_vectors
0x08000188 0x130 ./system/src/newlib/_startup.o
0x08000188_start
.after_vectors
0x080002b8 0x12c
./system/src/cortexm/exception_handlers.o
0x080002b8Reset_Handler
0x080002beNMI_Handler
0x080002c2HardFault_Handler
0x080002d6HardFault_Handler_C
0x08000334MemManage_Handler
0x08000338BusFault_Handler
0x0800034cBusFault_Handler_C
0x08000380UsageFault_Handler
0x08000394UsageFault_Handler_C
0x080003c8SVC_Handler
0x080003ccDebugMon_Handler
0x080003d0PendSV_Handler
.after_vectors
0x080003e40x4
./system/src/cmsis/vectors_stm32f407xx.o
0x080003e4DMA1_Stream3_IRQHandler
(... many more ...)
0x080003e4RTC_Alarm_IRQHandler
.inits 0x080003e8 0x2c
0x080003e8__data_regions_array_start =
.
I am aware that with LTO the code is restructured, and some functions may be
inlined, thus disapearing from the symbol table, but in this case the symbols
seem to remain in the symbol table, the problem being that the map generator
ommits them in the output file.
I'm using the Arm Embedded GCC 8.2.1 toolchain on a macOS.
[Bug inline-asm/87984] [7/8/9 Regression] wrong code for local reg var input to asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #16 from Richard Biener ---
The "issue" of GIMPLE is that while it treats local reg vars as "memory":
# .MEM_11 = VDEF <.MEM_2>
a = 1;
# VUSE <.MEM_11>
__asm__("add %1, %0" : "=g" o_16 : "r" a, "0" o_13);
it doesn't "properly" translate asm constraints mentioning only architectural
register names to alias that "memory:
__asm__ __volatile__("xor %%eax, %%eax" : : : "eax");
(this one is missing a virtual operand). We'd have to consider this kind
of "registers" memory. Currently we have
/* Clobber all memory and addressable symbols for asm ("" : : : "memory");
*/
if (gimple_asm_clobbers_memory_p (stmt))
add_virtual_operand (fn, stmt, opf_def);
that would need to include walking all local and global reg vars and
architecturally comparing the underlying register. Note how
compare_base_decls "gives up" for local reg vars unless the register
specifier is byte-for-byte the same (so it can identify some must-alias
cases but never no-alias ones).
Elsewhere people have asked for better (gimple) asm optimizations with
regard to alias analysis - currently the precision is at the virtual
operand level.
[Bug rtl-optimization/87902] [9 Regression] Shrink-wrapping multiple conditions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87902 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-05 Ever confirmed|0 |1
[Bug middle-end/89208] New: unaligned access expanded to memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89208
Bug ID: 89208
Summary: unaligned access expanded to memcpy
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
Target Milestone: ---
This test case is mis-compiled:
$ cat unaligned-argument-3.c
/* { dg-do compile } */
/* { dg-options "-ffreestanding -marm -march=armv6 -mno-unaligned-access
-mfloat-abi=soft -mabi=aapcs -O3" } */
struct s {
int a, b;
} __attribute__((packed));
void f(struct s *a, struct s *b)
{
*a = *b;
}
/* { dg-final { scan-assembler-times "ldrd" 0 } } */
/* { dg-final { scan-assembler-times "strd" 0 } } */
/* { dg-final { scan-assembler-times "ldm" 0 } } */
/* { dg-final { scan-assembler-times "stm" 0 } } */
/* { dg-final { scan-assembler-times "memcpy" 0 } } */
$ arm-linux-gnueabihf-gcc -ffreestanding -marm -march=armv6
-mno-unaligned-access -mfloat-abi=soft -mabi=aapcs -O3 -S
unaligned-argument-3.c
$ $ cat unaligned-argument-3.s
.arch armv6
.eabi_attribute 20, 1
.eabi_attribute 21, 1
.eabi_attribute 23, 3
.eabi_attribute 24, 1
.eabi_attribute 25, 1
.eabi_attribute 26, 1
.eabi_attribute 30, 2
.eabi_attribute 34, 0
.eabi_attribute 18, 4
.file "unaligned-argument-3.c"
.text
.align 2
.global f
.syntax unified
.arm
.fpu softvfp
.type f, %function
f:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
mov r2, #8
push{r4, lr}
bl memcpy
pop {r4, pc}
.size f, .-f
.ident "GCC: (GNU) 9.0.1 20190128 (experimental)"
.section.note.GNU-stack,"",%progbits
it is wrong to call memcpy if -ffreestanding is used.
[Bug inline-asm/87984] [7/8/9 Regression] wrong code for local reg var input to asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
--- Comment #17 from Alexander Monakov ---
Well, the asm with the xor was just to make the testcase more-obviously-broken,
it's still broken when %eax is clobbered in a more subtle way, like via a
libcall for integer division like in earlier examples, or simply by calling an
external function:
extern int clear_eax(void);
static inline void
ff(int *o)
{
register int a asm("eax");
a = 1;
asm("add %1, %0" : "+g"(*o) : "r"(a));
}
int f(void)
{
int o=0, i;
for (i=0; i<3; i++) {
ff(&o);
clear_eax();
}
return o;
}
[Bug libstdc++/89194] [9 regression] build failure with libstdc++ with std=c++2a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89194 Jonathan Wakely changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org --- Comment #4 from Jonathan Wakely --- Doesn't matter, I reproduced it and know what the problem is, but I think the first one is supposed to be using -std=c++2a and gcc9_stdcpp17.ii i.e. compiling the C++17 code in C++2a mode. That works, because the is_nothrow_convertible code is only in the preprocessed output if it was preprocessed as C++2a.
[Bug libstdc++/89164] can construct vector with non-copyable-but-trivially-copyable elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89164
--- Comment #4 from Jonathan Wakely ---
A similar fix is needed for uninitialized_fill and uninitialized_fill_n
otherwise this still compiles:
std::vector v3{2, X{}};
[Bug libstdc++/68350] std::uninitialized_copy overly restrictive for trivially_copyable types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68350
Jonathan Wakely changed:
What|Removed |Added
Keywords||missed-optimization
Last reconfirmed|2015-11-14 00:00:00 |2019-2-5
--- Comment #5 from Jonathan Wakely ---
To summarise:
The original report is wrong, we cannot use trivially-copyable there. The point
of the condition is to decide whether to use std::copy, because for
trivially-copyable types that is optimized to memmove. But unlike
std::uninitialized_copy, std::copy calls no constructors, so the type must be
trivially default constructible, and if an exception is thrown, it calls no
destructors, so the type must be trivially destructible as well. So we can only
use the memmove optimization for types which are trivially-copyable (which
implies trivially destructible) and trivially-default-constructible. That's a
trivial type, so __is_trivial is the right check.
The reason this bug is still open is that the other part of the condition is
overly-restrictive: the is_assignable check means that we don't optimize to
memmove for this case:
#include
struct Y {
Y() = default;
Y(const Y&) = default;
Y& operator=(const Y&) = delete;
};
static_assert(std::is_trivially_copyable::value, "");
int main()
{
alignas(Y) unsigned char buf[sizeof(Y)];
Y y;
std::uninitialized_copy(&y, &y+1, (Y*)buf);
}
This could be optimized to memmove. However, because std::copy would be
ill-formed (because std::copy does an assignment), we cannot use it, and do an
explicit copy construction using placement new. This is a missed-optimization.
[Bug target/88917] [8/9 Regression] Error: can't resolve `.text' {.text section} - `.LCFI2' {.text.unlikely section} with -fno-dwarf2-cfi-asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88917 --- Comment #4 from Jakub Jelinek --- (In reply to Florian Weimer from comment #3) > Isn't -fasynchronous-unwind-tables part of the GNU/Linux ABI and enabled by > default? Without it, asynchronous cancellation does not work. Yes, but nobody is actually using or should use -mindirect-branch=thunk-inline, we really shouldn't offer that option, and if somebody for some strange reason uses it, he could as well add -fno-asynchronous-unwind-tables. > Can we simplify this if we require frame pointers when using inline thunks? No. > Or get rid of inline thunks altogether? I'm all for this. I fail to see any advantage of that over non-inline thunks, that do have proper unwind info and are smaller from cache POV.
[Bug target/88917] [8/9 Regression] Error: can't resolve `.text' {.text section} - `.LCFI2' {.text.unlikely section} with -fno-dwarf2-cfi-asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88917 --- Comment #5 from Jakub Jelinek --- Other option is to spend a lot of energy on this. output_indirect_thunk would need to be told if it is emitted inside of normal functions or in the magic functions where it currently does the right thing already, for the normal functions walk back from current_output_insn (perhaps with some caching) to find out the previous NOTE_INSN_CFI that was already emitted, find corresponding entry in cfun->dw_fde_cfi vector, interpret the CFI instructions from the beginning until that point to figure out if the current CFA is stack pointer or something else and only if it is stack pointer, add the cfi stuff in there and undo it later. Furthermore, I see e.g. ix86_output_indirect_branch_via_push is emitting push instructions, that is again a big no no unless you adjust unwind info too.
[Bug target/88917] [8/9 Regression] Error: can't resolve `.text' {.text section} - `.LCFI2' {.text.unlikely section} with -fno-dwarf2-cfi-asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88917 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|jakub at gcc dot gnu.org |unassigned at gcc dot gnu.org
[Bug c++/89205] [8/9 Regression] Debug info size growth since r248469
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89205 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #9 from Richard Biener --- NOTABUG then.
[Bug middle-end/89208] unaligned access expanded to memcpy with -ffreestanding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89208 Richard Biener changed: What|Removed |Added Target||arm CC||rguenth at gcc dot gnu.org Summary|unaligned access expanded |unaligned access expanded |to memcpy |to memcpy with ||-ffreestanding --- Comment #1 from Richard Biener --- I _think_ even with -ffreestanding we assume some basic stuff like memcpy and memove is available, no? Note -ffreestanding is a C-family option only and thus doesn't limit the middle-end in any way.
[Bug lto/89207] Symbols missing in map file with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89207 Richard Biener changed: What|Removed |Added CC||hjl at gcc dot gnu.org --- Comment #1 from Richard Biener --- Hmm, what's your linker (version)?
[Bug middle-end/89208] unaligned access expanded to memcpy with -ffreestanding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89208 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #2 from Alexander Monakov --- Yeah, gcc not only assumes memcpy is always available like libgcc functions, but also that it's safe to call when a==b (see PR 32667 for that aspect).
[Bug middle-end/89208] unaligned access expanded to memcpy with -ffreestanding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89208
--- Comment #3 from Bernd Edlinger ---
The problem is that this pattern may be used in the implementation of memcpy.
But it reminds me much to what you did with
-ftree-loop-distribute-patterns last year,
and how it is enabled with -ffreestanding, and -fno-builtin,
thus, how about this:
Index: expr.c
===
--- expr.c (revision 268337)
+++ expr.c (working copy)
@@ -1625,6 +1625,7 @@
min_size, max_size, probable_max_size))
;
else if (may_use_call
+ && flag_tree_loop_distribute_patterns
&& ADDR_SPACE_GENERIC_P (MEM_ADDR_SPACE (x))
&& ADDR_SPACE_GENERIC_P (MEM_ADDR_SPACE (y)))
{
[Bug middle-end/89208] unaligned access expanded to memcpy with -ffreestanding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89208 --- Comment #4 from Richard Biener --- PR56888?
[Bug middle-end/89208] unaligned access expanded to memcpy with -ffreestanding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89208 --- Comment #5 from Bernd Edlinger --- (In reply to Richard Biener from comment #4) > PR56888? Yes.
[Bug middle-end/89208] unaligned access expanded to memcpy with -ffreestanding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89208 --- Comment #6 from Richard Biener --- (In reply to Bernd Edlinger from comment #5) > (In reply to Richard Biener from comment #4) > > PR56888? > > Yes. So is this a dup or are you after sth else?
[Bug middle-end/89208] unaligned access expanded to memcpy with -ffreestanding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89208 --- Comment #7 from Bernd Edlinger --- both. but if you use -fno-tree-loop-distribute-pattern I'd bet people would not want memcpy when not having asked for...
[Bug rtl-optimization/89195] [7/8/9 regression] Corrupted stack offset after combine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89195 --- Comment #11 from Wilco --- (In reply to Segher Boessenkool from comment #9) > That patch is pre-approved if it regchecks fine (on more than just x86). > Thanks! check-gcc is clean on aarch64_be-none-elf
[Bug libstdc++/89090] vector.tcc uses "if constexpr" in C++11 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89090 --- Comment #5 from Jonathan Wakely --- Author: redi Date: Tue Feb 5 14:44:56 2019 New Revision: 268536 URL: https://gcc.gnu.org/viewcvs?rev=268536&root=gcc&view=rev Log: PR libstdc++/89090 avoid C++17 features in C++11/C++14 code Although GCC and Clang both allow these features pre-C++17 in system headers, Clang does issue warnings with -Wsystem-headers. It can also complicate bisection and/or testcase reduction if # line markers are stripped, because the code won't be known to come from system headers. PR libstdc++/89090 * include/bits/stl_uninitialized.h (__relocate_a_1): Make unused parameter unnamed. Add message to static assertion. * include/bits/vector.tcc (vector::reserve, vector::_M_realloc_insert) (vector::_M_default_append): Use _GLIBCXX17_CONSTEXPR for if constexpr in C++11 code. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/stl_uninitialized.h trunk/libstdc++-v3/include/bits/vector.tcc
[Bug libstdc++/89130] [9 Regression] std::vector relocation fails for types with deleted move constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89130 --- Comment #4 from Jonathan Wakely --- Author: redi Date: Tue Feb 5 14:45:00 2019 New Revision: 268537 URL: https://gcc.gnu.org/viewcvs?rev=268537&root=gcc&view=rev Log: PR libstdc++/89130 restore support for non-MoveConstructible types The changes to "relocate" std::vector elements can lead to new errors outside the immediate context, because moving the elements to new storage no longer makes use of the move-if-noexcept utilities. This means that types with deleted moves no longer degenerate to copies, but are just ill-formed. The errors happen while instantiating the noexcept-specifier for __relocate_object_a, when deciding whether to try to relocate. This patch introduces indirections to avoid the ill-formed instantiations of std::__relocate_object_a. In order to avoid using if-constexpr prior to C++17 this is done by tag dispatching. After this patch all uses of std::__relocate_a are guarded by checks that will support sensible code (i.e. code not using custom allocators that fool the new checks). PR libstdc++/89130 * include/bits/alloc_traits.h (__is_copy_insertable_impl): Rename to __is_alloc_insertable_impl. Replace single type member with two members, one for each of copy and move insertable. (__is_move_insertable): New trait for internal use. * include/bits/stl_vector.h (vector::_S_nothrow_relocate(true_type)) (vector::_S_nothrow_relocate(true_type)): New functions to conditionally check if __relocate_a can throw. (vector::_S_use_relocate()): Dispatch to _S_nothrow_relocate based on __is_move_insertable. (vector::_S_do_relocate): New overloaded functions to conditionally call __relocate_a. (vector::_S_relocate): New function that dispatches to _S_do_relocate based on _S_use_relocate. * include/bits/vector.tcc (vector::reserve, vector::_M_realloc_insert) (vector::_M_default_append): Call _S_relocate instead of __relocate_a. * testsuite/23_containers/vector/modifiers/push_back/89130.cc: New. Added: trunk/libstdc++-v3/testsuite/23_containers/vector/modifiers/push_back/89130.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/alloc_traits.h trunk/libstdc++-v3/include/bits/stl_vector.h trunk/libstdc++-v3/include/bits/vector.tcc
[Bug libstdc++/89130] [9 Regression] std::vector relocation fails for types with deleted move constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89130 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jonathan Wakely --- (In reply to Marc Glisse from comment #3) > We already discussed this > https://gcc.gnu.org/ml/libstdc++/2018-09/msg7.html Ah yes, I thought I remembered a slightly different discussion, but it's exactly this issue. Looking at the standard, the requirements for the push_back call in comment 0 are that X is Cpp17CopyInsertable into vector, which is true. The check whether to use relocation fails if it isn't also Cpp17MoveInsertable into vector, which is not a requirement. So we do need to fix it, which I've now done.
[Bug libstdc++/89090] vector.tcc uses "if constexpr" in C++11 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89090 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jonathan Wakely --- The C++17 features are no longer used. This makes me sad.
[Bug tree-optimization/88606] [9 Regression] ICE: verify_type failed (error: type variant differs by TYPE_TRANSPARENT_AGGR)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88606 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Biener --- Fixed.
[Bug tree-optimization/88606] [9 Regression] ICE: verify_type failed (error: type variant differs by TYPE_TRANSPARENT_AGGR)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88606 --- Comment #6 from Richard Biener --- Author: rguenth Date: Tue Feb 5 14:57:32 2019 New Revision: 268540 URL: https://gcc.gnu.org/viewcvs?rev=268540&root=gcc&view=rev Log: 2019-02-05 Richard Biener PR c/88606 * c-decl.c (finish_struct): Reset TYPE_TRANSPARENT_AGGR on all type variants when not supported. Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-decl.c
[Bug libstdc++/89130] [9 Regression] std::vector relocation fails for types with deleted move constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89130 --- Comment #6 from Marc Glisse --- (In reply to Jonathan Wakely from comment #5) > Looking at the standard, the requirements for the push_back call in comment > 0 are that X is Cpp17CopyInsertable into vector, which is true. The check > whether to use relocation fails if it isn't also Cpp17MoveInsertable into > vector, which is not a requirement. So we do need to fix it, which I've > now done. "T is Cpp17CopyInsertable into X means that, in addition to T being Cpp17MoveInsertable into X, [...]"
[Bug libstdc++/89130] [9 Regression] std::vector relocation fails for types with deleted move constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89130 --- Comment #7 from Jonathan Wakely --- Oh, so it does. So I guess I could revert r268537 then. The downstream package where this caused a build failure was already changed to stop (foolishly) deleting move ctors, so it's not causing any more problems that I know of.
[Bug middle-end/89208] unaligned access expanded to memcpy with -ffreestanding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89208
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #8 from Jakub Jelinek ---
(In reply to Bernd Edlinger from comment #3)
> --- expr.c(revision 268337)
> +++ expr.c(working copy)
> @@ -1625,6 +1625,7 @@
> min_size, max_size, probable_max_size))
> ;
>else if (may_use_call
> +&& flag_tree_loop_distribute_patterns
> && ADDR_SPACE_GENERIC_P (MEM_ADDR_SPACE (x))
> && ADDR_SPACE_GENERIC_P (MEM_ADDR_SPACE (y)))
> {
This is certainly wrong. flag_tree_loop_distribute_patterns is false most of
the time, it is an option normally enabled by default for -O3 only.
If you want to check for explicit -fno-tree-loop-distribute-patterns, then it
would be && (!global_options_set.x_flag_tree_loop_distribute_patterns
|| flag_tree_loop_distribute_patterns))
but it still doesn't look correct nor desirable to me.
[Bug libstdc++/89130] [9 Regression] std::vector relocation fails for types with deleted move constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89130 --- Comment #8 from Marc Glisse --- (In reply to Jonathan Wakely from comment #7) > So I guess I could revert r268537 then. I don't think it was worth spending time on in the first place, but now that you have written it, it isn't as bad as I feared. I am usually in favor of **not** gratuitously rejecting things because the concept says so, unless we expect some use with SFINAE (although I see in PR 89164 that you prefer to be strict). Besides, isn't part of this patch also necessary for the if constexpr change?
[Bug tree-optimization/88771] [9 Regression] Misleading -Werror=array-bounds error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88771 Martin Sebor changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org --- Comment #16 from Martin Sebor --- Let me look into at least improving the diagnostic output for now.
[Bug target/88856] [8/9 Regression] gfortran producing wrong code with -funroll-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88856 --- Comment #16 from Andreas Krebbel --- I'll commit a patch which just removes the splitter for now. I'll try to come up with a nicer testcase.
[Bug middle-end/89208] unaligned access expanded to memcpy with -ffreestanding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89208 --- Comment #9 from Bernd Edlinger --- I would like to suppress the optimization when -ffreestanding, or fno-builtin, is used, but I agree that it will probably stretch -fno-loop-distribute-patterns a bit too much to cover this. OTOH -fno-loop-distribute-patterns was initially the only way we told people how gcc is not generating memcpy from the loop optimization. See the comment in c-family/c-opts.c: "If -ffreestanding, -fno-hosted or -fno-builtin then disable pattern recognition."
[Bug libstdc++/89130] [9 Regression] std::vector relocation fails for types with deleted move constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89130 --- Comment #9 from Jonathan Wakely --- With the removal of if constexpr we would unconditionally instantiate __relocate_a, which could fail ... but only in cases like a deleted move constructor. This avoids that instantiation, so it doesn't fail for weird types, and doesn't spend time instantiating a function template that isn't needed. Not strictly necessary, but like you say, it avoids gratuitously rejecting some types that are weird, but can still be used in limited ways. OK, let's leave it like this.
