Issue generating GCC coverage report since r14-1625-geba3565ce6d766

Issue generating GCC coverage report since r14-1625-geba3565ce6d766

[Martin Jambor]

Hello,

we try to build coverage info for GCC for our testsuite and upload it to
https://gcc.opensuse.org/gcc-lcov/ every weekend.  But since patch
r14-1625-geba3565ce6d766 (Add support for stc and cmc instructions in
i386.md) the generation broke down.  However, I don't think there is
something necessarily wrong with that particular commit, at least I
don't see anything suspicious.

I inherited the generating script from Martin Liška and have not really
looked much into it much, but it simply does the following after a fresh
GCC master checkout (I added the --disable-multilib and reduced the
number of languages to reproduce this more quickly):


  ../src/configure --prefix=/home/mjambor/gcc/mine/inst --enable-languages=c,c++ --disable-bootstrap --enable-host-shared --enable-coverage=opt --disable-multilib
  make -j64 && make -j64 -k check
  find gcc/testsuite/ -name '*.gcda' -exec rm -rvf {} \;  # I don't know why the script does this
  lcov -d . --capture --output-file gcc.info


and this last step, since the commit, when processing file
./gcc/insn-attrtab.gcda fails with error:

  geninfo: ERROR: mismatched end line for _Z12get_attr_isaP8rtx_insn at /home/mjambor/gcc/mine/src/gcc/config/i386/i386.md:5776: 5776 -> 8963
          (use "geninfo --ignore-errors mismatch ..." to bypass this error)

I tried looking briefly into the perl sources of lcov and geninfo but I
am afraid I don't have the necessary knowledge of the language and the
tool or the time to properly debug this.  So I am inclined to simply add
--ignore-errors mismatch to lcov options, which avoids the issue, and be
done with it.  Nevertheless, I thought I'd mention this here in case
anyone here has any ideas what can be going wrong.

Thanks,

Martin

RE: Issue generating GCC coverage report since r14-1625-geba3565ce6d766

[Roger Sayle]

Hi Martin,
It's great to hear from you.  My apologies for the inconvenience.
I believe that the problem has been solved by Jakub's patch:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;f=gcc/config/i386/i386.md;h=43a3252c42af12ad90082e4088ea58eecd0bf582

I strongly suspect that the problem was that my patch was emitting "(const_int 0)" as
an instruction into the RTL stream, which I'd misunderstood to be recognized as a
no-op by the middle-end.  This isn't the case and the correct idiom is to (also) use:
emit_note (NOTE_INSN_DELETED); DONE;

I can easily believe that this unintended behaviour is/was interfering with your code
coverage scripts (I should study your posted results).

I hope this explains things.  Please let me know if things really are not fixed (or not).
Cheers,
Roger
--

> -----Original Message-----
> From: Martin Jambor <mjambor@suse.cz>
> Sent: 16 June 2023 13:51
> To: GCC Mailing List <gcc@gcc.gnu.org>
> Cc: Roger Sayle <roger@nextmovesoftware.com>
> Subject: Issue generating GCC coverage report since r14-1625-geba3565ce6d766
> 
> Hello,
> 
> we try to build coverage info for GCC for our testsuite and upload it to
> https://gcc.opensuse.org/gcc-lcov/ every weekend.  But since patch
> r14-1625-geba3565ce6d766 (Add support for stc and cmc instructions in
> i386.md) the generation broke down.  However, I don't think there is something
> necessarily wrong with that particular commit, at least I don't see anything
> suspicious.
> 
> I inherited the generating script from Martin Liška and have not really looked
> much into it much, but it simply does the following after a fresh GCC master
> checkout (I added the --disable-multilib and reduced the number of languages to
> reproduce this more quickly):
> 
> 
>   ../src/configure --prefix=/home/mjambor/gcc/mine/inst --enable-
> languages=c,c++ --disable-bootstrap --enable-host-shared --enable-coverage=opt
> --disable-multilib
>   make -j64 && make -j64 -k check
>   find gcc/testsuite/ -name '*.gcda' -exec rm -rvf {} \;  # I don't know why the
> script does this
>   lcov -d . --capture --output-file gcc.info
> 
> 
> and this last step, since the commit, when processing file ./gcc/insn-attrtab.gcda
> fails with error:
> 
>   geninfo: ERROR: mismatched end line for _Z12get_attr_isaP8rtx_insn at
> /home/mjambor/gcc/mine/src/gcc/config/i386/i386.md:5776: 5776 -> 8963
>           (use "geninfo --ignore-errors mismatch ..." to bypass this error)
> 
> I tried looking briefly into the perl sources of lcov and geninfo but I am afraid I
> don't have the necessary knowledge of the language and the tool or the time to
> properly debug this.  So I am inclined to simply add --ignore-errors mismatch to
> lcov options, which avoids the issue, and be done with it.  Nevertheless, I thought
> I'd mention this here in case anyone here has any ideas what can be going wrong.
> 
> Thanks,
> 
> Martin

