[Bug fortran/47023] [4.6/4.7 regression] C_Sizeof: Rejects valid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47023 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-10-16 AssignedTo|unassigned at gcc dot |janus at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #10 from janus at gcc dot gnu.org 2011-10-16 08:43:56 UTC --- (In reply to comment #9) This patch itself doesn't do anything wrong AFAICS, it rather seems to expose an underlying bug: Either we need to set the 'is_c_interop' flag correctly or loosen the checks in verify_c_interop. I think the latter. I think one can allow all intrinsic types. On second thought, I'm not so sure about this. Is this actually allowed by the Fortran standard? (If not, one could think about allowing it only with --std=gnu as an extension.) Note, additionally, that setting attr.is_c_interop is kind of difficult for 0.0_c_int ... Well, no. We don't need to set 'attr.is_c_interop', but 'ts.is_c_interop', which can also be done for constants. I'm right now testing a patch which does so and fixes the regression.
[Bug tree-optimization/50727] [4.7 Regression] ICE with segfault in flow_bb_inside_loop_p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50727 Ira Rosen irar at il dot ibm.com changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-10-16 AssignedTo|unassigned at gcc dot |irar at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #2 from Ira Rosen irar at il dot ibm.com 2011-10-16 08:50:31 UTC --- This is the same bug as pr 50635 but in another function.
[Bug middle-end/48668] [4.6/4.7 regression] COMDAT Group signature not emitted in group
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48668 --- Comment #5 from Jan Hubicka hubicka at gcc dot gnu.org 2011-10-16 09:02:38 UTC --- Author: hubicka Date: Sun Oct 16 09:02:33 2011 New Revision: 180053 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=180053 Log: PR target/48668 PR target/50689 * cgraphunit.c (cgraph_expand_function): Expand thunks and alises after function body. Modified: trunk/gcc/ChangeLog trunk/gcc/cgraphunit.c
[Bug bootstrap/50689] AIX bootstrap failure from cgraphunit.c aliases change
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50689 --- Comment #6 from Jan Hubicka hubicka at gcc dot gnu.org 2011-10-16 09:02:38 UTC --- Author: hubicka Date: Sun Oct 16 09:02:33 2011 New Revision: 180053 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=180053 Log: PR target/48668 PR target/50689 * cgraphunit.c (cgraph_expand_function): Expand thunks and alises after function body. Modified: trunk/gcc/ChangeLog trunk/gcc/cgraphunit.c
[Bug tree-optimization/50730] SLP vectorization confused by unrelated DRs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50730
Ira Rosen irar at il dot ibm.com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2011-10-16
CC||irar at il dot ibm.com
Ever Confirmed|0 |1
--- Comment #1 from Ira Rosen irar at il dot ibm.com 2011-10-16 09:41:27 UTC
---
Tested only with the vectorizer tests.
Index: tree-vect-data-refs.c
===
--- tree-vect-data-refs.c (revision 179789)
+++ tree-vect-data-refs.c (working copy)
@@ -2524,7 +2524,7 @@ vect_analyze_data_refs (loop_vec_info lo
VEC (data_reference_p, heap) *datarefs;
struct data_reference *dr;
tree scalar_type;
- bool res;
+ bool res, stop_bb_analysis = false;
if (vect_print_dump_info (REPORT_DETAILS))
fprintf (vect_dump, === vect_analyze_data_refs ===\n);
@@ -2579,12 +2579,19 @@ vect_analyze_data_refs (loop_vec_info lo
{
if (vect_print_dump_info (REPORT_UNVECTORIZED_LOCATIONS))
fprintf (vect_dump, not vectorized: unhandled data-ref );
+
return false;
}
stmt = DR_STMT (dr);
stmt_info = vinfo_for_stmt (stmt);
+ if (stop_bb_analysis)
+{
+ STMT_VINFO_VECTORIZABLE (stmt_info) = false;
+ continue;
+}
+
/* Check that analysis of the data-ref succeeded. */
if (!DR_BASE_ADDRESS (dr) || !DR_OFFSET (dr) || !DR_INIT (dr)
|| !DR_STEP (dr))
@@ -2595,6 +2602,13 @@ vect_analyze_data_refs (loop_vec_info lo
print_gimple_stmt (vect_dump, stmt, 0, TDF_SLIM);
}
+ if (bb_vinfo)
+{
+ STMT_VINFO_VECTORIZABLE (stmt_info) = false;
+ stop_bb_analysis = true;
+ continue;
+}
+
return false;
}
@@ -2603,7 +2617,15 @@ vect_analyze_data_refs (loop_vec_info lo
if (vect_print_dump_info (REPORT_UNVECTORIZED_LOCATIONS))
fprintf (vect_dump, not vectorized: base addr of dr is a
constant);
- return false;
+
+ if (bb_vinfo)
+{
+ STMT_VINFO_VECTORIZABLE (stmt_info) = false;
+ stop_bb_analysis = true;
+ continue;
+}
+
+ return false;
}
if (TREE_THIS_VOLATILE (DR_REF (dr)))
@@ -2613,6 +2635,14 @@ vect_analyze_data_refs (loop_vec_info lo
fprintf (vect_dump, not vectorized: volatile type );
print_gimple_stmt (vect_dump, stmt, 0, TDF_SLIM);
}
+
+ if (bb_vinfo)
+{
+ STMT_VINFO_VECTORIZABLE (stmt_info) = false;
+ stop_bb_analysis = true;
+ continue;
+}
+
return false;
}
@@ -2628,6 +2658,14 @@ vect_analyze_data_refs (loop_vec_info lo
exception );
print_gimple_stmt (vect_dump, stmt, 0, TDF_SLIM);
}
+
+ if (bb_vinfo)
+{
+ STMT_VINFO_VECTORIZABLE (stmt_info) = false;
+ stop_bb_analysis = true;
+ continue;
+}
+
return false;
}
@@ -2745,6 +2783,14 @@ vect_analyze_data_refs (loop_vec_info lo
not vectorized: more than one data ref in stmt: );
print_gimple_stmt (vect_dump, stmt, 0, TDF_SLIM);
}
+
+ if (bb_vinfo)
+{
+ STMT_VINFO_VECTORIZABLE (stmt_info) = false;
+ stop_bb_analysis = true;
+ continue;
+}
+
return false;
}
@@ -2769,6 +2815,7 @@ vect_analyze_data_refs (loop_vec_info lo
{
/* Mark the statement as not vectorizable. */
STMT_VINFO_VECTORIZABLE (stmt_info) = false;
+ stop_bb_analysis = true;
continue;
}
else
[Bug c++/32614] -fmessage-length documentation and implementation disagree
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32614 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |ASSIGNED CC|paolo.carlini at oracle dot | |com | AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com
[Bug middle-end/50724] isnan broken by -ffinite-math-only in g++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50724 --- Comment #16 from Richard Guenther rguenth at gcc dot gnu.org 2011-10-16 09:59:35 UTC --- (In reply to comment #14) Richard said: The documentation states Allow optimizations for floating-point arithmetic that assume that arguments and results are not NaNs or +-Infs. Yes, that's my argument as well. Note ARITHMETIC. Also note MATH in the name of both --finite-MATH-only, and -ffast-MATH it falls under. And it doesn't reference the 'math library' to qualify that. Basically, if you want to close on this point, I want to see you explicitly argue why the classification functions should be considered arithmetic. I'm going to nail this down and list there are 5 classification functions (fpclassify, infinite, isinf, isnan, isnormal) and the vast majority of the other library functions are obviously proper arithmetic operations. The ones that aren't (signbit, copysign, nextafter, nan), you're exactly right that we should carefully consider the result of NaN optimization (special cases). You don't have to do this if *you* don't want to, but it should be done and it sounds like no one has. This has been discussed to death already, and the present behavior is how GCC behaved since ever. Except also NOT TRUE. It currently doesn't behave this way with math.h. math.h is not part of GCC, if math.h implements isnan in a way that skips GCC (by making it use inline assembler) then that doesn't show GCC does not perform the optimization (you can check with using __builtin_isnan instead of isnan). The only way out I see that not breaks other users uses would be a new flag, like -fpreserve-ieee-fp-classification that, ontop of -ffinite-math-only, would disable the optimization for the classification functions. (Note that they are folded to arithmetic, !(x==x), so that transform has to be disabled as well, and on some architectures you might get library calls because of this instead of inline expansions).
[Bug c++/50741] New: remove_unused_locals causes seg fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50741 Bug #: 50741 Summary: remove_unused_locals causes seg fault Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: dcb...@hotmail.com Created attachment 25512 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25512 C++ source code I just tried to compile the package fusecompress_offline1-1.99.19-7 on latest trunk snapshot 20111015 on an AMD x86_64 box. The compiler said CompressedMagic.cpp: In constructor 'CompressedMagic::CompressedMagic()': CompressedMagic.cpp:106:1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. valgrind said ==8702== Invalid read of size 1 ==8702==at 0xB0B2B6: mark_all_vars_used_1(tree_node**, int*, void*) (tree-fl ow-inline.h:562) ==8702==by 0xC1098D: walk_tree_1(tree_node**, tree_node* (*)(tree_node**, in t*, void*), void*, pointer_set_t*, tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*, pointer_set_t*)) (tree.c:10455) ==8702==by 0xC10F7A: walk_tree_1(tree_node**, tree_node* (*)(tree_node**, in t*, void*), void*, pointer_set_t*, tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*, pointer_set_t*)) (tree.c:10533) ==8702==by 0xB0C049: remove_unused_locals() (tree-ssa-live.c:595) ==8702==by 0x99165C: execute_function_todo(void*) (passes.c:1695) ==8702==by 0x991E7C: execute_todo(unsigned int) (passes.c:1741) ==8702==by 0x994FC9: execute_one_pass(opt_pass*) (passes.c:2087) ==8702==by 0x9952C4: execute_pass_list(opt_pass*) (passes.c:2119) ==8702==by 0x9944F3: do_per_function_toporder(void (*)(void*), void*) (passe s.c:1606) ==8702==by 0x995745: execute_ipa_pass_list(opt_pass*) (passes.c:2437) ==8702==by 0x78A362: cgraph_optimize() (cgraphunit.c:2011) ==8702==by 0x78A8D9: cgraph_finalize_compilation_unit() (cgraphunit.c:1312) ==8702== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==8702== Preprocessed source code attached. Flag -O2 required.
[Bug target/50737] FAIL: Throw_3 -O3 execution, generic dwarf2 EH problem?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50737 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2011-10/msg01403.htm ||l Last reconfirmed||2011-10-16 AssignedTo|unassigned at gcc dot |ubizjak at gmail dot com |gnu.org | Ever Confirmed|0 |1 --- Comment #9 from Uros Bizjak ubizjak at gmail dot com 2011-10-16 10:21:41 UTC --- Patch at [1]. [1] http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01403.html
[Bug c++/50742] New: tree check fail in check_previous_goto_1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50742 Bug #: 50742 Summary: tree check fail in check_previous_goto_1 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: dcb...@hotmail.com I just tried to compile the package openvrml-0.18.8-2 on latest trunk snapshot 20111015 on an AMD x86_64 box. The compiler said libopenvrml/openvrml/script.cpp: In constructor 'openvrml::script_node::script_node(openvrml::script_node_metatype, const boost::shared_ptropenvrml::scope, const node_interface_set, const initial_value_map)': libopenvrml/openvrml/script.cpp:2044:30: internal compiler error: tree check: expected tree that contains 'decl minimal' structure, have 'tree_list' in check_previous_goto_1, at cp/decl.c:2686 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Preprocessed source code attached. No special flags required.
[Bug c++/50742] tree check fail in check_previous_goto_1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50742 --- Comment #1 from dcb dcb314 at hotmail dot com 2011-10-16 10:37:19 UTC --- Created attachment 25513 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25513 gzipped C++ source code
[Bug objc/50743] New: [4.7 regression] objc-act.c triggers -Werror=sign-compare breaking bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50743 Bug #: 50743 Summary: [4.7 regression] objc-act.c triggers -Werror=sign-compare breaking bootstrap Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: objc AssignedTo: unassig...@gcc.gnu.org ReportedBy: mi...@it.uu.se Attempting to bootstrap gcc-4.7-20111015 with objc enabled and --disable-build-poststage1-with-cxx fails with: /mnt/scratch/gcc-4.7-20111015/gcc/objc/objc-act.c: In function 'check_duplicates': /mnt/scratch/gcc-4.7-20111015/gcc/objc/objc-act.c:5073:21: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare] /mnt/scratch/gcc-4.7-20111015/gcc/objc/objc-act.c:5106:17: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare] /mnt/scratch/gcc-4.7-20111015/gcc/objc/objc-act.c: In function 'insert_method_into_method_map': /mnt/scratch/gcc-4.7-20111015/gcc/objc/objc-act.c:5828:18: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare] /mnt/scratch/gcc-4.7-20111015/gcc/objc/objc-act.c:5840:18: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare] cc1: all warnings being treated as errors make[3]: *** [objc/objc-act.o] Error 1 make[3]: Leaving directory `/mnt/scratch/objdir47/gcc' make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory `/mnt/scratch/objdir47' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/mnt/scratch/objdir47' make: *** [bootstrap] Error 2 This is a regression from r179965: http://gcc.gnu.org/ml/gcc-cvs/2011-10/msg00561.html The issue is that the code was rewritten to use a number or for-loops with a size_t index and a TREE_VEC_LENGTH limit; however, TREE_VEC_LENGTH returns a signed integer, resulting in a signed/unsigned comparison. The C front-end catches this error, but the C++ front-end fails to do so due to PR50012.
[Bug c++/50744] New: ice in good_cloning_opportunity_p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50744 Bug #: 50744 Summary: ice in good_cloning_opportunity_p Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: dcb...@hotmail.com Created attachment 25514 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25514 C++ source code I just tried to compile the package polyml-5.4.1-1 on latest trunk snapshot 20111015 on an AMD x86_64 box. The compiler said foreign.cpp: At global scope: foreign.cpp:1919:1: internal compiler error: in good_cloning_opportunity_p, at ipa-cp.c:1228 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Preprocessed source code attached. Flag -O3 required.
[Bug objc/50743] [4.7 regression] objc-act.c triggers -Werror=sign-compare breaking bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50743 --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se 2011-10-16 10:50:19 UTC --- Created attachment 25515 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25515 preliminary patch Casting the value of TREE_VEC_LENGTH to size_t before comparing it with a size_t index fixes the issue for me on i686-linux.
[Bug libstdc++/50745] New: proposal to make visibility of namespace gcc configurable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50745
Bug #: 50745
Summary: proposal to make visibility of namespace gcc
configurable
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vincenzo.innoce...@cern.ch
CC: b...@redhat.com, ja...@gcc.gnu.org, pa...@gcc.gnu.org
following the discussion in PR50348 I would like to suggest to make
the visibility of namespace gcc configurable.
This will allow developers that build gcc themselves to experiment and
eventually choose the visibility that best fit their application.
something like
namespace std _GLIBCXX_STD_VISIBILITY {…}
with _GLIBCXX_STD_VISIBILITY properly set at configure time.
std::exception is already protected with #pragma by the way and should of
course stay like that.
[Bug objc/50743] [4.7 regression] objc-act.c triggers -Werror=sign-compare breaking bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50743 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-10-16 Ever Confirmed|0 |1 --- Comment #2 from Nicola Pero nicola at gcc dot gnu.org 2011-10-16 11:03:59 UTC --- Thanks for reporting this! The patch looks good to me (but I can't approve it). Alternatively, I suppose, the iterating variable itself could be declared as int. Do you want to submit the patch to gcc-patc...@gnu.org ? Thanks
[Bug target/50683] GCC compiles MPFR 3.1.0 wrongly on sparc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50683 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |ASSIGNED CC||ebotcazou at gcc dot ||gnu.org AssignedTo|unassigned at gcc dot |ebotcazou at gcc dot |gnu.org |gnu.org --- Comment #4 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-10-16 11:25:03 UTC --- Investigating.
[Bug objc/50743] [4.7 regression] objc-act.c triggers -Werror=sign-compare breaking bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50743 --- Comment #3 from Mikael Pettersson mikpe at it dot uu.se 2011-10-16 11:31:52 UTC --- (In reply to comment #2) Thanks for reporting this! The patch looks good to me (but I can't approve it). Thanks. Do you want to submit the patch to gcc-patc...@gnu.org ? Submitted: http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01416.html
[Bug c++/50744] ice in good_cloning_opportunity_p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50744 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-16 12:21:44 UTC --- tree-optimization?
[Bug tree-optimization/50730] SLP vectorization confused by unrelated DRs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50730 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-16 12:23:43 UTC --- First blush, looks like something could be abstracted as a function or a macro?!?
[Bug tree-optimization/50596] Problems in vectorization of condition expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50596 --- Comment #16 from Jakub Jelinek jakub at gcc dot gnu.org 2011-10-16 13:10:26 UTC --- Author: jakub Date: Sun Oct 16 13:10:20 2011 New Revision: 180057 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=180057 Log: PR tree-optimization/50596 * tree-vectorizer.h (NUM_PATTERNS): Increase to 7. * tree-vect-patterns.c (vect_vect_recog_func_ptrs): Add vect_recog_bool_pattern. (check_bool_pattern, adjust_bool_pattern_cast, adjust_bool_pattern, vect_recog_bool_pattern): New functions. * gcc.dg/vect/vect-cond-9.c: New test. Added: trunk/gcc/testsuite/gcc.dg/vect/vect-cond-9.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-patterns.c trunk/gcc/tree-vectorizer.h
[Bug rtl-optimization/50615] [4.7 Regression] ICE: in distribute_notes, at combine.c:13282 with -O --param max-cse-insns=1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50615 --- Comment #3 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-10-16 13:14:37 UTC --- Author: ebotcazou Date: Sun Oct 16 13:14:34 2011 New Revision: 180058 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=180058 Log: PR rtl-optimization/50615 * combine.c (distribute_notes) REG_ARGS_SIZE: Skip if I3 is a no-op. Added: trunk/gcc/testsuite/gcc.dg/vla-23.c Modified: trunk/gcc/ChangeLog trunk/gcc/combine.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/50690] [4.7 Regression] ICE with front end optimization and OMP workshare
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50690 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|NEW AssignedTo|tkoenig at gcc dot gnu.org |unassigned at gcc dot ||gnu.org --- Comment #6 from Thomas Koenig tkoenig at gcc dot gnu.org 2011-10-16 13:15:28 UTC --- Patch at: http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01383.html Unassigning myself.
[Bug ada/48835] Porting GNAT to GNU/Linux/m68k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48835
--- Comment #37 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org
2011-10-16 13:20:01 UTC ---
(In reply to comment #33)
(In reply to comment #32)
(In reply to comment #31)
* expmed.c
(store_bit_field_1): Use the new interfaces.
I'll continue trying to minimize the changeset.
Of the three translation paths in store_bit_field_1 that were updated in
that
revision, vec_set, movstrict, and insv, only the insv path update matters
for
GNAT/m68k.
Progress. The minimal fragment of r171341 that allows r171340 to bootstrap
GNAT/m68k is the following:
--- gcc-4.7-r171340/gcc/expmed.c.~1~2011-03-04 11:31:33.0 +0100
+++ gcc-4.7-r171340/gcc/expmed.c2011-10-11 09:31:31.0 +0200
@@ -656,7 +656,8 @@ store_bit_field_1 (rtx str_rtx, unsigned
(bitsize + bitpos GET_MODE_BITSIZE (op_mode)))
insn_data[CODE_FOR_insv].operand[1].predicate (GEN_INT (bitsize),
VOIDmode)
- check_predicate_volatile_ok (CODE_FOR_insv, 0, op0, VOIDmode))
+ check_predicate_volatile_ok (CODE_FOR_insv, 0, op0,
+
insn_data[CODE_FOR_insv].operand[0].mode))
{
int xbitpos = bitpos;
rtx value1;
That is, when checking insv opnd 0 use the mode from insn_data[] not VOIDmode.
(The code looks different in r171341 due new APIs and moving the operand
checking to a later point. The essential _functional_ difference wrt opnd 0
is
however just the different mode value used in the check.)
I'm currently trying to bootstrap GNAT/m68k with gcc-4.6.1 and the above
patch.
Adding Richard Sandiford to CC: list. Richard, do you have any idea why the
above mode change might have unbroken m68k?
Sorry for the slow reply. The SImode/nonimmediate_operand combination
in m68k's insv pattern looks a little odd:
(define_expand insv
[(set (zero_extract:SI (match_operand:SI 0 nonimmediate_operand )
(match_operand:SI 1 const_int_operand )
(match_operand:SI 2 const_int_operand ))
(match_operand:SI 3 register_operand ))]
TARGET_68020 TARGET_BITFIELD
)
The generic insv interface can take two styles of operand:
a QImode memory or a word_mode (SImode) register. The odd
thing is that this m68k pattern requires even the memories
to be SImode (which they never are).
In 4.6 and earlier, we simply ignored the :SI, so QImode
memories were still accepted. The effect of the backport
is to restrict insv to register operands (because the mode
is now checked), so the patch is equivalent to changing
nonimmediate_operand to register_operand in the define_expand.
But that isn't really what you want.
In other words, I'm afraid it looks like this backport is
hiding a bug elsewhere that appears somehow (and probably
indirectly!) related to the memory insv define_insns.
Looks like you've also found a performance regression in 4.7,
because I assume we no longer allow memory operands there either.
[Bug rtl-optimization/50615] [4.7 Regression] ICE: in distribute_notes, at combine.c:13282 with -O --param max-cse-insns=1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50615 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-10-16 13:20:01 UTC --- .
[Bug tree-optimization/50596] Problems in vectorization of condition expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50596
--- Comment #17 from vincenzo Innocente vincenzo.innocente at cern dot ch
2011-10-16 13:47:22 UTC ---
cool!
even
signed char k[1024];
61void foo6() {
62 for (int i=0; i!=N; ++i)
63k[i] = (a[i]b[i]) (c[i]d[i]);
vectorize!
with
bool k[1024];
does not. I can survive though.
I will have to measure performance. I suspect that using
int k[1024];
will be faster…
Anyhow great achievement
[Bug tree-optimization/50727] [4.7 Regression] ICE with segfault in flow_bb_inside_loop_p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50727 --- Comment #3 from irar at gcc dot gnu.org 2011-10-16 13:47:58 UTC --- Author: irar Date: Sun Oct 16 13:47:54 2011 New Revision: 180060 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=180060 Log: PR tree-optimization/50727 * tree-vect-patterns.c (vect_operation_fits_smaller_type): Add DEF_STMT to the list of statements to be replaced by the pattern statements. Added: trunk/gcc/testsuite/gcc.dg/vect/pr50727.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-patterns.c
[Bug libstdc++/50745] proposal to make visibility of namespace std configurable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50745 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-10-16 13:51:57 UTC --- I understand the benefit of hiding internal implementation details, but your proposal seems to imply that you could alter the visibility of everything in namespace std e.g. std::string would have hidden visibility. What's the point of the standard library if you can't use any of it outside libstdc++.so ?
[Bug tree-optimization/50727] [4.7 Regression] ICE with segfault in flow_bb_inside_loop_p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50727 Ira Rosen irar at il dot ibm.com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Ira Rosen irar at il dot ibm.com 2011-10-16 14:06:05 UTC --- Fixed.
[Bug libstdc++/50745] proposal to make visibility of namespace std configurable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50745 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-16 14:20:44 UTC --- I'm thinking, maybe as a normal, not configure-time, macro, like _GLIBCXX_DEBUG, the idea would make more sense? Of course a very dangerous thing, but more usable in that way, right?
[Bug libstdc++/50745] proposal to make visibility of namespace std configurable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50745 --- Comment #2 from vincenzo Innocente vincenzo.innocente at cern dot ch 2011-10-16 14:20:19 UTC --- I want just to remove _GLIBCXX_VISIBILITY(default) from namespace std so that visibility of std::xyz can be inherited from the outer scope for instance when compiling with -fvisibility=hidden. It is mostly to make template instantiation local to user shared libraries, surely not to make std::string local to libstdc++.so!
[Bug tree-optimization/50746] New: [4.7 Regression] FAIL: gcc.dg/vect/pr37482.c (internal compiler error) on powerpc-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50746 Bug #: 50746 Summary: [4.7 Regression] FAIL: gcc.dg/vect/pr37482.c (internal compiler error) on powerpc-apple-darwin9 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr CC: ia...@gcc.gnu.org, r...@gcc.gnu.org Host: powerpc-apple-darwin9 Target: powerpc-apple-darwin9 Build: powerpc-apple-darwin9 Between revisions 180043 (OK) and 180052 the following tests failed on powerpc-apple-darwin9 (see http://gcc.gnu.org/ml/gcc-testresults/2011-10/msg01830.html): FAIL: gcc.dg/vect/pr37482.c (internal compiler error) FAIL: gcc.dg/vect/pr37482.c (test for excess errors) FAIL: gcc.dg/vect/vect-114.c scan-tree-dump-times vect vectorized 0 loops 1 FAIL: gcc.dg/vect/pr37482.c -flto (internal compiler error) FAIL: gcc.dg/vect/pr37482.c -flto (test for excess errors) FAIL: gcc.dg/vect/vect-114.c -flto scan-tree-dump-times vect vectorized 0 loops 1 From http://gcc.gnu.org/regtest/HEAD/native-logsum/gcc/testsuite/gcc/gcc.log.gzip the ICE is Executing on host: /Users/regress/tbox/native/build/gcc/xgcc -B/Users/regress/tbox/native/build/gcc/ /Users/regress/tbox/svn-gcc/gcc/testsuite/gcc.dg/vect/pr37482.c-maltivec -ftree-vectorize -fno-vect-cost-model -O2 -fdump-tree-vect-details -S -o pr37482.s(timeout = 300) [address=0800 pc=005e6e10] /Users/regress/tbox/svn-gcc/gcc/testsuite/gcc.dg/vect/pr37482.c: In function 'SexiALI_Convert': /Users/regress/tbox/svn-gcc/gcc/testsuite/gcc.dg/vect/pr37482.c:14:10: internal compiler error: Segmentation Fault This is likely due to revision 180047 Author:rth Date:Sat Oct 15 19:36:50 2011 UTC (18 hours, 34 minutes ago) Changed paths:5 Log Message: Use VEC_PERM_EXPR in the vectorizer. * tree-vect-slp.c: Include langhooks.h. (vect_create_mask_and_perm): Emit VEC_PERM_EXPR, not a builtin. (vect_transform_slp_perm_load): Use can_vec_perm_expr_p. Simplify mask creation for VEC_PERM_EXPR. * tree-vect-stmts.c (perm_mask_for_reverse): Return the mask, not the builtin. (reverse_vec_elements): Emit VEC_PERM_EXPR not a builtin. * Makefile.in (tree-vect-slp.o): Update dependency. * optabs.c (can_vec_perm_expr_p): Allow NULL as unknown constant.
[Bug libstdc++/50745] proposal to make visibility of namespace std configurable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50745 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2011-10-16 14:27:00 UTC --- (In reply to comment #3) I'm thinking, maybe as a normal, not configure-time, macro, like _GLIBCXX_DEBUG, the idea would make more sense? Of course a very dangerous thing, but more usable in that way, right? making it easier for users to shoot themselves in the foot with ODR violations and hidden symbols that shouldn't be hidden, and report them as bugs? hmm ...
[Bug libstdc++/50745] proposal to make visibility of namespace std configurable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50745 --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-16 14:30:21 UTC --- We could add the macro-mechanism without documenting it ;)
[Bug libstdc++/50745] proposal to make visibility of namespace std configurable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50745 --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-16 14:35:18 UTC --- Seriously, wait a second: what happen if at configure time one simply passes --disable-visibility? Doesn't that disable completely the namespace decorations? That seems a sane thing.
[Bug tree-optimization/49140] [4.6 regression] wrong code with -O2 and -O3, not with -O3 -no-inline
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49140 --- Comment #23 from Mans Rullgard mans at mansr dot com 2011-10-16 14:40:29 UTC --- Created attachment 25516 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25516 Small test case with invalid code exhibiting the problem Here's a small test case with invalid code showing the problem with several gcc versions going back at least to 4.5. Compiling with -fno-tree-pta makes it behave as expected. I do not believe the compiler to be at fault here. PARI is clearly full of undefined behaviours they really ought to fix rather than complain that doing so would change the ABI and blame the compiler which is only doing a good job following the spec.
[Bug target/50683] GCC compiles MPFR 3.1.0 wrongly on sparc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50683 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added CC||davem at davemloft dot net --- Comment #5 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-10-16 14:45:36 UTC --- Ugh, annoying linker relaxation bug. The compiler correctly generates: add%l7, %l3, %l3, %tgd_add(__gmpfr_flags) [...] call__tls_get_addr, %tgd_call(__gmpfr_flags) mov%l3, %o0 ld[%o0], %g1 but the linker turns this into: 0x00014d14 +504: add %g7, %o0, %o0 0x00014d18 +508: mov %l3, %o0 0x00014d1c +512: ld [ %o0 ], %g1 so segfault on the load. Filed as http://sourceware.org/bugzilla/show_bug.cgi?id=13301 for the linker. Should we put a workaround in the compiler?
[Bug tree-optimization/50746] [4.7 Regression] FAIL: gcc.dg/vect/pr37482.c (internal compiler error) on powerpc-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50746 Ira Rosen irar at il dot ibm.com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-10-16 CC||irar at il dot ibm.com Ever Confirmed|0 |1 --- Comment #1 from Ira Rosen irar at il dot ibm.com 2011-10-16 14:51:58 UTC --- I see these failures on powerpc64-suse-linux. pr37482.c seems to fail during expand of VEC_PERM_EXPR. The accesses in vect-114.c are aligned, so it probably doesn't need vect_hw_misalign (it was me who added it there http://gcc.gnu.org/ml/gcc-patches/2010-11/msg01521.html, but it seems to be incorrect).
[Bug tree-optimization/50746] [4.7 Regression] FAIL: gcc.dg/vect/pr37482.c (internal compiler error) on powerpc-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50746 --- Comment #2 from Iain Sandoe iains at gcc dot gnu.org 2011-10-16 14:53:13 UTC --- Starting program: /Volumes/ScratchCS/gcc-4-7-trunk-build/gcc/cc1 -fpreprocessed pr37482.i -fPIC -quiet -dumpbase pr37482.c -mmacosx-version-min=10.5.8 -maltivec -m32 -auxbase-strip pr37482.s -O2 -version -ftree-vectorize -fno-vect-cost-model -fdump-tree-vect-details -o pr37482.s Reading symbols for shared libraries +++.. done GNU C (GCC) version 4.7.0 20111015 (experimental) [trunk revision 180048] (powerpc-apple-darwin9) compiled by GNU C version 4.7.0 20111015 (experimental) [trunk revision 180048], GMP version 5.0.2, MPFR version 3.0.1, MPC version 0.9 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU C (GCC) version 4.7.0 20111015 (experimental) [trunk revision 180048] (powerpc-apple-darwin9) compiled by GNU C version 4.7.0 20111015 (experimental) [trunk revision 180048], GMP version 5.0.2, MPFR version 3.0.1, MPC version 0.9 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 153db3953d8b0836637534bdb4728fc0 Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x42002284 const_rtx_hash_1 (xp=0x4170f504, data=0xbfffe814) at /GCC/gcc-live-trunk/gcc/varasm.c:3384 3384 code = GET_CODE (x); (gdb) bt #0 const_rtx_hash_1 (xp=0x4170f504, data=0xbfffe814) at /GCC/gcc-live-trunk/gcc/varasm.c:3384 #1 0x008664ec in const_rtx_hash_1 (xp=0x4170f504, data=0xbfffe814) at /GCC/gcc-live-trunk/gcc/varasm.c:3376 Previous frame identical to this frame (gdb could not unwind past this frame)
[Bug c++/50741] remove_unused_locals causes seg fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50741 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-16 15:04:32 UTC --- Tree-optimization?
[Bug c++/29859] reference-compatible is defined too narrowly in [decl.int.ref]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29859 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-16 15:19:46 UTC --- To be honest, I don't know if something changed lately in the ISO Standard about this, but really, doesn't look like a GCC issue. In case, you may consider also using comp.std.c++.moderated if not the reflectors.
[Bug libstdc++/50745] proposal to make visibility of namespace std configurable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50745 --- Comment #7 from vincenzo Innocente vincenzo.innocente at cern dot ch 2011-10-16 15:32:29 UTC --- At a first look --disable-visibility does the job.. have to check exception. the #pragma is still there though. I think I can experiment with that. thanks Paolo.
[Bug lto/50747] New: [4.7 Regression] ICE in produce_symtab, at lto-streamer-out.c:1435
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50747 Bug #: 50747 Summary: [4.7 Regression] ICE in produce_symtab, at lto-streamer-out.c:1435 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: mar...@trippelsdorf.de While I was trying to build gcc with -fno-fat-lto-objects I hit this ICE: ../../../../gcc/libstdc++-v3/src/complex_io.cc:92:1: internal compiler error: in produce_symtab, at lto-streamer-out.c:1435 Reduced testcase is attached. % g++ -fno-implicit-templates -w -fpermissive -flto test.ii test.ii:108:23: internal compiler error: in produce_symtab, at lto-streamer-out.c:1435 Please submit a full bug report, with preprocessed source if appropriate.
[Bug lto/50747] [4.7 Regression] ICE in produce_symtab, at lto-streamer-out.c:1435
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50747 --- Comment #1 from Markus Trippelsdorf markus at trippelsdorf dot de 2011-10-16 17:45:35 UTC --- Created attachment 25517 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25517 delta reduced testcase
[Bug libstdc++/50745] proposal to make visibility of namespace std configurable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50745 vincenzo Innocente vincenzo.innocente at cern dot ch changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #8 from vincenzo Innocente vincenzo.innocente at cern dot ch 2011-10-16 18:03:27 UTC --- I think we can close this. those interested can follow the companion bug for gold http://sourceware.org/bugzilla/show_bug.cgi?id=12919 that end-up to be not a defect either. Now all pieces of the puzzle fold togehter The solution is not ideal, the functionalities are all in place.
[Bug target/50737] FAIL: Throw_3 -O3 execution, generic dwarf2 EH problem?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50737 --- Comment #10 from Uros Bizjak ubizjak at gmail dot com 2011-10-16 18:16:52 UTC --- Hm, I didn't notice new Java failure with the patch: === libjava tests === Running target unix FAIL: Array_3 execution - source compiled test FAIL: Array_3 -findirect-dispatch execution - source compiled test FAIL: Array_3 -O3 execution - source compiled test FAIL: Array_3 -O3 -findirect-dispatch execution - source compiled test === libjava Summary === # of expected passes2578 # of unexpected failures4 # of untested testcases4 Running failing test manually with new libgcc_s.so, we get: ./Array_3.exe Exception in thread main java.lang.NullPointerException at Array_3.main(Array_3.java:37) We are just not there yet ...
[Bug c++/48489] Invalid error message 'has no member named' when referring directly to the base class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48489 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-16 18:24:48 UTC --- On it.
[Bug libstdc++/50745] proposal to make visibility of namespace std configurable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50745 --- Comment #9 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-16 19:03:59 UTC --- Yeah! ;)
[Bug fortran/50547] dummy procedure argument of PURE shall be PURE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50547 --- Comment #6 from janus at gcc dot gnu.org 2011-10-16 19:17:03 UTC --- Author: janus Date: Sun Oct 16 19:16:59 2011 New Revision: 180061 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=180061 Log: 2011-10-16 Janus Weil ja...@gcc.gnu.org PR fortran/50547 * resolve.c (resolve_formal_arglist): Remove unneeded error message. Some reshuffling. 2011-10-16 Janus Weil ja...@gcc.gnu.org PR fortran/50547 * gfortran.dg/elemental_args_check_4.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/elemental_args_check_4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/50547] dummy procedure argument of PURE shall be PURE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50547 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #7 from janus at gcc dot gnu.org 2011-10-16 19:24:35 UTC --- Finally closing this one. I noticed that in 'resolve_formal_arglist' there are two separate checks for procedure dummies in elemental procedures (for functions/subroutines). Those clearly could be unified. Done with r180061. Finally closing this one.
[Bug target/50737] FAIL: Throw_3 -O3 execution, generic dwarf2 EH problem?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50737 --- Comment #11 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-10-16 19:33:19 UTC --- (In reply to comment #10) Hm, I didn't notice new Java failure with the patch: === libjava tests === Running target unix FAIL: Array_3 execution - source compiled test FAIL: Array_3 -findirect-dispatch execution - source compiled test FAIL: Array_3 -O3 execution - source compiled test FAIL: Array_3 -O3 -findirect-dispatch execution - source compiled test Probably because of a double PC adjustment for signals. The old code should be removed, it is located in libjava/include/dwarf2-signal.h for alpha.
[Bug c++/50748] New: Incorrect error message for lambda inside static member function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50748
Bug #: 50748
Summary: Incorrect error message for lambda inside static
member function
Classification: Unclassified
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ve...@mail.ru
struct B
{
int member;
static void fn()
{
member = 0; // error: invalid use of member 'B::member'
// in static member function
auto lambda = []()
{
member = 0; // error: 'this' was not captured
// for this lambda function
};
}
};
Second error message is incorrect and confusing because there is no 'this' in
static function member. Error message might be the same.
[Bug fortran/47023] [4.6/4.7 regression] C_Sizeof: Rejects valid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47023 --- Comment #11 from janus at gcc dot gnu.org 2011-10-16 19:42:50 UTC --- Author: janus Date: Sun Oct 16 19:42:48 2011 New Revision: 180062 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=180062 Log: 2011-10-16 Janus Weil ja...@gcc.gnu.org PR fortran/47023 * primary.c (match_kind_param): Detect ISO_C_BINDING kinds. (get_kind): Pass on 'is_iso_c' flag. (match_integer_constant,match_real_constant,match_logical_constant): Set 'ts.is_c_interop'. 2011-10-16 Janus Weil ja...@gcc.gnu.org PR fortran/47023 * gfortran.dg/c_kind_tests_3.f03: New. Added: trunk/gcc/testsuite/gfortran.dg/c_kind_tests_3.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/primary.c trunk/gcc/testsuite/ChangeLog
[Bug target/50749] New: SH Target: Post-increment addressing used only for first memory access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50749
Bug #: 50749
Summary: SH Target: Post-increment addressing used only for
first memory access
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: oleg.e...@t-online.de
CC: kkoj...@gcc.gnu.org
Target: sh*-*-*
Post-increment addressing is generated only for the first
memory access. Any subsequent memory access does not use
post-increment addressing.
The following two functions are reduced examples and result
in the same code being generated.
The problem exists with any number of memory accesses 1
and at any optimization level.
int test_0 (char* p, int c)
{
int r = 0;
r += *p++;
r += *p++;
r += *p++;
return r;
}
int test_1 (char* p, int c)
{
int r = 0;
r += p[0];
r += p[1];
r += p[2];
return r;
}
compiled with -fno-ivopts -Os -m4-single -ml ...
movr4,r1
mov.b@r1+,r0
add#2,r4
mov.b@r1,r1
addr1,r0
mov.b@r4,r1
rts
addr1,r0
This could be done better ...
mov.b@r4+,r0
mov.b@r4+,r1
addr1,r0
mov.b@r4+,r1
rts
addr1,r0
Another example with a loop:
int test_func_1 (char* p, int c)
{
int r = 0;
do
{
r += *p++;
r += *p++;
} while (--c);
return r;
}
compiled with -fno-ivopts -Os -m4-single -ml ...
mov#0,r0
.L5:
movr4,r1
mov.b@r1+,r2
dtr5
mov.b@r1,r1
addr2,r0
add#2,r4
bf/s.L5
addr1,r0
rts
nop
would be better as:
mov#0, r0
.L5:
mov.b@r4+, r1
dtr5
mov.b@r4+, r2
addr1, r0
bf/s.L5
addr2, r0
rts
nop
Using built-in specs.
COLLECT_GCC=sh-elf-gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/sh-elf/4.7.0/lto-wrapper
Target: sh-elf
Configured with: ../gcc-trunk/configure --target=sh-elf --prefix=/usr/local
--enable-languages=c,c++ --enable-multilib --disable-libssp --disable-nls
--disable-werror --enable-lto --with-newlib --with-gnu-as --with-gnu-ld
--with-system-zlib
Thread model: single
gcc version 4.7.0 20111016 (experimental) (GCC)
[Bug target/50737] FAIL: Throw_3 -O3 execution, generic dwarf2 EH problem?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50737
--- Comment #12 from Uros Bizjak ubizjak at gmail dot com 2011-10-16 20:34:51
UTC ---
(In reply to comment #11)
Running target unix
FAIL: Array_3 execution - source compiled test
FAIL: Array_3 -findirect-dispatch execution - source compiled test
FAIL: Array_3 -O3 execution - source compiled test
FAIL: Array_3 -O3 -findirect-dispatch execution - source compiled test
Probably because of a double PC adjustment for signals. The old code should
be
removed, it is located in libjava/include/dwarf2-signal.h for alpha.
Indeed!
Following additional patch fixes all libjava tests:
Index: libjava/include/dwarf2-signal.h
===
--- libjava/include/dwarf2-signal.h(revision 180054)
+++ libjava/include/dwarf2-signal.h(working copy)
@@ -29,21 +29,8 @@
// then throw an exception. With the dwarf2 unwinder we don't usually
// need to do anything, with some minor exceptions.
-#ifdef __alpha__
-#define MAKE_THROW_FRAME(_exception)\
-do\
-{\
- /* Alpha either leaves PC pointing at a faulting instruction or the\
- following instruction, depending on the signal. SEGV always does\
- the former, so we adjust the saved PC to point to the following\
- instruction; this is what the handler in libgcc expects. */
\
- struct sigcontext *_sc = (struct sigcontext *)_p;\
- _sc-sc_pc += 4;\
-}\
-while (0)
+#ifdef __ia64__
-#elif defined(__ia64__)
-
#define MAKE_THROW_FRAME(_exception)\
do\
{\
I'm re-running libjava tests and will post complete patch to gcc-patches@ ML.
[Bug target/50750] New: SH Target: Pre-decrement addressing used only for first memory access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50750
Bug #: 50750
Summary: SH Target: Pre-decrement addressing used only for
first memory access
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: oleg.e...@t-online.de
CC: kkoj...@gcc.gnu.org
Target: sh*-*-*
Pre-decrement addressing is generated only for the first
memory access. Any subsequent memory access does not use
pre-decrement addressing.
The following is a reduced example.
The problem exists with any number of memory accesses 1
and at any optimization level.
int test_func_2_1 (int* p, int c)
{
int r = 0;
do
{
r += *--p;
r += *--p;
r += *--p;
} while (--c);
return r;
}
compiled with -fno-tree-loop-optimize -Os -m4-single -ml:
mov#0,r0
.L11:
movr4,r1
add#-64,r1
mov.l@(60,r1),r2
dtr5
add#-12,r4
addr2,r0
mov.l@(56,r1),r2
mov.l@(52,r1),r1
addr2,r0
bf/s.L11
addr1,r0
rts
nop
would be better as:
mov#0,r0
.L11:
mov.l@-r4,r1
dtr5
mov.l@-r4,r2
addr1,r0
mov.l@-r4,r3
addr2,r0
bf/s.L11
addr3,r0
rts
nop
Using built-in specs.
COLLECT_GCC=sh-elf-gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/sh-elf/4.7.0/lto-wrapper
Target: sh-elf
Configured with: ../gcc-trunk/configure --target=sh-elf --prefix=/usr/local
--enable-languages=c,c++ --enable-multilib --disable-libssp --disable-nls
--disable-werror --enable-lto --with-newlib --with-gnu-as --with-gnu-ld
--with-system-zlib
Thread model: single
gcc version 4.7.0 20111016 (experimental) (GCC)
[Bug fortran/50554] INQUIRE cannot redefine DO index (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50554
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- Comment #2 from kargl at gcc dot gnu.org 2011-10-16 22:35:10 UTC ---
(In reply to comment #1)
Confirmed. We need to add a gfc_check_do_variable in io.c's gfc_match_inquire.
This patch
Index: io.c
===
--- io.c(revision 180062)
+++ io.c(working copy)
@@ -3921,6 +3921,9 @@ gfc_match_inquire (void)
if (gfc_match_char (')') != MATCH_YES)
goto syntax;
+ if (gfc_check_do_variable (inquire-iolength-symtree))
+ goto cleanup;
+
m = match_io_list (M_INQUIRE, code);
if (m == MATCH_ERROR)
goto cleanup;
generates
laptop:kargl[213] gfc4x -c -Wall foo.f90
foo.f90:2.26:
inquire(iolength=I) n
1
foo.f90:1.15:
do I=1,10
2
Error: Variable 'i' at (1) cannot be redefined inside loop beginning at (2)
foo.f90:2.23:
inquire(iolength=I) n
1
Error: Unexpected junk in formal argument list at (1)
[Bug target/50751] New: SH Target: Displacement addressing does not work for QImode and HImode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50751
Bug #: 50751
Summary: SH Target: Displacement addressing does not work for
QImode and HImode
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: oleg.e...@t-online.de
CC: kkoj...@gcc.gnu.org
Target: sh*-*-*
Displacement addressing is only used for SImode but not
for QImode nor HImode. The following example summarizes the
problem:
struct X
{
chara, b, c, d;
short e, f;
int g, h;
};
int test_func_4 (X* x)
{
return x-b + x-e + x-g;
}
compiled with: -Os -m4-single -ml -S
movr4,r1
add#1,r1
mov.b@r1,r0
add#3,r1
mov.w@r1,r1
addr1,r0
mov.l@(8,r4),r1
rts
addr1,r0
would be better as:
mov.b@(1,r4),r0
movr0,r1
mov.w@(4,r4),r0
addr0,r1
mov.l@(8,r4),r0
addr1,r0
rts
nop
Using built-in specs.
COLLECT_GCC=sh-elf-gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/sh-elf/4.7.0/lto-wrapper
Target: sh-elf
Configured with: ../gcc-trunk/configure --target=sh-elf --prefix=/usr/local
--enable-languages=c,c++ --enable-multilib --disable-libssp --disable-nls
--disable-werror --enable-lto --with-newlib --with-gnu-as --with-gnu-ld
--with-system-zlib
Thread model: single
gcc version 4.7.0 20111016 (experimental) (GCC)
[Bug c++/50748] [C++0x] Incorrect error message for lambda inside static member function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50748 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Summary|Incorrect error message for |[C++0x] Incorrect error |lambda inside static member |message for lambda inside |function|static member function --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-16 22:57:39 UTC --- Already fixed in 4.6.x and mainline.
[Bug target/50694] SH Target: SH2A little endian does not actually work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50694
Kazumoto Kojima kkojima at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
Status|UNCONFIRMED |NEW
Last reconfirmed||2011-10-16
Ever Confirmed|0 |1
--- Comment #2 from Kazumoto Kojima kkojima at gcc dot gnu.org 2011-10-16
23:28:48 UTC ---
(In reply to comment #1)
Ah. One liner
-#define DRIVER_SELF_SPECS %{m2a:%{ml:%eSH2a does not support little-endian}}
+#define DRIVER_SELF_SPECS %{m2a*:%{ml:%eSH2a does not support
little-endian}}
should work.
[Bug target/50749] SH Target: Post-increment addressing used only for first memory access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50749 --- Comment #1 from Kazumoto Kojima kkojima at gcc dot gnu.org 2011-10-16 23:33:40 UTC --- GCC makes usual mem accesses into those with post_inc/pre_dec at auto_inc_dec pass. I guess that auto_inc_dec pass can't find post_inc insns well in that case because other tree/rtl optimizers tweak the code already. If this is the case, the problem would be not target specific.
[Bug fortran/50552] type name cannot be statement function dummy argument (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50552 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org 2011-10-16 23:43:11 UTC --- (In reply to comment #0) ! type name cannot be statement function dummy argument (r178939) type t real g end type f(t)=0 ! this should not be accepted end I can't find anything in the standard that confirms your statement. Can you point me to where the standard would prohibit the above code?
[Bug fortran/50552] type name cannot be statement function dummy argument (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50552 --- Comment #2 from kargl at gcc dot gnu.org 2011-10-16 23:55:49 UTC --- (In reply to comment #1) (In reply to comment #0) ! type name cannot be statement function dummy argument (r178939) type t real g end type f(t)=0 ! this should not be accepted end I can't find anything in the standard that confirms your statement. Can you point me to where the standard would prohibit the above code? I should also note that I cannot construct a program, which actually uses the statement function. All attempts end with an error message being emitted. I believe that this may be a non-issue. These 4 programs fail to compile. ! type t ! integer :: i = 42 ! end type ! type(t) s ! f(t) = 0 ! print *, f(s) ! end ! ! type t ! integer :: i = 42 ! end type ! type(t) s ! f(t) = t%i ! print *, f(s) ! end ! ! implicit none ! type t ! integer :: i = 42 ! end type ! type(t) s ! f(t) = t%i ! print *, f(s) ! end ! implicit none type t integer :: i = 42 end type type(t) s f(t) = 0 print *, f(s) end
[Bug target/50751] SH Target: Displacement addressing does not work for QImode and HImode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50751 --- Comment #1 from Kazumoto Kojima kkojima at gcc dot gnu.org 2011-10-17 00:29:55 UTC --- This is a known issue. See the comment just before sh.c:sh_legitimate_index_p. Unfortunately, I guess this PR might be marked as WONTFIX.
[Bug target/50749] SH Target: Post-increment addressing used only for first memory access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50749 --- Comment #2 from Kazumoto Kojima kkojima at gcc dot gnu.org 2011-10-17 00:32:39 UTC --- *** Bug 50750 has been marked as a duplicate of this bug. ***
[Bug target/50750] SH Target: Pre-decrement addressing used only for first memory access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50750 Kazumoto Kojima kkojima at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Kazumoto Kojima kkojima at gcc dot gnu.org 2011-10-17 00:32:39 UTC --- Looks duplicate of PR50749. *** This bug has been marked as a duplicate of bug 50749 ***
[Bug target/50751] SH Target: Displacement addressing does not work for QImode and HImode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50751 --- Comment #2 from Oleg Endo oleg.e...@t-online.de 2011-10-17 00:37:42 UTC --- (In reply to comment #1) This is a known issue. See the comment just before sh.c:sh_legitimate_index_p. Unfortunately, I guess this PR might be marked as WONTFIX. Yeah, I know this has been around for a while. I'd like to take my chances anyway :) Cheers, Oleg
[Bug target/50751] SH Target: Displacement addressing does not work for QImode and HImode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50751 --- Comment #3 from Kazumoto Kojima kkojima at gcc dot gnu.org 2011-10-17 00:51:15 UTC --- (In reply to comment #2) Yeah, I know this has been around for a while. I'd like to take my chances anyway :) Welcome to the spill-failure-for-class-'R0_REGS' club :-)
[Bug fortran/50540] Internal Error: Can't convert UNKNOWN to INTEGER(4) (r178939)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50540
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- Comment #1 from kargl at gcc dot gnu.org 2011-10-17 00:58:33 UTC ---
The internal error can be removed by changing the error
report. This patch downgrades the error from an internal
error to a standard error.
Index: resolve.c
===
--- resolve.c (revision 180062)
+++ resolve.c (working copy)
@@ -6415,14 +6415,14 @@ resolve_forall_iterators (gfc_forall_ite
gfc_error (FORALL start expression at %L must be a scalar INTEGER,
iter-start-where);
if (iter-var-ts.kind != iter-start-ts.kind)
- gfc_convert_type (iter-start, iter-var-ts, 2);
+ gfc_convert_type (iter-start, iter-var-ts, 1);
if (gfc_resolve_expr (iter-end) == SUCCESS
(iter-end-ts.type != BT_INTEGER || iter-end-rank != 0))
gfc_error (FORALL end expression at %L must be a scalar INTEGER,
iter-end-where);
if (iter-var-ts.kind != iter-end-ts.kind)
- gfc_convert_type (iter-end, iter-var-ts, 2);
+ gfc_convert_type (iter-end, iter-var-ts, 1);
if (gfc_resolve_expr (iter-stride) == SUCCESS)
{
@@ -6436,7 +6436,7 @@ resolve_forall_iterators (gfc_forall_ite
iter-stride-where);
}
if (iter-var-ts.kind != iter-stride-ts.kind)
- gfc_convert_type (iter-stride, iter-var-ts, 2);
+ gfc_convert_type (iter-stride, iter-var-ts, 1);
}
for (iter = it; iter; iter = iter-next)
The error message is then
laptop:kargl[251] gfc4x -c foo.f90
foo.f90:3.20:
forall (i=2:ix) dest(i)=i
1
Error: Symbol 'ix' at (1) has no IMPLICIT type
foo.f90:3.18:
forall (i=2:ix) dest(i)=i
1
Error: Can't convert UNKNOWN to INTEGER(4) at (1)
which I think is acceptable because when one fixes
the first error implicit typing of ix, then the
2nd message goes away.
[Bug target/50683] GCC compiles MPFR 3.1.0 wrongly on sparc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50683 --- Comment #6 from David S. Miller davem at davemloft dot net 2011-10-17 01:52:02 UTC --- I would suggest against a gcc workaround, let's just fix binutils. I have posted a fix to the binutils list for testing.
[Bug rtl-optimization/50489] [UPC/IA64] mis-schedule of MEM ref with -ftree-vectorize and -fschedule-insns2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50489 --- Comment #7 from Gary Funck gary at intrepid dot com 2011-10-17 03:04:08 UTC --- Do you have any suggestions on additional tests, debug steps that we can perform to narrow down the factors that lead to instructions being mis-scheduled?
[Bug middle-end/50724] isnan broken by -ffinite-math-only in g++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50724 Ethan Tira-Thompson ejtttje at gmail dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Comment #17 from Ethan Tira-Thompson ejtttje at gmail dot com 2011-10-17 04:12:31 UTC --- Richard said: math.h is not part of GCC But the point is there is value in consistency between math.h and cmath regardless of who owns math.h. I'm asserting that this value is greater than that gained by 'optimizing away' the classification functions in cmath. Inconsistency leads to confused users and therefore bugs, missed optimization is only going to cause slower code. I get that you want to make the most of -ffast-math, and if it were a big speedup it could be worthwhile, but it seems reasonable that if someone is serious about optimizing away their classification sanity checks in a release build, they would be better served by using assert() or an #ifdef instead of relying of the vagaries of -ffast-math for this purpose. The only way out I see that not breaks other users uses would be a new flag, like -fpreserve-ieee-fp-classification that, ontop of -ffinite-math-only, I'm not opposed to a new flag, but I'd suggest the reverse semantics. Disabling classification is an extra degree of non-compliance beyond ignoring non-finite math operations. I'd rather users add flags to progressively become less compliant, rather than add a flag to get some compliance back. But to rewind a second, I want to address the breaks other users comment... here is the status AFAIK: 1) Older versions (4.1, 4.2) of gcc did not do this optimization of classification functions. Thus, legacy code expects classification to work even in the face of -ffast-math, which was changed circa 4.3/4.4 2) Removing classification 'breaks' code because it fundamentally strips execution paths which may otherwise be used. 3) Leaving classification in could be considered a missed optimization, but is at worst only a performance penalty, not a change in execution values. 4) Personal conjecture: I doubt the classification routines are a performance bottleneck in the areas where -ff-m-o is being applied, so (3) is pretty minimal. And I seriously doubt anyone is relying on the removal of classification in a code-correctness context, that doesn't make any sense. Are we on the same page with these points? So if you are concerned with the breakage of existing code, isn't the solution to revert to the previous scope of the -ff-m-o optimization ASAP, and then if there is a desire to extend the finite-only optimization to classification functions, *that* would be a new feature request, perhaps with its own flag? (Note that they are folded to arithmetic, !(x==x), so that transform has to be disabled as well, and on some architectures you might get library calls because of this instead of inline expansions). I'd rather leave comparison optimizations as they are under -ff-m-o, that seems a sensible expectation of the 'arithmetic' scope, and is relatively well-known, long-standing effect of -ffast-math. It's only the 5 explicit fp classification calls which I think deserve protection to allow data validation in a non-hacky manner before doing core computations with the finite invariant. Unless you are saying things like std::isnan cannot be implemented separately from !(x==x)? That has not been my understanding.
