Re: Legal paperwork for GCC contributions
On Sun, Nov 23, 2014 at 06:48:53PM -0500, Lawrence Velázquez wrote: > Hi, > > I recently contributed some fixes against GCC trunk, gcc-4_9-branch, and > gcc-4_8-branch for which I need the requisite legal paperwork. > > However, I'd like to backport these particular fixes to the MacPorts > Project's ports of Apple GCC 4.2 and LLVM-GCC 4.2, which are licensed > under "version 2, or (at your option) any later version" of the GPL. We > would like the software provided by these ports to remain > GPLv2-licensed. > > Given this, what would be the best way for me to handle copyright? If you are the only author of the stuff you want to backport, I believe you do not need to ask any permission from anyone. Donating your own work to a FSF project does not prevent you from contributing it to a different project, even under a different license (IIUC, for example the go front-end works this way too). Of course, you must not include anybody else's substantial piece in the backport. Martin
Re: Legal paperwork for GCC contributions
On 24 November 2014 at 10:58, Martin Jambor wrote: > On Sun, Nov 23, 2014 at 06:48:53PM -0500, Lawrence Velázquez wrote: >> Hi, >> >> I recently contributed some fixes against GCC trunk, gcc-4_9-branch, and >> gcc-4_8-branch for which I need the requisite legal paperwork. >> >> However, I'd like to backport these particular fixes to the MacPorts >> Project's ports of Apple GCC 4.2 and LLVM-GCC 4.2, which are licensed >> under "version 2, or (at your option) any later version" of the GPL. We >> would like the software provided by these ports to remain >> GPLv2-licensed. >> >> Given this, what would be the best way for me to handle copyright? > > If you are the only author of the stuff you want to backport, I > believe you do not need to ask any permission from anyone. Donating > your own work to a FSF project does not prevent you from contributing > it to a different project, even under a different license (IIUC, for > example the go front-end works this way too). Of course, you must not > include anybody else's substantial piece in the backport. It doesn't prevent you from doing it, but you should give the FSF notice beforehand (i.e. before the other usage, unless that has already happened) that you intend to use your code in another project under a different license. Otherwise, the FSF would have no sure way to tell valid re-use of own code by the author from Copyright/left infringement (AKA GPL violations). IIRC, there is a passus in the Copyright assignment form that spells out what you should do.
RE: Optimized Allocation of Argument registers
All: The optimization of reducing save and restore of the callee and caller saved register has been the attention Of increasing the performance of the benchmark. The callee saved registers is saved at the entry and restore at the exit of the procedure if the register is reused inside the procedure whereas the caller save registers at the Caller site is saved before the call and the restore after the variable is live and spans through the call. The GCC port has done some optimization whereas the call-used registers are live inside the procedure and has been set as 1 bit then it will not be saved and restored. This is based on the data flow analysis. The callee saved registers is useful when there all multiple calls in the call graph whereas the caller save registers are useful if the call is the leaf procedure then the saving before the call and restore after the call will be useful and increases the performance. By traversing the call graph in depth-first-order and the bottom-up approach we can propagate the save and restore At the procedure entry and exit to the upper regions of the call graph which reduces the save and restore at all the lower Regions across the various lower calls. These decision can be made based on the frequency of the call in the call graph as Proposed by Fred Chow. Another approach to reducing the save and restore at the procedure entry and exit is moving the save and restore from The procedure entry to the active regions where the variable is Live inside the procedure based on the data flow analysis And thus improve the performance of many benchmarks as proposed by Fred Chow. The propagation of save and restore from the lower regions of the call graph to the upper regions is not implemented in The GCC framework and also the moving the save and restore to the active region of Liveness inside the procedure from The entry and exit is not implemented inside the GCC framework. Can this be proposed and implemented in GCC framework? For the open procedure whereas the indirect calls, recursive calls and the external linkage calls cannot be optimized and in The open case the save and restore at the entry and exit of the procedure is applied. But for the open procedure if all the Lower calls in the call-graph is closed and resolved through call-graph, the save and restore can be propagate to the upper Region in the open procedures from the lower region of the calls which are closed and resolved. This can also improve the Performance of many benchmarks and can this be proposed and implemented in GCC framework? Let me know what do you think. Thanks & Regards Ajit -Original Message- From: Ajit Kumar Agarwal Sent: Tuesday, November 18, 2014 7:01 PM To: 'Vladimir Makarov'; gcc Mailing List Cc: Vinod Kathail; Shail Aditya Gupta; Vidhumouli Hunsigida; Nagaraju Mekala Subject: RE: Optimized Allocation of Argument registers -Original Message- From: Vladimir Makarov [mailto:vmaka...@redhat.com] Sent: Tuesday, November 18, 2014 1:57 AM To: Ajit Kumar Agarwal; gcc Mailing List Cc: Vinod Kathail; Shail Aditya Gupta; Vidhumouli Hunsigida; Nagaraju Mekala Subject: Re: Optimized Allocation of Argument registers On 2014-11-17 8:13 AM, Ajit Kumar Agarwal wrote: > Hello All: > > I was looking at the optimized usage and allocation to argument registers. > There are two aspects to it as follows. > > 1. We need to specify the argument registers as followed by ABI in the target > specific code. Based on the function > argument registers defined in the target dependent code the function > argument registers are passed. If the > number of argument registers defined in the Architecture is large say 6/8 > function argument registers. > Most of the time in the benchmarks we don't pass so many arguments and the > number of arguments passed > is quite less. Since we reserve the function arguments as specified > in the target specific code for the given architecture, leads to unoptimized > usage as this function argument registers will not be used in the function. > Thus we need to steal some of the arguments registers and have the > usage of those in the function depending on the support of the number of > function argument registers. The stealing of function argument registers will > lead more number of registers available that are to be used in the function > and leading to less spill and fetch. > >>The argument registers should be not reserved. They should be present in RTL >>and RA allocator will figure out itself when it can use them. >>That is how other ports work. Thanks Vladimir for Clarifications. > 2. The other aspect of the function argument registers is not spill > and fetch the argument registers as they are live across the function > call. But the liveness is limited to certain point of the called > function after that point the function argument registers are not live > and can be used inside the called function. Oth
Re: Optimized Allocation of Argument registers
Ajit, Please check it out the -fshrink-wrap option. ~Umesh On Mon, Nov 24, 2014 at 5:17 PM, Ajit Kumar Agarwal wrote: > All: > > The optimization of reducing save and restore of the callee and caller saved > register has been the attention Of > increasing the performance of the benchmark. The callee saved registers is > saved at the entry and restore at the > exit of the procedure if the register is reused inside the procedure whereas > the caller save registers at the Caller site > is saved before the call and the restore after the variable is live and spans > through the call. > > The GCC port has done some optimization whereas the call-used registers are > live inside the procedure and has been > set as 1 bit then it will not be saved and restored. This is based on the > data flow analysis. > > The callee saved registers is useful when there all multiple calls in the > call graph whereas the caller save registers are > useful if the call is the leaf procedure then the saving before the call and > restore after the call will be useful and increases > the performance. > > By traversing the call graph in depth-first-order and the bottom-up approach > we can propagate the save and restore > At the procedure entry and exit to the upper regions of the call graph which > reduces the save and restore at all the lower > Regions across the various lower calls. These decision can be made based on > the frequency of the call in the call graph as > Proposed by Fred Chow. > > Another approach to reducing the save and restore at the procedure entry and > exit is moving the save and restore from > The procedure entry to the active regions where the variable is Live inside > the procedure based on the data flow analysis > And thus improve the performance of many benchmarks as proposed by Fred Chow. > > The propagation of save and restore from the lower regions of the call graph > to the upper regions is not implemented in > The GCC framework and also the moving the save and restore to the active > region of Liveness inside the procedure from > The entry and exit is not implemented inside the GCC framework. Can this be > proposed and implemented in GCC framework? > > For the open procedure whereas the indirect calls, recursive calls and the > external linkage calls cannot be optimized and in > The open case the save and restore at the entry and exit of the procedure is > applied. But for the open procedure if all the > Lower calls in the call-graph is closed and resolved through call-graph, the > save and restore can be propagate to the upper > Region in the open procedures from the lower region of the calls which are > closed and resolved. This can also improve the > Performance of many benchmarks and can this be proposed and implemented in > GCC framework? > > Let me know what do you think. > > Thanks & Regards > Ajit > > -Original Message- > From: Ajit Kumar Agarwal > Sent: Tuesday, November 18, 2014 7:01 PM > To: 'Vladimir Makarov'; gcc Mailing List > Cc: Vinod Kathail; Shail Aditya Gupta; Vidhumouli Hunsigida; Nagaraju Mekala > Subject: RE: Optimized Allocation of Argument registers > > > > -Original Message- > From: Vladimir Makarov [mailto:vmaka...@redhat.com] > Sent: Tuesday, November 18, 2014 1:57 AM > To: Ajit Kumar Agarwal; gcc Mailing List > Cc: Vinod Kathail; Shail Aditya Gupta; Vidhumouli Hunsigida; Nagaraju Mekala > Subject: Re: Optimized Allocation of Argument registers > > On 2014-11-17 8:13 AM, Ajit Kumar Agarwal wrote: >> Hello All: >> >> I was looking at the optimized usage and allocation to argument registers. >> There are two aspects to it as follows. >> >> 1. We need to specify the argument registers as followed by ABI in the >> target specific code. Based on the function >> argument registers defined in the target dependent code the function >> argument registers are passed. If the >> number of argument registers defined in the Architecture is large say 6/8 >> function argument registers. >> Most of the time in the benchmarks we don't pass so many arguments and the >> number of arguments passed >> is quite less. Since we reserve the function arguments as specified >> in the target specific code for the given architecture, leads to unoptimized >> usage as this function argument registers will not be used in the function. >> Thus we need to steal some of the arguments registers and have the >> usage of those in the function depending on the support of the number of >> function argument registers. The stealing of function argument registers will >> lead more number of registers available that are to be used in the >> function and leading to less spill and fetch. >> > >>>The argument registers should be not reserved. They should be present in >>>RTL and RA allocator will figure out itself when it can use them. >>>That is how other ports work. > > Thanks Vladimir for Clarifications. > >> 2. The other aspect of the function argument register
Re: GCC 5 fallout: libdata/pkgconfig/libgcj-5.0.pc
On Saturday 2014-08-23 12:38, Gerald Pfeifer wrote: > Packaging last week's GCC 5 snapshot, I ran into a couple of issues > due to the version number change. > > One is this: We are still creating libdata/pkgconfig/libgcj-5.0.pc > as we used to create libgcj-4.10.pc. > > Shouldn't that be libgcj-5.pc now? Ping. If it was 4.10 before, should it really not be just 5 now? Gerald
Re: GCC 5 fallout: libdata/pkgconfig/libgcj-5.0.pc
On 11/24/14 09:00, Gerald Pfeifer wrote: On Saturday 2014-08-23 12:38, Gerald Pfeifer wrote: Packaging last week's GCC 5 snapshot, I ran into a couple of issues due to the version number change. One is this: We are still creating libdata/pkgconfig/libgcj-5.0.pc as we used to create libgcj-4.10.pc. Shouldn't that be libgcj-5.pc now? Ping. If it was 4.10 before, should it really not be just 5 now? Yes. I wasn't even aware that we had a libgcj-.pc I guess I ought to eliminate my objection to bringing in pkg-config dependencies into the JIT with that new knowledge. Though in the case of libgcj we just install the file and don't, as far as I can tell, actually depend on pkg-config. jeff
Pushing recent libtool fix to binutils-gdb and newlib/libgloss
*ping*
Didn’t get any response to my question so far…
>> Thanks everyone for the comments and review.
>> Committed as r217366
>
> I cannot push the change to binutils-gdb as I don’t have write access there.
> Also, Joseph Myers said I needed to commit to newlib/libgloss, but their
> webpage only mentions read-only CVS.
>
> Could someone do it for me?
>
> Thanks,
> FX
>
>
>
>
> commit 8d25b840ce688bfa601b0ad5f53c4185627c8975
> Author: FX
> Date: Wed Nov 12 13:26:06 2014 +0100
>
>* libtool.m4: Fix globbing of darwin versions.
>
> diff --git a/ChangeLog b/ChangeLog
> index 32b3c15..5ed8242 100644
> --- a/ChangeLog
> +++ b/ChangeLog
> @@ -1,3 +1,7 @@
> +2014-11-12 Francois-Xavier Coudert
> +
> + * libtool.m4: Fix globbing of darwin versions.
> +
> 2014-10-15 Tristan Gingold
>
>* src-release.sh (do_proto_toplev): Configure with --target.
> diff --git a/libtool.m4 b/libtool.m4
> index 797468f..c96d80c 100644
> --- a/libtool.m4
> +++ b/libtool.m4
> @@ -1006,7 +1006,7 @@ _LT_EOF
> case ${MACOSX_DEPLOYMENT_TARGET-10.0},$host in
>10.0,*86*-darwin8*|10.0,*-darwin[[91]]*)
> _lt_dar_allow_undefined='${wl}-undefined ${wl}dynamic_lookup' ;;
> - 10.[[012]]*)
> + 10.[[012]][[,.]]*)
> _lt_dar_allow_undefined='${wl}-flat_namespace ${wl}-undefined
> ${wl}sup
>10.*)
> _lt_dar_allow_undefined='${wl}-undefined ${wl}dynamic_lookup' ;;
>
Re: Pushing recent libtool fix to binutils-gdb and newlib/libgloss
Done:
https://sourceware.org/ml/binutils/2014-11/msg00318.html
On Mon, Nov 24, 2014 at 9:04 AM, FX wrote:
> *ping*
>
> Didn’t get any response to my question so far…
>
>
>>> Thanks everyone for the comments and review.
>>> Committed as r217366
>>
>> I cannot push the change to binutils-gdb as I don’t have write access there.
>> Also, Joseph Myers said I needed to commit to newlib/libgloss, but their
>> webpage only mentions read-only CVS.
>>
>> Could someone do it for me?
>>
>> Thanks,
>> FX
>>
>>
>>
>>
>> commit 8d25b840ce688bfa601b0ad5f53c4185627c8975
>> Author: FX
>> Date: Wed Nov 12 13:26:06 2014 +0100
>>
>>* libtool.m4: Fix globbing of darwin versions.
>>
>> diff --git a/ChangeLog b/ChangeLog
>> index 32b3c15..5ed8242 100644
>> --- a/ChangeLog
>> +++ b/ChangeLog
>> @@ -1,3 +1,7 @@
>> +2014-11-12 Francois-Xavier Coudert
>> +
>> + * libtool.m4: Fix globbing of darwin versions.
>> +
>> 2014-10-15 Tristan Gingold
>>
>>* src-release.sh (do_proto_toplev): Configure with --target.
>> diff --git a/libtool.m4 b/libtool.m4
>> index 797468f..c96d80c 100644
>> --- a/libtool.m4
>> +++ b/libtool.m4
>> @@ -1006,7 +1006,7 @@ _LT_EOF
>> case ${MACOSX_DEPLOYMENT_TARGET-10.0},$host in
>>10.0,*86*-darwin8*|10.0,*-darwin[[91]]*)
>> _lt_dar_allow_undefined='${wl}-undefined ${wl}dynamic_lookup' ;;
>> - 10.[[012]]*)
>> + 10.[[012]][[,.]]*)
>> _lt_dar_allow_undefined='${wl}-flat_namespace ${wl}-undefined
>> ${wl}sup
>>10.*)
>> _lt_dar_allow_undefined='${wl}-undefined ${wl}dynamic_lookup' ;;
>>
>
--
H.J.
Re: Pushing recent libtool fix to binutils-gdb and newlib/libgloss
> Done: > https://sourceware.org/ml/binutils/2014-11/msg00318.html Thanks!
