Nabble - gcc - Help

Re: Efficient detection of signed overflow?

2009-11-30T05:54:20Z

2009/11/30 Florian Weimer <fw@...>:
>
>> On Sun, Nov 29, 2009 at 9:00 PM, me22 <me22.ca@...> wrote:
>>> What about using (long)((unsigned long)a + (unsigned long)b) or
>>> something to get around the UB?
>
> You'd also have to compare against (1 << (sizeof(long) * CHAR_BITS -
> 1)) instead of 0, pessimizing the code somewhat.
>

Why? If numbers are 2s-complement, the cast back to a signed type is
well-defined, isn't it?

Re: Using core\cores specification

2009-11-30T03:09:39Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

En/na Nicolas BENOIT ha escrit:

> alanklm wrote:
>>
>>
>> Harald Servat-3 wrote:
> En/na alanklm ha escrit:
>>>>> Do somebody know if there is some possibility in gcc to set on which
>>>>> fixed
>>>>> cores of multi-core processor I want to execute my program?
> I'm afraid that this feature depends on the OS not on gcc itself.
>
> For example, FreeBSD has the cpuset command and calls.
> http://www.freebsd.org/cgi/man.cgi?query=cpuset&sektion=2&apropos=0&manpath=FreeBSD+8.0-RELEASE
>
> http://www.freebsd.org/cgi/man.cgi?query=cpuset&sektion=1&apropos=0&manpath=FreeBSD+8.0-RELEASE
>
>
> Other OSes may have other commands/calls.
>
> Regards.
>>>
>>>
>> Thanks a lot. May be you know same command for Debian. (4.0 or 5.0)

> On Linux, this functionnality is notably described in the manpages of
> sched_setaffinity

> Regards,
> N. BENOIT

Also, taskset (1) may help you.

Regards.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAksTp/MACgkQwMPeuqUCg9ws9wCdFrUkptYaBwvZd58+F8oz8+gm
o/cAn1lKhlvRM17zyamzMa29vgP8Q6SZ
=LNaq
-----END PGP SIGNATURE-----

Re: Using core\cores specification

2009-11-30T03:07:07Z

alanklm wrote:

>
>
> Harald Servat-3 wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> En/na alanklm ha escrit:
>>> Do somebody know if there is some possibility in gcc to set on which
>>> fixed
>>> cores of multi-core processor I want to execute my program?
>> I'm afraid that this feature depends on the OS not on gcc itself.
>>
>> For example, FreeBSD has the cpuset command and calls.
>> http://www.freebsd.org/cgi/man.cgi?query=cpuset&sektion=2&apropos=0&manpath=FreeBSD+8.0-RELEASE
>> http://www.freebsd.org/cgi/man.cgi?query=cpuset&sektion=1&apropos=0&manpath=FreeBSD+8.0-RELEASE
>>
>> Other OSes may have other commands/calls.
>>
>> Regards.
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v2.0.9 (GNU/Linux)
>>
>> iEYEARECAAYFAksTlmIACgkQwMPeuqUCg9y66gCeOznWYFnyOxP+ld8mss3iWGYc
>> TUUAmgOnOUv9v/rPpmX8TQnw2gPQ1iRn
>> =yv5u
>> -----END PGP SIGNATURE-----
>>
>>
> Thanks a lot.
> May be you know same command for Debian. (4.0 or 5.0)

On Linux, this functionnality is notably described in the manpages of
sched_setaffinity

Regards,
N. BENOIT

Re: Using core\cores specification

2009-11-30T02:32:30Z

Harald Servat-3 wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

En/na alanklm ha escrit:
> Do somebody know if there is some possibility in gcc to set on which fixed
> cores of multi-core processor I want to execute my program?

I'm afraid that this feature depends on the OS not on gcc itself.

For example, FreeBSD has the cpuset command and calls.
http://www.freebsd.org/cgi/man.cgi?query=cpuset&sektion=2&apropos=0&manpath=FreeBSD+8.0-RELEASE
http://www.freebsd.org/cgi/man.cgi?query=cpuset&sektion=1&apropos=0&manpath=FreeBSD+8.0-RELEASE

Other OSes may have other commands/calls.

Regards.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAksTlmIACgkQwMPeuqUCg9y66gCeOznWYFnyOxP+ld8mss3iWGYc
TUUAmgOnOUv9v/rPpmX8TQnw2gPQ1iRn
=yv5u
-----END PGP SIGNATURE-----

Thanks a lot.
May be you know same command for Debian. (4.0 or 5.0)

Re: Using core\cores specification

2009-11-30T01:54:42Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

En/na alanklm ha escrit:
> Do somebody know if there is some possibility in gcc to set on which fixed
> cores of multi-core processor I want to execute my program?

I'm afraid that this feature depends on the OS not on gcc itself.

For example, FreeBSD has the cpuset command and calls.
http://www.freebsd.org/cgi/man.cgi?query=cpuset&sektion=2&apropos=0&manpath=FreeBSD+8.0-RELEASE
http://www.freebsd.org/cgi/man.cgi?query=cpuset&sektion=1&apropos=0&manpath=FreeBSD+8.0-RELEASE

