http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36299
--- Comment #9 from Vincent Lefèvre vincent at vinc17 dot org 2011-03-02
15:17:33 UTC ---
(In reply to comment #8)
Every warning warns about something valid in C, otherwise it would be an error
not a warning.
No, for instance:
int main(void
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36299
--- Comment #5 from Vincent Lefèvre vincent at vinc17 dot org 2011-03-01
15:05:19 UTC ---
Under Debian, I can no longer reproduce the problem with GCC 4.5.2:
$ gcc-4.5 -Wall warn-nulladdress.c
$ gcc-4.5 -Waddress warn-nulladdress.c
$ gcc-4.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36299
--- Comment #7 from Vincent Lefèvre vincent at vinc17 dot org 2011-03-02
01:15:23 UTC ---
(In reply to comment #6)
I think the intention is to warn, at least for a == (void *)0, since the
address of a cannot be zero or null. So I would say
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45248
--- Comment #12 from Vincent Lefèvre vincent at vinc17 dot org 2011-02-08
03:42:08 UTC ---
(In reply to comment #11)
Any updates on this? re-confirmation? I would like to continue testing
gcc-4.5.x on powerpc-darwin8, but can't b/c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44455
--- Comment #19 from Vincent Lefèvre vincent at vinc17 dot org 2010-12-12
23:02:58 UTC ---
FYI, the problem has been handled in the MPFR trunk r7291 for MPFR 3.1.0.
MPFR's configure script now retrieves the location of the GMP source from GMP's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46180
Vincent Lefèvre vincent at vinc17 dot org changed:
What|Removed |Added
CC||vincent
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46080
--- Comment #7 from Vincent Lefèvre vincent at vinc17 dot org 2010-10-20
23:43:33 UTC ---
But there's something strange in the generated code: sometimes the fsqrt
instruction is used, sometimes call sqrtf is used (for the same sqrtf() call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46080
Summary: incorrect precision of sqrtf builtin for x87
arithmetic (-mfpmath=387)
Product: gcc
Version: 4.4.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46080
--- Comment #2 from Vincent Lefèvre vincent at vinc17 dot org 2010-10-20
01:51:56 UTC ---
Created attachment 22089
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22089
sh script to test sqrtf
Similar problems can also be found
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45248
Vincent Lefèvre vincent at vinc17 dot org changed:
What|Removed |Added
CC||vincent
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vincent at vinc17 dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44842
--- Comment #7 from vincent at vinc17 dot org 2010-04-07 09:29 ---
This bug is still open, though it appears to be fixed. Is there any reason?
--
vincent at vinc17 dot org changed:
What|Removed |Added
with 'a'
type character
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vincent at vinc17 dot org
http://gcc.gnu.org
--- Comment #5 from vincent at vinc17 dot org 2010-04-07 10:58 ---
This bug should probably be resolved as fixed as well.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39037
is -
0
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vincent at vinc17 dot org
http://gcc.gnu.org/bugzilla
--- Comment #1 from vincent at vinc17 dot org 2010-03-18 14:33 ---
If I understand correctly, the bug appears with:
r119248 | rguenth | 2006-11-27 12:38:42 +0100 (Mon, 27 Nov 2006) | 10 lines
2006-11-27 Richard Guenther rguent...@suse.de
PR middle-end/25620
--- Comment #18 from vincent at vinc17 dot org 2010-03-18 14:37 ---
The patch affected C, where the transformation of pow(x, 0.5) into sqrt(x) is
incorrect. See PR 43419.
--
vincent at vinc17 dot org changed:
What|Removed |Added
--- Comment #11 from vincent at vinc17 dot org 2010-02-19 13:08 ---
(In reply to comment #10)
This issue was discussed on the WG14 reflector in October 2008, and the
general
view was that the standard should not make INT_MIN % -1 well defined (as this
would impose a significant
--- Comment #4 from vincent at vinc17 dot org 2009-11-26 15:53 ---
(In reply to comment #1)
Aliasing rules are indeed broken because you access a union of anonymous type
through a pointer to a union of type ieee_double_extract.
OK, the real code in MPFR is a double accessed through
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vincent at vinc17 dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42179
--- Comment #7 from vincent at vinc17 dot org 2009-11-23 04:51 ---
(In reply to comment #6)
Not a GCC bug, the POSIX list generally agreed the effects of reordering
system directories should be unspecified or undefined.
What the POSIX list says does not matter if this doesn't go
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vincent at vinc17 dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40960
--- Comment #2 from vincent at vinc17 dot org 2009-08-04 13:29 ---
There would the possibility to have a POSIX mode implied by c99, but I don't
think having different behaviors would be a good idea. IMHO, Makefiles should
be fixed to stick to POSIX.
Also, portable Makefiles, i.e
--- Comment #131 from vincent at vinc17 dot org 2009-07-22 17:33 ---
(In reply to comment #130)
#define axiom_order(a,b) !(a b b a)
#define axiom_eq(a) a == a
#define third ((double)atoi(1)/atoi(3))
[...]
in C99 (+TC1,TC2,TC3) different precision
--- Comment #4 from vincent at vinc17 dot org 2009-06-15 11:59 ---
(In reply to comment #3)
If you have modified the implementation (by putting headers/libraries in
standard directories where those headers/libraries were not provided by
the implementation in those versions in those
: vincent at vinc17 dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40442
--- Comment #2 from vincent at vinc17 dot org 2009-06-15 02:08 ---
This may be true for standard headers, but system directories don't contain
only standard headers: in practice, they generally also contain additional
libraries. And for instance, a -I/usr/include can be useful
--- Comment #8 from vincent at vinc17 dot org 2009-05-18 14:56 ---
Are you sure that this comes from the extended precision? This would mean that
GCC does implicit extended - double conversions in an asymmetric way, and
IIRC, I've never seen that.
I can't reproduce the problem with g
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vincent at vinc17 dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39867
--- Comment #1 from vincent at vinc17 dot org 2009-04-23 13:44 ---
I forgot to say: the bug occurs whether one compiles with optimizations or not.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39867
--- Comment #125 from vincent at vinc17 dot org 2008-11-11 10:13 ---
(In reply to comment #124)
It seems like the C99 standard prohibits double rounding,
only if Annex F is claimed to be supported (note: Annex F is not just IEEE 754,
it also contains specific bindings). IEEE 754
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vincent at vinc17 dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37845
: unassigned at gcc dot gnu dot org
ReportedBy: vincent at vinc17 dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37846
--- Comment #3 from vincent at vinc17 dot org 2008-10-16 13:54 ---
(In reply to comment #1)
Confirmed. The FP_CONTRACT macro is not implemented, but the default behavior
of GCC is to behave like it was set to OFF.
The problem is that on PowerPC, x*y+z is fused (contracted
--- Comment #14 from vincent at vinc17 dot org 2008-10-16 14:20 ---
(In reply to comment #12)
Turning -frounding-math on by default would be a disservice to (most of) our
users which is why the decision was made (long ago) to not enable this by
default.
The compiler should generate
--- Comment #16 from vincent at vinc17 dot org 2008-10-16 17:39 ---
I was suggesting to improve the behavior by having -frounding-math by default
(at least when the user compiles with -std=c99 -- if he does this, then this
means that he shows some interest in a conforming implementation
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vincent at vinc17 dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37838
--- Comment #9 from vincent at vinc17 dot org 2008-10-15 21:29 ---
What was said in bug 37838 but not here is that -frounding-math sometimes fixes
the problem. So, I was suggesting that -frounding-math should be enabled by
default.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #11 from vincent at vinc17 dot org 2008-10-15 22:33 ---
(In reply to comment #10)
The default of -fno-rounding-math is chosen with the reason that this is what
a compiler can assume if #pragma STDC FENV_ACCESS is not turned on.
The C standard doesn't require a compiler
--- Comment #8 from vincent at vinc17 dot org 2008-09-06 18:42 ---
(In reply to comment #7)
Does increasing bits cause floating point errors. How could 64 bit precison
give correct result where as 80 bit give incorrect one.
You can have rounding errors whether you increase
--- Comment #11 from vincent at vinc17 dot org 2008-09-06 22:19 ---
(In reply to comment #10)
The funny thing is that this only happens with -O2 or -O1 but not with -O0 ie
no optimization it is all correct , when we optimize the results start
varying.
Because with -O0, some values
--- Comment #3 from vincent at vinc17 dot org 2008-08-23 20:00 ---
(In reply to comment #2)
this warning was added on purpose, because probably someone requested it. I
don't see that it is very different from the documented case of using the
address of a function in a conditional
--- Comment #9 from vincent at vinc17 dot org 2008-08-18 22:58 ---
(In reply to comment #8)
Please provide a preprocessed reduced testcase as similar to the original as
possible.
Here's a similar testcase.
$ cat tst.c
void *foo (void);
void bar (void *);
void f (void)
{
int init
--- Comment #11 from vincent at vinc17 dot org 2008-08-19 01:31 ---
(In reply to comment #10)
If I replace the value 2 by 1 I still get the warning in GCC 4.4, so that
really sounds strange. Are you sure about that?
Yes and here Debian's GCC 4.4 snapshot has the same behavior as GCC
--- Comment #120 from vincent at vinc17 dot org 2008-07-17 12:41 ---
(In reply to comment #119)
REAL RESULT:
5.313991e+33
5.313991e+33
0.00e+00
0.00e+00
Only without optimizations. But since the ISO C standard allows expressions to
be evaluated in a higher precision
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: driver
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vincent at vinc17 dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36731
--- Comment #3 from vincent at vinc17 dot org 2008-07-04 19:34 ---
(In reply to comment #1)
Works if you provide an (empty) input file:
[...]
There's mtune, but not march. Also, most users probably don't know that.
(In reply to comment #2)
They do already via the configure options
--- Comment #118 from vincent at vinc17 dot org 2008-06-24 20:45 ---
(In reply to comment #117)
By a lucky hit, I have found this in the GCC documentation:
-mpc32
-mpc64
-mpc80
OK, this is new in gcc 4.3. I haven't tried, but if gcc just changes the
precision without changing
--- Comment #116 from vincent at vinc17 dot org 2008-06-22 21:14 ---
(In reply to comment #114)
Yes, but this requires quite a complicated workaround (solution (4) in my
comment #109).
The problem is on the compiler side, which could store every result of a cast
or an assignment
: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vincent at vinc17 dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36588
--- Comment #113 from vincent at vinc17 dot org 2008-06-22 00:52 ---
(In reply to comment #112)
It's true that double *precision* is available on x87. But not the *IEEE-754
double precision type*.
It is available when storing a result to memory.
Beside the precision of mantissa
--- Comment #111 from vincent at vinc17 dot org 2008-06-20 16:09 ---
(In reply to comment #109)
WHERE'S THE BUG
This is really not a GCC bug. The bug is actually in the x87 FPU because it
doesn't obey the IEEE standard.
Concerning the standards: The x87 FPU does obey the IEEE754
ReportedBy: vincent at vinc17 dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36578
--- Comment #1 from vincent at vinc17 dot org 2008-06-19 14:37 ---
To make things clear, perhaps I should have added:
#if __STDC__ == 1 __STDC_VERSION__ = 199901 defined(__STDC_IEC_559__)
#pragma STDC FP_CONTRACT OFF
printf (__STDC_IEC_559__ defined:\n
The implementation
: major
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vincent at vinc17 dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36484
--- Comment #2 from vincent at vinc17 dot org 2008-06-10 09:09 ---
(In reply to comment #1)
You should try out 4.3.1.
As I said, I could reproduce the problem with this version too (but there's a
bug in gmp.h, so I was not sure).
--
vincent at vinc17 dot org changed
--- Comment #4 from vincent at vinc17 dot org 2008-06-10 11:26 ---
cmpb$42, -481(%rbp)
je .L458
jmp .L456
.L463:
cmpb$85, -481(%rbp)
je .L461
cmpb$90, -481(%rbp)
je .L462
jmp .L456
.L458
--- Comment #6 from vincent at vinc17 dot org 2008-06-10 12:37 ---
OK, but shouldn't g++ generate a SIGABRT instead of a illegal instruction? I've
never had thought that a compiler should generate an illegal instruction on
purpose, so making me think that the problem comes from
--- Comment #8 from vincent at vinc17 dot org 2008-06-10 14:02 ---
I agree about SIGSEGV. But what about abort()? Wouldn't this be cleaner? This
builtin trap is quite similar to a failed assertion (often used to avoid
undefined behavior), isn't it?
--
http://gcc.gnu.org/bugzilla
--- Comment #10 from vincent at vinc17 dot org 2008-06-10 14:52 ---
(In reply to comment #9)
Calling abort() doesn't work with free-standing environments.
OK, but how about using an illegal instruction with free-standing environments
and abort() with hosted ones? After all, the abort
--- Comment #11 from vincent at vinc17 dot org 2008-06-10 15:21 ---
Here's the testcase (I've never used va_list and so on myself, so I hope it is
correct; at least it shows the missing warning problem). With gcc -Wall
-std=c99 -Wc++-compat -pedantic -Wextra, I don't get any warning
--- Comment #7 from vincent at vinc17 dot org 2008-05-28 08:18 ---
(In reply to comment #6)
(In reply to comment #5)
BTW, the i = i trick
it only works in the initializer and not as a statement after the fact.
But in such a case, as i is not initialized yet, this may be undefined
--- Comment #2 from vincent at vinc17 dot org 2008-05-22 08:34 ---
The severity should probably be changed to enhancement because gcc behaves as
documented (well, almost).
What can be done IMHO is:
1. Split the -Wuninitialized into two different warnings: one for which gcc
knows
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vincent at vinc17 dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36299
--- Comment #4 from vincent at vinc17 dot org 2008-05-22 11:01 ---
(In reply to comment #3)
A way to tell gcc a variable is not uninitialized is to perform
self-initialization like
int i = i;
This doesn't seem to be valid C code.
this will cause no code generation but inhibits
--- Comment #5 from vincent at vinc17 dot org 2008-05-22 11:23 ---
BTW, the i = i trick, which is guaranteed to be valid and no-op only *after* i
has been initialized doesn't avoid the warning in such a case. I don't know if
this would be a good feature (the main drawback I can see
--- Comment #3 from vincent at vinc17 dot org 2008-04-24 15:04 ---
Is there any reason why this hasn't been fixed yet? (The trunk still has the
error. And I'm asking this because there's only one word to change.)
--
vincent at vinc17 dot org changed:
What|Removed
--- Comment #4 from vincent at vinc17 dot org 2007-05-22 22:50 ---
(In reply to comment #3)
My recollection is that the special -I behavior is there because
the system headers have special non-warning properties.
This situation doesn't apply to -L.
But this introduces
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vincent at vinc17 dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31186
--- Comment #2 from vincent at vinc17 dot org 2007-03-15 16:51 ---
(In reply to comment #1)
I don't think this is a bug, you need to read the other part of the document
which says if you supply -I DEFAULT_DIR, it is ignored.
OK, but this isn't very clear, as the description under
--- Comment #1 from vincent at vinc17 dot org 2007-01-16 22:03 ---
Is this specific to x86? On PowerPC (gcc 4.0.1 from Mac OS X), I get:
-2147483648 % -1 - -2147483648
Ditto with:
#include limits.h
#include stdio.h
int main (void)
{
volatile int i = INT_MIN, j = -1;
printf (%d\n
--- Comment #2 from vincent at vinc17 dot org 2007-01-16 22:10 ---
-2147483648, this was on a G5, with gcc 4.0.1 under Mac OS X. On a G4 under
Linux, with gcc 4.1.2 prerelease (Debian), I get 2147483647.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30484
--- Comment #33 from vincent at vinc17 dot org 2006-11-05 23:27 ---
(In reply to comment #32)
(In reply to comment #31)
(In reply to comment #30)
So, I don't think a mpfr_signgam alone would really be useful. So, I think
that
choice 2 would be better.
Okay, sounds fine
--- Comment #31 from vincent at vinc17 dot org 2006-11-02 15:57 ---
(In reply to comment #30)
So, I don't think a mpfr_signgam alone would really be useful. So, I think that
choice 2 would be better.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335
--- Comment #26 from vincent at vinc17 dot org 2006-10-31 09:54 ---
(In reply to comment #25)
As I think about it more, I'm leaning toward having a new function
mpfr_lgamma.
This is because if we want this mpfr function to mimic the behavior of
lgamma,
we need some mechanism
--- Comment #28 from vincent at vinc17 dot org 2006-10-31 22:15 ---
(In reply to comment #27)
It's likely that I'll end up doing it, so would you please tell me how?
According to the C rationale (I haven't checked), the sign of gamma(x) is -1 if
[iff] x 0 remainder(floor(x), 2) != 0
--- Comment #18 from vincent at vinc17 dot org 2006-10-28 09:07 ---
(In reply to comment #17)
Yes, I can reproduce the NaN. In fact, any negative value
gives a NaN.
Not any negative value, but in lngamma.c:
/* if x 0 and -2k-1 = x = -2k, then lngamma(x) = NaN */
probably
--- Comment #20 from vincent at vinc17 dot org 2006-10-28 14:05 ---
(In reply to comment #19)
The documenation in MPFR says:
-- Function: int mpfr_lngamma (mpfr_t ROP, mpfr_t OP, mp_rnd_t RND)
Set ROP to the value of the Gamma function on OP, and its
logarithm
--- Comment #22 from vincent at vinc17 dot org 2006-10-28 16:58 ---
(In reply to comment #21)
Since you mentioned C functions missing in MPFR, what are your plans for the
Bessel functions? I'd like to hook up builtins j0/j1/jn/y0/y1/yn. Thanks.
They're in the TODO
--- Comment #2 from vincent at vinc17 dot org 2006-10-25 14:00 ---
(In reply to comment #1)
So this sounds like a bug in your installation.
This cannot be with my installation in particular as the bug occurred on
various Linux machines (only one is mine). However it could be due
path
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vincent at vinc17 dot org
GCC host
--- Comment #3 from vincent at vinc17 dot org 2006-10-10 13:53 ---
(In reply to comment #2)
What's worrying me a bit is the versioning of MPFR.
Note that GMP is similar.
Vincent, would it be possible that some version number is increased every
time a patch is posted, so
gnu dot org
ReportedBy: vincent at vinc17 dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28800
--- Comment #17 from vincent at vinc17 dot org 2006-06-08 07:18 ---
The patch looks strange to me too: is there any reason why the optimization
would be correct under wrapping? i.e. I don't understand why -fwrapv can fix
the problem (as said in comment #1).
--
http://gcc.gnu.org
--- Comment #5 from vincent at vinc17 dot org 2006-05-22 01:08 ---
IMHO, -frounding-math should be the default, unless -ffast-math is given.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21067
--- Comment #3 from vincent at vinc17 dot org 2006-04-11 15:16 ---
(In reply to comment #2)
which is incorrect since the input domain is not symmetric wrt 0.
I disagree. Could you give an explicit example?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27116
--- Comment #5 from vincent at vinc17 dot org 2006-04-11 15:46 ---
(In reply to comment #4)
I mean the middle-end probably does some interesting foldings of
-2147483647L
- 1L as the result -08000 has the overflow flag set.
The bug also occurs with: (long) -2147483648LL
--- Comment #6 from vincent at vinc17 dot org 2006-04-11 15:50 ---
BTW, concerning the overflow flag, I think it comes from the sign cancellation:
the long constant -2147483648 is replaced its opposite, but the opposite is not
representable in a long, hence the overflow.
--
http
--- Comment #5 from vincent at vinc17 dot org 2006-02-14 17:03 ---
(In reply to comment #4)
Note however, that the true accurate value for d, calculated at infinite
precision, is 1-(2^-16). So, the absolute error for gcj is 1+(2^-16) and the
absolute error with correct rounding is 1
--- Additional Comments From vincent at vinc17 dot org 2005-06-15 16:42
---
Even without fenv.h, the function could be in a library called in a directed
rounding mode.
And one can change the rounding mode via a standard function in the glibc, no
need for a pragma.
--
http
--
What|Removed |Added
CC||vincent at vinc17 dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21067
--- Additional Comments From vincent at vinc17 dot org 2005-06-15 16:49
---
I think that this is just bug 323 (which is a real bug, not invalid). Version
3.4 added other regressions related to this bug (e.g. when one has function
calls), and this is not specific to the negate operation
--- Additional Comments From vincent at vinc17 dot org 2005-06-15 17:08
---
Oops, forget my comment. There is a bug, but 5.1.2.3#13 / 6.3.1.5#2 / 6.3.1.8#2
is not related to it if gcc does reduce the precision (due to the volatile,
that in fact prevents bug 323 from occurring here
--- Additional Comments From vincent at vinc17 dot org 2004-12-08 15:13
---
I'm wrong. gcc 3.4 (from Debian) still has this problem. So, -ffloat-store is
still needed for C compliance.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14708
--- Additional Comments From vincent at vinc17 dot org 2004-11-29 15:35
---
In Comment 5, I wrote:
The real problem is that intermediate results in extended precision are not
converted back to double after a cast or an assignment; this is required by the
C standard, whether
95 matches
Mail list logo
