[Bug c++/67081] FAIL: g++.dg/cpp0x/nsdmi-template14.C (test for errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67081 İsmail Dönmez changed: What|Removed |Added CC||ismail at i10z dot com --- Comment #1 from İsmail Dönmez --- Also see this on Linux x86-64.
[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837 --- Comment #31 from chrbr at gcc dot gnu.org --- Author: chrbr Date: Mon Nov 16 08:46:42 2015 New Revision: 230404 URL: https://gcc.gnu.org/viewcvs?rev=230404&root=gcc&view=rev Log: 2015-11-16 Christian Bruel PR target/65837 * config/arm/arm.c (arm_fpu_desc): Remove. (all_fpus): Make global. (arm_option_override): Use FPU TARGET accessors. (arm_declare_function_name): Likewise. * config/arm/arm.h (TARGET_VFP, TARGET_VFPD32, TARGET_VFP5) (TARGET_VFP_SINGLE, TARGET_VFP_DOUBLE, TARGET_NEON_FP16) (TARGET_FP16, TARGET_FMA, TARGET_FPU_ARMV8, TARGET_CRYPTO) (TARGET_NEON): Likewise. (all_fpus): Declare extern. (TARGET_FPU_NAME, TARGET_FPU_MODEL, TARGET_FPU_REV) (TARGET_FPU_REGS, TARGET_FPU_FEATURES): Define all_fpus accessors. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c trunk/gcc/config/arm/arm.h
[Bug middle-end/68117] [6 Regression] error: invalid PHI argument <<< Unknown tree: >>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68117 --- Comment #26 from rguenther at suse dot de --- On Sun, 15 Nov 2015, trippels at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68117 > > --- Comment #25 from Markus Trippelsdorf --- > I think the issue is caused by Richi's r229405. > > In this patch the following two lines were accidentally removed from > tree-ssa.c (delete_tree_ssa): > > - /* We no longer need the edge variable maps. */ > - redirect_edge_var_map_destroy (); > > Restoring them fixes the bug for me: Hmm, they were removed "intentionally" (the function destroys a global map which should never be non-NULL after a patch finished). Of course I failed to add an assert for that ;) > diff --git a/gcc/tree-ssa.c b/gcc/tree-ssa.c > index 84a4d5b..02fca4c 100644 > --- a/gcc/tree-ssa.c > +++ b/gcc/tree-ssa.c > @@ -1126,6 +1126,9 @@ delete_tree_ssa (struct function *fn) >fn->gimple_df->decls_to_pointers = NULL; >fn->gimple_df->modified_noreturn_calls = NULL; >fn->gimple_df = NULL; > + > + /* We no longer need the edge variable maps. */ > + redirect_edge_var_map_destroy (); > } > > /* Return true if EXPR is a useless type conversion, otherwise return > >
[Bug c++/60336] empty struct value is passed differently in C and C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60336 --- Comment #39 from Andrew Pinski --- You should also update gimplify.c's zero_sized_type to be the same as your empty_record_p.
[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837 --- Comment #32 from chrbr at gcc dot gnu.org --- Author: chrbr Date: Mon Nov 16 09:00:09 2015 New Revision: 230406 URL: https://gcc.gnu.org/viewcvs?rev=230406&root=gcc&view=rev Log: 2015-11-16 Christian Bruel PR target/65837 * config/arm/arm-protos.h (arm_init_neon_builtins): Declare. * config/arm/arm.c (arm_valid_target_attribute_tree): Call arm_init_neon_builtins. * config/arm/arm-builtins.c (arm_init_neon_builtins): Split into... (arm_init_neon_builtins_internal) (arm_init_crypto_builtins_internal): Test and set neon_set_p, neon_crypto_set_p. (neon_set_p, neon_crypto_set_p): New static booleans. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm-builtins.c trunk/gcc/config/arm/arm-protos.h trunk/gcc/config/arm/arm.c
[Bug target/68363] [4.9/5/6 Regression] ICE: in recog_memoized, at recog.h:167 with RTL checking with -mfix-cortex-a53-835769 @ aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68363 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-11-16 CC||ktkachov at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |ktkachov at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from ktkachov at gcc dot gnu.org --- Confirmed. Apparently JUMP_TABLE_DATA can be an rtx_insn*, which cannot be recognised. Fix should be simple enough
[Bug middle-end/68117] [6 Regression] error: invalid PHI argument <<< Unknown tree: >>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68117
--- Comment #27 from Richard Biener ---
Sth like
Index: gcc/tree-ssa.c
===
--- gcc/tree-ssa.c (revision 230404)
+++ gcc/tree-ssa.c (working copy)
@@ -125,6 +125,14 @@ redirect_edge_var_map_destroy (void)
edge_var_maps = NULL;
}
+/* Verify the edge_var_map is empty. */
+
+void
+check_redirect_edge_var_map_empty (void)
+{
+ gcc_assert (!edge_var_maps || edge_var_maps->elements () == 0);
+}
+
/* Remove the corresponding arguments from the PHI nodes in E's
destination block and redirect it to DEST. Return redirected edge.
Index: gcc/tree-ssa.h
===
--- gcc/tree-ssa.h (revision 230404)
+++ gcc/tree-ssa.h (working copy)
@@ -36,6 +36,7 @@ extern void redirect_edge_var_map_clear
extern void redirect_edge_var_map_dup (edge, edge);
extern vec *redirect_edge_var_map_vector (edge);
extern void redirect_edge_var_map_destroy (void);
+extern void check_redirect_edge_var_map_empty (void);
extern edge ssa_redirect_edge (edge, basic_block);
extern void flush_pending_stmts (edge);
extern void gimple_replace_ssa_lhs (gimple *, tree);
Index: gcc/passes.c
===
--- gcc/passes.c(revision 230404)
+++ gcc/passes.c(working copy)
@@ -2211,7 +2214,10 @@ execute_one_ipa_transform_pass (struct c
/* Signal this is a suitable GC collection point. */
if (!(todo_after & TODO_do_not_ggc_collect))
-ggc_collect ();
+{
+ check_redirect_edge_var_map_empty ();
+ ggc_collect ();
+}
}
/* For the current function, execute all ipa transforms. */
@@ -2380,7 +2386,10 @@ execute_one_pass (opt_pass *pass)
/* Signal this is a suitable GC collection point. */
if (!((todo_after | pass->todo_flags_finish) & TODO_do_not_ggc_collect))
-ggc_collect ();
+{
+ check_redirect_edge_var_map_empty ();
+ ggc_collect ();
+}
return true;
}
after all edge_var_maps is _not_ GTY marked.
[Bug middle-end/68117] [6 Regression] error: invalid PHI argument <<< Unknown tree: >>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68117
--- Comment #28 from Joost VandeVondele
---
(In reply to Richard Biener from comment #27)
> Sth like
>
> Index: gcc/tree-ssa.c
> ===
> --- gcc/tree-ssa.c (revision 230404)
> +++ gcc/tree-ssa.c (working copy)
> @@ -125,6 +125,14 @@ redirect_edge_var_map_destroy (void)
>edge_var_maps = NULL;
> }
>
> +/* Verify the edge_var_map is empty. */
> +
> +void
> +check_redirect_edge_var_map_empty (void)
> +{
> + gcc_assert (!edge_var_maps || edge_var_maps->elements () == 0);
> +}
> +
>
> /* Remove the corresponding arguments from the PHI nodes in E's
> destination block and redirect it to DEST. Return redirected edge.
> Index: gcc/tree-ssa.h
> ===
> --- gcc/tree-ssa.h (revision 230404)
> +++ gcc/tree-ssa.h (working copy)
> @@ -36,6 +36,7 @@ extern void redirect_edge_var_map_clear
> extern void redirect_edge_var_map_dup (edge, edge);
> extern vec *redirect_edge_var_map_vector (edge);
> extern void redirect_edge_var_map_destroy (void);
> +extern void check_redirect_edge_var_map_empty (void);
> extern edge ssa_redirect_edge (edge, basic_block);
> extern void flush_pending_stmts (edge);
> extern void gimple_replace_ssa_lhs (gimple *, tree);
> Index: gcc/passes.c
> ===
> --- gcc/passes.c(revision 230404)
> +++ gcc/passes.c(working copy)
> @@ -2211,7 +2214,10 @@ execute_one_ipa_transform_pass (struct c
>
>/* Signal this is a suitable GC collection point. */
>if (!(todo_after & TODO_do_not_ggc_collect))
> -ggc_collect ();
> +{
> + check_redirect_edge_var_map_empty ();
> + ggc_collect ();
> +}
> }
>
> /* For the current function, execute all ipa transforms. */
> @@ -2380,7 +2386,10 @@ execute_one_pass (opt_pass *pass)
>
>/* Signal this is a suitable GC collection point. */
>if (!((todo_after | pass->todo_flags_finish) & TODO_do_not_ggc_collect))
> -ggc_collect ();
> +{
> + check_redirect_edge_var_map_empty ();
> + ggc_collect ();
> +}
>
>return true;
> }
>
> after all edge_var_maps is _not_ GTY marked.
triggers plenty of ICEs in my case:
/data/vjoost/clean/cp2k/cp2k/src/grid/fast.F:59:0:
END SUBROUTINE rankup
internal compiler error: in check_redirect_edge_var_map_empty, at
tree-ssa.c:133
[Bug middle-end/68117] [6 Regression] error: invalid PHI argument <<< Unknown tree: >>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68117 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #29 from Richard Biener --- Created attachment 36725 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36725&action=edit patch Ok, that trips all over the place (a good sign that things are quite broken). So instead of verifying we should maybe just empty the map at these points... Like the attached which I am testing.
[Bug middle-end/66214] [6 Regression] ICE verify_type failed with -O0 -g via gen_type_die_with_usage's dwarf2out.c:20250
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66214 --- Comment #24 from Guille --- Yes, just checked that. 'gcc -g file_that_include_ssl_h.cpp' builds fine, but 'g++ -g file_that_include_ssl_h.cpp' ICEs. (In reply to Magnus Fromreide from comment #23) > One more question - you are using the command > > g++ -g file_that_include_ssl_h.cpp > > right? Building it as C works for me as well.
[Bug target/68369] Unnecessary copying esp to ebp with regparm={1,2,3} on x86 at -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68369 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Target||i?86-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2015-11-16 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- I believe on i?86 with -Os we have the frame pointer enabled by default because usually that gives smaller code (for argument stack slot accesses). Try -Os -fomit-frame-pointer. This is a missed-optimization (when no frame is actually needed).
[Bug c++/68368] [6 regression] ICE tree check: expected integer_cst, have nop_expr in decompose, at tree.h:5123
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68368 Richard Biener changed: What|Removed |Added Target Milestone|--- |6.0
[Bug middle-end/68366] [6 Regression] sdbout.c build error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68366 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #2 from Richard Biener --- Fixed.
[Bug tree-optimization/68367] [6 regression] ICE in vectorizable_load, at tree-vect-stmts.c:6711
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68367 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-11-16 CC||rguenth at gcc dot gnu.org Component|ipa |tree-optimization Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |6.0 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Ok, so I assume this is after the fix for PR68306.
[Bug target/68363] [4.9/5/6 Regression] ICE: in recog_memoized, at recog.h:167 with RTL checking with -mfix-cortex-a53-835769 @ aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68363 Richard Biener changed: What|Removed |Added Target Milestone|--- |4.9.4
[Bug c++/68362] [6 Regression] ICE: tree check: expected integer_cst, have nop_expr in get_val, at tree.h:5157
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68362 Richard Biener changed: What|Removed |Added Target Milestone|--- |6.0
[Bug rtl-optimization/68328] [4.9/5/6 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68328 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-11-16 CC||jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from Jakub Jelinek --- I've managed to reproduce this if I link with the current trunk, if I link with my system gcc (5.1), it works fine. When linking with current trunk's gcc, I've bisected this to r206418.
[Bug c++/68362] [6 Regression] ICE: tree check: expected integer_cst, have nop_expr in get_val, at tree.h:5157
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68362 Richard Biener changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #3 from Richard Biener --- *** Bug 68368 has been marked as a duplicate of this bug. ***
[Bug c++/68368] [6 regression] ICE tree check: expected integer_cst, have nop_expr in decompose, at tree.h:5123
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68368 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Richard Biener --- dup *** This bug has been marked as a duplicate of bug 68362 ***
[Bug tree-optimization/68367] [6 regression] ICE in vectorizable_load, at tree-vect-stmts.c:6711
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68367 --- Comment #2 from Christophe Lyon --- (In reply to Richard Biener from comment #1) > Ok, so I assume this is after the fix for PR68306. Indeed: that was fixed at r230310, at which point my build still succeded. It started to fail at r230311.
[Bug middle-end/68360] GCC bitfield processing code is very inefficient
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68360 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2015-11-16 CC||rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- Confirmed.
[Bug c++/68362] [6 Regression] ICE: tree check: expected integer_cst, have nop_expr in get_val, at tree.h:5157
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68362 Richard Biener changed: What|Removed |Added CC||adam at os dot inf.tu-dresden.de --- Comment #4 from Richard Biener --- *** Bug 68359 has been marked as a duplicate of this bug. ***
[Bug c++/68359] ice: tree check: expected integer_cst, have nop_expr in get_len
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68359 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Richard Biener --- Dup. *** This bug has been marked as a duplicate of bug 68362 ***
[Bug c++/68357] [6 Regression] FAIL: g++.dg/other/darwin-cfstring1.C -std=* (internal compiler error) on x86_64-apple-darwin1(0|4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68357 Richard Biener changed: What|Removed |Added Target Milestone|--- |6.0
[Bug tree-optimization/68356] FAIL: gcc.dg/torture/pr68264.c -O* execution test on x86_64-apple-darwin1(0|4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68356 --- Comment #1 from Richard Biener --- It looks like a math library issue. The test has workarounds for glibc: /* Disabled due to glibc PR 6792, fixed in Apr 2015. */ if (0) TEST (log1p (d), LARGE_NEG_EDOM);
[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837 --- Comment #33 from chrbr at gcc dot gnu.org --- Author: chrbr Date: Mon Nov 16 10:21:09 2015 New Revision: 230408 URL: https://gcc.gnu.org/viewcvs?rev=230408&root=gcc&view=rev Log: 2015-11-16 Christian Bruel PR target/65837 * config/arm/arm-c.c (arm_cpu_builtins): Set or reset __ARM_FEATURE_CRYPTO, __VFP_FP__, __ARM_NEON__ (arm_pragma_target_parse): Change check for arm_cpu_builtins. undefine __ARM_FP. * config/arm/arm.c (arm_can_inline_p): Check FPUs. (arm_valid_target_attribute_rec): Handle -mfpu attribute target. * doc/invoke.texi (-mfpu=): Mention attribute and pragma. * doc/extend.texi (-mfpu=): Describe attribute. 2015-11-16 Christian Bruel PR target/65837 gcc.target/arm/lto/pr65837_0.c gcc.target/arm/attr-neon2.c gcc.target/arm/attr-neon.c gcc.target/arm/attr-neon-builtin-fail.c gcc.target/arm/attr-crypto.c Added: trunk/gcc/testsuite/gcc.target/arm/attr-crypto.c trunk/gcc/testsuite/gcc.target/arm/attr-neon-builtin-fail.c trunk/gcc/testsuite/gcc.target/arm/attr-neon.c trunk/gcc/testsuite/gcc.target/arm/attr-neon2.c trunk/gcc/testsuite/gcc.target/arm/lto/pr65837_0.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm-c.c trunk/gcc/config/arm/arm.c trunk/gcc/doc/extend.texi trunk/gcc/doc/invoke.texi trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/68335] [6 Regression][GRAPHITE] ICE: tree check: expected ssa_name, have real_cst in add_phi_arg_for_new_expr, at sese.c:1373
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68335 Richard Biener changed: What|Removed |Added Component|middle-end |tree-optimization Target Milestone|--- |6.0 Summary|ICE: tree check: expected |[6 Regression][GRAPHITE] |ssa_name, have real_cst in |ICE: tree check: expected |add_phi_arg_for_new_expr, |ssa_name, have real_cst in |at sese.c:1373 |add_phi_arg_for_new_expr, ||at sese.c:1373
[Bug rtl-optimization/68321] [5/6 Regression] wrong code at -O3 on x86_64-linux-gnu (in 64-bit mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68321 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #5 from Richard Biener --- Sounds like sth latent to me. Still will have a look.
[Bug tree-optimization/65752] Too strong optimizations int -> pointer casts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
Jeehoon Kang changed:
What|Removed |Added
CC||jeehoon.kang at sf dot
snu.ac.kr
--- Comment #43 from Jeehoon Kang ---
(In reply to Alexander Cherepanov from comment #38)
> The evident solution is to not apply this optimization when provenance info
> of the two variables differs. I guess for most integers it will be the same.
IMO tracking provenance info is not a good idea, since it is really
complicated. First, since integers and pointers can be casted to each other,
not only pointers but also integers should carry provenance information.
Second, tracking provenance info may work for simple examples, but it is even
hard to define the provenance info itself for complex expressions. For e.g.,
what is the provenance of "e1-e2"? "2*e"? "e1 XOR e2"? "e1 * e2"? (even
given the provenance info for integer expressions "e*")
I would rather prefer marking pointers casted to integers as *escaped*, and
forgetting about the provenance at all. Here are several reasons why this
works well:
- Standard optimizations are supported. Say we want to support the following
constant propagation example:
char f() {
char a = '0';
g(); // unknown function; may guess the address of "a" and
// try to access it (but it is always unsuccessful)
return a; // -> return '0'
}
Since the address of "a" is not casted to integers, "a" is private to the
function "f" (i.e., not escaped from "f"), and "g" cannot access "a". So we
know "a = 0" at the return.
- semantics is simple. No need to track the provenance info for variables.
Once a pointer is casted to integers, it is just integers without any tracked
information.
As a result, the standard integer optimizations of our interest, as the
following, are fully supported:
if (x != y) x = y; -> x = y;
- Performance degradation due to "casted pointers as escaped" is insignificant.
Morally, if a pointer is casted to an integer, the address is regarded as
"global": having the integer value of the pointer means you can access the
pointer. So there will be not much optimization opportunity (or intent) for
those pointers casted to integers.
Of course, this argument should be validated by some experiment; yet I am
quite convinced it is the case that the performance degradation is
insignificant.
I would like to ask how you think about this suggestion. Note that my argument
here is based on my paper on this issue, where you can find the formal memory
model we proposed, proofs that optimization examples are correct, and reasoning
principle for proving optimizations (see the paper and the slide):
A Formal C Memory Model Supporting Integer-Pointer Casts.
Jeehoon Kang, Chung-Kil Hur, William Mansky, Dmitri Garbuzov, Steve
Zdancewic, Viktor Vafeiadis.
PLDI 2015.
http://sf.snu.ac.kr/intptrcast/
[Bug tree-optimization/68341] [6 Regression] FAIL: gcc.dg/graphite/interchange-{1,11,13}.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68341
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |6.0
Summary|FAIL: |[6 Regression] FAIL:
|gcc.dg/graphite/interchange |gcc.dg/graphite/interchange
|-{1,11,13}.c (internal |-{1,11,13}.c (internal
|compiler error) |compiler error)
[Bug c++/68348] [6 regression] ICE: segfault in cxx_eval_constant_expression at cp/constexpr.c:3172
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68348 Richard Biener changed: What|Removed |Added Target Milestone|--- |6.0
[Bug rtl-optimization/68349] [6 regression] ice in decompose_normal_address with -O2 at rtlanal.c:6086
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68349 Richard Biener changed: What|Removed |Added Target Milestone|--- |6.0
[Bug c/68344] No warning for old-style function declarations.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68344 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |WORKSFORME --- Comment #3 from Marek Polacek --- Resolved.
[Bug fortran/68237] ICE on invalid with submodules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68237 Paul Thomas changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #9 from Paul Thomas --- I'll take a look at Steve's proposed patch tonight. In the meantime, I have taken the PR. Cheers Paul
[Bug fortran/66762] ICE when compiling gfortran.dg/submodule_[16].f90 with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66762 Paul Thomas changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #9 from Paul Thomas --- I had better take this, since I have responsibility for submodules :-) I still need help in diagnosing the problem, however. Cheers Paul
[Bug libstdc++/66145] [5/6 Regression] std::ios_base::failure objects thrown from libstdc++.so use old ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66145 Daniel Seither changed: What|Removed |Added CC||tiwoc at arcor dot de --- Comment #6 from Daniel Seither --- Is there any simple workaround for this bug short of checking f.fail() after each operation?
[Bug middle-end/68117] [6 Regression] error: invalid PHI argument <<< Unknown tree: >>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68117
--- Comment #30 from Richard Biener ---
Ok, so we already do
void
remove_edge (edge e)
{
if (current_loops != NULL)
rescan_loop_exit (e, false, true);
/* This is probably not needed, but it doesn't hurt. */
/* FIXME: This should be called via a remove_edge hook. */
if (current_ir_type () == IR_GIMPLE)
redirect_edge_var_map_clear (e);
but we fail to clear the edge map data during RTL expansion. So the simpler
patch
Index: gcc/cfgexpand.c
===
--- gcc/cfgexpand.c (revision 230404)
+++ gcc/cfgexpand.c (working copy)
@@ -6275,6 +6278,9 @@ pass_expand::execute (function *fun)
expand_phi_nodes (&SA);
+ /* Release any stale SSA redirection data. */
+ redirect_edge_var_map_destroy ();
+
/* Register rtl specific functions for cfg. */
rtl_register_cfg_hooks ();
might be enough.
[Bug c/68337] [MPX] memcpy() for arrays with function pointers results in huge resource usage and binaries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68337 Ilya Enkovich changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-11-16 CC||ienkovich at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |ienkovich at gcc dot gnu.org Ever confirmed|0 |1
[Bug rtl-optimization/68328] [4.9/5/6 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68328
Jakub Jelinek changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek ---
So, we have there:
(insn 63 8 69 3 (set (reg:QI 0 ax [106])
(mem/c:QI (symbol_ref:DI ("d") [flags 0x2] ) [2 d+0 S1 A32])) pr68328.c:14 92 {*movqi_internal}
(expr_list:REG_EQUIV (mem/c:QI (symbol_ref:DI ("d") [flags 0x2] ) [2 d+0 S1 A32])
(nil)))
(insn 69 63 15 3 (set (reg:SI 3 bx [orig:83 h ] [83])
(if_then_else:SI (ne (reg:CCZ 17 flags)
(const_int 0 [0]))
(reg:SI 0 ax [106])
(reg:SI 3 bx [orig:83 h ] [83]))) pr68328.c:14 952 {*movsicc_noc}
(nil))
(insn 15 69 4 3 (set (reg:SI 1 dx [orig:99 D.1789 ] [99])
(sign_extend:SI (reg/v:QI 3 bx [orig:83 h ] [83]))) pr68328.c:15 147
{extendqisi2}
(nil))
...
(insn 65 18 66 4 (set (reg:SI 0 ax [orig:100 D.1790 ] [100])
(plus:SI (reg:SI 3 bx [orig:83 h ] [83])
(const_int -120 [0xff88]))) 258 {*leasi}
(nil))
in *.split2, those are all spots where bx is mentioned. As can be seen from
the source, h is only conditionally defined (but the condition is actually
true), and may also get its value from previous loop iteration (although that
is not the case here). The ax from insn 65 (which is the only other spot where
bx is used) is then used only as QImode, so the bits outside of QImode don't
matter.
But REE in r206418 and later transforms this into:
(insn 63 8 70 3 (set (reg:SI 1 dx)
(sign_extend:SI (mem/c:QI (symbol_ref:DI ("d") [flags 0x2] ) [2 d+0 S1 A32]))) pr68328.c:14 147 {extendqisi2}
(expr_list:REG_EQUIV (mem/c:QI (symbol_ref:DI ("d") [flags 0x2] ) [2 d+0 S1 A32])
(nil)))
(insn 70 63 69 3 (set (reg:SI 3 bx)
(reg:SI 1 dx [orig:99 D.1789 ] [99])) pr68328.c:14 -1
(nil))
(insn 69 70 4 3 (set (reg:SI 3 bx [orig:83 h ] [83])
(if_then_else:SI (ne (reg:CCZ 17 flags)
(const_int 0 [0]))
(reg:SI 0 ax [106])
(reg:SI 3 bx [orig:83 h ] [83]))) pr68328.c:14 952 {*movsicc_noc}
...
(insn 65 18 66 4 (set (reg:SI 0 ax [orig:100 D.1790 ] [100])
(plus:SI (reg:SI 3 bx [orig:83 h ] [83])
(const_int -120 [0xff88]))) 258 {*leasi}
(nil))
which looks very wrong, originally the IF_THEN_ELSE had the memory load in ax
and bx has been previously either uninitialized, or from previous iteration.
But the changed code sets bx to the (now sign-extended) memory load, and leaves
ax uninitialized; but that is actually the value assigned to bx in the
movsicc_noc, so depending on what value %eax has upon entry to this function we
either fail or don't.
[Bug tree-optimization/68306] [6 Regression] ICE: in vectorizable_store, at tree-vect-stmts.c:5651
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68306 Richard Biener changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Richard Biener --- Fixed.
[Bug tree-optimization/68367] [6 regression] ICE in vectorizable_load, at tree-vect-stmts.c:6711
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68367 --- Comment #3 from Richard Biener --- (In reply to Christophe Lyon from comment #2) > (In reply to Richard Biener from comment #1) > > Ok, so I assume this is after the fix for PR68306. > > Indeed: that was fixed at r230310, at which point my build still succeded. > > It started to fail at r230311. Hmm, in a tree with the fix for PR68306 I can't reproduce with a cross. Can you double-check please?
[Bug rtl-optimization/68328] [4.9/5/6 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68328 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org --- Comment #6 from ktkachov at gcc dot gnu.org --- This looks like what I found out for PR 68194 and Thomas did for PR 68185. I'm testing a patch to fix the issue in ree and it involves disallowing the transformation when the defining insn doesn't feed directly into the extend, but rather goes through a conditional move
[Bug rtl-optimization/68328] [4.9/5/6 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68328
--- Comment #7 from Jakub Jelinek ---
In insn 70 actually set eax to edx rather than ebx, I'd suppose it would work
correctly.
Better testcase that fails reliably:
int a, b, c = 1, d = 1, e;
__attribute__((noinline, noclone)) int
foo (void)
{
asm volatile ("" : : : "memory");
return 4195552;
}
__attribute__((noinline, noclone)) void
bar (int x, int y)
{
asm volatile ("" : : "g" (x), "g" (y) : "memory");
if (y == 0)
__builtin_abort ();
}
int
baz (int x)
{
char g, h;
int i, j;
foo ();
for (;;)
{
if (c)
h = d;
g = h < x ? h : 0;
i = (char) ((g - 120) ^ 1);
j = i > 97;
if (a - j)
bar (0x123456, 0);
if (!b)
return e;
}
}
int
main ()
{
baz (2);
return 0;
}
[Bug tree-optimization/65752] Too strong optimizations int -> pointer casts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752 --- Comment #44 from rguenther at suse dot de --- On Mon, 16 Nov 2015, jeehoon.kang at sf dot snu.ac.kr wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752 > > Jeehoon Kang changed: > >What|Removed |Added > > CC||jeehoon.kang at sf dot > snu.ac.kr > > --- Comment #43 from Jeehoon Kang --- > - Performance degradation due to "casted pointers as escaped" is > insignificant. I think this is not true. For example with MatLab (might be sth else, if I don't remember correctly) you are required to pass pointers to arrays in two halves in double(!) values (I believe the only function argument type they support). GCC happily makes points-to analysis work through those. The other (unfortunate) thing is that in GCC pointer subtraction is always performed on integers, thus for the C source code int idx = ptr1 - ptr2; we internally have sth like int idx = ((long)ptr1 - (long)ptr2) / 4; so you can't really treat pointers as "escaped" here without loss. Note that we've had this (kind of) in the past and it tried to go without making pointers escaped at these points but only consider casts from integers to pointers as pointing to anything. But that's wrong correctness wise (not then treating the cast to integer as escape point). I also don't think doing the above would solve the cases of equality compares of pointes themselves. (hopefully undefined) I added the current handling of pointers vs. integers for a missed-optimization bug that said a hand-written memcpy loop didn't properly transfer points-to info (properly as in optimially for optimization). GCC can now do that ;)
[Bug middle-end/67790] [6 Regression] verify_ssa failed: definition in block 20 follows the use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67790 --- Comment #5 from Richard Biener --- Aww. And then I'm running into the issue of pattern recog / reduction analysis ordering which has caused me headaches before... maybe time to (finally) fix that.
[Bug c++/68372] New: [concepts] invalid use of pack expansion expression in member function template declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68372
Bug ID: 68372
Summary: [concepts] invalid use of pack expansion expression in
member function template declaration
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lucdanton at free dot fr
Target Milestone: ---
I can't really understand the error and I don't know the rules very well, but
here goes.
$ g++-trunk --version
g++-trunk (GCC) 6.0.0 20151103 (experimental)
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ g++-trunk -std=c++1z main.cpp
main.cpp: In substitution of 'template requires predicate(
C...) void foo::bar(X ...) [with X = {}]':
main.cpp:18:16: required from here
main.cpp:11:10: error: invalid use of pack expansion expression
void bar(X...)
^
$ cat main.cpp
template concept bool C = true;
// fine
template
void bar(X...)
{}
struct foo {
// error: invalid use of pack expansion expression
template
void bar(X...)
{}
};
int main()
{
bar();
foo {}.bar();
}
[Bug c/68337] [MPX] memcpy() for arrays with function pointers results in huge resource usage and binaries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68337 --- Comment #1 from Ilya Enkovich --- The problem is that memcpy is inlined before instrumentation takes place. This causes a lot of statements to copy bounds and thus we get a huge function and significant compilation time. One possible solution is to not inline memcpy. Actually I don't see why we do it. Seems it always happen when size of copied data is known. Another solution is to use wrapper function to copy bounds. This function is not in libmpx yet (it is currently on review) and I don't think it will be ported to GCC5.
[Bug rtl-optimization/68249] [4.9/5/6 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68249 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Supposedly the same issue as PR68328?
[Bug rtl-optimization/68189] [4.9/5/6 Regression] wrong code at -Os and above on x86_64-linux-gnu by RTL if-conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68189 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #9 from Jakub Jelinek --- Bet another PR68328 case. I'd say until that is fixed, all these vars only conditionally initialized in a conditional move are suspected dups.
[Bug rtl-optimization/68194] [6 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68194
--- Comment #5 from ktkachov at gcc dot gnu.org ---
The different if-conversion behaviour enabled a new cse opportunity
which then produced the RTL that triggered the bad ree behaviour.
The relevant RTL insns before the ree pass look like:
Basic Block A:
(set (reg:HI 0 ax)
(mem:HI (symbol_ref:DI ("f"
...
(set (reg:SI 3 bx)
(if_then_else:SI (eq (reg:CCZ 17 flags)
(const_int 0))
(reg:SI 0 ax)
(reg:SI 3 bx)))
(set (reg:SI 4 si)
(sign_extend:SI (reg:HI 3 bx)))
...
Basic block B (dominated by basic block A):
(set (reg:SI 4 si)
(sign_extend:SI (reg:QI 0 ax))) /* ax contains symbol "f". */
ree changes that into the broken:
Basic block A:
(set (reg:SI 4 si)
(sign_extend:SI (mem:HI (symbol_ref:DI ("f")
(set (reg:SI 3 bx)
(reg:SI 4 si))
...
(set (reg:SI 3 bx)
(if_then_else:SI (eq (reg:CCZ 17 flags)
(const_int 0 [0]))
(reg:SI 0 ax)
(reg:SI 3 bx)))
...
Basic block B:
(set (reg:SI 4 si)
(sign_extend:SI (reg:QI 0 ax))) /* Insn unchanged by ree, but ax now
undefined. */
[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837 --- Comment #34 from chrbr at gcc dot gnu.org --- Author: chrbr Date: Mon Nov 16 11:20:02 2015 New Revision: 230410 URL: https://gcc.gnu.org/viewcvs?rev=230410&root=gcc&view=rev Log: 2015-11-16 Christian Bruel PR target/65837 * config/arm/arm-c.c (arm_cpu_builtins): Conditionally set and reset __ARM_FEATURE_FMA and __ARM_NEON_FP, __ARM_FP. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm-c.c
[Bug c++/60336] empty struct value is passed differently in C and C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60336 --- Comment #40 from H.J. Lu --- (In reply to H.J. Lu from comment #38) > Created attachment 36724 [details] > An updated patch to add empty_record_p > > I am testing it now. It doesn't work since it misses for (binfo = TYPE_BINFO (type), i = 0; BINFO_BASE_ITERATE (binfo, i, base_binfo); ++i) if (!is_really_empty_class (BINFO_TYPE (base_binfo))) return false; in is_really_empty_class in cp/class.c. It is language specific.
[Bug c++/60336] empty struct value is passed differently in C and C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60336 --- Comment #41 from H.J. Lu --- (In reply to Andrew Pinski from comment #39) > You should also update gimplify.c's zero_sized_type to be the same as your > empty_record_p. It won't work since the size of empty class isn't zero in C++. We just pass and return it like zero size record in C++.
[Bug c++/68195] gcc//ld produces invalid ABI results (cxx11 problem?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68195 --- Comment #6 from Matthias Goldhoorn --- (In reply to Jonathan Wakely from comment #5) > Fails with gcc-5-branch, but doesn't fail on trunk for me. Is there a trunk branch or tag available i can try to compile, the last versions i tried does not compile (the compiler itself).
[Bug c++/68348] [6 regression] ICE: segfault in cxx_eval_constant_expression at cp/constexpr.c:3172
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68348 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- Started with r230365 aka C++ delayed folding merge.
[Bug jit/68370] Pointer arithmetic in libgccjit seems to require an extra cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68370 --- Comment #2 from David Malcolm --- Thanks for reporting this. That error message: libgccjit.so: error: gcc_jit_block_add_assignment: mismatching types: assignment to text (type: const char *) from &text[(int)1] (type: const char *) looks wrong. Please can you attach the full reproducer as a .c file (perhaps using gcc_jit_context_dump_reproducer_to_file; see https://gcc.gnu.org/onlinedocs/jit/topics/contexts.html#gcc_jit_context_dump_reproducer_to_file ).
[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837 chrbr at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #35 from chrbr at gcc dot gnu.org --- Specific NEON case fixed with the attribute/pragma target support for fpu= attribute support can now be extended for other target flags that need to be propagated to LTO (-mcpu=, -mtune=, -munaligned-access...)
[Bug tree-optimization/68157] [5/6 Regression] internal compiler error: in reassoc_stmt_dominates_stmt_p, at tree-ssa-reassoc.c:1287
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68157 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 36726 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36726&action=edit gcc6-pr68157.patch Untested fix.
[Bug target/66776] [AArch64] zero-extend version of csel not matching properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66776 --- Comment #2 from ktkachov at gcc dot gnu.org --- Renlin, can you close this PR if there's nothing more to do here?
[Bug target/68365] gfortran test case showing performance loss with vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68365 Richard Biener changed: What|Removed |Added Status|WAITING |NEW --- Comment #3 from Richard Biener --- Hmm, there are many loops here. I looked at the following (assuming the interesting loops are marked with safelen(1)) subroutine s111(ntimes,ld,n,ctime,dtime,a,b,c,d,e,aa,bb,cc) use lcd_mod C C linear dependence testing C no dependence - vectorizable C integer ntimes,ld,n,i,nl real a(n),b(n),c(n),d(n),e(n),aa(ld,n),bb(ld,n),cc(ld,n) real t1,t2,chksum,ctime,dtime,cs1d call init(ld,n,a,b,c,d,e,aa,bb,cc,'s111 ') call forttime(t1) do nl= 1,2*ntimes #ifndef __MIC__ !$omp simd safelen(1) #endif do i= 2,n,2 a(i)= a(i-1)+b(i) enddo call dummy(ld,n,a,b,c,d,e,aa,bb,cc,1.) enddo call forttime(t2) and current trunk doesn't consider this profitable unless -mavx is given (it needs the larger vector size for profitability it seems). Because of the step 2 it ends up using strided stores. Instead of doing interleaving on the loads and stores we could have just operated on all elements (rather than only even ones) and then use a masked store. That would waste half of the vector bandwidth but save all the shuffles. .L8: vmovups (%rdx), %xmm0 addl$1, %r9d addq$64, %rdx addq$64, %r11 vmovups -32(%rdx), %xmm2 vinsertf128 $0x1, -48(%rdx), %ymm0, %ymm1 vmovups -64(%r11), %xmm9 vinsertf128 $0x1, -16(%rdx), %ymm2, %ymm3 vmovups -32(%r11), %xmm11 vinsertf128 $0x1, -48(%r11), %ymm9, %ymm10 vinsertf128 $0x1, -16(%r11), %ymm11, %ymm12 vshufps $136, %ymm3, %ymm1, %ymm4 vshufps $136, %ymm12, %ymm10, %ymm13 vperm2f128 $3, %ymm4, %ymm4, %ymm5 vperm2f128 $3, %ymm13, %ymm13, %ymm14 vshufps $68, %ymm5, %ymm4, %ymm6 vshufps $238, %ymm5, %ymm4, %ymm7 vshufps $68, %ymm14, %ymm13, %ymm15 vshufps $238, %ymm14, %ymm13, %ymm0 vinsertf128 $1, %xmm7, %ymm6, %ymm8 vinsertf128 $1, %xmm0, %ymm15, %ymm1 vaddps %ymm1, %ymm8, %ymm2 vextractf128$0x1, %ymm2, %xmm4 vmovss %xmm2, -60(%rdx) vextractps $1, %xmm2, -52(%rdx) vextractps $2, %xmm2, -44(%rdx) vextractps $3, %xmm2, -36(%rdx) vmovss %xmm4, -28(%rdx) vextractps $1, %xmm4, -20(%rdx) vextractps $2, %xmm4, -12(%rdx) vextractps $3, %xmm4, -4(%rdx) cmpl%r9d, %ecx ja .L8 what we fail to realize here is that cross-lane interleaving isn't working with AVX256 and thus the interleave for the loads is very much more expensive than we think. That's a general vectorizer cost model issue: /* Uses an even and odd extract operations or shuffle operations for each needed permute. */ int nstmts = ncopies * ceil_log2 (group_size) * group_size; inside_cost = record_stmt_cost (body_cost_vec, nstmts, vec_perm, stmt_info, 0, vect_body); which 1) doesn't consider single-element interleaving differently, 2) simply uses vec_perm cost which heavily depends on the actual (constant) permutation used
[Bug tree-optimization/65752] Too strong optimizations int -> pointer casts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
--- Comment #45 from Jeehoon Kang ---
> I think this is not true. For example with MatLab (might be sth else,
> if I don't remember correctly) you are required to pass pointers to
> arrays in two halves in double(!) values (I believe the only function
> argument type they support). GCC happily makes points-to analysis work
> through those.
Thank you for giving me an example. Yet, I think it is a little bit
unfortunate for MatLab (or sth else) to pass pointers by packing two into a
double, at least due to the readability problem. I think it is beyond the
intended usage of the C/C++ language, but I understand that GCC is the
time-honored compiler for various software and systems.
> The other (unfortunate) thing is that in GCC pointer subtraction
> is always performed on integers, thus for the C source code
>
> int idx = ptr1 - ptr2;
>
> we internally have sth like
>
> int idx = ((long)ptr1 - (long)ptr2) / 4;
>
> so you can't really treat pointers as "escaped" here without loss.
Thank you for giving me the information. I don't know the GCC internals, so I
would like to ask how much it would cost to introduce the syntax for pointer
subtractions. I hope it is not that huge, but I really don't have any idea.
> Note that we've had this (kind of) in the past and it tried to go
> without making pointers escaped at these points but only consider
> casts from integers to pointers as pointing to anything. But
> that's wrong correctness wise (not then treating the cast to integer
> as escape point).
Treating the cast to integer as escape point is proven-correct by a
machine-checked proof (in Coq) for various standard optimization examples, such
as CP, DCE, dead allocation elimination, etc. For more detail, please see the
paper above-mentioned.
> I also don't think doing the above would solve the cases of equality
> compares of pointes themselves. (hopefully undefined)
The formal memory model in the paper I mentioned invokes undefined behavior for
the pointer equality comparison example above. In the formal model, a pointer
is represented as a pair of a memory block identifier (l) and an offset (o).
(cf. the CompCert memory model) When a memory is malloc-ed or alloca-ed, a new
memory block identifier is assigned. A pointer equality, say of (l, o) and
(l', o'), invokes undefined behavior when l != l'.
So for the following example (by Alexander Cherepanov):
#include
#include
int main() {
int y, x = 0;
int *volatile v = &x;
int *xp = v;
int *i = &y + 1;
if (xp != i) {
printf("hello\n");
xp = i;
}
printf("%d\n", xp == &x);
}
Say y and x are allocated at l1 and l2, respectively. Then xp = (l2, 0), and i
= (l1, 4). Thus comparing xp and i invokes undefined behavior, since l1 != l2.
[Bug libstdc++/66145] [5/6 Regression] std::ios_base::failure objects thrown from libstdc++.so use old ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66145 --- Comment #7 from Jonathan Wakely --- I would suggest not using exceptions with iostreams, they've always been an odd mix anyway.
[Bug tree-optimization/68306] [6 Regression] ICE: in vectorizable_store, at tree-vect-stmts.c:5651
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68306 Ulrich Weigand changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #12 from Ulrich Weigand --- Unfortunately, it seems that your second commit brought back the failure on spu-elf that had already been fixed by the first commit ... /home/uweigand/dailybuild/spu-tc-2015-11-13/gcc-head/src/libgfortran/generated/matmul_c4.c: In function 'matmul_c4': /home/uweigand/dailybuild/spu-tc-2015-11-13/gcc-head/src/libgfortran/generated/matmul_c4.c:79:1: internal compiler error: in vectorizable_store, at tree-vect-stmts.c:5655 matmul_c4 (gfc_array_c4 * const restrict retarray, ^ 0x10b19c83 vectorizable_store /home/uweigand/dailybuild/spu-tc-2015-11-13/gcc-head/src/gcc/tree-vect-stmts.c:5655 0x10b21db3 vect_transform_stmt(gimple*, gimple_stmt_iterator*, bool*, _slp_tree*, _slp_instance*) /home/uweigand/dailybuild/spu-tc-2015-11-13/gcc-head/src/gcc/tree-vect-stmts.c:8007 0x10b49ecf vect_schedule_slp_instance /home/uweigand/dailybuild/spu-tc-2015-11-13/gcc-head/src/gcc/tree-vect-slp.c:3608 0x10b503ab vect_schedule_slp(vec_info*) /home/uweigand/dailybuild/spu-tc-2015-11-13/gcc-head/src/gcc/tree-vect-slp.c:3673 0x10b2dffb vect_transform_loop(_loop_vec_info*) /home/uweigand/dailybuild/spu-tc-2015-11-13/gcc-head/src/gcc/tree-vect-loop.c:6773 0x10b57ab3 vectorize_loops() /home/uweigand/dailybuild/spu-tc-2015-11-13/gcc-head/src/gcc/tree-vectorizer.c:533 0x109fa5d7 execute /home/uweigand/dailybuild/spu-tc-2015-11-13/gcc-head/src/gcc/tree-ssa-loop.c:273
[Bug fortran/60993] Trouble initializing double precision variable using boz literals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60993 --- Comment #4 from Dominique d'Humieres --- With the patch at https://gcc.gnu.org/ml/fortran/2015-11/msg00093.html, compiling the test gives the error pr60993.f90:7:45: integer, parameter :: infn(2) = [Z'',Z'FFF0'] 1 Error: Arithmetic overflow converting INTEGER(16) to INTEGER(4) at (1). This check can be disabled with the option '-fno-range-check' The test compiles with the suggested option '-fno-range-check', but the output is sinfn=-Infinity sinfp= Infinity dinfp= Infinitydinfp1= 0. dinfn= -Infinity With the following change --- pr60993.f90 2014-04-29 22:32:47.0 +0200 +++ pr60993_db.f90 2015-11-16 13:26:14.0 +0100 @@ -14,7 +14,7 @@ sinfp = transfer(Z'7F80', sinfp) print *, "sinfn=", sinfn, " sinfp=", sinfp dinfp = transfer(infp, dinfp) ! Works - dinfp1 = transfer([Z'',Z'7FF0'], dinfp1) ! Fails --- Why?? + dinfp1 = transfer(int([Z'',Z'7FF0'],kind=4), dinfp1) ! Fails --- Why?? print *, "dinfp=",dinfp, " dinfp1=", dinfp1 the output is sinfn=-Infinity sinfp= Infinity dinfp= Infinitydinfp1= Infinity dinfn= -Infinity
[Bug sanitizer/67941] [5/6 Regression] calls on function pointer from a captureless lambda cause ubsan warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67941 Jakub Jelinek changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- The UBSAN_NULL instrumentation is added in c-family/c-ubsan.c (ubsan_maybe_instrument_member_call), on stmt that is main()operator() (0B) i.e.: > side-effects nothrow protected fn unsigned DI size unit size align 64 symtab 0 alias set -1 canonical type 0x7187c888> constant arg 0 addressable used nothrow static tree_2 autoinline decl_3 decl_5 QI file pr67941.C line 1 col 18 align 16 context initial result full-name "main()::" pending-inline-info 0x77ff9d80 arguments struct-function 0x7187c738>> arg 0 constant 0> pr67941.C:1:20 start: pr67941.C:1:20 finish: pr67941.C:1:20> And as the call is to a method (which has METHOD_TYPE), UBSAN_NULL is inserted. If this is valid, can you suggest which method calls the C++ FE considers (just with literal NULL passed to this, or others too?) valid?
[Bug tree-optimization/68306] [6 Regression] ICE: in vectorizable_store, at tree-vect-stmts.c:5651
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68306 --- Comment #13 from Richard Biener --- Can you attach preprocessed source? See also PR68367 which I can't reproduce with a cross.
[Bug tree-optimization/65752] Too strong optimizations int -> pointer casts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752 --- Comment #46 from rguenther at suse dot de --- On Mon, 16 Nov 2015, jeehoon.kang at sf dot snu.ac.kr wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752 > > --- Comment #45 from Jeehoon Kang --- > > I think this is not true. For example with MatLab (might be sth else, > > if I don't remember correctly) you are required to pass pointers to > > arrays in two halves in double(!) values (I believe the only function > > argument type they support). GCC happily makes points-to analysis work > > through those. > > Thank you for giving me an example. Yet, I think it is a little bit > unfortunate for MatLab (or sth else) to pass pointers by packing two into a > double, at least due to the readability problem. I think it is beyond the > intended usage of the C/C++ language, but I understand that GCC is the > time-honored compiler for various software and systems. > > > > > The other (unfortunate) thing is that in GCC pointer subtraction > > is always performed on integers, thus for the C source code > > > > int idx = ptr1 - ptr2; > > > > we internally have sth like > > > > int idx = ((long)ptr1 - (long)ptr2) / 4; > > > > so you can't really treat pointers as "escaped" here without loss. > > Thank you for giving me the information. I don't know the GCC internals, so I > would like to ask how much it would cost to introduce the syntax for pointer > subtractions. I hope it is not that huge, but I really don't have any idea. It would be quite some (mechanical) work but otherwise not too difficult. There is the choice whether to embed the division implicitely here or not. > > Note that we've had this (kind of) in the past and it tried to go > > without making pointers escaped at these points but only consider > > casts from integers to pointers as pointing to anything. But > > that's wrong correctness wise (not then treating the cast to integer > > as escape point). > > Treating the cast to integer as escape point is proven-correct by a > machine-checked proof (in Coq) for various standard optimization examples, > such > as CP, DCE, dead allocation elimination, etc. For more detail, please see the > paper above-mentioned. Yes, I agree that making this an escape point is enough.
[Bug rtl-optimization/68321] [5/6 Regression] wrong code at -O3 on x86_64-linux-gnu (in 64-bit mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68321 Richard Biener changed: What|Removed |Added Status|ASSIGNED|NEW Depends on||68143 Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #6 from Richard Biener --- -fno-ree fixes this one as well. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68143 [Bug 68143] [5/6 Regression][ARM] Wrong code initialising struct member after zeroing out the whole struct
[Bug target/68365] gfortran test case showing performance loss with vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68365 --- Comment #4 from n8tm at aol dot com --- On 11/16/2015 7:13 AM, rguenth at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68365 > > Richard Biener changed: > >What|Removed |Added > > Status|WAITING |NEW > > --- Comment #3 from Richard Biener --- > Hmm, there are many loops here. I looked at the following (assuming the > interesting loops are marked with safelen(1)) > > subroutine s111(ntimes,ld,n,ctime,dtime,a,b,c,d,e,aa,bb,cc) > use lcd_mod > C > C linear dependence testing > C no dependence - vectorizable > C > integer ntimes,ld,n,i,nl > real a(n),b(n),c(n),d(n),e(n),aa(ld,n),bb(ld,n),cc(ld,n) > real t1,t2,chksum,ctime,dtime,cs1d > call init(ld,n,a,b,c,d,e,aa,bb,cc,'s111 ') > call forttime(t1) > do nl= 1,2*ntimes > #ifndef __MIC__ > !$omp simd safelen(1) > #endif > do i= 2,n,2 > a(i)= a(i-1)+b(i) > enddo > call dummy(ld,n,a,b,c,d,e,aa,bb,cc,1.) > enddo > call forttime(t2) > > and current trunk doesn't consider this profitable unless -mavx is given > (it needs the larger vector size for profitability it seems). > > Because of the step 2 it ends up using strided stores. Instead of > doing interleaving on the loads and stores we could have just operated > on all elements (rather than only even ones) and then use a masked > store. That would waste half of the vector bandwidth but save all the > shuffles. > > .L8: > vmovups (%rdx), %xmm0 > addl$1, %r9d > addq$64, %rdx > addq$64, %r11 > vmovups -32(%rdx), %xmm2 > vinsertf128 $0x1, -48(%rdx), %ymm0, %ymm1 > vmovups -64(%r11), %xmm9 > vinsertf128 $0x1, -16(%rdx), %ymm2, %ymm3 > vmovups -32(%r11), %xmm11 > vinsertf128 $0x1, -48(%r11), %ymm9, %ymm10 > vinsertf128 $0x1, -16(%r11), %ymm11, %ymm12 > vshufps $136, %ymm3, %ymm1, %ymm4 > vshufps $136, %ymm12, %ymm10, %ymm13 > vperm2f128 $3, %ymm4, %ymm4, %ymm5 > vperm2f128 $3, %ymm13, %ymm13, %ymm14 > vshufps $68, %ymm5, %ymm4, %ymm6 > vshufps $238, %ymm5, %ymm4, %ymm7 > vshufps $68, %ymm14, %ymm13, %ymm15 > vshufps $238, %ymm14, %ymm13, %ymm0 > vinsertf128 $1, %xmm7, %ymm6, %ymm8 > vinsertf128 $1, %xmm0, %ymm15, %ymm1 > vaddps %ymm1, %ymm8, %ymm2 > vextractf128$0x1, %ymm2, %xmm4 > vmovss %xmm2, -60(%rdx) > vextractps $1, %xmm2, -52(%rdx) > vextractps $2, %xmm2, -44(%rdx) > vextractps $3, %xmm2, -36(%rdx) > vmovss %xmm4, -28(%rdx) > vextractps $1, %xmm4, -20(%rdx) > vextractps $2, %xmm4, -12(%rdx) > vextractps $3, %xmm4, -4(%rdx) > cmpl%r9d, %ecx > ja .L8 > > what we fail to realize here is that cross-lane interleaving isn't working > with AVX256 and thus the interleave for the loads is very much more expensive > than we think. > > That's a general vectorizer cost model issue: > > /* Uses an even and odd extract operations or shuffle operations > for each needed permute. */ > int nstmts = ncopies * ceil_log2 (group_size) * group_size; > inside_cost = record_stmt_cost (body_cost_vec, nstmts, vec_perm, > stmt_info, 0, vect_body); > > which 1) doesn't consider single-element interleaving differently, > 2) simply uses vec_perm cost which heavily depends on the actual > (constant) permutation used > Thanks for the interesting analysis. icc/icpc take safelen(1) as preventing vectorization for this case, but I found another stride 2 case where they still perform the unprofitable AVX vectorization. Maybe I'll submit an Intel PR (IPS).
[Bug sanitizer/67941] [5/6 Regression] calls on function pointer from a captureless lambda cause ubsan warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67941 --- Comment #5 from Jakub Jelinek --- Created attachment 36727 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36727&action=edit gcc6-pr67941.patch Random attempt to write some condition, but I really have no idea if it is at least anywhere close to the right one.
[Bug target/68277] [5/6 Regression] [SH]: error: insn does not satisfy its constraints when compiling erlang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68277 --- Comment #11 from Kazumoto Kojima --- (In reply to Kazumoto Kojima from comment #10) > I'll report back when the regression test currently running is done. I've confirmed that there are no new failures with the new patch on sh4-unknown-linux-gnu. BTW, the ICE for gcc.dg/atomic/c11-atomic-exec-4.c -Os pops up again even with the unmodified tree. So we have no regressions at all.
[Bug tree-optimization/68327] [6 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in vect_is_simple_use, at tree-vect-stmts.c:8562
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68327 Ilya Enkovich changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ienkovich at gcc dot gnu.org
[Bug target/68277] [5/6 Regression] [SH]: error: insn does not satisfy its constraints when compiling erlang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68277 --- Comment #12 from Oleg Endo --- (In reply to Kazumoto Kojima from comment #10) > (In reply to Oleg Endo from comment #9) > > At the current (lack of) pace I don't know when all of that will be done. > > So my idea was to at least reduce the R0 problem for users by making LRA the > > default in GCC 6. If we have to add the 2nd postreload temporarily, so be > > it. When the other solutions become more mature and stable, we can remove > > the 2nd postreload thing again. > > I don't object. Please go ahead. OK. I would like to wait with that a bit though. I'm still trying to get some work done on AMS... (In reply to Kazumoto Kojima from comment #11) > > I've confirmed that there are no new failures with the new patch on > sh4-unknown-linux-gnu. > BTW, the ICE for gcc.dg/atomic/c11-atomic-exec-4.c -Os pops up again > even with the unmodified tree. So we have no regressions at all. Great, thanks! I'll commit it to trunk and GCC 5 branch.
[Bug tree-optimization/68367] [6 regression] ICE in vectorizable_load, at tree-vect-stmts.c:6711
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68367 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #4 from Martin Liška --- Hi. I've just built cross-compiler (on x86_64-linux-pc as host system): ../configure --enable-languages=c,c++ --disable-bootstrap --target=arm-none-linux-gnueabihf and the test-case works for me: ./xgcc -B. /home/marxin/Programming/gcc3/libgfortran/generated/matmul_i4.c -I. -c -O2 -ftree-vectorize -I/usr/include -c I've tried your pre-processed file and also valgrind does not emit any error related to IPA ICF. Martin
[Bug ipa/67280] [5 Regression] wrong C++11 code generated on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67280 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org --- Comment #6 from ktkachov at gcc dot gnu.org --- So can this be closed?
[Bug middle-end/68117] [6 Regression] error: invalid PHI argument <<< Unknown tree: >>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68117 --- Comment #31 from Richard Biener --- Author: rguenth Date: Mon Nov 16 14:06:08 2015 New Revision: 230424 URL: https://gcc.gnu.org/viewcvs?rev=230424&root=gcc&view=rev Log: 2015-11-16 Richard Biener PR middle-end/68117 * cfgexpand.c (pass_expand::execute): Destroy the edge redirection var map before setting RTL CFG hooks. Modified: trunk/gcc/ChangeLog trunk/gcc/cfgexpand.c
[Bug middle-end/67653] [4.9/5/6 Regression] ICE on valid code on x86_64-linux-gnu: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67653
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
Bet r140431. The issue seems to be that the FEs make the "m" operand
addressable:
if (parse_output_constraint (&constraint, i, ninputs, noutputs,
&allows_mem, &allows_reg, &is_inout))
{
/* If the operand is going to end up in memory,
mark it addressable. */
if (!allows_reg && !cxx_mark_addressable (operand))
operand = error_mark_node;
}
or:
if (!allows_reg && allows_mem)
{
input = c_fully_fold (input, false, NULL);
/* Strip the nops as we allow this case. FIXME, this really
should be rejected or made deprecated. */
STRIP_NOPS (input);
if (!c_mark_addressable (input))
input = error_mark_node;
}
but for the case of a statement expression that doesn't mark it addressable.
Then during gimplify_asm_expr we:
5281 tret = gimplify_expr (&TREE_VALUE (link), pre_p, post_p,
5282is_gimple_lvalue, fb_lvalue |
fb_mayfail);
5283 mark_addressable (TREE_VALUE (link));
5284 if (tret == GS_ERROR)
and in this case tref actually is not GS_ERROR, as it is gimplified to an
artificial decl from a TARGET_EXPR. But it marks addressable something that
has been already used.
No idea what to do here. For "=m" we require lvalue_or_else (after doing a
hack and stripping nops), but for the input operands we don't.
So perhaps just replace the mark_addressable call with something like:
tree x = TREE_VALUE (link);
while (handled_component_p (x))
x = TREE_OPERAND (x, 0);
if (TREE_CODE (x) == MEM_REF
&& TREE_CODE (TREE_OPERAND (x, 0)) == ADDR_EXPR)
x = TREE_OPERAND (TREE_OPERAND (x, 0), 0);
if ((TREE_CODE (x) == VAR_DECL
|| TREE_CODE (x) == PARM_DECL
|| TREE_CODE (x) == RESULT_DECL)
&& !TREE_ADDRESSABLE (x))
{
error ("memory input %d is not directly addressable", i);
ret = GS_ERROR;
}
[Bug rtl-optimization/68194] [6 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68194 --- Comment #6 from ktkachov at gcc dot gnu.org --- Proposed patch at: https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01953.html
[Bug target/68277] [5/6 Regression] [SH]: error: insn does not satisfy its constraints when compiling erlang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68277 --- Comment #13 from Oleg Endo --- Author: olegendo Date: Mon Nov 16 14:11:50 2015 New Revision: 230425 URL: https://gcc.gnu.org/viewcvs?rev=230425&root=gcc&view=rev Log: gcc/ PR target/68277 * config/sh/sh.md (addsi3_scr): Handle reg overlap of operands[0] and operands[2]. (*addsi3): Add another insn_and_split variant for reload. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh.md
[Bug target/68277] [5/6 Regression] [SH]: error: insn does not satisfy its constraints when compiling erlang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68277 --- Comment #14 from Oleg Endo --- Author: olegendo Date: Mon Nov 16 14:22:10 2015 New Revision: 230426 URL: https://gcc.gnu.org/viewcvs?rev=230426&root=gcc&view=rev Log: gcc/ Backport from mainline 2015-11-16 Oleg Endo Kaz Kojima PR target/68277 * config/sh/sh.md (addsi3_scr): Handle reg overlap of operands[0] and operands[2]. (*addsi3): Add another insn_and_split variant for reload. Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/config/sh/sh.md
[Bug c++/68362] [6 Regression] ICE: tree check: expected integer_cst, have nop_expr in get_val, at tree.h:5157
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68362 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #5 from Marek Polacek --- The problem here is that check_case_bounds is getting NOP_EXPRs: (const A) 0 introduced in convert_and_check called in c_add_case_label, and then it tries tree_int_cst_compare on that, oops. STRIP_NOPS-ing case_low and case_high would fix this...
[Bug rtl-optimization/68349] [6 regression] ice in decompose_normal_address with -O2 at rtlanal.c:6086
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68349 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- Started with r228306.
[Bug ipa/67280] [5 Regression] wrong C++11 code generated on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67280 --- Comment #7 from cbaylis at gcc dot gnu.org --- I am backporting the fix to GCC 5 now. I'll close it once committed.
[Bug tree-optimization/68306] [6 Regression] ICE: in vectorizable_store, at tree-vect-stmts.c:5651
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68306
--- Comment #14 from Ulrich Weigand ---
Building the following reduced test case with
-O2 -ftree-vectorize -fcx-fortran-rules
with an spu-elf cross-cc1 shows the ICE.
void
test (_Complex float *dest,
_Complex float scale, int count)
{
for (int x = 0; x < count; x++)
dest[x] *= scale;
}
[Bug target/66312] [SH] Regression: Bootstrap failure gcc/d/ctfeexpr.dmd.o differs with gcc-4.8/4.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66312 --- Comment #23 from Oleg Endo --- Ping?
[Bug target/68277] [5/6 Regression] [SH]: error: insn does not satisfy its constraints when compiling erlang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68277 Oleg Endo changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #15 from Oleg Endo --- I think we can close this as fixed.
[Bug target/65251] sh4: internal compiler error: Bus error when compiling cpp-netlib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65251 --- Comment #7 from Oleg Endo --- Ping?
[Bug tree-optimization/68367] [6 regression] ICE in vectorizable_load, at tree-vect-stmts.c:6711
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68367 --- Comment #5 from Christophe Lyon --- (In reply to Richard Biener from comment #3) > (In reply to Christophe Lyon from comment #2) > > (In reply to Richard Biener from comment #1) > > > Ok, so I assume this is after the fix for PR68306. > > > > Indeed: that was fixed at r230310, at which point my build still succeded. > > > > It started to fail at r230311. > > Hmm, in a tree with the fix for PR68306 I can't reproduce with a cross. > > Can you double-check please? I've just reproduced it again with an extract at r230402. Please make sure you use target armeb-none-linux-gnueabihf, not arm-none-linux-gnueabihf as Martin used. It works for arm-none-linux-gnueabihf, but not for armeb-none-linux-gnueabihf (big-endian)
[Bug target/65251] sh4: internal compiler error: Bus error when compiling cpp-netlib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65251 --- Comment #8 from John Paul Adrian Glaubitz --- (In reply to Oleg Endo from comment #7) > Ping? Please wait a few more days. I'm currently trying a new approach with qemu-sh4 as you have probably seen on the debian-superh mailing list. This will hopefully allow me to reduce compile time by large margin (first benchmarks showed a 100% performance increase), so I will be able to report back more quickly and actually don't have to abuse the buildds for the tests. I am currently test-building gtk+3.0, then I'll gcc-5 a shot. Once I have verified that these work without issues, I will help with the remaining issues in the SH backend. Adrian
[Bug tree-optimization/68367] [6 regression] ICE in vectorizable_load, at tree-vect-stmts.c:6711
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68367 --- Comment #6 from rguenther at suse dot de --- On Mon, 16 Nov 2015, clyon at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68367 > > --- Comment #5 from Christophe Lyon --- > (In reply to Richard Biener from comment #3) > > (In reply to Christophe Lyon from comment #2) > > > (In reply to Richard Biener from comment #1) > > > > Ok, so I assume this is after the fix for PR68306. > > > > > > Indeed: that was fixed at r230310, at which point my build still succeded. > > > > > > It started to fail at r230311. > > > > Hmm, in a tree with the fix for PR68306 I can't reproduce with a cross. > > > > Can you double-check please? > > I've just reproduced it again with an extract at r230402. > > Please make sure you use target armeb-none-linux-gnueabihf, not > arm-none-linux-gnueabihf as Martin used. It works for > arm-none-linux-gnueabihf, > but not for armeb-none-linux-gnueabihf (big-endian) r230428?
[Bug tree-optimization/68306] [6 Regression] ICE: in vectorizable_store, at tree-vect-stmts.c:5651
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68306 --- Comment #16 from Richard Biener --- Author: rguenth Date: Mon Nov 16 15:04:00 2015 New Revision: 230428 URL: https://gcc.gnu.org/viewcvs?rev=230428&root=gcc&view=rev Log: 2015-11-16 Richard Biener PR tree-optimization/68306 * tree-vect-data-refs.c (vect_verify_datarefs_alignment): Fix bogus copying from verify_data_ref_alignment and use continue instead of return. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vect-data-refs.c
[Bug tree-optimization/68306] [6 Regression] ICE: in vectorizable_store, at tree-vect-stmts.c:5651
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68306
--- Comment #15 from rguenther at suse dot de ---
On Mon, 16 Nov 2015, uweigand at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68306
>
> --- Comment #14 from Ulrich Weigand ---
> Building the following reduced test case with
> -O2 -ftree-vectorize -fcx-fortran-rules
> with an spu-elf cross-cc1 shows the ICE.
>
> void
> test (_Complex float *dest,
> _Complex float scale, int count)
> {
> for (int x = 0; x < count; x++)
> dest[x] *= scale;
> }
Bah, too much copy&pasting. TRivial fix:
Index: gcc/tree-vect-data-refs.c
===
--- gcc/tree-vect-data-refs.c (revision 230421)
+++ gcc/tree-vect-data-refs.c (working copy)
@@ -967,13 +967,13 @@ vect_verify_datarefs_alignment (loop_vec
/* For interleaving, only the alignment of the first access
matters. */
if (STMT_VINFO_GROUPED_ACCESS (stmt_info)
&& GROUP_FIRST_ELEMENT (stmt_info) != stmt)
- return true;
+ continue;
/* Strided accesses perform only component accesses, alignment is
irrelevant for them. */
if (STMT_VINFO_STRIDED_P (stmt_info)
&& !STMT_VINFO_GROUPED_ACCESS (stmt_info))
- return true;
+ continue;
if (! verify_data_ref_alignment (dr))
return false;
[Bug ipa/67280] [5 Regression] wrong C++11 code generated on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67280 --- Comment #8 from cbaylis at gcc dot gnu.org --- Author: cbaylis Date: Mon Nov 16 15:01:01 2015 New Revision: 230427 URL: https://gcc.gnu.org/viewcvs?rev=230427&root=gcc&view=rev Log: backport of fix for PR67280 (r227407) 2015-11-16 Charles Baylis Backport from mainline r227407 PR ipa/67280 * cgraphunit.c (cgraph_node::create_wrapper): Set can_throw_external in new callgraph edge. Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/cgraphunit.c
[Bug c++/67354] [5/6 regression] internal compiler error: in add_to_same_comdat_group, at symtab.c:421
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67354 --- Comment #8 from Jakub Jelinek --- Created attachment 36728 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36728&action=edit gcc6-pr67354.patch Untested hack that just defers generating mangling aliases if at_eof, until the fns are put into the same comdat group.
[Bug c++/67354] [5/6 regression] internal compiler error: in add_to_same_comdat_group, at symtab.c:421
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67354 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- The problem is that first because of the -fabi-version=5 note_mangling_alias calls (at_eof) generate_mangling_alias, which for both base and comp ctors adds a same_comdat_group for the mangling alias. But then we want to put both those ctors into the same comdat group, but it is too late for that.
[Bug tree-optimization/68306] [6 Regression] ICE: in vectorizable_store, at tree-vect-stmts.c:5651
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68306 Richard Biener changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #17 from Richard Biener --- Fixed.
[Bug c++/67337] [4.9/5/6 Regression] Segmentation fault on a template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67337 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Perhaps ping this again?
[Bug tree-optimization/67326] [5/6 Regression] -ftree-loop-if-convert-stores does not vectorize conditional assignment (anymore)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67326 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Yeah, we could perhaps look at the other DRs and figure out that because v3[i] has the same index as v2[i] or v1[i], those are accessed unconditionally and v3 has at least as many elements as v1 or v2, v3[i] will not trap if v2[i] will not.
[Bug tree-optimization/67326] [5/6 Regression] -ftree-loop-if-convert-stores does not vectorize conditional assignment (anymore)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67326 --- Comment #4 from rguenther at suse dot de --- On Mon, 16 Nov 2015, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67326 > > Jakub Jelinek changed: > >What|Removed |Added > > CC||jakub at gcc dot gnu.org > > --- Comment #3 from Jakub Jelinek --- > Yeah, we could perhaps look at the other DRs and figure out that because v3[i] > has the same index as v2[i] or v1[i], those are accessed unconditionally and > v3 > has at least as many elements as v1 or v2, v3[i] will not trap if v2[i] will > not. That all to avoid relying on SCEV and niter analysis? Ok, I can see that it might catch some more cases that way.
[Bug tree-optimization/68367] [6 regression] ICE in vectorizable_load, at tree-vect-stmts.c:6711
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68367 --- Comment #7 from Christophe Lyon --- (In reply to rguent...@suse.de from comment #6) > On Mon, 16 Nov 2015, clyon at gcc dot gnu.org wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68367 > > > > --- Comment #5 from Christophe Lyon --- > > (In reply to Richard Biener from comment #3) > > > (In reply to Christophe Lyon from comment #2) > > > > (In reply to Richard Biener from comment #1) > > > > > Ok, so I assume this is after the fix for PR68306. > > > > > > > > Indeed: that was fixed at r230310, at which point my build still > > > > succeded. > > > > > > > > It started to fail at r230311. > > > > > > Hmm, in a tree with the fix for PR68306 I can't reproduce with a cross. > > > > > > Can you double-check please? > > > > I've just reproduced it again with an extract at r230402. > > > > Please make sure you use target armeb-none-linux-gnueabihf, not > > arm-none-linux-gnueabihf as Martin used. It works for > > arm-none-linux-gnueabihf, > > but not for armeb-none-linux-gnueabihf (big-endian) > > r230428? Build completed now, thanks!
