[Bug fortran/29697] gfortran should use TYPE_QUAL_CONST etc.

2006-11-03 Thread burnus at gcc dot gnu dot org


--- Comment #1 from burnus at gcc dot gnu dot org  2006-11-03 17:03 ---
A good introduction into restricted can be found at
http://developers.sun.com/sunstudio/articles/cc_restrict.html

Maybe this is something for the array implementation in gfortran?
I don't fully understand how the data part of arrays are used, but I would
assume they are pointers where the "restricted" part is not given.
As Fortran requires "target" for arrays to which a pointer may point, it should
be easy to add "restricted" in the non-target case; according to the article it
helps the compiler quit a bit to optimize - as "const" does.


-- 


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



[Bug fortran/29697] gfortran should use TYPE_QUAL_CONST etc.

2006-11-03 Thread burnus at gcc dot gnu dot org


--- Comment #2 from burnus at gcc dot gnu dot org  2006-11-03 17:26 ---
Andy pointed out that TYPE_QUAL_VOLATILE only changes the dumped string,
nonetheless it makes checking things easier, I think.


-- 


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



[Bug fortran/29697] gfortran should use TYPE_QUAL_CONST etc.

2006-11-03 Thread pinskia at gcc dot gnu dot org


--- Comment #3 from pinskia at gcc dot gnu dot org  2006-11-03 18:03 ---
For arguments, you missed that flag_argument_noalias is set to 2 (or is it 3
now).

It also changes debugging info which is needed in this case to get the correct
debuging info.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

OtherBugsDependingO||24546
  nThis||
   Severity|enhancement |normal


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



[Bug fortran/29697] gfortran should use TYPE_QUAL_CONST etc.

2006-11-07 Thread burnus at gcc dot gnu dot org


--- Comment #4 from burnus at gcc dot gnu dot org  2006-11-07 14:24 ---
Note for completeness: With PR 29601 the TYPE_QUAL_VOLATILE is used for for
VOLATILE variables (see -fdump-tree-original; however, the word "volatile" does
not show up in the dump for pointers and arrays, even though they are treated
as volatile correctly; cf. gfortran.dg/volatile{6,7}.f90.)


-- 


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



[Bug fortran/29697] gfortran should use TYPE_QUAL_CONST etc.

2007-04-17 Thread fxcoudert at gcc dot gnu dot org


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement


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



[Bug fortran/29697] gfortran should use TYPE_QUAL_CONST etc.

2007-04-17 Thread fxcoudert at gcc dot gnu dot org


-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-04-18 07:00:16
   date||


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



[Bug fortran/29697] gfortran should use TYPE_QUAL_CONST etc.

2013-06-25 Thread dominiq at lps dot ens.fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29697

--- Comment #6 from Dominique d'Humieres  ---
Per

> TYPE_QUAL_RESTRICT is now supported, see 
> http://gcc.gnu.org/ml/fortran/2009-08/msg00208.html
> TYPE_QUAL_CONST is to my knowledge a no op, for QUAL_VOLATILE, 
> I have not checked whether it is already (correctly) used or 
> not - according to comment 4 they are.

Closing as FIXED. Please reopen if I am wrong.


[Bug fortran/29697] gfortran should use TYPE_QUAL_CONST etc.

2013-06-25 Thread dominiq at lps dot ens.fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29697

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Dominique d'Humieres  ---
Done now.


[Bug fortran/29697] gfortran should use TYPE_QUAL_CONST etc.

2009-08-21 Thread burnus at gcc dot gnu dot org


--- Comment #5 from burnus at gcc dot gnu dot org  2009-08-21 18:44 ---
TYPE_QUAL_RESTRICT is now supported, see
http://gcc.gnu.org/ml/fortran/2009-08/msg00208.html
TYPE_QUAL_CONST is to my knowledge a no op, for QUAL_VOLATILE, I have not
checked whether it is already (correctly) used or not - according to comment 4
they are.


-- 


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