Re: LTO and libelf (and FreeBSD)

[Richard Guenther]

On Sun, May 2, 2010 at 11:38 PM, Gerald Pfeifer  wrote:
> As http://gcc.gnu.org/ml/gcc-testresults/2010-05/msg00120.html shows,
> *-unknown-freebsd* exhibits tons of failures around LTO.
>
> I dug a bit deeper, and even the most trivial test program
>  int main() { }
> fails with
>  lto1: internal compiler error: compressed stream: data error
>  Please submit a full bug report,
>  with preprocessed source if appropriate.
>  See  for instructions.
>  lto-wrapper: /files/pfeifer/gcc/bin/gcc returned 1 exit status
>  collect2: lto-wrapper returned 1 exit status
> when compiled with gcc -flto x.c.
>
> The backtrace looks as follows, not too helpful:
>
>  #0  diagnostic_action_after_output () at /usr/test/gcc/gcc/diagnostic.c:193
>  #1  0x08136d6e in diagnostic_report_diagnostic (context=0x8926400,
>      diagnostic=0xbfbfe5f4) at /usr/test/gcc/gcc/diagnostic.c:472
>  #2  0x0813754a in internal_error (gmsgid=0x87928df "compressed stream: %s")
>      at /usr/test/gcc/gcc/diagnostic.c:757
>  #3  0x0827117e in lto_end_uncompression (stream=0x28b03b80)
>      at /usr/test/gcc/gcc/lto-compress.c:309
>  Backtrace stopped: previous frame inner to this frame (corrupt stack?)
>  (gdb)
>
> Now, gcc/doc/install.texi requests libelf version 0.8.12 which is not
> present on this system.  Rather, from what I can see FreeBSD has its
> own, independent implementation.  And something seems to be broken or
> missing or incompatible here.
>
> I can see three outcomes here, addressing this issue (which happens on
> a default installation).
>
>  1. Tighten the GCC configure checks so that they detect that (if)
>    the FreeBSD provided libelf is not sufficient and bail out.
>  2. Fix GCC to work with the FreeBSD provided libelf.
>  3. Fix FreeBSD to sufficiently support GCC (Joseph and Kai on Cc: are
>    the respective maintainers there).
>
> How can we best get this resolved?

I think Steve Kargl had the same problem and it is indeed the
FreeBSD libelf that seems to be broken.  I'd tighten the libelf
check but have no idea how to detect the broken libelf.

Richard.

> Gerald
>

static linking of pthread crashes with segfault

[Klaus Rudolph]

Hi all,

I tried to link a pthread application with -static and run into a segfault on 
x86, same on powerpc.

I tried gcc 4.4.2 (linux/x86) and 4.0.2 for powerpc-unknown-linux-gnu



For the x86 linux example I got in gdb:
(gdb) bt
#0  0x in ?? ()
#1  0x08094d49 in __cxa_guard_release ()
#2  0x08050fa1 in get_locale_mutex () at 
../../../../libstdc++-v3/src/locale_init.cc:38
#3  0x0805326a in locale (this=0x81497dc) at 
../../../../libstdc++-v3/src/locale_init.cc:211
#4  0x0804efc7 in basic_streambuf (this=0x8147260) at 
/home/krud/work/gcc-4.4.2/build_linux/i686-pc-linux-gnu/libstdc++-v3/include/streambuf:442
#5  stdio_sync_filebuf (this=0x8147260) at 
/home/krud/work/gcc-4.4.2/build_linux/i686-pc-linux-gnu/libstdc++-v3/include/ext/stdio_sync_filebuf.h:68
#6  Init (this=0x8147260) at ../../../../libstdc++-v3/src/ios_init.cc:85
#7  0x08048242 in global constructors keyed to a ()
#8  0x0810beed in __do_global_ctors_aux ()
#9  0x08048120 in _init ()
#10 0x080a8112 in __libc_csu_init ()
#11 0x080a7b73 in __libc_start_main ()
#12 0x08048151 in _start () at ../sysdeps/i386/elf/start.S:119
(gdb) 

The application runs with shared libs without any problems.

g++ -static -O2 main.cpp /usr/lib/libpthread.a -o linux

Any ideas?

Thanks
 Klaus



-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

compile problems with gcc 4.5.0

[Klaus Rudolph]

Hi all,

