[Bug libstdc++/69190] FAIL: experimental/type_erased_allocator/uses_allocator.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69190 --- Comment #2 from Thomas Preud'homme --- It is indeed. Thanks
[Bug sanitizer/69147] [5 Regression] Several hundred asan failures with 5.3.1 on x86_64-apple-darwin15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69147 Yury Gribov changed: What|Removed |Added CC||chefmax at gcc dot gnu.org, ||y.gribov at samsung dot com --- Comment #1 from Yury Gribov --- Cc Max.
[Bug tree-optimization/69058] segfault with ftree-parallelize-loops=2 in libgo/go/strconv/decimal.go
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69058 --- Comment #3 from vries at gcc dot gnu.org --- Author: vries Date: Mon Jan 11 08:55:16 2016 New Revision: 232208 URL: https://gcc.gnu.org/viewcvs?rev=232208&root=gcc&view=rev Log: Don't parallelize loops if libgomp not supported 2016-01-11 Tom de Vries PR tree-optimization/69058 * tree-parloops.c (pass_parallelize_loops::execute): Return 0 if libgomp not supported. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-parloops.c
[Bug driver/67425] -frandom-seed documentation doesn't match code, incomplete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67425 --- Comment #3 from ygribov at gcc dot gnu.org --- Author: ygribov Date: Mon Jan 11 09:06:14 2016 New Revision: 232209 URL: https://gcc.gnu.org/viewcvs?rev=232209&root=gcc&view=rev Log: Fix docs for -frandom-seed. 2016-01-11 Yury Gribov PR 67425 * common.opt (frandom-seed): Fix parameter name. * doc/invoke.texi (frandom-seed): Ditto and describe parameter. Modified: trunk/gcc/ChangeLog trunk/gcc/common.opt trunk/gcc/doc/invoke.texi
[Bug driver/67425] -frandom-seed documentation doesn't match code, incomplete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67425 --- Comment #4 from ygribov at gcc dot gnu.org --- Author: ygribov Date: Mon Jan 11 09:11:11 2016 New Revision: 232210 URL: https://gcc.gnu.org/viewcvs?rev=232210&root=gcc&view=rev Log: Backport fix docs for -frandom-seed. 2016-01-11 Yury Gribov Backport from mainline 2016-01-11 Yury Gribov PR 67425 * common.opt (frandom-seed): Fix parameter name. * doc/invoke.texi (frandom-seed): Ditto and describe parameter. Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/common.opt branches/gcc-5-branch/gcc/doc/invoke.texi
[Bug tree-optimization/69058] segfault with ftree-parallelize-loops=2 in libgo/go/strconv/decimal.go
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69058 vries at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ian at airs dot com Resolution|--- |FIXED --- Comment #4 from vries at gcc dot gnu.org --- Patch committed. Could be nice to have a go testcase, but haven't figured out how to do that yet. Marking resolved-fixed.
[Bug driver/67425] -frandom-seed documentation doesn't match code, incomplete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67425 --- Comment #5 from Yury Gribov --- Martin, is this better now? Could you close the bug?
[Bug tree-optimization/69108] [6 Regression] ICE in gather_scalar_reductions with -ftree-parallelize-loops=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69108 --- Comment #3 from vries at gcc dot gnu.org --- Author: vries Date: Mon Jan 11 09:19:33 2016 New Revision: 232211 URL: https://gcc.gnu.org/viewcvs?rev=232211&root=gcc&view=rev Log: Handle case that outer phi res is not used in a phi in gather_scalar_reductions 2016-01-11 Tom de Vries PR tree-optimization/69108 * tree-parloops.c (gather_scalar_reductions): Handle case that outer phi res is not used in a phi. * gcc.dg/autopar/pr69108.c: New test. Added: trunk/gcc/testsuite/gcc.dg/autopar/pr69108.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-parloops.c
[Bug c++/69220] Internal error with array of negative size and initializers for it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69220
Richard Biener changed:
What|Removed |Added
Keywords||accepts-invalid,
||compile-time-hog
Status|UNCONFIRMED |NEW
Last reconfirmed||2016-01-11
Known to work||6.0
Ever confirmed|0 |1
Known to fail||5.3.0
--- Comment #1 from Richard Biener ---
On trunk:
> /abuild/rguenther/trunk3-g/gcc/cc1plus -quiet t.C -std=c++11t.C: In function
> ‘int main()’:
t.C:3:28: error: size of array is negative
int* p = new int[-1]{1};
^
confirmed for GCC 5 where it loops in
#0 process_init_constructor_array (type=0x769e3bd0, init=0x769ebee8,
complain=3) at /space/rguenther/src/svn/gcc-5-branch/gcc/cp/typeck2.c:1295
1291for (; i < len; ++i)
(gdb) p len
$2 = 18446744073709551615
(gdb) p i
$3 = 271414772
I suspect that
int *p = new int[184467440737095LL]{1};
might also take quite some time due to the loop not exiting early.
[Bug target/69187] ICE: Aborted when native compiling neon code with __builtin_neon_vmlals_lanev4hi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69187
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #7 from Jakub Jelinek ---
Seems the identical bug in aarch64 backend has been fixed with r221807.
The patch needs proper ChangeLog entry and the testcase added into the
testsuite too. Perhaps just grab the testcase from PR65624, and stick it into
testsuite/gcc.target/arm/
with
/* PR target/69187 */
/* { dg-require-effective-target arm_neon } */
/* { dg-options "-O0" } */
/* { dg-add-options arm_neon } */
or so?
[Bug ada/69219] [5/6 regression] failed to compile nested subprograms with Inline_Always and Intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69219 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |5.4
[Bug rtl-optimization/69217] [6 Regression] ICE at var-tracking.c:5038 Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69217 Richard Biener changed: What|Removed |Added CC||aoliva at gcc dot gnu.org, ||ebotcazou at gcc dot gnu.org Component|middle-end |rtl-optimization Target Milestone|--- |6.0 Summary|ICE at var-tracking.c:5038 |[6 Regression] ICE at |Segmentation fault |var-tracking.c:5038 ||Segmentation fault
[Bug sanitizer/69147] [5 Regression] Several hundred asan failures with 5.3.1 on x86_64-apple-darwin15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69147 --- Comment #2 from Maxim Ostapenko --- Dominique, could you please run ASan tests with ASAN_OPTIONS=debug=1:verbosity=2? This might be helpful for further debugging.
[Bug c++/69216] posix_memalign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69216 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2016-01-11 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Please provide information on the GCC version you are using as well as preprocessed source.
[Bug tree-optimization/69214] [4.9/5/6 Regression] ICE (segfault) at -Os on x86_64-linux-gnu in "fail_abnormal_edge_coalesce"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69214 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-01-11 Known to work||4.8.5 Target Milestone|--- |4.9.4 Summary|ICE (segfault) at -Os on|[4.9/5/6 Regression] ICE |x86_64-linux-gnu in |(segfault) at -Os on |"fail_abnormal_edge_coalesc |x86_64-linux-gnu in |e" |"fail_abnormal_edge_coalesc ||e" Ever confirmed|0 |1 Known to fail||4.9.2, 5.3.0, 6.0 --- Comment #3 from Richard Biener --- Confirmed.
[Bug target/69187] ICE: Aborted when native compiling neon code with __builtin_neon_vmlals_lanev4hi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69187
--- Comment #8 from ktkachov at gcc dot gnu.org ---
Yes, that should do.
/* PR target/69187 */
/* { dg-do compile } */
/* { dg-require-effective-target arm_neon } */
/* { dg-options "-O0" } */
/* { dg-add-options arm_neon } */
Please send the patch to gcc-patc...@gcc.gnu.org
[Bug rtl-optimization/69217] [6 Regression] ICE at var-tracking.c:5038 Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69217 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2016-01-11 Ever confirmed|0 |1 --- Comment #4 from Eric Botcazou --- > While I should get round to fixing the gimplify stage to conform, I think > the middle-end should do something other than SEGV when this happens. > > e.g: > > if (TYPE_FIELDS (type) == NULL_TREE > || DECL_CHAIN (TYPE_FIELDS (type)) == NULL_TREE) > return false; Yes, that's the correct thing to do, please test it and post the patch on the gcc-patches@ list once done.
[Bug tree-optimization/69108] [6 Regression] ICE in gather_scalar_reductions with -ftree-parallelize-loops=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69108 vries at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from vries at gcc dot gnu.org --- patch with test-case committed, marking resolved-fixed.
[Bug tree-optimization/69213] [6 Regression] g++ ICE (segfault) at -O1 and above on x86_64-linux-gnu in "add_dependency"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69213
--- Comment #2 from Richard Biener ---
The SSA _1 doesn't have a def stmt ...
int main() ()
{
bool a_lsm.9;
int a_lsm.8;
bool b_lsm.7;
int b_lsm.6;
unsigned int _1;
unsigned int _3;
int _7;
int a.0_9;
:
a.0_9 = a;
if (a.0_9 >= 0)
goto ;
else
goto ;
:
b_lsm.6_12 = b;
:
# b_lsm.6_6 = PHI
_7 = b_lsm.6_6 + 1;
b_lsm.6_14 = (int) _1;
if (b_lsm.6_14 >= 0)
goto ;
else
goto ;
:
goto ;
:
# a_lsm.8_22 = PHI
# b_lsm.6_24 = PHI <_7(4)>
b = b_lsm.6_24;
a = a_lsm.8_22;
:
return 0;
already broken in IVOPTs.
[Bug tree-optimization/69213] [6 Regression] g++ ICE (segfault) at -O1 and above on x86_64-linux-gnu in "add_dependency"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69213 --- Comment #3 from Richard Biener --- *** Bug 69212 has been marked as a duplicate of this bug. ***
[Bug middle-end/69212] [6 Regresion] g++ ICE (segfault) at -O3 on x86_64-linux-gnu in fsm_find_control_statement_thread_paths
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69212 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Richard Biener --- Essentially a dup - SSA name without def stmt. *** This bug has been marked as a duplicate of bug 69213 ***
[Bug tree-optimization/69209] [6 Regression] ICE at -Os and above on x86_64-linux-gnu (verify_gimple failed)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69209 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED CC||hubicka at gcc dot gnu.org Blocks||68721 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener --- Hmpf. I hate IPA split. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68721 [Bug 68721] [6 Regression] wrong code at -Os and above on x86_64-linux-gnu
[Bug tree-optimization/69109] [6 Regression] missing phi argument ICE in transform_to_exit_first_loop_alt with -O2 -funswitch-loops -ftree-parallelize-loops=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69109 --- Comment #5 from vries at gcc dot gnu.org --- Author: vries Date: Mon Jan 11 09:38:28 2016 New Revision: 232212 URL: https://gcc.gnu.org/viewcvs?rev=232212&root=gcc&view=rev Log: Don't allow latch with phi in try_transform_to_exit_first_loop_alt 2016-01-11 Tom de Vries PR tree-optimization/69109 * tree-parloops.c (try_transform_to_exit_first_loop_alt): Don't allow latch with phi. * gcc.dg/autopar/pr69109-2.c: New test. * gcc.dg/autopar/pr69109.c: New test. Added: trunk/gcc/testsuite/gcc.dg/autopar/pr69109-2.c trunk/gcc/testsuite/gcc.dg/autopar/pr69109.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-parloops.c
[Bug tree-optimization/69196] code size regression with jump threading at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69196
--- Comment #4 from Sebastian Huber ---
I did a very rough check to see which code is faster on the PSIM/GDB simulator
using the following input data:
void printk(const char *fmt, ...)
{
va_list ap;
va_start(ap, fmt);
vprintk(fmt, ap);
va_end(ap);
}
void test(void)
{
char *s = "x";
printk("abc%sx%ix%cx%lu\n", s, 0, 'c', 1UL);
}
GCC 4.9: 311 time units
GCC 6: 316 time units
I guess its quite difficult to determine if this target independent code size
increase is actually a regression in general. At least in this particular
function with this particular input data on this particular target/simulator
the code size is nearly doubled and the execution is slightly slower.
[Bug tree-optimization/69207] [6 Regression] gcc.target/aarch64/vldN_1.c ICEs at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69207 --- Comment #5 from Richard Biener --- (In reply to Jakub Jelinek from comment #4) > Seems there is a mismatch in between fold_convertible_p and > verify_gimple_assign_unary (and also the gimplifier). > E.g. for this special case fold_convertible_p has some weird exception: > 2188return (TREE_CODE (orig) == VECTOR_TYPE > 2189&& tree_int_cst_equal (TYPE_SIZE (type), TYPE_SIZE > (orig))); > But verify_gimple_assign_unary certainly doesn't allow that. It has also > various other restrictions, e.g. on pointer conversions etc. > So, Richard, do we or should we have another predicate that says for outer > and inner type if it is ok to use GIMPLE_ASSIGN with NOP_EXPR? > Most of the uses that use fold_convertible_p in the middle-end actually > perform fold_convert or fold_build1 (... NOP_EXPR, ...), which creates a > NOP_EXPR from the VECTOR_TYPE to same sized integral type. But that's invalid. fold_convert does case VECTOR_TYPE: if (integer_zerop (arg)) return build_zero_vector (type); gcc_assert (tree_int_cst_equal (TYPE_SIZE (type), TYPE_SIZE (orig))); gcc_assert (INTEGRAL_TYPE_P (orig) || POINTER_TYPE_P (orig) || TREE_CODE (orig) == VECTOR_TYPE); return fold_build1_loc (loc, VIEW_CONVERT_EXPR, type, arg); thus always creates a VCE. Note that fold_build1 (... NOP_EXPR ...) is _not_ equivalent to fold_convert (...)! > Strangely, when > trying to gimplify that it just creates a NOP_EXPR GIMPLE_ASSIGN, which then > fails verification. > So, what is the above mentioned 2188/2189 there for and corresponding > fold_convert_loc: > 2246gcc_assert (TREE_CODE (orig) == VECTOR_TYPE > 2247&& tree_int_cst_equal (TYPE_SIZE (type), TYPE_SIZE > (orig))); > 2248return fold_build1_loc (loc, NOP_EXPR, type, arg); > Shall it not create a VCE instead? > Or shall it at least not gimplify to a VCE instead of a NOP_EXPR? > For the tree-vect-slp.c case it is of course enough to just replace > fold_convertible_p with INTEGRAL_TYPE_P && INTEGRAL_TYPE_P check, but I > really think we should figure out what we want and have proper predicates > for it. I think on gimple we can't simply use fold_convertible_p because that has special handling for a lot of cases where it doesn't end up generating a NOP_EXPR. That is, if fold_convertible_p you can call fold_convert without ICEing, you can't just build a NOP_EXPR gimple assign.
[Bug target/69199] Incorrect prototypes for AVX512 unaligned load/store builtin functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69199 --- Comment #1 from Richard Biener --- OTOH it doesn't really matter to the middle-end.
[Bug c++/69222] [5/6 Regression] C++14 template code working in GCC 5.1 stops working in 5.2 and 5.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69222 Richard Biener changed: What|Removed |Added Keywords||rejects-valid Known to work||5.1.0 Target Milestone|--- |5.4 Summary|C++14 template code working |[5/6 Regression] C++14 |in GCC 5.1 stops working in |template code working in |5.2 and 5.3 |GCC 5.1 stops working in ||5.2 and 5.3 Known to fail||5.2.0
[Bug tree-optimization/69209] [6 Regression] ICE at -Os and above on x86_64-linux-gnu (verify_gimple failed)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69209 --- Comment #3 from Jakub Jelinek --- Unless I'm misreading ipa-split.c, it seems it is unprepared to see addressable retvals with gimple reg type, but where due to the addressability retval is not is_gimple_val. Unfortunately, it doesn't seem to be just a single spot, but tons of them. I'm afraid with right testcases we could end up e.g. with addressable int var on the lhs of a call, or as base of a MEM, etc. Richard, can you please have a look?
[Bug c/69224] -Warray-bounds false positive with -O3 and struct pointer parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69224 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-01-11 CC||hubicka at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- If you comment the line x is a trailing array we don't know its size for and thus we don't warn. As with (many?) other cases this happens because complete peeling added one copy too much (too conservative number of iteration upper bound): _72 = s_47->x[4]; if (_39 >= _72) goto ; else goto ; : _74 = s_47->x[5]; if (_39 <= _74) goto ; else goto ; so we have a x[5] in the IL and VRP can't prove it is not reachable either (obviously). niter analysis does: Statement _22 = s_7(D)->x[j_2]; is executed at most 4 (bounded by 4) + 1 times in loop 2. Statement _25 = s_7(D)->x[_24]; is executed at most 3 (bounded by 3) + 1 times in loop 2. Loop 2 iterates at most 5 times. t.c:16:33: note: loop with 6 iterations completely unrolled Latch of last iteration was marked by __builtin_unreachable (). Forced statement unreachable: _25 = s_7(D)->x[_24]; Forced statement unreachable: _22 = s_7(D)->x[j_2]; it looks like the conditionally read s->x[j] is not properly marked unreachable.
[Bug c++/69222] [5/6 Regression] C++14 template code working in GCC 5.1 stops working in 5.2 and 5.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69222 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-01-11 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- This is PR 69005 which I still have a pending patch for, in addition to Jason's front-end change.
[Bug ipa/66616] [4.9/5/6 regression] fipa-cp-clone ignores thunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66616 --- Comment #20 from Martin Jambor --- Author: jamborm Date: Mon Jan 11 09:59:48 2016 New Revision: 232213 URL: https://gcc.gnu.org/viewcvs?rev=232213&root=gcc&view=rev Log: [PR 66616] Check for thunks when adding extra constants to clones 2016-01-11 Martin Jambor PR ipa/66616 * ipa-cp.c (propagate_constants_accross_call): Move thuk check... (call_passes_through_thunk_p): ...here. (find_more_scalar_values_for_callers_subset): Perform thunk checks like propagate_constants_accross_call does. * cgraphclones.c (duplicate_thunk_for_node): Copy can_change_signature flag from the node to the new flag. testsuite/ * g++.dg/ipa/pr66616.C: New test. Added: branches/gcc-4_9-branch/gcc/testsuite/g++.dg/ipa/pr66616.C Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/cgraphclones.c branches/gcc-4_9-branch/gcc/ipa-cp.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug ipa/66616] [4.9/5/6 regression] fipa-cp-clone ignores thunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66616 --- Comment #21 from Martin Jambor --- Author: jamborm Date: Mon Jan 11 10:03:44 2016 New Revision: 232214 URL: https://gcc.gnu.org/viewcvs?rev=232214&root=gcc&view=rev Log: [PR ipa/66616] Copy can_change_signature flag to artificial thunks 2016-01-11 Martin Jambor PR ipa/66616 * cgraphclones.c (duplicate_thunk_for_node): Copy can_change_signature flag. Modified: trunk/gcc/ChangeLog trunk/gcc/cgraphclones.c
[Bug c++/68979] [6 Regression] error: left operand of shift expression ‘(-1 << 4)’ is negative
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68979 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-01-11 Ever confirmed|0 |1 --- Comment #3 from Richard Biener --- Maybe a warning that becomes an error with -pedantic[-errors] or at least accept this with -fpermissive. FWIW I agree it's a bit harsh by default.
[Bug ipa/68981] [4.9/5/6 Regression] g++.dg/ipa/pr60640-4.C FAILs with -ftree-vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68981 Richard Biener changed: What|Removed |Added Target||i?86-*-* Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-01-11 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- I will have a look.
[Bug target/68986] internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68986 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-01-11 Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- Confirmed.
[Bug ipa/69044] [6 regression] [CHKP] internal compiler error: in duplicate_thunk_for_node
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69044 --- Comment #4 from Martin Jambor --- Author: jamborm Date: Mon Jan 11 10:09:17 2016 New Revision: 232215 URL: https://gcc.gnu.org/viewcvs?rev=232215&root=gcc&view=rev Log: [PR ipa/69044] Do not clone for param removal when not possible 2016-01-11 Martin Jambor PR ipa/69044 * ipa-cp.c (estimate_local_effects): Do not clone for removal of useless parameters if we cannot change function signature. testsuite/ * gcc.target/i386/chkp-pr69044.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/chkp-pr69044.c Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-cp.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/69109] [6 Regression] missing phi argument ICE in transform_to_exit_first_loop_alt with -O2 -funswitch-loops -ftree-parallelize-loops=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69109 vries at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from vries at gcc dot gnu.org --- patch with test-cases committed, marking resolved-fixed.
[Bug ipa/69044] [6 regression] [CHKP] internal compiler error: in duplicate_thunk_for_node
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69044 Martin Jambor changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Martin Jambor --- Fixed with https://gcc.gnu.org/ml/gcc-patches/2016-01/msg00445.html
[Bug rtl-optimization/69052] [6 Regression] Performance regression after r229402.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69052 --- Comment #2 from amker at gcc dot gnu.org --- It's my change, I will look into it.
[Bug tree-optimization/69058] segfault with ftree-parallelize-loops=2 in libgo/go/strconv/decimal.go
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69058 Thomas Schwinge changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||tschwinge at gcc dot gnu.org --- Comment #5 from Thomas Schwinge --- Isn't it a gccgo front end (spec) bug, that it doesn't bring in GOMP stuff (builtins, link against libgomp) under the presence of "-ftree-parallelize-loops=2"? Cf. gcc/gcc.c:GOMP_SELF_SPECS.
[Bug target/69010] Boolean vector constant with a scalar mode is expanded incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69010 --- Comment #1 from Ilya Enkovich --- Author: ienkovich Date: Mon Jan 11 10:27:17 2016 New Revision: 232216 URL: https://gcc.gnu.org/viewcvs?rev=232216&root=gcc&view=rev Log: gcc/ PR target/69010 * expr.c (expand_expr_real_1): For boolean vector constants with a scalar mode use const_scalar_mask_from_tree. (const_scalar_mask_from_tree): New. * optabs.c (expand_vec_cond_mask_expr): Use mask mode assigned to a mask type to handle constants. gcc/testsuite/ PR target/69010 * gcc.target/i386/pr69010.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr69010.c Modified: trunk/gcc/ChangeLog trunk/gcc/expr.c trunk/gcc/optabs.c trunk/gcc/testsuite/ChangeLog
[Bug target/59810] [AArch64] LDn/STn implementations are not ABI-conformant for bigendian.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59810 James Greenhalgh changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2016-01-11 CC||jgreenhalgh at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from James Greenhalgh --- I believe this is now fixed?
[Bug target/69161] [6 Regression] ICE in simplify_const_unary_operation, at simplify-rtx.c:1633
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69161 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Component|rtl-optimization|target Assignee|unassigned at gcc dot gnu.org |ktkachov at gcc dot gnu.org --- Comment #17 from ktkachov at gcc dot gnu.org --- target issue then.
[Bug target/65770] [AArch64] vst2_lane broken on bigendian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65770 James Greenhalgh changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jgreenhalgh at gcc dot gnu.org Resolution|--- |FIXED --- Comment #1 from James Greenhalgh --- Looks to be fixed.
[Bug target/65770] [AArch64] vst2_lane broken on bigendian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65770 --- Comment #2 from James Greenhalgh --- r222582 for reference.
[Bug tree-optimization/69058] segfault with ftree-parallelize-loops=2 in libgo/go/strconv/decimal.go
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69058 --- Comment #6 from vries at gcc dot gnu.org --- (In reply to Thomas Schwinge from comment #5) > Isn't it a gccgo front end (spec) bug, that it doesn't bring in GOMP stuff > (builtins, link against libgomp) under the presence of > "-ftree-parallelize-loops=2"? Cf. gcc/gcc.c:GOMP_SELF_SPECS. Making parloops robust against missing libgomp support is a conservative fix for the ICE, and appropriate for stage3. Enabling parloops for go could be a stage1 effort. But (having no go knowledge whatsoever) I cannot exclude the possibility that the libgomp support is missing intentionally.
[Bug bootstrap/69123] [6 Regression] --with-build-config='bootstrap-O3 bootstrap-debug' miscompiled stage 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69123 --- Comment #16 from Alexandre Oliva --- Author: aoliva Date: Mon Jan 11 10:40:12 2016 New Revision: 232217 URL: https://gcc.gnu.org/viewcvs?rev=232217&root=gcc&view=rev Log: [PR69123] make dataflow_set_different details more verbose for gcc/ChangeLog PR bootstrap/69123 * var-tracking.c (dump_onepart_variable_differences): New. (dataflow_set_different): If a detailed dump is requested, delay early returns and dump differences between onepart variables present before and after, and added variables. Modified: trunk/gcc/ChangeLog trunk/gcc/var-tracking.c
[Bug bootstrap/69123] [6 Regression] --with-build-config='bootstrap-O3 bootstrap-debug' miscompiled stage 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69123 --- Comment #17 from Alexandre Oliva --- Author: aoliva Date: Mon Jan 11 10:40:33 2016 New Revision: 232218 URL: https://gcc.gnu.org/viewcvs?rev=232218&root=gcc&view=rev Log: [PR69123] fix handling of MEMs in VTA to avoid dataflow oscillation The problem arises because we used to drop overwritten MEMs from loc lists of VALUEs, but not of other onepart variables, and it just so happens that, by doing so, block 6 in the testcase has no D#5 in its output in the first pass, because the MEM holding its (previous) value was correctly dropped from value 88:88, but gains it in the second pass because D#5 has the MEM location incoming directly in its loc list, rather than indirectly in a VALUE. This incorrect binding enables other blocks to believe they have a tentative binding for D#5 in some cycles, but others, still operating on the early conclusion, believe there isn't, and they oscillate from that. Since we check for escaping MEMs in clobbers, we won't lose anything relevant by dropping call-clobbered or overwritten MEMs in all onepart variables, and this ensures the loc intersection operation in onepart vars won't let a MEM through that wasn't present in earlier iterations. for gcc/ChangeLog PR bootstrap/69123 * var-tracking.c (drop_overlapping_mem_locs): Operate on all onepart vars. Fix typo in comment. Fix reversed condition in unshare test. (dataflow_set_remove_mem_locs): Operate on all onepart vars. for gcc/testsuite/ChangeLog PR bootstrap/69123 * g++.dg/pr69123.C: New. Added: trunk/gcc/testsuite/g++.dg/pr69123.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/var-tracking.c
[Bug target/69010] Boolean vector constant with a scalar mode is expanded incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69010 Ilya Enkovich changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Ilya Enkovich --- Fixed
[Bug target/69225] New: gcc uses double precision instead of single float with -m32 -std=c99 -msoft-float
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69225
Bug ID: 69225
Summary: gcc uses double precision instead of single float with
-m32 -std=c99 -msoft-float
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: vaalfreja at gmail dot com
Target Milestone: ---
Testcase:
int main(){
float x, y, z;
z = x+y;
return 0;
}
Soft float first extends the result to double precision then truncates it.
[Bug tree-optimization/69214] [4.9/5/6 Regression] ICE (segfault) at -Os on x86_64-linux-gnu in "fail_abnormal_edge_coalesce"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69214 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Introduced in vrp1. I'll have a look.
[Bug bootstrap/69123] [6 Regression] --with-build-config='bootstrap-O3 bootstrap-debug' miscompiled stage 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69123 Alexandre Oliva changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #18 from Alexandre Oliva --- Fixed
[Bug c++/69211] [6 Regression] g++ ICE on x86_64-linux-gnu (verify_gimple failed)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69211 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Started with r230365. I'll have a look.
[Bug middle-end/69225] gcc uses double precision instead of single float with -m32 -std=c99 -msoft-float
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69225
Uroš Bizjak changed:
What|Removed |Added
Component|target |middle-end
--- Comment #1 from Uroš Bizjak ---
Not a target issue, this is what middle-end gives us with -std=c99, even for:
float test (float a, float b)
{
return a + b;
}
~/gcc-build/gcc/cc1 -O2 -m32 -std=c99 -msoft-float -fdump-tree-optimized
float.c.208t.optimized:
;; Function test (test, funcdef_no=0, decl_uid=1275, cgraph_uid=0,
symbol_order=0)
test (float a, float b)
{
long double _2;
long double _4;
long double _5;
float _6;
:
_2 = (long double) a_1(D);
_4 = (long double) b_3(D);
_5 = _2 + _4;
_6 = (float) _5;
return _6;
}
Without -std=c99, we get:
;; Function test (test, funcdef_no=0, decl_uid=1405, cgraph_uid=0,
symbol_order=0)
test (float a, float b)
{
float _3;
:
_3 = a_1(D) + b_2(D);
return _3;
}
[Bug tree-optimization/69155] [6 Regression] ICE (segfault in gimple_stmt_nonnegative_warnv_p)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69155 --- Comment #6 from Richard Biener --- (In reply to Jakub Jelinek from comment #4) > (In reply to Richard Biener from comment #2) > > I think we have a dup/related bug where we run into the issue that > > tree-complex.c > > wrecks SSA form during its rewrite. > > That is indeed what happens, but what solution do you see other than > avoiding all the simplifications/optimizations that follow ssa edges? In the other bug we discussed to do the processing in proper (dominator) order. Richard, any progress on that? > We have: > : > # a_22 = PHI > # b_23 = PHI > # a$real_28 = PHI > # a$imag_29 = PHI > # b$real_32 = PHI > # b$imag_33 = PHI > _9 = __complex__ (1.0e+0, 0.0) / a_22; > b_10 = b_23 - _9; > a_11 = a_22 + __complex__ (1.0e+0, 0.0); > _8 = REALPART_EXPR ; > if (_8 < 1.0e+1) > goto ; > else > goto ; > > While we could avoid the crash on lowering the division by handling it last, > e.g. the addition has a loop of dependencies, so either we create a PHI > first, but then don't have definitions for its arguments, or we lower the + > first, but then we don't have definition for the PHI. We can't create all > the statements in a transaction together. > Do you suggest we set some temporary SSA_NAME_DEF_STMTs for the SSA_NAMEs we > create and we don't have a real definition yet (say GIMPLE_NOP)? No, that's somewhat gross and I like to avoid that. > Wouldn't some simplification attempt to optimize it as uninitialized? > Or stop using gimple_build* and revert to constructing it using builders > that don't actually fold anything or try to optimize anything, and when we > have everything fold all newly added statements? tree-complex.c doesn't use gimple_build but gimplify_build which simply uses fold_buildN. The issue is that the new enhanced predicates unconditionally walk SSA ... (even if the match-and-simplify machinery is instructed not to do that which it doesn't for GENERIC anyway)
[Bug target/67896] Inconsistent behaviour between C and C++ for types poly8x8_t and poly16x8_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67896 James Greenhalgh changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-01-11 CC||jgreenhalgh at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from James Greenhalgh --- Confirmed, and thanks for the detailed analysis and the candidate patch. I think I agree with what your saying, and the patch looks like the right thing to do to me (though I would refactor it to avoid the need for the bool, can we not just pull the SET_TYPE_STRUCTURAL_EQUALITY check in to the if statement in which you set is_vector?). I was a little concerned that now a poly8_t and an int8_t would compare equal, but I see that build_distinct_type_copy sets TYPE_CANONICAL correctly for the scalar poly types, so I don't have to worry. Please submit your patch to the mailing list along with the testcase here annotated with the relevant dejagnu directives.
[Bug target/65689] [5 Regression][AArch64] S constraint fails for inline asm at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65689 --- Comment #14 from James Greenhalgh --- Jakub, were you planning to backport this fix to 5.4, or would you like me to do it?
[Bug sanitizer/69147] [5 Regression] Several hundred asan failures with 5.3.1 on x86_64-apple-darwin15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69147 --- Comment #3 from Dominique d'Humieres --- Could you please elaborate? Is there a way to run manually a test with ASAN_OPTIONS=debug=1:verbosity=2? If yes, how (I am using tcsh)? If no, can I do it at the test love? If yes, how? If no, I guess I have to do a bootstrap with it, but how? TIA Dominique > Le 11 janv. 2016 à 10:23, chefmax at gcc dot gnu.org > a écrit : > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69147 > > --- Comment #2 from Maxim Ostapenko --- > Dominique, could you please run ASan tests with > ASAN_OPTIONS=debug=1:verbosity=2? This might be helpful for further debugging. > > -- > You are receiving this mail because: > You reported the bug.
[Bug tree-optimization/67682] Missed vectorization: (another) straight-line memcpy/memset not vectorized when equivalent loop is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67682 James Greenhalgh changed: What|Removed |Added Status|NEW |WAITING CC||jgreenhalgh at gcc dot gnu.org --- Comment #2 from James Greenhalgh --- This looks to be vectorized on current trunk, Alan is this now fixed?
[Bug tree-optimization/67682] Missed vectorization: (another) straight-line memcpy/memset not vectorized when equivalent loop is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67682 alalaw01 at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #3 from alalaw01 at gcc dot gnu.org --- Yes, r230330.
[Bug target/65689] [5 Regression][AArch64] S constraint fails for inline asm at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65689 --- Comment #15 from Jakub Jelinek --- (In reply to James Greenhalgh from comment #14) > Jakub, were you planning to backport this fix to 5.4, or would you like me > to do it? Forgot about this one. If you could backport it, it would be greatly appreciated.
[Bug tree-optimization/69174] [6 Regression] ICE (segfault) in operand_equal_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69174 --- Comment #7 from Richard Biener --- Ok, so we have an interleaving store of size 3 (and thus also the SLP group size is 3) but an interleaved load of size 4 (with gaps). Ideally we'd not treat that load as interleaved but we do. The size 3 SLP requires unrolling 8 times (8 * 3 -> 24 elements). The grouped load is strided and in this case ncopies = SLP_TREE_NUMBER_OF_VEC_STMTS (slp_node); if (slp_perm) dr_chain.create (ncopies); is off. See /* For SLP permutation support we need to load the whole group, not only the number of vector stmts the permutation result fits in. */ if (slp_perm) vec_num = (group_size * vf + nunits - 1) / nunits; else vec_num = SLP_TREE_NUMBER_OF_VEC_STMTS (slp_node);
[Bug rtl-optimization/68920] [6 Regression] Undesirable if-conversion for a rarely taken branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68920 --- Comment #7 from Ilya Enkovich --- Author: ienkovich Date: Mon Jan 11 12:07:31 2016 New Revision: 232220 URL: https://gcc.gnu.org/viewcvs?rev=232220&root=gcc&view=rev Log: gcc/ 2016-01-11 Yuri Rumyantsev PR rtl-optimization/68920 * config/i386/i386.c (ix86_option_override_internal): Restrict number of conditional moves for RTL if-conversion to 1 for TARGET_ONE_IF_CONV_INSN. * config/i386/i386.h (TARGET_ONE_IF_CONV_INSN): New macros. * config/i386/x86-tune.def (X86_TUNE_ONE_IF_CONV_INSN): New macros. * params.def (PARAM_MAX_RTL_IF_CONVERSION_INSNS) : Introduce new parameter to restirct number of conditional moves for RTL if-conversion. * doc/invoke.texi (max-rtl-if-conversion-insns): Document it. * ifcvt.c (bb_ok_for_noce_convert_multiple_sets): Limit number of conditionl moves. gcc/testsuite/ 2016-01-11 Yuri Rumyantsev PR rtl-optimization/68920 * gcc.dg/ifcvt-4.c: Add "--param max-rtl-if-conversion-insns=3" option for ix86 targets. * gcc.dg/ifcvt-5.c: New test. Added: trunk/gcc/testsuite/gcc.dg/ifcvt-5.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/i386.h trunk/gcc/config/i386/x86-tune.def trunk/gcc/doc/invoke.texi trunk/gcc/ifcvt.c trunk/gcc/params.def trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/ifcvt-4.c
[Bug tree-optimization/69069] missing phi argument with -ftree-parallelize-loops=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69069 --- Comment #2 from vries at gcc dot gnu.org --- Author: vries Date: Mon Jan 11 12:08:38 2016 New Revision: 232221 URL: https://gcc.gnu.org/viewcvs?rev=232221&root=gcc&view=rev Log: Add missing phi args in create_parallel_loop 2016-01-11 Tom de Vries PR tree-optimization/69069 * tree-parloops.c (create_parallel_loop): Add missing phi args. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-parloops.c
[Bug target/68841] [6 Regression] gcc.c-torture/execute/pr59358.c FAILs with custom compiler flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68841 --- Comment #9 from ktkachov at gcc dot gnu.org --- Author: ktkachov Date: Mon Jan 11 12:13:50 2016 New Revision: 232223 URL: https://gcc.gnu.org/viewcvs?rev=232223&root=gcc&view=rev Log: [RTL-ifcvt] PR rtl-optimization/68841: Make sure one basic block doesn't clobber CC reg usage of the other PR rtl-optimization/68841 * ifcvt.c (struct noce_if_info): Add orig_x field. (bbs_ok_for_cmove_arith): Add to_rename parameter. Don't record conflicts on to_rename if it's present. Allow memory destinations in sets. (noce_try_cmove_arith): Call bbs_ok_for_cmove_arith even on simple blocks, passing orig_x to the checks. (noce_process_if_block): Set if_info->orig_x appropriately. * gcc.dg/pr68841.c: New test. * gcc.c-torture/execute/pr68841.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr68841.c trunk/gcc/testsuite/gcc.dg/pr68841.c Modified: trunk/gcc/ChangeLog trunk/gcc/ifcvt.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/68841] [6 Regression] gcc.c-torture/execute/pr59358.c FAILs with custom compiler flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68841 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Component|target |rtl-optimization Resolution|--- |FIXED --- Comment #10 from ktkachov at gcc dot gnu.org --- Fixed on trunk.
[Bug tree-optimization/69069] missing phi argument with -ftree-parallelize-loops=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69069 vries at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from vries at gcc dot gnu.org --- Patch committed. Would be nice to reduce and commit a testcase, but I'm not familiar enough with ada to do that. Marking resolved-fixed.
[Bug tree-optimization/69213] [6 Regression] g++ ICE (segfault) at -O1 and above on x86_64-linux-gnu in "add_dependency"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69213 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||kyukhin at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Bet this started with r230755, or at least is caused by it. Most of the changes in that commit affect solely Cilk+ gimplification, which is fine, that should only happen during the initial gimplification and not happen later on. Seems Igor has posted a patch that fixes this: https://gcc.gnu.org/ml/gcc-patches/2015-12/msg00651.html , but that patch still looks wrong to me.
[Bug tree-optimization/69213] [6 Regression] g++ ICE (segfault) at -O1 and above on x86_64-linux-gnu in "add_dependency"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69213 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Created attachment 37301 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37301&action=edit gcc6-pr69213.patch Better untested fix.
[Bug ipa/66616] [4.9/5/6 regression] fipa-cp-clone ignores thunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66616 --- Comment #22 from Martin Jambor --- Author: jamborm Date: Mon Jan 11 12:44:53 2016 New Revision: 232226 URL: https://gcc.gnu.org/viewcvs?rev=232226&root=gcc&view=rev Log: [PR ipa/66616] Copy can_change_signature flag to artificial thunks 2016-01-11 Martin Jambor PR ipa/66616 * cgraphclones.c (duplicate_thunk_for_node): Copy can_change_signature flag. Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/cgraphclones.c
[Bug middle-end/69225] gcc uses double precision instead of single float with -m32 -std=c99 -msoft-float
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69225 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-01-11 CC||jsm28 at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- That's -fexcess-precision=standard behavior (but really tailored to x87 math thus hopefully not relevant for -msoft-float). Not sure where target specifics factor in here (and thus where we could handle the -msoft-float case). Joseph, did you think about this case?
[Bug tree-optimization/69214] [4.9/5/6 Regression] ICE (segfault) at -Os on x86_64-linux-gnu in "fail_abnormal_edge_coalesce"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69214 --- Comment #5 from Jakub Jelinek --- Created attachment 37302 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37302&action=edit gcc6-pr69214.patch Untested fix.
[Bug tree-optimization/69214] [4.9/5/6 Regression] ICE (segfault) at -Os on x86_64-linux-gnu in "fail_abnormal_edge_coalesce"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69214 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug target/69226] New: Wrong __SIZE_TYPE__/__PTRDIFF_TYPE__/__WCHAR_TYPE__ for IA MCU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69226
Bug ID: 69226
Summary: Wrong __SIZE_TYPE__/__PTRDIFF_TYPE__/__WCHAR_TYPE__
for IA MCU
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: vaalfreja at gmail dot com
Target Milestone: ---
[hjl@gnu-tools-1 gcc]$ cat /tmp/y.c
typedef __SIZE_TYPE__ size_t;
typedef __PTRDIFF_TYPE__ ptrdiff_t;
typedef __WCHAR_TYPE__ wchar_t;
void
foo (size_t a, ptrdiff_t b, wchar_t c)
{
__builtin_printf ("%d 0x%x, %ld\n", a, b, c);
}
[hjl@gnu-tools-1 gcc]$ ./xgcc -B./ -S -Wall /tmp/y.c
/tmp/y.c: In function ‘foo’:
/tmp/y.c:8:23: warning: format ‘%d’ expects argument of type ‘int’, but
argument 2 has type ‘size_t {aka long unsigned int}’ [-Wformat=]
__builtin_printf ("%d 0x%x, %ld\n", a, b, c);
^
/tmp/y.c:8:28: warning: format ‘%x’ expects argument of type ‘unsigned int’,
but argument 3 has type ‘ptrdiff_t {aka long int}’ [-Wformat=]
__builtin_printf ("%d 0x%x, %ld\n", a, b, c);
^
/tmp/y.c:8:33: warning: format ‘%ld’ expects argument of type ‘long int’, but
argument 4 has type ‘wchar_t {aka int}’ [-Wformat=]
__builtin_printf ("%d 0x%x, %ld\n", a, b, c);
^
[hjl@gnu-tools-1 gcc]$ gcc -S -Wall /tmp/y.c -m32
[hjl@gnu-tools-1 gcc]$
[Bug target/69053] [6 Regression] ICE in build_vector_from_val
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69053
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #6 from Richard Biener ---
Certainly bougs though. The following works for me - can you test that?
Index: gcc/tree-vect-loop.c
===
--- gcc/tree-vect-loop.c(revision 232213)
+++ gcc/tree-vect-loop.c(working copy)
@@ -4063,10 +4075,10 @@ get_initial_def_for_reduction (gimple *s
tree *elts;
int i;
bool nested_in_vect_loop = false;
- tree init_value;
REAL_VALUE_TYPE real_init_val = dconst0;
int int_init_val = 0;
gimple *def_stmt = NULL;
+ gimple_seq stmts = NULL;
gcc_assert (vectype);
nunits = TYPE_VECTOR_SUBPARTS (vectype);
@@ -4095,16 +4107,6 @@ get_initial_def_for_reduction (gimple *s
return vect_create_destination_var (init_val, vectype);
}
- if (TREE_CONSTANT (init_val))
-{
- if (SCALAR_FLOAT_TYPE_P (scalar_type))
-init_value = build_real (scalar_type, TREE_REAL_CST (init_val));
- else
-init_value = build_int_cst (scalar_type, TREE_INT_CST_LOW (init_val));
-}
- else
-init_value = init_val;
-
switch (code)
{
case WIDEN_SUM_EXPR:
@@ -4181,7 +4183,10 @@ get_initial_def_for_reduction (gimple *s
break;
}
}
- init_def = build_vector_from_val (vectype, init_value);
+ init_val = gimple_convert (&stmts, TREE_TYPE (vectype), init_val);
+ if (! gimple_seq_empty_p (stmts))
+ gsi_insert_seq_on_edge_immediate (loop_preheader_edge (loop), stmts);
+ init_def = build_vector_from_val (vectype, init_val);
break;
default:
[Bug c++/68979] [6 Regression] error: left operand of shift expression ‘(-1 << 4)’ is negative
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68979 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #4 from Marek Polacek --- Ok, I'll try to soften that a bit.
[Bug debug/69077] [6 Regression] omnetpp ICEs with -flto -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69077 --- Comment #13 from Richard Biener --- It's not referenced from the t2.cc cgraph at all, just from the WeightedStdDev constructor, taking its address via the vtable setting. So the possibly-inlined version is dropped on the floor and we keep the non-possibly-inlined variant. Which means this flag is quite bogus in the face of devirtualization (we'd basically need to set it everywhere?).
[Bug target/69226] Wrong __SIZE_TYPE__/__PTRDIFF_TYPE__/__WCHAR_TYPE__ for IA MCU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69226 H.J. Lu changed: What|Removed |Added Target Milestone|--- |6.0 --- Comment #1 from H.J. Lu --- Also int32_t and uint32_t should be int, not long int.
[Bug target/69226] Wrong __SIZE_TYPE__/__PTRDIFF_TYPE__/__WCHAR_TYPE__ for IA MCU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69226 --- Comment #2 from H.J. Lu --- Created attachment 37303 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37303&action=edit A patch
[Bug middle-end/69225] gcc uses double precision instead of single float with -m32 -std=c99 -msoft-float
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69225 Kirill Yukhin changed: What|Removed |Added CC||kyukhin at gcc dot gnu.org --- Comment #3 from Kirill Yukhin --- BTW, for -std=gnu99 we have EXCESS_PRECISION_FAST engaged. This differs from -std=c99 If this correct behavior? I see no mentions of this difference w/ c99 in documentation. It only states that gnu99 is "C99 with GNU extensions" Maybe fix docs? Or make -std=gnu99 use EXCESS_PRECISION_STANDARD?
[Bug target/69227] New: FAIL: gcc.dg/torture/builtin-integral-1.c -O1 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69227 Bug ID: 69227 Summary: FAIL: gcc.dg/torture/builtin-integral-1.c -O1 (test for excess errors) Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: andre.simoesdiasvieira at arm dot com Target Milestone: --- Commit r232191 causes the following fail on arm-none-eabi target: FAIL: gcc.dg/torture/builtin-integral-1.c -O1 (test for excess errors) As it no longer folds away __builtin_ceill for __builtin_fabsf. This is because Gerald's patch checks for 'targetm.libc_has_function (function_c99_misc)' for a transformation used here and, for arm-none-eabi, TARGET_LIBC_HAS_FUNCTION is defined as 'no_c99_libc_has_function', which always returns false. The question now is whether we should support function_c99_misc with 'arm-none-eabi', which comes with newlib. I believe newlib does not claim to fully support C99.
[Bug target/69227] FAIL: gcc.dg/torture/builtin-integral-1.c -O1 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69227 --- Comment #1 from ktkachov at gcc dot gnu.org --- Relevant thread on gcc-patches: https://gcc.gnu.org/ml/gcc-patches/2016-01/msg00586.html
[Bug middle-end/69225] gcc uses double precision instead of single float with -m32 -std=c99 -msoft-float
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69225 --- Comment #4 from H.J. Lu --- This patch: https://gcc.gnu.org/git/?p=gcc.git;a=patch;h=a16c748c075b14ce65ae1f12d8862cef0af87842 fixes it. I will submit a patch with a testcase.
[Bug target/69226] Wrong __SIZE_TYPE__/__PTRDIFF_TYPE__/__WCHAR_TYPE__ for IA MCU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69226
--- Comment #3 from Yulia Koval ---
We can use this patch and fix both this bug and pr68456 for iamcu:
diff --git a/gcc/config/i386/iamcu.h b/gcc/config/i386/iamcu.h
index f143bf9..5ca5c5e 100644
--- a/gcc/config/i386/iamcu.h
+++ b/gcc/config/i386/iamcu.h
@@ -55,6 +55,9 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If
not, see
#undef LINK_GCC_C_SEQUENCE_SPEC
#define LINK_GCC_C_SEQUENCE_SPEC "%{!miamcu-fp-libgcc:-lsoftfp %G %L %G}
%{miamcu-fp-libgcc:%G %L %G}"
+#undef STDINT_LONG32
+#define STDINT_LONG32 0
+
/* A C statement (sans semicolon) to output to the stdio stream
FILE the assembler definition of uninitialized global DECL named
NAME whose size is SIZE bytes and alignment is ALIGN bytes.
[Bug target/64821] [AArch64] Improve target folding for vsqrt_f64 intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64821 ktkachov at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |7.0 --- Comment #2 from ktkachov at gcc dot gnu.org --- This fell through the cracks for GCC 6. Setting milestone for GCC 7
[Bug bootstrap/68563] LTO bootstrap fails on aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68563 James Greenhalgh changed: What|Removed |Added Status|NEW |RESOLVED CC||jgreenhalgh at gcc dot gnu.org Resolution|--- |INVALID --- Comment #4 from James Greenhalgh --- Resolving as invalid, as the bootstrap works with --disable-werror
[Bug target/69226] Wrong __SIZE_TYPE__/__PTRDIFF_TYPE__/__WCHAR_TYPE__ for IA MCU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69226 H.J. Lu changed: What|Removed |Added Attachment #37303|0 |1 is obsolete|| --- Comment #4 from H.J. Lu --- Created attachment 37304 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37304&action=edit An updated patch
[Bug target/64782] -mcpu=native should be supported on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64782 Bug 64782 depends on bug 64784, which changed state. Bug 64784 Summary: -march=native should be supported https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64784 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug target/64784] -march=native should be supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64784 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||6.0 Host||aarch64 Resolution|--- |FIXED Target Milestone|--- |6.0 Severity|normal |enhancement --- Comment #2 from ktkachov at gcc dot gnu.org --- Implemented for GCC 6.
[Bug target/69226] Wrong __SIZE_TYPE__/__PTRDIFF_TYPE__/__WCHAR_TYPE__ for IA MCU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69226 --- Comment #5 from H.J. Lu --- Created attachment 37305 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37305&action=edit An updated patch Please try this.
[Bug other/68813] [openacc] lto1: internal compiler error: in input_varpool_node, at lto-cgraph.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68813 cesar at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from cesar at gcc dot gnu.org --- This has been fixed in r232121. I also ended up applying that lto patch to gomp4 because it makes user errors involving undeclared variables and routines more user friendly. I.e., instead of crashing it just reports an error message.
[Bug rtl-optimization/69032] [5/6 Regression] ICE: in cfg_preds_1, at sel-sched-ir.c:4809 with -fsched-pressure -fsel-sched-pipelining -fselective-scheduling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69032 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-01-11 CC||amonakov at gcc dot gnu.org, ||jakub at gcc dot gnu.org, ||segher at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- I need also -mcpu=G4 to reproduce. Started with r218595.
[Bug target/69227] FAIL: gcc.dg/torture/builtin-integral-1.c -O1 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69227 --- Comment #2 from Andre Vieira --- I have decided to email the newlib mailinglist to figure out which function classes we should and should not support for 'arm-none-eabi'. See https://sourceware.org/ml/newlib/2016/msg9.html
[Bug sanitizer/69147] [5 Regression] Several hundred asan failures with 5.3.1 on x86_64-apple-darwin15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69147
--- Comment #4 from Maxim Ostapenko ---
If you want use make check stuff, you could try this:
max:~/build/master> setenv ASAN_OPTIONS verbosity=2:debug=1
max:~/build/master> make check RUNTESTFLAGS="asan.exp=memcmp-1.c"
or add such a line to, say, memcmp-1.c:
/* { dg-set-target-env-var ASAN_OPTIONS "debug=1:verbosity=2" } */
> Could you please elaborate?
>
> Is there a way to run manually a test with ASAN_OPTIONS=debug=1:verbosity=2?
> If yes, how (I am using tcsh)?
> If no, can I do it at the test love? If yes, how? If no, I guess I have to
> do a bootstrap with it, but how?
>
> TIA
>
> Dominique
>
> > Le 11 janv. 2016 à 10:23, chefmax at gcc dot gnu.org
> > a écrit :
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69147
> >
> > --- Comment #2 from Maxim Ostapenko ---
> > Dominique, could you please run ASan tests with
> > ASAN_OPTIONS=debug=1:verbosity=2? This might be helpful for further
> > debugging.
> >
> > --
> > You are receiving this mail because:
> > You reported the bug.
[Bug target/59810] [AArch64] LDn/STn implementations are not ABI-conformant for bigendian.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59810 James Greenhalgh changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug c++/66339] g++ 5.1.0 Generates memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66339 lh_mouse changed: What|Removed |Added CC||lh_mouse at 126 dot com --- Comment #2 from lh_mouse --- (In reply to Andreas Schwab from comment #1) > This is not a leak. The memory is still reachable and there is no point in > freeing it if the program is exiting anyway. It is definitely a leak. 'Being reachable' has nothing to do with whether it is a leak or not. If you malloc() something but never free() it, it leaks essentially. Being reachable only means the leak detector (here, valgrind) is unable to tell whether it is a false leak that would eventually be freed after the detector itself terminates.
[Bug debug/69077] [6 Regression] omnetpp ICEs with -flto -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69077
--- Comment #14 from Jan Hubicka ---
I suppose the problem here is that lto-symtab is not merging symtab nodes but
only the FUNCTION_DECLs so the flag is not merged. Something like this may
help.
Index: lto-symtab.c
===
--- lto-symtab.c(revision 232227)
+++ lto-symtab.c(working copy)
@@ -997,6 +1005,8 @@ lto_symtab_prevailing_virtual_decl (tree
n = n->next_sharing_asm_name;
if (n)
{
+ DECL_POSSIBLY_INLINED (n->decl) |= DECL_POSSIBLY_INLINED (decl);
+ DECL_POSSIBLY_INLINED (decl) |= DECL_POSSIBLY_INLINED (n->decl);
lto_symtab_prevail_decl (n->decl, decl);
decl = n->decl;
}
[Bug c++/66339] g++ 5.1.0 Generates memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66339 --- Comment #3 from Jonathan Wakely --- OK, whatever weird definition of leak you are using is irrelevant. The memory is still in use until the program exits, and there is still a pointer to it. It is not lost, or forgotten about, it is in use by the run-time.
[Bug rtl-optimization/68796] Make use of and-immediate+compare instructions more robust
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68796 --- Comment #3 from ktkachov at gcc dot gnu.org --- Author: ktkachov Date: Mon Jan 11 14:44:22 2016 New Revision: 232228 URL: https://gcc.gnu.org/viewcvs?rev=232228&root=gcc&view=rev Log: [AArch64] PR rtl-optimization/68796: Add patterns for QImode and HImode comparison with zero PR rtl-optimization/68796 * config/aarch64/aarch64.md (*and_compare0): New pattern. * config/aarch64/aarch64.c (aarch64_select_cc_mode): Handle HImode and QImode comparisons against zero with CC_NZmode. * config/aarch64/iterators.md (short_mask): New mode_attr. * gcc.target/aarch64/tst_5.c: New test. * gcc.target/aarch64/tst_6.c: Likewise. Added: trunk/gcc/testsuite/gcc.target/aarch64/tst_5.c trunk/gcc/testsuite/gcc.target/aarch64/tst_6.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/aarch64/aarch64.c trunk/gcc/config/aarch64/aarch64.md trunk/gcc/config/aarch64/iterators.md trunk/gcc/testsuite/ChangeLog
[Bug c++/69211] [6 Regression] g++ ICE on x86_64-linux-gnu (verify_gimple failed)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69211 --- Comment #3 from Jakub Jelinek --- I guess the bug is that lots of code in fold-const.c is totally unprepared to see NOP_EXPR wrapping up INTEGER_CST (or other constants), it assumes that if argN is say INTEGER_CST, then argN == opN and thus does not fold. Rather than changing everything in fold-const.c, I think it is better to make sure cp_fold folds those away early enough. Let me test a patch.
