Bug 20785 - Pragma STDC * (C99 FP) unimplemented
Summary: Pragma STDC * (C99 FP) unimplemented
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: c (show other bugs)
Version: 4.1.0
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
: 39036 (view as bug list)
Depends on:
Blocks: 16989 29186
  Show dependency treegraph
 
Reported: 2005-04-06 09:06 UTC by Aaron W. LaFramboise
Modified: 2021-11-13 14:31 UTC (History)
9 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2005-12-18 01:44:52


Attachments
Stephen Moshier's patch from 2001. (4.44 KB, text/plain)
2005-04-06 11:22 UTC, Joseph S. Myers
Details
Stephen Moshier's testcases from 2001. (2.00 KB, application/octet-stream)
2005-04-06 11:23 UTC, Joseph S. Myers
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Aaron W. LaFramboise 2005-04-06 09:06:47 UTC
#pragma STDC CX_LIMITED_RANGE off

is currently unimplemented, and generates the warning:

warning: ignoring #pragma STDC CX_LIMITED_RANGE
Comment 1 Joseph S. Myers 2005-04-06 11:21:41 UTC
We know.  I'm not sure how much use there is opening PRs for major points listed
as Missing at <http://gcc.gnu.org/c99status.html> unless there are particular
subtle points which might be missed in implementation which would be better
noted in a PR.

Stephen Moshier started a C99 pragma implementation some time ago.  I have his
code (version of June 2001, not a complete implementation, only does anything
with FENV_ACCESS) and at least the testcases might be useful; I'll attach the
files to this bug as we may as well use the bug now it's open.
Comment 2 Joseph S. Myers 2005-04-06 11:22:49 UTC
Created attachment 8543 [details]
Stephen Moshier's patch from 2001.
Comment 3 Joseph S. Myers 2005-04-06 11:23:58 UTC
Created attachment 8544 [details]
Stephen Moshier's testcases from 2001.
Comment 4 Aaron W. LaFramboise 2005-04-06 12:13:10 UTC
I opened the PR so I would have a tangible place to point to in a FIXME in some
code, saying "when this bug is fixed, uncomment this."  Perhaps though, for
things of this sort, it would be better to point to the status page.  However,
one can add oneself to the CC list for a bug much easier than he can add himself
to the "CC list" for a webpage.
Comment 5 Andrew Pinski 2006-09-22 19:27:59 UTC
*** Bug 29186 has been marked as a duplicate of this bug. ***
Comment 6 Richard Biener 2009-01-30 07:19:40 UTC
*** Bug 39036 has been marked as a duplicate of this bug. ***
Comment 7 Vincent Lefèvre 2015-11-23 12:39:42 UTC
For the STDC FENV_ACCESS pragma specifically, there is PR34678.

For the STDC FP_CONTRACT pragma, there is PR37845, which was fixed by r204460, though things could be improved in the future as the pragma is actually ignored: it's just that the default is now OFF in standard modes to be C99/C11 conforming. In the non-standard modes, one now misses the warning: PR68499.
Comment 8 Vincent Lefèvre 2020-02-21 10:18:13 UTC
Concerning the STDC FP_CONTRACT pragma, implementing it would not be sufficient. GCC would also need to restrict how it does contraction, as it currently does not contract only expressions, but also sequences of expressions, which is invalid. Example:

double foo (double a, double b, double c)
{
  double p = a * b;
  return p + c;
}

Since a * b and p + c are separate expressions, contraction to FMA must not be done according to the C standard. But when contraction is allowed, GCC generates a FMA on my x86_64 processor:

        .cfi_startproc
        vfmadd132sd     %xmm1, %xmm2, %xmm0
        ret
        .cfi_endproc
