List-initialization of bases with virtual bases was also broken,
because we weren't considering the VTT argument when looking for the
initializer-list argument or passing it through to a constructor.
Fixed by using num_artificial_parms_for.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 481
On Sat, Jul 23, 2016 at 10:55 PM, Jason Merrill wrote:
> Using build_value_init in a base initialization is wrong, because it
> calls the complete object constructor and misses protected access. So
> let's handle list-value-initialization in expand_aggr_init_1.
>
> Tested x86_64-pc-linux-gnu, app
On Sat, Jul 23, 2016 at 10:50 PM, Jason Merrill wrote:
> Here when we partially instantiated the declaration of the AddToFront
> partial specialization, which meant substituting into
> "Holder", we weren't replacing KeyType in the template
> parameter list of Holder, leading to confusion when we e
Using build_value_init in a base initialization is wrong, because it
calls the complete object constructor and misses protected access. So
let's handle list-value-initialization in expand_aggr_init_1.
Tested x86_64-pc-linux-gnu, applying to trunk.
Since a zero-length array is represented with a TYPE_MAX_VALUE of
unsigned -1, iterating up from 0 takes a long time. So let's avoid
that.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 237edb92e3aa09ad1eae62ed633bf161a8590bd7
Author: Jason Merrill
Date: Fri Jul 22 17:00:06 2016 -0400
Here when we partially instantiated the declaration of the AddToFront
partial specialization, which meant substituting into
"Holder", we weren't replacing KeyType in the template
parameter list of Holder, leading to confusion when we encounter it
later and try to substitute in 0.
Tested x86_64-pc-
Here lookup_template_class is tsubsting a TEMPLATE_DECL and then
crashing when it gets a TEMPLATE_DECL back, when a TEMPLATE_DECL is
what it wants to end up with anyway. This is silly.
The testcase is also silly, since members have access to their
enclosing class and so the friend declaration has
In this testcase we hit an error and then a warning while trying to
print the name of the function, because the warning wasn't properly
respecting complain.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 559a9aac40a5eb421948cd939637e4fe1c919843
Author: Jason Merrill
Date: Fri Jul 22 15:1
The code for recognizing problems with binding a glvalue to a
reference was using real_lvalue_p, which returns 0 for xvalues, so the
code that used that to handle bitfields wasn't handling a bitfield
member of an xvalue. Fixed by using lvalue_kind instead.
Tested x86_64-pc-linux-gnu, applying to
On 23/07/16 05:26, Patrick Palka wrote:
This patch teaches VRP to register along a default switch label
assertions that corresponds to the anti range of each case label.
Hi Patrick,
In case of a larger switch statement with case values that cannot be
combined, you could end up with very lar
On Sat, 2016-07-23 at 15:35 -0600, Martin Sebor wrote:
> On 07/08/2016 03:49 PM, David Malcolm wrote:
> > This patch implements precise tracking of source locations for the
> > individual chars within string literals, so that we can e.g.
> > underline
> > specific ranges in -Wformat diagnostics.
>
On 07/08/2016 03:49 PM, David Malcolm wrote:
This patch implements precise tracking of source locations for the
individual chars within string literals, so that we can e.g. underline
specific ranges in -Wformat diagnostics.
...
Successfully bootstrapped®rtested on x86_64-pc-linux-gnu.
Thoughts
The attached patch fixes PR middle-end/71712. We need to invalidate the
argument slots in
const/pure calls as they are owned by the callee. The caller can't assume they
are preserved
across the call. Fix is similar to that for PR71532.
Tested on hppa-unknown-linux-gnu.
Okay for trunk?
Dave
On 07/22/2016 01:14 PM, Martin Sebor wrote:
r231665 committed in the 6.0 cycle tightened up the checking of
flexible array members in C++ with the goal of rejecting code
that could lead to hard to find bugs, while at the same time
accepting (with a warning) benign extensions also accepted in
C mo
On July 22, 2016 5:09:07 PM GMT+02:00, Jakub Jelinek wrote:
>Hi!
>
>As Richard reported on IRC, we are marking C99 inline (without extern)
>functions as effectively always_inline, even when the intent has been
>to do
>this only for the GNU extern inline functions (i.e. -fgnu89-inline
>extern
>inli
We used to emit, in debug information, the values bound to pointer to
member function template parameters only when they were NULL or
virtual member functions, because those can be represented with
DW_AT_const_value.
In order to represent the symbolic pointer to member function
constants for non-v
1. When dumping assert details, print loc->expr instead of the bare SSA
name. loc->expr is not always equal to the SSA name. For example we
sometimes insert an ASSERT_EXPR like
x_7 = ASSERT_EXPR 8>;
The diff of the new dump output looks like:
Assertions to be inserted for x_4(D)
if
Hi Richard,
As we had value_range_type in tree-ssanames.h why not put value_range there?
For IPA_VRP, we now need value_range used in ipa-prop.h (in ipa-vrp
patch). Based on this, attached patch now adds struct value_range to
tree-ssanames.h and fixes the header files. Please note that I also
18 matches
Mail list logo
