[RFC] gcov: illogical option names

[Martin Liška]

Hey.

Historically, I made some illogical changes to options:

in GCC 8.x I added:

-j, --human-readable - I should have selected likely -H

in GCC 9.x I renamed:

-i, --intermediate-format
to:
-i, --json-format

So I preserved the short option name for a new intermediate format.
But it does not correspond to first letter of --json-format.

Thoughts how to clean the confusion?
Thanks,
Martin

Re: Use gcov for line coverage info of GIMPLE code

[Martin Liška]

On 6/18/20 4:31 AM, Shuai Wang wrote:

Hey Martin,

Thanks a lot for the info. I tried to play with __sanitizer_cov_trace_pc but 
still quite confused on whether it can instrument extra basic blocks introduced 
by ASAN. Let me present the GIMPLE code for your reference:


Probably not. My suggestion was to make the instrumentation by your own (and 
not using -fsanitize-coverage=trace-pc).

Martin



Given the following C code:

int main(int argc ,char **argv)
{
         int stack_array[100];
         stack_array[1] = 100;
         int c1 = stack_array[argc + 12];  <--- ASAN
         if (argc > 12){
                 int c3 = stack_array[argc + 17];   <--- ASAN
         }
}

I use the following way of compiling:

|trace.o: trace.c $(CC) -c -o $@ $< test.o: test.c $(CC) ||*-fdump-tree-all*||-g 
-O0 -fsanitize=address -c -o $@ $< $(CFLAGS) $(LIBS) test : $(OBJ) $(CC) -g -O0 
-fsanitize=address -o $@ $^ $(CFLAGS) $(LIBS)|


I note in the dumped IR code: test.c.223t.sanopt, I do find 
`__builtin___sanitizer_cov_trace_pc` in the if condition of the original C 
code; however, there was no __builtin___sanitizer_cov_trace_pc in the if 
branches corresponding to sanitizer checks:

|if (_32 != 0) goto ; [0.04%] else goto ; [99.96%]  [0.00%]: 
__builtin___asan_report_store4 (_22);  [0.00%]: stack_array[1] = 100; _1 = argc_6(D) + 12; _17 
= &stack_array[_1]; _33 = (unsigned long) _17; |

It seems that -fsanitize-coverage=trace-pc still happens before 
-fsanitize=address. Is it how it's supposed to be? Thanks a lot!

Best,
Shuai

On Wed, Jun 17, 2020 at 3:03 PM Martin Liška mailto:mli...@suse.cz>> wrote:

On 6/17/20 8:57 AM, Shuai Wang wrote:
 > Hello Martin,
 >
 > The issue is that I want to count the coverage of "true/false" branches 
taken in sanitizer's if conditions..

I see. Well, you may abuse a bit the existing:

         -fsanitize-coverage=trace-pc
             Enable coverage-guided fuzzing code instrumentation.  Inserts a call to 
"__sanitizer_cov_trace_pc" into every basic block.

And put corresponding builtins to the true/false branches in the 
instrumented code.

Martin

 >
 > Best,
 > Shuai
 >
 > On Wed, Jun 17, 2020 at 2:52 PM Martin Liška mailto:mli...@suse.cz> 
>> wrote:
 >
 >     On 6/17/20 5:40 AM, Shuai Wang via Gcc wrote:
 >      > Hello,
 >      >
 >
 >     Hello.
 >
 >     Right now, coverage information reports line execution of statements 
that
 >     are present in the original source code.
 >
 >     Can you make a mapping of the instrumented code to statements that 
are present
 >     in the original source code?
 >
 >     Martin
 >
 >      > I am aware of how to use gcov for c code line coverage 
collection. However,
 >      > currently I am working on a piece of GIMPLE code (did some 
instrumentation
 >      > on the GIMPLE code and therefore is more complex compared to the 
original C
 >      > code)l, and would like to collect the line coverage info of 
GIMPLE code
 >      > with gcov. Is it possible to do so? If so, could anyone shed some 
light on
 >      > this? Thank you very much.
 >      >
 >      > Best,
 >      > Shuai
 >      >
 >

Please put vim swap files into gitignore

[Thomas Koenig via Gcc]

Hi,

I just found a few unversioned files called .intrinsic.c.swp and
similar in my "git status" output.

Could somebody please put .*.swp into .gitignore?  I'm sure this
would save at least 10 reverts :-)

Regards

Thomas

Re: Please put vim swap files into gitignore

[Jonathan Wakely via Gcc]

