Comments

On Apr 11, 2012, at 3:55 PM, Bernd Schmidt wrote:
> I'm working on a target where intptr_t and pointers are larger than> size_t and ptrdiff_t. The testsuite has problems in this area, since we> often use the latter two types for casting from/to pointers, leading to> unwanted warnings. In some cases I've checked the corresponding PRs and> found that the original testcases used something like plain int or long.
Would this target be able to host gcc ?
Tristan.

On 04/11/2012 04:02 PM, Tristan Gingold wrote:
> > On Apr 11, 2012, at 3:55 PM, Bernd Schmidt wrote:> >> I'm working on a target where intptr_t and pointers are larger than>> size_t and ptrdiff_t. The testsuite has problems in this area, since we>> often use the latter two types for casting from/to pointers, leading to>> unwanted warnings. In some cases I've checked the corresponding PRs and>> found that the original testcases used something like plain int or long.> > Would this target be able to host gcc ?
I do not wish to think about this :) It's embedded, so hopefully no one
will try.
In principle, I'd think any target with enough memory can be made to
host gcc, with varying amounts of work.
Bernd

On Apr 11, 2012, at 7:04 AM, Bernd Schmidt wrote:
> On 04/11/2012 04:02 PM, Tristan Gingold wrote:>> >> On Apr 11, 2012, at 3:55 PM, Bernd Schmidt wrote:>>> I'm working on a target where intptr_t and pointers are larger than>>> size_t and ptrdiff_t. The testsuite has problems in this area, since we>>> often use the latter two types for casting from/to pointers, leading to>>> unwanted warnings. In some cases I've checked the corresponding PRs and>>> found that the original testcases used something like plain int or long.>> >> Would this target be able to host gcc ?> > I do not wish to think about this :) It's embedded, so hopefully no one> will try.> > In principle, I'd think any target with enough memory can be made to> host gcc, with varying amounts of work.
I've hosted gcc on mine, mainly as a code generation correctness check... It's nice having a simulator and enough address bits, you can just plop down yet more memory and presto, everything just works. The more annoying aspect is having to wire up stat and readdir for sim. Fork and exec, are more trivial by comparison. Some gcc ports might not have enough address bits, that might be the only hard requirement that one cannot fudge.

On Apr 11, 2012, at 4:52 PM, Mike Stump wrote:
> On Apr 11, 2012, at 7:04 AM, Bernd Schmidt wrote:>> On 04/11/2012 04:02 PM, Tristan Gingold wrote:>>> >>> On Apr 11, 2012, at 3:55 PM, Bernd Schmidt wrote:>>>> I'm working on a target where intptr_t and pointers are larger than>>>> size_t and ptrdiff_t. The testsuite has problems in this area, since we>>>> often use the latter two types for casting from/to pointers, leading to>>>> unwanted warnings. In some cases I've checked the corresponding PRs and>>>> found that the original testcases used something like plain int or long.>>> >>> Would this target be able to host gcc ?>> >> I do not wish to think about this :) It's embedded, so hopefully no one>> will try.>> >> In principle, I'd think any target with enough memory can be made to>> host gcc, with varying amounts of work.> > I've hosted gcc on mine, mainly as a code generation correctness check... It's nice having a simulator and enough address bits, you can just plop down yet more memory and presto, everything just works. The more annoying aspect is having to wire up stat and readdir for sim. Fork and exec, are more trivial by comparison. Some gcc ports might not have enough address bits, that might be the only hard requirement that one cannot fudge.
VMS is an host/target where pointers (64 bits) can be larger than size_t and ptrdiff_t.
We can run gcc on it, but we also still have a very few patches to submit to achieve that!
Tristan.