help with uninstalling gcc

[Diego Pardo via Gcc]

Hi,I've installed gcc 8, how can I uninstall it?
RegardsDiego Pardo

Re: Question about comparing function function decls

[Richard Biener via Gcc]

On Thu, Jun 4, 2020 at 10:24 PM Gary Oblock via Gcc  wrote:
>
> 
>
>
>
> I'm trying to determine during LTO optimization (with one partition)
> whether of not a function call is to a function in the partition.
>
> Here is the routine I've written. Note, I'm willing to admit up front
> that the comparison below ( ) is probably dicey.

I think you should simply lookup the callgraph edge for the call_stmt
in the caller via caller_graph_node->get_edge (call_stmt).

> ---
> static bool
> is_user_function ( gimple *call_stmt)
> {
>   tree fndecl = gimple_call_fndecl ( call_stmt);
>
>   DEBUG_L("is_user_function: decl in: %p,", fndecl);
>   DEBUG_F( print_generic_decl, stderr, fndecl, (dump_flags_t)-1);
>   DEBUG("\n");
>   INDENT(2);
>
>   cgraph_node* node;
>   bool ret_val = false;
>   FOR_EACH_FUNCTION_WITH_GIMPLE_BODY ( node)
>   {
> DEBUG_L("decl %p,", node->decl);
> DEBUG_F( print_generic_decl, stderr, node->decl, (dump_flags_t)-1);
> DEBUG("\n");
>
> if ( node->decl == fndecl )
>   {
> ret_val = true;
> break;
>   }
>   }
>
>   INDENT(-2);
>   return ret_val;
> }
> ---
>
> Here's the test program I was compiling.
>
> -- aux.h --
> #include "stdlib.h"
> typedef struct type type_t;
> struct type {
>   int i;
>   double x;
> };
>
> #define MAX(x,y) ((x)>(y) ? (x) : (y))
>
> extern int max1( type_t *, size_t);
> extern double max2( type_t *, size_t);
> extern type_t *setup( size_t);
> -- aux.c --
> #include "aux.h"
> #include "stdlib.h"
>
> type_t *
> setup( size_t size)
> {
>   type_t *data = (type_t *)malloc( size * sizeof(type_t));
>   size_t i;
>   for( i = 0; i < size; i++ ) {
> data[i].i = rand();
> data[i].x = drand48();
>   }
>   return data;
> }
>
> int
> max1( type_t *array, size_t len)
> {
>   size_t i;
>   int result = array[0].i;
>   for( i = 1; i < len; i++  ) {
> result = MAX( array[i].i, result);
>   }
>   return result;
> }
>
> double
> max2( type_t *array, size_t len)
> {
>   size_t i;
>   double result = array[0].x;
>   for( i = 1; i < len; i++  ) {
> result = MAX( array[i].x, result);
>   }
>   return result;
> }
> -- main.c -
> #include "aux.h"
> #include "stdio.h"
>
> type_t *data1;
>
> int
> main(void)
> {
>   type_t *data2 = setup(200);
>   data1 = setup(100);
>
>   printf("First %d\n" , max1(data1,100));
>   printf("Second %e\n", max2(data2,200));
> }
> ---
>
> The output follows:
>
> ---
> L# 1211: is_user_function: decl in: 0x7f078461be00,  static intD. 
> max1D. (struct type_t *, size_t);
> L# 1222:   decl 0x7f078462,  static struct type_t * setupD. (size_t);
> L# 1222:   decl 0x7f078461bf00,  static intD. max1.constprop.0D. 
> (struct type_t *);
> L# 1222:   decl 0x7f078461bd00,  static doubleD. max2.constprop.0D. 
> (struct type_t *);
> L# 1222:   decl 0x7f078461bb00,  static intD. mainD. (void);
> ---
>
> Now it's pretty obvious that constant propagation decided the size_t
> len arguments to max1 and max2 were no longer needed. However, the
> function declaration information on the calls to them weren't updated
> so they'll never match. Now if there is another way to see if the
> function is in the partition or if there is some other way to compare
> the functions in a partition, please let me know.
>
> Thanks,
>
> Gary Oblock
> Ampere Computing
>
> PS. The body of the message is attached in a file because my email program
> (Outlook) mangled the above.
>
>
>
> 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 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.

gcc math functions for OpenMP vectoization

[Feltgen, Eric]

Hi there,


my name is Eric, I'm a german student at RWTH Aachen University currently 
researching OpenMP.