I tried to compile the gcc 4.5.0 version, but got errors with gmp :-(


I did:


k...@mauersegler:~/work/gcc-4.5.0$ cp -pr ../gmp-5.0.1/ ./gmp
k...@mauersegler:~/work/gcc-4.5.0$ cp -pr ../mpfr-2.4.2/ ./mpfr
k...@mauersegler:~/work/gcc-4.5.0$ cp -pr ../mpc-0.8.1/ ./mpc
k...@mauersegler:~/work/gcc-4.5.0$ cp -pr ../ppl-0.10.2/ ./ppl
k...@mauersegler:~/work/gcc-4.5.0$ mkdir build_linux
k...@mauersegler:~/work/gcc-4.5.0$ cd build_linux/
k...@mauersegler:~/work/gcc-4.5.0/build_linux$ ../configure --prefix=/opt/linux 
--enable-languages=c,c++

And got:

...
hecking whether fmal is declared... yes
checking whether rintf is declared... yes
checking whether rintl is declared... yes
checking for int_fast16_t... yes
checking for int_fast32_t... yes
checking for int_fast64_t... yes
checking for uint_fast16_t... yes
checking for uint_fast32_t... yes
checking for uint_fast64_t... yes
checking for ld used by GCC... 
/opt/linux/lib/gcc/i686-pc-linux-gnu/4.4.2/../../../../i686-pc-linux-gnu/bin/ld
checking if the linker 
(/opt/linux/lib/gcc/i686-pc-linux-gnu/4.4.2/../../../../i686-pc-linux-gnu/bin/ld)
 is GNU ld... yes
checking for shared library run path origin... done
checking how to link with libgmp... -lgmp
checking how to link with libgmpxx... -lgmpxx -lgmp
checking for the GMP library version 4.1.3 or above... no
configure: error: Cannot find GMP version 4.1.3 or higher.
GMP is the GNU Multi-Precision library:
see http://www.swox.com/gmp/ for more information.
When compiling the GMP library, do not forget to enable the C++ interface:
add --enable-cxx to the configuration options.
make[2]: *** [configure-stage1-ppl] Fehler 1
make[2]: Verlasse Verzeichnis '/home/krud/work/gcc-4.5.0/build_linux'
make[1]: *** [stage1-bubble] Fehler 2
make[1]: Verlasse Verzeichnis '/home/krud/work/gcc-4.5.0/build_linux'
make: *** [all] Fehler 2


I also copied gmp-4.3.1 to the gcc path but got the same results.

How can I proceed here?

Thanks
 Klaus


-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

gcc 4.5.0 vms-gcc_shell_handler.c needs #define __NEW_STARLET

[Jay K]

/src/gcc-4.5.0/libgcc/../gcc/config/alpha/vms-gcc_shell_handler.c: In function 
'get_dyn_handler_pointer':
/src/gcc-4.5.0/libgcc/../gcc/config/alpha/vms-gcc_shell_handler.c:73:3: error: 
'PDSCDEF' undeclared (first use in this function)
/src/gcc-4.5.0/libgcc/../gcc/config/alpha/vms-gcc_shell_handler.c:73:3: note: 
each undeclared identifier is reported only once for each function it appears in
/src/gcc-4.5.0/libgcc/../gcc/config/alpha/vms-gcc_shell_handler.c:73:13: error: 
'pd' undeclared (first use in this function)
/src/gcc-4.5.0/libgcc/../gcc/config/alpha/vms-gcc_shell_handler.c:73:18: 
warning: cast to pointer from integer of different size
/src/gcc-4.5.0/libgcc/../gcc/config/alpha/vms-gcc_shell_handler.c:73:18: error: 
expected expression before ')' token
/src/gcc-4.5.0/libgcc/../gcc/config/alpha/vms-gcc_shell_handler.c:111:17: 
warning: cast to pointer from integer of different size
/src/gcc-4.5.0/libgcc/../gcc/config/alpha/vms-gcc_shell_handler.c:111:10: 
warning: cast to pointer from integer of different size
make[4]: *** [vms-gcc_shell_handler.o] Error 1
make[3]: *** [multi-do] Error 1
make[2]: *** [all-multi] Error 2
make[1]: *** [all-target-libgcc] Error 2
make: *** [all] Error 2
 
 
fix, put this at top:
  
 
#ifndef __NEW_STARLET
#define __NEW_STARLET
#endif
 
 
 - Jay
  

Re: Question about Machine Description

[yazdanbakhsh]

Dear all,

I'm working on my a gcc compiler for my own written processor with the help
of SimpleScalar.
I want to remove "srav/slav" (immediate arithmetic shift) from the
instruction set. I explore ss.md file but I didn't see any define_ins for
the mentioned instructions, but they are used in other instruction
definitions.
It is also exist for addi/addui. Where I can find the definitions of these
instructions? I want to force gcc to just use register shift and register
add.

Best Regards,
-- 
View this message in context: 
http://old.nabble.com/Question-about-Machine-Description-tp1026428p28433505.html
Sent from the gcc - Dev mailing list archive at Nabble.com.

gcc 4.5.0 stddef.h clobbers __size_t with #define, breaks VMS (code already avoids similar on FreeBSD)

[Jay K]

VMS decc$types.h:

    typedef unsigned int __size_t;

but with GCC 4.5.0 this preprocesses as:

    typedef unsigned int ;
    
and there are ensuing errors e.g. when compiling gcc/libiberty/regex.c

probably because of:

/usr/local/lib/gcc/alpha-dec-vms/4_5_0/include/stddef.h (it does get included)
#if defined (__FreeBSD__) && (__FreeBSD__>= 5)
/* __size_t is a typedef on FreeBSD 5!, must not trash it. */
#else
#define __size_t
#endif

presumably should be more like:

#if (defined (__FreeBSD__) && (__FreeBSD__>= 5)) || defined(__vms)
/* __size_t is a typedef on FreeBSD 5 and VMS, must not trash it! */
#else
#define __size_t
#endif


That gets further, then hits 


src/gcc-4.5.0/libiberty/regex.c: In function 'byte_insert_op2':
/src/gcc-4.5.0/libiberty/regex.c:4279:1: error: unrecognizable insn:
(insn 62 61 63 5 /src/gcc-4.5.0/libiberty/regex.c:4276 (set (reg:DI 135)
    (plus:SI (subreg/s:SI (reg/v/f:DI 109 [ pfrom ]) 0)
    (const_int 5 [0x5]))) -1 (nil))
/src/gcc-4.5.0/libiberty/regex.c:4279:1: internal compiler error: in 
extract_insn, at recog.c:2103
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make: *** [regex.o] Error 1


 - Jay

  

Re: gcc 4.5.0 vms-gcc_shell_handler.c needs #define __NEW_STARLET

[Tristan Gingold]

On May 3, 2010, at 12:02 PM, Jay K wrote:

> 
> /src/gcc-4.5.0/libgcc/../gcc/config/alpha/vms-gcc_shell_handler.c: In 
> function 'get_dyn_handler_pointer':
> /src/gcc-4.5.0/libgcc/../gcc/config/alpha/vms-gcc_shell_handler.c:73:3: 
> error: 'PDSCDEF' undeclared (first use in this function)
> /src/gcc-4.5.0/libgcc/../gcc/config/alpha/vms-gcc_shell_handler.c:73:3: note: 
> each undeclared identifier is reported only once for each function it appears 
> in
> /src/gcc-4.5.0/libgcc/../gcc/config/alpha/vms-gcc_shell_handler.c:73:13: 
> error: 'pd' undeclared (first use in this function)
> /src/gcc-4.5.0/libgcc/../gcc/config/alpha/vms-gcc_shell_handler.c:73:18: 
> warning: cast to pointer from integer of different size
> /src/gcc-4.5.0/libgcc/../gcc/config/alpha/vms-gcc_shell_handler.c:73:18: 
> error: expected expression before ')' token
> /src/gcc-4.5.0/libgcc/../gcc/config/alpha/vms-gcc_shell_handler.c:111:17: 
> warning: cast to pointer from integer of different size
> /src/gcc-4.5.0/libgcc/../gcc/config/alpha/vms-gcc_shell_handler.c:111:10: 
> warning: cast to pointer from integer of different size
> make[4]: *** [vms-gcc_shell_handler.o] Error 1
> make[3]: *** [multi-do] Error 1
> make[2]: *** [all-multi] Error 2
> make[1]: *** [all-target-libgcc] Error 2
> make: *** [all] Error 2
>  
>  
> fix, put this at top:
>   
>  
> #ifndef __NEW_STARLET
> #define __NEW_STARLET
> #endif

Hi,

yes, I think that the right thing to do.  You don't even need to protect the 
#define.
Could you submit formally a patch ?  Read the guidelines at 
http://gcc.gnu.org/contribute.html.

Thanks in advance,
Tristan.

Re: gcc 4.5.0 stddef.h clobbers __size_t with #define, breaks VMS (code already avoids similar on FreeBSD)

[Tristan Gingold]

On May 3, 2010, at 12:33 PM, Jay K wrote:

> 
> VMS decc$types.h:
> 
> typedef unsigned int __size_t;
> 
> but with GCC 4.5.0 this preprocesses as:
> 
> typedef unsigned int ;
> 
> and there are ensuing errors e.g. when compiling gcc/libiberty/regex.c
> 
> probably because of:
> 
> /usr/local/lib/gcc/alpha-dec-vms/4_5_0/include/stddef.h (it does get included)
> #if defined (__FreeBSD__) && (__FreeBSD__>= 5)
> /* __size_t is a typedef on FreeBSD 5!, must not trash it. */
> #else
> #define __size_t
> #endif
> 
> presumably should be more like:
> 
> #if (defined (__FreeBSD__) && (__FreeBSD__>= 5)) || defined(__vms)
> /* __size_t is a typedef on FreeBSD 5 and VMS, must not trash it! */
> #else
> #define __size_t
> #endif

Hi,

yes, I think this is necessary on VMS.  Could you submit formally a patch (I 
can't approve it, but it is
a required first step).

> That gets further, then hits 
> 
> 
> src/gcc-4.5.0/libiberty/regex.c: In function 'byte_insert_op2':
> /src/gcc-4.5.0/libiberty/regex.c:4279:1: error: unrecognizable insn:
> (insn 62 61 63 5 /src/gcc-4.5.0/libiberty/regex.c:4276 (set (reg:DI 135)
> (plus:SI (subreg/s:SI (reg/v/f:DI 109 [ pfrom ]) 0)
> (const_int 5 [0x5]))) -1 (nil))
> /src/gcc-4.5.0/libiberty/regex.c:4279:1: internal compiler error: in 
> extract_insn, at recog.c:2103
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.
> make: *** [regex.o] Error 1

I suppose you have hit a 32/64 pointer issue.  This requires some 
investigation!  We plan to fix them,
but we haven't yet started this work on gcc 4.5

Tristan.

gcc-4.5.0 internal compiler error on alpha-dec-vms compiling libiberty/regex.c without -mbwx

[Jay K]

> src/gcc-4.5.0/libiberty/regex.c: In function 'byte_insert_op2':
> /src/gcc-4.5.0/libiberty/regex.c:4279:1: error: unrecognizable insn:
> (insn 62 61 63 5 /src/gcc-4.5.0/libiberty/regex.c:4276 (set (reg:DI 135)
> (plus:SI (subreg/s:SI (reg/v/f:DI 109 [ pfrom ]) 0)
> (const_int 5 [0x5]))) -1 (nil))
> /src/gcc-4.5.0/libiberty/regex.c:4279:1: internal compiler error: in 
> extract_insn, at recog.c:2103
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.
> make: *** [regex.o] Error 1


Fixed by saying make CFLAGS=-mbwx, which enables some byte/word instructions.
More information needed?

Let's see.
Here is the code:

/* Like `insert_op1', but for two two-byte parameters ARG1 and ARG2.  */
/* ifdef WCHAR, integer parameter is 1 wchar_t.  */

static void
PREFIX(insert_op2) (re_opcode_t op, UCHAR_T *loc, int arg1,
    int arg2, UCHAR_T *end)
{
  register UCHAR_T *pfrom = end;
  register UCHAR_T *pto = end + 1 + 2 * OFFSET_ADDRESS_SIZE;

  while (pfrom != loc)
    *--pto = *--pfrom;

  PREFIX(store_op2) (op, loc, arg1, arg2);
}

Here is a reduced/preprocessed form that hits the same problem:


jbook2:~ jay$ cat re.c
typedef unsigned char UCHAR;


void insert_op2 (UCHAR *loc, UCHAR *end)
{
   UCHAR *pfrom = end;
   UCHAR *pto = end + 1;

  while (pfrom != loc)
    *--pto = *--pfrom;
}

jbook2:~ jay$ alpha-dec-vms-gcc -c re.c

jbook2:~ jay$ alpha-dec-vms-gcc -c -O2 re.c
re.c: In function 'insert_op2':
re.c:10:1: error: unrecognizable insn:
(insn 58 57 59 5 re.c:9 (set (reg:DI 120)
    (plus:SI (subreg/s:SI (reg/v/f:DI 108 [ pfrom ]) 0)
    (const_int 1 [0x1]))) -1 (nil))
re.c:10:1: internal compiler error: in extract_insn, at recog.c:2103
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
jbook2:~ jay$ 


I opened a bug in the database.


  - Jay
  

gcc4.5.0/libiberty/pex-common.h missing pid_t on vms

[Jay K]

In file included from /src/gcc-4.5.0/libiberty/pex-common.c:23:0:
/src/gcc-4.5.0/libiberty/pex-common.h:73:3: error: expected 
specifier-qualifier-list before 'pid_t'


the code:

/* pid_t is may defined by config.h or sys/types.h needs to be
   included.  */
#if !defined(pid_t) && defined(HAVE_SYS_TYPES_H)
#include 
#endif


proposed/tested fix:
#ifdef __vms
#include 
#endif

or similar.

This then hits:

/usr/local/lib/gcc/alpha-dec-vms/4_5_0/../../../../alpha-dec-vms/include/unistd.h:475:22:
 error: macro "geteuid" passed 1 arguments, but takes just 0
/usr/local/lib/gcc/alpha-dec-vms/4_5_0/../../../../alpha-dec-vms/include/unistd.h:476:22:
 error: macro "getuid" passed 1 arguments, but takes just 0
make[2]: *** [pex-common.o] Error 1


But I say that's a bug in the VMS headers and I patch it:

#if __USE_LONG_GID_T
#   pragma __extern_prefix __save
#   pragma __extern_prefix "__long_gid_"
#elif __CRTL_VER>= 7000 && !defined(_VMS_V6_SOURCE)
#   if __CAN_USE_EXTERN_PREFIX
#  pragma __extern_prefix __save
#  pragma __extern_prefix "__unix_"
#   else
-#    define geteuid() __unix_geteuid()
-#    define getuid() __unix_getuid()
+#    define geteuid __unix_geteuid
+#    define getuid __unix_getuid
#   endif
#endif


__uid_t geteuid (void);
__uid_t getuid  (void);


I did the same thing in the VMS header unixlib.h.
Maybe something for fixincludes? (along with #define __NEW_STARLET, #define 
__int64 long long...)


(Alternate interpretation is that gcc should implement __CAN_USE_EXTERN_PREFIX
and the #pragmas. I'd be willing to #define __USE_LONG_GID_T but I assume the 
pragmas are a problem.)


 - Jay

gcc 4.5.0 libiberty .o vs. .obj confusion

[Jay K]

build=i386-darwin
host=alpha-dec-vms

target=alpha-dec-vms


alpha-dec-vms-ar rc ./libiberty.a \
      ./regex.o ./cplus-dem.o ./cp-demangle.o ./md5.o ./sha1.o ./alloca.o 
./argv.o ./choose-temp.o ./concat.o ./cp-demint.o ./crc32.o ./dyn-string.o 
./fdmatch.o ./fibheap.o ./filename_cmp.o ./floatformat.o ./fnmatch.o 
./fopen_unlocked.o ./getopt.o ./getopt1.o ./getpwd.o ./getruntime.o ./hashtab.o 
./hex.o ./lbasename.o ./lrealpath.o ./make-relative-prefix.o ./make-temp-file.o 
./objalloc.o ./obstack.o ./partition.o ./pexecute.o ./physmem.o ./pex-common.o 
./pex-one.o ./pex-unix.o ./safe-ctype.o ./sort.o ./spaces.o ./splay-tree.o 
./strerror.o ./strsignal.o ./unlink-if-ordinary.o ./xatexit.o ./xexit.o 
./xmalloc.o ./xmemdup.o ./xstrdup.o ./xstrerror.o ./xstrndup.o  ./asprintf.obj 
./insque.obj ./memmem.obj ./mempcpy.obj ./mkstemps.obj ./stpcpy.obj 
./stpncpy.obj ./strndup.obj ./strverscmp.obj ./vasprintf.obj ./vfork.obj 
./strncmp.obj
alpha-dec-vms-ar: ./asprintf.obj: No such file or directory
make: *** [libiberty.a] Error 1
jbook2:libiberty jay$ edit Makefile 


alpha-dec-gcc -c foo.c outputs foo.obj.

"Something" seems to know this, since:

libiberty/Makefile.in:
LIBOBJS = @LIBOBJS@


libiberty/Makefile:
LIBOBJS =  ${LIBOBJDIR}./asprintf$U.obj ${LIBOBJDIR}./insque$U.obj 
${LIBOBJDIR}./memmem$U.obj ${LIBOBJDIR}./mempcpy$U.obj 
${LIBOBJDIR}./mkstemps$U.obj ${LIBOBJDIR}./stpcpy$U.obj 
${LIBOBJDIR}./stpncpy$U.obj ${LIBOBJDIR}./strndup$U.obj 
${LIBOBJDIR}./strverscmp$U.obj ${LIBOBJDIR}./vasprintf$U.obj 
${LIBOBJDIR}./vfork$U.obj ${LIBOBJDIR}./strncmp$U.obj


and then later there are explicit rules for building asprintf.o, etc.
I'll probably just hack the configure Makefile to say .o.


This could be an autoconf/automake bug.
Or maybe libiberty is supposed to say $O or such in place of .o?


 - Jay
  

RE: gcc 4.5.0 libiberty .o vs. .obj confusion

[Jay K]

I'm guessing that every ".o" in libiberty/Makefile.in should be changed to 
$(OBJEXT).

Thanks,
 - Jay


> From: jay.kr...@cornell.edu
> To: gcc@gcc.gnu.org
> Subject: gcc 4.5.0 libiberty .o vs. .obj confusion
> Date: Mon, 3 May 2010 11:29:15 +
>
>
> build=i386-darwin
> host=alpha-dec-vms
>
> target=alpha-dec-vms
>
>
> alpha-dec-vms-ar rc ./libiberty.a \
>   ./regex.o ./cplus-dem.o ./cp-demangle.o ./md5.o ./sha1.o ./alloca.o 
> ./argv.o ./choose-temp.o ./concat.o ./cp-demint.o ./crc32.o ./dyn-string.o 
> ./fdmatch.o ./fibheap.o ./filename_cmp.o ./floatformat.o ./fnmatch.o 
> ./fopen_unlocked.o ./getopt.o ./getopt1.o ./getpwd.o ./getruntime.o 
> ./hashtab.o ./hex.o ./lbasename.o ./lrealpath.o ./make-relative-prefix.o 
> ./make-temp-file.o ./objalloc.o ./obstack.o ./partition.o ./pexecute.o 
> ./physmem.o ./pex-common.o ./pex-one.o ./pex-unix.o ./safe-ctype.o ./sort.o 
> ./spaces.o ./splay-tree.o ./strerror.o ./strsignal.o ./unlink-if-ordinary.o 
> ./xatexit.o ./xexit.o ./xmalloc.o ./xmemdup.o ./xstrdup.o ./xstrerror.o 
> ./xstrndup.o  ./asprintf.obj ./insque.obj ./memmem.obj ./mempcpy.obj 
> ./mkstemps.obj ./stpcpy.obj ./stpncpy.obj ./strndup.obj ./strverscmp.obj 
> ./vasprintf.obj ./vfork.obj ./strncmp.obj
> alpha-dec-vms-ar: ./asprintf.obj: No such file or directory
> make: *** [libiberty.a] Error 1
> jbook2:libiberty jay$ edit Makefile
>
>
> alpha-dec-gcc -c foo.c outputs foo.obj.
>
> "Something" seems to know this, since:
>
> libiberty/Makefile.in:
> LIBOBJS = @LIBOBJS@
>
>
> libiberty/Makefile:
> LIBOBJS =  ${LIBOBJDIR}./asprintf$U.obj ${LIBOBJDIR}./insque$U.obj 
> ${LIBOBJDIR}./memmem$U.obj ${LIBOBJDIR}./mempcpy$U.obj 
> ${LIBOBJDIR}./mkstemps$U.obj ${LIBOBJDIR}./stpcpy$U.obj 
> ${LIBOBJDIR}./stpncpy$U.obj ${LIBOBJDIR}./strndup$U.obj 
> ${LIBOBJDIR}./strverscmp$U.obj ${LIBOBJDIR}./vasprintf$U.obj 
> ${LIBOBJDIR}./vfork$U.obj ${LIBOBJDIR}./strncmp$U.obj
>
>
> and then later there are explicit rules for building asprintf.o, etc.
> I'll probably just hack the configure Makefile to say .o.
>
>
> This could be an autoconf/automake bug.
> Or maybe libiberty is supposed to say $O or such in place of .o?
>
>
>  - Jay
>
  

internal compiler error compiling gmp/get_d/gmpn_get_d for alpha-dec-vms

[Jay K]

build=i386-darwin
host=alpha-dec-vms
target=alpha-dec-vms


/bin/sh ../libtool --mode=compile alpha-dec-vms-gcc -mbwx -std=gnu99 
-DHAVE_CONFIG_H -I. -I/src/gcc-4.5.0/gmp/mpn -I.. -D__GMP_WITHIN_GMP 
-I/src/gcc-4.5.0/gmp -DOPERATION_`echo get_d | sed 's/_$//'`    -g -O2 -c -o 
get_d.lo get_d.c
 alpha-dec-vms-gcc -mbwx -std=gnu99 -DHAVE_CONFIG_H -I. 
-I/src/gcc-4.5.0/gmp/mpn -I.. -D__GMP_WITHIN_GMP -I/src/gcc-4.5.0/gmp 
-DOPERATION_get_d -g -O2 -c get_d.c -o get_d.obj
get_d.c: In function '__gmpn_get_d':
get_d.c:490:1: internal compiler error: in 
compute_frame_pointer_to_fb_displacement, at dwarf2out.c:16269
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[2]: *** [get_d.lo] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
jbook2:gmp jay$ 


I said make CFLAGS=-mieee and it seemed to fix it.
I think that merely turned off optimization though.


I did configure gcc in the first place with -disable-shared 
-enable-sjlj-exception, since there were problems compiling the libgcc/Dwarf 
stuff.
I can try "normal" there again.


 - Jay


  

Re: Plan for gc-improv merge

[Laurynas Biveinis]

2010/4/27 Diego Novillo :
> On 4/19/10 10:43 , Laurynas Biveinis wrote:
>
>> 1) New API in libiberty for creating of hash tables and splay trees
>> with user-specified callbacks for allocation. Needs libiberty
>> maintainer review.
>> 2) Make gengtype accept variable_size GTY option and output typed GC
>> allocators to gtype-desc.h. Needs global maintainer review.
>> 3) Split ggc.h into ggc.h and ggc-internal.h, introduce internal
>> interface for gengtype output to use, fix MEM_STAT accounting, partly
>> fix zone allocator, partly fix zone allocator interaction with PCH,
>> and related minor ggc-*.c and stringpool.c changes. It is basically a
>> ggc.h rewrite from scratch. Needs global, or, I dunno, middle-end
>> maintainer review.
>> 4) Annotate several types with variable_size option. Needs all the
>> front-end maintainers' and middle-end maintainer review, or, maybe
>> easier, global maintainer review together with the next patch.
>> 5) Change all the allocation sites. Touches all the frontends,
>> significant parts of middle ends, and probably all the backends too.
>> The changes here are mechanical, so it would be easiest to get a
>> global approval from a global maintainer instead of specific area
>> maintainers.
>> 6) GTY documentation update in GCC internals manual.
>
> Makes sense to me.  These all seem to be independent in terms of what
> they touch, but interdependent to apply.  Is that correct?

