> +AC_COMPILE_IFELSE([__thread int a; int b; int main() { return a = b; }],
> + [if grep __emutls_get_address conftest.$ac_objext
> >/dev/null ; then
grepping in a binary file is not portable. If this works it would be
better:
AC_COMPILE_IFELSE([[__thread int a; int b;
ext
Maxim Kuvyrkov [mailto:ma...@codesourcery.com] wrote:
> Yes, it does depend on this assumption and the comment states exactly that.
What I concerned is that the assumption may be broken someday, unless scheduler
guarantees it.
> Which check[s] do you have in mind, the gcc_assert's? Also, out of
Ye, Joey wrote:
Maxim and Vladimir Wrote:
Anyone can help me through this please?
It was supposed to have two latency definitions at most (one in
define_insn_reservation and another one in define_bypass). That time it
seemed enough for all processors supported by GCC. It also simplified
Vladimir Makarov [mailto:vmaka...@redhat.com] wrote:
> It was supposed to have two latency definitions at most (one in
> define_insn_reservation and another one in define_bypass). That time it
> seemed enough for all processors supported by GCC. It also simplified
> semantics definition when t
Maxim and Vladimir Wrote:
>>> Anyone can help me through this please?
>>>
>> It was supposed to have two latency definitions at most (one in
>> define_insn_reservation and another one in define_bypass). That time it
>> seemed enough for all processors supported by GCC. It also simplified
>>
Hello, I am working on a gcc porting for a new instruction. This
instruction needs to move data from memory to two registers. So I use
the SET rtx, and the dest of SET is an UNSPEC rtx with two registers.
By using such a rtl pattern, gcc performs very differently. It makes
mistakes for register rep
I'm looking a failure for m32c-elf (-mcpu=m32c) in
gcc.c-torture/execute/2412-6.c.
I've narrowed it down to a transformation done in 107t.ivopts.
In 104t.cunroll: (tmp_9 and tmp_16 are 24-bit pointer values):
tmp_9 = tmp_16 + 2;
if (bufend_6(D) > tmp_9)
but in 107t.ivopts:
tmp_9 = t
Hello!
On Mon, Dec 01, 2008 at 01:36:58PM -0500, David Edelsohn wrote:
> I am pleased to announce that the GCC Steering Committee has
> appointed Thomas Schwinge as GCC maintainer for GNU Hurd.
>
> Please join me in congratulating Thomas on his new role.
> Thomas, please update your l
Status
==
The trunk remains Stage 4, so only fixes for regressions (and changes
to documentation) are allowed.
As stated previously, the GCC 4.4 branch will be created when there
are no open P1s and the total number of P1, P2, and P3 regressions is
under 100.
One issue that remains is remov
This is the beta release of binutils 2.19.51.0.1 for Linux, which is
based on binutils 2009 0106 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
Peter,
> I think I failed to be clear enough. Before this patch, thunks
> pointing to weak functions on Tru64 were weak, after it, the functions
> remain weak, but the thunks are not. This is problematic.
ah, I failed to appreciate that. That sounds like a proble with the patch.
nathan
--
Nat
Hi Nathan,
Thanks for replying. I did not manage to get gcc trunk built on the
Tru64 machine to confirm that it is still a problem (out of memory in
stage2 compiling fold-const.c, but that's a whole different issue).
On Mon, Jan 05, 2009 at 06:15:07PM -0800, Nathan Sidwell wrote:
> Peter O'Gorman
Gerald Pfeifer writes:
> 2008-11-18 Gerald Pfeifer
>
> * doc/install.texi (alpha*-dec-osf*): Remove note on 32-bit
> hosted cross-compilers generating less efficient code.
This is OK.
Thanks.
Ian
On Tue, Jan 6, 2009 at 12:37 AM, Kaveh R. GHAZI wrote:
> Sorry I missed this back when it was originally posted, and the other SC
> members likely did also. I'll try and get you going.
The request was forwarded to the GCC SC.
David
On Mon, 3 Nov 2008, Rainer Orth wrote:
>>> I believe that this is false these days. I believe that it has been
>>> false since a cross-compiler to the alpha required a 64-bit
>>> HOST_WIDE_INT, which was in gcc 3.4.
>> Does this mean you (or Rainer) would approve the following documentation
>> upd
15 matches
Mail list logo
