Re: seek advice about GCC learning

[Martin Jambor]

Hello Flint,

On Sat, Jan 28 2023, hmsjwzb via Gcc wrote:
> Hi GCC developers,
>
>   I am learning GCC. But the GCC code is hard to understand.

We are delighted you found looking into GCC interesting.  I definitely
agree that GCC source can be hard to read, especially for newcomers but
often even for seasoned contributors when they look at a part they are
not familiar with.  But when you manage to manage to overcome the
difficulty, the project can be very rewarding.  And so not hesitate to
ask us any specific question you may have here on the mailing list or on
IRC.

>   I'm reading the c compiler of GCC. It seems the understanding of
>   AST/GENERIC representation is very important. Is there a tool
>   can visualize the AST/GENERIC representation?

Intermediate representations like GENERIC, GIMPLE and RTL are indeed
fundamental.  In order to see the representation of instructions,
compile a simple program with option -fdump-tree-all and examine the
many files that will appear in your working directory (representation of
things like aggregate data types is unfortunately somewhat missing).

>
>   Do you have some advice for GCC beginner? Is there some documentations 
> can help in the learning of GCC?

David Malcolm wrote a very nice set of tutorials about various aspects
of starting with GCC:
https://gcc-newbies-guide.readthedocs.io/en/latest/

I believe that is the best generic resource there is.

Good luck,

Martin

Re: [PATCH v5 0/5] P1689R5 support

[Ben Boeckel via Gcc]

On Wed, Jan 25, 2023 at 16:06:31 -0500, Ben Boeckel wrote:
> This patch series adds initial support for ISO C++'s [P1689R5][], a
> format for describing C++ module requirements and provisions based on
> the source code. This is required because compiling C++ with modules is
> not embarrassingly parallel and need to be ordered to ensure that
> `import some_module;` can be satisfied in time by making sure that any
> TU with `export import some_module;` is compiled first.
> 
> [P1689R5]: https://isocpp.org/files/papers/P1689R5.html
> 
> I've also added patches to include imported module CMI files and the
> module mapper file as dependencies of the compilation. I briefly looked
> into adding dependencies on response files as well, but that appeared to
> need some code contortions to have a `class mkdeps` available before
> parsing the command line or to keep the information around until one was
> made.
> 
> I'd like feedback on the approach taken here with respect to the
> user-visible flags. I'll also note that header units are not supported
> at this time because the current `-E` behavior with respect to `import
> ;` is to search for an appropriate `.gcm` file which is not
> something such a "scan" can support. A new mode will likely need to be
> created (e.g., replacing `-E` with `-fc++-module-scanning` or something)
> where headers are looked up "normally" and processed only as much as
> scanning requires.
> 
> FWIW, Clang as taken an alternate approach with its `clang-scan-deps`
> tool rather than using the compiler directly.

Ping? It'd be nice to have this supported in at least GCC 14 (since it
missed 13).

Thanks,

--Ben

RISC-V V C Intrinsic API v1.0 release meeting reminder (November 28th, 2022)

[Eop Chen]

Hi all,

A reminder that the next open meeting to discuss on the RISC-V V C Intrinsic 
API v1.0 release is going to
be held later on  2022/02/02 6AM (GMT -7) / 11PM (GMT +8).

The agenda can be found in the second page of the meeting slides (link 
).
Please join the calendar to be constantly notified - Google calender link 
,
 ICal 

We also have a mailing list now hosted by RISC-V International (link 
).

Regards,

eop Chen

Re: [PATCH v5 0/5] P1689R5 support

[Harald Anlauf via Gcc]

Hi Ben,

Am 25.01.23 um 22:06 schrieb Ben Boeckel via Gcc-patches:

Hi,

This patch series adds initial support for ISO C++'s [P1689R5][], a
format for describing C++ module requirements and provisions based on
the source code. This is required because compiling C++ with modules is
not embarrassingly parallel and need to be ordered to ensure that
`import some_module;` can be satisfied in time by making sure that any
TU with `export import some_module;` is compiled first.

[P1689R5]: https://isocpp.org/files/papers/P1689R5.html


while that paper mentions Fortran, the patch in its present version
does not seem to implement anything related to Fortran and does not
touch the gfortran frontend.  Or am I missing anything?  Otherwise,
could you give an example how it would be used with Fortran?

