[Bug target/48009] Bootstrap failure: c++locale.cc: invalid conversion from 'const char*' to 'char*'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48009 Paolo Carlini changed: What|Removed |Added CC||dje at gcc dot gnu.org --- Comment #4 from Paolo Carlini 2012-05-12 08:34:13 UTC --- David, did you see this?
[Bug bootstrap/52887] Bootstrap on AIX failure: Undefined symbol: .std::function::function(std::function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52887 --- Comment #9 from Paolo Carlini 2012-05-12 08:35:05 UTC --- AIX used to be even more special about this...
[Bug target/53315] simple xtest program generates ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53315 --- Comment #11 from Jakub Jelinek 2012-05-12 09:14:53 UTC --- Created attachment 27385 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27385 gcc48-pr53315.patch That is because the patch is buggy. Fixed thusly, though haven't tested it on Haswell (obviously) nor sim. Note, it would be nice to have a peephole or something similar (guess peepholes won't do anything across multiple bbs, perhaps machine reorg) to optimize that movl$-1, %eax xbegin .L2 .L2: cmpl$-1, %eax jne .L3 xorl%eax, %eax into say movl$-1, %eax xbegin .L3 xorl%eax, %eax or even xbegin .L3 xorl%eax, %eax
[Bug fortran/49110] Deferred-length character result triggers (false positive) error for pure procedures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49110 --- Comment #14 from Tobias Burnus 2012-05-12 09:54:00 UTC --- Author: burnus Date: Sat May 12 09:53:53 2012 New Revision: 187427 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187427 Log: 2012-05-12 Tobias Burnus PR fortran/49110 PR fortran/52843 * resolve.c (resolve_fl_procedure): Don't regard character(len=:) as character(*) in the diagnostic. 2012-05-12 Tobias Burnus PR fortran/49110 PR fortran/52843 * gfortran.dg/deferred_type_param_5.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/deferred_type_param_5.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/52843] Unexpected rejection of pure recursive function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52843 --- Comment #1 from Tobias Burnus 2012-05-12 09:54:00 UTC --- Author: burnus Date: Sat May 12 09:53:53 2012 New Revision: 187427 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187427 Log: 2012-05-12 Tobias Burnus PR fortran/49110 PR fortran/52843 * resolve.c (resolve_fl_procedure): Don't regard character(len=:) as character(*) in the diagnostic. 2012-05-12 Tobias Burnus PR fortran/49110 PR fortran/52843 * gfortran.dg/deferred_type_param_5.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/deferred_type_param_5.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/52843] Unexpected rejection of pure recursive function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52843 Tobias Burnus changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #2 from Tobias Burnus 2012-05-12 09:56:45 UTC --- FIXED on the trunk. Thanks for the bugreport and sorry for the delay.
[Bug fortran/49110] Deferred-length character result triggers (false positive) error for pure procedures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49110 --- Comment #15 from Tobias Burnus 2012-05-12 09:59:10 UTC --- The commit of comment 13 fixes the issue with the bogus PURE diagnostic. Sorry that it took one year to get it fixed - and thanks for the bug report. * * * Regarding the REPEAT issue (cf. comment 9 and PR 51055): A patch solving that issue has been posted at http://gcc.gnu.org/ml/fortran/2012-05/msg00054.html
[Bug debug/49162] ICE in in output_die, at dwarf2out.c:10568 with -femit-struct-debug-reduced
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49162 --- Comment #1 from Pawel Sikora 2012-05-12 10:26:56 UTC --- could someone confirm this finally and set target milestone to 4.5.4? i'd like to drop this old problem from 'my bugs' list with 4.5 termination.
[Bug fortran/53329] New: ICE with deferred-length module variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53329 Bug #: 53329 Summary: ICE with deferred-length module variables Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org Blocks: 45170 The following code gives an ICE: module m character(len=:), allocatable :: str end module m Untested fix: --- a/gcc/fortran/trans-decl.c +++ b/gcc/fortran/trans-decl.c @@ -1103,2 +1103,10 @@ gfc_create_string_length (gfc_symbol * sym) sym->ts.u.cl->backend_decl = length; + + if (sym->attr.save + || (ns->parent && ns->parent->proc_name->attr.flavor == FL_MODULE)) + TREE_STATIC (length) = 1; + + if (ns->parent && ns->parent->proc_name->attr.flavor == FL_MODULE + && (sym->attr.access != ACCESS_PRIVATE || sym->attr.public_used)) + TREE_PUBLIC (length) = 1; }
[Bug c++/53330] New: new() operator can return NULL on a zero-length allocation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53330 Bug #: 53330 Summary: new() operator can return NULL on a zero-length allocation Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: kilob...@angband.pl Created attachment 27386 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27386 test case While in general C++ disallows zero-length arrays, they are explicitly allowed by the new() operator (C++ 3.7.4.1.2), with a guarantee that such an allocation will always return an unique non-null pointer. This worked correctly in 4.6 and before (and clang, and MSVC, ...), 4.7.0 (Debian 4.7.0-8) and trunk@187013 return null if elements of the array have a constructor and have sizeof() > 0 themselves. For simple types or structs, all is ok. Also, if there's a constructor (no regards for sizeof(element)) and the array length is known at compile time, -Wuninitialized returns incorrect diagnostics that the returned value is uninitialized.
[Bug c++/53330] new() operator can return NULL on a zero-length allocation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53330 --- Comment #1 from Adam Borowski 2012-05-12 11:01:23 UTC --- Correction: after testing with valgrind, the return value is indeed uninitialized; the pointer in contructor-but-no-fields case happens to be non-zero but is junk and will cause a crash when you try to free it.
[Bug bootstrap/53321] [4.8 Regression] LTO bootstrap failed with bootstrap-profiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53321 --- Comment #5 from Jan Hubicka 2012-05-12 11:03:01 UTC --- I need to add disable-werror otherwise we fail on extra warnings, but with that my bootstrap works. Is it still failing for you? The unreferenced nodes removal is very basic thing so when it breaks it should show up quite consistently. Honza
[Bug bootstrap/52700] lib* configure fails on --enable-symvers=gnu-versioned-namespace.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52700 Pawel Sikora changed: What|Removed |Added CC||bkoz at redhat dot com, ||paolo.carlini at oracle dot ||com --- Comment #2 from Pawel Sikora 2012-05-12 11:15:49 UTC --- Paolo, Benjamin, could you look at this issue?
[Bug target/53315] simple xtest program generates ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53315 --- Comment #12 from Uros Bizjak 2012-05-12 11:29:53 UTC --- (In reply to comment #11) > Created attachment 27385 [details] > gcc48-pr53315.patch Please introduce check-rtm.h header for use in runtime testcases, as is the case with i.e. check-sse2.h and other feature check headers.
[Bug tree-optimization/50847] missed diagnostics for dead code.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50847 Pawel Sikora changed: What|Removed |Added CC||lopezibanez at gmail dot ||com --- Comment #1 from Pawel Sikora 2012-05-12 11:35:07 UTC --- Manuel, could you improve gcc diagnostics in this area?
[Bug tree-optimization/50847] missed diagnostics for dead code.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50847 --- Comment #2 from Paolo Carlini 2012-05-12 11:56:45 UTC --- Related to PR46476?
[Bug tree-optimization/52054] Value-numbering does not enter translated expressions into the hash table
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52054 --- Comment #5 from Richard Guenther 2012-05-12 11:57:41 UTC --- (In reply to comment #4) > (In reply to comment #3) > > PR53125 has a testcase where we spend time in redundant store removal in > > eliminate() which does vn_reference_lookup with VN_WALK (which it should not > > need). > > The patch of comment #2 has no influence on the compile time for bug 53125. Is > that expected? Yes. You need to change the vn_reference_lookup with VN_WALK in eliminate() to VN_NOWALK, too (based on the fact that we'd have done that lookup at value-numbering time already and entered the result, so walking would no longer be necessary).
[Bug tree-optimization/50847] missed warning about unreachable code after throw statment.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50847 --- Comment #3 from Pawel Sikora 2012-05-12 12:07:06 UTC --- (In reply to comment #2) > Related to PR46476? similar (return vs. throw statment).
[Bug fortran/50221] Allocatable string length fails with array assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50221
--- Comment #2 from Tobias Burnus 2012-05-12
12:10:33 UTC ---
The following program illustrates some of the problems:
a) If the comment lines are removed (i.e. a module is used), there is no
valgrind failure and the result is correct. (Note: It requires the patch from
PR 53329 with "ns" replaced by "sym->ns".)
b) The program (as is) shows no valgrind failure, but the assignment is wrong:
"c3", "c3", "c3" instead of "a1", "b2", "c3".
c) If one removes the "save,", the result is as with (b) but valgrind shows
many errors of the form:
Conditional jump or move depends on uninitialised value(s)
at 0x4C2C3A9: memcpy@@GLIBC_2.14
(The same failures one gets for the original program of comment 0.)
Looking at the dump for (b) - also in comparison with (a) -, I fail to see why
one get's ["c1","c1","c1"] - the code looks correct ("S.0" goes from 1 to 3):
__builtin_memcpy ((void *) &(*D.1881)[(S.0 + D.1885) + D.1882],
(void *) &const[S.0 + -1], (unsigned long) D.1887);
In principle, accessing the second argument wrongly should cause that problem.
But that one looks okay. I wonder more about the left as
(*D.1881)[...]
assumes that the compiler knows the size of one element - I am not sure that
that works as ".str" is not yet the right value before the line:
character(kind=1)[0:][1:.str] * restrict D.1881;
!module m
character(len=:), save, allocatable :: str(:)
character(len=2), parameter :: const(3) = ["a1", "b2", "c3"]
!end
!use m
call test()
if(allocated(str)) deallocate(str)
contains
subroutine test()
call doit()
print *, 'strlen=',len(str),' / array size =',size(str)
print '(3a)', '>',str(1),'<'
print '(3a)', '>',str(2),'<'
print '(3a)', '>',str(3),'<'
end subroutine test
subroutine doit()
str = const
end subroutine doit
end
[Bug tree-optimization/50847] missed warning about unreachable code after throw statment.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50847 Manuel López-Ibáñez changed: What|Removed |Added CC|lopezibanez at gmail dot|manu at gcc dot gnu.org |com | --- Comment #4 from Manuel López-Ibáñez 2012-05-12 12:31:14 UTC --- (In reply to comment #1) > Manuel, could you improve gcc diagnostics in this area? Sorry but the little free time I have for GCC is going to be focused on improving the options machinery and the caret diagnostics. I may try to push for colors, if I find the time. Unfortunately, we are very very few working on C/C++ FEs right now. In this case, I am not even sure how this could be implemented in the FE without some kind of control-flow graph.
[Bug c++/46476] Missing Warning about unreachable code after return
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46476 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #2 from Manuel López-Ibáñez 2012-05-12 12:35:20 UTC --- (In reply to comment #1) > Confirmed. Hi Richard, how do you think this could be implemented? Wasn't -Wunreachable-code removed just a few releases ago?
[Bug target/53315] simple xtest program generates ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53315 Jakub Jelinek changed: What|Removed |Added Attachment #27385|0 |1 is obsolete|| --- Comment #13 from Jakub Jelinek 2012-05-12 14:05:07 UTC --- Created attachment 27387 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27387 gcc48-pr53315.patch Like this?
[Bug bootstrap/53331] New: [4.8 Regression] AIX bootstrap failure in tree-vect-data-ref compiling matmul_i4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53331 Bug #: 53331 Summary: [4.8 Regression] AIX bootstrap failure in tree-vect-data-ref compiling matmul_i4 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: d...@gcc.gnu.org The recent patch to tree-vect-data-ref.c produces an ICE when compiling matmul_i4 in libgfortran on PowerPC: /farm/dje/src/src/libgfortran/generated/matmul_i4.c: In function 'matmul_i4': /farm/dje/src/src/libgfortran/generated/matmul_i4.c:79:1: internal compiler error: in vect_enhance_data_refs_alignment, at tree-vect-data-refs.c:1963 matmul_i4 (gfc_array_i4 * const restrict retarray,
[Bug bootstrap/53331] [4.8 Regression] AIX bootstrap failure in tree-vect-data-ref compiling matmul_i4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53331 David Edelsohn changed: What|Removed |Added Target||powerpc64-*-* Status|UNCONFIRMED |NEW Keywords||ice-on-valid-code Last reconfirmed||2012-05-12 CC||rguenth at gcc dot gnu.org Host||powerpc64-*-* Ever Confirmed|0 |1 Target Milestone|--- |4.8.0 Build||powerpc64-*-* --- Comment #1 from David Edelsohn 2012-05-12 14:25:31 UTC --- /tmp/20120511/./gcc/xgcc -B/tmp/20120511/./gcc/ -B/farm/dje/install/powerpc-ibm-aix5.3.0.0-20120511/powerpc-ibm-aix5.3.0.0/bin/ -B/farm/dje/install/powerpc-ibm-aix5.3.0.0-20120511/powerpc-ibm-aix5.3.0.0/lib/ -isystem /farm/dje/install/powerpc-ibm-aix5.3.0.0-20120511/powerpc-ibm-aix5.3.0.0/include -isystem /farm/dje/install/powerpc-ibm-aix5.3.0.0-20120511/powerpc-ibm-aix5.3.0.0/sys-include -maix64 -DHAVE_CONFIG_H -I. -I/farm/dje/src/src/libgfortran -iquote/farm/dje/src/src/libgfortran/io -I/farm/dje/src/src/libgfortran/../gcc -I/farm/dje/src/src/libgfortran/../gcc/config -I../../.././gcc -I/farm/dje/src/src/libgfortran/../libgcc -I../../libgcc -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -fcx-fortran-rules -ffunction-sections -fdata-sections -ftree-vectorize -funroll-loops -std=gnu99 -g -O2 -Wunknown-pragmas -MT matmul_i4.lo -MD -MP -MF .deps/matmul_i4.Tpo -c /farm/dje/src/src/libgfortran/generated/matmul_i4.c -DPIC -o .libs/matmul_i4.o
[Bug bootstrap/53331] [4.8 Regression] AIX bootstrap failure in tree-vect-data-ref compiling matmul_i4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53331 --- Comment #2 from Dominique d'Humieres 2012-05-12 14:27:07 UTC --- On powerpc-apple-darwin9 I get a similar failure: ../../../work/libgfortran/generated/matmul_i8.c: In function 'matmul_i8': ../../../work/libgfortran/generated/matmul_i8.c:79:1: internal compiler error: in vect_enhance_data_refs_alignment, at tree-vect-data-refs.c:1963 matmul_i8 (gfc_array_i8 * const restrict retarray,
[Bug lto/47247] Linker plugin specification makes it difficult to handle COMDATs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47247 Jan Hubicka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #33 from Jan Hubicka 2012-05-12 14:33:47 UTC --- The actual problem was solved by V2 of plugin API. The warning you describe should not happen with or without the V2 API. Can you, please, try to fill in independent PR possibly with a testcase?
[Bug target/48009] Bootstrap failure: c++locale.cc: invalid conversion from 'const char*' to 'char*'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48009 David Edelsohn changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-05-12 Ever Confirmed|0 |1 --- Comment #5 from David Edelsohn 2012-05-12 14:34:13 UTC --- AIX 4.3 is extremely old and support was withdrawn a while ago. I am surprised that anyone is trying to build recent versions of GCC for it. If someone wants to develop a fixincludes patch, I can review it. The problem undoubtedly exists, but can be worked around manually.
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #130 from Jan Hubicka 2012-05-12 14:44:47 UTC --- After fixing one linker error, I can now build Mozilla with -flto-partition=none. It takes 11GB and 40 minutes, so there is space for improvement ;) There are some obvious questions, like why IRA needs 63% of GGC memory, and VRP 23% Also the -flto-partition=none .text section is now 18% smaller. This is large enough to be declared a bug, but I am not sure how to track it. Note that my macihne has quite poor since CPU performance, so the compile times are likely not comparable with LLVM ones reported above (and I also use debugging build). ipa lto gimple in : 52.12 ( 2%) usr 3.68 ( 9%) sys 55.72 ( 2%) wall 2998249 kB (84%) ggc ipa lto decl in : 225.68 ( 8%) usr 2.39 ( 6%) sys 228.17 ( 8%) wall 1124821 kB (31%) ggc ipa lto cgraph I/O : 4.82 ( 0%) usr 0.44 ( 1%) sys 5.27 ( 0%) wall 684110 kB (19%) ggc cfg construction: 3.01 ( 0%) usr 0.12 ( 0%) sys 3.29 ( 0%) wall 70205 kB ( 2%) ggc cfg cleanup : 46.57 ( 2%) usr 0.41 ( 1%) sys 46.69 ( 2%) wall 75005 kB ( 2%) ggc df live regs: 78.21 ( 3%) usr 0.25 ( 1%) sys 77.55 ( 3%) wall 0 kB ( 0%) ggc alias analysis : 25.59 ( 1%) usr 0.12 ( 0%) sys 25.88 ( 1%) wall 474769 kB (13%) ggc parser (global) : 8.62 ( 0%) usr 0.65 ( 2%) sys 10.00 ( 0%) wall 259389 kB ( 7%) ggc inline heuristics : 87.23 ( 3%) usr 0.51 ( 1%) sys 88.41 ( 3%) wall 451358 kB (13%) ggc integration : 50.61 ( 2%) usr 1.51 ( 4%) sys 52.67 ( 2%) wall 1479979 kB (41%) ggc tree CFG cleanup: 46.68 ( 2%) usr 0.43 ( 1%) sys 48.09 ( 2%) wall 70493 kB ( 2%) ggc tree VRP: 65.88 ( 2%) usr 0.73 ( 2%) sys 66.71 ( 2%) wall 862879 kB (24%) ggc tree copy propagation : 22.30 ( 1%) usr 0.17 ( 0%) sys 22.11 ( 1%) wall 144298 kB ( 4%) ggc tree PTA: 46.70 ( 2%) usr 0.06 ( 0%) sys 46.90 ( 2%) wall 100249 kB ( 3%) ggc tree SSA rewrite: 19.16 ( 1%) usr 0.15 ( 0%) sys 19.09 ( 1%) wall 149347 kB ( 4%) ggc tree SSA incremental: 27.75 ( 1%) usr 0.61 ( 1%) sys 27.86 ( 1%) wall 72307 kB ( 2%) ggc tree operand scan : 57.17 ( 2%) usr 3.03 ( 7%) sys 59.92 ( 2%) wall 1296208 kB (36%) ggc dominator optimization : 35.95 ( 1%) usr 0.21 ( 0%) sys 35.74 ( 1%) wall 311024 kB ( 9%) ggc tree CCP: 31.61 ( 1%) usr 0.12 ( 0%) sys 31.17 ( 1%) wall 69 kB ( 3%) ggc tree PRE: 87.46 ( 3%) usr 0.60 ( 1%) sys 88.62 ( 3%) wall 538859 kB (15%) ggc tree FRE: 47.37 ( 2%) usr 0.58 ( 1%) sys 45.89 ( 2%) wall 274455 kB ( 8%) ggc tree aggressive DCE : 8.96 ( 0%) usr 0.22 ( 1%) sys 8.86 ( 0%) wall 137686 kB ( 4%) ggc tree forward propagate : 10.28 ( 0%) usr 0.10 ( 0%) sys 10.33 ( 0%) wall 56466 kB ( 2%) ggc tree slp vectorization : 25.42 ( 1%) usr 0.16 ( 0%) sys 25.50 ( 1%) wall 436119 kB (12%) ggc complete unrolling : 5.81 ( 0%) usr 0.13 ( 0%) sys 6.07 ( 0%) wall 115165 kB ( 3%) ggc tree vectorization : 1.44 ( 0%) usr 0.05 ( 0%) sys 1.36 ( 0%) wall 31337 kB ( 1%) ggc tree iv optimization: 13.00 ( 0%) usr 0.08 ( 0%) sys 12.94 ( 0%) wall 185893 kB ( 5%) ggc dominance computation : 48.61 ( 2%) usr 0.54 ( 1%) sys 47.65 ( 2%) wall 0 kB ( 0%) ggc expand vars : 18.81 ( 1%) usr 0.09 ( 0%) sys 18.42 ( 1%) wall 167798 kB ( 5%) ggc expand : 116.32 ( 4%) usr 0.61 ( 1%) sys 116.22 ( 4%) wall 1508612 kB (42%) ggc forward prop: 23.01 ( 1%) usr 0.36 ( 1%) sys 23.43 ( 1%) wall 130825 kB ( 4%) ggc CSE : 67.21 ( 2%) usr 0.23 ( 1%) sys 66.28 ( 2%) wall 44439 kB ( 1%) ggc dead store elim1: 20.47 ( 1%) usr 0.10 ( 0%) sys 20.83 ( 1%) wall 103309 kB ( 3%) ggc dead store elim2: 18.99 ( 1%) usr 0.18 ( 0%) sys 20.48 ( 1%) wall 140398 kB ( 4%) ggc CPROP : 52.83 ( 2%) usr 0.33 ( 1%) sys 52.91 ( 2%) wall 336514 kB ( 9%) ggc PRE : 30.60 ( 1%) usr 0.06 ( 0%) sys 30.51 ( 1%) wall 52724 kB ( 1%) ggc CSE 2 : 37.89 ( 1%) usr 0.04 ( 0%) sys 38.88 ( 1%) wall 29785 kB ( 1%) ggc combiner: 80.20 ( 3%) usr 0.23 ( 1%) sys 80.57 ( 3%) wall 400168 kB (11%) ggc integrated RA : 191.13 ( 7%) usr 0.44 ( 1%) sys 190.64 ( 7%) wall 2328880 kB (65%) ggc reload : 65.46 ( 2%) usr 0.09 ( 0%) sys 67.43 ( 2%) wall 193522 kB ( 5%) ggc reload CSE regs : 56.71 ( 2%) usr 0.14 ( 0%) sys 56.49 ( 2%) wall 241394 kB ( 7%) ggc thread pro- & epilogue : 14.43 ( 1%) usr 0.15 ( 0%) sys 14.97 ( 1%) wall 201098 kB ( 6%) ggc final : 44.77 ( 2%) usr 2.80 ( 6%) sys 48.99 ( 2%) wall 367580 kB (10%) ggc rest of compilation : 57.58
[Bug ada/53323] assertion failure on indefinite array of controlled objects and storage pools
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53323 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot ||gnu.org Summary|Compiler bomb with |assertion failure on |indefinite array of |indefinite array of |controlled objects and |controlled objects and |storage pools |storage pools --- Comment #1 from Eric Botcazou 2012-05-12 14:47:36 UTC --- Hopefully the compiler doesn't really bomb by you...
[Bug other/53319] exact subtract of two decimal floating-point values raises FE_INEXACT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53319 --- Comment #5 from Fred J. Tydeman 2012-05-12 15:37:54 UTC --- Another failure: _Decimal32 val, lo; val = 0.e-40DF; lo = 9.e-1DF; val += lo; /* raises FE_INEXACT */ This is with gcc 4.5.1 on Linux Fedora Core 14 on Intel Core 2 in 32-bit mode. Command line options: -std=gnu99 -O0 -pedantic -H -fno-builtin -frounding-math -mieee-fp -ffloat-store -fexcess-precision=standard
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 Steven Bosscher changed: What|Removed |Added CC||steven at gcc dot gnu.org --- Comment #131 from Steven Bosscher 2012-05-12 15:52:54 UTC --- (In reply to comment #130) > There are some obvious questions, like why IRA needs 63% of GGC memory, > and VRP 23% > tree VRP: 65.88 ( 2%) usr 0.73 ( 2%) sys 66.71 >( 2%) wall 862879 kB (24%) ggc Is it possible to do this again with gathering statistics enabled? The only thing I can think of for this would be ASSERT_EXPRs and all the rewriting involved for them. > tree slp vectorization : 25.42 ( 1%) usr 0.16 ( 0%) sys 25.50 > ( 1%) wall 436119 kB (12%) ggc This 12% also seems excessive. > CPROP : 52.83 ( 2%) usr 0.33 ( 1%) sys 52.91 > ( 2%) wall 336514 kB ( 9%) ggc And this one also. I'll see if I can understand and explain this one. > integrated RA : 191.13 ( 7%) usr 0.44 ( 1%) sys 190.64 > ( 7%) wall 2328880 kB (65%) ggc Uh, wow! :-(
[Bug target/53315] simple xtest program generates ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53315 --- Comment #14 from Andi Kleen 2012-05-12 16:04:27 UTC --- I can confirm the simple test program works correctly with Jakub's patch. I'll leave full bootstrap to HJ.
[Bug target/53315] simple xtest program generates ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53315 --- Comment #15 from Andi Kleen 2012-05-12 16:06:00 UTC --- Oh yes and it would be really nice to have those peepholes for xbegin Jakub. I normally use my own macros with asm goto to avoid the ugly code. Do you think machine reorg could be done without slowing down the compiler?
[Bug c/53332] New: #pragma STDC FLOAT_CONST_DECIMAL64 ON done wrong
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53332
Bug #: 53332
Summary: #pragma STDC FLOAT_CONST_DECIMAL64 ONdone wrong
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: tyde...@tybor.com
The following code shows problems with floating-point constants and implied
decimal suffix. x10 ends up as a NaN and x2 ends up as zero (both wrong).
#define __STDC_WANT_DEC_FP__/* Tell implementation that we want Decimal FP
*/
#pragma STDC FLOAT_CONST_DECIMAL64 ON
#include
int main(void){
double d2 = (_Decimal64)((28.DD/3.DD-9.DD) - (31.DD/3.DD-10.DD));/*
decimal FP */
_Decimal64 d10 = (_Decimal64)((28.DD/3.DD-9.DD) - (31.DD/3.DD-10.DD));
double b2 = (_Decimal64)((28.D /3.D -9.D ) - (31.D /3.D -10.D ));/*
binary FP */
_Decimal64 b10 = (_Decimal64)((28.D /3.D -9.D ) - (31.D /3.D -10.D ));
double x2 = (_Decimal64)((28./3.-9.) - (31./3.-10.));/* should be
decimal FP */
_Decimal64 x10 = (_Decimal64)((28./3.-9.) - (31./3.-10.));
if( d2 != x2 ){
(void) printf(" d2 is %g, b2 is %g, x2 is %g\n", (double)d2, (double)b2,
(double)x2 );
}
if( d10 != x10 ){
(void) printf("d10 is %g, b10 is %g, x10 is %g\n", (double)d10,
(double)b10, (double)x10 );
}
return 0;
}
This is on Intel CPUs in both 32-bit and 64-bit mode.
This is with Fedora Core Linux 14 thru 17.
This is with gcc 4.5.1 thru 4.7.0
[Bug target/53315] simple xtest program generates ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53315 --- Comment #16 from Uros Bizjak 2012-05-12 16:31:21 UTC --- (In reply to comment #13) > Like this? Yes, this is OK, after someone confirms that the testcase works as expected on HW or simulator.
[Bug target/53315] simple xtest program generates ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53315 --- Comment #17 from Uros Bizjak 2012-05-12 16:36:39 UTC --- (In reply to comment #15) > Do you think machine reorg could be done without slowing down the compiler? Yes, xbegin RTM pattern can raise a flag that triggers machine reorg (so it won't fire for functions that don't emit xbegin).
[Bug c++/53333] New: Initializer lists in std=c++03 mode must be an error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
Bug #: 5
Summary: Initializer lists in std=c++03 mode must be an error
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: fpellicci...@gmail.com
Hi,
The following code, compiled with -std=c++03 option, emits a warning instead of
an error.
Regards,
Fernando.
//Begin code
#include
#include
void foo( std::string ) {}
void foo( std::pair ) {}
int main( /* int argc, char* argv[] */ )
{
foo( {"k0", "v0"} );
return 0;
}
// End code
#g++ -std=c++03 gcc_warning.cpp
gcc_warning.cpp: In function 'int main()':
gcc_warning.cpp:9:5: warning: extended initializer lists only available with
-std=c++11 or -std=gnu++11 [enabled by default]
gcc_warning.cpp:9:20: error: call of overloaded 'foo()' is ambiguous
gcc_warning.cpp:9:20: note: candidates are:
gcc_warning.cpp:4:6: note: void foo(std::string)
gcc_warning.cpp:5:6: note: void foo(std::pair,
std::basic_string >)
[Bug c++/53333] Initializer lists in std=c++03 mode must be an error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5 Paolo Carlini changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #1 from Paolo Carlini 2012-05-12 16:57:26 UTC --- Seems on purpose to me. Of course changing the warning to an error would be trivial. Maybe Jason can comment on why we have a warning here.
[Bug middle-end/53334] New: ICE in extract_insn, at recog.c:2131
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53334
Bug #: 53334
Summary: ICE in extract_insn, at recog.c:2131
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bernhard.rosenkran...@linaro.org
arm-linux-androideabi-gcc -Wp,-MD,archival/.gzip.o.d -std=gnu99 -Iinclude
-Ilibbb -include include/autoconf.h -D_GNU_SOURCE -DNDEBUG
-D"BB_VER=KBUILD_STR(1.19.4)" -DBB_BT=AUTOCONF_TIMESTAMP -Wall -Wshadow
-Wwrite-strings -Wundef -Wstrict-prototypes -Wunused -Wunused-parameter
-Wunused-function -Wunused-value -Wmissing-prototypes -Wmissing-declarations
-Wdeclaration-after-statement -Wold-style-definition -fno-builtin-strlen
-finline-limit=0 -fomit-frame-pointer -ffunction-sections -fdata-sections
-fno-guess-branch-probability -funsigned-char -static-libgcc
-falign-functions=1 -falign-jumps=1 -falign-labels=1 -falign-loops=1 -Os
-fno-exceptions -Wno-multichar -msoft-float -fpic -ffunction-sections
-fdata-sections -funwind-tables -fstack-protector -Wa,--noexecstack
-Werror=format-security -fno-short-enums -march=armv7-a -mfloat-abi=softfp
-mfpu=neon -include ../../system/core/include/arch/linux-arm/AndroidConfig.h
-I../../system/core/include/arch/linux-arm/ -Wno-psabi -mthumb-interwork
-DANDROID -fmessage-length=0 -W -Wall -Wno-unused -Winit-self -Wpointer-arith
-Werror=return-type -Werror=non-virtual-dtor -Werror=address
-Werror=sequence-point -mtune=cortex-a9 -mcpu=cortex-a9 -O3 -g
-fno-strict-aliasing -DNDEBUG -g -Wstrict-aliasing=2 -fgcse-after-reload
-frerun-cse-after-loop -frename-registers -DNDEBUG -UDEBUG
-I../../bionic/libc/include -I../../bionic/libc/kernel/common
-I../../bionic/libc/arch-arm/include -I../../bionic/libc/kernel/arch-arm
-I../../bionic/libm/include -fno-stack-protector -Wno-error=format-security
-fno-strict-aliasing-D"KBUILD_STR(s)=#s"
-D"KBUILD_BASENAME=KBUILD_STR(gzip)" -D"KBUILD_MODNAME=KBUILD_STR(gzip)" -c -o
archival/gzip.o archival/gzip.c
In file included from include/libbb.h:31:0,
from archival/gzip.c:57:
../../bionic/libc/include/stdlib.h:84:23: warning: declaration of 'abs' shadows
a built-in function [-Wshadow]
static __inline__ int abs(int __n) {
^
../../bionic/libc/include/stdlib.h:88:24: warning: declaration of 'labs'
shadows a built-in function [-Wshadow]
static __inline__ long labs(long __n) {
^
../../bionic/libc/include/stdlib.h:92:29: warning: declaration of 'llabs'
shadows a built-in function [-Wshadow]
static __inline__ long long llabs(long long __n) {
^
archival/gzip.c: In function 'fill_window':
archival/gzip.c:581:1: error: unrecognizable insn:
}
^
(insn 56 55 57 7 (set (reg:CC 24 cc)
(compare:CC (reg/v:SI 155 [ m ])
(const_int 32767 [0x7fff]))) archival/gzip.c:561 -1
(nil))
archival/gzip.c:581:1: internal compiler error: in extract_insn, at
recog.c:2131
Please submit a full bug report,
with preprocessed source if appropriate.
[Bug fortran/53328] [OOP] Ambiguous check for type-bound GENERIC shall ignore PASSed arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53328 --- Comment #2 from Tobias Burnus 2012-05-12 17:59:36 UTC --- Extended examples: http://gcc.gnu.org/ml/fortran/2012-05/msg00060.html
[Bug middle-end/53334] ICE in extract_insn, at recog.c:2131
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53334 --- Comment #1 from Bernhard Rosenkränzer 2012-05-12 18:06:12 UTC --- Created attachment 27388 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27388 Preprocessed source (not yet reduced) $ /opt/android-toolchain-trunk/bin/arm-linux-androideabi-gcc -o test.o -c gzip.i -O3 -march=armv7-a archival/gzip.c: In function 'fill_window': archival/gzip.c:581:1: error: unrecognizable insn: } ^ (insn 52 51 53 7 (set (reg:CC 24 cc) (compare:CC (reg/v:SI 154 [ m ]) (const_int 32767 [0x7fff]))) archival/gzip.c:561 -1 (nil)) archival/gzip.c:581:1: internal compiler error: in extract_insn, at recog.c:2131 Please submit a full bug report,
[Bug c/51294] spurious warning from -Wconversion in C and C++ in conditional expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51294 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|NEW AssignedTo|paolo.carlini at oracle dot |unassigned at gcc dot |com |gnu.org
[Bug middle-end/53334] ICE in extract_insn, at recog.c:2131
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53334 Bernhard Rosenkränzer changed: What|Removed |Added Attachment #27388|0 |1 is obsolete|| --- Comment #2 from Bernhard Rosenkränzer 2012-05-12 18:21:06 UTC --- Created attachment 27389 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27389 Reduced test case $ /opt/android-toolchain-trunk/bin/arm-linux-androideabi-gcc -o test.o -c bug53334.c -O3 -march=armv7-a bug53334.c: In function 'bug53334': bug53334.c:16:1: error: unrecognizable insn: } ^ (insn 60 59 61 4 (set (reg:CC 24 cc) (compare:CC (reg:SI 179 [ D.4130 ]) (const_int 32767 [0x7fff]))) bug53334.c:14 -1 (nil)) bug53334.c:16:1: internal compiler error: in extract_insn, at recog.c:2131
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #132 from Jan Hubicka 2012-05-12 18:32:14 UTC --- > > tree VRP: 65.88 ( 2%) usr 0.73 ( 2%) sys 66.71 > >( 2%) wall 862879 kB (24%) ggc > > Is it possible to do this again with gathering statistics enabled? The I started it some time ago, but it takes a while (it runs out of RAM even on my machine ;) > only thing I can think of for this would be ASSERT_EXPRs and all the > rewriting involved for them. It also might be folding doing too much of temporary stuff. > > tree slp vectorization : 25.42 ( 1%) usr 0.16 ( 0%) sys 25.50 > > ( 1%) wall 436119 kB (12%) ggc > > This 12% also seems excessive. Indeed it is. > > integrated RA : 191.13 ( 7%) usr 0.44 ( 1%) sys 190.64 > > ( 7%) wall 2328880 kB (65%) ggc > > Uh, wow! :-( Tep, sems something degenerate here. IRA is usually not that big of memory hog. Honza
[Bug c/51294] spurious warning from -Wconversion in C and C++ in conditional expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51294
--- Comment #10 from Manuel López-Ibáñez 2012-05-12
18:38:33 UTC ---
Latest patch by Paolo, who run out of time:
http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00861.html
BTW, I think the patch is not wrong, and if fixes some cases, then it is a step
forward.
I think a more complete fix would be something like:
Index: gcc/c-family/c-common.c
===
--- gcc/c-family/c-common.c (revision 187427)
+++ gcc/c-family/c-common.c (working copy)
@@ -2262,10 +2262,15 @@ conversion_warning (tree type, tree expr
location_t loc = EXPR_LOC_OR_HERE (expr);
if (!warn_conversion && !warn_sign_conversion)
return;
+ STRIP_USELESS_TYPE_CONVERSION (expr);
+ /* Don't warn about unsigned char y = 0xff, x = (int) y; */
+ expr = get_unwidened (expr, 0);
+ expr_type = TREE_TYPE (expr);
+
switch (TREE_CODE (expr))
{
case EQ_EXPR:
case NE_EXPR:
case LE_EXPR:
@@ -2294,26 +2299,18 @@ conversion_warning (tree type, tree expr
type, expr_type);
return;
case COND_EXPR:
{
- /* In case of COND_EXPR, if both operands are constants or
- COND_EXPR, then we do not care about the type of COND_EXPR,
- only about the conversion of each operand. */
- tree op1 = TREE_OPERAND (expr, 1);
- tree op2 = TREE_OPERAND (expr, 2);
-
- if ((TREE_CODE (op1) == REAL_CST || TREE_CODE (op1) == INTEGER_CST
-|| TREE_CODE (op1) == COND_EXPR)
- && (TREE_CODE (op2) == REAL_CST || TREE_CODE (op2) == INTEGER_CST
- || TREE_CODE (op2) == COND_EXPR))
- {
- conversion_warning (type, op1);
- conversion_warning (type, op2);
- return;
- }
- /* Fall through. */
+/* In case of COND_EXPR, we do not care about the type of
+ COND_EXPR, only about the conversion of each operand. */
+tree op1 = TREE_OPERAND (expr, 1);
+tree op2 = TREE_OPERAND (expr, 2);
+
+conversion_warning (type, op1);
+conversion_warning (type, op2);
+return;
}
default: /* 'expr' is not a constant. */
if (unsafe_conversion_p (type, expr, true))
warning_at (loc, OPT_Wconversion,
Totally untested, and it lacks testcases, ChangeLog, etc. Neither Paolo nor I
have time to pursue this, so someone new will have to step forward.
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #133 from Jan Hubicka 2012-05-12 19:07:32 UTC --- Another thing to observe is that GGC memory is "just" 4GB. I am not sure where the other 8GB goes when our IL is believed to be major memory consumer and it resists almost completely in GGC memory. perhaps some of the streaming hashtables gets out of control. Also it seems that line number info is about 1GB. It may be win to write better streaming of locations. Current one enables almost no reuse of locators. Honza
[Bug c++/53333] Initializer lists in std=c++03 mode must be an error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5 --- Comment #2 from Marc Glisse 2012-05-12 19:46:08 UTC --- There is -pedantic-errors if you want an error.
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #134 from Jan Hubicka 2012-05-12 20:22:27 UTC --- I tracked down the LTO/WHOPR code size difference. It is EH handling. EH frame is empty for LTO build and quite large for WHOPR. Probably -fno-exceptions getting lots on way to ltrans? With memory stats there don't seem to be major suprises: tree-phinodes.c:129 (allocate_phi_node) 110246192: 0.8% 0: 0.0%3405296: 0.1% 409376: 0.0% 372408 gimple.c:600 (gimple_build_nop) 119935632: 0.8% 0: 0.0% 252144: 0.0% 0: 0.0%2503912 gimplify.c:437 (create_tmp_var_raw) 119589760: 0.8% 0: 0.0%1119200: 0.0% 0: 0.0% 754431 tree-vrp.c:3993 (build_assert_expr_for) 124663296: 0.9% 0: 0.0% 0: 0.0% 0: 0.0%1298576 emit-rtl.c:3731 (make_jump_insn_raw) 118395600: 0.8% 0: 0.0% 11138960: 0.3% 0: 0.0%1619182 tree-streamer-in.c:484 (streamer_alloc_tree) 90340024: 0.6% 0: 0.0% 51300472: 1.5% 4376: 0.0%1420249 simplify-rtx.c:183 (simplify_gen_binary) 153607224: 1.1% 0: 0.0% 619968: 0.0% 0: 0.0%6426133 fold-const.c:1870 (fold_convert_loc) 154700600: 1.1% 0: 0.0% 2160: 0.0% 0: 0.0%3867569 ggc-common.c:253 (ggc_cleared_alloc_ptr_array_tw 80243272: 0.6% 1267966456:15.3% 76357960: 2.2% 11155352: 1.2%1833025 lto/lto.c:281 (lto_read_in_decl_state) 835696: 0.0% 0: 0.0% 163487336: 4.6% 31116920: 3.4%4176305 cfg.c:216 (connect_src) 174302184: 1.2% 623048: 0.0%7861944: 0.2% 133632: 0.0%4542618 cfg.c:226 (connect_dest) 177198328: 1.2%5444688: 0.1%8603432: 0.2% 347648: 0.0%4628047 tree.c:9115 (make_vector_type)206615472: 1.4% 0: 0.0% 6720: 0.0% 0: 0.0%1229894 emit-rtl.c:639 (gen_rtx_MEM) 202133352: 1.4% 0: 0.0%6629016: 0.2% 0: 0.0%8698432 dwarf2cfi.c:386 (copy_cfi_row)212886640: 1.5% 0: 0.0% 0: 0.0% 0: 0.0%1400570 tree-inline.c:4851 (copy_decl_no_change) 211988960: 1.5% 0: 0.0%7283480: 0.2% 0: 0.0%1387268 tree-ssanames.c:78 (init_ssanames)224107008: 1.6% 252869632: 3.1% 1536: 0.0% 153516032:16.6% 309555 lists.c:144 (alloc_EXPR_LIST) 236354400: 1.7% 0: 0.0%5798160: 0.2% 0: 0.0% 10089690 gimple.c:2237 (gimple_copy) 268995784: 1.9% 0: 0.0%4002872: 0.1% 644208: 0.1%2530798 gimple-streamer-in.c:95 (input_gimple_stmt) 272340080: 1.9% 0: 0.0%4356168: 0.1% 917040: 0.1%2550173 tree-inline.c:4331 (copy_tree_r) 286698704: 2.0% 0: 0.0%2053920: 0.1% 0: 0.0%5999420 rtl.c:287 (copy_rtx) 291942896: 2.0% 0: 0.0% 318864: 0.0% 0: 0.0% 12315136 emit-rtl.c:393 (gen_raw_REG) 271761568: 1.9% 0: 0.0% 25188032: 0.7% 0: 0.0%9279675 cselib.c:1896 (cselib_subst_to_values)299291264: 2.1% 0: 0.0% 0: 0.0% 0: 0.0% 12658684 emit-rtl.c:5427 (init_emit) 354914672: 2.5% 19547728: 0.2% 0: 0.0% 102897600:11.1% 132600 cgraph.c:359 (cgraph_allocate_node) 0: 0.0% 0: 0.0% 401297520:11.4% 0: 0.0%1286210 emit-rtl.c:3679 (make_insn_raw) 435416472: 3.0% 0: 0.0%1754496: 0.0% 0: 0.0%6071819 fold-const.c:7624 (build_fold_addr_expr_with_typ 463283920: 3.2% 0: 0.0% 72880: 0.0% 0: 0.0% 11583920 tree-ssanames.c:141 (make_ssa_name_fn)459164960: 3.2% 0: 0.0%5805920: 0.2% 0: 0.0%5812136 cfg.c:142 (alloc_block) 469702464: 3.3% 0: 0.0% 20328672: 0.6% 0: 0.0%4375278 toplev.c:964 (realloc_for_line_map) 0: 0.0% 357908640: 4.3% 1073741848:30.4%184: 0.0% 9 tree.c:1228 (build_int_cst_wide) 1188738504: 8.3% 0: 0.0% 31478720: 0.9% 401175208:43.3% 295230 tree-streamer-in.c:495 (streamer_alloc_tree) 2413661896:16.9% 0: 0.0% 1163973288:32.9% 41183648: 4.4% 28110064 Total14300758513 8262871404 3534486067927547008308001940 source location GarbageFreed Leak OverheadTimes >From explicitely freed GGC mem there are few interesting cases: alias.c:2807 (init_alias_analysis)0: 0.0% 597580152: 7.2% 0
[Bug c++/53333] Initializer lists in std=c++03 mode must be an error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #3 from Jason Merrill 2012-05-12 20:46:09 UTC --- (In reply to comment #2) > There is -pedantic-errors if you want an error. Precisely.
[Bug c++/53333] Initializer lists in std=c++03 mode must be an error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #4 from Fernando Pelliccioni
2012-05-12 20:59:58 UTC ---
For other features of C++11 don't need -pedantic-errors to emit an error.
See..
#include
void foo( std::string && str ) {}
int main( /* int argc, char* argv[] */ )
{
foo( "k0" );
return 0;
}
#g++ -std=c++03 gcc_warning.cpp
gcc_warning.cpp:3:23: error: expected ',' or '...' before '&&' token
It doesn't seem consistent.
What is the criteria?
[Bug c++/53292] multi-threaded (OpenMP) is slower than single-threaded
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53292 --- Comment #9 from FH 2012-05-12 21:27:31 UTC --- Well... I tested an OpenMP benchmarch (design to demonstrate OpenMP performances) found on the web : multi-threaded (OpenMP) is again slower than single-threaded. I looked at coding with pthreads : same thing. So, I have a dual-core hyper-threaded PC : I end up with multi-threaded applications slower than single-threaded and this is supposed to be a "normal" behavior ?!... Anyway this is still illogical to me ?!?!
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #135 from Jan Hubicka 2012-05-12 21:33:36 UTC --- ... and mem reports on WPA stage: toplev.c:964 (realloc_for_line_map) 0: 0.0% 89473168: 9.4% 268435472:10.3%160: 0.0% 8 cgraph.c:359 (cgraph_allocate_node) 0: 0.0% 0: 0.0% 401297520:15.3% 0: 0.0%1286210 tree.c:1228 (build_int_cst_wide) 1188709752:33.7% 0: 0.0% 22765400: 0.9% 399425424:83.1% 208540 tree-streamer-in.c:495 (streamer_alloc_tree) 1950272016:55.3% 0: 0.0% 1143907104:43.7% 41182080: 8.6% 22462122 Total3527995024956449616 2618397893480920037 47749265 source location GarbageFreed Leak OverheadTimes So about 50% trees, 15% cgraph nodes (I do have plans how to get those smaller), 10% linemaps (I wonder if simple cache would not save a lot of locators), 5% inline summaries I wonder who is producing that 1GB of temporary integer nodes? Someone abusing them for counting too much? It is there before IPA, so it seems to be streaming or type machinery. Heap vectors: source locationLeak Peak Times --- ipa-reference.c:186 (set_reference_optimization_ 10289688:10.5% 11240664 13: 0.0% lto-cgraph.c:118 (lto_cgraph_encoder_encode) 12756976:13.0% 23348152 26300: 0.2% ipa-ref.c:55 (ipa_record_reference)13593072:13.8% 41932432 1000565: 6.0% passes.c:2214 (execute_one_pass) 21214520:21.5% 41942992 557113: 3.3% ipa-inline-analysis.c:804 (inline_summary_alloc) 30037064:30.5% 30037064 1: 0.0% Total 98450004 16768143 Bitmap Overall Allocated PeakLeak searched search itr - ipa-reference.c:911 (propagate) 37274131244280 3122372031223720 0 0 ipa-reference.c:739 (propagate) 32925813341680 3058960 3058960 0 0 ipa-reference.c:923 (propagate) 37218625153920 2513852025138520 0 0 ipa-reference.c:417 (init_function_info)48726319809560 1980956019809560551335 ipa-reference.c:418 (init_function_info)48726319584680 1958468019584680 79 45 ipa-reference.c:747 (propagate) 32935113229360 3053920 3053920 0 0 Kind Nodes Bytes --- decls11059354 1770384416 types6163492 1035466656 blocks 1 80 stmts 0 0 refs5243 267944 exprs1826905 7444 constants2198755 72290570 identifiers 538891 21555640 vecs 208540 412624304 binfos 1420249 141631744 ssa names111 8880 constructors 1591693820056 random kinds 3270917 130837088 Honza
[Bug libstdc++/53263] priority_queue is very slow if -D_GLIBCXX_DEBUG is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53263 --- Comment #12 from Paolo Carlini 2012-05-12 21:41:15 UTC --- Francois, please double check that now you are ok, thanks.
[Bug c++/53333] Initializer lists in std=c++03 mode must be an error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #5 from Marc Glisse 2012-05-12 21:57:05
UTC ---
(In reply to comment #4)
> For other features of C++11 don't need -pedantic-errors to emit an error.
[...]
> It doesn't seem consistent.
> What is the criteria?
Allowing {} is a rather isolated extension that doesn't interfere much with
anything. Rvalue reference is perhaps the worst example you could pick as it
changes the behavior all over the place and can easily break code. I don't know
if there are official criteria, the choices may be questionable, but I don't
see that it matters that much...
[Bug c++/53181] static_assert sees as non constant the comparison between a constexpr and a template argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53181 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-05-12 Ever Confirmed|0 |1 --- Comment #1 from Paolo Carlini 2012-05-12 22:16:36 UTC --- Confirmed.
[Bug c++/51829] decltype() deduces non-const but only in a template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51829 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-05-12 CC|bugs at sehe dot nl | Ever Confirmed|0 |1 --- Comment #4 from Paolo Carlini 2012-05-12 22:46:31 UTC --- Still waiting.
[Bug c++/52767] Default inits for structs in struct initializer lists: wrong "this" pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52767 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.6.2, 4.7.0, 4.7.1, 4.8.0 Resolution||FIXED --- Comment #2 from Paolo Carlini 2012-05-12 23:03:56 UTC --- Confirmed fixed.
[Bug c++/53308] AIX 5.3 segmentation fault with basic_ofstream, pthread and -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53308 Paolo Carlini changed: What|Removed |Added CC||dje at gcc dot gnu.org --- Comment #1 from Paolo Carlini 2012-05-12 23:13:12 UTC --- David, this one is also for you to have a look. Thanks!
[Bug c++/53055] ICE in cp_build_indirect_ref, at cp/typeck.c:2836
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53055 --- Comment #4 from Marc Glisse 2012-05-12 23:33:16 UTC --- Created attachment 27390 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27390 patch 1 ice.cc:2:15: error: pointer to member must be on the right side of '->*' int i = p ->* p ; ^ so the caret is on the wrong side of the operator.
[Bug c++/53333] Initializer lists in std=c++03 mode must be an error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #6 from Fernando Pelliccioni
2012-05-12 23:53:30 UTC ---
(In reply to comment #5)
> (In reply to comment #4)
> > For other features of C++11 don't need -pedantic-errors to emit an error.
> [...]
> > It doesn't seem consistent.
> > What is the criteria?
>
> Allowing {} is a rather isolated extension that doesn't interfere much with
> anything. Rvalue reference is perhaps the worst example you could pick as it
> changes the behavior all over the place and can easily break code. I don't
> know
> if there are official criteria, the choices may be questionable, but I don't
> see that it matters that much...
I got it. Thanks!
[Bug c++/53308] AIX 5.3 segmentation fault with basic_ofstream, pthread and -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53308 David Edelsohn changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-05-13 Ever Confirmed|0 |1 --- Comment #2 from David Edelsohn 2012-05-13 00:04:15 UTC --- I do not have GCC 4.4.7 easily available, but I cannot duplicate the error with GCC 4.4.3. GCC 4.4 series is very old. This could be due to some AIX 5.3 update.
[Bug c++/51829] decltype() deduces non-const but only in a template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51829 --- Comment #5 from Seth Heeren 2012-05-13 00:05:00 UTC --- On 13-05-12 00:46, paolo.carlini at oracle dot com wrote: > Still waiting. Really. Well, to be honest, I can't afford to spend even more time minimizing that any further. I have to pick priorities. For quick win, of course, you could check whether the problem still exists with GCC 4.7 or dev versions. It might have been fixed in the process of other development/fixes. God knows I had spent over 6 hours trying to minimize that by manually decimating the preprocessed sources even before initially posting the report. And it wasn't even my own bug; it was a support call on the [spirit-general] list. I don't think it is worth my time to **learn** how to further reduce the testcase further, since that seems to be a highly specialized craft and, tools could do a good job. I'd be rather surprised if the GCC team didn't have just such tools, as well as people skilled and experienced in using them. All of the above would require a lot of time on my side, and sadly I don't have it. Regards Seth
[Bug debug/53235] [4.8 Regression] 20120504 broke -fdebug-types-section
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53235 --- Comment #5 from Jason Merrill 2012-05-13 03:37:42 UTC --- Author: jason Date: Sun May 13 03:37:38 2012 New Revision: 187435 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187435 Log: PR debug/53235 * dwarf2out.c (build_local_stub): Prefer DW_AT_signature for comdat types. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c
[Bug target/48009] Bootstrap failure: c++locale.cc: invalid conversion from 'const char*' to 'char*'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48009 --- Comment #6 from Daniel Richard G. 2012-05-13 05:11:32 UTC --- (In reply to comment #5) > AIX 4.3 is extremely old and support was withdrawn a while ago. I am surprised > that anyone is trying to build recent versions of GCC for it. If someone wants > to develop a fixincludes patch, I can review it. The problem undoubtedly > exists, but can be worked around manually. My employer favors the use of older systems for software builds, as Unix is generally solid on forward compatibility and this prevents awkward scenarios where a customer is running an older OS than we are. Continuing GCC support is one of the downsides of this approach, of course. I wouldn't be surprised if support for AIX 4.3 is obsoleted soon, but I'd like to ensure that everything is working before that point. (I didn't follow up Solaris 8 as aggressively, and now I'm trying to get some fixes in even as the support is being ripped out of 4.8.) I can provide a unified-diff patch for the header in question; I don't know how to hack fixincludes. (If anyone can point me to a fixinclude that does the same kind of one-line change elsewhere, I could work with that...)
