Re: [PATCH 2/6] gimple-ssa-store-merging.c: fix sort_by_bitpos
On Sat, Jul 15, 2017 at 11:47:45PM +0300, Alexander Monakov wrote: > --- a/gcc/gimple-ssa-store-merging.c > +++ b/gcc/gimple-ssa-store-merging.c > @@ -516,12 +516,12 @@ sort_by_bitpos (const void *x, const void *y) >store_immediate_info *const *tmp = (store_immediate_info * const *) x; >store_immediate_info *const *tmp2 = (store_immediate_info * const *) y; > > - if ((*tmp)->bitpos <= (*tmp2)->bitpos) > + if ((*tmp)->bitpos < (*tmp2)->bitpos) > return -1; >else if ((*tmp)->bitpos > (*tmp2)->bitpos) > return 1; > - > - gcc_unreachable (); > + else > +return 0; > } Does any sort using this comparison function require the sort to be stable? It looks like the <= was simply a typo and should have been <, but the gcc_unreachable was as intended? (With <= it is trivially unreachable there). Segher
Re: [PATCH] toplev: avoid recursive emergency_dump_function
Hi! On Thu, Jul 20, 2017 at 05:40:28PM +0300, Alexander Monakov wrote: > Segher pointed out on IRC that ICE reporting with dumps enabled got worse: > if emergency_dump_function itself leads to an ICE (e.g. by segfaulting), > nested ICE reporting will invoke emergency_dump_function in exactly the > same context, but not only would we uselessly announce current pass again, > this time around the second SIGSEGV will just terminate cc1 because the > signal handler is unregistered (so we won't print the backtrace). Sorry > for not really considering the implications when submitting that patch. > > Solve this by substituting the callback for global_dc->internal_error; > this avoids invoking emergency_dump_function, and also gives a > convenient point to flush the dump file. OK to apply? Extra thanks for that last point, it's been driving me nuts :-) > * topvel.c (dumpfile.h): New include. s/topvel/toplev/ Segher
[PATCH, alpha]: libgo patch: also recognize alpha in signal handler
Similar patch to the one for PPC [1]. [1] https://gcc.gnu.org/ml/gcc-patches/2017-07/msg01334.html Tested on alphaev68-pc-linux-gnu. Uros. Index: libgo/runtime/go-signal.c === --- libgo/runtime/go-signal.c (revision 250443) +++ libgo/runtime/go-signal.c (working copy) @@ -215,6 +215,11 @@ ret.sigpc = ((ucontext_t*)(context))->uc_mcontext.gregs[REG_EIP]; #endif #endif +#ifdef __alpha__ + #ifdef __linux__ + ret.sigpc = ((ucontext_t*)(context))->uc_mcontext.sc_pc; + #endif +#endif #ifdef __PPC__ #ifdef __linux__ ret.sigpc = ((ucontext_t*)(context))->uc_mcontext.regs->nip;
Re: gotools patch committed: Test runtime, misc/cgo/{test,testcarchive}
> This patch to the gotools Makefile adds tests to `make check`. We now > test the runtime package using the newly built go tool, and test that > cgo works by running the misc/cgo/test and misc/cgo/testcarchive > tests. Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. > Committed to mainline. There is now only one remaining gotools testsuite failure on alpha: FAIL: TestBreakpoint crash_test.go:106: testprog Breakpoint exit status: exit status 2 crash_test.go:310: output: SIGTRAP: trace trap PC=2199039253124 m=0 sigcode=0 goroutine 1 [running]: goroutine 3 [runnable]: created by runtime.SetFinalizer /space/homedirs/uros/gcc-svn/trunk/libgo/go/runtime/mfinal.go:355 +1280 want output containing: runtime.Breakpoint I would like to debug this one failure only. Is there a way to run only one gotools test? Can you perhaps give a hint where to look in the source? Uros.
Re: [00/77] Add wrapper classes for machine_modes
Hi Richard, On Thu, Jul 13, 2017 at 09:35:44AM +0100, Richard Sandiford wrote: > This series is an update of: > > https://gcc.gnu.org/ml/gcc-patches/2016-12/msg00766.html > > It adds a group of wrapper classes around machine_mode for modes that > are known to belong to, or need to belong to, a particular mode_class. > For example, it adds a scalar_int_mode wrapper for MODE_INT and > MODE_PARTIAL_INT modes, a scalar_float_mode wrapper for MODE_FLOAT and > MODE_DECIMAL_FLOAT modes, and so on. So what does it change in the interfaces we use? I couldn't find an update of documentation, maybe I missed it (it's a huge series :-) ) An overview of the new interfaces (and how they are used) would help. >From what I can tell so far it makes things much harder to read. Perhaps that is just because this is all new. > I tested this by compiling the testsuite for: > > aarch64-linux-gnu alpha-linux-gnu arc-elf arm-linux-gnueabi > arm-linux-gnueabihf avr-elf bfin-elf c6x-elf cr16-elf cris-elf > epiphany-elf fr30-elf frv-linux-gnu ft32-elf h8300-elf > hppa64-hp-hpux11.23 ia64-linux-gnu i686-pc-linux-gnu > i686-apple-darwin iq2000-elf lm32-elf m32c-elf m32r-elf > m68k-linux-gnu mcore-elf microblaze-elf mips-linux-gnu > mipsisa64-linux-gnu mmix mn10300-elf moxie-rtems msp430-elf > nds32le-elf nios2-linux-gnu nvptx-none pdp11 powerpc-linux-gnuspe > powerpc-eabispe powerpc64-linux-gnu powerpc-ibm-aix7.0 riscv64-elf > rl78-elf rx-elf s390-linux-gnu s390x-linux-gnu sh-linux-gnu > sparc-linux-gnu sparc64-linux-gnu sparc-wrs-vxworks spu-elf > tilegx-elf tilepro-elf xstormy16-elf v850-elf vax-netbsdelf > visium-elf x86_64-darwin x86_64-linux-gnu xtensa-elf > > and checking that there were no changes in assembly. Also tested > in the normal way on aarch64-linux-gnu, powerc64-linux-gnu and > x86_64-linux-gnu. Could you also test powerpc64le-linux please? It is a primary platform. gcc112 is a nice fast machine. Segher
Re: Fix inconsistent section flags
One more patch needed for another edge condition. Joerg Index: src/external/gpl3/gcc/dist/gcc/varasm.c diff -u src/external/gpl3/gcc/dist/gcc/varasm.c:1.2 src/external/gpl3/gcc/dist/gcc/varasm.c:1.3 --- src/external/gpl3/gcc/dist/gcc/varasm.c:1.2 Mon Jul 17 19:53:10 2017 +++ src/external/gpl3/gcc/dist/gcc/varasm.c Sat Jul 22 20:52:52 2017 @@ -6428,7 +6428,8 @@ location. -fmerge-all-constants allows even that (at the expense of not conforming). */ ret = SECCAT_RODATA; - else if (TREE_CODE (DECL_INITIAL (decl)) == STRING_CST) + else if (DECL_INITIAL (decl) != NULL + && TREE_CODE (DECL_INITIAL (decl)) == STRING_CST) ret = SECCAT_RODATA_MERGE_STR_INIT; else ret = SECCAT_RODATA_MERGE_CONST;
[PATCH] dwarf2asm.c for AIX
dw2_asm_output_nstring() essentially inlines the version of
OUTPUT_ASCII for the GNU Assembler ELF file format for the debug_asm
case to append the comment and calls OUTPUT_ASCII when not debugging.
The DWARF portion of the GCC testsuite relies on the text that appears
in the comments, so it needs to work somewhat on AIX.
The function previously had been adjusted to emit the AIX assembler
.byte directive. The AIX assembler escapes double quotes with another
double quote, not a backslash. The AIX toolchain added support for
the debug_macinfo section and macros with quotes generate assembler
errors when debug_asm is enabled.
This patch adjusts the function to emit a double quote instead of a
backslash when XCOFF_DEBUGGING_INFO is defined for AIX.
Bootstrapped on powerpc-ibm-aix7.2.0.0
Okay?
Thanks, David
Index: dwarf2asm.c
===
--- dwarf2asm.c (revision 250453)
+++ dwarf2asm.c (working copy)
@@ -345,7 +345,9 @@ dw2_asm_output_nstring (const char *str, size_t or
for (i = 0; i < len; i++)
{
int c = str[i];
- if (c == '\"' || c == '\\')
+ if (c == '\"')
+ fputc (XCOFF_DEBUGGING_INFO ? '\"' : '\\', asm_out_file);
+ else if (c == '\\')
fputc ('\\', asm_out_file);
if (ISPRINT (c))
fputc (c, asm_out_file);
[PATCH] dwarf2out.c patch for AIX
Recent versions of the AIX toolchain now support the debug_macinfo
section. The section header of the macinfo_section includes a
reference to the debug lineptr. As with the earlier adjustment to the
debug line reference in the debug_info section, the debug_macinfo
section requires a similar adjustment.
The adjustment is necessary because the AIX assembler inserts the
debug line section length, which causes the GCC generated label for
the beginning of the section to point to the incorrect location
expected by debuggers, such as GDB.
This patch mirrors the earlier patch to copy debug_section_label into
dl_section_ref and append the adjustment when necessary. With this
patch, GDB is able to report correct macro information.
Bootstrapped on powerpc-ibm-aix7.2.0.0
Okay?
Thanks, David
* dwarf2out.c (output_macinfo): Copy debug_line_section_label
to dl_section_ref. On AIX, append an expression to subtract the size
of the section length to dl_section_ref.
Index: dwarf2out.c
===
--- dwarf2out.c (revision 250453)
+++ dwarf2out.c (working copy)
@@ -26975,6 +26975,7 @@ output_macinfo (void)
macinfo_entry *ref;
vec *files = NULL;
macinfo_hash_type *macinfo_htab = NULL;
+ char dl_section_ref[MAX_ARTIFICIAL_LABEL_BYTES];
if (! length)
return;
@@ -26985,6 +26986,12 @@ output_macinfo (void)
&& (int) DW_MACINFO_start_file == (int) DW_MACRO_start_file
&& (int) DW_MACINFO_end_file == (int) DW_MACRO_end_file);
+ /* AIX Assembler inserts the length, so adjust the reference to match the
+ offset expected by debuggers. */
+ strcpy (dl_section_ref, debug_line_section_label);
+ if (XCOFF_DEBUGGING_INFO)
+strcat (dl_section_ref, DWARF_INITIAL_LENGTH_SIZE_STR);
+
/* For .debug_macro emit the section header. */
if (!dwarf_strict || dwarf_version >= 5)
{
@@ -26995,7 +27002,7 @@ output_macinfo (void)
else
dw2_asm_output_data (1, 2, "Flags: 32-bit, lineptr present");
dw2_asm_output_offset (DWARF_OFFSET_SIZE,
- (!dwarf_split_debug_info ?
debug_line_section_label
+ (!dwarf_split_debug_info ? dl_section_ref
: debug_skeleton_line_section_label),
debug_line_section, NULL);
