[Bug c/63480] -Wmissing-field-initializers should not warn about intentionally empty initializers (or that should be a separate option)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63480 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-10-08 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1
[Bug lto/61886] [4.8/4.9/5 Regression] LTO breaks fread with _FORTIFY_SOURCE=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886 --- Comment #23 from rguenther at suse dot de rguenther at suse dot de --- On Tue, 7 Oct 2014, hubicka at ucw dot cz wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886 --- Comment #22 from Jan Hubicka hubicka at ucw dot cz --- We can also put warning attribute into gimple call. I like that better. We can easily add a GF_CALL_WARN / GF_CALL_ERROR flag, but the question is where to put the warning string... the issue with this bugreport is that it might not be on the decl (because the decl is now replaced with one with/without the attribute). Maybe if we always merge the warning attributes then the call flag tells us whether to ignore it or not ... Thus for this particular bug (bogus warning) just adding the flag as a requirement to emit the warning/error would be enough. We may still lose warnings/errors if the wrong decl is picked for a GF_CALL_WARN call though. Yeah, now the idea of adding a generic annotation pointer to gimple stmts will pop up again ... of course I don't like that very much. OTOH we had the idea of avoiding warnings from the middle-end for dead code by queuing warnings to emit on stmts and only emit them if the stmt is still live at a certain point during the compilation. All that said - what about going with the simple GF_CALL_WARN_OR_ERROR flag to avoid the false positives?
[Bug target/63352] problem with fmt_g0_1.f08 on i386-pc-solaris2.11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63352 --- Comment #16 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE --- Well, I get this, for example: In file included from opncls.c:26:0: opncls.c: In function 'bfd_fopen': bfd.h:529:65: error: right-hand operand of comma expression has no effect [-Werror=unused-value] #define bfd_set_cacheable(abfd,bool) (((abfd)-cacheable = bool), TRUE) ^ opncls.c:263:5: note: in expansion of macro 'bfd_set_cacheable' bfd_set_cacheable (nbfd, TRUE); ^ Please configure with --disable-werror and file a gdb bug. This is not the place to discuss gdb build issues. Thanks. Rainer
[Bug ipa/63482] New: [5 Regression] ICE: in gimple_get_virt_method_for_vtable, at gimple-fold.c:4857
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63482 Bug ID: 63482 Summary: [5 Regression] ICE: in gimple_get_virt_method_for_vtable, at gimple-fold.c:4857 Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: trippels at gcc dot gnu.org Running the Boost library testsuite, I get: % g++ -O2 -std=c++11 CustomReactionTest.ii ../libs/statechart/test/CustomReactionTest.cpp:381:1: internal compiler error: in gimple_get_virt_method_for_vtable, at gimple-fold.c:4857 } ^ 0x12293d7 ipa_get_indirect_edge_target_1 ../../gcc/gcc/ipa-cp.c:1599 0xa3807a estimate_edge_devirt_benefit ../../gcc/gcc/ipa-inline-analysis.c:2979 0xa38dd9 estimate_edge_size_and_time ../../gcc/gcc/ipa-inline-analysis.c:3018 0xa38dd9 estimate_calls_size_and_time ../../gcc/gcc/ipa-inline-analysis.c:3083 0xa38c44 estimate_calls_size_and_time ../../gcc/gcc/ipa-inline-analysis.c:3071 0xa38c44 estimate_calls_size_and_time ../../gcc/gcc/ipa-inline-analysis.c:3071 0xa3b9af estimate_node_size_and_time ../../gcc/gcc/ipa-inline-analysis.c:3178 0xa3bd87 do_estimate_edge_time(cgraph_edge*) ../../gcc/gcc/ipa-inline-analysis.c:3673 0xa3e317 do_estimate_edge_size(cgraph_edge*) ../../gcc/gcc/ipa-inline-analysis.c:3724 0xa3e538 estimate_edge_size ../../gcc/gcc/ipa-inline.h:288 0xa3e538 estimate_edge_growth ../../gcc/gcc/ipa-inline.h:302 0xa3e538 estimate_size_after_inlining(cgraph_node*, cgraph_edge*) ../../gcc/gcc/ipa-inline-analysis.c:3817 0x1235fff caller_growth_limits ../../gcc/gcc/ipa-inline.c:186 0x1235fff can_inline_edge_p ../../gcc/gcc/ipa-inline.c:349 0x1238797 update_caller_keys ../../gcc/gcc/ipa-inline.c:1185 0x1239760 inline_small_functions ../../gcc/gcc/ipa-inline.c:1823 0x123a149 ipa_inline ../../gcc/gcc/ipa-inline.c:2175 0x123a149 execute ../../gcc/gcc/ipa-inline.c:2535 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. Reducing.
[Bug go/60406] recover.go: test13reflect2 test failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406 --- Comment #22 from Dominik Vogt vogt at linux dot vnet.ibm.com --- Hm, so the patch penalises platforms that cannot deal with the 16 byte window? Yes, but, recall that on your system almost all tests pass using the code that is in the tree today, before your patch. But they really only succeed by accident. The call for any platform might introduce control flow into the thunk and trigger the problem in any of the test cases. The spec says Suppose a function G defers a function D that calls recover and a panic occurs in a function on the same goroutine in which G is executing. The order is 1) G defers D; 2) a panic occurs. ... I'd still not understand it that way, but from other documentation the intention is clear. Maybe another bullet could be added to the list below: The return value of recover is nil if ... ... * defer was called when the panic already existed
[Bug target/63478] internal compiler error: in sparc_emit_set_const64, at config/sparc/sparc.c:2061
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63478 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ebotcazou at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #4 from Eric Botcazou ebotcazou at gcc dot gnu.org --- . *** This bug has been marked as a duplicate of bug 34191 ***
[Bug target/34191] Using gcc with -mptr64 option on Solaris 5.9 produces the following message: the internal compiler error: in sparc_emit_set_const64, at config/sparc/sparc.c:1669
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34191 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added CC||dev at cor0 dot com --- Comment #6 from Eric Botcazou ebotcazou at gcc dot gnu.org --- *** Bug 63478 has been marked as a duplicate of this bug. ***
[Bug lto/61886] [4.8/4.9/5 Regression] LTO breaks fread with _FORTIFY_SOURCE=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886 --- Comment #24 from Jakub Jelinek jakub at gcc dot gnu.org --- But is warning/error attribute the only thing on aliases that can hold extra semantics info (now or in the future)? I'd say LTO symtab merging should merge what is mergeable, and should leave leave as separate decls with the same asm-name what holds non-mergeable semantics on it. Say, if you declare some function (or different, just with same asm name) with warning attribute in one TU, with error attribute in another TU and without it on another TU, IMHO those three decls shouldn't be merged together, you should note in cgraph that you have aliases that have the same asm name but different semantics and just ensure that you use the right cgraph nodes and decls in the corresponding callers.
[Bug rtl-optimization/63483] New: Scheduler performs Invalid move of aliased memory reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483
Bug ID: 63483
Summary: Scheduler performs Invalid move of aliased memory
reference
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ubizjak at gmail dot com
CC: rguenth at gcc dot gnu.org, rth at gcc dot gnu.org
The original problem is present in [1], and can be illustrated by following
test on alpha-linux-gnu:
--cut here--
static char *a;
static char *b;
void foo (void)
{
a[1] = 1;
b[2] = 1;
}
int bar (void)
{
return a b;
}
--cut here--
The compilation with -O2 produces:
$foo..ng:
.prologue 1
lda $1,1($31)
lda $2,a
ldq $3,0($2) -- load a
lda $2,b
lda $7,1($3)
ldq_u $5,1($3) -- load a
insbl $1,$7,$4
ldq $2,0($2) -- load b
mskbl $5,$7,$5
lda $6,2($2)
bis $4,$5,$4
stq_u $4,1($3) -- store a
insbl $1,$6,$1
ldq_u $3,2($2) -- load b
mskbl $3,$6,$3
cpys $f31,$f31,$f31
bis $1,$3,$1
stq_u $1,2($2) -- store b
ret $31,($26),1
.end foo
if a and b alias to the same wide memory location, then b RMW
sequence corrupts a.
There is am early shortcut for MEM_READOLNY_P in true_dependence_1 in alias.c.
For the testcase above:
(insn 15 13 18 2 (set (reg/f:DI 78 [ b ])
(mem/u/f/c:DI (reg/f:DI 79) [2 b+0 S8 A64])) rmw.c:7 226 {*movdi}
(expr_list:REG_DEAD (reg/f:DI 79)
(nil)))
is free to be scheduled before
(insn 13 12 15 2 (set (mem:DI (and:DI (plus:DI (reg/f:DI 72 [ a ])
(const_int 1 [0x1]))
(const_int -8 [0xfff8])) [0 S8 A64])
(reg:DI 77)) rmw.c:6 226 {*movdi}
(expr_list:REG_DEAD (reg:DI 77)
(expr_list:REG_DEAD (reg/f:DI 72 [ a ])
(nil
rth explained situation on alpha a bit:
--quote--
It's not the loads, per se, it's the stores that get in the way.
Early alpha can't store sub-4-byte quantities. Altivec can't store anything
but 16 byte quantities. In order to perform smaller stores, we have to do a
read-modify-write sequence on a larger aligned chunk of memory. Two such RMW
sequences must conflict, lest we interleave and thus bork the operation.
I don't recall how much we ever did for this, exactly, but it's certainly
possible to know that some memory operations cannot conflict with these RMW
sequence. E.g. through size + alignment of the other memory operation. E.g.
on Alpha, a byte RMW store can't conflict with a normal DImode memory access.
--/quote--
And:
Btw, if the mem is MEM_READONLY_P how can it be part of
a {un}aligned_store sequence?
This flag is copied from the original memory operand of the store by
alpha_set_memflags to all memory operands in the expanded sequence.
[1] https://gcc.gnu.org/ml/gcc-patches/2014-06/msg02251.html
[Bug target/63478] internal compiler error: in sparc_emit_set_const64, at config/sparc/sparc.c:2061
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63478 --- Comment #5 from Dennis Clarke dev at cor0 dot com --- (In reply to Andrew Pinski from comment #3) Why are you trying to use -mptr64 anyways? Especially without -m64 ? Reasonable question. I often bootstrap GCC and then try a whole series of simple tests *after* I run the whole testsuite. To be honest I had not seen an ICE before and was surprised to see it. As for -mptr64, well yes it was a dumb idea. Given that it isn't documented anywhere. At least it does not seem to exist anywhere here : https://gcc.gnu.org/onlinedocs/gcc-4.7.4/gcc/ Some of the little tests I run involved posix thread dispatch tests as well as slogging memory around and some are simple floating point performance tests. I look at the output assembly from both GCC and Oracle Studio tools. There really is not much of a performance gap anymore unless you are in possession of a Sparc T5 or some server with 256 processor cores. Regardless, looks like a red herring : https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34191
[Bug target/63478] internal compiler error: in sparc_emit_set_const64, at config/sparc/sparc.c:2061
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63478 --- Comment #6 from Dennis Clarke dev at cor0 dot com --- *** This bug has been marked as a duplicate of bug 34191 *** Not really a duplicate but close enough. This is Solaris 10 and I bet we see the same thing on Solaris 11. If anyone actually uses that. dc
[Bug rtl-optimization/63483] Scheduler performs Invalid move of aliased memory reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483 --- Comment #1 from Uroš Bizjak ubizjak at gmail dot com --- $foo..ng: .prologue 1 lda $1,1($31) # 7*movqi/2[length = 4] lda $2,a # 27*movdi/7[length = 4] ldq $3,0($2) # 6*movdi/8[length = 4] lda $2,b # 26*movdi/7[length = 4] lda $7,1($3) # 9*adddi_internal/2[length = 4] ldq_u $5,1($3) # 8*movdi/8[length = 4] insbl $1,$7,$4 # 11insbl[length = 4] ldq $2,0($2) # 15*movdi/8[length = 4] mskbl $5,$7,$5 # 10mskxl[length = 4] lda $6,2($2) # 18*adddi_internal/2[length = 4] bis $4,$5,$4 # 12iordi3/1[length = 4] stq_u $4,1($3) # 13*movdi/9[length = 4] insbl $1,$6,$1 # 20insbl[length = 4] ldq_u $3,2($2) # 17*movdi/8[length = 4] mskbl $3,$6,$3 # 19mskxl[length = 4] cpys $f31,$f31,$f31 # 35fnop[length = 4] bis $1,$3,$1 # 21iordi3/1[length = 4] stq_u $1,2($2) # 22*movdi/9[length = 4] ret $31,($26),1 # 34*return_internal[length = 4] .end foo Before sched1 pass, we have: 5: r73:DI=`a' 6: r72:DI=[r73:DI] REG_DEAD r73:DI 7: r74:QI=0x1 8: r76:DI=[r72:DI+0x10xfff8] 9: r75:DI=r72:DI+0x1 10: r76:DI=!0xffr75:DI0x3r76:DI 11: r77:DI=zero_extend(r74:QI)r75:DI0x3 REG_DEAD r75:DI REG_EQUAL 0x1r75:DI0x3 12: r77:DI=r77:DI|r76:DI REG_DEAD r76:DI 13: [r72:DI+0x10xfff8]=r77:DI REG_DEAD r77:DI REG_DEAD r72:DI 14: r79:DI=`b' 15: r78:DI=[r79:DI] REG_DEAD r79:DI 17: r82:DI=[r78:DI+0x20xfff8] 18: r81:DI=r78:DI+0x2 19: r82:DI=!0xffr81:DI0x3r82:DI 20: r83:DI=zero_extend(r74:QI)r81:DI0x3 REG_DEAD r81:DI REG_DEAD r74:QI REG_EQUAL 0x1r81:DI0x3 21: r83:DI=r83:DI|r82:DI REG_DEAD r82:DI 22: [r78:DI+0x20xfff8]=r83:DI REG_DEAD r83:DI REG_DEAD r78:DI Please see (insn 15) going to the top in sched1 pass: 5: r73:DI=`a' 7: r74:QI=0x1 14: r79:DI=`b' 6: r72:DI=[r73:DI] REG_DEAD r73:DI 15: r78:DI=[r79:DI] REG_DEAD r79:DI 9: r75:DI=r72:DI+0x1 8: r76:DI=[r72:DI+0x10xfff8] 11: r77:DI=zero_extend(r74:QI)r75:DI0x3 REG_DEAD r75:DI REG_EQUAL 0x1r75:DI0x3 18: r81:DI=r78:DI+0x2 10: r76:DI=!0xffr75:DI0x3r76:DI 20: r83:DI=zero_extend(r74:QI)r81:DI0x3 REG_DEAD r81:DI REG_DEAD r74:QI REG_EQUAL 0x1r81:DI0x3 12: r77:DI=r77:DI|r76:DI REG_DEAD r76:DI 13: [r72:DI+0x10xfff8]=r77:DI REG_DEAD r77:DI REG_DEAD r72:DI 17: r82:DI=[r78:DI+0x20xfff8] 19: r82:DI=!0xffr81:DI0x3r82:DI 21: r83:DI=r83:DI|r82:DI REG_DEAD r82:DI 22: [r78:DI+0x20xfff8]=r83:DI REG_DEAD r83:DI REG_DEAD r78:DI 25: NOTE_INSN_DELETED
[Bug rtl-optimization/63483] Scheduler performs Invalid move of aliased memory reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483 --- Comment #2 from Uroš Bizjak ubizjak at gmail dot com --- Created attachment 33665 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33665action=edit Proposed patch Proposed patch prevents MEM_READONLY_P memory references to be moved over possibly aliased memory (with alignment ANDs). The patch prevents early exit for MEM_READONLY_P references when alignemt ANDs are involved. The aliasing is determined in the code later in the function.
[Bug rtl-optimization/63483] Scheduler performs Invalid move of aliased memory reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483 --- Comment #3 from Uroš Bizjak ubizjak at gmail dot com --- The patched compiler creates prevents scheduler to move unchanging reference over possibly aliasing memory: 7: r74:QI=0x1 5: r73:DI=`a' 14: r79:DI=`b' 6: r72:DI=[r73:DI] REG_DEAD r73:DI 9: r75:DI=r72:DI+0x1 8: r76:DI=[r72:DI+0x10xfff8] 11: r77:DI=zero_extend(r74:QI)r75:DI0x3 REG_DEAD r75:DI REG_EQUAL 0x1r75:DI0x3 10: r76:DI=!0xffr75:DI0x3r76:DI 12: r77:DI=r77:DI|r76:DI REG_DEAD r76:DI 13: [r72:DI+0x10xfff8]=r77:DI REG_DEAD r77:DI REG_DEAD r72:DI 15: r78:DI=[r79:DI] REG_DEAD r79:DI 18: r81:DI=r78:DI+0x2 17: r82:DI=[r78:DI+0x20xfff8] 20: r83:DI=zero_extend(r74:QI)r81:DI0x3 REG_DEAD r81:DI REG_DEAD r74:QI REG_EQUAL 0x1r81:DI0x3 19: r82:DI=!0xffr81:DI0x3r82:DI 21: r83:DI=r83:DI|r82:DI REG_DEAD r82:DI 22: [r78:DI+0x20xfff8]=r83:DI REG_DEAD r83:DI REG_DEAD r78:DI 25: NOTE_INSN_DELETED which results in: $foo..ng: .prologue 1 lda $1,1($31)# 7*movqi/2[length = 4] lda $2,a # 5*movdi/7[length = 4] ldq $2,0($2) # 6*movdi/8[length = 4] bis $31,$31,$31 # 34 nop [length = 4] lda $5,1($2) # 9*adddi_internal/2 [length = 4] ldq_u $4,1($2) # 8*movdi/8[length = 4] insbl $1,$5,$3 # 11 insbl [length = 4] mskbl $4,$5,$4 # 10 mskxl [length = 4] bis $3,$4,$3 # 12 iordi3/1[length = 4] stq_u $3,1($2) # 13 *movdi/9[length = 4] lda $2,b # 26 *movdi/7[length = 4] ldq $2,0($2) # 15 *movdi/8[length = 4] lda $4,2($2) # 18 *adddi_internal/2 [length = 4] ldq_u $3,2($2) # 17 *movdi/8[length = 4] insbl $1,$4,$1 # 20 insbl [length = 4] mskbl $3,$4,$3 # 19 mskxl [length = 4] bis $1,$3,$1 # 21 iordi3/1[length = 4] stq_u $1,2($2) # 22 *movdi/9[length = 4] ret $31,($26),1 # 33 *return_internal[length = 4] .end foo e.g. (insn 15) stays after possibly aliasing (insn 13).
[Bug tree-optimization/63445] [5 Regression] request: make -Wstrict-overflow avoid a class of false positives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63445 --- Comment #7 from Eric Botcazou ebotcazou at gcc dot gnu.org --- The range of n_7 is suboptimal and the test on _6 can be eliminated. The previous enhancement was apparently: 2010-04-06 Richard Guenther rguent...@suse.de PR tree-optimization/43627 * tree-vrp.c (extract_range_from_unary_expr): Widenings of [1, +INF(OVF)] go to [1, +INF(OVF)] of the wider type, not varying. but it didn't go far enough for this case.
[Bug rtl-optimization/63483] Scheduler performs Invalid move of aliased memory reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483 --- Comment #4 from Uroš Bizjak ubizjak at gmail dot com --- Patch at [1]. [1] https://gcc.gnu.org/ml/gcc-patches/2014-10/msg00625.html
[Bug rtl-optimization/63483] Scheduler performs Invalid move of aliased memory reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-10-08 Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com Ever confirmed|0 |1
[Bug c/63480] -Wmissing-field-initializers should not warn about intentionally empty initializers (or that should be a separate option)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63480 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic CC||manu at gcc dot gnu.org --- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org --- Wasn't this fixed for C++ recently? Perhaps the code could be shared... In any case, they should behave similarly.
[Bug c/63480] -Wmissing-field-initializers should not warn about intentionally empty initializers (or that should be a separate option)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63480
--- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org ---
I think it makes sense just not to warn on { }, much as we intentionally don't
warn for { 0 }.
I'm testing a patch.
[Bug c/63480] -Wmissing-field-initializers should not warn about intentionally empty initializers (or that should be a separate option)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63480
--- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org ---
In C++ we don't warn for { }. OTOH, C++ warns for { 0 } - I think it should
not.
[Bug c/63480] -Wmissing-field-initializers should not warn about intentionally empty initializers (or that should be a separate option)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63480
--- Comment #4 from Manuel López-Ibáñez manu at gcc dot gnu.org ---
Found it: PR61489
I think warning for {0} is on purpose, since one cannot tell if the struct
originally had one field and now it has two. But I don't really agree with it.
I think it is too noisy.
[Bug go/60406] recover.go: test13reflect2 test failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406
--- Comment #23 from Dominik Vogt vogt at linux dot vnet.ibm.com ---
Regarding the new patch:
1) We need to call __builtin_extract_return_address(retaddr) in
__go_set_defer_retaddr() too. (On s390 (31 bit) this is necessary to remove
the most significant bit of the address which indicates the addressing mode.)
I.e.
--snip--
-g-defer-__retaddr = retaddr;
+g-defer-__retaddr = __builtin_extract_return_addr (retaddr);
--snip--
2) The new patch does not compile for me:
--
In file included from ../../../libgo/runtime/go-check-interface.c:8:0:
../../../libgo/runtime/go-panic.h:43:13: error: conflicting types for
‘__go_makefunc_can_recover’
extern void __go_makefunc_can_recover (void *retaddr);
^
In file included from ../../../libgo/runtime/go-check-interface.c:7:0:
../../../libgo/runtime/runtime.h:845:9: note: previous declaration of
‘__go_makefunc_can_recover’ was here
void__go_makefunc_can_recover (const void *);
^
--
In runtime.h, __go_makefunc_can_recover still has a const argument:
--snip--
-void__go_makefunc_can_recover (const void *);
+void__go_makefunc_can_recover (void *);
--snip--
3) Couldn't this be written more efficiently by passing a flag?
+ /* If we are called from __go_makefunc_can_recover, then we need to
+ look one level higher. */
+ if (locs[0].function.len 0
+ __builtin_strcmp ((const char *) locs[0].function.str,
+ __go_makefunc_can_recover) == 0)
E.g.
_Bool __go_can_recover (void *retaddr, _Bool called_by_makefunc_can_recover)
{
...
if (called_by_makefunc_can_recover)
{ do something }
else
{ do something else }
...
}
4) With the suggested changes from 1 and 2 above:
s390x (64 bit):
* PASS: test/recover.go
* the test from #4 in my earlier posting works as expected
* my private defer/recover/panic testsuite works as expected
s390 (31 bit):
* PASS: test/recover.go
* the test from #4 in my earlier posting works as expected
* my private defer/recover/panic testsuite works as expected
5) I find the assumption in the loop at the end of __go_can_recover() that if a
caller's name begins with __go_ that means the panic can be recovered, a bit
hairy. Even if it is with the current libgo, an unrelated change elsewhere
could break this logic.
[Bug c/63480] -Wmissing-field-initializers should not warn about intentionally empty initializers (or that should be a separate option)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63480 --- Comment #5 from Manuel López-Ibáñez manu at gcc dot gnu.org --- The C warning is also nicer than the C++ one because it says where the field is declared. It also only mentions one missing field per declaration, whereas the C++ warning mentions all, which is terribly noisy and repetitive.
[Bug fortran/63473] Memory leak with ALLOCATABLE, INTENT(OUT) dummy arguments.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63473 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org --- It's probably related (but not identical) to not deallocating allocatable-scalars function results after their use [PR55603] and not finalizing function results (after their value has been used) [PR37336 ?].
[Bug go/60406] recover.go: test13reflect2 test failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406 --- Comment #24 from Dominik Vogt vogt at linux dot vnet.ibm.com --- --snip-- -g-defer-__retaddr = retaddr; +g-defer-__retaddr = __builtin_extract_return_addr (retaddr); --snip-- We need to double check whether this would break Sparc.
[Bug c/63480] -Wmissing-field-initializers should not warn about intentionally empty initializers (or that should be a separate option)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63480 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |5.0
[Bug c/63480] -Wmissing-field-initializers should not warn about intentionally empty initializers (or that should be a separate option)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63480 --- Comment #6 from Marek Polacek mpolacek at gcc dot gnu.org --- Also note PR39589, a request for -Wmissing-field-initializers=2, but it's not as trivial as it seems.
[Bug lto/61886] [4.8/4.9/5 Regression] LTO breaks fread with _FORTIFY_SOURCE=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886 --- Comment #25 from rguenther at suse dot de rguenther at suse dot de --- On Wed, 8 Oct 2014, jakub at gcc dot gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886 --- Comment #24 from Jakub Jelinek jakub at gcc dot gnu.org --- But is warning/error attribute the only thing on aliases that can hold extra semantics info (now or in the future)? I'd say LTO symtab merging should merge what is mergeable, and should leave leave as separate decls with the same asm-name what holds non-mergeable semantics on it. Say, if you declare some function (or different, just with same asm name) with warning attribute in one TU, with error attribute in another TU and without it on another TU, IMHO those three decls shouldn't be merged together, you should note in cgraph that you have aliases that have the same asm name but different semantics and just ensure that you use the right cgraph nodes and decls in the corresponding callers. Yes, I tried to fix things in this direction but failed (maybe didn't try hard enough). Basically I'd never merge decls in lto-symtab - tree merging already merges exactly equivalent function decls - but only fixup the cgraph for the tree merging that was done. Richard.
[Bug target/63483] Scheduler performs Invalid move of aliased memory reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target||alpha
Component|rtl-optimization|target
--- Comment #5 from Richard Biener rguenth at gcc dot gnu.org ---
The bug is clearly in
Btw, if the mem is MEM_READONLY_P how can it be part of
a {un}aligned_store sequence?
This flag is copied from the original memory operand of the store by
alpha_set_memflags to all memory operands in the expanded sequence.
and thus should be fixed there. What is the original memory reference
here? It seems for the read-modify-write you should use the target MEM
but somehow a source MEM gets used? Or rather you should not use either
MEMs flags for _all_ MEMs in the sequence but properly distinguish between
MEMs generated for the load of the source and MEMs generated for the store
to the destination.
[Bug tree-optimization/63445] [5 Regression] request: make -Wstrict-overflow avoid a class of false positives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63445 --- Comment #8 from Eric Botcazou ebotcazou at gcc dot gnu.org --- The range of n_7 is suboptimal and the test on _6 can be eliminated. Which turns out to be counter-productive for the testcase because the test is used to derive information by the sccp pass; as a result, if you eliminate it, the sccp pass does nothing and the loop is not eliminated in the final code...
[Bug ipa/63482] [5 Regression] ICE: in gimple_get_virt_method_for_vtable, at gimple-fold.c:4857
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63482 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.0
[Bug tree-optimization/63476] [5 Regression] ICE: tree check: expected ssa_name, have var_decl in walk_aliased_vdefs_1, at tree-ssa-alias.c:2689
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63476 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-10-08 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |5.0 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Mine (finally a small enough testcase...). This means somebody is not updating VDEFs properly (expected for load VUSEs btw).
[Bug libfortran/63471] [5.0 Regression] unix.c:1906:10: error: implicit declaration of function 'ttyname_r'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63471 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.0
[Bug target/63483] Scheduler performs Invalid move of aliased memory reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483
--- Comment #6 from Uroš Bizjak ubizjak at gmail dot com ---
(In reply to Richard Biener from comment #5)
The bug is clearly in
Btw, if the mem is MEM_READONLY_P how can it be part of
a {un}aligned_store sequence?
This flag is copied from the original memory operand of the store by
alpha_set_memflags to all memory operands in the expanded sequence.
and thus should be fixed there. What is the original memory reference
here? It seems for the read-modify-write you should use the target MEM
but somehow a source MEM gets used? Or rather you should not use either
MEMs flags for _all_ MEMs in the sequence but properly distinguish between
MEMs generated for the load of the source and MEMs generated for the store
to the destination.
No, this is wrong conclusion. I have new insight into this problem.
Please consider following test:
--cut here--
static char *a;
static int *b;
void foo (void)
{
a[1] = 1;
b[2] = 1;
}
int bar (void)
{
return a b;
}
--cut here--
(e.g. changing static char *b to static int *b. This way, the problematic
insn is generated as native read:
(insn 15 14 16 2 (set (reg/f:DI 78)
(mem/u/f/c:DI (lo_sum:DI (reg:DI 79)
(symbol_ref:DI (b) [flags 0x6] var_decl 0x2b1d67f5e090 b))
[2 b+0 S8 A64])) rmw1.c:7 -1
(nil))
and this is again moved over
(insn 13 12 14 2 (set (mem:DI (and:DI (plus:DI (reg/f:DI 72)
(const_int 1 [0x1]))
(const_int -8 [0xfff8])) [0 S8 A64])
(reg:DI 77)) rmw1.c:6 -1
(nil))
(note that there is no /u suffix on the *store* of a.)
With this testcase, we have following sequence before sched1 pass:
5: r73:DI=high(`a')
6: r72:DI=[r73:DI+low(`a')]
REG_DEAD r73:DI
7: r74:QI=0x1
8: r76:DI=[r72:DI+0x10xfff8]
9: r75:DI=r72:DI+0x1
10: r76:DI=!0xffr75:DI0x3r76:DI
11: r77:DI=zero_extend(r74:QI)r75:DI0x3
REG_DEAD r75:DI
REG_DEAD r74:QI
REG_EQUAL 0x1r75:DI0x3
12: r77:DI=r77:DI|r76:DI
REG_DEAD r76:DI
13: [r72:DI+0x10xfff8]=r77:DI
REG_DEAD r77:DI
REG_DEAD r72:DI
14: r79:DI=high(`b')
15: r78:DI=[r79:DI+low(`b')]
REG_DEAD r79:DI
16: r80:SI=0x1
17: [r78:DI+0x8]=r80:SI
REG_DEAD r80:SI
REG_DEAD r78:DI
and sched1 moves (insn 15) all the way up, past (insn 13):
5: r73:DI=high(`a')
14: r79:DI=high(`b')
7: r74:QI=0x1
6: r72:DI=[r73:DI+low(`a')]
REG_DEAD r73:DI
16: r80:SI=0x1
15: r78:DI=[r79:DI+low(`b')]
REG_DEAD r79:DI
9: r75:DI=r72:DI+0x1
8: r76:DI=[r72:DI+0x10xfff8]
11: r77:DI=zero_extend(r74:QI)r75:DI0x3
REG_DEAD r75:DI
REG_DEAD r74:QI
REG_EQUAL 0x1r75:DI0x3
10: r76:DI=!0xffr75:DI0x3r76:DI
12: r77:DI=r77:DI|r76:DI
REG_DEAD r76:DI
13: [r72:DI+0x10xfff8]=r77:DI
REG_DEAD r77:DI
REG_DEAD r72:DI
17: [r78:DI+0x8]=r80:SI
REG_DEAD r80:SI
REG_DEAD r78:DI
20: NOTE_INSN_DELETED
(this particular sequence won't end in a failure, but the insn shouldn't be
moved past possibly aliasing (insn 13) anyway.
Patched compiler results in:
5: r73:DI=high(`a')
7: r74:QI=0x1
14: r79:DI=high(`b')
6: r72:DI=[r73:DI+low(`a')]
REG_DEAD r73:DI
16: r80:SI=0x1
9: r75:DI=r72:DI+0x1
8: r76:DI=[r72:DI+0x10xfff8]
11: r77:DI=zero_extend(r74:QI)r75:DI0x3
REG_DEAD r75:DI
REG_DEAD r74:QI
REG_EQUAL 0x1r75:DI0x3
10: r76:DI=!0xffr75:DI0x3r76:DI
12: r77:DI=r77:DI|r76:DI
REG_DEAD r76:DI
13: [r72:DI+0x10xfff8]=r77:DI
REG_DEAD r77:DI
REG_DEAD r72:DI
15: r78:DI=[r79:DI+low(`b')]
REG_DEAD r79:DI
17: [r78:DI+0x8]=r80:SI
REG_DEAD r80:SI
REG_DEAD r78:DI
As shown, the code further down in true_dependence_1 function blocks the move,
since the read is detected as aliased with the preceding store involving AND
alignment.
There is nothing that can be done in target-dependant code, since the native
read from b gets marked as unchanging by the generic middle-end code.
Please reconsider the component setting. There is nothing that can be fixed
in target-dependent code.
[Bug tree-optimization/62053] [5 Regression] ICE: in remap_type_1, at tree-inline.c:540
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62053 --- Comment #5 from Alexander Ivchenko aivchenk at gmail dot com --- Ping.. any updates? We cannot build Android since the beginning of Jul, and, hence, cannot evaluate 5.0 candidate for it. I find it very unfortunate
[Bug c/39589] make -Wmissing-field-initializers=2 work with designated initializers ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39589 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic --- Comment #3 from Manuel López-Ibáñez manu at gcc dot gnu.org --- Also, I would propose to call the warning -Wmissing-designated-initializers better than a number that does not mean much.
[Bug ipa/63403] [5.0 Regression] ICE: in relative_time_benefit at ipa-inline.c:869
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63403 --- Comment #5 from dave.anglin at bell dot net --- Hi Richard, On 7-Oct-14, at 2:48 PM, rsandifo at gcc dot gnu.org wrote: Can you try the patches I posted here: https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02636.html https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02637.html The patches fix the ICE and restore bootstrap on hppa-unknown-linux- gnu. c and c++ tests are running. Thanks very much, Dave -- John David Anglindave.ang...@bell.net
[Bug c/63484] New: misleading/obsolete -fdelete-null-pointer-checks documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63484
Bug ID: 63484
Summary: misleading/obsolete -fdelete-null-pointer-checks
documentation
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
The current -fdelete-null-pointer-checks documentation is:
Assume that programs cannot safely dereference null pointers, and that no
code or data element resides there. This enables simple constant folding
optimizations at all optimization levels. In addition, other optimization
passes in GCC use this flag to control global dataflow analyses that
eliminate useless checks for null pointers; these assume that if a pointer is
checked after it has already been dereferenced, it cannot be null.
(both in the manual
https://gcc.gnu.org/onlinedocs/gcc-4.9.1/gcc/Optimize-Options.html#Optimize-Options
and the man page).
However a new check is done as of GCC 4.9, according to:
http://blog.mycre.ws/articles/bind-and-gcc-49/
and in particular:
https://gcc.gnu.org/gcc-4.9/porting_to.html
GCC might now optimize away the null pointer check in code like:
int copy (int* dest, int* src, size_t nbytes) {
memmove (dest, src, nbytes);
if (src != NULL)
return *src;
return 0;
}
The pointers passed to memmove (and similar functions in string.h) must be
non-null even when nbytes==0, so GCC can use that information to remove the
check after the memmove call. Calling copy(p, NULL, 0) can therefore deference
a null pointer and crash.
So, this new check makes the old -fdelete-null-pointer-checks documentation
Assume that programs cannot safely dereference null pointers, and that no code
or data element resides there. obsolete. Indeed, even though calling
memmove (dest, NULL, 0);
is invalid, it doesn't mean that the null src pointer is dereferenced by
memmove (this is not needed if nbytes is 0 like here) or that data reside
there.
Said otherwise, the developer may think I know that no data reside at address
0, and that null pointers are never dereferenced (otherwise the program would
crash). and deduce that the -fdelete-null-pointer-checks option is safe on his
code. However it isn't necessarily, just because of some ISO C rule that makes
some function call invalid (and many developers may not be aware of it, as this
rule is very unintuitive).
So, the documentation should be updated. Alternatively the option could be
split between one that removes checks because of code that is obviously wrong
(e.g. would yield a crash in practice on most platforms, or has semantically no
meanings) and one that removes checks because of any invalid code.
[Bug c++/63362] The c++11 triviality-traits need front-end help
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63362
--- Comment #23 from Jason Merrill jason at gcc dot gnu.org ---
(In reply to Ville Voutilainen from comment #22)
This test fails the static_assert for TType (which is a trivial type),
PODType and DelDef, and it would be expected that all those static_asserts
succeed.
No:
struct A { };
int main()
{
volatile A a;
volatile A a2(a); // ill-formed
}
test_category is testing whether volatile TType is trivially
copy-constructible, and it isn't copy-constructible at all.
Incidentally, you don't need to test anything else before
__is_trivially_constructible, it will just return false if the type isn't
constructible at all. Likewise for assignable.
Looking at the ICE.
[Bug ipa/63482] [5 Regression] ICE: in gimple_get_virt_method_for_vtable, at gimple-fold.c:4857
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63482 --- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Created attachment 33666 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33666action=edit somewhat reduced testcase % g++ -c -O2 CustomReactionTest.ii CustomReactionTest.ii:536:44: internal compiler error: in gimple_get_virt_method_for_vtable, at gimple-fold.c:4857
[Bug go/60406] recover.go: test13reflect2 test failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406 --- Comment #25 from Ian Lance Taylor ian at airs dot com --- (In reply to Dominik Vogt from comment #22) Hm, so the patch penalises platforms that cannot deal with the 16 byte window? Yes, but, recall that on your system almost all tests pass using the code that is in the tree today, before your patch. But they really only succeed by accident. The call for any platform might introduce control flow into the thunk and trigger the problem in any of the test cases. Yes, I understand that. You suggested that my patch penalized all cases where we have a control flow problem, because it will do a more costly unwind step. That is true. However, in practice, the case arises very rarely. We know that the code in the thunk is always very simple: if (__go_set_defer_retaddr (L)) goto L; real_function(args); L: The compiler is not going to start randomly throwing additional control flow statements into that function. The cases where it does do that are the cases where args is very large, so that it uses a block copy to copy them onto the stack. But that essentially never happens. The args here are the args in defer real_function(args). 90% of the time there are no arguments at all. 9.9% of the time it's just a couple of pointer/scalar arguments. In real code nobody ever calls defer with large arguments, because it's just a strange way to write; people write a function closure instead. The only code in the standard library that calls defer with a large argument is the recover.go test, to make sure that it works. It's necessary to handle all cases correctly. But there is nothing wrong with using an efficient mechanism when it works, as long as we can correctly fall back to a more expensive mechanism when it fails. I believe that my patch does that. If you like, we can incorporate your patch too, as long as it is only an addition to the existing code. Before calling runtime_callers, we can call _Unwind_FindEnclosingFunction. Then we need only go on to the runtime_callers code if _Unwind_FindEnclosingFunction returns NULL, or in the cases where d-__makefunc_can_recover is true.
[Bug c++/63362] The c++11 triviality-traits need front-end help
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63362
--- Comment #24 from Ville Voutilainen ville.voutilainen at gmail dot com ---
(In reply to Jason Merrill from comment #23)
(In reply to Ville Voutilainen from comment #22)
This test fails the static_assert for TType (which is a trivial type),
PODType and DelDef, and it would be expected that all those static_asserts
succeed.
No:
struct A { };
int main()
{
volatile A a;
volatile A a2(a); // ill-formed
}
test_category is testing whether volatile TType is trivially
copy-constructible, and it isn't copy-constructible at all.
Argh, thanks, I'll need to make those tests saner.
Incidentally, you don't need to test anything else before
__is_trivially_constructible, it will just return false if the type isn't
constructible at all. Likewise for assignable.
These library traits require that for a true-answer, the type used
must be referenceable. The 'main' traits do that, I wasn't sure whether
the intrinsic does. The 'main' traits also limit the accepted types
as per the standard, so I'm inclined to leave the general testing
approach as is. Jonathan took a quick look at it and thought it looks
ok. ;)
Looking at the ICE.
Excellent.
[Bug libfortran/63471] [5.0 Regression] unix.c:1906:10: error: implicit declaration of function 'ttyname_r'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63471 --- Comment #1 from Janne Blomqvist jb at gcc dot gnu.org --- Hmm, any idea how to fix it? Apparently just defining _REENTRANT globally might not be a good idea, as some systems may require linking in some other C library (libc_rt or such) then. We don't want to use the GCC -pthread flag (which should take care of necessary linking magic) either, since on systems with weakref support we want to avoid using mutexes etc. in single-threaded programs.
[Bug c++/63362] The c++11 triviality-traits need front-end help
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63362
--- Comment #25 from Jason Merrill jason at gcc dot gnu.org ---
And the ICE reduces to
struct A {
A(...);
};
int main()
{
volatile A a;
volatile A a2(a);
}
which crashes from infinite recursion trying to copy a for passing to So,
not an __is_trivially_constructible issue.
[Bug c++/63362] The c++11 triviality-traits need front-end help
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63362
--- Comment #26 from Ville Voutilainen ville.voutilainen at gmail dot com ---
(In reply to Jason Merrill from comment #25)
And the ICE reduces to
struct A {
A(...);
};
int main()
{
volatile A a;
volatile A a2(a);
}
which crashes from infinite recursion trying to copy a for passing to
So, not an __is_trivially_constructible issue.
Ah, yes, my test for a construct::Ellipsis will do that.
[Bug libfortran/63471] [5.0 Regression] unix.c:1906:10: error: implicit declaration of function 'ttyname_r'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63471 --- Comment #2 from Janne Blomqvist jb at gcc dot gnu.org --- Hmm, maybe add something like AC_CHECK_DECLS_ONCE([ttyname_r]) to configure.ac and then in unix.c(stream_ttyname) check with #ifdef HAVE_TTYNAME_R HAVE_DECL_TTYNAME_R
[Bug go/60406] recover.go: test13reflect2 test failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406
--- Comment #26 from Ian Lance Taylor ian at airs dot com ---
(In reply to Dominik Vogt from comment #23)
1) We need to call __builtin_extract_return_address(retaddr) in
__go_set_defer_retaddr() too. (On s390 (31 bit) this is necessary to remove
the most significant bit of the address which indicates the addressing mode.)
I.e.
--snip--
-g-defer-__retaddr = retaddr;
+g-defer-__retaddr = __builtin_extract_return_addr (retaddr);
--snip--
Will do.
2) The new patch does not compile for me:
--
In file included from ../../../libgo/runtime/go-check-interface.c:8:0:
../../../libgo/runtime/go-panic.h:43:13: error: conflicting types for
‘__go_makefunc_can_recover’
extern void __go_makefunc_can_recover (void *retaddr);
^
In file included from ../../../libgo/runtime/go-check-interface.c:7:0:
../../../libgo/runtime/runtime.h:845:9: note: previous declaration of
‘__go_makefunc_can_recover’ was here
void__go_makefunc_can_recover (const void *);
^
--
In runtime.h, __go_makefunc_can_recover still has a const argument:
--snip--
-void__go_makefunc_can_recover (const void *);
+void__go_makefunc_can_recover (void *);
--snip--
I think that must be a local change in your tree. In my tree runtime.h does
not declare __go_makefunc_can_recover.
3) Couldn't this be written more efficiently by passing a flag?
+ /* If we are called from __go_makefunc_can_recover, then we need to
+ look one level higher. */
+ if (locs[0].function.len 0
+ __builtin_strcmp ((const char *) locs[0].function.str,
+__go_makefunc_can_recover) == 0)
E.g.
_Bool __go_can_recover (void *retaddr, _Bool
called_by_makefunc_can_recover)
{
...
if (called_by_makefunc_can_recover)
{ do something }
else
{ do something else }
...
}
Yes, but I would rather do that later if it seems useful. It seems silly to
change the compiler to always pass an extra argument that will always be false.
Introducing a new function called by both __go_can_recover and
__go_makefunc_can_recover changes the stack layout depending on the compiler's
inlining choices, so must be treated with care. And it's worth remembering
that this case never ever happens outside of tests. It only happens when
somebody constructs a function using reflect.MakeFunc and then defers a call to
that function. That is a bizarre way to code and I am confident that
absolutely no real Go code does it. Making that case slightly less efficient
is not important.
4) With the suggested changes from 1 and 2 above:
s390x (64 bit):
* PASS: test/recover.go
* the test from #4 in my earlier posting works as expected
* my private defer/recover/panic testsuite works as expected
s390 (31 bit):
* PASS: test/recover.go
* the test from #4 in my earlier posting works as expected
* my private defer/recover/panic testsuite works as expected
Thanks for testing.
5) I find the assumption in the loop at the end of __go_can_recover() that
if a caller's name begins with __go_ that means the panic can be
recovered, a bit hairy. Even if it is with the current libgo, an unrelated
change elsewhere could break this logic.
I agree that it's imperfect. However, it's fairly difficult to construct a
case that causes the wrong thing to happen. No Go function can ever start with
__go. Very little code in libgo calls a function written in Go; it's easy to
find such code because it must call __go_set_closure (the defer thunks are a
special case that are known to have no closure). So it can only happen if
somebody writes a Go function that calls recover, and then passes it to C code,
and that C code names a function starting with __go_ and then calls the Go
function. And this has to happen from a deferred function called while there
is a panic in progress. The result will be that the function called by the C
code will incorrectly recover the panic.
[Bug c++/63485] New: [5 Regression] ICE: canonical types differ for identical types Aconst wchar_t [3]::type and const char_type [3]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63485
Bug ID: 63485
Summary: [5 Regression] ICE: canonical types differ for
identical types Aconst wchar_t [3]::type and const
char_type [3]
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: trippels at gcc dot gnu.org
Running the Boost testsuite shows:
markus@x4 /tmp % cat date_time_format_parser.ii
template typename C struct A
{
typedef C type;
};
template class class B
{
};
template class Range void as_literal (Range );
template typename struct C
{
typedef wchar_t char_type;
const char_type on_full_year_placeholder[3];
void
on_extended_iso_date ()
{
BAwchar_t const[3]::type a;
as_literal (on_full_year_placeholder);
}
};
template typename struct date_time_format_parser_callback : Cwchar_t
{
};
template typename BaseT struct D
{
typedef typename BaseT::char_type char_type;
char_type
parse (const char_type *, const char_type *,
typename BaseT::callback_type p3)
{
p3.on_extended_iso_date ();
}
};
struct F
{
typedef date_time_format_parser_callbackwchar_t callback_type;
typedef wchar_t char_type;
};
template typename CharT, typename ParserT, typename CallbackT
void
parse_format (CharT *p1, ParserT p2, CallbackT p3)
{
CharT p = p2.parse (p, p1, p3);
}
template typename CharT
void
parse_date_time_format (const CharT *, const CharT *p2,
date_time_format_parser_callbackCharT p3)
{
DF b;
parse_format (p2, b, p3);
}
template void
parse_date_time_format (const wchar_t *, const wchar_t *,
date_time_format_parser_callbackwchar_t );
markus@x4 /tmp % g++ -c -w -O0 date_time_format_parser.ii
date_time_format_parser.ii: In instantiation of ‘void C
template-parameter-1-1 ::on_extended_iso_date() [with
template-parameter-1-1 = wchar_t]’:
date_time_format_parser.ii:30:5: required from ‘DBaseT::char_type
DBaseT::parse(const char_type*, const char_type*, typename
BaseT::callback_type) [with BaseT = F; DBaseT::char_type = wchar_t; typename
BaseT::callback_type = date_time_format_parser_callbackwchar_t]’
date_time_format_parser.ii:42:33: required from ‘void parse_format(CharT*,
ParserT, CallbackT) [with CharT = const wchar_t; ParserT = DF; CallbackT =
date_time_format_parser_callbackwchar_t]’
date_time_format_parser.ii:50:16: required from ‘void
parse_date_time_format(const CharT*, const CharT*,
date_time_format_parser_callbackCharT) [with CharT = wchar_t]’
date_time_format_parser.ii:54:68: required from here
date_time_format_parser.ii:17:16: internal compiler error: canonical types
differ for identical types Aconst wchar_t [3]::type and const char_type [3]
{aka Aconst wchar_t [3]::type}
as_literal (on_full_year_placeholder);
^
0x6b6ebe comptypes(tree_node*, tree_node*, int)
../../gcc/gcc/cp/typeck.c:1407
0x6b4ffd structural_comptypes
../../gcc/gcc/cp/typeck.c:1341
0x6b6e77 comptypes(tree_node*, tree_node*, int)
../../gcc/gcc/cp/typeck.c:1399
0x6d1c51 ocp_convert(tree_node*, tree_node*, int, int, int)
../../gcc/gcc/cp/cvt.c:686
0x57baf8 convert_like_real
../../gcc/gcc/cp/call.c:6471
0x57832c build_over_call
../../gcc/gcc/cp/call.c:7209
0x587911 build_new_function_call(tree_node*, vectree_node*, va_gc,
vl_embed**, bool, int)
../../gcc/gcc/cp/call.c:4072
0x7060b4 finish_call_expr(tree_node*, vectree_node*, va_gc, vl_embed**, bool,
bool, int)
../../gcc/gcc/cp/semantics.c:2366
0x5fb7c6 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:15095
0x5db9d6 tsubst_expr
../../gcc/gcc/cp/pt.c:14272
0x5dbb1f tsubst_expr
../../gcc/gcc/cp/pt.c:13683
0x5db34b tsubst_expr
../../gcc/gcc/cp/pt.c:13669
0x5dc7e0 tsubst_expr
../../gcc/gcc/cp/pt.c:13855
0x5d9a7d instantiate_decl(tree_node*, int, bool)
../../gcc/gcc/cp/pt.c:20231
0x620192 instantiate_pending_templates(int)
../../gcc/gcc/cp/pt.c:20347
0x65d4d4 cp_write_global_declarations()
../../gcc/gcc/cp/decl2.c:4367
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 c++/63486] New: Magic Statics lock guard does not include registration into atexit handler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63486
Bug ID: 63486
Summary: Magic Statics lock guard does not include registration
into atexit handler
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mira.suk at centrum dot cz
void test()
{
static std::string x;
}
If I'm reading assembly right _cxa_atexit handler is not called inside lock
which could result in static variable being destructed multiple times.
Is compiled into following with -g3
|0x401312 test() push %rbp
│
│0x401313 test()+1 mov%rsp,%rbp
│
│0x401316 test()+4 push %r12
│
│0x401318 test()+6 push %rbx
│
|0x401319 test()+7 lea0x202e10(%rip),%rax# 0x604130
_ZGVZ4testvE1x
│
│0x401320 test()+14movzbl (%rax),%eax
│
│0x401323 test()+17test %al,%al
│
│0x401325 test()+19jne0x401398 test()+134
│
│0x401327 test()+21lea0x202e02(%rip),%rdi# 0x604130
_ZGVZ4testvE1x
│
│0x40132e test()+28callq 0x400c40 __cxa_guard_acquire@plt
│
│0x401333 test()+33test %eax,%eax
│
│0x401335 test()+35setne %al
│
│0x401338 test()+38test %al,%al
│
│0x40133a test()+40je 0x401398 test()+134
│
│0x40133c test()+42mov$0x0,%r12d
│
│0x401342 test()+48lea0x202dff(%rip),%rdi# 0x604148
_ZZ4testvE1x
│
│0x401349 test()+55callq 0x400c20 _ZNSsC1Ev@plt
│
│0x40134e test()+60lea0x202ddb(%rip),%rdi# 0x604130
_ZGVZ4testvE1x
│
│0x401355 test()+67callq 0x400cb0 __cxa_guard_release@plt
│
│0x40135a test()+72lea0x202d87(%rip),%rdx# 0x6040e8
│
│0x401361 test()+79lea0x202de0(%rip),%rsi# 0x604148
_ZZ4testvE1x
│
│0x401368 test()+86mov0x202c81(%rip),%rax# 0x603ff0
│
│0x40136f test()+93mov%rax,%rdi
│
│0x401372 test()+96callq 0x400ef1 __cxa_atexit(void (*)(void*),
void*, void*)
│
│0x401377 test()+101 jmp0x401398 test()+134
│
│0x401379 test()+103 mov%rax,%rbx
│
│0x40137c
[Bug target/63483] Scheduler performs Invalid move of aliased memory reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483
--- Comment #7 from rguenther at suse dot de rguenther at suse dot de ---
On Wed, 8 Oct 2014, ubizjak at gmail dot com wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483
--- Comment #6 from Uroš Bizjak ubizjak at gmail dot com ---
(In reply to Richard Biener from comment #5)
The bug is clearly in
Btw, if the mem is MEM_READONLY_P how can it be part of
a {un}aligned_store sequence?
This flag is copied from the original memory operand of the store by
alpha_set_memflags to all memory operands in the expanded sequence.
and thus should be fixed there. What is the original memory reference
here? It seems for the read-modify-write you should use the target MEM
but somehow a source MEM gets used? Or rather you should not use either
MEMs flags for _all_ MEMs in the sequence but properly distinguish between
MEMs generated for the load of the source and MEMs generated for the store
to the destination.
No, this is wrong conclusion. I have new insight into this problem.
Please consider following test:
--cut here--
static char *a;
static int *b;
void foo (void)
{
a[1] = 1;
b[2] = 1;
}
int bar (void)
{
return a b;
}
--cut here--
(e.g. changing static char *b to static int *b. This way, the problematic
insn is generated as native read:
(insn 15 14 16 2 (set (reg/f:DI 78)
(mem/u/f/c:DI (lo_sum:DI (reg:DI 79)
(symbol_ref:DI (b) [flags 0x6] var_decl 0x2b1d67f5e090
b))
[2 b+0 S8 A64])) rmw1.c:7 -1
(nil))
and this is again moved over
(insn 13 12 14 2 (set (mem:DI (and:DI (plus:DI (reg/f:DI 72)
(const_int 1 [0x1]))
(const_int -8 [0xfff8])) [0 S8 A64])
(reg:DI 77)) rmw1.c:6 -1
(nil))
(note that there is no /u suffix on the *store* of a.)
With this testcase, we have following sequence before sched1 pass:
5: r73:DI=high(`a')
6: r72:DI=[r73:DI+low(`a')]
REG_DEAD r73:DI
7: r74:QI=0x1
8: r76:DI=[r72:DI+0x10xfff8]
9: r75:DI=r72:DI+0x1
10: r76:DI=!0xffr75:DI0x3r76:DI
11: r77:DI=zero_extend(r74:QI)r75:DI0x3
REG_DEAD r75:DI
REG_DEAD r74:QI
REG_EQUAL 0x1r75:DI0x3
12: r77:DI=r77:DI|r76:DI
REG_DEAD r76:DI
13: [r72:DI+0x10xfff8]=r77:DI
REG_DEAD r77:DI
REG_DEAD r72:DI
14: r79:DI=high(`b')
15: r78:DI=[r79:DI+low(`b')]
REG_DEAD r79:DI
16: r80:SI=0x1
17: [r78:DI+0x8]=r80:SI
REG_DEAD r80:SI
REG_DEAD r78:DI
and sched1 moves (insn 15) all the way up, past (insn 13):
5: r73:DI=high(`a')
14: r79:DI=high(`b')
7: r74:QI=0x1
6: r72:DI=[r73:DI+low(`a')]
REG_DEAD r73:DI
16: r80:SI=0x1
15: r78:DI=[r79:DI+low(`b')]
REG_DEAD r79:DI
9: r75:DI=r72:DI+0x1
8: r76:DI=[r72:DI+0x10xfff8]
11: r77:DI=zero_extend(r74:QI)r75:DI0x3
REG_DEAD r75:DI
REG_DEAD r74:QI
REG_EQUAL 0x1r75:DI0x3
10: r76:DI=!0xffr75:DI0x3r76:DI
12: r77:DI=r77:DI|r76:DI
REG_DEAD r76:DI
13: [r72:DI+0x10xfff8]=r77:DI
REG_DEAD r77:DI
REG_DEAD r72:DI
17: [r78:DI+0x8]=r80:SI
REG_DEAD r80:SI
REG_DEAD r78:DI
20: NOTE_INSN_DELETED
(this particular sequence won't end in a failure, but the insn shouldn't be
moved past possibly aliasing (insn 13) anyway.
Patched compiler results in:
5: r73:DI=high(`a')
7: r74:QI=0x1
14: r79:DI=high(`b')
6: r72:DI=[r73:DI+low(`a')]
REG_DEAD r73:DI
16: r80:SI=0x1
9: r75:DI=r72:DI+0x1
8: r76:DI=[r72:DI+0x10xfff8]
11: r77:DI=zero_extend(r74:QI)r75:DI0x3
REG_DEAD r75:DI
REG_DEAD r74:QI
REG_EQUAL 0x1r75:DI0x3
10: r76:DI=!0xffr75:DI0x3r76:DI
12: r77:DI=r77:DI|r76:DI
REG_DEAD r76:DI
13: [r72:DI+0x10xfff8]=r77:DI
REG_DEAD r77:DI
REG_DEAD r72:DI
15: r78:DI=[r79:DI+low(`b')]
REG_DEAD r79:DI
17: [r78:DI+0x8]=r80:SI
REG_DEAD r80:SI
REG_DEAD r78:DI
As shown, the code further down in true_dependence_1 function blocks the move,
since the read is detected as aliased with the preceding store involving AND
alignment.
There is nothing that can be done in target-dependant code, since the native
read from b gets marked as unchanging by the generic middle-end code.
Where is that done? It looks bogus to me.
Please reconsider the component setting. There is nothing that can be fixed
in target-dependent code.
I'm not sure - copying MEM flags to all MEMs from a single source seems
possibly wrong.
[Bug go/60406] recover.go: test13reflect2 test failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406 --- Comment #27 from ian at gcc dot gnu.org ian at gcc dot gnu.org --- Author: ian Date: Wed Oct 8 14:03:13 2014 New Revision: 216003 URL: https://gcc.gnu.org/viewcvs?rev=216003root=gccview=rev Log: PR go/60406 runtime: Check callers in can_recover if return addressdoesn't match. Also use __builtin_extract_return_address and tighten up the checks in FFI code. Fixes PR 60406. Modified: trunk/libgo/go/reflect/makefunc_ffi_c.c trunk/libgo/runtime/go-defer.c trunk/libgo/runtime/go-panic.h trunk/libgo/runtime/go-recover.c trunk/libgo/runtime/panic.c
[Bug go/60406] recover.go: test13reflect2 test failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406 Ian Lance Taylor ian at airs dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #28 from Ian Lance Taylor ian at airs dot com --- Fixed on trunk.
[Bug c++/63485] [5 Regression] ICE: canonical types differ for identical types Aconst wchar_t [3]::type and const char_type [3]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63485 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Started with r214030.
[Bug target/63483] Scheduler performs Invalid move of aliased memory reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483 --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org --- How can I reproduce this? Even with -mcpu=ev4 I get $foo..ng: foo: .frame $30,0,$26,0 $LFB0: .cfi_startproc .prologue 0 mov $31,$2 ldq_u $1,1($2) zapnot $1,253,$1 stq_u $1,1($2) call_pal 0x81 I configured with --target=alphaev68-linux-gnu And used -O2 -mcpu=ev4 (sounds earliest). Note that the pointers 'a' and 'b' are likely made constant by IPA reference and thus loads of the pointers can validly get /u, but not loads from the pointers (well, we may even figure out their value is always zero...). Does it fix the testcase if you have a function writing to a and b or making a and b not static?
[Bug target/63483] Scheduler performs Invalid move of aliased memory reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483
--- Comment #9 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to Richard Biener from comment #8)
How can I reproduce this? Even with -mcpu=ev4 I get
$foo..ng:
foo:
.frame $30,0,$26,0
$LFB0:
.cfi_startproc
.prologue 0
mov $31,$2
ldq_u $1,1($2)
zapnot $1,253,$1
stq_u $1,1($2)
call_pal 0x81
I configured with --target=alphaev68-linux-gnu
And used -O2 -mcpu=ev4 (sounds earliest).
Note that the pointers 'a' and 'b' are likely made constant by IPA reference
and thus loads of the pointers can validly get /u, but not loads from the
pointers (well, we may even figure out their value is always zero...).
Indeed. From my .optimized dump:
foo ()
{
bb 2:
MEM[(char *)0B + 1B] ={v} 0;
__builtin_trap ();
Does it fix the testcase if you have a function writing to a and b or
making a and b not static?
Then I get
$foo..ng:
.prologue 1
ldq $1,a($29) !literal
ldq $2,0($1)
lda $1,1($31)
cpys $f31,$f31,$f31
lda $4,1($2)
ldq_u $3,1($2)
insbl $1,$4,$1
mskbl $3,$4,$3
bis $1,$3,$1
stq_u $1,1($2)
lda $2,1($31)
ldq $1,b($29) !literal
ldq $1,0($1)
stl $2,8($1)
ret $31,($26),1
not sure if that's correct. Adjusted testcase:
char *a;
int *b;
void foo (void)
{
a[1] = 1;
b[2] = 1;
}
int bar (void)
{
return a b;
}
[Bug target/63483] Scheduler performs Invalid move of aliased memory reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483
--- Comment #10 from Richard Biener rguenth at gcc dot gnu.org ---
Ok, I believe that even
char * const a;
int * const b;
void foo (void)
{
a[1] = 1;
b[2] = 1;
}
int bar (void)
{
return a b;
}
does not reproduces the issue.
$foo..ng:
.prologue 1
ldq $1,a($29) !literal
ldq $2,0($1)
ldq $1,b($29) !literal
bis $31,$31,$31
lda $4,1($2)
ldq_u $3,1($2)
ldq $5,0($1)
lda $1,1($31)
insbl $1,$4,$1
mskbl $3,$4,$3
bis $1,$3,$1
stq_u $1,1($2)
lda $1,1($31)
stl $1,8($5)
ret $31,($26),1
[Bug lto/61969] [4.8/4.9/5 Regression] wrong code by LTO on i?86-linux-gnu (affecting trunk, 4.9.x, and 4.8.x)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61969 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-10-08 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #10 from Richard Biener rguenth at gcc dot gnu.org --- Testing it.
[Bug libquadmath/53775] Errors in libquadmath documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53775 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||fxcoudert at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- Duplicate of 56072, has been fixed already. *** This bug has been marked as a duplicate of bug 56072 ***
[Bug libquadmath/56072] info page wrongly defines M_PI_2 and M_PI_4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56072 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added CC||e716018 at rtrtr dot com --- Comment #4 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- *** Bug 53775 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/63380] [5 Regression] Wrong constant folding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63380
--- Comment #3 from Richard Biener rguenth at gcc dot gnu.org ---
Hmm. We end up with
main ()
{
int d.0_4;
int e.1_5;
int _7;
int b.7_11;
int a.8_12;
bb 2:
d.0_4 = d;
e.1_5 = 1 d.0_4;
e = e.1_5;
_7 = 31 / 0;
in the end. Which is caused by tail-merging (part of PRE) optimizing
bb 2:
d.0_4 = d;
e.1_5 = 1 d.0_4;
e = e.1_5;
if (e.1_5 = 0)
goto bb 10;
else
goto bb 3;
bb 10:
goto bb 4;
bb 3:
_7 = 31 / 0;
bb 4:
by removing bb 3 as having no side-effect appearantly (_7 is unused). It
produces
bb 2:
d.0_4 = d;
e.1_5 = 1 d.0_4;
e = e.1_5;
bb 3:
_7 = 31 / 0;
bb 4:
not sure how it ends up doing that (I suppose it has code to merge an
if diamond).
[Bug libquadmath/60349] Any call to expq (or libquadmath function that might possibly call expq) segfaults in mingw-gcc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60349 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED CC||fxcoudert at gcc dot gnu.org Resolution|--- |INVALID --- Comment #3 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- This was apparently a bug in mingw itself, and was fixed a while back. I'm closing this report. Please reopen it, with added info (such as backtrace), if you still see this problem with latest mingw.
[Bug libquadmath/63487] New: typo in documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63487 Bug ID: 63487 Summary: typo in documentation Product: gcc Version: unknown Status: UNCONFIRMED Severity: trivial Priority: P3 Component: libquadmath Assignee: unassigned at gcc dot gnu.org Reporter: zimmerma+gcc at loria dot fr on https://gcc.gnu.org/onlinedocs/libquadmath.pdf, page 7, simulataneously should read simultaneously
[Bug libquadmath/63488] New: large errors in y0q
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63488 Bug ID: 63488 Summary: large errors in y0q Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libquadmath Assignee: unassigned at gcc dot gnu.org Reporter: zimmerma+gcc at loria dot fr For the input aa below (with 36 digits, we can recover the exact 113-bit binary value by rounding to nearest) mpfr_y0 gets the result cc (more precisely, the corresponding 113-bit binary value) which should be correctly rounded, and y0q gets the result dd which differs from 180688 ulps. aa=8.935761195587725798762818805462843676e-01 cc=-7.446238819993339201075302662649733975e-07 [MPFR] dd=-7.446238819993339201075302662815669696e-07 ulp difference = 180688.00 For other functions and one million random inputs per function, I got much smaller differences (at most 42 ulps). The compiler was gcc 4.6.3. Paul Zimmermann
[Bug libquadmath/54012] printf crash with -lgfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54012 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED CC||fxcoudert at gcc dot gnu.org Resolution|--- |WORKSFORME --- Comment #13 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- No feedback in the last 2 years, works for me on x86_64-linux at -m32 and -m64, with all gcc versions from 4.6 to trunk. Closing.
[Bug target/63483] Scheduler performs Invalid move of aliased memory reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483
--- Comment #11 from Uroš Bizjak ubizjak at gmail dot com ---
(In reply to Richard Biener from comment #10)
Ok, I believe that even
char * const a;
int * const b;
void foo (void)
{
a[1] = 1;
b[2] = 1;
}
int bar (void)
{
return a b;
}
does not reproduces the issue.
$foo..ng:
.prologue 1
ldq $1,a($29) !literal
ldq $2,0($1)
ldq $1,b($29) !literal
bis $31,$31,$31
lda $4,1($2)
ldq_u $3,1($2)
ldq $5,0($1) - this is (insn 15)
lda $1,1($31)
insbl $1,$4,$1
mskbl $3,$4,$3
bis $1,$3,$1
stq_u $1,1($2)- this is (insn 13)
lda $1,1($31)
stl $1,8($5)
ret $31,($26),1
$foo..ng:
.prologue 1
lda $1,a # 5*movdi/7[length = 4]
ldq $2,0($1) # 6*movdi/8[length = 4]
lda $1,b # 23 *movdi/7[length = 4]
bis $31,$31,$31 # 31 nop [length = 4]
lda $4,1($2) # 9*adddi_internal/2 [length = 4]
ldq_u $3,1($2) # 8*movdi/8[length = 4]
ldq $5,0($1) # 15 *movdi/8[length = 4]
lda $1,1($31)# 22 *movqi/2[length = 4]
insbl $1,$4,$1 # 11 insbl [length = 4]
mskbl $3,$4,$3 # 10 mskxl [length = 4]
bis $1,$3,$1 # 12 iordi3/1[length = 4]
stq_u $1,1($2) # 13 *movdi/9[length = 4]
lda $1,1($31)# 21 *movsi/2[length = 4]
stl $1,8($5) # 17 *movsi/6[length = 4]
ret $31,($26),1 # 30 *return_internal[length = 4]
5: $1:DI=`a'
REG_EQUIV `a'
6: $2:DI=[$1:DI]
REG_DEAD $1:DI
23: $1:DI=`b'
REG_EQUIV `b'
31: 0
9: $4:DI=$2:DI+0x1
8: $3:DI=[$2:DI+0x10xfff8]
15: $5:DI=[$1:DI]
REG_DEAD $1:DI
22: $1:QI=0x1
REG_EQUIV 0x1
11: $1:DI=zero_extend($1:QI)$4:DI0x3
REG_EQUAL 0x1$4:DI0x3
10: $3:DI=!0xff$4:DI0x3$3:DI
REG_DEAD $4:DI
12: $1:DI=$1:DI|$3:DI
REG_DEAD $3:DI
13: [$2:DI+0x10xfff8]=$1:DI
REG_DEAD $2:DI
REG_DEAD $1:DI
21: $1:SI=0x1
REG_EQUIV 0x1
17: [$5:DI+0x8]=$1:SI
REG_DEAD $5:DI
REG_DEAD $1:SI
30: return
29: barrier
20: NOTE_INSN_DELETED
24: NOTE_INSN_DELETED
My dumps were with -mexplicit-relocs for some reason, the above are with
-mno-explicit-relocs.
[Bug libquadmath/63487] typo in documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63487 --- Comment #1 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- Author: fxcoudert Date: Wed Oct 8 15:33:41 2014 New Revision: 216006 URL: https://gcc.gnu.org/viewcvs?rev=216006root=gccview=rev Log: PR libquadmath/63487 * libquadmath.texi (sincosq): Fix typo. Modified: trunk/libquadmath/ChangeLog trunk/libquadmath/libquadmath.texi
[Bug libquadmath/63487] typo in documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63487 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- Fixed on trunk.
[Bug target/62275] ARM should use vcvta instructions when possible for float - int rounding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62275 --- Comment #6 from Yvan Roux yroux at gcc dot gnu.org --- Author: yroux Date: Wed Oct 8 15:37:43 2014 New Revision: 216007 URL: https://gcc.gnu.org/viewcvs?rev=216007root=gccview=rev Log: gcc/ 2014-10-08 Yvan Roux yvan.r...@linaro.org Backport from trunk r214825, r214826. 2014-09-02 Kyrylo Tkachov kyrylo.tkac...@arm.com PR target/62275 * config/arm/neon.md (neon_vcvtNEON_VCVT:nvrint_variantsu_optabVCVTF:mode v_cmp_result): New pattern. * config/arm/iterators.md (NEON_VCVT): New int iterator. * config/arm/arm_neon_builtins.def (vcvtav2sf, vcvtav4sf, vcvtauv2sf, vcvtauv4sf, vcvtpv2sf, vcvtpv4sf, vcvtpuv2sf, vcvtpuv4sf, vcvtmv2sf, vcvtmv4sf, vcvtmuv2sf, vcvtmuv4sf): New builtin definitions. * config/arm/arm.c (arm_builtin_vectorized_function): Handle BUILT_IN_LROUNDF, BUILT_IN_LFLOORF, BUILT_IN_LCEILF. 2014-09-02 Kyrylo Tkachov kyrylo.tkac...@arm.com PR target/62275 * config/arm/iterators.md (FIXUORS): New code iterator. (VCVT): New int iterator. (su_optab): New code attribute. (su): Likewise. * config/arm/vfp.md (lvrint_patternsu_optabmodesi2): New pattern. gcc/testsuite/ 2014-10-08 Yvan Roux yvan.r...@linaro.org Backport from trunk r214825, r214826, r215085. 2014-09-09 Kyrylo Tkachov kyrylo.tkac...@arm.com * gcc.target/arm/vect-lceilf_1.c: Make input and output arrays global and 16-byte aligned. * gcc.target/arm/vect-lfloorf_1.c: Likewise. * gcc.target/arm/vect-lroundf_1.c: Likewise. * gcc.target/arm/vect-rounding-btruncf.c: Likewise. * gcc.target/arm/vect-rounding-ceilf.c: Likewise. * gcc.target/arm/vect-rounding-floorf.c: Likewise. * gcc.target/arm/vect-rounding-roundf.c: Likewise. 2014-09-02 Kyrylo Tkachov kyrylo.tkac...@arm.com PR target/62275 * gcc.target/arm/vect-lceilf_1.c: New test. * gcc.target/arm/vect-lfloorf_1.c: Likewise. * gcc.target/arm/vect-lroundf_1.c: Likewise. 2014-09-02 Kyrylo Tkachov kyrylo.tkac...@arm.com PR target/62275 * gcc.target/arm/lceil-vcvt_1.c: New test. * gcc.target/arm/lfloor-vcvt_1.c: Likewise. * gcc.target/arm/lround-vcvt_1.c: Likewise. Added: branches/linaro/gcc-4_9-branch/gcc/testsuite/gcc.target/arm/lceil-vcvt_1.c branches/linaro/gcc-4_9-branch/gcc/testsuite/gcc.target/arm/lfloor-vcvt_1.c branches/linaro/gcc-4_9-branch/gcc/testsuite/gcc.target/arm/lround-vcvt_1.c branches/linaro/gcc-4_9-branch/gcc/testsuite/gcc.target/arm/vect-lceilf_1.c branches/linaro/gcc-4_9-branch/gcc/testsuite/gcc.target/arm/vect-lfloorf_1.c branches/linaro/gcc-4_9-branch/gcc/testsuite/gcc.target/arm/vect-lroundf_1.c Modified: branches/linaro/gcc-4_9-branch/gcc/ChangeLog.linaro branches/linaro/gcc-4_9-branch/gcc/config/arm/arm.c branches/linaro/gcc-4_9-branch/gcc/config/arm/arm_neon_builtins.def branches/linaro/gcc-4_9-branch/gcc/config/arm/iterators.md branches/linaro/gcc-4_9-branch/gcc/config/arm/neon.md branches/linaro/gcc-4_9-branch/gcc/config/arm/vfp.md branches/linaro/gcc-4_9-branch/gcc/testsuite/ChangeLog.linaro branches/linaro/gcc-4_9-branch/gcc/testsuite/gcc.target/arm/vect-rounding-btruncf.c branches/linaro/gcc-4_9-branch/gcc/testsuite/gcc.target/arm/vect-rounding-ceilf.c branches/linaro/gcc-4_9-branch/gcc/testsuite/gcc.target/arm/vect-rounding-floorf.c branches/linaro/gcc-4_9-branch/gcc/testsuite/gcc.target/arm/vect-rounding-roundf.c
[Bug libfortran/63471] [5.0 Regression] unix.c:1906:10: error: implicit declaration of function 'ttyname_r'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63471 --- Comment #3 from dave.anglin at bell dot net --- On 10/8/2014 9:43 AM, jb at gcc dot gnu.org wrote: Hmm, maybe add something like AC_CHECK_DECLS_ONCE([ttyname_r]) to configure.ac and then in unix.c(stream_ttyname) check with #ifdef HAVE_TTYNAME_R HAVE_DECL_TTYNAME_R Don't we want to use ttyname_r in multithreaded applications? It seems HP-UX is the only platform to hide the declaration of ttyname_r using _REENTRANT :-( If configure finds ttyname_r, then presumably we don't need pthread linking for it. On some platforms (MacOS 10.4 and Solaris 11), ttyname_r may return a 'char *', not 'int'. Dave
[Bug libquadmath/63488] large errors in y0q
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63488 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-10-08 Version|unknown |5.0 Ever confirmed|0 |1 --- Comment #1 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- Confirmed on trunk. Also visible with the following Fortran source: real(kind=16), parameter :: x = 0.8935761195587725798762818805462843676_16 real(kind=16) :: y print *, bessel_y0(x) y = x ; y = bessel_y0(y) print *, y print *, (y - bessel_y0(x)) / bessel_y0(x) end which outputs: -7.44623881999333920107530266264973398E-0007 -7.44623881999333920107530266281566970E-0007 2.22845016536952266229206331898288934E-0029
[Bug c++/63489] New: stack allocated array pointer corrupted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63489 Bug ID: 63489 Summary: stack allocated array pointer corrupted Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jonathan.hogg at stfc dot ac.uk Created attachment 33667 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33667action=edit test case The attached code, when compiled as g++ -g -O2 testcase.cxx -o testcase ./testcase and run, produces: Try 0x7fff1cbe0a00 0x7fff1cbe0a00 Perm exit: 0 1 2 3 4 5 6 7 GO 0x7fff1cbe0a00 Try2 0x1 0x1 Segmentation fault g++ --version: g++ (Ubuntu 4.8.2-19ubuntu1) 4.8.2 Copyright (C) 2013 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. The lines Try and Try2 should be identical, as they refer to the same stack-allocated array perm[]. Running under valgrind is clean until the last line of ldlt_test() is encountered (which is clearly a segfault as perm is a bad pointer). Compiling without -O2 changes something, and the code crashes differently. I can supply a larger test case (from which this was created) that shuold produce meaningful answers if the code works correctly, but it will need to be provided privately for IP reasons.
[Bug target/61981] PPC64 Linux Split-Stack Support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61981 David Edelsohn dje at gcc dot gnu.org changed: What|Removed |Added Target||powerpc64-linux Status|UNCONFIRMED |NEW Last reconfirmed||2014-10-08 Summary|PowerPC Linux Split-Stack |PPC64 Linux Split-Stack |Support |Support Ever confirmed|0 |1 --- Comment #3 from David Edelsohn dje at gcc dot gnu.org --- Oka-san, thank you very much for your interest. The focus is PPC64 Linux and the ABI specifically has allocated space to support split stack. It will be more effective to utilize the POWER8 PPC64LE systems at OSUOSL for development.
[Bug libquadmath/63488] large errors in y0q
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63488 --- Comment #2 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- The code in question is at libquadmath/math/j0q.c, function y0q, in the branch annotated /* 0 = x = 2 */ It has to do with the rational function: /* Y0(x) = 2/pi * log(x) * J0(x) + R(x^2) Peak absolute error 1.7e-36 (relative where Y0 1) 0 = x = 2 */ Coefficients are in Y0_2N and Y0_2D. It would be useful to confirm this bug in the upstream glibc's j0l(), as it probably manifests on 128-bit long double (glibc/sysdeps/ieee754/ldbl-128/e_j0l.c).
[Bug target/62308] A bug with aarch64 big-endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62308 --- Comment #6 from Venkataramanan venkataramanan.kumar at amd dot com --- git bisect experiment showed this revision after which bug disappears. https://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=215707
[Bug libquadmath/55821] Release tarballs (unconditionally) install libquadmath.info when libquadmath is not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55821 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-10-08 CC||fxcoudert at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- Would this work? Gerald, can you try it? Index: Makefile.am === --- Makefile.am(revision 215645) +++ Makefile.am(working copy) @@ -158,6 +158,8 @@ libquadmath.info: $(STAMP_BUILD_INFO) # the relative path from the current `Makefile.am' to `texinfo.tex'. TEXINFO_TEX = ../gcc/doc/include/texinfo.tex +if BUILD_LIBQUADMATH + # Defines info, dvi, pdf and html targets MAKEINFOFLAGS = -I $(srcdir)/../gcc/doc/include info_TEXINFOS = libquadmath.texi @@ -165,3 +167,5 @@ libquadmath_TEXINFOS = libquadmath-vers. libquadmath-vers.texi: echo @set BUGURL $(REPORT_BUGS_TEXI) $@ + +endif BUILD_LIBQUADMATH
[Bug libquadmath/63488] large errors in y0q
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63488 --- Comment #3 from joseph at codesourcery dot com joseph at codesourcery dot com --- Note that libquadmath has not been updated from glibc since November 2012. So, while in the Bessel function case large errors are already known for all floating-point types in glibc, in general libquadmath bugs are quite likely to have been fixed in glibc since the last update (and testing the glibc code directly on a platform with binary128 long double may be better - AArch64, Alpha, MIPS64, S/390, SPARC are all such platforms, and the GCC Compile Farm has some of them). (It is of course possible there are some bugs specific to libquadmath, arising from the adaptation of the glibc code.) (Eventually I think we should provide _Float128 functions directly in glibc's libm on x86/x86_64, with the TS 18661-3 names, in which case libquadmath could become a thin wrapper round the libm versions, on platforms using current glibc or any other library providing the TS 18661-3 functions.)
[Bug lto/61886] [4.8/4.9/5 Regression] LTO breaks fread with _FORTIFY_SOURCE=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886 --- Comment #26 from Jan Hubicka hubicka at ucw dot cz --- But is warning/error attribute the only thing on aliases that can hold extra semantics info (now or in the future)? I'd say LTO symtab merging should merge what is mergeable, and should leave leave as separate decls with the same asm-name what holds non-mergeable semantics on it. Say, if you declare some function (or different, just with same asm name) with warning attribute in one TU, with error attribute in another TU and without it on another TU, IMHO those three decls shouldn't be merged together, you should note in cgraph that you have aliases that have the same asm name but different semantics and just ensure that you use the right cgraph nodes and decls in the corresponding callers. A I tried to explain, it is currently design decision to have one declaration and one symtam node for one symbol. The one decl rule was introduced by Codesourcery (Zack) in 2003-4. He updated frontends to avoid copying and dropped code that dealt with duplicated declarations. Due to lack of sanity checking some cases remained, like this one (because at that time we did not really have proper asm name hash). There are couple open PRs since that time that was never corrected. So either we need to fix remaining cases or revisit the decision and audit backend/middleend for duplicated decls. There are cases I know that would need updating - symbol equality folding - alias analysis - Symbol table allowing many to one mapping for symtab entries. I think it would be better to avoid duplicated entries in symbol table, so we will need way to associate all declarations with a given symbol. Probably ont that big deal except for updating code that deals with changing declaration associated with the node and we need to decide what declaration control symbol's visibility. Obviously if user provide two declarations, one is static and ohter public, we either want to error or do someting sane. - we need to produce errors when user defines two different symbols of same name (currently we produce invalid asm) - anchors - Zack dropped some code from dwarf2out - Visibility in varasm - those need to follow the main declaration. I had great fun fixing effects of this on AIX I definitly found the one decl scheme somewhat restrictive, but it also makes things easier and avoids weird bugs. We could revert this decision, but that is a project. Concerning Richards plan to annotate statements with warning strings, I think we could follow same scheme as EH regions and histograms does - i.e. have on side hash table annotating statements. For IPA I am trying to convince Martin Liska to introduce symtab annotation template for me that makes it easy to add data to a symbol that is removed/duplicated along with the symbol. Cgraph has the hook API for it, but convenient C++ wrap would be great. Here I think we want something similar and convert the existing EH/histograms to it. Honza
[Bug c++/63489] stack allocated array pointer corrupted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63489 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- Do you have a testcase that doesn't exhibit obvious undefined behaviour that's easily pointed out with -Wall, such as dividing by uninitialized values? There's a buffer overflow here: for(int i=0; i2; i++) invp[oldp[i]] = i; Try adding an assertion that oldp[i] is in range.
[Bug c++/63489] stack allocated array pointer corrupted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63489 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- That was pretty easily found with -fsanitize=address
[Bug c++/63459] operator new and returns_nonnull
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63459
--- Comment #5 from Jan Hubicka hubicka at ucw dot cz ---
Hi,
does something like this make sense (I also updated the DECL_BY_REFERENCE
check.
We allow to put variable at address NULL with -fno-delete-null-pointer-checks
that IMO can let me to pass it by reference.
Why this is not part of tree_expr_nonzero_p and vrp is not simply calling
it to set up the value ranges?
Honza
Index: tree-vrp.c
===
--- tree-vrp.c(revision 215901)
+++ tree-vrp.c(working copy)
@@ -365,6 +365,18 @@ nonnull_arg_p (const_tree arg)
if (arg == cfun-static_chain_decl)
return true;
+ /* THIS argument of method is always non-NULL. */
+ if (TREE_CODE (TREE_TYPE (current_function_decl)) == METHOD_TYPE
+ arg == DECL_ARGUMENTS (current_function_decl))
+return true;
+
+ /* Parameters passed by invisible reference are also always non-NULL
+ unsless we explicitly allow symbol to have NULL address, that is
+ permitted by -fno-delete-null-pointer-checks. */
+ if (DECL_BY_REFERENCE (arg)
+ flag_delete_null_pointer_checks)
+return true;
+
fntype = TREE_TYPE (current_function_decl);
for (attrs = TYPE_ATTRIBUTES (fntype); attrs; attrs = TREE_CHAIN (attrs))
{
@@ -772,7 +784,8 @@ get_value_range (const_tree var)
set_value_range_to_varying (vr);
}
else if (TREE_CODE (sym) == RESULT_DECL
-DECL_BY_REFERENCE (sym))
+DECL_BY_REFERENCE (sym)
+flag_delete_null_pointer_checks)
set_value_range_to_nonnull (vr, TREE_TYPE (sym));
}
[Bug c++/63459] operator new and returns_nonnull
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63459 --- Comment #6 from Jan Hubicka hubicka at ucw dot cz --- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63459 --- Comment #5 from Jan Hubicka hubicka at ucw dot cz --- Hi, does something like this make sense (I also updated the DECL_BY_REFERENCE check. We allow to put variable at address NULL with -fno-delete-null-pointer-checks that IMO can let me to pass it by reference. Hmm, actually in C++ one always gets a local copy. I wonder if other languages use it, but until one is found, I guess we do not need that test. Honza
[Bug c/63490] New: gcc-4.8 memcpy fails with internal compiler error: in ix86_copy_addr_to_reg, at config/i386/i386.c:21718
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63490
Bug ID: 63490
Summary: gcc-4.8 memcpy fails with internal compiler error: in
ix86_copy_addr_to_reg, at config/i386/i386.c:21718
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pekkanie at student dot oulu.fi
Created attachment 33668
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33668action=edit
Preprocessed source and precompiled *.s and *.i files
Compiling following code with gcc-4.8 produces:
#include stdio.h
#include string.h
#define SIZEOF_BUFFER 128
int main()
{
static char traceBuffer[SIZEOF_BUFFER];
memcpy((char *)0x40024000, traceBuffer, sizeof(traceBuffer));
return 0;
}
$ gcc memcpy_test.c -g -m32 -Wall -Wno-format -o memcpy.out
memcpy_test.c: In function ‘main’:
memcpy_test.c:10:8: internal compiler error: in ix86_copy_addr_to_reg, at
config/i386/i386.c:21718
memcpy((char *)0x40024000, traceBuffer, sizeof(traceBuffer));
^
Please submit a full bug report,
with preprocessed source if appropriate.
See file:///usr/share/doc/gcc-4.8/README.Bugs for instructions.
Preprocessed source stored into /tmp/ccZAYKJd.out file, please attach this to
your bugreport.
gcc version in use:
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.8.2-19ubuntu1'
--with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --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.8.2 (Ubuntu 4.8.2-19ubuntu1)
System:
$ lsb_release -rd
Description: Ubuntu 14.04.1 LTS
Release: 14.04
$ uname -a
Linux jeppe 3.13.0-36-generic #63-Ubuntu SMP Wed Sep 3 21:30:07 UTC 2014 x86_64
x86_64 x86_64 GNU/Linux
Not able to reproduce the issue with following gcc versions:
gcc version 5.0.0 20140919 (experimental) [trunk revision 215403] (Ubuntu
20140919-0ubuntu1))
gcc version 4.6.4 (Ubuntu/Linaro 4.6.4-6ubuntu2)
[Bug c/63490] gcc-4.8 memcpy fails with internal compiler error: in ix86_copy_addr_to_reg, at config/i386/i386.c:21718
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63490 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Dup. *** This bug has been marked as a duplicate of bug 60693 ***
[Bug target/60693] [4.8 Regression] ICE on funny memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60693 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||pekkanie at student dot oulu.fi --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org --- *** Bug 63490 has been marked as a duplicate of this bug. ***
[Bug libquadmath/63488] large errors in y0q
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63488 --- Comment #4 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- (In reply to jos...@codesourcery.com from comment #3) (Eventually I think we should provide _Float128 functions directly in glibc's libm on x86/x86_64, with the TS 18661-3 names, in which case libquadmath could become a thin wrapper round the libm versions, on platforms using current glibc or any other library providing the TS 18661-3 functions.) I would love that. We could even emit those directly from the Fortran front-end, on supported targets.
[Bug c++/63485] [5 Regression] ICE: canonical types differ for identical types Aconst wchar_t [3]::type and const char_type [3]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63485 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Wed Oct 8 20:27:11 2014 New Revision: 216012 URL: https://gcc.gnu.org/viewcvs?rev=216012root=gccview=rev Log: PR c++/63485 * tree.c (build_cplus_array_type): Look for a type with no typedef-name or attributes. Added: trunk/gcc/testsuite/g++.dg/template/array29.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/tree.c
[Bug libstdc++/61217] pop_heap can't guarantee At most 2 * log(last - first) comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61217 François Dumont fdumont at gcc dot gnu.org changed: What|Removed |Added CC||fdumont at gcc dot gnu.org --- Comment #1 from François Dumont fdumont at gcc dot gnu.org --- Rather than analysing the code I just add tests to the testsuite validating number of comparisons done for heap algos. See https://gcc.gnu.org/ml/libstdc++/2014-10/msg00058.html and there is no problem with pop_heap.
[Bug c++/63485] [5 Regression] ICE: canonical types differ for identical types Aconst wchar_t [3]::type and const char_type [3]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63485 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Target Milestone|--- |5.0 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org --- Fixed.
[Bug c++/63405] [4.9/5 regression] ICE in cp_perform_integral_promotions, at cp/typeck.c:2084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63405 --- Comment #13 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Wed Oct 8 21:06:00 2014 New Revision: 216014 URL: https://gcc.gnu.org/viewcvs?rev=216014root=gccview=rev Log: PR c++/63405 * pt.c (tsubst_pack_expansion): Limit simple expansion to type packs. Added: branches/gcc-4_9-branch/gcc/testsuite/g++.dg/cpp0x/variadic162.C Modified: branches/gcc-4_9-branch/gcc/cp/ChangeLog branches/gcc-4_9-branch/gcc/cp/pt.c
[Bug c++/63405] [4.9/5 regression] ICE in cp_perform_integral_promotions, at cp/typeck.c:2084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63405 --- Comment #12 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Wed Oct 8 21:05:50 2014 New Revision: 216013 URL: https://gcc.gnu.org/viewcvs?rev=216013root=gccview=rev Log: PR c++/63405 * pt.c (tsubst_pack_expansion): Limit simple expansion to type packs. Added: trunk/gcc/testsuite/g++.dg/cpp0x/variadic162.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
[Bug libstdc++/61107] stl_algo.h: std::__inplace_stable_partition() doesn't process the whole data range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61107 François Dumont fdumont at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-10-08 CC||fdumont at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |fdumont at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from François Dumont fdumont at gcc dot gnu.org --- There is indeed a bug, thanks for the report.
[Bug rtl-optimization/63491] New: Ice in LRA with simple vector test case on power
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63491
Bug ID: 63491
Summary: Ice in LRA with simple vector test case on power
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: bergner at gcc dot gnu.org
The following test case causes an ICE in LRA using trunk:
[bergner@makalu-lp1 LRA]$ cat pack01.i
typedef __int128_t __attribute__((__vector_size__(16))) vector_128_t;
typedef unsigned long long scalar_64_t;
void bar (vector_128_t);
void
foo (void)
{
union {
scalar_64_t i64[2];
vector_128_t v128;
} u;
u.i64[0] = 1;
u.i64[1] = 2;
bar (u.v128);
}
[bergner@makalu-lp1 LRA]$
/home/bergner/gcc/build/gcc-fsf-mainline-bootstrap-lra-debug/gcc/xgcc
-B/home/bergner/gcc/build/gcc-fsf-mainline-bootstrap-lra-debug/gcc/
-mcpu=power8 -O1 -S -m64 -mlra pack01.i
pack01.i: In function ‘foo’:
pack01.i:15:1: internal compiler error: in check_and_process_move, at
lra-constraints.c:1135
}
^
0x1087c5e3 check_and_process_move
/home/bergner/gcc/gcc-fsf-mainline-bootstrap-reload/gcc/lra-constraints.c:1132
0x108845d3 curr_insn_transform
/home/bergner/gcc/gcc-fsf-mainline-bootstrap-reload/gcc/lra-constraints.c:3274
0x10a3 lra_constraints(bool)
/home/bergner/gcc/gcc-fsf-mainline-bootstrap-reload/gcc/lra-constraints.c:4203
0x1086a163 lra(_IO_FILE*)
/home/bergner/gcc/gcc-fsf-mainline-bootstrap-reload/gcc/lra.c:2198
0x107ecc9b do_reload
/home/bergner/gcc/gcc-fsf-mainline-bootstrap-reload/gcc/ira.c:5311
0x107ed25f execute
/home/bergner/gcc/gcc-fsf-mainline-bootstrap-reload/gcc/ira.c:5470
The problematic rtl sequence is setting up the parameter to the call. After
IRA, we have the following rtl with pseudo 156 being allocated to hardreg
(pair) 10 (and 11).
(insn 12 5 13 2 (set (subreg:DI (reg/v:TI 156 [ u ]) 0)
(const_int 1 [0x1])) pack01.i:13 534 {*movdi_internal64}
(nil))
(insn 13 12 7 2 (set (subreg:DI (reg/v:TI 156 [ u ]) 8)
(const_int 2 [0x2])) pack01.i:13 534 {*movdi_internal64}
(nil))
(insn 7 13 8 2 (set (reg:V1TI 79 2)
(subreg:V1TI (reg/v:TI 156 [ u ]) 0)) pack01.i:14 967 {*vsx_movv1ti}
(expr_list:REG_DEAD (reg/v:TI 156 [ u ])
(nil)))
With reload (-mno-lra), we do:
Reload 1: reload_in (V1TI) = (reg:V1TI 10 10)
ALTIVEC_REGS, RELOAD_FOR_INPUT (opnum = 1), can't combine
reload_in_reg: (subreg:V1TI (reg/v:TI 10 10 [orig:156 u ] [156]) 0)
reload_reg_rtx: (reg:V1TI 79 2)
secondary_in_reload = 0
secondary_in_icode = reload_vsx_from_gprv1ti
which leads to:
(insn 12 5 13 2 (set (reg:DI 10 10 [ u ])
(const_int 1 [0x1])) pack01.i:13 534 {*movdi_internal64}
(nil))
(insn 13 12 17 2 (set (reg:DI 11 11 [orig:156 u+8 ] [156])
(const_int 2 [0x2])) pack01.i:13 534 {*movdi_internal64}
(nil))
(insn 17 13 8 2 (parallel [
(set (reg:V1TI 79 2)
(unspec:V1TI [
(reg:V1TI 10 10)
] UNSPEC_P8V_RELOAD_FROM_GPR))
(clobber (reg:TF 32 0))
]) pack01.i:14 513 {reload_vsx_from_gprv1ti}
(nil))
...and all is fine. However, with LRA (-mlra), we hit the assert in
check_and_process_move():
/* Check the target hook consistency. */
lra_assert
((secondary_class == NO_REGS sri.icode == CODE_FOR_nothing)
|| (old_sclass == NO_REGS old_sri.icode == CODE_FOR_nothing)
|| (secondary_class == old_sclass sri.icode == old_sri.icode));
Due to:
(gdb) p secondary_class
$1 = NO_REGS
(gdb) p (enum insn_code) sri.icode
$2 = CODE_FOR_reload_vsx_from_gprti
(gdb) p old_sclass
$3 = NO_REGS
(gdb) p (enum insn_code) old_sri.icode
$4 = CODE_FOR_reload_vsx_from_gprv1ti
The problem seems to be that LRA is trying to use
CODE_FOR_reload_vsx_from_gprti to reload the src rather than
CODE_FOR_reload_vsx_from_gprv1ti. This is due to calling
targetm.secondary_reload() with sreg_mode (ie, TImode) rather than V1TImode
that reload is calling it with. Shouldn't we be using V1TImode since we're
accessing src via a subreg:V1TI?
I'm marking this as an rtl issue for now, since the ICE is coming from LRA, but
I know this could end up as a target bug in the end.
[Bug rtl-optimization/63491] Ice in LRA with simple vector test case on power
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63491 Peter Bergner bergner at gcc dot gnu.org changed: What|Removed |Added Target||powerpc64-linux, ||powerpc64le-linux CC||meissner at gcc dot gnu.org, ||vmakarov at gcc dot gnu.org --- Comment #1 from Peter Bergner bergner at gcc dot gnu.org --- CCing Vlad and Mike for their input.
[Bug target/52941] SH Target: Add support for movco.l / movli.l atomics on SH4A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52941 --- Comment #16 from Oleg Endo olegendo at gcc dot gnu.org --- Author: olegendo Date: Wed Oct 8 23:13:02 2014 New Revision: 216018 URL: https://gcc.gnu.org/viewcvs?rev=216018root=gccview=rev Log: gcc/ PR target/52941 * config/sh/sync.md (atomic_exchangesi_hard, atomic_exchangemode_hard, atomic_fetch_fetchop_namesi_hard, atomic_fetch_fetchop_namemode_hard, atomic_fetch_nandsi_hard, atomic_fetch_nandmode_hard, atomic_fetchop_name_fetchsi_hard, atomic_fetchop_name_fetchmode_hard, atomic_nand_fetchsi_hard, atomic_nand_fetchmode_hard): Add missing set of T_REG. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sync.md
[Bug target/52941] SH Target: Add support for movco.l / movli.l atomics on SH4A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52941 --- Comment #17 from Oleg Endo olegendo at gcc dot gnu.org --- Author: olegendo Date: Wed Oct 8 23:15:44 2014 New Revision: 216019 URL: https://gcc.gnu.org/viewcvs?rev=216019root=gccview=rev Log: gcc/ Backport from mainline 2014-10-08 Oleg Endo olege...@gcc.gnu.org PR target/52941 * config/sh/sync.md (atomic_exchangesi_hard, atomic_exchangemode_hard, atomic_fetch_fetchop_namesi_hard, atomic_fetch_fetchop_namemode_hard, atomic_fetch_nandsi_hard, atomic_fetch_nandmode_hard, atomic_fetchop_name_fetchsi_hard, atomic_fetchop_name_fetchmode_hard, atomic_nand_fetchsi_hard, atomic_nand_fetchmode_hard): Add missing set of T_REG. Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config/sh/sync.md
[Bug target/52941] SH Target: Add support for movco.l / movli.l atomics on SH4A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52941 --- Comment #18 from Oleg Endo olegendo at gcc dot gnu.org --- Author: olegendo Date: Wed Oct 8 23:17:42 2014 New Revision: 216020 URL: https://gcc.gnu.org/viewcvs?rev=216020root=gccview=rev Log: gcc/ Backport from mainline 2014-10-08 Oleg Endo olege...@gcc.gnu.org PR target/52941 * config/sh/sync.md (atomic_exchangesi_hard, atomic_exchangemode_hard, atomic_fetch_fetchop_namesi_hard, atomic_fetch_fetchop_namemode_hard, atomic_fetch_nandsi_hard, atomic_fetch_nandmode_hard, atomic_fetchop_name_fetchsi_hard, atomic_fetchop_name_fetchmode_hard, atomic_nand_fetchsi_hard, atomic_nand_fetchmode_hard): Add missing set of T_REG. Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/config/sh/sync.md
[Bug other/63492] New: bconfig.h or config.h for gencondmd.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63492 Bug ID: 63492 Summary: bconfig.h or config.h for gencondmd.c Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: pangbw at gmail dot com I know config.h is for program running on host machine, bconfig.h is for program running on build machine, but for gencondmd.c the case is special, it is evaluating the macros would be defined on host instead of build machine, so I think config.h should be used for gencondmd.c.
[Bug go/63493] New: libgo: write power64 version of reflect.MakeFunc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63493 Bug ID: 63493 Summary: libgo: write power64 version of reflect.MakeFunc Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: ian at airs dot com CC: cmang at google dot com For efficiency, we should write a power64 version of reflect.MakeFunc. This means writing makefunc_power64be.s, makefunc_power64le.s, makefuncgo_power64be.go, and makefuncgo_power64le.go to implement the Power64 ABI calling convention, along the lines of the existing implementations for 386 and amd64. With the corresponding changes to MakeFunc, makeMethodValue, and makeValueMethod the reflect tests should continue to pass.
[Bug libfortran/63471] [5.0 Regression] unix.c:1906:10: error: implicit declaration of function 'ttyname_r'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63471 --- Comment #4 from dave.anglin at bell dot net --- There are more functions with this problem. The attached patch enables libgfortran to build on hpux11.11. Dave -- John David Anglindave.ang...@bell.net
[Bug libfortran/63471] [5.0 Regression] unix.c:1906:10: error: implicit declaration of function 'ttyname_r'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63471 --- Comment #5 from Janne Blomqvist jb at gcc dot gnu.org --- Ah, I suspected that other functions might be affected as well. Thanks for finding them. That being said, googling this issue I stumbled upon https://gcc.gnu.org/ml/gcc-patches/2011-03/msg00545.html where you fixed a similar issue for hp-ux 10, seemingly by making the driver always set _REENTRANT. Wouldn't a similar thing be the right thing to do for hp-ux 11 as well? If there are no ill effects of always enabling _REENTRANT that would help other software than just libgfortran, as well as eliminating the risk that unconditionally enabling _REENTRANT in libgfortran might break on some other target?
