[Bug c/70257] #line incorrectly handled in error messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70257 --- Comment #3 from Eric Gallager --- (In reply to Manuel López-Ibáñez from comment #2) > I think this is a dup of bug 79106. > ...or possibly the other way around? Since that one is newer... > The caret line is printed by reopening the file and counting 3 lines because > the line directive is believed by GCC to point to the actual source code.
[Bug c++/92268] Constraint normalization substitutes parameter too early
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92268
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #4 from Jason Merrill ---
Smaller example:
template concept Two = true;
template concept One = Two;
template concept Zero = requires
{
{ T() } -> One;
};
template
void f() requires Zero;
template
void f(...);
int main()
{
f();
}
[Bug target/82459] AVX512BW instruction costs: vpmovwb is 2 uops on Skylake and not always worth using vs. vpack + vpermq lane-crossing fixup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82459 Peter Cordes changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=89346 Summary|AVX512F instruction costs: |AVX512BW instruction costs: |vmovdqu8 stores may be an |vpmovwb is 2 uops on |extra uop, and vpmovwb is 2 |Skylake and not always |uops on Skylake and not |worth using vs. vpack + |always worth using |vpermq lane-crossing fixup --- Comment #5 from Peter Cordes --- Turns out vmovdqu8 with no masking doesn't cost an extra uop. IACA was wrong, and Agner Fog's results were *only* for the masked case. The only downside of that is the code-size cost of using EVEX load/store instructions instead of AVX2 VEX. That's bug 89346 https://www.uops.info/table.html confirms that SKX non-masked vmovdqu8 load and store are both single uop. (Or the usual micro-fused store-address + store-data). https://www.uops.info/html-tp/SKX/VMOVDQU8_ZMM_M512-Measurements.html https://www.uops.info/html-tp/SKX/VMOVDQU8_M512_ZMM-Measurements.html And between registers it can be eliminated if there's no masking. But *with* masking, as a load it's a micro-fused load+ALU uop, and as a masked store it's just a normal store uop for xmm and ymm. But zmm masked store is 5 uops (micro-fused to 4 front-end uops)! (Unlike vmovdqu16 or 32 masked stores which are efficient even for zmm). https://www.uops.info/html-tp/SKX/VMOVDQU8_M512_K_ZMM-Measurements.html uops.info's table also shows us that IACA3.0 is wrong about vmovdqu8 as an *unmasked* ZMM store: IACA thinks that's also 5 uops. Retitling this bug report since that part was based on Intel's bogus data, not real testing. vpmovwb is still 2 uops, and current trunk gcc still uses 2x vpmovwb + vinserti64x4 for ZMM auto-vec. -mprefer-vector-width=512 is not the default, but people may enable it in code that heavily uses 512-bit vectors. YMM auto-vec is unchanged since previous comments: we do get vpackusbw + vpermq, but an indexed addressing mode defeats micro-fusion. And we have redundant VPAND after shifting. --- For icelake-client/server (AVX512VBMI) GCC is using vpermt2b, but it doesn't fold the shifts into the 2-source byte shuffle. (vpermt2b has 5c latency and 2c throughput on ICL, so probably its uop count is the same as uops.info measured for CannonLake: 1*p05 + 2*p5. Possible 2x 1-uop vpermb with merge-masking for the 2nd into the first would work better.) IceLake vpmovwb ymm,zmm is still 2-cycle throughput, 4-cycle latency, so probably still 2 uops.
[Bug c++/79419] [concepts] Explicit specialization of constrained member template: ICE in set_constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79419 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #2 from Jason Merrill --- This is still breaken. During CWG discussion of this issue in Cologne I said that I thought that for this matching we need to do partial instantiation of the associated constraints of the in-class declaration in order to compare it to the specialization.
[Bug c++/92273] concepts check failed: std::vector iterator and std::string iterator are not contiguous iterator.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92273 fdlbxtqi changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from fdlbxtqi --- The browser generates the same ticket for twice. *** This bug has been marked as a duplicate of bug 92272 ***
[Bug c++/92272] concepts check failed: std::vector iterator and std::string iterator are not contiguous iterator.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92272 --- Comment #1 from fdlbxtqi --- *** Bug 92273 has been marked as a duplicate of this bug. ***
[Bug c++/92272] New: concepts check failed: std::vector iterator and std::string iterator are not contiguous iterator.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92272
Bug ID: 92272
Summary: concepts check failed: std::vector iterator and
std::string iterator are not contiguous iterator.
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: euloanty at live dot com
CC: jwakely at redhat dot com
Target Milestone: ---
Created attachment 47128
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47128=edit
vector::iterator contiguous_iterator concepts fail
Thank you for your hard work for concepts and ranges. However, the
std::contiguous_iterator concepts failed for checking std::vector and
std::string. I did the same on Visual C++ Preview. VC works (although vc does
not support concept auto).
cqwrteur@DESKTOP-7H7UHQ9:/mnt/d$ g++ -o a a.cc -O2 -std=c++2a -fconcepts
a.cc: In function ‘int main()’:
a.cc:11:53: error: deduced initializer does not satisfy placeholder constraints
11 | std::contiguous_iterator auto vec_iter(vec.cbegin());
| ^
a.cc:11:53: note: constraints not satisfied
In file included from a.cc:1:
/usr/local/include/c++/10.0.0/concepts:67:28: note:
‘std::contiguous_iterator_tag’ is not a base of
‘std::random_access_iterator_tag’
67 | concept derived_from = __is_base_of(_Base, _Derived)
|^
a.cc:15:53: error: deduced initializer does not satisfy placeholder constraints
15 | std::contiguous_iterator auto str_iter(str.cbegin());
| ^
a.cc:15:53: note: constraints not satisfied
In file included from a.cc:1:
/usr/local/include/c++/10.0.0/concepts:67:28: note:
‘std::contiguous_iterator_tag’ is not a base of
‘std::random_access_iterator_tag’
67 | concept derived_from = __is_base_of(_Base, _Derived)
|^
cqwrteur@DESKTOP-7H7UHQ9:/mnt/d$ gcc --version
gcc (cqwrteur) 10.0.0 20191029 (experimental)
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
#include
#include
#include
#include
#include
#include
int main()
{
std::vector vec;
std::contiguous_iterator auto vec_iter(vec.cbegin());
std::string_view sv;
std::contiguous_iterator auto sv_iter(sv.cbegin());
std::string str;
std::contiguous_iterator auto str_iter(str.cbegin());
std::deque dq;
std::random_access_iterator auto dq_iter(dq.cbegin());
static_assert(!std::contiguous_iterator,"deque
iterator should not be a contiguous_iterator");
}
[Bug c++/92273] New: concepts check failed: std::vector iterator and std::string iterator are not contiguous iterator.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92273
Bug ID: 92273
Summary: concepts check failed: std::vector iterator and
std::string iterator are not contiguous iterator.
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: euloanty at live dot com
CC: jwakely at redhat dot com
Target Milestone: ---
Created attachment 47127
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47127=edit
vector::iterator contiguous_iterator concepts fail
Thank you for your hard work for concepts and ranges. However, the
std::contiguous_iterator concepts failed for checking std::vector and
std::string. I did the same on Visual C++ Preview. VC works (although vc does
not support concept auto).
cqwrteur@DESKTOP-7H7UHQ9:/mnt/d$ g++ -o a a.cc -O2 -std=c++2a -fconcepts
a.cc: In function ‘int main()’:
a.cc:11:53: error: deduced initializer does not satisfy placeholder constraints
11 | std::contiguous_iterator auto vec_iter(vec.cbegin());
| ^
a.cc:11:53: note: constraints not satisfied
In file included from a.cc:1:
/usr/local/include/c++/10.0.0/concepts:67:28: note:
‘std::contiguous_iterator_tag’ is not a base of
‘std::random_access_iterator_tag’
67 | concept derived_from = __is_base_of(_Base, _Derived)
|^
a.cc:15:53: error: deduced initializer does not satisfy placeholder constraints
15 | std::contiguous_iterator auto str_iter(str.cbegin());
| ^
a.cc:15:53: note: constraints not satisfied
In file included from a.cc:1:
/usr/local/include/c++/10.0.0/concepts:67:28: note:
‘std::contiguous_iterator_tag’ is not a base of
‘std::random_access_iterator_tag’
67 | concept derived_from = __is_base_of(_Base, _Derived)
|^
cqwrteur@DESKTOP-7H7UHQ9:/mnt/d$ gcc --version
gcc (cqwrteur) 10.0.0 20191029 (experimental)
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
#include
#include
#include
#include
#include
#include
int main()
{
std::vector vec;
std::contiguous_iterator auto vec_iter(vec.cbegin());
std::string_view sv;
std::contiguous_iterator auto sv_iter(sv.cbegin());
std::string str;
std::contiguous_iterator auto str_iter(str.cbegin());
std::deque dq;
std::random_access_iterator auto dq_iter(dq.cbegin());
static_assert(!std::contiguous_iterator,"deque
iterator should not be a contiguous_iterator");
}
[Bug middle-end/92263] [10 Regression] ICE in commit_one_edge_insertion, at cfgrtl.c:2087 since r270758
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92263 --- Comment #5 from Jim Wilson --- The patch adds a RISC-V movcc pattern. This causes toplev.c to enable flag_tree_cselim. This optimization pass creates a complex long double conditional move via a phi node. complex long double cstore_31; ... [local count: 27903866]: cstore_30 = MEM [(void *)_8]; [local count: 55807731]: # cstore_31 = PHI <__complex__ (0.0, 0.0)(4), cstore_30(5)> MEM [(void *)_8] = cstore_31; When we try to convert gimple to rtl, eliminate_phi calls insert_value_copy_on_edge for the 32-byte long double 0 value. The constant then gets forced to memory, and we end up calling emit_block_move with BLOCK_OP_NO_LIBCALL, which ends up emitting a loop to do the memory to memory copy. Then later in commit_one_edge_insertion we split the edge, insert the code containing the loop, and then trigger an abort because the last instruction inserted is the loop back branch. I don't see where the RISC-V port did anything wrong. The load hoisting code is checking the movcc optab to see if the target supports the operation, but I don't see anything obvious like that in the cselim pass. The only obvious fix I see in the RISC-V back end is to modify riscv_expand_block_move to emit inline non-loop code for a 32-byte memory to memory copy, even when optimizing for size, which I'd rather not do. Maybe it can be fixed in commit_one_edge_insertion by allowing conditional branches but not unconditional branches, but it isn't clear why this is refusing to allow branches here in the first place. I will have to look at other targets to see why they aren't failing.
[Bug c++/92271] for consistency, __is_same_as should be named __is_same
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92271 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
[Bug c++/92201] [9/10 Regression] ICE: ‘verify_gimple’ failed with -std=c++2a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92201 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jakub Jelinek --- Should be fixed now.
[Bug c++/92270] Non-const ref treated as const-ref in the compiler.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92270 Jonathan Wakely changed: What|Removed |Added Resolution|FIXED |INVALID
[Bug c++/92270] Non-const ref treated as const-ref in the compiler.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92270
Yuki Wada changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |FIXED
--- Comment #1 from Yuki Wada ---
I'm really sorry, this is a bug in my code.
The code above causes hard error by deducing lambda return type.
I fixed my code by giving the lambda an explicit return type rather than a
deduced return type:
instance.fn([](auto& i) -> void {
i = 0;
});
[Bug c++/92271] for consistency, __is_same_as should be named __is_same
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92271 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-10-29 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- FWIW libstdc++ has only just started using __is_same_as and could very easily be changed to use __is_same. It would actually simplify the code if GCC and Clang used the same name.
[Bug driver/47785] GCC with -flto does not pass -Wa/-Xassembler options to the assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47785 --- Comment #16 from H.J. Lu --- (In reply to H.J. Lu from comment #15) > We need to also handle -Xassembler? Since -Wa, doesn't work with comma in > assembler options, like -mfoo=foo1,foo2, one needs to use > > -Xassembler -mfoo=foo1,foo2 > > to pass -mfoo=foo1,foo2 to assembler. We may also have -Xassembler -mfoo=foo1,foo2 -Wa,-mbar
[Bug c++/92271] New: for consistency, __is_same_as should be named __is_same
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92271 Bug ID: 92271 Summary: for consistency, __is_same_as should be named __is_same Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: richard-gccbugzilla at metafoo dot co.uk Target Milestone: --- The convention for type trait builtins adopted by essentially every C++ compiler vendor is to expose std::SOME_TRAIT::value as __SOME_TRAIT(A, B, C). GCC violates this convention in one case: std::is_same::value is exposed as __is_same_as(A, B) rather than as __is_same(A, B). For consistency and code portability, I suggest that GCC accepts __is_same as a synonym for __is_same_as. (FWIW, Clang uses the name __is_same here, but will soon accept __is_same_as for GCC compatibility.)
[Bug c++/92201] [9/10 Regression] ICE: ‘verify_gimple’ failed with -std=c++2a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92201 --- Comment #5 from Jakub Jelinek --- Author: jakub Date: Tue Oct 29 21:09:21 2019 New Revision: 277594 URL: https://gcc.gnu.org/viewcvs?rev=277594=gcc=rev Log: PR c++/92201 * cp-gimplify.c (cp_gimplify_expr): If gimplify_to_rvalue changes the function pointer type, re-add cast to the original one. * g++.dg/other/pr92201.C: New test. Added: branches/gcc-9-branch/gcc/testsuite/g++.dg/other/pr92201.C Modified: branches/gcc-9-branch/gcc/cp/ChangeLog branches/gcc-9-branch/gcc/cp/cp-gimplify.c branches/gcc-9-branch/gcc/testsuite/ChangeLog
[Bug c++/90998] [9 Regression] ICE (segfault) in gcc/cp/call.c compare_ics() with -std=c++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90998 Marek Polacek changed: What|Removed |Added Summary|[9/10 Regression] ICE |[9 Regression] ICE |(segfalut) in gcc/cp/call.c |(segfault) in gcc/cp/call.c |compare_ics() with |compare_ics() with |-std=c++17 |-std=c++17 --- Comment #5 from Marek Polacek --- Fixed on trunk so far.
[Bug c++/90998] [9/10 Regression] ICE (segfalut) in gcc/cp/call.c compare_ics() with -std=c++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90998 --- Comment #4 from Marek Polacek --- Author: mpolacek Date: Tue Oct 29 21:06:21 2019 New Revision: 277593 URL: https://gcc.gnu.org/viewcvs?rev=277593=gcc=rev Log: PR c++/90998 - ICE with copy elision in init by ctor and -Wconversion. After r269667 which introduced joust_maybe_elide_copy, in C++17 we can elide a constructor if it uses a conversion function that returns a prvalue, and use the conversion function in its stead. This eliding means that if we have a candidate that previously didn't have ->second_conv, it can have it after the elision. This confused the -Wconversion warning because it was assuming that if cand1->second_conv is non-null, so is cand2->second_conv. Here cand1->second_conv was non-null but cand2->second_conv remained null, so it crashed in compare_ics. I checked with clang that both compilers call A::operator B() in C++17 and B::B(A const &) otherwise. * call.c (joust): Don't attempt to warn if ->second_conv is null. * g++.dg/cpp0x/overload-conv-4.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/overload-conv-4.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/testsuite/ChangeLog
[Bug c++/92201] [9/10 Regression] ICE: ‘verify_gimple’ failed with -std=c++2a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92201 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Tue Oct 29 20:58:47 2019 New Revision: 277592 URL: https://gcc.gnu.org/viewcvs?rev=277592=gcc=rev Log: PR c++/92201 * cp-gimplify.c (cp_gimplify_expr): If gimplify_to_rvalue changes the function pointer type, re-add cast to the original one. * g++.dg/other/pr92201.C: New test. Added: trunk/gcc/testsuite/g++.dg/other/pr92201.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-gimplify.c trunk/gcc/testsuite/ChangeLog
[Bug c++/91548] [10 Regression] Regression in constexpr evaluation of std::array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91548 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Marek Polacek --- Fixed.
[Bug c++/91548] [10 Regression] Regression in constexpr evaluation of std::array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91548 --- Comment #10 from Marek Polacek --- Author: mpolacek Date: Tue Oct 29 20:34:43 2019 New Revision: 277591 URL: https://gcc.gnu.org/viewcvs?rev=277591=gcc=rev Log: PR c++/91548 - fix detecting modifying const objects for ARRAY_REF. This fixes a bogus "modifying a const object" error for an array that actually isn't declared const. The problem was how I handled ARRAY_REFs here; we shouldn't look at the ARRAY_REF itself, but at the array its accessing. * constexpr.c (cxx_eval_store_expression): Don't call modifying_const_object_p for ARRAY_REF. * g++.dg/cpp1y/constexpr-tracking-const15.C: New test. * g++.dg/cpp1y/constexpr-tracking-const16.C: New test. * g++.dg/cpp1z/constexpr-tracking-const1.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-tracking-const15.C trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-tracking-const16.C trunk/gcc/testsuite/g++.dg/cpp1z/constexpr-tracking-const1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/constexpr.c trunk/gcc/testsuite/ChangeLog
[Bug target/65342] [7/8 Regression] powerpc-darwin9 m64 code-gen error exposed by r210201
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65342 --- Comment #34 from Iain Sandoe --- Author: iains Date: Tue Oct 29 20:20:23 2019 New Revision: 277590 URL: https://gcc.gnu.org/viewcvs?rev=277590=gcc=rev Log: [Darwin, PPC] Fix PR 65342. The current Darwin load/store lo_sum patterns have neither predicate nor constraint. This means that most parts of the backend, which rely on recog() to validate the rtx, can produce invalid combinations/selections. For 32bit cases this isn't a problem since we can load/store to unaligned addresses using D-mode insns. Conversely, for 64bit instructions that use DS mode, this can manifest as assemble errors (for an assembler that checks the LO14 relocations), or as crashes caused by wrong offsets (or worse, wrong content for the two LSBs). What we want to check for Y on Darwin is: - that the alignment of the Symbols' target is sufficient for DS mode - that the offset is suitable for DS mode. (while looking through the Mach-O PIC unspecs). So, the patch removes the Darwin-specific lo_sum patterns (we begin using the movdi_internal64 patterns). We also we need to extend the handling of the mem_operand_gpr constraint to allow looking through Mach-O PIC UNSPECs in the lo_sum cases. 2019-10-29 Iain Sandoe Backport from mainline 2019-10-17 Iain Sandoe PR target/65342 * config/rs6000/darwin.md (movdi_low, movsi_low_st): Delete. (movdi_low_st): Delete. * config/rs6000/rs6000.c (darwin_rs6000_legitimate_lo_sum_const_p): New. (mem_operand_gpr): Validate Mach-O LO_SUM cases separately. * config/rs6000/rs6000.md (movsi_low): Delete. Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/config/rs6000/darwin.md branches/gcc-7-branch/gcc/config/rs6000/rs6000.c branches/gcc-7-branch/gcc/config/rs6000/rs6000.md
[Bug libstdc++/91495] std::transform_reduce with unary op is implemented in the parallel case but not the basic case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91495 --- Comment #5 from Jonathan Wakely --- No (the parallel versions are in those branches either).
[Bug target/67183] Darwin stub vs. non_lazy pointer ordering incompatible with clang assembler.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67183 --- Comment #8 from Iain Sandoe --- Author: iains Date: Tue Oct 29 20:16:28 2019 New Revision: 277587 URL: https://gcc.gnu.org/viewcvs?rev=277587=gcc=rev Log: [Darwin, machopic] Fix for 67183 When we're using the LLVM-based assembler (the default on modern Darwin) the ordering of stubs and non-lazy symbol pointers is important. Interleaving the output (current GCC behaviour) leads to crashes which prevents us from building code with symbol stubs. To resolve this, we order the output of stubs and symbol indirections: 1. Any indirections in the data section 2. Symbol stubs. 3. Non-lazy symbol pointers. At present, we still emit LTO sections after these. 2019-10-29 Iain Sandoe Backport from mainline 2019-10-12 Iain Sandoe PR target/67183 * config/darwin.c (machopic_indirection): New field to flag non-lazy-symbol-pointers in the data section. (machopic_indirection_name): Compute if an indirection should appear in the data section. (machopic_output_data_section_indirection): New callback split from machopic_output_indirection. (machopic_output_stub_indirection): Likewise. (machopic_output_indirection): Retain the code for non-lazy symbol pointers in their regular section. (machopic_finish): Use the new callbacks to order the indirection output. Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/config/darwin.c
[Bug target/59888] Darwin linker error "illegal text-relocation" with -shared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59888 --- Comment #22 from Iain Sandoe --- Author: iains Date: Tue Oct 29 20:05:05 2019 New Revision: 277584 URL: https://gcc.gnu.org/viewcvs?rev=277584=gcc=rev Log: [Darwin] Amend section for constants with relocations. Darwin's linker doesn't like text section relocations (they require special enabling). The Fortran FE, at least, seems to generate cases where the initialiser for a pointer constant can need a relocation. We can handle this by special-casing SECCAT_RODATA when the relocation is present by placing the constant in the .const_data section. 2019-10-29 Iain Sandoe Backport from mainline 2019-10-05 Iain Sandoe PR target/59888 * config/darwin.c (darwin_rodata_section): Add relocation flag, choose const_data section for constants with relocations. (machopic_select_section): Pass relocation flag to darwin_rodata_section (). Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/config/darwin.c
[Bug c++/92270] New: Non-const ref treated as const-ref in the compiler.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92270
Bug ID: 92270
Summary: Non-const ref treated as const-ref in the compiler.
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jostaberry.jam at gmail dot com
Target Milestone: ---
GCC rejects this valid code, but it can be compiled without "i = 0;".
And as expected, Overload #1 is selected.
=== CODE ===
#include
#include
template
struct test {
T value;
template
std::enable_if_t>
fn(F&& op) & { op(value); } // #1
template
std::enable_if_t>
fn(F&& op) const& { op(value); } // #2
};
template test(T) -> test;
int main() {
test instance{1};
instance.fn([](auto& i){
// error: cannot assign to variable 'i'
// with const-qualified type 'const int &'
i = 0;
});
}
= END CODE =
source>:24:11: error: cannot assign to variable 'i' with const-qualified type
'const int &'
i = 0;
~ ^
/opt/compiler-explorer/gcc-8.2.0/lib/gcc/x86_64-linux-gnu/8.2.0/../../../../include/c++/8.2.0/type_traits:2283:7:
note: in instantiation of function template specialization 'main()::(anonymous
class)::operator()' requested here
std::declval<_Fn>()(std::declval<_Args>()...)
^
/opt/compiler-explorer/gcc-8.2.0/lib/gcc/x86_64-linux-gnu/8.2.0/../../../../include/c++/8.2.0/type_traits:2294:24:
note: while substituting deduced template arguments into function template
'_S_test' [with _Fn = (lambda at :21:17) &&, _Args = (no value)]
typedef decltype(_S_test<_Functor, _ArgTypes...>(0)) type;
^
/opt/compiler-explorer/gcc-8.2.0/lib/gcc/x86_64-linux-gnu/8.2.0/../../../../include/c++/8.2.0/type_traits:2300:14:
note: in instantiation of template class 'std::__result_of_impl:21:17) &&, const int &>' requested here
: public __result_of_impl<
^
/opt/compiler-explorer/gcc-8.2.0/lib/gcc/x86_64-linux-gnu/8.2.0/../../../../include/c++/8.2.0/type_traits:2612:65:
note: in instantiation of template class 'std::__invoke_result<(lambda at
:21:17) &&, const int &>' requested here
struct __is_invocable_impl<_Result, _Ret, __void_t>
^
/opt/compiler-explorer/gcc-8.2.0/lib/gcc/x86_64-linux-gnu/8.2.0/../../../../include/c++/8.2.0/type_traits:2696:7:
note: during template argument deduction for class template partial
specialization '__is_invocable_impl<_Result, _Ret, __void_t >' [with _Result = std::__invoke_result<(lambda at
:21:17) &&, const int &>, _Ret = void]
: __is_invocable_impl<__invoke_result<_Fn, _ArgTypes...>, void>::type
^
/opt/compiler-explorer/gcc-8.2.0/lib/gcc/x86_64-linux-gnu/8.2.0/../../../../include/c++/8.2.0/type_traits:2696:7:
note: in instantiation of template class
'std::__is_invocable_impl:21:17) &&,
const int &>, void, void>' requested here
/opt/compiler-explorer/gcc-8.2.0/lib/gcc/x86_64-linux-gnu/8.2.0/../../../../include/c++/8.2.0/type_traits:2732:44:
note: in instantiation of template class 'std::is_invocable<(lambda at
:21:17) &&, const int &>' requested here
inline constexpr bool is_invocable_v = is_invocable<_Fn, _Args...>::value;
^
:13:27: note: in instantiation of variable template specialization
'std::is_invocable_v<(lambda at :21:17) &&, const int &>' requested
here
std::enable_if_t>
^
:21:14: note: while substituting deduced template arguments into
function template 'fn' [with F = (lambda at :21:17)]
instance.fn([](auto& i){
^
:21:26: note: variable 'i' declared const here
instance.fn([](auto& i){
~~^
1 error generated.
ASM generation compiler returned: 1
:24:11: error: cannot assign to variable 'i' with const-qualified type
'const int &'
i = 0;
~ ^
/opt/compiler-explorer/gcc-8.2.0/lib/gcc/x86_64-linux-gnu/8.2.0/../../../../include/c++/8.2.0/type_traits:2283:7:
note: in instantiation of function template specialization 'main()::(anonymous
class)::operator()' requested here
std::declval<_Fn>()(std::declval<_Args>()...)
^
/opt/compiler-explorer/gcc-8.2.0/lib/gcc/x86_64-linux-gnu/8.2.0/../../../../include/c++/8.2.0/type_traits:2294:24:
note: while substituting deduced template arguments into function template
'_S_test' [with _Fn = (lambda at :21:17) &&, _Args = (no value)]
typedef decltype(_S_test<_Functor, _ArgTypes...>(0)) type;
^
/opt/compiler-explorer/gcc-8.2.0/lib/gcc/x86_64-linux-gnu/8.2.0/../../../../include/c++/8.2.0/type_traits:2300:14:
note: in instantiation of template class 'std::__result_of_impl:21:17) &&, const int &>' requested
[Bug middle-end/92263] [10 Regression] ICE in commit_one_edge_insertion, at cfgrtl.c:2087 since r270758
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92263 --- Comment #4 from Jim Wilson --- OK, I get it now. You are using non-standard optimization options with a testsuite testcase. I can reproduce when I use your compiler options. I will take a look.
[Bug target/87243] FSF GCC needs to do something special (like using xcrun) on darwin18 to find system headers in SDK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87243 --- Comment #13 from Iain Sandoe --- Author: iains Date: Tue Oct 29 19:52:20 2019 New Revision: 277582 URL: https://gcc.gnu.org/viewcvs?rev=277582=gcc=rev Log: [Darwin] Pick up SDKROOT as the sysroot fallback. For compatibility with xcrun and the behaviour of the clang driver, make use of the setting of the SDKROOT environment variable when it is available. This applies to both finding headers and libraries (i.e. it is also passed to ld64). Priority: 1. User's command-line specified --sysroot= or -isysroot. 2. The SDKROOT variable when set, and validated. 3. Any sysroot provided by --with-sysroot= configuration parameter. SDKROOT is checked thus: 1. Presence. 2. That it starts with / (i.e. 'absolute'). 3. That it is not / only (since that's the default). 4. That it is readable by the process executing the driver. This is pretty much the same rule set as used by the clang driver. NOTE: (3) might turn out to be overly restrictive in the case that we have configured with --with-sysroot= and then we want to run on a system with an installation of the headers/libraries in /. We can revisit this if that turns out to be an important use-case. So one can do: xcrun --sdk macosx /path/to/gcc and that provides the SDK path as the sysroot to GCC as expected. CAVEAT: An unfortunate effect of the fact that gcc (and g++) are executables in the Xcode installation, which are found ahead of any such named in the $PATH PATH=/path/to/gcc/install:$PATH xcrun --sdk macosx gcc does *not* work, instead that executes the clang from the xcode/commmand line tools installation. PATH=/path/to/gcc/install:$PATH xcrun --sdk macosx x64_64-apple-darwinXX-gcc ... does work as expected, however. 2019-10-29 Iain Sandoe Backport from mainline 2019-10-03 Iain Sandoe PR target/87243 * config/darwin-driver.c (maybe_get_sysroot_from_sdkroot): New. (darwin_driver_init): Use the sysroot provided by SDKROOT when that is available and the user has not set one on the command line. Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/config/darwin-driver.c
[Bug sanitizer/92247] ‘__NR_open’ was not declared in this scope libsanitizer/sanitizer_common/sanitizer_linux compilation failed on ubuntu 18.04 WSL2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92247 --- Comment #9 from Andrew Pinski --- Yes SANITIZER_USES_CANONICAL_LINUX_SYSCALLS should be defined as 1 by default. The comment in front of the define there is incorrect for newer kernels which force the legacy system calls not be to defined (though they are still implemented). From the upstream source base: // The AArch64 and RISC-V linux ports use the canonical syscall set as // mandated by the upstream linux community for all new ports. Other ports // may still use legacy syscalls. That is why I said upstream is also broken and incorrect.
[Bug preprocessor/82176] Feature request: replace __FILE__ with file's basename instead its full name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82176 --- Comment #12 from f.hollerer at gmx dot net --- (In reply to Gregory Fuchedzhy from comment #10) > (In reply to f.hollerer from comment #8) > > To my understanding assert() uses __FILE__ and __LINE__. I would like to > > have a command line option which let __FILE__ expand to the last path > > component (the filename) instead of an invocation dependent full path of > > that file. > > If __FILE_NAME__ is implemented would adding -D__FILE__=__FILE_NAME__ solve > your particular usecase? Yes, but then I also have to add -Wno-builtin-macro-redefined otherwise the compiler will issue a warning. I think best match is the -ffile-prefix-map option jos...@codesourcery.com pointed me to.
[Bug preprocessor/82176] Feature request: replace __FILE__ with file's basename instead its full name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82176 --- Comment #11 from f.hollerer at gmx dot net --- (In reply to jos...@codesourcery.com from comment #9) > On Tue, 29 Oct 2019, f.hollerer at gmx dot net wrote: > > > This would: > > > > - shorten the output of assert() > > - minimize the image size due to shorter strings > > - make the build reproduceable as the output does not depend on the current > > working directory. > > Note that we have the -ffile-prefix-map / -fmacro-prefix-map / > -fdebug-prefix-map options you can use to specify a mapping from the > actual directory names used in the build to the names you want to appear > in the output. Thank you for pointing me to this options. I have to get a more recent compiler to try them, but according the documentation they should solve my problem.
[Bug sanitizer/92247] ‘__NR_open’ was not declared in this scope libsanitizer/sanitizer_common/sanitizer_linux compilation failed on ubuntu 18.04 WSL2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92247 --- Comment #8 from fdlbxtqi --- Line 211 #ifndef SANITIZER_USES_CANONICAL_LINUX_SYSCALLS # if defined(__aarch64__) && SANITIZER_LINUX # define SANITIZER_USES_CANONICAL_LINUX_SYSCALLS 1 # else # define SANITIZER_USES_CANONICAL_LINUX_SYSCALLS 0 # endif #endif https://github.com/gcc-mirror/gcc/blob/41d6b10e96a1de98e90a7c0378437c3255814b16/libsanitizer/sanitizer_common/sanitizer_platform.h I do not know why SANITIZER_USES_CANONICAL_LINUX_SYSCALLS is not defined. I think it is not because of the Linux kernel update or something since these changes were done one and a half years ago. The configure of GCC is clearly incorrect. I believe the problem is because of recent GCC updates that broke the entire compiler. The SANITIZER_USES_CANONICAL_LINUX_SYSCALLS should be defined by default for modern Linux kernel. #ifndef SANITIZER_USES_CANONICAL_LINUX_SYSCALLS # if defined(__aarch64__) && SANITIZER_LINUX # define SANITIZER_USES_CANONICAL_LINUX_SYSCALLS 1 # else # define SANITIZER_USES_CANONICAL_LINUX_SYSCALLS 0 # endif #endif
[Bug sanitizer/92247] ‘__NR_open’ was not declared in this scope libsanitizer/sanitizer_common/sanitizer_linux compilation failed on ubuntu 18.04 WSL2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92247 Andrew Pinski changed: What|Removed |Added Target|x86_64-linux-gnu, windows |x86_64-linux-gnu |subsystem for linux 2 | |(windows 10 build 19008)| Status|UNCONFIRMED |NEW Last reconfirmed||2019-10-29 Target Milestone|--- |10.0 Ever confirmed|0 |1 Severity|normal |blocker --- Comment #7 from Andrew Pinski --- It is still broken upstream too: https://github.com/llvm/llvm-project/blob/master/compiler-rt/lib/sanitizer_common/sanitizer_platform.h So it is not just GCC will break compiling but LLVM will also break :).
[Bug sanitizer/92247] ‘__NR_open’ was not declared in this scope libsanitizer/sanitizer_common/sanitizer_linux compilation failed on ubuntu 18.04 WSL2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92247 --- Comment #6 from fdlbxtqi --- I have examined the source code of the unistd.h in Microsoft WSL2. The same thing, these syscalls were removed as well. https://github.com/microsoft/WSL2-Linux-Kernel/blob/7fec2bd4a7fd7a952e3e5ea2202bef963aa4781d/include/uapi/asm-generic/unistd.h
[Bug middle-end/92263] [10 Regression] ICE in commit_one_edge_insertion, at cfgrtl.c:2087 since r270758
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92263 --- Comment #3 from Jim Wilson --- I did a cross compiler build and check yesterday using up-to-date sources and did not see this failure. I've been testing regularly. I did my build on an x86_64 Ubuntu 16.04 machine with gcc-5.4 as the system compiler. Maybe this depends on the compiler used for the build? Or the exact configure command?
[Bug c++/92268] Constraint normalization substitutes parameter too early
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92268 Andrew Sutton changed: What|Removed |Added CC||andrew.n.sutton at gmail dot com --- Comment #3 from Andrew Sutton --- > [02:40] but it looks like when we normalize the forward_iterator > constraint on the compound-requirement we're normalizing > forward_iterator, which is wrong -- we should be normalizing > forward_iterator, and then checking whether that's satisfied with iterator > [02:40] Andrew sent me a patch to improve handling of nested > requirements that I haven't looked at yet, it may help with this This patch doesn't touch that. We're definitely not normalizing that constraint at the point it appears. It's normalized w.r.t., substituted arguments in do_auto_deduction. I suppose the right thing to do is deduction vs. an unconstrained type, then satisfaction vs. result.
[Bug sanitizer/92247] ‘__NR_open’ was not declared in this scope libsanitizer/sanitizer_common/sanitizer_linux compilation failed on ubuntu 18.04 WSL2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92247 --- Comment #5 from fdlbxtqi --- https://github.com/torvalds/linux/commit/a0673fdbcd42105261646cd4f3447455b5854a32 It looks like all these system calls are removed in unistd.h in Linux kernel. /* * All syscalls below here should go away really, * these are provided for both review and as a porting * help for the C library version. * * Last chance: are any of these important enough to * enable by default? */ #ifdef __ARCH_WANT_SYSCALL_NO_AT #define __NR_open 1024 __SYSCALL(__NR_open, sys_open) #define __NR_link 1025 __SYSCALL(__NR_link, sys_link) #define __NR_unlink 1026 __SYSCALL(__NR_unlink, sys_unlink) #define __NR_mknod 1027 __SYSCALL(__NR_mknod, sys_mknod) #define __NR_chmod 1028 __SYSCALL(__NR_chmod, sys_chmod) #define __NR_chown 1029 __SYSCALL(__NR_chown, sys_chown) #define __NR_mkdir 1030 __SYSCALL(__NR_mkdir, sys_mkdir) #define __NR_rmdir 1031 __SYSCALL(__NR_rmdir, sys_rmdir) #define __NR_lchown 1032 __SYSCALL(__NR_lchown, sys_lchown) #define __NR_access 1033 __SYSCALL(__NR_access, sys_access) #define __NR_rename 1034 __SYSCALL(__NR_rename, sys_rename) #define __NR_readlink 1035 __SYSCALL(__NR_readlink, sys_readlink) #define __NR_symlink 1036 __SYSCALL(__NR_symlink, sys_symlink) #define __NR_utimes 1037 __SYSCALL(__NR_utimes, sys_utimes) #define __NR3264_stat 1038 __SC_3264(__NR3264_stat, sys_stat64, sys_newstat) #define __NR3264_lstat 1039 __SC_3264(__NR3264_lstat, sys_lstat64, sys_newlstat) #undef __NR_syscalls #define __NR_syscalls (__NR3264_lstat+1) #endif /* __ARCH_WANT_SYSCALL_NO_AT */ #ifdef __ARCH_WANT_SYSCALL_NO_FLAGS #define __NR_pipe 1040 __SYSCALL(__NR_pipe, sys_pipe) #define __NR_dup2 1041 __SYSCALL(__NR_dup2, sys_dup2) #define __NR_epoll_create 1042 __SYSCALL(__NR_epoll_create, sys_epoll_create) #define __NR_inotify_init 1043 __SYSCALL(__NR_inotify_init, sys_inotify_init) #define __NR_eventfd 1044 __SYSCALL(__NR_eventfd, sys_eventfd) #define __NR_signalfd 1045 __SYSCALL(__NR_signalfd, sys_signalfd) #undef __NR_syscalls #define __NR_syscalls (__NR_signalfd+1) #endif /* __ARCH_WANT_SYSCALL_NO_FLAGS */ #if (__BITS_PER_LONG == 32 || defined(__SYSCALL_COMPAT)) && \ defined(__ARCH_WANT_SYSCALL_OFF_T) #define __NR_sendfile 1046 __SYSCALL(__NR_sendfile, sys_sendfile) #define __NR_ftruncate 1047 __SYSCALL(__NR_ftruncate, sys_ftruncate) #define __NR_truncate 1048 __SYSCALL(__NR_truncate, sys_truncate) #define __NR_stat 1049 __SYSCALL(__NR_stat, sys_newstat) #define __NR_lstat 1050 __SYSCALL(__NR_lstat, sys_newlstat) #define __NR_fstat 1051 __SYSCALL(__NR_fstat, sys_newfstat) #define __NR_fcntl 1052 __SYSCALL(__NR_fcntl, sys_fcntl) #define __NR_fadvise64 1053 #define __ARCH_WANT_SYS_FADVISE64 __SYSCALL(__NR_fadvise64, sys_fadvise64) #define __NR_newfstatat 1054 #define __ARCH_WANT_SYS_NEWFSTATAT __SYSCALL(__NR_newfstatat, sys_newfstatat) #define __NR_fstatfs 1055 __SYSCALL(__NR_fstatfs, sys_fstatfs) #define __NR_statfs 1056 __SYSCALL(__NR_statfs, sys_statfs) #define __NR_lseek 1057 __SYSCALL(__NR_lseek, sys_lseek) #define __NR_mmap 1058 __SYSCALL(__NR_mmap, sys_mmap) #undef __NR_syscalls #define __NR_syscalls (__NR_mmap+1) #endif /* 32 bit off_t syscalls */ #ifdef __ARCH_WANT_SYSCALL_DEPRECATED #define __NR_alarm 1059 #define __ARCH_WANT_SYS_ALARM __SYSCALL(__NR_alarm, sys_alarm) #define __NR_getpgrp 1060 #define __ARCH_WANT_SYS_GETPGRP __SYSCALL(__NR_getpgrp, sys_getpgrp) #define __NR_pause 1061 #define __ARCH_WANT_SYS_PAUSE __SYSCALL(__NR_pause, sys_pause) #define __NR_time 1062 #define __ARCH_WANT_SYS_TIME #define __ARCH_WANT_COMPAT_SYS_TIME __SYSCALL(__NR_time, sys_time) #define __NR_utime 1063 #define __ARCH_WANT_SYS_UTIME __SYSCALL(__NR_utime, sys_utime) #define __NR_creat 1064 __SYSCALL(__NR_creat, sys_creat) #define __NR_getdents 1065 #define __ARCH_WANT_SYS_GETDENTS __SYSCALL(__NR_getdents, sys_getdents) #define __NR_futimesat 1066 __SYSCALL(__NR_futimesat, sys_futimesat) #define __NR_select 1067 #define __ARCH_WANT_SYS_SELECT __SYSCALL(__NR_select, sys_select) #define __NR_poll 1068 __SYSCALL(__NR_poll, sys_poll) #define __NR_epoll_wait 1069 __SYSCALL(__NR_epoll_wait, sys_epoll_wait) #define __NR_ustat 1070 __SYSCALL(__NR_ustat, sys_ustat) #define __NR_vfork 1071 __SYSCALL(__NR_vfork, sys_vfork) #define __NR_oldwait4 1072 __SYSCALL(__NR_oldwait4, sys_wait4) #define __NR_recv 1073 __SYSCALL(__NR_recv, sys_recv) #define __NR_send
[Bug c++/92206] [10 Regression] ICE in strip_typedefs, at cp/tree.c:1682 since r277281
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92206 --- Comment #5 from Jeffrey A. Law --- Just to pile on here. It affects icecat as well.
[Bug other/44209] [meta-bug] Some warnings are not linked to diagnostics options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44209 Bug 44209 depends on bug 92182, which changed state. Bug 92182 Summary: No way to silence ''A::TKind' is too small to hold all values of 'enum Kind'' https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92182 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |DUPLICATE
[Bug c++/61414] enum class bitfield size-checking needs a separate warning flag controlling it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61414 Eric Gallager changed: What|Removed |Added CC||david.bolvansky at gmail dot com --- Comment #18 from Eric Gallager --- *** Bug 92182 has been marked as a duplicate of this bug. ***
[Bug c++/92182] No way to silence ''A::TKind' is too small to hold all values of 'enum Kind''
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92182 Eric Gallager changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||egallager at gcc dot gnu.org Blocks||44209 Resolution|--- |DUPLICATE --- Comment #2 from Eric Gallager --- I think this is a dup of bug 61414 *** This bug has been marked as a duplicate of bug 61414 *** Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44209 [Bug 44209] [meta-bug] Some warnings are not linked to diagnostics options
[Bug c++/83806] [7 Regression] Spurious -Wunused-but-set-parameter with nullptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83806 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org Known to work||8.3.0, 9.2.1 Blocks||89180 --- Comment #8 from Eric Gallager --- (In reply to Matthias Noack from comment #7) > Can confirm, that it is fixed in 8.3.0 and 9.2.1. Yup, the reason this bug is still open is in case backports to the branch for 7 are desired. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89180 [Bug 89180] [meta-bug] bogus/missing -Wunused warnings
[Bug libstdc++/91495] std::transform_reduce with unary op is implemented in the parallel case but not the basic case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91495 gcc-bugs at marehr dot dialup.fu-berlin.de changed: What|Removed |Added CC||gcc-bugs at marehr dot dialup.fu-b ||erlin.de --- Comment #4 from gcc-bugs at marehr dot dialup.fu-berlin.de --- Will this be back-ported to gcc-7 or gcc-8?
[Bug target/92258] [10 Regression] ICE: output_operand: invalid %-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92258 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |FIXED --- Comment #3 from Jakub Jelinek --- Fixed.
[Bug preprocessor/82176] Feature request: replace __FILE__ with file's basename instead its full name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82176 --- Comment #10 from Gregory Fuchedzhy --- (In reply to f.hollerer from comment #8) > To my understanding assert() uses __FILE__ and __LINE__. I would like to > have a command line option which let __FILE__ expand to the last path > component (the filename) instead of an invocation dependent full path of > that file. If __FILE_NAME__ is implemented would adding -D__FILE__=__FILE_NAME__ solve your particular usecase?
[Bug c/92269] New: Profiling (-p) does not work on H8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92269 Bug ID: 92269 Summary: Profiling (-p) does not work on H8 Product: gcc Version: 9.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: mti-1 at tillenius dot com Target Milestone: --- gcc/config/h8300/h8300.h seems to be missing a single '.' in the definition of FUNCTION_PROFILER macro. It should be ".LP" rather than just "LP". #define FUNCTION_PROFILER(FILE, LABELNO) \ fprintf (FILE, "\t%s\t#.LP%d,%s\n\tjsr @mcount\n", \ h8_mov_op, (LABELNO), h8_reg_names[0]);
[Bug libstdc++/92267] [9/10 Regression] crash with a cppunit test case (built by GCC 9) and cpptest (built with GCC 8)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92267 --- Comment #4 from Jonathan Wakely --- Author: redi Date: Tue Oct 29 17:14:55 2019 New Revision: 277577 URL: https://gcc.gnu.org/viewcvs?rev=277577=gcc=rev Log: PR libstdc++/92267 fix ABI change in deque iterators Defaulting the copy constructor on its first declaration made it change from user-provided (and non-trivial) to implicitly-defined (and trivial). This caused an ABI incompatibility between GCC 8 and GCC 9, where functions taking a deque iterator disagree on the argument passing convention. PR libstdc++/92267 * include/bits/stl_deque.h (_Deque_iterator(const _Deque_iterator&)): Do not define as defaulted. * testsuite/23_containers/deque/types/92267.cc: New test. Added: trunk/libstdc++-v3/testsuite/23_containers/deque/types/92267.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/stl_deque.h
[Bug preprocessor/82176] Feature request: replace __FILE__ with file's basename instead its full name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82176 --- Comment #9 from joseph at codesourcery dot com --- On Tue, 29 Oct 2019, f.hollerer at gmx dot net wrote: > This would: > > - shorten the output of assert() > - minimize the image size due to shorter strings > - make the build reproduceable as the output does not depend on the current > working directory. Note that we have the -ffile-prefix-map / -fmacro-prefix-map / -fdebug-prefix-map options you can use to specify a mapping from the actual directory names used in the build to the names you want to appear in the output.
[Bug c++/92268] Constraint normalization substitutes parameter too early
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92268
--- Comment #2 from Jonathan Wakely ---
(Comment 1 was wrong)
A workaround is to replace the compound-requirement with a simple-requirement
that depends on a function constrained with the desired constraint:
template void workaround(I) { }
template
concept F = requires (T& t) { workaround(t.begin()); };
[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456 Bug 56456 depends on bug 92144, which changed state. Bug 92144 Summary: [10 regression] c-c++-common/Warray-bounds-4.c still fails after r277080 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92144 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug testsuite/92144] [10 regression] c-c++-common/Warray-bounds-4.c still fails after r277080
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92144 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org --- Comment #3 from Martin Sebor --- The test is running into the limitation in PR 83543. I've disabled the test in r277576 until that's resolved (hopefully in GCC 11).
[Bug testsuite/92144] [10 regression] c-c++-common/Warray-bounds-4.c still fails after r277080
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92144 --- Comment #2 from Martin Sebor --- Author: msebor Date: Tue Oct 29 16:14:18 2019 New Revision: 277576 URL: https://gcc.gnu.org/viewcvs?rev=277576=gcc=rev Log: gcc/testsuite/ChangeLog: PR testsuite/92144 * c-c++-common/Warray-bounds-4.c: Disable test to avoid failures due to PR 83543. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/Warray-bounds-4.c
[Bug tree-optimization/83543] strlen of a local array member not optimized on some targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83543 --- Comment #9 from Martin Sebor --- Author: msebor Date: Tue Oct 29 16:14:18 2019 New Revision: 277576 URL: https://gcc.gnu.org/viewcvs?rev=277576=gcc=rev Log: gcc/testsuite/ChangeLog: PR testsuite/92144 * c-c++-common/Warray-bounds-4.c: Disable test to avoid failures due to PR 83543. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/Warray-bounds-4.c
[Bug driver/47785] GCC with -flto does not pass -Wa/-Xassembler options to the assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47785 H.J. Lu changed: What|Removed |Added Summary|GCC with -flto does not |GCC with -flto does not |pass -Wa options to the |pass -Wa/-Xassembler |assembler |options to the assembler --- Comment #15 from H.J. Lu --- We need to also handle -Xassembler? Since -Wa, doesn't work with comma in assembler options, like -mfoo=foo1,foo2, one needs to use -Xassembler -mfoo=foo1,foo2 to pass -mfoo=foo1,foo2 to assembler.
[Bug c++/83806] [7 Regression] Spurious -Wunused-but-set-parameter with nullptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83806 --- Comment #7 from Matthias Noack --- Can confirm, that it is fixed in 8.3.0 and 9.2.1.
[Bug c++/92268] Constraint normalization substitutes parameter too early
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92268
--- Comment #1 from Jonathan Wakely ---
The workaround is to require that the common_reference_t types exist:
template
concept common_reference_with
=
//
requires { typename common_reference_t;
typename common_reference_t; }
&&
//
foo, common_reference_t>
&& bar, common_reference_t>
&& baz, common_reference_t>;
[Bug c++/92268] Constraint normalization substitutes parameter too early
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92268 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-10-29 Ever confirmed|0 |1
[Bug c++/92268] New: Constraint normalization substitutes parameter too early
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92268
Bug ID: 92268
Summary: Constraint normalization substitutes parameter too
early
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Blocks: 67491
Target Milestone: ---
The following program fails to compile with -std=gnu++2a
template
struct common_reference { };
template
using common_reference_t = typename common_reference::type;
template concept foo = true;
template concept bar = true;
template concept baz = true;
template
concept common_reference_with
= foo, common_reference_t>
&& bar, common_reference_t>
&& baz, common_reference_t>;
template
using iter_reference_t = decltype(((T*)0)->f());
template
concept forward_iterator
= common_reference_with&&, typename I::value_type&>;
struct test_range
{
struct iterator
{
using value_type = int;
char f() const;
};
iterator begin();
};
template
concept F = requires (T& t) { { t.begin() } -> forward_iterator; };
static_assert( !F );
Checking the F concept fails:
bug.cc:37:33: error: no type named 'type' in 'struct common_reference'
37 | concept F = requires (T& t) { { t.begin() } -> forward_iterator; };
| ~~^~~
bug.cc:37:33: error: no type named 'type' in 'struct common_reference'
bug.cc:37:33: error: no type named 'type' in 'struct common_reference'
On IRC Jason said:
[02:36] jwakely: you're hitting an error during normalization, which
means the constraints could never be satisfied
[02:40] but it looks like when we normalize the forward_iterator
constraint on the compound-requirement we're normalizing
forward_iterator, which is wrong -- we should be normalizing
forward_iterator, and then checking whether that's satisfied with iterator
[02:40] so it's a compiler bug
[02:40] as well as the diagnostic issue
[02:40] Andrew sent me a patch to improve handling of nested
requirements that I haven't looked at yet, it may help with this
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
[Bug 67491] [meta-bug] concepts issues
[Bug bootstrap/92235] [10 Regression] ICE in host_detect_local_cpu, segfault (profiled lto) on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92235 --- Comment #2 from Matthias Klose --- same with r277529
[Bug target/92265] [x86] Dubious target costs for vec_construct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92265 --- Comment #2 from Richard Biener --- Oh, and there's also the case where VPINSR[BWDQ] takes a GPR (or memory) to insert int a XMM reg. PINSRW is available with SSE2, the B/Q/D variants with SSE4.1. It's also only the non-zero lane inserts that require an extra move if the above are not available. There's memory move to upper half for DImode memory sources as well. Note the larger store might still be good to reduce needed store bandwith and to avoid later STLF issues when a vector load follows. But some targets have non-trivial move cost between register files (not Intel though). So the question is whether your example makes a difference in practice.
[Bug target/92265] [x86] Dubious target costs for vec_construct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92265 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-10-29 CC||hubicka at gcc dot gnu.org Version|unknown |10.0 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Honza noticed the integer vs. FP scalar thing as well. The DImode case should have higher cost already (but also not account for the int to FP register file move). Note that when the construction happens from memory via strided loads this move can be elided so care has to be taken to not pessimize the costs for that.
[Bug libstdc++/92267] [9/10 Regression] crash with a cppunit test case (built by GCC 9) and cpptest (built with GCC 8)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92267
Jonathan Wakely changed:
What|Removed |Added
Known to work||8.3.0
Target Milestone|--- |9.3
Known to fail||10.0, 9.2.0
--- Comment #3 from Jonathan Wakely ---
This change (to prevent a -Wdeprecated-copy warning) changes the copy
constructor from non-trivial to trivial:
+#if __cplusplus < 201103L
+ // Conversion from iterator to const_iterator.
_Deque_iterator(const iterator& __x) _GLIBCXX_NOEXCEPT
: _M_cur(__x._M_cur), _M_first(__x._M_first),
_M_last(__x._M_last), _M_node(__x._M_node) { }
+#else
+ // Conversion from iterator to const_iterator.
+ template,
+ is_same<_Iter, iterator>>>
+ _Deque_iterator(const _Iter& __x) noexcept
+ : _M_cur(__x._M_cur), _M_first(__x._M_first),
+ _M_last(__x._M_last), _M_node(__x._M_node) { }
+
+ _Deque_iterator(const _Deque_iterator&) = default;
+ _Deque_iterator& operator=(const _Deque_iterator&) = default;
+#endif
The fix is to define the copy constructor explicitly again:
- _Deque_iterator(const _Deque_iterator&) = default;
+ _Deque_iterator(const _Deque_iterator& __x) noexcept
+ : _M_cur(__x._M_cur), _M_first(__x._M_first),
+_M_last(__x._M_last), _M_node(__x._M_node) { }
+
[Bug middle-end/92263] [10 Regression] ICE in commit_one_edge_insertion, at cfgrtl.c:2087 since r270758
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92263 Martin Liška changed: What|Removed |Added Keywords|needs-bisection | Status|ASSIGNED|NEW Known to work||9.2.0 Assignee|marxin at gcc dot gnu.org |unassigned at gcc dot gnu.org Target Milestone|--- |10.0 Summary|ICE in |[10 Regression] ICE in |commit_one_edge_insertion, |commit_one_edge_insertion, |at cfgrtl.c:2087|at cfgrtl.c:2087 since ||r270758 Known to fail||10.0 --- Comment #2 from Martin Liška --- Started with r270758. @Jim: Can you please take a look?
[Bug libstdc++/92267] [9 Regression] crash with a cppunit test case (built by GCC 9) and cpptest (built with GCC 8)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92267 --- Comment #2 from Jonathan Wakely --- Seems to be due to r260380
[Bug rtl-optimization/92264] [10 Regression] Compile time hog in 521.wrf_r with -Ofast -march=znver2 -g since r276318
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264 --- Comment #2 from Martin Liška --- Just for the record, the compilation takes now ~2:30 hours.
[Bug tree-optimization/92260] [10 Regression] ICE in exact_div, at poly-int.h:2162
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92260 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Richard Biener --- Fixed.
[Bug tree-optimization/92260] [10 Regression] ICE in exact_div, at poly-int.h:2162
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92260 --- Comment #5 from Richard Biener --- Author: rguenth Date: Tue Oct 29 13:46:19 2019 New Revision: 277571 URL: https://gcc.gnu.org/viewcvs?rev=277571=gcc=rev Log: 2019-10-29 Richard Biener PR tree-optimization/92260 * tree-vect-slp.c (vect_get_constant_vectors): Special-case lane-reducing ops. * gcc.dg/pr92260.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/pr92260.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-slp.c
[Bug libstdc++/92267] [9 Regression] crash with a cppunit test case (built by GCC 9) and cpptest (built with GCC 8)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92267 --- Comment #1 from Jonathan Wakely --- Preprocessing with GCC 8 and then compiling with GCC 9 doesn't crash, so it's due to a change in libstdc++ headers.
[Bug middle-end/92263] ICE in commit_one_edge_insertion, at cfgrtl.c:2087
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92263 Martin Liška changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org --- Comment #1 from Martin Liška --- I'm bisecting that right now ..
[Bug libstdc++/92267] [9 Regression] crash with a cppunit test case (built by GCC 9) and cpptest (built with GCC 8)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92267 Jonathan Wakely changed: What|Removed |Added Keywords||ABI Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-10-29 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Summary|crash with a cppunit test |[9 Regression] crash with a |case (built by GCC 9) and |cppunit test case (built by |cpptest (built with GCC 8) |GCC 9) and cpptest (built ||with GCC 8) Ever confirmed|0 |1
[Bug libstdc++/92267] New: crash with a cppunit test case (built by GCC 9) and cpptest (built with GCC 8)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92267
Bug ID: 92267
Summary: crash with a cppunit test case (built by GCC 9) and
cpptest (built with GCC 8)
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: doko at debian dot org
Target Milestone: ---
Created attachment 47126
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47126=edit
abigail for cppunit
having a cppunit built with GCC 8, and building the testcase with GCC 9
crashes. Rebuild cppunit with GCC 9 as well, then the test runs as expected.
$ cat foo.cc
#include
#include
#include
class X {
private:
std::stack s1;
std::stack s2;
};
int
main(int argc, char *argv[]) {
X *x = new X();
// delete x;
std::string r;
CPPUNIT_ASSERT(r.empty());
return 0;
}
[Bug tree-optimization/88915] Try smaller vectorisation factors in scalar fallback
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88915 --- Comment #5 from avieira at gcc dot gnu.org --- Author: avieira Date: Tue Oct 29 13:15:46 2019 New Revision: 277569 URL: https://gcc.gnu.org/viewcvs?rev=277569=gcc=rev Log: [vect]PR 88915: Vectorize epilogues when versioning loops gcc/ChangeLog: 2019-10-29 Andre Vieira PR 88915 * tree-ssa-loop-niter.h (simplify_replace_tree): Change declaration. * tree-ssa-loop-niter.c (simplify_replace_tree): Add context parameter and make the valueize function pointer also take a void pointer. * gcc/tree-ssa-sccvn.c (vn_valueize_wrapper): New function to wrap around vn_valueize, to call it without a context. (process_bb): Use vn_valueize_wrapper instead of vn_valueize. * tree-vect-loop.c (_loop_vec_info): Initialize epilogue_vinfos. (~_loop_vec_info): Release epilogue_vinfos. (vect_analyze_loop_costing): Use knowledge of main VF to estimate number of iterations of epilogue. (vect_analyze_loop_2): Adapt to analyse main loop for all supported vector sizes when vect-epilogues-nomask=1. Also keep track of lowest versioning threshold needed for main loop. (vect_analyze_loop): Likewise. (find_in_mapping): New helper function. (update_epilogue_loop_vinfo): New function. (vect_transform_loop): When vectorizing epilogues re-use analysis done on main loop and call update_epilogue_loop_vinfo to update it. * tree-vect-loop-manip.c (vect_update_inits_of_drs): No longer insert stmts on loop preheader edge. (vect_do_peeling): Enable skip-vectors when doing loop versioning if we decided to vectorize epilogues. Update epilogues NITERS and construct ADVANCE to update epilogues data references where needed. * tree-vectorizer.h (_loop_vec_info): Add epilogue_vinfos. (vect_do_peeling, vect_update_inits_of_drs, determine_peel_for_niter, vect_analyze_loop): Add or update declarations. * tree-vectorizer.c (try_vectorize_loop_1): Make sure to use already created loop_vec_info's for epilogues when available. Otherwise analyse epilogue separately. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-loop-niter.c trunk/gcc/tree-ssa-loop-niter.h trunk/gcc/tree-ssa-sccvn.c trunk/gcc/tree-vect-loop-manip.c trunk/gcc/tree-vect-loop.c trunk/gcc/tree-vectorizer.c trunk/gcc/tree-vectorizer.h
[Bug tree-optimization/92266] New: Duplicate code generation for live stmts from SLP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92266
Bug ID: 92266
Summary: Duplicate code generation for live stmts from SLP
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
int foo (int * __restrict__ a, int * b, int n)
{
int tem1, tem2;
for (int i = 0; i < n; ++i)
{
tem1 = a[i*2 + 0] * 2;
tem2 = a[i*2 + 1] * 2;
b[i*4 + 0] = tem1;
b[i*4 + 1] = tem1;
b[i*4 + 2] = tem2;
b[i*4 + 3] = tem2;
}
return tem1 + tem2;
}
shows
[local count: 105119324]:
# tem1_55 = PHI
# tem2_54 = PHI
# vect_tem1_35.9_53 = PHI
_61 = BIT_FIELD_REF ;
_62 = BIT_FIELD_REF ;
_63 = BIT_FIELD_REF ;
_64 = BIT_FIELD_REF ;
goto ; [100.00%]
[local count: 850510900]:
goto ; [100.00%]
[local count: 118111601]:
# tem1_45 = PHI
# tem2_46 = PHI
_33 = tem1_45 + tem2_46;
which is because we iterate like
FOR_EACH_VEC_ELT (SLP_TREE_SCALAR_STMTS (slp_node), i, slp_stmt_info)
{
if (STMT_VINFO_LIVE_P (slp_stmt_info)
&& !vectorizable_live_operation (slp_stmt_info, gsi, slp_node,
slp_node_instance, i,
vec_stmt_p, cost_vec))
return false;
}
so for stmts appearing multiple times we code-gen the live operation multiple
times. This is even worse for stmts appearing in multiple SLP nodes.
Luckily the code is all dead in the end.
[Bug tree-optimization/92266] Duplicate code generation for live stmts from SLP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92266 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-10-29 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Mine.
[Bug target/92265] New: [x86] Dubious target costs for vec_construct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92265
Bug ID: 92265
Summary: [x86] Dubious target costs for vec_construct
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rsandifo at gcc dot gnu.org
CC: amonakov at gcc dot gnu.org, uros at gcc dot gnu.org
Target Milestone: ---
Target: x86_64-linux-gnu
The x86 costs for vec_construct look a little low, especially
for -m32. E.g. gcc.target/i386/pr84101.c has:
---
typedef struct uint64_pair uint64_pair_t ;
struct uint64_pair
{
unsigned long w0 ;
unsigned long w1 ;
} ;
uint64_pair_t pair(int num)
{
uint64_pair_t p ;
p.w0 = num << 1 ;
p.w1 = num >> 1 ;
return p ;
}
---
where uint64_pair is actually a uint32_pair for -m32.
If we consider applying SLP vectorisation to the store,
we have the difference between:
- 2 scalar_stores
- 1 vec_construct + 1 vector_store
The vec_construct cost for 64-bit and 128-bit vectors is:
int cost = TYPE_VECTOR_SUBPARTS (vectype) * ix86_cost->sse_op;
i.e. one SSE op per element. With -mtune=intel this gives:
- 2 scalar_stores = 3 + 3 insns
- 1 vec_construct + 1 vector_store = 2 + 3 insns
But for integer elements, the vec_construct actually needs two
integer-to-vector moves followed by an SSE pack:
movd%eax, %xmm1
movd%ecx, %xmm0
punpckldq %xmm1, %xmm0
movq%xmm0, (%edx)
compared to:
movl%eax, 4(%edx)
movl%ecx, (%edx)
I don't know enough about the Intel uarchs to know if there's
a significant difference between these two in practice.
But as Alexander points out, things are much worse if the
elements are DImode rather than SImode, i.e. if we change
the above "unsigned long"s to "__UINT64_TYPE__"s. We then
end up spilling the four registers to the stack, loading
them into a vector register, and then storing that vector
register out separately:
movl%edx, 8(%esp)
...
movl%edx, 12(%esp)
movq8(%esp), %xmm0
movl%eax, 8(%esp)
...
movl%edx, 12(%esp)
movhps 8(%esp), %xmm0
movups %xmm0, (%ecx)
vs. 4 scalar stores directly to (%ecx). Here we're operating
on DIs and V2DIs, but the costs are the same as for SI vs. V2SI:
- 2 scalar_stores = 3 + 3 insns
- 1 vec_construct + 1 vector_store = 2 + 3 insns
So as far as the vectoriser is concerned, the vector form
seems cheaper.
[Bug rtl-optimization/92264] [10 Regression] Compile time hog in 521.wrf_r with -Ofast -march=znver2 -g since r276318
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264 Richard Biener changed: What|Removed |Added Target||x86_64-linux-gnu Host|x86_64-linux-gnu| Target Milestone|--- |10.0 --- Comment #1 from Richard Biener --- Note find_base_term is known to be quadratic ... possibly we were able to short-cut this much more often before the rev.
[Bug ipa/92251] [10 regression] SEGV in ipa_get_cs_argument_count
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92251 Rainer Orth changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Rainer Orth --- (In reply to Martin Liška from comment #2) > @Rainer: Can you please test it now? I did during last night's bootstraps and the failure is gone. So indeed a dup. *** This bug has been marked as a duplicate of bug 92242 ***
[Bug ipa/92242] [10 regression] LTO ICE in ipa_get_cs_argument_count ipa-prop.h:598
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92242 Rainer Orth changed: What|Removed |Added CC||ro at gcc dot gnu.org --- Comment #6 from Rainer Orth --- *** Bug 92251 has been marked as a duplicate of this bug. ***
[Bug c++/92186] [concepts] requires expression outside of concept definition cannot return false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92186 Jonathan Wakely changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2019-10-29 Blocks||67491 Ever confirmed|0 |1 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 [Bug 67491] [meta-bug] concepts issues
[Bug c++/68781] [concepts] requires in member function is not unevaluated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68781 Jonathan Wakely changed: What|Removed |Added Known to work||10.0 Blocks||67491 --- Comment #2 from Jonathan Wakely --- dup of PR 90675 ? Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 [Bug 67491] [meta-bug] concepts issues
[Bug c++/67491] [meta-bug] concepts issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 Bug 67491 depends on bug 91662, which changed state. Bug 91662 Summary: [concepts] unable to deduce placeholder type, should be accepted https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91662 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/91662] [concepts] unable to deduce placeholder type, should be accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91662 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Blocks||67491 Resolution|--- |FIXED Target Milestone|--- |10.0 --- Comment #1 from Jonathan Wakely --- (In reply to Frederik Engels from comment #0) > The following should compile but doesn't on current gcc-trunk (20190902) > with options: "-std=c++2a -fconcepts" Because the implementation hadn't been updated for the recent changes to return type constraints. This was fixed by r276764. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 [Bug 67491] [meta-bug] concepts issues
[Bug c++/67658] [concepts] invalid code with constrained concepts compiles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67658 Jonathan Wakely changed: What|Removed |Added Keywords||accepts-invalid Known to work||10.0 --- Comment #3 from Jonathan Wakely --- Fixed on trunk but the testcase doesn't seem to be committed yet.
[Bug c++/91487] [concepts] alias constraint not respected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91487 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 67704 ***
[Bug c++/67704] [concepts] requirements not being applied to aliases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67704 Jonathan Wakely changed: What|Removed |Added CC||frederik.engels24 at gmail dot com --- Comment #4 from Jonathan Wakely --- *** Bug 91487 has been marked as a duplicate of this bug. ***
[Bug c++/91466] [concepts] indicates "used in its own initializer" when not, constraint order change passes compilation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91466
Jonathan Wakely changed:
What|Removed |Added
Known to work||10.0
Blocks||67491
--- Comment #1 from Jonathan Wakely ---
Compiles on current trunk after changing the return type constraint:
#include
#include
template
concept integral_constant_ = std::is_empty_v && std::is_trivial_v &&
requires
{
typename T::value_type;
requires std::is_integral_v;
{ T::value } -> std::same_as;
};
struct sz_fn
{
template requires requires(R&& r) { {static_cast(r).size()} ->
integral_constant_; }
constexpr auto operator()(R&& r) {
return static_cast(r).size();
}
};
constexpr auto sz = sz_fn{};
int main()
{
auto arr = std::array{1, 2, 3, 4, 5};
return !std::is_invocable_v;
}
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
[Bug 67491] [meta-bug] concepts issues
[Bug c++/91467] [concepts] ICE: in tsubst_copy, at cp/pt.c:15545
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91467
Jonathan Wakely changed:
What|Removed |Added
Keywords|ice-on-valid-code |ice-on-invalid-code
Known to work||10.0
Blocks||67491
--- Comment #1 from Jonathan Wakely ---
With an updated testcase using C++2a syntax there's no ICE on current trunk:
template constexpr bool same = false;
template constexpr bool same = true;
template concept same_as = same;
template
struct foo {
T t;
template
void set(U&& u) requires requires { { static_cast(u)} -> same_as; }
{
t = static_cast(u);
}
};
int main()
{
auto w = foo{5};
w.set(5.0f);
}
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
[Bug 67491] [meta-bug] concepts issues
[Bug c++/91405] [concepts] internal compiler error: in synthesize_implicit_template_parm, at cp/parser.c:41206
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91405 Jonathan Wakely changed: What|Removed |Added Keywords||ice-on-invalid-code Known to work||10.0 Blocks||67491 --- Comment #2 from Jonathan Wakely --- No ICE with current trunk (after updating the testcase to C++2a syntax). Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 [Bug 67491] [meta-bug] concepts issues
[Bug c++/90675] [concepts] expressions in compound requirements not correctly treated as unevaluated operands
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90675 Jonathan Wakely changed: What|Removed |Added Keywords||rejects-valid Known to work||10.0 Blocks||67491 --- Comment #1 from Jonathan Wakely --- Seems to be fixed on trunk. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 [Bug 67491] [meta-bug] concepts issues
[Bug c++/90398] [contracts] Segmentation fault when using [[assert]] and -fno-exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90398 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID Summary|[concepts] Segmentation |[contracts] Segmentation |fault when using [[assert]] |fault when using [[assert]] |and -fno-exception |and -fno-exception --- Comment #1 from Jonathan Wakely --- The contracts branch does not exist in upstream GCC, please report this to https://gitlab.com/lock3/gcc-new/issues instead.
[Bug c++/90396] [contracts] error while using sizeof in [[assert]]: internal compiler error: in gimplify_expr, at gimplify.c:13199
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90396 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Jonathan Wakely --- The contracts branch does not exist in upstream GCC, please report this to https://gitlab.com/lock3/gcc-new/issues (although it seems to compile with the version on godbolt now).
[Bug tree-optimization/92262] [10 Regression] ICE: verify_gimple failed (error: incorrect sharing of tree nodes)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92262 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 47125 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47125=edit gcc10-pr92262.patch Full patch I'm going to test.
[Bug c++/90033] [concepts] ICE segfault evaluating a requires clause that transitively depends on itself
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90033 Jonathan Wakely changed: What|Removed |Added Known to work||10.0 Blocks||67491 --- Comment #1 from Jonathan Wakely --- Compiles with current trunk. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 [Bug 67491] [meta-bug] concepts issues
[Bug c++/85991] [Concepts] Template placeholder: ICE cp_parser_lookup_name, at cp/parser.c:26223
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85991 Jonathan Wakely changed: What|Removed |Added Blocks||67491 --- Comment #1 from Jonathan Wakely --- No ICE with current trunk: b.cc:1:51: warning: the 'bool' keyword is not allowed in a C++20 concept definition 1 | template class, int> concept bool TmplC = true; | ^~~~ b.cc:3:10: error: 'TmplC' does not constrain a type 3 | void f(A> *); | ^~~ b.cc:1:56: note: concept defined here 1 | template class, int> concept bool TmplC = true; |^ b.cc:3:10: error: wrong number of template arguments (1, should be 2) 3 | void f(A> *); | ^~~ b.cc:1:56: note: provided for 'template class, int > concept const bool TmplC< , >' 1 | template class, int> concept bool TmplC = true; |^ b.cc:3:10: error: wrong number of template arguments (1, should be 2) 3 | void f(A> *); | ^~~ b.cc:1:56: note: provided for 'template class, int > concept const bool TmplC< , >' 1 | template class, int> concept bool TmplC = true; |^ b.cc:3:17: error: template argument 1 is invalid 3 | void f(A> *); | ^~ Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 [Bug 67491] [meta-bug] concepts issues
[Bug c++/89657] [concepts] ICE when calling lambda returning requires-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89657 Jonathan Wakely changed: What|Removed |Added Known to work||10.0 Blocks||67491 --- Comment #2 from Jonathan Wakely --- Seems to be fixed on trunk. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 [Bug 67491] [meta-bug] concepts issues
[Bug c++/85846] [Concepts] Concept as value in initializer: bogus declared-as-implicit-template error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85846 Jonathan Wakely changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2019-10-29 Blocks||67491 Ever confirmed|0 |1 Known to fail||10.0 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 [Bug 67491] [meta-bug] concepts issues
[Bug c++/79682] [concepts] ambiguous overload with functionally equivalent predicate constraints compiles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79682
Jonathan Wakely changed:
What|Removed |Added
Known to work||10.0
Blocks||67491
--- Comment #1 from Jonathan Wakely ---
With this updated testcase using C++2a syntax:
template
requires ((N & 0x1) != 0) && (N > 1)
int foo() { return 0; }
template
requires ((N & 0x1) != 0x0)
void foo() { }
int main(void) {
return foo<0x03>();
}
Current trunk prints:
b.cc: In function 'int main()':
b.cc:10:20: error: call of overloaded 'foo<3>()' is ambiguous
10 | return foo<0x03>();
|^
b.cc:3:5: note: candidate: 'int foo() [with unsigned int N = 3]'
3 | int foo() { return 0; }
| ^~~
b.cc:7:6: note: candidate: 'void foo() [with unsigned int N = 3]'
7 | void foo() { }
| ^~~
So it seems to be fixed. We might want to add the testcase to the testsuite
before closing the bug though.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
[Bug 67491] [meta-bug] concepts issues
[Bug c++/77755] [concepts] Abbreviatd function template pack expansions not working
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77755
Jonathan Wakely changed:
What|Removed |Added
Keywords||rejects-valid
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-10-29
Blocks||67491
Ever confirmed|0 |1
Known to fail||10.0
--- Comment #1 from Jonathan Wakely ---
Please provide complete testcases that we can actually test. You're missing the
header here.
Complete testcase:
template struct trait { static constexpr bool value = false; };
template struct S{};
template
concept Integral = trait::value;
void foo (S)
{
}
Still fails on current trunk with -std=gnu++2a
b.cc:8:25: error: expansion pattern 'auto:1' contains no parameter packs
8 | int foo (S)
| ^~~
b.cc:8:28: error: template argument 1 is invalid
8 | int foo (S)
|^
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
[Bug 67491] [meta-bug] concepts issues
[Bug c++/77811] [concepts] invalid redefinition error when declaring friend function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77811 Jonathan Wakely changed: What|Removed |Added Known to work||10.0 Blocks||67491 --- Comment #1 from Jonathan Wakely --- Compiles ok with current trunk. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 [Bug 67491] [meta-bug] concepts issues