Other OSes may have other commands/calls.

Regards.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAksTlmIACgkQwMPeuqUCg9y66gCeOznWYFnyOxP+ld8mss3iWGYc
TUUAmgOnOUv9v/rPpmX8TQnw2gPQ1iRn
=yv5u
-----END PGP SIGNATURE-----

Using core\cores specification

2009-11-30T01:18:57Z

Do somebody know if there is some possibility in gcc to set on which fixed cores of multi-core processor I want to execute my program?

Re: Efficient detection of signed overflow?

2009-11-29T22:36:53Z

* Mark Dickinson:

>>> Any suggestions for improvements over this?
>>
>> Use -fwrapv and your first version.
>
> gcc isn't the only compiler that's going to have to compile
> this code, so it still needs to be fixed to avoid undefined
> behaviour

Most compiler support something like -fwrapv.

> On Sun, Nov 29, 2009 at 9:00 PM, me22 <me22.ca@...> wrote:
>> What about using (long)((unsigned long)a + (unsigned long)b) or
>> something to get around the UB?
>
> Yep, that looks like the solution. Thanks!

You'd also have to compare against (1 << (sizeof(long) * CHAR_BITS -
1)) instead of 0, pessimizing the code somewhat.

Re: Efficient detection of signed overflow?

2009-11-29T14:00:30Z

On Sun, Nov 29, 2009 at 8:53 PM, Florian Weimer <fw@...> wrote:
> * Mark Dickinson:
> [...]
>> if ((x^a) < 0 && (x^b) < 0)
>
> Would this test be better? I think it's equivalent, and it saves a
> comparison.
>
> if (((x ^ a) & (x ^ b)) < 0)

Mmm. Quite possibly, yes. I'll do some timings.

>> Any suggestions for improvements over this?
>
> Use -fwrapv and your first version.

gcc isn't the only compiler that's going to have to compile
this code, so it still needs to be fixed to avoid undefined
behaviour (and I'm worried about -fwrapv inhibiting optimizations
elsewhere in the codebase). But I guess that casting everything in
sight to unsigned long and then casting the eventual result
back to long, as me22 suggests, would be pretty much equivalent.

On Sun, Nov 29, 2009 at 9:00 PM, me22 <me22.ca@...> wrote:
> What about using (long)((unsigned long)a + (unsigned long)b) or
> something to get around the UB?

Yep, that looks like the solution. Thanks!

Mark

Re: Efficient detection of signed overflow?

2009-11-29T13:00:57Z

2009/11/29 Mark Dickinson <dickinsm@...>:
>
> This code is wrong, I think, because it depends on undefined
> behaviour. I'm wondering how best to rewrite it so that (a)
> the replacement code is correct and portable C89, and (b)
> there's a reasonable chance of gcc compiling it to efficient
> assembler on common platforms.
>

What about using (long)((unsigned long)a + (unsigned long)b) or
something to get around the UB?

Re: Efficient detection of signed overflow?

2009-11-29T12:53:49Z

* Mark Dickinson:

> long a, b, x;
> ...
> x = a + b;
> if ((x^a) < 0 && (x^b) < 0)
> goto deal_with_overflow;
> ...

Would this test be better? I think it's equivalent, and it saves a
comparison.

if (((x ^ a) & (x ^ b)) < 0)

> Any suggestions for improvements over this?

Use -fwrapv and your first version.

> Are there any common C code constructs that gcc would compile to a
> jump-on-overflow instruction on x86?

I don't think so. Without support throughout GCC, anything in this
area (like a builtin) would mostly act as an optimization barrier.

Efficient detection of signed overflow?

2009-11-29T11:51:48Z

I've just found myself looking at a piece of C code like the
snippet given below. It's supposed to be adding two longs
and doing something special when the sum overflows.
Here a and b could have any value, but are likely to be small
in the common case. The snippet occurs in a fairly performance-
critical section of code.

long a, b, x;
...
x = a + b;
if ((x^a) < 0 && (x^b) < 0)
goto deal_with_overflow;
...

This code is wrong, I think, because it depends on undefined
behaviour. I'm wondering how best to rewrite it so that (a)
the replacement code is correct and portable C89, and (b)
there's a reasonable chance of gcc compiling it to efficient
assembler on common platforms.

A bullet-proof solution (valid even in the presence of ones'
complement machines, trap representations, etc.) is
something like:

if ((a >= 0 && 0UL + a > (unsigned long)LONG_MAX - b) ||
(a < 0 && 0UL - a > b - (unsigned long)LONG_MIN))
goto deal_with_overflow;
x = a + b;

but, not surprisingly, this generates rather inefficient assembler
(with gcc-4.4 -O3).

Any suggestions for improvements over this?

On x86 or x86-64, the optimal generated code would
presumably consist of just two instructions: an addition
followed by a jump-on-overflow. Unfortunately, using
inline assembly isn't really an option here. Are there
any common C code constructs that gcc would compile
to a jump-on-overflow instruction on x86?

Mark

Re: cache optimization

2009-11-28T12:51:39Z

£ukasz wrote:

