Re: S390 should change the meaning of -m31

[Michael Matz via Gcc]

Hello,

On Wed, 29 Sep 2021, Jesus Antonio via Gcc wrote:

> m31 is semantically the same as the m32 option.
> 
> 
> The m31 option allows for 32 bit addressing and that is confusing since 
> the m31 option in S390 would mean 2 GiB space addressing

Indeed that's exactly what it means, and what it's supposed to mean.  On 
s390, in AMODE(31) the toplevel bit of an (32bit) address is either 
ignored or an indicator to switch back to 24bit addresses from the s360 
times.  Either way that leaves 31 bits to generate the virtual address.  
On s390 you indeed have a 2GB address space, not more.

> Code used:
> 
>     volatile uint64_t *gib_test = (volatile uint64_t *)0x7FFF;
>     memset(gib_test, 1, 4096);
> 
> 
> Hercules dump:
> 
> r 0x7FFF-0x81FF
> R:7FFF:K:06=01 .

I'm not sure what you believe to have demonstrated here.  The (virtual or 
physical) address 0x7FFF is either (in AMODE(24)) equivalent to 
0x00ff or to 0x (in AMODE(31)), either way, the top byte of 
the addressable range ...

> R:800F:K:06=01 01010101 01010101 01010101 010101 

... while address 0x8001 is equivalent to address 0x1 (in AMODE(24) 
and AMODE(31)).  Again, the top bit (or bits in AMODE(24)) are ignored.  
So, you've built a memset that wraps around the line (AMODE(24)) or the 
bar (AMODE(32)).  Perhaps unusual and not what you expected, but as 
designed by IBM.

> The option i used was m31 of course, however this option is misleading 
> since it allows 32 bit mode, and there is no m32 so you have to use m31 
> - just lots of misleading options.

The -mXX options are supposed to reflect the address space's size, not the 
size of the general purpose registers.  An option that reflect AMODE(24) 
would also be called -m24, despite the registers still being 32bit in 
size.


Ciao,
Michael.

Re: s390 port

[Paul Edwards via Gcc]

Simply switching off optimization made the negative
indexes go away, allowing more than 2 GiB to be
addressed in standard z/Arch, with "-m31".



Prove it on real hardware, not hercules. Hercules doesnt count.


Real mainframe hardware is not easily accessible.
Hercules is the most convenient way people have
of accessing a mainframe. Do you have any reason
to suggest that Hercules doesn't emulate real
hardware in this respect?

BFN. Paul.

S390 should change the meaning of -m31

[Paul Edwards via Gcc]

Hi Michael.

Thanks for picking up this issue. I have been working
with Jesus on this.


m31 is semantically the same as the m32 option.


The m31 option allows for 32 bit addressing and that is confusing since 
the m31 option in S390 would mean 2 GiB space addressing


Indeed that's exactly what it means, and what it's supposed to mean.  On 
s390, in AMODE(31) the toplevel bit of an (32bit) address is either 
ignored or an indicator to switch back to 24bit addresses from the s360 
times.  Either way that leaves 31 bits to generate the virtual address. 
On s390 you indeed have a 2GB address space, not more.


He is using z/Arch and AM64.

But building with -m31.


Code used:

volatile uint64_t *gib_test = (volatile uint64_t *)0x7FFF;
memset(gib_test, 1, 4096);


Hercules dump:

r 0x7FFF-0x81FF
R:7FFF:K:06=01 .


I'm not sure what you believe to have demonstrated here.  The (virtual or 
physical) address 0x7FFF is either (in AMODE(24)) equivalent to 
0x00ff or to 0x (in AMODE(31)), either way, the top byte of 
the addressable range ...


I don't think that's what Hercules does for a real
memory display - it will instead say out of range.
But it doesn't matter, because we're using
64-bit Hercules with 4 GiB of memory and it doesn't
matter what the AMODE happens to be at any moment
in time, what is important is what is in that 4 GiB of
memory.

The -mXX options are supposed to reflect the address space's size, not the 
size of the general purpose registers.  An option that reflect AMODE(24) 
would also be called -m24, despite the registers still being 32bit in 
size.


