[Bug libstdc++/21772] exception safety testing
--- Comment #14 from bkoz at gcc dot gnu dot org 2009-12-17 08:18 --- Created an attachment (id=19333) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19333action=view) part 2 diff after merge of part 1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21772
[Bug middle-end/42398] New: internal compiler error: in sra_modify_expr, at tree-sra.c:2175
Attached testcase from linux kernel fails to compile with latest trunk rev 155302 on mips architecture. options to pass -c -O1 $ mips-oe-linux-gcc y.c -c -O1 y.c: In function ptrace_setregs: y.c:12917:1: internal compiler error: in sra_modify_expr, at tree-sra.c:2175 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- Summary: internal compiler error: in sra_modify_expr, at tree- sra.c:2175 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: raj dot khem at gmail dot com GCC build triplet: x86_64-linux GCC host triplet: x86_64-linux GCC target triplet: mips-oe-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42398
[Bug middle-end/42398] internal compiler error: in sra_modify_expr, at tree-sra.c:2175
--- Comment #1 from raj dot khem at gmail dot com 2009-12-17 08:36 --- Created an attachment (id=19334) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19334action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42398
[Bug target/42377] libstdc++.dll.a misses a definition of std::string::reserve
--- Comment #3 from davek at gcc dot gnu dot org 2009-12-17 09:04 --- This is starting to look like an LD bug. The function is there in the objects fed into the final link: $ x86_64-w64-mingw32-nm -C .libs/string-inst.o | grep reserve t .text$_ZNSs7reserveEy T std::string::reserve(unsigned long long) dkad...@ubik /tmp/mingw-w64/obj-gcc/x86_64-w64-mingw32/libstdc++-v3/src $ and it shows up as linked into the dll in the map file: .text$_ZNSs7reserveEy 0x6fc946b0 0xa0 .libs/string-inst.o 0x6fc946b0__ZNSs7reserveEy but for some reason it doesn't get exported. This only happens in the 64-bit multilib, not the 32-bit one; there it gets exported. So I think we've found an inconsistency between the pe and pe+ emulations in ld. I also get empty dependency_libs in both the $objdir .la files and the installed versions. I followed (more-or-less) the instructions at http://sourceforge.net/apps/trac/mingw-w64/wiki/Cross%20Win32%20and%20Win64%20compiler to build a multilibbed/biarch cygwin-x-w64 cross-compiler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42377
[Bug c++/42399] New: NULL dereference in strcmp at libibery/splay-tree.c:148 (segfault)
I am using an svn checkout of 4.5 trying to play with new c++0x features. I've
tried debugging this myself, but gcc is huge and this is my first foray into
it. I will list what I know.
My checkout information :
$ svn info
Path: .
URL: svn://gcc.gnu.org/svn/gcc/trunk
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 155176
Node Kind: directory
Schedule: normal
Last Changed Author: rguenth
Last Changed Rev: 155174
Last Changed Date: 2009-12-11 13:00:24 -0500 (Fri, 11 Dec 2009)
Running my makefile accomplishes the following :
LD_LIBRARY_PATH=/home/knome/local-gcc/lib /home/knome/local-gcc/bin/g++ -Wall
--pedantic --std=c++0x main.cc
Internal Compiler Error : attempt to lookup fileinfo for NULL.
In static member function static boost::shared_ptrmonad::MonadInnerType,
RsType monad::MonadInnerType, ChainType::result(boost::shared_ptrY)
[with RsType = std::basic_stringchar, InnerType = monad::World, ChainType =
monad::Undefined]:
main.cc:49:65: instantiated from here
cc1plus: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
The error only occurs when using a lambda with copying variable capture. A
lambda with no variable capture or reference capture does not trigger the
segfault.
A backtrace shows the source of the segfault seems to be a null tossed into the
splay_tree_lookup function. I picked around some and found the null was coming
from a LAMBDA_EXPR_LOCATION macro expansion. I put a watch on the
input_location variable using gdb and the last three locations to update it
before segfault are :
Old value = 2634207
New value = 2633833
tsubst_decl (t=0xb7634400, args=value optimized out, complain=3) at
../.././gcc/cp/pt.c:8626
$113790 = 0x8ce5238 main.cc
Hardware watchpoint 7: input_location
Old value = 2633833
New value = 2634207
tsubst_decl (t=value optimized out, args=value optimized out,
complain=value optimized out) at ../.././gcc/cp/pt.c:9381
$113791 = 0x8ce5238 main.cc
Hardware watchpoint 7: input_location
Old value = 2634207
New value = 0
build_lambda_object (lambda_expr=0xb7557aa8) at
../.././gcc/cp/semantics.c:5401
$113792 = 0x0
Internal Compiler Error : attempt to lookup fileinfo for NULL.
Program received signal SIGSEGV, Segmentation fault.
The relevant section in sematics.c being :
if (processing_template_decl)
return lambda_expr;
/* Make sure any error messages refer to the lambda-introducer. */
saved_loc = input_location;
input_location = LAMBDA_EXPR_LOCATION (lambda_expr);
for (node = LAMBDA_EXPR_CAPTURE_LIST (lambda_expr);
node;
node = TREE_CHAIN (node))
{
tree field = TREE_PURPOSE (node);
tree val = TREE_VALUE (node);
I will continue trying to backtrack this to the source, but felt I should
submit it as a bug so that someone with actual knowledge of gcc can have the
chance to find it before I slowly work my way there.
I've been looking through gcc/cp/parser.c trying to step through and see the
bad assignment. I will continue with this sort of tracking as I can.
--
Summary: NULL dereference in strcmp at libibery/splay-tree.c:148
(segfault)
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: knomenet at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42399
[Bug fortran/42144] [OOP] deferred TBPs do not work
--- Comment #8 from janus at gcc dot gnu dot org 2009-12-17 09:28 --- Subject: Bug 42144 Author: janus Date: Thu Dec 17 09:28:25 2009 New Revision: 155305 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155305 Log: gcc/fortran/ 2009-12-17 Janus Weil ja...@gcc.gnu.org PR fortran/42144 * trans-expr.c (select_class_proc): Skip abstract base types. gcc/testsuite/ 2009-12-17 Janus Weil ja...@gcc.gnu.org PR fortran/42144 * gfortran.dg/dynamic_dispatch_6.f03: New test. Added: trunk/gcc/testsuite/gfortran.dg/dynamic_dispatch_6.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42144
[Bug c++/42399] NULL dereference in strcmp at libibery/splay-tree.c:148 (segfault)
--- Comment #1 from knomenet at gmail dot com 2009-12-17 09:29 --- Created an attachment (id=19335) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19335action=view) This is a file that should trigger the segfault. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42399
[Bug tree-optimization/42027] [4.5 Regression] Performance regression in convolution loop optimization
--- Comment #17 from nbenoit at tuxfamily dot org 2009-12-17 09:32 --- (In reply to comment #16) Created an attachment (id=19332) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19332action=view) [edit] Real fix Now, before I blow it again, would you be so kind to test this patch (on top of some recent trunk, doesn't have to be the newest one, you don't need to bootstrap) if it fixes the performance problem. For me it does now, I swear :-) Tested with trunk revision 155304, the regression is gone. * Intel Xeon E5320 (x86_64 arch but gcc machine is i686-pc-linux-gnu), with -O1 flag GCC-4.4.2 7364 ms GCC-trunk-r155286 7360 ms * Intel Xeon 5160 (x86_64 arch and gcc machine is x86_64-linux-gnu), with -O1 flag GCC-4.4.1 5968 ms GCC-trunk-r155286 5963 ms -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42027
[Bug tree-optimization/42027] [4.5 Regression] Performance regression in convolution loop optimization
--- Comment #18 from nbenoit at tuxfamily dot org 2009-12-17 09:34 --- (In reply to comment #17) (In reply to comment #16) Created an attachment (id=19332) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19332action=view) [edit] Real fix Now, before I blow it again, would you be so kind to test this patch (on top of some recent trunk, doesn't have to be the newest one, you don't need to bootstrap) if it fixes the performance problem. For me it does now, I swear :-) Tested with trunk revision 155304, the regression is gone. * Intel Xeon E5320 (x86_64 arch but gcc machine is i686-pc-linux-gnu), with -O1 flag GCC-4.4.2 7364 ms GCC-trunk-r155286 7360 ms * Intel Xeon 5160 (x86_64 arch and gcc machine is x86_64-linux-gnu), with -O1 flag GCC-4.4.1 5968 ms GCC-trunk-r155286 5963 ms Oups, copy-pasted the GCC versions for the timings. The correct versions are: * Intel Xeon E5320 (x86_64 arch but gcc machine is i686-pc-linux-gnu), with -O1 flag GCC-4.4.2 7364 ms GCC-trunk-r155304-patched 7360 ms * Intel Xeon 5160 (x86_64 arch and gcc machine is x86_64-linux-gnu), with -O1 flag GCC-4.4.1 5968 ms GCC-trunk-r155304-patched 5963 ms -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42027
[Bug libstdc++/21772] exception safety testing
--- Comment #15 from bkoz at gcc dot gnu dot org 2009-12-17 09:37 --- Subject: Bug 21772 Author: bkoz Date: Thu Dec 17 09:37:16 2009 New Revision: 155306 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155306 Log: 2009-12-16 Benjamin Kosnik b...@redhat.com PR libstdc++/21772 part 2 * doc/xml/manual/test.xml: Add documentation about testing details. * testsuite/util/exception/safety.h: New. Functor objects for testing C++0x container classes. * testsuite/util/testsuite_container_traits.h: Add traits. * testsuite/23_containers/list/requirements/exception/ basic.cc: New. generation_prohibited.cc: New. propagation_consistent.cc: New. Added: trunk/libstdc++-v3/testsuite/23_containers/list/requirements/exception/ trunk/libstdc++-v3/testsuite/23_containers/list/requirements/exception/basic.cc trunk/libstdc++-v3/testsuite/23_containers/list/requirements/exception/generation_prohibited.cc trunk/libstdc++-v3/testsuite/23_containers/list/requirements/exception/propagation_consistent.cc trunk/libstdc++-v3/testsuite/util/exception/ trunk/libstdc++-v3/testsuite/util/exception/safety.h Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/doc/xml/manual/test.xml trunk/libstdc++-v3/testsuite/util/testsuite_container_traits.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21772
[Bug libstdc++/42198] [C++0x] Using std::thread without -pthread causes immediate crash
--- Comment #3 from jwakely dot gcc at gmail dot com 2009-12-17 09:43 --- Looks sensible to me, although maybe resource_unavailable_try_again is a better error: resource_unavailable_try_again the system lacked the necessary resources to create another thread, or the system-imposed limit on the number of threads in a process would be exceeded. Without -pthread the system lacks the resources to create *any* new threads :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42198
[Bug fortran/42144] [OOP] deferred TBPs do not work
--- Comment #9 from janus at gcc dot gnu dot org 2009-12-17 09:46 --- Fixed on trunk with r155305 (on fortran-dev it was working already). Closing. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42144
[Bug libstdc++/42198] [C++0x] Using std::thread without -pthread causes immediate crash
--- Comment #4 from paolo dot carlini at oracle dot com 2009-12-17 09:48 --- Yeah, the description technically fits better, but indeed, without -pthread the system cannot create thread *at all*, I'm afraid many users could be mystified by that... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42198
[Bug libstdc++/21772] exception safety testing
--- Comment #16 from paolo dot carlini at oracle dot com 2009-12-17 09:58 --- The std::array error seems indeed bogus: if I'm not wrong, it happens when swapping arrays, and there are no guarantees that the operation doesn't throw for std::array, because it's requires to just swap the ranges, thus copy construct and copy assign each array element. Another thing I noticed, about basic_string, something seems inappropriate for it in the framework, since the value_type must be a POD! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21772
[Bug target/42377] libstdc++.dll.a misses a definition of std::string::reserve
--- Comment #4 from davek at gcc dot gnu dot org 2009-12-17 10:07 --- Ok, it's not an LD bug. LD is doing the right thing, which in this case turns out to be filtering it out of the list of exports due to the version script. In the 32-bit multilib, we have this version of std::string::reserve $ x86_64-w64-mingw32-nm -C .libs/string-inst.o | grep reserve t .text$_ZNSs7reserveEj T std::string::reserve(unsigned int) which is covered by this part of the version script: # Names not in an 'extern' block are mangled names. # std::string [ ... snip ... ] _ZNSs[67][j-z]*E[PRcjmv]*; In the 64-bit multilib, however, std::string::reserve has a different signature: $ x86_64-w64-mingw32-nm -C .libs/string-inst.o | grep reserve t .text$_ZNSs7reserveEy T std::string::reserve(unsigned long long) and that trailing 'y' doesn't match the '[PRcjmv]*' character class. Now, I haven't yet tracked down why 'unsigned int' in the 32-bit multilib has changed to 'unsigned long long' in the 64-bit multilib; it's a consequence of some 32-vs-64 difference in the w64 standard types no doubt, but it's definitely doing the wrong thing here, because the signature of the std:: function args is of course part of the ABI and I think we probably can't go changing the types of std:: function arguments like this. I'll try and track down where the ULL is coming from. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42377
[Bug bootstrap/42400] New: objc build fails
most likely the changes of 155302 are the cause. ../../gcc-4-5-libwork/gcc/objc/objc-act.c: In function objc_substitute_decl: ../../gcc-4-5-libwork/gcc/objc/objc-act.c:3118:14: error: incompatible type for argument 3 of build_indirect_ref ../../gcc-4-5-libwork/gcc/c-common.h:465:13: note: expected ref_operator but argument is of type const char * ../../gcc-4-5-libwork/gcc/objc/objc-act.c: In function build_ivar_reference: ../../gcc-4-5-libwork/gcc/objc/objc-act.c:6826:14: error: incompatible type for argument 3 of build_indirect_ref ../../gcc-4-5-libwork/gcc/c-common.h:465:13: note: expected ref_operator but argument is of type const char * ../../gcc-4-5-libwork/gcc/objc/objc-act.c: In function get_super_receiver: ../../gcc-4-5-libwork/gcc/objc/objc-act.c:8844:10: error: incompatible type for argument 3 of build_indirect_ref ../../gcc-4-5-libwork/gcc/c-common.h:465:13: note: expected ref_operator but argument is of type const char * cc1: warnings being treated as errors ../../gcc-4-5-libwork/gcc/objc/objc-act.c: In function build_ivar_reference: ../../gcc-4-5-libwork/gcc/objc/objc-act.c:6827:1: error: control reaches end of non-void function make[3]: *** [objcp/objcp-act.o] Error 1 make[2]: *** [all-stage2-gcc] Error 2 make[1]: *** [stage2-bubble] Error 2 make: *** [bootstrap] Error 2 -- Summary: objc build fails Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: developer at sandoe-acoustics dot co dot uk GCC build triplet: i686-pc-linux-gnu, i686-apple-darwin GCC host triplet: i686-pc-linux-gnu, i686-apple-darwin GCC target triplet: i686-pc-linux-gnu, i686-apple-darwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42400
[Bug target/42377] libstdc++.dll.a misses a definition of std::string::reserve
--- Comment #5 from davek at gcc dot gnu dot org 2009-12-17 10:20 --- Starting to think that actually this is just how the ABI should be for w64 and the version script for libstdc++ just has a weakness. If I'm guessing right, it's because w64 is the only LLP64 target that is why this wouldn't have shown up before on other 64-bit systems. Definitely a bug. I'm mailing the libstdc list to find out if we should take the simple option of adding a 'y' into the trailing character class in the version script signature pattern, which I think might well be The Right Thing To Do. -- davek at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-12-17 10:20:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42377
[Bug target/42377] libstdc++.dll.a misses a definition of std::string::reserve
--- Comment #6 from paolo dot carlini at oracle dot com 2009-12-17 10:25 --- Under linux, it's just unsigned long, which is 64-bit anyway, because actually it's a size_t. Seems strange that we didn't notice yet, but it's well possible that on some 64-bit systems a size_t is an unsigned long long instead of an unsigned long. If it's only that, I don't see anything wrong with just adding the y class to this pattern, I don't see how it could create problems on other systems (if they weren't exporting the symbol by mistake at the ABI baseline .so version they were totally broken anyway, because basic_string cannot work without). In that case, therefore, the corresponding libstdc++ patch is pre-approved. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42377
[Bug debug/42380] CFI statements vs. -pg
--- Comment #4 from ramana at gcc dot gnu dot org 2009-12-17 10:49 --- Confirmed - -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-12-17 10:49:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42380
[Bug libstdc++/42198] [C++0x] Using std::thread without -pthread causes immediate crash
--- Comment #5 from paolo at gcc dot gnu dot org 2009-12-17 11:09 --- Subject: Bug 42198 Author: paolo Date: Thu Dec 17 11:09:05 2009 New Revision: 155308 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155308 Log: 2009-12-17 Paolo Carlini paolo.carl...@oracle.com PR libstdc++/42198 * src/thread.cc (thread::_M_start_thread): Throw system_error immediately if the thread system is inactive. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/src/thread.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42198
[Bug libstdc++/42198] [C++0x] Using std::thread without -pthread causes immediate crash
--- Comment #6 from paolo dot carlini at oracle dot com 2009-12-17 11:11 --- Done. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42198
[Bug libstdc++/40088] Creating a std::ostringstream object locks a global mutex
-- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle |dot org |dot com Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40088
[Bug bootstrap/42400] objc build fails
-- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pzhao at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-12-17 11:15:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42400
[Bug bootstrap/42400] objc build fails
--- Comment #1 from rainer at emrich-ebersheim dot de 2009-12-17 11:21 --- (In reply to comment #0) most likely the changes of 155302 are the cause. ../../gcc-4-5-libwork/gcc/objc/objc-act.c: In function objc_substitute_decl: ../../gcc-4-5-libwork/gcc/objc/objc-act.c:3118:14: error: incompatible type for argument 3 of build_indirect_ref ../../gcc-4-5-libwork/gcc/c-common.h:465:13: note: expected ref_operator but argument is of type const char * ../../gcc-4-5-libwork/gcc/objc/objc-act.c: In function build_ivar_reference: ../../gcc-4-5-libwork/gcc/objc/objc-act.c:6826:14: error: incompatible type for argument 3 of build_indirect_ref ../../gcc-4-5-libwork/gcc/c-common.h:465:13: note: expected ref_operator but argument is of type const char * ../../gcc-4-5-libwork/gcc/objc/objc-act.c: In function get_super_receiver: ../../gcc-4-5-libwork/gcc/objc/objc-act.c:8844:10: error: incompatible type for argument 3 of build_indirect_ref ../../gcc-4-5-libwork/gcc/c-common.h:465:13: note: expected ref_operator but argument is of type const char * cc1: warnings being treated as errors ../../gcc-4-5-libwork/gcc/objc/objc-act.c: In function build_ivar_reference: ../../gcc-4-5-libwork/gcc/objc/objc-act.c:6827:1: error: control reaches end of non-void function make[3]: *** [objcp/objcp-act.o] Error 1 make[2]: *** [all-stage2-gcc] Error 2 make[1]: *** [stage2-bubble] Error 2 make: *** [bootstrap] Error 2 Confirmed for x86_64-unknown-linux-gnu. It's caused by r155302 see http://gcc.gnu.org/ml/gcc-cvs/2009-12/msg00446.html and PR40885. -- rainer at emrich-ebersheim dot de changed: What|Removed |Added CC||rainer at emrich-ebersheim ||dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42400
[Bug c/40885] build_indirect_ref i18n problems
--- Comment #4 from rainer at emrich-ebersheim dot de 2009-12-17 11:22 --- (In reply to comment #3) Fixed for 4.5.0. This breaks bootstrap at stage 2 in objc/objc-act.c see PR42400, http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42400 -- rainer at emrich-ebersheim dot de changed: What|Removed |Added CC||rainer at emrich-ebersheim ||dot de, pzhao at gcc dot gnu ||dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40885
[Bug fortran/42397] FAIL: gfortran.dg/lto/20091028-2 f_lto_20091028-2_0.o-f_lto_20091028-2_1.o link, internal compiler error
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-12-17 11:23 --- I can reproduce it on i?86-linux with an extra assert. Index: gcc/expr.c === --- gcc/expr.c (revision 155297) +++ gcc/expr.c (working copy) @@ -1194,6 +1194,7 @@ emit_block_move_hints (rtx x, rtx y, rtx } align = MIN (MEM_ALIGN (x), MEM_ALIGN (y)); + gcc_assert (align = BITS_PER_UNIT); gcc_assert (MEM_P (x)); gcc_assert (MEM_P (y)); the testcase is sort-of invalid as it stores to a CONST_DECL via a memcpy. But it's only undefined at runtime so we shouldn't ICE here. CONST_DECLs are given 1 as alignment appearantly which is sort-of bogus - they should get the alignment of the mode or at least BITS_PER_UNIT and get_object_alignment doesn't honor that. I have a patch. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-12-17 11:23:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42397
[Bug target/42377] libstdc++.dll.a misses a definition of std::string::reserve
--- Comment #7 from davek at gcc dot gnu dot org 2009-12-17 11:27 --- Created an attachment (id=19336) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19336action=view) differences between 32-bit and 64-bit exported symbols There's a bunch more missing than just std::string::reserve(), all for probably the same reason: 'j' - 'y' in the signature. Here's the raw diffs; I'll have to figure out which other signatures in the version script to also change. -- davek at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |davek at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42377
[Bug fortran/42122] -fdump-tree-original shows wrong static decl for functions with procptr argument
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-12-17 11:29 --- Hm? The TREE_STATIC is ok, the bug is that the actual arguments are different and maybe that inside the __MAIN BLOCK vars there shouldn't be a function decl. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42122
[Bug bootstrap/42400] objc build fails
--- Comment #2 from developer at sandoe-acoustics dot co dot uk 2009-12-17 11:30 --- Created an attachment (id=19337) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19337action=view) apply the new ref_operator to objc-act.c this is a mechanical change to the file, bootstrapped and checked on i686-apple-darwin9 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42400
[Bug tree-optimization/42398] [4.5 Regression] internal compiler error: in sra_modify_expr, at tree-sra.c:2175
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-12-17 11:44 ---
Confirmed.
int ptrace_setregs(void)
{
union { unsigned int l; int t; } __gu_tmp;
__asm__ __volatile__( : =r (__gu_tmp.l));
return __gu_tmp.t;
}
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||jamborm at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Component|middle-end |tree-optimization
Ever Confirmed|0 |1
GCC build triplet|x86_64-linux|
GCC host triplet|x86_64-linux|
GCC target triplet|mips-oe-linux |
Keywords||ice-on-valid-code
Last reconfirmed|-00-00 00:00:00 |2009-12-17 11:44:48
date||
Summary|internal compiler error: in |[4.5 Regression] internal
|sra_modify_expr, at tree- |compiler error: in
|sra.c:2175 |sra_modify_expr, at tree-
||sra.c:2175
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42398
[Bug target/42372] [4.5 Regression] Regrename reuses non-dead register
--- Comment #9 from rearnsha at gcc dot gnu dot org 2009-12-17 11:46 --- Agreed, this is really a target bug. -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Component|middle-end |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42372
[Bug target/42372] [4.5 Regression] Regrename reuses non-dead register
--- Comment #10 from rearnsha at gcc dot gnu dot org 2009-12-17 11:50 --- Subject: Bug 42372 Author: rearnsha Date: Thu Dec 17 11:50:06 2009 New Revision: 155310 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155310 Log: PR target/42372 * arm.md (pic_add_dot_plus_eight): Change output constraint from update to write. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42372
[Bug target/42372] [4.5 Regression] Regrename reuses non-dead register
--- Comment #11 from rearnsha at gcc dot gnu dot org 2009-12-17 11:51 --- Fixed -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42372
[Bug target/42377] libstdc++.dll.a misses a definition of std::string::reserve
--- Comment #8 from davek at gcc dot gnu dot org 2009-12-17 11:52 --- Created an attachment (id=19338) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19338action=view) salient diffs extracted I removed all the matching +/- line pairs from the raw diff file where a signature changed but the function still got exported anyway, leaving this list. The remaining + lines are symbols that the 32-bit DLL exports but the 64-bit DLL doesn't. The '-' lines, interestingly, are symbols exported by the 64-bit DLL but not the 32-bit one. I'm not sure how that comes about yet or what its significance might be. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42377
[Bug middle-end/42397] FAIL: gfortran.dg/lto/20091028-2 f_lto_20091028-2_0.o-f_lto_20091028-2_1.o link, internal compiler error
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-12-17 11:53 --- It's also a middle-end issue. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|fortran |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42397
[Bug libstdc++/40497] [C++0x] troubles with std::next / std::prev declarations
--- Comment #23 from jwakely dot gcc at gmail dot com 2009-12-17 11:55
---
I can't see any 100% reliable way to prevent this problem, because the
catch-all specialisation of iterator_traits can be instantiated with
non-iterator types.
We could try tricks like this to restrict std::next to things that look like
iterators:
// deduction fails if _Iter doesn't meet InputIterator requirements
templatetypename _Iter,
typename _Sfinae1 = decltype(*std::declval_Iter()),
typename _Sfinae2 = decltype(++std::declval_Iter()),
typename _Sfinae3 = decltype(std::declval_Iter()++),
typename _Sfinae4 = decltype(*std::declval_Iter()++),
typename _Sfinae5 = decltype(std::declval_Iter()==std::declval_Iter())
typename iterator_traits_Iter::difference_type
__safe_iterator_diff_type(_Iter);
templatetypename _InputIterator
inline _InputIterator
next(_InputIterator __x, decltype(__safe_iterator_diff_type(__x)) __n = 1)
{
std::advance(__x, __n);
return __x;
}
But that will still fail for types that have an iterator-like interface. Then
again, I think such types would be detected as iterators even with concepts.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40497
[Bug bootstrap/42400] objc build fails
--- Comment #3 from paolo dot carlini at oracle dot com 2009-12-17 12:00 --- Fixed with: http://gcc.gnu.org/ml/gcc-cvs/2009-12/msg00455.html -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42400
[Bug libstdc++/40497] [C++0x] troubles with std::next / std::prev declarations
--- Comment #24 from jwakely dot gcc at gmail dot com 2009-12-17 12:01 --- Although that breaks if any of the iterator-like operators exists but is not accessible - I think concepts would have worked in that case, but I'm not sure -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40497
[Bug libstdc++/40497] [C++0x] troubles with std::next / std::prev declarations
--- Comment #25 from paolo dot carlini at oracle dot com 2009-12-17 12:07 --- Interesting trick, really, the power of extended SFINAE ;) I think we should keep that in mind, for the DO THE RIGHT THING clause of the containers too, for example (some time ago Howard told me that in his Metrowerks implementation, it is *much* better than the minimum requirements of the standard, it almost always actually does the right thing ;) but he did that a lot of time ago, it's probably just a jungle of enable_ifs + something). So... What do you think, shall we have an __is_iterator trait and use it where it's useful? For post-4.5.0, in any case... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40497
[Bug libstdc++/40856] numeric_limits not specialized for __int128_t or __uint128_t
--- Comment #2 from paolo dot carlini at oracle dot com 2009-12-17 12:09 --- Yeah, the usual accessibility issue: in Santa Cruz I discussed that briefly with Doug, he pretended to convince people that with extended SFINAE you can implement trivially *any* introspection trait, then somebody (me too) pointed out the accessibility issue and he said bah, I don't care, accessibility is broken n C++ anyway ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40856
[Bug libstdc++/40856] numeric_limits not specialized for __int128_t or __uint128_t
--- Comment #3 from paolo dot carlini at oracle dot com 2009-12-17 12:10 --- Sorry, the last comment is for 40497. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40856
[Bug libstdc++/40497] [C++0x] troubles with std::next / std::prev declarations
--- Comment #26 from paolo dot carlini at oracle dot com 2009-12-17 12:11 --- Yeah, the usual accessibility issue: in Santa Cruz I discussed that briefly with Doug, he pretended to convince people that with extended SFINAE you can implement trivially *any* introspection trait, then somebody (me too) pointed out the accessibility issue and he said bah, I don't care, accessibility is broken n C++ anyway ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40497
[Bug libstdc++/40497] [C++0x] troubles with std::next / std::prev declarations
--- Comment #27 from jwakely dot gcc at gmail dot com 2009-12-17 12:23 --- ha! std::next would want is_input_iterator and std::prev would ideally want is_bidi_iterator, so maybe more than one trait -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40497
[Bug libstdc++/40497] [C++0x] troubles with std::next / std::prev declarations
--- Comment #28 from paolo dot carlini at oracle dot com 2009-12-17 12:25 --- Actually, details, std::next now wants _ForwardIterator, don't ask me to lookup the DR ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40497
[Bug bootstrap/42400] objc build fails
--- Comment #4 from linuxl4 at sohu dot com 2009-12-17 12:32 --- confirmed! Today my gcc 4.5 bootstrap also failed :( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42400
[Bug target/32280] _mm_srli_si128, heinous code for some shifts
--- Comment #7 from uros at gcc dot gnu dot org 2009-12-17 12:33 --- Subject: Bug 32280 Author: uros Date: Thu Dec 17 12:33:09 2009 New Revision: 155312 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155312 Log: PR target/32280 * config/i386/i386-modes.def (V1TI): New vector mode. * config/i386/i386.h (VALID_SSE_REG_MODE): Add V1TImode. (SSE_REG_MODE_P): Ditto. * config/i386/sse.md (SSEMODE16): New mode iterator. (AVXMODE16): Ditto. (avxvecmode): Handle V1TI mode. (*avx_movmode_internal): Use AVXMODE16 instead of AVXMODE. (movmode): Use SSEMODE16 instead of SSEMODE. (*movmode_internal): Ditto. (pushmode1): Ditto. (movmisalignmode): Ditto. (sse2_ashlv1ti): Rename from sse2_ashlti. (sse2_lshrv1ti): Rename from sse2_lshrti. (*avx_ashlv1ti): Rename from *avx_ashlti and move from i386.md. (*avx_lshrv1ti): Rename from *avx_lshrti and move from i386.md. (vec_shl_mode): Convert operands to V1TImode and use V1TI shift. (vec_shr_mode): Ditto. (*sse2_mulv4si3): Update for renamed sse2_ashlv1ti3. (udot_prodv4si): Ditto. * config/i386/i386.c (classify_argument): Handle V1TImode. (function_arg_advance_32): Ditto. (function_arg_32): Ditto. (ix86_expand_sse4_unpack): Convert operands to V1TImode and update for renamed gen_sse2_lshrv1ti3. (ix86_expand_args_builtin) V2DI_FTYPE_V2DI_INT_CONVERT: Set rmode to V1TImode. (struct builtin_description) __builtin_ia32_pslldqi128: Update for renamed sse2_ashlv1ti3. __builtin_ia32_psrldqi128: Update for renamed sse2_lshrv1ti3. Revert: 2007-06-11 Uros Bizjak ubiz...@gmail.com PR target/32280 * config/i386/sse.md (sse2_ashlti, sse2_lshrti3): Move ... * config/i386/i386.md (sse2_ashlti, sse2_lshrti3): ... to here. testsuite/ChangeLog: PR target/32280 * gcc.target/i386/pr32280-1.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr32280-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386-modes.def trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/i386.h trunk/gcc/config/i386/i386.md trunk/gcc/config/i386/sse.md trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32280
[Bug lto/42401] New: wrong-code with -flto
cat main.cc
struct Foo { static void f(); };
int main() { Foo::f(); }
cat Foo.cc
#include string
#include map
struct Foo { static void f(); };
void Foo::f()
{
typedef std::mapint, std::string Map;
static Map m;
Map::const_iterator it = m.find(0);
if (it != m.end()) {
std::string s = it-second;
}
}
g++ -flto -O3 -c Foo.cc
g++ -flto -O3 -c main.cc
g++ -flto -O3 main.o Foo.o
./a.out
Segmentation fault (core dumped)
This program works as expected when compiled without -flto. Though when using
-flto it crashes. I'm using SVN revision tr...@155309 on linux x86_64.
I didn't have time yet to reduce this testcase further (expand an reduce the
#includes). I'll try to do that next week.
If you change -O3 into -O0 in the compilation commands but not in the link
command, this test triggers a ICE. But I'll file a different bug for this.
--
Summary: wrong-code with -flto
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wouter dot vermaelen at scarlet dot be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42401
[Bug lto/42402] New: ICE in propagate, at ipa-reference.c:1244
cat main.cc
struct Foo { static void f(); };
int main() { Foo::f(); }
cat Foo.cc
#include string
#include map
struct Foo { static void f(); };
void Foo::f()
{
typedef std::mapint, std::string Map;
static Map m;
Map::const_iterator it = m.find(0);
if (it != m.end()) {
std::string s = it-second;
}
}
g++ -flto -O0 -c Foo.cc
g++ -flto -O0 -c main.cc
g++ -flto -O3 main.o Foo.o
...
lto1: internal compiler error: in propagate, at ipa-reference.c:1244
...
(This is the same test case as in bug 42401). I'm using SVN revision
tr...@155309 on linux x86_64.
--
Summary: ICE in propagate, at ipa-reference.c:1244
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wouter dot vermaelen at scarlet dot be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42402
[Bug lto/42402] ICE in propagate, at ipa-reference.c:1244
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-12-17 12:55 --- Combining -O0 on either compile or link side with -On on the other side has interesting effects. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42402
[Bug debug/42403] New: Incorrect CFI: doesn't readjust CFA after pop
$ install/bin/arm-none-linux-gnueabi-gcc --version
arm-none-linux-gnueabi-gcc (GCC) 4.5.0 20091214 (experimental)
[...]
GCC fails to re-adjust the CFA after pop:
$ cat d.c
void foo(void)
{
register int r7 asm(r7);
asm volatile ( : : r (r7) : memory);
}
$ install/bin/arm-none-linux-gnueabi-gcc -g -O -c -o d.o d.c
$ install/bin/arm-none-linux-gnueabi-objdump -dr d.o
d.o: file format elf32-littlearm
Disassembly of section .text:
foo:
0: e52d7004push{r7}; (str r7, [sp, #-4]!)
4: e8bd0080pop {r7}
8: e12fff1ebx lr
$ install/bin/arm-none-linux-gnueabi-readelf -wf d.o
Contents of the .debug_frame section:
000c CIE
Version: 1
Augmentation:
Code alignment factor: 1
Data alignment factor: -4
Return address column: 14
DW_CFA_def_cfa: r13 ofs 0
0010 0014 FDE cie= pc=..000c
DW_CFA_advance_loc: 4 to 0004
DW_CFA_def_cfa_offset: 4
DW_CFA_offset: r7 at cfa-4
DW_CFA_nop
DW_CFA_nop
DW_CFA_nop
For correctness, GCC should emit .cfi_adjust_cfa_offset 0 and
.cfi_restore r7 at pos. 8.
--
Summary: Incorrect CFI: doesn't readjust CFA after pop
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tschwinge at gcc dot gnu dot org
GCC target triplet: arm-none-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42403
[Bug debug/42404] New: Incorrect CFI generated
$ install/bin/arm-none-linux-gnueabi-gcc --version
arm-none-linux-gnueabi-gcc (GCC) 4.5.0 20091214 (experimental)
[...]
This GCC contains the following patch for gcc/config/arm/arm.c:
@@ -1877,7 +1877,8 @@ arm_override_options (void)
debug info. However this also creates the .eh_frame
section, so disable them until GAS can handle
this properly. See PR40521. */
- if (TARGET_AAPCS_BASED)
+ if (TARGET_AAPCS_BASED
+ !getenv(GCC_ALLOW_CFI))
flag_dwarf2_cfi_asm = 0;
GCC created incorrect CFI:
$ cat d.c
void foo(void)
{
register int r7 asm(r7);
asm volatile ( : : r (r7) : memory);
}
$ GCC_ALLOW_CFI= install/bin/arm-none-linux-gnueabi-gcc -g -O -c -o d.o d.c
$ install/bin/arm-none-linux-gnueabi-objdump -dr d.o
d.o: file format elf32-littlearm
Disassembly of section .text:
foo:
0: e52d7004push{r7}; (str r7, [sp, #-4]!)
4: e8bd0080pop {r7}
8: e12fff1ebx lr
$ install/bin/arm-none-linux-gnueabi-readelf -wf d.o
Contents of the .debug_frame section:
000c CIE
Version: 1
Augmentation:
Code alignment factor: 2
Data alignment factor: -4
Return address column: 14
DW_CFA_def_cfa: r13 ofs 0
0010 0014 FDE cie= pc=..000c
DW_CFA_advance_loc: 4 to 0004
DW_CFA_def_cfa_offset: 4
DW_CFA_advance_loc: 8 to 000c
DW_CFA_offset: r7 at cfa-4
DW_CFA_nop
DW_CFA_nop
The .cfi_offset r7, -4 belongs at pos. 4, not 0xc.
Also, for correctness, GCC should emit .cfi_adjust_cfa_offset -4 and
.cfi_restore r7 at pos. 8, see PR42403.
--
Summary: Incorrect CFI generated
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tschwinge at gcc dot gnu dot org
GCC target triplet: arm-none-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42404
[Bug debug/42403] Incorrect CFI: doesn't readjust CFA after pop
--- Comment #1 from tschwinge at gcc dot gnu dot org 2009-12-17 14:12 --- Last paragraph: .cfi_adjust_cfa_offset *-4*, of course. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42403
[Bug tree-optimization/42376] [4.5 Regression] Performance regression of generated code
--- Comment #5 from martin at mpa-garching dot mpg dot de 2009-12-17 14:12 --- GCC with -std=c99 makes sure to properly handle the i387 FPU excess precision. With -fexcess-precision=fast the code is as fast (and non-conforming) like with GCC 4.4. Using -std=gnu99 is also an option. Thanks a lot for pointing this out! I was aware of the floating-point change but simply had not realized it would be switched on by -std=c99. I imagine that this might catch many people by surprise once 4.5.0 is released, and it might be politically advisable to mention it (and the fix) in a place where users can't miss it. Is there a plan to mention this (in a prominent place) in the release notes? Or in the FAQ or the non-bugs section of bugs.html? I can prepare a documentation patch if this is desirable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42376
[Bug lto/42401] wrong-code with -flto
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-12-17 14:26 --- It is DOM which threads over the check in bb 12: bb 11: __y_90 = __y_108; D.2866_92 = __y_108-_M_value_field.first; if (D.2866_92 0) goto bb 20; else goto bb 12; bb 12: # SR.42_94 = PHI SR.42_88(11) if (SR.42_94 != m._M_t._M_impl._M_header) goto bb 13; else goto bb 19; bb 13: # SR.42_78 = PHI SR.42_94(12), SR.42_87(20) D.2308_34 = (const struct _Rb_tree_node *) SR.42_78; D.2315_10 = D.2308_34-_M_value_field.second; __comp_ctor (s, D.2315_10); changing bb 11 to bb 11: __y_90 = __y_108; D.2837_92 = __y_108-_M_value_field.first; if (D.2837_92 0) goto bb 19; else goto bb 13; which looks correct but one wonders why it's only done with -fipa-cp-clone. This change is what in the end triggers the bug, so -fno-tree-dominator-opts fixes it as well. The DOM thing is a missed-optimization in the -flto case. In the LTO case we thread bb 10: # __y_108 = PHI __y_95(9), __y_75(5) SR.42_88 = (struct _Rb_tree_node_base *) __y_108; if (SR.42_88 == m._M_t._M_impl._M_header) goto bb 12; else goto bb 11; bb 11: __y_90 = __y_108; D.2837_92 = __y_90-_M_value_field.first; if (D.2837_92 0) goto bb 12; else goto bb 13; bb 12: bb 13: # SR.42_94 = PHI SR.42_88(11), m._M_t._M_impl._M_header(12) if (SR.42_94 != m._M_t._M_impl._M_header) goto bb 14; else goto bb 20; bb 14: D.2308_34 = (const struct _Rb_tree_node *) SR.42_94; D.2315_10 = D.2308_34-_M_value_field.second; __comp_ctor (s, D.2315_10); ... bb 20: return; } to bb 10: # __y_108 = PHI __y_95(9), __y_75(5) SR.42_88 = (struct _Rb_tree_node_base *) __y_108; if (SR.42_88 == m._M_t._M_impl._M_header) goto bb 20; else goto bb 11; bb 11: __y_90 = __y_108; D.2866_92 = __y_108-_M_value_field.first; if (D.2866_92 0) goto bb 20; else goto bb 12; bb 12: # SR.42_94 = PHI SR.42_88(11) if (SR.42_94 != m._M_t._M_impl._M_header) goto bb 13; else goto bb 19; bb 13: # SR.42_78 = PHI SR.42_94(12), SR.42_87(20) D.2308_34 = (const struct _Rb_tree_node *) SR.42_78; D.2315_10 = D.2308_34-_M_value_field.second; __comp_ctor (s, D.2315_10); which is 1) incomplete as noted above and 2) wrong, as the target BB 20 no longer is BB 20 but BB 19 ... ... bb 19: return; bb 20: # SR.42_87 = PHI m._M_t._M_impl._M_header(11), m._M_t._M_impl._M_header(10) goto bb 13; } thus somehow jump threading is messed up. Good threading: Jump threading proved probability of edge 13-20 too small (it is 3237, should be 1). Threaded jump 11 -- 13 to 13 Threaded jump 12 -- 13 to 22 Removing basic block 12 Merging blocks 13 and 14 Removing basic block 21 Bad threading: Threaded jump 12 -- 13 to 22 Removing basic block 12 Removing basic block 21 I can't see how this is not a latent problem with jump-threading independent of LTO. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn|39604 | Keywords||missed-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42401
[Bug java/42405] New: libgcj_bc.so.1 dependency causes gcj to fail
I'm trying to get java to run on the ARM processor based SheevaPlug. I am compiling on the SheevaPlug, itself. At /mnt/seagate2/work/gjc/trunk, I pulled from Subversion: plug trunk # svn info Path: . URL: svn://gcc.gnu.org/svn/gcc/trunk Repository Root: svn://gcc.gnu.org/svn/gcc Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4 Revision: 155206 Node Kind: directory Schedule: normal Last Changed Author: bje Last Changed Rev: 155206 Last Changed Date: 2009-12-13 21:06:50 -0800 (Sun, 13 Dec 2009) plug trunk # I had to run the .../contrib/download_ecj script to install the ecj.jar into the trunk directory, I then ran the configuration again so the ecj.jar would be staged into my target for make ... install. Now, when I try to compile, it looks like a libgcj_bc.so.1 is required and not included or found: plug bin # ./gcj -v -I /usr/local/gcj/usr/local/share/java/libgcj-4.5.0.jar /var /work/gcj/HelloWorld.java ... Using built-in specs. Reading specs from /usr/local/gcj/usr/local/bin/../lib/gcc/armv5tel-unknown-linu x-gnueabi/4.5.0/../../../libgcj.spec rename spec startfile to startfileorig rename spec lib to liborig COLLECT_GCC=./gcj COLLECT_LTO_WRAPPER=/usr/local/gcj/usr/local/bin/../libexec/gcc/armv5tel-unknown -linux-gnueabi/4.5.0/lto-wrapper Target: armv5tel-unknown-linux-gnueabi Configured with: ../trunk/configure --enable-languages=java : (reconfigured) ../ trunk/configure --enable-languages=java Thread model: posix gcc version 4.5.0 20091214 (experimental) (GCC) COLLECT_GCC_OPTIONS='-fsaw-java-file' '-v' '-fbootclasspath=/usr/local/gcj/usr/l ocal/share/java/libgcj-4.5.0.jar:./:/usr/local/share/java/libgcj-4.5.0.jar' '-g1 ' '-shared-libgcc' /usr/local/gcj/usr/local/bin/../libexec/gcc/armv5tel-unknown-linux-gnueabi/4.5. 0/ecj1 /var/work/gcj/HelloWorld.java -g1 -fbootclasspath=/usr/local/gcj/usr/loca l/share/java/libgcj-4.5.0.jar:./:/usr/local/share/java/libgcj-4.5.0.jar -g1 -fso urce=1.5 -ftarget=1.5 -fzip-dependency /tmp/ccApA393.zip -fzip-target /tmp/cciqI t8X.jar /usr/local/gcj/usr/local/bin/../libexec/gcc/armv5tel-unknown-linux-gnueabi/4.5.0 /ecj1: error while loading shared libraries: libgcj_bc.so.1: cannot open shared object file: No such file or directory plug bin # From reading bugs returned on search for libgcj_bc.so.1 it looks like there is a dependency comes from the ecj.jar What can I do to move forward and compile java with my freshly built gcj? I'm basically blocked, but am unfamiliar with your bug categorization, so I've marked this bug as normal -- Summary: libgcj_bc.so.1 dependency causes gcj to fail Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jlpoole at pon dot net GCC build triplet: armv5tel-unknown -linux-gnueabi GCC host triplet: armv5tel-unknown -linux-gnueabi GCC target triplet: armv5tel-unknown -linux-gnueabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42405
[Bug middle-end/42397] FAIL: gfortran.dg/lto/20091028-2 f_lto_20091028-2_0.o-f_lto_20091028-2_1.o link, internal compiler error
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-12-17 14:36 --- Subject: Bug 42397 Author: rguenth Date: Thu Dec 17 14:36:43 2009 New Revision: 155316 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155316 Log: 2009-12-17 Richard Guenther rguent...@suse.de PR middle-end/42397 * builtins.c (get_object_alignment): Properly deal with a CONST_DECL base. * expr.c (emit_block_move_hints): Assert the alignment makes sense. Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/expr.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42397
[Bug middle-end/42397] FAIL: gfortran.dg/lto/20091028-2 f_lto_20091028-2_0.o-f_lto_20091028-2_1.o link, internal compiler error
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-12-17 14:39 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42397
[Bug c/42406] New: gcc issues warning with tolower function with optimization flag
gcc issues warning when using the tolower function along with an optimization
flag. This warning also happens in other versions of gcc apart from 4.4.2
gcc -std=c99 -pedantic -O2 -Wall -Wunreachable-code a.c
a.c:13: warning: will never be executed
#include stdio.h
#include string.h
#include ctype.h
int main(void)
{
char A[50] = ;
strcat(A, Hello World!);
int COUNT = 0;
while(A[COUNT])
{
A[COUNT] = (char)(tolower(A[COUNT])); // this line issues warning
COUNT++;
}
puts(A); // output: hello world!
return 0;
}
--
Summary: gcc issues warning with tolower function with
optimization flag
Product: gcc
Version: 4.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joe dot bassis at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42406
[Bug lto/42401] wrong-code with -flto
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-12-17 15:17 ---
Btw, the single-file testcase
#include string
#include map
int main ()
{
typedef std::mapint, std::string Map;
static Map m;
Map::const_iterator it = m.find(0);
if (it != m.end()) {
std::string s = it-second;
}
}
fails the same way (with -flto).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42401
[Bug target/42377] libstdc++.dll.a misses a definition of std::string::reserve
--- Comment #9 from davek at gcc dot gnu dot org 2009-12-17 15:25 --- Subject: Bug 42377 Author: davek Date: Thu Dec 17 15:25:36 2009 New Revision: 155318 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155318 Log: PR target/42377 * config/abi/pre/gnu.ver: Adjust mangled function signatures to permit LLP64 sizetypes throughout. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/config/abi/pre/gnu.ver -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42377
[Bug target/42377] libstdc++.dll.a misses a definition of std::string::reserve
--- Comment #10 from davek at gcc dot gnu dot org 2009-12-17 15:27 --- Should be fixed in SVN now. Rainer, please verify when you get a chance. -- davek at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42377
[Bug c/42406] gcc issues warning with tolower function with optimization flag
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-12-17 16:20 --- -Wunreachable-code is broken and has been removed in 4.5. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42406
[Bug java/42405] libgcj_bc.so.1 dependency causes gcj to fail
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-12-17 16:22 --- Make sure your install library path is in LD_LIBRARY_PATH. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Version|unknown |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42405
[Bug tree-optimization/42376] [4.5 Regression] Performance regression of generated code
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-12-17 16:22 --- Documentation improvement is always welcome, especially if you looked for it but missed the critical piece. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42376
[Bug debug/42404] Incorrect CFI generated
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-12-17 16:25 --- I'm not sure if arm has been updated for CFI in the prologue/epilogue. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42404
[Bug debug/42396] [4.5 Regression] ICE: in dwarf2out_frame_debug_adjust_cfa, at dwarf2out.c:1859
--- Comment #2 from hjl dot tools at gmail dot com 2009-12-17 16:38 --- It is caused by revision 147995: http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00974.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||rth at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-12-17 16:38:20 date|| Summary|ICE: in |[4.5 Regression] ICE: in |dwarf2out_frame_debug_adjust|dwarf2out_frame_debug_adjust |_cfa, at dwarf2out.c:1859 |_cfa, at dwarf2out.c:1859 Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42396
[Bug preprocessor/42407] New: Detect non-unique header file names.
A potential source of error for C programmers is the inadvertent covering of one header file by another with the same name. This issue is documented by CERT in the CERT C Secure Coding Standard as PRE08-C. Guarantee that header file names are unique [https://www.securecoding.cert.org/confluence/display/seccode/PRE08-C.+Guarantee+that+header+file+names+are+unique].; The risk assessment for this issue is documented as: Failing to guarantee uniqueness of header files may result in the inclusion of an older version of a header file, which may include incorrect macro definitions or obsolete function prototypes or result in other errors that may or may not be detected by the compiler. Portability issues may also stem from the use of header names that are not guaranteed to be unique[https://www.securecoding.cert.org/confluence/display/seccode/PRE08-C.+Guarantee+that+header+file+names+are+unique].; To address this issue it would be a useful feature of the preprocessor to generate a warning when an include directive specifies a header file name which is non-unique within the active header search path. This feature should be an option for the user since implementations for detection of uniqueness would likely incur a performance penalty. It would also be useful to allow the user to specify exceptions for the cases where covering one header with another is intentional. The addition of such a feature to the gcc preprocessor will help programmers mediate the risk of CERT PRE08-C. -- Summary: Detect non-unique header file names. Product: gcc Version: 4.4.2 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: don at drexel dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42407
[Bug other/41255] [4.5 Regression] Release notes: Advice to use GDB later than 6.8
--- Comment #3 from bkoz at gcc dot gnu dot org 2009-12-17 17:04 --- We really need something for gcc-4.5/porting_to.html -- bkoz at gcc dot gnu dot org changed: What|Removed |Added CC||bkoz at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41255
[Bug java/42405] libgcj_bc.so.1 dependency causes gcj to fail
--- Comment #2 from jlpoole at pon dot net 2009-12-17 17:18 --- Thank you. This worked: export LD_LIBRARY_PATH=/usr/local/gcj/usr/local/lib then plug bin # ./gcj -v -I /usr/local/gcj/usr/local/share/java/libgcj-4.5.0.jar /var /work/gcj/HelloWorld.java -- jlpoole at pon dot net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Version|4.5.0 |unknown http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42405
[Bug tree-optimization/42398] [4.5 Regression] internal compiler error: in sra_modify_expr, at tree-sra.c:2175
--- Comment #3 from hjl dot tools at gmail dot com 2009-12-17 17:27 --- This is caused by new SRA: http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00959.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42398
[Bug libstdc++/42408] New: Missing templatized seed()
There is no templatized user-provided seed() and related constructors in the C++0x random number generation library. The draft N3000 says that the engines (Mersenne Twister, among others) have templateSeedSequence Sseq explicit mersenne_twister_engine(Sseq q); templateSeedSequence Sseq void seed(Sseq q); in order to use a user-supplied seed generator. GCC classes accept only std::seed_seq, which in some situations doesn't provide high-enough entropy. -- Summary: Missing templatized seed() Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: piotr dot wyderski at gmail dot com GCC host triplet: Cygwin/GCC4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42408
[Bug java/42409] New: org.eclipse.jdt.internal.compiler.batch.GCCMain not found
(This Bug follows 4205 which is not marked FIXED)
On armv5tel-unknown-linux-gnueabi I compiled gcj plus .../contrib/download_ecj.
Last Changed Rev: 155206
Last Changed Date: 2009-12-13 21:06:50 -0800 (Sun, 13 Dec 2009)
installed with DESTDIR=/usr/local/gcj
set LD_LIBRARY_PATH=/usr/local/gcj/usr/local/lib
plug bin # ./gcj -v -I /usr/local/gcj/usr/local/share/java/libgcj-4.5.0.jar
/var
/work/gcj/HelloWorld.java
produces:
...
Target: armv5tel-unknown-linux-gnueabi
Configured with: ../trunk/configure --enable-languages=java : (reconfigured)
../
trunk/configure --enable-languages=java
Thread model: posix
gcc version 4.5.0 20091214 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-fsaw-java-file' '-v'
'-fbootclasspath=/usr/local/gcj/usr/l
ocal/share/java/libgcj-4.5.0.jar:./:/usr/local/share/java/libgcj-4.5.0.jar'
'-g1
' '-shared-libgcc'
/usr/local/gcj/usr/local/bin/../libexec/gcc/armv5tel-unknown-linux-gnueabi/4.5.
0/ecj1 /var/work/gcj/HelloWorld.java -g1
-fbootclasspath=/usr/local/gcj/usr/loca
l/share/java/libgcj-4.5.0.jar:./:/usr/local/share/java/libgcj-4.5.0.jar -g1
-fso
urce=1.5 -ftarget=1.5 -fzip-dependency /tmp/ccEAvqtm.zip -fzip-target
/tmp/ccgLw
7My.jar
Exception in thread main java.lang.NoClassDefFoundError:
org.eclipse.jdt.inter
nal.compiler.batch.GCCMain
at gnu.java.lang.MainThread.run(MainThread.java:100)
Caused by: java.lang.ClassNotFoundException:
org.eclipse.jdt.internal.compiler.b
atch.GCCMain not found in gnu.gcj.runtime.SystemClassLoader{urls=[],
parent=gnu.
gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
at java.net.URLClassLoader.findClass(URLClassLoader.java:531)
at java.lang.ClassLoader.loadClass(ClassLoader.java:452)
at java.lang.ClassLoader.loadClass(ClassLoader.java:387)
at gnu.java.lang.MainThread.run(MainThread.java:96)
plug bin #
Here's the test code:
plug bin # cat /var/work/gcj/HelloWorld.java
class HelloWorld {
public static void main(String args[]){
System.out.println(Hello World!);
}
}
plug bin #
I really feel badly having to come to you with my struggling; however, I have a
good deal of experience with Perl and some Java and find myself gated by what
members of this team think trivial. Please keep in mind when someone comes to
try installing the gcc compiler and getting it to run, they do not have the
experience and day-to-day exposure you have, so something simple as an
incorrect path can be confounding.
I'm not sure which class is missing (or not pointed to with the class path)
from the above output.
--
Summary: org.eclipse.jdt.internal.compiler.batch.GCCMain not
found
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jlpoole at pon dot net
GCC build triplet: armv5tel-unknown-linux-gnueabi
GCC host triplet: armv5tel-unknown-linux-gnueabi
GCC target triplet: armv5tel-unknown-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42409
[Bug libstdc++/42408] Missing templatized seed()
--- Comment #1 from paolo dot carlini at oracle dot com 2009-12-17 17:55 --- Yes, this is known, no need to keep this issue open for ongoing C++0x work: the issue basically is that random has not been un-conceptualized yet in the WP, now that Concepts are gone, and we are for now keeping the sub-optimal, but consistent interfaces used *before* the conceptualized version has been added. We really have to wait. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42408
[Bug testsuite/40459] g++.dg/abi/mangle*.C fail on darwin
--- Comment #10 from espindola at gcc dot gnu dot org 2009-12-17 18:09 --- I tried to build gcc on darwin to debug this but the build fails with a link failure (sorry, don't remember exactly where). Do I need to do something special to build on darwin? The error message is emitted when mangling the names and the instantiated from bits use input_location. Yes, that is bad :-( I assume that the difference is coming from use computing the assembler name at a different point in time when building on darwin. The short term fix might be to force the assembler name computation to happen at a fixed point in time for both darwin and non-darwin systems. The correct fix would be to not use input_location. -- espindola at gcc dot gnu dot org changed: What|Removed |Added CC||dnovillo at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-12-17 18:09:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40459
[Bug testsuite/40459] g++.dg/abi/mangle*.C fail on darwin
--- Comment #11 from dominiq at lps dot ens dot fr 2009-12-17 19:16 --- I tried to build gcc on darwin to debug this but the build fails with a link failure (sorry, don't remember exactly where). Do I need to do something special to build on darwin? On which version of darwin did you try the build? Where were the gmp/mpfr/mpc libraries? Do you remember the configure command? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40459
[Bug tree-optimization/42386] [4.5 Regression] ICE in ipcp_iterate_stage, at ipa-cp.c:766
--- Comment #11 from jakub at gcc dot gnu dot org 2009-12-17 19:29 --- Subject: Bug 42386 Author: jakub Date: Thu Dec 17 19:29:48 2009 New Revision: 155321 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155321 Log: PR c++/42386 * ipa.c (function_and_variable_visibility): Clear same_comdat_group links of DECL_EXTERNAL nodes. * g++.dg/opt/dtor3.C: New test. Added: trunk/gcc/testsuite/g++.dg/opt/dtor3.C Modified: trunk/gcc/ChangeLog trunk/gcc/ipa.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42386
[Bug debug/41679] [4.5 Regression] internal compiler error: in loc_cmp, at var-tracking.c:2433
--- Comment #8 from jakub at gcc dot gnu dot org 2009-12-17 19:31 --- Subject: Bug 41679 Author: jakub Date: Thu Dec 17 19:30:58 2009 New Revision: 155322 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155322 Log: PR debug/41679 * var-tracking.c (add_stores): Avoid value mode mismatch for promoted declarations. * gcc.target/arm/pr41679.c: New. Added: trunk/gcc/testsuite/gcc.target/arm/pr41679.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/var-tracking.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41679
[Bug debug/41679] [4.5 Regression] internal compiler error: in loc_cmp, at var-tracking.c:2433
--- Comment #9 from jakub at gcc dot gnu dot org 2009-12-17 19:32 --- Subject: Bug 41679 Author: jakub Date: Thu Dec 17 19:31:52 2009 New Revision: 155323 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155323 Log: PR debug/41679 * var-tracking.c (use_type): Remove indirection from loc. (count_uses): Dereference incoming loc early. (add_uses): Dereference incoming loc early. Modified: trunk/gcc/ChangeLog trunk/gcc/var-tracking.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41679
[Bug debug/41679] [4.5 Regression] internal compiler error: in loc_cmp, at var-tracking.c:2433
--- Comment #10 from jakub at gcc dot gnu dot org 2009-12-17 19:32 --- Subject: Bug 41679 Author: jakub Date: Thu Dec 17 19:32:32 2009 New Revision: 155324 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155324 Log: PR debug/41679 * var-tracking.c (count_uses): Count MO_VAL_USE of original MO_VAL_SET value for COND_EXEC. (add_stores): Handle conditional stores. Modified: trunk/gcc/ChangeLog trunk/gcc/var-tracking.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41679
[Bug ada/42410] New: Illegal Ada 83 program accepted, universal_integer literal where Character expected
pragma ada_83; with text_io; procedure test1 is type T1 is record str: string(1..10); end record; x1: T1 := (str = (others = 49)); --ERROR: 49 is not a character begin text_io.put_line(x1.str); end test1; $ gnatmake test1; ./test1 gcc-4.3 -c test1.adb gnatbind -x test1.ali gnatlink test1.ali 11 $ gnatmake test1 gcc-4.4 -c test1.adb test1.adb:9:33: expected type Standard.Character test1.adb:9:33: found type universal integer gnatmake: test1.adb compilation error -- Summary: Illegal Ada 83 program accepted, universal_integer literal where Character expected Product: gcc Version: 4.3.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ludovic at ludovic-brenta dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42410
[Bug ada/42410] Illegal Ada 83 program accepted, universal_integer literal where Character expected
--- Comment #1 from ludovic at ludovic-brenta dot org 2009-12-17 19:42 --- Fixed in 4.4; this PR only to document the the issue for users of previous versions. -- ludovic at ludovic-brenta dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to fail||4.3.4 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42410
[Bug ada/42411] New: Illegal program accepted, RM 4.1(8), 8.6(27)/2
package pak1 is type T1 is new integer; type T1_access is access all T1; x1: aliased T1; x2: T1 := x1'access.all;--ERROR: 4.1(8) (missed) x3: T1_access := T1_access(x1'access); --ERROR: 4.6(6) (detected) end pak1; Gnat misses the error involving x1'access.all. RM 3.10.2(2)/2 says the expected type (for 'access) shall be a single access type. But .all doesn't provide a single access type. Instead, by RM 4.1(8), the name in a dereference is expected to be of any access type. The rule for type_conversions (x3) is similar. RM 4.6(6) says The operand of a type_conversion is expected to be of any type. Gnat does detect this error. $ gnatmake pak1 gcc-4.3 -c pak1.ads pak1.ads:6:21: argument of conversion cannot be access pak1.ads:6:21: use qualified expression instead gnatmake: pak1.ads compilation error -- Summary: Illegal program accepted, RM 4.1(8), 8.6(27)/2 Product: gcc Version: 4.3.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ludovic at ludovic-brenta dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42411
[Bug ada/42411] Illegal program accepted, RM 4.1(8), 8.6(27)/2
--- Comment #1 from ludovic at ludovic-brenta dot org 2009-12-17 19:47 --- RM 8.6(27)/2 is also relevant: When a construct is one that requires that its expected type be a single type in a given class, the type of the construct shall be determinable solely from the context in which the construct appears, excluding the construct itself, but using the requirement that it be in the given class. Furthermore, the context shall not be one that expects any type in some class that contains types of the given class; in particular, the construct shall not be the operand of a type_conversion. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42411
[Bug c++/41596] handling of library-related options by g++spec.c causes a failure when generating pch.
--- Comment #2 from developer at sandoe-acoustics dot co dot uk 2009-12-17 19:51 --- Created an attachment (id=19339) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19339action=view) updated patch to allow specification of -static-libstdc++ on the CL while generating PCH -- developer at sandoe-acoustics dot co dot uk changed: What|Removed |Added Attachment #18715|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41596
[Bug ada/42412] New: Illegal program accepted, RM 8.5.1(3), renames of classwide object
package pak1 is type T1 is tagged null record; x1: T1; x2: T1'class := x1; x3: T1'class renames x1; --ERROR: (detected) T1'class vs T1 x4: T1 renames x2;--ERROR: (missed)T1 vs T1'class end pak1; $ gnatmake pak1 gcc-4.3 -c pak1.ads pak1.ads:5:25: expected type T1'class defined at line 2 pak1.ads:5:25: found type T1 defined at line 2 gnatmake: pak1.ads compilation error RM 8.5.1(3) says The type of the object_name shall resolve to the type determined by the subtype_mark. T and T'class are considered to be different types, and shouldn't match. There is flexibility in RM 8.6(23) for T'class to sometimes match T, but only when the rules provide an expected type. But this flexibility doesn't apply when the rules say shall resolve to, as in this case, without giving an expected type. This subtle wording distinction can also be seen in other places in the RM, such as 12.4(4) vs. 12.4(5). -- Summary: Illegal program accepted, RM 8.5.1(3), renames of classwide object Product: gcc Version: 4.3.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ludovic at ludovic-brenta dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42412
[Bug ada/42412] Illegal program accepted, RM 8.5.1(3), renames of classwide object
--- Comment #1 from ludovic at ludovic-brenta dot org 2009-12-17 19:52 --- $ gnatmake pak1 gcc-4.4 -c pak1.ads pak1.ads:5:25: expected type T1'class defined at line 2 pak1.ads:5:25: found type T1 defined at line 2 pak1.ads:6:19: dynamically tagged expression not allowed gnatmake: pak1.ads compilation error So the bug is fixed in 4.4. -- ludovic at ludovic-brenta dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to fail||4.3.4 Known to work||4.4.2 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42412
[Bug c++/41596] handling of library-related options by g++spec.c causes a failure when generating pch.
--- Comment #3 from developer at sandoe-acoustics dot co dot uk 2009-12-17 19:54 --- the patch has been modified following the discussions in: http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00862.html http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00855.html to re-write -static-libstdc++ onto the command line even if the target supports -BStatic/dynamic. This allows such targets the option of spec substution. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41596
[Bug c++/41596] handling of library-related options by g++spec.c causes a failure when generating pch.
--- Comment #4 from davek at gcc dot gnu dot org 2009-12-17 19:58 ---
(In reply to comment #2)
Created an attachment (id=19339)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19339action=view) [edit]
updated patch to allow specification of -static-libstdc++ on the CL while
generating PCH
The maintainers will probably point out you've got a few bits of stray
formatting there (relative to the gcc coding standard); for example here:
- {
- library = library = 0 ? 2 : library;
- args[i] |= SKIPOPT;
- }
+ {
+ library |= library = 0 ? 2 : library;
+ args[i] |= SKIPOPT;
+ }
you've replaced a leading TAB by eight spaces, where the coding standard wants
all groups of 8 spaces at the start of a line to be real hard TABs. That may
be something you'll have to fix elsewhere too, I guess your editor probably
gave you spaces for indentation throughout. The only other nit I noticed was:
- if (library == 0)
+ if ( library = 0 (library 1) == 0)
an excess space before library there that you might as well tidy up while
you're at it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41596
[Bug ada/42413] New: Legal tasking program hangs at run time, function returning task that is then passed to a subprogram
with Text_IO; procedure test1 is task type T1 is entry E1; end T1; task body T1 is begin Text_IO.Put_Line (T1 started); accept E1; Text_IO.Put_Line (T1 done); end T1; function f1 return T1 is begin return R : T1; end f1; procedure p2 (x1: T1) is begin Text_IO.Put_Line (begin p2); x1.E1; end p2; begin declare x1: T1 := f1; begin p2(x1);-- this works end; declare x1: T1 renames f1; begin p2(x1);-- this works end; p2(f1); -- this hangs end test1; output: begin p2 T1 started T1 done begin p2 T1 started T1 done begin p2 hangs -- Summary: Legal tasking program hangs at run time, function returning task that is then passed to a subprogram Product: gcc Version: 4.3.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ludovic at ludovic-brenta dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42413
[Bug libfortran/33905] show_backtrace hangs on SIGSEGV in malloc/free
--- Comment #4 from pault at gcc dot gnu dot org 2009-12-17 20:17 --- I think that FX was right, since Toon has not responded in 6 months. Entering a WONTFIX Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33905
[Bug testsuite/42414] New: arbitrary path modification by a sed statement breaks testsuite if testsuite is in the absolute path
gcc/Makefile.in contains the line sed '/set tmpdir/ s|testsuite|$(TESTSUITEDIR)/$*|' \ ../../site.exp tmp-site.exp; \ which caused a large number of test failures because I had the testsuite in a path that included the word testsuite which was erroneously expanded. Because of this the testsuite referenced a lot of invalid paths causing a ton of failures. -- Summary: arbitrary path modification by a sed statement breaks testsuite if testsuite is in the absolute path Product: gcc Version: 4.2.4 Status: UNCONFIRMED Severity: minor Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jonathan at kc8onw dot net GCC build triplet: host-i686-pc-linux-gnu GCC host triplet: host-i686-pc-linux-gnu GCC target triplet: host-i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42414
[Bug c++/42415] New: Bad assembly generated for constructor call
test.cc:
class A {
void f();
}
void A::f() {
A::A();
}
g++ -c test.cc
/tmp/cciN3Byt.s: Assembler messages:
/tmp/cciN3Byt.s:18: Warning: missing operand; zero assumed
/tmp/cciN3Byt.s:18: Error: undefined symbol `_ZN1AC1Ev' in operation
/tmp/cciN3Byt.s:18: Error: undefined symbol `INTERNAL' in operation
I have no idea if this is valid, but these error messages are very confusing.
This is GCC 4.5, 20091210 snapshot, plus the patch for PR42251.
g++ -v:
Using built-in specs.
COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.5.0-alpha20091210/g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.5.0-alpha20091210/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-4.5.0_alpha20091210/work/gcc-4.5-20091210/configure
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.5.0-alpha20091210
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.0-alpha20091210/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.5.0-alpha20091210
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.5.0-alpha20091210/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.5.0-alpha20091210/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.0-alpha20091210/include/g++-v4
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec
--disable-fixed-point --without-ppl --without-cloog --enable-nls
--without-included-gettext --with-system-zlib --disable-checking
--disable-werror --enable-secureplt --enable-multilib --enable-libmudflap
--disable-libssp --enable-libgomp
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.5.0-alpha20091210/python
--enable-java-awt=gtk --enable-languages=c,c++,java --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo
4.5.0_alpha20091210' --enable-checking
Thread model: posix
gcc version 4.5.0-alpha20091210 20091210 (experimental) (Gentoo
4.5.0_alpha20091210)
--
Summary: Bad assembly generated for constructor call
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: truedfx at gentoo dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42415
[Bug c++/42415] Bad assembly generated for constructor call
--- Comment #1 from truedfx at gentoo dot org 2009-12-17 20:51 --- And here's the generated assembly: .file test.cc .text .align 2 .globl _ZN1A1fEv .type _ZN1A1fEv, @function _ZN1A1fEv: .LFB0: .cfi_startproc pushq %rbp .cfi_def_cfa_offset 16 movq%rsp, %rbp .cfi_offset 6, -16 .cfi_def_cfa_register 6 subq$16, %rsp movq%rdi, -8(%rbp) movq-8(%rbp), %rax movq%rax, %rdi call_ZN1AC1Ev *INTERNAL* leave .cfi_def_cfa 7, 8 ret .cfi_endproc .LFE0: .size _ZN1A1fEv, .-_ZN1A1fEv .ident GCC: (Gentoo 4.5.0_alpha20091210) 4.5.0-alpha20091210 20091210 (experimental) .section.note.GNU-stack,,@progbits -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42415
[Bug fortran/35913] INTRINISIC vs. host-associated procedures (check conformance)
--- Comment #1 from pault at gcc dot gnu dot org 2009-12-17 20:51 --- I believe that gfortran behaves correctly in all the testcases in this thread. I have written to Bob Corbet to see if he agrees. The nub of the matter is that a local declaration always has precedence over a host associated one. My inclination is to close the PR unless Bob disagrees. Cheers Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35913
[Bug fortran/36161] gfc_error formats are not marked gcc-internal-format in po file
--- Comment #10 from pault at gcc dot gnu dot org 2009-12-17 20:54 --- (In reply to comment #9) With the upcoming release of 4.5, I think it would be nice to fix/improve the translation related bugs now, i.e. this, PR38573 and PR40489. As I have no idea how to reproduce/check/whatever this kind of PR, could somebody be so kind to add a step-by-step description of the commands that need to be invoked to do so? Thanks. Daniel, Would you be so kind as to follow this. It's been unconfirmed for 18 months. Is it a bug or not and will we or won't we fix it? I vote for a WONTFIX to be honest. Cheers Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36161
[Bug tree-optimization/42386] [4.5 Regression] ICE in ipcp_iterate_stage, at ipa-cp.c:766
--- Comment #12 from jakub at gcc dot gnu dot org 2009-12-17 20:56 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42386
[Bug debug/41679] [4.5 Regression] internal compiler error: in loc_cmp, at var-tracking.c:2433
--- Comment #11 from jakub at gcc dot gnu dot org 2009-12-17 20:57 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41679
[Bug fortran/36497] USE association, cray pointers and error checking
--- Comment #2 from pault at gcc dot gnu dot org 2009-12-17 21:02 --- Hmmm! :-) Since Cray pointers are non-standard, one might argue for undetermined behaviour. However, logically, both pointer and pointee are symbols in the modules and so should be use associated. Therefore, I vote for a confirm. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-12-17 21:02:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36497
[Bug fortran/39654] ABI bug: FTELL intrinsic function not capable of large files
--- Comment #5 from pault at gcc dot gnu dot org 2009-12-17 21:04 --- (In reply to comment #4) (In reply to comment #3) Gentlemen, What is the word on this? A WONTFIX? Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39654
[Bug fortran/39695] [F03] ProcPtr function results: wrong name in error message
-- pault at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-12-17 21:05:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39695