For my research, I'm also looking at math functions provided by compilers like 
GCC. When writing vectorizable code, it is important to use math functions 
which also allow for vectorization. I've read that gcc includes a set of math 
functions which are SIMD compatible. Where can I find resources on them?


It would be awesome if you could tell me where to find documentation.


Thanks in advance, I highly appreciate your support.


Best regards,


Eric

Re: gcc math functions for OpenMP vectoization

[Jakub Jelinek via Gcc]

On Fri, Jun 05, 2020 at 01:58:55PM +, Feltgen, Eric wrote:
> my name is Eric, I'm a german student at RWTH Aachen University currently 
> researching OpenMP.
> 
> 
> For my research, I'm also looking at math functions provided by compilers 
> like GCC. When writing vectorizable code, it is important to use math 
> functions which also allow for vectorization. I've read that gcc includes a 
> set of math functions which are SIMD compatible. Where can I find resources 
> on them?
> 
> 
> It would be awesome if you could tell me where to find documentation.

It is glibc that provides them, not GCC.
See 
https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/x86/fpu/bits/math-vector.h;h=0801905da7b85e2f43fb6b682a7b84c5eec469d4;hb=HEAD
for the header file and the functions are then implemented (mostly?) in 
assembly in
e.g. /usr/src/libc/sysdeps/x86_64/fpu/ directory.  There is similar support
for aarch64.
All that is provided by GCC is -fopenmp #pragma omp declare simd support
and support for corresponding simd attribute (which is what is used if
-fopenmp is not enabled).

Jakub

AArch64 failures on tester

[Alex Coplan]

Hello,

Recently Jeff's tester picked up some test failures on AArch64. These
are now fixed as of commit ab563903 but the aarch64-linux-gnu build is
still failing with the following output:

  Old tests that failed, that have disappeared (8 tests): (Eeek!)
  
  g++.dg/warn/Wtype-limits-Wextra.C  -std=gnu++14  (test for bogus messages, 
line 61)
  g++.dg/warn/Wtype-limits-Wextra.C  -std=gnu++17  (test for bogus messages, 
line 61)
  g++.dg/warn/Wtype-limits-Wextra.C  -std=gnu++2a  (test for bogus messages, 
line 61)
  g++.dg/warn/Wtype-limits-Wextra.C  -std=gnu++98  (test for bogus messages, 
line 61)
  g++.dg/warn/Wtype-limits.C  -std=gnu++14  (test for bogus messages, line 61)
  g++.dg/warn/Wtype-limits.C  -std=gnu++17  (test for bogus messages, line 61)
  g++.dg/warn/Wtype-limits.C  -std=gnu++2a  (test for bogus messages, line 61)
  g++.dg/warn/Wtype-limits.C  -std=gnu++98  (test for bogus messages, line 61)
  
  ## Differences found: 
  # 1 differences in 10 common sum files found
  Build step 'Execute shell' marked build as failure
  Archiving artifacts
  Finished: FAILURE

This seems like a non-issue. Does something need to be manually updated
to make the build go green again here?

Thanks,
Alex

Re: help with uninstalling gcc

[Jonathan Wakely via Gcc]

On Fri, 5 Jun 2020 at 10:12, Diego Pardo via Gcc  wrote:
>
> Hi,I've installed gcc 8, how can I uninstall it?

That depends how you installed it, and you've told us nothing useful
that would allow us to help you.

But in any case, please direct this question to the
gcc-h...@gcc.gnu.org list where it is appropriate. This list is for
discussing development of GCC itself, not for help using or installing
it, or uninstalling it.

Re: gcc math functions for OpenMP vectoization

[Tobias Burnus]

On 6/5/20 4:11 PM, Jakub Jelinek via Gcc wrote:

It is glibc that provides them, not GCC.
See 
https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/x86/fpu/bits/math-vector.h;h=0801905da7b85e2f43fb6b682a7b84c5eec469d4;hb=HEAD


Minor addition: That header file is included in math.h, i.e. automatically 
available.
For Fortran/gfortran there is math-vector-fortran.h (also provided by glibc)
which has the same functions and a similar effect.

Cheers,

Tobias

-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander 
Walter

Re: gcc math functions for OpenMP vectoization

[Toon Moene]

On 6/5/20 6:10 PM, Tobias Burnus wrote:


On 6/5/20 4:11 PM, Jakub Jelinek via Gcc wrote:



It is glibc that provides them, not GCC.
See 
https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/x86/fpu/bits/math-vector.h;h=0801905da7b85e2f43fb6b682a7b84c5eec469d4;hb=HEAD 