>
> --- On Thu, 11/26/09, Tim Prince <n8tm@...> wrote:
>
>> From: Tim Prince <n8tm@...>
>> Subject: Re: cache optimization
>> To: "£ukasz" <blurrpp@...>
>> Cc: gcc-help@...
>> Date: Thursday, November 26, 2009, 4:38 PM
>> £ukasz wrote:
>>> Hi I want to learn how to optimaze cache usage in gcc.
>> I find builtin function __builtin_prefetch which should
>> prefetch datas to cache .. so i use cannonical :) example of
>> vector addition.
>>> for (i = 0; i < n; i++)
>>> {
>>> a[i] = a[i] + b[i];
>>> __builtin_prefetch
>> (&a[i+1], 1, 1);
>>> __builtin_prefetch
>> (&b[i+1], 0, 1);
>>> /* ... */
>>> }
>>>
>>> and compile it with gcc without special options ....
>> but its slower than
>>> for (i = 0; i < n; i++)
>>> {
>>> a[i] = a[i] + b[i];
>>> /* ... */
>>> }
>>>
>>> so maybe I should compile it with soem extra options
>> to have advantage of cache prefatching
>> ?(-fprefetch-loop-array doenst works )
>>>
>>>
>> Under normal settings, on CPUs of the last 6 years or so,
>> you are prefetching what has already been prefetched by
>> hardware prefetcher. If your search engine doesn't
>> find you many success stories about the use of this feature,
>> that might be a clue that it involves some serious
>> investigation. You would look for slow spots in your code
>> which don't fall in the usual hardware supported prefetch
>> patterns (linear access with not too large a stride, or
>> pairs of cache lines), and experiment with fetching the data
>> sufficiently far in advance for it to do some good, without
>> exceeding your cache capacity.
>> I do see a "success story" about prefetching for a reversed
>> loop. As the author doesn't divulge the CPU in use, one
>> suspects it might be something like the old Athlon32 which
>> supported hardware prefetch only in the forward direction.
>> Don't you like advice which assumes no one will ever use a
>> CPU different (e.g. more up to date) than the author's
>> favorite?
>>
>
> You are completely right, in this example gcc compiler change code to branch assembly, which ofcourse is already "predicted" ( means forward NOT TAKEN, backward TAKEN), but im looking for some nice example for modern procesors which would realy works I mean speed program(im searching net actualy ). In Intel Optimization Reference Manual they advice to use PREFETCH to any predicable memory access patern, but as you already mensioned some patern processor can predict by him self.
>
>

Prefetch intrinsics might be effective in a case such as

for(i=0; i<n; ++i)
a[indx[i]] += b[indx[i]];

but, as another responder said, you must recognize that you will be
fetching whole cache lines, or pairs of cache lines, and may need half a
dozen in advance. If you are running on an Atom (non-out-of-order), you
might expect entirely different results, and different optimum strategy,
from a CPU with a large out-of-order queue.

Re: cache optimization

2009-11-28T10:33:26Z

"(remember, adding instructions make your code slower)"

I would agree with you totaly two years ago, before i started writing GPU programs. There, programs which copy special part of data to SHARE memory, and has about 20% more instructions because of it, works 10 times faster than those without. Thanks for answer and if you have some nice example of speeding up CPU programs with using prefatching, or some good literature please give link :).

CentCollector :)

--- On Thu, 11/26/09, Harald Servat <harald.servat@...> wrote:

> From: Harald Servat <harald.servat@...>
> Subject: Re: cache optimization
> To: "£ukasz" <blurrpp@...>
> Cc: gcc-help@...
> Date: Thursday, November 26, 2009, 4:38 PM
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> Although there are other factors that may apply, you must
> consider that
> prefeteching the next element may be not enough for
> current
> microprocessors. First, I'm pretty sure that the processor
> would have
> the entire cache line once you bring some data. And second,
> nowadays,
> micoprocessors have hardware prefetching that do the same
> work for you
> without the need of adding extra instructions (remember,
> adding
> instructions make your code slower). Also consider that
> the
> microprocessor has other out-of-order special circuitry
> that may allow
> it to be working on "future" iterations while waiting on a
> cache miss.
>
> So I think that you may prefetch data which is farther.
> With current gap
> between micro and memory speeds, I wouldn't be too
> impressed if you had
> to go at 7 or 8 cache lines away.
>
> Just my .02 euro cents :)
>
> En/na £ukasz ha escrit:
> > Hi I want to learn how to optimaze cache usage in gcc.
> I find builtin function __builtin_prefetch which should
> prefetch datas to cache .. so i use cannonical :) example of
> vector addition.
> >
> > for (i = 0; i < n; i++)
> >   {
> >    a[i] = a[i] + b[i];
> >    __builtin_prefetch
> (&a[i+1], 1, 1);
> >    __builtin_prefetch
> (&b[i+1], 0, 1);
> >    /* ... */
> >   }
> >
> > and compile it with gcc without special options ....
> but its slower than
> >
> > for (i = 0; i < n; i++)
> >   {
> >    a[i] = a[i] + b[i];
> >    /* ... */
> >   }
> >
> > so maybe I should compile it with soem extra options
> to have advantage of cache prefatching
> ?(-fprefetch-loop-array doenst works )
> >
> >
> >
> >
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.9 (GNU/Linux)
>
> iEYEARECAAYFAksOoOsACgkQwMPeuqUCg9yj9wCbBd7DxNBKk9uNzV5xz4r66He4
> r9gAnRncLhV0SYr6MgoUz7qG+hSL8S9b
> =t8mz
> -----END PGP SIGNATURE-----
>

