[Bug c++/29365] New: Unnecessary anonymous namespace warnings
How to reproduce: g++ -c foo.C Compiling the attached code using g++-4.2 generates the warning foo.C:11: warning: 'foo::bar' has a base 'unnamed::gazonk' whose type uses the anonymous namespace I fail to see why this construct should be warned about -- Summary: Unnecessary anonymous namespace warnings Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gcc at magfr dot user dot lysator dot liu dot se GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29365
[Bug c++/29365] Unnecessary anonymous namespace warnings
--- Comment #1 from gcc at magfr dot user dot lysator dot liu dot se 2006-10-06 06:09 --- Created an attachment (id=12389) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12389action=view) foo.C - testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29365
[Bug fortran/19261] continuation character illegal as first non-blank character in statement
--- Comment #7 from patchapp at dberlin dot org 2006-10-06 07:02 --- Subject: Bug number PR19261 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00281.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19261
[Bug c/29091] [4.0/4.1/4.2 Regression] vector constant not fully outputed
--- Comment #4 from jakub at gcc dot gnu dot org 2006-10-06 07:16 --- Subject: Bug 29091 Author: jakub Date: Fri Oct 6 07:15:48 2006 New Revision: 117481 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117481 Log: PR c/29091 * varasm.c (output_constant): If TREE_VECTOR_CST_ELTS chain is shorter than the number of vector elements fill the rest with zeros. * gcc.dg/pr29091.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr29091.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/varasm.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29091
[Bug fortran/28415] 4.2.0 ICE when using automatic array and -fno-automatic
--- Comment #6 from jakub at gcc dot gnu dot org 2006-10-06 07:23 --- Subject: Bug 28415 Author: jakub Date: Fri Oct 6 07:23:00 2006 New Revision: 117482 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117482 Log: PR fortran/28415 * trans-decl.c (gfc_finish_var_decl): With -fno-automatic, don't make artificial variables or pointer to variable automatic array TREE_STATIC. * gfortran.dg/save_2.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/save_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28415
[Bug target/29198] [4.0/4.1/4.2 Regression] Incorrect reference to __thread array with -fPIC -O2 on x86
--- Comment #5 from jakub at gcc dot gnu dot org 2006-10-06 07:25 --- Subject: Bug 29198 Author: jakub Date: Fri Oct 6 07:25:02 2006 New Revision: 117483 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117483 Log: PR target/29198 * config/i386/i386.c (legitimize_pic_address): Reject TLS symbols. * config/i386/predicates.md (local_symbolic_operand): Likewise. * gcc.dg/tls/opt-12.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tls/opt-12.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/predicates.md trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29198
[Bug tree-optimization/29290] [4.1 Regression] SPEC CPU2000 178.galgel ICE using -O3 -ftree-loop-linear
--- Comment #3 from jakub at gcc dot gnu dot org 2006-10-06 07:27 --- Subject: Bug 29290 Author: jakub Date: Fri Oct 6 07:27:28 2006 New Revision: 117484 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117484 Log: PR tree-optimization/29290 * tree-loop-linear.c (linear_transform_loops): Bail if loop_nest has multiple exits. * gfortran.dg/loop_nest_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/loop_nest_1.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-loop-linear.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29290
[Bug fortran/28415] 4.2.0 ICE when using automatic array and -fno-automatic
--- Comment #7 from jakub at gcc dot gnu dot org 2006-10-06 07:33 --- Subject: Bug 28415 Author: jakub Date: Fri Oct 6 07:33:34 2006 New Revision: 117485 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117485 Log: PR fortran/28415 * trans-decl.c (gfc_finish_var_decl): With -fno-automatic, don't make artificial variables or pointer to variable automatic array TREE_STATIC. * gfortran.dg/save_2.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/save_2.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/trans-decl.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28415
[Bug target/29198] [4.0/4.1/4.2 Regression] Incorrect reference to __thread array with -fPIC -O2 on x86
--- Comment #6 from jakub at gcc dot gnu dot org 2006-10-06 07:35 --- Subject: Bug 29198 Author: jakub Date: Fri Oct 6 07:35:45 2006 New Revision: 117486 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117486 Log: PR target/29198 * config/i386/i386.c (legitimize_pic_address): Reject TLS symbols. * config/i386/predicates.md (local_symbolic_operand): Likewise. * gcc.dg/tls/opt-12.c: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/tls/opt-12.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/config/i386/i386.c branches/gcc-4_1-branch/gcc/config/i386/predicates.md branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29198
[Bug tree-optimization/29290] [4.1 Regression] SPEC CPU2000 178.galgel ICE using -O3 -ftree-loop-linear
--- Comment #4 from jakub at gcc dot gnu dot org 2006-10-06 07:37 --- Subject: Bug 29290 Author: jakub Date: Fri Oct 6 07:37:04 2006 New Revision: 117487 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117487 Log: PR tree-optimization/29290 * tree-loop-linear.c (linear_transform_loops): Bail if loop_nest has multiple exits. * gfortran.dg/loop_nest_1.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/loop_nest_1.f90 Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/tree-loop-linear.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29290
[Bug fortran/28415] 4.2.0 ICE when using automatic array and -fno-automatic
--- Comment #8 from jakub at gcc dot gnu dot org 2006-10-06 07:39 --- Fixed in SVN. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28415
[Bug target/29198] [4.0 Regression] Incorrect reference to __thread array with -fPIC -O2 on x86
--- Comment #7 from jakub at gcc dot gnu dot org 2006-10-06 07:41 --- Fixed on the trunk and on 4.1 branch. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.0.0 4.1.0 4.2.0 |4.0.0 4.1.0 4.1.1 Known to work|3.4.0 |3.4.0 4.1.2 4.2.0 Summary|[4.0/4.1/4.2 Regression]|[4.0 Regression] Incorrect |Incorrect reference to |reference to __thread array |__thread array with -fPIC - |with -fPIC -O2 on x86 |O2 on x86 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29198
[Bug tree-optimization/29290] [4.1 Regression] SPEC CPU2000 178.galgel ICE using -O3 -ftree-loop-linear
--- Comment #5 from jakub at gcc dot gnu dot org 2006-10-06 07:42 --- Fixed on 4.1 branch and on the trunk. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail|4.1.2 | Known to work|4.1.1 4.2.0 |4.1.1 4.2.0 4.1.2 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29290
[Bug c/29091] [4.0/4.1 Regression] vector constant not fully outputed
--- Comment #5 from jakub at gcc dot gnu dot org 2006-10-06 07:42 --- Fixed on the trunk so far. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.0/4.1/4.2 Regression]|[4.0/4.1 Regression] vector |vector constant not fully |constant not fully outputed |outputed| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29091
[Bug target/28924] x86 sync builtins fail for char and short memory operands
--- Comment #4 from uros at kss-loka dot si 2006-10-06 08:27 --- Please note, that in addition to http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00250.html, http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00244.html is also needed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28924
[Bug libstdc++/29118] [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites
--- Comment #15 from bkoz at gcc dot gnu dot org 2006-10-06 09:48 ---
// try this simpler code.
#include stdexcept
#include ext/concurrence.h
namespace
{
__gnu_cxx::__mutex test_mutex;
unsigned int i;
} // anonymous namespace
void* add(void*)
{
__gnu_cxx::__scoped_lock sentry(test_mutex);
{
++i; // break here
}
return 0;
}
void
check_thread_create(int ret)
{
if (ret != 0)
{
char buf[10];
sprintf(buf, %u, ret);
std::string error(pthread_create failed: );
error += buf;
error += strerror(ret);
throw std::runtime_error(error);
}
}
int main()
{
pthread_t id1;
pthread_t id2;
check_thread_create(pthread_create(id1, NULL, add, 0));
check_thread_create(pthread_create(id2, NULL, add, 0));
pthread_join(id1, NULL);
pthread_join(id2, NULL);
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29118
[Bug libstdc++/29118] [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites
--- Comment #16 from bkoz at gcc dot gnu dot org 2006-10-06 09:52 ---
When you get to break here this is what your mutex should look like in gdb:
Breakpoint 2, add () at lock_test.cc:14
(gdb) p test_mutex
$4 = {_M_mutex = {__data = {__lock = 1, __count = 0, __owner = 14845,
__kind = 0, __nusers = 1, {__spins = 0, __list = {__next = 0x0}}},
__size =
\001\000\000\000\000\000\000\000ý9\000\000\000\000\000\000\001\000\000\000\000\000\000,
__align = 1}}
Or, something like this (I see this on x86/linux.)
Actually, if you edit my example a bit and
void* add(void*)
{
{
__gnu_cxx::__scoped_lock sentry(test_mutex);
++i; // break here
}
return 0; // break here
}
On the return statement, you'll see:
(gdb) p test_mutex
$4 = {_M_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __kind = 0,
__nusers = 0, {__spins = 0, __list = {__next = 0x0}}},
__size = '\0' repeats 23 times, __align = 0}}
If this is not happening, then there is something wrong with mutex usage.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29118
[Bug libstdc++/29118] [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites
--- Comment #17 from bkoz at gcc dot gnu dot org 2006-10-06 09:55 --- I don't think this is an ordering problem... there are no complicated ordering issues in this code. Something to try might be making test_mutex static, and not in an anonymous namespace. I'm not quite sure why hppa is acting so strangely. Can you try a version of hppa-linux that is using NPTL? best, benjamin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29118
[Bug libstdc++/29354] Error when seeking on an ostringstream
--- Comment #2 from paolo at gcc dot gnu dot org 2006-10-06 09:57 --- Subject: Bug 29354 Author: paolo Date: Fri Oct 6 09:57:43 2006 New Revision: 117494 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117494 Log: 2006-10-06 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/29354 * include/bits/sstream.tcc (basic_stringbuf::seekpos(pos_type, ios_base::openmode)): Allow for seek to pos_type(off_type(0)) when the stream is empty. * testsuite/27_io/basic_stringbuf/seekpos/char/29354.cc: New. * testsuite/27_io/basic_stringbuf/seekpos/wchar_t/29354.cc: New. Added: trunk/libstdc++-v3/testsuite/27_io/basic_stringbuf/seekpos/char/29354.cc trunk/libstdc++-v3/testsuite/27_io/basic_stringbuf/seekpos/wchar_t/29354.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/sstream.tcc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29354
[Bug libstdc++/29354] Error when seeking on an ostringstream
--- Comment #3 from paolo at gcc dot gnu dot org 2006-10-06 09:58 --- Subject: Bug 29354 Author: paolo Date: Fri Oct 6 09:58:03 2006 New Revision: 117495 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117495 Log: 2006-10-06 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/29354 * include/bits/sstream.tcc (basic_stringbuf::seekpos(pos_type, ios_base::openmode)): Allow for seek to pos_type(off_type(0)) when the stream is empty. * testsuite/27_io/basic_stringbuf/seekpos/char/29354.cc: New. * testsuite/27_io/basic_stringbuf/seekpos/wchar_t/29354.cc: New. Added: branches/gcc-4_1-branch/libstdc++-v3/testsuite/27_io/basic_stringbuf/seekpos/char/29354.cc branches/gcc-4_1-branch/libstdc++-v3/testsuite/27_io/basic_stringbuf/seekpos/wchar_t/29354.cc Modified: branches/gcc-4_1-branch/libstdc++-v3/ChangeLog branches/gcc-4_1-branch/libstdc++-v3/include/bits/sstream.tcc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29354
[Bug libstdc++/29354] Error when seeking on an ostringstream
--- Comment #4 from pcarlini at suse dot de 2006-10-06 09:59 --- Fixed for 4.1.2 and 4.2.0. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29354
[Bug libstdc++/29095] [4.0/4.1/4.2 Regression] cxxabi.h __cxa_cdtor_type not declared when included from C
-- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29095
[Bug libstdc++/29366] New: atomics config for sh is wierd
The atomics configury for sh in libstdc++ is quite poor, and duplicates the generic atomicity files if __SH4A__ is undefined. This is the only cpu directory to do this, and leads to issues when the genric atomicity code is updated: twice now the sh config has been left behind. This is no good. Let's try to fix it. See: config/cpu/sh/atomicity.h Some of this is probably related to the multiplicity of sh ISAs and the lack of a specific SH atomic-instructions-presence macro coordinated with a target_cpu value. For this, I blame sh or the gcc support of sh. However, it's not sh's fault that there isn't a better way to do this in libstdc++ and the file has to be duplicated. Sometimes I think that we should redo atomics config yet again to do the following: 1) compile-time check for atomic builtins, use if found 2) if not found, try one of the asm hacks, and *RUN* something with the found config to see if it actually works 3) if none of the above work, use the *SINGLE* generic code with mutexes And, all of these have to work for multilibs, and whatever weird thread config that is passed down. However, I'm a bit timid about doing this, since we really need compiler support for 2 so that we can determine what the arch is for real when doing multilibs. That, and I've thrashed the atomics config enough for one year while ending up very close to the same place I started. -- Summary: atomics config for sh is wierd Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bkoz at gcc dot gnu dot org GCC host triplet: sh*-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29366
[Bug libstdc++/29367] New: pb_ds hash containers vs. _GLIBCXX_DEBUG
for 4.2 versions of the policy-based associated containers, the individual debug macros were stripped out and the usual libstc++-designating-debug-mode macro was used. This is: _GLIBCXX_DEBUG. While doing this, I found a long-standing issue with the pb_ds hash-based containers and the debug mode: parts are missing. This isn't the case for tree and priority_que data structures, which work perfectly. This is apparently an issue for every version of pb_ds and pb_assoc that I've seen. Can be seen here: /mnt/share/src/gcc/libstdc++-v3/testsuite/ext/pb_ds/example/basic_map.cc:98: instantiated from here /mnt/share/bld/gcc/i686-pc-linux-gnu/libstdc++-v3/include/ext/pb_ds/detail/cc_hash_table_map_/debug_fn_imps.hpp:70: error: 'm_store_hash_indicator' is not a member of 'pb_ds::detail::types_traitsstd::basic_stringchar, std::char_traitschar, std::allocatorchar , pb_ds::list_updatelong unsigned int, float, std::equal_tolong unsigned int, pb_ds::move_to_front_lu_policystd::allocatorchar , std::allocatorchar , std::allocatorchar, false' I'm not quite sure where this is supposed to come from. -- Summary: pb_ds hash containers vs. _GLIBCXX_DEBUG Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bkoz at gcc dot gnu dot org GCC build triplet: all GCC host triplet: all GCC target triplet: all http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29367
[Bug debug/7055] [alpha osf4] G++ 3.1 Produced bad debugging entries if compiled with -gcoff, also segv.
--- Comment #7 from markus dot schoepflin at comsoft dot de 2006-10-06 10:23 --- Created an attachment (id=12390) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12390action=view) Patch for mips-tfile.c against 4.1.1 source tree. This turned out to be a bug in mips-tfile.c, triggered by identifiers starting with a number. There is code which tries to allow that, but the logic is flawed. This patch corrects the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7055
[Bug libstdc++/28457] ext/pb_ds/regression/tree_data_map_rand.cc fails with a particular random seed.
--- Comment #6 from bkoz at gcc dot gnu dot org 2006-10-06 10:41 --- try again. the thing about (now) throw_allocator is that if some of the testcases have allocated memory and then an exception is thrown, the leaked memory is actually testsuite-type temporaries that should have been deleted. So, this could be a false herring. Anyway. I think the the only remaining pb_ds regressions that show up regularly are the priority_queue dijkstra tests on powerpc. -benjamin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28457
[Bug libstdc++/29095] [4.0/4.1/4.2 Regression] cxxabi.h __cxa_cdtor_type not declared when included from C
--- Comment #6 from pcarlini at suse dot de 2006-10-06 11:14 --- I'm reassigning to Benjamin... -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|pcarlini at suse dot de |bkoz at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29095
[Bug libstdc++/29368] New: wrong STL docs for rfind()
This is really a minor issue: There is an error in doxygen comments for rfind() family functions, in file include/bits/basic_string.h. @param pos is wrongly documented. It reads: * @param pos Index of character to start search at (default 0). while it should be: * @param pos Index of character to start search at (default end). -- Summary: wrong STL docs for rfind() Product: gcc Version: 4.0.3 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: milan dot mimica at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29368
[Bug c/28744] externally_visible attribute not effective with prior declaration of symbol.
-- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||jakub at gcc dot gnu dot org AssignedTo|jakub at gcc dot gnu dot org|hubicka at gcc dot gnu dot ||org Status|REOPENED|ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28744
[Bug libstdc++/29368] wrong STL docs for rfind()
--- Comment #1 from paolo at gcc dot gnu dot org 2006-10-06 11:48 --- Subject: Bug 29368 Author: paolo Date: Fri Oct 6 11:47:56 2006 New Revision: 117496 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117496 Log: 2006-10-06 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/29368 * include/bits/basic_string.h: Adjust rfind documentation. * include/ext/vstring.h: Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/basic_string.h trunk/libstdc++-v3/include/ext/vstring.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29368
[Bug libstdc++/29368] wrong STL docs for rfind()
--- Comment #2 from paolo at gcc dot gnu dot org 2006-10-06 11:48 --- Subject: Bug 29368 Author: paolo Date: Fri Oct 6 11:48:18 2006 New Revision: 117497 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117497 Log: 2006-10-06 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/29368 * include/bits/basic_string.h: Adjust rfind documentation. * include/ext/vstring.h: Likewise. Modified: branches/gcc-4_1-branch/libstdc++-v3/ChangeLog branches/gcc-4_1-branch/libstdc++-v3/include/bits/basic_string.h branches/gcc-4_1-branch/libstdc++-v3/include/ext/vstring.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29368
[Bug libstdc++/29368] wrong STL docs for rfind()
--- Comment #3 from paolo at gcc dot gnu dot org 2006-10-06 11:48 --- Subject: Bug 29368 Author: paolo Date: Fri Oct 6 11:48:34 2006 New Revision: 117498 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117498 Log: 2006-10-06 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/29368 * include/bits/basic_string.h: Adjust rfind documentation. * include/ext/vstring.h: Likewise. Modified: branches/gcc-4_0-branch/libstdc++-v3/ChangeLog branches/gcc-4_0-branch/libstdc++-v3/include/bits/basic_string.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29368
[Bug libstdc++/29368] wrong STL docs for rfind()
--- Comment #4 from pcarlini at suse dot de 2006-10-06 11:51 --- Fixed everywhere. -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29368
[Bug fortran/29364] No error given if using a non-defined type in a type definition
--- Comment #1 from pault at gcc dot gnu dot org 2006-10-06 12:32 --- Oh dear, yes. Thank you, Tobi. Paul -- 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 |2006-10-06 12:32:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29364
[Bug middle-end/28205] Request an option to make -finstrument-functions not apply to inlined function calls
--- Comment #3 from andreas dot knuepfer at tu-dresden dot de 2006-10-06 12:40 --- Would it be feasible to pass a different function address for inlined functions? In particular, it should not be the same address as the parent function. I seem to recall that in previous versions (2.95.x, 3.x) of GCC __cyg_profile_func_enter() used the call location of an inlined function as first argument. This is somewhere in the middle of the parent function, which makes sense somehow. Any invalid address could be used as well. In the end, the user could be aware of a function being inlined. -- andreas dot knuepfer at tu-dresden dot de changed: What|Removed |Added CC||andreas dot knuepfer at tu- ||dresden dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28205
[Bug tree-optimization/29330] [4.2 Regression] -O -ftree-loop-linear -- virtual memory exhausted
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-10-03 16:21:27 |2006-10-06 12:49:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29330
[Bug c++/29365] Unnecessary anonymous namespace warnings
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-06 12:59 --- As I understand it, the warning is because if you have the definition of class foo::bar, you will be violating ODR for foo. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||jason at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29365
[Bug c++/28450] [4.0/4.1 regression] ICE with new and complex/vector types
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-10-06 13:07 --- Subject: Bug 28450 Author: pinskia Date: Fri Oct 6 13:06:56 2006 New Revision: 117502 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117502 Log: 2006-10-06 Andrew Pinski [EMAIL PROTECTED] PR C++/28450 * cp/init.c (build_zero_init): Handle VECTOR_TYPE and COMPLEX_TYPEs. 2006-10-06 Andrew Pinski [EMAIL PROTECTED] PR C++/28450 * g++.dg/ext/vector4.C: New test. * g++.dg/ext/complex1.C: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/complex1.C - copied unchanged from r116341, trunk/gcc/testsuite/g++.dg/ext/complex1.C branches/gcc-4_1-branch/gcc/testsuite/g++.dg/ext/vector4.C - copied unchanged from r116341, trunk/gcc/testsuite/g++.dg/ext/vector4.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/init.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28450
[Bug c++/28450] [4.0 regression] ICE with new and complex/vector types
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-10-06 13:09 --- Fixed also on the 4.1 branch. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.0/4.1 regression] ICE|[4.0 regression] ICE with |with new and complex/vector |new and complex/vector types |types | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28450
[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
--- Comment #3 from ghazi at gcc dot gnu dot org 2006-10-06 13:25 ---
(In reply to comment #2)
(In reply to comment #0)
1. Whether a certain minimum version of GMP/MPFR is required to avoid known
bugs, etc.
See my recent patch to toplevel configure.in. THe minimum required
versions should be gmp-4.1.x and mpfr-2.2.0.
I see that, but when configure detects the broken mpfr, it just prints out a
message and proceeds happily. It doesn't disable anything. (???)
If you haven't read fortran/{arith.c,simplify.c}, then I'd suggest
that you take a look to see what gmp/mpfr can do.
I looked through those and read through the mpfr docs so I think I have a good
idea of what mpfr can do. My main area of concern right now is converting
between gcc's REAL_VALUE_TYPE and mpfr_t. I found gfc_conv_mpfr_to_tree() in
trans-const.c which uses a string as an intermediate type, is that the most
efficient way to convert? Also where is the function that does the reverse,
i.e. tree or REAL_VALUE_TYPE to mpfr_t?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335
[Bug fortran/29371] New: Coredump when using -fbounds-check with pointer nullify
The following program coredumps at nullify() when compiled with -fbounds-check, otherwise it does work as supposed. If I remove one of the nullify()s or remove the loop, it works ok. - program test implicit none type projector_t real, pointer :: ket(:, :), bra(:, :) end type projector_t type(projector_t),pointer, dimension(:) :: p integer :: stat,i allocate(p(2),stat=stat) print *, 'state = ',stat do i = 1, 2 nullify(p(i)%bra) nullify(p(i)%ket) end do end program - -- Summary: Coredump when using -fbounds-check with pointer nullify Product: gcc Version: unknown Status: UNCONFIRMED Severity: major Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29371
[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
--- Comment #4 from kargl at gcc dot gnu dot org 2006-10-06 14:40 ---
(In reply to comment #3)
(In reply to comment #2)
(In reply to comment #0)
1. Whether a certain minimum version of GMP/MPFR is required to
avoid known bugs, etc.
See my recent patch to toplevel configure.in. THe minimum required
versions should be gmp-4.1.x and mpfr-2.2.0.
I see that, but when configure detects the broken mpfr, it just prints
out a message and proceeds happily. It doesn't disable anything. (???)
It's simply a warning to a user that there are known problems with the
version of MPFR on the system. gfortran will work correctly with the
buggy mpfr with the exception of some corner cases and PRs that I've
fixed using newer features. In particular, there are problems with
the old hackish way that gfortran handled subnormal numbers. gfortran
also uses functions that are in 2.2.0 that are not available in some
of the older versions.
See simplify.c(gfc_simplify_nearest).
If you haven't read fortran/{arith.c,simplify.c}, then I'd suggest
that you take a look to see what gmp/mpfr can do.
I looked through those and read through the mpfr docs so I think I have a good
idea of what mpfr can do. My main area of concern right now is converting
between gcc's REAL_VALUE_TYPE and mpfr_t. I found gfc_conv_mpfr_to_tree() in
trans-const.c which uses a string as an intermediate type, is that the most
efficient way to convert?
I didn't write that function, and so I have experimented with a replacement.
There is mpfr_get_ld(), which converts to a long double. If the data type
never exceeds the properties of long double, then one may be able to
use mpfr_get_ld() and then fold_convert() the result to the proper type.
Also where is the function that does the reverse,
i.e. tree or REAL_VALUE_TYPE to mpfr_t?
gfortran doesn't have a need of going in the opposite direction.
gmp/mpfr are used in the frontend for the internal representation
of data types. By the time gfortran reaches the functions in
trans-*.c, it has done all the constant folding and manipulation
of the data types that it can. The trans-*.c functions simply
convert gfortran's black and red trees into the tree-ssa form.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335
[Bug rtl-optimization/29294] 4.1, 4.2 (possibly 4.0?) not finding postmodify address mode on ARM
--- Comment #5 from eplondke at gmail dot com 2006-10-06 14:55 --- Here's what's going on in this case: CSE changes an address if: A) The cost of the address is lower or B) The cost of the address is the same and the cost of the RTX would be higher outside of an address So, CSE changes (R) to (R+4) because it is lower cost as specified by the address_costs hook. It doesn't change beyond (R+4) because (R+8) is the same cost as (R+4). Once the address (R+4) gets in the RTL sequence, it never gets converted to a postincrement form. So by adding the cost of a simple REG RTX as being lower than (+ (REG) (CONST)) in the addressing modes, CSE doesn't convert the address to base+offset, and we get the postincrement code back again in 4.x. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29294
[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
--- Comment #5 from ghazi at gcc dot gnu dot org 2006-10-06 15:36 --- (In reply to comment #4) (In reply to comment #3) (In reply to comment #2) (In reply to comment #0) idea of what mpfr can do. My main area of concern right now is converting between gcc's REAL_VALUE_TYPE and mpfr_t. I found gfc_conv_mpfr_to_tree() in trans-const.c which uses a string as an intermediate type, is that the most efficient way to convert? I didn't write that function, and so I have experimented with a replacement. There is mpfr_get_ld(), which converts to a long double. If the data type never exceeds the properties of long double, then one may be able to use mpfr_get_ld() and then fold_convert() the result to the proper type. I think using long double defeats the whole purpose of using mpfr. We're supposed to avoid relying on the properties of the host's floating point for cross-compilers where the target format is different. Otherwise I could simply call out to e.g. cosl() on the host and avoid the whole mpfr thing (okay okay, assuming cosl() and the rest of c99 math functions exist... which they don't always, but my point about target long double remains.) I was hoping there was an easy was to extract the exponent and mantissa from one of (REAL_VALUE_TYPE/mpft_t) and put them back into the other in a way that preserves everything clean in both directions. Also where is the function that does the reverse, i.e. tree or REAL_VALUE_TYPE to mpfr_t? gfortran doesn't have a need of going in the opposite direction. gmp/mpfr are used in the frontend for the internal representation of data types. By the time gfortran reaches the functions in trans-*.c, it has done all the constant folding and manipulation of the data types that it can. The trans-*.c functions simply convert gfortran's black and red trees into the tree-ssa form. Okay I hacked up something in the other direction using strings again. If someone comes up with something better, then great. But it's not strictly necessary. I can put the two conversion functions into real.[ch]. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335
[Bug libstdc++/28457] ext/pb_ds/regression/tree_data_map_rand.cc fails with a particular random seed.
--- Comment #7 from pcarlini at suse dot de 2006-10-06 16:07 --- (In reply to comment #6) try again. Certainly I can confirm that the problem cannot be reproduced anymore by tweaking the random seed to 1153519516. the thing about (now) throw_allocator is that if some of the testcases have allocated memory and then an exception is thrown, the leaked memory is actually testsuite-type temporaries that should have been deleted. So, this could be a false herring. Crazy... Anyway. I think the the only remaining pb_ds regressions that show up regularly are the priority_queue dijkstra tests on powerpc. In practice there is also priority_queue_rand.cc on ia64-linux, which however, as I mentioned in Comment #1, seems a miscompilation... I have no idea what to do about it, besides waiting and hoping for the best... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28457
[Bug target/28924] x86 sync builtins fail for char and short memory operands
--- Comment #5 from jakub at gcc dot gnu dot org 2006-10-06 16:54 --- Subject: Bug 28924 Author: jakub Date: Fri Oct 6 16:54:43 2006 New Revision: 117508 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117508 Log: PR target/28924 * builtins.c (expand_builtin_sync_operation, expand_builtin_compare_and_swap, expand_builtin_lock_test_and_set): Use convert_to_mode to handle promoted arguments. * gcc.c-torture/compile/20061005-1.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/20061005-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28924
[Bug tree-optimization/29330] [4.2 Regression] -O -ftree-loop-linear -- virtual memory exhausted
--- Comment #6 from jakub at gcc dot gnu dot org 2006-10-06 16:57 --- Subject: Bug 29330 Author: jakub Date: Fri Oct 6 16:57:27 2006 New Revision: 117509 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117509 Log: PR tree-optimization/29330 * tree-data-ref.c (free_data_ref): Use DR_FREE_ACCESS_FNS macro. (initialize_data_dependence_relation): Clear DDR_LOOP_NEST pointer on newly allocated ddrs. (find_loop_nest_1, find_loop_nest): Change LOOP_NEST to a pointer to VEC (loop_p, heap) pointer. (compute_data_dependences_for_loop): Adjust caller. (free_dependence_relations): Free DDR_LOOP_NEST. * tree-loop-linear.c (linear_transform_loops): Don't forget to free DEPENDENCE_RELATIONS and DATAREFS. * gcc.dg/pr29330.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr29330.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-data-ref.c trunk/gcc/tree-loop-linear.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29330
[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
--- Comment #6 from kargl at gcc dot gnu dot org 2006-10-06 17:03 --- There is mpfr_get_ld(), which converts to a long double. If the data type never exceeds the properties of long double, then one may be able to use mpfr_get_ld() and then fold_convert() the result to the proper type. I think using long double defeats the whole purpose of using mpfr. It appears you misread what I wrote (or meant to write). If the data type never exceeds the properties of long double applies to a cross compiler as well where data type is on the target and long double is on the host. We're supposed to avoid relying on the properties of the host's floating point for cross-compilers where the target format is different. The host's long double is simply an intermediate representation of the value. It is the responsibility of the fold_convert to get the right target representation. This is no different than using strings as the intermediate. I was hoping there was an easy was to extract the exponent and mantissa from one of (REAL_VALUE_TYPE/mpft_t) and put them back into the other in a way that preserves everything clean in both directions. See trans-intrinsics.c (prepare_arg_info), although I'm get ready to submit a patch that removes that function. Also where is the function that does the reverse, i.e. tree or REAL_VALUE_TYPE to mpfr_t? gfortran doesn't have a need of going in the opposite direction. gmp/mpfr are used in the frontend for the internal representation of data types. By the time gfortran reaches the functions in trans-*.c, it has done all the constant folding and manipulation of the data types that it can. The trans-*.c functions simply convert gfortran's black and red trees into the tree-ssa form. Okay I hacked up something in the other direction using strings again. If someone comes up with something better, then great. But it's not strictly necessary. I can put the two conversion functions into real.[ch]. I would be interested in seeing the functions because gfortran currently can't constant fold a TRANSFER() of the form real, parameter :: x = transfer(1234,x) This is a bitwise copy of the integer 1234 into x. In gfortran 1235 is a gmp mpz_t type and x is an mpfr mpfr_t type. Emulating the bitwise copy will require strings manipulations. -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||kargl at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335
[Bug target/28924] x86 sync builtins fail for char and short memory operands
--- Comment #6 from jakub at gcc dot gnu dot org 2006-10-06 17:07 --- Subject: Bug 28924 Author: jakub Date: Fri Oct 6 17:06:52 2006 New Revision: 117511 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117511 Log: PR target/28924 * builtins.c (expand_builtin_sync_operation, expand_builtin_compare_and_swap, expand_builtin_lock_test_and_set): Use convert_to_mode to handle promoted arguments. * gcc.c-torture/compile/20061005-1.c: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.c-torture/compile/20061005-1.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/builtins.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28924
[Bug tree-optimization/29330] [4.2 Regression] -O -ftree-loop-linear -- virtual memory exhausted
--- Comment #7 from jakub at gcc dot gnu dot org 2006-10-06 17:17 --- Fixed in SVN. -- 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=29330
[Bug target/28924] x86 sync builtins fail for char and short memory operands
--- Comment #7 from jakub at gcc dot gnu dot org 2006-10-06 17:19 --- We still need the sync-2.c testcase, Uros, can you please commit it? Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28924
[Bug libgcj/29153] [ecj] clean up pthread assumptions
--- Comment #1 from tromey at gcc dot gnu dot org 2006-10-06 18:15 --- Andrew fixed this. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29153
[Bug c++/29365] Unnecessary anonymous namespace warnings
--- Comment #3 from jason at gcc dot gnu dot org 2006-10-06 18:36 --- Yes. If foo is used in multiple translation units, it violates the ODR because gazonk is a different type in each translation unit. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29365
[Bug c++/29365] Unnecessary anonymous namespace warnings
--- Comment #4 from gcc at magfr dot user dot lysator dot liu dot se 2006-10-06 18:48 --- I still fail to understand why this would inherently violate the ODR. I agree with Andrew that if more than one translation unit sees the defintion of foo::bar then it will violate the ODR but if only one translation unit ever sees the definition of foo::bar then I see no problem with this. Externally foo::bar is exposed only as a undefined inner class. About the only thing you could use it for would be as a pointer target. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29365
[Bug rtl-optimization/29294] 4.1, 4.2 (possibly 4.0?) not finding postmodify address mode on ARM
--- Comment #6 from eplondke at gmail dot com 2006-10-06 19:07 --- Changing the cost of (REG) to 1 fixes 4.1 but not 4.2, it seems. In 4.2, the RTL optimization does not combine ldr r2, [r1, #0] ldr r3, [r0, #0] add r0, r0, #4 add r1, r1, #4 into ldr r2, [r1], #4 ldr r3, [r0], #4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29294
[Bug target/25850] real kind=16 failures on powerpc-darwin
--- Comment #11 from geoffk at gcc dot gnu dot org 2006-10-06 19:14 --- This is entirely a dup of 25477. *** This bug has been marked as a duplicate of 25477 *** -- geoffk at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25850
[Bug target/25477] __builtin_sqrtl/__builtin_printf does not work unless including math.h/stdio.h
--- Comment #6 from geoffk at gcc dot gnu dot org 2006-10-06 19:14 --- *** Bug 25850 has been marked as a duplicate of this bug. *** -- geoffk at gcc dot gnu dot org changed: What|Removed |Added CC||dir at lanl dot gov http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25477
[Bug target/23504] 22_locale/money_get/get/char/5.cc fails on ppc-darwin7. because libstdc++ believes long double returns works
--- Comment #4 from geoffk at gcc dot gnu dot org 2006-10-06 19:16 --- Tracking this as part of the general problem under 25477. *** This bug has been marked as a duplicate of 25477 *** -- geoffk at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23504
[Bug target/25477] builtin functions should use $LDBL128 suffix on darwin when appropriate
--- Comment #7 from geoffk at gcc dot gnu dot org 2006-10-06 19:16 --- *** Bug 23504 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25477
[Bug libstdc++/29095] [4.0/4.1/4.2 Regression] cxxabi.h __cxa_cdtor_type not declared when included from C
--- Comment #7 from mmitchel at gcc dot gnu dot org 2006-10-06 19:18
---
I'm following up to the mailing list in the PR trail, since it's very confusing
to go back and forth between the two.
The technical issue is that in the following code:
extern C {
typedef void (*p1)();
}
typedef void (*p2)();
p1 and p2 are distinct types, and, in fact, you can overload based on that.
G++ doesn't implement that distinction; we don't keep track of language linkage
for types (just for functions) but we should, and, at some point, I'm sure
we'll implement that. The reason this is in the standard is so that an
implementation can use different calling conventions for C and C++. So, when
calling through a function pointer you have to know which kind of function
you're calling. (And, yes, name-mangling is supposed to encode the linkage of
the function type, when mangling a pointer-to-function type.)
So, changing the linkage of __cxa_cdtor_return_type (that name is not specified
in the ABI, by the way), technically changes the type of __cxa_vec_new.
However, the ABI specification does say that __cxa_vec_new is declared extern
C, and, since it specifically gives this prototype:
extern C void * __cxa_vec_new (
size_t element_count,
size_t element_size,
size_t padding_size,
void (*constructor) ( void *this ),
void (*destructor) ( void *this ) );
that means that the type of the constructor and destructor arguments are also
required to be pointers-to-C-functions.
In summary, I think Benjamin's proposed change (to change the constructor type
to have extern C linkage) is in fact required by the ABI. Although it's
technically a source-incompatible change, since G++ doesn't implement linkage
for function pointers, there's no way that a user of G++ can tell the
difference. Therefore, I think that's the right thing to do.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29095
[Bug target/25477] builtin functions should use $LDBL128 suffix on darwin when appropriate
--- Comment #8 from geoffk at gcc dot gnu dot org 2006-10-06 19:20 --- The general problem here is that on PPC Darwin, when using gcc with -mlong-double-128 (which is the default), some system functions (you can find a list in bug 25850) need to have $LDBL128 appended to their assembly names. For the variadic functions, like printf, which might not have any long doubles passed to them, this should happen only when compiling for 10.3.9 and later, since these functions aren't available earlier; the user needs to avoid calling those functions with long doubles when compiling with a -mmacosx-version-min of less than 10.3.9. -- geoffk at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet|*-*-darwin[789]*|powerpc-*-darwin[789]* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25477
[Bug xml/29362] NullPointerException in gnu.xml.transform.TransformerImpl.strip(libgcj.so.7rh)
--- Comment #5 from tromey at gcc dot gnu dot org 2006-10-06 19:21 --- Created an attachment (id=12391) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12391action=view) proposed patch This patch makes the crash go away. The bug is that strip() unconditionally uses 'stylesheet', but in our case this is null. I have no idea if this patch is correct. Another plausible approach would be to check stylesheet!=null before using it in strip(). I'd appreciate it if someone could look at this rather quickly. It breaks Eclipse in FC6. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29362
[Bug middle-end/29256] [4.2 regression] loop performance regression
--- Comment #17 from rakdver at gcc dot gnu dot org 2006-10-06 19:32 --- Subject: Bug 29256 Author: rakdver Date: Fri Oct 6 19:32:04 2006 New Revision: 117513 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117513 Log: PR middle-end/29256 * tree-ssa-loop-ivopts.c (determine_base_object): Handle pointers casted to integer type. (get_address_cost): Decrease cost of [symbol + index] addressing modes if they are significantly more expensive than [reg + index] ones. * gcc.dg/tree-ssa/loop-19.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/loop-19.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-loop-ivopts.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29256
[Bug fortran/29267] ICE in operand_subword_force, at emit-rtl.c:1353
--- Comment #3 from tobi at gcc dot gnu dot org 2006-10-06 20:36 --- Slightly reduced testcase, gives the same ice: implicit character*32 (a-z) CHARACTER(len=255), DIMENSION(1,2) :: a a = reshape((/ x, to_string(1.0) /), (/ 1, 2 /)) END PROGRAM -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29267
[Bug fortran/29267] ICE in operand_subword_force, at emit-rtl.c:1353
--- Comment #4 from tobi at gcc dot gnu dot org 2006-10-06 20:37 --- Another interesting variation: [EMAIL PROTECTED]:~/src/pr/29267 cat t.f90 implicit character*32 (a-z) CHARACTER(len=255), DIMENSION(1,2) :: a a = reshape((/ to_string(1.0) /), (/ 1, 2 /)) END PROGRAM [EMAIL PROTECTED]:~/src/pr/29267 ~/src/gcc/build/gcc/f951 t.f90 MAIN__ t.f90:1: fatal error: gfc_todo: Not Implemented: complex character array constructors compilation terminated. [EMAIL PROTECTED]:~/src/pr/29267 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29267
[Bug fortran/29373] New: implicit type declaration and contained function clash
(this is a spinoff of PR29267) [EMAIL PROTECTED]:~/src/pr/29267 cat t.f90 implicit character*32 (a-z) CHARACTER(len=255), DIMENSION(1,2) :: a a = reshape((/ to_string(1.0) /), (/ 1, 2 /)) print *, a CONTAINS CHARACTER(32) FUNCTION to_string(x) REAL, INTENT(in) :: x WRITE(to_string, FMT=(F6.3)) x END FUNCTION END PROGRAM [EMAIL PROTECTED]:~/src/pr/29267 gfortran t.f90 In file t.f90:6 CHARACTER(32) FUNCTION to_string(x) 1 In file t.f90:3 a = reshape((/ to_string(1.0) /), (/ 1, 2 /)) 2 Error: Procedure 'to_string' at (1) has an explicit interface and must not have attributes declared at (2) In file t.f90:6 CHARACTER(32) FUNCTION to_string(x) 1 Error: Syntax error in data declaration at (1) In file t.f90:7 REAL, INTENT(in) :: x 1 Error: Unexpected data declaration statement in CONTAINS section at (1) In file t.f90:8 WRITE(to_string, FMT=(F6.3)) x 1 Error: Syntax error in WRITE statement at (1) In file t.f90:9 END FUNCTION 1 Error: Expecting END PROGRAM statement at (1) [EMAIL PROTECTED]:~/src/pr/29267 -- Summary: implicit type declaration and contained function clash Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobi at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29373
[Bug c++/29365] Unnecessary anonymous namespace warnings
--- Comment #5 from jason at gcc dot gnu dot org 2006-10-06 21:00 --- Yes, sorry, I should have said if foo::bar is used in multiple TUs, rather than foo itself. If foo::bar is defined in only one TU, and is used as an opaque type in other TUs, you're fine. Perhaps we should suppress this warning in the main input file. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29365
[Bug fortran/29267] ICE in operand_subword_force, at emit-rtl.c:1353
--- Comment #5 from tobi at gcc dot gnu dot org 2006-10-06 21:01 --- Actually this is invalid code. The string lengths in the constructor are different, even though they have to be the same. See 4.5 in the F95 standard. -- tobi at gcc dot gnu dot org changed: What|Removed |Added Keywords|ice-on-valid-code |ice-on-invalid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29267
[Bug fortran/29267] ICE in operand_subword_force, at emit-rtl.c:1353
-- tobi at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tobi at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-10-04 06:59:59 |2006-10-06 21:42:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29267
[Bug rtl-optimization/29128] [4.2 Regression] ICE: in move_block_after_check, at haifa-sched.c:4337
--- Comment #6 from mkuvyrkov at gcc dot gnu dot org 2006-10-06 21:45 --- Subject: Bug 29128 Author: mkuvyrkov Date: Fri Oct 6 21:45:13 2006 New Revision: 117515 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117515 Log: 2006-10-06 Maxim Kuvyrkov [EMAIL PROTECTED] PR rtl-optimization/29128 * sched-int.h (IS_SPECULATION_BRANCHY_CHECK_P): New macro. * sched-ebb.c (advance_target_bb): Use it to fix condition to allow interblock movement of speculation checks. * gcc.c-torture/compile/pr29128.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr29128.c Modified: trunk/gcc/ChangeLog trunk/gcc/sched-ebb.c trunk/gcc/sched-int.h trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29128
[Bug rtl-optimization/29128] [4.2 Regression] ICE: in move_block_after_check, at haifa-sched.c:4337
--- Comment #7 from mkuvyrkov at gcc dot gnu dot org 2006-10-06 21:51 --- Fixed by the above patch. -- mkuvyrkov at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29128
[Bug target/25477] builtin functions should use $LDBL128 suffix on darwin when appropriate
--- Comment #9 from howarth at nitro dot med dot uc dot edu 2006-10-06 22:46 --- Geoff, Are the variadic functions really worth worrying about? Currently gcc trunk can only be built with the cctools from Xcode 2.4 or later (which basically limits the builds to MacOS X 10.4 machines unless a odcctools build of cctools is used). So for stock configurations, gcc trunk will be unusable on MacOS X 10.3.9. Perhaps we should declare gcc 4.2 as MacOS X 10.4 or later? Jack ps I am referring the requirement of the newer cctools for literal16. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25477
[Bug libgcj/29278] [ecj] libjava Makefile has -j bug
--- Comment #1 from tromey at gcc dot gnu dot org 2006-10-06 22:55 --- Subject: Bug 29278 Author: tromey Date: Fri Oct 6 22:55:24 2006 New Revision: 117521 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117521 Log: PR libgcj/29278: * Makefile.in: Rebuilt. * Makefile.am ($(generic_header_files)): Depend on gcjh.stamp. (gcjh.stamp): New target. Modified: branches/gcj-eclipse/libjava/ChangeLog branches/gcj-eclipse/libjava/Makefile.am branches/gcj-eclipse/libjava/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29278
[Bug libgcj/29278] [ecj] libjava Makefile has -j bug
--- Comment #2 from tromey at gcc dot gnu dot org 2006-10-06 22:55 --- Fix checked in. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29278
[Bug middle-end/29374] New: Inordinate space required for modulo scheduling
Compiling this file took about 2.9GB of ram with -fmodulo-sched -freschedule-modulo-scheduled-loops and 1.8 gigs without (visual inspection of top). I guess even the without space requirements are somewhat outside my expectations. all.i.gz will be attached to the next message. euler-7% gcc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../configure --prefix=/pkgs/gcc-mainline --disable-checking --enable-languages=c Thread model: posix gcc version 4.2.0 20061006 (experimental) With modulo-scheduling: euler-6% gcc -I../include -I. -Wall -W -Wno-unused -O1 -fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fwrapv -fexpensive-optimizations -fforce-addr -fpeephole2 -falign-jumps -falign-functions -fno-function-cse -ftree-copyrename -ftree-fre -ftree-dce -fregmove -fgcse-las -freorder-functions -fcaller-saves -fno-if-conversion2 -foptimize-sibling-calls -fcse-skip-blocks -funit-at-a-time -finline-functions -fmodulo-sched -freschedule-modulo-scheduled-loops -fomit-frame-pointer -fPIC -fno-common -mieee-fp -DHAVE_CONFIG_H -D___PRIMAL -D___LIBRARY -D___GAMBCDIR=\/pkgs/Gambit-C/4.0b20\ -c _io.c -save-temps -ftime-report -fmem-report Memory still allocated at the end of the compilation process Size AllocatedUsedOverhead 8 16k 15k480 1616k 12k352 64 4096 640 64 256 12k 9216 168 512 56k 53k784 1024 136k136k 1904 2048 116k114k 1624 4096 100k100k 1400 8192 56k 56k392 16384 16k 16k 56 112 4096 672 56 208 12k 8112 168 192 12k 8256 168 160 88k 82k 1232 176 160k157k 2240 96 1500k 1475k 20k 416 188k171k 2632 128 52k 51k728 48 228k225k 3648 224 368k359k 5152 32 224k222k 4032 8012k 11k168 Total 3376k 3286k 47k String pool entries 15401 identifiers 15401 (100.00%) slots 32768 bytes 426k (18k overhead) table size 256k coll/search 0.3413 ins/search 0.0729 avg. entry 28.37 bytes (+/- 15.54) longest entry 92 ??? tree nodes created (No per-node statistics) Type hash: size 1021, 372 elements, 0.247253 collisions DECL_DEBUG_EXPR hash: size 1021, 0 elements, 0.00 collisions DECL_VALUE_EXPR hash: size 1021, 0 elements, 0.00 collisions Execution times (seconds) TOTAL : 0.46 0.02 0.64 3231 kB Memory still allocated at the end of the compilation process Size AllocatedUsedOverhead 8 16k 13k480 1692k 39k 2024 64 820k729k 12k 256 40961024 56 512 4096 512 56 1024 124k120k 1736 2048 12k 10k168 4096 64k 64k896 8192 40k 40k280 16384 16k 16k 56 32768 96k 96k168 65536704k704k616 131072512k512k224 524288 1024k 1024k112 112 216k200k 3024 208 20k 17k280 192 1572k 1539k 21k 160 40k 18k560 176 976k723k 13k 96 5536k 4706k 75k 416 16k 8320 224 48 1744k826k 27k 224 440k390k 6160 32 1616k257k 28k 80 9624k 1018k131k Total 24M 12M327k String pool entries 49980 identifiers 49980 (100.00%) slots 131072 bytes 736k (54k overhead) table size 1024k coll/search 0.4881 ins/search 0.1914 avg. entry 15.09 bytes (+/- 11.94) longest entry 92 ??? tree nodes created (No per-node statistics) Type hash: size 1021, 515 elements, 0.801737 collisions DECL_DEBUG_EXPR hash: size 4093, 0 elements, 0.732265 collisions DECL_VALUE_EXPR hash: size 1021, 0 elements, 0.00 collisions Execution times (seconds) garbage collection: 1.69 ( 2%) usr 0.08 ( 1%) sys 1.81 ( 2%) wall 0 kB ( 0%) ggc callgraph construction: 0.21 ( 0%) usr 0.03 ( 1%) sys 0.26 ( 0%) wall 4932 kB ( 0%) ggc callgraph optimization: 0.01 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 0 kB ( 0%) ggc ipa reference : 0.06 ( 0%) usr 0.02 ( 0%) sys 0.08 ( 0%) wall 8 kB ( 0%) ggc cfg cleanup
[Bug target/25477] builtin functions should use $LDBL128 suffix on darwin when appropriate
--- Comment #10 from geoffk at gcc dot gnu dot org 2006-10-06 23:05 --- (In reply to comment #9) Geoff, Are the variadic functions really worth worrying about? Currently gcc trunk can only be built with the cctools from Xcode 2.4 or later (which basically limits the builds to MacOS X 10.4 machines unless a odcctools build of cctools is used). So for stock configurations, gcc trunk will be unusable on MacOS X 10.3.9. Perhaps we should declare gcc 4.2 as MacOS X 10.4 or later? Jack ps I am referring the requirement of the newer cctools for literal16. You're confusing host and target. cctools runs on the host, but printf$LDBL128 is a function that exists (or not) on the target. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25477
[Bug middle-end/29374] Inordinate space required for modulo scheduling
--- Comment #1 from lucier at math dot purdue dot edu 2006-10-06 23:06 --- Created an attachment (id=12394) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12394action=view) macro-expanded test file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29374
Copy constructor is not being called
Sorry - The copy constructor is not being called
The program below works for the Solaris and Microsoft compilers, but not for
the GCC compiler. Can anybody else verify this, and or if it's already been
fixed?
I'm using:
-bash-3.00$ gcc -v
Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.6/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-java-awt=gtk
--host=i386-redhat-linux
Thread model: posix
gcc version 3.4.6 20060404 (Red Hat 3.4.6-3)
#include stdio.h
struct S
{
S(){ printf( Inside default constructor \n ); }
S( const S ) { printf( Inside copy constructor \n ); }
};
S f( void )
{
S s1;
return s1;
}
int main ( int, char ** )
{
S s1;
S s2( s1 ); // must call the copy constructor
S s3 = f(); // must call the copy constructor
S s4( f() ); // must call the copy constructor
return 0;
}
#if 0
// GCC output is:
Inside default constructor
Inside copy constructor
Inside default constructor
Inside default constructor
// Both Solaris and Microsoft output is:
Inside default constructor
Inside copy constructor
Inside default constructor
Inside copy constructor
Inside default constructor
Inside copy constructor
#endif
[Bug middle-end/29374] Inordinate space required for modulo scheduling
--- Comment #2 from lucier at math dot purdue dot edu 2006-10-06 23:31 --- On Darwin you can't compile the PPC64 version of _num.c, an even smaller file, with Apple's gcc 4.0.1, and I can't build a 64-bit version of 4.2 to test it. Blah. gcc -mcpu=970 -m64 -I../include -I. -no-cpp-precomp -Wall -W -Wno-unused -O1 -fno-math-errno -fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fwrapv -fexpensive-optimizations -fforce-addr -fpeephole2 -falign-jumps -falign-functions -fno-function-cse -ftree-copyrename -ftree-fre -ftree-dce -fregmove -fgcse-las -freorder-functions -fcaller-saves -fno-if-conversion2 -foptimize-sibling-calls -fcse-skip-blocks -funit-at-a-time -finline-functions -fmodulo-sched -freschedule-modulo-scheduled-loops -fomit-frame-pointer -fPIC -fno-common -DHAVE_CONFIG_H -D___PRIMAL -D___LIBRARY -D___GAMBCDIR=\/usr/local/Gambit-C/4.0b20\ -c _num.c cc1(10820) malloc: *** vm_allocate(size=220135424) failed (error code=3) cc1(10820) malloc: *** error: can't allocate region cc1(10820) malloc: *** set a breakpoint in szone_error to debug cc1: out of memory allocating 220132608 bytes after a total of 0 bytes make[1]: *** [_num.o] Error 1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29374
[Bug target/25477] builtin functions should use $LDBL128 suffix on darwin when appropriate
--- Comment #11 from howarth at nitro dot med dot uc dot edu 2006-10-06 23:54 --- Geoff, Okay. Any chance you or Mike could take a stab at patching this bug in time for gcc 4.2? Jack -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25477
[Bug target/25477] builtin functions should use $LDBL128 suffix on darwin when appropriate
--- Comment #12 from geoffk at apple dot com 2006-10-07 00:28 --- Subject: Re: builtin functions should use $LDBL128 suffix on darwin when appropriate howarth at nitro dot med dot uc dot edu [EMAIL PROTECTED] writes: Any chance you or Mike could take a stab at patching this bug in time for gcc 4.2? No chance. It's not a regression and so not suitable for 4.2. Even for 4.3, I have no reason to think it's more important than what I'm spending time on now. Why don't you fix it, if you think it's important? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25477
[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
--- Comment #7 from ghazi at gcc dot gnu dot org 2006-10-07 02:04 --- (In reply to comment #6) There is mpfr_get_ld(), which converts to a long double. If the data type never exceeds the properties of long double, then one may be able to use mpfr_get_ld() and then fold_convert() the result to the proper type. I think using long double defeats the whole purpose of using mpfr. It appears you misread what I wrote (or meant to write). If the data type never exceeds the properties of long double applies to a cross compiler as well where data type is on the target and long double is on the host. We're supposed to avoid relying on the properties of the host's floating point for cross-compilers where the target format is different. The host's long double is simply an intermediate representation of the value. It is the responsibility of the fold_convert to get the right target representation. This is no different than using strings as the intermediate. I want the optimization to work always, not just in certain host/target combinations. So I'll use strings, no big deal. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335
[Bug c++/29375] New: gcc4.0.3 produces code that copies a structure twice
Using built-in specs.
Target: x86_64-redhat-linux-gnu
Configured with: ../gcc-4.0.3/configure x86_64-redhat-linux-gnu
--with-ld=/pixar/d2/sets/tools-03/bin/ld
--with-as=/pixar/d2/sets/tools-03/bin/as --prefix=/pixar/d2/sets/tools-03
--exec-prefix=/pixar/d2/sets/tools-03 --bindir=/pixar/d2/sets/tools-03/bin
--sbindir=/pixar/d2/sets/tools-03/sbin --sysconfdir=/pixar/d2/sets/tools-03/etc
--datadir=/pixar/d2/sets/tools-03/share
--includedir=/pixar/d2/sets/tools-03/include
--libdir=/pixar/d2/sets/tools-03/lib
--libexecdir=/pixar/d2/sets/tools-03/libexec
--localstatedir=/pixar/d2/sets/tools-03/var
--sharedstatedir=/pixar/d2/sets/tools-03/com
--mandir=/pixar/d2/sets/tools-03/man --infodir=/pixar/d2/sets/tools-03/info
--enable-version-specific-runtime-libs --enable-symvers
--enable-languages=c++,objc,f95 --enable-threads=posix --enable-shared
--enable-mudflap
Thread model: posix
gcc version 4.0.3
--code
struct Big {
char data[1024];
};
void ByValue(Big);
void MakeACopy() {
Big stuff;
ByValue(stuff);
}
---
The relevant assembly code, when compiled as: g++ -O2 -S prog.cpp
.globl _Z9MakeACopyv
.type _Z9MakeACopyv, @function
_Z9MakeACopyv:
.LFB2:
pushq %rbx
.LCFI0:
movl$1024, %edx
subq$3072, %rsp
.LCFI1:
leaq2048(%rsp), %rbx
leaq1024(%rsp), %rsi
movq%rbx, %rdi
callmemcpy
movq%rbx, %rsi
movq%rsp, %rdi
movl$1024, %edx
callmemcpy
call_Z7ByValue3Big
addq$3072, %rsp
popq%rbx
ret
---
I'm far from an export, but it sure looks to me like memcpy is being called
twice to copy the data!
This is supported by the fact that gcc3.3.2 only emits code to copy it once,
and that code runs twice as fast.
Also, gcc3.3.2 inlines the memcpy, while gcc4.0.3 does not. I assume that's a
regression as well?
If not, what's the best option to tell gcc4.0.3 to inline the copy?
--
Summary: gcc4.0.3 produces code that copies a structure twice
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: deb at pixar dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29375
[Bug c++/23372] [4.0/4.1 Regression] Temporary aggregate copy not elided when passing parameters by value
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to work|3.4.0 3.3.3 3.2.3 3.0.4 |3.4.0 3.3.3 3.2.3 3.0.4 |2.95.3 4.2.0|2.95.3 4.2.0 4.0.4 4.1.2 Target Milestone|4.1.2 |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23372
[Bug c++/29375] gcc4.0.3 produces code that copies a structure twice
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-07 03:50 --- I think this was fixed in 4.0.4 by the patch which fixed PR 23372. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29375
[Bug c++/29375] gcc4.0.3 produces code that copies a structure twice
--- Comment #2 from deb at pixar dot com 2006-10-07 04:00 --- (In reply to comment #1) I think this was fixed in 4.0.4 by the patch which fixed PR 23372. For various reasons, upgrading to 4.0.4 isn't an option at this time. (a) How do I obtain the specific patch you are referring to and (b) any idea if it would be safe to apply this patch to our current 4.0.3 source? Also, are you saying that the fix for PR23372 also brings us back to avoiding direct calls to memcpy? That may be the bigger issue; the number of POD datastructures we're copying around is probably very small. I was really trying to uncover why we were calling mempcy directly when I noticed the second copy. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29375
[Bug c++/29375] gcc4.0.3 produces code that copies a structure twice
--- Comment #3 from deb at pixar dot com 2006-10-07 04:01 --- Oops, I see how to get the patch. Never mind that part of the question, thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29375
[Bug c++/29375] gcc4.0.3 produces code that copies a structure twice
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-07 04:05 --- (In reply to comment #2) Also, are you saying that the fix for PR23372 also brings us back to avoiding direct calls to memcpy? No just the duplicated memcpy. not inlining memcpy is most likely not a bug, just tunning differences. If you want it inlined you should use -minline-all-stringops which just inlines always most of standard C string functions including memcpy but you should do timings before you do that because memcpy can be optimized for your target more than what gets inlined. For an example it could use SSE registers to do the copy if they exist. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29375
[Bug c/29376] New: Internal error: Killed
cc: Internal error: Killed (program cc1) Please submit a full bug report. See URL:http://gcc.gnu.org/bugs.html for instructions. For Debian GNU/Linux specific bug reporting instructions, see URL:file:///usr/share/doc/gcc-4.0/README.Bugs. make: *** [opcodeiz.o] Error 1 The source files used are at http://deft.thunkers.net/priv/asmsh_mod.tgz Compiled with -O2 -g --save-temps gcc info: $ gcc -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.0 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-java-awt=gtk-default --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --enable-mpfr --disable-werror --with-tune=i686 --enable-checking=release i486-linux-gnu Thread model: posix gcc version 4.0.4 20060507 (prerelease) (Debian 4.0.3-3) $ System info: Linux test 2.6.16.13-xenU-rimu6 #1 Wed Aug 30 05:37:56 UTC 2006 i686 GNU/Linux If anything else is needed, e-mail me at my registered address, thanks. -- Summary: Internal error: Killed Product: gcc Version: 4.0.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: deft at thunkers dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29376
[Bug middle-end/29376] Internal error: Killed
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-07 05:04 --- cc: Internal error: Killed (program cc1) This means you ran out of memory while running cc1. The kernel killed cc1 so we cannot do a better job at the error message. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |middle-end Keywords||memory-hog http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29376
[Bug c/29376] Internal error: Killed
--- Comment #2 from deft at thunkers dot net 2006-10-07 05:14 --- (In reply to comment #1) cc: Internal error: Killed (program cc1) This means you ran out of memory while running cc1. The kernel killed cc1 so we cannot do a better job at the error message. Ok. It compiles fine on a friend's ubuntu running 4.0.3, so I figured I'd shoot you guys the bug report as instructed. -- deft at thunkers dot net changed: What|Removed |Added Component|middle-end |c http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29376
