On 07/08/2013 05:39 PM, Bruce Korb wrote:
Any solution other than an explanation-less "fatal error:
gnu/stubs-32.h: No such file"
is fine. There is no way to translate that message into
"Either --disable-multilib or else install glibc 32 bit development"
without coming up with the right Googlin
On Tue, Jul 16, 2013 at 4:39 AM, Florian Weimer wrote:
> On 07/08/2013 05:39 PM, Bruce Korb wrote:
>
>> Any solution other than an explanation-less "fatal error:
>> gnu/stubs-32.h: No such file"
>> is fine. There is no way to translate that message into
>> "Either --disable-multilib or else insta
On 16 July 2013 13:46, Gabriel Dos Reis wrote:
> On Tue, Jul 16, 2013 at 4:39 AM, Florian Weimer wrote:
>> I think this is actually a glibc problem. I wonder if it's possible to
>> install a stubs-32.h file in a suitable location by default which contains
>> an illuminating #error directive. Tha
Hello Maxim,
Thanks for your reply. I have in the meantime adjusted the list scheduler to
handle the situation better and it's now working better than it was before on
my port.
However, I will give your suggestion of using sched-ebb a try given that it
might outperform the current solution I ha
On Tue, Jul 16, 2013 at 6:24 AM, Jonathan Wakely wrote:
> On 16 July 2013 13:46, Gabriel Dos Reis wrote:
>> On Tue, Jul 16, 2013 at 4:39 AM, Florian Weimer wrote:
>>> I think this is actually a glibc problem. I wonder if it's possible to
>>> install a stubs-32.h file in a suitable location by de
Jakub et al,
Steffen has developed a nice fix [1] for GOMP_CPU_AFFINITY failing with
>1024 cores.
What steps are needed to get this into GCC 4.8.2?
Thanks,
Daniel
[1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57298
--
Daniel J Blueman
Principal Software Engineer, Numascale
On Tue, Jul 16, 2013 at 7:25 AM, Andrew Pinski wrote:
>> GCC sources could contain a gnu/stubs-32.h header with an #error and
>> ensure that the right directory to find it is searched when building
>> the target libraries, but only after all other directories. It
>> wouldn't need to be installed
On Tue, Jul 16, 2013 at 9:35 AM, Bruce Korb wrote:
> On Tue, Jul 16, 2013 at 7:25 AM, Andrew Pinski wrote:
>>> GCC sources could contain a gnu/stubs-32.h header with an #error and
>>> ensure that the right directory to find it is searched when building
>>> the target libraries, but only after all
On Tue, Jul 16, 2013 at 10:11 AM, Jonathan Wakely wrote:
> On 16 July 2013 16:04, Gabriel Dos Reis wrote:
>> Agreed. It is surprising that we allowed ourselves to
>> break the most common target this way.
>
> It isn't broken, we just don't list one of the prerequisites in the
> installation docs.
On 16 July 2013 16:04, Gabriel Dos Reis wrote:
> Agreed. It is surprising that we allowed ourselves to
> break the most common target this way.
It isn't broken, we just don't list one of the prerequisites in the
installation docs.
On Tue, Jul 16, 2013 at 8:11 AM, Jonathan Wakely wrote:
> On 16 July 2013 16:04, Gabriel Dos Reis wrote:
>> Agreed. It is surprising that we allowed ourselves to
>> break the most common target this way.
>
> It isn't broken, we just don't list one of the prerequisites in the
> installation docs.
When porting to 4.8.x (own backend), I am getting an error when
compiling due to 'TARGET_CPU_CPP_BUILTINS' not defined when compiling
c-family/c-cppbuiltin.c. I am defining TARGET_CPU_CPP_BUILTINS and
related run-time macros in .h.
>From c-family/c-cppbuiltin.c I saw:
#include "tm_p.h" /* For TAR
On Tue, 16 Jul 2013, Hendrik Greving wrote:
> #include "tm_p.h" /* For TARGET_CPU_CPP_BUILTINS & friends. */
That comment is because the macro definition may call functions, whose
prototypes are in tm_p.h. The macro is defined in tm.h (also included in
c-cppbuiltin.c), and any functions it us
On 17/07/2013, at 2:29 AM, Daniel J Blueman wrote:
> Jakub et al,
>
> Steffen has developed a nice fix [1] for GOMP_CPU_AFFINITY failing with >1024
> cores.
>
> What steps are needed to get this into GCC 4.8.2?
>
> Thanks,
> Daniel
>
> [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57298
I
14 matches
Mail list logo
