[Bug libstdc++/64781] regex out-of-range submatches should represent an unmatched sub-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64781 Tim Shen changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Tim Shen --- Duplicated to 64441.
[Bug c++/65354] Converting lambda to pointer results in double destruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65354
--- Comment #2 from Charlie ---
Here's a more succinct example (using the "+" trick to convert to a function
pointer):
#include
int main ()
{
auto f = +[] (std::string s)
{
return std::string (std::move (s));
};
std::string s ("hello");
f (std::move (s));
}
[Bug target/65358] wrong parameter passing code with tail call optimization on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65358 Mikael Pettersson changed: What|Removed |Added CC||mikpelinux at gmail dot com --- Comment #3 from Mikael Pettersson --- Created attachment 34986 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34986&action=edit test case Here's a runtime test case that reproduces the wrong-code for me on armv5tel-linux-gnueabi and armv7l-linux-gnueabi, with (at least) gcc 4.9 and 4.8.
[Bug rtl-optimization/65321] [5 Regression] ICE on valid code at -O2 and -O3 with -g enabled in decompose, at rtl.h:2007
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65321 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #8 from Jakub Jelinek --- Created attachment 34987 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34987&action=edit gcc5-pr65321.patch >From what I've seen, backends generally ensure that the shift amount mode is not wider than the shift mode, so it is just the debug insns where this wasn't enforced. Fixed thusly (untested so far), does this look reasonable?
[Bug target/65358] wrong parameter passing code with tail call optimization on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65358 --- Comment #4 from Honggyu Kim --- Dear Mikael Pettersson I also have a runtime testcase, which is different from dejagnu format. Can I add this testcase with your modification as my first gcc contribution? :) I was trying to fix this bug myself for about 2 weeks but maybe I need some help from the community. I appreciate your help. Honggyu
[Bug target/65358] wrong parameter passing code with tail call optimization on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65358 --- Comment #5 from Honggyu Kim --- I just wrote foo function code separately to debug gcc more easily by compile only problematic code.
[Bug c/65357] aggressive loop optimization not correct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65357 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Perhaps by enabling warnings? E.g. with -Wall you get all the important warnings: warning: operation on ‘list’ may be undefined [-Wsequence-point] (twice) and warning: return type of ‘main’ is not ‘int’ [-Wmain]
[Bug target/65358] wrong parameter passing code with tail call optimization on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65358 --- Comment #6 from Mikael Pettersson --- (In reply to Honggyu Kim from comment #4) > Can I add this testcase with your modification as my first gcc contribution? > :) Sure, just attach it to this PR as a new test case.
[Bug c/65357] aggressive loop optimization not correct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65357 --- Comment #6 from Andrew Pinski --- I missed there was a sequence point issue there too :).
[Bug c++/65284] [5 Regression] C++ lambda and auto return value causes ICE or gimple error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65284 Ramana Radhakrishnan changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug tree-optimization/44563] GCC uses a lot of RAM when compiling a large numbers of functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44563 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #15 from Richard Biener --- Meanwhile finished to compile at -O1: ipa inlining heuristics : 155.14 (12%) usr 0.37 ( 2%) sys 155.31 (12%) wall 396289 kB (11%) ggc integration : 958.73 (75%) usr 2.18 (13%) sys 960.89 (74%) wall 86527 kB ( 2%) ggc tree CFG cleanup: 116.57 ( 9%) usr 0.30 ( 2%) sys 116.77 ( 9%) wall 0 kB ( 0%) ggc TOTAL :1285.2517.15 1302.17 3514948 kB
[Bug fortran/65359] New: [OOP] undefined output with array and inheritance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65359 Bug ID: 65359 Summary: [OOP] undefined output with array and inheritance Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: tkoenig at gcc dot gnu.org Originally from http://stackoverflow.com/questions/28933061/using-1n-with-inherited-classes-works-weirdly-in-gfortran : module try_mod implicit none type, public :: Inner_t integer :: i real :: r end type Inner_t type, public, extends(Inner_t) :: InnerSpec_t integer :: j end type InnerSpec_t type, public :: Outer_t integer :: nelem class( Inner_t ), allocatable, dimension(:) :: elem contains procedure :: init => initOuter end type Outer_t contains subroutine initOuter(this) class(Outer_t), intent(inout) :: this integer :: i, suma, k this%nelem = 4 allocate( InnerSpec_t :: this%elem(1:this%nelem) ) this%elem(1:2)%i = -100 this%elem(3:4)%i = -200 print*, '1st: ', this%elem(1:this%nelem)%i print*, '2nd: ', this%elem(1)%i, this%elem(2)%i, this%elem(3)%i, this%elem(4)%i this%elem(1)%i = 91 this%elem(2)%i = 92 this%elem(3)%i = 93 this%elem(4)%i = 94 print*,'3rd: ', this%elem(1:4)%i print*,'4th: ', this%elem(1)%i, this%elem(2)%i, this%elem(3)%i, this%elem(4)%i end subroutine initOuter end module try_mod program adgo use try_mod implicit none type( Outer_t ) :: outer call outer%init() end program ... has some undefined output (also according to valgrind).
[Bug libstdc++/64441] A match_results returns an incorrect sub_match if the sub_match::matched is false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64441 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-09 Ever confirmed|0 |1
[Bug libstdc++/64441] A match_results returns an incorrect sub_match if the sub_match::matched is false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64441 Jonathan Wakely changed: What|Removed |Added CC||kaballo86 at hotmail dot com --- Comment #3 from Jonathan Wakely --- *** Bug 64781 has been marked as a duplicate of this bug. ***
[Bug libstdc++/64781] regex out-of-range submatches should represent an unmatched sub-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64781 Jonathan Wakely changed: What|Removed |Added Resolution|FIXED |DUPLICATE --- Comment #2 from Jonathan Wakely --- This should be resolved as a duplicate, not FIXED. *** This bug has been marked as a duplicate of bug 64441 ***
[Bug c++/65336] name lookup finds operator in unnamed namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65336 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Jonathan Wakely --- Closing as a dup, I'll add the testcase to the other bug. *** This bug has been marked as a duplicate of bug 51577 ***
[Bug c++/51577] dependent name lookup finds operator in global namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51577 Jonathan Wakely changed: What|Removed |Added CC||thibaut.lutz at googlemail dot com --- Comment #9 from Jonathan Wakely --- *** Bug 65336 has been marked as a duplicate of this bug. ***
[Bug c++/51577] dependent name lookup finds operator in global namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51577
--- Comment #10 from Jonathan Wakely ---
Testcase from PR65336:
extern "C" int puts(const char*);
struct ostream {} cout;
template struct A{ T t; };
struct B{};
struct C : public B{};
ostream& operator<< (ostream& out, const B&)
{ puts("right"); return out; }
namespace {
template
ostream& operator<< (ostream& out, const A&v)
{ return out << v.t; }
ostream& operator<< (ostream& out, const C&)
{ puts("wrong"); return out; }
}
int main(){
A a;
cout << a;
}
[Bug c++/51577] dependent name lookup finds operator in global namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51577
--- Comment #11 from Jonathan Wakely ---
And the testcase from PR 61161:
struct T {
template void f(const T &v) {
0 << v;
}
};
namespace N {
struct X {};
struct Y : X {};
void operator<<(int, const X&) {}
}
void operator<<(int, const N::Y&) = delete;
int main() {
N::Y d;
T().f(d);
}
[Bug c++/65354] Converting lambda to pointer results in double destruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65354 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Jonathan Wakely --- This is PR 62052 *** This bug has been marked as a duplicate of bug 62052 ***
[Bug c++/62052] function parameter has wrong address in lambda converted to pointer-to-function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62052 Jonathan Wakely changed: What|Removed |Added CC||charlie at charliedyson dot net --- Comment #2 from Jonathan Wakely --- *** Bug 65354 has been marked as a duplicate of this bug. ***
[Bug c++/62052] function parameter has wrong address in lambda converted to pointer-to-function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62052
--- Comment #3 from Jonathan Wakely ---
Segfaulting testcase from PR 65354:
#include
int main ()
{
auto f = +[] (std::string s)
{
return std::string (std::move (s));
};
std::string s ("hello");
f (std::move (s));
}
[Bug rtl-optimization/65321] [5 Regression] ICE on valid code at -O2 and -O3 with -g enabled in decompose, at rtl.h:2007
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65321 Richard Biener changed: What|Removed |Added Assignee|rguenth at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #9 from Richard Biener --- looks reasonable
[Bug fortran/60780] Equivalence statements in nested modules results in fast growing duplicate statements in module files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60780 --- Comment #5 from Dominique d'Humieres --- I have doubled the number of modules to get the following results gcc version 4.8.5 21.907u 0.994s 0:23.00 99.5%0+0k 0+22io 3pf+0w -rw-r--r-- 1 dominiq staff 2923 Mar 9 10:59 module0.mod -rw-r--r-- 1 dominiq staff 3079 Mar 9 10:59 module1.mod -rw-r--r-- 1 dominiq staff 4230 Mar 9 10:59 module2.mod -rw-r--r-- 1 dominiq staff 6376 Mar 9 10:59 module3.mod -rw-r--r-- 1 dominiq staff10512 Mar 9 10:59 module4.mod -rw-r--r-- 1 dominiq staff18628 Mar 9 10:59 module5.mod -rw-r--r-- 1 dominiq staff34704 Mar 9 10:59 module6.mod -rw-r--r-- 1 dominiq staff66700 Mar 9 10:59 module7.mod -rw-r--r-- 1 dominiq staff 130536 Mar 9 10:59 module8.mod -rw-r--r-- 1 dominiq staff 258052 Mar 9 10:59 module9.mod -rw-r--r-- 1 dominiq staff 512931 Mar 9 10:59 module10.mod -rw-r--r-- 1 dominiq staff 1022530 Mar 9 10:59 module11.mod -rw-r--r-- 1 dominiq staff 2041569 Mar 9 10:59 module12.mod -rw-r--r-- 1 dominiq staff 4079488 Mar 9 10:59 module13.mod -rw-r--r-- 1 dominiq staff 8155167 Mar 9 10:59 module14.mod -rw-r--r-- 1 dominiq staff 16306366 Mar 9 10:59 module15.mod -rw-r--r-- 1 dominiq staff 32608774 Mar 9 10:59 module16.mod gcc version 4.9.3 5.432u 0.389s 0:06.00 96.8%0+0k 8+19io 1355pf+0w -rw-r--r-- 1 dominiq staff485 Mar 9 11:03 module0.mod -rw-r--r-- 1 dominiq staff498 Mar 9 11:03 module1.mod -rw-r--r-- 1 dominiq staff526 Mar 9 11:03 module2.mod -rw-r--r-- 1 dominiq staff560 Mar 9 11:03 module3.mod -rw-r--r-- 1 dominiq staff602 Mar 9 11:03 module4.mod -rw-r--r-- 1 dominiq staff668 Mar 9 11:03 module5.mod -rw-r--r-- 1 dominiq staff770 Mar 9 11:03 module6.mod -rw-r--r-- 1 dominiq staff952 Mar 9 11:03 module7.mod -rw-r--r-- 1 dominiq staff 1279 Mar 9 11:03 module8.mod -rw-r--r-- 1 dominiq staff 1911 Mar 9 11:03 module9.mod -rw-r--r-- 1 dominiq staff 3165 Mar 9 11:03 module10.mod -rw-r--r-- 1 dominiq staff 5650 Mar 9 11:03 module11.mod -rw-r--r-- 1 dominiq staff 10603 Mar 9 11:03 module12.mod -rw-r--r-- 1 dominiq staff 20493 Mar 9 11:03 module13.mod -rw-r--r-- 1 dominiq staff 40276 Mar 9 11:03 module14.mod -rw-r--r-- 1 dominiq staff 79811 Mar 9 11:03 module15.mod -rw-r--r-- 1 dominiq staff 158891 Mar 9 11:03 module16.mod gcc version 5.0.0 5.525u 0.381s 0:06.06 97.3%0+0k 9+23io 1605pf+0w -rw-r--r-- 1 dominiq staff485 Mar 9 11:07 module0.mod -rw-r--r-- 1 dominiq staff500 Mar 9 11:07 module1.mod -rw-r--r-- 1 dominiq staff529 Mar 9 11:07 module2.mod -rw-r--r-- 1 dominiq staff562 Mar 9 11:07 module3.mod -rw-r--r-- 1 dominiq staff606 Mar 9 11:07 module4.mod -rw-r--r-- 1 dominiq staff672 Mar 9 11:07 module5.mod -rw-r--r-- 1 dominiq staff774 Mar 9 11:07 module6.mod -rw-r--r-- 1 dominiq staff956 Mar 9 11:07 module7.mod -rw-r--r-- 1 dominiq staff 1283 Mar 9 11:07 module8.mod -rw-r--r-- 1 dominiq staff 1915 Mar 9 11:07 module9.mod -rw-r--r-- 1 dominiq staff 3170 Mar 9 11:07 module10.mod -rw-r--r-- 1 dominiq staff 5650 Mar 9 11:07 module11.mod -rw-r--r-- 1 dominiq staff 10603 Mar 9 11:07 module12.mod -rw-r--r-- 1 dominiq staff 20493 Mar 9 11:07 module13.mod -rw-r--r-- 1 dominiq staff 40276 Mar 9 11:07 module14.mod -rw-r--r-- 1 dominiq staff 79811 Mar 9 11:07 module15.mod -rw-r--r-- 1 dominiq staff 158891 Mar 9 11:07 module16.mod gcc version 5.0.0 with the patch in pr40958 comment 18 0.045u 0.034s 0:00.24 29.1%0+0k 12+18io 1767pf+0w -rw-r--r-- 1 dominiq staff 485 Mar 9 11:07 module0.mod -rw-r--r-- 1 dominiq staff 500 Mar 9 11:07 module1.mod -rw-r--r-- 1 dominiq staff 515 Mar 9 11:09 module2.mod -rw-r--r-- 1 dominiq staff 527 Mar 9 11:09 module3.mod -rw-r--r-- 1 dominiq staff 539 Mar 9 11:09 module4.mod -rw-r--r-- 1 dominiq staff 552 Mar 9 11:09 module5.mod -rw-r--r-- 1 dominiq staff 567 Mar 9 11:09 module6.mod -rw-r--r-- 1 dominiq staff 578 Mar 9 11:09 module7.mod -rw-r--r-- 1 dominiq staff 590 Mar 9 11:09 module8.mod -rw-r--r-- 1 dominiq staff 603 Mar 9 11:09 module9.mod -rw-r--r-- 1 dominiq staff 621 Mar 9 11:09 module10.mod -rw-r--r-- 1 dominiq staff 632 Mar 9 11:09 module11.mod -rw-r--r-- 1 dominiq staff 647 Mar 9 11:09 module12.mod -rw-r--r-- 1 dominiq staff 663 Mar 9 11:09 module13.mod -rw-r--r-- 1 dominiq staff 677 Mar 9 11:09 module14.mod -rw-r--r-- 1 dominiq staff 692 Mar 9 11:09 module15.mod -rw-r--r-- 1 dominiq staff 728 Mar 9 11:09 module16.mod Without the patch the module sizes double each time a module is added (asymptotic behavior) while the prefactor for 4.9 and 5.0 is ~200 smaller compared to 4.8. With the patch, the compile time is negligible and the module sizes increase is quite small (linear?). May be the patch should be submitted to fort...@gcc.gnu.org (for next stage1).
[Bug c/65360] New: Compiler error, while using gcc xml to parse a .c and a .h file at the same time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65360 Bug ID: 65360 Summary: Compiler error, while using gcc xml to parse a .c and a .h file at the same time Product: gcc Version: 4.4.6 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: pierre.sassoulas at fr dot thalesgroup.com Created attachment 34988 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34988&action=edit The small test project for gccxml and the command line gcc -v : Utilisation des specs internes. Target: x86_64-redhat-linux Configuré avec: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Modèle de thread: posix gcc version 4.4.6 20120305 (Red Hat 4.4.6-4) (GCC) I'm using the ab651a2aa866351bdd089a4bf1d57f6a9bec2a66 commit of https://github.com/gccxml/gccxml to make a test for gcc_xml with a small project (with a single .h and .c file). When I give both the .h and the .c, I get a compiler error. Command : ./gccxml_install/bin/gccxml -fno-strict-aliasing -fwrapv -I test_duo_lib-src/lib -o duo_lib-src_compilé test_duo_lib-src/src/main.c test_duo_lib-src/lib/mylib.h -fxml=resultat_test_duo_lib-src.xml Result : :0: internal compiler error: in push_srcloc, at toplev.c:970 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. I can't give the .i (-save-temp is not a recognised command). I can't attach the gccxml build either it's heavy and configured by cmake with static path.
[Bug c/65360] Compiler error, while using gcc xml to parse a .c and a .h file at the same time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65360 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- Please report this bug in gcc xml since we don't support that here.
[Bug ipa/65270] [5 regression] issues with merging memory accesses from different code paths
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65270 Richard Biener changed: What|Removed |Added Status|REOPENED|ASSIGNED --- Comment #32 from Richard Biener --- (In reply to Jan Hubicka from comment #30) > OK, thanks! Any ideas on Comment 26/27 testcases? I have a patch.
[Bug libgomp/65338] [5 Regression] Offloading from DSO is broken after OpenACC merge to trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65338 Thomas Schwinge changed: What|Removed |Added Keywords||openacc, openmp Assignee|unassigned at gcc dot gnu.org |jules at gcc dot gnu.org Target Milestone|--- |5.0
[Bug tree-optimization/44563] GCC uses a lot of RAM when compiling a large numbers of functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44563
--- Comment #16 from Richard Biener ---
callgrind shows the cgraph_edge_hasher quite high in the profile (via
redirect_all_calls). I suppose as the large main is a single BB walking
all stmts over-and-over is quite bad. Also hash_pointer isn't inlined!?
Ah - it's external in libiberty hashtab.c ... - it should transition to
using/inheriting from pointer_hash.
cgraph_edge *
cgraph_node::get_edge (gimple call_stmt)
{
cgraph_edge *e, *e2;
int n = 0;
if (call_site_hash)
return call_site_hash->find_with_hash (call_stmt,
htab_hash_pointer (call_stmt));
The estimate_calls_size_and_time portion is quite smaller.
cleanup-cfgs main portion is split_bb_on_noreturn_calls.
[Bug rtl-optimization/65321] [5 Regression] ICE on valid code at -O2 and -O3 with -g enabled in decompose, at rtl.h:2007
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65321 --- Comment #10 from rsandifo at gcc dot gnu.org --- Thanks, looks good to me too FWIW.
[Bug tree-optimization/65335] Potential optimization issue with 'tree-loop-vectorize'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65335
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-03-09
CC||law at gcc dot gnu.org,
||rguenth at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
This is if-conversion at work making the code vectorizable. You can disable it
with -fno-tree-loop-if-convert.
It's not easy to assess profitablility here (well, locally it should use
bb frequencies), as computing a*a*a*a*a always could be a win if vectorizing
the rest of the loop compensates for the cost.
In this case the optimal thing to do is to turn the loop into a loop nest.
Not sure how you'd call this kind of loop transform - sth with unswitching
IV-based conditions (it's not exactly splitting in this case). We want
for (int j = 0; j < 1/1000; j++){
int i;
for (i = j*1000; i < 999; ++i)
buffer[i] = a;
a = a * a * a * a * a;
buffer[i] = a;
}
so we can vectorize the inner loop and don't need to evaluate the conditional
there.
[Bug tree-optimization/65337] [5 Regression] bootstrap-lto gnat1 linktime ICE: gcc/ada/exp_aggr.adb:6570:0: internal compiler error: in forward_edge_to_pdom, at tree-ssa-dce.c:1086
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65337 Richard Biener changed: What|Removed |Added Keywords||build Target||x86_64-*-* Component|bootstrap |tree-optimization Target Milestone|--- |5.0 Summary|5.0 bootstrap-lto gnat1 |[5 Regression] |linktime ICE: |bootstrap-lto gnat1 |gcc/ada/exp_aggr.adb:6570:0 |linktime ICE: |: internal compiler error: |gcc/ada/exp_aggr.adb:6570:0 |in forward_edge_to_pdom, at |: internal compiler error: |tree-ssa-dce.c:1086 |in forward_edge_to_pdom, at ||tree-ssa-dce.c:1086
[Bug libgomp/65338] Offloading from DSO is broken after OpenACC merge to trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65338 Richard Biener changed: What|Removed |Added Target Milestone|5.0 |--- Summary|[5 Regression] Offloading |Offloading from DSO is |from DSO is broken after|broken after OpenACC merge |OpenACC merge to trunk |to trunk --- Comment #1 from Richard Biener --- Technically not a regression - no released compiler worked.
[Bug target/65341] [5 Regression] glibc build failure on ppc64le: setcontext.S:367: Error: junk at end of line: `1,0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65341 Richard Biener changed: What|Removed |Added Target Milestone|--- |5.0
[Bug target/65351] [5 Regression] ld: absolute addressing (perhaps -mdynamic-no-pic) used in _byte_common_op_match_null_string_p from ../libiberty/pic/libiberty.a(regex.o) not allowed ... on powerpc-a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65351 Richard Biener changed: What|Removed |Added Target Milestone|--- |5.0
[Bug go/65349] [5 Regression] go tool crashes, can't compile go code on 32bit linux systems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65349 Richard Biener changed: What|Removed |Added Target Milestone|--- |5.0
[Bug middle-end/65346] [5 Regression] glibc make check failures since r214941
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65346 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||rguenth at gcc dot gnu.org Resolution|--- |DUPLICATE Target Milestone|--- |5.0 --- Comment #2 from Richard Biener --- I think we have a duplicate for this. *** This bug has been marked as a duplicate of bug 64715 ***
[Bug tree-optimization/64715] [5 Regression] __builtin_object_size (..., 1) fails to locate subobject
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64715 Richard Biener changed: What|Removed |Added CC||trippels at gcc dot gnu.org --- Comment #7 from Richard Biener --- *** Bug 65346 has been marked as a duplicate of this bug. ***
[Bug go/65353] [5 Regression] unknown ptrSize for $GOARCH "arm64" on aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65353 Richard Biener changed: What|Removed |Added Target Milestone|--- |5.0
[Bug target/65342] [5 Regression] FAIL: gfortran.dg/intrinsic_(un)?pack_1.f90 -O1 execution test on powerpc-apple-darwin9 after r210201
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65342 Richard Biener changed: What|Removed |Added Target Milestone|--- |5.0
[Bug preprocessor/65238] [5 Regression] __has_attribute is not handled properly with -traditional-cpp.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65238 Jakub Jelinek changed: What|Removed |Added CC||emsr at gcc dot gnu.org, ||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- I guess we should start with whether we preprocessing of the __has_cpp_attribute and __has_attribute argument is desirable or not. I've looked at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4200 and whether attribute-token is macro expanded or not is not really clear from that. Trying Marek's 1) testcase with normal -E rather than -traditional-cpp, it is macro expanded in gcc (int i; is in the output), while it is not in clang (at least 3.5.0). If we don't want to expand macros, then we'd need to increment state.prevent_expansion around the processing of the __has*_attribute built-in macros. If we do want to expand macros, then I'd say we most likely just don't want to support it at all in -traditional-cpp mode (i.e. do the n -= 4 thing), because to me expansion of the arguments looks fundamentally incompatible with the traditional preprocessing, which works by recursively feeding the result of macro expansion to the preprocessor again. So, Ed/Jason, what does C++ intend here?
[Bug libstdc++/43660] range of random-number generator seems wrong/confusing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43660 --- Comment #5 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #2) > (In reply to comment #0) > > [Note that the same issue exists with other ways of invoking using the > > generator (e.g., a std::uniform_real_distribution with bounds of > > 0 and 1 will indeed return 1); but it's less clear its a bug in those > > cases (although, for instance, boost's random implementation never > > seems to return the upper bound).] > > Again, referring to the latest draft: > "A uniform_real_distribution random number distribution produces random > numbers x, a <= x < b" > > So that does appear to be a bug PR 64351 deals with that case.
[Bug lto/65361] New: [5 Regression] LTO: tree check: expected tree that contains ‘decl minimal’ structure, have ‘tree_binfo’ in add_type_duplicate, at ipa-devirt.c:1509
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65361 Bug ID: 65361 Summary: [5 Regression] LTO: tree check: expected tree that contains ‘decl minimal’ structure, have ‘tree_binfo’ in add_type_duplicate, at ipa-devirt.c:1509 Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org CC: hubicka at gcc dot gnu.org Created attachment 34989 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34989&action=edit one.ii Follow up to PR65276, PR65302 and PR65316, still for the same program - but I have the feeling, we are slowly getting there. The real-program's message is slightly different (get_odr_type, at ipa-devirt.c:1704). g++ -c -std=c++11 -flto -O2 two.ii one.ii gcc -r -nostdlib two.o one.o one.ii:66:21: warning: type ‘struct ctype’ violates one definition rule [-Wodr] template <> class ctype < char > ^ two.ii:51:21: note: a type with the same name but different number of polymorphic bases is defined in another translation unit template <> class ctype < char >:public locale::facet, public ctype_base ^ lto1: internal compiler error: tree check: expected tree that contains ‘decl minimal’ structure, have ‘tree_binfo’ in add_type_duplicate, at ipa-devirt.c:1509 0xca3d94 tree_contains_struct_check_failed(tree_node const*, tree_node_structure_enum, char const*, int, char const*) ../../gcc/tree.c:9468 0x8948ec contains_struct_check(tree_node*, tree_node_structure_enum, char const*, int, char const*) ../../gcc/tree.h:2960 0x8948ec add_type_duplicate ../../gcc/ipa-devirt.c:1508 0x8948ec get_odr_type(tree_node*, bool) ../../gcc/ipa-devirt.c:1763 0x89694f register_odr_type(tree_node*) ../../gcc/ipa-devirt.c:1839
[Bug lto/65361] [5 Regression] LTO: tree check: expected tree that contains ‘decl minimal’ structure, have ‘tree_binfo’ in add_type_duplicate, at ipa-devirt.c:1509
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65361 --- Comment #1 from Tobias Burnus --- Created attachment 34990 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34990&action=edit two.ii
[Bug libstdc++/64351] std::uniform_real_distribution(0, 1) returns 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64351 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-09 Ever confirmed|0 |1 --- Comment #2 from Jonathan Wakely --- Ed, did you test that patch?
[Bug libstdc++/64467] [5 Regression] 28_regex/traits/char/isctype.cc and wchar_t/isctype.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64467 --- Comment #17 from Jonathan Wakely --- Author: redi Date: Mon Mar 9 12:47:51 2015 New Revision: 221279 URL: https://gcc.gnu.org/viewcvs?rev=221279&root=gcc&view=rev Log: PR libstdc++/64467 * testsuite/28_regex/traits/char/isctype.cc: Don't test newline for newlib targets. Really fix mixed line-endings this time. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/testsuite/28_regex/traits/char/isctype.cc
[Bug c++/64446] Misleading error message when inheriting from a template class w/o the template params
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64446 Jonathan Wakely changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-09 Ever confirmed|0 |1 --- Comment #2 from Jonathan Wakely --- (In reply to petschy from comment #0) > 'Base' is definitely a valid class name. No it isn't, Base is a class template, and that is not a class. The error message is completely accurate, although it could be improved to say how to fix the code. Clang also says: p.cc:6:14: error: expected class name struct Foo : Base ^ EDG gives a better error: "p.cc", line 6: error: argument list for class template "Base" is missing struct Foo : Base ^ "p.cc", line 6: error: not a class or struct name struct Foo : Base ^ Ideally the compiler would recognise that Base is a template and point out that the template argument list is missing.
[Bug libstdc++/64467] [5 Regression] 28_regex/traits/char/isctype.cc and wchar_t/isctype.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64467 Jonathan Wakely changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #18 from Jonathan Wakely --- Fixed, I hope permanently!
[Bug lto/65361] [5 Regression] LTO: tree check: expected tree that contains ‘decl minimal’ structure, have ‘tree_binfo’ in add_type_duplicate, at ipa-devirt.c:1509
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65361 Richard Biener changed: What|Removed |Added Target Milestone|--- |5.0
[Bug ipa/65270] [5 regression] issues with merging memory accesses from different code paths
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65270 --- Comment #33 from Richard Biener --- Author: rguenth Date: Mon Mar 9 13:54:28 2015 New Revision: 221281 URL: https://gcc.gnu.org/viewcvs?rev=221281&root=gcc&view=rev Log: 2015-03-09 Richard Biener PR middle-end/65270 * tree-core.h (enum operand_equal_flag): Add OEP_ADDRESS_OF. * fold-const.c (operand_equal_p): When recursing for ADDR_EXPRs operand set OEP_ADDRESS_OF. Clear it when recursing to non-bases of that. When comparing dereferences compare alignment. When comparing MEM_REFs or TARGET_MEM_REFs compare dependence info. * gcc.dg/torture/pr65270-1.c: New testcase. * gcc.dg/torture/pr65270-2.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/torture/pr65270-1.c trunk/gcc/testsuite/gcc.dg/torture/pr65270-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-core.h
[Bug middle-end/65330] restrict should be considered when folding through references from global vars
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65330 Bug 65330 depends on bug 65270, which changed state. Bug 65270 Summary: [5 regression] issues with merging memory accesses from different code paths https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65270 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug ipa/65270] [5 regression] issues with merging memory accesses from different code paths
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65270 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #34 from Richard Biener --- Fixed (again - please open new bugreports for new issues ... the last fix is eligible for backporting I think).
[Bug c++/65292] Template function not emitted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65292 --- Comment #8 from John Marino --- As a final follow up, webkit-qt5 built on a March 8 version of gcc5 with no changes from my previous attempt. Good news, thanks for the patch! John
[Bug tree-optimization/65177] [5 Regression]: extend jump thread for finite state automata causes miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65177 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- Any progress on this? I've tried to reproduce but have the miscompile vs. compile dbg counter on ~ current trunk (221277) in a different spot (=198 works, =199 fails) and even with r21 different bbs and SSA_NAME versions, so it is hard to find out if we are looking at the same thing.
[Bug target/65342] [5 Regression] FAIL: gfortran.dg/intrinsic_(un)?pack_1.f90 -O1 execution test on powerpc-apple-darwin9 after r210201
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65342 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P4 CC||jakub at gcc dot gnu.org
[Bug c++/65269] internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65269 Andrew Sutton changed: What|Removed |Added CC||andrew.n.sutton at gmail dot com --- Comment #2 from Andrew Sutton --- This was caused by not checking that current_template_parms was valid during when building constraints for the declaration. This is was fixed in the last commit (221280).
[Bug go/65353] [5 Regression] unknown ptrSize for $GOARCH "arm64" on aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65353 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P4 CC||jakub at gcc dot gnu.org
[Bug lto/65361] [5 Regression] LTO: tree check: expected tree that contains ‘decl minimal’ structure, have ‘tree_binfo’ in add_type_duplicate, at ipa-devirt.c:1509
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65361 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-09 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Marek Polacek --- Confirmed.
[Bug go/65349] [5 Regression] go tool crashes, can't compile go code on 32bit linux systems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65349 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P4 CC||jakub at gcc dot gnu.org
[Bug tree-optimization/62630] [5 regression] gcc.dg/graphite/vect-pr43423.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62630 Jakub Jelinek changed: What|Removed |Added Priority|P1 |P2 --- Comment #19 from Jakub Jelinek --- I think in any case a graphite issue is not severe enough to justify P1.
[Bug fortran/65024] [4.9/5 Regression] [OOP] ICE concerning unlimited polymorphic pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65024 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |4.9.3
[Bug tree-optimization/65355] [4.8/4.9/5 Regression] vectorizer increase alignment of symbols already placed in anchors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65355 Richard Biener changed: What|Removed |Added Keywords||wrong-code Target Milestone|--- |4.8.5
[Bug target/65121] [5 regression] long_call attribute broken weak symbol arm*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65121 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |5.0
[Bug c++/65323] [4.8/4.9/5 Regression] duplicate -Wzero-as-null-pointer-constant warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65323 Richard Biener changed: What|Removed |Added Keywords||diagnostic Priority|P3 |P2 Target Milestone|--- |4.8.5
[Bug target/65222] [5 Regression] -mtune= or -march=: Not all options not documented: slm, knl, shanghai, istanbul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65222 Richard Biener changed: What|Removed |Added Target||x86_64-*-*, i?86-*-* Target Milestone|--- |5.0
[Bug fortran/65045] [4.8/4.9/5 Regression] ICE when using the same name for a block and a variable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65045 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #2 from Paul Thomas --- Created attachment 34991 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34991&action=edit Draft patch for the PR The attached patch bootstraps and regtests on trunk with FC21/x86_64. Paul
[Bug target/65121] [5 regression] long_call attribute broken weak symbol arm*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65121 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- So, what is the status of testing this? It passed bootstrap/regtest here for armv7hl-linux, no regressions.
[Bug libgomp/65362] New: OpenACC compilation on Tegra K1 (ARM)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65362 Bug ID: 65362 Summary: OpenACC compilation on Tegra K1 (ARM) Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: zziolko at clemson dot edu CC: jakub at gcc dot gnu.org Created attachment 34992 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34992&action=edit gfortran -v -save-temps -fopenacc abort-2.f90 output The GCC 5.0 snapshot gcc-5-20150301 builds successfully on Tegra K1 processor (Ubuntu 14.04 Linux on NVIDIA's Jetson TK1 platform). All attempts to compile c or fortran code with -fopenacc fail. For example code abort-2.f90 (from the testsuite): program main implicit none integer :: argc argc = command_argument_count () !$acc parallel copyin(argc) if (argc .ne. 0) then call abort end if !$acc end parallel end program main compiled using gfortran -fopenacc abort-2.f90 gives a message abort-2.f90: In function ‘MAIN__._omp_fn.0’: abort-2.f90:8:0: internal compiler error: in convert_memory_address_addr_space_1, at explow.c:292 if (argc .ne. 0) then ^ 0x1df1e1 convert_memory_address_addr_space_1 ../../gcc-5-20150301/gcc/explow.c:292 0x1df1e1 convert_memory_address_addr_space ../../gcc-5-20150301/gcc/explow.c:389 0x1df1e1 memory_address_addr_space(machine_mode, rtx_def*, unsigned char) ../../gcc-5-20150301/gcc/explow.c:403 0x1f1779 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) ../../gcc-5-20150301/gcc/expr.c:9904 0x1ef439 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) ../../gcc-5-20150301/gcc/expr.c:10171 0x1f8e83 store_expr_with_bounds(tree_node*, rtx_def*, int, bool, tree_node*) ../../gcc-5-20150301/gcc/expr.c:5385 0x1fe1a5 expand_assignment(tree_node*, tree_node*, bool) ../../gcc-5-20150301/gcc/expr.c:5154 0x1575e7 expand_gimple_stmt_1 ../../gcc-5-20150301/gcc/cfgexpand.c:3385 0x1575e7 expand_gimple_stmt ../../gcc-5-20150301/gcc/cfgexpand.c:3481 0x158e4b expand_gimple_basic_block ../../gcc-5-20150301/gcc/cfgexpand.c:5470 0x15a649 execute ../../gcc-5-20150301/gcc/cfgexpand.c:6088 Similar message for the rest of the fortran or c tests. Marcin
[Bug target/65121] [5 regression] long_call attribute broken weak symbol arm*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65121 Ramana Radhakrishnan changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Ramana Radhakrishnan --- https://gcc.gnu.org/ml/gcc-cvs/2015-03/msg00140.html should have fixed it. My auto-tester is down so I can't see the "fixed" testresults however https://gcc.gnu.org/ml/gcc-testresults/2015-03/msg00993.html shows it's fixed. Alex, please put PR numbers in your changelog and commit messages properly so that folks know when things are fixed up. regards Ramana
[Bug target/65121] [5 regression] long_call attribute broken weak symbol arm*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65121 --- Comment #5 from Ramana Radhakrishnan --- Author: ramana Date: Mon Mar 9 15:19:20 2015 New Revision: 221282 URL: https://gcc.gnu.org/viewcvs?rev=221282&root=gcc&view=rev Log: Fix PR number for 65121 in Changelog. PR target/65121 The commit that fixed this was https://gcc.gnu.org/ml/gcc-cvs/2015-03/msg00140.html Modified: trunk/gcc/ChangeLog
[Bug tree-optimization/44563] GCC uses a lot of RAM when compiling a large numbers of functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44563
--- Comment #17 from Richard Biener ---
(In reply to Richard Biener from comment #16)
> callgrind shows the cgraph_edge_hasher quite high in the profile (via
> redirect_all_calls). I suppose as the large main is a single BB walking
> all stmts over-and-over is quite bad. Also hash_pointer isn't inlined!?
> Ah - it's external in libiberty hashtab.c ... - it should transition to
> using/inheriting from pointer_hash.
>
> cgraph_edge *
> cgraph_node::get_edge (gimple call_stmt)
> {
> cgraph_edge *e, *e2;
> int n = 0;
>
> if (call_site_hash)
> return call_site_hash->find_with_hash (call_stmt,
>htab_hash_pointer (call_stmt));
>
Btw, for 1 calls (smaller testcase) we get 100 000 000 calls to
cgraph_edge::redirect_call_stmt_to_callee () (that's from 4
redirect_all_calls calls which is from 1 optimize_inline_calls calls).
Ah - we do this also for the ENTRY/EXIT block!
Index: gcc/tree-inline.c
===
--- gcc/tree-inline.c (revision 221278)
+++ gcc/tree-inline.c (working copy)
@@ -2802,11 +2802,13 @@ copy_cfg_body (copy_body_data * id, gcov
if (need_debug_cleanup
&& bb->index != ENTRY_BLOCK
&& bb->index != EXIT_BLOCK)
- maybe_move_debug_stmts_to_successors (id, (basic_block) bb->aux);
- /* Update call edge destinations. This can not be done before loop
- info is updated, because we may split basic blocks. */
- if (id->transform_call_graph_edges == CB_CGE_DUPLICATE)
- redirect_all_calls (id, (basic_block)bb->aux);
+ {
+ maybe_move_debug_stmts_to_successors (id, (basic_block) bb->aux);
+ /* Update call edge destinations. This can not be done before loop
+ info is updated, because we may split basic blocks. */
+ if (id->transform_call_graph_edges == CB_CGE_DUPLICATE)
+ redirect_all_calls (id, (basic_block)bb->aux);
+ }
((basic_block)bb->aux)->aux = NULL;
bb->aux = NULL;
}
makes sense?
> The estimate_calls_size_and_time portion is quite smaller.
>
> cleanup-cfgs main portion is split_bb_on_noreturn_calls.
[Bug lto/65361] [5 Regression] LTO: tree check: expected tree that contains ‘decl minimal’ structure, have ‘tree_binfo’ in add_type_duplicate, at ipa-devirt.c:1509
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65361 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Created attachment 34993 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34993&action=edit gcc5-pr65361.patch Untested fix. Now to create a smaller testcase.
[Bug tree-optimization/44563] GCC uses a lot of RAM when compiling a large numbers of functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44563
--- Comment #18 from Richard Biener ---
(In reply to Richard Biener from comment #17)
> (In reply to Richard Biener from comment #16)
> > callgrind shows the cgraph_edge_hasher quite high in the profile (via
> > redirect_all_calls). I suppose as the large main is a single BB walking
> > all stmts over-and-over is quite bad. Also hash_pointer isn't inlined!?
> > Ah - it's external in libiberty hashtab.c ... - it should transition to
> > using/inheriting from pointer_hash.
> >
> > cgraph_edge *
> > cgraph_node::get_edge (gimple call_stmt)
> > {
> > cgraph_edge *e, *e2;
> > int n = 0;
> >
> > if (call_site_hash)
> > return call_site_hash->find_with_hash (call_stmt,
> >htab_hash_pointer (call_stmt));
> >
>
> Btw, for 1 calls (smaller testcase) we get 100 000 000 calls to
> cgraph_edge::redirect_call_stmt_to_callee () (that's from 4
> redirect_all_calls calls which is from 1 optimize_inline_calls calls).
>
> Ah - we do this also for the ENTRY/EXIT block!
>
> Index: gcc/tree-inline.c
> ===
> --- gcc/tree-inline.c (revision 221278)
> +++ gcc/tree-inline.c (working copy)
> @@ -2802,11 +2802,13 @@ copy_cfg_body (copy_body_data * id, gcov
> if (need_debug_cleanup
> && bb->index != ENTRY_BLOCK
> && bb->index != EXIT_BLOCK)
> - maybe_move_debug_stmts_to_successors (id, (basic_block) bb->aux);
> - /* Update call edge destinations. This can not be done before loop
> - info is updated, because we may split basic blocks. */
> - if (id->transform_call_graph_edges == CB_CGE_DUPLICATE)
> - redirect_all_calls (id, (basic_block)bb->aux);
> + {
> + maybe_move_debug_stmts_to_successors (id, (basic_block) bb->aux);
> + /* Update call edge destinations. This can not be done before
> loop
> + info is updated, because we may split basic blocks. */
> + if (id->transform_call_graph_edges == CB_CGE_DUPLICATE)
> + redirect_all_calls (id, (basic_block)bb->aux);
> + }
> ((basic_block)bb->aux)->aux = NULL;
> bb->aux = NULL;
>}
>
> makes sense?
Fails to bootstrap :/ But would improve the testcase to only have the
inline heuristic issue.
/space/rguenther/src/svn/trunk/libstdc++-v3/libsupc++/pbase_type_info.cc: In
member function ‘virtual bool __cxxabiv1::__pbase_type_info::__do_catch(const
std::type_info*, void**, unsigned int) const’:
/space/rguenther/src/svn/trunk/libstdc++-v3/libsupc++/pbase_type_info.cc:32:6:
error: reference to dead statement
bool __pbase_type_info::
^
# .MEM = VDEF <.MEM>
_30 = OBJ_TYPE_REF(_28;(const struct __pbase_type_info)this_3(D)->6)
(this_3(D), thr_type_5(D), thr_obj_9(D), outer_29);
_ZNK10__cxxabiv117__pbase_type_info10__do_catchEPKSt9type_infoPPvj/74 (virtual
bool __cxxabiv1::__pbase_type_info::__do_catch(const std::type_info*, void**,
unsigned int) const) @0x2c8d3ab8
Type: function definition analyzed
Visibility: externally_visible public visibility_specified virtual
Address is taken.
References: _ZNK10__cxxabiv117__pbase_type_info15__pointer_catchEPKS0_PPvj/34
(addr) (speculative)
Referring: _ZTVN10__cxxabiv117__pbase_type_infoE/77 (addr)
Availability: overwritable
First run: 0
Function flags: body
Called by:
Calls: strcmp/85 (0.39 per call) __cxa_bad_typeid/83 (can throw external)
strcmp/85 (0.61 per call)
Indirect call(0.11 per call) (can throw external)
Polymorphic indirect call of type const struct __pbase_type_info
token:6(speculative) (0.03 per call) (can throw external) of param:0
Outer type (dynamic):struct __pbase_type_info (or a derived type) offset 0
/space/rguenther/src/svn/trunk/libstdc++-v3/libsupc++/pbase_type_info.cc:32:6:
internal compiler error: verify_cgraph_node failed
0xa8eebc cgraph_node::verify_node()
/space/rguenther/src/svn/trunk/gcc/cgraph.c:3115
0xa8473f symtab_node::verify()
/space/rguenther/src/svn/trunk/gcc/symtab.c:1103
0x1025861 optimize_inline_calls(tree_node*)
/space/rguenther/src/svn/trunk/gcc/tree-inline.c:4938
> > The estimate_calls_size_and_time portion is quite smaller.
> >
> > cleanup-cfgs main portion is split_bb_on_noreturn_calls.
[Bug debug/53927] wrong value for DW_AT_static_link
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53927
--- Comment #21 from Pierre-Marie de Rodat ---
(In reply to Eric Botcazou from comment #18)
> I think this is worth investigating though because it's conceptually
> much simpler than adding yet another indirection. And we should
> concentrate on -O0 (and -Og), we don't really care about what happens
> with aggressive optimization.
Understood and agreed. Nevertheless...
> I guess the question is: can we arrange to have a constant offset
> between the frame base and the FRAME object, "constant" meaning valid
> for every function but possibly target-dependent?
I started to hack into cfgexpand.c and dwarf2out.c, but I realized this
is not possible in the general case. Consider the following example:
#include
int
nestee (void)
{
int a __attribute__((aligned(64))) = 1234;
void
nested (int b)
{
a = b;
}
nested (2345);
return a;
}
int
call_nestee (int n)
{
int *v = alloca (sizeof (int) * n);
v[0] = nestee ();
return v[0];
}
int
main (void)
{
call_nestee (1);
call_nestee (8);
return 0;
}
With a GCC 5.0 built from fairly recent sources, I get the following CFA
information:
0090 002c 0064 FDE cie=0030
pc=004004ac..004004eb
DW_CFA_advance_loc: 5 to 004004b1
DW_CFA_def_cfa: r10 (r10) ofs 0
DW_CFA_advance_loc: 9 to 004004ba
DW_CFA_expression: r6 (rbp) (DW_OP_breg6 (rbp): 0)
DW_CFA_advance_loc: 5 to 004004bf
DW_CFA_def_cfa_expression (DW_OP_breg6 (rbp): -8; DW_OP_deref)
DW_CFA_advance_loc: 38 to 004004e5
And now here is what I get under GDB:
$ gdb -n -q -ex 'b nestee' ./dyn_frame
Reading symbols from ./dyn_frame...done.
Breakpoint 1 at 0x4004c3: file dyn_frame.c, line 6.
(gdb) r
[...]
Breakpoint 1, nestee () at dyn_frame.c:6
6 int a __attribute__((aligned(64))) = 1234;
(gdb) p $pc
$1 = (void (*)()) 0x4004c3
(gdb) x/1xg $rbp - 8
0x7fffdf28: 0x7fffdf60
(gdb) p/x (char *) 0x7fffdf60 - (char *) &a
$2 = 0xa0
... so for this frame, the CFA and the FRAME object are 0xa0 bytes from
each other. Now let's resume to see the next "nestee" frame:
(gdb) c
Continuing.
Breakpoint 1, nestee () at dyn_frame.c:6
6 int a __attribute__((aligned(64))) = 1234;
(gdb) p $pc
$3 = (void (*)()) 0x4004c3
(gdb) x/1xg $rbp - 8
0x7fffdf28: 0x7fffdf50
(gdb) p/x (char *) 0x7fffdf50 - (char *) &a
$4 = 0x90
The offset between the CFA and e FRAME object is now 0x90 bytes. So
because of alignment constraints, I think we cannot assume we can have a
constant offset (even function-dependent).
This offset is dynamic and the only way to compute it is to use the
frame's context: here, nestee's saved registers, which we don't have
access to in DWARF when computing the static link attribute.
[Bug debug/53927] wrong value for DW_AT_static_link
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53927 --- Comment #22 from Pierre-Marie de Rodat --- (In reply to Tom Tromey from comment #20) >> Yeah. There wasn't much point submitting it when it wouldn't work anyhow :} >> Also see the README.archer file. It explains some changes that are needed. >> Also I remember thinking that the dwarf "locexpr baton" changes needed >> some update, but I no longer recall what. > > I see now that I recorded my thoughts in the commit messages. > Yay me! Great, thank you for this!
[Bug lto/65361] [5 Regression] LTO: tree check: expected tree that contains ‘decl minimal’ structure, have ‘tree_binfo’ in add_type_duplicate, at ipa-devirt.c:1509
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65361
--- Comment #4 from Jakub Jelinek ---
--- gcc/testsuite/g++.dg/lto/pr65361_0.C.jj2015-03-09 16:43:42.720534781
+0100
+++ gcc/testsuite/g++.dg/lto/pr65361_0.C2015-03-09 16:47:00.325356410 +0100
@@ -0,0 +1,6 @@
+// { dg-lto-do link { xfail } }
+// { dg-lto-options { { -flto -O2 } } }
+// { dg-extra-ld-options "-r -nostdlib -O2" }
+
+struct A { A () {} virtual ~A () {} };
+A a;
--- gcc/testsuite/g++.dg/lto/pr65361_1.C.jj2015-03-09 16:43:45.981482330
+0100
+++ gcc/testsuite/g++.dg/lto/pr65361_1.C2015-03-09 16:39:00.0 +0100
@@ -0,0 +1,3 @@
+struct B {};
+struct A : public B { A () {} virtual ~A () {} };
+A b;
reproduces this, but unfortunately lto.exp doesn't support link failures, nor
error messages out of lto1 during the linking. So I'm afraid we need to live
without a testcase for now.
BTW, I see several spots with __attribute__((visibility ("default"))) on std
namespace in g++.dg/lto/, bet that is undesirable if some target would support
LTO, but not visibilities.
[Bug target/65341] [5 Regression] glibc build failure on ppc64le: setcontext.S:367: Error: junk at end of line: `1,0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65341 --- Comment #16 from Michael Meissner --- As I can see there are several issues/whatever. 1) Each of the _ARCH_PWR is cumulative, so if you say -mcpu=power8 for instance, it defines _ARCH_PWR4, _ARCH_PWR5, _ARCH_PWR5X, _ARCH_PWR6, _ARCH_PWR7, and _ARCH_PWR8. Note, it does not define _ARCH_PWR6X, since those instructions only exist in the power6x, and are not in later versions of the power hardware. 2) If you had used a compiler that was configured using the --with-cpu=power8 option, it would have shown the same results, since _ARCH_PWR6 would have been defined. It was only if you use a compiler that was not configured using --with-cpu=, would the code be assembled using the older form of the asm insns. I believe each of the 3 distributions use some form of --with-cpu= in building their compiler. 3) Given that ISA 2.07 (i.e. power8) is officially the minimum baseline for 64-bit PowerPC little endian, perhaps the assembler should be modified to default to power8. Obviously if this change is desired, you need to raise it on the appropriate binutils forums. 4) Using .machine altivec as you've discovered is the wrong value for PowerPC 64 Little Endian Linux. It was the right value back in the days of the Apple G5, but it is not right for the current PowerPC 64LE environment.
[Bug target/65242] [5 Regression] ICE (in gen_add2_insn, at optabs.c:4761) on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65242 --- Comment #8 from Michael Meissner --- I'm going to start looking at this. I suspect the issue is we need more checks about the offset in TOC references. In particular, the 64-bit GPR load/store instruction (ld, std), the sign-extended 32-bit load (lwa), and 128-bit load/store (lq, stq) are B-form instructions instead of D-form, meaning that the bottom 2 bits of the offset are required to be zero, and the encoding uses these bits for other purposes.
[Bug lto/65361] [5 Regression] LTO: tree check: expected tree that contains ‘decl minimal’ structure, have ‘tree_binfo’ in add_type_duplicate, at ipa-devirt.c:1509
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65361 --- Comment #5 from Tobias Burnus --- (In reply to Jakub Jelinek from comment #3) > Untested fix Thanks! It looks good for the the original two unreduced files. Also, I have finally been able again to compile the full code (at least with some option variants). For another variant, I still get an ICE (in add_symbol_to_partition_1, at lto/lto-partition.c:158) after 64min of compiling, which I will try to reduce now.
[Bug c/65345] ICE with _Generic selection on _Atomic int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65345
--- Comment #4 from joseph at codesourcery dot com ---
Or e.g.
_Atomic int i = 5;
int j = sizeof (i + 1);
which is valid code not involving _Generic. And, similarly:
_Atomic int i = 5;
int j = sizeof (i = 0);
or
_Atomic int i = 5;
int j = sizeof (++i);
or
_Atomic int i = 5;
int j = sizeof (i--);
This at first suggests (but see below) that the special-case handling of
atomics on lvalue-to-rvalue conversion, and on assignment / increment /
decrement / any other cases where creation of temporaries is involved,
should be disabled when at file scope - either the expression in question
is in a context such as sizeof or _Generic where its side effects do not
occur so the special handling is not needed, or an error will occur for
the expression being non-constant even without the special handling.
Much the same applies at function prototype scope, e.g.:
_Atomic int i = 5;
void f (int a[i + 1]);
(where [i + 1] means the same as [*]). But in the case of
_Atomic int i = 5;
void f (int a[i = 1]) {}
you have a valid program, where the atomic assignment must be executed on
function entry (see the pending_sizes handling in c-decl.c). So to handle
such cases, maybe the special handling of atomics needs to be partly
deferred, so that parsing "i = 1" generates some tree for atomic
assignment and the temporaries only get added at gimplification time.
[Bug tree-optimization/65363] New: trivial redundant code reordering makes code less optimal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65363
Bug ID: 65363
Summary: trivial redundant code reordering makes code less
optimal
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Consider this test-case test.c (based on PR65270 comment 27/28):
...
#define N 10
struct a
{
int a[N];
};
typedef struct a misaligned_t __attribute__ ((aligned (8)));
typedef struct a aligned_t __attribute__ ((aligned (32)));
static void
__attribute__ ((noinline))
__attribute__ ((noclone))
__attribute__ ((used))
t (void *a, aligned_t *d)
{
int v, v2;
int i;
for (i=0; i < N; i++)
{
#if REORDER
v2 = ((misaligned_t *)a)->a[i];
v = ((aligned_t *)a)->a[i];
#else
v = ((aligned_t *)a)->a[i];
v2 = ((misaligned_t *)a)->a[i];
#endif
d->a[i] += v + v2;
}
}
aligned_t aa;
aligned_t d;
int
main (void)
{
t (&aa, &d);
return 0;
}
...
Changing the order of loads in the loop body results in different instructions
(and I assume the unaligned one (movdqu) is more expensive than the aligned one
(movdqa)):
...
$ n=0; gcc -O2 -ftree-vectorize test.c -DREORDER=$n -S -o $n
$ n=1; gcc -O2 -ftree-vectorize test.c -DREORDER=$n -S -o $n
$ diff -u 0 1
--- 02015-03-09 15:46:41.395919753 +0100
+++ 12015-03-09 15:46:43.747919840 +0100
@@ -19,7 +19,7 @@
.p2align 4,,10
.p2align 3
.L4:
-movdqa(%rdi,%rax), %xmm0
+movdqu(%rdi,%rax), %xmm0
paddd%xmm0, %xmm0
paddd(%rsi,%rax), %xmm0
movaps%xmm0, (%rsi,%rax)
...
The two loads are redundant, and fre is the pass that picks the first one and
eliminates the second one. I'm not sure though whether you want to fix this
particular example in fre. Perhaps you want to propagate alignment before doing
fre.
OTOH, fre does not take the cost of the value producing statements into account
when determining which to choose as representative and which to eliminate.
[Bug target/65341] [5 Regression] glibc build failure on ppc64le: setcontext.S:367: Error: junk at end of line: `1,0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65341 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #17 from Markus Trippelsdorf --- OK, I will use --with-cpu=power8 in the future.
[Bug c/65345] ICE with _Generic selection on _Atomic int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65345
--- Comment #5 from Marek Polacek ---
(In reply to jos...@codesourcery.com from comment #4)
> Or e.g.
>
> _Atomic int i = 5;
> int j = sizeof (i + 1);
>
> which is valid code not involving _Generic. And, similarly:
>
> _Atomic int i = 5;
> int j = sizeof (i = 0);
>
> or
>
> _Atomic int i = 5;
> int j = sizeof (++i);
>
> or
>
> _Atomic int i = 5;
> int j = sizeof (i--);
>
> This at first suggests (but see below) that the special-case handling of
> atomics on lvalue-to-rvalue conversion, and on assignment / increment /
> decrement / any other cases where creation of temporaries is involved,
> should be disabled when at file scope - either the expression in question
> is in a context such as sizeof or _Generic where its side effects do not
> occur so the special handling is not needed, or an error will occur for
> the expression being non-constant even without the special handling.
Yeah, I had an idea of using create_tmp_var_raw that doesn't push the variable
into function's local vars vector. My thinking was that we don't need such
variables to survive into ME anyway in the valid cases, and in invalid cases,
the FE just rejects the code...
--- gcc/c/c-typeck.c
+++ gcc/c/c-typeck.c
@@ -2039,7 +2039,12 @@ convert_lvalue_to_rvalue (location_t loc, struct c_expr
exp,
/* Remove the qualifiers for the rest of the expressions and
create the VAL temp variable to hold the RHS. */
nonatomic_type = build_qualified_type (expr_type, TYPE_UNQUALIFIED);
- tmp = create_tmp_var (nonatomic_type);
+ /* If we are outside a function, avoid pushing the variable into the
+current binding. */
+ if (current_function_decl)
+tmp = create_tmp_var (nonatomic_type);
+ else
+tmp = create_tmp_var_raw (nonatomic_type);
tmp_addr = build_unary_op (loc, ADDR_EXPR, tmp, 0);
TREE_ADDRESSABLE (tmp) = 1;
TREE_NO_WARNING (tmp) = 1;
> Much the same applies at function prototype scope, e.g.:
>
> _Atomic int i = 5;
> void f (int a[i + 1]);
>
> (where [i + 1] means the same as [*]). But in the case of
>
> _Atomic int i = 5;
> void f (int a[i = 1]) {}
>
> you have a valid program, where the atomic assignment must be executed on
> function entry (see the pending_sizes handling in c-decl.c). So to handle
> such cases, maybe the special handling of atomics needs to be partly
> deferred, so that parsing "i = 1" generates some tree for atomic
> assignment and the temporaries only get added at gimplification time.
... but my patch wouldn't handle this case. Oh well.
[Bug c/65345] ICE with _Generic selection on _Atomic int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65345
--- Comment #6 from Marek Polacek ---
FWIW, my testcase was
/* PR c/65345 */
/* { dg-do compile } */
/* { dg-options "" } */
_Atomic int i = 3;
int g1 = sizeof (i + 1) + sizeof (-i);
int g2 = __builtin_constant_p (i + 1);
int g3 = 0 && i;
int g4 = 0 || i; /* { dg-error "initializer element is not constant" } */
int g5 = i; /* { dg-error "initializer element is not constant" } */
int g6[i]; /* { dg-error "variably modified" } */
int g7 = (i ? 1 : 2); /* { dg-error "initializer element is not constant" } */
int g8 = _Alignof (-i);
_Atomic long g10 = i; /* { dg-error "initializer element is not constant" } */
_Static_assert (_Generic (i, int: 1, default: 0) == 1, "");
_Static_assert (_Generic (i + 1, int: 1, default: 0) == 1, "");
void
foo (void)
{
static int q1 = sizeof (i + 1) + sizeof (-i);
static int q2 = __builtin_constant_p (i + 1);
static int q3 = 0 && i;
static int q4 = 0 || i; /* { dg-error "initializer element is not constant" }
*/
static int q5 = i; /* { dg-error "initializer element is not constant" } */
static int q6[i]; /* { dg-error "storage size" } */
static int q7 = (i ? 1 : 2); /* { dg-error "initializer element is not
constant" } */
static int q8 = _Alignof (-i);
}
[Bug rtl-optimization/64317] [5 Regression] Ineffective allocation of PIC base register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64317 --- Comment #23 from Jeffrey A. Law --- So with a functional prototype in place, I can get good code for this test. However, deeper testing of that prototype is proving difficult simply because the postreload-gcse.c code very rarely does anything useful, at least on x86 or x86-64. I put in some dumping in gcse_after_reload_main to always dump its statistics if its expression table has > 0 elements. Believe it or not, this *never* triggers during a bootstrap on x86_64. I was so amazed by this I fired up a VM and bootstraped i686 as well, nope, never fires there either. Concerned that maybe my other changes were somehow getting in the way, I put in just the dumping code, still doesn't fire. Yet it fires semi regularly in the testsuite. The original author of the code in postreload-gcse.c was doing their development on PPC boxes, so I'm going to grab one and see if I can get some useful testing from on it.
[Bug testsuite/65364] New: FAIL: gcc.dg/uninit-19.c (test for warnings, line 22)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65364
Bug ID: 65364
Summary: FAIL: gcc.dg/uninit-19.c (test for warnings, line 22)
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: danglin at gcc dot gnu.org
On hppa64-hp-hpux11.11 and other PIC targets, the expected warning
does not occur at the expected line number. I believe the test
was already adjusted once.
spawn /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/test/gnu/gcc/gc
c/gcc/testsuite/gcc.dg/uninit-19.c -fno-diagnostics-show-caret
-fdiagnostics-col
or=never -O -Wuninitialized -S -o uninit-19.s
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/uninit-19.c: In function 'fn2':
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/uninit-19.c:13:15: warning: 'n' may be
us
ed uninitialized in this function [-Wmaybe-uninitialized]
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/uninit-19.c:19:10: note: 'n' was
declared
here
output is:
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/uninit-19.c: In function 'fn2':
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/uninit-19.c:13:15: warning: 'n' may be
us
ed uninitialized in this function [-Wmaybe-uninitialized]
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/uninit-19.c:19:10: note: 'n' was
declared
here
FAIL: gcc.dg/uninit-19.c (test for warnings, line 22)
FAIL: gcc.dg/uninit-19.c (test for excess errors)
Excess errors:
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/uninit-19.c:13:15: warning: 'n' may be
us
ed uninitialized in this function [-Wmaybe-uninitialized]
/* { dg-warning "may be used uninitialized" "" { target nonpic } 13 } */^M
/* { dg-warning "may be used uninitialized" "" { target { ! nonpic } } 22 }
*/^M
The hppa64-hp-hpux11.11 target is always PIC and the warning occurs at line 13.
[Bug target/65222] [5 Regression] -mtune= or -march=: Not all options not documented: slm, knl, shanghai, istanbul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65222 Jakub Jelinek changed: What|Removed |Added CC||hjl.tools at gmail dot com, ||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- istanbul and shanghai don't seem to be valid -march=/-mtune= options. My understanding was that atom, core-avx2, core-avx-i, corei7, corei7-avx, slm are deprecated aliases (thus intentionally not documented) of bonell, haswell, ivybridge, nehalem, sandybridge, silvermont. Beyond that, knl is indeed not documented (should be fixed) and x86-64 (dunno).
[Bug testsuite/65364] FAIL: gcc.dg/uninit-19.c (test for warnings, line 22)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65364 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-09 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed on darwin.
[Bug testsuite/65364] FAIL: gcc.dg/uninit-19.c (test for warnings, line 22)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65364 --- Comment #2 from Dominique d'Humieres --- See https://gcc.gnu.org/ml/gcc-patches/2015-02/msg00557.html for a patch and https://gcc.gnu.org/ml/gcc-patches/2015-02/msg00737.html for some analysis for darwin.
[Bug sanitizer/63958] [5 Regression] bootstrap failure in the sanitizer libs on sparc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63958 --- Comment #11 from Jakub Jelinek --- Author: jakub Date: Mon Mar 9 18:25:28 2015 New Revision: 221283 URL: https://gcc.gnu.org/viewcvs?rev=221283&root=gcc&view=rev Log: PR sanitizer/63958 Reapply: 2014-10-14 David S. Miller * sanitizer_common/sanitizer_platform_limits_linux.cc (time_t): Define at __kernel_time_t, as needed for sparc. (struct __old_kernel_stat): Don't check if __sparc__ is defined. * libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h (__sanitizer): Define struct___old_kernel_stat_sz, struct_kernel_stat_sz, and struct_kernel_stat64_sz for sparc. (__sanitizer_ipc_perm): Adjust for sparc targets. (__sanitizer_shmid_ds): Likewsie. (__sanitizer_sigaction): Likewise. (IOC_SIZE): Likewsie. Modified: trunk/libsanitizer/ChangeLog trunk/libsanitizer/sanitizer_common/sanitizer_platform_limits_linux.cc trunk/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
[Bug c/65120] [5 Regression] Wlogical-not-parentheses should not warn about double exclamation !!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65120 --- Comment #11 from Jakub Jelinek --- Author: jakub Date: Mon Mar 9 18:26:52 2015 New Revision: 221284 URL: https://gcc.gnu.org/viewcvs?rev=221284&root=gcc&view=rev Log: PR c/65120 * c-typeck.c (parser_build_binary_op): Don't warn for !!x == y or !b == y where b is _Bool. * parser.c (cp_parser_binary_expression): Don't warn for !!x == y or !b == y where b is bool. * c-c++-common/pr49706.c: Adjust tests for not warning about !!x == y or !b == y where b is boolean, and add some further tests. * c-c++-common/pr62199-2.c: Likewise. Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-typeck.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/pr49706.c trunk/gcc/testsuite/c-c++-common/pr62199-2.c
[Bug fortran/60780] Equivalence statements in nested modules results in fast growing duplicate statements in module files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60780 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #6 from Jerry DeLisle --- The patch for 40958 is simple enough that we may be able to just commit it to trunk. Fortran is not release critical. With the patch do we have any problems with known large code bases like CP2K? Is 40958 a duplicate of this PR or is there something else lurking?
[Bug fortran/60780] Equivalence statements in nested modules results in fast growing duplicate statements in module files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60780 --- Comment #7 from Dominique d'Humieres --- > Is 40958 a duplicate of this PR or is there something else lurking? AFAIU pr40958 comment 13, Janne was anticipating possible exponential behaviors from a rather theoretical point of view. This PR is an instance of such exponential behavior. IMO pr40958 should be closed and new PRs for exponential behavior opened when new instances are found.
[Bug sanitizer/63958] [5 Regression] bootstrap failure in the sanitizer libs on sparc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63958 --- Comment #12 from Jakub Jelinek --- Fixed for GCC 5 now, but the problem will likely reappear during next merge :(.
[Bug sanitizer/63958] [5 Regression] bootstrap failure in the sanitizer libs on sparc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63958 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #13 from Jakub Jelinek --- .
[Bug testsuite/65364] FAIL: gcc.dg/uninit-19.c (test for warnings, line 22)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65364 --- Comment #3 from dave.anglin at bell dot net --- On 2015-03-09 2:08 PM, dominiq at lps dot ens.fr wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65364 > > --- Comment #2 from Dominique d'Humieres --- > See https://gcc.gnu.org/ml/gcc-patches/2015-02/msg00557.html for a patch and > https://gcc.gnu.org/ml/gcc-patches/2015-02/msg00737.html for some analysis for > darwin. > hppa64-hp-hpux* uses the default binding heuristics. Maybe the nonpic test doesn't really determine on which line the warning occurs. Dave
[Bug c++/65339] [5 Regression] C++ ICE with lambda and no capture list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65339 --- Comment #2 from Jason Merrill --- Author: jason Date: Mon Mar 9 19:59:54 2015 New Revision: 221285 URL: https://gcc.gnu.org/viewcvs?rev=221285&root=gcc&view=rev Log: PR c++/65339 * call.c: Don't call maybe_resolve_dummy when calling a constructor. Added: trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-conv9.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c
[Bug lto/65361] [5 Regression] LTO: tree check: expected tree that contains ‘decl minimal’ structure, have ‘tree_binfo’ in add_type_duplicate, at ipa-devirt.c:1509
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65361 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Jakub Jelinek --- Fixed.
[Bug lto/65361] [5 Regression] LTO: tree check: expected tree that contains ‘decl minimal’ structure, have ‘tree_binfo’ in add_type_duplicate, at ipa-devirt.c:1509
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65361 --- Comment #6 from Jakub Jelinek --- Author: jakub Date: Mon Mar 9 20:19:34 2015 New Revision: 221286 URL: https://gcc.gnu.org/viewcvs?rev=221286&root=gcc&view=rev Log: PR lto/65361 * ipa-devirt.c (add_type_duplicate): Don't use DECL_CONTEXT on a TREE_BINFO, instead use BINFO_TYPE. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-devirt.c
[Bug c++/65339] [5 Regression] C++ ICE with lambda and no capture list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65339 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Jakub Jelinek --- Fixed.
