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-unkno
--- 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
--- 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
--- 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
lation 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
--- 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
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
--- 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
--- 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
ignedTo: 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
--- 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
--- 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/b
--- 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
--- 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);
}
: 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
--- 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
--- 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 FS
--- 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 o
--- 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
--- 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
--- 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 ab
--- 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-un
--- 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
--- 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
--- 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
--- 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
--- 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 De
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: R
--- 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 gorwi
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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+
--- 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:
--- 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
clude 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
--- 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
--- 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
42 matches
Mail list logo
