This is the beta release of binutils 2.21.51.0.7 for Linux, which is
based on binutils 2011 0306 in CVS on sourceware.org plus various
changes. It is purely for Linux.
All relevant patches in patches have been applied to the source tree.
You can take a look at patches/README to see what have been
On Saturday, March 05, 2011 14:08:04 H.J. Lu wrote:
> Many x32 bugs are fixed in kernel, glibc, binutils and GCC:
>
> https://sites.google.com/site/x32abi/
>
> The major remaining issues are glibc/gcc testsuite failures,
> kernel core dump and signal handler unwind.
are you getting a unique host
Not that I'm abandoning the transactional memory party, but I'll also be
spending some cycles on the C++0x memory model work, which is an
offshoot of the atomics work Andrew Macleod has been working on
(http://gcc.gnu.org/wiki/Atomic).
I have added a link to the memory model work from the main
Jay Foad writes:
> This source code:
>
> $ cat rand.c
> #include
> uint32_t rand(uint32_t x) { return (uint64_t)x * 16807 % 0x7FFF; }
>
> compiles to this optimised x86 code:
>
> $ gcc -S -O3 -m32 -fomit-frame-pointer -o - rand.c
> ...
> rand:
> subl$28, %esp
> movl$16807
Hello!
> $ cat rand.c
> #include
> uint32_t rand(uint32_t x) { return (uint64_t)x * 16807 % 0x7FFF; }
>
> compiles to this optimised x86 code:
>
> $ gcc -S -O3 -m32 -fomit-frame-pointer -o - rand.c
> ...
> rand:
> subl$28, %esp
> movl$16807, %eax
> mull32(%esp)
>
In current trunk (r170704), 4.4-branch and 4.5-branch I observe the
following optimization issue in IRA: It saves regs in the frame
instead of in callee-saved registers which would be much smarter.
In the following C source, foo2 is compiled as desired (push/pop r17
to save r24). In foo1 and foo3
Hello All,
The gengtype state is persisted into a textual file with a lispy (actually
MELT-y) appearence.
This is very important for plugins (notably those using GTY).
The gengtype state is generated by gcc/Makefile.in rule:
s-gtype: build/gengtype$(build_exeext) $(filter-out [%], $(GTFILES))
Hello All,
I have a "philosophical" question about debug & trace printing from
inside GCC plugins (beyond the nearly useless answer that plugins being
outside of GCC could do what they wish), in particular from MELT (&
MELT extensions).
For various reasons (in particular because debugging MELT c
Anything related to gcc development goes on gcc/gcc-patches.
A mailing list for MELT *users* could work, but general conversations
on plugin development are better held on the main gcc lists. We
prefer message tagging to list splitting.
Diego.
On Mon, Mar 7, 2011 at 4:03 PM, Basile Starynkevitch
wrote:
> Hello All,
>
> I have a few subscribers to a french speaking GCC MELT mailing list on
> gcc-melt-fre...@googlegroups.com
>
> Since I have several potential non-french speaking but english-speaking
> users, I am considering to switch t
Hello All,
I have a few subscribers to a french speaking GCC MELT mailing list on
gcc-melt-fre...@googlegroups.com
Since I have several potential non-french speaking but english-speaking users,
I am considering to switch to an english list.
However, my intuition is that a list for plugins deve
Status
==
The trunk is still in Stage 4, open for only documentation and
regression fixes. We are nearly up to the point of having zero P1
regressions and thus a release candidate should appear soon. Please
be extra conservative what you consider a safe regression fix at
this point.
I have
This source code:
$ cat rand.c
#include
uint32_t rand(uint32_t x) { return (uint64_t)x * 16807 % 0x7FFF; }
compiles to this optimised x86 code:
$ gcc -S -O3 -m32 -fomit-frame-pointer -o - rand.c
...
rand:
subl$28, %esp
movl$16807, %eax
mull32(%esp)
13 matches
Mail list logo
