public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug middle-end/97656] New: Specify that there is no address arithmetic on a pointer
@ 2020-10-31 16:40 tkoenig at gcc dot gnu.org
2020-11-02 7:43 ` [Bug middle-end/97656] " rguenth at gcc dot gnu.org
` (2 more replies)
0 siblings, 3 replies; 4+ messages in thread
From: tkoenig at gcc dot gnu.org @ 2020-10-31 16:40 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97656
Bug ID: 97656
Summary: Specify that there is no address arithmetic on a
pointer
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
This involves Fortran, but possibly also other languages.
Consider
$ cat alias.f90
program main
interface
subroutine foo(a)
integer, intent(inout) :: a
end subroutine foo
end interface
integer, dimension(2) :: x
x(1) = 42
x(2) = 42
call foo(x(1))
if (x(2) /= 42) stop "Error!"
end program main
This program specifies that foo has a scalar argument, passed by reference.
It is forbidden by Fortran's rules foo could access the element x(2),
therefore the call to stop could be optimized away, but it isn't:
$ gfortran -O3 -S alias.f90
$ grep _gfortran_stop alias.s
call _gfortran_stop_string
$
It would be good if there was a TREE_NO_POINTER_ARITHMETC (or simlar) flag
that could be set by the Fortran front end.
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug middle-end/97656] Specify that there is no address arithmetic on a pointer
2020-10-31 16:40 [Bug middle-end/97656] New: Specify that there is no address arithmetic on a pointer tkoenig at gcc dot gnu.org
@ 2020-11-02 7:43 ` rguenth at gcc dot gnu.org
2020-11-02 8:23 ` jakub at gcc dot gnu.org
2020-11-02 8:26 ` rguenther at suse dot de
2 siblings, 0 replies; 4+ messages in thread
From: rguenth at gcc dot gnu.org @ 2020-11-02 7:43 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97656
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hubicka at gcc dot gnu.org,
| |rguenth at gcc dot gnu.org
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
It's of course not that simple since the GIMPLE IL can require pointer
arithmetic as implementation detail. I guess we could try modeling this as 'fn
spec'
by making 'direct' even stricter meaning 'direct w/o additional offset' so
we can build an exact ao_ref here. Maybe use
". WT"
for this? And the discussed 'a'...'z' for the "upper case" '1'...'9', both
to denote the range is exact? Note we discussed that we can this way
specify a must-def but here it's a may-def but with known offset. Guess
must vs. may would rather be another first letter like 'D'? (and only 'direct'
supported there obviously) And the upper case size specification means
at zero offset?
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug middle-end/97656] Specify that there is no address arithmetic on a pointer
2020-10-31 16:40 [Bug middle-end/97656] New: Specify that there is no address arithmetic on a pointer tkoenig at gcc dot gnu.org
2020-11-02 7:43 ` [Bug middle-end/97656] " rguenth at gcc dot gnu.org
@ 2020-11-02 8:23 ` jakub at gcc dot gnu.org
2020-11-02 8:26 ` rguenther at suse dot de
2 siblings, 0 replies; 4+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-11-02 8:23 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97656
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #1)
> Maybe use
>
> ". WT"
>
> for this? And the discussed 'a'...'z' for the "upper case" '1'...'9', both
> to denote the range is exact? Note we discussed that we can this way
> specify a must-def but here it's a may-def but with known offset. Guess
> must vs. may would rather be another first letter like 'D'? (and only
> 'direct' supported there obviously) And the upper case size specification
> means
> at zero offset?
Well, at least in the above case it is not just 0 offset, but any access from
the offset 0 (inclusive) to size of the type pointed by the argument
(exclusive).
E.g. if it is a structure, SRA must be surely be able to split it off and use
MEM_REFs even with non-zero offsets.
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug middle-end/97656] Specify that there is no address arithmetic on a pointer
2020-10-31 16:40 [Bug middle-end/97656] New: Specify that there is no address arithmetic on a pointer tkoenig at gcc dot gnu.org
2020-11-02 7:43 ` [Bug middle-end/97656] " rguenth at gcc dot gnu.org
2020-11-02 8:23 ` jakub at gcc dot gnu.org
@ 2020-11-02 8:26 ` rguenther at suse dot de
2 siblings, 0 replies; 4+ messages in thread
From: rguenther at suse dot de @ 2020-11-02 8:26 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97656
--- Comment #3 from rguenther at suse dot de <rguenther at suse dot de> ---
On Mon, 2 Nov 2020, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97656
>
> Jakub Jelinek <jakub at gcc dot gnu.org> changed:
>
> What |Removed |Added
> ----------------------------------------------------------------------------
> CC| |jakub at gcc dot gnu.org
>
> --- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> (In reply to Richard Biener from comment #1)
> > Maybe use
> >
> > ". WT"
> >
> > for this? And the discussed 'a'...'z' for the "upper case" '1'...'9', both
> > to denote the range is exact? Note we discussed that we can this way
> > specify a must-def but here it's a may-def but with known offset. Guess
> > must vs. may would rather be another first letter like 'D'? (and only
> > 'direct' supported there obviously) And the upper case size specification
> > means
> > at zero offset?
>
> Well, at least in the above case it is not just 0 offset, but any access from
> the offset 0 (inclusive) to size of the type pointed by the argument
> (exclusive).
> E.g. if it is a structure, SRA must be surely be able to split it off and use
> MEM_REFs even with non-zero offsets.
Yes, we can only model the effect in the caller not constraints to the
actual IL in the callee.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-11-02 8:26 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-10-31 16:40 [Bug middle-end/97656] New: Specify that there is no address arithmetic on a pointer tkoenig at gcc dot gnu.org
2020-11-02 7:43 ` [Bug middle-end/97656] " rguenth at gcc dot gnu.org
2020-11-02 8:23 ` jakub at gcc dot gnu.org
2020-11-02 8:26 ` rguenther at suse dot de
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).