iberty] Error 1
make[1]: Leaving directory `/home/rupp/ngnat/buildxppcaix'
make: *** [all] Error 2
--Douglas B Rupp
AdaCore
DJ Delorie wrote:
Is your target a newlib target? If so, are you including --with-newlib?
Thanks, that was the problem.
Why isn't --with-newlib the default for newlib targets?
DJ Delorie wrote:
Why isn't --with-newlib the default for newlib targets?
--with-newlib *tells* us that it's a newlib target.
Well not knowing what a newlib target was when you asked, I looked in
configure.in.
It seems that if it's not a newlib target then target-newlib is missing
from n
Andrew Haley wrote:
Douglas B Rupp writes:
> DJ Delorie wrote:
> > Is your target a newlib target? If so, are you including --with-newlib?
> >
>
> Thanks, that was the problem.
> Why isn't --with-newlib the default for newlib targets?
AIX is a newlib targe
Jim Wilson wrote:
Inside the gcc configure,
we do "test -x $NM_FOR_TARGET" and this fails because NM_FOR_TARGET
expands to more than a program name, and the shell test -x command does
not handle this case. We need to extract out the program name for this
test. This should be easy enough to d
Did someone forget to tell you that AIX 4.3 and above are not really
supported by the GNU binutils anyways? So it is kinda of useless to
have a cross compiler which does not work anyways :).
I emailed the maintainer on this subject when I started this project but
never got a reply. It seems
Jim Wilson wrote:
Douglas B Rupp wrote:
I'm happy to try writing a patch, but my version of gcc/configure
doesn't look like what you described.
I tried a build with the gcc-4.1.x branch, and gcc/nm is computed
correctly, so the problem I described on mainline does not
> And there were discussions about command line length problems in the GCC
build process on VMS.
The problem on VMS is not so much total command line length as element
length, e.g. strlen (argv [x]). A single element cannot exceed 1024
characters or something like that (have to look it up to b
This is a reproducer for a problem we have with fixincludes on
vxworks6.6. The desired output is
FOO= 1
The problem is the rules for handling headers enclosed in quotes can
cause gcc to #include the original header not the patched header.
It seems like a problem that could theoretically oc
Joseph S. Myers wrote:
* Interix (i[34567]86-*-interix3*) (see PR 47096).
I would appreciate it if you could leave Interix. I'll take the
responsibility to get it working.
Joseph S. Myers wrote:
On Mon, 14 Feb 2011, Douglas B Rupp wrote:
Joseph S. Myers wrote:
* Interix (i[34567]86-*-interix3*) (see PR 47096).
I would appreciate it if you could leave Interix. I'll take the responsibility
to get it working.
The deprecation patch has gone in. That means
Richard Henderson wrote:
On 07/12/2009 12:30 PM, Douglas B Rupp wrote:
There really are multiple epilogues. The compiler is quite happy to
generate those, and has been happy to do so for some time.
What has changed is that we're now bothering to tell the debug info
about these epi
LEB0 and LEB1 are duplicated in the attached ivms assembly file from
libgcc2. Note the first occurrence of each is at the prologue end,
which makes no sense to me.
FYI: I'm emitting the LPE labels at NOTE_INSN_FUNCTION_BEG and the LEB
labels at NOTE_INSN_EPILOGUE_BEG. I can send you the full
Richard Henderson wrote:
On 07/15/2009 05:27 PM, Douglas B Rupp wrote:
LEB0 and LEB1 are duplicated in the attached ivms assembly file from
libgcc2. Note the first occurrence of each is at the prologue end, which
makes no sense to me.
FYI: I'm emitting the LPE labels at NOTE_INSN_FUNCTIO
AdaCore has been maintaining the IVMS and AVMS ports for many years and
would like to submit our patches.
The patches consolidate the common parts of AVMS and IVMS into a new
config/vms directory. Since IVMS is a new port I believe the rules allow
it to be submitted all at once, but it does re
Greetings,
A pointer would be much appreciated!
In ia64.md for *cmpdi_normal this is found:
"cmp.%C1 %0, %I0 = %3, %r2"
Where are %C, %I, %r described?
--Doug
I'm stuck on this, A hint, a pointer to some code to look at would be
helpful.
The emit_move_insn gets a GCC error.
This is an intrinsic I'm working on for GNAT on Alpha/VMS.
Success is a system.address parameter in the intrinsic containing
"success_flag'address" where success_flag is a boole
I've been working on bringing the VMS patches up to date. The VMS
Debugger requires a label at end prologue and begin_epilogue, and the
fact that final_scan_insn makes multiple calls to NOTE_INSN_EPILOGUE_BEG
for the same function makes this awkward. I suppose it could be case
that there are
I can no longer make check ins to the gcc repository, it's been a few
months since my last check in, which worked fine.
I get:
ssh: connect to host gcc.gnu.org port 22: Connection refused
svn: Connection closed unexpectedly
anonymouse access works fine.
I'm "r...@gcc.gnu.org"
If someone cou
This bogus size of -1 is causing an informational warning from VMS Debug
on IA64 VMS. It would be useful to us if approved and merged.
--Douglas Rupp
AdaCore
The HP debugger on IA64 VMS defines a new Dwarf2 attribute that computes the
offset of the end of the prologue from the beginning of the function. To
implement this an end prologue label must be emitted and some related info
saved in dwarf2out.c.
However I've noted that calling debug_hooks->end_p
Yes, easy fix. An enhancement to config/vms/vms.opt is needed for the
missing variable. I'll get it sorted out.
--Doug
On 03/06/2014 05:35 PM, Jan-Benedict Glaw wrote:
Hi Doug!
Your recent VMS change committed by Arnaud Charlet won't build, see
eg. build log [1] for build #154768 [2], which
This impediment to the build should be fixed now.
On 03/06/2014 05:35 PM, Jan-Benedict Glaw wrote:
Hi Doug!
Your recent VMS change committed by Arnaud Charlet won't build, see
eg. build log [1] for build #154768 [2], which is targeted to
alpha64-dec-vms:
VxWorks7 has introduced an incompatible unwind.h header file that
conflicts with gcc's unwind.h (which is a build time header file linked
to the appropriate source header).
I'd like to propose renaming gcc's unwind.h to unwind-gcc.h
There are 54 occurrences in the gcc source tree, including
On 04/14/2014 02:01 PM, Ian Lance Taylor wrote:
You may have failed to consider that unwind.h is installed and can be
#include'd by any program that is built with GCC. Renaming the
installed file will break an unknown number of existing programs.
Ian
No I considered that but I think that num
On 04/16/2014 12:38 PM, Eric Botcazou wrote:
Because GCC would then be already incompatible with the Intel compiler from
which this interface was drawn, way back when the ia64 support was added to
GCC and we redesigned GCC's exception handling.
The irony being that WindRiver is now owned by Int
On 04/16/2014 12:55 PM, Richard Henderson wrote:
Is it a (reasonably) close match, interface-wise? Ought we be using
--with-system-libunwind for VxWorks7, like we do for hpux?
It looks reasonable at first glance, but there's a disturbing comment in
the code something to the effect:
until w
On 04/16/2014 05:56 PM, Ian Lance Taylor wrote:
I'm still not clear on what the real problem is.
It seems to me that when using GCC, if you #include , you
will get the GCC version, since it will come from the installed
GCC include directory, which is searched ahead of /usr/include. That
seems
28 matches
Mail list logo
