Re: [PATCH] Fix ICE with bogus posix_memalign call (PR middle-end/67222)
On Tue, Aug 18, 2015 at 12:28 PM, Marek Polacek pola...@redhat.com wrote:
On Tue, Aug 18, 2015 at 10:47:44AM +0200, Richard Biener wrote:
On Mon, Aug 17, 2015 at 8:01 PM, Marek Polacek pola...@redhat.com wrote:
Here we were crashing on an invalid call to posix_memalign. The code in
lower_builtin_posix_memalign assumed that the call had valid arguments.
The reason the C FE doesn't reject this code is, in short, that
int T () is compatible with int T (void **, size_t, size_t) and we
use the former -- so convert_arguments doesn't complain.
So I think let's validate the arguments in lower_stmt. I decided to
give an error if we see an invalid usage of posix_memalign, since
other code (e.g. alias machinery) assumes correct arguments as well.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
I don't think you can give errors here. Note that the appropriate
way to do the check is to simply use
Yeah, because the weirdo call is only undefined if it's reached at runtime,
right.
if (gimple_builtin_call_types_compatible_p (stmt, decl))
Nice, dunno how could I not find that.
not lowering in case it's not compatible is ok.
In that case I also need to check a place in tree-ssa-alias.c.
Bootstrapped/regtested on x86_64-linux, ok for trunk and 5?
Please instead change the tree-ssa-alias.c code to do
if (callee != NULL
gimple_call_builtin_p (call, BUILT_IN_NORMAL))
switch (DECL_FUNCTION_CODE (callee))
...
which should also fix quite a few issues in the other builtin handlings.
Likewise can you change stmt_kills_ref_p and ref_maybe_used_by_call_p_1
in a similar way?
Thanks,
Richard.
2015-08-18 Marek Polacek pola...@redhat.com
PR middle-end/67222
* gimple-low.c (lower_stmt): Check the posix_memalign call.
* tree-ssa-alias.c (call_may_clobber_ref_p_1): Likewise.
* gcc.dg/torture/pr67222.c: New test.
diff --git gcc/gimple-low.c gcc/gimple-low.c
index d4697e2..4eae3a0 100644
--- gcc/gimple-low.c
+++ gcc/gimple-low.c
@@ -346,7 +346,8 @@ lower_stmt (gimple_stmt_iterator *gsi, struct lower_data
*data)
return;
}
else if (DECL_FUNCTION_CODE (decl) == BUILT_IN_POSIX_MEMALIGN
- flag_tree_bit_ccp)
+ flag_tree_bit_ccp
+ gimple_builtin_call_types_compatible_p (stmt, decl))
{
lower_builtin_posix_memalign (gsi);
return;
diff --git gcc/testsuite/gcc.dg/torture/pr67222.c
gcc/testsuite/gcc.dg/torture/pr67222.c
index e69de29..739f869 100644
--- gcc/testsuite/gcc.dg/torture/pr67222.c
+++ gcc/testsuite/gcc.dg/torture/pr67222.c
@@ -0,0 +1,19 @@
+/* PR middle-end/67222 */
+/* { dg-do compile } */
+
+void
+foo (void **p)
+{
+ posix_memalign (); /* { dg-warning implicit declaration } */
+ posix_memalign (p);
+ posix_memalign (0);
+ posix_memalign (p, 1);
+ posix_memalign (p, foo);
+ posix_memalign (gnu, gcc);
+ posix_memalign (1, p);
+ posix_memalign (1, 2);
+ posix_memalign (1, 2, 3);
+ posix_memalign (p, p, p);
+ posix_memalign (p, qui, 3);
+ posix_memalign (p, 1, 2);
+}
diff --git gcc/tree-ssa-alias.c gcc/tree-ssa-alias.c
index e103220..e96a00c 100644
--- gcc/tree-ssa-alias.c
+++ gcc/tree-ssa-alias.c
@@ -2039,6 +2039,10 @@ call_may_clobber_ref_p_1 (gcall *call, ao_ref *ref)
by its first argument. */
case BUILT_IN_POSIX_MEMALIGN:
{
+ /* For weirdo calls we cannot say much so stay conservative. */
+ tree decl = gimple_call_fndecl (call);
+ if (!gimple_builtin_call_types_compatible_p (call, decl))
+ return true;
tree ptrptr = gimple_call_arg (call, 0);
ao_ref dref;
ao_ref_init_from_ptr_and_size (dref, ptrptr,
Marek
[Bug target/67254] On-stack memory regions with aligned attribute overlap on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67254 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Are you sure they are live at the same time? AFAIK when optimizing their lifetime is disjunct. Does it work when replicating the printf with 'reference' also before the one with 'data'?
Re: ira.c update_equiv_regs patch causes gcc/testsuite/gcc.target/arm/pr43920-2.c regression
On 31/07/15 12:04, Alex Velenko wrote: On 29/07/15 23:14, Jeff Law wrote: On 07/28/2015 12:18 PM, Alex Velenko wrote: On 21/04/15 06:27, Jeff Law wrote: On 04/20/2015 01:09 AM, Shiva Chen wrote: Hi, Jeff Thanks for your advice. can_replace_by.patch is the new patch to handle both cases. pr43920-2.c.244r.jump2.ori is the original jump2 rtl dump pr43920-2.c.244r.jump2.patch_can_replace_by is the jump2 rtl dump after patch can_replace_by.patch Could you help me to review the patch? Thanks. This looks pretty good. I expanded the comment for the new function a bit and renamed the function in an effort to clarify its purpose. From reviewing can_replace_by, it seems it should have been handling this case, but clearly wasn't due to implementation details. I then bootstrapped and regression tested the patch on x86_64-linux-gnu where it passed. I also instrumented that compiler to see how often this code triggers. During a bootstrap it triggers a couple hundred times (which is obviously a proxy for cross jumping improvements). So it's triggering regularly on x86_64, which is good. I also verified that this fixes BZ64916 for an arm-non-eabi toolchain configured with --with-arch=armv7. Installed on the trunk. No new testcase as it's covered by existing tests. Thanks,, jeff Hi, I see this patch been committed in r56 on trunk. Is it okay to port this to fsf-5? It's not a regression, so backporting it would be generally frowned upon. If you feel strongly about it, you should ask Jakub, Joseph or Richi (the release managers) for an exception to the general policy. jeff Hi Jakub, Can this commit be ported to fsf-5? It fixed gcc.target/arm/pr43920-2.c at the time, so I think it is a good idea to port. Please, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64916 Kind regards, Alex Ping! Currently this test is passed on fsf-trunk, but not passed on fsf-5, so I think it is a regression on fsf-5: arm-none-eabi fsf-5: PASS: gcc.target/arm/pr43920-2.c (test for excess errors) FAIL: gcc.target/arm/pr43920-2.c scan-assembler-times pop 2 PASS: gcc.target/arm/pr43920-2.c scan-assembler-times beq 3 Executing on host: arm-none-eabi-size pr43920-2.o (timeout = 300) spawn arm-none-eabi-size pr43920-2.o text databssdechexfilename 58 0 0 58 3apr43920-2.o text size is 58 FAIL: gcc.target/arm/pr43920-2.c object-size text = 54 arm-none-eabi fsf-trunk: PASS: gcc.target/arm/pr43920-2.c (test for excess errors) PASS: gcc.target/arm/pr43920-2.c scan-assembler-times pop 2 PASS: gcc.target/arm/pr43920-2.c scan-assembler-times beq 3 size is arm-none-eabi-size Executing on host: arm-none-eabi-size pr43920-2.o (timeout = 300) spawn arm-none-eabi-size pr43920-2.o text databssdechexfilename 54 0 0 54 36pr43920-2.o text size is 54 PASS: gcc.target/arm/pr43920-2.c object-size text = 54 Can this, please, be ported? Kind regards, Alex
Re: ira.c update_equiv_regs patch causes gcc/testsuite/gcc.target/arm/pr43920-2.c regression
On 31/07/15 12:04, Alex Velenko wrote: On 29/07/15 23:14, Jeff Law wrote: On 07/28/2015 12:18 PM, Alex Velenko wrote: On 21/04/15 06:27, Jeff Law wrote: On 04/20/2015 01:09 AM, Shiva Chen wrote: Hi, Jeff Thanks for your advice. can_replace_by.patch is the new patch to handle both cases. pr43920-2.c.244r.jump2.ori is the original jump2 rtl dump pr43920-2.c.244r.jump2.patch_can_replace_by is the jump2 rtl dump after patch can_replace_by.patch Could you help me to review the patch? Thanks. This looks pretty good. I expanded the comment for the new function a bit and renamed the function in an effort to clarify its purpose. From reviewing can_replace_by, it seems it should have been handling this case, but clearly wasn't due to implementation details. I then bootstrapped and regression tested the patch on x86_64-linux-gnu where it passed. I also instrumented that compiler to see how often this code triggers. During a bootstrap it triggers a couple hundred times (which is obviously a proxy for cross jumping improvements). So it's triggering regularly on x86_64, which is good. I also verified that this fixes BZ64916 for an arm-non-eabi toolchain configured with --with-arch=armv7. Installed on the trunk. No new testcase as it's covered by existing tests. Thanks,, jeff Hi, I see this patch been committed in r56 on trunk. Is it okay to port this to fsf-5? It's not a regression, so backporting it would be generally frowned upon. If you feel strongly about it, you should ask Jakub, Joseph or Richi (the release managers) for an exception to the general policy. jeff Hi Jakub, Can this commit be ported to fsf-5? It fixed gcc.target/arm/pr43920-2.c at the time, so I think it is a good idea to port. Please, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64916 Kind regards, Alex Ping! Currently this test is passed on fsf-trunk, but not passed on fsf-5, so I think it is a regression on fsf-5: arm-none-eabi fsf-5: PASS: gcc.target/arm/pr43920-2.c (test for excess errors) FAIL: gcc.target/arm/pr43920-2.c scan-assembler-times pop 2 PASS: gcc.target/arm/pr43920-2.c scan-assembler-times beq 3 Executing on host: arm-none-eabi-size pr43920-2.o (timeout = 300) spawn arm-none-eabi-size pr43920-2.o text databssdechexfilename 58 0 0 58 3apr43920-2.o text size is 58 FAIL: gcc.target/arm/pr43920-2.c object-size text = 54 arm-none-eabi fsf-trunk: PASS: gcc.target/arm/pr43920-2.c (test for excess errors) PASS: gcc.target/arm/pr43920-2.c scan-assembler-times pop 2 PASS: gcc.target/arm/pr43920-2.c scan-assembler-times beq 3 size is arm-none-eabi-size Executing on host: arm-none-eabi-size pr43920-2.o (timeout = 300) spawn arm-none-eabi-size pr43920-2.o text databssdechexfilename 54 0 0 54 36pr43920-2.o text size is 54 PASS: gcc.target/arm/pr43920-2.c object-size text = 54 Can this, please, be ported? Kind regards, Alex
[Bug c/63336] cilkplus array notation ICE in find_rank
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63336 --- Comment #3 from Marc barnabe.marc at gmail dot com --- Created attachment 36197 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36197action=edit GCC 5.2 preprocessed ICE code xz file, because .ii is 2 MB in size.
Re: ira.c update_equiv_regs patch causes gcc/testsuite/gcc.target/arm/pr43920-2.c regression
On 18 August 2015 at 10:25, Alex Velenko alex.vele...@arm.com wrote: On 31/07/15 12:04, Alex Velenko wrote: On 29/07/15 23:14, Jeff Law wrote: On 07/28/2015 12:18 PM, Alex Velenko wrote: On 21/04/15 06:27, Jeff Law wrote: On 04/20/2015 01:09 AM, Shiva Chen wrote: Hi, Jeff Thanks for your advice. can_replace_by.patch is the new patch to handle both cases. pr43920-2.c.244r.jump2.ori is the original jump2 rtl dump pr43920-2.c.244r.jump2.patch_can_replace_by is the jump2 rtl dump after patch can_replace_by.patch Could you help me to review the patch? Thanks. This looks pretty good. I expanded the comment for the new function a bit and renamed the function in an effort to clarify its purpose. From reviewing can_replace_by, it seems it should have been handling this case, but clearly wasn't due to implementation details. I then bootstrapped and regression tested the patch on x86_64-linux-gnu where it passed. I also instrumented that compiler to see how often this code triggers. During a bootstrap it triggers a couple hundred times (which is obviously a proxy for cross jumping improvements). So it's triggering regularly on x86_64, which is good. I also verified that this fixes BZ64916 for an arm-non-eabi toolchain configured with --with-arch=armv7. Installed on the trunk. No new testcase as it's covered by existing tests. Thanks,, jeff Hi, I see this patch been committed in r56 on trunk. Is it okay to port this to fsf-5? It's not a regression, so backporting it would be generally frowned upon. If you feel strongly about it, you should ask Jakub, Joseph or Richi (the release managers) for an exception to the general policy. jeff Hi Jakub, Can this commit be ported to fsf-5? It fixed gcc.target/arm/pr43920-2.c at the time, so I think it is a good idea to port. Please, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64916 Kind regards, Alex Ping! Currently this test is passed on fsf-trunk, but not passed on fsf-5, so I think it is a regression on fsf-5: That does not make it a regression, it is only a regression if a version prior to 5 passes, how does this test behave on 4.9? Cheers /Marcus
Re: ira.c update_equiv_regs patch causes gcc/testsuite/gcc.target/arm/pr43920-2.c regression
On 18 August 2015 at 10:25, Alex Velenko alex.vele...@arm.com wrote: On 31/07/15 12:04, Alex Velenko wrote: On 29/07/15 23:14, Jeff Law wrote: On 07/28/2015 12:18 PM, Alex Velenko wrote: On 21/04/15 06:27, Jeff Law wrote: On 04/20/2015 01:09 AM, Shiva Chen wrote: Hi, Jeff Thanks for your advice. can_replace_by.patch is the new patch to handle both cases. pr43920-2.c.244r.jump2.ori is the original jump2 rtl dump pr43920-2.c.244r.jump2.patch_can_replace_by is the jump2 rtl dump after patch can_replace_by.patch Could you help me to review the patch? Thanks. This looks pretty good. I expanded the comment for the new function a bit and renamed the function in an effort to clarify its purpose. From reviewing can_replace_by, it seems it should have been handling this case, but clearly wasn't due to implementation details. I then bootstrapped and regression tested the patch on x86_64-linux-gnu where it passed. I also instrumented that compiler to see how often this code triggers. During a bootstrap it triggers a couple hundred times (which is obviously a proxy for cross jumping improvements). So it's triggering regularly on x86_64, which is good. I also verified that this fixes BZ64916 for an arm-non-eabi toolchain configured with --with-arch=armv7. Installed on the trunk. No new testcase as it's covered by existing tests. Thanks,, jeff Hi, I see this patch been committed in r56 on trunk. Is it okay to port this to fsf-5? It's not a regression, so backporting it would be generally frowned upon. If you feel strongly about it, you should ask Jakub, Joseph or Richi (the release managers) for an exception to the general policy. jeff Hi Jakub, Can this commit be ported to fsf-5? It fixed gcc.target/arm/pr43920-2.c at the time, so I think it is a good idea to port. Please, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64916 Kind regards, Alex Ping! Currently this test is passed on fsf-trunk, but not passed on fsf-5, so I think it is a regression on fsf-5: That does not make it a regression, it is only a regression if a version prior to 5 passes, how does this test behave on 4.9? Cheers /Marcus
[Scalar masks 5/x] Bool patterns
Hi,
This patch adds few changes into existing bool patterns in case scalar masks
are used:
- for scalar masks we don't need comparison to be merged into cond expression
- when bool in converted into integer we don't need to convert all producers
and may just emit a single cond_expr instead
- to avoid unsupported (for now) masks packing and unpacking, operands for
cond_expr use type of a proper size and additional conversion is added if
required.
Thanks,
Ilya
--
2015-08-17 Ilya Enkovich enkovich@gmail.com
* tree-vect-patterns.c (search_type_for_mask): New.
(vect_recog_bool_pattern): When using scalar masks
don't transform whole bool chain, just use a single
cond instead.
diff --git a/gcc/tree-vect-patterns.c b/gcc/tree-vect-patterns.c
index bc3117d..38cd3c0 100644
--- a/gcc/tree-vect-patterns.c
+++ b/gcc/tree-vect-patterns.c
@@ -3191,6 +3191,75 @@ adjust_bool_pattern (tree var, tree out_type, tree
trueval,
}
+/* Try to determine a proper type for converting bool VAR
+ into an integer value. The type is chosen so that
+ conversion has the same number of elements as a mask
+ producer. */
+
+static tree
+search_type_for_mask (tree var, loop_vec_info loop_vinfo, bb_vec_info bb_vinfo)
+{
+ gimple def_stmt;
+ enum vect_def_type dt;
+ tree def, rhs1;
+ enum tree_code rhs_code;
+ tree res = NULL;
+
+ if (TREE_CODE (var) != SSA_NAME)
+return NULL;
+
+ if ((TYPE_PRECISION (TREE_TYPE (var)) != 1
+ || !TYPE_UNSIGNED (TREE_TYPE (var)))
+ TREE_CODE (TREE_TYPE (var)) != BOOLEAN_TYPE)
+return NULL;
+
+ if (!vect_is_simple_use (var, NULL, loop_vinfo, bb_vinfo, def_stmt, def,
+ dt))
+return NULL;
+
+ if (dt != vect_internal_def)
+return NULL;
+
+ if (!is_gimple_assign (def_stmt))
+return NULL;
+
+ rhs_code = gimple_assign_rhs_code (def_stmt);
+ rhs1 = gimple_assign_rhs1 (def_stmt);
+
+ switch (rhs_code)
+{
+case SSA_NAME:
+case BIT_NOT_EXPR:
+CASE_CONVERT:
+ res = search_type_for_mask (rhs1, loop_vinfo, bb_vinfo);
+ break;
+
+case BIT_AND_EXPR:
+case BIT_IOR_EXPR:
+case BIT_XOR_EXPR:
+ if (!(res = search_type_for_mask (rhs1, loop_vinfo, bb_vinfo)))
+ res = search_type_for_mask (gimple_assign_rhs2 (def_stmt),
+ loop_vinfo, bb_vinfo);
+ break;
+
+default:
+ if (TREE_CODE_CLASS (rhs_code) == tcc_comparison)
+ {
+ if (TREE_CODE (TREE_TYPE (rhs1)) != INTEGER_TYPE
+ || !TYPE_UNSIGNED (TREE_TYPE (rhs1)))
+ {
+ machine_mode mode = TYPE_MODE (TREE_TYPE (rhs1));
+ res = build_nonstandard_integer_type (GET_MODE_BITSIZE (mode), 1);
+ }
+ else
+ res = TREE_TYPE (rhs1);
+ }
+}
+
+ return res;
+}
+
+
/* Function vect_recog_bool_pattern
Try to find pattern like following:
@@ -3248,6 +3317,7 @@ vect_recog_bool_pattern (vecgimple *stmts, tree
*type_in,
enum tree_code rhs_code;
tree var, lhs, rhs, vectype;
stmt_vec_info stmt_vinfo = vinfo_for_stmt (last_stmt);
+ stmt_vec_info new_stmt_info;
loop_vec_info loop_vinfo = STMT_VINFO_LOOP_VINFO (stmt_vinfo);
bb_vec_info bb_vinfo = STMT_VINFO_BB_VINFO (stmt_vinfo);
gimple pattern_stmt;
@@ -3273,27 +3343,56 @@ vect_recog_bool_pattern (vecgimple *stmts, tree
*type_in,
if (vectype == NULL_TREE)
return NULL;
- if (!check_bool_pattern (var, loop_vinfo, bb_vinfo))
- return NULL;
+ if (targetm.vectorize.use_scalar_mask_p ())
+ {
+ tree type = search_type_for_mask (var, loop_vinfo, bb_vinfo);
+ tree cst0, cst1;
- rhs = adjust_bool_pattern (var, TREE_TYPE (lhs), NULL_TREE, stmts);
- lhs = vect_recog_temp_ssa_var (TREE_TYPE (lhs), NULL);
- if (useless_type_conversion_p (TREE_TYPE (lhs), TREE_TYPE (rhs)))
- pattern_stmt = gimple_build_assign (lhs, SSA_NAME, rhs);
+ if (!type || TYPE_MODE (type) == TYPE_MODE (TREE_TYPE (lhs)))
+ type = TREE_TYPE (lhs);
+ cst0 = build_int_cst (type, 0);
+ cst1 = build_int_cst (type, 1);
+ lhs = vect_recog_temp_ssa_var (type, NULL);
+ pattern_stmt = gimple_build_assign (lhs, COND_EXPR, var, cst0, cst1);
+
+ if (!useless_type_conversion_p (type, TREE_TYPE (lhs)))
+ {
+ tree new_vectype = get_vectype_for_scalar_type (type);
+ new_stmt_info = new_stmt_vec_info (pattern_stmt, loop_vinfo,
+bb_vinfo);
+ set_vinfo_for_stmt (pattern_stmt, new_stmt_info);
+ STMT_VINFO_VECTYPE (new_stmt_info) = new_vectype;
+ new_pattern_def_seq (stmt_vinfo, pattern_stmt);
+
+ rhs = lhs;
+ lhs = vect_recog_temp_ssa_var (TREE_TYPE (lhs), NULL);
+ pattern_stmt = gimple_build_assign (lhs, CONVERT_EXPR, rhs);
+ }
+ }
else
- pattern_stmt
-
Re: Move some flag_unsafe_math_optimizations using simplify and match
On Mon, Aug 17, 2015 at 7:24 AM, Hurugalawadi, Naveen
naveen.hurugalaw...@caviumnetworks.com wrote:
Hi,
Please find attached the modified patch as per the comments.
Tested the patch on AArch64 and X86 without any regressions.
The other hunks of the earlier patch have been removed as per the earlier
comments due to failure in regressions.
Investigated those issues and found that its because of Double and Float
patterns.
Could not deduce why the double and float patterns FAIL though.
fold_builtin_cos/cosh can be reduced to constant folding, thus
remove their fold_strip_sign_nops () path.
Had removed them but the double and float patterns does not generate the
optimizations and hence had to retain them
Please let me know why the double and float patterns are failing.
I could work on those and try to move all other patterns using
simplify and match.
Can you point me to which patterns exhibit this behavior? I guess
you mean 'long double' and 'float' variants, not 'double' variants?
The testcase for these pattern optimizations are present.
Please let me know whether we would need a separate check so that I
can add them.
In your new patch I see
+ /* Simplify sqrt(x) * sqrt(x) - x. */
+ (simplify
+ (mult:c (SQRT (SQRT@1 @0)) @1)
+ (if (!HONOR_SNANS (type))
+ @0))
which looks like a typo - it matches (sqrt (sqrt (x)) * sqrt (x). You want
(mult (SQRT@1 @0) @1)
also note there is no need for the :c here.
For cases like
+ /* Simplify tan(x) * cos(x) - sin(x). */
+ (simplify
+ (mult:c (TAN:s @0) (COS:s @0))
+ (SIN @0))
you can run into the issue that the program does not use sinf() and thus
the compiler refuses to generate it (but the fold-const.c has the same issue,
so it shouldn't regress). Not sure if that is your issue with long
double / float
variants.
+ /* Simplify pow(x,c) / x - pow(x,c-1). */
+ (simplify
+ (rdiv (POW @0 @1) @0)
:s missing on the POW
+ (if (TREE_CODE (@1) == REAL_CST
+!TREE_OVERFLOW (@1))
+ (POW @0 (minus @1 { build_one_cst (type); }
please use
(simplify
(rdiv (POW @0 REAL_CST@1) @0)
(if (!TREE_OVERFLOW (@1))
...
here and in other cases where you restrict one operand to a constant.
That results in more efficient code.
+ /* Simplify a/root(b/c) into a*root(c/b). */
+ (simplify
+ (rdiv @0 (SQRT (rdiv @1 @2)))
:s missing on the SQRT and the rdiv
+ (mult @0 (SQRT (rdiv @2 @1
+ /* Simplify x / pow (y,z) - x * pow(y,-z). */
+ (simplify
+ (rdiv @0 (POW @1 @2))
:s missing on the POW.
+ (mult @0 (POW @1 (negate @2
Otherwise the new patch looks ok to me.
Thanks,
Richard.
Thanks,
Naveen
ChangeLog
2015-08-17 Naveen H.S naveen.hurugalaw...@caviumnetworks.com
PR middle-end/16107
* fold-const.c (fold_binary_loc) : Move Optimize tan(x)*cos(x) as
sin(x) to match.pd.
Move Optimize x*pow(x,c) as pow(x,c+1) to match.pd.
Move Optimize pow(x,c)*x as pow(x,c+1) to match.pd.
Move Optimize sin(x)/cos(x) as tan(x) to match.pd.
Move Optimize cos(x)/sin(x) as 1.0/tan(x) to match.pd.
Move Optimize sin(x)/tan(x) as cos(x) to match.pd.
Move Optimize tan(x)/sin(x) as 1.0/cos(x) to match.pd.
Move Optimize pow(x,c)/x as pow(x,c-1) to match.pd.
Move Optimize x/pow(y,z) into x*pow(y,-z) to match.pd.
* match.pd (SIN ) : New Operator.
(TAN) : New Operator.
(mult:c (SQRT (SQRT@1 @0)) @1) : New simplifier.
(mult (POW:s @0 @1) (POW:s @2 @1))
(mult:c (TAN:s @0) (COS:s @0))
(mult:c @0 (POW @0 @1))
(rdiv (SIN:s @0) (COS:s @0))
(rdiv (COS:s @0) (SIN:s @0))
(rdiv (SIN:s @0) (TAN:s @0))
(rdiv (TAN:s @0) (SIN:s @0))
(rdiv (POW @0 @1) @0)
(rdiv @0 (SQRT (rdiv @1 @2)))
(rdiv @0 (POW @1 @2))
Re: [PATCH] Add extensions to dwarf2.def
On 08/18/2015 11:36 AM, Manuel López-Ibáñez wrote: On 18/08/15 10:32, Pedro Alves wrote: On 08/14/2015 10:49 AM, Pierre-Marie de Rodat wrote: I also tried to create the new pages on the wiki but it says You are not allowed to edit this page. (https://gcc.gnu.org/wiki/DW_AT_GNU_numerator_denominator?action=edit, I'm logged in as pmderodat). Does anyone know how I should proceed? I believe you need to be added to the editor group: https://gcc.gnu.org/wiki/EditorGroup You need someone on that list to add you. (I'm not on the list). Added. Please try now. I successfuly created the two wiki pages, thanks to both of you! As a side note, for some reason I could no longer login and I had to re-create my account (same identifier, which worked). I'm not sure, but I think it's the second time I had to do that (the first time I thought I did something wrong...). -- Pierre-Marie de Rodat
Re: [PATCH] Fix ICE with bogus posix_memalign call (PR middle-end/67222)
On Tue, Aug 18, 2015 at 10:47:44AM +0200, Richard Biener wrote:
On Mon, Aug 17, 2015 at 8:01 PM, Marek Polacek pola...@redhat.com wrote:
Here we were crashing on an invalid call to posix_memalign. The code in
lower_builtin_posix_memalign assumed that the call had valid arguments.
The reason the C FE doesn't reject this code is, in short, that
int T () is compatible with int T (void **, size_t, size_t) and we
use the former -- so convert_arguments doesn't complain.
So I think let's validate the arguments in lower_stmt. I decided to
give an error if we see an invalid usage of posix_memalign, since
other code (e.g. alias machinery) assumes correct arguments as well.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
I don't think you can give errors here. Note that the appropriate
way to do the check is to simply use
Yeah, because the weirdo call is only undefined if it's reached at runtime,
right.
if (gimple_builtin_call_types_compatible_p (stmt, decl))
Nice, dunno how could I not find that.
not lowering in case it's not compatible is ok.
In that case I also need to check a place in tree-ssa-alias.c.
Bootstrapped/regtested on x86_64-linux, ok for trunk and 5?
2015-08-18 Marek Polacek pola...@redhat.com
PR middle-end/67222
* gimple-low.c (lower_stmt): Check the posix_memalign call.
* tree-ssa-alias.c (call_may_clobber_ref_p_1): Likewise.
* gcc.dg/torture/pr67222.c: New test.
diff --git gcc/gimple-low.c gcc/gimple-low.c
index d4697e2..4eae3a0 100644
--- gcc/gimple-low.c
+++ gcc/gimple-low.c
@@ -346,7 +346,8 @@ lower_stmt (gimple_stmt_iterator *gsi, struct lower_data
*data)
return;
}
else if (DECL_FUNCTION_CODE (decl) == BUILT_IN_POSIX_MEMALIGN
- flag_tree_bit_ccp)
+ flag_tree_bit_ccp
+ gimple_builtin_call_types_compatible_p (stmt, decl))
{
lower_builtin_posix_memalign (gsi);
return;
diff --git gcc/testsuite/gcc.dg/torture/pr67222.c
gcc/testsuite/gcc.dg/torture/pr67222.c
index e69de29..739f869 100644
--- gcc/testsuite/gcc.dg/torture/pr67222.c
+++ gcc/testsuite/gcc.dg/torture/pr67222.c
@@ -0,0 +1,19 @@
+/* PR middle-end/67222 */
+/* { dg-do compile } */
+
+void
+foo (void **p)
+{
+ posix_memalign (); /* { dg-warning implicit declaration } */
+ posix_memalign (p);
+ posix_memalign (0);
+ posix_memalign (p, 1);
+ posix_memalign (p, foo);
+ posix_memalign (gnu, gcc);
+ posix_memalign (1, p);
+ posix_memalign (1, 2);
+ posix_memalign (1, 2, 3);
+ posix_memalign (p, p, p);
+ posix_memalign (p, qui, 3);
+ posix_memalign (p, 1, 2);
+}
diff --git gcc/tree-ssa-alias.c gcc/tree-ssa-alias.c
index e103220..e96a00c 100644
--- gcc/tree-ssa-alias.c
+++ gcc/tree-ssa-alias.c
@@ -2039,6 +2039,10 @@ call_may_clobber_ref_p_1 (gcall *call, ao_ref *ref)
by its first argument. */
case BUILT_IN_POSIX_MEMALIGN:
{
+ /* For weirdo calls we cannot say much so stay conservative. */
+ tree decl = gimple_call_fndecl (call);
+ if (!gimple_builtin_call_types_compatible_p (call, decl))
+ return true;
tree ptrptr = gimple_call_arg (call, 0);
ao_ref dref;
ao_ref_init_from_ptr_and_size (dref, ptrptr,
Marek
[Bug fortran/67250] gfortran does not faithfully preprocess the way cpp does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67250 --- Comment #9 from Jeff Hammond jeff.science at gmail dot com --- First, you will not accept the fusion of cpp+gfortran behavior as a feature request? Is there a reason other than you do not want to do it because you are already busy? Second, true, but that doesn't stop gcc from supporting inline assembly outside of ISO C11, or stop gfortran from being compatible with vendor implementations of https://gcc.gnu.org/onlinedocs/gfortran/Cray-pointers.html, or of supporting any number of other non-standard features. In short, it's not in the standard, therefore it's fine to break user experience seems pretty weak here. It's fine if you tell me that you do not care about my needs and will not implement it, but please don't use ISO as the excuse.
Re: [Aarch64] Adjust tests to take LSE extension into account.
On 18 August 2015 at 09:51, Matthew Wahab matthew.wa...@foss.arm.com wrote: gcc/testsuite 2015-08-18 Matthew Wahab matthew.wa...@arm.com * gcc.target/aarch64/atomic-comp-swap-release-acquire.c: Adjust dg-options to disable LSE extensions. * gcc.target/aarch64/atomic-op-acq_rel.c: Likewise. * gcc.target/aarch64/atomic-op-acquire.c: Likewise. * gcc.target/aarch64/atomic-op-char.c: Likewise. * gcc.target/aarch64/atomic-op-consume.c: Likewise. * gcc.target/aarch64/atomic-op-imm.c: Likewise. * gcc.target/aarch64/atomic-op-int.c: Likewise. * gcc.target/aarch64/atomic-op-long.c: Likewise. * gcc.target/aarch64/atomic-op-relaxed.c: Likewise. * gcc.target/aarch64/atomic-op-seq_cst.c: Likewise. * gcc.target/aarch64/atomic-op-release.c: Likewise. * gcc.target/aarch64/atomic-op-short.c: Likewise. * gcc.target/aarch64/sync-comp-swap.c: Likewise. * gcc.target/aarch64/sync-op-acquire.c: Likewise. * gcc.target/aarch64/sync-op-full.c: Likewise. * gcc.target/aarch64/sync-op-release.c: Likewise. OK /Marcus
[Bug fortran/28662] fpp call of gfortran: -traditional-cpp versus newer macros like #x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28662 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||jeff.science at gmail dot com --- Comment #11 from Manuel López-Ibáñez manu at gcc dot gnu.org --- *** Bug 67250 has been marked as a duplicate of this bug. ***
[Bug fortran/67250] gfortran does not faithfully preprocess the way cpp does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67250 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org Resolution|WONTFIX |DUPLICATE --- Comment #12 from Manuel López-Ibáñez manu at gcc dot gnu.org --- Hi Jeff, I think Steve and Andrew are just explaining why it works this way and why it is not possible to change the default behavior. Calling this a bug is not fair, because it works as intended and documented. Of course, it may be possible to implement a different behavior under a new command-line option, but that would require someone to do all the work required to get this implemented. In fact, there has been such work going on but progress has been slow (see PR28662). You could offer your help to Tobias (https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps). People who are already happy with the current behavior are not likely to do it for you. *** This bug has been marked as a duplicate of bug 28662 ***
Re: [RFC][Scalar masks 1/x] Introduce GEN_MASK_EXPR.
On Mon, Aug 17, 2015 at 6:22 PM, Ilya Enkovich enkovich@gmail.com wrote: Hi, This patch starts a series introducing scalar masks support in the vectorizer. It was discussed on the recent Cauldron and changes overiew is available here: https://gcc.gnu.org/wiki/cauldron2015?action=AttachFiledo=viewtarget=Vectorization+for+Intel+AVX-512.pdf. Here is shortly a list of changes introduced by this series: - Add new tree expr to produce scalar masks in a vectorized code - Fix-up if-conversion to use bool predicates instead of integer masks - Disable some bool patterns to avoid bool to int conversion where masks can be used - Support bool operands in vectorization factor computation - Support scalar masks in MASK_LOAD, MASK_STORE and VEC_COND_EXPR by adding new optabs - Support vectorization for statements which are now not transformed by bool patterns - Add target support (hooks, optabs, expands) This patch introduces GEN_MASK_EXPR code. Intitially I wanted to use a comparison as an operand for it directly mapping it into AVX-512 comparison instruction. But a feedback was to simplify new code's semantics and use it for converting vectors into scalar masks. Therefore if we want to compare two vectors into a scalar masks we use two statements: vect.18_87 = vect__5.13_81 vect__6.16_86; mask__ifc__23.17_88 = GEN_MASK vect.18_87; Trying it in practice I found it producing worse code. The problem is that on target first comparison is expanded into two instructions: cmp with mask result + masked move to get a vector. GEN_MASK is then expanded into another comparison with zero vector. Thus I get two comparisons + move instead of a single comparison and have to optimize this out on a target side (current optimizers can't handle it). That's actually what I wanted to avoid. For now I changed GEN_MASK_EXPR to get a vector value as an operand but didn't change expand pattern which has four opernads: two vectors to compare + cmp operator + result. On expand I try to detect GEN_MASK uses a result of comparison and thus avoid double comparison generation. Patch series is not actually fully finished yet. I still have several type conversion tests not being vectorized and it wasn't widely tested. That's what I'm working on now. Will be glad to any comments. You need to expand the documentation of GEN_MASK_EXPR to say something about which bits correspond to which vector elements. You also should add constant-folding of GEN_MASK_EXPR to const_unop in fold-const.c (which would also document the above). I agree that you need to combine the two GIMPLE stmts at expand time. How do intrinsics expose those masks btw? One other idea that crossed my mind is that we might want to support vectorbool and map that to an integer mode thus effectively allowing vect1 vect2 generating a vectorbool directly. But I'm not sure what kind of issues you run into with that approach. Thanks, Ilya -- 2015-08-17 Ilya Enkovich enkovich@gmail.com * expr.c (expand_expr_real_2): Support GEN_MASK_EXPR. * gimple-pretty-print.c (dump_unary_rhs): Likewise. * gimple.c (get_gimple_rhs_num_ops): Likewise. * optabs.c: Include gimple.h. (vector_compare_rtx): Add OPNO arg. (get_gen_mask_icode): New. (expand_gen_mask_expr_p): New. (expand_gen_mask_expr): New. (expand_vec_cond_expr): Adjust vector_compare_rtx call. * optabs.def (gen_mask_optab): New. (gen_masku_optab): New. * optabs.h (expand_gen_mask_expr_p): New. (expand_gen_mask_expr): New. * tree-cfg.c (verify_gimple_assign_unary): Support GEN_MASK_EXPR. * tree-inline.c (estimate_operator_cost): Likewise. * tree-pretty-print.c (dump_generic_node): Likewise. * tree-ssa-operands.c (get_expr_operands): Likewise. * tree.def (GEN_MASK_EXPR): New. diff --git a/gcc/expr.c b/gcc/expr.c index 31b4573..8af5926 100644 --- a/gcc/expr.c +++ b/gcc/expr.c @@ -9180,6 +9180,10 @@ expand_expr_real_2 (sepops ops, rtx target, machine_mode tmode, return temp; } +case GEN_MASK_EXPR: + target = expand_gen_mask_expr (type, treeop0, target); + return target; + case VEC_COND_EXPR: target = expand_vec_cond_expr (type, treeop0, treeop1, treeop2, target); return target; diff --git a/gcc/gimple-pretty-print.c b/gcc/gimple-pretty-print.c index 53900dd..ac25b79 100644 --- a/gcc/gimple-pretty-print.c +++ b/gcc/gimple-pretty-print.c @@ -300,6 +300,12 @@ dump_unary_rhs (pretty_printer *buffer, gassign *gs, int spc, int flags) pp_greater (buffer); break; +case GEN_MASK_EXPR: + pp_string (buffer, GEN_MASK ); + dump_generic_node (buffer, rhs, spc, flags, false); + pp_greater (buffer); + break; + default: if (TREE_CODE_CLASS (rhs_code) == tcc_declaration
[Bug c/63336] cilkplus array notation ICE in find_rank
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63336 Marc barnabe.marc at gmail dot com changed: What|Removed |Added CC||barnabe.marc at gmail dot com --- Comment #2 from Marc barnabe.marc at gmail dot com --- Same thing in GCC 5.2 Using built-in specs. COLLECT_GCC=./../../miscTools/gcc/bin/g++ COLLECT_LTO_WRAPPER=/media/lingsrv/exp//miscTools/gcc/libexec/gcc/x86_64-unknown-linux-gnu/5.2.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ./configure --prefix=/media/lingsrv/exp//miscTools/gcc --with-gmp=/media/lingsrv/exp/mbarnabe/miscTools/gmp_install/ --with-mpc=/media/lingsrv/exp//miscTools/mpc_install/ --with-mpfr=/media/lingsrv/exp//miscTools/mpfr_install/ Thread model: posix gcc version 5.2.0 (GCC) uname -a Linux technolin01 3.2.0-4-amd64 #1 SMP Debian 3.2.57-3 x86_64 GNU/Linux CFLAGS = -D WEIGHTTYPE=float -lm -D THREAD -O2 -Wall -ffast-math -fcilkplus -std=c++11 rnnlmlib.cpp:1115:1: internal compiler error: in find_rank, at c-family/array-notation-common.c:244 } ^ 0x74d4bc find_rank(unsigned int, tree_node*, tree_node*, bool, unsigned long*) ../.././gcc/c-family/array-notation-common.c:244 0x74d118 find_rank(unsigned int, tree_node*, tree_node*, bool, unsigned long*) ../.././gcc/c-family/array-notation-common.c:317 0x74d118 find_rank(unsigned int, tree_node*, tree_node*, bool, unsigned long*) ../.././gcc/c-family/array-notation-common.c:317 0x74d118 find_rank(unsigned int, tree_node*, tree_node*, bool, unsigned long*) ../.././gcc/c-family/array-notation-common.c:317 0x74d118 find_rank(unsigned int, tree_node*, tree_node*, bool, unsigned long*) ../.././gcc/c-family/array-notation-common.c:317 0x6f37de cp_expand_cond_array_notations ../.././gcc/cp/cp-array-notation.c:852 0x6f541f expand_array_notation_exprs(tree_node*) ../.././gcc/cp/cp-array-notation.c:1292 0x6f52e8 expand_array_notation_exprs(tree_node*) ../.././gcc/cp/cp-array-notation.c:1212 0x6f5633 expand_array_notation_exprs(tree_node*) ../.././gcc/cp/cp-array-notation.c:1185 0x6f5633 expand_array_notation_exprs(tree_node*) ../.././gcc/cp/cp-array-notation.c:1185 0x6f071f cp_genericize(tree_node*) ../.././gcc/cp/cp-gimplify.c:1406 0x60d75a finish_function(int) ../.././gcc/cp/decl.c:14328 0x6800e5 cp_parser_function_definition_after_declarator ../.././gcc/cp/parser.c:23527 0x680fe0 cp_parser_function_definition_from_specifiers_and_declarator ../.././gcc/cp/parser.c:23433 0x680fe0 cp_parser_init_declarator ../.././gcc/cp/parser.c:17096 0x681dd3 cp_parser_simple_declaration ../.././gcc/cp/parser.c:11607 0x66a033 cp_parser_block_declaration ../.././gcc/cp/parser.c:11481 0x6641e9 cp_parser_declaration ../.././gcc/cp/parser.c:11378 0x68af3a cp_parser_declaration_seq_opt ../.././gcc/cp/parser.c:11264 0x68b24f cp_parser_translation_unit ../.././gcc/cp/parser.c:4100 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions.
Re: ira.c update_equiv_regs patch causes gcc/testsuite/gcc.target/arm/pr43920-2.c regression
On 18/08/15 10:45, Marcus Shawcroft wrote: On 18 August 2015 at 10:25, Alex Velenko alex.vele...@arm.com wrote: On 31/07/15 12:04, Alex Velenko wrote: On 29/07/15 23:14, Jeff Law wrote: On 07/28/2015 12:18 PM, Alex Velenko wrote: On 21/04/15 06:27, Jeff Law wrote: On 04/20/2015 01:09 AM, Shiva Chen wrote: Hi, Jeff Thanks for your advice. can_replace_by.patch is the new patch to handle both cases. pr43920-2.c.244r.jump2.ori is the original jump2 rtl dump pr43920-2.c.244r.jump2.patch_can_replace_by is the jump2 rtl dump after patch can_replace_by.patch Could you help me to review the patch? Thanks. This looks pretty good. I expanded the comment for the new function a bit and renamed the function in an effort to clarify its purpose. From reviewing can_replace_by, it seems it should have been handling this case, but clearly wasn't due to implementation details. I then bootstrapped and regression tested the patch on x86_64-linux-gnu where it passed. I also instrumented that compiler to see how often this code triggers. During a bootstrap it triggers a couple hundred times (which is obviously a proxy for cross jumping improvements). So it's triggering regularly on x86_64, which is good. I also verified that this fixes BZ64916 for an arm-non-eabi toolchain configured with --with-arch=armv7. Installed on the trunk. No new testcase as it's covered by existing tests. Thanks,, jeff Hi, I see this patch been committed in r56 on trunk. Is it okay to port this to fsf-5? It's not a regression, so backporting it would be generally frowned upon. If you feel strongly about it, you should ask Jakub, Joseph or Richi (the release managers) for an exception to the general policy. jeff Hi Jakub, Can this commit be ported to fsf-5? It fixed gcc.target/arm/pr43920-2.c at the time, so I think it is a good idea to port. Please, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64916 Kind regards, Alex Ping! Currently this test is passed on fsf-trunk, but not passed on fsf-5, so I think it is a regression on fsf-5: That does not make it a regression, it is only a regression if a version prior to 5 passes, how does this test behave on 4.9? Cheers /Marcus Hi Marcus, On fsf-4.9 I see the test pass: PASS: gcc.target/arm/pr43920-2.c (test for excess errors) PASS: gcc.target/arm/pr43920-2.c scan-assembler-times pop 2 PASS: gcc.target/arm/pr43920-2.c scan-assembler-times beq 3 Executing on host: arm-none-eabi-size pr43920-2.o (timeout = 300) spawn arm-none-eabi-size pr43920-2.o textdata bss dec hex filename 54 0 0 54 36 pr43920-2.o text size is 54 PASS: gcc.target/arm/pr43920-2.c object-size text = 54 So this is a regression in fsf-5. Kind regards, Alex
Re: ira.c update_equiv_regs patch causes gcc/testsuite/gcc.target/arm/pr43920-2.c regression
On 18/08/15 10:45, Marcus Shawcroft wrote: On 18 August 2015 at 10:25, Alex Velenko alex.vele...@arm.com wrote: On 31/07/15 12:04, Alex Velenko wrote: On 29/07/15 23:14, Jeff Law wrote: On 07/28/2015 12:18 PM, Alex Velenko wrote: On 21/04/15 06:27, Jeff Law wrote: On 04/20/2015 01:09 AM, Shiva Chen wrote: Hi, Jeff Thanks for your advice. can_replace_by.patch is the new patch to handle both cases. pr43920-2.c.244r.jump2.ori is the original jump2 rtl dump pr43920-2.c.244r.jump2.patch_can_replace_by is the jump2 rtl dump after patch can_replace_by.patch Could you help me to review the patch? Thanks. This looks pretty good. I expanded the comment for the new function a bit and renamed the function in an effort to clarify its purpose. From reviewing can_replace_by, it seems it should have been handling this case, but clearly wasn't due to implementation details. I then bootstrapped and regression tested the patch on x86_64-linux-gnu where it passed. I also instrumented that compiler to see how often this code triggers. During a bootstrap it triggers a couple hundred times (which is obviously a proxy for cross jumping improvements). So it's triggering regularly on x86_64, which is good. I also verified that this fixes BZ64916 for an arm-non-eabi toolchain configured with --with-arch=armv7. Installed on the trunk. No new testcase as it's covered by existing tests. Thanks,, jeff Hi, I see this patch been committed in r56 on trunk. Is it okay to port this to fsf-5? It's not a regression, so backporting it would be generally frowned upon. If you feel strongly about it, you should ask Jakub, Joseph or Richi (the release managers) for an exception to the general policy. jeff Hi Jakub, Can this commit be ported to fsf-5? It fixed gcc.target/arm/pr43920-2.c at the time, so I think it is a good idea to port. Please, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64916 Kind regards, Alex Ping! Currently this test is passed on fsf-trunk, but not passed on fsf-5, so I think it is a regression on fsf-5: That does not make it a regression, it is only a regression if a version prior to 5 passes, how does this test behave on 4.9? Cheers /Marcus Hi Marcus, On fsf-4.9 I see the test pass: PASS: gcc.target/arm/pr43920-2.c (test for excess errors) PASS: gcc.target/arm/pr43920-2.c scan-assembler-times pop 2 PASS: gcc.target/arm/pr43920-2.c scan-assembler-times beq 3 Executing on host: arm-none-eabi-size pr43920-2.o (timeout = 300) spawn arm-none-eabi-size pr43920-2.o textdata bss dec hex filename 54 0 0 54 36 pr43920-2.o text size is 54 PASS: gcc.target/arm/pr43920-2.c object-size text = 54 So this is a regression in fsf-5. Kind regards, Alex
Re: ira.c update_equiv_regs patch causes gcc/testsuite/gcc.target/arm/pr43920-2.c regression
On fsf-4.9 I see the test pass: PASS: gcc.target/arm/pr43920-2.c (test for excess errors) PASS: gcc.target/arm/pr43920-2.c scan-assembler-times pop 2 PASS: gcc.target/arm/pr43920-2.c scan-assembler-times beq 3 Executing on host: arm-none-eabi-size pr43920-2.o (timeout = 300) spawn arm-none-eabi-size pr43920-2.o text databssdechexfilename 54 0 0 54 36pr43920-2.o text size is 54 PASS: gcc.target/arm/pr43920-2.c object-size text = 54 So this is a regression in fsf-5. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64916#c3 regards Ramana Kind regards, Alex
Re: ira.c update_equiv_regs patch causes gcc/testsuite/gcc.target/arm/pr43920-2.c regression
On fsf-4.9 I see the test pass: PASS: gcc.target/arm/pr43920-2.c (test for excess errors) PASS: gcc.target/arm/pr43920-2.c scan-assembler-times pop 2 PASS: gcc.target/arm/pr43920-2.c scan-assembler-times beq 3 Executing on host: arm-none-eabi-size pr43920-2.o (timeout = 300) spawn arm-none-eabi-size pr43920-2.o text databssdechexfilename 54 0 0 54 36pr43920-2.o text size is 54 PASS: gcc.target/arm/pr43920-2.c object-size text = 54 So this is a regression in fsf-5. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64916#c3 regards Ramana Kind regards, Alex
[Bug c/67224] UTF-8 support for identifier names in GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67224 --- Comment #13 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Eric from comment #12) I'm glad to know people like Joseph are working on UTF-8 in gcc. I think at the moment, neither Joseph nor anyone else is planning to work on this. There doesn't seem to be sufficient demand for this feature so that companies fund it or volunteers step up to implement it (you are the first one to do an attempt that I am aware of). I spent a week adding UTF-8 input support to pcc. At that time Microsoft Studio and clang already supported UTF-8 input files and I expected that gcc would do so in the next release. Unfortunately, GCC has very few developers compared to Microsoft or Clang. Many things in GCC will never get done if new people do not contribute to its development. This is why if you want to see this feature, you are the best and perhaps the only person to make it happen. The problem is that this cannot be fixed by one-line patch, otherwise it would have been fixed a long time ago. * GCC cannot rely on libiconv being always present. It has to work with glibc's iconv, which is what is used in GNU/Linux. * Even if glibc's supported C99 conversion, this will break other things. * You need to add tests explicitly for various things (see Joseph's comments). The tests will be added to the GCC testsuite to prove that your patch works as it should and to make sure future changes do not break the tests. * At a minimum, look at all the gcc.dg/cpp/ucnid-*.c g++.dg/cpp/ucnid-*.c and see what happens if you replace the \uNNN with actual extended characters. * Joseph thinks that the best approach is to do the conversion from UTF-8 to UCNs manually within cpplib, such that you can handle all the corner cases of C/C++ (quoted strings, \µ, macro names,...)
[Scalar masks 6/x] Vectorize bool statements
Hi,
This patch adds vectorization for statements we can now get due to modified
bool patterns. Comparison is transformed into vector comparison +
GEN_MASK_EXPR. Other ops basically just get integer type.
Thanks,
Ilya
--
2015-08-17 Ilya Enkovich enkovich@gmail.com
* tree-vectorizer.h (vect_var_kind): Add vect_mask_var.
(stmt_vec_info_type): Add bool_op_vec_info_type and
comparison_vec_info_type.
* tree-vect-data-refs.c (vect_get_new_vect_var): Support
vect_mask_var.
(vect_create_destination_var): Likewise.
* tree-vect-stmts.c (vectorizable_bool_op): New.
(vectorizable_comparison): New.
(vect_analyze_stmt): Add vectorizable_bool_op and
vectorizable_comparison.
(vect_transform_stmt): Support comparison_vec_info_type and
bool_op_vec_info_type.
diff --git a/gcc/tree-vect-data-refs.c b/gcc/tree-vect-data-refs.c
index f1eaef4..a6a6311 100644
--- a/gcc/tree-vect-data-refs.c
+++ b/gcc/tree-vect-data-refs.c
@@ -3849,6 +3849,9 @@ vect_get_new_vect_var (tree type, enum vect_var_kind
var_kind, const char *name)
case vect_scalar_var:
prefix = stmp;
break;
+ case vect_mask_var:
+prefix = mask;
+break;
case vect_pointer_var:
prefix = vectp;
break;
@@ -4403,7 +4406,11 @@ vect_create_destination_var (tree scalar_dest, tree
vectype)
tree type;
enum vect_var_kind kind;
- kind = vectype ? vect_simple_var : vect_scalar_var;
+ kind = vectype
+? TREE_CODE (vectype) == VECTOR_TYPE
+? vect_simple_var
+: vect_mask_var
+: vect_scalar_var;
type = vectype ? vectype : TREE_TYPE (scalar_dest);
gcc_assert (TREE_CODE (scalar_dest) == SSA_NAME);
diff --git a/gcc/tree-vect-stmts.c b/gcc/tree-vect-stmts.c
index d0e0833..301b9e1 100644
--- a/gcc/tree-vect-stmts.c
+++ b/gcc/tree-vect-stmts.c
@@ -7454,6 +7454,478 @@ vectorizable_condition (gimple stmt,
gimple_stmt_iterator *gsi,
return true;
}
+/* vectorizable_bool_op.
+
+ Check if STMT is a logical expression which is vectorized into
+ a scalar mask manipulation statement.
+
+ Return FALSE if not a vectorizable STMT, TRUE otherwise. */
+
+bool
+vectorizable_bool_op (gimple stmt, gimple_stmt_iterator *gsi,
+ gimple *vec_stmt, tree reduc_def,
+ slp_tree slp_node)
+{
+ tree lhs, rhs1, rhs2;
+ stmt_vec_info stmt_info = vinfo_for_stmt (stmt);
+ tree vectype1, vectype2;
+ tree vectype = STMT_VINFO_VECTYPE (stmt_info);
+ tree vec_rhs1 = NULL_TREE, vec_rhs2 = NULL_TREE;
+ tree new_temp;
+ loop_vec_info loop_vinfo = STMT_VINFO_LOOP_VINFO (stmt_info);
+ tree def;
+ enum vect_def_type dt, dts[4];
+ int nunits;
+ int ncopies;
+ enum tree_code code;
+ stmt_vec_info prev_stmt_info = NULL;
+ int i, j;
+ bb_vec_info bb_vinfo = STMT_VINFO_BB_VINFO (stmt_info);
+ vectree vec_oprnds0 = vNULL;
+ vectree vec_oprnds1 = vNULL;
+ tree mask;
+
+ if (VECTOR_TYPE_P (vectype))
+return false;
+
+ nunits = TYPE_PRECISION (vectype);
+
+ if (slp_node || PURE_SLP_STMT (stmt_info))
+ncopies = 1;
+ else
+ncopies = LOOP_VINFO_VECT_FACTOR (loop_vinfo) / nunits;
+
+ gcc_assert (ncopies = 1);
+ if (!STMT_VINFO_RELEVANT_P (stmt_info) !bb_vinfo)
+return false;
+
+ if (STMT_VINFO_DEF_TYPE (stmt_info) != vect_internal_def
+ !(STMT_VINFO_DEF_TYPE (stmt_info) == vect_nested_cycle
+ reduc_def))
+return false;
+
+ if (STMT_VINFO_LIVE_P (stmt_info))
+{
+ if (dump_enabled_p ())
+ dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
+value used after loop.\n);
+ return false;
+}
+
+ if (!is_gimple_assign (stmt))
+return false;
+
+ code = gimple_assign_rhs_code (stmt);
+
+ if (code != BIT_AND_EXPR
+ code != BIT_IOR_EXPR
+ code != BIT_XOR_EXPR
+ code != BIT_NOT_EXPR
+ code != NE_EXPR
+ code != EQ_EXPR
+ code != SSA_NAME)
+return false;
+
+ lhs = gimple_assign_lhs (stmt);
+ rhs1 = gimple_assign_rhs1 (stmt);
+ rhs2 = gimple_assign_rhs2 (stmt);
+
+ if (TREE_TYPE (lhs) != boolean_type_node
+ || TREE_TYPE (rhs1) != boolean_type_node
+ || (rhs2 TREE_TYPE (rhs2) != boolean_type_node))
+return false;
+
+ if (TREE_CODE (rhs1) == SSA_NAME)
+{
+ gimple rhs1_def_stmt = SSA_NAME_DEF_STMT (rhs1);
+ if (!vect_is_simple_use_1 (rhs1, stmt, loop_vinfo, bb_vinfo,
+rhs1_def_stmt, def, dt, vectype1))
+ return false;
+}
+ else
+return false;
+
+ if (rhs2 TREE_CODE (rhs2) == SSA_NAME)
+{
+ gimple rhs2_def_stmt = SSA_NAME_DEF_STMT (rhs2);
+ if (!vect_is_simple_use_1 (rhs2, stmt, loop_vinfo, bb_vinfo,
+rhs2_def_stmt, def, dt, vectype2))
+ return false;
+}
+ /* Constant may appear in binary operation but we actually
+ shoudn't need it. We don't expect result to be a constant
+ here and return false on it because constant mask
+
Re: [PATCH] Add extensions to dwarf2.def
On 08/14/2015 10:49 AM, Pierre-Marie de Rodat wrote: I also tried to create the new pages on the wiki but it says You are not allowed to edit this page. (https://gcc.gnu.org/wiki/DW_AT_GNU_numerator_denominator?action=edit, I'm logged in as pmderodat). Does anyone know how I should proceed? I believe you need to be added to the editor group: https://gcc.gnu.org/wiki/EditorGroup You need someone on that list to add you. (I'm not on the list). Thanks, Pedro Alves
Re: [PATCH] Fix ICE with bogus posix_memalign call (PR middle-end/67222)
On Mon, Aug 17, 2015 at 8:01 PM, Marek Polacek pola...@redhat.com wrote:
Here we were crashing on an invalid call to posix_memalign. The code in
lower_builtin_posix_memalign assumed that the call had valid arguments.
The reason the C FE doesn't reject this code is, in short, that
int T () is compatible with int T (void **, size_t, size_t) and we
use the former -- so convert_arguments doesn't complain.
So I think let's validate the arguments in lower_stmt. I decided to
give an error if we see an invalid usage of posix_memalign, since
other code (e.g. alias machinery) assumes correct arguments as well.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
I don't think you can give errors here. Note that the appropriate
way to do the check is to simply use
if (gimple_builtin_call_types_compatible_p (stmt, decl))
not lowering in case it's not compatible is ok.
Thanks,
Richard.
2015-08-17 Marek Polacek pola...@redhat.com
PR middle-end/67222
* gimple-low.c: Include builtins.h.
(lower_stmt): Validate arguments of posix_memalign.
* gcc.dg/torture/pr67222.c: New test.
diff --git gcc/gimple-low.c gcc/gimple-low.c
index d4697e2..03194f0 100644
--- gcc/gimple-low.c
+++ gcc/gimple-low.c
@@ -39,6 +39,7 @@ along with GCC; see the file COPYING3. If not see
#include langhooks.h
#include gimple-low.h
#include tree-nested.h
+#include builtins.h
/* The differences between High GIMPLE and Low GIMPLE are the
following:
@@ -345,10 +346,22 @@ lower_stmt (gimple_stmt_iterator *gsi, struct
lower_data *data)
data-cannot_fallthru = false;
return;
}
- else if (DECL_FUNCTION_CODE (decl) == BUILT_IN_POSIX_MEMALIGN
- flag_tree_bit_ccp)
+ else if (DECL_FUNCTION_CODE (decl) == BUILT_IN_POSIX_MEMALIGN)
{
- lower_builtin_posix_memalign (gsi);
+ if (gimple_call_num_args (stmt) != 3
+ || !validate_gimple_arglist (dyn_cast gcall * (stmt),
+POINTER_TYPE, INTEGER_TYPE,
+INTEGER_TYPE, VOID_TYPE))
+ {
+ error_at (gimple_location (stmt), invalid arguments
+ to %qD, decl);
+ gsi_next (gsi);
+ return;
+ }
+ if (flag_tree_bit_ccp)
+ lower_builtin_posix_memalign (gsi);
+ else
+ gsi_next (gsi);
return;
}
}
diff --git gcc/testsuite/gcc.dg/torture/pr67222.c
gcc/testsuite/gcc.dg/torture/pr67222.c
index e69de29..cf39aa1 100644
--- gcc/testsuite/gcc.dg/torture/pr67222.c
+++ gcc/testsuite/gcc.dg/torture/pr67222.c
@@ -0,0 +1,19 @@
+/* { dg-do compile } */
+/* { dg-options -Wno-implicit-function-declaration } */
+
+void
+foo (void **p)
+{
+ posix_memalign (); /* { dg-error invalid arguments } */
+ posix_memalign (p); /* { dg-error invalid arguments } */
+ posix_memalign (0); /* { dg-error invalid arguments } */
+ posix_memalign (p, 1); /* { dg-error invalid arguments } */
+ posix_memalign (p, foo); /* { dg-error invalid arguments } */
+ posix_memalign (gnu, gcc); /* { dg-error invalid arguments } */
+ posix_memalign (1, p); /* { dg-error invalid arguments } */
+ posix_memalign (1, 2); /* { dg-error invalid arguments } */
+ posix_memalign (1, 2, 3); /* { dg-error invalid arguments } */
+ posix_memalign (p, p, p); /* { dg-error invalid arguments } */
+ posix_memalign (p, qui, 3); /* { dg-error invalid arguments } */
+ posix_memalign (p, 1, 2);
+}
Marek
Re: top-level configure.ac: factor the libgomp check for posix-like OS
Hi!
On Mon, 17 Aug 2015 06:46:32 -0700, Gary Funck g...@intrepid.com wrote:
I'm working on a patch set for GUPC, and as part of that work,
I may have a couple changes to trunk that will improve the fit
with the GUPC changes. Here's one in configure.ac.
At the moment, there is a check to see if $enable_libgom
is not set, followed by a case statement which adds
libgomp to $noconfigdirs on non POSIX-like OS's.
Hmm...
We'd like to re-use that logic for libgupc,
which has a similar requirement and propose this
re-factoring for trunk.
--- configure.ac(revision 226928)
+++ configure.ac(working copy)
@@ -529,9 +529,8 @@ if test x$enable_static_libjava != xyes
fi
AC_SUBST(EXTRA_CONFIGARGS_LIBJAVA)
-# Enable libgomp by default on hosted POSIX systems, and a few others.
-if test x$enable_libgomp = x ; then
-case ${target} in
+posix_like_os=yes
+case ${target} in
*-*-linux* | *-*-gnu* | *-*-k*bsd*-gnu | *-*-kopensolaris*-gnu)
;;
*-*-netbsd* | *-*-freebsd* | *-*-openbsd* | *-*-dragonfly*)
@@ -543,9 +542,14 @@ if test x$enable_libgomp = x ; then
nvptx*-*-*)
;;
*)
- noconfigdirs=$noconfigdirs target-libgomp
- ;;
-esac
+posix_like_os=no
+;;
+esac
Even if applicable regarding the libgomp configuration (because
nvptx-none has its own libgomp port: libgomp/config/nvptx/), it seems a
bit strange to qualify nvptx-none as a POSIX-like system.
+
+# Enable libgomp by default on POSIX hosted systems.
+if test x$enable_libgomp = x test $posix_like_os = no ; then
+# Disable libgomp on non POSIX hosted systems.
+noconfigdirs=$noconfigdirs target-libgomp
fi
So, we'll have to see whether that applies to libgupc for nvptx-none,
too.
Grüße,
Thomas
signature.asc
Description: PGP signature
[Bug fortran/59104] Wrong result with SIZE specification expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59104 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed|2013-12-19 00:00:00 |2015-8-18 CC||fxcoudert at gcc dot gnu.org Blocks||32834 --- Comment #2 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- F95 bug. Still present. In the generated code, the size of Y is computed before the bounds for the F result are set, which leads to the error. Slightly reduced testcase: $ cat a.f90 program bug3 real y(2) y = f(2) print *, y contains function f(x) integer x real f(x) integer y(size(f)) write(*,*) 'size(f) = ',size(f) write(*,*) 'size(y) = ',size(y) f = -42 end function f end program bug3 $ gfortran a.f90 -std=f95 ./a.out size(f) =2 size(y) =0 -42.000 -42.000 Slight modification of the source leads to an ICE on what I think is invalid code: $ cat a.f90 function f(x) integer x integer y(size(f)) real f(x) write(*,*) 'size(f) = ',size(f) write(*,*) 'size(y) = ',size(y) f = -42 end function f $ gfortran a.f90 -std=f95 ./a.out a.f90:3:0: integer y(size(f)) 1 internal compiler error: in gfc_conv_expr_descriptor, at fortran/trans-array.c:6534 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32834 [Bug 32834] [Meta-bug] 'Fortran 95'-only failures
Re: [PATCH 3/5][ARM] Use new feature set representation.
On Mon, Aug 10, 2015 at 12:57 PM, Matthew Wahab matthew.wa...@foss.arm.com wrote: The ARM backend uses an unsigned long to record CPU feature flags and there are currently 31 bits in use. This series of patches replaces the single unsigned long with a representation based on an array of values. This patch replaces the existing representation of CPU feature sets with the type arm_feature_set and ARM_FSET macros added in an earlier patch in this series. Tested the series for arm-none-linux-gnueabihf with native bootstrap and make check. gcc/ 2015-08-10 Matthew Wahab matthew.wa...@arm.com * config/arm/arm-builtins.c (def_mbuiltin): Use ARM_FSET macro. (struct builtin_description): Change type of mask to unsigned long. * config/arm/arm-protos.h (insn_flags): Declare as type arm_feature_set. (tune_flags): Likewise. * config/arm/arm.c (feature_count): New. (insn_flags): Define as type arm_feature_set. (tune_flags): Likewise. (struct processors): Define field flags as type arm_feature_set. (all_cores): Update for change to struct processors. (all_architectures): Likewise. (arm_option_check_internal): Use arm_feature_set and ARM_FSET macros. (arm_option_override_internal): Likewise. (arm_option_override): Likewise. This is OK Thanks, Ramana
Re: [PATCH GCC]Improve bound information in loop niter analysis
On Mon, Aug 17, 2015 at 6:49 PM, Ajit Kumar Agarwal
ajit.kumar.agar...@xilinx.com wrote:
All:
Does the Logic to calculate the Loop bound information through Value Range
Analyis uses the post dominator and
Dominator info. The iteration branches instead of Loop exit condition can be
calculated through post dominator info.
If the node in the Loop has two successors and post dominates the two
successors then the iteration branch can be
The same node.
For All the nodes L in the Loop B
If (L1, L2 belongs to successors of (L) L1,L2 belongs to PosDom(Header of
Loop))
{
I = I union L1
}
Thus I will have all set of iteration branches. This will handle more cases
of Loop bound information that
Will be accurate through the exact iteration count that are known cases along
with Value Range Information
Where the condition is instead not the Loop exits but other nodes in the Loop.
I don't quite follow your words here. Could you please give a simple
example about it? Especially I don't know how post-dom helps the loop
bound analysis. Seems your pseudo code is collecting some comparison
basic block of loop?
Thanks,
bin
Thanks Regards
Ajit
-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org] On
Behalf Of Bin.Cheng
Sent: Monday, August 17, 2015 3:32 PM
To: Richard Biener
Cc: Bin Cheng; GCC Patches
Subject: Re: [PATCH GCC]Improve bound information in loop niter analysis
Thanks for all your reviews.
On Fri, Aug 14, 2015 at 4:17 PM, Richard Biener richard.guent...@gmail.com
wrote:
On Tue, Jul 28, 2015 at 11:36 AM, Bin Cheng bin.ch...@arm.com wrote:
Hi,
Loop niter computes inaccurate bound information for different loops.
This patch is to improve it by using loop initial condition in
determine_value_range. Generally, loop niter is computed by
subtracting start var from end var in loop exit condition. Moreover,
loop bound is computed using value range information of both start and end
variables.
Basic idea of this patch is to check if loop initial condition
implies more range information for both start/end variables. If yes,
we refine range information and use that to compute loop bound.
With this improvement, more accurate loop bound information is
computed for test cases added by this patch.
+ c0 = fold_convert (type, c0);
+ c1 = fold_convert (type, c1);
+
+ if (operand_equal_p (var, c0, 0))
I believe if c0 is not already of type type operand-equal_p will never
succeed.
It's quite specific case targeting comparison between var and it's range
bounds. Given c0 is in form of var + offc0, then the comparison var +
offc0 != range bounds doesn't have any useful information. Maybe useless
type conversion can be handled here though, it might be even corner case.
(side-note: we should get rid of the GMP use, that's expensive and now
we have wide-int available which should do the trick as well)
+ /* Case of comparing with the bounds of the type. */
+ if (TYPE_MIN_VALUE (type)
+ operand_equal_p (c1, TYPE_MIN_VALUE (type), 0))
+ cmp = GT_EXPR;
+ if (TYPE_MAX_VALUE (type)
+ operand_equal_p (c1, TYPE_MAX_VALUE (type), 0))
+ cmp = LT_EXPR;
don't use TYPE_MIN/MAX_VALUE. Instead use the types precision and all
wide_int operations (see match.pd wi::max_value use).
Done.
+ else if (!operand_equal_p (var, varc0, 0))
+goto end_2;
ick - goto. We need sth like a auto_mpz class with a destructor.
Label end_2 removed.
struct auto_mpz
{
auto_mpz () { mpz_init (m_val); }
~auto_mpz () { mpz_clear (m_val); }
mpz operator() { return m_val; }
mpz m_val;
};
Is it OK?
I see the code follows existing practice in niter analysis even though
my overall plan was to transition its copying of value-range related
optimizations to use VRP infrastructure.
Yes, I think it's easy to push it to VRP infrastructure. Actually from the
name of the function, it's more vrp related. For now, the function is called
only by bound_difference, not so many as vrp queries. We need cache facility
in vrp otherwise it would be expensive.
I'm still ok with improving the existing code on the basis that I
won't get to that for GCC 6.
So - ok with the TYPE_MIN/MAX_VALUE change suggested above.
Refactoring with auto_mpz welcome.
That will be an independent patch, so I skipped it in this one.
New version attached. Bootstrap and test on x86_64.
Thanks,
bin
Thanks,
RIchard.
Thanks,
bin
2015-07-28 Bin Cheng bin.ch...@arm.com
* tree-ssa-loop-niter.c (refine_value_range_using_guard): New.
(determine_value_range): Call refine_value_range_using_guard for
each loop initial condition to improve value range.
gcc/testsuite/ChangeLog
2015-07-28 Bin Cheng bin.ch...@arm.com
* gcc.dg/tree-ssa/loop-bound-1.c: New test.
*
[ARM] Use vector wide add for mixed-mode adds
This patch is designed to address code that was not being vectorized due
to missing widening patterns in the ARM backend. Code such as:
int t6(int len, void * dummy, short * __restrict x)
{
len = len ~31;
int result = 0;
__asm volatile ();
for (int i = 0; i len; i++)
result += x[i];
return result;
}
Validated on arm-none-eabi, arm-none-linux-gnueabi,
arm-none-linux-gnueabihf, and armeb-none-linux-gnueabihf.
There is one regression on gcc.dg/vect/slp-reduc-3.c that only occurs
when -flto is enabled:
gcc.dg/vect/slp-reduc-3.c -flto -ffat-lto-objects scan-tree-dump-times vect
vectorizing stmts using SLP 1
gcc.dg/vect/slp-reduc-3.c scan-tree-dump-times vect vectorizing stmts using
SLP 1
I could use some feedback on whether this is a regression or issue with
the test case.
-
2015-08-18 Michael Collison michael.colli...@linaro.org
* config/arm/neon.md (widen_ussummode): New patterns
where mode is VQI to improve mixed mode vectorization.
* config/arm/unspec.md: Add new unspecs: UNSPEC_VZERO_EXTEND and
UNSPEC_VSIGN_EXTEND.
* gcc.target/arm/neon-vaddws16.c: New test.
* gcc.target/arm/neon-vaddws32.c: New test.
* gcc.target/arm/neon-vaddwu16.c: New test.
* gcc.target/arm/neon-vaddwu32.c: New test.
* gcc.target/arm/neon-vaddwu8.c: New test.
diff --git a/gcc/config/arm/neon.md b/gcc/config/arm/neon.md
index 654d9d5..50cb409 100644
--- a/gcc/config/arm/neon.md
+++ b/gcc/config/arm/neon.md
@@ -1174,6 +1174,27 @@
;; Widening operations
+(define_insn_and_split widen_ssummode3
+ [(set (match_operand:V_double_width 0 s_register_operand =w)
+(plus:V_double_width (unspec:V_double_width
+ [(match_operand:VQI 1 s_register_operand w)]
+UNSPEC_VSIGN_EXTEND)
+(match_operand:V_double_width 2 s_register_operand
0)))]
+ TARGET_NEON
+ #
+ reload_completed
+ [(const_int 0)]
+{
+rtx loreg = simplify_gen_subreg (V_HALFmode, operands[1],
MODEmode, 0);
+rtx hireg = simplify_gen_subreg (V_HALFmode, operands[1],
MODEmode, GET_MODE_SIZE (V_HALFmode));
+
+emit_insn (gen_widen_ssumV_half3 (operands[0], loreg, operands[2]));
+emit_insn (gen_widen_ssumV_half3 (operands[0], hireg, operands[2]));
+DONE;
+ }
+ [(set_attr type neon_add_widen)
+ (set_attr length 8)])
+
(define_insn widen_ssummode3
[(set (match_operand:V_widen 0 s_register_operand =w)
(plus:V_widen (sign_extend:V_widen
@@ -1184,6 +1205,27 @@
[(set_attr type neon_add_widen)]
)
+(define_insn_and_split widen_usummode3
+ [(set (match_operand:V_double_width 0 s_register_operand =w)
+(plus:V_double_width (unspec:V_double_width
+ [(match_operand:VQI 1 s_register_operand w)]
+UNSPEC_VZERO_EXTEND)
+(match_operand:V_double_width 2 s_register_operand
0)))]
+ TARGET_NEON
+ #
+ reload_completed
+ [(const_int 0)]
+{
+rtx loreg = simplify_gen_subreg (V_HALFmode, operands[1],
MODEmode, 0);
+rtx hireg = simplify_gen_subreg (V_HALFmode, operands[1],
MODEmode, GET_MODE_SIZE (V_HALFmode));
+
+emit_insn (gen_widen_usumV_half3 (operands[0], loreg, operands[2]));
+emit_insn (gen_widen_usumV_half3 (operands[0], hireg, operands[2]));
+DONE;
+ }
+ [(set_attr type neon_add_widen)
+ (set_attr length 8)])
+
(define_insn widen_usummode3
[(set (match_operand:V_widen 0 s_register_operand =w)
(plus:V_widen (zero_extend:V_widen
diff --git a/gcc/config/arm/unspecs.md b/gcc/config/arm/unspecs.md
index 0ec2c48..e9cf836 100644
--- a/gcc/config/arm/unspecs.md
+++ b/gcc/config/arm/unspecs.md
@@ -358,5 +358,7 @@
UNSPEC_NVRINTX
UNSPEC_NVRINTA
UNSPEC_NVRINTN
+ UNSPEC_VZERO_EXTEND
+ UNSPEC_VSIGN_EXTEND
])
diff --git a/gcc/testsuite/gcc.target/arm/neon-vaddws16.c
b/gcc/testsuite/gcc.target/arm/neon-vaddws16.c
new file mode 100644
index 000..ed10669
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/neon-vaddws16.c
@@ -0,0 +1,21 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target arm_neon_hw } */
+/* { dg-add-options arm_neon_ok } */
+/* { dg-options -O3 } */
+
+
+int
+t6(int len, void * dummy, short * __restrict x)
+{
+ len = len ~31;
+ int result = 0;
+ __asm volatile ();
+ for (int i = 0; i len; i++)
+result += x[i];
+ return result;
+}
+
+/* { dg-final { scan-assembler vaddw\.s16 } } */
+
+
+
diff --git a/gcc/testsuite/gcc.target/arm/neon-vaddws32.c
b/gcc/testsuite/gcc.target/arm/neon-vaddws32.c
new file mode 100644
index 000..94bf0c9
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/neon-vaddws32.c
@@ -0,0 +1,19 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target arm_neon_hw } */
+/* { dg-add-options arm_neon_ok } */
+/* { dg-options -O3 } */
+
+int
+t6(int len, void * dummy, int * __restrict x)
+{
+ len = len ~31;
+ long long result = 0;
+ __asm volatile ();
+ for (int i = 0; i len;
[Bug middle-end/67133] [6 Regression] ICE at -Os and above on x86_64-linux-gnu in gimple_op, at gimple.h:2274
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67133 --- Comment #29 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to Martin Jambor from comment #28) I see, thinking about signature changes, I forgot about the situations where we do not have the body of the callee in the first place. Yeah, the whole gimple_call_fntype thing was invented so we can aggressively propagate (mismatching) fndecls into calls, making them direct calls and resulting in much better cgraph analysis. Previously those calls remained indirect (to preserve the original fntype), we only propagated when the types of the call and the fndecl matched. But matched is hard to compute thus simply preserving the original type always was much easier and allows for very aggressive propagation. Of course now you need to deal with actual mismatches and have to be careful what you access.
Re: [PATCH 4/8] DWARF: add a language hook for fixed-point types
On 07/16/2015 10:43 AM, Pierre-Marie de Rodat wrote:
Support for fixed-point types in GCC is not powerful enough for Ada
fixed-point types: GNAT uses regular scalar types to implement them.
This new language hook makes it possible to output the desired debugging
information anyway.
Here's the updated patch according to the discussion on the DWARF
extension: https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00771.html
Bootstrapped and regtested on x86_64-linux.
--
Pierre-Marie de Rodat
From 6892758d5cf458b63c63d869bb547bf0c5369820 Mon Sep 17 00:00:00 2001
From: Pierre-Marie de Rodat dero...@adacore.com
Date: Tue, 4 Nov 2014 12:04:24 +0100
Subject: [PATCH 4/8] DWARF: add a language hook for fixed-point types
Support for fixed-point types in GCC is not powerful enough for Ada
fixed-point types: GNAT uses regular scalar types to implement them.
This new language hook makes it possible to output the desired debugging
information anyway.
include/ChangeLog:
* dwarf2.def (DW_TAG_GNU_rational_constant): New tag.
(DW_AT_GNU_numerator, DW_AT_GNU_denominator): New attributes.
gcc/ada/ChangeLog:
* gcc-interface/ada-tree.def (POWER_EXPR): New binary operation.
* gcc-interface/ada-tree.h (TYPE_FIXED_POINT_P): New macro.
(TYPE_IS_FIXED_POINT_P): New macro.
(TYPE_SCALE_FACTOR): New macro.
(SET_TYPE_SCALE_FACTOR): New macro.
* gcc-interface/decl.c: Include urealp.h
(gnat_to_gnu_entity): Attach trees to encode scale factors to
fixed-point types.
* gcc-interface/misc.c (gnat_print_type): Print scale factors
for fixed-point types.
(gnat_get_fixed_point_type_info): New.
(gnat_init_ts): Initialize data for the POWER_EXPR binary
operation.
(LANG_HOOKS_GET_FIXED_POINT_INFO): Redefine macro to implement
the get_fixed_point_type_info language hook.
gcc/ChangeLog:
* langhooks.h (struct lang_hooks_for_types): Add a
get_fixed_point_type_info field.
* langhooks-def.h (LANG_HOOKS_GET_FIXED_POINT_TYPE_INFO): New
macro.
(LANG_HOOKS_FOR_TYPES_INITIALIZER): Initialize the
get_fixed_point_type_info field.
* dwarf2out.h (enum fixed_point_scale_factor): New.
(struct fixed_point_type_info): New.
* dwarf2out.c (base_type_die): In DWARFv3 or non-strict DWARF
mode, get fixed-point type information using the debugging hook
and describe it in DWARF, if any.
---
gcc/ada/gcc-interface/ada-tree.def | 5 +++
gcc/ada/gcc-interface/ada-tree.h | 17
gcc/ada/gcc-interface/decl.c | 72 -
gcc/ada/gcc-interface/misc.c | 82 ++
gcc/dwarf2out.c| 52
gcc/dwarf2out.h| 29 ++
gcc/langhooks-def.h| 4 +-
gcc/langhooks.h| 5 +++
8 files changed, 263 insertions(+), 3 deletions(-)
diff --git a/gcc/ada/gcc-interface/ada-tree.def b/gcc/ada/gcc-interface/ada-tree.def
index 93967b5..8eb4688 100644
--- a/gcc/ada/gcc-interface/ada-tree.def
+++ b/gcc/ada/gcc-interface/ada-tree.def
@@ -47,6 +47,11 @@ DEFTREECODE (PLUS_NOMOD_EXPR, plus_nomod_expr, tcc_binary, 2)
This is used for loops and never shows up in the tree. */
DEFTREECODE (MINUS_NOMOD_EXPR, minus_nomod_expr, tcc_binary, 2)
+/* An expression that computes an exponentiation. Operand 0 is the base and
+ Operand 1 is the exponent. This node is never passed to GCC: it is only
+ used internally to describe fixed point types scale factors. */
+DEFTREECODE (POWER_EXPR, power_expr, tcc_binary, 2)
+
/* Same as ADDR_EXPR, except that if the operand represents a bit field,
return the address of the byte containing the bit. This is used
for the Address attribute and never shows up in the tree. */
diff --git a/gcc/ada/gcc-interface/ada-tree.h b/gcc/ada/gcc-interface/ada-tree.h
index 2fc960e..8c4fdc9 100644
--- a/gcc/ada/gcc-interface/ada-tree.h
+++ b/gcc/ada/gcc-interface/ada-tree.h
@@ -126,6 +126,13 @@ do { \
#define TYPE_CONTAINS_TEMPLATE_P(NODE) \
TYPE_LANG_FLAG_3 (RECORD_OR_UNION_CHECK (NODE))
+/* For INTEGER_TYPE, nonzero if it implements a fixed-point type. */
+#define TYPE_FIXED_POINT_P(NODE) \
+ TYPE_LANG_FLAG_3 (INTEGER_TYPE_CHECK (NODE))
+
+#define TYPE_IS_FIXED_POINT_P(NODE) \
+ (TREE_CODE (NODE) == INTEGER_TYPE TYPE_FIXED_POINT_P (NODE))
+
/* True if NODE is a thin pointer. */
#define TYPE_IS_THIN_POINTER_P(NODE) \
(POINTER_TYPE_P (NODE)\
@@ -354,6 +361,16 @@ do { \
#define SET_TYPE_DEBUG_TYPE(NODE, X) \
SET_TYPE_LANG_SPECIFIC2(NODE, X)
+/* For an INTEGER_TYPE with TYPE_IS_FIXED_POINT_P, this is the value of the
+ scale factor. Modular types, index types (sizetype subtypes) and
+ fixed-point types are totally distinct types, so there is no problem with
+ sharing type lang specific's first slot. */
+#define TYPE_SCALE_FACTOR(NODE) \
+ GET_TYPE_LANG_SPECIFIC (INTEGER_TYPE_CHECK (NODE))
+#define SET_TYPE_SCALE_FACTOR(NODE, X) \
+ SET_TYPE_LANG_SPECIFIC (INTEGER_TYPE_CHECK (NODE), X)
+
+
/* Flags added
Re: [PATCH 7/8] DWARF: add a language hook for scalar biased types
On 07/16/2015 10:48 AM, Pierre-Marie de Rodat wrote:
Front-ends like GNAT for Ada sometimes use biased encodings for integral
types. This change creates a new language hook so that the bias
information can make it into the debugging information back-end and
introduces an experimental DWARF attribute to hold it.
Here's an updated, only to fix the conflict with the include/dwarf2.def
update that occurred here:
https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00771.html.
Bootstrapped and regtested on x86_64-linux.
--
Pierre-Marie de Rodat
From 68841d3ba7485932fc966386b46d54a934033736 Mon Sep 17 00:00:00 2001
From: Pierre-Marie de Rodat dero...@adacore.com
Date: Thu, 8 Jan 2015 11:07:06 +0100
Subject: [PATCH 7/8] DWARF: add a language hook for scalar biased types
Front-ends like GNAT for Ada sometimes use biased encodings for integral
types. This change creates a new language hook so that the bias
information can make it into the debugging information back-end and
introduces an experimental DWARF attribute to hold it.
include/ChangeLog:
* dwarf2.def (DW_AT_GNU_bias): New attribute.
gcc/ada/ChangeLog:
* gcc-interface/misc.c (gnat_get_type_bias): New.
(LANG_HOOKS_GET_TYPE_BIAS): Redefine macro to implement the
get_type_bias language hook.
gcc/ChangeLog:
* langhooks.h (struct lang_hooks_for_types): New get_bias_field.
* langhooks-def.h (LANG_HOOKS_GET_TYPE_BIAS): New.
(LANG_HOOKS_FOR_TYPES_INITIALIZER): Initialize the
get_bias_field.
* dwarf2out.c
(base_type_die): In non-strict DWARF mode, invoke the
get_type_bias language hook for INTEGER_TYPE nodes. If it
returns a bias, emit an attribute for it.
(subrange_type_die): Change signature to handle bias. If
non-strict DWARF mode, emit an attribute for it, if one passed.
(modified_type_die): For subrange types, invoke the
get_type_bias langage hook and pass the bias to
subrange_type_die.
---
gcc/ada/gcc-interface/misc.c | 12
gcc/dwarf2out.c | 27 ---
gcc/langhooks-def.h | 2 ++
gcc/langhooks.h | 5 +
4 files changed, 43 insertions(+), 3 deletions(-)
diff --git a/gcc/ada/gcc-interface/misc.c b/gcc/ada/gcc-interface/misc.c
index 4a355a3..47a8b1c 100644
--- a/gcc/ada/gcc-interface/misc.c
+++ b/gcc/ada/gcc-interface/misc.c
@@ -969,6 +969,16 @@ gnat_get_subrange_bounds (const_tree gnu_type, tree *lowval, tree *highval)
*highval = TYPE_MAX_VALUE (gnu_type);
}
+static tree
+gnat_get_type_bias (const_tree gnu_type)
+{
+ if (TREE_CODE (gnu_type) == INTEGER_TYPE
+ TYPE_BIASED_REPRESENTATION_P (gnu_type)
+ gnat_encodings == DWARF_GNAT_ENCODINGS_MINIMAL)
+return TYPE_RM_MIN_VALUE(gnu_type);
+ return NULL_TREE;
+}
+
/* GNU_TYPE is the type of a subprogram parameter. Determine if it should be
passed by reference by default. */
@@ -1268,6 +1278,8 @@ get_lang_specific (tree node)
#define LANG_HOOKS_GET_ARRAY_DESCR_INFO gnat_get_array_descr_info
#undef LANG_HOOKS_GET_SUBRANGE_BOUNDS
#define LANG_HOOKS_GET_SUBRANGE_BOUNDS gnat_get_subrange_bounds
+#undef LANG_HOOKS_GET_TYPE_BIAS
+#define LANG_HOOKS_GET_TYPE_BIAS gnat_get_type_bias
#undef LANG_HOOKS_DESCRIPTIVE_TYPE
#define LANG_HOOKS_DESCRIPTIVE_TYPE gnat_descriptive_type
#undef LANG_HOOKS_GET_DEBUG_TYPE
diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index b7d72eb..be12e43 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -3283,7 +3283,7 @@ static void output_line_info (bool);
static void output_file_names (void);
static dw_die_ref base_type_die (tree);
static int is_base_type (tree);
-static dw_die_ref subrange_type_die (tree, tree, tree, dw_die_ref);
+static dw_die_ref subrange_type_die (tree, tree, tree, tree, dw_die_ref);
static int decl_quals (const_tree);
static dw_die_ref modified_type_die (tree, int, dw_die_ref);
static dw_die_ref generic_parameter_die (tree, tree, bool, dw_die_ref);
@@ -10792,6 +10792,7 @@ base_type_die (tree type)
enum dwarf_type encoding;
bool fpt_used = false;
struct fixed_point_type_info fpt_info;
+ tree type_bias = NULL_TREE;
if (TREE_CODE (type) == ERROR_MARK || TREE_CODE (type) == VOID_TYPE)
return 0;
@@ -10842,6 +10843,10 @@ base_type_die (tree type)
encoding = DW_ATE_unsigned;
else
encoding = DW_ATE_signed;
+
+ if (!dwarf_strict
+ lang_hooks.types.get_type_bias)
+ type_bias = lang_hooks.types.get_type_bias (type);
break;
case REAL_TYPE:
@@ -10926,6 +10931,12 @@ base_type_die (tree type)
gcc_unreachable ();
}
}
+ if (type_bias != NULL)
+add_scalar_info (base_type_result, DW_AT_GNU_bias, type_bias,
+ dw_scalar_form_constant
+ | dw_scalar_form_exprloc
+ | dw_scalar_form_reference,
+ NULL);
add_pubtype (type, base_type_result);
return base_type_result;
@@ -11027,7 +11038,8 @@ offset_int_type_size_in_bits (const_tree type)
to a DIE that describes the given type. */
static dw_die_ref
-subrange_type_die (tree type, tree low, tree
Re: [PATCH] Fix middle-end/67133, part 1
On Mon, Aug 17, 2015 at 7:31 PM, Jeff Law l...@redhat.com wrote: On 08/14/2015 02:46 PM, Marek Polacek wrote: Then in isolate-paths in find_explicit_erroneous_behaviour we're walking the stmts in bb 2 and we find a null dereference, so insert_trap_and_remove_trailing_statements comes in play and turns bb 2 into: bb 2: ... SR.5_10 = MEM[(const struct A )0B]; __builtin_trap (); i.e. it removs the defining statement for c_13. Then find_explicit_erroneous_behaviour walks over bb 3, hits the fn1 (D.2434.OutBufCur, b, c_13); statement, and ICEs on the c_13 argument: it's a released SSA name with NULL TREE_TYPE. The question now is what to do with that. Skip SSA_NAME_IN_FREE_LIST? That sounds weird. Note that we're going to remove bb 3 and bb 4 anyway... Jeez, looking at the code N years later, I feel like a complete idiot. Of course that's not going to work. We certainly don't want to peek at SSA_NAME_IN_FREE_LIST. Yeh, I thought as much. I wonder if we should be walking in backwards dominator order to avoid these effects. Or maybe just ignoring any BB with no preds. I'll ponder those over the weekend. I suppose both ought to work. Or at least theoretically we could run e.g. cleanup_cfg to prune the IR after we've inserted trap and removed trailing stmts so that it gets rid of unreachable bbs. Would that make sense? Anyway, if you think of how would you like to solve this I can take a crack at it next week. The funny thing here is we remove the statements after the trap to avoid this exact situation! Not sure, when I came along that code in the past I wondered why we don't just do like other passes - split the block, insert the unreachable() at the end of the first and leave the actual cleanup to cfg-cleanup. I think the problem with schemes that either change the order of block processing, or which ignore some blocks are going to run into issues. By walking blocks and statements in a backwards order, we address 99% of the problems, including uses in PHIs in a direct successor block. What's not handled is a use in a PHI at the frontier of a subgraph that becomes unreachable. We'd have to do the usual unreachable block analysis to catch and handle those properly. So you are after second-level effects that require earlier unreachable paths to be pruned? I don't particularly like that idea But in walking through all that, I think I've stumbled on a simpler solution. Specifically do as a little as possible and let the standard mechanisms clean things up :-) 1. Delete the code that removes instructions after the trap. 2. Split the block immediately after the trap and remove the edge from the original block (with the trap) to the new block. cfg-cleanup will do that for you if you have a not returning stmt ending the previous block. Richard. THen let the standard mechanisms handle things when that pass is complete. By setting cfg_altered, we'll get unreachable code removal which will capture most of the intended effect. DCE fires a couple more passes down in the pipeline to pick up the remaining tidbits. Do you want to try and tackle this? jeff
Re: [PATCH][AARCH64]Add backend combine_bfi pattern.
On 5 August 2015 at 17:46, Renlin Li renlin...@arm.com wrote: Hi Kyrill, On 30/07/15 17:08, Kyrill Tkachov wrote: Hi Renlin, On 30/07/15 16:50, Renlin Li wrote: Hi all, This insn should match the following similar rtx pattern and remove the redundant zero_extend operation if the width of zero_extract and inner-size of zero_extend totally match. (set (zero_extract:SI (reg/i:SI 0 x0) (const_int 8 [0x8]) (const_int 0 [0])) (zero_extend:SI (reg:QI 1 x1 [ y ]))) aarch64-none-elf regression tests Okay. Okay to commit? Regards, Renlin gcc/ChangeLog: 2015-07-30 Renlin Li renlin...@arm.com * config/aarch64/aarch64.md (combine_bfi): New pattern. gcc/testsuite/ChangeLog: 2015-07-30 Renlin Li renlin...@arm.com * gcc.target/aarch64/combine-bfi.c: New. +(define_insn *combine_bfiGPI:modeALLX:mode + [(set (zero_extract:GPI (match_operand:GPI 0 register_operand +r) + (match_operand 1 const_int_operand n) + (match_operand 2 const_int_operand n)) + (zero_extend:GPI (match_operand:ALLX 3 register_operand r)))] + UINTVAL (operands[1]) == ALLX:sizen + bfi\\t%w0, %w3, %2, %1 + [(set_attr type bfm)] +) I notice we don't have any other patterns in aarch64 that start with combine_*. Would it be better to name them something like *aarch64_bfiGPI:modeALLX:mode4 instead? Thanks for the suggestion. I have adjust the patch accordingly. Regards, Renlin gcc/ChangeLog: 2015-08-05 Renlin Li renlin...@arm.com * config/aarch64/aarch64.md (*aarch64_bfiGPI:modeALLX:mode4): New pattern. gcc/testsuite/ChangeLog: 2015-08-05 Renlin Li renlin...@arm.com * gcc.target/aarch64/combine-bfi.c: New. For new test cases in this directory, follow the guidance given on the wiki here https://gcc.gnu.org/wiki/TestCaseWriting, specifically add the suffix _N, hence combine_bfi_1.c OK with that change. /Marcus
Re: [Aarch64] Adjust tests to take LSE extension into account.
On 14/08/15 16:18, Matthew Wahab wrote:
On 14/08/15 14:36, Matthew Wahab wrote:
Tests for the code generated by the Aarch64 backends for the __sync and
__atomic builtins assume that they are implemented using sequences based
on load-exclusive and store-exclusive instructions. ARMv8.1 introduces
atomic instructions which can be used to implement __sync and __atomic
builtins. This means that the tests could fail if the default target is
set to a cpu that enables the atomic instructions.
This patch adjusts the tests to explicitly disable the LSE extension
providing the atomic instructions so that the compiler falls back to
generating the load-excluclusive/store-exclusive sequences.
Tested for aarch64-none-elf with cross-compiled check-gcc. Also tested
aarch64-none-elf with check-gcc using a custom build of the compiler
with LSE extensions (atomic CAS) enabled by default.
I've noticed another test that should be adjusted; it doesn't use CAS but would
use
other atomic instructions. I'll respin the patch to include it.
I've updated the patch to also adjust gcc.target/aarch64/atomic-op-int.c and
gcc.target/aarch64/atomic-op-imm.c.
Tested for aarch64-none-elf with cross-compiled check-gcc.
Ok for trunk?
Matthew
gcc/testsuite
2015-08-18 Matthew Wahab matthew.wa...@arm.com
* gcc.target/aarch64/atomic-comp-swap-release-acquire.c: Adjust
dg-options to disable LSE extensions.
* gcc.target/aarch64/atomic-op-acq_rel.c: Likewise.
* gcc.target/aarch64/atomic-op-acquire.c: Likewise.
* gcc.target/aarch64/atomic-op-char.c: Likewise.
* gcc.target/aarch64/atomic-op-consume.c: Likewise.
* gcc.target/aarch64/atomic-op-imm.c: Likewise.
* gcc.target/aarch64/atomic-op-int.c: Likewise.
* gcc.target/aarch64/atomic-op-long.c: Likewise.
* gcc.target/aarch64/atomic-op-relaxed.c: Likewise.
* gcc.target/aarch64/atomic-op-seq_cst.c: Likewise.
* gcc.target/aarch64/atomic-op-release.c: Likewise.
* gcc.target/aarch64/atomic-op-short.c: Likewise.
* gcc.target/aarch64/sync-comp-swap.c: Likewise.
* gcc.target/aarch64/sync-op-acquire.c: Likewise.
* gcc.target/aarch64/sync-op-full.c: Likewise.
* gcc.target/aarch64/sync-op-release.c: Likewise.
diff --git a/gcc/testsuite/gcc.target/aarch64/atomic-comp-swap-release-acquire.c b/gcc/testsuite/gcc.target/aarch64/atomic-comp-swap-release-acquire.c
index b8f098d..49ca5d0 100644
--- a/gcc/testsuite/gcc.target/aarch64/atomic-comp-swap-release-acquire.c
+++ b/gcc/testsuite/gcc.target/aarch64/atomic-comp-swap-release-acquire.c
@@ -1,5 +1,5 @@
/* { dg-do compile } */
-/* { dg-options -O2 -fno-ipa-icf } */
+/* { dg-options -march=armv8-a+nolse -O2 -fno-ipa-icf } */
#include atomic-comp-swap-release-acquire.x
diff --git a/gcc/testsuite/gcc.target/aarch64/atomic-op-acq_rel.c b/gcc/testsuite/gcc.target/aarch64/atomic-op-acq_rel.c
index 8569ac0..74f2634 100644
--- a/gcc/testsuite/gcc.target/aarch64/atomic-op-acq_rel.c
+++ b/gcc/testsuite/gcc.target/aarch64/atomic-op-acq_rel.c
@@ -1,5 +1,5 @@
/* { dg-do compile } */
-/* { dg-options -O2 } */
+/* { dg-options -march=armv8-a+nolse -O2 } */
#include atomic-op-acq_rel.x
diff --git a/gcc/testsuite/gcc.target/aarch64/atomic-op-acquire.c b/gcc/testsuite/gcc.target/aarch64/atomic-op-acquire.c
index 57e6d57..66c1b1e 100644
--- a/gcc/testsuite/gcc.target/aarch64/atomic-op-acquire.c
+++ b/gcc/testsuite/gcc.target/aarch64/atomic-op-acquire.c
@@ -1,5 +1,5 @@
/* { dg-do compile } */
-/* { dg-options -O2 } */
+/* { dg-options -march=armv8-a+nolse -O2 } */
#include atomic-op-acquire.x
diff --git a/gcc/testsuite/gcc.target/aarch64/atomic-op-char.c b/gcc/testsuite/gcc.target/aarch64/atomic-op-char.c
index d6c2aa5..c09d043 100644
--- a/gcc/testsuite/gcc.target/aarch64/atomic-op-char.c
+++ b/gcc/testsuite/gcc.target/aarch64/atomic-op-char.c
@@ -1,5 +1,5 @@
/* { dg-do compile } */
-/* { dg-options -O2 } */
+/* { dg-options -march=armv8-a+nolse -O2 } */
#include atomic-op-char.x
diff --git a/gcc/testsuite/gcc.target/aarch64/atomic-op-consume.c b/gcc/testsuite/gcc.target/aarch64/atomic-op-consume.c
index 26ebbdf..5783ab8 100644
--- a/gcc/testsuite/gcc.target/aarch64/atomic-op-consume.c
+++ b/gcc/testsuite/gcc.target/aarch64/atomic-op-consume.c
@@ -1,5 +1,5 @@
/* { dg-do compile } */
-/* { dg-options -O2 } */
+/* { dg-options -march=armv8-a+nolse -O2 } */
#include atomic-op-consume.x
diff --git a/gcc/testsuite/gcc.target/aarch64/atomic-op-imm.c b/gcc/testsuite/gcc.target/aarch64/atomic-op-imm.c
index 47d7a96..18b8f0b 100644
--- a/gcc/testsuite/gcc.target/aarch64/atomic-op-imm.c
+++ b/gcc/testsuite/gcc.target/aarch64/atomic-op-imm.c
@@ -1,5 +1,5 @@
/* { dg-do compile } */
-/* { dg-options -O2 } */
+/* { dg-options -march=armv8-a+nolse -O2 } */
int v = 0;
diff --git a/gcc/testsuite/gcc.target/aarch64/atomic-op-int.c b/gcc/testsuite/gcc.target/aarch64/atomic-op-int.c
index 9ad7a79..8520f08 100644
---
Re: [PATCH GCC]Improve bound information in loop niter analysis
On Tue, Aug 18, 2015 at 10:02 AM, Ajit Kumar Agarwal
ajit.kumar.agar...@xilinx.com wrote:
-Original Message-
From: Bin.Cheng [mailto:amker.ch...@gmail.com]
Sent: Tuesday, August 18, 2015 1:08 PM
To: Ajit Kumar Agarwal
Cc: Richard Biener; Bin Cheng; GCC Patches; Vinod Kathail; Shail Aditya
Gupta; Vidhumouli Hunsigida; Nagaraju Mekala
Subject: Re: [PATCH GCC]Improve bound information in loop niter analysis
On Mon, Aug 17, 2015 at 6:49 PM, Ajit Kumar Agarwal
ajit.kumar.agar...@xilinx.com wrote:
All:
Does the Logic to calculate the Loop bound information through Value
Range Analyis uses the post dominator and Dominator info. The iteration
branches instead of Loop exit condition can be calculated through post
dominator info.
If the node in the Loop has two successors and post dominates the two
successors then the iteration branch can be The same node.
For All the nodes L in the Loop B
If (L1, L2 belongs to successors of (L) L1,L2 belongs to
PosDom(Header of Loop)) {
I = I union L1
}
Thus I will have all set of iteration branches. This will handle
more cases of Loop bound information that Will be accurate through the
exact iteration count that are known cases along with Value Range
Information Where the condition is instead not the Loop exits but other
nodes in the Loop.
I don't quite follow your words here. Could you please give a simple
example about it? Especially I don't know how post-dom helps the loop bound
analysis. Seems your pseudo code is collecting some comparison basic
block of loop?
The Algorithm I have given above is based on Post Dominator Info. This helps
to calculate the iteration branches. The iteration branches are the
Branches that determine the loop exit condition. Based on the condition it
either branches to the header of the Loop, Or it may branch to the
Block dominated by the header or exit from the loop. The above Algorithm
finds out such iteration branches and thus decides on the Loop bound
Or iteration count. If such iteration branches are not at the back edge node
and it may be a node inside the loop based on some conditions.
Finding out such iteration branches can be done through the post dominator
info using the above algorithm. Based on the iteration branches the
conditions can be analyzed and that helps in finding out the iteration bound
for Known cases. Know cases are the cases where the loop bound can be
determined at compile time.
One Example would be Multi-Exits Loops where the Loop exit condition can be
at the back edge or it may be a block inside the Loop based on the
IF conditions and breaks out based on the conditions. Thus having multiple
exits. Such iteration branches can be found using The above Algorithm.
We already have code to compute the iteration count for each loop exit
and combine that into an overall iteration count.
Richard.
Thanks Regards
Ajit
Thanks,
bin
Thanks Regards
Ajit
-Original Message-
From: gcc-patches-ow...@gcc.gnu.org
[mailto:gcc-patches-ow...@gcc.gnu.org] On Behalf Of Bin.Cheng
Sent: Monday, August 17, 2015 3:32 PM
To: Richard Biener
Cc: Bin Cheng; GCC Patches
Subject: Re: [PATCH GCC]Improve bound information in loop niter
analysis
Thanks for all your reviews.
On Fri, Aug 14, 2015 at 4:17 PM, Richard Biener richard.guent...@gmail.com
wrote:
On Tue, Jul 28, 2015 at 11:36 AM, Bin Cheng bin.ch...@arm.com wrote:
Hi,
Loop niter computes inaccurate bound information for different loops.
This patch is to improve it by using loop initial condition in
determine_value_range. Generally, loop niter is computed by
subtracting start var from end var in loop exit condition.
Moreover, loop bound is computed using value range information of both
start and end variables.
Basic idea of this patch is to check if loop initial condition
implies more range information for both start/end variables. If
yes, we refine range information and use that to compute loop bound.
With this improvement, more accurate loop bound information is
computed for test cases added by this patch.
+ c0 = fold_convert (type, c0);
+ c1 = fold_convert (type, c1);
+
+ if (operand_equal_p (var, c0, 0))
I believe if c0 is not already of type type operand-equal_p will never
succeed.
It's quite specific case targeting comparison between var and it's range
bounds. Given c0 is in form of var + offc0, then the comparison var +
offc0 != range bounds doesn't have any useful information. Maybe useless
type conversion can be handled here though, it might be even corner case.
(side-note: we should get rid of the GMP use, that's expensive and
now we have wide-int available which should do the trick as well)
+ /* Case of comparing with the bounds of the type. */
+ if (TYPE_MIN_VALUE (type)
+ operand_equal_p (c1, TYPE_MIN_VALUE (type), 0))
+ cmp = GT_EXPR;
+ if (TYPE_MAX_VALUE (type)
[Bug tree-optimization/61441] ARM aarch64 fails to quiet signaling NaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61441 --- Comment #8 from Sujoy ssaraswati at gmail dot com --- (In reply to jos...@codesourcery.com from comment #7) With -fno-signaling-nans, signaling NaN representations are trap representations - the compiler can assume that nothing ever manipulated as a floating-point value has such a representation. (It cannot assume anything about unions of floating-point and other types where the floating-point field is not accessed. But 58416 is a bug even in the absence of -fsignaling-nans.) Ok, have a further question though. For the current test case, which has the following code - float sNaN = __builtin_nansf () the sNaN will have a signaling NaN representation. What does -fno-signaling-nans imply for this situation? Should the compiler assume that this signaling NaN need not be preserved as this would not lead to a trap? In other words, can the compiler assume that it can carry out optimizations without having to care for traps? As for 58416, looks like this got resolved with revision 196841, where the i386.md now generates movsd instructions depending on type attribute. In both these cases, we formally don't care about the result (but if folding, it still would seem odd to fold incorrectly, so may as well fold to a qNaN). Ok. This point is nothing to do with -fsignaling-nans. It's a simple matter of C11 F.9.1 paragraph 3, This specification does not require support for trap handlers that maintain information about the order or count of floating-point exceptions (which TS 18661-1:2014, adding support for signaling NaNs, doesn't change). But it's true that any references to a number of exceptions should make clear it's only referring to the distinction between zero and nonzero numbers. Right, I think I interpreted the man page text number of exceptions visible with signaling NaNs. It probably means the number of types of exceptions and not the number of exceptions for any given type. Local fixes for particular signaling NaNs issues seem reasonable (as in: if you fold an operation involving a signaling NaN, you may as well quiet it in the process, even though signaling NaNs aren't meant to occur in any mode where folding them is likely to be safe). Thanks, I will prepare a patch to do this. Should I wait for the bug to move to new state, or is it ok to send a fix even though it is marked as unconfirmed?
[Bug c++/67238] [C++11][C++14]cc1plus crash for nested decltype expression in parameter pack in trailing return type when '-g' enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67238 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- Mainline works for me.
[Bug fortran/67250] gfortran does not faithfully preprocess the way cpp does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67250 --- Comment #11 from Steve Kargl sgk at troutmask dot apl.washington.edu --- On Tue, Aug 18, 2015 at 06:03:00AM +, jeff.science at gmail dot com wrote: In short, it's not in the standard, therefore it's fine to break user experience seems pretty weak here. It's fine if you tell me that you do not care about my needs and will not implement it, but please don't use ISO as the excuse. Well, no. It's not standard, so a compiler implementation is free define its own behavior. The gfortran manual has documented its behavior for a very long time. Have you read the gfortran manual?
Re: [PATCH 4/5][ARM] Use features sets for builtins.
On Mon, Aug 10, 2015 at 12:58 PM, Matthew Wahab matthew.wa...@foss.arm.com wrote: The ARM backend uses an unsigned long to record CPU feature flags and there are currently 31 bits in use. This series of patches replaces the single unsigned long with a representation based on an array of values. This patch updates the feature flags usage in the builtins description to be able use make of all representable flags. Tested the series for arm-none-linux-gnueabihf with native bootstrap and make check. gcc/ 2015-08-10 Matthew Wahab matthew.wa...@arm.com * config/arm/arm-builtins.c (def_mbuiltin): Test all flags in a feature set. (struct builtin_description): Replace field mask with field features. (IWMMXT_BUILTIN): Use ARM_FSET macros for feature flags. (IWMMXT2_BUILTIN): Likewise. (IWMMXT2_BUILTIN2): Likewise. (FP_BUILTIN): Likewise. (CRC32_BUILTIN): Likewise. (CRYPTO_BUILTIN): Likewise. (iwmmx_mbuiltin): Likewise. (iwmmx2_mbuiltin): Likewise. (arm_init_iwmmxt_builtins): Likewise. Also, update for change to struct builtin_description. OK - please watch out for any fallout in the next couple of days with any auto-testers. Ramana
RE: [PATCH GCC]Improve bound information in loop niter analysis
-Original Message-
From: Bin.Cheng [mailto:amker.ch...@gmail.com]
Sent: Tuesday, August 18, 2015 1:08 PM
To: Ajit Kumar Agarwal
Cc: Richard Biener; Bin Cheng; GCC Patches; Vinod Kathail; Shail Aditya Gupta;
Vidhumouli Hunsigida; Nagaraju Mekala
Subject: Re: [PATCH GCC]Improve bound information in loop niter analysis
On Mon, Aug 17, 2015 at 6:49 PM, Ajit Kumar Agarwal
ajit.kumar.agar...@xilinx.com wrote:
All:
Does the Logic to calculate the Loop bound information through Value
Range Analyis uses the post dominator and Dominator info. The iteration
branches instead of Loop exit condition can be calculated through post
dominator info.
If the node in the Loop has two successors and post dominates the two
successors then the iteration branch can be The same node.
For All the nodes L in the Loop B
If (L1, L2 belongs to successors of (L) L1,L2 belongs to
PosDom(Header of Loop)) {
I = I union L1
}
Thus I will have all set of iteration branches. This will handle
more cases of Loop bound information that Will be accurate through the
exact iteration count that are known cases along with Value Range Information
Where the condition is instead not the Loop exits but other nodes in the Loop.
I don't quite follow your words here. Could you please give a simple example
about it? Especially I don't know how post-dom helps the loop bound
analysis. Seems your pseudo code is collecting some comparison basic block
of loop?
The Algorithm I have given above is based on Post Dominator Info. This helps to
calculate the iteration branches. The iteration branches are the
Branches that determine the loop exit condition. Based on the condition it
either branches to the header of the Loop, Or it may branch to the
Block dominated by the header or exit from the loop. The above Algorithm finds
out such iteration branches and thus decides on the Loop bound
Or iteration count. If such iteration branches are not at the back edge node
and it may be a node inside the loop based on some conditions.
Finding out such iteration branches can be done through the post dominator info
using the above algorithm. Based on the iteration branches the
conditions can be analyzed and that helps in finding out the iteration bound
for Known cases. Know cases are the cases where the loop bound can be
determined at compile time.
One Example would be Multi-Exits Loops where the Loop exit condition can be at
the back edge or it may be a block inside the Loop based on the
IF conditions and breaks out based on the conditions. Thus having multiple
exits. Such iteration branches can be found using The above Algorithm.
Thanks Regards
Ajit
Thanks,
bin
Thanks Regards
Ajit
-Original Message-
From: gcc-patches-ow...@gcc.gnu.org
[mailto:gcc-patches-ow...@gcc.gnu.org] On Behalf Of Bin.Cheng
Sent: Monday, August 17, 2015 3:32 PM
To: Richard Biener
Cc: Bin Cheng; GCC Patches
Subject: Re: [PATCH GCC]Improve bound information in loop niter
analysis
Thanks for all your reviews.
On Fri, Aug 14, 2015 at 4:17 PM, Richard Biener richard.guent...@gmail.com
wrote:
On Tue, Jul 28, 2015 at 11:36 AM, Bin Cheng bin.ch...@arm.com wrote:
Hi,
Loop niter computes inaccurate bound information for different loops.
This patch is to improve it by using loop initial condition in
determine_value_range. Generally, loop niter is computed by
subtracting start var from end var in loop exit condition.
Moreover, loop bound is computed using value range information of both
start and end variables.
Basic idea of this patch is to check if loop initial condition
implies more range information for both start/end variables. If
yes, we refine range information and use that to compute loop bound.
With this improvement, more accurate loop bound information is
computed for test cases added by this patch.
+ c0 = fold_convert (type, c0);
+ c1 = fold_convert (type, c1);
+
+ if (operand_equal_p (var, c0, 0))
I believe if c0 is not already of type type operand-equal_p will never
succeed.
It's quite specific case targeting comparison between var and it's range
bounds. Given c0 is in form of var + offc0, then the comparison var +
offc0 != range bounds doesn't have any useful information. Maybe useless
type conversion can be handled here though, it might be even corner case.
(side-note: we should get rid of the GMP use, that's expensive and
now we have wide-int available which should do the trick as well)
+ /* Case of comparing with the bounds of the type. */
+ if (TYPE_MIN_VALUE (type)
+ operand_equal_p (c1, TYPE_MIN_VALUE (type), 0))
+ cmp = GT_EXPR;
+ if (TYPE_MAX_VALUE (type)
+ operand_equal_p (c1, TYPE_MAX_VALUE (type), 0))
+ cmp = LT_EXPR;
don't use TYPE_MIN/MAX_VALUE. Instead use the types precision and
all wide_int operations (see match.pd wi::max_value use).
Done.
+
Re: [PATCH][AARCH64] Make arm_align_max_stack_pwr.c and arm_align_max_pwr.c compile testcase, instead of execution.
On 28 July 2015 at 16:51, Renlin Li renlin...@arm.com wrote: 2015-07-28 Renlin Li renlin...@arm.com * gcc.target/aarch64/arm_align_max_pwr.c: Make it a compile test case, check the assembly. * gcc.target/aarch64/arm_align_max_stack_pwr.c: Likewise. Hi, #include stdio.h #include assert.h Test cases should not rely on external headers, see https://gcc.gnu.org/wiki/HowToPrepareATestcase and it looks like neither of these headers are actually required so OK with the includes removed (and tested). Cheers /Marcus
Re: [PATCH GCC]Improve bound information in loop niter analysis
On Tue, Aug 18, 2015 at 4:02 PM, Ajit Kumar Agarwal
ajit.kumar.agar...@xilinx.com wrote:
-Original Message-
From: Bin.Cheng [mailto:amker.ch...@gmail.com]
Sent: Tuesday, August 18, 2015 1:08 PM
To: Ajit Kumar Agarwal
Cc: Richard Biener; Bin Cheng; GCC Patches; Vinod Kathail; Shail Aditya
Gupta; Vidhumouli Hunsigida; Nagaraju Mekala
Subject: Re: [PATCH GCC]Improve bound information in loop niter analysis
On Mon, Aug 17, 2015 at 6:49 PM, Ajit Kumar Agarwal
ajit.kumar.agar...@xilinx.com wrote:
All:
Does the Logic to calculate the Loop bound information through Value
Range Analyis uses the post dominator and Dominator info. The iteration
branches instead of Loop exit condition can be calculated through post
dominator info.
If the node in the Loop has two successors and post dominates the two
successors then the iteration branch can be The same node.
For All the nodes L in the Loop B
If (L1, L2 belongs to successors of (L) L1,L2 belongs to
PosDom(Header of Loop)) {
I = I union L1
}
Thus I will have all set of iteration branches. This will handle
more cases of Loop bound information that Will be accurate through the
exact iteration count that are known cases along with Value Range
Information Where the condition is instead not the Loop exits but other
nodes in the Loop.
I don't quite follow your words here. Could you please give a simple
example about it? Especially I don't know how post-dom helps the loop bound
analysis. Seems your pseudo code is collecting some comparison basic
block of loop?
The Algorithm I have given above is based on Post Dominator Info. This helps
to calculate the iteration branches. The iteration branches are the
Branches that determine the loop exit condition. Based on the condition it
either branches to the header of the Loop, Or it may branch to the
Block dominated by the header or exit from the loop. The above Algorithm
finds out such iteration branches and thus decides on the Loop bound
Or iteration count. If such iteration branches are not at the back edge node
and it may be a node inside the loop based on some conditions.
Finding out such iteration branches can be done through the post dominator
info using the above algorithm. Based on the iteration branches the
conditions can be analyzed and that helps in finding out the iteration bound
for Known cases. Know cases are the cases where the loop bound can be
determined at compile time.
One Example would be Multi-Exits Loops where the Loop exit condition can be
at the back edge or it may be a block inside the Loop based on the
IF conditions and breaks out based on the conditions. Thus having multiple
exits. Such iteration branches can be found using The above Algorithm.
As far as I understand, GCC already do loop niter analysis one the
basis of exit edge (and the corresponding block and condition). And
yes, it uses scev/vrp information for the analysis. The original
patch is to improve the analysis with flow sensitive range
information. It's not about GCC can't work on exit edge.
Thanks,
bin
Thanks Regards
Ajit
Thanks,
bin
Thanks Regards
Ajit
-Original Message-
From: gcc-patches-ow...@gcc.gnu.org
[mailto:gcc-patches-ow...@gcc.gnu.org] On Behalf Of Bin.Cheng
Sent: Monday, August 17, 2015 3:32 PM
To: Richard Biener
Cc: Bin Cheng; GCC Patches
Subject: Re: [PATCH GCC]Improve bound information in loop niter
analysis
Thanks for all your reviews.
On Fri, Aug 14, 2015 at 4:17 PM, Richard Biener richard.guent...@gmail.com
wrote:
On Tue, Jul 28, 2015 at 11:36 AM, Bin Cheng bin.ch...@arm.com wrote:
Hi,
Loop niter computes inaccurate bound information for different loops.
This patch is to improve it by using loop initial condition in
determine_value_range. Generally, loop niter is computed by
subtracting start var from end var in loop exit condition.
Moreover, loop bound is computed using value range information of both
start and end variables.
Basic idea of this patch is to check if loop initial condition
implies more range information for both start/end variables. If
yes, we refine range information and use that to compute loop bound.
With this improvement, more accurate loop bound information is
computed for test cases added by this patch.
+ c0 = fold_convert (type, c0);
+ c1 = fold_convert (type, c1);
+
+ if (operand_equal_p (var, c0, 0))
I believe if c0 is not already of type type operand-equal_p will never
succeed.
It's quite specific case targeting comparison between var and it's range
bounds. Given c0 is in form of var + offc0, then the comparison var +
offc0 != range bounds doesn't have any useful information. Maybe useless
type conversion can be handled here though, it might be even corner case.
(side-note: we should get rid of the GMP use, that's expensive and
now we have wide-int available which should do the trick as well)
+ /* Case of comparing
[Bug fortran/67250] gfortran does not faithfully preprocess the way cpp does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67250 --- Comment #10 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Jeff Hammond from comment #9) First, you will not accept the fusion of cpp+gfortran behavior as a feature request? Is there a reason other than you do not want to do it because you are already busy? Because you are mixing two different things together. Patches are welcome really. Second, true, but that doesn't stop gcc from supporting inline assembly outside of ISO C11, or stop gfortran from being compatible with vendor implementations of https://gcc.gnu.org/onlinedocs/gfortran/Cray-pointers.html, or of supporting any number of other non-standard features. In short, it's not in the standard, therefore it's fine to break user experience seems pretty weak here. It's fine if you tell me that you do not care about my needs and will not implement it, but please don't use ISO as the excuse. No that is not what I am saying. What I am saying is since it is non-standard different compilers will decide to support it differently. In this case gfortran is following what was done for g77. So changing it will break user experience for folks who have used g77.
Re: [PATCH 5/5][ARM] Move initializer into arm-cores.def and arm-arches.def.
On Mon, Aug 10, 2015 at 1:00 PM, Matthew Wahab matthew.wa...@foss.arm.com wrote: The ARM backend uses an unsigned long to record CPU feature flags and there are currently 30 bits in use. This series of patches replaces the single unsigned long with a representation based on an array of values. This patch updates the entries in the arm-core.def and arm-arches.def files to for the new arm_feature_set representation, moving the initializers from a macro expansion and making them explicit in the file entries. Tested the series for arm-none-linux-gnueabihf with native bootstrap and make check. gcc/ 2015-08-10 Matthew Wahab matthew.wa...@arm.com * config/arm/arm-arches.def: Replace single value flags with initializer built from ARM_FSET_MAKE_CPU1. * config/arm/arm-cores.def: Likewise. * config/arm/arm.c: (all_cores): Remove ARM_FSET_MAKE_CPU1 derivation from the ARM_CORE macro definition, use the given value instead. (all_architectures): Remove ARM_FSET_MAKE_CPU1 derivation from the ARM_ARCH macro definition, use the given value instead. Please update the comment at the top level of arm-arches.def and arm-cores.def to reflect this change with respect to FLAGS. Ok with that change. Ramana
[Bug tree-optimization/67253] [6 Regression] ICE at -O3 on x86_64-linux-gnu (verify_gimple failed)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67253 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-checking, ||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2015-08-18 Known to work||5.2.1 Target Milestone|--- |6.0 Summary|ICE at -O3 on |[6 Regression] ICE at -O3 |x86_64-linux-gnu|on x86_64-linux-gnu |(verify_gimple failed) |(verify_gimple failed) Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed, exposed by inlining.
[Bug c++/67257] New: Internal compiler error in retrieve_specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67257 Bug ID: 67257 Summary: Internal compiler error in retrieve_specialization Product: gcc Version: 5.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jasterrett at gmail dot com Target Milestone: --- Created attachment 36199 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36199action=edit Preprocessed code Attached find the preprocessed code. System is Linux Mint 17.2 Cinnamon 64-bit, running as guest in Oracle VirtualBox. g++ -v yields: Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/5.2.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-5.2.0/configure --enable-languages=c,c++ --program-suffix=-5.2.0 --enable-shared --enable-threads=posix enable-libstdcxx-debug --enable-plugin --disable-werror --disable-multilib Thread model: posix gcc version 5.2.0 (GCC) Compiled as: g++ -std=c++14 -Wall -Wextra -pedantic -o test Matrix.tcc --save-temps Error message: Matrix.tcc: In substitution of ‘templateclass Func templateclass T, class ... Args T _foldl::operator()(T, Args ...) [with T = missing; Args = missing; Func = int]’: Matrix.tcc:34:51: required from here Matrix.tcc:34:51: internal compiler error: in retrieve_specialization, at cp/pt.c:1060 std::cout foldlstd::plusint(1, 2, 3, 4, 5) std::endl; ^ 0x6452a3 retrieve_specialization ../../gcc-5.2.0/gcc/cp/pt.c:1057 0x6596ae instantiate_template_1 ../../gcc-5.2.0/gcc/cp/pt.c:16038 0x6596ae instantiate_template(tree_node*, tree_node*, int) ../../gcc-5.2.0/gcc/cp/pt.c:16151 0x65e239 fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node* const*, unsigned int, tree_node*, unification_kind_t, int, bool, bool) ../../gcc-5.2.0/gcc/cp/pt.c:16500 0x61b6d9 add_template_candidate_real ../../gcc-5.2.0/gcc/cp/call.c:3067 0x61bd5c add_template_candidate ../../gcc-5.2.0/gcc/cp/call.c:3164 0x61bd5c add_candidates ../../gcc-5.2.0/gcc/cp/call.c:5295 0x61ff87 build_op_call_1 ../../gcc-5.2.0/gcc/cp/call.c:4281 0x61ff87 build_op_call(tree_node*, vectree_node*, va_gc, vl_embed**, int) ../../gcc-5.2.0/gcc/cp/call.c:4368 0x6e73b8 finish_call_expr(tree_node*, vectree_node*, va_gc, vl_embed**, bool, bool, int) ../../gcc-5.2.0/gcc/cp/semantics.c:2426 0x69b691 cp_parser_postfix_expression ../../gcc-5.2.0/gcc/cp/parser.c:6375 0x69db29 cp_parser_unary_expression ../../gcc-5.2.0/gcc/cp/parser.c:7438 0x69e997 cp_parser_simple_cast_expression ../../gcc-5.2.0/gcc/cp/parser.c:23892 0x69e997 cp_parser_binary_expression ../../gcc-5.2.0/gcc/cp/parser.c:8230 0x69ec9d cp_parser_assignment_expression ../../gcc-5.2.0/gcc/cp/parser.c:8430 0x6a1011 cp_parser_expression ../../gcc-5.2.0/gcc/cp/parser.c:8584 0x6a16c6 cp_parser_expression_statement ../../gcc-5.2.0/gcc/cp/parser.c:9991 0x698305 cp_parser_statement ../../gcc-5.2.0/gcc/cp/parser.c:9842 0x698e92 cp_parser_statement_seq_opt ../../gcc-5.2.0/gcc/cp/parser.c:10114 0x698fc3 cp_parser_compound_statement ../../gcc-5.2.0/gcc/cp/parser.c:10068 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions.
[Bug c/67255] -Wpadded mixes apostrophes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67255 --- Comment #2 from Дилян Палаузов dilyan.palauzov at aegee dot org --- git clone https://cgit.cyrus.foundation/cyrus-imapd cd cyrus-imapd libtoolize autoreconf -i CFLAGS=-Wpadded ./configure --with-sqlite make 21 | grep righ | sort -u prints: imap/append.h:62:9: warning: padding struct to align 'myrights' [-Wpadded] imap/append.h:62:9: warning: padding struct to align ‘myrights’ [-Wpadded] int myrights;
[Bug c/67255] -Wpadded mixes apostrophes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67255 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-08-18 Ever confirmed|0 |1 --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- No, please provide a stand-alone testcase. See http://bugzilla.redhat.com/bugzilla for instructions.
[Bug libstdc++/67256] [C++11] Global scope contaminated with symbols from mathcalls.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67256 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- N.B. the functions happen to be declared in bits/mathcalls.h but they are standard functions declared in math.h and so your code would already have failed to compile in C++03 if anyone included math.h (and the same applies for cmath when that is implemented in terms of math.h, which is permitted by the text I quoted from the standard).
Re: [PATCH] Add extensions to dwarf2.def
On 18 August 2015 at 14:38, Pierre-Marie de Rodat dero...@adacore.com wrote: I think it would be great to copy this text in GCC's: may I do this? Sorry, I did it before I read your message. For the future, I would advise to Just Do It and then say that you did it. It is a wiki, it can always be reverted if someone disagrees. Perhaps it would be great if the GNU tools did not have some much duplicated infrastructure (and inconsistent red-tape), but oh well... Cheers, Manuel.
Re: [PATCH] Add extensions to dwarf2.def
On 08/18/2015 02:47 PM, Manuel López-Ibáñez wrote: Sorry, I did it before I read your message. For the future, I would advise to Just Do It and then say that you did it. It is a wiki, it can always be reverted if someone disagrees. Sure, I have no problem with the paternity of this change. ;-) Thank you! I will just do it next time. -- Pierre-Marie de Rodat
Re: [PATCH] Fix ICE with bogus posix_memalign call (PR middle-end/67222)
On Tue, Aug 18, 2015 at 1:10 PM, Marek Polacek pola...@redhat.com wrote:
On Tue, Aug 18, 2015 at 12:47:45PM +0200, Richard Biener wrote:
Please instead change the tree-ssa-alias.c code to do
if (callee != NULL
gimple_call_builtin_p (call, BUILT_IN_NORMAL))
switch (DECL_FUNCTION_CODE (callee))
...
Ok. I see that works as well because gimple_call_builtin_p uses
gimple_builtin_call_types_compatible_p.
which should also fix quite a few issues in the other builtin handlings.
Likewise can you change stmt_kills_ref_p and ref_maybe_used_by_call_p_1
in a similar way?
Sure. Regtest/bootstrap running, ok for trunk/5 if it passes?
Ok.
Thanks,
Richard.
2015-08-18 Marek Polacek pola...@redhat.com
PR middle-end/67222
* gimple-low.c (lower_stmt): Don't lower BUILT_IN_POSIX_MEMALIGN
if the call isn't valid.
* tree-ssa-alias.c (ref_maybe_used_by_call_p_1): Check builtins using
gimple_call_builtin_p.
(call_may_clobber_ref_p_1): Likewise.
(stmt_kills_ref_p): Likewise.
* gcc.dg/torture/pr67222.c: New test.
diff --git gcc/gimple-low.c gcc/gimple-low.c
index d4697e2..4eae3a0 100644
--- gcc/gimple-low.c
+++ gcc/gimple-low.c
@@ -346,7 +346,8 @@ lower_stmt (gimple_stmt_iterator *gsi, struct lower_data
*data)
return;
}
else if (DECL_FUNCTION_CODE (decl) == BUILT_IN_POSIX_MEMALIGN
- flag_tree_bit_ccp)
+ flag_tree_bit_ccp
+ gimple_builtin_call_types_compatible_p (stmt, decl))
{
lower_builtin_posix_memalign (gsi);
return;
diff --git gcc/testsuite/gcc.dg/torture/pr67222.c
gcc/testsuite/gcc.dg/torture/pr67222.c
index e69de29..739f869 100644
--- gcc/testsuite/gcc.dg/torture/pr67222.c
+++ gcc/testsuite/gcc.dg/torture/pr67222.c
@@ -0,0 +1,19 @@
+/* PR middle-end/67222 */
+/* { dg-do compile } */
+
+void
+foo (void **p)
+{
+ posix_memalign (); /* { dg-warning implicit declaration } */
+ posix_memalign (p);
+ posix_memalign (0);
+ posix_memalign (p, 1);
+ posix_memalign (p, foo);
+ posix_memalign (gnu, gcc);
+ posix_memalign (1, p);
+ posix_memalign (1, 2);
+ posix_memalign (1, 2, 3);
+ posix_memalign (p, p, p);
+ posix_memalign (p, qui, 3);
+ posix_memalign (p, 1, 2);
+}
diff --git gcc/tree-ssa-alias.c gcc/tree-ssa-alias.c
index e103220..0445052 100644
--- gcc/tree-ssa-alias.c
+++ gcc/tree-ssa-alias.c
@@ -1535,7 +1535,7 @@ ref_maybe_used_by_call_p_1 (gcall *call, ao_ref *ref)
escape points. See tree-ssa-structalias.c:find_func_aliases
for the list of builtins we might need to handle here. */
if (callee != NULL_TREE
- DECL_BUILT_IN_CLASS (callee) == BUILT_IN_NORMAL)
+ gimple_call_builtin_p (call, BUILT_IN_NORMAL))
switch (DECL_FUNCTION_CODE (callee))
{
/* All the following functions read memory pointed to by
@@ -1941,7 +1941,7 @@ call_may_clobber_ref_p_1 (gcall *call, ao_ref *ref)
escape points. See tree-ssa-structalias.c:find_func_aliases
for the list of builtins we might need to handle here. */
if (callee != NULL_TREE
- DECL_BUILT_IN_CLASS (callee) == BUILT_IN_NORMAL)
+ gimple_call_builtin_p (call, BUILT_IN_NORMAL))
switch (DECL_FUNCTION_CODE (callee))
{
/* All the following functions clobber memory pointed to by
@@ -2341,7 +2341,7 @@ stmt_kills_ref_p (gimple stmt, ao_ref *ref)
{
tree callee = gimple_call_fndecl (stmt);
if (callee != NULL_TREE
- DECL_BUILT_IN_CLASS (callee) == BUILT_IN_NORMAL)
+ gimple_call_builtin_p (stmt, BUILT_IN_NORMAL))
switch (DECL_FUNCTION_CODE (callee))
{
case BUILT_IN_FREE:
Marek
RE: [PING][Patch] Add support for IEEE-conformant versions of scalar fmin* and fmax*
On Mon, Aug 17, 2015 at 11:29 AM, David Sherwood david.sherw...@arm.com wrote: Hi Richard, Thanks for the reply. I'd chosen to add new expressions as this seemed more consistent with the existing MAX_EXPR and MIN_EXPR tree codes. In addition it would seem to provide more opportunities for optimisation than a target-specific builtin implementation would. I accept that optimisation opportunities will be more limited for strict math compilation, but that it was still worth having them. Also, if we did map it to builtins then the scalar version would go through the optabs and the vector version would go through the target's builtin expansion, which doesn't seem very consistent. On another note ISTR you can't associate STRICT_MIN/MAX_EXPR and thus you can't vectorize anyway? (strict IEEE behavior is about NaNs, correct?) I thought for this particular case associativity wasn't an issue? We're not doing any reductions here, just simply performing max/min operations on each pair of elements in the vectors. I thought for IEEE-compliant behaviour we just need to ensure that for each pair of elements if one element is a NaN we return the other one. David. Richard. Regards, David. -Original Message- From: Richard Biener [mailto:richard.guent...@gmail.com] Sent: 13 August 2015 12:10 To: David Sherwood Cc: GCC Patches Subject: Re: [PING][Patch] Add support for IEEE-conformant versions of scalar fmin* and fmax* On Thu, Aug 13, 2015 at 12:11 PM, David Sherwood david.sherw...@arm.com wrote: Hi, Sorry to bother people again. Is this OK to go now? Hmm, why don't you go the vectorized function call path for this, implementing the builtin_vectorized_function target hook? Richard. Thanks! David. On Mon, 29 Jun 2015, David Sherwood wrote: Hi, I have added new STRICT_MAX_EXPR and STRICT_MIN_EXPR expressions to support the IEEE versions of fmin and fmax. This is done by recognising the math library fmax and fmin builtin functions in a similar way to how this is done for -ffast-math. This also allows us to vectorise the IEEE max/min functions for targets that support it, for example aarch64/aarch32. This patch is missing documentation. You need to document the new insn patterns in md.texi and the new tree codes in generic.texi. Hi, I've uploaded a new patch with the documentation. Hope this is ok. In various places where you refer to one operand being NaN, I think you mean one operand being a *quiet* NaN (if one is a signaling NaN - only supported by GCC if -fsignaling-nans - the IEEE minNum and maxNum operations raise invalid and return a quiet NaN). Hi, I have a new patch that hopefully addresses the documentation issues. Thanks, David. ChangeLog: 2015-07-15 David Sherwood david.sherw...@arm.com gcc/ * builtins.c (integer_valued_real_p): Add STRICT_MIN_EXPR and STRICT_MAX_EXPR. (fold_builtin_fmin_fmax): For strict math, convert builting fmin and fmax to STRICT_MIN_EXPR and STRICT_MIN_EXPR, respectively. * expr.c (expand_expr_real_2): Add STRICT_MIN_EXPR and STRICT_MAX_EXPR. * fold-const.c (const_binop): Likewise. (fold_binary_loc, tree_binary_nonnegative_warnv_p): Likewise. (tree_binary_nonzero_warnv_p): Likewise. * optabs.h (strict_minmax_support): Declare. * optabs.def: Add new optabs strict_max_optab/strict_min_optab. * optabs.c (optab_for_tree_code): Return new optabs for STRICT_MIN_EXPR and STRICT_MAX_EXPR. (strict_minmax_support): New function. * real.c (real_arithmetic): Add STRICT_MIN_EXPR and STRICT_MAX_EXPR. * tree.def: Likewise. * tree.c (associative_tree_code, commutative_tree_code): Likewise. * tree-cfg.c (verify_expr): Likewise. (verify_gimple_assign_binary): Likewise. * tree-inline.c (estimate_operator_cost): Likewise. * tree-pretty-print.c (dump_generic_node, op_code_prio): Likewise. (op_symbol_code): Likewise. gcc/config: * aarch64/aarch64.md: New pattern. * aarch64/aarch64-simd.md: Likewise. * aarch64/iterators.md: New unspecs, iterators. * arm/iterators.md: New iterators. * arm/unspecs.md: New unspecs. * arm/neon.md: New pattern. * arm/vfp.md: Likewise. gcc/doc: * generic.texi: Add STRICT_MAX_EXPR and STRICT_MIN_EXPR. * md.texi: Add strict_min and strict_max patterns. gcc/testsuite * gcc.target/aarch64/maxmin_strict.c: New test. * gcc.target/arm/maxmin_strict.c: New test.
[patch] libstdc++/67066 disable concept checks for C++11 and up
This fixes a bootstrap failure with --enable-concept-checks, caused by
the Filesystem code (built as C++14) not meeting the C++03 concept
requirements for containers.
I think building with --enable-concept-checks is crazy nowadays but
this at least makes it possible.
Rather than trying to fix the concept checks to understand move-only
types I'm just disabling the relevant checks in C++11 mode.
Tested powerpc64le-linux, committing to trunk.
commit cdb1515df059a1dadddf0121d0d8163ee50b3cf4
Author: Jonathan Wakely jwak...@redhat.com
Date: Tue Aug 18 11:21:37 2015 +0100
PR libstdc++/67066
* doc/xml/manual/configure.xml (manual.intro.setup.configure): Add
caveats for --enable-concept-checks. Improve link text.
* doc/xml/manual/diagnostics.xml (std.diagnostics.concept_checking):
Clarify caveats.
* doc/html/*: Regenerate.
* include/bits/stl_deque.h (deque): Only use concept checks in C++03.
* include/bits/stl_stack.h (stack): Likewise.
* include/bits/stl_vector.h (vector): Likewise.
diff --git a/libstdc++-v3/doc/xml/manual/configure.xml b/libstdc++-v3/doc/xml/manual/configure.xml
index a76b80c..2f558d2 100644
--- a/libstdc++-v3/doc/xml/manual/configure.xml
+++ b/libstdc++-v3/doc/xml/manual/configure.xml
@@ -288,10 +288,12 @@
varlistentrytermcode--enable-concept-checks/code/term
listitemparaThis turns on additional compile-time checks for instantiated
- library templates, in the form of specialized templates,
- link linkend=std.diagnostics.concept_checkingdescribed here/link. They
+ library templates, in the form of specialized templates described in
+the link linkend=std.diagnostics.concept_checkingConcept
+Checking/link section. They
can help users discover when they break the rules of the STL, before
- their programs run.
+ their programs run. These checks are based on C++03 rules and some of
+ them are not compatible with correct C++11 code.
/para
/listitem/varlistentry
diff --git a/libstdc++-v3/doc/xml/manual/diagnostics.xml b/libstdc++-v3/doc/xml/manual/diagnostics.xml
index 99206e9..88ed2e2 100644
--- a/libstdc++-v3/doc/xml/manual/diagnostics.xml
+++ b/libstdc++-v3/doc/xml/manual/diagnostics.xml
@@ -114,8 +114,9 @@
para
Please note that the checks are based on the requirements in the original
- C++ standard, some of which have changed in the new C++11 revision.
- Additionally, some correct code might be rejected by the concept checks,
+ C++ standard, many of which were relaxed in the C++11 standard and so valid
+ C++11 code may be incorrectly rejected by the concept checks. Additionally,
+ some correct C++03 code might be rejected by the concept checks,
for example template argument types may need to be complete when used in
a template definition, rather than at the point of instantiation.
There are no plans to address these shortcomings.
diff --git a/libstdc++-v3/include/bits/stl_deque.h b/libstdc++-v3/include/bits/stl_deque.h
index 50570ef..f674245 100644
--- a/libstdc++-v3/include/bits/stl_deque.h
+++ b/libstdc++-v3/include/bits/stl_deque.h
@@ -829,7 +829,9 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
{
// concept requirements
typedef typename _Alloc::value_type_Alloc_value_type;
+#if __cplusplus 201103L
__glibcxx_class_requires(_Tp, _SGIAssignableConcept)
+#endif
__glibcxx_class_requires2(_Tp, _Alloc_value_type, _SameTypeConcept)
typedef _Deque_base_Tp, _Alloc _Base;
diff --git a/libstdc++-v3/include/bits/stl_stack.h b/libstdc++-v3/include/bits/stl_stack.h
index 0ed212e..09dd611 100644
--- a/libstdc++-v3/include/bits/stl_stack.h
+++ b/libstdc++-v3/include/bits/stl_stack.h
@@ -100,8 +100,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
{
// concept requirements
typedef typename _Sequence::value_type _Sequence_value_type;
+#if __cplusplus 201103L
__glibcxx_class_requires(_Tp, _SGIAssignableConcept)
__glibcxx_class_requires(_Sequence, _BackInsertionSequenceConcept)
+#endif
__glibcxx_class_requires2(_Tp, _Sequence_value_type, _SameTypeConcept)
templatetypename _Tp1, typename _Seq1
diff --git a/libstdc++-v3/include/bits/stl_vector.h b/libstdc++-v3/include/bits/stl_vector.h
index 8407a15..305d446 100644
--- a/libstdc++-v3/include/bits/stl_vector.h
+++ b/libstdc++-v3/include/bits/stl_vector.h
@@ -215,7 +215,9 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
{
// Concept requirements.
typedef typename _Alloc::value_type_Alloc_value_type;
+#if __cplusplus 201103L
__glibcxx_class_requires(_Tp, _SGIAssignableConcept)
+#endif
__glibcxx_class_requires2(_Tp, _Alloc_value_type, _SameTypeConcept)
typedef _Vector_base_Tp, _Alloc _Base;
RE: [PATCH][MIPS] Fix register renaming in the interrupt handlers
Hi, gcc/ * config/mips/mips-protos.h (mips_hard_regno_rename_ok): New prototype. * config/mips/mips.c (mips_hard_regno_rename_ok): New function. (mips_hard_regno_scratch_ok): Likewise. (TARGET_HARD_REGNO_SCRATCH_OK): Define macro. * config/mips/mips.h (HARD_REGNO_RENAME_OK): New. gcc/testsuite/ * gcc.target/mips/interrupt_handler-bug-1.c: New test. --- Based on the feedback from Richard and Mike, this looks OK now. Thanks, Catherine Committed as r226968. I slightly modified the test to search for ^isr:.*\\\$8.*isr instead of just \\\$8 as with the ToT compiler 2 tests failed with -flto. It happened that $8 appeared in the LTO bytecode. Changed as obvious. Regards, Robert
[Bug sanitizer/67258] New: invalid vptr false positive from ubsan for virtual inheritance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67258 Bug ID: 67258 Summary: invalid vptr false positive from ubsan for virtual inheritance Product: gcc Version: 5.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: arvo at me dot com CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org Target Milestone: --- Created attachment 36200 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36200action=edit Minimal test program that triggers invalid vptr message from ubsan Building the attached minimal test program, which should be free of undefined behavior, with --sanitize=undefined and executing it yields: ubsan-virtual.cxx:7:8: runtime error: member call on address 0x7fff43c04a20 which does not point to an object of type 'A' 0x7fff43c04a20: note: object has invalid vptr 00 00 00 00 40 18 40 00 00 00 00 00 18 18 40 00 00 00 00 00 20 4b c0 43 ff 7f 00 00 00 3c c4 4f ^~~ invalid vptr
[Bug c/67255] -Wpadded mixes apostrophes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67255 Дилян Палаузов dilyan.palauzov at aegee dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #6 from Дилян Палаузов dilyan.palauzov at aegee dot org --- Indeed, the problem is not in GCC. Updating libtool 2.4.2 - 2.4.6 solved the problem.
[C++ Patch] PR 67160 (static_assert feature test macro)
Hi,
submitter noticed that we have the extended static_assert but the value
of the feature macro is still unconditionally 200410, whereas, eg,
http://wg21.link/n4440#recs.cpp17 , has 201411.
Submitter proposes to unconditionally, thus in c++11 and c++14 modes
too, bump the value, but thinking more about the issue, I guess we want
that only in c++1z, the only mode which doesn't trigger a pedwarn for
those extended features, consistently, with eg, __cpp_init_captures
which is defined only in c++14 and and c++1z but only triggers a pedwarn
in c++11. Thus a slightly larger patch.
Tested x86_64-linux.
Thanks,
Paolo.
/
c-family/
2015-08-18 Paolo Carlini paolo.carl...@oracle.com
PR c++/67160
* c-cppbuiltin.c (c_cpp_builtins): Fix __cpp_static_assert value
in c++1z mode.
testsuite/
2015-08-18 Paolo Carlini paolo.carl...@oracle.com
PR c++/67160
* g++.dg/cpp1z/feat-cxx1z.C: New.
Index: c-family/c-cppbuiltin.c
===
--- c-family/c-cppbuiltin.c (revision 226966)
+++ c-family/c-cppbuiltin.c (working copy)
@@ -832,7 +832,7 @@ c_cpp_builtins (cpp_reader *pfile)
if (cxx_dialect = cxx11)
{
- /* Set feature test macros for C++11 */
+ /* Set feature test macros for C++11. */
cpp_define (pfile, __cpp_unicode_characters=200704);
cpp_define (pfile, __cpp_raw_strings=200710);
cpp_define (pfile, __cpp_unicode_literals=200710);
@@ -841,7 +841,8 @@ c_cpp_builtins (cpp_reader *pfile)
if (cxx_dialect == cxx11)
cpp_define (pfile, __cpp_constexpr=200704);
cpp_define (pfile, __cpp_range_based_for=200907);
- cpp_define (pfile, __cpp_static_assert=200410);
+ if (cxx_dialect = cxx14)
+ cpp_define (pfile, __cpp_static_assert=200410);
cpp_define (pfile, __cpp_decltype=200707);
cpp_define (pfile, __cpp_attributes=200809);
cpp_define (pfile, __cpp_rvalue_reference=200610);
@@ -855,7 +856,7 @@ c_cpp_builtins (cpp_reader *pfile)
}
if (cxx_dialect cxx11)
{
- /* Set feature test macros for C++14 */
+ /* Set feature test macros for C++14. */
cpp_define (pfile, __cpp_return_type_deduction=201304);
cpp_define (pfile, __cpp_init_captures=201304);
cpp_define (pfile, __cpp_generic_lambdas=201304);
@@ -865,6 +866,11 @@ c_cpp_builtins (cpp_reader *pfile)
cpp_define (pfile, __cpp_variable_templates=201304);
cpp_define (pfile, __cpp_digit_separators=201309);
}
+ if (cxx_dialect cxx14)
+ {
+ /* Set feature test macros for C++1z. */
+ cpp_define (pfile, __cpp_static_assert=201411);
+ }
if (flag_concepts)
/* Use a value smaller than the 201507 specified in
the TS, since we don't yet support extended auto. */
Index: testsuite/g++.dg/cpp1z/feat-cxx1z.C
===
--- testsuite/g++.dg/cpp1z/feat-cxx1z.C (revision 0)
+++ testsuite/g++.dg/cpp1z/feat-cxx1z.C (working copy)
@@ -0,0 +1,7 @@
+// { dg-do compile { target c++1z } }
+
+#ifndef __cpp_static_assert
+# error __cpp_static_assert
+#elif __cpp_static_assert != 201411
+# error __cpp_static_assert != 201411
+#endif
[Bug c/67255] New: -Wpadded mixes apostrophes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67255 Bug ID: 67255 Summary: -Wpadded mixes apostrophes Product: gcc Version: 5.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dilyan.palauzov at aegee dot org Target Milestone: --- gcc -Wpadded produces output like: file.h:10:3: warning: padding struct to align 'z' [-Wpadded] and like file.h:10:3: warning: padding struct to align ‘z’ [-Wpadded] note the different apostrophe styles around z. When I try to compile a project with -Wpadded, I filter stderr through sort -u, but some lines appear twice, because of the different apostrophes used by gcc.
[Bug c/67255] -Wpadded mixes apostrophes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67255 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Do you have a testcase?
[Bug c/67236] New: Wrong Message of -Wvla for Standard ISO C90 However Emitted with -std=c11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67236 Bug ID: 67236 Summary: Wrong Message of -Wvla for Standard ISO C90 However Emitted with -std=c11 Product: gcc Version: 6.0 Status: RESOLVED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: chengniansun at gmail dot com CC: mpolacek at gcc dot gnu.org Target Milestone: --- Status: RESOLVED CC: mpolacek at gcc dot gnu.org Resolution: DUPLICATE When I compile the code int array[4.3];, in addition to the error, GCC also emits a -Wvla warning saying that ISO C90 forbids this. However, I specify -std=c11 in the command line, and IMHO this is at least an inconsistency between errors and error messages. $: cat t.c int array[4.3]; $: gcc-trunk -c -Wvla -std=c11 -pedantic t.c t.c:1:5: error: size of array ‘array’ has non-integer type int array[4.3]; ^ t.c:1:1: warning: variably modified ‘array’ at file scope int array[4.3]; ^ t.c:1:1: warning: ISO C90 forbids array ‘array’ whose size can’t be evaluated [-Wvla] $: gcc-trunk -v Using built-in specs. COLLECT_GCC=gcc-trunk COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-trunk/configure --enable-languages=c,c++,objc,obj-c++,fortran,lto --disable-werror --with-gmp=/usr/local/gcc-trunk --with-mpfr=/usr/local/gcc-trunk --with-mpc=/usr/local/gcc-trunk --with-cloog=/usr/local/gcc-trunk --prefix=/usr/local/gcc-trunk Thread model: posix gcc version 6.0.0 20150815 (experimental) [trunk revision 226911] (GCC) $: --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- . *** This bug has been marked as a duplicate of bug 67243 ***
[Bug c/67243] Wrong Message of -Wvla for Standard ISO C90 However Emitted with -std=c11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67243 --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- *** Bug 67237 has been marked as a duplicate of this bug. ***
[Bug c/67237] New: Wrong Message of -Wvla for Standard ISO C90 However Emitted with -std=c11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67237 Bug ID: 67237 Summary: Wrong Message of -Wvla for Standard ISO C90 However Emitted with -std=c11 Product: gcc Version: 6.0 Status: RESOLVED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: chengniansun at gmail dot com CC: mpolacek at gcc dot gnu.org Target Milestone: --- Status: RESOLVED CC: mpolacek at gcc dot gnu.org Resolution: DUPLICATE When I compile the code int array[4.3];, in addition to the error, GCC also emits a -Wvla warning saying that ISO C90 forbids this. However, I specify -std=c11 in the command line, and IMHO this is at least an inconsistency between errors and error messages. $: cat t.c int array[4.3]; $: gcc-trunk -c -Wvla -std=c11 -pedantic t.c t.c:1:5: error: size of array ‘array’ has non-integer type int array[4.3]; ^ t.c:1:1: warning: variably modified ‘array’ at file scope int array[4.3]; ^ t.c:1:1: warning: ISO C90 forbids array ‘array’ whose size can’t be evaluated [-Wvla] $: gcc-trunk -v Using built-in specs. COLLECT_GCC=gcc-trunk COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-trunk/configure --enable-languages=c,c++,objc,obj-c++,fortran,lto --disable-werror --with-gmp=/usr/local/gcc-trunk --with-mpfr=/usr/local/gcc-trunk --with-mpc=/usr/local/gcc-trunk --with-cloog=/usr/local/gcc-trunk --prefix=/usr/local/gcc-trunk Thread model: posix gcc version 6.0.0 20150815 (experimental) [trunk revision 226911] (GCC) $: --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- . *** This bug has been marked as a duplicate of bug 67243 ***
[Bug c/67235] New: Wrong Message of -Wvla for Standard ISO C90 However Emitted with -std=c11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67235 Bug ID: 67235 Summary: Wrong Message of -Wvla for Standard ISO C90 However Emitted with -std=c11 Product: gcc Version: 6.0 Status: RESOLVED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: chengniansun at gmail dot com CC: mpolacek at gcc dot gnu.org Target Milestone: --- Status: RESOLVED CC: mpolacek at gcc dot gnu.org Resolution: DUPLICATE When I compile the code int array[4.3];, in addition to the error, GCC also emits a -Wvla warning saying that ISO C90 forbids this. However, I specify -std=c11 in the command line, and IMHO this is at least an inconsistency between errors and error messages. $: cat t.c int array[4.3]; $: gcc-trunk -c -Wvla -std=c11 -pedantic t.c t.c:1:5: error: size of array ‘array’ has non-integer type int array[4.3]; ^ t.c:1:1: warning: variably modified ‘array’ at file scope int array[4.3]; ^ t.c:1:1: warning: ISO C90 forbids array ‘array’ whose size can’t be evaluated [-Wvla] $: gcc-trunk -v Using built-in specs. COLLECT_GCC=gcc-trunk COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-trunk/configure --enable-languages=c,c++,objc,obj-c++,fortran,lto --disable-werror --with-gmp=/usr/local/gcc-trunk --with-mpfr=/usr/local/gcc-trunk --with-mpc=/usr/local/gcc-trunk --with-cloog=/usr/local/gcc-trunk --prefix=/usr/local/gcc-trunk Thread model: posix gcc version 6.0.0 20150815 (experimental) [trunk revision 226911] (GCC) $: --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- . *** This bug has been marked as a duplicate of bug 67243 ***
[Bug c++/67256] New: [C++11] Global scope contaminated with symbols from mathcalls.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67256
Bug ID: 67256
Summary: [C++11] Global scope contaminated with symbols from
mathcalls.h
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: michal.fita at gmail dot com
Target Milestone: ---
Created attachment 36198
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36198action=edit
The test code.
I have problem with GCC 4.9.2 on Jessie, where with -std=c++11 I cannot compile
my code. I attached the test example which compiles with:
g++ -o test g++mathcalls-error.cpp
But doesn't compile with:
g++ -o test -std=c++11 g++mathcalls-error.cpp
Producing following errors:
g++mathcalls-error.cpp:7:15: error: ‘namespace log { }’ redeclared as different
kind of symbol
namespace log {
^
In file included from /usr/include/features.h:374:0,
from
/usr/include/x86_64-linux-gnu/c++/4.9/bits/os_defines.h:39,
from
/usr/include/x86_64-linux-gnu/c++/4.9/bits/c++config.h:430,
from /usr/include/c++/4.9/utility:68,
from /usr/include/c++/4.9/algorithm:60,
from g++mathcalls-error.cpp:2:
/usr/include/x86_64-linux-gnu/bits/mathcalls.h:109:1: note: previous
declaration ‘double log(double)’
__MATHCALL (log,, (_Mdouble_ __x));
^
g++mathcalls-error.cpp:19:15: error: ‘namespace sin { }’ redeclared as
different kind of symbol
namespace sin {
^
In file included from /usr/include/features.h:374:0,
from
/usr/include/x86_64-linux-gnu/c++/4.9/bits/os_defines.h:39,
from
/usr/include/x86_64-linux-gnu/c++/4.9/bits/c++config.h:430,
from /usr/include/c++/4.9/utility:68,
from /usr/include/c++/4.9/algorithm:60,
from g++mathcalls-error.cpp:2:
/usr/include/x86_64-linux-gnu/bits/mathcalls.h:65:1: note: previous declaration
‘double sin(double)’
__MATHCALL (sin,, (_Mdouble_ __x));
^
g++mathcalls-error.cpp: In function ‘int main()’:
g++mathcalls-error.cpp:28:5: error: ‘log’ is not a class, namespace, or
enumeration
log::info(Test %s, sinner);
^
g++mathcalls-error.cpp:29:5: error: ‘sin’ is not a class, namespace, or
enumeration
sin::cardinal(666);
^
So, this may not be bug inside the compiler (however studies of inclusion chain
leads nowhere), but with the standard set of headers. This cause symbols
related to math functions be present in global scope instead of std namespace.
This effectively block us from using namespaces like log or sin in our huge
codebase if we want to move toward C++11 standard.
Re: [Patch/rtl-expand] Take tree range info into account to improve LSHIFT_EXP expanding
Jiong Wang writes: Jeff Law writes: On 08/14/2015 11:40 AM, Jiong Wang wrote: * Figuring out whether the shift source is coming from sign extension by checking SSA_NAME_DEF_STMT instead of deducing from tree range info. I fell checking the gimple statement is more reliable and straigtforward. I suspect it'll also apply more often if you're looking for the nop-conversion rather than looking at range information. I keep thinking there ought to be a generalization here so that we're not so restrictive on the modes, but it's probably not worth doing. In a perfect world we'd also integrate the other strategies for double-word shifts that exist in the various ports as special cases in expansion and remove the double-word shift patterns for ports that don't actually have them in hardware. But that's probably a bit much to ask -- however, it probably couldn't hurt to see if there are any that are easily handled. Agree. Doing these in early tree/rtl expand stage is more clean safe, and expose more details to later RTL optimization passes as I think if you handle double-word by defining insn pattern, then you will try to split it in RTL split pass which happens later after some important optimizations. + + If mode == GET_MODE_WIDER_MODE (word_mode), then normally there isn't + native instruction to support this wide mode left shift. Given below + example: + + Type A = (Type) B C + +| T | +| high | low | + + |- size -| + + By checking tree shape, if operand B is coming from signed extension, + then the left shift operand can be simplified into: + + 1. high = low (size - C); + 2. low = low C; You'll want to reorder those to match the code you generate. Doesn't this require that C be less than the bitsize of a word? Yes. Above transformation is to handle double word left shift which shift the original source across the word boundary. Part of the contents shifted into the high half of destination, and the other remain in the low half. So if C is bigger than bitsize of a word, the the whole source will be shifted into high half, thus should generate what you have listed below and that's what gcc is generating, looks like the existed double word shift logic can recognize this special cases. So, I should check the value of C,if it's bigger than bitsize of a word, then just fall through to default expand logic. If C is larger than the bitsize of a word, then you need some adjustments, something like: 1. high = low (C - size) 2. low = 0 Does this transformation require that the wider mode be exactly 2X the narrower mode? If so, that needs to be verified. I think so, the wider mode should be exactly 2X the word_mode, will add the check. + if (GET_MODE_SIZE (rmode) GET_MODE_SIZE (mode) So we're assured we have a widening conversion. +((TREE_INT_CST_LOW (treeop1) + GET_MODE_BITSIZE (rmode)) + = GET_MODE_BITSIZE (word_mode))) This test seems wrong. I'm not sure what you're really trying to test here. It seems you want to look at the shift count relative to the bitsize of word_mode. If it's less, then generate the code you mentioned above in the comment. If it's more, then generate the sequence I referenced? Right? As explained above, I am trying to check whether the left shift is causing the original source across word boundary while I should make sure TREE_INT_CST_LOW (treeop1) GET_MODE_BITSIZE (word_mode) at the same time, otherwise fall through to default expand logic. I do think you need to be verifying that rmode == wordmode here. If I understand everything correctly, the final value is mode which must be 2X the size size of rmode/wordmode here, right? I think rmode don't need to equal wordmode. For example the transformation is OK for the following, where rmode = SImode, and final mode = TImode. int b; __128_int a = (__128_int) b; the expand_expr (treeop0... in the start of those code will generate necessary instruction sequences to extend whatever mode b is into TImode register (op0 in the patch); The other question is are we endianness-safe in these transformations? I think it is. As this transformation is done with register involved only. I think endianness issue will only happen if there is operation on memory object. + temp = expand_variable_shift (code, word_mode, low, treeop1, + tlow, unsignedp); Why use code here right than just using LSHIFT_EXPR? As noted earlier, Yes, better to use the constant LSHIFT_EXPR. Thanks. patch updated, please review thanks. Changes are: 1. s/shfit/shift/ 2. Re-write the comment. more explanations on the left shift across word size boundary
[Bug c++/67256] [C++11] Global scope contaminated with symbols from mathcalls.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67256 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- 17.6.1.2 [headers] specifically says: It is unspecified whether these names are first declared within the global namespace scope and are then injected into namespace std by explicit using- declarations. A conforming implementation can define ::log and ::sin when any standard header is included, and so your code will never be portable if you reuse those names for namespaces.
[Bug libstdc++/67256] [C++11] Global scope contaminated with symbols from mathcalls.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67256 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Component|c++ |libstdc++ Severity|major |normal
Re: [PATCH] Add extensions to dwarf2.def
On 08/18/2015 02:15 PM, Pedro Alves wrote: The blurb at the top of glibc's page explains this: https://sourceware.org/glibc/wiki/EditorGroup [...] Looks like neither GCC's nor GDB's borrowed that longer text yet. Ok, understood. Thank you very much! I think it would be great to copy this text in GCC's: may I do this? -- Pierre-Marie de Rodat
Re: [PATCH] Fix ICE with bogus posix_memalign call (PR middle-end/67222)
On Tue, Aug 18, 2015 at 12:47:45PM +0200, Richard Biener wrote:
Please instead change the tree-ssa-alias.c code to do
if (callee != NULL
gimple_call_builtin_p (call, BUILT_IN_NORMAL))
switch (DECL_FUNCTION_CODE (callee))
...
Ok. I see that works as well because gimple_call_builtin_p uses
gimple_builtin_call_types_compatible_p.
which should also fix quite a few issues in the other builtin handlings.
Likewise can you change stmt_kills_ref_p and ref_maybe_used_by_call_p_1
in a similar way?
Sure. Regtest/bootstrap running, ok for trunk/5 if it passes?
2015-08-18 Marek Polacek pola...@redhat.com
PR middle-end/67222
* gimple-low.c (lower_stmt): Don't lower BUILT_IN_POSIX_MEMALIGN
if the call isn't valid.
* tree-ssa-alias.c (ref_maybe_used_by_call_p_1): Check builtins using
gimple_call_builtin_p.
(call_may_clobber_ref_p_1): Likewise.
(stmt_kills_ref_p): Likewise.
* gcc.dg/torture/pr67222.c: New test.
diff --git gcc/gimple-low.c gcc/gimple-low.c
index d4697e2..4eae3a0 100644
--- gcc/gimple-low.c
+++ gcc/gimple-low.c
@@ -346,7 +346,8 @@ lower_stmt (gimple_stmt_iterator *gsi, struct lower_data
*data)
return;
}
else if (DECL_FUNCTION_CODE (decl) == BUILT_IN_POSIX_MEMALIGN
- flag_tree_bit_ccp)
+ flag_tree_bit_ccp
+ gimple_builtin_call_types_compatible_p (stmt, decl))
{
lower_builtin_posix_memalign (gsi);
return;
diff --git gcc/testsuite/gcc.dg/torture/pr67222.c
gcc/testsuite/gcc.dg/torture/pr67222.c
index e69de29..739f869 100644
--- gcc/testsuite/gcc.dg/torture/pr67222.c
+++ gcc/testsuite/gcc.dg/torture/pr67222.c
@@ -0,0 +1,19 @@
+/* PR middle-end/67222 */
+/* { dg-do compile } */
+
+void
+foo (void **p)
+{
+ posix_memalign (); /* { dg-warning implicit declaration } */
+ posix_memalign (p);
+ posix_memalign (0);
+ posix_memalign (p, 1);
+ posix_memalign (p, foo);
+ posix_memalign (gnu, gcc);
+ posix_memalign (1, p);
+ posix_memalign (1, 2);
+ posix_memalign (1, 2, 3);
+ posix_memalign (p, p, p);
+ posix_memalign (p, qui, 3);
+ posix_memalign (p, 1, 2);
+}
diff --git gcc/tree-ssa-alias.c gcc/tree-ssa-alias.c
index e103220..0445052 100644
--- gcc/tree-ssa-alias.c
+++ gcc/tree-ssa-alias.c
@@ -1535,7 +1535,7 @@ ref_maybe_used_by_call_p_1 (gcall *call, ao_ref *ref)
escape points. See tree-ssa-structalias.c:find_func_aliases
for the list of builtins we might need to handle here. */
if (callee != NULL_TREE
- DECL_BUILT_IN_CLASS (callee) == BUILT_IN_NORMAL)
+ gimple_call_builtin_p (call, BUILT_IN_NORMAL))
switch (DECL_FUNCTION_CODE (callee))
{
/* All the following functions read memory pointed to by
@@ -1941,7 +1941,7 @@ call_may_clobber_ref_p_1 (gcall *call, ao_ref *ref)
escape points. See tree-ssa-structalias.c:find_func_aliases
for the list of builtins we might need to handle here. */
if (callee != NULL_TREE
- DECL_BUILT_IN_CLASS (callee) == BUILT_IN_NORMAL)
+ gimple_call_builtin_p (call, BUILT_IN_NORMAL))
switch (DECL_FUNCTION_CODE (callee))
{
/* All the following functions clobber memory pointed to by
@@ -2341,7 +2341,7 @@ stmt_kills_ref_p (gimple stmt, ao_ref *ref)
{
tree callee = gimple_call_fndecl (stmt);
if (callee != NULL_TREE
- DECL_BUILT_IN_CLASS (callee) == BUILT_IN_NORMAL)
+ gimple_call_builtin_p (stmt, BUILT_IN_NORMAL))
switch (DECL_FUNCTION_CODE (callee))
{
case BUILT_IN_FREE:
Marek
[Bug target/67254] On-stack memory regions with aligned attribute overlap on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67254 Segher Boessenkool segher at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||segher at gcc dot gnu.org Resolution|--- |INVALID --- Comment #2 from Segher Boessenkool segher at gcc dot gnu.org --- There is no overlap, data just happens to live at a higher address than reference. Closing as invalid.
[Bug c/67243] Wrong Message of -Wvla for Standard ISO C90 However Emitted with -std=c11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67243 --- Comment #9 from Marek Polacek mpolacek at gcc dot gnu.org --- *** Bug 67231 has been marked as a duplicate of this bug. ***
[Bug c/67234] New: Wrong Message of -Wvla for Standard ISO C90 However Emitted with -std=c11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67234 Bug ID: 67234 Summary: Wrong Message of -Wvla for Standard ISO C90 However Emitted with -std=c11 Product: gcc Version: 6.0 Status: RESOLVED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: chengniansun at gmail dot com CC: mpolacek at gcc dot gnu.org Target Milestone: --- Status: RESOLVED CC: mpolacek at gcc dot gnu.org Resolution: DUPLICATE When I compile the code int array[4.3];, in addition to the error, GCC also emits a -Wvla warning saying that ISO C90 forbids this. However, I specify -std=c11 in the command line, and IMHO this is at least an inconsistency between errors and error messages. $: cat t.c int array[4.3]; $: gcc-trunk -c -Wvla -std=c11 -pedantic t.c t.c:1:5: error: size of array ‘array’ has non-integer type int array[4.3]; ^ t.c:1:1: warning: variably modified ‘array’ at file scope int array[4.3]; ^ t.c:1:1: warning: ISO C90 forbids array ‘array’ whose size can’t be evaluated [-Wvla] $: gcc-trunk -v Using built-in specs. COLLECT_GCC=gcc-trunk COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-trunk/configure --enable-languages=c,c++,objc,obj-c++,fortran,lto --disable-werror --with-gmp=/usr/local/gcc-trunk --with-mpfr=/usr/local/gcc-trunk --with-mpc=/usr/local/gcc-trunk --with-cloog=/usr/local/gcc-trunk --prefix=/usr/local/gcc-trunk Thread model: posix gcc version 6.0.0 20150815 (experimental) [trunk revision 226911] (GCC) $: --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- . *** This bug has been marked as a duplicate of bug 67243 ***
[Bug c/67243] Wrong Message of -Wvla for Standard ISO C90 However Emitted with -std=c11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67243 --- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org --- *** Bug 67236 has been marked as a duplicate of this bug. ***
[Bug c/67243] Wrong Message of -Wvla for Standard ISO C90 However Emitted with -std=c11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67243 --- Comment #5 from Marek Polacek mpolacek at gcc dot gnu.org --- *** Bug 67235 has been marked as a duplicate of this bug. ***
[Bug c/67243] Wrong Message of -Wvla for Standard ISO C90 However Emitted with -std=c11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67243 --- Comment #6 from Marek Polacek mpolacek at gcc dot gnu.org --- *** Bug 67234 has been marked as a duplicate of this bug. ***
[Bug c/67230] New: Wrong Message of -Wvla on ISO C90 Emitted with -std=c11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67230 Bug ID: 67230 Summary: Wrong Message of -Wvla on ISO C90 Emitted with -std=c11 Product: gcc Version: 6.0 Status: RESOLVED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: chengniansun at gmail dot com CC: mpolacek at gcc dot gnu.org Target Milestone: --- Status: RESOLVED CC: mpolacek at gcc dot gnu.org Resolution: DUPLICATE When I compile the code int array[4.3];, in addition to the error, GCC also emits a -Wvla warning saying that ISO C90 forbids this. However, I specify -std=c11 in the command line, and IMHO this is at least an inconsistency between errors and error messages. $: cat t.c int array[4.3]; $: gcc-trunk -c -Wvla -std=c11 -pedantic t.c t.c:1:5: error: size of array ‘array’ has non-integer type int array[4.3]; ^ t.c:1:1: warning: variably modified ‘array’ at file scope int array[4.3]; ^ t.c:1:1: warning: ISO C90 forbids array ‘array’ whose size can’t be evaluated [-Wvla] $: gcc-trunk -v Using built-in specs. COLLECT_GCC=gcc-trunk COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-trunk/configure --enable-languages=c,c++,objc,obj-c++,fortran,lto --disable-werror --with-gmp=/usr/local/gcc-trunk --with-mpfr=/usr/local/gcc-trunk --with-mpc=/usr/local/gcc-trunk --with-cloog=/usr/local/gcc-trunk --prefix=/usr/local/gcc-trunk Thread model: posix gcc version 6.0.0 20150815 (experimental) [trunk revision 226911] (GCC) $: --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- . *** This bug has been marked as a duplicate of bug 67243 ***
[Bug c/67243] Wrong Message of -Wvla for Standard ISO C90 However Emitted with -std=c11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67243 --- Comment #8 from Marek Polacek mpolacek at gcc dot gnu.org --- *** Bug 67232 has been marked as a duplicate of this bug. ***
[Bug c/67231] New: Wrong Message of -Wvla on ISO C90 Emitted with -std=c11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67231 Bug ID: 67231 Summary: Wrong Message of -Wvla on ISO C90 Emitted with -std=c11 Product: gcc Version: 6.0 Status: RESOLVED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: chengniansun at gmail dot com CC: mpolacek at gcc dot gnu.org Target Milestone: --- Status: RESOLVED CC: mpolacek at gcc dot gnu.org Resolution: DUPLICATE When I compile the code int array[4.3];, in addition to the error, GCC also emits a -Wvla warning saying that ISO C90 forbids this. However, I specify -std=c11 in the command line, and IMHO this is at least an inconsistency between errors and error messages. $: cat t.c int array[4.3]; $: gcc-trunk -c -Wvla -std=c11 -pedantic t.c t.c:1:5: error: size of array ‘array’ has non-integer type int array[4.3]; ^ t.c:1:1: warning: variably modified ‘array’ at file scope int array[4.3]; ^ t.c:1:1: warning: ISO C90 forbids array ‘array’ whose size can’t be evaluated [-Wvla] $: gcc-trunk -v Using built-in specs. COLLECT_GCC=gcc-trunk COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-trunk/configure --enable-languages=c,c++,objc,obj-c++,fortran,lto --disable-werror --with-gmp=/usr/local/gcc-trunk --with-mpfr=/usr/local/gcc-trunk --with-mpc=/usr/local/gcc-trunk --with-cloog=/usr/local/gcc-trunk --prefix=/usr/local/gcc-trunk Thread model: posix gcc version 6.0.0 20150815 (experimental) [trunk revision 226911] (GCC) $: --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- . *** This bug has been marked as a duplicate of bug 67243 ***
[Bug c/67243] Wrong Message of -Wvla for Standard ISO C90 However Emitted with -std=c11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67243 --- Comment #7 from Marek Polacek mpolacek at gcc dot gnu.org --- *** Bug 67233 has been marked as a duplicate of this bug. ***
[Bug c/67233] New: Wrong Message of -Wvla on ISO C90 Emitted with -std=c11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67233 Bug ID: 67233 Summary: Wrong Message of -Wvla on ISO C90 Emitted with -std=c11 Product: gcc Version: 6.0 Status: RESOLVED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: chengniansun at gmail dot com CC: mpolacek at gcc dot gnu.org Target Milestone: --- Status: RESOLVED CC: mpolacek at gcc dot gnu.org Resolution: DUPLICATE When I compile the code int array[4.3];, in addition to the error, GCC also emits a -Wvla warning saying that ISO C90 forbids this. However, I specify -std=c11 in the command line, and IMHO this is at least an inconsistency between errors and error messages. $: cat t.c int array[4.3]; $: gcc-trunk -c -Wvla -std=c11 -pedantic t.c t.c:1:5: error: size of array ‘array’ has non-integer type int array[4.3]; ^ t.c:1:1: warning: variably modified ‘array’ at file scope int array[4.3]; ^ t.c:1:1: warning: ISO C90 forbids array ‘array’ whose size can’t be evaluated [-Wvla] $: gcc-trunk -v Using built-in specs. COLLECT_GCC=gcc-trunk COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-trunk/configure --enable-languages=c,c++,objc,obj-c++,fortran,lto --disable-werror --with-gmp=/usr/local/gcc-trunk --with-mpfr=/usr/local/gcc-trunk --with-mpc=/usr/local/gcc-trunk --with-cloog=/usr/local/gcc-trunk --prefix=/usr/local/gcc-trunk Thread model: posix gcc version 6.0.0 20150815 (experimental) [trunk revision 226911] (GCC) $: --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- . *** This bug has been marked as a duplicate of bug 67243 ***
[Bug c/67243] Wrong Message of -Wvla for Standard ISO C90 However Emitted with -std=c11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67243 --- Comment #10 from Marek Polacek mpolacek at gcc dot gnu.org --- *** Bug 67230 has been marked as a duplicate of this bug. ***
[Bug c/67232] New: Wrong Message of -Wvla on ISO C90 Emitted with -std=c11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67232 Bug ID: 67232 Summary: Wrong Message of -Wvla on ISO C90 Emitted with -std=c11 Product: gcc Version: 6.0 Status: RESOLVED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: chengniansun at gmail dot com CC: mpolacek at gcc dot gnu.org Target Milestone: --- Status: RESOLVED CC: mpolacek at gcc dot gnu.org Resolution: DUPLICATE When I compile the code int array[4.3];, in addition to the error, GCC also emits a -Wvla warning saying that ISO C90 forbids this. However, I specify -std=c11 in the command line, and IMHO this is at least an inconsistency between errors and error messages. $: cat t.c int array[4.3]; $: gcc-trunk -c -Wvla -std=c11 -pedantic t.c t.c:1:5: error: size of array ‘array’ has non-integer type int array[4.3]; ^ t.c:1:1: warning: variably modified ‘array’ at file scope int array[4.3]; ^ t.c:1:1: warning: ISO C90 forbids array ‘array’ whose size can’t be evaluated [-Wvla] $: gcc-trunk -v Using built-in specs. COLLECT_GCC=gcc-trunk COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-trunk/configure --enable-languages=c,c++,objc,obj-c++,fortran,lto --disable-werror --with-gmp=/usr/local/gcc-trunk --with-mpfr=/usr/local/gcc-trunk --with-mpc=/usr/local/gcc-trunk --with-cloog=/usr/local/gcc-trunk --prefix=/usr/local/gcc-trunk Thread model: posix gcc version 6.0.0 20150815 (experimental) [trunk revision 226911] (GCC) $: --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- . *** This bug has been marked as a duplicate of bug 67243 ***
Re: [PATCH] Add extensions to dwarf2.def
On 08/18/2015 11:24 AM, Pierre-Marie de Rodat wrote: I successfuly created the two wiki pages, thanks to both of you! As a side note, for some reason I could no longer login and I had to re-create my account (same identifier, which worked). I'm not sure, but I think it's the second time I had to do that (the first time I thought I did something wrong...). The blurb at the top of glibc's page explains this: https://sourceware.org/glibc/wiki/EditorGroup As part of this wiki's spam prevention process we keep a community maintained list of allowed editors. Members of this group are allowed to edit the wiki. This is a community maintained list. As a member of EditorGroup you can add other users to this list but by doing so you vouch for them. This process has reduced spam to zero since only those interested humans are willing to ask to be added by other humans who vouch for them. Despite this feature, and our desire to keep the registration process open, the spammers still fill the database with new login entries that slow down MoinMoin. To combat spam login accounts we routinely purge the account database down to the list of users that are on this page. If you find your account was purged, please create it again, and make sure to get yourself added to this list. Looks like neither GCC's nor GDB's borrowed that longer text yet. Thanks, Pedro Alves
[PATCH] S390: Fix vec_load_bndry.
The attached patch fixes the vec_load_bndry builtin on S390. The second argument must be one of 64, 128, 256, ..., 4096, but the table expected that value to fit into 3 bits. Ciao Dominik ^_^ ^_^ -- Dominik Vogt IBM Germany From 51d68bc3b6fd293504ff859763bbc4f3aff8cb69 Mon Sep 17 00:00:00 2001 From: Dominik Vogt v...@linux.vnet.ibm.com Date: Tue, 18 Aug 2015 13:11:08 +0100 Subject: [PATCH] S390: Fix vec_load_bndry. In one place it required 64, 128, ..., 4096 as the second argument and in another place it required that value to fit into three bits. --- gcc/config/s390/s390-builtins.def | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/gcc/config/s390/s390-builtins.def b/gcc/config/s390/s390-builtins.def index 9b11e41..3250eef 100644 --- a/gcc/config/s390/s390-builtins.def +++ b/gcc/config/s390/s390-builtins.def @@ -447,15 +447,15 @@ B_DEF (s390_vllezf,vec_insert_and_zerov4si,0, B_DEF (s390_vllezg,vec_insert_and_zerov2di,0, B_VX, 0, BT_FN_UV2DI_ULONGLONGCONSTPTR) OB_DEF (s390_vec_load_bndry,s390_vec_load_bndry_s8,s390_vec_load_bndry_dbl,B_VX,BT_FN_OV4SI_INTCONSTPTR_INT) -OB_DEF_VAR (s390_vec_load_bndry_s8, s390_vlbb, O2_U3, BT_OV_V16QI_SCHARCONSTPTR_USHORT) -OB_DEF_VAR (s390_vec_load_bndry_u8, s390_vlbb, O2_U3, BT_OV_UV16QI_UCHARCONSTPTR_USHORT) -OB_DEF_VAR (s390_vec_load_bndry_s16,s390_vlbb, O2_U3, BT_OV_V8HI_SHORTCONSTPTR_USHORT) -OB_DEF_VAR (s390_vec_load_bndry_u16,s390_vlbb, O2_U3, BT_OV_UV8HI_USHORTCONSTPTR_USHORT) -OB_DEF_VAR (s390_vec_load_bndry_s32,s390_vlbb, O2_U3, BT_OV_V4SI_INTCONSTPTR_USHORT) -OB_DEF_VAR (s390_vec_load_bndry_u32,s390_vlbb, O2_U3, BT_OV_UV4SI_UINTCONSTPTR_USHORT) -OB_DEF_VAR (s390_vec_load_bndry_s64,s390_vlbb, O2_U3, BT_OV_V2DI_LONGLONGCONSTPTR_USHORT) -OB_DEF_VAR (s390_vec_load_bndry_u64,s390_vlbb, O2_U3, BT_OV_UV2DI_ULONGLONGCONSTPTR_USHORT) -OB_DEF_VAR (s390_vec_load_bndry_dbl,s390_vlbb, O2_U3, BT_OV_V2DF_DBLCONSTPTR_USHORT) +OB_DEF_VAR (s390_vec_load_bndry_s8, s390_vlbb, O2_U16, BT_OV_V16QI_SCHARCONSTPTR_USHORT) +OB_DEF_VAR (s390_vec_load_bndry_u8, s390_vlbb, O2_U16, BT_OV_UV16QI_UCHARCONSTPTR_USHORT) +OB_DEF_VAR (s390_vec_load_bndry_s16,s390_vlbb, O2_U16, BT_OV_V8HI_SHORTCONSTPTR_USHORT) +OB_DEF_VAR (s390_vec_load_bndry_u16,s390_vlbb, O2_U16, BT_OV_UV8HI_USHORTCONSTPTR_USHORT) +OB_DEF_VAR (s390_vec_load_bndry_s32,s390_vlbb, O2_U16, BT_OV_V4SI_INTCONSTPTR_USHORT) +OB_DEF_VAR (s390_vec_load_bndry_u32,s390_vlbb, O2_U16, BT_OV_UV4SI_UINTCONSTPTR_USHORT) +OB_DEF_VAR (s390_vec_load_bndry_s64,s390_vlbb, O2_U16, BT_OV_V2DI_LONGLONGCONSTPTR_USHORT) +OB_DEF_VAR (s390_vec_load_bndry_u64,s390_vlbb, O2_U16, BT_OV_UV2DI_ULONGLONGCONSTPTR_USHORT) +OB_DEF_VAR (s390_vec_load_bndry_dbl,s390_vlbb, O2_U16, BT_OV_V2DF_DBLCONSTPTR_USHORT) B_DEF (s390_vlbb, vlbb, 0, B_VX, O2_U3, BT_FN_UV16QI_UCHARCONSTPTR_USHORT) -- 2.3.0 gcc/ChangeLog * config/s390/s390-builtins.def: S390: Fix value range of vec_load_bndry.
[Bug rtl-optimization/67028] combine bug. Different assumptions about subreg in different places.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67028 --- Comment #7 from Segher Boessenkool segher at gcc dot gnu.org --- Author: segher Date: Tue Aug 18 12:21:41 2015 New Revision: 226967 URL: https://gcc.gnu.org/viewcvs?rev=226967root=gccview=rev Log: PR rtl-optimization/67028 * combine.c (simplify_comparison): Fix comment. Rearrange code. Add test to see if a const_int fits in the new mode. gcc/testsuite/ PR rtl-optimization/67028 * gcc.dg/pr67028.c: New testcase. Added: branches/gcc-5-branch/gcc/testsuite/gcc.dg/pr67028.c Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/combine.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug c/67255] -Wpadded mixes apostrophes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67255 --- Comment #5 from Marek Polacek mpolacek at gcc dot gnu.org --- Yeah, I see nothing wrong in GCC source files.
[v3 patch] Fix header included by bits/ptr_traits.h
While trying some header rearrangment I noticed that this file should
include bits/move.h for addressof.
Tested powerpc64le-linux, committing to trunk.
commit 223119133ca91452b3e9979a2f1eeb4554210d12
Author: Jonathan Wakely jwak...@redhat.com
Date: Tue Aug 18 13:03:40 2015 +0100
* include/bits/ptr_traits.h: Include bits/move.h for addressof.
diff --git a/libstdc++-v3/include/bits/ptr_traits.h b/libstdc++-v3/include/bits/ptr_traits.h
index 84cc4da..d1bc449 100644
--- a/libstdc++-v3/include/bits/ptr_traits.h
+++ b/libstdc++-v3/include/bits/ptr_traits.h
@@ -32,7 +32,7 @@
#if __cplusplus = 201103L
-#include type_traits
+#include bits/move.h
namespace std _GLIBCXX_VISIBILITY(default)
{
Re: [PATCH] S390: Fix vec_load_bndry.
Dominik Vogt wrote: The attached patch fixes the vec_load_bndry builtin on S390. The second argument must be one of 64, 128, 256, ..., 4096, but the table expected that value to fit into 3 bits. Makes sense. However, I'd really like to see a testcase that verifies we're accepting the correct values and generate correct assembler ... gcc/ChangeLog * config/s390/s390-builtins.def: S390: Fix value range of vec_load_bndry. The S390: seems out of place here. Thanks, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain ulrich.weig...@de.ibm.com
Re: [patch] Alter libstdc++ test to work after c++/67216 fix
Hi, On 08/18/2015 02:41 PM, Jonathan Wakely wrote: With Paolo's fix the use of the safe-bool idiom in this test no longer compiles in C++11 or C++14. The requirement in TR1 is that it works in a boolean context and p1 == false is not necessarily a boolean context. Do an explicit conversion to make it valid in all modes. Thanks Jon and sorry about the breakage! Paolo.
[Bug c/67255] -Wpadded mixes apostrophes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67255 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org --- GCC uses consistent quotes, but depends on environment variables such as LANG. Presumably one of the commands you are running sets LANG=C or similar, which causes GCC to output ASCII apostrophes. If you want consistent results then set LANG=C yourself before running any of the commands.
[patch] Alter libstdc++ test to work after c++/67216 fix
With Paolo's fix the use of the safe-bool idiom in this test no longer compiles in C++11 or C++14. The requirement in TR1 is that it works in a boolean context and p1 == false is not necessarily a boolean context. Do an explicit conversion to make it valid in all modes. Tested powerpc64le-linux, committing to trunk. commit 78c8f95718d21c97653a61ba93ca3c311ca21bc7 Author: Jonathan Wakely jwak...@redhat.com Date: Tue Aug 18 13:17:50 2015 +0100 PR c++/67216 * testsuite/tr1/2_general_utilities/shared_ptr/observers/bool_conv.cc: Fix use of safe-bool idiom that isn't valid in C++11. diff --git a/libstdc++-v3/testsuite/tr1/2_general_utilities/shared_ptr/observers/bool_conv.cc b/libstdc++-v3/testsuite/tr1/2_general_utilities/shared_ptr/observers/bool_conv.cc index 0c93f36..e7cefaf 100644 --- a/libstdc++-v3/testsuite/tr1/2_general_utilities/shared_ptr/observers/bool_conv.cc +++ b/libstdc++-v3/testsuite/tr1/2_general_utilities/shared_ptr/observers/bool_conv.cc @@ -31,9 +31,9 @@ test01() bool test __attribute__((unused)) = true; const std::tr1::shared_ptrA p1; - VERIFY( p1 == false ); + VERIFY( bool(p1) == false ); const std::tr1::shared_ptrA p2(p1); - VERIFY( p2 == false ); + VERIFY( bool(p2) == false ); return 0; }
[Bug c++/67257] [5/6 regression] Internal compiler error in retrieve_specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67257
Markus Trippelsdorf trippels at gcc dot gnu.org changed:
What|Removed |Added
Keywords||ice-on-invalid-code
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-08-18
CC||trippels at gcc dot gnu.org
Summary|Internal compiler error in |[5/6 regression] Internal
|retrieve_specialization |compiler error in
||retrieve_specialization
Ever confirmed|0 |1
--- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
It is an ICE on invalid:
% cat Matrix.ii
template typename struct plus;
template typename struct A {
template typename T auto operator()(T);
} foldl;
void foo() { foldlplusint(0); }
% /var/tmp/gcc_test/usr/local/bin/g++ -c Matrix.ii
Matrix.ii: In substitution of ‘templateclass templateclass T auto
A::operator()(T) [with T = missing; template-parameter-1-1 = int]’:
Matrix.ii:5:32: required from here
Matrix.ii:5:32: internal compiler error: in retrieve_specialization, at
cp/pt.c:1194
void foo() { foldlplusint(0); }
^
0x5e0c73 retrieve_specialization
../../gcc/gcc/cp/pt.c:1191
0x5e568e instantiate_template_1
../../gcc/gcc/cp/pt.c:16561
0x5e568e instantiate_template(tree_node*, tree_node*, int)
../../gcc/gcc/cp/pt.c:16675
0x5fa689 fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, bool, bool)
../../gcc/gcc/cp/pt.c:17024
0x5b3cf9 add_template_candidate_real
../../gcc/gcc/cp/call.c:3065
0x5b437c add_template_candidate
../../gcc/gcc/cp/call.c:3162
0x5b437c add_candidates
../../gcc/gcc/cp/call.c:5318
0x5b8527 build_op_call_1
../../gcc/gcc/cp/call.c:4305
0x5b8527 build_op_call(tree_node*, vectree_node*, va_gc, vl_embed**, int)
../../gcc/gcc/cp/call.c:4392
0x688568 finish_call_expr(tree_node*, vectree_node*, va_gc, vl_embed**, bool,
bool, int)
../../gcc/gcc/cp/semantics.c:2408
0x63cde8 cp_parser_postfix_expression
../../gcc/gcc/cp/parser.c:6422
0x640d29 cp_parser_unary_expression
../../gcc/gcc/cp/parser.c:7486
0x6418a7 cp_parser_binary_expression
../../gcc/gcc/cp/parser.c:8223
0x641e7d cp_parser_assignment_expression
../../gcc/gcc/cp/parser.c:8481
0x6488f1 cp_parser_expression
../../gcc/gcc/cp/parser.c:8635
0x64a0f6 cp_parser_expression_statement
../../gcc/gcc/cp/parser.c:10049
0x639365 cp_parser_statement
../../gcc/gcc/cp/parser.c:9900
0x639e42 cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:10172
0x639f73 cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:10126
0x652c5d cp_parser_function_body
../../gcc/gcc/cp/parser.c:19783
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
markus@x4 tmp % /usr/x86_64-pc-linux-gnu/gcc-bin/4.9.3/g++ -std=c++14 -c
Matrix.ii
Matrix.ii:4:3: error: template declaration of ‘A template-parameter-1-1
foldl’
} foldl;
^
Matrix.ii: In function ‘void foo()’:
Matrix.ii:5:14: error: ‘foldl’ was not declared in this scope
void foo() { foldlplusint(0); }
^
Matrix.ii:5:28: error: expected primary-expression before ‘’ token
void foo() { foldlplusint(0); }
^
[Bug rtl-optimization/67218] Combine incorrectly folds (double) (float) (unsigned)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67218 rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org --- Patch applied to trunk. It turned out to be a gcc 6 regression, so no backports are needed.
[Bug c/67224] UTF-8 support for identifier names in GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67224 --- Comment #15 from Eric ejolson at unr dot edu --- Created attachment 36206 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36206action=edit Improved UTF-8 identifier patch Improved patch to support UTF-8 identifiers. This version by default does no translation unless -finput-charset=XXX is specified where XXX is something other than C99 and should not affect EBCDIC hosts.
[v3 patch] Backport Filesystem TS to GCC 5 branch
I've been meaning to backport the FIlesystem TS library to the GCC 5 branch for some time, so here it is. As with trunk it's only enabled for targets where it's known to build and pass the tests. Tested powerpc64le-linux, committed to gcc-5-branch. Backport Filesystem TS from mainline * acinclude.m4 (GLIBCXX_ENABLE_FILESYSTEM_TS, GLIBCXX_CHECK_FILESYSTEM_DEPS): Define. * configure.ac: Use them. * configure: Regenerate. * config.h.in: Regenerate. * include/Makefile.am: Add filesystem headers. Fix order of headers. * include/Makefile.in: Regenerate. * include/bits/locale_conv.h (__do_str_codecvt, __str_codecvt_in, __str_codecvt_out, wstring_convert): Refactor to move all conversion logic to non-member functions. * include/bits/quoted_string.h (_Quoted_string, operator, operator): Move from iomanip to new header. * include/experimental/filesystem: New. * include/experimental/fs_dir.h: New. * include/experimental/fs_fwd.h: New. * include/experimental/fs_ops.h: New. * include/experimental/fs_path.h: New. * include/std/iomanip (_Quoted_string, operator, operator): Move to bits/quoted_string.h. * libstdcxx/v6/printers.py (StdExpPathPrinter): Define. * scripts/testsuite_flags.in: Add filesystem dir to ldflags. * src/Makefile.am: Add filesystem sub-dir. * src/Makefile.in: Regenerate. * src/filesystem/Makefile.am: New. * src/filesystem/Makefile.in: New. * src/filesystem/dir.cc: New. * src/filesystem/ops.cc: New. * src/filesystem/path.cc: New. * testsuite/experimental/filesystem/operations/absolute.cc: New. * testsuite/experimental/filesystem/operations/copy.cc: New. * testsuite/experimental/filesystem/operations/current_path.cc: New. * testsuite/experimental/filesystem/operations/exists.cc: New. * testsuite/experimental/filesystem/operations/file_size.cc: New. * testsuite/experimental/filesystem/operations/status.cc: New. * testsuite/experimental/filesystem/operations/temp_directory_path.cc: New. * testsuite/experimental/filesystem/path/append/path.cc: New. * testsuite/experimental/filesystem/path/assign/assign.cc: New. * testsuite/experimental/filesystem/path/assign/copy.cc: New. * testsuite/experimental/filesystem/path/compare/compare.cc: New. * testsuite/experimental/filesystem/path/compare/path.cc: New. * testsuite/experimental/filesystem/path/compare/strings.cc: New. * testsuite/experimental/filesystem/path/concat/path.cc: New. * testsuite/experimental/filesystem/path/concat/strings.cc: New. * testsuite/experimental/filesystem/path/construct/copy.cc: New. * testsuite/experimental/filesystem/path/construct/default.cc: New. * testsuite/experimental/filesystem/path/construct/locale.cc: New. * testsuite/experimental/filesystem/path/construct/range.cc: New. * testsuite/experimental/filesystem/path/decompose/extension.cc: New. * testsuite/experimental/filesystem/path/decompose/filename.cc: New. * testsuite/experimental/filesystem/path/decompose/parent_path.cc: New. * testsuite/experimental/filesystem/path/decompose/relative_path.cc: New. * testsuite/experimental/filesystem/path/decompose/root_directory.cc: New. * testsuite/experimental/filesystem/path/decompose/root_name.cc: New. * testsuite/experimental/filesystem/path/decompose/root_path.cc: New. * testsuite/experimental/filesystem/path/decompose/stem.cc: New. * testsuite/experimental/filesystem/path/generic/generic_string.cc: New. * testsuite/experimental/filesystem/path/itr/traversal.cc: New. * testsuite/experimental/filesystem/path/modifiers/clear.cc: New. * testsuite/experimental/filesystem/path/modifiers/make_preferred.cc: New. * testsuite/experimental/filesystem/path/modifiers/remove_filename.cc: New. * testsuite/experimental/filesystem/path/modifiers/ replace_extension.cc: New. * testsuite/experimental/filesystem/path/modifiers/replace_filename.cc: New. * testsuite/experimental/filesystem/path/modifiers/swap.cc: New. * testsuite/experimental/filesystem/path/nonmember/hash_value.cc: New. * testsuite/experimental/filesystem/path/query/empty.cc: New. * testsuite/experimental/filesystem/path/query/has_extension.cc: New. * testsuite/experimental/filesystem/path/query/has_filename.cc: New. * testsuite/experimental/filesystem/path/query/has_parent_path.cc: New. * testsuite/experimental/filesystem/path/query/has_relative_path.cc: New. * testsuite/experimental/filesystem/path/query/has_root_directory.cc:
Deprecate SH5/SH64
Hi all, Kaz and I have been discussing the SH5/SH64 status, which is part of the SH port, every now and then. To our knowledge, there is no real hardware available as of today and we don't think there are any real users for a SH5/SH64 toolchain out there. Moreover, the SH5/SH64 parts of the SH port haven't been touched by anybody for a long time. The only exception is occasional ad-hoc fixes for bug reports from people who build GCC for every architecture that is listed in the Linux kernel. However, we don't actually know whether code compiled for SH5/SH64 still runs at an acceptable level since nobody has been doing any testing for that architecture for a while now. If there are no objections, we would like to deprecate SH5/SH64 support as of GCC 6. Initially this would include an announcement on the changes page and the removal of any documentation related to SH5/SH64. After GCC 6 we might start removing configure options and the respective code paths in the target. Cheers, Oleg
Re: [RFC] COMDAT Safe Module Level Multi versioning
On Wed, Aug 12, 2015 at 10:36 PM, Sriraman Tallam tmsri...@google.com wrote:
On Tue, Aug 4, 2015 at 11:43 AM, Sriraman Tallam tmsri...@google.com wrote:
On Tue, Jun 16, 2015 at 4:22 PM, Sriraman Tallam tmsri...@google.com wrote:
On Tue, May 19, 2015 at 9:11 AM, Xinliang David Li davi...@google.com
wrote:
Hm. But which options are unsafe? Also wouldn't it be better to simply
_not_ have unsafe options produce comdats but always make local clones
for them (thus emit the comdat with unsafe flags dropped)?
Always localize comdat functions may lead to text size increase. It
does not work if the comdat function is a virtual function for
instance.
Based on Richard's suggestion, I have a patch to localize comdat
functions which seems like a very effective solution to this problem.
The text size increase is limited to the extra comdat copies generated
for the specialized modules (modules with unsafe options) which is
usually only a few. Since -fweak does something similar for
functions, I have called the new option -fweak-comdat-functions.
This does not apply to virtual comdat functions as their addresses can
always be leaked via the vtable. Using this flag with virtual
functions generates a warning.
To summarize, this is the intended usage of this option. Modules which
use unsafe code options, like -misa for multiversioning, to generate
code that is meant to run only on a subset of CPUs can generate
comdats with specialized instructions which when picked by the linker
can get run unconditionally causing SIGILL on unsupported platforms.
This flag hides these comdats to be local to these modules and not
make them available publicly, with the caveat that it does not apply
to virtual comdats.
Could you please review?
Ping. This patch uses Richard's suggestion to localize comdat
functions with option -fno-weak-comdat-functions. Comments?
Ping.
* c-family/c.opt (fweak-comdat-functions): New option.
* cp/decl2.c (comdat_linkage): Implement new option. Warn when
virtual comdat functions are seen.
* doc/invoke.texi: Document new option.
* testsuite/g++.dg/no-weak-comdat-functions-1.C: New test.
Ping.
* c-family/c.opt (fweak-comdat-functions): New option.
* cp/decl2.c (comdat_linkage): Implement new option. Warn when
virtual comdat functions are seen.
* doc/invoke.texi: Document new option.
* testsuite/g++.dg/no-weak-comdat-functions-1.C: New test.
* c-family/c.opt (fweak-comdat-functions): New option.
* cp/decl2.c (comdat_linkage): Implement new option. Warn when
virtual comdat functions are seen.
* doc/invoke.texi: Document new option.
* testsuite/g++.dg/no-weak-comdat-functions-1.C: New test.
* c-family/c.opt (fweak-comdat-functions): New option.
* cp/decl2.c (comdat_linkage): Implement new option. Warn when
virtual comdat functions are seen.
* doc/invoke.texi: Document new option.
* testsuite/g++.dg/no-weak-comdat-functions-1.C: New test.
Thanks
Sri
David
Richard.
Thanks
Sri
* c-family/c.opt (fweak-comdat-functions): New option.
* cp/decl2.c (comdat_linkage): Implement new option. Warn when
virtual comdat functions are seen.
* doc/invoke.texi: Document new option.
* testsuite/g++.dg/no-weak-comdat-functions-1.C: New test.
Index: c-family/c.opt
===
--- c-family/c.opt (revision 224486)
+++ c-family/c.opt (working copy)
@@ -1236,6 +1236,14 @@ fweak
C++ ObjC++ Var(flag_weak) Init(1)
Emit common-like symbols as weak symbols
+fweak-comdat-functions
+C++ Var(flag_weak_comdat_functions) Init(1)
+Specific to comdat functions(-fno-weak-comdat-functions : Localize Comdat
Functions).
+With -fno-weak-comdat-functions, virtual comdat functions are still linked as
+weak functions. With -fno-weak-comdat-functions, the address of the comdat
+functions that are localized will be unique and this can cause unintended
+behavior when addresses of comdat functions are used.
+
fwide-exec-charset=
C ObjC C++ ObjC++ Joined RejectNegative
-fwide-exec-charset=cset Convert all wide strings and character
constants to character set cset
Index: cp/decl2.c
===
--- cp/decl2.c (revision 224486)
+++ cp/decl2.c (working copy)
@@ -1702,8 +1702,19 @@ mark_vtable_entries (tree decl)
void
comdat_linkage (tree decl)
{
- if (flag_weak)
-make_decl_one_only (decl, cxx_comdat_group (decl));
+ if (flag_weak
+ (flag_weak_comdat_functions
+ || TREE_CODE (decl) != FUNCTION_DECL
+ || DECL_VIRTUAL_P (decl)))
+{
+ make_decl_one_only (decl, cxx_comdat_group (decl));
+ if (TREE_CODE (decl) == FUNCTION_DECL
+ DECL_VIRTUAL_P (decl)
+ !flag_weak_comdat_functions)
+ warning_at (DECL_SOURCE_LOCATION (decl), 0,
+ fno-weak-comdat-functions: Comdat linkage of virtual
+ function %q#D preserved.);
