RE: new mul* patterns U constraint in rl78
Hi DJ, Uses a U constraint. What should that constraint do? Could you post a patch to add it? The U constraint was part of a source tree we worked on previously. I have provided the patch for it below. I have also set the valloc attribute for the multiplication insns to 'umul'. Would that be the correct setting as 'macax' is used for the other SI multiplication insns which seem to also include accumulation? Please let me know if OK. Thanks Regards, Kaushik 2013-06-10 Kaushik Phatak kaushik.pha...@kpitcummins.com * config/rl78/constraints.md (U): New constraint. * config/rl78/rl78.md (mulqi3_rl78,mulhi3_rl78,mulhi3_g13): Add valloc attribute. Index: gcc/config/rl78/constraints.md === --- gcc/config/rl78/constraints.md (revision 199879) +++ gcc/config/rl78/constraints.md (working copy) @@ -256,6 +256,19 @@ (match_test !rl78_far_p (op) rl78_as_legitimate_address (VOIDmode, XEXP (op, 0), true, ADDR_SPACE_GENERIC))) ) +(define_memory_constraint U + memory references valid with mov to/from a/ax + (and (match_code mem) + (match_test rl78_virt_insns_ok () +|| satisfies_constraint_Wab (op) +|| satisfies_constraint_Wbc (op) +|| satisfies_constraint_Wde (op) +|| satisfies_constraint_Wd2 (op) +|| satisfies_constraint_Whl (op) +|| satisfies_constraint_Wh1 (op) +|| satisfies_constraint_Whb (op) +|| satisfies_constraint_Ws1 (op) +|| satisfies_constraint_Wfr (op) ))) (define_memory_constraint Qbi built-in compare types Index: gcc/config/rl78/rl78.md === --- gcc/config/rl78/rl78.md (revision 199879) +++ gcc/config/rl78/rl78.md (working copy) @@ -276,6 +276,7 @@ mova, x mov%h0, a ; end of mulqi macro + [(set_attr valloc umul)] ) (define_insn *mulhi3_rl78 @@ -290,6 +291,7 @@ mulhu ; bcax = bc * ax movw%h0, ax ; end of mulhi macro + [(set_attr valloc umul)] ) (define_insn *mulhi3_g13 @@ -309,6 +311,7 @@ movwax, 0x6 ; MDBL movw%h0, ax ; end of mulhi macro + [(set_attr valloc umul)] ) ;; 0x0 is MACR(L). 0x2 is MACR(H) but we don't care about it
Re: RFA: Switching LRA on for s390
On 08/06/13 20:41, Vladimir Makarov wrote: On 13-06-07 11:12 AM, Vladimir Makarov wrote: On 13-06-07 10:57 AM, Andreas Krebbel wrote: I've applied the attached patch. This helps me getting a little further when bootstrapping with lra and --with-arch=zEC12. 2013-06-07 Andreas Krebbel andreas.kreb...@de.ibm.com * config/s390/s390.md (cpu_facility): Add cpu_zarch. (*movmem_short, *clrmem_short, *cmpmem_short): Use cpu_zarch for last alternative in the cpu_facility attribute. --- gcc/config/s390/s390.md | 13 ! 1 file changed, 4 insertions(+), 9 modifications(!) Thanks, Andreas. I am not a specialist in 390 architecture. You are the expert. I'll check the bootstrap with this option too on a machine available for me. I've checked the bootstrap without any -with-arch option before submitting the patch for approval. If I find some problems, I'll work on them too. I'll work on PR57599 you just reported too. I've fixed PR57599. Unfortunately, I can not bootstrap with --with-arch=zEC12 as a machine available for me does not support this subtarget. Thanks. I would be happy to test the patch for you. Bye, -Andreas-
Re: [GOOGLE] More strict checking for call args
Hi, On Thu, Jun 06, 2013 at 08:10:13AM -0700, Dehao Chen wrote: Hi, Martin, Yes, your patch can fix my case. Thanks a lot for the fix. good. However, as usual when I'm trying to do things too quickly, I made a stupid mistaker and testing has revealed I picked exactly the wrong branch in the second hunk. So this is the correct patch, now after proper bootstrapping and testing on x86_64-linux. Since the intent is clearly the same as the approved patch, I intend to commit it later today/early tomorrow, unless there are any objections. Thanks and sorry again, Martin 2013-06-07 Martin Jambor mjam...@suse.cz * ipa-cp.c (ipa_get_indirect_edge_target_1): Check that param_index is within bounds at the beginning of the function. Index: src/gcc/ipa-cp.c === --- src.orig/gcc/ipa-cp.c +++ src/gcc/ipa-cp.c @@ -1481,7 +1481,8 @@ ipa_get_indirect_edge_target_1 (struct c tree otr_type; tree t; - if (param_index == -1) + if (param_index == -1 + || known_vals.length () = (unsigned int) param_index) return NULL_TREE; if (!ie-indirect_info-polymorphic) @@ -1516,8 +1517,7 @@ ipa_get_indirect_edge_target_1 (struct c t = NULL; } else - t = (known_vals.length () (unsigned int) param_index -? known_vals[param_index] : NULL); + t = known_vals[param_index]; if (t TREE_CODE (t) == ADDR_EXPR
Re: [RFC] Implement Undefined Behavior Sanitizer (take 2)
On Sat, Jun 08, 2013 at 07:48:27PM +0200, Marc Glisse wrote:
+ tt = fold_build2 (EQ_EXPR, boolean_type_node, op1,
+integer_minus_one_node);
Don't we usually try to have both operands of a comparison of the
same type?
Will fix.
+ t = fold_build2 (EQ_EXPR, boolean_type_node, op0,
+ TYPE_MIN_VALUE (TREE_TYPE (op0)));
I didn't see where this test was restricted to the signed case
(0u/-1 is well defined)?
Will fix.
+ t = fold_build2 (TRUTH_AND_EXPR, boolean_type_node, t, tt);
+ tt = build2 (EQ_EXPR, boolean_type_node,
+ op1, integer_zero_node);
Why not fold this one?
Sure, will do.
Name unsigned_type_for (TREE_TYPE (op1)) and TYPE_PRECISION
(TREE_TYPE (op0)) that are used several times?
Yeah.
@@ -4070,8 +4077,15 @@ cp_build_binary_op (location_t location,
{
enum tree_code tcode0 = code0, tcode1 = code1;
tree cop1 = fold_non_dependent_expr_sfinae (op1, tf_none);
+ cop1 = maybe_constant_value (cop1);
- warn_for_div_by_zero (location, maybe_constant_value (cop1));
+ if (!processing_template_decl tcode0 == INTEGER_TYPE
+ (TREE_CODE (cop1) != INTEGER_CST
+ || integer_zerop (cop1)
+ || integer_minus_onep (cop1)))
+doing_div_or_mod = true;
Aren't you already doing this test in ubsan_instrument_division?
Yep, I'll throw it out of cp/typeck.c.
Thanks for the review!
Marek
Re: [RFC] Implement Undefined Behavior Sanitizer (take 2)
On Mon, Jun 10, 2013 at 11:24:16AM +0200, Marek Polacek wrote:
@@ -4070,8 +4077,15 @@ cp_build_binary_op (location_t location,
{
enum tree_code tcode0 = code0, tcode1 = code1;
tree cop1 = fold_non_dependent_expr_sfinae (op1, tf_none);
+cop1 = maybe_constant_value (cop1);
-warn_for_div_by_zero (location, maybe_constant_value (cop1));
+if (!processing_template_decl tcode0 == INTEGER_TYPE
+ (TREE_CODE (cop1) != INTEGER_CST
+|| integer_zerop (cop1)
+|| integer_minus_onep (cop1)))
+ doing_div_or_mod = true;
Aren't you already doing this test in ubsan_instrument_division?
Yep, I'll throw it out of cp/typeck.c.
Note that the above one actually performs more than what you do in
ubsan_instrument_division, because it works on maybe_constant_value result.
So, perhaps typeck.c should ensure that the ubsan functions are always
called with arguments passed through
maybe_constant_value (fold_non_dependent_expr_sfinae (opX, tf_none)).
Jakub
Re: [RFC] Implement Undefined Behavior Sanitizer (take 2)
On Mon, Jun 10, 2013 at 11:32:22AM +0200, Jakub Jelinek wrote:
On Mon, Jun 10, 2013 at 11:24:16AM +0200, Marek Polacek wrote:
@@ -4070,8 +4077,15 @@ cp_build_binary_op (location_t location,
{
enum tree_code tcode0 = code0, tcode1 = code1;
tree cop1 = fold_non_dependent_expr_sfinae (op1, tf_none);
+ cop1 = maybe_constant_value (cop1);
- warn_for_div_by_zero (location, maybe_constant_value (cop1));
+ if (!processing_template_decl tcode0 == INTEGER_TYPE
+ (TREE_CODE (cop1) != INTEGER_CST
+ || integer_zerop (cop1)
+ || integer_minus_onep (cop1)))
+doing_div_or_mod = true;
Aren't you already doing this test in ubsan_instrument_division?
Yep, I'll throw it out of cp/typeck.c.
Note that the above one actually performs more than what you do in
ubsan_instrument_division, because it works on maybe_constant_value result.
So, perhaps typeck.c should ensure that the ubsan functions are always
called with arguments passed through
maybe_constant_value (fold_non_dependent_expr_sfinae (opX, tf_none)).
Ah, ok, will add it there. Thanks.
Marek
[Patch wwwdocs] gcc-4.9 changes: mention support of the Intel Silvermont microarchitecture
Hi! This patch mentions support of Silvermont architecture in the gcc-4.9/changes.html page. OK to install? Thanks, Igor Index: htdocs/gcc-4.9/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.9/changes.html,v retrieving revision 1.17 diff -c -1 -r1.17 changes.html *** htdocs/gcc-4.9/changes.html 6 Jun 2013 11:15:24 - 1.17 --- htdocs/gcc-4.9/changes.html 10 Jun 2013 10:11:24 - *** *** 177,178 --- 177,185 + h3IA-32/x86-64/h3 + ul + li GCC now supports new Intel microarchitecture named Silvermont + through code-march=slm/code. + /li + /ul + h3 id=rxRX/h3
Re: [PATCH] DATA_ALIGNMENT vs. DATA_ABI_ALIGNMENT (PR target/56564)
On 06/07/2013 10:43 PM, Richard Henderson wrote: But these I think require a good hard look to see if they really intended an ABI alignment: c6x comment explicitly mentions abi The ABI specifies a minimum alignment for arrays. Bernd
[PATCH][ARM][6/n] Partial IT block deprecation in ARMv8 AArch32 - VFP patterns
Hi all, This patch makes the changes to the various floating point patterns in vfp.md. Since pretty much all floating point instruction are always encoded in 32 bits, they cannot be used inside an IT block by the -mrestrict-it rules. Therefore this patch just goes and disables the predicable variants of the offending VFP patterns. The conditional floating point move patterns are disabled altogether for arm_restrict_it because they explicitly use IT blocks in their output template and the corresponding expanders in arm.md are updated to make sure we use the new vsel instruction that is available in ARMv8 when appropriate. Tested arm-none-eabi on qemu and model as part of the whole series and also independently bootstrapped with -mrestrict-it enabled on a Cortex-A15. Ok for trunk? Thanks, Kyrill 2013-06-10 Kyrylo Tkachov kyrylo.tkac...@arm.com * config/arm/predicates.md (arm_cond_move_operator): New predicate. * config/arm/arm.md (movsfcc): Use arm_cond_move_operator predicate. (movdfcc): Likewise. * config/arm/vfp.md (*thumb2_movsf_vfp): Disable predication for arm_restrict_it. (*thumb2_movsfcc_vfp): Disable for arm_restrict_it. (*thumb2_movdfcc_vfp): Likewise. (*abssf2_vfp, *absdf2_vfp, *negsf2_vfp, *negdf2_vfp, *addsf3_vfp, *adddf3_vfp, *subsf3_vfp, *subdf3_vfpc, *divsf3_vfp, *divdf3_vfp, *mulsf3_vfp, *muldf3_vfp, *mulsf3negsf_vfp, *muldf3negdf_vfp, *mulsf3addsf_vfp, *muldf3adddf_vfp, *mulsf3subsf_vfp, *muldf3subdf_vfp, *mulsf3negsfaddsf_vfp, *fmuldf3negdfadddf_vfp, *mulsf3negsfsubsf_vfp, *muldf3negdfsubdf_vfp, *fmaSDF:mode4, *fmsubSDF:mode4, *fnmsubSDF:mode4, *fnmaddSDF:mode4, *extendsfdf2_vfp, *truncdfsf2_vfp, *extendhfsf2, *truncsfhf2, *truncsisf2_vfp, *truncsidf2_vfp, fixuns_truncsfsi2, fixuns_truncdfsi2, *floatsisf2_vfp, *floatsidf2_vfp, floatunssisf2, floatunssidf2, *sqrtsf2_vfp, *sqrtdf2_vfp, *cmpsf_vfp, *cmpsf_trap_vfp, *cmpdf_vfp, *cmpdf_trap_vfp, vrint_patternSDF:mode2): Disable predication for arm_restrict_it. it-depr-vfp.patch Description: Binary data
Re: [PATCH] DATA_ALIGNMENT vs. DATA_ABI_ALIGNMENT (PR target/56564)
On Mon, Jun 10, 2013 at 12:51:05PM +0200, Bernd Schmidt wrote: On 06/07/2013 10:43 PM, Richard Henderson wrote: But these I think require a good hard look to see if they really intended an ABI alignment: c6x comment explicitly mentions abi The ABI specifies a minimum alignment for arrays. Thus after the patch c6x.h (DATA_ALIGNMENT) should be renamed to DATA_ABI_ALIGNMENT, right? Jakub
Re: [PATCH] DATA_ALIGNMENT vs. DATA_ABI_ALIGNMENT (PR target/56564)
On 06/10/2013 12:55 PM, Jakub Jelinek wrote: On Mon, Jun 10, 2013 at 12:51:05PM +0200, Bernd Schmidt wrote: On 06/07/2013 10:43 PM, Richard Henderson wrote: But these I think require a good hard look to see if they really intended an ABI alignment: c6x comment explicitly mentions abi The ABI specifies a minimum alignment for arrays. Thus after the patch c6x.h (DATA_ALIGNMENT) should be renamed to DATA_ABI_ALIGNMENT, right? I think so. Bernd
Re: [Patch wwwdocs] gcc-4.9 changes: mention support of the Intel Silvermont microarchitecture
Igor Zamyatin wrote:
+ li GCC now supports new Intel microarchitecture named Silvermont
+ through code-march=slm/code.
Not related to the release notes, but I think it should also be added to
gcc/doc/invoke.texi's @item -march=@var{cpu-type} - presumably after
the item:
@item atom
Intel Atom CPU with 64-bit extensions, MMX, SSE, SSE2, SSE3 and SSSE3
instruction set support.
Tobias
Re: [PATCH] DATA_ALIGNMENT vs. DATA_ABI_ALIGNMENT (PR target/56564)
Richard Henderson wrote: s390 comment mentions LARL instruction On s390(x) it is indeed an ABI requirement that all global symbols are at least 2-aligned. (Note that we skip that alignment requirement if a symbol is marked as attribute((aligned(1)), but that attribute must then be present for every use, too.) Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE ulrich.weig...@de.ibm.com
[PATCH] Do not redirect ld stdout/stderr in collect2 with -debug
This fixes one very annoying thing collect2 does when trying to
debug LTO WPA issues. Even with -v you need to wait until all
LTRANS stages completed to see the lto1 -fwpa invocation which
is because collect2 buffers and replays stdout/stderr of ld
(to avoid duplicating that in some cases). But I really want
to see the output immediately but there is no way to do that.
The easiest is to disable the buffering with -debug (that is,
-Wl,-debug to the -flto driver command line).
Tested with/without -debug.
Ok for trunk?
Thanks,
Richard.
2013-06-10 Richard Biener rguent...@suse.de
* collect2.c (main): Do not redirect ld stdout/stderr when
debugging.
Index: gcc/collect2.c
===
--- gcc/collect2.c (revision 199732)
+++ gcc/collect2.c (working copy)
@@ -1189,8 +1189,11 @@ main (int argc, char **argv)
#ifdef COLLECT_EXPORT_LIST
export_file = make_temp_file (.x);
#endif
- ldout = make_temp_file (.ld);
- lderrout = make_temp_file (.le);
+ if (!debug)
+{
+ ldout = make_temp_file (.ld);
+ lderrout = make_temp_file (.le);
+}
*c_ptr++ = c_file_name;
*c_ptr++ = -x;
*c_ptr++ = c;
Document Intel Silvermont support in invoke.texi
Hi! Following patch documents Intel Silvermont support. OK to install? Thanks, Igor Changelog: 2013-06-10 Igor Zamyatin igor.zamya...@intel.com * doc/invoke.texi: Document slm. diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi index b7b32f7..e4f1d45 100644 --- a/gcc/doc/invoke.texi +++ b/gcc/doc/invoke.texi @@ -13837,6 +13837,10 @@ set support. Intel Atom CPU with 64-bit extensions, MMX, SSE, SSE2, SSE3 and SSSE3 instruction set support. +@item slm +Intel Silvermont CPU with 64-bit extensions, MMX, SSE, SSE2, SSE3 and SSSE3, +SSE4.1, SSE4.2 instruction set support. + @item k6 AMD K6 CPU with MMX instruction set support.
Re: Document Intel Silvermont support in invoke.texi
On Mon, Jun 10, 2013 at 3:25 PM, Igor Zamyatin izamya...@gmail.com wrote: Following patch documents Intel Silvermont support. OK to install? Thanks, Igor Changelog: 2013-06-10 Igor Zamyatin igor.zamya...@intel.com * doc/invoke.texi: Document slm. diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi index b7b32f7..e4f1d45 100644 --- a/gcc/doc/invoke.texi +++ b/gcc/doc/invoke.texi @@ -13837,6 +13837,10 @@ set support. Intel Atom CPU with 64-bit extensions, MMX, SSE, SSE2, SSE3 and SSSE3 instruction set support. +@item slm +Intel Silvermont CPU with 64-bit extensions, MMX, SSE, SSE2, SSE3 and SSSE3, +SSE4.1, SSE4.2 instruction set support. SSE4.1 and SSE4.2 instruction set support. OK with this change. Thanks, Uros.
Re: Document Intel Silvermont support in invoke.texi
On Mon, Jun 10, 2013 at 05:25:36PM +0400, Igor Zamyatin wrote: Following patch documents Intel Silvermont support. OK to install? 2013-06-10 Igor Zamyatin igor.zamya...@intel.com * doc/invoke.texi: Document slm. diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi index b7b32f7..e4f1d45 100644 --- a/gcc/doc/invoke.texi +++ b/gcc/doc/invoke.texi @@ -13837,6 +13837,10 @@ set support. Intel Atom CPU with 64-bit extensions, MMX, SSE, SSE2, SSE3 and SSSE3 instruction set support. +@item slm +Intel Silvermont CPU with 64-bit extensions, MMX, SSE, SSE2, SSE3 and SSSE3, +SSE4.1, SSE4.2 instruction set support. Shouldn't it also list MOVBE (similarly for atom and core-avx2, btver2 already lists it). core-avx2 isn't even documented at all in invoke.texi. Jakub
Re: [RFA PATCH, alpha]: Fix PR 57379, segfault in invalidate_any_buried_refs
On Thu, May 23, 2013 at 7:20 PM, Richard Henderson r...@redhat.com wrote: On 05/23/2013 12:38 AM, Uros Bizjak wrote: 2013-05-23 Uros Bizjak ubiz...@gmail.com * config/alpha/alpha.md (unspec): Add UNSPEC_XFLT_COMPARE. * config/alpha/alpha.c (alpha_emit_xfloating_compare): Construct REG_EQUAL note as UNSPEC_XFLT_COMPARE unspec. Patch was bootstrapped and regression tested on alphaev68-linux-gnu. OK for mainline and release branches? [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57379 Ok. Actually, backport uncovered the problem with different compares, which now shared the same REG_EQUAL note. Attached patch fixes this oversight. 2013-06-10 Uros Bizjak ubiz...@gmail.com * config/alpha/alpha.c (alpha_emit_xfloating_compare): Also use cmp_code to construct REG_EQUAL note. Tested on alphaev68-pc-linux-gnu and committed to mainline SVN. Uros. Index: alpha.c === --- alpha.c(revision 199788) +++ alpha.c(working copy) @@ -3068,7 +3068,8 @@ alpha_emit_xfloating_compare (enum rtx_code *pcode out = gen_reg_rtx (DImode); /* What's actually returned is -1,0,1, not a proper boolean value. */ - note = gen_rtx_UNSPEC (DImode, gen_rtvec (2, op0, op1), UNSPEC_XFLT_COMPARE); + note = gen_rtx_fmt_ee (cmp_code, VOIDmode, op0, op1); + note = gen_rtx_UNSPEC (DImode, gen_rtvec (1, note), UNSPEC_XFLT_COMPARE); alpha_emit_xfloating_libcall (func, out, operands, 2, note); return out;
Re: [RFC] Implement Undefined Behavior Sanitizer (take 2)
On Sat, 8 Jun 2013, Marek Polacek wrote: + if (code == LSHIFT_EXPR + !TYPE_UNSIGNED (TREE_TYPE (op0)) + (flag_isoc99 || flag_isoc11)) flag_isoc11 implies flag_isoc99, you only need to check flag_isoc99 here. -- Joseph S. Myers jos...@codesourcery.com
Re: [PATCH] Fix for PR c/57563
On Sun, 9 Jun 2013, Iyer, Balaji V wrote: Attached, please find a patch that will fix the bug reported in PR 57563. There are a couple issues that went wrong. First, in the test case, we have a double multiplied to a double. When -std=c99 flag is used, they get converted to long double. The way to fix this is to add a type cast to the array notation to the same type as identity variable and thus they will all be double. You don't say what the actual error was, and neither does the original PR. But if it was an ICE from an EXCESS_PRECISION_EXPR getting to the gimplifier, that suggests that c_fully_fold isn't getting called somewhere it should be - and probably calling c_fully_fold is the correct fix rather than inserting a cast. If you can get such ICEs for EXCESS_PRECISION_EXPR, it's quite possible you might get them for C_MAYBE_CONST_EXPR as well (e.g. try using 0 / 0, or compound literals of variably modified type, in various places in the affected expressions), which should be fixed by using c_fully_fold but not by inserting a cast. -- Joseph S. Myers jos...@codesourcery.com
Re: [PATCH] Do not redirect ld stdout/stderr in collect2 with -debug
On Mon, 10 Jun 2013, Richard Biener wrote: This fixes one very annoying thing collect2 does when trying to debug LTO WPA issues. Even with -v you need to wait until all LTRANS stages completed to see the lto1 -fwpa invocation which is because collect2 buffers and replays stdout/stderr of ld (to avoid duplicating that in some cases). But I really want to see the output immediately but there is no way to do that. The easiest is to disable the buffering with -debug (that is, -Wl,-debug to the -flto driver command line). Tested with/without -debug. Ok for trunk? OK. -- Joseph S. Myers jos...@codesourcery.com
Re: [c++-concepts] code review
On 2013-06-09 20:34 , Gabriel Dos Reis wrote: So, my advice is for GCC source code to forget about the cxxx headers for the most part. I can see an instance where cmath or cstring would make a difference but given point (1) above, no it doesn't. Just use the traditional xxx.h headers and be done with it. Maybe I should have included this in our C++ coding standards, but I don't know how Benjamin, Lawrence, and Diego fee about it. Sounds reasonable to me. Diego.
Re: [PATCH] DATA_ALIGNMENT vs. DATA_ABI_ALIGNMENT (PR target/56564)
On 06/07/2013 02:14 PM, Jakub Jelinek wrote:
When the linker merges common blocks, it chooses both maximum size and
maximum
alignment. Thus for any common block for which we can prove the block must
reside in the module (any executable, or hidden common in shared object),
we
can go ahead and use the increased alignment.
But consider say:
one TU:
struct S { char buf[15]; } s __attribute__((aligned (32)));
another TU:
char c = 7;
struct S { char buf[15]; } s = { { 1, 2 } };
char d = 8;
int main () { return 0; }
(the aligned(32) is there just to simulate the DATA_ALIGNMENT optimization
increase). Linker warns about this (thus the question is if we want to
increase the alignment for optimization on commons at all) and doesn't align
it.
Oh, right. I hadn't considered commons unifying with non-common variables,
and the failure of commoning in that case. I'd mostly been thinking of
uninitialized Fortran-like common blocks, where it is more common for the
blocks to have nothing in common but the name.
r~
RE: [PATCH] Fix for PR c/57563
-Original Message- From: Joseph Myers [mailto:jos...@codesourcery.com] Sent: Monday, June 10, 2013 10:40 AM To: Iyer, Balaji V Cc: gcc-patches@gcc.gnu.org; Jakub Jelinek; mpola...@gcc.gnu.org Subject: Re: [PATCH] Fix for PR c/57563 On Sun, 9 Jun 2013, Iyer, Balaji V wrote: Attached, please find a patch that will fix the bug reported in PR 57563. There are a couple issues that went wrong. First, in the test case, we have a double multiplied to a double. When -std=c99 flag is used, they get converted to long double. The way to fix this is to add a type cast to the array notation to the same type as identity variable and thus they will all be double. You don't say what the actual error was, and neither does the original PR. But if it was an ICE from an EXCESS_PRECISION_EXPR getting to the gimplifier, that suggests that c_fully_fold isn't getting called somewhere it should be - and probably calling c_fully_fold is the correct fix rather than inserting a cast. If you can get such ICEs for EXCESS_PRECISION_EXPR, it's quite possible you might get them for C_MAYBE_CONST_EXPR as well (e.g. try using 0 / 0, or compound literals of variably modified type, in various places in the affected expressions), which should be fixed by using c_fully_fold but not by inserting a cast. It was not. It was actually a type mismatch between double and long double caught in verify_gimple_in_seq function. So, is it OK for trunk? Thanks, Balaji V. Iyer. -- Joseph S. Myers jos...@codesourcery.com
RE: [PATCH] Fix for PR c/57563
On Mon, 10 Jun 2013, Iyer, Balaji V wrote: You don't say what the actual error was, and neither does the original PR. But if it was an ICE from an EXCESS_PRECISION_EXPR getting to the gimplifier, that suggests that c_fully_fold isn't getting called somewhere it should be - and probably calling c_fully_fold is the correct fix rather than inserting a cast. If you can get such ICEs for EXCESS_PRECISION_EXPR, it's quite possible you might get them for C_MAYBE_CONST_EXPR as well (e.g. try using 0 / 0, or compound literals of variably modified type, in various places in the affected expressions), which should be fixed by using c_fully_fold but not by inserting a cast. It was not. It was actually a type mismatch between double and long double caught in verify_gimple_in_seq function. So, is it OK for trunk? A cast still doesn't make sense conceptually. Could you give a more detailed analysis of what the trees look like at this point where you are inserting this cast, and how you get to a mismatch? EXCESS_PRECISION_EXPR can be thought of as a conversion operator. It should only appear at the top level of an expression. At the point where excess precision should be removed - the value converted to its semantic type - either the expression with excess precision should be folded using c_fully_fold (if this is the expression of an expression statement, or otherwise will go inside a tree that c_fully_fold does not recurse inside), or the operand of the EXCESS_PRECISION_EXPR should be converted to the semantic type with the convert function. In neither case is generating a cast appropriate; that's for when the user actually wrote a cast in their source code. -- Joseph S. Myers jos...@codesourcery.com
Re: [PATCH] ARMv6-M MI thunk fix
On 07/06/13 17:50, Cesar Philippidis wrote:
On 6/6/13 9:00 AM, Richard Earnshaw wrote:
The pipeline offset is 4 for Thumb2 as well. So at the very least you
need to explain why your change doesn't apply then as well.
Yes some context is lost in that comment. Thunks are usually emitted in
ARM mode, except for Thumb-only targets. Is the new comment OK? If so,
please check it in since I do not have SVN write access.
So what about ARMv7-M, which is thumb2 but no ARM state?
R.
Thanks,
Cesar
2013-06-07 Julian Brown jul...@codesourcery.com
Cesar Philippidis ce...@codesourcery.com
gcc/
* config/arm/arm.c (arm_output_mi_thunk): Fix offset for
TARGET_THUMB1_ONLY.
ARM-fix-mi-thunks-TARGET_THUMB1_ONLY-rev2.patch
Index: gcc/config/arm/arm.c
===
--- gcc/config/arm/arm.c(revision 199695)
+++ gcc/config/arm/arm.c(working copy)
@@ -25217,7 +25217,12 @@
{
/* Output .word .LTHUNKn-7-.LTHUNKPCn. */
rtx tem = XEXP (DECL_RTL (function), 0);
- tem = gen_rtx_PLUS (GET_MODE (tem), tem, GEN_INT (-7));
+ /* When supported, thunks are generated in ARM mode. But for
+TARGET_THUMB1_ONLY the thunk is in Thumb mode, so the PC
+pipeline offset is four rather than eight. Adjust the
+offset accordingly. */
+ tem = gen_rtx_PLUS (GET_MODE (tem), tem,
+ GEN_INT (TARGET_THUMB1_ONLY ? -3 : -7));
tem = gen_rtx_MINUS (GET_MODE (tem),
tem,
gen_rtx_SYMBOL_REF (Pmode,
Re: [PATCH, rs6000] power8 patches, patch #6, direct move basic quad load/store
Mike, This patch is okay, but something seems really broken with respect to TImode. I don't know if we have to separate TImode from V1TImode or some distinction for atomics from other uses of TImode. This isn't like float modes where they mostly live in FPRs and only occassionally need to live in GPRs. TImode between VSX and GPRs really is bimodal. Something is wrong with this preferencing design. Maybe we need a separate set of logical TImode instructions for the atomic ops with a neutral set of preferences on the constraints for movti. Then the registers chosen for the computation will correctly drive the register allocation decisions. Thanks, David
Re: [PATCH] DATA_ALIGNMENT vs. DATA_ABI_ALIGNMENT (PR target/56564)
On Mon, Jun 10, 2013 at 07:51:54AM -0700, Richard Henderson wrote:
On 06/07/2013 02:14 PM, Jakub Jelinek wrote:
When the linker merges common blocks, it chooses both maximum size and
maximum
alignment. Thus for any common block for which we can prove the block
must
reside in the module (any executable, or hidden common in shared
object), we
can go ahead and use the increased alignment.
But consider say:
one TU:
struct S { char buf[15]; } s __attribute__((aligned (32)));
another TU:
char c = 7;
struct S { char buf[15]; } s = { { 1, 2 } };
char d = 8;
int main () { return 0; }
(the aligned(32) is there just to simulate the DATA_ALIGNMENT optimization
increase). Linker warns about this (thus the question is if we want to
increase the alignment for optimization on commons at all) and doesn't align
it.
Oh, right. I hadn't considered commons unifying with non-common variables,
and the failure of commoning in that case. I'd mostly been thinking of
uninitialized Fortran-like common blocks, where it is more common for the
blocks to have nothing in common but the name.
Ok, here is what I've committed to trunk (will wait for some time before
backporting). As discussed with Honza on IRC, decl_binds_to_current_def_p
will need further fixing, it does the wrong thing for extern int var
__attribute__((visibility (hidden))) or hidden DECL_COMMON symbols.
And, we don't have any feedback about SPE/E500 rs6000 - DATA_ALIGNMENT vs.
DATA_ABI_ALIGNMENT yet.
2013-06-10 Jakub Jelinek ja...@redhat.com
PR target/56564
* varasm.c (align_variable): Don't use DATA_ALIGNMENT or
CONSTANT_ALIGNMENT if !decl_binds_to_current_def_p (decl).
Use DATA_ABI_ALIGNMENT for that case instead if defined.
(get_variable_align): New function.
(get_variable_section, emit_bss, emit_common,
assemble_variable_contents, place_block_symbol): Use
get_variable_align instead of DECL_ALIGN.
(assemble_noswitch_variable): Add align argument, use it
instead of DECL_ALIGN.
(assemble_variable): Adjust caller. Use get_variable_align
instead of DECL_ALIGN.
* config/i386/i386.h (DATA_ALIGNMENT): Adjust x86_data_alignment
caller.
(DATA_ABI_ALIGNMENT): Define.
* config/i386/i386-protos.h (x86_data_alignment): Adjust prototype.
* config/i386/i386.c (x86_data_alignment): Add opt argument. If
opt is false, only return the psABI mandated alignment increase.
* config/c6x/c6x.h (DATA_ALIGNMENT): Renamed to...
(DATA_ABI_ALIGNMENT): ... this.
* config/mmix/mmix.h (DATA_ALIGNMENT): Renamed to...
(DATA_ABI_ALIGNMENT): ... this.
* config/mmix/mmix.c (mmix_data_alignment): Adjust function comment.
* config/s390/s390.h (DATA_ALIGNMENT): Renamed to...
(DATA_ABI_ALIGNMENT): ... this.
* doc/tm.texi.in (DATA_ABI_ALIGNMENT): Document.
* doc/tm.texi: Regenerated.
* gcc.target/i386/pr56564-1.c: New test.
* gcc.target/i386/pr56564-2.c: New test.
* gcc.target/i386/pr56564-3.c: New test.
* gcc.target/i386/pr56564-4.c: New test.
* gcc.target/i386/avx256-unaligned-load-4.c: Add -fno-common.
* gcc.target/i386/avx256-unaligned-store-1.c: Likewise.
* gcc.target/i386/avx256-unaligned-store-3.c: Likewise.
* gcc.target/i386/avx256-unaligned-store-4.c: Likewise.
* gcc.target/i386/vect-sizes-1.c: Likewise.
* gcc.target/i386/memcpy-1.c: Likewise.
* gcc.dg/vect/costmodel/i386/costmodel-vect-31.c (tmp): Initialize.
* gcc.dg/vect/costmodel/x86_64/costmodel-vect-31.c (tmp): Likewise.
--- gcc/config/c6x/c6x.h.jj 2013-02-26 16:39:34.0 +0100
+++ gcc/config/c6x/c6x.h2013-06-10 17:36:44.850082918 +0200
@@ -134,7 +134,7 @@ extern c6x_cpu_t c6x_arch;
Really only externally visible arrays must be aligned this way, as
only those are directly visible from another compilation unit. But
we don't have that information available here. */
-#define DATA_ALIGNMENT(TYPE, ALIGN)\
+#define DATA_ABI_ALIGNMENT(TYPE, ALIGN)
\
(((ALIGN) BITS_PER_UNIT * 8 TREE_CODE (TYPE) == ARRAY_TYPE) \
? BITS_PER_UNIT * 8 : (ALIGN))
--- gcc/config/mmix/mmix.h.jj 2013-01-11 09:03:16.0 +0100
+++ gcc/config/mmix/mmix.h 2013-06-10 17:36:05.585730695 +0200
@@ -164,7 +164,7 @@ struct GTY(()) machine_function
/* Copied from elfos.h. */
#define MAX_OFILE_ALIGNMENT (32768 * 8)
-#define DATA_ALIGNMENT(TYPE, BASIC_ALIGN) \
+#define DATA_ABI_ALIGNMENT(TYPE, BASIC_ALIGN) \
mmix_data_alignment (TYPE, BASIC_ALIGN)
#define CONSTANT_ALIGNMENT(CONSTANT, BASIC_ALIGN) \
--- gcc/config/mmix/mmix.c.jj 2013-03-26 10:03:58.0 +0100
+++ gcc/config/mmix/mmix.c 2013-06-10 17:36:28.012360493 +0200
@@ -313,7 +313,7 @@
Re: [PATCH] ARMv6-M MI thunk fix
On 6/10/13 8:32 AM, Richard Earnshaw wrote: On 07/06/13 17:50, Cesar Philippidis wrote: On 6/6/13 9:00 AM, Richard Earnshaw wrote: The pipeline offset is 4 for Thumb2 as well. So at the very least you need to explain why your change doesn't apply then as well. Yes some context is lost in that comment. Thunks are usually emitted in ARM mode, except for Thumb-only targets. Is the new comment OK? If so, please check it in since I do not have SVN write access. So what about ARMv7-M, which is thumb2 but no ARM state? Thumb2 is handled differently. This patch is inside an if (TARGET_THUMB1) block. Cesar
RE: [patch, mips] Fix for PR target/56942
Steven,
The assert has been in ToT for over a week now and I haven't seen any problems
reported.
Is it time to move on to the next step?
Steve Ellcey
sell...@mips.com
From: Steven Bosscher [stevenb@gmail.com]
Sent: Wednesday, May 29, 2013 3:15 PM
To: Steve Ellcey; gcc-patches@gcc.gnu.org; Andrew Bennett;
rdsandif...@googlemail.com
Subject: Re: [patch, mips] Fix for PR target/56942
OK for trunk?
If it causes any trouble, please file a PR and assign it to me.
And when the dust has settled, I can clean up the FIXME for
JUMP_TABLE_DATA in next_active_insn, and fix up the back ends.
Ciao!
Steven
* rtlanal.c (tablejump_p): Expect table and label to be adjacent.
Index: rtlanal.c
===
--- rtlanal.c (revision 199324)
+++ rtlanal.c (working copy)
@@ -2711,6 +2711,7 @@ tablejump_p (const_rtx insn, rtx *labelp, rtx *tab
(table = next_active_insn (label)) != NULL_RTX
JUMP_TABLE_DATA_P (table))
{
+ gcc_assert (table == NEXT_INSN (label));
if (labelp)
*labelp = label;
if (tablep)
[C++ testcase, committed] PR 52440
Hi,
committed to mainline.
Thanks,
Paolo.
2013-06-10 Paolo Carlini paolo.carl...@oracle.com
PR c++/52440
* g++.dg/cpp0x/pr52440.C: New.
Index: g++.dg/cpp0x/pr52440.C
===
--- g++.dg/cpp0x/pr52440.C (revision 0)
+++ g++.dg/cpp0x/pr52440.C (working copy)
@@ -0,0 +1,27 @@
+// PR c++/52440
+// { dg-do compile { target c++11 } }
+
+templatebool
+struct V
+{
+ typedef void type;
+};
+
+templatetypename T
+struct X
+{
+ templatetypename
+ static constexpr bool always_true()
+ {
+return true;
+ }
+
+ templatetypename U,
+ typename = typename Valways_trueU()::type
+ X(U ) {}
+};
+
+int main()
+{
+ Xint x(42);
+}
Re: [c++-concepts] code review
On 06/09/2013 08:34 PM, Gabriel Dos Reis wrote: I strongly suggest prefering stdlib.h over cstdlib for GCC source code base. The problem is that including stdlib.h does not define _GLIBCXX_CSTDLIB, so if one of the C++ library headers includes cstdlib the contents are added then, but by that point e.g. malloc is poisoned, so the mentions of malloc in cstdlib cause errors. Because we are poisoning these names, we need to #include *both* headers in system.h. Jason
Re: [c++-concepts] code review
On 06/09/2013 08:49 PM, Gabriel Dos Reis wrote: If you put the function in an unnamed namespace you would expect GCC to treat is as if it was of internal linkage for many purposes including automatic inlining, but it doesn't:-( For example, you lose the defined but not used warning, and the used but not defined warnings :-(( Indeed, G++ currently only gives those warnings for things declared 'static', but that's trivial to fix, and shouldn't affect other things in the compiler. Jason
RE: [PATCH] Fix for PR c/57563
-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
ow...@gcc.gnu.org] On Behalf Of Joseph S. Myers
Sent: Monday, June 10, 2013 11:16 AM
To: Iyer, Balaji V
Cc: gcc-patches@gcc.gnu.org; Jakub Jelinek; mpola...@gcc.gnu.org
Subject: RE: [PATCH] Fix for PR c/57563
On Mon, 10 Jun 2013, Iyer, Balaji V wrote:
You don't say what the actual error was, and neither does the original PR.
But if it was an ICE from an EXCESS_PRECISION_EXPR getting to the
gimplifier, that suggests that c_fully_fold isn't getting called
somewhere it should be - and probably calling c_fully_fold is the
correct fix rather than inserting a cast. If you can get such ICEs
for EXCESS_PRECISION_EXPR, it's quite possible you might get them
for C_MAYBE_CONST_EXPR as well (e.g. try using 0 / 0, or compound
literals of variably modified type, in various places in the affected
expressions), which should be fixed by using c_fully_fold but not by
inserting a
cast.
It was not. It was actually a type mismatch between double and long
double caught in verify_gimple_in_seq function. So, is it OK for trunk?
A cast still doesn't make sense conceptually. Could you give a more detailed
analysis of what the trees look like at this point where you are inserting
this cast,
and how you get to a mismatch?
EXCESS_PRECISION_EXPR can be thought of as a conversion operator. It should
only appear at the top level of an expression. At the point where excess
precision should be removed - the value converted to its semantic type -
either
the expression with excess precision should be folded using c_fully_fold (if
this is
the expression of an expression statement, or otherwise will go inside a tree
that c_fully_fold does not recurse inside), or the operand of the
EXCESS_PRECISION_EXPR should be converted to the semantic type with the
convert function. In neither case is generating a cast appropriate; that's
for
when the user actually wrote a cast in their source code.
I looked into it a bit more detail. It was an error on my side. I was removing
the excess precision expr layer instead of fully folding it. I did that change
(i.e. fully fold the expression) and all the errors seem to go away. Here is
the fixed patch that fixes PR c/57563. It passes for 32 bit and 64 bit tests.
Here are the changelog entries:
gcc/c/ChangeLog
2013-06-10 Balaji V. Iyer balaji.v.i...@intel.com
* c-array-notation.c (fix_builtin_array_notation_fn): Fully folded
excessive precision expressions in function parameters.
gcc/testsuite/ChangeLog
2013-06-10 Balaji V. Iyer balaji.v.i...@intel.com
PR c/57563
* c-c++-common/cilk-plus/AN/builtin_fn_mutating.c (main): Fixed a bug
in how we check __sec_reduce_mutating function's result.
Thanks,
Balaji V. Iyer.
--
Joseph S. Myers
jos...@codesourcery.com
diff --git a/gcc/c/c-array-notation.c b/gcc/c/c-array-notation.c
index b1040da..9298ae0 100644
--- a/gcc/c/c-array-notation.c
+++ b/gcc/c/c-array-notation.c
@@ -158,10 +158,13 @@ fix_builtin_array_notation_fn (tree an_builtin_fn, tree
*new_var)
func_parm = CALL_EXPR_ARG (an_builtin_fn, 0);
while (TREE_CODE (func_parm) == CONVERT_EXPR
-|| TREE_CODE (func_parm) == EXCESS_PRECISION_EXPR
|| TREE_CODE (func_parm) == NOP_EXPR)
func_parm = TREE_OPERAND (func_parm, 0);
+ /* Fully fold any EXCESSIVE_PRECISION EXPR that can occur in the function
+ parameter. */
+ func_parm = c_fully_fold (func_parm, false, NULL);
+
location = EXPR_LOCATION (an_builtin_fn);
if (!find_rank (location, an_builtin_fn, an_builtin_fn, true, rank))
diff --git a/gcc/testsuite/c-c++-common/cilk-plus/AN/builtin_fn_mutating.c
b/gcc/testsuite/c-c++-common/cilk-plus/AN/builtin_fn_mutating.c
index 6635565..7c194c2 100644
--- a/gcc/testsuite/c-c++-common/cilk-plus/AN/builtin_fn_mutating.c
+++ b/gcc/testsuite/c-c++-common/cilk-plus/AN/builtin_fn_mutating.c
@@ -44,11 +44,11 @@ int main(void)
max_value = array3[0] * array4[0];
for (ii = 0; ii 10; ii++)
if (array3[ii] * array4[ii] max_value) {
- max_value = array3[ii] * array4[ii];
max_index = ii;
}
-
+ for (ii = 0; ii 10; ii++)
+my_func (max_value, array3[ii] * array4[ii]);
#if HAVE_IO
for (ii = 0; ii 10; ii++)
Re: [announce] New scalar-storage-order branch in GCC repository
On 05/27/2013 01:13 PM, Eric Botcazou wrote:
I have just created a new branch off the trunk named scalar-storage-order to
host the (experimental) support to specify a reverse storage order (byte/word
order, aka endianness) for scalar components of aggregate types.
I will be maintaining the branch and start by porting AdaCore's GCC 4.7-based
implementation for the Ada compiler to this branch. Once this is done, I'll
welcome suggestions and ideas to support this new feature in other languages.
I experimented with something like this a while ago. The goal was to
have a -f{big,little}-endian switch that changes the default byteorder,
and also to add endianness attributes. It didn't go very far, but I
could compile some simple testcases and it seemed to behave as expected
for those.
The patch is attached for reference. The interesting problems are
byteswapping pointers and how to deal with function arguments; neither
is dealt with in this patch (except for a crummy attempt to get varargs
right). At the moment I don't intend to do further work on this.
Bernd
Index: gcc/c-family/c-pretty-print.c
===
--- gcc/c-family/c-pretty-print.c (revision 189318)
+++ gcc/c-family/c-pretty-print.c (working copy)
@@ -474,6 +474,10 @@
pp_c_specifier_qualifier_list (pp, TREE_TYPE (t));
break;
+case MOD_TYPE:
+ pp_c_ws_string (pp, bswapped);
+ break;
+
case VECTOR_TYPE:
case COMPLEX_TYPE:
if (code == COMPLEX_TYPE)
Index: gcc/c-family/c.opt
===
--- gcc/c-family/c.opt (revision 189318)
+++ gcc/c-family/c.opt (working copy)
@@ -772,6 +772,10 @@
C++ ObjC++ Joined RejectNegative UInteger Var(max_constexpr_depth) Init(512)
-fconstexpr-depth=number Specify maximum constexpr recursion depth
+fbig-endian
+C Var(flag_big_endian)
+Compile code outside system headers as big-endian
+
fdebug-cpp
C ObjC C++ ObjC++
Emit debug annotations during preprocessing
Index: gcc/c-family/c-common.c
===
--- gcc/c-family/c-common.c (revision 189318)
+++ gcc/c-family/c-common.c (working copy)
@@ -417,6 +417,9 @@
{ _Fract, RID_FRACT, D_CONLY | D_EXT },
{ _Accum, RID_ACCUM, D_CONLY | D_EXT },
{ _Sat, RID_SAT, D_CONLY | D_EXT },
+ { _NativeEndian,RID_SAT, D_CONLY | D_EXT },
+ { _LittleEndian,RID_SAT, D_CONLY | D_EXT },
+ { _BigEndian, RID_SAT, D_CONLY | D_EXT },
{ _Static_assert, RID_STATIC_ASSERT, D_CONLY },
{ _Noreturn,RID_NORETURN, D_CONLY },
{ __FUNCTION__, RID_FUNCTION_NAME, 0 },
@@ -10850,6 +10853,9 @@
case RID_DFLOAT128:
case RID_FRACT:
case RID_ACCUM:
+case RID_NATIVE:
+case RID_LE:
+case RID_BE:
case RID_BOOL:
case RID_WCHAR:
case RID_CHAR16:
Index: gcc/c-family/c-common.h
===
--- gcc/c-family/c-common.h (revision 189318)
+++ gcc/c-family/c-common.h (working copy)
@@ -105,6 +105,7 @@
RID_TYPES_COMPATIBLE_P, RID_BUILTIN_COMPLEX, RID_BUILTIN_SHUFFLE,
RID_DFLOAT32, RID_DFLOAT64, RID_DFLOAT128,
RID_FRACT, RID_ACCUM,
+ RID_NATIVE, RID_BE, RID_LE,
/* C11 */
RID_ALIGNAS,
Index: gcc/c/c-convert.c
===
--- gcc/c/c-convert.c (revision 189318)
+++ gcc/c/c-convert.c (working copy)
@@ -92,6 +92,31 @@
STRIP_TYPE_NOPS (e);
+ if (TREE_CODE (TREE_TYPE (expr)) == MOD_TYPE)
+{
+ switch (TYPE_PRECISION (TREE_TYPE (expr)))
+ {
+ case 8:
+ e = fold_build1 (NOP_EXPR, TREE_TYPE (expr), e);
+ break;
+ case 16:
+ e = fold_build_call_array_loc (loc, TREE_TYPE (expr),
+ build_fold_addr_expr (builtin_decl_explicit (BUILT_IN_BSWAP16M)),
+ 1, e);
+ break;
+ case 32:
+ e = fold_build_call_array_loc (loc, TREE_TYPE (expr),
+ build_fold_addr_expr (builtin_decl_explicit (BUILT_IN_BSWAP32M)),
+ 1, e);
+ break;
+ case 64:
+ e = fold_build_call_array_loc (loc, TREE_TYPE (expr),
+ build_fold_addr_expr (builtin_decl_explicit (BUILT_IN_BSWAP64M)),
+ 1, e);
+ break;
+ }
+}
+
if (TYPE_MAIN_VARIANT (type) == TYPE_MAIN_VARIANT (TREE_TYPE (expr)))
return fold_convert_loc (loc, type, expr);
if (TREE_CODE (TREE_TYPE (expr)) == ERROR_MARK)
@@ -107,6 +132,31 @@
case VOID_TYPE:
return fold_convert_loc (loc, type, e);
+case MOD_TYPE:
+ e = convert (TREE_TYPE (type), e);
+ switch (TYPE_PRECISION (TREE_TYPE (e)))
+ {
+ case 8:
+ ret = fold_build1 (NOP_EXPR, TREE_TYPE (e), e);
+ break;
+ case 16:
+ ret = fold_build_call_array_loc (loc, type,
+ build_fold_addr_expr (builtin_decl_explicit (BUILT_IN_BSWAPM16)),
+ 1, e);
+ break;
+ case 32:
+ ret = fold_build_call_array_loc (loc, type,
+ build_fold_addr_expr
Re: PR57548 - Call to multiversioned function from global namespace
On Sat, Jun 8, 2013 at 4:03 PM, David Edelsohn dje@gmail.com wrote: FYI, gcc/cp has it's own ChangeLog file. Yes, it is confusing that some directories have their own and others do not. Fixed now. Sri. - David
Re: [patch] install host specific {bits,ext}/opt_random.h headers in host specific c++ incdir
Am 22.05.2013 11:18, schrieb Paolo Carlini: On 05/21/2013 10:25 AM, Matthias Klose wrote: Am 19.05.2013 11:40, schrieb Paolo Carlini: On 05/19/2013 11:35 AM, Andreas Schwab wrote: Tests that now fail, but worked before: Thanks Andreas. Matthias, please revert ASAP, thanks. you already did that. Looks like ext/random includes opt_random.h, which is not on any include dir, so make it ext/opt_random.h. tests all pass, and check the include with an installed version too. Ok, if nobody has further comments over the next day or so, let's try again ;) now on the trunk for some weeks. ok for the 4.8 branch as well? Matthias
[cilkplus] pragma simd C++: fix more testcases
The following patch fixes the remaining problems in the C++ front-end to
bring the pragma simd implementation on equal footing with the C FE.
Herein lie some small changes to the code parsing the initialization
statement in the for loop, as well as the condition. I also separated
out the for2.c test, since both frontends were sufficiently different
to warrant different tests.
The remaining Cilk Plus failure (for both C and C++) is
c-c++-common/cilk-plus/PS/for5.c, which I'm still investigating how to fix.
Pushed to branch.
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index c93ea9e..d68bdf7 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -30236,6 +30236,17 @@ cp_parser_simd_for_init_statement (cp_parser *parser,
tree *init,
error_at (loc, expected iteration declaration);
return error_mark_node;
}
+
+ if (cp_lexer_next_token_is_keyword (parser-lexer, RID_STATIC)
+ || cp_lexer_next_token_is_keyword (parser-lexer, RID_REGISTER)
+ || cp_lexer_next_token_is_keyword (parser-lexer, RID_EXTERN)
+ || cp_lexer_next_token_is_keyword (parser-lexer, RID_MUTABLE)
+ || cp_lexer_next_token_is_keyword (parser-lexer, RID_THREAD))
+{
+ error_at (loc, storage class is not allowed);
+ cp_lexer_consume_token (parser-lexer);
+}
+
cp_parser_parse_tentatively (parser);
cp_parser_type_specifier_seq (parser, true, false, type_specifiers);
if (cp_parser_parse_definitely (parser))
@@ -30332,7 +30343,8 @@ cp_parser_simd_for_init_statement (cp_parser *parser,
tree *init,
}
else
{
- decl = NULL_TREE;
+ if (decl != error_mark_node)
+ decl = NULL;
cp_parser_abort_tentative_parse (parser);
*init = cp_parser_expression (parser, false, NULL);
}
@@ -30379,6 +30391,7 @@ cp_parser_cilk_for (cp_parser *parser, enum rid
for_keyword, tree clauses)
return error_mark_node;
}
+ /* Parse initialization. */
if (for_keyword == RID_FOR)
decl = cp_parser_simd_for_init_statement (parser, init, pre_body);
@@ -30410,6 +30423,13 @@ cp_parser_cilk_for (cp_parser *parser, enum rid
for_keyword, tree clauses)
valid = false;
}
+ if (!valid)
+{
+ /* Skip to the semicolon ending the init. */
+ cp_parser_skip_to_end_of_statement (parser);
+}
+
+ /* Parse condition. */
if (!cp_parser_require (parser, CPP_SEMICOLON, RT_SEMICOLON))
return error_mark_node;
if (cp_lexer_next_token_is (parser-lexer, CPP_SEMICOLON))
@@ -30426,7 +30446,8 @@ cp_parser_cilk_for (cp_parser *parser, enum rid
for_keyword, tree clauses)
if (cond == error_mark_node)
valid = false;
cp_parser_consume_semicolon_at_end_of_statement (parser);
-
+
+ /* Parse increment. */
if (cp_lexer_next_token_is (parser-lexer, CPP_CLOSE_PAREN))
{
error_at (loc, missing increment);
diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index 16e2472..f8c5d82 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -6058,7 +6058,7 @@ finish_omp_cancellation_point (tree clauses)
tree
finish_cilk_for_cond (tree cond)
{
- return maybe_convert_cond (cond);
+ return cp_truthvalue_conversion (cond);
}
/* Begin a __transaction_atomic or __transaction_relaxed statement.
diff --git a/gcc/testsuite/c-c++-common/cilk-plus/PS/body.c
b/gcc/testsuite/c-c++-common/cilk-plus/PS/body.c
index 5ecefd5..fe8b630 100644
--- a/gcc/testsuite/c-c++-common/cilk-plus/PS/body.c
+++ b/gcc/testsuite/c-c++-common/cilk-plus/PS/body.c
@@ -12,7 +12,7 @@ void foo()
for (int i=0; i 1000; ++i)
{
if (c == 5)
- return; /* { dg-error return statments are not allowed } */
+ return; /* { dg-error \(return statments are not allowed\|invalid
exit\) } */
if (c == 6)
__builtin_setjmp (jmpbuf); /* { dg-error calls to setjmp are not
allowed } */
a[i] = b[i];
diff --git a/gcc/testsuite/c-c++-common/cilk-plus/PS/for2.c
b/gcc/testsuite/c-c++-common/cilk-plus/PS/for2.c
deleted file mode 100644
index dc0a41e..000
--- a/gcc/testsuite/c-c++-common/cilk-plus/PS/for2.c
+++ /dev/null
@@ -1,66 +0,0 @@
-/* { dg-do compile } */
-/* { dg-options -O3 -fcilkplus } */
-
-// Test storage classes in the initialization of a #pragma simd for
-// loop.
-
-int *a, *b;
-
-void foo()
-{
-#pragma simd
- for (static int foo=5; foo 10; ++foo)
-a[foo] = b[foo];
- /* { dg-error declaration of static variable storage class1 { target
*-*-* } 12 } */
- /* { dg-error induction variable cannot be static storage class2 {
target *-*-* } 12 } */
-
- static int bar;
-#pragma simd
- for (bar=0; bar 1000; ++bar) /* { dg-error induction variable cannot be
static } */
-a[bar] = bar;
-
-#pragma simd
- for (extern int var=0; var 1000; ++var)
-a[var] = var;
- /* { dg-error has both 'extern' and initializer extern { target *-*-* }
23 } */
- /* { dg-error declaration of static variable { target *-*-* } 23 } */
- /* { dg-error induction variable
Re: new mul* patterns U constraint in rl78
umul is used when the insn takes two operands in A and X, and computes a value into AX. This is similar to op2 which, in general, does AX = AX op (other register or memory). The devirtualizer will arrange for the right values to be in real registers for these. macax is used when the insn pattern itself reads from two virtual registers and writes to a virtual register (i.e. V = V op V), but clobbers AX anx BC in the process. The devirutalizer does not need to devirtualize these insns.
[gomp4/cilkplus] special case NE_EXPR for omp4 loops
Hi Jakub. In contrast to OMP4+, Cilk Plus allows a != in the condition to a simd for loop (we are guaranteed no unsigned wrap around). I'm not totally happy with the cleanliness of this patch, but the alternative seems a lot more convoluted. Type checking before hand, should guarantee that we don't get a NE_EXPR incorrectly (both for Cilk Plus and OMP). I guess we could add some sort of annotation to the OMP_SIMD that lets us know we were originally a Cilk Plus construct, but that hardly seems worth the effort for handling this case. Although, there could be more things to come ??, though none come to mind right now. Anyway, this patch fixes the last remaining testsuite failure for both C/C++: c-c++-common/cilk-plus/PS/for5.c. If you hate this too much, I can work on an alternative approach, otherwise I'll queue it up with my patchset sitting on top of your gomp4 branch (my aldyh/cilk-in-gomp branch). Thoughts? Aldy diff --git a/gcc/ChangeLog.cilkplus b/gcc/ChangeLog.cilkplus index 96a02c6..6a48ada 100644 --- a/gcc/ChangeLog.cilkplus +++ b/gcc/ChangeLog.cilkplus @@ -3,6 +3,7 @@ * Makefile.in (C_COMMON_OBJS): Depend on c-family/c-cilkplus.o. (c-cilkplus.o): New dependency. + * omp-low.c (extract_omp_for_data): Add case for NE_EXPR. c-family/ * c-cilkplus.c: New. diff --git a/gcc/omp-low.c b/gcc/omp-low.c index b131cde..08ed83b 100644 --- a/gcc/omp-low.c +++ b/gcc/omp-low.c @@ -316,6 +316,12 @@ extract_omp_for_data (gimple for_stmt, struct omp_for_data *fd, case LT_EXPR: case GT_EXPR: break; + case NE_EXPR: + if (!flag_enable_cilk) + gcc_unreachable (); + /* NE_EXPR is technically not allowed in OpenMP, but it is +allowed in Cilk Plus, which generates OMP_SIMD constructs. */ + break; case LE_EXPR: if (POINTER_TYPE_P (TREE_TYPE (loop-n2))) loop-n2 = fold_build_pointer_plus_hwi_loc (loc, loop-n2, 1);
Re: [c++-concepts] code review
On 06/08/2013 09:34 AM, Andrew Sutton wrote: I think I previously put constraint_info in lang_decl_min, right next to template_info no less. It was easy to manage there, and initialized as part of build_template_decl. But this obviously doesn't work for partial specializations unless they get template_decls. Right. And we would want it to be specific to template_decls, not all decls that use lang_decl_min. I'd be okay committing the current design with the caveat that it may need to be rewritten in the not-so-distant future. I've already written the other other way two or three times, so I'm familiar with those changes. Yeah, that sounds fine. On the topic of logic.cc, I'm plan on rewriting this module to use a set instead of lists. There will be some pretty substantial changes to the internal interfaces. Would it be reasonable to commit this now (since it works correctly), and plan to rewrite it in the near future? OK. I think I see where the problem is. cp_parser_requires_clause is parsed non-optionally in a requires expression, but that's not included in the patch. I factored out the explicit parsing (hence the assertion) from the optional parsing. The two situations seem pretty similar; you don't decide you're parsing a requires expression until you see the keyword either, right? The usual pattern in the parser is for a function to try to parse a particular construct and then return NULL_TREE if we're looking at something else; it seems most straightforward to do that in this case as well. What is the main entry point to overload resolution? Perhaps finish_call_expr is what you want. Jason
Re: [PATCH] tree-into-ssa.c: make interesting_blocks static
On 06/07/2013 10:36 AM, David Malcolm wrote: * tree-into-ssa.c (interesting_blocks): Make static. Ok. r~
Re: [patch] install host specific {bits,ext}/opt_random.h headers in host specific c++ incdir
Hi, Matthias Klose d...@ubuntu.com ha scritto: Am 22.05.2013 11:18, schrieb Paolo Carlini: On 05/21/2013 10:25 AM, Matthias Klose wrote: Am 19.05.2013 11:40, schrieb Paolo Carlini: On 05/19/2013 11:35 AM, Andreas Schwab wrote: Tests that now fail, but worked before: Thanks Andreas. Matthias, please revert ASAP, thanks. you already did that. Looks like ext/random includes opt_random.h, which is not on any include dir, so make it ext/opt_random.h. tests all pass, and check the include with an installed version too. Ok, if nobody has further comments over the next day or so, let's try again ;) now on the trunk for some weeks. ok for the 4.8 branch as well? Ok with me. Thanks, Paolo
C++ PATCH to warn about undefined functions in anonymous namespace
Since members of the anonymous namespace can't be defined in another
translation unit, we should treat them like statics for diagnostic purposes.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 815fbf1df6dafdbeb04a35827222d78c9b419219
Author: Jason Merrill ja...@redhat.com
Date: Mon Jun 10 12:29:35 2013 -0400
* name-lookup.c (add_decl_to_level): Add decls in an anonymous
namespace to static_decls.
diff --git a/gcc/cp/name-lookup.c b/gcc/cp/name-lookup.c
index 17d5ca2..2b1f9fb 100644
--- a/gcc/cp/name-lookup.c
+++ b/gcc/cp/name-lookup.c
@@ -597,7 +597,9 @@ add_decl_to_level (tree decl, cp_binding_level *b)
if ((VAR_P (decl)
(TREE_STATIC (decl) || DECL_EXTERNAL (decl)))
|| (TREE_CODE (decl) == FUNCTION_DECL
- (!TREE_PUBLIC (decl) || DECL_DECLARED_INLINE_P (decl
+ (!TREE_PUBLIC (decl)
+ || decl_anon_ns_mem_p (decl)
+ || DECL_DECLARED_INLINE_P (decl
vec_safe_push (b-static_decls, decl);
}
}
diff --git a/gcc/testsuite/g++.dg/warn/anonymous-namespace-5.C b/gcc/testsuite/g++.dg/warn/anonymous-namespace-5.C
new file mode 100644
index 000..6f5a081
--- /dev/null
+++ b/gcc/testsuite/g++.dg/warn/anonymous-namespace-5.C
@@ -0,0 +1,8 @@
+namespace {
+ void f(); // { dg-message never defined }
+}
+
+int main()
+{
+ f();
+}
Re: [PATCH] DATA_ALIGNMENT vs. DATA_ABI_ALIGNMENT (PR target/56564)
On Mon, Jun 10, 2013 at 11:44 AM, Jakub Jelinek ja...@redhat.com wrote:
On Mon, Jun 10, 2013 at 07:51:54AM -0700, Richard Henderson wrote:
On 06/07/2013 02:14 PM, Jakub Jelinek wrote:
When the linker merges common blocks, it chooses both maximum size and
maximum
alignment. Thus for any common block for which we can prove the block
must
reside in the module (any executable, or hidden common in shared
object), we
can go ahead and use the increased alignment.
But consider say:
one TU:
struct S { char buf[15]; } s __attribute__((aligned (32)));
another TU:
char c = 7;
struct S { char buf[15]; } s = { { 1, 2 } };
char d = 8;
int main () { return 0; }
(the aligned(32) is there just to simulate the DATA_ALIGNMENT optimization
increase). Linker warns about this (thus the question is if we want to
increase the alignment for optimization on commons at all) and doesn't
align
it.
Oh, right. I hadn't considered commons unifying with non-common variables,
and the failure of commoning in that case. I'd mostly been thinking of
uninitialized Fortran-like common blocks, where it is more common for the
blocks to have nothing in common but the name.
Ok, here is what I've committed to trunk (will wait for some time before
backporting). As discussed with Honza on IRC, decl_binds_to_current_def_p
will need further fixing, it does the wrong thing for extern int var
__attribute__((visibility (hidden))) or hidden DECL_COMMON symbols.
And, we don't have any feedback about SPE/E500 rs6000 - DATA_ALIGNMENT vs.
DATA_ABI_ALIGNMENT yet.
SPE/e500 support was written by Aldy. He or someone from Freescale
needs to comment.
- David
[patch, mips] Micromips delay slot fix
We found a bug in the micromips implementation where the branch delay slot was not getting filled for micromips. You can reproduce this with a program that just has an empty main function. Andrew Bennett created this fix for it and we would like to check it in. I am submitting it for Andrew since he doesn't have write access. OK to checkin? 2013-06-10 Andrew Bennett andrew.benn...@imgtec.com Steve Ellcey sell...@mips.com * config/mips/mips.md (single_insn): Fix attribute for micromips. diff --git a/gcc/config/mips/mips.md b/gcc/config/mips/mips.md index 2fdc79d..f18ab50 100644 --- a/gcc/config/mips/mips.md +++ b/gcc/config/mips/mips.md @@ -704,7 +704,9 @@ ;; Is it a single instruction? (define_attr single_insn no,yes - (symbol_ref (get_attr_length (insn) == (TARGET_MIPS16 ? 2 : 4) + (symbol_ref (((TARGET_MIPS16 || TARGET_MICROMIPS) + get_attr_length (insn) == 2) + || (!TARGET_MIPS16 get_attr_length (insn) == 4) ? SINGLE_INSN_YES : SINGLE_INSN_NO))) ;; Can the instruction be put into a delay slot?
Re: [PATCH, rs6000] power8 patches, patch #6, direct move basic quad load/store
On Mon, Jun 10, 2013 at 11:41:20AM -0400, David Edelsohn wrote: Mike, This patch is okay, but something seems really broken with respect to TImode. I don't know if we have to separate TImode from V1TImode or some distinction for atomics from other uses of TImode. This isn't like float modes where they mostly live in FPRs and only occassionally need to live in GPRs. TImode between VSX and GPRs really is bimodal. Something is wrong with this preferencing design. Yes, though at present, I'm not sure how to solve it. I worry that when the 128-bit add/subtract support is done, it will make the problem worse. Maybe we need a separate set of logical TImode instructions for the atomic ops with a neutral set of preferences on the constraints for movti. Then the registers chosen for the computation will correctly drive the register allocation decisions. I can redo the atomics to have all of the logical operations done in PTImode, which restricts it to GPRs. I need to think about it for the logical operation revist. -- Michael Meissner, IBM IBM, M/S 2506R, 550 King Street, Littleton, MA 01460, USA email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
Re: [PATCH] tree-into-ssa.c: make interesting_blocks static
On Mon, 2013-06-10 at 12:32 -0700, Richard Henderson wrote: On 06/07/2013 10:36 AM, David Malcolm wrote: * tree-into-ssa.c (interesting_blocks): Make static. Ok. Thanks; committed to svn trunk as r199911.
[Debug/Fortran] PR37132 - RFC/RFA - support DW_TAG_namelist
Dear all,
this patch implements DW_TAG_namelist for Fortran's namelists.
Unfortunately, it does not yet handle all cases:
a) Namelists in modules
b) Namelists in procedures (subroutines, functions)
The patch currently supports (b) but it does not handle (a). Suggestions
how to best implement (a) are highly welcome.
The first approach (for (b);
http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00560.html) was to add a
gcc_debug_hookshook and call it from the front end. That nicely works,
except: If the namelist contains a dummy argument - in that case, the
DWARF die is not yet available.
Hence,the new attempt: The namelist is stored in as BLOCK_VAR, which
nicely solves the problem (b). However, it does not simply work if the
namelist is declared in a module. In the latter case, the variables in
the module are created via toplev.c's emit_debug_global_declarations,
which calls dwarf2out_global_decl - dwarf2out_decl - gen_decl_die -
where declare_in_namespace takes care of creating the var in the correct
namespace (= DW_TAG_module).
My problem: I do not see where one can best handle the namelist for
modules. One possibility would be gen_namespace_die - but that would
come before the dies of all VAR_DECLs used in the namelist have been
created. And the code seems to assume that the decl is not emitted,
hence, one cannot simply use force_decl_die in gen_namespace_die. - One
possibility would be to add a lookup_decl_die() check (e.g. in
dwarf2out_global_decl) and to use force_decl_die, but I don't know
whether that's a good approach.
Suggestions?
* * *
For code like
subroutine test()
integer :: i,
real :: r
NAMELIST /nml/ i, r
end subroutine test
the patch now emits:
2238: Abbrev Number: 11 (DW_TAG_namelist)
239 DW_AT_name: nml
23d DW_AT_sibling : 0x24c
3241: Abbrev Number: 12 (DW_TAG_namelist_item)
242 DW_AT_namelist_items: 0x24c
3246: Abbrev Number: 12 (DW_TAG_namelist_item)
247 DW_AT_namelist_items: 0x255
224c: Abbrev Number: 13 (DW_TAG_variable)
24d DW_AT_name: i
...
* * *
Example for the not yet working case:
module m
integer :: j
namelist /nml/ j
end module m
Tobias
dwarf2out.c | 34
fortran/trans-decl.c | 60 +++
lto-streamer-in.c| 27 +-
lto-streamer-out.c | 17 ++
lto-streamer.h |3 +-
tree.c |2 +
tree.def | 10
tree.h |5
8 files changed, 155 insertions(+), 3 deletions(-)
diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index b615b18..0996768 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -3175,6 +3175,7 @@ static inline int is_redundant_typedef (const_tree);
static bool is_naming_typedef_decl (const_tree);
static inline dw_die_ref get_context_die (tree);
static void gen_namespace_die (tree, dw_die_ref);
+static void gen_namelist_decl (tree, dw_die_ref, tree);
static dw_die_ref gen_decl_die (tree, tree, dw_die_ref);
static dw_die_ref force_decl_die (tree);
static dw_die_ref force_type_die (tree);
@@ -20196,6 +20197,11 @@ gen_decl_die (tree decl, tree origin, dw_die_ref context_die)
gen_namespace_die (decl, context_die);
break;
+case NAMELIST_DECL:
+ gen_namelist_decl (DECL_NAME (decl), context_die,
+ NAMELIST_DECL_ASSOCIATED_DECL (decl));
+ break;
+
default:
/* Probably some frontend-internal decl. Assume we don't care. */
gcc_assert ((int)TREE_CODE (decl) NUM_TREE_CODES);
@@ -20357,6 +20363,34 @@ dwarf2out_imported_module_or_decl (tree decl, tree name, tree context,
}
+/* Output debug information for namelists. */
+
+static void
+gen_namelist_decl (tree name, dw_die_ref scope_die, tree item_decls)
+{
+ dw_die_ref nml_die, nml_item_die, nml_item_ref_die;
+ tree value;
+ unsigned i;
+
+ if (debug_info_level = DINFO_LEVEL_TERSE)
+return;
+
+ gcc_assert (scope_die != NULL);
+ nml_die = new_die (DW_TAG_namelist, scope_die, NULL);
+ add_AT_string (nml_die, DW_AT_name, IDENTIFIER_POINTER (name));
+
+ FOR_EACH_CONSTRUCTOR_VALUE (CONSTRUCTOR_ELTS (item_decls), i, value)
+{
+ nml_item_ref_die = lookup_decl_die (value);
+ if (!nml_item_ref_die)
+ nml_item_ref_die = force_decl_die (value);
+
+ nml_item_die = new_die (DW_TAG_namelist_item, nml_die, NULL);
+ add_AT_die_ref (nml_item_die, DW_AT_namelist_items, nml_item_ref_die);
+}
+}
+
+
/* Write the debugging output for DECL. */
void
diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c
index 87652ba..9aa14a8 100644
--- a/gcc/fortran/trans-decl.c
+++ b/gcc/fortran/trans-decl.c
@@ -4105,6 +4107,37 @@ gfc_module_add_decl (struct module_htab_entry *entry, tree decl)
static struct module_htab_entry *cur_module;
+
+/* Generate debugging symbols for namelists. This function must come after
+ generate_local_decl to ensure that
RE: [PATCH] Fix for PR c/57563
On Mon, 10 Jun 2013, Iyer, Balaji V wrote: I looked into it a bit more detail. It was an error on my side. I was removing the excess precision expr layer instead of fully folding it. I did that change (i.e. fully fold the expression) and all the errors seem to go away. Here is the fixed patch that fixes PR c/57563. It passes for 32 bit and 64 bit tests. Here are the changelog entries: This version is better, but if removing an EXCESS_PRECISION_EXPR there caused problems, why is it OK to remove CONVERT_EXPR and NOP_EXPR like you still do - won't that also cause type mismatches (at least if the conversions are to types that count as sufficiently different for GIMPLE purposes - say conversions between 32-bit and 64-bit integers)? Maybe you actually need to fold without removing any such wrappers first at all? -- Joseph S. Myers jos...@codesourcery.com
PING - Sort SH / H8300 ISR tests
Hello,
Any comments on that one?
Original message containing the attachment is here:
http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01086.html
On Mon, 2013-05-20 at 18:06 +0200, Oleg Endo wrote:
Hi,
I've noticed that testsuite/gcc.dg has some ISR related test cases that
probably should have went to testsuite/gcc.target. The tests in
question were mainly for SH, with two of them being used also for
H8/300.
Attached patch is supposed to fix that, also fixing some formatting
issues and target checking for some of the SH tests.
Unfortunately there's no H8/300 target test collection, so I took the
liberty of adding one.
Tested briefly with
make check-gcc RUNTESTFLAGS=sh.exp --target_board=sh-sim
\{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}
OK?
Cheers,
Oleg
testsuite/ChangeLog:
* gcc.target/h8300/h8300.exp: New.
* gcc.dg/pragma-isr.c: Move to ...
* gcc.target/sh/torture/pragma-isr.c: ... here ...
* gcc.target/h8300/pragma-isr.c: ... and here.
* gcc.dg/pragma-isr2.c: Move to ...
* gcc.target/sh/torture/pragma-isr2.c: ... here ...
* gcc.target/h8300/pragma-isr2.c: ... and here.
* gcc.dg/pragma-isr-trapa.c: Move to ...
* gcc.target/sh/pragma-isr-trapa.c: ... here.
* gcc.dg/pragma-isr-trapa2.c: Move to ...
* gcc.target/sh/pragma-isr-trapa2.c: ... here.
* gcc.dg/pragma-isr-trap_exit.c: Move to ...
* gcc.target/sh/pragma-isr-trap-exit.c: ... here.
* gcc.dg/pragma-isr-nosave_low_regs.c: Move to ...
* gcc.target/sh/pragma-isr-nosave_low_regs.c: ... here.
* gcc.dg/attr-isr-nosave_low_regs.c: Move to ...
* gcc.target/sh/attr-isr-nosave_low_regs.c: ... here.
* gcc.dg/attr-isr-trap_exit.c: Move to ...
* gcc.target/sh/attr-isr-trap_exit.c: ... here.
* gcc.dg/attr-isr-trapa.c: Move to ...
* gcc.target/sh/attr-isr-trapa.c: ... here.
Re: PING - Sort SH / H8300 ISR tests
On Jun 10, 2013, at 2:36 PM, Oleg Endo oleg.e...@t-online.de wrote: Any comments on that one? Nope. Seems like a good idea to me. Ok.
Re: [patch, mips] Micromips delay slot fix
On Mon, 10 Jun 2013, Steve Ellcey wrote: We found a bug in the micromips implementation where the branch delay slot was not getting filled for micromips. You can reproduce this with a program that just has an empty main function. Andrew Bennett created this fix for it and we would like to check it in. I am submitting it for Andrew since he doesn't have write access. Your fix aside shouldn't empty main expand simply to: jrc $ra ? There's no delay slot there. diff --git a/gcc/config/mips/mips.md b/gcc/config/mips/mips.md index 2fdc79d..f18ab50 100644 --- a/gcc/config/mips/mips.md +++ b/gcc/config/mips/mips.md @@ -704,7 +704,9 @@ ;; Is it a single instruction? (define_attr single_insn no,yes - (symbol_ref (get_attr_length (insn) == (TARGET_MIPS16 ? 2 : 4) + (symbol_ref (((TARGET_MIPS16 || TARGET_MICROMIPS) + get_attr_length (insn) == 2) + || (!TARGET_MIPS16 get_attr_length (insn) == 4) ? SINGLE_INSN_YES : SINGLE_INSN_NO))) Is it safe to assume an RTL insn whose length is 4 has only a single machine instruction in the microMIPS mode? What's the difference to the MIPS16 instruction set here? Maciej
RE: [PATCH] Fix for PR c/57563
-Original Message-
From: Joseph Myers [mailto:jos...@codesourcery.com]
Sent: Monday, June 10, 2013 5:18 PM
To: Iyer, Balaji V
Cc: gcc-patches@gcc.gnu.org; Jakub Jelinek; mpola...@gcc.gnu.org
Subject: RE: [PATCH] Fix for PR c/57563
On Mon, 10 Jun 2013, Iyer, Balaji V wrote:
I looked into it a bit more detail. It was an error on my side. I was
removing the excess precision expr layer instead of fully folding it.
I did that change (i.e. fully fold the expression) and all the errors
seem to go away. Here is the fixed patch that fixes PR c/57563. It
passes for
32 bit and 64 bit tests. Here are the changelog entries:
This version is better, but if removing an EXCESS_PRECISION_EXPR there caused
problems, why is it OK to remove CONVERT_EXPR and NOP_EXPR like you still
do - won't that also cause type mismatches (at least if the conversions are to
types that count as sufficiently different for GIMPLE purposes - say
conversions
between 32-bit and 64-bit integers)? Maybe you actually need to fold without
removing any such wrappers first at all?
I looked into it and they were an artifact of previous implementation. Those
while loops were not even being entered. Thus, I took them out. Here is a fixed
patch.
Thanks,
Balaji V. Iyer.
--
Joseph S. Myers
jos...@codesourcery.com
diff --git a/gcc/c/c-array-notation.c b/gcc/c/c-array-notation.c
old mode 100644
new mode 100755
index b1040da..3285969
--- a/gcc/c/c-array-notation.c
+++ b/gcc/c/c-array-notation.c
@@ -143,25 +143,18 @@ fix_builtin_array_notation_fn (tree an_builtin_fn, tree
*new_var)
|| an_type == BUILT_IN_CILKPLUS_SEC_REDUCE_MUTATING)
{
call_fn = CALL_EXPR_ARG (an_builtin_fn, 2);
- while (TREE_CODE (call_fn) == CONVERT_EXPR
-|| TREE_CODE (call_fn) == NOP_EXPR)
+ if (TREE_CODE (call_fn) == ADDR_EXPR)
call_fn = TREE_OPERAND (call_fn, 0);
- call_fn = TREE_OPERAND (call_fn, 0);
-
identity_value = CALL_EXPR_ARG (an_builtin_fn, 0);
- while (TREE_CODE (identity_value) == CONVERT_EXPR
-|| TREE_CODE (identity_value) == NOP_EXPR)
- identity_value = TREE_OPERAND (identity_value, 0);
func_parm = CALL_EXPR_ARG (an_builtin_fn, 1);
}
else
func_parm = CALL_EXPR_ARG (an_builtin_fn, 0);
- while (TREE_CODE (func_parm) == CONVERT_EXPR
-|| TREE_CODE (func_parm) == EXCESS_PRECISION_EXPR
-|| TREE_CODE (func_parm) == NOP_EXPR)
-func_parm = TREE_OPERAND (func_parm, 0);
-
+ /* Fully fold any EXCESSIVE_PRECISION EXPR that can occur in the function
+ parameter. */
+ func_parm = c_fully_fold (func_parm, false, NULL);
+
location = EXPR_LOCATION (an_builtin_fn);
if (!find_rank (location, an_builtin_fn, an_builtin_fn, true, rank))
diff --git a/gcc/testsuite/c-c++-common/cilk-plus/AN/builtin_fn_mutating.c
b/gcc/testsuite/c-c++-common/cilk-plus/AN/builtin_fn_mutating.c
index 6635565..7c194c2 100644
--- a/gcc/testsuite/c-c++-common/cilk-plus/AN/builtin_fn_mutating.c
+++ b/gcc/testsuite/c-c++-common/cilk-plus/AN/builtin_fn_mutating.c
@@ -44,11 +44,11 @@ int main(void)
max_value = array3[0] * array4[0];
for (ii = 0; ii 10; ii++)
if (array3[ii] * array4[ii] max_value) {
- max_value = array3[ii] * array4[ii];
max_index = ii;
}
-
+ for (ii = 0; ii 10; ii++)
+my_func (max_value, array3[ii] * array4[ii]);
#if HAVE_IO
for (ii = 0; ii 10; ii++)
FW: [PATCH] Fix for PR c/57563
Here is the ChangeLog entries. Sorry I forgot to include in my previous email. gcc/c/ChangeLog 2013-06-10 Balaji V. Iyer balaji.v.i...@intel.com * c-array-notation.c (fix_builtin_array_notation_fn): Fully folded excessive precision expressions in function parameters. Also removed couple unwanted while statements. gcc/testsuite/ChangeLog 2013-06-10 Balaji V. Iyer balaji.v.i...@intel.com PR c/57563 * c-c++-common/cilk-plus/AN/builtin_fn_mutating.c (main): Fixed a bug in how we check __sec_reduce_mutating function's result.
[linaro/gcc-4_8-branch] Backports from trunk
Hi, I have just backported the following revisions from trunk to linaro/gcc-4_8-branch: r198890,199254,199259,199260,199293,199294,199407,199408,199454,199544,199545 (as rev 199915) r199261 as rev 199916 r199606 as rev 199917 r199652,199653,199656,199657,199658 as rev 199919 r198879 as rev 199922 r199438, r199439 as rev 199923 Thanks, Christophe.
RE: [PATCH] Fix for PR c/57563
On Mon, 10 Jun 2013, Iyer, Balaji V wrote: This version is better, but if removing an EXCESS_PRECISION_EXPR there caused problems, why is it OK to remove CONVERT_EXPR and NOP_EXPR like you still do - won't that also cause type mismatches (at least if the conversions are to types that count as sufficiently different for GIMPLE purposes - say conversions between 32-bit and 64-bit integers)? Maybe you actually need to fold without removing any such wrappers first at all? I looked into it and they were an artifact of previous implementation. Those while loops were not even being entered. Thus, I took them out. Here is a fixed patch. Thanks, this patch is OK. -- Joseph S. Myers jos...@codesourcery.com
Re: [c++-concepts] code review
On 6/10/13, Diego Novillo dnovi...@google.com wrote: On 2013-06-09 20:34 , Gabriel Dos Reis wrote: So, my advice is for GCC source code to forget about the cxxx headers for the most part. I can see an instance where cmath or cstring would make a difference but given point (1) above, no it doesn't. Just use the traditional xxx.h headers and be done with it. Maybe I should have included this in our C++ coding standards, but I don't know how Benjamin, Lawrence, and Diego fee about it. Sounds reasonable to me. Me too. The split in headers always felt excessively artifical to me. -- Lawrence Crowl
Re: GCC does not support *mmintrin.h with function specific opts
Ping.
On Tue, Jun 4, 2013 at 2:41 PM, Sriraman Tallam tmsri...@google.com wrote:
Ping.
On Thu, May 23, 2013 at 2:41 PM, Sriraman Tallam tmsri...@google.com wrote:
Ping, for review of ipa-inline.c change.
Sri
On Mon, May 20, 2013 at 11:04 AM, Sriraman Tallam tmsri...@google.com
wrote:
On Fri, May 17, 2013 at 11:21 PM, Jakub Jelinek ja...@redhat.com wrote:
On Fri, May 17, 2013 at 09:00:21PM -0700, Sriraman Tallam wrote:
--- ipa-inline.c (revision 198950)
+++ ipa-inline.c (working copy)
@@ -374,7 +374,33 @@ can_early_inline_edge_p (struct cgraph_edge *e)
return false;
}
if (!can_inline_edge_p (e, true))
-return false;
+{
+ enum availability avail;
+ struct cgraph_node *callee
+= cgraph_function_or_thunk_node (e-callee, avail);
+ /* Flag an error when the inlining cannot happen because of target
option
+ mismatch but the callee is marked as always_inline. In -O0 mode
+ this will go undetected because the error flagged in
+ expand_call_inline in tree-inline.c might not execute and the
+ inlining will not happen. Then, the linker could complain about a
+ missing body for the callee if it turned out that the callee was
+ also marked gnu_inline with extern inline keyword as bodies of
such
+ functions are not generated. */
+ if ((!optimize
+|| flag_no_inline)
This should be if ((!optimize || flag_no_inline) on one line.
I'd prefer also the testcase for the ICEs, something like:
/* Test case to check if AVX intrinsics and function specific target
optimizations work together. Check by including x86intrin.h */
/* { dg-do compile } */
/* { dg-options -O2 -mno-sse -mno-avx } */
#include x86intrin.h
__m256 a, b, c;
void __attribute__((target (avx)))
foo (void)
{
a = _mm256_and_ps (b, c);
}
and another testcase that does:
/* { dg-do compile } */
#pragma GCC target (mavx) /* { dg-error whatever } */
Otherwise it looks good to me, but I'd prefer the i?86 maintainers to
review
it too (and Honza for ipa-inline.c?).
Honza, could you please take a look at the ipa-inline.c fix? I will
split the patches and submit after Honza's review. I will also make
the changes mentioned.
Thanks
Sri
Jakub
Re: [patch] PR 57362
Ping. On Tue, Jun 4, 2013 at 11:55 AM, Sriraman Tallam tmsri...@google.com wrote: Hi, Sorry for the long delay. Test case added and patch attached. OK to commit? Thanks Sri On Wed, May 22, 2013 at 5:14 PM, H.J. Lu hjl.to...@gmail.com wrote: On Wed, May 22, 2013 at 4:20 PM, Sriraman Tallam tmsri...@google.com wrote: Hi, http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57362 This ICE reported here happens because the array storing the function versions that should be processed is not indexed correctly. This patch fixes this. This only happens when some versions cannot be dispatched because a dispatcher for that is not available or is an invalid target. Is this alright? Thanks, Sri PR 57362 * config/i386/i386.c (dispatch_function_versions): Use actual_versions to index into function_version_info. Index: config/i386/i386.c === --- config/i386/i386.c (revision 199219) +++ config/i386/i386.c (working copy) @@ -29061,10 +29061,10 @@ dispatch_function_versions (tree dispatch_decl, if (predicate_chain == NULL_TREE) continue; + function_version_info [actual_versions].version_decl = version_decl; + function_version_info [actual_versions].predicate_chain = predicate_chain; + function_version_info [actual_versions].dispatch_priority = priority; actual_versions++; - function_version_info [ix - 1].version_decl = version_decl; - function_version_info [ix - 1].predicate_chain = predicate_chain; - function_version_info [ix - 1].dispatch_priority = priority; } /* Sort the versions according to descending order of dispatch priority. The You should also add the testcase in PR57362. -- H.J.
Re: PING - Sort SH / H8300 ISR tests
Oleg Endo oleg.e...@t-online.de wrote: Any comments on that one? SH portion looks OK. Regards, kaz
Re: [PATCH] gfortran testsuite: implicitly cleanup-modules
Hi Bernhard, Would you accept something like the patch in the message below into dejagnu? http://gcc.gnu.org/ml/fortran/2012-03/msg00094.html Yes, I'm happy to fix this limitation. However, your patch isn't complete .. you need to update the documentation, testsuite, etc. Please send a revised patch to deja...@gnu.org and I'll review it. Cheers, Ben signature.asc Description: Digital signature
[v3] more abi_tagging for DR130
Some of the DR130-mandated signature changes for C++11 require the use
of abi_tag to properly distinguish from C++98 calls of the same
function, but with a different return type.
I've audited libstdc++ for C++98/C++11 API differences that are
signature changes that mangle the same. C++11 to C++14 changes of this
type will be mangled with abi_tag(cxx14), but I didn't notice any.
I put in reproducers for the fail, but these are only active on ia32 at
the moment. I've found testing a specific multilib in libstdc++ (ie
-m32 on x76_64) more difficult than imagined, so am just simplifying to
one psABI that demonstrates the issue. No doubt there are others. I'm
not quite sure how to abstract this
Similar to the complex::real/imag use, there are separate test cases to
confirm the newly mangled versions. I've noticed that these newly
mangled names using abi_tag cannot be presently demangled: see PR57581.
Since this is impacting C++98/C++11 compat, I intend to put this on 4.8
branch after a couple of days mellowing on trunk.
tested x86_64/linux
tested i686/linux
-benjamin2013-06-10 Benjamin Kosnik b...@redhat.com
* include/bits/c++config (_GLIBCXX_ABI_TAG_CXX11): Add.
* include/bits/stl_map.h (erase): Use abi_tag when C++11.
* include/bits/stl_multimap.h: Same.
* include/bits/stl_multiset.h: Same.
* include/bits/stl_set.h: Same.
* include/bits/stl_tree.h: Same.
* include/std/complex (real, imag): Use macro for abi_tag.
* testsuite/lib/libstdc++.exp: Disable inlinling with -fno-inline.
* testsuite/util/testsuite_containers.h (erase_external): New
declarations.
(erase_external_iterators): Same.
(linkage_check_cxx98_cxx11_erase): Same.
(linkage_check_cxx98_cxx11_erase_iterators): Same.
* testsuite/util/testsuite_shared.cc: Define.
* testsuite/23_containers/map/modifiers/erase/abi_tag.cc: New.
* testsuite/23_containers/map/modifiers/erase/
dr130-linkage-check.cc: New.
* testsuite/23_containers/multimap/modifiers/erase/abi_tag.cc: New.
* testsuite/23_containers/multimap/modifiers/erase/
dr130-linkage-check.cc: New.
* testsuite/23_containers/multiset/modifiers/erase/abi_tag.cc: New.
* testsuite/23_containers/multiset/modifiers/erase/
dr130-linkage-check.cc: New.
* testsuite/23_containers/set/modifiers/erase/abi_tag.cc: New.
* testsuite/23_containers/set/modifiers/erase/dr130-linkage-check.cc:
New.
* testsuite/ext/profile/mutex_extensions_neg.cc: Adjust line number.
* testsuite/23_containers/map/dr130.cc: Move...
* testsuite/23_containers/map/modifiers/dr130.cc: ...here.
* testsuite/23_containers/multimap/dr130.cc: Move ...
* testsuite/23_containers/multimap/modifiers/dr130.cc: ...here.
* testsuite/23_containers/multiset/dr130.cc: Move...
* testsuite/23_containers/multiset/modifiers/dr130.cc: ...here.
* testsuite/23_containers/set/dr130.cc: Move...
* testsuite/23_containers/set/modifiers/dr130.cc: ...here.
diff --git a/libstdc++-v3/include/bits/c++config b/libstdc++-v3/include/bits/c++config
index 04ae4cb..aca8484 100644
--- a/libstdc++-v3/include/bits/c++config
+++ b/libstdc++-v3/include/bits/c++config
@@ -84,6 +84,12 @@
# define _GLIBCXX_DEPRECATED
#endif
+// Macros for ABI tag attributes.
+#ifndef _GLIBCXX_ABI_TAG_CXX11
+# define _GLIBCXX_ABI_TAG_CXX11 __attribute ((__abi_tag__ (cxx11)))
+#endif
+
+
#if __cplusplus
// Macro for constexpr, to support in mixed 03/0x mode.
diff --git a/libstdc++-v3/include/bits/stl_map.h b/libstdc++-v3/include/bits/stl_map.h
index 1f6763c..d05e4b9 100644
--- a/libstdc++-v3/include/bits/stl_map.h
+++ b/libstdc++-v3/include/bits/stl_map.h
@@ -690,7 +690,8 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
erase(const_iterator __position)
{ return _M_t.erase(__position); }
- // LWG 2059.
+ // LWG 2059
+ _GLIBCXX_ABI_TAG_CXX11
iterator
erase(iterator __position)
{ return _M_t.erase(__position); }
diff --git a/libstdc++-v3/include/bits/stl_multimap.h b/libstdc++-v3/include/bits/stl_multimap.h
index 696e298..809ea54 100644
--- a/libstdc++-v3/include/bits/stl_multimap.h
+++ b/libstdc++-v3/include/bits/stl_multimap.h
@@ -596,6 +596,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
{ return _M_t.erase(__position); }
// LWG 2059.
+ _GLIBCXX_ABI_TAG_CXX11
iterator
erase(iterator __position)
{ return _M_t.erase(__position); }
diff --git a/libstdc++-v3/include/bits/stl_multiset.h b/libstdc++-v3/include/bits/stl_multiset.h
index ea22f4c..8ceb02a 100644
--- a/libstdc++-v3/include/bits/stl_multiset.h
+++ b/libstdc++-v3/include/bits/stl_multiset.h
@@ -532,6 +532,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
* not touched in any way. Managing the pointer is the user's
* responsibility.
*/
+ _GLIBCXX_ABI_TAG_CXX11
iterator
erase(const_iterator __position)
{ return _M_t.erase(__position); }
@@ -583,6 +584,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
* touched in any way. Managing the pointer is the user's
*
Re: [patch] Fix non-deterministic output order for type stubs in DWARF output
I've committed this patch.
-cary
2013-06-10 Cary Coutant ccout...@google.com
gcc/
* dwarf2out.c (hash_external_ref): Use die_symbol or signature
for hash so that hash table traversal order is deterministic.
Index: gcc/dwarf2out.c
===
--- gcc/dwarf2out.c (revision 198260)
+++ gcc/dwarf2out.c (working copy)
@@ -7385,7 +7385,22 @@ static hashval_t
hash_external_ref (const void *p)
{
const struct external_ref *r = (const struct external_ref *)p;
- return htab_hash_pointer (r-type);
+ dw_die_ref die = r-type;
+ hashval_t h = 0;
+
+ /* We can't use the address of the DIE for hashing, because
+ that will make the order of the stub DIEs non-deterministic. */
+ if (! die-comdat_type_p)
+/* We have a symbol; use it to compute a hash. */
+h = htab_hash_string (die-die_id.die_symbol);
+ else
+{
+ /* We have a type signature; use a subset of the bits as the hash.
+ The 8-byte signature is at least as large as hashval_t. */
+ comdat_type_node_ref type_node = die-die_id.die_type_node;
+ memcpy (h, type_node-signature, sizeof (h));
+}
+ return h;
}
/* Compare external_refs. */
Re: [patch, mips] Micromips delay slot fix
On Mon, 2013-06-10 at 23:13 +0100, Maciej W. Rozycki wrote:
On Mon, 10 Jun 2013, Steve Ellcey wrote:
We found a bug in the micromips implementation where the branch delay slot
was not getting filled for micromips. You can reproduce this with a program
that just has an empty main function. Andrew Bennett created this fix for
it and we would like to check it in. I am submitting it for Andrew since he
doesn't have write access.
Your fix aside shouldn't empty main expand simply to:
jrc $ra
? There's no delay slot there.
Sorry, it should have been 'main(void) {return 0; }. Then you get (with
the patch):
j $31
move$2,$0
instead of:
move$2,$0
j $31
diff --git a/gcc/config/mips/mips.md b/gcc/config/mips/mips.md
index 2fdc79d..f18ab50 100644
--- a/gcc/config/mips/mips.md
+++ b/gcc/config/mips/mips.md
@@ -704,7 +704,9 @@
;; Is it a single instruction?
(define_attr single_insn no,yes
- (symbol_ref (get_attr_length (insn) == (TARGET_MIPS16 ? 2 : 4)
+ (symbol_ref (((TARGET_MIPS16 || TARGET_MICROMIPS)
+ get_attr_length (insn) == 2)
+ || (!TARGET_MIPS16 get_attr_length (insn) == 4)
? SINGLE_INSN_YES : SINGLE_INSN_NO)))
Is it safe to assume an RTL insn whose length is 4 has only a single
machine instruction in the microMIPS mode? What's the difference to the
MIPS16 instruction set here?
Maciej
I think so, I don't know of any microMIPS RTL instructions whose length
is 4 that would not be a single instruction. Maybe I should add
Catherine in to the discussion to see if she knows differently.
Steve Ellcey
sell...@mips.com
Re: [PATCH] DATA_ALIGNMENT vs. DATA_ABI_ALIGNMENT (PR target/56564)
@@ -986,12 +1053,10 @@ align_variable (tree decl, bool dont_out if (! DECL_THREAD_LOCAL_P (decl) || const_align = BITS_PER_WORD) align = const_align; } -#endif } +#endif I think this change in get_variable_align() is wrong; it results in unbalanced braces inside an #ifdef, if the #ifdef body is not included (i.e. CONSTANT_ALIGNMENT not defined), the compile fails...
Re: Add error message for mismatched parentheses in reservation string
On 13-06-07 9:12 AM, Tom de Vries wrote: Vladimir, If I introduce an unbalanced parentheses error in a reservation string, f.i. in athlon.md using the following patch: ... diff --git a/gcc/config/i386/athlon.md b/gcc/config/i386/athlon.md index d872b8f..b1ed5cd 100644 --- a/gcc/config/i386/athlon.md +++ b/gcc/config/i386/athlon.md @@ -90,7 +90,7 @@ (athlon-decode0 | athlon-decode1 | athlon-decode2)) ;; Double instructions behaves like two direct instructions. -(define_reservation athlon-double ((athlon-decode2, athlon-decode0) +(define_reservation athlon-double (athlon-decode2, athlon-decode0) | (nothing,(athlon-decode0 + athlon-decode1)) | (nothing,(athlon-decode1 + athlon-decode2 ... and rebuild cc1, I get a segmentation fault: ... build/genautomata gcc/config/i386/i386.md \ insn-conditions.md tmp-automata.c /bin/bash: line 1: 18077 Segmentation fault (core dumped) build/genautomata gcc/config/i386/i386.md insn-conditions.md tmp-automata.c make: *** [s-automata] Error 139 ... The segmentation fault happens because sequence_vect is set to NULL here in gen_regexp_sequence in genautomata.c: ... sequence_vect = get_str_vect (str, els_num, ',', TRUE); if (els_num 1) ... and sequence_vect is dereferenced here: ... else return gen_regexp_oneof (sequence_vect[0]); ... The patch adds error checking for the specific case of unbalanced parentheses, and for sequence_vect == NULL in general. Using the patch the error message becomes: ... genautomata: unbalanced parentheses in reservation `(athlon-decode2, athlon-decode0) | (nothing,(athlon-decode0 + athlon-decode1)) | (nothing,(athlon-decode1 + athlon-decode2)))' ... Tested by completing a non-bootstrap build. OK for trunk? Yes. Thank you for fixing that, Tom.
Re: [patch, mips] Micromips delay slot fix
On Tue, 11 Jun 2013, Steve Ellcey wrote:
Sorry, it should have been 'main(void) {return 0; }. Then you get (with
the patch):
j $31
move$2,$0
instead of:
move$2,$0
j $31
Hmm, something must have been missed then from the microMIPS patches as
our toolchain seems to get this case right:
.setnoreorder
.setnomacro
jr $31
move$2,$0
.setmacro
.setreorder
(no idea where the extraneous newline comes from, hmm). Catherine, can
you please double-check you haven't got anything outstanding yet?
Is it safe to assume an RTL insn whose length is 4 has only a single
machine instruction in the microMIPS mode? What's the difference to the
MIPS16 instruction set here?
I think so, I don't know of any microMIPS RTL instructions whose length
is 4 that would not be a single instruction. Maybe I should add
Catherine in to the discussion to see if she knows differently.
I advise care here, even if we currently have no such pattern. It's easy
to miss the dependency and any such bug introduced could trigger very
rarely only. Also (unlike with the standard ISA) some otherwise ordinary
instructions can't be scheduled into a delay slot, e.g. MOVEP or
LWP/LDP/SWP/SDP.
Maciej
[RS6000] Fix rs6000_adjust_atomic_subword in little-endian mode
Fixes gcc/testsuite/gcc.dg/sync-2.c * config/rs6000/rs6000.c (rs6000_adjust_atomic_subword): Calculate correct shift value in little-endian mode. diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c --- a/gcc/config/rs6000/rs6000.c +++ b/gcc/config/rs6000/rs6000.c @@ -17314,8 +17314,9 @@ rs6000_adjust_atomic_subword (rtx orig_mem, rtx *pshift, rtx *pmask) shift = gen_reg_rtx (SImode); addr = gen_lowpart (SImode, addr); emit_insn (gen_rlwinm (shift, addr, GEN_INT (3), GEN_INT (shift_mask))); - shift = expand_simple_binop (SImode, XOR, shift, GEN_INT (shift_mask), - shift, 1, OPTAB_LIB_WIDEN); + if (WORDS_BIG_ENDIAN) +shift = expand_simple_binop (SImode, XOR, shift, GEN_INT (shift_mask), +shift, 1, OPTAB_LIB_WIDEN); *pshift = shift; /* Mask for insertion. */
Re: [RFC] Implement Undefined Behavior Sanitizer (take 2)
On Mon, Jun 10, 2013 at 02:29:25PM +, Joseph S. Myers wrote: On Sat, 8 Jun 2013, Marek Polacek wrote: + if (code == LSHIFT_EXPR + !TYPE_UNSIGNED (TREE_TYPE (op0)) + (flag_isoc99 || flag_isoc11)) flag_isoc11 implies flag_isoc99, you only need to check flag_isoc99 here. Ah, sure. Thanks, Marek
Re: [RS6000] Fix rs6000_adjust_atomic_subword in little-endian mode
On Mon, Jun 10, 2013 at 9:42 PM, Anton Blanchard an...@samba.org wrote: Fixes gcc/testsuite/gcc.dg/sync-2.c * config/rs6000/rs6000.c (rs6000_adjust_atomic_subword): Calculate correct shift value in little-endian mode. Okay. Thanks, David
Re: [PATCH] ARM: Don't clobber CC reg when it is live after the peephole window
On 06/06/2013 01:23 PM, Meador Inge wrote: On 06/06/2013 08:11 AM, Richard Earnshaw wrote: I understand (and agree with) this bit... +(define_peephole2 + [(set (reg:CC CC_REGNUM) +(compare:CC (match_operand:SI 0 register_operand ) +(match_operand:SI 1 arm_rhs_operand ))) + (cond_exec (ne (reg:CC CC_REGNUM) (const_int 0)) + (set (match_operand:SI 2 register_operand ) (const_int 0))) + (cond_exec (eq (reg:CC CC_REGNUM) (const_int 0)) + (set (match_dup 2) (const_int 1))) + (match_scratch:SI 3 r)] + TARGET_32BIT !peep2_reg_dead_p (3, operands[0]) + [(set (match_dup 3) (minus:SI (match_dup 0) (match_dup 1))) + (parallel +[(set (reg:CC CC_REGNUM) + (compare:CC (const_int 0) (match_dup 3))) + (set (match_dup 2) (minus:SI (const_int 0) (match_dup 3)))]) + (set (match_dup 2) +(plus:SI (plus:SI (match_dup 2) (match_dup 3)) + (geu:SI (reg:CC CC_REGNUM) (const_int 0]) + ... but what's this bit about? The original intent was to revert back to the original peephole pattern (pre-PR 46975) when the CC reg is still live, but that doesn't properly maintain the CC state either (it just happened to pass in the test case I was looking at because I only cared about the Z flag, which is maintained the same). OK with the above bit left out? OK? -- Meador Inge CodeSourcery / Mentor Embedded
Re: [testsuite] Adding target nonpic to certain tests part. 2
Yep, that also works for us. I updated the patch. Is it ok for trunk?
--Alexander
2013/6/5 Patrick Marlier patrick.marl...@gmail.com:
Hi Alexander,
At least for TM testcase, I would prefer to add 'transaction_safe'
attribute on foobar as in the attached patch.
Aldy and Richard H: What do you think?
Thanks,
--
Patrick
On Wed, Jun 5, 2013 at 1:13 PM, Alexander Ivchenko aivch...@gmail.com wrote:
Hi,
Another bunch of tests that fails with -fpic.
from here: http://gcc.gnu.org/ml/gcc-patches/2013-01/msg00539.html
Since -fpic option is turned on by default in Android we have certain test
fails. The reason for that is that those tests rely on the
availability of functions, defined in them
and with -fpic compiler conservatively assumes that they are
AVAIL_OVERWRITABLE.
I added {target nonpic} to them as before.
Is it ok for trunk?
thanks,
Alexander
add_target_nonpic_02.patch
Description: Binary data
Re: Document Intel Silvermont support in invoke.texi
Please see updated patch. Is it ok to install? Thanks, Igor Changelog: 2013-06-11 Igor Zamyatin igor.zamya...@intel.com * doc/invoke.texi (core-avx2): Document. (slm): Likewise. (atom): Updated with MOVBE. diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi index b7b32f7..dd82880 100644 --- a/gcc/doc/invoke.texi +++ b/gcc/doc/invoke.texi @@ -13833,10 +13833,19 @@ Intel Core CPU with 64-bit extensions, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, AVX, AES, PCLMUL, FSGSBASE, RDRND and F16C instruction set support. +@item core-avx2 +Intel Core CPU with 64-bit extensions, MOVBE, MMX, SSE, SSE2, SSE3, SSSE3, +SSE4.1, SSE4.2, AVX, AVX2, AES, PCLMUL, FSGSBASE, RDRND, FMA, BMI, BMI2 +and F16C instruction set support. + @item atom -Intel Atom CPU with 64-bit extensions, MMX, SSE, SSE2, SSE3 and SSSE3 +Intel Atom CPU with 64-bit extensions, MOVBE, MMX, SSE, SSE2, SSE3 and SSSE3 instruction set support. +@item slm +Intel Silvermont CPU with 64-bit extensions, MOVBE, MMX, SSE, SSE2, SSE3, SSSE3, +SSE4.1 and SSE4.2 instruction set support. + @item k6 AMD K6 CPU with MMX instruction set support. On Mon, Jun 10, 2013 at 5:29 PM, Jakub Jelinek ja...@redhat.com wrote: On Mon, Jun 10, 2013 at 05:25:36PM +0400, Igor Zamyatin wrote: Following patch documents Intel Silvermont support. OK to install? 2013-06-10 Igor Zamyatin igor.zamya...@intel.com * doc/invoke.texi: Document slm. diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi index b7b32f7..e4f1d45 100644 --- a/gcc/doc/invoke.texi +++ b/gcc/doc/invoke.texi @@ -13837,6 +13837,10 @@ set support. Intel Atom CPU with 64-bit extensions, MMX, SSE, SSE2, SSE3 and SSSE3 instruction set support. +@item slm +Intel Silvermont CPU with 64-bit extensions, MMX, SSE, SSE2, SSE3 and SSSE3, +SSE4.1, SSE4.2 instruction set support. Shouldn't it also list MOVBE (similarly for atom and core-avx2, btver2 already lists it). core-avx2 isn't even documented at all in invoke.texi. Jakub