Re: cache optimization

2009-11-28T10:18:52Z

--- On Thu, 11/26/09, Tim Prince <n8tm@...> wrote:

> From: Tim Prince <n8tm@...>
> Subject: Re: cache optimization
> To: "£ukasz" <blurrpp@...>
> Cc: gcc-help@...
> Date: Thursday, November 26, 2009, 4:38 PM
> £ukasz wrote:
> > Hi I want to learn how to optimaze cache usage in gcc.
> I find builtin function __builtin_prefetch which should
> prefetch datas to cache .. so i use cannonical :) example of
> vector addition.
> >
> > for (i = 0; i < n; i++)
> >   {
> >    a[i] = a[i] + b[i];
> >    __builtin_prefetch
> (&a[i+1], 1, 1);
> >    __builtin_prefetch
> (&b[i+1], 0, 1);
> >    /* ... */
> >   }
> >
> > and compile it with gcc without special options ....
> but its slower than
> >
> > for (i = 0; i < n; i++)
> >   {
> >    a[i] = a[i] + b[i];
> >    /* ... */
> >   }
> >
> > so maybe I should compile it with soem extra options
> to have advantage of cache prefatching
> ?(-fprefetch-loop-array doenst works )
> >
> >
> >
> Under normal settings, on CPUs of the last 6 years or so,
> you are prefetching what has already been prefetched by
> hardware prefetcher. If your search engine doesn't
> find you many success stories about the use of this feature,
> that might be a clue that it involves some serious
> investigation. You would look for slow spots in your code
> which don't fall in the usual hardware supported prefetch
> patterns (linear access with not too large a stride, or
> pairs of cache lines), and experiment with fetching the data
> sufficiently far in advance for it to do some good, without
> exceeding your cache capacity.
> I do see a "success story" about prefetching for a reversed
> loop. As the author doesn't divulge the CPU in use, one
> suspects it might be something like the old Athlon32 which
> supported hardware prefetch only in the forward direction.
> Don't you like advice which assumes no one will ever use a
> CPU different (e.g. more up to date) than the author's
> favorite?
>

You are completely right, in this example gcc compiler change code to branch assembly, which ofcourse is already "predicted" ( means forward NOT TAKEN, backward TAKEN), but im looking for some nice example for modern procesors which would realy works I mean speed program(im searching net actualy ). In Intel Optimization Reference Manual they advice to use PREFETCH to any predicable memory access patern, but as you already mensioned some patern processor can predict by him self.

Re: GDB in Lenny

2009-11-28T09:23:27Z

I Rattan wrote:

On Fri, 27 Nov 2009, Sanyi wrote:

>
> Hi .
>
> I'm trying to debug my example program with GDB. My question is why GDB do
> not show the simbolic information. (e.g Line number and vars)

Did you compile with -g flag?
-ishwar

Yes I did. Finaly I found the problem. I found the solution described here
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=227097

I have installed the libc6-dbg_2.3.2.ds1-12_i386.deb package from the ftp repo and now it's working

I don't know why in the package list is not mentioned
http://packages.debian.org/lenny/gdb

Now after i ran GDB . It looks like this
server:/home/sanyi/ALP/ch01# gdb reciprocal
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...
(gdb) run
Starting program: /home/sanyi/ALP/ch01/reciprocal

Program received signal SIGSEGV, Segmentation fault.
0xb7591358 in ____strtol_l_internal () from /lib/i686/cmov/libc.so.6
(gdb) where
#0 0xb7591358 in ____strtol_l_internal () from /lib/i686/cmov/libc.so.6
#1 0xb75910c0 in strtol () from /lib/i686/cmov/libc.so.6
#2 0xb758de21 in atoi () from /lib/i686/cmov/libc.so.6
#3 0x08048485 in main (argc=1, argv=0xbfde47b4) at main.c:6
(gdb)

Re: GDB in Lenny

2009-11-27T17:41:32Z

On Fri, 27 Nov 2009, Sanyi wrote:

>
> Hi .
>
> I'm trying to debug my example program with GDB. My question is why GDB do
> not show the simbolic information. (e.g Line number and vars)

Did you compile with -g flag?
-ishwar

GDB in Lenny

2009-11-27T14:43:04Z

Hi .

I'm trying to debug my example program with GDB. My question is why GDB do not show the simbolic information. (e.g Line number and vars)

server:/home/sanyi/ALP/ch01# gdb reciprocal
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...
(gdb) run
Starting program: /home/sanyi/ALP/ch01/reciprocal

Program received signal SIGSEGV, Segmentation fault.
0xb7510358 in ?? () from /lib/i686/cmov/libc.so.6
(gdb) where
#0 0xb7510358 in ?? () from /lib/i686/cmov/libc.so.6
#1 0xb77807c4 in ?? ()
#2 0x00000000 in ?? ()
(gdb)

