[Bug tree-optimization/64716] Missed vectorization in a hot code of SPEC2000 ammp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64716 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-01-21 CC||jakub at gcc dot gnu.org Blocks|53947 | Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- This is about SLP vectorization, and for some reason we treat the whole bb as one item to slp vectorize, rather than trying to vectorize just individual statements where beneficial. So we end up with: pr64716.c:2633:12: note: Build SLP failed: unrolling required in basic block SLP pr64716.c:2633:12: note: Failed to SLP the basic block. pr64716.c:2633:12: note: not vectorized: failed to find SLP opportunities in basic block. where 2633 in my copy is that r0 = 1./(*vector)[j+3]; line - group_size is 6 on that stmt and nunits is 4 (for AVX2) or 2 (for 128-bit vectors).
[Bug ipa/64710] [5 Regression] lto1: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64710 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #2 from Jan Hubicka hubicka at gcc dot gnu.org --- Should be fixed now.
[Bug fortran/57023] [4.8/4.9/5 Regression] Not packing arrays with changing variable used for size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57023 --- Comment #7 from Thomas Koenig tkoenig at gcc dot gnu.org --- Author: tkoenig Date: Wed Jan 21 19:40:54 2015 New Revision: 219963 URL: https://gcc.gnu.org/viewcvs?rev=219963root=gccview=rev Log: 2015-01-21 Thomas Koenig tkoe...@netcologne.de PR fortran/57023 * dependency.c (callback_dummy_intent_not_int): New function. (dummy_intent_not_in): New function. (gfc_full_array_ref_p): Use dummy_intent_not_in. 2015-01-21 Thomas Koenig tkoe...@netcologne.de PR fortran/57023 * gfortran.dg/internal_pack_15.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/internal_pack_15.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dependency.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/64713] Missed ccmp optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64713 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- I have this too even before the recent patch.
[Bug rtl-optimization/64081] [5 Regression] r217827 prevents RTL loop unroll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64081 --- Comment #8 from Igor Zamyatin izamyatin at gmail dot com --- Created attachment 34524 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34524action=edit patch to try AIX bootstrap
[Bug rtl-optimization/64081] [5 Regression] r217827 prevents RTL loop unroll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64081 --- Comment #9 from Igor Zamyatin izamyatin at gmail dot com --- David, could you please try attached patch?
[Bug c++/60211] [4.9/5 Regression] ICE with #pragma GCC ivdep and for-loop on global scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60211 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||paolo.carlini at oracle dot com --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- This is strictly speaking a regression that would be easy to fix in cp_parser_pragma. I wonder, however, if we want to handle the pragma as, eg, PRAGMA_CILK_SIMD, thus explicitly reject the pragma itself when context == pragma_external, or we want to eseentially ignore it in that case, thus do not call cp_parser_iteration_statement and return. Or something else?!?
[Bug c/53119] -Wmissing-braces wrongly warns about universal zero initializer {0}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53119 --- Comment #20 from Marek Polacek mpolacek at gcc dot gnu.org --- Sorry, the patch hasn't been applied to 4.9 nor 4.8 branch yet, and I don't think it should be backported as-is, because just today I found out that the patch contains a bug; see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64709
[Bug tree-optimization/64718] Bad 16-bit bswap replacement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64718
--- Comment #2 from H.J. Lu hjl.tools at gmail dot com ---
A run-time testcase:
[hjl@gnu-mic-2 gcc-regression]$ cat pr64718.c
int
__attribute__ ((noinline, noclone))
swap(int x)
{
return (unsigned short)((unsigned short)x 8 | (unsigned short)x 8);
}
int a = 0x1234;
int
main()
{
int b = 0x1234;
if (swap (a) != 0x3412)
__builtin_abort ();
if (swap (b) != 0x3412)
__builtin_abort ();
return 0;
}
[hjl@gnu-mic-2 gcc-regression]$
[Bug tree-optimization/64716] Missed vectorization in a hot code of SPEC2000 ammp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64716 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Say on: a2-qyz -= (k2+ka2+kb2)*yt*zt; a1-qyz -= (k2+ka2+kb2)*yt*zt; a2-qzz -= k2*(zt2 - 1./3) + ka2*(zt2 - 1./8)+kb2*(zt2-1./14) ; a1-qzz -= k2*(zt2 - 1./3) + ka2*(zt2 - 1./8)+kb2*(zt2-1./14) ; it seems that temp1 = (k2+ka2+kb2)*yt*zt and temp2 = k2*(zt2 - 1./3) + ka2*(zt2 - 1./8)+kb2*(zt2-1./14) are computed in scalar code, then combined into a V2DFmode vector and the a1-qyz -= temp1; a1-qzz -= temp2; a2-qyz -= temp1; a2-qyz -= temp2; is already performed using vectorized code. We'd need to carefully analyze the costs if putting the scalars into the vector is beneficial, but supposedly it is if the score shows that. Or the: xt = (*vector)[j] * r0; yt = (*vector)[j + 1] * r0; zt = (*vector)[j + 2] * r0; a2-dpx -= k1 * xt; a1-dpx += k1 * xt; a2-dpy -= k1 * yt; a1-dpy += k1 * yt; a2-dpz -= k1 * zt; a1-dpz += k1 * zt; part shows that even though this would be ideally vectorized with V3DFmode vectors, it can be vectorized using V2DFmode + scalar for the *z* elements. Or say for a group of 6 we could consider vectorizing with 4 units vector and 2 units vector for the remainder (perhaps split appart the SLP instance for that, analyze each individually?).
[Bug ipa/64710] [5 Regression] lto1: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64710 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com --- It was caused by r219910.
[Bug tree-optimization/64718] Bad 16-bit bswap replacement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64718 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-01-21 Target Milestone|--- |5.0 Ever confirmed|0 |1
[Bug tree-optimization/64718] Bad 16-bit bswap replacement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64718 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Target|i686-pc-linux-gnu |x86 Priority|P3 |P1 --- Comment #3 from H.J. Lu hjl.tools at gmail dot com --- Also happens on x86-64.
[Bug c/53119] -Wmissing-braces wrongly warns about universal zero initializer {0}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53119 roger pack rogerdpack at gmail dot com changed: What|Removed |Added CC||rogerdpack at gmail dot com --- Comment #19 from roger pack rogerdpack at gmail dot com --- Has this been applied yet? (If yes, in which version of gcc?) Seems to be a popular problem, if it's this: http://stackoverflow.com/questions/13746033/how-to-repair-warning-missing-braces-around-initializer
[Bug libstdc++/64695] [5 Regression] FAIL: libstdc++-prettyprinters/cxx11.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64695 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from H.J. Lu hjl.tools at gmail dot com --- Fixed by r219953.
[Bug ipa/63576] [5 Regression] ICE : in ipa_merge_profiles, at ipa-utils.c:540 during Firefox LTO/PGO build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63576 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #14 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Fixed. Thanks.
[Bug gcov-profile/64123] [5 Regression] Instrumented Firefox segfaults on start
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64123 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #2 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Works for me now.
[Bug ipa/64710] [5 Regression] lto1: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64710 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||trippels at gcc dot gnu.org Resolution|--- |FIXED --- Comment #3 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/64718] Bad 16-bit bswap replacement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64718 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||thomas.preudhomme at arm dot com --- Comment #1 from H.J. Lu hjl.tools at gmail dot com --- It is caused by r219256.
[Bug c/64714] [5.0 regression] __builtin_object_size (..., 1) fails to locate subobject
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64714 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andreas Schwab sch...@linux-m68k.org --- . *** This bug has been marked as a duplicate of bug 64715 ***
[Bug c/64714] New: [5.0 regression] __builtin_object_size (..., 1) fails to locate subobject
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64714 Bug ID: 64714 Summary: [5.0 regression] __builtin_object_size (..., 1) fails to locate subobject Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: sch...@linux-m68k.org Created attachment 34520 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34520action=edit Testcase From the glibc testsuite. $ gcc-4.9 -O2 fortify.i ./a.out echo $? *** buffer overflow detected ***: ./a.out terminated [...] $ gcc-5 -O2 fortify.i ./a.out echo $? 0
[Bug c/64715] New: [5.0 regression] __builtin_object_size (..., 1) fails to locate subobject
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64715 Bug ID: 64715 Summary: [5.0 regression] __builtin_object_size (..., 1) fails to locate subobject Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: sch...@linux-m68k.org Created attachment 34519 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34519action=edit Testcase From the glibc testsuite. $ gcc-4.9 -O2 fortify.i ./a.out echo $? *** buffer overflow detected ***: ./a.out terminated [...] $ gcc-5 -O2 fortify.i ./a.out echo $? 0
[Bug ipa/64710] [5 Regression] lto1: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64710 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1
[Bug tree-optimization/64715] [5.0 regression] __builtin_object_size (..., 1) fails to locate subobject
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64715
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2015-01-21
Component|c |tree-optimization
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #2 from Richard Biener rguenth at gcc dot gnu.org ---
Well. In a.buf1 + (0 + 4) a.buf1 decays to a (char *) pointer and + 4 just
increments it. You can hardly restrict that pointer arithmetic to a sub-object
this way.
Btw, this is likely caused by
2014-09-05 Richard Biener rguent...@suse.de
PR middle-end/63148
* fold-const.c (try_move_mult_to_index): Remove.
(fold_binary_loc): Do not call it.
* tree-data-ref.c (dr_analyze_indices): Strip conversions
from the base object again.
The docs say
@var{type} is an integer constant from 0 to 3. If the least significant
bit is clear, objects are whole variables, if it is set, a closest
surrounding subobject is considered the object a pointer points to.
but I believe we may not actually compute that subobject (or rather the
issue, in some cases, is that the wording is ambiguous for nested
structs where both a.b and a.b.c are at the same address). For the present
testcase we can unambiguously compute the closest surrounding subobject.
Let me see if I can fix this.
[Bug target/64669] [5 Regression] aarch64-linux profiledbootstrap failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64669 Richard Henderson rth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #15 from Richard Henderson rth at gcc dot gnu.org --- Fixed.
[Bug target/64368] [5 Regression] Several libstdc++ test failures on non-linux platforms after r218964.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64368 --- Comment #16 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #15) Note that the last failures belong to another PR: they come from a later commit and I see several of them on darwin (see FX tests). I have no inclination to open a PR for them as long as the PRs I open are rotting for ever. This PR is a month old today, hardly forever. I'm going to fix it.
[Bug tree-optimization/64716] New: Missed vectorization in a hot code of SPEC2000 ammp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64716 Bug ID: 64716 Summary: Missed vectorization in a hot code of SPEC2000 ammp Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: vmakarov at gcc dot gnu.org Created attachment 34521 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34521action=edit Preprocessed rectmm.c from SPEC2000 amp GCC does not vectorize one of the hotest code in SPECFP2000 ammp (function mm_fv_update_nonbon in file rectmm.c) on x86-64 when -Ofast -march=core-avx2 -ffast-math -fno-schedule-insns2 is used. The preprocessed rectmm.i is in the attachment. The source code in the consideration is r0 = 1./(*vector)[j+3]; r = r0*r0; r = r*r*r; xt = a1-q*a2-q*dielectric*r0; yt = a1-a*a2-a*r; zt = a1-b*a2-b*r*r; k = xt - yt + zt; xt = xt*r0; yt = yt*r0; zt = zt*r0; k1 = xt - yt*6. + zt*12.; xt = xt*r0; yt = yt*r0; zt = zt*r0; k2 = xt*3.; ka2 = - yt*6.*8.; kb2 = zt*12.*14; k1 = -k1; xt = (*vector)[j]*r0 ; yt = (*vector)[j+1]*r0 ; zt = (*vector)[j+2] *r0; a1-VP += k; a2-dpx -= k1*xt; a1-dpx += k1*xt; a2-dpy -= k1*yt; a1-dpy += k1*yt; a2-dpz -= k1*zt; a1-dpz += k1*zt; xt2 = xt*xt; yt2 = yt*yt; zt2 = zt*zt; a2-qxx -= k2*(xt2 - 1./3) + ka2*(xt2 - 1./8)+kb2*(xt2-1./14) ; a1-qxx -= k2*(xt2 - 1./3) + ka2*(xt2 - 1./8)+kb2*(xt2-1./14) ; a2-qxy -= (k2+ka2+kb2)*yt*xt; a1-qxy -= (k2+ka2+kb2)*yt*xt; a2-qxz -= (k2+ka2+kb2)*zt*xt; a1-qxz -= (k2+ka2+kb2)*zt*xt; a2-qyy -= k2*(yt2 - 1./3) + ka2*(yt2 - 1./8)+kb2*(yt2-1./14) ; a1-qyy -= k2*(yt2 - 1./3) + ka2*(yt2 - 1./8)+kb2*(yt2-1./14) ; a2-qyz -= (k2+ka2+kb2)*yt*zt; a1-qyz -= (k2+ka2+kb2)*yt*zt; a2-qzz -= k2*(zt2 - 1./3) + ka2*(zt2 - 1./8)+kb2*(zt2-1./14) ; a1-qzz -= k2*(zt2 - 1./3) + ka2*(zt2 - 1./8)+kb2*(zt2-1./14) ; GCC on the trunk generates 118 insns .L85: .cfi_restore_state vmovsd .LC12(%rip), %xmm7 vdivsd %xmm0, %xmm7, %xmm6 vmulsd %xmm6, %xmm6, %xmm0 vmulsd %xmm0, %xmm0, %xmm10 vmulsd %xmm10, %xmm0, %xmm0 vmovsd 56(%rbx), %xmm12 vmulsd 56(%rdi), %xmm12, %xmm12 vmulsd %xmm4, %xmm12, %xmm12 vmulsd %xmm12, %xmm6, %xmm12 vmovsd 64(%rbx), %xmm10 vmulsd 64(%rdi), %xmm10, %xmm10 vmulsd %xmm10, %xmm0, %xmm11 vmovsd 72(%rbx), %xmm10 vmulsd 72(%rdi), %xmm10, %xmm10 vmulsd %xmm10, %xmm0, %xmm10 vmulsd %xmm0, %xmm10, %xmm10 vmulsd %xmm12, %xmm6, %xmm0 vmulsd %xmm11, %xmm6, %xmm1 vmulsd %xmm10, %xmm6, %xmm2 vmulsd .LC22(%rip), %xmm2, %xmm8 vfnmadd231sd%xmm9, %xmm1, %xmm8 vaddsd %xmm8, %xmm0, %xmm8 vmulsd .LC21(%rip), %xmm6, %xmm5 vmulsd %xmm0, %xmm5, %xmm5 vmulsd %xmm1, %xmm6, %xmm0 vxorpd %xmm15, %xmm0, %xmm0 vmulsd .LC24(%rip), %xmm0, %xmm3 vmulsd .LC25(%rip), %xmm6, %xmm7 vmulsd %xmm2, %xmm7, %xmm7 vxorpd %xmm15, %xmm8, %xmm8 movslq %esi, %rax vmulsd (%r12,%rax,8), %xmm6, %xmm2 leal1(%rsi), %eax cltq vmulsd (%r12,%rax,8), %xmm6, %xmm1 leal2(%rsi), %eax cltq vmulsd (%r12,%rax,8), %xmm6, %xmm0 vaddsd 208(%rbx), %xmm12, %xmm12 vaddsd %xmm12, %xmm10, %xmm10 vsubsd %xmm11, %xmm10, %xmm10 vmovsd %xmm10, 208(%rbx) vmovapd %xmm8, %xmm6 vfnmadd213sd240(%rdi), %xmm2, %xmm6 vmovsd %xmm6, 240(%rdi) vmovapd %xmm8, %xmm6 vfmadd213sd 240(%rbx), %xmm2, %xmm6 vmovsd %xmm6, 240(%rbx) vmovapd %xmm8, %xmm6 vfnmadd213sd248(%rdi), %xmm1, %xmm6 vmovsd %xmm6, 248(%rdi) vmovapd %xmm8, %xmm6 vfmadd213sd 248(%rbx), %xmm1, %xmm6 vmovsd %xmm6, 248(%rbx) vmovapd %xmm8, %xmm6 vfnmadd213sd256(%rdi), %xmm0, %xmm6 vmovsd %xmm6, 256(%rdi) vfmadd213sd 256(%rbx), %xmm0, %xmm8 vmovsd %xmm8, 256(%rbx) vmovsd .LC26(%rip), %xmm8 vmovapd %xmm2, %xmm11 vfnmadd132sd%xmm2, %xmm8, %xmm11 vmulsd %xmm11, %xmm5, %xmm11 vmovsd .LC27(%rip), %xmm6 vmovapd %xmm2, %xmm10 vfnmadd132sd%xmm2, %xmm6, %xmm10 vmovapd %xmm10, %xmm12 vfmadd132sd %xmm7, %xmm11, %xmm12 vmovsd .LC28(%rip), %xmm10 vmovapd %xmm2, %xmm11 vfnmadd132sd%xmm2, %xmm10, %xmm11 vfmadd132sd %xmm3, %xmm12, %xmm11 vaddsd 264(%rdi), %xmm11, %xmm12 vmovsd %xmm12, 264(%rdi) vaddsd 264(%rbx), %xmm11, %xmm11 vmovsd %xmm11, 264(%rbx) vaddsd %xmm7, %xmm5, %xmm12 vaddsd %xmm12, %xmm3, %xmm12 vmulsd %xmm12, %xmm1, %xmm11 vmovapd %xmm2, %xmm13 vfnmadd213sd
[Bug tree-optimization/64716] Missed vectorization in a hot code of SPEC2000 ammp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64716 --- Comment #1 from Vladimir Makarov vmakarov at gcc dot gnu.org --- Created attachment 34523 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34523action=edit rectmm.c code annotated by gcov to see other hot code parts
[Bug rtl-optimization/62078] [5 Regression] ICE: verify_flow_info failed: missing REG_EH_REGION note at the end of bb 2 with -fdelete-dead-exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62078 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||law at gcc dot gnu.org --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- Then it is weird to treat is as regression, because r188666 didn't support -Og. In any case, either RTL DSE shouldn't remove stores with REG_EH_REGION note on it, or if it does remove them we need to clean up EH.
[Bug rtl-optimization/62078] [5 Regression] ICE: verify_flow_info failed: missing REG_EH_REGION note at the end of bb 2 with -fdelete-dead-exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62078 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 34518 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34518action=edit gcc5-pr62078.patch Untested fix. This is the way postreload-cse solves this issue.
[Bug target/64669] [5 Regression] aarch64-linux profiledbootstrap failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64669 --- Comment #14 from Richard Henderson rth at gcc dot gnu.org --- Author: rth Date: Wed Jan 21 15:47:49 2015 New Revision: 219951 URL: https://gcc.gnu.org/viewcvs?rev=219951root=gccview=rev Log: PR target/64669 * ccmp.c (used_in_cond_stmt_p): Remove. (expand_ccmp_expr): Don't use it. Added: trunk/gcc/testsuite/g++.dg/torture/pr64669.C Modified: trunk/gcc/ChangeLog trunk/gcc/ccmp.c
[Bug rtl-optimization/64713] New: Missed ccmp optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64713 Bug ID: 64713 Summary: Missed ccmp optimization Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: rth at gcc dot gnu.org In a small percentage of ccmp uses within the stage3 cc1plus I see 56b638: f100045fcmp x2, #0x1 56b63c: fa421320ccmpx25, x2, #0x0, ne 56b640: 1a9f17e3csetw3, eq 56b644: 350001c3cbnzw3, ... This is a reminder to dig those out as test cases and see if we can eliminate the cset.
[Bug sanitizer/64717] New: -fsanitize=vptr leads to warning: ‘anonymous’ may be used uninitialized in this function [-Wmaybe-uninitialized]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64717 Bug ID: 64717 Summary: -fsanitize=vptr leads to warning: ‘anonymous’ may be used uninitialized in this function [-Wmaybe-uninitialized] Product: gcc Version: 5.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org Created attachment 34522 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34522action=edit Testcase (test.ii), compile with: -Wmaybe-uninitialized -fsanitize=vptr Using -fsanitize=vptr on a mid-size C++ code leads to a few hundreds of the following warnings: warning: ‘anonymous’ may be used uninitialized in this function [-Wmaybe-uninitialized] The test case shows with g++ -S -Wmaybe-uninitialized -fsanitize=vptr test.ii also that message.
[Bug tree-optimization/64718] New: Bad 16-bit bswap replacement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64718
Bug ID: 64718
Summary: Bad 16-bit bswap replacement
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: a...@q-fu.com
Target: i686-pc-linux-gnu
This code is reduced from htons((int)port) on FreeBSD.
The expression gets replaced with a rotation in a 32-bit register
instead of a 16-bit register, so the upper byte is lost.
int swap(int x) {
return (unsigned short)((unsigned short)x 8 | (unsigned short)x 8);
}
gcc -O2 -S swap.c
swap:
movl4(%esp), %eax
roll$8, %eax # should be %ax
movzwl %ax, %eax
ret
Complete program:
#include stdio.h
int swap(int x) {
return (unsigned short)((unsigned short)x 8 | (unsigned short)x 8);
}
int a = 0x1234;
int main() {
int b = 0x1234;
printf(%x - %x\n, a, swap(a));
printf(%x - %x\n, b, swap(b));
}
gcc -O2 swap.c ./a.out
1234 - 3400
1234 - 3412
[Bug c/64715] [5.0 regression] __builtin_object_size (..., 1) fails to locate subobject
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64715 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Target Milestone|--- |5.0
[Bug libgcc/64677] incorrect result with complex division?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64677 --- Comment #11 from Sanjay Patel spatel at rotateright dot com --- (In reply to Mikhail Maltsev from comment #10) C++11 supports constexpr (and std::complex has constexpr constructor). Ah, that makes sense. Yes, we're only generating the answer using MPFR with c++11 and optimization. So I think this comes down to an implementation difference between libgcc and MPFR. By the way, according to C++ standard, precision of floating point numbers is implementation-defined. Hmmm...so we still don't know which answer is correct or if both answers are acceptable?
[Bug ada/64712] [5 Regression] FAIL: gnat.dg/unchecked_convert1.adb execution test (x86_64/-m32)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64712 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.0 Summary|FAIL: |[5 Regression] FAIL: |gnat.dg/unchecked_convert1. |gnat.dg/unchecked_convert1. |adb execution test |adb execution test |(x86_64/-m32) |(x86_64/-m32)
[Bug ada/64712] FAIL: gnat.dg/unchecked_convert1.adb execution test (x86_64/-m32)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64712 --- Comment #1 from vries at gcc dot gnu.org --- $ build/gcc/xgcc -v Using built-in specs. COLLECT_GCC=build/gcc/xgcc Target: x86_64-unknown-linux-gnu Configured with: src/configure --prefix=install --with-cloog=infra --with-ppl=infra --with-gmp=infra --with-mpfr=infra --with-mpc=infra --with-isl=infra --disable-bootstrap --enable-checking=yes,rtl --enable-languages=c,fortran,ada,java,objc,c++,go,obj-c++ Thread model: posix gcc version 5.0.0 20150121 (experimental) (GCC) Revision: r219928
[Bug c/64715] [5.0 regression] __builtin_object_size (..., 1) fails to locate subobject
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64715 --- Comment #1 from Andreas Schwab sch...@linux-m68k.org --- *** Bug 64714 has been marked as a duplicate of this bug. ***
[Bug libgomp/64719] New: omp_get_num_procs should not account for cpu affinity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64719 Bug ID: 64719 Summary: omp_get_num_procs should not account for cpu affinity Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: geir at cray dot com CC: jakub at gcc dot gnu.org Created attachment 34525 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34525action=edit omp.c The description for the routine omp_get_num_procs is stated as: Returns the number of processors online on that device. The GCC implementation behavior of omp_get_num_procs does not follow this description, but rather does the following: Returns the number of processors that have affinity to the calling process/thread. The Cray and PGI versions of omp_get_num_procs will return the actual number of processors available on the device without regard to affinity. [I suppose there could be some interpretation what is meant by the term online, but then this should be further explained in the description of omp_get_num_procs.] Our job launcher will set affinity to optimize performance of parallel programs (MPI, SHMEM, Gloab Arrays, UPC, Coarray Fortran, ...). In the following example two processes that have three OpenMP threads are being invoked: GCC compiled program: $ export OMP_NUM_THREADS=3 $ aprun -n 2 -d 3 ./omp.gcc Sysconf get nprocs reports 24 processors Sysconf get nprocs reports 24 processors Hello from pid 14544, thread 0 (core affinity = 0) (Available OpenMP processors = 1) Hello from pid 14544, thread 2 (core affinity = 2) (Available OpenMP processors = 1) Hello from pid 14544, thread 1 (core affinity = 1) (Available OpenMP processors = 1) Hello from pid 14545, thread 0 (core affinity = 3) (Available OpenMP processors = 1) Hello from pid 14545, thread 2 (core affinity = 5) (Available OpenMP processors = 1) Hello from pid 14545, thread 1 (core affinity = 4) (Available OpenMP processors = 1) $ Cray compiler compiled program: $ export OMP_NUM_THREADS=3 $ aprun -n 2 -d 3 ./omp.cray Sysconf get nprocs reports 24 processors Sysconf get nprocs reports 24 processors Hello from pid 14620, thread 2 (core affinity = 2) (Available OpenMP processors = 24) Hello from pid 14620, thread 0 (core affinity = 0) (Available OpenMP processors = 24) Hello from pid 14620, thread 1 (core affinity = 1) (Available OpenMP processors = 24) Hello from pid 14621, thread 0 (core affinity = 3) (Available OpenMP processors = 24) Hello from pid 14621, thread 2 (core affinity = 5) (Available OpenMP processors = 24) Hello from pid 14621, thread 1 (core affinity = 4) (Available OpenMP processors = 24) $ Here is the GCC compiled version with CPU affinity turned off: $ aprun -cc none -n 2 -d 3 ./omp.gcc Sysconf get nprocs reports 24 processors Sysconf get nprocs reports 24 processors Hello from pid 15044, thread 1 (core affinity = 0-23) (Available OpenMP processors = 24) Hello from pid 15044, thread 2 (core affinity = 0-23) (Available OpenMP processors = 24) Hello from pid 15044, thread 0 (core affinity = 0-23) (Available OpenMP processors = 24) Hello from pid 15045, thread 2 (core affinity = 0-23) (Available OpenMP processors = 24) Hello from pid 15045, thread 0 (core affinity = 0-23) (Available OpenMP processors = 24) Hello from pid 15045, thread 1 (core affinity = 0-23) (Available OpenMP processors = 24) $ -- I realize that this bug will very likely be closed as INVALID or WONTFIX, but the documentation needs to be fixed to make clear the behavior of omp_get_num_procs.
[Bug rtl-optimization/62078] [5 Regression] ICE: verify_flow_info failed: missing REG_EH_REGION note at the end of bb 2 with -fdelete-dead-exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62078 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Wed Jan 21 21:51:43 2015 New Revision: 219970 URL: https://gcc.gnu.org/viewcvs?rev=219970root=gccview=rev Log: PR rtl-optimization/62078 * dse.c: Include cfgcleanup.h. (rest_of_handle_dse): For -fnon-call-exceptions, if DSE removed anything call purge_all_dead_edges and cleanup_cfg at the end of the pass. * g++.dg/opt/pr62078.C: New test. Added: trunk/gcc/testsuite/g++.dg/opt/pr62078.C Modified: trunk/gcc/ChangeLog trunk/gcc/dse.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/62078] [5 Regression] ICE: verify_flow_info failed: missing REG_EH_REGION note at the end of bb 2 with -fdelete-dead-exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62078 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed.
[Bug fortran/60718] [4.8/4.9 regression] Test case gfortran.dg/select_type_4.f90 fails on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60718 --- Comment #19 from Bernd Edlinger bernd.edlinger at hotmail dot de --- (In reply to Dominique d'Humieres from comment #18) Any project to back port r218584 to 4.9/8? 4.9 should be easy, because I missed the deadline for 4.9.0 just by a few days. What I applied was just the original patch for 4.9.
[Bug sanitizer/64706] -fsanitize=vptr is not documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64706 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- It now is.
[Bug middle-end/64720] New: Provide strict check for pure attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64720
Bug ID: 64720
Summary: Provide strict check for pure attribute
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: fizzbooze at gmail dot com
Currently an impure function can be attributed as 'pure' and still compile
correctly with no warnings or errors. i.e.:
// BEGIN CODE
int global = 0;
__attribute__((pure))
void foo() {
global += 1; // this obviously violates the pure attribute
}
int main() {
foo();
}
// END CODE
It would be nice to be able to enable some sort of warning or error for code
like this.
[Bug jit/64721] New: SIBAGRT turns into SIGSEGV in jit testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64721 Bug ID: 64721 Summary: SIBAGRT turns into SIGSEGV in jit testsuite Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: dmalcolm at gcc dot gnu.org Failures of the CHECK_ macros within jit/harness.h call abort(), which ought to appear in the logs as a FAIL with SIGABRT. However, they actually lead to a SIGSEGV. Program received signal SIGSEGV, Segmentation fault. 0x776e0909 in pp_format (pp=0x0, text=0x7fffdac0) at ../../src/gcc/pretty-print.c:282 282 output_buffer *buffer = pp_buffer (pp); (gdb) bt #0 0x776e0909 in pp_format (pp=0x0, text=0x7fffdac0) at ../../src/gcc/pretty-print.c:282 #1 0x776de590 in diagnostic_report_diagnostic (context=0x77ffae40 global_diagnostic_context, diagnostic=0x7fffdac0) at ../../src/gcc/diagnostic.c:862 #2 0x776df772 in internal_error (gmsgid=0x77787c43 %s) at ../../src/gcc/diagnostic.c:1237 #3 0x76dcc5a6 in crash_signal (signo=6) at ../../src/gcc/toplev.c:381 #4 signal handler called #5 0x003095835887 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #6 0x003095836f78 in __GI_abort () at abort.c:89 #7 0x00402258 in verify_code (ctxt=0x604010, result=0x63df20) at /home/david/coding-3/gcc-git-jit-pypy/src/gcc/testsuite/jit.dg/test-abort.c:18 #8 0x0040213f in test_jit ( argv0=0x7fffe6b8 /home/david/coding-3/gcc-git-jit-pypy/build/gcc/testsuite/jit/test-abort.c.exe, user_data=0x0) at /home/david/coding-3/gcc-git-jit-pypy/src/gcc/testsuite/jit.dg/harness.h:346 #9 0x0040221e in main (argc=1, argv=0x7fffe448) at /home/david/coding-3/gcc-git-jit-pypy/src/gcc/testsuite/jit.dg/harness.h:389 where context-printer is NULL (for the global_diagnostic_context).
[Bug target/64688] [5 Regression] internal compiler error: Max. number of generated reload insns per insn is achieved (90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64688 --- Comment #3 from Vladimir Makarov vmakarov at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #2) This is while reloading (define_insn vec_setmode_0 [(set (match_operand:VI4F_128 0 nonimmediate_operand =Yr,*v,v,v ,x,x,v,Yr ,*x ,x ,m ,m ,m) (vec_merge:VI4F_128 (vec_duplicate:VI4F_128 (match_operand:ssescalarmode 2 general_operand Yr,*v,m,*r,m,x,v,*rm,*rm,*rm,!x,!*re,!*fF)) (match_operand:VI4F_128 1 vector_move_operand C , C,C,C ,C,0,v,0 ,0 ,x ,0 ,0 ,0) (const_int 1)))] instruction I think. The problem is related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64477 The solution proposed there solves this problem too. Changing '*r' to 'r resulting in constraint Yr,*v,m,r,m,x,v,*rm,*rm,*rm,!x,!*re,!*fF will solve the PR. So the change will solve 2 PRs (this one and 64477). I believe it is up to x86 maintainers to do this change.
[Bug target/64477] [4.9/5 Regression] x86 sse unnecessary GPR spill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64477 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- Uros, your thoughts on this?
[Bug fortran/60718] [4.8/4.9 regression] Test case gfortran.dg/select_type_4.f90 fails on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60718 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||bernd.edlinger at hotmail dot de --- Comment #18 from Dominique d'Humieres dominiq at lps dot ens.fr --- Any project to back port r218584 to 4.9/8?
[Bug c++/64603] [5 Regression] bogus error no matching function for call to ... with templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64603 --- Comment #5 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Wed Jan 21 21:56:34 2015 New Revision: 219973 URL: https://gcc.gnu.org/viewcvs?rev=219973root=gccview=rev Log: PR c++/64603 * constexpr.c (cxx_eval_constant_expression): Only shortcut constant CONSTRUCTORs. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-sizeof1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/constexpr.c
[Bug debug/64511] [5 Regression] ICE at -O3 with -g enabled on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64511 --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Wed Jan 21 21:59:34 2015 New Revision: 219974 URL: https://gcc.gnu.org/viewcvs?rev=219974root=gccview=rev Log: PR debug/64511 * simplify-rtx.c (simplify_relational_operation_1): Don't try to optimize (eq/ne (and (side_effects) (const_int 0)) (const_int 0)) into (eq/ne (and (not (side_effects)) (const_int 0)) (const_int 0)). * gcc.dg/pr64511.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr64511.c Modified: trunk/gcc/ChangeLog trunk/gcc/simplify-rtx.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/64700] Sink common code through PHI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64700 --- Comment #2 from Jeffrey A. Law law at redhat dot com --- I had a code hoisting pass on top of PRE a while back as well. Can't remember why I abandoned it. Oh yea, on top of PRE :-) I've still got a global code motion pass here based on Click's work. It handles both hoisting and sinking. Basically you record the earliest possible block for each statement and a latest block for each statement. The path through the dominator tree connecting those two blocks is the set of valid blocks for the statement. Then you just choose the 'best' one in that path. Most control dependent path within the shallowest loop nest. It didn't handle sinking PHIs or hoisting/sinking through a dependent node. Not sure if it could be changed to do that. I never pushed on it simply because it never did significantly better than the other code motion code we already have. It pointed out a few minor issues in tree-ssa-sink.c, but nothing that couldn't be easily fixed. Too bad, I always found the basic algorithm to be rather elegant. I'm certain we're missing all kinds of interesting code motions..
[Bug c/63307] [4.9/5 Regression] Cilk+ breaks -fcompare-debug bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63307 --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Wed Jan 21 21:23:04 2015 New Revision: 219969 URL: https://gcc.gnu.org/viewcvs?rev=219969root=gccview=rev Log: PR c/63307 * cilk.c (fill_decls_vec): Only put decls into vector v. (compare_decls): Fix up formatting. * c-c++-common/cilk-plus/CK/pr63307.c: New test. 2015-01-21 Igor Zamyatin igor.zamya...@intel.com PR c/63307 * cilk.c: Include vec.h. (struct cilk_decls): New structure. (wrapper_parm_cb): Split this function to... (fill_decls_vec): ...this... (create_parm_list): ...and this. (compare_decls): New function. (for_local_cb): Remove. (wrapper_local_cb): Ditto. (build_wrapper_type): For now first traverse and fill vector of declarations then sort it and then deal with sorted vector. (cilk_outline): Ditto. (declare_one_free_variable): Ditto. Added: trunk/gcc/testsuite/c-c++-common/cilk-plus/CK/pr63307.c Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/cilk.c trunk/gcc/testsuite/ChangeLog
[Bug target/64477] [4.9/5 Regression] x86 sse unnecessary GPR spill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64477
--- Comment #6 from Uroš Bizjak ubizjak at gmail dot com ---
(In reply to Jakub Jelinek from comment #5)
Uros, your thoughts on this?
All these *r are (were?) necessary for TARGET_INTER_UNIT_MOVES_{TO,FROM}_VEC to
avoid allocating general reg, but to go through memory.
It looks that this particular case is just an oversight, and this alternative
should be defined as (Yi/r/C), as is the case for similar sse2_loadd insn
Otherwise, these constraints were carefully fine-tuned for reload. IRA is
slightly different, and no wonder that these constraints will have to be
re-tuned in coming years.
[Bug sanitizer/64435] [5 Regression] Bootstrap failure in libsanitizer on AArch64 with Linux kernel = 3.15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64435 --- Comment #24 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Wed Jan 21 21:21:27 2015 New Revision: 219968 URL: https://gcc.gnu.org/viewcvs?rev=219968root=gccview=rev Log: PR sanitizer/64435 * sanitizer_common/sanitizer_platform_limits_posix.h: Cherry pick upstream r226637. * sanitizer_common/sanitizer_platform_limits_posix.cc: Likewise. * sanitizer_common/sanitizer_posix.cc: Cherry pick upstream r226639. Modified: trunk/libsanitizer/ChangeLog trunk/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc trunk/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h trunk/libsanitizer/sanitizer_common/sanitizer_posix.cc
[Bug ipa/63970] [4.9 Regression] gcc-4_9 inlines less funcs than gcc-4_8 because of used_as_abstract_origin flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63970 --- Comment #7 from wmi at gcc dot gnu.org --- Author: wmi Date: Wed Jan 21 21:56:14 2015 New Revision: 219972 URL: https://gcc.gnu.org/viewcvs?rev=219972root=gccview=rev Log: Backported from trunk. 2014-11-22 Jan Hubicka hubi...@ucw.cz PR ipa/63970 * ipa.c (symbol_table::remove_unreachable_nodes): Mark all inline clones as having abstract origin used. * ipa-inline-transform.c (can_remove_node_now_p_1): Drop abstract origin check. (clone_inlined_nodes): Copy abstract originflag. * lto-cgraph.c (compute_ltrans_boundary): Use get_create to get abstract origin node. Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/ipa-inline-transform.c branches/gcc-4_9-branch/gcc/ipa.c branches/gcc-4_9-branch/gcc/lto-cgraph.c
[Bug sanitizer/64435] [5 Regression] Bootstrap failure in libsanitizer on AArch64 with Linux kernel = 3.15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64435 Bug 64435 depends on bug 64131, which changed state. Bug 64131 Summary: [5 Regression] libsanitizer fails to build for AARCH64 with the glibc from the trunk https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64131 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug sanitizer/64131] [5 Regression] libsanitizer fails to build for AARCH64 with the glibc from the trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64131 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Wed Jan 21 21:21:27 2015 New Revision: 219968 URL: https://gcc.gnu.org/viewcvs?rev=219968root=gccview=rev Log: PR sanitizer/64435 * sanitizer_common/sanitizer_platform_limits_posix.h: Cherry pick upstream r226637. * sanitizer_common/sanitizer_platform_limits_posix.cc: Likewise. * sanitizer_common/sanitizer_posix.cc: Cherry pick upstream r226639. Modified: trunk/libsanitizer/ChangeLog trunk/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc trunk/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h trunk/libsanitizer/sanitizer_common/sanitizer_posix.cc
[Bug c++/64704] software crashed when using vectorizing optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64704 Mikhail Maltsev maltsevm at gmail dot com changed: What|Removed |Added CC||maltsevm at gmail dot com --- Comment #5 from Mikhail Maltsev maltsevm at gmail dot com --- (In reply to kathy from comment #3) i think, form line:13082c7 to 1308348, the code is to doing something with align? Yes 13082f0: 66 41 0f 6f 0b movdqa (%r11),%xmm1 Address in %r11 is expected to be aligned by 16-byte boundary.
[Bug c++/64647] [5 Regression] [C++14] std::__max_element contains code not allowed in constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64647 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Wed Jan 21 20:15:35 2015 New Revision: 219965 URL: https://gcc.gnu.org/viewcvs?rev=219965root=gccview=rev Log: PR c++/64647 * constexpr.c (ensure_literal_type_for_constexpr_object): Don't give a hard error in a template instantiation. Added: trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-local3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/constexpr.c
[Bug c++/64629] [5 Regression] -Wformat-security warns with const char *const vars
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64629 --- Comment #1 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Wed Jan 21 20:15:27 2015 New Revision: 219964 URL: https://gcc.gnu.org/viewcvs?rev=219964root=gccview=rev Log: PR c++/64629 * c-format.c (check_format_arg): Call decl_constant_value. Added: trunk/gcc/testsuite/g++.dg/warn/Wformat-1.C Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-format.c
[Bug c++/64603] [5 Regression] bogus error no matching function for call to ... with templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64603 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug fortran/60718] [4.8/4.9 regression] Test case gfortran.dg/select_type_4.f90 fails on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60718 --- Comment #20 from Dominique d'Humieres dominiq at lps dot ens.fr --- 4.9 should be easy, because I missed the deadline for 4.9.0 just by a few days. What I applied was just the original patch for 4.9. Could you please do it? I cannot test on arm-*-*. If it is too difficult for 4.8, the PR can be closed after the commit for 4.9.
[Bug fortran/60718] [4.8/4.9 regression] Test case gfortran.dg/select_type_4.f90 fails on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60718 --- Comment #21 from Bernd Edlinger bernd.edlinger at hotmail dot de --- (In reply to Dominique d'Humieres from comment #20) 4.9 should be easy, because I missed the deadline for 4.9.0 just by a few days. What I applied was just the original patch for 4.9. Could you please do it? I cannot test on arm-*-*. If it is too difficult for 4.8, the PR can be closed after the commit for 4.9. OK, will re-do that test for 4.9 next week.
[Bug jit/64721] SIBABRT becomes a SIGSEGV in jit testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64721 --- Comment #2 from David Malcolm dmalcolm at gcc dot gnu.org --- (In reply to David Malcolm from comment #1) Currently we unconditionally install crash_handler as a signal_handler, and crash_signal as a signal-handler this should have read.
[Bug jit/64721] SIBABRT becomes a SIGSEGV in jit testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64721 David Malcolm dmalcolm at gcc dot gnu.org changed: What|Removed |Added Summary|SIBAGRT turns into SIGSEGV |SIBABRT becomes a SIGSEGV |in jit testsuite|in jit testsuite --- Comment #1 from David Malcolm dmalcolm at gcc dot gnu.org --- Currently we unconditionally install crash_handler as a signal_handler, and this itself (ironically) will crash if called after toplev::main cleans up the global_diagnostic_context. Three options: (A) We could unregister the signal handlers in toplev::finalize immediately before global_diagnostic_context has diagnostic_finish called on it, potentially restoring whatever signal handlers were there before. (B) Don't register signal-handlers at all when run from inside libgccjit. (C) Make creation of global_diagnostic_context be idempotent, and don't clean it up. (B) seems best from the POV of a library that aims to be thread-safe: don't touch signal-handlers when inside libgccjit. I have a patch for this.
[Bug jit/64721] SIGABRT becomes a SIGSEGV after invoking gcc_jit_context_compile[_to_file] within a process
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64721 David Malcolm dmalcolm at gcc dot gnu.org changed: What|Removed |Added Summary|SIGABRT becomes a SIGSEGV |SIGABRT becomes a SIGSEGV |in jit testsuite|after invoking ||gcc_jit_context_compile[_to ||_file] within a process --- Comment #3 from David Malcolm dmalcolm at gcc dot gnu.org --- (retitling; it appears that any use of gcc_jit_context_compile[_to_file] that makes it as far as toplev::main will install the signal-handlers into the process, leading to SIGSEGV inside libgccjit due e.g. to assert failures in other DSOs within the process)
[Bug tree-optimization/18487] Warnings for pure and const functions that are not actually pure or const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18487 --- Comment #8 from Andrew Pinski pinskia at gcc dot gnu.org --- I don't think I agree with closing this as won't fix as shown now we have three duplicated bugs asking the same thing.
[Bug tree-optimization/18487] Warnings for pure and const functions that are not actually pure or const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18487 --- Comment #10 from David Malcolm dmalcolm at gcc dot gnu.org --- fizzbooze: you were asking on IRC about where the existing implementation is; see gcc/ipa-pure-const.c - though I believe that merely covers tracking the user-provided flags interprocedurally; I don't think it covers walking individual stmts and detecting side-effects.
[Bug middle-end/64720] Provide strict check for pure attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64720 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- Exact dup of bug 18487. *** This bug has been marked as a duplicate of bug 18487 ***
[Bug tree-optimization/18487] Warnings for pure and const functions that are not actually pure or const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18487 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added CC||fizzbooze at gmail dot com --- Comment #7 from Andrew Pinski pinskia at gcc dot gnu.org --- *** Bug 64720 has been marked as a duplicate of this bug. ***
[Bug target/64580] very high rs6000_stack_info() usage during LTO Firefox build on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64580 --- Comment #3 from Segher Boessenkool segher at gcc dot gnu.org --- Hi again, Unfortunately it seems I am unable to build a version of GCC that is compatible with that (every version I tried either complains or ICEs). Maybe you can answer the above questions yourself? How often is rs6000_output_mi_thunk called (+ some sense of scale, e.g. how many real functions are emitted)? Is there a real hotspot in rs6000_stack_info itself? I haven't been able to get it above 0.16% of cpu time, and no hotspots. Can perf be used to analyze results on a different machine than used to generate the data?
[Bug rtl-optimization/64682] [5 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64682 --- Comment #5 from Segher Boessenkool segher at gcc dot gnu.org --- Author: segher Date: Thu Jan 22 00:35:44 2015 New Revision: 219981 URL: https://gcc.gnu.org/viewcvs?rev=219981root=gccview=rev Log: PR rtl-optimization/64682 * combine.c (distribute_notes): When moving a death note for a register that is set in the new I2, make sure to put it before that new I2. PR rtl-optimization/64682 * gcc.c-torture/execute/pr64682.c: New file. Modified: trunk/gcc/ChangeLog trunk/gcc/combine.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/18487] Warnings for pure and const functions that are not actually pure or const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18487 David Malcolm dmalcolm at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED CC||dmalcolm at gcc dot gnu.org Resolution|WONTFIX |--- Ever confirmed|1 |0 --- Comment #9 from David Malcolm dmalcolm at gcc dot gnu.org --- (In reply to Andrew Pinski from comment #8) I don't think I agree with closing this as won't fix as shown now we have three duplicated bugs asking the same thing. I agree; reopening. It may not be possible to implement a perfect test for this, but it seems to me that it's possible to implement a warning that catches a subset of cases without false positives (at the cost of having false negatives). As a first iteration of an implementation: for all fns labelled as pure/const: for all basic blocks that are guaranteed to be in a path through the function: for all stmts in BB: if stmt is non-pure/non-const: issue a warning (yes, this would miss some things e.g. if (COND) non-pure else non-pure but could be cheap and effective)
[Bug ipa/64686] [5 Regression] ICE: in edge_badness, at ipa-inline.c:912 during Firefox LTO build with enabled checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64686 --- Comment #2 from Jan Hubicka hubicka at gcc dot gnu.org --- In what configuration do you build FIrefox? This does not reproduce for me with -O3 build.
[Bug libstdc++/64680] basic_regex::operator= does not reset flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64680 --- Comment #1 from Tim Shen timshen at gcc dot gnu.org --- Author: timshen Date: Thu Jan 22 05:07:03 2015 New Revision: 219987 URL: https://gcc.gnu.org/viewcvs?rev=219987root=gccview=rev Log: PR libstdc++/64680 * include/bits/regex.h (basic_regex::basic_regex, basic_regex::operator=, basic_regex::imbue): Conform to the standard interface. * testsuite/28_regex/basic_regex/assign/char/cstring.cc: New testcase. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/regex.h trunk/libstdc++-v3/testsuite/28_regex/basic_regex/assign/char/cstring.cc
[Bug c++/64724] C++ loop with -O3 optimization produces segfault while -O2 is fine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64724 --- Comment #3 from Andrey Prokopenko aprokop at sandia dot gov --- Andrew, Could you please point out the rule? I cannot find it. I also see that Intel x86/64 reference manual states in section 4.1.1 that ~~~ Words, doublewords, and quadwords do not need to be aligned in memory on natural boundaries. The natural boundaries for words, double words, and quadwords are even-numbered addresses, addresses evenly divisible by four, and addresses evenly divisible by eight, respectively. However, to improve the performance of programs, data structures (especially stacks) should be aligned on natural boundaries whenever possible. The reason for this is that the processor requires two memory accesses to make an unaligned memory access; aligned accesses require only one memory access. A word or doubleword operand that crosses a 4-byte boundary or a quadword operand that crosses an 8-byte boundary is considered unaligned and requires two separate memory bus cycles for access. ~~~
[Bug jit/64722] New: On 2nd time libgccjit is run in-process on i686, generated code clobbers %ebx register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64722
Bug ID: 64722
Summary: On 2nd time libgccjit is run in-process on i686,
generated code clobbers %ebx register
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: jit
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Build: i686-pc-linux-gnu
I'm seeing a crash on i686 for various test cases, each
within main, getting ready to begin the *3rd* iteration of the test.
FAIL: test-array-as-pointer.c.exe killed: 37097 exp8 0 0 CHILDKILLED SIGSEGV
{segmentation violation}
FAIL: test-calling-external-function.c.exe killed: 37185 exp8 0 0 CHILDKILLED
SIGSEGV {segmentation violation}
FAIL: test-combination.c.exe killed: 37273 exp8 0 0 CHILDKILLED SIGSEGV
{segmentation violation}
FAIL: test-expressions.c.exe killed: 38499 exp8 0 0 CHILDKILLED SIGSEGV
{segmentation violation}
FAIL: test-fibonacci.c.exe killed: 38587 exp8 0 0 CHILDKILLED SIGSEGV
{segmentation violation}
FAIL: test-functions.c.exe killed: 38627 exp8 0 0 CHILDKILLED SIGSEGV
{segmentation violation}
FAIL: test-hello-world.c.exe killed: 38695 exp8 0 0 CHILDKILLED SIGSEGV
{segmentation violation}
FAIL: test-nested-contexts.c.exe killed: 38831 exp8 0 0 CHILDKILLED SIGSEGV
{segmentation violation}
FAIL: test-operator-overloading.cc.exe killed: 38919 exp8 0 0 CHILDKILLED
SIGSEGV {segmentation violation}
FAIL: test-quadratic.c.exe killed: 38959 exp8 0 0 CHILDKILLED SIGSEGV
{segmentation violation}
FAIL: test-quadratic.cc.exe killed: 39000 exp8 0 0 CHILDKILLED SIGSEGV
{segmentation violation}
FAIL: test-reading-struct.c.exe killed: 39040 exp8 0 0 CHILDKILLED SIGSEGV
{segmentation violation}
FAIL: test-threads.c.exe killed: 39176 exp8 0 0 CHILDKILLED SIGSEGV
{segmentation violation}
All of them crash here in main, trying to read argv, apparently something has
trashed %ebx:
(gdb) disassemble main
Dump of assembler code for function main:
0x080499c0 +0:lea0x4(%esp),%ecx
0x080499c4 +4:and$0xfff0,%esp
0x080499c7 +7:pushl -0x4(%ecx)
0x080499ca +10:push %ebp
0x080499cb +11:mov%esp,%ebp
0x080499cd +13:push %ebx
0x080499ce +14:push %ecx
0x080499cf +15:sub$0x10,%esp
0x080499d2 +18:mov%ecx,%ebx
0x080499d4 +20:movl $0x1,-0xc(%ebp)
0x080499db +27:jmp0x8049a25 main+101
= 0x080499dd +29:mov0x4(%ebx),%eax
0x080499e0 +32:mov(%eax),%eax
0x080499e2 +34:sub$0xc,%esp
0x080499e5 +37:push %eax
0x080499e6 +38:call 0x8049982 extract_progname
0x080499eb +43:add$0x10,%esp
0x080499ee +46:sub$0x8,%esp
0x080499f1 +49:push $0x5
0x080499f3 +51:pushl -0xc(%ebp)
0x080499f6 +54:push %eax
0x080499f7 +55:push $0x804a06b
0x080499fc +60:push $0x400
0x08049a01 +65:push $0x804c340
0x08049a06 +70:call 0x8048fc0 snprintf@plt
0x08049a0b +75:add$0x20,%esp
0x08049a0e +78:mov0x4(%ebx),%eax
0x08049a11 +81:mov(%eax),%eax
0x08049a13 +83:sub$0x8,%esp
0x08049a16 +86:push $0x0
0x08049a18 +88:push %eax
0x08049a19 +89:call 0x80498be test_jit
0x08049a1e +94:add$0x10,%esp
0x08049a21 +97:addl $0x1,-0xc(%ebp)
0x08049a25 +101:cmpl $0x5,-0xc(%ebp)
0x08049a29 +105:jle0x80499dd main+29
0x08049a2b +107:call 0x8049335 totals
0x08049a30 +112:mov$0x0,%eax
0x08049a35 +117:lea-0x8(%ebp),%esp
0x08049a38 +120:pop%ecx
0x08049a39 +121:pop%ebx
0x08049a3a +122:pop%ebp
0x08049a3b +123:lea-0x4(%ecx),%esp
0x08049a3e +126:ret
End of assembler dump.
Investigating test-hello-world.c and the generated hello_world:
(gdb) break hello_world
On iteration 1:
(gdb) disassemble hello_world
Dump of assembler code for function hello_world:
0xf671a510 +0:push %ebp
0xf671a511 +1:mov%esp,%ebp
0xf671a513 +3:push %ebx
= 0xf671a514 +4:sub$0x4,%esp
0xf671a517 +7:call 0xf671a53d __x86.get_pc_thunk.ax
0xf671a51c +12:add$0x1ae4,%eax
0xf671a521 +17:sub$0x8,%esp
0xf671a524 +20:pushl 0x8(%ebp)
0xf671a527 +23:lea-0x1aa8(%eax),%edx
0xf671a52d +29:push %edx
0xf671a52e +30:mov%eax,%ebx
0xf671a530 +32:call 0xf671a3b0 printf@plt
0xf671a535 +37:add$0x10,%esp
0xf671a538 +40:mov-0x4(%ebp),%ebx
0xf671a53b +43:leave
0xf671a53c +44:ret
End of assembler dump.
but on iteration 2:
(gdb) cont
ITERATION 2
Breakpoint 1, 0xf671a516 in hello_world (name=0x804a35a world) from
/tmp/libgccjit-9zApb1/fake.so
(gdb) disassemble
Dump of assembler code for function hello_world:
0xf671a510 +0:push %ebp
0xf671a511
[Bug c++/64723] -O3 optimization produces segfault through vectorization, while -O2 is fine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64723 Andrey Prokopenko aprokop at sandia dot gov changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrey Prokopenko aprokop at sandia dot gov --- accidental submission
[Bug c++/64724] C++ loop with -O3 optimization produces segfault while -O2 is fine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64724 --- Comment #1 from Andrey Prokopenko aprokop at sandia dot gov --- Created attachment 34526 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34526action=edit .ii file
[Bug c++/64724] New: C++ loop with -O3 optimization produces segfault while -O2 is fine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64724 Bug ID: 64724 Summary: C++ loop with -O3 optimization produces segfault while -O2 is fine Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: aprokop at sandia dot gov $ gcc -v Using built-in specs. COLLECT_GCC=/home/aprokop/local/opt/gcc-4.9.2/bin/gcc COLLECT_LTO_WRAPPER=/home/aprokop/local/opt/gcc-4.9.2/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.9.2/configure --prefix=/home/aprokop/local/opt/gcc-4.9.2 --enable-gold --enable-languages=c,c++,fortran Thread model: posix gcc version 4.9.2 (GCC) I've tried 4.9.1, 4.9.2 and the trunk versions. The attached code results in segfault. Valgrind generates General protection fault.
[Bug libstdc++/64649] regex_traits::lookup_classname() only works with random access iterators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64649 --- Comment #4 from Tim Shen timshen at gcc dot gnu.org --- Author: timshen Date: Thu Jan 22 05:02:38 2015 New Revision: 219986 URL: https://gcc.gnu.org/viewcvs?rev=219986root=gccview=rev Log: PR libstdc++/64649 * include/bits/regex.tcc (regex_traits::lookup_collatename, regex_traits::lookup_classname): Correctly narrow input chars. * testsuite/28_regex/traits/wchar_t/user_defined.cc: New testcase. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/regex.tcc trunk/libstdc++-v3/testsuite/28_regex/traits/wchar_t/user_defined.cc
[Bug c++/64724] C++ loop with -O3 optimization produces segfault while -O2 is fine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64724 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org --- char * a_tmp = new char[n*sizeof(double)+1]; char * b_tmp = new char[n*sizeof(double)+1]; double * a = reinterpret_castdouble*(a_tmp+1); double * b = reinterpret_castdouble*(b_tmp+1); You are violating C rules dealing with alignment. Pointer a and b are not aligned to the alignment of double so the behavior is undefined.
[Bug tree-optimization/64718] Bad 16-bit bswap replacement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64718 thopre01 at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #4 from thopre01 at gcc dot gnu.org --- The problem comes from: bswap_type = TREE_TYPE (src); in bswap_replace when dealing with 16-bit bswap. I got a fix for that and testing is underway. Thanks for the testcase. Best regards.
[Bug c++/64314] [5 Regression] ICE in record_reference, at cgraphbuild.c:87
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64314 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug rtl-optimization/64081] [5 Regression] r217827 prevents RTL loop unroll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64081 --- Comment #10 from David Edelsohn dje at gcc dot gnu.org --- Unfortunately the attached patch causes the same failure demonstrating a miscompilation of the stage 2 compiler.
[Bug c++/64723] New: -O3 optimization produces segfault through vectorization, while -O2 is fine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64723 Bug ID: 64723 Summary: -O3 optimization produces segfault through vectorization, while -O2 is fine Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: aprokop at sandia dot gov Hi,
[Bug preprocessor/60570] expression in 'elif' directive mis-diagnosed as error when group will be skipped
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60570 moshansky at hotmail dot com changed: What|Removed |Added CC||moshansky at hotmail dot com --- Comment #4 from moshansky at hotmail dot com --- Still present as of gcc version 4.8.4 20140526 (release) [ARM/embedded-4_8-branch revision 211358] (GNU Tools for ARM Embedded Processors). Fails: #if(1) #pragma message This Should Work #elif(1/0) #pragma message 1/0 should not be attempted #endif Workaround: #if(1) #pragma message This Should Work #else #elif(1/0) #pragma message 1/0 should is not attempted #endif #endif
[Bug target/64580] very high rs6000_stack_info() usage during LTO Firefox build on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64580 --- Comment #4 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to Segher Boessenkool from comment #3) Hi again, Unfortunately it seems I am unable to build a version of GCC that is compatible with that (every version I tried either complains or ICEs). Yes, it's unfortunate that there is no stable interface at all. Every patch in this area potentially breaks things and there were a couple of them in the last few days. Maybe you can answer the above questions yourself? How often is rs6000_output_mi_thunk called (+ some sense of scale, e.g. how many real functions are emitted)? Is there a real hotspot in rs6000_stack_info itself? I haven't been able to get it above 0.16% of cpu time, and no hotspots. I will try to collect some callgrind data later today. Can perf be used to analyze results on a different machine than used to generate the data? If the version of perf is the same then yes.
[Bug target/64477] [4.9/5 Regression] x86 sse unnecessary GPR spill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64477 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Keywords|missed-optimization, ra | Target|x86_64-*-* |x86 Assignee|vmakarov at redhat dot com |ubizjak at gmail dot com --- Comment #7 from Uroš Bizjak ubizjak at gmail dot com --- Patch in testing: --cut here-- Index: config/i386/sse.md === --- config/i386/sse.md (revision 219987) +++ config/i386/sse.md (working copy) @@ -6391,11 +6391,11 @@ ;; see comment above inline_secondary_memory_needed function in i386.c (define_insn vec_setmode_0 [(set (match_operand:VI4F_128 0 nonimmediate_operand - =Yr,*v,v,v ,x,x,v,Yr ,*x ,x ,m ,m ,m) + =Yr,*v,v,Yi,x,x,v,Yr ,*x ,x ,m ,m ,m) (vec_merge:VI4F_128 (vec_duplicate:VI4F_128 (match_operand:ssescalarmode 2 general_operand - Yr,*v,m,*r,m,x,v,*rm,*rm,*rm,!x,!*re,!*fF)) + Yr,*v,m,r ,m,x,v,*rm,*rm,*rm,!x,!*re,!*fF)) (match_operand:VI4F_128 1 vector_move_operand C , C,C,C ,C,0,v,0 ,0 ,x ,0 ,0 ,0) (const_int 1)))] --cut here--
[Bug c++/64724] C++ loop with -O3 optimization produces segfault while -O2 is fine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64724 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- The fact that the CPU handles it has nothing to do whether it is undefined behavior or not. And i?86/x86_64 hw is actually hybrid in the alignment case, some instructions don't require strict alignment, while others do. You can try -fsanitize=undefined and it will diagnose this at runtime: $ g++ -fsanitize=undefined -o pr64724 pr64724.ii $ ./pr64724 a.cc:21:19: runtime error: load of misaligned address 0x025bd011 for type 'double', which requires 8 byte alignment 0x025bd011: note: pointer points here 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ^ a.cc:21:20: runtime error: store to misaligned address 0x025bd5a1 for type 'double', which requires 8 byte alignment 0x025bd5a1: note: pointer points here 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ^
[Bug debug/64511] [5 Regression] ICE at -O3 with -g enabled on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64511 --- Comment #14 from Jakub Jelinek jakub at gcc dot gnu.org --- Note the stack traces involving do_spec_1 are generally bogus (should be fixed), those stack traces are from the gcc driver rather than cc1/cc1plus etc., and are printed because cc1/cc1plus segfaulted.
[Bug tree-optimization/18487] Warnings for pure and const functions that are not actually pure or const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18487 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org --- It would have to be a warning, and would necessarily not catch many things, e.g. if you use inline asm, it is hard to find out if it is non-pure, as has been mentioned earlier, dead code or possible dead code should not be warned about, and if you call other functions, even if they aren't declared pure, it might be that they don't write anything with the given arguments or arranged through other means.
[Bug debug/64511] [5 Regression] ICE at -O3 with -g enabled on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64511
--- Comment #13 from Zhendong Su su at cs dot ucdavis.edu ---
(In reply to Jakub Jelinek from comment #11)
The #c0 issue is different (with the reorder_operands call commented out),
...
That said, I'd like to fix #c8 independently.
Jakub, indeed, #c8 was reduced from another test. I thought the two were the
same as they have the same exact stack trace.
FYI, below is a reduced test from the same original test as for #c0. It fails
with r219963.
$ 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/5.0.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 5.0.0 20150121 (experimental) [trunk revision 219963] (GCC)
$
$ gcc-trunk -O3 -g -c small2.c
$
$ time gcc-trunk -O3 -g -c small2.c
gcc-trunk: internal compiler error: Segmentation fault (program cc1)
0x40c27f execute
../../gcc-trunk/gcc/gcc.c:2913
0x40c589 do_spec_1
../../gcc-trunk/gcc/gcc.c:4846
0x40eb87 process_brace_body
../../gcc-trunk/gcc/gcc.c:6129
0x40eb87 handle_braces
../../gcc-trunk/gcc/gcc.c:6043
0x40d587 do_spec_1
../../gcc-trunk/gcc/gcc.c:5500
0x40eb87 process_brace_body
../../gcc-trunk/gcc/gcc.c:6129
0x40eb87 handle_braces
../../gcc-trunk/gcc/gcc.c:6043
0x40d587 do_spec_1
../../gcc-trunk/gcc/gcc.c:5500
0x40c913 do_spec_1
../../gcc-trunk/gcc/gcc.c:5615
0x40eb87 process_brace_body
../../gcc-trunk/gcc/gcc.c:6129
0x40eb87 handle_braces
../../gcc-trunk/gcc/gcc.c:6043
0x40d587 do_spec_1
../../gcc-trunk/gcc/gcc.c:5500
0x40eb87 process_brace_body
../../gcc-trunk/gcc/gcc.c:6129
0x40eb87 handle_braces
../../gcc-trunk/gcc/gcc.c:6043
0x40d587 do_spec_1
../../gcc-trunk/gcc/gcc.c:5500
0x40eb87 process_brace_body
../../gcc-trunk/gcc/gcc.c:6129
0x40eb87 handle_braces
../../gcc-trunk/gcc/gcc.c:6043
0x40d587 do_spec_1
../../gcc-trunk/gcc/gcc.c:5500
0x40eb87 process_brace_body
../../gcc-trunk/gcc/gcc.c:6129
0x40eb87 handle_braces
../../gcc-trunk/gcc/gcc.c:6043
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.
Command exited with non-zero status 4
8.05user 0.59system 0:12.84elapsed 67%CPU (0avgtext+0avgdata
3121136maxresident)k
0inputs+0outputs (0major+195936minor)pagefaults 0swaps
$
extern void fn1 (int p1, int p2);
short d;
void fn2 (int p1, unsigned char p2)
{
unsigned char k, *l = p2;
short m;
for (m = 27; m 37; m++)
d *= *l %= *l;
fn1 (p1 %= p2, p1 = k);
}
[Bug tree-optimization/18487] Warnings for pure and const functions that are not actually pure or const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18487 --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org --- And then there is the case of endless loops in such functions (either unconditional, or ones the compiler is not able to detect), exit calls, both either directly in the const/pure function or in some function it calls. So in all, I'm afraid such a warning would diagnose only the most trivial cases.
[Bug rtl-optimization/64682] [5 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64682 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- Thanks.
[Bug preprocessor/60570] expression in 'elif' directive mis-diagnosed as error when group will be skipped
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60570 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org, ||jsm28 at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- So shall we then partially revert r136209 aka PR36320? I say partially, because I think at least the addition of is_if argument to _cpp_parse_expr should be preserved.
[Bug debug/64511] [5 Regression] ICE at -O3 with -g enabled on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64511 --- Comment #15 from Zhendong Su su at cs dot ucdavis.edu --- (In reply to Jakub Jelinek from comment #14) Note the stack traces involving do_spec_1 are generally bogus (should be fixed), those stack traces are from the gcc driver rather than cc1/cc1plus etc., and are printed because cc1/cc1plus segfaulted. Oh, I see; thanks for the info.
[Bug target/64580] very high rs6000_stack_info() usage during LTO Firefox build on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64580 --- Comment #5 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Here is an example callgrind_control -e -b output (program is still running): PID 53944: /home/trippels/gcc_test/usr/local/bin/../libexec/gcc/powerpc64-unknown-linux-gnu/5.0.0/lto1 -quiet -dumpbase libxul.so.ltrans8.o -mcpu=power8 -auxbase-strip /dev/null -O3 -version -fPIC -fno-exceptions -fltrans /var/tmp/libxul.so.ltrans8.o -o /home/trippels/tmp/ccxhYq0O.s sending command status internal to pid 53944 Totals: Ir Th 1 163,422,428,166 Frame: Ir Backtrace for Thread 1 [ 0] 127,387,164,848 rs6000_stack_info() (932 x) [ 1] 127,387,195,580 rs6000_output_function_prologue(_IO_FILE*, long) (932 x) [ 2] 127,387,263,387 final_start_function(rtx_insn*, _IO_FILE*, int) (132 x) [ 3] 127,390,072,883 rs6000_output_mi_thunk(_IO_FILE*, tree_node*, long, long, tree_node*) (132 x) [ 4] 127,490,182,450 cgraph_node::expand_thunk(bool, bool) (132 x) [ 5] 127,490,272,999 cgraph_node::assemble_thunks_and_aliases() (190 x) [ 6] 127,491,063,296 cgraph_node::assemble_thunks_and_aliases() (800 x) [ 7] 156,624,357,942 cgraph_node::expand() (800 x) [ 8] 157,695,780,192 symbol_table::compile() [clone .part.53] (1 x) [ 9] 157,695,780,213 symbol_table::compile() (1 x) [10] 163,407,638,386 lto_main() (1 x) [11] 163,407,638,419 compile_file() (1 x) [12] 163,421,626,146 toplev::main(int, char**) (1 x) [13] 163,421,626,164 main (1 x) [14] 163,421,630,096 generic_start_main.isra.0 (1 x) [15] 163,421,630,244 (below main) (1 x) [16] 163,421,632,780 0x10f23930 (1 x) [17] 163,421,632,786 0x1012f5a0 (1 x) [18] 163,421,632,794 _start (1 x) [19] 163,421,634,426 _dl_start_user (1 x) [20]. _start
[Bug c++/64647] [5 Regression] [C++14] std::__max_element contains code not allowed in constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64647 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jason Merrill jason at gcc dot gnu.org --- Fixed.
