[Bug c/61739] __builtin_printf optimization conflicts with POSIX semantics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61739
--- Comment #1 from Andreas Schwab ---
Since printf("") does not need to obtain ownership of stdout there is no
conflict here. There is no requirement that it *must* obtain ownership even if
not needed.
[Bug tree-optimization/61742] [4.10 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61742 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-07-08 CC||jakub at gcc dot gnu.org, ||kyukhin at gcc dot gnu.org, ||ysrumyan at gmail dot com Target Milestone|--- |4.10.0 Summary|wrong code at -O3 on|[4.10 Regression] wrong |x86_64-linux-gnu|code at -O3 on ||x86_64-linux-gnu Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r209972.
[Bug tree-optimization/61576] [4.10 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61576 --- Comment #6 from Kirill Yukhin --- Author: kyukhin Date: Tue Jul 8 07:52:12 2014 New Revision: 212347 URL: https://gcc.gnu.org/viewcvs?rev=212347&root=gcc&view=rev Log: PR tree-optimization/61576 gcc/ * tree-if-conv.c (is_cond_scalar_reduction): Add check that basic block containing reduction statement is predecessor of phi basi block. gcc/testsuite/ * gcc.dg/torture/pr61576.c: New test. Added: trunk/gcc/testsuite/gcc.dg/torture/pr61576.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-if-conv.c
[Bug middle-end/61734] [4.10 Regression] Regression in ABS_EXPR recognition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61734 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- So perhaps teach fold also about A CMP B ? A - B : -(A - B) etc.? Then it will handle this idiom even if the user writes it that way in the source.
[Bug ipa/61190] [4.8/4.9/4.10 Regression] g++.old-deja/g++.mike/p4736b.C FAILs at -O2/-Os/-O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61190 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- That looks like a too ugly hack. Much better is just to teach the ipa-pure-const pass about thunks IMHO, what they can and can't access.
[Bug tree-optimization/61743] New: Complete unroll is not happened for loops with short upper bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61743 Bug ID: 61743 Summary: Complete unroll is not happened for loops with short upper bound Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: ysrumyan at gmail dot com We discovered significant performance regression on one important benchmark from eembc2.0 suite after r211625. It turned out that complete unroll didn't happen. I prepared simple reproducer that exhibits the problem. If we compile it with '-Dbtype=int' both innermost loops are unrolled completely by latest trunk compiler: test.c:20:5: note: loop with 8 iterations completely unrolled test.c:11:5: note: loop with 8 iterations completely unrolled but if '-Dbtype=e_u8' unroll does not happen. Note also that for this particular test-case compiler built before r211625 performs curoll only for one loop.
[Bug tree-optimization/61743] Complete unroll is not happened for loops with short upper bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61743 --- Comment #1 from Yuri Rumyantsev --- Created attachment 33088 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33088&action=edit test-case to reproduce Use '-O3 -funroll-loops -Dbtype=[int,e_u8]' to reproduce.
[Bug tree-optimization/61680] [4.8/4.9/4.10 Regression] vectorization gives wrong answer for sandybridge target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61680 --- Comment #9 from Richard Biener --- Author: rguenth Date: Tue Jul 8 08:59:17 2014 New Revision: 212348 URL: https://gcc.gnu.org/viewcvs?rev=212348&root=gcc&view=rev Log: 2014-07-08 Richard Biener PR tree-optimization/61680 * tree-vect-data-refs.c (vect_analyze_data_ref_dependence): Handle properly all read-write dependences with group accesses. * gcc.dg/vect/pr61680.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/vect/pr61680.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-data-refs.c
[Bug c++/53585] template value parameter of pointer-to-member type incorrectly rejects non-direct values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53585 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #4 from Paolo Carlini --- Current clang rejects it.
[Bug tree-optimization/61681] [4.9/4.10 Regression] wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61681 --- Comment #3 from Richard Biener --- Author: rguenth Date: Tue Jul 8 09:04:29 2014 New Revision: 212349 URL: https://gcc.gnu.org/viewcvs?rev=212349&root=gcc&view=rev Log: 2014-07-08 Richard Biener PR tree-optimization/61681 * tree-ssa-structalias.c (find_what_var_points_to): Expand NONLOCAL inside ESCAPED. * gcc.dg/torture/pr61681.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr61681.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-structalias.c
[Bug tree-optimization/61743] [4.10 Regression] Complete unroll is not happened for loops with short upper bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61743 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-07-08 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |4.10.0 Summary|Complete unroll is not |[4.10 Regression] Complete |happened for loops with |unroll is not happened for |short upper bound |loops with short upper ||bound Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- I will have a look.
[Bug tree-optimization/61742] [4.10 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61742 Richard Biener changed: What|Removed |Added Keywords||wrong-code Priority|P3 |P1
[Bug lto/61741] wrong code by LTO on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61741 Richard Biener changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-07-08 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Richard Biener --- I believe I fixed sth similar for 4.10 already (it's mismatching -fstrict-overflow on compile-time vs. link-time). I will have a look again.
[Bug c/45289] gcc lacks a "posix" option for "-std" since POSIX 2008 defines special behavior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45289 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #12 from Richard Biener --- Closed as fixed in POSIX.
[Bug c/61739] __builtin_printf optimization conflicts with POSIX semantics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61739 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Richard Biener --- Agreed.
[Bug middle-end/61725] [4.9/4.10 Regression] __builtin_ffs(0) leads to wrong code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61725 --- Comment #5 from Jakub Jelinek --- Author: jakub Date: Tue Jul 8 09:39:57 2014 New Revision: 212353 URL: https://gcc.gnu.org/viewcvs?rev=212353&root=gcc&view=rev Log: PR tree-optimization/61725 * tree-vrp.c (extract_range_basic): Don't assume vr0 is unsigned range, use range_includes_zerop_p instead of integer_zerop on vr0->min, only use log2 of max if min is not negative. * gcc.dg/tree-ssa/vrp93.c: New test. * gcc.c-torture/execute/pr61725.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr61725.c trunk/gcc/testsuite/gcc.dg/tree-ssa/vrp93.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c
[Bug middle-end/61734] [4.10 Regression] Regression in ABS_EXPR recognition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61734 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #3 from Eric Botcazou --- > So perhaps teach fold also about A CMP B ? A - B : -(A - B) etc.? Then it > will handle this idiom even if the user writes it that way in the source. Interesting idea, although it doesn't fit into fold_cond_expr_with_comparison. Maybe the X - Y CMP 0 to X CMP Y transformation should simply be disabled again (except for EQ/NE) and the missing comment giving the rationale for this added.
[Bug middle-end/61725] [4.9/4.10 Regression] __builtin_ffs(0) leads to wrong code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61725 --- Comment #6 from Jakub Jelinek --- Author: jakub Date: Tue Jul 8 09:42:44 2014 New Revision: 212354 URL: https://gcc.gnu.org/viewcvs?rev=212354&root=gcc&view=rev Log: PR tree-optimization/61725 * tree-vrp.c (extract_range_basic): Don't assume vr0 is unsigned range, use range_includes_zerop_p instead of integer_zerop on vr0->min, only use log2 of max if min is not negative. * gcc.dg/tree-ssa/vrp93.c: New test. * gcc.c-torture/execute/pr61725.c: New test. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.c-torture/execute/pr61725.c branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/tree-ssa/vrp93.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/testsuite/ChangeLog branches/gcc-4_9-branch/gcc/tree-vrp.c
[Bug middle-end/61725] [4.9/4.10 Regression] __builtin_ffs(0) leads to wrong code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61725 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jakub Jelinek --- Should be fixed now.
[Bug middle-end/61734] [4.10 Regression] Regression in ABS_EXPR recognition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61734 --- Comment #4 from Jakub Jelinek --- Sure, I wouldn't change fold_cond_expr_with_comparison itself. Instead, next to the two spots that call fold_cond_expr_with_comparison add another two, which would if arg1 or op2 is a MINUS_EXPR where the first MINUS_EXPR operand is equal to one comparison operand and the other to the other one, basically undo your transformation for the purpose of the fold_cond_expr_with_comparison call; if that returns non-NULL, we'd fold to that, essentially undoing your transformation, but otherwise we wouldn't undo anything. Perhaps in addition to MINUS_EXPR we should handle PLUS_EXPR with INTEGER_CST second operand, so A >= 5 ? (A + (-5)) : -(A + (-5)) and similar cases.
[Bug c++/57466] [DR 1584] Argument deduction fails for 'const T*' when T is function type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57466 Paolo Carlini changed: What|Removed |Added Status|SUSPENDED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com --- Comment #3 from Paolo Carlini --- DR1584 is Ready.
[Bug web/61744] New: misleading documentation about cast of extended vectors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61744 Bug ID: 61744 Summary: misleading documentation about cast of extended vectors Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: web Assignee: unassigned at gcc dot gnu.org Reporter: vincenzo.innocente at cern dot ch At the very bottom of https://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html one reads "It is possible to cast from one vector type to another, provided they are of the same size (in fact, you can also cast vectors to and from other datatypes of the same size)." I find this misleading as the reader can think that the result of such a cast is similar to a C-style cast of each element, while instead is a simple "reinterpretation" of the bit content (as "memcpy"). I suggest to add "The result is a vector of the new type with the same bit-content of the original." One can even add ", not what expected from a C-style cast". Of course adding a proper conversion builtin (see PR61731) would definitively solve the issue ;-)
[Bug target/59843] ICE with return of generic vector on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59843 --- Comment #6 from alalaw01 at gcc dot gnu.org --- Author: alalaw01 Date: Tue Jul 8 10:32:57 2014 New Revision: 212355 URL: https://gcc.gnu.org/viewcvs?rev=212355&root=gcc&view=rev Log: Backport r211502: PR target/59843 Fix arm_neon.h ZIP/UZP/TRN for bigendian 2014-06-10 Alan Lawrence gcc/: * config/aarch64/aarch64-modes.def: Add V1DFmode. * config/aarch64/aarch64.c (aarch64_vector_mode_supported_p): Support V1DFmode. gcc/testsuite/: * gcc.dg/vect/vect-singleton_1.c: New file. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/vect/vect-singleton_1.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config/aarch64/aarch64-modes.def branches/gcc-4_9-branch/gcc/config/aarch64/aarch64.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug tree-optimization/61742] [4.10 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61742 --- Comment #2 from Yuri Rumyantsev --- This is duplicate of PR 61576 and it should pass after r212347.
[Bug c++/61745] New: template friend for dyadic operator- is only accepted if the monadic operator- follows it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61745
Bug ID: 61745
Summary: template friend for dyadic operator- is only accepted
if the monadic operator- follows it
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jarausch at igpm dot rwth-aachen.de
If a template class contains both, the monadic and the dyadic operator-
the friend declaration is only accepted if it preceeds the
definition of the monadic operator.
This occurs with gcc 4.7.4 4.8.3 and 4.9.0
template class Zp;
template
Zp operator-(const Zp& a, const Zp& b);
template
class Zp {
public:
static const INT p = P;
private:
INT val;
public:
Zp() : val(0) {}
Zp( INT x ) : val(x%p) { if (x < 0 ) x+= p; }
// this compiles only if the following definition is moved AFTER the friend
declataion
Zp operator-() const { return Zp(p-val); }
friend Zp operator- <>(const Zp& a, const Zp& b);
/*
Quest_Templ.C:23:28: error: declaration of 'operator-' as non-function
friend Zp operator- (const Zp& a, const Zp& b);
^
Quest_Templ.C:23:28: error: expected ';' at end of member declaration
Quest_Templ.C:23:30: error: expected unqualified-id before '<' token
friend Zp operator- (const Zp& a, const Zp& b);
*/
};
[Bug tree-optimization/61742] [4.10 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61742 --- Comment #3 from Jakub Jelinek --- Indeed, it is. Can you add the testcase from this PR to trunk? Then we can close it.
[Bug tree-optimization/61681] [4.9/4.10 Regression] wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61681 --- Comment #4 from Richard Biener --- Author: rguenth Date: Tue Jul 8 11:05:13 2014 New Revision: 212357 URL: https://gcc.gnu.org/viewcvs?rev=212357&root=gcc&view=rev Log: 2014-07-08 Richard Biener PR tree-optimization/61680 * tree-vect-data-refs.c (vect_analyze_data_ref_dependence): Handle properly all read-write dependences with group accesses. * gcc.dg/vect/pr61680.c: New testcase. PR tree-optimization/61681 * tree-ssa-structalias.c (find_what_var_points_to): Expand NONLOCAL inside ESCAPED. * gcc.dg/torture/pr61681.c: New testcase. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/torture/pr61681.c branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/vect/pr61680.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/testsuite/ChangeLog branches/gcc-4_9-branch/gcc/tree-ssa-structalias.c branches/gcc-4_9-branch/gcc/tree-vect-data-refs.c
[Bug tree-optimization/61680] [4.8/4.9/4.10 Regression] vectorization gives wrong answer for sandybridge target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61680 --- Comment #10 from Richard Biener --- Author: rguenth Date: Tue Jul 8 11:05:13 2014 New Revision: 212357 URL: https://gcc.gnu.org/viewcvs?rev=212357&root=gcc&view=rev Log: 2014-07-08 Richard Biener PR tree-optimization/61680 * tree-vect-data-refs.c (vect_analyze_data_ref_dependence): Handle properly all read-write dependences with group accesses. * gcc.dg/vect/pr61680.c: New testcase. PR tree-optimization/61681 * tree-ssa-structalias.c (find_what_var_points_to): Expand NONLOCAL inside ESCAPED. * gcc.dg/torture/pr61681.c: New testcase. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/torture/pr61681.c branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/vect/pr61680.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/testsuite/ChangeLog branches/gcc-4_9-branch/gcc/tree-ssa-structalias.c branches/gcc-4_9-branch/gcc/tree-vect-data-refs.c
[Bug tree-optimization/61681] [4.9/4.10 Regression] wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61681 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||4.8.3, 4.9.1 Resolution|--- |FIXED Known to fail||4.9.0 --- Comment #5 from Richard Biener --- Fixed.
[Bug tree-optimization/61680] [4.8 Regression] vectorization gives wrong answer for sandybridge target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61680 Richard Biener changed: What|Removed |Added Keywords||wrong-code Known to work||4.10.0, 4.9.1 Summary|[4.8/4.9/4.10 Regression] |[4.8 Regression] |vectorization gives wrong |vectorization gives wrong |answer for sandybridge |answer for sandybridge |target |target Known to fail||4.8.3, 4.9.0 --- Comment #11 from Richard Biener --- Fixed for 4.9.1 and trunk sofar.
[Bug tree-optimization/61634] [4.8/4.9/4.10 Regression] ICE in in vect_get_vec_def_for_operand, at tree-vect-stmts.c:1423
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61634 --- Comment #4 from Richard Biener --- We have patt_24 = DOT_PROD_EXPR <_12, _12, prephitmp_48>; and _12 = _11 >> 2; is not STMT_VINFO_IN_PATTERN_P but it doesn't have a vec_stmt yet even though it is there: vect__12.29_90 = vect__11.27_87 >> 2; vect__12.29_91 = vect__11.28_89 >> 2; _12 = _11 >> 2; that's because vectorizable_shift doesn't assign to *vec_stmt!? if (slp_node) continue; if (j == 0) STMT_VINFO_VEC_STMT (stmt_info) = *vec_stmt = new_stmt; else STMT_VINFO_RELATED_STMT (prev_stmt_info) = new_stmt; if it's part of an SLP node... (pure_slp). I'm not sure we can vectorize this case.
[Bug middle-end/61734] [4.10 Regression] Regression in ABS_EXPR recognition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61734 --- Comment #5 from Marc Glisse --- (In reply to Jakub Jelinek from comment #2) > So perhaps teach fold also about A CMP B ? A - B : -(A - B) etc.? Or teach phiopt about A CMP B ? (U)((T)A - (T)B) : (U)((T)B - (T)A)? Hmm, it is starting to be a bit big, with a number of variations depending on where the casts are. fold may be easier indeed. (In reply to Jakub Jelinek from comment #4) > Perhaps in addition to MINUS_EXPR we should handle PLUS_EXPR with > INTEGER_CST second operand, so > A >= 5 ? (A + (-5)) : -(A + (-5)) and similar cases. I believe we canonicalize A+(-5) to A-5, but A >= -5 ? (A + 5) : -(A + 5) is the same idea.
[Bug c++/61745] template friend for dyadic operator- is only accepted if the monadic operator- follows it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61745 --- Comment #1 from Jonathan Wakely --- This seems to be what the standard requires, why do you think it's a bug?
[Bug tree-optimization/61742] [4.10 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61742 --- Comment #4 from Yuri Rumyantsev --- Ok. I will add it. 2014-07-08 14:45 GMT+04:00 jakub at gcc dot gnu.org : > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61742 > > --- Comment #3 from Jakub Jelinek --- > Indeed, it is. Can you add the testcase from this PR to trunk? Then we can > close it. > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug go/61746] New: A line starting with /*// causes an error even if the /* is closed on the next line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61746 Bug ID: 61746 Summary: A line starting with /*// causes an error even if the /* is closed on the next line Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: erezh at il dot ibm.com CC: cmang at google dot com Created attachment 33089 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33089&action=edit The file to compile to produce the error OS: Ubuntu 14.04 LTS, on either amd64 or ppc64le gccgo version: go version xgcc (Ubuntu 4.9-20140406-0ubuntu1) 4.9.0 20140405 (experimental) [trunk revision 209157] linux/amd64 [or linux/ppc64] How-to-produce: Compile the attached file hello.go.Tthe compiler responds with an error as following: # gccgo -g -save-temps -o hello hello.go hello.go:7:4: error: expected declaration /*// problem comment here ^ hello.go:8:1: error: expected declaration */ ^ hello.go:12:1: error: expected declaration } ^ Expected-output: There should be no error. When compiling with golang-go 1.2.2, there isn't an error produced.
[Bug c++/61745] template friend for dyadic operator- is only accepted if the monadic operator- follows it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61745 --- Comment #2 from Jonathan Wakely --- Clang and EDG behave the same as G++ for this code.
[Bug tree-optimization/61747] New: min,max pattern not always properly optimized (for sse4 targets)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61747
Bug ID: 61747
Summary: min,max pattern not always properly optimized (for
sse4 targets)
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vincenzo.innocente at cern dot ch
I was expecting gcc to substitute min/max instruction for (a>/
V1 vmax(V1 a, V1 b) {
return (a>b) ? a : b;
}
template
V1 vmin(V1 a, V1 b) {
return (a
Float bart(Float a) {
constexpr Float zero{0.f};
constexpr Float it = zero+4.f;
constexpr Float zt = zero-3.f;
return vmin(vmax(a,zt),it);
}
float bar(float a) {
return bart(a);
}
float32x4_t bar(float32x4_t a) {
return bart(a);
}
I see
c++ -std=c++11 -O2 -msse4.2 -s vmin.cc -S; cat vmin.s
__Z3foofff:
LFB2:
maxss%xmm1, %xmm0
minss%xmm2, %xmm0
ret
__Z3fooDv4_fS_S_:
LFB3:
maxps%xmm1, %xmm0
minps%xmm2, %xmm0
ret
__Z3barf:
LFB5:
ucomissLC3(%rip), %xmm0
jbeL12
minssLC2(%rip), %xmm0
ret
.align 4,0x90
L12:
movssLC3(%rip), %xmm0
ret
__Z3barDv4_f:
LFB6:
movapsLC5(%rip), %xmm1
movaps%xmm0, %xmm2
movaps%xmm1, %xmm0
cmpltps%xmm2, %xmm0
blendvps%xmm0, %xmm2, %xmm1
movapsLC6(%rip), %xmm2
movaps%xmm1, %xmm0
cmpltps%xmm2, %xmm0
blendvps%xmm0, %xmm1, %xmm2
movaps%xmm2, %xmm0
ret
-
c++ -std=c++11 -O2 -msse4.2 -s vmin.cc -S -ffinite-math-only; cat vmin.s
__Z3foofff:
LFB2:
maxss%xmm0, %xmm1
minss%xmm2, %xmm1
movaps%xmm1, %xmm0
ret
__Z3fooDv4_fS_S_:
LFB3:
maxps%xmm1, %xmm0
movaps%xmm0, %xmm1
movaps%xmm2, %xmm0
cmpleps%xmm1, %xmm0
blendvps%xmm0, %xmm2, %xmm1
movaps%xmm1, %xmm0
ret
__Z3barf:
LFB5:
maxssLC2(%rip), %xmm0
minssLC3(%rip), %xmm0
ret
__Z3barDv4_f:
LFB6:
movapsLC5(%rip), %xmm1
movaps%xmm0, %xmm2
movaps%xmm1, %xmm0
cmpltps%xmm2, %xmm0
blendvps%xmm0, %xmm2, %xmm1
movapsLC6(%rip), %xmm2
movaps%xmm1, %xmm0
cmpltps%xmm2, %xmm0
blendvps%xmm0, %xmm1, %xmm2
movaps%xmm2, %xmm0
ret
LFE6:
--
eventually
c++ -std=c++11 -Ofast -msse4.2 -s vmin.cc -S; cat vmin.s
__Z3foofff:
LFB2:
maxss%xmm0, %xmm1
minss%xmm2, %xmm1
movaps%xmm1, %xmm0
ret
__Z3fooDv4_fS_S_:
LFB3:
maxps%xmm0, %xmm1
minps%xmm2, %xmm1
movaps%xmm1, %xmm0
ret
__Z3barf:
LFB5:
maxssLC2(%rip), %xmm0
minssLC3(%rip), %xmm0
ret
__Z3barDv4_f:
LFB6:
maxpsLC5(%rip), %xmm0
minpsLC6(%rip), %xmm0
ret
[Bug middle-end/60102] [4.9/4.10 Regression] powerpc fp-bit ices at dwf_regno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60102 Rohit changed: What|Removed |Added CC||rohitarulraj at gmail dot com --- Comment #14 from Rohit --- I have tried to handle this as per comment #12. https://gcc.gnu.org/ml/gcc-patches/2014-07/msg00513.html
[Bug middle-end/61748] New: imm-devirt-2.C failed on arm-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61748
Bug ID: 61748
Summary: imm-devirt-2.C failed on arm-linux
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: amker at gcc dot gnu.org
Hi,
The newly added test check fails on
arm-none-linux-gnueabi/arm-none-linux-gnueabihf.
Compiled with below command:
$ g++ -O2 -S imm-devirt-2.C -o imm-devirt-2.S -fdump-tree-einline(-details)
The gcc is configured with below command:
$ ../gcc/configure
--prefix=/home/binche01/work/a15-cross/trunk-systematic-testing/target
--enable-languages=c,c++,fortran
--with-sysroot=/home/binche01/work/a15-cross/qemu-setup/gcc-linaro-arm-linux-gnueabihf-4.8-2013.12_linux/arm-linux-gnueabihf/libc
--with-gmp=/home/binche01/work/a15-cross/host-lib-arm/target
--with-mpfr=/home/binche01/work/a15-cross/host-lib-arm/target
--with-mpc=/home/binche01/work/a15-cross/host-lib-arm/target
--host=arm-linux-gnueabihf --build=arm-linux-gnueabihf --with-mode=thumb
--with-arch=armv7-a --with-tune=cortex-a15 --target=arm-linux-gnueabihf
--with-float=hard --with-fpu=neon --disable-bootstrap
The scan test fails as:
FAIL: g++.dg/ipa/imm-devirt-2.C -std=gnu++98 scan-tree-dump einline
"C::_ZThn24_N1C3fooEi \\("
Apparently there is no such information in the dump file as attached.
[Bug middle-end/61748] imm-devirt-2.C failed on arm-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61748 --- Comment #1 from amker at gcc dot gnu.org --- Created attachment 33090 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33090&action=edit Dump file of einline pass
[Bug c/61739] __builtin_printf optimization conflicts with POSIX semantics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61739
Rich Felker changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |---
--- Comment #3 from Rich Felker ---
Yes it does need to obtain ownership of the file: to set the orientation to
byte mode. This is required even by ISO C (without POSIX). A simpler test case:
printf("");
printf("%d\n", fwide(stdout));
[Bug c/61739] __builtin_printf optimization conflicts with POSIX semantics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61739
--- Comment #4 from Rich Felker ---
Sorry, that should be:
printf("");
printf("%d\n", fwide(stdout, 0));
[Bug target/61749] New: arm_neon.h "_lane" and "_n" intrinsics can cause ICEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61749
Bug ID: 61749
Summary: arm_neon.h "_lane" and "_n" intrinsics can cause ICEs
Product: gcc
Version: 4.8.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jgreenhalgh at gcc dot gnu.org
Given the following, all release branch and trunk AArch64 compilers will ICE
trying to expand the intrinsic.
#include "arm_neon.h"
int32x4_t foo (int32x4_t a, int16x4_t b, int16x4_t c, int d)
{
return vqdmlal_lane_s16 (a, b, c, 0);
}
As so:
/work/gcc-dev/build-aarch64-none-elf/install/lib/gcc/aarch64-none-elf/4.10.0/include/arm_neon.h:
In function 'foo':
/work/gcc-dev/build-aarch64-none-elf/install/lib/gcc/aarch64-none-elf/4.10.0/include/arm_neon.h:19294:10:
internal compiler error: in aarch64_simd_lane_bounds, at
config/aarch64/aarch64.c:7715
return __builtin_aarch64_sqdmlal_lanev4hi (__a, __b, __c, __d);
^
0xc608d0 aarch64_simd_lane_bounds(rtx_def*, long, long)
/work/gcc-dev/src/gcc/gcc/config/aarch64/aarch64.c:7715
0xcb0221 gen_aarch64_sqdmlal_lanev4hi(rtx_def*, rtx_def*, rtx_def*, rtx_def*,
rtx_def*)
/work/gcc-dev/src/gcc/gcc/config/aarch64/aarch64-simd.md:3015
0xc65b7f insn_gen_fn::operator()(rtx_def*, rtx_def*, rtx_def*, rtx_def*,
rtx_def*) const
/work/gcc-dev/src/gcc/gcc/recog.h:311
0xc65b7f aarch64_simd_expand_args
/work/gcc-dev/src/gcc/gcc/config/aarch64/aarch64-builtins.c:888
0xc66318 aarch64_simd_expand_builtin(int, tree_node*, rtx_def*)
/work/gcc-dev/src/gcc/gcc/config/aarch64/aarch64-builtins.c:990
0xc66968 aarch64_expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode,
int)
/work/gcc-dev/src/gcc/gcc/config/aarch64/aarch64-builtins.c:1071
0x6062a2 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
/work/gcc-dev/src/gcc/gcc/builtins.c:5756
0x6f897b expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/work/gcc-dev/src/gcc/gcc/expr.c:10344
0x6f9e7c expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
/work/gcc-dev/src/gcc/gcc/expr.c:7922
0x70078f store_expr(tree_node*, rtx_def*, int, bool)
/work/gcc-dev/src/gcc/gcc/expr.c:5312
0x7092b8 expand_assignment(tree_node*, tree_node*, bool)
/work/gcc-dev/src/gcc/gcc/expr.c:5098
0x626493 expand_call_stmt
/work/gcc-dev/src/gcc/gcc/cfgexpand.c:2305
0x626493 expand_gimple_stmt_1
/work/gcc-dev/src/gcc/gcc/cfgexpand.c:3202
0x626493 expand_gimple_stmt
/work/gcc-dev/src/gcc/gcc/cfgexpand.c:3354
0x628d75 expand_gimple_basic_block
/work/gcc-dev/src/gcc/gcc/cfgexpand.c:5192
0x62ad53 execute
/work/gcc-dev/src/gcc/gcc/cfgexpand.c:5799
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
The bug is in the treatment in aarch64-simd-builtins.def of these lane
intrinsics as "QUADOP"s. This allows their final parameter to *maybe* be an
immediate. But subsequent code on the expand path assumes it to *always* be an
immediate.
The fix would to special case the handling of these intrinsics and enforce that
the final parameter is *always* an immediate.
For 4.10 and 4.9 that means adding a new set of types to "qualifiers". For 4.8,
it means adding a new aarch64_simd_itype and handling it appropriately.
[Bug target/61749] arm_neon.h "_lane" and "_n" intrinsics can cause ICEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61749 jgreenhalgh at gcc dot gnu.org changed: What|Removed |Added Target||aarch64* Status|UNCONFIRMED |NEW Last reconfirmed||2014-07-08 Assignee|unassigned at gcc dot gnu.org |jgreenhalgh at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from jgreenhalgh at gcc dot gnu.org --- This is an AArch64 bug.
[Bug target/61749] arm_neon.h "_lane" and "_n" intrinsics can cause ICEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61749
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
CC||ktkachov at gcc dot gnu.org
--- Comment #2 from ktkachov at gcc dot gnu.org ---
Confirmed, also the testcase would be:
#include "arm_neon.h"
int32x4_t foo (int32x4_t a, int16x4_t b, int16x4_t c, int d)
{
return vqdmlal_lane_s16 (a, b, c, d);
}
[Bug tree-optimization/61747] min,max pattern not always properly optimized (for sse4 targets)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61747 --- Comment #1 from Marc Glisse --- I think you need -fno-signed-zeros for the transformation to be valid.
[Bug tree-optimization/61747] min,max pattern not always properly optimized (for sse4 targets)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61747 --- Comment #2 from vincenzo Innocente --- > I think you need -fno-signed-zeros for the transformation to be valid. possible. but then is the O2 code that is wrong? in any case adding -fno-signed-zeros makes no difference w/r/t O2 alone
[Bug tree-optimization/61747] min,max pattern not always properly optimized (for sse4 targets)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61747 --- Comment #3 from Marc Glisse --- (In reply to vincenzo Innocente from comment #2) > > I think you need -fno-signed-zeros for the transformation to be valid. > possible. > but then is the O2 code that is wrong? > in any case adding -fno-signed-zeros makes no difference w/r/t O2 alone -fno-signed-zeros comes in addition to some flag saying there are no NaNs (-ffinite-math-only for instance).
[Bug ipa/61750] New: Compiling gfortran.dg/where_operator_assign_2.f90 with -O3 -fwhole-program gives an ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61750 Bug ID: 61750 Summary: Compiling gfortran.dg/where_operator_assign_2.f90 with -O3 -fwhole-program gives an ICE Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr Compiling gfortran.dg/where_operator_assign_2.f90 with -O3 -fwhole-program gives an ICE for 4.9 and 4.10 configured with the default --enable-checking. [Book15] f90/bug% gfc /opt/gcc/work/gcc/testsuite/gfortran.dg/where_operator_assign_2.f90 -O3 -fwhole-program /opt/gcc/work/gcc/testsuite/gfortran.dg/where_operator_assign_2.f90: In function 'test': /opt/gcc/work/gcc/testsuite/gfortran.dg/where_operator_assign_2.f90:44:0: error: conversion of register to a different size program test ^ VIEW_CONVERT_EXPR(pretmp_322); _330 = VIEW_CONVERT_EXPR(pretmp_322); /opt/gcc/work/gcc/testsuite/gfortran.dg/where_operator_assign_2.f90:44:0: error: conversion of register to a different size VIEW_CONVERT_EXPR(pretmp_30); _328 = VIEW_CONVERT_EXPR(pretmp_30); /opt/gcc/work/gcc/testsuite/gfortran.dg/where_operator_assign_2.f90:44:0: error: conversion of register to a different size VIEW_CONVERT_EXPR(pretmp_666); _326 = VIEW_CONVERT_EXPR(pretmp_666); /opt/gcc/work/gcc/testsuite/gfortran.dg/where_operator_assign_2.f90:44:0: error: conversion of register to a different size VIEW_CONVERT_EXPR(pretmp_147); _325 = VIEW_CONVERT_EXPR(pretmp_147); /opt/gcc/work/gcc/testsuite/gfortran.dg/where_operator_assign_2.f90:44:0: error: conversion of register to a different size VIEW_CONVERT_EXPR(pretmp_322); _323 = VIEW_CONVERT_EXPR(pretmp_322); /opt/gcc/work/gcc/testsuite/gfortran.dg/where_operator_assign_2.f90:44:0: error: conversion of register to a different size VIEW_CONVERT_EXPR(pretmp_30); _321 = VIEW_CONVERT_EXPR(pretmp_30); /opt/gcc/work/gcc/testsuite/gfortran.dg/where_operator_assign_2.f90:44:0: error: conversion of register to a different size VIEW_CONVERT_EXPR(pretmp_666); _319 = VIEW_CONVERT_EXPR(pretmp_666); /opt/gcc/work/gcc/testsuite/gfortran.dg/where_operator_assign_2.f90:44:0: error: conversion of register to a different size VIEW_CONVERT_EXPR(pretmp_147); _307 = VIEW_CONVERT_EXPR(pretmp_147); /opt/gcc/work/gcc/testsuite/gfortran.dg/where_operator_assign_2.f90:44:0: error: conversion of register to a different size VIEW_CONVERT_EXPR(pretmp_322); _303 = VIEW_CONVERT_EXPR(pretmp_322); /opt/gcc/work/gcc/testsuite/gfortran.dg/where_operator_assign_2.f90:44:0: error: conversion of register to a different size VIEW_CONVERT_EXPR(pretmp_30); _286 = VIEW_CONVERT_EXPR(pretmp_30); /opt/gcc/work/gcc/testsuite/gfortran.dg/where_operator_assign_2.f90:44:0: error: conversion of register to a different size VIEW_CONVERT_EXPR(pretmp_666); _285 = VIEW_CONVERT_EXPR(pretmp_666); /opt/gcc/work/gcc/testsuite/gfortran.dg/where_operator_assign_2.f90:44:0: error: conversion of register to a different size VIEW_CONVERT_EXPR(pretmp_147); _281 = VIEW_CONVERT_EXPR(pretmp_147); /opt/gcc/work/gcc/testsuite/gfortran.dg/where_operator_assign_2.f90:44:0: error: conversion of register to a different size VIEW_CONVERT_EXPR(pretmp_322); _256 = VIEW_CONVERT_EXPR(pretmp_322); /opt/gcc/work/gcc/testsuite/gfortran.dg/where_operator_assign_2.f90:44:0: error: conversion of register to a different size VIEW_CONVERT_EXPR(pretmp_30); _251 = VIEW_CONVERT_EXPR(pretmp_30); /opt/gcc/work/gcc/testsuite/gfortran.dg/where_operator_assign_2.f90:44:0: error: conversion of register to a different size VIEW_CONVERT_EXPR(pretmp_666); _250 = VIEW_CONVERT_EXPR(pretmp_666); /opt/gcc/work/gcc/testsuite/gfortran.dg/where_operator_assign_2.f90:44:0: error: conversion of register to a different size VIEW_CONVERT_EXPR(pretmp_147); _242 = VIEW_CONVERT_EXPR(pretmp_147); /opt/gcc/work/gcc/testsuite/gfortran.dg/where_operator_assign_2.f90:44:0: internal compiler error: verify_gimple failed /opt/gcc/work/gcc/testsuite/gfortran.dg/where_operator_assign_2.f90:44:0: internal compiler error: Abort trap: 6 gfc: internal compiler error: Abort trap: 6 (program f951) Abort The errors and ICE go away if gcc is configured with --enable-checking=release or when compiling with -O2 -ftree-vectorize -fwhole-program.
[Bug tree-optimization/61747] min,max pattern not always properly optimized (for sse4 targets)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61747 --- Comment #4 from vincenzo Innocente --- confirm that -ffinite-math-only -fno-signed-zeros is equivalent to Ofast in this case so we conclude that the code generated at O2 is wrong and -ffinite-math-only -fno-signed-zeros is required to trigger min/max?
[Bug ipa/61750] Compiling gfortran.dg/where_operator_assign_2.f90 with -O3 -fwhole-program gives an ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61750 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-07-08 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- I will have a look.
[Bug rtl-optimization/61673] [4.9/4.10 Regression] Miscompilation of _gnutls_hostname_compare on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61673 --- Comment #2 from Jakub Jelinek --- Author: jakub Date: Tue Jul 8 15:39:36 2014 New Revision: 212364 URL: https://gcc.gnu.org/viewcvs?rev=212364&root=gcc&view=rev Log: PR rtl-optimization/61673 * combine.c (simplify_comparison): Test just mode's sign bit in tmode rather than the sign bit and any bits above it. * gcc.c-torture/execute/pr61673.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr61673.c Modified: trunk/gcc/ChangeLog trunk/gcc/combine.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/61673] [4.9/4.10 Regression] Miscompilation of _gnutls_hostname_compare on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61673 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Tue Jul 8 15:43:39 2014 New Revision: 212365 URL: https://gcc.gnu.org/viewcvs?rev=212365&root=gcc&view=rev Log: PR rtl-optimization/61673 * combine.c (simplify_comparison): Test just mode's sign bit in tmode rather than the sign bit and any bits above it. * gcc.c-torture/execute/pr61673.c: New test. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.c-torture/execute/pr61673.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/combine.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug tree-optimization/61747] min,max pattern not always properly optimized (for sse4 targets)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61747
--- Comment #5 from Richard Biener ---
;; ??? For !flag_finite_math_only, the representation with SMIN/SMAX
;; isn't really correct, as those rtl operators aren't defined when
;; applied to NaNs. Hopefully the optimizers won't get too smart on us.
(define_expand "3"
[(set (match_operand:VF 0 "register_operand")
(smaxmin:VF
(match_operand:VF 1 "")
(match_operand:VF 2 "")))]
"TARGET_SSE && &&
"
{
if (!flag_finite_math_only)
operands[1] = force_reg (mode, operands[1]);
ix86_fixup_binary_operands_no_copy (, mode, operands);
})
and
;; These versions of the min/max patterns implement exactly the operations
;; min = (op1 < op2 ? op1 : op2)
;; max = (!(op1 < op2) ? op1 : op2)
;; Their operands are not commutative, and thus they may be used in the
;; presence of -0.0 and NaN.
(define_insn "*ieee_smin3"
[(set (match_operand:VF 0 "register_operand" "=v,v")
(unspec:VF
[(match_operand:VF 1 "register_operand" "0,v")
(match_operand:VF 2 "nonimmediate_operand" "vm,vm")]
UNSPEC_IEEE_MIN))]
"TARGET_SSE"
...
maybe explain the -O2 code. Note that the middle-end uses min/max
regardless of flags and makes it the targets responsibility to disable
instructions that don't conform to IEEE.
The above suggests that a>b ? a : b isn't IEEE conform on x86.
[Bug rtl-optimization/61673] [4.9/4.10 Regression] Miscompilation of _gnutls_hostname_compare on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61673 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- Fixed.
[Bug c++/61751] New: Empty brace-initializer causes double destruction of unique_ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61751
Bug ID: 61751
Summary: Empty brace-initializer causes double destruction of
unique_ptr
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: perso...@e-maxx.ru
Created attachment 33091
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33091&action=edit
Full example.
Use of empty brace-initializer in default function argument causes strange
effects and, finally, crashes.
The minimal code is:
#include
class A {
std::unique_ptr ptr_;
public:
A() : ptr_(new int(123))
{ }
A(A&& other) : ptr_(std::move(other.ptr_))
{ }
};
void f(A a)
{ }
void g(A a = {}) // replace "{}" with "A()" makes it work
{ f(std::move(a)); }
int main()
{ g(); }
There is a more detailed example in the attachment, which produces some debug
output, e.g.:
A() called [this=0x7bac34f0, constructed unique_ptr=0xe18010]
A(A&&) called [this=0x7bac34b0, other=0x7bac34d0]
~A() called [this=0x7bac34b0, unique_ptr=0xe18010]
~A() called [this=0x7bac34f0, unique_ptr=0xe18010]
*** glibc detected *** ./a.out: double free or corruption (fasttop):
0x00e18010 ***
On the contrary, using some correct version of compiler (I tried 4.6.3 and
4.9.0) we get:
A() called [this=0x7fff77c52810, constructed unique_ptr=0xe1c010]
A(A&&) called [this=0x7fff77c527e0, other=0x7fff77c52810]
~A() called [this=0x7fff77c527e0, unique_ptr=0xe1c010]
~A() called [this=0x7fff77c52810, unique_ptr=0]
As it can be seen, the difference is that the bogus version moves from object
that has never been constructed.
[Bug libgcc/61752] New: on cygwin, aborts during exit() with a dynamically loaded C++ library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61752
Bug ID: 61752
Summary: on cygwin, aborts during exit() with a dynamically
loaded C++ library
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: jon.turney at dronecode dot org.uk
Target: i686-pc-cygwin
There seems to be a problem somehow related to having a C++ library which does
depend on libgcc dynamically loaded by a C program which doesn't depend on
libgcc, where abort is being called during exit()
This seems to be specific to x86 cygwin/mingw targets with dw2 eh
test.c:
#include
#include
int main()
{
void *h = dlopen("dllib.dll", 0);
assert(h);
dlclose(h);
}
dllib.c:
#include
std::fstream instance;
Makefile:
all:
g++ -g -O0 -c dllib.cc
g++ -g -O0 -shared -o dllib.dll dllib.o
gcc -g -O0 -o test.exe test.c
./test
Running under gdb shows gcc_abort() in __deregister_frame_info_bases() is being
hit
$ gdb test
[...]
Program received signal SIGABRT, Aborted.
0x0028da18 in ?? ()
(gdb) bt
#0 0x0028da18 in ?? ()
#1 0x74f912cc in WriteFile () from /cygdrive/c/Windows/syswow64/kernel32.dll
#2 0x610da70c in sig_send(_pinfo*, siginfo_t&, _cygtls*)@12
(p=p@entry=0x60fd, si=..., tls=tls@entry=0x0)
at /usr/src/debug/cygwin-1.7.30-1/winsup/cygwin/sigproc.cc:638
#3 0x610d7dbc in _pinfo::kill(siginfo_t&)@8 (this=0x60fd, si=...)
at /usr/src/debug/cygwin-1.7.30-1/winsup/cygwin/signal.cc:248
#4 0x610d8286 in kill0 (pid=pid@entry=5044, si=...) at
/usr/src/debug/cygwin-1.7.30-1/winsup/cygwin/signal.cc:299
#5 0x610d8452 in kill (sig=sig@entry=6, pid=5044) at
/usr/src/debug/cygwin-1.7.30-1/winsup/cygwin/signal.cc:308
#6 raise (sig=sig@entry=6) at
/usr/src/debug/cygwin-1.7.30-1/winsup/cygwin/signal.cc:284
#7 0x610d86f3 in abort () at
/usr/src/debug/cygwin-1.7.30-1/winsup/cygwin/signal.cc:371
#8 0x699134d1 in __deregister_frame_info_bases (begin=0x404038
<__EH_FRAME_BEGIN__>)
at /usr/src/debug/gcc-4.8.3-1/libgcc/unwind-dw2-fde.c:216
#9 0x00401182 in __gcc_deregister_frame ()
#10 0x61006466 in do_global_dtors () at
/usr/src/debug/cygwin-1.7.30-1/winsup/cygwin/dcrt0.cc:62
#11 0x61159aba in __call_exitprocs (code=code@entry=0, d=d@entry=0x0)
at /usr/src/debug/cygwin-1.7.30-1/newlib/libc/stdlib/__call_atexit.c:118
#12 0x611305d8 in exit (code=0) at
/usr/src/debug/cygwin-1.7.30-1/newlib/libc/stdlib/exit.c:66
#13 0x61006b39 in cygwin_exit (n=0) at
/usr/src/debug/cygwin-1.7.30-1/winsup/cygwin/dcrt0.cc:1248
#14 0x61008041 in cygwin_exit_return () at
/usr/src/debug/cygwin-1.7.30-1/winsup/cygwin/dcrt0.cc:1041
#15 0x61005e84 in _cygtls::call2(unsigned long (*)(void*, void*), void*,
void*)@16 (this=,
func=func@entry=0x610071d0 , arg=arg@entry=0x0,
buf=buf@entry=0x28cd84)
at /usr/src/debug/cygwin-1.7.30-1/winsup/cygwin/cygtls.cc:100
#16 0x61005ff6 in _cygtls::call (func=func@entry=0x610071d0
, arg=arg@entry=0x0)
at /usr/src/debug/cygwin-1.7.30-1/winsup/cygwin/cygtls.cc:30
#17 0x61006f54 in _dll_crt0@0 () at
/usr/src/debug/cygwin-1.7.30-1/winsup/cygwin/dcrt0.cc:1098
#18 0x00401222 in cygwin_crt0 (f=0x4011a0 ) at
/usr/src/debug/cygwin-1.7.30-1/winsup/cygwin/lib/cygwin_crt0.c:22
#19 0x00401015 in mainCRTStartup () at
/usr/src/debug/cygwin-1.7.30-1/winsup/cygwin/crt0.c:29
[Bug libgcc/61752] on cygwin, aborts during exit() with a dynamically loaded C++ library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61752 --- Comment #1 from jon.turney at dronecode dot org.uk --- Created attachment 33092 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33092&action=edit Patch to cygming-crtbegin.c to prevent libgcc pinning itself in memory This seems to be caused by the fix for pr 57982, to fix a different abort during __gcc_deregister_frame() Since that change is baked into libgcc itself, that patch has the side-effect of making libgcc pin itself in memory. I can't really tell from what's written there if that was deliberate or not, but it seems that it introduces a different problem when the executable doesn't have a dependency on libgcc. Attached is a patch which modifies __gcc_register_frame() to avoid it pinning itself in memory. Alternatively, as [1] says, the assert in __deregister_frame_info_bases() itself could be removed. [1] http://www.mail-archive.com/gcc@gcc.gnu.org/msg68286.html
[Bug c++/61753] New: [4.7.2 regression] prototype for function does not match any in class error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61753 Bug ID: 61753 Summary: [4.7.2 regression] prototype for function does not match any in class error Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: shapero at uw dot edu I'm trying to compile the Pegmatite library: https://github.com/CompilerTeaching/Pegmatite The commit I'm working off of is f5a941ebad149470fa633ba4fdbae318b1e66782. The library compiles and runs fine with the most recent version of clang and with g++ 4.6.3, on Linux Mint 14. However, using g++ 4.7.2, I get the following error message: /home/daniel/programs/Pegmatite/parser.cc:1330:7: error: prototype for ‘pegmatite::Rule::Rule(pegmatite::ExprPtr)’ does not match any in class ‘pegmatite::Rule’ In file included from /home/daniel/programs/Pegmatite/parser.cc:38:0: /home/daniel/programs/Pegmatite/parser.hh:486:2: error: candidates are: pegmatite::Rule::Rule(pegmatite::ExprPtr) /home/daniel/programs/Pegmatite/parser.hh:481:2: error: pegmatite::Rule::Rule(const pegmatite::Rule&&) /home/daniel/programs/Pegmatite/parser.hh:476:2: error: pegmatite::Rule::Rule(const pegmatite::Rule&) /home/daniel/programs/Pegmatite/parser.hh:472:2: error: pegmatite::Rule::Rule(pegmatite::CharacterExprPtr) The error says that the constructor pegmatite::Rule::Rule(pegmative::ExprPtr) has no match in the class pegmatite::Rule, and yet the very first candidate it lists is just that.
[Bug c++/61753] [4.7.2 regression] prototype for function does not match any in class error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61753 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-07-08 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- Please provide the information requested at http://gcc.gnu.org/bugs
[Bug c++/61751] Empty brace-initializer causes double destruction of unique_ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61751 --- Comment #1 from Jonathan Wakely --- Looks like a dup of PR 60367
[Bug c++/60367] Default argument object is not getting constructed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60367 Jonathan Wakely changed: What|Removed |Added CC||perso...@e-maxx.ru --- Comment #12 from Jonathan Wakely --- *** Bug 61751 has been marked as a duplicate of this bug. ***
[Bug c++/61751] Empty brace-initializer causes double destruction of unique_ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61751 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Jonathan Wakely --- Dup, should be fixed in 4.8.3 *** This bug has been marked as a duplicate of bug 60367 ***
[Bug c++/61753] [4.7.2 regression] prototype for function does not match any in class error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61753
Jonathan Wakely changed:
What|Removed |Added
Keywords||diagnostic
Status|WAITING |NEW
--- Comment #2 from Jonathan Wakely ---
This is not valid syntax for a constructor:
const Rule::Rule(const ExprPtr e) :
expr(e)
{
}
The first const is ill-formed (and the second one is pointless, but harmless)
The error message could be better though, reduced:
class Rule {
Rule(int e);
};
const Rule::Rule(int e) { }
test.cc:5:7: error: prototype for ‘Rule::Rule(int)’ does not match any in class
‘Rule’
const Rule::Rule(int e) { }
^
test.cc:1:7: error: candidates are: Rule::Rule(const Rule&)
class Rule {
^
test.cc:2:3: error: Rule::Rule(int)
Rule(int e);
^
EDG has a better diagnostic:
"test.cc", line 5: error: return type may not be specified on a constructor
[Bug go/61746] A line starting with /*// causes an error even if the /* is closed on the next line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61746 David Edelsohn changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-07-08 CC||ian at airs dot com Ever confirmed|0 |1 --- Comment #1 from David Edelsohn --- Confirmed.
[Bug c++/61753] poor diagnostic for constructor definition that starts with 'const'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61753 Jonathan Wakely changed: What|Removed |Added Summary|[4.7.2 regression] |poor diagnostic for |prototype for function does |constructor definition that |not match any in class |starts with 'const' |error | --- Comment #3 from Jonathan Wakely --- I don't know how you got that to compile with GCC 4.6.3 as every version I have rejects it - not a regression. (The upstream code on github has been fixed now btw)
[Bug c++/61754] New: [C++1y] [[deprecated]] attribute warns annoyingly compared to __attribute__((deprecated))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61754
Bug ID: 61754
Summary: [C++1y] [[deprecated]] attribute warns annoyingly
compared to __attribute__((deprecated))
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.kruegler at googlemail dot com
The following code, compiled with 4.10.0 20140707 (experimental) using the
compiler settings:
-Wall -Wextra -std=c++1y -pedantic
//-
struct __attribute__((deprecated)) Old1 {};
Old1 old1 __attribute__((deprecated));
struct [[deprecated]] Old2 {};
Old2 old2 [[deprecated]]; // ##
int main() {}
//-
produces a warning on the line marked with ##:
"warning: 'Old2' is deprecated (declared at prog.cc:5)
[-Wdeprecated-declarations]
Old2 old2 [[deprecated]];
^"
Note that the corresponding example using type Old1 does not so. Is the
difference in behaviour intended? I'm pretty sure that either variant is
conforming, but this has the effect that it makes [[deprecated]] much less
attractive in real-world code bases.
Please let me know whether the difference is due to your reading of the
standard, in this case I would like to submit a core language issue to make the
wording clearer for such situations.
[Bug c++/61755] New: Reference to function is parsed as const reference to function in debug info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61755
Bug ID: 61755
Summary: Reference to function is parsed as const reference to
function in debug info
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sijun.liu at oracle dot com
-- t.cc
int foo(){
return 2;
}
int main(){
int (&g)() = foo;
return 1;
}
Use g++ version 4.8.2 on intel Solaris 10, and Solaris studio debugger dbx, it
says the type of g is int (&const g)(), while it should be int (& g)().
bash-3.2$ g++ -g -std=c++11 t.cc
bash-3.2$ dbx a.out
For information about new features see `help changes'
To remove this message, put `dbxenv suppress_startup_message 8.0' in your
.dbxrcReading a.out
Reading ld.so.1
Reading libstdc++.so.6.0.18
Reading libm.so.2
Reading libgcc_s.so.1
Reading libc.so.1
(dbx) stop at 7
(2) stop at "t.cc":7
(dbx) run
Running: a.out
(process id 6747)
stopped in main at line 7 in file "t.cc"
7 return 1;
(dbx) whatis g
int (&const g)(); <= ERROR!!
(dbx) quit
The following is the debug info using Oracle dwarf dump, where the type of
function g is <0x00f2>, and the type at <0x00f2> is DW_TAG_const_type,
which is wrong.
--
bash-3.2$ dwarfdump a.out
.debug_info:
COMPILE_UNIT:
< 0><0x000b> DW_TAG_compile_unit
DW_AT_producer "GNU C++ 4.8.2 -mtune=generic
-m arch=pentium4 -g -std=c++11"
DW_AT_language DW_LANG_C_plus_plus
DW_AT_name "t.cc"
DW_AT_comp_dir "/workspace"
DW_AT_low_pc0x08050c3e
DW_AT_high_pc 0x08050c5c
DW_AT_stmt_list 0x
LOCAL_SYMBOLS:
< 1><0x0090>DW_TAG_subprogram
DW_AT_external yes(1)
DW_AT_name "foo"
DW_AT_decl_file 0x0001 /workspace/t.cc
DW_AT_decl_line 0x0001
DW_AT_MIPS_linkage_name "_Z3foov"
DW_AT_type <0x00b1>
DW_AT_low_pc0x08050c3e
DW_AT_high_pc 0x08050c48
DW_AT_frame_base
[ 0]DW_OP_breg4+4
[ 1]DW_OP_breg4+8
[ 2]DW_OP_breg5+8
[ 3]DW_OP_breg4+4
DW_AT_GNU_all_call_sitesyes(1)
< 1><0x00b1>DW_TAG_base_type
DW_AT_byte_size 0x0004
DW_AT_encoding DW_ATE_signed
DW_AT_name "int"
< 1><0x00b8>DW_TAG_subprogram
DW_AT_external yes(1)
DW_AT_name "main"
DW_AT_decl_file 0x0001 /workspace/t.cc
DW_AT_decl_line 0x0005
DW_AT_type <0x00b1>
DW_AT_low_pc0x08050c48
DW_AT_high_pc 0x08050c5c
DW_AT_frame_base
[ 0]DW_OP_breg4+4
[ 1]DW_OP_breg4+8
[ 2]DW_OP_breg5+8
[ 3]DW_OP_breg4+4
DW_AT_GNU_all_call_sitesyes(1)
DW_AT_sibling <0x00ed>
< 2><0x00d6> DW_TAG_lexical_block
DW_AT_low_pc0x08050c4e
DW_AT_high_pc 0x08050c5a
< 3><0x00df>DW_TAG_variable
DW_AT_name "g"
DW_AT_decl_file 0x0001
/workspace/t.cc
DW_AT_decl_line 0x0006
DW_AT_type <0x00f2>
DW_AT_location DW_OP_fbreg -12
< 1><0x00ed>DW_TAG_subroutine_type
DW_AT_type <0x00b1>
< 1><0x00f2>DW_TAG_const_type
DW_AT_type <0x00f7>
< 1><0x00f7>DW_TAG_reference_type
DW_AT_byte_size 0x0004
DW_AT_type <0x00ed>
File table: 1 entries
[ 1] /workspace/t.cc
(below is omitted...)
[Bug fortran/61459] [4.8/4.9/4.10 Regression] segfault when assigning to allocatable function result from matmul result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61459 --- Comment #8 from Paul Thomas --- Author: pault Date: Tue Jul 8 19:51:04 2014 New Revision: 212369 URL: https://gcc.gnu.org/viewcvs?rev=212369&root=gcc&view=rev Log: 2014-07-08 Paul Thomas PR fortran/61459 PR fortran/58883 * trans-expr.c (fcncall_realloc_result): Use the natural type for the address expression of 'res_desc'. 2014-07-08 Paul Thomas PR fortran/61459 PR fortran/58883 * gfortran.dg/allocatable_function_8.f90 : New test Added: branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/allocatable_function_8.f90 Modified: branches/gcc-4_8-branch/gcc/fortran/ChangeLog branches/gcc-4_8-branch/gcc/fortran/trans-expr.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug fortran/58883] Wrong code with realloc on assignment with assigning RESHAPE() to the function result variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58883 --- Comment #5 from Paul Thomas --- Author: pault Date: Tue Jul 8 19:51:04 2014 New Revision: 212369 URL: https://gcc.gnu.org/viewcvs?rev=212369&root=gcc&view=rev Log: 2014-07-08 Paul Thomas PR fortran/61459 PR fortran/58883 * trans-expr.c (fcncall_realloc_result): Use the natural type for the address expression of 'res_desc'. 2014-07-08 Paul Thomas PR fortran/61459 PR fortran/58883 * gfortran.dg/allocatable_function_8.f90 : New test Added: branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/allocatable_function_8.f90 Modified: branches/gcc-4_8-branch/gcc/fortran/ChangeLog branches/gcc-4_8-branch/gcc/fortran/trans-expr.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug fortran/61459] [4.8/4.9/4.10 Regression] segfault when assigning to allocatable function result from matmul result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61459 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Paul Thomas --- Fixed on 4.8, 4.9 and trunk. Thanks for the report Paul
[Bug fortran/58883] Wrong code with realloc on assignment with assigning RESHAPE() to the function result variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58883 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED CC||pault at gcc dot gnu.org Resolution|--- |FIXED --- Comment #6 from Paul Thomas --- Fixed on 4.8, 4.9 and trunk. Thanks for the report Paul
[Bug go/61746] A line starting with /*// causes an error even if the /* is closed on the next line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61746 --- Comment #2 from ian at gcc dot gnu.org --- Author: ian Date: Tue Jul 8 20:49:38 2014 New Revision: 212370 URL: https://gcc.gnu.org/viewcvs?rev=212370&root=gcc&view=rev Log: PR go/61746 compiler: Fix C-style comment parsing. The compiler was incorrectly seeing /*/ as a complete C-style comment. Modified: trunk/gcc/go/gofrontend/lex.cc
[Bug go/61746] A line starting with /*// causes an error even if the /* is closed on the next line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61746 --- Comment #3 from ian at gcc dot gnu.org --- Author: ian Date: Tue Jul 8 20:49:59 2014 New Revision: 212371 URL: https://gcc.gnu.org/viewcvs?rev=212371&root=gcc&view=rev Log: PR go/61746 compiler: Fix C-style comment parsing. The compiler was incorrectly seeing /*/ as a complete C-style comment. Modified: branches/gcc-4_9-branch/gcc/go/gofrontend/lex.cc
[Bug go/61746] A line starting with /*// causes an error even if the /* is closed on the next line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61746 Ian Lance Taylor changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Ian Lance Taylor --- Fixed. Thanks for the report.
[Bug go/61308] gccgo: ICE in Expression::check_bounds [GoSmith]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61308 --- Comment #1 from ian at gcc dot gnu.org --- Author: ian Date: Tue Jul 8 21:28:17 2014 New Revision: 212372 URL: https://gcc.gnu.org/viewcvs?rev=212372&root=gcc&view=rev Log: PR go/61308 compiler: Convert array start index before bounds checking. Modified: trunk/gcc/go/gofrontend/expressions.cc
[Bug go/61308] gccgo: ICE in Expression::check_bounds [GoSmith]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61308 --- Comment #2 from Dmitry Vyukov --- It would be great to accompany these fixes with regression tests. We have significant amount of Go code in std lib and tests, but still we discover new code patterns. Any new compiler functionality (like race detector or coverage analysis) would benefit from extensive tests. Does gccgo use tests from the main Go repo? The main repo looks like the best place for them.
[Bug c++/61382] parameter pack expansion unexpected order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61382 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|4.10.0 |4.9.1 --- Comment #16 from Jason Merrill --- Yes.
[Bug c++/61753] poor diagnostic for constructor definition that starts with 'const'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61753 --- Comment #4 from shapero at uw dot edu --- (In reply to Jonathan Wakely from comment #3) > I don't know how you got that to compile with GCC 4.6.3 as every version I > have rejects it - not a regression. > > (The upstream code on github has been fixed now btw) Thanks for getting to this so quickly! My C++ is spotty, so I didn't recognize that the syntax was invalid. I figured the fact that it compiled on clang meant that it was a problem with GCC and not the code itself.
[Bug target/61599] [x86_64] With -mcmodel=medium, extern global arrays without size are not treated conservatively.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61599 --- Comment #1 from tmsriram at gcc dot gnu.org --- Author: tmsriram Date: Wed Jul 9 00:50:25 2014 New Revision: 212380 URL: https://gcc.gnu.org/viewcvs?rev=212380&root=gcc&view=rev Log: 2014-07-08 Sriraman Tallam PR target/61599 * config/i386/i386.c (ix86_in_large_data_p): Check for size less than zero. PR target/61599 * gcc.target/i386/pr61599-1.c: New test. * gcc.target/i386/pr61599-2.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr61599-1.c trunk/gcc/testsuite/gcc.target/i386/pr61599-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog
[Bug bootstrap/61679] build fails with G++ 4.5.1 - prototype for hash_table does not match any in class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61679 --- Comment #8 from tbsaunde at gcc dot gnu.org --- Author: tbsaunde Date: Wed Jul 9 03:07:09 2014 New Revision: 212384 URL: https://gcc.gnu.org/viewcvs?rev=212384&root=gcc&view=rev Log: playcate old gcc gcc/ PR bootstrap/61679 * hash-table.h: use hash_table::value_type instead of Descriptor::value_type in the return types of several methods. Modified: trunk/gcc/ChangeLog trunk/gcc/hash-table.h
[Bug bootstrap/61679] build fails with G++ 4.5.1 - prototype for hash_table does not match any in class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61679 tbsaunde at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||tbsaunde at gcc dot gnu.org Resolution|--- |FIXED --- Comment #9 from tbsaunde at gcc dot gnu.org --- fixed
[Bug target/61544] ICE due to thumb1_reorg function mishandles label type insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61544 --- Comment #3 from zqchen at gcc dot gnu.org --- Author: zqchen Date: Wed Jul 9 05:27:16 2014 New Revision: 212385 URL: https://gcc.gnu.org/viewcvs?rev=212385&root=gcc&view=rev Log: Backport r211775 from trunk. 2014-06-18 Terry Guo PR target/61544 * config/arm/arm.c (thumb1_reorg): Move to next basic block if we reach the head. Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config/arm/arm.c
[Bug ipa/61602] [4.10 Regression] ICE in lto1 on x86_64-linux-gnu in ipa_single_use, at ipa.c:1257
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61602
--- Comment #1 from Zhendong Su ---
To help diagnose the issue, here is another test case that triggers the same
ICE without using LTO.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.10.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 4.10.0 20140708 (experimental) [trunk revision 212357] (GCC)
$
$ gcc-trunk -O1 -c small.c
small.c:9:1: internal compiler error: in ipa_single_use, at ipa.c:1255
}
^
0x81fc21 ipa_single_use
../../gcc-trunk/gcc/ipa.c:1255
0x81fc21 execute
../../gcc-trunk/gcc/ipa.c:1303
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.
$
---
static int a, *b = &a, **c = &b, ***d = &c;
int
main ()
{
d = 0;
b = 0;
return 0;
}
[Bug sanitizer/55561] TSAN: provide a TSAN instrumented libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561 --- Comment #50 from Roland Schulz --- I must say I don't know how the internals work. But I assume that reductions are implemented in libgomp (I know they are in iomp). Thus for any code which uses OpenMP reduce statements, libgomp would touch user data.
