[Bug go/90110] [9 Regression] libgo fails to build against glibc 2.19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90110 --- Comment #2 from Richard Biener --- Created attachment 46183 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46183&action=edit 32bit math.gox Here it is. The 64bit one looks similar btw.
[Bug go/90110] [9 Regression] libgo fails to build against glibc 2.19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90110 --- Comment #3 from Richard Biener --- Btw, I just checked and the build also fails with glibc 2.22 in the same way. Oddly enough it only fails in a controlled environment but not on a development machine with the same glibc I do regular testing on. (controlled environment aka package builds for SLES 12 based distros) I configure with ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,ada,go,d --enable-offload-targets=hsa,nvptx-none=/usr/nvptx-none, --without-cuda-driver --disable-werror --with-gxx-include-dir=/usr/include/c++/9 --enable-ssp --disable-libssp --disable-libvtv --disable-cet --disable-libcc1 --disable-plugin --with-bugurl=https://bugs.opensuse.org/ '--with-pkgversion=SUSE Linux' --with-slibdir=/lib64 --with-system-zlib --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --with-default-libstdcxx-abi=gcc4-compatible --enable-libphobos --enable-version-specific-runtime-libs --with-gcc-major-version-only --enable-linker-build-id --enable-linux-futex --enable-gnu-indirect-function --program-suffix=-9 --without-system-libunwind --enable-multilib --with-arch-32=x86-64 --with-tune=generic --build=x86_64-suse-linux --host=x86_64-suse-linux and build like setarch x86_64 -R make profiledbootstrap 'STAGE1_CFLAGS=-g -O2' 'BOOT_CFLAGS=-fmessage-length=0 -grecord-gcc-switches -O2 -D_FORTIFY_SOURCE=2 -funwind-tables -fasynchronous-unwind-tables -g -U_FORTIFY_SOURCE' -j3 the build uses trunk as of r270275
[Bug c++/90108] ICE: Segmentation fault (in c_tree_chain_next)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90108 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Created attachment 46184 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46184&action=edit gcc9-pr90108.patch Untested fix.
[Bug tree-optimization/43565] Missed address comparison folding of DECL_COMMONs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43565 --- Comment #14 from Richard Biener --- I think implementation-wise GCC outrules aliases that are not visible but takes care of symbols resolving to NULL. For optimizations of actual accesses it can assume the symbols do not resolve to NULL since the accesses would trap. So the question is whether we should follow suit and declare non-visible weak declarations similarly undefined as non-visible alias declarations (for externs and commons).
[Bug tree-optimization/90037] [9 Regression] -Wnull-dereference false positive after r269302
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90037 --- Comment #9 from Richard Biener --- (In reply to Jeffrey A. Law from comment #8) > So, if we change phionlycprop to look for other const/copy initializations > that can be eliminated and run a pass between DOM and the erroneous-path > isolation pass, then the false positive is eliminated (as expected). > > There's two things I don't like about that. First, it turns phionlycprop > into a full-fledged constant propagation pass. phionlycprop is supposed to > be so fast that we never really notice it. It accomplishes this by only > looking at PHI nodes that are degenerates and any constants exposed by > propagating way the degenerate PHI. Essentially it's just cleaning up > painfully obvious cruft left by jump threading. > > To pick up this case we'd have to scan statements in blocks. We could > restrict that to blocks where we eliminated degenerate PHI. But still. > Ugh. > > Second, once phionlycprop is doing more work, I'm less inclined to want to > add another instance of the pass. > > Finally, once phionlycprop is doing more work one could legitimately ask if > we should just drop the code and use the lattice copy propagator. > > Just for fun I replaced all the phi-only cprop calls with calls into the > lattice propagator (including the one I added between DOM and erroneous-path > optimization). As expected that fixes the testcase too. It also happens to > clean up things slightly better at an earlier point in the optimizer > pipeline. I don't know if it's a good trade-off though. As a middle-ground you can now run non-iterating value-numbering on a SEME region. We are already doing that for unrolled loop bodies, if-converted loop bodies and loop header copies, exactly to (mostly) get local constant propagation & simplifications done. IMHO the copied paths jump threading creates are a perfect candidate for this treatment as well. See for example tree-ssa-loop-ch.c where it calls do_rpo_vn (obviously VN needs up-to-date SSA so the VN is delayed until after all loop-header copying is done and we remember the SEME regions to VN).
[Bug translation/90117] Replace %<%s%> with %qs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90117 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-04-17 CC||marxin at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Makes sense, I'll integrate that to our linter.
[Bug debug/90109] gstabs flag generates wrong entry for long on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90109 --- Comment #3 from nebiun at hotmail dot com --- Sorry, but the bug is not related to the wrong dimension of a type, but to the fact that the bitsize of the same type (K&R type: long, not long long or double or a user type) is showed as 32 bit as typedef and 64 bit if used in a structure.
[Bug c/82542] -fdump-lang-raw (formerly -fdump-translation-unit) no longer available for C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82542 --- Comment #11 from Richard Biener --- Nathan, what does it take to re-instantiate -fdump-lang-raw for the C frontend?
[Bug translation/90121] extra space in error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90121 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-04-17 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1
[Bug translation/90118] Missing space between words
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90118 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-04-17 CC||marxin at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Target Milestone|--- |9.0 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Thanks for report, let me do it.
[Bug translation/90117] Replace %<%s%> with %qs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90117 Martin Liška changed: What|Removed |Added Target Milestone|--- |9.0
[Bug c++/90124] [9 Regression] Compilation of llvm PDBContext.cpp fails.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90124 Martin Liška changed: What|Removed |Added CC||jason at gcc dot gnu.org, ||marxin at gcc dot gnu.org Target Milestone|--- |9.0 Known to fail||9.0 --- Comment #4 from Martin Liška --- Started with r270135, let me reduce that.
[Bug translation/90121] extra space in error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90121 Martin Liška changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Target Milestone|--- |9.0
[Bug translation/90120] inconsistent punctuation in translation messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90120 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-04-17 CC||marxin at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Target Milestone|--- |9.0 Ever confirmed|0 |1
[Bug translation/90119] Merge translation msgids that only differ in placeholders
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90119 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-04-17 CC||marxin at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Target Milestone|--- |9.0 Ever confirmed|0 |1 --- Comment #3 from Martin Liška --- Also useful bug report, thanks for ideas!
[Bug debug/90109] gstabs flag generates wrong entry for long on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90109 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Richard Biener --- (In reply to nebiun from comment #3) > Sorry, but the bug is not related to the wrong dimension of a type, but to > the fact that the bitsize of the same type (K&R type: long, not long long or > double or a user type) is showed as 32 bit as typedef and 64 bit if used in > a structure. Well, the typedef is "wrong" (but we can't do anything about that w/o extensions) and the structure layout is "correct" (it seems we can represent things there correctly). What would be nice is to somehow not emit the bogus typedef but sth that wouldn't show this mismatch. But I get that stabs doesn't have a way to do this. That said, dbxout.c might want to issue a warning if we emit "bogus" stabs and suggest to use -gstabs+. But I agree, you shouldn't use stabs. It's not maintained, the world has moved on to dwarf (and I more than once argued to remove stabs support from GCC).
[Bug c/90125] New: Typo of AVX512 intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90125 Bug ID: 90125 Summary: Typo of AVX512 intrinsics Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: crazylht at gmail dot com CC: jakub at redhat dot com Target Milestone: --- for intrinsics _mm_maskz_f[n,]m[add,sub]_round_s[sd], I think it should be 1 file changed, 8 insertions(+), 8 deletions(-) gcc/config/i386/avx512fintrin.h | 16 modified gcc/config/i386/avx512fintrin.h @@ -12104,10 +12104,10 @@ _mm_maskz_fnmsub_round_ss (__mmask8 __U, __m128 __W, __m128 __A, __m128 __B, (__m128) __builtin_ia32_vfmaddss3_mask3 (A, B, C, U, R) #define _mm_maskz_fmadd_round_sd(U, A, B, C, R)\ -(__m128d) __builtin_ia32_vfmaddsd3_mask3 (A, B, C, U, R) +(__m128d) __builtin_ia32_vfmaddsd3_maskz (A, B, C, U, R) #define _mm_maskz_fmadd_round_ss(U, A, B, C, R)\ -(__m128) __builtin_ia32_vfmaddss3_mask3 (A, B, C, U, R) +(__m128) __builtin_ia32_vfmaddss3_maskz (A, B, C, U, R) #define _mm_mask_fmsub_round_sd(A, U, B, C, R)\ (__m128d) __builtin_ia32_vfmaddsd3_mask (A, B, -(C), U, R) @@ -12122,10 +12122,10 @@ _mm_maskz_fnmsub_round_ss (__mmask8 __U, __m128 __W, __m128 __A, __m128 __B, (__m128) __builtin_ia32_vfmsubss3_mask3 (A, B, C, U, R) #define _mm_maskz_fmsub_round_sd(U, A, B, C, R)\ -(__m128d) __builtin_ia32_vfmaddsd3_mask3 (A, B, -(C), U, R) +(__m128d) __builtin_ia32_vfmaddsd3_maskz (A, B, -(C), U, R) #define _mm_maskz_fmsub_round_ss(U, A, B, C, R)\ -(__m128) __builtin_ia32_vfmaddss3_mask3 (A, B, -(C), U, R) +(__m128) __builtin_ia32_vfmaddss3_maskz (A, B, -(C), U, R) #define _mm_mask_fnmadd_round_sd(A, U, B, C, R)\ (__m128d) __builtin_ia32_vfmaddsd3_mask (A, -(B), C, U, R) @@ -12140,10 +12140,10 @@ _mm_maskz_fnmsub_round_ss (__mmask8 __U, __m128 __W, __m128 __A, __m128 __B, (__m128) __builtin_ia32_vfmaddss3_mask3 (A, -(B), C, U, R) #define _mm_maskz_fnmadd_round_sd(U, A, B, C, R)\ -(__m128d) __builtin_ia32_vfmaddsd3_mask3 (A, -(B), C, U, R) +(__m128d) __builtin_ia32_vfmaddsd3_maskz (A, -(B), C, U, R) #define _mm_maskz_fnmadd_round_ss(U, A, B, C, R)\ -(__m128) __builtin_ia32_vfmaddss3_mask3 (A, -(B), C, U, R) +(__m128) __builtin_ia32_vfmaddss3_maskz (A, -(B), C, U, R) #define _mm_mask_fnmsub_round_sd(A, U, B, C, R)\ (__m128d) __builtin_ia32_vfmaddsd3_mask (A, -(B), -(C), U, R) @@ -12158,10 +12158,10 @@ _mm_maskz_fnmsub_round_ss (__mmask8 __U, __m128 __W, __m128 __A, __m128 __B, (__m128) __builtin_ia32_vfmsubss3_mask3 (A, -(B), C, U, R) #define _mm_maskz_fnmsub_round_sd(U, A, B, C, R)\ -(__m128d) __builtin_ia32_vfmaddsd3_mask3 (A, -(B), -(C), U, R) +(__m128d) __builtin_ia32_vfmaddsd3_maskz (A, -(B), -(C), U, R) #define _mm_maskz_fnmsub_round_ss(U, A, B, C, R)\ -(__m128) __builtin_ia32_vfmaddss3_mask3 (A, -(B), -(C), U, R) +(__m128) __builtin_ia32_vfmaddss3_maskz (A, -(B), -(C), U, R) #endif jakub, is it correct?
[Bug c/90125] Typo of AVX512 intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90125 --- Comment #1 from Hongtao.liu --- Last time I add runtime tests for -O2, didn't cover this part which use -O0.
[Bug c++/90124] [9 Regression] Compilation of llvm PDBContext.cpp fails.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90124 Richard Biener changed: What|Removed |Added Keywords||rejects-valid Priority|P3 |P1
[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093 --- Comment #51 from Jakub Jelinek --- Author: jakub Date: Wed Apr 17 08:30:44 2019 New Revision: 270404 URL: https://gcc.gnu.org/viewcvs?rev=270404&root=gcc&view=rev Log: PR target/89093 * config/arm/arm.c (arm_valid_target_attribute_rec): Don't skip whitespace at the start of target attribute string. * gcc.target/arm/pr89093-2.c: New test. Added: trunk/gcc/testsuite/gcc.target/arm/pr89093-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c trunk/gcc/testsuite/ChangeLog
[Bug c++/90124] [9 Regression] Compilation of llvm PDBContext.cpp fails.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90124
Martin Liška changed:
What|Removed |Added
Keywords|needs-reduction |
--- Comment #5 from Martin Liška ---
Reduced test-case:
$ cat pr90124.ii
class a {
public:
int b;
};
class c : a {
auto m_fn1() -> decltype(b);
};
$ g++ pr90124.ii -c -fmax-errors=1 -Werror
pr90124.ii:6:28: error: invalid use of incomplete type ‘class c’
6 | auto m_fn1() -> decltype(b);
|^
pr90124.ii:5:7: note: definition of ‘class c’ is not complete until the closing
brace
5 | class c : a {
| ^
$ g++-8 pr90124.ii -c -fmax-errors=1 -Werror
[OK]
[Bug fortran/90067] Loop variables in Fortran 'do' statements within a compute construct must be predetermined private
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90067 --- Comment #1 from Thomas Schwinge --- Author: tschwinge Date: Wed Apr 17 08:34:10 2019 New Revision: 270405 URL: https://gcc.gnu.org/viewcvs?rev=270405&root=gcc&view=rev Log: [PR90067, PR90114] Document Fortran OpenACC predetermined private status quo gcc/testsuite/ PR fortran/90067 PR fortran/90114 * gfortran.dg/goacc/private-1.f95: Remove file. * gfortran.dg/goacc/private-2.f95: Likewise. * gfortran.dg/goacc/private-predetermined-kernels-1.f95: New file. * gfortran.dg/goacc/private-predetermined-parallel-1.f95: Likewise. * gfortran.dg/goacc/private-predetermined-routine-1.f95: Likewise. Added: trunk/gcc/testsuite/gfortran.dg/goacc/private-predetermined-kernels-1.f95 trunk/gcc/testsuite/gfortran.dg/goacc/private-predetermined-parallel-1.f95 trunk/gcc/testsuite/gfortran.dg/goacc/private-predetermined-routine-1.f95 Removed: trunk/gcc/testsuite/gfortran.dg/goacc/private-1.f95 trunk/gcc/testsuite/gfortran.dg/goacc/private-2.f95 Modified: trunk/gcc/testsuite/ChangeLog
[Bug middle-end/90114] Predetermined private levels for variables declared in OpenACC accelerator routines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90114 --- Comment #1 from Thomas Schwinge --- Author: tschwinge Date: Wed Apr 17 08:34:10 2019 New Revision: 270405 URL: https://gcc.gnu.org/viewcvs?rev=270405&root=gcc&view=rev Log: [PR90067, PR90114] Document Fortran OpenACC predetermined private status quo gcc/testsuite/ PR fortran/90067 PR fortran/90114 * gfortran.dg/goacc/private-1.f95: Remove file. * gfortran.dg/goacc/private-2.f95: Likewise. * gfortran.dg/goacc/private-predetermined-kernels-1.f95: New file. * gfortran.dg/goacc/private-predetermined-parallel-1.f95: Likewise. * gfortran.dg/goacc/private-predetermined-routine-1.f95: Likewise. Added: trunk/gcc/testsuite/gfortran.dg/goacc/private-predetermined-kernels-1.f95 trunk/gcc/testsuite/gfortran.dg/goacc/private-predetermined-parallel-1.f95 trunk/gcc/testsuite/gfortran.dg/goacc/private-predetermined-routine-1.f95 Removed: trunk/gcc/testsuite/gfortran.dg/goacc/private-1.f95 trunk/gcc/testsuite/gfortran.dg/goacc/private-2.f95 Modified: trunk/gcc/testsuite/ChangeLog
[Bug fortran/90048] Fortran OpenACC 'private' clause rejected for predetermined private loop iteration variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90048 --- Comment #2 from Thomas Schwinge --- Author: tschwinge Date: Wed Apr 17 08:34:20 2019 New Revision: 270406 URL: https://gcc.gnu.org/viewcvs?rev=270406&root=gcc&view=rev Log: [PR90048] Fortran OpenACC 'private' clause rejected for predetermined private loop iteration variable gcc/fortran/ PR fortran/90048 * openmp.c (gfc_resolve_do_iterator): Handle sharing_clauses for OpenACC, too. (gfc_resolve_oacc_blocks): Populate sharing_clauses with private clauses. gcc/testsuite/ PR fortran/90048 * gfortran.dg/goacc/private-explicit-kernels-1.f95: New file. * gfortran.dg/goacc/private-explicit-parallel-1.f95: Likewise. * gfortran.dg/goacc/private-explicit-routine-1.f95: Likewise. Added: trunk/gcc/testsuite/gfortran.dg/goacc/private-explicit-kernels-1.f95 trunk/gcc/testsuite/gfortran.dg/goacc/private-explicit-parallel-1.f95 trunk/gcc/testsuite/gfortran.dg/goacc/private-explicit-routine-1.f95 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/openmp.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/85164] poly-int.h:845:5: runtime error: signed integer overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85164 --- Comment #4 from Martin Liška --- For the 2 test-cases we reach these backtraces: $ ./xgcc -B. test.c -O1 ../../gcc/poly-int.h:1941:12: runtime error: negation of -9223372036854775808 cannot be represented in type 'long int'; cast to an unsigned type to negate this value to itself #0 0xc8bbdc in poly_result::coeff_type, poly_int_traits::coeff_type, poly_coeff_pair_traits::coeff_type, poly_int_traits::coeff_type>::result_kind>::type known_alignment<1u, long>(poly_int_pod<1u, long> const&) ../../gcc/poly-int.h:1941 #1 0x3db9fdd in force_int_to_mode ../../gcc/combine.c:8949 #2 0x3db8c5b in force_to_mode ../../gcc/combine.c:8802 #3 0x3da45a8 in simplify_set ../../gcc/combine.c:6876 #4 0x3d9f16d in combine_simplify_rtx ../../gcc/combine.c:6456 #5 0x3d96712 in subst ../../gcc/combine.c:5727 #6 0x3d950fa in subst ../../gcc/combine.c:5590 #7 0x3d7ead4 in try_combine ../../gcc/combine.c:3420 #8 0x3d6e699 in combine_instructions ../../gcc/combine.c:1306 #9 0x3df4563 in rest_of_handle_combine ../../gcc/combine.c:15076 #10 0x3df4702 in execute ../../gcc/combine.c:15121 #11 0x1baf287 in execute_one_pass(opt_pass*) ../../gcc/passes.c:2487 #12 0x1bafb1d in execute_pass_list_1 ../../gcc/passes.c:2573 #13 0x1bafbd2 in execute_pass_list_1 ../../gcc/passes.c:2574 #14 0x1bafc71 in execute_pass_list(function*, opt_pass*) ../../gcc/passes.c:2584 #15 0xe52f0c in cgraph_node::expand() ../../gcc/cgraphunit.c:2198 #16 0xe544d3 in expand_all_functions ../../gcc/cgraphunit.c:2336 #17 0xe56b42 in symbol_table::compile() ../../gcc/cgraphunit.c:2687 #18 0xe575a8 in symbol_table::finalize_compilation_unit() ../../gcc/cgraphunit.c:2865 #19 0x2006fad in compile_file ../../gcc/toplev.c:481 #20 0x200ea9b in do_compile ../../gcc/toplev.c:2205 #21 0x200f0c9 in toplev::main(int, char**) ../../gcc/toplev.c:2340 #22 0x438f452 in main ../../gcc/main.c:39 #23 0x76e80b7a in __libc_start_main ../csu/libc-start.c:308 #24 0x85f579 in _start (/home/marxin/Programming/gcc2/objdir/gcc/cc1+0x85f579) and ../../gcc/poly-int.h:845:5: runtime error: signed integer overflow: 9223372036854775804 + 4 cannot be represented in type 'long int' #0 0xc088f7 in poly_int<1u, poly_result::result_kind>::type> operator+<1u, long, long>(poly_int_pod<1u, long> const&, poly_int_pod<1u, long> const&) ../../gcc/poly-int.h:845 #1 0x1e2e0f2 in rtx_addr_can_trap_p_1 ../../gcc/rtlanal.c:524 #2 0x1e2ef7d in rtx_addr_can_trap_p_1 ../../gcc/rtlanal.c:659 #3 0x1e2ec71 in rtx_addr_can_trap_p_1 ../../gcc/rtlanal.c:645 #4 0x1e3e6fc in may_trap_p_1(rtx_def const*, unsigned int) ../../gcc/rtlanal.c:2836 #5 0x1e3fc4c in may_trap_p_1(rtx_def const*, unsigned int) ../../gcc/rtlanal.c:2937 #6 0x1e3fedf in may_trap_p(rtx_def const*) ../../gcc/rtlanal.c:2956 #7 0x1cefd4b in copyprop_hardreg_forward_1 ../../gcc/regcprop.c:804 #8 0x1cf6191 in cprop_hardreg_bb ../../gcc/regcprop.c:1320 #9 0x1cf6da4 in execute ../../gcc/regcprop.c:1385 #10 0x1baf287 in execute_one_pass(opt_pass*) ../../gcc/passes.c:2487 #11 0x1bafb1d in execute_pass_list_1 ../../gcc/passes.c:2573 #12 0x1bafbd2 in execute_pass_list_1 ../../gcc/passes.c:2574 #13 0x1bafbd2 in execute_pass_list_1 ../../gcc/passes.c:2574 #14 0x1bafc71 in execute_pass_list(function*, opt_pass*) ../../gcc/passes.c:2584 #15 0xe52f0c in cgraph_node::expand() ../../gcc/cgraphunit.c:2198 #16 0xe544d3 in expand_all_functions ../../gcc/cgraphunit.c:2336 #17 0xe56b42 in symbol_table::compile() ../../gcc/cgraphunit.c:2687 #18 0xe575a8 in symbol_table::finalize_compilation_unit() ../../gcc/cgraphunit.c:2865 #19 0x2006fad in compile_file ../../gcc/toplev.c:481 #20 0x200ea9b in do_compile ../../gcc/toplev.c:2205 #21 0x200f0c9 in toplev::main(int, char**) ../../gcc/toplev.c:2340 #22 0x438f452 in main ../../gcc/main.c:39 #23 0x76e80b7a in __libc_start_main ../csu/libc-start.c:308 #24 0x85f579 in _start (/home/marxin/Programming/gcc2/objdir/gcc/cc1+0x85f579)
[Bug tree-optimization/90037] [9 Regression] -Wnull-dereference false positive after r269302
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90037
--- Comment #10 from Jonathan Wakely ---
Jeff posted this to PR 89819 instead of here:
Somewhat trimmed down testcase... Certainly easier to analyze...
typedef __SIZE_TYPE__ size_t;
typedef unsigned long int uintmax_t;
struct group
{
char *gr_name;
char *gr_passwd;
unsigned gr_gid;
char **gr_mem;
};
struct passwd
{
char *pw_name;
char *pw_passwd;
unsigned pw_uid;
unsigned pw_gid;
char *pw_gecos;
char *pw_dir;
char *pw_shell;
};
extern struct group *getgrnam (const char *);
extern struct group *getgrgid (unsigned);
extern void endgrent (void);
extern struct passwd *getpwnam (const char *);
extern void endpwent (void);
extern unsigned long int strtoul (const char *__restrict,
char **__restrict, int);
char const *
parse_with_separator (char const *spec, char const *separator,
unsigned *uid, unsigned *gid,
char **username, char **groupname)
{
static const char *E_bad_spec = "invalid spec";
const char *error_msg;
char *u;
char const *g;
struct group *grp;
unsigned unum = *uid;
error_msg = 0;
u = 0;
if (separator == 0)
u = __builtin_strdup (spec);
size_t ulen = separator - spec;
u = __builtin_malloc (ulen + 1);
g = (separator == 0 || *(separator + 1) == '\0' ? 0 : separator + 1);
if (u != 0)
{
_Bool use_login_group = (separator != 0 && g == 0);
if (use_login_group)
error_msg = E_bad_spec;
endpwent ();
}
if (g != 0 && error_msg == 0)
grp = (*g == '+' ? 0 : getgrnam (g));
if (error_msg == 0)
*uid = unum;
return 0;
}
[Bug c++/90126] New: gcc can not correctly deal with its own preprocessed output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90126 Bug ID: 90126 Summary: gcc can not correctly deal with its own preprocessed output Product: gcc Version: 8.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: stanislav at froglogic dot com Target Milestone: --- Created attachment 46185 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46185&action=edit attachment is a .cpp (de facto an .ii) file of a minimized case for which the problem occurs The result of g++ -v: Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 8.3.0-3' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-8 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 8.3.0 (Debian 8.3.0-3) Command line which causes the problem: g++ temp_namespace_anonymous.cpp RESULT OF THE CALL: namespace_anonymous_1_min_ok.cpp:14:8: warning: ‘Node’ has a field ‘Node::receiverQueue’ whose type uses the anonymous namespace [-Wsubobject-linkage] struct Node File temp_namespace_anonymous.cpp is generated as follows: g++ -E namespace_anonymous_1_min_ok.cpp > temp_namespace_anonymous.cpp HOWEVER output of g++ namespace_anonymous_1_min_ok.cpp is OK You will find file namespace_anonymous_1_min_ok.cpp (which can also be considered as .ii file) attached to this report.
[Bug target/89929] __attribute__((target("avx512bw"))) doesn't work on non avx512bw systems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89929 --- Comment #15 from Martin Liška --- @Nikolay: As discussed in https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00416.html email thread, we reached the following consensus with H.J: - As any AVX512 extensions (apart from AVX512F) can be enabled individually, it's difficult to come up with priorities in dispatcher. - We don't have a syntax for target_clone attribute where one would say e.g. avx512f+avx512cd+avx512er. - So that we would reject these (AVX512* except AVX512F) in target_clone attribute and we recommend to use rather. target_clones(arch=skylake,arch=skylake-avx512,arch=cannonlake,arch=icelake-client,arch=icelake-server, ..) - Using that one can cover used AVX512 ISA combinations for existing CPUs Does it work for you Nikolay?
[Bug c++/86368] an unknown [[attribute]] should not trigger a warning in C++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86368 --- Comment #8 from Jonathan Wakely --- (In reply to Justin Bassett from comment #7) > and it won't extend to future standardized attributes. That's a Good Thing. If I use a new standardized attribute like [[no_unique_address]] I definitely want to know if the compiler doesn't recognize it, because that affects the ABI of my code.
[Bug tree-optimization/90106] builtin sqrt() ignoring libm's sqrt call result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90106 JunMa changed: What|Removed |Added CC||JunMa at linux dot alibaba.com --- Comment #7 from JunMa --- yes, the transformation in CDEC prevent the tail call optimization. let's check the return stmt in CDEC pass.
[Bug web/90127] New: Disable bugzilla [[wiki_links]] and don't confuse rNN register names with rNNNNN svn revisions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90127 Bug ID: 90127 Summary: Disable bugzilla [[wiki_links]] and don't confuse rNN register names with rN svn revisions Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: web Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Target Milestone: --- Currently [[this_text]] will link to https://gcc.gnu.org/wiki/this_text which is distracting when trying to talk about C++11-style attributes such as [[noreturn]] and [[fallthrough]] e.g. see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86368 Either we should pick another syntax for wiki links, or just disable it. I don't think anybody uses it. Secondly, the shortcuts for svn revisions like r12345 also match register names like r1, r12, r123 and that's also distracting. I suggest that it should only link to an svn revision for 4 or more digits. GCC supports targets that have register names with three digits, and I doubt there's any need to link to the first 999 svn revisions.
[Bug debug/81135] Extra debug info generated for unused extern declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81135 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Richard Biener --- dup *** This bug has been marked as a duplicate of bug 86964 ***
[Bug debug/86964] [7/8 Regression] Too many debug symbols included, especially for extern globals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86964 Richard Biener changed: What|Removed |Added CC||peadar at arista dot com --- Comment #10 from Richard Biener --- *** Bug 81135 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/65752] Too strong optimizations int -> pointer casts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
--- Comment #57 from Richard Biener ---
(In reply to Richard Biener from comment #56)
> Testcase from PR82177:
>
> #include
> #include
>
> void f(int*, int*);
>
> int main()
> {
> int a=0, y[1], x = 0;
> uintptr_t pi = (uintptr_t) &x;
> uintptr_t yi = (uintptr_t) (y+1);
> uintptr_t n = pi != yi;
>
> if (n) {
> a = 100;
> pi = yi;
> }
>
> if (n) {
> a = 100;
> pi = (uintptr_t) y;
> }
>
> *(int *)pi = 15;
>
> printf("a=%d x=%d\n", a, x);
>
> f(&x,y);
>
> return 0;
> }
With the C provenance proposal this example is undefined since 'a' is not
exposed (it's address is not converted to an integer). The testcase
also relies on preserving the order of the variables on the stack.
[Bug tree-optimization/65752] Too strong optimizations int -> pointer casts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
--- Comment #58 from Richard Biener ---
(In reply to Richard Biener from comment #49)
> Related testcase from PR61502:
>
> #include
>
> int main()
> {
>int x, y = 1;
>int *volatile v;
>int *p;
>
>v = &y;
>p = v;
>if (p == &x + 1) {
> *p = 2;
> printf("y = %d\n", y);
>}
> }
>
> which shows how propagating conditional equivalences (&x+1 into *p = 2)
> breaks
> alias analysis.
We now optimize the comparison to false via ptrs_compare_unequal given
&x + 1 has provenance &x and p has provenance &y. Thus we decided to
ignore that sub-sentence of the standard that seems to allow comparing
such pointers. So we behave as-if we'd put at least one byte of padding
after each object.
[Bug c++/88136] -Wdeprecated-copy is draconian and shouldn't be in -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88136 --- Comment #6 from Ville Voutilainen --- Any chance of moving this warning out of -Wextra and re-considering adding it there for GCC 10?
[Bug c++/88136] -Wdeprecated-copy is draconian and shouldn't be in -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88136 --- Comment #7 from Ville Voutilainen --- Innocent users are going to hit it: https://bugreports.qt.io/browse/QTBUG-75210
[Bug c++/90126] gcc can not correctly deal with its own preprocessed output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90126 --- Comment #1 from Jonathan Wakely --- I don't think this is a bug. If you tell gcc that the preprocessed output is preprocessed output, then the behaviour is consistent. So either: g++ -E namespace_anonymous_1_min_ok.cpp > temp_namespace_anonymous.ii g++ temp_namespace_anonymous.ii Or: g++ -E namespace_anonymous_1_min_ok.cpp > temp_namespace_anonymous.cpp g++ -x c++-cpp-output temp_namespace_anonymous.cpp The warning is suppressed when the type is defined in the "main input context" i.e. not in a header file. When you treat the preprocessed output as unpreprocessed source you end up with two sets of line markers, which makes GCC think the type is defined in a header. If you want to use preprocessed output this way you should probably generate it without line markers: g++ -E -P namespace_anonymous_1_min_ok.cpp > temp_namespace_anonymous.cpp g++ temp_namespace_anonymous.cpp
[Bug c++/90126] gcc can not correctly deal with its own preprocessed output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90126 --- Comment #2 from Jonathan Wakely --- tl;dr the preprocessor should only be used once. You're running it twice on the same input.
[Bug c++/90126] gcc can not correctly deal with its own preprocessed output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90126
Richard Biener changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #3 from Richard Biener ---
Confirmed. I think this is odd behavior of the warning (not sure what it is
about). Note you get no warning when you pass -fpreprocessed. The key
to the diagnostic is that the anonymous namespace appears in a file
(through a #line directive) that is not the same as the file compiled.
Thus, the following testcase warns:
# 1 "t.C"
namespace {
struct Receiver { int object; };
}
struct Node
{
Receiver receiverQueue;
Node() { }
};
int main(int argc, char* argv[]) { return 0; }
> g++ t2.C
note to put the testcase into a file named t2.C, it doesn't warn when
the filename is t.C. This is because the warning intends to warn about
anonymous namespaces in headers which, when included from multiple sources
may cause issues.
So I think this behaves as intended and you need to compile preprocessed
source with -fpreprocessed (or use t2.ii filenames) or retain the original
filename. Or disable this particular warning.
[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #52 from Bernd Edlinger ---
I digged a bit, and found a D syntax for the target attribute,
it is a bit of a complication since D does not have a pre-processor,
but an empty target attribute does seem to be ignored without warnings.
--- libphobos/libdruntime/gcc/deh.d 2019-01-01 13:31:55.0 +0100
+++ libphobos/libdruntime/gcc/deh.d 2019-04-17 11:24:24.171579381 +0200
@@ -28,6 +28,7 @@ import gcc.unwind;
import gcc.unwind.pe;
import gcc.builtins;
import gcc.config;
+import gcc.attribute;
extern(C)
{
@@ -519,10 +520,19 @@ extern(C) void _d_throw(Throwable object
terminate("unwind error", __LINE__);
}
+static if (GNU_ARM_EABI_Unwinder)
+{
+enum TARGET_ATTRIBUTE = "general-regs-only";
+}
+else
+{
+enum TARGET_ATTRIBUTE = "";
+}
/**
* Read and extract information from the LSDA (.gcc_except_table section).
*/
+@attribute("target", (TARGET_ATTRIBUTE))
_Unwind_Reason_Code scanLSDA(const(ubyte)* lsda, _Unwind_Exception_Class
exceptionClass,
_Unwind_Action actions, _Unwind_Exception*
unwindHeader,
_Unwind_Context* context, _Unwind_Word cfa,
@@ -772,6 +782,7 @@ int actionTableLookup(_Unwind_Action act
* Called when the personality function has found neither a cleanup or
handler.
* To support ARM EABI personality routines, that must also unwind the stack.
*/
+@attribute("target", (TARGET_ATTRIBUTE))
_Unwind_Reason_Code CONTINUE_UNWINDING(_Unwind_Exception* unwindHeader,
_Unwind_Context* context)
{
static if (GNU_ARM_EABI_Unwinder)
@@ -814,6 +825,7 @@ else
static if (GNU_ARM_EABI_Unwinder)
{
pragma(mangle, PERSONALITY_FUNCTION)
+@attribute("target", (TARGET_ATTRIBUTE))
extern(C) _Unwind_Reason_Code gdc_personality(_Unwind_State state,
_Unwind_Exception*
unwindHeader,
_Unwind_Context* context)
@@ -873,6 +885,7 @@ else
}
}
+@attribute("target", (TARGET_ATTRIBUTE))
private _Unwind_Reason_Code __gdc_personality(_Unwind_Action actions,
_Unwind_Exception_Class
exceptionClass,
_Unwind_Exception* unwindHeader,
[Bug target/81616] Update -mtune=generic for the current Intel and AMD processors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81616 --- Comment #53 from Martin Jambor --- I'd vote for marking this fixed (and asking anyone with other ideas what could be improved in generic tuning to open a new bug).
[Bug target/17108] Store with update not generated for a simple loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17108 --- Comment #9 from Segher Boessenkool --- Author: segher Date: Wed Apr 17 09:45:57 2019 New Revision: 270407 URL: https://gcc.gnu.org/viewcvs?rev=270407&root=gcc&view=rev Log: rs6000: Improve the load/store-with-update patterns (PR17108) Many of these patterns only worked in 32-bit mode, and some only worked in 64-bit mode. This patch makes these use Pmode, fixing the PR. On the other hand, the stack updates have to use the same mode for the stack pointer as for the value stored, so let's simplify that a bit. Many of these patterns pass the wrong mode to avoiding_indexed_address_p (it should be the mode of the datum accessed, not the mode of the pointer). Finally, I merge some patterns into one (using iterators). PR target/17108 * config/rs6000/rs6000.c (rs6000_split_multireg_move): Adjust pattern name. (rs6000_emit_allocate_stack_1): Simplify condition. Adjust pattern name. * config/rs6000/rs6000.md (bits): Add entries for SF and DF. (*movdi_update1): Use Pmode. (movdi__update): Fix argument to avoiding_indexed_address_p. (movdi__update_stack): Rename to ... (movdi_update_stack): ... this. Fix comment. Change condition. Don't use Pmode. (*movsi_update1): Use Pmode. (*movsi_update2): Use Pmode. (movsi_update): Rename to ... (movsi__update): ... this. Use Pmode. (movsi_update_stack): Fix condition. (*movhi_update1): Use Pmode. Fix argument to avoiding_indexed_address_p. (*movhi_update2): Ditto. (*movhi_update3): Ditto. (*movhi_update4): Ditto. (*movqi_update1): Ditto. (*movqi_update2): Ditto. (*movqi_update3): Ditto. (*movsf_update1, *movdf_update1): Merge, rename to... (*mov_update1): This. Use Pmode. Fix argument to avoiding_indexed_address_p. Add "size" attribute. (*movsf_update2, *movdf_update2): Merge, rename to... (*mov_update2): This. Ditto. (*movsf_update3): Use Pmode. Fix argument to avoiding_indexed_address_p. (*movsf_update4): Ditto. (allocate_stack): Simplify condition. Adjust pattern names. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c trunk/gcc/config/rs6000/rs6000.md
[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #53 from Jakub Jelinek ---
(In reply to Bernd Edlinger from comment #52)
> I digged a bit, and found a D syntax for the target attribute,
> it is a bit of a complication since D does not have a pre-processor,
> but an empty target attribute does seem to be ignored without warnings.
>
>
> --- libphobos/libdruntime/gcc/deh.d 2019-01-01 13:31:55.0 +0100
> +++ libphobos/libdruntime/gcc/deh.d 2019-04-17 11:24:24.171579381 +0200
> @@ -28,6 +28,7 @@ import gcc.unwind;
> import gcc.unwind.pe;
> import gcc.builtins;
> import gcc.config;
> +import gcc.attribute;
>
> extern(C)
> {
> @@ -519,10 +520,19 @@ extern(C) void _d_throw(Throwable object
> terminate("unwind error", __LINE__);
> }
>
> +static if (GNU_ARM_EABI_Unwinder)
> +{
> +enum TARGET_ATTRIBUTE = "general-regs-only";
> +}
> +else
> +{
> +enum TARGET_ATTRIBUTE = "";
> +}
>
> /**
> * Read and extract information from the LSDA (.gcc_except_table section).
> */
> +@attribute("target", (TARGET_ATTRIBUTE))
> _Unwind_Reason_Code scanLSDA(const(ubyte)* lsda, _Unwind_Exception_Class
> exceptionClass,
> _Unwind_Action actions, _Unwind_Exception*
> unwindHeader,
> _Unwind_Context* context, _Unwind_Word cfa,
> @@ -772,6 +782,7 @@ int actionTableLookup(_Unwind_Action act
> * Called when the personality function has found neither a cleanup or
> handler.
> * To support ARM EABI personality routines, that must also unwind the
> stack.
> */
> +@attribute("target", (TARGET_ATTRIBUTE))
> _Unwind_Reason_Code CONTINUE_UNWINDING(_Unwind_Exception* unwindHeader,
> _Unwind_Context* context)
> {
> static if (GNU_ARM_EABI_Unwinder)
> @@ -814,6 +825,7 @@ else
> static if (GNU_ARM_EABI_Unwinder)
> {
> pragma(mangle, PERSONALITY_FUNCTION)
> +@attribute("target", (TARGET_ATTRIBUTE))
> extern(C) _Unwind_Reason_Code gdc_personality(_Unwind_State state,
>_Unwind_Exception*
> unwindHeader,
>_Unwind_Context* context)
> @@ -873,6 +885,7 @@ else
> }
> }
>
> +@attribute("target", (TARGET_ATTRIBUTE))
> private _Unwind_Reason_Code __gdc_personality(_Unwind_Action actions,
>_Unwind_Exception_Class
> exceptionClass,
>_Unwind_Exception*
> unwindHeader,
That is not going to work I'm afraid, many targets don't support target
attribute at all.
default_target_option_valid_attribute_p
will then just complain.
Only i386, rs6000, s390, arm, aarch64 and nios2 backends do support those.
On the other side, given the above, I thought all you want to ensure is that
the attribute is on the personality routine, not on the other ones, and the
gdc_personality definition is in
static if (GNU_ARM_EABI_Unwinder)
{
pragma(mangle, PERSONALITY_FUNCTION)
extern(C) _Unwind_Reason_Code gdc_personality(_Unwind_State state,
so can't you just stick @attribute("target", "general-regs-only") to there?
[Bug target/90125] Typo of AVX512 intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90125 --- Comment #2 from Jakub Jelinek --- Created attachment 46186 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46186&action=edit gcc9-pr90125.patch Oops, you're right, thanks for noticing. Here is a full patch including testcases that FAIL without the header patch and succeed with that. Two tests failed, because the tests rely on actually using fma and at -O0 for the C code fma is not used and so there is a small difference, I've just tweaked constants so that it passes regardless.
[Bug rtl-optimization/87763] [9 Regression] aarch64 target testcases fail after r265398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763 --- Comment #54 from Wilco --- (In reply to Jeffrey A. Law from comment #53) > Realistically the register allocation issues are not going to get addressed > this cycle nor are improvements to the overall handling of RMW insns in > combine. So we're going to be stuck with bandaids. > > I've got an updated backend pattern that should address the remainder of the > insv_1 and insv_2 regressions and Steve has a backend pattern to address the > other regression in this BZ. I'd prefer not to add quick hacks that aren't beneficial in the long term. Adding a very general pattern to handle any bitfield insert of any constant would be much more useful. There is no issue with xfailing these tests - neither insv pattern was used frequently so the regression for these is not significant compared to the register allocation and move issues.
[Bug tree-optimization/65752] Too strong optimizations int -> pointer casts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752 --- Comment #59 from post+gcc at ralfj dot de --- > With the C provenance proposal this example is undefined since 'a' is not exposed (it's address is not converted to an integer). However, from what I can tell, GCC's behavior does not change if we insert '(uintptr_t) &a;' at the beginning of the function. That change should be sufficient to make the example well-defined again.
[Bug translation/90120] inconsistent punctuation in translation messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90120 Jakub Jelinek changed: What|Removed |Added CC||claziss at gcc dot gnu.org, ||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- The general diagnostic rules we use say that diagnostics (gfortran/ diagnostics is an exception) shouldn't begin with a capital letter (unless such a word would be capitalized in the middle of a sentence too) and should not end with a dot, that is all violated here. As for what the DOC/DOC0/DOC1 expand too, it is easy to look up config/arc/arc-options.def where the strings are as the last argument of ARC_OPT or last two of ARC_OPTX. CCing the author of that, I know nothing about ARC otherwise.
[Bug target/90125] Typo of AVX512 intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90125 --- Comment #3 from Hongtao.liu --- L(In reply to Jakub Jelinek from comment #2) > Created attachment 46186 [details] > gcc9-pr90125.patch > > Oops, you're right, thanks for noticing. > Here is a full patch including testcases that FAIL without the header patch > and succeed with that. Two tests failed, because the tests rely on actually > using fma and at -O0 for the C code fma is not used and so there is a small > difference, I've just tweaked constants so that it passes regardless. LGTM.
[Bug web/90127] Disable bugzilla [[wiki_links]] and don't confuse r12 register names with r12345 svn revisions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90127 Frédéric Buclin changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-04-17 Assignee|unassigned at gcc dot gnu.org |LpSolit at gmail dot com Ever confirmed|0 |1 --- Comment #1 from Frédéric Buclin --- (In reply to Jonathan Wakely from comment #0) > Either we should pick another syntax for wiki links, or just disable it. I > don't think anybody uses it. Which solution do you prefer? > Secondly, the shortcuts for svn revisions like r12345 also match register > names like r1, r12, r123 and that's also distracting. I suggest that it > should only link to an svn revision for 4 or more digits. GCC supports > targets that have register names with three digits, and I doubt there's any > need to link to the first 999 svn revisions. OK, I will do it.
[Bug target/90125] Typo of AVX512 intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90125 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-04-17 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from Jakub Jelinek --- (In reply to Hongtao.liu from comment #3) > L(In reply to Jakub Jelinek from comment #2) > > Created attachment 46186 [details] > > gcc9-pr90125.patch > > > > Oops, you're right, thanks for noticing. > > Here is a full patch including testcases that FAIL without the header patch > > and succeed with that. Two tests failed, because the tests rely on actually > > using fma and at -O0 for the C code fma is not used and so there is a small > > difference, I've just tweaked constants so that it passes regardless. > > LGTM. I'll do full bootstrap/regtest on it and post.
[Bug translation/90120] inconsistent punctuation in translation messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90120 Claudiu Zissulescu changed: What|Removed |Added CC||claziss at gmail dot com --- Comment #2 from Claudiu Zissulescu --- I can craft quickly a patch to fix the upper/dot issue. Is it ok?
[Bug web/90127] Disable bugzilla [[wiki_links]] and don't confuse r12 register names with r12345 svn revisions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90127 --- Comment #2 from Jonathan Wakely --- Would it be easy to only link for strings that look like WikiNames and not identifiers in all lowercase like "noreturn"? e.g. a regex like [[:upper:]][[:alnum:]]+ That way [[InstallingGCC]] and [[DebuggingGCC]] and [[LibstdcxxTodo]] would still be links, but C++ attributes would not.
[Bug middle-end/85164] poly-int.h:845:5: runtime error: signed integer overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85164
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek ---
The first above is on:
case MINUS:
/* If X is (minus C Y) where C's least set bit is larger than any bit
in the mask, then we may replace with (neg Y). */
if (poly_int_rtx_p (XEXP (x, 0), &const_op0)
&& (unsigned HOST_WIDE_INT) known_alignment (const_op0) > mask)
and
template
inline POLY_BINARY_COEFF (Ca, Ca)
known_alignment (const poly_int_pod &a)
{
typedef POLY_BINARY_COEFF (Ca, Ca) C;
C r = a.coeffs[0];
for (unsigned int i = 1; i < N; ++i)
r |= a.coeffs[i];
return r & -r;
}
The poly_int* stuff makes this much harder to fix, it is unclear if there is
some way to get the unsigned type for the C type and use that as r & -(Cuns) r;
to avoid the UB, and there is no poly_uint_rtx_p or something to request
poly_uint64 from the rtx. Richard?
The second one is
return (!known_size_p (decl_size) || known_eq (decl_size, 0)
? maybe_ne (offset, 0)
: maybe_gt (offset + size, decl_size));
and again, both offset and size are poly_int64, not sure how can one
reinterpret cast that to poly_uint64 for the operation and then cast back to
poly_int64.
But in that case also if we shouldn't punt on the overflow somehow.
[Bug target/89929] __attribute__((target("avx512bw"))) doesn't work on non avx512bw systems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89929
--- Comment #16 from Nikolay Bogoychev ---
Created attachment 46187
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46187&action=edit
target("arch=foo") doesn't work
(In reply to Martin Liška from comment #15)
> @Nikolay:
>
> As discussed in https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00416.html
> email thread, we reached the following consensus with H.J:
>
> - As any AVX512 extensions (apart from AVX512F) can be enabled individually,
> it's difficult to come up with priorities in dispatcher.
> - We don't have a syntax for target_clone attribute where one would say e.g.
> avx512f+avx512cd+avx512er.
> - So that we would reject these (AVX512* except AVX512F) in target_clone
> attribute and we recommend to use rather.
> target_clones(arch=skylake,arch=skylake-avx512,arch=cannonlake,arch=icelake-
> client,arch=icelake-server, ..)
> - Using that one can cover used AVX512 ISA combinations for existing CPUs
>
> Does it work for you Nikolay?
@Martin:
Thank you for the detailed answer. This could work for now. I have a few
questions about it:
Wouldn't that create issues in the future if AMD decide to release avx512 for
their CPUs?
In case we are using C style target annotation (and not function
multi-versioning), should we also use target(arch=skylake-avx512) instead of
target(avx512bw)?
Also it seems that target("arch=foo") fails for my simple example with target
specific option mismatch error (but works in clang).
If I change target to avx2 it compiles again.
Cheers,
Nick
[Bug translation/90120] inconsistent punctuation in translation messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90120 --- Comment #3 from Claudiu Zissulescu --- Added a patch to solve upper/lower issue: https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00696.html
[Bug target/89929] __attribute__((target("avx512bw"))) doesn't work on non avx512bw systems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89929
--- Comment #17 from Martin Liška ---
>
> @Martin:
>
> Thank you for the detailed answer. This could work for now. I have a few
> questions about it:
>
> Wouldn't that create issues in the future if AMD decide to release avx512
> for their CPUs?
No, that will only require to add target(arch=amd-name-with-avx512).
>
> In case we are using C style target annotation (and not function
> multi-versioning), should we also use target(arch=skylake-avx512) instead of
> target(avx512bw)?
Yes. Let me discuss that with H.J.
>
> Also it seems that target("arch=foo") fails for my simple example with
> target specific option mismatch error (but works in clang).
>
> If I change target to avx2 it compiles again.
>
> Cheers,
>
> Nick
Let me investigate that.
[Bug tree-optimization/90128] New: 507.cactuBSSN_r is 9-11% slower at -Ofast and native march/tuning on Zen CPUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90128 Bug ID: 90128 Summary: 507.cactuBSSN_r is 9-11% slower at -Ofast and native march/tuning on Zen CPUs Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: jamborm at gcc dot gnu.org CC: rguenth at gcc dot gnu.org Blocks: 26163 Target Milestone: --- Host: x86_64-linux Target: x86_64-linux In my own measurements, 507.cactuBSSN_r is about 9.4% slower on an AMD Zen CPU when compiled with GCC 9 with -Ofast and native march/mtune than when it si compiled with GCC 8. LNT currently even shows 11.4% regression: https://lnt.opensuse.org/db_default/v4/SPEC/spec_report/branch I have done some bisecting and the slowdown happened in three steps. First, the benchmark slowed by about 2% at some point before r262510 which I have not tracked down yet. Second, it then dived 3% with r263874 but this seems to be some code-placement issue again because the assembly of the functions which gained perf samples has not changed in that revision and perf reported stalled-cycles-frontend went from 4.58% to 5.02%. However, the third regression was caused by the immediately following revision r263875, the difference is 4.5% (7.5% is compared to GCC 8 run-time) while perf reported stalled-cycles-frontend were only 4.05%. r263872 (good) perf stat and report: Performance counter stats for 'numactl -C 0 -l specinvoke': 238848.989836 task-clock:u (msec) #0.999 CPUs utilized 0 context-switches:u#0.000 K/sec 0 cpu-migrations:u #0.000 K/sec 92923 page-faults:u #0.389 K/sec 758195547230 cycles:u #3.174 GHz (83.33%) 34727040659 stalled-cycles-frontend:u #4.58% frontend cycles idle (83.33%) 15457735869 stalled-cycles-backend:u #2.04% backend cycles idle (83.33%) 1225370192228 instructions:u#1.62 insn per cycle #0.03 stalled cycles per insn (83.33%) 23031544594 branches:u# 96.427 M/sec (83.34%) 18985096 branch-misses:u #0.08% of all branches (83.33%) 239.158442295 seconds time elapsed # Event count (approx.): 758374775503 # # OverheadSamples Command Shared Object Symbol # . . . # 40.51% 387505 cactusBSSN_r cactusBSSN_r_peak ML_BSSN_RHS_Body 22.34% 214782 cactusBSSN_r cactusBSSN_r_peak ML_BSSN_Advect_Body 8.42% 80594 cactusBSSN_r cactusBSSN_r_peak ML_BSSN_constraints_Body 7.40% 70897 cactusBSSN_r libm-2.26.so __ieee754_exp_avx 5.77% 55393 cactusBSSN_r cactusBSSN_r_peak ML_BSSN_convertToADMBaseDtLapseShift_Body 4.99% 47952 cactusBSSN_r cactusBSSN_r_peak ML_BSSN_convertToADMBase_Body 2.98% 28573 cactusBSSN_r cactusBSSN_r_peak ML_BSSN_InitRHS_Body 2.44% 23623 cactusBSSN_r cactusBSSN_r_peak MoL_LinearCombination r263874 (worse) perf stat and report: Performance counter stats for 'numactl -C 0 -l specinvoke': 244036.523777 task-clock:u (msec) #0.999 CPUs utilized 0 context-switches:u#0.000 K/sec 0 cpu-migrations:u #0.000 K/sec 93013 page-faults:u #0.381 K/sec 774757677736 cycles:u #3.175 GHz (83.33%) 38930288027 stalled-cycles-frontend:u #5.02% frontend cycles idle (83.33%) 15508961324 stalled-cycles-backend:u #2.00% backend cycles idle (83.34%) 1226167776333 instructions:u#1.58 insn per cycle #0.03 stalled cycles per insn (83.33%) 23218262947 branches:u# 95.143 M/sec (83.33%) 18890390 branch-misses:u #0.08% of all branches (83.33%) 244.344340731 seconds time elapsed # Samples: 979K of event 'cycles' # Event count (approx.): 775138268715 # # OverheadSamples Command Shared Object Symbol # . . . # 41.43% 404835 cactusBSSN_r cactusBSSN_r_peak ML_BSSN_RHS_Body
[Bug target/79869] i18n: document placeholders for translators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79869 --- Comment #3 from Claudiu Zissulescu --- DOC is string that shortly describes an machine dependent option. This string is used to throw an warning/error when the underling option is not available for a specific architecture, which can be arcem, arc700, arc6xx or archs. The DOC definitions are in arc/arc-options.def The arches name are defined in arc/arc-arches.def
[Bug tree-optimization/90128] 507.cactuBSSN_r is 9-11% slower at -Ofast and native march/tuning on Zen CPUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90128 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-04-17 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- So the issue is in ML_BSSN_Advect_Body (the other function rebounded). I will have a look.
[Bug tree-optimization/90128] 507.cactuBSSN_r is 9-11% slower at -Ofast and native march/tuning on Zen CPUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90128 --- Comment #2 from Richard Biener --- Ugh. Cactus is really ugly code :/ For one there's an invariant switch () in the innermost loop, expanded to a binary tree (slightly different split point GCC 8 vs. trunk), obviously unswitching cannot handle this. This is a general missed optimization precluding any vectorization attempt here. Then we spill the hell out of us because of the way the code is written. Other than that I don't see anything obvious here. It might be that trunk: 5802: 83 fb 06cmp$0x6,%ebx 5805: 0f 84 25 84 00 00 je dc30 <_ZL19ML_BSSN_Advect_BodyPK4 _cGHiiPKdS3_S3_PKiS5_iPKPd+0xdc30> 580b: 0f 8f cf 1d 00 00 jg 75e0 <_ZL19ML_BSSN_Advect_BodyPK4_cGHiiPKdS3_S3_PKiS5_iPKPd+0x75e0> 5811: 83 fb 02cmp$0x2,%ebx 5814: 0f 85 06 c0 ff ff jne1820 <_ZL19ML_BSSN_Advect_BodyPK4_cGHiiPKdS3_S3_PKiS5_iPKPd+0x1820> is worse to the branch predictor than the GCC 8 version 89ee: 0f 84 bc 64 00 00 je eeb0 <_ZL19ML_BSSN_Advect_BodyPK4 _cGHiiPKdS3_S3_PKiS5_iPKPd+0xeeb0> 89f4: 0f 8e 96 45 00 00 jlecf90 <_ZL19ML_BSSN_Advect_BodyPK4_cGHiiPKdS3_S3_PKiS5_iPKPd+0xcf90> 89fa: 8b b4 24 a8 08 00 00mov0x8a8(%rsp),%esi 8a01: 83 fe 06cmp$0x6,%esi 8a04: 0f 85 e6 8e ff ff jne18f0 <_ZL19ML_BSSN_Advect_BodyPK4_cGHiiPKdS3_S3_PKiS5_iPKPd+0x18f0> (notice the "padding" reload). That is probably going to depend on final code layout again of course. I recall reading a third conditional jump in a fetch word requires an additional branch predictor slot or so. So it would be interesting to see if the branch misses accumulate on that binary tree generated from the loop invariant switch where in theory those should be all totally predictable. That said, I'm not yet able to reproduce the slowdown but will try.
[Bug target/89929] __attribute__((target("avx512bw"))) doesn't work on non avx512bw systems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89929
--- Comment #18 from Martin Liška ---
(In reply to Martin Liška from comment #17)
> >
> > @Martin:
> >
> > Thank you for the detailed answer. This could work for now. I have a few
> > questions about it:
> >
> > Wouldn't that create issues in the future if AMD decide to release avx512
> > for their CPUs?
>
> No, that will only require to add target(arch=amd-name-with-avx512).
>
> >
> > In case we are using C style target annotation (and not function
> > multi-versioning), should we also use target(arch=skylake-avx512) instead of
> > target(avx512bw)?
For C style, the functionality will be preserved as is.
>
> Yes. Let me discuss that with H.J.
>
> >
> > Also it seems that target("arch=foo") fails for my simple example with
> > target specific option mismatch error (but works in clang).
> >
> > If I change target to avx2 it compiles again.
This looks to me a bug, I'll create a separated PR for that.
Thanks
> >
> > Cheers,
> >
> > Nick
>
> Let me investigate that.
[Bug target/90129] New: Wrong error: inlining failed in call to always_inline ‘_mm256_adds_epi16’: target specific option mismatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90129
Bug ID: 90129
Summary: Wrong error: inlining failed in call to always_inline
‘_mm256_adds_epi16’: target specific option mismatch
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
Target Milestone: ---
Following code should be accepted:
$ cat pragma.c
#include
#include
#include
#pragma GCC target ("arch=haswell")
__m256i adds_epi16(__m256i first, __m256i second) {
return _mm256_adds_epi16(first, second);
}
But we reject that since for ever:
gcc pragma.c
In file included from
/usr/lib64/gcc/x86_64-suse-linux/8/include/immintrin.h:43,
from pragma.c:3:
pragma.c: In function ‘adds_epi16’:
/usr/lib64/gcc/x86_64-suse-linux/8/include/avx2intrin.h:140:1: error: inlining
failed in call to always_inline ‘_mm256_adds_epi16’: target specific option
mismatch
_mm256_adds_epi16 (__m256i __A, __m256i __B)
^
pragma.c:8:10: note: called from here
return _mm256_adds_epi16(first, second);
^~~~
While:
cat pragma.c && gcc pragma.c -march=haswell -c
#include
#include
#include
__m256i adds_epi16(__m256i first, __m256i second) {
return _mm256_adds_epi16(first, second);
}
is fine
[Bug tree-optimization/90128] 507.cactuBSSN_r is 9-11% slower at -Ofast and native march/tuning on Zen CPUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90128 --- Comment #3 from Martin Liška --- Direct graph link to branch comparison: https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=148.437.0&plot.1=59.437.0&plot.2=76.437.0&plot.3=33.437.0&;
[Bug target/90129] Wrong error: inlining failed in call to always_inline ‘_mm256_adds_epi16’: target specific option mismatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90129 --- Comment #1 from Richard Biener --- IIRC we have a duplicate for this (albeit with -msse2 vs. none)
[Bug tree-optimization/90128] 507.cactuBSSN_r is 9-11% slower at -Ofast and native march/tuning on Zen CPUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90128 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #4 from Martin Liška --- (In reply to Richard Biener from comment #2) > Ugh. Cactus is really ugly code :/ For one there's an invariant switch () > in the innermost loop, expanded to a binary tree (slightly different split > point > GCC 8 vs. trunk), obviously unswitching cannot handle this. Yes, the binary tree is bit different, but equally good to me: GCC 8: if (fdOrder_15741 == 4) goto ; [20.00%] else goto ; [80.00%] [local count: 955630223]: if (fdOrder_15741 > 4) goto ; [62.50%] else goto ; [37.50%] [local count: 955630223]: if (fdOrder_15741 == 2) goto ; [66.67%] else goto ; [33.33%] [local count: 955630223]: if (fdOrder_15741 == 6) goto ; [40.00%] else goto ; [60.00%] [local count: 955630223]: if (fdOrder_15741 == 8) goto ; [66.67%] else goto ; [33.33%] GCC 9: if (fdOrder_13024 == 6) goto ; [20.00%] else goto ; [80.00%] [local count: 955630224]: if (fdOrder_13024 > 6) goto ; [37.50%] else goto ; [62.50%] [local count: 955630224]: if (fdOrder_13024 == 2) goto ; [40.00%] else goto ; [60.00%] [local count: 955630224]: if (fdOrder_13024 == 4) goto ; [100.00%] else goto ; [0.00%] [local count: 955630224]: if (fdOrder_13024 == 8) goto ; [66.67%] else goto ; [33.33%]
[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #54 from Bernd Edlinger ---
Hmm, I see. What I am trying to accomplish is, put the target
attribute on every function that calls directly or in-directly
to CONTINUE_UNWINDING. And do that only for ARM.
For gdc_personality it is straight forward to do, as you pointed out.
But for __gdc_personality and scanLSDA what I would like to do is
static if (GNU_ARM_EABI_Unwinder)
{
@attribute("target", ("general-regs-only"))
}
private _Unwind_Reason_Code __gdc_personality(_Unwind_Action actions,
_Unwind_Exception_Class
exceptionClass,
_Unwind_Exception* unwindHeader,
_Unwind_Context* context)
{
...
but that does not work, what would work is
static if (GNU_ARM_EABI_Unwinder)
{
@attribute("target", ("general-regs-only"))
private _Unwind_Reason_Code __gdc_personality(_Unwind_Action actions,
_Unwind_Exception_Class
exceptionClass,
_Unwind_Exception* unwindHeader,
_Unwind_Context* context)
{
...
}
}
else
{
private _Unwind_Reason_Code __gdc_personality(_Unwind_Action actions,
_Unwind_Exception_Class
exceptionClass,
_Unwind_Exception* unwindHeader,
_Unwind_Context* context)
{
...
}
}
duplicating all that code is of course not an option.
[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #55 from Bernd Edlinger ---
But, how about that:
Index: deh.d
===
--- deh.d (revision 270395)
+++ deh.d (working copy)
@@ -28,6 +28,7 @@
import gcc.unwind.pe;
import gcc.builtins;
import gcc.config;
+import gcc.attribute;
extern(C)
{
@@ -519,10 +520,21 @@
terminate("unwind error", __LINE__);
}
+static if (GNU_ARM_EABI_Unwinder)
+{
+enum ATTRIBUTE_NAME = "target";
+enum ATTRIBUTE_ARGS = "general-regs-only";
+}
+else
+{
+enum ATTRIBUTE_NAME = "";
+enum ATTRIBUTE_ARGS = "";
+}
/**
* Read and extract information from the LSDA (.gcc_except_table section).
*/
+@attribute(ATTRIBUTE_NAME, (ATTRIBUTE_ARGS))
_Unwind_Reason_Code scanLSDA(const(ubyte)* lsda, _Unwind_Exception_Class
exceptionClass,
_Unwind_Action actions, _Unwind_Exception*
unwindHeader,
_Unwind_Context* context, _Unwind_Word cfa,
@@ -772,6 +784,7 @@
* Called when the personality function has found neither a cleanup or
handler.
* To support ARM EABI personality routines, that must also unwind the stack.
*/
+@attribute(ATTRIBUTE_NAME, (ATTRIBUTE_ARGS))
_Unwind_Reason_Code CONTINUE_UNWINDING(_Unwind_Exception* unwindHeader,
_Unwind_Context* context)
{
static if (GNU_ARM_EABI_Unwinder)
@@ -814,6 +827,7 @@
static if (GNU_ARM_EABI_Unwinder)
{
pragma(mangle, PERSONALITY_FUNCTION)
+@attribute(ATTRIBUTE_NAME, (ATTRIBUTE_ARGS))
extern(C) _Unwind_Reason_Code gdc_personality(_Unwind_State state,
_Unwind_Exception*
unwindHeader,
_Unwind_Context* context)
@@ -873,6 +887,7 @@
}
}
+@attribute(ATTRIBUTE_NAME, (ATTRIBUTE_ARGS))
private _Unwind_Reason_Code __gdc_personality(_Unwind_Action actions,
_Unwind_Exception_Class
exceptionClass,
_Unwind_Exception* unwindHeader,
[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #56 from Jakub Jelinek ---
Can't you just add prototypes?
Like:
static if (GNU_ARM_EABI_Unwinder)
{
@attribute("target", ("general-regs-only"))
private _Unwind_Reason_Code __gdc_personality(_Unwind_Action actions,
_Unwind_Exception_Class
exceptionClass,
_Unwind_Exception* unwindHeader,
_Unwind_Context* context);
}
etc. before the actual definitions? attribute ("", ("")) seems ugly.
[Bug tree-optimization/90128] 507.cactuBSSN_r is 9-11% slower at -Ofast and native march/tuning on Zen CPUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90128 --- Comment #5 from Richard Biener --- CPU 2006 436.cactusADM also has an interesting history: https://gcc.opensuse.org/gcc-old/SPEC/CFP/sb-czerny-head-64-2006/436_cactusADM_big.png
[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #57 from Bernd Edlinger ---
(In reply to Jakub Jelinek from comment #56)
> Can't you just add prototypes?
> Like:
> static if (GNU_ARM_EABI_Unwinder)
> {
> @attribute("target", ("general-regs-only"))
> private _Unwind_Reason_Code __gdc_personality(_Unwind_Action actions,
> _Unwind_Exception_Class
> exceptionClass,
> _Unwind_Exception*
> unwindHeader,
> _Unwind_Context* context);
> }
> etc. before the actual definitions? attribute ("", ("")) seems ugly.
I think that is worth a try. hang on...
[Bug tree-optimization/90128] 507.cactuBSSN_r is 9-11% slower at -Ofast and native march/tuning on Zen CPUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90128 --- Comment #6 from Richard Biener --- (In reply to Richard Biener from comment #5) > CPU 2006 436.cactusADM also has an interesting history: > https://gcc.opensuse.org/gcc-old/SPEC/CFP/sb-czerny-head-64-2006/ > 436_cactusADM_big.png compared to other benchmarks it is also quite noisy - esp. in the timeframe of this regression.
[Bug d/88150] Use sections_elf_shared.d on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88150 --- Comment #16 from Martin Nowak --- Regarding the dlopen/dlclose in handleForName, the semantics of RTLD_NOLOAD are so that it bumps the reference count if the library had been previously loaded. The sections module uses the handle as identifier to distinguish different DSOs and store metadata. Due to the self-registration mechanism of D DSOs (see _d_dso_registry) any D library remains loaded and (presumably) keeps the same handle if it is needed by the executable and loaded during startup. If a shared library is loaded dynamically, then the dlopen/dlclose actions will surround the calls to _d_dso_registry by the library, hence the handle should stay valid while until the DSO is unregistered. This is a lot of low-level plumbing (without going into private runtime linker structs) and semantics have been modeled after Linux and FreeBSD. If they differ on Solaris the code might indeed need some fixup. The RTLD_NOLOAD behavior of only inc-refing already loaded libs isn't well documented but seems like the only sensible one.
[Bug target/89929] __attribute__((target("avx512bw"))) doesn't work on non avx512bw systems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89929 --- Comment #19 from Nikolay Bogoychev --- (In reply to Martin Liška from comment #18) > (In reply to Martin Liška from comment #17) > > > > > > @Martin: > > > > > > Thank you for the detailed answer. This could work for now. I have a few > > > questions about it: > > > > > > Wouldn't that create issues in the future if AMD decide to release avx512 > > > for their CPUs? > > > > No, that will only require to add target(arch=amd-name-with-avx512). > > Does this mean that if I have an avx512bw+dq function, I'd have to have two identical versions of it that I have to target with arch=canonlake and arch=amd-something-with-avx512? Seems a bit... unellegant. > > > > > > > Cheers, > > > > > > Nick > > > > Let me investigate that. Thanks for opening the bug Cheers, Nick
[Bug target/90129] Wrong error: inlining failed in call to always_inline ‘_mm256_adds_epi16’: target specific option mismatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90129 Jakub Jelinek changed: What|Removed |Added CC||hjl.tools at gmail dot com, ||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- This one is because of: /* See if arch, tune, etc. are the same. */ else if (caller_opts->arch != callee_opts->arch) ret = false; For tune we ignore it if always_inline, the question is what should we do for arch for always_inline. I'm afraid we don't have a notion of arches being subset or superset of each other.
[Bug go/90110] [9 Regression] libgo fails to build against glibc 2.19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90110
--- Comment #4 from Ian Lance Taylor ---
Thanks for the file. Unfortunately it looks fine.
The error is coming from Import_function_body::read_type in
gcc/go/gofrontend/import.cc. At the point of the error this->body_ +
this->off_ points to a string starting with ",". The function starts
like this:
this->require_c_string("off_;
size_t i;
int c = '\0';
for (i = start; i < this->body_.length(); ++i)
{
c = static_cast(this->body_[i]);
if (c != '-' && (c < '0' || c > '9'))
break;
}
this->off_ = i + 1;
char *end;
long val = strtol(this->body_.substr(start, i - start).c_str(), &end, 10);
if (*end != '\0' || i > 0x7fff)
{
if (!this->saw_error_)
go_error_at(this->location(),
"invalid export data for %qs: expected integer at %lu",
this->name().c_str(),
static_cast(start));
this->saw_error_ = true;
return Type::make_error_type();
}
It skips ",". It steps past the "4".
Then it passes "4\0" to strtol. Somehow that is failing.
Since, needless to say, I can't reproduce the problem, do you have time to add
a bit of debugging around the strtol call, to see what is being passed and
returned?
[Bug target/90128] 507.cactuBSSN_r is 9-11% slower at -Ofast and native march/tuning on Zen CPUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90128 Richard Biener changed: What|Removed |Added Component|tree-optimization |target --- Comment #7 from Richard Biener --- Benchmarking r270408 on branch vs. trunk on Haswell doesn't show any regression for me. Will double-check with up-to-date CPU 2017 tree.
[Bug go/90110] [9 Regression] libgo fails to build against glibc 2.19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90110 --- Comment #5 from Andreas Schwab --- What is the condition i > 0x7fff for? Shouldn't that test val instead?
[Bug middle-end/90095] [9 Regression] wrong code with -Os -fno-tree-bit-ccp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90095 --- Comment #5 from Jakub Jelinek --- Author: jakub Date: Wed Apr 17 13:28:39 2019 New Revision: 270410 URL: https://gcc.gnu.org/viewcvs?rev=270410&root=gcc&view=rev Log: PR middle-end/90095 * internal-fn.c (expand_mul_overflow): Don't set SUBREG_PROMOTED_VAR_P on lowpart SUBREGs. * gcc.dg/pr90095-1.c: New test. * gcc.dg/pr90095-2.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr90095-1.c trunk/gcc/testsuite/gcc.dg/pr90095-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/internal-fn.c trunk/gcc/testsuite/ChangeLog
[Bug go/90110] [9 Regression] libgo fails to build against glibc 2.19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90110
--- Comment #6 from rguenther at suse dot de ---
On Wed, 17 Apr 2019, ian at airs dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90110
>
> --- Comment #4 from Ian Lance Taylor ---
> Thanks for the file. Unfortunately it looks fine.
>
> The error is coming from Import_function_body::read_type in
> gcc/go/gofrontend/import.cc. At the point of the error this->body_ +
> this->off_ points to a string starting with ",". The function starts
> like this:
>
> this->require_c_string(" size_t start = this->off_;
> size_t i;
> int c = '\0';
> for (i = start; i < this->body_.length(); ++i)
> {
> c = static_cast(this->body_[i]);
> if (c != '-' && (c < '0' || c > '9'))
> break;
> }
> this->off_ = i + 1;
>
> char *end;
> long val = strtol(this->body_.substr(start, i - start).c_str(), &end, 10);
Just a wild guess - does this->body_.substr(start, i - start).c_str()
really live until after strtol has completed? IIRC I saw this kind
of errors in other codes... since the temporary std::string isn't
passed to the function it should be destroyed. Assuming this->body_
is a std::string, of course.
Using profiledbootstrap might just expose this "issue" I guess.
Trying whether
Index: gcc/go/gofrontend/import.cc
===
--- gcc/go/gofrontend/import.cc (revision 270403)
+++ gcc/go/gofrontend/import.cc (working copy)
@@ -1478,7 +1478,8 @@ Import_function_body::read_type()
this->off_ = i + 1;
char *end;
- long val = strtol(this->body_.substr(start, i - start).c_str(), &end,
10);
+ std::string subs = this->body_.substr(start, i - start);
+ long val = strtol(subs.c_str(), &end, 10);
if (*end != '\0' || i > 0x7fff)
{
if (!this->saw_error_)
fixes the issue for me (will report back tomorrow). Just in case
this is indeed an obvious error feel free to fix faster than that ;)
[Bug target/89929] __attribute__((target("avx512bw"))) doesn't work on non avx512bw systems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89929
--- Comment #20 from Martin Liška ---
>
> Does this mean that if I have an avx512bw+dq function, I'd have to have two
> identical versions of it that I have to target with arch=canonlake and
> arch=amd-something-with-avx512? Seems a bit... unellegant.
>
If you use target_clone attribute of target attribute in C++ (with
automatically generated resolver function), then yes. You'll need 2 functions,
but you can use alias as seen here:
void xxx () { __builtin_printf ("haswell or skylake CPU\n"); }
void __attribute__ ((target("arch=haswell"),alias("_Z3xxxv"))) foo ();
void __attribute__ ((target("arch=skylake-avx512"),alias("_Z3xxxv"))) foo ();
void __attribute__ ((target("arch=skylake"))) foo () {}
void __attribute__ ((target("default"))) foo () {}
int main()
{
foo ();
return 0;
}
[Bug target/90128] 507.cactuBSSN_r is 9-11% slower at -Ofast and native march/tuning on Zen CPUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90128 --- Comment #8 from Richard Biener --- (In reply to Richard Biener from comment #7) > Benchmarking r270408 on branch vs. trunk on Haswell doesn't show any > regression > for me. Will double-check with up-to-date CPU 2017 tree. Confirmed.
[Bug rtl-optimization/87871] [9 Regression] testcases fail after r265398 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871 --- Comment #30 from Jakub Jelinek --- Is the *movsi_compare0 pattern actually ever a benefit before RA? At least in this case it clearly results in a worse generated code rather than better, and I bet in other cases too, it just ties the hands of the RA too much. I wonder if it better shouldn't be a pattern that is only matched when reload_completed and recognized say by a peephole2 or something similar.
[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #58 from Bernd Edlinger ---
No, sorry, the attribute on the prototype gets ignored, as the following
is compiled without generating an error:
private int test(double x)
{
return x > 1.0;
}
static if (GNU_ARM_EABI_Unwinder)
{
@attribute("target", ("general-regs-only"))
private _Unwind_Reason_Code __gdc_personality(_Unwind_Action actions,
_Unwind_Exception_Class
exceptionClass,
_Unwind_Exception*
unwindHeader,
_Unwind_Context* context);
}
private _Unwind_Reason_Code __gdc_personality(_Unwind_Action actions,
_Unwind_Exception_Class
exceptionClass,
_Unwind_Exception* unwindHeader,
_Unwind_Context* context)
{
const(ubyte)* lsda;
_Unwind_Ptr landingPad;
_Unwind_Word cfa;
int handler;
test(3.14);
// Shortcut for phase 2 found handler for domestic exception.
if (actions == (_UA_CLEANUP_PHASE | _UA_HANDLER_FRAME)
&& isGdcExceptionClass(exceptionClass))
{
ExceptionHeader.restore(unwindHeader, handler, lsda, landingPad, cfa);
but with the previous patch calling test(3.14) gives this:
../../../../gcc-trunk/libphobos/libdruntime/gcc/deh.d: In function
'__gdc_personality':
../../../../gcc-trunk/libphobos/libdruntime/gcc/deh.d:906:1: error: argument of
type 'double' not permitted with -mgeneral-regs-only
906 | test(3.14);
| ^
[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093 --- Comment #59 from Jakub Jelinek --- That looks like a D FE bug then. In any case, why can't you just use -mgeneral-regs-only on the deh.d compilation command line?
[Bug d/90130] gdc.test/runnable/test12.d FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90130 Rainer Orth changed: What|Removed |Added Target Milestone|--- |9.0
[Bug d/90130] New: gdc.test/runnable/test12.d FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90130
Bug ID: 90130
Summary: gdc.test/runnable/test12.d FAILs
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: ro at gcc dot gnu.org
Target Milestone: ---
Target: sparc*-*-solaris2.11
The gdc.test/runnable/test12.d test FAILs on Solaris 11/SPARC with Robin's
big-endian
patches applied:
FAIL: gdc.test/runnable/test12.d -finline-functions -funittest -g execution
test
core.exception.AssertError@runnable/test12.d(630): Assertion failure
/vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/gcc/deh.d:499 _d_throw
[0x1001bb58f]
/vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/core/exception.d:441
onAssertError [0x1001b880b]
/vol/gcc/src/hg/trunk/solaris/libphobos/libdruntime/core/exception.d:641
_d_assert [0x1001b8e13]
runnable/test12.d:630 int test12.hoge(test12.S29) [0x100112ddf]
runnable/test12.d:642 void test12.test29() [0x100112e4b]
runnable/test12.d:1220 _Dmain [0x100114fc7]
Thread 2 hit Breakpoint 1, test12.hoge(test12.S29) (s=...)
at runnable/test12.d:624
624 char[10] b;
(gdb) n
625 printf("%x\n", s);
(gdb) p s
$1 = {a = 1 '\001', b = 2 '\002', c = 3 '\003', d = 4 '\004'}
(gdb) n
ffbfe4d0
626 sprintf(b.ptr, "%x", s);
(gdb) n
630 assert(b[0 .. 7] == "1020304");
(gdb) p b
$2 = "ffbfe4d0\000\377"
This ia another call-by-value vs. call-by-reference issue: the test assumes
that passing a small struct (struct S29) happens by value. While this is true
in some ABIs, it's certainly not in others (like the 32-bit SPARC one) where
even small structs are passed by reference. PR d/90079 is another instance
of the same problem.
(gdb) p/x *&s
$11 = {a = 0x1, b = 0x2, c = 0x3, d = 0x4}
(gdb) p s
$12 = {a = 1 '\001', b = 2 '\002', c = 3 '\003', d = 4 '\004'}
(gdb) p/x *(int *)&s
$13 = 0x1020304
However, the test also FAILs on 64-bit SPARC where small structs *are* passed
by value:
(gdb) p s
$1 = {a = 1 '\001', b = 2 '\002', c = 3 '\003', d = 4 '\004'}
(gdb) p b
$2 = "\000\000\000\000\000\000\000\000\000"
(gdb) n
625 printf("%x\n", s);
(gdb) n
0
626 sprintf(b.ptr, "%x", s);
(gdb) n
630 assert(b[0 .. 7] == "1020304");
(gdb) p b
$3 = "0\000\377\377\377\377\377\377\377\377"
(gdb) p/x *(int *)&s
$9 = 0x1020304
I don't fully see why yet, however all this strongly argues that this part of
testcase is bogus: you cannot pass a struct to sprintf whose format string
expects an int.
[Bug go/90110] [9 Regression] libgo fails to build against glibc 2.19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90110 --- Comment #7 from Ian Lance Taylor --- > What is the condition i > 0x7fff for? Shouldn't that test val instead? Yes, it certainly should. Thanks. It's not the problem here, but should be fixed. > Just a wild guess - does this->body_.substr(start, i - start).c_str() really live until after strtol has completed? I *think* it should be OK. The rule in C++ is that temporary objects are destroyed after the full expression that lexically contains the point at which they are created has been evaluated. In this case the full expression is the call to strtol, so the temporary object created by the call to substr should live until the call to strtol is complete.
[Bug go/90110] [9 Regression] libgo fails to build against glibc 2.19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90110 Florian Weimer changed: What|Removed |Added CC||fw at gcc dot gnu.org --- Comment #8 from Florian Weimer --- (In reply to Ian Lance Taylor from comment #7) > > What is the condition i > 0x7fff for? Shouldn't that test val instead? > > Yes, it certainly should. Thanks. It's not the problem here, but should be > fixed. > > > Just a wild guess - does this->body_.substr(start, i - start).c_str() > really live until after strtol has completed? > > I *think* it should be OK. The rule in C++ is that temporary objects are > destroyed after the full expression that lexically contains the point at > which they are created has been evaluated. In this case the full expression > is the call to strtol, so the temporary object created by the call to substr > should live until the call to strtol is complete. I think the *end != '\0' check is the problem here. The temporary object is gone at that point.
[Bug debug/90131] New: wrong debug info at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90131
Bug ID: 90131
Summary: wrong debug info at -O3
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: qrzhang at gatech dot edu
Target Milestone: ---
This issue is similar to bug 90074 --- same flag, same gcc versions. The
bisection also points to r255267. It appears that the issue remains after the
patch.
$ gcc-trunk -v
gcc version 9.0.1 20190417 (experimental) [trunk revision 270407] (GCC)
$ gdb -v
GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1
#Wrong result#
$ gcc-trunk -g abc.c outer.c -O3
$ gdb -x cmds -batch a.out
Breakpoint 1 at 0x40040f: file abc.c, line 16.
Breakpoint 1, main () at abc.c:16
16optimize_me_not();
$1 = 9
#Correct result#
$ gcc-trunk -g abc.c outer.c
$ gdb -x cmds -batch a.out
Breakpoint 1 at 0x4004c8: file abc.c, line 16.
Breakpoint 1, main () at abc.c:16
16optimize_me_not();
$1 = 0
$ cat abc.c
volatile long a;
int b[9][1];
static short c[2][1] = {3};
int main() {
int i, d, e;
i = 0;
for (; i < 9; i++)
a = b[i][0];
i = 0;
for (; i < 2; i++) {
d = 0;
for (; d < 1; d++) {
e = 0;
for (; e < 1; e++)
a = c[i][e];
optimize_me_not();
}
}
}
$ cat outer.c
void optimize_me_not() {}
$ cat cmds
b 16
r
p i
kill
q
[Bug web/90127] Disable bugzilla [[wiki_links]] and don't confuse r12 register names with r12345 svn revisions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90127 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #3 from Eric Gallager --- oh yeah this has been bothering me for a while now; good to see an effort to finally do something about it!
[Bug c++/88136] -Wdeprecated-copy is draconian and shouldn't be in -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88136 maic changed: What|Removed |Added CC||maic23 at live dot de --- Comment #8 from maic --- Indeed this will be hit even when the own code has no issue, but qt headers are included. See also https://github.com/bitcoin/bitcoin/issues/15822
[Bug target/89736] New test pr87532-mc.c fails on compiler not defaulting to VSX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89736 --- Comment #5 from kelvin at gcc dot gnu.org --- Author: kelvin Date: Wed Apr 17 15:40:12 2019 New Revision: 270413 URL: https://gcc.gnu.org/viewcvs?rev=270413&root=gcc&view=rev Log: gcc/ChangeLog: 2019-04-17 Kelvin Nilsen Backport from mainline 2019-03-15 Kelvin Nilsen PR target/87532 * config/rs6000/rs6000-c.c (altivec_resolve_overloaded_builtin): When handling vec_extract, use modular arithmetic to allow constant selectors greater than vector length. * config/rs6000/rs6000.c (rs6000_expand_vector_extract): Allow V1TImode vectors to have constant selector values greater than 0. Use modular arithmetic to compute vector index. (rs6000_split_vec_extract_var): Use modular arithmetic to compute index for in-memory vectors. Correct code generation for in-register vectors. Use inner mode of vector rather than mode of destination for move instruction. (altivec_expand_vec_ext_builtin): Use modular arithmetic to compute index. 2019-04-12 Kelvin Nilsen PR target/87532 * config/rs6000/vsx.md (*vsx_extract__mode_var): Use QI inner mode with V16QI vector mode. gcc/testsuite/ChangeLog: 2019-04-17 Kelvin Nilsen Backport from mainline 2019-03-15 Kelvin Nilsen PR target/87532 * gcc.target/powerpc/pr87532.c: New test. * gcc.target/powerpc/vec-extract-v16qiu-v2.h: New test. * gcc.target/powerpc/vec-extract-v16qiu-v2a.c: New test. * gcc.target/powerpc/vec-extract-v16qiu-v2b.c: New test. * gcc.target/powerpc/vsx-builtin-10a.c: New test. * gcc.target/powerpc/vsx-builtin-10b.c: New test. * gcc.target/powerpc/vsx-builtin-11a.c: New test. * gcc.target/powerpc/vsx-builtin-11b.c: New test. * gcc.target/powerpc/vsx-builtin-12a.c: New test. * gcc.target/powerpc/vsx-builtin-12b.c: New test. * gcc.target/powerpc/vsx-builtin-13a.c: New test. * gcc.target/powerpc/vsx-builtin-13b.c: New test. * gcc.target/powerpc/vsx-builtin-14a.c: New test. * gcc.target/powerpc/vsx-builtin-14b.c: New test. * gcc.target/powerpc/vsx-builtin-15a.c: New test. * gcc.target/powerpc/vsx-builtin-15b.c: New test. * gcc.target/powerpc/vsx-builtin-16a.c: New test. * gcc.target/powerpc/vsx-builtin-16b.c: New test. * gcc.target/powerpc/vsx-builtin-17a.c: New test. * gcc.target/powerpc/vsx-builtin-17b.c: New test. * gcc.target/powerpc/vsx-builtin-18a.c: New test. * gcc.target/powerpc/vsx-builtin-18b.c: New test. * gcc.target/powerpc/vsx-builtin-19a.c: New test. * gcc.target/powerpc/vsx-builtin-19b.c: New test. * gcc.target/powerpc/vsx-builtin-20a.c: New test. * gcc.target/powerpc/vsx-builtin-20b.c: New test. * gcc.target/powerpc/vsx-builtin-9a.c: New test. * gcc.target/powerpc/vsx-builtin-9b.c: New test. 2019-03-19 Kelvin Nilsen PR target/89736 * gcc.target/powerpc/pr87532-mc.c: Modify dejagnu directives to restrict this test to vsx targets. Added: branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/pr87532-mc.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/pr87532.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vec-extract-v16qiu-v2.h branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vec-extract-v16qiu-v2a.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vec-extract-v16qiu-v2b.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-10a.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-10b.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-11a.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-11b.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-12a.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-12b.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-13a.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-13b.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-14a.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-14b.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-15a.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-15b.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-16a.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-16b.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-17a.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-17b.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-18a.c branches/gcc-8-branch/gcc/testsuite/gcc
[Bug target/87532] bad results from vec_extract(unsigned char, foo) dependent upon function inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87532 --- Comment #18 from kelvin at gcc dot gnu.org --- Author: kelvin Date: Wed Apr 17 15:40:12 2019 New Revision: 270413 URL: https://gcc.gnu.org/viewcvs?rev=270413&root=gcc&view=rev Log: gcc/ChangeLog: 2019-04-17 Kelvin Nilsen Backport from mainline 2019-03-15 Kelvin Nilsen PR target/87532 * config/rs6000/rs6000-c.c (altivec_resolve_overloaded_builtin): When handling vec_extract, use modular arithmetic to allow constant selectors greater than vector length. * config/rs6000/rs6000.c (rs6000_expand_vector_extract): Allow V1TImode vectors to have constant selector values greater than 0. Use modular arithmetic to compute vector index. (rs6000_split_vec_extract_var): Use modular arithmetic to compute index for in-memory vectors. Correct code generation for in-register vectors. Use inner mode of vector rather than mode of destination for move instruction. (altivec_expand_vec_ext_builtin): Use modular arithmetic to compute index. 2019-04-12 Kelvin Nilsen PR target/87532 * config/rs6000/vsx.md (*vsx_extract__mode_var): Use QI inner mode with V16QI vector mode. gcc/testsuite/ChangeLog: 2019-04-17 Kelvin Nilsen Backport from mainline 2019-03-15 Kelvin Nilsen PR target/87532 * gcc.target/powerpc/pr87532.c: New test. * gcc.target/powerpc/vec-extract-v16qiu-v2.h: New test. * gcc.target/powerpc/vec-extract-v16qiu-v2a.c: New test. * gcc.target/powerpc/vec-extract-v16qiu-v2b.c: New test. * gcc.target/powerpc/vsx-builtin-10a.c: New test. * gcc.target/powerpc/vsx-builtin-10b.c: New test. * gcc.target/powerpc/vsx-builtin-11a.c: New test. * gcc.target/powerpc/vsx-builtin-11b.c: New test. * gcc.target/powerpc/vsx-builtin-12a.c: New test. * gcc.target/powerpc/vsx-builtin-12b.c: New test. * gcc.target/powerpc/vsx-builtin-13a.c: New test. * gcc.target/powerpc/vsx-builtin-13b.c: New test. * gcc.target/powerpc/vsx-builtin-14a.c: New test. * gcc.target/powerpc/vsx-builtin-14b.c: New test. * gcc.target/powerpc/vsx-builtin-15a.c: New test. * gcc.target/powerpc/vsx-builtin-15b.c: New test. * gcc.target/powerpc/vsx-builtin-16a.c: New test. * gcc.target/powerpc/vsx-builtin-16b.c: New test. * gcc.target/powerpc/vsx-builtin-17a.c: New test. * gcc.target/powerpc/vsx-builtin-17b.c: New test. * gcc.target/powerpc/vsx-builtin-18a.c: New test. * gcc.target/powerpc/vsx-builtin-18b.c: New test. * gcc.target/powerpc/vsx-builtin-19a.c: New test. * gcc.target/powerpc/vsx-builtin-19b.c: New test. * gcc.target/powerpc/vsx-builtin-20a.c: New test. * gcc.target/powerpc/vsx-builtin-20b.c: New test. * gcc.target/powerpc/vsx-builtin-9a.c: New test. * gcc.target/powerpc/vsx-builtin-9b.c: New test. 2019-03-19 Kelvin Nilsen PR target/89736 * gcc.target/powerpc/pr87532-mc.c: Modify dejagnu directives to restrict this test to vsx targets. Added: branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/pr87532-mc.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/pr87532.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vec-extract-v16qiu-v2.h branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vec-extract-v16qiu-v2a.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vec-extract-v16qiu-v2b.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-10a.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-10b.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-11a.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-11b.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-12a.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-12b.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-13a.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-13b.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-14a.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-14b.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-15a.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-15b.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-16a.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-16b.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-17a.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-17b.c branches/gcc-8-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-18a.c branches/gcc-8-branch/gcc/testsuite/gc
[Bug rtl-optimization/87871] [9 Regression] testcases fail after r265398 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871 --- Comment #31 from Segher Boessenkool --- It's how you do a parallel of a mov and a flags set, which of course you can have before RA, and you want created by combine, typically. Or do I misunderstand the question? (I though Arm have a "movs" op for this, btw?)
[Bug middle-end/85164] poly-int.h:845:5: runtime error: signed integer overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85164
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
--- Comment #6 from rsandifo at gcc dot gnu.org
---
(In reply to Jakub Jelinek from comment #5)
> The first above is on:
> case MINUS:
> /* If X is (minus C Y) where C's least set bit is larger than any bit
> in the mask, then we may replace with (neg Y). */
> if (poly_int_rtx_p (XEXP (x, 0), &const_op0)
> && (unsigned HOST_WIDE_INT) known_alignment (const_op0) > mask)
> and
> template
> inline POLY_BINARY_COEFF (Ca, Ca)
> known_alignment (const poly_int_pod &a)
> {
> typedef POLY_BINARY_COEFF (Ca, Ca) C;
> C r = a.coeffs[0];
> for (unsigned int i = 1; i < N; ++i)
> r |= a.coeffs[i];
> return r & -r;
> }
>
> The poly_int* stuff makes this much harder to fix, it is unclear if there is
> some way to get the unsigned type for the C type and use that as r & -(Cuns)
> r;
> to avoid the UB, and there is no poly_uint_rtx_p or something to request
> poly_uint64 from the rtx. Richard?
Changing:
(unsigned HOST_WIDE_INT) known_alignment (const_op0)
to:
known_alignment (poly_uint64 (const_op0))
should work.
>
> The second one is
> return (!known_size_p (decl_size) || known_eq (decl_size, 0)
> ? maybe_ne (offset, 0)
> : maybe_gt (offset + size, decl_size));
> and again, both offset and size are poly_int64, not sure how can one
> reinterpret cast that to poly_uint64 for the operation and then cast back to
> poly_int64.
Normal casts between poly_X and poly_Y work if casts between X and Y work.
> But in that case also if we shouldn't punt on the overflow somehow.
I guess using known_subrange_p would do that.
[Bug tree-optimization/85762] [8/9 Regression] range-v3 abstraction overhead not optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85762 --- Comment #10 from Martin Jambor --- Author: jamborm Date: Wed Apr 17 15:52:16 2019 New Revision: 270414 URL: https://gcc.gnu.org/viewcvs?rev=270414&root=gcc&view=rev Log: 2019-04-17 Martin Jambor Backport from mainline 2019-03-10 Martin Jambor PR tree-optimization/85762 PR tree-optimization/87008 PR tree-optimization/85459 * tree-sra.c (contains_vce_or_bfcref_p): New parameter, set the bool it points to if there is a type changing MEM_REF. Adjust all callers. (build_accesses_from_assign): Disable total scalarization if contains_vce_or_bfcref_p returns true through the new parameter, for both rhs and lhs. testsuite/ * g++.dg/tree-ssa/pr87008.C: New test. * gcc.dg/guality/pr54970.c: Xfail tests querying a[0] everywhere. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/tree-ssa/pr87008.C Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/testsuite/gcc.dg/guality/pr54970.c branches/gcc-8-branch/gcc/tree-sra.c
[Bug tree-optimization/85459] [8 Regression] Larger code generated from GMP template meta-programming
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85459 --- Comment #12 from Martin Jambor --- Author: jamborm Date: Wed Apr 17 15:52:16 2019 New Revision: 270414 URL: https://gcc.gnu.org/viewcvs?rev=270414&root=gcc&view=rev Log: 2019-04-17 Martin Jambor Backport from mainline 2019-03-10 Martin Jambor PR tree-optimization/85762 PR tree-optimization/87008 PR tree-optimization/85459 * tree-sra.c (contains_vce_or_bfcref_p): New parameter, set the bool it points to if there is a type changing MEM_REF. Adjust all callers. (build_accesses_from_assign): Disable total scalarization if contains_vce_or_bfcref_p returns true through the new parameter, for both rhs and lhs. testsuite/ * g++.dg/tree-ssa/pr87008.C: New test. * gcc.dg/guality/pr54970.c: Xfail tests querying a[0] everywhere. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/tree-ssa/pr87008.C Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/testsuite/gcc.dg/guality/pr54970.c branches/gcc-8-branch/gcc/tree-sra.c
[Bug tree-optimization/87008] [8 Regression] gimple mem-to-mem assignment badly optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87008 --- Comment #12 from Martin Jambor --- Author: jamborm Date: Wed Apr 17 15:52:16 2019 New Revision: 270414 URL: https://gcc.gnu.org/viewcvs?rev=270414&root=gcc&view=rev Log: 2019-04-17 Martin Jambor Backport from mainline 2019-03-10 Martin Jambor PR tree-optimization/85762 PR tree-optimization/87008 PR tree-optimization/85459 * tree-sra.c (contains_vce_or_bfcref_p): New parameter, set the bool it points to if there is a type changing MEM_REF. Adjust all callers. (build_accesses_from_assign): Disable total scalarization if contains_vce_or_bfcref_p returns true through the new parameter, for both rhs and lhs. testsuite/ * g++.dg/tree-ssa/pr87008.C: New test. * gcc.dg/guality/pr54970.c: Xfail tests querying a[0] everywhere. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/tree-ssa/pr87008.C Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/testsuite/gcc.dg/guality/pr54970.c branches/gcc-8-branch/gcc/tree-sra.c
[Bug tree-optimization/85459] [8 Regression] Larger code generated from GMP template meta-programming
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85459 Martin Jambor changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #13 from Martin Jambor --- And fixed on the gcc-8-branch too.
