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
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
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
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
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
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
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
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.
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
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
: 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
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57237
Chris Johns changed:
What|Removed |Added
CC||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.
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
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
16 matches
Mail list logo