Thus I'd say that it is OK from the gfortran side.

Thanks,
Harald


I've also added patches to include imported module CMI files and the
module mapper file as dependencies of the compilation. I briefly looked
into adding dependencies on response files as well, but that appeared to
need some code contortions to have a `class mkdeps` available before
parsing the command line or to keep the information around until one was
made.

I'd like feedback on the approach taken here with respect to the
user-visible flags. I'll also note that header units are not supported
at this time because the current `-E` behavior with respect to `import
;` is to search for an appropriate `.gcm` file which is not
something such a "scan" can support. A new mode will likely need to be
created (e.g., replacing `-E` with `-fc++-module-scanning` or something)
where headers are looked up "normally" and processed only as much as
scanning requires.

FWIW, Clang as taken an alternate approach with its `clang-scan-deps`
tool rather than using the compiler directly.

Thanks,

--Ben

---
v4 -> v5:

- add dependency tracking for imported modules to `-MF`
- add dependency tracking for static module mapper files given to
   `-fmodule-mapper=`

v3 -> v4:

- add missing spaces between function names and arguments

v2 -> v3:

- changelog entries moved to commit messages
- documentation updated/added in the UTF-8 routine editing

v1 -> v2:

- removal of the `deps_write(extra)` parameter to option-checking where
   ndeeded
- default parameter of `cpp_finish(fdeps_stream = NULL)`
- unification of libcpp UTF-8 validity functions from v1
- test cases for flag parsing states (depflags-*) and p1689 output
   (p1689-*)

Ben Boeckel (5):
   libcpp: reject codepoints above 0x10
   libcpp: add a function to determine UTF-8 validity of a C string
   p1689r5: initial support
   c++modules: report imported CMI files as dependencies
   c++modules: report module mapper files as a dependency

  gcc/c-family/c-opts.cc|  40 +++-
  gcc/c-family/c.opt|  12 +
  gcc/cp/mapper-client.cc   |   4 +
  gcc/cp/mapper-client.h|   1 +
  gcc/cp/module.cc  |  23 +-
  gcc/doc/invoke.texi   |  15 ++
  gcc/testsuite/g++.dg/modules/depflags-f-MD.C  |   2 +
  gcc/testsuite/g++.dg/modules/depflags-f.C |   1 +
  gcc/testsuite/g++.dg/modules/depflags-fi.C|   3 +
  gcc/testsuite/g++.dg/modules/depflags-fj-MD.C |   3 +
  gcc/testsuite/g++.dg/modules/depflags-fj.C|   4 +
  .../g++.dg/modules/depflags-fjo-MD.C  |   4 +
  gcc/testsuite/g++.dg/modules/depflags-fjo.C   |   5 +
  gcc/testsuite/g++.dg/modules/depflags-fo-MD.C |   3 +
  gcc/testsuite/g++.dg/modules/depflags-fo.C|   4 +
  gcc/testsuite/g++.dg/modules/depflags-j-MD.C  |   2 +
  gcc/testsuite/g++.dg/modules/depflags-j.C |   3 +
  gcc/testsuite/g++.dg/modules/depflags-jo-MD.C |   3 +
  gcc/testsuite/g++.dg/modules/depflags-jo.C|   4 +
  gcc/testsuite/g++.dg/modules/depflags-o-MD.C  |   2 +
  gcc/testsuite/g++.dg/modules/depflags-o.C |   3 +
  gcc/testsuite/g++.dg/modules/modules.exp  |   1 +
  gcc/testsuite/g++.dg/modules/p1689-1.C|  18 ++
  gcc/testsuite/g++.dg/modules/p1689-1.exp.json |  27 +++
  gcc/testsuite/g++.dg/modules/p1689-2.C|  16 ++
  gcc/testsuite/g++.dg/modules/p1689-2.exp.json |  16 ++
  gcc/testsuite/g++.dg/modules/p1689-3.C|  14 ++
  gcc/testsuite/g++.dg/modules/p1689-3.exp.json |  16 ++
  gcc/testsuite/g++.dg/modules/p1689-4.C|  14 ++
  gcc/testsuite/g++.dg/modules/p1689-4.exp.json |  14 ++
  gcc/testsuite/g++.dg/modules/p1689-5.C|  14 ++
  gcc/testsuite/g++.dg/modules/p1689-5.exp.json |  14 ++
  gcc/testsuite/g++.dg/modules/test-p1689.py| 222 ++
  gcc/testsuite/lib/modules.exp |  71 ++
  libcpp/charset.cc |  28 ++-
  libcpp/include/cpplib.h   |  12 +-
  libcpp/include/mkdeps.h   |  17 +-
  libcpp/init.cc|  13 +-
  libcpp/internal.h |   2

