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
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
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
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.
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 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 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 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 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 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 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
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
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
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
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 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
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 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 07:42 AM, Michael Matz wrote:
> __transaction_atomic
> {
> {
> struct shared_count sc;
> try
> // ctor(&sc), dtor(&sc)
> finally
> {
> sc = {CLOBBER};
>
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 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
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
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
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
> 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
> >>
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
> -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,
> "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
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'
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:13 PM, Hans-Peter Nilsson wrote:
> * Makefile.in ($(srcdir)/emutls.c): Explain why it's in
> LIB2ADDEH et al.
Definitely ok. ;-)
r~
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 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
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
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 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
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 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
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 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
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
101 - 141 of 141 matches
Mail list logo
