[Bug tree-optimization/91909] [10 regression] gcc.dg/vect/vect-cond-4.c fails on armeb after r275898
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91909 --- Comment #6 from rsandifo at gcc dot gnu.org --- Author: rsandifo Date: Fri Sep 27 08:21:37 2019 New Revision: 276175 URL: https://gcc.gnu.org/viewcvs?rev=276175&root=gcc&view=rev Log: Fix reduc_index==1 handling for COND_REDUCTION (PR91909) The then/else order of the VEC_COND_EXPRs created by vect_create_epilog_for_reduction meeds to line up with the main VEC_COND_EXPR. 2019-09-27 Richard Sandiford gcc/ PR tree-optimization/91909 * tree-vect-loop.c (vect_create_epilog_for_reduction): Take a reduc_index parameter. When handling COND_REDUCTION, make sure that the reduction phi operand is in the correct arm of the VEC_COND_EXPR. (vectorizable_reduction): Pass reduc_index to the above. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vect-loop.c
[Bug tree-optimization/91909] [10 regression] gcc.dg/vect/vect-cond-4.c fails on armeb after r275898
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91909 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from rsandifo at gcc dot gnu.org --- Fixed.
[Bug middle-end/91920] ggc 9.2.0 failing openmp compile on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91920 --- Comment #3 from Jakub Jelinek --- Will fix, just note that the testcase is invalid (racy).
[Bug middle-end/91920] ggc 9.2.0 failing openmp compile on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91920 --- Comment #4 from Daniel Kolesa --- Yeah, the testcase doesn't really matter, AFAIK the purpose here was just to provide something that fails in the same way as darktable (which is the project where this bug shows up).
[Bug c++/91925] New: -fpack-struct causes a decltype with template to ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91925 Bug ID: 91925 Summary: -fpack-struct causes a decltype with template to ICE Product: gcc Version: 9.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jan at ypmania dot nl Target Milestone: --- Created attachment 46959 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46959&action=edit Minimal reproducer testcase When compiling the given test case (which uses decltype on an expression that needs template argument inference) with "-fpack-struct", gcc produces an internal compiler error (segmentation fault). $ gcc -fpack-struct test.cpp -o test.o test.cpp:21:32: internal compiler error: Segmentation fault 21 | auto_var(pinTX, PinPD1(usart0)); |^ test.cpp:17:39: note: in definition of macro ‘auto_var’ 17 | #define auto_var(name, expr) decltype(expr) name = expr Removing pack-struct makes the code compile fine, as does uncommenting the alternative declaration on line 22 (which does not use decltype). This is on 9.2.0 (arch linux). Using compiler explorer shows that trunk, 9.2, 9.1 have the bug, while 8.3.0 compiled this fine (with -fpack-struct). The context is AVR embedded development, where it is common to use -fpack-struct (and not use any standard library).
[Bug middle-end/91920] ggc 9.2.0 failing openmp compile on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91920 robert at robbieab dot com changed: What|Removed |Added Attachment #46954|0 |1 is obsolete|| --- Comment #5 from robert at robbieab dot com --- Created attachment 46960 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46960&action=edit Revised, more minimal, non-racy test case. This is an even more minimal test-case with the racy-behaviour stripped out.
[Bug middle-end/91920] ggc 9.2.0 failing openmp compile on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91920 robert at robbieab dot com changed: What|Removed |Added Attachment #46955|0 |1 is obsolete|| --- Comment #6 from robert at robbieab dot com --- Created attachment 46961 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46961&action=edit Preprocessed version of the revised test case.
[Bug middle-end/91920] ggc 9.2.0 failing openmp compile on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91920 --- Comment #7 from robert at robbieab dot com --- Yeah, what Daniel said. The test case here was just "something simple that triggers the problem". The revised test cases also exhibit the problem for me, and shouldn't be racy, or anything else really!
[Bug middle-end/91920] ggc 9.2.0 failing openmp compile on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91920 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-09-27 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #8 from Jakub Jelinek --- Created attachment 46962 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46962&action=edit gcc10-pr91920.patch Untested fix.
[Bug lto/48200] Implement function attribute for symbol versioning (.symver)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200 --- Comment #32 from Andrew Pinski --- >I'm sure -flto-parition=none is needed for workaround, now. This does not always work. I think if the symver was done in an archive.
[Bug lto/48200] Implement function attribute for symbol versioning (.symver)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200 --- Comment #33 from Andrew Pinski --- See https://mails.dpdk.org/archives/dev/2019-September/144749.html also.
[Bug middle-end/91920] ggc 9.2.0 failing openmp compile on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91920 --- Comment #9 from robert at robbieab dot com --- Does the patch mean k[] gets marked as shared?
[Bug tree-optimization/91885] [9 Regression] ICE when compiling SPEC 2017 blender benchmark with -O3 -fprofile-generate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91885 --- Comment #7 from Jakub Jelinek --- Author: jakub Date: Fri Sep 27 10:28:48 2019 New Revision: 276178 URL: https://gcc.gnu.org/viewcvs?rev=276178&root=gcc&view=rev Log: PR tree-optimization/91885 * gcc.dg/pr91885.c (__int64_t): Change from long to long long. (__uint64_t): Change from unsigned long to unsigned long long. Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/pr91885.c
[Bug middle-end/91920] ggc 9.2.0 failing openmp compile on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91920 --- Comment #10 from Jakub Jelinek --- (In reply to robert from comment #9) > Does the patch mean k[] gets marked as shared? No, k is a local automatic variable in the scope of the worksharing loop body and as such it is really private. The patch is about the .LC0 which is an artificial static variable which the gimplifier inserts on some targets for the initializer, and indeed, the patch makes it shared (it was shared before as well, because without default(none) vars with implicit data sharing are shared and shared is the only reasonable thing to do with .rodata variables, you don't want to copy them just to make things slower.
[Bug middle-end/91920] ggc 9.2.0 failing openmp compile on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91920 --- Comment #11 from Jakub Jelinek --- BTW, dunno what darktable uses, but if it has possibly large automatic local variable in the body with possibly large initializer and that variable isn't really modified, you might as well make it static const.
[Bug middle-end/91920] ggc 9.2.0 failing openmp compile on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91920 --- Comment #12 from robert at robbieab dot com --- Ah, thank you for the explanation. I will try and test this today.
[Bug ipa/89924] [missed-optimization] Function not de-virtualized within the same TU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89924 --- Comment #7 from Kamlesh Kumar --- After this patch diff --git a/gcc/ipa-polymorphic-call.c b/gcc/ipa-polymorphic-call.c index 705af03..b76793f 100644 --- a/gcc/ipa-polymorphic-call.c +++ b/gcc/ipa-polymorphic-call.c @@ -1118,6 +1118,10 @@ ipa_polymorphic_call_context::ipa_polymorphic_call_context (tree fndecl, We do not make this type of flow sensitive analysis yet. */ if (instance) *instance = base_pointer; + + if (((TREE_CODE (TREE_TYPE(base_type)) == RECORD_TYPE))) +outer_type = TYPE_MAIN_VARIANT (TREE_TYPE (TREE_TYPE (base_pointer))); + return; } Gcc produces this code for above reported testcase. .file "test.cpp" .text .section .text._ZN4AintpLERK1A,"axG",@progbits,_ZN4AintpLERK1A,comdat .align 2 .p2align 4 .weak _ZN4AintpLERK1A .type _ZN4AintpLERK1A, @function _ZN4AintpLERK1A: .LFB3: .cfi_startproc movl8(%rsi), %edx movq%rdi, %rax addl%edx, 8(%rdi) ret .cfi_endproc .LFE3: .size _ZN4AintpLERK1A, .-_ZN4AintpLERK1A .text .p2align 4 .globl _Z9foo_innerPi .type _Z9foo_innerPi, @function _Z9foo_innerPi: .LFB0: .cfi_startproc sall(%rdi) ret .cfi_endproc .LFE0: .size _Z9foo_innerPi, .-_Z9foo_innerPi .p2align 4 .globl _Z17foo_virtual_innerP1A .type _Z17foo_virtual_innerP1A, @function _Z17foo_virtual_innerP1A: .LFB1: .cfi_startproc movq(%rdi), %rax movq(%rax), %rax cmpq$_ZN4AintpLERK1A, %rax jne .L5 sall8(%rdi) ret .p2align 4,,10 .p2align 3 .L5: movq%rdi, %rsi jmp *%rax .cfi_endproc .LFE1: .size _Z17foo_virtual_innerP1A, .-_Z17foo_virtual_innerP1A .p2align 4 .globl _Z3fooPi .type _Z3fooPi, @function _Z3fooPi: .LFB6: .cfi_startproc sall(%rdi) ret .cfi_endproc .LFE6: .size _Z3fooPi, .-_Z3fooPi .p2align 4 .globl _Z11foo_virtualP4Aint .type _Z11foo_virtualP4Aint, @function _Z11foo_virtualP4Aint: .LFB4: .cfi_startproc sall8(%rdi) ret .cfi_endproc .LFE4: .size _Z11foo_virtualP4Aint, .-_Z11foo_virtualP4Aint .ident "GCC: (GNU) 10.0.0 20190821 (experimental)" .section.note.GNU-stack,"",@progbits
[Bug middle-end/91920] ggc 9.2.0 failing openmp compile on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91920 --- Comment #13 from robert at robbieab dot com --- The patch appears to fix both my test-case, and the original problem in Darktable. Darktable is using a 3 member array which does get modified, initialized to -FLT_MAX and than used to store the max value for a set of RGB values. Thank you for fixing this.
[Bug fortran/91497] -Wconversion warns when doing explicit type conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497 --- Comment #19 from Manfred Schwarb --- Created attachment 46963 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46963&action=edit extended patch from comment #4 to also cover gfc_simplify_dble and gfc_simplify_sngl Note, I do not have neither commit rights nor assigment. Supresses all warnings of the test in comment #9 and regtests cleanly.
[Bug tree-optimization/88760] GCC unrolling is suboptimal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88760 --- Comment #25 from Richard Earnshaw --- Well very small loops should be unrolled more than slightly larger ones. So perhaps if the loop body is only 3 or 4 instructions it should be unrolled four times but above that perhaps only twice. Some consideration should be given, however, to whether the target micro-architecture has looping buffers as unrolling beyond the limit of such structures will hurt performance.
[Bug c++/91925] [9/10 Regression] -fpack-struct causes a decltype with template to ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91925 Marek Polacek changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2019-09-27 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |9.3 Summary|-fpack-struct causes a |[9/10 Regression] |decltype with template to |-fpack-struct causes a |ICE |decltype with template to ||ICE Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed on x86_64 too.
[Bug c++/91925] [9/10 Regression] -fpack-struct causes a decltype with template to ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91925 --- Comment #2 from Marek Polacek --- Started with r268075.
[Bug lto/70929] [7/8/9/10 regression] Cross-module inlining for functions having argument passed by reference is no longer working.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70929 Martin Jambor changed: What|Removed |Added CC||jamborm at gcc dot gnu.org --- Comment #12 from Martin Jambor --- (In reply to Jan Hubicka from comment #11) > Since we now stream parameter types into ipa-fnsummary, we should be able to > resolve this precisely? We stream types of formal parameters (so in WPA we know that the type of the formal parameter of t is a reference and not a struct) but we don't stream type of actual arguments unless they are a constant, so, at least if I understand the question correctly, we still cannot make the type comparison in the IPA decision stage.
[Bug c++/89239] gcc claims that this expression is not constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89239 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Jason Merrill --- Same issue as 71504. *** This bug has been marked as a duplicate of bug 71504 ***
[Bug c++/71504] bogus error: accessing value through a glvalue in a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71504 Jason Merrill changed: What|Removed |Added CC||n.eugene536 at gmail dot com --- Comment #7 from Jason Merrill --- *** Bug 89239 has been marked as a duplicate of this bug. ***
[Bug c++/71504] bogus error: accessing value through a glvalue in a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71504 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/91923] [9/10 Regression] Failure-to-SFINAE with class type NTTP in C++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91923 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
[Bug c++/79328] Wshadow and lambda captures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79328
Arnaud Desitter changed:
What|Removed |Added
CC||arnaud02 at users dot
sourceforge.
||net
--- Comment #3 from Arnaud Desitter ---
This defect makes -Wshadow=local difficult to use with immediately invoked
lambda expressions. For instance,
gcc 9.2 compiles:
#include
auto f(int s) {
const auto v = []{
std::array v = {1, 2};
return v;
}();
return v.size();
}
with:
source>: In lambda function:
:4:25: warning: declaration of 'v' shadows a previous local [-Wshadow]
4 | std::array v = {1, 2};
| ^
:3:14: note: shadowed declaration is here
3 | const auto v = []{
| ^
[Bug c++/88203] assert does not compile with OpenMP's pragma omp parallel for default(none)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88203 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #6 from Jakub Jelinek --- OpenMP 5.1 will have in the Certain variables and objects have predetermined data-sharing attributes as follows: list "The __func__ variable and similar function-local predefined variables are shared." and in the For these exceptions only, listing a predetermined variable in a data-sharing attribute clause is allowed and overrides the variable’s predetermined data-sharing attributes. list "The __func__ variable and similar function-local predefined variables may be listed in a shared or firstprivate clause." So, with __func__/__FUNCTION__/__PRETTY_FUNCTION__ may be explicitly specified in shared or firstprivate clause, but with default(none) doesn't have to be.
[Bug c++/88203] assert does not compile with OpenMP's pragma omp parallel for default(none)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88203 --- Comment #7 from Jakub Jelinek --- Created attachment 46964 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46964&action=edit gcc10-pr88203.patch Untested implementation of that.
[Bug target/91919] [10 Regression] arm-linux-eabi ICE with building kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91919 --- Comment #2 from Jakub Jelinek --- Author: jakub Date: Fri Sep 27 15:48:51 2019 New Revision: 276183 URL: https://gcc.gnu.org/viewcvs?rev=276183&root=gcc&view=rev Log: PR target/91919 * config/arm/arm.md (mlal): Remove SE wrappers around operands of SImode MULT. * gcc.c-torture/compile/pr91919.c: New.test Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr91919.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.md trunk/gcc/testsuite/ChangeLog
[Bug libquadmath/91924] tgammal(- odd.5 ) has wrong sign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91924 Joseph S. Myers changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Joseph S. Myers --- Fixed by the libquadmath update from glibc in GCC 9. *** This bug has been marked as a duplicate of bug 68686 ***
[Bug libquadmath/68686] tgammaq(x) is always negative for noninteger x < 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68686 Joseph S. Myers changed: What|Removed |Added CC||tydeman at tybor dot com --- Comment #7 from Joseph S. Myers --- *** Bug 91924 has been marked as a duplicate of this bug. ***
[Bug libstdc++/91910] Debug mode: there is a racing condition between destructors of iterator and the associated container.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91910 --- Comment #6 from Jonathan Wakely --- Author: redi Date: Fri Sep 27 16:20:40 2019 New Revision: 276184 URL: https://gcc.gnu.org/viewcvs?rev=276184&root=gcc&view=rev Log: PR libstdc++/91910 fix data race in Debug Mode destructors Fix data race when _Safe_iterator_base::_M_detach() runs concurrently with the _Safe_container_base destructor. PR libstdc++/91910 * src/c++11/debug.cc (_Safe_iterator_base::_M_detach()): Load pointer atomically and lock the mutex before accessing the sequence. (_Safe_local_iterator_base::_M_detach()): Likewise. (_Safe_iterator_base::_M_reset()): Clear _M_sequence atomically. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/src/c++11/debug.cc
[Bug libstdc++/91910] Debug mode: there is a racing condition between destructors of iterator and the associated container.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91910 --- Comment #7 from Jonathan Wakely --- Fixed on trunk only for now but I might backport it.
[Bug tree-optimization/80936] bcmp, bcopy, and bzero not declared nonnull
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80936 Martin Sebor changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org --- Comment #6 from Martin Sebor --- Testing a patch.
[Bug fortran/91926] New: assumed rank optional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91926 Bug ID: 91926 Summary: assumed rank optional Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at hotmail dot com Target Milestone: --- Created attachment 46965 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46965&action=edit C code Assumed rank optional generates segmentation fault. using: GNU Fortran (GCC) 9.1.0
[Bug fortran/91926] assumed rank optional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91926 --- Comment #1 from José Rui Faustino de Sousa --- Created attachment 46966 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46966&action=edit Fortran code
[Bug tree-optimization/88760] GCC unrolling is suboptimal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88760 --- Comment #26 from Segher Boessenkool --- Yeah, and it probably should be a param (that different targets can default differently, per CPU probably). On most Power CPUs all loops take a minimum number of cycles per iteration (say, three), but that translates to a lot of instructions (say, >10). Small loops should probably be unrolled at -O2 already as well. Maybe fixed length loops only?
[Bug ipa/89924] [missed-optimization] Function not de-virtualized within the same TU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89924 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #8 from Jason Merrill --- > (In reply to Jan Hubicka from comment #3) > > The reason why we do not devirtualize is that only information about Aint is > > the type of function parameter > > and we do not believe it implies the type of > > memory location it points to because there is no read or anything from that > > pointer before it is casted to struct A* and pointer of a given type does > > not need to necessarily point to memory location of the same type unless you > > dereference it. > > > > Is it really valid to devirtualize here? I think if the object were not an actual Aint, performing the standard conversion to A* should be undefined, allowing the devirtualization. But I'm not finding actual wording to that effect in the current draft.
[Bug c++/86173] Default construction of a union (in std::optional)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86173 --- Comment #5 from Marc Glisse --- A similar example was reported on https://stackoverflow.com/q/57964217/1918193
[Bug tree-optimization/80936] bcmp, bcopy, and bzero not declared nonnull
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80936 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #7 from Martin Sebor --- Patch: https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01620.html
[Bug c++/91369] Implement P0784R7: constexpr new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91369 Jakub Jelinek changed: What|Removed |Added Attachment #46956|0 |1 is obsolete|| --- Comment #9 from Jakub Jelinek --- Created attachment 46967 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46967&action=edit gcc10-pr91369.patch Updated patch.
[Bug ipa/89924] [missed-optimization] Function not de-virtualized within the same TU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89924 --- Comment #9 from Eyal Rozenberg --- (In reply to Jason Merrill from comment #8) > I think if the object were not an actual Aint, performing the standard > conversion to A* should be undefined, allowing the devirtualization. But > I'm not finding actual wording to that effect in the current draft. I'm not sure you _should_ find such language, because it's unnecessary. A function getting a T* is allowed to assume that the pointer is pointing to a valid T (and if I were a language lawyer I would tell you where that's stated). Implicitly, therefore,, a C++ program is not required to have any defined behavior when that T* does not point to a valid T.
[Bug middle-end/91920] ggc 9.2.0 failing openmp compile on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91920 --- Comment #14 from Jakub Jelinek --- Author: jakub Date: Fri Sep 27 20:13:00 2019 New Revision: 276211 URL: https://gcc.gnu.org/viewcvs?rev=276211&root=gcc&view=rev Log: PR middle-end/91920 * gimplify.c (omp_default_clause): Predetermine DECL_IN_CONSTANT_POOL variables as shared. * c-c++-common/gomp/pr91920.c: New test. Added: trunk/gcc/testsuite/c-c++-common/gomp/pr91920.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c trunk/gcc/testsuite/ChangeLog
[Bug c++/88203] assert does not compile with OpenMP's pragma omp parallel for default(none)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88203 --- Comment #8 from Jakub Jelinek --- Author: jakub Date: Fri Sep 27 20:14:24 2019 New Revision: 276212 URL: https://gcc.gnu.org/viewcvs?rev=276212&root=gcc&view=rev Log: PR c++/88203 c-family/ * c-common.h (c_omp_predefined_variable): Declare. * c-omp.c (c_omp_predefined_variable): New function. (c_omp_predetermined_sharing): Return OMP_CLAUSE_DEFAULT_SHARED for predefined variables. c/ * c-parser.c (c_parser_predefined_identifier): New function. (c_parser_postfix_expression): Use it. (c_parser_omp_variable_list): Parse predefined identifiers. * c-typeck.c (c_finish_omp_clauses): Allow predefined variables in shared and firstprivate clauses, even when they are predetermined shared. cp/ * parser.c (cp_parser_omp_var_list_no_open): Parse predefined variables. * semantics.c (finish_omp_clauses): Allow predefined variables in shared and firstprivate clauses, even when they are predetermined shared. * cp-gimplify.c (cxx_omp_predetermined_sharing_1): Return OMP_CLAUSE_DEFAULT_SHARED for predefined variables. testsuite/ * c-c++-common/gomp/pr88203-1.c: New test. * c-c++-common/gomp/pr88203-2.c: New test. * c-c++-common/gomp/pr88203-3.c: New test. Added: trunk/gcc/testsuite/c-c++-common/gomp/pr88203-1.c trunk/gcc/testsuite/c-c++-common/gomp/pr88203-2.c trunk/gcc/testsuite/c-c++-common/gomp/pr88203-3.c Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.h trunk/gcc/c-family/c-omp.c trunk/gcc/c/ChangeLog trunk/gcc/c/c-parser.c trunk/gcc/c/c-typeck.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-gimplify.c trunk/gcc/cp/parser.c trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog
[Bug target/91927] New: -mstrict-align doesn't prevent unaligned accesses at -O2 and -O3 on AARCH64 targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91927
Bug ID: 91927
Summary: -mstrict-align doesn't prevent unaligned accesses at
-O2 and -O3 on AARCH64 targets
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gr.audio at gmail dot com
Target Milestone: ---
Target: aarch64-elf
Hello,
I'm writing code for an AARCH64 target, and ran into the following issue.
First off, at the stage my code runs, the MMU is not enabled, so the CPU
doesn't allow unaligned accesses. I thus enabled the "-mstrict-align" option.
The GCC (8.3.0) binaries I'm using are from ARM:
https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-a/downloads
but I built GCC 9.2.0 for aarch64-elf and got the same issue.
I get an exception (unaligned access) when my code runs, and investigated. Here
is how it happens.
I'm accessing successively two successive uint32_t members of a packed struct:
eg:
---
typedef struct __attribute__((__packed__))
{
...
uint32_t nWidth;
uint32_t nHeight;
...
} MyStruct_t;
...
MyStruct_t sThisStruct;
...
// My code accesses them just like so:
... = sThisStruct.nWidth;
... = sThisStruct.nHeight;
---
At -O2 and -O3, despite the "-mstrict-align" option, GCC emits code that
creates an unaligned access:
ldr d0, [sp, 52]
(SP + 52 is 4-byte aligned obviously, but not 8-byte aligned, and thus, this
64-bit access yields an exception.)
GCC optimizes the two 32-bit accesses in one 64-bit access, but it shouldn't in
this case, with the "-mstrict-align" option.
At -O1 and below, GCC correctly emits:
ldr w0, [sp, 52]
...
ldr w0, [sp, 56]
instead, which are correctly aligned accesses.
This issue looks like a cousin to the following bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71727
It looks like the "-mstrict-align" option is not correctly enforced at certain
optimization levels, for different optimizations (but with the same overall
problem of potentially unaligned accesses).
---
GCC version:
Target: aarch64-elf
Configured with:
/tmp/dgboter/bbs/dsggnu-vm-1-x86_64--mingw32-i686/buildbot/mingw32-i686--aarch64-elf/build/src/gcc/configure
--target=aarch64-elf
--prefix=/tmp/dgboter/bbs/dsggnu-vm-1-x86_64--mingw32-i686/buildbot/mingw32-i686--aarch64-elf/build/bui
ld-mingw-aarch64-elf/install//
--with-gmp=/tmp/dgboter/bbs/dsggnu-vm-1-x86_64--mingw32-i686/buildbot/mingw32-i686--aarch64-el
f/build/build-mingw-aarch64-elf/host-tools
--with-mpfr=/tmp/dgboter/bbs/dsggnu-vm-1-x86_64--mingw32-i686/buildbot/mingw32-i68
6--aarch64-elf/build/build-mingw-aarch64-elf/host-tools
--with-mpc=/tmp/dgboter/bbs/dsggnu-vm-1-x86_64--mingw32-i686/buildbot
/mingw32-i686--aarch64-elf/build/build-mingw-aarch64-elf/host-tools
--with-isl=/tmp/dgboter/bbs/dsggnu-vm-1-x86_64--mingw32-i
686/buildbot/mingw32-i686--aarch64-elf/build/build-mingw-aarch64-elf/host-tools
--disable-shared --disable-nls --disable-thre
ads --disable-tls --enable-checking=release --enable-languages=c,c++,fortran
--with-newlib --with-libiconv-prefix=/tmp/dgbote
r/bbs/dsggnu-vm-1-x86_64--mingw32-i686/buildbot/mingw32-i686--aarch64-elf/build/build-mingw-aarch64-elf/host-tools
--host=i68
6-w64-mingw32 --with-pkgversion='GNU Toolchain for the A-profile Architecture
8.3-2019.03 (arm-rel-8.36)' --with-bugurl=https
://bugs.linaro.org/
Thread model: single
gcc version 8.3.0 (GNU Toolchain for the A-profile Architecture 8.3-2019.03
(arm-rel-8.36))
---
Also happens with aarch-64-elf-gcc 9.2.0 (custom built).
[Bug c++/71504] [C++11] constexpr fails with multidimensional arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71504 --- Comment #8 from Jason Merrill --- Created attachment 46968 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46968&action=edit partial fix This fixes handling of references to the first object, but not later ones, so several of the testcases in this PR still fail. Putting this aside for now.
[Bug c++/71504] [C++11] constexpr fails with multidimensional arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71504 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|jason at gcc dot gnu.org |unassigned at gcc dot gnu.org
[Bug c++/91925] [9/10 Regression] -fpack-struct causes a decltype with template to ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91925
--- Comment #3 from Marek Polacek ---
struct A {};
template T fn(T);
class B {
A a;
decltype(fn(a)) p;
};
[Bug c++/91925] [9/10 Regression] -fpack-struct causes a decltype with template to ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91925
--- Comment #4 from Marek Polacek ---
Also ICEs without the template:
struct A {};
int fn(A);
struct B {
A a;
decltype(fn(a)) p;
};
[Bug target/91927] -mstrict-align doesn't prevent unaligned accesses at -O2 and -O3 on AARCH64 targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91927 --- Comment #1 from Andrew Pinski --- Do you have a full testcase?
[Bug target/91927] -mstrict-align doesn't prevent unaligned accesses at -O2 and -O3 on AARCH64 targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91927 --- Comment #2 from Guillaume --- Thanks for your quick reply. Yes, I actually managed to write a minimal test case showing the problem (attached source file). Compiling it with: aarch64-elf-gcc -mcpu=cortex-a72 -march=armv8-a+crc -O3 -mstrict-align -S Unaligned_Access.c I get the following assembly code: TestCase: cbz x0, .L7 stp x29, x30, [sp, -48]! mov x29, sp str x19, [sp, 16] mov x19, x0 add x0, sp, 32 str xzr, [sp, 32] str wzr, [sp, 40] bl SetTag ldr d0, [sp, 36] str d0, [x19, 8] ldr x19, [sp, 16] ldp x29, x30, [sp], 48 ret As can be seen here, an "ldr d0, [sp, 36]" instruction is emitted, which is a 64-bit transfer on an address aligned to 4-byte, but not aligned to 8-byte (sp + 36). This particular test case doesn't seem to generate a problem with -O2, only with -O3, but my own code did. With -O2, it emits "ldp w1, w0, [sp, 36]" instead of " ldr d0, [sp, 36]", which I believe should be aligned? I didn't find how to show the same behavior with -O2 as happens with -O3, with a simple test case, so far, so you may add to the report that the problem with -O2 is unconfirmed. Thanks for your time, Le sam. 28 sept. 2019 à 00:53, pinskia at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> a écrit : > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91927 > > --- Comment #1 from Andrew Pinski --- > Do you have a full testcase? > > -- > You are receiving this mail because: > You reported the bug.
[Bug target/91927] -mstrict-align doesn't prevent unaligned accesses at -O2 and -O3 on AARCH64 targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91927 Andrew Pinski changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2019-09-28 Ever confirmed|0 |1 Known to fail||7.3.0 --- Comment #3 from Andrew Pinski --- Confirmed. The misalignment check does not take into account if the misalignment is known at compile time :).
[Bug target/91927] -mstrict-align doesn't prevent unaligned accesses at -O2 and -O3 on AARCH64 targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91927 --- Comment #4 from Guillaume --- Thanks :) Le sam. 28 sept. 2019 à 02:13, pinskia at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> a écrit : > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91927 > > Andrew Pinski changed: > >What|Removed |Added > > >Keywords||wrong-code > Status|UNCONFIRMED |NEW >Last reconfirmed||2019-09-28 > Ever confirmed|0 |1 > Known to fail||7.3.0 > > --- Comment #3 from Andrew Pinski --- > Confirmed. > The misalignment check does not take into account if the misalignment is > known > at compile time :). > > -- > You are receiving this mail because: > You reported the bug.
[Bug target/85978] config/frv/frv.c: 3 * iffy code in switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85978 Eric Gallager changed: What|Removed |Added CC||aoliva at gcc dot gnu.org, ||nickc at gcc dot gnu.org --- Comment #1 from Eric Gallager --- cc-ing frv maintainers
[Bug libgcc/70800] libgcc/config/libbid/bid_binarydecimal.c: suspicious comparison ? (missed -Wtautological-compare)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70800 --- Comment #5 from Eric Gallager --- (In reply to David Binderman from comment #0) > trunk/libgcc/config/libbid/bid_binarydecimal.c:143934]: (style) Expression > '(X & 0x) > 0xf423f' is always false. > > Source code is > > nan(s,x) & 0xul) > 99ul) ? 0 : \ >(((unsigned long long) x) << 44)),0ull); > I can't seem to find this code in the mentioned source file any longer, so I guess that part is fixed; keeping bug open for the enhancement to -Wtautological-compare
[Bug target/66469] config/rl78/rl78.c:679: possible bad array index ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66469 --- Comment #1 from Eric Gallager --- I can't seem to find the mentioned code in the source file any longer...
[Bug target/69286] trunk/libgcc/config/s390/tpf-unwind.h: 28 redundant condition ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69286 Eric Gallager changed: What|Removed |Added CC||uweigand at gcc dot gnu.org --- Comment #1 from Eric Gallager --- svn blame says Ulrich Weigand did this code; cc-ing him
[Bug other/71324] liboffloadmic/runtime/offload_env.cpp:316]: (style) Redundant condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71324 Eric Gallager changed: What|Removed |Added CC||kyukhin at gcc dot gnu.org --- Comment #1 from Eric Gallager --- svn blame says Kirill Yukhin wrote this code; cc-ing him
[Bug other/71327] libiberty/cplus-dem.c:2702]: (style) Redundant condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71327 --- Comment #1 from Eric Gallager --- (In reply to David Binderman from comment #0) > libiberty/cplus-dem.c:2702]: (style) Redundant condition: If 'EXPR == '_'', > the comparison 'EXPR' is always true. > > Source code is > > while (*scan && *scan == '_') > > Suggest new code > > while (*scan == '_') I can't seem to find the mentioned code in the original source file any longer...
[Bug libstdc++/77936] libstdc++-v3/include/parallel/checkers.h:66: pointless local variable ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77936 Eric Gallager changed: What|Removed |Added CC||singler at gcc dot gnu.org Summary|include/parallel/checkers.h |libstdc++-v3/include/parall |:66: pointless local|el/checkers.h:66: pointless |variable ? |local variable ? --- Comment #1 from Eric Gallager --- svn blame says the author of this code is "singler" (not sure who that is), so cc-ing them
[Bug testsuite/91676] new test case gcc.dg/torture/pr91656-1.c in r275406 fails on powerpc64 BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91676 Alan Modra changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com --- Comment #2 from Alan Modra --- Created attachment 46970 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46970&action=edit fix currently under test
[Bug target/80672] gcc/config/sh/sh.c:716: prefer compare to find.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80672 Eric Gallager changed: What|Removed |Added CC||olegendo at gcc dot gnu.org --- Comment #2 from Eric Gallager --- svn blame says Oleg Endo wrote this code; cc-ing him
[Bug libstdc++/69285] libstdc++-v3/include/parallel/partition.h: 2 * array index check after use ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69285 Eric Gallager changed: What|Removed |Added CC||paolo at gcc dot gnu.org --- Comment #2 from Eric Gallager --- svn blame says the author of this code is "Paolo" (not sure if that's Bonzini or Carlini), cc-ing whichever of them got the "paolo at gcc dot gnu dot org" email address
[Bug target/59205] config/iq2000/iq2000.c:2188: possible cut'n'paste error ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59205 Eric Gallager changed: What|Removed |Added CC||nickc at gcc dot gnu.org --- Comment #1 from Eric Gallager --- cc-ing iq2000 maintainer
[Bug target/52124] config/cr16/cr16.c: possibly redundant code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52124 Eric Gallager changed: What|Removed |Added CC||jayants at gcc dot gnu.org --- Comment #1 from Eric Gallager --- svn blame says "jayants" wrote that code, so cc-ing them
[Bug target/50355] Comparison is always true in alpha config code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50355 --- Comment #1 from Eric Gallager --- I can't seem to find the code in question in the source file any longer...
[Bug target/71175] trunk/gcc/config/arm/arm.c: 2 * minor printf problems ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71175 --- Comment #2 from Eric Gallager --- svn blame says many people were involved in this code; not sure which of them to cc...
[Bug middle-end/81669] trunk/gcc/fibonacci_heap.h:58: possible missing initialisation ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81669 Eric Gallager changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #3 from Eric Gallager --- svn blame says Martin Liska wrote this code; cc-ing him
[Bug c/71176] trunk/fixincludes/fixincl.c:162: bad % specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71176 Eric Gallager changed: What|Removed |Added CC||bonzini at gnu dot org --- Comment #6 from Eric Gallager --- svn blame says Paolo Bonzini wrote this code; cc-ing him
[Bug middle-end/54582] gap in FORTIFY checking of buffer lengths
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54582 Eric Gallager changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #17 from Eric Gallager --- Martin Sebor might be interested in this
[Bug other/82648] libiberty/regex.c:2364]: pointless test ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82648 Eric Gallager changed: What|Removed |Added CC||dj at gcc dot gnu.org --- Comment #3 from Eric Gallager --- svn blame says "dj" authored this code; cc-ing him
[Bug c/66249] -Wformat-signedness should not warn on enums
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66249 --- Comment #2 from Eric Gallager --- (In reply to Marek Polacek from comment #1) > -Wformat-signedness has many issues (which was the reason it's been pulled > out of -Wformat=2). Maybe it's time for a -Wformat=3?
[Bug rtl-optimization/82338] valgrind error in inherit_in_ebb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82338 Eric Gallager changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #6 from Eric Gallager --- (In reply to Eric Gallager from comment #5) > (In reply to Eric Gallager from comment #4) > > (In reply to Vladimir Makarov from comment #3) > > > Author: vmakarov > > > Date: Fri Sep 29 17:15:24 2017 > > > New Revision: 253299 > > > > > > URL: https://gcc.gnu.org/viewcvs?rev=253299&root=gcc&view=rev > > > Log: > > > 2017-09-29 Vladimir Makarov > > > > > > PR rtl-optimization/82338 > > > * lra-constraints.c (inherit_in_ebb): Check usage_insns check. > > > > > > > > > Modified: > > > trunk/gcc/ChangeLog > > > trunk/gcc/lra-constraints.c > > > > Did this fix it? > > WAITING on a reply Assuming this has been fixed.
