RE: A case exposing code sink issue
The job to do this is final value replacement, not sinking (we do not sink non-invariant expressions - you'd have to translate them through the loop-closed SSA exit PHI node, certainly doable, patches welcome ;)). Richard, In final value replacement, expression a + D. can be figured out, while a[i_xxx] failed to be CHRECed, so I'm wondering if we should lower a[i_xxx] to a + unitsize(a) * i_xxx first? It seems GCC intends to keep a[i_xxx] until cfgexpand pass. Or we have to directly modify CHREC algorithm to get it calculated? Appreciate your kindly help in advance! Thanks, -Jiangning
FW: a nifty feature for c preprocessor
i'm an amateur programmer that just started learning C. i like most of the features, specially the c preprocessor that it comes packed with. it's an extremely portable way of implementing metaprogramming in C. though i've always thought it lacked a single feature -- an evaluation feature. say i have these definitions: #define MACRO_1 (x/y)*y #define MACRO_2 sqrt(a) #define MACRO_3 calc13() #define MACRO_15 (a + b)/c now, all throughout the codebase, whenever and whichever of MACRO_1, or MACRO_2 (or so forth) needs to be called, they are conveniently indexed by another macro expansion: #define CONCAT(a, b) a##b #define CONCAT_VAR(a, b) CONCAT(a, b) #define MASTER_MACRO(N) CONCAT_VAR(MACRO_, N) now, if we use MASTER_MACRO with a direct value: MASTER_MACRO(10) or #define N 10 MASTER_MACRO(10) both will work. but substitute this with: #define N ((5*a)/c + (10*b)/c + ((5*a) % c + (10*b) % c)/c) and MASTER_MACRO expands to: MACRO_((5*a)/c + (10*b)/c + ((5*a) % c + (10*b) % c)/c) which, of course is wrong. there are other workarounds or many times this scheme can be avoided altogether. but it can be made to work (elegantly) by adding an eval preprocessor operation: so we redefine MASTER_MACRO this way: #define MASTER_MACRO(N) CONCAT_VAR(MACRO_, eval(N)) which evaluates correctly. this nifty trick (though a bit extended than what i elaborated above) can also be used to *finally* have increments and decrements (among others). since eval forces the evaluation of an *arithmetic* expression (for now), it will force the evaluation of an expression, then define it to itself. this will of course trigger a redefinition flag from our beloved preprocessor, but the defined effect would be: #define X (((14*x)/y)/z) /* say this evaluates to simply 3 */ incrementing X, will simply be: #define X eval(eval(X) + 1) /* 1) will be evaluated as 4 before any token substitution */ #define X eval(eval(X) + 1) /* 2) will be evaluated as 5 before any token substitution */ that easy. to suppress the redef warnings, we can have another directive like force_redef (which can only work in conjunction with eval) #force_redef X eval(eval(X) + 1) i'm just confused :-S... why hasn't this been suggested? i would love to have this incorporated (even just on test builds) to gcc. it would make my code so, so much more manageable and virtually extensible to more platforms. i would love to have a go at it and probably modify the gcc preprocessor, but i since i know nothing of it's implementation details, i don't know where to begin. i was hoping that this being a gnu implementation, it's been heavily modularized (the fact that gcc was heavily revised back then to use abstract syntax trees, gimple, etc, past version 2.95 -- ???). so i can easily interrupt the parsing operation (i wouldn't dare implement a pre-preprocessing operation, being big and redundant), then substitute the eval, then make the whole prasing go again. any advice for a novice? thnx.
c preprocessor feature suggestion
i'm an amateur programmer that just started learning C. i like most of the features, specially the c preprocessor that it comes packed with. it's an extremely portable way of implementing metaprogramming in C. though i've always thought it lacked a single feature -- an evaluation feature. say i have these definitions: #define MACRO_1 (x/y)*y #define MACRO_2 sqrt(a) #define MACRO_3 calc13() #define MACRO_15 (a + b)/c now, all throughout the codebase, whenever and whichever of MACRO_1, or MACRO_2 (or so forth) needs to be called, they are conveniently indexed by another macro expansion: #define CONCAT(a, b) a##b #define CONCAT_VAR(a, b) CONCAT(a, b) #define MASTER_MACRO(N) CONCAT_VAR(MACRO_, N) now, if we use MASTER_MACRO with a direct value: MASTER_MACRO(10) or #define N 10 MASTER_MACRO(10) both will work. but substitute this with: #define N((5*a)/c + (10*b)/c + ((5*a) % c + (10*b) % c)/c) and MASTER_MACRO expands to: MACRO_((5*a)/c + (10*b)/c + ((5*a) % c + (10*b) % c)/c) which, of course is wrong. there are other workarounds or many times this scheme can be avoided altogether. but it can be made to work (elegantly) by adding an eval preprocessor operation: so we redefine MASTER_MACRO this way: #define MASTER_MACRO(N) CONCAT_VAR(MACRO_, eval(N)) which evaluates correctly. this nifty trick (though a bit extended than what i elaborated above) can also be used to *finally* have increments and decrements (among others). since eval forces the evaluation of an *arithmetic* expression (for now), it will force the evaluation of an expression, then define it to itself. this will of course trigger a redefinition flag from our beloved preprocessor, but the defined effect would be: #define X (((14*x)/y)/z)/* say this evaluates to simply 3 */ incrementing X, will simply be: #define X eval(eval(X) + 1)/* 1) will be evaluated as 4 before any token substitution */ #define X eval(eval(X) + 1)/* 2) will be evaluated as 5 before any token substitution */ that easy. to suppress the redef warnings, we can have another directive like force_redef (which can only work in conjunction with eval) #force_redef X eval(eval(X) + 1) i'm just confused :-S... why hasn't this been suggested? i would love to have this incorporated (even just on test builds) to gcc. it would make my code so, so much more manageable and virtually extensible to more platforms. i would love to have a go at it and probably modify the gcc preprocessor, but i since i know nothing of it's implementation details, i don't know where to begin. i was hoping that this being a gnu implementation, it's been heavily modularized (the fact that gcc was heavily revised back then to use abstract syntax trees, gimple, etc, past version 2.95 -- ???). so i can easily interrupt the parsing operation (i wouldn't dare implement a pre-preprocessing operation, being big and redundant), then substitute the eval, then make the whole prasing go again. any advice for a novice? thnx.
[Bug tree-optimization/51684] [4.7 Regression]: ICE in gfortran.dg/maxloc_bounds_5 on ia64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51684
Ira Rosen irar at il dot ibm.com changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2011-12-27
CC||irar at il dot ibm.com
AssignedTo|unassigned at gcc dot |irar at il dot ibm.com
|gnu.org |
Ever Confirmed|0 |1
--- Comment #1 from Ira Rosen irar at il dot ibm.com 2011-12-27 13:53:13 UTC
---
Untested patch:
Index: tree-vect-slp.c
===
--- tree-vect-slp.c (revision 182692)
+++ tree-vect-slp.c (working copy)
@@ -2885,6 +2885,8 @@ vect_schedule_slp_instance (slp_tree nod
REFERENCE_CLASS_P (gimple_get_lhs (stmt)))
{
gimple last_store = vect_find_last_store_in_slp_instance (instance);
+ if (is_pattern_stmt_p (vinfo_for_stmt (last_store)))
+ last_store = STMT_VINFO_RELATED_STMT (vinfo_for_stmt (last_store));
si = gsi_for_stmt (last_store);
}
@@ -2989,6 +2991,8 @@ vect_schedule_slp (loop_vec_info loop_vi
if (!STMT_VINFO_DATA_REF (vinfo_for_stmt (store)))
break;
+ if (is_pattern_stmt_p (vinfo_for_stmt (store)))
+ store = STMT_VINFO_RELATED_STMT (vinfo_for_stmt (store));
/* Free the attached stmt_vec_info and remove the stmt. */
gsi = gsi_for_stmt (store);
gsi_remove (gsi, true);
[Bug target/51685] New: FAIL: gcc.dg/tm/pr51472.c (internal compiler error) on ppc*-*-*, s390*-*-*, spu-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51685 Bug #: 51685 Summary: FAIL: gcc.dg/tm/pr51472.c (internal compiler error) on ppc*-*-*, s390*-*-*, spu-*-* Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr CC: al...@gcc.gnu.org Target: ppc*-*-* s390*-*-* spu-*-* The test gcc.dg/tm/pr51472.c introduced at revision 182588 fails on ppc*-*-*, s390*-*-*, and spu-*-*: [karma] f90/bug% gcc47 -fgnu-tm -O --param tm-max-aggregate-size=32 /opt/gcc/work/gcc/testsuite/gcc.dg/tm/pr51472.c /opt/gcc/work/gcc/testsuite/gcc.dg/tm/pr51472.c: In function 'foo': /opt/gcc/work/gcc/testsuite/gcc.dg/tm/pr51472.c:8:1: error: missing definition for SSA_NAME: v.0_2 in statement: # .MEM_9 = VDEF .MEM_6 D.2083 = v.0_2; /opt/gcc/work/gcc/testsuite/gcc.dg/tm/pr51472.c:8:1: internal compiler error: verify_ssa failed
[Bug tree-optimization/51683] New: [4.7 Regression] __builtin_memcpy etc. with constant first argument optimized away by ccp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51683
Bug #: 51683
Summary: [4.7 Regression] __builtin_memcpy etc. with constant
first argument optimized away by ccp
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: ja...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
static inline void *
bar (void *p, void *q, int r)
{
return __builtin_memcpy (p, q, r);
}
void *
foo (void *p)
{
return bar ((void *) 0x12345000, p, 256);
}
at -O2 starting with http://gcc.gnu.org/viewcvs?root=gccview=revrev=175290
is optimized away. While the return value from memcpy is known to be constant
and we know that constant, we ignore the other side-effects of the call.
[Bug libfortran/32770] [Meta-bug] -fdefault-integer-8 issues
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32770 --- Comment #35 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-12-27 11:04:09 UTC --- Created attachment 26186 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26186 Failures with -fdefault-integer-8 at revision 182676 New summaries of failures with -fdefault-integer-8 at revision 182676 (I have attached the list) === gfortran Summary for unix/-m32/-fdefault-integer-8 === of expected passes37794 of unexpected failures489 of expected failures39 of unresolved testcases24 of unsupported tests570 === gfortran Summary for unix/-m64/-fdefault-integer-8 === # of expected passes38111 # of unexpected failures499 # of expected failures39 # of unresolved testcases24 # of unsupported tests409
[Bug fortran/32957] C/Fortran interoperability and -fdefault-integer-8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32957 --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-12-27 11:14:24 UTC --- Created attachment 26187 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26187 patch to fix some failures with -fdefault-integer-8 I have this patch in my tree for a quite long time. It fixes some failures with -fdefault-integer-8 by replacing some implicit kinds with explicit ones.
[Bug libstdc++/51673] undefined references / libstdc++-7.dll
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51673 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-12-27 Ever Confirmed|0 |1 --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2011-12-27 10:26:42 UTC --- To be clear, no matter what, undefined references is a bug, in any mode of the library even the most esoteric ;) The fix may be simple too.
[Bug c++/51680] g++ 4.7 fails to inline trivial template stuff
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51680 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2011-12-27 14:15:06 UTC --- To be honest, this kind of expectation is completely new to me. I may be wrong, but I don't think we have anything dealing specially with templates from the inlining point of view.
[Bug tree-optimization/51683] [4.7 Regression] __builtin_memcpy etc. with constant first argument optimized away by ccp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51683 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-12-27 11:33:01 UTC --- Created attachment 26188 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26188 gcc47-pr51683.patch Untested fix.
[Bug tree-optimization/48641] [4.7 Regression] ICE: verify_flow_info failed: Wrong frequency of block 77 -419530 with -O -fno-tree-ccp -fno-tree-copy-prop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48641 --- Comment #5 from Jan Hubicka hubicka at gcc dot gnu.org 2011-12-27 10:42:01 UTC --- Author: hubicka Date: Tue Dec 27 10:41:58 2011 New Revision: 182693 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182693 Log: PR middle-end/48641 * tree-ssa-threadupdate.c (redirect_edges): Watch for overflow. * gcc.dg/compile/pr48641.c: New file. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr48641.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-threadupdate.c
[Bug rtl-optimization/51667] [4.7 Regression] new FAIL: 27_io/basic_*stream/* execution test with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51667
--- Comment #17 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-12-27
16:25:52 UTC ---
Author: ebotcazou
Date: Tue Dec 27 16:25:43 2011
New Revision: 182694
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182694
Log:
PR rtl-optimization/51667
* ree.c (insn_merge_code): Delete.
(is_insn_merge_attempted): Likewise.
(get_insn_status): Likewise.
(set_insn_status): Likewise.
(struct ext_cand): Add CODE and MODE fields.
(combine_set_extend): Rename to...
(combine_set_extension): ...this. Use above fields and tidy up.
(transform_ifelse): Likewise.
(get_defs): Return the chain of definitions.
(is_this_a_cmove): Merge into...
(is_cond_copy_insn): ...this. Return bool.
(make_defs_and_copies_lists): Adjust calls to get_defs and simplify.
(merge_def_and_ext): Adjust call to combine_set_extend.
(combine_reaching_defs): Remove calls to {g|s}et_insn_status.
(struct extend_info): Rename to...
(struct re_info): ...this. Add DEF_MAP field.
(add_ext_candidate): Merge into...
(add_removable_extension): ...this. Adjust calls to get_defs. Ensure
reaching definitions are associated with only one kind of extension.
(find_removable_extensions): Create and destroy the definition map.
(find_and_remove_re): Return void. Change 'long' variables to 'int'.
Do not deal with is_insn_merge_attempted.
Added:
trunk/gcc/testsuite/gcc.c-torture/execute/20111227-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ree.c
trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/51667] [4.7 Regression] new FAIL: 27_io/basic_*stream/* execution test with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51667 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #18 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-12-27 16:28:42 UTC --- Thanks for the testing.
[Bug libstdc++/51673] undefined references / libstdc++-7.dll
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51673 --- Comment #4 from Pawel Sikora pluto at agmk dot net 2011-12-27 09:32:11 UTC --- i'm using the mt allocator for large std containers with small fixed-size objects. the mt's flexible pool configuration and alloc/free speed are an advantage over the simple new (malloc/free) allocator and i'd like to avoid reinventing the wheel with yet another pool allocator.
[Bug tree-optimization/48641] [4.7 Regression] ICE: verify_flow_info failed: Wrong frequency of block 77 -419530 with -O -fno-tree-ccp -fno-tree-copy-prop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48641 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2011-12-27 12:12:32 UTC --- Fixed.
[Bug tree-optimization/51684] [4.7 Regression]: ICE in gfortran.dg/maxloc_bounds_5 on ia64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51684 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org Target Milestone|--- |4.7.0
[Bug rtl-optimization/51667] [4.7 Regression] new FAIL: 27_io/basic_*stream/* execution test with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51667 --- Comment #16 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-12-27 11:56:06 UTC --- I confirm that the patch in comment #15 fixes the PR without visible side effect so far. Thanks.
[Bug fortran/51682] New: Coarray ICEs when compiling with -fdefault-integer-8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51682 Bug #: 51682 Summary: Coarray ICEs when compiling with -fdefault-integer-8 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr CC: bur...@net-b.de The following coarray tests give an ICE when compiled with -fdefault-integer-8: FAIL: gfortran.dg/coarray/alloc_comp_1.f90 -fcoarray=lib -O2 -lcaf_single (internal compiler error) FAIL: gfortran.dg/coarray/image_index_1.f90 -fcoarray=lib -O2 -lcaf_single (internal compiler error) FAIL: gfortran.dg/coarray/image_index_2.f90 -fcoarray=lib -O2 -lcaf_single (internal compiler error) FAIL: gfortran.dg/coarray/lock_1.f90 -fcoarray=lib -O2 -lcaf_single (internal compiler error) FAIL: gfortran.dg/coarray/poly_run_1.f90 -fcoarray=lib -O2 -lcaf_single (internal compiler error) FAIL: gfortran.dg/coarray/poly_run_2.f90 -fcoarray=lib -O2 -lcaf_single (internal compiler error) FAIL: gfortran.dg/coarray/poly_run_3.f90 -fcoarray=lib -O2 -lcaf_single (internal compiler error) FAIL: gfortran.dg/coarray/scalar_alloc_1.f90 -fcoarray=lib -O2 -lcaf_single (internal compiler error) FAIL: gfortran.dg/coarray/this_image_2.f90 -fcoarray=lib -O2 -lcaf_single (internal compiler error) The ICEs are of the kind [macbook] f90/bug% gfc /opt/gcc/work/gcc/testsuite/gfortran.dg/coarray/alloc_comp_1.f90 -fcoarray=lib -O2 -lcaf_single -fdefault-integer-8 /opt/gcc/work/gcc/testsuite/gfortran.dg/coarray/alloc_comp_1.f90: In function 'MAIN__': /opt/gcc/work/gcc/testsuite/gfortran.dg/coarray/alloc_comp_1.f90:5:0: error: type mismatch in binary expression integer(kind=8) integer(kind=4) integer(kind=8) D.1923 = _gfortran_caf_this_image.7 + 2; /opt/gcc/work/gcc/testsuite/gfortran.dg/coarray/alloc_comp_1.f90:5:0: internal compiler error: verify_gimple failed Note that I am not surprised by the failure, but if the error is expected, gfortran should not emit an ICE.
[Bug target/51681] [4.7 Regression]: ICE in gcc.dg/torture/vshuf-v2si.c on ia64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51681 --- Comment #1 from Uros Bizjak ubizjak at gmail dot com 2011-12-27 11:39:00 UTC --- Maybe related: FAIL: gcc.dg/torture/vshuf-v8qi.c -O2 execution test
[Bug c++/51680] g++ 4.7 fails to inline trivial template stuff
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51680 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-12-27 11:14:05 UTC --- This seems somehow intended (I don't think I would have expected process_fun_at to be inlined at -O2 (vs -O3), missing the inline keyword). Let's ask Honza.
I look for a nice man to take me go to partner
Privet, gentleman! If only I could have come up with the right words to express the depth of the beautiful feeling that I have in my heart www.simpleitislove.in/ The best thing I can do is to show you my deepest dreams and hopes about love, about our happy relationship and sweetest memories that we can create together with my soul mate. Find me, I need you as an air. All the best renee
[Bug target/51681] New: [4.7 Regression]: ICE in gcc.dg/torture/vshuf-v2si.c on ia64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51681
Bug #: 51681
Summary: [4.7 Regression]: ICE in gcc.dg/torture/vshuf-v2si.c
on ia64
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ubiz...@gmail.com
Target: ia64
Also crashes in crosscompiler:
~/gcc-build-xxx/gcc/cc1 -O2 -quiet vshuf-v2si.c
In file included from vshuf-v2si.c:17:0:
vshuf-main.inc: In function ‘test_12’:
vshuf-main.inc:28:1: internal compiler error: in expand_vec_perm_shrp, at
config/ia64/ia64.c:11107
Please submit a full bug report,
[...]
Breakpoint 2, internal_error (gmsgid=0xd8d205 in %s, at %s:%d) at
../../gcc-svn/trunk/gcc/diagnostic.c:839
839 {
(gdb) bt
#0 internal_error (gmsgid=0xd8d205 in %s, at %s:%d) at
../../gcc-svn/trunk/gcc/diagnostic.c:839
#1 0x00bd4f64 in fancy_abort (file=optimized out, line=11107,
function=0xce6410 expand_vec_perm_shrp)
at ../../gcc-svn/trunk/gcc/diagnostic.c:899
#2 0x00a71885 in expand_vec_perm_shrp (d=0x7fffd100) at
../../gcc-svn/trunk/gcc/config/ia64/ia64.c:11107
#3 expand_vec_perm_1 (d=0x7fffd100) at
../../gcc-svn/trunk/gcc/config/ia64/ia64.c:11164
#4 0x00a718bd in ia64_expand_vec_perm_const_1 (d=0x7fffd100) at
../../gcc-svn/trunk/gcc/config/ia64/ia64.c:11390
#5 0x00a7af58 in ia64_expand_vec_perm_const (operands=optimized out)
at ../../gcc-svn/trunk/gcc/config/ia64/ia64.c:11467
#6 0x00a9af44 in gen_vec_perm_constv2si (operand0=0x711ff320,
operand1=0x711ff0e0, operand2=0x711ff340,
operand3=0x71546d80) at
../../gcc-svn/trunk/gcc/config/ia64/vect.md:1601
#7 0x007a1119 in maybe_expand_insn (icode=optimized out,
nops=optimized out, ops=optimized out)
at ../../gcc-svn/trunk/gcc/optabs.c:8301
#8 0x007a15fa in expand_vec_perm_1 (icode=CODE_FOR_vec_perm_constv2si,
target=optimized out, v0=0x711ff0e0, v1=0x711fa9c0,
sel=optimized out) at ../../gcc-svn/trunk/gcc/optabs.c:6874
#9 0x007a8052 in expand_vec_perm (mode=V2SImode, v0=0x711ff0e0,
v1=0x711fa9c0, sel=0x71546d80, target=0x711fa978)
at ../../gcc-svn/trunk/gcc/optabs.c:6915
(gdb) frame 2
#2 0x00a71885 in expand_vec_perm_shrp (d=0x7fffd100) at
../../gcc-svn/trunk/gcc/config/ia64/ia64.c:11107
11107 gcc_assert (IN_RANGE (shift, 1, 63));
(gdb) p shift
$1 = 96
(gdb) p d-perm[0]
$2 = 3 '\003'
(gdb) p debug_rtx (d-op0)
(reg:V2SI 340 [ a.22 ])
$3 = void
(gdb) p debug_rtx (d-op1)
(reg:V2SI 358)
$4 = void
Probably some adjustment to shift is missing when selecting second operand.
[Bug tree-optimization/51684] New: [4.7 Regression]: ICE in gfortran.dg/maxloc_bounds_5 on ia64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51684 Bug #: 51684 Summary: [4.7 Regression]: ICE in gfortran.dg/maxloc_bounds_5 on ia64 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: ubiz...@gmail.com A problem in SLP vectorizer, can be triggered with a cross: $ ~/gcc-build-xxx/gcc/f951 -O3 -quiet maxloc_bounds_5.f90 maxloc_bounds_5.f90: In function ‘foo’: maxloc_bounds_5.f90:6:0: internal compiler error: in gsi_for_stmt, at gimple-iterator.c:560 Please submit a full bug report, [...] (gdb) bt #0 internal_error (gmsgid=0xdfea45 in %s, at %s:%d) at ../../gcc-svn/trunk/gcc/diagnostic.c:839 #1 0x00c462f4 in fancy_abort (file=optimized out, line=560, function=0xcf3913 gsi_for_stmt) at ../../gcc-svn/trunk/gcc/diagnostic.c:899 #2 0x0074885c in gsi_for_stmt (stmt=0x714724b0) at ../../gcc-svn/trunk/gcc/gimple-iterator.c:560 #3 0x00a62372 in vect_schedule_slp_instance (node=0x13ad400, instance=0x13b71e0, vectorization_factor=optimized out) at ../../gcc-svn/trunk/gcc/tree-vect-slp.c:2888 #4 0x00a68fa9 in vect_schedule_slp (loop_vinfo=optimized out, bb_vinfo=optimized out) at ../../gcc-svn/trunk/gcc/tree-vect-slp.c:2970 #5 0x00a5bc24 in vect_transform_loop (loop_vinfo=0x13b97d0) at ../../gcc-svn/trunk/gcc/tree-vect-loop.c:5395 #6 0x00a69acb in vectorize_loops () at ../../gcc-svn/trunk/gcc/tree-vectorizer.c:214 #7 0x0081f8a7 in execute_one_pass (pass=0x10dad40) at ../../gcc-svn/trunk/gcc/passes.c:2080 (gdb) f 2 #2 0x0074885c in gsi_for_stmt (stmt=0x714724b0) at ../../gcc-svn/trunk/gcc/gimple-iterator.c:560 560 gcc_unreachable (); (gdb) p debug_gimple_stmt (stmt) VIEW_CONVERT_EXPRunnamed-unsigned:8(MEM[(logical(kind=1)[0:] *)D.900_81][D.987_168]) = patt.40_106; $3 = void
[Bug c++/51680] g++ 4.7 fails to inline trivial template stuff
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51680 --- Comment #2 from miles at gnu dot org 2011-12-27 13:54:38 UTC --- Hmm, I dunno, my impression is that people expect that template'd code is, in general more inlined -- templates are often used kind of as macro replacement in C++ -- especially for very trivial cases like this one...
[Bug libgcj/49193] __sync_xxxx builtins aren't used in sysdep/*/locks.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49193 --- Comment #3 from uros at gcc dot gnu.org 2011-12-27 09:40:27 UTC --- Author: uros Date: Tue Dec 27 09:40:23 2011 New Revision: 182692 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182692 Log: PR libgcj/49193 * sysdep/alpha/locks.h (compare_and_swap): Call __sync_bool_compare_and_swap. (release_set): Call __sync_synchronize. Modified: trunk/libjava/ChangeLog trunk/libjava/sysdep/alpha/locks.h
[Bug tree-optimization/51683] [4.7 Regression] __builtin_memcpy etc. with constant first argument optimized away by ccp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51683 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-12-27 Target Milestone|--- |4.7.0 Ever Confirmed|0 |1
[Bug plugins/51686] New: make install-strip-gcc didn't install liblto-plugin* files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51686 Bug #: 51686 Summary: make install-strip-gcc didn't install liblto-plugin* files Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: plugins AssignedTo: unassig...@gcc.gnu.org ReportedBy: norb...@yahoo.com In gcc-4.6.2, the top-level Makefile.in line 60018 is: install-gcc: maybe-install-lto-plugin That's fine, but there's no corresponding line for stripped install: install-strip-gcc: maybe-install-strip-lto-plugin Without that line, my make install-strip-gcc attempt did not install the three liblto-plugin* files. My host Windows/MinGW/MSYS, target microblaze-xilinx-elf.
[Bug c/51687] New: gcc is killed when compiling med-3.0.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51687 Bug #: 51687 Summary: gcc is killed when compiling med-3.0.4 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: thie...@freebsd.org Created attachment 26189 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26189 Preprocessed file of med-3.0.4/src/ci/MEDmeshGridStructRd.c When compiling the latest version of MED (3.0.4), a tool of Code_Aster ( http://www.code-aster.org/V2/spip.php?article275 ), it fails: /bin/sh ../../libtool --tag=CC --mode=compile gcc47 -std=gnu99 -DHAVE_CONFIG_H -I. -I. -I../../include -I../../include -DH5_USE_16_API -I/usr/local/include -save-temps -O2 -pipe -march=pentiumpro -Wl,-rpath=/usr/local/lib/gcc47 -fno-strict-aliasing -MT MEDmeshGridStructRd.lo -MD -MP -MF .deps/MEDmeshGridStructRd.Tpo -c -o MEDmeshGridStructRd.lo MEDmeshGridStructRd.c libtool: compile: gcc47 -std=gnu99 -DHAVE_CONFIG_H -I. -I. -I../../include -I../../include -DH5_USE_16_API -I/usr/local/include -save-temps -O2 -pipe -march=pentiumpro -Wl,-rpath=/usr/local/lib/gcc47 -fno-strict-aliasing -MT MEDmeshGridStructRd.lo -MD -MP -MF .deps/MEDmeshGridStructRd.Tpo -c MEDmeshGridStructRd.c -fPIC -DPIC -o .libs/MEDmeshGridStructRd.o gcc47: warning: -pipe ignored because -save-temps specified Killed gmake[2]: *** [MEDmeshGridStructRd.lo] Erreur 1 gmake[2] : on quitte le répertoire « /usr/ports/french/med/work/med-3.0.4/src/ci » gmake[1]: *** [all-recursive] Erreur 1 Tested with: gcc47 (FreeBSD Ports Collection) 4.7.0 20111210 (experimental) but the same error occurs with previous version gcc 4.6 and gcc 4.4. Attached is the pre-processed file MEDmeshGridStructRd.i.
[Bug plugins/51686] make install-strip-gcc didn't install liblto-plugin* files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51686
--- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2011-12-27
18:04:41 UTC ---
Easy fix:
pinskia@server:~/src/local/gcc$ svn diff Makefile.def
Index: Makefile.def
===
--- Makefile.def(revision 182635)
+++ Makefile.def(working copy)
@@ -314,6 +314,7 @@
dependencies = { module=install-gcc ; on=install-fixincludes; };
dependencies = { module=install-gcc ; on=install-lto-plugin; };
dependencies = { module=install-strip-gcc ; on=install-strip-fixincludes; };
+dependencies = { module=install-strip-gcc ; on=install-strip-lto-plugin; };
dependencies = { module=configure-libcpp; on=configure-libiberty; hard=true;
};
dependencies = { module=configure-libcpp; on=configure-intl; };
--- CUT ---
And then regenerate Makefile.in.
[Bug rtl-optimization/51069] [4.7 Regression] ICE in verify_loop_structure, at cfgloop.c:1559
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51069 --- Comment #5 from Jan Hubicka hubicka at gcc dot gnu.org 2011-12-27 18:32:05 UTC --- note that remove_path may affect presence of irreducible loops and it already has logic to update the flags. It seems to be case that gets missed. I am trying to make sense of it now.
[Bug rtl-optimization/51069] [4.7 Regression] ICE in verify_loop_structure, at cfgloop.c:1559
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51069
--- Comment #6 from Jan Hubicka hubicka at gcc dot gnu.org 2011-12-27
18:50:14 UTC ---
OK,
the problem is that by removing conditional entrance into irreducible region,
the BB becomes part of the region itself.
I am testing the following patch
Index: cfgloopmanip.c
===
--- cfgloopmanip.c (revision 182692)
+++ cfgloopmanip.c (working copy)
@@ -290,6 +290,7 @@ remove_path (edge e)
int i, nrem, n_bord_bbs;
sbitmap seen;
bool irred_invalidated = false;
+ edge_iterator ei;
if (!can_remove_branch_p (e))
return false;
@@ -329,9 +330,12 @@ remove_path (edge e)
/* Find border hexes -- i.e. those with predecessor in removed path. */
for (i = 0; i nrem; i++)
SET_BIT (seen, rem_bbs[i]-index);
+ FOR_EACH_EDGE (ae, ei, e-src-succs)
+if (ae != e ae-dest != EXIT_BLOCK_PTR !TEST_BIT (seen,
ae-dest-index)
+ae-flags EDGE_IRREDUCIBLE_LOOP)
+ irred_invalidated = true;
for (i = 0; i nrem; i++)
{
- edge_iterator ei;
bb = rem_bbs[i];
FOR_EACH_EDGE (ae, ei, rem_bbs[i]-succs)
if (ae-dest != EXIT_BLOCK_PTR !TEST_BIT (seen, ae-dest-index))
[Bug c++/51547] auto, type deduction, reference collapsing and const: invalid initialization of reference of type 'const X' from expression of type 'const X'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51547 --- Comment #2 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2011-12-27 19:04:28 UTC --- Author: paolo Date: Tue Dec 27 19:04:24 2011 New Revision: 182695 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182695 Log: 2011-12-27 Paolo Carlini paolo.carl...@oracle.com PR c++/51547 * g++.dg/cpp0x/pr51547.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/pr51547.C
[Bug c++/51547] auto, type deduction, reference collapsing and const: invalid initialization of reference of type 'const X' from expression of type 'const X'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51547 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2011-12-27 19:07:23 UTC --- Testcase added, I'm closing the PR as fixed for 4.7.0.
[Bug c++/51680] g++ 4.7 fails to inline trivial template stuff
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51680 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2011-12-27 19:14:54 UTC --- This changed with http://gcc.gnu.org/viewcvs?root=gccview=revrev=172609
[Bug c++/51669] ICE verify-gimple with openmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51669 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-12-27 20:18:07 UTC --- Created attachment 26190 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26190 Reduced
[Bug c++/51669] ICE verify-gimple with openmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51669 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-12-27 Ever Confirmed|0 |1
[Bug other/51688] New: libgcc dll is installed in sysroot/lib instead of sysroot/bin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51688 Bug #: 51688 Summary: libgcc dll is installed in sysroot/lib instead of sysroot/bin Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: vanboxem.ru...@gmail.com GCC configured like this: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=m:/development/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/4.7.0/lto-wrapper.exe Target: x86_64-w64-mingw32 Configured with: /home/ruben/mingw-w64/toolchain/src/gcc/configure --host=x86_64-w64-mingw32 --build=x86_64-linux-gnu --target=x86_64-w64-mingw32 --with-sysroot=/home/ruben/mingw-w64/toolchain/mingw64mingw64/mingw64 --prefix=/home/ruben/mingw-w64/toolchain/mingw64mingw64/mingw64 --with-libiconv-prefix=/home/ruben/mingw-w64/toolchain/mingw64mingw64/prereq_install --with-gmp=/home/ruben/mingw-w64/toolchain/mingw64mingw64/prereq_install --with-mpfr=/home/ruben/mingw-w64/toolchain/mingw64mingw64/prereq_install --with-mpc=/home/ruben/mingw-w64/toolchain/mingw64mingw64/prereq_install --with-ppl=/home/ruben/mingw-w64/toolchain/mingw64mingw64/prereq_install --with-cloog=/home/ruben/mingw-w64/toolchain/mingw64mingw64/prereq_install --enable-cloog-backend=isl --with-host-libstdcxx='-static -lstdc++ -lm -lgcc_eh' --enable-shared --enable-static --enable-threads=posix --disable-multilib --enable-languages=c,lto,c++,objc,obj-c++,java --enable-libgomp --enable-sjlj-exceptions --enable-fully-dynamic-string --disable-nls --disable-werror --enable-checking=release --disable-win32-registry --disable-rpath --disable-werror CFLAGS='-O2 -mtune=core2 -fomit-frame-pointer -momit-leaf-frame-pointer -fgraphite-identity -floop-interchange -floop-block -floop-parallelize-all' LDFLAGS= Thread model: posix gcc version 4.7.0 20111226 (experimental) (GCC) puts libgcc_s_sjlj-1.dll in /home/ruben/mingw-w64/toolchain/mingw64mingw64/mingw64/lib, instead of the previous (GCC 4.5/4.6) /home/ruben/mingw-w64/toolchain/mingw64mingw64/mingw64/bin, where it belongs. This is with a native 64-bit windows compiler, built from Linux.
[Bug tree-optimization/42382] _Bool foo = bar; vs _Bool foo = foo bar; vs _Bool foo = foo bar; emitted code different
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42382 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2011-12-27 20:40:47 UTC --- Fixed in 4.7.0: bb 2: D.2697_1 = rand (); foo_2 = D.2697_1 != 0; D.2698_3 = rand (); bar_4 = D.2698_3 != 0; D.2711_30 = bar_4 foo_2; D.2700_9 = (int) bar_4; D.2699_10 = (int) D.2711_30; printf (%u %u\n, D.2699_10, D.2700_9); D.2702_11 = rand (); foo_12 = D.2702_11 != 0; D.2703_13 = rand (); bar_14 = D.2703_13 != 0; D.2712_7 = bar_14 foo_12; D.2700_19 = (int) bar_14; D.2699_20 = (int) D.2712_7; printf (%u %u\n, D.2699_20, D.2700_19); D.2704_21 = rand (); foo_22 = D.2704_21 != 0; D.2705_23 = rand (); bar_24 = D.2705_23 != 0; D.2706_25 = bar_24 foo_22; D.2700_28 = (int) bar_24; D.2699_29 = (int) D.2706_25; printf (%u %u\n, D.2699_29, D.2700_28);
[Bug target/51244] SH Target: Inefficient conditional branch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244
--- Comment #2 from Oleg Endo oleg.e...@t-online.de 2011-12-27 21:26:33 UTC
---
(In reply to comment #1)
BTW, OT, (a != b || a != c) ? b : c could be reduced to b, I think.
Yes, very much so.
It is reduced to return b for -m2, -m2e, -m2a, -m3, -m3e
but not for -m1 and -m4*.
The correct test function should be rather:
int test_func_0_NG (int a, int b, int c, int d)
{
return (a != b || a != d) ? b : c;
}
which is actually OK for all variants except -m1 and -m4*:
cmp/eqr5,r4! 11cmpeqsi_t/3[length = 2]
bf.s.L6! 12branch_false[length = 2]
cmp/eqr7,r5! 14cmpeqsi_t/3[length = 2]
bf.L6! 15branch_false[length = 2]
movr6,r5! 8movsi_i/2[length = 2]
.L6:
rts! 42*return_i[length = 2]
movr5,r0! 23movsi_i/2[length = 2]
[Bug c++/51689] New: GCC apparently is inconsistent with warning about invalid brace-elision use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51689
Bug #: 51689
Summary: GCC apparently is inconsistent with warning about
invalid brace-elision use
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: schaub.johan...@googlemail.com
GCC gives a warning about
std::arrayint, 2{1, 2}
But it gives an error about
struct A {
A():a{1, 2} { }
std::{arrayint, 2 a;
};
I would expect consistent handling of the two cases.
[Bug c++/51669] ICE verify-gimple with openmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51669
--- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2011-12-27
22:18:06 UTC ---
This is enough, really simple:
int omp_get_max_threads();
templatetypename _Tp const _Tp min(const _Tp, const _Tp);
void s451_()
{
int i;
#pragma omp parallel for num_threads(min(4, omp_get_max_threads()))
for (i = 1; i 33; ++i)
;
}
[Bug target/51244] SH Target: Inefficient conditional branch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244
--- Comment #3 from Oleg Endo oleg.e...@t-online.de 2011-12-27 22:43:11 UTC
---
Created attachment 26191
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26191
Proposed patch to improve some of the issues.
(In reply to comment #1)
[...]
mov #-1,rn
negc rn,rm
tst #255,rm
which is essentially T_reg = T_reg. Usually combine catches such
situation, but negc might be too complex for combine.
For this case, replacing current movnegt expander by insn, splitter
and peephole something like
[...]
the above useless sequence could be removed, though we will miss
the chance that the -1 can be CSE-ed when the cstore value is
used. This will cause a bit worse code for the loop like
int
foo (int *a, int x, int n)
{
int i;
int count;
for (i = 0; i n; i++)
count += (*(a + i) != x);
return count;
}
Thanks for your ideas and comments. It was really useful.
The attached patch removes the useless sequence and still allows the -1
constant to be CSE-ed for such cases as the example function above.
I haven't ran all tests on it yet, but CSiBE shows average code size reduction
of approx. -0.1% for -m4* with some code size increases in some files.
Would something like that be OK for stage 3?
[Bug target/51244] SH Target: Inefficient conditional branch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244
--- Comment #4 from Oleg Endo oleg.e...@t-online.de 2011-12-27 23:17:03 UTC
---
(In reply to comment #1)
return a = 0 b = 0 ? c : d;
x = 0 is expanded to the sequence like
ra = not x
rb = -31
rc = ra (neg rb)
T = (rc == 0)
conditional jump
and combine tries to simplify it. combine simplifies b = 0
successfully into shll and bt but fails to simplify a = 0.
It seems that combine doesn't do constant propagation well and
misses the constant -31.
Another simpler fail:
int test_func_22_NG (int a, int b, int c, int d)
{
return a = 0;
}
becomes:
not r4,r0 ! 9one_cmplsi2[length = 2]
mov #-31,r1 ! 12movsi_ie/3[length = 2]
rts ! 31*return_i[length = 2]
shldr1,r0 ! 13lshrsi3_d[length = 2]
which could be:
cmp/pzr4
rts
movtr0
From what I could observe, this is caused by the various shift insns which
leads combine to this result. For example, the shll, branch sequence that
is used instead of cmp/pz, branch is caused by the ashlsi_c insn, which
defines a lt:SI comparison. Although that is correct, using cmp/pz could
be better, since it does not modify the reg, and on SH4 it is an MT group
insn. The ashlsi_c insn / lt:SI picking can be avoided by adjusting the
rtx costs, for instance (just tried it out briefly).
I think a peephole in this case could fix some of the symptoms but not the
actual cause. I'll see if I can come up with something that works without a
peephole, even though all the shift stuff looks a bit suspicious ;)
[Bug c++/51680] g++ 4.7 fails to inline trivial template stuff
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51680 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2011-12-28 00:42:16 UTC --- (In reply to comment #3) To be honest, this kind of expectation is completely new to me. Me too. Templates are about genericity, not inlining.
[Bug c++/51680] g++ 4.7 fails to inline trivial template stuff
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51680
--- Comment #6 from miles at gnu dot org 2011-12-28 01:04:05 UTC ---
Well, it's just an impression ... :]
I think one reason is that unlike normal functions, template functions are
implicitly sort of local (by necessity), in that they can have a definition
in many compilation units without causing a link conflict. To get this effect
for normal functions, one must use the static or inline keywords -- so the
impression (rightly or wrongly) is that template functions definitions are like
one of those.
... and of course if a [normal] function definition has static or inline
attached, gcc does do inlining differently. As I mentioned in my original
report, gcc 4.6, seems to treat template functions this way w/r/t inlining, as
if they were static.[*]
On another note, I'd kinda expect gcc these days to be making pretty reasonable
decisions about inlining even without hints; that's why I'm surprised at
behavior of my example, where the functions involved are so trivial that
inlining seems almost always a good bet...
[*] For instance, here's a normal function version of my example: extern
void process (float);
void process_fun_at (float (fun)(float), float x)
{
process (fun (x));
}
static float add1 (float x)
{
return x + 1;
}
void test (float i)
{
process_fun_at (add1, i);
}
gcc 4.6 will compile this differently if process_fun_at is declared static;
if it's static, everything gets inlined, otherwise, nothing is inlined. gcc
4.6 completely inlines the original template example with no special
declaration for the process_fun_at template function, meaning it's being
treated kind of like it's static for inlining purposes.
gcc 4.7 compiles the normal-function example the same as gcc 4.6 for both
static and non-static cases, but _doesn't_ inline the template version by
default. So if nothing else, this is a change in behavior from gcc 4.6;
whether it's good or bad I dunno.
[and yeah, I know inlining heuristics are a big ball of hair that nobody wants
to mess with if they can help it sorry :]
Thanks,
-miles
[Bug target/51244] SH Target: Inefficient conditional branch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244 --- Comment #5 from Oleg Endo oleg.e...@t-online.de 2011-12-28 02:44:05 UTC --- (In reply to comment #2) (In reply to comment #1) BTW, OT, (a != b || a != c) ? b : c could be reduced to b, I think. Yes, very much so. It is reduced to return b for -m2, -m2e, -m2a, -m3, -m3e but not for -m1 and -m4*. This seems to be due to the following in sh.h: #define BRANCH_COST(speed_p, predictable_p) \ (TARGET_SH5 ? 1 : ! TARGET_SH2 || TARGET_HARD_SH4 ? 2 : 1)
[Bug ada/51690] New: Ada.Finalization with pointer field without explicit initialization confuses compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51690 Bug #: 51690 Summary: Ada.Finalization with pointer field without explicit initialization confuses compiler Classification: Unclassified Product: gcc Version: 4.5.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassig...@gcc.gnu.org ReportedBy: gary...@comcast.net Created attachment 26192 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26192 26 line source file, self contained except for Ada.Text_Io which can be eliminated. Ada.Finalization plus access type fields that are not explicitly initialized in the type declaration cause the compiler to complain that it has not seen the body of its own internally generated support routines. gcc -c -gnata -gnatE -fstack-check -gnatef -gnatf -gnatm50 -gnatn -gnato -gnatwe -gnatwi -gnatwj -gnatwK -gnatwl -Wuninitialized -gnatVa -pass-exit-codes -O -g -I- -gnatA /home/geb/foo.gnat.bug3/pb_code_main.adb /home/geb/foo.gnat.bug3/pb_code_main.adb:10:05: warning: cannot call F207b before body seen /home/geb/foo.gnat.bug3/pb_code_main.adb:10:05: warning: Program_Error will be raised at run time gnatmake: /home/geb/foo.gnat.bug3/pb_code_main.adb compilation error The number in F207b varies greatly as one works towards a cut down example. The b in F207b is sometimes an s. But this is always the form of the complaint. The attached file is about as minimal as I've been able to make it, 26 lines. Compile it with the options above. Eliminate any type, an field, or change the access type to something that is not an access type, and the problem goes away. There is a workaround. Explicitly initialize the access type field to := null;. In a real program this means explicitly initializing all access type fields to null but it seems to get the job done.
Re: [Patch] Adjust diag-scans in vect-tests to fix fails on AVX/AVX2
The patch at http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01600/vec-tests-avx2_fixes-7.patch fixes the XPASS, tested on powerpc-apple-darwin9 and x86_64-apple-darwin10. Thanks, Dominique
[PATCH, alpha]: Use __sync* functions in libjava locks.h
Hello!
No functional change.
2011-12-27 Uros Bizjak ubiz...@gmail.com
PR libgcj/49193
* sysdep/alpha/locks.h (compare_and_swap): Call
__sync_bool_compare_and_swap.
(release_set): Call __sync_synchronize.
Tested on alphaeev68-pc-linux-gnu, committed to mainline SVN.
Uros.
Index: sysdep/alpha/locks.h
===
--- sysdep/alpha/locks.h(revision 182691)
+++ sysdep/alpha/locks.h(working copy)
@@ -1,6 +1,6 @@
// locks.h - Thread synchronization primitives. Alpha implementation.
-/* Copyright (C) 2002 Free Software Foundation
+/* Copyright (C) 2002, 2011 Free Software Foundation
This file is part of libgcj.
@@ -11,41 +11,38 @@
#ifndef __SYSDEP_LOCKS_H__
#define __SYSDEP_LOCKS_H__
-typedef size_t obj_addr_t; /* Integer type big enough for object */
- /* address. */
+/* Integer type big enough for object address. */
+typedef size_t obj_addr_t;
+// Atomically replace *addr by new_val if it was initially equal to old.
+// Return true if the comparison succeeded.
+// Assumed to have acquire semantics, i.e. later memory operations
+// cannot execute before the compare_and_swap finishes.
inline static bool
compare_and_swap(volatile obj_addr_t *addr,
- obj_addr_t old,
- obj_addr_t new_val)
+obj_addr_t old,
+obj_addr_t new_val)
{
- unsigned long oldval;
- char result;
- __asm__ __volatile__(
- 1:ldq_l %0, %1\n\t \
- cmpeq %0, %5, %2\n\t \
- beq %2, 2f\n\t \
- mov %3, %0\n\t \
- stq_c %0, %1\n\t \
- bne %0, 2f\n\t \
- br 1b\n\t \
- 2:mb
- : =r(oldval), =m(*addr), =r(result)
- : r (new_val), m(*addr), r(old) : memory);
- return (bool) result;
+ return __sync_bool_compare_and_swap(addr, old, new_val);
}
+// Set *addr to new_val with release semantics, i.e. making sure
+// that prior loads and stores complete before this
+// assignment.
inline static void
release_set(volatile obj_addr_t *addr, obj_addr_t new_val)
{
- __asm__ __volatile__(mb : : : memory);
+ __sync_synchronize();
*(addr) = new_val;
}
+// Compare_and_swap with release semantics instead of acquire semantics.
+// On many architecture, the operation makes both guarantees, so the
+// implementation can be the same.
inline static bool
compare_and_swap_release(volatile obj_addr_t *addr,
-obj_addr_t old,
-obj_addr_t new_val)
+obj_addr_t old,
+obj_addr_t new_val)
{
return compare_and_swap(addr, old, new_val);
}
PR middle-end/48641 (tree-ssa-threadupdate messing up profile)
Hi
this patch solves problem with negative frequency that is result of overflow
in profile updating code. The testcase shows quite pathological case where
profile is misguessed and the mistake is propagated across the CFG by jump
threading. I can't of think of much better solution than adding a capping
to that code. It should not have bad effect, since frequency will be hot anyway.
Bootstrapped/regtested x86_64-linux, comitted.
Honza
Index: ChangeLog
===
*** ChangeLog (revision 182685)
--- ChangeLog (working copy)
***
*** 1,3
--- 1,8
+ 2011-12-25 Jan Hubicka j...@suse.cz
+
+ PR middle-end/48641
+ * tree-ssa-threadupdate.c (redirect_edges): Watch for overflow.
+
2011-12-23 Richard Henderson r...@redhat.com
* tree.def (VEC_EXTRACT_EVEN_EXPR, VEC_EXTRACT_ODD_EXPR): Remove.
Index: tree-ssa-threadupdate.c
===
*** tree-ssa-threadupdate.c (revision 182676)
--- tree-ssa-threadupdate.c (working copy)
*** redirect_edges (void **slot, void *data)
*** 513,519
e-src-index, e-dest-index, rd-dup_block-index);
rd-dup_block-count += e-count;
! rd-dup_block-frequency += EDGE_FREQUENCY (e);
EDGE_SUCC (rd-dup_block, 0)-count += e-count;
/* Redirect the incoming edge to the appropriate duplicate
block. */
--- 513,523
e-src-index, e-dest-index, rd-dup_block-index);
rd-dup_block-count += e-count;
!
! /* Excessive jump threading may make frequencies large enough so
!the computation overflows. */
! if (rd-dup_block-frequency BB_FREQ_MAX * 2)
! rd-dup_block-frequency += EDGE_FREQUENCY (e);
EDGE_SUCC (rd-dup_block, 0)-count += e-count;
/* Redirect the incoming edge to the appropriate duplicate
block. */
Index: testsuite/gcc.c-torture/compile/pr48641.c
===
*** testsuite/gcc.c-torture/compile/pr48641.c (revision 0)
--- testsuite/gcc.c-torture/compile/pr48641.c (revision 0)
***
*** 0
--- 1,249
+ /* { dg-options -O -fno-tree-ccp -fno-tree-copy-prop } */
+ #define CSF __builtin_copysignf
+ #define CSD __builtin_copysign
+ #define CSL __builtin_copysignl
+ #define MODFF __builtin_modff
+ #define MODFD __builtin_modf
+ #define MODFL __builtin_modfl
+
+ extern void link_error (void);
+
+ void
+ foo (void)
+ {
+ float iptrf;
+ double iptr;
+ long double iptrl;
+ long long iptrll;
+ if ((CSF (1.0F, MODFF (0x1p10F + 0.5f, iptrf)) != CSF (1.0F, 0.5f))
+ || (CSF (1.0F, iptrf) != 0x1p10f))
+ link_error ();
+ if (MODFD (0x1p10F + 0.5, iptr) != 0.5
+ || (CSD (1.0, MODFD (0x1p10F + 0.5, iptr)) != CSD (1.0, 0.5))
+ || (CSD (1.0, iptr) != CSD (1.0, 0x1p10)))
+ link_error ();
+ if (MODFL (0x1p10F + 0.5l, iptrl) != 0.5l
+ || (CSL (1.0L, MODFL (0x1p10F + 0.5l, iptrl)) != CSL (1.0L, 0.5l))
+ || (CSL (1.0L, iptrl) != CSL (1.0L, 0x1p10l)))
+ link_error ();
+ if ((CSF (1.0F, (MODFF (0x1p10F + 0x1p-10f, iptrf)))
+!= CSF (1.0F, 0x1p-10f))
+ || (CSF (1.0F, iptrf) != CSF (1.0F, 0x1p10f)))
+ link_error ();
+ if (MODFD (0x1p10F + 0x1p-10, iptr) != 0x1p-10
+ || (CSD (1.0, (MODFD (0x1p10F + 0x1p-10, iptr)))
+ != CSD (1.0, 0x1p-10)) || (CSD (1.0, iptr) != CSD (1.0, 0x1p10)))
+ link_error ();
+ if (MODFL (0x1p10F + 0x1p-10l, iptrl) != 0x1p-10l
+ || (CSL (1.0L, (MODFL (0x1p10F + 0x1p-10l, iptrl)))
+ != CSL (1.0L, 0x1p-10l))
+ || (CSL (1.0L, iptrl) != CSL (1.0L, 0x1p10l)))
+ link_error ();
+ if ((CSF (1.0F, (MODFF (12345678L / 17.0f, iptrf)))
+!= CSF (1.0F, (-726216L + 12345678L / 17.0f)))
+ || (CSF (1.0F, iptrf) != CSF (1.0F, 726216.0f)))
+ link_error ();
+ if (MODFD (12345678L / 17.0, iptr) != -726216L + 12345678L / 17.0
+ || (CSD (1.0, (MODFD (12345678L / 17.0, iptr)))
+ != CSD (1.0, (-726216L + 12345678L / 17.0)))
+ || (CSD (1.0, iptr) != CSD (1.0, 726216.0)))
+ link_error ();
+ if ((CSL (1.0L, (MODFL (12345678L / 17.0l, iptrl)))
+!= CSL (1.0L, (-726216L + 12345678L / 17.0l)))
+ || (CSL (1.0L, iptrl) != CSL (1.0L, 726216.0l)))
+ link_error ();
+ if (MODFF (555.555f, iptrf) != -555 + 555.555f
+ || (CSF (1.0F, iptrf) != CSF (1.0F, 555.0f)))
+ link_error ();
+ if (MODFD (555.555, iptr) != -555 + 555.555
+ || (CSD (1.0, (MODFD (555.555, iptr))) != CSD (1.0, (-555 + 555.555)))
+ || (CSD (1.0, iptr) != CSD (1.0, 555.0)))
+ link_error ();
+ if (MODFL (555.555l, iptrl) != -555 + 555.555l
+ || (CSL (1.0L, (MODFL (555.555l, iptrl)))
+ != CSL (1.0L, (-555 + 555.555l)))
+ || (CSL (1.0L, iptrl) != CSL (1.0L, 555.0l)))
+ link_error ();
+ if (MODFF
Fix PR rtl-optimization/51667
This fixes an oversight we made when turning the original ZEE pass into the
more general REE pass. In the former, all extensions considered were of the
same kind (zero-extension from SImode to DImode) whereas, in the latter, they
can be of any kind. The code was implicitly relying on the former property.
The patch makes is so that each definition insn is associated with only one
kind of extension; this is obviously quite conservative, but still strictly
more powerful than the original pass. In the process, several convoluted
implementation patterns are replaced with more straightforward ones.
Bootstrapped/regtested on x86_64-suse-linux, applied on the mainline.
2011-12-27 Eric Botcazou ebotca...@adacore.com
PR rtl-optimization/51667
* ree.c (insn_merge_code): Delete.
(is_insn_merge_attempted): Likewise.
(get_insn_status): Likewise.
(set_insn_status): Likewise.
(struct ext_cand): Add CODE and MODE fields.
(combine_set_extend): Rename to...
(combine_set_extension): ...this. Use above fields and tidy up.
(transform_ifelse): Likewise.
(get_defs): Return the chain of definitions.
(is_this_a_cmove): Merge into...
(is_cond_copy_insn): ...this. Return bool.
(make_defs_and_copies_lists): Adjust calls to get_defs and simplify.
(merge_def_and_ext): Adjust call to combine_set_extend.
(combine_reaching_defs): Remove calls to {g|s}et_insn_status.
(struct extend_info): Rename to...
(struct re_info): ...this. Add DEF_MAP field.
(add_ext_candidate): Merge into...
(add_removable_extension): ...this. Adjust calls to get_defs. Ensure
reaching definitions are associated with only one kind of extension.
(find_removable_extensions): Create and destroy the definition map.
(find_and_remove_re): Return void. Change 'long' variables to 'int'.
Do not deal with is_insn_merge_attempted.
2011-12-27 Eric Botcazou ebotca...@adacore.com
* gcc.c-torture/execute/20111227-1.c: New test.
--
Eric Botcazou
--
Eric Botcazou
Index: ree.c
===
--- ree.c (revision 182676)
+++ ree.c (working copy)
@@ -1,9 +1,9 @@
/* Redundant Extension Elimination pass for the GNU compiler.
- Copyright (C) 2010-2011 Free Software Foundation, Inc.
- Contributed by Ilya Enkovich (ilya.enkov...@intel.com)
+ Copyright (C) 2010, 2011 Free Software Foundation, Inc.
+ Contributed by Ilya Enkovich (ilya.enkov...@intel.com)
- Based on the Redundant Zero-extension elimination pass contributed by
- Sriraman Tallam (tmsri...@google.com) and Silvius Rus (r...@google.com).
+ Based on the Redundant Zero-extension elimination pass contributed by
+ Sriraman Tallam (tmsri...@google.com) and Silvius Rus (r...@google.com).
This file is part of GCC.
@@ -71,11 +71,11 @@ along with GCC; see the file COPYING3.
extension differ from the other instructions. For instance, the
instruction *cmov ebx, eax*
zero-extends eax onto rax only when the move from ebx to eax happens.
- Otherwise, eax may not be zero-extended. Consider conditional move as
+ Otherwise, eax may not be zero-extended. Consider conditional moves as
RTL instructions of the form
(set (reg:SI x) (if_then_else (cond) (reg:SI y) (reg:SI z))).
This pass tries to merge an extension with a conditional move by
- actually merging the defintions of y and z with an extension and then
+ actually merging the definitions of y and z with an extension and then
converting the conditional move into :
(set (reg:DI x) (if_then_else (cond) (reg:DI y) (reg:DI z))).
Since registers y and z are extended, register x will also be extended
@@ -105,13 +105,13 @@ along with GCC; see the file COPYING3.
400315: b8 4e 00 00 00 mov$0x4e,%eax
40031a: 0f af f8imul %eax,%edi
- 40031d: 89 ff mov%edi,%edi -- Useless extend
+ 40031d: 89 ff mov%edi,%edi - useless extension
40031f: 8b 04 bd 60 19 40 00mov0x401960(,%rdi,4),%eax
400326: c3 retq
..
400330: ba 2d 00 00 00 mov$0x2d,%edx
400335: 0f af faimul %edx,%edi
- 400338: 89 ff mov%edi,%edi -- Useless extend
+ 400338: 89 ff mov%edi,%edi - useless extension
40033a: 8b 04 bd 60 19 40 00mov0x401960(,%rdi,4),%eax
400341: c3 retq
@@ -149,7 +149,7 @@ along with GCC; see the file COPYING3.
400365: 29 f0 sub%esi,%eax
400367: 83 ff 65cmp$0x65,%edi
40036a: 0f 43 c2cmovae %edx,%eax
- 40036d: 89 c0
Re: [patch] Flag-controlled type conversions/promotions
-freal-4-real-8 is not equivalent to -fdefault-real-8 and -fdefault-double-8.
-freal-4-real-8 interprets any 4-byte real type, whether it is a
default real type or explicitly declared as 4-byte, as a 8-byte double
precision type, and that applies to all variables, functions and
constants.
-fdefault-real-8 will promote only default real type to double
precision and only variables and functions. Since constants are
usually declared explicitly as 4-byte, e.g. 1.01223e0 is an explicitly
defined 4-byte constant in gfortran, they will not be promoted.
I agree with the above and I think this should go into the manual. One
thing which can be done with -fdefault-real-8, but not with
-freal-4-real-8 is to work around some pitfalls of these otions by
specifying explicit kinds when needed (this probably explains why less
tests fail with the former option than with the later, see results at the
end of this mail).
In my opinion, these options, while useful, have several pitfalls:
(1) call to external procedures (especially in libraries),
(2) alignements in EQUIVALENCE and/or COMMON,
(3) generic interfaces,
(4) BOZ,
(5) I/Os,
(6) ...
I wonder if they should not have their own page in the manual with a big
warning at the beginning telling the user that these options are likely to
break legacy codes.
The raw test results are the following
make -k check-gfortran
RUNTESTFLAGS=--target_board=unix'{-m32/-finteger-4-integer-8,
-m64/-finteger-4-integer-8,-m32/-freal-4-real-8,-m64/-freal-4-real-8,-m32/-freal-8-real-10,-m64/-freal-8-real-10}'
=== gfortran Summary for unix/-m32/-finteger-4-integer-8 ===
# of expected passes37336
# of unexpected failures896
# of expected failures 39
# of unresolved testcases 1
# of unsupported tests 570
=== gfortran Summary for unix/-m64/-finteger-4-integer-8 ===
# of expected passes37728
# of unexpected failures840
# of expected failures 39
# of unsupported tests 409
=== gfortran Summary for unix/-m32/-freal-4-real-8 ===
# of expected passes37526
# of unexpected failures702
# of expected failures 39
# of unsupported tests 570
=== gfortran Summary for unix/-m64/-freal-4-real-8 ===
# of expected passes37857
# of unexpected failures698
# of expected failures 39
# of unsupported tests 409
=== gfortran Summary for unix/-m32/-freal-8-real-10 ===
# of expected passes37928
# of unexpected failures394
# of expected failures 39
# of untested testcases 8
# of unsupported tests 570
=== gfortran Summary for unix/-m64/-freal-8-real-10 ===
# of expected passes38300
# of unexpected failures357
# of expected failures 39
# of untested testcases 8
# of unsupported tests 409
=== gfortran Summary ===
# of expected passes226675
# of unexpected failures3887
# of expected failures 234
# of unresolved testcases 1
# of untested testcases 16
# of unsupported tests 2937
to be compared with
make -k check-gfortran
RUNTESTFLAGS=--target_board=unix'{-m32/-fdefault-integer-8,
-m64/-fdefault-integer-8,-m32/-fdefault-real-8,-m64/-fdefault-real-8}'
=== gfortran Summary for unix/-m32/-fdefault-integer-8 ===
# of expected passes37794
# of unexpected failures489
# of expected failures 39
# of unresolved testcases 24
# of unsupported tests 570
=== gfortran Summary for unix/-m64/-fdefault-integer-8 ===
# of expected passes38111
# of unexpected failures499
# of expected failures 39
# of unresolved testcases 24
# of unsupported tests 409
=== gfortran Summary for unix/-m32/-fdefault-real-8 ===
# of expected passes37705
# of unexpected failures539
# of expected failures 39
# of untested testcases 8
# of unsupported tests 570
=== gfortran Summary for unix/-m64/-fdefault-real-8 ===
# of expected passes38028
# of unexpected failures535
# of expected failures 39
# of untested testcases 8
# of unsupported tests 409
=== gfortran Summary ===
# of expected passes151638
# of unexpected failures2062
# of expected failures 156
# of unresolved testcases 48
# of untested testcases 16
# of unsupported tests 1958
I did not have the time to look in detail to the results. From a quick
glance I can tell that there are overlaps between the failures of
-fdefault-*-8 and -f*-4-*-8. In particular the ICEs with coarray appear
for both cases (I have open pr51682).
Dominique
Re: [patch] Flag-controlled type conversions/promotions
On Tue, Dec 27, 2011 at 6:52 AM, Dominique Dhumieres domi...@lps.ens.fr wrote: -freal-4-real-8 is not equivalent to -fdefault-real-8 and -fdefault-double-8. -freal-4-real-8 interprets any 4-byte real type, whether it is a default real type or explicitly declared as 4-byte, as a 8-byte double precision type, and that applies to all variables, functions and constants. -fdefault-real-8 will promote only default real type to double precision and only variables and functions. Since constants are usually declared explicitly as 4-byte, e.g. 1.01223e0 is an explicitly defined 4-byte constant in gfortran, they will not be promoted. I agree with the above and I think this should go into the manual. One thing which can be done with -fdefault-real-8, but not with -freal-4-real-8 is to work around some pitfalls of these otions by specifying explicit kinds when needed (this probably explains why less tests fail with the former option than with the later, see results at the end of this mail). That is correct. -fdefault-real-8 provides a finely tuned type promotion mechanism, while -freal-*-real-* overrides all type definitions via brute force. We actually like that: some of the codes we have date back to the 70's, we don't want to convert them into Fortran 95 and/or maintain several copies with different type definitions - this is just too expensive and time consuming. In such cases, we really do want to override all old-style definitions. In our work, this doesn't happen often, usually, we are running our code in double precision, but from time to time we would like to raise precision to pre-compute tables with more digits or to investigate ill-conditioning and numerical stability issues. In my opinion, these options, while useful, have several pitfalls: (1) call to external procedures (especially in libraries), (2) alignements in EQUIVALENCE and/or COMMON, (3) generic interfaces, (4) BOZ, (5) I/Os, (6) ... I wonder if they should not have their own page in the manual with a big warning at the beginning telling the user that these options are likely to break legacy codes. We do recompile all codes with the promotion flags to address this, usually, with only minor modifications. Things like calls to external C functions need to be fixed, although this is also needed if using -fdefault-* flags. Alignment could be also a problem, especially if promoting to quad precision which currently requires 128-bit variable aligment, again this also might also happen with -fdefault-* flags. The user has to be somewhat aware of this and adjust the code accordingly. We tend to ignore such issues in practice and proceed anyway with fingers crossed: everything works 90% of the time just fine! Zydrunas
Re: [patch] Flag-controlled type conversions/promotions
On Tue, Dec 27, 2011 at 12:52:19PM +0100, Dominique Dhumieres wrote: -freal-4-real-8 is not equivalent to -fdefault-real-8 and -fdefault-double-8. -freal-4-real-8 interprets any 4-byte real type, whether it is a default real type or explicitly declared as 4-byte, as a 8-byte double precision type, and that applies to all variables, functions and constants. -fdefault-real-8 will promote only default real type to double precision and only variables and functions. Since constants are usually declared explicitly as 4-byte, e.g. 1.01223e0 is an explicitly defined 4-byte constant in gfortran, they will not be promoted. I agree with the above and I think this should go into the manual. One thing which can be done with -fdefault-real-8, but not with -freal-4-real-8 is to work around some pitfalls of these otions by specifying explicit kinds when needed (this probably explains why less tests fail with the former option than with the later, see results at the end of this mail). AFAICT, the whole point of these options is to promote everything, so one doesn't need to remember, for example, if literal constants, which are declarated with kind suffixes, are promoted or not. I don't see that as a pitfall. If one is testing the stability or accuracy of an algorithm, then promoting 'x = 1._4 / 1._4' may be important. Consider program k real x x = 1._4 / 3._4 end program k gfc4x -c -fdump-tree-original -fdefault-real-8 k.f90 real(kind=8) x; x = 3.33432674407958984375e-1; gfc4x -c -fdump-tree-original -freal-4-real-8 k.f90 real(kind=8) x; x = 3.33314829616256247390992939472198486328125e-1; The difference is one heck of alot of ULPs. In my opinion, these options, while useful, have several pitfalls: (1) call to external procedures (especially in libraries), (2) alignements in EQUIVALENCE and/or COMMON, (3) generic interfaces, (4) BOZ, (5) I/Os, (6) ... One needs to worry about these things with the -fdefault-* options as well. In particular, anything that may depend on NUMERIC_STORAGE_SIZE will present a problem, because it is always set to 32 (except on a possibly pathological target without a 32-bit float type). I wonder if they should not have their own page in the manual with a big warning at the beginning telling the user that these options are likely to break legacy codes. These options as well as the -fdefault-* are likely to break any Fortran code. It is up to the user to test whether these options are suitable for his/her purpose. I'll update the manual with a sentence of the form: This option should be used with case and may not be suitable for codes. Inspection of the intermediate representation of the translated Fortran code, produced by the -fdump-tree-original option, is suggested. === gfortran Summary for unix/-m32/-finteger-4-integer-8 === # of expected passes 37336 # of unexpected failures 896 # of expected failures39 # of unresolved testcases 1 # of unsupported tests570 Well, I think you'll find a large number of these unexpected failures are due to hard coded assumptions about sizeof(INTEGER) etc. All of the failures I saw in gfortran.fortran-torture were of this variety. -- Steve
Re: [google] Patch to enable efficient function level instrumentation (issue 5416043)
Ok for google branches when tests are done. Update ChangeLog file properly. David On Tue, Dec 20, 2011 at 1:55 PM, Harshit Chopra hars...@google.com wrote: On Fri, Dec 16, 2011 at 3:10 PM, davi...@google.com wrote: Ok, Cary's explanation makes sense. Please update the comments to make it clearer. http://codereview.appspot.com/5416043/diff/1/gcc/config/i386/i386.c File gcc/config/i386/i386.c (right): http://codereview.appspot.com/5416043/diff/1/gcc/config/i386/i386.c#newcode10927 gcc/config/i386/i386.c:10927: + is later renamed to 'section_name' by ix86_elf_asm_named_section(). */ Probably better to change the comment to something like -- we emit a unique section name for the back pointer section. This is needed because otherwise the 'get_section' call may return an existing non-comdat section with the same name, leading to references from non-comdat section to comdat functions. Updated comment as suggested. http://codereview.appspot.com/5416043/
Re: [C++ Patch] for c++/23211
2011/12/21 Jason Merrill ja...@redhat.com:
This seems problematic to me; it could be that a dependent scope ends up
matching a non-dependent base in the end, i.e.
struct A { int x; };
template class T
struct B: A
{
using T::x;
};
BA b;
Very nice indeed, I hadn't thought of that.
this code is silly, but I think well-formed, and that your patch will break
it.
I think that just changing dependent_type_p (scope) to dependent_scope_p
(scope) will have the desired effect on this testcase.
Yes, it works. Tested x86_64-unknown-linux-gnu, OK to commit ?
gcc/testsuite/ChangeLog
2011-12-27 Fabien Chêne fab...@gcc.gnu.org
PR c++/23211
* g++.dg/template/using18.C: New.
* g++.dg/template/using19.C: New.
* g++.dg/template/nested3.C: Remove dg-message at instantiation.
* g++.dg/template/crash13.C: Likewise.
gcc/cp/ChangeLog
2011-12-27 Fabien Chêne fab...@gcc.gnu.org
PR c++/23211
* name-lookup.c (do_class_using_decl): Check that a non-dependent
nested-name-specifier of a class-scope using declaration refers to
a base, even if the current scope is dependent.
* parser.c (cp_parser_using_declaration): Set
USING_DECL_TYPENAME_P to 1 if the DECL is not null. Re-indent a
'else' close to the prior modification.
--
Fabien
23211.patch
Description: Binary data
Go patch committed: Tweak debug info
This patch to the gcc-specific part of the Go frontend tweaks the debug
info in a couple of ways.
For a named struct or array type, this uses build_distinct_type_copy
rather than build_variant_type_copy. Using build_variant_type_copy
caused trouble because it wound up causing the main variant to be named
while the copy was unnamed. The effect was to cause gcc to emit a
typedef defined as itself, which was not useful.
The middle-end currently expects all basic types to have a name. If
they don't, it uses the name __unknown__, which is not helpful (see
modified_type_die in dwarf2out.c). In Go all basic types will have a
name anyhow. This patch ensures that the first time we see a named
builtin basic type, we use that name rather than making a copy.
Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline.
Ian
2011-12-27 Ian Lance Taylor i...@google.com
* go-gcc.cc (Gcc_backend::set_placeholder_struct_type): Use
build_distinct_type_copy rather than build_variant_type_copy.
(Gcc_backend::set_placeholder_array_type): Likewise.
(Gcc_backend::named_type): Add special handling for builtin
basic types.
Index: go-gcc.cc
===
--- go-gcc.cc (revision 182696)
+++ go-gcc.cc (working copy)
@@ -663,7 +663,7 @@ Gcc_backend::set_placeholder_struct_type
Btype* r = this-fill_in_struct(placeholder, fields);
// Build the data structure gcc wants to see for a typedef.
- tree copy = build_variant_type_copy(t);
+ tree copy = build_distinct_type_copy(t);
TYPE_NAME(copy) = NULL_TREE;
DECL_ORIGINAL_TYPE(TYPE_NAME(t)) = copy;
@@ -696,7 +696,7 @@ Gcc_backend::set_placeholder_array_type(
Btype* r = this-fill_in_array(placeholder, element_btype, length);
// Build the data structure gcc wants to see for a typedef.
- tree copy = build_variant_type_copy(t);
+ tree copy = build_distinct_type_copy(t);
TYPE_NAME(copy) = NULL_TREE;
DECL_ORIGINAL_TYPE(TYPE_NAME(t)) = copy;
@@ -712,6 +712,24 @@ Gcc_backend::named_type(const std::strin
tree type = btype-get_tree();
if (type == error_mark_node)
return this-error_type();
+
+ // The middle-end expects a basic type to have a name. In Go every
+ // basic type will have a name. The first time we see a basic type,
+ // give it whatever Go name we have at this point.
+ if (TYPE_NAME(type) == NULL_TREE
+ location.gcc_location() == BUILTINS_LOCATION
+ (TREE_CODE(type) == INTEGER_TYPE
+ || TREE_CODE(type) == REAL_TYPE
+ || TREE_CODE(type) == COMPLEX_TYPE
+ || TREE_CODE(type) == BOOLEAN_TYPE))
+{
+ tree decl = build_decl(BUILTINS_LOCATION, TYPE_DECL,
+ get_identifier_from_string(name),
+ type);
+ TYPE_NAME(type) = decl;
+ return this-make_type(type);
+}
+
tree copy = build_variant_type_copy(type);
tree decl = build_decl(location.gcc_location(), TYPE_DECL,
get_identifier_from_string(name),
Go patch committed: No func, map or slice comparisons
The Go language was changed to prohibit comparing values of func, map,
or slice type, except for comparisons to nil. This patch implements
that in the Go frontend. The patch includes some testsuite updates.
Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline.
Ian
Index: gcc/go/gofrontend/expressions.h
===
--- gcc/go/gofrontend/expressions.h (revision 182696)
+++ gcc/go/gofrontend/expressions.h (working copy)
@@ -1147,9 +1147,9 @@ class Binary_expression : public Express
do_import(Import*);
// Report an error if OP can not be applied to TYPE. Return whether
- // it can.
+ // it can. OTYPE is the type of the other operand.
static bool
- check_operator_type(Operator op, Type* type, Location);
+ check_operator_type(Operator op, Type* type, Type* otype, Location);
protected:
int
Index: gcc/go/gofrontend/types.cc
===
--- gcc/go/gofrontend/types.cc (revision 182696)
+++ gcc/go/gofrontend/types.cc (working copy)
@@ -1235,8 +1235,6 @@ Type::type_functions(const char** hash_f
case Type::TYPE_FLOAT:
case Type::TYPE_COMPLEX:
case Type::TYPE_POINTER:
-case Type::TYPE_FUNCTION:
-case Type::TYPE_MAP:
case Type::TYPE_CHANNEL:
*hash_fn = __go_type_hash_identity;
*equal_fn = __go_type_equal_identity;
@@ -1249,6 +1247,8 @@ Type::type_functions(const char** hash_f
case Type::TYPE_STRUCT:
case Type::TYPE_ARRAY:
+case Type::TYPE_FUNCTION:
+case Type::TYPE_MAP:
// These types can not be hashed or compared.
*hash_fn = __go_type_hash_error;
*equal_fn = __go_type_equal_error;
@@ -4731,7 +4731,9 @@ bool
Map_type::do_verify()
{
if (this-key_type_-struct_type() != NULL
- || this-key_type_-array_type() != NULL)
+ || this-key_type_-array_type() != NULL
+ || this-key_type_-function_type() != NULL
+ || this-key_type_-map_type() != NULL)
{
error_at(this-location_, invalid map key type);
return false;
Index: gcc/go/gofrontend/expressions.cc
===
--- gcc/go/gofrontend/expressions.cc (revision 182696)
+++ gcc/go/gofrontend/expressions.cc (working copy)
@@ -6052,11 +6052,11 @@ Binary_expression::do_determine_type(con
}
// Report an error if the binary operator OP does not support TYPE.
-// Return whether the operation is OK. This should not be used for
-// shift.
+// OTYPE is the type of the other operand. Return whether the
+// operation is OK. This should not be used for shift.
bool
-Binary_expression::check_operator_type(Operator op, Type* type,
+Binary_expression::check_operator_type(Operator op, Type* type, Type* otype,
Location location)
{
switch (op)
@@ -6092,6 +6092,16 @@ Binary_expression::check_operator_type(O
or function type));
return false;
}
+ if ((type-is_slice_type()
+ || type-map_type() != NULL
+ || type-function_type() != NULL)
+ !otype-is_nil_type())
+ {
+ error_at(location,
+ (slice, map, and function types may only
+ be compared to nil));
+ return false;
+ }
break;
case OPERATOR_LT:
@@ -6189,8 +6199,10 @@ Binary_expression::do_check_types(Gogo*)
return;
}
if (!Binary_expression::check_operator_type(this-op_, left_type,
+ right_type,
this-location())
|| !Binary_expression::check_operator_type(this-op_, right_type,
+ left_type,
this-location()))
{
this-set_is_error();
@@ -6205,6 +6217,7 @@ Binary_expression::do_check_types(Gogo*)
return;
}
if (!Binary_expression::check_operator_type(this-op_, left_type,
+ right_type,
this-location()))
{
this-set_is_error();
Index: gcc/testsuite/go.test/test/closure.go
===
--- gcc/testsuite/go.test/test/closure.go (revision 182418)
+++ gcc/testsuite/go.test/test/closure.go (working copy)
@@ -76,7 +76,6 @@ func h() {
func newfunc() func(int) int { return func(x int) int { return x } }
-
func main() {
go f()
check([]int{1, 4, 5, 4})
@@ -90,10 +89,6 @@ func main() {
check([]int{100, 200, 101, 201, 500, 101, 201, 500})
x, y := newfunc(), newfunc()
- if x == y {
- println(newfunc returned same func)
- panic(fail)
- }
if x(1) != 1 || y(2) != 2 {
println(newfunc returned broken funcs)
panic(fail)
Index: gcc/testsuite/go.test/test/cmp1.go
===
--- gcc/testsuite/go.test/test/cmp1.go (revision 182418)
+++ gcc/testsuite/go.test/test/cmp1.go (working copy)
@@ -1,130 +0,0 @@
-// $G $D/$F.go $L $F.$A ./$A.out
-
-// Copyright 2009 The Go Authors. All rights reserved.
-// Use of this source code is governed by a BSD-style
-// license that can be found in the LICENSE file.
-
-package main
-
-import unsafe
-
Re: [C++ Patch] for c++/23211
2011/12/27 Jason Merrill ja...@redhat.com: On 12/27/2011 02:12 PM, Fabien Chêne wrote: - if (!scope_dependent_p) + if (!dependent_scope_p (scope)) I was thinking to change the line scope_dependent_p = dependent_type_p (scope); to use dependent_scope_p instead of dependent_type_p. OK, I have adjusted the patch. It passes regtest as well (on x86_64_unknown-linux-gnu). gcc/testsuite/ChangeLog 2011-12-27 Fabien Chêne fab...@gcc.gnu.org PR c++/23211 * g++.dg/template/using18.C: New. * g++.dg/template/using19.C: New. * g++.dg/template/nested3.C: Remove dg-message at instantiation. * g++.dg/template/crash13.C: Likewise. gcc/cp/ChangeLog 2011-12-27 Fabien Chêne fab...@gcc.gnu.org PR c++/23211 * name-lookup.c (do_class_using_decl): Use dependent_scope_p instead of dependent_type_p, to check that a non-dependent nested-name-specifier of a class-scope using declaration refers to a base, even if the current scope is dependent. * parser.c (cp_parser_using_declaration): Set USING_DECL_TYPENAME_P to 1 if the DECL is not null. Re-indent a 'else' close to the prior modification. -- Fabien pr23211.patch Description: Binary data
Re: [C++ Patch] for c++/23211
OK, thanks. Jason
Re: [patch testsuite g++.old-deja]: Fix some testcases for mingw targets
Ping 2011/12/15 Dave Korn dave.korn.cyg...@gmail.com: On 15/12/2011 17:44, Mike Stump wrote: On Dec 15, 2011, at 1:43 AM, Kai Tietz wrote: This patch takes care that we are using for operator new/delete replacement test static version on mingw-targets. As the shared (DLL) version isn't able to have operator overload within DLL itself, as a DLL is finally-linked for PE-COFF. Ok for apply? Not sure who would review this if I don't, so, Ok. That said, if a shared library C++ type person wants to chime in... I get the feeling this is unfortunate, and it might have been nice to manage this in some other way, but, I just want to step back and let others think about it. Well, it's a consequence of how you can't leave undefined references in Windows DLLs at link-time for the loader to just fill in with the first definition it comes across at run-time (as you can on ELF). We have to jump through hoops to get operator new/delete replacement working on Cygwin, and were lucky in that the cygwin1.dll is linked against absolutely everything, so we had somewhere to hang our redirection hooks. Without someone adding some similar amount of infrastructure to MinGW, the only time function replacement can work is for a statically-linked executable, when all definitions are visible in one single link. * g++.old-deja/g++.brendan/new3.C: Adjust test for mingw targets to use static-version. s/static-version/static linking/ +// Avoid use of none-overridable new/delete operators in shared s/none-overridable/non-overridable/g s/in shared/in shared link/g Patch looks perfectly sensible to me, but I can't approve. cheers, DaveK -- | (\_/) This is Bunny. Copy and paste | (='.'=) Bunny into your signature to help | ()_() him gain world domination
Re: [patch testsuite g++.dg]: Reflect ABI change for windows native targets about bitfield layout in structures
Ping
2011/12/16 Dave Korn dave.korn.cyg...@gmail.com:
On 16/12/2011 09:01, Kai Tietz wrote:
2011/12/15 Dave Korn:
{ dg-options -mno-align-double { target i?86-*-cygwin* i?86-*-mingw* } }
{ dg-additional-options -mno-ms-bitfields { target i?86-*-mingw* } }
... so that MinGW gets both and Cygwin only the one it wants? (Actually the
first one could just as well be changed to dg-additional-options at the same
time, couldn't it?)
Well, interesting. I think it should be the additional variant for
cygwin/mingw, as otherwise -O2 gets clobbered for it, isn't it?
Yes, that's what I was concerned with.
So I modified patch as attached.
Thanks for that. I recommend this patch for approval.
cheers,
DaveK
--
| (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination
