Hi,
I have already finished CPU port named RICE. The previous version
I did is on gcc 4.0.2. it can be compiled. Now I wanna move it to
v4.3.0. I added the config script just as the CRX architechture.
But when run the configure,
export TARGET=rice-elf
export
daniel tian wrote:
/home/daniel.tian/gcc_rice_dev/rice-binutils/build-gcc-debug/./gcc/xgcc
-B/home/daniel.tian/gcc_rice_dev/rice-binutils/build-gcc-debug/./gcc/
-B/usr/local/cross/rice-elf/rice-elf/bin/
-B/usr/local/cross/rice-elf/rice-elf/lib/ -isystem
Hi All,
Our project is to optimize instruction scheduling in gcc. It
requires us to specify architecture information
(basically number of cycles per instruction, stall and branch delays)
to gcc, to optimize structural hazard detection.
Problem: Is there any specific format in which we
You've got to get in there with gdb and find out why
compute_frame_pointer_to_fb_displacement()
is erroring. There's no way to avoid this.
Thank you.
But I don't know how. I mean which execute file, even I can't find the
conftest.c file.
Sorry for asking this simple question.
You should check how to construct DFA for your target architecture.
Look at Specifying processor pipeline description in GCC internal
manual and checked out how other architectures do it.
-Bingfeng
-Original Message-
From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On
Hi ,
Follow this wiki http://gcc.gnu.org/wiki/DebuggingGCC; to know
how to debug gcc.
As far as I know compute_frame_pointer_to_fb_displacement is the
displacement between your
frame pointer and the frame base ( mostly stack pointer's location
after your prologue code - depends
2009/9/21 sumanth sumanth.gundapn...@redpinesignals.com:
Hi ,
Follow this wiki http://gcc.gnu.org/wiki/DebuggingGCC; to know how to
debug gcc.
As far as I know compute_frame_pointer_to_fb_displacement is the
displacement between your
frame pointer and the frame base ( mostly stack
daniel tian wrote:
2009/9/21 sumanth sumanth.gundapn...@redpinesignals.com:
Hi ,
Follow this wiki http://gcc.gnu.org/wiki/DebuggingGCC; to know how to
debug gcc.
As far as I know compute_frame_pointer_to_fb_displacement is the
displacement between your
frame pointer and the frame
I am pleased to announce that the GCC Steering Committee has
accepted the Lattice Mico32 port for inclusion in GCC. The initial
patch needs approval from a GCC GWP maintainer before it may be committed.
Happy hacking!
David
2009/9/21 Andrew Haley a...@redhat.com:
daniel tian wrote:
2009/9/21 sumanth sumanth.gundapn...@redpinesignals.com:
Hi ,
Follow this wiki http://gcc.gnu.org/wiki/DebuggingGCC; to know how to
debug gcc.
As far as I know compute_frame_pointer_to_fb_displacement is the
displacement
On Mon, Sep 21, 2009 at 05:04:27PM +0100, Hariharan wrote:
Hi Alexandre,
I was having some trouble with dwarf sections in picochip port. I am not
a dwarf expert, but when i loo...@the changes in r151312, file
dwarf2out.c, function dwarf2out_var_location on line 17965, we have
On 09/14/2009 11:54 AM, Jason Merrill wrote:
I think the way to go with this is to revert the compiler bits of
r149964, not mess with mangle.c at all, and insert the initial * if the
typeinfo name won't have TREE_PUBLIC set, since that's precisely the
property we want to mirror in comparison.
What version of GCC will build for a cross --target=armv4t-linux-eabi,
which I believe is the right code for an ixp425 processor? The host
compiler is gcc-4.3.3 on a Linux-debian-test system. I have also tried
unsuccessfully tried the armv5t target, with similar results.
I have tried numerous
On Mon, Sep 21, 2009 at 11:54:17AM -0600, Kevin Handy wrote:
What version of GCC will build for a cross --target=armv4t-linux-eabi,
which I believe is the right code for an ixp425 processor? The host
compiler is gcc-4.3.3 on a Linux-debian-test system. I have also tried
unsuccessfully tried
So aren't we now likely to lose the first few days of what little remains
of
stage 1 waiting for trunk to start working again, then have a mad rush of
people falling all over each other to get their new features in in the last
couple of days? One of which will inevitably break trunk again
On Mon, 2009-09-21 at 13:06 -0400, Jason Merrill wrote:
On 09/14/2009 11:54 AM, Jason Merrill wrote:
I think the way to go with this is to revert the compiler bits of
r149964, not mess with mangle.c at all, and insert the initial * if the
typeinfo name won't have TREE_PUBLIC set, since
daniel tian daniel.xnt...@gmail.com writes:
I have already finished CPU port named RICE. The previous version
I did is on gcc 4.0.2. it can be compiled. Now I wanna move it to
v4.3.0. I added the config script just as the CRX architechture.
configure:2379: $? = 1
configure:2398:
On Mon, Sep 21, 2009 at 11:23:11AM -0700, Cary Coutant wrote:
So aren't we now likely to lose the first few days of what little
remains of
stage 1 waiting for trunk to start working again, then have a mad rush of
people falling all over each other to get their new features in in the
On 09/21/2009 02:43 PM, Jerry Quinn wrote:
Another approach could be to use 2 different names for anonymous
namespaces that should and should not be compared by pointer. I don't
like the speed implications, but it might work.
Any type that involves the anonymous namespace should be compared
It turns out that IRIX and OSF have not managed to keep Rainer Orth
sufficiently busy after I sent
http://gcc.gnu.org/ml/gcc/2006-07/msg00654.html
so I am pleased to announce that the steering committee is appointing
him maintainer for our Solaris ports as well. :-)
Please update MAINTAINERS
On Mon, Sep 21, 2009 at 05:04:27PM +0100, Hariharan wrote:
Hi Alexandre,
I was having some trouble with dwarf sections in picochip port. I am not
a dwarf expert, but when i looked at the changes in r151312, file
dwarf2out.c, function dwarf2out_var_location on line 17965, we have
Hi,
What is the proper type to use in an Ada binding
for a C method that returns a C99 bool?
This appears to be an issue in s-stchop-rtems.adb
where it binds to the C routine:
bool rtems_stack_checker_is_blown( void )
Thanks.
--
Joel Sherrill, Ph.D. Director of Research
Are you saying that current gcc trunk should require -gdwarf-4
to issue dwarf4 commands? I ask because r151815...
http://gcc.gnu.org/ml/gcc-patches/2009-09/msg00220.html
causes dwarf4 by default. Is there a consistent policy on this?
Currently in PR41405, there is a proposal for a
extensibility, this isn't a problem for these extensions, as older
DWARF readers will simply ignore the location expressions that use the
extensions -- which produces the same behavior as DWARF-2 without
those extensions.
I said will simply ignore when I guess I should have said should
simply
Florian Weimer f...@deneb.enyo.de writes:
G++ currently accepts the following code:
char *
alloc(unsigned a, unsigned b)
{
typedef char array[a];
return **(new array[b]);
}
Is this intentional? The equivalent new char[a][b] is rejected (as
required by the C++ standard).
Is there
Amker.Cheng amker.ch...@gmail.com writes:
In function new_ready, it calls to min_insn_conflict_delay with
min_insn_conflict_delay (curr_state, next, next).
But the function's comments say that it returns minimal delay of issue of
the 2nd insn after issuing the 1st in given state.
Why the
On Mon, Sep 21, 2009 at 4:56 PM, Ian Lance Taylor i...@google.com wrote:
Florian Weimer f...@deneb.enyo.de writes:
G++ currently accepts the following code:
char *
alloc(unsigned a, unsigned b)
{
typedef char array[a];
return **(new array[b]);
}
Is this intentional? The equivalent
Thanks for the pointer, Jakub.
Cheers
Hari
Jakub Jelinek wrote:
On Mon, Sep 21, 2009 at 05:04:27PM +0100, Hariharan wrote:
Hi Alexandre,
I was having some trouble with dwarf sections in picochip port. I am not
a dwarf expert, but when i looked at the changes in r151312, file
On Sun, Sep 20, 2009 at 01:49:39PM -0400, Andrew Hutchinson wrote:
All,
I have been debugging AVR port to see why we fail to match so many bit
test opportunities.
When dealing with longer modes I have come across a problem I can not solve.
Expansion in RTL for a bit test can produce two
Thank you so much for your information!
I will investigate your patch.
(I just hacked lowpart_for_combine to allow lowering something larger
than word and the subreg matched no problem.)
It looks like RTL generation is somewhat odd and not helping.
My test used
extern long x;
if (x 1)
Why doesn't combine try matching unsimplified expressions when it fails?
This would at least permit creating patterns based on explicit format
of input RTL without the added vagaries of simplification
Andy
Joern Rennecke wrote:
On Sun, Sep 20, 2009 at 01:49:39PM -0400, Andrew Hutchinson
--- Comment #3 from jakub at gcc dot gnu dot org 2009-09-21 06:58 ---
I think it is an assembler bug, unless GOTPCREL is only allowed for non-local
symbols (then it would be testcase author's fault).
GOTPCREL which is address of a pointer to the symbol should never be resolved
to
the
--- Comment #20 from jakub at gcc dot gnu dot org 2009-09-21 07:01 ---
Wonder why gcc on darwin should always work around darwin toolchain bugs, but
on most other OSes if you have bugs in tools, you just require those bugs to be
fixed, gcc doesn't work around them. What is so special
--- Comment #5 from burnus at gcc dot gnu dot org 2009-09-21 07:45 ---
Thank you for your response. I would appreciate very much if you could you
please supply me with a web site and the name of the particular version of
binutils.
The generic place is
--- Comment #4 from davek at gcc dot gnu dot org 2009-09-21 07:53 ---
(In reply to comment #3)
First off, do you happen to know whether this is a regression?
'fraid not, I never thought to try this before.
Then, please show more of the build output of the failing build:
--- Comment #3 from rwild at gcc dot gnu dot org 2009-09-21 07:46 ---
First off, do you happen to know whether this is a regression?
Then, please show more of the build output of the failing build:
everything starting from toplevel target 'configure-target-libgomp'.
You can recreate
--- Comment #21 from dominiq at lps dot ens dot fr 2009-09-21 08:05 ---
Changed the subject to reflect the comments.
[this might not be quite enough; backing out of only 151814-151815 for trunk
version 151904 produced a working bootstrap but with still some dsymutil
fails].
I don't
--- Comment #22 from jakub at gcc dot gnu dot org 2009-09-21 08:40 ---
Created an attachment (id=18620)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18620action=view)
gcc45-pr41404.patch
This fixes the bug, unfortunately doesn't do any good with CONST_STRINGs.
CONST_STRING as
--- Comment #4 from scott dot gccbugs dot 2009 at scottrix dot co dot uk
2009-09-21 08:46 ---
Thanks for the help, I have got the intermediate files out and can see what you
mean. I'll raise the issue with binutils. Again, thanks for the help and very
quick response.
--
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41399
--- Comment #22 from developer at sandoe-acoustics dot co dot uk
2009-09-21 09:04 ---
Dominique has confirmed what I've found, that some changes beyond
151814-151815 are also significant.
test results for powerpc-apple-darwin8 and i686-apple-darwin9
--- Comment #6 from burnus at gcc dot gnu dot org 2009-09-21 10:04 ---
(In reply to comment #5)
Please mark the bug as user error.
Sorry for the false alert.
Great that it now works for you. (Closed as INVALID.)
--
burnus at gcc dot gnu dot org changed:
What
--- Comment #23 from jakub at gcc dot gnu dot org 2009-09-21 10:22 ---
Created an attachment (id=18621)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18621action=view)
gcc45-pr41405.patch
Patch implementing -gstrict-dwarf (darwin would need to set it to 1 unless
explicitly set on
--- Comment #1 from xxcv07 at gmail dot com 2009-09-21 10:25 ---
Looks like I may have made a mistake in compiling a library which was causing
this issue, will report back later.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41424
--- Comment #2 from xxcv07 at gmail dot com 2009-09-21 10:47 ---
Sorry about this invalid report, my mistake in building ffmpeg.
--
xxcv07 at gmail dot com changed:
What|Removed |Added
--- Comment #14 from t7 at gmail dot com 2009-09-21 11:05 ---
I can confirm this is fixed in gcc-4_4-branch.
Thank you.
--
t7 at gmail dot com changed:
What|Removed |Added
If I cast an int to the enum type all values outside the enum triggers the
first case-statement.
The number of enum values is important. It must be a power of 2.
This works in GCC 4.3.4.
--
Summary: switch with enums doesn't work
Product: gcc
Version: 4.4.1
--- Comment #24 from dominiq at lps dot ens dot fr 2009-09-21 12:19 ---
Patch implementing -gstrict-dwarf (darwin would need to set it to 1 unless
explicitly set on the command line). I went through all the DWARF 3 and DWARF
4 additions used by dwarf2out.c, except DW_CFA_* so far.
--- Comment #1 from Woebbeking at web dot de 2009-09-21 12:19 ---
Created an attachment (id=18622)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18622action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41425
--- Comment #2 from Woebbeking at web dot de 2009-09-21 12:21 ---
g++ case.cpp is sufficient to reproduce this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41425
--
Woebbeking at web dot de changed:
What|Removed |Added
Severity|normal |critical
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41425
--- Comment #3 from paolo dot carlini at oracle dot com 2009-09-21 12:41
---
As far as I can see, you are triggering undefined behavior. Per 5.2.9/7: A
value of integral or enumeration type can be explicitly converted to an
enumeration type. The value is unchanged if the original value
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Severity|critical|normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41425
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-09-21 12:44 ---
In C++ an enum type only has the minimum number of bits that is required to
store all its values, thus 1 in your case. So (foo)5 is a truncation.
--
rguenth at gcc dot gnu dot org changed:
What
--- Comment #25 from developer at sandoe-acoustics dot co dot uk
2009-09-21 12:45 ---
(In reply to comment #23)
Created an attachment (id=18621)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18621action=view) [edit]
gcc45-pr41405.patch
thanks for the patch.
I bootstrapped
I think g++ simplifies too early array types into pointers when looking for a
conversion sequence in a return statement.
---
struct B
{
B (int (v)[10]);
B();
};
B g2()
{
int c[10];
return c;
}
---
results in
test.cc: In function B g2():
test.cc:10: error: conversion from
--- Comment #5 from Woebbeking at web dot de 2009-09-21 12:53 ---
Paolo, but std::cout static_castfoo(i); prints 5, so it's not the
conversion but the switch statement which is broken.
Richard, if it's only truncation shouldn't case B be triggered?
--
--- Comment #11 from ubizjak at gmail dot com 2009-09-21 13:02 ---
Another week, another patch in testing:
Index: c-typeck.c
===
--- c-typeck.c (revision 151915)
+++ c-typeck.c (working copy)
@@ -9465,6 +9465,7 @@
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-09-21 13:08 ---
Switch assembly is optimized if you handle all valid cases (which you do) into
if (i != 0)
case B
else
case A
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41425
--- Comment #2 from mahatma at eu dot by 2009-09-21 13:08 ---
(In reply to comment #1)
Can you provide the preprocessed source?
Yes. After make/error:
http://mahatma.bspu.unibel.by/download/transit/glibc-2.10.1-error.tar.bz2
(gentoo flavored, sorry)
New info: it happened on -O2 or
--- Comment #3 from mahatma at eu dot by 2009-09-21 13:12 ---
Created an attachment (id=18623)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18623action=view)
linux-2.6.31 deconfig x86_64 error
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41025
Consider this code:
void f1()
{
for (int i = 0;;)
int i;
}
void f2()
{
for (int i = 0;;)
{
int i;
}
}
void f3()
{
for (int i = 0;;)
{
{
int i;
}
}
}
Only f3() should compile, yet f1() and f2() compile too.
While f1()
extern C void abort (void);
inline void *operator new (__SIZE_TYPE__, void *__p) throw () { return __p; }
int __attribute__((noinline))
foo(void)
{
float f = 0;
int *i = new (f) int (1);
return *(int *)f;
}
CCP produces
bb 2:
f = 0.0;
D.2121_3 = f;
D.2107_4 = (int *) f;
if
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-09-21 14:06 ---
Mine. I'm going to disentangle the maze in substitute_and_fold by introducing
another hook in the generic SSA propagator to fold a stmt.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-09-21 14:22 ---
*** This bug has been marked as a duplicate of 2288 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pinskia at gcc dot gnu dot org 2009-09-21 14:22 ---
*** Bug 41427 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #26 from developer at sandoe-acoustics dot co dot uk
2009-09-21 14:24 ---
(In reply to comment #23)
Created an attachment (id=18621)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18621action=view) [edit]
gcc45-pr41405.patch
as pre previous comment - this bootstraps
--- Comment #7 from schwab at linux-m68k dot org 2009-09-21 14:25 ---
(In reply to comment #3)
As far as I can see, you are triggering undefined behavior.
There is a big difference between undefined and unspecified behaviour. With
unspecified behaviour the implementation must chose a
--- Comment #8 from paolo dot carlini at oracle dot com 2009-09-21 14:45
---
Agreed, unspecified, as the actual citation says.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41425
Somewhere between mainline revision 151676 and 151704 I started getting several
gomp failures which manifest as timeouts in the testsuite when using
-fpic/-fPIC.
Here are the differing testsuite results:
Clean: http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg01244.html
FAIL:
--- Comment #1 from ghazi at gcc dot gnu dot org 2009-09-21 15:04 ---
To reproduce, target x86_64-unknown-linux-gnu and compile g++.dg/gomp/pr37189.C
with:
cc1plus -quiet -v pr37189.C -dumpbase pr37189.C -mtune=generic -auxbase pr37189
-version -fopenmp -fpic -o pr37189.s
Somewhere between mainline revisions 151661 and 151676 I started getting new
testsuite failures from objc++ as shown here:
Clean: http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg01158.html
FAIL: http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg01244.html
The new failures are:
FAIL:
--- Comment #27 from jakub at gcc dot gnu dot org 2009-09-21 15:37 ---
I believe I've caught all DW_OP_{implicit,stack}_value uses in dwarf2out.c, so
likely -gstrict-dwarf wasn't used when compiling something that has been linked
into those libraries.
No idea if Mach-O has any tools
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-09-21 15:59 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jason at gcc dot gnu dot org 2009-09-21 16:11 ---
Subject: Bug 41421
Author: jason
Date: Mon Sep 21 16:11:26 2009
New Revision: 151932
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151932
Log:
PR c++/41421
* tree.c (trivial_type_p): Fix logic.
--- Comment #3 from janis at gcc dot gnu dot org 2009-09-21 16:22 ---
Subject: Bug 41049
Author: janis
Date: Mon Sep 21 16:22:43 2009
New Revision: 151934
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151934
Log:
PR c/41049
* real.c decimal_from_integer,
--- Comment #3 from jason at gcc dot gnu dot org 2009-09-21 16:30 ---
Fixed, thanks.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from nightstrike at gmail dot com 2009-09-21 16:30 ---
Current list:
../../../../../build/gcc/gcc/libgfortran/io/list_read.c:1847:10: warning:
variable 'elem' might be clobbered by 'longjmp' or 'vfork'
../../../../../build/gcc/gcc/libgfortran/io/list_read.c:1849:10:
--- Comment #16 from nightstrike at gmail dot com 2009-09-21 16:33 ---
(In reply to comment #14)
Subject: Bug 41219
Author: jvdelisle
Date: Sat Sep 12 15:08:27 2009
New Revision: 151653
As of r151914, this warning still exists when the host=linux64 and the
target=win64.
--
--- Comment #4 from rwild at gcc dot gnu dot org 2009-09-21 16:44 ---
With PR 35619 fixed in trunk it works fine for me to build in the source tree.
Feel free to Cc: me on new bugs arising from an in-tree build.
(Leaving bug open as it addresses 4.4 not trunk.)
--
--- Comment #9 from Woebbeking at web dot de 2009-09-21 16:46 ---
So it's ok to change the behavior in a minor release?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41425
--- Comment #28 from developer at sandoe-acoustics dot co dot uk
2009-09-21 16:46 ---
(In reply to comment #27)
I believe I've caught all DW_OP_{implicit,stack}_value uses in dwarf2out.c, so
likely -gstrict-dwarf wasn't used when compiling something that has been
linked
into those
--- Comment #17 from burnus at gcc dot gnu dot org 2009-09-21 17:01 ---
../../../../../build/gcc/gcc/libgfortran/intrinsics/iso_c_binding.c:98:24:
warning: 'str' may be used uninitialized in this function
I think this warning is bogus:
index_type size, str;
for (i = 0; i
--- Comment #29 from howarth at nitro dot med dot uc dot edu 2009-09-21
17:07 ---
Do we even know for certain that older versions of bintuils really work
properly with the newer dwarf3/dwarf4? I wonder how much of the general
instability in the recent bootstraps might be related these
--- Comment #30 from jakub at gcc dot gnu dot org 2009-09-21 17:25 ---
Yes, we know for certain binutils are fine.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41405
--
ktietz at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #3 from ubizjak at gmail dot com 2009-09-21 17:34 ---
The testcase compiles OK with 4.3.5, 4.4.2 and 4.5.0.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #18 from nightstrike at gmail dot com 2009-09-21 17:36 ---
(In reply to comment #17)
../../../../../build/gcc/gcc/libgfortran/intrinsics/iso_c_binding.c:98:24:
warning: 'str' may be used uninitialized in this function
I think this warning is bogus:
index_type
--- Comment #4 from ktietz at gcc dot gnu dot org 2009-09-21 17:36 ---
By using this code and compiling with gcc test.c -O2 I can reproduce this for
i686-pc-linux, x86_64-pc-linux, x86_64-pc-mingw32, and for i686-pc-mingw32.
--
ktietz at gcc dot gnu dot org changed:
What
--- Comment #5 from davek at gcc dot gnu dot org 2009-09-21 17:44 ---
Created an attachment (id=18624)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18624action=view)
good rebuild log
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41418
--- Comment #6 from davek at gcc dot gnu dot org 2009-09-21 17:44 ---
Created an attachment (id=18625)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18625action=view)
bad rebuild log
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41418
--- Comment #7 from Ralf dot Wildenhues at gmx dot de 2009-09-21 17:51
---
Subject: Re: Can't build libgomp without
--enable-languages=fortran
* davek at gcc dot gnu dot org wrote on Mon, Sep 21, 2009 at 07:44:49PM CEST:
Created an attachment (id=18625)
--
--- Comment #8 from davek at gcc dot gnu dot org 2009-09-21 17:57 ---
Created an attachment (id=18626)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18626action=view)
good config log
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41418
--- Comment #9 from davek at gcc dot gnu dot org 2009-09-21 17:57 ---
Created an attachment (id=18627)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18627action=view)
bad config log
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41418
--- Comment #19 from kargl at gcc dot gnu dot org 2009-09-21 18:01 ---
(In reply to comment #18)
(In reply to comment #17)
../../../../../build/gcc/gcc/libgfortran/intrinsics/iso_c_binding.c:98:24:
warning: 'str' may be used uninitialized in this function
I think this
--- Comment #2 from jakub at gcc dot gnu dot org 2009-09-21 18:06 ---
Created an attachment (id=18628)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18628action=view)
gcc45-pr41429.patch
Patch I'm going to bootstrap/regtest.
--
jakub at gcc dot gnu dot org changed:
--- Comment #20 from nightstrike at gmail dot com 2009-09-21 18:12 ---
(In reply to comment #19)
(In reply to comment #18)
(In reply to comment #17)
../../../../../build/gcc/gcc/libgfortran/intrinsics/iso_c_binding.c:98:24:
warning: 'str' may be used uninitialized in this
--- Comment #11 from jakub at gcc dot gnu dot org 2009-09-21 18:32 ---
The #c10 problem is that df marks pseudo 60 used last in j += i; (and then just
in 2 DEBUG_INSNs following it) as REG_DEAD in that instruction and drops the
DEBUG_INSN uses below it on the floor.
--
--- Comment #4 from joel at gcc dot gnu dot org 2009-09-21 18:45 ---
The patch allowed my build of sparc-rtems4.10 C/C++ to complete.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41411
--- Comment #31 from developer at sandoe-acoustics dot co dot uk
2009-09-21 18:50 ---
OK. this is what I've done
(a) bootstrapped with Jakub's path but modified thus
Common Report Var(dwarf_strict) Init(1)
- bootstrap succeeds (with the four errors mentioned in #26).
(b) I then
1 - 100 of 111 matches
Mail list logo