The code generated by -m24 would be identical to
code generated by -m31 which would be identical to
code generated by -m32.

Why can't we just have a normal -m32 and accept -m31
and maybe -m24 too, and flag them as "obsolete"?

Thanks. Paul.

gcc-9-20210930 is now available

[GCC Administrator via Gcc]

Snapshot gcc-9-20210930 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/9-20210930/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 9 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-9 
revision e3ad4c45d128c1f4a69f86116a36312aa593554c

You'll find:

 gcc-9-20210930.tar.xzComplete GCC

  SHA256=50dfe2b19ca7c20a518496ade91d2a36f5421639bf4afa3e6cf4c4981b0a791b
  SHA1=e5e2024741df4adfd66919becb58a85f14165850

Diffs from 9-20210923 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-9
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

A Scientific Јοurnal Calls for ՏuЬmissions of Original Works

[Cecilia Li]

We won't send you еmaіls again if you ᴄliᴄк here
 to unѕubѕcrіbe.
SuЬmіt Your
Artіclҽs
Reasons for PuƄlіshing Рapҽrs in Our Јοurnal
01: Speedy Schedule Guidance:

   1. ՏuЬmission of the рαрer
   2. Pre-rеviеԝed result within one to two workdays
   3. Peer-rеviеԝed result provided within 4 weeks
   4. Mаnυscript to be revised
   5. Acceptance of your аrtіcle
   6. Рapҽr ρublicαtion within about 50-60 days from ѕᴜbmiѕѕion

02: Transfer Artіclҽs among Different Јοurnals:
Under a certain discipline, some correlated јοurnals will be suggested. If
you decide not to publіѕh in the ѕuƅmitted јοurnal, you can select the
suggested јοurnal for рαрer transferal.
03: More Audience:
*American Јοurnal of Aerospace Engineering*, as an international acaԁemіc
јοurnal, makes a broader group of reѕearϲhers all over the world αccҽssible
to advanced reѕearϲh developments in their field.
American Јοurnal of Aerospace Engineering

Dear Hohnka, MJ; Miller, JA; Dacumos, KM...,
Your previously publіѕhed рαрer owns the great appreciation of us and thus
we sincerely hope to have the opportunity to publіѕh your other
аrtіcles in *American
Јοurnal of Aerospace Engineering* (IЅЅƝ Online: 2376-4821), a peer-rеviеԝed
јοurnal.
Сontributе Your Mаnυscripts
Kindly ᴄliᴄк the following weЬѕite to ᴄontrіbute to this јοurnal:
http://www.ajaerospace.com/sfii/u2v39
Acceptable Criterion for ՏuЬmissions
The general standards of рαрer formatting (Times New Roman，two-columns,
etc.) should be met. For the convenience of aսthоrs, the рαрer formats like
MS Word (.doc/.docx) and LaTeX are available.
Your cοntrіbutіοn is of great significance for us and we believe it will
definitely facilitate the establishment of higher standards of this јοurnal.
Assistant from Еdіtorial Office of Open Aссеss *American Јοurnal of
Aerospace Engineering*
Here ҽnclоsҽd is the excerpt of your reѕearϲh which has given us a deep
impression: This рαрer explores computer security vulnerabilities that are
generated inadvertently by a compiler. By using a novel approach of
examining the assembly language and other intermediate files generated by
the compilation process, it has been successfully demonstrated that the
compiler's processing of the high-level source code can create a vulnerable
end product. Proper software assurance is intended to provide confidence
that software is frҽҽ from vulnerabilities, and compiler-induced
vulnerabilities reduce this confidence level. The discovered
vulnerabilities can be related to standard vulnerability classes, side
channel attacks, undefined behavior, and persistent state violations.
Additionally, the reѕearϲh revealed that the executable machine code
generated by the compiler can differ in structure from the original source
code due to simplifications and optimizations performed during the
compilation process that cannot be disabled. This reѕearϲh examined both
the open-source GNU C compiler and the Microsoft C/C++ compiler that is
part of the Microsoft Visual Studio package. Both of these compilers are
widely used and represent typical compilers in use today.