https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89961
Martin Liška changed:
What|Removed |Added
Resolution|--- |FIXED
Known to fail|11.2.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89961
--- Comment #27 from CVS Commits ---
The releases/gcc-11 branch has been updated by Martin Liska
:
https://gcc.gnu.org/g:f7134a12cd633e8ffdcee1af7e294e9ab60647c0
commit r11-8892-gf7134a12cd633e8ffdcee1af7e294e9ab60647c0
Author: Martin Liska
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89961
Martin Liška changed:
What|Removed |Added
Known to fail||11.2.0
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89961
--- Comment #25 from CVS Commits ---
The master branch has been updated by Martin Liska :
https://gcc.gnu.org/g:b777f228b481ae881a7fbb09de367a053740932c
commit r12-3038-gb777f228b481ae881a7fbb09de367a053740932c
Author: Martin Liska
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89961
--- Comment #24 from Martin Liška ---
> Correct, but `--help` and `--version` are formatted for humans, not machines.
> This can lead to false positives or negatives. It forces every application
> that
> calls gcov and wants to support wide
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89961
--- Comment #23 from xaizek ---
> it should be fixed in the updated version of the patch.
Yes, it is.
> Right now, one can easily detect JSON format with
> `gcov --help | grep json-format`, am I right? What type of capability would
> you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89961
Martin Liška changed:
What|Removed |Added
Attachment #51316|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89961
--- Comment #21 from Martin Liška ---
(In reply to xaizek from comment #20)
> The patch works! I think you actually implemented behaviour of `-p` for `-l`
> (you hash path in the code and don't process includes). `-l` doesn't seem to
> make much
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89961
--- Comment #20 from xaizek ---
The patch works! I think you actually implemented behaviour of `-p` for `-l`
(you hash path in the code and don't process includes). `-l` doesn't seem to
make much sense for JSON, because all includes will be in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89961
--- Comment #19 from Martin Liška ---
Created attachment 51316
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51316=edit
Patch candidate
All right, I've created a patch that implements -x and -l options for JSON
format.
@xaizek: Can you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89961
--- Comment #18 from xaizek ---
> The following 2 files should be created (right now b.gcov.json.gz and
> a.gcov.json.gz are created)
>
> b.gcov.json.gz
> src/a.gcov.json.gz
>
> and so -p and -x does not play any role here.
Now you'll need to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89961
--- Comment #17 from Martin Liška ---
> $ gcov src/a.x b.yy --json-format
this ought to be src/a.c b.c (but as you noticed gcov deduces .gcda/.gcno files
by skipping the last dot component of a path). That's why it works as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89961
--- Comment #16 from Martin Liška ---
All right, so what's different about JSON and non-JSON mode:
1) normal mode:
gcov src/a.c test/a.c
First, gcda/gcno files are searched for both the arguments (so src/a.gcda, ..)
and then output is emitted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89961
--- Comment #15 from xaizek ---
> I don't think anything is violated, because GCC has `-o` option.
Actually, I tried it and GCC can produce such weird results as well, but
documentation talks about file discovery, not about reproducing this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89961
--- Comment #14 from xaizek ---
> This example violates that because you would end up with clasing myclass.o.
I don't think anything is violated, because GCC has `-o` option. It's
equivalent in GCOV is mangling:
> The mangledname part of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89961
--- Comment #13 from Martin Liška ---
(In reply to xaizek from comment #11)
> > Closing this as fixed.
>
> This isn't fixed. I don't think the problem was actually understood.
>
> Say you have:
>
> * src/myclass.o
> * tests/myclass.o
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89961
Martin Liška changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89961
xaizek changed:
What|Removed |Added
CC||xaizek at posteo dot net
--- Comment #11 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89961
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89961
--- Comment #9 from Martin Liška ---
Author: marxin
Date: Mon Apr 8 12:16:15 2019
New Revision: 270204
URL: https://gcc.gnu.org/viewcvs?rev=270204=gcc=rev
Log:
Add data_file to GCOV interm. format (PR gcov-profile/89961).
2019-04-08 Martin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89961
--- Comment #8 from Martin Liška ---
I took back what I took back ;)
The intermediate format file is created from GCDA file and contains information
for multiple source files. So that it does not make sense to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89961
--- Comment #7 from Martin Liška ---
I take it base. Makes sense to behave exactly as for non-intermediate format
mode.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89961
--- Comment #6 from Martin Liška ---
(In reply to Cristian Morales Vega from comment #5)
> OK, trying to catch you here, from my gcc-8.3.1.
> So with gcc 9 "--intermediate-format" is gone and we now have
> "--json-format" (keeping the "-i"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89961
--- Comment #5 from Cristian Morales Vega ---
OK, trying to catch you here, from my gcc-8.3.1.
So with gcc 9 "--intermediate-format" is gone and we now have "--json-format"
(keeping the "-i" version)?
The "--intermediate-format" documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89961
--- Comment #4 from Martin Liška ---
(In reply to Cristian Morales Vega from comment #3)
> I have just took a look inside one of the intermediate format .gcov files
> and didn't see any "current_working_directory". There is a full path "file"
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89961
--- Comment #3 from Cristian Morales Vega ---
I have just took a look inside one of the intermediate format .gcov files and
didn't see any "current_working_directory". There is a full path "file"
variable though.
Not sure if that's what you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89961
--- Comment #2 from Martin Liška ---
Note that the intermediate format provides 'current_working_directory' value
that should be easily used to distinguish among same files in different
folders?
Does it work for you?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89961
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
28 matches
Mail list logo
