[Bug target/95182] New: Change the definition of Pmode

[Bug target/95182] New: Change the definition of Pmode

[duanbo3 at huawei dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95182

            Bug ID: 95182
           Summary: Change the definition of Pmode
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: duanbo3 at huawei dot com
  Target Milestone: ---
            Target: aarch64

Hi

I found a problem in aarch64.

--
An alias for the machine mode for pointers. On most machines, define this to be
the integer mode corresponding to the width of a hardware pointer; SImode on
32-bit machine or DImode on 64-bit machines. On some machines you must define
this to
be one of the partial integer modes, such as PSImode.
The width of Pmode must be at least as large as the value of POINTER_SIZE. If
it
is not equal, you must define the macro POINTERS_EXTEND_UNSIGNED to specify how
pointers are extended to Pmode.
--
this is the Document description of Pmode.

Unlike x86,S390 etc., Pmode is always set to DImode for aarch64 port even under
ILP32. Because of that definition,  machine mode of symbol_ref which is
supposed to be SImode becomes DImode under target ILP32.
Definition of Pmode should depend on the current ABI, i.e., SImode for ILP32
and DImode for LP64.

[Bug target/95182] Change the definition of Pmode

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95182

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
It won't work.  When I was originally working on AARCH64 ILP32, it did not work
and will not work due to wrapping and way subtracting works.

[Bug target/95182] Change the definition of Pmode

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95182

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Also explictly this part of the documentation makes it clear that Pmode should
be DImode for AARCH64 ILP32:
define this to be the integer mode corresponding to the width of a hardware
pointer

The hardware pointer size is 64bits aka DImode.  That is all load/stores index
instruction do handle the VA calulcation in 64bits.

[Bug target/95182] Change the definition of Pmode

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95182

--- Comment #3 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Nathan Sidwell <nathan@gcc.gnu.org>:

https://gcc.gnu.org/g:a641d6d3e631e523e8cf0cfc8b8e324da118dff2

commit r11-496-ga641d6d3e631e523e8cf0cfc8b8e324da118dff2
Author: Nathan Sidwell <nathan@acm.org>
Date:   Tue May 19 06:11:22 2020 -0700

    preprocessor: Fix ICE with EOF in macro args [pr95182]

    This was another latent case of us losing an EOF token, but succeeding
    anyway.  Since my patch to make us pay more attention to EOFs it came
    to light.  We also need to keep the EOF if we fall off the end of the
    main file.  Forced includes look like regular nested includes at this
    point.

            PR preprocessor/95182
            libcpp/
            * macro.c (collect_args): Preserve EOFif we fell out of the main
            file.
            (cpp_get_token_1): Reformat a couple of short lines.

[Bug target/95182] Change the definition of Pmode

[nathan at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95182

Nathan Sidwell <nathan at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nathan at gcc dot gnu.org

--- Comment #4 from Nathan Sidwell <nathan at gcc dot gnu.org> ---
That patch was aiming for 95183, but missed :)