Jan Kratochvil writes:
currently (on x86_64) the gdb backtrace does not properly stop at
the outermost frame:
#3 0x0036ddb0610a in start_thread () from /lib64/tls/libpthread.so.0
#4 0x0036dd0c68c3 in clone () from /lib64/tls/libc.so.6
#5 0x in ?? ()
Jan Kratochvil writes:
currently (on x86_64) the gdb backtrace does not properly stop at
the outermost frame:
#3 0x0036ddb0610a in start_thread () from
/lib64/tls/libpthread.so.0
#4 0x0036dd0c68c3 in clone () from /lib64/tls/libc.so.6
#5 0x
Andrew Haley wrote:
Null-terminating the call stack is too well-established practice to be
changed now.
Which does not mean that the mistake should hold people back. This is
just one of the mistakes in the x86-64 ABI. It was copied from x86 and
it was wrong there already.
In practice,
Ulrich Drepper writes:
Andrew Haley wrote:
Null-terminating the call stack is too well-established practice to be
changed now.
Which does not mean that the mistake should hold people back.
Sure it does. Not breaking things is an excellent reason, probably
one of the the best reasons
Andrew Haley wrote:
Sure it does. Not breaking things is an excellent reason, probably
one of the the best reasons you can have.
Nothing breaks if the responsible tools are updated in unison.
Really? Well, that's one interpretation. I don't believe that,
though. It's certainly an
On Tue, 12 Dec 2006 16:26:34 +0100, Andrew Haley wrote:
...
It's certainly an inconsistency in the specification, which says that
null-termination is supported, and this implies that you can't put a zero in
there.
I tested now that you can put the zero there for both the libgcc unwinder and
On Mon, Dec 11, 2006 at 02:40:22PM -0800, Roland McGrath wrote:
My reading is that the ABI authoring body for GNU systems or the
compilation system authoring body for GNU compilers already specifies
that the default rule is same_value for callee-saves registers (as chosen
by each particular
On Tue, Dec 12, 2006 at 03:26:34PM +, Andrew Haley wrote:
Ulrich Drepper writes:
Andrew Haley wrote:
Null-terminating the call stack is too well-established practice to be
changed now.
Which does not mean that the mistake should hold people back.
Sure it does. Not
Andrew Haley [EMAIL PROTECTED] writes:
In practice, %ebp either points to a call frame -- not necessarily the
most recent one -- or is null. I don't think that having an optional
frame pointer mees you can use %ebp for anything random at all, but we
need to make a clarification request of
Ian Lance Taylor writes:
Andrew Haley [EMAIL PROTECTED] writes:
In practice, %ebp either points to a call frame -- not necessarily the
most recent one -- or is null. I don't think that having an optional
frame pointer mees you can use %ebp for anything random at all, but we
need
Ian Lance Taylor writes:
Andrew Haley [EMAIL PROTECTED] writes:
In practice, %ebp either points to a call frame -- not necessarily
the
most recent one -- or is null. I don't think that having an optional
frame pointer mees you can use %ebp for anything random at all,
Snapshot gcc-4.2-20061212 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20061212/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.2 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Andrew Pinski wrote:
On Fri, 2006-10-13 at 12:51 -0400, Carlos O'Donell wrote:
A relocated compiler should not look in $prefix.
Comments?
OK for Stage1?
I do have another issue with these set of patches which I did not notice
until today.
I can no longer do inside a just built GCC do:
I've come across an issue with using the -pg switch for profiling on the
DJGPP DOS platform, using GCC 4.1.0. After some digging through
disassembly, I found that the part of the function prologue for main()
before the call to mcount() is using the ECX register, and the call to
the mcount()
Joslwah writes:
Joslwah Looking at the Linux 32bit PowerPC ABI spec, it appears to me that
Joslwah floats in excess of those that are passed in registers are supposed to
Joslwah be promoted to doubles and passed on the stack. Examing the resulting
Joslwah stack from a gcc generated C call it
On Dec 12, 2006, at 11:42 AM, David Edelsohn wrote:
Joslwah writes:
Joslwah Looking at the Linux 32bit PowerPC ABI spec, it appears to
me that
Joslwah floats in excess of those that are passed in registers are
supposed to
Joslwah be promoted to doubles and passed on the stack. Examing
Dale Johannesen writes:
Dale It may have been intended to allow the callee to be a KR-style or
Dale varargs function, where all float args get promoted to double.
Dale In particular, printf was often called without being declared in KR-
Dale era code. This is one way to make that code work
On Dec 12, 2006, at 12:07 PM, David Edelsohn wrote:
Dale Johannesen writes:
Dale It may have been intended to allow the callee to be a KR-
style or
Dale varargs function, where all float args get promoted to double.
Dale In particular, printf was often called without being declared
in
What are the contents of t.c? What if you set GCC_EXEC_PREFIX?
t.c:
#include stdio.h
int main(void)
{
printf(Hello World\n);
return 0;
}
--
No I did not set GCC_EXEC_PREFIX as I did not know I have to set that now.
Seems like a change like this should be mentioned on
Andrew Pinski wrote:
What are the contents of t.c? What if you set GCC_EXEC_PREFIX?
t.c:
#include stdio.h
int main(void)
{
printf(Hello World\n);
return 0;
}
--
No I did not set GCC_EXEC_PREFIX as I did not know I have to set that now.
Seems like a change
Andrew Pinski wrote:
But other non user-visible changes are mentioned on changes.html already.
Forward prop in 4.3.
Incompatible changes to the build system in 4.2 which seems very related to
stuff like
this.
If you want to make a patch, and Gerald approves it, it's fine by me.
But, fwprop
On 06 Dec 2006 23:13:35 -0800, Ian Lance Taylor [EMAIL PROTECTED] wrote:
David Daney [EMAIL PROTECTED] writes:
I am working on a private target where jump instruction patterns are
similiar to this
jmp 24 bit offset
jmp address register for 32 bit offsets
if my offset is greater
Rohit Arul Raj [EMAIL PROTECTED] writes:
If you can't afford to lose a register, then I think your only option
is to pick some callee-saved register and have each branch instruction
explicitly clobber it. Then it will be available for use in a long
branch, and it will be available for
Testcase:
struct aaa
{
aaa(_Complex float __z) ;
_Complex float _M_value;
};
aaa::aaa(_Complex float __z) : _M_value(__z) {}
We must not be setting DECL_COMPLEX_GIMPLE_REG_P correctly.
--
Summary: C++ constructors can cause invalid gimple to happen with
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-12 08:39 ---
This testcase comes from a reduced testcase from:
26_numerics/complex/13450.cc
26_numerics/complex/pow.cc
tr1/8_c_compatibility/complex/functions.cc
And most likely more.
--
The following program fails to compile:
template typename T struct A {};
template typename T struct B
{
typedef T type;
operator AT() const;
};
template typename T void F(const Atypename BT::type ) {}
template typename T BT::operator AT() const {}
test.cpp:8: error: no
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-12-12 08:44 ---
Here is another testcase (a C one this time):
int x, *p = x;
g (int n)
{
int i = 1, j, sum = 0;
#pragma omp parallel reduction(+: sum) num_threads(2)
{
f1 (j);
sum += i + j + *p + n;
}
}
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-12 08:46 ---
Fails with 4.0.4 20061011 but passes with 4.1.2 20061204 so closing as
fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
|
When compiling EuroBen mod3a benchmark, following errors terminate the
compilation:
gfortran -c mod3a.f
mod3a.f:61.72:
Status = 'scratch' )
1
Error: The STATUS specified in
--- Comment #6 from tbm at cyrius dot com 2006-12-12 10:57 ---
(In reply to comment #5)
The problem is EXECUTE_IF_SET_IN_BITMAP does not like the bitmap to change
from
underneath it.
I have a patch which fixes this issue.
Wow, nice you tracked this down. I thought this bug
See https://bugs.helixcommunity.org/show_bug.cgi?id=5641 -- particularly the
assignment to va_list (the references are uncommon enough that they probably
don't matter).
The world would be a better place if this kind of code would fail to build, or
at least _warn_, on i386. The ABI might not allow
--- Comment #7 from bkoz at gcc dot gnu dot org 2006-12-12 11:24 ---
Subject: Bug 28125
Author: bkoz
Date: Tue Dec 12 11:23:44 2006
New Revision: 119774
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119774
Log:
2006-12-11 Benjamin Kosnik [EMAIL PROTECTED]
PR
--- Comment #8 from bkoz at gcc dot gnu dot org 2006-12-12 11:24 ---
Subject: Bug 28125
Author: bkoz
Date: Tue Dec 12 11:23:56 2006
New Revision: 119775
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119775
Log:
2006-12-11 Benjamin Kosnik [EMAIL PROTECTED]
PR
--- Comment #9 from bkoz at gcc dot gnu dot org 2006-12-12 11:25 ---
Should be fixed on gcc/gcc-4_2-branch/gcc-4_1-branch
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from patchapp at dberlin dot org 2006-12-12 11:25 ---
Subject: Bug number PR29624
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/2006-12/msg00827.html
--
--- Comment #5 from bkoz at gcc dot gnu dot org 2006-12-12 11:32 ---
I suspect that the fix for 28125 may also fix this. If not, then the only thing
I can think of to do is to add a compile test explicitly for iconv_t in
GLIBCXX_CHECK_ICONV_SUPPORT.
This seems redundant, however, as
--- Comment #22 from bkoz at gcc dot gnu dot org 2006-12-12 11:37 ---
This is closed as gcjx is dead.
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from bkoz at gcc dot gnu dot org 2006-12-12 12:14 ---
Created an attachment (id=12789)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12789action=view)
add check_linker_features for solaris crosses
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26497
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-12-12 12:21 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from rmathew at gcc dot gnu dot org 2006-12-12 12:27 ---
The real problem (IIRC) was that iconv_t was being used even though there was
no libiconv (I think the inclusion of the header file was properly guarded, but
the usage of the type wasn't).
MinGW uses the Windows C
We do not fold for example
__complex__ ( x, 0 ) * __complex__ ( 0, 1 )
or
__complex__ ( x, 0 ) + __complex__ ( 0, y )
I have a partial patch.
--
Summary: Operations with partly constant complex values not
folded
Product: gcc
Version:
--- Comment #7 from rmathew at gcc dot gnu dot org 2006-12-12 12:28 ---
(See the comment above.)
--
rmathew at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from bkoz at gcc dot gnu dot org 2006-12-12 12:33 ---
Can I get some feedback on this bug? If not, I will close it...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22339
--- Comment #4 from bkoz at gcc dot gnu dot org 2006-12-12 12:40 ---
Danny, any chance we can get current status on this with a current version of
gcc/libstdc++? 4.2-branch would be great.
If _GLIBCXX_USE_LFS is now being defined for native, then the crosses should
have it too.
If
--- Comment #9 from bkoz at gcc dot gnu dot org 2006-12-12 12:41 ---
Subject: Bug 26497
Author: bkoz
Date: Tue Dec 12 12:41:26 2006
New Revision: 119778
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119778
Log:
2006-12-12 Benjamin Kosnik [EMAIL PROTECTED]
PR
--- Comment #1 from burnus at gcc dot gnu dot org 2006-12-12 12:55 ---
The standard is very clear about it (Fortran 2003, but similar for Fortran 95):
9.4.5 The OPEN statement
If the STATUS= specifier has the value SCRATCH, the FILE= specifier shall not
appear.
One might want to allow
--- Comment #1 from kkojima at gcc dot gnu dot org 2006-12-12 13:01 ---
A slightly different test case
unsigned int foo(unsigned int x)
{
if (x 5)
x = 4;
else
x = 8;
return x;
}
int main(void)
{
if (foo (4) != 4)
abort ();
if (foo (8) != 8)
abort ();
exit
--- Comment #1 from bkoz at gcc dot gnu dot org 2006-12-12 13:09 ---
Any chance cris-elf testresults for current gcc could be posted to
gcc-testresults? It looks like 11 months since the last posting.
--
bkoz at gcc dot gnu dot org changed:
What|Removed
--- Comment #10 from bkoz at gcc dot gnu dot org 2006-12-12 13:13 ---
Subject: Bug 26497
Author: bkoz
Date: Tue Dec 12 13:13:08 2006
New Revision: 119780
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119780
Log:
2006-12-12 Benjamin Kosnik [EMAIL PROTECTED]
PR
--- Comment #11 from bkoz at gcc dot gnu dot org 2006-12-12 13:13 ---
Subject: Bug 26497
Author: bkoz
Date: Tue Dec 12 13:13:21 2006
New Revision: 119781
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119781
Log:
2006-12-12 Benjamin Kosnik [EMAIL PROTECTED]
PR
--- Comment #12 from bkoz at gcc dot gnu dot org 2006-12-12 13:14 ---
Fixed.
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28125
--- Comment #8 from bkoz at gcc dot gnu dot org 2006-12-12 13:31 ---
Thanks Ranjit.
Then:
Index: crossconfig.m4
===
--- crossconfig.m4 (revision 119781)
+++ crossconfig.m4 (working copy)
@@ -178,7 +178,6 @@
--- Comment #2 from dnovillo at gcc dot gnu dot org 2006-12-12 13:51
---
Adding Andrew to CC list. Seems related to out-of-ssa changes.
--
dnovillo at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from mankatob at yahoo dot com 2006-12-12 13:52 ---
Subject: Re: gcc/vec.h line 538 references vec which is undefined (should be
vec_)
If its already spec'd - why are we calculating it?
Did something change between when it was defined and
vec.h 538? Since the
--- Comment #3 from bkoz at gcc dot gnu dot org 2006-12-12 13:57 ---
kazu, are you the target maintainer for h8300? If so, I think this is for you.
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from bkoz at gcc dot gnu dot org 2006-12-12 14:01 ---
Subject: Bug 28265
Author: bkoz
Date: Tue Dec 12 14:00:54 2006
New Revision: 119782
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119782
Log:
2006-12-12 Benjamin Kosnik [EMAIL PROTECTED]
PR
--- Comment #3 from amacleod at redhat dot com 2006-12-12 14:11 ---
Analyzing Edge Insertions.
foo (x)
{
unsigned int x.24;
bb 2:
if (x.24 = 4) goto L5; else goto L4;
Yeah, this is clearly wrong. It looks like the coalescer somehow neglected to
coalesce the parameter to the first
--- Comment #10 from bkoz at gcc dot gnu dot org 2006-12-12 14:19 ---
Subject: Bug 28265
Author: bkoz
Date: Tue Dec 12 14:18:36 2006
New Revision: 119783
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119783
Log:
2006-12-12 Benjamin Kosnik [EMAIL PROTECTED]
PR
--- Comment #11 from bkoz at gcc dot gnu dot org 2006-12-12 14:29 ---
Subject: Bug 28265
Author: bkoz
Date: Tue Dec 12 14:28:53 2006
New Revision: 119784
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119784
Log:
2006-12-12 Benjamin Kosnik [EMAIL PROTECTED]
PR
--- Comment #12 from bkoz at gcc dot gnu dot org 2006-12-12 14:31 ---
Fixed.
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from ubizjak at gmail dot com 2006-12-12 14:41 ---
Fixed (by reverting x87 register-passing patch).
Look at http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00729.html for a
discussion.
--
ubizjak at gmail dot com changed:
What|Removed
--- Comment #7 from jakub at gcc dot gnu dot org 2006-12-12 15:03 ---
Subject: Bug 27761
Author: jakub
Date: Tue Dec 12 15:03:39 2006
New Revision: 119785
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119785
Log:
PR rtl-optimization/27761
* combine.c
--- Comment #8 from jakub at gcc dot gnu dot org 2006-12-12 15:05 ---
Subject: Bug 27761
Author: jakub
Date: Tue Dec 12 15:05:08 2006
New Revision: 119786
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119786
Log:
PR rtl-optimization/27761
* combine.c
--- Comment #9 from jakub at gcc dot gnu dot org 2006-12-12 15:07 ---
Subject: Bug 27761
Author: jakub
Date: Tue Dec 12 15:07:23 2006
New Revision: 119787
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119787
Log:
PR rtl-optimization/27761
* combine.c
--- Comment #43 from jakub at gcc dot gnu dot org 2006-12-12 15:15 ---
Subject: Bug 11953
Author: jakub
Date: Tue Dec 12 15:15:19 2006
New Revision: 119788
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119788
Log:
PR libstdc++/11953
* gthr-posix.h (_REENTRANT):
--- Comment #44 from jakub at gcc dot gnu dot org 2006-12-12 15:22 ---
Subject: Bug 11953
Author: jakub
Date: Tue Dec 12 15:21:53 2006
New Revision: 119789
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119789
Log:
PR libstdc++/11953
* gthr-posix.h (_REENTRANT):
--- Comment #45 from jakub at gcc dot gnu dot org 2006-12-12 15:24 ---
Subject: Bug 11953
Author: jakub
Date: Tue Dec 12 15:24:07 2006
New Revision: 119790
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119790
Log:
PR libstdc++/11953
* gthr-posix.h (_REENTRANT):
--- Comment #4 from amacleod at redhat dot com 2006-12-12 15:50 ---
Subject: Bug 30159
Author: amacleod
Date: Tue Dec 12 15:50:06 2006
New Revision: 119792
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119792
Log:
2006-12-12 Andrew Macleod [EMAIL PROTECTED]
PR
Version Information
[EMAIL PROTECTED] ~]$ arm-elf-gcc -v
Using built-in specs.
Target: arm-elf
Configured with: ../gcc-4.1.1/configure
--prefix=/usr/local/armdev-926ej-s-4.1.1 --target=arm-elf --enable-languages=c
--with-float=soft --enable-interwork --enable-multilib --with-cpu=arm926ej-s
See for example http://gcc.gnu.org/ml/gcc-testresults/2006-12/msg00374.html.
This test has been failing since the following change was introduced:
2006-10-31 Geoffrey Keating [EMAIL PROTECTED]
* tree.c (get_file_function_name): Rename from
get_file_function_name_long; improve
--- Comment #2 from danglin at gcc dot gnu dot org 2006-12-12 16:33 ---
Same failures occur on hppa2.0w-hp-hpux11.11.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-12-12 16:44 ---
We're now ICEing in
internal compiler error: in ssa_operand_alloc, at tree-ssa-operands.c:365
for the second testcase.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #7 from dberlin at gcc dot gnu dot org 2006-12-12 16:49 ---
Subject: Re: reassoc can sometimes get in the way of PRE
Here is a slightly modified example that shows that there's still a PRE
opportunity
void motion_test22(int * data, int i)
{
int j;
if (data[1])
Both tramp3d-v4 and Polyhedron gas_dyn regress in runtime with the mem-ssa
merge.
See
http://www.suse.de/~gcctest/c++bench/polyhedron/polyhedron-summary.txt-2-0.html
and
http://www.suse.de/~gcctest/c++bench/tramp3d/split-run.html
--
Summary: Runtime regressions with mem-ssa merge
FAIL: gcc.dg/tree-prof/stringop-1.c scan-tree-dump memcpy.*4\\)
looks like a wrong regexp?
--
Summary: gcc.dg/tree-prof/stringop-1.c fails
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-12-12 17:12 ---
(In reply to comment #6)
Wow, nice you tracked this down. I thought this bug would stay open forever
as
unreproducible.
I only tracked it down because of the duplicate to this bug.
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-12 17:31 ---
This warning could perhaps be enabled by default on any platform which code is
expected to be portable (like Linux) but disabled on i386-only platforms
(win32).
No, I disagree with the last part of that
--- Comment #2 from dwmw2 at infradead dot org 2006-12-12 17:33 ---
Yeah, fair enough. Enable the warning by default everywhere then.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30171
--- Comment #6 from ian at airs dot com 2006-12-12 18:00 ---
Copyright status is cleared, my patch is here:
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00868.html
--
ian at airs dot com changed:
What|Removed |Added
--- Comment #7 from patchapp at dberlin dot org 2006-12-12 18:00 ---
Subject: Bug number PR c++/19564
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/2006-12/msg00868.html
--
--- Comment #1 from marc dot glisse at normalesup dot org 2006-12-12 18:40
---
In gcc/cp/decl.c, I see:
if (global_scope_p (current_binding_level))
asmspec_tree = maybe_apply_renaming_pragma (decl, asmspec_tree);
So if I understand correctly (it is the first time I have a look
current trunk ICEs with:
[EMAIL PROTECTED]:~/projects/wine/dlls/user32/tests
/home/marcus/projects/gcc/BIN/bin/gcc-O2 -c sysparams.i
sysparams.i: In function 'f':
sysparams.i:26: internal compiler error: in ssa_operand_alloc, at
tree-ssa-operands.c:365
Please submit a full bug report,
with
--- Comment #1 from marcus at jet dot franken dot de 2006-12-12 19:38
---
Created an attachment (id=12790)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12790action=view)
sysparams.i
gcc -c -O2 sysparams.i
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30177
Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/te
st/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/execute/20010422-1.c -w -O1
-fno-s
how-column -lm -o /test/gnu/gcc/objdir/gcc/testsuite/gcc/20010422-1.x1
(ti
meout = 300)
PASS: gcc.c-torture/execute/20010422-1.c
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-12 19:53 ---
*** This bug has been marked as a duplicate of 30159 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-12-12 19:53 ---
*** Bug 30178 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/te
st/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/execute/mode-dependent-address.c -w
-O0 -fno-show-column -lm -o
/test/gnu/gcc/objdir/gcc/testsuite/gcc/mode-dep
endent-address.x0(timeout = 300)
Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/te
st/gnu/gcc/gcc/gcc/testsuite/gcc.dg/builtin-bswap-1.c-fno-show-column -S
-o
builtin-bswap-1.s(timeout = 300)
/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/builtin-bswap-1.c:5: error: stdint.h: No
such file or
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
BugsThisDependsOn||28067
AssignedTo|unassigned at gcc dot gnu |tromey at gcc
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
BugsThisDependsOn||28067
AssignedTo|unassigned at gcc dot gnu |tromey at gcc
Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/te
st/gnu/gcc/gcc/gcc/testsuite/gcc.dg/builtins-57.c -fdump-tree-gimple
-fno-show
-column -S -o builtins-57.s(timeout = 300)
PASS: gcc.dg/builtins-57.c (test for excess errors)
PASS: gcc.dg/builtins-57.c
--- Comment #1 from dave at hiauly1 dot hia dot nrc dot ca 2006-12-12
20:28 ---
Subject: Re: New: FAIL: gcc.dg/builtins-57.c scan-tree-dump trunc
Attached tree dump.
Dave
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2006-12-12
20:28 ---
Created an
--- Comment #2 from tromey at gcc dot gnu dot org 2006-12-12 20:30 ---
A stack trace would help here ... can you install debug info or something
and try again?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29869
Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/te
st/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr28796-2.c -O2
-funsafe-math-optimization
s -fno-finite-math-only -fno-show-column -lm -o ./pr28796-2.exe(timeout
=
300)
/usr/ccs/bin/ld: Unsatisfied symbols:
finite
Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/te
st/gnu/gcc/gcc/gcc/testsuite/gcc.dg/noncompile/pr16876.c -O0 -O
-finline-func
tions -fno-show-column -S -o pr16876.s(timeout = 300)
FAIL: gcc.dg/noncompile/pr16876.c -O0 (test for errors, line 10)
PASS:
Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/te
st/gnu/gcc/gcc/gcc/testsuite/gcc.dg/torture/builtin-sin-mpfr-1.c -O0
-fno-sh
ow-column -lm -o builtin-sin-mpfr-1.exe(timeout = 300)
/usr/ccs/bin/ld: Unsatisfied symbols:
link_error (first referenced in
--- Comment #1 from danglin at gcc dot gnu dot org 2006-12-12 20:49 ---
Oh, this is mpfr bug and I need to finish updating mpfr.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
1 - 100 of 158 matches
Mail list logo
