Re: Missing functionality

[Gary Oblock via Gcc]

> gsi_insert_seq_before

Yes, I discovered this myself via Google and ironically it was because of a 
2008 comment by you that you'd renamed gsi_link_seq_before. Frankly, I find 
this a bit amusing. This doesn't seem to be a very heavily used function and 
I'm probably going to be its user.

Gary

From: Richard Biener 
Sent: Thursday, October 22, 2020 11:01 PM
To: Gary Oblock 
Cc: gcc@gcc.gnu.org 
Subject: Re: Missing functionality

[EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please 
be mindful of safe email handling and proprietary information protection 
practices.]


On Fri, Oct 23, 2020 at 5:10 AM Gary Oblock via Gcc  wrote:
>
> I'm finishing up coding my patterns for the structure reorganization
> optimization. They recognize certain instructions and replace them
> other instructions. I've got some code that generates gimple which is
> inserted as it's created with gsi_insert_before.  This code is
> something I'd like to use at other points in my optimization so I'd
> like to create a function to do this.
>
> Now comes the interesting bit. I'd like to use gimple sequences and
> after reading the internals documentation I put together something
> using gimple_seq_add_stmt to add the generated gimple to a new
> sequence. After this I tried inserting the sequence into the basic
> block's sequence with gsi_link_seq_before. It turns out there is no
> gsi_link_seq_before! I could probably write one myself but that begs
> the question, why is there no gsi_link_seq_before and what should I
> use instead?

gsi_insert_seq_before

> Thank
>
> Gary
>
>
> CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is 
> for the sole use of the intended recipient(s) and contains information that 
> is confidential and proprietary to Ampere Computing or its subsidiaries. It 
> is to be used solely for the purpose of furthering the parties' business 
> relationship. Any unauthorized review, copying, or distribution of this email 
> (or any attachments thereto) is strictly prohibited. If you are not the 
> intended recipient, please contact the sender immediately and permanently 
> delete the original and any copies of this email and any attachments thereto.

VLA warning on recent git

[Uecker, Martin]

I tested a recent GCC from git and noticed a couple
of new warnings for VLA parameters. 

(Martin, I assume this is your work. First, let me
say: thank you! I think this is really important.)

Here is some feedback from running this on an
existing code base. See below for comments and
toy examples. The capital letters refer to 
specific warnings.

Best,
Martin



-Wvla-parameter

A and B: I think the warning is a bit too strict.
These types are compatible, just one of them is
incomplete. 

C: this seems to be bug as the types are
identical.

-Wstringop-overflow / -Wnonnull

D and F: Without 'static' I am not sure why this
is not allowed to be a null pointer (as in E and G).




#include 

void f1(int n, int x[n]);

void f1(int n, int x[]) { }; 
// A: warning: argument 2 of type ‘int[]’ declared as an ordinary array

void f2(int n, int x[]);

void f2(int n, int x[n]) { }; 
// B: argument 2 of type ‘int[n]’ declared as a variable length array

void f3(int n, int x[n + 1]);

void f3(int n, int x[n + 1]) { }; 
// C: argument 2 of type ‘int[n + 1]’ declared with mismatched bound ‘n
+ 1’

void f4(int n, int x[static n]) { };

void foo(void)
{
  int x[] = { };
  f1(0, x);
  f1(1, x); 
// D: ‘f1’ accessing 4 bytes in a region of size 0

  f4(0, x);
  f4(1, x):
// E: ‘f4’ accessing 4 bytes in a region of size
0

  f1(0, NULL);
  f1(1, NULL);
// F: argument 1 of variable length array ‘int[n]’ is null but the
corresponding bound argument 2 value is 1

  f4(0, NULL);
  f4(1, NULL);
// G: argument 1 of variable length array ‘int[n]’ is null but the
corresponding bound argument 2 value is 1
}

Re: VLA warning on recent git

[Martin Sebor via Gcc]

On 10/23/20 7:41 AM, Uecker, Martin wrote:



I tested a recent GCC from git and noticed a couple
of new warnings for VLA parameters.

(Martin, I assume this is your work. First, let me
say: thank you! I think this is really important.)

