Re: GCC 9.5 Release Candidate available

[Iain Sandoe]

> On 23 May 2022, at 07:50, Iain Sandoe  wrote:
> 
> Hi Richard,
> 
>> On 23 May 2022, at 07:27, Richard Biener  wrote:
>> 
>> On Sun, 22 May 2022, Iain Sandoe wrote:
>> 
>>> Hi
>>> 
 On 20 May 2022, at 09:02, Richard Biener via Gcc  wrote:
>>> 
 The first release candidate for GCC 9.5 is available from
 
 https://sourceware.org/pub/gcc/snapshots/9.5.0-RC-20220520/
 
 and shortly its mirrors.  It has been generated from git commit
 1bc79c506205b6a5db82897340bdebaaf7ada934.
 
 I have so far bootstrapped and tested the release candidate
 on x86_64-suse-linux.
>>> 
>>> I have bootstrapped (using GCC5.4 on darwin9 and GCC7.5 elsewhere) r9-10192 
>>> on:
>>> i686-darwin9,17
>>> powerpc-darwin9
>>> x86_64-darwin10 to 21.
>>> 
>>> As, expected (since I was not able to find enough time to do the backports),
>>> although bootstrap succeeds on darwin21 (macOS 12) the resulting compiler
>>> is not really usable.  I will have to provide a darwin branch with the 
>>> necessary
>>> changes.
>>> 
>>> One observation outside of this:
>>> 
>>> Several of the testsuite runs hung with cc1 spinning in reload for pr88414.
>>> I was not really able to correlate exactly with CPU / tuning chosen.
>>> 
>>> Pretty sure this is a regression - I do not recall the testsuite hanging 
>>> (for anything
>>> other than D) for years.
>> 
>> That's gcc.target/i386/pr88414.c?
>> 
>> Can you be more specific on the target the issue occurs on (so one
>> can maybe try with a cross?).  Bisecting would be most helpful of
>> course, if it's some of the recent backports reversion would be
>> most appropriate at this point.
> 
> several cases, here’s the most modern with an m32 multilib:
> 
> Configured with: /src-local/gcc-git-9/configure 
> --prefix=/opt/iains/x86_64-apple-darwin17/gcc-9-wip 
> --build=x86_64-apple-darwin17 
> --with-sysroot=/Library//Developer/CommandLineTools/SDKs/MacOSX.sdk 
> --with-as=/XC/9.4/usr/bin/as --with-ld=/XC/9.4/usr/bin/ld 
> --enable-languages=all CC=x86_64-apple-darwin17-gcc 
> CXX=x86_64-apple-darwin17-g++
> 
> log info:
> 
> [ note the m64 multilib, also emits the diagnostic, but it does not appear to 
> spin. ]
> 
> /scratch/10-13-his/gcc-9-wip/gcc/xgcc -B/scratch/10-13-his/gcc-9-wip/gcc/ 
> /src-local/gcc-git-9/gcc/testsuite/gcc.target/i386/pr88414.c -m32 
> -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers 
> -fdiagnostics-color=never -O1 -ftrapv -S -o pr88414.s
> /src-local/gcc-git-9/gcc/testsuite/gcc.target/i386/pr88414.c: In function 
> 'foo':
> /src-local/gcc-git-9/gcc/testsuite/gcc.target/i386/pr88414.c:15:7: error: 
> 'asm' operand has impossible constraints
> got a INT signal, interrupted by user // (manually killed it)

Hmm, this is not a regression - (although the problem is real) - I also see it 
on 9.4 and 9.3 at least, 
apologies for the noise.
Iain

Re: OMPD: 5.5.8 Display Control Variables

[Jakub Jelinek via Gcc]

On Sun, May 22, 2022 at 05:56:46PM +0200, Mohamed Atef wrote:
> To implement this
> ,
> should I add a function in the runtime to dump all the
> environment variables. Or should I use variables from helper functions?
> To make the icv-name=icv-value pair I think it will be too costly
> to use helper functions.

ICVs are of different kinds, some are pre-process, some are per-device, some
are per-thread, some are per-task.  But the function only has an address
space handle, so it can't query e.g. particular thread, task etc. ICVs.

