[Bug middle-end/78174] out of bounds array subscript in rtl.h NOTE_DATA macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78174
--- Comment #9 from Jakub Jelinek ---
No, I've also explained what to do about the u.fld thing.
sed -n '/^DEF_RTL_EXPR/{s/DEF_RTL_EXPR([^,]*,[^,]*, "//;s/".*$//;p}' rtl.def |
sort -u
shows we have at most 8 fields right now, so we could define some macro to 8
and replace
rtunion fld[1];
with
rtunion fld[RTL_FLD_MAX_COUNT];
plus some verification (selftest) that no RTL format not containing w is longer
than that.
Similarly for
HOST_WIDE_INT hwint[1];
We probably can't use real.h here, so again we have to live with some maximum,
real.h shows
the longest supported REAL_WIDTH is 6.
Then in struct tree_exp we have:
tree GTY ((special ("tree_exp"),
desc ("TREE_CODE ((tree) &%0)")))
operands[1];
which have I think maximum of 7 right now (again, we'd need macro and self test
verification).
Then struct tree_omp_clause has:
tree GTY ((length ("omp_clause_num_ops[OMP_CLAUSE_CODE ((tree)&%h)]")))
ops[1];
and in that case the maximum is 5.
The question is if we ever just have a struct rtx_def, struct tree_exp etc. or
some struct
that contains those as a field or class that has those as a base as a global
variable or
automatic variable, such changes would change it obviously. Most of it is
allocated
through corresponding tree or rtl allocators and allocates offsetof (...,
field) + length.
We'd be trading one kind of pedantic undefined behavior for another one I bet,
right now
we often have larger objects than what the compiler can see and thus use the
"flexible-array-like"
extension we probably don't document very well, but support nevertheless - too
much code
in the wild would break otherwise. And with the above proposed changes we'd
turn it into something
different, the compiler would be told the structures are large, but in reality
they would be shorter,
the compiler couldn't rely in all of the structure to be readable etc. (that
actually is the case
now too, e.g. for RTLs with zero operands or OpenMP clauses with zero
operands).
But it would shut up coverity and other static analyzers. Perhaps we should do
it only
conditionally (in some compilation modes) that would be enabled for those
static analyzers.
GCC isn't alone that uses techniques like this and so warning about it is not
really useful.
[Bug middle-end/78174] out of bounds array subscript in rtl.h NOTE_DATA macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78174 --- Comment #10 from Jakub Jelinek --- Other such spots are in gimple.h (e.g. gimple_statement_with_ops, gimple_statement_with_memory_ops, gcall, gphi, gasm. Most likely we have other spots with that.
[Bug middle-end/78047] [5/6/7 Regression] Chromium apparently gets miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78047 Richard Biener changed: What|Removed |Added Known to work||7.0 Target Milestone|7.0 |5.5 Summary|[7 Regression] Chromium |[5/6/7 Regression] Chromium |apparently gets miscompiled |apparently gets miscompiled --- Comment #9 from Richard Biener --- Fixed on trunk. I'm going to backport for the latent wrong-PTA issue. --- Comment #10 from Richard Biener --- Author: rguenth Date: Wed Nov 2 08:13:29 2016 New Revision: 241775 URL: https://gcc.gnu.org/viewcvs?rev=241775&root=gcc&view=rev Log: 2016-11-02 Richard Biener PR tree-optimization/78047 * tree-ssa-structalias.c (push_fields_onto_fieldstack): Initialize fake field at offset zero conservatively regarding to may_have_pointers. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-structalias.c
[Bug middle-end/78047] [5/6/7 Regression] Chromium apparently gets miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78047 Richard Biener changed: What|Removed |Added Known to work||7.0 Target Milestone|7.0 |5.5 Summary|[7 Regression] Chromium |[5/6/7 Regression] Chromium |apparently gets miscompiled |apparently gets miscompiled --- Comment #9 from Richard Biener --- Fixed on trunk. I'm going to backport for the latent wrong-PTA issue. --- Comment #10 from Richard Biener --- Author: rguenth Date: Wed Nov 2 08:13:29 2016 New Revision: 241775 URL: https://gcc.gnu.org/viewcvs?rev=241775&root=gcc&view=rev Log: 2016-11-02 Richard Biener PR tree-optimization/78047 * tree-ssa-structalias.c (push_fields_onto_fieldstack): Initialize fake field at offset zero conservatively regarding to may_have_pointers. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-structalias.c
[Bug fortran/77679] [6 Regression] ICE in fold_array_ctor_reference, at gimple-fold.c:5586
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77679 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Richard Biener --- .
[Bug middle-end/77964] [7 Regression] Linux kernel firmware loader miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77964 --- Comment #18 from Richard Biener --- Author: rguenth Date: Wed Nov 2 08:29:48 2016 New Revision: 241776 URL: https://gcc.gnu.org/viewcvs?rev=241776&root=gcc&view=rev Log: 2016-11-02 Richard Biener PR tree-optimization/78035 PR tree-optimization/77964 * gimple-pretty-print.c (pp_points_to_solution): Print vars_contains_interposable. * tree-ssa-alias.c: Include varasm.h. (ptrs_compare_unequal): Check vars_contains_interposable and decl_binds_to_current_def_p. (dump_points_to_solution): Dump vars_contains_interposable. * tree-ssa-alias.h (struct pt_solution): Add vars_contains_interposable flag. * tree-ssa-structalias.c: Include varasm.h. (set_uids_in_ptset): Record whether vars contains a not decl_binds_to_current_def_p variable in vars_contains_interposable. (ipa_escaped_pt): Update initializer. * gcc.target/i386/pr78035.c: New testcase. Added: trunk/gcc/testsuite/gcc.target/i386/pr78035.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-pretty-print.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-alias.c trunk/gcc/tree-ssa-alias.h trunk/gcc/tree-ssa-structalias.c
[Bug tree-optimization/78035] Inconsistency between address comparison and alias analysis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78035 --- Comment #7 from Richard Biener --- Author: rguenth Date: Wed Nov 2 08:29:48 2016 New Revision: 241776 URL: https://gcc.gnu.org/viewcvs?rev=241776&root=gcc&view=rev Log: 2016-11-02 Richard Biener PR tree-optimization/78035 PR tree-optimization/77964 * gimple-pretty-print.c (pp_points_to_solution): Print vars_contains_interposable. * tree-ssa-alias.c: Include varasm.h. (ptrs_compare_unequal): Check vars_contains_interposable and decl_binds_to_current_def_p. (dump_points_to_solution): Dump vars_contains_interposable. * tree-ssa-alias.h (struct pt_solution): Add vars_contains_interposable flag. * tree-ssa-structalias.c: Include varasm.h. (set_uids_in_ptset): Record whether vars contains a not decl_binds_to_current_def_p variable in vars_contains_interposable. (ipa_escaped_pt): Update initializer. * gcc.target/i386/pr78035.c: New testcase. Added: trunk/gcc/testsuite/gcc.target/i386/pr78035.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-pretty-print.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-alias.c trunk/gcc/tree-ssa-alias.h trunk/gcc/tree-ssa-structalias.c
[Bug tree-optimization/78035] Inconsistency between address comparison and alias analysis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78035 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Richard Biener --- Fixed.
[Bug fortran/78178] ICE in WHERE statement with diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78178 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener --- Fixed.
[Bug fortran/69544] [5/6/7 Regression] Internal compiler error with -Wall and where
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69544 Bug 69544 depends on bug 78178, which changed state. Bug 78178 Summary: ICE in WHERE statement with diagnostic https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78178 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug ada/78175] [Ada] Storage_Error stack overflow or erroneous memory access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78175 Richard Biener changed: What|Removed |Added Target||x86_64-*-* --- Comment #1 from Richard Biener --- Please try GCC 5.4 (or newer)
[Bug lto/78140] [7 Regression] libxul -flto uses 1GB more memory than gcc-6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78140 --- Comment #8 from Martin Liška --- (In reply to Markus Trippelsdorf from comment #7) > BTW Firefox trunk fails to build for me: > > ld: error: /tmp/ccsbLieS.ltrans29.ltrans.o: requires dynamic R_X86_64_PC32 > reloc against '_ZN2js3jitL2R0E' which may overflow at runtime; recompile > with -fPIC > ld: error: read-only segment has dynamic relocations > /tmp/ccsbLieS.ltrans29.ltrans.o::function > js::jit::BaselineCompiler::emitCheckThis(js::jit::ValueOperand) [clone > .constprop.20226]: error: undefined reference to 'js::jit::R0' > > Haven't looked into it yet. Could well be a Firefox bug. This looks known to me, I used to see this unresolved symbol, but currently it's gone on x86_64-linux-gnu.
[Bug c++/78180] Poor optimization of std::array on gcc 4.8/5.4/6.2 as compared to simple raw array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78180 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-11-02 CC||trippels at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Markus Trippelsdorf --- .type void BM_Rolling(benchmark::State&), @function void BM_Rolling(benchmark::State&): .LFB1712: .cfi_startproc pushq %r13 .cfi_def_cfa_offset 16 .cfi_offset 13, -16 pushq %r12 .cfi_def_cfa_offset 24 .cfi_offset 12, -24 movl$128, %ecx pushq %rbp .cfi_def_cfa_offset 32 .cfi_offset 6, -32 pushq %rbx .cfi_def_cfa_offset 40 .cfi_offset 3, -40 movq%rdi, %rbp xorl%eax, %eax xorl%ebx, %ebx xorl%r12d, %r12d subq$1048, %rsp .cfi_def_cfa_offset 1088 xorl%r13d, %r13d movq%rsp, %rdi rep stosq .p2align 4,,10 .p2align 3 .L28: cmpb$0, 0(%rbp) je .L39 .L23: movq8(%rbp), %rax cmpq72(%rbp), %rax leaq1(%rax), %rdx movq%rdx, 8(%rbp) jnb .L40 movq24(%rbp), %r8 movq16(%rbp), %rdi movq%r8, %rax subq%rdi, %rax sarq$2, %rax testq %rax, %rax je .L25 movl(%rdi), %edx xorl%eax, %eax xorl%ecx, %ecx movl%ebx, %esi testl %edx, %edx jg .L26 jmp .L28 .p2align 4,,10 .p2align 3 .L31: addq$1, %rax cmpl(%rdi), %ecx
[Bug c++/78180] Poor optimization of std::array on gcc 4.8/5.4/6.2 as compared to simple raw array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78180 --- Comment #3 from Markus Trippelsdorf --- void BM_Rolling:| void BM_Rolling >: .LFB1712: | .LFB1713: .cfi_startproc .cfi_startproc pushq %r13< .cfi_def_cfa_offset 16 < .cfi_offset 13, -16 < pushq %r12< .cfi_def_cfa_offset 24 < .cfi_offset 12, -24 < movl$128, %ecx < pushq %rbppushq %rbp .cfi_def_cfa_offset 32 | .cfi_def_cfa_offset 16 .cfi_offset 6, -32 | .cfi_offset 6, -16 pushq %rbxpushq %rbx .cfi_def_cfa_offset 40 | .cfi_def_cfa_offset 24 .cfi_offset 3, -40 | .cfi_offset 3, -24 movq%rdi, %rbp < xorl%eax, %eax xorl%eax, %eax xorl%ebx, %ebx | movq%rdi, %rbx xorl%r12d, %r12d| movl$128, %ecx > xorl%ebp, %ebp subq$1048, %rsp subq$1048, %rsp .cfi_def_cfa_offset 1088| .cfi_def_cfa_offset 1072 xorl%r13d, %r13d< movq%rsp, %rdi movq%rsp, %rdi rep stosq rep stosq > movabsq $429496729600, %rax > movq%rax, 1024(%rsp) .p2align 4,,10 .p2align 4,,10 .p2align 3 .p2align 3 .L28: | .L7: cmpb$0, 0(%rbp) | cmpb$0, (%rbx) je .L39| je .L20 .L23: | .L2: movq8(%rbp), %rax | movq8(%rbx), %rax cmpq72(%rbp), %rax | cmpq72(%rbx), %rax leaq1(%rax), %rdx leaq1(%rax), %rdx movq%rdx, 8(%rbp) | movq%rdx, 8(%rbx) jnb .L40| jnb .L21 movq24(%rbp), %r8 | movq24(%rbx), %r8 movq16(%rbp), %rdi | movq16(%rbx), %rsi movq%r8, %rax movq%r8, %rax subq%rdi, %rax | subq%rsi, %rax sarq$2, %raxsarq$2, %rax testq %rax, %rax testq %rax, %rax je .L25| je .L4 movl(%rdi), %edx| movl(%rsi), %eax xorl%eax, %eax | xorl%edx, %edx xorl%ecx, %ecx xorl%ecx, %ecx movl%ebx, %esi | testl %eax, %eax testl %edx, %edx | jg .L5 jg .L26| jmp .L7 jmp .L28< .p2align 4,,10 .p2align 4,,10 .p2align 3 .p2align 3 .L31: | .L11: addq$1, %rax| addq$1, %rdx cmpl(%rdi), %ecx| cmpl(%rsi), %ecx jge .L28| jge .L7 .L26: | .L5: addl$1, %ebx| movl1024(%rsp), %edi movq%rax, (%rsp,%rsi,8) | movq%rdi, %rax movq%rax, %rdx | movq%rdx, (%rsp,%rdi,8) cmpl$100, %ebx | addl$1, %eax cmove %r13d, %ebx | cmpl1028(%rsp), %eax movl%ebx, %esi | movl%eax, 1024(%rsp) subq(%rsp,%rsi,8), %rdx | jne .L9 cmpq$99, %rdx | movl$0, 1024(%rsp) jg .L30| xorl%eax, %eax addq$1, %r12| .L9: movq16(%rbp), %rdi | movq%rdx, %rdi movq24(%rbp), %r8 | subq(%rsp,%rax,8), %rdi .L30: | cmpq$99, %rdi movq%r8, %rdx
[Bug c/78181] New: unrecognized option -mcpu=cortex-a73
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78181 Bug ID: 78181 Summary: unrecognized option -mcpu=cortex-a73 Product: gcc Version: 6.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: airbak.li at huawei dot com Target Milestone: --- When I build a cross-toolchain with gcc 6.2. When I used -mcpu=cortex-a73, it failed. When I used -mtune=cortex-a73, is OK. ljhui@key:~/toolchain/git/build-toolchain/gcc-uclibc$ /home/os_net/ljhui/toolchain/git/build-toolchain/gcc-uclibc/gcc_build/./gcc/xgcc -B/home/os_net/ljhui/toolchain/git/build-toolchain/gcc-uclibc/gcc_build/./gcc/ -B/home/os_net/ljhui/toolchain/git/build-toolchain/gcc-uclibc/install/arm-hisiv510-linux/arm-hisiv510-linux-uclibcgnueabi/bin/ -B/home/os_net/ljhui/toolchain/git/build-toolchain/gcc-uclibc/install/arm-hisiv510-linux/arm-hisiv510-linux-uclibcgnueabi/lib/ -isystem /home/os_net/ljhui/toolchain/git/build-toolchain/gcc-uclibc/install/arm-hisiv510-linux/arm-hisiv510-linux-uclibcgnueabi/include -isystem /home/os_net/ljhui/toolchain/git/build-toolchain/gcc-uclibc/install/arm-hisiv510-linux/arm-hisiv510-linux-uclibcgnueabi/sys-include -mcpu=cortex-a73 -o conftest -g -O2 a.c Assembler messages: Error: unknown cpu `cortex-a73' Error: unrecognized option -mcpu=cortex-a73
[Bug c/78181] unrecognized option -mcpu=cortex-a73
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78181 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ktkachov at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from ktkachov at gcc dot gnu.org --- support for Cortex-A73 was added to GCC 7. Are you using a non-FSF GCC 6.2? Perhaps a Linaro toolchain? In any case, -mtune guides tuning decisions without enforcing any particular architecture features. -mcpu requires the toolchain to use the architecture features of its argument (Cortex-A73 in this case) so it outputs that information in the assembly. You require assembler support for that. You need to update your binutils as support for Cortex-A73 was added to them in June 2016. I think it was in the 2.26 release
[Bug c++/78180] Poor optimization of std::array on gcc 4.8/5.4/6.2 as compared to simple raw array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78180 --- Comment #4 from Markus Trippelsdorf --- Created attachment 39942 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39942&action=edit unreduced testcase
[Bug target/77308] surprisingly large stack usage for sha512 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308 --- Comment #48 from Bernd Edlinger --- (In reply to wilco from comment #22) > > Anyway, there is another bug: on AArch64 we correctly recognize there are 8 > 1-byte loads, shifts and orrs which can be replaced by a single 8-byte load > and a byte reverse. Although it is recognized on ARM and works correctly if > it is a little endian load, it doesn't perform the optimization if a byte > reverse is needed. As a result there are lots of 64-bit shifts and orrs > which create huge register pressure if not expanded early. Hmm... I think the test case does something invalid here: const SHA_LONG64 *W = in; T1 = X[0] = PULL64(W[0]); in is not aligned, but it is cast to a 8-byte aligned type. If the bswap pass assumes with your proposed patch it is OK to merge 4 byte accesses into an aligned word access, it may likely break openssl on -mno-unaligned targets. Even on our cortex-a9 the O/S will trap on unaligned accesses. I have checked that openssl still works on arm-none-eabi with my patch, but I am not sure about your patch.
[Bug tree-optimization/78162] [7 Regression] ICE on invalid code at -Os and above on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78162 --- Comment #2 from ktkachov at gcc dot gnu.org --- Author: ktkachov Date: Wed Nov 2 09:25:22 2016 New Revision: 241778 URL: https://gcc.gnu.org/viewcvs?rev=241778&root=gcc&view=rev Log: PR tree-optimization/78162: Reject negative offsets in store merging early PR tree-optimization/78162 * gimple-ssa-store-merging.c (execute): Mark stores with bitpos < 0 as invalid. * gcc.c-torture/compile/pr78162.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr78162.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-ssa-store-merging.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/78162] [7 Regression] ICE on invalid code at -Os and above on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78162 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from ktkachov at gcc dot gnu.org --- Fixed. Thanks for the report
[Bug tree-optimization/78170] [7 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78170 --- Comment #6 from ktkachov at gcc dot gnu.org --- Author: ktkachov Date: Wed Nov 2 09:28:35 2016 New Revision: 241779 URL: https://gcc.gnu.org/viewcvs?rev=241779&root=gcc&view=rev Log: PR tree-optimization/78170: Truncate sign-extended padding when encoding bitfields PR tree-optimization/78170 * gimple-ssa-store-merging.c (encode_tree_to_bitpos): Truncate padding introduced by native_encode_expr on little-endian as well. * gcc.c-torture/execute/pr78170.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr78170.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-ssa-store-merging.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/78170] [7 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78170 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from ktkachov at gcc dot gnu.org --- Fixed. Thanks for the report
[Bug lto/78140] [7 Regression] libxul -flto uses 1GB more memory than gcc-6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78140 --- Comment #9 from Markus Trippelsdorf --- (In reply to Martin Liška from comment #8) > (In reply to Markus Trippelsdorf from comment #7) > > BTW Firefox trunk fails to build for me: > > > > ld: error: /tmp/ccsbLieS.ltrans29.ltrans.o: requires dynamic R_X86_64_PC32 > > reloc against '_ZN2js3jitL2R0E' which may overflow at runtime; recompile > > with -fPIC > > ld: error: read-only segment has dynamic relocations > > /tmp/ccsbLieS.ltrans29.ltrans.o::function > > js::jit::BaselineCompiler::emitCheckThis(js::jit::ValueOperand) [clone > > .constprop.20226]: error: undefined reference to 'js::jit::R0' > > > > Haven't looked into it yet. Could well be a Firefox bug. > > This looks known to me, I used to see this unresolved symbol, but currently > it's gone on x86_64-linux-gnu. Not for me. I hit the issue yesterday with gcc trunk and mozilla trunk. js::jit::R0 is an asm statement, that could end up in the wrong partition.
[Bug lto/78140] [7 Regression] libxul -flto uses 1GB more memory than gcc-6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78140 --- Comment #10 from Martin Liška --- (In reply to Markus Trippelsdorf from comment #9) > (In reply to Martin Liška from comment #8) > > (In reply to Markus Trippelsdorf from comment #7) > > > BTW Firefox trunk fails to build for me: > > > > > > ld: error: /tmp/ccsbLieS.ltrans29.ltrans.o: requires dynamic R_X86_64_PC32 > > > reloc against '_ZN2js3jitL2R0E' which may overflow at runtime; recompile > > > with -fPIC > > > ld: error: read-only segment has dynamic relocations > > > /tmp/ccsbLieS.ltrans29.ltrans.o::function > > > js::jit::BaselineCompiler::emitCheckThis(js::jit::ValueOperand) [clone > > > .constprop.20226]: error: undefined reference to 'js::jit::R0' > > > > > > Haven't looked into it yet. Could well be a Firefox bug. > > > > This looks known to me, I used to see this unresolved symbol, but currently > > it's gone on x86_64-linux-gnu. > > Not for me. I hit the issue yesterday with gcc trunk and mozilla trunk. > js::jit::R0 is an asm statement, that could end up in the wrong partition. Ah, I see. Can you please name the source file where's it's defined? Can't grep the symbol.
[Bug target/77308] surprisingly large stack usage for sha512 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308 --- Comment #49 from Bernd Edlinger --- (In reply to Bernd Edlinger from comment #48) > (In reply to wilco from comment #22) > > > > Anyway, there is another bug: on AArch64 we correctly recognize there are 8 > > 1-byte loads, shifts and orrs which can be replaced by a single 8-byte load > > and a byte reverse. Although it is recognized on ARM and works correctly if > > it is a little endian load, it doesn't perform the optimization if a byte > > reverse is needed. As a result there are lots of 64-bit shifts and orrs > > which create huge register pressure if not expanded early. > > Hmm... > > I think the test case does something invalid here: > > const SHA_LONG64 *W = in; > > T1 = X[0] = PULL64(W[0]); > > > in is not aligned, but it is cast to a 8-byte aligned type. > > If the bswap pass assumes with your proposed patch > it is OK to merge 4 byte accesses into an aligned word access, > it may likely break openssl on -mno-unaligned targets. > Even on our cortex-a9 the O/S will trap on unaligned accesses. > I have checked that openssl still works on arm-none-eabi > with my patch, but I am not sure about your patch. I tried it out. Although the code is bogus the code generation does not use the wrong alignment. With -mno-unaligned-access the ldr is split out into 4 ldb and the result is fed into the rev. At least in this configuration that is not profitable though.
[Bug lto/78140] [7 Regression] libxul -flto uses 1GB more memory than gcc-6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78140 --- Comment #11 from Markus Trippelsdorf --- js/src/jit/BaselineCompiler.cpp
[Bug target/77308] surprisingly large stack usage for sha512 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308 --- Comment #50 from Richard Earnshaw --- (In reply to wilco from comment #47) > (In reply to Richard Earnshaw from comment #46) > > (In reply to wilco from comment #44) > > > (In reply to Bernd Edlinger from comment #38) > > > > Created attachment 39939 [details] > > > > proposed patch, v2 > > > > > > > > > > > Unlike the previous patch, thumb1 stack usage stays at 1588 bytes, > > > > because thumb1 cannot split the adddi3 pattern, once it is emitted. > > > > > > We can split into a new pattern that contains adds/adc together. Splitting > > > should help Thumb-1 the most as it has just 3 allocatable DI mode > > > registers... > > > > Not on Thumb-1 we can't. Because of register allocation limitations, we > > cannot expose the flags until after register allocation has completed. > > (Since the register allocator needs to be able to insert loads, adds and > > copy instructions between any two insns. The add and copy instructions > > clobber the flags, making early splitting impossible. > > What I meant is splitting into a single new instruction using SI mode > registers rather than DI mode registers so that register allocation is more > efficient. You couldn't do that before combine, since the pattern would have to describe setting both 'result' registers independently. That would create a pattern that combine couldn't handle (more than one non-flag result) and so that in turn would stop the compiler being able to optimize such a pattern properly. Note the pattern would probably end up looking like a parallel that set high and low parts to the result of the 64-bit operation. It might help to rewrite the pattern that way after combine, but before register allocation.
[Bug c/78181] unrecognized option -mcpu=cortex-a73
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78181 --- Comment #2 from Richard Earnshaw --- The error message comes from the assembler, not the compiler, you need to update your assembler binaries.
[Bug lto/78140] [7 Regression] libxul -flto uses 1GB more memory than gcc-6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78140
--- Comment #12 from Martin Liška ---
(In reply to Markus Trippelsdorf from comment #11)
> js/src/jit/BaselineCompiler.cpp
Hm, I see the R0 defined as:
# 1
"/home/marxin/BIG/buildbot/slave/source/firefox/js/src/jit/x64/SharedICRegisters-x64.h"
1
# 12
"/home/marxin/BIG/buildbot/slave/source/firefox/js/src/jit/x64/SharedICRegisters-x64.h"
namespace js {
namespace jit {
static constexpr Register BaselineFrameReg = rbp;
static constexpr Register BaselineStackReg = rsp;
static constexpr ValueOperand R0(rcx);
not as an ASM statement.
[Bug target/63752] avr ICE at reload1.c:2128 building newlib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63752 Senthil Kumar Selvaraj changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Senthil Kumar Selvaraj --- Couldn't reproduce this on 5.1.0 or trunk
[Bug tree-optimization/78182] New: Missed optimizations: "fused" byte stores
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78182
Bug ID: 78182
Summary: Missed optimizations: "fused" byte stores
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rureclonic at thraml dot com
Target Milestone: ---
Consider the following program, which writes '0001' in `text`.
constexpr unsigned long Size = 12;
char text[Size];
void foo() {
auto value = 1u;
for (auto i = 0ul; i < Size; ++i) {
text[Size - i - 1] = (value % 10) + '0';
value /= 10;
}
}
The codegen for foo with `g++-7 -std=c++1z -O3 -march=corei7-avx` is:
foo():
mov BYTE PTR text[rip+11], 49
mov BYTE PTR text[rip+10], 48
mov BYTE PTR text[rip+9], 48
mov BYTE PTR text[rip+8], 48
mov BYTE PTR text[rip+7], 48
mov BYTE PTR text[rip+6], 48
mov BYTE PTR text[rip+5], 48
mov BYTE PTR text[rip+4], 48
mov BYTE PTR text[rip+3], 48
mov BYTE PTR text[rip+2], 48
mov BYTE PTR text[rip+1], 48
mov BYTE PTR text[rip], 48
ret
Why can't the 9 last movs be combined into wider stores?
[Bug tree-optimization/78182] Missed optimizations: "fused" byte stores
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78182 Richard Biener changed: What|Removed |Added Target||x86_64-*-* Status|UNCONFIRMED |RESOLVED CC||ktkachov at gcc dot gnu.org Resolution|--- |FIXED --- Comment #1 from Richard Biener --- They are now: _Z3foov: .LFB0: .cfi_startproc movabsq $3472328296227680304, %rax movl$825241648, text+8(%rip) movq%rax, text(%rip) ret since store-merging was merged (Oct 28)
[Bug debug/49775] [5/6/7 Regression] on AVR ICE in based_loc_descr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49775 Senthil Kumar Selvaraj changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|5.5 |4.9.0 --- Comment #15 from Senthil Kumar Selvaraj --- Fixed by r208045 a while back. 4.9.0 onwards has the fix
[Bug tree-optimization/78182] Missed optimizations: "fused" byte stores
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78182 --- Comment #2 from ktkachov at gcc dot gnu.org --- Heh, please try r241649 or later. I now get: movabsq $3472328296227680304, %rax movl$825241648, text+8(%rip) movq%rax, text(%rip) ret
[Bug tree-optimization/78182] Missed optimizations: "fused" byte stores
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78182 --- Comment #3 from Rurec Lonic --- Fantastic. Thanks for this, and next time I'll make sure to pull the very latest revision!.
[Bug target/77308] surprisingly large stack usage for sha512 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308 --- Comment #51 from wilco at gcc dot gnu.org --- (In reply to Bernd Edlinger from comment #49) > (In reply to Bernd Edlinger from comment #48) > > (In reply to wilco from comment #22) > > > > > > Anyway, there is another bug: on AArch64 we correctly recognize there are > > > 8 > > > 1-byte loads, shifts and orrs which can be replaced by a single 8-byte > > > load > > > and a byte reverse. Although it is recognized on ARM and works correctly > > > if > > > it is a little endian load, it doesn't perform the optimization if a byte > > > reverse is needed. As a result there are lots of 64-bit shifts and orrs > > > which create huge register pressure if not expanded early. > > > > Hmm... > > > > I think the test case does something invalid here: > > > > const SHA_LONG64 *W = in; > > > > T1 = X[0] = PULL64(W[0]); > > > > > > in is not aligned, but it is cast to a 8-byte aligned type. > > > > If the bswap pass assumes with your proposed patch > > it is OK to merge 4 byte accesses into an aligned word access, > > it may likely break openssl on -mno-unaligned targets. > > Even on our cortex-a9 the O/S will trap on unaligned accesses. > > I have checked that openssl still works on arm-none-eabi > > with my patch, but I am not sure about your patch. > > I tried it out. Although the code is bogus the code generation > does not use the wrong alignment. > > With -mno-unaligned-access the ldr is split out into 4 ldb and > the result is fed into the rev. > > At least in this configuration that is not profitable though. Indeed, that's the reason behind the existing check. However it disables all profitable bswap cases while still generating unaligned accesses if no bswap is needed. So I am looking for a callback that gives the correct answer. It would need to check -mno-unaligned-access and the target capabilities (eg. if unaligned accesses are supported in hardware but really expensive we want to avoid them).
[Bug tree-optimization/61056] strchr (x, 0) is not converted to strlen (x)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61056 wilco at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||wilco at gcc dot gnu.org Resolution|--- |FIXED --- Comment #6 from wilco at gcc dot gnu.org --- Fixed in r240568.
[Bug lto/78140] [7 Regression] libxul -flto uses 1GB more memory than gcc-6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78140
--- Comment #13 from Markus Trippelsdorf ---
(In reply to Martin Liška from comment #12)
> (In reply to Markus Trippelsdorf from comment #11)
> > js/src/jit/BaselineCompiler.cpp
>
> Hm, I see the R0 defined as:
>
> # 1
> "/home/marxin/BIG/buildbot/slave/source/firefox/js/src/jit/x64/
> SharedICRegisters-x64.h" 1
> # 12
> "/home/marxin/BIG/buildbot/slave/source/firefox/js/src/jit/x64/
> SharedICRegisters-x64.h"
> namespace js {
> namespace jit {
>
> static constexpr Register BaselineFrameReg = rbp;
> static constexpr Register BaselineStackReg = rsp;
>
> static constexpr ValueOperand R0(rcx);
>
> not as an ASM statement.
Yes, you're right. I only took a cursory look and got confused by all these
masm. statements.
Not sure how to debug this further.
[Bug fortran/77679] [6 Regression] ICE in fold_array_ctor_reference, at gimple-fold.c:5586
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77679 --- Comment #8 from Dominique d'Humieres --- > Fixed. Really? I still see the error Error: size of variable 'A.0' is too large
[Bug fortran/78062] sinus and cosinus fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78062 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WORKSFORME --- Comment #3 from Dominique d'Humieres --- No feedback. Closing as WORKSFORME.
[Bug target/77308] surprisingly large stack usage for sha512 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308 --- Comment #52 from Bernd Edlinger --- (In reply to wilco from comment #51) > > Indeed, that's the reason behind the existing check. However it disables all > profitable bswap cases while still generating unaligned accesses if no bswap > is needed. So I am looking for a callback that gives the correct answer. It > would need to check -mno-unaligned-access and the target capabilities (eg. > if unaligned accesses are supported in hardware but really expensive we want > to avoid them). Yes. I think ARM is becoming a non-strict-alignment platform. While x86_64 is moving in the opposite direction. Would it be possible to handle the STRICT_ALIGNMENT switchable like int the rs6000, in that case you have also more flexibility in the handling of SLOW_UNALIGNED_ACCESS macro ?
[Bug fortran/77679] [6 Regression] ICE in fold_array_ctor_reference, at gimple-fold.c:5586
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77679 --- Comment #9 from rguenther at suse dot de --- On Wed, 2 Nov 2016, dominiq at lps dot ens.fr wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77679 > > --- Comment #8 from Dominique d'Humieres --- > > Fixed. > > Really? I still see the error > > Error: size of variable 'A.0' is too large The ICE is gone and the testcase is invalid (well, the reporter says so). Maybe the FE can better diagnose this but this wouldn't be a regression.
[Bug c/78183] New: Silence warnings about alternate forms of custom format specifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78183
Bug ID: 78183
Summary: Silence warnings about alternate forms of custom
format specifiers
Product: gcc
Version: 5.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: drazen.kacar at tereo dot hr
Target Milestone: ---
Glibc allows writing custom printf format conversions, so I've implemented a
conversion which takes char * and prints the string with all non-printable
characters in \xxx notation. This is very useful for printing debugging
output (I'm currently writing a lot of unit tests) and logging.
However, if I register it with unused conversion specifier (eg. %W) then gcc
produces a warning. This has already been reported in bug 47781, but doesn't
look like it will be resolved soon.
Another option is to use %s and implement my version as an alternate form,
so it would be used with the %#s specifier. Then the compiler would now how to
check arguments without any code modifications. However, if I do this gcc
warns about '#' flag being used with %s.
For example (function which implements conversion not shown):
prompt> tail -17 myprintf.c
int
main()
{
char *str = "burek\r\n";
printf("Before registering: %#s\n", str);
if(register_printf_specifier ('s', str_log, str_log_arginfo))
{
fputs("Cannot register %s specifier", stderr);
exit(1);
}
printf("%s\n", str);
printf("%#s\n", str);
return 0;
}
prompt> gcc -o myprintf myprintf.c
myprintf.c: In function 'main':
myprintf.c:94:12: warning: '#' flag used with '%s' gnu_printf format
[-Wformat=]
printf("Before registering: %#s\n", str);
^
myprintf.c:102:12: warning: '#' flag used with '%s' gnu_printf format
[-Wformat=]
printf("%#s\n", str);
^
prompt> ./myprintf
Before registering: burek
burek
burek\r\n
=== End example ===
While we're waiting for the full implementation of the problem from bug 47781
would it be possible to implement something that would silence warnings for
alternate forms which aren't specified by a standard?
I can see two approaches:
a) Don't produce warning about this by default and introduce a compiler flag to
turn it on.
b) Introduce another compiler flag (eg. -Wno-format-alt-flag) which would
silence this specific warning.
I tried to find command line option which would disable specific warning
identified by a number or a name, but couldn't find it.
[Bug fortran/78152] [6/7 Regression] coarray and associate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78152 --- Comment #8 from vehre at gcc dot gnu.org --- Hi Steve, you asked what other compilers have to say to the code (the one in the description). Ifort: > ifort bug.f90 -o bug -coarray bug.f90: catastrophic error: **Internal compiler error: segmentation violation signal raised** Please report this error along with the circumstances in which it occurred in a Software Problem Report. Note: File and line given may not be explicit cause of this error. compilation aborted for bug.f90 (code 1) > ifort -v ifort version 15.0.1 While Cray say: >ftn bug.f90 -o bug >ftn -V Cray Fortran : Version 8.5.1 Wed Nov 02, 2016 05:35:28 I can't run the resulting executable though, because some runtime library is reported missing (I don't get how to setup it up correctly). Changing the program to subroutine has no effect. - Andre
[Bug tree-optimization/77648] [5/6 Regression] Setting conversion to a integer to double to 0 3/4 through a loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77648 --- Comment #11 from Richard Biener --- Author: rguenth Date: Wed Nov 2 12:47:10 2016 New Revision: 241788 URL: https://gcc.gnu.org/viewcvs?rev=241788&root=gcc&view=rev Log: 2016-11-02 Richard Biener Backport from mainline 2016-11-02 Richard Biener PR tree-optimization/78047 * tree-ssa-structalias.c (push_fields_onto_fieldstack): Initialize fake field at offset zero conservatively regarding to may_have_pointers. 2016-10-31 Richard Biener PR lto/78129 * lto.c (do_whole_program_analysis): Bail out after errors from WPA analysis. 2016-10-07 Richard Biener PR tree-optimization/77879 * tree-ssa-structalias.c (handle_const_call): Properly handle NRV return slots. (handle_pure_call): Likewise. 2016-10-06 Richard Biener PR tree-optimization/77839 * tree-ssa-sccvn.c (set_ssa_val_to): Forbid value -> constant value lattice transition. * gcc.dg/torture/pr77839.c: New testcase. 2016-09-27 Richard Biener PR tree-optimization/77745 * tree-ssa-pre.c (eliminate_dom_walker::before_dom_children): When removing redundant stores make sure to check compatibility of the TBAA state for downstream accesses. * tree-ssa-sccvn.c (visit_reference_op_store): Likewise for when value-numbering virtual operands for store matches. * g++.dg/torture/pr77745.C: New testcase. 2016-09-21 Richard Biener PR tree-optimization/77648 * tree-ssa-structalias.c (process_constraint): Handle all DEREF with complex RHS. (make_transitive_closure_constraints): Adjust comment. (make_any_offset_constraints): New function. (handle_rhs_call): Make sure to first expand a pointer to all subfields before transitively closing it. (handle_const_call): Likewise. Properly expand returned pointers as well. (handle_pure_call): Likewise. * gcc.dg/torture/pr77648-1.c: New testcase. * gcc.dg/torture/pr77648-2.c: Likewise. Added: branches/gcc-6-branch/gcc/testsuite/g++.dg/torture/pr77745.C branches/gcc-6-branch/gcc/testsuite/gcc.dg/torture/pr77648-1.c branches/gcc-6-branch/gcc/testsuite/gcc.dg/torture/pr77648-2.c branches/gcc-6-branch/gcc/testsuite/gcc.dg/torture/pr77839.c Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/lto/ChangeLog branches/gcc-6-branch/gcc/lto/lto.c branches/gcc-6-branch/gcc/testsuite/ChangeLog branches/gcc-6-branch/gcc/tree-ssa-pre.c branches/gcc-6-branch/gcc/tree-ssa-sccvn.c branches/gcc-6-branch/gcc/tree-ssa-structalias.c
[Bug tree-optimization/77839] [6 Regression] Memory- and compile time hog at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77839 --- Comment #7 from Richard Biener --- Author: rguenth Date: Wed Nov 2 12:47:10 2016 New Revision: 241788 URL: https://gcc.gnu.org/viewcvs?rev=241788&root=gcc&view=rev Log: 2016-11-02 Richard Biener Backport from mainline 2016-11-02 Richard Biener PR tree-optimization/78047 * tree-ssa-structalias.c (push_fields_onto_fieldstack): Initialize fake field at offset zero conservatively regarding to may_have_pointers. 2016-10-31 Richard Biener PR lto/78129 * lto.c (do_whole_program_analysis): Bail out after errors from WPA analysis. 2016-10-07 Richard Biener PR tree-optimization/77879 * tree-ssa-structalias.c (handle_const_call): Properly handle NRV return slots. (handle_pure_call): Likewise. 2016-10-06 Richard Biener PR tree-optimization/77839 * tree-ssa-sccvn.c (set_ssa_val_to): Forbid value -> constant value lattice transition. * gcc.dg/torture/pr77839.c: New testcase. 2016-09-27 Richard Biener PR tree-optimization/77745 * tree-ssa-pre.c (eliminate_dom_walker::before_dom_children): When removing redundant stores make sure to check compatibility of the TBAA state for downstream accesses. * tree-ssa-sccvn.c (visit_reference_op_store): Likewise for when value-numbering virtual operands for store matches. * g++.dg/torture/pr77745.C: New testcase. 2016-09-21 Richard Biener PR tree-optimization/77648 * tree-ssa-structalias.c (process_constraint): Handle all DEREF with complex RHS. (make_transitive_closure_constraints): Adjust comment. (make_any_offset_constraints): New function. (handle_rhs_call): Make sure to first expand a pointer to all subfields before transitively closing it. (handle_const_call): Likewise. Properly expand returned pointers as well. (handle_pure_call): Likewise. * gcc.dg/torture/pr77648-1.c: New testcase. * gcc.dg/torture/pr77648-2.c: Likewise. Added: branches/gcc-6-branch/gcc/testsuite/g++.dg/torture/pr77745.C branches/gcc-6-branch/gcc/testsuite/gcc.dg/torture/pr77648-1.c branches/gcc-6-branch/gcc/testsuite/gcc.dg/torture/pr77648-2.c branches/gcc-6-branch/gcc/testsuite/gcc.dg/torture/pr77839.c Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/lto/ChangeLog branches/gcc-6-branch/gcc/lto/lto.c branches/gcc-6-branch/gcc/testsuite/ChangeLog branches/gcc-6-branch/gcc/tree-ssa-pre.c branches/gcc-6-branch/gcc/tree-ssa-sccvn.c branches/gcc-6-branch/gcc/tree-ssa-structalias.c
[Bug tree-optimization/77745] [5/6 Regression] Inconsistent application of aliasing rules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77745 --- Comment #10 from Richard Biener --- Author: rguenth Date: Wed Nov 2 12:47:10 2016 New Revision: 241788 URL: https://gcc.gnu.org/viewcvs?rev=241788&root=gcc&view=rev Log: 2016-11-02 Richard Biener Backport from mainline 2016-11-02 Richard Biener PR tree-optimization/78047 * tree-ssa-structalias.c (push_fields_onto_fieldstack): Initialize fake field at offset zero conservatively regarding to may_have_pointers. 2016-10-31 Richard Biener PR lto/78129 * lto.c (do_whole_program_analysis): Bail out after errors from WPA analysis. 2016-10-07 Richard Biener PR tree-optimization/77879 * tree-ssa-structalias.c (handle_const_call): Properly handle NRV return slots. (handle_pure_call): Likewise. 2016-10-06 Richard Biener PR tree-optimization/77839 * tree-ssa-sccvn.c (set_ssa_val_to): Forbid value -> constant value lattice transition. * gcc.dg/torture/pr77839.c: New testcase. 2016-09-27 Richard Biener PR tree-optimization/77745 * tree-ssa-pre.c (eliminate_dom_walker::before_dom_children): When removing redundant stores make sure to check compatibility of the TBAA state for downstream accesses. * tree-ssa-sccvn.c (visit_reference_op_store): Likewise for when value-numbering virtual operands for store matches. * g++.dg/torture/pr77745.C: New testcase. 2016-09-21 Richard Biener PR tree-optimization/77648 * tree-ssa-structalias.c (process_constraint): Handle all DEREF with complex RHS. (make_transitive_closure_constraints): Adjust comment. (make_any_offset_constraints): New function. (handle_rhs_call): Make sure to first expand a pointer to all subfields before transitively closing it. (handle_const_call): Likewise. Properly expand returned pointers as well. (handle_pure_call): Likewise. * gcc.dg/torture/pr77648-1.c: New testcase. * gcc.dg/torture/pr77648-2.c: Likewise. Added: branches/gcc-6-branch/gcc/testsuite/g++.dg/torture/pr77745.C branches/gcc-6-branch/gcc/testsuite/gcc.dg/torture/pr77648-1.c branches/gcc-6-branch/gcc/testsuite/gcc.dg/torture/pr77648-2.c branches/gcc-6-branch/gcc/testsuite/gcc.dg/torture/pr77839.c Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/lto/ChangeLog branches/gcc-6-branch/gcc/lto/lto.c branches/gcc-6-branch/gcc/testsuite/ChangeLog branches/gcc-6-branch/gcc/tree-ssa-pre.c branches/gcc-6-branch/gcc/tree-ssa-sccvn.c branches/gcc-6-branch/gcc/tree-ssa-structalias.c
[Bug tree-optimization/77879] [5/6 Regression] mpd gets miscompiled since r235622
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77879 --- Comment #8 from Richard Biener --- Author: rguenth Date: Wed Nov 2 12:47:10 2016 New Revision: 241788 URL: https://gcc.gnu.org/viewcvs?rev=241788&root=gcc&view=rev Log: 2016-11-02 Richard Biener Backport from mainline 2016-11-02 Richard Biener PR tree-optimization/78047 * tree-ssa-structalias.c (push_fields_onto_fieldstack): Initialize fake field at offset zero conservatively regarding to may_have_pointers. 2016-10-31 Richard Biener PR lto/78129 * lto.c (do_whole_program_analysis): Bail out after errors from WPA analysis. 2016-10-07 Richard Biener PR tree-optimization/77879 * tree-ssa-structalias.c (handle_const_call): Properly handle NRV return slots. (handle_pure_call): Likewise. 2016-10-06 Richard Biener PR tree-optimization/77839 * tree-ssa-sccvn.c (set_ssa_val_to): Forbid value -> constant value lattice transition. * gcc.dg/torture/pr77839.c: New testcase. 2016-09-27 Richard Biener PR tree-optimization/77745 * tree-ssa-pre.c (eliminate_dom_walker::before_dom_children): When removing redundant stores make sure to check compatibility of the TBAA state for downstream accesses. * tree-ssa-sccvn.c (visit_reference_op_store): Likewise for when value-numbering virtual operands for store matches. * g++.dg/torture/pr77745.C: New testcase. 2016-09-21 Richard Biener PR tree-optimization/77648 * tree-ssa-structalias.c (process_constraint): Handle all DEREF with complex RHS. (make_transitive_closure_constraints): Adjust comment. (make_any_offset_constraints): New function. (handle_rhs_call): Make sure to first expand a pointer to all subfields before transitively closing it. (handle_const_call): Likewise. Properly expand returned pointers as well. (handle_pure_call): Likewise. * gcc.dg/torture/pr77648-1.c: New testcase. * gcc.dg/torture/pr77648-2.c: Likewise. Added: branches/gcc-6-branch/gcc/testsuite/g++.dg/torture/pr77745.C branches/gcc-6-branch/gcc/testsuite/gcc.dg/torture/pr77648-1.c branches/gcc-6-branch/gcc/testsuite/gcc.dg/torture/pr77648-2.c branches/gcc-6-branch/gcc/testsuite/gcc.dg/torture/pr77839.c Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/lto/ChangeLog branches/gcc-6-branch/gcc/lto/lto.c branches/gcc-6-branch/gcc/testsuite/ChangeLog branches/gcc-6-branch/gcc/tree-ssa-pre.c branches/gcc-6-branch/gcc/tree-ssa-sccvn.c branches/gcc-6-branch/gcc/tree-ssa-structalias.c
[Bug middle-end/78047] [5/6 Regression] Chromium apparently gets miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78047 --- Comment #11 from Richard Biener --- Author: rguenth Date: Wed Nov 2 12:47:10 2016 New Revision: 241788 URL: https://gcc.gnu.org/viewcvs?rev=241788&root=gcc&view=rev Log: 2016-11-02 Richard Biener Backport from mainline 2016-11-02 Richard Biener PR tree-optimization/78047 * tree-ssa-structalias.c (push_fields_onto_fieldstack): Initialize fake field at offset zero conservatively regarding to may_have_pointers. 2016-10-31 Richard Biener PR lto/78129 * lto.c (do_whole_program_analysis): Bail out after errors from WPA analysis. 2016-10-07 Richard Biener PR tree-optimization/77879 * tree-ssa-structalias.c (handle_const_call): Properly handle NRV return slots. (handle_pure_call): Likewise. 2016-10-06 Richard Biener PR tree-optimization/77839 * tree-ssa-sccvn.c (set_ssa_val_to): Forbid value -> constant value lattice transition. * gcc.dg/torture/pr77839.c: New testcase. 2016-09-27 Richard Biener PR tree-optimization/77745 * tree-ssa-pre.c (eliminate_dom_walker::before_dom_children): When removing redundant stores make sure to check compatibility of the TBAA state for downstream accesses. * tree-ssa-sccvn.c (visit_reference_op_store): Likewise for when value-numbering virtual operands for store matches. * g++.dg/torture/pr77745.C: New testcase. 2016-09-21 Richard Biener PR tree-optimization/77648 * tree-ssa-structalias.c (process_constraint): Handle all DEREF with complex RHS. (make_transitive_closure_constraints): Adjust comment. (make_any_offset_constraints): New function. (handle_rhs_call): Make sure to first expand a pointer to all subfields before transitively closing it. (handle_const_call): Likewise. Properly expand returned pointers as well. (handle_pure_call): Likewise. * gcc.dg/torture/pr77648-1.c: New testcase. * gcc.dg/torture/pr77648-2.c: Likewise. Added: branches/gcc-6-branch/gcc/testsuite/g++.dg/torture/pr77745.C branches/gcc-6-branch/gcc/testsuite/gcc.dg/torture/pr77648-1.c branches/gcc-6-branch/gcc/testsuite/gcc.dg/torture/pr77648-2.c branches/gcc-6-branch/gcc/testsuite/gcc.dg/torture/pr77839.c Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/lto/ChangeLog branches/gcc-6-branch/gcc/lto/lto.c branches/gcc-6-branch/gcc/testsuite/ChangeLog branches/gcc-6-branch/gcc/tree-ssa-pre.c branches/gcc-6-branch/gcc/tree-ssa-sccvn.c branches/gcc-6-branch/gcc/tree-ssa-structalias.c
[Bug lto/78129] -Werror=suggest-final-types leads to -ENOSPC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78129 --- Comment #6 from Richard Biener --- Author: rguenth Date: Wed Nov 2 12:47:10 2016 New Revision: 241788 URL: https://gcc.gnu.org/viewcvs?rev=241788&root=gcc&view=rev Log: 2016-11-02 Richard Biener Backport from mainline 2016-11-02 Richard Biener PR tree-optimization/78047 * tree-ssa-structalias.c (push_fields_onto_fieldstack): Initialize fake field at offset zero conservatively regarding to may_have_pointers. 2016-10-31 Richard Biener PR lto/78129 * lto.c (do_whole_program_analysis): Bail out after errors from WPA analysis. 2016-10-07 Richard Biener PR tree-optimization/77879 * tree-ssa-structalias.c (handle_const_call): Properly handle NRV return slots. (handle_pure_call): Likewise. 2016-10-06 Richard Biener PR tree-optimization/77839 * tree-ssa-sccvn.c (set_ssa_val_to): Forbid value -> constant value lattice transition. * gcc.dg/torture/pr77839.c: New testcase. 2016-09-27 Richard Biener PR tree-optimization/77745 * tree-ssa-pre.c (eliminate_dom_walker::before_dom_children): When removing redundant stores make sure to check compatibility of the TBAA state for downstream accesses. * tree-ssa-sccvn.c (visit_reference_op_store): Likewise for when value-numbering virtual operands for store matches. * g++.dg/torture/pr77745.C: New testcase. 2016-09-21 Richard Biener PR tree-optimization/77648 * tree-ssa-structalias.c (process_constraint): Handle all DEREF with complex RHS. (make_transitive_closure_constraints): Adjust comment. (make_any_offset_constraints): New function. (handle_rhs_call): Make sure to first expand a pointer to all subfields before transitively closing it. (handle_const_call): Likewise. Properly expand returned pointers as well. (handle_pure_call): Likewise. * gcc.dg/torture/pr77648-1.c: New testcase. * gcc.dg/torture/pr77648-2.c: Likewise. Added: branches/gcc-6-branch/gcc/testsuite/g++.dg/torture/pr77745.C branches/gcc-6-branch/gcc/testsuite/gcc.dg/torture/pr77648-1.c branches/gcc-6-branch/gcc/testsuite/gcc.dg/torture/pr77648-2.c branches/gcc-6-branch/gcc/testsuite/gcc.dg/torture/pr77839.c Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/lto/ChangeLog branches/gcc-6-branch/gcc/lto/lto.c branches/gcc-6-branch/gcc/testsuite/ChangeLog branches/gcc-6-branch/gcc/tree-ssa-pre.c branches/gcc-6-branch/gcc/tree-ssa-sccvn.c branches/gcc-6-branch/gcc/tree-ssa-structalias.c
[Bug tree-optimization/77839] [6 Regression] Memory- and compile time hog at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77839 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||6.2.1 Resolution|--- |FIXED Known to fail||6.2.0 --- Comment #8 from Richard Biener --- Fixed.
[Bug lto/78129] -Werror=suggest-final-types leads to -ENOSPC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78129 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||6.2.1 Resolution|--- |FIXED --- Comment #7 from Richard Biener --- Fixed.
[Bug c++/78184] New: std::call_once freezes on second execution if the callable threw an exception on first execution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78184
Bug ID: 78184
Summary: std::call_once freezes on second execution if the
callable threw an exception on first execution
Product: gcc
Version: 5.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: simon.heybrock at esss dot se
Target Milestone: ---
=== Overview ===
If the callable in std::call_once throws an exception, a subsequent execution
of std::call_once causes a freeze.
Error observed with:
- gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.2)
- g++ (GCC) 6.2.1 20160830
Works with:
- g++ (GCC) 4.8.5 20150623 (Red Hat 4.8.5-4)
=== Example 1 ===
Compiled with: g++ --std=c++11 -fopenmp
#include
#include
#include
struct Cache {
mutable std::once_flag flag;
void cache() const {
std::cout << "caching...\n";
throw std::runtime_error("error");
}
void freeze() const {
std::cout << "freeze?\n";
std::call_once(flag, &Cache::cache, this);
}
};
int main() {
Cache cache;
try {
cache.freeze();
} catch (std::runtime_error &) {
}
try {
cache.freeze();
} catch (std::runtime_error &) {
}
}
# Expected output:
freeze?
caching...
freeze?
caching...
# Actual output:
freeze?
caching...
freeze?
^C
=== Example 2 ===
A similar, slightly longer example can be found at
http://en.cppreference.com/w/cpp/thread/call_once.
# Expected output:
Simple example: called once
throw: call_once will retry
throw: call_once will retry
Didn't throw, call_once will not attempt again
# Actual output:
Simple example: called once
throw: call_once will retry
^C
=== Details ===
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
5.4.0-6ubuntu1~16.04.2' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-5 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --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 --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
[Bug tree-optimization/78185] New: Wrong branch optimization with -O1 on x86/x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78185 Bug ID: 78185 Summary: Wrong branch optimization with -O1 on x86/x86_64 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: mdaniels at qnx dot com Target Milestone: --- Created attachment 39943 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39943&action=edit Testcase The attached test case is being incorrectly optimized on x86/x86_64 with -O1 or above. $ gcc -O1 -fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations -Wall -Wextra -o /tmp/test /tmp/test.c $ /tmp/test Floating point exception (core dumped) The test case is reduced from csmith output. Looking at the resulting assembly, it seems like the wrong branch is being optimized away. Since it takes the wrong branch it ends up trying to divide by zero. I had also tried with armv7 and aarch64, which kept both branches so the problem was not seen on those archs. Tested on a Linux x86_64 host with GCC 5.4 and ToT.
[Bug target/77904] [ARM Cortex-M0] Frame pointer thrashes registers if assembly statements with "sp" clobber are used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77904 Thomas Preud'homme changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |thopre01 at gcc dot gnu.org --- Comment #3 from Thomas Preud'homme --- Working on a patch.
[Bug gcov-profile/65831] gcov does not output 0% coverage files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65831 Alex K. changed: What|Removed |Added CC||pleskav at ya dot ru --- Comment #3 from Alex K. --- I noticed that this bug was fixed on trunk. https://github.com/gcc-mirror/gcc/blob/master/gcc/gcov.c#L916 But in branch gcc-4_9-branch https://github.com/gcc-mirror/gcc/blob/gcc-4_9-branch/gcc/gcov.c#L728 gcov.c-file does not contain this bug fix. What newest version of GCC will contain this bug fix?
[Bug tree-optimization/78185] Wrong branch optimization with -O1 on x86/x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78185 Marc Glisse changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2016-11-02 Ever confirmed|0 |1 --- Comment #1 from Marc Glisse --- lim2 not checking that the statement may trap before pulling it?
[Bug middle-end/72747] powerpc: wrong code generated for vec_splats in cascading assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72747 --- Comment #3 from Will Schmidt --- Author: willschm Date: Wed Nov 2 14:12:23 2016 New Revision: 241792 URL: https://gcc.gnu.org/viewcvs?rev=241792&root=gcc&view=rev Log: [gcc] 2016-11-02 Will Schmidt Backport from trunk 2016-10-26 Will Schmidt PR middle-end/72747 * gimplify.c (gimplify_init_constructor): Move emit of constructor assignment to earlier in the if/else logic. [gcc/testsuite] 2016-11-02 Will Schmidt Backport from trunk 2016-10-26 Will Schmidt PR middle-end/72747 * c-c++-common/pr72747-1.c: New test. * c-c++-common/pr72747-2.c: Likewise. Added: branches/gcc-6-branch/gcc/testsuite/c-c++-common/pr72747-1.c branches/gcc-6-branch/gcc/testsuite/c-c++-common/pr72747-2.c Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/gimplify.c branches/gcc-6-branch/gcc/testsuite/ChangeLog
[Bug middle-end/72747] powerpc: wrong code generated for vec_splats in cascading assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72747 --- Comment #4 from Will Schmidt --- Author: willschm Date: Wed Nov 2 14:13:07 2016 New Revision: 241793 URL: https://gcc.gnu.org/viewcvs?rev=241793&root=gcc&view=rev Log: [gcc] 2016-11-02 Will Schmidt Backport from trunk 2016-10-26 Will Schmidt PR middle-end/72747 * gimplify.c (gimplify_init_constructor): Move emit of constructor assignment to earlier in the if/else logic. [gcc/testsuite] 2016-11-02 Will Schmidt Backport from trunk 2016-10-26 Will Schmidt PR middle-end/72747 * c-c++-common/pr72747-1.c: New test. * c-c++-common/pr72747-2.c: Likewise. Added: branches/gcc-5-branch/gcc/testsuite/c-c++-common/pr72747-1.c branches/gcc-5-branch/gcc/testsuite/c-c++-common/pr72747-2.c Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/gimplify.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
Re: [Bug target/77308] surprisingly large stack usage for sha512 on arm
On 02/11/16 11:57, bernd.edlinger at hotmail dot de wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308 > > --- Comment #52 from Bernd Edlinger --- > (In reply to wilco from comment #51) >> >> Indeed, that's the reason behind the existing check. However it disables all >> profitable bswap cases while still generating unaligned accesses if no bswap >> is needed. So I am looking for a callback that gives the correct answer. It >> would need to check -mno-unaligned-access and the target capabilities (eg. >> if unaligned accesses are supported in hardware but really expensive we want >> to avoid them). > > Yes. I think ARM is becoming a non-strict-alignment platform. > While x86_64 is moving in the opposite direction. It can never be a non-strict alignment platform while some memory access instructions do not support unaligned accesses. However, it is progressively becoming a less slow unaligned access platform. R.
[Bug target/77308] surprisingly large stack usage for sha512 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308 --- Comment #53 from richard.earnshaw at arm dot com --- On 02/11/16 11:57, bernd.edlinger at hotmail dot de wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308 > > --- Comment #52 from Bernd Edlinger --- > (In reply to wilco from comment #51) >> >> Indeed, that's the reason behind the existing check. However it disables all >> profitable bswap cases while still generating unaligned accesses if no bswap >> is needed. So I am looking for a callback that gives the correct answer. It >> would need to check -mno-unaligned-access and the target capabilities (eg. >> if unaligned accesses are supported in hardware but really expensive we want >> to avoid them). > > Yes. I think ARM is becoming a non-strict-alignment platform. > While x86_64 is moving in the opposite direction. It can never be a non-strict alignment platform while some memory access instructions do not support unaligned accesses. However, it is progressively becoming a less slow unaligned access platform. R.
[Bug tree-optimization/78185] Wrong branch optimization with -O1 on x86/x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78185 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener --- Nope. if (TREE_CODE (lhs) != SSA_NAME || gimple_could_trap_p (stmt)) return MOVE_PRESERVE_EXECUTION; But then LIM fails to check whether the exit of the nested loop is ever taken (it infinitely loops). Thus that LIM logic has a flaw. It marks that block as always executed in the outer loop. Thus the bug is in fill_always_executed_in[_1]. A tiny bit academic as it requires a never terminating inner loop, but well.
[Bug tree-optimization/78185] Wrong branch optimization with -O1 on x86/x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78185
Richard Biener changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
--- Comment #3 from Richard Biener ---
diff --git a/gcc/tree-ssa-loop-im.c b/gcc/tree-ssa-loop-im.c
index 463db04..a89cabf 100644
--- a/gcc/tree-ssa-loop-im.c
+++ b/gcc/tree-ssa-loop-im.c
@@ -44,6 +44,7 @@ along with GCC; see the file COPYING3. If not see
#include "trans-mem.h"
#include "gimple-fold.h"
#include "tree-scalar-evolution.h"
+#include "tree-ssa-loop-niter.h"
/* TODO: Support for predicated code motion. I.e.
@@ -2369,8 +2370,17 @@ fill_always_executed_in_1 (struct loop *loop, sbitmap
contains_call)
break;
FOR_EACH_EDGE (e, ei, bb->succs)
- if (!flow_bb_inside_loop_p (loop, e->dest))
- break;
+ {
+ /* If there is an exit from this BB. */
+ if (!flow_bb_inside_loop_p (loop, e->dest))
+ break;
+ /* Or we enter a possibly non-finite loop.
+??? Does that reliably detect infinite child loops
+inside the child loop? */
+ if (e->dest->loop_father != loop
+ && ! finite_loop_p (e->dest->loop_father))
+ break;
+ }
if (e)
break;
fixes the invariant motion on the GIMPLE level (at quite some cost generally
I would assume, finite_loop_p is quite conservative). RTL invariant motion
still messes things up then though... (CCing rtl opt maintainer)
[Bug tree-optimization/78185] Wrong branch optimization with -O1 on x86/x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78185
--- Comment #5 from Richard Biener ---
So for RTL the same issue exists - the always_reached computation is wrong.
I suppose the easiest would be to simply not try moving trapping invariants in
RTL invariant motion, it looks hardly useful after GIMPLE was here...
diff --git a/gcc/loop-invariant.c b/gcc/loop-invariant.c
index 551103f..deb5be6 100644
--- a/gcc/loop-invariant.c
+++ b/gcc/loop-invariant.c
@@ -1076,7 +1076,7 @@ pre_check_invariant_p (bool simple, rtx dest)
unless the program ends due to a function call. */
static void
-find_invariant_insn (rtx_insn *insn, bool always_reached, bool
always_executed)
+find_invariant_insn (rtx_insn *insn, bool, bool always_executed)
{
df_ref ref;
struct def *def;
@@ -1108,8 +1108,8 @@ find_invariant_insn (rtx_insn *insn, bool always_reached,
bool always_executed)
if (can_throw_internal (insn))
return;
- /* We cannot make trapping insn executed, unless it was executed before. */
- if (may_trap_or_fault_p (PATTERN (insn)) && !always_reached)
+ /* We cannot make trapping insn executed. */
+ if (may_trap_or_fault_p (PATTERN (insn)))
return;
depends_on = BITMAP_ALLOC (NULL);
dead code removal possible here (always_reached computation, eventually
always_executed as well).
Now have to devise a testcase... (raise a timeout signal, verify it is
catched?)
[Bug tree-optimization/78185] Wrong branch optimization with -O1 on x86/x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78185
--- Comment #4 from Richard Biener ---
Better patch (question answered, we walk all BBs of each loop, thus BBs in
sub-loop multiple times, and no, finite_loop_p would not catch infinite
subloops):
diff --git a/gcc/tree-ssa-loop-im.c b/gcc/tree-ssa-loop-im.c
index 463db04..0524e57 100644
--- a/gcc/tree-ssa-loop-im.c
+++ b/gcc/tree-ssa-loop-im.c
@@ -44,6 +44,7 @@ along with GCC; see the file COPYING3. If not see
#include "trans-mem.h"
#include "gimple-fold.h"
#include "tree-scalar-evolution.h"
+#include "tree-ssa-loop-niter.h"
/* TODO: Support for predicated code motion. I.e.
@@ -2369,8 +2370,16 @@ fill_always_executed_in_1 (struct loop *loop, sbitmap
contains_call)
break;
FOR_EACH_EDGE (e, ei, bb->succs)
- if (!flow_bb_inside_loop_p (loop, e->dest))
- break;
+ {
+ /* If there is an exit from this BB. */
+ if (!flow_bb_inside_loop_p (loop, e->dest))
+ break;
+ /* Or we enter a possibly non-finite loop. */
+ if (flow_loop_nested_p (bb->loop_father,
+ e->dest->loop_father)
+ && ! finite_loop_p (e->dest->loop_father))
+ break;
+ }
if (e)
break;
[Bug go/78172] gen-sysinfo.go vs AIX cred.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78172 --- Comment #4 from David Edelsohn --- Created attachment 39944 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39944&action=edit sysinfo.go Generated sysinfo.go file attached.
[Bug target/77933] Stack corruption on ARM when using high registers and __builtin_return_address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77933 Thomas Preud'homme changed: What|Removed |Added Known to fail||4.7.4, 4.8.5, 4.9.3 --- Comment #4 from Thomas Preud'homme --- Add known to fail version for unsupported releases as well.
[Bug middle-end/72747] powerpc: wrong code generated for vec_splats in cascading assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72747 Will Schmidt changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Will Schmidt --- Patches committed to trunk, and backported to both gcc-5 and gcc-6 branches. all fixed. :-)
[Bug tree-optimization/78185] Wrong branch optimization with -O1 on x86/x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78185 --- Comment #6 from Eric Botcazou --- > I suppose the easiest would be to simply not try moving trapping invariants > in RTL invariant motion, it looks hardly useful after GIMPLE was here... IIRC last time someone tried, this badly regressed gzip.
[Bug target/77308] surprisingly large stack usage for sha512 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308 --- Comment #54 from Bernd Edlinger --- (In reply to richard.earnshaw from comment #53) > On 02/11/16 11:57, bernd.edlinger at hotmail dot de wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308 > > > > --- Comment #52 from Bernd Edlinger --- > > (In reply to wilco from comment #51) > >> > >> Indeed, that's the reason behind the existing check. However it disables > >> all > >> profitable bswap cases while still generating unaligned accesses if no > >> bswap > >> is needed. So I am looking for a callback that gives the correct answer. It > >> would need to check -mno-unaligned-access and the target capabilities (eg. > >> if unaligned accesses are supported in hardware but really expensive we > >> want > >> to avoid them). > > > > Yes. I think ARM is becoming a non-strict-alignment platform. > > While x86_64 is moving in the opposite direction. > > It can never be a non-strict alignment platform while some memory access > instructions do not support unaligned accesses. > > However, it is progressively becoming a less slow unaligned access platform. > But isn't that exactly the same situation for x86_64: Most instructions support unaligned memory accesses, and a few data types need a movmisalign_optab ?
[Bug target/77904] [ARM Cortex-M0] Frame pointer thrashes registers if assembly statements with "sp" clobber are used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77904 Thomas Preud'homme changed: What|Removed |Added Keywords||wrong-code Known to fail||6.2.1 --- Comment #4 from Thomas Preud'homme --- Add known fail for older releases and wrong-code tag.
[Bug gcov-profile/65831] gcov does not output 0% coverage files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65831 --- Comment #4 from Martin Liška --- (In reply to Alex K. from comment #3) > I noticed that this bug was fixed on trunk. > https://github.com/gcc-mirror/gcc/blob/master/gcc/gcov.c#L916 > > But in branch gcc-4_9-branch > https://github.com/gcc-mirror/gcc/blob/gcc-4_9-branch/gcc/gcov.c#L728 > gcov.c-file > does not contain this bug fix. > > What newest version of GCC will contain this bug fix? GCC 4.9 is not going to have a release. If you are interested, I can back-port that to 5 and 6 branch. Are you?
[Bug rtl-optimization/78186] New: FAIL: gcc.c-torture/execute/bf64-1.c execution test because of revision 241664
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78186 Bug ID: 78186 Summary: FAIL: gcc.c-torture/execute/bf64-1.c execution test because of revision 241664 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: amker at gcc dot gnu.org Target Milestone: --- Hi, below commit commit 17fc6eeba9352b97ba16d64fd1de9a5bdc081062 Author: segher Date: Fri Oct 28 20:56:28 2016 + combine: Improve change_zero_ext (fixes PR71847) This improves a few things in change_zero_ext. Firstly, it should use the passed in pattern in recog_for_combine, not the pattern of the insn (they are not the same if the whole pattern was replaced). Secondly, it handled zero_ext of a subreg, but with hard registers we do not get a subreg, instead the mode of the reg is changed. So this handles that. Thirdly, after changing a zero_ext to an AND, the resulting RTL may become non-canonical, like (ior (ashift ..) (and ..)); the AND should be first, it is commutative. And lastly, zero_extract as a set_dest wasn't handled at all, but now it is. This fixes the testcase in PR71847, and improves code generation in some other edge cases too. PR target/71847 * combine.c (change_zero_ext): Handle zero_ext of hard registers. Swap commutative operands in new RTL if needed. Handle zero_ext in the set_dest. (recog_for_combine): Pass *pnewpat to change_zero_ext instead of PATTERN (insn). git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@241664 138bc75d-0d04-0410-961f-82ee72b054a4 causes test case failure on arm-none-linux-gnueabihf target: FAIL: gcc.c-torture/execute/bf64-1.c -O1 execution test GCC is configured as: ../gcc/configure --prefix=... --enable-languages=c,c++,fortran --disable-bootstrap --disable-libsanitizer --disable-libgomp --disable-libitm --disable-libssp --with-tune=cortex-a15 --with-fpu=neon --with-float=hard Test is compiled as: ./gcc bf64-1.c -fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects -w -lm -o ./bf64-1.exe -march=armv7-a also fails with -O1 optimization level. Thanks, bin
[Bug fortran/78152] [6/7 Regression] coarray and associate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78152 --- Comment #9 from physiker at toast2 dot net --- (In reply to vehre from comment #8) > Hi Steve, > > you asked what other compilers have to say to the code (the one in the > description). > > Ifort: > > > ifort bug.f90 -o bug -coarray > bug.f90: catastrophic error: **Internal compiler error: segmentation > violation signal raised** Please report this error along with the > circumstances in which it occurred in a Software Problem Report. Note: File > and line given may not be explicit cause of this error. > compilation aborted for bug.f90 (code 1) > > ifort -v > ifort version 15.0.1 > Ifort version 17 (linux) supports coarrays as selectors in an associate construct: >ifort -o bug bug.f90 -warn all -check all -coarray >./bug >echo $? 0 >ifort -v ifort version 17.0
[Bug gcov-profile/65831] gcov does not output 0% coverage files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65831 --- Comment #5 from Alex K. --- (In reply to Martin Liška from comment #4) > (In reply to Alex K. from comment #3) > > I noticed that this bug was fixed on trunk. > > https://github.com/gcc-mirror/gcc/blob/master/gcc/gcov.c#L916 > > > > But in branch gcc-4_9-branch > > https://github.com/gcc-mirror/gcc/blob/gcc-4_9-branch/gcc/gcov.c#L728 > > gcov.c-file > > does not contain this bug fix. > > > > What newest version of GCC will contain this bug fix? > > GCC 4.9 is not going to have a release. If you are interested, I can > back-port that to 5 and 6 branch. Are you? Yes, I am interested. Please, back-port that to 5 and 6 branch. Thank you!
[Bug fortran/78152] [6/7 Regression] coarray and associate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78152 --- Comment #10 from Steve Kargl --- On Wed, Nov 02, 2016 at 03:39:58PM +, physiker at toast2 dot net wrote: > > Ifort version 17 (linux) supports coarrays as selectors in an associate > construct: > >ifort -o bug bug.f90 -warn all -check all -coarray > >./bug > >echo $? > 0 > >ifort -v > ifort version 17.0 > According the standard (at least under my interpretation of the standard) it should only support coarray as a selector under very limited conditions. I have been in contact with a member of J3 and sent him an interpretation request. Your code should compile because entities in a main program implicitly have the SAVE attribute. Changing your code to a subroutine removes the implicit SAVE. In that case, none of the conditions in F2008 C526 are met, and ifort is required to issue an error.
[Bug rtl-optimization/78186] FAIL: gcc.c-torture/execute/bf64-1.c execution test because of revision 241664
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78186 --- Comment #1 from amker at gcc dot gnu.org --- Lto is unnecessary to reproduce it: ./gcc bf64-1.c -fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -w -lm -o ./bf64-1.exe -march=armv7-a Thanks, bin
[Bug fortran/78187] New: -fno-automatic does not work with allocatable scalar character result result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78187 Bug ID: 78187 Summary: -fno-automatic does not work with allocatable scalar character result result Product: gcc Version: 6.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: nuclearlee at gmail dot com Target Milestone: --- Created attachment 39945 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39945&action=edit test.f90 contains a module and a test program to demonstrate described bug. Summary: The attached code should returns an allocatable scalar character as a "result". If I compile without -fno-automtic I get the correct result, if I compile with -fno-automatic, I get an empty string that is allocated (for gfortran 6.2.0, 5.4.1, and 4.9.4. 4.8.5 gives close to the correct result with some garbage appended to it). If I instead use the function name to return the result (instead of using the keyword "result"), the function works with -fno-automatic). More details below. Thanks, Lee Detail: If I compile in Ubuntu using gcc-6.2 (gcc version 6.2.0 20160901 (Ubuntu 6.2.0-3ubuntu11~14.04) using the following command $ gfortran-6 -o test.exe test.f90 I get the correct result: $ ./test.exe c|abcdef| T If I compile using -fno-automatic, however, I get the folowing $ gfortran-6 -fno-automatic -o test.exe test.f90 I get the correct result: $ ./test.exe c|| T Also, If I change the function scalar in test_module so that I'm not using "result", and instead declaring scalar and setting it, it returns the *correct* result using -fno-automatic, i.e., function scalar(a, b) result(c) character(len=*), intent(in) :: a, b character(len=:), allocatable :: scalar scalar = trim(a)//trim(b) end function scalar I used a few different versions and -fno-automatic has the same result in all of them (4.9.4, 5.4.1 and 4.8.5). gfortran 4.8.5 returns the closest to a correct result (though still incorrect): $ gfortran-4.8 -fno-automatic -o test.exe test.f90 $ ./test.exe c|abcdef�q�abcdef��| T
[Bug target/69616] optimization of 8 movb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69616 Bug 69616 depends on bug 22141, which changed state. Bug 22141 Summary: [5/6/7 Regression] Missing optimization when storing structures https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22141 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug other/16996] [meta-bug] code size improvements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16996 Bug 16996 depends on bug 22141, which changed state. Bug 22141 Summary: [5/6/7 Regression] Missing optimization when storing structures https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22141 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug middle-end/22141] [5/6/7 Regression] Missing optimization when storing structures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22141 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Known to work||7.0 Resolution|--- |FIXED --- Comment #38 from ktkachov at gcc dot gnu.org --- Fixed for GCC 7
[Bug target/77933] Stack corruption on ARM when using high registers and __builtin_return_address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77933 Thomas Preud'homme changed: What|Removed |Added Known to fail||5.4.1 --- Comment #3 from Thomas Preud'homme --- Bug was introduced in r175605 and thus affect all releases from 4.7 onwards
[Bug go/78172] gen-sysinfo.go vs AIX cred.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78172 --- Comment #5 from Ian Lance Taylor --- Thanks. I do not see any problem in that file you attached. I also don't see anything like the line in the original error message. Looking more closely at that line, I see now that it appears to have several separate statements stuck together. Each "type" keyword should appear at the beginning of a line (this is not required by the Go language, but it is a result of how sysinfo.go is generated). And indeed in the sysinfo.go file that you attached that is what I see. I think we need to understand why that is not true in the original report. sysinfo.go is generated by the script libgo/mksysinfo.sh from the generated file gen-sysinfo.go. The file gen-sysinfo.go is generated by running gcc -fdump-go-spec on sysinfo.c. Where did things go wrong?
[Bug target/78168] [7 Regression] Second ICE in maybe_record_trace_start, at dwarf2cfi.c:2285
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78168 --- Comment #12 from Segher Boessenkool --- Author: segher Date: Wed Nov 2 17:06:04 2016 New Revision: 241799 URL: https://gcc.gnu.org/viewcvs?rev=241799&root=gcc&view=rev Log: rs6000: Disable shrink-wrap-separate for abi=spe (PR78168) With the SPE ABI, if we wrap GPRs we need to handle the upper half of the extended 64-bit registers as well, which we cannot easily do. So, this patch disables separate shrink-wrapping for the SPE ABI. PR target/78168 * config/r6000/rs6000.c (rs6000_get_separate_components): Return NULL if TARGET_SPE_ABI. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c
[Bug bootstrap/78188] New: [7 Regression] AIX Bootstrap broken by tree-vrp.c change
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78188 Bug ID: 78188 Summary: [7 Regression] AIX Bootstrap broken by tree-vrp.c change Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: dje at gcc dot gnu.org CC: rguenth at gcc dot gnu.org Target Milestone: --- Target: powerpc-ibm-aix* With the tree-vrp.c change of r241774, I encounter the following error during stage2: In file included from /nasfarm/edelsohn/src/sandbox/gcc/tree-ssa-sccvn.c:58:0: /nasfarm/edelsohn/src/sandbox/gcc/tree-ssa-sccvn.h: In function 'tree_node* vn_valueize(tree)': /nasfarm/edelsohn/src/sandbox/gcc/tree-ssa-sccvn.h:249:1: error: tree_node* vn_valueize(tree) causes a section type conflict with tree_node** gimple_ops(gimple*) vn_valueize (tree name) ^~~ In file included from /nasfarm/edelsohn/src/sandbox/gcc/tree-ssa-sccvn.c:27:0: /nasfarm/edelsohn/src/sandbox/gcc/gimple.h:2360:1: note: 'tree_node** gimple_ops(gimple*)' was declared here gimple_ops (gimple *gs) ^~ Analysis continuing...
[Bug go/78172] gen-sysinfo.go vs AIX cred.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78172
--- Comment #6 from Tony Reix ---
Created attachment 39946
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39946&action=edit
Original sysinfo.go file
Hi Ian
Here is the sysinfo.go file that was generated at first.
The previous sysinfo.go file provided in this bug was the result of a patch in
order to fix some issue and go further.
The faulty line is:
type Ucred struct { Cr_ref int32; Cr_ruid uint32; Cr_uid uint32; Cr_suid
uint32; Cr_luid uint32; Cr_acctid uint32; Cr_gid uint32; Cr_rgid uint32;
Cr_sgid uint32; Cr_ngrps int16; Cr_caps int16; Cr_groupset _groupset_t;
Cr_mpriv _priv_t; Cr_ipriv _priv_t; Cr_epriv _priv_t; Cr_bpriv _priv_t; Cr_pag
int32; } type _ucred_43 struct { ocr_ref int32; Ocr_ruid uint32; Ocr_uid
uint32; Ocr_suid uint32; Ocr_luid uint32; Ocr_acctid uint32; Ocr_gid uint32;
Ocr_rgid uint32; Ocr_sgid uint32; Ocr_ngrps int16; Ocr_groups [31+1]uint32;
Ocr_mpriv _priv_t; Ocr_ipriv _priv_t; Ocr_epriv _priv_t; Ocr_bpriv _priv_t;
Ocr_pag int32; } type _ucred_ext struct { crx_ruid uint32; Crx_uid uint32;
Crx_suid uint32; Crx_luid uint32; Crx_acctid uint32; Crx_gid uint32; Crx_rgid
uint32; Crx_sgid uint32; Crx_ngrps int32; Crx_groups [127+1]uint32;
Crx_reserved_1 int32; Crx_caps ___cap_t; Crx_mpriv _priv_t; Crx_ipriv _priv_t;
Crx_epriv _priv_t; Crx_bpriv _priv_t; Crx_npags int32; Crx_pagids [15+1]uint8;
Crx_pags [15+1]int32; Crx_reserved_2 int32; Crx_roles [7+1]uint32; Crx_nroles
int16; Crx_reserved_3 int16; Crx_flags uint32; Crx_effpriv _privg_t;
Crx_maxpriv _privg_t; Crx_inhpriv _privg_t; Crx_limpriv _privg_t; Crx_usedpriv
_privg_t; Crx_pad [31+1]int32; } type _ucred_ext2_t struct { crx2_labels
_sec_labels_t; Crx_pad [147+1]int32; }
This line contains several definitions, like:
type Ucred struct { ... } type _ucred_43 struct { ... } type _ucred_ext
struct { ... } type _ucred_ext2_t struct { ... }
It appears that, on AIX, there are several ucred* definitions and the tool does
not handle them correctly.
I've written the following patch for working-around the issue:
--- old/libgo/mksysinfo.sh 2016-10-21 10:45:35 +0200
+++ new/libgo/mksysinfo.sh 2016-10-21 11:03:34 +0200
@@ -532,7 +532,8 @@
field="$f$r"
nfields="$nfields $field;"
done
-echo "${prefix} {$nfields }"
+# AIX: For ucred case, split joined lines "...} type ..." into several lines
+echo "${prefix} {$nfields }" | sed -e "s/} type/}\\ntype/g"
fi
}
@@ -816,7 +817,12 @@
sed -e 's/^\(const \)_\(SCM_[^= ]*\)\(.*\)$/\1\2 = _\2/' >> ${OUT}
# The ucred struct.
-upcase_fields "_ucred" "Ucred" >> ${OUT} || true
+# AIX: In addition to: _ucred , -fdump-go-spec finds also: _ucred_43
_ucred_ext _ucred_ext2
+# AIX: For ucred, several types after first one are duplicated. Print only
first one.
+upcase_fields "_ucred" "Ucred" | awk '{print $0; exit}' >> ${OUT} ||
true
+upcase_fields "_ucred_43" "Ucred_43" | awk '{print $0; exit}' >> ${OUT} ||
true
+upcase_fields "_ucred_ext" "Ucred_ext" | awk '{print $0; exit}' >> ${OUT} ||
true
+upcase_fields "_ucred_ext2" "Ucred_ext2" | awk '{print $0; exit}' >> ${OUT} ||
true
# The ip_mreq struct.
grep '^type _ip_mreq ' gen-sysinfo.go | \
@@ -1466,6 +1472,7 @@
fi
# Struct sizes.
+# AIX: This generates several ucred lines
set cmsghdr Cmsghdr ip_mreq IPMreq ip_mreqn IPMreqn ipv6_mreq IPv6Mreq \
ifaddrmsg IfAddrmsg ifinfomsg IfInfomsg in_pktinfo Inet4Pktinfo \
in6_pktinfo Inet6Pktinfo inotify_event InotifyEvent linger Linger \
I've found also another issue within mksysinfo.sh on AIX:
The "grep -v 'in6_addr'" command removes definition that seem useful.
--- old/libgo/mksysinfo.sh 2016-10-21 10:45:35 +0200
+++ new/libgo/mksysinfo.sh 2016-10-21 11:03:34 +0200
@@ -299,6 +299,15 @@
-e 's/\([^a-zA-Z0-9_]\)_timestruc_t\([^a-zA-Z0-9_]\)/\1Timestruc\2/g' \
>> ${OUT}
+# AIX: The _arpcom struct, removed by previous "grep -v 'in6_addr'"
+grep '^type _arpcom ' gen-sysinfo.go | \
+ sed -e 's/\([^a-zA-Z0-9_]\)_timeval\([^a-zA-Z0-9_]\)/\1Timeval\2/g' \
+ -e 's/\([^a-zA-Z0-9_]\)_timespec_t\([^a-zA-Z0-9_]\)/\1Timespec\2/g' \
+ -e 's/\([^a-zA-Z0-9_]\)_timespec\([^a-zA-Z0-9_]\)/\1Timespec\2/g' \
+ -e 's/\([^a-zA-Z0-9_]\)_timestruc_t\([^a-zA-Z0-9_]\)/\1Timestruc\2/g' \
+ -e 's/_in6_addr/[16]byte/' \
+>> ${OUT}
+
# The errno constants. These get type Errno.
echo '#include ' | ${CC} -x c - -E -dM | \
egrep '#define E[A-Z0-9_]+ ' | \
[Bug go/78172] gen-sysinfo.go vs AIX cred.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78172
--- Comment #7 from Ian Lance Taylor ---
Thanks. Does a patch like this fix the immediate ucred problem?
diff --git a/libgo/mksysinfo.sh b/libgo/mksysinfo.sh
index 3640476..6c457b6 100755
--- a/libgo/mksysinfo.sh
+++ b/libgo/mksysinfo.sh
@@ -268,7 +268,7 @@ fi
# is not empty, the structure or type is renamed to $2.
upcase_fields () {
name="$1"
- def=`grep "^type $name" gen-sysinfo.go`
+ def=`grep "^type $name " gen-sysinfo.go`
fields=`echo $def | sed -e 's/^[^{]*{\(.*\)}$/\1/'`
prefix=`echo $def | sed -e 's/{.*//'`
if test "$2" != ""; then
[Bug go/78172] gen-sysinfo.go vs AIX cred.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78172 --- Comment #8 from Tony Reix --- Created attachment 39947 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39947&action=edit Patch for mksysinfo for ucred and in6_addr Here is the patch I talked about in the previous comment, now as a file. It is a work-around for enabling me to go further building GCC Go. Probably that a cleaner and generic solution is required.
[Bug go/78172] gen-sysinfo.go vs AIX cred.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78172 --- Comment #9 from Ian Lance Taylor --- Regarding arpcom, the syscall package is not really intended to include everything that seems useful. That is the goal of the external package golang.org/x/sys/unix. The syscall package only includes everything needed by the standard library, and some functions and types that were there historically and are now hard to remove.
[Bug rtl-optimization/78186] FAIL: gcc.c-torture/execute/bf64-1.c execution test because of revision 241664
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78186 --- Comment #2 from amker at gcc dot gnu.org --- Hmm, looks like it also causes below failures: aarch64_be-none-elf: FAIL: gcc.c-torture/execute/pr57130.c -O1 execution test FAIL: g++.dg/torture/vshuf-v8si.C -O2 execution test arm-none-eabi/-marm -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=softfp: FAIL: c-c++-common/torture/vector-compare-1.c -O1 execution test FAIL: c-c++-common/torture/vector-compare-1.c -O2 execution test FAIL: c-c++-common/torture/vector-compare-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none execution test FAIL: c-c++-common/torture/vector-compare-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects execution test FAIL: c-c++-common/torture/vector-compare-1.c -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test FAIL: c-c++-common/torture/vector-compare-1.c -O3 -g execution test FAIL: c-c++-common/torture/vector-compare-1.c -Os execution test I guess bf64-1.c is easier to debug, I can verify these tests once you got a patch. Thanks, bin
[Bug fortran/77679] [6 Regression] ICE in fold_array_ctor_reference, at gimple-fold.c:5586
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77679 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #10 from kargl at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #8) > > Fixed. > > Really? I still see the error > > Error: size of variable 'A.0' is too large As Richard noted, the code is invalid because n(1) is reference but never defined. n(1) likely contains garbage. -Wuninitialized and.or -Wall should probably catch this, but it currently doesn't.
[Bug c++/69967] #pragma GCC diagnostic ignored being ignored for -Wunused-variable in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69967 gnuBSt changed: What|Removed |Added CC||ext-borislav.stoyanov@here. ||com --- Comment #4 from gnuBSt --- PS. Any development on this issue?
[Bug tree-optimization/78189] New: movaps generated for unaligned store in aligned struct, when struct is referenced via unaligned member.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78189
Bug ID: 78189
Summary: movaps generated for unaligned store in aligned
struct, when struct is referenced via unaligned
member.
Product: gcc
Version: 6.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jwyatt at feralinteractive dot com
Target Milestone: ---
The code below, when compiled with -O2 -ftree-slp-vectorize -Wall -Wextra,
generates:
pxor %xmm0,%xmm0
movaps %xmm0,0x10(%rdi)
for NullB. This causes a segfault, as rdi contains the address of the 8-byte
aligned "misaligned" member of struct B.
This does not happen if NullB uses reinterpret_cast instead of
uint8_t*, if "misaligned" and "pad" are swapped (so that "misaligned" is in
fact aligned). B::Null() is also fine.
// Impl.h
#include
struct A
{
void * a;
void * b;
};
struct alignas(16) B
{
void * pad;
void * misaligned;
void * pad2;
A a;
void Null();
};
static_assert((offsetof(B, a) % 16) == 8, "A should be misaligned for this
test");
void NullB(void * misalignedPtr);
// Impl.cpp
#include
#include "Impl.h"
void B::Null()
{
a.a = nullptr;
a.b = nullptr;
}
void NullB(void * misalignedPtr)
{
B* b = reinterpret_cast(reinterpret_cast(misalignedPtr)
- offsetof(B, misaligned));
b->Null();
}
// main.cpp
#include "Impl.h"
int main()
{
B b;
NullB(&b.misaligned);
return 0;
}
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/6.2.1/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-linker-hash-style=gnu --enable-plugin --enable-initfini-array
--disable-libgcj --with-isl --enable-libmpx --enable-gnu-indirect-function
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 6.2.1 20160916 (Red Hat 6.2.1-2) (GCC)
[Bug c/65892] gcc fails to implement N685 aliasing of union members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892 --- Comment #21 from Tim Rentsch --- [responding to comments from jos...@codesourcery.com in Comment 19] >> Five: The answer to the question is clearly No. The example code >> is very much on point to the "one special guarantee" clause, and >> so the read access p1->m is permitted. As the access is permitted, > > I maintain that, as I said in comment#9, the textual history > indicates that the original intent of saying things are permitted > here is *only* an exception to the general implementation-defined > nature of type punning, not to any other reason why things might > be undefined (such as aliasing rules, data races, etc.). I went back and read through your earlier comments more carefully. After that I also reviewed C90, N869, C99, N1124, N1256, DR 236, DR 257, DR 283, and C11 (in the guise of the just-pre-C11 draft N1570). Let me say first that I agree with you that the Semantics section of the member access operators (. and ->) needs at least some revision and clarification. Having said that, let me offer several more detailed responses and/or comments. One: IME later versions of the C standard generally do a better job of expressing what is intended than earlier versions do. Two: The "visible union" condition in C99 was viewed not as a change to C90 but as correcting an oversight; it was expected all along that the union type would be in scope, even if the expectation was not a conscious one originally. I am sorry I don't have a reference handy for this, but one can be found digging around in the historical documents on the open-std.org website. Three: The "one special guarantee" rule is independent of the rules for effective types. This observation is obviously right because effective type rules matter only for access to objects. The only objects being accessed under the "one special guarantee" rule are guaranteed to have compatible types, which is always allowed by effective type rules. Four: The "one special guarantee" rule is related to the area of "type punning" through unions, but seen by WG14 as a separate issue relative to the general topic. This is evident from the committee response in DR 257. Five: The footnote added in C99 TC3 about type punning is seen by WG14 not as a change but just as a clarifying comment noting what behavior was intended all along. This is evident from the text and response in DR 283. Note that Clark Nelson, the author of this DR, is a long-standing member of WG14, and the suggested revision given in the text was adopted verbatim for the TC. Six: A key question here is What is the point or purpose of the "one special guarantee" rule in the first place? the Standard doesn't say, but let me propose two likely motivations. 1. Normally objects may be assumed not to overlap unless they are accessed through an explicit union membership expression (or through a character type, etc). The "one special guarantee" rule identifies a case where an explicit union membership expression is not needed. 2. The C standard distinctly allows any amount of padding between consecutive members of a struct. Without the "one special guarantee" rule, there would be no way to be sure that the offsets of the respective members would match in all cases. The "one special guarantee" rule has the effect of forcing offsets of struct members in a common initial sequence to be the same. That is important for code portability. Seven: Given that the question is now under serious debate, IMO someone involved with gcc development should take the initiative and responsibility to submit a defect report in order to clarify the issue. Apparently other compilers don't have this problem - only gcc does. Eight: In the meantime, the most prudent course of action is to fix gcc so that it does not reorder code in cases like the above. Whenever there is any doubt, the only sensible choice is to err on the side of caution, and not perform any code transformations that might not be allowed in a conforming implementation. (Of course it would be okay to perform such transformations under some non-default compiler option, as long as it is not in force unless explicitly requested, and clearly flagged as possibly non-conforming.) Nine: Doing a final review, I realized I have not yet responded directly to your last comment. I agree with your general sentiment that the "one special guarantee" rule is not meant as a "super rule" that trumps all other possible reasons for undefined behavior. However, I do not agree with your primary point that it is meant to be limited to the "type punning" area. The example I previously mentioned in the C standard, and the committee discussion in DR 257, both show that there are other factors involved here beyond just those related to type punning. I hope the above has helped clarify the matter. I look forward to reading your responding comment
[Bug c/65892] gcc fails to implement N685 aliasing of union members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892 --- Comment #22 from Tim Rentsch --- [responding to comments from rguent...@suse.de in Comment 20] > GCC already implements this if you specify -fno-strict-aliasing. The main point of my comments is that the ISO C standard requires the behavior in this case (and similar cases) be defined and not subject to any reordering. In other words the result must be the same as an unoptimized version. If a -fstrict-aliasing gcc /does/ transform the code so that the behavior is not the same as an unoptimized version, then gcc is not a conforming implementation. Or is it your position that gcc is conforming only when operated in the -fno-strict-aliasing mode? That position seems contrary to the documented description of the -fstrict-aliasing option.
[Bug rtl-optimization/78186] FAIL: gcc.c-torture/execute/bf64-1.c execution test because of revision 241664
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78186 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-11-02 Ever confirmed|0 |1 --- Comment #3 from Segher Boessenkool --- Hi Bin, Could you try this patch please? === diff --git a/gcc/combine.c b/gcc/combine.c index 7c21fe4..7ed0a62 100644 --- a/gcc/combine.c +++ b/gcc/combine.c @@ -11224,6 +11224,9 @@ change_zero_ext (rtx pat) rtx x = gen_rtx_AND (mode, reg, immed_wide_int_const (mask, mode)); rtx y = simplify_gen_binary (ASHIFT, mode, SET_SRC (pat), GEN_INT (offset)); + wide_int mask2 = wi::shifted_mask (offset, width, false, reg_width); + y = simplify_gen_binary (AND, mode, y, + immed_wide_int_const (mask2, mode)); rtx z = simplify_gen_binary (IOR, mode, x, y); SUBST (SET_DEST (pat), reg); SUBST (SET_SRC (pat), z); ===
[Bug fortran/69544] [5/6/7 Regression] Internal compiler error with -Wall and where
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69544 --- Comment #8 from Thomas Koenig --- Author: tkoenig Date: Wed Nov 2 20:54:29 2016 New Revision: 241802 URL: https://gcc.gnu.org/viewcvs?rev=241802&root=gcc&view=rev Log: 2016-11-02 Thomas Koenig Backport from trunk PR fortran/69544 PR fortran/78178 * gfortran.dg/where_5.f90: New test. * gfortran.dg/where_6.f90: New test. 2016-11-02 Thomas Koenig Backport from trunk PR fortran/69544 PR fortran/78178 * match.c (match_simple_where): Fill in locus for assigment in simple WHERE statement. (gfc_match_where): Likewise. Added: branches/gcc-6-branch/gcc/testsuite/gfortran.dg/where_5.f90 branches/gcc-6-branch/gcc/testsuite/gfortran.dg/where_6.f90 Modified: branches/gcc-6-branch/gcc/fortran/ChangeLog branches/gcc-6-branch/gcc/fortran/match.c branches/gcc-6-branch/gcc/testsuite/ChangeLog
[Bug fortran/78178] ICE in WHERE statement with diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78178 --- Comment #4 from Thomas Koenig --- Author: tkoenig Date: Wed Nov 2 20:54:29 2016 New Revision: 241802 URL: https://gcc.gnu.org/viewcvs?rev=241802&root=gcc&view=rev Log: 2016-11-02 Thomas Koenig Backport from trunk PR fortran/69544 PR fortran/78178 * gfortran.dg/where_5.f90: New test. * gfortran.dg/where_6.f90: New test. 2016-11-02 Thomas Koenig Backport from trunk PR fortran/69544 PR fortran/78178 * match.c (match_simple_where): Fill in locus for assigment in simple WHERE statement. (gfc_match_where): Likewise. Added: branches/gcc-6-branch/gcc/testsuite/gfortran.dg/where_5.f90 branches/gcc-6-branch/gcc/testsuite/gfortran.dg/where_6.f90 Modified: branches/gcc-6-branch/gcc/fortran/ChangeLog branches/gcc-6-branch/gcc/fortran/match.c branches/gcc-6-branch/gcc/testsuite/ChangeLog
[Bug c/65892] gcc fails to implement N685 aliasing of union members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892 --- Comment #23 from joseph at codesourcery dot com --- On Wed, 2 Nov 2016, txr at alumni dot caltech.edu wrote: > Seven: Given that the question is now under serious debate, IMO > someone involved with gcc development should take the initiative > and responsibility to submit a defect report in order to clarify > the issue. Apparently other compilers don't have this problem - I thought Martin was going to do that (comment#10). The various DR responses in this area suffer from (a) only deciding particular limited cases at most rather than interpreting things more generally, and not being very clear about what they decide, and (b) by not looking at exactly what the special guarantee is meant to relate to, and the different ways that has been interpreted in the past, thereby compounding the confusion from that wording having been written and edited over time by people who interpreted it in different ways, probably each assuming all the other people had interpreted it the same way.
[Bug fortran/78187] -fno-automatic does not work with allocatable scalar character result result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78187
Thomas Koenig changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2016-11-02
CC||tkoenig at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Thomas Koenig ---
Seems like allocatable character functions don't work with
-fno-automatic. The problem is not in the main program:
$ cat mod.f90
module test_module
implicit none
contains
function scalar(a, b) result(c)
character(len=*), intent(in) :: a, b
character(len=:), allocatable :: c
c = trim(a)//trim(b)
print *,c
end function scalar
end module test_module
$ cat a.f90
! built using the following commands
! gfortran-6 -o testscal_f.exe testallocatablescalars.f90
! gfortran-6 -fno-automatic -o testscal_f.exe testallocatablescalars.f90
program test
use test_module
use iso_fortran_env
implicit none
character(len=:), allocatable :: c
c = scalar("abc","def")
write(*,*)"c|", c, "|", allocated(c)
end program test
$ gfortran -c -fno-automatic mod.f90 && gfortran -c a.f90 && gfortran mod.o a.o
&& ./a.out
abcdef
c|| T
