s://sourceware.org/pipermail/binutils/2000-November/007873.html
and thence to https://github.com/chaos4ever/chaos
John
em as suck? Or
are they real failures of the analyzer?
see also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113150
Although I xfail'ed the tests on HPUX, I left the bug open.
Dave
--
John David Anglin dave.ang...@bell.net
Please remove me from the mailing lists
fort...@gcc.gnu.org
and
gcc-patc...@gcc.gnu.org
or show me how to remove myself from these lists.
Thank you
--
John Koval
859 Waterloo St
London Ontario Canada N6A 3W7
519-439-5349
On Thu, Aug 5, 2021, at 8:30 AM, Michael Matz wrote:
> Hello,
>
> On Wed, 4 Aug 2021, John Ericson wrote:
>
> > On Wed, Aug 4, 2021, at 10:48 AM, Michael Matz wrote:
> > > ... the 'as' and 'ld' executables should be simply found within the
>
--- i.e. at most 1
target-disambiguating method is used at a time.
I now have some patches for this change I suppose I could also submit.
Cheers,
John
On Wed, Aug 4, 2021, at 3:32 AM, Jonathan Wakely via Gcc wrote:
>
> Doesn't GCC automatically look for those commands in the --prefix directory
> that you configure GCC with? Or is that only for native compilers?
>
It will search only if --with-*=... was not passed, and it will never prefix
the
e prefixed.
Per [1], Clang does in fact look up prefixed exes against -B across the board.
Making GCC look up exes that same way seems like a fine solution too.
What do you all think?
John
[1]:
https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-b-prefix
bmit, I figured I should ask about the openness to such
a change.
Thanks,
John
[1]: I hope it's OK to email both lists at once like this; this is a question
about a change that I think only makes sense if both projects approve.
[2] Nixpkgs, https://github.com/nixos/nixpkgs/
[3]: https:
ote: while referencing
'bcdacc'
184 | uByte bcdacc[(DIVOPLEN+1)*9+2]; /* for quotient in BCD, +1, +1 */
| ^~
make[2]: Leaving directory
'/home/glaubitz/gccrs/build/powerpc-unknown-linux-gnu/libgcc'
make[1]: *** [Makefile:13143: all-target-libgcc] Error
41;344;0cOn Sun, Apr 11, 2021 at 07:30:13PM -0300, Adhemerval Zanella via Gcc
wrote:
And there was no hate (at least not from my side) only *disappointment*
that you used your status to do it even though most of senior developers and
maintainers said explicitly you shouldn’t do it.
I
Hey there,
I wanted to contact you about how we can work together linkbuilding.
Would you be open to the idea?
- John
On Sun, Apr 11, 2021 at 09:30:48AM -0400, Richard Kenner via Gcc wrote:
> > When it comes to deciding the direction of a project like GCC -
technical
> > and otherwise - in my mind it primarily should be those actually
involved
> > and contributing.
>
> GNU follows the
On Sun, Apr 11, 2021 at 12:30:41AM +0200, Gerald Pfeifer wrote:
There are a number of people arguing here who have contributed little
to nothing to GCC, whose names even did not trigger memories - unlike
David M. or Jonathan, for example, or Nathan or Alexandre.
For myself, I hav
On Sat, Apr 10, 2021 at 01:50:42PM +0100, Bronek Kozicki via Gcc wrote:
I would
very much prefer if a person who openly expressed opinions, and also openly
exercised behaviours, which I consider abhorrent, was *not* associated with
the GCC project. It does not matter to me
On Fri, Apr 09, 2021 at 07:01:07PM +0200, David Brown wrote:
Different opinions are fine. Bringing national or international
politics into the discussion (presumably meant to be as an insult) is
not fine. This is not a political discussion - please stop trying to
make it
On Thu, Apr 08, 2021 at 09:35:23PM -0400, David Malcolm wrote:
> RMS was the first person to be involved in GNU and GCC. Others
> became
> involved later (under his leadership). Their contribution was and
> continues to be welcome. They are also free to stop contributin
On Thu, Apr 08, 2021 at 10:54:25AM -0400, David Malcolm wrote:
I think it's important to distinguish between the figurative and
literal here.
No one is literally calling for anyone's head.
Nobody has explicitly done so. However in the last 2 or 3 years there
has been a
On Thu, Apr 08, 2021 at 07:56:14AM -0400, Richard Kenner wrote:
> Having one guy at the top from whom all power flows.
>
> Power does not "flow" from RMS. Since you have used a political analogy:
> I think it is more akin to a constitutional monarchy.
I think i
On Wed, Apr 07, 2021 at 06:34:12PM -0400, David Malcolm wrote:
>
> What you're describing sounds like a dictatorship to me.
>
> I cannot see how you reach that conclusion.
Having one guy at the top from whom all power flows.
Power does not "flow" fro
On Wed, Apr 07, 2021 at 11:15:14AM -0400, David Malcolm via Gcc wrote:
> It reflects the same message that has been sent to new GNU
> maintainers
> for the decades. The GNU structure and organization document
> (https://www.gnu.org/gnu/gnu-structure.en.html) is basically a
see if you can throw/catch exceptions between code
> compiled by your llvm port and a gcc
Perfect, thanks.
> hope that helps.
I'll give it a try.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
ontent.com/llvm/llvm-project/master/llvm/lib/Target/X86/X86ISelLowering.cpp
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Hi Nathan!
On 9/29/20 7:58 PM, Nathan Sidwell wrote:
> On 9/29/20 11:22 AM, John Paul Adrian Glaubitz wrote:
>>
>> I'm looking for an information regarding exception handling on Linux/m68k,
>> in particular
>> I need to know what registers are used by t
fo.td#L151
> [4] https://github.com/gcc-mirror/gcc/blob/master/gcc/config/m68k/m68k.h#L741
> [5]
> https://github.com/M680x0/M680x0-mono-repo/blob/master/llvm/lib/Target/M680x0/M680x0RegisterInfo.td
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub
https://www.bountysource.com/issues/84630749-avr-convert-the-backend-to-mode_cc-so-it-can-be-kept-in-future-releases
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0
Hi!
On 5/25/20 2:56 PM, John Paul Adrian Glaubitz wrote:
>> I'm thinking about attempting to do the CC0 transition for the
>> AVR port in my spare time. I've read the CC0Transition gcc wiki
>> page, and as the AVR ISA does not have non-condition-code
>>
9-avr-convert-the-backend-to-mode_cc-so-it-can-be-kept-in-future-releases
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
you are reducing the
number of open bug reports and you can somehow claim you fixed a bug.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
> misleading.
If you don't accept my opinion, why did you ask for it in the first place.
Please do whatever you want. I will still continue to contribute to GCC
and start BountySource campaigns to support, despite my opinion not being
of any relevance.
Thanks,
Adrian
--
.''`. Joh
e removed code, so
I don't really understand what you gain by closing bugs? Is it important
to keep the number of open issues low?
I don't consider bug reports a bad thing, they document the code quality
and are a useful resource to anyone working on the code or using these
versions.
Adria
it doesn't really work yet. I think finishing LLVM for m68k would be another
idea for a Bountysource campaign.
Adrian
> [1] https://github.com/M680x0/M680x0-llvm/
> [2] https://www.vutbr.cz/en/students/final-thesis?zp_id=34902
> [3] https://github.com/glaubitz/rust/tree/m68k-linux
--
drian
> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91851
> [2]
> https://www.bountysource.com/issues/80706251-m68k-convert-the-backend-to-mode_cc-so-it-can-be-kept-in-future-releases
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.o
Hi
You can get a new payment in your personal account. You have to manage it right
away or it will be removed.
Go HERE To Confirm Your Payment Info Is Correct.
Registered email: g...@gnu.org
User ID: UEMG6C1SHB
Enjoy & please let me know if all is well.
Thanks!
Jeff
E Marketer
202
=sid
So gcc is tested regularly on ia64 and co and it's actively being used
to build the whole Debian archive.
Thanks,
Adrian
[1] https://gcc.gnu.org/ml/gcc/2019-06/msg00158.html
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `&
Hi,
I want to insert a new function `test_fn` in plugin and call it in `main`,
but got `undefined reference to `test_fn’ in `ld`. Can someone please give
any help? Thanks.
Here is the example code,
//== plugin.c
#include "gcc-plugin.h"
#include "plugin-version.h"
#include "
On Tue, Aug 20, 2019 at 08:56:39AM +0200, Richard Biener wrote:
> Most of these suggestions involve adding some sort of virtual registers
> So I hacked the machine description to add two new registers Z1 and Z2
> with the same mode as X and Y.
>
> Obviously the assembler b
On Mon, Aug 19, 2019 at 10:07:11AM -0500, Segher Boessenkool wrote:
> ? As I remember there were a few other ideas from Richard Biener and
> Segher Boessenkool.? I also proposed to add a new address register which
> will be always a fixed stack memory slot at the end. Unfortunatel
On Fri, Aug 16, 2019 at 10:50:13AM -0400, Vladimir Makarov wrote:
No I meant something like that
(define_special_memory_constraint "a" ...)
(define_predicate "my_special_predicate" ...
{
if (lra_in_progress_p)
return REG_P (o
On Thu, Aug 15, 2019 at 02:23:45PM -0400, Vladimir Makarov wrote:
> I tried this solution earlier. But unfortunately it makes things worse.
What happens is it libgcc cannot
> even be built -- ICEs occur on a memory from address reg insn such as:
> (insn 117 2981 3697 5 (set (mem
On Thu, Aug 15, 2019 at 06:38:30PM +0200, Richard Biener wrote:
Couldn't we spill the frame pointer? Basically we should be able to
compute the first address into a reg, spill that, do the second
(both could require the frame pointer), spill the frame pointer,
reload the first computed
On Thu, Aug 15, 2019 at 12:29:13PM -0400, Vladimir Makarov wrote:
Thank you for providing the sources.?? It helped me to understand what is
going on.?? So the test crashes on
/home/jmd/Source/GCC2/gcc/testsuite/gcc.c-torture/compile/pr53410-2.c: In
function ???f1???:
/
On Sat, Aug 10, 2019 at 11:12:18AM -0500, Segher Boessenkool wrote:
Hi!
On Sat, Aug 10, 2019 at 08:05:53AM +0200, John Darrington wrote:
> Choosing alt 5 in insn 14: (0) m (1) m {*movsi}
>14: [r40:PSI+0x20]=[r41:PSI]
> Inserting insn relo
On Fri, Aug 09, 2019 at 09:16:44AM -0500, Segher Boessenkool wrote:
Is your code in some branch in our git?
No. But it could be pushed there if people think it would be
appropriate to do so, and if I'm given the permissions to do so.
Or in some other public git?
It's in my rep
On Fri, Aug 09, 2019 at 01:34:36PM -0400, Vladimir Makarov wrote:
If you provide LRA dump for such test (it is better to use
-fira-verbose=15 to output full RA info into stderr), I probably could
say more.
I've attached such a dump (generated from
gcc/testsuite/gcc.c-torture/
On Thu, Aug 08, 2019 at 01:57:41PM -0600, Jeff Law wrote:
Yea, it's certainly designed with the more mainstream architectures in
mind. THe double-indirect case that's being talked about here is well
out of the mainstream and not a feature of anything LRA has targetted to
date.
I'm trying to write a back-end for an architecture (s12z - the ISA you can
download from [1]). This arch accepts indirect memory addresses. That is to
say, those of the form (mem (mem (...))) and although my
TARGET_LEGITIMATE_ADDRESS
function returns true for such addresses, LRA insists on
unsubscribe
On Mon, Jun 24, 2019, at 3:55 PM, 김규래 wrote:
> Hi,
> I'm not very familiar with the gomp plugin system.
> However, looking at 'GOMP_PLUGIN_target_task_completion' seem like
> tasks have to go in and out of the runtime.
> In that case, is it right that the tasks have to know from which
Hi Guys,
I guess back in July, the release of 8.3 was expected by the end of
2018. Now it's February. Is the next release of the 8 series imminent?
if not, any idea when it might come?
Thanks,
John
On Sun, Jul 22, 2018 at 03:24:48AM +0200, Carlo Pisani wrote:>
> On HPPA:
> - "gnatgcc" is not existing out of the debian pagkage(1)
> - gnat make calls "gcc-4.3"
> - the installed gcc (provided by gentoo) can't compile ada-files
> - since the compiler was compiled with languages=C,C++,Fortran
>
https://buildd.debian.org/status/fetch.php?pkg=gcc-8&arch=powerpcspe&ver=8-20180402-1&stamp=1522856967&raw=0
Is there anything in the powerpcspe port that is currently making life for
the users or developers of other code harder?
Thanks,
Adrian
--
.''`. John Pa
e new patch has been in use for months, I was
still thinking it caused the test failures.
Thanks for piping up, Eric! :)
John
P.S. I'll post the dragonfly-specific unwind patch to the patches mail
list later today. It's been tested internally for weeks.
t;
> Like void, f.ex.
Wait. Do you think this would actually allow ghc to determine the
return type later? If I remember correctly, ghc currently initially
declares the function prototype with return type void*, doesn't it?
Adrian
--
.''`. John Paul Adrian Glaubitz
this as crap code.
^
But I don't want to argue anyway. I was assuming ppc64le might have
similarities to m68k in that regard.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Univers
On 01/26/2016 11:07 AM, Andreas Schwab wrote:
> John Paul Adrian Glaubitz writes:
>
>> Having gcc allow to work with such code would actually allow us
>> to bootstrap ghc on m68k again which would be awesome :).
>
> The ghc code just needs to be fixed to not lie in su
would you actually favor the inclusion of Michael's changes?
Having gcc allow to work with such code would actually allow us
to bootstrap ghc on m68k again which would be awesome :).
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `&
ubmitting the PR gets to set the severity field, it
should be dropped. If anybody sets the severity, it should be the
people *doing* the triage or the person to whom the PR is eventually
assigned.
John
On 9/21/15 4:45 PM, H.J. Lu wrote:
On Mon, Sep 21, 2015 at 11:52 AM, John Criswell wrote:
On 9/21/15 12:27 PM, H.J. Lu via cfe-dev wrote:
On Thu, Sep 17, 2015 at 12:26 PM, H.J. Lu wrote:
On Tue, Sep 15, 2015 at 1:11 PM, H.J. Lu wrote:
To implement interrupt and exception handlers for x86
o see if it is worth adding complexity to the compiler.
Regards,
John Criswell
--
John Criswell
Assistant Professor
Department of Computer Science, University of Rochester
http://www.cs.rochester.edu/u/criswell
p_insn (CODE_FOR_indirect_jump, 1, ops);
emit_barrier ();
#endif
}
but I think testing HAVE_indirect_jump (-> targetm.have_indirect_jump ())
is more correct.
Would it be OK to remove the operands[] condition? Or should/could it be a
pmode_register_operand instead of a register_operand?
Thanks,
Richard
--
John David Anglin dave.ang...@bell.net
ssible to do a 64-bit bootstrap on
hppa-linux-gnu since there
is no glibc or kernel support for 64-bit runtime. The 64-bit compiler is built
as a cross and just
used to build 64-bit kernels. 32-bit bootstrap should work fine. "Full"
64-bit support is only
available on hpux11.
r-intuitive and
confusing. I also think this should be fixed properly, and ripping off
the band-aid seems reasonable to me.
Regards,
John
stion to go rename everything consistently and
accurately.
Sorry about butting in, but I thought that my recent experience with
this might be relevant to the topic.
John
ation,
or known to be executed a million times per invocation.
John.
On 02/12/14 10:23, Richard Biener wrote:
> On Tue, Dec 2, 2014 at 12:11 AM, shmeel gutl
> wrote:
>> While testing my implementation of passing arguments in
>> registers, I noticed that gcc 4.7 creates instructi
CC_ATOMIC_INT_LOCK_FREE = 2, etc.
Have to see if this works with our library functions :-
Dave
--
John David Anglindave.ang...@bell.net
On 1-Jul-14, at 4:40 AM, Matthias Klose wrote:
Looks like more than one issue is involved, I remember that the
math symbols were already dropped in earlier versions for other
architectures. The build is configured -with-long-double-128.
Long double is 64 bits on hppa-linux.
Dave
--
John
y define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4, etc, in
pa-linux.h. I'll experiment with defining ATOMIC_INT_LOCK_FREE there.
Thanks,
Dave
--
John David Anglin dave.ang...@bell.net
#gcc chatroom too.
John T
http://www.mozilla.org Firefox browser, Thunderbird email, Seamonkey
all-in-one, Sunbird calendar and more. Free open-source software for Windows,
Linux, Mac OS and other systems
this change as I know this causes support issues. The HP
ansi
C compiler and aCC have long long. This is not an issue for linux. I
believe
people can find HP-UX GCC binaries on the net.
Dave
--
John David Anglin dave.ang...@bell.net
ber but without ansi support one needs to start with
an early 4.X version.
Dave
--
John David Anglindave.ang...@bell.net
c discussion because answering yes or no changes
nothing, but I think the majority of the people would give it a
different file name if they could do it all over again. It's not a big
concession.
John
discuss as well.
John Ward
AMD Organization Relations
888-319-6336 x707 (by appointment only please)
Alt: j.w...@americanmediad.com <mailto:j.w...@americanmediad.com>
http://www.americanmediadistribution.com
American Media Distribution
4057 US Hwy 9 North
Howell NJ 07731
An Internationa
eatly appreciated.
Thanks,
John Lu
On 06/01/2013 11:45 AM, Jens Taprogge wrote:
On Sat, Jun 01, 2013 at 05:37:05PM +0200, Jens Taprogge wrote:
On Fri, May 31, 2013 at 05:16:49PM -0700, John Stultz wrote:
On 05/31/2013 04:42 PM, Jens Taprogge wrote:
On Fri, May 31, 2013 at 02:14:47PM -0700, John Stultz wrote:
Ok. None of this
On 6-Apr-13, at 3:16 PM, Steven Bosscher wrote:
On Sat, Apr 6, 2013 at 7:09 PM, John David Anglin wrote:
On 6-Apr-13, at 12:25 PM, Steven Bosscher wrote:
Are there any reasons against removing !TARGET_BIG_SWITCH support?
It
would really help if this code can go away...
Yes, branch
thrash. This occurs on machines with
shared
instruction and data TLBs. Would this help?
Dave
--
John David Anglin dave.ang...@bell.net
"cpmpilation"
probably meant "compilation"
On 12/13/2012 13:32, Steven Bosscher wrote:
On Thu, Dec 13, 2012 at 1:21 PM, John Marino wrote:
Which clause are you invoking to remove it from the primary tier list?
Richard claimed "they are not at all happy with GPLv3". That's not a reason
listed on your reference. He al
not quantified so no way to defend
accusations of being not popular enough). GCC is certainly "frequently
used" on FreeBSD so that's not in violation.
John
On 12/13/2012 12:38, David Brown wrote:
On 13/12/2012 12:24, Steven Bosscher wrote:
On Thu, Dec 13, 2012 at 11:43 AM, John Marino wrote:
I don't speak for FreeBSD, but dropping them from Tier 1 support because
they don't use a GPLv3 *BASE* compiler is a bit vindictive.
FreeBSD h
as for i486. I don't know about NetBSD or OpenBSD.
I don't speak for FreeBSD, but dropping them from Tier 1 support because
they don't use a GPLv3 *BASE* compiler is a bit vindictive.
John
stly in which insn is "in
charge". */
+ (the RT is the only known exception at this point). */
#include "config.h"
#include "system.h"
Dave
--
John David Anglin dave.ang...@bell.net
Section I-3 in PA-RISC 2.0
Architecture).
;;- See file "rtl.def" for documentation on define_insn, match_*,
et. al.
Dave
--
John David Anglin dave.ang...@bell.net
g.
I'd appreciate comments on how difficult phase 1 would be.
John Nagle
strict mode,
and would wring out the concept.
Think of it as FORTIFY on steroids. It can do the parameter
checks FORTIFY does, but for any function with an array parameter
and a size. It's not limited to a built-in list of the usual
suspect functions.
John Nagle
On 9/2/2012 1:12 AM, Florian Weimer wrote:
> * John Nagle:
>
>>We have proposed an extension to C (primarily) and C++ (possibly)
>> to address buffer overflow prevention. Buffer overflows are still
>> a huge practical problem in C, and much important code is still
>
On 9/1/2012 9:59 AM, James Dennett wrote:
> On Fri, Aug 31, 2012 at 2:55 PM, John Nagle
> wrote:
>> We have proposed an extension to C (primarily) and C++ (possibly)
>> to address buffer overflow prevention. Buffer overflows are still
>> a huge practical problem in C,
person there (having had them included in a pre-meeting mailing), if
> you want a wider range of implementer opinions.
That may happen, but I'm still getting comments informally at
this point. I'd like to see enough of this implemented in GCC
as an extension that people could try it out.
John Nagle
Animats
ld
be migrated to strict mode from the bottom up. First
standard libraries, then security-critical libraries,
then security-critical applications.
What I'd like for now is an an estimate of how hard this would
be to implement in GCC. Most of the necessary features, or
something close to them, are
compiling and running the same program with std=f95
three times.
On Thu, 5 Jul 2012, John Harper wrote:
Date: Thu, 5 Jul 2012 11:38:39 +1200 (NZST)
From: John Harper
To: gcc@gcc.gnu.org
Subject: Two gfortran bugs
My program testpublic5.f90 (see below) when compiled with -std=f95
using gfortran
h --with-gmp=/local/scratch
Thread model: posix
gcc version 4.8.0 20120701 (experimental) (GCC)
cayley[~/Jfh] %
cayley[~/Jfh] % gf -std=f95 testpublic5.f90
testpublic5.f90:18.22:
character name*63 ! Max length of a name in f2003
1
Warning: Obsolescent feature: Old-style cha
ou were going to make
a proposal to the GCC list, I was under the impression that we'd
reached some level of consensus.
John.
ot; here. The ABI does not allow us to emit these
symbols with non-coalescing linkage. We're not going to break ABI
just because people didn't consider a particular code pattern when they
hacked in devirtualization through external v-tables.
John.
y be emitted in arbitrary
other translation units — we cannot change the ABI to say that these
symbols are *only* emitted in the file defining the v-table.
Finally, both the language standard and the ABI are clearly designed
around an assumption that every translation unit that needs an inline
function will emit it.
John.
and user code to link against
libatomic.
So, I'm not sure this is an improvement.
The sync builtins aren't supported on hpux.
Dave
--
John David Anglindave.ang...@bell.net
http://blog.regehr.org/archives/697
John
(float:SF (match_dup 2)))]
"TARGET_PA_11 && ! TARGET_SOFT_FLOAT"
"
{
if (TARGET_PA_20)
{
emit_insn (gen_floatunssisf2_pa20 (operands[0], operands[1]));
DONE;
}
operands[2] = gen_reg_rtx (DImode);
}")
TARGET_PA_20 implies TARGET_PA_11.
Dave
--
John David Anglindave.ang...@bell.net
On 5/7/2012 2:29 PM, Jeff Law wrote:
On 05/07/2012 12:25 PM, John David Anglin wrote:
There is also a 32-bit netbsd port that a limited number of users are
still using.
Do you know if they're using the open-sourced SOM linker or the 32 bit
ELF stuff?
ELF.
PA linux runs on both PA 1.
;t think the effort is worth it and would prefer to
spend my time working
on new features like movmisalign support.
Dave
--
John David Anglindave.ang...@bell.net
s.
The resulting PA port would support HP-UX11 on 64bits PA-RISC 2.0
(i.e. HP-PA8xxx).
It's hard enough to maintain HP-UX11 support on HP-PA. With this
cleanup, the job would become a bit simpler.
Thoughts/comments?
Ciao!
Steven
Dave
--
John David Anglindave.ang...@bell.net
ib/ld-linux.so.2 /usr/lib/crt1.o
/usr/lib/crti.o /tmp/gf/lib/gcc/i686-pc-linux-gnu/4.6.2/crtbegin.o
-L/tmp/gf/lib/gcc/i686-pc-linux-gnu/4.6.2
-L/tmp/gf/lib/gcc/i686-pc-linux-gnu/4.6.2/../../.. /tmp/ccGzx8Uk.o
-lgfortran -lm -lgcc_s -lgcc -lquadmath -lm -lgcc_s -lgcc -lc -lgcc_s
-lgcc /t
1 - 100 of 272 matches
Mail list logo
