On 9/26/07, Alexandre Oliva [EMAIL PROTECTED] wrote:
On Sep 11, 2007, Mark Mitchell [EMAIL PROTECTED] wrote:
That's a possibility, but I don't want to commit at this point. We can
have a look at it when you submit it and decide. However, in general,
introducing churn for the sake of a
On Oct 1, 2007, Richard Guenther [EMAIL PROTECTED] wrote:
Can you develop this more in the open to allow contribution,
facititate further review and make merging it to 4.4 less pain?
Sure! I'm very glad you asked ;-)
I've just created the var-tracking-assignments branch, and I'll check
my
On 10/1/07, Alexandre Oliva [EMAIL PROTECTED] wrote:
On Oct 1, 2007, Richard Guenther [EMAIL PROTECTED] wrote:
Can you develop this more in the open to allow contribution,
facititate further review and make merging it to 4.4 less pain?
Sure! I'm very glad you asked ;-)
I've just
In either case, I don't think that this is a showstopper. (AFAIK,
you're the first person to notice this, and you've indicated that
it's
now a relatively long-standing bug.)
This is bug #31955 in Bugzilla. It is rather annoying, because the
online installation instructions only cover
Snapshot gcc-4.1-20071001 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20071001/
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
Hi,
the starting pages for the mailing lists like
http://gcc.gnu.org/ml/gcc or http://gcc.gnu.org/ml/gcc-patches
are broken. To be more precise, the entry generated for September is
corrupted: It shows a strange size, and the link points to a wrong location.
* October, 2007
* September,
On 10/1/07, Christopher Faylor
[EMAIL PROTECTED] wrote:
On Mon, Oct 01, 2007 at 05:42:15PM -0700, Andrew Pinski wrote:
This is maybe more appropriate for overseers.
We're not supporting the ftp archives anymore so all of those links will
be disappearing soon.
I forgot to mention when this
--- Comment #4 from mathias dot hasselmann at gmx dot de 2007-10-01 06:45
---
(In reply to comment #1)
Not a bug as printf can segfault if it is supplied a NULL pointer for the
string formatter.
If glibc does something different than that, glibc is does not have a bug
either as it
--- Comment #11 from pault at gcc dot gnu dot org 2007-10-01 07:01 ---
(In reply to comment #10)
Yes, the initialization is occurring in the wrong place in
gfc_trans_deferred_vars. It looks to be easily fixable. I'll be onto it
tonight.
I figured out how to do it on the way to
I have experienced a null pointer exception when calling g++ from java (using
swig generated bindings).
I have made a reduced test case that exhibits the same behaviour which
is attached to this report. If I run this on Fedora Core 6 I get:
[EMAIL PROTECTED] ~]$ tar -z -x -f java-test.tar.gz
--- Comment #1 from mattias dot ellert at tsl dot uu dot se 2007-10-01
08:41 ---
Created an attachment (id=14277)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14277action=view)
The test case...
This is the test case used above.
--
--- Comment #5 from manu at gcc dot gnu dot org 2007-10-01 09:12 ---
(In reply to comment #4)
Question is: Which group is bigger. The missuse printf as puts group or the
rely on glibc's relaxed NULL handling group. My guess would be that people who
do not even know puts care even
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-10-01 09:46 ---
With a more recent 4.3 version I get
4.2 4.3
-O2 6.1s 5.1s
-O3 4.1s 5.1s
both -O3 variants have one function not inlined in the main loop. For 4.2
it is
EiEvalEiMatrixProductEiMatrixdouble, 3, 3,
--- Comment #2 from pcarlini at suse dot de 2007-10-01 10:06 ---
The most recent boost release (1.34.1) of those checks uses the same code of
our adaption. Given that, and given of course that we are finally in the era of
real concepts in the core language for the forthcoming new
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-10-01 10:58
---
There are three different issues:
1. -fwhole-program should be documented as not working for the Fortran
programs.
2. The Fortran main program (MAIN__) needs to be kept by the -fwhole-program
optimization;
--- Comment #11 from fxcoudert at gcc dot gnu dot org 2007-10-01 11:19
---
(In reply to comment #10)
It looks like it is now only a Macintosh PowerPC version problem. It also
works Ok on the Intel Macintosh and on the MSYS versions of gfortran.
I can confirm that bug on ppc-darwin.
gcc -static-libgcc -o gnatbind ada/b_gnatb.o ada/adaint.o ada/argv.o
ada/exit.o ada/cio.o ada/cstreams.o ada/env.o ada/final.o ada/init.o
ada/initialize.o ada/seh_init.o ada/link.o ada/targext.o ada/raise.o
ada/tracebak.o ada/ada.o ada/a-clrefi.o ada/a-comlin.o ada/a-elchha.o
ada/a-except.o
--- Comment #20 from aldot at gcc dot gnu dot org 2007-10-01 11:55 ---
Tripping exactly this while thinking about uclibc on hurd.
To me it looks like linux.h shouldn't be included and gnu.h should be made
uclibc-aware..
--
aldot at gcc dot gnu dot org changed:
What
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-10-01 13:05
---
You might also want to build GMP and MPFR with internal checking enabled
(--enable-assert, I think). Doesn't this one appear on hpux11?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33584
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-10-01 13:13
---
Can you compile and run the following C test code? (gcc -std=c99, or the system
compiler)
#include math.h
#include stdio.h
int main (void)
{
printf (%ld %ld %ld\n, lround (nextafter(0.5,-9.0)), lround (0.5),
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
The following code:
print *, real(huge(1.0_8),16)
end
gives an ICE on gcc version 4.3.0 20071001 (experimental) (GCC):
print *, real(huge(1.0_8),16)
1
Error: Arithmetic overflow converting REAL(8) to REAL(16) at (1). This check
can be disabled with the option -fno-range-check
--- Comment #2 from virtualphoton at hotmail dot com 2007-10-01 14:22
---
That's it. I went to gcc IRC and pestered people to help me with it till a guy
named 'damjan' caved. Hehe. I just wonder, why can't it be literal? Is there
a reason? I'll ask the mailing group.
--
--- Comment #7 from gd at spherenet dot de 2007-10-01 14:42 ---
Just to be sure I understood everything correctly. Assume the following code:
namespace foo __attribute__((__visibility__(default))) {
...
}
namespace foo {
...
}
The same binding level is used for both namespace
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-10-01 14:44
---
What does it do with -fno-range-check?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33609
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-10-01 15:06 ---
Confirmed. Also fails on x86_64, i586 and ia64. So I guess everywhere.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-10-01 15:06 ---
Err, confirmed I said.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-10-01 15:09 ---
I see this as well, on all archs for 4.2.2 (a regression from 4.2.1).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33429
--- Comment #2 from dominiq at lps dot ens dot fr 2007-10-01 15:13 ---
Subject: Re: ICE on arithmetic overflow
What does it do with -fno-range-check?
compiles and outputs +Infinity
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33609
--- Comment #7 from pthaugen at gcc dot gnu dot org 2007-10-01 15:15
---
Subject: Bug 30565
Author: pthaugen
Date: Mon Oct 1 15:14:57 2007
New Revision: 128907
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128907
Log:
2007-10-01 Pat Haugen [EMAIL PROTECTED]
Backport
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-10-01 15:18 ---
r128363 is good, r128394 is bad. Which points to:
Author: jason
Date: Tue Sep 11 15:20:47 2007
New Revision: 128382
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128382
Log:
PR c++/15745
*
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-01
15:23 ---
Subject: Re: FAIL: gfortran.dg/integer_exponentiation_4.f90 -O (internal
compiler error)
You might also want to build GMP and MPFR with internal checking enabled
(--enable-assert, I think). Doesn't
Compile the following program:
#include stdio.h
long double d = 22092007.192016;
struct abc {
long double a, b, c;
};
void outer(void) {
struct abc x;
void inner(struct abc p) {
printf(Enter inner\n);
/* Next line causes problem: bus error, segmentation fault or
result of
--- Comment #1 from peter_schorn at yahoo dot com 2007-10-01 16:11 ---
Created an attachment (id=14278)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14278action=view)
Source code of program showing the bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33610
--- Comment #2 from peter_schorn at yahoo dot com 2007-10-01 16:12 ---
Created an attachment (id=14279)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14279action=view)
After pre-processing
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33610
--- Comment #3 from kargl at gcc dot gnu dot org 2007-10-01 16:32 ---
(In reply to comment #2)
Subject: Re: ICE on arithmetic overflow
What does it do with -fno-range-check?
compiles and outputs +Infinity
What does -fdump-tree-original give when you use the -fno-range-check
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-01
16:33 ---
Subject: Re: FAIL: gfortran.dg/nint_2.f90 -O0 execution test
It should print 0 1 1. If it prints 1 1 1, then your system libm has a
bug.
It prints 0 1 1 on hpux11. lround and nextafter aren't
--- Comment #16 from aoliva at gcc dot gnu dot org 2007-10-01 16:36 ---
Subject: Bug 22156
Author: aoliva
Date: Mon Oct 1 16:35:55 2007
New Revision: 128908
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128908
Log:
PR middle-end/22156
* tree-sra.c (struct sra_elt): Add
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-10-01 16:39
---
(In reply to comment #2)
lround and nextafter aren't available on hpux10.
Does hpux10 have round()? And does it have ceil()? (I assume that the last
answer is yes, because it's ANSI C, but hpux could surprise
--- Comment #17 from aoliva at gcc dot gnu dot org 2007-10-01 16:46 ---
Patch checked in.
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from dominiq at lps dot ens dot fr 2007-10-01 16:48 ---
Subject: Re: ICE on arithmetic overflow
What does -fdump-tree-original give when you use the -fno-range-check
option?
MAIN__ ()
{
static int4 options.0[7] = {68, 127, 0, 0, 0, 1, 0};
_gfortran_set_options
The following snipped when compiled with -O0 generates a program that quickly
finishes (correct behavior). But when compiled with any optimizations (-O1, -O2
or -O3) generates a program that never finishes. Variations on the code, (such
as the comment line) geneate valid program with either level
--- Comment #1 from macracan at yahoo dot com 2007-10-01 17:05 ---
Created an attachment (id=14280)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14280action=view)
source file and the result of 'gcc -v -save-temps -O3 aa.cpp 2stderr'
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-10-01 17:10 ---
I think you should read http://www.validlab.com/goldberg/paper.pdf . I think
what is happening is on x86, there is extra precision so really you are running
into bug 323. Can you try to add -ffloat-store?
--
--- Comment #3 from bangerth at dealii dot org 2007-10-01 17:16 ---
For once a real floating point bug. In this code
double p = 0.422244 * f[a.e];
if (f[0] p)
with a.e=1, f[1]=0.285433, we should calculate p=0.285433. Since
f[0]=0.0461109, we shouldn't enter the if-clause, but
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2007-10-01
17:29 ---
Subject: Re: FAIL: gfortran.dg/nint_2.f90 -O0 execution test
Does hpux10 have round()? And does it have ceil()? (I assume that the last
answer is yes, because it's ANSI C, but hpux could surprise me
--- Comment #4 from macracan at yahoo dot com 2007-10-01 17:43 ---
(In reply to comment #3)
For once a real floating point bug. In this code
double p = 0.422244 * f[a.e];
if (f[0] p)
with a.e=1, f[1]=0.285433, we should calculate p=0.285433. Since
f[0]=0.0461109, we
--- Comment #5 from macracan at yahoo dot com 2007-10-01 17:43 ---
*** This bug has been marked as a duplicate of 323 ***
--
macracan at yahoo dot com changed:
What|Removed |Added
--- Comment #99 from macracan at yahoo dot com 2007-10-01 17:43 ---
*** Bug 33611 has been marked as a duplicate of this bug. ***
--
macracan at yahoo dot com changed:
What|Removed |Added
--- Comment #21 from ams at gnu dot org 2007-10-01 18:04 ---
Subject: Re: [4.2/4.3 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC'
undeclared
To me it looks like linux.h shouldn't be included
It should be included.
and gnu.h should be made uclibc-aware..
This would be
See:
http://gcc.gnu.org/ml/libstdc++/2007-09/msg00089.html
Some of the older cruft (-j1 mandated) has been removed from the libstdc++
Makefiles, but the older problem remains.
This is because there is basically one large call to runtest, which then runs
on one processor. And I have not found
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33612
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-10-01 18:30 ---
This needs dejagnu support (or just forcing the move over to qmtest which I
think is a big task).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33612
--- Comment #2 from tromey at gcc dot gnu dot org 2007-10-01 18:32 ---
The SWIG code violates strict aliasing rules.
Try adding -Wstrict-aliasing and you will see what I mean.
If I add -fno-strict-aliasing to the -O2 case, it works.
--
tromey at gcc dot gnu dot org changed:
On 1 Oct 2007 18:04:09 -, ams at gnu dot org
[EMAIL PROTECTED] wrote:
--- Comment #21 from ams at gnu dot org 2007-10-01 18:04 ---
Subject: Re: [4.2/4.3 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC'
undeclared
To me it looks like linux.h shouldn't be included
It
--- Comment #22 from pinskia at gcc dot gnu dot org 2007-10-01 18:36
---
Subject: Re: [4.2/4.3 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC'
undeclared
On 1 Oct 2007 18:04:09 -, ams at gnu dot org
[EMAIL PROTECTED] wrote:
--- Comment #21 from ams at gnu dot org
--- Comment #2 from pcarlini at suse dot de 2007-10-01 19:15 ---
On it.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot
--- Comment #1 from pcarlini at suse dot de 2007-10-01 19:18 ---
On it.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot
The following code fails to compile when -D_GLIBCXX_DEBUG is used. If
-D_GLIBCXX_DEBUG is not used, or the upper_bound call is commented out, the
code compiles fine.
// test.cc begin
#include algorithm
struct A {};
struct B {};
bool ab(A, B);
bool ba(B, A);
void
--- Comment #1 from leo dot moisio at gmail dot com 2007-10-01 19:55
---
Created an attachment (id=14281)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14281action=view)
The preprocessed source as created by g++ -v -save-temps -D_GLIBCXX_DEBUG
test.cc
--
--- Comment #13 from aoliva at gcc dot gnu dot org 2007-10-01 19:55 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2007-10/msg00061.html is quite
likely to fix this.
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-10-01 20:11
---
This is not target-specific:
$ cat u.f90
print *, real(huge(1.0_8),4)
end
$ gfortran u.f90
u.f90:1.16:
print *, real(huge(1.0_8),4)
1
Error: Arithmetic overflow converting REAL(8) to
--- Comment #5 from hjl at lucon dot org 2007-10-01 20:43 ---
Fixed.
--
hjl at lucon dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #3 from hjl at lucon dot org 2007-10-01 20:50 ---
Fixed.
--
hjl at lucon dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #5 from jason at gcc dot gnu dot org 2007-10-01 20:53 ---
Subject: Bug 15745
Author: jason
Date: Mon Oct 1 20:53:09 2007
New Revision: 128917
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128917
Log:
PR c++/15745
* except.c (prepare_eh_type): Use
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Version|unknown |4.3.0
--- Comment #4 from jason at gcc dot gnu dot org 2007-10-01 20:54 ---
This is not a compiler bug; I forgot to apply the same patch to vla4.C on the
branch that I did on the trunk. Fixed now.
--
jason at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from hjl at lucon dot org 2007-10-01 21:04 ---
I saw 40% performance regression at -O3 with testcase in comment #1 on
Linux/x86-64.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33604
I'm not fixing this until someone can tell me what exactly is going
wrong. There have been *so* many changes to PTA since that revision
that the majority of the code it touched doesn't even do the same
thing anymore.
My guess is that this is a case where adding extra vdefs/vuses made
some dumb
--- Comment #5 from dberlin at gcc dot gnu dot org 2007-10-01 21:07 ---
Subject: Re: [4.3 Regression] Revision 119502 causes significantly slower
results with 4.3 compared to 4.2
I'm not fixing this until someone can tell me what exactly is going
wrong. There have been *so* many
--- Comment #3 from hjl at lucon dot org 2007-10-01 21:03 ---
I have verified that revision 119502:
http://gcc.gnu.org/ml/gcc-cvs/2006-12/msg00119.html
is the cause.
--
hjl at lucon dot org changed:
What|Removed |Added
--- Comment #2 from pcarlini at suse dot de 2007-10-01 21:26 ---
Yes. In short, the debug-mode checks must implement the detailed requirements
of DR270.
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#270
In practice, probably we need a dual version of
The following code:
---
typedef float V2SF __attribute__ ((vector_size (8)));
V2SF
foo (int x, V2SF a)
{
while (x--)
a += (V2SF) {1.0f/0.0f - 1.0f/0.0f, 1.0f/0.0f - 1.0f/0.0f};
return a;
}
--- Comment #1 from rsandifo at gcc dot gnu dot org 2007-10-01 21:37
---
I have a patch.
--
rsandifo at gcc dot gnu dot org changed:
What|Removed |Added
If the following C++ code is compiled with -fnon-call-exceptions,
the tree optimisers still hoist 1.0 / 0.0:
-
extern volatile int y;
double
foo (double a, int x)
{
while (x--)
{
y++;
a += 1.0 / 0.0;
}
return a;
}
--- Comment #1 from rsandifo at gcc dot gnu dot org 2007-10-01 21:41
---
I have a patch.
--
rsandifo at gcc dot gnu dot org changed:
What|Removed |Added
[EMAIL PROTECTED]:/tmp$ cat non-lvalue-pmf.cpp
struct Receive {
};
struct TcpStats {
Receive rx;
};
typedef void (Receive::*StatsGatherer)(void);
template StatsGatherer gatherStats
void test(TcpStats* tcpStats) {
(tcpStats-rx.*gatherStats)();
}
[EMAIL PROTECTED]:/tmp$ g++ -W -Wall
The following code:
---
typedef float V8SF __attribute__ ((vector_size (32)));
void test0 (V8SF);
void
foo (float x)
{
test ((V8SF) { x, x, x, x, x, x, x, x });
}
--- Comment #1 from rsandifo at gcc dot gnu dot org 2007-10-01 21:43
---
I have a patch.
--
rsandifo at gcc dot gnu dot org changed:
What|Removed |Added
bash# /build/gcc-4.2.1/configure --enable-threads --disable-static
--with-arch=i586 --disable-libjava-multilib
/bin/sh ./libtool --tag=GCJ --mode=link /root/object/gcc/gcj
-B/root/object/i686-pc-linux-gnu/libjava/ -B/root/object/gcc/
-L/root/object/i686-pc-linux-gnu/libjava -ffloat-store
Related to PR 29877.
Take the following PPC64-linux code (ignore the fact the inline-asm should be
improved a lot via use of clobbers).
static inline int sys_ppu_thread_set_priority(sys_ppu_thread_t thread_id,int
prio)
{
register uint64_t p1 __asm__ (3) = thread_id;
register uint64_t p2 __asm__
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33619
Compiling the attached preprocessed code with gcc 4.3 svn rev. 128893
(regardless of compiler flags) results in
project.cpp:2826: internal compiler error: canonical types differ for identical
types const QListQStringList and const QListQStringList
Please submit a full bug report,
See
--- Comment #1 from bero at arklinux dot org 2007-10-01 22:14 ---
Created an attachment (id=14282)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14282action=view)
bzip2-ed preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33620
Sysgen make depend fails in fuction usage.
Message: Internal compiler error
Bus Error 10
Please submit a bug report to ...
Routine being compiled was not modified from
CDROM distribution. Using compiler supplied
with the distribution CDROM.
--
Summary: Sysgen
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
Component|c |middle-end
--- Comment #2 from rsandifo at gcc dot gnu dot org 2007-10-01 23:23
---
...but the patch was deemed unacceptable.
--
rsandifo at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-10-01 23:28
---
Hum, the real(16) case looks like loads of fun to come!
$ cat k.f90
integer, parameter :: k = 16
character(80) :: buf
real(k) :: xk, yk
xk = 1.0_k - epsilon(xk)
write (buf,'(1PG60.40)') xk
read
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-10-02 00:37
---
(In reply to comment #5)
Hum, the real(16) case looks like loads of fun to come!
Part of it is simply a libc bug. There are numbers close to 1.0 and -1.0 that
the darwin libc can't output properly:
$ cat k2.c
--- Comment #14 from aoliva at gcc dot gnu dot org 2007-10-02 01:38 ---
Subject: Bug 33572
Author: aoliva
Date: Tue Oct 2 01:37:59 2007
New Revision: 128939
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128939
Log:
PR tree-optimization/33572
* tree-cfg.c (verify_stmts): Check
--- Comment #5 from danglin at gcc dot gnu dot org 2007-10-02 02:18 ---
Subject: Bug 31828
Author: danglin
Date: Tue Oct 2 02:17:50 2007
New Revision: 128947
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128947
Log:
PR testsuite/31828
gcc.dg/float-range-3.c
--- Comment #6 from danglin at gcc dot gnu dot org 2007-10-02 02:19 ---
Fixed.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
93 matches
Mail list logo
