* [Bug middle-end/67442] [5/6 Regression] GCC 5.2.0 on x86_64 creates invalid address on specific array index calculation through pointer
2015-09-03 7:00 [Bug c/67442] New: GCC 5.2.0 on x86_64 creates invalid address on specific array index calculation through pointer jussi.judin at ericsson dot com
@ 2015-09-03 8:24 ` rguenth at gcc dot gnu.org
2015-09-03 8:27 ` mpolacek at gcc dot gnu.org
` (12 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: rguenth at gcc dot gnu.org @ 2015-09-03 8:24 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67442
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |ASSIGNED
Version|unknown |5.2.0
Keywords| |wrong-code
Last reconfirmed| |2015-09-03
Component|target |middle-end
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org
Ever confirmed|0 |1
Summary|GCC 5.2.0 on x86_64 creates |[5/6 Regression] GCC 5.2.0
|invalid address on specific |on x86_64 creates invalid
|array index calculation |address on specific array
|through pointer |index calculation through
| |pointer
Target Milestone|--- |5.3
Known to fail| |5.2.0, 6.0
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed on x86_64 and the 5 branch with -O1 even:
main:
.LFB0:
.cfi_startproc
movabsq $foo+4294967408, %rax
movswl (%rax), %eax
ret
.original has:
short int value = *(bar + (sizetype) (((long unsigned int) i * (long unsigned
int) j) * 4294967292 + 16));
works correctly with -fstrict-overflow (or -O2). Some bug in folding
somewhere.
4.8 and 4.9 have
short int value = *(bar + (sizetype) (((long unsigned int) i * (long unsigned
int) j) * 18446744073709551612 + 16));
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug middle-end/67442] [5/6 Regression] GCC 5.2.0 on x86_64 creates invalid address on specific array index calculation through pointer
2015-09-03 7:00 [Bug c/67442] New: GCC 5.2.0 on x86_64 creates invalid address on specific array index calculation through pointer jussi.judin at ericsson dot com
2015-09-03 8:24 ` [Bug middle-end/67442] [5/6 Regression] " rguenth at gcc dot gnu.org
@ 2015-09-03 8:27 ` mpolacek at gcc dot gnu.org
2015-09-03 8:44 ` rguenth at gcc dot gnu.org
` (11 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: mpolacek at gcc dot gnu.org @ 2015-09-03 8:27 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67442
Marek Polacek <mpolacek at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mpolacek at gcc dot gnu.org
--- Comment #2 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Seems this started with r210113 - wide_int merge.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug middle-end/67442] [5/6 Regression] GCC 5.2.0 on x86_64 creates invalid address on specific array index calculation through pointer
2015-09-03 7:00 [Bug c/67442] New: GCC 5.2.0 on x86_64 creates invalid address on specific array index calculation through pointer jussi.judin at ericsson dot com
2015-09-03 8:24 ` [Bug middle-end/67442] [5/6 Regression] " rguenth at gcc dot gnu.org
2015-09-03 8:27 ` mpolacek at gcc dot gnu.org
@ 2015-09-03 8:44 ` rguenth at gcc dot gnu.org
2015-09-03 8:59 ` rguenth at gcc dot gnu.org
` (10 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: rguenth at gcc dot gnu.org @ 2015-09-03 8:44 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67442
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rsandifo at gcc dot gnu.org
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
tree built by
0x00000000009f4f2a in associate_trees (loc=0, t1=0x7ffff69ea230,
t2=0x7ffff69e9378, code=MULT_EXPR, type=0x7ffff68d09d8)
at /space/rguenther/src/svn/trunk/gcc/fold-const.c:919
919 return build2_loc (loc, code, type, fold_convert_loc (loc, type,
t1),
920 fold_convert_loc (loc, type, t2));
#1 0x0000000000a1870e in fold_binary_loc (loc=0, code=MULT_EXPR,
type=0x7ffff68d09d8, op0=0x7ffff69ea208, op1=0x7ffff69fe0e0)
at /space/rguenther/src/svn/trunk/gcc/fold-const.c:9565
#2 0x0000000000a2653c in fold_build2_stat_loc (loc=0, code=MULT_EXPR,
type=0x7ffff68d09d8, op0=0x7ffff69ea208, op1=0x7ffff69fe0e0)
at /space/rguenther/src/svn/trunk/gcc/fold-const.c:12422
#3 0x0000000000a09f78 in extract_muldiv_1 (t=0x7ffff69ea1b8,
c=0x7ffff68e9318, code=MULT_EXPR, wide_type=0x7ffff68d09d8,
strict_overflow_p=0x7fffffffc747)
at /space/rguenther/src/svn/trunk/gcc/fold-const.c:6153
#4 0x0000000000a088d9 in extract_muldiv (t=0x7ffff69ea1b8, c=0x7ffff68e9318,
code=MULT_EXPR, wide_type=0x7ffff68d09d8, strict_overflow_p=0x7fffffffc747)
at /space/rguenther/src/svn/trunk/gcc/fold-const.c:5877
so extract_muldiv goes berzerk somewhere (ugh, how I hate this beast...)
Hmm, no, it looks wide-int related:
/* If these are the same operation types, we can associate them
assuming no overflow. */
if (tcode == code)
{
bool overflow_p = false;
bool overflow_mul_p;
signop sign = TYPE_SIGN (ctype);
wide_int mul = wi::mul (op1, c, sign, &overflow_mul_p);
overflow_p = TREE_OVERFLOW (c) | TREE_OVERFLOW (op1);
if (overflow_mul_p
&& ((sign == UNSIGNED && tcode != MULT_EXPR) || sign == SIGNED))
overflow_p = true;
if (!overflow_p)
return fold_build2 (tcode, ctype, fold_convert (ctype, op0),
wide_int_to_tree (ctype, mul));
so we have op1 == -2, c == 2, both 'int' but ctype is unsinged long. What
wide_int_to_tree does now is _not_ sign-extend mul properly!?
Richard?
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug middle-end/67442] [5/6 Regression] GCC 5.2.0 on x86_64 creates invalid address on specific array index calculation through pointer
2015-09-03 7:00 [Bug c/67442] New: GCC 5.2.0 on x86_64 creates invalid address on specific array index calculation through pointer jussi.judin at ericsson dot com
` (2 preceding siblings ...)
2015-09-03 8:44 ` rguenth at gcc dot gnu.org
@ 2015-09-03 8:59 ` rguenth at gcc dot gnu.org
2015-09-03 9:02 ` rguenth at gcc dot gnu.org
` (9 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: rguenth at gcc dot gnu.org @ 2015-09-03 8:59 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67442
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
That is,
tree
wide_int_to_tree (tree type, const wide_int_ref &pcst)
{
...
unsigned int prec = TYPE_PRECISION (type);
signop sgn = TYPE_SIGN (type);
...
wide_int cst = wide_int::from (pcst, prec, sgn);
is according to its docs "The value is extended from its precision according to
the sign of the type", but that isn't what anyone would expect. IIRC
the wide_int_ref doesn't have a "sign", so we can't do the correct thing.
So IMHO we should require pcst.get_precision () == prec and maybe offer an
overload
tree
wide_int_to_tree (tree type, const wide_int_ref &pcst, signop sgn);
that can specify the sign of pcst (or maybe require that always...).
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug middle-end/67442] [5/6 Regression] GCC 5.2.0 on x86_64 creates invalid address on specific array index calculation through pointer
2015-09-03 7:00 [Bug c/67442] New: GCC 5.2.0 on x86_64 creates invalid address on specific array index calculation through pointer jussi.judin at ericsson dot com
` (3 preceding siblings ...)
2015-09-03 8:59 ` rguenth at gcc dot gnu.org
@ 2015-09-03 9:02 ` rguenth at gcc dot gnu.org
2015-09-03 9:09 ` rguenth at gcc dot gnu.org
` (8 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: rguenth at gcc dot gnu.org @ 2015-09-03 9:02 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67442
--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
I wonder how many bugs of this kind we have lurking in the tree... It works
fine when type has the same signedness as pcst of course, but as we don't
know pcst sign we can't check for that case... The only way to get all
places that need auditing is to assert the precisions match :(
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug middle-end/67442] [5/6 Regression] GCC 5.2.0 on x86_64 creates invalid address on specific array index calculation through pointer
2015-09-03 7:00 [Bug c/67442] New: GCC 5.2.0 on x86_64 creates invalid address on specific array index calculation through pointer jussi.judin at ericsson dot com
` (4 preceding siblings ...)
2015-09-03 9:02 ` rguenth at gcc dot gnu.org
@ 2015-09-03 9:09 ` rguenth at gcc dot gnu.org
2015-09-03 9:11 ` rguenth at gcc dot gnu.org
` (7 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: rguenth at gcc dot gnu.org @ 2015-09-03 9:09 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67442
--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
Ok, truncation also should work, thus
gcc_assert (prec <= pcst.get_precision ());
(trying to see how far bootstrap goes with that)
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug middle-end/67442] [5/6 Regression] GCC 5.2.0 on x86_64 creates invalid address on specific array index calculation through pointer
2015-09-03 7:00 [Bug c/67442] New: GCC 5.2.0 on x86_64 creates invalid address on specific array index calculation through pointer jussi.judin at ericsson dot com
` (5 preceding siblings ...)
2015-09-03 9:09 ` rguenth at gcc dot gnu.org
@ 2015-09-03 9:11 ` rguenth at gcc dot gnu.org
2015-09-03 9:28 ` rguenth at gcc dot gnu.org
` (6 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: rguenth at gcc dot gnu.org @ 2015-09-03 9:11 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67442
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |NEW
CC| |rguenth at gcc dot gnu.org
Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot gnu.org
--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
Ok, so fold_convert_const_int_from_int makes sure to use a widest_int. So
the fold code in question should do the same? But then I suppose overflow
detection doesn't work anymore.
Un-assigning for now, I'm going to be on vacation starting from tomorrow.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug middle-end/67442] [5/6 Regression] GCC 5.2.0 on x86_64 creates invalid address on specific array index calculation through pointer
2015-09-03 7:00 [Bug c/67442] New: GCC 5.2.0 on x86_64 creates invalid address on specific array index calculation through pointer jussi.judin at ericsson dot com
` (6 preceding siblings ...)
2015-09-03 9:11 ` rguenth at gcc dot gnu.org
@ 2015-09-03 9:28 ` rguenth at gcc dot gnu.org
2015-09-03 10:04 ` rguenth at gcc dot gnu.org
` (5 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: rguenth at gcc dot gnu.org @ 2015-09-03 9:28 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67442
--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
/space/rguenther/src/svn/trunk2/gcc/genmatch.c:4640:1: internal compiler
error:in wide_int_to_tree, at tree.c:1398
}
^
0x12cfa95 wide_int_to_tree(tree_node*,
generic_wide_int<wide_int_ref_storage<false> > const&)
/space/rguenther/src/svn/trunk2/gcc/tree.c:1398
0x133cd51 output_constant
/space/rguenther/src/svn/trunk2/gcc/varasm.c:4702
so we don't get very far. Of course
else if (TREE_CODE (exp) == INTEGER_CST)
exp = wide_int_to_tree (saved_type, exp);
is just a stupid way to write fold_convert (saved_type, exp). Or not, if
the special wide_int_to_tree behavior was desired.
Seems we get a bit further with the above "fixed".
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug middle-end/67442] [5/6 Regression] GCC 5.2.0 on x86_64 creates invalid address on specific array index calculation through pointer
2015-09-03 7:00 [Bug c/67442] New: GCC 5.2.0 on x86_64 creates invalid address on specific array index calculation through pointer jussi.judin at ericsson dot com
` (7 preceding siblings ...)
2015-09-03 9:28 ` rguenth at gcc dot gnu.org
@ 2015-09-03 10:04 ` rguenth at gcc dot gnu.org
2015-09-15 14:21 ` rguenth at gcc dot gnu.org
` (4 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: rguenth at gcc dot gnu.org @ 2015-09-03 10:04 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67442
--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
Bootstrap finished with that assert and the fix (c,c++,fortran only, expanding
that now). I'm going to commit the varasm.c change if testing is fine.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug middle-end/67442] [5/6 Regression] GCC 5.2.0 on x86_64 creates invalid address on specific array index calculation through pointer
2015-09-03 7:00 [Bug c/67442] New: GCC 5.2.0 on x86_64 creates invalid address on specific array index calculation through pointer jussi.judin at ericsson dot com
` (8 preceding siblings ...)
2015-09-03 10:04 ` rguenth at gcc dot gnu.org
@ 2015-09-15 14:21 ` rguenth at gcc dot gnu.org
2015-09-16 7:25 ` rguenth at gcc dot gnu.org
` (3 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: rguenth at gcc dot gnu.org @ 2015-09-15 14:21 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67442
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org
--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
Testing
@@ -6166,8 +6173,12 @@ extract_muldiv_1 (tree t, tree c, enum t
&& ((sign == UNSIGNED && tcode != MULT_EXPR) || sign == SIGNED))
overflow_p = true;
if (!overflow_p)
- return fold_build2 (tcode, ctype, fold_convert (ctype, op0),
- wide_int_to_tree (ctype, mul));
+ {
+ mul = wide_int::from (mul, TYPE_PRECISION (ctype),
+ TYPE_SIGN (TREE_TYPE (op1)));
+ return fold_build2 (tcode, ctype, fold_convert (ctype, op0),
+ wide_int_to_tree (ctype, mul));
+ }
}
/* If these operations "cancel" each other, we have the main
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug middle-end/67442] [5/6 Regression] GCC 5.2.0 on x86_64 creates invalid address on specific array index calculation through pointer
2015-09-03 7:00 [Bug c/67442] New: GCC 5.2.0 on x86_64 creates invalid address on specific array index calculation through pointer jussi.judin at ericsson dot com
` (9 preceding siblings ...)
2015-09-15 14:21 ` rguenth at gcc dot gnu.org
@ 2015-09-16 7:25 ` rguenth at gcc dot gnu.org
2015-09-16 7:26 ` [Bug middle-end/67442] [5 " rguenth at gcc dot gnu.org
` (2 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: rguenth at gcc dot gnu.org @ 2015-09-16 7:25 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67442
--- Comment #12 from Richard Biener <rguenth at gcc dot gnu.org> ---
Author: rguenth
Date: Wed Sep 16 07:25:15 2015
New Revision: 227818
URL: https://gcc.gnu.org/viewcvs?rev=227818&root=gcc&view=rev
Log:
2015-09-16 Richard Biener <rguenther@suse.de>
PR middle-end/67442
* fold-const.c (extract_muldiv_1): Properly extend multiplication
result before builting a tree via wide_int_to_tree.
* gcc.dg/torture/pr67442.c: New testcase.
Added:
trunk/gcc/testsuite/gcc.dg/torture/pr67442.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug middle-end/67442] [5 Regression] GCC 5.2.0 on x86_64 creates invalid address on specific array index calculation through pointer
2015-09-03 7:00 [Bug c/67442] New: GCC 5.2.0 on x86_64 creates invalid address on specific array index calculation through pointer jussi.judin at ericsson dot com
` (10 preceding siblings ...)
2015-09-16 7:25 ` rguenth at gcc dot gnu.org
@ 2015-09-16 7:26 ` rguenth at gcc dot gnu.org
2015-09-28 10:46 ` rguenth at gcc dot gnu.org
2015-09-28 10:46 ` rguenth at gcc dot gnu.org
13 siblings, 0 replies; 15+ messages in thread
From: rguenth at gcc dot gnu.org @ 2015-09-16 7:26 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67442
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Known to work| |6.0
Summary|[5/6 Regression] GCC 5.2.0 |[5 Regression] GCC 5.2.0 on
|on x86_64 creates invalid |x86_64 creates invalid
|address on specific array |address on specific array
|index calculation through |index calculation through
|pointer |pointer
Known to fail|6.0 |
--- Comment #13 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed on trunk sofar.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug middle-end/67442] [5 Regression] GCC 5.2.0 on x86_64 creates invalid address on specific array index calculation through pointer
2015-09-03 7:00 [Bug c/67442] New: GCC 5.2.0 on x86_64 creates invalid address on specific array index calculation through pointer jussi.judin at ericsson dot com
` (11 preceding siblings ...)
2015-09-16 7:26 ` [Bug middle-end/67442] [5 " rguenth at gcc dot gnu.org
@ 2015-09-28 10:46 ` rguenth at gcc dot gnu.org
2015-09-28 10:46 ` rguenth at gcc dot gnu.org
13 siblings, 0 replies; 15+ messages in thread
From: rguenth at gcc dot gnu.org @ 2015-09-28 10:46 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67442
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution|--- |FIXED
--- Comment #14 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug middle-end/67442] [5 Regression] GCC 5.2.0 on x86_64 creates invalid address on specific array index calculation through pointer
2015-09-03 7:00 [Bug c/67442] New: GCC 5.2.0 on x86_64 creates invalid address on specific array index calculation through pointer jussi.judin at ericsson dot com
` (12 preceding siblings ...)
2015-09-28 10:46 ` rguenth at gcc dot gnu.org
@ 2015-09-28 10:46 ` rguenth at gcc dot gnu.org
13 siblings, 0 replies; 15+ messages in thread
From: rguenth at gcc dot gnu.org @ 2015-09-28 10:46 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67442
--- Comment #15 from Richard Biener <rguenth at gcc dot gnu.org> ---
Author: rguenth
Date: Mon Sep 28 10:45:55 2015
New Revision: 228199
URL: https://gcc.gnu.org/viewcvs?rev=228199&root=gcc&view=rev
Log:
2015-09-28 Richard Biener <rguenther@suse.de>
Backport from mainline
2015-08-03 Richard Biener <rguenther@suse.de>
PR tree-optimization/66917
* tree-vectorizer.h (struct dataref_aux): Add base_element_aligned
field.
(DR_VECT_AUX): New macro.
(set_dr_misalignment): Adjust.
(dr_misalignment): Likewise.
* tree-vect-data-refs.c (vect_compute_data_ref_alignment):
Compute whether the base is at least element aligned.
* tree-vect-stmts.c (ensure_base_align): Adjust.
(vectorizable_store): If the base is not element aligned
preserve alignment of the original access if misalignment is unknown.
(vectorizable_load): Likewise.
2015-09-16 Richard Biener <rguenther@suse.de>
PR middle-end/67442
* fold-const.c (extract_muldiv_1): Properly extend multiplication
result before builting a tree via wide_int_to_tree.
* gcc.dg/torture/pr67442.c: New testcase.
Added:
branches/gcc-5-branch/gcc/testsuite/gcc.dg/torture/pr67442.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/fold-const.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog
branches/gcc-5-branch/gcc/tree-vect-data-refs.c
branches/gcc-5-branch/gcc/tree-vect-stmts.c
branches/gcc-5-branch/gcc/tree-vectorizer.h
^ permalink raw reply [flat|nested] 15+ messages in thread