--- Comment #3 from rob1weld at aol dot com 2009-02-13 08:36 ---
Here is another person who makes the same complaint (with a patch):
http://hackage.haskell.org/trac/ghc/ticket/2951
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39150
--- Comment #21 from jakub at gcc dot gnu dot org 2009-02-13 09:17 ---
To answer 2), I bet fwprop would suffer the same problem, but fwprop is
disabled at -O1, LICM is not. I can try it today.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39157
--- Comment #4 from rob1weld at aol dot com 2009-02-13 09:11 ---
Googling for amd64-pc-solaris2.11 gives a few hits.
Googling for x86_64-pc-solaris2.11 gives a dozen hits.
That is not many. Perhaps there is 'no such word'.
It seems there are a few others who discovered this problem:
/* { dg-options -O2 -m32 -fvisibility=hidden -msecure-plt -fpic } */
__attribute__((noinline)) int
foo (int x)
{
return x;
}
int foo (int x);
int
bar (int x)
{
return foo (x);
}
ICEs on the
if (DEFAULT_ABI == ABI_V4 flag_pic)
{
gcc_assert (!TARGET_SECURE_PLT);
return \b
--- Comment #14 from bonzini at gnu dot org 2009-02-13 09:57 ---
It seems to me that it would help to have a postreload LIM pass that would
concentrate on loop-invariant memory accesses that are as cheap or cheaper than
loading back a spill. These would be excluded from the current
--- Comment #15 from steven at gcc dot gnu dot org 2009-02-13 10:03 ---
Re. Comment #14
No, this is not crazy. It is called postreload-gcse. But it is a stupid pass
that doesn't handle all cases it ought to handle.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38134
--- Comment #1 from burnus at gcc dot gnu dot org 2009-02-13 10:34 ---
For completeness, the F2003 standard has in 4.4.4 Character type
The length is a type parameter; its value is greater than or equal to zero.
and later
If the character length parameter value evaluates to a
--- Comment #1 from jakub at gcc dot gnu dot org 2009-02-13 10:36 ---
The problem is in the redundant prototype after function.
First the foo FUNCTION_DECL is created, afterwards finish_function calls
c_determine_visibility on it which changes its visibility from default to
hidden.
--- Comment #22 from rguenther at suse dot de 2009-02-13 11:06 ---
Subject: Re: Code that compiles fine in 1GB of memory
with 4.1.2 requires 20GB in 4.2.* and higher
On Thu, 12 Feb 2009, lucier at math dot purdue dot edu wrote:
--- Comment #19 from lucier at math dot purdue
--- Comment #23 from rguenth at gcc dot gnu dot org 2009-02-13 11:08
---
Lemme close this bug as a dup of the one marked as regression.
*** This bug has been marked as a duplicate of 26854 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #85 from rguenth at gcc dot gnu dot org 2009-02-13 11:08
---
*** Bug 39157 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
--- Comment #7 from tsyvarev at ispras dot ru 2009-02-13 11:21 ---
(In reply to comment #4)
I'm not sure I understand your rationale or I agree that this is a bug. IIUC,
string(1, CHAR_MAX) indicates that groups may be of arbitrary length, which
includes 123,456 This behavior is
--- Comment #8 from paolo dot carlini at oracle dot com 2009-02-13 11:31
---
(In reply to comment #7)
Standard use term unlimited length, which
means(as I understand) that all other digits should incorporate in only one
group - only 123456 is
--- Comment #2 from jakub at gcc dot gnu dot org 2009-02-13 11:33 ---
Created an attachment (id=17292)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17292action=view)
gcc44-pr39175.patch
Patch I'm going to bootstrap/regtest.
--
jakub at gcc dot gnu dot org changed:
--- Comment #9 from paolo dot carlini at oracle dot com 2009-02-13 11:39
---
In other terms, as usual about those matters, Martin is right ;) Only he has
got a wrong data point about libstdc++, he believes we are setting eofbit.
Thanks anyway for pointing our attention to this
I noticed this running mixed mpi/openmp on a system that required an executable
without dynamics libraries. Don't know if the Fortran IO is supposed to be
thread safe (i.e. serialized thread safe), but this seems to work without
-static. It also appears to work with 4.3.1 but not 4.4 (trunk)
cat
--- Comment #4 from jakub at gcc dot gnu dot org 2009-02-13 12:35 ---
It is glibc specific, on the other hand it isn't particularly -fopenmp related.
I guess easiest will be if glibc stops shipping libpthread.a.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39176
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-02-13 12:44 ---
This also ICEs on the 4.3 branch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39175
--- Comment #3 from pault at gcc dot gnu dot org 2009-02-13 12:53 ---
The patch for 36703 also fixes this fellow.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from tsyvarev at ispras dot ru 2009-02-13 13:41 ---
(In reply to comment #8)
(In reply to comment #7)
Standard use term unlimited length, which
means(as I understand) that all other digits should incorporate in only one
group -
--- Comment #11 from paolo dot carlini at oracle dot com 2009-02-13 13:43
---
(In reply to comment #10)
Do you mean that when reading 123,456 with string(1, -1), failbit shouldn't
be set?
Right, as Martin said.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39168
--- Comment #5 from jv244 at cam dot ac dot uk 2009-02-13 14:01 ---
(In reply to comment #4)
It is glibc specific, on the other hand it isn't particularly -fopenmp
related.
I guess easiest will be if glibc stops shipping libpthread.a.
but if -fopenmp automatically adds -lpthread
--- Comment #3 from hjl at gcc dot gnu dot org 2009-02-13 14:34 ---
Subject: Bug 39162
Author: hjl
Date: Fri Feb 13 14:34:00 2009
New Revision: 144157
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144157
Log:
gcc/
2009-02-13 H.J. Lu hongjiu...@intel.com
PR
--- Comment #1 from burnus at gcc dot gnu dot org 2009-02-13 14:57 ---
s/MAIN_/MAIN__/g
* * *
Intel's solution is to link for_main-o, but that is not as elegant as for
ifort *.o one needs to specify -nofor-main if there is a non-fortran C
The last line should read: 'if there is a
--- Comment #12 from tsyvarev at ispras dot ru 2009-02-13 15:04 ---
Let's consider the following situation (seems lifelike to me). Suppose one
needs a representation of numbers in which only the last 3 digits are separated
from all other digits (grouped), like 1234,567 or 1234567,890.
--- Comment #13 from paolo dot carlini at oracle dot com 2009-02-13 15:11
---
(In reply to comment #12)
Could you suggest which grouping string should be used to do such number
representation? Or is this unachievable?
Actually \003\176 seems perfectly practical to me. In particular
--- Comment #2 from burnus at gcc dot gnu dot org 2009-02-13 15:11 ---
Note: Moving main() to f951 will break programs which assume that MAIN__ will
be called, compile e.g. the following program with gcc:
---
#include stdio.h
int MAIN__( int argc, char* argv[] )
--- Comment #14 from paolo dot carlini at oracle dot com 2009-02-13 15:21
---
If I understand correctly, in order to implement the POSIX behavior for C++,
assuming we want it, the Standard should be clarified to explain that values =
0 or CHAR_MAX are different in that do no admit
--- Comment #21 from d dot g dot gorbachev at gmail dot com 2009-02-13
15:25 ---
Created an attachment (id=17293)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17293action=view)
precompiled source
The same issue with GCC 4.3.3 (i686-pc-linux-gnu).
C source:
--- Comment #15 from tsyvarev at ispras dot ru 2009-02-13 15:38 ---
(In reply to comment #14)
If I understand correctly, in order to implement the POSIX behavior for C++,
assuming we want it, the Standard should be clarified to explain that values
=
0 or CHAR_MAX are different in
--- Comment #86 from lucier at math dot purdue dot edu 2009-02-13 15:40
---
Subject: Re: [4.3/4.4 Regression] Inordinate
compile times on large routines
It's unfortunate that the discussion from 39157 will be somewhat hard to
find now that that bug is closed.
Steven wrote in a
It seems so that for optimization levels one or higher, gcc produces wrong code
for the two test files below.
If I compile the same test with -O or -Os everything works fine.
On taking a look into produced assembly, it seems that it wrongly assumes the
assert alway have to raise.
File 1: t1.cpp
--- Comment #16 from paolo dot carlini at oracle dot com 2009-02-13 15:49
---
(In reply to comment #15)
(In reply to comment #14)
If I understand correctly, in order to implement the POSIX behavior for C++,
assuming we want it, the Standard should be clarified to explain that
--- Comment #6 from hjl dot tools at gmail dot com 2009-02-13 15:51 ---
I checked gcc 3.4.6. The bug is there.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39082
--with-ld=/usr/local/bin/ld --with-gmp=/usr/local --with-mpfr=/usr/local
--without-ppl
Thread model: posix
gcc version 4.4.0 20090213 (experimental) [trunk revision 144149] (GCC)
# gmake
...
./gcj-dbtool -n classmap.db || touch classmap.db
/bin/sh: line 1: 20225: Memory fault(coredump)
cp
--- Comment #10 from hjl dot tools at gmail dot com 2009-02-13 15:57
---
Fixed. Gcc 4.4.0 revision 144128 generates:
foo2:
movd%edi, %xmm0
movd%esi, %xmm1
movd%edx, %xmm2
punpckldq %xmm0, %xmm1
movd%ecx, %xmm0
--- Comment #37 from hjl dot tools at gmail dot com 2009-02-13 16:00
---
Gcc 4.4.0 revision 144128 generates:
.globl convert
.type convert, @function
convert:
movl%edi, -4(%rsp)
movss -4(%rsp), %xmm0
ret
.size convert, .-convert
--- Comment #44 from bonzini at gnu dot org 2009-02-13 16:05 ---
A simplified (local, noncascading) fwprop not using UD chains would not be hard
to do... Basically, at -O1 use FOR_EACH_BB/FOR_EACH_BB_INSN instead of walking
the uses, keep a (regno, insn) map of pseudos (cleared at the
--- Comment #45 from lucier at math dot purdue dot edu 2009-02-13 16:09
---
Subject: Re: [4.3/4.4 Regression] 30%
performance slowdown in floating-point code caused by r118475
On Fri, 2009-02-13 at 16:05 +, bonzini at gnu dot org wrote:
--- Comment #44 from bonzini at gnu
--- Comment #3 from hjl dot tools at gmail dot com 2009-02-13 17:31 ---
(In reply to comment #2)
See the comment:
... Remove this code in GCC 3.2 or later.
But given the bogus warning message, we may never remove it :-).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39149
--- Comment #90 from lucier at math dot purdue dot edu 2009-02-13 17:37
---
Subject: Re: [4.3/4.4 Regression] Inordinate
compile times on large routines
On Fri, 2009-02-13 at 16:54 +, bonzini at gnu dot org wrote:
--- Comment #87 from bonzini at gnu dot org 2009-02-13
--- Comment #91 from lucier at math dot purdue dot edu 2009-02-13 17:43
---
Subject: Re: [4.3/4.4 Regression] Inordinate
compile times on large routines
On Fri, 2009-02-13 at 17:37 +, lucier at math dot purdue dot edu
wrote:
--- Comment #90 from lucier at math dot purdue
--- Comment #4 from hjl dot tools at gmail dot com 2009-02-13 17:44 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00657.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #1 from gnu_andrew at member dot fsf dot org 2009-02-13 17:45
---
Created an attachment (id=17294)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17294action=view)
Preliminary patch, has issues with the returned string reading from the wrong
memory location
Preliminary
--- Comment #5 from hjl at gcc dot gnu dot org 2009-02-13 17:48 ---
Subject: Bug 39149
Author: hjl
Date: Fri Feb 13 17:48:20 2009
New Revision: 144160
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144160
Log:
2009-02-13 H.J. Lu hongjiu...@intel.com
PR target/39149
--- Comment #2 from tromey at gcc dot gnu dot org 2009-02-13 17:54 ---
This line looks fishy:
+ boffset = cbuf-position();
boffset is a byte offset from the start of 'data' to the first character.
So, you probably need to multiply by sizeof(jchar) and also add in
the size of
We get this error multiple places in the RTEMS code base.
m32c-rtems4.10-gcc --pipe -mcpu=m32cm --pipe -DHAVE_CONFIG_H -I..
-I../../../lib/include -D__RTEMS_INSIDE__ -Wall
-Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -fasm -g
-O2 -mcpu=m32cm -MT
--- Comment #1 from joel at gcc dot gnu dot org 2009-02-13 18:50 ---
Created an attachment (id=17295)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17295action=view)
preprocessed test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39182
--- Comment #2 from joel at gcc dot gnu dot org 2009-02-13 18:52 ---
WORKS: m32c-rtems4.10-gcc -mcpu=m32cm j.c -c
FAILS: m32c-rtems4.10-gcc -mcpu=m32cm j.c -O1 -c
FAILS: m32c-rtems4.10-gcc -mcpu=m32cm j.c -O2 -c
--
joel at gcc dot gnu dot org changed:
What|Removed
--- Comment #7 from jason at gcc dot gnu dot org 2009-02-13 19:14 ---
Subject: Bug 39070
Author: jason
Date: Fri Feb 13 19:14:07 2009
New Revision: 144161
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144161
Log:
PR c++/39070
* semantics.c (finish_call_expr):
--- Comment #19 from jakub at gcc dot gnu dot org 2009-02-13 19:15 ---
Created an attachment (id=17296)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17296action=view)
Unsuccessful attempt to avoid stack realignment for DImode and for DFmode at
-Os
Just for the record, here is an
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39181
I just tried to compile the Linux kernel 2.6.28.5
with the GNU C compiler version 4.4 snapshot 20090206,
using the valgrind debugging tool.
The compiler said
as --gdwarf2 -V -Qy --64 -o arch/x86/ia32/ia32entry.o ia32entry.s
==4085== Conditional jump or move depends on uninitialised value(s)
--- Comment #48 from bonzini at gnu dot org 2009-02-13 20:09 ---
Subject: Re: [4.3/4.4 Regression] 30%
performance slowdown in floating-point code caused by r118475
Yes. I don't see why the optimizations in CSE, which were relatively
cheap and which were effective for this
--- Comment #1 from dcb314 at hotmail dot com 2009-02-13 20:10 ---
Created an attachment (id=17297)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17297action=view)
pre-processed assembly language code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39183
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-02-13 20:11 ---
As is not part of GCC project, report it to binutils project,
http://sourceware.org/bugzilla/
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-02-13 20:18 ---
Not a gcc bug so closing as invalid. That warning comes from glibc anyways.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from hjl dot tools at gmail dot com 2009-02-13 20:19 ---
FWIW, I can't reproduce it with the current binutils in CVS.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39183
--- Comment #3 from dj at redhat dot com 2009-02-13 20:28 ---
Fails with m32c-elf in 4.3.4 also.
Note: does NOT fail in 4.4/trunk
--
dj at redhat dot com changed:
What|Removed |Added
ICE at -O1 and -02. Target specific error message at -O0. But even that would
be more helpful if it told what the actual limit was.
$ avr-rtems4.10-gcc -mmcu=avr25 -O2 j.c -c
../../../../../rtems/cpukit/telnetd/des.c: In function 'des_init':
../../../../../rtems/cpukit/telnetd/des.c:274:
--- Comment #1 from joel at gcc dot gnu dot org 2009-02-13 20:54 ---
Created an attachment (id=17298)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17298action=view)
preprocessed test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39184
--- Comment #7 from jv244 at cam dot ac dot uk 2009-02-13 21:00 ---
(In reply to comment #6)
Not a gcc bug so closing as invalid.
The gcc 'bug' is that -fopenmp -static should link to pthreads as
-Wl,--whole-archive -lpthread -Wl,--no-whole-archive, if that is required, or
error
--- Comment #8 from jakub at gcc dot gnu dot org 2009-02-13 21:10 ---
This is not a gcc bug, glibc either should not ship libpthread.a at all or
mv libpthread.a libpthreadx.a; gcc -r -nostdlib -o libpthread.a --whole-archive
libpthreadx.a; rm libpthreadx.a
I'll try the latter in Fedora
--- Comment #3 from pault at gcc dot gnu dot org 2009-02-13 21:12 ---
Subject: Bug 36528
Author: pault
Date: Fri Feb 13 21:12:34 2009
New Revision: 144164
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144164
Log:
2009-02-13 Paul Thomas pa...@gcc.gnu.org
PR
--- Comment #4 from pault at gcc dot gnu dot org 2009-02-13 21:12 ---
Subject: Bug 36703
Author: pault
Date: Fri Feb 13 21:12:34 2009
New Revision: 144164
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144164
Log:
2009-02-13 Paul Thomas pa...@gcc.gnu.org
PR
$ h8300-rtems4.10-gcc -O1 -msx -c j.c
../../../../../rtems/cpukit/libnetworking/netinet/in_cksum.c: In function
'in_cksum':
../../../../../rtems/cpukit/libnetworking/netinet/in_cksum.c:118: internal
compiler error: in gen_rtx_SUBREG, at emit-rtl.c:773
Please submit a full bug report,
with
--- Comment #1 from joel at gcc dot gnu dot org 2009-02-13 21:17 ---
Created an attachment (id=17299)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17299action=view)
preprocessed test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39185
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-02-13 21:20 ---
Most likely related to PR 33163 and PR 32739.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39185
--- Comment #8 from jason at gcc dot gnu dot org 2009-02-13 21:53 ---
Subject: Bug 39070
Author: jason
Date: Fri Feb 13 21:53:38 2009
New Revision: 144166
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144166
Log:
PR c++/39070
* semantics.c (finish_call_expr):
--- Comment #2 from hjl dot tools at gmail dot com 2009-02-13 21:58 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00674.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #4 from sje at gcc dot gnu dot org 2009-02-13 21:59 ---
Subject: Bug 38056
Author: sje
Date: Fri Feb 13 21:59:32 2009
New Revision: 144168
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144168
Log:
PR target/38056
* config/ia64/ia64.c
--- Comment #5 from burnus at gcc dot gnu dot org 2009-02-13 22:16 ---
Subject: Bug 38259
Author: burnus
Date: Fri Feb 13 22:16:20 2009
New Revision: 144169
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=144169
Log:
2009-02-13 Mikael Morin mikael.mo...@tele2.fr
PR
--- Comment #6 from burnus at gcc dot gnu dot org 2009-02-13 22:17 ---
FIXED on the trunk (4.4.0).
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
/local
--without-ppl
Thread model: posix
gcc version 4.4.0 20090213 (experimental) [trunk revision 144162] (GCC)
# as --version
GNU assembler (GNU Binutils) 2.19.1
# ld --version
GNU ld (GNU Binutils) 2.19.1
The Build breaks here:
# gmake
...
cp gcj gcj-cross
gmake[2]: Leaving directory `/usr
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-02-13 23:54 ---
the -X86_64 option is not being passed to as which is a bug in the specs.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
[...@gnu-6 936]$ cat x.cc
#include foo.h
const char *
x (void)
{
return f ();
}
[...@gnu-6 936]$ cat y.cc
#include stdio.h
#include foo.h
extern const char *x (void);
int
main ()
{
printf (%p, %p\n, x (), f ());
return 0;
}
[...@gnu-6 936]$ cat foo.h
inline const char *
f ()
{
static
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-02-14 00:11 ---
Except the C++ standard has a defect against this area, see PR 12056 which is
still opened the last time I looked.
*** This bug has been marked as a duplicate of 12056 ***
--
pinskia at gcc dot gnu dot org
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-02-14 00:11 ---
*** Bug 39187 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
Summary: G++ doesn't handle static anonymous union right
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
--- Comment #1 from hjl dot tools at gmail dot com 2009-02-14 00:38 ---
[...@gnu-6 936]$ cat x.cc
#include foo.h
int *
x (void)
{
return f ();
}
[...@gnu-6 936]$ cat y.cc
#include stdio.h
#include foo.h
extern int *x (void);
int
main ()
{
printf (%p, %p\n, x (), f ());
return
--- Comment #5 from hjl dot tools at gmail dot com 2009-02-14 00:56 ---
FWIW, it isn't a problem with GNU linker when all files are compiled
with the same version of gcc since linker can merge identical strings
with gcc help.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12056
--- Comment #2 from rob1weld at aol dot com 2009-02-14 01:19 ---
A quick hack in ../gcc_trunk/libgcc/configure (line 2065) to
add -m64 to the 'ac_compile' and 'ac_link' lines will allow
the build to proceed through libgcc to libgcov where it then
fails due to an issue unrelated to this
When using perverted technique like:
SUBROUTINE A
INTEGER, ALLOCATABLE, DIMENSION(:), TARGET :: ARRAY
INTEGER, POINTER, DIMENSION(:) :: ARRAY_PTR
COMMON /AP/ ARRAY_PTR !for later use in another sub
ALLOCATE(ARRAY(10))
ARRAY = 10
ARRAY_PTR = ARRAY
END SUBROUTINE A
SUBROUTINE B
INTEGER, POINTER,
--- Comment #3 from rob1weld at aol dot com 2009-02-14 02:06 ---
The next issue is here:
../gcc_trunk/gcc/unwind-dw2.c and ../gcc_trunk/gcc/unwind-dw2-fde.c, etc ...
../../../../gcc_trunk/libgcc/../gcc/gthr-posix.h:44:21: error: pthread.h: No
such file or directory
--- Comment #4 from rob1weld at aol dot com 2009-02-14 02:08 ---
Correction, should have said:
-Thus, I conclude that the -m32 for
+Thus, I conclude that the -m64 for
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39186
--- Comment #5 from rob1weld at aol dot com 2009-02-14 02:48 ---
I forced that 32 bit and continued, failing here:
T=`${PWDCMD-pwd}`/ \
cd ../../.././gcc \
gmake GCC_FOR_TARGET=/usr/share/src/gcc_build/./gcc/xgcc
-B/usr/share/src/gcc_build/./gcc/
--- Comment #6 from rob1weld at aol dot com 2009-02-14 03:39 ---
I wonder if I discovered a regression ...
If I compile with gcc version 4.4.0 20090213 (experimental) [trunk revision
144149] it produces a little of 32-bit code that is not going to get
compiled with all the -m64
--- Comment #7 from rob1weld at aol dot com 2009-02-14 04:17 ---
I grepped for CRT_GET_RFIB_DATA and found a definition at the tail of:
/usr/share/src/gcc_trunk/gcc/config/frv/frv.h .
Here is ../gcc_trunk/gcc/crtstuff.c :
static void __attribute__((used))
frame_dummy (void)
{ ...
--- Comment #8 from rob1weld at aol dot com 2009-02-14 04:36 ---
(In reply to comment #7)
...
Slowly I inch forward ...
and go back ...
/usr/local/bin/ld: /usr/share/src/gcc_build/./gcc/amd64/crtbegin.o: relocation
R_X86_64_32 against `__DTOR_END__' can not be used when making a
--- Comment #9 from jason at gcc dot gnu dot org 2009-02-14 05:42 ---
Fixed in 4.3 and 4.4.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
I am trying to derive a minimal Testcase for a Bug found in:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39186
d# gcc/xgcc -v
Using built-in specs.
Target: x86_64-pc-solaris2.11
Configured with: ../gcc_trunk/configure --build=i386-pc-solaris2.11
--target=x86_64-pc-solaris2.11
91 matches
Mail list logo
