svn feature request: print URL in diff output
I would like that svn print the URL of each file in the diff output, like CVS's `RCS file'. One of the scripts I use to test GCC (which I have not contributed yet because of the svn transition) used it to detect the directory in which the patch should apply. Danny, can you do it for 1.3? If not (as I think), I can work on it myself. Paolo
Re: weird installation problem on i686-pc-linux-gnu
Hi, someone at the computing center just told me that the version of "install" that caused the problem was terribly obsolete and only got installed by accident. It has been removed now. If you want to add an autoconf check for this version, I can try to get a copy of the binary. But I'm not sure it's worth the trouble. Cheers, Martin --
Re: svn feature request: print URL in diff output
Paolo Bonzini wrote: > I would like that svn print the URL of each file in the diff output, like > CVS's > `RCS file'. One of the scripts I use to test GCC (which I have not contributed > yet because of the svn transition) used it to detect the directory in which the > patch should apply. Is it possible also to include a "diff" line (as it was the case with CVS diff) that shows the diff command used to produce the patch? BTW: Is there a way to include a C function heading in diff output? I have tried 'svn diff -x -p' to get: svn: '-p' is not supported Thanks, Uros.
Re: svn feature request: print URL in diff output
BTW: Is there a way to include a C function heading in diff output? I have tried 'svn diff -x -p' to get: svn: '-p' is not supported To add this by default, I made diff-cmd point to this script I called gcc-diff #! /bin/sh case "$1" in -u|-U*) exec diff -p "$@" ;; -c|-C*) exec diff -p "$@" ;; -p) exec diff -u "$@" ;; *) exec diff -up "$@" ;; esac Paolo
Re: svn feature request: print URL in diff output
Uros Bizjak <[EMAIL PROTECTED]> wrote: >> I would like that svn print the URL of each file in the diff output, >> like CVS's `RCS file'. One of the scripts I use to test GCC (which I >> have not contributed yet because of the svn transition) used it to >> detect the directory in which the > patch should apply. > > Is it possible also to include a "diff" line (as it was the case with > CVS diff) that shows the diff command used to produce the patch? > > BTW: Is there a way to include a C function heading in diff output? I > have tried http://gcc.gnu.org/wiki/SvnTricks Giovanni Bajo
__gcc_cpu_feature
Richard Guenther wrote: >Just to put some more thoughts on the table, I'm about to propose adding >a __gcc_cpu_feature symbol to $suitable_place, similar to what Intel is >doing with its __intel_cpu_indicator which is used in their runtime libraries >to select different code paths based on processor capabilities. I'm not >yet sure if and how to best expose this to the user, but internally this could >be mapped 1:1 to what we have in the TARGET_* flags. > > Richard, I think that irrespective of the current needs of v3, this preprocessor builtin can be very useful for people wanting to flexibly configure their projects to exploit the builtins when available. I would like to see you proposing a finished patch. Are there objections? Paolo.
Re: __gcc_cpu_feature
On 11/8/05, Paolo Carlini <[EMAIL PROTECTED]> wrote: > Richard Guenther wrote: > > >Just to put some more thoughts on the table, I'm about to propose adding > >a __gcc_cpu_feature symbol to $suitable_place, similar to what Intel is > >doing with its __intel_cpu_indicator which is used in their runtime libraries > >to select different code paths based on processor capabilities. I'm not > >yet sure if and how to best expose this to the user, but internally this > >could > >be mapped 1:1 to what we have in the TARGET_* flags. > > > > > Richard, I think that irrespective of the current needs of v3, this > preprocessor builtin can be very useful for people wanting to flexibly > configure their projects to exploit the builtins when available. I would > like to see you proposing a finished patch. > > Are there objections? I don't know. I still have to decide where to put the symbol and how/if to give users access to it officially. I.e. put it in crt?.o or libgcc? Have some builtin_test_cpu_feature()? Or just builtin_cpu_features() returning a pointer to the symbol? Of course not exposing it initially allows to correct all mistakes initially done. What would be interesting to know, is what architectures apart from ia32 will likely profit from this? Of course general dislike will help not wasting more time on doing it as well ;) Richard.
Re: __gcc_cpu_feature
Richard Guenther wrote: >What would be interesting to know, is what architectures apart from ia32 will >likely profit from this? > A quick comment about this: *many*. It's not only about i386 vs i486+, it's about all the arches that don't have the builtins *currently* implemented not because of fundamental limitations, but because of lazyness of the maintainers :-) I mean, currently we have nothing more than: i686 (and real, 64-bit, x86_64), ia64, alpha, powerpc, s390. Jakub just contributed sparc in gomp-branch (but, I gather, only new sparcs are amenable to that) There is also the case of hppa, which, I gather, is uncertain whether or not can have the builtins implemented in the first place. Paolo.
Cross compile, no grmic/grmiregistry
Hi all, To transform my java RMI code to windows native code, I followed Ranjit Mathew's tutorial to compile gcc to a cross compiler. http://ranjitmathew.hostingzero.com/phartz/gcj/bldgcj.html The src packages I am using are: binutils-2.16.1 gcc-4.0.2 The binary packages I am using are: mingw-runtime-3.8 w32api-3.5 After successfully runing the cross-compiler shell scripts, then checked /bin directory, I found mingw32-gcc/g++. There however is no grmic/grmiregistry. Any ideas what is going on? I then tried to compile gcc to a native compile, a error has been thrown out: collect2: ld returned 1 exit status make[2]: *** [jv-convert.exe] Error 1 make[2]: Leaving directory `/root/wingccbuild/mingw32/libjava' make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory `/root/wingccbuild/mingw32/libjava' make: *** [install-target-libjava] Error 2 Am I using the wrong src/bin packages? Any help would be much appreciated! Best Regards Rui Wang
BROKEN: pthreads and c++ statically linked
I really don't know what I could be doing wrong, but on a _stock_ FC4
install, I'm having a segfault in a pthread call when
statically linked and including iostream (or STL includes like string)
Here's the code:
#include
#include
int main(int argc, char *argv[])
{
pthread_mutexattr_t attr;
pthread_mutexattr_init( &attr );
}
And I compile with:
g++ -g -c example.c
g++ -static -g -o example example.o -lpthread
The resulting program crashes in pthread_mutexattr_init. If I merely
remove the include of , it works fine. This works fine
on FC3.
A dynamic linking variation that blows up:
g++ -g -o example example.o (leave off the -lpthread, yes this links)
I also noticed that there are _2_ libpthread.so files. One in /usr/lib,
and another in /lib which is the one ldd points to.
Finally, if I remove the include, and attempt to dynamically
link, it _finally_ complains about not finding the
pthread_mutexattr_init call. Was it somehow getting a
pthread_mutexattr_init from the libstdc++ library??
Can anyone else confirm this crash? Has anyone else seen this problem?
I've googled everywhere, and even posted to 2 forums without *any*
response. And, yes, I must statically link in my case.
Thanks for any help,
Lee
Re: BROKEN: pthreads and c++ statically linked
On Tue, Nov 08, 2005 at 09:31:56AM -0500, Dixon, Lee L. wrote:
> I really don't know what I could be doing wrong, but on a _stock_ FC4
> install, I'm having a segfault in a pthread call when
> statically linked and including iostream (or STL includes like string)
>
> Here's the code:
>
> #include
> #include
>
> int main(int argc, char *argv[])
> {
> pthread_mutexattr_t attr;
> pthread_mutexattr_init( &attr );
> }
This is a known problem, see
http://gcc.gnu.org/ml/gcc/2005-10/msg00235.html
for details.
In the mean time, don't link statically (which is a terribly bad idea
anyway), or use -Wl,--whole-archive -lpthread -Wl,--no-whole-archive.
Jakub
Re: BROKEN: pthreads and c++ statically linked
Thank you SOOO much for the reply. I'd been pulling hair out while
getting *no* responses on several forums and mail lists.
In my case, statically linking is important because of configuration
management of executable files for an airborne embedded flight control
system.
I'd like to find out if there is a bug number associated with this; be
nice to document these symptoms for others that have the same problem.
At the least, I'll try to go back to those forums and post this
workaround.
Thanks again!
Lee
On Tue, 2005-11-08 at 09:38 -0500, Jakub Jelinek wrote:
> On Tue, Nov 08, 2005 at 09:31:56AM -0500, Dixon, Lee L. wrote:
> > I really don't know what I could be doing wrong, but on a _stock_
> FC4
> > install, I'm having a segfault in a pthread call when
> > statically linked and including iostream (or STL includes like
> string)
> >
> > Here's the code:
> >
> > #include
> > #include
> >
> > int main(int argc, char *argv[])
> > {
> > pthread_mutexattr_t attr;
> > pthread_mutexattr_init( &attr );
> > }
>
> This is a known problem, see
> http://gcc.gnu.org/ml/gcc/2005-10/msg00235.html
> for details.
>
> In the mean time, don't link statically (which is a terribly bad idea
> anyway), or use -Wl,--whole-archive -lpthread -Wl,--no-whole-archive.
>
> Jakub
>
[gomp] ./libgomp_f.h:71: error: size of array 'test' is negative
Currently, on the gomp branch, I get this: if /bin/sh ./libtool --mode=compile /usr/local/src/branch/objdir.gomp/./gcc/xgcc -B/usr/local/src/branch/objdir.gomp/./gcc/ -B/usr/local/sparc64-unknown-linux-gnu/bin/ -B/usr/local/sparc64-unknown-linux-gnu/lib/ -isystem /usr/local/sparc64-unknown-linux-gnu/include -isystem /usr/local/sparc64-unknown-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I../../../gcc.gomp/libgomp -I. -I../../../gcc.gomp/libgomp/config/linux/sparc -I../../../gcc.gomp/libgomp/config/linux -I../../../gcc.gomp/libgomp/config/posix -I../../../gcc.gomp/libgomp -Wall -Werror -ftls-model=initial-exec -mcpu=v9 -Wc,-pthread -O2 -g -O2 -MT env.lo -MD -MP -MF ".deps/env.Tpo" -c -o env.lo ../../../gcc.gomp/libgomp/env.c; \ then mv -f ".deps/env.Tpo" ".deps/env.Plo"; else rm -f ".deps/env.Tpo"; exit 1; fi /usr/local/src/branch/objdir.gomp/./gcc/xgcc -B/usr/local/src/branch/objdir.gomp/./gcc/ -B/usr/local/sparc64-unknown-linux-gnu/bin/ -B/usr/local/sparc64-unknown-linux-gnu/lib/ -isystem /usr/local/sparc64-unknown-linux-gnu/include -isystem /usr/local/sparc64-unknown-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I../../../gcc.gomp/libgomp -I. -I../../../gcc.gomp/libgomp/config/linux/sparc -I../../../gcc.gomp/libgomp/config/linux -I../../../gcc.gomp/libgomp/config/posix -I../../../gcc.gomp/libgomp -Wall -Werror -ftls-model=initial-exec -pthread -mcpu=v9 -O2 -g -O2 -MT env.lo -MD -MP -MF .deps/env.Tpo -c ../../../gcc.gomp/libgomp/env.c -fPIC -DPIC -o .libs/env.o In file included from ../../../gcc.gomp/libgomp/env.c:32: ./libgomp_f.h: In function 'omp_check_defines': ./libgomp_f.h:71: error: size of array 'test' is negative This is on: Aurora SPARC Linux release 2.0 (Kashmir FC3) UltraSparc IIi (Sabre) sun4u: (auroralinux corona + rathann's and rzm's FC3 updates) binutils-2.16.91.0.2-4.sparc bison-1.875c-2.sparc dejagnu-1.4.4-2.noarch expect-5.42.1-1.sparc gcc-3.4.3-22.sparc.sparc gcc4-4.0.0-0.41.sparc.sparc glibc-2.3.5-0.fc3.1.sparcv9 glibc-2.3.5-0.fc3.1.sparc64 glibc-devel-2.3.5-0.fc3.1.sparc glibc-devel-2.3.5-0.fc3.1.sparc64 glibc-headers-2.3.5-0.fc3.1.sparc glibc-kernheaders-2.6-20sparc.sparc gmp-4.1.4-3sparc.sparc gmp-4.1.4-3sparc.sparc64 gmp-devel-4.1.4-3sparc.sparc gmp-devel-4.1.4-3sparc.sparc64 kernel-2.6.13-1.1603sp4.sparc64 package kernel-devel is not installed package kernel-smp is not installed libgcc-3.4.3-22.sparc.sparc libgcc-3.4.3-22.sparc.sparc64 libstdc++-3.4.3-22.sparc.sparc libstdc++-3.4.3-22.sparc.sparc64 libstdc++-devel-3.4.3-22.sparc.sparc libstdc++-devel-3.4.3-22.sparc.sparc64 make-3.80-5.sparc nptl-devel-2.3.5-0.fc3.1.sparcv9 tcl-8.4.7-2.sparc with: ../gcc.gomp/configure --enable-__cxa_atexit --enable-shared --with-cpu=v7 --disable-libgcj --enable-languages=c,c++,fortran Any ideas? Want more information? -- Cheers, /ChJ
Re: [gomp] ./libgomp_f.h:71: error: size of array 'test' is negative
On Tue, Nov 08, 2005 at 04:05:20PM +0100, Christian Joensson wrote: > Currently, on the gomp branch, I get this: > > if /bin/sh ./libtool --mode=compile > /usr/local/src/branch/objdir.gomp/./gcc/xgcc > -B/usr/local/src/branch/objdir.gomp/./gcc/ > -B/usr/local/sparc64-unknown-linux-gnu/bin/ > -B/usr/local/sparc64-unknown-linux-gnu/lib/ -isystem > /usr/local/sparc64-unknown-linux-gnu/include -isystem > /usr/local/sparc64-unknown-linux-gnu/sys-include -DHAVE_CONFIG_H -I. > -I../../../gcc.gomp/libgomp -I. > -I../../../gcc.gomp/libgomp/config/linux/sparc > -I../../../gcc.gomp/libgomp/config/linux > -I../../../gcc.gomp/libgomp/config/posix -I../../../gcc.gomp/libgomp > -Wall -Werror -ftls-model=initial-exec -mcpu=v9 -Wc,-pthread -O2 -g > -O2 -MT env.lo -MD -MP -MF ".deps/env.Tpo" -c -o env.lo > ../../../gcc.gomp/libgomp/env.c; \ > then mv -f ".deps/env.Tpo" ".deps/env.Plo"; else rm -f > ".deps/env.Tpo"; exit 1; fi > /usr/local/src/branch/objdir.gomp/./gcc/xgcc > -B/usr/local/src/branch/objdir.gomp/./gcc/ > -B/usr/local/sparc64-unknown-linux-gnu/bin/ > -B/usr/local/sparc64-unknown-linux-gnu/lib/ -isystem > /usr/local/sparc64-unknown-linux-gnu/include -isystem > /usr/local/sparc64-unknown-linux-gnu/sys-include -DHAVE_CONFIG_H -I. > -I../../../gcc.gomp/libgomp -I. > -I../../../gcc.gomp/libgomp/config/linux/sparc > -I../../../gcc.gomp/libgomp/config/linux > -I../../../gcc.gomp/libgomp/config/posix -I../../../gcc.gomp/libgomp > -Wall -Werror -ftls-model=initial-exec -pthread -mcpu=v9 -O2 -g -O2 > -MT env.lo -MD -MP -MF .deps/env.Tpo -c > ../../../gcc.gomp/libgomp/env.c -fPIC -DPIC -o .libs/env.o > In file included from ../../../gcc.gomp/libgomp/env.c:32: > ./libgomp_f.h: In function 'omp_check_defines': > ./libgomp_f.h:71: error: size of array 'test' is negative Can you please paste the omp_check_defines routine as from libgomp_f.h and grep config_path Makefile ? Jakub
Re: [gomp] ./libgomp_f.h:71: error: size of array 'test' is negative
On 11/8/05, Jakub Jelinek <[EMAIL PROTECTED]> wrote:
> Can you please paste the omp_check_defines routine as from libgomp_f.h
> and grep config_path Makefile
Sure, here's the (relevant(?) part of) generated libgomp_f.h:
static inline void
omp_check_defines (void)
{
char test[(24 != sizeof (omp_lock_t)
|| 4 != __alignof (omp_lock_t)
|| 24 != sizeof (omp_nest_lock_t)
|| 4 != __alignof (omp_nest_lock_t)
|| 8 != sizeof (*(omp_lock_arg_t) 0)
|| 8 != sizeof (*(omp_nest_lock_arg_t) 0))
? -1 : 1] __attribute__ ((__unused__));
}
Here's the rest:
[EMAIL PROTECTED] libgomp]$ grep config_path Makefile
config_path = linux/sparc linux posix
search_path = $(addprefix $(top_srcdir)/config/, $(config_path)) $(top_srcdir)
[EMAIL PROTECTED] libgomp]$
--
Cheers,
/ChJ
Re: [gomp] ./libgomp_f.h:71: error: size of array 'test' is negative
On Tue, Nov 08, 2005 at 05:00:43PM +0100, Christian Joensson wrote:
> Sure, here's the (relevant(?) part of) generated libgomp_f.h:
>
> static inline void
> omp_check_defines (void)
> {
> char test[(24 != sizeof (omp_lock_t)
>|| 4 != __alignof (omp_lock_t)
>|| 24 != sizeof (omp_nest_lock_t)
>|| 4 != __alignof (omp_nest_lock_t)
>|| 8 != sizeof (*(omp_lock_arg_t) 0)
>|| 8 != sizeof (*(omp_nest_lock_arg_t) 0))
> ? -1 : 1] __attribute__ ((__unused__));
> }
That smells like libgomp_f.h has been generated before linux/sparc and linux
have been added to the search path.
Can you remove it and make so that it will be recreated?
If on the first line is still not 4, please investigate with what exact
options is the mkomp_h.pl script called and why it doesn't include
config/linux/omp-lock.h instead of config/posix/omp-lock.h.
Jakub
Re: Skipping incompatable libaries on a SPARC cross compile
On Tue, Nov 08, 2005 at 09:17:10AM -0700, Mark Cuss wrote: > Hi Eric > > sparc-sun-solaris2.9-objdump -f returns the following: > libc.so: > start address 0x > ... Congratulations, this must be the longest top-post ever. -- Markus
Re: Skipping incompatable libaries on a SPARC cross compile
- Original Message - From: "Markus Trippelsdorf" <[EMAIL PROTECTED]> To: "Mark Cuss" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; Sent: Tuesday, November 08, 2005 9:29 AM Subject: Re: Skipping incompatable libaries on a SPARC cross compile On Tue, Nov 08, 2005 at 09:17:10AM -0700, Mark Cuss wrote: Hi Eric sparc-sun-solaris2.9-objdump -f returns the following: libc.so: start address 0x ... Congratulations, this must be the longest top-post ever. -- Markus Sorry, I didn't know top-posting was frowned upon. Anyways, I found a mistake in my sysroot and these messages seem to have vanished I had a symlink pointing to my local (linux) /lib instead of the sysroot's /lib (oops) Mark
Re: Skipping incompatable libaries on a SPARC cross compile
> Anyways, I found a mistake in my sysroot and these messages seem to have > vanished I had a symlink pointing to my local (linux) /lib instead of > the sysroot's /lib (oops) That would indeed explain the problem you were having. -- Eric Botcazou
Re: [gomp] ./libgomp_f.h:71: error: size of array 'test' is negative
On 11/8/05, Jakub Jelinek <[EMAIL PROTECTED]> wrote:
> On Tue, Nov 08, 2005 at 05:00:43PM +0100, Christian Joensson wrote:
> > Sure, here's the (relevant(?) part of) generated libgomp_f.h:
> >
> > static inline void
> > omp_check_defines (void)
> > {
> > char test[(24 != sizeof (omp_lock_t)
> >|| 4 != __alignof (omp_lock_t)
> >|| 24 != sizeof (omp_nest_lock_t)
> >|| 4 != __alignof (omp_nest_lock_t)
> >|| 8 != sizeof (*(omp_lock_arg_t) 0)
> >|| 8 != sizeof (*(omp_nest_lock_arg_t) 0))
> > ? -1 : 1] __attribute__ ((__unused__));
> > }
>
> That smells like libgomp_f.h has been generated before linux/sparc and linux
> have been added to the search path.
> Can you remove it and make so that it will be recreated?
> If on the first line is still not 4, please investigate with what exact
> options is the mkomp_h.pl script called and why it doesn't include
> config/linux/omp-lock.h instead of config/posix/omp-lock.h.
Before I experiment with that, pls note that the compiler is (default)
configured for target sparc64-unknown-linux-gnu and with the configure
option --with-cpu=v7 resulting in default v7 (32-bit) code. May this
"trick" be the trouble here?
--
Cheers,
/ChJ
Re: [gomp] ./libgomp_f.h:71: error: size of array 'test' is negative
On 11/8/05, Christian Joensson <[EMAIL PROTECTED]> wrote:
> On 11/8/05, Jakub Jelinek <[EMAIL PROTECTED]> wrote:
> > On Tue, Nov 08, 2005 at 05:00:43PM +0100, Christian Joensson wrote:
> > > Sure, here's the (relevant(?) part of) generated libgomp_f.h:
> > >
> > > static inline void
> > > omp_check_defines (void)
> > > {
> > > char test[(24 != sizeof (omp_lock_t)
> > >|| 4 != __alignof (omp_lock_t)
> > >|| 24 != sizeof (omp_nest_lock_t)
> > >|| 4 != __alignof (omp_nest_lock_t)
> > >|| 8 != sizeof (*(omp_lock_arg_t) 0)
> > >|| 8 != sizeof (*(omp_nest_lock_arg_t) 0))
> > > ? -1 : 1] __attribute__ ((__unused__));
> > > }
> >
> > That smells like libgomp_f.h has been generated before linux/sparc and linux
> > have been added to the search path.
> > Can you remove it and make so that it will be recreated?
> > If on the first line is still not 4, please investigate with what exact
> > options is the mkomp_h.pl script called and why it doesn't include
> > config/linux/omp-lock.h instead of config/posix/omp-lock.h.
>
>
> Before I experiment with that, pls note that the compiler is (default)
> configured for target sparc64-unknown-linux-gnu and with the configure
> option --with-cpu=v7 resulting in default v7 (32-bit) code. May this
> "trick" be the trouble here?
simply deleting the file libgomp_f.h does not work. I get this new
file generated, different:
diff -c sparc64-unknown-linux-gnu/libgomp/libgomp_f.h ~/libgomp_f.h
*** sparc64-unknown-linux-gnu/libgomp/libgomp_f.h 2005-11-08
18:53:55.0 +0100
--- /home/chj/libgomp_f.h 2005-10-30 02:45:09.0 +0200
***
*** 39,46
#include
#endif
! #if (4 == 4) \
! && (4 <= 4)
# define OMP_LOCK_DIRECT
typedef omp_lock_t *omp_lock_arg_t;
# define omp_lock_arg(arg) (arg)
--- 39,46
#include
#endif
! #if (24 == 8) \
! && (4 <= 24)
# define OMP_LOCK_DIRECT
typedef omp_lock_t *omp_lock_arg_t;
# define omp_lock_arg(arg) (arg)
***
*** 49,56
# define omp_lock_arg(arg) ((arg)->lock)
# endif
! #if (8 == 8) \
! && (4 <= 8)
# define OMP_NEST_LOCK_DIRECT
typedef omp_nest_lock_t *omp_nest_lock_arg_t;
# define omp_nest_lock_arg(arg) (arg)
--- 49,56
# define omp_lock_arg(arg) ((arg)->lock)
# endif
! #if (24 == 8) \
! && (4 <= 24)
# define OMP_NEST_LOCK_DIRECT
typedef omp_nest_lock_t *omp_nest_lock_arg_t;
# define omp_nest_lock_arg(arg) (arg)
***
*** 62,72
static inline void
omp_check_defines (void)
{
! char test[(4 != sizeof (omp_lock_t)
|| 4 != __alignof (omp_lock_t)
!|| 8 != sizeof (omp_nest_lock_t)
|| 4 != __alignof (omp_nest_lock_t)
!|| 4 != sizeof (*(omp_lock_arg_t) 0)
|| 8 != sizeof (*(omp_nest_lock_arg_t) 0))
? -1 : 1] __attribute__ ((__unused__));
}
--- 62,72
static inline void
omp_check_defines (void)
{
! char test[(24 != sizeof (omp_lock_t)
|| 4 != __alignof (omp_lock_t)
!|| 24 != sizeof (omp_nest_lock_t)
|| 4 != __alignof (omp_nest_lock_t)
!|| 8 != sizeof (*(omp_lock_arg_t) 0)
|| 8 != sizeof (*(omp_nest_lock_arg_t) 0))
? -1 : 1] __attribute__ ((__unused__));
}
and the compile ends the same:
/usr/local/src/branch/objdir.gomp/./gcc/xgcc
-B/usr/local/src/branch/objdir.gomp/./gcc/
-B/usr/local/sparc64-unknown-linux-gnu/bin/
-B/usr/local/sparc64-unknown-linux-gnu/lib/ -isystem
/usr/local/sparc64-unknown-linux-gnu/include -isystem
/usr/local/sparc64-unknown-linux-gnu/sys-include -DHAVE_CONFIG_H -I.
-I../../../../gcc.gomp/libgomp -I.
-I../../../../gcc.gomp/libgomp/config/linux/sparc
-I../../../../gcc.gomp/libgomp/config/linux
-I../../../../gcc.gomp/libgomp/config/posix
-I../../../../gcc.gomp/libgomp -Wall -Werror -pthread
-ftls-model=initial-exec -O2 -g -O2 -m64 -MT env.lo -MD -MP -MF
.deps/env.Tpo -c ../../../../gcc.gomp/libgomp/env.c -fPIC -DPIC -o
.libs/env.o
In file included from ../../../../gcc.gomp/libgomp/env.c:32:
./libgomp_f.h: In function 'omp_check_defines':
./libgomp_f.h:71: error: size of array 'test' is negative
--
Cheers,
/ChJ
Re: Copies of the GCC repository
On 11/7/05, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote: [snip] > I have generated an SVK repository to go with this. As anyone who's > doing or done this themselves can attest, it takes a long time and a > lot of RAM and a whole ton of I/O. Yes, it takes very long time, few hours before I interrupted it. Plus, I am not sure I was following correct steps. Would it be possible to updatw svkhelp page on wiki to list all the steps required to set up a svk mirror using one or both of these tar.rz files ? Thank you. [snip] > point I will update the wiki with useful bits, but I don't have many > just yet. For instance, two open questions while I was writing this: > > - how to make svk refuse commits to the mirrored portion instead of > wanting to push them upstream My plan is to set up read only mirror (using svn://gcc.gnu.org/...). I do not know if it will work or not. > - how to make svk access depots remotely I have not figured this out, so I also want to know this. One additional open question for me, - how to keep local branches on two machines in sync with each other ? Thanks, - Devang
Re: Copies of the GCC repository
On Tue, Nov 08, 2005 at 10:37:13AM -0800, Devang Patel wrote: > On 11/7/05, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote: > > [snip] > > > I have generated an SVK repository to go with this. As anyone who's > > doing or done this themselves can attest, it takes a long time and a > > lot of RAM and a whole ton of I/O. > > Yes, it takes very long time, few hours before I interrupted it. Plus, Try "five to seven days". > I am not sure I was following correct steps. Would it be possible to > updatw svkhelp page on wiki to list all the steps required to set up a > svk mirror using one or both of these tar.rz files ? Thank you. All you need to do is what I outlined in the mail you're responding to. Yes, I need to update the Wiki with this information. I'll do that now. > > point I will update the wiki with useful bits, but I don't have many > > just yet. For instance, two open questions while I was writing this: > > > > - how to make svk refuse commits to the mirrored portion instead of > > wanting to push them upstream > > My plan is to set up read only mirror (using svn://gcc.gnu.org/...). I > do not know if it will work or not. Yes, that works fine, but I'm not sure what will happen if you try to commit. -- Daniel Jacobowitz CodeSourcery, LLC
Re: Copies of the GCC repository
On Tue, 2005-11-08 at 13:42 -0500, Daniel Jacobowitz wrote: > On Tue, Nov 08, 2005 at 10:37:13AM -0800, Devang Patel wrote: > > On 11/7/05, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote: > > > > [snip] > > > > > I have generated an SVK repository to go with this. As anyone who's > > > doing or done this themselves can attest, it takes a long time and a > > > lot of RAM and a whole ton of I/O. > > > > Yes, it takes very long time, few hours before I interrupted it. Plus, > > Try "five to seven days". > > > I am not sure I was following correct steps. Would it be possible to > > updatw svkhelp page on wiki to list all the steps required to set up a > > svk mirror using one or both of these tar.rz files ? Thank you. > > All you need to do is what I outlined in the mail you're responding to. > Yes, I need to update the Wiki with this information. I'll do that > now. > > > > point I will update the wiki with useful bits, but I don't have many > > > just yet. For instance, two open questions while I was writing this: > > > > > > - how to make svk refuse commits to the mirrored portion instead of > > > wanting to push them upstream > > > > My plan is to set up read only mirror (using svn://gcc.gnu.org/...). I > > do not know if it will work or not. > > Yes, that works fine, but I'm not sure what will happen if you try to > commit. > If you try to commit to the mirror, it will try to commit to the underlying repo. That's how svk push actually works. It is expected that you make local branches from the mirror, and use smerge and friends to keep them up-to-date (smerge is apparently very smart and can do this without any trouble :P) --Dan
Re: Copies of the GCC repository
On Tue, Nov 08, 2005 at 01:47:52PM -0500, Daniel Berlin wrote: > If you try to commit to the mirror, it will try to commit to the > underlying repo. > > That's how svk push actually works. Yes, of course, but what if you've checked out using a read-only protocol? Is it going to fall down? Refuse to commit entirely? -- Daniel Jacobowitz CodeSourcery, LLC
Re: Copies of the GCC repository
On Tue, 2005-11-08 at 13:56 -0500, Daniel Jacobowitz wrote: > On Tue, Nov 08, 2005 at 01:47:52PM -0500, Daniel Berlin wrote: > > If you try to commit to the mirror, it will try to commit to the > > underlying repo. > > > > That's how svk push actually works. > > Yes, of course, but what if you've checked out using a read-only > protocol? Is it going to fall down? Refuse to commit entirely? > It will simply tell you you don't have access :) The protocol isn't readonly, the perms are just set on the repo so it can't commit.
Re: Re: Does gcc-3.4.3 for HP-UX 11.23/IA-64 work?
> > As mentioned before, there is a brace missing after the gcc_s_hpux64. > > This brace is needed to close off the shared-libgcc rule before the > > static-libgcc rule starts. You then must delete a brace from the end of > > the !static rule which has one too many. > > Yes, doing so gives the correct 'gcc -shared' output. I am not convinced there is a bug here. I think there may have been a deliberate change between 3.4.* and 4.* about whether or not '-shared' implied '-shared-libgcc', particularly for C code. I notice that if I compile using 3.4.4 and use '-shared -shared-libgcc' instead of just '-shared' then it works as you want. Steve Ellcey [EMAIL PROTECTED]
Re: [gomp] ./libgomp_f.h:71: error: size of array 'test' is negative
On Tue, Nov 08, 2005 at 07:28:45PM +0100, Christian Joensson wrote: > > Before I experiment with that, pls note that the compiler is (default) > > configured for target sparc64-unknown-linux-gnu and with the configure > > option --with-cpu=v7 resulting in default v7 (32-bit) code. May this > > "trick" be the trouble here? No, I have been using exactly the same when I built it on SPARC a few days ago. > simply deleting the file libgomp_f.h does not work. I get this new > file generated, different: The sparc64-unknown-linux-gnu/libgomp/libgomp_f.h one contains the expected numbers. If that fails the env.c check too, please replace -c on the command line you pasted with -E -dD and mail the result to me. > /usr/local/src/branch/objdir.gomp/./gcc/xgcc > -B/usr/local/src/branch/objdir.gomp/./gcc/ > -B/usr/local/sparc64-unknown-linux-gnu/bin/ > -B/usr/local/sparc64-unknown-linux-gnu/lib/ -isystem > /usr/local/sparc64-unknown-linux-gnu/include -isystem > /usr/local/sparc64-unknown-linux-gnu/sys-include -DHAVE_CONFIG_H -I. > -I../../../../gcc.gomp/libgomp -I. > -I../../../../gcc.gomp/libgomp/config/linux/sparc > -I../../../../gcc.gomp/libgomp/config/linux > -I../../../../gcc.gomp/libgomp/config/posix > -I../../../../gcc.gomp/libgomp -Wall -Werror -pthread > -ftls-model=initial-exec -O2 -g -O2 -m64 -MT env.lo -MD -MP -MF > .deps/env.Tpo -c ../../../../gcc.gomp/libgomp/env.c -fPIC -DPIC -o > .libs/env.o > In file included from ../../../../gcc.gomp/libgomp/env.c:32: > ./libgomp_f.h: In function 'omp_check_defines': > ./libgomp_f.h:71: error: size of array 'test' is negative Jakub
apps built w/ -fstack-protector-all segfault
Hello! gcc-4.1.20051105 -fno-stack-protector-all is not recognised/implemented apps built w/ -fstack-protector-all segfault test env: - uClibc-svn - guard is set up like glibc does in ld.so as non-TLS version - libssp is not used, gcc's configure check was enabled to recognize __stack_chk_guard in uClibc Peter PS: please CC to me, not on list, thanks -- Peter S. MazingerID: 0xA5F059F2 Key fingerprint = 92A4 31E1 56BC 3D5A 2D08 BB6E C389 975E A5F0 59F2
gcc-3.4-20051108 is now available
Snapshot gcc-3.4-20051108 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/3.4-20051108/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 3.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-3_4-branch revision 106659 You'll find: gcc-3.4-20051108.tar.bz2 Complete GCC (includes all of below) gcc-core-3.4-20051108.tar.bz2 C front end and core compiler gcc-ada-3.4-20051108.tar.bz2 Ada front end and runtime gcc-g++-3.4-20051108.tar.bz2 C++ front end and runtime gcc-g77-3.4-20051108.tar.bz2 Fortran 77 front end and runtime gcc-java-3.4-20051108.tar.bz2 Java front end and runtime gcc-objc-3.4-20051108.tar.bz2 Objective-C front end and runtime gcc-testsuite-3.4-20051108.tar.bz2The GCC testsuite Diffs from 3.4-20051025 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-3.4 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Does gcc-3.4.3 for HP-UX 11.23/IA-64 work?
Steve Ellcey wrote: I am not convinced there is a bug here. There is an extremely obvious bug here. Please look at the specs that Albert Chin included in his email message. There is no way that -static-libgcc should require -shared-libgcc, which is what happens in his specs. The only part I don't understand is where these specs came from, as this doesn't match anything in the FSF tree. I'm guessing that HP is distributing a modified gcc with patches added to it, and these patches are buggy. I went to the HP web site, and I see that the gcc sources there are in a depot file. Can I do anything with a depot file even though I don't have HPUX? I haven't tried downloading the file to check. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: -Wuninitialized issues
On Wed, 2005-11-02 at 18:02 -0800, Mark Mitchell wrote:
> Jeffrey A Law wrote:
>
> > For example, if the only use was inside an unreachable hunk of
> > code, does that count as a use or not?
>
> Yes, the EDG front-end does this:
>
> [EMAIL PROTECTED]:~/tmp$ cat test.cpp
> void f() {
> int i;
> if (0)
> i = 3;
> }
> [EMAIL PROTECTED]:~/tmp$ eccp -A test.cpp
> "test.cpp", line 2: warning: variable "i" was set but never used
> int i;
Well, if we wanted to do something that simplistic, it's just a walk
over the IL :-) Two bits. One if we've seen a set for the variable,
the other if we've seen a use.
> (Wouldn't it be easy to emit a warning for this in GCC, in the same
> optimization-based way we do uninitialized warnings? If there are no
> paths from the block with the assignment to a use, then the store is
> useless.)
It wouldn't be terribly hard. It's just DCE with some additional
bookkeeping.
FWIW, I have come across a case where we're still going to have
inconsistencies in our uninitialized warnings, even with the
new -Wuninitialized=2 bits.
We do not give uninitialized warnings for objects which live in
memory. So for example if a variable's address is taken, then we
do not attempt to give an uninitialized warning for it.
However, our optimizers _may_ remove the need for taking the
variable's address. If that happens, then the new variable is
exposed and we'll do the uninitialized analysis after optimization
is complete.
So there's still going to be cases where we can get inconsistent
results from one release to the next. Ugh.
I also mis-read the passes.c code, we do not build the SSA form
unless we are optimizing. So we still need -O to get uninitialized
warnings. I think we can address that separately.
I've put a possible patch in the metabug (24639). As I mention in
the comments, I'm not comfortable self-approving it given my lack of
knowledge about the option processing code and the debate over what
we want the default -Wuninitialized behavior to be.
jeff
Re: Does gcc-3.4.3 for HP-UX 11.23/IA-64 work?
On Tue, Nov 08, 2005 at 04:00:42PM -0800, Jim Wilson wrote: > The only part I don't understand is where these specs came from, as > this doesn't match anything in the FSF tree. I'm guessing that HP > is distributing a modified gcc with patches added to it, and these > patches are buggy. I went to the HP web site, and I see that the > gcc sources there are in a depot file. Can I do anything with a > depot file even though I don't have HPUX? I haven't tried > downloading the file to check. A .depot file is a tar file so just untar it. -- albert chin ([EMAIL PROTECTED])
Re: Does gcc-3.4.3 for HP-UX 11.23/IA-64 work?
On Tue, 2005-11-08 at 17:22, Albert Chin wrote: > A .depot file is a tar file so just untar it. Yeah, I knew that, it just took me a while to remember. I added comments to PR 24718 explaining what the underlying problem is, and confirming the bug. I probably can't do much more as I don't have an ia64-hpux machine. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: -Wuninitialized issues
> I've put a possible patch in the metabug (24639). As I mention in > the comments, I'm not comfortable self-approving it given my lack of > knowledge about the option processing code and the debate over what > we want the default -Wuninitialized behavior to be. > jeff If it helps, I withdraw my objection. Out of curiosity, I bootstrapped your patch with -Wuninitialized=2 in STRICT2_WARN and got 63 hits within GCC on x86_64-unknown-linux-gnu. That's not too terrible to fix, if we decide to add that flag to the bootstrap sequence. --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
non-ambiguous typedefs
Hi All,
I'm wondering if the following behavior is:
1. An already reported bug.
2. Not reported, I need to file a bugzilla.
3. Disputed.
Here's the test case:
typedef unsigned short ushort;
namespace X
{
typedef unsigned short ushort;
}
using namespace X;
int main()
{
ushort us = 0;
}
We currently get:
error: 'ushort' was not declared in this scope
The deal is that the typedef ushort is defined in two different
places, to the same type, and then brought "in conflict" via a using
declaration. But since the two typedefs refer to the same type, I
expect that the compiler will see that there is no conflict, and
proceed without error or warning (reference C++03 7.1.3p2).
Had the two typedefs referred to different types, I expect the
compiler to complain about an ambiguity, for example:
typedef unsigned short ushort;
namespace X
{
typedef short ushort;
}
using namespace X;
int main()
{
ushort us = 0;
}
error: ambiguous access to name found 'ushort' and 'X::ushort'
-Howard
Re: Copies of the GCC repository
On 11/8/05, Daniel Berlin <[EMAIL PROTECTED]> wrote: > It will simply tell you you don't have access :) However, it is rejecting local branch creation also. --- $ svk ls /svkgcc/gcc/local_branches Path /gcc/local_branches is not a versioned directory bardoli:~ bardoli$ svk mkdir /svkgcc/gcc/local_branches Waiting for editor... Merging back to mirror source svn://gcc.gnu.org/svn/gcc. Use of uninitialized value in concatenation (.) or string at /usr/local/svk-1.05/perl/darwin-thread-multi-2level/SVN/Core.pm line 579. Authorization failed: Commit message saved in svk-commitllh82.tmp. --- Isn't this, creating local branches, is a local operation ? - Devang
Re: Copies of the GCC repository
On Tue, Nov 08, 2005 at 06:41:05PM -0800, Devang Patel wrote: > On 11/8/05, Daniel Berlin <[EMAIL PROTECTED]> wrote: > > > It will simply tell you you don't have access :) > > However, it is rejecting local branch creation also. > > --- > $ svk ls /svkgcc/gcc/local_branches > Path /gcc/local_branches is not a versioned directory > bardoli:~ bardoli$ svk mkdir /svkgcc/gcc/local_branches > Waiting for editor... > Merging back to mirror source svn://gcc.gnu.org/svn/gcc. > Use of uninitialized value in concatenation (.) or string at > /usr/local/svk-1.05/perl/darwin-thread-multi-2level/SVN/Core.pm line > 579. > Authorization failed: > Commit message saved in svk-commitllh82.tmp. > --- > > Isn't this, creating local branches, is a local operation ? //gcc is a mirrored location. You have to create your branches outside of there; try /svkgcc/local-gcc in your example. -- Daniel Jacobowitz CodeSourcery, LLC
Re: Copies of the GCC repository
On 11/8/05, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote: > > > Isn't this, creating local branches, is a local operation ? > > //gcc is a mirrored location. You have to create your branches outside > of there; try /svkgcc/local-gcc in your example. Yes, this works. Thanks, - Devang
Re: non-ambiguous typedefs
Howard Hinnant <[EMAIL PROTECTED]> writes:
| Hi All,
|
| I'm wondering if the following behavior is:
|
| 1. An already reported bug.
| 2. Not reported, I need to file a bugzilla.
| 3. Disputed.
|
| Here's the test case:
|
| typedef unsigned short ushort;
|
| namespace X
| {
| typedef unsigned short ushort;
| }
|
| using namespace X;
|
| int main()
| {
| ushort us = 0;
| }
|
| We currently get:
|
| error: 'ushort' was not declared in this scope
Plain compiler bug. I'm not aware of any existing report to that
effect, though GCC/g++ currently is completely confused when it sees
apparently ambiguous declarations, and would report non-existent
declaration. That needs fixing.
-- Gaby
Re: [gomp] ./libgomp_f.h:71: error: size of array 'test' is negative
On 11/8/05, Jakub Jelinek <[EMAIL PROTECTED]> wrote:
> On Tue, Nov 08, 2005 at 05:00:43PM +0100, Christian Joensson wrote:
> > Sure, here's the (relevant(?) part of) generated libgomp_f.h:
> >
> > static inline void
> > omp_check_defines (void)
> > {
> > char test[(24 != sizeof (omp_lock_t)
> >|| 4 != __alignof (omp_lock_t)
> >|| 24 != sizeof (omp_nest_lock_t)
> >|| 4 != __alignof (omp_nest_lock_t)
> >|| 8 != sizeof (*(omp_lock_arg_t) 0)
> >|| 8 != sizeof (*(omp_nest_lock_arg_t) 0))
> > ? -1 : 1] __attribute__ ((__unused__));
> > }
>
> That smells like libgomp_f.h has been generated before linux/sparc and linux
> have been added to the search path.
> Can you remove it and make so that it will be recreated?
> If on the first line is still not 4, please investigate with what exact
> options is the mkomp_h.pl script called and why it doesn't include
> config/linux/omp-lock.h instead of config/posix/omp-lock.h.
mea culpa, this was due to a bubblestrap... a clean bootstrap gets me through.
sorry fro the fuzz...
--
Cheers,
/ChJ
i686-pc-cygwin crash gcc-4.0 branch
I have been noticing the following error in trunk and in branch. It looks look in libstdc++-v3 signbit, Has it been reported yet? /home/sherlock/gcc/o/gcc/xgcc -B/home/sherlock/gcc/o/gcc/ -B/usr/local/i686-pc-c ygwin/bin/ -B/usr/local/i686-pc-cygwin/lib/ -isystem /usr/local/i686-pc-cygwin/i nclude -isystem /usr/local/i686-pc-cygwin/sys-include -DHAVE_CONFIG_H -I. -I../. ./../../gcc-4_0-branch/libstdc++-v3/libmath -I.. -O2 -g -O2 -c ../../../../gcc-4 _0-branch/libstdc++-v3/libmath/signbit.c -o signbit.o In file included from ../../../../gcc-4_0-branch/libstdc++-v3/libmath/signbit.c: 32: ../../../../gcc-4_0-branch/libstdc++-v3/libmath/mathconf.h:167: error: conflicti ng types for 'ieee_double_shape_type' ../../../../gcc-4_0-branch/libstdc++-v3/libmath/mathconf.h:156: error: previous declaration of 'ieee_double_shape_type' was here ../../../../gcc-4_0-branch/libstdc++-v3/libmath/mathconf.h:216: error: conflicti ng types for 'ieee_long_double_shape_type' ../../../../gcc-4_0-branch/libstdc++-v3/libmath/mathconf.h:203: error: previous declaration of 'ieee_long_double_shape_type' was here ../../../../gcc-4_0-branch/libstdc++-v3/libmath/mathconf.h:254: error: conflicti ng types for 'ieee_quad_double_shape_type' ../../../../gcc-4_0-branch/libstdc++-v3/libmath/mathconf.h:239: error: previous declaration of 'ieee_quad_double_shape_type' was here make[3]: *** [signbit.lo] Error 1 make[3]: Leaving directory `/home/sherlock/gcc/o/i686-pc-cygwin/libstdc++-v3/lib math' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/sherlock/gcc/o/i686-pc-cygwin/libstdc++-v3' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/sherlock/gcc/o/i686-pc-cygwin/libstdc++-v3' make: *** [all-target-libstdc++-v3] Error 2 [EMAIL PROTECTED] ~/gcc/o $
Re: Cross compile, no grmic/grmiregistry
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rui Wang wrote: > Hi all, > > To transform my java RMI code to windows native code, I followed Ranjit > Mathew's tutorial to compile gcc to a cross compiler. > http://ranjitmathew.hostingzero.com/phartz/gcj/bldgcj.html [...] > After successfully runing the cross-compiler shell scripts, then checked > /bin directory, I found mingw32-gcc/g++. There however is no > grmic/grmiregistry. Any ideas what is going on? > > I then tried to compile gcc to a native compile, a error has been thrown out: > collect2: ld returned 1 exit status > make[2]: *** [jv-convert.exe] Error 1 [...] > Am I using the wrong src/bin packages? Any help would be much appreciated! It seems that both on trunk as well as the 4.0 branch, we do not build jv-convert, grmic, etc. if the build is not native. From the file "libjava/Makefile.am" on the 4.0 branch: - - 8< - ## For now, only on native systems. FIXME. if NATIVE bin_PROGRAMS = jv-convert gij grmic grmiregistry gcj-dbtool endif - - 8< - So this is expected behaviour at the moment. HTH, Ranjit. - -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDcaK/Yb1hx2wRS48RAknqAJ4xLPplk5AE8FfIcTB7wKDeT3FQxgCdG6FJ eYUCAZKwbz5w08rQ2HCJiFo= =8l0s -END PGP SIGNATURE-
Re: i686-pc-cygwin crash gcc-4.0 branch
Bobby McNulty wrote: > I have been noticing the following error in trunk and in branch. I get no such error when compiling the trunk. > /home/sherlock/gcc/o/gcc/xgcc -B/home/sherlock/gcc/o/gcc/ > -B/usr/local/i686-pc-c > ygwin/bin/ -B/usr/local/i686-pc-cygwin/lib/ -isystem > /usr/local/i686-pc-cygwin/i > nclude -isystem /usr/local/i686-pc-cygwin/sys-include -DHAVE_CONFIG_H > -I. -I../. > ./../../gcc-4_0-branch/libstdc++-v3/libmath -I.. -O2 -g -O2 -c > ../../../../gcc-4 > _0-branch/libstdc++-v3/libmath/signbit.c -o signbit.o > In file included from > ../../../../gcc-4_0-branch/libstdc++-v3/libmath/signbit.c: > 32: > ../../../../gcc-4_0-branch/libstdc++-v3/libmath/mathconf.h:167: error: > conflicti > ng types for 'ieee_double_shape_type' It looks like what is happening is BYTE_ORDER isn't getting defined correctly. This is supposed to be taken care of by the sys/param.h header of the target, which Cygwin does provide correctly. It looks like for some reason gcc isn't picking this up in your case. Are you doing a native or a cross? What configure options are you using? Brian
Re: i686-pc-cygwin crash gcc-4.0 branch
Brian Dessent wrote: Bobby McNulty wrote: I have been noticing the following error in trunk and in branch. I get no such error when compiling the trunk. /home/sherlock/gcc/o/gcc/xgcc -B/home/sherlock/gcc/o/gcc/ -B/usr/local/i686-pc-c ygwin/bin/ -B/usr/local/i686-pc-cygwin/lib/ -isystem /usr/local/i686-pc-cygwin/i nclude -isystem /usr/local/i686-pc-cygwin/sys-include -DHAVE_CONFIG_H -I. -I../. ./../../gcc-4_0-branch/libstdc++-v3/libmath -I.. -O2 -g -O2 -c ../../../../gcc-4 _0-branch/libstdc++-v3/libmath/signbit.c -o signbit.o In file included from ../../../../gcc-4_0-branch/libstdc++-v3/libmath/signbit.c: 32: ../../../../gcc-4_0-branch/libstdc++-v3/libmath/mathconf.h:167: error: conflicti ng types for 'ieee_double_shape_type' It looks like what is happening is BYTE_ORDER isn't getting defined correctly. This is supposed to be taken care of by the sys/param.h header of the target, which Cygwin does provide correctly. It looks like for some reason gcc isn't picking this up in your case. Are you doing a native or a cross? What configure options are you using? Brian native. Might be the snapshots. anyway, ../gcc-4_0-branch/configure straight like that. No other options. trunk is the sameway. Bobby
