[Bug target/97205] arm: Compiler fails with an ICE for -O0 on Trunk and GCC-10 for _Generic feature.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97205 Bernd Edlinger changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #14 from Bernd Edlinger --- fixed on trunk.
[Bug testsuite/98225] gcc.misc-tests/outputs.exp ltrans_args tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98225 --- Comment #2 from Bernd Edlinger --- Unfortunately I cannot reproduce. I configured like this: ../gcc-trunk/configure --prefix=/home/ed/gnu/install --enable-languages=all and use GNU ld (GNU Binutils) 2.35.1
[Bug testsuite/98225] gcc.misc-tests/outputs.exp ltrans_args tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98225 --- Comment #4 from Bernd Edlinger --- It is interesting that some tests are reported failing on the x86_64-pc-linux-gnu platform that I also use. I really wonder what prevents these failures for me. Could you say if there the outputs.exp test case produces additional temp files in the /tmp folder when it fails?
[Bug testsuite/98225] gcc.misc-tests/outputs.exp ltrans_args tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98225 --- Comment #7 from Bernd Edlinger --- when you leave just one of those tests, you can get somewhat more verbose output by using something like that: make check-gcc-c RUNTESTFLAGS="--target_board=unix/-v/-Wl,-v outputs.exp" you should see where the collect-ld is invoked: collect2 version 11.0.0 20210105 (experimental)^M /home/ed/gnu/gcc-build/gcc/collect-ld @outputs.ld1_args^M GNU ld (GNU Binutils) 2.35.1^M The arguments are in a response-file: @outputs.ld1_args maybe that looks different for you?
[Bug testsuite/98225] gcc.misc-tests/outputs.exp ltrans_args tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98225 --- Comment #10 from Bernd Edlinger --- I tried to bootstrap with GNU ld (GNU Binutils for Ubuntu) 2.24 but still cannot reproduce the reported failure ltrans0.ltrans_args / ltrans0.ltrans_args.0 I really wonder what makes the difference.
[Bug testsuite/98225] gcc.misc-tests/outputs.exp ltrans_args tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98225
--- Comment #12 from Bernd Edlinger ---
Aah, now I see (lto-wrapper.c):
if (parallel)
{
fprintf (mstream, "%s:\n\t@%s ", output_name, new_argv[0]);
for (j = 1; new_argv[j] != NULL; ++j)
fprintf (mstream, " '%s'", new_argv[j]);
fprintf (mstream, "\n");
/* If we are not preserving the ltrans input files then
truncate them as soon as we have processed it. This
reduces temporary disk-space usage. */
if (! save_temps)
fprintf (mstream, "\t@-touch -r %s %s.tem > /dev/null 2>&1 "
"&& mv %s.tem %s\n",
input_name, input_name, input_name, input_name);
}
else
{
char argsuffix[sizeof (DUMPBASE_SUFFIX) + 1];
if (save_temps)
snprintf (argsuffix, sizeof (DUMPBASE_SUFFIX),
"ltrans%u.ltrans_args", i);
fork_execute (new_argv[0], CONST_CAST (char **, new_argv),
true, save_temps ? argsuffix : NULL);
maybe_unlink (input_name);
}
IF parallel is true, the "ltrans%u.ltrans_args and the "ltrans%u.ltrans_args.0
is obviously not taken.
AND on my system I use a gnu-make
that does not always pass the jobserver file ids to the sub-makes.
Only when "$(MAKE)" is used.
I already thought about adding something like "#$(MAKE)" somewhere
to un-break that
[Bug testsuite/98225] gcc.misc-tests/outputs.exp ltrans_args tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98225
--- Comment #13 from Bernd Edlinger ---
could someone try this for me?
diff --git a/gcc/testsuite/gcc.misc-tests/outputs.exp
b/gcc/testsuite/gcc.misc-tests
index 80d4b61..7cd755c 100644
--- a/gcc/testsuite/gcc.misc-tests/outputs.exp
+++ b/gcc/testsuite/gcc.misc-tests/outputs.exp
@@ -67,6 +67,9 @@ if {[board_info $dest exists output_format]} {
append link_options " additional_flags=-Wl,-oformat,[board_info $dest
output_fo
}
+# avoid influence from jobserver
+unsetenv MAKEFLAGS
+
# For the test named TEST, run the compiler with SOURCES and OPTS, and
# look in DIRS for OUTPUTS. SOURCES is a list of suffixes for source
# files starting with $b in $srcdir/$subdir, OPTS is a string with
Thanks!
[Bug testsuite/98225] gcc.misc-tests/outputs.exp ltrans_args tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98225 --- Comment #17 from Bernd Edlinger --- (In reply to David Edelsohn from comment #15) > I'm seeing a number of new testsuite failures on AIX after the > collect2/testsuite change. Do you want a separate PR or use this as well? > > They are: > > FAIL: outputs exe savetmp named2: extra > FAIL: outputs exe savetmp named2: extra > FAIL: outputs exe savetmp named2: extra the extra is maybe a different file that gets created. Can you look up in the log file, the line directly after the FAIL which files you see there?
[Bug testsuite/98225] gcc.misc-tests/outputs.exp ltrans_args tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98225 Bernd Edlinger changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #20 from Bernd Edlinger --- should be fixed now. Thanks!
[Bug target/100106] [10/11 Regression] ICE in gen_movdi, at config/arm/arm.md:6187 since r10-2840-g70cdb21e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100106 Bernd Edlinger changed: What|Removed |Added Summary|[10/11/12 Regression] ICE |[10/11 Regression] ICE in |in gen_movdi, at|gen_movdi, at |config/arm/arm.md:6187 |config/arm/arm.md:6187 |since r10-2840-g70cdb21e|since r10-2840-g70cdb21e Status|NEW |ASSIGNED --- Comment #5 from Bernd Edlinger --- fixed on trunk
[Bug testsuite/100467] [12 regression] g++.dg/debug/dwarf2/thunk1.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100467
Bernd Edlinger changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed||2021-05-07
--- Comment #1 from Bernd Edlinger ---
confirmed, I did not try to test with --target_board=unix/-m32
and the test case is unsupported on x86_64.
I'm not sure what to here,
the test case says
// Test that we don't add the x86 PC thunk to .debug_ranges
but my patch does emit a line number (if there is any) for thunks,
and of course include them in debug_ranges and debug_aranges,
so it is not possible to debug those functions where it was
previously not possible.
intersting that the LFB3 increase from 5 to 9 when I tried this:
diff --git a/gcc/testsuite/g++.dg/debug/dwarf2/thunk1.C
b/gcc/testsuite/g++.dg/d
index 304cf45..3d5f301 100644
--- a/gcc/testsuite/g++.dg/debug/dwarf2/thunk1.C
+++ b/gcc/testsuite/g++.dg/debug/dwarf2/thunk1.C
@@ -1,9 +1,9 @@
-// Test that we don't add the x86 PC thunk to .debug_ranges
+// Test that we do add the x86 PC thunk to .debug_ranges
// { dg-do compile { target { { i?86-*-* x86_64-*-* } && ia32 } } }
// { dg-require-effective-target fpic }
// { dg-skip-if "darwin doesn't use the thunk for PIC" { *-*-darwin* } }
// { dg-options "-g -fpic -fno-dwarf2-cfi-asm" }
-// { dg-final { scan-assembler-times "LFB3" 5 } }
+// { dg-final { scan-assembler-times "LFB3" 9 } }
template void f(T t) { }
[Bug testsuite/100467] [12 regression] g++.dg/debug/dwarf2/thunk1.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100467 --- Comment #2 from Bernd Edlinger --- > so it is not possible to debug those functions Aehm, i meant of course it is _now_ possible
[Bug testsuite/100467] [12 regression] g++.dg/debug/dwarf2/thunk1.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100467
--- Comment #3 from Bernd Edlinger ---
Okay, after some debugging I see the problem.
Usually thunks are emitted from ymtab-thunks.cc:
cfun->is_thunk = 1;
insn_locations_init ();
set_curr_insn_location (DECL_SOURCE_LOCATION (thunk_fndecl));
prologue_location = curr_insn_location ();
targetm.asm_out.output_mi_thunk (asm_out_file, thunk_fndecl,
fixed_offset, virtual_value, alias);
the only other place where prologue_location is set
is in cfgexpand.c:
if (!DECL_IS_UNDECLARED_BUILTIN (current_function_decl))
{
/* Eventually, all FEs should explicitly set function_start_locus. */
if (LOCATION_LOCUS (fun->function_start_locus) == UNKNOWN_LOCATION)
set_curr_insn_location
(DECL_SOURCE_LOCATION (current_function_decl));
else
set_curr_insn_location (fun->function_start_locus);
}
else
set_curr_insn_location (UNKNOWN_LOCATION);
prologue_location = curr_insn_location ();
BUT this special "thunk" is emitted from toplev.c:
/* This must be at the end before unwind and debug info.
Some target ports emit PIC setup thunks here. */
targetm.asm_out.code_end ();
and here the prologue_location is not initialized, also the backend
does not know about it's significance.
So the source line number for this thunk is indeed wrong.
[Bug middle-end/100467] [12 regression] g++.dg/debug/dwarf2/thunk1.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100467 --- Comment #4 from Bernd Edlinger --- Created attachment 50778 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50778&action=edit Proposed patch
[Bug middle-end/100467] [12 regression] g++.dg/debug/dwarf2/thunk1.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100467 --- Comment #5 from Bernd Edlinger --- Rainer, I would be happy if you could give this patch a try. Thanks Bernd.
[Bug middle-end/100467] [12 regression] g++.dg/debug/dwarf2/thunk1.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100467 Bernd Edlinger changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #7 from Bernd Edlinger --- should be fixed now. Thanks for reporting.
[Bug debug/100515] [12 Regression] ICE in output_rnglists, at dwarf2out.c:12294 since r12-574-ge69ac0203725fb8d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100515 --- Comment #4 from Bernd Edlinger --- Created attachment 50795 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50795&action=edit Proposed patch This is what I'm currently testing.
[Bug debug/100515] [12 Regression] ICE in output_rnglists, at dwarf2out.c:12294 since r12-574-ge69ac0203725fb8d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100515 Bernd Edlinger changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from Bernd Edlinger --- The ICE should be fixed now.
[Bug debug/100515] [12 Regression] ICE in output_rnglists, at dwarf2out.c:12294 since r12-574-ge69ac0203725fb8d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100515 --- Comment #7 from Bernd Edlinger --- Okay, while the ICE is fixed, there is something odd in the test case: foo._omp_fn.0: .LVL0: .LFB2: .cfi_startproc .file 1 "pr100515.c" .loc 1 10 5 view -0 ret .cfi_endproc .LFE2: .size foo._omp_fn.0, .-foo._omp_fn.0 .p2align 4 .type bar._omp_fn.0, @function bar._omp_fn.0: .LFB5: .cfi_startproc ret .cfi_endproc .LFE5: .size bar._omp_fn.0, .-bar._omp_fn.0 .p2align 4 .globl foo .type foo, @function foo._omp_fn.0 does have a correct .loc statement, while bar._omp_fn.0 does not have a .loc statement and therefore no debugging in bar is possible. This must be a pre-existing issue already there before r12-574-ge69ac0203725fb8d.
[Bug debug/101598] [debug, ada] .loc generated for defs__struct1IP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101598 Bernd Edlinger changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #10 from Bernd Edlinger --- fixed
[Bug debug/116470] [15 regression] Enabling -gvariable-location-views breaks Solaris/x86 bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116470 Bernd Edlinger changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #16 from Bernd Edlinger --- Thanks!
[Bug debug/116470] [15 regression] Enabling -gvariable-location-views breaks Solaris/x86 bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116470 --- Comment #17 from Bernd Edlinger --- (In reply to r...@cebitec.uni-bielefeld.de from comment #12) > (thanks), but on Solaris/sparc there's > > FAIL: gcc.dg/debug/dwarf2/inline7.c scan-assembler DW_AT_ranges > > both with as and gas. Hmm, looks like PR 116462 is not yet completely fixed...
[Bug other/116462] [15 regression] new test case gcc.dg/debug/dwarf2/inline7.c from r15-3083-gbcb33b1237042e fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116462 Bernd Edlinger changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #7 from Bernd Edlinger --- I've been informed that this test case does still fail on sparc: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116470#c12
[Bug other/116462] [15 regression] new test case gcc.dg/debug/dwarf2/inline7.c from r15-3083-gbcb33b1237042e fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116462 Bernd Edlinger changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #9 from Bernd Edlinger --- fixed