Minor addition: That header file is included in math.h, i.e. 
automatically available.
For Fortran/gfortran there is math-vector-fortran.h (also provided by 
glibc)

which has the same functions and a similar effect.


I wonder if there are Linux distributions where this actually effected 
already.


I know for sure that it is not in Debian Testing (as of two weeks ago) 
and Red Hat Fedora 30 (similarly).


Do you know of any ?

Kind regards,

--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands

Re: gcc math functions for OpenMP vectoization

[Richard Biener via Gcc]

On June 5, 2020 7:58:20 PM GMT+02:00, Toon Moene  wrote:
>On 6/5/20 6:10 PM, Tobias Burnus wrote:
>
>> On 6/5/20 4:11 PM, Jakub Jelinek via Gcc wrote:
>
>>> It is glibc that provides them, not GCC.
>>> See 
>>>
>https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/x86/fpu/bits/math-vector.h;h=0801905da7b85e2f43fb6b682a7b84c5eec469d4;hb=HEAD
>
>>>
>> 
>> Minor addition: That header file is included in math.h, i.e. 
>> automatically available.
>> For Fortran/gfortran there is math-vector-fortran.h (also provided by
>
>> glibc)
>> which has the same functions and a similar effect.
>
>I wonder if there are Linux distributions where this actually effected 
>already.
>
>I know for sure that it is not in Debian Testing (as of two weeks ago) 
>and Red Hat Fedora 30 (similarly).
>
>Do you know of any ?

It works in openSUSE Tumbleweed at least.

Richard. 

>
>Kind regards,

Re: gcc math functions for OpenMP vectoization

[Jonathan Wakely via Gcc]

On Fri, 5 Jun 2020 at 18:59, Toon Moene  wrote:
>
> On 6/5/20 6:10 PM, Tobias Burnus wrote:
>
> > On 6/5/20 4:11 PM, Jakub Jelinek via Gcc wrote:
>
> >> It is glibc that provides them, not GCC.
> >> See
> >> https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/x86/fpu/bits/math-vector.h;h=0801905da7b85e2f43fb6b682a7b84c5eec469d4;hb=HEAD
> >>
> >
> > Minor addition: That header file is included in math.h, i.e.
> > automatically available.
> > For Fortran/gfortran there is math-vector-fortran.h (also provided by
> > glibc)
> > which has the same functions and a similar effect.
>
> I wonder if there are Linux distributions where this actually effected
> already.
>
> I know for sure that it is not in Debian Testing (as of two weeks ago)
> and Red Hat Fedora 30 (similarly).

Fedora 30 is EOL.

> Do you know of any ?

Fedora 31 and 32.

Re: AArch64 failures on tester

[Jeff Law via Gcc]

On Fri, 2020-06-05 at 14:27 +, Alex Coplan wrote:
> Hello,
> 
> Recently Jeff's tester picked up some test failures on AArch64. These
> are now fixed as of commit ab563903 but the aarch64-linux-gnu build is
> still failing with the following output:
> 
>   Old tests that failed, that have disappeared (8 tests): (Eeek!)
>   
>   g++.dg/warn/Wtype-limits-Wextra.C  -std=gnu++14  (test for bogus messages, 
> line 61)
>   g++.dg/warn/Wtype-limits-Wextra.C  -std=gnu++17  (test for bogus messages, 
> line 61)
>   g++.dg/warn/Wtype-limits-Wextra.C  -std=gnu++2a  (test for bogus messages, 
> line 61)
>   g++.dg/warn/Wtype-limits-Wextra.C  -std=gnu++98  (test for bogus messages, 
> line 61)
>   g++.dg/warn/Wtype-limits.C  -std=gnu++14  (test for bogus messages, line 61)
>   g++.dg/warn/Wtype-limits.C  -std=gnu++17  (test for bogus messages, line 61)
>   g++.dg/warn/Wtype-limits.C  -std=gnu++2a  (test for bogus messages, line 61)
>   g++.dg/warn/Wtype-limits.C  -std=gnu++98  (test for bogus messages, line 61)
That will not cause the tester to fail.  It only cares about regressions, ie
something that passed before, but fails now.