RE: Issue generating GCC coverage report since r14-1625-geba3565ce6d766

[Martin Jambor]

Hi Roger,

sorry for late reply, rather unexpectedly I found myself traveling last
week.

On Fri, Jun 16 2023, Roger Sayle wrote:
> Hi Martin,
> It's great to hear from you.  My apologies for the inconvenience.
> I believe that the problem has been solved by Jakub's patch:
> https://gcc.gnu.org/git/?p=gcc.git;a=commit;f=gcc/config/i386/i386.md;h=43a3252c42af12ad90082e4088ea58eecd0bf582

Unfortunately the situation remains the same, even with the above patch
in master.

The workaround I hoped for (adding --ignore-errors mismatch) does not
help either, the whole process then fails later on.  Perhaps adding
another --ignore-errors elsewhere may fix this, but at the moment I need
to defer playing with this for a few weeks.

Thanks,

Martin


>
> I strongly suspect that the problem was that my patch was emitting "(const_int 0)" as
> an instruction into the RTL stream, which I'd misunderstood to be recognized as a
> no-op by the middle-end.  This isn't the case and the correct idiom is to (also) use:
> emit_note (NOTE_INSN_DELETED); DONE;
>
> I can easily believe that this unintended behaviour is/was interfering with your code
> coverage scripts (I should study your posted results).
>
> I hope this explains things.  Please let me know if things really are not fixed (or not).
> Cheers,
> Roger
> --
>
>> -----Original Message-----
>> From: Martin Jambor <mjambor@suse.cz>
>> Sent: 16 June 2023 13:51
>> To: GCC Mailing List <gcc@gcc.gnu.org>
>> Cc: Roger Sayle <roger@nextmovesoftware.com>
>> Subject: Issue generating GCC coverage report since r14-1625-geba3565ce6d766
>> 
>> Hello,
>> 
>> we try to build coverage info for GCC for our testsuite and upload it to
>> https://gcc.opensuse.org/gcc-lcov/ every weekend.  But since patch
>> r14-1625-geba3565ce6d766 (Add support for stc and cmc instructions in
>> i386.md) the generation broke down.  However, I don't think there is something
>> necessarily wrong with that particular commit, at least I don't see anything
>> suspicious.
>> 
>> I inherited the generating script from Martin Liška and have not really looked
>> much into it much, but it simply does the following after a fresh GCC master
>> checkout (I added the --disable-multilib and reduced the number of languages to
>> reproduce this more quickly):
>> 
>> 
>>   ../src/configure --prefix=/home/mjambor/gcc/mine/inst --enable-
>> languages=c,c++ --disable-bootstrap --enable-host-shared --enable-coverage=opt
>> --disable-multilib
>>   make -j64 && make -j64 -k check
>>   find gcc/testsuite/ -name '*.gcda' -exec rm -rvf {} \;  # I don't know why the
>> script does this
>>   lcov -d . --capture --output-file gcc.info
>> 
>> 
>> and this last step, since the commit, when processing file ./gcc/insn-attrtab.gcda
>> fails with error:
>> 
>>   geninfo: ERROR: mismatched end line for _Z12get_attr_isaP8rtx_insn at
>> /home/mjambor/gcc/mine/src/gcc/config/i386/i386.md:5776: 5776 -> 8963
>>           (use "geninfo --ignore-errors mismatch ..." to bypass this error)
>> 
>> I tried looking briefly into the perl sources of lcov and geninfo but I am afraid I
>> don't have the necessary knowledge of the language and the tool or the time to
>> properly debug this.  So I am inclined to simply add --ignore-errors mismatch to
>> lcov options, which avoids the issue, and be done with it.  Nevertheless, I thought
>> I'd mention this here in case anyone here has any ideas what can be going wrong.
>> 
>> Thanks,
>> 
>> Martin