My understanding is that the function should return something close to what
omp_display_env prints, except with different formatting, without _OPENMP =
line, the OPENMP DISPLAY ENVIRONMENT BEGIN/END pairs etc.
So, look at what omp_display_env does, copy the content of gomp_global_icv
and various other global vars from the process and then print it into
strings like omp_display_env prints then.
Note, omp_display_env can print also device sets before the vars (there are
patches floating for that in libgomp but still need work), like
  [device] OMP_NUM_THREADS='2'
  [host,device] OMP_DYNAMIC='TRUE'
  [host] OMP_PLACES='{0:4},{4:4},{8:4},{12:4}'
but probably this function should print host only stuff without such
prefixes (and without the 's) or indentation.

Jakub

gcc

[Sarah Burgener]

Hi Gcc,



Would you like to communicate with all participants enrolled in the Glee - 
Garden Industry Exhibition 2022?



If so, please let me know so that I can assist you in obtaining a list of 
participants.



Best,

Sarah Burgener

Event Analyst

Re: [RFC Linux patch] powerpc: add documentation for HWCAPs

[Paul E Murphy via Gcc]

On 5/20/22 7:11 PM, Nicholas Piggin wrote:

Excerpts from Paul E Murphy's message of May 21, 2022 12:21 am:



On 5/20/22 12:15 AM, Nicholas Piggin via Gcc wrote:

+PPC_FEATURE2_TAR
+VSX facility is available.


Was manipulating the tar spr was once a privileged instruction, is this
a hint userspace can use the related instructions?


It can be disabled with facility control, and I guess there was
some consideration for how it might be used, e.g., "system software"
could use it for its own purpose then clear the bit for the application.

In practice I don't really know what makes use of this or whether
anything sanely can, it's marked reserved in the ABI. Would be
interesting to know whether there is much benefit to use it in the
compiler. The kernel could actually use it for something nifty if we
were able to prevent userspace from accessing it entirely...


It might be useful as a scratch register for indirect branches in some 
odd cases, such as golang's preemptive userspace threading.  Though, it 
seems more trouble than its worth for a very limited benefit.





+
+PPC_FEATURE2_HAS_IEEE128
+IEEE 128 is available? What instructions/data?


Maybe something like "IEEE 128 binary floating point instructions are
supported.  Individual instruction availability is dependent on the
reported architecture version."?


Right, I just didn't know what architectural class of instructions
those are. Is it just VSX in general or are there some specific
things we can name?


I think ISA 3.1 buckets this into an OpenPOWER Linux Optional Feature 
for "Quad-precision floating-point (QFP)".  I guess ISA 3.0 predates 
those categorizations.




+PPC_FEATURE2_MMA
+MMA facility is available.


Maybe another note that specific instruction availability may depend on
the reported architecture version?
Yep. I wonder if it would help to note how these align (or don't) with 
the various OpenPOWER features.

Re: GCC 9.5 Release Candidate available

[William Seurer via Gcc]

On 5/20/22 3:02 AM, Richard Biener via Gcc wrote:

The first release candidate for GCC 9.5 is available from

https://sourceware.org/pub/gcc/snapshots/9.5.0-RC-20220520/

and shortly its mirrors.  It has been generated from git commit
1bc79c506205b6a5db82897340bdebaaf7ada934.

I have so far bootstrapped and tested the release candidate
on x86_64-suse-linux.

Please test it and report any issues to bugzilla.

If all goes well I'd like to release 9.5 on Friday, May 27th,
which will then close the branch.



I tried the RC on powerpc64 power 7 BE, power 8 BE and LE, and power 9 
and 10 LE and saw nothing unexpected.

Buggy error message when dereferencing once a double pointer to struct

[Andrea Monaco via Gcc]

This snippet that I wrote


  struct
  str
  {
int val;
  };  


  void
  main (int argc, char **argv)
  {
struct str **p;
int i;
  
i = p->val;
  }


is obviously incorrect.  But gcc 8.3.0 says

  pointer.c: In function ‘main’:
  pointer.c:14:8: error: ‘*p’ is a pointer; did you mean to use ‘->’?
 i = p->val;
  ^~
  ->

which seems a buggy error message to me: I wrote "p", not "*p"; also the
compiler suggests replacing "->" with itself.



Andrea Monaco

Re: Buggy error message when dereferencing once a double pointer to struct

[Marek Polacek via Gcc]

On Mon, May 23, 2022 at 06:43:55PM +0200, Andrea Monaco via Gcc wrote:
> 
> This snippet that I wrote
> 
> 
>   struct
>   str
>   {
> int val;
>   };  
> 
> 
>   void
>   main (int argc, char **argv)
>   {
> struct str **p;
> int i;
>   
> i = p->val;
>   }
> 
> 
> is obviously incorrect.  But gcc 8.3.0 says
> 
>   pointer.c: In function ‘main’:
>   pointer.c:14:8: error: ‘*p’ is a pointer; did you mean to use ‘->’?
>  i = p->val;
>   ^~
>   ->
> 
> which seems a buggy error message to me: I wrote "p", not "*p"; also the
> compiler suggests replacing "->" with itself.

Yes, this is https://gcc.gnu.org/PR91134

Marek

Welcome GCC GSoC 2022 participants

[Martin Jambor]

Hello,

I am pleased to announce that as many as six contributors will be
working on GCC Google Summer of Code (GSoC) projects in 2022!  In no
particular order:

- Faisal Abbas will be working on "Complete Support for Constant
  Folding in GCC Rust Front-end." This project will be mentored by
  Philip Herron.

- Immad Mir will "Extend GCCs static analyzer to support checking for
  POSIX file descriptor APIs" and the project will be mentored by
  David Malcolm.

- Andrew Naguib will also work on a Rust front-end project, specifically
  on "Improving debugging experience by enhancing the HIR dump."  The
  project will be mentored by Arthur Cohen and Philip Herron.

- Nitin Kumar will "Bypass assembler when generating LTO object files"
  and in that effort will be mentored by Jan Hubička and myself.

- Tim Lange will add "New checkers for GCC’s static analyzer" and will
  be mentored by David Malcolm.

- Wileam Phan has succeeded with a project on "Accelerating Fortran DO
  CONCURRENT in GCC."  The mentors will be Tobias Burnus and Thomas
  Schwinge.

I'd like to congratulate all of them for putting together very solid
proposals and wish them best of luck with their projects.

The GSoC program has now entered its "community bonding period" which
lasts until June 13th.  During this time you should get in touch with
your mentors unless you have already done so and probably start
looking quite a bit more at GCC in general.

In the initial discussion with your mentors, please take a while to talk
about the time-frame of your project.  If you are happy with the
standard one (mid-term evaluation deadline on July 29th, final deadline
on September 12th) you are all set.  This year the program can however
also accommodate non-standard schedules within some constraints, see
suggestions at:
https://developers.google.com/open-source/gsoc/help/2022-project-dates

If you want to change the duration of your project, first please reach
an agreement with your mentor and then email me.

Because GCC targets many computer platforms, you may also find it very
useful to get an account on the compile farm so that you can test your
code on a variety of architectures.  For more details, see
https://gcc.gnu.org/wiki/CompileFarm

I'd also like to ask all six accepted contributors to take a few
minutes to familiarize themselves with the legal pre-requisites that
we have for contributing.  There are two options.  The much simpler
one is that copyright remains with you but you provide a "Developer
Certificate of Origin" for your contributions.  You can do that by
adding a "Signed-off-by:" tag to all your patches.  The second option
is to assign your copyright to the Free Software Foundation (if anyone
wants to do this, please let me know and I will help).  More
information about both is at:
https://gcc.gnu.org/contribute.html#legal

Last but not least, feel free to raise any question you might have on
an appropriate mailing list (https://gcc.gnu.org/lists.html) or say hi
to us on the gcc development IRC channel
(https://gcc.gnu.org/wiki/GCConIRC).

If you have any concerns or questions regarding the organizational part
of GSoC 2022 or just don't know who else to reach out to, feel free to
contact me throughout the duration of the program.

Once more, congratulations and good luck!

Martin

Re: Welcome GCC GSoC 2022 participants

[Wileam Yonatan Phan via Gcc]

Hi everyone,

Thanks a lot for the quick introduction, Martin! And greetings to my fellow
GSoC contributors: Faisal, Immad, Andrew, Nitin, and Tim. Hoping that we can
get along with each other well! And for the mentors, please be patient with us
as we learn the ropes... :joy:

I'm personally excited for my GSoC project because upon successful completion
of the project, GFortran will be the 2nd compiler to be able to offload DO
CONCURRENT to GPUs after NVIDIA nvfortran. AFAIK currently there are only three
compilers that can process DO CONCURRENT for execution on the CPU (let alone
GPU): gfortran, nvfortran, and Intel ifort.

I'll be honest: this is my first foray deep into compiler technology, and I'm
thankful for this opportunity through GSoC to jump head-first into it. Just
like learning a foreign language, the best way to do it is full immersion in a
native country. It will be a lot of work, but I think I'll enjoy it a lot too.

I will try my best to document my progress on both my personal website at <
https://wyphan.github.io>, at the Fortran Discourse forum thread at
<
https://fortran-lang.discourse.group/t/gsoc-2022-accelerating-fortran-do-concurrent-in-gcc/3269
>, and here through this mailing list.

Wish us luck!

Thanks,
Wil

On Mon, 2022-05-23 at 20:24 +0200, Martin Jambor wrote:
> Hello,
> 
> I am pleased to announce that as many as six contributors will be
> working on GCC Google Summer of Code (GSoC) projects in 2022!  In no
> particular order:
> 
> - Faisal Abbas will be working on "Complete Support for Constant
>   Folding in GCC Rust Front-end." This project will be mentored by
>   Philip Herron.
> 
> - Immad Mir will "Extend GCCs static analyzer to support checking for
>   POSIX file descriptor APIs" and the project will be mentored by
>   David Malcolm.
> 
> - Andrew Naguib will also work on a Rust front-end project, specifically
>   on "Improving debugging experience by enhancing the HIR dump."  The
>   project will be mentored by Arthur Cohen and Philip Herron.
> 
> - Nitin Kumar will "Bypass assembler when generating LTO object files"
>   and in that effort will be mentored by Jan Hubička and myself.
> 
> - Tim Lange will add "New checkers for GCC’s static analyzer" and will
>   be mentored by David Malcolm.
> 
> - Wileam Phan has succeeded with a project on "Accelerating Fortran DO
>   CONCURRENT in GCC."  The mentors will be Tobias Burnus and Thomas
>   Schwinge.
> 
> I'd like to congratulate all of them for putting together very solid
> proposals and wish them best of luck with their projects.
> 
> The GSoC program has now entered its "community bonding period" which
> lasts until June 13th.  During this time you should get in touch with
> your mentors unless you have already done so and probably start
> looking quite a bit more at GCC in general.
> 
> In the initial discussion with your mentors, please take a while to talk
> about the time-frame of your project.  If you are happy with the
> standard one (mid-term evaluation deadline on July 29th, final deadline
> on September 12th) you are all set.  This year the program can however
> also accommodate non-standard schedules within some constraints, see
> suggestions at:
> https://developers.google.com/open-source/gsoc/help/2022-project-dates
> 
> 
> If you want to change the duration of your project, first please reach
> an agreement with your mentor and then email me.
> 
> Because GCC targets many computer platforms, you may also find it very
> useful to get an account on the compile farm so that you can test your
> code on a variety of architectures.  For more details, see
> https://gcc.gnu.org/wiki/CompileFarm
> 
> 
> I'd also like to ask all six accepted contributors to take a few
> minutes to familiarize themselves with the legal pre-requisites that
> we have for contributing.  There are two options.  The much simpler
> one is that copyright remains with you but you provide a "Developer
> Certificate of Origin" for your contributions.  You can do that by
> adding a "Signed-off-by:" tag to all your patches.  The second option
> is to assign your copyright to the Free Software Foundation (if anyone
> wants to do this, please let me know and I will help).  More
> information about both is at:
> https://gcc.gnu.org/contribute.html#legal
> 
> 
> Last but not least, feel free to raise any question you might have on
> an appropriate mailing list (
> https://gcc.gnu.org/lists.html
> ) or say hi
> to us on the gcc development IRC channel
> (
> https://gcc.gnu.org/wiki/GCConIRC
> ).
> 
> If you have any concerns or questions regarding the organizational part
> of GSoC 2022 or just don't know who else to reach out to, feel free to
> contact me throughout the duration of the program.
> 
> Once more, congratulations and good luck!
> 
> Martin
>