[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/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 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 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 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 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 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 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 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 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&action=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 #10 from Mark Wielaard --- Created attachment 49293 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49293&action=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 #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 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 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 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 #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/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/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/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 #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/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/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/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/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/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 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 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 #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 #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 #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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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/116146] Split insn-recog.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116146 --- Comment #4 from Mark Wielaard --- (In reply to Robin Dapp from comment #3) > On riscv insn-output is the largest file right now as well. Note that size matters, but the largest file does not always take the longest to compile. On a risc-v setup insn-recog.cc and the largest insn-emit-nn.cc file take hours more to build than any of the other larger files.
[Bug tree-optimization/116166] New: risc-v (last) insn-emit-nn.c build takes hours
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116166 Bug ID: 116166 Summary: risc-v (last) insn-emit-nn.c build takes hours Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: mark at gcc dot gnu.org Target Milestone: --- Created attachment 58789 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58789&action=edit preprocessed insn-emit-96.cc Compiling on risc-v the (last) insn-emit-nn.s takes hours. Even using --with-insnemit-partitions=96 insn-emit-96.cc is still 2.5MB. preprocessed source attached. git gcc-15-2456-g69a9ee05c68 /home/builder/worker/gcc-full-fedora-riscv/gcc-build/./prev-gcc/cc1plus -quiet -march=rv64imafdc_zicsr_zifencei_zaamo_zalrsc -mabi=lp64d -misa-spec=20191213 -mtls-dialect=trad -march=rv64imafdc_zicsr_zifencei_zca_zcd -g -gtoggle -O2 -Wwrite-strings /tmp/insn-emit-96.i -fno-checking -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -fno-PIE -o /tmp/insn-emit-96.s perf -g profile looks like: + 98.46% 0.00% cc1plus cc1plus [.] jump_threader::thread_around_empty_blocks + 98.42% 0.00% cc1plus cc1plus [.] jump_threader::simplify_control_stmt_condition + 98.41% 0.00% cc1plus cc1plus [.] jump_threader::simplify_control_stmt_condition_1 + 98.33% 0.00% cc1plus cc1plus [.] dom_jt_simplifier::simplify + 98.26% 0.00% cc1plus cc1plus [.] hybrid_jt_simplifier::simplify + 97.84% 0.00% cc1plus cc1plus [.] path_range_query::reset_path + 96.53% 0.07% cc1plus cc1plus [.] path_range_query::compute_ranges + 95.45% 0.44% cc1plus cc1plus [.] path_range_query::compute_ranges_in_block + 46.65% 0.19% cc1plus cc1plus [.] gori_compute::edge_range_p + 40.20% 0.11% cc1plus cc1plus [.] gori_compute::compute_operand_range + 38.54% 0.33% cc1plus cc1plus [.] gori_compute::compute_operand1_range + 25.39% 0.72% cc1plus cc1plus [.] irange::intersect + 20.40% 0.16% cc1plus cc1plus [.] path_range_query::compute_outgoing_relations + 14.79% 8.26% cc1plus cc1plus [.] generic_wide_int::~generic_wide_int + 14.39% 0.27% cc1plus cc1plus [.] fur_source::register_outgoing_edges + 14.21% 0.23% cc1plus cc1plus [.] gcond_edge_range + 13.01% 7.29% cc1plus cc1plus [.] generic_wide_int::generic_wide_int + 12.35% 1.15% cc1plus cc1plus [.] int_range<3u, true>::~int_range + 11.95% 0.26% cc1plus cc1plus [.] value_range::~value_range + 10.89% 0.89% cc1plus cc1plus [.] irange::maybe_resize + 10.22% 0.18% cc1plus cc1plus [.] path_range_query::get_cache + 10.19% 0.45% cc1plus cc1plus [.] irange::set Will run overnight with -ftime-report to get better stats.
[Bug tree-optimization/116166] risc-v (last) insn-emit-nn.c build takes hours
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116166 --- Comment #2 from Mark Wielaard --- Time variable usr sys wall GGC phase setup: 0.10 ( 0%) 0.00 ( 0%) 0.11 ( 0%) 2844k ( 0%) phase parsing : 37.04 ( 0%) 12.65 ( 32%) 49.85 ( 0%) 306M ( 46%) phase lang. deferred : 0.44 ( 0%) 0.08 ( 0%) 0.52 ( 0%) 2970k ( 0%) phase opt and generate :21747.57 (100%) 27.03 ( 68%)21848.93 (100%) 348M ( 53%) phase last asm : 0.07 ( 0%) 0.01 ( 0%) 0.08 ( 0%) 69k ( 0%) |name lookup : 5.85 ( 0%) 1.62 ( 4%) 7.20 ( 0%) 4335k ( 1%) |overload resolution : 5.41 ( 0%) 1.51 ( 4%) 6.97 ( 0%) 30M ( 5%) garbage collection : 1.50 ( 0%) 2.15 ( 5%) 3.67 ( 0%) 0 ( 0%) dump files : 0.86 ( 0%) 0.07 ( 0%) 1.00 ( 0%) 0 ( 0%) callgraph construction : 1.28 ( 0%) 0.09 ( 0%) 1.27 ( 0%) 4404k ( 1%) callgraph optimization : 1.03 ( 0%) 0.11 ( 0%) 1.10 ( 0%) 108k ( 0%) callgraph functions expansion :21669.92 ( 99%) 25.01 ( 63%)21768.97 ( 99%) 266M ( 40%) callgraph ipa passes : 72.78 ( 0%) 1.83 ( 5%) 74.87 ( 0%) 29M ( 4%) ipa function summary : 1.87 ( 0%) 0.09 ( 0%) 1.96 ( 0%) 1513k ( 0%) ipa dead code removal : 0.04 ( 0%) 0.00 ( 0%) 0.04 ( 0%) 0 ( 0%) ipa cp : 0.55 ( 0%) 0.00 ( 0%) 0.61 ( 0%) 695k ( 0%) ipa inlining heuristics: 0.19 ( 0%) 0.14 ( 0%) 0.40 ( 0%) 345k ( 0%) ipa function splitting : 0.62 ( 0%) 0.01 ( 0%) 0.66 ( 0%) 52k ( 0%) ipa various optimizations : 0.01 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 0 ( 0%) ipa reference : 0.01 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 0 ( 0%) ipa pure const : 0.61 ( 0%) 0.02 ( 0%) 0.46 ( 0%) 0 ( 0%) ipa icf: 0.47 ( 0%) 0.00 ( 0%) 0.47 ( 0%) 0 ( 0%) ipa SRA: 2.09 ( 0%) 0.02 ( 0%) 2.11 ( 0%) 137k ( 0%) ipa free lang data : 0.01 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 0 ( 0%) ipa free inline summary: 0.01 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 0 ( 0%) ipa modref : 0.67 ( 0%) 0.00 ( 0%) 0.67 ( 0%) 541k ( 0%) cfg construction : 0.84 ( 0%) 0.10 ( 0%) 0.88 ( 0%) 10M ( 2%) cfg cleanup: 6.88 ( 0%) 0.07 ( 0%) 6.99 ( 0%) 2264k ( 0%) trivially dead code: 0.80 ( 0%) 0.02 ( 0%) 0.78 ( 0%) 0 ( 0%) df scan insns : 1.27 ( 0%) 0.05 ( 0%) 1.32 ( 0%) 88k ( 0%) df reaching defs : 1.58 ( 0%) 0.07 ( 0%) 1.52 ( 0%) 0 ( 0%) df live regs : 6.56 ( 0%) 0.17 ( 0%) 7.13 ( 0%) 0 ( 0%) df live&initialized regs : 4.12 ( 0%) 0.05 ( 0%) 4.18 ( 0%) 0 ( 0%) df must-initialized regs : 0.19 ( 0%) 0.01 ( 0%) 0.35 ( 0%) 0 ( 0%) df use-def / def-use chains: 0.67 ( 0%) 0.01 ( 0%) 0.65 ( 0%) 0 ( 0%) df reg dead/unused notes : 2.92 ( 0%) 0.08 ( 0%) 3.31 ( 0%) 2712k ( 0%) register information : 4.01 ( 0%) 0.19 ( 0%) 4.33 ( 0%) 0 ( 0%) alias analysis : 3.40 ( 0%) 0.12 ( 0%) 3.33 ( 0%) 10M ( 2%) alias stmt walking : 0.47 ( 0%) 0.05 ( 0%) 0.55 ( 0%) 0 ( 0%) register scan : 0.21 ( 0%) 0.02 ( 0%) 0.23 ( 0%) 59k ( 0%) rebuild jump labels: 0.41 ( 0%) 0.00 ( 0%) 0.44 ( 0%) 0 ( 0%) preprocessing : 2.51 ( 0%) 2.79 ( 7%) 5.46 ( 0%) 26M ( 4%) parser (global): 12.93 ( 0%) 4.93 ( 12%) 17.89 ( 0%) 175M ( 27%) parser struct body : 1.31 ( 0%) 0.24 ( 1%) 1.52 ( 0%) 6856k ( 1%) parser enumerator list : 0.76 ( 0%) 0.25 ( 1%) 0.90 ( 0%) 8060k ( 1%) parser function body : 13.71 ( 0%) 3.11 ( 8%) 16.57 ( 0%) 61M ( 9%) parser inl. func. body : 2.42 ( 0%) 0.62 ( 2%) 3.00 ( 0%) 12M ( 2%) parser inl. meth. body : 0.54 ( 0%) 0.06 ( 0%) 0.60 ( 0%) 3821k ( 1%) template instantiation : 2.45 ( 0%) 0.61 ( 2%) 3.29 ( 0%) 16M ( 2%) constant expression evaluation : 0.77 ( 0%) 0.10 ( 0%) 1.03 ( 0%) 192k ( 0%) early inlining heuristics : 0.16 ( 0%) 0.01 ( 0%) 0.27 ( 0%) 950k ( 0%) inline paramet
[Bug tree-optimization/116166] risc-v (last) insn-emit-nn.c build takes hours
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116166 --- Comment #4 from Mark Wielaard --- (In reply to Richard Biener from comment #3) > There's another PR where DOM shows up via ranger also at -O1 - does -O1 help > here? No. With -O2 it took 6 hours for that file to compile. With -O1 it is still running after 12 hours...
[Bug tree-optimization/116166] risc-v (last) insn-emit-nn.c build takes hours
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116166 --- Comment #10 from Mark Wielaard --- (In reply to Andrew Macleod from comment #7) > Meanwhile the "workaround" might be to use '-fno-tree-dominator-opts' That reduces the compile time from hours to just 15 minutes! Still trying to figure out where to insert it. Adding it to BOOT_CFLAGS seems overkill and creates warning/errors for various string-compare and format-truncation warnings because it is missing some constant optimizations.
[Bug tree-optimization/116166] risc-v (last) insn-emit-nn.c build takes hours
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116166 --- Comment #12 from Mark Wielaard --- (In reply to Andreas Schwab from comment #11) > You can add target-specific flags like this: > > $(INSNEMIT_SEQ_O): ALL_COMPILERFLAGS += -fno-tree-dominator-opts Thanks. With "$(GIMPLE_MATCH_PD_SEQ_O) $(INSNEMIT_SEQ_O) insn-opinit.o insn-recog.o: ALL_COMPILERFLAGS += -O1 -fno-tree-dominator-opts" a make -j64 drops from 8 hours to 3.5 hours: real202m25.031s user2209m7.176s sys 108m49.102s Now insn-recog.cc (even though it is included in the workaround) takes the longest time (~1 hour) to compile.
[Bug target/116152] RISC-V: Proposed deprecation of LP64E abi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116152 Mark Wielaard changed: What|Removed |Added CC||mark at gcc dot gnu.org --- Comment #2 from Mark Wielaard --- This seems to have broken the build because the URL isn't quoted correctly: ../../gcc/gcc/config/riscv/riscv.cc: In function ‘void riscv_option_override()’: ../../gcc/gcc/config/riscv/riscv.cc:9829:35: error: unquoted sequence of 3 consecutive punctuation characters ‘://’ in format [-Werror=format-diag] 9829 | inform (UNKNOWN_LOCATION, "If you need LP64E please notify the GCC " | ^~ 9830 | "project via https://gcc.gnu.org/PR116152";); | ~~ cc1plus: all warnings being treated as errors make[3]: *** [Makefile:2555: riscv.o] Error 1 make[3]: *** Waiting for unfinished jobs https://builder.sourceware.org/buildbot/#/builders/310/builds/25
[Bug tree-optimization/116166] [13/14 Regression] risc-v (last) insn-emit-nn.c build takes hours
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116166 --- Comment #26 from Mark Wielaard --- With gcc-15-2791-g2083389a18d native build of the preprocessed insn-emit-96.cc from attachment #1 goes from 6 hours to 5 minutes. Time variable usr sys wall GGC phase setup: 0.04 ( 0%) 0.02 ( 0%) 0.05 ( 0%) 2844k ( 0%) phase parsing : 11.98 ( 4%) 10.66 ( 47%) 22.73 ( 7%) 306M ( 47%) phase lang. deferred : 0.20 ( 0%) 0.01 ( 0%) 0.22 ( 0%) 2970k ( 0%) phase opt and generate : 278.46 ( 96%) 11.75 ( 52%) 291.62 ( 93%) 346M ( 53%) phase last asm : 0.01 ( 0%) 0.01 ( 0%) 0.02 ( 0%) 69k ( 0%) phase finalize : 0.00 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 0 ( 0%) |name lookup : 2.16 ( 1%) 1.64 ( 7%) 3.94 ( 1%) 4335k ( 1%) |overload resolution : 2.15 ( 1%) 1.33 ( 6%) 3.28 ( 1%) 30M ( 5%) garbage collection : 0.92 ( 0%) 1.84 ( 8%) 2.76 ( 1%) 0 ( 0%) dump files : 0.85 ( 0%) 0.18 ( 1%) 1.02 ( 0%) 0 ( 0%) callgraph construction : 0.46 ( 0%) 0.04 ( 0%) 0.54 ( 0%) 4404k ( 1%) callgraph optimization : 0.41 ( 0%) 0.06 ( 0%) 0.53 ( 0%) 108k ( 0%) callgraph functions expansion : 261.74 ( 90%) 10.47 ( 47%) 273.55 ( 87%) 264M ( 40%) callgraph ipa passes : 15.34 ( 5%) 1.17 ( 5%) 16.57 ( 5%) 29M ( 4%) ipa function summary : 0.34 ( 0%) 0.02 ( 0%) 0.31 ( 0%) 1513k ( 0%) ipa dead code removal : 0.02 ( 0%) 0.00 ( 0%) 0.02 ( 0%) 0 ( 0%) ipa inheritance graph : 0.01 ( 0%) 0.00 ( 0%) 0.00 ( 0%) 152 ( 0%) ipa devirtualization : 0.01 ( 0%) 0.00 ( 0%) 0.00 ( 0%) 0 ( 0%) ipa cp : 0.15 ( 0%) 0.02 ( 0%) 0.19 ( 0%) 695k ( 0%) ipa inlining heuristics: 0.10 ( 0%) 0.10 ( 0%) 0.26 ( 0%) 345k ( 0%) ipa function splitting : 0.21 ( 0%) 0.00 ( 0%) 0.14 ( 0%) 52k ( 0%) ipa comdats: 0.01 ( 0%) 0.00 ( 0%) 0.00 ( 0%) 0 ( 0%) ipa various optimizations : 0.01 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 0 ( 0%) ipa reference : 0.01 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 0 ( 0%) ipa pure const : 0.15 ( 0%) 0.02 ( 0%) 0.15 ( 0%) 0 ( 0%) ipa icf: 0.11 ( 0%) 0.00 ( 0%) 0.11 ( 0%) 0 ( 0%) ipa SRA: 0.14 ( 0%) 0.00 ( 0%) 0.15 ( 0%) 137k ( 0%) ipa free lang data : 0.01 ( 0%) 0.00 ( 0%) 0.00 ( 0%) 0 ( 0%) ipa modref : 0.11 ( 0%) 0.00 ( 0%) 0.12 ( 0%) 541k ( 0%) cfg construction : 0.35 ( 0%) 0.10 ( 0%) 0.40 ( 0%) 11M ( 2%) cfg cleanup: 3.59 ( 1%) 0.10 ( 0%) 3.81 ( 1%) 2215k ( 0%) trivially dead code: 0.55 ( 0%) 0.04 ( 0%) 0.53 ( 0%) 0 ( 0%) df scan insns : 0.46 ( 0%) 0.06 ( 0%) 0.43 ( 0%) 88k ( 0%) df reaching defs : 0.81 ( 0%) 0.06 ( 0%) 0.82 ( 0%) 0 ( 0%) df live regs : 4.37 ( 2%) 0.27 ( 1%) 4.54 ( 1%) 0 ( 0%) df live&initialized regs : 2.34 ( 1%) 0.08 ( 0%) 2.54 ( 1%) 0 ( 0%) df must-initialized regs : 0.18 ( 0%) 0.00 ( 0%) 0.16 ( 0%) 0 ( 0%) df use-def / def-use chains: 0.32 ( 0%) 0.02 ( 0%) 0.37 ( 0%) 0 ( 0%) df reg dead/unused notes : 2.11 ( 1%) 0.11 ( 0%) 2.07 ( 1%) 2691k ( 0%) register information : 1.09 ( 0%) 0.14 ( 1%) 1.24 ( 0%) 0 ( 0%) alias analysis : 1.64 ( 1%) 0.10 ( 0%) 1.91 ( 1%) 9836k ( 1%) alias stmt walking : 0.16 ( 0%) 0.05 ( 0%) 0.15 ( 0%) 0 ( 0%) register scan : 0.13 ( 0%) 0.01 ( 0%) 0.16 ( 0%) 59k ( 0%) rebuild jump labels: 0.33 ( 0%) 0.02 ( 0%) 0.24 ( 0%) 0 ( 0%) preprocessing : 0.98 ( 0%) 2.08 ( 9%) 3.00 ( 1%) 26M ( 4%) parser (global): 3.80 ( 1%) 4.47 ( 20%) 8.31 ( 3%) 175M ( 27%) parser struct body : 0.32 ( 0%) 0.09 ( 0%) 0.38 ( 0%) 6856k ( 1%) parser enumerator list : 0.22 ( 0%) 0.22 ( 1%) 0.46 ( 0%) 8060k ( 1%) parser function body : 4.28 ( 1%) 2.47 ( 11%) 7.02 ( 2%) 61M ( 9%) parser inl. func. body : 0.78 ( 0%) 0.36 ( 2%) 1.23 (
[Bug tree-optimization/116166] [13/14 Regression] risc-v (last) insn-emit-nn.c build takes hours
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116166 Mark Wielaard changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=116146 --- Comment #27 from Mark Wielaard --- With gcc-15-2794-g5b97d1a most insn-*.cc files compile in minutes. The only exception is insn-recog.cc which takes 85 minutes (1 hour 25 minutes). Time variable usr sys wall GGC phase setup: 0.07 ( 0%) 0.04 ( 0%) 0.11 ( 0%) 2844k ( 0%) phase parsing : 201.81 ( 4%) 42.93 ( 28%) 245.90 ( 5%) 1189M ( 21%) phase lang. deferred : 0.38 ( 0%) 0.05 ( 0%) 0.43 ( 0%) 2659k ( 0%) phase opt and generate :4774.72 ( 96%) 109.82 ( 72%)4907.10 ( 95%) 4440M ( 79%) phase last asm : 0.03 ( 0%) 0.00 ( 0%) 0.03 ( 0%) 48 ( 0%) |name lookup : 14.27 ( 0%) 2.80 ( 2%) 16.63 ( 0%) 4296k ( 0%) |overload resolution : 36.86 ( 1%) 5.25 ( 3%) 41.14 ( 1%) 135M ( 2%) garbage collection : 14.27 ( 0%) 4.73 ( 3%) 19.06 ( 0%) 0 ( 0%) dump files : 2.16 ( 0%) 0.08 ( 0%) 2.16 ( 0%) 0 ( 0%) callgraph construction : 44.76 ( 1%) 4.36 ( 3%) 49.32 ( 1%) 530M ( 9%) callgraph optimization : 11.08 ( 0%) 2.23 ( 1%) 13.63 ( 0%) 59k ( 0%) callgraph functions expansion :4033.43 ( 81%) 75.70 ( 50%)4128.66 ( 80%) 3151M ( 56%) callgraph ipa passes : 665.59 ( 13%) 31.14 ( 20%) 699.38 ( 14%) 456M ( 8%) ipa function summary : 14.36 ( 0%) 0.28 ( 0%) 14.82 ( 0%) 15M ( 0%) ipa dead code removal : 1.39 ( 0%) 0.02 ( 0%) 1.37 ( 0%) 0 ( 0%) ipa inheritance graph : 0.02 ( 0%) 0.00 ( 0%) 0.02 ( 0%) 152 ( 0%) ipa devirtualization : 0.02 ( 0%) 0.00 ( 0%) 0.02 ( 0%) 0 ( 0%) ipa cp : 7.86 ( 0%) 0.37 ( 0%) 8.33 ( 0%) 9201k ( 0%) ipa inlining heuristics: 7.76 ( 0%) 0.59 ( 0%) 8.24 ( 0%) 28M ( 1%) ipa function splitting : 0.55 ( 0%) 0.03 ( 0%) 0.66 ( 0%) 36k ( 0%) ipa comdats: 0.09 ( 0%) 0.00 ( 0%) 0.08 ( 0%) 0 ( 0%) ipa various optimizations : 0.02 ( 0%) 0.00 ( 0%) 0.02 ( 0%) 0 ( 0%) ipa reference : 0.18 ( 0%) 0.00 ( 0%) 0.18 ( 0%) 0 ( 0%) ipa profile: 0.06 ( 0%) 0.00 ( 0%) 0.06 ( 0%) 0 ( 0%) ipa pure const : 4.89 ( 0%) 0.17 ( 0%) 5.00 ( 0%) 9648 ( 0%) ipa icf: 8.30 ( 0%) 1.88 ( 1%) 10.22 ( 0%) 0 ( 0%) ipa SRA: 95.18 ( 2%) 1.04 ( 1%) 96.50 ( 2%) 16M ( 0%) ipa free lang data : 0.02 ( 0%) 0.00 ( 0%) 0.02 ( 0%) 0 ( 0%) ipa free inline summary: 0.18 ( 0%) 0.02 ( 0%) 0.20 ( 0%) 0 ( 0%) ipa modref : 8.55 ( 0%) 0.05 ( 0%) 8.62 ( 0%) 3720k ( 0%) cfg construction : 1.83 ( 0%) 0.04 ( 0%) 1.93 ( 0%) 14M ( 0%) cfg cleanup: 54.36 ( 1%) 0.85 ( 1%) 55.83 ( 1%) 23M ( 0%) trivially dead code: 14.16 ( 0%) 0.13 ( 0%) 14.18 ( 0%) 0 ( 0%) df scan insns : 25.06 ( 1%) 0.35 ( 0%) 25.37 ( 0%) 147k ( 0%) df reaching defs : 20.26 ( 0%) 0.17 ( 0%) 20.15 ( 0%) 0 ( 0%) df live regs : 143.04 ( 3%) 2.10 ( 1%) 145.64 ( 3%) 0 ( 0%) df live&initialized regs : 75.37 ( 2%) 0.93 ( 1%) 77.70 ( 2%) 0 ( 0%) df must-initialized regs : 2.80 ( 0%) 0.02 ( 0%) 3.04 ( 0%) 0 ( 0%) df use-def / def-use chains: 9.87 ( 0%) 0.06 ( 0%) 10.06 ( 0%) 0 ( 0%) df reg dead/unused notes : 47.82 ( 1%) 1.04 ( 1%) 48.15 ( 1%) 46M ( 1%) register information : 64.50 ( 1%) 0.88 ( 1%) 66.26 ( 1%) 0 ( 0%) alias analysis : 46.03 ( 1%) 0.51 ( 0%) 47.00 ( 1%) 202M ( 4%) alias stmt walking : 30.76 ( 1%) 1.98 ( 1%) 30.73 ( 1%) 106k ( 0%) register scan : 5.85 ( 0%) 0.09 ( 0%) 6.14 ( 0%) 2405k ( 0%) rebuild jump labels: 5.38 ( 0%) 0.15 ( 0%) 5.76 ( 0%) 96 ( 0%) preprocessing : 13.40 ( 0%) 11.45 ( 7%) 25.81 ( 1%) 245M ( 4%) parser (global)
[Bug preprocessor/116458] [15 regression] New valgrind error in search_line_ssse3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116458 --- Comment #7 from Mark Wielaard --- You could try --expensive-definedness-checks=yes --expensive-definedness-checks= [default: auto] Controls whether Memcheck should employ more precise but also more expensive (time consuming) instrumentation when checking the definedness of certain values. In particular, this affects the instrumentation of integer adds, subtracts and equality comparisons. Selecting --expensive-definedness-checks=yes causes Memcheck to use the most accurate analysis possible. This minimises false error rates but can cause up to 30% performance degradation. Selecting --expensive-definedness-checks=no causes Memcheck to use the cheapest instrumentation possible. This maximises performance but will normally give an unusably high false error rate. The default setting, --expensive-definedness-checks=auto, is strongly recommended. This causes Memcheck to use the minimum of expensive instrumentation needed to achieve the same false error rate as --expensive-definedness-checks=yes. It also enables an instrumentation-time analysis pass which aims to further reduce the costs of accurate instrumentation. Overall, the performance loss is generally around 5% relative to --expensive-definedness-checks=no, although this is strongly workload dependent. Note that the exact instrumentation settings in this mode are architecture dependent.
[Bug rust/116561] New: gcc/testsuite/rust/execute/torture/iter1.rs:350:5: internal compiler error: 'verify_gimple' failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116561
Bug ID: 116561
Summary: gcc/testsuite/rust/execute/torture/iter1.rs:350:5:
internal compiler error: 'verify_gimple' failed
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rust
Assignee: unassigned at gcc dot gnu.org
Reporter: mark at gcc dot gnu.org
CC: dkm at gcc dot gnu.org, gcc-rust at gcc dot gnu.org,
pierre-emmanuel.patry at embecosm dot com
Target Milestone: ---
A gcc configured with --enable-languages=rust and
--enable-checking=yes,extra,rtl will show failures in
rust/rust/execute/torture/iter1.rs with internal compiler error:
'verify_gimple' failed
https://builder.sourceware.org/buildbot/#/builders/312/builds/24
=== rust tests ===
Running target unix
FAIL: rust/execute/torture/iter1.rs -O1 (internal compiler error:
'verify_gimple' failed)
FAIL: rust/execute/torture/iter1.rs -O1 (test for excess errors)
UNRESOLVED: rust/execute/torture/iter1.rs -O1 compilation failed to produce
executable
FAIL: rust/execute/torture/iter1.rs -O2 (internal compiler error:
'verify_gimple' failed)
FAIL: rust/execute/torture/iter1.rs -O2 (test for excess errors)
UNRESOLVED: rust/execute/torture/iter1.rs -O2 compilation failed to produce
executable
FAIL: rust/execute/torture/iter1.rs -O2 -flto -fno-use-linker-plugin
-flto-partition=none (internal compiler error: 'verify_gimple' failed)
FAIL: rust/execute/torture/iter1.rs -O2 -flto -fno-use-linker-plugin
-flto-partition=none (test for excess errors)
UNRESOLVED: rust/execute/torture/iter1.rs -O2 -flto -fno-use-linker-plugin
-flto-partition=none compilation failed to produce executable
FAIL: rust/execute/torture/iter1.rs -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects (internal compiler error: 'verify_gimple' failed)
FAIL: rust/execute/torture/iter1.rs -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects (test for excess errors)
UNRESOLVED: rust/execute/torture/iter1.rs -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects compilation failed to produce executable
FAIL: rust/execute/torture/iter1.rs -O3 -g (internal compiler error:
'verify_gimple' failed)
FAIL: rust/execute/torture/iter1.rs -O3 -g (test for excess errors)
UNRESOLVED: rust/execute/torture/iter1.rs -O3 -g compilation failed to
produce executable
FAIL: rust/execute/torture/iter1.rs -Os (internal compiler error:
'verify_gimple' failed)
FAIL: rust/execute/torture/iter1.rs -Os (test for excess errors)
UNRESOLVED: rust/execute/torture/iter1.rs -Os compilation failed to produce
executable
=== rust Summary ===
# of expected passes8421
# of unexpected failures12
# of expected failures 69
# of unresolved testcases 6
# of unsupported tests 1
Logs are in bunsen:
https://builder.sourceware.org/testrun/a838fa2940edef1f921401c6066417d2e88b6008?rawfilename=gcc%2Ftestsuite%2Frust%2Frust.log
Executing on host:
/home/builder/shared/x3d1/worker/gcc-fullest-debian-amd64/gcc-build/gcc/testsuite/rust/../../gccrs
-B/home/builder/shared/x3d1/worker/gcc-fullest-debian-amd64/gcc-build/gcc/testsuite/rust/../../
/home/builder/shared/x3d1/worker/gcc-fullest-debian-amd64/gcc/gcc/testsuite/rust/execute/torture/iter1.rs
-fdiagnostics-plain-output
-frust-incomplete-and-experimental-compiler-do-not-use -O1 -lm -o
./iter1.exe(timeout = 10)
spawn -ignore SIGHUP
/home/builder/shared/x3d1/worker/gcc-fullest-debian-amd64/gcc-build/gcc/testsuite/rust/../../gccrs
-B/home/builder/shared/x3d1/worker/gcc-fullest-debian-amd64/gcc-build/gcc/testsuite/rust/../../
/home/builder/shared/x3d1/worker/gcc-fullest-debian-amd64/gcc/gcc/testsuite/rust/execute/torture/iter1.rs
-fdiagnostics-plain-output
-frust-incomplete-and-experimental-compiler-do-not-use -O1 -lm -o ./iter1.exe
/home/builder/shared/x3d1/worker/gcc-fullest-debian-amd64/gcc/gcc/testsuite/rust/execute/torture/iter1.rs:
In function '>::try_from':
/home/builder/shared/x3d1/worker/gcc-fullest-debian-amd64/gcc/gcc/testsuite/rust/execute/torture/iter1.rs:350:5:
error: non-trivial conversion in 'constructor'
union iter1::result::Result
union iter1::result::Result
D.4488 = {};
/home/builder/shared/x3d1/worker/gcc-fullest-debian-amd64/gcc/gcc/testsuite/rust/execute/torture/iter1.rs:350:5:
internal compiler error: 'verify_gimple' failed
0x332987b internal_error(char const*, ...)
../../gcc/gcc/diagnostic-global-context.cc:492
0x1bcbcc6 verify_gimple_in_seq(gimple*, bool)
../../gcc/gcc/tree-cfg.cc:5332
0x17e56ba gimplify_body(tree_node*, bool)
../../gcc/gcc/gimplify.cc:19488
0x17e5865 gimplify_function_tree(tree_node*)
../../gcc/gcc/gimplify.cc:19606
0x15e7087 cgraph_node::analyze()
../../gcc/gcc/cgraphunit.cc:687
0x15e9e87 analyze_functions
../../gcc/gcc/cgraphun
[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/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 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 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 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 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 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 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 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 #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 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/117039] [15 Regression] Build failure: libcpp/directives.cc:2078:34: error: unknown conversion type character '>' in format [-Werror=format=]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117039 Mark Wielaard changed: What|Removed |Added CC||mark at gcc dot gnu.org --- Comment #1 from Mark Wielaard --- https://builder.sourceware.org/buildbot/#/changes/63248 "gcc, libcpp: Add warning switch for "#pragma once in main file" [PR89808]" Fails bootstrap as above on arm64, amd64 and riscv.
[Bug ada/116945] Valgrind reports uninitialized memory use in sem_ch12.adb (sem_ch12__instance_context__save_and_reset)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116945 --- Comment #13 from Mark Wielaard --- (In reply to Eric Botcazou from comment #12) > Unlike the C and C++ standards, the Ada standard is freely available at: > http://www.ada-auth.org/standards/22rm/html/RM-TTL.html > and the 'Valid attribute is specified there: > http://www.ada-auth.org/standards/22rm/html/RM-13-9-2.html Thanks for the reference. But this does seem to be a bit of a circular definition. It says the 'Valid attribute can be used to check whether the value has a valid representation, and an invalid representation can be created by an uninitialized object. But it doesn't define how it checks for the invalid representation. It does state that it is not an error to check the validity of an object that is invalid. "Determining whether X is normal and has a valid representation as part of the evaluation of X'Valid is not considered to include an evaluation of X." But it looks like valgrind here determines that an evaluation of X is happening because the code flow depends on uninitialized value. I think what makes this hard is that nobody seems to know what code is being generated for this case. Sam, might it be possible to disassemble or produce the assembly gnat creates for the code that triggers this error?
[Bug ada/116945] Valgrind reports uninitialized memory use in sem_ch12.adb (sem_ch12__instance_context__save_and_reset)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116945 --- Comment #9 from Mark Wielaard --- Re comment #4. Sam reports that --expensive-definedness-checks=yes doesn't work in this case.
[Bug target/117316] [15 regression] gcc/config/riscv/riscv.cc:479:1: error: could not convert ‘...’ from ‘’ to ‘const riscv_tune_param’ since r15-4589-g078f7c4f1fcf4d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117316 Mark Wielaard changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2024-10-27 CC||mark at gcc dot gnu.org --- Comment #2 from Mark Wielaard --- The gcc-full-fedora-riscv buildbot has been red for several days now: https://builder.sourceware.org/buildbot/#/builders/gcc-full-fedora-riscv
[Bug ada/116945] Valgrind reports uninitialized memory use in sem_ch12.adb (sem_ch12__instance_context__save_and_reset)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116945 --- Comment #3 from Mark Wielaard --- What code is generated for that call to 'Valid in "if Indexed_Assoc.Gen_Id'Valid then". Does that conditional really depend on uninitialized data?
[Bug ada/116945] Valgrind reports uninitialized memory use in sem_ch12.adb (sem_ch12__instance_context__save_and_reset)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116945 --- Comment #4 from Mark Wielaard --- Also does running valgrind memcheck with --expensive-definedness-checks=yes help? --expensive-definedness-checks= [default: auto] Controls whether Memcheck should employ more precise but also more expensive (time consuming) instrumentation when checking the definedness of certain values. In particular, this affects the instrumentation of integer adds, subtracts and equality comparisons. Selecting --expensive-definedness-checks=yes causes Memcheck to use the most accurate analysis possible. This minimises false error rates but can cause up to 30% performance degradation.
[Bug ada/116945] Valgrind reports uninitialized memory use in sem_ch12.adb (sem_ch12__instance_context__save_and_reset)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116945 --- Comment #6 from Mark Wielaard --- (In reply to Eric Botcazou from comment #5) > > What code is generated for that call to 'Valid in "if > > Indexed_Assoc.Gen_Id'Valid then". Does that conditional really depend on > > uninitialized data? > > Yes, as explained in the comment, Indexed_Assoc.Gen_Id may be uninitialized. Sure. But I assume the unitialized part isn't accessed when resolving the 'Valid attribute. Does checking for the 'Valid attribute depend on any uninitialized bits? What would probably be most useful is knowing what code is generated for that if statement.
[Bug ada/116945] Valgrind reports uninitialized memory use in sem_ch12.adb (sem_ch12__instance_context__save_and_reset)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116945 --- Comment #8 from Mark Wielaard --- (In reply to Eric Botcazou from comment #7) > > Sure. But I assume the unitialized part isn't accessed when resolving the > > 'Valid attribute. Does checking for the 'Valid attribute depend on any > > uninitialized bits? > > Testing 'Valid means comparing the value with the allowed range, so how can > you do that without accessing that value? I don't know, my Ada foo isn't very strong. How is the allowed range defined? How do you test for it? Doesn't that mean the value needs to be defined at least for that range check? If not, is the 'Valid attribute check non-deterministic because you cannot rely on the value being or not being in the allowed range?
[Bug other/116947] --enable-checking=valgrind ignores failures during bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116947 --- Comment #3 from Mark Wielaard --- Does --enable-checking=valgrind imply --enable-valgrind-annotations ? If not I would enable --error-exitcode=99 only if --enable-valgrind-annotations is also given (to avoid erroring out on false positives).
[Bug tree-optimization/116166] [13 Regression] risc-v (last) insn-emit-nn.c build takes hours
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116166 Mark Wielaard changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #34 from Mark Wielaard --- (In reply to Mark Wielaard from comment #33) > (In reply to Robin Dapp from comment #32) > > With insn-recog split, is this still relevant or can we close it? > > I think it is not relevant anymore, but I haven't been able to verify yet. > > The current compile hog is insn-attrtab.cc which takes a couple of hours to > compile. > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118032 As just commented on that bug there is a very nice speedup somewhere after December 11 and today, when a full bootstrap test (on a 64 core riscv machine) took ~4 hours, now it takes just ~3 hours. So lets close this bug.
[Bug target/111600] [14/15 Regression] RISC-V bootstrap time regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600 Bug 111600 depends on bug 116166, which changed state. Bug 116166 Summary: [13 Regression] risc-v (last) insn-emit-nn.c build takes hours https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116166 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/118032] [15 regression] Bootstrap slowdown for risc-v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118032
--- Comment #34 from Mark Wielaard ---
After r15-6598-g668cad04b16fc044142474232ac072fcc5f94433
("tree-switch-conversion: don't apply switch size limit on jump tables") the
build speeds up considerably:
https://builder.sourceware.org/buildbot/#/builders/310/builds/787
make -j64: 1h:31m
make check -j64: 1h:28m
total: 3h:08m
(The extra few minutes come from checkout, setup, etc.)
This is a considerable speedup, even compared to about a month ago.
On December 11 a full build took ~4 hours.
[Bug tree-optimization/118032] [15 regression] Bootstrap slowdown for risc-v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118032 --- Comment #35 from Mark Wielaard --- Shall we close this bug or keep it open for implementing greedy switch clustering for jump tables as suggested in comment #29 ?
[Bug tree-optimization/118032] Bootstrap slowdown for risc-v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118032 --- Comment #4 from Mark Wielaard --- The slowdown is on the pioneer box, which has 64 cores and 128GB ram. https://builder.sourceware.org/buildbot/#/builders/gcc-full-fedora-riscv See the build times tab on that page. It used to do builds in 4 to 5 hours (it slowly increased in the last month) (bootstrap, make -j64 in ~2.5 hours, plus tests, make -j64 check in ~1.5 hours) But recently jumped to ~9 hours (bootstrap, make -j64 in ~7.5 hours, plus tests, make -j64 check in ~1.5 hours) And in the last day it kept timing out trying to build insn-attrtab.cc for more than 2.5 hours.
[Bug tree-optimization/116166] [13 Regression] risc-v (last) insn-emit-nn.c build takes hours
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116166 --- Comment #33 from Mark Wielaard --- (In reply to Robin Dapp from comment #32) > With insn-recog split, is this still relevant or can we close it? I think it is not relevant anymore, but I haven't been able to verify yet. The current compile hog is insn-attrtab.cc which takes a couple of hours to compile. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118032
[Bug tree-optimization/118032] [15 regression] Bootstrap slowdown for risc-v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118032
--- Comment #15 from Robin Dapp ---
> Based on earlier builds this file will take 2.5 to 3 hours to build (while
> all other cores are idle).
insn-attrtab.c doesn't consist of many functions so a split won't help. Given
that we have a number of huge if/else constructs in it I could imagine the
ifcombine change being a culprit.
--- Comment #16 from Mark Wielaard ---
The slowdown of make -j64 seems to have occurred between a build against
revision 92e0e0f8177530b8c6fcafe1d61ba03b00dff6a6 (which took ~3h:15m) and
revision bbb7c53d32ece75ec0c336663ec37df9e63652d3 (which took ~7h:45m).
make check -j64 builds didn't seem to slow down at all (takes ~1h:30m)
Which would be just 11 commits:
bbb7c53d32ec ("Fortran: Add DECL_EXPR for variable length assoc name
[PR117901]")
56946c801a7c ("gimple: Add limit after which slower switchlower algs are used
[PR117091] [PR117352]")
337815c8bbd0 ("c++: allow stores to anon union vars to change current union
member in constexpr [PR117614]")
4b4023d52986 ("c++: tweak colorization of incompatible declspecs")
7435d1dbae8a ("diagnostics: suppress "note: " prefix in nested diagnostics
[PR116253]")
d3dd24acd746 ("c++: print z candidate count and number them (v2)")
331226fd87c2 ("diagnostics: tweak output for nested messages [PR116253]")
e4ef3aa2911f ("input.cc: rename file_cache:in_context")
d9f87b7b02d3 ("Ada: Add GNU/Hurd x86_64 support")
d56e82d1a937 ("Ada: Fix GNU/Hurd priority range")
aeab6f88a115 ("Ada: Factorize bsd signal definitions")
Since insn-attrtab.cc contains lots of large switch tables might it have been
commit 56946c801a7c ("gimple: Add limit after which slower switchlower algs are
used [PR117091] [PR117352]")?
[Bug tree-optimization/118032] [15 regression] Bootstrap slowdown for risc-v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118032 --- Comment #13 from Mark Wielaard --- Just looking at a current build there are a couple of files that take 10+ minutes to build while nothing else is building: gimple-match-10.cc gimple-match-91.cc insn-opinit.cc lto-lang.cc insn-attrtab.cc That is with configure --with-arch=rv64gc --with-abi=lp64d --with-multilib-list=lp64d --enable-checking=release --with-matchpd-partitions=96 --with-insnemit-partitions=96
[Bug tree-optimization/118032] [15 regression] Bootstrap slowdown for risc-v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118032 --- Comment #14 from Mark Wielaard --- After about 20~25 minutes only insn-attrtab.cc is left (all other files mentioned in comment #13 have compiled successfully). /home/builder/worker/gcc-full-fedora-riscv/gcc-build/./prev-gcc/cc1plus -quiet -nostdinc++ -I /home/builder/worker/gcc-full-fedora-riscv/gcc-build/prev-riscv64-unknown-linux-gnu/libstdc++-v3/include/riscv64-unknown-linux-gnu -I /home/builder/worker/gcc-full-fedora-riscv/gcc-build/prev-riscv64-unknown-linux-gnu/libstdc++-v3/include -I /home/builder/worker/gcc-full-fedora-riscv/gcc/libstdc++-v3/libsupc++ -I . -I . -I ../../gcc/gcc -I ../../gcc/gcc/. -I ../../gcc/gcc/../include -I ../../gcc/gcc/../libcpp/include -I ../../gcc/gcc/../libcody -I ../../gcc/gcc/../libdecnumber -I ../../gcc/gcc/../libdecnumber/dpd -I ../libdecnumber -I ../../gcc/gcc/../libbacktrace -imultilib . -iprefix /home/builder/worker/gcc-full-fedora-riscv/gcc-build/prev-gcc/../lib/gcc/riscv64-unknown-linux-gnu/15.0.0/ -isystem /home/builder/worker/gcc-full-fedora-riscv/gcc-build/./prev-gcc/include -isystem /home/builder/worker/gcc-full-fedora-riscv/gcc-build/./prev-gcc/include-fixed -MMD insn-attrtab.d -MF ./.deps/insn-attrtab.TPo -MP -MT insn-attrtab.o -D_GNU_SOURCE -D IN_GCC -D HAVE_CONFIG_H insn-attrtab.cc -quiet -dumpbase insn-attrtab.cc -dumpbase-ext .cc -march=rv64imafdc_zicsr_zifencei_zaamo_zalrsc -mabi=lp64d -misa-spec=20191213 -mtls-dialect=trad -march=rv64imafdc_zicsr_zifencei_zmmul_zaamo_zalrsc_zca_zcd -g -O2 -Wextra -Wall -Wno-error=narrowing -Wwrite-strings -Wcast-qual -Wsuggest-attribute=format -Wconditionally-supported -Woverloaded-virtual=2 -Wpedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fchecking=1 -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -fno-PIE -o /tmp/ccMkz4ih.s Based on earlier builds this file will take 2.5 to 3 hours to build (while all other cores are idle).
[Bug tree-optimization/118032] New: Bootstrap slowdown for risc-v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118032 Bug ID: 118032 Summary: Bootstrap slowdown for risc-v Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: mark at gcc dot gnu.org CC: aoliva at gcc dot gnu.org, law at gcc dot gnu.org, palmer at gcc dot gnu.org, sjames at gcc dot gnu.org, vmakarov at gcc dot gnu.org Target Milestone: --- Build times of https://builder.sourceware.org/buildbot/#/builders/gcc-full-fedora-riscv have doubled in recent days, from 4 hours to 8 hours... Are any others seeing this with their risc-v bootstraps? We haven't fully analysed it yet, but looking at `git log -p 92e0e0f8177530b8c6fcafe1d61ba03b00dff6a6..b563a3a00db064d4d47fd171379e1d34d0698faa` (https://builder.sourceware.org/buildbot/#/builders/310/builds/730 vs https://builder.sourceware.org/buildbot/#/builders/310/builds/732), it surely is the ifcombine changes or the LRA one. commit fca0ab08cd936464b152e9b45356f625eba27575 Author: Vladimir N. Makarov Date: Wed Dec 11 15:36:21 2024 -0500 [PR116778][LRA]: Check pseudos assigned to FP after rematerialization to build live ranges commit e8febb641415fd80eabce1c4fdf2d4a4b411213b Author: Alexandre Oliva Date: Thu Dec 12 11:43:03 2024 -0300 fold fold_truth_andor field merging into ifcombine commit 3eb6e1e3335fe0aabc79e75bf4d71366727c3971 Author: Alexandre Oliva Date: Thu Dec 12 11:43:09 2024 -0300 ifcombine field-merge: set upper bound for get_best_mode
[Bug tree-optimization/118032] [15 regression] Bootstrap slowdown for risc-v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118032
--- Comment #21 from Mark Wielaard ---
(In reply to Mark Wielaard from comment #14)
> After about 20~25 minutes only insn-attrtab.cc is left (all other files
> mentioned in comment #13 have compiled successfully).
>
> /home/builder/worker/gcc-full-fedora-riscv/gcc-build/./prev-gcc/cc1plus
> -quiet -nostdinc++ -I
> /home/builder/worker/gcc-full-fedora-riscv/gcc-build/prev-riscv64-unknown-
> linux-gnu/libstdc++-v3/include/riscv64-unknown-linux-gnu -I
> /home/builder/worker/gcc-full-fedora-riscv/gcc-build/prev-riscv64-unknown-
> linux-gnu/libstdc++-v3/include -I
> /home/builder/worker/gcc-full-fedora-riscv/gcc/libstdc++-v3/libsupc++ -I .
> -I . -I ../../gcc/gcc -I ../../gcc/gcc/. -I ../../gcc/gcc/../include -I
> ../../gcc/gcc/../libcpp/include -I ../../gcc/gcc/../libcody -I
> ../../gcc/gcc/../libdecnumber -I ../../gcc/gcc/../libdecnumber/dpd -I
> ../libdecnumber -I ../../gcc/gcc/../libbacktrace -imultilib . -iprefix
> /home/builder/worker/gcc-full-fedora-riscv/gcc-build/prev-gcc/../lib/gcc/
> riscv64-unknown-linux-gnu/15.0.0/ -isystem
> /home/builder/worker/gcc-full-fedora-riscv/gcc-build/./prev-gcc/include
> -isystem
> /home/builder/worker/gcc-full-fedora-riscv/gcc-build/./prev-gcc/include-
> fixed -MMD insn-attrtab.d -MF ./.deps/insn-attrtab.TPo -MP -MT
> insn-attrtab.o -D_GNU_SOURCE -D IN_GCC -D HAVE_CONFIG_H insn-attrtab.cc
> -quiet -dumpbase insn-attrtab.cc -dumpbase-ext .cc
> -march=rv64imafdc_zicsr_zifencei_zaamo_zalrsc -mabi=lp64d
> -misa-spec=20191213 -mtls-dialect=trad
> -march=rv64imafdc_zicsr_zifencei_zmmul_zaamo_zalrsc_zca_zcd -g -O2 -Wextra
> -Wall -Wno-error=narrowing -Wwrite-strings -Wcast-qual
> -Wsuggest-attribute=format -Wconditionally-supported -Woverloaded-virtual=2
> -Wpedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
> -Werror -fchecking=1 -fno-exceptions -fno-rtti -fasynchronous-unwind-tables
> -fno-PIE -o /tmp/ccMkz4ih.s
>
> Based on earlier builds this file will take 2.5 to 3 hours to build (while
> all other cores are idle).
Reverting commit 56946c801a7c ("gimple: Add limit after which slower
switchlower algs are used [PR117091] [PR117352]") on top of commit
gcc-15-6366-g8462a5fdbfe brings the above compile down to just 1m9.461s.
Total bootstrap (make -j64) comes down to 2 hours and 20 minutes (from 6 to 8
hours).
[Bug tree-optimization/118032] [15 regression] Bootstrap slowdown for risc-v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118032 --- Comment #23 from Mark Wielaard --- Created attachment 59930 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59930&action=edit preprocessed -E output of generated insn-attrtab.cc Note that the generated insn-attrtab.cc file is 10M. The -E output is slightly less 9.4M (because all comments have been removed). Compressed with xz -9e insn-attrtab.i
[Bug tree-optimization/118032] [15 regression] Bootstrap slowdown for risc-v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118032
--- Comment #26 from Mark Wielaard ---
(In reply to Andreas Schwab from comment #25)
> 20241220: 2d 06:58:23
That seems like a nice speedup. Do you know what caused that?
Is the because r15-6223-g6dcfe8743134936db17ffdfd0a5102a87338f494 ("genrecog:
Split into separate partitions [PR111600]")?
[Bug tree-optimization/118353] Implement greedy algorithm for switch jump table cluster finding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118353 --- Comment #5 from Mark Wielaard --- One difference might be how many cores are used for the builds. The more cores how more sensitive they are for parallelism bottlenecks. And riscv (was) kind of special in that there were just a handful of files that could take a couple of hours to build. With the last patch there seems to be none that takes more than 30 minutes. The full bootstrap builders that sourceware has are here: https://builder.sourceware.org/buildbot/#/builders?tags=gcc-full amd64 make -j12 arm64 make -j16 riscv make -j64 sparc make -j64 Those do a bootstrap plus check in a couple of hours. Only the riscv one shows a big difference (8-9 hours to 3-4 hours). But it seems most of them had slightly longer build times end of November/December than in January. It isn't super clear though, the individual build timess differ a lot (partly because of the use of ccache, which can speed up stage 1 a lot).
[Bug tree-optimization/118032] [15 regression] Bootstrap slowdown for risc-v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118032 --- Comment #32 from Mark Wielaard --- (In reply to Mark Wielaard from comment #31) > (In reply to Filip Kastl from comment #30) > > (In reply to Mark Wielaard from comment #28) > > > I haven't tried yet, but do you mean something like the following? > > > - /* Note: l + 1 is the number of cases of the switch. */ > > > - if (l + 1 > (unsigned) param_switch_lower_slow_alg_max_cases) > > > -return clusters.copy (); > > > > Yes. Exactly that. > > OK, with just those 3 lines reverted (on top of commit > gcc-15-6430-g27af1a14f3a) compiling insn-attrtab.cc took just 60 seconds. Posted a patch to revert just those 3 lines: https://inbox.sourceware.org/gcc-patches/20250105172539.906393-1-m...@klomp.org/T/
[Bug tree-optimization/118032] [15 regression] Bootstrap slowdown for risc-v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118032 --- Comment #28 from Mark Wielaard --- (In reply to Filip Kastl from comment #24) > One way to fix this would be to not apply the switch size limit on jump > tables. Since finding jump tables is at least O(n^2), this could > theoretically cause long compile times in some specific cases. However, > nobody has reported any bug of that kind yet. There is only pr117091 for > bit tests. That pr would remain fixed, I believe. > > Do we want to do that, though? Maybe GCC taking this long to compile > something just because we didn't use jump table lowering is a sign of a > problem in a different pass? I haven't tried yet, but do you mean something like the following? diff --git a/gcc/tree-switch-conversion.cc b/gcc/tree-switch-conversion.cc index b98e70cf7d16..74abc74d842b 100644 --- a/gcc/tree-switch-conversion.cc +++ b/gcc/tree-switch-conversion.cc @@ -1643,10 +1643,6 @@ jump_table_cluster::find_jump_tables (vec &clusters) unsigned l = clusters.length (); - /* Note: l + 1 is the number of cases of the switch. */ - if (l + 1 > (unsigned) param_switch_lower_slow_alg_max_cases) -return clusters.copy (); - auto_vec min; min.reserve (l + 1);
[Bug tree-optimization/118032] [15 regression] Bootstrap slowdown for risc-v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118032 --- Comment #31 from Mark Wielaard --- (In reply to Filip Kastl from comment #30) > (In reply to Mark Wielaard from comment #28) > > I haven't tried yet, but do you mean something like the following? > > - /* Note: l + 1 is the number of cases of the switch. */ > > - if (l + 1 > (unsigned) param_switch_lower_slow_alg_max_cases) > > -return clusters.copy (); > > Yes. Exactly that. OK, with just those 3 lines reverted (on top of commit gcc-15-6430-g27af1a14f3a) compiling insn-attrtab.cc took just 60 seconds. Total make -j64 took: real139m44.774s user2015m35.598s sys 131m40.992s
[Bug tree-optimization/118032] [15 regression] Bootstrap slowdown for risc-v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118032 Mark Wielaard changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #37 from Mark Wielaard --- (In reply to Filip Kastl from comment #36) > (In reply to Mark Wielaard from comment #35) > > Shall we close this bug or keep it open for implementing greedy switch > > clustering for jump tables as suggested in comment #29 ? > > I think that it would be better to open a new bug report for this -- so I > did that. See pr118353. > > If I understand correctly, the build time has gone back to the original > numbers and we can close this bug, right? Yes, the build times became a bit faster compared to ~1 month ago, see comment #34.
