[Bug other/42540] c++ error message [vtable undefined] is unhelpful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42540 Zhihao Yuan changed: What|Removed |Added CC||lichray at gmail dot com --- Comment #11 from Zhihao Yuan --- The example in this bug is not as severe and frequent as the one in bug 44841. Users are more likely to encounter this issue when adding a new API to existing interface or type erasure. Calling this a "well-known issue" is irresponsible. The issue significantly increases the bar to learners to consume and accept new paradigms in the language. The issue has not been fixed for ten years. It is a shame rather than some arcane knowledge that worth to be proud of. MSVC has no such issue. The error message reads as "undefined reference to Class::that_virtual_function." Some possible fixes: 1. Adjust the error message to say, "The first non-inline, non-pure function may not have a definition in ." 2. Add extra information to name the key function, and pass it to the linker, generate an error message to match MSVC's quality.
[Bug tree-optimization/93891] New: CSE where clobber writes the same value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93891
Bug ID: 93891
Summary: CSE where clobber writes the same value
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
void f(int**p,int**q){
++**p;
*q=*p;
--**p;
}
produces
_1 = *p_8(D);
_2 = *_1;
_3 = _2 + 1;
*_1 = _3;
*q_10(D) = _1;
_4 = *p_8(D);
etc
where we do not CSE _4 -> _1. We do have code in vn_reference_lookup_3 to
handle this kind of thing, look past a potential clobber, and ignore it if we
find the same value. But for this test, vn_reference_lookup_2 returns 0 and we
never look further than *q=1 when we valueize *p for _4. If we did, I expect we
would skip *_1=3 using TBAA and eventually find _1=*p, which matches the
potential clobber.
(this comes from the same code as PR 93745 but should not have the same issue)
[Bug target/93658] [9/10 Regression] infinite loop building ghostscript and icu with -O3 on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93658 --- Comment #13 from Peter Bergner --- Simple backports to GCC 8 and 9 exposed some bugs that have already been fixed on trunk. The following patch resubmission includes those extra fixes that need backports too: https://gcc.gnu.org/ml/gcc-patches/2020-02/msg01253.html
[Bug c++/93880] missing test for diagnostic: %s%#qD (reversed)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93880 --- Comment #6 from Roland Illig --- (In reply to Marek Polacek from comment #5) > Right, but that still doesn't make it significantly easier to grep, I think. Oh, damn, I forgot about the regular expressions. In other contexts I have seen ".expected.", but that was used for quotes instead of parentheses, probably to avoid any Tcl backslashes. Another possibility would be to have a plain "(expected)" comment somewhere in the test code. This would help when grepping, and there are only 10 instances of this string in the whole GCC source tree right now. Or a hint in the main code referring to the test code, but that would be kind of unusual.
[Bug c++/93880] missing test for diagnostic: %s%#qD (reversed)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93880 --- Comment #5 from Marek Polacek --- Right, but that still doesn't make it significantly easier to grep, I think.
[Bug c++/93880] missing test for diagnostic: %s%#qD (reversed)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93880
--- Comment #4 from Andreas Schwab ---
You can use {\(reversed\)} instead.
[Bug c++/93880] missing test for diagnostic: %s%#qD (reversed)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93880
--- Comment #3 from Marek Polacek ---
In this particular case I'm not sure how better we could test it. Now we have:
6 bool operator==(Y, int);// #2 { dg-message "reversed" "" { target c++2a
} }
and with all the escaping in tcl I don't think "\\\(reversed\\\)" would be much
better (and it's a pain to write it).
[Bug c++/93881] cxx-pretty-print: only few i18n strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93881 --- Comment #2 from Roland Illig --- Thanks for the explanation and for providing context for this single-word translation. (This is exactly the reason why single-word translations are discouraged — they provoke unnecessary questions from the translator.) Could you please add a /* TRANSLATORS: ... */ comment to the code that explains in which context this single word is used? This makes it easier to translate properly.
[Bug c++/93880] missing test for diagnostic: %s%#qD (reversed)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93880 --- Comment #2 from Roland Illig --- Could you perhaps make the diagnostic in the test a bit more verbose? The word "reversed" appears 492 times in the GCC source tree, and I'm not going through all these occurrences just to find the test for this diagnostic. The diagnostics in the test should be as close to the diagnostics in the main code, in order to make it easy to find them.
[Bug c++/93883] missing test for diagnostic: using-declaration may not name enumerator %<%E::%D%>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93883 --- Comment #2 from Roland Illig --- Could you perhaps make the diagnostic in the test a bit more verbose? I thought that the words "name enumerator" were way too generic, therefore I didn't even start searching for them. The diagnostics in the test should be as close to the diagnostics in the main code, in order to make it easy to find them.
[Bug fortran/93890] New: trailing space in diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93890
Bug ID: 93890
Summary: trailing space in diagnostic
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
From interface.c:
> gfc_error ("Element of assumed-shape or pointer array "
>"as actual argument at %L can not correspond to "
>"actual argument at %L ",
1. "can not" should be "cannot"
2. the space at the end should be removed
[Bug fortran/93889] New: missing closing parenthesis in diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93889 Bug ID: 93889 Summary: missing closing parenthesis in diagnostic Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- From interface.c: > gfc_error_opt (0, "Rank mismatch between actual argument at %L " >"and actual argument at %L (rank-%d and rank-%d", where, >where_formal, rank1, rank2); To avoid this problem in general, in 2019 the -Wformat-diag option has been added to GCC to detect typos like this. I'm not sure whether it covers Fortran diagnostics as well, but I think it should. If in doubt, ask Martin Sebor.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #201 from dave.anglin at bell dot net --- On 2020-02-22 4:33 p.m., peter.bisroev at groundlabs dot com wrote: > They both seem to be ELF32 Maybe run failing program under gdb to find faulting instruction. Compare with executable that works.
[Bug debug/93888] New: Incorrect DW_AT_location generated for copy-constructed function argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93888
Bug ID: 93888
Summary: Incorrect DW_AT_location generated for
copy-constructed function argument
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: mgulick at mathworks dot com
Target Milestone: ---
Created attachment 47889
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47889=edit
reproducer code, gdb test script, makefile and README
Hi,
I have observed that gcc produces an incorrect DW_AT_location list for a
function argument when both of the following are true:
a) The argument is passed by value with the help of a copy constructor
b) The function is inlined
When this occurs, the DW_AT_location list actually ends up pointing to the
address of the data, not the data itself. Thus, it is either missing a
DW_OP_deref, or contains a gratuitous DW_OP_stack_value.
I have turned off all other optimizations and the issue is still reproducible.
I have observed this issue on all versions of GCC I have available to test,
including the current git master, 8.3, 6.3, 4.9, 4.7, and 4.4.
Here is a sample program:
class K
{
public:
K() {}
// Commenting out this copy-constructor makes the test pass
K ( K const& rhs ) {
m_storage[0] = 'C'; // 0x43
}
// Initialize this array to some known values (0x42)
char m_storage[ 8 ] = {'B','B','B','B','B','B','B','B'};
};
// Not inlining also fixes the issue
__attribute__((always_inline))
bool func1(const K func1_k) {
return func1_k.m_storage[0] == 'C';
}
int main() {
K my_k;
return func1(my_k);
}
I am compiling this with 'g++ -g -O0 -fvar-tracking ...'.
In gdb, if I break inside 'func1' and print the value of 'func1_k', the wrong
value is printed. If I instead print '*(K*)func1_k', I get the expected value.
If I ask gdb what the address of func1_k is, I get:
(gdb) info address func1_k
Symbol "func1_k" is multi-location:
Range 0x40113f-0x401148: a complex DWARF expression:
0: DW_OP_breg6 -8 [$rbp]
2: DW_OP_stack_value
I verified with dwarfdump that this matches the value in the .o file, so it
does not appear to be a gdb bug. I am using the latest gdb 9.1 release.
I have attached a tarball containing the reproduction code, along with a gdb
test script, and a README with additional details.
While this issue itself is relatively minor, there isn't an easy workaround if
you need to debug optimized code. Also, in the production code where this
issue was found, the value being passed happens to be a boost::optional which
we have a gdb pretty-printer setup for, and this causes the unfortunate
side-effect that running a 'backtrace' command in gdb any time this function is
in the stack (which is pretty much all the time) causes the boost
pretty-printer to try to dereference an invalid value, and gdb segfaults.
I spent some time trying to debug gcc itself, but I got lost very quickly and
was unable to localize where the issue is. Hopefully this reproduction case is
small-enough to help you determine the source of the error.
Thank you!
-Mike
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #200 from Peter Bisroev --- (In reply to dave.anglin from comment #199) > On 2020-02-22 4:09 p.m., peter.bisroev at groundlabs dot com wrote: > > Reassembled with GNU's as and relinked. PCREL21B changes to PCREL60B, but > > when > > I try to run the binary I get an "Illegal instruction" and a core dump. The > > illegal instruction seems to be the brl. I know almost nothing of IA-64 > > assembly, so will read up a bit more and try to figure out what is going on > > there. > That suggests to me that HP's aCC generates 64-bit ELF code and gcc > generates 32-bit code. > Compare header info of the two executable files with readelf. > > I'm not sure why we are struggling with the 32-bit runtime. They both seem to be ELF32 -- $ readelf -h hello ELF Header: Magic: 7f 45 4c 46 01 02 01 01 01 00 00 00 00 00 00 00 Class: ELF32 Data: 2's complement, big endian Version: 1 (current) OS/ABI:UNIX - HP-UX ABI Version: 1 Type: EXEC (Executable file) Machine: Intel IA-64 Version: 0x1 Entry point address: 0x4000980 Start of program headers: 52 (bytes into file) Start of section headers: 69184 (bytes into file) Flags: 0x8, 32-bit Size of this header: 52 (bytes) Size of program headers: 32 (bytes) Number of program headers: 12 Size of section headers: 40 (bytes) Number of section headers: 37 Section header string table index: 36 $ readelf -h hello-gcc ELF Header: Magic: 7f 45 4c 46 01 02 01 01 01 00 00 00 00 00 00 00 Class: ELF32 Data: 2's complement, big endian Version: 1 (current) OS/ABI:UNIX - HP-UX ABI Version: 1 Type: EXEC (Executable file) Machine: Intel IA-64 Version: 0x1 Entry point address: 0x4000930 Start of program headers: 52 (bytes into file) Start of section headers: 67824 (bytes into file) Flags: 0x8, 32-bit Size of this header: 52 (bytes) Size of program headers: 32 (bytes) Number of program headers: 12 Size of section headers: 40 (bytes) Number of section headers: 34 Section header string table index: 33 -- I am looking for any other differences now.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #199 from dave.anglin at bell dot net --- On 2020-02-22 4:09 p.m., peter.bisroev at groundlabs dot com wrote: > Reassembled with GNU's as and relinked. PCREL21B changes to PCREL60B, but when > I try to run the binary I get an "Illegal instruction" and a core dump. The > illegal instruction seems to be the brl. I know almost nothing of IA-64 > assembly, so will read up a bit more and try to figure out what is going on > there. That suggests to me that HP's aCC generates 64-bit ELF code and gcc generates 32-bit code. Compare header info of the two executable files with readelf. I'm not sure why we are struggling with the 32-bit runtime.
[Bug c/93878] -Wfloat-equal complains even in safe cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93878 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #1 from Andrew Pinski --- -Wfloat-equal is not flow sensative. So GCC does not know that rounded is rounded to the nearest integer. We are not going to improve this warning to be flow sensative as that would produce too many false negaitves. Yes there are some false positives but not enough to make a difference in general.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #198 from Peter Bisroev --- (In reply to dave.anglin from comment #196) > If you create a second object file with a second instance of hello, the > linker should not > complain about the second definition of hello since it is weak. It would > complain about > two global instances. Hi Dave, I have created a new object hello2.o, and when I tried to link I got -- "ld: Duplicate symbol "hello" in files hello.o and hello2.o " -- Then I realized that in hello.s hello is defined as ".global hello". Changing that to '.weak hello', reassembling and relinking all worked. I guess this confirms what I have seen in comment 187. So this seems to work as expected. This worked both with aCC and gcc. > Could you test whether the "brl" branch works? Simply take your main.s file > and edit the branch > to hello. This should show whether the assembler can handle it. If it > assembles, look at relocation > and see if program will link. I took main.s generated by aCC. Made the following changes: -- $ diff main-aCC.s main-aCC-weak-brl.s 7c7 < .global hello --- > .weak hello 41c41 < br.call.dptk.many rp = hello# ;; // B [main.cc: 10/5] --- > brl.call.dptk.many rp = hello# ;; // B [main.cc: 10/5] -- Reassembled with HP's as, relinked and the test ran fine. With this change when hello was global PCREL21B relocation was used. When I changed hello to weak, PCREL21B was still used. When I changed this to weak with a brl, PCREL60B was used. I have then tried to do a similar thing with main.s generated by gcc. -- $ diff main-gcc.s main-gcc-brl.s 19c19 < br.call.sptk.many b0 = hello# --- > brl.call.sptk.many b0 = hello# -- Reassembled with GNU's as and relinked. PCREL21B changes to PCREL60B, but when I try to run the binary I get an "Illegal instruction" and a core dump. The illegal instruction seems to be the brl. I know almost nothing of IA-64 assembly, so will read up a bit more and try to figure out what is going on there. Please let me know if I have missed anything. Thanks! --peter
[Bug middle-end/93848] missing -Warray-bounds warning for array subscript 1 is outside array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93848 --- Comment #6 from Vincent Lefèvre --- bar_aux can be any function. It doesn't need to do any thing. As soon as p[1] is evaluated, one has undefined behavior, just like in function foo.
[Bug c/93887] New: -Q --help=warning,c does not list -Wreturn-local-addr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93887 Bug ID: 93887 Summary: -Q --help=warning,c does not list -Wreturn-local-addr Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: tim.ruehsen at gmx dot de Target Milestone: ---
[Bug c/93886] New: -Q --help=warning,c does not list -Warray-bounds (gcc 10)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93886 Bug ID: 93886 Summary: -Q --help=warning,c does not list -Warray-bounds (gcc 10) Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: tim.ruehsen at gmx dot de Target Milestone: ---
[Bug middle-end/93873] gcc or lto-wrapper does not consider individual bitfield values on static analysis and instead tests the whole value of all bitfield bits combined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93873 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Looks very much related to PR93582.
[Bug other/55930] [8/9 Regression] libatomic build failure if configured with --disable-dependency-tracking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55930 --- Comment #19 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:128ff73d7c5b70b20991b191b64a27d64145d762 commit r10-6799-g128ff73d7c5b70b20991b191b64a27d64145d762 Author: Jakub Jelinek Date: Sat Feb 22 19:55:09 2020 +0100 libatomic: Fix last change [PR55930] 2020-02-22 Jakub Jelinek PR other/55930 * Makefile.am (M_DEPS): Guard the empty definition with @AMDEP_FALSE@ rather than @AMDEP_TRUE@. * Makefile.in: Regenerated.
[Bug c++/93885] New: Spurious instruction kshiftlw issued
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93885
Bug ID: 93885
Summary: Spurious instruction kshiftlw issued
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: guille at berkeley dot edu
Target Milestone: ---
[gcc version 10.0.1 20200216]
The following code ( https://www.godbolt.org/z/JynEy6 )
#include
__m512 f(__m512 x, __m512 y, __m512 z)
{
const __mmask16 masky = 0b0010001000100010;
const __m512 xy = _mm512_mask_blend_ps(masky, x, y);
const __mmask16 maskz = _kshiftli_mask16(masky, 1);
return _mm512_mask_blend_ps(maskz, xy, z);
}
computes 'maskz' by shifting 'masky'. The generated asm:
f(float __vector(16), float __vector(16), float __vector(16)):
mov eax, 8738
kmovw k1, eax
mov eax, 17476
vmovaps zmm0{k1}, zmm1
kmovw k2, eax
kshiftlwk1, k1, 1
vmovaps zmm0{k2}, zmm2
ret
both loads the value (17476) directly, *and* performs the left-shift
'kshiftlw'.
Unless I'm missing something, it would seem one of them (move+kmovw, or
kshiftlw) isn't needed.
Thanks.
[Bug libstdc++/93884] ranges::copy doesn't like output iterators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93884 Christopher Di Bella changed: What|Removed |Added CC||cjdb.ns at gmail dot com --- Comment #1 from Christopher Di Bella --- Created attachment 47888 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47888=edit Example with standard iterators
[Bug libstdc++/93884] New: ranges::copy doesn't like output iterators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93884 Bug ID: 93884 Summary: ranges::copy doesn't like output iterators Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: cjdb.ns at gmail dot com Target Milestone: --- ranges::copy doesn't currently like non-readable iterators as its second/third argument. * Branch: GCC trunk * Version: gcc (GCC) 10.0.1 20200222 (experimental) * Git Hash: d6f420d98126ac51396b89fbe287a32287cd92ed * GCC configured with: ../gcc/configure --disable-nls --disable-multilib --enable-languages=c,c++ --disable-werror * GCC built with: CFLAGS='-O3 -g0 -w' CXXFLAGS='-O3 -g0 -w' LDFLAGS='-fuse-ld=gold' * System: Ubuntu 18.04 (WSL) * GCC invocation: g++ -std=c++2a Output: ``` copy.cpp: In function 'int main()': copy.cpp:14:73: error: no match for call to '(const std::ranges::__copy_fn) (std::ranges::iota_view::_Iterator, std::ranges::iota_view::_Iterator, std::back_insert_iterator >)' 14 | ranges::copy(ranges::begin(i), ranges::end(i), std::back_inserter(v)); | ^ In file included from /usr/local/include/c++/10.0.1/bits/ranges_algo.h:35, from /usr/local/include/c++/10.0.1/algorithm:64, from copy.cpp:1: /usr/local/include/c++/10.0.1/bits/ranges_algobase.h:304:7: note: candidate: 'constexpr std::ranges::copy_result<_Iter, _Out> std::ranges::__copy_fn::operator()(_Iter, _Sent, _Out) const [with _Iter = std::ranges::iota_view::_Iterator; _Sent = std::ranges::iota_view::_Iterator; _Out = std::back_insert_iterator >; std::ranges::copy_result<_Iter, _Out> = std::ranges::in_out_result::_Iterator, std::back_insert_iterator > >]' 304 | operator()(_Iter __first, _Sent __last, _Out __result) const | ^~~~ /usr/local/include/c++/10.0.1/bits/ranges_algobase.h:304:7: note: constraints not satisfied In file included from /usr/local/include/c++/10.0.1/compare:39, from /usr/local/include/c++/10.0.1/bits/stl_pair.h:65, from /usr/local/include/c++/10.0.1/utility:70, from /usr/local/include/c++/10.0.1/algorithm:60, from copy.cpp:1: /usr/local/include/c++/10.0.1/concepts: In instantiation of 'constexpr std::ranges::copy_result<_Iter, _Out> std::ranges::__copy_fn::operator()(_Iter, _Sent, _Out) const [with _Iter = std::ranges::iota_view::_Iterator; _Sent = std::ranges::iota_view::_Iterator; _Out = std::back_insert_iterator >; std::ranges::copy_result<_Iter, _Out> = std::ranges::in_out_result::_Iterator, std::back_insert_iterator > >]': copy.cpp:14:73: required from here /usr/local/include/c++/10.0.1/concepts:138:13: required for the satisfaction of 'constructible_from > > >' /usr/local/include/c++/10.0.1/concepts:143:13: required for the satisfaction of 'default_initializable > > >' /usr/local/include/c++/10.0.1/bits/iterator_concepts.h:507:13: required for the satisfaction of 'weakly_incrementable > > >' /usr/local/include/c++/10.0.1/concepts:139:30: note: the expression 'is_constructible_v<_Tp, _Args ...>' evaluated to 'false' 139 | = destructible<_Tp> && is_constructible_v<_Tp, _Args...>; | ^ In file included from /usr/local/include/c++/10.0.1/bits/ranges_algo.h:35, from /usr/local/include/c++/10.0.1/algorithm:64, from copy.cpp:1: /usr/local/include/c++/10.0.1/bits/ranges_algobase.h:314:7: note: candidate: 'template requires (input_range<_Range>) && (weakly_incrementable<_Out>) && (indirectly_copyable)())), _Out>) constexpr std::ranges::copy_result, _Out> std::ranges::__copy_fn::operator()(_Range&&, _Out) const' 314 | operator()(_Range&& __r, _Out __result) const | ^~~~ /usr/local/include/c++/10.0.1/bits/ranges_algobase.h:314:7: note: template argument deduction/substitution failed: copy.cpp:14:73: note: candidate expects 2 arguments, 3 provided 14 | ranges::copy(ranges::begin(i), ranges::end(i), std::back_inserter(v)); | ^ copy.cpp:15:84: error: no match for call to '(const std::ranges::__copy_fn) (std::ranges::iota_view::_Iterator, std::ranges::iota_view::_Iterator, std::insert_iterator >)' 15 | ranges::copy(ranges::begin(i), ranges::end(i), std::inserter(v, ranges::end(v))); | ^ In file included from /usr/local/include/c++/10.0.1/bits/ranges_algo.h:35, from /usr/local/include/c++/10.0.1/algorithm:64,
[Bug c++/93883] missing test for diagnostic: using-declaration may not name enumerator %<%E::%D%>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93883 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |WORKSFORME --- Comment #1 from Marek Polacek --- This is tested in g++.dg/cpp0x/using-enum-2.C and g++.dg/cpp0x/using-enum-3.C.
[Bug c++/93880] missing test for diagnostic: %s%#qD (reversed)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93880 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- spaceship-rewrite3.C is a test where this triggers. It means: "For equality operator expressions x==y and x!=y, a synthesized candidate with the order of the two parameters reversed is added for each member, non-member, and built-in operator=='s found."
[Bug c++/93881] cxx-pretty-print: only few i18n strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93881 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- Although "requires" is a C++20 keyword, in this case it is not meant as that AFAICS; here it's an ordinary English verb. Used e.g. in auto1.C:16:13: error: unable to deduce ‘A, >], auto [requires C<, >]>’ from ‘a2’ because a2 has wrong types.
[Bug c++/93882] i18n: use consistent message template in decl.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93882 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Marek Polacek --- Fixed.
[Bug c++/93882] i18n: use consistent message template in decl.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93882 --- Comment #2 from CVS Commits --- The master branch has been updated by Marek Polacek : https://gcc.gnu.org/g:6cd5024c8643b4359825219cdc3ae7280018d06d commit r10-6798-g6cd5024c8643b4359825219cdc3ae7280018d06d Author: Marek Polacek Date: Sat Feb 22 11:53:45 2020 -0500 c++: Use %qs in diagnostic message [PR93882] A tweak for translators, as requested in the PR. 2020-02-22 Marek Polacek PR c++/93882 * decl.c (grokdeclarator): Use %qs in a diagnostic message.
[Bug libfortran/93871] COTAN is slow for complex types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871 --- Comment #16 from Thomas Henlich --- Additional note: The issue is not restricted to complex types, but also occurs for real types. On i686-mingw32, by a factor 2...10 depending on kind. However I could not measure any slowdown on i686-pc-linux-gnu. Due to this, and my earlier confusion about mpc/mpfr, I chose not to include it in this bug report.
[Bug c++/93883] New: missing test for diagnostic: using-declaration may not name enumerator %<%E::%D%>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93883
Bug ID: 93883
Summary: missing test for diagnostic: using-declaration may not
name enumerator %<%E::%D%>
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
From name-lookup.c:
> error ("using-declaration may not name enumerator %<%E::%D%>",
As the German i18n translator, I am unsure how to translate this diagnostic. To
get an impression about the code that produces such diagnostic, I'd like to see
some example code that triggers this error.
The existing tests don't contain the string "using-declaration may not name
enumerator", therefore I suspect that no such test exists.
[Bug c++/93882] i18n: use consistent message template in decl.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93882 Marek Polacek changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-02-22 CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Ok, will fix.
[Bug libfortran/93871] COTAN is slow for complex types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871 --- Comment #15 from Steve Kargl --- On Sat, Feb 22, 2020 at 10:17:17AM +, thenlich at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871 > > --- Comment #14 from Thomas Henlich --- > Come for the runtime, stay for the ICE! To improve the runtime, one needs to rework gfc_resolve_cotan(). This is where sin(x) and cos(x) are evaluated, then the quotient is taken. The slowness comes from doing the argument reduction twice. For some architectures, it can be improved by computed cexp() and then using the real and imaginary parts to compute cotan(). Why? On some architectures, cexp() is computed via __builtin_sincos().
[Bug c++/93882] New: i18n: use consistent message template in decl.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93882
Bug ID: 93882
Summary: i18n: use consistent message template in decl.c
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
From decl.c:
error_at (declspecs->locations[ds_consteval],
"%qs cannot appear in a typedef declaration", "consteval");
return error_mark_node;
}
if (constinit_p && typedef_p)
{
error_at (declspecs->locations[ds_constinit],
"% cannot appear in a typedef declaration");
return error_mark_node;
}
The second error_at should use %qs in the same way as the first error_at. This
creates less work for the i18n translators.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #197 from dave.anglin at bell dot net --- On 2020-02-21 11:43 p.m., peter.bisroev at groundlabs dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 > > --- Comment #195 from Peter Bisroev --- > Hi Dave, > > I was doing a bit more searching and found this doc from HP, "Solaris to HP-UX > Porting Guide" > (http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.475.5577=rep1=pdf). > I know it is not from hpe.com but seems to be an official HP document HP-UX > 11i > v2 and later. > > Anyway, on page 56, it states: > -- > In Solaris, symbols can be set with a pragma to be weak, which means that > these > symbols are always overridden by any global definition. If an undefined weak > symbol is never satisfied by a global definition, it is set to 0 before the > program starts execution. HP_SECONDARY_DEF symbols are similar to Solaris weak > symbols, but there are some differences. You can use the _HP_SECONDARY_DEF > pragma to connect a weak and a strong definition (for example, _fopen and > fopen). The weak definition can be overridden by other strong definitions. > -- > > I guess that confirms your statement about sdef. > > On page 85, it states: > -- > The ELF file format provides support for global, local, and weak symbols. > Creating these symbols requires support from the compiler. The HP C and HP C++ > compilers do not provide support for weak symbols. > > The HP-UX 11i v2 and later assembler (/usr/ccs/bin/as) provides support using > the .weak directive. Example 7-3 “Weak Function Binding Using ASM” defines > weakfunc to be a weak binding to func. Details on the assembler can be found > in > the Itanium Architecture Assembly Language Reference Guide. > -- > I guess that confirms your suspicion that aCC does not support weak symbols > and > my results that .weak is supported by HP's assembler. Yes. Thus, ia64 running hpux is essentially the same as hppa64 running hpux in its support for weak (sdef) symbols. We didn't hit the long branch issue I guess because pc-relative branches go a factor of two further, and maybe the -O0 code generation is denser.
[Bug c++/93881] New: cxx-pretty-print: only few i18n strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93881
Bug ID: 93881
Summary: cxx-pretty-print: only few i18n strings
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
From cxx-pretty-print.c:
> pp_cxx_ws_string (pp, "requires");
> pp->translate_string ("requires");
It feels strange to me that the word "requires" is i18n-translated in some
cases and not in other cases.
Since there are only 5 matches of "->translate_string" in the whole file, it
looks to me as if most of the generated text is in English (or GIMPLE) anyway,
and that sprinkling a few German words in-between would be more irritating than
helpful.
Is translate_string really meant for i18n?
[Bug other/55930] [8/9 Regression] libatomic build failure if configured with --disable-dependency-tracking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55930 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com Summary|[8/9/10 Regression] |[8/9 Regression] libatomic |libatomic build failure if |build failure if configured |configured with |with |--disable-dependency-tracki |--disable-dependency-tracki |ng |ng --- Comment #18 from Jeffrey A. Law --- I concur with Jon, this is trivial enough not to need any kind of paperwork. I've committed the patch to the trunk. I'm not planning to backport, but I wouldn't object if someone else did. Thanks for the patch Richard. Jon, thanks for marking the regression. Otherwise it would have been missed for (yet another) cycle.
[Bug other/55930] [8/9/10 Regression] libatomic build failure if configured with --disable-dependency-tracking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55930 --- Comment #17 from CVS Commits --- The master branch has been updated by Jeff Law : https://gcc.gnu.org/g:d6f420d98126ac51396b89fbe287a32287cd92ed commit r10-6797-gd6f420d98126ac51396b89fbe287a32287cd92ed Author: Richarde Purdie Date: Sat Feb 22 10:13:13 2020 -0500 Honor --disable-dependency-tracking in libatomic PR other/55930 * Makefile.am (M_DEPS): Honor -disable-dependency-tracking. * Makefile.in: Regenerated.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #196 from dave.anglin at bell dot net --- On 2020-02-21 10:55 p.m., peter.bisroev at groundlabs dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 > > --- Comment #194 from Peter Bisroev --- > (In reply to dave.anglin from comment #193) >> I presume that if you compile main.cc with g++, hello() becomes weak. You >> could test with a second instance of hello. > Yes, sorry forgot to mention that. When I compile with gcc hello() becomes > weak > as expected. One question though, what do you mean with the second instance of > hello? If you create a second object file with a second instance of hello, the linker should not complain about the second definition of hello since it is weak. It would complain about two global instances. One major difference between GNU weak definitions and HP sdef definitions is that the HP linker and dynamic loader don't like undefined sdef symbols. In PA-RISC, there's no way to override this in the dynamic loader. > The comdat testing that I have performed in comment 181 and comment 185 by > forcing the use of comdat with --enable-comdat definitely made things better > as > we got a significant reduction in PCREL21B linking errors. However some still > remained. Is it because the use of --enable-comdat did not apply to all the > code (such as libraries), or even when usage of comdat is forced, HP's ld > still > keeps unnecessary instances around? I don't know whether HP's ld removes unecessary comdat instances. Even with comdat groups enabled, I think we still have some use of weak because of how MAKE_DECL_ONE_ONLY is defined. Could you test whether the "brl" branch works? Simply take your main.s file and edit the branch to hello. This should show whether the assembler can handle it. If it assembles, look at relocation and see if program will link.
[Bug fortran/93599] [9/10 regression] Bug in fortran asynchronous I/O wait function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93599 Thomas Koenig changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #15 from Thomas Koenig --- Fixed on trunk and gcc-9. Thanks a lot for the bug report and the testing!
[Bug c++/93880] New: missing test for diagnostic: %s%#qD (reversed)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93880 Bug ID: 93880 Summary: missing test for diagnostic: %s%#qD (reversed) Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- From cp/call.c: > inform (cloc, "%s%#qD (reversed)", msg, fn); As the German i18n translator, I'm unsure how to translate this message. To get more confidence, I searched for automatic tests containing the string "(reversed)", but I didn't find one. Other diagnostics have easily readable tests demonstrating code that triggers the diagnostic and code that doesn't trigger it. Such a test should be added for this diagnostic as well.
[Bug c/93879] New: typo: frequency quality
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93879 Bug ID: 93879 Summary: typo: frequency quality Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- From gimple-parser.c: > c_parser_error (parser, "expected frequency quality"); The word "quality" looks like a copy-and-paste mistake from the message below it, which is "expected profile quality". There should be an automatic test for this diagnostic, which would have probably caught this mistake before it reaches the i18n translator. :)
[Bug c/93878] New: -Wfloat-equal complains even in safe cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93878
Bug ID: 93878
Summary: -Wfloat-equal complains even in safe cases
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: roland.illig at gmx dot de
Target Milestone: ---
$ cat float.c
#include
int f(float a, float b) {
float rounded = roundf(b);
if (a < 0) return 1;
if (a == 3.0) return 2;
if (rounded == 3.0) return 3;
if (a == b) return 4;
return 5;
}
$ gcc -Wall -Os -Wextra -Wfloat-equal -c float.c
float.c: In function ‘f’:
float.c:6:11: warning: comparing floating point with == or != is unsafe
[-Wfloat-equal]
6 | if (a == 3.0) return 2;
| ^~
float.c:7:17: warning: comparing floating point with == or != is unsafe
[-Wfloat-equal]
7 | if (rounded == 3.0) return 3;
| ^~
float.c:8:11: warning: comparing floating point with == or != is unsafe
[-Wfloat-equal]
8 | if (a == b) return 4;
| ^~
The case "a == 3.0" may be debatable. But the case "rounded == 3.0" is
perfectly safe since the number is rounded before being compared.
These test cases should be added to the test suite for this diagnostic, to
demonstrate the current behavior and limitations.
There are probably many other situations that are safe as well, therefore it's
good that -Wfloat-equal is neither included in -Wall nor in -Wextra. Thanks for
that. :)
[Bug middle-end/91623] [8 Regression] -msse4.1 -O3 segfault in /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/include/smmintrin.h:270:10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91623 --- Comment #16 from David Seifert --- (In reply to David Seifert from comment #15) > Created attachment 47887 [details] > preprocessed_example.c.gz > > Running GCC 9.2 with > > gcc-9.2.0 -msse4.1 -O3 -c preprocessed_example.c -o foo.o > > on this file yields > > $ gcc-9.2.0 -msse4.1 -O3 -c preprocessed_example.c -o foo.o > during RTL pass: expand > In file included from src/nw_stats_diag_sse41_128_64.c:16: > /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/include/smmintrin.h: In function > ‘parasail_nw_stats_rowcol_diag_sse41_128_64’: > /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/include/smmintrin.h:270:10: internal > compiler error: Segmentation fault > 270 | return (__m128i) ((__v2di)__X == (__v2di)__Y); > | ^~ Just to clarify, this issue also occurs with GCC 7.5, that already has the supposed fix.
[Bug fortran/93599] [9/10 regression] Bug in fortran asynchronous I/O wait function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93599 --- Comment #14 from CVS Commits --- The releases/gcc-9 branch has been updated by Thomas Kथघnig : https://gcc.gnu.org/g:c080a6fb6f0cf402affc287fc600c189980cfb2d commit r9-8264-gc080a6fb6f0cf402affc287fc600c189980cfb2d Author: Thomas König Date: Thu Feb 13 22:22:04 2020 +0100 Use au->lock exclusively for locking in async I/O. 2020-02-18 Thomas Koenig Backport from trunk PR fortran/93599 * io/async.c (destroy_adv_cond): Do not destroy lock. (async_io): Make sure au->lock is locked for finishing of thread. Do not lock/unlock around signalling emptysignal. Unlock au->lock before return. (init_adv_cond): Do not initialize lock. (enqueue_transfer): Unlock after signal. (enqueue_done_id): Likewise. (enqueue_done): Likewise. (enqueue_close): Likewise. (enqueue_data_transfer): Likewise. (async_wait_id): Do not lock/unlock around signalling au->work. (async_wait): Unlock after signal. * io/async.h (SIGNAL): Add comment about needed au->lock. Remove locking/unlocking of advcond->lock. (WAIT_SIGNAL_MUTEX): Add comment. Remove locking/unlocking of advcond->lock. Unlock mutex only at the end. Loop on __ghread_cond_wait returning zero. (REVOKE_SIGNAL): Add comment. Remove locking/unlocking of advcond->lock. (struct adv_cond): Remove mutex from struct.
[Bug middle-end/91623] [8 Regression] -msse4.1 -O3 segfault in /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/include/smmintrin.h:270:10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91623 --- Comment #15 from David Seifert --- Created attachment 47887 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47887=edit preprocessed_example.c.gz Running GCC 9.2 with gcc-9.2.0 -msse4.1 -O3 -c preprocessed_example.c -o foo.o on this file yields $ gcc-9.2.0 -msse4.1 -O3 -c preprocessed_example.c -o foo.o during RTL pass: expand In file included from src/nw_stats_diag_sse41_128_64.c:16: /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/include/smmintrin.h: In function ‘parasail_nw_stats_rowcol_diag_sse41_128_64’: /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/include/smmintrin.h:270:10: internal compiler error: Segmentation fault 270 | return (__m128i) ((__v2di)__X == (__v2di)__Y); | ^~
[Bug c/82283] Wrong warning with -Wmissing-field-initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82283
--- Comment #4 from Yann Droneaud ---
Also with the ({}) GCC extension:
struct a {
int b;
int c;
};
void d(struct a *);
void e(void) {
struct a f = {
.b = ({
int g = 0;
g;
})
};
d();
}
It produces the warning:
: In function 'e':
:10:17: error: missing initializer for field 'c' of 'struct a'
[-Werror=missing-field-initializers]
10 | })};
| ^
:3:7: note: 'c' declared here
3 | int c;
| ^
cc1: all warnings being treated as errors
Compiler returned: 1
See https://godbolt.org/z/VJAuv4
(Note: this example and the one above were reduced by c-reduce
https://embed.cs.utah.edu/creduce/ )
[Bug libfortran/93871] COTAN is slow for complex types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871 --- Comment #14 from Thomas Henlich --- Come for the runtime, stay for the ICE!
[Bug target/93877] [9 10 Regression] [SH] webkit2gtk fails to build with "internal compiler error: in extract_constrain_insn, at recog.c:2211"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93877 --- Comment #3 from John Paul Adrian Glaubitz --- Building with -O1 instead of -O2 helps. I can try to bisect the optimization flag which causes this problem later.
[Bug target/93877] [9 10 Regression] [SH] webkit2gtk fails to build with "internal compiler error: in extract_constrain_insn, at recog.c:2211"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93877 --- Comment #2 from John Paul Adrian Glaubitz --- This bug does not affect gcc-8. It affects gcc-9 and gcc-10. Using -mlra does not help.
[Bug target/93876] [9 10 Regression] [SH] webkit2gtk fails to build with "error: unable to find a register to spill in class 'R0_REGS'"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93876 Oleg Endo changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #8 from Oleg Endo --- Closing as 'won't fix'
[Bug target/93877] [9 10 Regression] [SH] webkit2gtk fails to build with "internal compiler error: in extract_constrain_insn, at recog.c:2211"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93877 --- Comment #1 from John Paul Adrian Glaubitz --- Created attachment 47886 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47886=edit Source and preprocessed source plus assembly
[Bug target/93877] New: [9 10 Regression] [SH] webkit2gtk fails to build with "internal compiler error: in extract_constrain_insn, at recog.c:2211"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93877
Bug ID: 93877
Summary: [9 10 Regression] [SH] webkit2gtk fails to build with
"internal compiler error: in extract_constrain_insn,
at recog.c:2211"
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: glaubitz at physik dot fu-berlin.de
CC: jrtc27 at jrtc27 dot com, kkojima at gcc dot gnu.org,
olegendo at gcc dot gnu.org
Target Milestone: ---
Target: sh*-*-*
As mentioned in PR91913, the issue reported there for ARM affects SH as well
when building webkit2gtk on Debian sh4:
(sid-sh4-sbuild)root@nofan:/build/webkit2gtk-huItPy/webkit2gtk-2.26.4/build#
g++-9 -DANGLE_ENABLE_ESSL -DANGLE_ENABLE_GLSL -DBUILDING_GTK__=1
-DBUILDING_WITH_CMAKE=1 -DEGL_EGL_PROTOTYPES=0
-DGETTEXT_PACKAGE=\"WebKit2GTK-4.0\" -DGL_GLES_PROTOTYPES=0 -DHAVE_CONFIG_H=1
-DJSC_GLIB_API_ENABLED -DLIBANGLE_IMPLEMENTATION
-DWEBKITGTK_API_VERSION_STRING=\"4.0\" -I../Source/ThirdParty/ANGLE/include
-I../Source/ThirdParty/ANGLE/include/KHR -I../Source/ThirdParty/ANGLE/src
-I../Source/ThirdParty/ANGLE/src/common/third_party/base
-fdiagnostics-color=always -Wextra -Wall -Wno-expansion-to-defined -Wno-psabi
-Wno-noexcept-type -Wno-maybe-uninitialized -Wwrite-strings -Wundef
-Wpointer-arith -Wmissing-format-attribute -Wformat-security -Wcast-align -g1
-O2 -fdebug-prefix-map=/build/webkit2gtk-huItPy/=.
-specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -mlra -DNDEBUG
-DG_DISABLE_CAST_CHECKS -fno-strict-aliasing -fno-exceptions -fno-rtti -fPIC
-Wno-cast-align -Wno-suggest-attribute=format -Wno-type-limits -Wno-undef
-Wno-unused-parameter -std=c++17 -MD -MT
Source/ThirdParty/ANGLE/CMakeFiles/ANGLE.dir/src/compiler/translator/IntermNode.cpp.o
-MF
Source/ThirdParty/ANGLE/CMakeFiles/ANGLE.dir/src/compiler/translator/IntermNode.cpp.o.d
-o
Source/ThirdParty/ANGLE/CMakeFiles/ANGLE.dir/src/compiler/translator/IntermNode.cpp.o
-c ../Source/ThirdParty/ANGLE/src/compiler/translator/IntermNode.cpp
../Source/ThirdParty/ANGLE/src/compiler/translator/IntermNode.cpp: In static
member function 'static sh::TConstantUnion*
sh::TIntermConstantUnion::FoldAggregateBuiltIn(sh::TIntermAggregate*,
sh::TDiagnostics*)':
../Source/ThirdParty/ANGLE/src/compiler/translator/IntermNode.cpp:3747:1:
error: insn does not satisfy its constraints:
3747 | }
| ^
(insn 9655 9654 3155 385 (parallel [
(set (reg:SF 66 fr2 [orig:645 _696 ] [645])
(reg:SF 0 r0 [3233]))
(use (reg:SI 154 fpscr0))
(clobber (scratch:SI))
]) 214 {movsf_ie}
(expr_list:REG_DEAD (reg:SF 0 r0 [3233])
(nil)))
during RTL pass: cprop_hardreg
../Source/ThirdParty/ANGLE/src/compiler/translator/IntermNode.cpp:3747:1:
internal compiler error: in extract_constrain_insn, at recog.c:2211
[Bug target/93876] [9 10 Regression] [SH] webkit2gtk fails to build with "error: unable to find a register to spill in class 'R0_REGS'"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93876 --- Comment #7 from John Paul Adrian Glaubitz --- (In reply to Oleg Endo from comment #6) > If -mlra helps with this case, then let's close this one as 'WON'T FIX', ok? Yes, I'll open a new issue for the actual bug I wanted to report. I can reproduce it just fine.
[Bug c/82283] Wrong warning with -Wmissing-field-initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82283
Yann Droneaud changed:
What|Removed |Added
CC||yann at droneaud dot fr
--- Comment #3 from Yann Droneaud ---
I'm experiencing the same issue in multiple cases, even with latest GCC trunk
(10.x).
I believe the following code is C99 conformant, but still trigger an unexpected
warning:
struct a {
int b;
};
struct c {
struct a d;
int e;
};
void f(struct c *);
void g(void) {
struct c h = {.d = (struct a){0}};
f();
}
It produces the following warning:
: In function 'g':
:10:30: error: missing initializer for field 'e' of 'struct c'
[-Weror=missing-field-initializers]
10 | struct c h = {.d = (struct a){0}};
| ^
:6:7: note: 'e' declared here
6 | int e;
| ^
cc1: all warnings being treated as errors
Compiler returned: 1
See https://godbolt.org/z/vQLYRX
[Bug target/93876] [9 10 Regression] [SH] webkit2gtk fails to build with "error: unable to find a register to spill in class 'R0_REGS'"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93876 --- Comment #6 from Oleg Endo --- If -mlra helps with this case, then let's close this one as 'WON'T FIX', ok?
[Bug target/93876] [9 10 Regression] [SH] webkit2gtk fails to build with "error: unable to find a register to spill in class 'R0_REGS'"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93876 --- Comment #5 from John Paul Adrian Glaubitz --- (In reply to Oleg Endo from comment #4) > the error message is > > unable to find a register to spill in class 'R0_REGS' > > please try to re-build with -mlra Yes, that helps and I just realized that I reported the wrong issue since building webkit2gtk provokes multiple bugs. The one I mentioned in PR91913 affected a different source file.
[Bug target/93876] [9 10 Regression] [SH] webkit2gtk fails to build with "error: unable to find a register to spill in class 'R0_REGS'"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93876 --- Comment #4 from Oleg Endo --- the error message is unable to find a register to spill in class 'R0_REGS' please try to re-build with -mlra
[Bug target/93808] [9 Regression] [SH] Ruby crashes with 'Illegal Instruction' with -fcrossjumping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93808 --- Comment #23 from Oleg Endo --- (In reply to Oleg Endo from comment #22) > > I see at least one encoder function that ... does not check that p is >= e and blindly starts reading data at p. ... so I'd like to try to narrow it down a bit.
[Bug target/93808] [9 Regression] [SH] Ruby crashes with 'Illegal Instruction' with -fcrossjumping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93808
--- Comment #22 from Oleg Endo ---
(In reply to Andrew Pinski from comment #21)
>
> I think it is more by accident.strict-alginment here should not make a
> difference really as it is undefined even on non-strict targets.
> fcross-jumping in this case causes the BB that contains
> __builtin_unreachable to go to an invalid basic-block which is valid
> optimization which just happens on sh and for some reason not arm or other
> targets. I have not looked into the code or even the RTL to double check
> this theory though.
But then that would mean, the code is just generally undefined and might reach
the "unreachable" cases in any case.
The function 'search_nonascii' is used in the crashing function
'coderange_scan' 3 times. It's a bit difficult to see what's going on in the
resulting code. Prohibiting the inlining with...
--- "orig ng/string.c.orig" 2019-10-01 20:02:30.0 +0900
+++ "orig ng/string.c" 2020-02-22 17:12:02.624621304 +0900
@@ -436,7 +436,7 @@
VALUE rb_fs;
-static inline const char *
+static const char * __attribute__((noinline))
search_nonascii(const char *p, const char *e)
{
const uintptr_t *s, *t;
...results in a more straight forward code of course. In that case the
unreachable case just falls through into one of the other cases, so the code
will not crash, but it will also not work correctly. The latter switch is also
not translated into a jump table but a series of simple comparisons.
One thing I've noticed ...
if (0 || e - p >= 4)
this line uses a signed comparison for e-p >= 4 in the final code.
If 'p' is greater than 'e', then this code will do nonsense. It might then go
into the unreachable case in the latter switch.
'p' is modified in the calling function 'coderange_scan' like so
p += (ret);
if 'ret' is >= 0, where ret is the return value of function
'rb_enc_precise_mbclen', which in turn calls
(enc)->precise_mbc_enc_len(p,e,enc)
through the macro ONIGENC_PRECISE_MBC_ENC_LEN
I see at least one encoder function that
Adrian, could please apply the following patch to the original string.c file
and try building & running the whole thing again with the original compiler
flags, with -fno-cross-jumping and with -O1. Does one of the added traps go
off?
--- "orig ng/string.c.orig" 2019-10-01 20:02:30.0 +0900
+++ "orig ng/string.c" 2020-02-22 18:29:54.904783490 +0900
@@ -446,13 +446,15 @@
# define NONASCII_MASK 0x80808080UL
#endif
+if ( (intptr_t)(e-p) < 0) __builtin_trap ();
+
if (UNALIGNED_WORD_ACCESS || e - p >= SIZEOF_VOIDP) {
#if !UNALIGNED_WORD_ACCESS
if ((uintptr_t)p % SIZEOF_VOIDP) {
int l = SIZEOF_VOIDP - (uintptr_t)p % SIZEOF_VOIDP;
p += l;
switch (l) {
- default: UNREACHABLE;
+ default: __builtin_trap ();
#if SIZEOF_VOIDP > 4
case 7: if (p[-7]&0x80) return p-7;
case 6: if (p[-6]&0x80) return p-6;
@@ -481,7 +483,7 @@
}
switch (e - p) {
- default: UNREACHABLE;
+ default: __builtin_trap ();
#if SIZEOF_VOIDP > 4
case 7: if (e[-7]&0x80) return e-7;
case 6: if (e[-6]&0x80) return e-6;
[Bug target/93876] [9 10 Regression] [SH] webkit2gtk fails to build with "error: unable to find a register to spill in class 'R0_REGS'"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93876 --- Comment #3 from John Paul Adrian Glaubitz --- The problem does not affect gcc-8. It affects gcc-9 and gcc-10.
[Bug target/93876] [9 10 Regression] [SH] webkit2gtk fails to build with "error: unable to find a register to spill in class 'R0_REGS'"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93876 --- Comment #2 from John Paul Adrian Glaubitz --- Created attachment 47885 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47885=edit Source and preprocessed source plus assembly
[Bug target/93876] [9 10 Regression] [SH] webkit2gtk fails to build with "error: unable to find a register to spill in class 'R0_REGS'"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93876 --- Comment #1 from John Paul Adrian Glaubitz --- Command line is: /usr/bin/c++ -DBUILDING_GTK__=1 -DBUILDING_JavaScriptCore -DBUILDING_WITH_CMAKE=1 -DGETTEXT_PACKAGE=\"WebKit2GTK-4.0\" -DHAVE_CONFIG_H=1 -DJSC_COMPILATION -DJSC_GLIB_API_ENABLED -DJavaScriptCore_EXPORTS -DSTATICALLY_LINKED_WITH_WTF -DWEBKITGTK_API_VERSION_STRING=\"4.0\" -IDerivedSources/ForwardingHeaders -I. -I../Source/JavaScriptCore -I../Source/JavaScriptCore/API -I../Source/JavaScriptCore/assembler -I../Source/JavaScriptCore/b3 -I../Source/JavaScriptCore/b3/air -I../Source/JavaScriptCore/bindings -I../Source/JavaScriptCore/builtins -I../Source/JavaScriptCore/bytecode -I../Source/JavaScriptCore/bytecompiler -I../Source/JavaScriptCore/dfg -I../Source/JavaScriptCore/disassembler -I../Source/JavaScriptCore/disassembler/ARM64 -I../Source/JavaScriptCore/disassembler/udis86 -I../Source/JavaScriptCore/domjit -I../Source/JavaScriptCore/ftl -I../Source/JavaScriptCore/heap -I../Source/JavaScriptCore/debugger -I../Source/JavaScriptCore/inspector -I../Source/JavaScriptCore/inspector/agents -I../Source/JavaScriptCore/inspector/augmentable -I../Source/JavaScriptCore/inspector/remote -I../Source/JavaScriptCore/interpreter -I../Source/JavaScriptCore/jit -I../Source/JavaScriptCore/llint -I../Source/JavaScriptCore/parser -I../Source/JavaScriptCore/profiler -I../Source/JavaScriptCore/runtime -I../Source/JavaScriptCore/tools -I../Source/JavaScriptCore/wasm -I../Source/JavaScriptCore/wasm/js -I../Source/JavaScriptCore/yarr -IDerivedSources/JavaScriptCore -IDerivedSources/JavaScriptCore/inspector -IDerivedSources/JavaScriptCore/runtime -IDerivedSources/JavaScriptCore/yarr -IDerivedSources/ForwardingHeaders/JavaScriptCore/glib -IDerivedSources/JavaScriptCore/javascriptcoregtk/jsc -I../Source/JavaScriptCore/API/glib -IDerivedSources/JavaScriptCore/javascriptcoregtk -I../Source/JavaScriptCore/inspector/remote/glib -IDerivedSources -I../Source/ThirdParty -isystem /usr/include/glib-2.0 -isystem /usr/lib/sh4-linux-gnu/glib-2.0/include -fdiagnostics-color=always -Wextra -Wall -Wno-expansion-to-defined -Wno-psabi -Wno-noexcept-type -Wno-maybe-uninitialized -Wwrite-strings -Wundef -Wpointer-arith -Wmissing-format-attribute -Wformat-security -Wcast-align -g1 -O2 -fdebug-prefix-map=/<>=. -specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -DNDEBUG -DG_DISABLE_CAST_CHECKS -fno-strict-aliasing -fno-exceptions -fno-rtti -fPIC -ffp-contract=off -std=c++17 -MD -MT Source/JavaScriptCore/CMakeFiles/JavaScriptCore.dir/__/__/DerivedSources/JavaScriptCore/unified-sources/UnifiedSource-f2e18ffc-15.cpp.o -MF Source/JavaScriptCore/CMakeFiles/JavaScriptCore.dir/__/__/DerivedSources/JavaScriptCore/unified-sources/UnifiedSource-f2e18ffc-15.cpp.o.d -o Source/JavaScriptCore/CMakeFiles/JavaScriptCore.dir/__/__/DerivedSources/JavaScriptCore/unified-sources/UnifiedSource-f2e18ffc-15.cpp.o -c DerivedSources/JavaScriptCore/unified-sources/UnifiedSource-f2e18ffc-15.cpp
[Bug target/93876] New: [9 10 Regression] [SH] webkit2gtk fails to build with "error: unable to find a register to spill in class 'R0_REGS'"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93876
Bug ID: 93876
Summary: [9 10 Regression] [SH] webkit2gtk fails to build with
"error: unable to find a register to spill in class
'R0_REGS'"
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: glaubitz at physik dot fu-berlin.de
CC: gcc-bugzilla at mkarcher dot dialup.fu-berlin.de,
jrtc27 at jrtc27 dot com, kkojima at gcc dot gnu.org,
olegendo at gcc dot gnu.org
Target Milestone: ---
Target: sh*-*-*
Trying to build webkit2gtk on Debian sh4 with gcc-9/gcc-10 fails with:
../Source/JavaScriptCore/runtime/JSArrayBufferView.cpp: In member function
'JSC::ArrayBuffer* JSC::JSArrayBufferView::slowDownAndWasteMemory()':
../Source/JavaScriptCore/runtime/JSArrayBufferView.cpp:298:1: error: unable to
find a register to spill in class 'R0_REGS'
298 | }
| ^
../Source/JavaScriptCore/runtime/JSArrayBufferView.cpp:298:1: error: this is
the insn:
(insn 419 418 425 47 (parallel [
(set (subreg:SI (reg:QI 433) 0)
(unspec_volatile:SI [
(mem/v:QI (reg/f:SI 3 r3 [orig:487 _347 ] [487]) [-1
S1 A8])
(reg:QI 7 r7 [425])
(subreg:QI (reg:SI 5 r5 [432]) 0)
] UNSPECV_CMPXCHG_1))
(set (mem/v:QI (reg/f:SI 3 r3 [orig:487 _347 ] [487]) [-1 S1 A8])
(unspec_volatile:QI [
(const_int 0 [0])
] UNSPECV_CMPXCHG_2))
(set (reg:SI 147 t)
(unspec_volatile:SI [
(const_int 0 [0])
] UNSPECV_CMPXCHG_3))
(clobber (scratch:SI))
(clobber (reg:SI 0 r0))
(clobber (reg:SI 1 r1))
]) "/usr/include/c++/10/bits/atomic_base.h":464:36 405
{atomic_compare_and_swapqi_soft_gusa}
(expr_list:REG_DEAD (reg:SI 5 r5 [432])
(expr_list:REG_DEAD (reg:QI 7 r7 [425])
(expr_list:REG_UNUSED (reg:QI 433)
(expr_list:REG_UNUSED (reg:SI 1 r1)
(expr_list:REG_UNUSED (reg:SI 0 r0)
(nil)))
../Source/JavaScriptCore/runtime/JSArrayBufferView.cpp:298: confused by earlier
errors, bailing out
