Bug 41209 - Add full ATTRIBUTE support to gfortran (ALIGN, (WEAK)ALIAS, ...)
Summary: Add full ATTRIBUTE support to gfortran (ALIGN, (WEAK)ALIAS, ...)
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.5.0
: P3 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
: 49501 (view as bug list)
Depends on:
Blocks: 53552
  Show dependency treegraph
Reported: 2009-09-01 09:35 UTC by Tobias Burnus
Modified: 2017-06-13 13:40 UTC (History)
6 users (show)

See Also:
Known to work:
Known to fail:
Last reconfirmed: 2009-12-04 23:33:29

Draft patch - first steps but incomplete & will not work (3.98 KB, patch)
2009-09-01 17:39 UTC, Tobias Burnus
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Tobias Burnus 2009-09-01 09:35:02 UTC
gfortran currently supports only STDCALL, FASTCALL and CDECL as attributes using

  !GCC$ ATTRIBUTE <list> :: symbol

The attributes are saved as bit in the attr struct. For full attribute support, one presumably should save the string and convert it later in trans*.c into a TREE.

The string should then be saved in the .mod file. (That is also the reason that one cannot directly save the attributes into a TREE.)

Issue: For STDCALL etc. we do some conformance checking for proc-pointer assignments. That should continue to work. Maybe one needs to do further checks.


PR 34112 and PR 40955
Comment 1 Tobias Burnus 2009-09-01 13:29:51 UTC
As fun one can think of supporting also alignment within a TYPE, similarly to C's:
   struct foo { int x[2] __attribute__ ((aligned (8))); };

See http://gcc.gnu.org/onlinedocs/gcc/Type-Attributes.html for details.
Comment 2 Tobias Burnus 2009-09-01 17:39:23 UTC
Created attachment 18463 [details]
Draft patch - first steps but incomplete & will not work

Draft patch (not really work yet).

a) Copy attributes properly and free them at the end
b) Write/read them from the .mod file
c) Use an ENUM for stdcall etc.? Requires a check whether they are already set but those options are orthogonal thus that makes sense.

TODO 2: Check whether derived types are properly handled: bind(C) vs. sequence vs. extensible types. And attributes to components vs. attributes to the type as a whole.
Plus checking whether we set some attributes by default which clash with user settings.
Plus: Are additional front-end checks needed besides stdcall etc. conformance for proc-pointers?
Comment 3 Daniel Franke 2009-12-04 23:33:29 UTC
Confirmed and marked as enhancement.
(I'd like to eventually be able to use the attribute DEPRECATED.)
Comment 4 Tobias Burnus 2010-02-18 16:19:25 UTC
Another request for this feature:
Comment 5 Tobias Burnus 2010-08-24 14:38:15 UTC
This feature is also useful for the test suite, e.g. to force no inlining.

Some attributes need to be moved out of c-family/c-common.c to be available for Fortran.
Comment 6 Bastien ROUCARIES 2011-06-10 10:16:51 UTC
Please not that bug #35827 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35827) depend of this bug.
Comment 7 stevenj 2011-06-22 05:17:45 UTC
Note that Bug 49501 (requesting at least ATTRIBUTES ALIGN) is also related to this one.
Comment 8 Thomas Koenig 2011-09-11 12:06:48 UTC
*** Bug 49501 has been marked as a duplicate of this bug. ***
Comment 9 Tobias Burnus 2013-08-28 06:34:07 UTC
For ALIGN, we should consider following Intel's compiler by also using it for ALLOCATE and not only for static arrays; cf. http://software.intel.com/en-us/articles/data-alignment-to-assist-vectorization (That has to be explicitly spelled out as for C/C++ the aligned attribute - obviously - does not have this effect.)