On Thu, 28 Feb 2008, Jan Hubicka wrote:
-static inline void __attribute__((format(printf, 1, 2)))
-__simple_attr_check_format(const char *fmt, ...)
It would be nice to have a testcase, but I guess it is because GCC can't
inline variadic functions. The function gets identified as const
Hi,
I am beginner in GCC. I want to make few changes in source code. What are
the steps that I need to do to get the changes in effect and to test the
changes?
Any help is appreciated.
Thanks and Regards
Jaishri
On Thu, Feb 28, 2008 at 12:58:35AM +0100, Jan Hubicka wrote:
We probably also can simply allow inlining variadic functions not
calling va_start. I must say that this option appeared to me but I was
unable to think of any sane use case. This probably is one ;)
We already allow inlining
Jaishri wrote:
Hi,
I am beginner in GCC. I want to make few changes in source code. What are
the steps that I need to do to get the changes in effect and to test the
changes?
Any help is appreciated.
I'm also a beginner, so I'll try my best but I cannot ensure you that my
'howto' is error
On Thu, Feb 28, 2008 at 12:58:35AM +0100, Jan Hubicka wrote:
We probably also can simply allow inlining variadic functions not
calling va_start. I must say that this option appeared to me but I was
unable to think of any sane use case. This probably is one ;)
We already allow inlining
Jeff,
Thanks for the quick response. As it turns out, the libcall issue will
soon be gone, as bonzini will be deleting them. We have finally
overcome that issue.
The subregs are clearly going to be the issue, and before i dive into it
i want to understand what it means to do a merge a bunch
Thanks for the quick response. As it turns out, the libcall issue will
soon be gone, as bonzini will be deleting them. We have finally
overcome that issue.
Not really. There seems always to be something that prevents them from
being deleted, and I have no time to spend on GCC at work
Hi,
as discussed briefly on IRC yesterday, I would be very happy to see
current DU/UD infrastructure changed to FUD chains (or on side SSA
form). This way it will be more symmetric to how tree level virtual
operands are handled and will hopefully make whole compiler more
standard and easier to
Hello all,
I've tried to build gcc-4.2.2 cross to E500 target,
configured with --target=powerpc-linux-gnuspe
--disable-multilib --with-newlib --with-cpu=8540
--enable-cxx-flags=-mcpu=8540 --enable-e500_double
but failed with the following message:
...
In file included from
Kenneth Zadeck wrote:
Birthpoints are not nearly as useful as phi-functions because the
algorithms that use birthpoints do not generally leave the birthpoints
in the right places when they are finished. There is a lot of value
added by the operand of phi-functions. But they do solve the n**2
Hello Basile,
A mere quick portability review:
* Basile STARYNKEVITCH wrote on Thu, Feb 28, 2008 at 05:39:47PM CET:
compile-basilys-defs:
echo '#generated compile-basilys-defs' $@
echo 'ALL_CFLAGS=' $(ALL_CFLAGS) '' $@
echo 'ALL_CPPFLAGS=' -I$(PWD) $(ALL_CPPFLAGS) ''
Ralf Wildenhues wrote:
Hello Basile,
A mere quick portability review:
A big thanks
* Basile STARYNKEVITCH wrote on Thu, Feb 28, 2008 at 05:39:47PM CET:
compile-basilys-defs:
echo '#generated compile-basilys-defs' $@
echo 'ALL_CFLAGS=' $(ALL_CFLAGS) '' $@
echo
Hi Taras,
Thank you for your message! Our main work (GCC-ICI) is
slightly orthogonal to plugins - our main goal at the moment
is to improve or automatically tune optimization heuristic
for evolving systems. However, naturally we implemented
it as a plugin system and we would be happy to have
a
On Thu, 28 Feb 2008, Sergei Poselenov wrote:
Gcc 4.2.2 release sources are patched with the Joseph S. Myers
patch for E500 long double support
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01388.html
There are a lot of preliminary patches and followups to them and to this
main patch that are
Basile STARYNKEVITCH wrote:
Ralf Wildenhues wrote:
Hello Basile,
A mere quick portability review:
A big thanks
Commited into MELT branch rev 132754.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la
My real point in starting this discussion was to try to interest
(sucker) one of the subreg specialists into helping me solve the issue
of inserting move at the birthpoint where subregs or strict lower values
are used.
I don't see your problem here. Any use (as in reading) of a
subreg can
last 24 hrs I get this:
make[2]: Entering directory `/mnt/share/bld/gcc'
make[3]: Entering directory `/mnt/share/bld/gcc'
rm -f stage_current
make[3]: Leaving directory `/mnt/share/bld/gcc'
Comparing stages 2 and 3
warning: ./cc1-checksum.o differs
warning: ./cc1plus-checksum.o differs
Ralf == Ralf Wildenhues [EMAIL PROTECTED] writes:
[snip]
Ralf Wasn't there a proposal to use depcomp in gcc a while ago?
Yes. I'm planning to submit the automatic dependencies patch for real
in a week or two. I'm working through my backlog of 4.4 patches and
that is the last one.
Tom
On Thu, Feb 28, 2008 at 2:32 PM, Paolo Bonzini [EMAIL PROTECTED] wrote:
Thanks for the quick response. As it turns out, the libcall issue will
soon be gone, as bonzini will be deleting them. We have finally
overcome that issue.
Not really. There seems always to be something that
Steven Bosscher wrote:
On Thu, Feb 28, 2008 at 2:32 PM, Paolo Bonzini [EMAIL PROTECTED] wrote:
Thanks for the quick response. As it turns out, the libcall issue will
soon be gone, as bonzini will be deleting them. We have finally
overcome that issue.
Not really. There seems
Steven Bosscher [EMAIL PROTECTED] writes:
On Thu, Feb 28, 2008 at 2:32 PM, Paolo Bonzini [EMAIL PROTECTED] wrote:
Thanks for the quick response. As it turns out, the libcall issue will
soon be gone, as bonzini will be deleting them. We have finally
overcome that issue.
Not
On 28 Feb 2008 12:41:30 -0800, Ian Lance Taylor [EMAIL PROTECTED] wrote:
libcalls are still used for no-conflict blocks. This may be what you
mean by the scheduling thing. No-conflict blocks are emitted by
emit_no_conflict_block and checked in local-alloc.
I thought the no-conflict blocks
On Thu, Feb 28, 2008 at 02:02:26PM +0530, Jaishri wrote:
Hi,
I am beginner in GCC. I want to make few changes in source code. What are
the steps that I need to do to get the changes in effect and to test the
changes?
Any help is appreciated.
It's all on the web and wiki.
Configuring and
Steven Bosscher [EMAIL PROTECTED] writes:
On 28 Feb 2008 12:41:30 -0800, Ian Lance Taylor [EMAIL PROTECTED] wrote:
libcalls are still used for no-conflict blocks. This may be what you
mean by the scheduling thing. No-conflict blocks are emitted by
emit_no_conflict_block and checked in
Hi,
I'd like to know your experiences with the gcc loop optimizations.
What loop optimizations (in your opinion) can be applied to a large
number of programs and yield a (significant) improvement of the
program run-time?
I've tested the gcc compiler optimization loop unswitching
(introduced in
On Thu, 2008-02-28 at 11:23 +0100, Jan Hubicka wrote:
The call ought to be always
early inlined and not seen by any optimization pass.
The inlined functions don't actually appear in the generated code.
Look at the code generation differences for kernel/sched.c
function place_entity
$ size
platform : microsoft windowsXP(32) sp2 intel core duo
i managed to build gcc-4.2.3 using MinGW-5.1.3 candidate with gcc 3.4.5
and binutils-2.17.50 in MSYS-1.0.10
../../src/gcc-4.2.3/configure --prefix=/mingw --target=i686-pc-mingw32
--program-prefix= --with-as=/mingw/bin/as.exe
--- Comment #6 from d dot frey at gmx dot de 2008-02-28 08:14 ---
I looked at bug #99, but I am unsure whether this bug is really a dup of it.
#99 is about overloads and occurs with user types, while this bug is about
partial template specializations and occurs only with certain types
--- Comment #12 from benny at ammitzboell-consult dot dk 2008-02-28 08:18
---
We have now tried the 4.2.3 version of gcc and it generates the same assembler
code (objdump -d) for the example here on both the 32-bit and the 64-bit host.
The RTL is still different though, so it seems
I face a problem when trying to convert string to double numbers, when the
string represents a denormalized number.
I use g++ 4.2.2 on powerpc-ibm-aix5.3.0.0.
Example:
-
#include vector
#include sstream
#include iostream
int main() {
std::stringstream stream(5.6 0 0.205867 1.0809
--- Comment #4 from ubizjak at gmail dot com 2008-02-28 09:47 ---
Test case fails on x86_64:
Running target unix
FAIL: gcc.dg/tree-prof/pr34999.c compilation, -fprofile-use -D_PROFILE_USE
UNRESOLVED: gcc.dg/tree-prof/pr34999.c execution,-fprofile-use
-D_PROFILE_USE
--- Comment #3 from victork at gcc dot gnu dot org 2008-02-28 09:48 ---
I have no installed cygwin, could you check if this patch fixes the failure?
Index: gcc/testsuite/gcc.dg/vect/pr31041.c
===
---
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2008-02-28 10:12
---
Confirmed on i686-apple-darwin8.10.1 with mainline.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2008-02-28 10:10
---
Marking the bug as FIXED in 4.3.0 and later. Thanks for the bug report!
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from thomas dot orgis at awi dot de 2008-02-28 10:40 ---
Eh... one question: Does the fix in 4.3 just make the initialization with
REAL exponent work (Fortran 2003, AFAIK) or does it also fix the error message
when working in strict Fortran 95 mode (hm, I suppose there is
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2008-02-28 10:42
---
(In reply to comment #8)
There's more to it... using the result syntax for the function makes it fail
even with my patch
That's because the result symbol is not marked with attr.always_explicit, only
the
--- Comment #5 from ubizjak at gmail dot com 2008-02-28 09:55 ---
(In reply to comment #3)
I can only test in x86_64-unknown-linux-gnu.
make -k check RUNTESTFLAGS=--target_board=unix/-m32 will run the testsuite in
32bit mode.
BTW: make -j2 -k check
--- Comment #65 from ubizjak at gmail dot com 2008-02-28 11:29 ---
(In reply to comment #62)
The first situation was clearly better, but I was at work when Dominique
emailed my after my first commit, saying the new testcase FAILed, and I got
confused. I think I'll revert to the old
templateint
void foo()
{}
void test()
{
foo1(); // (1)
void (*func)() = foo1; // (2)
foo1;// (3)
void* d = (void*)foo1; // (4)
}
(1) and (2) are OK.
(3) fails with:
error: statement cannot resolve address of overloaded function
--- Comment #2 from jsm28 at gcc dot gnu dot org 2008-02-28 12:35 ---
Subject: Bug 33963
Author: jsm28
Date: Thu Feb 28 12:34:51 2008
New Revision: 132744
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132744
Log:
PR target/33963
* tree.c (handle_dll_attribute):
--- Comment #20 from d dot frey at gmx dot de 2008-02-28 12:42 ---
According to DR 425's proposed resolution, GCC is already doing the right
thing, so I'm closing this bug report.
--
d dot frey at gmx dot de changed:
What|Removed |Added
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2008-02-28 12:51
---
Reduced testcase:
$ cat bounds_check_9.f90
program main
call sub()
contains
subroutine set_optional(iopt)
integer, optional :: iopt(:)
end subroutine set_optional
subroutine sub(ivec)
integer,
--- Comment #5 from eres at il dot ibm dot com 2008-02-28 13:00 ---
I can not reproduce this fail on my local x86_64-unknown-linux-gnu machine:
PASS: gcc.dg/tree-prof/pr34999.c compilation, -fprofile-use -D_PROFILE_USE
PASS: gcc.dg/tree-prof/pr34999.c execution,-fprofile-use
--- Comment #6 from ubizjak at gmail dot com 2008-02-28 13:26 ---
(In reply to comment #5)
I can not reproduce this fail on my local x86_64-unknown-linux-gnu machine:
PASS: gcc.dg/tree-prof/pr34999.c compilation, -fprofile-use -D_PROFILE_USE
PASS: gcc.dg/tree-prof/pr34999.c
--- Comment #7 from eres at il dot ibm dot com 2008-02-28 13:49 ---
(In reply to comment #6)
(In reply to comment #5)
I appreciate any info on this ICE so I could try to fix it.
Sometimes --enable-checking=release triggers bugs that are hidden by other
--enable-checking settings.
--- Comment #66 from howarth at nitro dot med dot uc dot edu 2008-02-28
14:39 ---
I find that...
! { dg-xfail-if { *-*-freebsd* } { * } { } }
! { dg-xfail-if apple libc problems { powerpc*-apple-darwin* } {* } {-O0}
}
in gfortran.dg/large_real_kind_3.F90, still produces...
FAIL:
--- Comment #67 from ubizjak at gmail dot com 2008-02-28 14:54 ---
(In reply to comment #66)
in gfortran.dg/large_real_kind_3.F90, still produces...
It should be in reverse:
! { dg-xfail-if libc bug { powerpc*-apple-darwin* } { -O0 } { } }
-
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2008-02-28 15:43
---
Subject: Bug 34868
Author: fxcoudert
Date: Thu Feb 28 15:42:21 2008
New Revision: 132751
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132751
Log:
PR fortran/34868
* trans-expr.c
--- Comment #11 from fxcoudert at gcc dot gnu dot org 2008-02-28 15:44
---
Fixed on mainline.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2008-02-28 16:01
---
Tobias, what target and options are you compiling with? I can't reproduce this
on x86_64-linux...
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot
|dot org
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-02-28 16:47 ---
With the patch proposed for PR34043 we get
f:
.LFB2:
addss (%rdi), %xmm0
movd%xmm0, (%rsi)
ret
instead of
f:
.LFB2:
addss (%rdi), %xmm0
movss %xmm0, -4(%rsp)
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-02-28 16:47 ---
*** This bug has been marked as a duplicate of 11407 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from pinskia at gcc dot gnu dot org 2008-02-28 16:47
---
*** Bug 35398 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
Component|c++ |target
--- Comment #4 from tprince at computer dot org 2008-02-28 17:05 ---
With Victor's patch on SVN: trunk revision 132553 version 4.4.0 20080222:
PASS: gcc.dg/vect/pr31041.c (test for excess errors)
--
tprince at computer dot org changed:
What|Removed
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |blocker
GCC build triplet|powerpc-apple-darwin9 |
GCC host
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-02-28 17:10 ---
With the trunk, I get the following:
t.cc: In function 'int main()':
t.cc:9: warning: ignoring attributes applied to class type 'Foo' outside of
definition
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35380
--- Comment #16 from pinskia at gcc dot gnu dot org 2008-02-28 17:07
---
*** Bug 35387 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from pinskia at gcc dot gnu dot org 2008-02-28 17:07 ---
No, bug 99 has specialization too:
templateunsigned int n, unsigned int m
double ch(dummyn, dummym);
templateunsigned int n
double ch(dummyn, dummy0);
templateunsigned int m
double ch(dummy0, dummym);
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2008-02-28 17:57
---
One more remark: checking of intrinsics and compliance to the -std option
specified is lacking, and this is a generic issue of gfortran. Maybe there's a
PR open about it?
--
--- Comment #8 from ubizjak at gmail dot com 2008-02-28 18:34 ---
(In reply to comment #7)
Thanks, unfortunately I still can not reproduce the fail.
Probably you need newer binutils:
GNU ld (GNU Binutils) 2.18
Executing on host: /home/uros/gcc-build/gcc/xgcc
--- Comment #9 from ubizjak at gmail dot com 2008-02-28 19:12 ---
Created an attachment (id=15241)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15241action=view)
asm that crashes linker
gcc pr34999.s
gcc is configured with:
--with-pkgversion='Debian 4.3-20080227-1'
--with-bugurl='file:///usr/share/doc/gcc-4.3/README.Bugs'
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext
This is a regression probably introduced roughly three or four days ago,
unless it's due to a change in the codebase I'm building (which is Wine):
...gcc -Wtype-limits -O2 action.i
action.c: In function 'move_files_wildcard':
action.c:5232: internal compiler error: tree check: expected ssa_name,
--- Comment #2 from dfranke at gcc dot gnu dot org 2008-02-28 20:23 ---
Subject: Bug 33950
Author: dfranke
Date: Thu Feb 28 20:22:55 2008
New Revision: 132756
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132756
Log:
gcc/fortran:
2008-02-28 Daniel Franke [EMAIL PROTECTED]
--- Comment #6 from dfranke at gcc dot gnu dot org 2008-02-28 20:23 ---
Subject: Bug 31463
Author: dfranke
Date: Thu Feb 28 20:22:55 2008
New Revision: 132756
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132756
Log:
gcc/fortran:
2008-02-28 Daniel Franke [EMAIL PROTECTED]
--- Comment #3 from dfranke at gcc dot gnu dot org 2008-02-28 20:23 ---
Subject: Bug 34296
Author: dfranke
Date: Thu Feb 28 20:22:55 2008
New Revision: 132756
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132756
Log:
gcc/fortran:
2008-02-28 Daniel Franke [EMAIL PROTECTED]
--- Comment #7 from dfranke at gcc dot gnu dot org 2008-02-28 20:25 ---
Fixed in trunk. Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from gerald at pfeifer dot com 2008-02-28 20:25 ---
Created an attachment (id=15242)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15242action=view)
Testcase to reproduce
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35400
--- Comment #3 from dfranke at gcc dot gnu dot org 2008-02-28 20:25 ---
Fixed in trunk. Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from dfranke at gcc dot gnu dot org 2008-02-28 20:27 ---
Both issues fixed in trunk. Closing.
[The second issue, INTENT(out) not set, was already fixed earlier.]
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33950
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-on-valid-code
Summary|[4.4 regression] -Wtype-
I installed gcc4.3 20080221 onto an intel mac, core 2 duo, os x10.5.2 using
macports
The configure arguments (with prefix = /opt/local) are:
47 configure.args --enable-languages=c,c++,objc,obj-c++ \
48 --libdir=${prefix}/lib/${name} \
49
--- Comment #5 from tprince at computer dot org 2008-02-28 21:07 ---
(In reply to comment #3)
I have no installed cygwin, could you check if this patch fixes the failure?
Index: gcc/testsuite/gcc.dg/vect/pr31041.c
Testcase:
/* { dg-do compile } */
/* { dg-options -O2 -fdump-tree-optimized } */
static const int conststaticvariable;
int f(void)
{
return conststaticvariable;
}
/* There should be no reference to conststaticvariable as we should have
inlined the 0. */
/* { dg-final { scan-tree-dump-times
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-02-28 22:08 ---
Mine.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-02-28 22:26 ---
/* { dg-final { scan-tree-dump-times conststaticvariable o optimized} } */
that should be:
/* { dg-final { scan-tree-dump-times conststaticvariable 0 optimized} } */
:)
--
Testcase:
/* { dg-do compile } */
/* { dg-options -O2 -fdump-tree-optimized } */
static int conststaticvariable;
int f(void)
{
return conststaticvariable;
}
/* There should be no reference to conststaticvariable as we should have
inlined the 0
as IPA reference should have marked the
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35402
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-02-28 22:26 ---
Mine.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
I'm reporting this as an enhancement request to record a case where libcalls
are still used in the compiler.
Consider this test case:
extern long long bar();
long long foo () { return bar () | bar (); }
Compile it with -O2 -fno-wide-types. I'm using -fno-wide-types to permit using
a simple
--- Comment #1 from ian at airs dot com 2008-02-28 22:59 ---
Created an attachment (id=15244)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15244action=view)
Old patch for this issue
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35404
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2008-02-28 23:08
---
(In reply to comment #6)
I knew I was missing something :)
I try again... this time, with less ambition, just fix the case at hand... this
should not break anything (but... I can't regtest right now).
Index:
--- Comment #2 from manu at gcc dot gnu dot org 2008-02-29 00:12 ---
(In reply to comment #0)
This is a regression probably introduced roughly three or four days ago,
unless it's due to a change in the codebase I'm building (which is Wine):
...gcc -Wtype-limits -O2 action.i
--- Comment #3 from gerald at pfeifer dot com 2008-02-29 00:20 ---
The last one that I tested was 132756, and that one was broken. Or do you
mean 132591 might be the culprit?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35400
~g++-svn-4.3 troep.cc
troep.cc: In instantiation of âcheckint, Saveableâ:
troep.cc:38: instantiated from here
troep.cc:14: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2008-02-29
02:52 ---
This problem isn't just limited to libstdc++. I find that all of the shared
libraries created for gcc 4.3.0 are linked to the system libgcc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35401
--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2008-02-29
04:47 ---
Subject: Re: Cannot bootstrap Ada with host gnatmake-4.2
I tried the setenv change with 4.2.3. Had to apply the -larg -lgcc_eh
hack to Make-lang.in to do an initial bootstrap. After installing this
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2008-02-29 04:52
---
Need to update hollerith.f90 and hollerith_f95.f90, otherwise OK.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35009
--- Comment #10 from eres at il dot ibm dot com 2008-02-29 05:23 ---
(In reply to comment #8)
(In reply to comment #7)
Thanks, unfortunately I still can not reproduce the fail.
Probably you need newer binutils:
GNU ld (GNU Binutils) 2.18
Yes, using a newer binutils the fail is
--- Comment #11 from hjl dot tools at gmail dot com 2008-02-29 05:54
---
I don't think it is a linker bug. This bug looks very similar
to PR 34249. Uros, you fixed PR 34249. Maybe there is another
similar problem elsewhere in dwarf2.out.c.
--
--- Comment #12 from ubizjak at gmail dot com 2008-02-29 06:07 ---
(In reply to comment #11)
I don't think it is a linker bug. This bug looks very similar
to PR 34249. Uros, you fixed PR 34249. Maybe there is another
similar problem elsewhere in dwarf2.out.c.
The problem is in this
--- Comment #14 from ubizjak at gmail dot com 2008-02-29 06:47 ---
CC Jakub, perhaps he can give us a clue what goes wrong here.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #13 from ubizjak at gmail dot com 2008-02-29 06:32 ---
(In reply to comment #12)
If the marked line is changed to .long .LCOLDB2-.LCOLDB2 (or ..E2 - ..E2) the
compilation succeeds. However, looking through asm, it looks correct to me.
That is, the frame and label
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-02-29 07:26 ---
Because I am lazy and I don't have access right now to my ppc box, could
someone attach the preprocessed source?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
97 matches
Mail list logo
