[Bug target/27396] New: It seems that x86_64-unknown-openbsd3.9 is completely unsupported.
Hello,
while trying to compile recent trunk (20060502) on AMD64/OpenBSD platform I've
found that compilation fails quickly with:
checking for .preinit_array/.init_array/.fini_array support... no
checking if mkdir takes one argument... no
*** Configuration x86_64-unknown-openbsd3.9 not supported
gmake[2]: *** [configure-stage1-gcc] Error 1
gmake[2]: Leaving directory `/home/karel/obj'
gmake[1]: *** [stage1-bubble] Error 2
gmake[1]: Leaving directory `/home/karel/obj'
gmake: *** [bootstrap] Error 2
I've configured GCC with:
/home/karel/svn/gcc/trunk/configure
--prefix=/home/karel/usr/local/gcc-trunk-20060502 --enable-shared
--enable-threads --enable-languages=c++ --disable-checking --disable-nls
--disable-werror
and tried to build it with:
time gmake CFLAGS=-O LIBCFLAGS=-g -O2 LIBCXXFLAGS=-g -O2
-fno-implicit-templates bootstrap
Am I right assuming that this platform is completely unsupported, or have I
done anything wrong?
Thanks,
Karel
Karel
--
Summary: It seems that x86_64-unknown-openbsd3.9 is completely
unsupported.
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kgardas at objectsecurity dot com
GCC build triplet: x86_64-unknown-openbsd3.9
GCC host triplet: x86_64-unknown-openbsd3.9
GCC target triplet: x86_64-unknown-openbsd3.9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27396
[Bug middle-end/17278] [4.0/4.1 Regression] 8% C++ compile-time regression in comparison with 3.4.1 at -O1 optimization level
--- Additional Comments From kgardas at objectsecurity dot com 2005-03-02 20:05 --- Subject: Re: [4.0/4.1 Regression] 8% C++ compile-time regression in comparison with 3.4.1 at -O1 optimization level New results for 4.0.0 20050301 are posted here: http://gcc.gnu.org/ml/gcc/2005-03/msg00132.html Cheers, Karel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17278
[Bug middle-end/13776] [4.0/4.1 Regression] Many C++ compile-time regressions for MICO's ORB code
--- Additional Comments From kgardas at objectsecurity dot com 2005-03-02 20:09 --- New results meassured for MICO compiled with 4.0.0 20050301 are posted here: http://gcc.gnu.org/ml/gcc/2005-03/msg00132.html Cheers, Karel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13776
[Bug middle-end/17278] [4.0/4.1 Regression] 8% C++ compile-time regression in comparison with 3.4.1 at -O1 optimization level
--- Additional Comments From kgardas at objectsecurity dot com 2005-03-02 21:25 --- Subject: Re: [4.0/4.1 Regression] 8% C++ compile-time regression in comparison with 3.4.1 at -O1 optimization level I agree with Giovanni that both #17278 and #13776 are fixed from MICO compile-time regressions point of view. If you would like to close them, I'm also for it, just please be careful with #13776 which seems to "accumulate" more staff than only MICO-related regressions. Thanks! Karel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17278
[Bug libstdc++/43683] New: libstdc++ profile mode is not working on OpenSolaris (build 134) due to compilation failure
c-solaris2.11/4.5.0/../../../../include/c++/4.5.0/profile/impl/profiler_trace.h:307:3:
error: no match for âoperator=â in
â((__gnu_profile::__trace_base<__gnu_profile::__map2umap_info,
__gnu_profile::__map2umap_stack_info>*)this)->__gnu_profile::__trace_base<__gnu_profile::__map2umap_info,
__gnu_profile::__map2umap_stack_info>::__stack_table_lock = {{0, 0, 0, 0,
19800}, {{{0}}}, 0}â
/usr/include/sys/types.h:404:31: note: candidate is: _pthread_mutex&
_pthread_mutex::operator=(const _pthread_mutex&)
/usr/local/gcc-4.5-rc0-20100412/lib/gcc/i386-pc-solaris2.11/4.5.0/../../../../include/c++/4.5.0/profile/impl/profiler_trace.h:
In constructor â__gnu_profile::__trace_base<__object_info,
__stack_info>::__trace_base() [with __object_info =
__gnu_profile::__vector2list_info, __stack_info =
__gnu_profile::__vector2list_stack_info]â:
/usr/local/gcc-4.5-rc0-20100412/lib/gcc/i386-pc-solaris2.11/4.5.0/../../../../include/c++/4.5.0/profile/impl/profiler_vector_to_list.h:173:66:
instantiated from here
/usr/local/gcc-4.5-rc0-20100412/lib/gcc/i386-pc-solaris2.11/4.5.0/../../../../include/c++/4.5.0/profile/impl/profiler_trace.h:307:3:
error: no match for âoperator=â in
â((__gnu_profile::__trace_base<__gnu_profile::__vector2list_info,
__gnu_profile::__vector2list_stack_info>*)this)->__gnu_profile::__trace_base<__gnu_profile::__vector2list_info,
__gnu_profile::__vector2list_stack_info>::__stack_table_lock = {{0, 0, 0, 0,
19800}, {{{0}}}, 0}â
/usr/include/sys/types.h:404:31: note: candidate is: _pthread_mutex&
_pthread_mutex::operator=(const _pthread_mutex&)
/usr/local/gcc-4.5-rc0-20100412/lib/gcc/i386-pc-solaris2.11/4.5.0/../../../../include/c++/4.5.0/profile/impl/profiler_trace.h:
In constructor â__gnu_profile::__trace_base<__object_info,
__stack_info>::__trace_base() [with __object_info =
__gnu_profile::__list2slist_info, __stack_info =
__gnu_profile::__list2slist_stack_info]â:
/usr/local/gcc-4.5-rc0-20100412/lib/gcc/i386-pc-solaris2.11/4.5.0/../../../../include/c++/4.5.0/profile/impl/profiler_list_to_slist.h:99:66:
instantiated from here
/usr/local/gcc-4.5-rc0-20100412/lib/gcc/i386-pc-solaris2.11/4.5.0/../../../../include/c++/4.5.0/profile/impl/profiler_trace.h:307:3:
error: no match for âoperator=â in
â((__gnu_profile::__trace_base<__gnu_profile::__list2slist_info,
__gnu_profile::__list2slist_stack_info>*)this)->__gnu_profile::__trace_base<__gnu_profile::__list2slist_info,
__gnu_profile::__list2slist_stack_info>::__stack_table_lock = {{0, 0, 0, 0,
19800}, {{{0}}}, 0}â
/usr/include/sys/types.h:404:31: note: candidate is: _pthread_mutex&
_pthread_mutex::operator=(const _pthread_mutex&)
/usr/local/gcc-4.5-rc0-20100412/lib/gcc/i386-pc-solaris2.11/4.5.0/../../../../include/c++/4.5.0/profile/impl/profiler_trace.h:
In constructor â__gnu_profile::__trace_base<__object_info,
__stack_info>::__trace_base() [with __object_info =
__gnu_profile::__list2vector_info, __stack_info =
__gnu_profile::__list2vector_stack_info]â:
/usr/local/gcc-4.5-rc0-20100412/lib/gcc/i386-pc-solaris2.11/4.5.0/../../../../include/c++/4.5.0/profile/impl/profiler_list_to_vector.h:172:66:
instantiated from here
/usr/local/gcc-4.5-rc0-20100412/lib/gcc/i386-pc-solaris2.11/4.5.0/../../../../include/c++/4.5.0/profile/impl/profiler_trace.h:307:3:
error: no match for âoperator=â in
â((__gnu_profile::__trace_base<__gnu_profile::__list2vector_info,
__gnu_profile::__list2vector_stack_info>*)this)->__gnu_profile::__trace_base<__gnu_profile::__list2vector_info,
__gnu_profile::__list2vector_stack_info>::__stack_table_lock = {{0, 0, 0, 0,
19800}, {{{0}}}, 0}â
/usr/include/sys/types.h:404:31: note: candidate is: _pthread_mutex&
_pthread_mutex::operator=(const _pthread_mutex&)
Preprocessed file attached.
Thanks,
Karel
--
Summary: libstdc++ profile mode is not working on OpenSolaris
(build 134) due to compilation failure
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kgardas at objectsecurity dot com
GCC build triplet: i386-pc-solaris2.11
GCC host triplet: i386-pc-solaris2.11
GCC target triplet: i386-pc-solaris2.11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43683
[Bug libstdc++/43683] libstdc++ profile mode is not working on OpenSolaris (build 134) due to compilation failure
--- Comment #1 from kgardas at objectsecurity dot com 2010-04-08 08:16 --- Created an attachment (id=20332) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20332&action=view) preprocessed test.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43683
[Bug c++/42576] New: GCC miscompiles switch statement (omits case label/block)
Hello,
first of all, I've tried hard to judge if MICO[1] code is wrong or GCC is wrong
in this case, but I still think GCC is wrong here, hence reporting this. I'm
not able to simplify testcase for this, but we're using following idiom:
#include
#include
using namespace std;
#define TK_RECURSIVE ((int)0x)
class TypeCode {
public:
int tckind;
TypeCode(int v)
: tckind(v)
{}
};
int
main(int argc, char* argv[])
{
TypeCode* tc = NULL;
if (argc > 5) {
tc = new TypeCode(TK_RECURSIVE);
}
else {
tc = new TypeCode(argc);
}
switch (tc->tckind) {
case 1:
case 2:
case 3:
case 4:
case 5:
cout << "number supplied" << endl;
break;
case TK_RECURSIVE:
cout << "TK_RECURSIVE is working!" << endl;
break;
default:
cout << "C++ Compiler BUG!" << endl;
assert(0);
}
return 0;
}
i.e. quite long switch statement of `int' where (int)0x is used as a
case label this everything done in object (C++ class). Some case blocks are
also rather large (several C++ code lines) Please note: the code above just
shows an idiom, but is not able to duplicate my issue. First problem seems to
be shown by GCC complaining with a warning like:
typecode.cc: In member function âCORBA::Boolean
CORBA::TypeCode::equal(CORBA::TypeCode*, CORBA::Boolean, CORBA::Boolean)
constâ:
typecode.cc:750: warning: case label value is less than minimum value for type
typecode.cc: In member function âCORBA::Boolean
CORBA::TypeCode::equaltype(CORBA::TypeCode*,
std::set,
std::less >,
std::allocator > >*)â:
typecode.cc:827: warning: case label value is less than minimum value for type
typecode.cc: In member function âCORBA::Boolean
CORBA::TypeCode::decode(CORBA::DataDecoder&, std::map, std::less,
std::allocator > > >*, CORBA::ULong)â:
typecode.cc:1672: warning: case label value is less than minimum value for type
typecode.cc: In member function âvoid
CORBA::TypeCode::encode(CORBA::DataEncoder&, std::map,
std::allocator > >*)
constâ:
typecode.cc:1913: warning: case label value is less than minimum value for type
so GCC does not like our code that much, although I think it's completely legal
(the same code is well compilable by GCC up to 4.3.x version, Sun C++ up to
5.10 and Intel C++, the issue starts with GCC 4.4.x).
The second problem seems to be that GCC completely omits generating code for
this as it thinks bad case label block. This results in a switch statement code
being corrupted and application not working well. Concretely I'm seeing asserts
done in default switch block.
I've tested simple workaround which is moving problematic case block in front
of the switch block into simple `if' statement and this works well. Fully
preprocessed source code is attached for your reference, you can find
appropriate lines following warnings above inside it.
Thanks for looking into it!
Karel
[1]: www.mico.org
--
Summary: GCC miscompiles switch statement (omits case
label/block)
Product: gcc
Version: 4.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kgardas at objectsecurity dot com
GCC build triplet: i386-pc-solaris2.11
GCC host triplet: i386-pc-solaris2.11
GCC target triplet: i386-pc-solaris2.11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42576
[Bug c++/42576] GCC miscompiles switch statement (omits case label/block)
--- Comment #1 from kgardas at objectsecurity dot com 2010-01-01 19:20 --- Created an attachment (id=19438) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19438&action=view) MICO's head preprocessed typecode.cc file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42576
[Bug c++/42576] GCC miscompiles switch statement (omits case label/block)
--- Comment #5 from kgardas at objectsecurity dot com 2010-01-01 20:34 --- yes, tckind is enum. Thanks for pointing out that this is MICO code issue. If you also could be so kind and cite some C++/C language specification point which GCC follows here and which all older GCC releases "overlooked" (or does not implement support for) as does Sun's C++ and Intel C++ that would be great. I find somehow silly that while using GCC 4.4.x (1) I'm able to assign arbitrary value to enum type variable w/o any warning, (2) I'm able to use arbitrary int for comparison with enum and (3) if I set enum variable value to arbitrary integer I'm able to use this arbitrary integer in `if/else' comparison successfully so the assignment nor comparison is not truncated to enum value IMHO, yet still it does omit my arbitrary integer from switch/case. Isn't this kind of strange? Thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42576
[Bug c++/43980] New: Using __sync_fetch_and_add produces linking errors on OpenSolaris
Hello,
my gcc is my own built:
$ c++ -v
Using built-in specs.
Target: i386-pc-solaris2.11
Configured with: ../gcc-4.4.2/configure --prefix=/usr/local/gcc-4.4.2
--with-as=/usr/bin/gas --with-gnu-as --with-ld=/usr/bin/ld --without-gnu-ld
--enable-shared --enable-threads --enable-languages=c++
--with-gmp-include=/usr/include/gmp --with-mpfr-include=/usr/include/mpfr
Thread model: posix
gcc version 4.4.2 (GCC)
I'm trying to compile as simple as possible __sync_fetch_and_add testcase:
#include
using namespace std;
int
main()
{
int x = 2;
int y = __sync_fetch_and_add(&x, 1);
cerr << "y: " << y << endl;
return y;
}
but the problem is that linking of this fails:
$ c++ sync_fetch_and_add_test.cc
Undefined first referenced
symbol in file
__sync_fetch_and_add_4 /var/tmp//cc17aqlv.o
ld: fatal: symbol referencing errors. No output written to a.out
collect2: ld returned 1 exit status
I've tried the same on OpenSuSE 11.2 with distro provided GNU C++ 4.4.1 and the
testcase links fine. Is there any known issue why GNU C++ does not support this
on OpenSolaris 2009.06?
Thanks!
Karel
--
Summary: Using __sync_fetch_and_add produces linking errors on
OpenSolaris
Product: gcc
Version: 4.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kgardas at objectsecurity dot com
GCC build triplet: i386-pc-solaris2.11
GCC host triplet: i386-pc-solaris2.11
GCC target triplet: i386-pc-solaris2.11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43980
[Bug c++/43980] Using __sync_fetch_and_add produces linking errors on OpenSolaris
--- Comment #3 from kgardas at objectsecurity dot com 2010-05-03 20:30 --- Folks, please close this. Indeed, when I add -march=i486 I get no linker errors anymore. Thanks for your fast help! Karel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43980
[Bug libstdc++/43259] ext/profile/all.cc fails on Solaris
--- Comment #15 from kgardas at objectsecurity dot com 2010-05-05 10:45 --- Created an attachment (id=20560) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20560&action=view) Output of compiler patched with 43259-0504.patch on SunOS 5.11 snv_134 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43259
[Bug libstdc++/43259] ext/profile/all.cc fails on Solaris
--- Comment #16 from kgardas at objectsecurity dot com 2010-05-05 10:46 --- (From update of attachment 20560) Hello, unfortunately your patch is still not working, but it seems you've solved originally reported issue. See attached log file for compilers complains with your patch applied. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43259
[Bug libstdc++/43259] ext/profile/all.cc fails on Solaris
--- Comment #22 from kgardas at objectsecurity dot com 2010-05-07 06:53
---
Viola! Something happens now! Thanks for fixing this.
$ cat test-profile-mode.cc
#include
using namespace std;
int main() {
vector v;
for (int k = 0; k < 1024; ++k) v.insert(v.begin(), k);
}
$ c++ -D_GLIBCXX_PROFILE test-profile-mode.cc
$ ./a.out
$ ls -la libstdcxx-profile.*
-rw-r--r-- 1 karelkarel520 May 7 08:52
libstdcxx-profile.conf.out
-rw-r--r-- 1 karelkarel152 May 7 08:52 libstdcxx-profile.raw
-rw-r--r-- 1 karelkarel268 May 7 08:52 libstdcxx-profile.txt
$ uname -a
SunOS thinkpad 5.11 snv_134 i86pc
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43259
[Bug c++/26966] New: linking of C++ app fail on OpenBSD 3.9 due POSIX threading unresolved symbols
d3.9/4.2.0/libgcc.a(unwind-sjlj.o)(.text+0x3ee):
In function `_Unwind_Backtrace':
/home/karel/svn/gcc/trunk/gcc/gthr-posix.h:536: undefined reference to
`pthread_getspecific'
/home/karel/usr/local/gcc-trunk-20060331/lib/gcc/i386-unknown-openbsd3.9/4.2.0/libgcc.a(unwind-sjlj.o)(.text+0x46a):
In function `_Unwind_SjLj_Resume_or_Rethrow':
/home/karel/svn/gcc/trunk/gcc/gthr-posix.h:536: undefined reference to
`pthread_getspecific'
/home/karel/usr/local/gcc-trunk-20060331/lib/gcc/i386-unknown-openbsd3.9/4.2.0/libgcc.a(unwind-sjlj.o)(.text+0x4cf):
In function `_Unwind_SjLj_Resume':
/home/karel/svn/gcc/trunk/gcc/gthr-posix.h:536: undefined reference to
`pthread_getspecific'
/home/karel/usr/local/gcc-trunk-20060331/lib/gcc/i386-unknown-openbsd3.9/4.2.0/libgcc.a(unwind-sjlj.o)(.text+0x536):
In function `_Unwind_SjLj_ForcedUnwind':
/home/karel/svn/gcc/trunk/gcc/gthr-posix.h:536: undefined reference to
`pthread_getspecific'
collect2: ld returned 1 exit status
If I add -lpthread to the command-line, then everything works as expected. The
same behaviour is also presented on 4.1.0 and 4.0.3 releases.
Cheers,
Karel
--
Summary: linking of C++ app fail on OpenBSD 3.9 due POSIX
threading unresolved symbols
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kgardas at objectsecurity dot com
GCC build triplet: i386-unknown-openbsd3.9
GCC host triplet: i386-unknown-openbsd3.9
GCC target triplet: i386-unknown-openbsd3.9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26966
[Bug other/26966] linking of C++ app fail on OpenBSD 3.9 due POSIX threading unresolved symbols
--- Comment #3 from kgardas at objectsecurity dot com 2006-04-02 19:08 --- Created an attachment (id=11186) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11186&action=view) Hello World test preprocessed source Hello, here is requested preprocessed source bzip2ed. Karel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26966
[Bug other/26966] linking of C++ app fail on OpenBSD 3.9 due POSIX threading unresolved symbols
--- Comment #5 from kgardas at objectsecurity dot com 2006-04-02 19:18 --- Hello, I don't know if it is of any use, but from the OpenBSD history I remember it used really ancient binutils version, i.e. as 0.92 or so, the linker very same. Now, at least in 3.9 it's using FSF binutils 2.15, with probably some patches applied. During my search thorough libstdc++ sources, I've found some references and specific file for free and netbsds, but nothing for OpenBSD. Does it mean this OS is completely unsupported by libstdc++? Thanks, Karel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26966
[Bug other/26966] linking of C++ app fail on OpenBSD 3.9 due POSIX threading unresolved symbols
--- Comment #6 from kgardas at objectsecurity dot com 2006-04-02 19:23 --- After correcting abort(0) to abort() on line 9 I get: $ /home/karel/usr/local/gcc-trunk-20060331/bin/gcc test.c test.c: In function 'main': test.c:9: warning: incompatible implicit declaration of built-in function 'abort' test.c:11: warning: incompatible implicit declaration of built-in function 'exit' $ ./a.out $ ls -la a.out -rwxr-xr-x 1 karel wheel 6512 Apr 2 21:20 a.out $ ldd a.out a.out: StartEnd Type Open Ref GrpRef Name exe 10 0 a.out 0149b000 214cc000 rlib 01 0 /usr/lib/libc.so.39.0 0bb97000 0bb97000 rtld 01 0 /usr/libexec/ld.so $ At least I assumed that I should compile with 4.2, since OpenBSD's 3.3.5 complained with: $ gcc test.c test.c:2: warning: `__weakref__' attribute directive ignored test.c: In function `main': test.c:9: error: too many arguments to function `abort' and GCC 4.2 complained about abort in the same way: $ /home/karel/usr/local/gcc-trunk-20060331/bin/gcc test.c test.c: In function 'main': test.c:9: warning: incompatible implicit declaration of built-in function 'abort' test.c:9: error: too many arguments to function 'abort' test.c:11: warning: incompatible implicit declaration of built-in function 'exit' So I hope I've not breaken your test code too much. Thanks, Karel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26966
[Bug other/26966] linking of C++ app fail on OpenBSD 3.9 due POSIX threading unresolved symbols
--- Comment #8 from kgardas at objectsecurity dot com 2006-04-03 06:59
---
Subject: Re: linking of C++ app fail on OpenBSD 3.9 due
POSIX threading unresolved symbols
> Now if this works, then we have a problem in libstdc++ check to enable weakref
> for some reason.
Could you be so kind and point me into direction where the check is made?
Anyway, greping thorough sources for "weakref" and thorough build
directory I've found this (in build dir):
$ find . -name 'config*' -exec grep "weakref" \{} \; -print
configure:13473: checking assembler for .weakref
conftest.s:1: Error: unknown pseudo-op: `.weakref'
.weakref foobar, barfnot
gcc_cv_as_weakref=no
./gcc/config.log
gcc_cv_as_weakref=${gcc_cv_as_weakref=no}
./gcc/config.cache
configure:13473: checking assembler for .weakref
conftest.s:1: Error: unknown pseudo-op: `.weakref'
.weakref foobar, barfnot
gcc_cv_as_weakref=no
./prev-gcc/config.log
gcc_cv_as_weakref=${gcc_cv_as_weakref=no}
./prev-gcc/config.cache
configure:13473: checking assembler for .weakref
conftest.s:1: Error: unknown pseudo-op: `.weakref'
.weakref foobar, barfnot
gcc_cv_as_weakref=no
./stage1-gcc/config.log
gcc_cv_as_weakref=${gcc_cv_as_weakref=no}
./stage1-gcc/config.cache
$
which seems to me .weakref is not supported by assembler. I've tried to
syntetize back the test case and got this:
$ cat /tmp/weakref.s
.weakref foobar, barfnot
$ as /tmp/weakref.s
/tmp/weakref.s: Assembler messages:
/tmp/weakref.s:1: Error: unknown pseudo-op: `.weakref'
$ as --version
GNU assembler 2.15
Copyright 2002 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License. This program has absolutely no warranty.
This assembler was configured for a target of `i386-unknown-openbsd3.9'.
$
It's interesting it's working in gcc then...
Karel
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26966
[Bug other/26966] linking of C++ app fail on OpenBSD 3.9 due POSIX threading unresolved symbols
--- Comment #10 from kgardas at objectsecurity dot com 2006-04-03 07:08 --- Subject: Re: linking of C++ app fail on OpenBSD 3.9 due POSIX threading unresolved symbols Small addition to previous post. Although .weakref is not supported, .weak is: $ cat /tmp/weak-conftest.s .weak foobar $ as /tmp/weak-conftest.s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26966
[Bug other/26966] linking of C++ app fail on OpenBSD 3.9 due POSIX threading unresolved symbols
--- Comment #12 from kgardas at objectsecurity dot com 2006-04-03 08:01 --- Subject: Re: linking of C++ app fail on OpenBSD 3.9 due POSIX threading unresolved symbols Sorry, I've enabled only c++ for this build and I would prefer not to rebuild if possible, since c/c++ took about 4-5 hours to built. Anyway, I consider libstdc++ support to be quite broken on OpenBSD. You named it, shared library is missing and I've also found that other shared libs seems to be presented: $ find . -name '*.so*' ./lib/libssp.so.0.0 ./lib/libgcc-math.so.0.0 ./lib/libgomp.so.1.0 $ if possible please write me what to test/check and I will do this here on OBSD of course. If you point me to the direction of libstdc++ hacker manual (to found out which autoconf is required), I'm able to also check some configure.ac hacks for you. Anyway, if you consider ObjC test important, let me know and I will start rebuild immediatelly. Thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26966
[Bug other/26966] linking of C++ app fail on OpenBSD 3.9 due POSIX threading unresolved symbols
--- Comment #13 from kgardas at objectsecurity dot com 2006-04-04 15:53 --- Subject: Re: linking of C++ app fail on OpenBSD 3.9 due POSIX threading unresolved symbols Hello, I've rebuild todays trunk and configured it as: $ gcc -v Using built-in specs. Target: i386-unknown-openbsd3.9 Configured with: /home/karel/svn/gcc/trunk/configure --prefix=/home/karel/usr/local/gcc-trunk-20060404 --enable-shared --enable-threads --enable-languages=c++,objc --disable-checking --disable-nls --disable-werror Thread model: posix gcc version 4.2.0 20060404 (experimental) $ now I've tested your ObjC test and compilation fails with: $ gcc test.m /tmp//ccsP4264.o(.text+0x18): In function `main': : undefined reference to `objc_get_class' /tmp//ccsP4264.o(.text+0x2c): In function `main': : undefined reference to `objc_msg_lookup' /tmp//ccsP4264.o(.text+0x62): In function `__objc_gnu_init': : undefined reference to `__objc_exec_class' /tmp//ccsP4264.o(.data+0x40): undefined reference to `__objc_class_name_Object' collect2: ld returned 1 exit status $ as it seems gcc does not link against libobjc automatically I also tried this: $ gcc test.m -lobjc and I finally got some POSIX threading related undefined symbols: $ gcc test.m -lobjc /home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0: warning: strcpy() is almost always misused, please use strlcpy() /home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0: warning: sprintf() is often misused, please use snprintf() /home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0: undefined reference to `pthread_cond_signal' /home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0: undefined reference to `pthread_attr_destroy' /home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0: undefined reference to `pthread_create' /home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0: undefined reference to `pthread_getspecific' /home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0: undefined reference to `pthread_attr_init' /home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0: undefined reference to `pthread_exit' /home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0: undefined reference to `pthread_key_delete' /home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0: undefined reference to `pthread_cond_broadcast' /home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0: undefined reference to `pthread_once' /home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0: undefined reference to `pthread_key_create' /home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0: undefined reference to `pthread_cond_init' /home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0: undefined reference to `pthread_mutex_unlock' /home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0: undefined reference to `pthread_self' /home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0: undefined reference to `pthread_mutex_destroy' /home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0: undefined reference to `pthread_mutex_lock' /home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0: undefined reference to `pthread_cond_wait' /home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0: undefined reference to `pthread_mutex_trylock' /home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0: undefined reference to `pthread_cond_destroy' /home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0: undefined reference to `pthread_mutex_init' /home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0: undefined reference to `pthread_attr_setdetachstate' /home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0: undefined reference to `sched_yield' /home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0:
[Bug other/26966] linking of C++/ObjC app fail on OpenBSD 3.9 due POSIX threading unresolved symbols
--- Comment #15 from kgardas at objectsecurity dot com 2006-04-04 15:57 --- I've changed summary from "C++ app" to "C++/ObjC app" to better reflect the issue. -- kgardas at objectsecurity dot com changed: What|Removed |Added Summary|linking of C++ app fail on |linking of C++/ObjC app fail |OpenBSD 3.9 due POSIX |on OpenBSD 3.9 due POSIX |threading unresolved symbols|threading unresolved symbols http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26966
[Bug c++/17278] [4.0 Regression] 24% C++ compile-time regression in comparison with 3.4.1 at -O1 optimization level
--- Additional Comments From kgardas at objectsecurity dot com 2004-12-28 21:00 --- Subject: Re: [4.0 Regression] 24% C++ compile-time regression in comparison with 3.4.1 at -O1 optimization level New comparison is here: http://gcc.gnu.org/ml/gcc/2004-12/msg01157.html Good work! :-) Cheers, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17278
[Bug middle-end/13776] [4.0 Regression] Many C++ compile-time regression in 4.0-tree-ssa 040120
--- Additional Comments From kgardas at objectsecurity dot com 2004-12-28 21:03 --- Hello, New comparison is here: http://gcc.gnu.org/ml/gcc/2004-12/msg01157.html Cheers, Karel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13776
[Bug middle-end/17278] [4.0 Regression] 8% C++ compile-time regression in comparison with 3.4.1 at -O1 optimization level
--- Additional Comments From kgardas at objectsecurity dot com 2004-12-28 22:39 --- Subject: Re: [4.0 Regression] 8% C++ compile-time regression in comparison with 3.4.1 at -O1 optimization level On Tue, 28 Dec 2004, pinskia at gcc dot gnu dot org wrote: > Now only 8%. True for typecode.cc, but not for ir.cc where there is ~28% regression. Cheers, Karel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17278
[Bug middle-end/17278] [4.0 Regression] 8% C++ compile-time regression in comparison with 3.4.1 at -O1 optimization level
--- Additional Comments From kgardas at objectsecurity dot com 2004-12-28 22:42 --- Subject: Re: [4.0 Regression] 8% C++ compile-time regression in comparison with 3.4.1 at -O1 optimization level On Tue, 28 Dec 2004, pinskia at gcc dot gnu dot org wrote: > > On Tue, 28 Dec 2004, pinskia at gcc dot gnu dot org wrote: > > > > > Now only 8%. > > > > True for typecode.cc, but not for ir.cc where there is ~28% regression. > > PR 13776 is keeping track of that regression. > This one is for typecode.cc. Err, you are right! Sorry for that. Karel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17278
[Bug middle-end/13776] [4.0 Regression] Many C++ compile-time regressions for MICO's ORB code
--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen dot de 2005-01-26 10:24 --- Subject: Re: [4.0 Regression] Many C++ compile-time regressions for MICO's ORB code > Bah, I hate profiles for "cc1plus -O2 ir.ii" without peaks: > > CPU: P4 / Xeon with 2 hyper-threads, speed 3194.17 MHz (estimated) > Counted GLOBAL_POWER_EVENTS events (time during which processor is not > stopped) with a unit mask of 0x01 (mandatory) count 10 > samples %symbol name > 25018 1.6858 walk_tree > 24322 1.6389 cgraph_node_for_asm > 19586 1.3198 htab_find_slot_with_hash Do you have numbers wether we are memory-bandwith limited here? If not, we might micro-optimize hash table access somewhat more. --- Additional Comments From kgardas at objectsecurity dot com 2005-01-26 10:24 --- Subject: Re: [4.0 Regression] Many C++ compile-time regressions for MICO's ORB code On Wed, 26 Jan 2005, steven at gcc dot gnu dot org wrote: > > --- Additional Comments From steven at gcc dot gnu dot org 2005-01-26 > 10:20 --- > Bah, I hate profiles for "cc1plus -O2 ir.ii" without peaks: True, if I may add something, I would recommend to look at why ir.cc regress so much in memory consumption in comparison with 3.4.x. If you solve this, perhaps compile time regressions goes away too. Thanks, Karel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13776
[Bug middle-end/13776] [4.0 Regression] Many C++ compile-time regressions for MICO's ORB code
--- Additional Comments From kgardas at objectsecurity dot com 2005-01-26 10:46 --- Subject: Re: [4.0 Regression] Many C++ compile-time regressions for MICO's ORB code Just to note something about 4.0.0 and 3.4.2 memory usage while compiling ir.cc. 3.4.2: it is quickly gorwing up to 90MB RAM, then it stay there for a long time and then goes quickly to 99MB RAM where it finishes -- i.e. majority of time is spend with ~90MB and less consumed memory 4.0.0: in comparison with 3.4.2, it is growing up to 243MB RAM, stays there for some time (not majority but let say 1/3 of compilation certainly), then it goes back to 200MB RAM consumed and then it finishes. Hard to tell avarage memory usage here, but I think it is about 200MB. My 4.0.0 here is quite old 20041228, but I guess the picture is still the same. Thanks, Karel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13776
[Bug middle-end/17278] [4.0 Regression] 8% C++ compile-time regression in comparison with 3.4.1 at -O1 optimization level
--- Additional Comments From kgardas at objectsecurity dot com 2005-01-31 09:00 --- Subject: Re: [4.0 Regression] 8% C++ compile-time regression in comparison with 3.4.1 at -O1 optimization level Hello, new timings are here: http://gcc.gnu.org/ml/gcc/2005-01/msg01714.html Actually typecode.cc went to ~9% regression for -O1, please read this report for more information why. Cheers, Karel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17278
[Bug middle-end/13776] [4.0 Regression] Many C++ compile-time regressions for MICO's ORB code
--- Additional Comments From kgardas at objectsecurity dot com 2005-01-31 09:31 --- Hello, new timings MICO ORB sources are here: http://gcc.gnu.org/ml/gcc/2005-01/msg01714.html Cheers, Karel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13776
[Bug tree-optimization/13776] [4.0 Regression] [tree-ssa] Many C++ compile-time regression in 4.0-tree-ssa 040120
--- Additional Comments From kgardas at objectsecurity dot com 2004-10-25 12:03 --- Subject: Re: [4.0 Regression] [tree-ssa] Many C++ compile-time regression in 4.0-tree-ssa 040120 Sure! Here we go: http://gcc.gnu.org/ml/gcc/2004-10/msg00952.html and results are really promissing, although some interesting regressions are still presented. Cheers, Karel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13776
[Bug c++/17278] [4.0 Regression] 24% C++ compile-time regression in comparison with 3.4.1 at -O1 optimization level
--- Additional Comments From kgardas at objectsecurity dot com 2004-10-25 13:06 --- Subject: Re: [4.0 Regression] 24% C++ compile-time regression in comparison with 3.4.1 at -O1 optimization level Yes, but this only apply to typecode.cc. If you consider ir.cc, you will need to increase from 40 to 44% and since subject does not talk about typecode.cc, I would consider leaving it at 40% better option for now... Cheers, Karel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17278
[Bug c++/17278] [4.0 Regression] 24% C++ compile-time regression in comparison with 3.4.1 at -O1 optimization level
--- Additional Comments From kgardas at objectsecurity dot com 2004-10-25 13:12 --- Subject: Re: [4.0 Regression] 24% C++ compile-time regression in comparison with 3.4.1 at -O1 optimization level Please have a look into http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13776 for preprocessed ir.cc file for your experiments. Cheers, Karel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17278
[Bug tree-optimization/13776] [4.0 Regression] [tree-ssa] Many C++ compile-time regression in 4.0-tree-ssa 040120
--- Additional Comments From kgardas at objectsecurity dot com 2004-10-25 13:20 --- Subject: Re: [4.0 Regression] [tree-ssa] Many C++ compile-time regression in 4.0-tree-ssa 040120 Updated table with GCC 3.4.2 and 4.0.0-041024 results is available here: http://gcc.gnu.org/ml/gcc/2004-10/msg00952.html -- still some regressions mainly on -O1 and -O2. Cheers, Karel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13776
[Bug c++/17278] [4.0 Regression] 24% C++ compile-time regression in comparison with 3.4.1 at -O1 optimization level
--- Additional Comments From kgardas at objectsecurity dot com 2004-10-26 06:45 --- Subject: Re: [4.0 Regression] 24% C++ compile-time regression in comparison with 3.4.1 at -O1 optimization level Hi, I have tested -fno-threadsafe-statics now and it does not affect so much, IMHO: $ c++ -I../include -time -O0 -Wall -DPIC -fPIC -c ir.cc -o ir.pic.o # cc1plus 68.57 2.26 # as 5.92 0.27 $ c++ -I../include -fno-threadsafe-statics -time -O0 -Wall -DPIC -fPIC -c ir.cc -o ir.pic.o # cc1plus 67.94 2.04 # as 5.86 0.26 Cheers, Karel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17278
[Bug tree-optimization/13776] [4.0 Regression] [tree-ssa] Many C++ compile-time regression in 4.0-tree-ssa 040120
--- Additional Comments From kgardas at objectsecurity dot com 2004-11-19 11:14 --- Subject: Re: [4.0 Regression] [tree-ssa] Many C++ compile-time regression in 4.0-tree-ssa 040120 I've tested 3.4.2, 4.0.0 (20041026) and 4.0.0 (20041118) with following results: 3.4.2: c++ -I../include -time -O0 -Wall -DPIC -fPIC -c ir.cc -o ir.pic.o # cc1plus 46.98 0.53 # as 4.62 0.22 peak memory consumed: 99MB 4.0.0 (20041026): c++ -I../include -time -O0 -Wall -DPIC -fPIC -c ir.cc -o ir.pic.o # cc1plus 67.13 2.05 # as 5.98 0.30 peak memory consumed: 243MB 4.0.0 (20041118): c++ -I../include -time -O0 -Wall -DPIC -fPIC -c ir.cc -o ir.pic.o # cc1plus 66.47 1.97 # as 5.84 0.27 peak memory consumed 243MB so there is still both compile-time and memory usage regressions presented on main-line. The reason why do you see speed-up in comparison with 3.1/3.3 is that 3.4.2 is really faster compiler (at least from MICO sources point of view). Cheers, Karel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13776
[Bug tree-optimization/13776] [4.0 Regression] [tree-ssa] Many C++ compile-time regression in 4.0-tree-ssa 040120
--- Additional Comments From kgardas at objectsecurity dot com 2004-11-29 19:56 --- Subject: Re: [4.0 Regression] [tree-ssa] Many C++ compile-time regression in 4.0-tree-ssa 040120 I've updated comparison table for 4.0.0 20041126 compiler version. You can find it here: http://gcc.gnu.org/ml/gcc/2004-11/msg01157.html Cheers, Karel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13776
[Bug tree-optimization/13776] [4.0 Regression] [tree-ssa] Many C++ compile-time regression in 4.0-tree-ssa 040120
--- Additional Comments From kgardas at objectsecurity dot com 2004-11-29 21:04 --- Subject: Re: [4.0 Regression] [tree-ssa] Many C++ compile-time regression in 4.0-tree-ssa 040120 On Mon, 29 Nov 2004, law at redhat dot com wrote: > > I've updated comparison table for 4.0.0 20041126 compiler version. You can > > find it here: http://gcc.gnu.org/ml/gcc/2004-11/msg01157.html > BTW, if I'm reading that table correctly, overall the compile time > performance of mainline is actually on-par or better than 3.4 at > -O0, -O1 and -O2 for this test. Yes, you are 100% right. Karel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13776
[Bug libstdc++/18808] New: iostream include makes algorithm/transform broken
Hello,
using gcc3.4.2, following code compiles well:
1
2 #include
3 #include
4 #include
5 //#include
6
7 using namespace std;
8
9 int
10 main() {
11 string s="HeLLO";
12 transform(s.begin(), s.end(), s.begin(), tolower);
13 return 0;
14 }
15
but when I uncomment iostream include on line 5, it starts to be broken:
$ c++ str.cc
str.cc: In function `int main()':
str.cc:12: error: no matching function for call to
`transform(__gnu_cxx::__normal_iterator, std::allocator > >,
__gnu_cxx::__normal_iterator, std::allocator > >,
__gnu_cxx::__normal_iterator, std::allocator > >, )'
$
Although this code is perfectly compilable by Comeau C++ 4.3.3/Dinkumware 4.02
and Intel C++ 8.0.
Cheers,
Karel
--
Summary: iostream include makes algorithm/transform broken
Product: gcc
Version: 3.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kgardas at objectsecurity dot com
CC: gcc-bugs at gcc dot gnu dot org
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=18808
[Bug libstdc++/18808] iostream include makes algorithm/transform broken
--- Additional Comments From kgardas at objectsecurity dot com 2004-12-03 12:15 --- GCC 4.0.0 20041126 also complains about this code: $ /mnt/karel/gcc-main-20041126/bin/c++ str.cc str.cc: In function 'int main()': str.cc:12: error: no matching function for call to 'transform(__gnu_cxx::__normal_iterator, std::allocator > >, __gnu_cxx::__normal_iterator, std::allocator > >, __gnu_cxx::__normal_iterator, std::allocator > >, )' $ Cheers, Karel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18808
[Bug libstdc++/17315] Strange compile-time regression in cpp against gcc3.4.1
--- Additional Comments From kgardas at objectsecurity dot com 2004-12-08 10:26 --- Subject: Re: Strange compile-time regression in cpp against gcc3.4.1 Sure, close it! 4.0.0 is enough faster anyway! :-) Cheers, Karel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17315
