2014-10-07 23:13 GMT+02:00 Jason Merrill ja...@redhat.com:
On 09/24/2014 05:15 PM, Jason Merrill wrote:
On 09/24/2014 05:06 PM, Fabien Chêne wrote:
Unfortunately, just stripping the USING_DECL in lookup_and_check_tag
does not really work because some diagnotic codes expect the
USING_DECL
Hi,
As a followup, the following patch homogeneise some diagnostics that
relate to uninitialized const or reference members.
Tested x86_64 linux in progress, OK to commit for next stage 1 if that
succeeds ? (or trunk otherwise, I dare to mention it).
2014-03-28 Fabien Chêne fab...@gcc.gnu.org
2014-03-28 20:27 GMT+01:00 Mike Stump mikest...@comcast.net:
Just a nit...
2014-03-28 Fabien Chêne fab...@gcc.gnu.org
* cp/init.c (perform_member_init): homogeneize uninitialized
diagnostics.
Sentences begin with an upper case letter, and spelling... Homogenize..
I will fix
2014-03-28 17:59 GMT+01:00 Jason Merrill ja...@redhat.com:
On 03/27/2014 05:32 PM, Fabien Chêne wrote:
+ permerror (DECL_SOURCE_LOCATION (current_function_decl),
+uninitialized reference member in %q#T, type);
+ inform (DECL_SOURCE_LOCATION
2014-03-28 17:59 GMT+01:00 Jason Merrill ja...@redhat.com:
[...]
The inform should only happen if permerror returns true (i.e. without
-fpermissive -w). OK with that change.
I did a little tour around the permerror uses, and found that in decl.c:
if (permerror (input_location,
specification in %q#D here,
olddecl);
should the second permerror be a note instead ?
Yes.
OK to commit the attached patch ?
Tested x86_64 linux, though this piece of code does not seem to be
covered by the testsuite.
2014-04-02 Fabien Chêne fab...@gcc.gnu.org
* cp
2014-04-02 22:39 GMT+02:00 Jason Merrill ja...@redhat.com:
On 04/02/2014 04:21 PM, Fabien Chêne wrote:
* cp/decl.c (duplicate_decls): Check for the return of
permerror before emitting a note.
You don't need cp/ within cp/ChangeLog. OK with that change.
I was a bit too optimistic
Hi,
Following the previous patchlet about conditional notes after
'permerror', same cleanup with 'warning'. Tested x86_64 linux without
regressions. OK to commit ?
cp/ChangeLog
2014-04-04 Fabien Chêne fab...@gcc.gnu.org
* class.c (find_abi_tags_r): Check for the return of warning
Hi,
next victim of the cleanup: warning_at.
Tested x86_64 linux without regressions. OK to commit ?
cp/ChangeLog
2014-04-04 Fabien Chêne fab...@gcc.gnu.org
* decl.c (duplicate_decls): Check for the return of warning_at
before emitting a note.
(warn_misplaced_attr_for_class_type
Hi,
Idem than the previous patchlets, this time concerning 'pedwarn'.
Tested x86_64 linux. OK to commit ?
cp/ChangeLog
2014-04-04 Fabien Chêne fab...@gcc.gnu.org
* pt.c (check_template_variable): Check for the return of pedwarn
before emitting a note.
* parser.c
Hi,
We fail here to create a typename_type on dependent using
declarations. In fact, facing a USING_DECLs on spotted places, either
we want to strip non-dependent USING_DECLs or we want to create a
typename_type. The attached patch simply propagates the change made to
fix c++/14258 through
2014-01-28 Jason Merrill ja...@redhat.com:
On 01/27/2014 04:28 PM, Fabien Chêne wrote:
+ if (DECL_DEPENDENT_P (decl) USING_DECL_TYPENAME_P (decl))
+{
+ /* We have found a type introduced by a using
+declaration at class scope that refers to a dependent
+type
Hi,
This bug seems already fixed on mainline. I have added two testcases,
but as the C++11 one is not obvious to me, I guess this path does not
qualify as obvious. Incidentally, while writing the C++11 testcase, I
realized that the diagnostic was not emitted at the proper location
and fixed it.
: Likewise.
* g++.dg/init/ctor4.C: Likewise.
* g++.dg/init/ctor8.C: Likewise.
* g++.dg/init/uninitialized1.C: Likewise.
--
Fabien
2014-02-06 18:04 GMT+01:00 Fabien Chêne fabien.ch...@gmail.com:
Hi,
This bug seems already fixed on mainline. I have added two testcases,
but as the C
Ping (yeah boring to review!)
2014-02-23 20:36 GMT+01:00 Fabien Chêne fabien.ch...@gmail.com:
Ahem, patch resubmitted with the testsuite correctly adjusted this
time. Tested x86_64 linux, still OK to commit ?
2014-02-23 Fabien Chene fab...@gcc.gnu.org
PR c++/52369
* cp
2014-02-28 22:52 GMT+01:00 Fabien Chêne fabien.ch...@gmail.com:
Incidentally, while moving the diagnostic concerning the uninitialized
field from an error to an inform, I realized that the syntactic sugar
%q#D is no longer honored an is treated as %qD, is it expected ?
No, how do you mean
2014-02-28 22:52 GMT+01:00 Fabien Chêne fabien.ch...@gmail.com:
2014-02-28 22:27 GMT+01:00 Jason Merrill ja...@redhat.com:
Let's change the C++11 diagnostic to match the C++98 diagnostic. So,
uninitialized const member in %q#T + %qD should be initialized.
OK.
Hmm, sorry to iterate
2014-03-21 1:33 GMT+01:00 Paul Pluzhnikov ppluzhni...@google.com:
Greetings,
Attached patch deletes code to warn about repeated friend declaration.
Why not making this warning suppressable, instead of removing it ?
Shouldn't it fall under -W(no)-redundant-decls ?
--
Fabien
Hi, sorry for the delay,
2014-03-03 2:16 GMT+01:00 Jason Merrill ja...@redhat.com:
[...]
Yes, in C++11 the point of use is the source location of the constructor,
which is going to be different from where the constructor is called. I just
meant use the same wording.
There we are, locating a
2014-03-07 22:43 GMT+01:00 Jason Merrill ja...@redhat.com:
The first patch changes the C++ testsuite to run in C++14 mode as well as
C++98 and C++11.
As a result, specifying { target c++11 } matches c++11 and c++1y mode.
{ target c++1y } matches c++1y only, and { target c++98 } matches c++98
2014-10-09 15:34 GMT+02:00 Jason Merrill ja...@redhat.com:
[...]
If the USING_DECL is returned, the code below will be rejected as
expected, but the error message will not mention the line where the
USING_DECL appears as the previous definition, but at the target
declaration of the USING_DECL
is to know if stripping USING_DECLs is
desirable. Not very exciting to fix it this way, but that is the only
solution I managed to find.
Tested x86_64 linux without regressions. OK to commit to trunk ? And
branches after some weeks of incubation ?
gcc/cp/ChangeLog
2014-09-24 Fabien Chêne fab
Hi,
2011/9/20 Jason Merrill ja...@redhat.com:
On 09/17/2011 09:44 AM, Fabien Chêne wrote:
I tried various things without success, and I ended up hacking
supplement_binding_1 to handle those ENUMERAL_TYPEs.
I am all ear for another solution ...
Your solution seems reasonable to me
... with the ChangeLog
gcc/ChangeLog
2011-09-21 Fabien Chêne fab...@gcc.gnu.org
PR c++/26256
* dbxout.c (dbxout_type_fields): Ignore using declarations.
gcc/testsuite/ChangeLog
2011-09-21 Fabien Chêne fab...@gcc.gnu.org
PR c++/26256
* g++.dg/lookup
2011/9/21 Jason Merrill ja...@redhat.com:
On 09/21/2011 01:59 PM, Fabien Chêne wrote:
if (!DECL_DEPENDENT_P (field))
- continue;
+ {
+ tree using_decl = USING_DECL_DECLS (field);
+ if ((TREE_CODE (using_decl) == FIELD_DECL
2011/9/22 Jason Merrill ja...@redhat.com:
On 09/22/2011 04:22 AM, Fabien Chêne wrote:
I would have thought that we want to do something with OVERLOAD here,
in order to get rid of PR c++/30195 and c++/25994 (removing a wrong
diagnostic additionaly)... But those PRs are already fixed
2011/9/24 Jason Merrill ja...@redhat.com:
[...]
Tested x86_64-pc-linux-gnu, applied to trunk. I'm also considering applying
it to 4.6 since we got more strict about the pre-253 rule in 4.6.
Great, I would be glad to see it applied to 4.6. If you do that, you
may also want to adjust the last
in supplement_binding_1. Tested x86_64-unknown-linux-gnu, OK
to commit?
gcc/ChangeLog
2011-09-21 Fabien Chêne fab...@gcc.gnu.org
PR c++/26256
* dbxout.c (dbxout_type_fields): Ignore using declarations.
gcc/testsuite/ChangeLog
2011-09-21 Fabien Chêne fab...@gcc.gnu.org
PR c
2011/9/25 Paolo Carlini pcarl...@gmail.com:
... nitpicking, of course, but in the testcases you have many blank trailing
lines (and also some gratuitus, imho, blank lines in the middle)
Indeed, I've removed the blank trailing lines, and some in the middle,
not all though, I like it readable as
Jason,
Please ignore the previous patch, where I have introduced an
unintentional modification for PR c++/30195 in search.c, here is a new
one, sorry about that.
--
Fabien
Index: gcc/testsuite/g++.old-deja/g++.other/using1.C
===
2011/9/25 Paolo Carlini paolo.carl...@oracle.com:
On 09/25/2011 08:39 PM, Fabien Chêne wrote:
And as a really minor detail, some empty constructor I added in
libstdc++-v3/src/future.cc, libstdc++-v3/src/system_error.cc, and
libstdc++-v3/testsuite/util/testsuite_error.h (r158797) might
2011/9/23 Jason Merrill ja...@redhat.com:
On 09/22/2011 05:11 PM, Fabien Chêne wrote:
2011/9/22 Jason Merrillja...@redhat.com:
I don't, it just seemed strange to handle functions differently from
other
decls here. But when I look more closely I see that we're in
lookup_field_1, which
Hi,
2011/9/26 Jason Merrill ja...@redhat.com:
On 09/25/2011 05:06 PM, Fabien Chêne wrote:
+ else if ((using_decl = strip_using_decl (member)) != member)
+ /* If it is a using decl, use its underlying decl. */
+ type_decl = strip_using_decl (type_decl);
- if (DECL_NAME (field
2011/10/11 Jason Merrill ja...@redhat.com:
On 10/10/2011 03:56 PM, Fabien Chêne wrote:
It tried to add the target declaration of a USING_DECL in the
method_vec of the class where the USING_DECL is declared. Thus, I
copied the target decl, adjusted its access, and then called
add_method
[...]
Does the attached testcase checked what you mention ?
... with the testcase attached.
--
Fabien
// { dg-do run }
template class T
struct A
{
int f() { return 1; }
};
template class T
struct B : AT
{
int f() { return 2; }
using AT::f;
void g()
{
if (AT::f() != 1 )
Hi,
2011/10/12 Jason Merrill ja...@redhat.com:
Copying the decl is unlikely to do what we want, I think. Does putting
the
target decl directly into the method vec work?
Unfortunately not, it ends up with the same error: undefined
reference.
Hunh, that's surprising.
Furthermore, I don't
2012/3/29 Jason Merrill ja...@redhat.com:
On 03/08/2012 04:34 PM, Fabien Chêne wrote:
* decl.c (grokdeclarator): Call strip_using_decl.
I would think we ought to be stripping USING_DECLs at a lower level, when we
first look up the name in the parser. They shouldn't make it as far
2012/3/12 Fabien Chêne fabien.ch...@gmail.com:
Salut Dodji,
2012/3/12 Dodji Seketeli do...@seketeli.org:
[...]
Index: gcc/cp/decl.c
===
--- gcc/cp/decl.c (revision 184891)
+++ gcc/cp/decl.c (working copy)
@@ -8686,6
2012/4/7 Jason Merrill ja...@redhat.com:
On 04/07/2012 11:37 AM, Fabien Chêne wrote:
Perhaps it is more correct like that, in cp_parser_set_decl_spec_type ?
Even that seems late. Why not just return the target decl from
cp_parser_class_name?
Ah yes, that's slightly better.
(I've kept
2012/4/11 Jason Merrill ja...@redhat.com:
[...]
Your ChangeLog needs to be adjusted. :)
I did write an updated ChangeLog, but I pasted here the wrong one...
I committed it to trunk yesterday, hopefully with the correct
ChangeLog . I'll be backporting it to 4.7 after a relaxing weekend :-)
--
2012/2/29 Jason Merrill ja...@redhat.com:
On 02/28/2012 05:06 PM, Fabien Chêne wrote:
I agree, this is not efficient but I didn't find a better place.
perhaps in cp_parser_enumerator_list, that would require adding an
additional parameter to keep track of all the enum DECLs. Is it what
you
2012/5/21 Paolo Carlini paolo.carl...@oracle.com:
On 05/21/2012 01:45 AM, Michael Hope wrote:
The testsuite for PR52796 uses the 'target c++11' selector which doesn't
exist in 4.6.
This patch backports the selector, clearing the 'ERROR:
g++.dg/cpp0x/variadic-value1.C:
syntax error in target
2012/5/7 Jason Merrill ja...@redhat.com:
On 05/06/2012 04:06 PM, Fabien Chêne wrote:
+ if (late_enum_values)
+ VEC_safe_push (tree, gc, late_enum_values, decl);
I would think you could walk the TYPE_VALUES list directly, rather than copy
it into a temporary VEC.
Indeed, let's
for improvement here, though I'm not sure the C++ front
end is the better place to de-virtualize.
Tested x84_64-unknown-linux-gnu without regressions. OK to commit ?
gcc/testsuite/ChangeLog
2012-08-12 Fabien Chêne fab...@gcc.gnu.org
PR c++/11750
* g++.dg/inherit/vitual9.C: New.
gcc
Hi Paolo,
2012/8/23 Jason Merrill ja...@redhat.com:
[...]
The below passes testing, anyway.
OK.
Jason
Thanks for tackling this using bug !
Incidentally, as you seem to be used to visiting old C++ bugs, feel
free to ping/assign me on bugs that concern using-declarations --
obviously if you
-09 Fabien Chêne fab...@gcc.gnu.org
PR c++/54537
* cp-tree.h: Check OVL_USED with OVERLOAD_CHECK.
* name-lookup.c (do_nonmember_using_decl): Make sure we have an
OVERLOAD before calling OVL_USED.
2012-09-09 Fabien Chêne fab...@gcc.gnu.org
PR c++/54537
Oops, not sure how I test that change initially, or I must be blind,
because it triggers an error in tr1/cmath about pow. I'll see what I
can do...
2012/9/10 Jason Merrill ja...@redhat.com:
OK.
Jason
--
Fabien
2012/6/3 Jason Merrill ja...@redhat.com:
On 05/24/2012 09:18 AM, Jason Merrill wrote:
OK, thanks.
I notice you haven't checked the patch in yet, is there a problem?
Not at all, just lack of time, so many problems/holidays to tackle at
the moment... That is May month in France ;-)
I'll be
2012/6/3 Gabriel Dos Reis g...@integrable-solutions.net:
On Sun, Jun 3, 2012 at 10:56 AM, Fabien Chêne fabien.ch...@gmail.com wrote:
2012/6/3 Jason Merrill ja...@redhat.com:
On 05/24/2012 09:18 AM, Jason Merrill wrote:
OK, thanks.
I notice you haven't checked the patch in yet
2012/6/5 Jason Merrill ja...@redhat.com:
OK.
Out of curiosity, do you happen to know what kind of problem was
triggered here ?
Shouldn't we fix the underlying issue as well ? Unless that the
canonical way to solve it be to simply return earlier...
Thanks,
--
Fabien
2012/6/3 Fabien Chêne fabien.ch...@gmail.com:
2012/6/3 Jason Merrill ja...@redhat.com:
On 05/24/2012 09:18 AM, Jason Merrill wrote:
OK, thanks.
I notice you haven't checked the patch in yet, is there a problem?
Not at all, just lack of time, so many problems/holidays to tackle
2012/6/6 Jason Merrill ja...@redhat.com:
[...]
Often if we continue parsing something on the assumption that the previous
bits are correct it leads to problems; that's all there is to this bug.
When we see
using sat::Solvable::bool_type;
cp_parser_alias_declaration eats sat and then tries
2012/6/7 Fabien Chêne fabien.ch...@gmail.com:
[...]
... committed as rev 188294.
I will backport it to 4.7 when it unfreezes.
... Eventually backported as rev 189021.
--
Fabien
2011/10/27 Jason Merrill ja...@redhat.com:
[...]
3) seems complicated: in finish_member_declaration, we must put away
the decl into TYPE_FIELDS or TYPE_METHODS, but we would like to put
the target_decl into TYPE_METHODS (and call add_method), and at the
same time put its using decl into
Hi,
2011/11/9 Jason Merrill ja...@redhat.com:
On 11/09/2011 01:02 PM, Joseph S. Myers wrote:
To confirm: what do the PASS or FAIL lines look like?
For tests run in both modes, they look like
PASS: g++.dg/whatever -std=c++98
PASS: g++.dg/whatever -std=c++11
Nice, but ... is there a way to
2011/11/10 Dodji Seketeli do...@seketeli.org:
Fabien Chêne fabien.ch...@gmail.com a écrit:
Index: gcc/dbxout.c
===
--- gcc/dbxout.c (revision 178088)
+++ gcc/dbxout.c (working copy)
@@ -1518,6 +1518,8
Hi,
As discussed in the audit trail, here is a patch that fixes this PR
and all its duplicates.
Tested x86_64-unknown-linux-gnu without regressions. OK to commit ?
gcc/testsuite/ChangeLog
2011-11-18 Fabien Chêne fab...@gcc.gnu.org
PR c++/51188
* g++.dg/lookup/using46.C: New
2011/11/18 Jason Merrill ja...@redhat.com:
On 11/18/2011 05:18 AM, Fabien Chêne wrote:
+template size_t, size_t struct AlignedBuffer;
+template size_t size struct AlignedBuffer
+ size, 8 {
+};
This testcase will break on targets where alignof(void*) != 8; just define
the base
on x86_64-unknown-linux-gnu.
OK for trunk and 4.6 ?
gcc/cp/ChangeLog:
2011-05-07 Fabien Chêne fab...@gcc.gnu.org
PR c++/48859
* init.c (diagnose_uninitialized_cst_or_ref_member_1): stop the
recursion if there is user defined constructor.
gcc/testsuite/ChangeLog:
2001-05-07
Hi,
PR c++/20039 was closed without providing a testcase, here's one.
tested x86_64-unknown-linux-gnu.
OK for trunk ?
gcc/testsuite/ChangeLog:
2011-05-09 Fabien Chêne fab...@gcc.gnu.org
PR c++/20039
* g++.dg/init/pr20039.C: New.
--
Fabien
pr20039.patch
Description: Binary
44086.
I have changed error to permerror only for the cases where it was
needed for the PR listed above.
OK for the 4.6 branch ?
gcc/cp/ChangeLog:
2011-05-21 Fabien Chêne fab...@gcc.gnu.org
* init.c (diagnose_uninitialized_cst_or_ref_member_1): Use
permerror instead of error
.
OK for 4.6 ?
I would like to add the testcase pr25811-3.C to Trunk, is it OK ?
gcc/cp/ChangeLog:
2011-05-25 Fabien Chêne fab...@gcc.gnu.org
* init.c (diagnose_uninitialized_cst_or_ref_member_1): Use
permerror instead of error, adjust the error count.
gcc/testsuite/ChangeLog
for another solution ...
Attached is an updated patch that should address most of your previous
comments (except for c++0X enums). Tested x86_64_unknown-linux-gnu
without new regressions.
Is it in better shape ?
gcc/ChangeLog
2011-09-15 Fabien Chêne fab...@gcc.gnu.org
PR c++/26256
Ping ?
2012/1/27 Fabien Chêne fabien.ch...@gmail.com:
Hi Gerald,
2012/1/13 Fabien Chêne fabien.ch...@gmail.com:
[...]
Mind suggesting a snippet for our release notes at
http://gcc.gnu.org/gcc-4.7/changes.html ?
Yes, sure, thanks for suggestion. Unfortunately, my machine is
currently down
2012/2/12 Gerald Pfeifer ger...@pfeifer.com:
On Fri, 27 Jan 2012, Fabien Chêne wrote:
I get back to you for the snippet about deprecated access
declarations. I would also find it sensible to advertise about the fix
of c++/14258, a popular bug I have hit myself many times. OK to commit
)
work correctly.
Tested x86_64-unknown-linux-gnu without regressions.
gcc/testsuite/ChangeLog
2012-02-16 Fabien Chêne fab...@gcc.gnu.org
* g++.dg/template/using21.C: New.
* g++.dg/template/using22.C: Likewise.
gcc/cp/ChangeLog
2012-02-16 Fabien Chêne fab...@gcc.gnu.org
2012/2/16 Jason Merrill ja...@redhat.com:
On 02/16/2012 01:47 PM, Fabien Chêne wrote:
+ tree binfo_type = TYPE_MAIN_VARIANT (BINFO_TYPE (binfo));
BINFO_TYPE should already be its TYPE_MAIN_VARIANT. Why isn't it here?
For (2), the lookup was failing because the flag
-unknown-linux-gnu, OK for 4.7 ?
gcc/testsuite/ChangeLog
2012-02-27 Fabien Chêne fab...@gcc.gnu.org
* g++.dg/cpp0x/forw_enum11.C: New.
gcc/cp/ChangeLog
2012-02-27 Fabien Chêne fab...@gcc.gnu.org
* cp-tree.h (insert_into_classtype_sorted_fields): Declare.
* class.c
2012/2/28 Jason Merrill ja...@redhat.com:
On 02/28/2012 03:36 PM, Fabien Chêne wrote:
* decl.c (build_enumerator): Call
insert_into_classtype_sorted_fields if an enumerator-definition
referring
to a class scope opaque enum has been encountered.
This will insert
2012/2/28 Fabien Chêne fabien.ch...@gmail.com:
2012/2/28 Jason Merrill ja...@redhat.com:
On 02/28/2012 03:36 PM, Fabien Chêne wrote:
[...]
Will unqualified lookup work
because we're in the enumeration scope, or do we need to make lookup in the
class work?
Unqualified lookup works because
Salut Dodji,
2012/3/12 Dodji Seketeli do...@seketeli.org:
[...]
Index: gcc/cp/decl.c
===
--- gcc/cp/decl.c (revision 184891)
+++ gcc/cp/decl.c (working copy)
@@ -8686,6 +8686,9 @@ grokdeclarator (const cp_declarator *dec
?
gcc/testsuite/ChangeLog
2011-12-02 Fabien Chêne fab...@gcc.gnu.org
PR c++/51319
* g++.dg/lookup/using50.C: New.
* g++.dg/lookup/using51.C: New.
gcc/cp/ChangeLog
2011-12-02 Fabien Chêne fab...@gcc.gnu.org
PR c++/51319
* semantics.c
2011/12/5 Jason Merrill ja...@redhat.com:
Is there a reason not to just do
decl = strip_using_decl (decl);
early in finish_id_expression?
Not really, I've already tried it and it works. I wasn't sure it was
correct not to return a USING_DECL in aIl cases -- they are numerous
in this huge
2011/12/5 Jason Merrill ja...@redhat.com:
[...]
Since finish_id_expression often returns something that isn't a decl at all,
I think stripping the using here makes sense.
Good, here is an updated patch, (re)tested x86_64-unknown-linux-gnu.
OK to commit ?
--
Fabien
51319.patch
Description:
for USING_DECLs), and set it appropriately in
cp_parser_using_declaration.
Tested x86_64-unkown-linux-gnu, OK to commit ?
gcc/testsuite/ChangeLog
2011-12-11 Fabien Chêne fab...@gcc.gnu.org
PR c++/14258
* g++.dg/template/using16.C: New.
* g++.dg/template/using17.C: New.
gcc
Hi,
According to § 11.3/1 from c++98, access delarations are deprecated:
The access of a member of a base class can be changed in the derived
class by mentioning its qualified-id in the derived class declaration.
Such mention is called an access declaration. The effect of an access
declaration
2011/12/11 Jonathan Wakely jwakely@gmail.com:
On 11 December 2011 22:22, Fabien Chêne wrote:
Consequently, I propose to deprecate them with a warning, as clang already
does.
So that you get a warning for the following code:
struct A { int i; };
struct B : A
{
A::i; // - warning
2011/12/12 Jason Merrill ja...@redhat.com:
On 12/11/2011 09:00 AM, Fabien Chêne wrote:
Here, we weren't creating a typename_type for a dependent type
introduced by a using declaration. A USING_DECL was not recording the
fact that it refers to a dependent type, so I've created a new macro
2011/12/13 Miles Bader mi...@gnu.org:
Jonathan Wakely jwakely@gmail.com writes:
How about ...; suggest adding the using keyword?
That sounds like the compiler is suggesting that the user suggests
doing that!
It is similar to suggest parentheses
Good point, that's not correct
2011/12/17 Jason Merrill ja...@redhat.com:
This testcase was aborting when we tried to check ENUM_UNDERLYING_TYPE on a
non-enum. Fixed by checking the tree code first.
Ahem ... thank you !
--
Fabien
to work.
Tested x86_64-unknown-linux-gnu, OK to commit ?
gcc/testsuite/ChangeLog
2011-12-20 Fabien Chêne fab...@gcc.gnu.org
PR c++/23211
* g++.dg/template/using18.C: New.
* g++.dg/template/nested3.C: Remove dg-message on the
instantiation.
* g++.dg
2011-12-27 Fabien Chêne fab...@gcc.gnu.org
PR c++/23211
* g++.dg/template/using18.C: New.
* g++.dg/template/using19.C: New.
* g++.dg/template/nested3.C: Remove dg-message at instantiation.
* g++.dg/template/crash13.C: Likewise.
gcc/cp/ChangeLog
2011-12-27
2011/12/27 Jason Merrill ja...@redhat.com:
On 12/27/2011 02:12 PM, Fabien Chêne wrote:
- if (!scope_dependent_p)
+ if (!dependent_scope_p (scope))
I was thinking to change the line
scope_dependent_p = dependent_type_p (scope);
to use dependent_scope_p instead of dependent_type_p.
OK
declaration is actually valid.
Bootstrapped/Tested x86_64-unknown-linux-gnu, OK to commit ?
gcc/testsuite/ChangeLog
2011-12-28 Fabien Chêne fab...@gcc.gnu.org
* g++.old-deja/g++.brendan/crash25.C: Adjust.
* g++.old-deja/g++.brendan/crash56.C: Likewise.
* g++.old-deja/g
2011/12/30 Jason Merrill ja...@redhat.com:
Why // { dg-warning } deprecated on some tests, and
// { dg-warning deprecated } on others? I would think all of the could
use the second form.
I was believing that // { dg-warning } deprecated was the way to
test a warning in old-deja. If we can
Hi,
2012/1/7 Gerald Pfeifer ger...@pfeifer.com:
On Thu, 29 Dec 2011, Fabien Chêne wrote:
As previously announced, here is a patch that deprecate access
declarations . I did a little tour in the GCC museum old-deja --and in
g++.dg as well -- to disinter and adjust those dusty tests. To avoid
2012/1/19 Jason Merrill ja...@redhat.com:
When we have a class-scope using-declaration that nominates functions, we
want to insert those functions into the derived class' CLASSTYPE_METHOD_VEC.
In non-template code we do this in handle_using_decl, which is called from
check_bases_and_members.
Hi Gerald,
2012/1/13 Fabien Chêne fabien.ch...@gmail.com:
[...]
Mind suggesting a snippet for our release notes at
http://gcc.gnu.org/gcc-4.7/changes.html ?
Yes, sure, thanks for suggestion. Unfortunately, my machine is
currently down, I'll get back to you when it is repaired.
I get back
succeeds.
Bootstrapped, regtested on x86_64-unknown-linux-gnu.
OK for trunk ?
gcc/cp/ChangeLog
2010-11-15 Fabien Chêne fab...@gcc.gnu.org
PR c++/48010
* name-lookup.c (supplement_binding_1): If the old binding was a
type name, also check that the DECL actually refers
Hi,
After updating the patch, I now see a failure on c++0x forward enums.
Consider the below code:
template class T
struct S1
{
enum class E1;
enum class E1;
};
Currently, the second declaration of E1 relies on a successfull call
to supplement_binding_1.
With the patch I am working on,
Jason, could you please have a look at this (rather old) one ?
Thanks.
2012/8/13 Fabien Chêne fabien.ch...@gmail.com:
Hi,
Here, we were setting the LOOKUP_NONVIRTUAL flag wrongly. Actually, we
need to check if the function context is the same than the instance
type -- yes that might happen
hi,
2012/9/19 Paolo Carlini paolo.carl...@oracle.com:
Hi Fabien,
On 09/19/2012 07:29 PM, Fabien Chêne wrote:
But I'm afraid this is still not completely correct, because if the user
code has a using std::pow in the global namespace and then and include
tr1/cmath the latter drags again
for this legacy TR1 stuff, IMO.
Good, here is the patch then, bootstrapped and tested
x86_64-unknown-linux-gnu without regressions on a old tree.
I plan to perform an additional testing before committing anyway.
2012-11-14 Fabien Chêne fab...@gcc.gnu.org
PR c++/54537
* cp-tree.h: Check
Hi,
2012/11/14 Jason Merrill ja...@redhat.com:
I'll just note that another solution would be to change non-template
forwarding pows to be extern C declarations. But it sounds like you folks
have this issue in hand.
I'm a bit puzzled by your suggestion, altough I have not tried it yet,
how
2012/9/11 Fabien Chêne fabien.ch...@gmail.com:
Oops, not sure how I test that change initially, or I must be blind,
because it triggers an error in tr1/cmath about pow. I'll see what I
can do...
Well, as summarized in the code below, the problem seems to be the
redundant overload of std::tr1
... And the patch.
2012/9/18 Fabien Chêne fabien.ch...@gmail.com:
2012/9/11 Fabien Chêne fabien.ch...@gmail.com:
Oops, not sure how I test that change initially, or I must be blind,
because it triggers an error in tr1/cmath about pow. I'll see what I
can do...
Well, as summarized
2012/9/18 Paolo Carlini paolo.carl...@oracle.com:
I don't understand: what's wrong - exactly - with the std::tr1::pow (double,
double) overload above? Now I can't immediately check, but do the EDG and
CLANG front ends accept it or not?
They don't. The problem is that it conflicts with
Hi Paolo,
2012/9/19 Paolo Carlini paolo.carl...@oracle.com:
On 09/19/2012 01:24 AM, Paolo Carlini wrote:
On 09/19/2012 01:12 AM, Paolo Carlini wrote:
Hi again,
On 09/18/2012 08:33 PM, Paolo Carlini wrote:
But I'm not surprised, frankly, I think the conflict is expected, *IF*
(please
Hi,
Again sorry for such a delay. Paolo subtly ping'ed me on DR39
(c++/13590), and I remember that this bug (c++/54537) was blocking the
patch I wrote last year for DR39.
2012/11/15 Jason Merrill ja...@redhat.com:
[...]
I was only thinking of the primary signature; putting
extern C double pow
Hi,
2013/5/23 Jason Merrill ja...@redhat.com
On 05/22/2013 04:53 PM, Fabien Chêne wrote:
Ah, I see, it works. Then we end up with three solutions:
1) remove the pow(double,double) overload
2) add a specialization template pow(double,double)
3) add an extern C declaration to refer to the C
1 - 100 of 103 matches
Mail list logo
