On Wed, Jan 12, 2011 at 8:27 AM, Ian Lance Taylor wrote:
> Gidi Nave writes:
>
>> On Tue, Jan 11, 2011 at 7:22 PM, Ian Lance Taylor wrote:
>>> Gidi Nave writes:
>>>
On Tue, Jan 11, 2011 at 5:34 PM, Ian Lance Taylor wrote:
> So why doesn't d1 = d1 + -96 match the last instruction
On Wed, Jan 12, 2011 at 4:10 AM, Jie Zhang wrote:
> Dear Steering Committee:
>
> The current listed maintainer for option handling is:
>
> option handling Neil Booth n...@daikokuya.co.uk
>
> But I'm wondering if Neil is still active. There are no replies to my recent
> pings f
On 01/12/2011 06:07 PM, Richard Guenther wrote:
On Wed, Jan 12, 2011 at 4:10 AM, Jie Zhang wrote:
Dear Steering Committee:
The current listed maintainer for option handling is:
option handling Neil Booth n...@daikokuya.co.uk
But I'm wondering if Neil is still active. The
First, the problem: I've got a C library I want to share. There are
many users who want to use it. This should be as easy as breathing,
but it's not!
My users and I face what I'm calling "GNU/Linux Innovation Red Tape".
This library is two files: sonic.c and sonic.h. To share it in
Debian, fir
On Wed, Jan 12, 2011 at 06:07:48AM -0500, Bill Cox wrote:
> Unfortunately, while I could implement this idea in a few days, the
> red tape would keep it in limbo so long that I'll likely die of old
> age before it gets into Debian Stable. Oh, well... here's the dumb
> idea anyway... In short, sup
On Wed, 12 Jan 2011, Robert Millan wrote:
> Hi Joseph
>
> I'll look at more detail at the other problems, but first it
> seems that non-Linux GNU targets are currently broken
> because many declarations that are not Linux-specific
> have been added to the Linux-specific sections of
> config.gcc.
2011/1/12 Joseph S. Myers :
> I don't think they are necessarily broken - and if they are, it is because
> of Linux-specific headers being used in non-Linux-specific code, not the
> other way round.
Actually, it's a different problem. I'll just prepare a patch and
send it, it'll be obvious by rea
2011/1/12 Bill Cox :
> $ gcc myprog.c -lgit://github/~waywardgeek/sonic=0.1
You already have this, it's called FUSE. E.g.
$ sshfs $publicrepo $tmp
$ gcc myprog.c -I$tmp $tmp/sonic.c
If you want it to speak GIT protocol, just write a GIT
extension, etc.
--
Robert Millan
Hi,
On Wed, Jan 12, 2011 at 01:43:51PM +0100, Basile Starynkevitch wrote:
> On Wed, Jan 12, 2011 at 06:07:48AM -0500, Bill Cox wrote:
> > Unfortunately, while I could implement this idea in a few days, the
> > red tape would keep it in limbo so long that I'll likely die of old
> > age before it get
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/12/11 01:45, Gidi Nave wrote:
>
> One more question:
> GCC usually knows how to handle cases which need decomposition of
> expressions due to architecture limitations.
> In my case it didn't know.
> How can I foreseen additional such cases, in
2011/1/1 Joseph S. Myers :
> [...] I found
> several possible problems with the configurations for *-kfreebsd-gnu,
> *-knetbsd-gnu and *-kopensolaris-gnu.
Ok. Unless indicated otherwise, my answers below apply to
*-kfreebsd-gnu, which is the only in these 3 systems that is
actively maintained.
F
On Wed, Jan 12, 2011 at 8:43 AM, Axel Freyn wrote:
> Hi,
> On Wed, Jan 12, 2011 at 01:43:51PM +0100, Basile Starynkevitch wrote:
>> On Wed, Jan 12, 2011 at 06:07:48AM -0500, Bill Cox wrote:
>> > Unfortunately, while I could implement this idea in a few days, the
>> > red tape would keep it in limb
On 12/01/2011 12:07, Bill Cox wrote:
First, the problem: I've got a C library I want to share. There are
many users who want to use it. This should be as easy as breathing,
but it's not!
My users and I face what I'm calling "GNU/Linux Innovation Red Tape".
This library is two files: sonic.c a
On Wed, Jan 12, 2011 at 3:50 PM, Jeff Law wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 01/12/11 01:45, Gidi Nave wrote:
>
>>
>> One more question:
>> GCC usually knows how to handle cases which need decomposition of
>> expressions due to architecture limitations.
>> In my case i
On Wed, 12 Jan 2011, Robert Millan wrote:
> > * These configurations use file_end_indicate_exec_stack to use the
> > PT_GNU_STACK convention. While some of the implementation of this
> > is in the GNU linker and glibc, it also requires kernel support for
> > correct operation. Do all these ke
On 12 January 2011 14:07, Bill Cox wrote:
>
> Well, after a short nap, the thought of fixing this in gcc seems even
> dumber to me, though the problem is quite real. Another tool called
> before gcc could get the header and library files into a place where
> they could be used. It could even be c
Hi all,
I'm in the early stages of a Leon-based project, and have been trying to put
together a cross toolchain for it. I'm having some problems getting it
configured and working correctly, and this proposed option would very likely
help me a lot.
Is there any time scale for implementation, o
Hello all.
I have a idea for automatic generation of headers in a c++ program.
Having to maintain headers is a very time consuming task, and I think
we will all benefit from such a thing. The idea is the following:
Each time the compiler finds the pragma
#pragma autoinclude("foo.hpp")
it does t
Robert Millan writes:
> I'm not familiar with PT_GNU_STACK. Does a working
> _dl_make_stack_executable() in glibc [1] indicate it's supported?
>
> [1]
> http://svn.debian.org/viewsvn/glibc-bsd/trunk/glibc-ports/kfreebsd/dl-execstack.c?revision=1685&view=markup
PT_GNU_STACK is a program header
On 12/01/2011 13:50, Jeff Law wrote:
> On 01/12/11 01:45, Gidi Nave wrote:
>
>> One more question:
>> GCC usually knows how to handle cases which need decomposition of
>> expressions due to architecture limitations.
>> In my case it didn't know.
>> How can I foreseen additional such cases, in ord
On 12/01/2011 16:22, Achilleas Margaritis wrote:
Hello all.
I have a idea for automatic generation of headers in a c++ program.
Having to maintain headers is a very time consuming task, and I think
we will all benefit from such a thing. The idea is the following:
Each time the compiler finds th
Bill Cox writes:
> $ gcc myprog.c -lgit://github/~waywardgeek/sonic=0.1
In Go we have a program goinstall which looks at import statements and
pulls in required libraries, where the libraries are named based on
where the sources live. A similar process could work in the C/C++
world, based o
Achilleas Margaritis writes:
> I have a idea for automatic generation of headers in a c++ program.
> Having to maintain headers is a very time consuming task, and I think
> we will all benefit from such a thing. The idea is the following:
>
> Each time the compiler finds the pragma
>
> #pragma au
On 01/12/2011 09:17 AM, David Paterson wrote:
Hi all,
I'm in the early stages of a Leon-based project, and have been trying to put
together a cross toolchain for it. I'm having some problems getting it
configured and working correctly, and this proposed option would very likely
help me a lot
* Ian Lance Taylor:
> Bill Cox writes:
>
>> $ gcc myprog.c -lgit://github/~waywardgeek/sonic=0.1
>
> In Go we have a program goinstall which looks at import statements and
> pulls in required libraries, where the libraries are named based on
> where the sources live. A similar process could
2011/1/7 Chung-Lin Tang :
> I analyzed this testcase regression a while earlier; the direct cause of
> this is due to mips_order_regs_for_local_alloc(), which now serves as
> MIPS' ADJUST_REG_ALLOC_ORDER macro.
>
> The mips_order_regs_for_local_alloc() function seems to be written for
> the old loc
26 matches
Mail list logo
