[Bug libgcc/66032] RTEMS MIPS build fails on FreeBSD

2015-05-05 Thread chris at contemporary dot net.au
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66032 --- Comment #3 from Chris Johns --- Built GNU sed from source and added to my path: ruru rtems $ sed --version GNU sed version 4.2 Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. T

[Bug libgcc/66032] RTEMS MIPS build fails on FreeBSD

2015-05-05 Thread chris at contemporary dot net.au
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66032 --- Comment #2 from Chris Johns --- (In reply to Andrew Pinski from comment #1) > Have you tried GNU sed rather than BSD sed? No and a good idea. I will. FYI I tend to keep the machines used for testing builds clean and minimal to minimised th

[Bug libgcc/66032] New: RTEMS MIPS build fails on FreeBSD

2015-05-05 Thread chris at contemporary dot net.au
Assignee: unassigned at gcc dot gnu.org Reporter: chris at contemporary dot net.au Target Milestone: --- Created attachment 35473 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35473&action=edit RSB Report for RTEMS 4.1 MIPS failure on FreeBSD. Build RTEMS 4.11 MIP t

[Bug other/64133] m68k-rtems-gcc generates invalid code.

2014-11-30 Thread chris at contemporary dot net.au
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64133 --- Comment #2 from Chris Johns --- Thanks for the quick response. The clean trap instruction did confuse me. I suppose my work around to move the code into another file stops gcc detecting the access. Is this true ? I am happy to build our cod

[Bug other/64133] New: m68k-rtems-gcc generates invalid code.

2014-11-30 Thread chris at contemporary dot net.au
Assignee: unassigned at gcc dot gnu.org Reporter: chris at contemporary dot net.au Created attachment 34151 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34151&action=edit Preprocessed source The preprocessed output attached generates invalid code for the -O2 optim

[Bug target/61026] New: sh-rtems4.11 build of 4.9.0 fails on FreeBSD 10 c++ (clang).

2014-05-01 Thread chris at contemporary dot net.au
Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: chris at contemporary dot net.au Building gcc-4.9.0 and gcc-4.8.2 for the sh-rtems4.11 on FreeBSD 10 using the standard c++ compiler fails with ... [ Note config/sh/sh.c has a comment

[Bug target/61024] New: nios2-rtems4.11 build of 4.9.0 fails on FreeBSD 10 c++ (clang).

2014-05-01 Thread chris at contemporary dot net.au
Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: chris at contemporary dot net.au Building gcc for the nios2-rtems4.11 on FreeBSD 10 using the standard c++ compiler fails with ... /usr/bin/c++ -O2 -pipe -I/mnt/data0/chrisj/rtems/rsb

[Bug libstdc++/60645] Improve handling of errors from pthread functions throughout libstdc++

2014-03-25 Thread chris at contemporary dot net.au
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60645 --- Comment #7 from Chris Johns --- Thanks and the timing is fine. I saw this as a long term issue. We have a working rtems thread model that is SMP safe so we are fine for now.

[Bug libstdc++/60645] locale::facet::_S_get_c_locale does not handle __gthread_once error codes.

2014-03-25 Thread chris at contemporary dot net.au
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60645 --- Comment #5 from Chris Johns --- I do not know what the right thing to do is for something like libstdc++ with such a wide number of different users. I suspect a patch would be easy if the path to take was clear. In the RTEMS case raising a ru

[Bug libstdc++/60645] locale::facet::_S_get_c_locale does not handle __gthread_once error codes.

2014-03-25 Thread chris at contemporary dot net.au
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60645 --- Comment #3 from Chris Johns --- Yes I agree the error should not happen in this case. I apologise as I should have looked for a better example to highlight the issue being discussed in the RTEMS project. I also agree the handling of any error

[Bug libstdc++/60645] New: locale::facet::_S_get_c_locale does not handle __gthread_once error codes.

2014-03-25 Thread chris at contemporary dot net.au
: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: chris at contemporary dot net.au RTEMS cannot use the posix thread model because the pthread_once call may return an error code. The code libgcc/gthr-posix.h#696 returns

[Bug other/57282] New: Canadian cross on FreeBSD to MingW32 fails with unknown warning "-Wno-narrowing" is build gcc is too old

2013-05-14 Thread chris at contemporary dot net.au
ion: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: chris at contemporary dot net.au Using gcc-4.8-branch sources from the git repo. FreeBSD 9.1 machine with the d

[Bug target/57237] Upstreaming the rtems v850 multilib gcc patch

2013-05-12 Thread chris at contemporary dot net.au
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57237 Chris Johns changed: What|Removed |Added CC||chris at contemporary dot net.au

[Bug target/56771] Integer Overflow? Building arm-rtems libgcc2

2013-04-02 Thread chris at contemporary dot net.au
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56771 --- Comment #6 from Chris Johns 2013-04-02 11:04:29 UTC --- It looks to me like libcpp/configure.ac is not setting 'need_64bit_hwint' to 'yes'. It looks like the RTEMS ptch to change arm-rtems*eabi to arm-rtems* needs to have this added.

[Bug target/56771] Integer Overflow? Building arm-rtems libgcc2

2013-04-01 Thread chris at contemporary dot net.au
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56771 --- Comment #5 from Chris Johns 2013-04-02 06:28:32 UTC --- A cygwin cross-compile also fails as it is a 32bit host. The failure is not specific to Linux. This means RTEMS users have problems building from source on Windows as cygwin cu

[Bug target/56771] Integer Overflow? Building arm-rtems libgcc2

2013-04-01 Thread chris at contemporary dot net.au
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56771 --- Comment #4 from Chris Johns 2013-04-02 06:23:53 UTC --- Created attachment 29771 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29771 xgcc dumps from a cygwin build that also fails. The file contains all the gcc trace and dump