Re: Copyright years for new old ports (Re: Ping^6: contribute Synopsys Designware ARC port)
On Wed, 2 Oct 2013, Joern Rennecke wrote: From my understanding, the condition for adding the current Copyright year without a source code change is to have a release in that year. Are we sure 4.9.0 will be released this year? release here includes availability of a development version in public version control, as well as snapshots and non-FSF releases. The effect is that if the first copyright year in a GCC source file is 1987 or later, a single range year-2013 can be used. -- Joseph S. Myers jos...@codesourcery.com
Re: Copyright years for new old ports (Re: Ping^6: contribute Synopsys Designware ARC port)
On 10/3/2013 5:10 PM, Joseph S. Myers wrote: On Wed, 2 Oct 2013, Joern Rennecke wrote: From my understanding, the condition for adding the current Copyright year without a source code change is to have a release in that year. Are we sure 4.9.0 will be released this year? release here includes availability of a development version in public version control, as well as snapshots and non-FSF releases. The effect is that if the first copyright year in a GCC source file is 1987 or later, a single range year-2013 can be used. Just as a FYI, for the GNAT front end we have always used year ranges, but we only update the year if we actually modify a file.
Re: Ping^6: contribute Synopsys Designware ARC port
On Tue, Oct 01, 2013 at 04:22:38PM -0600, Jeff Law wrote: - The Copyright years should be 2013 in every new file. Or has this port been released before? The port has been available via git for quite a while: https://github.com/foss-for-synopsys-dwc-arc-processors/gcc Right. Was any of this code from Doug Evans's old ARC support? It doesn't hurt to have 2013 in the dates, and I suspect most files will get touched as a result of addressing Diego's comments. Because GCC has switched to Copyright year ranges, in fact all the Copyright lines should be either 2013, or firstyear-2013. Jakub
Copyright years for new old ports (Re: Ping^6: contribute Synopsys Designware ARC port)
Quoting Jakub Jelinek ja...@redhat.com: On Tue, Oct 01, 2013 at 04:22:38PM -0600, Jeff Law wrote: - The Copyright years should be 2013 in every new file. Or has this port been released before? The port has been available via git for quite a while: https://github.com/foss-for-synopsys-dwc-arc-processors/gcc Right. Was any of this code from Doug Evans's old ARC support? I don't have version control information to confirm or deny this. At any rate, to my knowledge, the Copyright year of any predecessor files has been included. And the old port wouldn't fill in any gaps in the 2009-2012 time frame, as any copy - if it happened - would have been much earlier. I've filled in Copyright year gaps from internal ChangeLogs / revision control info (inasmuch as available to me) where indicated, but some files were just not much touched at all. It doesn't hurt to have 2013 in the dates, and I suspect most files will get touched as a result of addressing Diego's comments. I've added 2013 for the affected files that didn't already have that year in their list/range. From my understanding, the condition for adding the current Copyright year without a source code change is to have a release in that year. Are we sure 4.9.0 will be released this year? Because GCC has switched to Copyright year ranges, in fact all the Copyright lines should be either 2013, or firstyear-2013. The way I recall the argument is that the releases we make allow us to add a copyright year without a source code change, and because files on trunk are included in a release at least once a year, you can fill in a range for their stay within trunk. However, this port hasn't been in the FSF gcc trunk till now, so what we have at this moment are the lists of years when the code was prepared.
Re: Copyright years for new old ports (Re: Ping^6: contribute Synopsys Designware ARC port)
On Wed, Oct 02, 2013 at 06:05:14AM -0400, Joern Rennecke wrote: From my understanding, the condition for adding the current Copyright year without a source code change is to have a release in that year. Are we sure 4.9.0 will be released this year? We are sure we don't want 4.9.0 to be released this year ;) Because GCC has switched to Copyright year ranges, in fact all the Copyright lines should be either 2013, or firstyear-2013. The way I recall the argument is that the releases we make allow us to add a copyright year without a source code change, and because files on trunk are included in a release at least once a year, you can fill in a range for their stay within trunk. However, this port hasn't been in the FSF gcc trunk till now, so what we have at this moment are the lists of years when the code was prepared. But, all the other files in gcc/ are now someyear-2013, new files added are also 2013, if you make your files someyear-2011 or similar, then I think the scripts won't easily adjust it to someyear-2014 when we run the script early in January 2014. Jakub
Re: Copyright years for new old ports (Re: Ping^6: contribute Synopsys Designware ARC port)
Quoting Jakub Jelinek ja...@redhat.com: On Wed, Oct 02, 2013 at 06:05:14AM -0400, Joern Rennecke wrote: From my understanding, the condition for adding the current Copyright year without a source code change is to have a release in that year. Are we sure 4.9.0 will be released this year? We are sure we don't want 4.9.0 to be released this year ;) Because GCC has switched to Copyright year ranges, in fact all the Copyright lines should be either 2013, or firstyear-2013. The way I recall the argument is that the releases we make allow us to add a copyright year without a source code change, and because files on trunk are included in a release at least once a year, you can fill in a range for their stay within trunk. However, this port hasn't been in the FSF gcc trunk till now, so what we have at this moment are the lists of years when the code was prepared. But, all the other files in gcc/ are now someyear-2013, new files added are also 2013, if you make your files someyear-2011 or similar, then I think the scripts won't easily adjust it to someyear-2014 when we run the script early in January 2014. So, should I add 2014 now? That would be no more speculative than adding the current year at the start of the year in anticipation of a release that year. Or put something in my Calendar to do it in 2014? Or should I backport the port into the gcc 4.8 branch, so assuming we still make another 4.8.x release this year, there is justification to add the 2013 year?
Re: Copyright years for new old ports (Re: Ping^6: contribute Synopsys Designware ARC port)
On Wed, 2 Oct 2013, Joern Rennecke wrote: From my understanding, the condition for adding the current Copyright year without a source code change is to have a release in that year. Are we sure 4.9.0 will be released this year? We are sure we don't want 4.9.0 to be released this year ;) But(!) we'll be releasing another dozen of 4.9.0 snapshots this year. That probably was something the FSF had not considered when creating the original policy (recall how even GCC did not have a publicly accessible source code repository in the days). So, should I add 2014 now? That would be no more speculative than adding the current year at the start of the year in anticipation of a release that year. I would do add 2013. This is when the port has hit the tree and when we will be doing snapshots available via our and many other servers. Gerald
Re: Copyright years for new old ports (Re: Ping^6: contribute Synopsys Designware ARC port)
Quoting Gerald Pfeifer ger...@pfeifer.com: On Wed, 2 Oct 2013, Joern Rennecke wrote: From my understanding, the condition for adding the current Copyright year without a source code change is to have a release in that year. Are we sure 4.9.0 will be released this year? We are sure we don't want 4.9.0 to be released this year ;) But(!) we'll be releasing another dozen of 4.9.0 snapshots this year. That probably was something the FSF had not considered when creating the original policy (recall how even GCC did not have a publicly accessible source code repository in the days). So, should I add 2014 now? That would be no more speculative than adding the current year at the start of the year in anticipation of a release that year. I would do add 2013. This is when the port has hit the tree and when we will be doing snapshots available via our and many other servers. Ok, commited as revision 203110.
Re: Ping^6: contribute Synopsys Designware ARC port
On Sat, Sep 28, 2013 at 9:54 AM, Joern Rennecke joern.renne...@embecosm.com wrote: The main part of the port (everything but the testsuite) is still waiting for review: http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00323.html http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00324.html http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00325.html http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00328.html http://gcc.gnu.org/ml/gcc-patches/2013-09/msg01870.html http://gcc.gnu.org/ml/gcc-patches/2013-09/msg02070.html I've retested a i686-pc-linux-gnu native bootstrap as well as the obvious arc-elf32 / arc-linux-uclibc builds in trunk r202981. I have been reviewing these patches (I've gone through 2), and so far I find nothing surprising in them. I should be able to finish them today or tomorrow. Joern, I assume that you'll be one of the maintainers for the port? Anyone else? SC folks, could you appoint Joern (and any other volunteer that Joern suggests) as maintainers? Thanks. Diego.
Re: Ping^6: contribute Synopsys Designware ARC port
2013/10/1 Diego Novillo dnovi...@google.com: On Sat, Sep 28, 2013 at 9:54 AM, Joern Rennecke joern.renne...@embecosm.com wrote: The main part of the port (everything but the testsuite) is still waiting for review: I have been reviewing these patches (I've gone through 2), and so far I find nothing surprising in them. I should be able to finish them today or tomorrow. Joern, I assume that you'll be one of the maintainers for the port? Anyone else? SC folks, could you appoint Joern (and any other volunteer that Joern suggests) as maintainers? Thanks. Diego. It seems that Joern has been appointed as port maintainer earlier: http://gcc.gnu.org/ml/gcc/2013-01/msg00094.html And he also added himself in MAINTAINERS file already. :) Best regards, jasonwucj
Re: Ping^6: contribute Synopsys Designware ARC port
Quoting Diego Novillo dnovi...@google.com: I have been reviewing these patches (I've gone through 2), and so far I find nothing surprising in them. I should be able to finish them today or tomorrow. Joern, I assume that you'll be one of the maintainers for the port? Anyone else? Yes. Claudiu Zissulescu at Synopsys would in principle be available as co-maintainer, but I suppose it is customary to apply for write-after- approval status first. SC folks, could you appoint Joern (and any other volunteer that Joern suggests) as maintainers? I've already been appointed as maintainer back in January.
Re: Ping^6: contribute Synopsys Designware ARC port
On Tue, Oct 1, 2013 at 10:10 AM, Joern Rennecke joern.renne...@embecosm.com wrote: Yes. Claudiu Zissulescu at Synopsys would in principle be available as co-maintainer, but I suppose it is customary to apply for write-after- approval status first. I'm not sure. A question for the SC. SC folks, could you appoint Joern (and any other volunteer that Joern suggests) as maintainers? I've already been appointed as maintainer back in January. OK, great. Here's me paying attention :)
Re: Ping^6: contribute Synopsys Designware ARC port
On Sat, Sep 28, 2013 at 9:54 AM, Joern Rennecke
joern.renne...@embecosm.com wrote:
The main part of the port (everything but the testsuite) is still waiting
for review:
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00323.html
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00324.html
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00325.html
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00328.html
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg01870.html
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg02070.html
I have finished reading through these patches. They are OK to commit.
The changes indicated below are minor. Ideally, you'd address them
before committing the patch, but if it's easier to do it post-commit,
that's OK too.
- The Copyright years should be 2013 in every new file. Or has this
port been released before?
- In config/arc/arc-protos.h:
+/* insn-attrtab.c doesn't include reload.h, which declares
regno_clobbered_p. */
+extern int regno_clobbered_p (unsigned int, rtx, enum machine_mode, int);
Why not include reload.h here? Interface changes (however rare) make
this a hassle.
- In config/arc/simdext.md
+;; Va, [Ib,u8] instructions
+;; (define_insn vld32wh_insn
+;; [(set (match_operand:V8HI 0 vector_register_operand =v)
+;; (vec_concat:V8HI (unspec:V4HI [(match_operand:SI 1 immediate_operand P)
+;; (vec_select:HI (match_operand:V8HI 2 vector_register_operand v)
+;; (parallel [(match_operand:SI 3 immediate_operand L)]))]
UNSPEC_ARC_SIMD_VLD32WH)
+;; (vec_select:V4HI (match_dup 0)
Necessary? If so, please add a comment stating why it's commented out.
- In doc/extend.texi:
+Permissible values for this parameter are: @w{@code{ilink1}} and
+@w{@code{ilink2}}.
+
ARC developers already know what ilink1 and ilink2 mean?
+@cindex indirect calls on Epiphany
+These attribute specifies how a particular function is called on
+ARC, ARM and Epiphany
s/specifies/specify/
+because __alignof__ sees only the type of the dereference, wheras
+__builtin_arc_align uses alignment information from the pointer
s/wheras/whereas/
- I have not fully cross-referenced the list of documented builtins vs
the list of implemented builtins. Please double check them.
- Ditto the list of -m options. It looks like they're all documented,
but I haven't diff'd the doc vs the options file.
- In libgcc/config/arc/gmon/mcount.c
The file has a different copyright/license notice at the top. Is this
from a third party source? Can it be changed to lgpl?
+#if 0
+ if (catomic_compare_and_exchange_bool_acq (p-state, GMON_PROF_BUSY,
+ GMON_PROF_ON))
+ return;
Get rid of this?
+#elif defined (__ARC700__)
+/* ??? This could temporrarily loose the ERROR / OFF condition in a race,
s/temporrarily/temporarily/
s/loose/lose/
- Many files in libgcc/config/arc/... have #if0 blocks. Are they
really necessary?
- In libgcc/config/arc/ieee-754/arc600-dsp/muldf3.S
+/* We have checked for infinitey / NaN input before, and transformed
+ denormalized inputs into normalized inputs. Thus, the worst case
s/infinitey/infinity/
It also happens in another muldf3.S file in a sibling directory.
- libgcc/config/arc/t-arc-newlib does not contain the exception clause.
- In config/arc/arc.md there are several define patterns commented
out. Toss them out?
- In config/arc/arc.c:
No need to include stdio.h
No need to mark struct arc_frame_info with GTY. It contains no pointers.
In arc_expand_epilogue():
Get rid of fp_restored_p
if (1)
{
unsigned int pretend_size = cfun-machine-frame_info.pretend_size;
Just move everything out of the if()?
In output_shift(): Get rid of the #if 1s?
In arc_encode_section_info():
/* Symbols in the text segment can be accessed without indirecting via the
constant pool; it may take an extra binary operation, but this is still
faster than indirecting via memory. Don't do this when not optimizing,
since we won't be calculating al of the offsets necessary to do this
simplification. */
But that seems out of sync with the code. It never checks whether
optimizations are enabled.
Thanks. Diego.
Re: Ping^6: contribute Synopsys Designware ARC port
Quoting Diego Novillo dnovi...@google.com:
On Sat, Sep 28, 2013 at 9:54 AM, Joern Rennecke
joern.renne...@embecosm.com wrote:
The main part of the port (everything but the testsuite) is still waiting
for review:
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00323.html
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00324.html
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00325.html
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00328.html
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg01870.html
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg02070.html
I have finished reading through these patches. They are OK to commit.
The changes indicated below are minor. Ideally, you'd address them
before committing the patch, but if it's easier to do it post-commit,
that's OK too.
Oops, I've already started my commit-spree after discussion on IRC.
- The Copyright years should be 2013 in every new file. Or has this
port been released before?
The port has been available via git for quite a while:
https://github.com/foss-for-synopsys-dwc-arc-processors/gcc
I've also added earlier versions as a branches in the FSF gcc svn repo
in 2008 and 2009.
- In config/arc/arc-protos.h:
+/* insn-attrtab.c doesn't include reload.h, which declares
regno_clobbered_p. */
+extern int regno_clobbered_p (unsigned int, rtx, enum machine_mode, int);
Why not include reload.h here? Interface changes (however rare) make
this a hassle.
There was also a general rule against including headers in header files,
although that has been weakened in the interim. Not sure what the exact
position now is.
At any rate, things that didn't use to depend on reload.h would suddenly do.
Not sure if the automatic dependencies take care of adding all the
new dependencies, but at any rate, this constrains the build.
And all the requirements for reload.h would also have to be included.
Worst of all, a number of generator programs includes tm_p.h, so if any
of the include files that have to be included for the sake of reload.h
is generated, there'll be a circular dependency. AFAICT, insn-modes.h
is a current example. And it is intrinsically needed for the prototype
I want.
Finally, tricks like the #ifdef RTX_CODE in function.h backfire when
the order of includes gets modified by includes from tm_p.h .
I'd rather have to copy a prototype in response to a clear error message
once in a blue moon than constantly fight with weird breakages of the
build system.
I suppose a better way would be for the *.md file that causes a header
file dependency to somehow request the inclusion of the header file by
the generated file(s).
- In config/arc/simdext.md
+;; Va, [Ib,u8] instructions
+;; (define_insn vld32wh_insn
+;; [(set (match_operand:V8HI 0 vector_register_operand =v)
+;; (vec_concat:V8HI (unspec:V4HI [(match_operand:SI 1
immediate_operand P)
+;; (vec_select:HI (match_operand:V8HI 2 vector_register_operand v)
+;; (parallel [(match_operand:SI 3 immediate_operand L)]))]
UNSPEC_ARC_SIMD_VLD32WH)
+;; (vec_select:V4HI (match_dup 0)
Necessary? If so, please add a comment stating why it's commented out.
As you can see in svn, this was already commented out in arc-20081210-branch;
ISTR that this was just a pair of UNSPEC patterns that could be replaced with
then-new vector operations; but the exact history is lost with the ARC svn
repo. At any rate, the replacement patterns are clearly below, so I deleted
the old commented out patterns along with their unspec constants.
- In doc/extend.texi:
+Permissible values for this parameter are: @w{@code{ilink1}} and
+@w{@code{ilink2}}.
+
ARC developers already know what ilink1 and ilink2 mean?
The ones that have to program interrupts should, or they can read about
them in the architecture manual.
These are two link registers (for interrupt return addresses) associated
with specific interrupt levels.
+@cindex indirect calls on Epiphany
+These attribute specifies how a particular function is called on
+ARC, ARM and Epiphany
s/specifies/specify/
+because __alignof__ sees only the type of the dereference, wheras
+__builtin_arc_align uses alignment information from the pointer
s/wheras/whereas/
Fixed.
- I have not fully cross-referenced the list of documented builtins vs
the list of implemented builtins. Please double check them.
- Ditto the list of -m options. It looks like they're all documented,
but I haven't diff'd the doc vs the options file.
I think we already did this, but these things have a way of having forgotten
items and/or grow new inconsistencies... I'll try to remember ot check
again...
- In libgcc/config/arc/gmon/mcount.c
The file has a different copyright/license notice at the top. Is this
from a third party source?
Yes, it is from one of the newer BSD releases. Can't recall exactly which,
but as you can see, I took care to use a base that has the three-clause
license, so there should be no issue with license compatibility.
Can it be changed to lgpl?
GTY on simple struct (Was: Re: Ping^6: contribute Synopsys Designware ARC port)
Quoting Diego Novillo dnovi...@google.com: No need to mark struct arc_frame_info with GTY. It contains no pointers. That's not quite how it works. machine_function needs GTY. It uses arc_frame_info, hence arc_frame_info also needs GTY.
Re: Ping^6: contribute Synopsys Designware ARC port
On 10/01/13 15:26, Joern Rennecke wrote: I have finished reading through these patches. They are OK to commit. The changes indicated below are minor. Ideally, you'd address them before committing the patch, but if it's easier to do it post-commit, that's OK too. Oops, I've already started my commit-spree after discussion on IRC. No worries. Just address Diego's stuff now. - The Copyright years should be 2013 in every new file. Or has this port been released before? The port has been available via git for quite a while: https://github.com/foss-for-synopsys-dwc-arc-processors/gcc Right. Was any of this code from Doug Evans's old ARC support? It doesn't hurt to have 2013 in the dates, and I suspect most files will get touched as a result of addressing Diego's comments. Jeff
Re: GTY on simple struct (Was: Re: Ping^6: contribute Synopsys Designware ARC port)
On Tue, Oct 1, 2013 at 5:50 PM, Joern Rennecke joern.renne...@embecosm.com wrote: Quoting Diego Novillo dnovi...@google.com: No need to mark struct arc_frame_info with GTY. It contains no pointers. That's not quite how it works. machine_function needs GTY. It uses arc_frame_info, hence arc_frame_info also needs GTY. Gah, you're right. I missed that connection. Silly GC. Diego.
