--- Comment #14 from jakub at gcc dot gnu dot org 2007-03-20 08:09 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #9 from jakub at gcc dot gnu dot org 2007-03-20 08:09 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from dannysmith at users dot sourceforge dot net 2007-03-20
08:21 ---
This is a dup of PR 29826.
The testcase (and 29826) succeeds on gcc version 4.2.0 20070319 (prerelease)
and on gcc version 4.3.0 20070318 (experimental) with mingw32
Danny
--
http://gcc.gnu.org/
--- Comment #5 from bonzini at gnu dot org 2007-03-20 08:31 ---
Subject: Bug 30907
Author: bonzini
Date: Tue Mar 20 08:31:13 2007
New Revision: 123084
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123084
Log:
2007-03-19 Paolo Bonzini <[EMAIL PROTECTED]>
PR rtl-optimi
--- Comment #4 from bonzini at gnu dot org 2007-03-20 08:31 ---
Subject: Bug 30841
Author: bonzini
Date: Tue Mar 20 08:31:13 2007
New Revision: 123084
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123084
Log:
2007-03-19 Paolo Bonzini <[EMAIL PROTECTED]>
PR rtl-optimi
--- Comment #5 from bonzini at gnu dot org 2007-03-20 08:31 ---
fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30841
--- Comment #6 from bonzini at gnu dot org 2007-03-20 08:32 ---
patch committed.
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #23 from anlauf at gmx dot de 2007-03-20 08:51 ---
(In reply to comment #22)
> Error 5001 would be ERROR_OPTION_CONFLICT. There are 18 different errors
> associated with that code. To find out which one, you must remove the iostat
> from the offending line so that gfortran
The code is
templateclass b{friend ba::c();};
templateba::c(){return b();}
The preprocessed code is
# 1 "stupid.cc"
# 1 ""
# 1 ""
# 1 "stupid.cc"
templateclass b{friend ba::c();};
templateba::c(){return b();}
gcc was built on Fedora Core 4; configured with command:
../gcc-4.1.2/configure --pre
--- Comment #5 from mimo2 at free dot fr 2007-03-20 08:56 ---
OK but in the present situation, the execution could be different wether you
have -fbounds-check or not. Let's change the code by
program toto
implicit none
real:: a(100)
integer :: i, k
a(:) = 1.
do i=1,100
if(
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #3 from o dot mangold at gmx dot de 2007-03-20 09:21 ---
Maybe I should remark, that on my system the assembler output looks I little
different than yours.
Good:
.L2:
pushl %edi
fildl (%esp)
addl$4, %esp
fstpl (%esp)
call
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-03-20 09:27
---
Here's a patch:
Index: trans-const.c
===
--- trans-const.c (revision 123017)
+++ trans-const.c (working copy)
@@ -165,23 +165,31 @@
--- Comment #16 from rguenth at gcc dot gnu dot org 2007-03-20 09:34
---
I didn't notice before, but can we have a testcase for the testsuite please?
Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30590
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-03-20 10:00 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #3 from pault at gcc dot gnu dot org 2007-03-20 10:09 ---
> > All compilers I know reject this code, except g95. The list includes Lahey,
> > which is a reason for me to doubt whether this code is legal or not.
The code is legal because the interface to test2 only needs the
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-20 10:39 ---
Confirmed. This is neither done at the tree nor at the rtl level.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-03-20 10:43 ---
I see on x86_64 with -O2 (vrp can cleanup this somewhat):
in_canforward:
.LFB2:
movl%edi, %eax
andl$240, %eax
cmpl$240, %eax
je .L4
cmpl$224, %eax
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-03-20 10:54 ---
Confirmed. Also related to PR28778 - call clobbering is broken in 4.1. I
don't
see us fixing this on the 4.1 branch though.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-03-20 11:04 ---
I agree it's surprising to get user-visible effects with the
TARGET_C99_FUNCTIONS
difference between the frontends, but they are (supposed to) providing C99
runtime completion by their runtime libraries. And they re
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-03-20 11:05 ---
A slightly related testcase is now properly optimized.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31146
--- Comment #1 from guillaume dot melquiond at ens-lyon dot fr 2007-03-20
11:22 ---
I just encountered another instance of a missing typename diagnostic. This time
with a different message, so I add it here for completeness:
a.cpp:5: error: dependent-name T::#typename_type not suppo
--- Comment #2 from pcarlini at suse dot de 2007-03-20 11:45 ---
Related to C++/30982?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31267
--- Comment #6 from aph at gcc dot gnu dot org 2007-03-20 12:45 ---
Subject: Bug 31264
Author: aph
Date: Tue Mar 20 12:45:19 2007
New Revision: 123085
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123085
Log:
2007-03-19 Andrew Haley <[EMAIL PROTECTED]>
PR tree-optimi
--- Comment #7 from mueller at gcc dot gnu dot org 2007-03-20 12:48 ---
testcase works after PR31146 fix
*** This bug has been marked as a duplicate of 31146 ***
--
mueller at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #8 from mueller at gcc dot gnu dot org 2007-03-20 12:48 ---
*** Bug 30864 has been marked as a duplicate of this bug. ***
--
mueller at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #8 from dominiq at lps dot ens dot fr 2007-03-20 13:57 ---
> The only reason why cexp is slow on PPC darwin is because the ABI is stupid.
> Complex float arguments are passed via the GPR and returned also the same way
> instead of via the FPRs. So you will get a transfer of
--- Comment #3 from arcangelpip at hotmail dot com 2007-03-20 13:58 ---
I just tried with the latest sources for 4.1 and it still ICE with that. Same
place same message. It may work on 4.2 and 4.3 but it doesn't work for me on
4.1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3127
--- Comment #9 from dominiq at lps dot ens dot fr 2007-03-20 14:03 ---
> I agree it's surprising to get user-visible effects with the
> TARGET_C99_FUNCTIONS difference between the frontends,
> but they are (supposed to) providing C99 runtime completion
> by their runtime libraries. An
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-03-20 14:26
---
That sin+cos is practically sincos (so you get one for free). Just not every
library exports that sincos.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31249
A backtrace (or coredump) would be nice for array out of bounds.
It would have to be implemented in as library call. This could be combined with
given more information (accessed index, allowed index) which is often
requested, e.g. PR 31270).
--
Summary: Backtrace/coredump for array-o
--- Comment #11 from dominiq at lps dot ens dot fr 2007-03-20 14:57 ---
Subject: Re: pseudo-optimzation with sincos/cexpi
> That sin+cos is practically sincos (so you get one for free). Just not every
> library exports that sincos.
Does not this assume that it exists a real sincos(x)
--- Comment #12 from rguenth at gcc dot gnu dot org 2007-03-20 15:06
---
Depends on how you name it ;) You can propose that we only enable sincos
transformation if TARGET_HAS_SINCOS is set, I wouldn't necessarily object to
that.
(The targets I care for have a sincos)
--
http://gcc
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-03-20 15:20 ---
*** Bug 31275 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-03-20 15:20 ---
*** This bug has been marked as a duplicate of 29826 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-03-20 15:21 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-03-20 15:29 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #9 from pthaugen at us dot ibm dot com 2007-03-20 15:31 ---
Looks like I can reproduce with mainline using -O2 -ftree-loop-linear when
building galgel benchmark from cpu2000.
(My FORTRAN skills are lacking, so couldn't whittle down to a single testcase,
but got close)
178.g
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-03-20 15:37
---
> Looks like I can reproduce with mainline using -O2 -ftree-loop-linear when
> building galgel benchmark from cpu2000.
This is a different issue and should be filed in a different bug.
--
http://gcc.gnu.org/b
In Fortran one can specify the intent of variables thus if all arguments have
INTENT(IN) then GCC should be able to detect that alist in the call to cshift
is uninitialized.
This depends on the middle end support of intents (PR31094) plus using these in
gfortran.
Example (using an intrinsic funct
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31279
--- Comment #17 from spark at gcc dot gnu dot org 2007-03-20 15:42 ---
Subject: Bug 30590
Author: spark
Date: Tue Mar 20 15:42:37 2007
New Revision: 123087
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123087
Log:
2007-03-19 Seongbae Park <[EMAIL PROTECTED]>
PR tree-o
Seeing the following with mainline using -O2 -ftree-loop-linear when
building galgel benchmark from cpu2000.
I couldn't whittle down to a single testcase so will attatch both source files.
178.galgel/run> /home/pthaugen/install/gcc/trunk/bin/gfortran -c -m64
-ffixed-form -O2 -ftree-loop-linear mo
--- Comment #1 from pthaugen at us dot ibm dot com 2007-03-20 15:53 ---
Having trouble attatching source files, will keep trying...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31280
--- Comment #11 from pthaugen at us dot ibm dot com 2007-03-20 15:54
---
31280 opened.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30562
--- Comment #13 from dominiq at lps dot ens dot fr 2007-03-20 16:08 ---
> You can propose that we only enable sincos transformation
> if TARGET_HAS_SINCOS is set, I wouldn't necessarily object to
> that. (The targets I care for have a sincos)
Sound reasonable: replacing:
return (TAR
--- Comment #14 from rguenth at gcc dot gnu dot org 2007-03-20 16:12
---
The recommended way is to post a message to gcc@gcc.gnu.org or
[EMAIL PROTECTED]
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31249
--- Comment #15 from pinskia at gcc dot gnu dot org 2007-03-20 16:14
---
> Is this also true for complex double on 32 bit architectures (i.e., 4 GPRs)
> or do you mean the GPR is used to pass a pointer?
4 GPRS
Yes this was a stupid decission on Apple's part for not looking at fixing G
--- Comment #18 from spark at gcc dot gnu dot org 2007-03-20 16:44 ---
Subject: Bug 30590
Author: spark
Date: Tue Mar 20 16:44:00 2007
New Revision: 123089
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123089
Log:
2007-03-20 Seongbae Park <[EMAIL PROTECTED]>
PR tree-o
--- Comment #19 from spark at gcc dot gnu dot org 2007-03-20 16:45 ---
Subject: Bug 30590
Author: spark
Date: Tue Mar 20 16:44:54 2007
New Revision: 123090
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123090
Log:
2007-03-20 Seongbae Park <[EMAIL PROTECTED]>
PR tree-o
The 4.2 ObjC compiler ICEs on this (nonsensically reduced) testcase. Compile
with -O2:
int f(unsigned int i)
{
@try { } @catch(id) { }
for (;;)
for (;;)
@try {
if (i)
break;
} @catch(id) { }
}
The 4.0 compiler does not ICE with this testcase.
--
Just a note on the severity, I've marked this as a "blocker" because it seems
quite basic and it makes it impossible for us to use GCC/G++ to generate a
thread safe shared object for use with JNI. Please adjust as appropriate.
I'm not sure if this is a g++ bug or a libstdc++ bug, I've followed Da
--- Comment #6 from rth at gcc dot gnu dot org 2007-03-20 17:09 ---
Spill slots *are* being aligned, else you'd see SEGV, not incorrect data.
Aliasing *is* the problem:
pand(%esi), %xmm0
movl$1, (%ebx)
movl$2, 4(%ebx)
movl$3, 8(%ebx)
The 4.2 ObjC compiler ICEs on this (nonsensically reduced) testcase. Compile
with -O2:
int f(unsigned int i)
{
@try { } @catch(id) { }
for (;;)
for (;;)
@try {
if (i)
break;
} @catch(id) { }
}
The 4.0 compiler does not ICE with this testcase.
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-20 17:16 ---
This works for me on the trunk on powerpc-linux-gnu with the GNU runtime and
next runtime.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-20 17:17 ---
*** Bug 31283 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31281
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-20 17:17 ---
*** This bug has been marked as a duplicate of 31281 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|blocker |normal
Component|libstdc++ |other
http:/
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-20 17:34 ---
You can just send them to me if you want.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31280
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-20 17:36 ---
It is not hard to do "b _gfortran_out_of_bounds" in gdb.
I never understood why gfortran or any language these extra features when there
is something called a debugger.
--
http://gcc.gnu.org/bugzilla/show_bug.c
In the following program, the uninitialized "i" is only detected if one
uncomments the print statement.
program test
implicit none
integer :: i,j
j = i*5
print*,i
end program test
--
Summary: Uninitialized variable not detected
Product: gcc
Version: 4.3.0
--- Comment #1 from burnus at gcc dot gnu dot org 2007-03-20 17:38 ---
Forgot to write that this is a Fortran program. Use
gfortran -Wall -O
to compile it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31284
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-20 17:43 ---
And the issue here is really PR19430
For some reason gfortran decided that print will cause a pass via reference :).
*** This bug has been marked as a duplicate of 19430 ***
--
pinskia at gcc dot gnu dot org ch
--- Comment #13 from pinskia at gcc dot gnu dot org 2007-03-20 17:43
---
*** Bug 31284 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from burnus at gcc dot gnu dot org 2007-03-20 17:45 ---
> It is not hard to do "b _gfortran_out_of_bounds" in gdb.
Well, it is not always easy to find the symbol. In C it is much easier:
Essentially all you type is what you get. Fortran with all its hidden library
calls i
--- Comment #6 from tobi at gcc dot gnu dot org 2007-03-20 17:50 ---
I don't see why nobody besides me thinks that consistency, whether it's
mandated by the standard or not is a user-friendly feature. Yes I understand
the arguments for our current behavior, but I'm not going to discuss
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-03-20 18:03 ---
> I don't see why nobody besides me thinks that consistency
Because the code is undefined either way you look at it :).
Yes GCC might allow it to work without -fbounds-check but that does not mean it
will work somew
--- Comment #3 from pthaugen at us dot ibm dot com 2007-03-20 18:09 ---
Created an attachment (id=13238)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13238&action=view)
Fortran source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31280
--- Comment #4 from pthaugen at us dot ibm dot com 2007-03-20 18:10 ---
Created an attachment (id=13239)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13239&action=view)
Fortran source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31280
--- Comment #21 from pluto at agmk dot net 2007-03-20 18:52 ---
http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01343.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7302
--- Comment #8 from mimo2 at free dot fr 2007-03-20 18:52 ---
Why do you say the code is undefined. The last version (comment #5) is totally
valid, but possible side effects in the function k could lead to different
results depending on the fact that the -fbounds-check is set or no.
And
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-03-20 18:57 ---
(In reply to comment #8)
> Why do you say the code is undefined. The last version (comment #5) is totally
> valid, but possible side effects in the function k could lead to different
> results depending on the fact t
--- Comment #22 from manu at gcc dot gnu dot org 2007-03-20 19:01 ---
(In reply to comment #21)
> http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01343.html
>
Hint, if you use the patch queue[1], it takes care of adding a comment pointing
to the patch. Also, your patch lacks a Changelog [
--- Comment #10 from tobi at gcc dot gnu dot org 2007-03-20 19:11 ---
Mimo,
you rely on behavior that is not specified by the standard. It says explicitly
that only, in order to determine the value of an expression, only as much of it
needs to be evaluated, as is needed to determine th
As found by Salvatore Filippone using valgrind.
---
program testcshft
integer :: alist(4)
!!$alist = (/1,2,3,4/)
alist =cshift(alist,-1)
write(*,*) alist
end program testcshft
-
==6801== Conditional jump or move depends on uninitialised value(s)
> ==
--- Comment #23 from patchapp at dberlin dot org 2007-03-20 19:42 ---
Subject: Bug number PR7302
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01347.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #1 from bangerth at dealii dot org 2007-03-20 20:02 ---
Confirmed.
W.
--
bangerth at dealii dot org changed:
What|Removed |Added
CC|
--- Comment #11 from mimo2 at free dot fr 2007-03-20 20:12 ---
hi tobi, may-be they have strong arguments as you say, but I've not catched
them. And I still believe that if there is an ambiguity in the standard, the
solution is to have a -fshort-circuit to let the user decide what he wan
--- Comment #12 from Tobias dot Schlueter at physik dot uni-muenchen dot de
2007-03-20 20:17 ---
Subject: Re: short-circuit in -fbounds-check
I'm on your side, mimo, no need to convince me :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31269
--- Comment #13 from pinskia at gcc dot gnu dot org 2007-03-20 20:58
---
> But I'll stop this discussion here, and will stay with g95 when I want to
> bound-check my program.
Why short circuiting is legal and so is not short circuiting. Yes Gfortran's
behavior is semi inconstaint but
I have a simple for for loop that initializes a char array and never stops.
Here is a small sample program that simulated the problem.
#include
int main(int argc, char *argv[]){
int i=0;
char name_array[7][100];
for (i=0; i <= 7; i++)
{
printf("Loop i: %d\n", i);
na
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-20 21:01 ---
Note you are going over name_array's bounds so you are invoking undefined
behavior. 7 <= 7. arrays go from 0 to last-1 in C or (0, last-1] in math
notation for C arrays.
--
http://gcc.gnu.org/bugzilla/show_bug.
--- Comment #2 from bryan_sauser at pa-ucl dot com 2007-03-20 21:03 ---
Was code given to me by Contract programmer. Released person simple mistake
after reviewing.
--
bryan_sauser at pa-ucl dot com changed:
What|Removed |Added
I have a simple for for loop that initializes a char array and never stops.
Here is a small sample program that simulated the problem.
#include
int main(int argc, char *argv[]){
int i=0;
char name_array[7][100];
for (i=0; i <= 7; i++)
{
printf("Loop i: %d\n", i);
na
--- Comment #14 from Tobias dot Schlueter at physik dot uni-muenchen dot de
2007-03-20 21:04 ---
Subject: Re: short-circuit in -fbounds-check
pinskia at gcc dot gnu dot org wrote:
>> But I'll stop this discussion here, and will stay with g95 when I want to
>> bound-check my program.
>
--- Comment #30 from sje at cup dot hp dot com 2007-03-20 21:13 ---
I tried the C++ and Fortran tests (in addition to C) with version 122821 using
a non-boostrapped compiler but I got no new failures. It looks like the only
failing test case we have is the compiler itself.
--
http:
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-03-20 21:26 ---
*** Bug 31288 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31287
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-20 21:26 ---
*** This bug has been marked as a duplicate of 31287 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from dje at gcc dot gnu dot org 2007-03-20 21:40 ---
What tools are you using for the cross-compiler? Cross-compiling to AIX is not
supported because the rest of the GNU crosstools are incomplete for AIX 5.
--
dje at gcc dot gnu dot org changed:
What|R
--- Comment #1 from dje at gcc dot gnu dot org 2007-03-20 21:43 ---
Compiling with -pthread adds -D_THREAD_SAFE to the defined macros, which causes
different header files to be included. Prior to GCC 4.3, this appears to cause
a non-unique name to be chosen for the global constructor in
--- Comment #2 from kstemen at centeris dot com 2007-03-20 21:45 ---
I'm trying to create rpms of cross compilers. I looked on the crosstools
website, but it doesn't look like it supports that. So I am more or less
building the cross compiler from scratch.
I noticed that C++ is unsuppor
--- Comment #2 from dje at gcc dot gnu dot org 2007-03-20 21:47 ---
Andrew Pinski pointed out that this is known with a workaround:
http://www-128.ibm.com/developerworks/forums/dw_thread.jsp?forum=747&thread=119546&cat=72
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31282
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-03-20 21:48 ---
http://gcc.gnu.org/ml/gcc-help/2007-03/msg00095.html
According to IBM, the fix for this APAR IY90737 is incorporated into
Service Pack 5300-05-04.
Do you have that installed?
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #4 from dje at gcc dot gnu dot org 2007-03-20 21:48 ---
and more info http://gcc.gnu.org/ml/gcc-help/2007-03/msg00095.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31282
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-03-20 21:59 ---
>If it would help you, I can give you the options I used to configure binutils,
> and a list of the AIX libraries in my AIX sysroot.
Does not matter, binutils does not support AIX 5.3 features.
--
pinskia at gcc
--- Comment #4 from kstemen at centeris dot com 2007-03-20 22:10 ---
Tell me what binutils doesn't support and I'll file a bug on binutils. I
already filed a bug about the default rpath in the cross compiler version of
gnu ld for AIX 5.3.0.0, and they fixed it. They didn't say anything a
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-03-20 22:15 ---
"The native as and ld are recommended for bootstrapping on AIX 4 and required
for bootstrapping on AIX 5L. The GNU Assembler reports that it supports WEAK
symbols on AIX 4, which causes GCC to try to utilize weak sym
--- Comment #6 from kstemen at centeris dot com 2007-03-20 22:19 ---
That says you can't bootstrap GCC on AIX 5L with GNU ld and as. It doesn't say
you can't build a cross compiler with them, and it doesn't say you can't use
them after GCC is bootstrapped.
In fact, I have looked at coll
--- Comment #7 from dje at gcc dot gnu dot org 2007-03-20 22:41 ---
If GNU Binutils and Linker do not support AIX 5L sufficiently to bootstrap GCC,
then you should infer that does not support AIX 5L sufficiently for anything
"interesting", like shared libraries.
--
http://gcc.gnu.or
--- Comment #7 from membar at gcc dot gnu dot org 2007-03-20 22:45 ---
This fix works for me. Thanks. Not sure who's responsible for closing this out.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31264
1 - 100 of 116 matches
Mail list logo
