On 7 November 2011 21:05, Jonathan Wakely wrote:
> On 7 November 2011 20:58, Eric Botcazou wrote:
>>> Tested x86_64-linux and committed to trunk.
>>>
>>> * testsuite/30_threads/async/49668.cc: Add missing dg-require.
>>> * testsuite/30_threads/packaged_task/49668.cc: Likewise.
>>
>>
On 11/07/2011 10:45 PM, Jason Merrill wrote:
On 10/26/2011 04:35 PM, Paolo Carlini wrote:
We have that parser->scope is a RECORD_TYPE and postfix_expression is an
INDIRECT_REF.
Ah, OK. I guess we swallow up the namespace while parsing the full
nested-name-specifier and it isn't a problem. So
Add merging of namespaces.
Add testcase for namespace merging. test fails because lookup fails
for reasons apparently associated with identifiers.
Add tracing of both front and back of trees so as to better identify
the tree structure.
Add tracing of record markers.
Various formatting fixes.
T
On Mon, Nov 7, 2011 at 4:57 PM, Michael Matz wrote:
> Hi,
>
> On Thu, 3 Nov 2011, Richard Guenther wrote:
>
>> Otherwise the patch looks ok, but given the Ada issue let's wait until
>> that is sorted out in some way. That also gives others the chance to
>> comment on the patch.
>
> So, this is wh
On Mon, Nov 7, 2011 at 1:30 PM, Sharad Singhai wrote:
> Honza,
> Sorry, I forgot about this. Could you please put this on your TODO list?
>
> David,
> While a proper fix is pending for the trunk, we need this interim fix
> internally. Okay for google/main?
ok.
thanks,
David
>
> Thanks,
> Sharad
On Mon, Nov 7, 2011 at 5:41 PM, Xinliang David Li wrote:
> Here is the stack trace when the watch point is hit (the watch point
> is on address &cleanups->base.prefix.num
>
> David
>
> #0 memset () at ../sysdeps/x86_64/memset.S:336
> #1 0x00d1528d in poison_pages () at
> /usr/local/googl
Hi all,
Attached patch fixes the documentation of ATAN2 regarding signed zeros (aka
PR49336) and the documentation of option -fsign-zero regarding I/O behaviour
(aka PR49188). While I was at it, I also removed some lonely contractions
(it's, 'll, can't, don't, etc.)
Tested with "make man info
On Mon, Nov 07, 2011 at 11:09:52PM +0100, FX wrote:
> Hi all,
>
> Attached patch fixes the documentation of ATAN2 regarding signed zeros (aka
> PR49336) and the documentation of option -fsign-zero regarding I/O behaviour
> (aka PR49188). While I was at it, I also removed some lonely contractions
On 11/07/2011 08:59 AM, Walter Lee wrote:
> Seeking more feedback or status update.
>
> Thanks,
>
> Walter Lee
>
> On 10/30/2011 12:07 PM, Walter Lee wrote:
>> Ping? I believe I have addressed all the reviewer's (namely Joseph Myers')
>> comments to date.
I haven't seen a re-post since Joseph'
On Mon, Nov 7, 2011 at 8:03 PM, Jeff Law wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 11/07/11 08:49, Richard Guenther wrote:
>
>>
>> OTOH I'm not sure we want to change a possible trap (And thus
>> program abort) to a fallthru ...
> I think this is the big question we need to a
On 7 November 2011 21:51, Jonathan Wakely wrote:
>
> Aha, this is a problem with all platforms where _GLIBCXX_HAVE_TLS is
> not defined, std::call_once uses std:function which assumes a copyable
> target object.
>
> I'm working on it ..
>
Fixed like so ...
* include/std/mutex (call_once):
On Mon, Nov 7, 2011 at 8:01 PM, Richard Henderson wrote:
> On 11/05/2011 03:09 PM, Richard Guenther wrote:
>> On Sat, Nov 5, 2011 at 10:05 PM, Aldy Hernandez wrote:
>>> [rth, see below]
>>>
> local_define_builtin ("__builtin_eh_pointer", ftype,
> BUILT_IN_EH_POINTER,
>
On Mon, Nov 7, 2011 at 8:47 PM, Jeff Law wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 11/07/11 07:38, Richard Guenther wrote:
>>
>>
>> The cond_chain stuff should be as we have discussed quite some
>> time ago on IRC - modeled after tree-affine.c - a "vector" of
>> predicates of
On Mon, Nov 7, 2011 at 3:43 PM, Jonathan Wakely wrote:
> This is a new version of my -Wmeminit patch, first posted to PR c++/2972.
>
> Jason suggested combining the Wmeminit warning with the adjacent
> Weffc++ one which I agree with. The advice in the Effective C++ book
> actually says not to lea
On 11/07/2011 05:38 PM, Gabriel Dos Reis wrote:
struct C
{
int i;
C() = default;
};
so the defaulted constructor does not initialize C::i?
No, it doesn't. value-initialization of a C will initialize it, but not
default-initialization.
Jason
Fix the build warning introduced in r180971.
This is for google branch only.
Tested with build.
2011-11-07 Rong Xu
* gcc/dwarf2out.c (dwarf2out_decl): fix mixed declarations and code.
Index: gcc/dwarf2out.c
===
--- gcc
ok for google/main.
David
On Mon, Nov 7, 2011 at 2:40 PM, Rong Xu wrote:
> Fix the build warning introduced in r180971.
>
> This is for google branch only.
>
> Tested with build.
>
> 2011-11-07 Rong Xu
>
> * gcc/dwarf2out.c (dwarf2out_decl): fix mixed declarations and code.
>
> Index:
On Mon, Nov 7, 2011 at 8:36 PM, Jeff Law wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 11/07/11 09:14, Richard Guenther wrote:
>
>>>
>>> Well, not that I noticed that I missed here any freedom. In
>>> what cases you mean I would need here freedom to create new
>>> ssa-statements
My change to accept C99 array-designators in C++ broke use of lambdas in
an initializer-list, since both start with [. Fixed by parsing the
array-designator tentatively.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit fc9080728a450c22b6f70c133e9d12835733195f
Author: Jason Merrill
Date:
Tested on x86_64-linux.
r
gcc/Changelog:
2011-11-07 Roberto Agostino Vitillo
PR debug/50983
* dwarf2out.c (set_cur_line_info_table): Restore the last is_stmt value
in the current line table.
Index: gcc/gcc/dwarf2out.c
===
Dodji's work on template parameter lists of different lengths exposed a
problem whereby we weren't handling partial instantiation of a
COMPONENT_REF where the member is a SCOPE_REF. Fixed by not messing
with it when the object is still dependent.
Tested x86_64-pc-linux-gnu, applying to trunk.
On Mon, Nov 7, 2011 at 10:25 PM, Jakub Jelinek wrote:
> Hi!
>
> This patch attempts to optimize VEC_BASE if we know
> that offsetof of base is 0 (unless the compiler is doing something
> strange, it is true).
> It doesn't have a clear code size effect, some .text sections
> grew, supposedly becaus
On 7 November 2011 22:38, Gabriel Dos Reis wrote:
>> Unfortunately this doesn't work very well in C++11 mode, as defaulted
>> constructors don't cause warnings when they should do e.g.
>>
>> struct C
>> {
>> int i;
>> C() = default;
>> };
>>
>> This doesn't produce the same warning as C() {} even
On 11/07/2011 11:49 PM, Jason Merrill wrote:
Dodji's work on template parameter lists of different lengths exposed
a problem whereby we weren't handling partial instantiation of a
COMPONENT_REF where the member is a SCOPE_REF. Fixed by not messing
with it when the object is still dependent.
A slight revision of the previous version. Updated for mainline,
and tested on x86_64 and arm.
This time I also saw some more references to the sync_c_a_s optab
in the java front end. Now updated to use can_compare_and_swap_p.
Follow-on patches will invoke init_sync_libfuncs for arm, pa, mips,
On 11/7/2011 5:17 PM, Richard Henderson wrote:
> I haven't seen a re-post since Joseph's review?
> If I've missed it, please give me urls into the gcc-patches archive.
contrib:
http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01881.html
gcc:
http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01880.html
htt
On Mon, 7 Nov 2011, Richard Henderson wrote:
> We should make sure that the bootstrap succeeds though,
> disabling the library when porting work hasn't been done.
For disabling libraries, I've suggested that toplevel configure should
source a file from the subdirectory that says whether a target
On Mon, Nov 7, 2011 at 4:39 PM, Jason Merrill wrote:
> On 11/07/2011 05:38 PM, Gabriel Dos Reis wrote:
>>>
>>> struct C
>>> {
>>> int i;
>>> C() = default;
>>> };
>>
>> so the defaulted constructor does not initialize C::i?
>
> No, it doesn't. value-initialization of a C will initialize it, but
> Fixed like so ...
>
> * include/std/mutex (call_once): Store closure in __once_functor
> as bound function wrapper might not be copyable.
>
> The fix would be simpler but the lambda can't capture the parameter
> pack directly because of PR c++/41933. Unfortunately the non-TLS
> st
On Mon, Nov 07, 2011 at 04:10:38PM +, Joseph S. Myers wrote:
> FWIW, when I encountered such a problem in 4.4-based tools I found I
> needed the following change to stack_tie patterns to fix it (applied to
> and rediffed against trunk, but not tested there), in addition to a
> DEFAULT_ABI ==
On Mon, 7 Nov 2011, Richard Guenther wrote:
> Joseph, do you have any advise on how to address frontend specific
> options in a more general way? I'm trying to re-construct a
> command-line that when processed frontend agnostic would produce
> the same end-result in global_options as if going thr
On Mon, 7 Nov 2011, Iain Sandoe wrote:
> > How is the default selected (that's not obvious to me). flag_next_runtime
> > doesn't use options mechanisms it seems, that's bad. Both
> > -fgnu-runtime and -fnext-runtime are frontend-only flags, they should
> > be at least also enabled for LTO, other
On Mon, 7 Nov 2011, Richard Guenther wrote:
> Just looking for a more general solution (but I note that Ada lacks
> some conversion to the new cl_decoded_options facility anyways ...)
Full conversion may be hard because of things done in Ada code not C/C++,
but it is indeed the case that it woul
This fixes the problem on the Epiphany, but I haven't tested if it also fixes
it on
the SH - AAUI you'd have to back out a workaround first to properly test it.
Bootstrapped powerpc64-unknown-linux-gnu.
pr40154-fix
Description: Binary data
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/07/11 15:53, Richard Guenther wrote:
> On Mon, Nov 7, 2011 at 10:25 PM, Jakub Jelinek
> wrote:
>> Hi!
>>
>> This patch attempts to optimize VEC_BASE if we know that offsetof
>> of base is 0 (unless the compiler is doing something strange, it
>>
On Tue, 8 Nov 2011, Alan Modra wrote:
> OK, so you made the stack ties conflict with all memory. I wondered
> about that too, but didn't find a testcase where it mattered. It
The test I had was one of those from the various PRs for this issue.
int find_num(int i)
{
const int arr[5] = {0, 1,
Hi,
this is what I figured out for the parser: I'm dealing also with '.', as
you recommended, and I tidied a bit the code wrt my first draft try,
consistently with the way we are handling another error condition a few
lines earlier.
Re-tested x86_64-linux.
Thanks,
Paolo.
//
The new alias-declaration support in trunk allows the
std::pointer_traits and std::allocator_traits implementations to be
finished, by replacing the __rebind::__type workarounds with the
required alias-declarations.
* include/bits/ptr_traits.h (__rebind): Replace with...
(rebind):
On 11/07/2011 06:15 PM, Paolo Carlini wrote:
Thanks. This also implies that we don't ICE anymore on c++/50864, we
just accept it, as uninstiantiated template. I guess being able to
reject it early at parsing time would still be a good idea, in general.
Agreed.
Jason
On 11/07/2011 07:31 PM, Paolo Carlini wrote:
+ if (TREE_CODE (parser->scope) == NAMESPACE_DECL
+ && (TREE_CODE (postfix_expression) == ARROW_EXPR
+ || TREE_CODE (postfix_expression) == CALL_EXPR))
Do we need to check the code of postfix_expression
On 11/08/2011 01:49 AM, Jason Merrill wrote:
On 11/07/2011 07:31 PM, Paolo Carlini wrote:
+ if (TREE_CODE (parser->scope) == NAMESPACE_DECL
+ && (TREE_CODE (postfix_expression) == ARROW_EXPR
+ || TREE_CODE (postfix_expression) == CALL_EXPR))
Do we need to check the code
Hi,
Marc noticed we had a few redundant const qualifiers.
Tested x86_64-linux, committed.
Paolo.
//
2011-11-07 Paolo Carlini
* include/std/complex (complex<>::real(), complex<>::imag()):
Remove redundant const qualifiers.
Index: include/std/complex
=
Here our code trying to give a helpful diagnostic for a call to an
undeclared name in a template assumed that doing the lookup in
instantiated context would find a function; in this testcase it finds an
int&, and gets all confused.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 2bf99c2e
On 11/08/2011 01:51 AM, Paolo Carlini wrote:
Do we need to check the code of postfix_expression at all?
Ah! You implied that, in your previous message, but seemed too nice to
me ;) Let me regtest without...
And this indeed passes testing. A rather old testcase got a slightly
more accurate error
This removes a TODO where I'd been waiting to use an alias-declaration
to make the code a bit simpler.
Also uses std::decay in the packaged_task constraint I added recently.
* include/std/future (__future_base::_Ptr): Use alias-declaration.
(__is_same_pkgdtask): Rename to __constr
The std::pointer_traits and std::allocator_traits implementations are
complete now, update the release notes.
Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.7/changes.html,v
retrieving revision 1.46
diff -u -r1.46 chan
Hi,
committed to mainline.
Paolo.
///
2011-11-07 Paolo Carlini
PR libstdc++/51018
* include/profile/impl/profiler_node.h (__stack_hash::
operator()(__stack_t)): Just use std::size_t everywhere.
Index: include/profile/impl/profiler_node.h
=
On Mon, Nov 7, 2011 at 6:52 PM, Paolo Carlini wrote:
> Hi,
>
> Marc noticed we had a few redundant const qualifiers.
Yes and no. They were left redundant NOT out of careless
or lazyness.
At the time, it was lobbied hard that for transitional purposes,
#defning constexpr to nothing should still l
On 11/08/2011 02:43 AM, Gabriel Dos Reis wrote:
On Mon, Nov 7, 2011 at 6:52 PM, Paolo Carlini wrote:
Hi,
Marc noticed we had a few redundant const qualifiers.
Yes and no. They were left redundant NOT out of careless
or lazyness.
At the time, it was lobbied hard that for transitional purposes
> There still seem to be problems printing the scope:
>
> namespace N
> {
> template using U = T*;
> };
>
> void f(N::U) { blah; }
>
>
> wa.C: In function ‘void N::f(U)’:
> wa.C:6:21: error: ‘blah’ was not declared in this scope
>
> Note how the N:: is attached to the function r
Hi,
This patch turns on FMA4 for the AMD BDVER2 processor.
Okay for trunk if no regressions?
--
Quentin
Index: ChangeLog
===
--- ChangeLog (revision 181147)
+++ ChangeLog (working copy)
@@ -1,3 +1,8 @@
+2011-11-07 Quentin Nei
patch2 fixes parsing of transaction expressions, so that two txn
expressions that are part of a single expression do not get treated as
nested txns anymore, but become two separate ones (see test case).
Approved off-line by Richard Henderson, but I'll run tests again
tomorrow just to be sure.
patc
On 11/07/11 19:36, Torvald Riegel wrote:
patch2 fixes parsing of transaction expressions, so that two txn
expressions that are part of a single expression do not get treated as
nested txns anymore, but become two separate ones (see test case).
Approved off-line by Richard Henderson, but I'll run
The patch seems to work fine, except that MUST_NOT_THROW_EXPR isn't
working as expected. When used inside an expression, it isn't correctly
transformed to Gimple. Second, we loose terminate calls for some reason
(see noexcept-5.C). Those two things cause the failures with those test
cases.
The noe
OK.
Jason
OK.
Jason
On 11/07/2011 10:42 PM, Torvald Riegel wrote:
+ noex = tsubst_copy_and_build (noex, args, complain, in_decl,
+ /*function_p=*/false,
+ /*integral_const_expr_p=*/true);
+ noex = buil
> From: Andrew MacLeod
> Date: Mon, 7 Nov 2011 19:08:26 +0100
> So, what DO we do if there is no basic level of atomic
> support...
I just realized I may be feeding you an inconsistent
configuration, see the atomicity stuff in
libstdc++-v3/config/cpu/cris. Is that just obsolete and unused
now o
On Tue, Nov 08, 2011 at 12:30:36AM +, Joseph S. Myers wrote:
> On Tue, 8 Nov 2011, Alan Modra wrote:
>
> > OK, so you made the stack ties conflict with all memory. I wondered
> > about that too, but didn't find a testcase where it mattered. It
>
> The test I had was one of those from the va
On 2/11/2011, at 10:18 AM, Richard Guenther wrote:
>
Thus, I don't think we want to
merge this in its current form or in this stage1.
>>>
>>> What is the benefit of pushing this to a later release? If anything,
>>> merging the support for iterative optimizations now will allow us to
>
Hi!
Working virtually out of Pago Pago.
Is there a reason why we don't prefer 32-byte integer vector modes
even for AVX? If a vectorized loop needs some operation that is only
supported by AVX2 we would retry whenever seeing such stmt, so
what I think this costs us mainly some small amount of ti
On 7 November 2011 20:35, Jakub Jelinek wrote:
> Hi!
Hi,
>
> Here is an updated patch, which handles both modifier == NONE
> and modifier == NARROW for SLP, after all it wasn't that hard.
> Additionally it checks that the fndecls and various call flags
> match, and adds some testcases.
>
> Boots
On Tue, Nov 08, 2011 at 09:05:16AM +0200, Ira Rosen wrote:
> > + /* Arguments are ready. Create the new vector stmt. */
> > + FOR_EACH_VEC_ELT (tree, vec_oprnds0, i, vec_oprnd0)
>
> Was this line left by mistake?
Oops, yes. It didn't make a difference at runtime, so pas
The attached patch documents the fact that using the -finit-* options will
silence -Wuninitialized warnings. I don't think that's unreasonable (and Steve
classified it as a "it hurts when I do this" problem), so I intend to close the
PR after committing.
Tested with "make info man html pdf". OK
201 - 264 of 264 matches
Mail list logo
