"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> Robert Dewar wrote:
>> H.J. Lu wrote:
>>
>>> So that is the bug in the Linux kernel. Since fixing kernel is much
>>> easier
>>> than providing a workaround in compilers, I think kernel should be fixed
>>> and no need for icc/gcc fix.
>>
>> Fixing a bu
* Robert Dewar:
> again, in the real world, there are MANY projects that are nothing
> like this interactive when it comes to moving to new versions of
> operating systems.
Sure, but how many of those get to see software compiled with GCC 4.3?
If this has any real impact, it's more likely to sho
Hello everybody,
I have a feature request.
I'd like to (manually) define some byte blocks, eg. as functions with an
identifier. Then, if GCC would emit exactly these bytes, it puts a JMP
identifier there instead.
This would help by sharing many identical (text/code) byte sequences, to
make a s
On Fri, Mar 7, 2008 at 11:02 AM, Philipp Marek <[EMAIL PROTECTED]> wrote:
> Hello everybody,
>
> I have a feature request.
>
>
> I'd like to (manually) define some byte blocks, eg. as functions with an
> identifier. Then, if GCC would emit exactly these bytes, it puts a JMP
> identifier there
Hi,
Philipp Marek wrote:
Hello everybody,
I have a feature request.
and my scripts emit space savings of about 30kB. Now that's not
that much, but for embedded systems it means another userspace
binary more.
[ If anyone's interested, I can post my scripts here ... they're not
that large.
Hello Richard!
[ I took linux-tiny out - it's moderated, and I don't want to spam them. ]
> Sounds like what -frtl-abstract-sequences is trying to do.
Yes, thank you. I didn't know that; that should be close.
*But*: I think it doesn't work.
$ size vmlinux-as vmlinux-Os
textdata b
Hello Michael!
> Can I test your script in my embedded system?
> Can you send to me?
Here you are.
code_overlap.pl - disassembles a binary, and outputs a list
(address, name, instruction, bytes) to STDOUT.
bytes_saved.pl - takes such a list, and tries to estimate
the amount of bytes that c
On Fri, Mar 07, 2008 at 11:10:53AM +0100, Richard Guenther wrote:
> On Fri, Mar 7, 2008 at 11:02 AM, Philipp Marek <[EMAIL PROTECTED]> wrote:
> > I wrote some perl scripts to test this. I took a "alldefconfig" i686
> > kernel, let objdump disassemble it, and on "iret", "ret", "ljmp" or "jmp"
> >
Hello Dave!
> One achitectural problem here is that GCC doesn't emit bytes. It emits
> ASCII text, in the form of assembly instructions, and it's
> not always easy to predict how they'll look by the time they've been
> through the assembler and then had relocs applied by the
> linker. (Indeed, to
Philipp Marek wrote:
> I'd like to (manually) define some byte blocks, eg. as functions with
> an identifier. Then, if GCC would emit exactly these bytes, it
> puts a JMP identifier there instead.
One achitectural problem here is that GCC doesn't emit bytes. It emits ASCII
text, in the form
Hello Jakub!
> You need to be very careful with it, as if there are any jumps
> into the middle of the to be abstracted tail sequences, you can't
> abstract them or would need to adjust also the jumps into them (if
> possible, which not always is).
When wouldn't that possible? My script currently
On Fri, Mar 7, 2008 at 12:46 PM, Jakub Jelinek <[EMAIL PROTECTED]> wrote:
> On Fri, Mar 07, 2008 at 11:10:53AM +0100, Richard Guenther wrote:
> > On Fri, Mar 7, 2008 at 11:02 AM, Philipp Marek <[EMAIL PROTECTED]> wrote:
>
> > > I wrote some perl scripts to test this. I took a "alldefconfig" i686
On Fri, Mar 07, 2008 at 01:05:03PM +0100, Philipp Marek wrote:
> When wouldn't that possible? My script currently splits on an
> instruction-level -- although I would see no problem that some branch
> jumps into a "half" opcode of another branch, if the byte sequence
> matches.
Consider:
Hello Jakub!
>> When wouldn't that possible? My script currently splits on an
>> instruction-level -- although I would see no problem that some branch
>> jumps into a "half" opcode of another branch, if the byte sequence
>> matches.
>
> Consider:
> :
>0: b8 a4 00 00 00
BTW - It gets much better:
$ ls -la /usr/lib/libgcj.so.90.0.0
-rw-r--r-- 1 root root 32844984 3. Feb 16:03 /usr/lib/libgcj.so.90.0.0
$ ./run /usr/lib/libgcj.so.90.0.0
Approx. 470045 bytes saved.
That's 1.4% :-)
If my script isn't buggy, that is
--
Versioning your /etc, /home or
Hi,
On Thu, 6 Mar 2008, Andi Kleen wrote:
> To be realistic it is very unlikely anybody will measure a difference
> from a few more or a few less clds in a program.
Only an assumption, and in fact wrong. See upthread for a benchmark.
IIRC Uros also made measurements to justify the removal of
"Philipp Marek" <[EMAIL PROTECTED]> writes:
>> Shouldn't this be done in the linker instead?
> Well, can the linker change the instruction sequences? Ie. put a JMP
> instead of other code?
Sure. The linker can do whatever it likes. The usual problem is that
by the time the linker sees the cod
On Friday 07 March 2008 Ian Lance Taylor wrote:
> "Philipp Marek" <[EMAIL PROTECTED]> writes:
> >> Shouldn't this be done in the linker instead?
> >
> > Well, can the linker change the instruction sequences? Ie. put a JMP
> > instead of other code?
>
> Sure. The linker can do whatever it likes.
> "Manuel" == Manuel López-Ibáñez <[EMAIL PROTECTED]> writes:
Manuel> Here is a patch that give us caret diagnostics in C/C++.
Nice.
Manuel> The third approach would be to store an offset and when
Manuel> generating diagnostics, reopen the file, fseek to the offset
Manuel> and print that lin
On Fri, Mar 7, 2008 at 4:54 PM, Tom Tromey <[EMAIL PROTECTED]> wrote:
> > "Manuel" == Manuel López-Ibáñez <[EMAIL PROTECTED]> writes:
>
> Manuel> Here is a patch that give us caret diagnostics in C/C++.
>
> Nice.
>
> Manuel> The third approach would be to store an offset and when
> Manuel>
Otherwise, the libgomp.spec, which only resides in lib64, won't be found
at link time.
So I applied the link by hand - however, it occurs to me a computer is
the perfect tool to do this for me. Hence, why doesn't the make install
machinery do this ?
Kind regards,
--
Toon Moene - e-mail: [E
Snapshot gcc-4.4-20080307 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20080307/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
Tom Tromey <[EMAIL PROTECTED]> writes:
> Ian suggested that we delete this information after the FE is
> finished. This makes sense, I think, from a memory-saving
> perspective. But, that means we will get different kinds of error
> output depending on when a diagnostic is emitted, which I think
On Mar 7, 2008, at 6:06 PM, Ian Lance Taylor wrote:
Tom Tromey <[EMAIL PROTECTED]> writes:
Ian suggested that we delete this information after the FE is
finished. This makes sense, I think, from a memory-saving
perspective. But, that means we will get different kinds of error
output dependi
24 matches
Mail list logo
