2015-08-28 9:19 GMT+02:00 Kai Tietz :
> 2015-08-28 4:11 GMT+02:00 Jason Merrill :
>> On 08/27/2015 02:12 PM, Kai Tietz wrote:
>>>
>>> + else if (TREE_CODE (type) == VECTOR_TYPE)
>>> +{
>>> + if (TREE_CODE (arg1) == VECTOR_CST
>>> + && code == NOP_EXPR
>>> + && TYPE_VECTOR_
2015-08-28 4:11 GMT+02:00 Jason Merrill :
> On 08/27/2015 02:12 PM, Kai Tietz wrote:
>>
>> + else if (TREE_CODE (type) == VECTOR_TYPE)
>> +{
>> + if (TREE_CODE (arg1) == VECTOR_CST
>> + && code == NOP_EXPR
>> + && TYPE_VECTOR_SUBPARTS (type) == VECTOR_CST_NELTS (arg1))
>>
On 08/27/2015 02:12 PM, Kai Tietz wrote:
+ else if (TREE_CODE (type) == VECTOR_TYPE)
+{
+ if (TREE_CODE (arg1) == VECTOR_CST
+ && code == NOP_EXPR
+ && TYPE_VECTOR_SUBPARTS (type) == VECTOR_CST_NELTS (arg1))
+ {
+ tree r = copy_node (arg1);
+ TREE_T
On 08/27/2015 09:38 AM, Kai Tietz wrote:
2015-08-27 15:27 GMT+02:00 Jason Merrill :
On 08/27/2015 06:39 AM, Kai Tietz wrote:
2015-08-27 4:56 GMT+02:00 Jason Merrill :
On 08/24/2015 03:15 AM, Kai Tietz wrote:
2015-08-03 17:39 GMT+02:00 Jason Merrill :
On 08/03/2015 05:42 AM, Kai Tietz wro
With following patch testcase passes:
Index: fold-const.c
===
--- fold-const.c(Revision 227111)
+++ fold-const.c(Arbeitskopie)
@@ -2110,6 +2110,17 @@ fold_convert_const (enum tree_code code, tree type
else if (T
2015-08-27 15:27 GMT+02:00 Jason Merrill :
> On 08/27/2015 06:39 AM, Kai Tietz wrote:
>>
>> 2015-08-27 4:56 GMT+02:00 Jason Merrill :
>>>
>>> On 08/24/2015 03:15 AM, Kai Tietz wrote:
2015-08-03 17:39 GMT+02:00 Jason Merrill :
>
> On 08/03/2015 05:42 AM, Kai Tietz wrote:
>>
>>>
On 08/27/2015 06:39 AM, Kai Tietz wrote:
2015-08-27 4:56 GMT+02:00 Jason Merrill :
On 08/24/2015 03:15 AM, Kai Tietz wrote:
2015-08-03 17:39 GMT+02:00 Jason Merrill :
On 08/03/2015 05:42 AM, Kai Tietz wrote:
2015-08-03 5:49 GMT+02:00 Jason Merrill :
On 07/31/2015 05:54 PM, Kai Tietz wrote:
2015-08-27 4:56 GMT+02:00 Jason Merrill :
> On 08/24/2015 03:15 AM, Kai Tietz wrote:
>>
>> 2015-08-03 17:39 GMT+02:00 Jason Merrill :
>>>
>>> On 08/03/2015 05:42 AM, Kai Tietz wrote:
2015-08-03 5:49 GMT+02:00 Jason Merrill :
>
> On 07/31/2015 05:54 PM, Kai Tietz wrote:
>>
On 08/24/2015 03:15 AM, Kai Tietz wrote:
2015-08-03 17:39 GMT+02:00 Jason Merrill :
On 08/03/2015 05:42 AM, Kai Tietz wrote:
2015-08-03 5:49 GMT+02:00 Jason Merrill :
On 07/31/2015 05:54 PM, Kai Tietz wrote:
The "STRIP_NOPS-requirement in 'reduced_constant_expression_p'" I could
remove, but
Hello Jason,
after a longer delay the answer to your question.
2015-08-03 17:39 GMT+02:00 Jason Merrill :
> On 08/03/2015 05:42 AM, Kai Tietz wrote:
>>
>> 2015-08-03 5:49 GMT+02:00 Jason Merrill :
>>>
>>> On 07/31/2015 05:54 PM, Kai Tietz wrote:
The "STRIP_NOPS-requirement in 'redu
On 08/03/2015 05:42 AM, Kai Tietz wrote:
2015-08-03 5:49 GMT+02:00 Jason Merrill :
On 07/31/2015 05:54 PM, Kai Tietz wrote:
The "STRIP_NOPS-requirement in 'reduced_constant_expression_p'" I could
remove, but for one case in constexpr. Without folding we don't do
type-sinking/raising.
Right
2015-08-03 5:49 GMT+02:00 Jason Merrill :
> On 07/31/2015 05:54 PM, Kai Tietz wrote:
>>
>> The "STRIP_NOPS-requirement in 'reduced_constant_expression_p'" I could
>> remove, but for one case in constexpr. Without folding we don't do
>> type-sinking/raising.
>
>
> Right.
>
>> So binary/unary operat
On 07/31/2015 05:54 PM, Kai Tietz wrote:
The "STRIP_NOPS-requirement in 'reduced_constant_expression_p'" I could remove,
but for one case in constexpr. Without folding we don't do type-sinking/raising.
Right.
So binary/unary operations might be containing cast, which were in the past
unexp
- Ursprüngliche Mail -
> On 07/30/2015 05:00 PM, Kai Tietz wrote:
> > 2015-07-30 18:52 GMT+02:00 Jason Merrill :
> >> On 07/29/2015 06:56 PM, Kai Tietz wrote:
> >>> @@ -13078,6 +13042,8 @@ build_enumerator (tree name, tree value,
> >>> tree
> >>> enumtype, tree attri
- Ursprüngliche Mail -
> On 07/31/2015 12:46 PM, Jakub Jelinek wrote:
> > On Fri, Jul 31, 2015 at 06:25:57PM +0200, Kai Tietz wrote:
> >> 2015-07-31 18:14 GMT+02:00 Jason Merrill :
> >>> On 07/30/2015 10:48 PM, Jeff Law wrote:
>
> Note, anything outside of the C/C++ front-ends dep
On 07/31/2015 12:46 PM, Jakub Jelinek wrote:
On Fri, Jul 31, 2015 at 06:25:57PM +0200, Kai Tietz wrote:
2015-07-31 18:14 GMT+02:00 Jason Merrill :
On 07/30/2015 10:48 PM, Jeff Law wrote:
Note, anything outside of the C/C++ front-ends depending on that
canonicalization done by shorten_compare
On Fri, Jul 31, 2015 at 06:25:57PM +0200, Kai Tietz wrote:
> 2015-07-31 18:14 GMT+02:00 Jason Merrill :
> > On 07/30/2015 10:48 PM, Jeff Law wrote:
> >>
> >> Note, anything outside of the C/C++ front-ends depending on that
> >> canonicalization done by shorten_compare is, IMHO, broken.
> >
> >
> >
2015-07-31 18:14 GMT+02:00 Jason Merrill :
> On 07/30/2015 10:48 PM, Jeff Law wrote:
>>
>> Note, anything outside of the C/C++ front-ends depending on that
>> canonicalization done by shorten_compare is, IMHO, broken.
>
>
> I think the OMP code isn't relying on it being done by shorten_compare; it'
On 07/30/2015 10:48 PM, Jeff Law wrote:
Note, anything outside of the C/C++ front-ends depending on that
canonicalization done by shorten_compare is, IMHO, broken.
I think the OMP code isn't relying on it being done by shorten_compare;
it's trying to do it itself in c_finish_omp_for but is som
On 07/30/2015 05:02 PM, Jason Merrill wrote:
Actually ME deals with none-cannonical form too. It just asserts on
it at this place. After delayed-folding work I will continue work
(Jeff pushed first parts of this work already to ML) on eliminating
use of shorten_compare completely, and move its
On 07/30/2015 10:52 AM, Jason Merrill wrote:
This hunk is necessary as we don't use canonical-form produced by
shorten_compare anymore. Therefore special operand can occur on
right-hand side too.
That seems like a problem, if the middle end is expecting the canonical
form. What is your plan
On 07/30/2015 05:00 PM, Kai Tietz wrote:
2015-07-30 18:52 GMT+02:00 Jason Merrill :
On 07/29/2015 06:56 PM, Kai Tietz wrote:
@@ -1430,6 +1438,8 @@ cxx_eval_call_expression (const
constexpr_ctx
*ctx,
tree t,
bool
reduced_constant_expression_p (tree t)
{
+ /* Make sure we remove
2015-07-30 18:52 GMT+02:00 Jason Merrill :
> On 07/29/2015 06:56 PM, Kai Tietz wrote:
>>
>> @@ -1430,6 +1438,8 @@ cxx_eval_call_expression (const
>> constexpr_ctx
>> *ctx,
>> tree t,
>> bool
>> reduced_constant_expression_p (tree t)
>>
On 07/29/2015 06:56 PM, Kai Tietz wrote:
@@ -1430,6 +1438,8 @@ cxx_eval_call_expression (const constexpr_ctx
*ctx,
tree t,
bool
reduced_constant_expression_p (tree t)
{
+ /* Make sure we remove useless initial NOP_EXPRs. */
+ STRIP_NOPS (t);
Checked, and removing those STRIP_NOPS
2015-07-30 0:56 GMT+02:00 Kai Tietz :
> 2015-07-29 19:48 GMT+02:00 Jason Merrill :
>> On 07/28/2015 04:10 PM, Kai Tietz wrote:
> The change to adjust_temp_type seems to be no more necessary (just
> doing tests on it).
Yes, committed it.
>>
> @@ -3391,8 +3431,23 @@ cxx_eval_constant_expres
2015-07-29 19:48 GMT+02:00 Jason Merrill :
> On 07/28/2015 04:10 PM, Kai Tietz wrote:
>>
>> 2015-07-28 1:14 GMT+02:00 Kai Tietz :
>>
>>> 2015-07-27 18:51 GMT+02:00 Jason Merrill :
I've trimmed this to the previously mentioned issues that still need to
be
addressed; I'll do anoth
On 07/28/2015 04:10 PM, Kai Tietz wrote:
2015-07-28 1:14 GMT+02:00 Kai Tietz :
2015-07-27 18:51 GMT+02:00 Jason Merrill :
I've trimmed this to the previously mentioned issues that still need to be
addressed; I'll do another full review after these are dealt with.
Thanks for doing this summary
2015-07-28 1:14 GMT+02:00 Kai Tietz :
> 2015-07-27 18:51 GMT+02:00 Jason Merrill :
>> I've trimmed this to the previously mentioned issues that still need to be
>> addressed; I'll do another full review after these are dealt with.
>
> Thanks for doing this summary of missing parts of prior review.
2015-07-27 18:51 GMT+02:00 Jason Merrill :
> I've trimmed this to the previously mentioned issues that still need to be
> addressed; I'll do another full review after these are dealt with.
Thanks for doing this summary of missing parts of prior review.
> On 06/13/2015 12:15 AM, Jason Merrill wrot
I've trimmed this to the previously mentioned issues that still need to
be addressed; I'll do another full review after these are dealt with.
On 06/13/2015 12:15 AM, Jason Merrill wrote:
On 06/12/2015 12:11 PM, Kai Tietz wrote:
@@ -1052,6 +1054,9 @@ adjust_temp_type (tree type, tree temp)
{
On 06/12/2015 12:11 PM, Kai Tietz wrote:
@@ -589,9 +589,9 @@ null_member_pointer_value_p (tree t)
return false;
else if (TYPE_PTRMEMFUNC_P (type))
return (TREE_CODE (t) == CONSTRUCTOR
- && integer_zerop (CONSTRUCTOR_ELT (t, 0)->value));
+ && integer_zerop (fold
Hello Jason,
Thanks for the review. I addressed a lot of your comments directly on
svn-branch. See revision r224439.
- Ursprüngliche Mail -
> Generally, it seems like most of my comments from April haven't been
> addressed yet.
Yes, most of them.
> > @@ -3023,13 +3023,14 @@ conversi
Generally, it seems like most of my comments from April haven't been
addressed yet.
@@ -3023,13 +3023,14 @@ conversion_warning (location_t loc, tree type, tree expr
Instead of adding folds here, let's make sure that the argument we pass
(e.g. from cp_convert_and_check to warnings_for_convert
On 04/28/2015 08:06 AM, Kai Tietz wrote:
2015-04-24 20:25 GMT+02:00 Jason Merrill :
So for warning folding, I think
the caching approach we were talking about in the call today is the way to
go.
Ok. Just a question about where to hook up the hash-variable. What
would be a good place to creat
2015-04-24 20:25 GMT+02:00 Jason Merrill :
> On 04/24/2015 09:46 AM, Kai Tietz wrote:
>>
>> Sure, we can use here instead *_fully_fold, but for what costs? In
>> general we need to deal here a simple one-level fold for simplifying
>> constant-values, and/or removing useless type-conversions.
>
>
>
On 04/24/2015 09:46 AM, Kai Tietz wrote:
Sure, we can use here instead *_fully_fold, but for what costs? In
general we need to deal here a simple one-level fold for simplifying
constant-values, and/or removing useless type-conversions.
Well, here you're doing a two-level fold. And in general
2015-04-24 6:22 GMT+02:00 Jason Merrill :
>> + expr = fold (expr);
>>/* This may happen, because for LHS op= RHS we preevaluate
>> RHS and create C_MAYBE_CONST_EXPR >, which
>> means we could no longer see the code of the EXPR. */
>>if (TREE_CODE (expr) == C_MAYBE_CONST_EXPR)
+ expr = fold (expr);
/* This may happen, because for LHS op= RHS we preevaluate
RHS and create C_MAYBE_CONST_EXPR >, which
means we could no longer see the code of the EXPR. */
if (TREE_CODE (expr) == C_MAYBE_CONST_EXPR)
expr = C_MAYBE_CONST_EXPR_EXPR (expr);
if (TREE_
38 matches
Mail list logo
