This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH fortran] Use fold_build everywhere


FX Coudert wrote:
Attached is an updated version of the patch which also modifies the copyright years of the touched files and which fixes a typo I made when I tried to fix formatting in the diff.

My understanding was that the copyright years in the files need to include year X iff a release of the codebase is done in year X, independently of whether the file was actually modified or not. From http://www.gnu.org/prep/maintain/html_node/Copyright-Notices.html:
To update the list of year numbers, add each year in which you have made nontrivial changes to the package. (Here we assume you're using a publicly accessible revision control server, so that every revision installed is also immediately and automatically published.) When you add the new year, it is not required to keep track which files have seen significant changes in the new year and which have not. It is recommended and simpler to add the new year to all files in the package, and be done with it for the rest of the year.

Well, that doesn't make wrong what I did :-) Certainly it's better than not updating the numbers at all. I will take care of the rest later today.



Other than that, the patch is OK. To satisfy my curiosity: I sometimes used buildN() instead of fold_buildN() when I know that the expression can't be simplified, to avoid extra burden on the middle-end, was that wrong or is it just that the benefit is too small to notice?

Last I checked the optimizers eat practically all the time in a compilation, so it's not important time-wise. Note that (at least according to my understanding) fold_* would more appropriately be called canonicalize_*, i.e. not only does it fold trees with constant arguments, it also puts trees into standard forms by replacing expressions with equivalent ones (say, something like (!a && !b) -> !(a || b)). Therefore, folding may have benefits even for non-constant arguments.


Thanks,
- Tobi


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]