--- 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
--- 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
--- 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
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
--- 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=19604action=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=19605action=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
--- 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
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=19608action=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=19609action=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:37 ---
Yes
--- 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
--- 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
--- 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
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
--- 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
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
--- 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 #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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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=18086action=view)
Top level config.log, with libraries in /usr/local/lib
This is the top level config.log. I'll post
--- 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=18087action=view)
sparc-sun-solaris2.10/libgcc/config.log with mpfr and gmp libraires in
/usr/local/lib.
As you will note
--- 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 do this. I'm not even
--- 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
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
--- 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=18081action=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=18082action=view)
sparc-sun-solaris2.10/libgcc/config.log
This is the file, which shows it can't find the library, a couple
--- 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
--- 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
--- 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
--- 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 think
: 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
--- 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=18051action=view)
config.log from the Sun Blade 2000
This is the config.log that was generated on the Sun Blade 2000. gcc
--- 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=18052action=view)
config.log from a 16-core Sun T5240
This is config.log from the Sun T5240, which was configured to use
--- 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 stdio.h
int main
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
--- 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
.
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
--- 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
:
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
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
--- 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
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
58 matches
Mail list logo