The source programs are :

main.c

#include <stdio.h>
#include <stdlib.h>
#include "reciprocal.hpp"
int main (int argc, char **argv){
int i;
i = atoi (argv[1]);
printf ("The reciprocal of %d is %g\n",i,reciprocal (i));
return 0;
}

reciprocal.cpp:

#include <cassert>
#include "reciprocal.hpp"

double reciprocal (int i) {
assert (i != 0);
return 1.0/i;
}

The Makefile:

reciprocal: main.o reciprocal.o
g++ $(CFLAGS) -o reciprocal main.o reciprocal.o
main.o: main.c reciprocal.hpp
gcc $(CFLAGS) -c main.c
reciprocal.o: reciprocal.cpp reciprocal.hpp
g++ $(CFLAGS) -c reciprocal.cpp
clean:
rm -f *.o reciprocal

I build the programm with make CFLAGS=-g

server:/home/sanyi/ALP/ch01# make CFLAGS=-g
gcc -g -c main.c
g++ -g -c reciprocal.cpp
g++ -g -o reciprocal main.o reciprocal.o

gcc version:

server:/home/sanyi/ALP/ch01# gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-targets=all --enable-cld --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.3.2 (Debian 4.3.2-1.1)

Thank You

Re: Missing warning about uninitialized variable

2009-11-27T06:29:34Z

David Sveningsson <ext@...> writes:

> Hi, I recently ran into an issue with an uninitialized pointer which I
> expected g++ to warn about.
>
> class Foo {
> public:
> Foo* a(){ return this; }
> };
>
> int main(int argc, const char*[] ){
> for ( int i = 0; i < 6; i++ ){
> Foo* foo = foo->a();
> }
> }
>
> This code compiles without any warnings (with -Wall) with both
> g++-4.4.2 and g++-4.2.4. Removing the for-loop gives me a warning as
> expected:
>
> foo.cpp: In function ‘int main(int, const char**)’:
> foo.cpp:8: warning: ‘foo’ is used uninitialized in this function
>
> I know this case is a bit silly but it happened because of a typo and
> went unnoticed for a while.
>
> Is my reasoning flawed or should g++ emit a warning?

You may get a warning with -Winit-self.

However, this sounds like a bug either way. Please consider filing a
bug report as described at http://gcc.gnu.org/bugs/ .

Ian

Re: multiple definition error when compiling gcc-4.4.2

2009-11-27T06:25:50Z

xinsan Chen <xinsan.chen@...> writes:

> checking for x86_64-unknown-linux-gnu-gcc... /home/cj/gcc-
>
> 442/./gcc/xgcc -B/home/cj/gcc-442/./gcc/ -B/home/cj/gcc-442/x86_64-
>
> unknown-linux-gnu/bin/ -B/home/cj/gcc-442/x86_64-unknown-linux-gnu/lib/
>
> -isystem /home/cj/gcc-442/x86_64-unknown-linux-gnu/include -isystem
>
> /home/cj/gcc-442/x86_64-unknown-linux-gnu/sys-include
> checking for suffix of object files... configure: error: in
>
> `/home/cj/gcc-442/x86_64-unknown-linux-gnu/libgcc':
> configure: error: cannot compute suffix of object files: cannot compile
> See `config.log' for more details.
> make[2]: *** [configure-stage1-target-libgcc] Error 1

You need to look at x86_64-unknown-linux-gnu/libgcc/config.log. You
did send a config.log file, but it was the wrong one.

Ian

mulhisi3

2009-11-27T03:12:36Z

Hi , i am an novice here.

What test case should i write so that gcc produce "mulhisi3" pattern. mulsi3 , mulhi3 are working fine. I also have defined extendhisi2.

thanks

Re: libstdc++.so without version information

2009-11-26T22:54:46Z

Philipp Thomas wrote:

> On Wed, 25 Nov 2009 11:40:25 +0100, Christian Schaubschlaeger wrote:
>
>
>> root:# objdump -p libstdc++.so.6.0.8
>>
>> libstdc++.so.6.0.8: file format elf32-i386
>>
>> ldconfig did find the library, but could not extract the version info
>> (regarding CXXABI and GLIBCXX), since it's obviously not there. And
>> I don't know why.
>>
>
> If there is no version info, you'll have to examine the build log of
> your gcc (or start a new build and log that) and search for the
> line(s) where libstdc+ is itself linked. I haven't looked at gcc
> makefiles for a long time but ld should be passed a version script
> that contains the versioning info ld will then put into the library.
>

Examining the 'libstdc++-v3/config.log' alone would tell the possible
reason. My (re)build of
cross-gcc-4.1.2 for SuSE 10.3 (no version info there earlier) told in
the $target/libstdc++-v3/config.log :

configure:87446: WARNING: === Linker version 1750 is too old for
configure:87448: WARNING: === full symbol versioning support in this
release of GCC.
configure:87450: WARNING: === You would need to upgrade your binutils to
version
configure:87452: WARNING: === 21400 or later and rebuild GCC.
configure:87454: WARNING: === Symbol versioning will be disabled.

