[Bug ada/52123] [4.7/4.8 Regression] gcc bootstrap with ada fails on mingw target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52123 --- Comment #16 from Eric Botcazou ebotcazou at gcc dot gnu.org 2013-03-08 08:04:07 UTC --- Author: ebotcazou Date: Fri Mar 8 08:04:00 2013 New Revision: 196536 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196536 Log: PR ada/52123 * seh_init.c (Raise_From_Signal_Handler): Declare as no-return. (__gnat_SEH_error_handler): Likewise. Remove final return. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/seh_init.c
[Bug ada/52123] [4.7/4.8 Regression] gcc bootstrap with ada fails on mingw target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52123 --- Comment #17 from Eric Botcazou ebotcazou at gcc dot gnu.org 2013-03-08 08:04:32 UTC --- Author: ebotcazou Date: Fri Mar 8 08:04:22 2013 New Revision: 196537 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196537 Log: PR ada/52123 * seh_init.c (Raise_From_Signal_Handler): Declare as no-return. (__gnat_SEH_error_handler): Likewise. Remove final return. Modified: branches/gcc-4_7-branch/gcc/ada/ChangeLog branches/gcc-4_7-branch/gcc/ada/seh_init.c
[Bug ada/52123] [4.7/4.8 Regression] gcc bootstrap with ada fails on mingw target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52123 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #18 from Eric Botcazou ebotcazou at gcc dot gnu.org 2013-03-08 08:09:08 UTC --- Thanks for the patch, applied. Reopen if there are remaining issues.
[Bug target/56561] Miscompilation with -Os -arm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56561 --- Comment #4 from Mikael Pettersson mikpe at it dot uu.se 2013-03-08 08:23:31 UTC --- Created attachment 29613 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29613 backport of r183512/PR48308 to 4.6 branch This is the backport I've been using since early June 2012. The original patch required adjustments related to how LOG_LINKS are stored. Tested extensively on x86_64, sparc64, powerpc64, armv5te, and m68k.
[Bug c++/56567] New: ICE with lambda return type deduction and braced-init-list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56567
Bug #: 56567
Summary: ICE with lambda return type deduction and
braced-init-list
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pot...@mac.com
#include string
#include iostream
#include initializer_list
int main() {
for ( auto s : []()
{ return { std::string( first ), std::string( second ) }; }() )
std::cout s '\n';
}
ildtice.cpp: In lambda function:
ildtice.cpp:7:61: internal compiler error: in make_decl_rtl, at varasm.c:1136
{ return { std::string( first ), std::string( second ) }; }() )
^
ildtice.cpp:7:61: internal compiler error: Abort trap: 6
g++: internal compiler error: Abort trap: 6 (program cc1plus)
C++11 5.1.2/4:
…
— if the compound-statement is of the form
{ attribute-specifier-seqopt return expression ; }
…
The return statement doesn't match the pattern because a braced-init-list is
not an expression. Should be a proper error.
[Bug c/56566] bogus is narrower than values of its type warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56566 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-03-08 AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-08 08:35:56 UTC --- Created attachment 29614 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29614 gcc48-pr56566.patch Untested fix. Doesn't look to be a regression, at least not recent, gcc/g++ 3.2 behaved the same way.
[Bug c++/56568] New: std::initializer_list return value contents lost prematurely
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56568
Bug #: 56568
Summary: std::initializer_list return value contents lost
prematurely
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pot...@mac.com
See http://stackoverflow.com/q/15286450/153285
This program segfaults:
#include string
#include iostream
#include initializer_list
int main() {
for ( auto s : []() - std::initializer_list std::string
{ return { std::string( first ), std::string( second ) }; }() )
std::cout s '\n';
}
The return value object should be initialized from the braced-init-list, and
bound directly to the implicit auto __range object of the range-based for
statement. The array backing that object should have the same lifetime as it,
namely the duration of the loop. Instead, the array is destroyed when the
lambda exits.
This is not easy to fix, but I'll just file this.
[Bug c++/56567] [4.8 Regression] ICE with lambda return type deduction and braced-init-list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56567 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-03-08 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Target Milestone|--- |4.8.0 Summary|ICE with lambda return type |[4.8 Regression] ICE with |deduction and |lambda return type |braced-init-list|deduction and ||braced-init-list Ever Confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-08 08:42:43 UTC --- Started with http://gcc.gnu.org/viewcvs?root=gccview=revrev=185768
[Bug middle-end/54582] gap in FORTIFY checking of buffer lengths
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54582 --- Comment #15 from David Binderman dcb314 at hotmail dot com 2013-03-08 08:48:47 UTC --- Created attachment 29615 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29615 C++ source code This one now understands 40 common formats and can properly interpret field widths. The next version will understand the NUM1.NUM2 format.
[Bug c/56569] New: When compiling the source insn does not satisfy its constraints:with CFlags as -mcfv4e
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56569
Bug #: 56569
Summary: When compiling the source insn does not satisfy its
constraints:with CFlags as -mcfv4e
Classification: Unclassified
Product: gcc
Version: 3.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jebinael...@gmail.com
When compiling the source insn does not satisfy its constraints:with CFlags as
-mcfv4e. I'm getting this error only when i inlcude mcfv4e.
/home/ts2/Share/TS2/webserver/barracuda8/src/plugins/SharkSSL/src/SharkSslCon_hs.c:2848:
error: insn does not satisfy its constraints:
(insn 10115 2196 2198 191
/home/ts2/Share/TS2/webserver/barracuda8/src/plugins/SharkSSL/src/SharkSslCon_hs.c:1053
(set (reg:QI 9 %a1)
(mem:QI (plus:SI (reg/f:SI 14 %a6)
(const_int -127 [0xff81])) [97 S1 A8])) 38 {*m68k.md:939}
(nil)
(nil))
[Bug middle-end/39326] Segmentation fault with -O1, out of memory with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326 --- Comment #40 from Richard Biener rguenth at gcc dot gnu.org 2013-03-08 09:12:38 UTC --- (In reply to comment #31) (In reply to comment #30) Hmm, RTL PRE isn't really mine either, but I probably know it as well as anyone else, so I will have a look. It's probably a similar issue as for gimple LIM: alias checks. Can you attach your TLC patches for gimple LIM to this PR, please? Found it on some testing machine. I merged it and saw to it that it compiles and passes tree-ssa.exp (some ???s remain, I've added a TODO). The idea should be clear, and it's memory savings only and it will eventually be a bit slower (unless it is optimized further).
[Bug middle-end/39326] Segmentation fault with -O1, out of memory with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326 --- Comment #41 from Richard Biener rguenth at gcc dot gnu.org 2013-03-08 09:13:53 UTC --- Created attachment 29616 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29616 make LIM work per outermost loop
[Bug middle-end/39326] Segmentation fault with -O1, out of memory with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326 --- Comment #42 from rguenther at suse dot de rguenther at suse dot de 2013-03-08 09:22:39 UTC --- On Thu, 7 Mar 2013, steven at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326 --- Comment #38 from Steven Bosscher steven at gcc dot gnu.org 2013-03-07 22:15:39 UTC --- Created attachment 29612 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29612 Punt on loops with more memory references than LIM can handle For the LIM problem, I'm thinking of a patch like this one (not tested yet). Basically, this means giving up on really large loops with many loads and/or stores. That's not an unreasonable thing to do anyway. Code motion from really big loops usually isn't an improvement. Richi, could you have a look at this, and see if I've got it all right, more-or-less? LIM is quite complicated and I'm not sure if I should look at, or update, the set of optimizable loops somewhere. Yeah, well - it should be easy to avoid most overhead (even collecting the memory references) with my proposed scheme (see patch). First, for each BB count the number of memory stmts (easy, look for VUSEs), then, when walking the set of outermost loops we want to apply LIM to sum over its BB counts and instead walk over its siblings if the number is too large. But yes, limiting it should be done as it performs O(n^2) dependence checks (well, O(#of stores * #of memory references), so for a low number of stores it's quite cheap). I've yet to recover the obstack-ification of struct depend, struct mem_ref, struct mem_ref_locs and lim_aux_data allocations ... (LIM is the biggest load on malloc/free). With the patch, and with -O2 -fgcse, I now have: gap_TlnLv4.c: In function 'RDFT_49152_1': gap_TlnLv4.c:37502:18: warning: -ftree-loop-im: number of memory references in loop exceeds the --param loops-max-datarefs-for-datadeps threshold [-Wdisabled-optimization] t12308[500] = t12304[6144*i0+1000]; ^ dead store elim1: 57.70 ( 8%) dead store elim2: 76.82 (10%) combiner: 360.07 (48%) reload CSE regs : 55.44 ( 7%) TOTAL : 743.77 Nice. Well ... ;)
[Bug target/56560] [4.6/4.7 regression] vzeroupper clobbers argument with AVX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56560 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added CC||hjl.tools at gmail dot com Known to work||4.8.0 --- Comment #3 from Uros Bizjak ubizjak at gmail dot com 2013-03-08 09:24:27 UTC --- Adding author of 4,6/4.7 vzerouopper pass to CC.
[Bug c/56569] When compiling the source insn does not satisfy its constraints:with CFlags as -mcfv4e
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56569 --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se 2013-03-08 09:25:58 UTC --- gcc-3.4.0 is ancient and hasn't been supported by upstream for years. Please try again with a supported release, e.g. 4.7.2 or 4.6.3. Also, you failed to provide a test case.
[Bug c++/56564] movdqa on possibly-8-byte-aligned struct with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56564
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed||2013-03-08
Summary|[4.7 Regression] movdqa on |movdqa on
|possibly-8-byte-aligned |possibly-8-byte-aligned
|struct with -O3 |struct with -O3
Ever Confirmed|0 |1
Known to fail||4.6.4, 4.7.2, 4.8.0
--- Comment #2 from Richard Biener rguenth at gcc dot gnu.org 2013-03-08
10:00:54 UTC ---
This instruction appears in an EH region of function
_ZN5boost16exception_detail27get_static_exception_objectINS0_10bad_alloc_EEENS_13exception_ptrEv
(AFAIK). It's defined twice, once weak and aligned 8 and once strong
and aligned 16, so AFAIK it _is_ aligned properly.
.align 8
.type
_ZGVZN5boost16exception_detail27get_static_exception_objectINS0_10bad_alloc_EEENS_13exception_ptrEvE2ep,
@gnu_unique_object
.size
_ZGVZN5boost16exception_detail27get_static_exception_objectINS0_10bad_alloc_EEENS_13exception_ptrEvE2ep,
8
_ZGVZN5boost16exception_detail27get_static_exception_objectINS0_10bad_alloc_EEENS_13exception_ptrEvE2ep:
.zero 8
.weak
_ZZN5boost16exception_detail27get_static_exception_objectINS0_10bad_alloc_EEENS_13exception_ptrEvE2ep
.section
.bss._ZZN5boost16exception_detail27get_static_exception_objectINS0_10bad_alloc_EEENS_13exception_ptrEvE2ep,awG,@nobits,_ZZN5boost16exception_detail27get_static_exception_objectINS0_10bad_alloc_EEENS_13exception_ptrEvE2ep,comdat
.align 16
.type
_ZZN5boost16exception_detail27get_static_exception_objectINS0_10bad_alloc_EEENS_13exception_ptrEvE2ep,
@gnu_unique_object
.size
_ZZN5boost16exception_detail27get_static_exception_objectINS0_10bad_alloc_EEENS_13exception_ptrEvE2ep,
16
_ZZN5boost16exception_detail27get_static_exception_objectINS0_10bad_alloc_EEENS_13exception_ptrEvE2ep:
.zero 16
and readelf shows:
[192] .bss._ZZN5boost16 NOBITS 1ca0
0010 WAG 0 0 16
with alignment of 16.
This crashes if
_ZZN5boost16exception_detail27get_static_exception_objectINS0_10bad_alloc_EEENS_13exception_ptrEvE2ep
comes from another object file where it is declared with 8-byte alignment.
so this would be a bug and a violation of ODR(?)
What's this other object file?
The code piece in question is:
template class Exception
exception_ptr
get_static_exception_object()
{
Exception ba;
exception_detail::clone_implException c(ba);
static exception_ptr ep(shared_ptrexception_detail::clone_base
const(new exception_detail::clone_implException(c)));
return ep;
}
OTOH, not sure what increases the alignment of that object from it's
type-alignmend.
Same alignment is emitted with 4.8 and also 4.6 - so you must be unlucky
with that other object file (compiled with which compiler?)
Please also attach preprocessed source of the other object file
[Bug c++/56564] movdqa on possibly-8-byte-aligned struct with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56564 --- Comment #3 from lukeocamden at gmail dot com 2013-03-08 10:32:34 UTC --- Sorry for my cryptic comments about the other object file. It's compiled with icc 13. I will attach the preprocessed source and generated assembly.
[Bug lto/56570] New: ICE when streaming a TREE_BLOCK
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56570 Bug #: 56570 Summary: ICE when streaming a TREE_BLOCK Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: jamb...@gcc.gnu.org Created attachment 29617 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29617 Pre-processed failing source When building Mozilla Firefox with LTO (gcc revision 196427, FF changeset 123831:c95439870e05), I'm encountering an ICE when compiling js/src/ion/shared/CodeGenerator-shared.cpp (and I suppose the same one in a number of other files). The problem occurs in the compilation phase. The ICE simply disappears when I add -save-temps to the command line but reappeared when I also added --param ggc-min-expand=10 --param ggc-min-heapsize=1024. The attached resultant .ii file also ICEs but --param ggc-min-expand=5 --param ggc-min-heapsize=512 is necessary to trigger it.
[Bug lto/56570] ICE when streaming a TREE_BLOCK
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56570 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added Target||x86_64-linux-gnu Host||x86_64-linux-gnu --- Comment #1 from Martin Jambor jamborm at gcc dot gnu.org 2013-03-08 10:39:52 UTC --- Let me copy over here from PR 45375 the backtrace: #0 0x00f89a73 in get_location_from_adhoc_loc (set=0x77ff2000, loc=2947526575) at /home/mjambor/gcc/trunk/src/libcpp/line-map.c:165 #1 0x00c247fe in inlined_function_outer_scope_p (block=0x7fffee4bcb28) at /home/mjambor/gcc/trunk/src/gcc/tree.h:5561 #2 pack_ts_block_value_fields (expr=0x7fffee4bcb28, bp=0x7fffd1a0, ob=0x1c73210) at /home/mjambor/gcc/trunk/src/gcc/tree-streamer-out.c:319 #3 streamer_pack_tree_bitfields (ob=0x1c73210, bp=0x7fffd1a0, expr=0x7fffee4bcb28) at /home/mjambor/gcc/trunk/src/gcc/tree-streamer-out.c:417 #4 0x009c3bc9 in lto_write_tree (ref_p=true, expr=0x7fffee4bcb28, ob=0x1c73210) at /home/mjambor/gcc/trunk/src/gcc/lto-streamer-out.c:317 #5 lto_output_tree (ob=0x1c73210, expr=0x7fffee4bcb28, ref_p=true, this_ref_p=optimized out) at /home/mjambor/gcc/trunk/src/gcc/lto-streamer-out.c:410 #6 0x00c26617 in write_ts_common_tree_pointers (ref_p=true, expr=0x73f6bc80, ob=0x1c73210) at /home/mjambor/gcc/trunk/src/gcc/tree-streamer-out.c:514 #7 streamer_write_tree_body (ob=0x1c73210, expr=0x73f6bc80, ref_p=optimized out) at /home/mjambor/gcc/trunk/src/gcc/tree-streamer-out.c:845 #8 0x009c3bf7 in lto_write_tree (ref_p=true, expr=0x73f6bc80, ob=0x1c73210) at /home/mjambor/gcc/trunk/src/gcc/lto-streamer-out.c:321 #9 lto_output_tree (ob=ob@entry=0x1c73210, expr=0x73f6bc80, ref_p=ref_p@entry=true, this_ref_p=this_ref_p@entry=true) at /home/mjambor/gcc/trunk/src/gcc/lto-streamer-out.c:410 #10 0x00c26e62 in write_ts_exp_tree_pointers (ref_p=optimized out, expr=optimized out, ob=optimized out) at /home/mjambor/gcc/trunk/src/gcc/tree-streamer-out.c:747 #11 streamer_write_tree_body (ob=0x1c73210, expr=0x7fffecc63dc0, ref_p=optimized out) at /home/mjambor/gcc/trunk/src/gcc/tree-streamer-out.c:884 #12 0x009c3bf7 in lto_write_tree (ref_p=true, expr=0x7fffecc63dc0, ob=0x1c73210) at /home/mjambor/gcc/trunk/src/gcc/lto-streamer-out.c:321 #13 lto_output_tree (ob=0x1c73210, expr=0x7fffecc63dc0, ref_p=true, this_ref_p=optimized out) at /home/mjambor/gcc/trunk/src/gcc/lto-streamer-out.c:410 #14 0x00c26df8 in write_ts_exp_tree_pointers (ref_p=optimized out, expr=optimized out, ob=optimized out) at /home/mjambor/gcc/trunk/src/gcc/tree-streamer-out.c:746 #15 streamer_write_tree_body (ob=0x1c73210, expr=0x7fffecc70078, ref_p=optimized out) at /home/mjambor/gcc/trunk/src/gcc/tree-streamer-out.c:884 #16 0x009c3bf7 in lto_write_tree (ref_p=true, expr=0x7fffecc70078, ob=0x1c73210) at /home/mjambor/gcc/trunk/src/gcc/lto-streamer-out.c:321 #17 lto_output_tree (ob=ob@entry=0x1c73210, expr=0x7fffecc70078, ref_p=ref_p@entry=true, this_ref_p=this_ref_p@entry=true) at /home/mjambor/gcc/trunk/src/gcc/lto-streamer-out.c:410 #18 0x00c2681d in write_ts_decl_common_tree_pointers (ref_p=true, expr=0x7fffecc6d720, ob=0x1c73210) at /home/mjambor/gcc/trunk/src/gcc/tree-streamer-out.c:584 #19 streamer_write_tree_body (ob=0x1c73210, expr=0x7fffecc6d720, ref_p=optimized out) at /home/mjambor/gcc/trunk/src/gcc/tree-streamer-out.c:857 #20 0x009c3bf7 in lto_write_tree (ref_p=true, expr=0x7fffecc6d720, ob=0x1c73210) at /home/mjambor/gcc/trunk/src/gcc/lto-streamer-out.c:321 #21 lto_output_tree (ob=0x1c73210, expr=0x7fffecc6d720, ref_p=true, this_ref_p=optimized out) at /home/mjambor/gcc/trunk/src/gcc/lto-streamer-out.c:410 #22 0x00ecd118 in output_gimple_stmt (stmt=0x7fffec6206c0, ob=0x1c73210) at /home/mjambor/gcc/trunk/src/gcc/gimple-streamer-out.c:143 #23 output_bb (ob=0x1c73210, bb=0x7fffed130f08, fn=0x7fffef8603f0) at /home/mjambor/gcc/trunk/src/gcc/gimple-streamer-out.c:199 #24 0x009c4f26 in output_function (node=0x7fffef8614a0) at /home/mjambor/gcc/trunk/src/gcc/lto-streamer-out.c:823 #25 lto_output () at /home/mjambor/gcc/trunk/src/gcc/lto-streamer-out.c:987 #26 0x009fa971 in ipa_write_summaries_2 ( pass=0x1618f00 pass_ipa_lto_gimple_out, state=0x1ad8c00) at /home/mjambor/gcc/trunk/src/gcc/passes.c:2408 I am not sure to what extent it matters, given that the failure apparently depends on when certain GC takes place, but the first failing revision is 196174: commit 560965e9b33deb5fa67c848c8b14ea7bbb42e8a2 Author: rguenth Date: Wed Feb 20 15:19:13 2013 +
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added Depends on||56570 --- Comment #181 from Martin Jambor jamborm at gcc dot gnu.org 2013-03-08 10:41:54 UTC --- The bug described in comment #179 is now PR 56570.
[Bug rtl-optimization/56571] New: ICE in copyprop_hardreg_forward_1, at regcprop.c (insn does not satisfy its constraints !)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56571
Bug #: 56571
Summary: ICE in copyprop_hardreg_forward_1, at regcprop.c (insn
does not satisfy its constraints !)
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: antoine.balest...@gmail.com
Hello !
The following testcase makes GCC 4.7.2 and 4.8.0 as of 20130308 fail.
$ cat insn.c
int a, b;
int f(void)
{
(a % b) f();
a = (0 || a | (a ? : 1));
}
$ xgcc -w -O2 -funroll-loops -ftracer insn.c
insn.c: In function ‘f’:
insn.c:7:1: error: insn does not satisfy its constraints:
}
^
(insn 83 79 84 9 (parallel [
(set (reg:CCZ 17 flags)
(compare:CCZ (ior:SI (reg:SI 4 si [81])
(reg:SI 2 cx [orig:69 D.1741 ] [69]))
(const_int 0 [0])))
(clobber (reg:SI 39 r10 [81]))
]) insn.c:6 451 {*iorsi_3}
(expr_list:REG_DEAD (reg:SI 2 cx [orig:69 D.1741 ] [69])
(expr_list:REG_DEAD (reg:SI 0 ax [81])
(expr_list:REG_UNUSED (reg:SI 0 ax [81])
(nil)
insn.c:7:1: internal compiler error: in copyprop_hardreg_forward_1, at
regcprop.c:774
0x8a175a _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../srcdir/gcc/rtl-error.c:109
0x8a177f _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../srcdir/gcc/rtl-error.c:120
0x87b1e7 copyprop_hardreg_forward_1
../../srcdir/gcc/regcprop.c:774
0x87b1e7 copyprop_hardreg_forward
../../srcdir/gcc/regcprop.c:1085
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug lto/56570] ICE when streaming a TREE_BLOCK
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56570 --- Comment #2 from Martin Jambor jamborm at gcc dot gnu.org 2013-03-08 10:43:12 UTC --- I forgot the compilation options I use: ~/gcc/trunk/inst/bin/g++ -o CodeGenerator-shared.o -c -fPIC -Wno-invalid-offsetof -Wcast-align -flto -fpermissive -Wno-maybe-uninitialized -Wno-unused-local-typedefs -fuse-linker-plugin -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -pthread -DNDEBUG -DTRIMMED -g -O3 CodeGenerator-shared.ii --param ggc-min-expand=5 --param ggc-min-heapsize=512
[Bug c++/56564] movdqa on possibly-8-byte-aligned struct with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56564 --- Comment #4 from lukeocamden at gmail dot com 2013-03-08 10:47:10 UTC --- Created attachment 29618 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29618 Preprocessed with ICC
[Bug c++/56564] movdqa on possibly-8-byte-aligned struct with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56564 --- Comment #5 from lukeocamden at gmail dot com 2013-03-08 11:07:45 UTC --- Created attachment 29619 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29619 Generated by icc 13
[Bug lto/56570] ICE when streaming a TREE_BLOCK
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56570
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2013-03-08
Ever Confirmed|0 |1
--- Comment #3 from Richard Biener rguenth at gcc dot gnu.org 2013-03-08
11:20:22 UTC ---
Index: gcc/tree-cfg.c
===
--- gcc/tree-cfg.c (revision 196540)
+++ gcc/tree-cfg.c (working copy)
@@ -4521,6 +4541,15 @@ verify_expr_location_1 (tree *tp, int *w
{
struct pointer_set_t *blocks = (struct pointer_set_t *) data;
+ if (TREE_CODE (*tp) == VAR_DECL
+ DECL_DEBUG_EXPR_IS_FROM (*tp))
+{
+ tree t = DECL_DEBUG_EXPR (*tp);
+ tree addr = walk_tree (t, verify_expr_location_1, blocks, NULL);
+ if (addr)
+ return addr;
+}
+
if (!EXPR_P (*tp))
{
*walk_subtrees = false;
exposes it. Various fixes to tree-inline.c didn't yet fix it :/
Reducing the testcase with the above.
[Bug c++/56564] movdqa on possibly-8-byte-aligned struct with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56564
--- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-08
11:20:19 UTC ---
This is due to ix86_data_alignment, which has:
/* x86-64 ABI requires arrays greater than 16 bytes to be aligned
to 16byte boundary. */
if (TARGET_64BIT)
{
if (AGGREGATE_TYPE_P (type)
TYPE_SIZE (type)
TREE_CODE (TYPE_SIZE (type)) == INTEGER_CST
(TREE_INT_CST_LOW (TYPE_SIZE (type)) = 128
|| TREE_INT_CST_HIGH (TYPE_SIZE (type))) align 128)
return 128;
}
The comment and wording of
http://refspecs.linuxfoundation.org/elf/x86_64-abi-0.95.pdf
seems to be inconsistent with what the code does.
The comment and 0.95 version of the psABI only talks about arrays:
An array uses the same alignment as its elements, except that a local or
global
array variable that requires at least 16 bytes, or a C99 local or global
variable-length array variable, always has alignment of at least 16 bytes.
but AGGREGATE_TYPE_P isn't solely about array local/global variables, but any
aggregates (arrays, structs, unions, ...). ep apparently has size of 16 and
the above code aligns it to 16 bytes, but icc probably aligns it just to 8
bytes, as the maximum alignment of its members. Now, changing the above to
only look at arrays would probably cause more harm than good, because while
code compiled by fixed gcc would be compatible with icc, it would be
incompatible with code compiled by older gcc. Guess if we want to change
something, we'd need to change it in a way that such aggregates (non-array
ones) of size 16 and above are still 16-byte aligned, but if the variable isn't
known to bind locally, don't increase DECL_ALIGN of the var, so that no
optimizers actually rely on it.
[Bug rtl-optimization/56571] [4.7/4.8 Regression] ICE in copyprop_hardreg_forward_1, at regcprop.c (insn does not satisfy its constraints !)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56571 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target||x86_64-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2013-03-08 Known to work||4.6.4 Target Milestone|--- |4.7.3 Summary|ICE in |[4.7/4.8 Regression] ICE in |copyprop_hardreg_forward_1, |copyprop_hardreg_forward_1, |at regcprop.c (insn does|at regcprop.c (insn does |not satisfy its constraints |not satisfy its constraints |!) |!) Ever Confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org 2013-03-08 11:24:42 UTC --- Confirmed.
[Bug target/56564] movdqa on possibly-8-byte-aligned struct with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56564 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||ABI, wrong-code Target||x86_64-*-* Status|WAITING |NEW --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org 2013-03-08 11:26:19 UTC --- Confirmed.
[Bug target/56564] movdqa on possibly-8-byte-aligned struct with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56564 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-08 11:35:36 UTC --- Guess we'd need to split DATA_ALIGNMENT into two different macros (or one with an extra argument), so that align_variable would know what alignment is part of ABI and what is just an optimization above that, then align_variable could call targetm.binds_local_p to see if DECL_ALIGN can be increased to the optimization level or needs to stay at the ABI guaranteed level. And then when assembling vars, we'd increase the emitted alignment to the optimization level.
[Bug c/56569] When compiling the source insn does not satisfy its constraints:with CFlags as -mcfv4e
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56569 --- Comment #2 from JET jebinaelsie at gmail dot com 2013-03-08 12:06:19 UTC --- It seems to solve with gcc-4.3.43.Thanks
[Bug rtl-optimization/56571] [4.7/4.8 Regression] ICE in copyprop_hardreg_forward_1, at regcprop.c (insn does not satisfy its constraints !)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56571 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-08 12:08:53 UTC --- Started with http://gcc.gnu.org/viewcvs?root=gccview=revrev=181188
[Bug rtl-optimization/55177] missed optimizations with __builtin_bswap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55177 --- Comment #9 from David Woodhouse dwmw2 at infradead dot org 2013-03-08 12:11:24 UTC --- This is now enabled in the Linux kernel. Core patch: http://git.kernel.org/linus/cf66bb93 (in v3.8 but does nothing there) x86:http://git.kernel.org/linus/83a57a4d (will be in v3.9) PowerPC:http://git.kernel.org/linus/fe3955cb (will be in v3.9) There's an ARM patch which looks like it missed the boat for 3.9 but should hopefully be in v3.10: https://lkml.org/lkml/2013/2/22/475 On ARM where we have no load-and-swap or store-and-swap primitives we are already seeing a tiny win. But fixing up more of the missing optimisations would be good.
[Bug lto/56570] ICE when streaming a TREE_BLOCK
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56570
--- Comment #5 from Richard Biener rguenth at gcc dot gnu.org 2013-03-08
12:15:13 UTC ---
typedef struct { unsigned long long w[4]; } UINT256;
static void add256 (UINT256 x, UINT256 y, UINT256 * pz)
{
UINT256 z;
z.w[0] = x.w[0] + y.w[0];
z.w[1] = x.w[1] + y.w[1];
z.w[2] = x.w[2] + y.w[2];
z.w[3] = x.w[3] + y.w[3];
*pz = z;
}
static inline void bid128_ext_fma ()
{
UINT256 C4;
UINT256 R256;
add256 (C4, R256, R256);
nr_digits256 (R256);
}
void __bid128_fma ()
{
bid128_ext_fma ();
}
ICEs at -O2 -g -m32 with the extra checking.
[Bug lto/56570] ICE when streaming a TREE_BLOCK
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56570 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-08 12:15:38 UTC --- Locations are useless in DECL_DEBUG_EXPR expressions, so I have nothing against that SRA change, but please note that also gimplify.c and tree-complex.c create DECL_DEBUG_EXPRs, so those places should be investigated too. In gimplify.c sounds like *to_p is always DECL_P though, and in tree-complex.c REALPART_EXPR or IMAGPART_EXPR of a DECL_P where the expr is created with build1 (thus doesn't have loc?).
[Bug c/56569] When compiling the source insn does not satisfy its constraints:with CFlags as -mcfv4e
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56569 --- Comment #3 from Mikael Pettersson mikpe at it dot uu.se 2013-03-08 12:19:15 UTC --- The please close this bug report.
[Bug lto/56570] ICE when streaming a TREE_BLOCK
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56570 --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org 2013-03-08 12:25:50 UTC --- Created attachment 29620 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29620 inliner patches For the inliner I've now synced copy_tree_body_r and remap_gimple_op_r wrt MEM_REFs (to no avail). I also added debug-expr remapping to copy_debug_stmt (as the tree-ssa-live.c code shows not all debug-expr decls are in local-decls), to no avail either. See attachment.
[Bug target/56564] movdqa on possibly-8-byte-aligned struct with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56564
--- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-08
12:38:20 UTC ---
Smaller testcase (-O2 -fpic):
struct S { long a, b; } s;
int foo (void)
{
return ((long) s) 15;
}
is since http://gcc.gnu.org/viewcvs?root=gccview=revrev=162943 optimized into
return 0, even when (probably) the psABI doesn't guarantee that. But e.g. for
__builtin_memset (s, 0, sizeof (s)); one can see already in 4.0 RTL dumps with
-O2 -fpic that MEM_ALIGN of s is assumed to be 128-bit.
[Bug lto/56570] ICE when streaming a TREE_BLOCK
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56570 --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org 2013-03-08 12:42:12 UTC --- We don't even copy the decl with the DECL_DEBUG_EXPR in copy_debug_stmt during the 2nd inlining! Because when the decls disappear from local-decls nothing remaps them and we get into else if (TREE_CODE (t) == VAR_DECL !is_global_var (t) !pointer_map_contains (id-decl_map, t)) /* T is a non-localized variable. */; so we absolutely rely on being able to share DECL_DEBUG_EXPR for those! Thus, the SRA patch is correct and verification should be made even stricter.
[Bug c/56572] New: GCC generates non-optimal transactional code when inlining nested transaction.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56572
Bug #: 56572
Summary: GCC generates non-optimal transactional code when
inlining nested transaction.
Classification: Unclassified
Product: gcc
Version: trans-mem
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: srdjan.sti...@gmail.com
GCC generates non-optimal transactional code
when inlining function that has transactional code.
This affects gcc-4.7 and gcc-4.8 (gcc version 4.8.0 20130222 (experimental)).
// example
int a;
static inline void f() {
__transaction_atomic {
++a;
}
}
void g() {
__transaction_atomic {
f();
}
}
void h() {
__transaction_atomic {
__transaction_atomic {
++a;
}
}
}
Generated code:
g():
subq$8, %rsp
movl$41, %edi
xorl%eax, %eax
call_ITM_beginTransaction
movl$41, %edi
xorl%eax, %eax
call_ITM_beginTransaction
movl$a, %edi
call_ITM_RfWU4
leal1(%rax), %esi
movl$a, %edi
call_ITM_WaWU4
call_ITM_commitTransaction
call_ITM_commitTransaction
addq$8, %rsp
ret
h():
subq$8, %rsp
movl$41, %edi
xorl%eax, %eax
call_ITM_beginTransaction
movl$a, %edi
call_ITM_RfWU4
leal1(%rax), %esi
movl$a, %edi
call_ITM_WaWU4
call_ITM_commitTransaction
addq$8, %rsp
ret
The bug:
The functions g() and h() should have the __same__ asm.
The problem is that GCC doesn't remove __nested__
_ITM_beginTransaction()/_ITM_commitTransaction
that are known at compile time.
Compiled with:
gcc-4.7 -v -O2 -fgnu-tm -c example.c
Using built-in specs.
COLLECT_GCC=gcc
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.7.2-5ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs
--enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.7 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object
--enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i686
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.7.2 (Ubuntu/Linaro 4.7.2-5ubuntu1)
COLLECT_GCC_OPTIONS='-v' '-O2' '-fgnu-tm' '-c' '-mtune=generic' '-march=x86-64'
'-pthread'
/usr/lib/gcc/x86_64-linux-gnu/4.7/cc1 -quiet -v -imultiarch x86_64-linux-gnu
-D_REENTRANT example.c -quiet -dumpbase example.c -mtune=generic -march=x86-64
-auxbase example -O2 -version -fgnu-tm -fstack-protector -o /tmp/ccKJdU1H.s
GNU C (Ubuntu/Linaro 4.7.2-5ubuntu1) version 4.7.2 (x86_64-linux-gnu)
compiled by GNU C version 4.7.2, GMP version 5.0.2, MPFR version 3.1.0-p3,
MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory /usr/local/include/x86_64-linux-gnu
ignoring nonexistent directory
/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../x86_64-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/usr/lib/gcc/x86_64-linux-gnu/4.7/include
/usr/local/include
/usr/lib/gcc/x86_64-linux-gnu/4.7/include-fixed
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
GNU C (Ubuntu/Linaro 4.7.2-5ubuntu1) version 4.7.2 (x86_64-linux-gnu)
compiled by GNU C version 4.7.2, GMP version 5.0.2, MPFR version 3.1.0-p3,
MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: fbb4af59dce4dce949ee30395742b8d0
COLLECT_GCC_OPTIONS='-v' '-O2' '-fgnu-tm' '-c' '-mtune=generic' '-march=x86-64'
'-pthread'
as -v --64 -o example.o /tmp/ccKJdU1H.s
GNU assembler version 2.22.90 (x86_64-linux-gnu) using BFD version (GNU
Binutils for Ubuntu) 2.22.90.20120924
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.7/:/usr/lib/gcc/x86_64-linux-gnu/4.7/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.7/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.7/:/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-O2' '-fgnu-tm' '-c' '-mtune=generic' '-march=x86-64'
'-pthread'
[Bug c/56573] New: GCC generates non-optimal transactional code when inlining nested transaction.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56573
Bug #: 56573
Summary: GCC generates non-optimal transactional code when
inlining nested transaction.
Classification: Unclassified
Product: gcc
Version: trans-mem
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: srdjan.sti...@gmail.com
Created attachment 29621
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29621
Minimal test case.
GCC generates non-optimal transactional code
when inlining function that has transactional code.
This affects gcc-4.7 and gcc-4.8 (gcc version 4.8.0 20130222 (experimental)).
// example
int a;
static inline void f() {
__transaction_atomic {
++a;
}
}
void g() {
__transaction_atomic {
f();
}
}
void h() {
__transaction_atomic {
__transaction_atomic {
++a;
}
}
}
Generated code:
g():
subq$8, %rsp
movl$41, %edi
xorl%eax, %eax
call_ITM_beginTransaction
movl$41, %edi
xorl%eax, %eax
call_ITM_beginTransaction
movl$a, %edi
call_ITM_RfWU4
leal1(%rax), %esi
movl$a, %edi
call_ITM_WaWU4
call_ITM_commitTransaction
call_ITM_commitTransaction
addq$8, %rsp
ret
h():
subq$8, %rsp
movl$41, %edi
xorl%eax, %eax
call_ITM_beginTransaction
movl$a, %edi
call_ITM_RfWU4
leal1(%rax), %esi
movl$a, %edi
call_ITM_WaWU4
call_ITM_commitTransaction
addq$8, %rsp
ret
The bug:
The functions g() and h() should have the __same__ asm.
The problem is that GCC doesn't remove __nested__
_ITM_beginTransaction()/_ITM_commitTransaction
that are known at compile time.
Compiled with:
gcc-4.7 -v -O2 -fgnu-tm -c example.c
Using built-in specs.
COLLECT_GCC=gcc
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.7.2-5ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs
--enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.7 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object
--enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i686
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.7.2 (Ubuntu/Linaro 4.7.2-5ubuntu1)
COLLECT_GCC_OPTIONS='-v' '-O2' '-fgnu-tm' '-c' '-mtune=generic' '-march=x86-64'
'-pthread'
/usr/lib/gcc/x86_64-linux-gnu/4.7/cc1 -quiet -v -imultiarch x86_64-linux-gnu
-D_REENTRANT example.c -quiet -dumpbase example.c -mtune=generic -march=x86-64
-auxbase example -O2 -version -fgnu-tm -fstack-protector -o /tmp/ccKJdU1H.s
GNU C (Ubuntu/Linaro 4.7.2-5ubuntu1) version 4.7.2 (x86_64-linux-gnu)
compiled by GNU C version 4.7.2, GMP version 5.0.2, MPFR version 3.1.0-p3,
MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory /usr/local/include/x86_64-linux-gnu
ignoring nonexistent directory
/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../x86_64-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/usr/lib/gcc/x86_64-linux-gnu/4.7/include
/usr/local/include
/usr/lib/gcc/x86_64-linux-gnu/4.7/include-fixed
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
GNU C (Ubuntu/Linaro 4.7.2-5ubuntu1) version 4.7.2 (x86_64-linux-gnu)
compiled by GNU C version 4.7.2, GMP version 5.0.2, MPFR version 3.1.0-p3,
MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: fbb4af59dce4dce949ee30395742b8d0
COLLECT_GCC_OPTIONS='-v' '-O2' '-fgnu-tm' '-c' '-mtune=generic' '-march=x86-64'
'-pthread'
as -v --64 -o example.o /tmp/ccKJdU1H.s
GNU assembler version 2.22.90 (x86_64-linux-gnu) using BFD version (GNU
Binutils for Ubuntu) 2.22.90.20120924
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.7/:/usr/lib/gcc/x86_64-linux-gnu/4.7/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.7/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.7/:/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-O2' '-fgnu-tm' '-c'
[Bug lto/56570] ICE when streaming a TREE_BLOCK
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56570 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #10 from Richard Biener rguenth at gcc dot gnu.org 2013-03-08 13:46:57 UTC --- Fixed.
[Bug lto/56570] ICE when streaming a TREE_BLOCK
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56570 --- Comment #9 from Richard Biener rguenth at gcc dot gnu.org 2013-03-08 13:46:35 UTC --- Author: rguenth Date: Fri Mar 8 13:46:18 2013 New Revision: 196546 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196546 Log: 2013-03-08 Richard Biener rguent...@suse.de PR tree-optimization/56570 * tree-cfg.c (verify_expr_location_1): Verify locations for DECL_DEBUG_EXPR. * tree-sra.c (create_access_replacement): Strip locations from DECL_DEBUG_EXPRs. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-cfg.c trunk/gcc/tree-sra.c
[Bug lto/48724] Lto build of mozilla dies at lto-wrapper: error trying to exec 'make -j1': execvp: No such file or directory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48724 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||Ralf.Wildenhues at gmx dot ||de --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org 2013-03-08 13:58:27 UTC --- Caused by 2010-05-23 Ralf Wildenhues ralf.wildenh...@gmx.de * lto-wrapper.c (run_gcc): Unset MAKEFLAGS and MFLAGS before calling make; allow override through $MAKE. * doc/invoke.texi (Optimize Options): Document override. simply checking with access (..., X_OK) of course doesn't work (that doesn't search the path...).
[Bug lto/48763] Inliner type ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48763 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org 2013-03-08 14:05:36 UTC --- Fixed. We substitute zero for the mismatched parameter. Eh.
[Bug tree-optimization/56522] [4.8 Regression] Bytemark ASSIGNMENT 9% / 11% slower
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56522 --- Comment #5 from wbrana wbrana at gmail dot com 2013-03-08 14:17:52 UTC --- weird results in comment 4 were caused by unexpected Gentoo patches and/or broken GIT I made own build which doesn't contain any Gentoo patches and still can reproduce 9% slow down caused by 196263 When I run reduced test there is only 1% slow down. Reduced test case has similar difference on my PC as in comment 2. I'm using -m64.
[Bug tree-optimization/56522] [4.8 Regression] Bytemark ASSIGNMENT 9% / 11% slower
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56522 --- Comment #6 from wbrana wbrana at gmail dot com 2013-03-08 14:22:03 UTC --- Created attachment 29622 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29622 assign.c with main function
[Bug tree-optimization/56522] [4.8 Regression] Bytemark ASSIGNMENT 9% / 11% slower
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56522 --- Comment #7 from wbrana wbrana at gmail dot com 2013-03-08 14:23:35 UTC --- Created attachment 29623 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29623 assign.c.164t.optimized.diff
[Bug tree-optimization/56522] [4.8 Regression] Bytemark ASSIGNMENT 9% / 11% slower
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56522 --- Comment #8 from wbrana wbrana at gmail dot com 2013-03-08 14:24:38 UTC --- Created attachment 29624 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29624 nbench1.c.164t.optimized.diff
[Bug tree-optimization/56478] [4.8 Regression] ICE: Floating point exception in tree_estimate_probability
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56478 --- Comment #5 from Marek Polacek mpolacek at gcc dot gnu.org 2013-03-08 14:41:20 UTC --- Author: mpolacek Date: Fri Mar 8 14:41:14 2013 New Revision: 196547 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196547 Log: PR tree-optimization/56478 * predict.c (is_comparison_with_loop_invariant_p): Change the type of loop_step to tree. (predict_loops): Adjust. (predict_iv_comparison): Perform the computations on double_ints. Added: trunk/gcc/testsuite/gcc.dg/torture/pr56478.c Modified: trunk/gcc/ChangeLog trunk/gcc/predict.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/56478] [4.8 Regression] ICE: Floating point exception in tree_estimate_probability
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56478 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Marek Polacek mpolacek at gcc dot gnu.org 2013-03-08 14:42:10 UTC --- Fixed.
[Bug rtl-optimization/56571] [4.7/4.8 Regression] ICE in copyprop_hardreg_forward_1, at regcprop.c (insn does not satisfy its constraints !)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56571
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||bernds at gcc dot gnu.org,
||jakub at gcc dot gnu.org,
||steven at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-08
14:49:10 UTC ---
Sounds like regrename.c bug. This pass changes:
83: {flags:CCZ=cmp(ax:SI|cx:SI,0);clobber ax:SI;}
instruction (iorsi_3) into:
83: {flags:CCZ=cmp(si:SI|cx:SI,0);clobber r10:SI;}
which of course doesn't work, the pattern has =r constraint on the clobber,
and %0 and rme constraints on the comparison operands, so it requires that
the clobber matches one of the registers.
I'm quite surprised not to see any validate_change calls in the whole
regrename.c, how does it ensure that what it changes is actually valid?
[Bug rtl-optimization/55177] missed optimizations with __builtin_bswap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55177 --- Comment #10 from Andrew Pinski pinskia at gcc dot gnu.org 2013-03-08 15:18:35 UTC --- Eric, I have some patches to improve __builtin_bswap* that I can line up for 4.9. Do you mind if I take this bug? They are located on the pinskia/bytewiseunop branch in git: http://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/pinskia/bytewiseunop
[Bug tree-optimization/56522] [4.8 Regression] Bytemark ASSIGNMENT 9% / 11% slower
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56522 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target||x86_64-*-* --- Comment #9 from Richard Biener rguenth at gcc dot gnu.org 2013-03-08 15:28:29 UTC --- I don't see any substantial differences in code-generation (register allocation and some basic-block order differences appear), and I cannot reproduce a slowdown. Flags as you cited: ./xgcc -B. -o t t.c -O3 -march=corei7 -fomit-frame-pointer -funroll-loops -ffast-math -static
[Bug tree-optimization/56273] [4.8 regression] Bogus -Warray-bounds warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56273 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2 Status|ASSIGNED|NEW AssignedTo|rguenth at gcc dot gnu.org |unassigned at gcc dot ||gnu.org --- Comment #13 from Richard Biener rguenth at gcc dot gnu.org 2013-03-08 15:33:17 UTC --- I give up. We have to live with this false positive.
[Bug rtl-optimization/56339] [4.8 Regression]: Suboptimal register allocation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56339 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org 2013-03-08 15:39:21 UTC --- So - what regressed this compared to 4.7? It wasn't regmove.c changes.
[Bug target/56470] [4.7/4.8 Regression] ICE output_operand: invalid shift operand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56470 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Priority|P3 |P2 Target Milestone|4.8.0 |4.7.3 Summary|[4.8 Regression] ICE|[4.7/4.8 Regression] ICE |output_operand: invalid |output_operand: invalid |shift operand |shift operand --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org 2013-03-08 15:46:00 UTC --- According to reporter also broken on the 4.7 branch.
[Bug rtl-optimization/56339] [4.8 Regression]: Suboptimal register allocation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56339 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|WAITING |NEW --- Comment #7 from Uros Bizjak ubizjak at gmail dot com 2013-03-08 15:51:15 UTC --- (In reply to comment #6) So - what regressed this compared to 4.7? It wasn't regmove.c changes. As said in comment 0: gcc-4.7 generates: f: addsd %xmm2, %xmm0 ret gcc-4.8 generates: f: addsd %xmm0, %xmm2 movapd %xmm2, %xmm0 ret
[Bug tree-optimization/56490] [4.6/4.7 Regression] -Wall triggering infinite loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56490 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2 Component|middle-end |tree-optimization Known to work||4.8.0 Blocks||47344 Summary|[4.6/4.7/4.8 Regression]|[4.6/4.7 Regression] -Wall |-Wall triggering infinite |triggering infinite loop |loop| --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org 2013-03-08 15:51:44 UTC --- Fixed on trunk by 2013-03-01 Xinliang David Li davi...@google.com * tree-ssa-uninit.c (compute_control_dep_chain): Limit post-dom walk length. after the patch: uninit var analysis : 1.05 (84%) usr so it's still very expensive.
[Bug libstdc++/56557] [4.8 Regression] Link error about `std::fstream' or `std::stringstream' with `-flto' and `-rdynamic' options
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56557 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1
[Bug c++/56567] [4.8 Regression] ICE with lambda return type deduction and braced-init-list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56567 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org 2013-03-08 15:55:28 UTC --- Author: jason Date: Fri Mar 8 15:55:18 2013 New Revision: 196548 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196548 Log: PR c++/56567 * semantics.c (apply_deduced_return_type): Don't allow returning std::initializer_list. Added: trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-initlist3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c
[Bug tree-optimization/56490] [4.6/4.7/4.8 Regression] -Wall triggering infinite loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56490 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work|4.8.0 | Summary|[4.6/4.7 Regression] -Wall |[4.6/4.7/4.8 Regression] |triggering infinite loop|-Wall triggering infinite ||loop Known to fail||4.8.0 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org 2013-03-08 16:03:30 UTC --- Clearly the limiting is bougs ... the issue is with large fanout BBs we recurse in compute_control_dep_chain which leads to exponential complexity. Limiting that to 8^5 isn't really a fix ... (yes, you can call that O(1)). compute_control_dep_chain is called 65 million times(!) for the testcase after the patch. There has to be a better algorithmic way of implementing this. IMHO still not fixed in 4.8.
[Bug c++/56222] Pointer to member in lambda should not require this to be captured
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56222 --- Comment #5 from Jason Merrill jason at gcc dot gnu.org 2013-03-08 16:03:57 UTC --- Author: jason Date: Fri Mar 8 16:03:48 2013 New Revision: 196549 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196549 Log: PR c++/51494 PR c++/51884 PR c++/56222 * tree.c (maybe_dummy_object): Don't capture 'this'. * semantics.c (maybe_resolve_dummy): New. (finish_non_static_data_member): Use it. (finish_qualified_id_expr): Don't test is_dummy_object. * cp-tree.h: Declare maybe_resolve_dummy. * call.c (build_new_method_call_1): Use it. Added: trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-this11.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/semantics.c trunk/gcc/cp/tree.c
[Bug c++/51494] Legal program rejection - capturing this when using static method inside lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51494 --- Comment #9 from Jason Merrill jason at gcc dot gnu.org 2013-03-08 16:03:57 UTC --- Author: jason Date: Fri Mar 8 16:03:48 2013 New Revision: 196549 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196549 Log: PR c++/51494 PR c++/51884 PR c++/56222 * tree.c (maybe_dummy_object): Don't capture 'this'. * semantics.c (maybe_resolve_dummy): New. (finish_non_static_data_member): Use it. (finish_qualified_id_expr): Don't test is_dummy_object. * cp-tree.h: Declare maybe_resolve_dummy. * call.c (build_new_method_call_1): Use it. Added: trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-this11.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/semantics.c trunk/gcc/cp/tree.c
[Bug c++/51884] [C++11] ICE with local class/lambda template argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51884 --- Comment #8 from Jason Merrill jason at gcc dot gnu.org 2013-03-08 16:03:57 UTC --- Author: jason Date: Fri Mar 8 16:03:48 2013 New Revision: 196549 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196549 Log: PR c++/51494 PR c++/51884 PR c++/56222 * tree.c (maybe_dummy_object): Don't capture 'this'. * semantics.c (maybe_resolve_dummy): New. (finish_non_static_data_member): Use it. (finish_qualified_id_expr): Don't test is_dummy_object. * cp-tree.h: Declare maybe_resolve_dummy. * call.c (build_new_method_call_1): Use it. Added: trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-this11.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/semantics.c trunk/gcc/cp/tree.c
[Bug c++/51884] [C++11] ICE with local class/lambda template argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51884 --- Comment #9 from Jason Merrill jason at gcc dot gnu.org 2013-03-08 16:04:30 UTC --- Author: jason Date: Fri Mar 8 16:04:15 2013 New Revision: 196551 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196551 Log: PR c++/51884 * class.c (modify_all_vtables): Mangle the vtable name before entering dfs_walk. Added: trunk/gcc/testsuite/g++.dg/cpp0x/local-targ1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c
[Bug rtl-optimization/56571] [4.7/4.8 Regression] ICE in copyprop_hardreg_forward_1, at regcprop.c (insn does not satisfy its constraints !)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56571 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-08 16:06:33 UTC --- Ok, it seems to be caused by rtl sharing of the clobber, which has been introduced by Honza: http://gcc.gnu.org/ml/gcc-patches/2004-01/msg01918.html Honza is going to try sharing only clobbers of hard regs that don't have ORIGINAL_REGNO set on them and disallow sharing anything else (plus copy it on copy_rtx etc.).
[Bug c++/51884] [C++11] ICE with local class/lambda template argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51884 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.8.0 --- Comment #10 from Jason Merrill jason at gcc dot gnu.org 2013-03-08 16:09:09 UTC --- Fixed for 4.8.
[Bug c++/56222] Pointer to member in lambda should not require this to be captured
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56222 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #6 from Jason Merrill jason at gcc dot gnu.org 2013-03-08 16:09:29 UTC --- Fixed for 4.8.
[Bug c++/51494] Legal program rejection - capturing this when using static method inside lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51494 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #10 from Jason Merrill jason at gcc dot gnu.org 2013-03-08 16:10:48 UTC --- Fixed for 4.8.
[Bug c++/52183] [C++0x] Redeclaration of __this in lambda inside template member function when calling static class function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52183 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org 2013-03-08 16:11:36 UTC --- Fixed for 4.8.
[Bug c++/56567] [4.8 Regression] ICE with lambda return type deduction and braced-init-list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56567 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | --- Comment #3 from Jason Merrill jason at gcc dot gnu.org 2013-03-08 16:13:53 UTC --- Fixed.
[Bug tree-optimization/56490] [4.6/4.7/4.8 Regression] -Wall triggering infinite loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56490 --- Comment #5 from davidxl xinliangli at gmail dot com 2013-03-08 16:21:13 UTC --- (In reply to comment #4) Clearly the limiting is bougs ... the issue is with large fanout BBs we recurse in compute_control_dep_chain which leads to exponential complexity. Limiting that to 8^5 isn't really a fix ... (yes, you can call that O(1)). compute_control_dep_chain is called 65 million times(!) for the testcase after the patch. There has to be a better algorithmic way of implementing this. IMHO still not fixed in 4.8. Right. However for on demand computation like this, limiting is still needed. For this particular case, limiting the depth to 3 (or may be smaller) won't cause any regressions.
[Bug target/56560] [4.6/4.7 regression] vzeroupper clobbers argument with AVX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56560
--- Comment #4 from H.J. Lu hjl.tools at gmail dot com 2013-03-08 17:21:18
UTC ---
The caller info is lost by
(gdb) bt
#0 init_cumulative_args (cum=0x7fffc3f0, fntype=0x71472e70,
libname=0x0, fndecl=0x0, caller=1)
at /export/gnu/import/git/gcc-release/gcc/config/i386/i386.c:5562
#1 0x00640011 in block_move_libcall_safe_for_call_parm ()
at /export/gnu/import/git/gcc-release/gcc/expr.c:1244
#2 0x0063fc07 in emit_block_move_hints (x=0x71470780,
y=0x71470750, size=0x7133a530, method=BLOCK_OP_CALL_PARM,
expected_align=0, expected_size=-1)
at /export/gnu/import/git/gcc-release/gcc/expr.c:1139
#3 0x0063ff3c in emit_block_move (x=0x71470780, y=0x71470750,
size=0x7133a530, method=BLOCK_OP_CALL_PARM)
at /export/gnu/import/git/gcc-release/gcc/expr.c:1206
#4 0x0064693a in emit_push_insn (x=0x71470750, mode=BLKmode,
type=0x71472690, size=0x7133a530, align=64, partial=0, reg=0x0,
extra=4, args_addr=0x71334560, args_so_far=0x7133a470,
reg_parm_stack_space=0, alignment_pad=0x7133a470)
at /export/gnu/import/git/gcc-release/gcc/expr.c:4116
#5 0x0056d1ad in store_one_arg (arg=0x7fffc760,
argblock=0x71334560, flags=0, variable_size=0, reg_parm_stack_space=0)
at /export/gnu/import/git/gcc-release/gcc/calls.c:4646
#6 0x00568b51 in expand_call (exp=0x71333cb0,
target=0x71461f00, ignore=0)
at /export/gnu/import/git/gcc-release/gcc/calls.c:3023
when storing struct S on stack. This patch:
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index c1f6c88..8005207 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -5562,7 +5562,7 @@ init_cumulative_args (CUMULATIVE_ARGS *cum, /* Argument
info to initialize */
memset (cum, 0, sizeof (*cum));
/* Initialize for the current callee. */
- if (caller)
+ if (caller fndecl)
{
cfun-machine-callee_pass_avx256_p = false;
cfun-machine-callee_return_avx256_p = false;
fixes it.
[Bug tree-optimization/56522] [4.8 Regression] Bytemark ASSIGNMENT 9% / 11% slower
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56522 --- Comment #10 from wbrana wbrana at gmail dot com 2013-03-08 17:27:49 UTC --- I found strange thing - result depends on linker there is slow down with GNU ld (GNU Binutils) 2.23.1 there is improvement with GNU gold (GNU Binutils 2.23.1) 1.11
[Bug tree-optimization/56522] [4.8 Regression] Bytemark ASSIGNMENT 9% / 11% slower
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56522 --- Comment #11 from wbrana wbrana at gmail dot com 2013-03-08 17:36:10 UTC --- GNU ld (GNU Binutils) 2.23.1 192263 - slow 192260 - fast GNU gold (GNU Binutils 2.23.1) 1.11 192263 - fast 192260 - slow It is possible that result also depends on CPU model (core count, cache size, etc.)
[Bug tree-optimization/56522] [4.8 Regression] Bytemark ASSIGNMENT 9% / 11% slower
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56522 --- Comment #12 from wbrana wbrana at gmail dot com 2013-03-08 17:41:09 UTC --- (In reply to comment #11) GNU ld (GNU Binutils) 2.23.1 192263 - slow 192260 - fast I meant 196260 and 196263
[Bug rtl-optimization/56339] [4.8 Regression]: Suboptimal register allocation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56339 --- Comment #8 from Steven Bosscher steven at gcc dot gnu.org 2013-03-08 18:49:09 UTC --- (In reply to comment #6) So - what regressed this compared to 4.7? It wasn't regmove.c changes. Probably LRA, it better respects IRA's choices (which is good). The fix should be found in a change to IRA or regmove.
[Bug c/56574] New: False possibly uninitialized variable warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56574
Bug #: 56574
Summary: False possibly uninitialized variable warning
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mark.d.rus...@intel.com
The following code produces the warning,'value' may be used uninitialized:
int get_value(void);
void show_problem(int flag)
{
int value;
if (!flag)
value = get_value();
for (;;) {
if (!flag value)
continue;
if (!flag)
break;
}
}
The warning occurs only with -O1 and -O2 optimization. -O0 and -O3 and higher
do not. It also occurs with many versions. I have gotten the same result with
the following versions of gcc:
i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5664)
gcc (SUSE Linux) 4.3.4 [gcc-4_3-branch revision 152973]
gcc (GCC) 4.4.6 20110731 (Red Hat 4.4.6-3)
gcc (GCC) 4.7.0 20120507 (Red Hat 4.7.0-5)
Interestingly, the much larger function that originally displayed the problem
does not generate a warning with the 4.7.0 compiler, but does on the others.
[Bug c/56574] False possibly uninitialized variable warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56574 --- Comment #1 from Mark Rustad mark.d.rustad at intel dot com 2013-03-08 19:24:27 UTC --- It also appears that incorrect code is generated in cases where the warning is produced. That incorrect code was referencing the uninitialized value. So the warning is consistent with the code generated, but the code is wrong.
[Bug rtl-optimization/56339] [4.8 Regression]: Suboptimal register allocation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56339 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-08 19:46:59 UTC --- You don't need to guess, http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55941#c1 mentions the commits that regressed it.
[Bug middle-end/56574] False possibly uninitialized variable warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56574 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Component|c |middle-end --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2013-03-08 19:51:05 UTC --- I don't think it matters if the unitialized value is used in this case as: pretmp_14 = flag_3(D) == 0; pretmp_1 = value_12 != 0; pretmp_15 = pretmp_1 pretmp_14; pretmp_14 will always be false (0) so pretmp_15 wil also be false (0)
[Bug libgomp/56357] [4.8 Regression] missing symbol references for libgomp when using -flto -fopenmp on mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56357 --- Comment #4 from Daniel Starke daniel.f.starke at freenet dot de 2013-03-08 20:05:19 UTC --- I tried the same configuration in a different mingw build environment for gcc. The resulting gcc build worked fine and did not show the described issue.
[Bug middle-end/56574] False possibly uninitialized variable warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56574 Thiago Macieira thiago at kde dot org changed: What|Removed |Added CC||thiago at kde dot org --- Comment #3 from Thiago Macieira thiago at kde dot org 2013-03-08 21:11:19 UTC --- Looking at the code that GCC generated (4.7.2 from Fedora and similarly with pristine 4.8 trunk@196249): %edi = flag; %eax = value 11 testl %edi, %edi 12 je .L12 .L12 is the call to get_value() is placed 13 .L2: 14 testl %edi, %edi 15 sete%dl 16 testl %eax, %eax Here, EAX might be uninitialised 17 setne %al 18 testb %dl, %al 19 jne .L3 .L3 is an infinite loop 20 testb %dl, %dl 21 jne .L8 .L8 is the function exit (the loop break) fall-through is an infinite loop In other words, the warning is true: the generated code *is* using an uninitialised variable. The question is whether that is acceptable. In order for EAX to be uninitialised, we must not have jumped to .L12. Since the JE jump on line 12 was not taken, SETE must have set DL to 0 on line 15. Then we compare AL to DL on line 18: as DL is zero, the result of the comparison is ZF, whichever the value of AL might be. That means the JNZ jump on line 19 is not taken. The code will then proceed to the infinite loop. Conclusion: it's just a bogus warning. It is correct from the point of view of the assembly code that was generated, but the uninitialised value is never used in any decisions.
[Bug middle-end/56574] False possibly uninitialized variable warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56574 --- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org 2013-03-08 21:25:47 UTC --- (In reply to comment #3) Looking at the code that GCC generated (4.7.2 from Fedora and similarly with pristine 4.8 trunk@196249): For -O2, the generated code looks though: testl%edi, %edi sete%dl testl%eax, %eax setne%al andl%edx, %eax Here eax might be uninitialized but that is ok because dl will always be 0 when it is.
[Bug c++/56565] lambda function in NSMI fails to capture non-static data member.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56565 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2013-03-08 22:35:33 UTC --- This got fixed by today's commits. I'm adding the testcase and closing the PR.
[Bug c++/51412] [c++0x] Broken diagnostic with invalid lambda expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51412 --- Comment #2 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2013-03-08 22:37:10 UTC --- Author: paolo Date: Fri Mar 8 22:37:04 2013 New Revision: 196563 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196563 Log: /cp 2013-03-08 Paolo Carlini paolo.carl...@oracle.com PR c++/51412 * cxx-pretty-print.c (pp_cxx_expression): Handle LAMBDA_EXPR. * error.c (dump_expr): Likewise. /testsuite 2013-03-08 Paolo Carlini paolo.carl...@oracle.com PR c++/51412 * g++.dg/cpp0x/lambda/lambda-err3.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-err3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cxx-pretty-print.c trunk/gcc/cp/error.c trunk/gcc/testsuite/ChangeLog
[Bug c++/51412] [c++0x] Broken diagnostic with invalid lambda expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51412 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2013-03-08 22:38:28 UTC --- Fixed for 4.8.0.
[Bug c++/56565] lambda function in NSMI fails to capture non-static data member.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56565 --- Comment #3 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2013-03-08 22:52:54 UTC --- Author: paolo Date: Fri Mar 8 22:52:36 2013 New Revision: 196564 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196564 Log: 2013-03-08 Paolo Carlini paolo.carl...@oracle.com PR c++/56565 * g++.dg/cpp0x/lambda/lambda-nsdmi2.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-nsdmi2.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/56565] lambda function in NSMI fails to capture non-static data member.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56565 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2013-03-08 22:55:30 UTC --- Done.
[Bug fortran/56575] New: An invalid OO code causes ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56575 Bug #: 56575 Summary: An invalid OO code causes ICE Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: latlon90180+gcc_bugzi...@gmail.com Dear all, An invalid code shown below causes ICE on gfortran 4.8.0 and gfortran 4.6.3. gfortran 4.5.3 produces proper error messages for the code. Sincerely, Amato $ cat ice.F90 module lib_container implicit none type:: Object end type Object type:: Container class(Object):: v end type Container contains subroutine proc(self) class(Container), intent(inout):: self end subroutine proc end module lib_container -4.8- $ /usr/lib/gcc-snapshot/bin/gfortran ice.F90 -c f951: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-snapshot/README.Bugs for instructions. $ /usr/lib/gcc-snapshot/bin/gfortran --version GNU Fortran (Ubuntu/Linaro 20120314-0ubuntu2) 4.8.0 20120314 (experimental) [trunk revision 185382] Copyright (C) 2012 Free Software Foundation, Inc. GNU Fortran comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of GNU Fortran under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING -4.6- $ gfortran-4.6 ice.F90 -c f951: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See file:///share/doc/gcc-4.6/README.Bugs for instructions. $ gfortran-4.6 --version GNU Fortran (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3 Copyright (C) 2011 Free Software Foundation, Inc. GNU Fortran comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of GNU Fortran under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING -4.5- $ gfortran-4.5 ice.F90 -c ice.F90:8.21: class(Object):: v 1 Error: Component 'v' with CLASS at (1) must be allocatable or pointer ice.F90:8.21: class(Object):: v 1 Error: Component 'v' with CLASS at (1) must be allocatable or pointer $ gfortran-4.5 --version GNU Fortran (Ubuntu/Linaro 4.5.3-12ubuntu2) 4.5.3 Copyright (C) 2010 Free Software Foundation, Inc. GNU Fortran comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of GNU Fortran under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING
[Bug rtl-optimization/55177] missed optimizations with __builtin_bswap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55177 --- Comment #11 from Eric Botcazou ebotcazou at gcc dot gnu.org 2013-03-09 00:05:46 UTC --- Eric, I have some patches to improve __builtin_bswap* that I can line up for 4.9. Do you mind if I take this bug? They are located on the pinskia/bytewiseunop branch in git: http://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/pinskia/bytewiseunop I have something too (albeit preliminary), but go ahead.
[Bug tree-optimization/55177] missed optimizations with __builtin_bswap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55177 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Component|rtl-optimization|tree-optimization AssignedTo|ebotcazou at gcc dot|pinskia at gcc dot gnu.org |gnu.org | --- Comment #12 from Andrew Pinski pinskia at gcc dot gnu.org 2013-03-09 00:16:23 UTC --- Mine for 4.9. I will also post the bswap for mipsr2 at the same time as I post these.
[Bug tree-optimization/56576] New: wrong code for aliased union at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56576
Bug #: 56576
Summary: wrong code for aliased union at -O3
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dhaze...@yahoo.com
The following code behaves differently at -O3 than at -O2 or below on 4.7 and
mainline on x86_64-linux. At -O3 it returns 1, whereas at -O2 and below it
returns 0, for both -m32 and -m64 targets.
It behaves as expected on gcc 4.6 at all optimization levels (returns 0).
$ gcc-trunk --version
gcc-trunk (GCC) 4.8.0 20130308 (experimental) [trunk revision 196555]
$ gcc-trunk -O2 trans-reduced.c
$ ./a.out
$ echo $?
0
$ gcc-trunk -O3 trans-reduced.c
$ ./a.out
$ echo $?
1
$ gcc-4.6 -O3 trans-reduced.c
$ ./a.out
$ echo $?
0
$ cat trans-reduced.c
/* gcc-4.7/gcc-trunk -O3 -m32/-m64 */
union
{
int f0;
int f1;
long f2;
}
a, b;
int c, h;
int *d, *e = a.f0;
long *f = b.f2;
int **g = d;
void fn1 ()
{
c = 0;
for (; c = 3; c++)
{
int *i = b.f1;
*f = 1;
*i = 0;
*g = 0;
h = *e;
}
}
int main ()
{
fn1 ();
return b.f0;
}
[Bug tree-optimization/56577] New: wrong code for aliased union on gcc 4.7 only
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56577
Bug #: 56577
Summary: wrong code for aliased union on gcc 4.7 only
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dhaze...@yahoo.com
The following code behaves differently at -O3 than at -O2 or below on 4.7 on
x86_64-linux. At -O3 it returns 1, whereas at -O2 and below it
returns 0, for both -m32 and -m64 targets.
It behaves consistently on gcc 4.6 at all optimization levels (returns 0). It
may be related to 56576 (derived from a similar testcase) but that bug is also
present on mainline.
$ gcc-4.7 --version
gcc-4.7 (GCC) 4.7.2
$ gcc-4.7 -O2 orig-reduced.c
$ ./a.out
$ echo $?
0
$ gcc-4.7 -O3 orig-reduced.c
$ ./a.out
$ echo $?
1
$ gcc-4.6 -O3 orig-reduced.c
$ ./a.out
$ echo $?
0
$ cat orig-reduced.c
/* gcc-4.7 -O3 -m32/-m64 (works with trunk or at -O2) */
union
{
int f0;
int f1;
long f2;
}
b, *g, **i = g;
int a, m;
int *c = (int *)b.f2, *e, *f = a;
int d;
int h;
long **j = (long **)c;
int k;
int **l = e;
void fn1 ()
{
d = 0;
for (; d = 3; d++)
{
k = 0;
for (; k = 3; k++)
{
int *n = b.f1;
*i = 0;
**j = 1;
*n = 0;
*l = 0;
}
m = *f;
a = 1;
for (; a = 0; a--)
h = 1;
}
}
int main ()
{
fn1 ();
return b.f0;
}
[Bug c++/56493] Performance regression in google dense hashmap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56493 --- Comment #7 from Andrew Gallagher andrewjcg at gmail dot com 2013-03-09 04:17:39 UTC --- I was able to bisect this to http://gcc.gnu.org/viewcvs?view=revisionrevision=172430. I haven't had time to dig in further, but that rev looks like it has plenty of inlining changes, which makes sense.
[Bug middle-end/56524] [4.8 Regression] Compiler ICE when compiling with -mips16
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56524 --- Comment #11 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org 2013-03-09 07:54:08 UTC --- Author: rsandifo Date: Sat Mar 9 07:54:02 2013 New Revision: 196570 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196570 Log: gcc/ PR middle-end/56524 * tree.h (tree_optimization_option): Rename target_optabs to optabs. Add base_optabs. (TREE_OPTIMIZATION_OPTABS): Update after previous field change. (TREE_OPTIMIZATION_BASE_OPTABS): New macro. (save_optabs_if_changed): Replace with... (init_tree_optimization_optabs): ...this. * optabs.c (save_optabs_if_changed): Rename to... (init_tree_optimization_optabs): ...this. Take the optimization node as argument. Do nothing if the base optabs are already correct. Reuse the existing TREE_OPTIMIZATION_OPTABS memory if we need to recompute optabs. * function.h (function): Remove optabs field. * function.c (invoke_set_current_function_hook): Call init_tree_optimization_optabs. Use the result to initialize this_fn_optabs. gcc/c-family/ PR middle-end/56524 * c-common.c (handle_optimize_attribute): Don't call save_optabs_if_changed. gcc/testsuite/ PR middle-end/56524 * gcc.target/mips/pr56524.c: New test. Added: trunk/gcc/testsuite/gcc.target/mips/pr56524.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.c trunk/gcc/function.c trunk/gcc/function.h trunk/gcc/optabs.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree.h
