Copyright assignment forms
Hello, Could someone please send me the copyright assignment forms for single contributions and for all future contributions? Cheers, -- PMatos
Re: Copyright assignment forms
Hi, Here the links about that: http://gcc.gnu.org/wiki/CopyrightAssignment -- Patrick On 08/02/2012 09:14 AM, Paulo J. Matos wrote: Hello, Could someone please send me the copyright assignment forms for single contributions and for all future contributions? Cheers,
Re: Copyright assignment forms
On 02/08/12 14:31, Patrick Marlier wrote: Hi, Here the links about that: http://gcc.gnu.org/wiki/CopyrightAssignment Thanks, I just sent the request to the list because the GCC webpage http://gcc.gnu.org/contribute.html request you to contact the list to obtain the forms: "See some documentation by the FSF for details and contact us (either via the gcc@gcc.gnu.org list or the GCC maintainer that is taking care of your contributions) to obtain the relevant forms. The most common forms are an assignment for a specific change, an assignment for all future changes, and an employer disclaimer, if an employer or school owns work created by the developer. " Cheers, Paulo -- Patrick On 08/02/2012 09:14 AM, Paulo J. Matos wrote: Hello, Could someone please send me the copyright assignment forms for single contributions and for all future contributions? Cheers, -- PMatos
Re: Copyright assignment forms
On Thu, Aug 2, 2012 at 6:14 AM, Paulo J. Matos wrote: > > Could someone please send me the copyright assignment forms for single > contributions and for all future contributions? Sent off-list. (FYI for others: we generally send off-list because there are several forms, and us sending the form makes it more likely that the contributor will fill out the right one.) Ian
x86_64 unwinder in libgcc_s
Hello! I got strange problem in LuaJIT [1] stack unwinding on Solaris x64. If I build everything using GCC with unwinder from libgcc_s everything works fine. But when I try to use GCC-built libluajit.a in executable built using Sun Studio 12.2 with standard solaris unwinder from libc I got a crash. As it turned out this is due to invalid value that _Unwind_GetCFA() function returned (called from Lua personality routine) E.g. in core I can see the following stack: [1] err_unwind(0x71255e31, 0x6e0bd80, 0x0, 0x6e0bd80, 0x6e0b5d0, 0x7124bbb5), at 0x7124b875 [2] lj_err_unwind_dwarf(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x7124bc25 [3] _Unwind_RaiseException_Body(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfd7ffaae0bfc [4] _SUNW_Unwind_RaiseException(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfd7ffaae0de9 [5] err_raise_ext(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x7124be2c [6] lj_err_throw(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x7124be89 [7] lj_trace_err_info(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x7129b8d8 [8] lj_record_ins(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x7127f0ec [9] trace_state(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x7129d7cd [10] lj_vm_cpcall(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x712473ba [11] lj_trace_ins(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x7129db8d [12] lj_dispatch_ins(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x71255e31 [13] lj_vm_inshook(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x71248a41 [14] lua_pcall(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x7125a584 ... lj_err_unwind_dwarf() is personality routine for lj_vm_cpcall() (frame 10) so it's called to process its stack frame. x86_64 psABI says that _Unwind_GetCFA() "returns the 64-bit Canonical Frame Address which is defined as the value of %rsp at the call site in the previous frame." (6.2.5 Context Management) So if I understand this correctly *(CFA - 8) should contain address somewhere inside lj_vm_cpcall() caller, i.e. in lj_trace_ins() (frame 11). And when using Solaris std unwinder it's in fact true, but it crashes. When using GCC unwinder return address is somewhere inside lj_vm_cpcall() itself, i.e. AFAIU CFA for trace_state() (frame 9) is returned instead, but it works. I can make std unwinder work by adjusting returned CFA to point to next frame by subtracting 80 bytes from it but it's interesting to understand why this happens. Am I missing something and GCC unwinder is right? TIA [1] http://luajit.org/
Re: PR53914, rs6000 constraints and reload queries
On Aug 1, 2012, at 16:04 , Ulrich Weigand wrote: > I've been wondering about mode_dependent_address_p myself. It currently > appears to cover two quite separate questions: > > - If I have a valid address, will it remain valid if I change its mode to > something else? > > - If I have a valid address, and change it mode (resulting in another > valid address), will the two address expressions have different > "meanings" or side effects? (E.g. an auto-increment address where > the increment depends on the mode size.) > > It seems to me that the first of those questions is rather redundant. > Instead of speculating whether the address would remain valid if the > mode were changed, code should IMO rather simply just change the > address and then check its validity in the usual way (legitimate > address etc.). Only the second question really provides any actual > *new* information ... > > See also the reload patch I recently posted to get rid of some uses > of offsettable_memref_p in favor of simply doing the change and testing > its validity afterwards: > http://gcc.gnu.org/ml/gcc-patches/2012-07/msg01421.html I think I see and need to give this further thought ... Thanks for your feedback :-) Cheers, Olivier
Merging the cxx-conversion branch into trunk
We are about ready to have the cxx-conversion branch merged back into trunk. This merge will change the following: 1- The compiler can only be built with a C++ compiler. 2- The tree macros can be called from gdb (when GCC is built with -g3). 3- htab and VEC have been converted to use C++ templates. The existing API is still present as wrappers that call the new API. We will change this after the branch is merged. 4- gengtype is now capable of supporting user-defined structure markers. This allows users to have structures in GC memory for which gengtype does not know how to generate marking code for. I am currently debugging this change. After I fix the remaining PCH failures, I will send the patch for review. Our immediate plan after we merge the branch into trunk includes: - Fix any failures caused by the change. - Modifying all the user code for VEC and htab to use the new interfaces. - Convert double_int. - Convert cgraph. - Convert the pass manager. - Convert hooks. After this round of changes, we are planning to work on more API cleanups (e.g., adding the introspection API that would be usable for plugins as we discussed in the Plugins BoF in Prague). I would also like to reduce the amount of code that is being generated by gengtype. There is a lot of boilerplate code that could be offloaded to user-provided functions. This would reduce the number of GTY markings that we need to support. There are other aspects of this that I will include in the gengtype patch that I'm finishing up. We will keep the branch alive to work on bigger scale changes that will not be ready for this release (e.g., experimenting with gimple and tree). I will split up the merge patch in 4 or 5 chunks to simplify reviews. For now, we would appreciate if folks test the branch with: $ svn co ssh://gcc.gnu.org/svn/gcc/branches/cxx-conversion $ mkdir bld && cd bld $ ../cxx-conversion/configure --enable-languages=all,ada,go && make bootstrap && make check We welcome any suggestions (and volunteers!) Thanks.
