mary: double floating point suffix of 'd' and 'D' not accepted
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
Re
--- Comment #3 from tydeman at tybor dot com 2009-01-29 21:52 ---
The Decimal Floating-Point Technical Report (WG14/N1176 and later) added
the suffixes 'd' and 'D' to indicate (binary) double, and 'dd' and 'DD' to
indicate decimal double (_Deci
Summary: HUGE_VAL_D32, HUGE_VAL_D64, HUGE_VAL_D128 missing from
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ty: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tydeman at tybor dot com
GCC host triplet: 4.3.2
GCC target triplet: 4.3.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39032
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tydeman at tybor dot com
GCC host triplet: 4.3.2
GCC target triplet: 4.3.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39033
d at gcc dot gnu dot org
ReportedBy: tydeman at tybor dot com
GCC host triplet: 4.3.2
GCC target triplet: 4.3.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39034
ned at gcc dot gnu dot org
ReportedBy: tydeman at tybor dot com
GCC host triplet: 4.3.2
GCC target triplet: 4.3.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39035
ating-point exception flags done wrong
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tydeman at tybor dot com
GCC host triplet: 4.3.2
GCC target triplet: 4.3.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39036
: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tydeman at tybor dot com
GCC host triplet: 4.3.2
GCC target triplet: 4.3.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39037
--- Comment #1 from tydeman at tybor dot com 2009-01-30 17:31 ---
My analysis shows that
d10=0x2fe3=+3.e-15
So, d10 is not zero, while d2 is zero.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39034
--- Comment #2 from tydeman at tybor dot com 2009-01-30 17:34 ---
This is NOT a dup of 39034. In this one, the value of the expression is zero.
In 39034, the value of d10 is not zero (but should be).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39035
--- Comment #5 from tydeman at tybor dot com 2009-01-30 22:42 ---
I consider emulation of decimal FP to be part of the compiler's job. Part of
that emulation is setting the FP execption flags as per IEEE-754-2008.
There is one set of FP exception flags (used for both binary F
--- Comment #1 from tydeman at tybor dot com 2009-01-31 15:29 ---
Problem still exists in gcc 4.3.2-7
--
tydeman at tybor dot com changed:
What|Removed |Added
--- Comment #9 from tydeman at tybor dot com 2009-01-31 20:16 ---
4.3.2-7 still has problems (even with -frounding-math).
A more complete test can be found at:
http://www.tybor.com/tflt2int.c
--
tydeman at tybor dot com changed:
What|Removed
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tydeman at tybor dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40503
--- Comment #2 from tydeman at tybor dot com 2009-06-26 05:57 ---
Created an attachment (id=18073)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18073&action=view)
Find precision of *, /, +, -, ==
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40503
--- Comment #4 from tydeman at tybor dot com 2009-02-04 16:16 ---
/*
* _Bool bit-fields: C99: 6.7.2.1, paragraph 3 along with Defect Report 335.
* _Bool bit-fields of size up to CHAR_BIT must be supported.
*/
#include /* CHAR_BIT */
int main(void){
struct bits
--- Comment #6 from tydeman at tybor dot com 2009-02-04 17:15 ---
Opps. I missed that the bug report was against C++ (I still am learning
bugzilla). So, ignore my previous comments.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19618
--- Comment #5 from tydeman at tybor dot com 2009-02-12 02:54 ---
The latest version of TR 18037 is WG14 document N1275 of 2007/10/01.
The suffix really is case insensitive, so 'uhk' has 8 variations.
'll' and 'LL' are not valid suffixes for fixed
RMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tydeman at tybor dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39878
ts: Fail 2
--
Summary: x * 1.0DF gets wrong value
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tyde
: unassigned at gcc dot gnu.org
Reporter: tydeman at tybor dot com
Target Milestone: ---
/*
* These should all print the same thing: 2e+35
*/
#include
#define FMT "%.14g"
#define FMTL "%.14Lg"
int main(void){
const long double ld = 2e+35L;
const double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94654
--- Comment #2 from Fred J. Tydeman ---
If float is really promoted to double in this case, then why is the output
different? Seems to me that a float promoted to a double (case 2) should
produce
the same output as just a double (case a). Seems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94654
Fred J. Tydeman changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: tydeman at tybor dot com
Target Milestone: ---
The following code prints failures for 35 and 36 digit numbers.
/*
* Decimal floating-point constants suffer double rounding => get wrong va
Assignee: unassigned at gcc dot gnu.org
Reporter: tydeman at tybor dot com
Target Milestone: ---
Based on the output of "gcc $CFLAGS -E -dM hello.c", I see that most of the
_Decimal32/64/128 related values are defined for ARM -std=gnu2x
-mcpu=cortex-a72 when I use gcc 9.3.0
Assignee: unassigned at gcc dot gnu.org
Reporter: tydeman at tybor dot com
Target Milestone: ---
This valid code will not compile.
int main(void){
register const double d[3] = { 0., 1., 2. };
return 0;
}
--- Comment #3 from tydeman at tybor dot com 2009-10-20 06:25 ---
In 4.4.1, it appears that the type of the LHS in LHS = RHS determines how the
RHS
is evaluated. If the RHS involves only _Decimal32 types, then the RHS will be
evaluated to the type of the LHS (_Decimal32, 64, or 128
eturn 0;
}
--
Summary: Translation time Floating Point precision is too small
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tydeman at tybor dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41867
--- Comment #2 from tydeman at tybor dot com 2009-10-29 19:27 ---
Compile options: -std=gnu99 -pedantic -H -fno-builtin -frounding-math
Since I take the gcc that comes with Fedora Core Linux 9 and 10, I have
no idea how GCC was configured.
The output shows that all the file scope
--- Comment #4 from tydeman at tybor dot com 2009-10-31 17:42 ---
The requirement that translation time precision be at least as great as runtime
precision existed in C89, C90, C95, and C99 (so has been around for 20 years).
My code is a test of translation time precision versus
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53216
Bug #: 53216
Summary: fmaf() alters rounding mode of sse2 FPU
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53319
Bug #: 53319
Summary: exact subtract of two decimal floating-point values
raises FE_INEXACT
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53319
--- Comment #2 from Fred J. Tydeman 2012-05-11
05:31:01 UTC ---
Intel Core i5, 64-bit mode, Fedora Core Linux 17 and I believe
Intel Core 2 Due, 32-bit mode, Fedora Core Linux 17.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53319
--- Comment #5 from Fred J. Tydeman 2012-05-12
15:37:54 UTC ---
Another failure:
_Decimal32 val, lo;
val = 0.e-40DF;
lo = 9.e-1DF;
val += lo; /* raises FE_INEXACT */
This is with gcc 4.5.1 on Linux Fedora Core 14 on Intel Core 2 in 32-bit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53332
Bug #: 53332
Summary: #pragma STDC FLOAT_CONST_DECIMAL64 ONdone wrong
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52930
Bug #: 52930
Summary: quadmath: missing logbq, modfq, nexttowardq, exp2q
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: tydeman at tybor dot com
Target Milestone: ---
static int * f1(void){return NULL;}
int main(void){
int i = _Generic(f1, int * _Atomic (*)(void): 1, default: 0);
return i;
}
The above _Generic() should match, but does
Assignee: unassigned at gcc dot gnu.org
Reporter: tydeman at tybor dot com
Target Milestone: ---
tgammal() of negative odd non-integers, e.g., -33.5, -37.5, -67.5, -69.5, ...
has the wrong sign. It should be positive.
Assignee: unassigned at gcc dot gnu.org
Reporter: tydeman at tybor dot com
Target Milestone: ---
On an Intel 64-bit CPU (Core i5 7th gen), running Linux, gcc using
-mlong-double-64 gets strange results for long doubles in (at least) isnan()
and scanf().
For example, scanf() using "%L
Assignee: unassigned at gcc dot gnu.org
Reporter: tydeman at tybor dot com
Target Milestone: ---
Around 2012/09/23 with WG14 N1632, DEC32_SUBNORMAL_MIN became DEC32_TRUE_MIN in
. The same is true for the 64 and 128 bit versions.
Assignee: unassigned at gcc dot gnu.org
Reporter: tydeman at tybor dot com
Target Milestone: ---
This code, which I believe is valid C11 code, will not compile.
struct a {
int y;
}; /* anonymous */
struct b {
int x;
struct a;
int z;
};
static struct b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90296
Fred J. Tydeman changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Assignee: unassigned at gcc dot gnu.org
Reporter: tydeman at tybor dot com
Target Milestone: ---
This code gets "caught" at runtime, but I believe that the code is valid.
This is on Intel i5, 32-bit Fedora 29, gcc 8.2.1.
command line flags are: "-fsanitize=undefined -fs
Assignee: unassigned at gcc dot gnu.org
Reporter: tydeman at tybor dot com
Target Milestone: ---
/*
* Type generic wrong for faddl()
* 64-bit Fedora Linux 29 on Intel i5
* gcc 8.2.1-5
*/
/* Tell implementation that we want FP extensions */
#define __STDC_WANT_IEC_60559_BFP_EXT__ 1
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: tydeman at tybor dot com
Target Milestone: ---
/*
* 3 different answers from 4 "same" expressions for Intel x87 (not sse2).
* 5580 5556 5581 5581
* CFLAGS=&quo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40503
--- Comment #6 from Fred J. Tydeman ---
No. All evaluations should be as if 34 digits of precision.
Assignee: unassigned at gcc dot gnu.org
Reporter: tydeman at tybor dot com
Target Milestone: ---
/*
* C standard appears to be unclear on scope of new type defined in
* offsetof() macro. Some compilers accept; some reject.
* This is related to C Defect Report 496
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82909
--- Comment #2 from Fred J. Tydeman ---
I agree with your analysis. The behavior is C standard version dependent with
respect to the 'if' statement. There is no bug in gcc.
: Get compiler internal error with DFP expression
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tydeman at tybor dot com
--- Comment #2 from tydeman at tybor dot com 2010-03-23 12:08 ---
Host and target info:
CPU: Intel Pentium 4
OS: Linux
Fedora Core 10 with gcc 4.3.2
Fedora Core 11 with gcc 4.4.1
Fedora Core 12 with gcc 4.4.3
Command line options: CFLAGS="-std=gnu99 -pedantic -H -fno-bu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30580
Fred J. Tydeman changed:
What|Removed |Added
CC||tydeman at tybor dot com
--- Comment
52 matches
Mail list logo