On Thu, 18 Jun 2020 at 19:22, Thomas Koenig via Gcc  wrote:
>
> Hi,
>
> I just found a few unversioned files called .intrinsic.c.swp and
> similar in my "git status" output.
>
> Could somebody please put .*.swp into .gitignore?  I'm sure this
> would save at least 10 reverts :-)

You can just add it to .git/info/exclude in your own clone.

Re: Please put vim swap files into gitignore

[Joel Sherrill]

On Thu, Jun 18, 2020 at 1:34 PM Jonathan Wakely via Gcc 
wrote:

> On Thu, 18 Jun 2020 at 19:22, Thomas Koenig via Gcc 
> wrote:
> >
> > Hi,
> >
> > I just found a few unversioned files called .intrinsic.c.swp and
> > similar in my "git status" output.
> >
> > Could somebody please put .*.swp into .gitignore?  I'm sure this
> > would save at least 10 reverts :-)
>
> You can just add it to .git/info/exclude in your own clone.
>

Or have a personal ~/.gitignore_global for all projects. Here is mine.

$ cat ~/.gitignore_global
*.o
*.swp
*~
*.gcno
changes-xxx
cscope.out

Here is the section in ~/.gitconfig to enable it and a couple of other
handy things.

[core]
excludesfile = /home/joel/.gitignore_global
whitespace = trailing-space,space-before-tab
pager = less -R

Git is magic and full of options!

--joel
RTEMS

Re: Please put vim swap files into gitignore

[Andrew Stubbs]

On 18/06/2020 19:20, Thomas Koenig via Gcc wrote:

Hi,

I just found a few unversioned files called .intrinsic.c.swp and
similar in my "git status" output.

Could somebody please put .*.swp into .gitignore?  I'm sure this
would save at least 10 reverts :-)


I have this in my .vimrc to keep such junk out of my working directories.

" Keep .swp files all in one place
set dir=~/tmp
" same for undo files
set undodir=~/tmp
set undofile

Andrew

Re: Please put vim swap files into gitignore

[Thomas Koenig via Gcc]

Am 18.06.20 um 20:34 schrieb Jonathan Wakely via Gcc:

On Thu, 18 Jun 2020 at 19:22, Thomas Koenig via Gcc  wrote:


Hi,

I just found a few unversioned files called .intrinsic.c.swp and
similar in my "git status" output.

Could somebody please put .*.swp into .gitignore?  I'm sure this
would save at least 10 reverts :-)


You can just add it to .git/info/exclude in your own clone.


The same argument goes for the emacs files, do you suggest we
remove them from .gitignore? :-)

Seriously, while a personal solution will work for me personally,
I don't suppose that I am the only person ever to visit a file
in the Gcc source tree with vim.

Regards

Thomas

Re: Please put vim swap files into gitignore

[Jonathan Wakely via Gcc]

On Thu, 18 Jun 2020 at 20:34, Thomas Koenig  wrote:
>
> Am 18.06.20 um 20:34 schrieb Jonathan Wakely via Gcc:
> > On Thu, 18 Jun 2020 at 19:22, Thomas Koenig via Gcc  wrote:
> >>
> >> Hi,
> >>
> >> I just found a few unversioned files called .intrinsic.c.swp and
> >> similar in my "git status" output.
> >>
> >> Could somebody please put .*.swp into .gitignore?  I'm sure this
> >> would save at least 10 reverts :-)
> >
> > You can just add it to .git/info/exclude in your own clone.
>
> The same argument goes for the emacs files, do you suggest we
> remove them from .gitignore? :-)
>
> Seriously, while a personal solution will work for me personally,
> I don't suppose that I am the only person ever to visit a file
> in the Gcc source tree with vim.

You could propose a patch for .gitignore on the gcc-patches list, like
any other change to the source tree.

[OMPD] regarding const char **ompd_dll_locations

[y2s1982 . via Gcc]

Hello everyone,

I would like to share some of my thoughts and seek some opinions on coding
for const char **ompd_dll_locations.

After reviewing the documentation
, looking over LLVM
approach

as a reference, looking around in GCC code base, and searching around for
similar cases and their solutions, I have just a few more questions before
finally putting down some unit tests and code.

- This post
seems
to use compiler macro to rely on the compiler to suggest architecture,
including 32bit and 64bit. I found some macro in gcc/config/i386/i386.h
that seems relevant. Is this an acceptable approach? If yes, which header
should I use? If not, should I then compare byte size of int and decide
from there?

