Hi
For example i hear that native posix threads has portions of it implemented in
kernel and also requires glibc support. In such cases if i attempt to run an
application compiled with gcc-4 on a linux-2.4 kernel, wont there be problems??
With changes in binutils, would there be changes in the
Hi!
extern void bar (void) __attribute__((visibility (hidden)));
void foo (void)
{
bar ();
bar ();
}
compiled on ppc64-linux with -O2 -m64 -mminimal-toc
leads to bl bar without nop in the following instruction
and to sibling call.
Now, when this together with bar's definition is linked
into a
Jakub Jelinek writes:
Jakub compiled on ppc64-linux with -O2 -m64 -mminimal-toc
Jakub leads to bl bar without nop in the following instruction
Jakub and to sibling call.
Jakub Now, when this together with bar's definition is linked
Jakub into a big binary and foo and bar need to have different
On 6/25/07, David Edelsohn [EMAIL PROTECTED] wrote:
Just out of curiosity, are you using a version of GCC with or
without the section anchor support? Is the application still overrunning
the TOC with sectcion anchors?
I have access to programs that overflow the TOC even with section
As for C++, I think we need more OO language specific
optimizations. I don't know what the status of
devirtualizion which was reported on the previous
summit.
Sorry for the late replay.
The devirtualization is on hold. Currently GCC is lacking the necessary
infrastructure needed by C++
On Mon, Jun 25, 2007 at 07:32:48AM -0400, David Edelsohn wrote:
Jakub Jelinek writes:
Jakub compiled on ppc64-linux with -O2 -m64 -mminimal-toc
Jakub leads to bl bar without nop in the following instruction
Jakub and to sibling call.
Jakub Now, when this together with bar's definition is
Jakub Jelinek wrote:
Hi!
extern void bar (void) __attribute__((visibility (hidden)));
void foo (void)
{
bar ();
bar ();
}
compiled on ppc64-linux with -O2 -m64 -mminimal-toc
leads to bl bar without nop in the following instruction
and to sibling call.
Shouldn't -mminimal-toc also
Mark Mitchell writes:
Mark I think the DECL_EXTERNAL case should go before the visibility checks in
Mark default_binds_local_p_1. A DECL_EXTERNAL entity never binds locally.
Jakub,
Do you want to follow up with a patch to change the ordering of
tests in default_binds_local_p_1()?
On Mon, Jun 25, 2007 at 09:31:14AM -0400, Mark Mitchell wrote:
David Edelsohn wrote:
/* If defined in this object and visibility is not default, must be
local. */
else if (DECL_VISIBILITY (exp) != VISIBILITY_DEFAULT)
local_p = true;
Why does binds_local_p return true
On Mon, Jun 25, 2007 at 09:15:40AM -0400, David Edelsohn wrote:
Emitting a NOP depends on SYMBOL_FLAG_LOCAL.
if (targetm.binds_local_p (decl))
flags |= SYMBOL_FLAG_LOCAL;
PPC64 uses the default binds_local_p() hook, default_binds_local_p_1():
/* If defined in this object
Mark Mitchell writes:
Mark That would be my recommendation: limit optimizations that require a
Mark short branch to calls to functions in the same translation unit, not
Mark just in the same shared object. But, that's just my two cents; the
Mark Power maintainers might have a different take.
[EMAIL PROTECTED] wrote:
Hi
For example i hear that native posix threads has portions of it implemented in
kernel and also requires glibc support. In such cases if i attempt to run an
application compiled with gcc-4 on a linux-2.4 kernel, wont there be problems??
With changes in binutils,
Emitting a NOP depends on SYMBOL_FLAG_LOCAL.
if (targetm.binds_local_p (decl))
flags |= SYMBOL_FLAG_LOCAL;
PPC64 uses the default binds_local_p() hook, default_binds_local_p_1():
/* If defined in this object and visibility is not default, must be
local. */
else if
David Edelsohn wrote:
/* If defined in this object and visibility is not default, must be
local. */
else if (DECL_VISIBILITY (exp) != VISIBILITY_DEFAULT)
local_p = true;
Why does binds_local_p return true for non-default visibility?
I was just about to ask that.
It's an
On Mon, Jun 25, 2007 at 07:06:01AM -0400, Jakub Jelinek wrote:
Hi!
extern void bar (void) __attribute__((visibility (hidden)));
void foo (void)
{
bar ();
bar ();
}
compiled on ppc64-linux with -O2 -m64 -mminimal-toc
leads to bl bar without nop in the following instruction
and to
Daniel Jacobowitz wrote:
I think the DECL_EXTERNAL case should go before the visibility checks in
default_binds_local_p_1. A DECL_EXTERNAL entity never binds locally.
That isn't the meaning that most callers of this function want,
however. They want same shared object, which is what it
Hello Andreas,
Hello Jeff,
I have recently started on implementing processor pipeline model for
m68k target. At this point I am trying to figure out the best way of
annotating instructions in m68k.md, so that appropriate cpu unit
reservations could be assigned to each one of them.
The
On Jun 24, 2007, at 16:20, Eric Botcazou wrote:
Indeed. It would be interesting to confirm whether or not a copy
of gcc
bootstrapped with a non-gcc compiler matched byte-for-byte with a
copy
of gcc bootstrapped from gcc.
I just made the experiment on an old SPARC/Solaris 2.5.1 machine
On Mon, Jun 25, 2007 at 10:15:55AM -0400, Mark Mitchell wrote:
Daniel Jacobowitz wrote:
I think the DECL_EXTERNAL case should go before the visibility checks in
default_binds_local_p_1. A DECL_EXTERNAL entity never binds locally.
That isn't the meaning that most callers of this
Jakub Jelinek wrote:
For replacability the current definition is just fine. Weak functions
must be assumed to be always replaceable and non-weak functions which are
known to bind within the same executable resp. shared library are not
replaceable - linker will issue error if two non-weak
Mark Mitchell writes:
Mark Good point -- if there's no definition in the current translation unit,
Mark then I guess we aren't going to make any bad assumptions about the
Mark contents of the function. So, I guess that just means that the Power
Mark back end needs to check for !DECL_EXTERNAL in
David Edelsohn wrote:
Mark Mitchell writes:
Mark Good point -- if there's no definition in the current translation unit,
Mark then I guess we aren't going to make any bad assumptions about the
Mark contents of the function. So, I guess that just means that the Power
Mark back end needs to
Hi All,
I am looking for an open source compiler, such as GCC, Open64, Scale
and SUIF, as the infrastructure of my research. Though I have read
some of their documents, they are still complicate to me and it is
difficult to decide which one is better. Can you please help me to
compare these
On Mon, Jun 25, 2007 at 12:48:10PM -0400, Mark Mitchell wrote:
I was suggesting leaving the hook alone, but modifying the test for the
sibling call optimization in rs6000_function_ok_for_sibcall to:
!DECL_EXTERNAL (decl) binds_local_p (decl)
In other words, per Jakub's argument,
Jiahua He wrote:
Hi All,
I am looking for an open source compiler, such as GCC, Open64, Scale
and SUIF, as the infrastructure of my research. Though I have read
some of their documents, they are still complicate to me and it is
difficult to decide which one is better. Can you please help me to
2007/6/25, Basile STARYNKEVITCH [EMAIL PROTECTED]:
Jiahua He wrote:
Hi All,
I am looking for an open source compiler, such as GCC, Open64, Scale
and SUIF, as the infrastructure of my research. Though I have read
some of their documents, they are still complicate to me and it is
difficult
Still, if you use these two bootstrapped, slightly different compilers
as base for a fresh bootstrap in a new build directory, you'll likely
get identical results and that would still prove that there is no
self-propagating back door in GCC on that configuration.
Probably. But, as Mike told
Jakub Jelinek writes:
Jakub I guess the right thing to do would be to replace the current
Jakub 3 uses of SYMBOL_REF_LOCAL_P (x) macro in config/rs6000/*.md
Jakub with
Jakub SYMBOL_REF_LOCAL_P (x) (!TARGET_ARCH64 || !SYMBOL_REF_EXTERNAL_P (x))
Jakub where TARGET_ARCH64 is replaced by whatever
On Jun 25, 2007, at 10:59 AM, Eric Botcazou wrote:
Probably. But, as Mike told me privately, STABS are sensitive to
the build
directory, so I tried again and got identical executables byte-for-
byte:
Cool. Glad you could verify them on a byte for byte basis. This
helps keep your
On Mon, Jun 18, 2007 at 02:08:15PM -0700, H. J. Lu wrote:
On Mon, Jun 18, 2007 at 11:10:43AM -0700, Steve Ellcey wrote:
BTW: IA64 has the same issues with two FP types (long double XFmode and
longer double TFmode). How is this solved for IA64?
Uros.
This is different on IA64
Hello,
This email is to follow up on your communication with the Free Software
Foundation. Previously, you had expressed interest in contributing to
the GNU Project. If this is still the case please respond so that we
can move the process along. If you did not receive the assignment
please let us
I thought I have completed it earlier. Can you check for me? Thanks!
Hui-May Chang
On Jun 25, 2007, at 3:14 PM, Jonas Jacobson via RT wrote:
Hello,
This email is to follow up on your communication with the Free
Software
Foundation. Previously, you had expressed interest in contributing to
On Jun 25, 2007, at 3:31 PM, Hui-May Chang via RT wrote:
I thought I have completed it earlier. Can you check for me? Thanks!
Don't worry, they just spammed the entire list with a seemingly off-
list issue I think they just meant to ping Francois.
On Jun 25, 2007, at 3:31 PM, Hui-May Chang via RT wrote:
I thought I have completed it earlier. Can you check for me? Thanks!
Don't worry, they just spammed the entire list with a seemingly off-
list issue I think they just meant to ping Francois.
On Jun 25, 2007, at 3:31 PM, Hui-May Chang via RT wrote:
I thought I have completed it earlier. Can you check for me? Thanks!
Don't worry, they just spammed the entire list with a seemingly off-
list issue I think they just meant to ping Francois.
Snapshot gcc-4.1-20070625 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20070625/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
The following program causes an endless loop in gfortran.
I'm not 100% sure that it is invalid though I think it is.
- NAG f95 accepts the program and prints:
- g95: Error: Circular specification in variable 'ouch' at (1)
- ifort:
fortcom: Error: cyclic_specs1.f90, line 10: Conflicting
The program compiles in 2 to 3 seconds with g95, f95 and sunf95; ifort needs 7
seconds.
gfortran I stopped after 2GB memory consumption after ~1 minute.
--
Summary: Endless loop when compiling
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
--- Comment #1 from burnus at gcc dot gnu dot org 2007-06-25 06:50 ---
Created an attachment (id=13781)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13781action=view)
fft257.f90 test case
From http://home.comcast.net/~kmbtib/
--
--- Comment #14 from bonzini at gnu dot org 2007-06-25 07:01 ---
wrong bug marked as duplicate... reopening...
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #6 from bonzini at gnu dot org 2007-06-25 07:02 ---
*** This bug has been marked as a duplicate of 30563 ***
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #15 from bonzini at gnu dot org 2007-06-25 07:02 ---
*** Bug 30537 has been marked as a duplicate of this bug. ***
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #16 from bonzini at gnu dot org 2007-06-25 07:03 ---
... to close as fixed
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|REOPENED
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-25 06:58 ---
h1 =
(/(sum((/(exp(-2*pi*(0,1)*mod(k*L,N)/N)*h2(L),L=0,N-1)/)),k=0,N-1)/)
Seen this before
I think this is the same bug as something I filed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32489
I believe this is not what gcc was supposed to do.
The code below produces a segmentation fault. I have written the reason of the
segmentation fault in a comment block toward the end of the code below.
And I don't think this is how gcc is supposed to behave.
#include unistd.h
#include stdio.h
Greetings,
Please consider the scenario below:
Since i'm using -ffunction-sections and -fdata-sections, my segments are put
int (.text.*) and (.data.*) instead of just (.text) and (.data). This results
in arm-elf-size outputs as follows:
When I use 'arm-elf-size -B' I get:
arm-elf-size -B
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-25 07:22 ---
b+4096 is the same as (typeof(b)) ( ((char*)b) + 4096 * sizeof(*b) ) which is
not you wanted.
You should write it as:
(chunk*) ( ((char*)b) + 4096+sizeof(chunk) )
--
pinskia at gcc dot gnu dot org changed:
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-25 07:29 ---
The size program is not part of GCC but part of binutils, report this issue to
them: http://www.sourceware.org/bugzilla/ .
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from ftwilliam at gmail dot com 2007-06-25 07:39 ---
(In reply to comment #1)
b+4096 is the same as (typeof(b)) ( ((char*)b) + 4096 * sizeof(*b) ) which is
not you wanted.
You should write it as:
(chunk*) ( ((char*)b) + 4096+sizeof(chunk) )
Thank you very much
--- Comment #2 from fink at racemouse dot net 2007-06-25 07:57 ---
(In reply to comment #1)
The size program is not part of GCC but part of binutils, report this issue to
them: http://www.sourceware.org/bugzilla/ .
You're ofcourse right. I wasn't thinking. Please delete this report
--- Comment #3 from burnus at gcc dot gnu dot org 2007-06-25 08:02 ---
Seen this before
I think this is the same bug as something I filed.
I found it (PR31301) after looking for closed bugs; it was marked as duplicate
of
PR31301.
*** This bug has been marked as a duplicate of
--- Comment #7 from burnus at gcc dot gnu dot org 2007-06-25 08:02 ---
*** Bug 32489 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20923
--- Comment #28 from rearnsha at gcc dot gnu dot org 2007-06-25 08:06
---
(In reply to comment #27)
As for the code size regression, Richard E., have you had a chance to identify
a specific CSiBE file that expands, so that Zdenek can look at that?
There were a number of files
--- Comment #3 from burnus at gcc dot gnu dot org 2007-06-25 09:53 ---
Could you try it with gfortran 4.3, available from:
http://gcc.gnu.org/wiki/GFortranBinaries
As this is fixed in 4.3 and it is neither a regression nor a wrong-code bug, I
don't think we will fix it for 4.2 due to
gcc: warning: -pipe ignored because -save-temps specified
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.3.0/configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --disable-nls --disable-multilib --disable-werror
--disable-libunwind-exceptions
--- Comment #1 from malitzke at metronets dot com 2007-06-25 10:15 ---
Created an attachment (id=13782)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13782action=view)
standrd *.i file
drivers/acpi/ec.c:124: sorry, unimplemented: inlining failed in call to
'acpi_ec_write_cmd':
cat bug.ii
__attribute__((always_inline)) void f1() {}
__attribute__((always_inline)) void f2(char) {}
void f3() { f1(); f2(0); }
g++ bug.ii
bug.ii: In function void f3():
bug.ii:2: sorry, unimplemented: inlining failed in call to void f2(char):
recursive inlining
bug.ii:3: sorry,
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-06-25 10:53 ---
Might be related to (dupe of?) PR21023?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32487
--- Comment #3 from dfranke at gcc dot gnu dot org 2007-06-25 10:54 ---
Ups, meant PR21203 ...
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from namolaru at il dot ibm dot com 2007-06-25 11:17 ---
(In reply to comment #5)
This bug should be assigned to Mircea Namolaru [EMAIL PROTECTED]. I have
sent him mail asking that he get a proper bugzilla id.
==
The underlying problem
--- Comment #5 from dfranke at gcc dot gnu dot org 2007-06-25 11:43 ---
The problem of the cyclic definition is (more or less), the same described in
PR24886, isn't it? E.g. replace
implicit character(len(ouch)) (x)
implicit character(len(x)+1) (y)
intent(in) x,y
by
--- Comment #3 from kazu at gcc dot gnu dot org 2007-06-25 11:50 ---
Richard Sandiford says that this bug is probably what
MODE_INDEX_REG_CLASS is intended to fix. Unfortunately, the patch to
add MODE_INDEX_REG_CLASS
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg00782.html
has been
--- Comment #29 from mmitchel at gcc dot gnu dot org 2007-06-25 11:38
---
Richard --
Thank you for refreshing my memory as to the code-size issue and putting the PR
numbers in the audit trail here.
-- Mark
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31360
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-06-25 11:33 ---
A dupe of 31306?
Here, I don't get an endless loop but an ICE (20070522).
*** This bug has been marked as a duplicate of 31306 ***
--
dfranke at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from dfranke at gcc dot gnu dot org 2007-06-25 11:33 ---
*** Bug 32488 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31306
--- Comment #2 from kazu at gcc dot gnu dot org 2007-06-25 11:44 ---
Here is the command line for configure.
/scratch/kazu/ce/2007-06-23-1351-0/src/gcc-mainline/configure
--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=m68k-elf
--enable-shared --enable-threads
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-25 12:16 ---
You need to learn this is not a bug.
if you do:
long long f(long long a, long long b)
{
return a/b;
}
You will get a reference to divdi3. There is no bug here except inside the
lInux kernel.
Linus is wrong in
--- Comment #2 from eres at il dot ibm dot com 2007-06-25 12:31 ---
I would like to be assigned to this bug.
Thanks,
Revital
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31150
On Fri, 18 May 2007, Andrew Morton wrote:
gcc-4.3 appears to have cunningly converted this:
Very cunning indeed.
Considerign that gcc converted straightforward and simple code to a total
disaster with a 64-bit divide, I'd call it a gcc bug.
into a divide-by-10 operation, so it
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-06-25 12:37 ---
Huh? This bug is invalid. Linus is incorrect. Please read all the emails
including Segher's. Note GCC is not ignorining unlikely at all (except maybe
for a code size issue).
--
pinskia at gcc dot gnu dot org
--- Comment #31 from samjnaa at gmail dot com 2007-06-25 12:58 ---
Just mentioning: printf() and std::cout need to be updated if the binary values
are also to be *output*. Any ideas on how or where that is to be done?
Thanks.
--
samjnaa at gmail dot com changed:
What
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-06-25 12:53 ---
Pong.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from malitzke at metronets dot com 2007-06-25 12:50 ---
Ping?
--
malitzke at metronets dot com changed:
What|Removed |Added
Status|RESOLVED
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-25 12:33 ---
Also by the way the divide is only inside the unlikely part of the code so it
will not slow down the common code.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32494
--- Comment #3 from malitzke at metronets dot com 2007-06-25 12:35 ---
Ping?
--
malitzke at metronets dot com changed:
What|Removed |Added
Status|RESOLVED
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-06-25 12:53 ---
What is there to ping?
The problem again is in the Linux kernel.
Please read http://lkml.org/lkml/2007/5/18/371 as I mentioned before.
Linus is incorrect. GCC is not ignoring unlikely as the divide is only
--- Comment #8 from malitzke at metronets dot com 2007-06-25 13:03 ---
Ping?
--
malitzke at metronets dot com changed:
What|Removed |Added
Status|RESOLVED
--- Comment #32 from j at uriah dot heep dot sax dot de 2007-06-25 13:38
---
(In reply to comment #31)
Just mentioning: printf() and std::cout need to be updated if the
binary values are also to be *output*. Any ideas on how or where
that is to be done?
That would be a library
___ added for emphasis
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.3.0/configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --disable-nls --disable-multilib --disable-werror
--disable-libunwind-exceptions --disable-checking
--- Comment #1 from schwab at suse dot de 2007-06-25 13:58 ---
__udivdi3 is not a builtin. It is a libcall that implements 64 bit division for
architectures that don't have support for it in the ISA.
--
schwab at suse dot de changed:
What|Removed
Configure command:
/n/12/rask/src/all/configure --target mipsisa64-unknown-elf
--with-newlib--enable-sim --disable-gdb --disable-nls
Build fails with this:
libtool: compile: /home/rask/build/gcc-mipsisa64-unknown-elf/./gcc/xgcc
-B/home/rask/build/gcc-mipsisa64-unknown-elf/./gcc/ -nostdinc
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-06-25 13:06 ---
Now you are getting annoying. Richard closed the bug already too. Please read
my whole comments and Segher's. Nobody has really looked into the code
produced except for the fact GCC is emitting a call to divdi3
--- Comment #1 from burnus at gcc dot gnu dot org 2007-06-25 14:19 ---
Try this patch:
http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01800.html
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |eres at il dot ibm dot com
|dot org
Configure string:
$ /n/12/rask/src/all/configure --target=powerpc-unknown-eabisim --with-newlib
--enable-sim --disable-libffi --disable-gdb --disable-nls
Build fails:
libtool: compile: /home/rask/build/gcc-powerpc-unknown-eabisim/./gcc/xgcc
-B/home/rask/build/gcc-powerpc-unknown-eabisim/./gcc/
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-25 14:49 ---
boehm-gc should not be enabled for the embedded ppc. In fact all of libjava
should most likely not be enabled.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32498
--- Comment #3 from pault at gcc dot gnu dot org 2007-06-25 14:51 ---
I have a fix for this that needs a bit of cleaning up - will submit tonight.
For some reason, gfc_simplify_repeat denies even the possibility of character
literal arguments - it's not even a question of a failing
--- Comment #4 from pault at gcc dot gnu dot org 2007-06-25 14:56 ---
I'd better take this on since I have had my patch for it accepted!
Thanks for the report, Michael.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
NetBSD autobuild cluster is a mixture of i386 and amd64 machines, and
when sh3 builds hit an amd64 build host the build fails when
cross-compiling native /usr/bin/gcc for sh3 target.
/usr/nb/tools/bin/shle--netbsdelf-gcc ... -c insn-emit.c
insn-emit.c: In function 'gen_mshfhi_l_di':
I noticed that the libstdc++ testsuite fails to run on mips-sgi-irix6.5 and
mips-sgi-irix5.3::
ERROR: tcl error sourcing
/vol/gcc/src/gcc-dist/libstdc++-v3/testsuite/libstdc++-abi/abi.exp.
ERROR: could not link libtestc++.a
while executing
error could not link libtestc++.a
(procedure
Hello,
On the FreeBSD -CURRENT mailing lists a user of the upcoming FreeBSD release
discovered a bug in the GCC that is shipped with the base system (4.2.0
20070514). This bug causes the amount of iterations in a loop to be limited to
the range of an array used in a single part of the loop. When
--- Comment #1 from ed at fxq dot nl 2007-06-25 15:35 ---
Created an attachment (id=13783)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13783action=view)
C source code which triggers the bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32500
--- Comment #2 from ed at fxq dot nl 2007-06-25 15:36 ---
Created an attachment (id=13784)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13784action=view)
GCC intermediate code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32500
--- Comment #3 from ed at fxq dot nl 2007-06-25 15:36 ---
Created an attachment (id=13785)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13785action=view)
Generated assembly code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32500
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-06-25 15:45 ---
i.10_10: [5, 12]
D.2123_11 = i.10_10 - 7;
D.2123_11: [0fffa, +INF]
I think this might have been already fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32500
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|blocker |normal
Component|c
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-06-25 15:46 ---
This works on the trunk.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from ed at fxq dot nl 2007-06-25 15:50 ---
Thanks for confirming this. Will the fix in question be part of 4.2.1 as well?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32500
--
spark at gcc dot gnu dot org changed:
What|Removed |Added
CC||zadeck at gcc dot gnu dot
|
--- Comment #1 from hjl at lucon dot org 2007-06-25 16:07 ---
Revision 125997 also fails at -O2 on Linux/x86-64 and the 4.2 patch
for PR 30252 fixes this bug for 4.3.
--
hjl at lucon dot org changed:
What|Removed |Added
1 - 100 of 187 matches
Mail list logo
