Jeff Law writes:
> They're Fortran specific options. I'm not sure how that impacts your
> tests though.
Thanks Jeff. I figured this out now. I was building a C compiler from
a source tree that does not include the sources for the fortran
front-end. It seems that this is no longer supported,
My builds from HEAD are failing unless I remove these tests. Are these
invalid tests?
diff --git a/gcc/opt-suggestions.c b/gcc/opt-suggestions.c
index 9444a35cb54..e64ee7e5660 100644
--- a/gcc/opt-suggestions.c
+++ b/gcc/opt-suggestions.c
@@ -264,8 +264,6 @@ test_completion_valid_options (optio
lokesh janghel writes:
> I am starting to looking into this issue.
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85667#c0
Thank you for looking into this bug, which was caught by the libffi testsuite:
https://sourceware.org/ml/libffi-discuss/2018/msg00032.html
I would like to see this fixed,
Mikael Pettersson writes:
> I have a toy backend based on the moxie backend as a template. During its
> development I found some oddities in the moxie backend that may be bugs.
>
> 1. The REGNO_OK_FOR_INDEX_P(NUM) macro in moxie.h is:
>
> #define REGNO_OK_FOR_INDEX_P(NUM) MOXIE_FP
>
> Since MOXI
Is it still important that libffi be included in the GCC tree?
AG
On Thu, Oct 27, 2016 at 8:55 AM, Matthias Klose wrote:
> With the removal of libgcj, the only user of libffi in GCC is libgo, however
> there is now no maintainer listed anymore for libffi in the MAINTAINERS file,
> and the libff
Jeff Law writes:
> On 04/02/14 06:08, Anthony Green wrote:
>>
>> One embarrassing feature of the moxie compiler port is that it really
>> doesn't understand how to promote integral types. Moxie cores
>> zero-extend all loads, but the compiler still shifts loaded
Joern Rennecke writes:
> On 2 April 2014 13:08, Anthony Green wrote:
>
>> I though the answer was to simply add something like this...
>>
>> (define_insn "zero_extendqisi"
>> [(set (match_operand:SI 0 "register_operand" "=r")
>
One embarrassing feature of the moxie compiler port is that it really
doesn't understand how to promote integral types. Moxie cores
zero-extend all loads, but the compiler still shifts loaded values back
and forth to zero out the upper bits.
So...
unsigned int foo (unsigned char *c)
{
return
FX MOREL writes:
> Hi everyone,
>
> I am developing on a custom design using the LatticeMico32
> architecture and I use gcc 4.5.1 to compile C code for this arch.
>
> In this architecture, the loading of an address 0x always
> takes two assembly instructions to fetch the address because
>
On 3/6/2011 9:10 AM, H.J. Lu wrote:
On Sun, Mar 6, 2011 at 5:57 AM, Dave Korn wrote:
On 06/03/2011 07:02, Anthony Green wrote:
All of the -flto tests fail for moxie-elf...
http://gcc.gnu.org/ml/gcc-testresults/2011-03/msg00399.html
It turns out that this is because it fails to link with the
All of the -flto tests fail for moxie-elf...
http://gcc.gnu.org/ml/gcc-testresults/2011-03/msg00399.html
It turns out that this is because it fails to link with the code in
libgloss when I enable -flto.
I link the test code with a special linker script (sim.ld) that pulls in
the libgloss cod
On 7/9/2010 4:44 PM, Anthony Green wrote:
Building and testing the moxie-uclinux toolchain with the HEAD of GCC
is very simple:
$ git clone git://github.com/atgreen/moxiedev
$ cd moxiedev/gcc
$ ../scripts/fix-svn.sh
$ ./contrib/gcc_update
$ cd ..
$ PATH=`pwd`/root/usr/bin:$PATH
$ ant build
On 7/9/2010 11:59 AM, Maxim Kuvyrkov wrote:
On 7/9/10 3:22 PM, Anthony Green wrote:
Hi Maxim,
Recent changes to config.gcc are preventing me from building a
moxie-uclinux toolchain.
Anthony,
What is the error the build process is failing on?
Here are the details:
Without OPTION_ANDROID=0
Hi Maxim,
Recent changes to config.gcc are preventing me from building a
moxie-uclinux toolchain. They look related to your 2010-05-27 change
for adding support for the Bionic C library. Your patches says that you
updated the moxie-*-uclinux* config, but were you able to test this?
I had t
On 03/01/2010 04:47 PM, Rainer Orth wrote:
> If this is deemed acceptable, I'll probably go ahead and implement
> proper support for this in libffi, but only after providing a common
> symbol versioning infrastructure in GCC instead of again duplicating
> what we already have in several runtime lib
Gerald Pfeifer wrote:
It is my pleasure to announce that the steering committee is
appointing Anthony Green as maintainer of the new Moxie port
that has been approved from a technical perspective as well.
Please adjust the MAINTAINERS file accordingly, Anthony, and
happy hacking! And of course
The top level configury suggests that you can simply drop gmp, ppl, etc
into the top level source dir and they will get configured and used.
Does this really work?
At the very least, I think ppl requires that gmp be configured with
--enable-cxx, like so:
Index: Makefile.def
==
On Fri, 2006-01-27 at 16:41 -0800, Per Bothner wrote:
> I.e. I'm hoping one can *statically* link ecj without any
> dependencies on (say) the SWT toolkit, or the debugger?
Yes, you can. And when references have crept in by mistake, the Eclipse
guys were pretty quick about removing them.
BTW, the
On Tue, 2005-11-29 at 13:01 -0800, Richard Henderson wrote:
> On Tue, Nov 29, 2005 at 12:42:36PM -0800, Mark Mitchell wrote:
> > RTH is listed as the author of a lot of those bits, so perhaps he knows
> > more?
>
> The glibc bits handle ieee quad format, whereas I don't believe
> that Torbajorn's
On Mon, 2005-11-28 at 18:05 -0800, Mark Mitchell wrote:
> That message contains an IEEE floating-point emulation library, like
> fp-bit.c. Howeve, the performance is considerably better; Joseph
> measured against fp-bit.c with a modern compiler, and ieeelib.c is about
> 10-15% better than the curr
20 matches
Mail list logo
