[Bug fortran/54463] -fdefault-real-8 does not promote the BLAS call when using -fexternal-blas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54463 --- Comment #7 from Tobias Burnus 2012-09-06 07:03:49 UTC --- Author: burnus Date: Thu Sep 6 07:03:42 2012 New Revision: 191012 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191012 Log: 2012-09-06 Tobias Burnus PR fortran/54463 * trans-intrinsic.c (gfc_conv_intrinsic_funcall): Fix matmul call to BLAS if the default-kind has been promoted. 2012-09-06 Tobias Burnus PR fortran/54463 * gfortran.dg/promotion_2.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/promotion_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/54463] -fdefault-real-8 does not promote the BLAS call when using -fexternal-blas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54463 Tobias Burnus changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #8 from Tobias Burnus 2012-09-06 07:12:15 UTC --- FIXED on the 4.8 trunk. Thanks for the report Simon!
[Bug fortran/54467] [4.8 Regression] f951: internal compiler error: in gfc_add_component_ref, at fortran/class.c:213
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54467 Tobias Burnus changed: What|Removed |Added Status|NEW |RESOLVED CC||burnus at gcc dot gnu.org Resolution||FIXED --- Comment #4 from Tobias Burnus 2012-09-06 07:14:22 UTC --- FIXED - sorry for the breakage and thanks for the report!
[Bug rtl-optimization/54455] [4.7/4.8 Regression] ICE: RTL check: expected elt 3 type 'B', have '0' (rtx barrier) in compute_bb_for_insn, at cfgrtl.c:418
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54455 --- Comment #14 from Jakub Jelinek 2012-09-06 07:29:24 UTC --- Author: jakub Date: Thu Sep 6 07:29:12 2012 New Revision: 191013 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191013 Log: PR rtl-optimization/54455 * sel-sched-ir.c (maybe_tidy_empty_bb): Give up if previous fallthru bb ends up with asm goto referencing bb's label. * gcc.dg/54455.c: New test. Added: trunk/gcc/testsuite/gcc.dg/54455.c Modified: trunk/gcc/ChangeLog trunk/gcc/fortran/ChangeLog trunk/gcc/sel-sched-ir.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/54455] [4.7 Regression] ICE: RTL check: expected elt 3 type 'B', have '0' (rtx barrier) in compute_bb_for_insn, at cfgrtl.c:418
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54455 Jakub Jelinek changed: What|Removed |Added Known to work||4.8.0 Summary|[4.7/4.8 Regression] ICE: |[4.7 Regression] ICE: RTL |RTL check: expected elt 3 |check: expected elt 3 type |type 'B', have '0' (rtx |'B', have '0' (rtx barrier) |barrier) in |in compute_bb_for_insn, at |compute_bb_for_insn, at |cfgrtl.c:418 |cfgrtl.c:418| Known to fail|4.8.0 | --- Comment #15 from Jakub Jelinek 2012-09-06 07:36:05 UTC --- Fixed on the trunk so far.
[Bug tree-optimization/54494] [4.7/4.8 Regression] Missing store to volatile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54494 --- Comment #5 from Andrew Pinski 2012-09-06 08:08:21 UTC --- Author: pinskia Date: Thu Sep 6 08:08:09 2012 New Revision: 191014 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191014 Log: 2012-09-06 Andrew Pinski PR tree-opt/54494 * tree-inline.c (remap_gimple_op_r): Copy TREE_SIDE_EFFECTS also. 2012-09-06 Andrew Pinski PR tree-opt/54494 * gcc.dg/tree-ssa/strlen-1.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/strlen-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-inline.c
[Bug tree-optimization/54494] [4.7 Regression] Missing store to volatile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54494 Andrew Pinski changed: What|Removed |Added Known to work||4.8.0 Summary|[4.7/4.8 Regression]|[4.7 Regression] Missing |Missing store to volatile |store to volatile Known to fail|4.8.0 | --- Comment #5 from Andrew Pinski 2012-09-06 08:08:21 UTC --- Author: pinskia Date: Thu Sep 6 08:08:09 2012 New Revision: 191014 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191014 Log: 2012-09-06 Andrew Pinski PR tree-opt/54494 * tree-inline.c (remap_gimple_op_r): Copy TREE_SIDE_EFFECTS also. 2012-09-06 Andrew Pinski PR tree-opt/54494 * gcc.dg/tree-ssa/strlen-1.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/strlen-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-inline.c --- Comment #6 from Andrew Pinski 2012-09-06 08:09:13 UTC --- Fixed on the trunk so far.
[Bug tree-optimization/54494] [4.7 Regression] Missing store to volatile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54494 Andrew Pinski changed: What|Removed |Added Known to work||4.8.0 Summary|[4.7/4.8 Regression]|[4.7 Regression] Missing |Missing store to volatile |store to volatile Known to fail|4.8.0 | --- Comment #6 from Andrew Pinski 2012-09-06 08:09:13 UTC --- Fixed on the trunk so far.
[Bug c/54500] New: While(TRUE) loop optimization of global struct variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54500
Bug #: 54500
Summary: While(TRUE) loop optimization of global struct
variables
Classification: Unclassified
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: t...@email.cz
Target: avr-*
Build: WinAVR 20081205
I have large global static structure with substructers, longs etc.
struct {
longs ...
structs ...
struct {
boolean isEnd;
} ss;
etc.
} gs;
void procedure() {
while(true) {
if (gs.ss.isEnd) {
if (an_cond1) {
break;
}
}
if (an_cond2) {
break;
}
do_access_and_modify_gs_fields;
gs.ss.isEnd = TRUE;
do_access_and_modify_gs_fields;
}
if (gs.ss.IsEnd) {
}
when used in "neverending" while with breaks then gcc fails to optimize
correctly changed fields of global structure. Gcc tries to cache field used in
loop into registers and when no more registers on the stack (what is benefit
of copying vars from global variable onto stack ???). Changed values are
flushed back into global variable when loop terminates. There are several
breaks how to exit the loop. Suprisingly every loop has "copy&pasted" the same
exit code (why don't reuse one to save some memory ??). Respectively they
should be at least equal but in my case one of them did not flush back one
field (gs.isEnd after loop get unupdated value). I tried somehow persuade gcc
to know that isEnd is really modified by asm inline code. Sucessfully but any
change of code may change optimization and it appears again in another form.
Currently is problem that "gs.isEnd = TRUE;" updates optimized value in
register but "if (gs.ss.isEnd)" in loop check again global memory.
Seems gcc is totally confused with this construction. I hope setting struct as
volatile should help.
avr-g++ -MM -mmcu=atmega2560 -g -Os -Wall -Wextra -w -ffunct
ion-sections -fdata-sections -fno-exceptions my.cpp -MF my.d -MT my.o
[Bug testsuite/54184] [4.8 Regression] gcc.dg/pr52558-1.c failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54184 --- Comment #7 from rguenther at suse dot de 2012-09-06 08:53:36 UTC --- On Wed, 5 Sep 2012, aldyh at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54184 > > Aldy Hernandez changed: > >What|Removed |Added > > AssignedTo|unassigned at gcc dot |aldyh at gcc dot gnu.org >|gnu.org | > > --- Comment #5 from Aldy Hernandez 2012-09-05 > 21:15:52 UTC --- > What I was trying to test here originally was whether the LIM pass kept a flag > of changes to "count" and only if the flag was true, allow the cached version > of "count" to be stored. > > Technically, I could get away with only checking the presence of > count_lsm_flag > in the dump, though I realize that this also is an imperfect solution if a > previous pass changed things around. > > Apart from checking count_lsm_flag, the only thing I can think of is replacing > this test with one within the simulate-thread/ infrastructure that actually > checks that no caching occurs unless p->data > 0. Yes, that sounds like the proper solution. > Richard, which solution do you prefer, or do you recommend something else? Another way would be to make LIM emit something in the dump when it did a "conditional" hoisting as opposed to an un-conditional one and check that for the testcases the hoisting occurs but only conditional. Richard.
[Bug fortran/54405] bad debugging info which lead to a wrong behavior of reverse-next in gdb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54405 Jan Kratochvil changed: What|Removed |Added CC||jan.kratochvil at redhat ||dot com --- Comment #2 from Jan Kratochvil 2012-09-06 09:01:25 UTC --- This is a GDB only reverse-execution bug, filed now as: http://sourceware.org/bugzilla/show_bug.cgi?id=14548
[Bug fortran/54405] bad debugging info which lead to a wrong behavior of reverse-next in gdb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54405 --- Comment #3 from Jan Kratochvil 2012-09-06 09:05:23 UTC --- It happened because gfortran >= 4.6 uses this function and GDB cannot reverse-step-over such jmp-only function. (gdb) disass _gfortran_transfer_real_write Dump of assembler code for function _gfortran_transfer_real_write: 0x77b9f930 <+0>:jmpq 0x77ae0a30 <_gfortran_transfer_real@plt> End of assembler dump.
[Bug libstdc++/54376] incorrect complaint about redefinition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54376 --- Comment #17 from paolo at gcc dot gnu.org 2012-09-06 09:27:20 UTC --- Author: paolo Date: Thu Sep 6 09:27:10 2012 New Revision: 191016 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191016 Log: 2012-08-26 Marc Glisse Paolo Carlini PR libstdc++/54376 * include/bits/random.h (lognormal_distribution<>::operator==, gamma_distribution<>::operator==, chi_squared_distribution<>::operator==, fisher_f_distribution<>::operator==, student_t_distribution<>::operator==, binomial_distribution<>::operator==, negative_binomial_distribution<>::operator==, poisson_distribution<>::operator==): Change inline friend definition to non-template. * testsuite/26_numerics/random/binomial_distribution/requirements/ explicit_instantiation/1.cc: New. * testsuite/26_numerics/random/cauchy_distribution/requirements/ explicit_instantiation/1.cc: Likewise. * testsuite/26_numerics/random/chi_squared_distribution/ requirements/explicit_instantiation/1.cc: Likewise. * testsuite/26_numerics/random/discrete_distribution/requirements/ explicit_instantiation/1.cc: Likewise. * testsuite/26_numerics/random/exponential_distribution/ requirements/explicit_instantiation/1.cc: Likewise. * testsuite/26_numerics/random/extreme_value_distribution/ requirements/explicit_instantiation/1.cc: Likewise. * testsuite/26_numerics/random/fisher_f_distribution/requirements/ explicit_instantiation/1.cc: Likewise. * testsuite/26_numerics/random/gamma_distribution/requirements/ explicit_instantiation/1.cc: Likewise. * testsuite/26_numerics/random/geometric_distribution/requirements/ explicit_instantiation/1.cc: Likewise. * testsuite/26_numerics/random/lognormal_distribution/requirements/ explicit_instantiation/1.cc: Likewise. * testsuite/26_numerics/random/negative_binomial_distribution/ requirements/explicit_instantiation/1.cc: Likewise. * testsuite/26_numerics/random/normal_distribution/requirements/ explicit_instantiation/1.cc: Likewise. * testsuite/26_numerics/random/piecewise_constant_distribution/ requirements/explicit_instantiation/1.cc: Likewise. * testsuite/26_numerics/random/piecewise_linear_distribution/ requirements/explicit_instantiation/1.cc: Likewise. * testsuite/26_numerics/random/poisson_distribution/requirements/ explicit_instantiation/1.cc: Likewise. * testsuite/26_numerics/random/student_t_distribution/requirements/ explicit_instantiation/1.cc: Likewise. * testsuite/26_numerics/random/uniform_int_distribution/ requirements/explicit_instantiation/1.cc: Likewise. * testsuite/26_numerics/random/uniform_real_distribution/ requirements/explicit_instantiation/1.cc: Likewise. * testsuite/26_numerics/random/weibull_distribution/requirements/ explicit_instantiation/1.cc: Likewise. Added: branches/gcc-4_7-branch/libstdc++-v3/testsuite/26_numerics/random/binomial_distribution/requirements/explicit_instantiation/ branches/gcc-4_7-branch/libstdc++-v3/testsuite/26_numerics/random/binomial_distribution/requirements/explicit_instantiation/1.cc branches/gcc-4_7-branch/libstdc++-v3/testsuite/26_numerics/random/cauchy_distribution/requirements/explicit_instantiation/ branches/gcc-4_7-branch/libstdc++-v3/testsuite/26_numerics/random/cauchy_distribution/requirements/explicit_instantiation/1.cc branches/gcc-4_7-branch/libstdc++-v3/testsuite/26_numerics/random/chi_squared_distribution/requirements/explicit_instantiation/ branches/gcc-4_7-branch/libstdc++-v3/testsuite/26_numerics/random/chi_squared_distribution/requirements/explicit_instantiation/1.cc branches/gcc-4_7-branch/libstdc++-v3/testsuite/26_numerics/random/discrete_distribution/requirements/explicit_instantiation/ branches/gcc-4_7-branch/libstdc++-v3/testsuite/26_numerics/random/discrete_distribution/requirements/explicit_instantiation/1.cc branches/gcc-4_7-branch/libstdc++-v3/testsuite/26_numerics/random/exponential_distribution/requirements/explicit_instantiation/ branches/gcc-4_7-branch/libstdc++-v3/testsuite/26_numerics/random/exponential_distribution/requirements/explicit_instantiation/1.cc branches/gcc-4_7-branch/libstdc++-v3/testsuite/26_numerics/random/extreme_value_distribution/requirements/explicit_instantiation/ branches/gcc-4_7-branch/libstdc++-v3/testsuite/26_numerics/random/extreme_value_distribution/requirements/explicit_instantiation/1.cc branches/gcc-4_7-branch/libstdc++-v3/testsuite/26_numerics/random/fisher_f_distribution/requirements/explicit_instantiation/ branches/gcc-4_7-branch/libstdc++-v3/testsuite/26_numerics/random/fisher_f_distribution/requirements/explicit_instantiation/1.cc branches/gcc-4_7-branch/libstdc++-v3/testsuite/26_numerics/random/gamma_distribution/requirements/explicit_instantiation/ branches/gcc-4_7-branch/libstdc++-v3/testsuite/26_numerics
[Bug libstdc++/54376] incorrect complaint about redefinition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54376 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Known to fail|4.7.2, 4.8.0| --- Comment #17 from paolo at gcc dot gnu.org 2012-09-06 09:27:20 UTC --- Author: paolo Date: Thu Sep 6 09:27:10 2012 New Revision: 191016 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191016 Log: 2012-08-26 Marc Glisse Paolo Carlini PR libstdc++/54376 * include/bits/random.h (lognormal_distribution<>::operator==, gamma_distribution<>::operator==, chi_squared_distribution<>::operator==, fisher_f_distribution<>::operator==, student_t_distribution<>::operator==, binomial_distribution<>::operator==, negative_binomial_distribution<>::operator==, poisson_distribution<>::operator==): Change inline friend definition to non-template. * testsuite/26_numerics/random/binomial_distribution/requirements/ explicit_instantiation/1.cc: New. * testsuite/26_numerics/random/cauchy_distribution/requirements/ explicit_instantiation/1.cc: Likewise. * testsuite/26_numerics/random/chi_squared_distribution/ requirements/explicit_instantiation/1.cc: Likewise. * testsuite/26_numerics/random/discrete_distribution/requirements/ explicit_instantiation/1.cc: Likewise. * testsuite/26_numerics/random/exponential_distribution/ requirements/explicit_instantiation/1.cc: Likewise. * testsuite/26_numerics/random/extreme_value_distribution/ requirements/explicit_instantiation/1.cc: Likewise. * testsuite/26_numerics/random/fisher_f_distribution/requirements/ explicit_instantiation/1.cc: Likewise. * testsuite/26_numerics/random/gamma_distribution/requirements/ explicit_instantiation/1.cc: Likewise. * testsuite/26_numerics/random/geometric_distribution/requirements/ explicit_instantiation/1.cc: Likewise. * testsuite/26_numerics/random/lognormal_distribution/requirements/ explicit_instantiation/1.cc: Likewise. * testsuite/26_numerics/random/negative_binomial_distribution/ requirements/explicit_instantiation/1.cc: Likewise. * testsuite/26_numerics/random/normal_distribution/requirements/ explicit_instantiation/1.cc: Likewise. * testsuite/26_numerics/random/piecewise_constant_distribution/ requirements/explicit_instantiation/1.cc: Likewise. * testsuite/26_numerics/random/piecewise_linear_distribution/ requirements/explicit_instantiation/1.cc: Likewise. * testsuite/26_numerics/random/poisson_distribution/requirements/ explicit_instantiation/1.cc: Likewise. * testsuite/26_numerics/random/student_t_distribution/requirements/ explicit_instantiation/1.cc: Likewise. * testsuite/26_numerics/random/uniform_int_distribution/ requirements/explicit_instantiation/1.cc: Likewise. * testsuite/26_numerics/random/uniform_real_distribution/ requirements/explicit_instantiation/1.cc: Likewise. * testsuite/26_numerics/random/weibull_distribution/requirements/ explicit_instantiation/1.cc: Likewise. Added: branches/gcc-4_7-branch/libstdc++-v3/testsuite/26_numerics/random/binomial_distribution/requirements/explicit_instantiation/ branches/gcc-4_7-branch/libstdc++-v3/testsuite/26_numerics/random/binomial_distribution/requirements/explicit_instantiation/1.cc branches/gcc-4_7-branch/libstdc++-v3/testsuite/26_numerics/random/cauchy_distribution/requirements/explicit_instantiation/ branches/gcc-4_7-branch/libstdc++-v3/testsuite/26_numerics/random/cauchy_distribution/requirements/explicit_instantiation/1.cc branches/gcc-4_7-branch/libstdc++-v3/testsuite/26_numerics/random/chi_squared_distribution/requirements/explicit_instantiation/ branches/gcc-4_7-branch/libstdc++-v3/testsuite/26_numerics/random/chi_squared_distribution/requirements/explicit_instantiation/1.cc branches/gcc-4_7-branch/libstdc++-v3/testsuite/26_numerics/random/discrete_distribution/requirements/explicit_instantiation/ branches/gcc-4_7-branch/libstdc++-v3/testsuite/26_numerics/random/discrete_distribution/requirements/explicit_instantiation/1.cc branches/gcc-4_7-branch/libstdc++-v3/testsuite/26_numerics/random/exponential_distribution/requirements/explicit_instantiation/ branches/gcc-4_7-branch/libstdc++-v3/testsuite/26_numerics/random/exponential_distribution/requirements/explicit_instantiation/1.cc branches/gcc-4_7-branch/libstdc++-v3/testsuite/26_numerics/random/extreme_value_distribution/requirements/explicit_instantiation/ branches/gcc-4_7-branch/libstdc++-v3/testsuite/26_numerics/random/extreme_value_distribution/requirements/explicit_instantiation/1.cc branches/gcc-4_7-branch/libstdc++-v3/testsuite/26_numerics/random/fisher_f_distribution/requirements/explicit_instantiation/
[Bug libstdc++/54376] incorrect complaint about redefinition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54376 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Known to fail|4.7.2, 4.8.0| --- Comment #18 from Paolo Carlini 2012-09-06 09:28:28 UTC --- Done.
[Bug c/54500] While(TRUE) loop optimization of global struct variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54500 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-09-06 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther 2012-09-06 09:51:13 UTC --- This is not a testcase that can be compiled, please provide one so we can reproduce the issue and analyze it. Please also try a more recent compiler, 4.3.2 is out of maintainance since several years - try at least GCC 4.6.3.
[Bug c++/24314] Extra "template<>" in partial specialization is compiled successfuly.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24314 Paolo Carlini changed: What|Removed |Added Status|NEW |ASSIGNED CC|gcc-bugs at gcc dot gnu.org | AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com Known to fail|| --- Comment #7 from Paolo Carlini 2012-09-06 09:50:19 UTC --- Let's look a bit into this.
[Bug tree-optimization/54498] [4.7/4.8 Regression] incorrect code generation from g++ -O
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54498 Richard Guenther changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | --- Comment #2 from Richard Guenther 2012-09-06 09:58:26 UTC --- Let me see. We seem to pick up : REALPART_EXPR = 0.0; when optimizing : D.25613_38 = ft._M_value; __r$_M_value = D.25613_38; - D.25615_39 = MEM[(const double &)&prev_ft]; + D.25615_39 = 0.0; possibly not realizing that : prev_ft = ft; clobbers it.
[Bug tree-optimization/54497] [4.8 Regression] Revision 190015 causes 22% degradation on 172.mgrid on PowerPC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54497 Richard Guenther changed: What|Removed |Added CC||rguenth at gcc dot gnu.org Target Milestone|--- |4.8.0 Summary|Revision 190015 causes 22% |[4.8 Regression] Revision |degradation on 172.mgrid on |190015 causes 22% |PowerPC |degradation on 172.mgrid on ||PowerPC --- Comment #1 from Richard Guenther 2012-09-06 10:01:41 UTC --- I suppose the loop is no longer predicted to execute enough times?
[Bug tree-optimization/54498] [4.7/4.8 Regression] incorrect code generation from g++ -O
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54498 --- Comment #3 from Richard Guenther 2012-09-06 10:21:36 UTC --- Testing Index: gcc/tree-ssa-alias.c === --- gcc/tree-ssa-alias.c(revision 191016) +++ gcc/tree-ssa-alias.c(working copy) @@ -2094,7 +2094,10 @@ walk_non_aliased_vuses (ao_ref *ref, tre /* Lookup succeeded. */ else if (res != NULL) break; - /* Translation succeeded, continue walking. */ + /* Translation succeeded, continue walking. We have to +again visit cycles though. */ + if (visited) + bitmap_clear (visited); } vuse = gimple_vuse (def_stmt); }
[Bug c++/54501] New: infinite recursion on illegal code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54501
Bug #: 54501
Summary: infinite recursion on illegal code
Classification: Unclassified
Product: gcc
Version: 4.6.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d...@gcc.gnu.org
seen on 4.6, 4.7 and trunk on x86_64-linux-gnu
int main()
{
char argv[][0] = {"", 0};
}
$ g++ test.cc
doesn't terminate, or only if the VM get's exhausted.
[Bug bootstrap/39572] x86_64-*-openbsd* is not supported yet
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39572 Jonathan Gray changed: What|Removed |Added CC||jsg at openbsd dot org --- Comment #2 from Jonathan Gray 2012-09-06 11:09:32 UTC --- A target has now been merged, this can be closed. http://gcc.gnu.org/ml/gcc-cvs/2012-09/msg00020.html
[Bug bootstrap/39572] x86_64-*-openbsd* is not supported yet
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39572 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #3 from Paolo Carlini 2012-09-06 11:20:27 UTC --- Ok.
[Bug c++/54502] New: g++ 4.6 -std=c++0x ICE (segfault)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54502
Bug #: 54502
Summary: g++ 4.6 -std=c++0x ICE (segfault)
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d...@gcc.gnu.org
this works with 4.7 and trunk, fails with 4.6
$ cat foo.cc
#include
int main(){
std::deque y;
y.push_back( {2,5} );
}
$ g++-4.6 -std=c++0x foo.cc
foo.cc: In function 'int main()':
foo.cc:4:23: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
[Bug c++/54502] g++ 4.6 -std=c++0x ICE (segfault)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54502 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #1 from Paolo Carlini 2012-09-06 12:12:48 UTC --- I bet we have a duplicate. Fixed in the active branches anyway.
[Bug tree-optimization/54498] [4.7/4.8 Regression] incorrect code generation from g++ -O
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54498 H.J. Lu changed: What|Removed |Added Status|ASSIGNED|NEW CC||rguenth at gcc dot gnu.org --- Comment #4 from H.J. Lu 2012-09-06 12:21:36 UTC --- It was caused by revision 177672: http://gcc.gnu.org/ml/gcc-cvs/2011-08/msg00686.html
[Bug lto/53604] ld reports errors using lto after upgrading from gcc-4.6.2 to gcc-4.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53604 --- Comment #12 from Paul Scruby 2012-09-06 13:03:17 UTC --- I just tried Matt Hargett's patch from Bug53572 with gcc4.7.1 and it still has not fixed the problem we're having. I'll continue test these issues in our codebase with new versions of gcc as they're released. If I get some more time which I don't have at the moment, I'll try to replicate it with a standalone example. Thanks, Paul
[Bug target/27396] It seems that x86_64-unknown-openbsd3.9 is completely unsupported.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27396 Jonathan Gray changed: What|Removed |Added CC||jsg at openbsd dot org --- Comment #4 from Jonathan Gray 2012-09-06 13:44:00 UTC --- This is a duplicate of 39572 which has been closed. A target has now been merged. http://gcc.gnu.org/ml/gcc-cvs/2012-09/msg00020.html
[Bug tree-optimization/54494] [4.7 Regression] Missing store to volatile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54494
--- Comment #7 from Andrew Pinski 2012-09-06
13:51:45 UTC ---
Author: pinskia
Date: Thu Sep 6 13:51:37 2012
New Revision: 191025
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191025
Log:
2012-09-06 Andrew Pinski
PR tree-opt/54494
* tree-inline.c (remap_gimple_op_r): Copy TREE_SIDE_EFFECTS also.
2012-09-06 Andrew Pinski
PR tree-opt/54494
* gcc.dg/tree-ssa/strlen-1.c: New testcase.
Added:
branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/tree-ssa/strlen-1.c
- copied unchanged from r191014,
trunk/gcc/testsuite/gcc.dg/tree-ssa/strlen-1.c
Modified:
branches/gcc-4_7-branch/ (props changed)
branches/gcc-4_7-branch/gcc/ChangeLog
branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
branches/gcc-4_7-branch/gcc/tree-inline.c
Propchange: branches/gcc-4_7-branch/
('svn:mergeinfo' modified)
[Bug tree-optimization/54494] [4.7 Regression] Missing store to volatile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54494 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #8 from Andrew Pinski 2012-09-06 13:53:57 UTC --- Fixed. --- Comment #9 from Andrew Pinski 2012-09-06 13:53:57 UTC --- Fixed.
[Bug tree-optimization/54494] [4.7 Regression] Missing store to volatile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54494 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #8 from Andrew Pinski 2012-09-06 13:53:57 UTC --- Fixed. --- Comment #9 from Andrew Pinski 2012-09-06 13:53:57 UTC --- Fixed.
[Bug tree-optimization/54498] [4.6/4.7/4.8 Regression] incorrect code generation from g++ -O
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54498 Richard Guenther changed: What|Removed |Added Status|NEW |ASSIGNED Target Milestone|4.7.2 |4.6.4 Summary|[4.7/4.8 Regression]|[4.6/4.7/4.8 Regression] |incorrect code generation |incorrect code generation |from g++ -O |from g++ -O --- Comment #5 from Richard Guenther 2012-09-06 13:54:34 UTC --- Latent in 4.6, too.
[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419 --- Comment #38 from Jack Howarth 2012-09-06 14:04:11 UTC --- Created attachment 28140 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28140 revised patch tested against clang on darwin12
[Bug fortran/54503] New: debug: Consider using the beginning of the main program as locus for the set_* calls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54503
Bug #: 54503
Summary: debug: Consider using the beginning of the main
program as locus for the set_* calls
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org
Follow up to PR 54405
For the program
program essai_1
x = 1.0
end program
gfortran generates the following dump:
//
[hjff.f90 : 3] {
real(kind=4) x;
[hjff.f90 : 2] x = 1.0e+0;
}
main (integer(kind=4) argc, character(kind=1) * * argv)
[hjff.f90 : 3] {
static integer(kind=4) options.0[7] = {68, 1023, 0, 0, 1, 1, 0};
[hjff.f90 : 3] _gfortran_set_args (argc, argv);
[hjff.f90 : 3] _gfortran_set_options (7, [hjff.f90 : 3] &options.0[0]);
[hjff.f90 : 3] essai_1 ();
[hjff.f90 : 3] return 0;
}
//
Thus, if one sets a break point in "main", the position is 'end program'. If
one now steps ("s") through the program, one remains in that line for the
set_args/set_options calls, then one jumps to "MAIN__" alias "essai_1" in line
2 for the assignment - and for the rest, one remains as expected in line 3.
I wonder whether it wouldn't be more natural to have "main" and the set_*
functions with the locus of line 1 - and keep the "return 0" with the locus
line 3.
It's of low priority as doing a "n" won't do what users will expect either: It
jumps over the "essai_1()" call to the "return 0". Thus, it is only a minor
glitch.
[Bug fortran/54405] bad debugging info which lead to a wrong behavior of reverse-next in gdb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54405 Tobias Burnus changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||MOVED --- Comment #4 from Tobias Burnus 2012-09-06 14:07:02 UTC --- Edouard Canot: Thanks for the bug report! (In reply to comment #2) > This is a GDB only reverse-execution bug, filed now as: > http://sourceware.org/bugzilla/show_bug.cgi?id=14548 Thanks Jan for analyzing this bug - and for creating a draft patch at gdb bugzilla. As it is not a GCC bug, I close now this PR. (In reply to comment #3) > It happened because gfortran >= 4.6 uses this function and GDB cannot > reverse-step-over such jmp-only function. > (gdb) disass _gfortran_transfer_real_write > Dump of assembler code for function _gfortran_transfer_real_write: >0x77b9f930 <+0>:jmpq 0x77ae0a30 > <_gfortran_transfer_real@plt> Side note: The reason that gfortran uses the function _gfortran_transfer_real_write which directly calls _gfortran_transfer_real is that it allows to mark the arguments to the function as only being read and not modified, which allows for optimizations. Example: i = 5 write (*,*) i if (i /= 5) then ... ! < this conditional block can be removed while for read (*,*) i it couldn't. Previously, read and write called _gfortran_transfer_real, the former now goes through the wrapper and which has the read-only attributes.
[Bug c++/54504] New: Link failed when I move the GCC to another directory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54504 Bug #: 54504 Summary: Link failed when I move the GCC to another directory Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: prog...@163.com When I move the Cross GCC to another directory, the link failed. This is a requirement, our compilers are managed by Revision control, and the directory is always changed。 And I can not choose the library use -L option also. The lib file is exist on the origional directory. /repo/yuhuamei/mips-linux-eglibc/bin/mips-linux-g++ test.cc /repo/yuhuamei/mips-linux-eglibc/bin/../lib/gcc/mips-linux/4.7.1/../../../../mips-linux/bin/ld: cannot find /repo/yuhuamei/mips-linux-eglibc-gnu/mips-linux/lib/libc.so.6 /repo/yuhuamei/mips-linux-eglibc/bin/../lib/gcc/mips-linux/4.7.1/../../../../mips-linux/bin/ld: cannot find /repo/yuhuamei/mips-linux-eglibc-gnu/mips-linux/lib/libc_nonshared.a /repo/yuhuamei/mips-linux-eglibc/bin/../lib/gcc/mips-linux/4.7.1/../../../../mips-linux/bin/ld: cannot find /repo/yuhuamei/mips-linux-eglibc-gnu/mips-linux/lib/ld.so.1 collect2: error: ld returned 1 exit status /repo/yuhuamei/mips-linux-eglibc/bin/mips-linux-g++ -L/repo/yuhuamei/mips-linux-eglibc-gnu/mips-linux/lib test.cc /repo/yuhuamei/mips-linux-eglibc/bin/../lib/gcc/mips-linux/4.7.1/../../../../mips-linux/bin/ld: cannot find /repo/yuhuamei/mips-linux-eglibc-gnu/mips-linux/lib/libc.so.6 /repo/yuhuamei/mips-linux-eglibc/bin/../lib/gcc/mips-linux/4.7.1/../../../../mips-linux/bin/ld: cannot find /repo/yuhuamei/mips-linux-eglibc-gnu/mips-linux/lib/libc_nonshared.a /repo/yuhuamei/mips-linux-eglibc/bin/../lib/gcc/mips-linux/4.7.1/../../../../mips-linux/bin/ld: cannot find /repo/yuhuamei/mips-linux-eglibc-gnu/mips-linux/lib/ld.so.1 collect2: error: ld returned 1 exit status ls /repo/yuhuamei/mips-linux-eglibc/mips-linux/lib/libc.so.6 /repo/yuhuamei/mips-linux-eglibc/mips-linux/lib/libc_nonshared.a /repo/yuhuamei/mips-linux-eglibc/mips-linux/lib/ld.so.1 /repo/yuhuamei/mips-linux-eglibc/mips-linux/lib/ld.so.1 /repo/yuhuamei/mips-linux-eglibc/mips-linux/lib/libc.so.6 /repo/yuhuamei/mips-linux-eglibc/mips-linux/lib/libc_nonshared.a
[Bug c++/54504] Link failed when I move the GCC to another directory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54504 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-09-06 Ever Confirmed|0 |1 Severity|major |normal --- Comment #1 from Andrew Pinski 2012-09-06 14:13:26 UTC --- It works for me. How did you configure GCC?
[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419
--- Comment #39 from Jack Howarth 2012-09-06
14:11:49 UTC ---
The attached revised patch is Ulrich's original with the change of the test in
configure.ac from...
AC_TRY_COMPILE(, [void f(void){asm("rdrand %eax");}],
[ac_cv_x86_rdrand=yes], [ac_cv_x86_rdrand=no])
to
AC_TRY_COMPILE(,[asm("rdrand %eax");],
[ac_cv_x86_rdrand=yes], [ac_cv_x86_rdrand=no])
and the additional missing conditional on the definition of _GLIBCXX_X86_RDRAND
...
@@ -118,7 +118,7 @@ namespace std _GLIBCXX_VISIBILITY(defaul
random_device::result_type
random_device::_M_getval()
{
-#if (defined __i386__ || defined __x86_64__)
+#if (defined __i386__ || defined __x86_64__) && defined _GLIBCXX_X86_RDRAND
if (! _M_file)
return __x86_rdrand();
#endif
in libstdc++-v3/src/c++11/random.cc.
[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419
--- Comment #40 from Jakub Jelinek 2012-09-06
14:15:29 UTC ---
(In reply to comment #39)
> The attached revised patch is Ulrich's original with the change of the test in
> configure.ac from...
>
> AC_TRY_COMPILE(, [void f(void){asm("rdrand %eax");}],
> [ac_cv_x86_rdrand=yes], [ac_cv_x86_rdrand=no])
>
> to
>
> AC_TRY_COMPILE(,[asm("rdrand %eax");],
> [ac_cv_x86_rdrand=yes], [ac_cv_x86_rdrand=no])
>
> and the additional missing conditional on the definition of
> _GLIBCXX_X86_RDRAND
> ...
>
> @@ -118,7 +118,7 @@ namespace std _GLIBCXX_VISIBILITY(defaul
>random_device::result_type
>random_device::_M_getval()
>{
> -#if (defined __i386__ || defined __x86_64__)
> +#if (defined __i386__ || defined __x86_64__) && defined _GLIBCXX_X86_RDRAND
> if (! _M_file)
>return __x86_rdrand();
> #endif
>
> in libstdc++-v3/src/c++11/random.cc.
Looks ok to me, but patches should be mailed with ChangeLog entry to
gcc-patches and libstdc++ mailing lists.
[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419
--- Comment #40 from Jakub Jelinek 2012-09-06
14:15:29 UTC ---
(In reply to comment #39)
> The attached revised patch is Ulrich's original with the change of the test in
> configure.ac from...
>
> AC_TRY_COMPILE(, [void f(void){asm("rdrand %eax");}],
> [ac_cv_x86_rdrand=yes], [ac_cv_x86_rdrand=no])
>
> to
>
> AC_TRY_COMPILE(,[asm("rdrand %eax");],
> [ac_cv_x86_rdrand=yes], [ac_cv_x86_rdrand=no])
>
> and the additional missing conditional on the definition of
> _GLIBCXX_X86_RDRAND
> ...
>
> @@ -118,7 +118,7 @@ namespace std _GLIBCXX_VISIBILITY(defaul
>random_device::result_type
>random_device::_M_getval()
>{
> -#if (defined __i386__ || defined __x86_64__)
> +#if (defined __i386__ || defined __x86_64__) && defined _GLIBCXX_X86_RDRAND
> if (! _M_file)
>return __x86_rdrand();
> #endif
>
> in libstdc++-v3/src/c++11/random.cc.
Looks ok to me, but patches should be mailed with ChangeLog entry to
gcc-patches and libstdc++ mailing lists.
--- Comment #41 from Jakub Jelinek 2012-09-06
14:17:18 UTC ---
Ah, actually not completely, the
#if defined __i386__ || defined __x86_64__ && defined _GLIBCXX_X86_RDRAND
line in your patch is wrong, there should be () like in the other two
preprocessor conditionals.
[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419 --- Comment #41 from Jakub Jelinek 2012-09-06 14:17:18 UTC --- Ah, actually not completely, the #if defined __i386__ || defined __x86_64__ && defined _GLIBCXX_X86_RDRAND line in your patch is wrong, there should be () like in the other two preprocessor conditionals. --- Comment #42 from Paolo Carlini 2012-09-06 14:20:15 UTC --- Sorry if I'm saying something naive - I didn't follow the whole discussion - but I don't understand why - assuming indeed we want to do something at configure time - are being attached patches directly touching libstdc++-v3/configure* files, instead of acinclude.m4 (to be processed by autoreconf), which is the normal way we write this kind of code in the libraries.
[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419 --- Comment #43 from Jack Howarth 2012-09-06 14:31:53 UTC --- (In reply to comment #42) > Sorry if I'm saying something naive - I didn't follow the whole discussion - > but I don't understand why - assuming indeed we want to do something at > configure time - are being attached patches directly touching > libstdc++-v3/configure* files, instead of acinclude.m4 (to be processed by > autoreconf), which is the normal way we write this kind of code in the > libraries. Probably because... AC_TRY_COMPILE(, [ #if !defined __LONG_DOUBLE_128__ || (defined(__sparc__) && defined(__arch64__)) #error no need for long double compatibility #endif ], [ac_ldbl_compat=yes], [ac_ldbl_compat=no]) if test "$ac_ldbl_compat" = yes; then AC_DEFINE([_GLIBCXX_LONG_DOUBLE_COMPAT],1, [Define if compatibility should be provided for -mlong-double-64.]) port_specific_symbol_files="\$(top_srcdir)/config/os/gnu-linux/ldbl-extra.ver" fi already existed immediately above the new test in configure.ac.
[Bug rtl-optimization/52543] lower-subreg.c: code bloat of 300%-400% for multi-word memory splits
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52543 Oleg Endo changed: What|Removed |Added CC||olegendo at gcc dot gnu.org --- Comment #13 from Oleg Endo 2012-09-06 14:37:22 UTC --- I'm not sure, but this looks similar to what is happening in PR 54386, although there the mem load splitting happens way before lower-subreg.
[Bug other/54490] [4.7 Regression] ICE: Spill failure in newlib build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54490 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.7.2
[Bug c++/53958] [4.6/4.7/4.8 Regression] set_slot_part and canon_value_cmp using 90% of compile time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53958 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.6.4
[Bug libstdc++/54388] [4.7/4.8 Regression] std::array.at() const results in undefined behaviour
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54388 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.7.2
[Bug libstdc++/54392] [4.6/4.7/4.8 Regression] std::string::assign() fails to update length
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54392 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.6.4
[Bug tree-optimization/54498] [4.6/4.7/4.8 Regression] incorrect code generation from g++ -O
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54498 --- Comment #6 from Richard Guenther 2012-09-06 14:47:50 UTC --- Author: rguenth Date: Thu Sep 6 14:47:42 2012 New Revision: 191030 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191030 Log: 2012-09-06 Richard Guenther PR tree-optimization/54498 * tree-ssa-alias.h (get_continuation_for_phi): Add flag to abort when reaching an already visited region. * tree-ssa-alias.c (maybe_skip_until): Likewise. And do it. (get_continuation_for_phi_1): Likewise. (walk_non_aliased_vuses): When we translated the reference, abort when we re-visit a region. * tree-ssa-pre.c (translate_vuse_through_block): Adjust. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-alias.c trunk/gcc/tree-ssa-alias.h trunk/gcc/tree-ssa-pre.c
[Bug c++/53650] [4.7/4.8 Regression] large array causes huge memory use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53650 Richard Guenther changed: What|Removed |Added Priority|P3 |P2
[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419 --- Comment #44 from Paolo Carlini 2012-09-06 14:47:57 UTC --- Unless there are very special and compelling technical reasons, please use the autotools.
[Bug middle-end/54386] Unaligned mem load wrongly generated for inlined inline/static function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54386 Georg-Johann Lay changed: What|Removed |Added CC||gjl at gcc dot gnu.org --- Comment #1 from Georg-Johann Lay 2012-09-06 14:50:41 UTC --- Who expands the 8-bit loads? Is there an implicit memcpy, expanded in movmem*?
[Bug libstdc++/54482] failures in static linking with libstdc++, due to versioned symbols
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54482 Ollie Wild changed: What|Removed |Added AssignedTo|unassigned at gcc dot |aaw at gcc dot gnu.org |gnu.org | --- Comment #1 from Ollie Wild 2012-09-06 14:52:23 UTC --- The best solution I could come up with was to patch libtool to enable passing options destined for only the shared or static library builds. See http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00340.html for the temporary workaround I've applied to the google/* branches. Getting this submitted to trunk is going to be a roundabout process. I need to patch libtool, import an updated libtool to gcc (last one was in 2009), and convert libstdc++ to use a macro other than PIC for identifying that it's being compiled as part of a shared library. If other people have better ideas, I'm all ears.
[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419 --- Comment #45 from Jakub Jelinek 2012-09-06 14:58:25 UTC --- Well, it is using autotools, the decision whether to put the stuff into autoinclude.m4 and reference in configure.ac, or put in full just into configure.ac is pure esthetical thing.
[Bug c/54408] sqrt for vector types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54408
--- Comment #3 from Marc Glisse 2012-09-06 15:04:53
UTC ---
Thanks for the explanations.
One goal would be, in C++, to be able to write a single function template:
template T f(T x){return x+sqrt(x);}
which would work for float, double, long double, float vectors and double
vectors. (how exactly sqrt is spelled, possibly __builtin_math_sqrt, isn't that
important)
Currently, std::sqrt is overloaded on arithmetic types. If we had
__builtin_vec_sqrt, I guess we could add an extra overload to std::sqrt for
vector types (sfinae-constrained in some way). Not quite as convenient as a
completely generic __builtin_sqrt, but good enough I think (assuming the
libstdc++ maintainers are ok with it). Otherwise, a more generic
__builtin_math_sqrt which works on both scalars and vectors would be better.
[Bug middle-end/53667] [4.6/4.7/4.8 Regression] Cray pointer: Wrong result with optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53667
Richard Guenther changed:
What|Removed |Added
Priority|P3 |P2
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2012-09-06
AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
--- Comment #4 from Richard Guenther 2012-09-06
15:11:01 UTC ---
Confirmed. Must be fortran issue, the equivalent C testcase works:
extern void abort (void);
typedef __SIZE_TYPE__ uintptr_t;
void foo (uintptr_t *u)
{
static int i;
*u = (uintptr_t) &i;
}
void bar (uintptr_t *u)
{
if (*(int *)*u != 1)
abort ();
}
int main ()
{
uintptr_t mem;
foo (&mem);
*(int *)mem = 1;
bar (&mem);
return 0;
}
in particular the call to foo makes mem point to NONLOCAL as can be seen
from the ealias dump:
foo (&mem);
mem.0_1 = mem;
# PT = nonlocal escaped
mem.1_2 = (int *) mem.0_1;
while for the fortran case I see
object_holder_init (&object_holder);
pobj_1 = object_holder;
# PT =
pobj.4_2 = (integer(kind=8)[3] *) pobj_1;
*pobj.4_2[0] = 900;
so object_holder points to nothing. If I remove the implementations
of object_hoder_init and print_vals then the alias info is correct.
Thus, some attribute on object_holder_init confuses points-to analysis.
I see it has ".w" fnspec, so that must be where the bug lies (nothing
is wrong in specifying ".w" here).
Mine.
[Bug tree-optimization/54498] [4.6/4.7/4.8 Regression] incorrect code generation from g++ -O
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54498 --- Comment #7 from Richard Guenther 2012-09-06 15:20:29 UTC --- Author: rguenth Date: Thu Sep 6 15:20:24 2012 New Revision: 191031 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191031 Log: 2012-09-06 Richard Guenther PR tree-optimization/54498 * tree-ssa-alias.h (get_continuation_for_phi): Add flag to abort when reaching an already visited region. * tree-ssa-alias.c (maybe_skip_until): Likewise. And do it. (get_continuation_for_phi_1): Likewise. (walk_non_aliased_vuses): When we translated the reference, abort when we re-visit a region. * tree-ssa-pre.c (translate_vuse_through_block): Adjust. Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/tree-ssa-alias.c branches/gcc-4_7-branch/gcc/tree-ssa-alias.h branches/gcc-4_7-branch/gcc/tree-ssa-pre.c
[Bug middle-end/53676] [4.7 regression] empty loop is not always removed now
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53676 Richard Guenther changed: What|Removed |Added Priority|P3 |P2
[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419 --- Comment #46 from Paolo Carlini 2012-09-06 15:31:52 UTC --- I would say not just esthetical, because normally the maintainers know that the configury code is in acinclude.m4 and in case of issues look into it. If we start randomly adding non-trivial code "by hand" to confifure.ac, then each time there are two different places to check.
[Bug c++/54501] infinite recursion on illegal code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54501 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #1 from Daniel Krügler 2012-09-06 15:42:07 UTC --- I can confirm the problem for gcc 4.8 trunk for os=win32 arch=64bit systems
[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419
--- Comment #47 from Dominique d'Humieres
2012-09-06 16:01:09 UTC ---
The test in comment #20 is
/* end confdefs.h. */
int
main ()
{
void f(void){asm("rdrand %eax");}
;
return 0;
}
I have compiled it with clang 1.7 and gcc 4.4.6, 4.5.3, 4.6.3, 4.7.1, and 4.8.0
r191013 with
'-O0 -fdump-tree-all rdrand.c -save-temps'.
clang gives
In file included from rdrand.c:1:
rdrand.c:6:13: error: expected ';' at end of declaration
void f(void){asm("rdrand %eax");}
^
;
1 error generated.
gcc 4.4 and 4.5 gives
rdrand.c:6:no such instruction: `rdrand %eax'
and "grep rdrand rdrand.c.*"
rdrand.c.001t.tu:@2761 function_declname: @2768type: @2769srcp:
rdrand.c:4
rdrand.c.001t.tu: srcp: rdrand.c:6 link:
static
rdrand.c.001t.tu:@2800 result_decl type: @3 scpe: @2761srcp:
rdrand.c:4
rdrand.c.003t.original: __asm__ __volatile__("rdrand %eax"::);
rdrand.c.004t.gimple: __asm__ __volatile__("rdrand %eax");
rdrand.c.005t.nested: __asm__ __volatile__("rdrand %eax");
rdrand.c.008t.omplower: __asm__ __volatile__("rdrand %eax");
rdrand.c.009t.lower: __asm__ __volatile__("rdrand %eax");
rdrand.c.011t.eh: __asm__ __volatile__("rdrand %eax");
rdrand.c.012t.cfg: __asm__ __volatile__("rdrand %eax");
rdrand.c.013t.veclower: __asm__ __volatile__("rdrand %eax");
rdrand.c.021t.cleanup_cfg: __asm__ __volatile__("rdrand %eax");
rdrand.c.023t.ssa: __asm__ __volatile__("rdrand %eax");
rdrand.c.024t.einline2: __asm__ __volatile__("rdrand %eax");
rdrand.c.040t.release_ssa: __asm__ __volatile__("rdrand %eax");
rdrand.c.135t.cplxlower0: __asm__ __volatile__("rdrand %eax");
rdrand.c.140t.optimized: __asm__ __volatile__("rdrand %eax");
(with a bunch of additional hit in rdrand.c.001t.tu for 4.4).
For gcc 4.6 and above the test compiles without error and "grep rdrand
rdrand.c.*" gives
rdrand.c.001t.tu: srcp: rdrand.c:4 link:
extern
rdrand.c.001t.tu: srcp: rdrand.c:6 link:
static
rdrand.c.001t.tu:@2807 result_decl type: @3 scpe: @2768srcp:
rdrand.c:4
rdrand.c.003t.original: __asm__ __volatile__("rdrand %eax"::);
rdrand.c.005t.nested: __asm__ __volatile__("rdrand %eax");
i.e., "f(void){asm("rdrand %eax");}" is discarded after rdrand.c.005t.nested.
If someone thinks it is a [4.6/4.7/4.8 Regression] or a new undocumented
feature, please read the end of comment #33!
I have tried to bootstrap 191018 with the patch in comment #20 and gcc 4.4
(which fails the test for rdrand) and it failed with "no such instruction:
`rdrand %eax'". I think this answer the concern expressed by Marc in comment
#29: the bootstrapping compiler is not used for the tests in
libstdc++-v3/configure (am I wrong to assume that they use the new built one?).
[Bug middle-end/54386] Unaligned mem load wrongly generated for inlined inline/static function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54386 --- Comment #2 from Oleg Endo 2012-09-06 16:03:50 UTC --- (In reply to comment #1) > Who expands the 8-bit loads? Is there an implicit memcpy, expanded in > movmem*? I haven't investigated further into the issue. The logs in the original description are from the RTL expand pass, i.e. the first RTL pass.
[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419 Jack Howarth changed: What|Removed |Added Attachment #28140|0 |1 is obsolete|| --- Comment #48 from Jack Howarth 2012-09-06 16:14:37 UTC --- Created attachment 28141 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28141 revised patch tested against clang on darwin12 with ChangeLog
[Bug c++/54253] [C++11] constexpr constructor crashes with polymorphic base classes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54253 --- Comment #7 from Jason Merrill 2012-09-06 16:24:25 UTC --- Author: jason Date: Thu Sep 6 16:24:10 2012 New Revision: 191033 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191033 Log: PR c++/54341 PR c++/54253 * semantics.c (sort_constexpr_mem_initializers): New. (build_constexpr_constructor_member_initializers): Use it. (cx_check_missing_mem_inits): Skip artificial fields. * init.c (expand_aggr_init_1): Don't zero out a class with no data. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-virtual2.C trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-virtual3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/init.c trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog
[Bug c++/54341] [4.7/4.8 Regression] ICE (segfault) in cx_check_missing_mem_inits, at cp/semantics.c:6093
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54341 --- Comment #4 from Jason Merrill 2012-09-06 16:24:25 UTC --- Author: jason Date: Thu Sep 6 16:24:10 2012 New Revision: 191033 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191033 Log: PR c++/54341 PR c++/54253 * semantics.c (sort_constexpr_mem_initializers): New. (build_constexpr_constructor_member_initializers): Use it. (cx_check_missing_mem_inits): Skip artificial fields. * init.c (expand_aggr_init_1): Don't zero out a class with no data. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-virtual2.C trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-virtual3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/init.c trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog
[Bug c++/54253] [C++11] constexpr constructor crashes with polymorphic base classes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54253 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org Target Milestone|--- |4.8.0 --- Comment #8 from Jason Merrill 2012-09-06 16:25:00 UTC --- Fixed for 4.8.
[Bug c++/54253] [C++11] constexpr constructor crashes with polymorphic base classes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54253 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org Target Milestone|--- |4.8.0 --- Comment #7 from Jason Merrill 2012-09-06 16:24:25 UTC --- Author: jason Date: Thu Sep 6 16:24:10 2012 New Revision: 191033 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191033 Log: PR c++/54341 PR c++/54253 * semantics.c (sort_constexpr_mem_initializers): New. (build_constexpr_constructor_member_initializers): Use it. (cx_check_missing_mem_inits): Skip artificial fields. * init.c (expand_aggr_init_1): Don't zero out a class with no data. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-virtual2.C trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-virtual3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/init.c trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog --- Comment #8 from Jason Merrill 2012-09-06 16:25:00 UTC --- Fixed for 4.8.
[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54419 --- Comment #49 from Marc Glisse 2012-09-06 16:24:19 UTC --- (In reply to comment #47) > I think this answer the concern expressed by Marc in comment > #29: the bootstrapping compiler is not used for the tests in > libstdc++-v3/configure Thank you for this investigation :-) --- Comment #50 from Dominique d'Humieres 2012-09-06 16:46:56 UTC --- > Created attachment 28140 [details] > revised patch tested against clang on darwin12 I just finished a clean bootstrap with the patch in comment #38 on x86_64-apple-darwin10 (it works with the missing parentheses;-) with gcc 4.8 r190619. Thanks Jack!
[Bug tree-optimization/54505] New: RFE: Inline function tables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54505
Bug #: 54505
Summary: RFE: Inline function tables
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: a...@redhat.com
It is common to see code such as
static const int (*ftable[])(struct context *) = {
[V1] = f1,
[V2] = f2,
...
};
...
{
ftable[nr](context);
}
However, this is less efficient than an equivalent switch () statement since
the calling convention must be observed. Some registers are clobbered, others
must be set to the arguments, and the functions must have a prolog and an
epilogue.
It is easy to recognize the pattern though and convert it into an equivalent
switch:
switch (nr) {
case V1:
f1(context);
break;
case V2:
f2(context);
break;
...
}
[Bug testsuite/54184] [4.8 Regression] gcc.dg/pr52558-1.c failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54184 --- Comment #8 from Dominique d'Humieres 2012-09-06 17:06:07 UTC --- What about gcc.dg/pr52558-2.c and gcc.dg/tm/reg-promotion.c not handled by the patch posted at http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00390.html?
[Bug tree-optimization/54505] RFE: Inline function tables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54505
Steven Bosscher changed:
What|Removed |Added
CC||steven at gcc dot gnu.org
--- Comment #1 from Steven Bosscher 2012-09-06
17:29:02 UTC ---
struct context;
#undef ONE
#undef EIGHT
#define ONE(X)extern const int f0##X (struct context *);
#define EIGHT(X)ONE(X##0) ONE(X##1) ONE(X##2) ONE(X##3) \
ONE(X##4) ONE(X##5) ONE(X##6) ONE(X##7)
EIGHT(0)
EIGHT(1)
#undef ONE
#undef EIGHT
#define ONE(X)[X] = f0##X,
#define EIGHT(X)ONE(X##0) ONE(X##1) ONE(X##2) ONE(X##3) \
ONE(X##4) ONE(X##5) ONE(X##6) ONE(X##7)
static const int (*ftable[])(struct context *) = {
EIGHT(0)
EIGHT(1)
0
};
extern int foo (int, struct context *);
int
foo (int v, struct context *context)
{
ftable[v](context);
}
[Bug tree-optimization/54505] RFE: Inline function tables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54505 Steven Bosscher changed: What|Removed |Added CC|steven at gcc dot gnu.org | --- Comment #2 from Steven Bosscher 2012-09-06 17:30:43 UTC --- I don't think this transformation would always be an improvement. Had a developer wanted to use a switch, I'd think he/she would have used one. A dispatch table is much more code-size efficient compared to a switch.
[Bug c++/54506] New: Defaulted move constructors and move assignment operators are erroneously defined as deleted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54506
Bug #: 54506
Summary: Defaulted move constructors and move assignment
operators are erroneously defined as deleted
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ts...@mail.ru
g++ rejects the following well-formed code:
template
struct A
{
A() {}
A(A const volatile &&) = delete;
A &operator =(A const volatile &&) = delete;
template
A(A &&) {}
template
A &operator =(A &&) { return *this; }
};
struct B
{
A a;
B() = default;
B(B &&) = default;
B &operator =(B &&) = default;
};
int main()
{
B b = B();
b = B();
}
The compiler says that the defaulted move functions in B are deleted, however
12.8/11 and 12.8/23 do not define such functions as deleted.
[Bug go/54507] New: libgo testsuite does not timeout compilation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54507 Bug #: 54507 Summary: libgo testsuite does not timeout compilation Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go AssignedTo: i...@airs.com ReportedBy: ubiz...@gmail.com Recently text/template libgo test starts to compile for a very long time on alpha, probably due to some variable tracking explosion issue. The problem is, that the compilation does not timeout after some time and can run for a very long time, or even indefinitely. Please introduce some kind of compilation timeout to libgo testsuite. FYI: The compilation can finish in reasonable time with -fno-var-tracking-assignments option.
[Bug libstdc++/54172] [4.7/4.8 Regression] __cxa_guard_acquire thread-safety issue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54172 --- Comment #11 from Richard Henderson 2012-09-06 18:53:25 UTC --- The combined patch set also looks ok. Talking with bkoz, he would like to see more comments added, since a reasonable testcase seems unlikely.
[Bug debug/54508] New: Wrong debug information emitted if data members not referenced
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54508 Bug #: 54508 Summary: Wrong debug information emitted if data members not referenced Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassig...@gcc.gnu.org ReportedBy: paul_kon...@dell.com Created attachment 28142 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28142 test case file For the attached test case, GDB shows that the class definition for CIpcDumpACK_NP is wrong. Only the method is shows; the base class and data member are missing.
[Bug gcov-profile/54487] [4.8 Regression] profiledbootstrap broken by r190952
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54487
--- Comment #8 from Teresa Johnson 2012-09-06
18:58:55 UTC ---
I think I have a solution for the issue that H.J. is encountering. Details
below. Markus and H.J., would you be able to try the following patch to see if
it addresses the failure you were seeing? Markus, were you only seeing failures
when using a parallel make?
Index: libgcc/libgcov.c
===
--- libgcc/libgcov.c(revision 191035)
+++ libgcc/libgcov.c(working copy)
@@ -707,7 +707,9 @@ gcov_exit (void)
memcpy (cs_all, cs_prg, sizeof (*cs_all));
else if (!all_prg.checksum
&& (!GCOV_LOCKED || cs_all->runs == cs_prg->runs)
- && memcmp (cs_all, cs_prg, sizeof (*cs_all)))
+ && memcmp (cs_all, cs_prg,
+ sizeof (*cs_all) - (sizeof (gcov_bucket_type)
+ * GCOV_HISTOGRAM_SIZE)))
{
fprintf (stderr, "profiling:%s:Invocation mismatch - some data files
may have been removed%s\n",
gi_filename, GCOV_LOCKED
After looking at the cp-demangle matching issue for awhile, I finally realized
that in my case at least, it was a valid issue with the preprocessed
cp-demangle source code not matching the existing cp-demangle.gcda file. I
tracked that down to different includes being done due to a difference in the
libiberty configure. The libiberty config.log showed that there were some
failures in some of the checks which were using the instrumented prev-gcc/xgcc
that was giving errors like:
profiling:/home/tejohnson/extra/gcc_trunk_4_validate4/gcc/dwarf2out.gcda:Invocation
mismatch - some data files may have been removed
configure:3427: $? = 0
configure: failed program was:
...
When profile merging happens, there are some sanity checks to ensure that the
merged summaries for all object files are the same. These tests are failing in
some cases due to small differences in the merged histograms, resulting in the
above message. The total of the counter values in the histogram is the same,
but there are slight differences in the cumulative counter values assigned to
consecutive buckets. This could happen due to the way the cumulative counter
values are apportioned out to the counters when merging. If the summaries are
merged in different orders by the parallel runs, the integer division
truncation may result in small differences. Ultimately these differences don't
matter much as the sum of all the counter values saved in the histograms is
consistent and the differences will be small and not significant.
The best solution is to ignore the histogram when doing the sanity check, and
just compare the high-level summary info (sum_all, sum_max, run_max, etc). That
seems to be addressing the issue I was having. At least, I haven't been able to
reproduce it yet.
[Bug tree-optimization/54505] RFE: Inline function tables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54505 --- Comment #3 from Andrew Pinski 2012-09-06 19:25:29 UTC --- I think this optimization is only a benefit when the following happens: 1) all functions will be inlined (not just a wrapper though). 2) the table is small
[Bug gcov-profile/54487] [4.8 Regression] profiledbootstrap broken by r190952
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54487 --- Comment #9 from Markus Trippelsdorf 2012-09-06 19:34:44 UTC --- (In reply to comment #8) > I think I have a solution for the issue that H.J. is encountering. Details > below. Markus and H.J., would you be able to try the following patch to see if > it addresses the failure you were seeing? I just successfully completed a lto/profiledbootstrap with your patch applied. Thanks Teresa. > Markus, were you only seeing failures when using a parallel make? I never use non-parallel make, so I can't tell.
[Bug gcov-profile/54487] [4.8 Regression] profiledbootstrap broken by r190952
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54487 --- Comment #10 from Teresa Johnson 2012-09-06 20:02:30 UTC --- That's good news. I will finish testing the patch and send it for review. Thanks, Teresa
[Bug gcov-profile/54487] [4.8 Regression] profiledbootstrap broken by r190952
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54487
--- Comment #11 from H.J. Lu 2012-09-06 20:06:55
UTC ---
(In reply to comment #8)
> I think I have a solution for the issue that H.J. is encountering. Details
> below. Markus and H.J., would you be able to try the following patch to see if
> it addresses the failure you were seeing? Markus, were you only seeing
> failures
> when using a parallel make?
>
> Index: libgcc/libgcov.c
> ===
> --- libgcc/libgcov.c(revision 191035)
> +++ libgcc/libgcov.c(working copy)
> @@ -707,7 +707,9 @@ gcov_exit (void)
> memcpy (cs_all, cs_prg, sizeof (*cs_all));
>else if (!all_prg.checksum
> && (!GCOV_LOCKED || cs_all->runs == cs_prg->runs)
> - && memcmp (cs_all, cs_prg, sizeof (*cs_all)))
> + && memcmp (cs_all, cs_prg,
> + sizeof (*cs_all) - (sizeof (gcov_bucket_type)
> + * GCOV_HISTOGRAM_SIZE)))
> {
>fprintf (stderr, "profiling:%s:Invocation mismatch - some data
> files
> may have been removed%s\n",
> gi_filename, GCOV_LOCKED
>
>
I applied it by hand:
diff --git a/libgcc/libgcov.c b/libgcc/libgcov.c
index fce8587..daf95af 100644
--- a/libgcc/libgcov.c
+++ b/libgcc/libgcov.c
@@ -707,7 +707,10 @@ gcov_exit (void)
memcpy (cs_all, cs_prg, sizeof (*cs_all));
else if (!all_prg.checksum
&& (!GCOV_LOCKED || cs_all->runs == cs_prg->runs)
-&& memcmp (cs_all, cs_prg, sizeof (*cs_all)))
+&& memcmp (cs_all, cs_prg, sizeof (*cs_all))
+&& memcmp (cs_all, cs_prg,
+ sizeof (*cs_all) - (sizeof (gcov_bucket_type)
+ * GCOV_HISTOGRAM_SIZE)))
{
fprintf (stderr, "profiling:%s:Invocation mismatch - some data files
may have been removed%s\n",
gi_filename, GCOV_LOCKED
and it still failed for me on Fedora/18 24 core x86-64
with -j 12:
/export/gnu/import/git/gcc/gcc/tree-cfg.c: In function ‘bool
gimple_can_merge_blocks_p(basic_block, basic_block)’:
/export/gnu/import/git/gcc/gcc/tree-cfg.c:7904:1: error: corrupted profile
info: edge from 52 to 53 exceeds maximal count
}
^
/export/gnu/import/git/gcc/gcc/tree-cfg.c:7904:1: error: corrupted profile
info: edge from 54 to 55 exceeds maximal count
/export/gnu/import/git/gcc/gcc/tree-cfg.c:7904:1: error: corrupted profile
info: edge from 55 to 56 exceeds maximal count
/export/gnu/import/git/gcc/gcc/tree-cfg.c:7904:1: error: corrupted profile
info: edge from 56 to 57 exceeds maximal count
/export/gnu/import/git/gcc/gcc/tree-cfg.c:7904:1: internal compiler error: in
cgraph_create_edge_1, at cgraph.c:669
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
make[4]: *** [tree-cfg.o] Error 1
make[4]: *** Waiting for unfinished jobs
rm gcov.pod gcc.pod cpp.pod fsf-funding.pod gfdl.pod
make[4]: Leaving directory `/export/build/gnu/gcc-fdo/build-x86_64-linux/gcc'
make[3]: *** [all-stagefeedback-gcc] Error 2
[Bug c++/54509] New: If Move constructor is templatized then it is invoked else not
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54509
Bug #: 54509
Summary: If Move constructor is templatized then it is invoked
else not
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rsdev...@gmail.com
#include
#include
using namespace std;
// uncomment to see the bug with 4.7.1 and 4.8.0
#define _BUG_
struct Test
{
Test() = default;
Test(const Test & )
{
cout << "ctor overload 1 & " << endl;
}
#ifdef _BUG_
template
Test(T && )
{
//T* t = "0"; // For intentional error
cout << "ctor template version overload 2 && " << endl;
}
#else
Test(Test && )
{
cout << "ctor specialized overload 2 && " << endl;
}
#endif
};
int main()
{
Test t1( []()-> Test { return Test();}() );
return 0;
}
I expect Test(Test && ) to be invokved (without template version).
Also if you uncommment //T* t = "0"; -> you will see that data type is not a
magical data type, Being same as class itself, behavior is wrong.
[Bug c++/54510] New: If Move constructor is templatized then, that version is invoked instead default move
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54510
Bug #: 54510
Summary: If Move constructor is templatized then, that version
is invoked instead default move
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rsdev...@gmail.com
#include
#include
using namespace std;
// uncomment to see the bug with 4.7.1 and 4.8.0
#define _BUG_
struct Test
{
Test() = default;
Test(const Test & )
{
cout << "ctor overload 1 & " << endl;
}
#ifdef _BUG_
template
Test(T && )
{
//T* t = "0"; // For intentional error
cout << "ctor template version overload 2 && " << endl;
}
#else
Test(Test && )
{
cout << "ctor specialized overload 2 && " << endl;
}
#endif
};
int main()
{
Test t1( []()-> Test { return Test();}() );
return 0;
}
I expect Test(Test && ) to be invokved (without template version).
Also if you uncommment //T* t = "0"; -> you will see that data type is not a
magical data type, Being same as class itself, behavior is wrong.
[Bug gcov-profile/54487] [4.8 Regression] profiledbootstrap broken by r190952
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54487
--- Comment #12 from Teresa Johnson 2012-09-06
20:23:50 UTC ---
On Thu, Sep 6, 2012 at 1:06 PM, hjl.tools at gmail dot com
wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54487
>
> --- Comment #11 from H.J. Lu 2012-09-06 20:06:55
> UTC ---
> (In reply to comment #8)
>> I think I have a solution for the issue that H.J. is encountering. Details
>> below. Markus and H.J., would you be able to try the following patch to see
>> if
>> it addresses the failure you were seeing? Markus, were you only seeing
>> failures
>> when using a parallel make?
>>
>> Index: libgcc/libgcov.c
>> ===
>> --- libgcc/libgcov.c(revision 191035)
>> +++ libgcc/libgcov.c(working copy)
>> @@ -707,7 +707,9 @@ gcov_exit (void)
>> memcpy (cs_all, cs_prg, sizeof (*cs_all));
>>else if (!all_prg.checksum
>> && (!GCOV_LOCKED || cs_all->runs == cs_prg->runs)
>> - && memcmp (cs_all, cs_prg, sizeof (*cs_all)))
>> + && memcmp (cs_all, cs_prg,
>> + sizeof (*cs_all) - (sizeof (gcov_bucket_type)
>> + * GCOV_HISTOGRAM_SIZE)))
>> {
>>fprintf (stderr, "profiling:%s:Invocation mismatch - some data
>> files
>> may have been removed%s\n",
>> gi_filename, GCOV_LOCKED
>>
>>
>
> I applied it by hand:
> diff --git a/libgcc/libgcov.c b/libgcc/libgcov.c
> index fce8587..daf95af 100644
> --- a/libgcc/libgcov.c
> +++ b/libgcc/libgcov.c
> @@ -707,7 +707,10 @@ gcov_exit (void)
>memcpy (cs_all, cs_prg, sizeof (*cs_all));
> else if (!all_prg.checksum
> && (!GCOV_LOCKED || cs_all->runs == cs_prg->runs)
> -&& memcmp (cs_all, cs_prg, sizeof (*cs_all)))
> +&& memcmp (cs_all, cs_prg, sizeof (*cs_all))
> +&& memcmp (cs_all, cs_prg,
> + sizeof (*cs_all) - (sizeof (gcov_bucket_type)
> + * GCOV_HISTOGRAM_SIZE)))
>{
> fprintf (stderr, "profiling:%s:Invocation mismatch - some data files
> may have been removed%s\n",
> gi_filename, GCOV_LOCKED
>
> and it still failed for me on Fedora/18 24 core x86-64
> with -j 12:
>
> /export/gnu/import/git/gcc/gcc/tree-cfg.c: In function ‘bool
> gimple_can_merge_blocks_p(basic_block, basic_block)’:
> /export/gnu/import/git/gcc/gcc/tree-cfg.c:7904:1: error: corrupted profile
> info: edge from 52 to 53 exceeds maximal count
> }
> ^
> /export/gnu/import/git/gcc/gcc/tree-cfg.c:7904:1: error: corrupted profile
> info: edge from 54 to 55 exceeds maximal count
> /export/gnu/import/git/gcc/gcc/tree-cfg.c:7904:1: error: corrupted profile
> info: edge from 55 to 56 exceeds maximal count
> /export/gnu/import/git/gcc/gcc/tree-cfg.c:7904:1: error: corrupted profile
> info: edge from 56 to 57 exceeds maximal count
> /export/gnu/import/git/gcc/gcc/tree-cfg.c:7904:1: internal compiler error: in
> cgraph_create_edge_1, at cgraph.c:669
Unfortunately I haven't been able to reproduce this one yet. Can you
send me the corrupt gcda file?
Thanks,
Teresa
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See for instructions.
> make[4]: *** [tree-cfg.o] Error 1
> make[4]: *** Waiting for unfinished jobs
> rm gcov.pod gcc.pod cpp.pod fsf-funding.pod gfdl.pod
> make[4]: Leaving directory `/export/build/gnu/gcc-fdo/build-x86_64-linux/gcc'
> make[3]: *** [all-stagefeedback-gcc] Error 2
>
> --
> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
> --- You are receiving this mail because: ---
> You are on the CC list for the bug.
[Bug libstdc++/54172] [4.7/4.8 Regression] __cxa_guard_acquire thread-safety issue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54172 --- Comment #12 from Benjamin Kosnik 2012-09-06 20:31:13 UTC --- Author: bkoz Date: Thu Sep 6 20:31:08 2012 New Revision: 191042 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191042 Log: 2012-09-06 Thiago Macieira PR libstdc++/54172 * libsupc++/guard.cc (__cxa_guard_acquire): Exit the loop earlier if we detect that another thread has had success. Don't compare_exchange from a finished state back to a waiting state. Comment. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/libsupc++/guard.cc
[Bug gcov-profile/54487] [4.8 Regression] profiledbootstrap broken by r190952
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54487 --- Comment #13 from H.J. Lu 2012-09-06 20:49:02 UTC --- It works for me now after syncing with revision 191037.
[Bug tree-optimization/54497] [4.8 Regression] Revision 190015 causes 22% degradation on 172.mgrid on PowerPC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54497 --- Comment #2 from Pat Haugen 2012-09-06 21:05:05 UTC --- (In reply to comment #1) > I suppose the loop is no longer predicted to execute enough times? I don't think that's the issue, I'm thinking it's somewhere in the data dependence analysis. Looking at the dump before .pcom (i.e. .dceloop3), both resid_ and resid_.constprop.0 list BB7, the inner loop block, as freq=1. The .pcom dump has many differences in the data analysis portion between the two procedures, but the main difference is the analysis on resid_.constprop.0 ends with the following: Predictive commoning failed: no suitable chains
[Bug go/54507] libgo testsuite does not timeout compilation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54507 --- Comment #1 from Uros Bizjak 2012-09-06 21:15:09 UTC --- (In reply to comment #0) > FYI: The compilation can finish in reasonable time with > -fno-var-tracking-assignments option. The difference in compile time with this particular test was 38 minutes vs. a couple of minutes with -fno-var-tracking-assignment option.
[Bug rtl-optimization/52543] lower-subreg.c: code bloat of 300%-400% for multi-word memory splits
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52543 --- Comment #14 from Oleg Endo 2012-09-06 22:13:22 UTC --- (In reply to comment #0) > > For the __flash address space no preparation is needed, but a 32-bit read can > use post-increment addressing whereas a split to 4 byte moves won't use > post-increment because GCC is completely afraid of pre-/post-modify > addressing. > BTW, the reason for the auto-inc-dec problem is described in PR 50749. I've started writing a replacement for the auto-inc-dec pass, but it will take some time.
[Bug c/54495] gcc gives a false warning in kernel/trace/trace_events_filter.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54495 Toralf Förster changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Toralf Förster 2012-09-06 22:21:57 UTC --- yep, commit 92d8d4a8b0f "tracing/filter: Add missing initialization" will fix it
[Bug c++/54511] New: internal compiler error: in make_decl_rtl, at varasm.c:1147
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54511
Bug #: 54511
Summary: internal compiler error: in make_decl_rtl, at
varasm.c:1147
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: justda...@gmail.com
---hardwarecfg.cpp---
#include
template
class SPI
{
public:
SPI(uint32_t maxfreq)
{
union
{
int a;
int b;
};
a=0;
}
};
SPI<> spi(2500);
---end-of-file---
Command line:
arm-none-eabi-g++.exe hardwarecfg.cpp -save-temps
Compiler output:
hardwarecfg.cpp: In constructor 'SPI::SPI(uint32_t) [with int i = 0;
uint32_t = long unsigned int]':
hardwarecfg.cpp:14:3: internal compiler error: in make_decl_rtl, at
varasm.c:1147
Software versions:
GCC 4.7.1, YAGARTO GNU ARM toolchain
(http://sourceforge.net/projects/yagarto/files/YAGARTO%20for%20Windows/20120616/)
Windows XP SP3 (x86)
[Bug c++/54512] New: Assembler fails with error "fatal error: can't write ... file too big"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54512 Bug #: 54512 Summary: Assembler fails with error "fatal error: can't write ... file too big" Classification: Unclassified Product: gcc Version: 3.4.5 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: brad.t...@gmail.com Recently we have added build support for compiling our unit test using gcc on win32. The test compile successfully using Visual Studio, but when we compile using g++ we get an error from the assembler like the following: fatal error: can't write x.obj, file too big We are using the gcc distributed with MinGW. >From some research on the web I have seen the others have had the same issue using more recent versions of GCC.
[Bug c++/54504] Link failed when I move the GCC to another directory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54504 --- Comment #2 from progmei 2012-09-07 01:10:41 UTC --- My configuration as follow /repo/yuhuamei/mips-linux-eglibc/bin/mips-linux-gcc -v Using built-in specs. COLLECT_GCC=/repo/yuhuamei/mips-linux-eglibc/bin/mips-linux-gcc COLLECT_LTO_WRAPPER=/repo/yuhuamei/mips-linux-eglibc/bin/../libexec/gcc/mips-linux/4.7.1/lto-wrapper Target: mips-linux Configured with: ../gcc-4.7.1/configure --prefix=/repo/yuhuamei/mips-linux-eglibc-gnu --with-ppl=/repo/yuhuamei/ppl --with-cloog=/repo/yuhuamei/cloog-ppl --enable-languages=c,c++ --target=mips-linux : (reconfigured) ../gcc-4.7.1/configure --prefix=/repo/yuhuamei/mips-linux-eglibc-gnu --target=mips-linux --with-ppl=/repo/yuhuamei/ppl --with-cloog=/repo/yuhuamei/cloog-ppl --enable-__cxa_atexit --enable-languages=c,c++ Thread model: posix gcc version 4.7.1 (GCC)
[Bug c++/54512] Assembler fails with error "fatal error: can't write ... file too big"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54512 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||MOVED --- Comment #1 from Andrew Pinski 2012-09-07 01:10:09 UTC --- This is not a GCC issue but rather a binutils one. Report this first to mingw.
[Bug c++/54504] Link failed when I move the GCC to another directory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54504 --- Comment #3 from Andrew Pinski 2012-09-07 01:15:46 UTC --- So you are not using a sysroot?
[Bug other/54398] Incorrect ARM assembly when building with -fno-omit-frame-pointer -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54398
Carrot changed:
What|Removed |Added
CC||carrot at google dot com
--- Comment #4 from Carrot 2012-09-07 01:19:31 UTC
---
The code before the position Ahmad pointed out is already wrong.
The fault instruction sequence is:
asrsr5, r5, #1
asr ip, ip, #1 ; A, tmp1.x
asrsr0, r0, #1 ; B, tmp1.y
asrsr6, r6, #1
mov r4, r1
add r8, ip, r6 ; C, tmp3.x
add r9, r0, r5 ; D, tmp3.y
add r7, sp, #0
asr r1, r8, #1
add ip, r4, #8 ; E,
asr r9, r9, #1
str r1, [r7, #16]
str r9, [r7, #20]
ldmia r3, {r0, r1}; F,
stmia r4, {r0, r1}
Instruction A computes the result of tmp1.x, instruction C use it to compute
tmp3.x, instruction E overwrite the value of tmp1.x. But in the source code,
tmp1.x is still needed to execute "dst1->p2 = tmp1;", so at last dest1->p2.x
gets garbage.
Similarly instruction B computes tmp1.y, instruction D uses it to compute
tmp3.y, instruction F overwrites it. After executing "dst1->p2 = tmp1;",
dst1->p2.y gets another garbage value.
For comparison, following is the correct version
asrsr7, r7, #1; A, tmp1.x
asrsr0, r0, #1; B, tmp1.y
asrsr6, r6, #1
asrsr5, r5, #1
sub sp, sp, #28
mov r4, r1
add r8, r7, r6; C, tmp3.x
add ip, r0, r5; D, tmp3.y
str r7, [sp, #0] ; X, save tmp1.x
str r0, [sp, #4] ; Y, save tmp1.y
asr r1, ip, #1
add r7, r4, #8 ; E
asr r8, r8, #1
str r1, [sp, #20]
str r8, [sp, #16]
ldmia r3, {r0, r1} ; F
stmia r4, {r0, r1}
The obvious difference is the extra instructions X and Y, they save the value
of tmp1 to stack before reusing the register.
The simplified preprocessed source code is
struct A
{
int x;
int y;
void f(const A &a, const A &b)
{
x = (a.x + b.x)>>1;
y = (a.y + b.y)>>1;
}
};
class C {
public:
A p1;
A p2;
A p3;
bool b;
void g(C *, C *) const;
};
void C::g(C *dst1, C *dst2) const
{
A tmp1, tmp2, tmp3;
tmp1.f(p2,p1);
tmp2.f(p2,p3);
tmp3.f(tmp1, tmp2);
dst1->p1 = p1;
dst1->p2 = tmp1;
dst1->p3 =
dst2->p1 = tmp3;
dst2->p2 = tmp2;
dst2->p3 = p3;
}
The simplified command line is:
./cc1plus -fpreprocessed t.ii -quiet -dumpbase t.cpp -mthumb "-march=armv7-a"
"-mtune=cortex-a15" -auxbase t -O2 -fno-omit-frame-pointer -o t.s
It looks like the dse2 pass did wrong transformation.
The gcc4.7 and trunk generate correct code.
[Bug c++/54504] Link failed when I move the GCC to another directory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54504 --- Comment #4 from progmei 2012-09-07 04:49:04 UTC --- no，i'm not using a sysroot
[Bug driver/54504] Link failed when I move the GCC to another directory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54504 Andrew Pinski changed: What|Removed |Added Component|c++ |driver --- Comment #5 from Andrew Pinski 2012-09-07 04:53:08 UTC --- This is a cross you really should be using a sysroot. I use 4.7.x as a cross compiler with a sysroot and am able to move around GCC all the time.
[Bug gcov-profile/54487] [4.8 Regression] profiledbootstrap broken by r190952
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54487 --- Comment #14 from Teresa Johnson 2012-09-07 05:19:10 UTC --- On Thu, Sep 6, 2012 at 1:49 PM, hjl.tools at gmail dot com wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54487 > > --- Comment #13 from H.J. Lu 2012-09-06 20:49:02 > UTC --- > It works for me now after syncing with revision 191037. Unfortunately, I have now hit this myself a couple times in further testing, so I am still digging... Teresa > > -- > Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email > --- You are receiving this mail because: --- > You are on the CC list for the bug.
[Bug c++/54509] If Move constructor is templatized then it is invoked else not
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54509 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #1 from Daniel Krügler 2012-09-07 05:37:56 UTC --- The language requires that the presence of a user-declared copy-constructor (which you have used in your code) shall prevent the compiler-declared move constructor. When _BUG_ is defined, the effect is that the class has a copy constructor and a template constructor template Test(T &&); but *no* move constructor. The template constructor will always be a better match for rvalue arguments than the copy constructor, therefore it is called twice in your program. In other words: The behavior of gcc looks correct and this report seems invalid to me.
[Bug c++/54510] If Move constructor is templatized then, that version is invoked instead default move
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54510 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #1 from Daniel Krügler 2012-09-07 05:40:24 UTC --- This bug report looks invalid to me for the same reason as bug 54510
