Enabling multi-section feature compulsively
Is it possible to enable this feature without `*-fdata-sections*` and ` *-ffunction-sections*` flags in GCC? And without `*--gc-sections*` in LD? This feature can reduce the size of statically linked binaries, but many build systems don't support it.
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
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
> Sent: 16 June 2023 13:51
> To: GCC Mailing List
> Cc: Roger Sayle
> 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: [PATCH v6 0/4] P1689R5 support
On Thu, Jun 08, 2023 at 21:59:13 +0400, Maxim Kuvyrkov wrote: > This patch series causes ICEs on arm-linux-gnueabihf. Would you > please investigate? Please let me know if you need any in reproducing > these. Finally back at it. I tried on aarch64, but wasn't able to reproduce the errors (alas, it is probably a 32bit thing…let me try with `-m32`). Is there hardware I can access to try this out on the same target triple? Alternatively, a backtrace may be able to help pinpoint it enough if you have the cycles. Thanks, --Ben
gcc-12-20230616 is now available
Snapshot gcc-12-20230616 is now available on https://gcc.gnu.org/pub/gcc/snapshots/12-20230616/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 12 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-12 revision 43e8299b7181c4828eab984259a8d76edfec0bd2 You'll find: gcc-12-20230616.tar.xz Complete GCC SHA256=c282a64532759127e410a7e3a2690996cdb71113846a2364156c8dca1e8d550a SHA1=403e1e61e3fd69e8bba64ea0017025ffb0a6704f Diffs from 12-20230609 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-12 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.
Re: [PATCH v6 0/4] P1689R5 support
On Fri, Jun 16, 2023 at 15:48:59 -0400, Ben Boeckel wrote: > On Thu, Jun 08, 2023 at 21:59:13 +0400, Maxim Kuvyrkov wrote: > > This patch series causes ICEs on arm-linux-gnueabihf. Would you > > please investigate? Please let me know if you need any in reproducing > > these. > > Finally back at it. I tried on aarch64, but wasn't able to reproduce the > errors (alas, it is probably a 32bit thing…let me try with `-m32`). Is > there hardware I can access to try this out on the same target triple? Trying inside of an i386 container also came up with nothing…I'll try qemu. --Ben
Create a password for Active IT zone
Welcome to z3n Precreated Account. Please click the link below to create a password and sign-in. https://activeitzone.zendesk.com/verification/email/DCK6wByYNm5x6eur7u8PAgdP2N6C7tba If you didn’t sign up to Active IT zone using this email address, you can safely ignore this email. This email is a service from Active IT zone.
Re: [PATCH v6 0/4] P1689R5 support
On Fri, Jun 16, 2023 at 3:49 PM Ben Boeckel wrote: > > On Thu, Jun 08, 2023 at 21:59:13 +0400, Maxim Kuvyrkov wrote: > > This patch series causes ICEs on arm-linux-gnueabihf. Would you > > please investigate? Please let me know if you need any in reproducing > > these. > > Finally back at it. I tried on aarch64, but wasn't able to reproduce the > errors (alas, it is probably a 32bit thing…let me try with `-m32`). Is > there hardware I can access to try this out on the same target triple? > > Alternatively, a backtrace may be able to help pinpoint it enough if you > have the cycles. I see the same thing with patch 4 on x86_64-pc-linux-gnu, e.g. FAIL: g++.dg/modules/ben-1_a.C -std=c++17 (test for excess errors) Excess errors: /home/jason/gt/gcc/testsuite/g++.dg/modules/ben-1_a.C:9:1: internal compiler error: Segmentation fault 0x19e2f3c crash_signal /home/jason/gt/gcc/toplev.cc:314 0x340f3f8 mkdeps::vec::size() const /home/jason/gt/libcpp/mkdeps.cc:57 0x340dc1f apply_vpath /home/jason/gt/libcpp/mkdeps.cc:194 0x340e08e deps_add_dep(mkdeps*, char const*) /home/jason/gt/libcpp/mkdeps.cc:318 0xea7b51 module_client::open_module_client(unsigned int, char const*, mkdeps*, void (*)(char const*), char const*) /home/jason/gt/gcc/cp/mapper-client.cc:291 0xef2ba8 make_mapper /home/jason/gt/gcc/cp/module.cc:14042 0xf0896c get_mapper(unsigned int, mkdeps*) /home/jason/gt/gcc/cp/module.cc:3977 0xf032ac name_pending_imports /home/jason/gt/gcc/cp/module.cc:19623 0xf03a7d preprocessed_module(cpp_reader*) /home/jason/gt/gcc/cp/module.cc:19817 0xe85104 module_token_cdtor(cpp_reader*, unsigned long) /home/jason/gt/gcc/cp/lex.cc:548 0xf467b2 cp_lexer_new_main /home/jason/gt/gcc/cp/parser.cc:756 0xfc1e3a c_parse_file() /home/jason/gt/gcc/cp/parser.cc:49725 0x11c5bf5 c_common_parse_file() /home/jason/gt/gcc/c-family/c-opts.cc:1268
