src/external/mit/xorg/lib/libxcb/xkb.
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=231599
PR debug/67355
* var-tracking.c (reverse_op): Don't add dummy zero to reverse
ops that simplify back to the original value.
* alias.c (refs_newer_value_p): Cut off recursion for
expressions containing the original value.
_GNU_SOURCE to be defined for systems that need it (like glibc ones.)
be sure to find the right config.h for host programs.
these fixes combined make builds on debian 7 complete for me.
- earmv4 works (atf has one new failure, that seems common)
- mipsel run
- sparc runs
- sparc64 mostly works in UP mode
- add list of actual machines tested on
For several years I've been eager to find the time to fix the bugs
in C++ exceptions on VAX to get them working on NetBSD, because
theyâve been broken for many years and it looked like only a few
changes were needed to get them working. Without C++ exceptions,
the NetBSD test suite canât be run. The good news is that I was
able to fix all the bugs in the VAX machine description to make
C++ exceptions work in GCC 4.8.5 (version unimportant). I wrote a
blog post explaining the bugs, with patches:
Here's a short summary, with the diffs in text form at the end of this email.
1) Replace #define FRAME_POINTER_CFA_OFFSET(FNDECL) 0 with #define
ARG_POINTER_CFA_OFFSET(FNDECL) 0 in gcc/config/vax/elf.h and
gcc/config/vax/vax.h. This changes the definition of __builtin_dwarf_cfa()
to return %ap instead of %fp, which correctly points to CFA.
Previously, the stack unwinder was crashing in _Unwind_RaiseException()
trying to follow bad pointers from the initial CFA.
2) Define EH_RETURN_DATA_REGNO(N) to include only R2 and R3 (instead
of R2-R5) and add code to vax_expand_prologue() in gcc/config/vax/vax.c
to add R2-R3 to the procedure entry mask but only if crtl->calls_eh_return
is set. This fixes a crash when the stack unwinder tried to write
values to R2 and R3 in the previous stack frame via
__builtin_eh_return_data_regno (0) and __builtin_eh_return_data_regno (1).
3) Removed definitions of EH_RETURN_STACKADJ_RTX and STARTING_FRAME_OFFSET
from gcc/config/vax/elf.h. It's not necessary to remember the stack
adjustment or to waste four bytes on every stack frame for a value
that's not needed. Also remove the suspicious changes in
gcc/config/vax/vax.md to the definitions of call_pop and call_value
regarding DW_CFA_GNU_args_size and EH unwinding. I reverted to the
previous versions from an older version of GCC, adding a few useful
comments that had been removed.
4) The last bug is the one I understand the least. I'm hoping
someone reading this can implement a correct fix. What I was seeing
after making all the previous changes to fix the other bugs is that
my test program failed to catch any exceptions, but instead returned
normally to the original return path.
Investigation revealed that GCC was correctly generating the
necessary move instruction to copy the second parameter passed to
__builtin_eh_return() into the return address, because
EH_RETURN_HANDLER_RTX had been defined correctly in config/vax/elf.h.
Hereâs what the call looks like in gcc/except.c:
#ifdef EH_RETURN_HANDLER_RTX
rtx insn = emit_move_insn (EH_RETURN_HANDLER_RTX, crtl->eh.ehr_handler);
#else
error ("__builtin_eh_return not supported on this target");
#endif
The problem was that the optimizer is deleting the final move
instruction when I compile with -O or higher. The assembly code at
-O0 (no optimization) generated for the __builtin_eh_return() call
at the end of _Unwind_RaiseException() looked like:
calls $2,_Unwind_DebugHook
movl -12(%fp),%r1
movl %r1,16(%fp)
ret
.cfi_endproc
But then when I compiled with -O1 or -O2, all I saw was:
calls $2,_Unwind_DebugHook
ret
.cfi_endproc
This was a mystery for me and I donât know enough about how the
final peephole optimizer works to really track down why it thinks
it can remove the move call to store the previous return address.
My workaround was to add a call to RTX_FRAME_RELATED_P (insn) = 1;
after the emit_move_insn() in gcc/except.c, which was used in
vax_expand_prologue() to mark the procedure entry mask.
By making this change, the optimizer no longer removes the call to
write the value to the previous stack pointer, but it adds an extra
line of .cfi exception info, which seems unnecessary since the code
is immediately going to return from the call and any adjustment
made by the DWARF stack unwinder will already have been done. Hereâs
what the optimized code looks like with the patch (%r6 had been
loaded earlier):
calls $2,_Unwind_DebugHook
movl %r6,16(%fp)
.cfi_offset 6, -36
ret
.cfi_endproc
With that final change, C++ exception handling now finally works
on NetBSD/vax, and I was able to successfully run the vast majority
of the tests in the ATF testsuite, which had been completely
inaccessible when I started due to both atf-run and atf-report
immediately dumping core due to the bad pointers that I fixed. Now
I have a bunch of new bugs to track down fixes for, but I think
this was the hardest set of problems that needed to be solved to
bring NetBSD on VAX up to the level of the other NetBSD ports.
Here are the diffs I have so far. They should apply to any recent
version of GCC (tested on GCC 4.8.5). With the exception of the
hack to gcc/except.c, the other diffs are ready to submit to NetBSD
as well as to upstream GCC. The fix Iâd like to see for the final
problem I discovered of the emit_move_insn() being deleted by the
optimizer would be another patch to one of the files in the
gcc/config/vax directory to explain to the optimizer that writing
to 16(%fp) is important and not something to be deleted from the
epilogue (perhaps it thinks itâs writing to a local variable in
the frame that's about to be destroyed?).
I didn't see any indication that any other GCC ports required
anything special to tell the optimizer not to delete the move
instruction to EH_RETURN_HANDLER_RTX, so the other suspicion I have
is that there may be a bug specific to VAX's peephole optimizer or
related functions. Any ideas?
/usr/src/lib/csu/common/crt0-common.c: In function '___start':
/usr/src/lib/csu/common/crt0-common.c:184:1: internal compiler error: in dwf_regno, at dwarf2cfi.c:988
}
^
- explain the columns
- update arm status:
- MKCOMPAT problems with oabi
- coldfire builds as much as GCC 4.8
- sun2, m68k builds
- most mips builds now (mips64 has generic build issues)
- update sparc64 and ppc problems (sshd)
- there is something very very odd in linking libldap.so.4.3 where
using the GCC 4.8 compiler to link the GCC 5.3 compiled objects
works, or using GCC 5.3 compiler to link the 4.8 compiled objects
fails -- ie, the compiler output seems fine, but the interactions
between GCC and ld(1) are broken.
- add or1k, riscv*, ia64 and ppc64 columns:
- or1k and riscv* both fail, they need to have their support
ported to GCC 5.x (i understand that at least one of them
has a GCC 5.x tree.)
- expand the list of actually tested to complete "build.sh release"
to include machines, not just cpus.
- sshd problem is libldap.so.4.3, at least on sparc64. placing with 4.8 one works
- alpha mostly works fine, 7 new failures in atf, plus sshd problem
- update release build info for many *earm*, hppa, i386, amd64, mipsel, sh3*
- *mips* now at least completes mknative-gcc
- sh3eb has a mknative-gcc problem
since they want it now.
XXX: super ugly, probably can be fixed by rearranging a bunch of what
XXX: is currently in ../usr.bin/backend/ that builds insn-modes.h.
- handle wide-int{,-print}.cc with a hack
- clean up CLEANFILES
- build gengtype{-lex,-parse,-state,}.c properly
- build genmatch and its outputs
- build pass-instances.def