gcc-10-20230202 is now available

[GCC Administrator via Gcc]

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

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

You'll find:

 gcc-10-20230202.tar.xz   Complete GCC

  SHA256=d8dbf6be7bb87d8f128105b2b7743033dab1cd1b974dc2e4e9f02fe4912a75d5
  SHA1=73cd12890a71c74234d07c53a104fb325a8bbb8a

Diffs from 10-20230126 are available in the diffs/ subdirectory.

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

-Ofast/-ffast-math and SPEC 511.pov miscompilation with gcc 13.0

[Vineet Gupta]

Hi,

I've noticed SPEC 2017, 511.pov failing for RV64 on bleeding edge gcc.
This is with -Ofast -march=rv64gcv_zba_zbb_zbc_zbs.
Problem also happens with -O3 -ffast-math (and goes away with fast-math 
removed)


I've bisected it to b7fd7fb50111 ("frange: drop endpoints to min/max 
representable numbers for -ffinite-math-only")
With that commit evrp is eliding a bunch of if conditions as they 
pertain to inf (in code snippet below, it elides code corresponding to 
lines 1401-1418 with line 1417 being elided causing the failure).


I think I know the answer, but  just wanted to confirm if that is the 
intended behavior given -Ofast / -ffast-math


Thx,
-Vineet


