ature under the sun. That doesn't mean that
anyone is actually _using_ them these days.
Is "staging" still a thing? Maybe we should move these drivers into the
staging directory and pick a release where we'll sunset it, and then see
who comes out of the woodwork?
Cheers,
--
Jeff Layton
gcc-bugs database.
I know someone (probably Andreas) with some work was able to get GCC
working with Ada. However, they didn't push to get all those changes
upstreamed.
It's one of the reasons why I think we should at least explore a more a
solution within GCC iteslf.
Jeff
portable to be used on function pointers on all architectures gcc
supports. Furthermore, this hides the fact that the use case is not
supported by playing games with the optimizer, whereas Jeff and Richard
try to get this use case supported.
If gcc decides that the m68k backend should not be adjusted
roject, but one positive vote
against two doubtful or negative votes is not what I would call "consensus".
Given overall contribution history within the GCC project, Richi and
myself carry more weight than Thorsten & Andreas.
jeff
? Does ppc64el actually have separate address
and data registers?
Ignore other targets. There's nothing really shared across them when it
comes to the low level implementation details of an ABI like this.
jeff
somehow get at the actual
DECL called.
I think that's a good thing -- however, I suspect there's m68k backend
issues that need to be addressed here. So I think we're roughly on the
same page.
jeff
e ill-formed to a
certain degree.
jeff
e the case that we're not doing this properly
for indirect calls from a quick scan of m68k_function_arg.
The only way to know for sure would be to examine it under the debugger.
Jeff
Looking for cheap high-quality software?
http://nxdpl.k96hnj2vzckrhl2.cahowci.com
An idea isn't responsible for the people who believe in it.
The future is here. It's just not widely distributed yet.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Troub
1. Update from binutils 2003 0121.
2. Fix an ia64 gas bug.
3. Fix some TLS bugs.
4. Fix some ELF/ppc bugs.
5. Fix an ELF/m68k bug.
Tks,
Jeff Bailey
I haven't seen mention of it on this list, so I wanted to bring it up -
Bug #175526 against glibc is m68k specific. None of the current Debian
Glibc folks are strongly versed in m68k. Is there a porter available to
take a look at it?
Tks,
Jeff Bailey
sn't in CVS yet, and I have no idea
what's up with Sparc. So it doesn't seem like post of the arch bugs are
in CVS right now. I hope we can change that, though.
Let's see how necessary it is. We can always do a CVS pull after this
upload.
Tks,
Jeff Bailey
done before my wife wakes up and demands the computer. =)
Tks,
Jeff Bailey
On Mon, Sep 09, 2002 at 10:41:45PM -0400, Ben Collins wrote:
> > sparc:
> Sparc is me. Getting it tonight.
Ah, thanks. I wasn't sure if you had time for it these days. Lemme
know if I can help with anything.
Tks,
Jeff Bailey
--
At last you cry out in anguish: "Why me?
Fellow porters,
Your Glibc maintainer team is trying to get glibc 2.3 ready for
general consumption, and we need some help for arch's that we're not
familiar with. So far we have the following covered:
i386: Jeff Bailey, GOTO Masanori
hurd-i386: Jeff Bailey
ppc: Jack Howawth
a
;
# Add necessary new display entries to .Xauthority file.
xauth -v add "${eth0}:${xdpnum}" "${access}" "${mcookie}"
xauth -v add "${host}:${xdpnum}" "${access}" "${mcookie}"
xauth -v add "${host}/unix:${xdpnum}" "${access}" "${mcookie}"
Why does anyone need to read megabytes of urandom? If it really
is random, then 16 bytes should be enough.
--
Jeff Sheinberg
16 matches
Mail list logo
