[Bug target/111600] [14/15 Regression] RISC-V bootstrap time regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600 --- Comment #35 from Mark Wielaard --- (In reply to GCC Commits from comment #28) > The master branch has been updated by Robin Dapp : > > https://gcc.gnu.org/g:184378027e92f51e02d3649e0ca523f487fd2810 > > commit r14-5034-g184378027e92f51e02d3649e0ca523f487fd2810 > Author: Robin Dapp > Date: Thu Oct 12 11:23:26 2023 +0200 > > genemit: Split insn-emit.cc into several partitions. > > On riscv insn-emit.cc has grown to over 1.2 mio lines of code and > compiling it takes considerable time. > Therefore, this patch adjust genemit to create several partitions > (insn-emit-1.cc to insn-emit-n.cc). The available patterns are > written to the given files in a sequential fashion. > > Similar to match.pd a configure option --with-emitinsn-partitions=num > is introduced that makes the number of partition configurable. The size of the partitions is a little uneven though. Using --with-emitinsn-partitions=48 I get some empty partitions and some bigger than 2MB: $ du -sb insn-emit-*cc | sort -n 814 insn-emit-12.cc 814 insn-emit-26.cc 814 insn-emit-27.cc 814 insn-emit-28.cc 113694 insn-emit-1.cc 168449 insn-emit-2.cc 197478 insn-emit-4.cc 231826 insn-emit-25.cc 264612 insn-emit-24.cc 269851 insn-emit-3.cc 273807 insn-emit-23.cc 309345 insn-emit-15.cc 354863 insn-emit-22.cc 399238 insn-emit-29.cc 469333 insn-emit-13.cc 494480 insn-emit-16.cc 529290 insn-emit-7.cc 548060 insn-emit-14.cc 587349 insn-emit-8.cc 605757 insn-emit-18.cc 654426 insn-emit-11.cc 674447 insn-emit-21.cc 715062 insn-emit-6.cc 719623 insn-emit-30.cc 722383 insn-emit-17.cc 739181 insn-emit-5.cc 740943 insn-emit-19.cc 752354 insn-emit-10.cc 775514 insn-emit-9.cc 798665 insn-emit-37.cc 864751 insn-emit-39.cc 880633 insn-emit-45.cc 898498 insn-emit-20.cc 921502 insn-emit-47.cc 927048 insn-emit-38.cc 940841 insn-emit-46.cc 954115 insn-emit-33.cc 979274 insn-emit-44.cc 1054316 insn-emit-32.cc 1133828 insn-emit-31.cc 1151717 insn-emit-40.cc 1190472 insn-emit-36.cc 1207434 insn-emit-41.cc 1218249 insn-emit-43.cc 1299464 insn-emit-42.cc 1887267 insn-emit-34.cc 1977532 insn-emit-35.cc 2935485 insn-emit-48.cc Note that the last one (insn-emit-48.cc) is much larger than the rest. Something similar happens with --with-emitinsn-partitions=20 where the smallest one is just 120K but the biggest (and again the last one) is 4.3M. $ du -sb insn-emit-*cc | sort -n 122643 insn-emit-11.cc 466445 insn-emit-12.cc 545997 insn-emit-1.cc 691176 insn-emit-10.cc 773776 insn-emit-2.cc 1027938 insn-emit-6.cc 1138222 insn-emit-5.cc 1524621 insn-emit-9.cc 1558328 insn-emit-3.cc 1730818 insn-emit-7.cc 1865168 insn-emit-4.cc 1893646 insn-emit-8.cc 2174548 insn-emit-16.cc 2378629 insn-emit-19.cc 2404572 insn-emit-13.cc 2840108 insn-emit-17.cc 2894107 insn-emit-14.cc 3030400 insn-emit-18.cc 4156366 insn-emit-15.cc 4486663 insn-emit-20.cc Another problematic file is insn-recog.cc which is 19MB and takes 1 hour+ to compile for me.
[Bug bootstrap/115453] [15 regression] Noise from new dlopen, pthread configure checks since r15-1177-g75299e4fe50aa8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115453
Mark Wielaard changed:
What|Removed |Added
CC||mark at gcc dot gnu.org
--- Comment #15 from Mark Wielaard ---
Something seems to have gone slightly wrong when regenerating the configure
files.
The gcc-autoregen bot is unhappy:
https://builder.sourceware.org/buildbot/#/builders/gcc-autoregen
https://builder.sourceware.org/buildbot/#/builders/269/builds/5952
Sourceware
Buildersgcc-autoregen5952git diffstdio
Anonymous
git diff --exit-code
in dir /home/builder/shared/bb2-2/worker/gcc-autoregen/build (timeout 1200
secs)
watching logfiles {}
argv: [b'git', b'diff', b'--exit-code']
environment:
BUILDMASTER=builder.sourceware.org
BUILDMASTER_PORT=9989
CCACHE_DIR=/home/builder/shared/autotools/ccache
CCACHE_LIBDIR=/usr/lib/ccache
HOME=/home/builder
HOSTNAME=cf526139a6b4
IMAGE_NAME=autotools
LC_CTYPE=C.UTF-8
PATH=/usr/lib/ccache:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
PWD=/home/builder/shared/bb2-2/worker/gcc-autoregen/build
WORKERNAME=bb2-2
using PTY: False
diff --git a/configure b/configure
index 6e95b27d9df..03dad4d362d 100755
--- a/configure
+++ b/configure
@@ -19746,7 +19746,7 @@ config.status
configured by $0, generated by GNU Autoconf 2.69,
with options \\"\$ac_cs_config\\"
-Copyright (C) Free Software Foundation, Inc.
+Copyright (C) 2012 Free Software Foundation, Inc.
This config.status script is free software; the Free Software Foundation
gives unlimited permission to copy, distribute and modify it."
diff --git a/gcc/configure b/gcc/configure
index b536af664d3..a8fc4bb34aa 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -30239,7 +30239,7 @@ else
fi
{ $as_echo "$as_me:${as_lineno-$LINENO}: result:
$gcc_cv_as_mips_explicit_relocs_pcrel" >&5
$as_echo "$gcc_cv_as_mips_explicit_relocs_pcrel" >&6; }
-if test "x$gcc_cv_as_mips_explicit_relocs_pcrel" = "xyes"; then
+if test $gcc_cv_as_mips_explicit_relocs_pcrel = yes; then
$as_echo "#define MIPS_EXPLICIT_RELOCS MIPS_EXPLICIT_RELOCS_PCREL"
>>confdefs.h
@@ -30498,7 +30498,7 @@ fi
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking assembler and linker for
explicit JALR relocation" >&5
$as_echo_n "checking assembler and linker for explicit JALR relocation... "
>&6; }
gcc_cv_as_ld_jalr_reloc=no
-if test $gcc_cv_as_mips_explicit_relocs = yes; then
+if test "x$gcc_cv_as_mips_explicit_relocs" = "xyes"; then
if test $in_tree_ld = yes ; then
if test "$gcc_cv_gld_major_version" -eq 2 -a
"$gcc_cv_gld_minor_version" -ge 20 -o "$gcc_cv_gld_major_version" -gt 2 \
&& test $in_tree_ld_is_elf = yes; then
program finished with exit code 1
elapsedTime=0.410978
I am not sure what exactly could have caused this difference.
[Bug bootstrap/115453] [15 regression] Noise from new dlopen, pthread configure checks since r15-1177-g75299e4fe50aa8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115453
Mark Wielaard changed:
What|Removed |Added
CC||mark at gcc dot gnu.org
--- Comment #15 from Mark Wielaard ---
Something seems to have gone slightly wrong when regenerating the configure
files.
The gcc-autoregen bot is unhappy:
https://builder.sourceware.org/buildbot/#/builders/gcc-autoregen
https://builder.sourceware.org/buildbot/#/builders/269/builds/5952
Sourceware
Buildersgcc-autoregen5952git diffstdio
Anonymous
git diff --exit-code
in dir /home/builder/shared/bb2-2/worker/gcc-autoregen/build (timeout 1200
secs)
watching logfiles {}
argv: [b'git', b'diff', b'--exit-code']
environment:
BUILDMASTER=builder.sourceware.org
BUILDMASTER_PORT=9989
CCACHE_DIR=/home/builder/shared/autotools/ccache
CCACHE_LIBDIR=/usr/lib/ccache
HOME=/home/builder
HOSTNAME=cf526139a6b4
IMAGE_NAME=autotools
LC_CTYPE=C.UTF-8
PATH=/usr/lib/ccache:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
PWD=/home/builder/shared/bb2-2/worker/gcc-autoregen/build
WORKERNAME=bb2-2
using PTY: False
diff --git a/configure b/configure
index 6e95b27d9df..03dad4d362d 100755
--- a/configure
+++ b/configure
@@ -19746,7 +19746,7 @@ config.status
configured by $0, generated by GNU Autoconf 2.69,
with options \\"\$ac_cs_config\\"
-Copyright (C) Free Software Foundation, Inc.
+Copyright (C) 2012 Free Software Foundation, Inc.
This config.status script is free software; the Free Software Foundation
gives unlimited permission to copy, distribute and modify it."
diff --git a/gcc/configure b/gcc/configure
index b536af664d3..a8fc4bb34aa 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -30239,7 +30239,7 @@ else
fi
{ $as_echo "$as_me:${as_lineno-$LINENO}: result:
$gcc_cv_as_mips_explicit_relocs_pcrel" >&5
$as_echo "$gcc_cv_as_mips_explicit_relocs_pcrel" >&6; }
-if test "x$gcc_cv_as_mips_explicit_relocs_pcrel" = "xyes"; then
+if test $gcc_cv_as_mips_explicit_relocs_pcrel = yes; then
$as_echo "#define MIPS_EXPLICIT_RELOCS MIPS_EXPLICIT_RELOCS_PCREL"
>>confdefs.h
@@ -30498,7 +30498,7 @@ fi
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking assembler and linker for
explicit JALR relocation" >&5
$as_echo_n "checking assembler and linker for explicit JALR relocation... "
>&6; }
gcc_cv_as_ld_jalr_reloc=no
-if test $gcc_cv_as_mips_explicit_relocs = yes; then
+if test "x$gcc_cv_as_mips_explicit_relocs" = "xyes"; then
if test $in_tree_ld = yes ; then
if test "$gcc_cv_gld_major_version" -eq 2 -a
"$gcc_cv_gld_minor_version" -ge 20 -o "$gcc_cv_gld_major_version" -gt 2 \
&& test $in_tree_ld_is_elf = yes; then
program finished with exit code 1
elapsedTime=0.410978
I am not sure what exactly could have caused this difference.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug debug/91507] wrong debug for completed array with previous incomplete declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91507 Mark Wielaard changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||mark at gcc dot gnu.org Resolution|--- |FIXED --- Comment #9 from Mark Wielaard --- 10.1 is long since released
[Bug debug/78100] DWARF symbols for an array sometimes missing the array length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78100 Mark Wielaard changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #9 from Mark Wielaard --- (In reply to Kevin Puetz from comment #8) > Found it: this is a duplicate of bug 91507, thus fixed by > r276403/31632e2c4327146ea8d21cff33adaa505b17d2bd Thanks for the research. *** This bug has been marked as a duplicate of bug 91507 ***
[Bug debug/91507] wrong debug for completed array with previous incomplete declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91507 Mark Wielaard changed: What|Removed |Added CC||gccbugs at dima dot secretsauce.ne ||t --- Comment #8 from Mark Wielaard --- *** Bug 78100 has been marked as a duplicate of this bug. ***
[Bug web/114223] Utilize filtering for git://gcc.gnu.org/git/gcc.git
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114223 Mark Wielaard changed: What|Removed |Added CC||mark at gcc dot gnu.org --- Comment #1 from Mark Wielaard --- I believe this is enabled by setting the following settings described at https://git-scm.com/docs/git-config#Documentation/git-config.txt-uploadpackallowFilter uploadpack.allowFilter If this option is set, upload-pack will support partial clone and partial fetch object filtering. uploadpackfilter.allow Provides a default value for unspecified object filters (see: the below configuration variable). If set to true, this will also enable all filters which get added in the future. Defaults to true. uploadpackfilter..allow Explicitly allow or ban the object filter corresponding to , where may be one of: blob:none, blob:limit, object:type, tree, sparse:oid, or combine. If using combined filters, both combine and all of the nested filter kinds must be allowed. Defaults to uploadpackfilter.allow. uploadpackfilter.tree.maxDepth Only allow --filter=tree: when is no more than the value of uploadpackfilter.tree.maxDepth. If set, this also implies uploadpackfilter.tree.allow=true, unless this configuration variable had already been set. Has no effect if unset.
[Bug target/113045] armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045 --- Comment #25 from Mark Wielaard --- Note comment #16 which explains that valgrind seems to translate this large read into smaller chunks. Which most likely causes memcheck to flag the (last) 8 bytes read as fully invalid. See --partial-loads-ok= [default: yes] Controls how Memcheck handles 32-, 64-, 128- and 256-bit naturally aligned loads from addresses for which some bytes are addressable and others are not. When yes, such loads do not produce an address error. Instead, loaded bytes originating from illegal addresses are marked as uninitialised, and those corresponding to legal addresses are handled in the normal way. When no, loads from partially invalid addresses are treated the same as loads from completely invalid addresses: an illegal-address error is issued, and the resulting bytes are marked as initialised. It would be helpful to see if someone with arm knowledge (and valgrind VEX knowledge) can see if there is a better translation of the vld1 instruction so that it is one big read. That way memcheck at least has a chance of detecting that the part that is invalid isn't actually used. See https://sourceware.org/cgit/valgrind/tree/VEX/priv/guest_arm_toIR.c#n8383 But maybe there is no good/natural translation of these vector loads that would help memcheck see it is a valid read and only the defined bytes are used.
[Bug target/113045] armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045 --- Comment #19 from Mark Wielaard --- (In reply to David Binderman from comment #18) > (In reply to Mark Wielaard from comment #17) > > I am surprised valgrind memcheck doesn't produce more output, normally it > > would tell you why & where it found the address invalid. > > The valgrind output I gave originally looks to be in the usual valgrind > format to me. > Perhaps you are assuming some other debugging tool like asan or ubsan ? Normally valgrind adds something like: Address 0xaa is x bytes inside a block of size y free'd please a stacktrace where that block was allocated/freed In this case I would expect to say something like that the address that is being access is after a block. Assuming it is indeed not accessible. The read of 4 bytes is interesting, it seems to mean that valgrind decided to chop up this read into smaller blocks. > > I assume somehow > > valgrind memcheck believes it is reading past the end of a data buffer, > > while the code assumes this is fine because it will mask off the bits it > > won't use. > > valgrind doesn't normally produce an error for copying around un-initialised > bytes. > > However, it will produce an error if those bytes are used in a decision > like an if statement. Or it will produce an error if it is an unaddressible location. Which seems to be the case here. I would try to figure out which address exactly it is, what the exact arm/neon (?) instruction it is that is being executed. How many bytes it is supposed to read and if that many bytes are actually available. If this is an overread then you might try --partial-loads-ok=yes (although that should be the default these days). If that doesn't work then valgrind might have chopped up the read into smaller blocks, so memcheck cannot see that it is a larger load and the backend (VEX/priv/guest_arm_toIR.c) might have to be adjusted.
[Bug target/113045] armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045 --- Comment #17 from Mark Wielaard --- I am surprised valgrind memcheck doesn't produce more output, normally it would tell you why & where it found the address invalid. I assume somehow valgrind memcheck believes it is reading past the end of a data buffer, while the code assumes this is fine because it will mask off the bits it won't use.
[Bug web/108473] bugzilla see also should support gitlab.com URLs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108473 Mark Wielaard changed: What|Removed |Added Status|NEW |WAITING --- Comment #7 from Mark Wielaard --- OK, applied all 12 above commits to both both gcc and sourceware bugzilla. There were some small whitespace issues, but most applied cleanly. Could you check that everything looks fine and the new trackers can be added through See Also now?
[Bug web/108473] bugzilla see also should support gitlab.com URLs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108473 --- Comment #6 from Mark Wielaard --- Also looking at f944c5b2a894f866fc50e06ba90fb5dbd902ba36 "Bug 1167919: See Also: support debbugs.gnu.org tracker"
[Bug web/108473] bugzilla see also should support gitlab.com URLs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108473 Mark Wielaard changed: What|Removed |Added Ever confirmed|0 |1 CC||mark at gcc dot gnu.org Last reconfirmed||2023-11-20 Status|UNCONFIRMED |NEW --- Comment #3 from Mark Wielaard --- Have those patches been upstreamed?
[Bug other/106899] Snapshots do not contain pre-generated man pages & info pages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106899 Mark Wielaard changed: What|Removed |Added CC||mark at gcc dot gnu.org --- Comment #6 from Mark Wielaard --- (In reply to Richard Biener from comment #5) > The resource issue is probably a non-issue these days Yes, we have more hardware these these. Even a separate machine just to create snapshots. Thanks to OSUOSL we now have https://snapshots.sourceware.org/ to publish static artifacts from current git repos created in isolated containers. It can be used as alternative to cron jobs on the main machine to generate snapshots and documentation. The container files and build steps are defined through the builder project. We could do both. Have the current snapshots once a week. And have a full "release snapshot" through snapshorts.sourceware.org whenever the sources change (every hour) that regenerates all generated files (so we also know whenever manual creation is broken).
[Bug demangler/110147] UBSAN error in rust-demangle.c: NULL pointer passed to memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110147
Mark Wielaard changed:
What|Removed |Added
Last reconfirmed||2023-06-08
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #3 from Mark Wielaard ---
(In reply to Jonathan Wakely from comment #2)
> --- a/libiberty/rust-demangle.c
> +++ b/libiberty/rust-demangle.c
> @@ -1569,8 +1569,11 @@ str_buf_append (struct str_buf *buf, const char
> *data, size_t len)
>if (buf->errored)
> return;
>
> - memcpy (buf->ptr + buf->len, data, len);
> - buf->len += len;
> + if (len)
> + {
> +memcpy (buf->ptr + buf->len, data, len);
> +buf->len += len;
> + }
> }
>
> static void
That is probably the correct fix/workaround. str_buf_append is the
function/callback used to build up the demangled string. If it gets an empty
NULL/0 string it really shouldn't do anything (so you could also do a if (len
== 0) return at the top).
We might want to ping ed...@lyken.rs (who wrote the original v0 rust demangler)
in case he thinks this might also need to raise an error flag. But that would
technically be a separate bug I think.
[Bug c/88088] -Wtrampolines should be enabled by -Wall (or -Wextra)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88088 --- Comment #24 from Mark Wielaard --- (In reply to Eric Gallager from comment #23) > (In reply to Mark Wielaard from comment #22) > > (In reply to Eric Gallager from comment #21) > > > (In reply to Mark Wielaard from comment #20) > > > > https://gcc.gnu.org/ml/gcc-patches/2018-11/msg02055.html > > > > > > Did this make it in? If not, have you pinged it lately? > > > > No, there was some review, I think we are generally good, but I am waiting > > for stage1 to open. > > Stage1 has opened. And it has opened again. So this comment is mostly for myself to not forget about this again (and again...)
[Bug debug/108996] Proposal for adding DWARF call site information in GCC with -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108996 --- Comment #6 from Mark Wielaard --- (In reply to Jakub Jelinek from comment #5) > So, I wonder if we just shouldn't ask for a DWARF 6 extension here, have > some way for the compiler to specify DW_AT_location for the return value. There is https://dwarfstd.org/ShowIssue.php?issue=221105.1 "Add a mechanism for specifying subprogram return value locations"
[Bug driver/108572] New: -gz=none produces gcc: error: -gz=zstd is not supported in this configuration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108572
Bug ID: 108572
Summary: -gz=none produces gcc: error: -gz=zstd is not
supported in this configuration
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: mark at gcc dot gnu.org
Target Milestone: ---
gcc (GCC) 13.0.1 20230117 (Red Hat 13.0.1-0)
$ echo "int main () {}" | gcc -xc -gz=none -
gcc: error: -gz=zstd is not supported in this configuration
OK, apparently -gz=zstd needs a newer binutils, but I am using -gz=none not
-gz=zstd
[Bug middle-end/104069] -Werror=use-after-free false positive on elfutils-0.186
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104069 --- Comment #25 from Mark Wielaard --- Note that elfutils-0.187 builds fine for me on fedora x86_64 with either: gcc (GCC) 12.2.1 20220819 (Red Hat 12.2.1-2) So this might have been fixed since 12.2.0?
[Bug tree-optimization/107413] Perf loss ~14% on 519.lbm_r SPEC cpu2017 benchmark
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107413 --- Comment #4 from Mark Wielaard --- The content of attachment 53775 has been deleted for the following reason: https://sourceware.org/pipermail/overseers/2022q4/019048.html
[Bug tree-optimization/107409] Perf loss ~5% on 519.lbm_r SPEC cpu2017 benchmark
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107409 --- Comment #7 from Mark Wielaard --- The content of attachment 53773 has been deleted for the following reason: https://sourceware.org/pipermail/overseers/2022q4/019048.html
[Bug debug/105088] Small DWARF 5 spec violation in line table when passing an absolute path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105088 --- Comment #11 from Mark Wielaard --- I believe the intention of the DWARF5 spec as that dir entry zero would be equal to the comp_dir attribute of the CU and file entry zero would be equal to the name attribute of the CU. Also, although the spec does not explicitly seem to say so, consumers take an absolute source path to mean that the file isn't relative to the compilation dir. So if the current working directory is my home dir and I compile a source file /tmp/test.c then I would expect the Compile Unit DIE to have the following two attributes: name (line_strp) "/tmp/test.c" comp_dir (line_strp) "/home/mark" And the dir/line table to match with: Directory table: [path(line_strp)] 0 /home/mark (23) File name table: [path(line_strp), directory_index(udata)] 0 /tmp/test.c (52), 0 gcc tries to make that happen using the following .file 0 entry: .file 0 "/home/mark" "/tmp/test.c" So if that is no longer the case, then I think binutils gas is getting this wrong now.
[Bug libbacktrace/104463] Split debug info not loaded from .debug/ if .gnu_debuglink points to binary itself
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104463 Mark Wielaard changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2022-02-25 --- Comment #1 from Mark Wielaard --- Note. The term "split dwarf" is often associated with the -gsplit-dwarf option, which uses .dwo sections (and files) to split DWARF debuginfo. This bug isn't about that. I can replicate the issue, but haven't fully traced why it happens. It seems libbacktrace gets confused about where /proc/self/exe points to and tries to open /proc/self/bug, /proc/self/.debug/bug and /usr/lib/debug//proc/self/bug
[Bug middle-end/63311] [9/10/11/12 Regression] -O1 optimization introduces valgrind warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63311 Mark Wielaard changed: What|Removed |Added CC||mark at gcc dot gnu.org --- Comment #19 from Mark Wielaard --- This still replicates with valgrind 3.18.1 and gcc 11.2.1: $ gcc -O1 -std=c11 -g PR63311.c -lm && valgrind --track-origins=yes ./a.out ==2836066== Memcheck, a memory error detector ==2836066== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==2836066== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info ==2836066== Command: ./a.out ==2836066== ==2836066== Conditional jump or move depends on uninitialised value(s) ==2836066==at 0x4011E2: test (PR63311.c:41) ==2836066==by 0x401223: main (PR63311.c:130) ==2836066== Uninitialised value was created by a stack allocation ==2836066==at 0x40112D: test (PR63311.c:11) ==2836066== ==2836066== ==2836066== HEAP SUMMARY: ==2836066== in use at exit: 0 bytes in 0 blocks ==2836066== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==2836066== ==2836066== All heap blocks were freed -- no leaks are possible ==2836066== ==2836066== For lists of detected and suppressed errors, rerun with: -s ==2836066== ERROR SUMMARY: 4 errors from 1 contexts (suppressed: 0 from 0)
[Bug libgcj/44415] [5/6/7 regression] gmp multilib support broke bootstrap with static libgmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44415 Bug 44415 depends on bug 39747, which changed state. Bug 39747 Summary: Installation documentation should suggest building libgmp as PIC for building with libjava https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39747 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX
[Bug classpath/39747] Installation documentation should suggest building libgmp as PIC for building with libjava
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39747 Mark Wielaard changed: What|Removed |Added CC||mark at gcc dot gnu.org Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #9 from Mark Wielaard --- (In reply to Eric Gallager from comment #8) > Is this still relevant now that gcc no longer ships with java? No, not really.
[Bug preprocessor/19753] different LANG settings and ccache don't work together
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19753
Mark Wielaard changed:
What|Removed |Added
CC||mark at gcc dot gnu.org
--- Comment #4 from Mark Wielaard ---
Since then gcc/c-opts.c has been moved to gcc/c-family/c-opts.c which still
uses _("" and _("").
Note that there is also _("") used in some files.
All probably shouldn't be translated, since they also end up in the DWARF
output.
[Bug target/100217] [11/12 Regression] ICE when building valgrind testsuite with -march=z14 since r11-7552
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100217 --- Comment #13 from Mark Wielaard --- (In reply to Jakub Jelinek from comment #12) > For valgrind, the quick workaround would be -march=z13 when compiling the > s390x tests that have register long double variables. Yes, this works, if fpext and pfpo are build with -march=z13 they compile (and the tests pass under valgrind).
[Bug target/100217] [11/12 Regression] ICE when building valgrind testsuite with -march=z14 since r11-7552
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100217
--- Comment #11 from Mark Wielaard ---
BTW. Disabling that test in valgrind produces another crash in another test
that looks similar:
gcc -DHAVE_CONFIG_H -I. -I../../.. -I../../.. -I../../../include
-I../../../coregrind -I../../../include -I../../../VEX/pub -I../../../VEX/pub
-DVGA_s390x=1 -DVGO_linux=1 -DVGP_s390x_linux=1 -DVGPV_s390x_linux_vanilla=1
-Winline -Wall -Wshadow -Wno-long-long -g -m64 -c -o pfpo.o pfpo.c
during RTL pass: expand
pfpo.c: In function 'main':
pfpo.c:35:3: internal compiler error: in gen_rtx_SUBREG, at emit-rtl.c:1023
35 | asm volatile(".short 0x010a\n\t"
\
| ^~~
pfpo.c:146:15: note: in expansion of macro 'PFPO'
146 | d32 = PFPO(f128_in[j], long double, _Decimal32,
PFPO_F128_TO_D32,
| ^~~~
The whole PFPO define is:
#define PFPO(initial, src_type, dst_type, fn_code, round, ret_code, cc) \
({ \
register src_type src_reg asm("f4") = initial;\
register dst_type dst_reg asm("f0"); \
register unsigned long fn asm("0") = fn_code | (round & 0xf); \
register unsigned int ret asm("1"); \
asm volatile(".short 0x010a\n\t" \
"ipm %2\n\t" \
"srl %2,28\n\t" \
:"=f"(dst_reg), "=d"(ret), "=d" (cc) \
: "f"(src_reg), "d"(fn));\
ret_code = ret; \
dst_reg; \
})
[Bug debug/92442] Compiling Boost.Spirit.X3 code uses exuberant amount of RAM with -gpubnames
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92442 Mark Wielaard changed: What|Removed |Added CC||tromey at gcc dot gnu.org --- Comment #11 from Mark Wielaard --- (In reply to Richard Biener from comment #10) > Mark, you're looking after -gsplit-dwarf - can you comment on whether we can > drop the -gpubnames "requirement"? We discussed this a bit on irc. The only reason for the pubnames seems to be that gold can generate .gdb_index from it. Although it isn't clear if this usage is common. gdb itself doesn't seem to use pubnames.
[Bug target/99488] dwz: /usr/lib/gcc/mips64el-linux-gnuabi64/11/go1: Found two copies of .debug_line_str section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99488 --- Comment #8 from Mark Wielaard --- On Mon, 2021-03-15 at 12:21 +, jakub at gcc dot gnu.org wrote: > --- Comment #7 from Jakub Jelinek --- > [43] .debug_line_str MIPS_DWARF ecf07bf 0066e6 01 > MS > 0 0 1 > [44] .debug_line_str MIPS_DWARF ecf6ea5 0005d1 01 > MS > 0 0 1 > Thus, doesn't seem to be dwz fault, the two .debug_line_str sections is > something unexpected. But that is odd. It has the same name, section type, flags (merge strings) and alignment. Why didn't the linker merge these? The only difference with other arches would be the MIPS_DWARF instead of PROGBITS type. But that shouldn't really matter to the linker.
[Bug target/99488] dwz: /usr/lib/gcc/mips64el-linux-gnuabi64/11/go1: Found two copies of .debug_line_str section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99488 --- Comment #3 from Mark Wielaard --- So gcc/dwarf2out.c creates it as: #define DEBUG_STR_SECTION_FLAGS \ (HAVE_GAS_SHF_MERGE && flag_merge_debug_strings \ ? SECTION_DEBUG | SECTION_MERGE | SECTION_STRINGS | 1\ : SECTION_DEBUG) debug_line_str_section = get_section (DEBUG_LINE_STR_SECTION, DEBUG_STR_SECTION_FLAGS, NULL); And gas/dwarf2dbg.c sets the flags as: bfd_set_section_flags (line_str_seg, SEC_READONLY | SEC_DEBUGGING | SEC_OCTETS | SEC_MERGE | SEC_STRINGS); I hope that results in the same section type/flags set. But you should probably check because MIPS has some special cases.
[Bug debug/99490] -gdwarf-5 -gsplit-dwarf puts .debug_rnglists to main file, not .dwo file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99490 --- Comment #5 from Mark Wielaard --- I don't believe it is a requirement to generate a separate .debug_rnglists.dwo section, the spec says the same data can be provided in the .debug_rnglists section and gdb and elfutils handle that just fine for split dwarf. If we would generate a .debug_rnglists.dwo section then we have to make sure it only contains DW_RLE_ entries that don't require relocations (like we already do for .loclists and DW_LLE_ entries).
[Bug web/98875] DWARF5 as default causes perf probe to hang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98875 Mark Wielaard changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Mark Wielaard --- Hopefully https://gcc.gnu.org/gcc-11/changes.html now lists the DWARF5 requirements correctly. gcc-wwwdocs commit 80dc53f6b38d697b169fad9ce3b8787ce1c6768c (HEAD -> master, origin/master, origin/HEAD) Author: Mark Wielaard Date: Fri Feb 19 18:02:19 2021 +0100 Document the GCC11 change to DWARF5 default. * gcc-11/changes.html (General Improvements): Add a section on the DWARF version 5 default.
[Bug debug/99178] Emit .debug_names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99178 --- Comment #3 from Mark Wielaard --- So if the compiler would emit the .debug_name index would that make any link/post-processing steps easier or more efficient?
[Bug web/98875] DWARF5 as default causes perf probe to hang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98875 --- Comment #5 from Mark Wielaard --- https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565587.html
[Bug web/98875] DWARF5 as default causes perf probe to hang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98875 Mark Wielaard changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |mark at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-02-19 Component|debug |web --- Comment #4 from Mark Wielaard --- (In reply to Paul Clarke from comment #3) > The IBM Advance Toolchain supports SLES 15, where the latest version of > libdw is 0.168. We'll work around the issue by reverting the commit for the > version of GCC included with the Advance Toolchain. Yes, that is probably reasonable when targetting a distro that is so old that it doesn't have any tooling to support DWARF5. Still you might want to request that the perf tool be fixed to simply skip the DWARF5 data instead of going into an infinite loop. That bug could trigger for any DWARF that old perf/libdw doesn't know about and it really should just skip it. The fix for that really is just a oneliner. > I didn't see any update to the GCC documentation regarding the disruptive > nature of the change causing the problem other than "[DWARF] Version 5 > requires GDB 8.0 or higher". > > Should there be something about libdw as well? Anything else? You are right. I'll submit an update for the GCC 11 Release Notes to document things.
[Bug debug/98875] DWARF5 as default causes perf probe to hang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98875 Mark Wielaard changed: What|Removed |Added CC||mark at gcc dot gnu.org --- Comment #2 from Mark Wielaard --- I didn't realize this was also posted as a bug. There was some discussion on the gcc-patches mailinglist here: https://gcc.gnu.org/pipermail/gcc-patches/2021-January/thread.html#564485 The conclusion was that this was simply because of some ancient installation of elfutils/libdw (0.168, which is from before the DWARF5 spec was released). Make sure you have elfutils libdw version 0.172 or newer when dealing with DWARF5. Latest elfutils release is 0.183. I believe this issue can be closed, or are there any other issues with perf?
[Bug rtl-optimization/98692] Unitialized Values reported only with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692 --- Comment #18 from Mark Wielaard --- The current thinking (Julian did the thinking, I am just repeating) is that this is caused by the way the _savegpr and/or restgpr functions return using blr. PPC has two special "lets zap the red zone" (the 288 bytes below the stack pointer) cases: # define VG_STACK_REDZONE_SZB288 // number of addressable bytes below R1 // from 64-bit PowerPC ELF ABI // Supplement 1.7 guest_ppc_zap_RZ_at_blr guest is ppc64-linux==> True guest is ppc32-linux==> False guest is other ==> inapplicable guest_ppc_zap_RZ_at_bl guest is ppc64-linux==> const True guest is ppc32-linux==> const False guest is other ==> inapplicable guest_stack_redzone_size guest is ppc32-linux==> 0 guest is ppc64-linux==> 288 guest is amd64-linux==> 128 guest is other ==> inapplicable /* PPC and AMD64 GUESTS only: how many bytes below the stack pointer are validly addressible? */ Int guest_stack_redzone_size; /* PPC GUESTS only: should we zap the stack red zone at a 'blr' (function return) ? */ Bool guest_ppc_zap_RZ_at_blr; /* PPC GUESTS only: should we zap the stack red zone at a 'bl' (function call) ? Is supplied with the guest address of the target of the call since that may be significant. If NULL, is assumed equivalent to a fn which always returns False. */ Bool (*guest_ppc_zap_RZ_at_bl)(Addr); # if defined(VGP_ppc32_linux) vex_abiinfo.guest_ppc_zap_RZ_at_blr= False; vex_abiinfo.guest_ppc_zap_RZ_at_bl = NULL; # endif # if defined(VGP_ppc64be_linux) vex_abiinfo.guest_ppc_zap_RZ_at_blr= True; vex_abiinfo.guest_ppc_zap_RZ_at_bl = const_True; vex_abiinfo.host_ppc_calls_use_fndescrs= True; # endif # if defined(VGP_ppc64le_linux) vex_abiinfo.guest_ppc_zap_RZ_at_blr= True; vex_abiinfo.guest_ppc_zap_RZ_at_bl = const_True; vex_abiinfo.host_ppc_calls_use_fndescrs= False; # endif What happens on a blr function return is that, based on the guest_ppc_zap_RZ_at_blr value, the redzone is marked as containing undefined values. And indeed, with this patch: diff --git a/coregrind/m_translate.c b/coregrind/m_translate.c index 332202a91..6dd01afac 100644 --- a/coregrind/m_translate.c +++ b/coregrind/m_translate.c @@ -1709,7 +1709,7 @@ Bool VG_(translate) ( ThreadId tid, # endif # if defined(VGP_ppc64le_linux) - vex_abiinfo.guest_ppc_zap_RZ_at_blr= True; + vex_abiinfo.guest_ppc_zap_RZ_at_blr= False; vex_abiinfo.guest_ppc_zap_RZ_at_bl = const_True; vex_abiinfo.host_ppc_calls_use_fndescrs= False; # endif The warning goes away. But is that the right thing to do always? It seems to mask issues where a function is using the red zone values set by another function.
[Bug rtl-optimization/98692] Unitialized Values reported only with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692 --- Comment #17 from Mark Wielaard --- Thanks for the step-by-step explanation of the assembly instructions and calling conventions. (In reply to Segher Boessenkool from comment #16) > (In reply to Mark Wielaard from comment #13) > > ==25741== Use of uninitialised value of size 8 > > ==25741==at 0x1504: main (pr9862.C:16) > > r4 is argv here > >0x14f0 <+16>:ld r3,0(r4) > r3 = argv[0]; > >0x14f4 <+20>:mr r31,r4 > r31 = argv; // because we need it after the call, save it in a non-volatile > reg > >0x14f8 <+24>:std r0,16(r1) > >0x14fc <+28>:stdur1,-48(r1) > >0x1500 <+32>:bl 0x16b4 > The call; after this we have to load argv[0] again, the called function might > have changed it. > >0x1504 <+36>:ld r3,0(r31) > r3 = argv[0]; > > So it is funny that the exact same insn four insns earlier (in the program > text) > worked fine, but this one fails. The different (according to valgrind) is that r4 has a defined value, while it believes r31 has an undefined value after the isVariable call. > The ABI says (taken from the ELFv1 ABI, the ELFv2 doc is not nice for > copy/paste): > > > Here is a sample implementation of _savegpr0_N and _restgpr0_N. > > _savegpr0_14: std r14,-144(r1) > _savegpr0_15: std r15,-136(r1) > _savegpr0_16: std r16,-128(r1) > _savegpr0_17: std r17,-120(r1) > _savegpr0_18: std r18,-112(r1) > _savegpr0_19: std r19,-104(r1) > _savegpr0_20: std r20,-96(r1) > _savegpr0_21: std r21,-88(r1) > _savegpr0_22: std r22,-80(r1) > _savegpr0_23: std r23,-72(r1) > _savegpr0_24: std r24,-64(r1) > _savegpr0_25: std r25,-56(r1) > _savegpr0_26: std r26,-48(r1) > _savegpr0_27: std r27,-40(r1) > _savegpr0_28: std r28,-32(r1) > _savegpr0_29: std r29,-24(r1) > _savegpr0_30: std r30,-16(r1) > _savegpr0_31: std r31,-8(r1) > std r0, 16(r1) > blr > _restgpr0_14: ld r14,-144(r1) > _restgpr0_15: ld r15,-136(r1) > _restgpr0_16: ld r16,-128(r1) > _restgpr0_17: ld r17,-120(r1) > _restgpr0_18: ld r18,-112(r1) > _restgpr0_19: ld r19,-104(r1) > _restgpr0_20: ld r20,-96(r1) > _restgpr0_21: ld r21,-88(r1) > _restgpr0_22: ld r22,-80(r1) > _restgpr0_23: ld r23,-72(r1) > _restgpr0_24: ld r24,-64(r1) > _restgpr0_25: ld r25,-56(r1) > _restgpr0_26: ld r26,-48(r1) > _restgpr0_27: ld r27,-40(r1) > _restgpr0_28: ld r28,-32(r1) > _restgpr0_29: ld r0, 16(r1) > ld r29,-24(r1) > mtlr r0 > ld r30,-16(r1) > ld r31,-8(r1) > blr > _restgpr0_30: ld r30,-16(r1) > _restgpr0_31: ld r0, 16(r1) > ld r31,-8(r1) > mtlr r0 > blr > > So this is one function with many entry points you could say. Maybe that is > what confused valgrind? So for some reason valgrind doesn't believe the stack value for -8(r1) is valid when r31 is restored. What seems to confuse valgrind is: 0x16c0 <+20>:bl 0x1820 <_savegpr0_25> 0x16c4 <+24>:stdur1,-128(r1) [...] 0x1720 <+116>: addir1,r1,128 0x1724 <+120>: b 0x1844 <_restgpr0_25> It looks like it interprets those stack pointer moves as invalidating the values stored on the stack.
[Bug rtl-optimization/98692] Unitialized Values reported only with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692
--- Comment #13 from Mark Wielaard ---
I could replicate this with gcc 9.1.1 with the following source:
#define variables (const char* []){ "PK", "KEK", "db"}
int ret, len;
void isVariable(char *var)
{
for (int v = 0; v < 2; v++)
if (__builtin_strncmp(var,variables[v], 2) == 0)
ret = 0;
}
int main(int argc, char* argv[])
{
// __builtin_printf ("argv[0]=%s\n", argv[0]);
isVariable(argv[0]);
len = __builtin_strlen (argv[0]);
return 0;
}
compiled with gcc -g -Os and valgrind from git trunk with --vgdb=full
--track-origins=yes:
==25741== Command: ./a.out
==25741==
==25741== Use of uninitialised value of size 8
==25741==at 0x1504: main (pr9862.C:16)
==25741== Uninitialised value was created by a stack allocation
==25741==at 0x16C4: isVariable(char*) (pr9862.C:6)
==25741==
Disassambly of main and isVariable
Dump of assembler code for function main(int, char**):
0x14e0 <+0>: lis r2,4098
0x14e4 <+4>: addir2,r2,32512
0x14e8 <+8>: mflrr0
0x14ec <+12>:std r31,-8(r1)
0x14f0 <+16>:ld r3,0(r4)
0x14f4 <+20>:mr r31,r4
0x14f8 <+24>:std r0,16(r1)
0x14fc <+28>:stdur1,-48(r1)
0x1500 <+32>:bl 0x16b4
0x1504 <+36>:ld r3,0(r31)
0x1508 <+40>:bl 0x14a0
<0023.plt_call.strlen@@GLIBC_2.17>
0x150c <+44>:ld r2,24(r1)
0x1510 <+48>:nop
0x1514 <+52>:addir1,r1,48
0x1518 <+56>:stw r3,-32452(r2)
0x151c <+60>:li r3,0
0x1520 <+64>:b 0x186c <_restgpr0_31>
0x1524 <+68>:.long 0x0
0x1528 <+72>:.long 0x1000900
0x152c <+76>:.long 0x180
End of assembler dump.
Dump of assembler code for function isVariable(char*):
0x16ac <+0>: lis r2,4098
0x16b0 <+4>: addir2,r2,32512
0x16b4 <+8>: mflrr0
0x16b8 <+12>:addis r9,r2,-2
0x16bc <+16>:addir9,r9,-30152
0x16c0 <+20>:bl 0x1820 <_savegpr0_25>
0x16c4 <+24>:stdur1,-128(r1)
0x16c8 <+28>:ld r29,0(r9)
0x16cc <+32>:ld r28,8(r9)
0x16d0 <+36>:nop
0x16d4 <+40>:mr r30,r3
0x16d8 <+44>:ld r27,16(r9)
0x16dc <+48>:li r31,0
0x16e0 <+52>:addir25,r2,-32456
0x16e4 <+56>:addir26,r1,32
0x16e8 <+60>:std r29,32(r1)
0x16ec <+64>:std r28,40(r1)
0x16f0 <+68>:rldicr r9,r31,3,60
0x16f4 <+72>:li r5,2
0x16f8 <+76>:std r27,48(r1)
0x16fc <+80>:mr r3,r30
0x1700 <+84>:ldx r4,r26,r9
0x1704 <+88>:bl 0x14c0
<0023.plt_call.strncmp@@GLIBC_2.17>
0x1708 <+92>:ld r2,24(r1)
0x170c <+96>:mr. r9,r3
0x1710 <+100>: bne 0x1718
0x1714 <+104>: stw r9,0(r25)
0x1718 <+108>: cmpldi r31,1
0x171c <+112>: bne 0x1728
0x1720 <+116>: addir1,r1,128
0x1724 <+120>: b 0x1844 <_restgpr0_25>
0x1728 <+124>: li r31,1
0x172c <+128>: b 0x16e8
0x1730 <+132>: .long 0x0
0x1734 <+136>: .long 0x1000900
0x1738 <+140>: .long 0x780
End of assembler dump.
[Bug rtl-optimization/98692] Unitialized Values reported only with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692 --- Comment #12 from Mark Wielaard --- OK, so according to memcheck the load uses a pointer value that isn't initialized properly. And it thinks that value originated from a stack value in the isVariable call. Unfortunately my powerpc assembly is not strong enough to know how to read this precisely, what the calling conventions are and how the address is setup in isVariable.
[Bug rtl-optimization/98692] Unitialized Values reported only with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692 --- Comment #10 from Mark Wielaard --- (In reply to Will Schmidt from comment #9) > (In reply to Segher Boessenkool from comment #5) > > Have you tried a new valgrind? > > > > Either this is (or was) a known problem in valgrind, or it is related to > > one. Cc:ing Aaron, he might know more (he wrote the GCC optimisations > > that expose the problem). > > > I've recreated against new (built out of upstream git) valgrind: > with --track-origins=yes > > > ==37507== > argv[0]=./a.out > ==37507== Use of uninitialised value of size 8 > ==37507==at 0x1618: main (pr9862.C:16) > ==37507== Uninitialised value was created by a stack allocation > ==37507==at 0x17D4: isVariable(char*) (pr9862.C:5) Trying to get hold of a ppc64 setup. But could you try with --vgdb-error=0 and then (in another window) gdb ./a.out and target remote | vgdb and continue till you get the TRAP. Then disassamble so we can see the exact instruction that generates the use of uninitialised value?
[Bug debug/98811] [11 regression] All Go tests FAIL with abbrev offset out of range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98811 --- Comment #3 from Mark Wielaard --- (In reply to r...@cebitec.uni-bielefeld.de from comment #2) > If the DWARF-5 support depends on specific binutils versions/patches to > work, this should both be documented and detected at configure time. > Having users run into such complete failure as in the Go case is a very > bad user experience IMO. I believe it already does. There are some known issues with debug_line generation that gcc configure should detect and disable if a bad/old binutils is detected. But given your experience there might be other bugs, but I don't which they are. If you know which binutils patch fixes it then we might be able to create a configure test for it.
[Bug debug/98811] [11 regression] All Go tests FAIL with abbrev offset out of range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98811 --- Comment #1 from Mark Wielaard --- (In reply to Rainer Orth from comment #0) > However, when I switched to > the freshly released GNU as 2.36 today, the error vanished everywhere. Which GNU as were you using before? There were some bug fixes for 2.35 which never made it into a released version: https://sourceware.org/pipermail/binutils/2020-November/114152.html
[Bug debug/98755] [11 regression] r11-6755 causes failure in g++.dg/debug/dwarf2/constexpr-var-1.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98755 Mark Wielaard changed: What|Removed |Added Build|powerpc64*-linux-gnu| Target|powerpc64*-linux-gnu| Host|powerpc64*-linux-gnu| CC||jakub at redhat dot com, ||jason at redhat dot com, ||law at gcc dot gnu.org --- Comment #1 from Mark Wielaard --- This isn't ppc64 specific and was also reported in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98728 > This is https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552474.html > There is a suggested fix, but no consensus on whether that is a good one: > https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553102.html
[Bug debug/98728] [11 regression] Several debug tests FAIL with DWARF-5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98728 Mark Wielaard changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from Mark Wielaard --- Since the second issue was fixed lets close this and track the other issue in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98755
[Bug debug/98728] [11 regression] Several debug tests FAIL with DWARF-5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98728 --- Comment #2 from Mark Wielaard --- (In reply to Mark Wielaard from comment #1) > Maybe this bug should be split in two (or three) for each specific FAIL? > > (In reply to Rainer Orth from comment #0) > > With the switch to DWARF-5, two debug tests have started to FAIL: > > [...] > > +FAIL: gcc.dg/debug/dwarf2/dwarf-float.c scan-assembler > > 0x10.*DW_AT_byte_size > > > > 32-bit Solaris/x86 and Linux/x86_64 > > So this fails in 32bit mode, but not in 64bit mode. > > In 64bit mode gcc generates: > > .uleb128 0x2# (DIE (0x7d) DW_TAG_base_type) > .byte 0x10# DW_AT_byte_size > # DW_AT_encoding (0x4) > .long .LASF4 # DW_AT_name: "long double" > > But in 32bit mode it generates: > > .uleb128 0x2# (DIE (0x6d) DW_TAG_base_type) > .byte 0xc # DW_AT_byte_size > # DW_AT_encoding (0x4) > .long .LASF4 # DW_AT_name: "long double" This part has been fixed by Jeff: https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563840.html
[Bug debug/98716] [11 Regression] sanitizer regressions by r11-6755
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98716 --- Comment #9 from Mark Wielaard --- (In reply to Mark Wielaard from comment #7) > (In reply to Ian Lance Taylor from comment #5) > > I'm not seeing any failures in the Go testsuite with GNU binutils 2.35.1. > > Anybody know what changed in newer version of the binutils? > > The difference is that with binutils 2.36 (not released yet) gas generates > when asked to (with -gdwarf-5) DWARF 5 line tables. While 2.35.1 always > generated DWARF 4 line tables. Actually 2.35.1 does already have support for -gdwarf-5, but had some bugs which are detected by gcc configure, so that it is not used. The bugs were fixed on the 2.35 branch, but there is no 2.35.2 release (yet?). Anyway. The difference is the gcc configure check for HAVE_AS_WORKING_DWARF_N_FLAG.
[Bug debug/98716] [11 Regression] sanitizer regressions by r11-6755
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98716 --- Comment #8 from Mark Wielaard --- (In reply to Ian Lance Taylor from comment #6) > On the other hand the libbacktrace testsuite now fails when using dwz > 0.13+20201015-2. But I guess that is not a GCC problem. > > dwz -m b3test_dwz_common.debug b3test_dwz_1 b3test_dwz_2 > dwz: b3test_dwz_1: Unknown DWARF DW_FORM_implicit_const > dwz: b3test_dwz_1: Couldn't read abbrev at offset 0x0 > dwz: b3test_dwz_2: Unknown DWARF DW_FORM_implicit_const > dwz: b3test_dwz_2: Couldn't read abbrev at offset 0x0 > dwz: Too few files for multifile optimization > make[3]: *** [Makefile:2436: b3test_dwz] Error 1 Yes, you need the following upstream patch (already in Fedora rawhide): https://sourceware.org/pipermail/dwz/2021q1/000775.html
[Bug debug/98716] [11 Regression] sanitizer regressions by r11-6755
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98716 --- Comment #7 from Mark Wielaard --- (In reply to Ian Lance Taylor from comment #5) > I'm not seeing any failures in the Go testsuite with GNU binutils 2.35.1. > Anybody know what changed in newer version of the binutils? The difference is that with binutils 2.36 (not released yet) gas generates when asked to (with -gdwarf-5) DWARF 5 line tables. While 2.35.1 always generated DWARF 4 line tables.
[Bug debug/98728] [11 regression] Several debug tests FAIL with DWARF-5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98728 Mark Wielaard changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org --- Comment #1 from Mark Wielaard --- Hi, Maybe this bug should be split in two (or three) for each specific FAIL? (In reply to Rainer Orth from comment #0) > With the switch to DWARF-5, two debug tests have started to FAIL: > > +FAIL: g++.dg/debug/dwarf2/constexpr-var-1.C scan-assembler-times > DW_AT_const_expr 2 > > 32 and 64-bit Solaris/SPARC and x86, Linux/x86_64 This is https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552474.html There is a suggested fix, but no consensus on whether that is a good one: https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553102.html > +FAIL: gcc.dg/debug/dwarf2/dwarf-float.c scan-assembler 0x10.*DW_AT_byte_size > > 32-bit Solaris/x86 and Linux/x86_64 So this fails in 32bit mode, but not in 64bit mode. In 64bit mode gcc generates: .uleb128 0x2# (DIE (0x7d) DW_TAG_base_type) .byte 0x10# DW_AT_byte_size # DW_AT_encoding (0x4) .long .LASF4 # DW_AT_name: "long double" But in 32bit mode it generates: .uleb128 0x2# (DIE (0x6d) DW_TAG_base_type) .byte 0xc # DW_AT_byte_size # DW_AT_encoding (0x4) .long .LASF4 # DW_AT_name: "long double" > Besides, there were many changes to guality tests on Linux/x86_64, both tests > previously XPASSing now XFAIL again, as well as several new FAILs. The guality tests are a little fragile, they also depend on the gdb version installed.
[Bug debug/98708] [11 Regression] cxx11-ios_failure-lt.s:36733: Error: file number less than one by r11-6755
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98708
--- Comment #12 from Mark Wielaard ---
On the binutils gas side it could be as simple as turning the error into a
warning:
diff --git a/gas/dwarf2dbg.c b/gas/dwarf2dbg.c
index a428370ecca..a216bfd6b28 100644
--- a/gas/dwarf2dbg.c
+++ b/gas/dwarf2dbg.c
@@ -1044,7 +1044,7 @@ dwarf2_directive_filename (void)
if ((offsetT) num < 1 && DWARF2_LINE_VERSION < 5)
{
- as_bad (_("file number less than one"));
+ as_warn (_("file number less than one, ignored"));
ignore_rest_of_line ();
return NULL;
}
@@ -1143,7 +1143,8 @@ dwarf2_directive_loc (int dummy ATTRIBUTE_UNUSED)
{
if (filenum != 0 || DWARF2_LINE_VERSION < 5)
{
- as_bad (_("file number less than one"));
+ as_warn (_("file number less than one, ignored"));
+ ignore_rest_of_line ();
return;
}
}
diff --git a/gas/testsuite/gas/lns/lns-diag-1.l
b/gas/testsuite/gas/lns/lns-diag-1.l
index 1256e85cfcb..d8aa84d9d1a 100644
--- a/gas/testsuite/gas/lns/lns-diag-1.l
+++ b/gas/testsuite/gas/lns/lns-diag-1.l
@@ -1,5 +1,5 @@
.*: Assembler messages:
-.*:2: Error: file number less than one
+.*:2: Warning: file number less than one, ignored
.*:3: Error: missing string
.*:4: Error: file table slot 1 is already occupied.*
.*:8: Error: unassigned file number 3
@@ -9,7 +9,7 @@
.*:19: Error: bad or irreducible absolute expression
.*:23: Error: isa number less than zero
.*:26: Error: bad or irreducible absolute expression
-.*:26: Error: file number less than one
+.*:26: Warning: file number less than one, ignored
.*:27: Error: bad or irreducible absolute expression
.*:28: Error: unknown .loc sub-directive `frobnitz'
.*:29: Error: unknown .loc sub-directive `frobnitz'
[Bug debug/98708] [11 Regression] cxx11-ios_failure-lt.s:36733: Error: file number less than one by r11-6755
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98708 --- Comment #11 from Mark Wielaard --- Aha, now I see in libstdc++-v3/src/c++11/Makefile.am: if ENABLE_DUAL_ABI # Rewrite the type info for __ios_failure. rewrite_ios_failure_typeinfo = sed -e '/^_*_ZTISt13__ios_failure:/,/_ZTVN10__cxxabiv120__si_class_type_infoE/s/_ZTVN10__cxxabiv120__si_class_type_infoE/_ZTVSt19__iosfail_type_info/' cxx11-ios_failure-lt.s: cxx11-ios_failure.cc $(LTCXXCOMPILE) -S $< -o tmp-cxx11-ios_failure-lt.s -test -f tmp-cxx11-ios_failure-lt.o && mv -f tmp-cxx11-ios_failure-lt.o tmp-cxx11-ios_failure-lt.s $(rewrite_ios_failure_typeinfo) tmp-$@ > $@ -rm -f tmp-$@ cxx11-ios_failure.s: cxx11-ios_failure.cc $(CXXCOMPILE) -S $< -o tmp-$@ $(rewrite_ios_failure_typeinfo) tmp-$@ > $@ -rm -f tmp-$@ cxx11-ios_failure.lo: cxx11-ios_failure-lt.s $(LTCXXCOMPILE) -g0 -c $< -o $@ cxx11-ios_failure.o: cxx11-ios_failure.s $(CXXCOMPILE) -g0 -c $< endif Then my workaround of checking for debug_info_level > DINFO_LEVEL_NONE indeed wouldn't work. It is explicitly generating debuginfo for the assembly file and then adding -g0 when turning the assembly file into an object file. So that is too late. I don't think adding -gno-as-loc-support to the -S invocation will work because of the definition of asm_outputs_debug_line_str () which is true if dwarf_version >= 5 && ! output_asm_line_debug_info () && DWARF5_USE_DEBUG_LINE_STR. So then it will still generate the .file 0 directive. Ideally gas wouldn't error on .file 0, but simply ignore it when not generating DWARF5. Maybe the simplest workaround for now would be also adding -g0 to the -S invocations?
[Bug debug/98708] [11 Regression] cxx11-ios_failure-lt.s:36733: Error: file number less than one by r11-6755
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98708
--- Comment #8 from Mark Wielaard ---
I am not sure where the -g -O2 -g0 comes from. I must have missed this in my
testing.
The issue is the .file 0 directive, which is special to gas (only valid with
-gdwarf-5).
It is generated by dwarf2out_finish ():
/* Output the source line correspondence table. We must do this
even if there is no line information. Otherwise, on an empty
translation unit, we will generate a present, but empty,
.debug_info section. IRIX 6.5 `nm' will then complain when
examining the file. This is done late so that any filenames
used by the debug_info section are marked as 'used'. */
switch_to_section (debug_line_section);
ASM_OUTPUT_LABEL (asm_out_file, debug_line_section_label);
if (! output_asm_line_debug_info ())
output_line_info (false);
else if (asm_outputs_debug_line_str ())
{
/* When gas outputs DWARF5 .debug_line[_str] then we have to
tell it the comp_dir and main file name for the zero entry
line table. */
const char *comp_dir, *filename0;
comp_dir = comp_dir_string ();
if (comp_dir == NULL)
comp_dir = "";
filename0 = get_AT_string (comp_unit_die (), DW_AT_name);
if (filename0 == NULL)
filename0 = "";
fprintf (asm_out_file, "\t.file 0 ");
output_quoted_string (asm_out_file, remap_debug_filename (comp_dir));
fputc (' ', asm_out_file);
output_quoted_string (asm_out_file, remap_debug_filename (filename0));
fputc ('\n', asm_out_file);
}
So it looks like the asm_outputs_debug_line_str () is wrong:
/* Returns TRUE if we are outputting DWARF5 and the assembler supports
DWARF5 .debug_line tables using .debug_line_str or we generate
it ourselves, except for split-dwarf which doesn't have a
.debug_line_str. */
static bool
asm_outputs_debug_line_str (void)
{
if (dwarf_version >= 5
&& ! output_asm_line_debug_info ()
&& DWARF5_USE_DEBUG_LINE_STR)
return true;
else
{
#if defined(HAVE_AS_GDWARF_5_DEBUG_FLAG) &&
defined(HAVE_AS_WORKING_DWARF_N_FLAG)
return !dwarf_split_debug_info && dwarf_version >= 5;
#else
return false;
#endif
}
}
It probably should check debug_info_level > DINFO_LEVEL_NONE.
[Bug lto/48200] Implement function attribute for symbol versioning (.symver)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200 --- Comment #45 from Mark Wielaard --- Note that the hack in comment 43 doesn't really work with elfutils since the .symver attribute doesn't work exactly like the assembly construct with @@@. The @@@ symver variant see https://sourceware.org/binutils/docs/as/Symver.html The third usage of the .symver directive is: .symver name, name2@@@nodename When name is not defined within the file being assembled, it is treated as name2@nodename. When name is defined within the file being assembled, the symbol name, name, will be changed to name2@@nodename. Which means it is renamed, so that it doesn't clash when used in a version map file.
[Bug ada/97541] Ada failed to bootstrap: Error: file table slot 1 is already occupied by a different file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97541
--- Comment #5 from Mark Wielaard ---
(In reply to Jakub Jelinek from comment #4)
> # 82 "s-atocou.adb" 1
> isn't a .file assignment though.
> As I said earlier, if we don't want to revert the r11-3693 change and be
> able to specify -gdwarf-5 etc. to gas even when compiling files that contain
> explicit .debug_info from the compiler, then we need gas to act as if all
> that option affects is the version of the .debug_line emitted for explicit
> .file*/.loc* directives if present and nothing else (whenever the assembly
> contains manual
> .file*/.loc* directives or .debug_{info,line,...} sections).
That is the intention indeed, and I believe that is what binutils gas should be
doing. There used to be a bug where that didn't work for .file 1, but I thought
that was fixed upstream. Is this different from
https://sourceware.org/bugzilla/show_bug.cgi?id=26740
The assembly posted doesn't seem complete, what does ada really pass to gas?
> So, basically,
> gas can start preparing for generation of its own .debug_* sections but
> should roll all that back when it sees .file/.loc directives or user
> .debug_{info,line} sections (perhaps some others).
Like I said above, that is the intention. So if it doesn't work like that it is
simply a bug in gas. It would be helpful to attach the preprocessed file that
ada generates to investigate what is really going on.
> Or, the other option is not to pass -gdwarf-5 to gas, but pass
> -gdwarf-line-version=5 or whatever other new option, which would only change
> the decision on if gas emits .debug_line section because of .file*/.loc*
> directives (and .debug_line is not present), what version of that to use.
That would be another option. But I like to first understand what is really
going on here.
[Bug bootstrap/97355] [11 Regression] Bootstrap comparison failure!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97355 --- Comment #15 from Mark Wielaard --- (In reply to Jakub Jelinek from comment #14) > In any case, the change to use -gdwarf-* by default even when not compiling > just assembly was based on the assumption that gas would in that case pretty > much only change the format of the .debug_line section generated from > .file/.loc directives, but certainly not append anything on top of that > itself (e.g. append some stuff to the compiler emitted .debug* sections). Right, that was certainly the intention. I believe it is simply a bug is gas where a file is kept that isn't used and put into the file table anyway: https://sourceware.org/bugzilla/show_bug.cgi?id=26740#c1 There is already a patch to fix it: https://sourceware.org/pipermail/binutils/2020-October/113741.html We just have to double check with Nick this is really what his original code was intended to do.
[Bug bootstrap/97355] [11 Regression] Bootstrap comparison failure!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97355 --- Comment #11 from Mark Wielaard --- I don't understand why the .debug sections are compared in this case. But if they are then the diff comes from this gas issue: https://sourceware.org/bugzilla/show_bug.cgi?id=26740 Even though unused gas -g might emit the input file name in the file table in some situations. It is harmless but since the the generated assembly file name might be different between stage2 and stage3 you will see a diff. If this really is an issue I think a workaround might be to make sure that the .file 1 directive is emitted as early as possible.
[Bug analyzer/95188] analyzer-unsafe-call-within-signal-handler shows wrong statement for signal registration event
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95188 --- Comment #12 from Mark Wielaard --- (In reply to David Malcolm from comment #11) > (In reply to Mark Wielaard from comment #10) > > Created attachment 49293 [details] > > supergraph > > Thanks. Compared to my testing, I'm seeing what appear to be differences in > the inputs to the analyzer at the gimple level, which are likely due to > differences in the rest of the compiler. > > Is this with the same version of gcc as in comment #4, where you said "gcc > (GCC) 11.0.0 20200916 (experimental)". > > You don't happen to know exactly which revision, do you? I am afraid I don't know exactly. I have been experimenting with having DWARF 5 as default in my builds, which is another difference. > [The md5sum of the bzip2.c I'm using is 23f66348f80345353d5b5b98e299ff15. > There could also be differences in the system headers, I suppose] The MD5 matches. But I am indeed using system headers from RHEL7 with DTS9 installed to bootstrap my GCC builds.
[Bug analyzer/95188] analyzer-unsafe-call-within-signal-handler shows wrong statement for signal registration event
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95188 --- Comment #10 from Mark Wielaard --- Created attachment 49293 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49293=edit supergraph > Mark: please can you add -fdump-analyzer-supergraph to the arguments and > attach > the bzip2.c.supergraph.dot file to this bug. Doing so may help > track down (d). gcc -g -O2 -fanalyzer -fdump-analyzer-supergraph -c bzip2.c
[Bug analyzer/95188] analyzer-unsafe-call-within-signal-handler shows wrong statement for signal registration event
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95188 --- Comment #6 from Mark Wielaard --- Created attachment 49291 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49291=edit Output for gcc -Wanalyzer-too-complex -g -O2 -fanalyzer -c bzip2.c (In reply to David Malcolm from comment #5) > Thanks Mark. What architecture are you on? RHEL7 x86_64. > When I do those steps, there's a long wait and then in terminates with no > analyzer output. > > If I add -Wanalyzer-too-complex I see lots of warnings about "terminating > analysis for this program point". > > What do you see if you add -Wanalyzer-too-complex? Lots and lots of output saying "warning: terminating analysis for this program point". log attached.
[Bug analyzer/95188] analyzer-unsafe-call-within-signal-handler shows wrong statement for signal registration event
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95188
--- Comment #4 from Mark Wielaard ---
Note that I can replicate it with the instructions in the description and gcc
git: gcc (GCC) 11.0.0 20200916 (experimental)
$ /opt/local/install/gcc/bin/gcc -g -O2 -fanalyzer -c bzip2.c 2>&1 | head -25
bzip2.c: In function ‘showFileNames.part.0’:
bzip2.c:677:4: warning: call to ‘fprintf’ from within signal handler [CWE-479]
[-Wanalyzer-unsafe-call-within-signal-handler]
677 |fprintf (
|^
678 | stderr,
| ~~~
679 | "\tInput file = %s, output file = %s\n",
|
680 | inName, outName
| ~~~
681 |);
|~
‘main’: events 1-2
|
| 1776 | IntNative main ( IntNative argc, Char *argv[] )
| | ^~~~
| | |
| | (1) entry to ‘main’
| 1777 | {
| 1778 |Int32 i, j;
| |~
| ||
| |(2) registering ‘mySIGSEGVorSIGBUScatcher’ as signal handler
|
event 3
It doesn't point at smallMode anymore, but the Int32 type isn't the right place
either.
For reference this is the main method starting at line 1776:
IntNative main ( IntNative argc, Char *argv[] )
{
Int32 i, j;
Char *tmp;
Cell *argList;
Cell *aa;
Bool decode;
/*-- Be really really really paranoid :-) --*/
if (sizeof(Int32) != 4 || sizeof(UInt32) != 4 ||
sizeof(Int16) != 2 || sizeof(UInt16) != 2 ||
sizeof(Char) != 1 || sizeof(UChar) != 1)
configError();
/*-- Initialise --*/
outputHandleJustInCase = NULL;
smallMode = False;
keepInputFiles = False;
forceOverwrite = False;
noisy = True;
verbosity = 0;
blockSize100k = 9;
testFailsExist = False;
unzFailsExist = False;
numFileNames= 0;
numFilesProcessed = 0;
workFactor = 30;
deleteOutputOnInterrupt = False;
exitValue = 0;
i = j = 0; /* avoid bogus warning from egcs-1.1.X */
/*-- Set up signal handlers for mem access errors --*/
signal (SIGSEGV, mySIGSEGVorSIGBUScatcher);
[Bug lto/94311] LTO produces line info entries with invalid line numbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94311 --- Comment #8 from Mark Wielaard --- Note that VEX/priv/guest_arm64_toIR.c is fairly big (1.2M): $ wc VEX/priv/guest_amd64_toIR.c 32655 127564 1189783 VEX/priv/guest_amd64_toIR.c (but still less than 2^15 lines)
[Bug lto/94311] LTO produces line info entries with invalid line numbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94311 --- Comment #7 from Mark Wielaard --- Note that the above is in ./install/lib/valgrind/memcheck-amd64-linux Which has .debug_line entries like: [0x00098404] Set is_stmt to 0 [0x00098405] Advance PC by constant 17 to 0x5809993c [0x00098406] Special opcode 103: advance Address by 7 to 0x58099943 and Line by 0 to 13372 [0x00098407] Set is_stmt to 1 [0x00098408] Advance Line by 23257547 to 23270919 [0x0009840d] Special opcode 145: advance Address by 10 to 0x5809994d and Line by 0 to 23270919 [0x0009840e] Advance Line by 58034 to 23328953 [0x00098412] Special opcode 117: advance Address by 8 to 0x58099955 and Line by 0 to 23328953 [0x00098413] Advance Line by 75462 to 23404415 [0x00098417] Special opcode 131: advance Address by 9 to 0x5809995e and Line by 0 to 23404415 [0x00098418] Advance Line by -23388426 to 15989 [0x0009841d] Special opcode 187: advance Address by 13 to 0x5809996b and Line by 0 to 15989 with readelf --debug-dump=decodedline we see: priv/guest_amd64_toIR.c: guest_amd64_toIR.c 1505 0x580998b8 x guest_amd64_toIR.c 23769 0x580998d8 x guest_amd64_toIR.c 10611 0x580998f1 x guest_amd64_toIR.c 10611 0x580998f8 guest_amd64_toIR.c 10610 0x580998f8 1 x guest_amd64_toIR.c 24067 0x58099900 x guest_amd64_toIR.c 24067 0x58099900 1 guest_amd64_toIR.c 13368 0x58099917 x guest_amd64_toIR.c 13368 0x5809991e guest_amd64_toIR.c 14968 0x5809991e 1 x guest_amd64_toIR.c 13368 0x58099926 x guest_amd64_toIR.c 13368 0x5809992b guest_amd64_toIR.c 13372 0x5809992b 1 x guest_amd64_toIR.c 13372 0x58099943 guest_amd64_toIR.c 23270919 0x5809994d x guest_amd64_toIR.c 23328953 0x58099955 x guest_amd64_toIR.c 23404415 0x5809995e x guest_amd64_toIR.c 15989 0x5809996b x guest_amd64_toIR.c 15989 0x58099970 guest_amd64_toIR.c 15055 0x58099970 1 x guest_amd64_toIR.c 1254 0x5809997d x guest_amd64_toIR.c 1253 0x58099980 x guest_amd64_toIR.c 226 0x58099982 x guest_amd64_toIR.c 226 0x58099987 guest_amd64_toIR.c 14316 0x58099987 1 x guest_amd64_toIR.c 226 0x5809998c x guest_amd64_toIR.c 226 0x5803 guest_amd64_toIR.c 14316 0x5803 1 x guest_amd64_toIR.c 14315 0x5806 x guest_amd64_toIR.c 14316 0x5809 x guest_amd64_toIR.c 226 0x580c x guest_amd64_toIR.c 226 0x580999a0 guest_amd64_toIR.c 14316 0x580999a0 1 x guest_amd64_toIR.c 14316 0x580999a2 guest_amd64_toIR.c 226 0x580999a2 1 x guest_amd64_toIR.c 226 0x580999a7 guest_amd64_toIR.c 226 0x580999b4 guest_amd64_toIR.c 226 0x580999c5 guest_amd64_toIR.c 226 0x580999ca guest_amd64_toIR.c 226 0x580999d7 guest_amd64_toIR.c 226 0x580999dc guest_amd64_toIR.c 5664 0x580999dc 1 x guest_amd64_toIR.c 226 0x580999e0 x guest_amd64_toIR.c 226 0x580999e4 guest_amd64_toIR.c 5664 0x580999e4 1 x
[Bug lto/94311] LTO produces line info entries with invalid line numbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94311
--- Comment #6 from Mark Wielaard ---
(In reply to Mark Wielaard from comment #5)
> I can no longer replicate the issue of the bad line numbers with gcc (GCC)
> 10.1.1 20200507 (Red Hat 10.1.1-1) on fedora 32. With either 3.15.0 or
> current valgrind git.
Note that current valgrind git hides these warnings:
commit 5920eb0c4302015f3648354e4f9c059f899194b7
Author: Philippe Waroquiers
Date: Tue Feb 18 21:35:44 2020 +0100
Improve line info tracing, in particular when using lto.
With gcc 9 and --enable-lto, we now have spurious warnings telling
that the line information in the debug info has huge line numbers,
greater than the (valgrind) maximum of 2^20.
These spurious warnings make that all tests are failing.
This change modifies the tracing/debugging of the line info to:
* disable by default the warning for line info greater than 2^20.
When using -d, such warnings are however still shown (once).
* allow to see all such warnings, when using at least -d -d -d -d
And I am able to replicate with valgrind git on Fedora 32 with gcc (GCC) 10.2.1
20200723 (Red Hat 10.2.1-1) gcc-10.2.1-1.fc32.x86_64
$ { ./autogen.sh; ./configure --prefix=`pwd`/install --enable-only64bit
--enable-lto; make -j8 install; } >& build.log
$ ./install/bin/valgrind -d date 2>&1 | grep info\ entry
==110351== warning: Can't handle line info entry with line number 23270919
greater than 1048575
==110351== warning: Can't handle inlined call info entry with line number
23270918 greater than 1048575
[Bug c/96407] LTO inlined functions don't inherit disabled warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96407 Mark Wielaard changed: What|Removed |Added CC||mark at gcc dot gnu.org --- Comment #1 from Mark Wielaard --- Same for using -Wstack-usage= on the command line. It is one of the workarounds needed for building elfutils with LTO enabled: https://sourceware.org/pipermail/elfutils-devel/2020q2/002733.html This version of elfutils handles debuginfo generated with GCC LTO better and it can finally be build with GCC LTO itself: export AR=gcc-ar RANLIB=gcc-ranlib NM=gcc-nm ./configure CFLAGS="-O2 -g -flto=auto -flto-partition=none \ -Wno-error=stack-usage=" \ CXXFLAGS="-O2 -g -flto=auto -flto-partition=none" Note the two workaround. -flto-partition=none is needed to preserve the symbol versioning. -Wno-error=stack-usage= is needed because LTO will combine objects build with and without a -Wstack-usage limit.
[Bug c++/96328] [11 Regression] Single keyword "friend" makes GCC ICE in cp_lexer_previous_token, at cp/parser.c:769 since r11-891-g1dc83b460653c29f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96328 --- Comment #6 from Mark Wielaard --- (In reply to Jakub Jelinek from comment #5) > Created attachment 48931 [details] > gcc11-pr96328-alt.patch > > If you want, we could call the safe_previous_token also in the other spot, > while we don't have a known testcase for those cases, it is still just a > hint and thus not really required if something goes wrong and everything > before it is purged. Yes. I think this alt.patch is perfect. Could you please submit it? Thanks.
[Bug c++/96328] [11 Regression] Single keyword "friend" makes GCC ICE in cp_lexer_previous_token, at cp/parser.c:769 since r11-891-g1dc83b460653c29f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96328 --- Comment #4 from Mark Wielaard --- (In reply to Jakub Jelinek from comment #3) > Created attachment 48930 [details] > gcc11-pr96328.patch > > I wrote this for it (the first hunk is similar). Yours is nicer because it fixes just the specific part that fails (and it includes an actual test case). I tried to fix any use of prev_token in cp_parser_error_1. But I cannot tell if the one under missing_token_desc != RT_NONE can ever trigger. It was just the most safe fix I could come up with.
[Bug c++/96328] [11 Regression] Single keyword "friend" makes GCC ICE in cp_lexer_previous_token, at cp/parser.c:769 since r11-891-g1dc83b460653c29f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96328
Mark Wielaard changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #2 from Mark Wielaard ---
Only tested on the failing testcase, but this seems to fix it:
$ echo "friend" | /opt/local/install/gcc/bin/g++ -c -xc++ -
:1:1: error: ‘friend’ used outside of class
:2: error: expected unqualified-id at end of input
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 0c77c20da862..9c4f6a50523c 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -781,9 +781,13 @@ static cp_token *
cp_lexer_safe_previous_token (cp_lexer *lexer)
{
if (lexer->buffer)
-if (lexer->next_token != lexer->buffer->address ())
- return cp_lexer_previous_token (lexer);
-
+{
+ cp_token_position tp = cp_lexer_previous_token_position (lexer);
+ while (tp->purged_p && tp != lexer->buffer->address ())
+ tp--;
+ if (tp != lexer->buffer->address ())
+ return tp;
+}
return NULL;
}
@@ -2932,15 +2936,15 @@ cp_parser_error_1 (cp_parser* parser, const char*
gmsgid,
gcc_rich_location richloc (input_location);
bool added_matching_location = false;
+ cp_token *prev_token = cp_lexer_safe_previous_token (parser->lexer);
- if (missing_token_desc != RT_NONE)
+ if (prev_token && missing_token_desc != RT_NONE)
{
/* Potentially supply a fix-it hint, suggesting to add the
missing token immediately after the *previous* token.
This may move the primary location within richloc. */
enum cpp_ttype ttype = get_required_cpp_ttype (missing_token_desc);
- location_t prev_token_loc
- = cp_lexer_previous_token (parser->lexer)->location;
+ location_t prev_token_loc = prev_token->location;
maybe_suggest_missing_token_insertion (, ttype, prev_token_loc);
/* If matching_location != UNKNOWN_LOCATION, highlight it.
@@ -2957,7 +2961,6 @@ cp_parser_error_1 (cp_parser* parser, const char* gmsgid,
standard string literal constants defined in header files. If
there is one, then add that as an hint to the error message. */
name_hint h;
- cp_token *prev_token = cp_lexer_safe_previous_token (parser->lexer);
if (prev_token && cp_parser_is_string_literal (prev_token)
&& token->type == CPP_NAME)
{
[Bug lto/70611] Compiling binutils with -flto -Wstack-usage fails.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70611 --- Comment #7 from Mark Wielaard --- (In reply to Mark Wielaard from comment #6) > Sorry, commented on the wrong bug, the above was meant for bug #93865 Groan, I seem very confused today. That comment was fine. It was me who got confused because I have "After changing a bug" set to "Show next bug in my list". I'll set my preferences to confuse myself less. Apologies.
[Bug lto/70611] Compiling binutils with -flto -Wstack-usage fails.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70611 --- Comment #6 from Mark Wielaard --- (In reply to Mark Wielaard from comment #5) > This is also one of the issues that prevent elfutils to build with LTO. > The workaround is to compile with -Wno-error=stack-usage= added to CFLAGS: > https://sourceware.org/pipermail/elfutils-devel/2020q2/002733.html Sorry, commented on the wrong bug, the above was meant for bug #93865
[Bug debug/93865] .debug_line with LTO refers to bogus file-names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93865 --- Comment #2 from Mark Wielaard --- This also impacts rpm (find-debuginfo.sh) when it tries to extract the source files from binaries compiled with LTO enabled: https://github.com/rpm-software-management/rpm/issues/1207
[Bug debug/47819] [meta-bug] LTO debug information issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47819 Mark Wielaard changed: What|Removed |Added Depends on||88389, 88878, 93117, 91794, ||93951, 94311 --- Comment #5 from Mark Wielaard --- (In reply to Mark Wielaard from comment #4) > The following bugs might be added to this meta-bug. But they seemed not very > urgent because they involve non-default -g/-f debug flags: It is probably good for tracking to just add them as dependencies of this meta-bug whether or not they are "urgent" or not. So I'll just add them all for now. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88389 [Bug 88389] -flto -g -gsplit-dwarf is broken https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88878 [Bug 88878] .debug_pubnames/types empty with -flto https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91794 [Bug 91794] exception and unwind state is not carried to LTO but controls EH vs debug frame https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93117 [Bug 93117] -g -flto -fdebug-types-section is broken for units with over 64k types https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93951 [Bug 93951] [8/9/10/11 Regression] ICE with '-flto -g -femit-struct-debug-baseonly' https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94311 [Bug 94311] LTO produces line info entries with invalid line numbers
[Bug debug/47819] [meta-bug] LTO debug information issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47819 --- Comment #4 from Mark Wielaard --- The following bugs might be added to this meta-bug. But they seemed not very urgent because they involve non-default -g/-f debug flags: - -flto -g -gsplit-dwarf is broken https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88389 - .debug_pubnames/types empty with -flto https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88878 - -g -flto -fdebug-types-section is broken for units with over 64k types https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93117 - exception and unwind state is not carried to LTO but controls EH vs debug frame https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91794 - ICE with '-flto -g -femit-struct-debug-baseonly' https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93951 There is also: - LTO produces line info entries with invalid line numbers https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94311 But that seems to have been reduced to a variant of: - debug_line with LTO refers to bogus file-names https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93865 (Which already blocks this bug)
[Bug lto/94311] LTO produces line info entries with invalid line numbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94311
Mark Wielaard changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #5 from Mark Wielaard ---
I can no longer replicate the issue of the bad line numbers with gcc (GCC)
10.1.1 20200507 (Red Hat 10.1.1-1) on fedora 32. With either 3.15.0 or current
valgrind git.
But when building with LTO it looks like the (relative) paths to the VEX
library linked into memcheck-amd64-linux doesn't come out correctly. Both
valgrind and gdb cannot find the actual files, even when in the build dir.
You can see the same issue with elfutils eu-readelf --debug-dump=decodedline
./install/lib/valgrind/memcheck-amd64-linux
Without lto you'll get full (absolute) path names:
CU [b] mc_leakcheck.c
line:col SBPE* disc isa op address (Statement Block Prologue Epilogue *End)
/tmp/valgrind-3.15.0/memcheck/mc_leakcheck.c (mtime: 0, length: 0)
253:1 S0 0 0 0x58001070
254:4 S0 0 0 0x58001070
255:4 S0 0 0 0x58001070
256:4 S0 0 0 0x58001070
256:11 0 0 0 0x58001070
256:23 0 0 0 0x58001073
256:70 0 0 0x58001076
257:70 0 0 0x5800107e
259:10 0 0 0x5800108c
While with lto some of the paths seem relative (but to what?):
CU [b]
line:col SBPE* disc isa op address (Statement Block Prologue Epilogue *End)
priv/guest_amd64_toIR.c (mtime: 0, length: 0)
2036:00 0 0 0x58001000
2446:00 0 0 0x58001007
/home/mark/valgrind/memcheck/m_mallocfree.c (mtime: 0, length: 0)
2643:00 0 0 0x5800100e
/home/mark/valgrind/memcheck/m_libcprint.c (mtime: 0, length: 0)
61:0 S0 0 0 0x5800100e
61:0 S0 0 0 0x5800100e
61:0 S0 0 0 0x5800100e
/home/mark/valgrind/memcheck/m_mallocfree.c (mtime: 0, length: 0)
2643:00 0 0 0x58001018
/home/mark/valgrind/memcheck/m_libcprint.c (mtime: 0, length: 0)
61:0 S0 0 0 0x58001018
61:0 S0 0 0 0x58001018
61:0 S0 0 0 0x58001018
61:0 S *0 0 0 0x58001021
priv/guest_amd64_toIR.c (mtime: 0, length: 0)
7007:0 S0 0 0 0x58001150
7011:0 S0 0 0 0x58001150
7012:0 S0 0 0 0x58001150
7013:0 S0 0 0 0x58001150
7014:00 0 0 0x5800115e
7010:00 0 0 0x5800116c
This looks similar to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93865
(".debug_line with LTO refers to bogus file-names")
[Bug debug/78871] Anonymous namespace and -flto -gsplit-dwarf: ICE in lhd_decl_printable_name, at langhooks.c:215
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78871 Mark Wielaard changed: What|Removed |Added CC||mark at gcc dot gnu.org --- Comment #4 from Mark Wielaard --- I think this is (now) a duplicate of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88389
[Bug driver/47785] GCC with -flto does not pass -Wa/-Xassembler options to the assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47785 Mark Wielaard changed: What|Removed |Added CC||mark at gcc dot gnu.org --- Comment #18 from Mark Wielaard --- Since this patch has been included in gcc10 (I verified it works now, but fails with gcc9) can this issue be closed? Or does it need backporting to earlier versions?
[Bug lto/86412] lto1: internal compiler error: in lto_symtab_prevailing_virtual_decl, at lto/lto-symtab.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86412 Mark Wielaard changed: What|Removed |Added CC||mark at gcc dot gnu.org --- Comment #8 from Mark Wielaard --- Both the minimal and original reproducer seem to build fine with gcc version 10.1.1 20200507 (Red Hat 10.1.1-1) (GCC)
[Bug debug/87726] -fdebug-prefix-map doesn't work with lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87726 Mark Wielaard changed: What|Removed |Added Ever confirmed|0 |1 CC||mark at gcc dot gnu.org Blocks||47819 Last reconfirmed||2020-07-16 Status|UNCONFIRMED |NEW --- Comment #1 from Mark Wielaard --- Replicated. With -flto added the result is a linker error: g++ -g -o app/app app/app.o -L./lib -lA /usr/bin/ld: /tmp/app.BSgkYr.ltrans0.ltrans.o: in function `main': //app.cpp:6: undefined reference to `Lib::func()' collect2: error: ld returned 1 exit status Removing -fdebug-prefix-map (but keeping -flto) things build fine. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47819 [Bug 47819] [meta-bug] LTO debug information issues
[Bug lto/58528] lto1: internal compiler error: in build_abbrev_table, at dwarf2out.c:7478
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58528 Mark Wielaard changed: What|Removed |Added CC||mark at gcc dot gnu.org --- Comment #10 from Mark Wielaard --- It isn't entirely clear to me how to replicate this. Is this still an issue with newer gcc?
[Bug debug/54734] Debug info for C++ and LTO misses types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54734 Mark Wielaard changed: What|Removed |Added CC||mark at gcc dot gnu.org --- Comment #1 from Mark Wielaard --- This seems fixed with recent GCC. At least with GNU C++14 10.1.1 20200507 (Red Hat 10.1.1-1) I now get: [6b]typedef abbrev: 2 name (strp) "sstring" decl_file(data1) t.cc (1) decl_line(data1) 2 decl_column (data1) 28 type (ref4) [77] [77]class_type abbrev: 3 name (strp) "basic_string" byte_size(data1) 1 decl_file(data1) t.cc (1) decl_line(data1) 5 decl_column (data1) 7 sibling (ref4) [99] [84] typedef abbrev: 4 name (strp) "type" decl_file(data1) t.cc (1) decl_line(data1) 8 decl_column (data1) 13 type (ref4) [99] accessibility(data1) public (1) [91] template_type_parameter abbrev: 5 name (string) "T" type (ref4) [99] [99]base_typeabbrev: 6 byte_size(data1) 1 encoding (data1) signed_char (6) name (strp) "char"
[Bug lto/70611] Compiling binutils with -flto -Wstack-usage fails.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70611 Mark Wielaard changed: What|Removed |Added CC||mark at gcc dot gnu.org --- Comment #5 from Mark Wielaard --- This is also one of the issues that prevent elfutils to build with LTO. The workaround is to compile with -Wno-error=stack-usage= added to CFLAGS: https://sourceware.org/pipermail/elfutils-devel/2020q2/002733.html
[Bug target/92658] x86 lacks vector extend / truncate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92658
Mark Wielaard changed:
What|Removed |Added
CC||mark at gcc dot gnu.org
--- Comment #19 from Mark Wielaard ---
(In reply to CVS Commits from comment #18)
> gcc/testsuite/ChangeLog:
> * gcc.target/i386/pr92658-avx512f.c: New test.
> * gcc.target/i386/pr92658-avx512vl.c: Ditto.
> * gcc.target/i386/pr92658-avx512bw-trunc.c: Ditto.
Note that the second one as committed has an extra closing brace which causes
an error:
ERROR: gcc.target/i386/pr92658-avx512vl.c: unknown dg option: \} for "}"
diff --git a/gcc/testsuite/gcc.target/i386/pr92658-avx512vl.c
b/gcc/testsuite/gcc.target/i386/pr92658-avx512vl.c
index 50b32f968ac3..dc50084119b5 100644
--- a/gcc/testsuite/gcc.target/i386/pr92658-avx512vl.c
+++ b/gcc/testsuite/gcc.target/i386/pr92658-avx512vl.c
@@ -121,7 +121,7 @@ truncdb_128 (v16qi * dst, v4si * __restrict src)
dst[0] = *(v16qi *) tem;
}
-/* { dg-final { scan-assembler-times "vpmovqd" 2 } } } */
+/* { dg-final { scan-assembler-times "vpmovqd" 2 } } */
/* { dg-final { scan-assembler-times "vpmovqw" 2 { xfail *-*-* } } } */
/* { dg-final { scan-assembler-times "vpmovqb" 2 { xfail *-*-* } } } */
/* { dg-final { scan-assembler-times "vpmovdw" 1 } } */
[Bug analyzer/95188] New: analyzer-unsafe-call-within-signal-handler shows wrong statement for signal registration event
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95188 Bug ID: 95188 Summary: analyzer-unsafe-call-within-signal-handler shows wrong statement for signal registration event Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: mark at gcc dot gnu.org Target Milestone: --- Reproducer: wget https://sourceware.org/ftp/bzip2/bzip2-1.0.8.tar.gz tar zxf bzip2-1.0.8.tar.gz cd bzip2-1.0.8/ gcc -g -O2 -fanalyzer -c bzip2.c In function ‘showFileNames.part.0’: bzip2.c:677:4: warning: call to ‘fprintf’ from within signal handler [CWE-479] [-Wanalyzer-unsafe-call-within-signal-handler] 677 |fprintf ( |^ 678 | stderr, | ~~~ 679 | "\tInput file = %s, output file = %s\n", | 680 | inName, outName | ~~~ 681 |); |~ ‘main’: events 1-2 | | 1776 | IntNative main ( IntNative argc, Char *argv[] ) | | ^~~~ | | | | | (1) entry to ‘main’ |.. | 1792 |smallMode = False; | |~ | || | |(2) registering ‘mySIGSEGVorSIGBUScatcher’ as signal handler | event 3 | |cc1: | (3): later on, when the signal is delivered to the process | +--> ‘mySIGSEGVorSIGBUScatcher’: events 4-5 | | 676 |if (noisy) | | ~ | | | | | (5) following ‘true’ branch... |.. | 816 | void mySIGSEGVorSIGBUScatcher ( IntNative n ) | | ^~~~ | | | | | (4) entry to ‘mySIGSEGVorSIGBUScatcher’ | ‘mySIGSEGVorSIGBUScatcher’: event 6 | |cc1: | (6): ...to here | ‘mySIGSEGVorSIGBUScatcher’: event 7 | |cc1: | (7): calling ‘showFileNames.part.0’ from ‘mySIGSEGVorSIGBUScatcher’ | +--> ‘showFileNames.part.0’: events 8-9 | | 674 | void showFileNames ( void ) | | ^ | | | | | (8) entry to ‘showFileNames.part.0’ |.. | 677 |fprintf ( | |~ | || | |(9) call to ‘fprintf’ from within signal handler | 678 | stderr, | | ~~~ | 679 | "\tInput file = %s, output file = %s\n", | | | 680 | inName, outName | | ~~~ | 681 |); | |~ | Note that the signal handler registration points to the wrong instruction: | 1792 |smallMode = False; | |~ | || | |(2) registering ‘mySIGSEGVorSIGBUScatcher’ as signal handler A workaround is to add -fanalyzer-fine-grained, then it does show to correct signal registration event: | 1808 |signal (SIGSEGV, mySIGSEGVorSIGBUScatcher); | |~~ | || | |(2) registering ‘mySIGSEGVorSIGBUScatcher’ as signal handler
[Bug analyzer/94976] New: Oddities with -fanalyzer and -flto (SSA names leaking through)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94976
Bug ID: 94976
Summary: Oddities with -fanalyzer and -flto (SSA names leaking
through)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: mark at gcc dot gnu.org
Target Milestone: ---
$ gcc --version
gcc (GCC) 10.0.1 20200430 (Red Hat 10.0.1-0.13)
This is the build of elfutils libelf with both -flto and -fanalyzer.
The report is correct. __elf64_getshdr_rdlock () can return NULL and we are
directly dereferencing the result without a NULL check.
The report could be a bit better though:
In function ‘elf_strptr’:
elf_strptr.c:148:11: warning: dereference of NULL ‘_67’ [CWE-690]
[-Wanalyzer-null-dereference]
148 | if (unlikely (shdr->sh_type != SHT_STRTAB))
| ^
‘elf_strptr’: events 1-14
|
| 73 | elf_strptr (Elf *elf, size_t idx, size_t offset)
| | ^
| | |
| | (1) entry to ‘elf_strptr’
| 74 | {
| 75 | if (elf == NULL)
| | ~
| | |
| | (2) following ‘false’ branch (when ‘elf_77(D)’ is
non-NULL)...
|..
| 78 | if (elf->kind != ELF_K_ELF)
| | ~ ~
| | | |
| | | (4) following ‘false’ branch...
| | (3) ...to here
|..
| 84 | rwlock_rdlock (elf->lock);
| | ~
| | |
| | (5) ...to here
|..
| 96 | if (idx < runp->max)
| | ~
| | |
| | (6) following ‘true’ branch...
| 97 | {
| 98 |if (idx < runp->cnt)
| |~ ~
| || |
| || (8) following ‘true’ branch...
| |(7) ...to here
| 99 | strscn = >data[idx];
| | ~
| | |
| | (9) ...to here
|..
| 119 | if (elf->class == ELFCLASS32)
| | ~
| | |
| | (10) following ‘false’ branch...
|..
| 147 | Elf64_Shdr *shdr = strscn->shdr.e64 ?:
__elf64_getshdr_rdlock (strscn);
| | ~~ ~
| | || |
| | || (13) ...to here
| | || (14) calling
‘__elf64_getshdr_rdlock’ from ‘elf_strptr’
| | (11) ...to here (12) following ‘false’
branch...
|
+--> ‘__elf64_getshdr_rdlock’: events 15-16
|
|elf32_getshdr.c:250:1:
| 250 | __elfw2(LIBELFBITS,getshdr_rdlock) (Elf_Scn *scn)
| | ^
| | |
| | (15) entry to ‘__elf64_getshdr_rdlock’
|..
| 254 | if (!scn_valid (scn))
| |~
| ||
| |(16) calling ‘scn_valid’ from
‘__elf64_getshdr_rdlock’
|
+--> ‘scn_valid’: events 17-22
|
| 228 | scn_valid (Elf_Scn *scn)
| | ^
| | |
| | (17) entry to ‘scn_valid’
| 229 | {
| 230 | if (scn == NULL)
| | ~
| | |
| | (18) following ‘false’ branch (when ‘scn_12(D)’
is non-NULL)...
|..
| 233 | if (unlikely (scn->elf->state.elf.ehdr == NULL))
| | ~ ~
| | | |
| | | (20) following ‘true’ branch...
| | (19) ...to here
| 234 | {
| 235 | __libelf_seterrno (ELF_E_WRONG_ORDER_EHDR);
| | ~
| | |
| | (21) ...to here
| | (22) calling ‘__libelf_seterrno’ from
‘scn_valid’
|
+--> ‘__libelf_seterrno’: events 23-25
|
|elf_error.c:334:1:
| 334 | __libelf_seterrno (int value)
| | ^
| | |
| | (23) entry to ‘__libelf_seterrno’
| 335 | {
| 336 | global_error = value >= 0 && value <
nmsgidx ? value : ELF_E_UNKNOWN_ERROR;
| |~
~
| ||
|
[Bug lto/48200] Implement function attribute for symbol versioning (.symver)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200 --- Comment #43 from Mark Wielaard --- It looks there is now some support for a symver function attribute. But it only accepts the single and double @ forms. This makes things a little awkward when using a symbol foo itself for foo@@DEFAULT_VERSION. It causes the (non-versioned) foo symbol to still appear in the object, which doesn't work very nicely when combined with linker version scripts. For elfutils I had to workaround that by adding foo also to a non-exported version section, so that the assembler and linker didn't both try to create a default version for foo: https://sourceware.org/pipermail/elfutils-devel/2020q2/002609.html It works, but feels like a hack. Please also support the @@@ symver variant.
[Bug lto/94311] LTO produces line info entries with invalid line numbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94311 --- Comment #3 from Mark Wielaard --- (In reply to Richard Biener from comment #1) > Err, but isn't this interpreting the dwarf from 'date'? So doesn't this > mean that valgrind is "miscompiled" with --enable-lto rather than wrong > debug? The error message isn't very clear, but valgrind also reads its own code/binary (which is inserted into the process), which is build with LTO. It is that library that has the wrong line numbers. Which can also be seen in gdb: ./install/bin/valgrind -q date ==48528== warning: Can't handle line info entry with line number 177277754 greater than 1048575 ==48528== (Nb: this message is only shown once) ==48528== warning: Can't handle inlined call info entry with line number 177277750 greater than 1048575 ==48528== (Nb: this message is only shown once) Double check that valgrind debug info reader is correct: gdb ./.in_place/memcheck-amd64-linux Reading symbols from ./.in_place/memcheck-amd64-linux... (gdb) info line guest_amd64_toIR.c:177277754 Line number 177277754 is out of range for "priv/guest_amd64_toIR.c". Line 177277754 of "priv/guest_amd64_toIR.c" starts at address 0x58069001 and ends at 0x58069005 . (gdb) You can also try: (gdb) disass /s dis_ESC_0F__SSE4 and you zillions of useless lines. If needed, you can ask valgrind to show more info about what it is doing/reading by doing e.g. ./install/bin/valgrind -v -v -v -v -d -d -d -d --debug-dump=line date |& tee d.out
[Bug libbacktrace/93608] [libbacktrace] Add support for .gnu_debugdata section (aka MiniDebugInfo)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93608 --- Comment #3 from Mark Wielaard --- (In reply to Ian Lance Taylor from comment #2) > It looks like this would mean that libbacktrace needs an lzma decompressor. > This is probably doable but is probably non-trivial. At least it doesn't > look quite as bad as the zlib decompressor that we already have. Yes, it is basically an ELF image, containing just a symbol table, compressed with lzma inside an ELF section. The linux kernel contains a small unlzma implementation based on the busybox code that we might be able to adapt (it is LGPLv2+).
[Bug libbacktrace/93608] [libbacktrace] Add support for .gnu_debugdata section (aka MiniDebugInfo)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93608 Mark Wielaard changed: What|Removed |Added CC||mark at gcc dot gnu.org --- Comment #1 from Mark Wielaard --- The gdb description: https://sourceware.org/gdb/current/onlinedocs/gdb/MiniDebugInfo.html#MiniDebugInfo Some more background in this talk: https://fosdem.org/2020/schedule/event/debugging_mini/
[Bug demangler/70517] c++filt crashes when demangling a symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70517 --- Comment #6 from Mark Wielaard --- (In reply to Christian Biesinger from comment #5) > Using binutils from a month ago or so, this does not crash but also does not > demangle... Could you be slightly more specific? Which symbol produced by which compiler doesn't (correctly) demangle? And, if known, is it a valid mangled symbol?
[Bug debug/90981] [9/10 Regression] ICE in dwarf2out_finish, at dwarf2out.c:31644
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90981 --- Comment #6 from Mark Wielaard --- Author: mark Date: Wed Jul 3 13:08:01 2019 New Revision: 273008 URL: https://gcc.gnu.org/viewcvs?rev=273008=gcc=rev Log: PR debug/90981 Empty .debug_addr crashes -gdwarf-5 -gsplit-dwarf Even if there was no, or an empty address list we would try to generate a header for the .debug_addr section with -gdwarf-5 and -gsplit-dwarf. The skeleton DIE would also get a (dangling) DW_AT_addr_base in that case. PR debug/90981 * dwarf2out.c (add_top_level_skeleton_die_attrs): Only add DW_AT_addr_base if there is actually a .debug_addr section with addresses. (output_addr_table): Add DWARF5 table header generation here after checking there are actually any addresses from... (dwarf2out_finish): ...here. * testsuite/g++.dg/pr90981.C: New test. Added: trunk/gcc/testsuite/g++.dg/pr90981.C Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c
[Bug debug/90981] [9/10 Regression] ICE in dwarf2out_finish, at dwarf2out.c:31644
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90981 Mark Wielaard changed: What|Removed |Added Component|c++ |debug --- Comment #5 from Mark Wielaard --- https://gcc.gnu.org/ml/gcc-patches/2019-06/msg01682.html
[Bug c++/90981] [9/10 Regression] ICE in dwarf2out_finish, at dwarf2out.c:31644
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90981 Mark Wielaard changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mark at gcc dot gnu.org --- Comment #4 from Mark Wielaard --- Created attachment 46518 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46518=edit Don't emit debug_addr attribute or addr index if there is no addr table. Testing the following patch that makes sure we don't try to emit a DW_AT_addr_base and .debug_addr debug table if there is no (or an empty) address table.
[Bug c++/90981] [9/10 Regression] ICE in dwarf2out_finish, at dwarf2out.c:31644
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90981 --- Comment #3 from Mark Wielaard --- (In reply to Martin Liška from comment #2) > Btw. started with r259743. Thanks. So that is mine: commit ac7a2c61cf2ae7fcc948724ae179ac812c12186a Author: mark Date: Sat Apr 28 19:54:08 2018 + DWARF: Add .debug_addr table header for dwarf_version >= 5. GNU DebugFission didn't add table headers for the .debug_addr tables, but DWARF5 does. The table header makes it possible for a DWARF consumer to parse the address tables without having to index all .debug_info CUs first. We can keep using the .debug_addr section label as is, because the DW_AT_[GNU_]addr_base attribute points at the actual address index, which starts right after the table header. So the label is generated at the correct location whether the header is added first or not. Add DW_AT_addr_base instead of DW_AT_GNU_addr_base to the skeleton CU DIE for DWARF5. gcc/ChangeLog * dwarf2out.c (dwarf2out_finish): Add .debug_addr table header for dwarf_version >= 5. (dwarf_AT): Handle DW_AT_addr_base. (add_top_level_skeleton_die_attrs): Use dwarf_AT for DW_AT_addr_base. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@259743 138bc75d-0d04-0410-961f-82ee72b054a4
[Bug c/88088] -Wtrampolines should be enabled by -Wall (or -Wextra)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88088 --- Comment #22 from Mark Wielaard --- (In reply to Eric Gallager from comment #21) > (In reply to Mark Wielaard from comment #20) > > https://gcc.gnu.org/ml/gcc-patches/2018-11/msg02055.html > > Did this make it in? If not, have you pinged it lately? No, there was some review, I think we are generally good, but I am waiting for stage1 to open.
[Bug tree-optimization/88835] overly aggressive -Werror=format-overflow for printf since r265648
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88835 --- Comment #17 from Mark Wielaard --- (In reply to Martin Sebor from comment #16) > The warning has been relaxed for GCC 9 in r269125. Thanks, I can confirm elfutils builds fine without warnings with GCC 9 now.
[Bug tree-optimization/88835] overly aggressive -Werror=format-overflow for printf since r265648
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88835
--- Comment #14 from Mark Wielaard ---
(In reply to Mark Wielaard from comment #12)
> (In reply to Martin Sebor from comment #11)
> > Ah, but you mentioned elfutilts, not binutils. I've now downloaded and
> > built elfutils-0.175. It took a bit more effort because --disable-werror
> > doesn't work there but once I got past that I just got the three
> > -Wformat-truncation instances below:
> >
> > DiagnosticCount UniqueFiles
> > -Wformat-truncation= 332
> >
> > -Wformat-truncation Instances:
> > /src/elfutils-0.175/src/ar.c:1468
> > /src/elfutils-0.175/src/ar.c:859
> > /src/elfutils-0.175/src/arlib.c:63
>
> I am not seeing these, but they might have been fixed in git. We like to
> keep the code warning free since we always build with -Werror.
Aha, I now see, you are using -Wformat-truncation=2. Then yes, these snprintfs
formats could produce more characters than would fit in the given buffer/size.
But that is kind of the point of the code, that we don't overflow the given
buffer. The snprintf is supposed to truncate to what would fit in these cases.
I can see if I could come up with something smarter to detect this without
using snprintf, but that seems to defeat the point of using snprintf. So for
now we just don't use -Wformat-truncation=2. (Background, ar files are weird,
they use fixed size character fields for numbers as decimal strings without a
zero terminator, but right padded with spaces.)
The specific warnings which we enable can be found in config/eu.am and depend
on some configure checks to make sure gcc supports them:
AM_CFLAGS = -std=gnu99 -Wall -Wshadow -Wformat=2 \
-Wold-style-definition -Wstrict-prototypes -Wtrampolines \
$(LOGICAL_OP_WARNING) $(DUPLICATED_COND_WARNING) \
$(NULL_DEREFERENCE_WARNING) $(IMPLICIT_FALLTHROUGH_WARNING) \
$(if $($(*F)_no_Werror),,-Werror) \
$(if $($(*F)_no_Wunused),,-Wunused -Wextra) \
$(if $($(*F)_no_Wstack_usage),,$(STACK_USAGE_WARNING)) \
$(if $($(*F)_no_Wpacked_not_aligned),-Wno-packed-not-aligned,) \
$($(*F)_CFLAGS)
With the following (if supported):
STACK_USAGE_WARNING=-Wstack-usage=262144
LOGICAL_OP_WARNING=-Wlogical-op
DUPLICATED_COND_WARNING=-Wduplicated-cond
NULL_DEREFERENCE_WARNING=-Wnull-dereference
IMPLICIT_FALLTHROUGH_WARNING=-Wimplicit-fallthrough=5
As you can see individual files can turn off some of these if necessary in the
Makefile by adding file_no_Wxxx. So the easiest way to see which warnings are
used it by running make V=1 which for this specific case gives (note the -m32
since I am running this on x86_64):
gcc -D_GNU_SOURCE -DHAVE_CONFIG_H -DLOCALEDIR='"/usr/local/share/locale"'
-DDEBUGPRED=0 -DSRCDIR=\"/home/mark/src/elfutils/src\"
-DOBJDIR=\"/opt/local/build/elfutils-obj/src\" -I.
-I/home/mark/src/elfutils/src -I.. -I. -I/home/mark/src/elfutils/src
-I/home/mark/src/elfutils/lib -I.. -I/home/mark/src/elfutils/src/../libelf
-I/home/mark/src/elfutils/src/../libebl -I/home/mark/src/elfutils/src/../libdw
-I/home/mark/src/elfutils/src/../libdwelf
-I/home/mark/src/elfutils/src/../libdwfl
-I/home/mark/src/elfutils/src/../libasm -std=gnu99 -Wall -Wshadow -Wformat=2
-Wold-style-definition -Wstrict-prototypes -Wtrampolines -Wlogical-op
-Wduplicated-cond -Wnull-dereference -Wimplicit-fallthrough=5 -Werror -Wunused
-Wextra-D_FORTIFY_SOURCE=2 -m32 -g -O2 -DBAD_FTS=1 -MT readelf.o -MD -MP
-MF .deps/readelf.Tpo -c -o readelf.o /home/mark/src/elfutils/src/readelf.c
/home/mark/src/elfutils/src/readelf.c: In function ‘print_debug_str_section’:
/home/mark/src/elfutils/src/readelf.c:10167:15: error: ‘%*llx’ directive output
between 4 and 2147483647 bytes may cause result to exceed ‘INT_MAX’
[-Werror=format-overflow=]
10167 | printf (" [%*" PRIx64 "] \"%s\"\n", digits, (uint64_t) offset,
str);
| ^~
/home/mark/src/elfutils/src/readelf.c:10167:18: note: format string is defined
here
10167 | printf (" [%*" PRIx64 "] \"%s\"\n", digits, (uint64_t) offset,
str);
/home/mark/src/elfutils/src/readelf.c:10167:15: note: directive argument in the
range [0, 18446744073709551614]
10167 | printf (" [%*" PRIx64 "] \"%s\"\n", digits, (uint64_t) offset,
str);
| ^~
cc1: all warnings being treated as errors
[Bug tree-optimization/88835] overly aggressive -Werror=format-overflow for printf since r265648
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88835 --- Comment #12 from Mark Wielaard --- (In reply to Martin Sebor from comment #11) > Ah, but you mentioned elfutilts, not binutils. I've now downloaded and > built elfutils-0.175. It took a bit more effort because --disable-werror > doesn't work there but once I got past that I just got the three > -Wformat-truncation instances below: > > DiagnosticCount UniqueFiles > -Wformat-truncation= 332 > > -Wformat-truncation Instances: > /src/elfutils-0.175/src/ar.c:1468 > /src/elfutils-0.175/src/ar.c:859 > /src/elfutils-0.175/src/arlib.c:63 I am not seeing these, but they might have been fixed in git. We like to keep the code warning free since we always build with -Werror. > I'm probably not using the same sources as you, but shouldn't I be seeing at > least some of the warnings? (I couldn't find an easy way build the top of > trunk -- there's no configure script.) I am using git master. git://sourceware.org/git/elfutils.git See the README for build instructions: To build a git checkout do: autoreconf -i -f && \ ./configure --enable-maintainer-mode && \ make && make check Note that the warning/error only occurs on 32bit systems, like these fedora koji arm32 and i686 builds: https://koji.fedoraproject.org/koji/taskinfo?taskID=32816136 To get the same on a 64bit system build with CFLAGS="-g -O2 -m32"
[Bug tree-optimization/88835] overly aggressive -Werror=format-overflow for printf since r265648
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88835
--- Comment #9 from Mark Wielaard ---
(In reply to Martin Sebor from comment #8)
> The patch I posted for the related pr88993 also relaxes this warning for
> printf and fprintf: https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00224.html
>
> Like in the case of pr88993, the warning is by design and (in my view) makes
> sense for sprintf but it's not very useful for the other functions where
> very little code worries about exceeding these limits (or even cares about
> the functions failing as they can for many other reasons).
I tried that patch, but it does not fix this issue. This case now triggers the
following warning, which isn't guarded by is_string_func:
/* The directive output or either causes or may cause the total
length of output to exceed INT_MAX bytes. */
if (likelyximax && fmtres.range.min == fmtres.range.max)
warned = fmtwarn (dirloc, argloc, NULL, info.warnopt (),
"%<%.*s%> directive output of %wu bytes causes "
"result to exceed %", dirlen,
target_to_host (hostdir, sizeof hostdir, dir.beg),
fmtres.range.min);
So with that patch we get:
/home/mark/src/elfutils/src/readelf.c: In function ‘print_debug_str_section’:
/home/mark/src/elfutils/src/readelf.c:10167:15: error: ‘] "’ directive output
of 4 bytes causes result to exceed ‘INT_MAX’ [-Werror=format-overflow=]
10167 | printf (" [%*" PRIx64 "] \"%s\"\n", digits, (uint64_t) offset,
str);
| ^~
/home/mark/src/elfutils/src/readelf.c:10167:30: note: format string is defined
here
10167 | printf (" [%*" PRIx64 "] \"%s\"\n", digits, (uint64_t) offset,
str);
| ^
cc1: all warnings being treated as errors
Which is actually more mysterious than the previous warning (without the patch
as shown in description).
