[Bug target/56726] i386: MALLOC_ABI_ALIGNMENT is too small (usually)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56726 --- Comment #6 from Chip Salzenberg chip at pobox dot com 2013-03-29 06:05:19 UTC --- May I have this accepted?
[Bug fortran/55591] strict-aliasing Fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55591 --- Comment #5 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2013-03-29 06:13:38 UTC --- (In reply to comment #3) Untested (but successfully compiled) patch: --- a/gcc/fortran/options.c +++ b/gcc/fortran/options.c @@ -170,4 +170,6 @@ gfc_init_options (unsigned int decoded_options_count, set_default_std_flags (); + flag_strict_aliasing = -1; + /* Initialize cpp-related options. */ gfc_cpp_init_options (decoded_options_count, decoded_options); @@ -275,4 +277,8 @@ gfc_post_options (const char **pfilename) gfc_option.flag_whole_file = 1; + /* By default use strict-aliasing semantics. */ + if (flag_strict_aliasing == -1) +flag_strict_aliasing = 1; + /* Fortran allows associative math - but we cannot reassociate if we want traps or signed zeros. Cf. also flag_protect_parens. */ what about applying this to stage 1 4.9 ?
[Bug sanitizer/55561] TSAN: provide a TSAN instrumented libgomp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Summary|TSAN: Fortran/OMP yields|TSAN: provide a TSAN |false positives |instrumented libgomp --- Comment #40 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2013-03-29 08:11:17 UTC --- I'm updating the summary for this bug. It is my impression that tsan omp now work well together, but in order for this to be useful, a tsan instrumented libgomp needs to be linked in. In my opinion, it would be great if gcc would build to versions of the runtime library (one standard, one tsan instrumented) and link the tsan instrumented libgomp as needed. As a side effect, it will provide good checking for the libgomp library. I also believe this is a more sustainable approach than writing wrappers for all omp functionality.
[Bug web/56063] [bugzilla] last reconfirmed : now
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56063 --- Comment #9 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2013-03-29 08:12:23 UTC --- (In reply to comment #7) What I could do is to hide the calendar button and add a Now link instead. I think this would be really appreciated.
[Bug rtl-optimization/31021] gfortran 20% slower than ifort on CP2K computational kernel
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31021 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Depends on||37150 --- Comment #16 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2013-03-29 08:15:30 UTC --- I believe this is actually testing the same kernel (maybe a slightly older variant) as in PR37150. I would rather revisit this once PR37150 has been fixed.
[Bug fortran/56378] [4.6/4.7/4.8 Regression] ICE with C_LOC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56378 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Summary|[4.6/4.7/4.8/4.9|[4.6/4.7/4.8 Regression] |Regression] ICE with C_LOC |ICE with C_LOC --- Comment #10 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2013-03-29 08:23:59 UTC --- Fixed on trunk (4.9.0): PR56378.f90:13.23: call lat_to_c2 (c_loc(fvec2vec(ic, n1_ic))) 1 Error: Argument X at (1) to C_LOC shall have either the POINTER or the TARGET attribute
[Bug middle-end/47341] unnecessary versioning in the vectorizer, not implemented affine-affine test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47341 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Last reconfirmed|2012-06-30 11:21:06 |2013-03-29 CC||Joost.VandeVondele at mat ||dot ethz.ch --- Comment #5 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2013-03-29 08:29:53 UTC --- still versioning for trunk 4.9.0
[Bug fortran/25708] [F95] Module loading is not good at all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25708 --- Comment #22 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2013-03-29 08:33:31 UTC --- Improved in part by http://gcc.gnu.org/ml/fortran/2013-03/msg00143.html as r197124 for 4.9.0
[Bug target/56734] Even simple exceptions cause a segmentation fault in my build of gcc on Solaris 10.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56734 --- Comment #6 from Marc Girod marc.girod at gmail dot com 2013-03-29 08:39:38 UTC --- I can acknowledge that installing binutils 2.23.2 solved my problem with gcc 4.7.2
[Bug fortran/34640] ICE when assigning item of a derived-component to a pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34640 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Last reconfirmed|2009-04-06 10:57:29 |2013-03-29 CC||Joost.VandeVondele at mat ||dot ethz.ch --- Comment #22 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2013-03-29 08:40:06 UTC --- Still affects trunk 4.9.0 values = d(:)%value ^ 0x99687f crash_signal ../../gcc/gcc/toplev.c:332 0x610d2b gfc_trans_pointer_assignment(gfc_expr*, gfc_expr*) ../../gcc/gcc/fortran/trans-expr.c:6337 0x5e0d4a trans_code ../../gcc/gcc/fortran/trans.c:1439 0x6083bd gfc_generate_function_code(gfc_namespace*) ../../gcc/gcc/fortran/trans-decl.c:5392 0x5e19c1 gfc_generate_module_code(gfc_namespace*) ../../gcc/gcc/fortran/trans.c:1755 0x59efc8 translate_all_program_units ../../gcc/gcc/fortran/parse.c:4453 0x59efc8 gfc_parse_file() ../../gcc/gcc/fortran/parse.c:4663 0x5dc355 gfc_be_parse_file ../../gcc/gcc/fortran/f95-lang.c:189 Please submit a full bug report,
[Bug libfortran/51119] MATMUL slow for large matrices
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51119 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Last reconfirmed|2011-11-14 00:00:00 |2013-03-29 --- Comment #10 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2013-03-29 08:47:39 UTC --- What about compiling the fortran runtime library with vectorization, and all the fancy options that come with graphite (loop-blocking in particular). If they don't work for a matrix multiplication pattern what's their use ? Further naivety would be to provide an lto'ed runtime, allowing matrix multiplication to be inlined for known small bounds ... kind of the ultimate dogfooding ?
[Bug tree-optimization/34940] contained subroutines called only once are not inlined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34940 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Last reconfirmed|2012-06-29 11:27:01 |2013-03-29 CC||Joost.VandeVondele at mat ||dot ethz.ch Known to fail||4.9.0 --- Comment #16 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2013-03-29 08:58:42 UTC --- (In reply to comment #6) Function is static, that seems OK. We inline it with ./xgcc -B ./ -O2 t.f90 -S --param large-stack-frame=2000 We are somewhat stupid here, since the call happens all the time and thus stack frame growth limits don't need to apply. I can implement this if this is common case for fortran. How commonly we run into these io structs? We can also bump large stack limits to make fortran I/O to fit in. Honza I think it would make sense to implement this, if easy enough. It could be a common pattern for contained subroutines and private module procedures
[Bug middle-end/41453] use INTENT(out) for optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41453 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Last reconfirmed|2012-06-29 00:00:00 |2013-03-29 CC||Joost.VandeVondele at mat ||dot ethz.ch --- Comment #2 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2013-03-29 09:04:29 UTC --- and 4.9.0
[Bug middle-end/40194] fortran rules for optimizing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40194 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||Joost.VandeVondele at mat ||dot ethz.ch Resolution||FIXED --- Comment #11 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2013-03-29 09:07:25 UTC --- Fixed.
[Bug libgomp/50175] data race with OMP barrier
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50175 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||Joost.VandeVondele at mat ||dot ethz.ch Resolution||DUPLICATE --- Comment #2 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2013-03-29 09:11:10 UTC --- This is at best a dup of PR40362, and likely fixed for the linux futex version as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561#c38 *** This bug has been marked as a duplicate of bug 40362 ***
[Bug libgomp/40362] openmp: some libgomp functions trigger data races
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40362 --- Comment #15 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2013-03-29 09:11:10 UTC --- *** Bug 50175 has been marked as a duplicate of this bug. ***
[Bug lto/47532] valgrind errors while compiling with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47532 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Status|NEW |RESOLVED CC||Joost.VandeVondele at mat ||dot ethz.ch Resolution||FIXED --- Comment #2 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2013-03-29 09:13:28 UTC --- seems fixed.
[Bug rtl-optimization/56776] New: valgrind errors within ira
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56776 Bug #: 56776 Summary: valgrind errors within ira Classification: Unclassified Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: joost.vandevond...@mat.ethz.ch The famously short Fortran program: cat test.f90 END yields errors in ira: valgrind --tool=memcheck --trace-children=yes gfortran -c test.f90 ==7625== Conditional jump or move depends on uninitialised value(s) ==7625==at 0x882AF7: make_object_born(ira_object*) (sparseset.h:147) ==7625==by 0x882C3A: mark_pseudo_regno_live(int) (ira-lives.c:294) ==7625==by 0x883C34: process_bb_node_lives(ira_loop_tree_node*) (ira-lives.c:1321) ==7625==by 0x86D4A8: ira_traverse_loop_tree(bool, ira_loop_tree_node*, void (*)(ira_loop_tree_node*), void (*)(ira_loop_tree_node*)) (ira-build.c:1604) ==7625==by 0x884811: ira_create_allocno_live_ranges() (ira-lives.c:1595) ==7625==by 0x86DD84: ira_build() (ira-build.c:3198) ==7625==by 0x866792: rest_of_handle_ira() (ira.c:4473) ==7625==by 0x8F0626: execute_one_pass(opt_pass*) (passes.c:2330) ==7625==by 0x8F0A54: execute_pass_list(opt_pass*) (passes.c:2378) ==7625==by 0x8F0A66: execute_pass_list(opt_pass*) (passes.c:2379) ==7625==by 0x6C2637: expand_function(cgraph_node*) (cgraphunit.c:1640) ==7625==by 0x6C4749: compile() (cgraphunit.c:1833) ==7625== ==7625== Use of uninitialised value of size 8 ==7625==at 0x882C22: mark_pseudo_regno_live(int) (sparseset.h:147) ==7625==by 0x883C34: process_bb_node_lives(ira_loop_tree_node*) (ira-lives.c:1321) ==7625==by 0x86D4A8: ira_traverse_loop_tree(bool, ira_loop_tree_node*, void (*)(ira_loop_tree_node*), void (*)(ira_loop_tree_node*)) (ira-build.c:1604) ==7625==by 0x884811: ira_create_allocno_live_ranges() (ira-lives.c:1595) ==7625==by 0x86DD84: ira_build() (ira-build.c:3198) ==7625==by 0x866792: rest_of_handle_ira() (ira.c:4473) ==7625==by 0x8F0626: execute_one_pass(opt_pass*) (passes.c:2330) ==7625==by 0x8F0A54: execute_pass_list(opt_pass*) (passes.c:2378) ==7625==by 0x8F0A66: execute_pass_list(opt_pass*) (passes.c:2379) ==7625==by 0x6C2637: expand_function(cgraph_node*) (cgraphunit.c:1640) ==7625==by 0x6C4749: compile() (cgraphunit.c:1833) ==7625==by 0x6C4A74: finalize_compilation_unit() (cgraphunit.c:2119)
[Bug rtl-optimization/56776] [4.8/4.9 Regression] valgrind errors within ira
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56776 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added CC||Joost.VandeVondele at mat ||dot ethz.ch Known to work||4.7.3 Summary|valgrind errors within ira |[4.8/4.9 Regression] ||valgrind errors within ira Known to fail||4.8.1, 4.9.0 --- Comment #1 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2013-03-29 09:23:00 UTC --- seems absent in 4.7
[Bug fortran/45337] gfortran accepts pointer initialization of DT dummy arguments w/ INTENT(OUT)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45337 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Last reconfirmed|2010-08-19 09:47:08 |2013-03-29 CC||Joost.VandeVondele at mat ||dot ethz.ch --- Comment #12 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2013-03-29 09:27:23 UTC --- comment #11 still fails on 4.9 trunk.
[Bug fortran/56735] [4.6/4.7/4.8/4.9 Regression] Namelist Read Error with question marks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56735 --- Comment #7 from Tobias Burnus burnus at gcc dot gnu.org 2013-03-29 09:34:29 UTC --- Author: burnus Date: Fri Mar 29 09:32:57 2013 New Revision: 197228 URL: http://gcc.gnu.org/viewcvs?rev=197228root=gccview=rev Log: 2013-03-29 Tobias Burnus bur...@net-b.de PR fortran/56735 * io/list_read.c (nml_query): Only abort when an error occured. (namelist_read): Add goto instead of falling through. 2013-03-29 Tobias Burnus bur...@net-b.de PR fortran/56735 * gfortran.dg/namelist_80.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/namelist_80.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/libgfortran/io/list_read.c
[Bug libfortran/56737] [4.6/4.7/4.8/4.9 Regression] Wrong I/O result with format cache for Hollerith strings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56737 --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2013-03-29 09:38:20 UTC --- Author: burnus Date: Fri Mar 29 09:37:37 2013 New Revision: 197229 URL: http://gcc.gnu.org/viewcvs?rev=197229root=gccview=rev Log: 2013-03-29 Tobias Burnus bur...@net-b.de PR fortran/56737 * io/format.c (parse_format): With caching, copy dtp-format string. (save_parsed_format): Use dtp-format directly without copying. 2013-03-29 Tobias Burnus bur...@net-b.de PR fortran/56737 * testsuite/gfortran.dg/fmt_cache_3.f90: New. (Plus: Move fortran/ChangeLog item to libgfortran/ChangeLog) Added: trunk/gcc/testsuite/gfortran.dg/fmt_cache_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/io/format.c
[Bug libfortran/56737] [4.6/4.7/4.8/4.9 Regression] Wrong I/O result with format cache for Hollerith strings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56737 --- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org 2013-03-29 09:40:13 UTC --- Author: burnus Date: Fri Mar 29 09:39:47 2013 New Revision: 197230 URL: http://gcc.gnu.org/viewcvs?rev=197230root=gccview=rev Log: 2012-03-29 Tobias Burnus bur...@net-b.de PR fortran/56737 * io/format.c (parse_format_list): Also cache FMT_STRING. (parse_format): Update call. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/format.c
[Bug fortran/41137] inefficient zeroing of an array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41137 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Last reconfirmed|2009-11-01 16:21:21 |2013-03-29 CC||Joost.VandeVondele at mat ||dot ethz.ch Blocks||38654 --- Comment #14 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2013-03-29 09:46:53 UTC --- The code in comment #0 is actually a frontend optimization, PR38654. Noteworthy that the optimizers (ipa-cp plus others) do the right thing for the tester in comment #1 at -O3 (but can't do this in the general case).
[Bug bootstrap/56752] GCC fails to bootstrap on Debian GNU/Linux 7.0 (wheezy) when 32-bit libraries aren't installed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56752 --- Comment #5 from David Starner prosfilaes at gmail dot com 2013-03-29 10:00:04 UTC --- You could check that right after building the multilib compiler before trying to compile real code. That would at least give an error message that said what was wrong, instead of one that's opaque to the causal installer.
[Bug tree-optimization/25621] Missed optimization when unrolling the loop (splitting up the sum) (only with -ffast-math)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25621 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added CC||Joost.VandeVondele at mat ||dot ethz.ch Depends on||53947 --- Comment #12 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2013-03-29 10:07:06 UTC --- This has become much more a vectorizer problem. Basically ifort generates code that is twice as fast for routine S31 of the initial comment. Given that this is a common dot product, it might be good to see why that happens. Both compilers fail to notice that S32 is basically the same code hand-unrolled. Tested with the code in comment #6 (without inlining) gfortran -march=native -ffast-math -O3 -fno-inline PR25621.f90 ./a.out default loop 0.564915006 hand optimized loop 0.744886016 ifort -xHost -O3 -fno-inline PR25621.f90 ./a.out default loop 0.3779430 hand optimized loop 0.5799110
[Bug fortran/40958] module files too large
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40958 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added CC||Joost.VandeVondele at mat ||dot ethz.ch --- Comment #7 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2013-03-29 10:17:20 UTC --- see part 2/3 in the message here: http://gcc.gnu.org/ml/fortran/2013-03/msg00125.html
[Bug fortran/36933] unneeded temporary with derived type containing an array as argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36933 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Status|NEW |RESOLVED CC||Joost.VandeVondele at mat ||dot ethz.ch Resolution||FIXED --- Comment #10 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2013-03-29 10:20:31 UTC --- The original problem is fixed. The problem in comment #3 seems not worth fixing, and would require alias analysis in the FE.
[Bug fortran/39304] ICE with MATMUL, specific/generic functions and rank checking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39304 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||Joost.VandeVondele at mat ||dot ethz.ch Depends on||34640 Resolution||DUPLICATE Known to fail||4.9.0 --- Comment #14 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2013-03-29 10:31:19 UTC --- This is fails with 4.9.0, but I think it has become a pure dup of PR34640 *** This bug has been marked as a duplicate of bug 34640 ***
[Bug fortran/34640] ICE when assigning item of a derived-component to a pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34640 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Blocks||39304 CC||Huub.van-Dam at stfc dot ||ac.uk --- Comment #23 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2013-03-29 10:31:19 UTC --- *** Bug 39304 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/40168] missing unrolling/scalarization/reassoc/free
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40168 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Last reconfirmed|2009-12-18 14:45:13 |2013-03-29 CC||Joost.VandeVondele at mat ||dot ethz.ch --- Comment #21 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2013-03-29 10:50:49 UTC --- So, the testcase in comment #14 is indeed still (4.9.0) yielding the 324 multiplies for subroutine S2, instead of the more optimal 192 as shown in S1. Ifort also results in 324 multiplies, but is able to do a couple of them with mulpd instead of mulsd. So the common subexpressions are still not found.
[Bug tree-optimization/14741] graphite with loop blocking and interchanging doesn't optimize a matrix multiplication loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14741 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Last reconfirmed|2006-04-23 17:57:20 |2013-03-29 CC||Joost.VandeVondele at mat ||dot ethz.ch Blocks||51119 Summary|missing transformations |graphite with loop blocking |lead to poorly optimized|and interchanging doesn't |code|optimize a matrix ||multiplication loop Known to fail|tree-ssa|4.9.0 --- Comment #17 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2013-03-29 11:03:40 UTC --- With 4.9 trunk using gfortran -ffast-math -O3 -march=native -fgraphite -floop-interchange -floop-block PR14741.f90 The testcase still runs about 8x slower than what ifort produces at -O3 -xHost. This is too bad, and in my opinion blocks as simple solution for PR51119
[Bug debug/35118] ICE in mem_loc_descriptor, at dwarf2out.c:8974
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35118 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||Joost.VandeVondele at mat ||dot ethz.ch Resolution||FIXED --- Comment #3 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2013-03-29 11:09:49 UTC --- testcase doesn't compile with trunk anymore. I suspect the original problem is fixed. If not, please provide an updated testcase.
[Bug lto/56777] New: bad grammar in fwhole-program documentation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56777 Bug #: 56777 Summary: bad grammar in fwhole-program documentation Classification: Unclassified Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: jtaylor.deb...@gmail.com http://gcc.gnu.org/onlinedocs//gcc/Optimize-Options.html#Optimize-Options -fwhole-program ... In combination with -flto using this option should not be used. it should probably be : In combination with -flto this option should not be used. or This option should not be used in combination with -flto.
[Bug tree-optimization/56778] New: ICE on several benchmarks after r196775.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56778
Bug #: 56778
Summary: ICE on several benchmarks after r196775.
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ysrum...@gmail.com
We got ICE on several benchmarks that can be reproduced on the simple
test-case:
typedef struct {
float a,b,c;
} S;
S * arr[100];
void bar (float *in[], int n)
{
int i;
for (i=0; in; i++)
(*in)[i] = -arr[i]-b;
}
and compile on x86 with following options:
-march=core-avx2 -O3
[Bug libstdc++/56779] New: libstdc++.so: undefined reference to `libintl_textdomain'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56779 Bug #: 56779 Summary: libstdc++.so: undefined reference to `libintl_textdomain' Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: tre...@sourcemage.org Created attachment 29749 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29749 full compile log for gcc-4.8.0 libstdc++.so has references to libintl_textdomain, but intl is not listed as a needed library $ readelf -d /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/../../../../lib/libstdc++.so |grep NEEDED 0x0001 (NEEDED) Shared library: [libm.so.6] 0x0001 (NEEDED) Shared library: [libc.so.6] 0x0001 (NEEDED) Shared library: [ld-linux-x86-64.so.2] 0x0001 (NEEDED) Shared library: [libgcc_s.so.1] $ readelf -s /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/../../../../lib/libstdc++.so |grep libintl 252: 0 NOTYPE GLOBAL DEFAULT UND libintl_gettext 1825: 0 NOTYPE GLOBAL DEFAULT UND libintl_textdomain 2592: 0 NOTYPE GLOBAL DEFAULT UND libintl_bindtextdomain 961: 0 NOTYPE GLOBAL DEFAULT UND libintl_gettext 2534: 0 NOTYPE GLOBAL DEFAULT UND libintl_textdomain 3301: 0 NOTYPE GLOBAL DEFAULT UND libintl_bindtextdomain This causes major problems when trying to link a C++ program eg: g++ -march=native -mtune=native -m64 -pipe -ffast-math -funroll-loops -O3 -s -Wl,--as-needed -lpthread -lintl -pthread -Wl,-rpath,'$ORIGIN/../lib' -Wl,-rpath,'$ORIGIN/../intl' -Wl,--version-script,empty.vers /var/git/x86_64/firebird3/temp/Release/gpre/hsh.o /var/git/x86_64/firebird3/temp/Release/gpre/jrdmet.o /var/git/x86_64/firebird3/temp/Release/gpre/cme.o /var/git/x86_64/firebird3/temp/Release/gpre/par.o /var/git/x86_64/firebird3/temp/Release/gpre/sqe.o /var/git/x86_64/firebird3/temp/Release/gpre/msc.o /var/git/x86_64/firebird3/temp/Release/gpre/c_cxx.o /var/git/x86_64/firebird3/temp/Release/gpre/exp.o /var/git/x86_64/firebird3/temp/Release/gpre/movg.o /var/git/x86_64/firebird3/temp/Release/gpre/pat.o /var/git/x86_64/firebird3/temp/Release/gpre/cmp.o /var/git/x86_64/firebird3/temp/Release/gpre/gpre.o /var/git/x86_64/firebird3/temp/Release/gpre/sql.o /var/git/x86_64/firebird3/temp/Release/gpre/int_cxx.o /var/git/x86_64/firebird3/temp/Release/gpre/cmd.o /var/git/x86_64/firebird3/temp/Release/gpre/boot/gpre_meta_boot.o /var/git/x86_64/firebird3/temp/Release/yvalve/gds.o /var/git/x86_64/firebird3/temp/Release/common.a -o /var/git/x86_64/firebird3/gen/Release/firebird/bin/gpre_boot -L/var/git/x86_64/firebird3/gen/Release/firebird/lib -lpthread -latomic_ops -lm -ldl -lcurses /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/../../../../lib/libstdc++.so: undefined reference to `libintl_gettext' /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/../../../../lib/libstdc++.so: undefined reference to `libintl_textdomain' /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/../../../../lib/libstdc++.so: undefined reference to `libintl_bindtextdomain' collect2: error: ld returned 1 exit status gettext In some cases this can be solved by setting LDFLAGS=-lintl, but in other cases the makefiles ignore this setting and fail. gcc was configure with --disable-nls, but gettext-0.18.2 was on the system,and installed /usr/lib/libasprintf.a /usr/lib/libasprintf.la /usr/lib/libasprintf.so /usr/lib/libasprintf.so.0 /usr/lib/libasprintf.so.0.0.0 /usr/lib/libgettextlib-0.18.2.so /usr/lib/libgettextlib.la /usr/lib/libgettextlib.so /usr/lib/libgettextpo.a /usr/lib/libgettextpo.la /usr/lib/libgettextpo.so /usr/lib/libgettextpo.so.0 /usr/lib/libgettextpo.so.0.5.2 /usr/lib/libgettextsrc-0.18.2.so /usr/lib/libgettextsrc.la /usr/lib/libgettextsrc.so /usr/lib/libintl.a /usr/lib/libintl.la /usr/lib/libintl.so /usr/lib/libintl.so.8 /usr/lib/libintl.so.8.1.2 The output from configure includes the following: checking whether NLS is requested... no checking build system type... checking for msgfmt... x86_64-pc-linux-gnu checking for x86_64-pc-linux-gnu-gcc... gcc x86_64-pc-linux-gnu checking host system type... x86_64-pc-linux-gnu checking target system type... /usr/bin/msgfmt checking for gmsgfmt... x86_64-pc-linux-gnu checking target system type... /usr/bin/msgfmt checking for xgettext... x86_64-pc-linux-gnu checking for x86_64-pc-linux-gnu-ar... ar checking for x86_64-pc-linux-gnu-ranlib... ranlib checking for x86_64-pc-linux-gnu-gcc... gcc x86_64-pc-linux-gnu checking for x86_64-pc-linux-gnu-gcc... gcc checking for a BSD-compatible install... /bin/install -c checking whether build
[Bug c++/53330] new() operator can return NULL on a zero-length allocation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53330 --- Comment #2 from Adam Borowski kilobyte at angband dot pl 2013-03-29 13:13:21 UTC --- Created attachment 29750 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29750 updated testcase Updated testcase: it checks for invalid pointers (by freeing them), and returns an exit code (if it won't crash first).
[Bug other/28315] gcc doesn't use locale for default input charset
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28315 Laszlo Ersek lacos at caesar dot elte.hu changed: What|Removed |Added CC||bonzini at gnu dot org, ||lacos at caesar dot elte.hu --- Comment #1 from Laszlo Ersek lacos at caesar dot elte.hu 2013-03-29 13:17:21 UTC --- gcc has defaulted to UTF-8 rather than the locale's codeset in _cpp_default_encoding() [libcpp/charset.c] since the following 2004 hunk: http://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=d856c8a6#patch25 ( The default encoding is selected for both input_charset (overrideable with -finput-charset) and narrow_charset (overrideable with -fexec-charset): cpp_create_reader() [libcpp/init.c] ~ narrow_charset = _cpp_default_encoding() ~ input_charset = _cpp_default_encoding() The overrides are implemented in c_common_handle_option() [gcc/c-family/c-opts.c]. ) Considering the encodings of source files in the wild that gcc has been used to compile in the last 8+ years (ie. while the 0 has been in place): - UTF-8 (of which 7-bit ASCII is a subset) worked. - Any non-UTF-8 encoding that utilized the MSB (eg. ISO-8859-2) required the -finput-charset option. People who would have originally wanted gcc to take that codeset from the locale were probably *developing* the source code in question, hence they could easily add the -finput-charset to their makefiles. Much of the world must have migrated to UTF-8-encoded locales by now. Reverting the 0 would: - not affect people with such a distro-default locale who build UTF-8 / ASCII sources: their locale codeset matches the current hardwired default, - not affect people building sources with non-UTF-8 8-bit codesets (eg. ISO-8859-2), since those projects already have to use the -finput-charset options in their makefiles, - affect people who have stuck to their 7-bit ASCII, or non-UTF-8 8-bit codesets in their locales, and compile real UTF-8 sources. People in the last group (which includes me :)) would be forced to (a) modify their locale when building such sources as end-users, or (b) to find out about -finput-charset=UTF-8 and pass it via (b1) Makefile hacking or (b2) ./configure settings (env vars, or command line options). I think that's unreasonable; building random projects from the tubes would break for this small but existent group of users. Therefore I suggest to keep the logic as-is, and update the docs instead (gcc/doc/cppopts.texi): -finput-charset should not refer to the locale.
[Bug c++/53330] new() operator can return NULL on a zero-length allocation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53330 --- Comment #3 from Adam Borowski kilobyte at angband dot pl 2013-03-29 13:20:53 UTC --- Re-tested: * gcc-4.7.2 works on amd64, armhf, x32, fails on i386 * gcc-4.8.0 works on all of the above (all Debian) So it appears to be fixed in 4.8, at least on architectures I tried. Regardless of whether you'll fix it in 4.7 or not, it may be worth adding to the test suite.
[Bug other/56780] New: --disable-install-libiberty still installs libiberty.a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56780 Bug #: 56780 Summary: --disable-install-libiberty still installs libiberty.a Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: matt...@linuxfromscratch.org I'd like to build GCC with --disable-install-libiberty so that the version of libiberty.a provided by Binutils that is already installed will not be overwritten. However, the libiberty.a library is still installed even with that flag specified. My full configure invocation (run from within ~/gcc-build) is: ../gcc-4.8.0-version;/configure --prefix=/usr \ --libexecdir=/usr/lib \ --enable-shared \ --enable-threads=posix \ --enable-__cxa_atexit \ --enable-clocale=gnu\ --enable-languages=c,c++\ --disable-multilib \ --disable-bootstrap \ --disable-install-libiberty \ --with-system-zlib Additionally, libiberty's configure script's help output states: ' --enable-install-libiberty Install headers for end users' For clarity, that should probably read: 'Install headers and static library for end users'. That way, it's in agreement with what is also mentioned in libiberty.texi. Thanks, Matt.
[Bug sanitizer/56781] New: boostrap-asan failure: fixincl fails to link (missing -lasan)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56781 Bug #: 56781 Summary: boostrap-asan failure: fixincl fails to link (missing -lasan) Classification: Unclassified Product: gcc Version: 4.9.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: sanitizer AssignedTo: unassig...@gcc.gnu.org ReportedBy: al...@gcc.gnu.org CC: do...@gcc.gnu.org, dvyu...@gcc.gnu.org, ja...@gcc.gnu.org, k...@gcc.gnu.org bootstrap on x86_64-linux-gnu fails with: /scratch/obj.x86_64/gcc-4.9.mine/./gcc/xgcc -B/scratch/obj.x86_64/gcc-4.9.mine/./gcc/ -B/opt/x86_64/gcc-4.9.mine/x86_64-unknown-linux-gnu/bin/ -B/opt/x86_64/gcc-4.9.mine/x86_64-unknown-linux-gnu/lib/ -isystem /opt/x86_64/gcc-4.9.mine/x86_64-unknown-linux-gnu/include -isystem /opt/x86_64/gcc-4.9.mine/x86_64-unknown-linux-gnu/sys-include-Og -g3 -ggdb3 -static-libstdc++ -static-libgcc -o fixincl fixincl.o fixtests.o fixfixes.o server.o procopen.o fixlib.o fixopts.o ../libiberty/libiberty.a ../libiberty/libiberty.a(regex.o): In function `byte_compile_range': /scratch/obj.x86_64/gcc-4.9.mine/libiberty/../../../src/gcc-4.9.mine/libiberty/regex.c:4499: undefined reference to `__asan_report_store1' /scratch/obj.x86_64/gcc-4.9.mine/libiberty/../../../src/gcc-4.9.mine/libiberty/regex.c:4499: undefined reference to `__asan_report_load1' [snip] we would obviously need to link against asan but it is not immediately obvious to me how to pass POSTSTAGE1_LDFLAGS to fixincludes/ $ /scratch/obj.x86_64/gcc-4.9.mine/./gcc/xgcc -B/scratch/obj.x86_64/gcc-4.9.mine/./gcc/ -B/scratch/obj.x86_64/gcc-4.9.mine/x86_64-unknown-linux-gnu/libsanitizer/asan -B/scratch/obj.x86_64/gcc-4.9.mine/x86_64-unknown-linux-gnu/libsanitizer/asan/.libs -B/opt/x86_64/gcc-4.9.mine/x86_64-unknown-linux-gnu/bin/ -B/opt/x86_64/gcc-4.9.mine/x86_64-unknown-linux-gnu/lib/ -isystem /opt/x86_64/gcc-4.9.mine/x86_64-unknown-linux-gnu/include -isystem /opt/x86_64/gcc-4.9.mine/x86_64-unknown-linux-gnu/sys-include-Og -g3 -ggdb3 -static-libstdc++ -static-libgcc -o fixincl fixincl.o fixtests.o fixfixes.o server.o procopen.o fixlib.o fixopts.o ../libiberty/libiberty.a -fsanitize=address -static-libasan produces the desired fixincl $ /scratch/obj.x86_64/gcc-4.9.mine/./gcc/xgcc -v Using built-in specs. COLLECT_GCC=/scratch/obj.x86_64/gcc-4.9.mine/./gcc/xgcc Target: x86_64-unknown-linux-gnu Configured with: ../../src/gcc-4.9.mine/configure -v --enable-languages=c,lto,fortran,c++,go LD=/usr/bin/ld.bfd CFLAGS='-O2 -g3 -ggdb3' CXXFLAGS='-O2 -g3 -ggdb3' 'BOOT_CFLAGS=-O2 -g3 -ggdb3' 'BOOT_CXXFLAGS=-O2 -g3 -ggdb3' 'CFLAGS_FOR_TARGET=-Og -g3 -ggdb3' 'CXXFLAGS_FOR_TARGET=-Og -g3 -ggdb3' --prefix=/opt/x86_64/gcc-4.9.mine// --enable-shared --with-system-zlib --enable-nls --without-included-gettext --enable-threads=posix --program-suffix=-4.9.mine-HEAD --with-build-config=bootstrap-asan --enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --disable-werror --enable-checking=yes --enable-debug -C --disable-intermodule --enable-multilib --disable-libstdcxx-pch --enable-bootstrap --enable-checking=release --with-cpu=native --with-tune=native --enable-plugin Thread model: posix gcc version 4.9.0 20130327 (experimental) [vnhoist revision 32ddde1:a851c38:065ec6e627efa59b32f9fb743368a4a55c4ac310] (GCC)
[Bug lto/56777] bad grammar in fwhole-program documentation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56777 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com Target Milestone|--- |4.8.1 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2013-03-29 13:41:54 UTC --- Fixed mainline and 4.8.1.
[Bug c++/56782] New: [C++11] Regression with empty pack expansions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56782
Bug #: 56782
Summary: [C++11] Regression with empty pack expansions
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.krueg...@googlemail.com
As of gcc 4.8.0 the following code is now rejected when compiled with flags
-std=c++11 -Wall -W -pedantic
//---
templateclass T
T declval();
struct is_convertible_impl {
templateclass T
static void sink(T);
templateclass T, class U, class = decltype(sinkU(declvalT()))
static auto test(int) - char;
templateclass, class
static auto test(...) - char()[2];
};
templateclass T, class U
struct is_convertible : is_convertible_impl
{
static const bool value = sizeof(testT, U(0)) == 1;
};
templatebool, class
struct enable_if {};
templateclass T
struct enable_iftrue, T { typedef T type; };
templatebool, class If, class Else
struct conditional { typedef If type; };
templateclass If, class Else
struct conditionalfalse, If, Else { typedef Else type; };
templateclass...
struct and_;
template
struct and_
{
static const bool value = true;
};
templateclass P
struct and_P : P
{
};
templateclass P1, class P2
struct and_P1, P2 : conditionalP1::value, P2, P1::type
{
};
templateclass... T
struct Tuple {
templateclass... U,
class = typename enable_ifand_
is_convertibleU, T...
::value, int::type
Tuple(U...){}
};
static_assert(is_convertibleTupleint, Tupleint::value, Ouch); // OK
static_assert(is_convertibleTuple, Tuple::value, Ouch); // Error
//---
The diagnostics being:
Compilation finished with errors:
source.cpp:18:48: error: template instantiation depth exceeds maximum of 900
(use -ftemplate-depth= to increase the maximum) substituting 'templateclass,
class static char ( is_convertible_impl::test(...))[2] [with
template-parameter-1-1 = Tuple; template-parameter-1-2 = Tuple]'
static const bool value = sizeof(testT, U(0)) == 1;
^
source.cpp:55:5: recursively required from 'const bool is_convertibleTuple,
Tuple ::value'
source.cpp:55:5: required from 'const bool is_convertibleTuple, Tuple
::value'
source.cpp:64:49: required from here
source.cpp:18:48: error: no matching function for call to
'is_convertibleTuple, Tuple ::test(int)'
source.cpp:18:48: note: candidates are:
source.cpp:9:15: note: templateclass T, class U, class static char
is_convertible_impl::test(int)
static auto test(int) - char;
^
source.cpp:9:15: note: template argument deduction/substitution failed:
source.cpp:12:15: note: templateclass, class static char (
is_convertible_impl::test(...))[2]
static auto test(...) - char()[2];
^
source.cpp:12:15: note: substitution of deduced template arguments resulted in
errors seen above
source.cpp:64:1: error: non-constant condition for static assertion
static_assert(is_convertibleTuple, Tuple::value, Ouch); // Error
^
source.cpp:64:1: error: the value of 'is_convertibleTuple, Tuple ::value'
is not usable in a constant expression
source.cpp:18:21: note: 'is_convertibleTuple, Tuple ::value' was not
initialized with a constant expression
static const bool value = sizeof(testT, U(0)) == 1;
^
The code is accepted with gcc 4.7.2 and with Clang 3.2.
It seems that for empty expansions the compiler erroneously does enter into the
actually empty expansion:
is_convertibleU, T...
[Bug c++/56782] [4.8/4.9 Regression] Regression with empty pack expansions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56782 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-03-29 CC||jason at gcc dot gnu.org Summary|[C++11] Regression with |[4.8/4.9 Regression] |empty pack expansions |Regression with empty pack ||expansions Ever Confirmed|0 |1 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2013-03-29 13:51:01 UTC --- Confirmed.
[Bug tree-optimization/56770] Partial sums loop optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56770 David Edelsohn dje at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-03-29 Ever Confirmed|0 |1 --- Comment #1 from David Edelsohn dje at gcc dot gnu.org 2013-03-29 15:29:38 UTC --- Currently not implemented in GCC.
[Bug tree-optimization/54200] copyrename generates wrong debuginfo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54200
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-29
15:36:15 UTC ---
This patch regressed code quality on find_vma function in Linux kernel on
s390x:
struct rb_node
{
unsigned long __rb_parent_color;
struct rb_node *rb_right;
struct rb_node *rb_left;
} __attribute__ ((aligned (sizeof (long;
struct rb_root {
struct rb_node *rb_node;
};
struct vm_area_struct
{
unsigned long vm_start;
unsigned long vm_end;
struct vm_area_struct *vm_next, *vm_prev;
struct rb_node vm_rb;
};
struct mm_struct
{
struct vm_area_struct *mmap;
struct rb_root mm_rb;
struct vm_area_struct *mmap_cache;
};
struct vm_area_struct *
find_vma (struct mm_struct *mm, unsigned long addr)
{
struct vm_area_struct *vma = ((void *) 0);
static _Bool __attribute__ ((__section__ (.data.unlikely))) __warned;
int __ret_warn_once = !!(!mm);
if (__builtin_expect (!!(__ret_warn_once), 0))
{
int __ret_warn_on = !!(!__warned);
if (__builtin_expect (!!(__ret_warn_on), 0))
asm volatile (: :i (1920), i (((1 0) | ((9) 8))), i (64));
if (__builtin_expect (!!(__ret_warn_on), 0))
__warned = 1;
}
if (__builtin_expect (!!(__ret_warn_once), 0))
return ((void *) 0);
vma = mm-mmap_cache;
if (!(vma vma-vm_end addr vma-vm_start = addr))
{
struct rb_node *rb_node;
rb_node = mm-mm_rb.rb_node;
vma = ((void *) 0);
while (rb_node)
{
struct vm_area_struct *vma_tmp;
const typeof (((struct vm_area_struct *)0)-vm_rb) *__mptr = rb_node;
vma_tmp = (struct vm_area_struct *) ((char *) __mptr - __builtin_offsetof
(struct vm_area_struct, vm_rb));
if (vma_tmp-vm_end addr)
{
vma = vma_tmp;
if (vma_tmp-vm_start = addr)
break;
rb_node = rb_node-rb_left;
}
else
rb_node = rb_node-rb_right;
}
if (vma)
mm-mmap_cache = vma;
}
return vma;
}
with:
-fno-strict-aliasing -fno-common -fno-delete-null-pointer-checks -O2 -m64
-mbackchain -msoft-float -march=z9-109 -mpacked-stack -mstack-size=16384
-fno-strength-reduce -fno-stack-protector -fomit-frame-pointer
-fno-inline-functions-called-once -fconserve-stack
The difference in *.optimized is just:
- # vma_5 = PHI 0B(18), vma_2(15), vma_20(6), vma_2(16), 0B(7)
- return vma_5;
+ # _5 = PHI 0B(18), vma_2(15), vma_20(6), vma_2(16), 0B(7)
+ return _5;
but later on CSE2 decides to use REG_EQUAL somewhere for some reason, and we
end up reading mm-mmap_cache twice, first into a register to do the
comparisons of it, and then when we know it is the value we actually want to
return, we just forget we have it in a pseudo and read it again from memory.
[Bug tree-optimization/56770] Partial sums loop optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56770 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added CC||Joost.VandeVondele at mat ||dot ethz.ch --- Comment #2 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2013-03-29 15:55:38 UTC --- well actually related to PR25621, I think, and partially implemented via -fvariable-expansion-in-unroller -ffast-math would be nice to have this enabled (and well working) at -O3 or so.
[Bug sanitizer/56781] boostrap-asan failure: fixincl fails to link (missing -lasan)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56781 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-03-29 Ever Confirmed|0 |1 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2013-03-29 16:20:46 UTC --- Please try http://gcc.gnu.org/git/?p=gcc.git;a=commit;h=61be6ebfe22f9ce5799dac2679541911eb744a86 http://gcc.gnu.org/git/?p=gcc.git;a=commit;h=6b526a34a0bc852461cb50636c6e757bf8e27faf
[Bug c++/56783] New: g++ does not supply signatures for gdb on g++ 4.7 versions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56783 Bug #: 56783 Summary: g++ does not supply signatures for gdb on g++ 4.7 versions Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: dick.guer...@gmail.com Steps to reproduce: On Snow Leopard, compile c-programs with -g option using g++ to create a linked module for execution. Use gdb to read the module, and attempt to set breakpoints. No symbols are found. g++ no longer places the signatures in the linked module, or the object decks, so gdb can't find the signatures to satisfy something like: break emsvc.c:DoSVC ; However, the same source compiled with g++ and linked on Tiger, when copied to Snow Leopard, can set breakpoints. Actual results: dickguertin$ g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/local/bin/../libexec/gcc/x86_64-apple-darwin11.4.0/4.7.1/lto-wrapper Target: x86_64-apple-darwin11.4.0 Configured with: ../gcc-4.7.1/configure --enable-languages=fortran Thread model: posix gcc version 4.7.1 (GCC) dickguertin$ gdb -q emg 2/dev/null Reading symbols for shared libraries . done (gdb) maint print psymbols emg.sym (gdb) break emsvc.c:DoSVC Function DoSVC not defined in file emsvc.c. Make breakpoint pending on future shared library load? (y or [n]) n (gdb) quit dickguertin$ Expected results: In the command sequence shown above, the breakpoint should have been set. The maint command creates a symbol-table text-file (emg.sym), which shows that the signatures are no longer included in either the object decks or linked module (emg). Similar commands on Tiger produce symbol-tables with signatures, and breakpoints can be found (and set) by gdb on Tiger, and even the gdb on Snow Leopard.
[Bug debug/56783] g++ does not supply signatures for gdb on g++ 4.7 versions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56783 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Component|c++ |debug --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2013-03-29 17:21:30 UTC --- Are you sure that this is not a bug in Apple's part of the toolchain and not g++?
[Bug debug/56783] g++ does not supply signatures for gdb on g++ 4.7 versions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56783 --- Comment #2 from Dick Guertin dick.guertin at gmail dot com 2013-03-29 17:57:43 UTC --- (In reply to comment #1) Are you sure that this is not a bug in Apple's part of the toolchain and not g++? I'm almost positive. But you need to define the term toolchain since that doesn't make sense to me. I know if I compile withthe -g option using the g++ version 4.0.1 on Tiger, and link the executable module, it can be debugged with gdb on both Tiger AND Snow Leopard. But if I compile with g++ version 4.2 or above on Snow Leopard, the linked module can NOT be debugged. I've used the maint command with gdb to get the symbol-tables output on both Tiger and Snow Leopard, the the object decks don't contain the same information. Sorry to say, my research shows that the g++ compiler on Snow Leopard no longer places symbols in the linked module that have any meaning to gdb. The only symbols found are the made-up symbols created to make ALL symbols unique. Here is a brief sample: `_Z5DoSVCi', function, 0x151dd `_Z7SEBTrapv', function, 0x1383c Those same symbols in Tiger were like this: `_Z5DoSVCi' `DoSVC(int)', FUNCTION, 0x1394c `_Z7SEBTrapv' `SEBTrap()', FUNCTION, 0xf994 The signature is what gdb needs to resolve things like: break emsvc.c:DoSVC Furthermore, you must still have all the object decks, like emsvc.o, because Snow Leopard's g++ apparently does not carry the symbols in the linked module anymore.
[Bug c++/56782] [4.8/4.9 Regression] Regression with empty pack expansions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56782 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added CC||dodji at gcc dot gnu.org Depends on||53609 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org 2013-03-29 17:59:18 UTC --- This seems to be an issue with Dodji's patch for bug 53609; we aren't using PACK_EXPANSION_EXTRA_ARGS for the partial instantiation of the tuple constructor, but we should be.
[Bug tree-optimization/56770] Partial sums loop optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56770 --- Comment #3 from David Edelsohn dje at gcc dot gnu.org 2013-03-29 18:11:54 UTC --- I tried -funroll-loops -fvariable-expansion-in-unroller. I did not see any additional benefit from -fvariable-expansion-in-unroller. Unrolling helped somewhat, the intermediate sum was computed in each loop iteration instead of sunk after the loop.
[Bug libitm/56784] New: bootstrap broken by libitm on x86_64-unknown-freebsd10.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56784
Bug #: 56784
Summary: bootstrap broken by libitm on
x86_64-unknown-freebsd10.0
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: libitm
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ka...@gcc.gnu.org
Updated 4.9.0 to top-of-tree
% svn info gcc4x
Path: gcc4x
Working Copy Root Path: /usr/home/sgk/gcc/gcc4x
URL: svn+ssh://ka...@gcc.gnu.org/svn/gcc/trunk
Repository Root: svn+ssh://ka...@gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 197239
Node Kind: directory
Schedule: normal
Last Changed Author: paolo
Last Changed Rev: 197237
Last Changed Date: 2013-03-29 06:41:14 -0700 (Fri, 29 Mar 2013)
% cd obj
% ../gcc4x/configure --prefix=$HOME/work/4x --enable-languages=c,fortran,c++
% gmake bootstrap
libtool: compile: /home/sgk/gcc/obj4x/./gcc/xg++ -B/home/sgk/gcc/obj4x/./gcc/
-nostdinc++ -nostdinc++
-I/home/sgk/gcc/obj4x/x86_64-unknown-freebsd10.0/libstdc++-v3/include/x86_64-unknown-freebsd10.0
-I/home/sgk/gcc/obj4x/x86_64-unknown-freebsd10.0/libstdc++-v3/include
-I/home/sgk/gcc/gcc4x/libstdc++-v3/libsupc++
-I/home/sgk/gcc/gcc4x/libstdc++-v3/include/backward
-I/home/sgk/gcc/gcc4x/libstdc++-v3/testsuite/util
-L/home/sgk/gcc/obj4x/x86_64-unknown-freebsd10.0/libstdc++-v3/src
-L/home/sgk/gcc/obj4x/x86_64-unknown-freebsd10.0/libstdc++-v3/src/.libs
-B/home/sgk/work/4x/x86_64-unknown-freebsd10.0/bin/
-B/home/sgk/work/4x/x86_64-unknown-freebsd10.0/lib/ -isystem
/home/sgk/work/4x/x86_64-unknown-freebsd10.0/include -isystem
/home/sgk/work/4x/x86_64-unknown-freebsd10.0/sys-include -DHAVE_CONFIG_H -I.
-I../../../gcc4x/libitm -I../../../gcc4x/libitm/config/x86
-I../../../gcc4x/libitm/config/posix -I../../../gcc4x/libitm/config/generic
-I../../../gcc4x/libitm -mrtm -Wall -pthread -Werror -std=gnu++0x
-funwind-tables -fno-exceptions -fno-rtti -fabi-version=4 -g -O2 -MT aatree.lo
-MD -MP -MF .deps/aatree.Tpo -c ../../../gcc4x/libitm/aatree.cc -fPIC -DPIC -o
.libs/aatree.o
In file included from ../../../gcc4x/libitm/libitm_i.h:40:0,
from ../../../gcc4x/libitm/aatree.cc:28:
../../../gcc4x/libitm/local_atomic:1580:3: error: always_inline function might
not be inlinable [-Werror=attributes]
atomic_flag_clear(volatile atomic_flag* __a) noexcept
^
../../../gcc4x/libitm/local_atomic:1576:3: error: always_inline function might
not be inlinable [-Werror=attributes]
atomic_flag_clear(atomic_flag* __a) noexcept
^
../../../gcc4x/libitm/local_atomic:1572:3: error: always_inline function might
not be inlinable [-Werror=attributes]
atomic_flag_test_and_set(volatile atomic_flag* __a) noexcept
^
../../../gcc4x/libitm/local_atomic:1568:3: error: always_inline function might
not be inlinable [-Werror=attributes]
atomic_flag_test_and_set(atomic_flag* __a) noexcept
^
../../../gcc4x/libitm/local_atomic:1563:3: error: always_inline function might
not be inlinable [-Werror=attributes]
atomic_flag_clear_explicit(volatile atomic_flag* __a,
^
../../../gcc4x/libitm/local_atomic:1559:3: error: always_inline function might
not be inlinable [-Werror=attributes]
atomic_flag_clear_explicit(atomic_flag* __a, memory_order __m) noexcept
^
../../../gcc4x/libitm/local_atomic:1554:3: error: always_inline function might
not be inlinable [-Werror=attributes]
atomic_flag_test_and_set_explicit(volatile atomic_flag* __a,
^
../../../gcc4x/libitm/local_atomic:1549:3: error: always_inline function might
not be inlinable [-Werror=attributes]
atomic_flag_test_and_set_explicit(atomic_flag* __a,
^
../../../gcc4x/libitm/local_atomic:95:3: error: always_inline function might
not be inlinable [-Werror=attributes]
atomic_signal_fence(memory_order __m) noexcept
^
../../../gcc4x/libitm/local_atomic:89:3: error: always_inline function might
not be inlinable [-Werror=attributes]
atomic_thread_fence(memory_order __m) noexcept
./../../gcc4x/libitm/local_atomic:79:3: error: always_inline function might not
be inlinable [-Werror=attributes]
__calculate_memory_order(memory_order __m) noexcept
^
../../../gcc4x/libitm/local_atomic: In function 'bool
std::atomic_flag_test_and_set(std::atomic_flag*)':
../../../gcc4x/libitm/local_atomic:1549:3: error: inlining failed in call to
always_inline 'bool std::atomic_flag_test_and_set_explicit(std::atomic_flag*,
std::memory_order) noexcept (true)': function body can be overwritten at link
time
atomic_flag_test_and_set_explicit(atomic_flag* __a,
^
../../../gcc4x/libitm/local_atomic:1569:71: error: called from here
{ return atomic_flag_test_and_set_explicit(__a, memory_order_seq_cst); }
^
[Bug c++/56774] [4.7/4.8/4.9 Regression] G++ 4.8 reverses variadic template types during unpacking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56774 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org |
[Bug c++/56749] [4.8/4.9 Regression] weird interaction between scoped enum used as non-type template parameter and template lookup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56749 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #1 from Jason Merrill jason at gcc dot gnu.org 2013-03-29 18:38:44 UTC --- Fixed for 4.8.1.
[Bug c++/56746] [4.8 regression] increased memory usage when compiling C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56746 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #8 from Jason Merrill jason at gcc dot gnu.org 2013-03-29 18:43:55 UTC --- (In reply to comment #7) So it seems the macro expansion tracking is what's causing a lot of extra memory usage here. OK, that makes sense, as the compiler is keeping more information around in order to give better diagnostic context with macros.
[Bug debug/56783] g++ does not supply signatures for gdb on g++ 4.7 versions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56783 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2013-03-29 19:27:03 UTC --- (In reply to comment #2) (In reply to comment #1) Are you sure that this is not a bug in Apple's part of the toolchain and not g++? I'm almost positive. But you need to define the term toolchain since that doesn't make sense to me. http://en.wikipedia.org/wiki/Toolchain I know if I compile withthe -g option using the g++ version 4.0.1 on Tiger, and link the executable module, it can be debugged with gdb on both Tiger AND Snow Leopard. But if I compile with g++ version 4.2 or Is 4.2 a typo or are you really saying this applies to old versions and not just 4.7? above on Snow Leopard, the linked module can NOT be debugged. I've used the maint command with gdb to get the symbol-tables output on both Tiger and Snow Leopard, the the object decks don't contain the same information. Sorry to say, my research shows that the g++ compiler on Snow Leopard no longer places symbols in the linked module that have any meaning to gdb. The only symbols found are the made-up symbols created to make ALL symbols unique. Here is a brief sample: `_Z5DoSVCi', function, 0x151dd `_Z7SEBTrapv', function, 0x1383c Those same symbols in Tiger were like this: `_Z5DoSVCi' `DoSVC(int)', FUNCTION, 0x1394c `_Z7SEBTrapv' `SEBTrap()', FUNCTION, 0xf994 The signature is what gdb needs to resolve things like: break emsvc.c:DoSVC Furthermore, you must still have all the object decks, like emsvc.o, because Snow Leopard's g++ apparently does not carry the symbols in the linked module anymore. If the symbols are in emsvc.o then the problem is probably not with g++, because after it creates a .o file GCC doesn't do anything else, it just invokes the linker, which is Apple's part of the toolchain. Also, what is your gdb version?
[Bug middle-end/56770] Partial sums loop optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56770 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Status|NEW |ASSIGNED Component|tree-optimization |middle-end AssignedTo|unassigned at gcc dot |steven at gcc dot gnu.org |gnu.org | --- Comment #4 from Steven Bosscher steven at gcc dot gnu.org 2013-03-29 19:38:21 UTC --- Interesting idea, I'll have a look.
[Bug middle-end/56770] Partial sums loop optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56770
--- Comment #5 from David Edelsohn dje at gcc dot gnu.org 2013-03-29 19:53:44
UTC ---
Segher pointed out that the transformed code example is has a bug. The first
revised loop should test j+1 NZ.
for (j = 0; j+1 NZ; j += 2){
fValue += Q[j] / r[j];
fValue1 += Q[j+1] / r[j+1];
}
[Bug debug/56783] g++ does not supply signatures for gdb on g++ 4.7 versions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56783 --- Comment #4 from Dick Guertin dick.guertin at gmail dot com 2013-03-29 20:04:45 UTC --- (In reply to comment #3) (In reply to comment #2) (In reply to comment #1) Are you sure that this is not a bug in Apple's part of the toolchain and not g++? I'm almost positive. But you need to define the term toolchain since that doesn't make sense to me. http://en.wikipedia.org/wiki/Toolchain I know if I compile withthe -g option using the g++ version 4.0.1 on Tiger, and link the executable module, it can be debugged with gdb on both Tiger AND Snow Leopard. But if I compile with g++ version 4.2 or Is 4.2 a typo or are you really saying this applies to old versions and not just 4.7? above on Snow Leopard, the linked module can NOT be debugged. I've used the maint command with gdb to get the symbol-tables output on both Tiger and Snow Leopard, the the object decks don't contain the same information. Sorry to say, my research shows that the g++ compiler on Snow Leopard no longer places symbols in the linked module that have any meaning to gdb. The only symbols found are the made-up symbols created to make ALL symbols unique. Here is a brief sample: `_Z5DoSVCi', function, 0x151dd `_Z7SEBTrapv', function, 0x1383c Those same symbols in Tiger were like this: `_Z5DoSVCi' `DoSVC(int)', FUNCTION, 0x1394c `_Z7SEBTrapv' `SEBTrap()', FUNCTION, 0xf994 The signature is what gdb needs to resolve things like: break emsvc.c:DoSVC Furthermore, you must still have all the object decks, like emsvc.o, because Snow Leopard's g++ apparently does not carry the symbols in the linked module anymore. If the symbols are in emsvc.o then the problem is probably not with g++, because after it creates a .o file GCC doesn't do anything else, it just invokes the linker, which is Apple's part of the toolchain. Also, what is your gdb version? Johanathan, 4.2 was NOT a typo. That was the version of g++ that came with Snow Leopard. It was failing. I replaced it by version 4.7 obtained from SourceForge, and it fails in EXACTLY the same way. As for the symbols, only the artificially created symbols are in the object decks, like _Z5DoSVCi, but the signatures are in the linked module (emg) because that's where gdb gets them on Tiger (g++ 4.0.1). Tiger doesn't need the object decks to debug a linked module. With g++ 4.2 OR 4.7, the linked module does NOT have the signatures, and gdb tries to obtain them from the object decks, therefore you must RETAIN the ojbect decks. But that doesn't help because gdb can't constuct the signatures. So debugging fails in the sense that you can't reference user-known symbols. The artificial symbols are not known to the user unless they've created a text file with the maint command using gdb. That's why I know the signatures are NOT in the linked module, because gdb reads the linked module to create the text file. Therefore, the linker must be adding the signatures to the linked module, probably by reading the object decks AND the source files. But that only seems to be happening with g++ 4.0.1 and associated linker. The linker with versions 4.2 and higher must have revised linkers that DO NOT create the signatures.
[Bug debug/56783] g++ does not supply signatures for gdb on g++ 4.7 versions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56783 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2013-03-29 20:56:29 UTC --- (In reply to comment #4) Johanathan, 4.2 was NOT a typo. That was the version of g++ that came with Snow Leopard. It was failing. I replaced it by version 4.7 obtained from SourceForge, and it fails in EXACTLY the same way. Then the problem is unlikely to be GCC. I'm fairly sure Apple's modified GCC 4.2 should work with their own OS and linker. Maybe the problem is with your GDB version, which you haven't stated. Therefore, the linker must be adding the signatures to the linked module, probably by reading the object decks AND the source files. But that only seems to be happening with g++ 4.0.1 and associated linker. The linker with versions 4.2 and higher must have revised linkers that DO NOT create the signatures. GCC doesn't have an associated linker, it is using the Apple linker that comes with the OS.
[Bug debug/56783] g++ does not supply signatures for gdb on g++ 4.7 versions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56783 --- Comment #6 from Dick Guertin dick.guertin at gmail dot com 2013-03-29 21:19:47 UTC --- (In reply to comment #5) (In reply to comment #4) Johanathan, 4.2 was NOT a typo. That was the version of g++ that came with Snow Leopard. It was failing. I replaced it by version 4.7 obtained from SourceForge, and it fails in EXACTLY the same way. Then the problem is unlikely to be GCC. I'm fairly sure Apple's modified GCC 4.2 should work with their own OS and linker. Maybe the problem is with your GDB version, which you haven't stated. Therefore, the linker must be adding the signatures to the linked module, probably by reading the object decks AND the source files. But that only seems to be happening with g++ 4.0.1 and associated linker. The linker with versions 4.2 and higher must have revised linkers that DO NOT create the signatures. GCC doesn't have an associated linker, it is using the Apple linker that comes with the OS. First, my apology for not giving the gdp version. I assume you meant this: GNU gdb 6.3.50-20050815 (Apple version gdb-1515) (Sat Jan 15 08:33:48 UTC 2011) Next, let me point out that this gdb works correctly with source modules compiled and linked on Tiger with g++ 4.0.1 and Mac OS X 10.4.11. It also worked on Leopard, system 10.5. But it now fails with the same sources compiled and link with g++ 4.2 or higher on Mac OS X 10.6. Therefore, it must be the Apple linker because if I use vi to view a linked module, I find path information to sources in the OS 10.4 system, but paths to objects in the 10.6 system. If gdb reads the 10.4 linked module, it then reads the sources and constructs the symbol-table with signatures. But if gdb reads the 10.6 linked modules, all it finds are references to the objects, which do NOT carry the signature information. So, I'm forced to agree with you, Unfortunately, Apple says they won't fix it in Snow Leopard (10.6), which is where the linker resides. Bummer.
[Bug debug/56783] g++ does not supply signatures for gdb on g++ 4.7 versions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56783 --- Comment #7 from Dick Guertin dick.guertin at gmail dot com 2013-03-29 21:22:54 UTC --- Is there a replacement for Apple's linker that would run on Snow Leopard?
[Bug fortran/56765] [OOP] compilation errors/ICE with unlimited polymorphic array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56765 --- Comment #3 from janus at gcc dot gnu.org 2013-03-29 21:30:03 UTC --- With this patch ... Index: gcc/fortran/resolve.c === --- gcc/fortran/resolve.c(revision 196862) +++ gcc/fortran/resolve.c(working copy) @@ -2538,7 +2538,9 @@ found: expr-ts = sym-ts; expr-value.function.name = sym-name; expr-value.function.esym = sym; - if (sym-as != NULL) + if (sym-result-ts.type == BT_CLASS CLASS_DATA (sym-result)-as) +expr-rank = CLASS_DATA (sym-result)-as-rank; + else if (sym-as != NULL) expr-rank = sym-as-rank; return MATCH_YES; ... the behavior of the two test cases is swapped: The second one is (correctly) rejected, while the first one ends up with the ICE.
[Bug fortran/49232] Pointer assignment of stride to CONTIGUOUS pointer not diagnosed as invalid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49232 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-03-29 CC||tkoenig at gcc dot gnu.org Ever Confirmed|0 |1
[Bug fortran/56744] [meta-bug] Namelist bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56744 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-03-29 Ever Confirmed|0 |1
[Bug target/56771] Integer Overflow? Building arm-rtems libgcc2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56771 Joel Sherrill joel at gcc dot gnu.org changed: What|Removed |Added Host||centos-6.4/i686 --- Comment #3 from Joel Sherrill joel at gcc dot gnu.org 2013-03-29 22:18:26 UTC --- Adding another data point. This also fails on gcc63.fsffrance.org which is: $ ssh j...@gcc63.fsffrance.org Linux deluxe 2.6.26-2-sparc64-smp #1 SMP Sun Mar 4 22:02:58 UTC 2012 sparc64 $ cat /etc/issue Debian GNU/Linux 5.0 \n \l
[Bug fortran/41137] inefficient zeroing of an array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41137 --- Comment #15 from Thomas Koenig tkoenig at gcc dot gnu.org 2013-03-29 22:19:05 UTC --- The patch from comment#12 causes memory failure of the following code: module zero implicit none contains subroutine foo(a) real, contiguous :: a(:,:) a(:,:) = 0 end subroutine foo end module zero program main use zero implicit none real, dimension(5,5) :: a a = 1. call foo(a(1:5:2,1:5:2)) write (*,'(5F12.5)') a end program main which is a bit strange.
[Bug fortran/35203] OPTIONAL, VALUE actual argument cannot be an INTEGER 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35203 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #12 from Tobias Burnus burnus at gcc dot gnu.org 2013-03-29 22:32:32 UTC --- Author: burnus Date: Fri Mar 29 22:26:17 2013 New Revision: 197252 URL: http://gcc.gnu.org/viewcvs?rev=197252root=gccview=rev Log: 2013-03-29 Tobias Burnus bur...@net-b.de PR fortran/35203 * trans-decl.c (create_function_arglist): Pass hidden argument for passed-by-value optional+value dummies. * trans-expr.c (gfc_conv_expr_present, gfc_conv_procedure_call): Handle those. 2013-03-29 Tobias Burnus bur...@net-b.de PR fortran/35203 * gfortran.dg/optional_absent_3.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/optional_absent_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/35203] OPTIONAL, VALUE actual argument cannot be an INTEGER 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35203 --- Comment #13 from Tobias Burnus burnus at gcc dot gnu.org 2013-03-29 22:35:01 UTC --- FIXED on the 4.9 trunk. Thanks Toon for pointing out this feature. The feature is handled in the same way as IBM: The hidden present argument is passed before the hidden string-length arguments.
[Bug fortran/41137] inefficient zeroing of an array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41137
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #16 from Tobias Burnus burnus at gcc dot gnu.org 2013-03-29
22:38:58 UTC ---
Possible off-topic remark - or hitting right on the nail: Looking at
a(:,:,:,:)=0.0
and
a(5:) = 0.0
I wonder whether it couldn't be handled via RANGE_REF, e.g.
RANGE_REF(a,5,...) = { };
should work if I am not mistaken. Currently, we only do a = 0.0 - a = {};.
See ARRAY_RANGE_REF in trans-expr.c's class_array_data_assign
(gfc_index_zero_node is the offset) for the usage; see also GCC internal manual
and Ada.
[Bug target/49880] SuperH: ICE when -m4 is used with -mdiv=call-div1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49880 Oleg Endo olegendo at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #7 from Oleg Endo olegendo at gcc dot gnu.org 2013-03-29 23:18:50 UTC --- Fixed for 4.8 and 4.7.
[Bug target/48326] Target attribute leaks from function pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48326 --- Comment #2 from michael at talamasca dot ocis.net michael at talamasca dot ocis.net 2013-03-30 00:26:53 UTC --- The bug itself seems to have been silently fixed in 4.7.2 or earlier, maybe. My testcase no longer causes cmov to be emitted, although this could be an accidental side effect of other changes. However, there is a related bug that is definitely still present. I noticed the first bug because GCC itself is also an example of code that triggers it. This means that modern versions of GCC may fail to bootstrap themselves from older GCCs that have the original bug. Fixing this second bug is fairly simple, changing the ifdef that controls SSE use in libcpp/lex.c to require GCC_VERSION = 4008 instead of 4005. (The exact value is not certain, but it must at least be 4007 since 4.6.0 is known to have the bug.) It would be a good idea to fix this in 4.7.3. As the last version compilable from C alone, it will be a likely intermediate stop for anyone trying to bootstrap up from an ancient GCC installation.
[Bug c++/22488] [4.6/4.7/4.8/4.9 Regression] push_fields_onto_fieldstack calculates offset incorrectly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22488 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Priority|P5 |P2 Status|WAITING |NEW AssignedTo|jason at gcc dot gnu.org|unassigned at gcc dot ||gnu.org --- Comment #56 from Jason Merrill jason at gcc dot gnu.org 2013-03-30 00:30:38 UTC --- I still hope to get to this, but I don't anticipate it being a high priority for me any time soon, so I'm going to unassign myself for now. I'm also going to bump up the priority again.
[Bug c++/56774] [4.7/4.8/4.9 Regression] G++ 4.8 reverses variadic template types during unpacking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56774 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.7.3 --- Comment #5 from Jason Merrill jason at gcc dot gnu.org 2013-03-30 00:31:50 UTC --- Fixed for 4.7.3/4.8.1/4.9.
[Bug libstdc++/56785] New: std::tuple of two elements does not apply empty base class optimization when one of its elements is a std::tuple with two elements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56785
Bug #: 56785
Summary: std::tuple of two elements does not apply empty base
class optimization when one of its elements is a
std::tuple with two elements
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: da...@doublewise.net
#include tuple
class Empty {
};
int main() {
static_assert(sizeof(std::tupleEmpty, std::tupleint, int) ==
sizeof(std::tupleint, int), Too big);
}
[david@localhost test]$ g++ source/test.cpp -std=c++11 -Wall -Wextra -pedantic
source/test.cpp: In function ‘int main()’:
source/test.cpp:23:2: error: static assertion failed: Too big
The static_assert does not fail if I change it to be a std::tupleint, int,
int on both sides, however, or any number of int other than exactly 2. I also
get this bug regardless of the type in the std::tuple (for instance, my own
class type).
Therefore, I have created a workaround, demonstrated such:
#include tuple
class Empty {
};
class Empty2 {
};
int main() {
static_assert(sizeof(std::tupleEmpty, std::tupleint, short, Empty2) ==
sizeof(std::tupleint, short, Empty2), Too big);
static_assert(sizeof(std::tupleEmpty, std::tupleint, int, Empty2) ==
sizeof(int) * 2, Too big);
}
[david@localhost test]$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.7.2/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --disable-build-with-cxx
--disable-build-poststage1-with-cxx --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin
--enable-initfini-array --enable-java-awt=gtk --disable-dssi
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-ppl --with-cloog --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.7.2 20121109 (Red Hat 4.7.2-8) (GCC)
[Bug libfortran/49791] [4.6/4.7/4.8/4.9 Regression] Formatted namelist reads fails with: Cannot match namelist object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49791 --- Comment #24 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2013-03-30 02:58:25 UTC --- Created attachment 29751 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29751 Related test case This example fails with a runtime error and passes with ifort. The other cases in this PR are fixed.
[Bug fortran/51825] Fortran runtime error: Cannot match namelist object name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51825 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2013-03-30 03:13:27 UTC --- Fixed on trunk, lets close this one and will carry forward on 56660.
[Bug libfortran/49791] [4.6/4.7/4.8/4.9 Regression] Formatted namelist reads fails with: Cannot match namelist object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49791 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #25 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2013-03-30 03:18:49 UTC --- Lets close this one and carry forward on PR56660.
[Bug fortran/52512] Cannot match namelist object name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52512 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #6 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2013-03-30 03:30:25 UTC --- This bug fixed by Tilo's patch. Closing.
[Bug fortran/55117] Programs fails to read namelist (contains derived types objects)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55117 --- Comment #20 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2013-03-30 03:54:27 UTC --- Lets take namelist out of the picture here for the case of comment #6 program test_type_extension type t1_t real :: x end type t1_t type, extends(t1_t) :: t1e_t character(8) :: string end type t1e_t type(t1e_t) :: t1e tle%x = 5.678 end program test_type_extension $ gfc pr55117.f90 pr55117.f90:13.6: tle%x = 5.678 1 Error: Symbol 'tle' at (1) has no IMPLICIT type Ifort agrees with gfortran on this example So, I think this PR (55117) can be closed and if the example in this comment and #6 is another bug, lets open a new PR for it.
[Bug fortran/56743] Namelist bug with comment and no blank
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56743 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added CC||jvdelisle at gcc dot ||gnu.org --- Comment #3 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2013-03-30 04:08:19 UTC --- Agree, we should just audit list_read.c for this case.
[Bug fortran/55117] Programs fails to read namelist (contains derived types objects)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55117 --- Comment #21 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2013-03-30 05:05:03 UTC --- Oops! Disregard Comment #20. There is a not so subtle effect when one mixes up the letter 'l' and the digit '1' in names.
[Bug plugins/56754] some missing plugin headers during installation in gcc 4.8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56754 Michael Davies nemykal at mercurylampe dot org changed: What|Removed |Added CC||nemykal at mercurylampe dot ||org --- Comment #3 from Michael Davies nemykal at mercurylampe dot org 2013-03-30 05:26:32 UTC --- I get this same error when trying to compile kernel 3.8.5 with the hardened grsecurity patch, and selecting CONFIG_PAX_CONSTIFY_PLUGIN: scripts/kconfig/conf --silentoldconfig Kconfig HOSTCXX -fPIC tools/gcc/colorize_plugin.o HOSTCXX -fPIC tools/gcc/constify_plugin.o tools/gcc/constify_plugin.c:35:20: fatal error: target.h: No such file or directory #include target.h ^ compilation terminated. make[1]: *** [tools/gcc/constify_plugin.o] Error 1 make: *** [gcc-plugins] Error 2 Worked fine in 4.7.2, doesn't work with 4.8.0
