On Tue, Jun 15, 2010 at 1:00 PM, Joern Rennecke <amyl...@spamcop.net> wrote: > Quoting "Paulo J. Matos" <pocma...@gmail.com>: > >> On Tue, Jun 15, 2010 at 11:46 AM, Joern Rennecke <amyl...@spamcop.net> >> wrote: >>> >>> I think it is also a reflection of an 'all the world is (at least) 32 >>> bit' >>> attitude - in part supported by the GNU coding standard as it was then >>> aimed at making an easily maintainable workstation / server operating >>> system. >>> I.e. the C "int" type was assumed to be 32 bit. And gcc stood for >>> 'GNU C compiler' - and C has type promotion rules that mean you don't >>> need >>> to convert floating point from/to integer types narrower than int. >>> >> >> I can't understand those statements in the sense that GCC was meant to >> be a generic compiler framework therefore having code tying GCC to >> specific archs should be specific in the manual or elsewhere. > > I was merely trying to give some historical context to help interpret > what that SImode check should really be. >
Yes, I understand, thanks. I am sorry if my reply seemed a bit confrontational. That was not the intent. >> Is GCC slowly losing support >> for certain archs or it is still striving to be as generic as >> possible? > > GCC looses and gains support for architectures depending on the availability > of competent volunteer maintainers for these architectures. > Of course, 'volunteer' in this context can also mean that a company > volunteers to employ / contract with a developer to do this work. > But while the backends might vary as much as they like, the core gcc code such as optabs.c should be as generic as possible, right? -- PMatos
