[Bug middle-end/69547] [6 regression] no-op array initializer emits an empty loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69547 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #4 from Richard Biener --- Hmm, so we have : # _1 = PHI <&a(2), _9(4)> # _2 = PHI <63(2), _10(4)> if (_2 == -1) goto ; else goto ; : MEM[(struct &)_1] ={v} {CLOBBER}; _9 = _1 + 1; _10 = _2 + -1; goto ; in CDDCE and do processing: foo (&a, 64); marking necessary through .MEM_15 stmt MEM[(struct &)_1] ={v} {CLOBBER}; processing: MEM[(struct &)_1] ={v} {CLOBBER}; I'm trying a patch to fix that.
[Bug middle-end/69546] [5/6 Regression] wrong code with -O and simple int128 arithmetics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69546 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug fortran/69544] [5/6 Regression] Internal compiler error with -Wall and where
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69544 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |5.4
[Bug preprocessor/69543] [6 Regression] _Pragma does not apply within macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69543 Richard Biener changed: What|Removed |Added Target Milestone|--- |6.0
[Bug middle-end/69537] [6 Regression] Incorrect -Wmaybe-uninitialized warning with enum variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69537 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Richard Biener --- Fixed.
[Bug middle-end/69537] [6 Regression] Incorrect -Wmaybe-uninitialized warning with enum variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69537 --- Comment #7 from Richard Biener --- Author: rguenth Date: Fri Jan 29 08:36:04 2016 New Revision: 232968 URL: https://gcc.gnu.org/viewcvs?rev=232968&root=gcc&view=rev Log: 2016-01-29 Richard Biener PR middle-end/69537 * match.pd: Allow all integral types when simplifying a widening or sign-changing conversion. * gcc.dg/uninit-21.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/uninit-21.c Modified: trunk/gcc/ChangeLog trunk/gcc/match.pd trunk/gcc/testsuite/ChangeLog
[Bug middle-end/69547] [6 regression] no-op array initializer emits an empty loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69547 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Started with r222135.
[Bug c++/69516] [5/6 regression] infinite recursion on a VLA with excess initializer elements in constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69516 --- Comment #3 from Marek Polacek --- Author: mpolacek Date: Fri Jan 29 09:25:14 2016 New Revision: 232969 URL: https://gcc.gnu.org/viewcvs?rev=232969&root=gcc&view=rev Log: PR c++/69509 PR c++/69516 * constexpr.c (cxx_eval_array_reference): Give the "array subscript out of bound" error earlier. * init.c (build_vec_init): Change NE_EXPR into GT_EXPR. Update the commentary. * g++.dg/ext/constexpr-vla2.C: New test. * g++.dg/ext/constexpr-vla3.C: New test. * g++.dg/ubsan/vla-1.C: Remove dg-shouldfail. Added: trunk/gcc/testsuite/g++.dg/ext/constexpr-vla2.C trunk/gcc/testsuite/g++.dg/ext/constexpr-vla3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/constexpr.c trunk/gcc/cp/init.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/ubsan/vla-1.C
[Bug c++/69509] [5/6 regression] infinite loop compiling a VLA in a recursive constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69509 --- Comment #4 from Marek Polacek --- Author: mpolacek Date: Fri Jan 29 09:25:14 2016 New Revision: 232969 URL: https://gcc.gnu.org/viewcvs?rev=232969&root=gcc&view=rev Log: PR c++/69509 PR c++/69516 * constexpr.c (cxx_eval_array_reference): Give the "array subscript out of bound" error earlier. * init.c (build_vec_init): Change NE_EXPR into GT_EXPR. Update the commentary. * g++.dg/ext/constexpr-vla2.C: New test. * g++.dg/ext/constexpr-vla3.C: New test. * g++.dg/ubsan/vla-1.C: Remove dg-shouldfail. Added: trunk/gcc/testsuite/g++.dg/ext/constexpr-vla2.C trunk/gcc/testsuite/g++.dg/ext/constexpr-vla3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/constexpr.c trunk/gcc/cp/init.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/ubsan/vla-1.C
[Bug target/69538] gcc.dg/torture/stackalign/builtin-apply-4.c fails with flto for aarch32 targets with single precision FPU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69538 --- Comment #3 from ktkachov at gcc dot gnu.org --- I suspect the place to start at is looking what arm_function_value does for the lto case. This is where the code decides what register the function returns its value based on ABI. But I'm having a tough time getting gdb to attach properly to debug the final LTO combination :(
[Bug c++/69516] [5/6 regression] infinite recursion on a VLA with excess initializer elements in constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69516 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Marek Polacek --- Fixed for GCC 6.
[Bug c++/69509] [5/6 regression] infinite loop compiling a VLA in a recursive constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69509 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Marek Polacek --- Fixed for GCC 6.
[Bug target/69459] [5 Regression] wrong code with -O2 and vector arithmetics @ x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69459 Jakub Jelinek changed: What|Removed |Added Summary|[5/6 Regression] wrong code |[5 Regression] wrong code |with -O2 and vector |with -O2 and vector |arithmetics @ x86_64|arithmetics @ x86_64 --- Comment #13 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug c++/69517] [5/6 regression] SEGV on a VLA with excess initializer elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69517 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-01-29 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #6 from Marek Polacek --- Martin is planning some changes, thus confirmed.
[Bug target/69538] gcc.dg/torture/stackalign/builtin-apply-4.c fails with flto for aarch32 targets with single precision FPU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69538 --- Comment #4 from ktkachov at gcc dot gnu.org --- So during LTO compilation inside aapcs_allocate_return_reg the pcs_variant used is ARM_PCS_AAPCS_LOCAL (/* Private call within this compilation unit. */) whereas for non-LTO it is: ARM_PCS_AAPCS_VFP (/* Use VFP registers for floating point values. */)
[Bug c++/69462] FLT_EVAL_METHOD and DECIMAL_DIG missing in float.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69462 --- Comment #6 from Andreas Krebbel --- Author: krebbel Date: Fri Jan 29 10:03:26 2016 New Revision: 232970 URL: https://gcc.gnu.org/viewcvs?rev=232970&root=gcc&view=rev Log: PR c++/69462: Provide FLT_EVAL_METHOD and DECIMAL_DIG in float.h. gcc/ChangeLog PR c++/69462 * ginclude/float.h: Also provide FLT_EVAL_METHOD and DECIMAL_DIG for C++-11. Modified: trunk/gcc/ChangeLog trunk/gcc/ginclude/float.h
[Bug other/69006] [6 Regression] Extraneous newline emitted between error messages in GCC 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69006 --- Comment #5 from Andreas Krebbel --- Author: krebbel Date: Fri Jan 29 10:12:11 2016 New Revision: 232972 URL: https://gcc.gnu.org/viewcvs?rev=232972&root=gcc&view=rev Log: PR other/69006: S/390: Fix extra newlines after diagnostics. gcc/ChangeLog PR other/69006 * config/s390/s390-c.c (s390_resolve_overloaded_builtin): Remove trailing blank line from error message. Modified: trunk/gcc/ChangeLog trunk/gcc/config/s390/s390-c.c
[Bug target/69533] [6 Regression] python miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69533 --- Comment #2 from Jeffrey A. Law --- Quick update. It appears that we've got something like this t = b * c; r = b / c; if (r != b) Which python is using as an overflow check. We now know how to optimize the mul/div sequence, which in turn causes the IF statement to have a known value. Ultimately we end up removing the overflow check, which appears to make the python testsuite unhappy.
[Bug c++/69550] New: Need a way to disable "flexible array member in an otherwise empty struct" error on GCC 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69550 Bug ID: 69550 Summary: Need a way to disable "flexible array member in an otherwise empty struct" error on GCC 6 Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: nalimilan at club dot fr Target Milestone: --- Created attachment 37514 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37514&action=edit Test C++ program which compiles with GCC 5 but not with GCC 6 GCC 6 has become stricter than GCC 5 as regards having two flexible array members in a struct with no other fields. In GCC 5, the attached test program used to compile fine. It only triggered a warning with -Wpedantic. In GCC 6, it triggers an error with all -std modes. While this is arguably against the standard, the fact that this code was accepted before and not in GCC 6 is a problem when the public API of a library includes such a construct: the library cannot be built with GCC 6 without breaking the API. This is the case for Julia [1]. Would it be possible to provide a way to turn the error into a warning? For example, -std=gnu++11 could allow this, while -std=c++11 would still consider it as an error. 1: https://github.com/JuliaLang/julia/pull/14829
[Bug c++/65143] [C++11] missing devirtualization for virtual base in "final" classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65143 Jonathan Wakely changed: What|Removed |Added Version|5.3.0 |4.9.2 Severity|major |enhancement --- Comment #8 from Jonathan Wakely --- (In reply to Paolo Carlini from comment #7) > I'm not sure the two bugs are exactly equivalent. Anyway, when working on > these optimization issues, let' remember c++/63164 too. They're not the same at all, one involves virtual bases and one involves devirtualising calls to virtual functions in (non-virtual) bases. PR 67184 is the same as my PR 69445 though.
[Bug bootstrap/69506] [6 Regression] check-in 232454 seems to cause problems with cygwin builds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69506 --- Comment #5 from Jonathan Wakely --- Author: redi Date: Fri Jan 29 10:52:08 2016 New Revision: 232974 URL: https://gcc.gnu.org/viewcvs?rev=232974&root=gcc&view=rev Log: Fix Cygwin bootstrap error due to TM symbols PR libstdc++/69506 * config/os/newlib/os_defines.h (_GLIBCXX_USE_WEAK_REF): Define. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/config/os/newlib/os_defines.h
[Bug c++/69550] Need a way to disable "flexible array member in an otherwise empty struct" error on GCC 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69550 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org, ||msebor at gcc dot gnu.org --- Comment #1 from Marek Polacek --- CCing Martin.
[Bug c++/67184] Missed optimization with C++11 final specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67184 Jonathan Wakely changed: What|Removed |Added Status|RESOLVED|NEW Last reconfirmed|2015-08-11 00:00:00 |2016-1-29 Resolution|DUPLICATE |--- --- Comment #4 from Jonathan Wakely --- Not a dup, this is a different case.
[Bug tree-optimization/69445] Fail to devirtualize call to base class function even though derived class type is 'final'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69445 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Jonathan Wakely --- dup *** This bug has been marked as a duplicate of bug 67184 ***
[Bug c++/67184] Missed optimization with C++11 final specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67184 Jonathan Wakely changed: What|Removed |Added CC||redi at gcc dot gnu.org --- Comment #5 from Jonathan Wakely --- *** Bug 69445 has been marked as a duplicate of this bug. ***
[Bug c++/69550] Need a way to disable "flexible array member in an otherwise empty struct" error on GCC 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69550 --- Comment #2 from Jonathan Wakely --- The code is nonsense, what's it even supposed to do? It would be invalid in C (where flexible arrays are actually standard) because flexible arrays can only be the last member, *and* because apart from the flexible arrays it's an otherwise empty struct. It's useless, and only compiled by accident. Allowing it with -fpermissive might make sense though, as that flag allows all kinds of terrible rubbish to compile.
[Bug c++/69550] Need a way to disable "flexible array member in an otherwise empty struct" error on GCC 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69550 --- Comment #3 from Jonathan Wakely --- (In reply to Milan Bouchet-Valat from comment #0) > Would it be possible to provide a way to turn the error into a warning? For > example, -std=gnu++11 could allow this, while -std=c++11 would still > consider it as an error. There is no reason to sanction this as a supported GNU extension. If it's allowed it should only be via -fpermissive which means "yes I know my code is rubbish but I can't fix it".
[Bug fortran/67451] [5/6 Regression] ICE with sourced allocation from coarray.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67451 vehre at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |vehre at gcc dot gnu.org
[Bug fortran/69418] [5/6 Regression] ICE: tree check: expected record_type ... in gfc_class_vptr_get, at fortran/trans-expr.c:149
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69418 vehre at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |vehre at gcc dot gnu.org
[Bug middle-end/69546] [5/6 Regression] wrong code with -O and simple int128 arithmetics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69546 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Created attachment 37515 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37515&action=edit gcc6-pr69546.patch Untested fix.
[Bug debug/66869] [6 regression] -Wunused-function no longer warns for static declarations without definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66869 --- Comment #8 from Jakub Jelinek --- Author: jakub Date: Fri Jan 29 11:14:42 2016 New Revision: 232975 URL: https://gcc.gnu.org/viewcvs?rev=232975&root=gcc&view=rev Log: PR debug/66869 * decl.c (wrapup_globals_for_namespace): Warn about unused static function declarations. * g++.dg/warn/Wunused-function2.C: New test. Added: trunk/gcc/testsuite/g++.dg/warn/Wunused-function2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog
[Bug debug/66869] [6 regression] -Wunused-function no longer warns for static declarations without definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66869 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Jakub Jelinek --- Fixed.
[Bug middle-end/69547] [6 regression] no-op array initializer emits an empty loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69547 --- Comment #6 from Richard Biener --- Author: rguenth Date: Fri Jan 29 11:21:19 2016 New Revision: 232976 URL: https://gcc.gnu.org/viewcvs?rev=232976&root=gcc&view=rev Log: 2016-01-29 Richard Biener PR tree-optimization/69547 * tree-ssa-dce.c (mark_aliased_reaching_defs_necessary_1): Do not mark clobbers necessary. (mark_all_reaching_defs_necessary_1): Likewise. * g++.dg/tree-ssa/pr69547.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/tree-ssa/pr69547.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-dce.c
[Bug fortran/69495] unused-label warning does not tell which flag triggered it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69495 --- Comment #8 from janus at gcc dot gnu.org --- (In reply to Manuel López-Ibáñez from comment #2) > Im sure there are more... One more case that I just ran across by coincidence (from resolve.c): if (warn_compare_reals) { gfc_intrinsic_op op = e->value.op.op; /* Type conversion has made sure that the types of op1 and op2 agree, so it is only necessary to check the first one. */ if ((op1->ts.type == BT_REAL || op1->ts.type == BT_COMPLEX) && (op == INTRINSIC_EQ || op == INTRINSIC_EQ_OS || op == INTRINSIC_NE || op == INTRINSIC_NE_OS)) { const char *msg; if (op == INTRINSIC_EQ || op == INTRINSIC_EQ_OS) msg = "Equality comparison for %s at %L"; else msg = "Inequality comparison for %s at %L"; gfc_warning (0, msg, gfc_typename (&op1->ts), &op1->where); } }
[Bug middle-end/69551] New: Wrong code with single element vector insert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69551 Bug ID: 69551 Summary: Wrong code with single element vector insert Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: ubizjak at gmail dot com Target Milestone: --- Target: x86 Following testcase aborts when compiled with "-O2 -msse -mno-sse2": --cut here-- typedef unsigned char v16qi __attribute__ ((vector_size (16))); typedef unsigned int v4si __attribute__ ((vector_size (16))); char __attribute__((noinline, noclone)) test (v4si vec) { vec[1] = 0x5fb856; return ((v16qi) vec)[0]; } int main () { char z = test ( (v4si) {-1, -1, -1, -1} ); if (z != -1) __builtin_abort (); return 0; } --cut here-- $ ~/gcc-build/gcc/xgcc -B ~/gcc-build/gcc/ -O2 -msse -mno-sse2 -m32 tt.c $ ./a.out Aborted The test function expands to following RTL: 1: NOTE_INSN_DELETED 4: NOTE_INSN_BASIC_BLOCK 2 2: r91:V4SI=xmm0:V4SI 3: NOTE_INSN_FUNCTION_BEG 6: r92:SI=0x5fb856 7: r94:V4SF=r93:V4SF 8: r93:V4SF=vec_select(vec_concat(r93:V4SF,r93:V4SF),parallel) 9: r93:V4SF=vec_merge(vec_duplicate(r92:SI#0),r93:V4SF,0x1) 10: r93:V4SF=vec_select(vec_concat(r93:V4SF,r94:V4SF),parallel) 11: r91:V4SI=r93:V4SF#0 12: r96:SI#0=vec_select(r91:V4SI#0,parallel) 13: r90:QI=r96:SI#0 17: ax:QI=r90:QI 18: use ax:QI which is already wrong. r91, used to pass argument is not used anywhere.
[Bug middle-end/69547] [6 regression] no-op array initializer emits an empty loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69547 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Richard Biener --- Fixed. Made me notice we only remove empty loops at -O2. Sth to think about for GCC7.
[Bug middle-end/69551] Wrong code with single element vector insert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69551 Richard Biener changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2016-01-29 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed. And note how r93 is used uninitialized.
[Bug fortran/69524] [6 Regression] [F08] Compiler segfaults on "module procedure"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69524 --- Comment #8 from Paul Thomas --- (In reply to Paul Thomas from comment #7) > I could be wrong but I do not agree that this is valid code. I will turn to > it tomorrow. I believe that a MODULE SUBROUTINE/FUNCTION declaration cannot > appear in the contained part of a module. It seems that I was wrong. From the Fortran 2008 standard: C1247 (R1225) MODULE shall appear only in the function-stmt or subroutine-stmt of a module subprogram or of a nonabstract interface body that is declared in the scoping unit of a module or submodule. Modifying the gcc_assert (trans-decl.c:2065) that causes the ICE to bool module_procedure; module_procedure = sym->attr.module_procedure && sym->ns && sym->ns->proc_name && sym->ns->proc_name->attr.flavor == FL_MODULE; gcc_assert (!sym->attr.external || module_procedure); Gives what seems to be the correct behaviour and allows: module A interface module subroutine A1(i) integer i end subroutine A1 module subroutine B1(i) integer i end subroutine B1 end interface contains module subroutine A1(i) integer i print *, 'A::A1(): i == ', i end subroutine A1 end module A submodule (A) a_son contains module procedure b1 print *, 'A_SON::B1(): Calling A1' call a1(i) end procedure end submodule use A call b1 (42) end to do the right thing. I cannot remember at all where module procedures pick up the external attribute. It would be better to modify this at source rather than the fix above :-) Paul
[Bug target/69533] [6 Regression] python miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69533 --- Comment #3 from Richard Biener --- Ok, makes sense if b and c are signed and thus overflow is undefined. Where's that code in python?
[Bug target/69551] Wrong code with single element vector insert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69551 Richard Biener changed: What|Removed |Added Component|middle-end |target --- Comment #2 from Richard Biener --- So we go the store_field path in expand_assignment with to_rtx being a V4SI reg which ends up using the vec_set_optab producing this code: /* Use vec_set patterns for inserting parts of vectors whenever available. */ if (VECTOR_MODE_P (GET_MODE (op0)) && !MEM_P (op0) && optab_handler (vec_set_optab, GET_MODE (op0)) != CODE_FOR_nothing && fieldmode == GET_MODE_INNER (GET_MODE (op0)) && bitsize == GET_MODE_UNIT_BITSIZE (GET_MODE (op0)) && !(bitnum % GET_MODE_UNIT_BITSIZE (GET_MODE (op0 { struct expand_operand ops[3]; machine_mode outermode = GET_MODE (op0); machine_mode innermode = GET_MODE_INNER (outermode); enum insn_code icode = optab_handler (vec_set_optab, outermode); int pos = bitnum / GET_MODE_BITSIZE (innermode); create_fixed_operand (&ops[0], op0); create_input_operand (&ops[1], value, innermode); create_integer_operand (&ops[2], pos); if (maybe_expand_insn (icode, 3, ops)) return true;
[Bug target/69548] libatomic fails to build with -Os on powerpc64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69548 --- Comment #1 from Alan Modra --- Created attachment 37516 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37516&action=edit possible fix This fixes the testcase on gcc-5. I haven't yet bootstrapped it, or investigated why the problem doesn't seem to occur on master.
[Bug target/69551] Wrong code with single element vector insert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69551 --- Comment #3 from Richard Biener --- if (SSE2) else /* For SSE1, we have to reuse the V4SF code. */ rtx t = gen_reg_rtx (V4SFmode); ix86_expand_vector_set (false, t, gen_lowpart (SFmode, val), elt); emit_move_insn (target, gen_lowpart (mode, t)); somehow ends up recursing in a weird way, using the new reg t but nowhere using 'target' apart from overwriting it in the end
[Bug c++/69550] Need a way to disable "flexible array member in an otherwise empty struct" error on GCC 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69550 --- Comment #4 from Milan Bouchet-Valat --- Yes, -fpermissive is a better solution. The code at stake has been replaced in the master branch, but breaking API in stable releases isn't great.
[Bug target/69551] [4.9/5/6 Regression] Wrong code with single element vector insert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69551 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Target Milestone|--- |4.9.4 Summary|Wrong code with single |[4.9/5/6 Regression] Wrong |element vector insert |code with single element ||vector insert --- Comment #4 from Jakub Jelinek --- Started with r206420. Works with gcc 4.8.
[Bug target/67839] Bit addressable instructions generated for invalid memory address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67839 --- Comment #5 from Senthil Kumar Selvaraj --- The patch did not make it to the 5 branch, my fault really - guess I forgot to submit it for backporting. Not sure how you get that code though - I pulled the latest gcc-5_branch (svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-5-branch@232962), built it with main.c from PR 69330, and this is what I got cbi 0x20,0 ldi r24,0 ldi r25,0 ret .size main, .-main .ident "GCC: (GNU) 5.3.1 20160129" The problem shows up only when define_special_predicate is used - 4.9 and below only used define_predicate. Like I said in the first comment, I don't know wny that was changed. The change of constraint from n to i, IIRC, was to defer address computation for IO instructions to link time, so that that io and io_low attributes work (https://gcc.gnu.org/onlinedocs/gcc/AVR-Variable-Attributes.html)
[Bug driver/69552] New: flto save-temps overwrites file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69552 Bug ID: 69552 Summary: flto save-temps overwrites file Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org Target Milestone: --- Say we use save-temps with flto in it's simplest form: ... $ gcc -O2 -flto banana.c orange.c lemon.c -O2 -fno-use-linker-plugin -flto-partition=none -save-temps ... After compilation we have: ... $ ls -1 | egrep -v '\.(c|i)$' a.out banana.o banana.s lemon.o lemon.s orange.o orange.s ... Both lemon.s and orange.s contain gimple and assembly from the initial cc1 invocation. But banana.s contains only assembly, and contains at the beginning '.file ""'. It contains the output of lto1. When adding -c, we see the original contents of banana.s from cc1: gimple and assembly, starting with '.file "banana.c"'. So, we appear to be using the file banana.s twice in the compilation process. Confirmed by grepping: ... $ gcc -O2 -flto banana.c orange.c lemon.c -O2 -fno-use-linker-plugin -flto-partition=none -save-temps -v 2>&1 | grep '\-o banana.s' libexec/gcc/x86_64-pc-linux-gnu/6.0.0/cc1 -fpreprocessed banana.i -quiet -dumpbase banana.c -mtune=generic -march=x86-64 -auxbase banana -O2 -O2 -version -flto -fno-use-linker-plugin -flto-partition=none -o banana.s libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto1 -quiet -dumpbase banana.o -mtune=generic -march=x86-64 -mtune=generic -march=x86-64 -auxbase-strip /tmp/ccbAWzhX.lto.o -O2 -O2 -O2 -O2 -version -fmath-errno -fsigned-zeros -ftrapping-math -fno-trapv -fno-openmp -fno-openacc -fno-use-linker-plugin -flto-partition=none @/tmp/cctx7jrX -o banana.s ...
[Bug target/69551] [4.9/5/6 Regression] Wrong code with single element vector insert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69551 --- Comment #5 from Jakub Jelinek --- So --- gcc/config/i386/i386.c.jj 2016-01-28 15:07:25.0 +0100 +++ gcc/config/i386/i386.c 2016-01-29 13:02:32.100788474 +0100 @@ -46744,6 +46744,7 @@ ix86_expand_vector_set (bool mmx_ok, rtx { /* For SSE1, we have to reuse the V4SF code. */ rtx t = gen_reg_rtx (V4SFmode); + emit_move_insn (t, gen_lowpart (V4SFmode, target)); ix86_expand_vector_set (false, t, gen_lowpart (SFmode, val), elt); emit_move_insn (target, gen_lowpart (mode, t)); } ?
[Bug target/69533] [6 Regression] python miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69533 --- Comment #4 from Jeffrey A. Law --- I believe it's in replace_substring.
[Bug target/69551] [4.9/5/6 Regression] Wrong code with single element vector insert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69551 --- Comment #6 from Uroš Bizjak --- (In reply to Jakub Jelinek from comment #5) > So > --- gcc/config/i386/i386.c.jj 2016-01-28 15:07:25.0 +0100 > +++ gcc/config/i386/i386.c2016-01-29 13:02:32.100788474 +0100 > @@ -46744,6 +46744,7 @@ ix86_expand_vector_set (bool mmx_ok, rtx > { > /* For SSE1, we have to reuse the V4SF code. */ > rtx t = gen_reg_rtx (V4SFmode); > + emit_move_insn (t, gen_lowpart (V4SFmode, target)); > ix86_expand_vector_set (false, t, gen_lowpart (SFmode, val), elt); > emit_move_insn (target, gen_lowpart (mode, t)); > } > ? Yep. Pre-approved everywhere, if you want to continue with the patch.
[Bug target/69551] [4.9/5/6 Regression] Wrong code with single element vector insert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69551 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- Created attachment 37517 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37517&action=edit gcc6-pr69551.patch Patch I'm going to bootstrap/regtest momentarily.
[Bug driver/69552] flto save-temps overwrites file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69552 --- Comment #1 from Richard Biener --- Yes, there's no linker output so we use whatever else. We could try falling back to a.out. Similarly without LTO -save-temps overwrites files if you do gcc t.c t.C both assembly and linker files will be t.s/t.o and the link will even fail. t.c --- int main() { foo();} t.C --- extern "C" int foo () {} so hardly a new issue with -save-temps - you need to know what you are doing.
[Bug c++/69550] Need a way to disable "flexible array member in an otherwise empty struct" error on GCC 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69550 --- Comment #5 from Milan Bouchet-Valat --- Note this actually also happens with the C compiler (the attached example also illustrates this).
[Bug c++/69550] Need a way to disable "flexible array member in an otherwise empty struct" error on GCC 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69550 --- Comment #6 from Marek Polacek --- (In reply to Milan Bouchet-Valat from comment #5) > Note this actually also happens with the C compiler (the attached example > also illustrates this). That's the correct behavior.
[Bug debug/69518] [6 Regression] Flag -g causes "error: type variant has different TYPE_VFIELD"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69518 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Created attachment 37518 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37518&action=edit gcc6-pr69518.patch Untested fix. The problem is that when type variants are created, the generic code copies there also the TYPE_VFIELD aka C_TYPE_INCOMPLETE_VARS. We clear it only in the main type variant, but not in other variants, so if not anything else, it is at least undesirable for GC purposes, plus we leak the C FE use of that field into the middle-end.
[Bug target/69533] [6 Regression] python miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69533 --- Comment #5 from Richard Biener --- Created attachment 37519 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37519&action=edit patch to fix it in two places Uh, indeed. Looks like those kind of broken overflow checks are everywhere (well, the one we optimize only in two places).
[Bug c++/69550] Need a way to disable "flexible array member in an otherwise empty struct" error on GCC 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69550 --- Comment #7 from H.J. Lu --- Also see PR 60336 for impact of empty class.
[Bug c++/69550] Need a way to disable "flexible array member in an otherwise empty struct" error on GCC 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69550 --- Comment #8 from Milan Bouchet-Valat --- (In reply to Marek Polacek from comment #6) > (In reply to Milan Bouchet-Valat from comment #5) > > Note this actually also happens with the C compiler (the attached example > > also illustrates this). > > That's the correct behavior. As I said, I don't deny it's the correct application of the standard, nor that it's a sane behavior. But the fact that this was accepted without even a warning by default in the last GCC release, and that no way to disable the error is offered in GCC 6 creates problems for existing code bases.
[Bug c++/69550] Need a way to disable "flexible array member in an otherwise empty struct" error on GCC 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69550 --- Comment #9 from Marek Polacek --- (In reply to Milan Bouchet-Valat from comment #8) > As I said, I don't deny it's the correct application of the standard, nor > that it's a sane behavior. But the fact that this was accepted without even > a warning by default in the last GCC release, and that no way to disable the > error is offered in GCC 6 creates problems for existing code bases. Note that this was only accepted by the C++ compiler; the C compiler always rejected such a code (going back to at least gcc 3.4).
[Bug c++/69550] Need a way to disable "flexible array member in an otherwise empty struct" error on GCC 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69550 --- Comment #10 from Jonathan Wakely --- (In reply to Milan Bouchet-Valat from comment #5) > Note this actually also happens with the C compiler (the attached example > also illustrates this). Which is a Good Thing. It's also a Good Thing that the C++ compiler is now consistent. GCC has improved. Much rejoicing.
[Bug target/69533] [6 Regression] python miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69533 --- Comment #6 from Richard Biener --- Ugh, totally insufficient patch. Probably warrants a CVE, I'm sure some of them we optimized before, like old_size = sz; sz += a; if (sz < old_size) ... I'll dig further (just look for PyExc_OverflowError) and when I get the testsuite clean bug our security guys with a patch.
[Bug c++/69550] Need a way to disable "flexible array member in an otherwise empty struct" error on GCC 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69550 --- Comment #11 from Milan Bouchet-Valat --- (In reply to Marek Polacek from comment #9) > Note that this was only accepted by the C++ compiler; the C compiler always > rejected such a code (going back to at least gcc 3.4). Indeed you're right. The example only compiles with gcc (both 5 and 6) after changing the first struct member to *fieldptr0[0].
[Bug c++/69550] Need a way to disable "flexible array member in an otherwise empty struct" error on GCC 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69550 --- Comment #12 from Jonathan Wakely --- Apparently the case they actually care about in Julia is not what was posted here, which might be where the disagreement comes from. What they actually have is: typedef struct mytype { struct mytype *fieldptr0[0]; struct mytype *fieldptr[]; } mytype; The C front-end *does* accept this, which uses the non-standard zero-length array extension *and* a flexible array member.
[Bug c++/69550] Need a way to disable "flexible array member in an otherwise empty struct" error on GCC 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69550 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-01-29 Ever confirmed|0 |1 --- Comment #13 from Jonathan Wakely --- So if the intention is for the C++ front-end to match the C front-end then this should be accepted (and there's no need to allow the original example even with -fpermissive).
[Bug c++/69550] Need a way to disable "flexible array member in an otherwise empty struct" error on GCC 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69550 Milan Bouchet-Valat changed: What|Removed |Added Attachment #37514|0 |1 is obsolete|| --- Comment #14 from Milan Bouchet-Valat --- Created attachment 37520 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37520&action=edit Test C++ program which compiles with GCC 5 but not with GCC 6 Yes, sorry, I was about to explain the actual use case. Looks like I oversimplified the test program, as I hadn't spotted the difference of behavior in gcc (as opposed to g++). I've updated the test case to reflect this.
[Bug libstdc++/69553] New: Optimizations O1/O2 makes std::array value incorrect when passed to function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69553 Bug ID: 69553 Summary: Optimizations O1/O2 makes std::array value incorrect when passed to function Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: gee at ptilouk dot net Target Milestone: --- Created attachment 37521 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37521&action=edit Source code generating the bug The following example displays incorrect values when compiling with optimizations -O1 or -O2 (but not without optimization and not with -O3): -- #include #include typedef std::array, 2> Matrix; void foo(const double &px, const double &py) { std::cerr << px << " " << py << std::endl; } std::ostream& operator<<(std::ostream& os, const std::array& p) { return os << p[0] << " " << p[1]; } void test (const Matrix& t) { std::cerr << "In test: " << std::endl << t[0] << std::endl << t[1] << std::endl; std::cerr << "In foo: " << std::endl; foo(t[0][0], t[0][1]); foo(t[1][0], t[1][1]); } int main (int, char**) { Matrix t = {{ {{1,2}}, {{3,4}} }}; test (t); return 0; } -- (Compiled with 'g++-6 -std=c++11 -O1 test_bug_array.cpp') Without optimization (or with O3), i have the following output: In test: 1 2 3 4 In foo: 1 2 3 4 Which makes sense. Now if I turn on O1 or O2, I get: In test: 1 2 3 4 In foo: 1 3 3 4 The bug does not appear when using boost::array or when replacing the structure by a simple C-array (double[2][2]) or by pairs (std::pair >).
[Bug target/69161] [6 Regression] ICE in simplify_const_unary_operation, at simplify-rtx.c:1633
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69161 --- Comment #19 from Jakub Jelinek --- Any progress on this?
[Bug bootstrap/69506] [6 Regression] check-in 232454 seems to cause problems with cygwin builds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69506 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Jakub Jelinek --- Hopefully fixed.
[Bug target/69161] [6 Regression] ICE in simplify_const_unary_operation, at simplify-rtx.c:1633
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69161 --- Comment #20 from ktkachov at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #19) > Any progress on this? Yes, I'm testing patches for both arm and aarch64 to fix this. I'll try to post them early next week
[Bug other/69554] New: Multi-location diagnostics writes too many lines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69554 Bug ID: 69554 Summary: Multi-location diagnostics writes too many lines Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: tkoenig at gcc dot gnu.org Target Milestone: --- When showing multiple diagnostics in one error message, intermediate lines are shown (and some empty lines as well). This can be shown with the attached patch, which has the line gfc_error ("Symbol %qs at %C also declared as a type at %L", name, &st->n.sym->declared_at); With the test case type X end type integer :: q real :: a integer, parameter :: h=3 type(X) :: X end the error message is type.f90:8:12: type X 2 end type integer :: q real :: a integer, parameter :: h=3 type(X) :: X 1 Error: Symbol »x« at (1) also declared as a type at (2)
[Bug other/69554] Multi-location diagnostics writes too many lines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69554 --- Comment #1 from Thomas Koenig --- Created attachment 37522 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37522&action=edit patch to expose the problem
[Bug c++/69553] [6 Regression] Optimizations O1/O2 makes std::array value incorrect when passed to function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69553 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||5.3.0 Keywords||wrong-code Last reconfirmed||2016-01-29 Component|libstdc++ |c++ CC||trippels at gcc dot gnu.org Ever confirmed|0 |1 Summary|Optimizations O1/O2 makes |[6 Regression] |std::array value incorrect |Optimizations O1/O2 makes |when passed to function |std::array value incorrect ||when passed to function Known to fail||6.0 --- Comment #1 from Markus Trippelsdorf --- This is not a libstdc++ issue. gcc-5 and clang don't miscompile the example.
[Bug other/69554] Multi-location diagnostics writes too many lines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69554 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- I thought we already had a PR about this.
[Bug target/66137] [4.9/5/6 Regression] ICE with -ffixed-ebp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66137 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Fri Jan 29 14:07:40 2016 New Revision: 232981 URL: https://gcc.gnu.org/viewcvs?rev=232981&root=gcc&view=rev Log: PR target/66137 * gcc.target/i386/pr66137.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr66137.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug target/66137] [4.9/5/6 Regression] ICE with -ffixed-ebp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66137 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Jakub Jelinek --- Fixed by r231419. *** This bug has been marked as a duplicate of bug 68701 ***
[Bug target/68701] [4.9/5/6 Regression] "gcc -m32 -finstrument-functions -ffixed-ebp" produces internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68701 --- Comment #17 from Jakub Jelinek --- *** Bug 66137 has been marked as a duplicate of this bug. ***
[Bug target/69551] [4.9/5/6 Regression] Wrong code with single element vector insert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69551 --- Comment #8 from Jakub Jelinek --- Author: jakub Date: Fri Jan 29 14:14:56 2016 New Revision: 232982 URL: https://gcc.gnu.org/viewcvs?rev=232982&root=gcc&view=rev Log: PR target/69551 * config/i386/i386.c (ix86_expand_vector_set) : For SSE1, copy target into the temporary reg first before recursing on it. * gcc.target/i386/pr69551.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr69551.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog
[Bug c++/69553] [6 Regression] Optimizations O1/O2 makes std::array value incorrect when passed to function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69553 Richard Biener changed: What|Removed |Added Target Milestone|--- |6.0
[Bug target/69161] [6 Regression] ICE in simplify_const_unary_operation, at simplify-rtx.c:1633
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69161 --- Comment #21 from ktkachov at gcc dot gnu.org --- Patches posted at: https://gcc.gnu.org/ml/gcc-patches/2016-01/msg02308.html https://gcc.gnu.org/ml/gcc-patches/2016-01/msg02309.html
[Bug target/69551] [4.9/5/6 Regression] Wrong code with single element vector insert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69551 --- Comment #9 from Jakub Jelinek --- Author: jakub Date: Fri Jan 29 14:37:02 2016 New Revision: 232983 URL: https://gcc.gnu.org/viewcvs?rev=232983&root=gcc&view=rev Log: PR target/69551 * config/i386/i386.c (ix86_expand_vector_set) : For SSE1, copy target into the temporary reg first before recursing on it. * gcc.target/i386/pr69551.c: New test. Added: branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/pr69551.c Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/config/i386/i386.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug middle-end/69553] [6 Regression] Optimizations O1/O2 makes std::array value incorrect when passed to function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69553 Markus Trippelsdorf changed: What|Removed |Added CC||hubicka at ucw dot cz Component|c++ |middle-end --- Comment #2 from Markus Trippelsdorf --- Started with r229265: commit 2425f3b6ce0532030e1e4274d0fc82a5d7e16c79 Author: hubicka Date: Fri Oct 23 18:05:55 2015 + * fold-const.c (operand_equal_p): Do not compare TYPE_MODE when comparing addresses.
[Bug libgomp/69555] New: libgomp.c++/target-6.C fails because of undefined behaviour
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69555 Bug ID: 69555 Summary: libgomp.c++/target-6.C fails because of undefined behaviour Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: vogt at linux dot vnet.ibm.com CC: jakub at gcc dot gnu.org, krebbel at gcc dot gnu.org Target Milestone: --- Target: s390x The test case libgomp.c++/target-6.C fails on s390x, and I think that's because it uses a reference type variable in a "private" construct: -- snip -- ... int a[y - 2], b[y - 2]; int (&c)[y - 2] = a, (&d)[y - 2] = b; ^^^ ... #pragma omp target private (x, u, s, c, i) firstprivate (y, v, t, d) map(from\ :err) ^^^ { ... for (i = 0; i < y - 2; i++) c[i] = d[i]; ... } ... -- snip -- Depending on optimisations and the rest of the code, this leads to either incorrect values in the array "a" or accessing a pointer to random memory. As far as I understand it, the "OpenMP Application Program Interface, Version 4.0 - July 2013" explicitly forbids this on page 161: 28 • A variable that appears in a private clause must not have an incomplete type or a 29 reference type.
[Bug libgomp/69555] libgomp.c++/target-6.C fails because of undefined behaviour
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69555 --- Comment #1 from Jakub Jelinek --- But the test is OpenMP 4.5, and OpenMP 4.5 does allow reference types in the privatization clauses.
[Bug libgomp/69555] libgomp.c++/target-6.C fails because of undefined behaviour
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69555 --- Comment #2 from Dominik Vogt --- Does it work on other platforms?
[Bug libgomp/69555] libgomp.c++/target-6.C fails because of undefined behaviour
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69555 --- Comment #3 from Jakub Jelinek --- Works on x86_64/i686/ppc64/ppc64le/aarch64 for me, fails on armv7hfp, s390{,x}. I'm not saying there is not a middle-end bug, will need to analyze it.
[Bug middle-end/32401] [PPC/Altivec] Non optimal code structure with -mabi=altivec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32401 David Edelsohn changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-01-29 CC||wschmidt at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from David Edelsohn --- New
[Bug libgomp/69555] libgomp.c++/target-6.C fails because of undefined behaviour
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69555 --- Comment #4 from Dominik Vogt --- Sure. Can I provide any debug information or another kind of help?
[Bug tree-optimization/69556] New: [6 Regression] forwprop4/match.pd undoing work from recip
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69556 Bug ID: 69556 Summary: [6 Regression] forwprop4/match.pd undoing work from recip Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: jgreenhalgh at gcc dot gnu.org Target Milestone: --- For this code compiled at -Ofast: double bar (double, double, double, double, double); double foo (double a) { return bar (1.0/a, 2.0/a, 4.0/a, 8.0/a, 16.0/a); } GCC 5 generates: foo: .LFB0: .cfi_startproc movsd .LC0(%rip), %xmm1 movsd .LC1(%rip), %xmm4 movsd .LC2(%rip), %xmm3 divsd %xmm0, %xmm1 movsd .LC3(%rip), %xmm2 mulsd %xmm1, %xmm4 movapd %xmm1, %xmm0 mulsd %xmm1, %xmm3 mulsd %xmm1, %xmm2 addsd %xmm1, %xmm1 jmp bar (i.e. one divide, 4 multiplies) GCC trunk at revision r232907 generates: foo: .LFB0: .cfi_startproc movapd %xmm0, %xmm5 movsd .LC0(%rip), %xmm4 movsd .LC4(%rip), %xmm0 movsd .LC1(%rip), %xmm3 movsd .LC2(%rip), %xmm2 movsd .LC3(%rip), %xmm1 divsd %xmm5, %xmm0 divsd %xmm5, %xmm4 divsd %xmm5, %xmm3 divsd %xmm5, %xmm2 divsd %xmm5, %xmm1 jmp bar (i.e. 5 divides) This is bad for performance. forwprop4 shows: Applying pattern match.pd:453, gimple-match.c:32116 gimple_simplified to _2 = 1.6e+1 / a_1(D); Applying pattern match.pd:453, gimple-match.c:32116 gimple_simplified to _3 = 8.0e+0 / a_1(D); Applying pattern match.pd:453, gimple-match.c:32116 gimple_simplified to _4 = 4.0e+0 / a_1(D); Applying pattern match.pd:453, gimple-match.c:32116 gimple_simplified to _5 = 2.0e+0 / a_1(D); This starts with r229107 which moves the (C1/X)*C2 into (C1*C2)/X pattern from fold-const.c to match.pd.
[Bug libgomp/69555] libgomp.c++/target-6.C fails because of undefined behaviour
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69555 --- Comment #5 from Dominik Vogt --- Hm, actually the chapter about "private" says nothing about how to actually *handle* a reference type whereas it states that for "firstprivate" and "lastprivate" the reference must bind to the same object for all threads. To me it still looks as if using references in "private" is undefined.
[Bug libgomp/69555] libgomp.c++/target-6.C fails because of undefined behaviour
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69555 --- Comment #6 from Dominik Vogt --- Example: -- snip -- #include int main () { int a; int &c = a; printf("a %p\n", &a); printf("g %p\n", &c); #pragma omp target private (c) { printf("t %p\n", &c); } return 0; } -- snip -- prints a 0x3a0edb4 g 0x3a0edb4 t 0x3a0ea24 <--- c in the loop points to different memory
[Bug libgomp/69555] libgomp.c++/target-6.C fails because of undefined behaviour
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69555 --- Comment #7 from Jakub Jelinek --- It is well defined. Anyway, most likely the bug is already during gimplification. I see in the omplower dump: int[0:(sizetype) D.2477] & c; ... D.2477 = D.2476 + -1; ... #pragma omp target num_teams(1) thread_limit(0) map(from:err [len: 4]) firstprivate(d) firstprivate(t) firstprivate(v) firstprivate(y) priv ate(i) private(c) private(s) private(u) private(x) [child fn: _Z3fooRiS_R1SS1_RdS2_._omp_fn.0 (.omp_data_arr.7, .omp_data_sizes.8, .omp_data_kinds. 9)] { try { ... D.2689 = (sizetype) D.2477; D.2690 = D.2689 + 1; D.2691 = D.2690 * 4; D.2692 = __builtin_alloca_with_align (D.2691, 32); c = D.2692; Accessing an automatic variable from the caller inside of target region is wrong, it should have been made firstprivate during gimplification, which would allow it to work.
[Bug rtl-optimization/69557] New: [ARM] revsh instruction not being conditionalised for Thumb2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69557 Bug ID: 69557 Summary: [ARM] revsh instruction not being conditionalised for Thumb2 Product: gcc Version: 6.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: ktkachov at gcc dot gnu.org Target Milestone: --- Target: arm* While doing some of the testcase splitting work for PR 65578 I saw that we don't use conditional execution as much as we should for Thumb2. The testcase: extern short foos16 (short); /* revshne */ short swaps16_cond (short x, int y) { short z = x; if (y) z = __builtin_bswap16 (x); return foos16 (z); } for -march=armv6t2 -mthumb -O2 I get: swaps16_cond: @ args = 0, pretend = 0, frame = 0 @ frame_needed = 0, uses_anonymous_args = 0 @ link register save eliminated. cbz r1, .L2 revsh r0, r0 .L2: b whereas for -march=armv6t2 -mthumb -O2 we get conditional execution: swaps16_cond: @ args = 0, pretend = 0, frame = 0 @ frame_needed = 0, uses_anonymous_args = 0 @ link register save eliminated. cmp r1, #0 revshne r0, r0 .L2: b Note that the -marm version gets conditionalised at the very end in arm_final_prescan_insn which we don't perform for Thumb2. The ce3 pass doesn't create the COND_EXEC forms like I'd expect. For the testcase above it refuses to perform any transformations in cond_exec_find_if_block (from ifcvt.c) where it fails the check: /* The edges of the THEN and ELSE blocks cannot have complex edges. */ FOR_EACH_EDGE (cur_edge, ei, then_bb->preds) { if (cur_edge->flags & EDGE_COMPLEX) return FALSE; } Seems the edge is deemed complex so ifconversion bails out.
[Bug target/65010] ppc backend generates unnecessary signed extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65010 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org --- Comment #8 from Segher Boessenkool --- Not the same thing. The ABI requires sign extension for the function result and the parameters. In PR23450, the request is we do not follow the ABI for a function that is only called locally. In this PR on the other hand, the sign extension will never do anything, so the PR asks for the code to be optimised better, removing the unnecessary extsw.
[Bug tree-optimization/69556] [6 Regression] forwprop4/match.pd undoing work from recip
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69556 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2016-01-29 CC||pinskia at gcc dot gnu.org Target Milestone|--- |6.0 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- I suspect we should disable "Fold (C1/X)*C2 into (C1*C2)/X" for gimple then and have it only for generic.
[Bug tree-optimization/69556] [6 Regression] forwprop4/match.pd undoing work from recip
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69556 --- Comment #2 from Andrew Pinski --- (In reply to Andrew Pinski from comment #1) > I suspect we should disable "Fold (C1/X)*C2 into (C1*C2)/X" for gimple then > and have it only for generic. Or check for single use of the divide.
[Bug rtl-optimization/69530] [6 Regression] ICE: SIGSEGV in ix86_split_long_move (i386.c:24353) with -fno-split-wide-types -mavx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69530 --- Comment #13 from H.J. Lu --- (In reply to Vladimir Makarov from comment #12) > (In reply to H.J. Lu from comment #11) > > (In reply to H.J. Lu from comment #10) > > > Created attachment 37512 [details] > > > A new patch > > > > > > I am testing this now. > > > > No regressions on x86-64. I will leave it to Vladimir. > > Thanks, HJ. I'll investigate it. It will take some time. But what I see > you removed a code in LRA which was used to fix some bugs. And it is > questionable for me. I reverted r229087 which was supposed to fix PR 67609 which is tracked by gcc.target/i386/pr67609-2.c and gcc.target/i386/pr67609.c. Apparently r229458 made r229087 unnecessary.
[Bug rtl-optimization/69530] [6 Regression] ICE: SIGSEGV in ix86_split_long_move (i386.c:24353) with -fno-split-wide-types -mavx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69530 --- Comment #12 from Vladimir Makarov --- (In reply to H.J. Lu from comment #11) > (In reply to H.J. Lu from comment #10) > > Created attachment 37512 [details] > > A new patch > > > > I am testing this now. > > No regressions on x86-64. I will leave it to Vladimir. Thanks, HJ. I'll investigate it. It will take some time. But what I see you removed a code in LRA which was used to fix some bugs. And it is questionable for me.
[Bug target/65604] MIPS -fno-delayed-branch generates incorrect code with -mcheck-zero-division
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65604 --- Comment #4 from Steve Ellcey --- Author: sje Date: Fri Jan 29 16:29:58 2016 New Revision: 232985 URL: https://gcc.gnu.org/viewcvs?rev=232985&root=gcc&view=rev Log: PR target/65604 * config/mips/mips.c (mips_output_division): Check flag_delayed_branch. Modified: trunk/gcc/ChangeLog trunk/gcc/config/mips/mips.c
[Bug target/65604] MIPS -fno-delayed-branch generates incorrect code with -mcheck-zero-division
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65604 --- Comment #5 from Steve Ellcey --- Author: sje Date: Fri Jan 29 16:31:18 2016 New Revision: 232986 URL: https://gcc.gnu.org/viewcvs?rev=232986&root=gcc&view=rev Log: PR target/65604 * gcc.target/mips/div-delay.c: New test. Added: trunk/gcc/testsuite/gcc.target/mips/div-delay.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug target/69459] [5 Regression] wrong code with -O2 and vector arithmetics @ x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69459 --- Comment #14 from uros at gcc dot gnu.org --- Author: uros Date: Fri Jan 29 16:52:15 2016 New Revision: 232988 URL: https://gcc.gnu.org/viewcvs?rev=232988&root=gcc&view=rev Log: PR target/69459 * config/i386/constraints.md (C): Only accept constant zero operand. (BC): New constraint. * config/i386/sse.md (*mov_internal): Use BC constraint instead of C constraint. * doc/md.texi (Machine Constraints): Update description of C constraint. testsuite/ChangeLog: PR target/69459 * gcc.target/i386/pr69459.c: New test. Added: branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/pr69459.c Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/config/i386/constraints.md branches/gcc-5-branch/gcc/config/i386/sse.md branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug middle-end/69553] [6 Regression] Optimizations O1/O2 makes std::array value incorrect when passed to function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69553 --- Comment #3 from Andrew Pinski --- foo (_13, _11); _9 = &MEM[(const int[2] &)t_2(D) + 8][1]; foo (_11, _9); [tail call] Trying to reduce the issue. (In reply to Markus Trippelsdorf from comment #2) > Started with r229265: > > commit 2425f3b6ce0532030e1e4274d0fc82a5d7e16c79 > Author: hubicka > Date: Fri Oct 23 18:05:55 2015 + > > * fold-const.c (operand_equal_p): Do not compare TYPE_MODE when > comparing addresses. I think this just exposed the issue somewhere else.