public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/29697]  New: gfortran should use TYPE_QUAL_CONST etc.
@ 2006-11-03 16:54 burnus at gcc dot gnu dot org
  2006-11-03 17:03 ` [Bug fortran/29697] " burnus at gcc dot gnu dot org
                   ` (6 more replies)
  0 siblings, 7 replies; 10+ messages in thread
From: burnus at gcc dot gnu dot org @ 2006-11-03 16:54 UTC (permalink / raw)
  To: gcc-bugs

I came accross this when implementing the volatile statement/attribute
(PR29601), where I used:
> + if (sym->attr.volatile_)
> +   TREE_THIS_VOLATILE (decl) = 1;

Ian Lance Taylor noted that:
"I think you will also want to give DECL a type which is
volatile-qualified:
    build_qualified_type (original_type, TYPE_QUAL_VOLATILE)"

tree.h offers:
- TYPE_QUAL_CONST
- TYPE_QUAL_VOLATILE
- TYPE_QUAL_RESTRICT

whereas fortran only "uses":
DEF_PRIMITIVE_TYPE (BT_VOLATILE_PTR,
                    build_pointer_type
                     (build_qualified_type (void_type_node,
                                            TYPE_QUAL_VOLATILE)))

I think TYPE_QUAL_CONST should be used for all PARAMETERs (unless I miss
something), maybe also for intent(in) pointers etc.

Currently, using "const int" in C gives in (-dump-tree-original) "const int"
whereas "integer, parameter ::" in Fortran only gives "int".

  * * *

The meaning can be found in the C99 standard (6.7.3):

"An object that has volatile-qualified type may be modified in ways unknown to
the implementation or have other unknown side effects. Therefore any expression
referring to such an object shall be evaluated strictly according to the rules
of the abstract machine, as described in 5.1.2.3. Furthermore, at every
sequence point the value last stored in the object shall agree with that
prescribed by the abstract machine, except as modified by the unknown factors
mentioned previously.114) What constitutes an access to an object that
has volatile-qualified type is implementation-defined."

"An object that is accessed through a restrict-qualified pointer has a special
association with that pointer. This association, defined in 6.7.3.1 below,
requires that all accesses to that object use, directly or indirectly, the
value of that particular pointer.115) The intended use of the restrict
qualifier (like the register storage class) is to promote optimization, and
deleting all instances of the qualifier from all preprocessing translation
units composing a conforming program does not change its meaning (i.e.,
observable
behavior)." (And more detailed and formal in the paragraphs below.)


-- 
           Summary: gfortran should use TYPE_QUAL_CONST etc.
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: burnus at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29697


^ permalink raw reply	[flat|nested] 10+ messages in thread
[parent not found: <bug-29697-4@http.gcc.gnu.org/bugzilla/>]
end of thread, other threads:[~2013-06-25  9:05 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-11-03 16:54 [Bug fortran/29697] New: gfortran should use TYPE_QUAL_CONST etc burnus at gcc dot gnu dot org
2006-11-03 17:03 ` [Bug fortran/29697] " burnus at gcc dot gnu dot org
2006-11-03 17:26 ` burnus at gcc dot gnu dot org
2006-11-03 18:03 ` pinskia at gcc dot gnu dot org
2006-11-07 14:24 ` burnus at gcc dot gnu dot org
2007-04-18  6:00 ` fxcoudert at gcc dot gnu dot org
2007-04-18  6:00 ` fxcoudert at gcc dot gnu dot org
2009-08-21 18:44 ` burnus at gcc dot gnu dot org
     [not found] <bug-29697-4@http.gcc.gnu.org/bugzilla/>
2013-06-25  9:05 ` dominiq at lps dot ens.fr
2013-06-25  9:05 ` dominiq at lps dot ens.fr

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).