[Bug c/26372] New: opposite of may_alias attribute

[Bug c/26372] New: opposite of may_alias attribute

[acahalan at gmail dot com]

This would be for char of course.

When -fno-strict-aliasing is in effect, the proposed attribute should be able
to reenable strict aliasing for any type.


-- 
           Summary: opposite of may_alias attribute
           Product: gcc
           Version: 4.2.0
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: acahalan at gmail dot com


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

[Bug c/26372] opposite of may_alias attribute

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2006-02-19 21:31 -------
__restrict it is called.


-- 


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

[Bug c/26372] opposite of may_alias attribute

[acahalan at gmail dot com]

------- Comment #2 from acahalan at gmail dot com  2006-02-19 21:40 -------
No, __restrict is too strong. It also, last I heard, couldn't be applied to a
type.

(if restrict was right, then using it on an int would be redundant)


-- 


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

[Bug c/26372] opposite of may_alias attribute

[pinskia at gcc dot gnu dot org]

------- Comment #3 from pinskia at gcc dot gnu dot org  2006-02-20 02:04 -------
Can you give an example of where this is useful and why not instead improve GCC
for your code gen issues?


-- 


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

[Bug c/26372] opposite of may_alias attribute

[acahalan at gmail dot com]

------- Comment #4 from acahalan at gmail dot com  2006-02-20 03:29 -------
There have been times when I could not prove to myself that __restrict would be
safe (it may have been), yet I knew that the char pointer would not alias with
non-char pointers.

(sorry to not have a nice chunk of code handy -- I just discovered where to
report gcc bugs and missing features, so I had a backlog of things that have
bothered me over the years)


-- 


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

[Bug c/26372] opposite of may_alias attribute

[rguenth at gcc dot gnu dot org]

------- Comment #5 from rguenth at gcc dot gnu dot org  2006-02-21 10:17 -------
This needs more explanation.  char pointers are special with and without
strict-aliasing.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING


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

[Bug c/26372] opposite of may_alias attribute

[acahalan at gmail dot com]

------- Comment #6 from acahalan at gmail dot com  2006-02-22 03:28 -------
Yes, char pointers are special. I'd like a non-special char pointer.

I often know that a char pointer will never alias non-char data, but can not
prove that it obeys all the complicated rules for __restrict.

For non-char pointers the attribute would be useless unless
-fno-strict-aliasing is in effect.


-- 


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

[Bug c/26372] opposite of may_alias attribute

[pinskia at gcc dot gnu dot org]

------- Comment #7 from pinskia at gcc dot gnu dot org  2006-07-19 03:47 -------
(In reply to comment #6)
> Yes, char pointers are special. I'd like a non-special char pointer.

Actually it is not the char pointers which are special but access through a
character, there is a difference.

> I often know that a char pointer will never alias non-char data, but can not
> prove that it obeys all the complicated rules for __restrict.

restrict is actually less strict than what you want :).  restrict attributed
pointers are can still alias other pointers, just not other restrict attributed
pointers.


> For non-char pointers the attribute would be useless unless
> -fno-strict-aliasing is in effect.

Even then it might be useless as -fno-strict-aliasing is huge hammer.

Also no feedback on an example in 3 months so closing.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|                            |INVALID


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