[Bug tree-optimization/48739] [4.5/4.6/4.7 Regression] ICE in check_loop_closed_ssa_use() with "-ftree-parallelize-loops=2 -fno-tree-dominator-opts"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48739 --- Comment #5 from Jakub Jelinek 2011-08-20 07:48:41 UTC --- Author: jakub Date: Sat Aug 20 07:48:35 2011 New Revision: 177924 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=177924 Log: PR tree-optimization/48739 * tree-ssa.c: Include cfgloop.h. (execute_update_addresses_taken): When updating ssa, if in loop closed SSA form, call rewrite_into_loop_closed_ssa instead of update_ssa. * Makefile.in (tree-ssa.o): Depend on $(CFGLOOP_H). * gcc.dg/pr48739-1.c: New test. * gcc.dg/pr48739-2.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr48739-1.c trunk/gcc/testsuite/gcc.dg/pr48739-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa.c
[Bug tree-optimization/48739] [4.5/4.6/4.7 Regression] ICE in check_loop_closed_ssa_use() with "-ftree-parallelize-loops=2 -fno-tree-dominator-opts"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48739 --- Comment #6 from Jakub Jelinek 2011-08-20 07:51:12 UTC --- Author: jakub Date: Sat Aug 20 07:51:09 2011 New Revision: 177925 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=177925 Log: PR tree-optimization/48739 * tree-ssa.c: Include cfgloop.h. (execute_update_addresses_taken): When updating ssa, if in loop closed SSA form, call rewrite_into_loop_closed_ssa instead of update_ssa. * Makefile.in (tree-ssa.o): Depend on $(CFGLOOP_H). * gcc.dg/pr48739-1.c: New test. * gcc.dg/pr48739-2.c: New test. Added: branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/pr48739-1.c branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/pr48739-2.c Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/Makefile.in branches/gcc-4_6-branch/gcc/testsuite/ChangeLog branches/gcc-4_6-branch/gcc/tree-ssa.c
[Bug tree-optimization/48739] [4.5 Regression] ICE in check_loop_closed_ssa_use() with "-ftree-parallelize-loops=2 -fno-tree-dominator-opts"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48739 Jakub Jelinek changed: What|Removed |Added Summary|[4.5/4.6/4.7 Regression]|[4.5 Regression] ICE in |ICE in |check_loop_closed_ssa_use() |check_loop_closed_ssa_use() |with |with|"-ftree-parallelize-loops=2 |"-ftree-parallelize-loops=2 |-fno-tree-dominator-opts" |-fno-tree-dominator-opts" | --- Comment #7 from Jakub Jelinek 2011-08-20 07:57:04 UTC --- Fixed for 4.6+ so far.
[Bug target/50131] Optimize x = -1 with "or" for -O
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50131 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek 2011-08-20 08:32:12 UTC --- Is or $-1, reg on all CPUs equally expensive to mov $-1, reg though (as or generally needs the previous reg content while mov does not; I know some CPUs special case xor reg, reg, but I doubt or $-1, reg is special cased)?
[Bug c++/50134] -Wmissing-prototypes doesn't work for C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50134 --- Comment #1 from Andreas Schwab 2011-08-20 08:37:21 UTC --- -Wmissing-declaration should do what you want.
[Bug middle-end/50137] New: [4.7 Regression] ppc64/libstdc++-v3 is miscompiled on powerpc-apple-darwin9 since revision 177691
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50137 Bug #: 50137 Summary: [4.7 Regression] ppc64/libstdc++-v3 is miscompiled on powerpc-apple-darwin9 since revision 177691 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr CC: dnovi...@google.com, ia...@gcc.gnu.org, rguent...@suse.de Host: powerpc-apple-darwin9 Target: powerpc-apple-darwin9 Build: powerpc-apple-darwin9 On powerpc-apple-darwin9 after revision 177691, I get the following failures in the libstdc++-v3 test suite with -m64: Running target unix/-m64 FAIL: 22_locale/money_get/get/char/19.cc execution test FAIL: 22_locale/money_get/get/char/38399.cc execution test FAIL: 22_locale/money_get/get/char/39168.cc execution test FAIL: 22_locale/money_get/get/wchar_t/19.cc execution test FAIL: 22_locale/money_get/get/wchar_t/38399.cc execution test FAIL: 22_locale/money_get/get/wchar_t/39168.cc execution test FAIL: 22_locale/num_get/get/char/10.cc execution test FAIL: 22_locale/num_get/get/char/12.cc execution test FAIL: 22_locale/num_get/get/char/15.cc execution test FAIL: 22_locale/num_get/get/char/22131.cc execution test FAIL: 22_locale/num_get/get/char/39168.cc execution test FAIL: 22_locale/num_get/get/char/7.cc execution test FAIL: 22_locale/num_get/get/wchar_t/10.cc execution test FAIL: 22_locale/num_get/get/wchar_t/12.cc execution test FAIL: 22_locale/num_get/get/wchar_t/15.cc execution test FAIL: 22_locale/num_get/get/wchar_t/22131.cc execution test FAIL: 22_locale/num_get/get/wchar_t/39168.cc execution test FAIL: 22_locale/num_get/get/wchar_t/7.cc execution test FAIL: 22_locale/time_get/get_date/char/1.cc execution test FAIL: 22_locale/time_get/get_date/char/12791.cc execution test FAIL: 22_locale/time_get/get_date/wchar_t/1.cc execution test FAIL: 22_locale/time_get/get_date/wchar_t/12791.cc execution test FAIL: 22_locale/time_get/get_monthname/char/1.cc execution test FAIL: 22_locale/time_get/get_monthname/wchar_t/1.cc execution test FAIL: 22_locale/time_get/get_time/char/4.cc execution test FAIL: 22_locale/time_get/get_time/wchar_t/4.cc execution test FAIL: 22_locale/time_get/get_weekday/char/1.cc execution test FAIL: 22_locale/time_get/get_weekday/wchar_t/1.cc execution test FAIL: 22_locale/time_get/get_year/char/1.cc execution test FAIL: 22_locale/time_get/get_year/wchar_t/1.cc execution test FAIL: ext/mt_allocator/deallocate_global_thread-1.cc execution test FAIL: ext/mt_allocator/deallocate_global_thread-3.cc execution test === libstdc++ Summary === # of expected passes7201 # of unexpected failures32 # of expected failures46 # of unsupported tests723 Reverting revision 177691 gives Running target unix/-m64 FAIL: ext/mt_allocator/deallocate_global_thread-1.cc execution test FAIL: ext/mt_allocator/deallocate_global_thread-3.cc execution test === libstdc++ Summary === # of expected passes7231 # of unexpected failures2 # of expected failures46 # of unsupported tests723 Compiler version: 4.7.0 20110818 (experimental) [trunk revision 177878p2] (GCC) Platform: powerpc-apple-darwin9.8.0 configure flags: --prefix=/opt/gcc/gcc4.7w --enable-languages=c,c++,fortran,objc,obj-c++,java,lto --with-gmp=/sw --with-libiconv-prefix=/usr --with-system-zlib --with-cloog=/sw --enable-lto --enable-cloog-backend=isl (where the last two failures are pr47762). Note that I have to rebuild ppc64/libstdc++-v3 to see the failures disappear; this is why I think the library is miscompiled. Would it be possible to infer from the failures what is (are) the file(s) that is (are) miscompiled?
[Bug tree-optimization/50138] New: ICE in vect_transform_stmt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50138 Bug #: 50138 Summary: ICE in vect_transform_stmt Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: d.g.gorbac...@gmail.com Target: i686-pc-linux-gnu Created attachment 25061 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25061 Compile with `-O3 -DBUG'
[Bug target/50091] [4.5/4.6/4.7 Regression] -fstack-check gives bad assembly on powerpc-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50091
--- Comment #5 from Iain Sandoe 2011-08-20 13:02:19
UTC ---
(In reply to comment #4)
> If I edit the assembly code to have
>
> ...
> stw r0,-12284(r1)
> mr r0,r1
> stw r0,-12556(r1)
> ...
>
> The code assembles, links and runs without further hiccup.
rs6000.md:
(define_insn "probe_stack"
[(set (match_operand 0 "memory_operand" "=m")
(unspec [(const_int 0)] UNSPEC_PROBE_STACK))]
""
"{st%U0%X0|stw%U0%X0} 0,%0"
[(set_attr "type" "store")
(set_attr "length" "4")])
it appears (to one with near zero experience of md files) that the intent of
the insn is to store a value (0) into the location (thus probing the stack).
Presumably, one gets a segfault or bus error in the case of fail.
The i386 equivalent stores $0 into the location ... but I suppose any value or
register would do.
Presumably, for PPC assemblers that don't use the 'r' prefix on the registers,
it will be storing r0 into the slot (effectively, what Dominique's hand-edit is
doing).
I guess there's some really obvious way to fix this... but I don't (yet) know
the syntax of the md stuff ..
[Bug fortran/50129] [4.6/4.7 Regression] ICE on where statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50129 --- Comment #4 from Mikael Morin 2011-08-20 14:22:26 UTC --- Author: mikael Date: Sat Aug 20 14:22:22 2011 New Revision: 177929 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=177929 Log: 2011-08-20 Mikael Morin PR fortran/50129 * parse.c (parse_where): Undo changes after emitting an error. 2011-08-20 Mikael Morin PR fortran/50129 * gfortran.dg/where_3.f90: New test. Added: branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/where_3.f90 Modified: branches/gcc-4_6-branch/gcc/fortran/ChangeLog branches/gcc-4_6-branch/gcc/fortran/parse.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug fortran/50129] [4.6/4.7 Regression] ICE on where statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50129 Mikael Morin changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Mikael Morin 2011-08-20 14:48:39 UTC --- Fixed on trunk (4.7.0) and 4.6 branch (4.6.2).
[Bug target/50091] [4.5/4.6/4.7 Regression] -fstack-check gives bad assembly on powerpc-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50091 --- Comment #6 from Andreas Schwab 2011-08-20 14:49:14 UTC --- "st 0,%0" stores the contents of register 0 at the address pointed to by operand 0. The st insn always operates on registers and cannot take immediate data. There is no modifier that expands to the register prefix. Currently the only way to produce the correct register name is to substitute a suitable register operand.
[Bug fortran/50050] Internal compiler error free_expr0 at expr.c:3709 via gfc_done_2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50050 --- Comment #4 from Mikael Morin 2011-08-20 14:51:40 UTC --- Patch posted at: http://gcc.gnu.org/ml/fortran/2011-08/msg00106.html
[Bug fortran/50046] Hexadecimal Constants
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50046 Mikael Morin changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011-08-20 Ever Confirmed|0 |1 --- Comment #5 from Mikael Morin 2011-08-20 14:54:53 UTC --- Waiting for feedback...
[Bug fortran/49943] libgfortran fails to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49943 Mikael Morin changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011-08-20 CC||mikael at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #4 from Mikael Morin 2011-08-20 14:58:08 UTC --- (In reply to comment #3) > Thank you so much for your suggestions. I'll try it at once. Any news?
[Bug bootstrap/50139] New: in-tree GMP/PPL/CLooG is misconfigured
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50139 Bug #: 50139 Summary: in-tree GMP/PPL/CLooG is misconfigured Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: vanboxem.ru...@gmail.com Created attachment 25062 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25062 Patch When building the Graphite prereqs in-tree mkdir $GCC_SRC/ppl mkdir $GCC_SRC/cloog ln -s $SRC/ppl-0.11.2/* $GCC_SRC/ppl ln -s $SRC/cloog)0.16.3/* $GCC_SRC/cloog All subdirectories are detected well, but as some may or may not know, GMP in tree does not play well with PPL/CLooG in tree, and CLooG(-isl) does not work well in-tree. Attached is a patch to add the necessary paths in the various places, using existing infrastructure. Some notes before you ask yourself what I did: - PPL-0.11.2 has a configure option --with-gmp-build, but it does not seem to work as MPFR/MPC's options do (ie only the linker uses it, the include path still needed to be set by CPPFLAGS). My way is a bit more secure for older versions of PPL as well. - CLooG has an half-documented feature (not in the online docs, but you get it from "configure --help"): --with-gmp-builddir, which is equally broken, as the C compiler test tries to link with gmp. - PPL also needs both the gmp source as gmp build path, because it checks for gmpxx.h, which is not in the build directory, but gmpxx.h includes gmp.h, which is only present in the build directory. The 4.5 and 4.6 branches also work with the CLooG/PPL versions I used here (if built out-of-tree) so a fix for those branches would be very helpful as well.
[Bug libgomp/46967] lots of testsuite failures with libgomp on hppa-hp-hpux11.31
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46967 --- Comment #8 from dave.anglin at bell dot net 2011-08-20 15:45:46 UTC --- The pthread change was applied in r170290. If it doesn't fix the bug, then further debugging is needed. I can say the tests don't fail with 11.11. You also indicated the tests don't fail with 11.23. So, these fails either have to do with differences in linking, or processor architecture. The linking issue mentioned in comment #2 is a libtool issue. It incorrectly links in libc in shared library links. It is possible to hack libtool to not link in libtool on hppa*-*-hpux*. Some other targets do this, so there is sample code. If the non functional pthread stubs are used, races will result causing test failures. The for-*.C tests are especially sensitive to this as they create many threads to parallelize loops. The libtool project is essentially dormant, and none of the maintainers have responded to my patches or bug reports in recent months. I believe there are subtle differences in the behavior of the dynamic linker in different hpux versions. There is also the issue that 11.31 usually only runs on PA8800/PA8900 servers. These CPUs have much larger instruction and data caches (32 MB), and the caches do not support non equivalent aliasing. From experience, I know that it is much more difficult to do a good pthread implementation on these CPUs. More cache flushing is needed than on earlier CPUs, and this changes program timing quite a bit. It's quite tricky to avoid the aliasing issues and cache corruption. -- John David Anglindave.ang...@bell.net
[Bug bootstrap/50010] i386-unknown-freebsd bootstrap comparison failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50010 --- Comment #4 from Gary Funck 2011-08-20 17:03:58 UTC --- We ran a reghunt of sorts and came up with the following results. The first confirmed bootstrap comparison failure occurred after revision 177265 was applied. r177265 | uros | 2011-08-03 03:46:04 -0700 (Wed, 03 Aug 2011) | 9 lines However, the builds before that revision terminated with a compilation error in config/linux/affinity.c, which was fixed by this revision. The compilation error was introduced by this commit: r177194 | jakub | 2011-08-02 09:13:29 -0700 (Tue, 02 Aug 2011) | 238 lines Merge from gomp-3_1-branch branch: Thus, it seems that revision 177194 or a subsequent revision preceding 177265 introduced the bootstrap comparison failure on i386 (we ran our tests on i686 running CentOS).
[Bug bootstrap/50010] [4.7 regression] i386-unknown-freebsd bootstrap comparison failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50010 Gerald Pfeifer changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-08-20 Summary|i386-unknown-freebsd|[4.7 regression] |bootstrap comparison|i386-unknown-freebsd |failure |bootstrap comparison ||failure Ever Confirmed|0 |1 --- Comment #5 from Gerald Pfeifer 2011-08-20 17:56:31 UTC --- This is consistent with my own binary search r177170 2011-08-02 14:55:47 okay r177212 2011-08-02 20:26:57 okay r177216 2011-08-02 21:09:26 okay r177218 2011-08-02 22:18:35 comparison failure which clearly identifies the following commit: 2011-08-02 Richard Henderson PR target/49864 * reg-notes.def (REG_ARGS_SIZE): New. * calls.c (emit_call_1): Emit REG_ARGS_SIZE for call_pop. (expand_call): Add REG_ARGS_SIZE to emit_stack_restore. * cfgcleanup.c (old_insns_match_p): Don't allow cross-jumping to different stack levels. * combine-stack-adj.c (adjust_frame_related_expr): Remove. (maybe_move_args_size_note): New. (combine_stack_adjustments_for_block): Use it. * combine.c (distribute_notes): Place REG_ARGS_SIZE.
[Bug c++/50114] ICE on invalid code in pop_binding, at cp/name-lookup.c:382
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50114
--- Comment #2 from Launchpad 2011-08-20
19:04:30 UTC ---
jas mann added the following comment to Launchpad bug report 827806:
Sorry, I don't know, but I can venture some guesses:
Q. Why did I code in such a manner as to foil parsing of the source?
A. Careless, or worse? The error was obvious of course so in that respect a
crash was as good as a diagnostic.
Q. You want the preprocessor output?
A. It's gone. I thought perhaps the bug reporting script grabbed it.
Q. Why didn't I attach the preprocessor output to the bug report?
A. I guess it wasn't immediately obvious how, and I was in a rush.
Q: What was the code that caused the problem?
A. I don't remember. I corrected it at the time. I should have saved it and
should a similar situation arise in the future I will do so.
Here's the lambda in which the indicated errors used to be if that's any help.
It iterates through a circular list of circular lists.
auto log_serviceorder = [&]() {
const char* F = "%2d. %c[%d] %s id=%d\n";
$LOG(log, BP, TTINF, "service order for %d feeds follows:\n", feedcount);
for(int i=0; i < feedcount; i++) {
circlist::node* feednode =
feedgroups.next()->content.next();
tt::feedhdlr* feed = feednode->content;
$LOG(log,BP,TTINF,F, i,
feed->venue(),feednode->id,feed->name(),feed->id());
}
} ;
> Date: Fri, 19 Aug 2011 09:18:00 +
> From: 827...@bugs.launchpad.net
> To: dotmar...@hotmail.com
> Subject: [Bug 827806]
>
> You know what I'm going to ask... ;)
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/827806
>
> Title:
> cc1plus bails can't handle situation
>
> Status in The GNU Compiler Collection:
> New
> Status in “gcc-4.5” package in Ubuntu:
> Confirmed
> Status in “gcc-4.6” package in Ubuntu:
> Confirmed
>
> Bug description:
> src/bp/bp_b.cc: In lambda function:
> src/bp/bp_b.cc:538:33: error: invalid conversion from
> ‘tt_bookprxor::open_newfeeds()::x2feed*’ to ‘int’
> src/bp/bp_b.cc:539:25: error: base operand of ‘->’ is not a pointer
> src/bp/bp_b.cc:540:24: error: ‘x2feeds_i’ was not declared in this scope
> src/bp/bp_b.cc:540:58: error: return-statement with a value, in function
> returning 'void'
> src/bp/bp_b.cc:545:9: warning: name lookup of ‘x2feed_i’ changed
> src/bp/bp_b.cc:534:46: warning: matches this ‘x2feed_i’ under ISO
> standard rules
> src/bp/bp_b.cc:538:22: warning: matches this ‘x2feed_i’ under old rules
> src/bp/bp_b.cc:545:55: error: cannot convert ‘tt::feedhdlr*’ to
> ‘circlist*’ in assignment
> src/bp/bp_b.cc:546: confused by earlier errors, bailing out
> Preprocessed source stored into /tmp/ccR2q49G.out file, please attach this
> to your bugreport.
>
> ProblemType: Crash
> DistroRelease: Ubuntu 11.04
> Package: g++-4.5 4.5.2-8ubuntu4
> ProcVersionSignature: Ubuntu 2.6.38-10.46-generic 2.6.38.7
> Uname: Linux 2.6.38-10-generic x86_64
> NonfreeKernelModules: nvidia
> Architecture: amd64
> Date: Tue Aug 16 23:24:26 2011
> ExecutablePath: /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.2/cc1plus
> InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release amd64
> (20101007)
> SourcePackage: gcc-4.5
> UpgradeStatus: Upgraded to natty on 2011-05-29 (79 days ago)
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/gcc/+bug/827806/+subscriptions
--
http://launchpad.net/bugs/827806
[Bug fortran/49638] [OOP] length parameter is ignored when overriding type bound character functions with constant length.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49638 --- Comment #20 from janus at gcc dot gnu.org 2011-08-20 19:11:59 UTC --- Author: janus Date: Sat Aug 20 19:11:56 2011 New Revision: 177932 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=177932 Log: 2011-08-20 Janus Weil PR fortran/49638 * dependency.c (gfc_dep_compare_expr): Add new result value "-3". (gfc_check_element_vs_section,gfc_check_element_vs_element): Handle result value "-3". * frontend-passes.c (optimize_comparison): Ditto. * interface.c (gfc_check_typebound_override): Ditto. 2011-08-20 Janus Weil PR fortran/49638 * gfortran.dg/typebound_override_1.f90: Modified. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dependency.c trunk/gcc/fortran/frontend-passes.c trunk/gcc/fortran/interface.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/typebound_override_1.f90
[Bug fortran/49638] [OOP] length parameter is ignored when overriding type bound character functions with constant length.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49638 --- Comment #21 from janus at gcc dot gnu.org 2011-08-20 19:30:44 UTC --- (In reply to comment #19) > ToDo: For many cases one only gets a warning instead of an error right now. r177932 turns some warnings into errors.
[Bug bootstrap/50010] [4.7 regression] i386-unknown-freebsd bootstrap comparison failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50010
--- Comment #6 from Gary Funck 2011-08-20 19:35:11
UTC ---
(In reply to comment #2)
> (In reply to comment #0)
> > x86_64-unknown-freebsd seems to work, and with nobody seeing this on
> > GNU/Linux
> > I am wondering whether this may be due to i386 (vs i586)?
>
> Can you trigger this bug on linux (either x86_64 or i686) using following
> configure string:
>
> CC="gcc -m32" CXX="g++ -m32" /configure i586-linux
On FC14 x86_64, after installing the i686 libraries for
{gmp,libmpc,mpfr}{,-devel}, built against trunk
revision 177922 (last changed 2011-08-19 17:18:07 PDT),
the build completed *without* error.
I'll try trunk revision r177218 (reported by Gerald) for completeness,
and post the results.
[Bug target/50131] Optimize x = -1 with "or" for -O
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50131 --- Comment #3 from H.J. Lu 2011-08-20 19:44:49 UTC --- (In reply to comment #2) > Is or $-1, reg on all CPUs equally expensive to mov $-1, reg though (as or > generally needs the previous reg content while mov does not; I know some CPUs > special case xor reg, reg, but I doubt or $-1, reg is special cased)? We should add a new x86 optimization flag and turn it on only if it helps for the processor to be optimized.
[Bug target/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 --- Comment #69 from hjl at gcc dot gnu.org 2011-08-20 20:02:21 UTC --- Author: hjl Date: Sat Aug 20 20:02:17 2011 New Revision: 177933 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=177933 Log: Use .init_arrary/.fini_array sections if possible. 2011-08-20 H.J. Lu PR other/46770 * config.gcc (tm_file): Add initfini-array.h if .init_arrary/.fini_array are supported. * crtstuff.c: Don't generate .ctors nor .dtors sections if USE_INITFINI_ARRAY is defined. * output.h (default_elf_init_array_asm_out_constructor): New. (default_elf_fini_array_asm_out_destructor): Likewise. * varasm.c (elf_init_array_section): Likewise. (elf_fini_array_section): Likewise. (get_elf_initfini_array_priority_section): Likewise. (default_elf_init_array_asm_out_constructor): Likewise. (default_elf_fini_array_asm_out_destructor): Likewise. * config/initfini-array.h: New. Added: trunk/gcc/config/initfini-array.h Modified: trunk/gcc/ChangeLog trunk/gcc/config.gcc trunk/gcc/crtstuff.c trunk/gcc/output.h trunk/gcc/varasm.c
[Bug other/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770 H.J. Lu changed: What|Removed |Added Status|ASSIGNED|RESOLVED Component|target |other Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #70 from H.J. Lu 2011-08-20 20:06:16 UTC --- Fixed for GCC 4.7.0.
[Bug c++/50140] New: sorry, unimplemented: cannot expand ‘T ...’ into a fixed-length argument list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50140
Bug #: 50140
Summary: sorry, unimplemented: cannot expand ‘T ...’ into a
fixed-length argument list
Classification: Unclassified
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: lcid-f...@gmx.net
Trying to use metaprogramming with variadic templates g++ chokes on the
following code:
template
class Eval
{
public:
bool eval(GLenum value)
{
if( value == One )
return true;
Eval recurse();
// Try out the rest
return recurse.eval(value);
};
};
template<>
class Eval
{
public:
bool eval(GLenum value)
{
return false;
};
};
template
class GLPart
{
protected:
GLPart()
{
};
public:
bool Evaluate(GLenum value)
{
Eval ev();
bool isValid = ev.eval(value);
if( !isValid )
glSetError(GL_INVALID_ENUM);
return isValid;
};
};
which gives the error:
sorry, unimplemented: cannot expand ‘Others ...’ into a fixed-length argument
list
[Bug bootstrap/50010] [4.7 regression] i386-unknown-freebsd bootstrap comparison failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50010
--- Comment #7 from Gary Funck 2011-08-20 20:52:08
UTC ---
(In reply to comment #6)
> On FC14 x86_64, after installing the i686 libraries for
> {gmp,libmpc,mpfr}{,-devel}, built against trunk
> revision 177922 (last changed 2011-08-19 17:18:07 PDT),
> the build completed *without* error.
>
> I'll try trunk revision r177218 (reported by Gerald) for completeness,
> and post the results.
This also completed *without* error.
[Bug bootstrap/50010] [4.7 regression] i386-unknown-freebsd bootstrap comparison failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50010
--- Comment #8 from Gerald Pfeifer 2011-08-20
21:04:56 UTC ---
(In reply to comment #7)
>> On FC14 x86_64, after installing the i686 libraries for
>> {gmp,libmpc,mpfr}{,-devel}, built against trunk
>> revision 177922 (last changed 2011-08-19 17:18:07 PDT),
>> the build completed *without* error.
> This also completed *without* error.
I believe the difference may be i686 versus i486:
config/i386/freesd.h has #define SUBTARGET32_DEFAULT_CPU "i486" and does
not use a different default otherwise.
[Bug c++/50140] [C++0x] sorry, unimplemented: cannot expand ‘T ...’ into a fixed-length argument list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50140 Paolo Carlini changed: What|Removed |Added CC||dodji at gcc dot gnu.org Summary|sorry, unimplemented: |[C++0x] sorry, |cannot expand ‘T ...’ into |unimplemented: cannot |a fixed-length argument |expand ‘T ...’ into a |list|fixed-length argument list --- Comment #1 from Paolo Carlini 2011-08-20 23:13:04 UTC --- Seems related to PR35722. Dodji?
[Bug bootstrap/50010] [4.7 regression] i386-unknown-freebsd bootstrap comparison failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50010 Uros Bizjak changed: What|Removed |Added CC||rth at gcc dot gnu.org --- Comment #9 from Uros Bizjak 2011-08-20 23:15:39 UTC --- (In reply to comment #5) > This is consistent with my own binary search > > r177170 2011-08-02 14:55:47 okay > r177212 2011-08-02 20:26:57 okay > r177216 2011-08-02 21:09:26 okay > r177218 2011-08-02 22:18:35 comparison failure > > which clearly identifies the following commit: > > 2011-08-02 Richard Henderson > > PR target/49864 > * reg-notes.def (REG_ARGS_SIZE): New. > * calls.c (emit_call_1): Emit REG_ARGS_SIZE for call_pop. > (expand_call): Add REG_ARGS_SIZE to emit_stack_restore. > * cfgcleanup.c (old_insns_match_p): Don't allow cross-jumping to > different stack levels. > * combine-stack-adj.c (adjust_frame_related_expr): Remove. > (maybe_move_args_size_note): New. > (combine_stack_adjustments_for_block): Use it. > * combine.c (distribute_notes): Place REG_ARGS_SIZE. Adding some CCs.
[Bug c++/50114] ICE on invalid code in pop_binding, at cp/name-lookup.c:382
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50114 --- Comment #3 from Paolo Carlini 2011-08-20 23:17:42 UTC --- I was winking at Matthias... As he knows well, a reduced testcase (say, below 100 lines) would help a lot, if/when you can.
