mpiled with and
without strict-aliasing. If there is a difference,
we will have to review it. This eliminates a lot of the code base but
it is still generating a lot of cases to examine by
hand.
I'm curious if your patch will ease this process.
Thank you,
Silvius
--joel sherrill
Andrew Haley wrote:
Joel Sherrill writes:
> Silvius Rus wrote:
> >
> > I wrote some code (not released yet) that improves the accuracy of
> > -Wstrict-aliasing using tree-ssa-alias information. The primary idea
> > was to tell the programmer "go fix t
The RTEMS community is still building and trying to test RC2.
We always build with newlib.
Ralf encountered problems on the avr and bfin during the tool
build and has filed or updated PRs for those.
I am now building the complete RTEMS source tree and tests
for every board and multilib. The
Mark Mitchell wrote:
Joel Sherrill wrote:
Ralf encountered problems on the avr and bfin during the tool
build and has filed or updated PRs for those.
Understood, and thnanks for testing!
I should make clear that I don't see release candidates as opportunities
for general te
On Mon, Apr 13, 2020 at 8:34 AM Bryce Cherry via Gcc
wrote:
> Hello all,
>
> I'm just curious about this, but what is the percentage of (and what are
> the) unused instructions for each supported architecture under GCC?
>
I would bet that this info doesn't exist. And you would have to clarify
us
Hi
Over at RTEMS, we have had a report that this very old code has quit
compiling:
#ifdef __SSE__
#define _CPU_Context_restore_fp(fp_context_pp) \
do { \
__asm__ __volatile__( \
"fldcw %0" \
Thanks. We will try this.
FWIW git blame says this inline asm is 11 years old and the new GCC
reported this. :)
--joel
On Sun, Apr 19, 2020 at 2:55 AM Uros Bizjak wrote:
> Hello!
>
> > Over at RTEMS, we have had a report that this very old code has quit
> > compiling:
> >
> > #ifdef __SSE__
>
Hi
Over at RTEMS, we were discussing ports to deprecate/obsolete
and the SH seems to be on everyone's candidate list. I can't seem
to find any gcc test results sh-unknown-elf since 2009 and none
for sh-rtems. I know I posted some but when, I can't say. But the
new mailing list setup may be messi
On Mon, Apr 20, 2020, 3:13 PM Jeff Law wrote:
> On Mon, 2020-04-20 at 14:47 -0500, Joel Sherrill wrote:
> > Hi
> >
> > Over at RTEMS, we were discussing ports to deprecate/obsolete
> > and the SH seems to be on everyone's candidate list. I can't seem
> &
On Tue, Apr 21, 2020 at 4:04 AM Richard Biener
wrote:
> On Mon, Apr 20, 2020 at 11:05 PM Jeff Law via Gcc wrote:
> >
> > On Mon, 2020-04-20 at 15:29 -0500, Joel Sherrill wrote:
> > >
> > >
> > > On Mon, Apr 20, 2020, 3:13 PM Jeff Law wrote:
>
On Wed, Apr 22, 2020 at 12:53 PM Moritz Strübe
wrote:
>
> Am 22.04.2020 um 18:38 schrieb Jeff Law via Gcc:
> > [..] as the
> > alternative would be dropping the AVR port.
>
> Shouldn't that work be sponsored by Microchip (or whoever currently owns
> AVR)? Arduino Inc. might also be highly interes
On Thu, Jun 18, 2020 at 1:34 PM Jonathan Wakely via Gcc
wrote:
> On Thu, 18 Jun 2020 at 19:22, Thomas Koenig via Gcc
> wrote:
> >
> > Hi,
> >
> > I just found a few unversioned files called .intrinsic.c.swp and
> > similar in my "git status" output.
> >
> > Could somebody please put .*.swp into
Hi
RTEMS supports over 15 processor architectures and we would like to ensure
that TLS is supported on all rather than just a handful of popular ones
(arm, x86, powerpc, sparc, etc). I know of Ulrich Drepper's document (
https://www.akkadia.org/drepper/tls.pdf) but it is a few years old and
cover
On Thu, Jun 25, 2020 at 2:54 PM Nathan Sidwell wrote:
> On 6/25/20 2:34 PM, Joel Sherrill wrote:
> > Hi
> >
> > RTEMS supports over 15 processor architectures and we would like to
> ensure
> > that TLS is supported on all rather than just a handful of popular ones
Hi
Over at RTEMS, we ran into a case where the C++ atomics may not be right
for one of the lower level x86 models. We will investigate whether it can
be made right but this has led to the discussion of dropping older models
and setting a new minimum model. Right now, our base is a i386 w/FPU. The
On Fri, Sep 11, 2020 at 1:07 PM Florian Weimer wrote:
> * Joel Sherrill:
>
> > With that in mind, what's the lowest/oldest i386 CPU model we
> > should consider as the new base model?
>
> The 80486 has a CMPXCHG instruction (4-byte CAS). Starting from CAS,
> you
On Fri, Sep 11, 2020 at 1:40 PM Florian Weimer wrote:
> * Joel Sherrill:
>
> > I don't know that we have a huge issue in making the i486 a minimum.
> > I was proposing a Pentium II or P6 as a baseline since that moves you
> > up to having a TBR and initial SMP sup
On Fri, Sep 11, 2020 at 4:36 PM Janne Blomqvist
wrote:
> On Fri, Sep 11, 2020 at 6:52 PM Joel Sherrill wrote:
> >
> > Hi
> >
> > Over at RTEMS, we ran into a case where the C++ atomics may not be right
> > for one of the lower level x86 models. We will inves
On Fri, Sep 11, 2020, 5:02 PM Joel Sherrill wrote:
>
>
> On Fri, Sep 11, 2020 at 4:36 PM Janne Blomqvist
> wrote:
>
>> On Fri, Sep 11, 2020 at 6:52 PM Joel Sherrill wrote:
>> >
>> > Hi
>> >
>> > Over at RTEMS, we ran into a case where t
Hi
being deprecated for nearly 20 years of C++ standards has
always been a bit baffling to me. I'm used to thingis being deprecated and
then removed a bit faster than that.
It is still deprecated in C++17 but does not appear in C++2x as of
draft N4860. GCC 10 still behaves the same and you get a
On Fri, Oct 9, 2020 at 8:49 AM Jonathan Wakely
wrote:
> On Fri, 9 Oct 2020 at 14:31, Joel Sherrill wrote:
> >
> > Hi
> >
> > being deprecated for nearly 20 years of C++ standards has
> > always been a bit baffling to me. I'm used to thingis being deprecat
Hi
This isn't the perfect place to ask this but someone here may have insight.
And getting help with Coverity Scan directly isn't easy. I'm hoping someone
here has some insight or can point me to someone who does.
We have been using Coverity Scan a long time with RTEMS. It works fine
using gcc 7.
On Wed, Oct 28, 2020 at 11:45 AM wrote:
> - Original Message -
> > Hi
> >
> > This isn't the perfect place to ask this but someone here may have
> > insight.
> > And getting help with Coverity Scan directly isn't easy. I'm hoping
> > someone
> > here has some insight or can point me to so
On Fri, Jan 15, 2021 at 4:12 AM Jonathan Wakely via Gcc
wrote:
> On Fri, 15 Jan 2021, 07:39 Sebastian Huber, <
> sebastian.hu...@embedded-brains.de> wrote:
>
> > On 14/01/2021 15:16, Sebastian Huber wrote:
> >
> > > Hello,
> > >
> > > I try to add a nios2 multilib to support the "Nios II Floating
On Thu, Mar 4, 2021 at 3:00 AM wrote:
> Hello,
>
> My OS project has a very long history (I started with it in 1988) and it
> is running on 1000s of installations. Thus, it's a pretty mature
> project. Doing something meaningful on the kernel side requires a lot of
> knowledge of how it operates,
On Wed, Mar 31, 2021 at 9:23 AM Paul Koning via Gcc wrote:
> I may have lost it in the enormous flood of text, but I want to ask these
> general questions.
>
> 1. Is there a published code of conduct for GCC community members,
> possibly different ones depending on which level of the organization
needs soft-float. They are all relatively slow.
But posted measurements of size and speed impact of doing this
would be appreciated.
Unless I slept through it getting removed, the rtems targets
never dropped the lower end i386 to keep legacy hardware supported.
--
Joel Sherrill, Ph.D.
Hi
Just noticed this building the head for arm-rtems4.11. Should
the first comparison be eliminated and, maybe, a comment added?
ctype_members.cc:216:14: warning: comparison of unsigned expression >= 0 is
always true [-Wtype-limits]
if (__wc >= 0 && __wc < 128 && _M_narrow_ok)
Hi
I saw these warnings in the build of some RTEMS targets on
the gcc head.
/home/joel/test-gcc/gcc/libgcc/emutls.c:159:7: warning: implicit declaration of
function 'calloc' [-Wimplicit-function-declaration]
/home/joel/test-gcc/gcc/libgcc/emutls.c:159:13: warning: incompatible implicit
declara
On August 20, 2015 5:22:47 PM EDT, Joseph Myers wrote:
>On Thu, 20 Aug 2015, FX wrote:
>
>> > Well, they aren't *targets*, but *host* and *build* systems.
>>
>> Yes, but do we maintain a list of support host or build systems, that
>
>> would be different from our list of supported targets?
>
>I
On August 26, 2015 8:28:40 PM CDT, Jeff Law wrote:
>On 08/26/2015 06:02 PM, Peter Bergner wrote:
>> On Wed, 2015-08-26 at 13:44 -0700, Ian Lance Taylor wrote:
>>> On Wed, Aug 26, 2015 at 12:31 PM, Eric S. Raymond
>wrote:
click = click
>>>
>>> You've got me on that one. Any hints?
>>
>> J
s.
j...@oarcorp.com
joel.sherr...@oarcorp.com
j...@gcc.gnu.org
If it isn't too much trouble, just map me to the j...@gcc.gnu.org and I
will try to be better about using that in ChangeLog entries in the future.
--joel sherrill
ructures should be double
checked as well.
--joel sherrill
On 10/25/2015 12:59 PM, Arnaud Charlet wrote:
I would like to know from where Complete_Master is called to break there
and
find out why it uses the wrong id.
Why don't you simply put a breakpoint on Complete_Master?
That's
On 10/26/2015 3:02 PM, Jan Sommer wrote:
Am Monday 26 October 2015, 08:26:57 schrieb Joel Sherrill:
Hi
I am on travel this week but I thought we had this problem
solved. I poked on a build server I used but can't find
the change and it doesn't look to be committed.
Yes, it w
On October 26, 2015 5:02:07 PM EDT, Jan Sommer
wrote:
>Am Monday 26 October 2015, 15:09:34 schrieb Joel Sherrill:
>>
>> On 10/26/2015 3:02 PM, Jan Sommer wrote:
>> > Am Monday 26 October 2015, 08:26:57 schrieb Joel Sherrill:
>> >> Hi
>> >>
>
On 10/29/2015 5:46 AM, Sebastian Huber wrote:
On 28/10/15 15:22, Jan Sommer wrote:
I got it working. The Set function was always overwriting the address of the
previous ATCB, so STPO.Self was always returning the ATCB of the task created
last.
It turns out that I was building rtems without t
Hi
It has come time for RTEMS to obsolete three targets: avr-rtems*, h8300-rtems*,
and m32r-rtems* in gcc and binutils. They have been removed from the RTEMS
master.
Since we were dealing with more than one, I thought I would ask for advice on
making sure I executed the process correctly.
--jo
Hi
Is there something special needed to commit via git? I got an odd error pushing
some minor RTEMS patches and wondered what the proper procedure was.
I am using the same commands and process I use with newlib so was wondering.
The website has svn instructions so maybe I am just confused after
On 2/26/2016 11:50 AM, Jonathan Wakely wrote:
On 26 February 2016 at 17:25, Joel Sherrill wrote:
Hi
Is there something special needed to commit via git? I got an odd error pushing
some minor RTEMS patches and wondered what the proper procedure was.
I am using the same commands and process
On February 28, 2016 3:20:24 PM CST, Gerald Pfeifer wrote:
>On Wed, 24 Feb 2016, Richard Earnshaw (lists) wrote:
>> I propose to commit this patch later this week.
>
>+ Support for revisions of the ARM architecture prior to ARMv4t
>has
>+ been deprecated and will be removed in a futu
On 2/29/2016 5:37 AM, Kyrill Tkachov wrote:
On 28/02/16 21:34, Joel Sherrill wrote:
On February 28, 2016 3:20:24 PM CST, Gerald Pfeifer wrote:
On Wed, 24 Feb 2016, Richard Earnshaw (lists) wrote:
I propose to commit this patch later this week.
+ Support for revisions of the ARM
I may have missed this comment but GCC wouldn't need to apply as it's own GSoC
project. The GNU Project applied as an umbrella organization and was accepted.
Any GCC activities would be under that. I don't know who the organization
administrator is for the GNU Project but the loop needs to be cl
rence to `__gnu_cxx::__atomic_add(int volatile*, int)'
Is this present for sh-elf? Or is there some magic
bit missing in the RTEMS configuration stanzas?
Thanks in advance.
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Lin
On April 16, 2016 7:50:21 PM CDT, Oleg Endo wrote:
>Hi,
>
>On Sat, 2016-04-16 at 18:58 -0500, Joel Sherrill wrote:
>
>> I am hoping the solution to this is obvious to someone
>> more familiar with the C++ libraries. Recently the
>> sh4 BSP for RTEMS began to have
On 4/18/2016 6:11 AM, Oleg Endo wrote:
On Sun, 2016-04-17 at 13:33 -0500, Joel Sherrill wrote:
Thanks for the quick and thorough reply.
This doesn't happen with GCC 4.9 which we are using on our newest
release branch. With any luck your work will be in gcc 7 before we
make another re
nity
cares about being proper per POSIX and I would expect the Cygwin
community to feel the same way.
Other than inspection, what can be done to find violations?
--joel
RTEMS
Even if I fix libstdc++ to not require _GNU_SOURCE that won't make the
problem go away, because a user could
On May 4, 2016 2:35:38 PM CDT, "Manuel López-Ibáñez"
wrote:
>On 04/05/16 19:20, David Malcolm wrote:
>> On Wed, 2016-05-04@18:15 +0200, Antonio Diaz Diaz wrote:
>>> - It can't be portably disabled; older versions of gcc do not
>>> accept
>>> '-Wno-misleading-indentation'. (At least 4.
On 5/9/2016 2:25 PM, Ian Lance Taylor wrote:
On Fri, May 6, 2016 at 10:42 PM, Rich Felker wrote:
The *context APIs are deprecated and I'm not sure they're worth
supporting with this. It would be a good excuse to get people to stop
using them.
The gccgo library uses them, because there is n
On 5/9/2016 2:45 PM, Ian Lance Taylor wrote:
On Mon, May 9, 2016 at 12:41 PM, Joel Sherrill
wrote:
On 5/9/2016 2:25 PM, Ian Lance Taylor wrote:
On Fri, May 6, 2016 at 10:42 PM, Rich Felker wrote:
The *context APIs are deprecated and I'm not sure they're worth
supporting wit
On 5/9/2016 3:03 PM, Michael Matz wrote:
Hi,
On Mon, 9 May 2016, Rich Felker wrote:
The *context APIs are deprecated and I'm not sure they're worth
supporting with this. It would be a good excuse to get people to
stop using them.
How? POSIX decided to remove the facilities without any ade
On 5/9/2016 3:41 PM, Ian Lance Taylor wrote:
On Mon, May 9, 2016 at 1:07 PM, Joel Sherrill wrote:
One complication on RTEMS which is a single process, multi-threaded RTOS
is that we can no longer check the stack bounds. For threads, we know
where the stack memory is and the range for each
On October 26, 2016 9:07:16 AM EDT, Ian Lance Taylor wrote:
>On Tue, Oct 25, 2016 at 10:53 PM, Will Hawkins
>wrote:
>>
>> My name is Will Hawkins and I am a longtime user of gcc and admirer
>of
>> the project. I hope that this is the proper forum for the question I
>> am going to ask. If it isn
rtems4.11/4.8.2/../../../../sh-rtems4.11/bin/ld:
final link failed: Bad value
Thanks.
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available(256) 722-9985
date sweep for C++ transition missed this file?
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available(256) 722-9985
On 5/1/2014 3:29 PM, Oleg Endo wrote:
> On 01 May 2014, at 22:08, Joel Sherrill wrote:
>
>> Hi
>>
>> gcc-4.8.2 targeting sh-*-* fails to compile on
>> FreeBSD 10 which is using clang. I am hoping someone
>> has some ideas about these.
> Yes, I've no
tems-4.11-work/tools/lib/gcc/sh-rtems4.11/4.8.2
-L/users/joel/rtems-4.11-work/tools/lib/gcc/sh-rtems4.11/4.8.2/../../../../sh-rtems4.11/lib
../shared/src/cache_rel-cache_aligned_malloc.o
../shared/src/cache_rel-cache_manager.o -EL
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available(256) 722-9985
a_options="${extra_options} sh/superh.opt" ;;
Do we need to add those? Anything else we might be missing?
On 5/5/2014 11:37 AM, Joel Sherrill wrote:
> Hi
>
> We have a few build failures on the RTEMS target where it appears
> that the -ml argument to make a relocatable is
rated.
Other than fixing the manual or downgrading makeinfo, any suggestions
or comments?
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support
e
was aware of it.
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available(256) 722-9985
Hi
I was updating the RTEMS scripts to build GNAT and it appears
that passing CFLAGS_FOR_TARGET in to add a -I option to
the build no longer works. We were using it so the Ada build
could find the networking .h files.
What's the current way of doing this?
Thanks.
--
Joel Sherrill,
es.
>
> If the library is not going to be expanded to support all GPUs and
> offload targets, the library name should be more specific to Intel.
That matches what I understood and should have said Yes to.
> Thanks, David
--
Joel Sherrill, Ph.D. Director of Research & D
be
>>make CFLAGS="-g -O2 -fbracket-depth=512"
> Also i thought we did not support cross building with anything besides gcc.
The RTEMS community sees this when using clang/llvm on FreeBSD.
Franzi.. did the suggestion from Chris Johns to increase the limit
to
UyTPp
m32c-elf/m32cm
m32c-elf/m32cm/libgcc
I think that looks odd. Normally the top directory is named for libraries
not multilib variants.
Any ideas?
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me
/greed/dj/gnu/gcc/svn/gcc-4_9-branch/gcc/final.c:2891
> 0x6258ef final(rtx_def*, _IO_FILE*, int)
> /greed/dj/gnu/gcc/svn/gcc-4_9-branch/gcc/final.c:2023
> 0x626035 rest_of_handle_final
> /greed/dj/gnu/gcc/svn/gcc-4_9-branch/gcc/final.c:4427
> 0x626035 execute
>
thing odd in the top
configurery magic for m32c which could cause this but I could
easily be missing something.
On 7/17/2014 3:17 PM, Joel Sherrill wrote:
> On 7/17/2014 3:08 PM, DJ Delorie wrote:
>> I just tried a 4.9.1 build and got this error:
> Same error in m32c-elf/m32cm/libg
d in darwin.opt with this:
fapple-kext
Target Report C++ Var(flag_apple_kext)
Generate code for darwin loadable kernel extensions
Who is comfortable fixing that?
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available(256) 722-9985
On August 31, 2014 8:19:49 AM CDT, Peng Fan wrote:
>Hi,
>
>I am writing some code and found that system crashed. I found it was
>unaligned access which causes `data abort` exception. I write a piece
>of code and objdump
>it. I am not sure this is right or not.
>
>command:
>arm-poky-linux-gnueabi
On September 1, 2014 6:10:40 AM CDT, Jakub Jelinek wrote:
>On Mon, Sep 01, 2014 at 12:35:57PM +0200, Frédéric Buclin wrote:
>> I again disabled account creation on GCC Bugzilla due to spammers
>being
>> still very active. 117 user accounts have been created since
>yesterday.
>> 102 have been ide
it might be missing it'd be helpful for
> evaluation.
>
> My recommendation would be to file a bug report with the reproducer.
> m68k isn't nearly as important today as it has been in the past, so
> getting developer time to hash through how all this should work for the
> coldfire may be difficult.
>
> jeff
>
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available(256) 722-9985
expects argument of type 'double', but
argument 2 has type 'float' [-Wformat=]
The code is:
#include
void f(float X)
{
printf( "%f", X );
}
Any ideas? Should I raise a PR?
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oa
On September 10, 2014 3:40:05 PM CDT, "Joseph S. Myers"
wrote:
>On Wed, 10 Sep 2014, Joel Sherrill wrote:
>
>> Hi
>>
>> We have a few RTEMS BSPs which use CPUs where float, double,
>> and long double are the same. This triggers the printf format
>
-exceptions on the
configure line. Before we didn't have to do this.
FWIW I think this same issue is tripped by the h8300.
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS H
to detect exception model
make[1]: *** [configure-target-libgcc] Error 1
Any suggestions?
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Avail
toconf probe code. m32c when -mcpu=m32cm and h8300
when -ms.
I suppose I need to file these as target specific regressions since 4.9.
Thanks for prodding my rusty memory.
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Application
^
../../../../../../gcc/libstdc++-v3/src/c++98/mt_allocator.cc:643:52:
warning: cast to pointer from integer of different size
[-Wint-to-pointer-cast]
__gthread_setspecific(freelist._M_key, (void*)_M_id);
^
Thanks.
--
Joel Sherrill
Attached is a patch which changes size_t to uintptr_t.
It is enough to let the build continue. But I would appreciate
feedback given the code.
--joel
On 11/7/2014 9:07 AM, Joel Sherrill wrote:
> Hi
>
> On m32c-rtems, we have a build error in C++ because size_t
> is 16-bits and poi
On 11/7/2014 9:25 AM, Paolo Carlini wrote:
> Hi,
>
> On 11/07/2014 04:07 PM, Joel Sherrill wrote:
>> Hi
>>
>> On m32c-rtems, we have a build error in C++ because size_t
>> is 16-bits and pointers are 24 bits. m32c-elf probably does not
>> enable __GTHREAD
On November 8, 2014 9:00:02 AM CST, Jonathan Wakely
wrote:
>On 7 November 2014 16:56, Joel Sherrill wrote:
>>
>> On 11/7/2014 9:25 AM, Paolo Carlini wrote:
>>> Hi,
>>>
>>> On 11/07/2014 04:07 PM, Joel Sherrill wrote:
>>>> Hi
>>>&g
On November 8, 2014 9:00:02 AM CST, Jonathan Wakely
wrote:
>On 7 November 2014 16:56, Joel Sherrill wrote:
>>
>> On 11/7/2014 9:25 AM, Paolo Carlini wrote:
>>> Hi,
>>>
>>> On 11/07/2014 04:07 PM, Joel Sherrill wrote:
>>>> Hi
>>>&g
On November 8, 2014 9:04:14 AM CST, Joel Sherrill
wrote:
>
>
>On November 8, 2014 9:00:02 AM CST, Jonathan Wakely
> wrote:
>>On 7 November 2014 16:56, Joel Sherrill wrote:
>>>
>>> On 11/7/2014 9:25 AM, Paolo Carlini wrote:
>>>> Hi,
>&
/tmp/cc9EfnXy.s: Assembler messages:
/tmp/cc9EfnXy.s:69: Error: MOV Rd, Rs with two low registers is not
permitted on this architecture -- `mov r6,r7'
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Researc
e we need to
> issue a last call to maintainers caring about those targets to fill in
> this information, and failing that deprecate them.
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
On 11/10/2014 10:59 AM, Joseph Myers wrote:
> On Mon, 10 Nov 2014, Joel Sherrill wrote:
>
>> On 11/10/2014 10:32 AM, Joseph Myers wrote:
>>> On Sat, 8 Nov 2014, Paolo Carlini wrote:
>>>
>>>> Good. Sorry, if I missed some relatively recent development: i
ecute_function_todo
../../gcc/gcc/passes.c:1868
0x870733 execute_todo
../../gcc/gcc/passes.c:1925
Please submit a full bug report,
with preprocessed source if appropriate.
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line A
On 11/11/2014 9:27 AM, Ramana Radhakrishnan wrote:
> On Tue, Nov 11, 2014 at 3:16 PM, Joel Sherrill
> wrote:
>>> Fix is committed to trunk at
>>> https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=217341.
>>>
>>> BR,
>>> Terry
>>&g
On December 18, 2014 4:14:54 AM CST, Matthew Fortune
wrote:
>> Does this cover OS specific areas in the gcc/config.gcc file? For
>> example:
>>
>> https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01214.html
>
>I can’t answer authoritatively but I would expect it does include
>OS specific areas o
the MAINTAINERS file accordingly, and Happy Hacking!
-- Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.com On-Line Applications Research Ask me about
RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
If not, then I will prepare patches to fix the spelling. :)
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available(256) 722-9985
complex approach, this usually can be done in a simpler way
> with a machine-specific pass that runs at the end of the RTL pipeline.
>
Isn't this similar to needing to fill a delay slot after a branch
instruction? My recollection
is that some SPARC and MIPS have to deal with that.
--
J
from last report
>> --- ---
>> P1 39+ 24
>> P2 98+ 15
>> P3 48- 84
>> --- ---
>> Total 185- 45
>>
>>
>> P
ry `/home2/joel/build/b-arm-gcc'
make: *** [all] Error 2
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available(256) 722-9985
On January 9, 2015 4:00:38 PM CST, Jan-Benedict Glaw wrote:
>On Fri, 2015-01-09 15:05:52 -0600, Joel Sherrill
> wrote:
>> Hi
>>
>> Does anyone else see this? There is a semi-colon at the end of
>> gcc/config/arm/arm.h:771 which I don't think should be the
have taken a couple of swings at this in the past but
never gotten a solution. I am hoping we are luckier this time. :)
Thanks.
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a
On 1/12/2015 10:30 AM, Andreas Schwab wrote:
> Joel Sherrill writes:
>
>> FAIL: gfortran.dg/g77/f77-edit-x-out.f -Os output pattern test, is 1 2 3
>> 1 2 3
>>
>> , should match ^1 2 3(
>> |
>> |)1 2 3(
>> |
>> |)$
> Where is the \r g
On 1/12/2015 1:14 PM, Tobias Burnus wrote:
> Joel Sherrill wrote:
>> On 1/12/2015 10:30 AM, Andreas Schwab wrote:
>>> Joel Sherrill writes:
>>>
>>>> FAIL: gfortran.dg/g77/f77-edit-x-out.f -Os output pattern test, is 1 2 3
>>>> 1 2 3
>
On 1/12/2015 2:49 PM, Tobias Burnus wrote:
> Joel Sherrill wrote:
>> run.txt is the cut and paste of the log file which reflects DejaGNU's
>> view of the run.
> Which means that it hopefully matches every bit of the original output
> and that no editor interferes
On 1/12/2015 3:18 PM, Tobias Burnus wrote:
> Hi Joel,
>
> Am 12.01.2015 um 22:04 schrieb Joel Sherrill:
>> That was very close.
>>
>> cat out.txt | \
>>perl -e '$in = join("", ); if ($in =~ m/^1 2 3(\n|\r\n|\r)1 2
>> 3(\n|\r\n|\r)((\
1:13: warning: incompatible implicit
declaration of built-in function 'realloc'
../../../gcc/libgcc/emutls.c:171:13: note: include '' or
provide a declaration of 'realloc'
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp
to end up with details in one section
and a reference in another. I am wondering if there are some common
questions users ask about options which could be addressed like this.
Disabling C++ exceptions and RTTI plus the floating point options for
performance which usually come up in Intel C vs GCC be
On January 17, 2015 8:34:04 AM CST, Gary Funck wrote:
>On 01/14/15 23:15:59, Jeff Law wrote:
>> Sounds good. I think just starting with the list & creating the
>buckets
>> with the list. Then post here and we'll iterate and try to nail that
>down
>> before you start moving everything in the .t
1 - 100 of 509 matches
Mail list logo
