On 09/09/2013 12:44 PM, Paolo Carlini wrote:
I understand that. It seems to me a much bigger project and must be
done for the C front-end too (I don't know the name of the equivalent
of location_of, but the location is wrong for it too, there must be
the equivalent of t = DECL_CONTEXT (t
Stage 1 the risk of
breaking locations somewhere else is low enough. By the way, as
discussed today elsewhere, the C front-end is already Ok.
Thanks!
Paolo.
//////
/cp
2013-09-09 Paolo Carlini
PR c++/58362
* error.c (location_of): Don't handle PARM_DECLs spec
Hi,
thus the below is what I actually tested on x86_64-linux. I think we
discuss already most of it.
Thanks!
Paolo.
2013-09-09 Jan Hubicka
Paolo Carlini
* cgraphunit.c (analyze_functions): Save input_location, set it
to UNKNOWN_LOCATION
On 09/10/2013 08:38 PM, Jakub Jelinek wrote
Agreed, can you please revert it?
Sure, I'll do that momentarily.
Paolo.
Hi,
On 09/10/2013 05:34 PM, Jakub Jelinek wrote:
On Wed, Sep 04, 2013 at 03:29:43PM +0100, Gary Benson wrote:
I've added the result to the demangler test suite, but I know of
no way to check the validity of the demangled symbol other than by
inspection (and I am no expert here!) If anybody kno
Hi,
On 09/11/2013 07:40 PM, domi...@lps.ens.fr wrote:
The failures are (at least on x86_64-apple-darwin10):
/opt/gcc/work/gcc/testsuite/g++.dg/torture/pr58380.C: In static member function
'static iplugin_factory& selection_to_stdout::get_factory()':
/opt/gcc/work/gcc/testsuite/g++.dg/torture/p
build at the beginning has code which
assigns input_location the EXPR_LOCATION (t), in case it's known.
Tested x86_64-linux.
Thanks!
Paolo.
2013-09-11 Paolo Carlini
* semantics.c (finish_pseudo_destructor_expr): Add location_t
parameter.
Hi,
On 09/12/2013 03:25 PM, Tim Shen wrote:
This patch implement the (expecting) last two features in regex. Work
is easier after this ;)
Great. A quick-quick comment: if these are the last two features, why we
can't un-xfail the testcase which we added latety? Also, a grep revealed
a couple m
On 09/12/2013 04:12 PM, Richard Biener wrote:
On Wed, Sep 11, 2013 at 9:28 PM, Paolo Carlini wrote:
Hi,
when yesterday I analyzed a bit c++/58363 and eventually I committed a
pretty printing fix I noticed that the column was wrong for the pseudo
destructor expression m.~f, pointing at the end
Hi,
On 09/12/2013 04:51 PM, Tim Shen wrote:
On Thu, Sep 12, 2013 at 9:57 AM, Paolo Carlini wrote:
Great. A quick-quick comment: if these are the last two features, why we
can't un-xfail the testcase which we added latety? Also, a grep revealed a
couple more xfails. Can you clarify?
.. please fix the overlong lines, I spotted quite a few.
Paolo.
Hi,
see the audit trail for details. Tested x86_64-linux, committed to mainline.
Thanks,
Paolo.
2013-09-12 Paolo Carlini
PR libstdc++/58403
* include/bits/stl_iterator.h (__normal_iterator<>::operator[],
operator+=, operator+, op
On 09/11/2013 09:31 PM, Jeff Law wrote:
-w is the right thing to do, warnings or the lack thereof aren't
important for what that test is detecting. I'll fix it up momentarily.
I went ahead and added the "-w" myself. I hope you don't mind,
otherwise, just let me know and I will revert/commit som
Hi,
On 09/13/2013 08:51 AM, Kai Tietz wrote:
Hello,
this patch enables the 'long long' use in libstdc++ for Windows native targets.
ChangeLog
2013-09-13 Kai Tietz
* config/os/mingw32/os_defines.h (_GLIBCXX_USE_LONG_LONG):
Enable feature.
* config/os/mingw-w64/os_defines.h (
On 09/13/2013 11:27 AM, Kai Tietz wrote:
The check for this is broken for some Windows targets, due printf
doesn't support in all cases the %ll width modifier. So why probing,
if we know it works.
Which check? I don't see any, this is my point.
Paolo.
Hi,
On 09/13/2013 02:01 AM, Paul Pluzhnikov wrote:
On Wed, Sep 4, 2013 at 9:55 PM, Daniel Krügler
wrote:
Did you mean "pessimises code size", or something else?
Yes.
Daniel's idea proved a good one, and I now have a patch that I am
happy with, and that will be easy to extend to string::at()
Hi,
fixed mainline and 4_8-branch. Tested x86_64-linux.
Thanks,
Paolo.
2013-09-13 Paolo Carlini
PR libstdc++/58415
* include/ext/sso_string_base.h (__sso_string_base<>::
__sso_string_base(__sso_string_base&&)): Fix
On 09/12/2013 06:20 PM, Tim Shen wrote:
On Thu, Sep 12, 2013 at 12:00 PM, Jakub Jelinek wrote:
That is not the right test, because you need to count all tabs (at least
the leading ones, you probably shouldn't have other tabs) as 8 columns
rather than just one. And there are 11 lines that are o
Hi,
Marc Glisse ha scritto:
>Hello,
>
>this patch passes bootstrap+testsuite. The guarantees given by the
>standard on allocators are a bit weird, but I see there is already
>DR2016
>taking care of it.
Patch looks good to me, thanks!
Paolo
... what about debug-mode (and profile-mode)? Is in principle possible to
detect the noexcepts? If we can't exclude that, we should probably change at
the same time the special modes too. Otherwise seems just matter of consistency?
Paolo
Hi,
>I was going one file at a time, and the priority is clearly
>"release"-mode, since this is about performance. I don't think there is
>
>anything wrong with debug-mode having a different exception
>specification
>(it is already binary-incompatible with the default mode) but I
>understand
>w
Hi Marc,
On 09/15/2013 11:12 AM, Marc Glisse wrote:
I had to separate the constructor that takes an allocator from the
default constructor in debug/profile, since in release the noexcept
only applies to one of them (and the testsuite asserts that release
and debug agree on this). An alternativ
On 09/16/2013 07:32 PM, Marc Glisse wrote:
New version that passed testing.
Looks good to me, thanks!
Paolo.
6_64-linux.
Thanks!
Paolo.
////////
/cp
2013-09-17 Paolo Carlini
PR c++/58435
* pt.c (tsubst, [BOUND_TEMPLATE_TEMPLATE_PARM]): Take into account
the cp_type_quals (r) too.
/testsuite
2013-09-17 Paolo Carlini
PR c++/58435
* g++.dg/cpp0x/a
Hi,
On 09/15/2013 03:45 AM, Tim Shen wrote:
...finally.
This patch complete flags specifed in [28.5]. However, `optimize` and
`match_any` are ignored. `format_*` are unimplemented yet.
regex_iterator and regex_token_iterator should work now, but need more
testcases.
Great. Tim, please complete
roducing such TYPE_DECLs in case
of errors (it does that for error recovery reasons, I suppose: just
returning error_mark_node leads to worse diagnostic for eg,
parse/error32.C).
Tested x86_64-linux.
Thanks,
Paolo.
///
/cp
2013-09-17 Paolo Carlini
PR c
Hi,
On 09/17/2013 08:44 PM, Marc Glisse wrote:
Hello,
after vectors, lists. I didn't touch the throw we were discussing
earlier today for now. There will be an inconsistency with debug list
iterators because they use a general wrapper:
- I would need François to tell if that wrapper is ever u
Hi,
committed to mainline/4_8/4_7.
Thanks,
Paolo.
/
2013-09-18 Daniel Morris
Paolo Carlini
PR c++/58458
* doc/implement-cxx.texi: Fix references to the C++ standards.
Index: doc/implement-cxx.texi
Hi,
in this 4.8/4.9 Regression having to do with using declarations we ICE
at the gcc_assert in instantiate_type:
gcc_assert (TREE_CODE (rhs) == ADDR_EXPR
|| TREE_CODE (rhs) == COMPONENT_REF
|| really_overloaded_fn (rhs)
|| (flag_ms_extensions && TREE_CODE (
Hi,
On 09/18/2013 05:51 PM, Marc Glisse wrote:
Hello,
some more containers...
In debug array, we already have throw in noexcept functions, but if I
understand correctly it is only because of syntax limitations for
constexpr
functions and aborts before throwing, although the use of
_GLIBCXX_T
Hi,
> Il giorno 18/set/2013, alle ore 21:38, Paul Pluzhnikov
> ha scritto:
>
>> On Fri, Sep 13, 2013 at 3:02 AM, Paolo Carlini
>> wrote:
>>
>> - The game with the variadic and the non-variadic __throw_out_of_range makes
>> me a little nervous. Let&#x
Hi,
On 09/18/2013 09:23 PM, Paul Pluzhnikov wrote:
Ping x3?
2013/9/11 Paul Pluzhnikov :
Ping x2?
Original message:
http://gcc.gnu.org/ml/gcc-patches/2013-08/msg00394.html
I'm adding Ian in CC.
Paolo.
Hi,
On 09/19/2013 05:46 AM, Marc Glisse wrote:
Hello,
I did not touch the regular basic_string because Paulo usually says
not to touch it, but I could do it as well if wanted.
If you like, please go ahead, there are no ABI issues in this case.
Indeed, in the current implementation the move co
On 09/19/2013 10:50 AM, Paolo Carlini wrote:
Hi,
On 09/19/2013 05:46 AM, Marc Glisse wrote:
Hello,
I did not touch the regular basic_string because Paulo usually says
not to touch it, but I could do it as well if wanted.
If you like, please go ahead, there are no ABI issues in this case
On 09/20/2013 09:46 AM, Marc Glisse wrote:
Hello,
for basic_string, I tried not to add lies about exceptions, but I didn't
remove existing ones.
Of course we should not have lies, I thought we didn't, besides maybe
special cases having to do with the FULLY_DYNAMIC string thing, really a
C++98
.. first blush, I think we have to remove the noexcept from the
non-const forms of begin and end and from clear. Because the string can
be shared...
Thanks,
Paolo.
Great indeed!
More comments later. First nit: please review the various regex_replace
overloads vs inline: if I'm not misreading the diff I see large ones
inline and small ones out of line!?! Should we have a regex.tcc?
Also, old story about ChangeLogs ;) This is not ok:
* include/bi
On 09/20/2013 04:09 PM, Marc Glisse wrote:
On Fri, 20 Sep 2013, Paolo Carlini wrote:
On 09/20/2013 09:46 AM, Marc Glisse wrote:
Hello,
for basic_string, I tried not to add lies about exceptions, but I
didn't
remove existing ones.
Of course we should not have lies, I thought we d
Hi,
this bug looks superficially similar to the already fixed c++/50089: an
ICE on valid in build_base_path for a qualified-id call in a lambda,
which can be worked around by qualifying with this->. It seems to me
that in this case too a fix may boil down to simply using
current_nonlambda_cla
Hi,
Tim Shen ha scritto:
>I think I get it this time :)
>
>Now we have "regex.tcc".
>
>I'll do a full test before committing.
If testing goes well patch is Ok to commit.
Thanks!
Paolo
Hi,
thanks Andreas.
On 9/23/13 3:53 AM, Andreas Schwab wrote:
Paul Pluzhnikov writes:
Index: libstdc++-v3/src/c++11/snprintf_lite.cc
===
--- libstdc++-v3/src/c++11/snprintf_lite.cc (revision 0)
+++ libstdc++-v3/src/c++11/snp
Hi
Andreas Schwab ha scritto:
>What's wrong with always adding the instantiation?
That quite a few targets will not use it and will remain dead in the .so? But I
agree that it's an option, that you can also pursue immediately if you like,
also preapproved (I'm traveling, either you or Paul
On 9/23/13 8:22 AM, Andreas Schwab wrote:
Paolo Carlini writes:
Hi
Andreas Schwab ha scritto:
What's wrong with always adding the instantiation?
That quite a few targets will not use it and will remain dead in the .so?
How many uses are there for the unsigned long version?
I woul
Hi,
On 9/23/13 9:48 AM, Paul Pluzhnikov wrote:
On 9/23/13 4:26 AM, Paolo Carlini wrote:
m68k-linux/./libstdc++-v3/src/.libs/libstdc++.so: undefined reference
to `int std::__int_to_char(char*, unsigned int,
char const*, std::_Ios_Fmtflags, bool)'
Reproduced on i686.
Sorry about the tr
Hi,
On 9/23/13 11:02 AM, Paul Pluzhnikov wrote:
On 9/23/13 7:54 AM, Paolo Carlini wrote:
Testing this patch:
In fact, however, that unsigned long long instantiation isn't
*unconditionally* available, see locale-inst.cc.
Thanks,
I think we have to use
unsigned long as a fall
On 9/23/13 10:55 AM, Marc Glisse wrote:
Hello,
this patch was tested on x86_64 with a bootstrap and a simple make -k
check, without regression. Note that it doesn't completely fix 56166, it
merely admits that we may currently throw and avoids turning that into
std::terminate.
Of course.
Patc
Hi again,
It is funny that with fully dynamic strings, the copy constructor is
"better" than the move constructor: faster, doesn't throw, etc. I
think we should remove the move constructor in that case, or at least
make it act the same as the copy constructor. I didn't mark the copy
constructo
Hi,
On 9/23/13 2:23 PM, Marc Glisse wrote:
On Mon, 23 Sep 2013, Paolo Carlini wrote:
On 9/23/13 10:55 AM, Marc Glisse wrote:
Hello,
this patch was tested on x86_64 with a bootstrap and a simple make
-k check, without regression. Note that it doesn't completely fix
56166, it
merely a
On 9/23/13 3:44 PM, Marc Glisse wrote:
Sorry.
You are welcome. Thanks for the time you are spending on these details!
Paolo.
Hi,
On 9/24/13 11:13 AM, Marc Glisse wrote:
Hello,
bootstrap+testsuite ok. I think all container iterators are done, but
not the containers themselves.
Ok, thanks.
Paolo.
Hi,
On 9/24/13 11:35 AM, Marek Polacek wrote:
I admit I haven't spent much time on this, but it seems we should just
check whether we can set the expr location before actually setting it...
Regtested/bootstrapped on x86_64-linux, ok for trunk?
Two minor nits (assuming the general idea makes se
On 9/24/13 5:37 PM, Marc Glisse wrote:
Hello,
this was only minimally tested since trunk is broken at the moment.
There don't seem to be specific tests for the existing functors, so a
couple tests for the new specializations seem good enough.
What about at least covering all of them? Just to m
On 9/25/13 10:46 AM, Andrew MacLeod wrote:
I was going to bring it up at some point too. My preference is
strongly to simply eliminate the space on methods...
Which wouldn't be so weird: in the libstdc++-v3 code we do it all the time.
Paolo.
On 9/27/13 4:34 AM, Jonathan Wakely wrote:
On 27 September 2013 03:15, Tim Shen wrote:
POSIX ERE says that escaping an ordinary char, say R"\n" is not
permitted, because 'n' is not a special char. However, they also say
that : "Implementations are permitted to extend the language to allow
these.
Hi
Tim Shen ha scritto:
>Do I need to bootstrap again?
Nah, only double check that the testcase you are un-xfail-ing uses
-std=gnu++11, otherwise will not pass ;)
Paolo
Hi,
"François Dumont" ha scritto:
>I also get your remark about the open round bracket, I didn't know that
>
>round bracket was the other name for parentheses ! I also fix the one
>you pointed me, I will be more careful next time.
No problem ;) For your linguistic curiosity, I often find myse
Hi,
thus the below are the patches which I'm applying to mainline and
4_7/4_8, respectively. Tested x86_64-linux.
Thanks,
Paolo.
/
2013-09-30 Chris Jefferson
PR libstdc++/58437
* include/bits/stl_algo.h (__move_median_first): Rename to
__mov
Hi,
this ICE seems easy to avoid: just check the return value of
make_typename_type for error_mark_node, like we normally do everywhere
else in the parser.
Tested x86_64-linux.
Thanks,
Paolo.
///
/cp
2013-09-30 Paolo Carlini
PR c++/58563
Hi,
Tim Shen ha scritto:
>Is it OK not to bootstrap it ? Tested under -m64 and -m32.
Ok, thanks.
Paolo
Hi,
> Il giorno 02/ott/2013, alle ore 00:03, Tim Shen ha
> scritto:
>
>> On Mon, Sep 30, 2013 at 2:25 PM, Paolo Carlini
>> wrote:
>> 3- Tweak the implementation status page
>> libstdc++/doc/xml/manual/status_cxx2011.xml (possibly clarify bits still
>>
Hi,
> Il giorno 02/ott/2013, alle ore 00:21, Tim Shen ha
> scritto:
>
>> On Tue, Oct 1, 2013 at 6:08 PM, Paolo Carlini
>> wrote:
>> What do you mean by "not well defined"? Non confoming? Why?
>
> I don't know if the word 'define&
On 10/02/2013 01:45 AM, Tim Shen wrote:
On Tue, Oct 1, 2013 at 6:41 PM, Paolo Carlini wrote:
Ok, thus just say that transform_primary is unimplented. Please also add a comment inline
in the code explaining the issue, but don't word it in term of , because
is just what it is per C++11
On 10/02/2013 02:00 AM, Tim Shen wrote:
On Tue, Oct 1, 2013 at 7:49 PM, Paolo Carlini wrote:
Thanks. But then the function actually *is* implemented, saying 'not
implemented' is misleading. Please change the xml to something like 'isn't
correctly implemented', or mor
10-02 Paolo Carlini
PR c++/58565
* semantics.c (potential_constant_expression_1): Handle LABEL_EXPR.
/testsuite
2013-10-02 Paolo Carlini
PR c++/58565
* g++.dg/parse/crash64.C: New.
Index: cp/semant
Hi,
On 10/02/2013 12:19 PM, Gerald Pfeifer wrote:
On Tue, 1 Oct 2013, Tim Shen wrote:
Hi, libstdc++-v3 is ready for releasing.
Nice!
Is it Ok to apply? By the way, do we need a News entry for this
improvement?
Yes, and yes. :-)
Just one question "improved experimental support" sounds a bi
On 10/02/2013 12:45 PM, Jonathan Wakely wrote:
On 2 October 2013 11:41, Paolo Carlini wrote:
Minimally, I would talk about "improved support": the evolution from
-std=c++0x to -std=c++11 meant that we aren't in experimental mode anymore.
From speaking to Jason he's prett
On 10/02/2013 12:59 PM, Jakub Jelinek wrote:
We have announced only core language feature completeness, the library
was known to be incomplete. And, I think for 4.9 the library C++11
support is still meant to be experimental because of the ABI issues,
where we know we'll need to change std::str
Hi,
this patchlet fixes the issue reported by Daniel by simply adding
nullptr_t to the global namespace in stddef.h (over which luckily we
have control). Tested x86_64-linux.
Thanks,
Paolo.
/
2012-09-28 Paolo Carlini
PR c++/54249
* ginclude/stddef.h
09-28 Paolo Carlini
PR c++/54738
* decl2.c (build_offset_ref_call_from_tree): Add tsubst_flags_t
parameter.
* pt.c (tsubst_copy_and_build): Adjust.
* parser.c (cp_parser_postfix_expression): Likewise.
* cp-tree.h: Adjust declaration.
/testsuite
20
Hi,
sanity checked x86_64-linux (both cases), committed to mainline.
Thanks,
Paolo.
/
2012-10-01 Paolo Carlini
PR libstdc++/54757
* include/ext/random (rice_distribution<>::operator()): Use std::hypot
only if _GLIBCXX_USE_C99_MA
Hi,
I'm adding the testcase and closing the PR. Tested x86_64-linux.
Thanks,
Paolo.
/
2012-10-04 Paolo Carlini
PR c++/54323
* g++.dg/cpp0x/pr54323.C: New.
Index: g++.dg/cpp0x/pr54
Hi,
I'm adding the testcase and closing the PR. Tested x86_64-linux.
Thanks,
Paolo.
/
2012-10-04 Paolo Carlini
PR c++/53403
* g++.dg/template/friend53.C
Index: g++.dg/template/frien
Hi,
I'm adding the testcase and closing the PR. Tested x86_64-linux.
Thanks,
Paolo.
2012-10-04 Paolo Carlini
PR c++/52233
* g++.dg/cpp0x/alias-decl-23.C: New.
Index: g++.dg/cpp0x/alias-decl
Hi,
I'm adding the testcase and closing the PR. Tested x86_64-linux.
Thanks,
Paolo.
/
2012-10-05 Paolo Carlini
PR c++/50893
* g++.dg/cpp0x/defaulted38.C: New.
Index: g++.dg/cpp0x/defaulte
Hi,
remove some cruft noticed by Marc (and myself). Sanity checked
x86_64-linux, committed to mainline.
Thanks,
Paolo.
//
2012-10-05 Paolo Carlini
* include/c_global/cstdlib: Remove redundant pasto code protected
by __GXX_EXPERIMENTAL_CXX0X__
On 10/06/2012 02:33 AM, Joe Seymour wrote:
I'm seeing tr2/headers/all.cc fail in the libstdc++ testsuite:
In file included from
src/gcc-mainline/libstdc++-v3/testsuite/tr2/headers/all.cc:22:0:
/scratch/jseymour/mainline/i686-pc-linux-gnu/install/opt/codesourcery/include/c++/4.8.0/tr2/dynamic_bit
Hi,
On 10/06/2012 03:52 PM, Jason Merrill wrote:
On 09/27/2012 07:08 AM, Paolo Carlini wrote:
Then checking error_operand_p (decl) in is_capture_proxy solves the
problem but now the question is: do we have reasons to believe that such
VAR_DECLs should never ever reach is_normal_capture_proxy
lated tweaks noticed while going through the code).
Tested x86_64-linux.
Thanks,
Paolo.
//
2012-10-07 Paolo Carlini
* pt.c (fold_non_dependent_expr_sfinae): Remove static specifier.
(tsubst_copy_and_build): Use get_target_expr_sfinae.
* c
Hi,
in this PR submitter points out that in the -Wparentheses warning, for, eg,
char in[4]={0}, out[6];
out[1] = in[1] & 0x0F | ((in[3] & 0x3C) << 2);
warning: suggest parentheses around arithmetic in operand of ‘|’
[-Wparentheses]
the caret points to end of the expression, ie the final clos
On 10/08/2012 03:57 PM, Jason Merrill wrote:
This is definitely an improvement, though for warnings about issues
with the left or right argument, we could use the EXPR_LOCATION of the
problematic argument rather than the location of the new operand.
I agree. Let me see if I can figure out somet
On 10/08/2012 03:43 PM, Pavel Chupin wrote:
This issue has been introduced in 4.7.
Irrespective of what we are eventually going to do from a practical
point of view, I think it would be important to understand when/what
introduced the issue: did you analyze that in any detail?
Thanks,
Paolo.
Hi,
Pavel Chupin ha scritto:
>It has been changed here:
>http://gcc.gnu.org/git/?p=gcc.git;a=commit;h=630d52ca0a88d173f89634a5d7dd8aee07d04d80
>
>subj:"Move gthr to toplevel libgcc"
I see, thanks. Let's add Rainer in CC, see if he expected this to happen or not.
Paolo
On 10/08/2012 04:04 PM, Paolo Carlini wrote:
On 10/08/2012 03:57 PM, Jason Merrill wrote:
This is definitely an improvement, though for warnings about issues
with the left or right argument, we could use the EXPR_LOCATION of
the problematic argument rather than the location of the new operand
On 10/08/2012 11:44 PM, Jason Merrill wrote:
On 10/08/2012 05:31 PM, Paolo Carlini wrote:
So, there is a serious difficulty, I'm afraid: for the example at issue,
EXPR_LOCATION (arg_left) is 0 not any meaningful value. And of course
EXPR_LOC_OR_HERE would not be better in this case, would
Hi again,
On 10/08/2012 11:44 PM, Jason Merrill wrote:
On 10/08/2012 05:31 PM, Paolo Carlini wrote:
So, there is a serious difficulty, I'm afraid: for the example at issue,
EXPR_LOCATION (arg_left) is 0 not any meaningful value. And of course
EXPR_LOC_OR_HERE would not be better in this
Paolo Carlini
PR libstdc++/54869
* include/ext/random (simd_fast_mersenne_twister_engine): Provide
only for little endian targets.
* include/ext/random.tcc: Likewise.
* config/cpu/i486/opt/ext/opt_random.h: Likewise.
* testsuite/lib/libstdc++.exp
On 10/09/2012 05:04 PM, Rainer Orth wrote:
Paolo Carlini writes:
apparently simd_fast_mersenne_twister_engine is designed (so far) for
little endian targets only.
Patch sanity checked x86_64-linux (with the __BYTE_ORDER__ ==
__ORDER_LITTLE_ENDIAN__ checks artificially altered to return false
Hi,
I'm adding the testcase and closing the PR as fixed for 4.8.0.
Thanks,
Paolo.
/
2012-10-09 Paolo Carlini
PR c++/53763
* g++.dg/cpp0x/decltype43.C: New.
Index: g++.dg/cpp0x/decltyp
Hi,
more great stuff from Daniel. Tested x86_64-linux, committed to mainline.
Thanks,
Paolo.
//
2012-10-09 Daniel Krugler
* include/std/type_traits (common_time): Provide "SFINAE-friendly"
implementation.
(__success_type, __failure_type): Fix.
Hi,
I'm adding the testcase and closing the PR as fixed. Tested x86_64-linux.
Thanks,
Paolo.
//
2012-10-10 Paolo Carlini
PR c++/53307
* g++.dg/cpp0x/decltype44.C: New.
Index: g++.dg/cpp0x/decltyp
Hi,
adding the testcase and closing the PR as fixed.
Thanks,
Paolo.
//
2012-10-10 Paolo Carlini
PR c++/50478
* g++.dg/cpp0x/initlist67.C: New.
Index: g++.dg/cpp0x/initlist67.C
Hi,
adding the testcase and closing the PR as fixed.
Thanks,
Paolo.
2012-10-10 Paolo Carlini
PR c++/53741
* g++.dg/cpp0x/lambda/lambda-ice9.C: New.
Index: g++.dg/cpp0x/lambda/lambda-ice9.C
Hi,
On 10/03/2012 11:57 AM, Gopalasubramanian, Ganesh wrote:
Testing was done before posting the patch. It was successful.
This change is now in:
http://gcc.gnu.org/ml/gcc-cvs/2012-10/msg00418.html
and it looks like is breaking the build for me:
build/genattrtab
/scratch/Gcc/svn-dir
Hi,
On 10/10/2012 12:53 PM, Jakub Jelinek wrote:
Yeah, clearly a different version of the patch has been posted
vs. what has been checked in. The difference is removal of the
(define_cpu_unit "bdver1-mult" "bdver1_mult")
line (present in the posted patch, not in the checked in patch).
Also, th
On 10/10/2012 01:00 PM, Jakub Jelinek wrote:
I have removed the extra line as obvious in SVN, to allow my
bootstraps to continue.
Thanks!
Paolo.
... tested x86_64-linux. Committed to mainline.
Paolo.
2012-10-10 Paolo Carlini
* include/std/type_traits (__do_common_type_impl): Revert for now
LWG 2141-related change.
* testsuite/20_util/common_type/requirements/typedefs-1.cc: Likewise
On 10/10/2012 02:06 PM, Daniel Krügler wrote:
2012/10/10 Paolo Carlini :
... tested x86_64-linux. Committed to mainline.
I'd like to mention that this patch does not reflect what the core
language says, e.g.
static_assert(is_type, int>(), "");
Should assert, the correc
Hi,
adding the testcase and closing the PR as fixed in mainline.
Thanks,
Paolo.
//
2012-10-10 Paolo Carlini
PR c++/53122
* g++.dg/cpp0x/auto35.C: New.
Index: g++.dg/cpp0x/auto35.C
===
--- g++.dg
ass" vs "union" (when it makes
sense, I'm leaving alone bases, virtuals, already rejected by the parser
for unions)
Tested x86_64-linux, as usual.
Thanks,
Paolo.
//
/cp
2012-10-10 Paolo Carlini
PR c++/53761
* class.c (
On 10/10/2012 07:16 PM, Andrew MacLeod wrote:
This bootstraps and causes no new regressions on the 4.7 branch.Is
it OK to check this into the 4.7 branch right now?
Yes, thanks.
Paolo.
101 - 200 of 3018 matches
Mail list logo
