[Bug c/96253] New: decimal floating point missing on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96253 Bug ID: 96253 Summary: decimal floating point missing on ARM Product: gcc Version: 9.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c 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 on an ARM based computer. Yet, when I try to use _Decimal32/64/128 as a floating-point type, I get the error: decimal floating point not supported for this target. Assuming decimal floating point is supported for some version of ARM, what command line options (or other things) do I need to get it? It would be nice if the online gcc documentation said which targets do support decimal floating point.
[Bug c/95300] New: Decimal floating-point constants suffer double rounding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95300
Bug ID: 95300
Summary: Decimal floating-point constants suffer double
rounding
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
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 value.
* It appears that first the constant is convert to 34 digit _Decimal128 (1st
rounding)
* and then converted to _Decimal32 (2nd rounding).
*/
#define __STDC_WANT_IEC_60559_DFP_EXT__ 1 /* Tell implementation that we want
Decimal FP */
#define __STDC_WANT_DEC_FP__/* Tell implementation that we want Decimal FP
*/
#include
int main(void){
_Decimal32 d7, d33, d34, d35, d36;
d7 = 1234567.DF;
d33 = 1234567.49DF;
d34 = 1234567.499DF;
/*1234567 89-123456789-123456789-123456789 */
d35 = 1234567.4999DF;
d36 = 1234567.4DF;
if( d7 != d33 ) (void)printf("d33 bad\n");
if( d7 != d34 ) (void)printf("d34 bad\n");
if( d7 != d35 ) (void)printf("d35 bad\n");
if( d7 != d36 ) (void)printf("d36 bad\n");
return 0;
}
[Bug c/94654] printf calls with floats
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94654 Fred J. Tydeman changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Fred J. Tydeman --- Never mind. I misread the output. It is a user error.
[Bug c/94654] printf calls with floats
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 to me that the bug is in the call, not in printf().
[Bug c/94654] New: printf calls with floats
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94654
Bug ID: 94654
Summary: printf calls with floats
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: 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 d = 2e+35;
const floatf = 2e+35F;
(void)printf("1:" FMT "\n", f );
(void)printf("2:" FMT "\n", (double)f );
(void)printf("3:" FMT "\n", 2e+35F );
(void)printf("4:" FMT "\n", (double)2e+35F );
(void)printf("5:" FMT "\n", (float)d );
(void)printf("6:" FMT "\n", (float)ld );
(void)printf("a:" FMT "\n", d );
(void)printf("b:" FMT "\n", 2e+35 );
(void)printf("c:" FMTL "\n", ld );
(void)printf("d:" FMTL "\n", 2e+35L );
return 0;
}
The first 6 print as if %f (which is wrong).
The last 4 print as if %e
varargs are supposed to promote float to double.
[Bug c/93949] New: Register const local var will not compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93949
Bug ID: 93949
Summary: Register const local var will not compile
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
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;
}
[Bug c/92083] New: -mlong-double-64 strange results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92083 Bug ID: 92083 Summary: -mlong-double-64 strange results Product: gcc Version: 9.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c 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 "%Lg" to read into a long double, stores 10 bytes (80-bit x87 format) instead of the expected 8 bytes (64-bit double format). isnan() of a long double that is a NaN returns false. Similar issues may also exists for functions, printf(), , and . Is there documentation on exactly what -mlong-double-64/80/128 are supposed to do? Are they supposed to link in different libraries?
[Bug libquadmath/91924] New: tgammal(- odd.5 ) has wrong sign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91924 Bug ID: 91924 Summary: tgammal(- odd.5 ) has wrong sign Product: gcc Version: 7.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libquadmath 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.
[Bug c/90296] C11 anonymous struct not liked
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90296
Fred J. Tydeman changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #1 from Fred J. Tydeman ---
User misunderstood C standard. struct b should be:
struct b {
int x;
struct { /* anonymous */
int y;
};
int z;
};
[Bug c/90296] New: C11 anonymous struct not liked
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90296
Bug ID: 90296
Summary: C11 anonymous struct not liked
Product: gcc
Version: 8.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
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 c = { 20, 30, 50 };
static struct b d = { .z=5, .x=2, .y=3 };
[Bug c/89276] New: DEC32_TRUE_MIN missing from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89276 Bug ID: 89276 Summary: DEC32_TRUE_MIN missing from Product: gcc Version: 8.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c 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.
[Bug c/88062] New: tgmath with fadd vs faddl done wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88062
Bug ID: 88062
Summary: tgmath with fadd vs faddl done wrong
Product: gcc
Version: 8.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
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
#include
#include
#include
#include
int main(void){
float specific, generic;
specific = (faddl)(INFINITY,-LDBL_MAX); /* inf */
generic = fadd( INFINITY,-LDBL_MAX); /* nan */
(void)printf("specific=%f, generic=%f\n", specific, generic);
return 0;
}
[Bug c/88054] New: Sanitizer triggers on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88054
Bug ID: 88054
Summary: Sanitizer triggers on valid code
Product: gcc
Version: 8.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
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 -fsanitize=address
-fsanitize=bounds-strict -fstack-protector-all -H -std=gnu17 -O0 -march=native
-mfpmath=387 -mieee-fp -fno-builtin -frounding-math -ffloat-store
-fexcess-precision=standard -fsignaling-nans"
#include
#include /* wchar_t, wcsto*(), swprintf(), swscanf() */
#include
static FILE *file = NULL; /* points to FILE returned by open() */
static char *filename = NULL; /* points to name of temp file */
typedef struct {
float str_fpval; /* FP value returned by wcsto*, and maybe
*wscanf */
ptrdiff_t str_numread;/* number of characters accepted by wcsto* */
int wscan_cnt;/* # of chars processed by %f */
int wscan_rc; /* return code from wscanf */
const wchar_t from[20]; /* string to process by *wscanf and wcsto* */
const wchar_t wscan_str[20-8];/* string return by wscanf's %ls; this
or next time */
} data;
static data tv[] = {
/* 0*/{ 100.f, (ptrdiff_t)3, 3, 1, L"100", L"" }
};
int main(void){
int rc;
int i = 0;
{ (void)printf("DEBUG 1\n"); fflush(NULL); }
filename = tmpnam(NULL); /* create a temporary file */
{ (void)printf("DEBUG 2\n"); fflush(NULL); }
(void)printf("temp file name=%s\n", filename);
{ (void)printf("DEBUG 3\n"); fflush(NULL); }
file = fopen(filename,"wb"); /* make sure we can open the file */
{ (void)printf("DEBUG 4\n"); fflush(NULL); }
file = freopen(NULL, "wb", file); /* so can write */
{ (void)printf("DEBUG 5\n"); fflush(NULL); }
{ (void)printf("str=%ls\n", tv[i].from); fflush(NULL); }
{ (void)printf("DEBUG 6\n"); fflush(NULL); }
{ (void)printf("file=%p\n", file); fflush(NULL); }
{ (void)printf("DEBUG 7\n"); fflush(NULL); }
rc = fwprintf( file, L"%ls", tv[i].from ); /* string to process */
{ (void)printf("DEBUG 8\n"); fflush(NULL); }
return 0;
}
[Bug c/86221] New: _Generic not match function return that has _Atomic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86221
Bug ID: 86221
Summary: _Generic not match function return that has _Atomic
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
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 not.
If _Atomic is replaced with any of: const, volatile, restrict,
then it works as expected.
[Bug c/82909] Scope of type defined by offsetof() macro
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.
[Bug c/82909] New: Scope of type defined by offsetof() macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82909
Bug ID: 82909
Summary: Scope of type defined by offsetof() macro
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
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.
*/
#include /* offsetof() */
int main(void){
if( 0 == (int)offsetof( struct s4 {int i4;}, i4 ) ){
struct s4 s43; /* OK here */
}
{
struct s4 s44; /* Should(?) be OK here */
}
return 0;
}
[Bug target/40503] DEC_EVAL_METHOD not match operators
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.
[Bug c/82775] New: int += float different from int = int + float on Intel x87
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82775
Bug ID: 82775
Summary: int += float different from int = int + float on Intel
x87
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
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="-H -std=gnu11 -O0 -march=native -mfpmath=387 -mieee-fp -fno-builtin
-frounding-math -ffloat-store -fexcess-precision=standard -fsignaling-nans"
*/
#include
int main(void){
int i1 = 0x;
int i2 = 0x;
int i3 = 0x;
int i4 = 0x;
float one = 1.f;
i1 += one;
i2 += 1.f;
i3 = i3 + one;
i4 = i4 + 1.f;
(void)printf("%x %x %x %x\n", i1, i2, i3, i4);
return 0;
}
[Bug other/53319] exact subtract of two decimal floating-point values raises FE_INEXACT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53319 --- Comment #5 from Fred J. Tydeman tydeman at tybor dot com 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 mode. Command line options: -std=gnu99 -O0 -pedantic -H -fno-builtin -frounding-math -mieee-fp -ffloat-store -fexcess-precision=standard
[Bug c/53332] New: #pragma STDC FLOAT_CONST_DECIMAL64 ON done wrong
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
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: tyde...@tybor.com
The following code shows problems with floating-point constants and implied
decimal suffix. x10 ends up as a NaN and x2 ends up as zero (both wrong).
#define __STDC_WANT_DEC_FP__/* Tell implementation that we want Decimal FP
*/
#pragma STDC FLOAT_CONST_DECIMAL64 ON
#include stdio.h
int main(void){
double d2 = (_Decimal64)((28.DD/3.DD-9.DD) - (31.DD/3.DD-10.DD));/*
decimal FP */
_Decimal64 d10 = (_Decimal64)((28.DD/3.DD-9.DD) - (31.DD/3.DD-10.DD));
double b2 = (_Decimal64)((28.D /3.D -9.D ) - (31.D /3.D -10.D ));/*
binary FP */
_Decimal64 b10 = (_Decimal64)((28.D /3.D -9.D ) - (31.D /3.D -10.D ));
double x2 = (_Decimal64)((28./3.-9.) - (31./3.-10.));/* should be
decimal FP */
_Decimal64 x10 = (_Decimal64)((28./3.-9.) - (31./3.-10.));
if( d2 != x2 ){
(void) printf( d2 is %g, b2 is %g, x2 is %g\n, (double)d2, (double)b2,
(double)x2 );
}
if( d10 != x10 ){
(void) printf(d10 is %g, b10 is %g, x10 is %g\n, (double)d10,
(double)b10, (double)x10 );
}
return 0;
}
This is on Intel CPUs in both 32-bit and 64-bit mode.
This is with Fedora Core Linux 14 thru 17.
This is with gcc 4.5.1 thru 4.7.0
[Bug c/53319] New: exact subtract of two decimal floating-point values raises FE_INEXACT
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: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: tyde...@tybor.com Code similar to _Decimal64 res1, val = 0.DD /* 16 9s */ res1 = val; res1 = res1 - val; /* exactly zero */ raises FE_INEXACT when in fact the result is an exact zero.
[Bug c/53319] exact subtract of two decimal floating-point values raises FE_INEXACT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53319 --- Comment #2 from Fred J. Tydeman tydeman at tybor dot com 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.
[Bug c/53216] New: fmaf() alters rounding mode of sse2 FPU
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: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: tyde...@tybor.com
The following code shows that the rounding mode of the sse2 FPU is altered by a
call to fmaf().
#include stdio.h
#include float.h
#include math.h
static float res0, res1, res2, res3;
static float half = 0.5f;
void chk( void ){
res2 = res0 + half;/* should round down to even */
if( res2 == res0 ){ puts(OK1); }else{ puts(Bad1); }
res3 = res1 + half;/* should round up to even */
if( res3 != res1 ){ puts(OK2); }else{ puts(Bad2); }
}
int main(void){
res0 = FLT_EPSILON;
res0++;
res0--;
res0 = 1.f / res0;/* even; 1/EPSILON is a magic number */
res1 = res0 + 1.f;/* odd */
chk();
res2 = sinf( 1.f );/* sse2 rounding is not altered */
chk();
res2 = fmaf( 1.f, 1.f, 1.f );/* this messes up sse2 rounding */
chk();
return 0;
}
Hardware: Intel Core 2 Duo in 32-bit mode
O.S.: Fedora Core 17 in 32-bit mode
Compiler: gcc 4.7.0-2
Library : glibc 2.15-32
Compiler options: -std=gnu11 -O0 -mfpmath=sse -msse2 -fno-builtin
-frounding-math -mieee-fp -ffloat-store -fexcess-precision=standard
[Bug other/52930] New: quadmath: missing logbq, modfq, nexttowardq, exp2q
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 Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: tyde...@tybor.com Either the header quadmath.h is missing the prototypes, and/or the library -lquadmath is missing the functions listed in the summary. These problems were found in a C99 program using 4.6.3-2 of float128 in Linux Fedora Core 16 on an Intel Core 2 CPU. Also, FLT128_DENORM_MIN should be renamed to FLT128_TRUE_MIN to match C11. Also, #define FLT128_DECIMAL_DIG 36 should be added to match C11. Also, #define FLT128_HAS_SUBNORM 1 should be added to match C11. It would be nice if tgmath.h supported all four floating-point types; float, double, long double, __float128. It would be nice if isnan(), isinf(), ... supported all four floating-point types. It appears that the 113/128 quad is converted to 64/80 long double when any of the quad functions are called. For example, fabsq(1.0Q - FLT128_EPSILON) returns 1.0Q
[Bug c/30580] GCC doesn't set floating-point exceptions when performing fp-int conversions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30580 Fred J. Tydeman tydeman at tybor dot com changed: What|Removed |Added CC||tydeman at tybor dot com --- Comment #6 from Fred J. Tydeman tydeman at tybor dot com 2010-10-05 18:28:05 UTC --- I believe that this is a dup of bug 27682. It still is failing in 4.5.1 on Intel Pentium 4 under Linux.
[Bug c/43488] Get compiler internal error with DFP expression
--- 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-builtin
-frounding-math -DTAILOR ${INCS}
Failure:
test65.c:4: internal compiler error: in decimal_to_decnumber, at dfp.c:114
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43488
[Bug c/43488] New: Get compiler internal error with DFP expression
Programs similar to the following get compiler internal error in dfp
#define __STDC_WANT_DEC_FP__/* Tell implementation that we want DFP */
#define MAX_D10 9.999E384DD
int main(void){
if( MAX_D10 + MAX_D10 ){
return 1;
}else{
return 0;
}
}
--
Summary: 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43488
[Bug c/41867] Translation time Floating Point precision is too small
--- 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 runtime precision. The first code I saw in bug 323 involved 3 auto variables (so is just runtime). That is a different issue, so I believe that this bug is not a duplicate of 323. I used gnu99 instead of c99 for the std because I also am testing Decimal FP in addition to Binary FP. Where should I find documentation on compiler options to get as close to C99 conformance as possible? Also, C99 + Decimal FP conformance? The output you show is what I expected. -- tydeman at tybor dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41867
[Bug c/41867] New: Translation time Floating Point precision is too small
The following code fails on (at least) Intel x86/x87 systems running Linux:
/*
* From C99:
* 6.6 Constant expressions
*
* #5 An expression that evaluates to a constant is required in several
* contexts. If a floating expression is evaluated in the translation
* environment, the arithmetic precision and range shall be at least
* as great as if the expression were being evaluated in the execution
* environment.
*/
#include float.h /* *_EPSILON */
#include stdio.h /* printf() */
/*
* Compute epsilon == Unit Last Place; may be + or - depends upon rounding.
*/
#define Q2 (((4.F /3.F - 1.F ) - 1.F /4.F )*3.F - 1.F /4.F )
/*
* File scope is translation time
*/
static long double fs_ld2 = Q2;
static double fs_d2 = Q2;
static float fs_f2 = Q2;
int main(void){
/*
* Local scope is runtime
*/
long double ls_ld2 = Q2;
double ls_d2 = Q2;
float ls_f2 = Q2;
if( fs_ld2 != ls_ld2 ){
(void)printf( 1: BFP: translation time != runtime\n);
}
if( fs_d2 != ls_d2 ){
(void)printf( 2: BFP: translation time != runtime\n);
}
if( fs_f2 != ls_f2 ){
(void)printf( 3: BFP: translation time != runtime\n);
}
if( fs_ld2 != fs_d2 ){
(void)printf( 7: BFP: translation time: variable precision\n);
}
if( fs_d2 != fs_f2 ){
(void)printf( 8: BFP: translation time: variable precision\n);
}
if( ls_ld2 != ls_d2 ){
(void)printf(11: BFP:runtime: variable precision\n);
}
if( ls_d2 != ls_f2 ){
(void)printf(12: BFP:runtime: variable precision\n);
}
(void)printf(ls_ld2=%Lg\n, ls_ld2);
(void)printf(ls_d2 =%g\n, ls_d2);
(void)printf(ls_f2 =%g\n, ls_f2);
(void)printf(LD_EPS=%Lg\n, LDBL_EPSILON);
(void)printf( D_EPS=%g\n, DBL_EPSILON);
(void)printf( F_EPS=%g\n, FLT_EPSILON);
(void)printf(fs_ld2=%Lg\n, fs_ld2);
(void)printf(fs_d2 =%g\n, fs_d2);
(void)printf(fs_f2 =%g\n, fs_f2);
return 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
[Bug c/41867] Translation time Floating Point precision is too small
--- 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 (translation time) precisions used were small (ULP is same magnitude as FLT_EPSILON), while all the local scope (runtime) precisions used were large (ULP same magnitude as LDBL_EPSILON). All six should be the same magnitude as LDBL_EPSILON for this hardware. None of the messages with 1:, 2:, 3:, 7:, 8:, 11:, or 12: should be printed if things are done as per the C standard. A large precision implies a small magnitude ULP value (closer to zero). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41867
[Bug target/40503] DEC_EVAL_METHOD not match operators
--- 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). That behavoiur is not what C99 wants. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40503
[Bug target/40503] DEC_EVAL_METHOD not match operators
--- 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=18073action=view) Find precision of *, /, +, -, == -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40503
[Bug c/40503] New: DEC_EVAL_METHOD not match operators
It appears that decimal floating-point (DFP) constants and the operators + and - are done to type (as if DEC_EVAL_METHOD were 0), but that the operators * and / are done as if _Decimal128 (as if DEC_EVAL_METHOD were 2) -- this is in gcc 4.4.0. In gcc 4.3.2, everything was done as if to type (DEC_EVAL_METHOD were 0). This in on Intel Pentium 4 with Fedora Core Linux 11. -- Summary: DEC_EVAL_METHOD not match operators Product: gcc Version: 4.4.0 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=40503
[Bug c/39902] New: x * 1.0DF gets wrong value
Multiplication by a decimal floating-point (DFP) value of one appears to be
optimized away, thereby producing the wrong value. In DFP, the value one has
many representations. Only one of them (1.DF) results in no change to values
for multiplication; the others change the quantum exponent.
/* DFP TR 24732 == WG14 / N1312 */
#define __STDC_WANT_DEC_FP__ /* Tell implementation that we want Decimal FP */
#include stdio.h /* printf() */
#include string.h /* memcmp() */
int main(void){
_Decimal32 f1 = 1.0DF;
_Decimal32 f2 = 2.0DF;
_Decimal32 f3;
f3 = f2 * f1; /* should change quantum exponent */
if( 0 == memcmp( f3, f2, sizeof(f3) ) ){
(void)printf(Fail 1\n);
}
f3 = f2 * 1.0DF; /* should change quantum exponent */
if( 0 == memcmp( f3, f2, sizeof(f3) ) ){
(void)printf(Fail 2\n);
}
return 0;
}
gets: 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: tydeman at tybor dot com
GCC build triplet: 4.3.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39902
[Bug c/39878] New: gcc 4.3.2 converts Decimal FP constants wrong
/* DFP TR 24732 == WG14 / N1312 */
#define __STDC_WANT_DEC_FP__ /* Tell implementation that we want Decimal FP */
#include stdio.h
int main(void){
/*
* If DEC_EVAL_METHOD is 0, then these triples are not the same.
* If DEC_EVAL_METHOD is 1 or 2, then these suffer double rounding
* and are the same.
*/
_Decimal32 f1 = 998.4999DF;
_Decimal32 f2 = 998.5DF;
_Decimal32 f3 = 998.5001DF;
_Decimal32 f4 = 999.4999DF;
_Decimal32 f5 = 999.5DF;
_Decimal32 f6 = 999.5001DF;
_Decimal128 ld1 = .DF;
if( .667DF == ld1 ){
(void)printf(DEC_EVAL_METHOD appears to be 0\n);
}else if( .6667DD == ld1 ){
(void)printf(DEC_EVAL_METHOD appears to be 1\n);
}else if( .67DL == ld1 ){
(void)printf(DEC_EVAL_METHOD appears to be 2\n);
}else{
(void)printf(DEC_EVAL_METHOD appears to be -1\n);
}
if( (f1==f2) (f2==f3) ){
(void)printf(Fail 1 if DEC_EVAL_METHOD is 0\n);
}
if( (f4==f5) (f5==f6) ){
(void)printf(Fail 2 if DEC_EVAL_METHOD is 0\n);
}
return 0;
}
--
Summary: gcc 4.3.2 converts Decimal FP constants 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39878
[Bug c/33466] mixed-case suffix for decimal float constants
--- 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 point constants. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33466
[Bug c++/19618] Does warn if bit-fields exceed the size of bool types
--- 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 limits.h /* CHAR_BIT */
int main(void){
struct bits {
int: 0;
_Bool : 0; /* force alignment */
_Bool bbf1 : 1; /* holds values 0 and 1 */
_Bool bbf8 : CHAR_BIT; /* must be supported */
} bits;
return 0;
}
The above code fails to compile in gcc 4.3.2-7
The error message is:
error: width of 'bbf8' exceeds its type
A _Bool is one storage unit, so is CHAR_BIT bits.
Therefore, _Bool bit-fields of size 0, 1, 2, ... CHAR_BIT
must be supported.
--
tydeman at tybor dot com changed:
What|Removed |Added
CC||tydeman at tybor dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19618
[Bug c++/19618] Does warn if bit-fields exceed the size of bool types
--- 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
[Bug c/33466] mixed-case suffix for decimal float constants
--- 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 CC||tydeman at tybor dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33466
[Bug target/27682] float to int conversion doesn't raise invalid exception
--- 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 |Added CC||tydeman at tybor dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27682
[Bug c/39034] Decimal floating-point math done wrong
--- 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
[Bug c/39035] if( 0.0DF ) is considered true
--- 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
[Bug c/39036] Decimal floating-point exception flags done wrong
--- 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 FP and decimal FP). Given that the fenv.h functions work correctly for binary FP exceptions (and they mostly do on Intel x86/x87), then they should work correctly for decimal FP exceptions. The full set of command line options I give gcc is: -std=gnu99 -pedantic -H -fno-builtin -frounding-math My understanding is -frounding-math is supposed to act like a global #pragma STDC FENV_ACCESS ON -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39036
[Bug c/39027] New: double floating point suffix of 'd' and 'D' not accepted
With C command line option -std=gnu99 double floating-point constants with either 'd' or 'D' suffix are not accepted by gcc 4.3.2-7 running on Intel x86/x87 Pentium 4 running Fedora Core 10 Linux Part of gcc -v is: gcc version 4.3.2 20081105 (Red Hat 4.3.2-7) (GCC) #define __STDC_WANT_DEC_FP__ /* Tell implementation that we want Decimal FP */ double d1 = 1.0d; /* binary double (yes) versus decimal double (no) */ double d2 = 2.0D; gets error: invalid suffix d on floating constant error: invalid suffix D on floating constant -- Summary: 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 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=39027
[Bug target/39027] double floating point suffix of 'd' and 'D' not accepted
--- 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 (_Decimal64). The suffixes 'd' and 'D' are in addition to unsuffixed decimal floating constants (all three mean 'double'). This is pages 12 and 13 in N1176, section 7 Constants, which is changing C99 section 6.4.4.2 floating-suffix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39027
[Bug c/39031] New: HUGE_VAL_D32, HUGE_VAL_D64, HUGE_VAL_D128 missing from math.h
The Decimal Floating Point (DFP) Technical Report (TR) added DFP versions of HUGE_VAL to math.h. They are missing in (at least) gcc 4.3.2-7. /* DFP TR 24732 == WG14 / N1176, N1312 */ #define __STDC_WANT_DEC_FP__/* Tell implementation that we want Decimal FP */ #include math.h /* HUGE_VAL_D* */ _Decimal32 d32 = HUGE_VAL_D32; _Decimal64 d64 = HUGE_VAL_D64; _Decimal128 d128 = HUGE_VAL_D128; gets: test1.c:5: warning: ISO C does not support decimal floating point test1.c:5: error: 'HUGE_VAL_D32' undeclared here (not in a function) test1.c:6: warning: ISO C does not support decimal floating point test1.c:6: error: 'HUGE_VAL_D64' undeclared here (not in a function) test1.c:7: warning: ISO C does not support decimal floating point test1.c:7: error: 'HUGE_VAL_D128' undeclared here (not in a function) Janis asked to be CCed on DFP bugs. -- Summary: HUGE_VAL_D32, HUGE_VAL_D64, HUGE_VAL_D128 missing from math.h 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=39031
[Bug c/39032] New: DEC_INFINITY missing from math.h
gcc 4.3.2-7 with command line option -std=gnu99 of /* DFP TR 24732 == WG14 / N1176, N1312 */ #define __STDC_WANT_DEC_FP__ /* Tell implementation that we want Decimal FP */ #include math.h /* DEC_INFINITY */ _Decimal32 d32 = DEC_INFINITY; gets: test2.c:5: warning: ISO C does not support decimal floating point test2.c:5: error: 'DEC_INFINITY' undeclared here (not in a function) janis asked to be CCed on DFP bugs -- Summary: DEC_INFINITY missing from math.h 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=39032
[Bug c/39033] New: DEC_EVAL_METHOD missing from float.h
Using gcc 4.3.2-7 on Intel Pentium running Linux Fedora Core 10
with -std=gnu99 of
/* DFP TR 24732 == WG14 / N1176, N1312 */
#define __STDC_WANT_DEC_FP__ /* Tell implementation that we want Decimal FP */
#include float.h /* DEC_EVAL_METHOD */
#ifndef DEC_EVAL_METHOD
#error Missing DEC_EVAL_METHOD
#endif
int main(void){
return 0;
}
gets:
. /usr/lib/gcc/i386-redhat-linux/4.3.2/include/float.h
test3.c:6:2: error: #error Missing DEC_EVAL_METHOD
--
Summary: DEC_EVAL_METHOD missing from float.h
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=39033
[Bug c/39034] New: Decimal floating-point math done wrong
Using gcc 4.3.2-7 on Intel Pentium 4 running Fedora Core 10 with -std=gnu99 of
/* DFP TR 24732 == WG14 / N1176, N1312 */
#define __STDC_WANT_DEC_FP__ /* Tell implementation that we want Decimal FP */
#include stdio.h /* printf() */
int main(void){
double d2 = (double)((28./3.-9.) - (31./3.-10.));
_Decimal64 d10 = (double)((28./3.-9.) - (31./3.-10.));
if( d2 ){
printf(d2 should be zero\n);
}
if( d10 ){
printf(d10 should be zero\n);
}
return 0;
}
gets:
d10 should be zero
This should be independent of Translation Time Data Type (TTDT)
which has been dropped from the DFP TR as of WG14 N1312.
--
Summary: Decimal floating-point math 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=39034
[Bug c/39035] New: if( 0.0DF ) is considered true
Using gcc 4.3.2-7 on Intel Pentium 4 running Fedora Core 10 and -std=gnu99 of
/* DFP TR 24732 == WG14 / N1176, N1312 */
#define __STDC_WANT_DEC_FP__ /* Tell implementation that we want Decimal FP */
#include stdio.h /* printf() */
int main(void){
if( 0.0DF ){
printf(0.0DF should be zero\n);
}
return 0;
}
gets:
0.0DF should be zero
--
Summary: if( 0.0DF ) is considered true
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=39035
[Bug c/39036] New: Decimal floating-point exception flags done wrong
Using gcc 4.3.2-7 on Intel Pentium 4 running Linux Fedora Core 10 and
-std=gnu99
/* DFP TR 24732 == WG14 / N1176, N1312 */
#define __STDC_WANT_DEC_FP__ /* Tell implementation that we want Decimal FP */
#pragma STDC FENV_ACCESS ON /* will be testing FP exception flags */
#include stdio.h /* printf() */
#include fenv.h /* fetestexcept(), FE_* */
#include float.h /* DEC*_MIN, DEC*_MAX */
int main(void){
_Decimal64 d10;
int before;
int after;
before = feclearexcept( FE_ALL_EXCEPT );
d10 = 1.0DD;
d10 /= 3.0DD;
after = fetestexcept( FE_ALL_EXCEPT );
if( FE_INEXACT after ){
printf(Inexact raised as expected\n);
}else{
printf(Inexact wrong; after=%i\n, after);
}
before = feclearexcept( FE_ALL_EXCEPT );
d10 = DEC64_MIN;
d10 *= d10;
after = fetestexcept( FE_ALL_EXCEPT );
if( FE_UNDERFLOW after ){
printf(Underflow raised as expected\n);
}else{
printf(Underflow wrong; after=%i\n, after);
}
before = feclearexcept( FE_ALL_EXCEPT );
d10 = DEC64_MAX;
d10 *= d10;
after = fetestexcept( FE_ALL_EXCEPT );
if( FE_OVERFLOW after ){
printf(Overflow raised as expected\n);
}else{
printf(Overflow wrong; after=%i\n, after);
}
before = feclearexcept( FE_ALL_EXCEPT );
d10 = DEC64_MIN;
d10 /= (d10-d10);
after = fetestexcept( FE_ALL_EXCEPT );
if( FE_DIVBYZERO after ){
printf(Divbyzero raised as expected\n);
}else{
printf(Divbyzero wrong; after=%i\n, after);
}
before = feclearexcept( FE_ALL_EXCEPT );
d10 = 0.0e-15DD;
d10 /= d10;
after = fetestexcept( FE_ALL_EXCEPT );
if( FE_INVALID after ){
printf(Invalid raised as expected\n);
}else{
printf(Invalid wrong; after=%i\n, after);
}
printf(%2i = FE_INEXACT\n, FE_INEXACT);
printf(%2i = FE_UNDERFLOW\n, FE_UNDERFLOW);
printf(%2i = FE_OVERFLOW\n, FE_OVERFLOW);
printf(%2i = FE_DIVBYZERO\n, FE_DIVBYZERO);
printf(%2i = FE_INVALID\n, FE_INVALID);
return 0;
}
gets:
Inexact wrong; after=0
Underflow wrong; after=0
Overflow wrong; after=32
Divbyzero wrong; after=0
Invalid wrong; after=0
32 = FE_INEXACT
16 = FE_UNDERFLOW
8 = FE_OVERFLOW
4 = FE_DIVBYZERO
1 = FE_INVALID
--
Summary: Decimal floating-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
[Bug c/39037] New: FLOAT_CONST_DECIMAL64 pragma not supported
Using gcc 4.3.2-7 on Intel Pentium 4 running Linux Fedora Core 10 with -std=gnu99 /* DFP TR 24732 == WG14 / N1312 */ #define __STDC_WANT_DEC_FP__ /* Tell implementation that we want Decimal FP */ #pragma STDC FLOAT_CONST_DECIMAL64 ON /* unsuffixed = Decimal (not Binary) */ _Decimal64 d10 = 1.0DD / 3.0 ; /* 3.0 should be treated as 3.0DD */ gets: test7.c:5: warning: ISO C does not support decimal floating point test7.c:5:18: warning: decimal float constants are a GCC extension test7.c:5: error: can't mix operands of decimal float and other float types NOTE: This pragma is new with WG14 N1312 version of Decimal Floating Point Technical Report (it replaced Translation Time Data Type (TTDT)). -- Summary: FLOAT_CONST_DECIMAL64 pragma not supported 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=39037
