[Bug other/54398] Incorrect ARM assembly when building with -fno-omit-frame-pointer -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54398 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2012-09-11 06:09:13 UTC --- cselib.c has for this the various spots that special case HARD_FRAME_POINTER_REGNUM (or STACK_POINTER_REGNUM or FRAME_POINTER_REGNUM). Please see why that doesn't work in this case.
[Bug preprocessor/54528] [4.8 Regression] system.h:288:78: error: integer overflow in expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54528 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #2 from Mikael Pettersson mikpe at it dot uu.se 2012-09-11 07:21:57 UTC --- I got these errors too, when trying to bootstrap gcc-4.8-20120909 on m68k-linux using g++ 4.5.3 as the bootstrap compiler.
[Bug middle-end/54515] cc1plus sigsegv -O2 anonymous namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54515 --- Comment #10 from Richard Guenther rguenth at gcc dot gnu.org 2012-09-11 08:32:43 UTC --- Author: rguenth Date: Tue Sep 11 08:32:29 2012 New Revision: 191174 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=191174 Log: 2012-09-11 Richard Guenther rguent...@suse.de PR middle-end/54515 * gimple.c (get_base_address): Do not return NULL_TREE apart from for WITH_SIZE_EXPR. * gimple-fold.c (canonicalize_constructor_val): Do not call get_base_address when not necessary. * g++.dg/tree-ssa/pr54515.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/tree-ssa/pr54515.C Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-fold.c trunk/gcc/gimple.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/54515] cc1plus sigsegv -O2 anonymous namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54515 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||4.6.4, 4.7.2, 4.8.0 Resolution||FIXED Known to fail||4.6.3, 4.7.1 --- Comment #10 from Richard Guenther rguenth at gcc dot gnu.org 2012-09-11 08:32:43 UTC --- Author: rguenth Date: Tue Sep 11 08:32:29 2012 New Revision: 191174 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=191174 Log: 2012-09-11 Richard Guenther rguent...@suse.de PR middle-end/54515 * gimple.c (get_base_address): Do not return NULL_TREE apart from for WITH_SIZE_EXPR. * gimple-fold.c (canonicalize_constructor_val): Do not call get_base_address when not necessary. * g++.dg/tree-ssa/pr54515.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/tree-ssa/pr54515.C Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-fold.c trunk/gcc/gimple.c trunk/gcc/testsuite/ChangeLog --- Comment #11 from Richard Guenther rguenth at gcc dot gnu.org 2012-09-11 08:33:36 UTC --- Fixed.
[Bug middle-end/54515] cc1plus sigsegv -O2 anonymous namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54515 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||4.6.4, 4.7.2, 4.8.0 Resolution||FIXED Known to fail||4.6.3, 4.7.1 --- Comment #11 from Richard Guenther rguenth at gcc dot gnu.org 2012-09-11 08:33:36 UTC --- Fixed.
[Bug target/54546] New: SH: Enable -fshrink-wrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54546 Bug #: 54546 Summary: SH: Enable -fshrink-wrap Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: ch...@gcc.gnu.org Created attachment 28169 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28169 simple-return pattern Implement the simple_return pattern to enable shrink-wrapping, which is beneficial on SH when the prologue/epilogue is small enough or when not optimizing for size. Adding the sh_can_use_return_insn_p function so refinements based on epilogue size can be further added. However this exposes a -freorder-blocks-and-partition -fprofile-use regression in the testsuite with that must be investigated.
[Bug target/54546] SH: Enable -fshrink-wrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54546 chrbr at gcc dot gnu.org changed: What|Removed |Added Severity|normal |enhancement
[Bug c++/54545] diagnostic overflow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54545
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRMED |NEW
Last reconfirmed||2012-09-11
Ever Confirmed|0 |1
Severity|normal |enhancement
--- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-09-11
09:46:45 UTC ---
Confirmed.
t.C:1:15: error: expected '{' instead of '('
enum class d(a,b,c};
^
would be nice ;)
[Bug debug/54534] [4.7 Regression] Missing location for unused variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54534 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2012-09-11 09:49:27 UTC --- I am testing Index: gcc/cgraph.h === --- gcc/cgraph.h(revision 191174) +++ gcc/cgraph.h(working copy) @@ -951,7 +951,7 @@ varpool_can_remove_if_no_refs (struct va return (!node-force_output !node-used_from_other_partition ((DECL_COMDAT (node-decl) !varpool_used_from_object_file_p (node)) - || !node-externally_visible + || (flag_toplevel_reorder !node-externally_visible) || DECL_HAS_VALUE_EXPR_P (node-decl))); } which restores previous behavior.
[Bug debug/54534] [4.7 Regression] Missing location for unused variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54534 --- Comment #4 from Jan Hubicka hubicka at gcc dot gnu.org 2012-09-11 10:19:04 UTC --- Well, the patch really is quite symptomatic - i.e. dwarf2out should not forget about the decl when it is removed from varpool. The way things are supposed to work (I believe) is to call global_decl debug hook via emit_debug_global_declarations that is called from frontend at global decl wrapup time (i.e. the thing that is executed after whole compilation and should not be frontend specific :) I made some cleanups in this area as part of symtab work, but I do not see how those should affect the debug output...
[Bug c++/54403] [C++11] operator! applied to a member of a templated class in a lambda expression that captures 'this' pointer crashes compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54403 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-09-11 Ever Confirmed|0 |1
[Bug debug/54534] [4.7 Regression] Missing location for unused variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54534 --- Comment #5 from rguenther at suse dot de rguenther at suse dot de 2012-09-11 10:38:32 UTC --- On Tue, 11 Sep 2012, hubicka at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54534 --- Comment #4 from Jan Hubicka hubicka at gcc dot gnu.org 2012-09-11 10:19:04 UTC --- Well, the patch really is quite symptomatic - i.e. dwarf2out should not forget about the decl when it is removed from varpool. The way things are supposed to work (I believe) is to call global_decl debug hook via emit_debug_global_declarations that is called from frontend at global decl wrapup time (i.e. the thing that is executed after whole compilation and should not be frontend specific :) I made some cleanups in this area as part of symtab work, but I do not see how those should affect the debug output... The regression is that it prints optimized_out which it really is. But at -O0 we don't IMHO want unused decls to go away. Not sure why it doesn't regress on trunk - somehow the decl is output anyway. Richard.
[Bug debug/54534] [4.7 Regression] Missing location for unused variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54534 --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2012-09-11 10:43:17 UTC --- Author: rguenth Date: Tue Sep 11 10:43:13 2012 New Revision: 191176 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=191176 Log: 2012-09-11 Richard Guenther rguent...@suse.de PR debug/54534 * cgraph.h (varpool_can_remove_if_no_refs): Restore dependence on flag_toplevel_reorder. Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/cgraph.h
[Bug debug/54534] [4.7 Regression] Missing location for unused variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54534 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2012-09-11 10:43:17 UTC --- Author: rguenth Date: Tue Sep 11 10:43:13 2012 New Revision: 191176 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=191176 Log: 2012-09-11 Richard Guenther rguent...@suse.de PR debug/54534 * cgraph.h (varpool_can_remove_if_no_refs): Restore dependence on flag_toplevel_reorder. Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/cgraph.h --- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2012-09-11 10:43:40 UTC --- Fixed.
[Bug other/54398] Incorrect ARM assembly when building with -fno-omit-frame-pointer -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54398 --- Comment #7 from ramrad01 at arm dot com 2012-09-11 10:44:30 UTC --- On 09/11/12 07:09, jakub at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54398 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2012-09-11 06:09:13 UTC --- cselib.c has for this the various spots that special case HARD_FRAME_POINTER_REGNUM (or STACK_POINTER_REGNUM or FRAME_POINTER_REGNUM). Please see why that doesn't work in this case. This rings a bell. Maybe the patch mentioned below needs backporting given Carrot is reporting this against the 4.6 branch. What's not clear if this is reproducible on anything later though. http://old.nabble.com/-PATCH--Prevent-cselib-substitution-of-FP,-SP,-SFP-td33080657.html Full disclaimer that I've not investigated whether the same problem occurs on trunk. HTH, Ramana
[Bug debug/54534] [4.7 Regression] Missing location for unused variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54534 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED --- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2012-09-11 10:43:40 UTC --- Fixed.
[Bug c++/54548] New: unclear error message for ambiguous type lookup.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54548
Bug #: 54548
Summary: unclear error message for ambiguous type lookup.
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pl...@agmk.net
#include new
struct X;
namespace { struct X; }
int main()
{
new X();
}
a gcc error message is unreadable for end-user in case when
the first 'struct X' decl is hidden deeply in the #include forest.
$ LANG=C g++ -Wall t.cpp -c
t.cpp: In function 'int main()':
t.cpp:6:6: error: expected type-specifier before 'X'
t.cpp:6:6: error: expected ';' before 'X'
clang is more user-friendly and shows problem directly.
$ LANG=C clang++ -Wall t.cpp -c
t.cpp:6:6: error: reference to 'X' is ambiguous
new X();
^
t.cpp:2:8: note: candidate found by name lookup is 'X'
struct X;
^
t.cpp:3:20: note: candidate found by name lookup is 'anonymous namespace::X'
namespace { struct X; }
^
t.cpp:6:6: error: allocation of incomplete type 'X'
new X();
^
t.cpp:2:8: note: forward declaration of 'X'
struct X;
^
2 errors generated.
[Bug lto/54312] uniquify_nodes takes 12% of Mozilla LTO build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54312 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-09-11 11:03:52 UTC --- Patch pre-approved (also for 4.7) if it passes your testing.
[Bug middle-end/54149] write introduction incorrect wrt the C11 memory model
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54149 --- Comment #3 from Aldy Hernandez aldyh at gcc dot gnu.org 2012-09-11 12:28:11 UTC --- Author: aldyh Date: Tue Sep 11 12:28:02 2012 New Revision: 191179 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=191179 Log: PR middle-end/54149 * tree-ssa-loop-im.c (execute_sm_if_changed_flag_set): Only set flag for writes. Added: trunk/gcc/testsuite/gcc.dg/simulate-thread/speculative-store-4.c Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-loop-im.c
[Bug middle-end/54149] write introduction incorrect wrt the C11 memory model
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54149 Aldy Hernandez aldyh at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Aldy Hernandez aldyh at gcc dot gnu.org 2012-09-11 12:30:36 UTC --- fixed on trunk
[Bug ada/54549] New: Compilation Error : Assertion Failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54549 Bug #: 54549 Summary: Compilation Error : Assertion Failure Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: blocker Priority: P3 Component: ada AssignedTo: unassig...@gcc.gnu.org ReportedBy: webe...@gmail.com Created attachment 28170 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28170 The source code to be compiled. gnatmake -ws -c -u -P/home/someone/Projects/RTES_Train/rtes_train.gpr layout.ads gcc-4.6 -c -I- -gnatA /home/someone/Projects/RTES_Train/layout.ads +===GNAT BUG DETECTED==+ | 4.6.3 (i686-pc-linux-gnu) Assert_Failure sinfo.adb:2547 | | Error detected at layout.ads:9:4 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc-4.6 or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. Consider also -gnatd.n switch (see debug.adb). /home/someone/Projects/RTES_Train/layout.ads /home/someone/Projects/RTES_Train/bin/GNAT-TEMP-01.TMP /home/someone/Projects/RTES_Train/bin/GNAT-TEMP-02.TMP raised SYSTEM.ASSERTIONS.ASSERT_FAILURE : namet.adb:655 gnatmake: /home/someone/Projects/RTES_Train/layout.ads compilation error [2012-09-11 07:32:17] process exited with status 4 (elapsed time: 00.12s)
[Bug debug/54519] [4.6/4.7/4.8 Regression] Debug info quality regression due to (pointless) partial inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54519 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2012-09-11 13:26:54 UTC --- Created attachment 28171 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28171 gcc48-pr54519.patch Generic solution patch. This doesn't attempt to special case inlining of FN.part.N back into FN or FN inlined into BAR (which is going to be harder than I've initially thought, because both the (possibly inlined) FN and FN.part.N have originally full copy of the BLOCK tree of FN, after some optimizations in between fnsplit and inlining some of the BLOCKs or BLOCK_VARS in either or both of them might be removed though. So, expand_call_inline would probably need to avoid attaching remap_blocks as children of new BLOCK it creates, instead it should somehow merge the two BLOCK trees back into one (it could use BLOCK_ABSTRACT_ORIGIN to find the matching blocks, and for the blocks that already exist in FN just insert_decl_map from FN.part.N's BLOCK to corresponding FN BLOCK). Similarly BLOCK_VARS need to be handled by preferring to remap to vars in the caller FN BLOCK_VARS (just insert_decl_map those), and just re-add the rest that was dropped on the floor in the mean time. And it would need to drop some of the debug bind and debug source bind stmts for parameters that this patch adds. Several of the tests fail sometimes, I'm going to file a separate PR for that because the problem is during the first df_analyze.
[Bug fortran/50640] [4.7 Regression] [OOP] FAIL: gfortran.dg/select_type_12.f03 -O (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50640 --- Comment #26 from Tobias Burnus burnus at gcc dot gnu.org 2012-09-11 13:44:44 UTC --- The solution of comment 3, fixed by comment 24 seems to break the test case of PR fortran/53718. Reverting the patch (comment 24, except for unrelated class.c part) fixes the issue of PR 53718. For some reason, reverting the patch no longer triggers the issue of this PR, i.e. gfortran.dg/select_type_12.f03 gives no ICE. Hence, it seems as if comment 2 no longer applies. To recap (rough version): gfortran generates in MAIN__ the nested function __copy_MAIN___T1 and assigns it (function pointer) to a field of the static struct __vtab_MAIN___T1. But __copy_MAIN___T1 does not get called in MAIN__ but only in foo which is also a nested function of MAIN__ - thus, __vtab_MAIN___T1 didn't get marked as referenced, causing the ICE. The patch in comment 24 hoisted the __copy_MAIN___T1 out of MAIN__ into the TU space. Does anyone see a reason why the patch shouldn't be revered? (I assume one of Richard's patches in May fixed the issue. That probably means that one has to find another solution for 4.7. Suggestions?) Comments - especially from the middle-end side?
[Bug fortran/53718] [4.7/4.8 regression] [OOP] gfortran generates asm label twice in the same output file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53718 --- Comment #10 from Tobias Burnus burnus at gcc dot gnu.org 2012-09-11 13:47:59 UTC --- (In reply to comment #7) (In reply to comment #6) Could it be revision 181505? Very likely. If it is, I'm betting on the PR50640 part of that commit. Indeed the following patch, which is practically a revert of the trans-decl.c part of the above commit, makes the errors go away: We should backout everything - except for the class.c part of the commit in bug 50640 comment 24. My suspicious is that one of Richard's commits in May fixed the issue. In turn that probably means that backing out the patch for PR50640 only works for 4.7 and not for 4.8 See also some comments/analysis/RFC at bug 50640 comment 26.
[Bug c/54550] New: GCC -O3 breaks floating point equality comparison
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54550 Bug #: 54550 Summary: GCC -O3 breaks floating point equality comparison Classification: Unclassified Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: veio...@gmail.com 32-bit X86 on Linux. First of all, this is not one of those bug reports that states that floating point is implemented differently on different platforms. This is the same C source on the same platform. Secondly, this isn't a blanket statement. It happens in a very specific set of circumstances. If there's interest from this forum, then I'll try to hack together a demo. Doing so is nontrivial due to the sensitive (to surrounding code) nature of the bug, and my inability to upload my entire source. Here's the bug, from a high level perspective: 1. Fill a list with a bunch of random (but valid) 64-bit double-precision values. 2. Sort the list from negative to positive, to another list. 3. For each random value in the first list, scan through the second (sorted) list to find it, using floating point comparison for equality. This should work because numbers are bit-for-bit identical to the original list. (Only the order of the numbers is different between the lists.) 4. If you find any value which is not on the list, print an error. With -O2, it's fine. With -O3, it prints an error. However, if I use 80-bit long double precision, it works again with -O3. I suspect that, at higher optimization levels, GCC is caching doubles in X87 registers. That's great, but somehow equality comparison is getting messed up under _some_ scenarios. When I print out the values that are different, they're identical, down to the bit. Again, no math is done on any of these values after generating them. It's purely loads and stores. It's worth noting that, if instead of -O3, I do -O2 and add all the command line options that -O3 enables beyond -O2 _except_ for -finline_functions, then it also works fine. I suspect that function inlining, in this case, causes the above register caching issue to break equality comparison, probably because the compiler is inlining the search function in step 3. Maybe there's some subtle spec violation here, i.e. maybe floating point equality is somehow illegitimate. If it is, sorry for submitting this bug.
[Bug tree-optimization/52445] [4.6 Regression] conditional store replacement causes segfault in generated code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52445 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #13 from Mikael Pettersson mikpe at it dot uu.se 2012-09-11 14:21:09 UTC --- Could this be applied to gcc-4.6.4 please? A recently reported miscompilation of a device driver in the Linux/ARM kernel by gcc-4.6.3 was traced to this bug. Applying the trunk patch to 4.6.3 fixed that test case. FWIW, I've been using and testing this fix in my own 4.6-based branch since early March, on multiple targets, without regressions.
[Bug debug/54551] New: DF resets some DEBUG_INSNs unnecessarily
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54551
Bug #: 54551
Summary: DF resets some DEBUG_INSNs unnecessarily
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
CC: aol...@gcc.gnu.org, hubi...@gcc.gnu.org,
jan.kratoch...@redhat.com, m...@gcc.gnu.org,
rgue...@gcc.gnu.org
Depends on: 54519
+++ This bug was initially created as a clone of Bug #54519 +++
Several of the PR54519 tests fail. The problem can be reproduced even without
any partial inlining though, e.g. on:
void bar (void);
int
foo (int x, int y, int z)
{
if (x != z)
{
int a = z + 8;
bar ();
bar ();
}
return y;
}
at -g -O2. At *.dfinit we still have:
(insn 4 3 5 2 (set (reg/v:SI 62 [ z ])
(reg:SI 1 dx [ z ])) vu.c:5 65 {*movsi_internal}
(nil))
(note 5 4 8 2 NOTE_INSN_FUNCTION_BEG)
(insn 8 5 9 2 (set (reg:CCZ 17 flags)
(compare:CCZ (reg/v:SI 60 [ x ])
(reg/v:SI 62 [ z ]))) vu.c:6 7 {*cmpsi_1}
(nil))
(jump_insn 9 8 10 2 (set (pc)
(if_then_else (eq (reg:CCZ 17 flags)
(const_int 0 [0]))
(label_ref 14)
(pc))) vu.c:6 595 {*jcc_1}
(expr_list:REG_BR_PROB (const_int 3784 [0xec8])
(nil))
- 14)
(note 10 9 11 3 [bb 3] NOTE_INSN_BASIC_BLOCK)
(debug_insn 11 10 12 3 (var_location:SI a (plus:SI (reg/v:SI 62 [ z ])
(const_int 8 [0x8]))) vu.c:8 -1
(nil))
but during CSE1 when fast DCE is performed, the debug insn for a is reset, as
pseudo 62 isn't live in that basic block. We have the valtrack.c
infrastructure for this kind of things, but that apparently works only within
basic blocks, while in this case we have a BB (2) where the pseudo dies and a
BB (3) that is dominated by that BB and has a debug insn using that pseudo.
Perhaps in further RTL passes that use DF that is sufficient, but the first
time DF liveness is computed as this testcase or PR54519 shows we drop on the
floor debug insns that could still refer to debug temporaries if we initialized
them in the bbs where they die and that dominate the debug uses. For this
particular testcase it could still live in %edx on the first call bar insn,
then in DW_OP_GNU_entry_value (%edx).
Alex, what do you think about this?
[Bug fortran/53957] Polyhedron 11 benchmark: MP_PROP_DESIGN twice as long as other compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53957 --- Comment #10 from Richard Guenther rguenth at gcc dot gnu.org 2012-09-11 15:02:00 UTC --- There are a lot more reasons why we do not vectorize this loop :(
[Bug libstdc++/54172] [4.7 Regression] __cxa_guard_acquire thread-safety issue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54172 --- Comment #16 from Jakub Jelinek jakub at gcc dot gnu.org 2012-09-11 15:23:01 UTC --- Author: jakub Date: Tue Sep 11 15:22:54 2012 New Revision: 191190 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=191190 Log: PR libstdc++/54172 * libsupc++/guard.cc (__cxa_guard_acquire): Fix up the last argument of the first __atomic_compare_exchange_n. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/libsupc++/guard.cc
[Bug libstdc++/54172] [4.7 Regression] __cxa_guard_acquire thread-safety issue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54172 --- Comment #16 from Jakub Jelinek jakub at gcc dot gnu.org 2012-09-11 15:23:01 UTC --- Author: jakub Date: Tue Sep 11 15:22:54 2012 New Revision: 191190 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=191190 Log: PR libstdc++/54172 * libsupc++/guard.cc (__cxa_guard_acquire): Fix up the last argument of the first __atomic_compare_exchange_n. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/libsupc++/guard.cc --- Comment #17 from Jakub Jelinek jakub at gcc dot gnu.org 2012-09-11 15:24:12 UTC --- Author: jakub Date: Tue Sep 11 15:24:06 2012 New Revision: 191191 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=191191 Log: PR libstdc++/54172 * libsupc++/guard.cc (__cxa_guard_acquire): Fix up the last argument of the first __atomic_compare_exchange_n. Modified: branches/gcc-4_7-branch/libstdc++-v3/ChangeLog branches/gcc-4_7-branch/libstdc++-v3/libsupc++/guard.cc
[Bug libstdc++/54172] [4.7 Regression] __cxa_guard_acquire thread-safety issue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54172 --- Comment #17 from Jakub Jelinek jakub at gcc dot gnu.org 2012-09-11 15:24:12 UTC --- Author: jakub Date: Tue Sep 11 15:24:06 2012 New Revision: 191191 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=191191 Log: PR libstdc++/54172 * libsupc++/guard.cc (__cxa_guard_acquire): Fix up the last argument of the first __atomic_compare_exchange_n. Modified: branches/gcc-4_7-branch/libstdc++-v3/ChangeLog branches/gcc-4_7-branch/libstdc++-v3/libsupc++/guard.cc
[Bug c/54550] GCC -O3 breaks floating point equality comparison
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54550 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-09-11 15:34:59 UTC --- Have you read http://gcc.gnu.org/bugs/#nonbugs_general and PR 323?
[Bug c/54550] GCC -O3 breaks floating point equality comparison
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54550 Michael Matz matz at gcc dot gnu.org changed: What|Removed |Added CC||matz at gcc dot gnu.org --- Comment #2 from Michael Matz matz at gcc dot gnu.org 2012-09-11 15:46:08 UTC --- In particular your speculation about the x87 registers is most probably right. If so, it's a known deficiency in the 32bit x86 backend, and you should be able to work around this with -ffloat-store. We have no intention to change this behaviour in GCC.
[Bug c/54550] GCC -O3 breaks floating point equality comparison
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54550 --- Comment #3 from Michael Matz matz at gcc dot gnu.org 2012-09-11 15:48:10 UTC --- Or with the more recent -fexcess-precision=standard option.
[Bug fortran/53718] [4.7/4.8 regression] [OOP] gfortran generates asm label twice in the same output file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53718 --- Comment #11 from janus at gcc dot gnu.org 2012-09-11 15:57:35 UTC --- (In reply to comment #10) My suspicious is that one of Richard's commits in May fixed the issue. In turn that probably means that backing out the patch for PR50640 only works for 4.7 and not for 4.8 I assume you mean the other way around, right? The patch of comment 7 *does* work on trunk. I just checked that applying it on the 4.7 branch revives the old ICE on select_type_12. So, should we apply the patch only on trunk for now?
[Bug tree-optimization/54492] [4.8 Regression] SLSR takes ages
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54492 William J. Schmidt wschmidt at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #2 from William J. Schmidt wschmidt at gcc dot gnu.org 2012-09-11 16:00:11 UTC --- Fixed with r191178. I apparently typoed the PR number in the ChangeLog.
[Bug c/54552] New: Cast to pointer to VLA crash the compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54552 Bug #: 54552 Summary: Cast to pointer to VLA crash the compiler Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: jens.gust...@loria.fr Created attachment 28172 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28172 code to reproduce the problem I stumbled int to a case where a cast (double(*)[n]) crashes the compiler, whereas first having a typedef for the VLA works ok. I attach code that reproduces the problem for me. The bug is present as well in gcc 4.6.3 as in 4.7.0. This is on an ubuntu x86_64, but I don't think that this should matter. Jens
[Bug c/54552] Cast to pointer to VLA crash the compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54552 --- Comment #1 from Jens Gustedt jens.gustedt at loria dot fr 2012-09-11 16:11:59 UTC --- The compiler error is test-p99-gcc-bug.c:9:6: internal compiler error: in gimplify_expr, at gimplify.c:7584
[Bug c/54552] [4.6/4.7/4.8 Regression] Cast to pointer to VLA crash the compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54552 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-09-11 CC||jakub at gcc dot gnu.org Target Milestone|--- |4.6.4 Summary|Cast to pointer to VLA |[4.6/4.7/4.8 Regression] |crash the compiler |Cast to pointer to VLA ||crash the compiler Ever Confirmed|0 |1 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2012-09-11 16:18:17 UTC --- Fails since http://gcc.gnu.org/viewcvs?root=gccview=revrev=145254
[Bug middle-end/54544] Option -Wuninitialized does not work as documented with volatile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54544
Zakhar jimfr06 at gmail dot com changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |
--- Comment #3 from Zakhar jimfr06 at gmail dot com 2012-09-11 16:41:43 UTC
---
On second thoughs, I reopen the issue!
WHY:
---
The 'correction' of the code above is a contrary to what the function intended
to do and thus breaks its logic: the declaration in the second version of the
code are inconsistent with what the function was intented to. That is because,
I suppose, the message gcc delivers and its correction are not OK with what
really happens.
FURTHER EXPLANATIONS:
-
You are right Andrew, the variable 'bar' is indeed (first version of the code)
a 'pointer to a volatile memory location' (location of an int).
*And that was intended so*.
The code is a simplification of a 'memory protection algorithm' where the int
that is pointed represents the count of threads using a given piece of memory.
This count being accessed from several threads, is indeed volatile as no thread
can assume the value didn't change from last time it read/wrote the value.
(atomic instructions where removed from the code example).
The pointer itself is not at all volatile. Anyway, once it is passed to the
function, it sits on the stack where its value should be unchanged as long a
the function lives, and same goes for the 'bar' automatic variable. I'm not
doing crazy threaded things on variables on the stack of this function!
I was confused by the warning message saying:
'bar' may be used uninitialized in this function
... because the message is indeed confusing. 'bar' is NOT used uninitialized
(as demonstrated) but the *content pointed by 'bar'* could be. I must confess
that I didn't look from far enough to interpret the message this way.
HYPOTHESIS:
---
So could it be that gcc saw that, and warns incorrectly on 'bar' instead of
'*bar'?
If so, yes, because the function receives a pointer to a memory location, the
function itself cannot know whether the location pointed to was initialized or
not. 'bar' gets the same address ( bar = p ) thus, indeed, the location pointed
by 'bar' could be un-initialized.
This could also be coherent with the fact that when we change the function to
static, the warning disappears. Being static, all the callers have to be on the
same source, thus the compiler can check if the callers initialize properly the
content memory pointed to.
But then, shouldn't the message be:
'*bar' may be used uninitialized in this function.
And that would indeed be correct, because '*bar' being the memory pointed to by
bar, could indeed be un-initialized (if the caller didn't initialize it).
And thus, the compiler would do a good job signaling that, as '*bar' (memory
which bar points to) is declared as volatile, but it is NOT an automatic
variable (the pointer is, not the memory pointed to).
My hypothesis is probably wrong, because if gcc warned about un-initialized
memory pointed to, it would have to warn on that:
/*01*/ int
/*02*/ foo( p )
/*03*/ int *p;
/*04*/ {
/*05*/ int foobar;
/*06*/
/*07*/ foobar= *p;
/*08*/
/*09*/ return foobar + 2;
/*10*/ }
(we don't know if '*p' has ever been initialized).
And this short code snipet produces no warning at all, which is fine because a
lot of code do that (passing variable 'by reference'), and it is perfectly
correct not to warn.
CONCLUSION:
--
As previously concluded, it is not strictly a 'bug' as the documentation
perfectly states that in some case the dectection is broken, but I assume this
issue can go in the general thread better wuninitialized.
- either gcc saw that '*bar' is uninitialized and should report that (and not
report the pointer instead)
- or gcc saw 'bar' (the pointer) to be unitialized, and that is a test case
where it can do better work, as we can demonstrate it IS initialized.
VERSION 3 of the code:
-
Of course, NOT to break my program logic, the correct declaration of the
variable should be:
/*09*/ volatile int * volatile bar;
The 1st 'volatile' because indeed the memory we point to MUST be declared as
volatile.
The 2nd 'volatile' to suppress the 'false positive' detection on the pointer.
QUESTION @Andrew:
Should I post something on the general thread better wuninitialized (unless
my deductions are wrong again), or do you attach the use case directly from
this bug report?
[Bug gcov-profile/54487] [4.8 Regression] profiledbootstrap broken by r190952
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54487 --- Comment #16 from Teresa Johnson tejohnson at google dot com 2012-09-11 17:24:58 UTC --- On Thu, Sep 6, 2012 at 10:18 PM, Teresa Johnson tejohn...@google.com wrote: On Thu, Sep 6, 2012 at 1:49 PM, hjl.tools at gmail dot com gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54487 --- Comment #13 from H.J. Lu hjl.tools at gmail dot com 2012-09-06 20:49:02 UTC --- It works for me now after syncing with revision 191037. Unfortunately, I have now hit this myself a couple times in further testing, so I am still digging... After digging into this for several days now, I am convinced that the gcda file is changing out from underneath the profile-use compile during the read. I just don't understand how, since fcntl is being used to lock the file. Details below. I am hoping someone has some ideas or advice on where to go. First, some info on the compile step and gcda file locking, then I will explain why I belive the gcda file is being written mid-read. The failure is occurring sporadically during the profile-use step of a parallel profiledbootstrap. In this step, not only are the gcc profiles being read in by the profile-use compilation, but the gcc binaries being used in the compile are instrumented, so the gcda files are also being written by the parallel build processes. However, the fcntl file locking should prevent interference between the reads and the writes of the same gcda file. According to the fcntl documentation, the lock is lost on any fclose on the file by the same process, even if it uses a different file descriptor. But for a given profile use compile, the read step should be complete before the write step when the gcc exits and updates the gcda files with libgcov. So I don't think the lock should be lost this way. The failure is not reproducible manually. Therefore, I have been adding instrumentation to the compiler to spit out information at both the point of failure (error: corrupted profile info: edge from 54 to 55 exceeds maximal count from read_profile_edge_counts()), and then at the point when the gcda counts are being read in by read_counts_file(). This is the loop that looks like: for (ix = 0; ix != n_counts; ix++) entry-counts[ix] += gcov_read_counter (); I modified the above loop to check each count as it is read in against the sum_max, and if it exceeds sum_max to print the summary and counters at that point. I then compared this to the counters obtained for that function from a gcov-dump of the gcda file afterwards. The counters in the gcda file from gcov-dump are slightly higher because of subsequent merges into it by other parallel builds before compilation aborts, but it is still fairly easy to correlate the counter values between them. What I found is that the counter values being read by read_counts_file look good up to a certain point, and then they go bad. Looking at the huge bad values in hex, they are actually valid values from the gcda file, but it looks like we suddenly jumped back or ahead several locations. So for example, in some cases where it looks like we suddenly jumped ahead in the gcda file, I see that some of the last counter values being read into the array as counters are actually the tag values from just after the counter array in the gcda file. Or in some cases, the counter values are being read mis-aligned by one word, so they look huge because instead of having 0x in the most significant of the 2 counter words, the 0x is in the least significant of the 2 counter words. In other words, we jumped some odd number of words ahead (or behind) in the gcda file. If another process is writing into the gcda file at the same time, this could happen. Specifically, since the histogram now included in the gcda file summaries with my patch only write non-zero values, after a merge the size of the histogram, and therefore the size of the summaries, could change. This will cause the starting offsets of different tags/sections throughout the rest of the gcda file to shift. This shouldn't be a problem if the file locking is working though. But if the file locking is not working, then that would explain why suddenly during the read we suddenly seem to jump to a different spot. A couple of other notes: - I added some code after each counter read in the above loop to seek back to the offset where we read the tag, re-read it, and compare it to the tag we read earlier (then re-seek back to the current location in the counter array before continuing the read). Normally this check succeeds, but in the cases where I am hitting the above errors, the tag at that location has changed to something that doesn't look like a tag. - Jumping to a different spot should corrupt the reads of the rest of the file. But the main loop in read_counts_file will simply ignore any tag it doesn't understand, and exits when it reads a '0' tag. That's why there was no
[Bug gcov-profile/54487] [4.8 Regression] profiledbootstrap broken by r190952
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54487 --- Comment #17 from H.J. Lu hjl.tools at gmail dot com 2012-09-11 17:29:15 UTC --- Thanks for looking into it. This is a long standing problem. I have seen random profiledbootstrap failures for a long time.
[Bug gcov-profile/54487] [4.8 Regression] profiledbootstrap broken by r190952
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54487 --- Comment #18 from Teresa Johnson tejohnson at google dot com 2012-09-11 17:39:00 UTC --- On Tue, Sep 11, 2012 at 10:29 AM, hjl.tools at gmail dot com gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54487 --- Comment #17 from H.J. Lu hjl.tools at gmail dot com 2012-09-11 17:29:15 UTC --- Thanks for looking into it. This is a long standing problem. I have seen random profiledbootstrap failures for a long time. Thanks for confirming that this has happened prior. Unfortunately the addition of the histogram is likely making this more frequent, due to the changing summary sizes after merging. One way to deal with this for now might be to write all histogram entries (even the 0 ones) into the summary to keep the size static. Honza, what do you think? Teresa -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug gcov-profile/54487] [4.8 Regression] profiledbootstrap broken by r190952
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54487 --- Comment #19 from davidxl at google dot com 2012-09-11 17:44:29 UTC --- How much saving do we get by not writing out the 0 entries? With the proposed change, how less frequent is the problem occuring? David On Tue, Sep 11, 2012 at 10:38 AM, Teresa Johnson tejohn...@google.com wrote: On Tue, Sep 11, 2012 at 10:29 AM, hjl.tools at gmail dot com gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54487 --- Comment #17 from H.J. Lu hjl.tools at gmail dot com 2012-09-11 17:29:15 UTC --- Thanks for looking into it. This is a long standing problem. I have seen random profiledbootstrap failures for a long time. Thanks for confirming that this has happened prior. Unfortunately the addition of the histogram is likely making this more frequent, due to the changing summary sizes after merging. One way to deal with this for now might be to write all histogram entries (even the 0 ones) into the summary to keep the size static. Honza, what do you think? Teresa -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413
[Bug gcov-profile/54487] [4.8 Regression] profiledbootstrap broken by r190952
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54487 --- Comment #20 from Teresa Johnson tejohnson at google dot com 2012-09-11 18:05:13 UTC --- On Tue, Sep 11, 2012 at 10:44 AM, Xinliang David Li davi...@google.com wrote: How much saving do we get by not writing out the 0 entries? With the proposed change, how less frequent is the problem occuring? Let me get back with some stats. Each histogram entry requires 5 words, and there are a max of 252 entries. In the few cases I checked just now, we were printing about 60 entries per summary, with 3 summaries per gcda file. So printing the whole thing in these cases would require 5*(252-60)*3 = 2880 extra words, or 11520 bytes. Unfortunately, that is a significant increase over the current sizes of those files, which are currently only double or triple that. I also need to verify that changing this would reduce the frequency. A couple other possibilities since this is not frequent: - change the existing error to a warning (as we do under flag_profile_correction) - after finishing reading the counts, re-read the tag as I am doing in my debugging, and if it is no longer valid, throw everything away and re-read the file. - check the counters after reading each one, and if it is sum_max, ignore it and abort the profile read with a warning but continue compiling. Obviously the best solution would be to figure out how the lock is being lost/ignored and fix that, but that may take some time. Teresa David On Tue, Sep 11, 2012 at 10:38 AM, Teresa Johnson tejohn...@google.com wrote: On Tue, Sep 11, 2012 at 10:29 AM, hjl.tools at gmail dot com gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54487 --- Comment #17 from H.J. Lu hjl.tools at gmail dot com 2012-09-11 17:29:15 UTC --- Thanks for looking into it. This is a long standing problem. I have seen random profiledbootstrap failures for a long time. Thanks for confirming that this has happened prior. Unfortunately the addition of the histogram is likely making this more frequent, due to the changing summary sizes after merging. One way to deal with this for now might be to write all histogram entries (even the 0 ones) into the summary to keep the size static. Honza, what do you think? Teresa -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413
[Bug gcov-profile/54487] [4.8 Regression] profiledbootstrap broken by r190952
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54487 --- Comment #21 from davidxl at google dot com 2012-09-11 18:08:26 UTC --- Assuming the size of histogram for the same file does not vary that much, is it better to round the size to the next power of 2 -- 60 entries will need print out 64 etc? David On Tue, Sep 11, 2012 at 11:04 AM, Teresa Johnson tejohn...@google.com wrote: On Tue, Sep 11, 2012 at 10:44 AM, Xinliang David Li davi...@google.com wrote: How much saving do we get by not writing out the 0 entries? With the proposed change, how less frequent is the problem occuring? Let me get back with some stats. Each histogram entry requires 5 words, and there are a max of 252 entries. In the few cases I checked just now, we were printing about 60 entries per summary, with 3 summaries per gcda file. So printing the whole thing in these cases would require 5*(252-60)*3 = 2880 extra words, or 11520 bytes. Unfortunately, that is a significant increase over the current sizes of those files, which are currently only double or triple that. I also need to verify that changing this would reduce the frequency. A couple other possibilities since this is not frequent: - change the existing error to a warning (as we do under flag_profile_correction) - after finishing reading the counts, re-read the tag as I am doing in my debugging, and if it is no longer valid, throw everything away and re-read the file. - check the counters after reading each one, and if it is sum_max, ignore it and abort the profile read with a warning but continue compiling. Obviously the best solution would be to figure out how the lock is being lost/ignored and fix that, but that may take some time. Teresa David On Tue, Sep 11, 2012 at 10:38 AM, Teresa Johnson tejohn...@google.com wrote: On Tue, Sep 11, 2012 at 10:29 AM, hjl.tools at gmail dot com gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54487 --- Comment #17 from H.J. Lu hjl.tools at gmail dot com 2012-09-11 17:29:15 UTC --- Thanks for looking into it. This is a long standing problem. I have seen random profiledbootstrap failures for a long time. Thanks for confirming that this has happened prior. Unfortunately the addition of the histogram is likely making this more frequent, due to the changing summary sizes after merging. One way to deal with this for now might be to write all histogram entries (even the 0 ones) into the summary to keep the size static. Honza, what do you think? Teresa -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413 -- Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413
[Bug gcov-profile/54487] [4.8 Regression] profiledbootstrap broken by r190952
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54487 --- Comment #22 from H.J. Lu hjl.tools at gmail dot com 2012-09-11 18:10:55 UTC --- (In reply to comment #20) Obviously the best solution would be to figure out how the lock is being lost/ignored and fix that, but that may take some time. Can we use a lockfile to verify that fcntl lock is working correctly?
[Bug gcov-profile/54487] [4.8 Regression] profiledbootstrap broken by r190952
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54487 --- Comment #23 from Markus Trippelsdorf markus at trippelsdorf dot de 2012-09-11 18:14:52 UTC --- gcc/gcov-io.h has: #if defined (HOST_HAS_F_SETLKW) #define GCOV_LOCKED 1 #else #define GCOV_LOCKED 0 #endif But HOST_HAS_F_SETLKW isn't defined anywhere else AFAICS: gcc % git grep HOST_HAS_F_SETLKW gcc/gcov-io.h:#if defined (HOST_HAS_F_SETLKW) gcc %
[Bug fortran/53306] [4.6/4.7/4.8 Regression] ICE on invalid 'array(*) =' statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53306 --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-09-11 18:16:59 UTC --- This PR is fixed by the patch at http://gcc.gnu.org/ml/fortran/2012-09/msg00035.html for pr54225. Isn't it a duplicate?
[Bug fortran/54225] [4.6/4.7/4.8 Regression] fortran compiler segfault processing ' print *, A(1,*) '
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54225 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-09-11 18:19:29 UTC --- This PR seems to be a duplicate of pr53306.
[Bug middle-end/54550] GCC -O3 breaks floating point equality comparison
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54550 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Target|32-bit X86 on Linux |i?86-*-* Status|UNCONFIRMED |WAITING Last reconfirmed||2012-09-11 Component|c |middle-end Ever Confirmed|0 |1 --- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org 2012-09-11 18:48:50 UTC --- And we need a testcase.
[Bug gcov-profile/54487] [4.8 Regression] profiledbootstrap broken by r190952
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54487 --- Comment #24 from Teresa Johnson tejohnson at google dot com 2012-09-11 18:57:05 UTC --- On Tue, Sep 11, 2012 at 11:14 AM, markus at trippelsdorf dot de gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54487 --- Comment #23 from Markus Trippelsdorf markus at trippelsdorf dot de 2012-09-11 18:14:52 UTC --- gcc/gcov-io.h has: #if defined (HOST_HAS_F_SETLKW) #define GCOV_LOCKED 1 #else #define GCOV_LOCKED 0 #endif But HOST_HAS_F_SETLKW isn't defined anywhere else AFAICS: gcc % git grep HOST_HAS_F_SETLKW gcc/gcov-io.h:#if defined (HOST_HAS_F_SETLKW) gcc % Maybe it is as simple as that?! I thought I saw that GCOV_LOCKED was set for my compile, but that may have been on the libgcov compile. In fact, just above the code Markus shows from gcov-io.h, when IN_LIBGCOV, GCOV_LOCKED is set based on TARGET_POSIX_IO: #if defined (TARGET_POSIX_IO) #define GCOV_LOCKED 1 #else #define GCOV_LOCKED 0 #endif Indeed, when I look at the preprocessed libgcov.c output from its compile command, the GCOV_LOCKED is clearly set (by looking at the preprocessed gcov_open() code). But when I use the compile command for coverage.c, which includes gcov-io.c but is !IN_LIBGCOV (so GCOV_LOCKED is set based on HOST_HAS_F_SETLKW), the preprocessed gcov_open code is that of a !GCOV_LOCKED compile, without the call to fcntl. So perhaps it is just the case that the libgcov code is that writes the gcda files is doing the locking, but the read on profile-use is not! Anyone know how HOST_HAS_F_SETLKW was supposed to be set? I do see that my configure is setting HAVE_FCNTL_H, perhaps that was intended? Teresa -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug gcov-profile/54487] [4.8 Regression] profiledbootstrap broken by r190952
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54487 --- Comment #25 from Jakub Jelinek jakub at gcc dot gnu.org 2012-09-11 18:58:59 UTC --- Indeed, seems http://gcc.gnu.org/ml/gcc-patches/2003-05/msg00571.html has introduced use of that macro, but didn't bother to actually define it anywhere.
[Bug gcov-profile/54487] [4.8 Regression] profiledbootstrap broken by r190952
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54487
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #26 from Jakub Jelinek jakub at gcc dot gnu.org 2012-09-11
19:04:47 UTC ---
For the check, I guess you want to check that you can actually compile on host
something like:
#include fcntl.h
int
main ()
{
struct flock fl;
fl.l_whence = 0;
fl.l_start = 0;
fl.l_len = 0;
fl.l_pid = 0;
return fcntl (1, F_SETLKW, fl);
}
[Bug gcov-profile/54487] [4.8 Regression] profiledbootstrap broken by r190952
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54487
--- Comment #27 from Teresa Johnson tejohnson at google dot com 2012-09-11
19:08:07 UTC ---
Thanks for the pointers, Jakub. I'll work on adding this check.
Teresa
On Tue, Sep 11, 2012 at 12:04 PM, jakub at gcc dot gnu.org
gcc-bugzi...@gcc.gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54487
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #26 from Jakub Jelinek jakub at gcc dot gnu.org 2012-09-11
19:04:47 UTC ---
For the check, I guess you want to check that you can actually compile on host
something like:
#include fcntl.h
int
main ()
{
struct flock fl;
fl.l_whence = 0;
fl.l_start = 0;
fl.l_len = 0;
fl.l_pid = 0;
return fcntl (1, F_SETLKW, fl);
}
--
Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
[Bug target/40836] ICE: insn does not satisfy its constraints (iwmmxt_movsi_insn)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40836 --- Comment #31 from Daniel Drake dsd at laptop dot org 2012-09-11 19:11:27 UTC --- Created attachment 28173 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28173 preprocessed source that crashes Another preprocessed source example that shows this crasher, from glibc gconv_cache compilation. Compile with: gcc -march=iwmmxt -O3 -c test.c Note: -O3 is needed to cause the crash, with -O2 it compiles OK.
[Bug middle-end/54544] Option -Wuninitialized does not work as documented with volatile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54544
--- Comment #4 from Zakhar jimfr06 at gmail dot com 2012-09-11 21:09:28 UTC
---
MORE
Unfortunately, I don't think the hypothesis of the uninitialized pointed memory
hold. That should prove it if we add:
/*01*/ int fct(volatile int *p);
/*02*/
/*03*/ static int
/*04*/ foo( p )
/*05*/ volatile int * p;
/*06*/ {
/*07*/ volatile int foobar,barfoo;
/*08*/ volatile int flag=0;
/*09*/ volatile int * bar;
/*10*/
/*11*/ do
/*12*/ {
/*13*/ if ( *p )
/*14*/ {
/*15*/ flag= fct( p );
/*16*/ bar = p;
/*17*/ }
/*18*/ if ( fct( p ) ) break;
/*19*/ if ( flag )
/*20*/ {
/*21*/ barfoo = *bar;
/*22*/ if ( bar == (int *)0 ) break;
/*23*/ foobar = *bar;
/*24*/ return foobar + barfoo;
/*25*/ }
/*26*/ }
/*27*/ while ( fct( p ) );
/*28*/
/*29*/ return 0;
/*30*/ }
/*31*/
/*32*/ int
/*33*/ main()
/*34*/ {
/*35*/ int i;
/*35*/
/*37*/ return foo( i );
/*38*/
/*40*/ }
Here 'main' calls the 'foo' function with a pointer to a variable which for
sure is NOT initialized, and there is no warning whatsoever when we compile
with:
$ gcc -O3 -c uninit.c -o /dev/null -Wall
In this example, if we go to line 23, for sure the result of the returned value
is totally unpredictable as it depends on the value of 'i' in the main
function.
'i' is on the stack, and has not been initialized, so it gets any value that
was there previously on the stack!
If we remove 'static' in front of the function, this time we get our warning
back... but probably a 'false positive' on 'bar', and not related to tracking
down pointed memory.
In this new use-case, if we add 'inline' after static (which -O3 should do by
itself here?) we are for sure doing something wrong.
Shouldn't -WUninitialized output something instead of remaining silent?
[Bug debug/54551] DF resets some DEBUG_INSNs unnecessarily
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54551 --- Comment #1 from Alexandre Oliva aoliva at gcc dot gnu.org 2012-09-11 21:20:11 UTC --- I guess we have to somehow local all death points of the pseudo in paths towards the debug use, and insert debug insns binding the same debug temp to the pseudo before all of the death points, then replace the debug use with a use of the debug temp. I'm not sure how well this fits in the general structure of the DF machinery. Presumably we just need to look up a table of (lists of?) debug temps as we reach death points.
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 Larry Baker baker at usgs dot gov changed: What|Removed |Added Attachment #28165|0 |1 is obsolete|| --- Comment #26 from Larry Baker baker at usgs dot gov 2012-09-11 21:33:55 UTC --- Created attachment 28174 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28174 Patch for trunk version 2012-08-12 of gcc/config/m68k/m68k.c Missed second LEGITIMATE_CONSTANT_P; should be m68k_legitimate_constant_p.
[Bug preprocessor/44191] -E output broken for gcc-4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44191 Israel Pinkas ipinkas at nds dot com changed: What|Removed |Added CC||ipinkas at nds dot com --- Comment #2 from Israel Pinkas ipinkas at nds dot com 2012-09-11 22:40:08 UTC --- A am not sure what Jakub means by Locus, but the C and C++ standards are clear that during the preprocessing stage, the sequence backslash-newline is dropped from the stream. Line splicing occurs before tokenization. While in most situations there is no difference, there are some cases which are affected by this bug: 1. Token splicing. Two tokens are separated by only a backslash-newline in the source are supposed to be concatenated into a single token. In a bizzare twist to this bug, this behavior is preserved. See example below. 2. Use of cpp for other purposes. There exist multiple software packages which are not compilers for C-line languages that use cpp as a preprocessor, accepting that cpp is C-oriented in a number of ways. This includes some assemblers and other packages that need file inclusion, conditional compilation, and simple macros. Many of these packages rely on the line splicing. The bug description needs to be slighly ammended. The splicing behavior was changed only when the first character following the newline is a space or tab. The following demonstrates: x.txt Test\ ing Test\ case END $ cpp x.txt # 1 x.txt # 1 built-in # 1 command-line # 1 x.txt Testing Test code == The first instance spliced the tokens. However, the second instance left the newline, a change in behavior and a deviation from the spec.
[Bug libstdc++/54482] failures in static linking with libstdc++, due to versioned symbols
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54482 Benjamin Kosnik bkoz at gcc dot gnu.org changed: What|Removed |Added CC||bkoz at gcc dot gnu.org, ||Ralf.Wildenhues at gmx dot ||de --- Comment #2 from Benjamin Kosnik bkoz at gcc dot gnu.org 2012-09-12 03:26:23 UTC --- FYI this bug is a duplicate of 28811. The summary/diagnosis is wrong. It's not about versioned symbols, at least not in 4.7.x and above (after fix of 52689). The issue is that even for all libstdc++ sources that are destined for the static library, ie libstdc++.a, compile flags should include -fPIC or equivalent, so that -static-libstdc++ works. These files are not compiled this way at the moment. So, compat*.o files need to be compiled with -prefer-pic. But, using that means that the delicate balance of the non-convenience library files in src, ie compat*.cc files is disturbed. At the moment, compat*.cc files are special, and have have code suitable for static and shared libs, and some code intended only for shared libs. Right now, the compile-time macro to designate these shared-only sections is PIC. But, using libtool's -prefer-pic for the compat*.cc files means -fPIC -DPIC, which messes up static/shared code paths. So, one solution may be to use -prefer-pic when using libtool to create all object files, but to use another macro, say _GLIBCXX_SHARED when compiling only shared code. (Another solution is to make yet-another convenience libary, that is only shared, and manually separate the source file dependencies. Let's try not to do it this way.) So, what is desired is a compile-time hook or flag into libtool that deals with just the static or just the shared compiled objects. There are currently configure-time hooks for this (--enable-shared/-static, etc). One hook is to create an override for libtool's pic_flag variable, using CXX_pic_flag, that is special for libstdc++. ie, from the generated libtool: from: pic_flag= -fPIC -DPIC to: pic_flag=-D_GLIBCXX_SHARED -fPIC -DPIC Sadly, I cannot figure out the correct way to do this, perhaps Ralf can help me. In the meantime: A hacky way to do this in configure.ac: # Use _GLIBCXX_SHARED as a compile-time switch just for libstdc++ to designate # a shared-only codepath. AC_CONFIG_COMMANDS([libtool-pic-patch], [echo config.status: patching libtool's pic_flag with -D_GLIBCXX_SHARED; sed libtool libtool.tmp 's/^pic_flag=/pic_flag=-D_GLIBCXX_SHARED /'; mv libtool.tmp libtool; chmod 775 libtool; ])
[Bug middle-end/54550] GCC -O3 breaks floating point equality comparison
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54550 --- Comment #5 from Veiokej veiokej at gmail dot com 2012-09-12 03:28:43 UTC --- Johnathan, Yes, I've read the floating point nonbug stuff. This isn't a nonbug. Michael, I understand your point, and thanks for the command line option. However, this is a subtly different issue than saying 64-bit double precision is slightly more accurate on X86 platforms due to 80-bit temporaries, vs. X64 platforms. The reason it's different is because there is no math done, and 80-bit precision can hold 100% of 64-bit values with no loss of precision. So no matter what, my equality test should not fail. Andrew, I appreciate that. Let me see if I can come up with something short of uploading the entire codebase. It's extremely sensitive to neighboring code, and is thus hard to isolate.
[Bug middle-end/54550] GCC -O3 breaks floating point equality comparison
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54550 --- Comment #6 from Veiokej veiokej at gmail dot com 2012-09-12 04:14:52 UTC --- In the process of trying to create a demo, I think I found the problem. Indeed, no math is taking place between when the value X is first computed and stored to the list, and when it's compared for equality with the nearest value Y found in the list. (They should be identical.) I think that X is observed to be unequal to Y because X is cached in a register, despite the fact that Y is computed in a (later) function. (Evidence is that removing -finline_functions, as does -ffloat-store fixes the problem.) When I was printing the value previously, I was inadvertently causing both X and Y to be stored to memory as 64-bit doubles, then taking the difference after the fact, which of course turned out to be 0. The difference was actually closer to 6x10^(-17). So this demonstrates how the previously well known excess precision issue can actually cause equality testing to fail, even when no math is involved between the store to memory, and the compare with memory. Yikes! Thankfully this is fixable by using full 80-bit precision, or migrating to X64. Let's leave this on the record for documentation, but I don't think it's worth further pursuit. Thanks to all for your input.
[Bug libstdc++/54482] failures in static linking with libstdc++, due to versioned symbols
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54482 --- Comment #3 from Ollie Wild aaw at gcc dot gnu.org 2012-09-12 04:58:29 UTC --- Note, however, that simply changing pic_flag to pic_flag=-D_GLIBCXX_SHARED -fPIC -DPIC is insufficient. It suffers from the same issue as the original problem, namely that, when configured with --with-pic, pic_flag is passed even when compiling objects for libstdc++.a. Since your solution passes -DPIC and -D_GLIBCXX_SHARED in tandem, keying off the new macro suffers from the same limitations as the old one. See my previous comment. In particular, the link there points to a more detailed analysis, as well as a patch which outlines the basics of what I think needs to change. As you correctly suggest, we need a mechanism to pass flags based on whether we're compiling for a static or shared library independently of whether or not -fPIC is used. The aforementioned patch does that in our branch, but that will need to be cleaned up and submitted to upstream libtool before incorporating it in GCC trunk.
[Bug debug/54551] DF resets some DEBUG_INSNs unnecessarily
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54551 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2012-09-12 05:54:29 UTC --- If there is a death point of the pseudo that dominates bbs with uses in some debug insns, then I think best is to insert the debug temporary immediately before the death point. If the death point of the pseudo doesn't dominate the bb with debug uses, or if there are multiple death point in different branches, but if the setter of the pseudo dominates the bb with debug uses or if there is some bb where the pseudo is live, isn't changed afterwards and that spot dominates the debug uses, then the best spot to insert the debug temporary is probably before the conditional jump/whatever other control changing insn at the end of that bb. E.g. for: +---+ | |set| / \ +---+ +---++---+ ||set||set| / \ +---++---+ | | | | \ / \ / (1) | +-+ (2) |death| / \ +-+ | \ | +-+ \ / \ |death| +-+ | | +-+ |death| | / \ | +-+ | | | \ / | \ / | | |+--+ | +--+ |dbguse| | |dbguse| +--+ | +--+ I think we want to insert the debug temp at (1) resp. (2). If there is no such spot, I think we have to give up, trying to build (if_then_else (condition) D#1234 D#2345) would bloat the debug info too much. Still handling even the dominating cases would be better than what we have right now. Perhaps we could handle single setters first if DF has computed that already. Perhaps this handling could be keyed off some new DF flag which would only be set in the first cse pass.