I'd like to flip it to fail for stuff like you've shown above, but we're having
enough trouble keeping things green when only looking at regressions :(

jeff

Re: GSoC: OMPD conversation

[y2s1982 . via Gcc]

Hello,

On Thu, Jun 4, 2020 at 6:54 PM Martin Jambor  wrote:

> Hi,
>
> On Sun, May 31 2020, y2s1982 . wrote:
> > Hello team,
> >
> > I just wanted to give an update to my current progress. I spent most of
> the
> > time looking over OMPD documentation again and studying LLVM's approach
> to
> > it.
> >
>
> thanks a lot, sorry about replying this late again, unfortunately I
> missed your email on Monday and only noticed it yesterday.
>

> [...]
>
> >>
> >> 1) We are used to reviewing patches in our email clients and prefer it
> >>to reviews in web-based tools.  I have quite a lot of customizations
> >>in place that I am used to and so prefer it to
> >>one-method-fits-everyone web tools.
> >>
> > I understand. This kind of information is exactly what I wanted to know
> so
> > I can adjust my work process to fit the community needs. My I follow the
> > above process of making PR but also create a patch using 'git diff'
> command
> > and share that with the mailing list?
>
> yeah, sure, although I think people usually use git format-patch.
>

Oh okay. This is the exact kind of information I was looking for :D.  I was
looking at the command, too, but I wasn't sure how exactly to use it. I
will look more into it and learn.

>
> > In an effort to understand how I might go about starting the OMPD
> project,
> > I spent some time studying LLVM's attempt. Following are my findings and
> > some questions.
> >
> > The LLVM's repository for OMPD development is at this github repo
> > ,
> > under the branch ompd-test.
> > The OMPD documentation
> > 
> states
> > that the omp-tools.h be available.
>
> I believe it is
> https://github.com/OpenMP/sources/blob/master/include/omp-tools.h
>
> It should be referenced somewhere from the openmp.org but possibly
> actually isn't.
>

Hmm, does this mean the file should be or is already imported via autoconf?
I also assume I should have at least a dummy definition for all declared
prototypes when the header file is included.


>
> > The closest thing to this I found
> > was in this
> > .var file
> > <
> https://github.com/OpenMPToolsInterface/LLVM-openmp/blob/ompd-tests/runtime/src/include/50/omp-tools.h.var
> >,
> > though I am not familiar enough to understand how this translate to
> > omp-tools.h file later.  After this, things got a little more
> interesting.
> > First, they seem to be using GNU gdb as the debugger. From there, their
> older
> > attempt
> > <
> https://github.com/OpenMPToolsInterface/LLVM-openmp/tree/ompd-tests/libompd/gdb-wrapper
> >,
> > stored
> > in a folder called "gdb-wrapper", seems to work around with creating a
> > C/C++ wrapper. This seems to be in the process of being replaced with
> > gdb-plugin idea, as represented in this git issue
> >  and
> their
> > current CMakeList.txt
> > <
> https://github.com/OpenMPToolsInterface/LLVM-openmp/blob/ompd-tests/libompd/CMakeLists.txt
> >.
> > The gdb-plugin
> > <
> https://github.com/OpenMPToolsInterface/LLVM-openmp/tree/ompd-tests/libompd/gdb-plugin
> >
> > seems
> > to rely on python to implement OMPD.
>
> So by now you may know quite a bit more about LLVM's OMPD effort than I
> do but it rather seems like they use the python gdb scripts to call into
> a python module written in C - which in term uses OMPD interface to get
> information about the debugged program - in order to provide the user
> with useful OpenMP context.  I only looked at them quickly but they do
> not look anything like an implementation.
>
>
Yes, they do call gdb via Python. I wasn't sure if that's what I was
supposed to do or not.
Good thing you clarified that for me just now :D


>
> > For example, other than the fact that
> > most of the code in the folder is written in python, the ompdModule.c's
> > _read()
> > <
> https://github.com/OpenMPToolsInterface/LLVM-openmp/blob/3b6c06e354ef1e59da22778a9033d87ed0e3b19d/libompd/gdb-plugin/ompdModule.c#L504-L534
> >,
> > which corresponds to ompd_callback_memory_read_fn_t typedef
> > <
> https://www.openmp.org/spec-html/5.0/openmpsu209.html#x264-17550005.4.3.2>
> > defined
> > in the OMPD documentation, creates and manipulates PyObject throughout
> the
> > function implementation.
>
> Right.  But looking at the python scripts I really tend to think they
> are simply OMPD users.
>

> >
> > I am left with a couple of questions:
> > First of all, they seem to be working with gdb to provide OMPD solution
> in
> > forms of wrapper/plugin. Can we use this code, too? What kind of issues
> do
> > we have with licensing?
>
> We do take the sanitizer run-time library code from LLVM upstream, so I
> think it is possible, in principle.  but...
>
> >
> > Secondly, the LLVM team started from C/C++ wrapper and moved on to Python
> > implementation.
>
> ...again, maybe I'm misunderstanding you, but

