--- Comment #2 from christian dot metzler at bmw-carit dot de 2006-02-22
08:11 ---
Simple test case:
int main(int argc, char **argv) {
float t;
char u;
t = 1.0;
u = ( ( t0.0)?-1:((t0.0)?1:0));
return (int)u;
}
Compiles e.g. on i386 and
--- Comment #17 from jakub at gcc dot gnu dot org 2006-02-22 08:11 ---
The nop before the signal trampoline is needed for similar reason, but one
signal frame lower. A normal signal frame lower in the stack will contain
the exact address of the start of the trampoline (or in unusual
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-02-22 09:55 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #18 from uweigand at gcc dot gnu dot org 2006-02-22 09:57
---
(In reply to comment #17)
(e.g. s390/linux-unwind.h was doing that, although just for 2 selected
signals, which wasn't good enough, as e.g. all async signals need to be
handled the same).
We've actually
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-02-22 10:05 ---
Interesting. a_3 is not single use, so we shouldn't do this. Investigating.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from uros at kss-loka dot si 2006-02-22 10:15 ---
Works OK with gcc-4.2 and -Os -msse -fomit-frame-pointer.
--
uros at kss-loka dot si changed:
What|Removed |Added
--- Comment #19 from jakub at gcc dot gnu dot org 2006-02-22 10:25 ---
Sure, if you want to do that for s390, s390/linux-unwind.h can still do
if (!signo || (*signo != 4 *signo != 5 *signo != 8))
fs-signal_frame = 1;
(I think !signo - fs-signal_frame = 1; is better default, there
The following code causes gcc to crash when openmp is enabled:
bug2.c:
/*
* This program triggers an openmp bug in gcc 4.2:
Using built-in specs.
Target: powerpc-apple-darwin8.4.0
Configured with: /opt/local/var/db/dports/build/_opt_local_var_db_dports_sour
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-02-22 10:32 ---
find_equivalent_equality_comparison through simplify_cond,
forward_propagate_into_cond does this. I have a patch which restricts forwprop
to using single-use names. Though I wonder if this is appropriate and we
--- Comment #2 from schwab at suse dot de 2006-02-22 10:40 ---
You need to use %h2.
--
schwab at suse dot de changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-02-22 11:30 ---
Providing -frandom-seed=0 is a workaround.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26399
--- Comment #18 from roger dot larsson at norran dot net 2006-02-22 11:31
---
(In reply to comment #16)
raising severity because this bug makes -Os almost useless on modern x86.
With gcc version 4.0.2 20050901 (prerelease) (SUSE Linux)
my testcase works but not Serge Belyshevs
--
trunk 20060218, on m68k-linux:
Matthias
/build/buildd/gcc-snapshot-20060218/build/./prev-gcc/xgcc
-B/build/buildd/gcc-snapshot-20060218/build/./prev-gcc/
-B/usr/lib/gcc-snapshot/m68k-linux-gnu/bin/ -c -O2 -DIN_GCC -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-02-22 12:47 ---
Of course we have the other case where we _have_ to propagate to optimize away
the test (gcc.dg/tree-ssa/20030807-2.c):
foo(int n)
{
int *space = (int *)__builtin_alloca (n);
if (space == 0)
abort ();
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-02-22 12:49 ---
Created an attachment (id=10891)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10891action=view)
patch restricting forwprop
Patch that apart from regressing gcc.dg/tree-ssa/20030807-2.c bootstrapped and
tested
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-02-22 12:58 ---
(In reply to comment #6)
Patch that apart from regressing gcc.dg/tree-ssa/20030807-2.c bootstrapped and
tested ok.
There is no regressions here as this test is already failing before your patch,
see PR 26344.
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-22 13:01 ---
Confirmed, backtrace:
#0 0x00105ff4 in omp_add_variable (ctx=0x429008e0, decl=0x41edae70, flags=5)
at /Users/pinskia/src/gcc/local/gcc/gcc/gimplify.c:4271
#1 0x00105fc0 in omp_add_variable (ctx=0x429008e0,
--- Comment #8 from patchapp at dberlin dot org 2006-02-22 13:10 ---
Subject: Bug number PR26406
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-02/msg01754.html
--
The code below generates a compiler ICE with g++ 3.3 (debian stable),
g++ 3.4 (debian testing):
[pollindd] ~ g++-3.3 -c ice-typeid.cc
1036
ice-typeid.cc: In function `int bug5(BaseB*)':
ice-typeid.cc:43: internal compiler error: in expand_expr, at expr.c:8833
Please submit a full bug
/*
This code segfaults when executed on gcc 4.01 on i586/linux (mandriva 2006)
Works fine on gcc 3.x - couldn't find a newer version to test it on.
PS I couldn't find anything in your bug writing guidelines what to put in
host triplet etc...
gcc -v:
Using built-in specs.
Target:
--- Comment #1 from fuchsia dot groan at virgin dot net 2006-02-22 13:41
---
No compile options just g++ test.cpp generates faulty code
--
fuchsia dot groan at virgin dot net changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-22 13:59 ---
Also confirmed on x86_64-linux-gnu with the same backtrace.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26412
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-22 14:04 ---
ptr+alloc()
The C and the C++ standard does not say which of ptr and alloc() is evaluated
first so GCC is producing code which evaluates ptr before calling alloc which
is ok for C and C++.
*** This bug has been
--- Comment #59 from pinskia at gcc dot gnu dot org 2006-02-22 14:04
---
*** Bug 26418 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from jv244 at cam dot ac dot uk 2006-02-22 14:08 ---
Added Jan Hubicka, since he seems the original author of the code that fails
(hope I get it right this time) and might have an idea on how to fix this in
time for 4.0.3
--
jv244 at cam dot ac dot uk changed:
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-22 14:09 ---
Yes this is a dup of bug 25357.
*** This bug has been marked as a duplicate of 25357 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-02-22 14:09 ---
*** Bug 26417 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-22 14:10 ---
The reason why I say it is a dup is because it works in 4.1.0 and the mainline
just fine and 4.0.3 gave the same ICE for both of the bugs.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26417
The documentation for -ftree-vectorizer-verbose doesn't give the slightest
hints
on useful values for n:
-ftree-vectorizer-verbose=n
This option controls the amount of debugging output the vectorizer prints.
This information is written to standard error, unless -fdump-tree-all or
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-02-22 14:18
---
Even shorter testcase:
==
extern int table[];
void foo()
{
#pragma omp parallel
table[0];
}
==
--
reichelt at gcc dot gnu dot org changed:
What
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-22 14:19 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
tramp3d-v4.cpp:3740: note: vectorized 0 loops in function.
tramp3d-v4.cpp:3740: note: vectorized 0 loops in function.
tramp3d-v4.cpp:50941: note: vectorized 0 loops in function.
tramp3d-v4.cpp:3740: note: vectorized 0 loops in function.
tramp3d-v4.cpp:3740: note: vectorized 0 loops in
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-22 14:27 ---
This works for me, at both -O2 and -O0. Please report a new bug if you can
give more information and don't put the preprocessed source in the gccbug.
Attach it after the fact.
--
pinskia at gcc dot gnu dot org
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-22 14:31 ---
I have seen a bug like this before.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26390
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-22 14:32 ---
(In reply to comment #2)
Still, it would be lots better if warning options simply enabled the necessary
analysis.
It is very hard to do so as the warnings are based on the information gathered
from
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-22 14:34 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rootkit85 at yahoo dot it 2006-02-22 14:40 ---
I have broken RAM.
Sorry for complaining gcc
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26407
--- Comment #1 from reichelt at gcc dot gnu dot org 2006-02-22 15:10
---
Confirmed.
Even shorter testcase:
==
int i=0;
#pragma omp threadprivate (i)
void foo()
{
i=0;
}
==
--
reichelt at gcc dot gnu dot org
--- Comment #5 from danglin at gcc dot gnu dot org 2006-02-22 15:22 ---
The libiberty version is documented as unsigned and has been this
way for many years. The Open Group has a strawman proposal which may
be submitted to the Austin Group for addition to POSIX in its next
release. It
--- Comment #9 from law at redhat dot com 2006-02-22 15:24 ---
Subject: Re: Fowardprop does harm for VRP to
figure out if a point is non zero
On Wed, 2006-02-22 at 10:32 +, rguenth at gcc dot gnu dot org wrote:
--- Comment #4 from rguenth at gcc dot gnu dot org
The function in question should ignore ADDR_EXPRs that appear inside CALL_EXPR
parameter lists so that we, for
typedef struct {
int i;
int j;
int k;
} Foo;
void bar(Foo*);
void foo(void)
{
Foo a;
a.i = 1;
bar(a);
}
do not create SFTs for all elements of a, but only for the first.
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-22 16:02 ---
Really for this example:
For this case V_MAY_DEF's are dead anyways at least for the other SFT's besides
the one for a.i.
Try thinking what about:
typedef struct {
int i;
int j;
int k;
} Foo;
void bar(Foo*);
--- Comment #3 from sabre at nondot dot org 2006-02-22 16:11 ---
Fair enough. Shouldn't this be diagnosed with an error though?
-Chris
--
sabre at nondot dot org changed:
What|Removed |Added
--- Comment #10 from law at redhat dot com 2006-02-22 16:22 ---
Subject: Re: Fowardprop does harm for VRP to
figure out if a point is non zero
On Wed, 2006-02-22 at 12:47 +, rguenth at gcc dot gnu dot org wrote:
A little history...
DOM was pretty clever in that it had the
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-02-22 16:23 ---
I get
bb 2:
# SFT.0D.1534_2 = V_MUST_DEF SFT.0D.1534_1;
aD.1532.iD.1521 = 1;
# SFT.0D.1534_3 = V_MAY_DEF SFT.0D.1534_2;
bar (aD.1532);
# SFT.0D.1534_4 = V_MAY_DEF SFT.0D.1534_3;
bar2 (aD.1532);
--
pcarlini at suse dot de changed:
What|Removed |Added
Target Milestone|--- |4.1.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26132
--- Comment #18 from rguenth at gcc dot gnu dot org 2006-02-22 16:30
---
As this is a wrong-code regression for 4.1 (albeit on ia64-linux), Mark should
re-consider the priority and maybe allow this patch in. And the patch
submitter should have asked for that in the first place (and
Configured with: ../gcc/configure --prefix=/Users/dir/gfortran
--enable-languages=c,f95
Thread model: posix
gcc version 4.2.0 20060222 (experimental)
[dranta:~/tests/gfortran-D] dir% cat testio7.f
program test
implicit real*8 (a-h,o-z)
dimension a(8476)
istoh=8476
do 10 j
The number of buckets is currently limited to ~2^32 (see X::primes). This is
a serious issue: for correctness, rehash(n) for n 2^32 should throw and do
nothing, in order not to violate the post-conditions in Table 21.
We have various options: as suggested by Howard off-line, we could well
--- Comment #19 from hjl at gcc dot gnu dot org 2006-02-22 16:59 ---
Subject: Bug 25603
Author: hjl
Date: Wed Feb 22 16:59:45 2006
New Revision: 111365
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111365
Log:
2006-02-22 H.J. Lu [EMAIL PROTECTED]
PR target/25603
--- Comment #20 from hjl at lucon dot org 2006-02-22 17:04 ---
I don't want to see this patch hold up 4.1.0 release. I will ask it be
applied to the 4.1 branch when it is open. But it is Mark's call.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25603
I just tried to compile a recent Linux kernel with a recent
GNU C++ compiler version 4.2 snapshot 20060218.
The compiler snapshot said
/home/dcb/gnu/42-20060218/results/bin/gcc -g -O3 -Wall
-Wp,-MD,security/keys/.keyring.o.d -nostdinc -isystem
--- Comment #1 from paolo at gcc dot gnu dot org 2006-02-22 17:06 ---
Subject: Bug 26132
Author: paolo
Date: Wed Feb 22 17:05:58 2006
New Revision: 111366
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111366
Log:
2006-02-22 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #1 from dcb314 at hotmail dot com 2006-02-22 17:06 ---
Created an attachment (id=10892)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10892action=view)
C source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26425
--- Comment #1 from falk at debian dot org 2006-02-22 17:11 ---
Just curious: is the assumption of prime-size buckets hardwired in the TR?
Otherwise, the obvious alternative would be to use power-of-two sizes, which
are much faster in access.
--
--- Comment #8 from bkoz at gcc dot gnu dot org 2006-02-22 17:17 ---
This is now fixed to my satisfaction.
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-02-22 17:22
---
Subject: Bug 26291
Author: reichelt
Date: Wed Feb 22 17:22:08 2006
New Revision: 111367
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111367
Log:
PR c++/26291
* decl.c (grok_op_properties):
--- Comment #2 from pcarlini at suse dot de 2006-02-22 17:23 ---
(In reply to comment #1)
Just curious: is the assumption of prime-size buckets hardwired in the TR?
Otherwise, the obvious alternative would be to use power-of-two sizes, which
are much faster in access.
Yes. Really, I
--- Comment #9 from bkoz at gcc dot gnu dot org 2006-02-22 17:26 ---
HP, I also don't know what is going on here, but it seems unlikely that the
libstdc++ code is to blame, just because there's been no change to this part of
libstdc++ in quite a while.
One thing you could check, if
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-22 17:34 ---
Reducing (which means I can reproduce this ICE).
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-02-22 17:35
---
Fixed on mainline.
Waiting for the 4.1 branch to reopen.
Testing on the 4.0 and 3.4 branch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-22 17:55 ---
It is ICEing in the last VRP.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-22 17:59 ---
Reduced testcase:
struct keyring_list {
struct key *keys[0];
};
void keyring_destroy(struct keyring_list *keyring, unsigned short a)
{
int loop;
for (loop = a - 1; loop = 0; loop--)
--- Comment #3 from pcarlini at suse dot de 2006-02-22 18:01 ---
... something considered obvious in the literature is that the size policy
goes together with the range-hashing function: e.g., an exponential size-policy
would not work well together with our default modulo range-hashing
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-02-22 18:07 ---
Hmm, for some reason the Type's TYPE_MAX_VALUE is null.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26425
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-22 18:10 ---
Hmm, this worked in 4.0.3 at least on x86_64-linux-gnu.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26423
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-22 18:11 ---
But not with 4.2.0 on x86_64-linux so confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from law at redhat dot com 2006-02-22 18:18 ---
Subject: Re: [4.2 Regression] ice on valid C
code with flag -Os
On Wed, 2006-02-22 at 18:07 +, pinskia at gcc dot gnu dot org wrote:
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-02-22 18:07
Consider:
struct A { virtual ~A(); }; // 4
struct B { virtual ~B(); }; // 4
struct X : virtual public A,
virtual public B { // 8
};
struct Y : virtual public B { // 4
virtual ~Y();
};
struct Z : virtual public X, public Y { // 8
Z();
};
Z::Z() {}
In
--- Comment #9 from mueller at gcc dot gnu dot org 2006-02-22 18:53 ---
Yes, thanks.
--
mueller at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-22 18:57 ---
I am working on this again.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Testcase:
struct a {};
static const int d = 1;
static const struct a b = {};
static const int c = 1;
int f(const int *, const struct a *, const int*, const int*);
int g(void)
{
return f(c, b, d, c);
}
int f(const int *b, const struct a *c, const int *d, const int *e)
{
return *b == *d;
}
int
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-22 19:00 ---
This causes a lot of the gfortran testsuite to fail.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26427
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-22 19:19 ---
Patch posted:
http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01774.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
When using g++ as a compiler and my program is trying to substract to floats
that have the same ending digits, after comma, or even when the digits are not
even or odd at the same time the returned number is buged!
For example:
105.8 - 108.5 === 2.67
583.4 - 1583.4 === 1000.099976
The same
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-22 20:24 ---
And why do you think this is a bug?
Floating point is not the same as math as you would do on paper.
Also where is the testcase?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26428
--- Comment #2 from g dot delaportas at gmail dot com 2006-02-22 20:29
---
It is abdolutely true and well known that 1583.5-583.4=1000.1
Its defenate. Simple mathematics
Its not my problem if u have problems with maths!
Try your calculators and pleas do not reply stupid thing!
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-22 20:31 ---
(In reply to comment #2)
It is abdolutely true and well known that 1583.5-583.4=1000.1
Who said that 1000.1 can be repesented exactly in the computer?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26428
--- Comment #4 from g dot delaportas at gmail dot com 2006-02-22 20:34
---
(In reply to comment #3)
(In reply to comment #2)
It is abdolutely true and well known that 1583.5-583.4=1000.1
Who said that 1000.1 can be repesented exactly in the computer?
okso explain to me why
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-02-22 20:44 ---
Well the caculator is using higher precission (maybe even unlimited) floating
point than what your testcase would look like.
Again where is the testcase?
Also you should go read some papers about floating point in
--- Comment #6 from g dot delaportas at gmail dot com 2006-02-22 20:46
---
(In reply to comment #5)
Well the caculator is using higher precission (maybe even unlimited) floating
point than what your testcase would look like.
Again where is the testcase?
Also you should go read
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-02-22 20:48 ---
(In reply to comment #6)
TEST CASE
I mean some source code.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-02-22 20:50
---
Confirmed on i686-linux (trunk) too:
$ cat testio.f
integer :: a(8476)
a(1) = 1
write(2) a
a(1) = 2
write(2) a
rewind 2
read(2) a
write(*,*) a(1)
read(2) a
--- Comment #8 from steven at gcc dot gnu dot org 2006-02-22 20:50 ---
User doesn't understand number representations in computers.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from g dot delaportas at gmail dot com 2006-02-22 20:53
---
(In reply to comment #7)
(In reply to comment #6)
TEST CASE
I mean some source code.
Oh the source code is rather simple
float Val1,Val2,Val3;
Val1=1583.5;
Val2=583.4;
Val3=Val2-Val1;
--- Comment #11 from rguenth at gcc dot gnu dot org 2006-02-22 20:55
---
So I suppose VRP cannot see backwards for
i_2 = j_1;
if (i_2 == 0)
return j_1;
? (of course copyprop would clean this up, but suppose for a moment this
gets to VRP)
If it can see that i_1 is zero at
--- Comment #10 from g dot delaportas at gmail dot com 2006-02-22 20:56
---
If u don't understand that this is not right then u have a big problem in
mathematics cause bc,xcalc or whatever and all the other compilers i have
tested in other operating systems returned the actual and
For
typedef struct {
int i;
int j;
int k;
} Foo;
void bar(Foo*);
void foo(void)
{
{
Foo a;
bar(a);
}
{
Foo b;
bar(b);
}
}
we have in the alias1 dump:
foo ()
{
struct Foo b;
struct Foo a;
bb 2:
# a_3 = V_MAY_DEF a_1;
# b_4 = V_MAY_DEF b_2;
bar (a);
When using g++ as a compiler and my program is trying to substract to floats
that have the same ending digits, after comma, or even when the digits are not
even or odd at the same time the returned number is buged!
For example:
105.8 - 108.5 === 2.67
1583.5- 583.4 === 1000.099976
The same
When using g++ as a compiler and my program is trying to substract to floats
that have the same ending digits, after comma, or even when the digits are not
even or odd at the same time the returned number is buged!
For example:
105.8 - 108.5 === 2.67
1583.5- 583.4 === 1000.099976
The same
--- Comment #1 from pcarlini at suse dot de 2006-02-22 21:15 ---
*** This bug has been marked as a duplicate of 26428 ***
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #11 from pcarlini at suse dot de 2006-02-22 21:15 ---
*** Bug 26430 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26428
--- Comment #2 from pcarlini at suse dot de 2006-02-22 21:16 ---
*** This bug has been marked as a duplicate of 26428 ***
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #12 from pcarlini at suse dot de 2006-02-22 21:16 ---
*** Bug 26431 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26428
--- Comment #1 from g dot delaportas at gmail dot com 2006-02-22 21:15
---
There is no EXCUSES for higher or lower bitsthe numbers are WRONG and this
should be fixed
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26431
--- Comment #7 from law at redhat dot com 2006-02-22 21:30 ---
Subject: Re: [4.2 Regression] ice on valid C
code with flag -Os
On Wed, 2006-02-22 at 18:07 +, pinskia at gcc dot gnu dot org wrote:
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-02-22 18:07
our current kernel does does boot ok on G4 systems (PowerMac, Pegasos2),
but it locksup early (before the atyfb init) on a G3 ibook, no idea where
exactly.
gcc33 hammer as shipped with SLES9 works ok, gcc-4_0-branch works ok,
gcc-4_1-branch does not boot.
cant test gcc-mainline because make does
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-02-22 21:32 ---
Patch posted, but now stdarg-5.c ICEs.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from law at redhat dot com 2006-02-22 21:45 ---
Subject: Re: Fowardprop does harm for VRP to
figure out if a point is non zero
On Wed, 2006-02-22 at 20:55 +, rguenth at gcc dot gnu dot org wrote:
--- Comment #11 from rguenth at gcc dot gnu dot org
1 - 100 of 137 matches
Mail list logo