Here is some feedback from running this on an
existing code base. See below for comments and
toy examples. The capital letters refer to
specific warnings.

Best,
Martin



-Wvla-parameter

A and B: I think the warning is a bit too strict.
These types are compatible, just one of them is
incomplete.

C: this seems to be bug as the types are
identical.


Yes, it's a bug.  I opened pr97548 for it.  It probably won't be
trivial to fix.



-Wstringop-overflow / -Wnonnull

D and F: Without 'static' I am not sure why this
is not allowed to be a null pointer (as in E and G).


I agree it should be.  It seems to be allowed on trunk.  The warning
inadvertently skips the 'static' part for VLAs.  I've raised pr97552
as a reminder to fix that.

Thanks for testing!

Martin


#include 

void f1(int n, int x[n]);

void f1(int n, int x[]) { };
// A: warning: argument 2 of type ‘int[]’ declared as an ordinary array

void f2(int n, int x[]);

void f2(int n, int x[n]) { };
// B: argument 2 of type ‘int[n]’ declared as a variable length array

void f3(int n, int x[n + 1]);

void f3(int n, int x[n + 1]) { };
// C: argument 2 of type ‘int[n + 1]’ declared with mismatched bound ‘n
+ 1’

void f4(int n, int x[static n]) { };

void foo(void)
{
   int x[] = { };
   f1(0, x);
   f1(1, x);
// D: ‘f1’ accessing 4 bytes in a region of size 0

   f4(0, x);
   f4(1, x):
// E: ‘f4’ accessing 4 bytes in a region of size
0

   f1(0, NULL);
   f1(1, NULL);
// F: argument 1 of variable length array ‘int[n]’ is null but the
corresponding bound argument 2 value is 1

   f4(0, NULL);
   f4(1, NULL);
// G: argument 1 of variable length array ‘int[n]’ is null but the
corresponding bound argument 2 value is 1
}

Fortran Shared Coarrays for GCC 11

[Nicolas König]

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!

  Nicolas König

Re: Fortran Shared Coarrays for GCC 11

[Richard Biener via Gcc]

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

Greetings my dear

[kevinwat001--- via Gcc]

I've invited you to fill out the following form:
Untitled form

To fill it out, visit:
https://docs.google.com/forms/d/e/1FAIpQLSf7X7bcfxZWQkzCKrKVtwJfE03rP10UpN9QLlI85wJHnmgfkQ/viewform?vc=0&c=0&w=1&flr=0&usp=mail_form_link

Greetings my dear
I am Kevin Watson, i have an important project to discuss with you. Please  
reply back for more details. Thanks, Kevin


Google Forms: Create and analyze surveys.

What would happen when linking code that compiles with -fexec-charset=IBM-12712 and UTF8?

[sotrdg sotrdg via Gcc]

I think that just generates undefined behaviors.

Sent from Mail for Windows 10

gcc-9-20201023 is now available

[GCC Administrator via Gcc]

Snapshot gcc-9-20201023 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/9-20201023/
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 3fca9cad041097627a1db3b84598b155c204bc5a

You'll find:

 gcc-9-20201023.tar.xzComplete GCC

  SHA256=a25c5c6a1fd7d94305fba264f3223f00c9474d3bf424f1df7b754f9c361cd08e
  SHA1=723c808f9e8d6bcd47efe8769549aa1d74524054

Diffs from 9-20201016 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.

Re: Fortran Shared Coarrays for GCC 11

[David Edelsohn via Gcc]

On Fri, Oct 23, 2020 at 12:52 PM 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 GNU Compile Farm has a wide variety of systems on which you can
test bootstrap.

I tested the branch on AIX and it broke because the new files are
violating a GCC coding style convention: the libgfortran.h header file
MUST be the first header file included.  Some of the new files in the
libgfortran/nca subdirectory include system header files first.  This
is verboten.

It also is incorrect to include libgfortran.h in the source code, and
again include it in the coarrays header files.  And some system header
files are included in source code and some in the coarrays header
files.  The header file inclusion style should be consistent.

But, most importantly, libgfortran.h MUST be included first in any
coarrays source code file.

Thanks, David