On 28/10/2011, at 7:24 PM, Maxim Kuvyrkov wrote:
> On 20/10/2011, at 10:32 PM, Jan Hubicka wrote:
>
>> Hi,
>>> Jan,
>>>
>>> The following patch started as a one-liner for ipa-inline-analysis.c:
>>> account_size_time() to merge predicates when we are adding data to entry[0]
>>> (i.e., when spac
On 30/09/2011, at 6:56 PM, Maxim Kuvyrkov wrote:
> On 30/09/2011, at 4:02 PM, Maxim Kuvyrkov wrote:
>
>> On 24/09/2011, at 2:19 AM, Martin Jambor wrote:
>>
>>> However, both of these are really 4.8 material and since the patches
>>> probably need only minor updates, it might be worthwhile to do
1
mov %g1, %i0
return %i7+8
nop
.size main, .-main
.ident "GCC: (GNU) 4.7.0 2021 (experimental)"
.section.note.GNU-stack,"",@progbits
On 11/21/2011 11:02 PM, Andrew MacLeod wrote:
Anyway, it looks like __atomic_always_lock_free doesn't fold early
enough to be usable by the preprocessor like that even with my earlier
version. ugg. I think I can get something defined in cpp-builtins
that we can use. We're going to need it
On any target which defines ASM_OUTPUT_EXTERNAL, there is some fiddling
that has to be done with external labels. hpux is such a target, and any
unresolved functions need to be emitted as CODE labels rather than the
default DATA label.
previously, all __builtin functions were considered to be
On Sun, Nov 20, 2011 at 6:17 PM, Jiangning Liu wrote:
> Hi,
>
> This patch is to implement a peephole like optimization in ARM back-end.
>
> If we have an if condition expression like "((r3 != 0) & r1) != 0",
So this is the same as:
int f1(int r1, int r3)
{
if (((r3 != 0) & r1) != 0)
return
PR 51256 points out that
void *p;
__atomic_compare_exchange(p, p, p, 0, 0, 0);
results in an ICE.
This patch reports the error that a generic function call must not have
a void pointer for the first argument, or a size of the object cannot be
determined. It also now returns error_mark_node w
On 11/21/2011 09:29 PM, Benjamin Kosnik wrote:
Here's the first step in making the libstdc++ atomic configure bits into
something that makes more sense. This consolidates the builtin parts of
the configury, such that builtins mean C++11 atomics, not C++11 atomics
mixed with pre-C++11 atomics.
I
On Sat, Nov 19, 2011 at 12:41 PM, Eric Botcazou wrote:
> This is the miscompilation of the cross-compiler targetting AVR by the native
> compiler on the SPARC at -O2, a latent problem in reorg.c that is exposed in
> the 4.5.x (and later) series by the introduction of __builtin_unreachable.
I saw
Here's the first step in making the libstdc++ atomic configure bits into
something that makes more sense. This consolidates the builtin parts of
the configury, such that builtins mean C++11 atomics, not C++11 atomics
mixed with pre-C++11 atomics.
I think this is mostly right, modulo my logic on t
On 11/21/2011 05:13 PM, Hans-Peter Nilsson wrote:
> * Makefile.in ($(srcdir)/emutls.c): Explain why it's in
> LIB2ADDEH et al.
Definitely ok. ;-)
r~
At 2011-11-19 07:11:17,"Ramana Radhakrishnan"
wrote:
> On 10 November 2011 18:07, Sameera Deshpande
> wrote:
> > Please find attached the reworked patch.
>
> OK but for a very small bit .
>
> I'll note that we need to add support for the iwMMXt registers but the
> attached patch (untested) sho
On 11/21/2011 05:31 PM, Jiangning Liu wrote:
> My question is essentially is "May I really use REG_EXPR in back-end code?"
> like the patch I gave below?
I suppose.
Another alternative is to use BImode for booleans. Dunno how much of that
you'd be able to gleen from mere rtl expansion or if you'
> "rl" > "rs", mind sorting this in?
Oops. I'd been putting RL78 before RX for so long it seemed natural
(it's been powerpc so far, which doesn't come between rl78 and rx)
> > Index: gcc/doc/extend.texi
> > ===
> > -the SPU and M32
> -Original Message-
> From: Richard Henderson [mailto:r...@redhat.com]
> Sent: Tuesday, November 22, 2011 7:55 AM
> To: Jiangning Liu
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [RFC] Use which_alternative in preparation-statements of
> define_insn_and_split
>
> On 11/20/2011 07:34 PM,
The original subject doesn't catch the key point, so I changed the subject
to get more people noticed.
My question is essentially is "May I really use REG_EXPR in back-end code?"
like the patch I gave below?
Thanks,
-Jiangning
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [m
> From: Iain Sandoe
> Date: Mon, 21 Nov 2011 11:04:18 +0100
> On 21 Nov 2011, at 09:34, Hans-Peter Nilsson wrote:
>
> >> From: Paolo Bonzini
> >> Sender: Paolo Bonzini
> >> Date: Mon, 21 Nov 2011 10:20:39 +0100
> >
> >> H-P, can you try bootstrapping your patch on cygwin and/or mingw too
> >>
On 11/18/2011 01:24 PM, Aldy Hernandez wrote:
> - if (DECL_COMDAT (new_decl))
> + if (DECL_COMDAT (new_decl) && HAVE_COMDAT_GROUP)
> DECL_COMDAT_GROUP (new_decl) = tm_mangle (DECL_COMDAT_GROUP (old_decl));
> + else
> +DECL_COMDAT_GROUP (new_decl) = DECL_COMDAT_GROUP (old_decl);
This lo
This allows std::bind and tr1::bind to work together and support each
other's placeholders and recognise each other's call wrappers as bind
expressions.
* include/std/functional (is_placeholder, is_bind_expression): Add
partial specializations for cv-qualified types.
* incl
Richard Henderson schrieb:
On 11/21/2011 11:31 AM, Georg-Johann Lay wrote:
;; The caveat is that if there are insns for some mode, there must also be a
;; respective move insn that describes reloads. Therefore, this
;; implementation uses an accumulator-based model with two hard-coded,
;; accu
On 11/21/2011 06:46 PM, Patrick Marlier wrote:
On 11/21/2011 06:14 PM, Richard Henderson wrote:
On 11/21/2011 02:13 PM, Richard Henderson wrote:
It has been pointed out to me that I'm an idiot and sent an empty attachment.
So lets try this again...
Arg... I have never said that!
+#if USE_TM
On 11/20/2011 07:34 PM, Jiangning Liu wrote:
> Hi,
>
> I find which_alternative can't really be used in preparation-statements of
> define_insn_and_split, so can this be fixed like below?
>
> For example, I want to use which_alternative in the pattern below,
>
> (define_insn_and_split "*thumb2_m
On 11/21/2011 07:42 AM, Michael Matz wrote:
> __transaction_atomic
> {
> {
> struct shared_count sc;
> try
> // ctor(&sc), dtor(&sc)
> finally
> {
> sc = {CLOBBER};
>
On 11/21/2011 02:13 PM, Richard Henderson wrote:
> This was actually a merge error on the branch. When crtstuff.c
> moved to libgcc/, Aldy failed to copy the changes.
>
> I've tidied things even a bit more from the branch, with the
> introduction of the USE_TM_CLONE_REGISTRY control macro, which
On 11/21/2011 01:58 PM, Torvald Riegel wrote:
> On Mon, 2011-11-21 at 13:45 -0800, Richard Henderson wrote:
>> On 11/21/2011 01:39 PM, Torvald Riegel wrote:
>>> It still fails when combined
>>> with transaction expressions (noexcept-4.C and noexcept-1.C) because
>>> gimplify_must_not_throw_expr() c
On 11/21/2011 11:31 AM, Georg-Johann Lay wrote:
> ;; The caveat is that if there are insns for some mode, there must also be a
> ;; respective move insn that describes reloads. Therefore, this
> ;; implementation uses an accumulator-based model with two hard-coded,
> ;; accumulator-like registers
This was actually a merge error on the branch. When crtstuff.c
moved to libgcc/, Aldy failed to copy the changes.
I've tidied things even a bit more from the branch, with the
introduction of the USE_TM_CLONE_REGISTRY control macro, which
is in turn now predicated on ELF.
Tested on x86_64-linux.
On Mon, 2011-11-21 at 13:45 -0800, Richard Henderson wrote:
> On 11/21/2011 01:39 PM, Torvald Riegel wrote:
> > It still fails when combined
> > with transaction expressions (noexcept-4.C and noexcept-1.C) because
> > gimplify_must_not_throw_expr() calls voidify_wrapper_expr() on a
> > MUST_NOT_THR
From: Eric Botcazou
Date: Thu, 17 Nov 2011 22:21:32 +0100
>> Eric, this is just something I noticed while trying to fix the
>> vec_init problems last week.
>>
>> I'm confident that the issue is real, however I can't point to any
>> real bugs that are caused by this.
>>
>> Therefore I'm reluctant
As discussed on gcc.
Committed to trunk.
gcc/
Revert
2011-11-16 Andreas Krebbel
PR middle-end/50325
* expmed.c (store_bit_field_1): Use extract_bit_field on big
endian targets if the source cannot be exactly covered by word
mode chunks.
---
g
On 11/21/2011 01:39 PM, Torvald Riegel wrote:
> It still fails when combined
> with transaction expressions (noexcept-4.C and noexcept-1.C) because
> gimplify_must_not_throw_expr() calls voidify_wrapper_expr() on a
> MUST_NOT_THROW_EXPR which it doesn't know to be a wrapper. What's the
> cleanest
On 11/21/2011 12:37 PM, Torvald Riegel wrote:
> PR47747: Fix error messages for calls to unsafe virtual functions.
>
> gcc/
> * trans-mem.c (diagnose_tm_1): Print an expression instead of a
> declaration in error messages for indirect calls.
>
> testsuite/
>
On Mon, 2011-11-21 at 12:30 -0800, Richard Henderson wrote:
> On 11/21/2011 12:27 PM, Torvald Riegel wrote:
> > voidify_wrapper_expr didn't handle MUST_NOT_THROW_EXPR before, but was
> > used by the C++ side gimplify function for MUST_NOT_THROW_EXPR. Handle
> > it like other wrappers which have th
On 11/21/2011 04:27 PM, Torvald Riegel wrote:
On Mon, 2011-11-21 at 16:06 -0500, Jason Merrill wrote:
At this point I think it'd be simpler to handle noexcept in a
transaction-expression directly in cp_parser_transaction_expression.
And keep transaction statements as is, or change them as well
On Mon, 2011-11-21 at 16:06 -0500, Jason Merrill wrote:
> At this point I think it'd be simpler to handle noexcept in a
> transaction-expression directly in cp_parser_transaction_expression.
And keep transaction statements as is, or change them as well?
> Since TRANSACTION_EXPR_NOEX is only for
On Nov 21, 2011, at 2:30 AM, Iain Sandoe
wrote:
> Darwin uses ".private_extern" for hidden visibility, and also we have
> __USER_LABEL_PREFIX__ set to "_".
>
> OK for trunk?
Ok.
On Nov 21, 2011, at 1:17 AM, Iain Sandoe
wrote
> Actually, two questions have come to mind overnight;
>
> 1. should I be applying this constructor/destructor pair to shared libraries
> as well?
I'll plead ignorance.
> 2. Mike: I think to append "regular,no_dead_strip" to the section text, OK
On Nov 20, 2011, at 3:27 PM, Iain Sandoe
wrote:
> Since Darwin has its own crt infrastructure, we will still need to deal with
> this (even once the tm version is merged into gcc/crtstuff)...
> OK for trunk?
Ok.
Hi!
ENTRY_VALUE's argument has '0' format letter instead of 'e', so XEXP
must not be used on it (at least not in RTL checking, otherwise it is the
same).
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk.
2011-11-21 Jakub Jelinek
PR debug/50827
* var-tr
At this point I think it'd be simpler to handle noexcept in a
transaction-expression directly in cp_parser_transaction_expression.
Since TRANSACTION_EXPR_NOEX is only for the template representation, I'd
rather not add it to the language-independent tree code. Maybe
introduce a C++ template-s
This just tweaks the error message to use an expression (%qE) instead of
a declaration (%qD) when we complain about an indirect call being
unsafe. The output isn't very pretty, but it does seem to do the job.
Also, if it is a direct call, it should hopefully always be some kind of
expression. All
This revision of the patch is now complete and passes all the tests I
could come up with. Compared to previous iterations, I added parsing of
noexcept without explicit true/false. This makes
cp_parser_noexcept_specification_opt a bit more complex, but we can now
reuse it.
The other two patches I
On 11/21/2011 12:27 PM, Torvald Riegel wrote:
> voidify_wrapper_expr didn't handle MUST_NOT_THROW_EXPR before, but was
> used by the C++ side gimplify function for MUST_NOT_THROW_EXPR. Handle
> it like other wrappers which have the inner part in operand 0.
>
> OK for trunk?
Not ok. This is a c+
On 11/21/2011 12:25 PM, Torvald Riegel wrote:
> gcc/cp/
> * pt.c (tsubst_copy_and_build): Handle TRANSACTION_EXPR.
Ok.
> +/* { dg-final { scan-tree-dump-times "ITM_RU4\\s*\\(&global" 2 "tmmark" } }
> */
This needs to cater to sizeof(int) != 4.
Why not just match "ITM_RU" and leave i
voidify_wrapper_expr didn't handle MUST_NOT_THROW_EXPR before, but was
used by the C++ side gimplify function for MUST_NOT_THROW_EXPR. Handle
it like other wrappers which have the inner part in operand 0.
OK for trunk?
commit 9cb965d2a5cf9ca6708ee85929784982253ded7a
Author: Torvald Riegel
Date:
This patch fixes the instantiation of transaction expressions.
Transaction statements were correctly before via tsubst_expr, so just
use this code for expressions in tsubst_copy_and_build too.
OK for trunk?
commit 08726d496492d5a0fc2b0310983b04689ba17a48
Author: Torvald Riegel
Date: Sat Nov 19
On 11/21/2011 11:58 AM, Jack Howarth wrote:
>> > It was probably due to the version number not being applied previously.
> Richard,
>I asked because we have libssp and libquadmath at 0 so I thought that the
> initial release of
> libitm would soversioned the same way.
Those simply don't seem
On Mon, Nov 21, 2011 at 11:55:00AM -0800, Richard Henderson wrote:
> On 11/21/2011 11:50 AM, Jack Howarth wrote:
> > On Mon, Nov 21, 2011 at 08:35:39PM +0100, Torvald Riegel wrote:
> >> On Mon, 2011-11-21 at 15:06 +0100, Rainer Orth wrote:
> >>> * _ITM_getThreadnum is the only symbol in libitm.map
On 11/21/2011 11:50 AM, Jack Howarth wrote:
> On Mon, Nov 21, 2011 at 08:35:39PM +0100, Torvald Riegel wrote:
>> On Mon, 2011-11-21 at 15:06 +0100, Rainer Orth wrote:
>>> * _ITM_getThreadnum is the only symbol in libitm.map that isn't present
>>> in the library. It's documented as missing and sh
> It's my pleasure to announce that Eric Botcazou is joining Arnaud,
> Geert and Robert as maintainer for Ada.
>
> (Turns out that when discussing this many were actually suprised
> he was not already. :-)
>
> Eric, you know the procedure, MAINTAINERS and such.
Thanks, file updated thusly.
On Mon, Nov 21, 2011 at 08:35:39PM +0100, Torvald Riegel wrote:
> On Mon, 2011-11-21 at 15:06 +0100, Rainer Orth wrote:
> > * _ITM_getThreadnum is the only symbol in libitm.map that isn't present
> > in the library. It's documented as missing and should perhaps be
> > removed from the map?
>
On 11/21/2011 11:31 AM, Aldy Hernandez wrote:
> case GIMPLE_DEBUG:
> +case GIMPLE_TRANSACTION:
>for (i = 0; i < gimple_num_ops (stmt); i++)
> {
>tree op = gimple_op (stmt, i);
> @@ -145,6 +146,8 @@ output_gimple_stmt (struct output_block
>else
> stream
On 11/21/2011 11:31 AM, Aldy Hernandez wrote:
> Tested on x86-64 Linux. The testcase only tests for assembly, since I see no
> way of testing linkage and depending on libitm as well.
All these tests support multi-file linkage (otherwise LTO is moot).
You could supply dummy implementations of the
On 11/20/2011 05:24 PM, Ed Smith-Rowland wrote:
Ping.
There's a patch that should do the literal operator resolution correctly
and resolve PR50958:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50958
Ah, I didn't realize you had attached a patch there. Next time please
also send patches to gc
On Mon, 2011-11-21 at 15:06 +0100, Rainer Orth wrote:
> * _ITM_getThreadnum is the only symbol in libitm.map that isn't present
> in the library. It's documented as missing and should perhaps be
> removed from the map?
Yes, this is not supported anymore.
Thanks,
Torvald
This adds support for DImode insns that don't operate byte-wise like NEG,
COMPARE, PLUS, MINUS, ASHIFT, LSHIFTRT, ASHIFTRT, ROTATE.
The crucial point is that there is no movdi, with the following reasoning as
cited from new avr-dimode.md:
;; The purpose of this file is to provide a light-weight D
No sense not supporting LTO in the first TM release, if we can avoid it.
OK for trunk, or should I queue for 4.8? This only affects the TM code
path.
Tested on x86-64 Linux. The testcase only tests for assembly, since I
see no way of testing linkage and depending on libitm as well. Plus, w
On 11/21/2011 02:04 AM, Iain Sandoe wrote:
> The reason it was in libgcc_eh (AFAIK, the original implementation
> pre-dates my GCC days) - is because there can only be one copy of the
> static emutls locking entities in a given exe. I guess it was felt
> analogous to the "only one unwinder" rule.
Here the pointer to the patch I just committed.
Test results:
http://gcc.gnu.org/ml/gcc-testresults/2011-11/msg02168.html
Commit:
http://gcc.gnu.org/ml/gcc-cvs/2011-11/msg00886.html
And sorry for the inconsistency.
Thanks,
Andreas
On Mon, Nov 21, 2011 at 05:40:26PM +0100, Rainer Orth wrote:
> 2011-11-20 Rainer Orth
>
> * gcc.c (init_gcc_specs) [USE_SHARED_LIBGCC_FOR_EH]: Always use
> libgcc_s.
> * config/sol2.h [USE_GLD] (USE_SHARED_LIBGCC_FOR_EH): Define.
That's an ugly hack. IMHO we just want to do
On 11/21/2011 09:23 AM, Rainer Orth wrote:
> Richard Henderson writes:
>
>> This is only ok if the compiler and library are build with default options.
>> If you use --with-arch=corei7-avx then we may well use AVX insns all through
>> the library, not just in the one interface that will only be u
On 11/21/2011 01:17 AM, Iain Sandoe wrote:
> 1. should I be applying this constructor/destructor pair to shared libraries
> as well?
> (the specs need minor amendment)
Yes.
r~
Jason Merrill writes:
> See my comment in the PR.
Yes, sorry I have missed it.
Here is an updated patch hopefully addressing that comment. I have also
updated a bunch of tests as a result of the change from error to note.
Bootstrapped and tested on x86_64-unknown-linux-gnu against trunk.
Fro
From: Rainer Orth
Date: Mon, 21 Nov 2011 16:07:04 +0100
> The new gcc.target/sparc/vec-init-[1-3]-vis3.c tests might fail on
> Solaris 10 and 11 with Sun as on non-VIS3 capable hardware
> (e.g. UltraSPARC T2 or UltraSPARC IV) like this:
>
> ld.so.1: vec-init-1-vis3.exe: fatal: vec-init-1-vis3.ex
From: Rainer Orth
Date: Mon, 21 Nov 2011 14:53:33 +0100
> Right now, it is only possible to clear the hardware capabilities
> completely, while the new v2 mapfile syntax supports selectively adding
> and removing capabilities. It is only available in Solaris 11 and
> Solaris 10 Update 10, though
Hello!
This patch moves unspec/unspecv constants to their new homes. The
patch also moves a couple of fence patterns from sse.md to sync.md.
No functional changes.
2011-11-21 Uros Bizjak
* config/i386/mmx.md (unspec) :
Move from config/i386/i386.md
(unspecv) : Ditto.
Joel Sherrill writes:
> Does this patch apply OK for others?
>
> Ranier.. you can just send me the impacted files if you like. I have
> no local changes to libgcc.
>
> $ cat /tmp/libgcc-t-savresfgpr.patch | patch -p1
> patching file libgcc/config.host
> Hunk #1 succeeded at 843 (offset -9 lines)
On 11/21/2011 11:25 AM, Rainer Orth wrote:
Paolo Bonzini writes:
Wrong patch attached.
Indeed ;-)
Does this patch apply OK for others?
Ranier.. you can just send me the impacted files if you like. I have
no local changes to libgcc.
$ cat /tmp/libgcc-t-savresfgpr.patch | patch -p1
patchin
2011/11/21 Georg-Johann Lay :
> After updating my local copy I get new runtime FAILs in the test suite because
> of the following sequence, e.g. from gcc.c-torture/execute/990527-1.c:
>
> sbiw r28,1 ; 12 addhi3_clobber/1 [length = 1]
> ldi r24,lo8(9) ; 24 *movhi/5
Paolo Bonzini writes:
> Wrong patch attached.
Indeed ;-)
# HG changeset patch
# Parent e270cbe9e8641882fbcae2c23e927cdfd2be182f
Cleanup rs6000/t-ppccomm configurations (PR other/51022)
diff --git a/libgcc/config.host b/libgcc/config.host
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -85
On Mon, Nov 21, 2011 at 06:56:55PM +0200, Razya Ladelsky wrote:
> I have some non-affine cases for which compute_affine_dependence is called
> (as it is called for
> ALL dependences from compte_all_depepndences()), and no harm is done.
> I looked a little bit closer into the code, and this is wha
Richard Henderson writes:
> This is only ok if the compiler and library are build with default options.
> If you use --with-arch=corei7-avx then we may well use AVX insns all through
> the library, not just in the one interface that will only be used if the
> user of the library is using avx.
>
On 11/21/2011 05:01 PM, Rainer Orth wrote:
As reported in the PR, powerpc-rtems bootstrap (and certainly several
other powerpc targets) is currently broken since rs6000/ibm-ldouble.c
appears twice in LIB2ADD, once from rs6000/t-ppccomm and
rs6000/t-ppccomm-ldbl, which confuses make.
It took me a
On 11/21/2011 05:53 AM, Rainer Orth wrote:
> The libitm execution tests are currently failing on Solaris 10 and up
> with Sun as/ld:
>
> ld.so.1: cancel.exe: fatal:
> /var/gcc/regression/trunk/11-gcc/build/i386-pc-solaris2.11/./libitm/.libs/libitm.so.0:
> hardware capability (CA_SUNW_HW_1) unsup
Hi,
On Mon, 21 Nov 2011, Richard Henderson wrote:
> On 11/21/2011 06:06 AM, Rainer Orth wrote:
> > * libitm.so wasn't versioned even with gld, since libitm_la_LDFLAGS
> > wasn't passed when linking it.
>
> foo_LDFLAGS is supposed to be one of those auto variables that gets used
> when linking
On 11/21/2011 06:06 AM, Rainer Orth wrote:
> * libitm.so wasn't versioned even with gld, since libitm_la_LDFLAGS
> wasn't passed when linking it.
foo_LDFLAGS is supposed to be one of those auto variables that gets used when
linking foo. I know that the library was successfully versioned when I
Jakub Jelinek wrote on 21/11/2011 05:07:54 PM:
> From: Jakub Jelinek
> To: Razya Ladelsky/Haifa/IBM@IBMIL
> Cc: GCC Patches , Richard Guenther
>
> Date: 21/11/2011 05:08 PM
> Subject: Re: [PATCH, take 2] Fix PR tree-optimization/49960 ,Fix
> self data dependence
>
> On Mon, Nov 21, 2011 at 0
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/18/11 19:47, Gerald Pfeifer wrote:
>
> Just mind the long line
Do we wrap earlier in the texi file (first line is 79chars I think)?
Or are you referring to an output file?
and it's Rawhide (uppercase), I think.
Yea, fixed.
jeff
-BEGIN PGP
For the last two weeks, testsuite results on Solaris 11/x86 with gld
2.21.1 have been terrible, which hundreds of link failures. One example
is
spawn /var/gcc/regression/trunk/11-gcc-gas-gld/build/gcc/xgcc
-B/var/gcc/regression/trunk/11-gcc-gas-gld/build/gcc/
/vol/gcc/src/hg/trunk/local/libffi/
Hi,
Continuing investigation of fails on bootstrap I found next problem
(besides the problem with unknown alignment described above): there is
a mess with size_needed and epilogue_size_needed when we generate
epilogue loop which also use SSE-moves, but no unrolled - that's
probably the reason of t
On 11/21/2011 07:17 AM, Iain Sandoe wrote:
> config:
>
> * weakref.m4: New file.
>
> libitm:
>
> * configure.ac: Use GCC_CHECK_ELF_STYLE_WEAKREF.
> * alloc_cpp.cc: Generate dummy functions if we don't
> HAVE_ELF_STYLE_WEAKREF.
> * eh_cpp.cc: Likewise.
> * configure: Regen
Hi,
On Sat, 19 Nov 2011, Tom de Vries wrote:
> On 11/18/2011 10:29 PM, Eric Botcazou wrote:
> >> For the test-case of PR50764, a dead label is introduced by
> >> fixup_reorder_chain in cfg_layout_finalize, called from
> >> pass_reorder_blocks.
> >
> > I presume that there is no reasonable way of
As reported in the PR, powerpc-rtems bootstrap (and certainly several
other powerpc targets) is currently broken since rs6000/ibm-ldouble.c
appears twice in LIB2ADD, once from rs6000/t-ppccomm and
rs6000/t-ppccomm-ldbl, which confuses make.
It took me a while to understand how we got into that sit
On 11/21/2011 04:43 PM, Rainer Orth wrote:
Paolo Bonzini writes:
On 11/07/2011 07:15 PM, Rainer Orth wrote:
Bernd Schmidt writes:
On 11/03/11 20:20, Rainer Orth wrote:
* config/c6x/t-elf (LIB2ADDEH): Set.
* config/c6x/t-c6x-elf: Remove.
It builds now, but parts of libg
Paolo Bonzini writes:
> On 11/07/2011 07:15 PM, Rainer Orth wrote:
>> Bernd Schmidt writes:
>>
>>> On 11/03/11 20:20, Rainer Orth wrote:
* config/c6x/t-elf (LIB2ADDEH): Set.
* config/c6x/t-c6x-elf: Remove.
>>>
>>> It builds now, but parts of libgcc are missing. There's no s
Hi,
On Fri, 18 Nov 2011, Aldy Hernandez wrote:
> I just CC'ed you on a bug that I believe was caused by your patch.
>
> I forgot to CC you on the bug before I wrote the comment on it.
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51125#c4
>
> Perhaps you can take a look?
The attached patch
Hello All,
This is the last piece needed to get libitm working on Darwin.
---
It is take 2 on auto-configury for weakrefs in libitm.
It takes into account the comments made by Rainer (and follow-up) on:
http://gcc.gnu.org/ml/gcc-patches/2011-11/msg01898.html
* moves the checking functions to
On Mon, Nov 21, 2011 at 04:54:09PM +0200, Razya Ladelsky wrote:
> Although compute_affine_dependence() can't do anything meaningful for the
> gather data refs,
> it may still be assigning values to the dependence relation structure, if
> you need to use them.
> Therefore I did not skip the call
The new gcc.target/sparc/vec-init-[1-3]-vis3.c tests might fail on
Solaris 10 and 11 with Sun as on non-VIS3 capable hardware
(e.g. UltraSPARC T2 or UltraSPARC IV) like this:
ld.so.1: vec-init-1-vis3.exe: fatal: vec-init-1-vis3.exe: hardware capability (C
A_SUNW_HW_1) unsupported: 0x400 [ VIS3 ]
All,
[Apologies to those getting this twice - used wrong account to send it
initially].
The attached patch updates the gcc.dg/vshift-*.c tests to call the
function rand and not random, as random is not available on all targets,
but rand should be as it is in the Standard C Library.
Can som
Markus Trippelsdorf writes:
>
> I have deleted the tarballs because they don't apply cleanly anymore.
> But this is not rocket science and you can easily update to the new
> libtool yourself by just copying the new version to the gcc root dir
> and running "ACLOCAL='aclocal -I .. -I ../config' aut
Jakub Jelinek wrote on 21/11/2011 03:59:15 PM:
> From: Jakub Jelinek
> To: Razya Ladelsky/Haifa/IBM@IBMIL
> Cc: GCC Patches , Richard Guenther
>
> Date: 21/11/2011 03:59 PM
> Subject: Re: [PATCH, take 2] Fix PR tree-optimization/49960 ,Fix
> self data dependence
>
> On Mon, Nov 21, 2011 at 0
On Mon, 21 Nov 2011, Joseph S. Myers wrote:
> I don't see this on mainline, only 4.6 branch - am I missing something
> or is mainline now in a regressed state relative to 4.6? A fix should
> always go on mainline before 4.6, 4.6 before 4.5, 4.5 before 4.4, and
> unless and until a full merge fr
This test fails on Solaris 2 when compiled as C++:
FAIL: c-c++-common/tm/malloc.c -std=gnu++98 scan-tree-dump-times tmmark "
malloc .666" 1
FAIL: c-c++-common/tm/malloc.c -std=gnu++11 scan-tree-dump-times tmmark "
malloc .666" 1
It scans for ' malloc', but the Solaris 2 headers are C++aware and
After updating my local copy I get new runtime FAILs in the test suite because
of the following sequence, e.g. from gcc.c-torture/execute/990527-1.c:
sbiw r28,1 ; 12 addhi3_clobber/1[length = 1]
ldi r24,lo8(9) ; 24 *movhi/5[length = 2]
clr r25
Symbol versioning support in libitm is currently based on an old version
of the code in libgomp, which doesn't support sun style versioning. The
following patch corrects this by merging the changes made to libgomp
versioning support since, with the exception of parts that aren't used
in libitm (sy
On Mon, Nov 21, 2011 at 01:58:18PM +, Matthew Gretton-Dann wrote:
> gcc/testsuite/ChangeLog:
>
> 2011-11-21 Matthew Gretton-Dann
>
>* gcc.dg/vshift-1.c (main): Call rand instead of random.
>* gcc.dg/vshift-3.c (main): Likewise.
This is ok for the trunk.
Jakub
On Mon, Nov 21, 2011 at 03:50:10PM +0200, Razya Ladelsky wrote:
> what do you mean by 'except for the affine stuff'?
I mean that compute_affine_dependence must never be called on gather
data refs, that function can't do anything meaningful for them, they are
gather data refs exactly because dr_ana
The libitm execution tests are currently failing on Solaris 10 and up
with Sun as/ld:
ld.so.1: cancel.exe: fatal:
/var/gcc/regression/trunk/11-gcc/build/i386-pc-solaris2.11/./libitm/.libs/libitm.so.0:
hardware capability (CA_SUNW_HW_1) unsupported: 0x2000 [ AVX ]
FAIL: libitm.c/cancel.c exe
gcc-patches-ow...@gcc.gnu.org wrote on 21/11/2011 02:57:07 PM:
> From: Jakub Jelinek
> To: Razya Ladelsky/Haifa/IBM@IBMIL
> Cc: Richard Guenther , GCC Patches patc...@gcc.gnu.org>
> Date: 21/11/2011 02:57 PM
> Subject: Re: [PATCH, take 2] Fix PR tree-optimization/49960 ,Fix
> self data dependen
1 - 100 of 141 matches
Mail list logo
