On 10/30/2012 07:44 PM, Paolo Carlini wrote:
straightforward fix. The below, which regtests fine, simply acts on any
MULT_EXPR as TYPE_SIZE, which I think should be fine, but, in case the
idea is basically Ok, we could also consider the more complex but more
sophisticated variably_modified_type_p
On 10/30/2012 05:49 PM, Sriraman Tallam wrote:
AFAIU, this should not be a problem. For duplicate declarations,
duplicate_decls should merge them and they should never be seen here.
Did I miss something?
With extern "C" functions you can have multiple declarations of the same
function in diffe
On 10/02/2013 09:05 AM, Andrew Sutton wrote:
+ // Do not permit the declaration of constrained friend
+ // function declarations. They cannot be instantiated since
+ // the resulting declaration would never match the definition,
+ // which must be a non-templat
OK.
Jason
On 08/27/2013 04:03 PM, Aldy Hernandez wrote:
+ /* First, try to parse as an initialized declaration. See
+ cp_parser_condition, from whence the bulk of this is copied. */
You didn't do this copy, but I'd appreciate it if you could reintegrate
this with cp_parser_condition. I notice th
On 10/03/2013 05:52 AM, Paolo Carlini wrote:
+ else if (!TREE_TYPE (*begin) || !TREE_TYPE (*end))
This should use type_dependent_expression_p.
And there should be a positive test for a dependent range that exercises
this code.
Jason
On 10/02/2013 09:02 PM, Paolo Carlini wrote:
- save_template_attributes (&attributes, decl);
+ if (attributes != error_mark_node)
+ save_template_attributes (&attributes, decl);
I'd rather make save_template_attributes handle error_mark_node
appropriately.
+ if (attributes
On 10/02/2013 06:19 PM, Easwaran Raman wrote:
+ chainon (prefix_attributes, attributes));
This should be reversed, so it's
chainon (attributes, prefix_attributes);
Otherwise the attributes for this decl would be applied to later decls
with the same declspecs.
OK with
OK.
Jason
OK.
Jason
OK.
Jason
OK.
Jason
On 10/03/2013 07:42 PM, Paolo Carlini wrote:
My point is that do_range_for_auto_deduction is called only by
cp_parser_range_for and *only* when type_dependent_expression_p is
*false* for the range_expr.
Aha.
Now, is it possible that in a range-based
for-statement with such a range_expr, begin
On 10/04/2013 09:20 AM, Andrew Sutton wrote:
>Perhaps you mean that it must match a fully-instantiated function, so any
>constraints on the templates were considered during
>determine_specialization.
This seems like a simple comment fix, but there's a longer explanation
of what I want (see bel
OK.
Jason
OK.
Jason
OK.
Jason
OK.
Jason
For EXPR_PACK_EXPANSION we can just return true; a pack expansion is
always dependent, on the number of arguments if nothing else.
Jason
On 10/06/2013 03:35 PM, Paolo Carlini wrote:
PS: I struggled a bit with "%qT" vs "%q#T": I would slightly prefer
simply talking about, eg, "base class 'A'", we do that in other cases,
but here we are already using # which automatically picks class vs
struct. Thus I think we should use # for the b
OK.
If we have a friend declaration inside a constrained partial
specialization, will that still get a false positive?
Jason
OK.
Jason
On 10/07/2013 05:14 AM, Adam Butcher wrote:
+ /* Forbid ambiguous implicit pack expansions by only allowing
+a single generic type in such a parameter.
+XXX: Maybe allow if explicitly specified template
+XXX: 'typename..
On 10/08/2013 07:03 PM, Paolo Carlini wrote:
.. a curiosity: the cp_parser_commit_to_tentative_parse at the end of
cp_parser_pseudo_destructor_name, which didn't exist in 4.6.x and we can
consider the root of this issue, is also my fault:
http://gcc.gnu.org/ml/gcc-patches/2011-05/msg02246.h
OK.
Jason
On 10/07/2013 07:02 AM, Jakub Jelinek wrote:
duplicates anywhere, but during error diagnostics. Without those two decl.c
hunks (either of them), pushdecl will sometimes return a different decl from
the original or error_mark_node, and the original fndecl passed to it has
ggc_free called on it, t
On 10/08/2013 03:53 PM, Jakub Jelinek wrote:
case OMP_CLAUSE_REDUCTION:
- gcc_assert (!is_invisiref_parm (OMP_CLAUSE_DECL (stmt)));
+ if (is_invisiref_parm (OMP_CLAUSE_DECL (stmt)))
+ {
+ *walk_subtrees = 0;
+ if (OMP_CLAUSE_REDUCTION_INIT (stmt))
+
On 10/09/2013 01:43 PM, Jakub Jelinek wrote:
Perhaps DECL_TEMPLATE_INFO check could also be less expensive to be done
before calling decl_maybe_constant_var_p or undeduced_auto_decl ?
Sure.
+ DECL_LOCAL_FUNCTION_P (fndecl) = 1;
This should be set by pushdecl_maybe_friend_1, so I don
On 10/10/2013 08:33 AM, Paolo Carlini wrote:
+ expr_type = TREE_TYPE (expr) = cp_build_qualified_type
+ (TREE_TYPE (expr), cp_type_quals (TREE_TYPE (probe_type)));
Won't that end up being the same as the contents of expr_type before
this statement? Can we just remove
On 10/10/2013 11:01 AM, Jakub Jelinek wrote:
int inhibit_evaluation_warnings;
+ int omp_declare_target_attribute;
Let's keep the comment you had on the variable, just put it on the
member now.
OK with that change.
Jason
On 10/09/2013 11:14 AM, Mitchell, Mark wrote:
Unfortunately, I no longer remember this code well. My recollection --
such as it is -- is just that I couldn't find a case where it was
necessary to commit only a single level. You sometimes had to scan an
unbounded number of tokens to complete the
On 10/10/2013 04:45 PM, Adam Butcher wrote:
Of course; makes sense. I had confused myself. Not that it's a
function parameter pack, but presumably you would expect
auto f(tuple p)
to be supported?
That makes sense, though it's a (further) extension.
Can we put this in cp_parser, invert
On 10/10/2013 03:31 PM, Paolo Carlini wrote:
On 10/10/2013 08:26 PM, Jason Merrill wrote:
On 10/10/2013 08:33 AM, Paolo Carlini wrote:
+ expr_type = TREE_TYPE (expr) = cp_build_qualified_type
+(TREE_TYPE (expr), cp_type_quals (TREE_TYPE (probe_type)));
Won't that e
On 10/11/2013 04:51 AM, Paolo Carlini wrote:
The 6th time we get there when compiling the testcase, that is when we
are converting to int&, at that line this is expr_type:
Aha. The patch is OK then.
Jason
On 10/11/2013 09:56 AM, Jakub Jelinek wrote:
With the operator bool (), there is ambiguity in the
if (((mask >> something) & 1) == 0)
tests (so had to use OMP_CLAUSE_MASK_{1,0} instead of {1,0})
This is an example of why operator bool is a bad idea in general. If we
were using C++11, we could
On 10/11/2013 06:28 AM, Paolo Carlini wrote:
The issue is a regression in 4_7/4_8 too, what should we do in those
branches? I'm thinking applying the change to 4_8 too and either not
fixing in 4_7 or just reverting the cp_parser_commit_to_tentative_parse
change which improved the diagnostic for 4
On 10/11/2013 10:36 AM, Jakub Jelinek wrote:
>Since the coding standards say "Conversion operators should be
>avoided" (because they can't be explicit), I think this is the way
>to go.
We then violate the coding standard in vec.h:
/* Type to provide NULL values for vec. This is used to
prov
How does a TEMPLATE_PARM_INDEX get this far? It should have been
detected as dependent before this.
Jason
This needs a testcase (compile with -dA and use scan-assembler; see
other tests in g++.dg/debug/dwarf2).
Jason
OK.
Jason
On 10/16/2013 01:48 PM, Aldy Hernandez wrote:
On 10/02/13 16:53, Jason Merrill wrote:
Can't the step size be a value-dependent expression like a template
non-type parameter?
Jason, I'm not sure. The standard says:
"The conditional-expression in a simd-linear-st
Early exit from cp_write_global_declarations in the PCH case completely
broke -fdump-translation-unit; the simple fix is just to do the dump on
the PCH path as well.
Tested x86_64-pc-linux-gnu, applying to trunk and 4.8.
commit 106091d492179afa32d3042c4c74fb2ae6c440f4
Author: Jason Merrill
If we're deducing an array type from an initializer list, we can also
deduce the bound.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit c1effcb5fe5b63628a4a7ef75c96d9415ee18f20
Author: Jason Merrill
Date: Mon Sep 23 06:15:25 2013 -0500
Core 1591
* pt.c (unify_array_d
Printing "noexcept (true)" is redundant.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 5305dc0cdb0736a0c56ce3d126b4baad0521f096
Author: Jason Merrill
Date: Thu Oct 3 15:35:11 2013 -0400
* error.c (dump_exception_spec): Print "noexcept" rather than
&quo
While reviewing a recent patch I noticed that we weren't using
attribute_takes_identifier_p here. Fixed.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 021fe309badd55090a5bc212c44d24b7c23f37af
Author: Jason Merrill
Date: Fri Oct 11 10:38:23 2013 -0400
*
On 10/15/2013 05:21 PM, Adam Butcher wrote:
On Wed, 25 Sep 2013 11:01:26 -0500, Jason Merrill wrote:
1) Build up the type as normal and use tsubst to replace the non-pack
template parameter with a pack if needed.
The problem I've hit with this (and other hacks I've tried th
OK.
Jason
OK. I thought I had already approved this, but apparently not.
Jason
OK.
Jason
On 10/11/2013 01:59 PM, Dehao Chen wrote:
It's hard to get a testcase without
http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=201856 because
none of these *INTERNAL* symbols will be emitted in debug info.
Why does that change cause one of these symbols to be emitted? As Cary
says, that
OK, thanks.
Jason
On 10/22/2013 08:54 AM, Andrew Sutton wrote:
This fixes the longstanding problem with bitfield references. The
default dialect was set to cxx1y, which was resulting different
conversions for bitfield references. I'm not sure if there's a change
in semantics for 1y or if that's a separate bug, but
OK.
Jason
I don't think this patch should be blocked on those bugs.
Jason
ng to trunk.
commit cbc14ce6b840e6311b8c580564f8c836f8dc18ae
Author: Jason Merrill
Date: Tue Oct 22 16:38:01 2013 -0400
In C++11 a trivial [cd]tor might not be callable.
* class.c (user_provided_p): A function deleted on its declation
in the class is not user-pro
On 10/08/2013 05:54 AM, Gary Benson wrote:
diff --git a/test.c b/test.c
I don't think we want to add this to the top level directory. :)
Other than that, the patch is OK.
Jason
exception-specification in
diagnostics.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 785cdfa527c1481af08a31fb0f3c2489119b539c
Author: Jason Merrill
Date: Tue Oct 22 16:17:31 2013 -0400
LWG 2165
* method.c (defaulted_late_check): Delete on eh-spec mismatch
On 10/14/2013 08:23 AM, Marek Polacek wrote:
We were ICEing on the attached testcase, because in check_narrowing,
for = {{}}, we wanted to check recursively the CONSTRUCTOR_ELTs,
even though init in this case has 0 CONSTRUCTOR_NELTS. So I added
the check for CONSTRUCTOR_NELTS > 0. Moreover, sin
On 09/25/2013 08:41 AM, Marek Polacek wrote:
+ /* Do the instrumentation of VLAs if desired. */
+ if ((flag_sanitize & SANITIZE_VLA)
+ && size && !TREE_CONSTANT (size)
+ /* From C++1y onwards, we throw an exception on a negative length size
+ of an array. */
+ && cxx_di
On 10/10/2013 04:46 AM, Tobias Burnus wrote:
I considered to add the annotation also to C++11's range-based loops,
but as those are unlikely to vectorize, I didn't do so.
I would think that a range-based loop over an array should vectorize nicely:
int ar[8];
for (int i: ar) { ... }
But your m
OK.
Jason
On 10/25/2013 12:58 PM, Marek Polacek wrote:
I've tried to implement the instrumentation in cp_finish_decl.
However, the problem is with multidimensional arrays, e.g. for
int x = -1;
int a[1][x];
array_of_runtime_bound_p returns false, thus we don't instrument this
at all, nor throw an exceptio
On 10/25/2013 01:53 PM, Eric Botcazou wrote:
This has introduced a problem for the -fdump-ada-spec machinery, which boils
down to the TYPE_METHODS field of the following structure:
struct _outer {
struct _inner {
int x;
} inner;
} outer;
Previously it was empty, now it contain
On 10/25/2013 03:03 PM, Marek Polacek wrote:
On Fri, Oct 25, 2013 at 02:17:48PM -0400, Jason Merrill wrote:
I think the right place to handle both ubsan and c++1y VLA checks is
in compute_array_index_type, in the block where we're calling
variable_size.
I'm sorry, you want me to
On 10/25/2013 04:46 PM, Tobias Burnus wrote:
+ do_range_for_auto_deduction (range_decl, range_expr); // FIXME:IVDEP
I think in this situation let's set a flag on the RANGE_FOR_STMT so we
can do ivdep handling at instantiation time.
Jason
On 10/28/2013 09:10 AM, Joseph S. Myers wrote:
On Sun, 27 Oct 2013, Ed Smith-Rowland wrote:
Here is an implementation for C++14 digit separators (single quote).
I tend to think that such features should come with a test that the
feature is not enabled for language / standard versions for whic
My question is, why do we need that whole block for massaging VAR_DECL
initializers? That all ought to be handled properly by cp_finish_decl.
Does removing everything after
else if (!VAR_P (value))
gcc_unreachable ();
work?
Jason
On 10/28/2013 05:48 PM, Tobias Burnus wrote:
I am not completely sure whether you had the following in mind, but
that's what I have now implemented:
DEFTREECODE (RANGE_FOR_STMT, "range_for_stmt", tcc_statement, 4)
has now a 5th operator (RANGE_FOR_IVDEP), which has the value
boolean_true_node
OK.
Jason
On 10/28/2013 06:12 PM, Dehao Chen wrote:
ping...
Sorry for the slow response.
If we're actually emitting the name now, we need to give it a name
different from the complete constructor. I suppose it makes sense to go
with C4/D4 as in the decloning patch,
http://gcc.gnu.org/ml/gcc-patches
On 10/29/2013 01:37 PM, Dehao Chen wrote:
If we're actually emitting the name now, we need to give it a name different
from the complete constructor. I suppose it makes sense to go with C4/D4 as
in the decloning patch,
Shall we do it in a separate patch? And I suppose binutils also need
to be
c40b06619fc9ef74e4d4d8b299a6c77c6fb63df5
Author: Jason Merrill
Date: Mon Oct 28 16:45:05 2013 -0400
/
* Makefile.tpl (STAGE1_CONFIGURE_FLAGS): Pass
--disable-build-format-warnings.
gcc/
* configure.ac (loose_warn): Add -Wno-format if
--disable-build-format-warnings.
diff --git
On 10/30/2013 10:52 AM, Marek Polacek wrote:
+ if ((flag_sanitize & SANITIZE_VLA)
+ && !processing_template_decl
You don't need to check processing_template_decl; the template case was
already handled above.
+ tree x = cp_save_expr (size);
+ x = b
On 10/30/2013 06:14 AM, Eric Botcazou wrote:
+/* Return whether DECL, a method of a C++ TYPE, is trivial, that is to say
+ doesn't do anything for the objects of TYPE. */
+
+static bool
+is_trivial_method (const_tree decl, const_tree type)
+{
+ if (cpp_check (decl, IS_CONSTRUCTOR) && !TYPE_NE
At the Chicago meeting the EWG agreed that we don't need to throw on
0-length VLAs.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 1e328cbd26bfb641db8e218e4a4c32fc1a9a8d9d
Author: Jason Merrill
Date: Fri Oct 25 06:15:01 2013 -0400
* decl.c (cp_finish_decl): Never throw fo
OK.
Jason
OK.
Jason
hings.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit beac93e0a45d47f6a896d9f3f27eed224ad51ee9
Author: Jason Merrill
Date: Tue Oct 22 16:32:07 2013 -0400
* init.c (push_base_cleanups): Check ANON_AGGR_TYPE_P.
diff --git a/gcc/cp/init.c b/gcc/cp/init.c
index 78ea986..82b3cae 1006
On 10/30/2013 12:15 PM, Marek Polacek wrote:
On Wed, Oct 30, 2013 at 11:56:25AM -0400, Jason Merrill wrote:
Saving 'size' here doesn't help since it's already been used above.
Could you use itype instead of size here?
I already experimented with that and I think I can&
OK.
Jason
On 10/25/2013 03:04 PM, Jason Merrill wrote:
In C++ all classes have destructors, but we try to defer building the
implicit declaration. My patch causes us to build those implicit
declarations more often, which is probably a bit of a memory regression,
We can still avoid doing this in C++98
We're building up the full initialization for the non-static data member
in cp_parser_late_parse_one_default_arg, so we don't need to do it again
when we use the NSDMI.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit a0065b92a8039a07eb0d5fa577b919e820d86590
Author: Jason Mer
no point in limiting use of
LOOKUP_NONVIRTUAL in cxx_maybe_build_cleanup because it will be added
anyway in build_new_method_call.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit d2987bf536b65ef47ab537d84659caebb501cfc1
Author: Jason Merrill
Date: Tue Oct 22 16:35:25 2013 -0400
On 10/31/2013 10:47 AM, Eric Botcazou wrote:
I think a good way to check for any non-trivial methods would be to
check trivial_type_p in the front end and then see if there are any
!DECL_ARTIFICIAL decls in TYPE_METHODS.
Revised patch attached, tested on x86-64/Linux.
Looks good.
Jason
On 10/31/2013 07:03 PM, Marc Glisse wrote:
* pt.c (value_dependent_expression_p): Handle null argument.
What is calling this with a null argument? The recursive call near the
end of the function checks for null there.
Jason
On 11/01/2013 11:13 AM, Marc Glisse wrote:
position). I can make it not call value_dependent_expression_p with a
null argument, but it seems more general to let
value_dependent_expression_p handle 0 like a number of other functions
already do.
OK. But the change is to type_..., not value_...,
On 10/31/2013 02:28 PM, Marek Polacek wrote:
/* A variable sized array. */
itype = variable_size (itype);
+
+ /* We need to stabilize side-effects in VLA sizes for regular array
+declarations too, not just pointers to arrays. */
+ stabilize_vla_si
On 10/31/2013 03:07 PM, Paolo Carlini wrote:
... I understand that at this point likely this isn't 4.9 material anymore.
I think it's fine for 4.9, we're still in stage 1.
The revised patch is OK.
Jason
On 10/18/2013 02:48 PM, Aldy Hernandez wrote:
This has the potential of throwing my mind for a spin. Can I do this as
a followup, and keep it simple for now?
Sure.
+ else if (!TREE_TYPE (e) || !TREE_CONSTANT (e)
+ || !INTEGRAL_TYPE_P (TREE_TYPE (e)))
+cp_pars
OK.
Jason
On 11/01/2013 03:10 PM, Marek Polacek wrote:
+ /* We need to stabilize side-effects in VLA sizes for regular array
+declarations too, not just pointers to arrays. */
This comment isn't really relevant to its new location. :)
OK with that removed.
Jason
OK.
Jason
On 11/04/2013 07:41 AM, Richard Biener wrote:
Please make sure the warning is preserved when not bootstrapping,
it's useful to have them in your dev-tree and not notice errors only
during -Werror bootstrap ...
I found it to be useless noise when not bootstrapping, since my system
compiler isn'
On 11/04/2013 05:50 AM, Marek Polacek wrote:
case RO_ARROW:
+case RO_ARROW_STAR:
error_at (loc,
"invalid type argument of %<->%> (have %qT)",
type);
I think the diagnostic for RO_ARROW_STAR should say ->*, not just ->.
Jason
OK.
Jason
Surely it should be valid to allocate a Java boolean type. Andrew, how
should that work?
Jason
On 11/04/2013 10:50 AM, Jakub Jelinek wrote:
That's true, but it is easy to ignore those, while without -Wformat
you won't notice until you bootstrap that you actually passed incorrect
parameters to some *printf etc. family function.
Sure, but that is much less common than the false positives,
On 01/19/2016 01:09 PM, Martin Sebor wrote:
Attached is the patch to avoid the ICE that Kai posted below
with the test case Marek asked for in his response. I didn't
see any further followup on the list.
Thanks, but the code is actually well-formed; I've now fixed the bug
properly.
Jason
On 01/19/2016 11:31 PM, Sandra Loosemore wrote:
-@option{-gdwarf-2} does not accept a concatenated debug level, because
-GCC used to support an option @option{-gdwarf} that meant to generate
-debug information in version 1 of the DWARF format (which is very
-different from version 2), and it woul
On 01/19/2016 10:30 PM, Patrick Palka wrote:
* g++.dg/template/unify17.C: XFAIL.
Hmm, I'm not comfortable with deliberately regressing this testcase.
template
-void bar (void (T[5])); // { dg-error "array of 'void'" }
+void bar (void (T[5])); // { dg-error "array of 'void'" "" { xfail
1501 - 1600 of 11982 matches
Mail list logo