Re: GSoC: OMPD conversation

[Jakub Jelinek via Gcc]

On Fri, Jun 05, 2020 at 03:13:42PM -0400, y2s1982 . wrote:
> > > The LLVM's repository for OMPD development is at this github repo
> > > ,
> > > under the branch ompd-test.
> > > The OMPD documentation
> > > 
> > states
> > > that the omp-tools.h be available.
> >
> > I believe it is
> > https://github.com/OpenMP/sources/blob/master/include/omp-tools.h
> >
> > It should be referenced somewhere from the openmp.org but possibly
> > actually isn't.
> >
> 
> Hmm, does this mean the file should be or is already imported via autoconf?

No.  We need our version of omp-tools.h in libgomp/ directory, which has
roughly the same content as the one from the OpenMP/sources repo, and
cross-checked against what the LLVM omp-tools.h.var contains, but with the
omp.h.in code formatting, similar style of multiple inclusion guard, license
boilerplate, the __GOMP_NOTHROW macros etc.

I think that should be your first coding task, the next one would be to
tweak libgomp/Makefile.am so that it also builds the libgompd shared
library, initially just containing a single function or two from the
interfaces and then you'd start adding further ones.

And yes, we'll need to also test it, which can be done by using gdb
with some python scripts that will load either libgomp.so directly shared 
library or
perhaps some wrapper library that will make it usable from python.

> This week, I spent more time on understanding libgomp and gimple.
> For libgomp, I started from the GOMP_parallel() and followed a chain of
> function calls, macros, and various structs used. The structs were the most
> interesting of the three, and I still feel I have much to digest.
> 
> I also spent a few days looking at gimple. Just to be sure, is the
> following progression correct?
> .gimple -> ... -> .omplower -> ompexp -> ompexpssa2 -> ... -> optimized
> The style of code seems to transition a bit between omplower and ompexp.
> 
> Between the gimple documentation and just reading through the gimple files,
> I think I have a rough understanding of how things go. I do have few
> questions, likely with much more to come:
> 1. When compiling for-1.C test file with -fdump-tree-all, I came across the
> variable declaration like this in .gimple file: struct I & D.3626;
> In C++, I would think that's some sort of reference, but then it would need
> to be defined at declaration.
> The declaration disappears in .omplower though the variable is still used.
> 
> 2. When compiling taskloop-5.C with the same flag, in .gimple file, I saw a
> for loop that seems to appear twice.
> 
> Original:
>   #pragma omp taskloop firstprivate (b, f)
> for (int i = 0; i < 30; i++)
>   {
> 
> .gimple:
>   #pragma omp taskloop private(D.2631)
>   for (D.2631 = 0; D.2631 < 30; D.2631 = D.2631 + 1)
>   {
>  {
>#pragma omp taskloop firstprivate(f) firstprivate(b)
> private(i)
> {
>   #pragma omp taskloop
>   for (i = 0; i < 30; i = i + 1)
>   {
> I was hoping someone could explain why this happened so I can better
> understand how libgomp broke down the problem.

This is just a temporary way how to express the taskloop complexity until
ompexp is done with it.  For taskloop, we need to be able to compute the
number of iterations in the encountering thread, which is what is
represented by the outer taskloop, then it behaves as an explicit task (many
of them in fact), for which we need the data sharing effects of it,
that is the middle construct which actually is really the same GIMPLE as
explicit task, just with an extra flag, and finally we need something in the
task that will iterate on all the iterations that were assigned to the task,
make sure the iteration variable is properly initialized etc., and that is
represented by the innermost taskloop.

What you care more about is what the ompexp dump looks like (or optimized
dump).

Jakub

gcc-9-20200605 is now available

[GCC Administrator via Gcc]

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

You'll find:

 gcc-9-20200605.tar.xzComplete GCC

  SHA256=5da9903a85775f35505f70c7da88a771da7e62f9786b733867e30ff7520f87ee
  SHA1=7f0822bf8ea4d57f2c4bb6a1cffc3b5291158df1

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

Max Filippov appointed Xtensa maintainer

[David Edelsohn]

I am pleased to announce that the GCC Steering Committee has
appointed Max Filippov as Xtensa maintainer.

Please join me in congratulating Max on his new role.
Max, please update your listing in the MAINTAINERS file.

Happy hacking!
David