[Bug target/83748] Local variables not aligned to word boundary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83748 --- Comment #8 from Sumit --- Hi Segher, I somehow missed the below update from your side. Can you help me understand if this was some known issue in GCC which got fixed in r205896? If yes, can you let us know if got fixed in 4.8.1 version? Thanks. Regards, Sumit -Original Message- From: segher at gcc dot gnu.org Sent: Wednesday, March 07, 2018 12:12 AM To: Bansal, Sumit Subject: [**EXTERNAL**] [Bug target/83748] Local variables not aligned to word boundary https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83748 Segher Boessenkool changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WORKSFORME --- Comment #7 from Segher Boessenkool --- Closing this now. This was fixed in 2013, in r205896 -- so should be fixed in 4.9 already. That commit added this to the documentation: In some cases, such as when the 'packed' attribute is applied to a structure field, it may not be possible to access the field with a single read or write that is correctly aligned for the target machine. In this case GCC falls back to generating multiple accesses rather than code that will fault or truncate the result at run time. (and also added the code to implement it; as you noticed, older compilers will do misaligned loads if you're not careful). -- You are receiving this mail because: You reported the bug.
[Bug target/85530] New: [X86] _mm512_mullox_epi64 and _mm512_mask_mullox_epi64 not implemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85530 Bug ID: 85530 Summary: [X86] _mm512_mullox_epi64 and _mm512_mask_mullox_epi64 not implemented Product: gcc Version: 7.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: craig.topper at gmail dot com Target Milestone: --- icc has these intrinsics which emulate a v8di multiply using multiple pmuludqs when avx512f is enabled, but avx512dq is not enabled. If avx512dq is enabled it uses vpmullq. I just added support to clang in r330923. Would be good if gcc could implement it too.
[Bug tree-optimization/85529] New: wrong code at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85529 Bug ID: 85529 Summary: wrong code at -O2 and -O3 on x86_64-linux-gnu Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: su at cs dot ucdavis.edu Target Milestone: --- It appears to be a recent regression. $ gcctk -v Using built-in specs. COLLECT_GCC=gcctk COLLECT_LTO_WRAPPER=/home/su/software/tmp/gcc/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/9.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto --prefix=/home/su/software/tmp/gcc/gcc-trunk --disable-bootstrap Thread model: posix gcc version 9.0.0 20180426 (experimental) [trunk revision 259666] (GCC) $ $ gcctk -Os small.c; ./a.out 1 $ gcc-7.3.0 -O2 small.c; ./a.out 1 $ $ gcctk -O2 small.c $ ./a.out 0 $ -- int printf (const char *, ...); struct S { int a; }; int b, c = 1, d, e, f; static int g; volatile struct S s; char h (char i, int j) { return i < 0 ? i : i << j; } int main () { char k = -83; if (!d) goto L; k = e || f; L: for (; b < 1; b++) s.a != (k < h (k, 2) && (c = k = g)); printf ("%d\n", c); return 0; }
[Bug rtl-optimization/85528] New: ICE in code_motion_process_successors, at sel-sched.c:6403
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85528 Bug ID: 85528 Summary: ICE in code_motion_process_successors, at sel-sched.c:6403 Product: gcc Version: unknown Status: UNCONFIRMED Keywords: ice-checking, ice-on-valid-code Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- Target: powerpc-*-linux-gnu*, powerpcspe-*-linux-gnu* gcc-8.0.0-alpha20180422 snapshot (r259553) w/ r259563 applied still ICEs when compiling the following snippet w/ -misel -O1 -frename-registers -fschedule-insns2 -fselective-scheduling2 -ftree-pre -fvar-tracking-assignments -fno-ssa-phiopt -fno-tree-ccp -fno-tree-dce -fno-tree-fre: long long int id; short int am; int sf; void qj (void) { if (id == 0) return; for (;;) { short int kq; id *= 2; kq = id; id = (kq < 3) ? sf : 0; if (id == 0) { int bp; bp = !!id || !!sf; am += bp * (!!id || !!(kq *= 2)); } else sf += id; } } % powerpc-e300c3-linux-gnu-gcc-8.0.0-alpha20180422 -misel -O1 -frename-registers -fschedule-insns2 -fselective-scheduling2 -ftree-pre -fvar-tracking-assignments -fno-ssa-phiopt -fno-tree-ccp -fno-tree-dce -fno-tree-fre -w -c sx9cnxly.c during RTL pass: sched2 sx9cnxly.c: In function 'qj': sx9cnxly.c:28:1: internal compiler error: in code_motion_process_successors, at sel-sched.c:6403 } ^ 0xc1180b code_motion_process_successors /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180422/work/gcc-8-20180422/gcc/sel-sched.c:6400 0xc1180b code_motion_path_driver /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180422/work/gcc-8-20180422/gcc/sel-sched.c:6622 0xc11269 code_motion_process_successors /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180422/work/gcc-8-20180422/gcc/sel-sched.c:6356 0xc11269 code_motion_path_driver /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180422/work/gcc-8-20180422/gcc/sel-sched.c:6622 0xc11ab5 move_op /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180422/work/gcc-8-20180422/gcc/sel-sched.c:6714 0xc11ab5 move_exprs_to_boundary /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180422/work/gcc-8-20180422/gcc/sel-sched.c:5237 0xc11ab5 schedule_expr_on_boundary /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180422/work/gcc-8-20180422/gcc/sel-sched.c:5450 0xc15b28 fill_insns /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180422/work/gcc-8-20180422/gcc/sel-sched.c:5592 0xc1796e schedule_on_fences /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180422/work/gcc-8-20180422/gcc/sel-sched.c:7366 0xc1796e sel_sched_region_2 /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180422/work/gcc-8-20180422/gcc/sel-sched.c:7504 0xc189e1 sel_sched_region_1 /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180422/work/gcc-8-20180422/gcc/sel-sched.c:7546 0xc19fd5 sel_sched_region(int) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180422/work/gcc-8-20180422/gcc/sel-sched.c:7647 0xc1a929 run_selective_scheduling() /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180422/work/gcc-8-20180422/gcc/sel-sched.c:7733 0xbf142d rest_of_handle_sched2 /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180422/work/gcc-8-20180422/gcc/sched-rgn.c:3732 0xbf142d execute /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180422/work/gcc-8-20180422/gcc/sched-rgn.c:3876
[Bug fortran/85526] [6/7/8/9 regression] ICE when calling a (pure) function from inside another pure function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85526 --- Comment #3 from Steve Kargl --- On Wed, Apr 25, 2018 at 11:33:34PM +, dominiq at lps dot ens.fr wrote: > The code compiles with 6.4.0 and 7.3.0, but not with 6.4.1, 7.3.1, > 8.0.1 and trunk (9.0). This is likely r258347 for gcc8, r258367 > for gcc7, and r258368 for gcc6. Bummer. Don't know how to fix this one. Workaround is to move checkFmt() to above its first use in another function.
[Bug fortran/85526] [6/7/8/9 regression] ICE when calling a (pure) function from inside another pure function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85526 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Known to work||6.4.0, 7.3.0 Keywords||ice-on-valid-code Last reconfirmed||2018-04-25 Ever confirmed|0 |1 Summary|[6.4 regression] calling a |[6/7/8/9 regression] ICE |(pure) function from inside |when calling a (pure) |another pure function may |function from inside |cause segmentation fault|another pure function |during compilation | Known to fail||6.4.1, 7.3.1, 8.0.1 --- Comment #2 from Dominique d'Humieres --- The code compiles with 6.4.0 and 7.3.0, but not with 6.4.1, 7.3.1, 8.0.1 and trunk (9.0). This is likely r258347 for gcc8, r258367 for gcc7, and r258368 for gcc6.
[Bug fortran/85526] [6.4 regression] calling a (pure) function from inside another pure function may cause segmentation fault during compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85526 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- Reduce test case. module fox_m_fsys_format implicit none integer, parameter :: dp=8 interface leng module procedure str_real_dp_fmt_len end interface contains pure function str_real_dp_fmt_len(x, fmt) result(n) real(dp), intent(in) :: x character(len=10), intent(in) :: fmt integer :: n if (.not.checkFmt(fmt)) then n = 0 return end if end function str_real_dp_fmt_len function str_real_dp_fmt(x, fmt) result(s) real(dp), intent(in) :: x character(len=10), intent(in) :: fmt character(len=leng(x, fmt)) :: s end function str_real_dp_fmt function checkFmt(fmt) result(good) character(len=10), intent(in) :: fmt logical good good = .true. end function checkFmt end module fox_m_fsys_format
[Bug target/85525] Alignment Issue in AVX compiler intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85525 Jonathan Wakely changed: What|Removed |Added Status|WAITING |UNCONFIRMED Ever confirmed|1 |0 --- Comment #8 from Jonathan Wakely --- Thanks for the details.
[Bug testsuite/85527] New: [openacc] atomic_capture-1.{c,f90} undefined behaviour
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85527 Bug ID: 85527 Summary: [openacc] atomic_capture-1.{c,f90} undefined behaviour Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org Target Milestone: --- I. Consider this test-case, minimized from atomic_capture-1.f90: ... program main real fgot, fexp, ftmp integer, parameter :: N = 32 fgot = 1234.0 fexp = 1266.0 !$acc parallel loop copy (fgot, ftmp) do i = 1, N !$acc atomic capture ftmp = fgot fgot = fgot + 1.0 !$acc end atomic end do !$acc end parallel loop if (ftmp /= fexp - 1.0) call abort end program main ... We write different values to the scalar ftmp in a parallel loop. So, roughtly equivalent to: ... !$acc parallel loop copy (fgot, ftmp) do i = 1, N ftmp = i end do !$acc end parallel loop ... This is undefined behaviour. If we look in atomic_capture-1.c, the equivalent loop looks like this: ... #pragma acc data copy (fgot, fdata[0:N]) { #pragma acc parallel loop for (i = 0; i < N; i++) { #pragma acc atomic capture fdata[i] = fgot++; } } if (fexp != fgot) abort (); ... So, the solution here is to write to different entries in an array. II. atomic_capture-1.c contains only a single case of checking the contents of fdata/ldata/idata: ... fgot = 1.0; fexp = 0.0; #pragma acc data copy (fgot, fdata[0:N]) { #pragma acc parallel loop for (i = 0; i < N; i++) { float expr = 32.0; #pragma acc atomic capture fdata[i] = fgot = expr - fgot; } } for (i = 0; i < N; i++) if (i % 2 == 0) { if (fdata[i] != 31.0) abort (); } else { if (fdata[i] != 1.0) abort (); } ... That was already observed to be causing problem here (https://gcc.gnu.org/ml/gcc-patches/2016-05/msg00173.html ), and was removed in this patch: ... commit 39be832ac8fb62836b54b98c118ce713a323bb2e Author: nathan Date: Fri Jan 22 22:01:33 2016 + * testsuite/libgomp.oacc-c-c++-common/atomic_capture-1.c: Don't assume atomic op ordering. * testsuite/libgomp.oacc-fortran/atomic_capture-1.f90: Likewise. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gomp-4_0-branch@232749 138bc75d-0d04-0410-961f-82ee72b054a4 ... but that's still missing on trunk. That patch also removes some of the ftmp/itmp/ltmp checks in atomic_capture-1.f90, but not the one mentioned in I. III. It may still be a good idea to check the result of fdata/idata/ldata array, but not in the order-dependent fashion that's used in the example listed at II.
[Bug target/85525] Alignment Issue in AVX compiler intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85525 --- Comment #7 from Tom Ritter --- I'm compiling some AVX code with MinGW+gcc. I'm afraid it's difficult to create a test case, but I think there's an alignment issue here. Registers at crash site: rbp is 0x00 % 20 > 0:000> r > rax=15ce306b rbx=00656930 rcx=1f1ba500 > rdx= rsi= rdi=00656440 > rip=072656fa rsp=00656bc0 rbp=00657060 > r8=1fc0f0a0 r9=0018 r10=1fc0f0a0 > r11=1f75bcff r12=00657c90 r13=000f > r14= r15= > iopl=0 nv up ei pl nz na po nc > cs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010204 > xul!XRE_GetBootstrap+0x256380a: > `072656fa c5fd7f45f0 vmovdqa ymmword ptr [rbp-10h],ymm0 > ss:`00657050=17 Disassembly: vmovdqa expects 0x20 alignment but offset by 0x10: `072356fa c5fd7f45f0 vmovdqa ymmword ptr [rbp-10h],ymm0 I've attached the disassembly. The c++ code is attached and also at: https://searchfox.org/mozilla-central/rev/36dec78aecc40539ecc8d78e91612e38810f963c/gfx/skia/skia/src/opts/SkOpts_hsw.cpp There is a function; convolve_16_pixels that corresponds to xul!XRE_GetBootstrap+0x6676510 in the attached disassembly It was pointed out that `07235595 48c1e805shr rax,5 `07235599 48c1e005shl rax,5 `0723559d 4889c3 mov rbx,rax aligns rbx at the entry to the function, so it can safely do things like vmovdqa ymmword ptr [rbx+3E0h],ymm0 However rbp does not get the same alignment treatment, and operations offset from it may not be correctly aligned.
[Bug target/85525] Alignment Issue in AVX compiler intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85525 --- Comment #6 from Tom Ritter --- Created attachment 44020 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44020&action=edit Disassembly of affected function
[Bug fortran/85526] New: [6.4 regression] calling a (pure) function from inside another pure function may cause segmentation fault during compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85526 Bug ID: 85526 Summary: [6.4 regression] calling a (pure) function from inside another pure function may cause segmentation fault during compilation Product: gcc Version: 6.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mail at pietrodelugas dot it Target Milestone: --- Created attachment 44019 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44019&action=edit fortran source file to demonstrate the bug A call to a pure function from inside a pure function crashes the compilation with this message internal compiler error: Segmentation fault the same code has been compiling regularly with gfortran up to 6.2 while it is failing in 6.4 and 7.3 versions I attach a sample source file
[Bug target/85525] Alignment Issue in AVX compiler intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85525 --- Comment #5 from Tom Ritter --- ./x86_64-w64-mingw32-g++ -v Using built-in specs. COLLECT_GCC=./x86_64-w64-mingw32-g++ COLLECT_LTO_WRAPPER=/builds/worker/workspace/build/src/mingw32/bin/../libexec/gcc/x86_64-w64-mingw32/6.4.0/lto-wrapper Target: x86_64-w64-mingw32 Configured with: ../gcc-6.4.0/configure --prefix=/tmp/tmp.G8UuS5o8Pw/tools/mingw32 --target=x86_64-w64-mingw32 --with- gnu-ld --with-gnu-as --disable-multilib --enable-threads=posix Thread model: posix gcc version 6.4.0 (GCC) /builds/worker/workspace/build/src/mingw32/bin/x86_64-w64-mingw32-g++ -mwindows -o SkOpts_hsw.o -c -I/builds/worker/workspace/build/src/obj-firefox/dist/stl_wrappers -DDEBUG=1 -DSK_JUMPER_USE_ASSEMBLY=0 -DUNICODE -D_UNICODE -DSKIA_IMPLEMENTATION=1 -DSK_PDF_USE_SFNTLY=1 -DSK_CAN_USE_DLOPEN=0 -DSTATIC_EXPORTABLE_JS_API -DMOZ_HAS_MOZGLUE -DMOZILLA_INTERNAL_API -DIMPL_LIBXUL -I/builds/worker/workspace/build/src/gfx/skia -I/builds/worker/workspace/build/src/obj-firefox/gfx/skia -I/builds/worker/workspace/build/src/gfx/skia/skia/include/c -I/builds/worker/workspace/build/src/gfx/skia/skia/include/config -I/builds/worker/workspace/build/src/gfx/skia/skia/include/core -I/builds/worker/workspace/build/src/gfx/skia/skia/include/effects -I/builds/worker/workspace/build/src/gfx/skia/skia/include/gpu -I/builds/worker/workspace/build/src/gfx/skia/skia/include/pathops -I/builds/worker/workspace/build/src/gfx/skia/skia/include/ports -I/builds/worker/workspace/build/src/gfx/skia/skia/include/private -I/builds/worker/workspace/build/src/gfx/skia/skia/include/utils -I/builds/worker/workspace/build/src/gfx/skia/skia/include/utils/mac -I/builds/worker/workspace/build/src/gfx/skia/skia/include/views -I/builds/worker/workspace/build/src/gfx/skia/skia/src/core -I/builds/worker/workspace/build/src/gfx/skia/skia/src/gpu -I/builds/worker/workspace/build/src/gfx/skia/skia/src/gpu/effects -I/builds/worker/workspace/build/src/gfx/skia/skia/src/gpu/gl -I/builds/worker/workspace/build/src/gfx/skia/skia/src/gpu/glsl -I/builds/worker/workspace/build/src/gfx/skia/skia/src/image -I/builds/worker/workspace/build/src/gfx/skia/skia/src/lazy -I/builds/worker/workspace/build/src/gfx/skia/skia/src/opts -I/builds/worker/workspace/build/src/gfx/skia/skia/src/sfnt -I/builds/worker/workspace/build/src/gfx/skia/skia/src/sksl -I/builds/worker/workspace/build/src/gfx/skia/skia/src/utils -I/builds/worker/workspace/build/src/gfx/skia/skia/src/utils/mac -I/builds/worker/workspace/build/src/gfx/skia/skia/src/utils/win -I/builds/worker/workspace/build/src/gfx/sfntly/cpp/src -I/builds/worker/workspace/build/src/obj-firefox/dist/include -I/builds/worker/workspace/build/src/obj-firefox/dist/include/nspr -I/builds/worker/workspace/build/src/obj-firefox/dist/include/nss -DMOZILLA_CLIENT -include /builds/worker/workspace/build/src/obj-firefox/mozilla-config.h -Wall -Wempty-body -Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code -Wwrite-strings -Wno-invalid-offsetof -Wduplicated-cond -Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations -Wno-error=array-bounds -Wno-error=free-nonheap-object -Wno-unknown-pragmas -Wno-unused-function -Wno-conversion-null -Wno-switch -Wno-enum-compare -fno-sized-deallocation -fno-exceptions -fno-strict-aliasing -mms-bitfields -fno-keep-inline-dllexport -fno-rtti -ffunction-sections -fdata-sections -Wa,-mbig-obj -fno-exceptions -fno-math-errno -pthread -pipe -g -fno-omit-frame-pointer -Wno-deprecated-declarations -Wno-overloaded-virtual -Wno-shadow -Wno-sign-compare -Wno-unreachable-code -Wno-unused-function -Wno-logical-op -Wno-maybe-uninitialized -MD -MP -MF .deps/SkOpts_hsw.o.pp -mavx2 /builds/worker/workspace/build/src/gfx/skia/skia/src/opts/SkOpts_hsw.cpp (There is no compiler output.)
[Bug target/85525] Alignment Issue in AVX compiler intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85525 --- Comment #4 from Tom Ritter --- Created attachment 44018 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44018&action=edit Preprocessed source file
[Bug target/85525] Alignment Issue in AVX compiler intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85525 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-04-25 Ever confirmed|0 |1 --- Comment #3 from Jonathan Wakely --- Please read https://gcc.gnu.org/bugs/ and provide the information requested there, and put the details in this report instead of a link to a pastebin.
[Bug target/85525] Alignment Issue in AVX compiler intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85525 --- Comment #2 from Tom Ritter --- (In reply to Andrew Pinski from comment #1) > What exact target is this on? Sorry, this is x64 if that's what you mean?
[Bug target/85525] Alignment Issue in AVX compiler intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85525 Andrew Pinski changed: What|Removed |Added Component|c |target --- Comment #1 from Andrew Pinski --- What exact target is this on?
[Bug c/85525] New: Alignment Issue in AVX compiler intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85525 Bug ID: 85525 Summary: Alignment Issue in AVX compiler intrinsics Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: tom at ritter dot vg CC: jacek at codeweavers dot com Target Milestone: --- I am using gcc 6.4.0 and MinGW to compile some code that uses AVX intrinsics for Windows. Specifically, this code: https://searchfox.org/mozilla-central/rev/36dec78aecc40539ecc8d78e91612e38810f963c/gfx/skia/skia/src/opts/SkOpts_hsw.cpp The crashing instruction is: vmovdqa ymmword ptr [rbp-10h],ymm0 However at this location, rbp is 0 % 0x20 and vmovdqa expects 0x20 alignment (and in the assembly offset by 0x10). We think there is a missing alignment sequence at the beginning the function (there is one for rbx, but not rbp). The full disassembly and details are at https://pastebin.mozilla.org/9083932
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #48 from John Paul Adrian Glaubitz --- (In reply to Segher Boessenkool from comment #47) > Believe it or not, but the rs6000 port maintainers *care* about older > systems. Then why is something that is still working and being used by people being deprecated? > I wanted to obsolete SPE support because it is a big burden, not in small > part > because no one maintains it. This has been going on for years and years. In what sense? Care to elaborate? I thought the codebase has already been separated out so it doesn't bother the rest of the code base. As mentioned above, it would be nice to be pointed to an actual problem the code is causing right now as-is. > Big pushback; people still want SPE, they just don't want to spend work on > it. So, does every gcc user also have to be a gcc developer? I think the number of people using gcc is magnitudes larger than the people capable of working on the gcc codebase. So I think this argument is a bit unfair. > Well neither do we, it's been enough. So I spent a week splitting off the > port > (also tested removing VSX etc.; removing unused code does not take that long; > I just have no way to *test* it so that was not included). It was agreed the > powerpcspe port would be maintained or it would be removed. Ignoring that there are people still using it. > Now a year later GCC 8 is on the horizon, and the powerpcspe port is still > not > maintained. And the RMs decided to give it *another* year: it is not removed > but merely obsoleted. Why not leave it in as long as it works and it's being used? Mark it as unsupported, broken or wontfix, but please don't remove it.
[Bug libstdc++/85472] Regex match bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85472 --- Comment #12 from Hans Åberg --- (In reply to Tim Shen from comment #11) > > The problem is that #4 has an earlier capture, making it impossible to see > > that it is left undefined later. > > I wouldn't say it's impossible. libc++ implements it correctly at a cost. > > Specifically, see > https://github.com/llvm-mirror/libcxx/blob/ > e54a22f809bc741760e39ac78444f57f06117652/include/regex#L5566. I meant the way I do it now. > > So it would be better to capture it as an > > empty string here: > > > > In the example I gave, if the transitions are marked (ignoring #2) > > 1: {a ↦ {1#3, 2#3, 3#3$4}}; > > 2: {b ↦ {2#4, 3#4}}; > > 3: {c ↦ {3#5, 2#5, 1#5, ∅#2}. > > Then in the "ac" part, 'a' in state 1 goes to 3 and gets a #3 match 'a' plus > > an empty which I have written $4. That is the idea, though. > > I'm feeling that this is going to a quadratic space complexity here. Does > "(((...((a_0)|(a_1)|(a_2)|...(a_n))...)))" if the regex expands to n > surrounding parenthesis, and n characters in the middle? Would this regex > match taking up to n^2 time, given a n-sized input string? It is all linear, in one traverse, just pick down the action form the transitions instead of the states. Both are computed when checking the forward transition for a character: I just record them. > If you think it's time and space efficiently doable, maybe you can develop a > prototype first. Yes. I will have to think about it, and report back here. > > I have though not implemented the counted repetitions A{m, n}, which I think > > usually are implemented as loops, so I do not know how that fits into the > > picture. > > It might also be helpful to think about back-references like "(a+)\1". What's this?
[Bug libstdc++/85472] Regex match bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85472 --- Comment #11 from Tim Shen --- > The problem is that #4 has an earlier capture, making it impossible to see > that it is left undefined later. I wouldn't say it's impossible. libc++ implements it correctly at a cost. Specifically, see https://github.com/llvm-mirror/libcxx/blob/e54a22f809bc741760e39ac78444f57f06117652/include/regex#L5566. > So it would be better to capture it as an > empty string here: > > In the example I gave, if the transitions are marked (ignoring #2) > 1: {a ↦ {1#3, 2#3, 3#3$4}}; > 2: {b ↦ {2#4, 3#4}}; > 3: {c ↦ {3#5, 2#5, 1#5, ∅#2}. > Then in the "ac" part, 'a' in state 1 goes to 3 and gets a #3 match 'a' plus > an empty which I have written $4. That is the idea, though. I'm feeling that this is going to a quadratic space complexity here. Does "(((...((a_0)|(a_1)|(a_2)|...(a_n))...)))" if the regex expands to n surrounding parenthesis, and n characters in the middle? Would this regex match taking up to n^2 time, given a n-sized input string? If you think it's time and space efficiently doable, maybe you can develop a prototype first. > I have though not implemented the counted repetitions A{m, n}, which I think > usually are implemented as loops, so I do not know how that fits into the > picture. It might also be helpful to think about back-references like "(a+)\1".
[Bug libstdc++/85472] Regex match bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85472 --- Comment #10 from Hans Åberg --- (In reply to Tim Shen from comment #9) > Ah with the example it's clear, thanks! You are welcome. > > The last line gives for #1 the sub-string "z" , and for #2 "aacbbbcac". > > This is not what ECMAScript produces either. for capture #2, ECMAScriptn > produces "ac", the last match of the loop. > > Think about the difference between > > (z)((a+)?(b+)?(c))* > > and > > (z)((?:(a+)?(b+)?(c))*) > > Your #2 seems to capture the second case, which is different. Yes, I thought about this difference in an earlier version that marked the start and last states only, but switched to this, because I wanted to ignore empty matches: I think though that one might mark the transitions with action numbers and capture it that way (see below). > > For > > #3 "a", and for #5 "c". But #4 is missing, indication there is no match. So > > there might be problem here, as there are earlier matches: > > > > Perhaps the intent is that it should be implemented as a loop, only > > retaining the last #4, > > That's what the implementations (boost, libstdc++, python) actually do. > That's not ECMAScript's intention. ECMAScript's intention is to leave #4 > undefined (*not* retaining the last non-empty #4), as in the last iteration > of the loop, #4 (b+)? doesn't match any sub-string. The problem is that #4 has an earlier capture, making it impossible to see that it is left undefined later. So it would be better to capture it as an empty string here: In the example I gave, if the transitions are marked (ignoring #2) 1: {a ↦ {1#3, 2#3, 3#3$4}}; 2: {b ↦ {2#4, 3#4}}; 3: {c ↦ {3#5, 2#5, 1#5, ∅#2}. Then in the "ac" part, 'a' in state 1 goes to 3 and gets a #3 match 'a' plus an empty which I have written $4. That is the idea, though. > > but the problem is that that is not what the > > underlying theory says. > > I'm not sure if there is any theory around caputring groups. If we are about > to create one, be aware that there are multiple plausible definitions. I have though not implemented the counted repetitions A{m, n}, which I think usually are implemented as loops, so I do not know how that fits into the picture.
[Bug c++/85523] Add fix-it hint for missing return statement in assignment operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85523 --- Comment #4 from David Malcolm --- Note to self: this came out of this ML thread: https://gcc.gnu.org/ml/gcc/2018-04/msg00168.html
[Bug c++/85523] Add fix-it hint for missing return statement in assignment operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85523 --- Comment #3 from David Malcolm --- Note to self: test coverage should also verify += and so on.
[Bug middle-end/85524] Strange cbrt() result on linux in C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85524 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c |middle-end Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- This is 1ulp difference. This is a standard issue with floating point; please read "what every computer scientist should know about floating-point arithmetic". The first case is the result from libm (which in Linux case comes from glibc project) and in the second case, GCC constants folds the cbrt and gets an exact result.
[Bug c/85524] New: Strange cbrt() result on linux in C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85524 Bug ID: 85524 Summary: Strange cbrt() result on linux in C Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: toto852 at courriel dot fr.nf Target Milestone: --- This behavior strange. It meets on different version of gcc linux. #include #include #include int main() { double nb = 56623104; double v1 = cbrt(nb); printf("v1 -> %.15f\n",v1); double v2 = cbrt((double) 56623104); printf("v2 -> %.15f\n",v2); } Compilation : gcc test.c -o test -lm && ./test Result : v1 -> 384.057 v2 -> 384.000
[Bug target/85473] internal compiler error: in emit_move_insn, at expr.c:3722
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85473 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |8.0 --- Comment #6 from H.J. Lu --- Fixed for GCC 8.
[Bug c++/85523] Add fix-it hint for missing return statement in assignment operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85523 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-04-25 Ever confirmed|0 |1 --- Comment #2 from Jonathan Wakely --- With that patch -fdiagnostics-generate-patch produces: ret.cc: In member function 'X& X::operator=(const X&)': ret.cc:2:28: warning: no return statement in function returning non-void [-Wreturn-type] X& operator=(const X&) { } // show fix-it ^ ret.cc:2:28: note: assignment operators usually return *this X& operator=(const X&) { } // show fix-it ^ return *this; ret.cc: In member function 'int Y::operator=(int)': ret.cc:7:24: warning: no return statement in function returning non-void [-Wreturn-type] int operator=(int) { } // no fix-it here, just a -Wreturn-type warning ^ ret.cc: In member function 'Z& Z::operator=(const Z&)': ret.cc:13:3: warning: no return statement in function returning non-void [-Wreturn-type] } // show fix-it ^ ret.cc:13:3: note: assignment operators usually return *this } // show fix-it ^ return *this; --- ret.cc +++ ret.cc @@ -1,5 +1,5 @@ struct X { - X& operator=(const X&) { } // show fix-it + X& operator=(const X&) { return *this;} // show fix-it }; struct Y { @@ -10,7 +10,7 @@ struct Z { Z& operator=(const Z& z) { i = z.i; - } // show fix-it + return *this;} // show fix-it int i; }; On IRC Dave said: to do it right, should handle both single-line and multiline methods and indent to match that of nearby code; see that add_newline_fixit_with_indentation from https://gcc.gnu.org/ml/gcc-patches/2017-05/msg00334.html probably a trailing space for the single-line case
[Bug c++/85523] Add fix-it hint for missing return statement in assignment operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85523 --- Comment #1 from Jonathan Wakely --- Created attachment 44017 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44017&action=edit Proof-of-concept patch to add fix-it
[Bug c++/85523] New: Add fix-it hint for missing return statement in assignment operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85523 Bug ID: 85523 Summary: Add fix-it hint for missing return statement in assignment operators Product: gcc Version: 8.0 Status: UNCONFIRMED Keywords: diagnostic Severity: enhancement Priority: P3 Component: c++ Assignee: dmalcolm at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Target Milestone: --- As discussed at https://gcc.gnu.org/ml/gcc/2018-04/msg00170.html we could offer fix-it hints for cases like: struct X { X& operator=(const X&) { } // show fix-it }; struct Y { void operator=(const Y&) { } int operator=(int) { } // no fix-it here, just a -Wreturn-type warning }; struct Z { Z& operator=(const Z& z) { i = z.i; } // show fix-it int i; };
[Bug libstdc++/85472] Regex match bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85472 --- Comment #9 from Tim Shen --- Ah with the example it's clear, thanks! > The last line gives for #1 the sub-string "z" , and for #2 "aacbbbcac". This is not what ECMAScript produces either. for capture #2, ECMAScriptn produces "ac", the last match of the loop. Think about the difference between (z)((a+)?(b+)?(c))* and (z)((?:(a+)?(b+)?(c))*) Your #2 seems to capture the second case, which is different. > For > #3 "a", and for #5 "c". But #4 is missing, indication there is no match. So > there might be problem here, as there are earlier matches: > > Perhaps the intent is that it should be implemented as a loop, only > retaining the last #4, That's what the implementations (boost, libstdc++, python) actually do. That's not ECMAScript's intention. ECMAScript's intention is to leave #4 undefined (*not* retaining the last non-empty #4), as in the last iteration of the loop, #4 (b+)? doesn't match any sub-string. > but the problem is that that is not what the > underlying theory says. I'm not sure if there is any theory around caputring groups. If we are about to create one, be aware that there are multiple plausible definitions.
[Bug target/85473] internal compiler error: in emit_move_insn, at expr.c:3722
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85473 --- Comment #5 from hjl at gcc dot gnu.org --- Author: hjl Date: Wed Apr 25 17:31:20 2018 New Revision: 259654 URL: https://gcc.gnu.org/viewcvs?rev=259654&root=gcc&view=rev Log: x86: Correct movdir64b builtin function gcc/ChangeLog: Backport from mainline 2018-04-25 Sebastian Peryt PR target/85473 * config/i386/i386.c (ix86_expand_builtin): Change memory operand to XI, extend p0 to Pmode. * config/i386/i386.md: Change unspec volatile and operand 1 mode to XI, change operand 0 mode to P. gcc/testsuite/ChangeLog: Backport from mainline 2018-04-25 Sebastian Peryt PR target/85473 * gcc.target/i386/pr85473-1.c: New test. * gcc.target/i386/pr85473-2.c: New test. Added: branches/gcc-8-branch/gcc/testsuite/gcc.target/i386/pr85473-1.c branches/gcc-8-branch/gcc/testsuite/gcc.target/i386/pr85473-2.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/config/i386/i386.c branches/gcc-8-branch/gcc/config/i386/i386.md branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug libstdc++/85517] std::variant exception safety problems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85517 Matt Calabrese changed: What|Removed |Added CC||metaprogrammingtheworld@gma ||il.com --- Comment #2 from Matt Calabrese --- Example copy-assign non-compliance: // #include struct bar { bar() noexcept = default; bar(bar&&) { /*never throws, but not noexcept*/ } bar(bar const&) // A copy constructor that throws. { throw 0; } bar& operator=(bar&&) noexcept = default; bar& operator=(bar const&) noexcept = default; }; int main() { std::variant v1, v2 = bar(); try { v1 = v2; } catch( int ) { return 0; } return 1; }
[Bug libstdc++/85517] std::variant exception safety problems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85517 Ville Voutilainen changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-04-25 CC||ville.voutilainen at gmail dot com Assignee|unassigned at gcc dot gnu.org |ville.voutilainen at gmail dot com Ever confirmed|0 |1 --- Comment #1 from Ville Voutilainen --- Mine.
[Bug target/85434] Address of stack protector guard spilled to stack on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85434 --- Comment #9 from Thomas Preud'homme --- Managed to reach a state where nothing is spilled on the stack for Thumb-1 either. I want to do 3 more changes before I start full testing: - put some compiler barrier between address computation and canari setting / canari check to ensure no instruction is scheduled between the two - clarify in documentation that it's the target's responsability to ensure guard's address computation is not CSE (in particular for PIC access) - tighten scan pattern for testcase a bit more
[Bug tree-optimization/85509] fails to promote local static to const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85509 --- Comment #5 from ASA --- > > I would expect this is likely true for any non-const static duration > > function pointer, not just the case when the auto type specifier is used, > > but I have not confirmed it. > > But it is the case for any non-const static duration function pointer. > This has nothing to do with 'auto', changing the testcase to > > static inline bool > RunTest( void ) { > static bool (*PerformQuickly)(int &, const int &) = Perform< SumQuickly > >; > static bool (*PerformSafely)(int &, const int &) = Perform< SumSafely >; > int i = 0; > return PerformQuickly( i, 1 ) && !PerformSafely( i, INT_MAX ); > } > > has no effect. Which is exactly what I stated I would have expected. Thank you for the confirmation of that expectation, though very oddly worded.
[Bug target/85401] segfault building code for VAX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85401 --- Comment #4 from Martin Husemann --- The costs are missing for various modes: (gdb) p (default_target_ira_int->x_ira_register_move_cost) $6 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x7f7ff7b8c8b0, 0x7f7ff7b8c8b0, 0x0 } (that is: only HImode and SImode costs are available)
[Bug target/85401] segfault building code for VAX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85401 --- Comment #3 from Martin Husemann --- Indeed. Digging a bit with gdb (but in our local 6.4 version) shows: #0 0x009fa7be in allocno_copy_cost_saving (allocno=0x7f7ff679a178, hard_regno=11) at /usr/src/tools/gcc/../../external/gpl3/gcc/dist/gcc/ira-color.c:2763 2763 cost += cp->freq * ira_register_move_cost[allocno_mode][rclass][rclass]; (gdb) p (default_target_ira_int->x_ira_register_move_cost)[allocno_mode] $5 = (move_table *) 0x0 Where is that table supposed to be setup?
[Bug rtl-optimization/85522] ICE: in model_update_limit_points_in_group, at haifa-sched.c:1985 with -O2 -ftracer --param=max-sched-extend-regions-iters=5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85522 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-04-25 CC||ktkachov at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from ktkachov at gcc dot gnu.org --- Confirmed.
[Bug middle-end/51677] don't suggest giving main() __attribute__((const))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51677 --- Comment #4 from Eric Gallager --- (In reply to Martin Sebor from comment #3) > It should be easy to white-list the main function in the > -Wsuggest-attribute= checker. At the same time, I'm not sure it's necessary > or that the problem is unique to main. The reasons noted in comment #0 > apply to other functions as well. Defining empty functions is useful for a > variety of reasons (e.g., default no-op handlers or, in C++, default no-op > implementations of virtual functions). Similarly, without perfect data flow > analysis across the whole program it's impossible to tell whether an extern > function is ever called. Why should main be treated differently from those? Because it's an easy first step that doesn't require doing all of those extra data flow analyses
[Bug other/63613] dejagnu.h needs to be fix included
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63613 --- Comment #12 from Eric Gallager --- (In reply to David Malcolm from comment #11) > Patch posted as https://gcc.gnu.org/ml/gcc-patches/2014-12/msg00468.html Does this still apply?
[Bug c/49702] Undefined static functions resolve to external definitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49702 Eric Gallager changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=19315 --- Comment #3 from Eric Gallager --- Possibly related: bug 19315? (both cases of statics becoming externs; that for variables, this for functions)
[Bug middle-end/85414] [8 Regression] ICE: in ix86_expand_prologue, at config/i386/i386.c:13810 with -Og -fgcse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85414 --- Comment #6 from Jakub Jelinek --- Author: jakub Date: Wed Apr 25 13:10:01 2018 New Revision: 259649 URL: https://gcc.gnu.org/viewcvs?rev=259649&root=gcc&view=rev Log: PR middle-end/85414 * simplify-rtx.c (simplify_unary_operation_1) : Pass SUBREG_REG (op) rather than op to gen_lowpart_no_emit. Modified: trunk/gcc/ChangeLog trunk/gcc/expr.c trunk/gcc/simplify-rtx.c
[Bug target/85401] segfault building code for VAX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85401 Thomas Preud'homme changed: What|Removed |Added Status|ASSIGNED|UNCONFIRMED CC||m...@3am-software.com Assignee|thopre01 at gcc dot gnu.org|unassigned at gcc dot gnu.org Ever confirmed|1 |0 --- Comment #2 from Thomas Preud'homme --- Actually given where the fault occurs this does not seem to be related to bswap. Might be a missing pattern or cost in the vax backend.
[Bug c/36941] gcc does not reject invalid cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36941 Eric Gallager changed: What|Removed |Added Keywords||accepts-invalid, diagnostic CC||joseph at codesourcery dot com --- Comment #8 from Eric Gallager --- (In reply to Eric Gallager from comment #7) > (In reply to Chris Lattner from comment #0) > > GCC accepts: > > extern struct S x; > > void foo() { (void)x; } > > > > But correctly rejects: > > > > extern struct S x; > > void foo() { x; } > > > > Confirmed. Note that clang diagnoses the first one like this: > > $ /sw/opt/llvm-3.1/bin/clang-3.1 -c 36941.c > 36941.c:2:20: error: incomplete type 'struct S' where a complete type is > required > void foo() { (void)x; } >^ > 36941.c:1:15: note: forward declaration of 'struct S' > extern struct S x; > ^ Same thing with a newer version of clang (5.0). Assuming that since clang still rejects this that this is an accepts-invalid for gcc.
[Bug libstdc++/85472] Regex match bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85472 --- Comment #8 from Hans Åberg --- (In reply to Tim Shen from comment #5) > I'm not following the meaning of "action number" and "the partial reverse > NFA is recorded". > > How many actions numbers are recorded? for regex_match(s, regex(re)), is it > on the order of O(s.size()), or O(re.size())? The goal is to allocate > O(re.size()) of memory exactly once. Let's check the OP example, to see if it is useful, which will also explain the action numbers. So for regex '(z)((a+)?(b+)?(c))*', I used '(z)(a*b*(c))*' with action numbers same as in the C++ library numbering. Here they are written out with # in the NFA: ex = ({0}, {0, 3}, {0: {z ↦ {1, ∅}}[#1];1: {a ↦ {1, 2, 3}}[#2#3]; 2: {b ↦ {2, 3}}[#2#4]; 3: {c ↦ {3, 2, 1, ∅}}[#2#5]}, {}) with start set {0}, and set of last (pointing to a final state ∅) states {0, 3}. (The last {} is the not yet computed DFA.) Then lexing: > zaacbbbcac Full string is a valid match! Matches: {zaacbbbcac, [@0@3@7@9]; [#1] [#1][#2#3][#2#3][#2#5] [#1][#2#3][#2#3][#2#5][#2#4][#2#4][#2#4][#2#5] [#1][#2#3][#2#3][#2#5][#2#4][#2#4][#2#4][#2#5][#2#3][#2#5] } Time: 0.000555 s. Each line gives the action numbers for the string positions for the successive strings z, zaac, zaacbbbc, zaacbbbcac with final string positions @0, @3, @7, @9. The last line gives for #1 the sub-string "z" , and for #2 "aacbbbcac". For #3 "a", and for #5 "c". But #4 is missing, indication there is no match. So there might be problem here, as there are earlier matches: Perhaps the intent is that it should be implemented as a loop, only retaining the last #4, but the problem is that that is not what the underlying theory says.
[Bug c/37200] duplicate warning message with braced initializer list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37200 Eric Gallager changed: What|Removed |Added Status|NEW |WAITING --- Comment #3 from Eric Gallager --- (In reply to Eric Gallager from comment #2) > Confirmed that gcc still prints 2 warnings for the testcase. It's necessary > to set the standard manually to c89 or gnu89 now that GCC defaults to > -std=gnu11. Now that GCC has carets for its diagnostics, we can see that the > 2 warnings actually point to different places: > > $ /usr/local/bin/gcc -c -std=gnu89 -pedantic 37200.c > 37200.c: In function ‘foo’: > 37200.c:10:11: warning: initializer element is not computable at load time > [-Wpedantic] >{ (void**) &x->tst } >^ > 37200.c:10:3: warning: initializer element is not computable at load time > [-Wpedantic] >{ (void**) &x->tst } >^ > > So are they still actually duplicates? WAITING on a response to this.
[Bug target/85473] internal compiler error: in emit_move_insn, at expr.c:3722
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85473 --- Comment #4 from speryt at gcc dot gnu.org --- Author: speryt Date: Wed Apr 25 12:39:57 2018 New Revision: 259648 URL: https://gcc.gnu.org/viewcvs?rev=259648&root=gcc&view=rev Log: 2018-04-25 Sebastian Peryt gcc/ChangeLog: PR target/85473 * config/i386/i386.c (ix86_expand_builtin): Change memory operand to XI, extend p0 to Pmode. * config/i386/i386.md: Change unspec volatile and operand 1 mode to XI, change operand 0 mode to P. gcc/testsuite/ChangeLog: PR target/85473 * gcc.target/i386/pr85473-1.c: New test. * gcc.target/i386/pr85473-2.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr85473-1.c trunk/gcc/testsuite/gcc.target/i386/pr85473-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/i386.md trunk/gcc/testsuite/ChangeLog
[Bug target/85401] segfault building code for VAX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85401 Thomas Preud'homme changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-04-25 Ever confirmed|0 |1
[Bug target/85519] [nvptx, openacc, openmp, testsuite] Recursive tests may fail due to thread stack limit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85519 Tom de Vries changed: What|Removed |Added Keywords||openacc, openmp, patch Severity|normal |trivial --- Comment #2 from Tom de Vries --- https://gcc.gnu.org/ml/gcc-patches/2018-04/msg01122.html
[Bug target/84923] [8/9 regression] gcc.dg/attr-weakref-1.c failed on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84923 --- Comment #5 from Richard Biener --- So in spirit of the comment#2 patch I'd propose Index: gcc/varasm.c === --- gcc/varasm.c(revision 259638) +++ gcc/varasm.c(working copy) @@ -5641,7 +5641,8 @@ weak_finish (void) tree alias_decl = TREE_PURPOSE (t); tree target = ultimate_transparent_alias_target (&TREE_VALUE (t)); - if (! TREE_SYMBOL_REFERENCED (DECL_ASSEMBLER_NAME (alias_decl))) + if (! TREE_SYMBOL_REFERENCED (DECL_ASSEMBLER_NAME (alias_decl)) + || TREE_SYMBOL_REFERENCED (target)) /* Remove alias_decl from the weak list, but leave entries for the target alone. */ target = NULL_TREE; given do_assemble_alias skips the weak_finish part if TREE_SYMBOL_REFERENCED (target) and thus will not end up removing target from the alias list. The above makes both paths match.
[Bug libstdc++/85472] Regex match bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85472 --- Comment #7 from Hans Åberg --- (In reply to Tim Shen from comment #5) > (In reply to Hans Åberg from comment #4) > > I wrote an NFA/DFA that computes all matches, it seems, in an efficient > > manner: Action numbers are marked on the states of the sub-NFAs one is > > interested in. While lexing a string, the partial reverse NFA is recorded, > > which is searched when a final state is encountered. The string position > > action numbers, as marked on the corresponding states, are recorded, and for > > each action number, the contiguous string sequences are the possible > > submatches. > > I'm not following the meaning of "action number"... Arbitrary numbers used identify the sub-automatons; in the C++ library, the number of left parentheses in the regex expression from which it derives. > ...and "the partial reverse > NFA is recorded". The lexing states are sets of NFA states, which are also the DFA states. If a lexing character c in the state p = {p_0, ...} has transition p_i -> {q_0, ...}, the reverse state q_0 -> {r_0, ...} gets p_i added at this position in the string. This is to record the states which c actually uses. > How many actions numbers are recorded? They are sets, both in the states and the string matches. Each final state position in the string produces a separate match, containing information about the submatches via the action numbers. > for regex_match(s, regex(re)), is it > on the order of O(s.size()), or O(re.size())? The goal is to allocate > O(re.size()) of memory exactly once. The action numbers are just stamped onto the NFA states when it is created, and then carried along. So it is the same as the number of states in the NFA. When a string is lexed, one just gets the action numbers for each position that produced a character match.
[Bug libstdc++/85472] Regex match bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85472 --- Comment #6 from Hans Åberg --- (In reply to Tim Shen from comment #5) > (In reply to Hans Åberg from comment #4) > > I wrote an NFA/DFA that computes all matches, it seems, in an efficient > > manner: Action numbers are marked on the states of the sub-NFAs one is > > interested in. While lexing a string, the partial reverse NFA is recorded, > > which is searched when a final state is encountered. The string position > > action numbers, as marked on the corresponding states, are recorded, and for > > each action number, the contiguous string sequences are the possible > > submatches. > > I'm not following the meaning of "action number"... Arbitrary numbers used identify the sub-automatons; in the C++ library, the number of left parentheses in the regex expression from which it derives. > ...and "the partial reverse > NFA is recorded". The lexing states are sets of NFA states, which are also the DFA states. If a lexing character c in the state p = {p_0, ...} has transition p_i -> {q_0, ...}, the reverse state q_0 -> {r_0, ...} gets p_i added at this position in the string. This is to record the states which c actually uses. > How many actions numbers are recorded? They are sets, both in the states and the string matches. Each final state position in the string produces a separate match, containing information about the submatches via the action numbers. > for regex_match(s, regex(re)), is it > on the order of O(s.size()), or O(re.size())? The goal is to allocate > O(re.size()) of memory exactly once. The action numbers are just stamped onto the NFA states when it is created, and then carried along. So it is the same as the number of states in the NFA. When a string is lexed, one just gets the action numbers for each position that produced a character match.
[Bug rtl-optimization/85522] New: ICE: in model_update_limit_points_in_group, at haifa-sched.c:1985 with -O2 -ftracer --param=max-sched-extend-regions-iters=5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85522 Bug ID: 85522 Summary: ICE: in model_update_limit_points_in_group, at haifa-sched.c:1985 with -O2 -ftracer --param=max-sched-extend-regions-iters=5 Product: gcc Version: 8.0.1 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: aarch64-unknown-linux-gnu Created attachment 44016 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44016&action=edit reduced testcase Compiler output: $ aarch64-unknown-linux-gnu-gcc -O2 -ftracer --param=max-sched-extend-regions-iters=5 testcase.c during RTL pass: sched1 testcase.c: In function 'foo': testcase.c:11:1: internal compiler error: in model_update_limit_points_in_group, at haifa-sched.c:1985 } ^ 0x149b095 model_update_limit_points_in_group /repo/gcc-trunk/gcc/haifa-sched.c:1985 0x149b095 model_update_limit_points /repo/gcc-trunk/gcc/haifa-sched.c:1996 0x149b095 schedule_insn /repo/gcc-trunk/gcc/haifa-sched.c:4080 0x149d64c schedule_block(basic_block_def**, void*) /repo/gcc-trunk/gcc/haifa-sched.c:6871 0xc25e5a schedule_region /repo/gcc-trunk/gcc/sched-rgn.c:3177 0xc25e5a schedule_insns() /repo/gcc-trunk/gcc/sched-rgn.c:3516 0xc26283 schedule_insns() /repo/gcc-trunk/gcc/sched-rgn.c:3501 0xc26283 rest_of_handle_sched /repo/gcc-trunk/gcc/sched-rgn.c:3720 0xc26283 execute /repo/gcc-trunk/gcc/sched-rgn.c:3828 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ aarch64-unknown-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-aarch64/bin/aarch64-unknown-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-259628-checking-yes-rtl-df-extra-aarch64/bin/../libexec/gcc/aarch64-unknown-linux-gnu/8.0.1/lto-wrapper Target: aarch64-unknown-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --with-sysroot=/usr/aarch64-unknown-linux-gnu --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=aarch64-unknown-linux-gnu --with-ld=/usr/bin/aarch64-unknown-linux-gnu-ld --with-as=/usr/bin/aarch64-unknown-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-259628-checking-yes-rtl-df-extra-aarch64 Thread model: posix gcc version 8.0.1 20180425 (experimental) (GCC)
[Bug target/84923] [8/9 regression] gcc.dg/attr-weakref-1.c failed on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84923 --- Comment #4 from Ramana Radhakrishnan --- (In reply to Richard Biener from comment #3) > For x86_64 if I append > > const int *dat[] = { &Wv12, &wv12 }; > > the testcase links fine irrespective of where I place the > > .weakrefWv12,wv12 > .weak wv12 > > assembler declarations. > > When I look at the assembler generated by a cross from x86_64 I do not > see any .weak wv12 directive which is likely the issue. Yep, the .weak wv12 directive is the one that disappears. Putting that back in by hand fixes the issue.
[Bug target/84923] [8/9 regression] gcc.dg/attr-weakref-1.c failed on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84923 --- Comment #3 from Richard Biener --- For x86_64 if I append const int *dat[] = { &Wv12, &wv12 }; the testcase links fine irrespective of where I place the .weakrefWv12,wv12 .weak wv12 assembler declarations. When I look at the assembler generated by a cross from x86_64 I do not see any .weak wv12 directive which is likely the issue.
[Bug sanitizer/84307] asan blocks dead-store elimination
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84307 --- Comment #5 from Jakub Jelinek --- Author: jakub Date: Wed Apr 25 10:02:24 2018 New Revision: 259641 URL: https://gcc.gnu.org/viewcvs?rev=259641&root=gcc&view=rev Log: PR sanitizer/84307 * c-decl.c (build_compound_literal): Call pushdecl (decl) even when it is not TREE_STATIC. * c-typeck.c (c_mark_addressable) : Mark not just the COMPOUND_LITERAL_EXPR node itself addressable, but also its COMPOUND_LITERAL_EXPR_DECL. Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-decl.c trunk/gcc/c/c-typeck.c
[Bug ada/85007] -b flag to gnatlink not recognized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85007 --- Comment #17 from Eric Botcazou --- Author: ebotcazou Date: Wed Apr 25 10:01:55 2018 New Revision: 259640 URL: https://gcc.gnu.org/viewcvs?rev=259640&root=gcc&view=rev Log: PR ada/85007 * gnat_ugn.texi: Regenerate. Modified: branches/gcc-8-branch/gcc/ada/ChangeLog branches/gcc-8-branch/gcc/ada/gnat_ugn.texi
[Bug ada/85007] -b flag to gnatlink not recognized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85007 --- Comment #16 from Eric Botcazou --- Author: ebotcazou Date: Wed Apr 25 10:01:13 2018 New Revision: 259639 URL: https://gcc.gnu.org/viewcvs?rev=259639&root=gcc&view=rev Log: PR ada/85007 * gnat_ugn.texi: Regenerate. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/gnat_ugn.texi
[Bug target/84923] [8/9 regression] gcc.dg/attr-weakref-1.c failed on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84923 Richard Biener changed: What|Removed |Added Component|c |target Known to work||7.3.1 Target Milestone|--- |8.0 Summary|[8 regression] |[8/9 regression] |gcc.dg/attr-weakref-1.c |gcc.dg/attr-weakref-1.c |failed on aarch64 |failed on aarch64
[Bug target/68256] Defining TARGET_USE_CONSTANT_BLOCKS_P causes go bootstrap failure on aarch64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68256 --- Comment #12 from Ramana Radhakrishnan --- (In reply to Steve Ellcey from comment #11) > FYI: This caused a regression on aarch64. > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84923 I have marked 84923 as an 8 regression as it wasn't done earlier and probably slipped in the cracks. The regression was noticed and a patch was posted but it appears that this wasn't reviewed. Ramana
[Bug libstdc++/85472] Regex match bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85472 --- Comment #5 from Tim Shen --- (In reply to Hans Åberg from comment #4) > (In reply to Tim Shen from comment #1) > > I know exactly how libc++ produces this result. It creates an empty > > match_result during each repetition ("*" operator). It's less confusing but > > much slower. > > I wrote an NFA/DFA that computes all matches, it seems, in an efficient > manner: Action numbers are marked on the states of the sub-NFAs one is > interested in. While lexing a string, the partial reverse NFA is recorded, > which is searched when a final state is encountered. The string position > action numbers, as marked on the corresponding states, are recorded, and for > each action number, the contiguous string sequences are the possible > submatches. I'm not following the meaning of "action number" and "the partial reverse NFA is recorded". How many actions numbers are recorded? for regex_match(s, regex(re)), is it on the order of O(s.size()), or O(re.size())? The goal is to allocate O(re.size()) of memory exactly once.
[Bug libstdc++/85472] Regex match bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85472 --- Comment #4 from Hans Åberg --- (In reply to Tim Shen from comment #1) > I know exactly how libc++ produces this result. It creates an empty > match_result during each repetition ("*" operator). It's less confusing but > much slower. I wrote an NFA/DFA that computes all matches, it seems, in an efficient manner: Action numbers are marked on the states of the sub-NFAs one is interested in. While lexing a string, the partial reverse NFA is recorded, which is searched when a final state is encountered. The string position action numbers, as marked on the corresponding states, are recorded, and for each action number, the contiguous string sequences are the possible submatches.
[Bug libstdc++/85472] Regex match bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85472 --- Comment #3 from Tim Shen --- Conclusively, yes it is a bug, but it is hard to fix without regressing normal case performance.
[Bug target/85519] [nvptx, openacc, openmp, testsuite] Recursive tests may fail due to thread stack limit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85519 --- Comment #1 from Tom de Vries --- (In reply to Tom de Vries from comment #0) > All these solutions work until the next failure shows up. It would be nice > to fix this more definitely in some way, but I'm not sure how. We could try to figure out the frame size of the recursive function. Using GOMP_DEBUG=1 we see the JIT compile/link log: ... Link log warning : Stack size for entry function 'main$_omp_fn$0' cannot be statically determined info: 0 bytes gmem info: Function properties for 'main$_omp_fn$0': info: used 8 registers, 0 stack, 0 bytes smem, 328 bytes cmem[0], 0 bytes lmem ... but the stack size is only shown for the offloading region, not for individual functions. Using GOMP_NVPTX_SAVE_TEMPS=1 we could get the cubin, and dump the resource usage: ... $ cuobjdump -res-usage gomp-nvptx.*.cubin Resource usage: Common: GLOBAL:0 Function rec: REG:8 STACK:0 SHARED:0 LOCAL:0 TEXTURE:0 SURFACE:0 SAMPLER:0 Function main$_omp_fn$0: REG:8 STACK:UNKNOWN SHARED:0 LOCAL:0 CONSTANT[0]:328 TEXTURE:0 SURFACE:0 SAMPLER:0 ... but the STACK entry for rec shows up as 0. Finally, using nvdisasm (or GOMP_NVPTX_DISASM=1) we find the info: ... $ nvdisasm gomp-nvptx.*.cubin //- nvinfo : EIATTR_FRAME_SIZE .align 4 /**/.byte 0x04, 0x11 /*0002*/.short (.L_6 - .L_5) .align 4 .L_5: /*0004*/.word index@(rec) /*0008*/.word 0x0010 //- nvinfo : EIATTR_FRAME_SIZE .align 4 .L_6: /*000c*/.byte 0x04, 0x11 /*000e*/.short (.L_8 - .L_7) .align 4 .L_7: /*0010*/.word index@(main$_omp_fn$0) /*0014*/.word 0x //- nvinfo : EIATTR_MIN_STACK_SIZE .align 4 .L_8: /*0018*/.byte 0x04, 0x12 /*001a*/.short (.L_10 - .L_9) .align 4 .L_9: /*001c*/.word index@(main$_omp_fn$0) /*0020*/.word 0x .L_10: ... So, we could write some tcl function to get the frame size for a function, and xfail or skip the test if the frame size is bigger that given constant x, but AFAIK dejagnu is not setup for this. The best we could do is to add a dg-final check and emit a: ... PASS: rec.c dg-nvptx-frame-size-check main$_omp_fn$0 0 FAIL: rec.c dg-nvptx-frame-size-check rec 8 ... Or, going for a more precise check: ... FAIL: rec.c dg-nvptx-stack-size-check main$_omp_fn$0,rec=65 (peak stack size 1048 is larger than stack size limit 1024) ... where you then check that frame-size (main$_omp_fn$0) + 65 * frame-size (rec) < udaThreadGetLimit(&size, cudaLimitStackSize)). Presumably formulating the peak stack composition gets more involved with openmp test cases which have a more complicated call stack.
[Bug libstdc++/85472] Regex match bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85472 --- Comment #2 from Tim Shen --- My bad, I didn't realize that "(z)((a+)?(b+)?(c))*" is exactly an example described in ECMAScript third edition 15.10.2.5. Therefore libstdc++ is not conforming.
[Bug libstdc++/85472] Regex match bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85472 Tim Shen changed: What|Removed |Added CC||timshen at gcc dot gnu.org --- Comment #1 from Tim Shen --- As I cross checked, boost 1.66, libstdc++, and python3 have the same behavior, only libc++ is different from the rest. I haven't checked the ECMAScript spec, but I suspect that it describes the boost/libstdc++/python behavior, only because it's more efficient, not less confusing. I know exactly how libc++ produces this result. It creates an empty match_result during each repetition ("*" operator). It's less confusing but much slower.
[Bug lto/85405] [6 Regression] ICE in odr_types_equivalent_p, at ipa-devirt.c:1581
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85405 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||6.4.1 Resolution|--- |FIXED Known to fail|6.4.1 | --- Comment #10 from Martin Liška --- Fixed.
[Bug lto/85405] [6 Regression] ICE in odr_types_equivalent_p, at ipa-devirt.c:1581
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85405 --- Comment #9 from Martin Liška --- Author: marxin Date: Wed Apr 25 07:41:44 2018 New Revision: 259634 URL: https://gcc.gnu.org/viewcvs?rev=259634&root=gcc&view=rev Log: Backport r259431 2018-04-25 Martin Liska Backport from mainline 2018-04-17 Martin Liska PR lto/85405 * ipa-devirt.c (odr_types_equivalent_p): Remove trailing in message, remote space in between '_G' and '('. Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/ipa-devirt.c
[Bug lto/85248] [6 Regression] Miscompilation when using error function that returns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85248 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||6.4.1 Resolution|--- |FIXED Known to fail|6.4.0 | --- Comment #17 from Martin Liška --- Fixed.
[Bug lto/85405] [6 Regression] ICE in odr_types_equivalent_p, at ipa-devirt.c:1581
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85405 --- Comment #8 from Martin Liška --- Author: marxin Date: Wed Apr 25 07:41:25 2018 New Revision: 259633 URL: https://gcc.gnu.org/viewcvs?rev=259633&root=gcc&view=rev Log: Backport r259429 2018-04-25 Martin Liska Backport from mainline 2018-04-17 Jan Hubicka PR lto/85405 * ipa-devirt.c (odr_types_equivalent_p): Handle bit fields. Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/ipa-devirt.c
[Bug lto/85248] [6 Regression] Miscompilation when using error function that returns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85248 --- Comment #16 from Martin Liška --- Author: marxin Date: Wed Apr 25 07:40:46 2018 New Revision: 259632 URL: https://gcc.gnu.org/viewcvs?rev=259632&root=gcc&view=rev Log: Backport r259274 2018-04-25 Martin Liska Backport from mainline 2018-04-10 Martin Liska PR lto/85248 * lto-symtab.c (lto_symtab_merge_p): Do not check for TREE_VALUES of error attributes. Modified: branches/gcc-6-branch/gcc/lto/ChangeLog branches/gcc-6-branch/gcc/lto/lto-symtab.c
[Bug lto/85248] [6 Regression] Miscompilation when using error function that returns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85248 --- Comment #15 from Martin Liška --- Author: marxin Date: Wed Apr 25 07:40:27 2018 New Revision: 259631 URL: https://gcc.gnu.org/viewcvs?rev=259631&root=gcc&view=rev Log: Backport r259265 2018-04-25 Martin Liska Backport from mainline 2018-04-10 Richard Biener Martin Liska PR lto/85248 * lto-symtab.c (lto_symtab_merge_p): Handle noreturn attribute. 2018-04-25 Martin Liska Backport from mainline 2018-04-10 Jakub Jelinek PR lto/85248 * gcc.dg/lto/pr85248_0.c: New test. * gcc.dg/lto/pr85248_1.c: New test. Added: branches/gcc-6-branch/gcc/testsuite/gcc.dg/lto/pr85248_0.c branches/gcc-6-branch/gcc/testsuite/gcc.dg/lto/pr85248_1.c Modified: branches/gcc-6-branch/gcc/lto/ChangeLog branches/gcc-6-branch/gcc/lto/lto-symtab.c branches/gcc-6-branch/gcc/testsuite/ChangeLog
[Bug rtl-optimization/85412] [8/9 Regression] ICE in put_TImodes, at sel-sched.c:7191
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85412 Richard Biener changed: What|Removed |Added Target|x86_64-pc-linux-gnu |x86_64-pc-linux-gnu, ||ia64-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2018-04-25 Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- Confirmed. This also hits Itanium when building SPEC CPU 2000 with -O3 -funroll-loops -fpeel-loops in 176.gcc, 191.fma3d and 177.mesa.
[Bug middle-end/85516] [missed-optimization] gcc does not convert multiple compares against constants to a shift+bitmask test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85516 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2018-04-25 Ever confirmed|0 |1 --- Comment #4 from Richard Biener --- I expected fold_truth_andor to eventually catch this via fold_range_test. Probably the "bad" association in the testcase prevents this. Anyway, this is a job for reassoc / if-conversion.
[Bug tree-optimization/85509] fails to promote local static to const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85509 --- Comment #4 from Richard Biener --- (In reply to ASA from comment #3) > (In reply to Richard Biener from comment #2) > > The issue is you fail to make PerformQuickly and PerformSafely const and GCC > > doesn't have local analysis to promote it so and IPA analysis is too late > > for that since it is also the last inlining point. > > > > Slight complication is nested functions and OMP outlining which may refer to > > these variables. But even the initial cgraph build should be able to figure > > out the const-ness, no? > > > > Workaround: make the vars const. > > > I stated that const solves the issue in the description. If the auto > variables have automatic duration (remove the keyword static), the compiler > is able to inline the invocation without the const qualifier. As stated, > LLVM (clang++) does inline the invocation even if it has static duration. > > I would expect this is likely true for any non-const static duration > function pointer, not just the case when the auto type specifier is used, > but I have not confirmed it. But it is the case for any non-const static duration function pointer. This has nothing to do with 'auto', changing the testcase to static inline bool RunTest( void ) { static bool (*PerformQuickly)(int &, const int &) = Perform< SumQuickly >; static bool (*PerformSafely)(int &, const int &) = Perform< SumSafely >; int i = 0; return PerformQuickly( i, 1 ) && !PerformSafely( i, INT_MAX ); } has no effect.
[Bug c++/49171] [C++0x][constexpr] Constant expressions support reinterpret_cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49171 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |FIXED --- Comment #15 from Jakub Jelinek --- Fixed for 8.1+.
[Bug c++/55004] [meta-bug] constexpr issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004 Bug 55004 depends on bug 49171, which changed state. Bug 49171 Summary: [C++0x][constexpr] Constant expressions support reinterpret_cast https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49171 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/55004] [meta-bug] constexpr issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004 Bug 55004 depends on bug 85437, which changed state. Bug 85437 Summary: [8 Regression] member pointer static upcast rejected in a constexpr context https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85437 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/85437] [8 Regression] member pointer static upcast rejected in a constexpr context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85437 --- Comment #7 from Jakub Jelinek --- Author: jakub Date: Wed Apr 25 07:10:16 2018 New Revision: 259629 URL: https://gcc.gnu.org/viewcvs?rev=259629&root=gcc&view=rev Log: PR c++/85437 PR c++/49171 * cp-tree.h (REINTERPRET_CAST_P): New. * constexpr.c (cxx_eval_constant_expression) : Reject REINTERPET_CAST_P conversions. Use cplus_expand_constant for non-trivial PTRMEM_CST cases. * typeck.c (build_nop_reinterpret): New. (build_reinterpret_cast_1): Use it. Set REINTERPRET_CAST_P on NOP_EXPRs returned by cp_convert. * g++.dg/cpp0x/addressof1.C: Make reinterpret cases runtime checks. * g++.dg/cpp0x/constexpr-cast.C: Remove xfails * g++.dg/cpp0x/constexpr-nullptr-2.C: Likewise. * g++.dg/cpp0x/constexpr-pmf1.C: Check when optimized. * g++.dg/cpp0x/pr85437-1.C: New. * g++.dg/cpp0x/pr85437-2.C: New. * g++.dg/cpp0x/pr85437-3.C: New. * g++.dg/cpp0x/pr85437-4.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/pr85437-1.C trunk/gcc/testsuite/g++.dg/cpp0x/pr85437-2.C trunk/gcc/testsuite/g++.dg/cpp0x/pr85437-3.C trunk/gcc/testsuite/g++.dg/cpp0x/pr85437-4.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/constexpr.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/cpp0x/addressof1.C trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-cast.C trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-nullptr-2.C trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-pmf1.C
[Bug c++/49171] [C++0x][constexpr] Constant expressions support reinterpret_cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49171 --- Comment #14 from Jakub Jelinek --- Author: jakub Date: Wed Apr 25 07:10:16 2018 New Revision: 259629 URL: https://gcc.gnu.org/viewcvs?rev=259629&root=gcc&view=rev Log: PR c++/85437 PR c++/49171 * cp-tree.h (REINTERPRET_CAST_P): New. * constexpr.c (cxx_eval_constant_expression) : Reject REINTERPET_CAST_P conversions. Use cplus_expand_constant for non-trivial PTRMEM_CST cases. * typeck.c (build_nop_reinterpret): New. (build_reinterpret_cast_1): Use it. Set REINTERPRET_CAST_P on NOP_EXPRs returned by cp_convert. * g++.dg/cpp0x/addressof1.C: Make reinterpret cases runtime checks. * g++.dg/cpp0x/constexpr-cast.C: Remove xfails * g++.dg/cpp0x/constexpr-nullptr-2.C: Likewise. * g++.dg/cpp0x/constexpr-pmf1.C: Check when optimized. * g++.dg/cpp0x/pr85437-1.C: New. * g++.dg/cpp0x/pr85437-2.C: New. * g++.dg/cpp0x/pr85437-3.C: New. * g++.dg/cpp0x/pr85437-4.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/pr85437-1.C trunk/gcc/testsuite/g++.dg/cpp0x/pr85437-2.C trunk/gcc/testsuite/g++.dg/cpp0x/pr85437-3.C trunk/gcc/testsuite/g++.dg/cpp0x/pr85437-4.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/constexpr.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/cpp0x/addressof1.C trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-cast.C trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-nullptr-2.C trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-pmf1.C
[Bug c++/85437] [8 Regression] member pointer static upcast rejected in a constexpr context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85437 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Jakub Jelinek --- Fixed by Nathan.