Re: Fortran Shared Coarrays for GCC 11

2020-10-25 Thread Nicolas König 

Hi Richard,

that's an excellent idea, I'll try to figure out to do that.

Thanks for the advice!

Nicolas

On 23/10/2020 19:29, Richard Biener wrote:

On October 23, 2020 7:49:04 PM GMT+02:00, "Nicolas König" 
 wrote:

Hello everyone,

I'm hoping to get shared coarrays for fortran (the devel/coarray_native
branch) merged for GCC 11 as an experimental feature, but, since the
library uses a lot of low-level routines, I'm a bit scared of breaking
bootstrap. It would be great if some people with more unusual setup-ups
could try building with the branch (at the moment, I have tested it on
Linux both on Power and x86_64). The focus at the moment is just on
bootstrap.

Thanks in advance!


The library part could be made opt-in for known working platforms like we do 
for others (through configure.tgt)

Richard.


   Nicolas König

Question about whether a code fragment is expected to parse.

2020-10-25 Thread Iain Sandoe via Gcc 

Hi

Given that GNU attributes are not part of the standard..

I wonder if the following is expected to work?

__attribute__((__deprecated__))
extern "C" __attribute__((__visibility__("default")))
void foo ()
{

}

t.C:3:8: error: expected unqualified-id before string constant
3 | extern "C" __attribute__((__visibility__("default")))

===

Note that the C (and C++) front ends are happy to accept:

__attribute__((__deprecated__))
extern __attribute__((__visibility__("default")))
void foo ()
{

}

happy to file a PR/attempt a fix if we expect this to work
(clang accepts it, FWIW)

thanks
Iain

[__mulvti3] register allocator plays shell game

2020-10-25 Thread Stefan Kanthak 
Hi,

for the AMD64 alias x86_64 platform and the __int128_t [DW]type,
the first few lines of the __mulvDI3() function from libgcc2.c

| DWtype
| __mulvDI3 (DWtype u, DWtype v)
| {
|   /* The unchecked multiplication needs 3 Wtype x Wtype multiplications,
|  but the checked multiplication needs only two.  */
|   const DWunion uu = {.ll = u};
|   const DWunion vv = {.ll = v};
|
|   if (__builtin_expect (uu.s.high == uu.s.low >> (W_TYPE_SIZE - 1), 1))
| {
|   /* u fits in a single Wtype.  */
|   if (__builtin_expect (vv.s.high == vv.s.low >> (W_TYPE_SIZE - 1), 1))
|  {
|/* v fits in a single Wtype as well.  */
|/* A single multiplication.  No overflow risk.  */
|return (DWtype) uu.s.low * (DWtype) vv.s.low;
|  }

are compiled to this braindead code (obtained from libgcc.a of
GCC 10.2.0 installed on Debian):

 <__mulvti3>:
   0: 41 55 push   %r13
   2: 49 89 cb  mov%rcx,%r11
   5: 48 89 d0  mov%rdx,%rax
   8: 49 89 d2  mov%rdx,%r10
   b: 41 54 push   %r12
   d: 49 89 fc  mov%rdi,%r12
  10: 48 89 d1  mov%rdx,%rcx
  13: 49 89 f0  mov%rsi,%r8
  16: 4c 89 e2  mov%r12,%rdx
  19: 49 89 f5  mov%rsi,%r13
  1c: 53push   %rbx
  1d: 48 89 fe  mov%rdi,%rsi
  20: 48 c1 fa 3f   sar$0x3f,%rdx
  24: 48 c1 f8 3f   sar$0x3f,%rax
  28: 4c 89 df  mov%r11,%rdi
  2b: 4c 39 c2  cmp%r8,%rdx
  2e: 75 18 jne48 <__mulvti3+0x48>
  30: 4c 39 d8  cmp%r11,%rax
  33: 75 6b jnea0 <__mulvti3+0xa0>
  35: 4c 89 e0  mov%r12,%rax
  38: 49 f7 ea  imul   %r10
  3b: 5bpop%rbx
  3c: 41 5c pop%r12
  3e: 41 5d pop%r13
  40: c3retq   
...

There are EIGHT superfluous MOV instructions here, clobbering the
non-volatile registers RBX, R12 and R13, plus THREE superfluous
PUSH/POP pairs.

What stops GCC from generating the following straightforward code
(11 instructions in 31 bytes instead of 25 instructions in 65 bytes)?

.intel_syntax noprefix
__mulvti3:
mov   r8, rdi
mov   r9, rdx
sra   r8, 63
sra   r9, 63
cmp   r8, rsi
jne   __mulvti3+0x48+65-31
cmp   r9, rcx
jne   __mulvti3+0xa0+65-31
mov   rax, rdi
imul  rdx
ret
...


not amused
Stefan Kanthak

gcc-11-20201025 is now available

2020-10-25 Thread GCC Administrator via Gcc 
Snapshot gcc-11-20201025 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/11-20201025/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 11 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch master 
revision 308e40331f9d2820f8286769b5fc764671187364

You'll find:

 gcc-11-20201025.tar.xz   Complete GCC

  SHA256=dd59afe340edc66b62626117790f0310d088b52d350118e48c061c08a6422be1
  SHA1=befa1761c8f44ee3bef5b853538d2057f705de66

Diffs from 11-20201018 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-11
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.

Security wrapper around the stack

2020-10-25 Thread Raj J Putari (unidef) via Gcc 
I know compiling is exponenental when considering it compiles operating 
systems, but can someone either implement or help me implement some kind of 
singular security feature for the stack so hacks dont access the heap? Im 
thinking the first few bytes would be some security software or feature (which 
can be optionally compiled in I guess)

Any takers?

Jonathan Maharaj
jmaharaj2...@gmail.com
Founder, Owner, and Operator of Unidef



smime.p7s
Description: S/MIME cryptographic signature