The case really was that the earlier buggy gcc-4.1.2 toolchain had
the :

[root@Dell i686-suse-linux10.3]# bin/ld -V
GNU ld (Linux/GNU Binutils) 2.17.50.0.16.20070511
Supported emulations:
elf_i386
i386linux

Earlier there were no dot but a space between the version string and the
date string. Downgrading
the target binutils to 2.15.94 was my first workaround and with them the
version info was added.
Also the more uptodate binutils like 2.19.51 have this dot there so
either it should be fixed away
in the binutils sources or the gcc-4.1.2/libstdc++-v3/configure* stuff
be fixed to accept the dot
and interpret the binutils version right... The newer GCCs seem to
interpret this ok so looking at
the diffs could tell the patch....

Re: Can I find what #defines's the pre-processor makes?

2009-11-26T17:44:46Z

On Thu, 26 Nov 2009 17:19:47 +0000, you wrote:

>I know if I use gcc, it will define __GNUC__, and no doubt many other things
>too. Does anyone know how to get a list of them all? Is there a command I can
>execute which will list them?

I use 'gcc -dM -E -xc /dev/null' to get all predefines.

Philipp

Re: libstdc++.so without version information

2009-11-26T17:41:43Z

On Wed, 25 Nov 2009 11:40:25 +0100, you wrote:

>root:# objdump -p libstdc++.so.6.0.8
>
>libstdc++.so.6.0.8: file format elf32-i386
>
>ldconfig did find the library, but could not extract the version info
>(regarding CXXABI and GLIBCXX), since it's obviously not there. And
>I don't know why.

If there is no version info, you'll have to examine the build log of
your gcc (or start a new build and log that) and search for the
line(s) where libstdc+ is itself linked. I haven't looked at gcc
makefiles for a long time but ld should be passed a version script
that contains the versioning info ld will then put into the library.

Philipp

Re: Can I find what #defines's the pre-processor makes?

2009-11-26T13:02:41Z

Andrew Haley wrote:
> gcc -save-temps -Wp,-dD
>
> Look in the .i file
>
On unix like machines,

echo | cpp -dD

generates the list on stdout (i.e. to your console, or xterm or
whatever) without having to have any files involved.

Patrick

Re: Can I find what #defines's the pre-processor makes?

2009-11-26T09:24:08Z

Dr. David Kirkby wrote:
> I know if I use gcc, it will define __GNUC__, and no doubt many other things
> too. Does anyone know how to get a list of them all? Is there a command I can
> execute which will list them?
>
> I'd rather a command, than a pointer to documentation, as I want to do this on a
> gcc-like complier from Sun, which has a gcc-front end, but uses Sun's superior
> back end, to generate faster code. I want to know what that defines, but since
> it acts like gcc, anything that works on gcc should work on that too.

gcc -save-temps -Wp,-dD

Look in the .i file

Can I find what #defines's the pre-processor makes?

2009-11-26T09:19:47Z

I know if I use gcc, it will define __GNUC__, and no doubt many other things
too. Does anyone know how to get a list of them all? Is there a command I can
execute which will list them?

I'd rather a command, than a pointer to documentation, as I want to do this on a
gcc-like complier from Sun, which has a gcc-front end, but uses Sun's superior
back end, to generate faster code. I want to know what that defines, but since
it acts like gcc, anything that works on gcc should work on that too.

Dave

Re: cache optimization

2009-11-26T07:38:19Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Although there are other factors that may apply, you must consider that
prefeteching the next element may be not enough for current
microprocessors. First, I'm pretty sure that the processor would have
the entire cache line once you bring some data. And second, nowadays,
micoprocessors have hardware prefetching that do the same work for you
without the need of adding extra instructions (remember, adding
instructions make your code slower). Also consider that the
microprocessor has other out-of-order special circuitry that may allow
it to be working on "future" iterations while waiting on a cache miss.

So I think that you may prefetch data which is farther. With current gap
between micro and memory speeds, I wouldn't be too impressed if you had
to go at 7 or 8 cache lines away.

Just my .02 euro cents :)

En/na £ukasz ha escrit:

> Hi I want to learn how to optimaze cache usage in gcc. I find builtin function __builtin_prefetch which should prefetch datas to cache .. so i use cannonical :) example of vector addition.
>
> for (i = 0; i < n; i++)
> {
> a[i] = a[i] + b[i];
> __builtin_prefetch (&a[i+1], 1, 1);
> __builtin_prefetch (&b[i+1], 0, 1);
> /* ... */
> }
>
> and compile it with gcc without special options .... but its slower than
>
> for (i = 0; i < n; i++)
> {
> a[i] = a[i] + b[i];
> /* ... */
> }
>
> so maybe I should compile it with soem extra options to have advantage of cache prefatching ?(-fprefetch-loop-array doenst works )
>
>
>
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAksOoOsACgkQwMPeuqUCg9yj9wCbBd7DxNBKk9uNzV5xz4r66He4
r9gAnRncLhV0SYr6MgoUz7qG+hSL8S9b
=t8mz
-----END PGP SIGNATURE-----

