* Mike Stump <mikest...@comcast.net> [2017-01-17 10:49:30 -0800]: > On Jan 17, 2017, at 3:30 AM, Andrew Burgess <andrew.burg...@embecosm.com> > wrote: > > > >> This patch revamps the arc's header file by means of using separate > >> headers for different tool targets. Each target header file holds the > >> specific compiler backend macros definitions. Thus, we have: > >> - elf.h is used for bare metal type of toolchains. > >> - linux.h is used by our Linux type of toolchains. > >> - big.h is used by big-endians toolchains. > >> > >> This patch also cleans up arc specifics from config.gcc, consolidating > >> everything in one of the above new header files. > >> > >> OK to apply? > > > > I'm happy with this change, but I don't think it can be applied until > > GCC is back in to Stage 1, right? > > Ports have more latitude to check things into gcc into stage 2+ and more > latitude to check things into release branches. The patch set strikes me as > something not unreasonable to drop into trunk if you want. > > Like all things, you have to use your good judgement. You should have around > 3 months to spot and correct any deficiencies in the patch, which strikes me > as a reasonable amount of time to spot any problems. > > As the time grows short, you'll want to approve less and tighten down the > criteria you use. You should weigh things like, risk, how hard it is to > review the work, how easy is it to miss something in a review, the type of > failure it might introduce, the benefits the work brings, any perceived > downsides, the likelihood of the test suite being able to spot problems with > the work, do you have time to fix any deficiencies people might find, and so > on. > > That said, if you're not comfortable approving it, as reviewer, asking for it > to wait till stage one isn't unreasonable. >
In that case Claudiu, I'm happy for you to merge this. Thanks, Andrew
