[Bug fortran/54678] second call to get_environment_variable gives valgrind warning with 8-byte integers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54678 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2012-09-24 06:37:26 UTC --- Draft patch: --- a/libgfortran/intrinsics/env.c +++ b/libgfortran/intrinsics/env.c @@ -186,5 +186,6 @@ get_environment_variable_i8 (char *name, char *value, GFC_INTEGER_8 *length, get_environment_variable_i4 (name, value, length4, status4, - trim_name4, name_len, value_len); + trim_name ? trim_name4 : NULL, + name_len, value_len); if (length)
[Bug tree-optimization/53663] [4.7/4.8 Regression] inconsistent inline handling of bool within union
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53663 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW CC||jakub at gcc dot gnu.org Version|unknown |4.7.2 Target Milestone|--- |4.7.3 Summary|4.7 inconsistent inline |[4.7/4.8 Regression] |handling of bool within |inconsistent inline |union |handling of bool within ||union
[Bug target/39244] Various cleanup tests fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39244 --- Comment #6 from Andrew Pinski pinskia at gcc dot gnu.org 2012-09-24 07:18:33 UTC --- I don't see the failures on arm-linux-gnueabi but do on powerpc64-linux-gnu; I wonder if this is a related bug.
[Bug ada/54688] New: [4.8 regression] a-ioexce.ads violation of implicit restriction No_Elaboration_Code breaks Ada bootstrap on sparc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54688 Bug #: 54688 Summary: [4.8 regression] a-ioexce.ads violation of implicit restriction No_Elaboration_Code breaks Ada bootstrap on sparc64-linux Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassig...@gcc.gnu.org ReportedBy: mi...@it.uu.se Bootstrapping gcc-4.8-20120923 on sparc64-linux w/ Ada fails: /mnt/scratch/objdir48/./prev-gcc/xgcc -B/mnt/scratch/objdir48/./prev-gcc/ -B/mnt/scratch/install48/sparc64-unknown-linux-gnu/bin/ -B/mnt/scratch/install48/sparc64-unknown-linux-gnu/bin/ -B/mnt/scratch/install48/sparc64-unknown-linux-gnu/lib/ -isystem /mnt/scratch/install48/sparc64-unknown-linux-gnu/include -isystem /mnt/scratch/install48/sparc64-unknown-linux-gnu/sys-include-c -g -O2 -gnatpg -gnata -W -Wall -nostdinc -I- -I. -Iada -I/mnt/scratch/gcc-4.8-20120923/gcc/ada -I/mnt/scratch/gcc-4.8-20120923/gcc/ada/gcc-interface /mnt/scratch/gcc-4.8-20120923/gcc/ada/a-ioexce.ads -o ada/a-ioexce.o a-ioexce.ads:21:19: violation of implicit restriction No_Elaboration_Code a-ioexce.ads:22:19: violation of implicit restriction No_Elaboration_Code a-ioexce.ads:23:19: violation of implicit restriction No_Elaboration_Code a-ioexce.ads:24:19: violation of implicit restriction No_Elaboration_Code a-ioexce.ads:25:19: violation of implicit restriction No_Elaboration_Code a-ioexce.ads:26:19: violation of implicit restriction No_Elaboration_Code a-ioexce.ads:27:19: violation of implicit restriction No_Elaboration_Code a-ioexce.ads:28:19: violation of implicit restriction No_Elaboration_Code make[3]: *** [ada/a-ioexce.o] Error 1 make[3]: *** Waiting for unfinished jobs make[3]: Leaving directory `/mnt/scratch/objdir48/gcc' make[2]: *** [all-stage3-gcc] Error 2 make[2]: Leaving directory `/mnt/scratch/objdir48' make[1]: *** [stage3-bubble] Error 2 make[1]: Leaving directory `/mnt/scratch/objdir48' make: *** [bootstrap] Error 2 The previous weekly snapshot, gcc-4.8-20120916, did not have this problem. Complete configuration parameters: /mnt/scratch/gcc-4.8-20120923/configure --prefix=/mnt/scratch/install48 --with-gmp=/home/mikpe/pkgs/linux-sparc64/gmp-5.0.5 --with-mpfr=/home/mikpe/pkgs/linux-sparc64/mpfr-3.1.1 --with-mpc=/home/mikpe/pkgs/linux-sparc64/mpc-1.0.1 --with-cpu=v8 --enable-multilib --disable-plugin --disable-lto --disable-nls --enable-threads=posix --enable-checking=release --disable-libmudflap --enable-languages=c,c++,fortran,ada
[Bug tree-optimization/54345] jump threading leaks e-aux heap memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54345 --- Comment #4 from rguenther at suse dot de rguenther at suse dot de 2012-09-24 08:52:06 UTC --- On Fri, 21 Sep 2012, polacek at redhat dot com wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54345 --- Comment #3 from Marek Polacek polacek at redhat dot com 2012-09-21 15:11:08 UTC --- Hmm. I hoped that something like this will show the leak, but no (it does a lot of threading with -O2--through conditionals, through loop headers and also through latches). But obviously it's not enough. Any ideas, please? ISTR I recognized this on the testcase for PR46590
[Bug middle-end/52173] internal compiler error: verify_ssa failed possibly caused by itm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52173 --- Comment #16 from Richard Guenther rguenth at gcc dot gnu.org 2012-09-24 08:57:12 UTC --- Author: rguenth Date: Mon Sep 24 08:57:08 2012 New Revision: 191658 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=191658 Log: 2012-09-24 Richard Guenther rguent...@suse.de PR middle-end/52173 * gimple.c (gimple_copy): Properly mark the copy modified if SSA operands are present. * gcc.dg/tm/pr52173-1.c: New. * gcc.dg/tm/pr52173-2.c: New. Added: trunk/gcc/testsuite/gcc.dg/tm/pr52173-1.c trunk/gcc/testsuite/gcc.dg/tm/pr52173-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimple.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/52173] internal compiler error: verify_ssa failed possibly caused by itm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52173 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|NEW Known to work||4.8.0 AssignedTo|rguenth at gcc dot gnu.org |unassigned at gcc dot ||gnu.org Known to fail||4.7.2 --- Comment #17 from Richard Guenther rguenth at gcc dot gnu.org 2012-09-24 08:58:20 UTC --- Fixed on trunk.
[Bug tree-optimization/54676] [4.8 Regression] ICE: in set_value_range, at tree-vrp.c:433
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54676 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2012-09-24 08:59:19 UTC --- Created attachment 28258 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28258 gcc48-pr54676.patch Untested fix.
[Bug middle-end/54689] New: sparseset.h:147 Conditional jump or move depends on uninitialised value(s)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54689
Bug #: 54689
Summary: sparseset.h:147 Conditional jump or move depends on
uninitialised value(s)
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dim...@gmail.com
GNU C++ (GCC) version 4.8.0 20120923 (experimental) [trunk revision 191649]
(x86_64-unknown-linux-gnu)
$ cat undef_sparseset_h.ii
class A {
int f() const;
};
int A::f() const {}
$ LANG=C valgrind --track-origins=yes --num-callers=24
/usr/local/gcc_current/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/cc1plus -v
-fpreprocessed undef_sparseset_h.ii -quiet -march=x86-64 -o -version
==19291== Memcheck, a memory error detector
==19291== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==19291== Using Valgrind-3.9.0.SVN and LibVEX; rerun with -h for copyright info
==19291== Command:
/usr/local/gcc_current/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/cc1plus -v
-fpreprocessed undef_sparseset_h.ii -quiet -march=x86-64 -o -version
==19291==
GNU C++ (GCC) version 4.8.0 20120923 (experimental) [trunk revision 191649]
(x86_64-unknown-linux-gnu)
compiled by GNU C version 4.8.0 20120923 (experimental) [trunk revision
191649], GMP version 5.0.2, MPFR version 3.1.0, MPC version 0.9
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory
/usr/local/gcc_current/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../x86_64-unknown-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/usr/local/gcc_current/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/include/c++
/usr/local/gcc_current/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/include/c++/x86_64-unknown-linux-gnu
/usr/local/gcc_current/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/include/c++/backward
/usr/local/gcc_current/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/include
/usr/local/include
/usr/local/gcc_current/include
/usr/local/gcc_current/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/include-fixed
/usr/include
End of search list.
GNU C++ (GCC) version 4.8.0 20120923 (experimental) [trunk revision 191649]
(x86_64-unknown-linux-gnu)
compiled by GNU C version 4.8.0 20120923 (experimental) [trunk revision
191649], GMP version 5.0.2, MPFR version 3.1.0, MPC version 0.9
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: fc0afb1edaeae797a870fb2622727189
==19291== Conditional jump or move depends on uninitialised value(s)
==19291==at 0x92D0FD: mark_pseudo_regno_live(int) (sparseset.h:147)
==19291==by 0x92E11C: process_bb_node_lives(ira_loop_tree_node*)
(ira-lives.c:1326)
==19291==by 0x9161FA: ira_traverse_loop_tree(bool, ira_loop_tree_node*,
void (*)(ira_loop_tree_node*), void (*)(ira_loop_tree_node*))
(ira-build.c:1495)
==19291==by 0x92ECA1: ira_create_allocno_live_ranges() (ira-lives.c:1591)
==19291==by 0x9188C4: ira_build() (ira-build.c:3093)
==19291==by 0x911D7E: rest_of_handle_ira() (ira.c:4223)
==19291==by 0x97F20C: execute_one_pass(opt_pass*) (passes.c:2199)
==19291==by 0x97F5C4: execute_pass_list(opt_pass*) (passes.c:2254)
==19291==by 0x97F5D6: execute_pass_list(opt_pass*) (passes.c:2255)
==19291==by 0x7815F7: expand_function(cgraph_node*) (cgraphunit.c:1601)
==19291==by 0x783771: compile() (cgraphunit.c:1794)
==19291==by 0x783A94: finalize_compilation_unit() (cgraphunit.c:2080)
==19291==by 0x5B03DA: cp_write_global_declarations() (decl2.c:4024)
==19291==by 0xA1E444: compile_file() (toplev.c:560)
==19291==by 0xA20019: toplev_main(int, char**) (toplev.c:1863)
==19291==by 0x38E3421734: (below main) (libc-start.c:226)
==19291== Uninitialised value was created by a heap allocation
==19291==at 0x480871C: malloc (vg_replace_malloc.c:270)
==19291==by 0xF08587: xmalloc (xmalloc.c:147)
==19291==by 0xA0814F: sparseset_alloc(unsigned long) (sparseset.c:33)
==19291==by 0x92EC2F: ira_create_allocno_live_ranges() (ira-lives.c:1583)
==19291==by 0x9188C4: ira_build() (ira-build.c:3093)
==19291==by 0x911D7E: rest_of_handle_ira() (ira.c:4223)
==19291==by 0x97F20C: execute_one_pass(opt_pass*) (passes.c:2199)
==19291==by 0x97F5C4: execute_pass_list(opt_pass*) (passes.c:2254)
==19291==by 0x97F5D6: execute_pass_list(opt_pass*) (passes.c:2255)
==19291==by 0x7815F7: expand_function(cgraph_node*) (cgraphunit.c:1601)
==19291==by 0x783771: compile() (cgraphunit.c:1794)
==19291==by 0x783A94: finalize_compilation_unit() (cgraphunit.c:2080)
==19291==by 0x5B03DA: cp_write_global_declarations() (decl2.c:4024)
==19291==by 0xA1E444: compile_file() (toplev.c:560)
==19291==by
[Bug tree-optimization/53663] [4.7/4.8 Regression] inconsistent inline handling of bool within union
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53663 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | --- Comment #11 from Richard Guenther rguenth at gcc dot gnu.org 2012-09-24 09:08:17 UTC --- Mine.
[Bug tree-optimization/53663] [4.7/4.8 Regression] inconsistent inline handling of bool within union
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53663 --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org 2012-09-24 09:14:31 UTC --- Guess for BOOLEAN_TYPE in unions we can't look just at the single bit, but also all other bits of the boolean type, because we rely that the bool doesn't contain other values than false/true.
[Bug bootstrap/54684] bootstrap broken with --disable-checking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54684 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-09-24 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-09-24 09:24:36 UTC --- Confirmed. Reducing.
[Bug middle-end/54683] [4.8 Regression] Bootstrap comparison failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54683 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug lto/54632] [4.8 Regression] not supported in LTO streams : tree code '�F ��D�� `
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54632 --- Comment #8 from Richard Guenther rguenth at gcc dot gnu.org 2012-09-24 09:26:25 UTC --- If it's triggered by GC I suggest to try reducing with --param ggc-min-expand=0 --param ggc-min-heapsize=0 (not that this will make it any faster ;))
[Bug target/54686] std::abs (long long) resorts to std::abs (double) if llabs is absent
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54686 --- Comment #28 from Paolo Carlini paolo.carlini at oracle dot com 2012-09-24 09:27:05 UTC --- Indeed uglier ;) but I must say that overall I think we have to do something like this. I'm still annoyed that because of the type we can't handle in the same way div but I'm also coming to the conclusion that in terms of actual code we can't do much about it, besides making the configury more fine grained, and separating the stdlib.h bits, which maybe could help other targets but, if I understand correctly, would not help newlib anyway, because llabs is completely missing (Note that around the corner there is us providing fall backs for *everything* missing from the target libc, where in this case *us* has nothing to do with *me* ;)
[Bug other/54671] [4.7/4.8 Regression] gcc 4.7.2 -Wl,--no-ctors-in-init-array causes binutils test failure, works with 4.7.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54671 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target||i?86-*-* Known to work||4.7.1 Target Milestone|--- |4.7.3 Summary|gcc 4.7.2 |[4.7/4.8 Regression] gcc |-Wl,--no-ctors-in-init-arra |4.7.2 |y causes binutils test |-Wl,--no-ctors-in-init-arra |failure, works with 4.7.1 |y causes binutils test ||failure, works with 4.7.1 Known to fail||4.7.2
[Bug middle-end/54666] when do lto opitimizing with attribute (weak,alias), it will produce wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54666 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Version|lto |4.7.2 Keywords||lto, wrong-code Last reconfirmed||2012-09-24 Component|c |middle-end CC||hubicka at gcc dot gnu.org Ever Confirmed|0 |1 Known to fail||4.7.2, 4.8.0 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-09-24 09:33:02 UTC --- Confirmed. 4.6.x segfaults for me.
[Bug lto/54632] [4.8 Regression] not supported in LTO streams : tree code '�F ��D�� `
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54632 --- Comment #9 from Zdenek Sojka zsojka at seznam dot cz 2012-09-24 09:38:40 UTC --- If I remember correctly, with --param ggc-min-expand=0 --param ggc-min-heapsize=0 the program didn't crash - maybe the space was reallocated of another tree, so the pointer became valid again. I tried to compile gcc with --disable-bootstrap --enable-checking=valgrind, but the compilation fails when linking (saying I should use -fPIC). That would give me the chance to use valgrind to find the invalid memory access (memory allocations aren't hooked by valgrind here; valgrind checking adds explicit calls to valgrind routines). I am not reducing the file any longer, if it's caused by invalid memory references, the crash could appear and disappear 'randomly' with changes in the code.
[Bug fortran/54690] New: [4.8 Regression] FAIL: gfortran.dg/typebound_operator_(7|13).f03 * (internal compiler error) after revision 191649
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54690 Bug #: 54690 Summary: [4.8 Regression] FAIL: gfortran.dg/typebound_operator_(7|13).f03 * (internal compiler error) after revision 191649 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr CC: bur...@net-b.de, hjl.to...@gmail.com The tests gfortran.dg/typebound_operator_7.f03 and gfortran.dg/typebound_operator_13.f03 fail after revision 191649 (see http://gcc.gnu.org/ml/gcc-regression/2012-09/msg00430.html ): /opt/gcc/_clean/gcc/testsuite/gfortran.dg/typebound_operator_13.f03: In function 'MAIN__': /opt/gcc/_clean/gcc/testsuite/gfortran.dg/typebound_operator_13.f03:54:0: internal compiler error: in gfc_conv_procedure_call, at fortran/trans-expr.c:3944 fireworks = fireworks + fireworks*dt Line 3944 is gcc_assert (fsym-ts.u.derived == e-ts.u.derived); added by r191649.
[Bug lto/54632] [4.8 Regression] not supported in LTO streams : tree code '�F ��D�� `
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54632 --- Comment #10 from Dmitry G. Dyachenko dimhen at gmail dot com 2012-09-24 09:46:12 UTC --- for me testcase FAIl with -O2 -flto --param ggc-min-heapsize=0 and OK with -O3 -flto --param ggc-min-expand=0
[Bug other/54671] [4.7/4.8 Regression] gcc 4.7.2 -Wl,--no-ctors-in-init-array causes binutils test failure, works with 4.7.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54671 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2012-09-24 10:13:53 UTC --- I think this is a user bug. If gcc is configured against binutils that support conversion of ctors into init_array, then it will assume it, obviously you can't use --no-ctors-in-init-array then, you'd need to configure gcc not to assume it. Why do you need to use that option (actually, I wonder why the linker has that option at all)?
[Bug libstdc++/43554] profile-mode version of forward_list missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43554 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #13 from Paolo Carlini paolo.carlini at oracle dot com 2012-09-24 10:29:44 UTC --- I'm closing this.
[Bug fortran/54687] Use gcc option machinery for gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54687 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-09-24 Blocks||44054 Ever Confirmed|0 |1 --- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-09-24 10:46:41 UTC --- This is also a pre-requisite for using LangEnabledBy to encode options dependencies in fortran/lang.opt file.
[Bug bootstrap/54684] bootstrap broken with --disable-checking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54684
--- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-09-24
10:47:27 UTC ---
Created attachment 28259
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28259
autoreduced testcase
(gdb) p *pass
$1 = {type = GIMPLE_PASS, name = 0x149a13a fab, gate = 0x0,
execute = 0xce06c1 execute_fold_all_builtins(), sub = 0x0,
next = 0x1a95ea0 pass_optimize_widening_mul, static_pass_number = 139,
tv_id = TV_NONE, properties_required = 40, properties_provided = 0,
properties_destroyed = 0, todo_flags_start = 524288,
todo_flags_finish = 2052}
[Bug tree-optimization/54684] [4.8 Regression] bootstrap broken with --disable-checking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54684 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Component|bootstrap |tree-optimization Target Milestone|--- |4.8.0 Summary|bootstrap broken with |[4.8 Regression] bootstrap |--disable-checking |broken with ||--disable-checking
[Bug middle-end/54689] sparseset.h:147 Conditional jump or move depends on uninitialised value(s)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54689 --- Comment #1 from Dmitry G. Dyachenko dimhen at gmail dot com 2012-09-24 11:35:56 UTC --- 189310 OK 189563 OK 189602 OK 189648 OK 190510 FAIL 190556 FAIL 190613 FAIL 190868 FAIL 191105 FAIL 191129 FAIL 191244 FAIL 191356 FAIL 191461 FAIL 191511 FAIL 191649 FAIL 191663 FAIL - today' trunk
[Bug tree-optimization/53663] [4.7/4.8 Regression] inconsistent inline handling of bool within union
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53663 --- Comment #13 from Richard Guenther rguenth at gcc dot gnu.org 2012-09-24 11:44:32 UTC --- This boils down to the question whether reading a 1-bit precision quantity from memory has to disregard the upper bits or not (I think we had similar issues with SRA). Thus, whether reading a _Bool from memory is a bitfield extract or not (expansion does not treat it as bitfield extract because the FIELD_DECLs size is 8, not 1). We go into /* 3) Assignment from a constant. We can use folds native encode/interpret routines to extract the assigned bits. */ which has the issue that it doesn't work if TYPE_PRECISION is not equal to TYPE_SIZE. At least not for detecting redundant stores (it does work for folding a read of v.b though). I have a patch.
[Bug bootstrap/54329] [4.8 Regression] gcc/cfgcleanup.o differs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54329 --- Comment #7 from wbrana wbrana at gmail dot com 2012-09-24 11:48:51 UTC --- still broken
[Bug tree-optimization/54684] [4.8 Regression] bootstrap broken with --disable-checking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54684 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2012-09-24 11:56:07 UTC --- Immediate uses are hosed by optimize_unreachable.
[Bug other/54691] New: [4.8 Regression] --enable-checking=valgrind doesn't build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54691 Bug #: 54691 Summary: [4.8 Regression] --enable-checking=valgrind doesn't build Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: mar...@trippelsdorf.de --disable-bootstrap --enable-checking=valgrind doesn't build: ... true AR_FLAGS=rc CC_FOR_BUILD=gcc CFLAGS=-g -O2 CXXFLAGS=-g -O2 -D_GNU_SOURCE CFLAGS_FOR_BUILD=-g -O2 CFLAGS_FOR_TARGET=-g -O2 INSTALL=/ usr/bin/install -c INSTALL_DATA=/usr/bin/install -c -m 644 INSTALL_PROGRAM=/usr/bin/install -c INSTALL_SCRIPT=/usr/bin/install -c JC1FLAGS= LDFLAGS= LIBCFLAGS=-g -O2 LIBCFLAGS_FOR_TARGET=-g -O2 MAKE=make MAKEINFO=makeinfo --split-size=500 --split-size=500 PICFLAG= P ICFLAG_FOR_TARGET= SHELL=/bin/sh RUNTESTFLAGS= exec_prefix=/usr/local infodir=/usr/local/share/info libdir=/usr/local/lib prefix=/usr/loc al includedir=/usr/local/include AR=ar AS=/var/tmp/gcc_build_dir/./gcc/as CC=/var/tmp/gcc_build_dir/./gcc/xgcc -B/var/tmp/gcc_build_dir/./gcc / -B/usr/local/x86_64-unknown-linux-gnu/bin/ -B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/x86_64-unknown-linux-gnu/include -isystem /usr/local/x86_64-unknown-linux-gnu/sys-include CXX=-B/usr/local/x86_64-unknown-linux-gnu/bin/ -B/usr/local/x86_64-unknown-linux-gnu/lib/ -isys tem /usr/local/x86_64-unknown-linux-gnu/include -isystem /usr/local/x86_64-unknown-linux-gnu/sys-include LD=/var/tmp/gcc_build_dir/./gcc/collect -ld LIBCFLAGS=-g -O2 NM=/var/tmp/gcc_build_dir/./gcc/nm PICFLAG= RANLIB=ranlib DESTDIR= DO=all multi-do # make /bin/sh ./libtool --tag=CC --mode=link /var/tmp/gcc_build_dir/./gcc/xgcc -B/var/tmp/gcc_build_dir/./gcc/ -B/usr/local/x86_64-unknown-linux-gnu/bin/ -B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/x86_64-unknown-linux-gnu/include -isystem /usr/local/x86_64-unknown-linux-gnu/sys-inc lude-Wall -g -O2 -version-info `grep -v '^#' /home/markus/gcc/libssp/libtool-version` -Wl,--version-script=/home/markus/gcc/libssp/ssp.map -o l ibssp.la -rpath /usr/local/lib/../lib64 ssp.lo gets-chk.lo memcpy-chk.lo memmove-chk.lo mempcpy-chk.lo memset-chk.lo snprintf-chk.lo sprintf-chk.lo s tpcpy-chk.lo strcat-chk.lo strcpy-chk.lo strncat-chk.lo strncpy-chk.lo vsnprintf-chk.lo vsprintf-chk.lo libtool: link: /var/tmp/gcc_build_dir/./gcc/xgcc -B/var/tmp/gcc_build_dir/./gcc/ -B/usr/local/x86_64-unknown-linux-gnu/bin/ -B/usr/local/x86_64-unkno wn-linux-gnu/lib/ -isystem /usr/local/x86_64-unknown-linux-gnu/include -isystem /usr/local/x86_64-unknown-linux-gnu/sys-include-shared .libs/ssp .o .libs/gets-chk.o .libs/memcpy-chk.o .libs/memmove-chk.o .libs/mempcpy-chk.o .libs/memset-chk.o .libs/snprintf-chk.o .libs/sprintf-chk.o .libs/stpc py-chk.o .libs/strcat-chk.o .libs/strcpy-chk.o .libs/strncat-chk.o .libs/strncpy-chk.o .libs/vsnprintf-chk.o .libs/vsprintf-chk.o -O2 -Wl,--versi on-script=/home/markus/gcc/libssp/ssp.map -Wl,-soname -Wl,libssp.so.0 -o .libs/libssp.so.0.0.0 /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/../../../../x86_64-pc-linux-gnu/bin/ld: error: .libs/ssp.o: requires dynamic R_X86_64_32 reloc which may overf low at runtime; recompile with -fPIC /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/../../../../x86_64-pc-linux-gnu/bin/ld: error: .libs/ssp.o: requires dynamic R_X86_64_PC32 reloc against '__st ack_chk_guard' which may overflow at runtime; recompile with -fPIC /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/../../../../x86_64-pc-linux-gnu/bin/ld: error: .libs/gets-chk.o: requires dynamic R_X86_64_PC32 reloc against 'malloc' which may overflow at runtime; recompile with -fPIC /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/../../../../x86_64-pc-linux-gnu/bin/ld: error: .libs/memcpy-chk.o: requires dynamic R_X86_64_PC32 reloc agains t '__chk_fail' which may overflow at runtime; recompile with -fPIC /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/../../../../x86_64-pc-linux-gnu/bin/ld: error: .libs/memmove-chk.o: requires dynamic R_X86_64_PC32 reloc again st '__chk_fail' which may overflow at runtime; recompile with -fPIC /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/../../../../x86_64-pc-linux-gnu/bin/ld: error: .libs/mempcpy-chk.o: requires dynamic R_X86_64_PC32 reloc again st 'memcpy' which may overflow at runtime; recompile with -fPIC /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/../../../../x86_64-pc-linux-gnu/bin/ld: error: .libs/memset-chk.o: requires dynamic R_X86_64_PC32 reloc agains t '__chk_fail' which may overflow at runtime; recompile with -fPIC /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/../../../../x86_64-pc-linux-gnu/bin/ld: error: .libs/snprintf-chk.o: requires dynamic R_X86_64_PC32 reloc agai nst 'vsnprintf' which may overflow at runtime; recompile with -fPIC
[Bug lto/54632] [4.8 Regression] not supported in LTO streams : tree code '�F ��D�� `
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54632 --- Comment #11 from Markus Trippelsdorf markus at trippelsdorf dot de 2012-09-24 12:27:28 UTC --- I get: ==24033== Memcheck, a memory error detector ==24033== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==24033== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==24033== Command: /var/tmp/foo/usr/local/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/cc1plus -fpreprocessed test.ii -quiet -dumpbase test.ii -mtune=generic -march=x86-64 -auxbase test -O2 -Wfatal-errors -w -std=c++11 -flto -flto-partition=none --param ggc-min-heapsize=0 -o /tmp/ccj0VbuA.s ==24033== ==24033== Invalid read of size 2 ==24033==at 0x947E70: lto_output_tree(output_block*, tree_node*, bool, bool) (lto-streamer-out.c:127) ==24033==by 0xB8D64F: streamer_write_tree_body(output_block*, tree_node*, bool) (tree-streamer-out.c:672) ==24033==by 0x948569: lto_output_tree(output_block*, tree_node*, bool, bool) (lto-streamer-out.c:339) ==24033==by 0xB8CDE3: streamer_write_tree_body(output_block*, tree_node*, bool) (tree-streamer-out.c:507) ==24033==by 0x948569: lto_output_tree(output_block*, tree_node*, bool, bool) (lto-streamer-out.c:339) ==24033==by 0x948CAE: lto_output() (lto-streamer-out.c:751) ==24033==by 0x97DBE0: ipa_write_summaries_2(opt_pass*, lto_out_decl_state*) (passes.c:2284) ==24033==by 0x97EA2D: ipa_write_summaries() (passes.c:2314) ==24033==by 0x782919: compile() (cgraphunit.c:1866) ==24033==by 0x782B54: finalize_compilation_unit() (cgraphunit.c:2080) ==24033==by 0x5AE5FA: cp_write_global_declarations() (decl2.c:4024) ==24033==by 0xA1D784: compile_file() (toplev.c:560) ==24033== Address 0x8c46af0 is not stack'd, malloc'd or (recently) free'd ==24033== ==24033== Invalid read of size 2 ==24033==at 0x947E99: lto_output_tree(output_block*, tree_node*, bool, bool) (tree-streamer.h:63) ==24033==by 0xB8D64F: streamer_write_tree_body(output_block*, tree_node*, bool) (tree-streamer-out.c:672) ==24033==by 0x948569: lto_output_tree(output_block*, tree_node*, bool, bool) (lto-streamer-out.c:339) ==24033==by 0xB8CDE3: streamer_write_tree_body(output_block*, tree_node*, bool) (tree-streamer-out.c:507) ==24033==by 0x948569: lto_output_tree(output_block*, tree_node*, bool, bool) (lto-streamer-out.c:339) ==24033==by 0x948CAE: lto_output() (lto-streamer-out.c:751) ==24033==by 0x97DBE0: ipa_write_summaries_2(opt_pass*, lto_out_decl_state*) (passes.c:2284) ==24033==by 0x97EA2D: ipa_write_summaries() (passes.c:2314) ==24033==by 0x782919: compile() (cgraphunit.c:1866) ==24033==by 0x782B54: finalize_compilation_unit() (cgraphunit.c:2080) ==24033==by 0x5AE5FA: cp_write_global_declarations() (decl2.c:4024) ==24033==by 0xA1D784: compile_file() (toplev.c:560) ==24033== Address 0x8c46af0 is not stack'd, malloc'd or (recently) free'd ==24033== test.ii: In member function ‘AirportTileTableIterator::operator++()’: test.ii:10619:6: internal compiler error: tree code ‘�F���’ is not supported in LTO streams } ^ Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Bug lto/54632] [4.8 Regression] not supported in LTO streams : tree code '�F ��D�� `
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54632
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2012-09-24
AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
--- Comment #12 from Richard Guenther rguenth at gcc dot gnu.org 2012-09-24
12:42:27 UTC ---
The backtrace hints at trees containing DECL_VALUE/DEBUG_EXPRs. We
are indeed writing TREE_BLOCK which has been garbage-collected.
(gdb) up
#3 0x00dcf803 in write_ts_exp_tree_pointers (ob=0x1c809d0,
expr=0x74de, ref_p=true)
at /space/rguenther/src/svn/trunk/gcc/tree-streamer-out.c:674
674 stream_write_tree (ob, TREE_BLOCK (expr), ref_p);
...
#7 0x00dcea3c in write_ts_decl_common_tree_pointers (ob=0x1c809d0,
expr=0x74ddc2f8, ref_p=true)
at /space/rguenther/src/svn/trunk/gcc/tree-streamer-out.c:509
509 stream_write_tree (ob, DECL_DEBUG_EXPR (expr), ref_p);
...
#11 0x00ad8e10 in output_struct_function_base (ob=0x1c809d0,
fn=0x75440c80)
at /space/rguenther/src/svn/trunk/gcc/lto-streamer-out.c:751
748 /* Output all the local variables in the function. */
749 streamer_write_hwi (ob, VEC_length (tree, fn-local_decls));
750 FOR_EACH_VEC_ELT (tree, fn-local_decls, i, t)
751 stream_write_tree (ob, t, true);
so somehow GC does not mark this block as used (or it is not marked
as used in the block tree and thus removed in remove_unused_scope_block_p).
We indeed forget to walk all locals in clear_unused_block_pointer ().
Testing
Index: gcc/tree-ssa-live.c
===
--- gcc/tree-ssa-live.c (revision 191664)
+++ gcc/tree-ssa-live.c (working copy)
@@ -620,11 +620,6 @@ clear_unused_block_pointer_1 (tree *tp,
if (EXPR_P (*tp) TREE_BLOCK (*tp)
!TREE_USED (TREE_BLOCK (*tp)))
TREE_SET_BLOCK (*tp, NULL);
- if (TREE_CODE (*tp) == VAR_DECL DECL_DEBUG_EXPR_IS_FROM (*tp))
-{
- tree debug_expr = DECL_DEBUG_EXPR (*tp);
- walk_tree (debug_expr, clear_unused_block_pointer_1, NULL, NULL);
-}
return NULL_TREE;
}
@@ -636,6 +631,16 @@ clear_unused_block_pointer ()
{
basic_block bb;
gimple_stmt_iterator gsi;
+ tree t;
+ unsigned i;
+
+ FOR_EACH_VEC_ELT (tree, cfun-local_decls, i, t)
+if (TREE_CODE (t) == VAR_DECL DECL_DEBUG_EXPR_IS_FROM (t))
+ {
+ tree debug_expr = DECL_DEBUG_EXPR (t);
+ walk_tree (debug_expr, clear_unused_block_pointer_1, NULL, NULL);
+ }
+
FOR_EACH_BB (bb)
for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi); gsi_next (gsi))
{
[Bug c++/54383] Internal compiler error for lamba function using this- with -std=c++0x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54383
166291 at gmail dot com changed:
What|Removed |Added
CC||166291 at gmail dot com
--- Comment #1 from 166291 at gmail dot com 2012-09-24 12:53:57 UTC ---
The following code breaks GCC 4.7.1:
auto test = [=]() { this
Yes, I didn't paste that badly. That entire line of code alone by itself in the
file will crash GCC.
[Bug tree-optimization/53663] [4.7/4.8 Regression] inconsistent inline handling of bool within union
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53663
--- Comment #14 from Richard Guenther rguenth at gcc dot gnu.org 2012-09-24
13:14:00 UTC ---
We still want to possibly optimize
extern void abort (void);
union u
{
int i;
_Bool b;
};
void f(union u * vp, union u v)
{
*vp = v;
}
int main()
{
union u v;
union u v1;
union u v2;
v.i = 0;
f(v1, v);
v.b = 0;
f(v2, v);
if (v2.b != 0)
abort ();
return 0;
}
though we might be able to trigger TBAA issues when removing a store
that would merely change the effective type (without changing the
underlying value). Of course we try hard (on the tree level) to
make DWIM code work, but still ... thus,
float = 1.;
int = 0;
float = 0.;
... = float;
if we remove the store float = 0. as redundant (it stores a value
already there) then further optimizations might re-order the float
and the int store. We don't perform redundant store elimination here
because 0. and 0 are not operand_equal_p though - but it works for shorts.
extern void abort (void);
union u
{
int i;
short f;
} v;
short foo (short *f)
{
*f = 1;
v.i = 0;
v.f = 0;
return *f;
}
int main()
{
if (foo (v.f) != 0)
abort ();
return 0;
}
(still doesn't break though).
[Bug other/54692] New: [4.8 Regression] gcc doesn't build with -Og -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54692 Bug #: 54692 Summary: [4.8 Regression] gcc doesn't build with -Og -g Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: mar...@trippelsdorf.de With: gcc_build_dir % ~/gcc/configure --disable-werror --disable-multilib --enable-languages=c,c++ gcc_build_dir % make STAGE1_CFLAGS=-g -Og all-stage1 I get: ... g++ -c -g -Og -DIN_GCC -fno-exceptions -fno-rtti -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I/home/markus/gcc/gcc -I/home/markus/gcc/gcc/build -I/home/markus/gcc/gcc/../include -I/home/markus/gcc/gcc/../libcpp/include -I/home/markus/gcc/gcc/../libdecnumber -I/home/markus/gcc/gcc/../libdecnumber/bid -I../libdecnumber\ -o build/genconstants.o /home/markus/gcc/gcc/genconstants.c In file included from /home/markus/gcc/gcc/read-md.h:22:0, from /home/markus/gcc/gcc/genconstants.c:32: /home/markus/gcc/gcc/../include/obstack.h:153:40: error: attempt to use poisoned bcopy # define _obstack_memcpy(To, From, N) bcopy ((char *)(From), (To), (N)) ^ In file included from ./bconfig.h:3:0, from /home/markus/gcc/gcc/genconstants.c:28: ./auto-host.h:1988:17: error: multiple types in one declaration #define ssize_t int ^ ./auto-host.h:1988:17: error: declaration does not declare anything [-fpermissive] ./auto-host.h:1976:15: error: multiple types in one declaration #define pid_t int ^ ./auto-host.h:1976:15: error: declaration does not declare anything [-fpermissive] In file included from /home/markus/gcc/gcc/system.h:198:0, from /home/markus/gcc/gcc/genconstants.c:29: /usr/include/sys/types.h:116:26: error: expected unqualified-id before ‘;’ token typedef __caddr_t caddr_t; ^ In file included from ./bconfig.h:3:0, from /home/markus/gcc/gcc/genconstants.c:28: ./auto-host.h:1982:16: error: declaration does not declare anything [-fpermissive] #define rlim_t long ^ In file included from /home/markus/gcc/gcc/genconstants.c:29:0: /home/markus/gcc/gcc/system.h:447:48: error: new declaration ‘char* strstr(const char*, const char*)’ extern char *strstr (const char *, const char *); ^ In file included from /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/include/g++-v4/cstring:44:0, from /home/markus/gcc/gcc/system.h:207, from /home/markus/gcc/gcc/genconstants.c:29: /usr/include/string.h:331:1: error: ambiguates old declaration ‘const char* strstr(const char*, const char*)’ strstr (const char *__haystack, const char *__needle) __THROW ^ In file included from /home/markus/gcc/gcc/genconstants.c:29:0: /home/markus/gcc/gcc/system.h:499:34: error: declaration of C function ‘const char* strsignal(int)’ conflicts with extern const char *strsignal (int); ^ In file included from /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/include/g++-v4/cstring:44:0, from /home/markus/gcc/gcc/system.h:207, from /home/markus/gcc/gcc/genconstants.c:29: /usr/include/string.h:562:14: error: previous declaration ‘char* strsignal(int)’ here extern char *strsignal (int __sig) __THROW; ^ In file included from /home/markus/gcc/gcc/system.h:639:0, from /home/markus/gcc/gcc/genconstants.c:29: /home/markus/gcc/gcc/../include/libiberty.h:110:36: error: new declaration ‘char* basename(const char*)’ extern char *basename (const char *); ^ In file included from /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/include/g++-v4/cstring:44:0, from /home/markus/gcc/gcc/system.h:207, from /home/markus/gcc/gcc/genconstants.c:29: /usr/include/string.h:599:26: error: ambiguates old declaration ‘const char* basename(const char*)’ extern C++ const char *basename (const char *__filename) ^ make[1]: *** [build/genconstants.o] Error 1 make[1]: Leaving directory `/var/tmp/gcc_build_dir/gcc'
[Bug fortran/54690] [4.8 Regression] FAIL: gfortran.dg/typebound_operator_(7|13).f03 * (internal compiler error) after revision 191649
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54690
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org,
||pault at gcc dot gnu.org
--- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2012-09-24
13:25:30 UTC ---
12.5.2.5 Allocatable and pointer dummy variables has:
The actual argument shall be polymorphic if and only if the associated dummy
argument is polymorphic, and either both the actual and dummy arguments shall
be unlimited polymorphic, or the declared type of the actual argument shall be
the same as the declared type of the dummy argument.
Thus, the assert is okay:
gcc_assert (fsym-ts.u.derived == e-ts.u.derived);
If one looks at the name, one has:
__class_soop_stars_class_Soop_stars_a (e-ts.u.derived-name)
__class_soop_stars_class_Soop_stars(fsym-ts.u.derived-name)
Thus, for some reason, the formal symbol is allocatable, but its type is not
marked as such.
Thus, the assert is fine, but the test is not:
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -3920,3 +3920,3 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
|| (fsym-ts.type == BT_CLASS
- CLASS_DATA (e)-attr.allocatable)))
+ CLASS_DATA (fsym)-attr.allocatable)))
{
[Bug debug/54693] New: VTA guality issues with loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54693
Bug #: 54693
Summary: VTA guality issues with loops
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
CC: aol...@gcc.gnu.org
Something that has been reported privately to me - gcc -g -O2:
__attribute__((noinline, noclone)) void
foo (char *str, char c)
{
asm volatile ( : : r (str), r (c) : memory);
*str = c;
}
int
main ()
{
int i;
char c;
char arr[11];
for (i = 0; i 10; i++)
{
c = 0x30 + i;
foo (arr[i], c);
}
__builtin_printf (arr = %s\n, arr);
return 0;
}
In 4.7.x the c variable in main is available in the whole loop (just not in the
prologue, but that is kind of expected when it is not initialized there), but
the i variable is available only in the prologue (0, correctly) and very short
part of the loop. In 4.8.0
http://gcc.gnu.org/viewcvs?root=gccview=revrev=185129
change made it even worse, the ivopts pass changes there the debug insns for i
to point to D#2 which is initialized to NULL right away.
As for the problem common to 4.7.x and 4.8.0, I think the issue is that vrp1
transforms:
bb 2:
# DEBUG i = 0
goto bb 4;
bb 3:
...
# DEBUG i = i_10
bb 4:
# i_1 = PHI 0(2), i_10(3)
# DEBUG i = i_1
if (i_1 = 9)
goto bb 3;
else
goto bb 5;
into:
bb 2:
# DEBUG i = 0
goto bb 6;
bb 3:
# i_16 = PHI i_1(4), i_14(6)
...
# DEBUG i = i_10
bb 4:
# i_1 = PHI i_10(3)
# DEBUG i = i_1
if (i_1 != 10)
goto bb 3;
else
goto bb 5;
...
bb 6:
# i_14 = PHI 0(2)
# DEBUG i = i_14
goto bb 3;
(still fine), but the debug insn no longer references the PHI), then dce1 comes
in, and I guess in some cfg cleanup makes this into:
bb 2:
# DEBUG i = 0
# DEBUG i = 0
bb 3:
# i_16 = PHI i_10(3), 0(2)
...
# DEBUG i = i_10
# DEBUG i = i_10
if (i_10 != 10)
goto bb 3;
else
goto bb 4;
Note, in neither case ... contains any # DEBUG i = something stmts.
The problem with this is that vrp together with dce transformations effectively
moved the almost the end of the bb only, it is no longer at the start of the
loop where it used to be before the transformations. Would be nice if we could
figure out that for the two blocks we have DEBUG stmts that refer to
corresponding PHI arguments (i_16 above) and that we should insert
# DEBUG i = i_16
at the start of bb 3, because previously if going from bb 2 there is # DEBUG i
= 0 and if going from bb 3 there is # DEBUG i = i_10.
Alex, what do you think? As for IVOPTS, haven't looked at that at all yet.
[Bug fortran/54690] [4.8 Regression] FAIL: gfortran.dg/typebound_operator_(7|13).f03 * (internal compiler error) after revision 191649
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54690 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-09-24 Target Milestone|--- |4.8.0 Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-09-24 13:52:02 UTC --- Confirmed.
[Bug other/54692] [4.8 Regression] gcc doesn't build with -Og -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54692 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-09-24 13:54:07 UTC --- ISTR it worked for me when checking in -Og support with BOOT_CFLAGS/BOOT_CXXFLAGS=-Og -g. I don't have a host compiler with -Og support around, but I wonder how -Og can make a difference for preprocessing? Is it some configure tests giving different results?
[Bug fortran/53685] surprising warns about transfer with explicit character range
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53685 --- Comment #6 from Andy May ajmay81 at googlemail dot com 2012-09-24 13:57:37 UTC --- Thanks for fixing this, the GCC 4.7.1 shipping with openSUSE 12.2 does not show this problem, and a build of GCC 4.7.2 from source doesn't either. Providing this has also been pushed to trunk and is not causing problems, I think this bug can be closed.
[Bug fortran/54690] [4.8 Regression] FAIL: gfortran.dg/typebound_operator_(7|13).f03 * (internal compiler error) after revision 191649
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54690 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-09-24 14:04:38 UTC --- The patch in comment #1 fixes this PR. Thanks.
[Bug other/54692] [4.8 Regression] gcc doesn't build with -Og -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54692 --- Comment #2 from Markus Trippelsdorf markus at trippelsdorf dot de 2012-09-24 14:07:06 UTC --- (In reply to comment #1) ISTR it worked for me when checking in -Og support with BOOT_CFLAGS/BOOT_CXXFLAGS=-Og -g. I don't have a host compiler with -Og support around, but I wonder how -Og can make a difference for preprocessing? Is it some configure tests giving different results? Yes (from gcc/config.log): configure:5224: checking for ANSI C header files configure:5244: gcc -c -g g conftest.c 5 gcc: error: g: No such file or directory and many more similar ones.
[Bug tree-optimization/54684] [4.8 Regression] bootstrap broken with --disable-checking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54684 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2012-09-24 14:14:24 UTC --- Author: rguenth Date: Mon Sep 24 14:14:18 2012 New Revision: 191667 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=191667 Log: 2012-09-24 Richard Guenther rguent...@suse.de PR tree-optimization/54684 * tree-ssa-ccp.c (optimize_unreachable): Properly update stmts. * g++.dg/torture/pr54684.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/torture/pr54684.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-ccp.c
[Bug tree-optimization/54684] [4.8 Regression] bootstrap broken with --disable-checking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54684 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2012-09-24 14:14:59 UTC --- Fixed.
[Bug target/50457] SH2A atomic functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50457 Oleg Endo olegendo at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2012-09-24 CC||kkojima at gcc dot gnu.org Resolution|INVALID | Ever Confirmed|0 |1 --- Comment #3 from Oleg Endo olegendo at gcc dot gnu.org 2012-09-24 14:19:41 UTC --- Uhm, I've been thinking In fact, the current atomic sequences (-msoft-atomic) are not compatible with anything but SH3* and SH4*. This is because everything SH3 (including SH2A) pushes SR and PC on the stack (R15) when an exception occurs, and for that the stack pointer must always be valid. The crashes mentioned in the original description are caused by the invalid stack pointer. I'm sorry for not noticing this when replying/closing this PR prematurely. I don't know how linux/glibc have been handling atomic ops on SH2 or SH2A, but I've got an idea that would work in a bare-metal setup. Instead of signaling the 'is in atomic sequence' condition through R15, it can be signaled through a thread local variable. For example a compare_and_swap sequence might look like this: mov #(0f-1f),r1 ! sequence length is held in R1 mova1f,r0 .align 2 mov.lr0,@(#x,gbr)! enter atomic sequence by setting the ! exit point to the thread local variable. ! #x is user defined through -m option 0: mov.bwl @r1,%0 mov#0,r0 cmp/eq %0,%4 bf1f mov.bwl %3,@%1 1: mov.l r0,@(#x,gbr)! set thread local variable to nullptr, ! which exits the atomic sequence. The check in the exception handling code for the 'is in atomic sequence' would be: @(#x,gbr) != 0 @(0,r15) @(#x,gbr) The atomic sequence rewind step in the exception handling code would be: @(0,r15) = @(#x,gbr) + r1 My assumption here is that gbr points to the execution context housekeeping structure, which is also accessible from user space. I've briefly checked the code of glibc and this seems to be the case. Problems will occur when the gbr is modified by user code (inline asm etc). So user code should not modify the gbr, or at least do it in a controlled way. But I think this issue can be ignored for now. The execution context struct must be modified to hold the additional variable for atomic sequences. The thread library / kernel will need a modification (the kernel will need a modification on SH2(A) anyway), so that @(#x,gbr) is initialized to zero on thread creation. Kaz, could you please provide some feedback on this idea?
[Bug other/54692] [4.8 Regression] gcc doesn't build with -Og -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54692 --- Comment #3 from Markus Trippelsdorf markus at trippelsdorf dot de 2012-09-24 14:21:05 UTC --- The following lines from gcc/configure don't know about -Og: 4862 # Remove the -O2: for historical reasons, unless bootstrapping we prefer 4863 # optimizations to be activated explicitly by the toplevel. 4864 case $CC in 4865 */prev-gcc/xgcc*) ;; 4866 *) CFLAGS=`echo $CFLAGS | sed s/-O[s0-9]* *// ` 4867 CXXFLAGS=`echo $CXXFLAGS | sed s/-O[s0-9]* *// ` ;; 4868 esac When I comment them out, gcc builds fine.
[Bug other/54692] [4.8 Regression] gcc doesn't build with -Og -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54692 Markus Trippelsdorf markus at trippelsdorf dot de changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Markus Trippelsdorf markus at trippelsdorf dot de 2012-09-24 14:32:16 UTC --- Looks like Jakuk is responsible: r191267 commit 56d581e9cde5c36d15b6d859abf6b2ea99f64ea0 Author: jakub jakub@138bc75d-0d04-0410-961f-82ee72b054a4 Date: Thu Sep 13 16:30:17 2012 + * configure.ac (CXXFLAGS): Remove -O2 when not bootstrapping. * configure: Regenerated.
[Bug other/54692] [4.8 Regression] gcc doesn't build with -Og -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54692 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #5 from Marek Polacek mpolacek at gcc dot gnu.org 2012-09-24 14:36:24 UTC --- Does it work with s/-O[sg0-9]* *//?
[Bug other/54692] [4.8 Regression] gcc doesn't build with -Og -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54692 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2012-09-24 14:39:30 UTC --- Guess *) CFLAGS=`echo $CFLAGS | sed s/-O[[s0-9]]* *// ` CXXFLAGS=`echo $CXXFLAGS | sed s/-O[[s0-9]]* *// ` ;; needs to be now -O[[s0-9gf]] instead (also for -Ofast). That said, I don't see how it is related to using STAGE1_CFLAGS (note missing XX).
[Bug other/54692] [4.8 Regression] gcc doesn't build with -Og -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54692 --- Comment #7 from Markus Trippelsdorf markus at trippelsdorf dot de 2012-09-24 14:40:50 UTC --- (In reply to comment #5) Does it work with s/-O[sg0-9]* *//? Yes: tmp % echo -Og -g| sed s/-O[sg0-9]* *// -g tmp %
[Bug other/54692] [4.8 Regression] gcc doesn't build with -Og -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54692 --- Comment #8 from Richard Guenther rguenth at gcc dot gnu.org 2012-09-24 14:49:55 UTC --- (In reply to comment #6) Guess *) CFLAGS=`echo $CFLAGS | sed s/-O[[s0-9]]* *// ` CXXFLAGS=`echo $CXXFLAGS | sed s/-O[[s0-9]]* *// ` ;; needs to be now -O[[s0-9gf]] instead (also for -Ofast). That said, I don't see how it is related to using STAGE1_CFLAGS (note missing XX). I wonder why we do the above at all? I suppose that's for removing a configure default, but the toplevel passes STAGE1_CFLAGS as CFLAGS to gcc configure (that's why we need to re-specify CFLAGS on the make command-line?!). So - why not drop this and instead save/restore flags around AC_PROG_CC/CXX?
[Bug lto/54632] [4.8 Regression] not supported in LTO streams : tree code '�F ��D�� `
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54632 --- Comment #13 from Richard Guenther rguenth at gcc dot gnu.org 2012-09-24 15:03:01 UTC --- Author: rguenth Date: Mon Sep 24 15:02:53 2012 New Revision: 191669 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=191669 Log: 2012-09-24 Richard Guenther rguent...@suse.de PR middle-end/54632 * tree-ssa-live.c (clear_unused_block_pointer_1): Do not handle DECL_DEBUG_EXPR_IS_FROM here... (clear_unused_block_pointer): ... but here when walking all local decls. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-live.c
[Bug lto/54632] [4.8 Regression] not supported in LTO streams : tree code '�F ��D�� `
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54632 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #14 from Richard Guenther rguenth at gcc dot gnu.org 2012-09-24 15:03:28 UTC --- Fixed.
[Bug other/54692] [4.8 Regression] gcc doesn't build with -Og -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54692 --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2012-09-24 15:04:06 UTC --- (In reply to comment #8) (In reply to comment #6) Guess *) CFLAGS=`echo $CFLAGS | sed s/-O[[s0-9]]* *// ` CXXFLAGS=`echo $CXXFLAGS | sed s/-O[[s0-9]]* *// ` ;; needs to be now -O[[s0-9gf]] instead (also for -Ofast). That said, I don't see how it is related to using STAGE1_CFLAGS (note missing XX). I wonder why we do the above at all? I suppose that's for removing a configure default, but the toplevel passes STAGE1_CFLAGS as CFLAGS to gcc configure (that's why we need to re-specify CFLAGS on the make command-line?!). The intent of this is to make sure that the toplevel Makefile has whatever fancy CXXFLAGS/CFLAGS is needed for bootstrapping, and gcc/Makefile has corresponding CXXFLAGS/CFLAGS without -O2 or similar in it. Thus, if in --disable-bootstrap (or cross) gcc you do make in toplevel, you are building an optimized compiler, while cd gcc; make after you tweak stuff here and there will default to no optimization and thus hopefully better debugging experience. If/when -Og is better than -O0 for debug experience surely we can use there -Og instead. From toplevel make just passes down CXXFLAGS/CFLAGS, so the values stored in gcc/Makefile are ignored.
[Bug other/54692] [4.8 Regression] gcc doesn't build with -Og -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54692 --- Comment #10 from Markus Trippelsdorf markus at trippelsdorf dot de 2012-09-24 15:08:27 UTC --- (In reply to comment #6) -O[[s0-9gf]] instead (also for -Ofast). s/-O\([sg0-9]\|fast\) *// should work.
[Bug fortran/54690] [4.8 Regression] FAIL: gfortran.dg/typebound_operator_(7|13).f03 * (internal compiler error) after revision 191649
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54690 --- Comment #4 from paul.richard.thomas at gmail dot com paul.richard.thomas at gmail dot com 2012-09-24 15:28:52 UTC --- Looks good to me - why did this pop up now? On 24 September 2012 16:04, dominiq at lps dot ens.fr gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54690 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-09-24 14:04:38 UTC --- The patch in comment #1 fixes this PR. Thanks. -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug target/14202] [arm] Thumb __builtin_setjmp not interworking safe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14202 Daniel Jacobowitz drow at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #16 from Daniel Jacobowitz drow at gcc dot gnu.org 2012-09-24 16:11:40 UTC --- Obsolete without arm-elf.
[Bug target/52122] [4.6/4.7/4.8 Regression] incorrect ln -s replacement for mingw like targets in configure files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52122 --- Comment #9 from Daniel Starke daniel.f.starke at freenet dot de 2012-09-24 16:55:33 UTC --- The problem in autoconf was fixed with version 2.69. I suggest to update AC_PREREQ within the configure.ac files to this version.
[Bug c++/50828] class template parameter not printed for member function template in candidate list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50828 --- Comment #6 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2012-09-24 16:56:52 UTC --- Author: paolo Date: Mon Sep 24 16:56:41 2012 New Revision: 191673 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=191673 Log: 2012-09-24 Paolo Carlini paolo.carl...@oracle.com PR c++/50828 * error.c (dump_function_decl): Strip TFF_TEMPLATE_NAME from flags at the outset. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/error.c
[Bug target/52122] [4.6/4.7/4.8 Regression] incorrect ln -s replacement for mingw like targets in configure files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52122 --- Comment #10 from Daniel Starke daniel.f.starke at freenet dot de 2012-09-24 16:57:53 UTC --- Here is the reference to the autoconf change: http://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=commitdiff;h=17ea0df46f819a9b64c21151983a5c5b8561fefb
[Bug c++/50828] class template parameter not printed for member function template in candidate list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50828 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com 2012-09-24 16:58:40 UTC --- Fixed.
[Bug fortran/52724] Internal read with character(kind=4) data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52724
--- Comment #5 from Thomas Koenig tkoenig at gcc dot gnu.org 2012-09-24
18:07:17 UTC ---
This patch looks promising:
Index: list_read.c
===
--- list_read.c (Revision 191649)
+++ list_read.c (Arbeitskopie)
@@ -199,9 +199,16 @@ next_char (st_parameter_dt *dtp)
if (is_internal_unit (dtp))
{
- char cc;
- length = sread (dtp-u.p.current_unit-s, cc, 1);
- c = cc;
+ /* Check for kind=4 internal unit. */
+ if (dtp-common.unit)
+ length = sread (dtp-u.p.current_unit-s, c, sizeof (gfc_char4_t));
+ else
+ {
+ char cc;
+ length = sread (dtp-u.p.current_unit-s, cc, 1);
+ c = cc;
+ }
+
if (length 0)
{
generate_error (dtp-common, LIBERROR_OS, NULL);
Index: unix.c
===
--- unix.c (Revision 191649)
+++ unix.c (Arbeitskopie)
@@ -959,7 +959,7 @@ open_internal4 (char *base, int length, gfc_offset
s-buffer = base;
s-buffer_offset = offset;
- s-active = s-file_length = length;
+ s-active = s-file_length = length * sizeof (gfc_char4_t);
s-st.vptr = mem4_vtable;
[Bug tree-optimization/54674] [4.8 Regression] ICE in build2_stat, at tree.c:3835
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54674 --- Comment #7 from William J. Schmidt wschmidt at gcc dot gnu.org 2012-09-24 18:35:41 UTC --- I'm working on a patch to avoid introducing a multiply by a pointer type, such as happened here. The interesting thing is that this doesn't look like a profitable transformation on most architectures. It appears that a multiply of two registers and an add of two registers may be given the same RTL cost in the SH family? It seems unlikely that those two operations have the same cost in practice, so it might be worth looking into whether the cost model for this target is fully implemented.
[Bug target/54457] [x32] Fail to combine 64bit index + constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54457 --- Comment #1 from Uros Bizjak ubizjak at gmail dot com 2012-09-24 18:38:46 UTC --- (In reply to comment #0) combine fails on: Trying 6 - 8: Failed to match this instruction: (set (reg:QI 66) (mem/j:QI (plus:SI (subreg:SI (plus:DI (reg/v:DI 62 [ position ]) (const_int 1 [0x1])) 0) (symbol_ref:SI (array) [flags 0x40] var_decl 0x719ad260 arra y)) [0 array S1 A8])) This should be a valid address. In principle yes, but the RTX is not accepted in ix86_decompose_address since we have two displacements here. Combine should simplify this RTX to: (set (reg:QI 68) (mem/j:QI (plus:SI (subreg:SI (reg/v:DI 62 [ position ]) 0) (const:SI (plus:SI (symbol_ref:SI (array) [flags 0x40] var_decl 0x7f8d1bc41390 array) (const_int 1 [0x1] [0 array S1 A8])) as is the case with -m32 (but rejected in ix86_address_subreg_operand): /* Don't allow SUBREGs that span more than a word. It can lead to spill failures when the register is one word out of a two word structure. */ if (GET_MODE_SIZE (mode) UNITS_PER_WORD) return false;
[Bug other/54691] [4.8 Regression] --enable-checking=valgrind doesn't build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54691 --- Comment #1 from Zdenek Sojka zsojka at seznam dot cz 2012-09-24 18:44:51 UTC --- At x86_64-unknown-linux-gnu, the build fails at a different place: ... libtool: link: /home/smatz/build-191654-lto-checking-valgrind-disable-bootstrap-disable-graphite/./gcc/xgcc -B/home/smatz/build-191654-lto-checking-valgrind-disable-bootstrap-disable-graphite/./gcc/ -B/mnt/svn/gcc-trunk/binary-191654-lto-checking-valgrind-disable-bootstrap-disable-graphite/x86_64-unknown-linux-gnu/bin/ -B/mnt/svn/gcc-trunk/binary-191654-lto-checking-valgrind-disable-bootstrap-disable-graphite/x86_64-unknown-linux-gnu/lib/ -isystem /mnt/svn/gcc-trunk/binary-191654-lto-checking-valgrind-disable-bootstrap-disable-graphite/x86_64-unknown-linux-gnu/include -isystem /mnt/svn/gcc-trunk/binary-191654-lto-checking-valgrind-disable-bootstrap-disable-graphite/x86_64-unknown-linux-gnu/sys-include -shared math/.libs/acoshq.o math/.libs/fmodq.o math/.libs/acosq.o math/.libs/frexpq.o math/.libs/rem_pio2q.o math/.libs/asinhq.o math/.libs/hypotq.o math/.libs/remainderq.o math/.libs/asinq.o math/.libs/rintq.o math/.libs/atan2q.o math/.libs/isinfq.o math/.libs/roundq.o math/.libs/atanhq.o math/.libs/isnanq.o math/.libs/scalblnq.o math/.libs/atanq.o math/.libs/j0q.o math/.libs/scalbnq.o math/.libs/cbrtq.o math/.libs/j1q.o math/.libs/signbitq.o math/.libs/ceilq.o math/.libs/jnq.o math/.libs/sincos_table.o math/.libs/complex.o math/.libs/ldexpq.o math/.libs/sincosq.o math/.libs/copysignq.o math/.libs/lgammaq.o math/.libs/sincosq_kernel.o math/.libs/coshq.o math/.libs/llroundq.o math/.libs/sinhq.o math/.libs/cosq.o math/.libs/log10q.o math/.libs/sinq.o math/.libs/cosq_kernel.o math/.libs/log1pq.o math/.libs/sinq_kernel.o math/.libs/erfq.o math/.libs/logq.o math/.libs/sqrtq.o math/.libs/expm1q.o math/.libs/lroundq.o math/.libs/tanhq.o math/.libs/expq.o math/.libs/modfq.o math/.libs/tanq.o math/.libs/fabsq.o math/.libs/nanq.o math/.libs/tgammaq.o math/.libs/finiteq.o math/.libs/nextafterq.o math/.libs/truncq.o math/.libs/floorq.o math/.libs/powq.o math/.libs/fmaq.o math/.libs/cacoshq.o math/.libs/cacosq.o math/.libs/casinhq.o math/.libs/casinq.o math/.libs/catanhq.o math/.libs/catanq.o math/.libs/cimagq.o math/.libs/conjq.o math/.libs/cprojq.o math/.libs/crealq.o math/.libs/fdimq.o math/.libs/fmaxq.o math/.libs/fminq.o math/.libs/ilogbq.o math/.libs/llrintq.o math/.libs/log2q.o math/.libs/lrintq.o math/.libs/nearbyintq.o math/.libs/remquoq.o printf/.libs/addmul_1.o printf/.libs/add_n.o printf/.libs/cmp.o printf/.libs/divrem.o printf/.libs/flt1282mpn.o printf/.libs/fpioconst.o printf/.libs/lshift.o printf/.libs/mul_1.o printf/.libs/mul_n.o printf/.libs/mul.o printf/.libs/printf_fphex.o printf/.libs/printf_fp.o printf/.libs/quadmath-printf.o printf/.libs/rshift.o printf/.libs/submul_1.o printf/.libs/sub_n.o strtod/.libs/strtoflt128.o strtod/.libs/mpn2flt128.o strtod/.libs/tens_in_limb.o-lm -Wl,--version-script=/mnt/svn/gcc-trunk/libquadmath/quadmath.map -Wl,-soname -Wl,libquadmath.so.0 -o .libs/libquadmath.so.0.0.0 /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.4/../../../../x86_64-pc-linux-gnu/bin/ld: math/.libs/fmodq.o: relocation R_X86_64_32S against `.rodata' can not be used when making a shared object; recompile with -fPIC math/.libs/fmodq.o: could not read symbols: Bad value collect2: error: ld returned 1 exit status make[3]: *** [libquadmath.la] Error 1 make[3]: Leaving directory `/home/smatz/build-191654-lto-checking-valgrind-disable-bootstrap-disable-graphite/x86_64-unknown-linux-gnu/libquadmath' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/smatz/build-191654-lto-checking-valgrind-disable-bootstrap-disable-graphite/x86_64-unknown-linux-gnu/libquadmath' make[1]: *** [all-target-libquadmath] Error 2 make[1]: Leaving directory `/home/smatz/build-191654-lto-checking-valgrind-disable-bootstrap-disable-graphite' make: *** [all] Error 2
[Bug other/54692] gcc doesn't build with -Og -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54692 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Summary|[4.8 Regression] gcc|gcc doesn't build with -Og |doesn't build with -Og -g |-g --- Comment #11 from Steven Bosscher steven at gcc dot gnu.org 2012-09-24 18:54:55 UTC --- Not a regression, -Og is new.
[Bug bootstrap/54688] [4.8 regression] violation of implicit restriction No_Elaboration_Code on a-ioexce.ads
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54688 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-09-24 CC||ebotcazou at gcc dot ||gnu.org Component|ada |bootstrap Target Milestone|--- |4.8.0 Summary|[4.8 regression]|[4.8 regression] violation |a-ioexce.ads violation of |of implicit restriction |implicit restriction|No_Elaboration_Code on |No_Elaboration_Code |a-ioexce.ads |breaks Ada bootstrap on | |sparc64-linux | Ever Confirmed|0 |1 --- Comment #1 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-09-24 19:04:29 UTC --- Yep. This is stage 3 so the stage 2 compiler is very likely miscompiled.
[Bug fortran/54618] [OOP] wrong-code with CLASS(...), INTENT(OUT) -- and OPTIONAL or ALLOCATABLE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54618 --- Comment #7 from Tobias Burnus burnus at gcc dot gnu.org 2012-09-24 19:05:24 UTC --- Author: burnus Date: Mon Sep 24 19:05:18 2012 New Revision: 191676 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=191676 Log: 2012-09-24 Tobias Burnus bur...@net-b.de PR fortran/54618 * trans-expr.c (gfc_conv_procedure_call): Fix INTENT(OUT) handling for allocatable BT_CLASS. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c
[Bug fortran/54690] [4.8 Regression] FAIL: gfortran.dg/typebound_operator_(7|13).f03 * (internal compiler error) after revision 191649
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54690 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2012-09-24 19:08:42 UTC --- FIXED by the following commit. Sorry for the breakage. Author: burnus Date: Mon Sep 24 19:05:18 2012 New Revision: 191676 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=191676 Log: 2012-09-24 Tobias Burnus bur...@net-b.de PR fortran/54618 * trans-expr.c (gfc_conv_procedure_call): Fix INTENT(OUT) handling for allocatable BT_CLASS. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c
[Bug bootstrap/54688] [4.8 regression] violation of implicit restriction No_Elaboration_Code on a-ioexce.ads
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54688 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC|ebotcazou at gcc dot| |gnu.org | AssignedTo|unassigned at gcc dot |ebotcazou at gcc dot |gnu.org |gnu.org --- Comment #2 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-09-24 19:15:32 UTC --- Investigating.
[Bug debug/54508] Wrong debug information emitted if data members not referenced
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54508 --- Comment #3 from Paul Koning paul_koning at dell dot com 2012-09-24 19:32:21 UTC --- Created attachment 28260 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28260 Fix and testcase for this, as submitted to the gcc-bugs list I'm not sure if the main submission should be here or to gcc-bugs -- I posted a fix there a week ago. Attached is what I submitted (including a small adjustment to the regexp used in the testcase file).
[Bug bootstrap/54281] [4.8 Regression] Fails to bootstrap with --disable-nls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54281 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #13 from Tobias Burnus burnus at gcc dot gnu.org 2012-09-24 19:41:16 UTC --- This patch kind of caused PR bootstrap/54281.
[Bug bootstrap/54281] [4.8 Regression] Fails to bootstrap with --disable-nls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54281 --- Comment #14 from Tobias Burnus burnus at gcc dot gnu.org 2012-09-24 19:43:07 UTC --- (In reply to comment #13) This patch kind of caused PR bootstrap/54281. [which is this PR ...] I meant another PR, namely PR bootstrap/54659.
[Bug libstdc++/44436] [C++0x] Implement emplace* in associative containers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44436 --- Comment #32 from François Dumont fdumont at gcc dot gnu.org 2012-09-24 19:53:46 UTC --- Author: fdumont Date: Mon Sep 24 19:53:36 2012 New Revision: 191679 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=191679 Log: 2012-09-24 François Dumont fdum...@gcc.gnu.org PR libstdc++/44436 * include/bits/stl_tree.h (_Rb_tree::_M_insert_): Take _Base_ptr rather than _Const_Base_ptr. (_Rb_tree::_M_insert_node): New. (_Rb_tree::_M_get_insert_unique_pos): New, search code of _M_insert_unique method. (_Rb_tree::_M_insert_unique): Use latter. (_Rb_tree::_M_emplace_unique): New, likewise. (_Rb_tree::_M_get_insert_equal_pos): New, search code of _M_insert_equal method. (_Rb_tree::_M_insert_equal): Use latter. (_Rb_tree::_M_emplace_equal): New, likewise. (_Rb_tree::_M_get_insert_hint_unique_pos): New, search code of _M_insert_unique_ method. (_Rb_tree::_M_insert_unique_): Use latter. (_Rb_tree::_M_emplace_hint_unique): New, likewise. (_Rb_tree::_M_get_insert_hint_equal_pos): New, search code of _M_insert_equal_ method. (_Rb_tree::_M_insert_equal_): Use latter. (_Rb_tree::_M_emplace_hint_equal): New, likewise. (_Rb_tree::_M_insert_lower): Remove first _Base_ptr parameter, useless as always null. * include/bits/stl_map.h: Include tuple in C++11. (map::operator[](const key_type)): Use _Rb_tree::_M_emplace_hint_unique in C++11. (map::operator[](key_type)): Likewise. (map::emplace): New. (map::emplace_hint): New. * include/bits/stl_multimap.h (multimap::emplace): New. (multimap::emplace_hint): New. * include/bits/stl_set.h (set::emplace): New. (set::emplace_hint): New. * include/bits/stl_multiset.h (multiset::emplace): New. (multiset::emplace_hint): New. * include/debug/map.h (std::__debug::map::emplace): New. (std::__debug::map::emplace_hint): New. * include/debug/multimap.h (std::__debug::multimap::emplace): New. (std::__debug::multimap::emplace_hint): New. * include/debug/set.h (std::__debug::set::emplace): New. (std::__debug::set::emplace_hint): New. * include/debug/multiset.h (std::__debug::multiset::emplace): New. (std::__debug::multiset::emplace_hint): New. * include/profile/map.h (std::__profile::map::emplace): New. (std::__profile::map::emplace_hint): New. * include/profile/multimap.h (std::__profile::multimap::emplace): New. (std::__profile::multimap::emplace_hint): New. * include/profile/set.h (std::__profile::set::emplace): New. (std::__profile::set::emplace_hint): New. * include/profile/multiset.h (std::__profile::multiset::emplace): New. (std::__profile::multiset::emplace_hint): New. * testsuite/util/testsuite_container_traits.h: Signal that emplace and emplace_hint are available on std::map, std::multimap, std::set and std::multiset in C++11. * testsuite/23_containers/map/operators/2.cc: New. * testsuite/23_containers/map/modifiers/emplace/1.cc: New. * testsuite/23_containers/multimap/modifiers/emplace/1.cc: New. * testsuite/23_containers/set/modifiers/emplace/1.cc: New. * testsuite/23_containers/multiset/modifiers/emplace/1.cc: New. Added: trunk/libstdc++-v3/testsuite/23_containers/map/modifiers/emplace/ trunk/libstdc++-v3/testsuite/23_containers/map/modifiers/emplace/1.cc trunk/libstdc++-v3/testsuite/23_containers/map/operators/2.cc trunk/libstdc++-v3/testsuite/23_containers/multimap/modifiers/emplace/ trunk/libstdc++-v3/testsuite/23_containers/multimap/modifiers/emplace/1.cc trunk/libstdc++-v3/testsuite/23_containers/multiset/modifiers/emplace/ trunk/libstdc++-v3/testsuite/23_containers/multiset/modifiers/emplace/1.cc trunk/libstdc++-v3/testsuite/23_containers/set/modifiers/emplace/ trunk/libstdc++-v3/testsuite/23_containers/set/modifiers/emplace/1.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/stl_map.h trunk/libstdc++-v3/include/bits/stl_multimap.h trunk/libstdc++-v3/include/bits/stl_multiset.h trunk/libstdc++-v3/include/bits/stl_set.h trunk/libstdc++-v3/include/bits/stl_tree.h trunk/libstdc++-v3/include/debug/map.h trunk/libstdc++-v3/include/debug/multimap.h trunk/libstdc++-v3/include/debug/multiset.h trunk/libstdc++-v3/include/debug/set.h trunk/libstdc++-v3/include/profile/map.h trunk/libstdc++-v3/include/profile/multimap.h trunk/libstdc++-v3/include/profile/multiset.h trunk/libstdc++-v3/include/profile/set.h trunk/libstdc++-v3/testsuite/util/testsuite_container_traits.h
[Bug tree-optimization/54674] [4.8 Regression] ICE in build2_stat, at tree.c:3835
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54674 --- Comment #8 from Oleg Endo olegendo at gcc dot gnu.org 2012-09-24 20:11:03 UTC --- (In reply to comment #7) I'm working on a patch to avoid introducing a multiply by a pointer type, such as happened here. The interesting thing is that this doesn't look like a profitable transformation on most architectures. It appears that a multiply of two registers and an add of two registers may be given the same RTL cost in the SH family? It seems unlikely that those two operations have the same cost in practice, so it might be worth looking into whether the cost model for this target is fully implemented. I just checked the rtx_costs code on SH. You are right, plus/minus and mul might return the same cost. The cost function for mul doesn't even look at the operands to see whether they are regs, consts etc. This could probably be corrected, although I'm not sure of the consequences. I'll have to try it out. It seems that the mul costs return the number of insns a mul costs, not taking into account that mul insn execution time usually takes longer. The explanation why this ICE happens only for -Os seems to be sh.c (multcosts): if (optimize_size) return 2; return 3; Probably this was put like that to discourage conversions of muls into plus/shift insns when optimizing for size. The mul cost number could be made to be always higher than plus/minus, but there's also a target option that allows the user to specify the mul cost, which would then always return the fixed specified cost number. So I don't think it's a safe thing to rely on (that mul costs are always plus/minus costs). For example, I'd catch power-of-two mul constants and return the shift costs, which then again would be the same as plus/minus for those constants.
[Bug other/54671] [4.7/4.8 Regression] gcc 4.7.2 -Wl,--no-ctors-in-init-array causes binutils test failure, works with 4.7.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54671 --- Comment #3 from ncahill_alt at yahoo dot com 2012-09-24 20:14:04 UTC --- From what I understand, gold's failing test assumes that gcc will make available in general the old functionality, functionality that certain BSD derived systems lacking the .init_array ELF section require(d), but which glibc has not used in 10 years. What can I say, the test is wrong. I will report this to binutils, that the initpri3b test should disclaim or run only when the system-default is a separate .ctors section. Thank you, Jakub, for the quick response and clarification. Neil.
[Bug tree-optimization/54674] [4.8 Regression] ICE in build2_stat, at tree.c:3835
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54674 --- Comment #9 from William J. Schmidt wschmidt at gcc dot gnu.org 2012-09-24 20:32:34 UTC --- To be clear, SLSR doesn't rely on mult costs being greater than int costs -- it simply trusts that the given costs are accurate and makes decisions based upon them. Don't worry about the power-of-two shift cases. The logic in expmed.c that SLSR, IVOPTS, and other passes rely on figures out whether a multiply-by-coefficient can be replaced by a combination of shifts/adds/subtracts based on the costs of those items versus the cost of a multiply. It's just that, as things stand, it will never believe those replacements are better since a general multiply appears to be so cheap (even a single shift/add will only be equal to a general multiply). Probably you will get some overall code gen improvement by just raising the cost of the general multiply to reflect the average cycles for a multiply of unknown values.
[Bug preprocessor/54694] New: internal compiler error: in dwarf2out_frame_debug_expr, at dwarf2out.c:2387
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54694
Bug #: 54694
Summary: internal compiler error: in
dwarf2out_frame_debug_expr, at dwarf2out.c:2387
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: toralf.foers...@gmx.de
I originally reported it here https://bugs.gentoo.org/show_bug.cgi?id=434908
but t could not be reproduced by one gentoo dev, nevertheless here again :
n22 /var/tmp/portage/app-emulation/qemu-kvm-1.1.1-r3/work/qemu-kvm-1.1.1 # make
V=1
make
BUILD_DIR=/var/tmp/portage/app-emulation/qemu-kvm-1.1.1-r3/work/qemu-kvm-1.1.1
-C libhw64 V=1 TARGET_DIR=libhw64/ all
make[1]: Entering directory
`/var/tmp/portage/app-emulation/qemu-kvm-1.1.1-r3/work/qemu-kvm-1.1.1/libhw64'
make[1]: Leaving directory
`/var/tmp/portage/app-emulation/qemu-kvm-1.1.1-r3/work/qemu-kvm-1.1.1/libhw64'
make
BUILD_DIR=/var/tmp/portage/app-emulation/qemu-kvm-1.1.1-r3/work/qemu-kvm-1.1.1
-C libdis V=1 TARGET_DIR=libdis/ all
make[1]: Entering directory
`/var/tmp/portage/app-emulation/qemu-kvm-1.1.1-r3/work/qemu-kvm-1.1.1/libdis'
make[1]: Leaving directory
`/var/tmp/portage/app-emulation/qemu-kvm-1.1.1-r3/work/qemu-kvm-1.1.1/libdis'
make
BUILD_DIR=/var/tmp/portage/app-emulation/qemu-kvm-1.1.1-r3/work/qemu-kvm-1.1.1
-C i386-softmmu V=1 TARGET_DIR=i386-softmmu/ all
make[1]: Entering directory
`/var/tmp/portage/app-emulation/qemu-kvm-1.1.1-r3/work/qemu-kvm-1.1.1/i386-softmmu'
i686-pc-linux-gnu-gcc
-I/var/tmp/portage/app-emulation/qemu-kvm-1.1.1-r3/work/qemu-kvm-1.1.1/slirp
-I. -I/var/tmp/portage/app-emulation/qemu-kvm-1.1.1-r3/work/qemu-kvm-1.1.1
-I/var/tmp/portage/app-emulation/qemu-kvm-1.1.1-r3/work/qemu-kvm-1.1.1/fpu
-I/var/tmp/portage/app-emulation/qemu-kvm-1.1.1-r3/work/qemu-kvm-1.1.1/linux-headers
-I/var/tmp/portage/app-emulation/qemu-kvm-1.1.1-r3/work/qemu-kvm-1.1.1/tcg
-I/var/tmp/portage/app-emulation/qemu-kvm-1.1.1-r3/work/qemu-kvm-1.1.1/tcg/i386
-fPIE -DPIE -m32 -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64
-D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef
-Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing
-fstack-protector-all -Wendif-labels -Wmissing-include-dirs -Wempty-body
-Wnested-externs -Wformat-security -Wformat-y2k -Winit-self
-Wignored-qualifiers -Wold-style-declaration -Wold-style-definition
-Wtype-limits -I/usr/include/libpng15 -DHAS_AUDIO -DHAS_AUDIO_CHOICE
-DTARGET_PHYS_ADDR_BITS=64 -I../linux-headers -I..
-I/var/tmp/portage/app-emulation/qemu-kvm-1.1.1-r3/work/qemu-kvm-1.1.1/target-i386
-DNEED_CPU_H -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
-I/var/tmp/portage/app-emulation/qemu-kvm-1.1.1-r3/work/qemu-kvm-1.1.1/include
-I/usr/include/libpng15 -fomit-frame-pointer -MMD -MP -MT op_helper.o -MF
./op_helper.d -O2 -O2 -march=native -pipe -c -o op_helper.o
/var/tmp/portage/app-emulation/qemu-kvm-1.1.1-r3/work/qemu-kvm-1.1.1/target-i386/op_helper.c
/var/tmp/portage/app-emulation/qemu-kvm-1.1.1-r3/work/qemu-kvm-1.1.1/target-i386/op_helper.c:
In function ‘helper_flds_FT0’:
/var/tmp/portage/app-emulation/qemu-kvm-1.1.1-r3/work/qemu-kvm-1.1.1/target-i386/op_helper.c:3650:1:
internal compiler error: in dwarf2out_frame_debug_expr, at dwarf2out.c:2387
Please submit a full bug report,
with preprocessed source if appropriate.
See http://bugs.gentoo.org/ for instructions.
{standard input}: Assembler messages:
{standard input}: Error: open CFI at the end of file; missing .cfi_endproc
directive
make[1]: *** [op_helper.o] Error 1
make[1]: Leaving directory
`/var/tmp/portage/app-emulation/qemu-kvm-1.1.1-r3/work/qemu-kvm-1.1.1/i386-softmmu'
make: *** [subdir-i386-softmmu] Error 2
[Bug tree-optimization/54674] [4.8 Regression] ICE in build2_stat, at tree.c:3835
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54674 --- Comment #10 from Oleg Endo olegendo at gcc dot gnu.org 2012-09-24 21:26:16 UTC --- (In reply to comment #9) To be clear, SLSR doesn't rely on mult costs being greater than int costs -- it simply trusts that the given costs are accurate and makes decisions based upon them. Don't worry about the power-of-two shift cases. The logic in expmed.c that SLSR, IVOPTS, and other passes rely on figures out whether a multiply-by-coefficient can be replaced by a combination of shifts/adds/subtracts based on the costs of those items versus the cost of a multiply. It's just that, as things stand, it will never believe those replacements are better since a general multiply appears to be so cheap (even a single shift/add will only be equal to a general multiply). Probably you will get some overall code gen improvement by just raising the cost of the general multiply to reflect the average cycles for a multiply of unknown values. Yeah, good point. I'll try it out and see what happens.
[Bug target/54457] [x32] Fail to combine 64bit index + constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54457 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-09-24 AssignedTo|unassigned at gcc dot |ubizjak at gmail dot com |gnu.org | Ever Confirmed|0 |1 --- Comment #2 from Uros Bizjak ubizjak at gmail dot com 2012-09-24 22:48:37 UTC --- Created attachment 28261 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28261 Proposed patch Patch that enhances combine_simplify_rtx to generate canonical binop sequences that simplify_plus_minus can recognize and further optimize. Bootstrapped and regression tested on x86_64-pc-linux-gnu. Patched gcc generates expected code for the above testcase: foo: movzbl array+1(%edi), %eax ret
[Bug rtl-optimization/54457] [x32] Fail to combine 64bit index + constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54457 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Component|target |rtl-optimization Target Milestone|--- |4.8.0
[Bug rtl-optimization/54457] [x32] Fail to combine 64bit index + constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54457 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Attachment #28261|0 |1 is obsolete|| --- Comment #3 from Uros Bizjak ubizjak at gmail dot com 2012-09-25 00:00:51 UTC --- Created attachment 28262 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28262 Updated patch
[Bug target/50457] SH2A atomic functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50457 --- Comment #4 from Kazumoto Kojima kkojima at gcc dot gnu.org 2012-09-25 00:53:23 UTC --- (In reply to comment #3) I don't know how linux/glibc have been handling atomic ops on SH2 or SH2A, but I've got an idea that would work in a bare-metal setup. There is no glibc port for SH2* and highly unlikely someone will add it. SH2* linux uses and will use totally different environment instead of glibc/nptl. Those CPUs have no user/privilege modes and folks tend to use disable/enable interrupts for the atomicity on them like as in #0. *-linux configuration of gcc assumes glibc/nptl everywhere. It means that only sh[34]*-linux configuration will work well. For this PR, the current atomic functions or builtins should be disabled for sh2*-linux configuration and add something that works on SH2*. You would have a free hand to the implementation in this case, since currently there is nothing correct for SH2*.
[Bug middle-end/54630] [4.8 Regression] GCC 4.8 --enable-languages=c build fails: Undefined symbols: ___cxa_guard_acquire and ___cxa_guard_release
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54630
--- Comment #9 from Larry Baker baker at usgs dot gov 2012-09-25 01:53:01 UTC
---
The build on Linux i386 works fine without --with-host-libstdcxx. I believe
g++ is used for linking.
I tried using a native Linux i386 GCC 4.7.1 to build a cross GCC 4.8.0, with
--with-host-libstdcxx='-static-libgcc -static-libstdc++'. That fails with the
same error I encountered before: undefined references to __cxa_guard_acquire
and __cxa_guard_release in the link step. I am sure this is because gcc was
used and libstdc++ was not searched because I did not include -lstdc++ in
--with-host-libstdcxx.
Lastly, I hacked gcc/Makefile.in to always use g++ for the linker:
# Libraries to use on the host.
HOST_LIBS = @HOST_LIBS@
# The name of the compiler to use.
COMPILER = $(CXX)
COMPILER_FLAGS = $(CXXFLAGS)
# If HOST_LIBS is set, then the user is controlling the libraries to
# link against. In that case, link with $(CC) so that the -lstdc++
# library is not introduced. If HOST_LIBS is not set, link with
# $(CXX) to pick up -lstdc++.
#--- ifeq ($(HOST_LIBS),)
LINKER = $(CXX)
LINKER_FLAGS = $(CXXFLAGS)
#--- else
#--- LINKER = $(CC)
#--- LINKER_FLAGS = $(CFLAGS)
#--- endif
# ( cd cross-gcc-4.8.0-experimental ;
PATH=/usr/local/gcc-4.7.1/bin:${PWD}/../freescale-coldfire-2011.09/bin:${PATH/.:/}
CC_FOR_BUILD=gcc CC=gcc CXX=g++ AR=ar RANLIB=ranlib
AS_FOR_TARGET=m68k-uclinux-as LD_FOR_TARGET=m68k-uclinux-ld
AR_FOR_TARGET=m68k-uclinux-ar RANLIB_FOR_TARGET=m68k-uclinux-ranlib
NM_FOR_TARGET=m68k-uclinux-nm OBJDUMP_FOR_TARGET=m68k-uclinux-objdump
STRIP_FOR_TARGET=m68k-uclinux-strip ${PWD}/../gcc-4.8.0-experimental/configure
--disable-decimal-float --disable-fixed-point --disable-libffi
--disable-libgomp --disable-libmudflap --disable-libquadmath --disable-libssp
--disable-libstdcxx-pch --disable-nls --disable-shared --enable-languages=c,c++
--enable-lto --enable-poison-system-directories --enable-threads
--prefix=/usr/local/gcc-4.8.0 --program-prefix=m68k-uclinux-
--target=m68k-uclinux --with-arch=cf --with-gnu-as --with-gnu-ld
--with-build-time-tools=${PWD}/../freescale-coldfire-2011.09/m68k-uclinux/bin
--with-host-libstdcxx='-static-libgcc -static-libstdc++'
--with-sysroot=${PWD}/../freescale-coldfire-2011.09/m68k-uclinux/libc )
# ( cd cross-gcc-4.8.0-experimental ;
PATH=/usr/local/gcc-4.7.1/bin:${PWD}/../freescale-coldfire-2011.09/bin:${PATH/.:/}
make -j4 )
# ( cd cross-gcc-4.8.0-experimental ;
PATH=/usr/local/gcc-4.7.1/bin:${PWD}/../freescale-coldfire-2011.09/bin:${PATH/.:/}
make install )
This works fine. This is as close as I could get to supplying
LDFLAGS_FOR_BUILD='-static-libgcc -static-libstdc++' to the link step without
causing LINKER=gcc.
[Bug fortran/54695] New: Bogus warning for module variable in USE statement with -Wall
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54695 Bug #: 54695 Summary: Bogus warning for module variable in USE statement with -Wall Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: spam.brian.tay...@gmail.com Created attachment 28263 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28263 Fortran source file that generates bogus warning when compiled with -Wall When compiled with -Wall, gfortran gives a bogus warning with the attached code. Clearly, the module variable b has not been imported, yet gfortran warns about it being explicitly imported. This only seems to be triggered by module variables that are stored in common blocks. user@host $ gfortran-4.7 -Wall -c bogus_warning.f90 bogus_warning.f90:8.4: use mod, only: a 1 Warning: Unused module variable 'b' which has been explicitly imported at (1) user@host $ gfortran-4.7 --version GNU Fortran (GCC) 4.7.0 Copyright (C) 2012 Free Software Foundation, Inc. user@host $ uname -a Darwin MBP.local 11.4.0 Darwin Kernel Version 11.4.0: Mon Apr 9 19:32:15 PDT 2012; root:xnu-1699.26.8~1/RELEASE_X86_64 x86_64
[Bug c/54696] New: Makefile doesn't propagate CPPFLAGS properly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54696 Bug #: 54696 Summary: Makefile doesn't propagate CPPFLAGS properly Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: noah.b.lav...@gmail.com I tried to build GCC 4.7.2 from the source tarball, specifying a -I option in CPPFLAGS because I keep header files in a nonstandard place (~/.nix-profile/include). Unfortunately, gcc failed to build. Instead it produced the error gcc -I../.././libcpp -I. -I../.././libcpp/../include -I../.././libcpp/include -g -fkeep-inline-functions -W -Wall -Wwrite-strings -Wmissing-format-attribute -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wc++-compat -pedantic -Wno-long-long -I../.././libcpp -I. -I../.././libcpp/../include -I../.././libcpp/include -c -o charset.o -MT charset.o -MMD -MP -MF .deps/charset.Tpo ../.././libcpp/charset.c In file included from ../.././libcpp/charset.c:22:0: ../.././libcpp/system.h:276:21: fatal error: libintl.h: No such file or directory compilation terminated. But libintl.h exists in ~/.nix-profile/include. The problem is clear: the -I statement from CPPFLAGS is not being used. This particular statement is part of compiling libcpp, so I looked at the makefile for libcpp, and found this line: CPPFLAGS = This is the problem. It seems clear that what is happening is that the CPPFLAGS that I use when I configure the main GCC executable are not being passed on to the configuration script for libcpp, which then doesn't know where to find libintl. When I edit the makefile by hand to set CPPFLAGS correctly, the build gets past that point. One odd note is that I also pass LDFLAGS, and that *is* passed on to libcpp. So it is not that all environment variables aren't propagated.
[Bug fortran/54695] Bogus warning for module variable in USE statement with -Wall
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54695 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||kargl at gcc dot gnu.org Resolution||WORKSFORME --- Comment #1 from kargl at gcc dot gnu.org 2012-09-25 02:45:34 UTC --- It seems to be fixed in 4.7.2 and trunk. Thanks for the bug report.
[Bug testsuite/54697] New: testsuite in gcc 4.7.x leaves zombie processes.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54697 Bug #: 54697 Summary: testsuite in gcc 4.7.x leaves zombie processes. Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassig...@gcc.gnu.org ReportedBy: ht...@users.sourceforge.net After trying to systematically re-test recent version of gcc on alphaev68-dec-osf5.1a for other issues, I see a fair number of zombie processes from 4.7.x: (I was testing all versions from 4.3.x onwards, so only 4.7.x. leaves zombie processes behind) 14360 ?? T0:00.42 /home/htl10/tmp-build/gcc-4.7.1-build/gcc/testsuite/gcc/atomic-other-int.exe 163379 ?? T0:00.37 /home/htl10/tmp-build/gcc-4.7.2-build4/gcc/testsuite/gcc/atomic-other-longlong.exe 19924 ?? T0:00.22 /home/htl10/tmp-build/gcc-4.7.1-build/gcc/testsuite/gcc/atomic-other-longlong.exe 212548 ?? T0:00.15 /home/htl10/tmp-build/gcc-4.7.1-build/gcc/testsuite/g++/bitfields-4.exe 23369 ?? T0:00.81 /home/htl10/tmp-build/gcc-4.7.1-build/gcc/testsuite/gcc/atomic-other-short.exe 271603 ?? T0:00.38 /home/htl10/tmp-build/gcc-4.7.0-build/gcc/testsuite/gcc/atomic-other-int.exe 272885 ?? T0:00.28 /home/htl10/tmp-build/gcc-4.7.0-build/gcc/testsuite/gcc/atomic-other-int.exe 280126 ?? T0:00.69 /home/htl10/tmp-build/gcc-4.7.0-build/gcc/testsuite/gcc/atomic-other-short.exe 377160 ?? T0:00.39 /home/htl10/tmp-build/gcc-4.7.1-build/gcc/testsuite/gcc/atomic-other-short.exe 414670 ?? T0:00.79 /home/htl10/tmp-build/gcc-4.7.1-build4/gcc/testsuite/gcc/atomic-other-longlong.exe 414820 ?? T0:00.15 /home/htl10/tmp-build/gcc-4.7.1-build/gcc/testsuite/g++/atomics-2.exe 427365 ?? T0:00.27 /home/htl10/tmp-build/gcc-4.7.2-build/gcc/testsuite/gcc/atomic-other-int.exe
[Bug testsuite/54698] New: make -j 3 -k check, trying to do parallel check at the top level, go around in circles.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54698 Bug #: 54698 Summary: make -j 3 -k check, trying to do parallel check at the top level, go around in circles. Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassig...@gcc.gnu.org ReportedBy: ht...@users.sourceforge.net make -j 3 -k check, trying to do parallel check at the top level, go around in circles. I tried that to save some time, but want to make sure I have a full report, and noticed that some targets are remade over and over. (perhaps failure was never registered, etc).
[Bug testsuite/54698] make -j 3 -k check, trying to do parallel check at the top level, go around in circles.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54698 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-09-25 03:44:32 UTC --- It works for me and I have been using -j5 even -j32 recently too.
[Bug testsuite/54698] make -j 3 -k check, trying to do parallel check at the top level, go around in circles.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54698 --- Comment #2 from Hin-Tak Leung htl10 at users dot sourceforge.net 2012-09-25 03:53:58 UTC --- (In reply to comment #1) It works for me and I have been using -j5 even -j32 recently too. with -k?
[Bug libstdc++/54448] many failures with /sbin/loader: Error: libstdc++.so.6: symbol __pthread_mutex_init unresolved
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54448 Hin-Tak Leung htl10 at users dot sourceforge.net changed: What|Removed |Added Known to work||4.3.3, 4.3.6, 4.4.1, 4.4.7 Known to fail||4.5.0, 4.5.4 --- Comment #2 from Hin-Tak Leung htl10 at users dot sourceforge.net 2012-09-25 04:41:14 UTC --- See my testsuite results for various versions submitted on 25 sept 2012: http://gcc.gnu.org/ml/gcc-testresults/2012-09/ The issue seems to happen with 4.5.0.