Re: cache optimization

2009-11-26T07:38:02Z

£ukasz wrote:

Under normal settings, on CPUs of the last 6 years or so, you are
prefetching what has already been prefetched by hardware prefetcher. If
your search engine doesn't find you many success stories about the use
of this feature, that might be a clue that it involves some serious
investigation. You would look for slow spots in your code which don't
fall in the usual hardware supported prefetch patterns (linear access
with not too large a stride, or pairs of cache lines), and experiment
with fetching the data sufficiently far in advance for it to do some
good, without exceeding your cache capacity.
I do see a "success story" about prefetching for a reversed loop. As the
author doesn't divulge the CPU in use, one suspects it might be
something like the old Athlon32 which supported hardware prefetch only
in the forward direction. Don't you like advice which assumes no one
will ever use a CPU different (e.g. more up to date) than the author's
favorite?

cache optimization

2009-11-26T05:14:10Z

Hi I want to learn how to optimaze cache usage in gcc. I find builtin function __builtin_prefetch which should prefetch datas to cache .. so i use cannonical :) example of vector addition.

for (i = 0; i < n; i++)
{
a[i] = a[i] + b[i];
__builtin_prefetch (&a[i+1], 1, 1);
__builtin_prefetch (&b[i+1], 0, 1);
/* ... */
}

and compile it with gcc without special options .... but its slower than

for (i = 0; i < n; i++)
{
a[i] = a[i] + b[i];
/* ... */
}

so maybe I should compile it with soem extra options to have advantage of cache prefatching ?(-fprefetch-loop-array doenst works )

Compiled with gcc -pg, but no gmon.out produced

2009-11-25T20:41:18Z

Hi,

I'm having some trouble trying to profile my code. I'm just testing it
out with a simple hello world program:

$ cat bar.c
#include <stdio.h>
int main(void)
{
printf("Hello, world!\n");
return 0;
}

However, when I compile and run it, no gmon.out is produced (as
required by gprof):

$ gcc -o bar bar.c -pg && ./bar && ls ./gmon.out
Hello, world!
ls: ./gmon.out: No such file or directory

Is there anything obvious that I'm screwing up here? I'm running this
on OS X 10.5.

Thanks.

Re: libstdc++.so without version information

2009-11-25T02:40:25Z

Philipp Thomas schrieb:

> On Tue, 24 Nov 2009 16:02:29 +0100, you wrote:
>
>> libdl.so.2 (GLIBC_2.0) => /lib/libdl.so.2
>> libstdc++.so.6 (CXXABI_1.3) => not found
>> libstdc++.so.6 (GLIBCXX_3.4) => not found
>> [snip]
>> It seems that the libstdc++ does not contain the needed information:
>>
>
> You can't check with strings. The right way to check the version
> information is by using 'objdump -p' on the library. When doing so,
> you'll see something like
>
> Version definitions:
> 1 0x01 0x025f4d66 libstdc++.so.6
> 2 0x00 0x08922974 GLIBCXX_3.4
> 3 0x00 0x02297f81 GLIBCXX_3.4.1
> GLIBCXX_3.4
> 4 0x00 0x02297f82 GLIBCXX_3.4.2
> GLIBCXX_3.4.1
> 5 0x00 0x02297f83 GLIBCXX_3.4.3
> GLIBCXX_3.4.2

Thanks for your tips!
With objdump I get:

root:# objdump -p libstdc++.so.6.0.8

libstdc++.so.6.0.8: file format elf32-i386

Program Header:
LOAD off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**12
filesz 0x000e1ee0 memsz 0x000e1ee0 flags r-x
LOAD off 0x000e28d8 vaddr 0x000e28d8 paddr 0x000e28d8 align 2**12
filesz 0x00004190 memsz 0x00009e8c flags rw-
DYNAMIC off 0x000e597c vaddr 0x000e597c paddr 0x000e597c align 2**2
filesz 0x000000e0 memsz 0x000000e0 flags rw-
TLS off 0x000e28d8 vaddr 0x000e28d8 paddr 0x000e28d8 align 2**2
filesz 0x00000000 memsz 0x00000008 flags r--
EH_FRAME off 0x000c4cb0 vaddr 0x000c4cb0 paddr 0x000c4cb0 align 2**2
filesz 0x0000456c memsz 0x0000456c flags r--
STACK off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**2
filesz 0x00000000 memsz 0x00000000 flags rw-
RELRO off 0x000e28d8 vaddr 0x000e28d8 paddr 0x000e28d8 align 2**0
filesz 0x000030a4 memsz 0x0000308c flags r--

Dynamic Section:
NEEDED libm.so.6
NEEDED libgcc_s.so.1
NEEDED libc.so.6
NEEDED ld-linux.so.2
SONAME libstdc++.so.6
INIT 0x446c0
FINI 0xc0954
HASH 0x114
STRTAB 0x135ac
SYMTAB 0x4b8c
STRSZ 0x295d0
SYMENT 0x10
PLTGOT 0xe5ff4
PLTRELSZ 0x11a8
PLTREL 0x11
JMPREL 0x43518
REL 0x3e980
RELSZ 0x4b98
RELENT 0x8
VERNEED 0x3e8c0
VERNEEDNUM 0x3
VERSYM 0x3cb7c
RELCOUNT 0x108

