On 12/15/2012 07:02 PM, Joel Sherrill wrote:
I did test i386-rtems in the past few months but it had a build breakage and I
filed a PR. That issue was resolved but at that point about 1/4 of the rtems
targets failed to compile.
You likely are referring to
http://gcc.gnu.org/bugzilla/show_bug.c
Snapshot gcc-4.7-20121215 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.7-20121215/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.7 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
I am on travel and answering from my phone so don't remember all the exact
dates and PRs.
I did test i386-rtems in the past few months but it had a build breakage and I
filed a PR. That issue was resolved but at that point about 1/4 of the rtems
targets failed to compile. I filed PRs but didn't
On 12/15/2012 12:32 PM, Cynthia Rempel wrote:
Hi,
Thanks for the fast response!
So to keep an architecture supported by GCC, we would need to:
Three or more times a year preferably either during OR after
"stage3"
1. use the SVN version of gcc, 2. patch with an RTEMS patch, 3. use
./contrib/te
Hi,
Thanks for the fast response!
So to keep an architecture supported by GCC, we would need to:
Three or more times a year preferably either during OR after "stage3"
1. use the SVN version of gcc,
2. patch with an RTEMS patch,
3. use ./contrib/test_summary and pipe the output to a shell.
4.
On 12/15/2012 12:42 AM, Ralf Corsepius wrote:
If you want a port to be live show that it is live by posting regular
testresults to gcc-testresults.
Not all of this world is Linux nor backed by large teams at
companies :) We simply do not have the resources do to this.
But that's the poi
On Sat, Dec 15, 2012 at 6:42 AM, Ralf Corsepius
wrote:
> On 12/14/2012 10:09 PM, Richard Biener wrote:
>>
>> On Fri, Dec 14, 2012 at 9:16 PM, Robert Dewar wrote:
>>>
>>> On 12/14/2012 3:13 PM, Cynthia Rempel wrote:
Hi,
RTEMS still supports the i386, and there are many i38
Jan,
It appears that the gcc.dg/tree-prof/pr44777.c execution, -fprofile-generate
-D_PROFILE_GENERATE
testcase exposes inconsistent code generation on both x86_64 darwin and x86_64
linux at -m32.
The darwin linker developer looked at the crashing pr44777.exe executable that
this testcase
pro