Comment 9 Richard Biener 2020-02-21 10:43:05 UTC
Note fixin(In reply to Vincent Lefèvre from comment #8)
> Concerning the STDC FP_CONTRACT pragma, implementing it would not be
> sufficient. GCC would also need to restrict how it does contraction, as it
> currently does not contract only expressions, but also sequences of
> expressions, which is invalid. Example:
> 
> double foo (double a, double b, double c)
> {
>   double p = a * b;
>   return p + c;
> }
> 
> Since a * b and p + c are separate expressions, contraction to FMA must not
> be done according to the C standard. But when contraction is allowed, GCC
> generates a FMA on my x86_64 processor:
> 
>         .cfi_startproc
>         vfmadd132sd     %xmm1, %xmm2, %xmm0
>         ret
>         .cfi_endproc

Note fixing that is as easy as wrapping FP expressions in PAREN_EXPR to
denote which ones are separate.  PAREN_EXPRs also serve as association
barriers and the FE needs to decide what FP optimization flag elides
them where exactly (the middle-end leaves them in place even with
-ffast-math).
Comment 10 joseph@codesourcery.com 2020-02-21 17:07:35 UTC
On Fri, 21 Feb 2020, vincent-gcc at vinc17 dot net wrote:

> Concerning the STDC FP_CONTRACT pragma, implementing it would not be
> sufficient. GCC would also need to restrict how it does contraction, as it
> currently does not contract only expressions, but also sequences of
> expressions, which is invalid. Example:

Note that -ffp-contract=on is currently equivalent to -ffp-contract=off 
for this reason.  It's only -ffp-contract=fast that contracts outside 
expressions (and C standards conformance modes disable contraction).
Comment 11 Andrew Pinski 2021-09-15 21:30:01 UTC
I have idea on how to fix the FENV_ACCESS issue (for gimple), basically you add an extra virtual use op for float gimples and virtual define for functions and inline-asm. Now I am not going to implement this but I want to record it somewhere.
Comment 12 Pavel M 2021-11-03 10:47:47 UTC
As far as I understand, support of #pragma STDC xxx is required by the C standard for hosted implementation. If so, then it is worth reaching conformance to increase the priority of this issue. It is logical for the end users to expect the support of  #pragma STDC xxx. Now they see:
t888.c:3: warning: ignoring ‘#pragma STDC FP_CONTRACT’ [-Wunknown-pragmas]
t888.c:4: warning: ignoring ‘#pragma STDC FENV_ACCESS’ [-Wunknown-pragmas]
t888.c:5: warning: ignoring ‘#pragma STDC CX_LIMITED_RANGE’ [-Wunknown-pragmas]
Invoked with: gcc t888.c -c -std=c11 -Wall.
Comment 13 Vincent Lefèvre 2021-11-03 12:43:45 UTC
If the default state of these pragmas (at least with options like -std=c11) is respectively "off", "on", "off", then changing the pragma state can safely be ignored by the implementation, as implementations are not obliged to optimize as allowed by the new pragma state. Thus, in such a case, the warnings are useless.
Comment 14 Pavel M 2021-11-08 11:20:54 UTC
To: Vincent Lefèvre
Re: the warnings are useless.

The "warning: ignoring '#pragma STDC FENV_ACCESS' [-Wunknown-pragmas]" probably needs to be generated by default (i.e. not with -Wall) because now gcc silently miscompiles the following (though unusual) code:
/* t0.c */
#include <stdio.h>
#include <fenv.h>
#include <float.h>

#pragma STDC FENV_ACCESS ON

int main( void )
{
    volatile double d1 = DBL_MAX;
    volatile double d2 = DBL_MAX;

#ifdef __STDC__
    printf("__STDC__         %d\n", __STDC__);
#endif
#ifdef __STDC_VERSION__
    printf("__STDC_VERSION__ %ld\n", __STDC_VERSION__);
#endif
#ifdef __STDC_IEC_559__
    printf("__STDC_IEC_559__ %d\n", __STDC_IEC_559__);
#endif

    if (feclearexcept( FE_ALL_EXCEPT ) != 0)
    {
        printf("error: feclearexcept( FE_ALL_EXCEPT ) failed\n");
        return 1;
    }
    ( void )( d1 * d2 );
    if (fetestexcept( FE_OVERFLOW ) == 0)
    {
        printf("error: no FE_OVERFLOW is raised\n");
        return 2;
    }
    return 0;  ​
}

Invocation: gcc t0.c -std=c11 -pedantic -lm
<nothing>

Execution: ./a.out

Expected output:
__STDC__         1
__STDC_VERSION__ 201710
__STDC_IEC_559__ 1

Actual output:
__STDC__         1
__STDC_VERSION__ 201710
__STDC_IEC_559__ 1
error: no FE_OVERFLOW is raised
Comment 15 Vincent Lefèvre 2021-11-08 12:30:04 UTC
(In reply to Pavel M from comment #14)
> The "warning: ignoring '#pragma STDC FENV_ACCESS' [-Wunknown-pragmas]"
> probably needs to be generated by default

Getting the warning on "#pragma STDC FENV_ACCESS OFF" is useless. The issue comes from the fact that the FENV_ACCESS is OFF by default and you want to set it to ON; there should be a warning in this case, but only in this case. Concerning the other pragmas, this also depends on their default state.

For instance, since commit 6dbe09581a1349498f6b4546f68cb9fd3205e120[*], the STDC FP_CONTRACT pragma is set to OFF by default when a standard mode is provided (e.g. -std=c17), so that the warning on this pragma is not needed in this case (whether the user sets it to ON or OFF).

[*] https://gcc.gnu.org/git/?p=gcc.git&a=commit;h=6dbe09581a1349498f6b4546f68cb9fd3205e120
Comment 16 Pavel M 2021-11-12 22:02:19 UTC
Note: The #pragma STDC FENV_ACCESS is unknown and ignored (leading to FP issues), however, the __STDC_IEC_559__ is defined to 1. Confused.
Comment 17 Vincent Lefèvre 2021-11-13 00:39:23 UTC
(In reply to Pavel M from comment #16)
> Note: The #pragma STDC FENV_ACCESS is unknown and ignored (leading to FP
> issues), however, the __STDC_IEC_559__ is defined to 1. Confused.

Yes, and IMHO, with __STDC_IEC_559__ defined to 1, this is a much more severe issue. This PR should not be regarded as an enhancement, but as a real bug (this would be an enhancement only if when __STDC_IEC_559__ is defined to 1, there would be a lack of optimization).
Comment 18 Eric Gallager 2021-11-13 14:31:04 UTC
(In reply to Vincent Lefèvre from comment #17)
> (In reply to Pavel M from comment #16)
> > Note: The #pragma STDC FENV_ACCESS is unknown and ignored (leading to FP
> > issues), however, the __STDC_IEC_559__ is defined to 1. Confused.
> 
> Yes, and IMHO, with __STDC_IEC_559__ defined to 1, this is a much more
> severe issue. This PR should not be regarded as an enhancement, but as a
> real bug

OK, I put the importance back to "normal"