Hi Rainer,
On Fri, Aug 8, 2014 at 11:04 PM, Rainer Orth
wrote:
> Hi Karel,
>
>> More information: It looks like gcc driver invokes cc1 with -P option
>> which switches off linemakers on Solaris. On Linux cc1 is invoked
>> without -P and so linemakers are presented. The question is why on
>> Solar
gcc itself...
Thanks,
Karel
On Fri, Aug 8, 2014 at 8:47 PM, Karel Gardas wrote:
> Hello,
>
> GHC (Haskell compiler) is using builtin gcc's cpp for its cpp
> capability. The problem is a little bit different behaviour on
> different platform which I observed. As one of GHC's
Hello,
GHC (Haskell compiler) is using builtin gcc's cpp for its cpp
capability. The problem is a little bit different behaviour on
different platform which I observed. As one of GHC's testcases
completely unrelated to gcc's cpp we use:
{-# LANGUAGE CPP #-}
module T7145b ( A.Applicative(pure) ) w
Hello,
I'm using GCC 4.3.2 (debian provided) on IA64 machine and I'm starting
to be hit by while building GHC (Haskell compiler) HEAD:
/usr/bin/ld: : short data segment overflowed (0x434a58 >= 0x40)
/usr/bin/ld: can't relax section: No such file or directory
linker messages. In the past
Hello,
with recent fixes into profile mode I've succeed even using it for
MICO[1] on OpenSolaris platform. It seems only compilation to static
libraries is supported at the moment, but never mind my server run
generates something. As it provides some hints I'd like to more
closely analyze I would
Hello,
I've checkouted todays sources from trunk and I can confirm that the same
failure also happens there.
Cheers,
Karel
On Fri, 31 Mar 2006, Karel Gardas wrote:
Hello,
I'm trying to build GCC-4.2-20060325 on OpenBSD 3.9-current, but it fails
with:
echo timestamp >
en also on more supported
platforms? (Linux/FreeBSD) If so, then my question is: is this already
fixed on trunk?
Thanks,
Karel
--
Karel Gardas [EMAIL PROTECTED]
ObjectSecurity Ltd. http://www.objectsecurity.com
86-unknown-openbsd3.9/4.1.0/libgcc.a(unwind-sjlj.o)(.text+0x4ba):
In function `_Unwind_SjLj_Resume':
/home/karel/build/gcc-4.1.0/gcc/gthr-posix.h:535: undefined reference to
`pthread_getspecific'
/home/karel/usr/local/lib/gcc/i386-unknown-openbsd3.9/4.1.0/libgcc.a(unwind-sjlj.o)(.text+0x521):
In functi
Hello,
I'm curious why is GCC 4.1.0 release libstdc++'s abi_check failing for me
on linux/amd64 platform? I've submited my testsuite results here:
http://gcc.gnu.org/ml/gcc-testresults/2006-03/msg00224.html
Thanks,
Karel
--
Karel Gardas [EMAIL PROTECTED]
Obj
Hello,
it's been a while since my last comparison of various GCC's compilation
performance on MICO sources. A lot happened in GCC development since
then and so I'm here with more up-to-date measurements. This time I've
used MICO 2.3.12 release sources and again measured time of
compilation of o
ar to anyone?
--
Karel Gardas [EMAIL PROTECTED]
ObjectSecurity Ltd. http://www.objectsecurity.com
On Tue, 3 Jan 2006, Richard Earnshaw wrote:
On Tue, 2006-01-03 at 17:15, Karel Gardas wrote:
I have tried this with binutils 2.16.1 and gcc 4.0.1, but w/o success. The
failure happen during compilation of gcc and it looks like:
/tmp/arm-elf-build/obj-gcc/gcc/xgcc -B/tmp/arm-elf-build/obj-gcc
On Tue, 3 Jan 2006, Richard Earnshaw wrote:
On Tue, 2006-01-03 at 15:52, Karel Gardas wrote:
On Tue, 3 Jan 2006, Richard Earnshaw wrote:
On Tue, 2006-01-03 at 15:38, Karel Gardas wrote:
OK, if I understand you well, then I should not use -msoft-float for both:
compiling of eCos lib and
ts to suit your needs (this is for the
multilibs stuff).
Just a note. I'm using/building gcc-4.0.1 and I'm using/hacking t-arm-elf
from the gcc-4.0.1 release.
Anyway, thanks for your kind explanation and advice which I'm going to
follow to see if it solves my issue.
Thanks,
K
On Tue, 3 Jan 2006, Richard Earnshaw wrote:
On Tue, 2006-01-03 at 15:38, Karel Gardas wrote:
OK, if I understand you well, then I should not use -msoft-float for both:
compiling of eCos lib and then for compiling my eCos-based app. The
problem is that this is not right way how to workaround
On Tue, 3 Jan 2006, Richard Earnshaw wrote:
On Sat, 2005-12-31 at 20:26, Karel Gardas wrote:
/home/karel/usr/local/arm-elf1/bin/../lib/gcc/arm-elf/4.0.1/../../../../arm-elf/bin/ld:
ERROR:
/home/karel/usr/local/arm-elf1/bin/../lib/gcc/arm-elf/4.0.1/be/libgcc.a(_dvmd_tls.o)
uses hardware FP
if this
is not the case please correct me.
Thanks,
Karel
--
Karel Gardas [EMAIL PROTECTED]
ObjectSecurity Ltd. http://www.objectsecurity.com
his issue GCC's bug to publicly expose
asinl/ldexpl/frexpl/fmodl/ceill/floorl/fabsl symbols in its libstdc++?
2) is it reliable to use _GLIBCXX_HAVE_ASINL to detect if asinl is just
exposed by libstdc++ and not supported by the target OS?
Thanks,
Karel
--
Karel Gardas
Music Unlimited
Access over 1 million songs. Try it free.
http://music.yahoo.com/unlimited/
--
Karel Gardas [EMAIL PROTECTED]
ObjectSecurity Ltd. http://www.objectsecurity.com
builds using time(1), one with gcc 3.3 and one
with gcc 4.0.
Using gcc 3.3.6: 56692.17s user 2784.40s system 97% cpu 16:54:01.65 total
Using gcc 4.0.2: 39189.33s user 2417.85s system 96% cpu 11:57:52.48 total
5 hours less... and the kernel still works fine.
--
Karel Gardas
used. So I would recommend the same
instead of `make bootstrap'
Cheers,
Karel
--
Karel Gardas [EMAIL PROTECTED]
ObjectSecurity Ltd. http://www.objectsecurity.com
s
PS : Sorry for shouting I can't believe it's so difficult to find
information on this option.
info gcc
info ld
Is this so difficult? Cheers,
Karel
--
Karel Gardas [EMAIL PROTECTED]
ObjectSecurity Ltd. http://www.objectsecurity.com
On Mon, 18 Jul 2005, Janis Johnson wrote:
On Mon, Jul 18, 2005 at 12:53:01PM +0200, Karel Gardas wrote:
I'm trying to build 4.0.1 release on powerpc64-linux, but without success
so far, since build fails with:
I've configured it with:
../gcc-4.0.1/configure --prefix=$HOME/usr
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.
[EMAIL PROTECTED]:/tmp/kgardas/obj$
Any hint how to solve this?
Thanks,
Karel
--
Karel Gardas [EMAIL PROTECTED]
ObjectSecurity Ltd. http://www.objectsecurity.com
r the terms of
the GNU General Public License. This program has absolutely no warranty.
silence:~$
and IMHO testresults look quite good except abi_check, don't they? i.e. do
you mean updating binutils will resolve abi_check issue in libstdc++
testsuite?
Thanks,
Karel
--
Karel Gardas
to find any notes about minimal
binutils 2.15.90.0.1.1 version required for libstdc++ build on AMD64
linux. Especially:
http://gcc.gnu.org/install/specific.html
notes more recent binutils version than 2.15 release only in case of
*-*-solaris2* configuration.
Thanks,
Karel
--
Karel Gardas
, the CPU is IMHO OK. FYI:
IIRC I've been doing 3.4.x builds on my 1GHz PIII + 512MB RAM for around
30 minutes (c/c++) and for around 1.5 hour full build.
Cheers,
Karel
--
Karel Gardas [EMAIL PROTECTED]
ObjectSecurity Ltd. http://www.objectsecurity.com
provided by people on them.
Karel
--
Karel Gardas [EMAIL PROTECTED]
ObjectSecurity Ltd. http://www.objectsecurity.com
a 10x compile time improvement. If someone wants to pull them out
from that branch, I think they are fairly isolated, let me know, and I can
point the way.
If it is possible, I'm at least interested in testing those bits on my
classical "benchmark".
Thanks,
K
On Mon, 23 May 2005, Mark Mitchell wrote:
Mike Stump wrote:
On May 17, 2005, at 3:16 PM, Karel Gardas wrote:
1) the most expensive seems to be comptypes -- at least from data L2
refill point of view (~17%)
2) comptypes is also the most CPU intensive operation since the most
of time is
7.html
and got some interesting results which might be more similar to the
machines with low memory.
Cheers,
Karel
--
Karel Gardas [EMAIL PROTECTED]
ObjectSecurity Ltd. http://www.objectsecurity.com
On Tue, 17 May 2005, Mike Stump wrote:
On May 17, 2005, at 3:16 PM, Karel Gardas wrote:
1) the most expensive seems to be comptypes -- at least from data L2
refill point of view (~17%)
2) comptypes is also the most CPU intensive operation since the most
of time is spent there
I think comptypes
2938 0.0752 48274 6.2699 push_to_top_level
--
Karel Gardas [EMAIL PROTECTED]
ObjectSecurity Ltd. http://www.objectsecurity.com
On Tue, 17 May 2005, Andi Kleen wrote:
Karel Gardas <[EMAIL PROTECTED]> writes:
I've thought that L1 and L2 DTLB misses are the most important for the
overall performance or performance degradation, if not please correct
me since this is my first attempt to measure and interpret such d
0.2335 21898 0.6014
grokdeclarator
44777 1.0027 18205 0.6902 529 0.2758 13609 0.3738
cp_walk_subtrees
39890 0.8933 65131 2.4693 10764 5.6114 6737 0.1850
push_to_top_level
--
Karel Gardas [EMAIL PROTECTED]
Obje
On Tue, 17 May 2005, Alexandre Oliva wrote:
On May 17, 2005, Karel Gardas <[EMAIL PROTECTED]> wrote:
you see that 4.0 added "embedded" platforms like arm-none-elf and
mips-none-elf to the primary platforms list.
These are only embedded targets. You can't run GCC natively o
hat platform would you suggest? I think that if you take the
discussion into this direction then we can see very good fruits comming
from it, at least for some future GCC releases.
Thanks and I appreciate your hard work on rtems/gcc platform!
Karel
--
Karel Gardas [EMAIL PROTECTED]
ObjectSecurity Ltd. http://www.objectsecurity.com
sible, please!
Thanks,
Karel
--
Karel Gardas [EMAIL PROTECTED]
ObjectSecurity Ltd. http://www.objectsecurity.com
he light of your claim that it will results in swapping especially
when we consider developers' machines with 512MB/1GB RAM, i.e. machines
where memory is not "tight".
Thanks,
Karel
--
Karel Gardas [EMAIL PROTECTED]
ObjectSecurity Ltd. http://www.objectsecurity.com
s more on 512MB
due to memory usage heuristic(s) -- so I assume setting hard ulimit to
128MB will just result in build process crashing instead of slowdown and
swapping, which would man get while using mem=128m as a linux boot param.
Or am I completely mistaken?
Thanks,
Karel
e I started.
Is it possible to also add -Os to your tested option set? IMHO this option
is quite necessary for embedded developers who seems to complain in this
thread.
Thanks,
Karel
--
Karel Gardas [EMAIL PROTECTED]
ObjectSecurity Ltd. http://www.objectsecurity.com
Hello,
just short follow-up to this thread. I've also tried gcc head (from today)
and its libstdc++ is OK, i.e. no dead-lock presented. I've also verified
that it is libstdc++ and not libgcc_s.
Any idea what's going wrong with GCC 4.0.x's libstdc++?
Thanks,
Karel
Hello,
in a process of installing new box I've found interesting issue: MICO's
IDL compiler dead-locks while compiled with 4.0.x, but not while compiled
with 3.4.4 (provided by OS). It is even more interesting, since it
dead-locks only when linked against 4.0.x's libstdc++ but not when linked
a
[have not followed this thread, so sorry if it was already suggested]
BTW: Have you tried to also look at what ulimits are set on your system?
Cheers,
Karel
--
Karel Gardas [EMAIL PROTECTED]
ObjectSecurity Ltd. http://www.objectsecurity.com
etween
3.4.x and 4.0.0!
Conclusion: people are willing to investigate compiler slowness and even
they add new features to the compiler itself.
Thank you all for writing GCC!
Karel
--
Karel Gardas [EMAIL PROTECTED]
ObjectSecurity Ltd. http://www.objectsecurity.com
as "generated using 'SLOCCount' by David A. Wheeler."
Cheers,
Karel
--
Karel Gardas [EMAIL PROTECTED]
ObjectSecurity Ltd. http://www.objectsecurity.com
On Tue, 12 Apr 2005, Mike Stump wrote:
> On Tuesday, April 12, 2005, at 06:38 AM, Karel Gardas wrote:
> > Especially: ``Currently gcc takes a cache miss every 20 instructions,
> > or
> > some ungodly number, and that really saps performance.''
> >
> &
On Tue, 12 Apr 2005, Karel Gardas wrote:
> using cache and how much cache it needs (I'm cosidering 512KB cache CPU
> here either Winchester or Venice core) and that's the reason why I ask
> here, since I've not been able so far to search by google for sufficient
> answ
far to search by google for sufficient
answer for this question.
Thanks for any idea and sorry for off-topic!
Karel
--
Karel Gardas [EMAIL PROTECTED]
ObjectSecurity Ltd. http://www.objectsecurity.com
On Fri, 4 Mar 2005, Jonathan Wakely wrote:
> On Fri, Mar 04, 2005 at 03:51:42PM +0100, Karel Gardas wrote:
>
> > I would like to ask if the behaviour of GCC 4.0.0 20050301 is correct or
> > not. I have for example abstract base class like:
> >
> > class Foo
>
abstract and will never be instantiated. It's quite easy to add
virtual dtor there, but I'm reluctant to do so, since IMHO GCC should
check if the class is abstract or not, so I would like to ask if I should
fill a bugreport or correct my code.
Thanks,
Karel
--
Karel Gardas
files: uni_base64.cc (~7%)
Overall, 4.0 is now faster about 37% for -O0, 16% for -O1 and 15% for -O2
than 3.4.2 which is really great progress! Thank you all who are working
on making GCC more usable!
Karel
--
Karel Gardas [EMAIL PROTECTED]
ObjectSecurity Ltd. http
On Fri, 11 Feb 2005, Karel Gardas wrote:
> On Fri, 11 Feb 2005, Jan Reimers wrote:
>
> > Can someone verify that this is valid C++ before I submit a bug report:
> >
> > // test.C
> > template class A {static T* c;};
> >
> > class B : public A {};
>
0 compile it and to me it also
looks ok, but I'm not at all C++ language lawer!
Cheers,
Karel
--
Karel Gardas [EMAIL PROTECTED]
ObjectSecurity Ltd. http://www.objectsecurity.com
54 matches
Mail list logo
