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
--- 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
gure: 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
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
G
--- 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 c
--- 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
ity: 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: Sun
--- 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
ured 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: S
--- 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 20
--- 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
--- 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
--- 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
ummary: 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
--- 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
--- 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 libra
--- 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
> se
--- 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 th
--- 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 i
--- 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
--- 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
--- 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'
--- 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 wi
--- 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
--- 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 d
--- 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,
--- 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 2009
--- 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
--- 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.
--- 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
--- 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
--- 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
--- 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 = 0x80
--- 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
--- 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 t
--- 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
--- 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
--- 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
t: 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.or
--- 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
--- 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
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
--- 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
>
x 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)_C
--- 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
--- 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
--- 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
--- 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 ---
&g
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
--- 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
--- 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
--- 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
--- 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
&
--- 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
--- 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:
>
> &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 th
--- 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:
>
>
rsion: 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
--- 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
59 matches
Mail list logo