- I did some digging around to find conventional library location.  One of
the issue, however, is that my Linux x86 64bit machine is currently down
for repair. I checked in my FreeBSD x86 64bit machine, which suggested
/usr/lib for 64bit library and /usr/lib32 for 32bit library, and my
raspberry pi Linux 64bit ARM, which suggested /usr/lib/aarch64-linux-gnu
for 64bit library. At the moment, I assumed I would keep the scope small
and stay with x86 machine's 32bit and 64bit machines, but I wasn't sure
what would be the best path to put in that would accommodate all machines.
I haven't even looked into Windows, although I assume it's likely
C:\Program Files\system and C:\Program Files\system32. Should I simply put
all possible path into the array per arch?
(LLVM currently simply puts { "ompd.so", NULL }, but I am assuming this was
just a placeholder.)

- There doesn't seem to be any dedicated function to assign values to the
variable. I would like to create a header file to declare some additional
functions, such as one that would assign the value. Is this acceptable and,
if so, where would be the best place to put such header file?

I would appreciate any suggestions.

Cheers and stay safe,

Tony Sim

Re: [OMPD] regarding const char **ompd_dll_locations

[Jakub Jelinek via Gcc]

On Thu, Jun 18, 2020 at 05:24:25PM -0400, y2s1982 . wrote:
> (LLVM currently simply puts { "ompd.so", NULL }, but I am assuming this was
> just a placeholder.)

Let's put there { "libgompd" SONAME_SUFFIX (1), NULL } for now.
You'll need to change the SONAME_SUFFIX macros though - remove the ()s
around the strings, so that it can be further concatenated.

libgomp/config/darwin/plugin-suffix.h:#define SONAME_SUFFIX(n) ("." #n ".dylib")
libgomp/config/posix/plugin-suffix.h:#define SONAME_SUFFIX(n) (".so." #n)
libgomp/config/hpux/plugin-suffix.h:#define SONAME_SUFFIX(n) (".sl." #n)
libgomp/target.c:  const char *suffix = SONAME_SUFFIX (1);

Jakub

Re: [OMPD] regarding const char **ompd_dll_locations

[y2s1982 . via Gcc]

Hello Jakub,

Thank you for the quick response. I assume, then, there's no need for
making a function to set this global variable at this point. Should I
create a simple unit test that asserts the value to be "libgompd.so.1" for
now, or should I skip the unit test on this for now?

Cheers,

Tony Sim

On Thu, Jun 18, 2020 at 5:36 PM Jakub Jelinek  wrote:

> On Thu, Jun 18, 2020 at 05:24:25PM -0400, y2s1982 . wrote:
> > (LLVM currently simply puts { "ompd.so", NULL }, but I am assuming this
> was
> > just a placeholder.)
>
> Let's put there { "libgompd" SONAME_SUFFIX (1), NULL } for now.
> You'll need to change the SONAME_SUFFIX macros though - remove the ()s
> around the strings, so that it can be further concatenated.
>
> libgomp/config/darwin/plugin-suffix.h:#define SONAME_SUFFIX(n) ("." #n
> ".dylib")
> libgomp/config/posix/plugin-suffix.h:#define SONAME_SUFFIX(n) (".so." #n)
> libgomp/config/hpux/plugin-suffix.h:#define SONAME_SUFFIX(n) (".sl." #n)
> libgomp/target.c:  const char *suffix = SONAME_SUFFIX (1);
>
> Jakub
>
>

Re: [OMPD] regarding const char **ompd_dll_locations

[Jakub Jelinek via Gcc]

On Thu, Jun 18, 2020 at 06:19:43PM -0400, y2s1982 . wrote:
> Thank you for the quick response. I assume, then, there's no need for
> making a function to set this global variable at this point. Should I
> create a simple unit test that asserts the value to be "libgompd.so.1" for
> now, or should I skip the unit test on this for now?

There is no need for test for that, what you want to test is that the
debugger can actually dlopen the library and do something useful with it.

Jakub

gcc-8-20200618 is now available

[GCC Administrator via Gcc]

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

This snapshot has been generated from the GCC 8 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-8 
revision 496966ffb81a32b38781cf5542cbb6f8e128a57a

You'll find:

 gcc-8-20200618.tar.xzComplete GCC

  SHA256=5ad9d58f3ee09c79d3f35b1710d26985074ecfe9e1fb35fa7a448254ac293221
  SHA1=ae19257d6d3ff12d28e2c1f4d0e272b1a63ce098

Diffs from 8-20200611 are available in the diffs/ subdirectory.

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

Publishing paid sponsored post on your site

[Swathi Gade via Gcc]

Hello,

 We wanted to reach out to you regarding interest in purchasing guest posts
on your site octave.org in the form of content that’s linked with the
gambling site. Is this something you would be able to offer? And if so,
what would your rate be?

 Looking forward to hearing from you :)

 Thanks,