[Bug rtl-optimization/89487] [7/8 Regression] ICE in expand_expr_addr_expr_1, at expr.c:7993
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89487 --- Comment #10 from Jakub Jelinek --- On the trunk it is fine, but it needs to be backported to 8 (and the dup bug shows that to 7 as well).
[Bug middle-end/87256] hppa spends huge amount of time in synth_mult()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87256 --- Comment #8 from Matt Turner --- This xxhash.c file is embedded in many different projects, and is really causing problems on gentoo/hppa: zstandard: Fri Mar 15 14:16:42 2019: 7 hours, 29 minutes, 49 seconds Are we any closer to a fix than we were six months ago?
[Bug c++/87015] [8/9 Regression] miscompilation of template heavy Boost Spirit code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87015 Daniel Starke changed: What|Removed |Added Known to work||8.3.0 --- Comment #10 from Daniel Starke --- Whatever it was, for me the bug is gone using gcc 8.3.0 with binutils 2.32.
[Bug target/89523] Incorrect AVX instructions with VSIB address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89523 --- Comment #2 from hjl at gcc dot gnu.org --- Author: hjl Date: Sun Mar 17 09:11:22 2019 New Revision: 269738 URL: https://gcc.gnu.org/viewcvs?rev=269738&root=gcc&view=rev Log: x32: Add addr32 prefix to VSIB address 32-bit indices in VSIB address are sign-extended to 64 bits. In x32, when 32-bit indices are used as addresses, like in vgatherdps %ymm7, 0(,%ymm9,1), %ymm6 32-bit indices, 0xf7fa3010, is sign-extended to 0xf7fa3010 which is invalid address. Add addr32 prefix to UNSPEC_VSIBADDR instructions for x32 if there is no base register nor symbol. This fixes 175.vpr and 254.gap in SPEC CPU 2000 on x32 with -Ofast -funroll-loops -march=haswell gcc/ Backport from mainline 2019-03-14 H.J. Lu PR target/89523 * config/i386/i386.c (ix86_print_operand): Handle 'M' to add addr32 prefix to VSIB address for X32. * config/i386/sse.md (*avx512pf_gatherpfsf_mask): Prepend "%M2" to opcode. (*avx512pf_gatherpfdf_mask): Likewise. (*avx512pf_scatterpfsf_mask): Likewise. (*avx512pf_scatterpfdf_mask): Likewise. (*avx2_gathersi): Prepend "%M3" to opcode. (*avx2_gathersi_2): Prepend "%M2" to opcode. (*avx2_gatherdi): Prepend "%M3" to opcode. (*avx2_gatherdi_2): Prepend "%M2" to opcode. (*avx2_gatherdi_3): Prepend "%M3" to opcode. (*avx2_gatherdi_4): Prepend "%M2" to opcode.` (*avx512f_gathersi): Prepend "%M4" to opcode. (*avx512f_gathersi_2): Prepend "%M3" to opcode. (*avx512f_gatherdi): Prepend "%M4" to opcode. (*avx512f_gatherdi_2): Prepend "%M3" to opcode. (*avx512f_scattersi): Prepend "%M0" to opcode. (*avx512f_scatterdi): Likewise. gcc/testsuite/ Backport from mainline 2019-03-14 H.J. Lu PR target/89523 * gcc.target/i386/pr89523-1a.c: New test. * gcc.target/i386/pr89523-1b.c: Likewise. * gcc.target/i386/pr89523-2.c: Likewise. * gcc.target/i386/pr89523-3.c: Likewise. * gcc.target/i386/pr89523-4.c: Likewise. * gcc.target/i386/pr89523-5.c: Likewise. * gcc.target/i386/pr89523-6.c: Likewise. * gcc.target/i386/pr89523-7.c: Likewise. * gcc.target/i386/pr89523-8.c: Likewise. * gcc.target/i386/pr89523-9.c: Likewise. Added: branches/gcc-8-branch/gcc/testsuite/gcc.target/i386/pr89523-1a.c branches/gcc-8-branch/gcc/testsuite/gcc.target/i386/pr89523-1b.c branches/gcc-8-branch/gcc/testsuite/gcc.target/i386/pr89523-2.c branches/gcc-8-branch/gcc/testsuite/gcc.target/i386/pr89523-3.c branches/gcc-8-branch/gcc/testsuite/gcc.target/i386/pr89523-4.c branches/gcc-8-branch/gcc/testsuite/gcc.target/i386/pr89523-5.c branches/gcc-8-branch/gcc/testsuite/gcc.target/i386/pr89523-6.c branches/gcc-8-branch/gcc/testsuite/gcc.target/i386/pr89523-7.c branches/gcc-8-branch/gcc/testsuite/gcc.target/i386/pr89523-8.c branches/gcc-8-branch/gcc/testsuite/gcc.target/i386/pr89523-9.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/config/i386/i386.c branches/gcc-8-branch/gcc/config/i386/sse.md branches/gcc-8-branch/gcc/testsuite/ChangeLog
qhh提%%供%%税%%栗%zT
gcc-bugs@gcc.gnu.org + 润匀 可 办 税 票，认 证 后 付 歀。 详 电：李 生，136—6075— 4190， 业 q：157— 533— 2698 ---
[Bug target/89523] Incorrect AVX instructions with VSIB address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89523 --- Comment #3 from hjl at gcc dot gnu.org --- Author: hjl Date: Sun Mar 17 09:27:56 2019 New Revision: 269739 URL: https://gcc.gnu.org/viewcvs?rev=269739&root=gcc&view=rev Log: x32: Add addr32 prefix to VSIB address 32-bit indices in VSIB address are sign-extended to 64 bits. In x32, when 32-bit indices are used as addresses, like in vgatherdps %ymm7, 0(,%ymm9,1), %ymm6 32-bit indices, 0xf7fa3010, is sign-extended to 0xf7fa3010 which is invalid address. Add addr32 prefix to UNSPEC_VSIBADDR instructions for x32 if there is no base register nor symbol. This fixes 175.vpr and 254.gap in SPEC CPU 2000 on x32 with -Ofast -funroll-loops -march=haswell gcc/ Backport from mainline 2019-03-14 H.J. Lu PR target/89523 * config/i386/i386.c (ix86_print_operand): Handle 'M' to add addr32 prefix to VSIB address for X32. * config/i386/sse.md (*avx512pf_gatherpfsf_mask): Prepend "%M2" to opcode. (*avx512pf_gatherpfdf_mask): Likewise. (*avx512pf_scatterpfsf_mask): Likewise. (*avx512pf_scatterpfdf_mask): Likewise. (*avx2_gathersi): Prepend "%M3" to opcode. (*avx2_gathersi_2): Prepend "%M2" to opcode. (*avx2_gatherdi): Prepend "%M3" to opcode. (*avx2_gatherdi_2): Prepend "%M2" to opcode. (*avx2_gatherdi_3): Prepend "%M3" to opcode. (*avx2_gatherdi_4): Prepend "%M2" to opcode.` (*avx512f_gathersi): Prepend "%M4" to opcode. (*avx512f_gathersi_2): Prepend "%M3" to opcode. (*avx512f_gatherdi): Prepend "%M4" to opcode. (*avx512f_gatherdi_2): Prepend "%M3" to opcode. (*avx512f_scattersi): Prepend "%M0" to opcode. (*avx512f_scatterdi): Likewise. gcc/testsuite/ Backport from mainline 2019-03-14 H.J. Lu PR target/89523 * gcc.target/i386/pr89523-1a.c: New test. * gcc.target/i386/pr89523-1b.c: Likewise. * gcc.target/i386/pr89523-2.c: Likewise. * gcc.target/i386/pr89523-3.c: Likewise. * gcc.target/i386/pr89523-4.c: Likewise. * gcc.target/i386/pr89523-5.c: Likewise. * gcc.target/i386/pr89523-6.c: Likewise. * gcc.target/i386/pr89523-7.c: Likewise. * gcc.target/i386/pr89523-8.c: Likewise. * gcc.target/i386/pr89523-9.c: Likewise. Added: branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/pr89523-1a.c branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/pr89523-1b.c branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/pr89523-2.c branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/pr89523-3.c branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/pr89523-4.c branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/pr89523-5.c branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/pr89523-6.c branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/pr89523-7.c branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/pr89523-8.c branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/pr89523-9.c Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/config/i386/i386.c branches/gcc-7-branch/gcc/config/i386/sse.md branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug fortran/68009] [7/8/9 Regression] prototype for gfortran_runtime_error with inline matmul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68009 Thomas Koenig changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org
[Bug c++/89744] New: [8/9 Regression] ICE with specialization of nested template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89744
Bug ID: 89744
Summary: [8/9 Regression] ICE with specialization of nested
template class
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
Target Milestone: ---
The following valid testcase triggers an ICE since GCC 8.1.0:
template struct A
{
template struct B {};
A() { B b; }
};
template<> template
struct A::B
{
virtual void foo() {}
};
A a;
bug.cc: In instantiation of 'struct A::B':
bug.cc:10:16: recursively required from 'void A::B<
>::foo() [with = int]'
bug.cc:10:16: required from here
bug.cc:9:1: internal compiler error: in finish_member_declaration, at
cp/semantics.c:3126
9 | {
| ^
0x68321f finish_member_declaration(tree_node*)
../../gcc/gcc/cp/semantics.c:3126
0xa3175f instantiate_class_template_1
../../gcc/gcc/cp/pt.c:11167
0xa3175f instantiate_class_template(tree_node*)
../../gcc/gcc/cp/pt.c:11468
0xa7750d complete_type(tree_node*)
../../gcc/gcc/cp/typeck.c:138
0xa3f0af lookup_member(tree_node*, tree_node*, int, bool, int,
access_failure_info*)
../../gcc/gcc/cp/search.c:1129
0x994575 get_class_binding
../../gcc/gcc/cp/name-lookup.c:4451
0x9991bf outer_binding(tree_node*, cxx_binding*, bool)
../../gcc/gcc/cp/name-lookup.c:6330
0x9a07d4 check_local_shadow
../../gcc/gcc/cp/name-lookup.c:2631
0x9a07d4 do_pushdecl
../../gcc/gcc/cp/name-lookup.c:3097
0x9a07d4 pushdecl(tree_node*, bool)
../../gcc/gcc/cp/name-lookup.c:3162
0x928dfe store_parm_decls
../../gcc/gcc/cp/decl.c:15683
0x928dfe start_preparsed_function(tree_node*, tree_node*, int)
../../gcc/gcc/cp/decl.c:1
0xa2fb66 instantiate_decl(tree_node*, bool, bool)
../../gcc/gcc/cp/pt.c:24643
0xa33c8b instantiate_pending_templates(int)
../../gcc/gcc/cp/pt.c:24777
0x952258 c_parse_final_cleanups()
../../gcc/gcc/cp/decl2.c:4802
Please submit a full bug report, [etc.]
However, similar testcases regressed with different releases.
ICE since GCC 4.0.0:
template struct A
{
template struct B {};
A() { B b; }
};
template<> template
struct A::B
{
virtual void foo() {}
void bar() {}
};
A a;
ICE since GCC 3.2.3:
template struct A
{
template struct B {};
A() { B b; }
};
template<> template
struct A::B
{
~B() {}
};
A a;
ICE since GCC 4.8.4:
template struct A
{
template struct B {};
typedef B X;
};
template<> template
struct A::B
{
typedef int Y;
};
A::B b;
[Bug c++/89744] [8/9 Regression] ICE with specialization of nested template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89744 Volker Reichelt changed: What|Removed |Added Target Milestone|--- |8.4
[Bug c++/79308] ICE on specialization of nested template classes (in finish_member_declaration, at cp/semantics.c:2963)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79308 Volker Reichelt changed: What|Removed |Added CC||reichelt at gcc dot gnu.org Depends on||89744 --- Comment #5 from Volker Reichelt --- IMHO the testcase is invalid (e.g. clang rejects it). But by changing the line struct Element::WriteOutput into struct Element::WriteOutput it can be turned into a valid testcase. There are several similar testcases, so I opened a new PR 89744 for this. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89744 [Bug 89744] [8/9 Regression] ICE with specialization of nested template class
[Bug c++/89745] New: [[no_unique_address]] has no effect in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89745
Bug ID: 89745
Summary: [[no_unique_address]] has no effect in some cases
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tower120 at gmail dot com
Target Milestone: ---
[[no_unique_address]] has no effect in the following case:
https://wandbox.org/permlink/pcMbjWGcdKL3aHJS
template
struct alternative_pair{
[[no_unique_address]] F first;
[[no_unique_address]] S second;
};
int main(){
struct empty{};
using Data = void*;
using P1 = alternative_pair;
using P2 = alternative_pair;
std::cout << sizeof(Data) << std::endl;
std::cout << sizeof(P1) << std::endl;
std::cout << sizeof(P2) << std::endl;
return 0;
}
Output: 8 8 16
Expected: 8 8 8
[Bug c++/81866] [7/8/9 Regression] ICE with a default template parameter which is a template class nested in a template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81866 Volker Reichelt changed: What|Removed |Added Last reconfirmed|2017-09-11 00:00:00 |2019-3-17 CC||reichelt at gcc dot gnu.org Target Milestone|--- |7.5 Summary|ICE with a default template |[7/8/9 Regression] ICE with |parameter which is a|a default template |template class nested in a |parameter which is a |template class |template class nested in a ||template class --- Comment #2 from Volker Reichelt --- This is a regression that was introduced in GCC 4.5.0.
[Bug c++/89745] [[no_unique_address]] has no effect in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89745
tower120 changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #1 from tower120 ---
Sorry, gcc behavior is correct. If empty types should are different - all ok:
struct empty{};
struct empty2{};
using Data = void*;
using P1 = alternative_pair;
using P2 = alternative_pair;
[Bug c++/79308] ICE on specialization of nested template classes (in finish_member_declaration, at cp/semantics.c:2963)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79308 --- Comment #6 from bjhend --- (In reply to Volker Reichelt from comment #5) > IMHO the testcase is invalid (e.g. clang rejects it). > But by changing the line > struct Element::WriteOutput > into > struct Element::WriteOutput > it can be turned into a valid testcase. Yes, you're right. It's the generic definition of the inner template so the additional shouldn't be there. Thanks for correcting this. > There are several similar testcases, so I opened a new PR 89744 for this. Thanks.
[Bug fortran/84394] [7/8 Regression] compiler error when using modules with derived types in block data subprograms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84394 --- Comment #7 from Thomas Koenig --- Author: tkoenig Date: Sun Mar 17 12:45:33 2019 New Revision: 269740 URL: https://gcc.gnu.org/viewcvs?rev=269740&root=gcc&view=rev Log: 2019-03-17 Thomas Koenig PR fortran/84394 Backport from trunk * symbol.c (gfc_add_subroutine): If we are encountering a subrtoutine within a BLOCK DATA and the name starts with an underscore, do not check. 2019-03-17 Thomas Koenig PR fortran/84394 Backport from trunk * gfortran.dg/blockdata_11.f90: New test. Added: branches/gcc-8-branch/gcc/testsuite/gfortran.dg/blockdata_11.f90 Modified: branches/gcc-8-branch/gcc/fortran/ChangeLog branches/gcc-8-branch/gcc/fortran/symbol.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug fortran/84394] [7/8 Regression] compiler error when using modules with derived types in block data subprograms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84394 --- Comment #8 from Thomas Koenig --- Author: tkoenig Date: Sun Mar 17 12:54:29 2019 New Revision: 269741 URL: https://gcc.gnu.org/viewcvs?rev=269741&root=gcc&view=rev Log: 2019-03-17 Thomas Koenig PR fortran/84394 Backport from trunk * symbol.c (gfc_add_subroutine): If we are encountering a subrtoutine within a BLOCK DATA and the name starts with an underscore, do not check. 2019-03-17 Thomas Koenig PR fortran/84394 Backport from trunk * gfortran.dg/blockdata_11.f90: New test. Added: branches/gcc-7-branch/gcc/testsuite/gfortran.dg/blockdata_11.f90 Modified: branches/gcc-7-branch/gcc/fortran/ChangeLog branches/gcc-7-branch/gcc/fortran/symbol.c branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug fortran/84394] [7/8 Regression] compiler error when using modules with derived types in block data subprograms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84394 Thomas Koenig changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Thomas Koenig --- Fixed on all open branches, closing.
[Bug c++/89743] [concepts] ICE when using decltype(requires-expr) as type template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89743 Jonathan Wakely changed: What|Removed |Added Keywords||ice-checking Status|UNCONFIRMED |NEW Last reconfirmed||2019-03-17 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- GCC 8 gives: c.cc:5:23: error: expected nested-name-specifier using type = typename use_type; ~~~ But I think that might be because my GCC 8 builds use --enable-checking=release
[Bug c++/89745] [[no_unique_address]] has no effect in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89745 --- Comment #2 from Jonathan Wakely --- Right, this is how it's supposed to work. Two different objects of the same type must have unique addresses.
[Bug fortran/67123] ICE with source allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67123 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Dominique d'Humieres --- > I can confirm that this is a duplicate of 66927. Then mark this PR as a duplicate. *** This bug has been marked as a duplicate of bug 66927 ***
[Bug fortran/66927] [6 Regression] ICE in gfc_conf_procedure_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66927 Dominique d'Humieres changed: What|Removed |Added CC||mrestelli at gmail dot com --- Comment #21 from Dominique d'Humieres --- *** Bug 67123 has been marked as a duplicate of this bug. ***
[Bug fortran/61261] [OOP] Segfault on source-allocating polymorphic variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61261 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #10 from Dominique d'Humieres --- > AFAICT all related PRs are fixed. Close this one, too? Confirmed, closing.
[Bug fortran/45715] [ABI cleanup] Move runtime parsing of I/O control list to front end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45715 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WONTFIX --- Comment #5 from Dominique d'Humieres --- > Any progress after four years and a half? No feedback after three years and a half. Closing as WONTFIX.
[Bug fortran/37577] [meta-bug] change internal array descriptor format for better syntax, C interop TR, rank 15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37577 Bug 37577 depends on bug 45715, which changed state. Bug 45715 Summary: [ABI cleanup] Move runtime parsing of I/O control list to front end https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45715 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WONTFIX
[Bug fortran/48419] Reduce gfortran stack usage for procedures doing IO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48419 Bug 48419 depends on bug 45715, which changed state. Bug 45715 Summary: [ABI cleanup] Move runtime parsing of I/O control list to front end https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45715 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WONTFIX
[Bug fortran/56818] [meta-bug] fortran-dev bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56818 Bug 56818 depends on bug 45715, which changed state. Bug 45715 Summary: [ABI cleanup] Move runtime parsing of I/O control list to front end https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45715 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WONTFIX
[Bug fortran/53298] ICE in gfc_conv_scalarized_array_ref for ARRAY + substring
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53298 --- Comment #6 from Dominique d'Humieres --- The tests in comment 0 and 5 compile if I replace '(1:)' with something such as '(1:3)'.
[Bug fortran/88750] [9 Regression] runtime error in statically linked binaries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750 --- Comment #36 from Dominique d'Humieres --- Any progress? Is it really a gfortran bug?
[Bug fortran/88750] [9 Regression] runtime error in statically linked binaries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750 --- Comment #37 from Jürgen Reuter --- I'm inclined to advice to close this PR. In principle, it would be good to follow up on this and see which change around Christmas 2018 triggered this, but I fear we don't have the personpower atm.
[Bug c++/89745] [[no_unique_address]] has no effect in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89745 Marc Glisse changed: What|Removed |Added Keywords||ABI --- Comment #3 from Marc Glisse --- This is a weakness of the ABI. There is enough space to put 8 "empty" objects in parallel to Data, but depending on the exact way you ask for it, the specification sometimes says to give up looking for reusable space :-( A class with empty, empty and void* members in this order will have size 8.
[Bug fortran/78865] [7/8/9 Regression] ICE in create_tmp_var, at gimple-expr.c:473
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78865 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #5 from Thomas Koenig --- Created attachment 45983 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45983&action=edit Patch which causes regressions This fixes the test case, but causes regressions.
[Bug c++/87015] [8/9 Regression] miscompilation of template heavy Boost Spirit code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87015 Marek Polacek changed: What|Removed |Added Status|WAITING |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED --- Comment #11 from Marek Polacek --- Closing then. Please reopen if you find it again.
[Bug fortran/88750] [9 Regression] runtime error in statically linked binaries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750 Jakub Jelinek changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WORKSFORME --- Comment #38 from Jakub Jelinek --- Closing then.
[Bug fortran/71861] [7/8/9 Regression] [F03] ICE in write_symbol(): bad module symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71861 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #6 from Thomas Koenig --- > module m >intrinsic abs >abstract interface > function abs(x) > real :: abs, x > end >end interface > end I cannot tell if this is legal or not. How should the compiler behave?
[Bug c++/89743] [concepts] ICE when using decltype(requires-expr) as type template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89743 --- Comment #2 from Jason Cobb --- (In reply to Jonathan Wakely from comment #1) > GCC 8 gives: > > c.cc:5:23: error: expected nested-name-specifier > using type = typename use_type^~ > 1; > ~~ > })>; > ~~~ > > But I think that might be because my GCC 8 builds use > --enable-checking=release Yes, that would actually be an error if it didn't ICE. However, the ICE does still occur without the typename keyword.
[Bug libfortran/79134] Implicit declaration of free due to missing include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79134 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WONTFIX --- Comment #3 from Dominique d'Humieres --- No feedback -> WONTFIX.
[Bug c++/58074] [C++11][DR 1333] __is_trivial intrinsic fails for deleted members and for non-trivial copy-c'tors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58074 --- Comment #10 from Daniel Krügler --- (In reply to Jonathan Wakely from comment #9) > (In reply to Daniel Krügler from comment #0) > > The deleted default constructor should not prevent type Trivial of being > > trivial (Maybe this part of the problem is related to bug 52707, but I'm not > > sure). > > I think DR 1363 changed that (and DR 1496 reconfirmed it) so the first test > is wrong. But G++ now passes that assertion, so that's also wrong (that is > Bug 85723 though). I agree in regard to DR 1496. The history behind that was that during the Portland 2012 CWG drafting of that issue the following wording suggestion was provided: "A trivial class is a class that is trivially copyable and has either a trivial default constructor or no default constructor (12.1 class.ctor)." That wording had the effect that classes with either deleted or no default constructor could be trivial and made these two cases consistent as pointed out by DR 1496. That P/R was then later rejected and modified to the now accepted wording at the Kona 2015 meeting, which also had the effect of making the two cases consistent in a now a different way, by imposing the requirement that at least one non-deleted default constructor exists. I don't think that DR 1363 changed the situation, because the meaning of the 1363 wording still didn't exclude deleted constructors from being trivial.
[Bug fortran/71861] [7/8/9 Regression] [F03] ICE in write_symbol(): bad module symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71861 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #7 from kargl at gcc dot gnu.org --- (In reply to Thomas Koenig from comment #6) > > module m > >intrinsic abs > >abstract interface > > function abs(x) > > real :: abs, x > > end > >end interface > > end > > I cannot tell if this is legal or not. How should the compiler > behave? Does Note 15.2 in F2018 apply? An interface body cannot be used to describe the interface of an internal procedure, a module procedure that is not a separate module procedure, or an intrinsic procedure because the interfaces of such procedures are already explicit. However, the name of a procedure can appear in a PROCEDURE statement in an interface block (15.4.3.2).
[Bug fortran/42122] [F03] -fdump-tree-original shows wrong static decl for functions with procptr argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42122 --- Comment #4 from Dominique d'Humieres --- > Is this eight-year old PR fixed or not? Should I close this PR as FIXED to get an answer?
[Bug testsuite/89666] FAIL: gcc.dg/ipa/ipa-icf-39.c scan-ipa-dump-times icf "Unified;" 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89666 --- Comment #4 from John David Anglin --- Author: danglin Date: Sun Mar 17 17:59:03 2019 New Revision: 269742 URL: https://gcc.gnu.org/viewcvs?rev=269742&root=gcc&view=rev Log: PR testsuite/89666 * c-c++-common/builtin-has-attribute-3.c: Define SKIP_ALIAS on hppa*-*-hpux*. * gcc.dg/attr-copy.c: Require alias support. * gcc.dg/ipa/ipa-icf-39.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/builtin-has-attribute-3.c trunk/gcc/testsuite/gcc.dg/attr-copy.c trunk/gcc/testsuite/gcc.dg/ipa/ipa-icf-39.c
[Bug testsuite/89666] FAIL: gcc.dg/ipa/ipa-icf-39.c scan-ipa-dump-times icf "Unified;" 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89666 John David Anglin changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from John David Anglin --- Fixed on trunk.
[Bug libfortran/88805] hidden symbol `__cpu_model' is referenced by DSO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88805 --- Comment #10 from Dominique d'Humieres --- > Okay, since this a downstream bug, moving back to waiting. Is this really a gfortran bug?
[Bug fortran/82173] [meta-bug] Parameterized derived type errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82173 Bug 82173 depends on bug 84120, which changed state. Bug 84120 Summary: Syntax for used for PDT constructors is incorrect https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84120 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |DUPLICATE
[Bug fortran/84120] Syntax for used for PDT constructors is incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84120 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Dominique d'Humieres --- > Duplicate of PR82205? Yes. *** This bug has been marked as a duplicate of bug 82205 ***
[Bug fortran/84094] several correctness issues in gfortran.dg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84094 Bug 84094 depends on bug 84120, which changed state. Bug 84120 Summary: Syntax for used for PDT constructors is incorrect https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84120 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |DUPLICATE
[Bug fortran/82205] parametrized derived types, problems with initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82205 Dominique d'Humieres changed: What|Removed |Added CC||neil.n.carlson at gmail dot com --- Comment #2 from Dominique d'Humieres --- *** Bug 84120 has been marked as a duplicate of this bug. ***
[Bug fortran/82205] parametrized derived types, problems with initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82205 --- Comment #3 from Dominique d'Humieres --- See pr84120 for the analysis.
[Bug c++/89571] [9 Regression] ICE in nothrow_spec_p, at cp/except.c:1238
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89571 --- Comment #7 from Jason Merrill --- Author: jason Date: Sun Mar 17 20:07:26 2019 New Revision: 269746 URL: https://gcc.gnu.org/viewcvs?rev=269746&root=gcc&view=rev Log: PR c++/89571 - ICE with ill-formed noexcept on constructor. Earlier changes to defer instantiating a defaulted noexcept-specifier that depends on yet-unparsed default member initializers broke this testcase, where instantiation fails for another reason. In this case there's no reason to defer and try again later, so let's not. * pt.c (maybe_instantiate_noexcept): Only return false if defaulted. (regenerate_decl_from_template): Use it for noexcept-specs. Added: trunk/gcc/testsuite/g++.dg/cpp0x/noexcept36.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
[Bug libstdc++/89740] reading from cin & writing to cout sync_with_stdio(false) has race conditions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89740 --- Comment #4 from bert hubert --- I did a longer writeup here, where I tentatively conclude this is not a bug, just highly unfortunate: https://ds9a.nl/articles/posts/iostreams-unexpected/
[Bug libstdc++/52114] SFINAE out the rvalue iostream operators to give better error messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52114 Ville Voutilainen changed: What|Removed |Added CC||ville.voutilainen at gmail dot com --- Comment #13 from Ville Voutilainen --- This bug has been fixed, we do nowadays SFINAE in these return types.
[Bug fortran/85797] ICE in gfc_element_size, at fortran/target-memory.c:126
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85797 Harald Anlauf changed: What|Removed |Added CC||anlauf at gmx dot de --- Comment #3 from Harald Anlauf --- Patch submitted: https://gcc.gnu.org/ml/fortran/2019-03/msg00099.html
[Bug target/89746] New: powerpc-none-eabi-gcc emits code using stfiwx to misaligned address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89746
Bug ID: 89746
Summary: powerpc-none-eabi-gcc emits code using stfiwx to
misaligned address
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: davem at devkitpro dot org
Target Milestone: ---
The following code produces an alignment exception on powerpc 750 and I presume
on other powerpc ISAs where unaligned floating point is not allowed.
typedef struct
{
int i;
short x, y, z;
} foo;
void bar(foo *p, float f)
{
int d = f;
p->y = d>>16;
p->z = d&0x;
}
file"stfiwx-test.c"
.section".text"
.align 2
.globl bar
.type bar, @function
bar:
.LFB0:
.cfi_startproc
fctiwz %f1,%f1
addi %r3,%r3,6
stfiwx %f1,0,%r3
blr
.cfi_endproc
.LFE0:
.size bar, .-bar
compiling with -mstrict-align generates working code
.file "stfiwx-test.c"
.section".text"
.align 2
.globl bar
.type bar, @function
bar:
.LFB0:
.cfi_startproc
stwu %r1,-16(%r1)
.cfi_def_cfa_offset 16
fctiwz %f1,%f1
addi %r9,%r1,8
stfiwx %f1,0,%r9
lwz %r9,8(%r1)
srawi %r10,%r9,16
sth %r9,8(%r3)
sth %r10,6(%r3)
addi %r1,%r1,16
.cfi_def_cfa_offset 0
blr
.cfi_endproc
.LFE0:
.size bar, .-bar
[Bug target/89746] powerpc-none-eabi-gcc emits code using stfiwx to misaligned address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89746 --- Comment #1 from Andrew Pinski --- I don't think this is directly an issue. If you don't want unaligned accesses from happening and your "kernel" does not support unaligned fix ups, then you need to use -mstrict-align .
[Bug libfortran/89747] New: valgrind error in gfc_match_decl_type_spec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89747 Bug ID: 89747 Summary: valgrind error in gfc_match_decl_type_spec Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- From this configure line: ../trunk/configure --prefix=/home/dcb/gcc/results.269700.valgrind \ --disable-multilib \ --disable-werror \ --enable-checking=valgrind \ --enable-languages=ada,c,c++,fortran with revision 269700 $ svn info Path: . Working Copy Root Path: /home/dcb/gcc/trunk URL: svn://gcc.gnu.org/svn/gcc/trunk Relative URL: ^/trunk Repository Root: svn://gcc.gnu.org/svn/gcc Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4 Revision: 269700 Node Kind: directory Schedule: normal Last Changed Author: jakub Last Changed Rev: 269700 Last Changed Date: 2019-03-15 08:00:46 + (Fri, 15 Mar 2019) I got $ egrep "^==|^Config" mk.out | more ... Configuring in x86_64-pc-linux-gnu/libsanitizer Configuring in x86_64-pc-linux-gnu/libvtv Configuring in x86_64-pc-linux-gnu/libitm Configuring in x86_64-pc-linux-gnu/libgfortran ==9649== Conditional jump or move depends on uninitialised value(s) ==9649==at 0x628358: gfc_match_decl_type_spec(gfc_typespec*, int) (decl.c:40 47) ==9649==by 0x6297EC: gfc_match_data_decl() (decl.c:5950) ==9649==by 0x688540: match_word (parse.c:65) ==9649==by 0x688540: decode_statement() (parse.c:376)
[Bug target/89746] powerpc-none-eabi-gcc emits code using stfiwx to misaligned address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89746 --- Comment #2 from Segher Boessenkool --- (This is on a PowerPC 750). The compiler makes an unaligned store for this, because it knows no better than it is just a SImode store: d_5 = (int) f_4(D); _10 = (unsigned int) d_5; MEM[(short int *)p_7(D) + 6B] = _10; and *normal* unaligned stores of SImode are just fine -- they just cause an extra access if crossing an 8B boundary. OTOH, floating point load/store cause a misalignment interrupt if unaligned.
[Bug c++/41958] [c++0x] bogus variadic partial ordering code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41958 stinkingmadgod at gmail dot com changed: What|Removed |Added CC||stinkingmadgod at gmail dot com --- Comment #11 from stinkingmadgod at gmail dot com --- DR1395 made it in C++17. template int f(T*...); // #1 template int f(const T&); // #2 f((int*)0); // Should select #1 past C++17, should be ambiguous prior C++17. // Selects #2 instead. This is still the behaviour for trunk https://godbolt.org/z/ucAUHw
[Bug tree-optimization/89748] New: missing _FORTIFY_SOURCE protection due to stpcpy folding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89748
Bug ID: 89748
Summary: missing _FORTIFY_SOURCE protection due to stpcpy
folding
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
When _FORTIFY_SOURCE is defined GCC instruments the string concatenation in g()
against buffer overflow as expected.
But as a result of folding chained stpcpy calls to memcpy, GCC fails to do the
same instrumentation in the equivalent (but more efficient) code in h(). The
buffer overflow is only detected "by accident" by the -Warray-bounds warning in
gimple-ssa-warn-restrict.c.
$ cat t.c && gcc -D_FORTIFY_SOURCE=2 -O2 -S -Wall -fdump-tree-lower=/dev/stdout
t.c
#include
void f (void*);
void g (void)
{
char a[8];
strcat (strcpy (a, "12345678"), "abcdefgh");
f (a);
}
void h (void)
{
char a[8];
stpcpy (stpcpy (a, "12345678"), "abcdefgh");
f (a);
}
;; Function g (g, funcdef_no=11, decl_uid=2153, cgraph_uid=12, symbol_order=11)
g ()
{
char a[8];
try
{
_1 = strcpy (&a, "12345678");
strcat (_1, "abcdefgh");
f (&a);
}
finally
{
a = {CLOBBER};
}
return;
}
;; Function strcpy (, funcdef_no=6, decl_uid=887, cgraph_uid=7,
symbol_order=6)
__attribute__((artificial, gnu_inline, always_inline, leaf, nothrow))
strcpy (char * restrict __dest, const char * restrict __src)
{
char * D.2161;
_1 = __builtin_object_size (__dest, 1);
D.2161 = __builtin___strcpy_chk (__dest, __src, _1);
goto ;
:
return D.2161;
}
;; Function strcat (, funcdef_no=9, decl_uid=881,
cgraph_uid=10, symbol_order=9)
__attribute__((artificial, gnu_inline, always_inline, leaf, nothrow))
strcat (char * restrict __dest, const char * restrict __src)
{
char * D.2163;
_1 = __builtin_object_size (__dest, 1);
D.2163 = __builtin___strcat_chk (__dest, __src, _1);
goto ;
:
return D.2163;
}
;; Function h (h, funcdef_no=12, decl_uid=2157, cgraph_uid=13, symbol_order=12)
h ()
{
char a[8];
try
{
__builtin_memcpy (&a, "12345678", 9);
_1 = &a + 8;
__builtin_memcpy (_1, "abcdefgh", 9);
f (&a);
}
finally
{
a = {CLOBBER};
}
return;
}
In file included from /usr/include/string.h:494,
from t.c:1:
In function ‘strcpy’,
inlined from ‘g’ at t.c:7:3:
/usr/include/bits/string_fortified.h:90:10: warning: ‘__builtin___memcpy_chk’
forming offset 9 is out of the bounds [0, 8] of object ‘a’ with type ‘char[8]’
[-Warray-bounds]
90 | return __builtin___strcpy_chk (__dest, __src, __bos (__dest));
| ^~
t.c: In function ‘g’:
t.c:6:8: note: ‘a’ declared here
6 | char a[8];
|^
In file included from /usr/include/string.h:494,
from t.c:1:
In function ‘strcat’,
inlined from ‘g’ at t.c:7:3:
/usr/include/bits/string_fortified.h:128:10: warning: ‘__builtin___memcpy_chk’
writing 9 bytes into a region of size 0 overflows the destination
[-Wstringop-overflow=]
128 | return __builtin___strcat_chk (__dest, __src, __bos (__dest));
| ^~
t.c: In function ‘h’:
cc1: warning: ‘__builtin_memcpy’ forming offset 9 is out of the bounds [0, 8]
of object ‘a’ with type ‘char[8]’ [-Warray-bounds]
t.c:13:8: note: ‘a’ declared here
13 | char a[8];
|^
t.c:14:3: warning: ‘__builtin_memcpy’ forming offset [9, 17] is out of the
bounds [0, 8] of object ‘a’ with type ‘char[8]’ [-Warray-bounds]
14 | stpcpy (stpcpy (a, "12345678"), "abcdefgh");
| ^~~
t.c:13:8: note: ‘a’ declared here
13 | char a[8];
|^
[Bug tree-optimization/89748] missing _FORTIFY_SOURCE protection due to stpcpy folding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89748 --- Comment #1 from Andrew Pinski --- Isn't the bug is that glibc does not include a fortified version of stpcpy?
[Bug tree-optimization/89749] New: Very odd vector constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89749
Bug ID: 89749
Summary: Very odd vector constructor
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
Target Milestone: ---
[hjl@gnu-cfl-2 pr88828]$ cat i1.i
typedef short __v8hi __attribute__ ((__vector_size__ (16)));
typedef long long int __m128i __attribute__ ((__vector_size__ (16),
__may_alias__));
__m128i
foo (__m128i __A)
{
return (__m128i) (__v8hi) { ((__v8hi)__A)[0], ((__v8hi)__A)[1],
((__v8hi)__A)[2], ((__v8hi)__A)[3],
((__v8hi)__A)[4], ((__v8hi)__A)[5],
((__v8hi)__A)[6], ((__v8hi)__A)[7] };
}
[hjl@gnu-cfl-2 pr88828]$ gcc -S -O2 i2.i
[hjl@gnu-cfl-2 pr88828]$ cat i2.s
.file "i2.i"
.text
.p2align 4,,15
.globl foo
.type foo, @function
foo:
.LFB1:
.cfi_startproc
pextrw $3, %xmm0, %edx
pextrw $2, %xmm0, %eax
pextrw $6, %xmm0, %ecx
salq$16, %rdx
pextrw $0, %xmm0, %esi
orq %rax, %rdx
pextrw $1, %xmm0, %eax
salq$16, %rdx
orq %rax, %rdx
pextrw $7, %xmm0, %eax
salq$16, %rax
salq$16, %rdx
orq %rcx, %rax
pextrw $5, %xmm0, %ecx
orq %rsi, %rdx
salq$16, %rax
movq%rdx, -24(%rsp)
orq %rcx, %rax
pextrw $4, %xmm0, %ecx
salq$16, %rax
orq %rcx, %rax
movq%rax, -16(%rsp)
movdqa -24(%rsp), %xmm0
ret
.cfi_endproc
I am expecting an empty function body.
[Bug target/89750] New: Wrong code for _mm_comi_round_ss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89750
Bug ID: 89750
Summary: Wrong code for _mm_comi_round_ss
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: ubizjak at gmail dot com
Target Milestone: ---
Target: i386, x86-64
[hjl@gnu-cfl-2 pr86444]$ cat b.c
#include
__m128 x, y;
void init_regs()
{
x = _mm_set_ps(1.0,1.0,1.0,1.0);
y = _mm_set_ps(2.0,2.0,2.0,2.0);
}
int
avx512f_test (void)
{
return _mm_comi_round_ss (x, y, _CMP_LT_OS, _MM_FROUND_NO_EXC);
}
int main()
{
init_regs();
if (!avx512f_test())
__builtin_abort ();
return 0;
}
[hjl@gnu-cfl-2 pr86444]$ gcc -O2 -mavx512f b.c
[hjl@gnu-cfl-2 pr86444]$ ./sde -- ./a.out
Aborted
[hjl@gnu-cfl-2 pr86444]$ clang -O2 -mavx512f b.c
[hjl@gnu-cfl-2 pr86444]$ ./sde -- ./a.out
[hjl@gnu-cfl-2 pr86444]$
[Bug target/89750] Wrong code for _mm_comi_round_ss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89750
--- Comment #1 from H.J. Lu ---
ix86_expand_sse_comi_round has
/* See avxintrin.h for values. */
enum rtx_code comi_comparisons[32] =
{
UNEQ, GT, GE, UNORDERED, LTGT, UNLE, UNLT, ORDERED, UNEQ, UNLT,
UNLE, LT, LTGT, GE, GT, LT, UNEQ, GT, GE, UNORDERED, LTGT, UNLE,
UNLT, ORDERED, UNEQ, UNLT, UNLE, LT, LTGT, GE, GT, LT
};
which looks wrong for
#define _CMP_EQ_OQ 0x00
#define _CMP_LT_OS 0x01
#define _CMP_LE_OS 0x02
#define _CMP_UNORD_Q0x03
#define _CMP_NEQ_UQ 0x04
#define _CMP_NLT_US 0x05
#define _CMP_NLE_US 0x06
#define _CMP_ORD_Q 0x07
#define _CMP_EQ_UQ 0x08
#define _CMP_NGE_US 0x09
#define _CMP_NGT_US 0x0a
#define _CMP_FALSE_OQ 0x0b
#define _CMP_NEQ_OQ 0x0c
#define _CMP_GE_OS 0x0d
#define _CMP_GT_OS 0x0e
#define _CMP_TRUE_UQ0x0f
#define _CMP_EQ_OS 0x10
#define _CMP_LT_OQ 0x11
#define _CMP_LE_OQ 0x12
#define _CMP_UNORD_S0x13
#define _CMP_NEQ_US 0x14
#define _CMP_NLT_UQ 0x15
#define _CMP_NLE_UQ 0x16
#define _CMP_ORD_S 0x17
#define _CMP_EQ_US 0x18
#define _CMP_NGE_UQ 0x19
#define _CMP_NGT_UQ 0x1a
#define _CMP_FALSE_OS 0x1b
#define _CMP_NEQ_OS 0x1c
#define _CMP_GE_OQ 0x1d
#define _CMP_GT_OQ 0x1e
#define _CMP_TRUE_US0x1f
[Bug tree-optimization/89749] Very odd vector constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89749 Marc Glisse changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2019-03-18 Ever confirmed|0 |1 --- Comment #1 from Marc Glisse --- simplify_vector_constructor is supposed to handle this, but doesn't because it is scared by the mix between a vector of short and a vector of long long. This check is probably too strict.