|New->Angle = __builtin_huge_val(); switch(New->Type) ||{ ||... 
||1246: if(Parse_Camera_Mods(New) == false) ||EXIT ||... ||} 1401: 
if (New->Up[X] == __builtin_huge_val|()|) { ... } 1417: if 
(New->Angle != |||__builtin_huge_val|()) ||{ ||1419: if ((New->Type == 
PERSPECTIVE_CAMERA) |||

Re: -Ofast/-ffast-math and SPEC 511.pov miscompilation with gcc 13.0

[Vineet Gupta]

On 2/2/23 15:38, Vineet Gupta wrote:

Hi,

I've noticed SPEC 2017, 511.pov failing for RV64 on bleeding edge gcc.
This is with -Ofast -march=rv64gcv_zba_zbb_zbc_zbs.
Problem also happens with -O3 -ffast-math (and goes away with 
fast-math removed)


I've bisected it to b7fd7fb50111 ("frange: drop endpoints to min/max 
representable numbers for -ffinite-math-only")
With that commit evrp is eliding a bunch of if conditions as they 
pertain to inf (in code snippet below, it elides code corresponding to 
lines 1401-1418 with line 1417 being elided causing the failure).


I think I know the answer, but  just wanted to confirm if that is the 
intended behavior given -Ofast / -ffast-math


Thx,
-Vineet


Apologies, mailer munged the code snippet

    New->Angle = __builtin_huge_val();
...
   switch(New->Type)
   {
...
1246:    if(Parse_Camera_Mods(New) == false)
  EXIT
...
    }

1401:   if (New->Up != __builtin_huge_val())
    {
...
    }

1417:   if (New->Angle != __builtin_huge_val())
    {
1419:   if ((New->Type == PERSPECTIVE_CAMERA) ||
||

Re: [PATCH v5 0/5] P1689R5 support

[Ben Boeckel via Gcc]

On Thu, Feb 02, 2023 at 21:24:12 +0100, Harald Anlauf wrote:
> Am 25.01.23 um 22:06 schrieb Ben Boeckel via Gcc-patches:
> > Hi,
> >
> > This patch series adds initial support for ISO C++'s [P1689R5][], a
> > format for describing C++ module requirements and provisions based on
> > the source code. This is required because compiling C++ with modules is
> > not embarrassingly parallel and need to be ordered to ensure that
> > `import some_module;` can be satisfied in time by making sure that any
> > TU with `export import some_module;` is compiled first.
> >
> > [P1689R5]: https://isocpp.org/files/papers/P1689R5.html
> 
> while that paper mentions Fortran, the patch in its present version
> does not seem to implement anything related to Fortran and does not
> touch the gfortran frontend.  Or am I missing anything?  Otherwise,
> could you give an example how it would be used with Fortran?

Correct. Still trying to put the walls back together after modules
KoolAid Man'd their way into the build graph structure :) . Being able
to drop our Fortran parser (well, we'd have to drop support for Fortran
compilers that exist today…so maybe in 2075 or something) and rely on
compilers to tell us the information would be amazing though :) .

FWIW, the initial revision of the patchset did touch the gfortran
frontend, but the new parameter is now defaulted and therefore the
callsite doesn't need an update anymore. I still thought it worthwhile
to keep the Fortran side aware of what is going on in the space.

The link to Fortran comes up because the build graph problem is
isomorphic (Fortran supports exporting multiple modules from a single
TU, but it's not relevant at the graph level; it's the zero -> any case
that is hard), CMake "solved" it already, and C++ is going to have a
*lot* more "I want to consume $other_project's modules using my favorite
compiler/flags" than seems to happen in Fortran. If you're interested,
this is the paper showing how we do it:

https://mathstuf.fedorapeople.org/fortran-modules/fortran-modules.html

> Thus I'd say that it is OK from the gfortran side.

Eventually we'll like to get gfortran supporting this type of scanning,
but…as above.

Thanks,

--Ben

Re: [PATCH v5 0/5] P1689R5 support

[Andrew Pinski via Gcc]

On Wed, Jan 25, 2023 at 1:07 PM Ben Boeckel via Fortran
 wrote:
>
> Hi,
>
> This patch series adds initial support for ISO C++'s [P1689R5][], a
> format for describing C++ module requirements and provisions based on
> the source code. This is required because compiling C++ with modules is
> not embarrassingly parallel and need to be ordered to ensure that
> `import some_module;` can be satisfied in time by making sure that any
> TU with `export import some_module;` is compiled first.


I like how folks are complaining that GCC outputs POSIX makefile
syntax from GCC's dependency files which are supposed to be in POSIX
Makefile syntax.
It seems like rather the build tools are people like to use are not
understanding POSIX makefile syntax any more rather.
Also I am not a fan of json, it is too verbose for no use. Maybe it is
time to go back to standardizing a new POSIX makefile syntax rather
than changing C++ here.

Thanks,
Andrew Pinski

>
> [P1689R5]: https://isocpp.org/files/papers/P1689R5.html
>
> I've also added patches to include imported module CMI files and the
> module mapper file as dependencies of the compilation. I briefly looked
> into adding dependencies on response files as well, but that appeared to
> need some code contortions to have a `class mkdeps` available before
> parsing the command line or to keep the information around until one was
> made.
>
> I'd like feedback on the approach taken here with respect to the
> user-visible flags. I'll also note that header units are not supported
> at this time because the current `-E` behavior with respect to `import
> ;` is to search for an appropriate `.gcm` file which is not
> something such a "scan" can support. A new mode will likely need to be
> created (e.g., replacing `-E` with `-fc++-module-scanning` or something)
> where headers are looked up "normally" and processed only as much as
> scanning requires.
>
> FWIW, Clang as taken an alternate approach with its `clang-scan-deps`
> tool rather than using the compiler directly.
>
> Thanks,
>
> --Ben
>
> ---
> v4 -> v5:
>
> - add dependency tracking for imported modules to `-MF`
> - add dependency tracking for static module mapper files given to
>   `-fmodule-mapper=`
>
> v3 -> v4:
>
> - add missing spaces between function names and arguments
>
> v2 -> v3:
>
> - changelog entries moved to commit messages
> - documentation updated/added in the UTF-8 routine editing
>
> v1 -> v2:
>
> - removal of the `deps_write(extra)` parameter to option-checking where
>   ndeeded
> - default parameter of `cpp_finish(fdeps_stream = NULL)`
> - unification of libcpp UTF-8 validity functions from v1
> - test cases for flag parsing states (depflags-*) and p1689 output
>   (p1689-*)
>
> Ben Boeckel (5):
>   libcpp: reject codepoints above 0x10
>   libcpp: add a function to determine UTF-8 validity of a C string
>   p1689r5: initial support
>   c++modules: report imported CMI files as dependencies
>   c++modules: report module mapper files as a dependency
>
>  gcc/c-family/c-opts.cc|  40 +++-
>  gcc/c-family/c.opt|  12 +
>  gcc/cp/mapper-client.cc   |   4 +
>  gcc/cp/mapper-client.h|   1 +
>  gcc/cp/module.cc  |  23 +-
>  gcc/doc/invoke.texi   |  15 ++
>  gcc/testsuite/g++.dg/modules/depflags-f-MD.C  |   2 +
>  gcc/testsuite/g++.dg/modules/depflags-f.C |   1 +
>  gcc/testsuite/g++.dg/modules/depflags-fi.C|   3 +
>  gcc/testsuite/g++.dg/modules/depflags-fj-MD.C |   3 +
>  gcc/testsuite/g++.dg/modules/depflags-fj.C|   4 +
>  .../g++.dg/modules/depflags-fjo-MD.C  |   4 +
>  gcc/testsuite/g++.dg/modules/depflags-fjo.C   |   5 +
>  gcc/testsuite/g++.dg/modules/depflags-fo-MD.C |   3 +
>  gcc/testsuite/g++.dg/modules/depflags-fo.C|   4 +
>  gcc/testsuite/g++.dg/modules/depflags-j-MD.C  |   2 +
>  gcc/testsuite/g++.dg/modules/depflags-j.C |   3 +
>  gcc/testsuite/g++.dg/modules/depflags-jo-MD.C |   3 +
>  gcc/testsuite/g++.dg/modules/depflags-jo.C|   4 +
>  gcc/testsuite/g++.dg/modules/depflags-o-MD.C  |   2 +
>  gcc/testsuite/g++.dg/modules/depflags-o.C |   3 +
>  gcc/testsuite/g++.dg/modules/modules.exp  |   1 +
>  gcc/testsuite/g++.dg/modules/p1689-1.C|  18 ++
>  gcc/testsuite/g++.dg/modules/p1689-1.exp.json |  27 +++
>  gcc/testsuite/g++.dg/modules/p1689-2.C|  16 ++
>  gcc/testsuite/g++.dg/modules/p1689-2.exp.json |  16 ++
>  gcc/testsuite/g++.dg/modules/p1689-3.C|  14 ++
>  gcc/testsuite/g++.dg/modules/p1689-3.exp.json |  16 ++
>  gcc/testsuite/g++.dg/modules/p1689-4.C|  14 ++
>  gcc/testsuite/g++.dg/modules/p1689-4.exp.json |  14 ++
>  gcc/testsuite/g++.dg/modules/p1689-5.C|  14 ++
>  gcc/testsuite/g++.dg/modules/p1689-5.exp.json |  14 ++
>  gcc/testsuite/g++.dg/modules/test-p1689.py| 222 ++
>  gcc/testsuite/lib/modules.exp |  71 ++
>  libcpp/charset.c

Re: -Ofast/-ffast-math and SPEC 511.pov miscompilation with gcc 13.0

[Richard Biener via Gcc]

On Fri, Feb 3, 2023 at 12:39 AM Vineet Gupta  wrote:
>
> Hi,
>
> I've noticed SPEC 2017, 511.pov failing for RV64 on bleeding edge gcc.
> This is with -Ofast -march=rv64gcv_zba_zbb_zbc_zbs.
> Problem also happens with -O3 -ffast-math (and goes away with fast-math
> removed)
>
> I've bisected it to b7fd7fb50111 ("frange: drop endpoints to min/max
> representable numbers for -ffinite-math-only")
> With that commit evrp is eliding a bunch of if conditions as they
> pertain to inf (in code snippet below, it elides code corresponding to
> lines 1401-1418 with line 1417 being elided causing the failure).
>
> I think I know the answer, but  just wanted to confirm if that is the
> intended behavior given -Ofast / -ffast-math

It's the intended behavior of -ffinite-math-only which is part of
-Ofast / -ffast-math.  There's a CLOSED INVALID bug in bugzilla
about the povray failure as well.

Richard.

> Thx,
> -Vineet
>
>
> |New->Angle = __builtin_huge_val(); switch(New->Type) ||{ ||...
> ||1246: if(Parse_Camera_Mods(New) == false) ||EXIT ||... ||} 1401:
> if (New->Up[X] == __builtin_huge_val|()|) { ... } 1417: if
> (New->Angle != |||__builtin_huge_val|()) ||{ ||1419: if ((New->Type ==
> PERSPECTIVE_CAMERA) |||