That is correct.

I was planning to submit the patches last Monday but contracted flu
instead :( Better luck this week.

-- 
Laurynas

Re: compile problems with gcc 4.5.0

[Jonathan Wakely]

On 3 May 2010 10:43, Klaus Rudolph wrote:
> Hi all,
>
> I tried to compile the gcc 4.5.0 version, but got errors with gmp :-(

Hi,
this question is not appropriate on this mailing list, which is for
discussing development of gcc, please take any further questions about
building or using gcc to the gcc-help mailing list, thanks.

> I did:
>
>
> k...@mauersegler:~/work/gcc-4.5.0$ cp -pr ../gmp-5.0.1/ ./gmp
> k...@mauersegler:~/work/gcc-4.5.0$ cp -pr ../mpfr-2.4.2/ ./mpfr
> k...@mauersegler:~/work/gcc-4.5.0$ cp -pr ../mpc-0.8.1/ ./mpc
> k...@mauersegler:~/work/gcc-4.5.0$ cp -pr ../ppl-0.10.2/ ./ppl

You don't need to copy the sources, a symlink will do.

> k...@mauersegler:~/work/gcc-4.5.0$ mkdir build_linux
> k...@mauersegler:~/work/gcc-4.5.0$ cd build_linux/
> k...@mauersegler:~/work/gcc-4.5.0/build_linux$ ../configure 
> --prefix=/opt/linux --enable-languages=c,c++

See http://gcc.gnu.org/install/configure.html
Building in a sub-directory of the source directory is not supported.

Jonathan

peephole optimizations

[roy rosen]

Hi All,

I have tried to write some peephole patterns and I now have some
questions regarding the way it is working.

1. Is that true that if I try to match in the pattern two insns and in
my code between these insns there is another insn which does not have
any dependency connection to the other two, Is that true that the
peephole would not match in this case? (i.e. the insns to match must
come in the code in sequential order with no other insns between
them)?

2. I saw that the peephole2 pass is done after IRA. Many peepholes are
practically useless after register allocating.
Is it possible to run it before IRA? Is it possible to run it several times?

Thanks, Roy.

Re: static linking of pthread crashes with segfault

[Jonathan Wakely]

On 3 May 2010 10:37, Klaus Rudolph wrote:
>
> g++ -static -O2 main.cpp /usr/lib/libpthread.a -o linux

You could try -static -pthread instead of specifying the static lib

Please take any follow up questions to the gcc-help list, your
question is not appropriate for this list.

Thanks,

Jonathan

[Fwd: Re: Parallelized loads and widening mults cont:ed (was: Re: GCC porting tutorials)]

[Jonas Paulsson]

>> Date: Thu, 29 Apr 2010 08:55:56 +0200 (CEST)
>> From: "Jonas Paulsson" 
>
>> It feels good to know that the widening mults issue has been
>> resolved
>
> Yes, nice, and as late as last week too, though the patch was
> from February.
>
>> as
>> it was a bit of a disapointment I noted the erratic behaviour with GCC
>> 4.4.1. Perhaps you would care to comment on what to expect as a user
>> now,
>> then?
>
> IIUC, it should Just Work.  No, I haven't checked.  Note that
> the fix was somewhat along the lines of what you wrote in your
> thesis IIUC; adding a specific pass to fix up separated
> operations.  See
>  and
> .  BTW,
> my observation was from the 4.3 era.  It's a regression, which
> explains why I hadn't noticed it with the 3.x version I used
> before that.  A pity it was deemed too invasive to fix for 4.5.

>
>> Another issue that gave me porting problems was the SIMD memory
>> accesses,
>> for e g doing a wide load into two adjacent narrow registers with one
>> instruction. This was resolved earlier on the mailinglist to not be
>> handleable on RTL, so I wonder now if anything has been done for this,
>> as
>> it too seems rather reasonable, just like the widening loads?
>
> You wanted to load adjacent data in a wider mode that was then
> to be separately used in a mode half that size, but the
> registers had to be adjacent too?  That's kind of the opposite
> problem to what's usually needed!  If the use of the data was
> actually for the obvious wider mode (SI or V2HI), you'd just
> have to define the movsi or movv2hi pattern and it would be
> used, but that unfortunately seems not applicable in any way.
> I'm not sure that problem is of common interest I'm afraid, but
> if it can be resolved with a target-specific pass, there'd be
> reason to add a hook somewhat like
> TARGET_MACHINE_DEPENDENT_REORG, but earlier.
>
> But, did you check whether combine tried to match RTL that
> looked somewhat like:
>
> (parallel
>  [(set (reg:HI 1) (mem:HI (plus:SI (reg:HI 3) (const_int 2
>   (set (reg:HI 2) (mem:HI (plus:SI (reg:HI 3) (const_int 4])
>
> I.e. a parallel with the two loads where the addresses were
> adjacent?  From gdb you inspect the calls to try_combine (IIRC).
> That insn could have been matched to a pattern like:
>
> (define_insn "*load_wide"
>  [(set (match_operand:HI 0 "register_operand" "=d0,d1,d2")
>(match_operand:HI 1 "reg_plus_const_memory_operand" "m"))
>   (set (match_operand:HI 2 "register_operand" "=d1,d2,d3")
>(match_operand:HI 3 "reg_plus_const_memory_operand" "m"))]
>  "rtx_equal_p (XEXP (operands[3], 0),
>plus_constant (XEXP (operands[1]), 2))"
>  "load_wide %0,%1")
>

Yes, of course I checked with combine, but the debug dump of the pass
revealed that it is not looking for a wider load in the case of an
adjacent load, unfortunately. I checked this again now by setting a bp in
try_combine, but there is no attempt to use the wider load insn. This
combination I then handled by an added pass that located and replaced
load/store instructions. Along with successful uses of post-inc insns,
this was an important optimization for the project. Does not make sense to
me, not to do such a simple thing as looking for offset 1 in the local
block, even... (of course, I did just the simple thing of checking for
CODE_FOR... in terms of locating load insns)

I think I tried to add a pattern with a parallel semantic pattern, but
combine did not care about it.

> Just a WAG, there are reasons this would not match in the
> general case (for one, you'd want to try to match the opposite
> order too).  Don't pay too much attention to the exact matching
> predicates, constraints and condition above.  The point is just
> whether combine tried to generate and match a parallel with two
> valid loads, given source where there was obvious opportunity
> for it.
>
> That insn *could* then be caught with a pattern which would,
> through the right constraints coerce register allocation to make
> the right choices for the (initially separete) registers.  In
> the example above, four registers are assumed to be valid as
> destination with the matching singleton constraints d0..d3.
>
I guess I wonder here how much of a tweak it is to use GCC in this fashion
- pairing 16 bit regs to 32 bit regs. There does not seem to be complete
support for it, although it works on a basic level.

> brgds, H-P
>

Re: anonymous struct

[wuyin]

I find.
-fms-extentions

Re: anonymous struct

[Michael Witten]

On Sun, May 2, 2010 at 22:47, wuyin  wrote:
> Please support this grammar.
> http://sourceforge.net/projects/coo/

My advice is to use a language with proper abstraction facilities, like C++.

Re: Question about Machine Description

[Ian Lance Taylor]

yazdanbakhsh  writes:

> I'm working on my a gcc compiler for my own written processor with the help
> of SimpleScalar.
> I want to remove "srav/slav" (immediate arithmetic shift) from the
> instruction set. I explore ss.md file but I didn't see any define_ins for
> the mentioned instructions, but they are used in other instruction
> definitions.
> It is also exist for addi/addui. Where I can find the definitions of these
> instructions? I want to force gcc to just use register shift and register
> add.

There is no ss.md file in the standard gcc distribution.  If
SimpleScalar has a gcc port, I don't know anything about it.  So it's
hard to answer to your question precisely.

Instructions can come from either a .md file or a .c file in the
config/CPU directory used for your CPU.  If those instructions are
appearing in the generated assembler, then they must be in there
somewhere.

Ian

Re: gcc4.5.0/libiberty/pex-common.h missing pid_t on vms

[Ian Lance Taylor]

Jay K  writes:

> proposed/tested fix:
> #ifdef __vms
> #include 
> #endif
>
> or similar.

Use #ifdef HAVE_UNISTD_H instead.  There are many examples in
libiberty.

Ian

Re: gcc 4.5.0 libiberty .o vs. .obj confusion

[Ian Lance Taylor]

Jay K  writes:

> I'm guessing that every ".o" in libiberty/Makefile.in should be changed to 
> $(OBJEXT).

Yes.

Ian

Re: peephole optimizations

[Ian Lance Taylor]

roy rosen  writes:

> 1. Is that true that if I try to match in the pattern two insns and in
> my code between these insns there is another insn which does not have
> any dependency connection to the other two, Is that true that the
> peephole would not match in this case? (i.e. the insns to match must
> come in the code in sequential order with no other insns between
> them)?

Yes.


> 2. I saw that the peephole2 pass is done after IRA. Many peepholes are
> practically useless after register allocating.
> Is it possible to run it before IRA? Is it possible to run it several times?

There are also many peepholes can not be run before register
allocation, because they depend on relationships between the
registers.

Before register allocation, you should normally write an insn pattern
which can be recognized by the combine pass, rather than writing a
peephole.  To do this, write a define_insn as usual, and use
appropriate operand and insn predicates to recognize the pattern you
are looking for.

That has the advantage that it works even if random insns appear in
between the insns you care about, the case you ask about in your first
question.  (However, it does not work across block boundaries.)

Ian

Re: Question about Machine Description

[yazdanbakhsh]

Hi,

Please assume I'm working with the MIPS. There is a little difference
between the MIPS and what I'm actually working on it. How can I remove
immediate logical shift right/left from the compiler?
I mean If I want the programmer writes an immediate shift, It is compiled to
the two instructions:

sll %2,%2,5

changed to:

addi %3,%0,5
sllv %2,%2,%3

thanks in advance

Ian Lance Taylor-3 wrote:
> 
> yazdanbakhsh  writes:
> 
>> I'm working on my a gcc compiler for my own written processor with the
>> help
>> of SimpleScalar.
>> I want to remove "srav/slav" (immediate arithmetic shift) from the
>> instruction set. I explore ss.md file but I didn't see any define_ins for
>> the mentioned instructions, but they are used in other instruction
>> definitions.
>> It is also exist for addi/addui. Where I can find the definitions of
>> these
>> instructions? I want to force gcc to just use register shift and register
>> add.
> 
> There is no ss.md file in the standard gcc distribution.  If
> SimpleScalar has a gcc port, I don't know anything about it.  So it's
> hard to answer to your question precisely.
> 
> Instructions can come from either a .md file or a .c file in the
> config/CPU directory used for your CPU.  If those instructions are
> appearing in the generated assembler, then they must be in there
> somewhere.
> 
> Ian
> 
> 

-- 
View this message in context: 
http://old.nabble.com/Question-about-Machine-Description-tp1026428p28439702.html
Sent from the gcc - Dev mailing list archive at Nabble.com.

Re: Question about Machine Description

[Ian Lance Taylor]

yazdanbakhsh  writes:

> Please assume I'm working with the MIPS. There is a little difference
> between the MIPS and what I'm actually working on it. How can I remove
> immediate logical shift right/left from the compiler?
> I mean If I want the programmer writes an immediate shift, It is compiled to
> the two instructions:
>
> sll %2,%2,5
>
> changed to:
>
> addi %3,%0,5
> sllv %2,%2,%3

Find the insn which generates sll.  Change the operand constraints and
predicates to reject an immediate operand.

E.g., in mips.md this is:

(define_insn "*3"
  [(set (match_operand:GPR 0 "register_operand" "=d")
(any_shift:GPR (match_operand:GPR 1 "register_operand" "d")
   (match_operand:SI 2 "arith_operand" "dI")))]
  "!TARGET_MIPS16"
{
  if (CONST_INT_P (operands[2]))
operands[2] = GEN_INT (INTVAL (operands[2])
   & (GET_MODE_BITSIZE (mode) - 1));

  return "\t%0,%1,%2";
}
  [(set_attr "type" "shift")
   (set_attr "mode" "")])


For operand 2, change the predicate to register_operand and remove the
'I' constraint.

Ian

Re: anonymous struct

[Pedro Pedruzzi]

On 03-05-2010 00:47 wuyin wrote:

struct T{
   int n;
};
struct T1{
   struct T;
} t;
t.n=1;

Please support this grammar.


I believe it _is_ currently supported with -fms-extensions.

See:

http://gcc.gnu.org/onlinedocs/gcc/Unnamed-Fields.html

Regards,
--
Pedro Pedruzzi

Re: Question about Machine Description

[yazdanbakhsh]

Is it any way that we can chat?
I'm working on my thesis project and a paper. I appreciate it if you would
cooperate in this project.
I have gmail Id "amir.yazdanbakhsh"
and also skype "amir.yazdanbakhsh"

best regards,

yazdanbakhsh wrote:
> 
> Hi,
> 
> Please assume I'm working with the MIPS. There is a little difference
> between the MIPS and what I'm actually working on it. How can I remove
> immediate logical shift right/left from the compiler?
> I mean If I want the programmer writes an immediate shift, It is compiled
> to the two instructions:
> 
> sll %2,%2,5
> 
> changed to:
> 
> addi %3,%0,5
> sllv %2,%2,%3
> 
> thanks in advance
> 
> Ian Lance Taylor-3 wrote:
>> 
>> yazdanbakhsh  writes:
>> 
>>> I'm working on my a gcc compiler for my own written processor with the
>>> help
>>> of SimpleScalar.
>>> I want to remove "srav/slav" (immediate arithmetic shift) from the
>>> instruction set. I explore ss.md file but I didn't see any define_ins
>>> for
>>> the mentioned instructions, but they are used in other instruction
>>> definitions.
>>> It is also exist for addi/addui. Where I can find the definitions of
>>> these
>>> instructions? I want to force gcc to just use register shift and
>>> register
>>> add.
>> 
>> There is no ss.md file in the standard gcc distribution.  If
>> SimpleScalar has a gcc port, I don't know anything about it.  So it's
>> hard to answer to your question precisely.
>> 
>> Instructions can come from either a .md file or a .c file in the
>> config/CPU directory used for your CPU.  If those instructions are
>> appearing in the generated assembler, then they must be in there
>> somewhere.
>> 
>> Ian
>> 
>> 
> 
> 

-- 
View this message in context: 
http://old.nabble.com/Question-about-Machine-Description-tp1026428p28439854.html
Sent from the gcc - Dev mailing list archive at Nabble.com.

Re: Question about Machine Description

[yazdanbakhsh]

I forget to thank you for your help.
But if I do write your code how compiler knows that it should be put two
instructions instead immediate shift?

I write this piese of code:

###33
(define_insn "lshrsi3"
  [(set (match_operand:SI 0 "register_operand" "=d")
(lshiftrt:SI (match_operand:SI 1 "register_operand" "d")
 (match_operand:SI 2 "arith_operand" "dI")))
(clobber(match_scratch:SI 3 "=&d"))]
  ""
  "*
{
  if (GET_CODE (operands[2]) == CONST_INT)
operands[2] = gen_rtx (CONST_INT, VOIDmode, (XINT (operands[2], 0))&
0x1f);
operands[4] = gen_rtx (REG, VOIDmode, 0);
  return \"add\\t%3,%4,%z2;srl\\t%0,%1,%3\";
}"
  [(set_attr "type" "arith")
   (set_attr "mode" "SI")
   (set_attr "length"   "1")])


Is there any other solutions?

Best Regards,

yazdanbakhsh wrote:
> 
> Is it any way that we can chat?
> I'm working on my thesis project and a paper. I appreciate it if you would
> cooperate in this project.
> I have gmail Id "amir.yazdanbakhsh"
> and also skype "amir.yazdanbakhsh"
> 
> best regards,
> 
> yazdanbakhsh wrote:
>> 
>> Hi,
>> 
>> Please assume I'm working with the MIPS. There is a little difference
>> between the MIPS and what I'm actually working on it. How can I remove
>> immediate logical shift right/left from the compiler?
>> I mean If I want the programmer writes an immediate shift, It is compiled
>> to the two instructions:
>> 
>> sll %2,%2,5
>> 
>> changed to:
>> 
>> addi %3,%0,5
>> sllv %2,%2,%3
>> 
>> thanks in advance
>> 
>> Ian Lance Taylor-3 wrote:
>>> 
>>> yazdanbakhsh  writes:
>>> 
 I'm working on my a gcc compiler for my own written processor with the
 help
 of SimpleScalar.
 I want to remove "srav/slav" (immediate arithmetic shift) from the
 instruction set. I explore ss.md file but I didn't see any define_ins
 for
 the mentioned instructions, but they are used in other instruction
 definitions.
 It is also exist for addi/addui. Where I can find the definitions of
 these
 instructions? I want to force gcc to just use register shift and
 register
 add.
>>> 
>>> There is no ss.md file in the standard gcc distribution.  If
>>> SimpleScalar has a gcc port, I don't know anything about it.  So it's
>>> hard to answer to your question precisely.
>>> 
>>> Instructions can come from either a .md file or a .c file in the
>>> config/CPU directory used for your CPU.  If those instructions are
>>> appearing in the generated assembler, then they must be in there
>>> somewhere.
>>> 
>>> Ian
>>> 
>>> 
>> 
>> 
> 
> 

-- 
View this message in context: 
http://old.nabble.com/Question-about-Machine-Description-tp1026428p28440002.html
Sent from the gcc - Dev mailing list archive at Nabble.com.

Re: Question about Machine Description

[yazdanbakhsh]

This is the newer version. It works correctly. I just want know is there any
other way.

thanks
***
(define_insn "lshrsi3"
  [(set (match_operand:SI 0 "register_operand" "=d")
(lshiftrt:SI (match_operand:SI 1 "register_operand" "d")
 (match_operand:SI 2 "arith_operand" "dI")))
(clobber(match_scratch:SI 3 "=&d"))]
  ""
  "*
{
  if (GET_CODE (operands[2]) == CONST_INT)
{
operands[2] = gen_rtx (CONST_INT, VOIDmode, (XINT (operands[2], 0))&
0x1f);
operands[4] = gen_rtx (REG, VOIDmode, 0);
return \"add\\t%3,%4,%z2;srl\\t%0,%1,%3\";
}
else
return \"srl\\t%0,%1,%2\";
}"
  [(set_attr "type" "arith")
   (set_attr "mode" "SI")
   (set_attr "length"   "1")])
***

yazdanbakhsh wrote:
> 
> Dear all,
> 
> I'm working on my a gcc compiler for my own written processor with the
> help of SimpleScalar.
> I want to remove "srav/slav" (immediate arithmetic shift) from the
> instruction set. I explore ss.md file but I didn't see any define_ins for
> the mentioned instructions, but they are used in other instruction
> definitions.
> It is also exist for addi/addui. Where I can find the definitions of these
> instructions? I want to force gcc to just use register shift and register
> add.
> 
> Best Regards,
> 

-- 
View this message in context: 
http://old.nabble.com/Question-about-Machine-Description-tp1026428p28440200.html
Sent from the gcc - Dev mailing list archive at Nabble.com.

Re: Question about Machine Description

[Ian Lance Taylor]

yazdanbakhsh  writes:

> This is the newer version. It works correctly. I just want know is there any
> other way.

Did you read what I wrote earlier?

http://gcc.gnu.org/ml/gcc/2010-05/msg00048.html

Ian

Re: split lui_movf pattern on mips?

[Amker.Cheng]

> It's the encoding of 1.0f (single precision).  The point is that we want
> something we can safely compare with 0.0f using floating-point instructions.
> "Safe" means "without generating any kind of exception", so a subnormal
> representation like 0x0001 isn't acceptable.  1.0f seems as good a
> value as any.
>

> Yes, this is OK.  Your split looks good, but I don't see any reason
> for the !CANNOT_CHANGE_MODE_CLASS condition.
>
> Couple of minor suggestions:
>
>  - There is no need for the double quotes around the { ... }.
>    Plain { ... } is better.  (Support for plain { ... } was
>    added a few years ago, so you can still see some older code
>    that uses "{ ... }".  But { ... } is better for new code.)
>
>  - It's generally better to restrict match_dups to things
>    that depend on the operands of the original insn.
>    In the above, it'd be better to replace (match_dup 4)
>    with (const_int 0) and then not set operands[4] in the
>    C code.  (match_dup 3) is OK as an exception because
>    read-rtl.c doesn't support hex constants yet...

Thanks, learned a lot from your detailed explanation.

-- 
Best Regards.

-pthread

[Magnus Fromreide]

I recently ended up in a discussion about the -pthread flag at work and
when looking at the documentation I noticed that it is defined onlt for
SPARC and RS/6000/PowerPC.

Additionally -fopenmp and -ftree-parallelize-loops say they are only
supported on targets where -pthread are available.

Now, on x86-linux it seems as if -pthread does something but there is no
documentation of it so I'd like to know

  * What does -pthread do on x86?
  * If I am to compile a threaded program am I then requiered to use
-pthread?

/MF