Version References:
required from ld-linux.so.2:
0x0d696913 0x00 09 GLIBC_2.3
required from libgcc_s.so.1:
0x0d696910 0x00 10 GLIBC_2.0
0x0b792653 0x00 08 GCC_3.3
0x0b792650 0x00 05 GCC_3.0
required from libc.so.6:
0x0d696911 0x00 07 GLIBC_2.1
0x0d696913 0x00 06 GLIBC_2.3
0x09691f73 0x00 04 GLIBC_2.1.3
0x0d696910 0x00 03 GLIBC_2.0
0x0d696912 0x00 02 GLIBC_2.2

i.e. no CXXABI, no GLIBCXX!

> Looks likeWhat ldconfig is telling you is that it doesn't find the
> library. Try calling ldconfig to get the dynamic linker to cache the
> library and then again ldd.

ldconfig did find the library, but could not extract the version info
(regarding CXXABI and GLIBCXX), since it's obviously not there. And
I don't know why.

Thanks
Christian

Re: libstdc++.so without version information

2009-11-25T02:13:27Z

On Tue, 24 Nov 2009 16:02:29 +0100, you wrote:

> libdl.so.2 (GLIBC_2.0) => /lib/libdl.so.2
> libstdc++.so.6 (CXXABI_1.3) => not found
> libstdc++.so.6 (GLIBCXX_3.4) => not found
>[snip]
>
>It seems that the libstdc++ does not contain the needed information:
>

You can't check with strings. The right way to check the version
information is by using 'objdump -p' on the library. When doing so,
you'll see something like

Version definitions:
1 0x01 0x025f4d66 libstdc++.so.6
2 0x00 0x08922974 GLIBCXX_3.4
3 0x00 0x02297f81 GLIBCXX_3.4.1
GLIBCXX_3.4
4 0x00 0x02297f82 GLIBCXX_3.4.2
GLIBCXX_3.4.1
5 0x00 0x02297f83 GLIBCXX_3.4.3
GLIBCXX_3.4.2

Looks likeWhat ldconfig is telling you is that it doesn't find the
library. Try calling ldconfig to get the dynamic linker to cache the
library and then again ldd.

>How can I build libstdc++ so that it contains version information?

I'm certain that is does contain the info when looking with the right
tool :)

Philipp

Missing warning about uninitialized variable

2009-11-25T02:09:04Z

Hi, I recently ran into an issue with an uninitialized pointer which I
expected g++ to warn about.

class Foo {
public:
Foo* a(){ return this; }
};

int main(int argc, const char*[] ){
for ( int i = 0; i < 6; i++ ){
Foo* foo = foo->a();
}
}

This code compiles without any warnings (with -Wall) with both g++-4.4.2
and g++-4.2.4. Removing the for-loop gives me a warning as expected:

foo.cpp: In function ‘int main(int, const char**)’:
foo.cpp:8: warning: ‘foo’ is used uninitialized in this function

I know this case is a bit silly but it happened because of a typo and
went unnoticed for a while.

Is my reasoning flawed or should g++ emit a warning?

Re: Error message unrecognized opcode 'addl' in gcc-4.1.0 powerpc-eabi

2009-11-25T01:43:29Z

On Wed, 18 Nov 2009 22:14:23 -0800 (PST), you wrote:

>These instructions are inline asm from freebsd source with GNU C
>extension (__GNUC__) conditional compilation flag. I could
>proceed by undefining the flag for that file.

The right way would be to conditionalize the code on an architecture
specific definition like __i386__. IMO you should try to inform the
authors/maintainers of that code to fix it.

Philipp

Re: template classes faster than derived classes?

2009-11-25T01:15:02Z

Hi Nav,
On Tue, Nov 24, 2009 at 08:53:11PM +0000, Nava Whiteford wrote:

> >> http://linuxjunk.blogspot.com/2009/11/are-templates-faster-than-subclasses.html
>
> > I didn't see the first version. In the current version, the templated
> > code is simple enough that the optimizer can figure out the whole thing
> > and skip everything. The virtual code is not simple enough, so the code
> > actually executes.
>
> Ah ok, so it's able to optimise my loop in to a single multiply here? That's neat.
>
> > So you still aren't measuring what you set out to measure.
>
> I've constructed a slightly more complicated test:
>
> http://linuxjunk.blogspot.com/2009/11/templates-v-subclasses-v2.html
>
> In this case the templated version doesn't seem to have the same huge
> advantage. Templated 20.73s against 21.1s for the classed version. I would guess
> real, but not huge.

May be another test would be to use a very simple function - and in
addition forbid gcc to inline or optimize away the function calls:
If you define the function as:
int get_i() __attribute__((noinline)){
asm("");
return i*i;
}
it will be neither inlined nor the calls can't be optimized away (see
http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html).
Then, you really can make the functions as small as possible (e.g. doing
nothing) and compare the time needed to call them.

Axel