[Bug target/42753] _Complex_I is reported as undeclared. Code builds with Sun compiler.
--- Comment #13 from david dot kirkby at onetel dot net 2010-01-17 03:53 --- (In reply to comment #12) > Subject: Re: _Complex_I is reported as undeclared. Code > builds with Sun compiler. > > On Sat, 16 Jan 2010, david dot kirkby at onetel dot net wrote: > > > Do you know of anyone with the necessary knowledge? If so, I'll drop them an > > The correct way to communicate with maintainers is via the mailing lists > and bug database, not direct contact to individuals. They are however > listed in MAINTAINERS. > > > as we are having to disable working code on Solaris due to a bug in gcc. > > A bug in Solaris's headers and a missing feature in GCC that it doesn't > work around that bug. > Marc Glisse said on gcc-help "It looks like it was fixed in trunk in Septembre (r151331), did you check?" I downloaded gcc-4.4-20100112, but that did not fix the issue. I was hoping it might be fixed in a 4.4.x series, but no such luck. I just downloaded gcc-4.5-20100114 in the vague hope that it might be fixed, and the snapshot not cause more problems than it solves. I've not compiled that yet - just had to install MPC first. If this is fixed "in trunk" do you do you know I might get that fix? If possible, I'd like to get just the fix applied to the latest stable release (i.e. 4.4.2 plus the fix), so it is as risk-free as reasonably practical. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42753
[Bug c++/21057] iso C99 complex double: problems with g++
--- Comment #3 from david dot kirkby at onetel dot net 2010-01-16 14:29 --- (In reply to comment #2) > Confirmed. However, this has really low priority: the C++ standard is not > a superset of the C99 standard, so a number of things new to C99 are not > part of C++, and this is one of them. If you want to write portable code, > you should use the std::complex class. If you have cases where you can show > that std::complex is slower than using the C99 means, we'd be happy to > accept bug reports. > > Thanks > Wolfgang Note this bug, which you considered as low priority since it applied to using C code with the C++ compiler, is not limited to the C++ compiler. Take a look at #42753 where you will see this bug stops one building C code if using gcc. -- david dot kirkby at onetel dot net changed: What|Removed |Added CC| |david dot kirkby at onetel | |dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21057
[Bug target/42753] _Complex_I is reported as undeclared. Code builds with Sun compiler.
--- Comment #11 from david dot kirkby at onetel dot net 2010-01-16 14:27 --- (In reply to comment #10) > Subject: Re: _Complex_I is reported as undeclared. Code > builds with Sun compiler. > > On Fri, 15 Jan 2010, david dot kirkby at onetel dot net wrote: > > > Is this is trivial fix that could be implemted quickly, or it will require > > quite a bit of work, and so I should not expect a solution soon? > > It could be implemented quickly if someone familiar with fixincludes > wishes to fix it. Do you know of anyone with the necessary knowledge? If so, I'll drop them an email and ask if they would mind looking at it. It is a *major* headache for the GPL Sage maths project, http://www.sagemath.org/ as we are having to disable working code on Solaris due to a bug in gcc. Unfortunately, not all of Sage will build with Sun's compiler, so that is not an option. BTW, the bug is still marked as 'UNCONFIRMED'. Is that still appropriate? Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42753
[Bug target/42753] _Complex_I is reported as undeclared. Code builds with Sun compiler.
--- Comment #9 from david dot kirkby at onetel dot net 2010-01-15 18:25 --- (In reply to comment #8) > Fixincludes is part of the compiler sources, and it is the part that should > work around GCC-incompatible system headers (such as this one) by making > fixed copies when GCC is built and installed. Thus, a failure to fix it > indicates a limitation in fixincludes, and the fix would be to enhance > fixincludes and rebuild GCC. > > It is not part of the C front end, so "c" is not the correct component. Do > not change components back if a maintainer changes them to be more accurate. Is this is trivial fix that could be implemted quickly, or it will require quite a bit of work, and so I should not expect a solution soon? Is there any workaround you can suggest? Would simply adding #define _Complex_I _Complex_I #define complex _Complex #define _Imaginary_I_Imaginary_I #define imaginary _Imaginary #undef I #define I _Imaginary_I at the top of the source files work? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42753
[Bug c/42753] _Complex_I is reported as undeclared. Code builds with Sun compiler.
--- Comment #7 from david dot kirkby at onetel dot net 2010-01-15 16:02 --- (In reply to comment #5) > *** Bug 42755 has been marked as a duplicate of this bug. *** > (In reply to comment #4) > This is a fixincludes bug; it needs to fix Sun's complex.h header to > work with GCC. > I've read the fixincludes README, and http://autogen.SourceForge.net/fixinc.html Perhaps I'm thick, but I have great difficulty in understanding what I am supposed to do. Is this a bug in gcc, or just I've not installed gcc fully? The bug has not been marked as CONFIRMED or INVALID, so I'm unsure what you believe it is. If it's due to the fact I've mis-installed gcc, I would appreciate some clearer instructions about how to fix this problem. Those fixincludes instructions make very little sense to me. The same problem exists with the gcc included by Sun at /usr/sfw/bin/gcc (on SPARC) and also the gcc 4.3.4 build by Blastwave (a well known distributor of Solaris software) Does the fixincludes actually modify the Solaris header (in which case one would need root access)? Would including the above bit of code as another header file solve the problem? -- david dot kirkby at onetel dot net changed: What|Removed |Added Component|target |c http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42753
[Bug bootstrap/36481] gcc fails to build on Solaris x86 - it forgets the locations of libmpfr
--- Comment #18 from david dot kirkby at onetel dot net 2010-01-15 13:15 --- Subject: Re: gcc fails to build on Solaris x86 - it forgets the locations of libmpfr BlanchardJ at ieee dot org wrote: > --- Comment #17 from BlanchardJ at ieee dot org 2010-01-15 12:37 --- > >> Yes, thank you. That is helpful. How do you produce the $ISALIST? Is that >> simply >> sparcv9 on a modern SPARC and amd64 on an Open Solaris system, or is it a >> list. >> If the latter, how do you every it. >> >> >> drkir...@hawk:~$ isalist >> amd64 pentium_pro+mmx pentium_pro pentium+mmx pentium i486 i386 i86 >> >> Do I need >> >> xport LD_OPTIONS='-R/opt/csw/lib/amd64 -R opt/csw/lib/pentium_pro+mmx etc" ? >> I >> doubt it, but I'm not sure what you mean there. >> >> Is it just this, or anything else I need to do? You say "typical blastwave >> build >> would have at a minimum .." but I doubt you would consider gcc a "typical >> blastwave build" If there are further complications, can you let me know >> what >> they are. >> >> Dave >> > > Hi, > > It's just the string '$ISALIST' so it will appear as-is in the final run path. > The runtime linker will take care of expanding it correctly at runtime. So one > just export LD_OPTIONS as-is before building. > > Thank you. That's very helpful. I really hate having to set LD_LIBRARY_PATH - it is particularly an issue if you have multiple compilers. There's alyways the chance it gets set to the wrong compiler by mistake. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36481
[Bug c/42755] Using _Complex_I on Open Solaris fails to build an executable
--- Comment #2 from david dot kirkby at onetel dot net 2010-01-15 10:31 --- Created an attachment (id=19609) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19609&action=view) Preprocessed header -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42755
[Bug c/42755] Using _Complex_I on Open Solaris fails to build an executable
--- Comment #1 from david dot kirkby at onetel dot net 2010-01-15 10:30 --- Created an attachment (id=19608) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19608&action=view) simple_complex.c C source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42755
[Bug c/42755] New: Using _Complex_I on Open Solaris fails to build an executable
I reported this bug against a SPARC system at #42753, but as this is a
different version of gcc, on a different operating system with a different
processor, I thought it wise to create another ticket.
The hardware is a Sun Ultra 27, with a 3.33 GHz Xeon processor.
The attached code builds and runs as expected using the Sun Studio 12.1
compiler.
drkir...@hawk:~$ /opt/sunstudio12.1/bin/cc -V simple_complex.c
cc: Sun C 5.10 SunOS_i386 2009/06/03
acomp: Sun C 5.10 SunOS_i386 2009/06/03
ld: Software Generation Utilities - Solaris Link Editors: 5.11-1.1652
drkir...@hawk:~$ ./a.out
CYTHON_CCOMPLEX 1
However, it fails with gcc 4.3.4
drkir...@hawk:~$ /usr/local/gcc-4.3.4-GNU-assembler-Sun-linker/bin/gcc
-std=c99 -v -save-temps simple_complex.c
Using built-in specs.
Target: i386-pc-solaris2.11
Configured with: ../gcc-4.3.4/configure
--prefix=/usr/local/gcc-4.3.4-GNU-assembler-Sun-linker
--with-as=/usr/local/binutils-2.20/bin/as --with-ld=/usr/ccs/bin/ld
--with-gmp=/usr/local --with-mpfr=/usr/local
Thread model: posix
gcc version 4.3.4 (GCC)
COLLECT_GCC_OPTIONS='-std=c99' '-v' '-save-temps' '-mtune=generic'
/usr/local/gcc-4.3.4-GNU-assembler-Sun-linker/libexec/gcc/i386-pc-solaris2.11/4.3.4/cc1
-E -quiet -v simple_complex.c -mtune=generic -std=c99 -fpch-preprocess -o
simple_complex.i
ignoring nonexistent directory
"/usr/local/gcc-4.3.4-GNU-assembler-Sun-linker/lib/gcc/i386-pc-solaris2.11/4.3.4/../../../../i386-pc-solaris2.11/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/usr/local/gcc-4.3.4-GNU-assembler-Sun-linker/include
/usr/local/gcc-4.3.4-GNU-assembler-Sun-linker/lib/gcc/i386-pc-solaris2.11/4.3.4/include
/usr/local/gcc-4.3.4-GNU-assembler-Sun-linker/lib/gcc/i386-pc-solaris2.11/4.3.4/include-fixed
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-std=c99' '-v' '-save-temps' '-mtune=generic'
/usr/local/gcc-4.3.4-GNU-assembler-Sun-linker/libexec/gcc/i386-pc-solaris2.11/4.3.4/cc1
-fpreprocessed simple_complex.i -quiet -dumpbase simple_complex.c
-mtune=generic -auxbase simple_complex -std=c99 -version -o simple_complex.s
GNU C (GCC) version 4.3.4 (i386-pc-solaris2.11)
compiled by GNU C version 4.3.4, GMP version 4.3.1, MPFR version 2.4.1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: aa8da34c6527631409af75a63ef2
simple_complex.c: In function __pyx_t_double_complex_from_parts:
simple_complex.c:20: error: _Complex_I undeclared (first use in this
function)
simple_complex.c:20: error: (Each undeclared identifier is reported only once
simple_complex.c:20: error: for each function it appears in.)
--
Summary: Using _Complex_I on Open Solaris fails to build an
executable
Product: gcc
Version: 4.3.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: david dot kirkby at onetel dot net
GCC build triplet: SunOS hawk 5.11 snv_111b i86pc i386 i86pc
GCC host triplet: SunOS hawk 5.11 snv_111b i86pc i386 i86pc
GCC target triplet: SunOS hawk 5.11 snv_111b i86pc i386 i86pc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42755
[Bug bootstrap/36481] gcc fails to build on Solaris x86 - it forgets the locations of libmpfr
--- Comment #16 from david dot kirkby at onetel dot net 2010-01-15 09:59 --- Subject: Re: gcc fails to build on Solaris x86 - it forgets the locations of libmpfr BlanchardJ at ieee dot org wrote: > --- Comment #15 from BlanchardJ at ieee dot org 2010-01-15 05:12 --- > (In reply to comment #14) >> (In reply to comment #10) >>> In reply to #9: >>> >>> I have tried to build gcc with and without my own patch on our solaris >>> machines. While both of them fails they fail at the same place (namely >>> configuration of [arch]/libgcc trying to figure out the object suffix). >>> They >> It would be good if a patch similar to yours will work, so alloing gcc to be >> installed in an arbitrary location and used without setting LD_LIBRARY_PATH. >> >> The fact is, a lot of people using Solaris do not have root access, so using >> crle is not an option. >> >> It should be noted, gcc binaries from Blastwave install in a non standard >> location (/opt/csw) and do run without the user having to set >> LD_LIBRARY_PATH. >> Of course, you need root acces to install them, but they do *not* modify the >> linker search path with crle, but work without doing that. >> >> Despite asking a couple of times, I've never managed to get an answer how the >> Blastwave binaries achieve this. >> >> I'd like a pound (I'm English) for every time I have seen this issue raised >> on >> Solaris forums. It is something wanted by many, but I believe the gcc >> developers do not feel is necessary. >> >> Some have told be /usr/local is "a standard" though it's not a "standard" >> reconised by any official body, like ISO, IEEE etc. But normal users cant >> write >> there either. >> >> PS, you could always ask your uni system admins if they would set you up in a >> Solaris 10 zone. The memory overhead of a zone is quite small (well under 100 >> MB) and if in a zone, they could give you root access. >> >> Dave >> > > We modify the runpaths of the final binaries to achieve this results. It is > done the same way with nearly all of our packages. > > There is a few way of doing this but the most reliable one is as follow : > > Define the LD_OPTIONS env variable before building gcc and use it to add the > correct runtime path. > > for example a typical blastwave build would have at a minimum : > > export LD_OPTIONS='-R/opt/csw/lib' > > In this case the final shared libraries will contain runtime search paths to > find stuff in /opt/csw/lib. Now there is a catch though if you want to build a > multilib gcc for the gcc build you should use : > > export LD_OPTIONS='-R/opt/csw/lib/$ISALIST' > > In this case the libraries will be able to search for 64 or 32 bit libs > accordingly. > > Hope this help, > > Jonathan Blanchard > > Yes, thank you. That is helpful. How do you produce the $ISALIST? Is that simply sparcv9 on a modern SPARC and amd64 on an Open Solaris system, or is it a list. If the latter, how do you every it. drkir...@hawk:~$ isalist amd64 pentium_pro+mmx pentium_pro pentium+mmx pentium i486 i386 i86 Do I need xport LD_OPTIONS='-R/opt/csw/lib/amd64 -R opt/csw/lib/pentium_pro+mmx etc" ? I doubt it, but I'm not sure what you mean there. Is it just this, or anything else I need to do? You say "typical blastwave build would have at a minimum .." but I doubt you would consider gcc a "typical blastwave build" If there are further complications, can you let me know what they are. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36481
[Bug c/42753] _Complex_I is reported as undeclared. Code builds with Sun compiler.
--- Comment #3 from david dot kirkby at onetel dot net 2010-01-15 09:27 --- I discovered the bug first on a Sun Blade 2000 running Solaris 10 while building the Sage maths software. http://www.sagemath.org/ A test case was created by Robert Bradshaw. The attached header file was generated on a Sun T5240. If necessary, access can be arranged for a serious developer to the system, but it has failed on every Solaris system tested on, including Open Solaris x86 systems, so I assume you will be able to verify it easily. But if not, I can create an account on the T5240. -- david dot kirkby at onetel dot net changed: What|Removed |Added CC||david dot kirkby at onetel ||dot net Known to fail||3.4.3 4.4.1 Summary|_Complex_I is reported as |_Complex_I is reported as |undeclared. Code builds with|undeclared. Code builds with |Sun compiler. |Sun compiler. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42753
[Bug c/42753] _Complex_I is reported as undeclared. Code builds with Sun compiler.
--- Comment #2 from david dot kirkby at onetel dot net 2010-01-15 09:19 --- Created an attachment (id=19605) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19605&action=view) Preprocessed header -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42753
[Bug c/42753] _Complex_I is reported as undeclared. Code builds with Sun compiler.
--- Comment #1 from david dot kirkby at onetel dot net 2010-01-15 09:18 --- Created an attachment (id=19604) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19604&action=view) C source code that generates error -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42753
[Bug c/42753] New: _Complex_I is reported as undeclared. Code builds with Sun compiler.
st);
extern int vsscanf(const char *restrict, const char *restrict,
__va_list);
# 68 "/usr/include/iso/stdio_c99.h" 3 4
extern int snprintf(char *restrict, size_t, const char *restrict,
...);
extern int vsnprintf(char *restrict, size_t, const char *restrict,
__va_list);
# 137 "/usr/include/stdio.h" 2 3 4
# 198 "/usr/include/stdio.h" 3 4
extern unsigned char _sibuf[], _sobuf[];
# 230 "/usr/include/stdio.h" 3 4
extern unsigned char *_bufendtab[];
extern FILE *_lastbuf;
# 2 "simple_complex.c" 2
# 1 "/usr/include/complex.h" 1 3 4
# 9 "/usr/include/complex.h" 3 4
#pragma ident "@(#)complex.h1.9 04/10/23 SMI"
# 24 "/usr/include/complex.h" 3 4
extern float cabsf(float _Complex);
extern float cargf(float _Complex);
extern float cimagf(float _Complex);
extern float crealf(float _Complex);
extern float _Complex cacosf(float _Complex);
extern float _Complex cacoshf(float _Complex);
extern float _Complex casinf(float _Complex);
extern float _Complex casinhf(float _Complex);
extern float _Complex catanf(float _Complex);
extern float _Complex catanhf(float _Complex);
extern float _Complex ccosf(float _Complex);
extern float _Complex ccoshf(float _Complex);
extern float _Complex cexpf(float _Complex);
extern float _Complex clogf(float _Complex);
extern float _Complex conjf(float _Complex);
extern float _Complex cpowf(float _Complex, float _Complex);
extern float _Complex cprojf(float _Complex);
extern float _Complex csinf(float _Complex);
extern float _Complex csinhf(float _Complex);
extern float _Complex csqrtf(float _Complex);
extern float _Complex ctanf(float _Complex);
extern float _Complex ctanhf(float _Complex);
extern double cabs(double _Complex);
extern double carg(double _Complex);
extern double cimag(double _Complex);
extern double creal(double _Complex);
extern double _Complex cacos(double _Complex);
extern double _Complex cacosh(double _Complex);
extern double _Complex casin(double _Complex);
extern double _Complex casinh(double _Complex);
extern double _Complex catan(double _Complex);
extern double _Complex catanh(double _Complex);
extern double _Complex ccos(double _Complex);
extern double _Complex ccosh(double _Complex);
extern double _Complex cexp(double _Complex);
# 61 "/usr/include/complex.h" 3 4
#pragma redefine_extname clog __clog
# 61 "/usr/include/complex.h" 3 4
extern double _Complex clog(double _Complex);
extern double _Complex conj(double _Complex);
extern double _Complex cpow(double _Complex, double _Complex);
extern double _Complex cproj(double _Complex);
extern double _Complex csin(double _Complex);
extern double _Complex csinh(double _Complex);
extern double _Complex csqrt(double _Complex);
extern double _Complex ctan(double _Complex);
extern double _Complex ctanh(double _Complex);
extern long double cabsl(long double _Complex);
extern long double cargl(long double _Complex);
extern long double cimagl(long double _Complex);
extern long double creall(long double _Complex);
extern long double _Complex cacoshl(long double _Complex);
extern long double _Complex cacosl(long double _Complex);
extern long double _Complex casinhl(long double _Complex);
extern long double _Complex casinl(long double _Complex);
extern long double _Complex catanhl(long double _Complex);
extern long double _Complex catanl(long double _Complex);
extern long double _Complex ccoshl(long double _Complex);
extern long double _Complex ccosl(long double _Complex);
extern long double _Complex cexpl(long double _Complex);
extern long double _Complex clogl(long double _Complex);
extern long double _Complex conjl(long double _Complex);
extern long double _Complex cpowl(long double _Complex, long double _Complex);
extern long double _Complex cprojl(long double _Complex);
extern long double _Complex csinhl(long double _Complex);
extern long double _Complex csinl(long double _Complex);
extern long double _Complex csqrtl(long double _Complex);
extern long double _Complex ctanhl(long double _Complex);
extern long double _Complex ctanl(long double _Complex);
# 3 "simple_complex.c" 2
# 12 "simple_complex.c"
typedef double _Complex __pyx_t_double_complex;
static __pyx_t_double_complex __pyx_t_double_complex_from_parts(double x,
double y) {
return x + y*(__pyx_t_double_complex)_Complex_I;
}
# 32 "simple_complex.c"
int main(int argc, char** argv) {
printf("CYTHON_CCOMPLEX %d\n", 1);
return 0;
}
--
Summary: _Complex_I is reported as undeclared. Code builds with
Sun compiler.
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: david dot kirkby at onetel dot net
GCC build triplet: Sun SPARC Enterprise T5240 Server running Solaris 10
05/2009
GCC host triplet: Sun SPARC Enterprise T5240 Server running Solaris 10
05/2009
GCC target triplet: Sun SPARC Enterprise T5240 Server running Solaris 10
05/2009
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42753
[Bug bootstrap/36481] gcc fails to build on Solaris x86 - it forgets the locations of libmpfr
--- Comment #14 from david dot kirkby at onetel dot net 2010-01-15 04:44 --- (In reply to comment #10) > In reply to #9: > > I have tried to build gcc with and without my own patch on our solaris > machines. While both of them fails they fail at the same place (namely > configuration of [arch]/libgcc trying to figure out the object suffix). They It would be good if a patch similar to yours will work, so alloing gcc to be installed in an arbitrary location and used without setting LD_LIBRARY_PATH. The fact is, a lot of people using Solaris do not have root access, so using crle is not an option. It should be noted, gcc binaries from Blastwave install in a non standard location (/opt/csw) and do run without the user having to set LD_LIBRARY_PATH. Of course, you need root acces to install them, but they do *not* modify the linker search path with crle, but work without doing that. Despite asking a couple of times, I've never managed to get an answer how the Blastwave binaries achieve this. I'd like a pound (I'm English) for every time I have seen this issue raised on Solaris forums. It is something wanted by many, but I believe the gcc developers do not feel is necessary. Some have told be /usr/local is "a standard" though it's not a "standard" reconised by any official body, like ISO, IEEE etc. But normal users cant write there either. PS, you could always ask your uni system admins if they would set you up in a Solaris 10 zone. The memory overhead of a zone is quite small (well under 100 MB) and if in a zone, they could give you root access. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36481
[Bug bootstrap/41899] New: gcc fails to build on OpenSolaris, as gcc uses non-standard option to 'find'
799/ POSIX standards, and see no mention of a -path option. Is this a GNUism that has slipped though the net? Is there any chance of it being removed, so making the gcc more portable? GCC is never easy to build on Solaris, but it will be more difficult if non-POSIX options are used to standard commands. PS, I'm never sure what is meant by the host/target/build triplet, but I guess you know what I mean here. I'm not cross-compiling. PPS, Since 'gcc' is used in the Sage maths project, if a *serious* gcc developer wants access to Sun hardware (both SPARC and x86), I can arrange this. Drop me a private email, telling me your role in gcc development. Dave -- Summary: gcc fails to build on OpenSolaris, as gcc uses non- standard option to 'find' Product: gcc Version: 4.4.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: david dot kirkby at onetel dot net GCC build triplet: SunOS hawk 5.11 snv_111b i86pc i386 i86pc GCC host triplet: SunOS hawk 5.11 snv_111b i86pc i386 i86pc GCC target triplet: SunOS hawk 5.11 snv_111b i86pc i386 i86pc http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41899
[Bug target/40757] gcc 4.4.0 miscompiles mpfr-2.4.1
--- Comment #26 from david dot kirkby at onetel dot net 2009-10-01 08:34 --- I should have added this some time back, but Sun have confirmed this is a bug. I should have a IDR from Sun myself in a couple of weeks, and a patch will be on sunsolve some time after that. It will be fixed in Solaris 10 update 8. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40757
[Bug fortran/41080] gfortran -dumpversion does not behave like gcc or g++
--- Comment #2 from david dot kirkby at onetel dot net 2009-08-15 20:10 --- Thank you. Does this mean the next version of gcc will support this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41080
[Bug fortran/41080] New: gfortran -dumpversion does not behave like gcc or g++
The 'dumpversion' option of gcc and g++ show just the version number, which is useful. The same is not true of gfortran, which shows a lot of other information, making getting the version more difficult drkir...@smudge:[~] $ g++ -dumpversion 4.4.1 drkir...@smudge:[~] $ gcc -dumpversion 4.4.1 drkir...@smudge:[~] $ gfortran -dumpversion GNU Fortran (GCC) 4.4.1 Copyright (C) 2009 Free Software Foundation, Inc. GNU Fortran comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of GNU Fortran under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING -- Summary: gfortran -dumpversion does not behave like gcc or g++ Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: david dot kirkby at onetel dot net GCC build triplet: Solaris 10 update 7 on Sun Ultra 80 GCC host triplet: Solaris 10 update 7 on Sun Ultra 80 GCC target triplet: Solairs 10 update 7 on Sun Ultra 80 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41080
[Bug c/40757] gcc 4.4.0 miscompiles mpfr-2.4.1
--- Comment #25 from david dot kirkby at onetel dot net 2009-07-18 19:33 --- (In reply to comment #24) > I should have added, the core dumps were observed on gcc versions > > 3.4.3 > 4.2.4 > 4.4.0 > 4.4.1 20090715 (prerelease) > > on the Sun T5240 with it's T2+ processors. > > The success on the Sun Blade 2000 was only tried with gcc 3.4.4 and 4.4.0. > > To me at least, that does rather point the finger at Solaris's memset(). > >From what I now understand of this, it does indeed indicate a bug in the memset() implementation on Solaris for this particular machine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40757
[Bug c/40757] gcc 4.4.0 miscompiles mpfr-2.4.1
--- Comment #24 from david dot kirkby at onetel dot net 2009-07-18 14:44 --- I should have added, the core dumps were observed on gcc versions 3.4.3 4.2.4 4.4.0 4.4.1 20090715 (prerelease) on the Sun T5240 with it's T2+ processors. The success on the Sun Blade 2000 was only tried with gcc 3.4.4 and 4.4.0. To me at least, that does rather point the finger at Solaris's memset(). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40757
[Bug c/40757] gcc 4.4.0 miscompiles mpfr-2.4.1
--- Comment #23 from david dot kirkby at onetel dot net 2009-07-18 14:36
---
(In reply to comment #22)
> (In reply to comment #20)
> > buf[n] = 6;
> > memset (buf+n, 0, i + j);
> > if (buf[0] != 6)
>
> It looks like you forgot to replace the second buf[0] by buf[n].
>
Sorry, my mistake. This is the current code and it does show something
intersting.
drkir...@kestrel:[~] $ cat check2.c
#include
typedef __SIZE_TYPE__ size_t;
extern void *memset (void *, const void *, size_t);
extern void abort (void);
volatile size_t i = 0x8000U, j = 0x8000U;
char buf[16];
int main (void)
{
int n;
for (n=0 ; n <=10;++n) {
printf("n=%d\n",n);
if (sizeof (size_t) != 4)
return 0;
buf[n] = 6;
memset (buf+n, 0, i + j);
if (buf[n] != 6)
abort ();
}
return 0;
}
On the machine with the T2+ processor, which fails the mpfr tests:
kir...@t2:[~] $ gcc -Wall check2.c
check2.c: In function 'main':
check2.c:17: warning: null argument where non-null required (argument 2)
kir...@t2:[~] $ ./a.out
n=0
n=1
Abort (core dumped)
I tried with the Sun compiler too, but that refuses to compile the code.
kir...@t2:[~] $ /opt/SUNWspro/bin/cc check2.c
"check2.c", line 2: warning: no explicit type given
"check2.c", line 2: syntax error before or at: size_t
"check2.c", line 2: warning: useless declaration
cc: acomp failed for check2.c
However, when I went back and took away all the loop stuff and dropped it to
the bare minimum.
kir...@t2:[~] $ cat check3.c
typedef __SIZE_TYPE__ size_t;
extern void *memset (void *, const void *, size_t);
extern void abort (void);
volatile size_t i = 0x8000U, j = 0x8000U;
char buf[16];
int main (void)
{
if (sizeof (size_t) != 4)
return 0;
buf[1] = 6;
memset (buf+1, 0, i + j);
if (buf[1] != 6)
abort ();
return 0;
}
then it does not dump core.
kir...@t2:[~] $ gcc check3.c
kir...@t2:[~] $ ./a.out
kir...@t2:[~] $
In fact, trying a few small values manually, without the loop, causes no
problem.
I also tried it on my own personal machine, a Sun Blade 2000 with the sun4u
architecture (unlike the T5240 with it's T2+ processors, which is sun4v).
drkir...@kestrel:[~] $ ./a.out
n=0
n=1
n=2
n=3
n=4
n=5
n=6
n=7
n=8
n=9
n=10
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40757
[Bug c/40757] gcc 4.4.0 miscompiles mpfr-2.4.1
--- Comment #21 from david dot kirkby at onetel dot net 2009-07-18 01:18
---
(In reply to comment #20)
> (In reply to comment #19)
> > (In reply to comment #18)
> > > I've compiled and linked that code. It does not abort.
> >
> > Bad point for this theory :-(
> > The result could still depend on the alignment of the pointer, so you could
> > try
> > replacing buf[0] by buf[4] and calling memset(buf+4,...) (try several small
> > values instead of 4).
> >
>
> I tried this in a loop. It still works, with no abort.
>
>
> typedef __SIZE_TYPE__ size_t;
> extern void *memset (void *, const void *, size_t);
> extern void abort (void);
> volatile size_t i = 0x8000U, j = 0x8000U;
> char buf[16];
>
> int main (void)
> {
> int n;
>
> for (n=0 ; n <=64;++n) {
> if (sizeof (size_t) != 4)
> return 0;
> buf[n] = 6;
> memset (buf+n, 0, i + j);
> if (buf[0] != 6)
> abort ();
> }
> return 0;
> }
>
> I extended 'n' to larger values and find it does abort when it is 5592, but
> not
> exactly the 'small' value you were looking for.
>
Looking closely, you only declared allocated 16 bytes for the buffer, so it was
hardly surprising it aborted at large n. When I increased the buffer size, so
it worked as expected, even for n as large as 1
dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40757
[Bug c/40757] gcc 4.4.0 miscompiles mpfr-2.4.1
--- Comment #20 from david dot kirkby at onetel dot net 2009-07-18 01:14
---
(In reply to comment #19)
> (In reply to comment #18)
> > I've compiled and linked that code. It does not abort.
>
> Bad point for this theory :-(
> The result could still depend on the alignment of the pointer, so you could
> try
> replacing buf[0] by buf[4] and calling memset(buf+4,...) (try several small
> values instead of 4).
>
I tried this in a loop. It still works, with no abort.
typedef __SIZE_TYPE__ size_t;
extern void *memset (void *, const void *, size_t);
extern void abort (void);
volatile size_t i = 0x8000U, j = 0x8000U;
char buf[16];
int main (void)
{
int n;
for (n=0 ; n <=64;++n) {
if (sizeof (size_t) != 4)
return 0;
buf[n] = 6;
memset (buf+n, 0, i + j);
if (buf[0] != 6)
abort ();
}
return 0;
}
I extended 'n' to larger values and find it does abort when it is 5592, but not
exactly the 'small' value you were looking for.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40757
[Bug c/40757] gcc 4.4.0 miscompiles mpfr-2.4.1
--- Comment #18 from david dot kirkby at onetel dot net 2009-07-17 11:19
---
(In reply to comment #17)
> Try:
> typedef __SIZE_TYPE__ size_t;
> extern void *memset (void *, const void *, size_t);
> extern void abort (void);
> volatile size_t i = 0x8000U, j = 0x8000U;
> char buf[16];
>
> int main (void)
> {
> if (sizeof (size_t) != 4)
> return 0;
> buf[0] = 6;
> memset (buf, 0, i + j);
> if (buf[0] != 6)
> abort ();
> return 0;
> }
> In 32-bit code, size_t is 32-bit, memset is called with buf, 0, 0 arguments,
> but the %o2 register passed to it doesn't contain 0, but 0x1. That is
> fine, this is 32-bit code, so the uppermost bits are always undefined. But
> when 32-bit memset uses brnz %o2, ... instruction, it needs to first
> zero-extend it to 64-bits, as brnz operates on all 64 bits only. Or not use
> brnz, but compare and be %icc, ...
>
I've compiled and linked that code. It does not abort. i.e. I do NOT see:
Abort (core dumped).
In 64-bit mode, it issues a warning:
$ gcc -m64 check.c
check.c:2: warning: conflicting types for built-in function 'memset'
but again builds an executable which exits normally.
If you want the assembler output posted from Tim's preprocessed file, let me
know how to do it and I'll do it, just in case gcc is behaving differently on
this machine to yours.
As I say, if you want an account Jakub, you can have one. Just tell me a user
name. It might be the simplest way for you to look at this.
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40757
[Bug c/40757] gcc 4.4.0 miscompiles mpfr-2.4.1
--- Comment #16 from david dot kirkby at onetel dot net 2009-07-17 04:11 --- (In reply to comment #0) > See http://websympa.loria.fr/wwsympa/arc/mpfr/2009-07/msg00031.html > and the following discussion. > > This was on t2.math.washington.edu with > /usr/local/gcc-4.4.0-sun-linker/bin/gcc: > zimme...@t2:/tmp/mpfr-2.4.1$ /usr/local/gcc-4.4.0-sun-linker/bin/gcc -v > Using built-in specs. > Target: sparc-sun-solaris2.10 > Configured with: /home/kirkby/gcc-4.4.0/configure CC=/usr/sfw/bin/gcc > --prefix=/usr/local/gcc-4.4.0-sun-linker --without-gnu-as --without-gnu-ld > --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld > --enable-languages=c,c++,fortran --with-mpfr-lib=/usr/local/lib > --with-mpfr-include=/usr/local/include --with-gmp-include=/usr/local/include > --with-gmp-lib=/usr/local/lib --with-libiconv-prefix=/usr/lib/iconv > Thread model: posix > gcc version 4.4.0 (GCC) It would be useful if we had an exact statement of the problem, in terms of "memset fails for ..." or whatever. I'd ask a few Sun people to have a look here, and comment, but it's unclear precisely what is believed to be the issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40757
[Bug c/40757] gcc 4.4.0 miscompiles mpfr-2.4.1
--- Comment #15 from david dot kirkby at onetel dot net 2009-07-17 03:21 --- (In reply to comment #14) > > You haven't mentioned what options you compiled this file with. > > the problem appears both with -O0, -O1 and -O2. > > Paul > Also worth noting is that this builds fine with some versions of gcc gcc 4.1.1 OK gcc 4.2.1 OK gcc 4.2.4 OK I could build gcc 4.3.0, but it would never install properly, so I have not tested on gcc 4.3.0. gcc 4.3.1 MPFRfails 20 tests gcc 4.3.3 MPFRfails 20 tests gcc 4.4.0 MPFRfails 20 tests. gcc-4.4.1-RC-20090715 MPFR fails 20 tests -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40757
[Bug c/40757] gcc 4.4.0 miscompiles mpfr-2.4.1
--- Comment #13 from david dot kirkby at onetel dot net 2009-07-16 21:29 --- (In reply to comment #11) > You haven't mentioned what options you compiled this file with. So, assuming > -O2, I see: > add %i4, -1, %l5! n,, tmp186 > sethi %hi(1073740800), %o2!, tmp189 > sll %l5, 2, %l5 ! tmp186,, D.4491 > or %o2, 1023, %o2 ! tmp189,, tmp188 > st %g1, [%i0+%l5] !,* D.4491 > add %i4, %o2, %o2 ! n, tmp188, tmp187 > mov %i0, %o0! a, > sll %o2, 2, %o2 ! tmp187,, > callmemset, 0 !, > mov0, %o1 !, > for this memset call, which looks correct to me. The st %g1, [%i0+%l5] line > stores to %i0 a[n-1] and memset is called with memset (a, 0, (n + 0x3fffU) > << 2); So, if this doesn't work (and you see the same), you hit a bug in > Solaris memset implementation, which doesn't handle properly length with > garbage in upper 32-bits, guess it could use brz,pn %o2, do_nothing or > something similar, which is fine for 64-bit code, but certainly not for 32-bit > code. > I should add we are using the Sun assembler and linker, not the GNU ones. I don't know whether that would effect the output. If so, can you tell me how to generate the assembler code? Or as I say, you can have an account. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40757
[Bug c/40757] gcc 4.4.0 miscompiles mpfr-2.4.1
--- Comment #10 from david dot kirkby at onetel dot net 2009-07-16 12:32 --- (In reply to comment #9) > folding happens even at -O0 and both bugs are in the folder. So, please try > ftp://sources.redhat.com/pub/gcc/snapshots/4.4.1-RC-20090715/ > first. > I tried it. kir...@t2:[/tmp/kirkby/mpfr-2.4.1] $ gcc -v Using built-in specs. Target: sparc-sun-solaris2.10 Configured with: ../gcc-4.4.1-RC-20090715/configure --prefix=/usr/local/gcc-4.4.1-RC-20090715-sun-linker --with-as=/usr/ccs/bin/as --without-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++,fortran --with-mpfr-include=/usr/local/include --with-mpfr-lib=/usr/local/lib --with-gmp-include=/usr/local/include --with-gmp-lib=/usr/local/lib Thread model: posix gcc version 4.4.1 20090715 (prerelease) (GCC) but again got 20 test failures on mpfr 2.4.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40757
[Bug c/40757] gcc 4.4.0 miscompiles mpfr-2.4.1
--- Comment #8 from david dot kirkby at onetel dot net 2009-07-16 10:24 --- (In reply to comment #4) > Sounds a lot like PR39867 and PR40747 are hitting you. Can you grab those > fixes, apply them to your 4.4.0, rebuild it, and test mpfr again? Or get the > 4.4.1-RC and test that instead. > > I just finished building 4.3.4 and 4.4.0 on USIIIi/Solaris 9, and they built > gmp-4.2.4 and mpfr-2.4.1 fine, with both passing make check. I can't see how it is similar to PR39867 and PR40747 only occurs at an optimisation of 1 or higher. This occurs with no optimisation at all. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40757
[Bug c/40757] gcc 4.4.0 miscompiles mpfr-2.4.1
--- Comment #7 from david dot kirkby at onetel dot net 2009-07-16 10:19 --- (In reply to comment #4) > mpfr-2.4.1 compiles and tests Ok for me on an Ultra5 (USIIi) running > sparc64-linux, with gmp-4.2.4 (compiled by gcc-4.3.4) and gcc 4.3.4, 4.4.0, > and > 4.4.1 20090630. > > I don't have a T2, but could possibly do some tests on USIIIi/Solaris 9. > I believe the problem is likely to only be seen on the T2+ or similar processors. Someone noticed the library code in OpenSolaris is different on the T2+ processor to what it would be on a more common SPARC processor. I have built gcc 4.4.0 on Solaris 10 on a Sun Blade 2000 (UltraSPARC II processors) and have no problem with mpfr, but on the T2+ processors of the T5240 server, it does not work. I'll try a later snapshot, but any serious gcc developer would be welcome to an account on the machine where it fails. That does not mean anyone that just happens to be interested and fancies playing on a 16-core machine, but if you are a serious gcc developer, then I could give you an account. Dave -- david dot kirkby at onetel dot net changed: What|Removed |Added CC| |david dot kirkby at onetel | |dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40757
[Bug bootstrap/40572] gcc insistance on using LD_LIBRARY_PATH and ignoring LD_FLAGS
--- Comment #18 from david dot kirkby at onetel dot net 2009-06-28 19:30 --- I have solved this. The key was setting LD_OPTIONS LD_OPTIONS='-L/usr/local/lib -R/usr/local/lib' I suspect that is a Solaris Environment variable, which is useful to the Sun linker I was using, but not to the GNU linker. \\ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40572
[Bug bootstrap/40572] gcc insistance on using LD_LIBRARY_PATH and ignoring LD_FLAGS
--- Comment #17 from david dot kirkby at onetel dot net 2009-06-28 17:17 --- I just realised that: LDFLAGS='-L/usr/local/lib -R/usr/local/lib' BOOT_LDFLAGS='-L/usr/local/lib -R/usr/local/lib' export LDFLAGS export BOOT_LDFLAGS was probably not the best way to do this. I'm not even sure if it is valid or not, which probably explains it this time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40572
[Bug bootstrap/40572] gcc insistance on using LD_LIBRARY_PATH and ignoring LD_FLAGS
--- Comment #16 from david dot kirkby at onetel dot net 2009-06-28 16:55 --- I thought my comments were going to appear before the files were posted, not after it. Anyway, the libraries are in /usr/local/lib, and appear to work, as I can compile and link against them. kir...@t2:[~] $ /usr/sfw/bin/gcc -L/usr/local/lib -R /usr/local/lib -lgmp -lmpfr hello_world.c kir...@t2:[~] $ ldd ./a.out libgmp.so.3 => /usr/local/lib/libgmp.so.3 libmpfr.so.1 => /usr/local/lib/libmpfr.so.1 libc.so.1 => /lib/libc.so.1 libgcc_s.so.1 => /usr/sfw/lib/libgcc_s.so.1 libm.so.2 => /lib/libm.so.2 /platform/SUNW,T5240/lib/libc_psr.so.1 kir...@t2:[~] But a script I used to try to build gcc #!/bin/sh LDFLAGS='-L/usr/local/lib -R/usr/local/lib' BOOT_LDFLAGS='-L/usr/local/lib -R/usr/local/lib' export LDFLAGS export BOOT_LDFLAGS rm -rf gcc-4.4.0-built-with-gcc-3.4.3-ABI32b mkdir gcc-4.4.0-built-with-gcc-3.4.3-ABI32b cd gcc-4.4.0-built-with-gcc-3.4.3-ABI32b /home/kirkby/gcc-4.4.0/configure 'CC=/usr/sfw/bin/gcc' \ --prefix=/usr/local/gcc-4.4.0-sun-linker \ --without-gnu-as \ --without-gnu-ld \ --with-as=/usr/ccs/bin/as \ --with-ld=/usr/ccs/bin/ld \ --enable-languages=c,c++,fortran \ --with-mpfr-lib=/usr/local/lib \ --with-mpfr-include=/usr/local/include \ --with-gmp-include=/usr/local/include \ --with-gmp-lib=/usr/local/lib \ --with-libiconv-prefix=/usr/lib/iconv gmake -j 200 fails, with the logs I just posted. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40572
[Bug bootstrap/40572] gcc insistance on using LD_LIBRARY_PATH and ignoring LD_FLAGS
--- Comment #15 from david dot kirkby at onetel dot net 2009-06-28 16:52 --- Created an attachment (id=18087) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18087&action=view) sparc-sun-solaris2.10/libgcc/config.log with mpfr and gmp libraires in /usr/local/lib. As you will note, the first sort of error message is: ld.so.1: cc1: fatal: libmpfr.so.1: open failed: No such file or directory then later down. configure:2630: error: cannot compute suffix of object files: cannot compile -- david dot kirkby at onetel dot net changed: What|Removed |Added Attachment #18081|0 |1 is obsolete|| Attachment #18082|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40572
[Bug bootstrap/40572] gcc insistance on using LD_LIBRARY_PATH and ignoring LD_FLAGS
--- Comment #14 from david dot kirkby at onetel dot net 2009-06-28 16:49 --- Created an attachment (id=18086) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18086&action=view) Top level config.log, with libraries in /usr/local/lib This is the top level config.log. I'll post the /sparc-sun-solaris2.10/libgcc/config.log in a minute. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40572
[Bug bootstrap/40572] gcc insistance on using LD_LIBRARY_PATH and ignoring LD_FLAGS
--- Comment #11 from david dot kirkby at onetel dot net 2009-06-28 03:51
---
(In reply to comment #3)
> Note that setting LDFLAGS maybe not what you want (it affects stage1 only
> AFAIK), you likely want to set BOOT_LDFLAGS.
FWIW, BOOT_LDFLAGS. that did not solve it either. I think I'll have a go with
'sed' and change /usr/local to somewhere else in the gcc-4.4.0.tar file.
Hopefully that will avoid the need for setting LD library path.
It would be good if the /usr/local thing could be overridden, but sed might
come to my rescuse!
../gcc-4.4.0/configure 'CC=/usr/sfw/bin/gcc' \
--prefix=/usr/local/gcc-4.4.0-Sun-linker-and-assembler-ABI32 \
--without-gnu-as \
--without-gnu-ld \
--with-as=/usr/ccs/bin/as \
--with-ld=/usr/ccs/bin/ld \
--enable-languages=c,c++,fortran \
--with-mpfr=/usr/local/mpfr-2.4.1-gcc-3.4.3-ABI32 \
--with-gmp=/usr/local/gmp-4.3.1-gcc-3.4.3-ABI32 \
--with-libiconv-prefix=/usr/lib/iconv \
BOOT_LDFLAGS='-R
/usr/local/mpfr-2.4.1-gcc-3.4.3-ABI32/lib:/usr/local/gmp-4.3.1-gcc-3.4.3-ABI32/lib
-L
/usr/local/mpfr-2.4.1-gcc-3.4.3-ABI32/lib:/usr/local/gmp-4.3.1-gcc-3.4.3-ABI32/lib'
\
LDFLAGS='-R
/usr/local/mpfr-2.4.1-gcc-3.4.3-ABI32/lib:/usr/local/gmp-4.3.1-gcc-3.4.3-ABI32/lib
-L
/usr/local/mpfr-2.4.1-gcc-3.4.3-ABI32/lib:/usr/local/gmp-4.3.1-gcc-3.4.3-ABI32/lib'
It later failed with
-DHAVE_CONFIG_H -I. -I. -I../../gcc-4.4.0/gcc -I../../gcc-4.4.0/gcc/.
-I../../gcc-4.4.0/gcc/../include -I./../intl
-I../../gcc-4.4.0/gcc/../libcpp/include
-I/usr/local/gmp-4.3.1-gcc-3.4.3-ABI32/include
-I/usr/local/mpfr-2.4.1-gcc-3.4.3-ABI32/include
-I../../gcc-4.4.0/gcc/../libdecnumber -I../../gcc-4.4.0/gcc/../libdecnumber/dpd
-I../libdecnumber\
-DSTANDARD_STARTFILE_PREFIX=\"../../../\"
-DSTANDARD_EXEC_PREFIX=\"/usr/local/gcc-4.4.0-Sun-linker-and-assembler-ABI32/lib/gcc/\"
-DSTANDARD_LIBEXEC_PREFIX=\"/usr/local/gcc-4.4.0-Sun-linker-and-assembler-ABI32/libexec/gcc/\"
-DDEFAULT_TARGET_VERSION=\"4.4.0\"
-DDEFAULT_TARGET_MACHINE=\"sparc-sun-solaris2.10\"
-DSTANDARD_BINDIR_PREFIX=\"/usr/local/gcc-4.4.0-Sun-linker-and-assembler-ABI32/bin/\"
-DTOOLDIR_BASE_PREFIX=\"../../../../\" `test "X${SHLIB_LINK}" = "X" || test
"yes" != "yes" || echo "-DENABLE_SHARED_LIBGCC"` \
-c ../../gcc-4.4.0/gcc/gcc.c -o gcc.o)
In file included from ../../gcc-4.4.0/gcc/gcc.c:73:
./multilib.h:21: error: expected '=', ',', ';', 'asm' or '__attribute__' before
':' token
gmake[3]: *** [gcc.o] Error 1
gmake[3]: Leaving directory
`/home/kirkby/gcc-4.4.0-built-with-gcc-3.4.3-ABI32/gcc'
gmake[2]: *** [all-stage2-gcc] Error 2
gmake[2]: Leaving directory `/home/kirkby/gcc-4.4.0-built-with-gcc-3.4.3-ABI32'
gmake[1]: *** [stage2-bubble] Error 2
gmake[1]: Leaving directory `/home/kirkby/gcc-4.4.0-built-with-gcc-3.4.3-ABI32'
gmake: *** [all] Error 2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40572
[Bug bootstrap/40572] gcc insistance on using LD_LIBRARY_PATH and ignoring LD_FLAGS
--- Comment #8 from david dot kirkby at onetel dot net 2009-06-27 22:57 --- It looks as though we will have to agree to differ about the LD_LIBRARY_PATH being the right way to do things. But do you not agree that this probably should be found at an earlier stage in the build process? If so, could you at least fix that, so other people don't want so much time over this problem. If you Google for it, you will find there are thousands of references to this. -- david dot kirkby at onetel dot net changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40572
[Bug bootstrap/40572] gcc insistance on using LD_LIBRARY_PATH and ignoring LD_FLAGS
--- Comment #7 from david dot kirkby at onetel dot net 2009-06-27 22:31 --- (In reply to comment #6) > LD_LIBRARY_PATH is for the runtime linker/loader so it is needed as you are > running programs which use shared libraries stored in a "non standard" place. > So is any user who uses the compiler going to need to set LD_LIBRARY_PATH ? That would seem crazy if that is true. I don't need to set LD_LIBRARY_PATH on my Sun to use the gcc from Blastwave, which resides in /opt/csw/bin/gcc or the one which Sun ship which resides in /usr/sfw/bin. It is impossible for me to create a gcc-4.4.0 which links to libraries in locations I chose, without users having to set LD_LIBRARY_PATH? It is not possible to specify the locations of the libraries? I thought options like: --with-mpfr-lib=PATHspecify directory for the installed MPFR library were supposed to override the default /usr/local/lib. In some ways, an option like --ignore-usr-local would be nice on LOTS of programs. The trouble with the 'standard' /usr/local is that it tends to accumulate a lot of rubbish. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40572
[Bug bootstrap/40572] gcc insistance on using LD_LIBRARY_PATH and ignoring LD_FLAGS
--- Comment #5 from david dot kirkby at onetel dot net 2009-06-27 21:00 --- (In reply to comment #3) > Note that setting LDFLAGS maybe not what you want (it affects stage1 only > AFAIK), you likely want to set BOOT_LDFLAGS. Sorry, forget to comment on that. I'll try that. I would have thought if one set a standard option to the linker like -R, it would have propagated, but I'll try that. It stills seems a bug to me though. This probably should be detected much earlier. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40572
[Bug bootstrap/40572] gcc insistance on using LD_LIBRARY_PATH and ignoring LD_FLAGS
--- Comment #4 from david dot kirkby at onetel dot net 2009-06-27 20:57 --- (In reply to comment #3) > What is the LDFLAGS supposed to do? Is it supposed to adjust the run-path of > the built executables to find the mpfr/gmp libraries to not need > LD_LIBRARY_PATH > set? > > Note that setting LDFLAGS maybe not what you want (it affects stage1 only > AFAIK), you likely want to set BOOT_LDFLAGS. > > $ ../gcc-4.4.0/configure CC=/usr/sfw/bin/gcc > --prefix=/usr/local/gcc-4.4.0-Sun-linker-and-assembler-ABI32 > --with-as=/usr/ccs/bin/as --without-gnu-as --with-ld=/usr/ccs/bin/ld > --without-gnu-ld --enable-languages=c,c++,fortran > --with-mpfr=/usr/local/mpfr-2.4.1-gcc-3.4.3-ABI32 > --with-gmp=/usr/local/gmp-4.3.1-gcc-3.4.3-ABI32/ > --with-libiconv-prefix=/usr/lib/iconv LDFLAGS=-R > /usr/local/mpfr-2.4.1-gcc-3.4.3-ABI32/lib:/usr/local/gmp-4.3.1-gcc-3.4.3-ABI32/lib > -L > /usr/local/mpfr-2.4.1-gcc-3.4.3-ABI32/lib:/usr/local/gmp-4.3.1-gcc-3.4.3-ABI32/lib > LD_LIBRARY_PATH should be used as a last resort - not the first resort. But it is surely crazy for the configure script to look for the libraries and header files, then two hours later the build fails since the location of a library, which was previously check for, is now forgotten. Does that not seem a bit illogical? If I've specified the location of the library in a way the configure script accepts, AND specified -L option to the linker, why can't the linker find it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40572
[Bug bootstrap/40572] gcc insistance on using LD_LIBRARY_PATH and ignoring LD_FLAGS
--- Comment #2 from david dot kirkby at onetel dot net 2009-06-27 20:29 --- Created an attachment (id=18082) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18082&action=view) sparc-sun-solaris2.10/libgcc/config.log This is the file, which shows it can't find the library, a couple of hours after the configure script finds it. VERY annoying. PLEASE PLEASE fix this. It hits a lot of people - I'm far from the only one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40572
[Bug bootstrap/40572] gcc insistance on using LD_LIBRARY_PATH and ignoring LD_FLAGS
--- Comment #1 from david dot kirkby at onetel dot net 2009-06-27 20:25 --- Created an attachment (id=18081) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18081&action=view) Top level config.log -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40572
[Bug bootstrap/40572] New: gcc insistance on using LD_LIBRARY_PATH and ignoring LD_FLAGS
I've tried my hardest to build gcc without resorting to the use of LD_LIBRARY_PATH. I simply can't understand why if LD_FLAGS is set to the path of the mpfr library, the compiler can't use them. My compile bombs out with the well known error: error: cannot compute suffix of object files: cannot compile after trying to build it for a couple of hours. A read of $BUILD_DIRECOTRYsparc-sun-solaris2.10/libgcc/config.log shows the real reason is that the compiler can't find the mpfr library. ld.so.1: cc1: fatal: libmpfr.so.1: open failed: No such file or directory But I've specified in three ways where to look for this library. 1) Use of -L 2) Use of -R 3) Use of the configure flag --with-mpfr= I've seen others report the same failure (cannot compute suffix of object files) - see for example http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35693 but it gets closed as 'invalid'. Given gcc finds the library during the initial configure stage, spends two hours compiling (making two copies of xgcc), then to bomb out since it can't find the library seems crazy. So I decided to set LD_LIBRARY_PATH (against my better judgement), but the build would not proceed. However, I expect it will if I set it first, then rebuild. Personally I think there are three things wrong here, that should be fixed, but do doubt the bug will be closed as invalid. 1) Don't expect people to use LD_LIBRARY_PATH 2) Check the location of the libraries in the configure script, so people don't waste two hours building, only to find the library is not found. 3) Respect the option --with-mpfr= 4) Respect LD_FLAGS I expect this will be closed as invalid, so you will still get people (especially on Solaris) finding this odd error. Clearly the configure script found the libraries in a way specified by the options - perhaps the compiler should not forget them a couple of hours later. I note a note by Brian Dessent on bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35693 (reported against 4.3), that the top level configure script should pick this up earlier, not when it comes to run state 1 xgcc for the first time. I can't actually understand why it wont even I will both config.log and sparc-sun-solaris2.10/libgcc/config.log in the hope someone might actually fix this bug, rather than dismiss it. -- Summary: gcc insistance on using LD_LIBRARY_PATH and ignoring LD_FLAGS Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: david dot kirkby at onetel dot net GCC build triplet: Sun T5240 Solaris 10 update 4 GCC host triplet: Sun T5240 Solaris 10 update 4 GCC target triplet: Sun T5240 Solaris 10 update 4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40572
[Bug target/40524] gcc 4.4.0 failure of: e1 ? e2 : e3 on Solaris (several machines, all configured differently)
--- Comment #5 from david dot kirkby at onetel dot net 2009-06-23 00:04
---
Thinking about this more, why should it matter if the type being printed is of
a smaller size than the print statement. This clearly works ok,
drkir...@kestrel:[~] $ cat test2.c
#include
int main() {
printf ("%lu\n",2);
}
drkir...@kestrel:[~] $ gcc test2.c
drkir...@kestrel:[~] $ ./a.out
2
The other point I forgot to mention is that the output of the first test
program changes if the code is compiled as 64-bit.
drkir...@kestrel:[~] $ gcc -m64 test.c
drkir...@kestrel:[~] $ ./a.out
9223372036854775808
2
drkir...@kestrel:[~] $ gcc -m32 test.c
drkir...@kestrel:[~] $ ./a.out
2147483648
2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40524
[Bug target/40524] gcc 4.4.0 failure of: e1 ? e2 : e3 on Solaris (several machines, all configured differently)
--- Comment #4 from david dot kirkby at onetel dot net 2009-06-22 23:56 --- i take you point, but I'm still puzzled why the two print statements should be different. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40524
[Bug target/40524] gcc 4.4.0 failure of: e1 ? e2 : e3 on Solaris (several machines, all configured differently)
--- Comment #3 from david dot kirkby at onetel dot net 2009-06-22 23:52 --- Created an attachment (id=18052) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18052&action=view) config.log from a 16-core Sun T5240 This is config.log from the Sun T5240, which was configured to use the GNU assembler and linker. This is a dual processor machine, with each processor having 8 cores, so the machine has 16 cores. 32 GB RAM kir...@t2:[~/build-gcc-4.4.0] $ cat /etc/release Solaris 10 8/07 s10s_u4wos_12b SPARC Copyright 2007 Sun Microsystems, Inc. All Rights Reserved. Use is subject to license terms. Assembled 16 August 2007 kir...@t2:[~/build-gcc-4.4.0] $ uname -a SunOS t2 5.10 Generic_127111-09 sun4v sparc SUNW,T5240 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40524
[Bug target/40524] gcc 4.4.0 failure of: e1 ? e2 : e3 on Solaris (several machines, all configured differently)
--- Comment #2 from david dot kirkby at onetel dot net 2009-06-22 23:42 --- Created an attachment (id=18051) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18051&action=view) config.log from the Sun Blade 2000 This is the config.log that was generated on the Sun Blade 2000. gcc 4.4.0 was compiled with the aid of the compiler shipped by Sun, gcc version 3.4.3 in /usr/sfw/bin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40524
[Bug c/40524] New: gcc 4.4.0 failure of: e1 ? e2 : e3 on Solaris (several machines, all configured differently)
One of the MPFR developers sent me this test program, which I've called test.c
You would expect both print statements to be the same, as exactly the same
things are being compared, but in fact the output is different with gcc-4.4.0
on Solaris to that with other versions of gcc.
drkir...@kestrel:[~] $ cat test.c
#include
#include
int main (void) {
long int exp = LONG_MIN;
printf ("%lu\n", (exp < (long int) 2 ? 2 : (unsigned long int) exp));
printf ("%lu\n", (exp < (long int) 2 ? 2 : 3));
return 0;
}
drkir...@kestrel:[~] $ gcc test.c
drkir...@kestrel:[~] $ ./a.out
2147483648
2
The code works as expected with gcc 3.4.3 on both SPARC machines, and gcc 4.3.2
on the other machine.
drkir...@kestrel:[~] $ /usr/sfw/bin/gcc test.c
drkir...@kestrel:[~] $ ./a.out
2
2
The failure appears on 3 different machines - two are SPARC based Suns, and
another is an x_64 machine, which was probably running Solaris, but I can't
confirm that yet.
1) A Sun Blade 2000, running Solaris 10 update 6, where gcc was configured to
use the Sun linker and assembler.
drkir...@kestrel:[~] $ uname -a
SunOS kestrel 5.10 Generic_139555-08 sun4u sparc SUNW,Sun-Blade-1000
drkir...@kestrel:[~] $ gcc -v
Using built-in specs.
Target: sparc-sun-solaris2.10
Configured with: ../gcc-4.4.0/configure CC=/usr/sfw/bin/gcc
--prefix=/export/home/drkirkby/install-gcc-4.4.0-Sun-as-ld
--with-as=/usr/ccs/bin/as --without-gnu-as --with-ld=/usr/ccs/bin/ld
--without-gnu-ld --enable-languages=c,c++,fortran
--with-mpfr-include=/export/home/drkirkby/install-mpfr-2.3.1/include
--with-mpfr-lib=/export/home/drkirkby/install-mpfr-2.3.1/lib
--with-gmp-include=/export/home/drkirkby/install-gmp-4.3.1/include
--with-gmp-lib=/export/home/drkirkby/install-gmp-4.3.1/lib
--with-libiconv-prefix=/usr/local
Thread model: posix
gcc version 4.4.0 (GCC)
2) A Sun T5240 where gcc was configured to use the GNU linker and assembler.
(bintuils 2.19.1)
kir...@t2:[~] $ uname -a
SunOS t2 5.10 Generic_127111-09 sun4v sparc SUNW,T5240
kir...@t2:[~] $ gcc -v
Using built-in specs.
Target: sparc-sun-solaris2.10
Configured with: ../gcc-4.4.0/configure --with-gnu-as
--with-as=/home/kirkby/bin/as --with-gnu-ld --with-ld=/home/kirkby/bin/ld
--with-gmp=/home/kirkby/dependencies/ --with-mpfr=/home/kirkby/dependencies/
--enable-languages=c,c++,fortran --prefix=/home/kirkby/dependencies/
Thread model: posix
gcc version 4.4.0 (GCC)
3) A 64-bit machine, which I *think* was running Solaris, but I've no idea
exactly what version, or how gcc was compiled.
--
Summary: gcc 4.4.0 failure of: e1 ? e2 : e3 on Solaris (several
machines, all configured differently)
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: david dot kirkby at onetel dot net
GCC build triplet: SunOS kestrel 5.10 Generic_139555-08 sun4u sparc
SUNW,Sun-Blade-
GCC host triplet: SunOS kestrel 5.10 Generic_139555-08 sun4u sparc
SUNW,Sun-Blade-
GCC target triplet: SunOS kestrel 5.10 Generic_139555-08 sun4u sparc
SUNW,Sun-Blade-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40524
[Bug bootstrap/40504] Configure make a makefile, despite saying: "mpfr.h... buggy but acceptable"
--- Comment #2 from david dot kirkby at onetel dot net 2009-06-20 17:47 --- OK, i take your point - I should have taken more notice of the actual error message. It would be sensible to give some advice to the user, like what would not be a less buggy version. If possible, it would be useful if the versions of gmp and mprf are reported too. I have soemtimes spent ages trying to work out where i have different versions. I think it is the fact that there are some gmp libraries installed by Sun in /usr/lib. -- david dot kirkby at onetel dot net changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40504
[Bug bootstrap/40504] New: Configure make a makefile, despite saying: "mpfr.h... buggy but acceptable"
I doubt the following configure options were optimal, as I'd simuply cut/hasted
from another machine. However, what I find odd is that the configure script
determined says "
checking how to compare bootstrapped objects... cmp $$f1 $$f2 16 16
checking for correct version of gmp.h... yes
checking for correct version of mpfr.h... buggy but acceptable
Given the configure script has determined that mpfr.h is buggy, it should at
least
1) Exit, with an error
2) Print a message such as "This will not be used, mpfr.h from gcc will be used
instead'
Simply to report something is buggy and unaccesptable, then continue as nothing
had happened seems unwise.
../gcc-4.4.0/configure --without-gnu-as --with-as=/usr/ccs/bin/as
--without-gnu-ld --with-ld=/usr/ccs/bin/ld
--with-gmp=/home/kirkby/dependencies/ --with-mpfr=/home/kirkby/dependencies/
--enable-languages=c,c++,fortran --prefix=/home/kirkby/gcc-4.4.0-Sun-Tools/
--with-pkgversion=Built-un-kestrel
The veriosn of gcc used to build attempt to build gcc 4.4.0 was an earlier one.
The configur options to that are:
Target: sparc-sun-solaris2.10
Configured with: ../gcc-4.3.2/configure
--prefix=/home/mabshoff/sparc-solaris-toolchain/
--enable-languages=c,c++,fortran --with-gnu-ld
--with-ld=/home/mabshoff/sparc-solaris-toolchain/bin/ld --with-gnu-as
--with-as=/home/mabshoff/sparc-solaris-toolchain/bin/as
--with-gmp=/usr/local/gmp-4.2.3/sparc-SunOS-gcc-4.3.1-abi32/
--with-mpfr=/usr/local/mpfr-2.3.2/sparc-SunOS-gmp-4.2.3-gcc-4.3.1-abi32/
Thread model: posix
gcc version 4.3.2 (GCC)
But basically, it seems irrelavant what options are compiler are used. If gcc
determines something is unacceptable, it should not continue, and produce a
makefile that at least starts compiling. I did not see if it actually ever
built gcc - that would have been a bit stupid given the error message.
--
Summary: Configure make a makefile, despite saying: "mpfr.h...
buggy but acceptable"
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: david dot kirkby at onetel dot net
GCC build triplet: SunOS kestrel 5.10 Generic_139555-08 sun4u sparc
SUNW,Sun-Blade-
GCC host triplet: SunOS kestrel 5.10 Generic_139555-08 sun4u sparc
SUNW,Sun-Blade-
GCC target triplet: SunOS kestrel 5.10 Generic_139555-08 sun4u sparc
SUNW,Sun-Blade-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40504
[Bug bootstrap/40447] Add a switch to configure to allow *source* directory of mprt and gmp to be specified.
--- Comment #4 from david dot kirkby at onetel dot net 2009-06-15 16:56 --- I assume this is only in your experimental version. I can see that is an improvement. I still think the switch would be useful, but it does reduce the need for it somewhat. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40447
[Bug bootstrap/40447] Add a switch to configure to allow *source* directory of mprt and gmp to be specified.
--- Comment #2 from david dot kirkby at onetel dot net 2009-06-15 16:52 --- That's what I did. The real benefit I see is that someone could see what versions of the gmp and mpfr were used to configure gcc. So if they wanted to build it the same, they would have a much better chance. It would also be quicker to do. I guess it depends on the amount of worked needed to the configure.ac to determine if this is sensible or not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40447
[Bug bootstrap/40447] New: Add a switch to configure to allow *source* directory of mprt and gmp to be specified.
It's currently possible to build gcc in two ways.
1) Compiler and install mpfr and use switches to indicate the location of their
instalation
--with-mpfr=/somedirector --
2) Put directories mpfr and gmp under the source of gcc.
What I propose is to allow a couple of extra switches
--mpfr-source-dir= & --gmp-source-dir=
Apart from making installation easier, it would mean anyone doing a 'gcc -v'
would know what versions of the mpfr and gmp were used.
Dave
--
Summary: Add a switch to configure to allow *source* directory of
mprt and gmp to be specified.
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: david dot kirkby at onetel dot net
GCC build triplet: N/A
GCC host triplet: N/A
GCC target triplet: N/A
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40447
[Bug bootstrap/40360] New: configure: error: cannot compute suffix of object files: cannot compile
First, this bug report is very similar to the closed bug 35693. I could find no
way to re-open that bug report, and in any case this is a different version of
gcc, a different machine etc.
I believe the 'solution' given there, which involves setting LD_LIBRARY_PATH is
not really the right answer, and instead the code should be fixed.
LD_LIBRARY_PATH should be used as a last resort - see for example
'Why LD_LIBRARY_PATH is bad'
http://xahlee.org/UnixResource_dir/_/ldpath.html
'The evil LD_LIBRARY_PATH'
http://www.sunmanagers.org/pipermail/sunmanagers/2002-May/014159.html
gcc has been told the location of the library with switches - it should not
need LD_LIBRARY_PATH set.
This bug comes up time and again. Numerous people find it. Really the code
should be fixed, and not workarounds suggested.
../gcc-4.4.0/configure --with-gnu-as --with-as=/usr/sfw/bin/gas --with-gnu-ld
--with-ld=/usr/sfw/bin/gld
--with-gmp=/usr/local/gmp-4.3.1-Solaris-10-u4-ABI=32-gcc-3.4.3
--with-mpfr=/usr/local/mpfr-2.4.1p5-Solaris-10-u4-gcc-3.4.3
--enable-languages=c,c++,fortran --prefix=/usr/local/gcc-4.4.0
fails with:
checking for sparc-sun-solaris2.10-strip... strip
checking whether ln -s works... yes
checking for sparc-sun-solaris2.10-gcc...
/home/kirkby/build-gcc-4.4.0/./gcc/xgcc -B/home/kirkby/build-gcc-4.4.0/./gcc/
-B/usr/local/gcc-4.4.0/sparc-sun-solaris2.10/bin/
-B/usr/local/gcc-4.4.0/sparc-sun-solaris2.10/lib/ -isystem
/usr/local/gcc-4.4.0/sparc-sun-solaris2.10/include -isystem
/usr/local/gcc-4.4.0/sparc-sun-solaris2.10/sys-include
checking for suffix of object files... configure: error: in
`/home/kirkby/build-gcc-4.4.0/sparc-sun-solaris2.10/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
make[2]: Leaving directory `/home/kirkby/build-gcc-4.4.0'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/home/kirkby/build-gcc-4.4.0'
make: *** [bootstrap] Error 2
--
Summary: configure: error: cannot compute suffix of object files:
cannot compile
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: david dot kirkby at onetel dot net
GCC host triplet: Sun T5240
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40360
[Bug fortran/40358] nternal error: Segmentation Fault (program f951) on Solaris.
--- Comment #2 from david dot kirkby at onetel dot net 2009-06-05 22:10 --- Thanks. On closer inspection, it appears compilation, which was performed on one SPARC and moved to another is broken quite seriously. Ignore this bug report. dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40358
[Bug fortran/40358] New: nternal error: Segmentation Fault (program f951) on Solaris.
The following bit of code generates an internal compiler error on a Sun T5240.
Using the *exact* same binary on a Sun Blade 2000, no internal error is
generated.
kir...@t2:~$ gfortran secondtst.f
gfortran: Internal error: Segmentation Fault (program f951)
Please submit a full bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
Here's the bit of code. I did not write it, and do not even known Fortran well,
so I've no idea if the code is good/bad, but the compiler should not generate
an internal error.
kir...@t2:~$ cat secondtst.f
PROGRAM TEST4
*
* -- LAPACK test routine (version 3.1) --
* Univ. of Tennessee, Univ. of California Berkeley and NAG Ltd..
* November 2006
*
* .. Parameters ..
INTEGERNMAX, ITS
PARAMETER ( NMAX = 100, ITS = 5000 )
* ..
* .. Local Scalars ..
INTEGERI, J
REAL ALPHA, AVG, T1, T2, TNOSEC
* ..
* .. Local Arrays ..
REAL X( NMAX ), Y( NMAX )
* ..
* .. External Functions ..
REAL SECOND
EXTERNAL SECOND
* ..
* .. Intrinsic Functions ..
INTRINSIC REAL
* ..
* .. Executable Statements ..
*
*
* Initialize X and Y
*
DO 10 I = 1, NMAX
X( I ) = REAL( 1 ) / REAL( I )
Y( I ) = REAL( NMAX-I ) / REAL( NMAX )
10 CONTINUE
ALPHA = 0.315
*
* Time 1,000,000 SAXPY operations
*
T1 = SECOND( )
DO 30 J = 1, ITS
DO 20 I = 1, NMAX
Y( I ) = Y( I ) + ALPHA*X( I )
20CONTINUE
ALPHA = -ALPHA
30 CONTINUE
T2 = SECOND( )
WRITE( 6, )T2 - T1
IF( T2-T1.GT.0.0 ) THEN
WRITE( 6, 9998 )1.0 / ( T2-T1 )
ELSE
WRITE( 6, 9994 )
END IF
TNOSEC = T2 - T1
*
* Time 1,000,000 SAXPY operations with SECOND in the outer loop
*
T1 = SECOND( )
DO 50 J = 1, ITS
DO 40 I = 1, NMAX
Y( I ) = Y( I ) + ALPHA*X( I )
40CONTINUE
ALPHA = -ALPHA
T2 = SECOND( )
50 CONTINUE
*
* Compute the time used in milliseconds used by an average call
* to SECOND.
*
WRITE( 6, 9997 )T2 - T1
AVG = ( ( T2-T1 ) - TNOSEC ) * 1000./REAL( ITS )
WRITE( 6, 9996 )AVG
*
* Compute the equivalent number of floating point operations used
* by an average call to SECOND.
*
IF( TNOSEC.GT.0.0 )
$ WRITE( 6, 9995 )1000.*AVG / TNOSEC
*
FORMAT( ' Time for 1,000,000 SAXPY ops = ', G10.3, ' seconds' )
9998 FORMAT( ' SAXPY performance rate= ', G10.3, ' mflops ' )
9997 FORMAT( ' Including SECOND, time= ', G10.3, ' seconds' )
9996 FORMAT( ' Average time for SECOND = ', G10.3,
$ ' milliseconds' )
9995 FORMAT( ' Equivalent floating point ops = ', G10.3, ' ops' )
9994 FORMAT( ' *** Error: Time for operations was zero' )
CALL MYSUB(NMAX,X,Y)
END
SUBROUTINE MYSUB(N,X,Y)
INTEGER N
REAL X(N), Y(N)
RETURN
END
--
Summary: nternal error: Segmentation Fault (program f951) on
Solaris.
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: david dot kirkby at onetel dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40358
[Bug bootstrap/36481] gcc fails to build on Solaris x86 - it forgets the locations of libmpfr
--- Comment #2 from david dot kirkby at onetel dot net 2008-06-10 22:37 --- Subject: Re: gcc fails to build on Solaris x86 - it forgets the locations of libmpfr pinskia at gcc dot gnu dot org wrote: > --- Comment #1 from pinskia at gcc dot gnu dot org 2008-06-10 08:52 > --- > Your configure line should not have LD_LIBRARY_PATH set. > > Also this works for me ... > > > Can you tell me what I should set? Previous versions have worked with far less messing around with flags to configure. If you can suggest a set of flags which will work, I will try that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36481
[Bug c/36481] New: gcc fails to build on Solaris x86 - it forgets the locations of libmpfr
n Solaris x86 - it forgets the
locations of libmpfr
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: david dot kirkby at onetel dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36481
