Re: [Gcc-cfarm-users] gcc10 logs segfaults

2015-04-28 Thread Laurent GUERBY
Hi Bart, This messages are usually from user space processes segfaulting (running testsuites with bugs, etc...) Sincerely, Laurent On Fri, 2015-04-17 at 10:50 +0200, Bart Van Assche wrote: > Hello, > > A very large number of segfaults is present in the kernel log of system > gcc10. Can someon

[Gcc-cfarm-users] Future of non-x86/Linux platforms?

2015-04-28 Thread Paul Hargrove
I've seen this topic addressed in the archives, and don't want to restart any of the arguments about how useful/relevant CFarm has become. >From my point of view "beggars can't be choosers" and so this email is just my observations and a few questions and NOT any sort of complaint. As others have

Re: [Gcc-cfarm-users] Future of non-x86/Linux platforms?

2015-04-28 Thread Matthew Fortune
> 1) Is there any effort (current or planned for the near-future) to revive any > of the IA64, ARM, MIPS or SPARC systems? MIPS boards in the form of some edge router pros are currently being shipped to the CFarm in France courtesy of Imagination Technologies. Ø 2) Is there any desire from us

Re: [Gcc-cfarm-users] Future of non-x86/Linux platforms?

2015-04-28 Thread Vincent Lefevre
On 2015-04-28 15:31:50 -0700, Paul Hargrove wrote: > Since most of us probably use Linux or OSX on x86-64 every day, this is not > "diverse" for some of us (though I know our definitions of "diverse" will > differ). Indeed I was using CFarm mainly for non x86-64/Linux machines. > So, I want to as

Re: [Gcc-cfarm-users] Future of non-x86/Linux platforms?

2015-04-28 Thread Paul Hargrove
On Tue, Apr 28, 2015 at 4:24 PM, Vincent Lefevre wrote: > On 2015-04-28 15:31:50 -0700, Paul Hargrove wrote: [...snip...] > > > 1) Is there any effort (current or planned for the near-future) to revive > > any of the IA64, ARM, MIPS or SPARC systems? > > > > 2) Is there any desire from users to

Re: [Gcc-cfarm-users] Future of non-x86/Linux platforms?

2015-04-28 Thread Thibaut Varène
On 29 avr. 2015, at 00:31, Paul Hargrove wrote: > I've seen this topic addressed in the archives, and don't want to restart any > of the arguments about how useful/relevant CFarm has become. > From my point of view "beggars can't be choosers" and so this email is just > my observations and a f

Re: [Gcc-cfarm-users] Future of non-x86/Linux platforms?

2015-04-28 Thread Andrew Pinski
On Tue, Apr 28, 2015 at 5:47 PM, Thibaut Varène wrote: > > On 29 avr. 2015, at 00:31, Paul Hargrove wrote: > >> I've seen this topic addressed in the archives, and don't want to restart >> any of the arguments about how useful/relevant CFarm has become. >> From my point of view "beggars can't be

Re: [Gcc-cfarm-users] Future of non-x86/Linux platforms?

2015-04-28 Thread Fotis Georgatos
Hi, On Apr 29, 2015, at 1:47 AM, Thibaut Varène wrote: > This brings the question of "what is cfarm used for". QEMU can only "emulate" > so much, and in some specific cases, nothing can replace actual hardware > testing. The behavior of some platforms, and more precisely some flavors of > said

Re: [Gcc-cfarm-users] Future of non-x86/Linux platforms?

2015-04-28 Thread Paul Hargrove
On Tue, Apr 28, 2015 at 6:14 PM, Fotis Georgatos wrote (in part): > For the record, both hardware and virtual/simulated resources are useful, > for different purposes each. I agree entirely and that is exactly the spirit in which I was operating when introduced the question. I never intended to

[Gcc-cfarm-users] Fwd: Future of non-x86/Linux platforms?

2015-04-28 Thread Paul Hargrove
My message below was intended for the entire list, not just for Matthew. -Paul -- Forwarded message -- From: Paul Hargrove Date: Tue, Apr 28, 2015 at 4:20 PM Subject: Re: [Gcc-cfarm-users] Future of non-x86/Linux platforms? To: Matthew Fortune On Tue, Apr 28, 2015 at 3:47 PM, M

Re: [Gcc-cfarm-users] Future of non-x86/Linux platforms?

2015-04-28 Thread Paul Hargrove
On Tue, Apr 28, 2015 at 7:31 PM, Paul Hargrove wrote: [...snip...] > FWIW: There is a "neat trick" one can use involving distcc. > [...snip...] > While I've not tried building gcc this way (but might try now with > --disable-bootstrap) I've found this far faster than compiling inside the > emula