[Bug jit/105829] Allow getting the size of floating-point types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105829 Antoni changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Antoni --- I pushed the updated patch to master.
[Bug jit/105829] Allow getting the size of floating-point types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105829 --- Comment #2 from CVS Commits --- The master branch has been updated by Antoni Boucher : https://gcc.gnu.org/g:5940b4e59f8e198dbf7e8b733561ef72a9ba2cbc commit r13-1036-g5940b4e59f8e198dbf7e8b733561ef72a9ba2cbc Author: Antoni Boucher Date: Thu Jun 9 21:37:23 2022 -0400 libgccjit: Support getting the size of a float [PR105829] 2022-06-09 Antoni Boucher gcc/jit/ PR jit/105829 * libgccjit.cc: Add support for floating-point types in gcc_jit_type_get_size. gcc/testsuite/ PR jit/105829 * jit.dg/test-types.c: Add tests for gcc_jit_type_get_size.
[Bug c++/74765] missing uninitialized warning (parenthesis, TREE_NO_WARNING abuse)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=74765
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
--- Comment #10 from Eric Botcazou ---
I don't understand the new code in gimple_set_location:
static inline void
gimple_set_location (gimple *g, location_t location)
{
/* Copy the no-warning data to the statement location. */
copy_warning (location, g->location);
g->location = location;
}
Typically g->location is UNKNOWN_LOCATION since the GIMPLE statement was just
built so this does:
copy_warning (location, UNKNOWN_LOCATION);
and finally invokes nowarn_map->remove (location)?
I can fix my particular problem by adding the obvious guard:
static inline void
gimple_set_location (gimple *g, location_t location)
{
/* Copy the no-warning data to the statement location. */
if (g->location != UNKNOWN_LOCATION)
copy_warning (location, g->location);
g->location = location;
}
but shouldn't the code query warning-control.cc instead to see if the
no-warning bit is set on g?
[Bug c++/105912] internal compiler error: in extract_call_expr, at cp/call.cc:7114
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105912 --- Comment #3 from Marek Polacek --- The ICE started with r277733 commit f968ef9b8df2bc2287e5e7e87299e5a2a44e8c94 Author: Jakub Jelinek Date: Sat Nov 2 00:28:20 2019 +0100 PR c++/88335 - Implement P1073R3: Immediate functions
[Bug c++/104642] Add __builtin_trap() for missing return at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104642 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/105912] internal compiler error: in extract_call_expr, at cp/call.cc:7114
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105912 Marek Polacek changed: What|Removed |Added Ever confirmed|0 |1 Keywords||ice-on-invalid-code CC||mpolacek at gcc dot gnu.org Last reconfirmed||2022-06-09 Status|UNCONFIRMED |NEW --- Comment #2 from Marek Polacek --- Thanks for the reduction, confirmed.
[Bug c++/105912] internal compiler error: in extract_call_expr, at cp/call.cc:7114
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105912
--- Comment #1 from Luke Dalessandro ---
Somewhat reduced testcase:
template struct A {};
template struct B {};
template
static consteval auto operator~(A) -> B {
return {};
}
A<'i'> i;
template
auto test() -> bool {
auto ii = ~i; // ICE HERE
return true;
}
int main()
{
bool i = test();
}
https://godbolt.org/z/rEf4neexc
[Bug c++/105912] New: internal compiler error: in extract_call_expr, at cp/call.cc:7114
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105912 Bug ID: 105912 Summary: internal compiler error: in extract_call_expr, at cp/call.cc:7114 Product: gcc Version: 12.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ldalessandro at gmail dot com Target Milestone: --- Created attachment 53113 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53113&action=edit output from -freport-bug ICE in complex constexpr/consteval context. I think this code is invalid. Debian testing gcc-12.1. - [ 83%] Building CXX object tests/CMakeFiles/expressions.dir/expressions.cpp.o /home/ldalessa/open/ttl/tests/expressions.cpp: In instantiation of ‘constexpr bool contraction(ttl::utils::type_args) [with T = int]’: /home/ldalessa/open/ttl/tests/expressions.cpp:589:24: required from ‘constexpr bool tests(ttl::utils::type_args) [with T = int]’ /home/ldalessa/open/ttl/tests/expressions.cpp:600:19: required from here /home/ldalessa/open/ttl/tests/expressions.cpp:149:13: internal compiler error: in extract_call_expr, at cp/call.cc:7114 149 | T dot = a(~i) * a(i); | ^~ 0x65a180 extract_call_expr(tree_node*) ../../src/gcc/cp/call.cc:7114 0x80b0cb tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) ../../src/gcc/cp/pt.cc:20971 0x819ea1 tsubst_copy_and_build_call_args ../../src/gcc/cp/pt.cc:19937 0x80ae60 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) ../../src/gcc/cp/pt.cc:20687 0x80a6a7 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) ../../src/gcc/cp/pt.cc:20322 0x81b618 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) ../../src/gcc/cp/pt.cc:19491 0x822f79 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) ../../src/gcc/cp/pt.cc:16770 0x822f79 tsubst_init ../../src/gcc/cp/pt.cc:16774 0x81dc83 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) ../../src/gcc/cp/pt.cc:18643 0x81cb62 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) ../../src/gcc/cp/pt.cc:18462 0x81cb62 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) ../../src/gcc/cp/pt.cc:18476 0x81c158 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) ../../src/gcc/cp/pt.cc:18462 0x81c158 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) ../../src/gcc/cp/pt.cc:18833 0x81ab7c tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) ../../src/gcc/cp/pt.cc:26412 0x81ab7c instantiate_body ../../src/gcc/cp/pt.cc:26412 0x81b439 instantiate_decl(tree_node*, bool, bool) ../../src/gcc/cp/pt.cc:26704 0x6d4962 cxx_eval_call_expression ../../src/gcc/cp/constexpr.cc:2664 0x6d6f68 cxx_eval_constant_expression ../../src/gcc/cp/constexpr.cc:6720 0x6d9011 cxx_eval_constant_expression ../../src/gcc/cp/constexpr.cc:6828 0x6d6ebe cxx_eval_constant_expression ../../src/gcc/cp/constexpr.cc:7044
[Bug jit/100613] libgccjit should produce dylib on macOS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100613 Iain Sandoe changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #7 from Iain Sandoe --- so fixed on open branches.
[Bug jit/100613] libgccjit should produce dylib on macOS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100613 --- Comment #6 from CVS Commits --- The releases/gcc-10 branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:e1f99a4b0563e53a6ea5d03b44d5a4c27699c50b commit r10-10820-ge1f99a4b0563e53a6ea5d03b44d5a4c27699c50b Author: Iain Sandoe Date: Thu Aug 5 09:55:19 2021 +0100 Darwin, jit: Fix build [PR100613]. The generic unix build is not completely suitable for Darwin platforms: * It is a convention to encode the library versioning in the binary and to have only one level of symlink for the installed files. This needs to be applied to the installation too. * The library needs to be built with its correct install name so that two-level library naming works. * The extension for shared libraries should be .dylib Signed-off-by: Iain Sandoe PR jit/100613 - libgccjit should produce dylib on macOS PR jit/100613 gcc/jit/ChangeLog: * Make-lang.in: Provide clauses for Darwin hosts. (cherry picked from commit 08defd9c4e4f8dc428f2f490705ab816af81a03d)
[Bug target/105911] [13 Regression] ICE: in extract_insn, at recog.cc:2791 (error: unrecognizable insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105911 Jakub Jelinek changed: What|Removed |Added Last reconfirmed||2022-06-09 Target Milestone|--- |13.0 Priority|P3 |P1 CC||jakub at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with my r13-927-gdcfdd2851b297e0005a8490b7f867ca45d1ad340 Thanks for the report!
[Bug c++/53288] [C++11] Lifetime of temporary object backing pointer-to-member expression not extended
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53288 Egor changed: What|Removed |Added CC||iamsupermouse at mail dot ru --- Comment #4 from Egor --- Still happens on 12.1 and trunk.
[Bug target/105911] New: [13 Regression] ICE: in extract_insn, at recog.cc:2791 (error: unrecognizable insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105911
Bug ID: 105911
Summary: [13 Regression] ICE: in extract_insn, at recog.cc:2791
(error: unrecognizable insn)
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: x86_64-unknown-linux-gnu
gcc 13.0.0 20220605 snapshot (g:ad6919374beafac4ec1a2f8059620f261019b02f) ICEs
when compiling the following testcase w/ -O1:
__int128 v;
void
bar (__int128, __int128);
void
foo (void)
{
bar (v /= v, v >> (v &= 0x10001));
}
% x86_64-unknown-linux-gnu-gcc-13.0.0 -O1 yhk2zj2p.c
yhk2zj2p.c: In function 'foo':
yhk2zj2p.c:10:1: error: unrecognizable insn:
10 | }
| ^
(insn 20 8 21 2 (parallel [
(set (reg:DI 94)
(and:DI (subreg:DI (reg:TI 82 [ v.0_1 ]) 0)
(const_int 4294967297 [0x10001])))
(clobber (reg:CC 17 flags))
]) "yhk2zj2p.c":9:3 -1
(nil))
during RTL pass: subreg3
yhk2zj2p.c:10:1: internal compiler error: in extract_insn, at recog.cc:2791
0x7258ef _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220605/work/gcc-13-20220605/gcc/rtl-error.cc:108
0x72590b _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220605/work/gcc-13-20220605/gcc/rtl-error.cc:116
0x723f05 extract_insn(rtx_insn*)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220605/work/gcc-13-20220605/gcc/recog.cc:2791
0x1dbab37 decompose_multiword_subregs
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220605/work/gcc-13-20220605/gcc/lower-subreg.cc:1555
0x1dbbafd execute
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220605/work/gcc-13-20220605/gcc/lower-subreg.cc:1818
[Bug middle-end/105910] ICE: with -O1 optimization level and code calling __builtin_return_address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105910 --- Comment #2 from Karine EM --- It is probably the case: gcc-10 just compiles the program (as it is a UB) which crashes with "Abort" when trying to actually run this program; llvm returns an error: test4.c:4:13: error: argument value 524288 is outside the valid range [0, 65535] I think instead of an ICE, any of the options is a good solution.
[Bug middle-end/105910] ICE: with -O1 optimization level and code calling __builtin_return_address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105910 Andrew Pinski changed: What|Removed |Added Component|c |middle-end --- Comment #1 from Andrew Pinski --- I am sure 524288 value will cause a runtime undefined and even a crash at runtime .
[Bug c/105910] New: ICE: with -O1 optimization level and code calling __builtin_return_address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105910
Bug ID: 105910
Summary: ICE: with -O1 optimization level and code calling
__builtin_return_address
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: k.even-mendoza at imperial dot ac.uk
Target Milestone: ---
This code (reduced):
===
int a;
void b() {
a = ((long)__builtin_return_address(0) ^ (long)__builtin_return_address(0)) *
(long)__builtin_return_address(524288);
}
int main(void) { return 0;}
===
crashed the compiler with -O1: gcc -O1 test4.c
gcc: internal compiler error: Segmentation fault signal terminated program cc1
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See
[Bug middle-end/105866] [13 Regression] ICE in emit_move_insn building glibc for MIPS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105866 Joseph S. Myers changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Joseph S. Myers --- Yes, it's now working again. https://sourceware.org/pipermail/libc-testresults/2022q2/009793.html
[Bug c++/65328] GCC perf issue when compiling templates - 120x slower than Clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65328 Patrick Palka changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org CC||ppalka at gcc dot gnu.org
[Bug c++/105871] ICE: in wide_int_to_tree_1, at tree.cc:1777 with __builtin_shufflevector() in C++ code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105871 --- Comment #4 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:4c334e0e4ff05d3a7ca9ebb832428c446cd0ae8d commit r13-1027-g4c334e0e4ff05d3a7ca9ebb832428c446cd0ae8d Author: Jakub Jelinek Date: Thu Jun 9 17:42:31 2022 +0200 c++: Fix up ICE on __builtin_shufflevector constexpr evaluation [PR105871] As the following testcase shows, BIT_FIELD_REF result doesn't have to have just integral type, it can also have vector type. And in that case cxx_eval_bit_field_ref just ICEs on it because it is unprepared for that case, creates the initial value with build_int_cst (sure, that one could be easily replaced with build_zero_cst) and then expects it can through shifts, ands and ors come up with the final value, but that doesn't work for vectors. We already call fold_ternary if whole is a VECTOR_CST, this patch does the same if the result doesn't have integral type. And, there is no guarantee fold_ternary will succeed and the callers certainly don't expect NULL being returned, so it also diagnoses those as non-constant and returns original t in that case. 2022-06-09 Jakub Jelinek PR c++/105871 * constexpr.cc (cxx_eval_bit_field_ref): For BIT_FIELD_REF with non-integral result type use fold_ternary too like for BIT_FIELD_REFs from VECTOR_CST. If fold_ternary returns NULL, diagnose non-constant expression, set *non_constant_p and return t, instead of returning NULL. * g++.dg/pr105871.C: New test.
[Bug c++/90254] [9 Regression] ice on aggregate initialization of unmovable base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90254
m.cencora at gmail dot com changed:
What|Removed |Added
CC||m.cencora at gmail dot com
--- Comment #13 from m.cencora at gmail dot com ---
Slightly modified example still produces ICE on gcc-10.3 (works in gcc-11 and
later)
g++ -std=c++17
struct A {
A();
A(const A &);
};
struct B : A { };
A foo ();
int
main ()
{
B{foo()};
}
[Bug analyzer/105909] New: RFE: SARIF output could contain metadata about limitations of the analysis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105909 Bug ID: 105909 Summary: RFE: SARIF output could contain metadata about limitations of the analysis Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: dmalcolm at gcc dot gnu.org Target Milestone: --- The analysis has various limitations: - It can give up the analysis (currently with the off-by-default -Wanalyzer-too-complex): - too many exploded nodes at a program point - too many exploded nodes altogether - If it encounters a function with unknown behavior, it can approximate the behavior of the call; the code to do this makes various assumptions - the analyzer has hard-coded handlers for various standard functions - otherwise, it has a more general "unknown function" handler - The path-feasibility code can give up if it hits a complexity limit The SARIF output could contain metadata about these various situations. Perhaps a warning about "approximating the behavior of unknown function" ? That way a user of the SARIF data could supply enough stubs/handlers from the analysis to be "closed world".
[Bug analyzer/105894] RFE: -fanalyzer could complain about misuse of functions that return pointers to a static buffer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105894 --- Comment #1 from David Malcolm --- (In reply to David Malcolm from comment #0) > The analyzer's region model might make this fairly easy to implement. Specifically: the result of the function call would be a conjured_svalue where the stmt of the conjured_svalue was a call to such an annotated function.
[Bug c++/105397] Cannot export module initializer symbols with `-fvisibility=hidden`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105397 Mathias Stearn changed: What|Removed |Added CC||redbeard0531 at gmail dot com --- Comment #1 from Mathias Stearn --- Perhaps the best option is to default the visibility of the implicit functions to the widest visibility of any function or object in module purview exposed by the TU. The assumption being that if anything is visibile outside the library, then it is expected to be imported from TUs outside the library and that should Just Work. Conversely, if everything is defined as internal visibility, then it is unlikely that this module was intended to be imported from outside of the library, and so it may be desireable to allow different libs to have their own module with the same name. Unfortunately that doesn't give any good indication of what to do for importable units that have an empty module purview (or where everything inside it has TU-local internal linkage). While legal, maybe that isn't a case worth optimizing the Just Works experience for?
[Bug c++/105841] [12/13 Regression] Change in behavior of CTAD for alias templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105841 Patrick Palka changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=102529 --- Comment #5 from Patrick Palka --- PR102529 seems related, though not a regression. There it's a constraint (on the alias template) rather than a default template argument that messes us up.
[Bug c++/84920] Better handling of unmatched/ambiguous calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84920
--- Comment #10 from Lewis Hyatt ---
(In reply to Jonathan Wakely from comment #9)
> That looks pretty good to me. What does it produce for the operator<<
> example in comment 1?
With the default options:
=
iowarn2.cpp: In function ‘void f(std::ostream&, const A&)’:
iowarn2.cpp:13:5: error: no match for ‘operator<<’ (operand types are
‘std::ostream’ {aka ‘std::basic_ostream’} and ‘const A’)
13 | o << a;
| ~ ^~ ~
| ||
| |const A
| std::ostream {aka std::basic_ostream}
iowarn2.cpp:13:5: note: declining to output 34 candidates (limit 7); compile
with ‘-foverload-candidates-stop-level=34’ to see them
=
With the suggestion from the diagnostic -foverload-candidates-stop-level=34, so
this is the ~50% abbreviated mode:
=
iowarn2.cpp: In function ‘void f(std::ostream&, const A&)’:
iowarn2.cpp:13:5: error: no match for ‘operator<<’ (operand types are
‘std::ostream’ {aka ‘std::basic_ostream’} and ‘const A’)
13 | o << a;
| ~ ^~ ~
| ||
| |const A
| std::ostream {aka std::basic_ostream}
In file included from iowarn2.cpp:1:
/home/lewis/gccdev/dev/rel/include/c++/13.0.0/ostream:108:7: note: candidate:
‘std::basic_ostream<_CharT, _Traits>::__ostream_type&
std::basic_ostream<_CharT, _Traits>::operator<<(__ostream_type&
(*)(__ostream_type&)) [with _CharT = char; _Traits = std::char_traits;
__ostream_type = std::basic_ostream]’
/home/lewis/gccdev/dev/rel/include/c++/13.0.0/ostream:108:36: note: no known
conversion for argument 1 from ‘const A’ to
‘std::basic_ostream::__ostream_type&
(*)(std::basic_ostream::__ostream_type&)’ {aka ‘std::basic_ostream&
(*)(std::basic_ostream&)’}
/home/lewis/gccdev/dev/rel/include/c++/13.0.0/ostream:117:7: note: candidate:
‘std::basic_ostream<_CharT, _Traits>::__ostream_type&
std::basic_ostream<_CharT, _Traits>::operator<<(__ios_type& (*)(__ios_type&))
[with _CharT = char; _Traits = std::char_traits; __ostream_type =
std::basic_ostream; __ios_type = std::basic_ios]’
/home/lewis/gccdev/dev/rel/include/c++/13.0.0/ostream:117:32: note: no known
conversion for argument 1 from ‘const A’ to
‘std::basic_ostream::__ios_type&
(*)(std::basic_ostream::__ios_type&)’ {aka ‘std::basic_ios&
(*)(std::basic_ios&)’}
/home/lewis/gccdev/dev/rel/include/c++/13.0.0/ostream:127:7: note: candidate:
‘std::basic_ostream<_CharT, _Traits>::__ostream_type&
std::basic_ostream<_CharT, _Traits>::operator<<(std::ios_base&
(*)(std::ios_base&)) [with _CharT = char; _Traits = std::char_traits;
__ostream_type = std::basic_ostream]’
/home/lewis/gccdev/dev/rel/include/c++/13.0.0/ostream:127:30: note: no known
conversion for argument 1 from ‘const A’ to ‘std::ios_base&
(*)(std::ios_base&)’
/home/lewis/gccdev/dev/rel/include/c++/13.0.0/ostream:166:7: note: candidate:
‘std::basic_ostream<_CharT, _Traits>::__ostream_type&
std::basic_ostream<_CharT, _Traits>::operator<<(long int) [with _CharT = char;
_Traits = std::char_traits; __ostream_type = std::basic_ostream]’
/home/lewis/gccdev/dev/rel/include/c++/13.0.0/ostream:166:23: note: no known
conversion for argument 1 from ‘const A’ to ‘long int’
/home/lewis/gccdev/dev/rel/include/c++/13.0.0/ostream:170:7: note: candidate:
‘std::basic_ostream<_CharT, _Traits>::__ostream_type&
std::basic_ostream<_CharT, _Traits>::operator<<(long unsigned int) [with _CharT
= char; _Traits = std::char_traits; __ostream_type =
std::basic_ostream]’
/home/lewis/gccdev/dev/rel/include/c++/13.0.0/ostream:170:32: note: no known
conversion for argument 1 from ‘const A’ to ‘long unsigned int’
/home/lewis/gccdev/dev/rel/include/c++/13.0.0/ostream:174:7: note: candidate:
‘std::basic_ostream<_CharT, _Traits>::__ostream_type&
std::basic_ostream<_CharT, _Traits>::operator<<(bool) [with _CharT = char;
_Traits = std::char_traits; __ostream_type = std::basic_ostream]’
/home/lewis/gccdev/dev/rel/include/c++/13.0.0/ostream:174:23: note: no known
conversion for argument 1 from ‘const A’ to ‘bool’
In file included from
/home/lewis/gccdev/dev/rel/include/c++/13.0.0/ostream:833:
/home/lewis/gccdev/dev/rel/include/c++/13.0.0/bits/ostream.tcc:91:5: note:
candidate: ‘std::basic_ostream<_CharT, _Traits>& std::basic_ostream<_CharT,
_Traits>::operator<<(short int) [with _CharT = char; _Traits =
std::char_traits]’
/home/lewis/gccdev/dev/rel/include/c++/13.0.0/bits/ostream.tcc:92:22: note:
no known conversion for argument 1 from ‘const A’ to ‘short int’
/home/lewis/gccdev/dev/rel/include/c++/13.0.0/ostream:181:7: note: candidate:
‘std::basic_ostream<_CharT, _Traits>::__ostream_type&
std::basic_ostream<_CharT, _Traits>::operator<<(short unsigned int) [with
_CharT = char; _Traits = std::char_traits; __ostream_type =
std::basic_ostream]’
/home/lewis/gccdev/dev/rel/include/c++/13.0.0/ostream:181:33: note: no known
conversion for argument 1 from ‘const A’ to ‘short unsigned int’
/home/lewis/gccdev/dev/rel/include/c++/13.0.0/bits/ostream.tcc:105:5: note
[Bug target/105856] [13 Regression] ice in emit_move_insn, at expr.cc:4011
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105856 Roger Sayle changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Roger Sayle --- Thanks David.
[Bug c++/102529] ctad for aliases fails in the presence of constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102529 Patrick Palka changed: What|Removed |Added Assignee|ppalka at gcc dot gnu.org |unassigned at gcc dot gnu.org Status|ASSIGNED|NEW
[Bug c++/105908] New: out-of-class definition of templated method with decltype in trailing return type fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105908
Bug ID: 105908
Summary: out-of-class definition of templated method with
decltype in trailing return type fails to compile
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: falemagn at gmail dot com
Target Milestone: ---
This code fails to compile with g++12.
struct test
{
template
int templated_func();
int normal_func();
template
auto call_with_scope_templated_func() ->
decltype(test::templated_func());
template
auto call_templated_func() -> decltype(templated_func());
template
auto call_normal_func() -> decltype(normal_func());
};
template
auto test::call_with_scope_templated_func() ->
decltype(test::templated_func())
{
return templated_func();
}
template
auto test::call_templated_func() -> decltype(templated_func())
{
return templated_func();
}
template
auto test::call_normal_func() -> decltype(normal_func())
{
return normal_func();
}
gcc complaines like this:
:25:6: error: no declaration matches 'decltype
(((test*)this)->templated_func()) test::call_templated_func()'
25 | auto test::call_templated_func() -> decltype(templated_func())
| ^~~~
:12:10: note: candidate is: 'template decltype
(((test*)this)->templated_func()) test::call_templated_func()'
12 | auto call_templated_func() -> decltype(templated_func());
| ^~~
:1:8: note: 'struct test' defined here
1 | struct test
|^~~~
However, as you can see, it works if the class name is prepended to the
template_func() call within the decltype expression, and it also works if
the called function is not templated.
G++11 doesn't show any such issue, nor does clang.
An working example on godbolt: https://godbolt.org/z/xK5aoxfxY
[Bug fortran/60913] [OOP] Memory leak with allocatable polymorphic function result (in type-bound operator)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60913 dr.i.j.bush at googlemail dot com changed: What|Removed |Added CC||dr.i.j.bush at googlemail dot com --- Comment #11 from dr.i.j.bush at googlemail dot com --- Just wondering if any progress has been made/is likely on this bug - it basically makes gfortran unusable with some of my latest code. I've tested Ian Harvey's example with the latest version of the compiler I have and I see the same problem as he reports: ijb@ijb-Latitude-5410:~/work$ gfortran-11 -O -std=f2018 -Wall -Wextra -fcheck=all ianh.f90 ijb@ijb-Latitude-5410:~/work$ valgrind --leak-check=full ./a.out ==337876== Memcheck, a memory error detector ==337876== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==337876== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info ==337876== Command: ./a.out ==337876== 1 ... 100 ==337876== ==337876== HEAP SUMMARY: ==337876== in use at exit: 400 bytes in 100 blocks ==337876== total heap usage: 121 allocs, 21 frees, 13,984 bytes allocated ==337876== ==337876== 400 bytes in 100 blocks are definitely lost in loss record 1 of 1 ==337876==at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==337876==by 0x401240: __m_MOD_f (in /home/ijb/work/a.out) ==337876==by 0x4012C5: main (in /home/ijb/work/a.out) ==337876== ==337876== LEAK SUMMARY: ==337876==definitely lost: 400 bytes in 100 blocks ==337876==indirectly lost: 0 bytes in 0 blocks ==337876== possibly lost: 0 bytes in 0 blocks ==337876==still reachable: 0 bytes in 0 blocks ==337876== suppressed: 0 bytes in 0 blocks ==337876== ==337876== For lists of detected and suppressed errors, rerun with: -s ==337876== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
[Bug target/105856] [13 Regression] ice in emit_move_insn, at expr.cc:4011
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105856 --- Comment #7 from David Binderman --- (In reply to Roger Sayle from comment #6) > Hi David. Thanks again for all your help (building Linux distributions is a > helpful/vital service to the GCC community). Thanks. Good to know I am doing something useful. 820 bugs in 10+ years. >Can you confirm that this problem is now fixed on ARM? I just confirmed that today's gcc compiler (git hash 2fc6e3d55f6080da) has it fixed. Much thanks for your fast work on this bug report. Found & fixed in four days.
[Bug tree-optimization/105739] [10 Regression] Miscompilation of Linux kernel update.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105739 --- Comment #8 from Jan Hubicka --- After inlning I see: IPA function summary for rcu_tasks_trace_pertask/5350 inlinable global time: 13.535950 self size: 11 global size: 16 min size: 11 self stack: 0 global stack:0 estimated growth:5 size:8.00, time:5.807250 size:3.00, time:2.00, executed if:(not inlined) size:2.00, time:2.00, nonconst if:(op0 changed) calls: rcu_tasks_trace_pertask.part.0/5788 inlined freq:0.62 Stack frame offset 0, callee self size 0 trc_wait_for_one_reader/5799 inlined freq:0.62 Stack frame offset 0, callee self size 0 __builtin_unreachable/5800 unreachable freq:0.00 loop depth: 0 size: 0 time: 0 predicate: (false) op0 is compile time invariant op1 is compile time invariant trc_wait_for_one_reader.part.0/5784 --param max-inline-insns-auto limit reached freq:0.31 loop depth: 0 size: 3 time: 12 callee size:100 stack: 0 __builtin_expect/5421 function body not available freq:1.00 loop depth: 0 size: 0 time: 0 op1 is compile time invariant So it seems that we determine call in trc_wait_for_one_reader unreachable. It originally calls printk: IPA function summary for trc_wait_for_one_reader/5348 inlinable global time: 13.50 self size: 20 global size: 20 min size: 1 self stack: 0 global stack:0 size:1.00, time:1.00 size:3.00, time:2.00, executed if:(not inlined) size:0.50, time:0.50, executed if:(not inlined), nonconst if:(op0[ref offset: 8672] changed) && (not inlined) size:2.50, time:2.50, nonconst if:(op0[ref offset: 8672] changed) size:1.50, time:0.25, executed if:(op0[ref offset: 8672] != -1) && (not inlined) size:3.50, time:1.25, executed if:(op0[ref offset: 8672] != -1) calls: trc_wait_for_one_reader.part.0/5784 function not considered for inlining freq:0.50 loop depth: 0 size: 3 time: 12 callee size:55 stack: 0 predicate: (op0[ref offset: 8672] == -1) _printk/5452 function body not available freq:0.00 loop depth: 0 size: 5 time: 14 predicate: (op0[ref offset: 8672] != -1) op0 is compile time invariant So we somehow figure out (op0[ref offset: 8672] != -1) here: Enqueueing calls in rcu_tasks_trace_pertask.part.0/5788. Estimating body: trc_wait_for_one_reader/5348 Known to be false: not inlined, op0[ref offset: 8672] != -1, op0[ref offset: 8672] changed size:4 time:7.00 nonspec time:12.00 This seems to be based on: Jump functions: Jump functions of caller rcu_tasks_trace_pertask.part.0/5788: callsite rcu_tasks_trace_pertask.part.0/5788 -> trc_wait_for_one_reader/5348 : param 0: PASS THROUGH: 0, op nop_expr Aggregate passed by reference: offset: 8672, type: int, CONST: -1 value: 0x0, mask: 0xfff
[Bug c++/84920] Better handling of unmatched/ambiguous calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84920 --- Comment #9 from Jonathan Wakely --- That looks pretty good to me. What does it produce for the operator<< example in comment 1?
[Bug target/105856] [13 Regression] ice in emit_move_insn, at expr.cc:4011
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105856 --- Comment #6 from Roger Sayle --- Hi David. Thanks again for all your help (building Linux distributions is a helpful/vital service to the GCC community). Can you confirm that this problem is now fixed on ARM?
[Bug middle-end/105853] [13 regression] ice in pieces_addr constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105853 Roger Sayle changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Roger Sayle --- This should now be fixed on mainline. Sorry for the breakage.
[Bug middle-end/105866] [13 Regression] ICE in emit_move_insn building glibc for MIPS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105866 --- Comment #2 from Roger Sayle --- Hi Joseph. Sorry again for the breakage. Hopefully, the load_register_parameters ICE is now resolved. Can you confirm that glibc now builds without problems on MIPS?
[Bug middle-end/105874] [13 Regression] Incorrect codegen and ICE since g:ed6fd2aed58f2cca99f15331bf68999c0e6df370
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105874 Roger Sayle changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Roger Sayle --- Thanks again Tamar for confirming this bug is now fixed (alas I don't have an aarch64 to check for myself). Sorry again for the inconvenience.
[Bug libstdc++/105907] New: unordered containers should cache result of std::hash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105907
Bug ID: 105907
Summary: unordered containers should cache result of
std::hash
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: ABI
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
The std::hash specializations for PMR strings do not have corresponding
specializations of the __is_fast_hash trait, which means they use the default
i.e. fast-hash == true. This means that unordered containers do not bother to
cache the hash code.
This is wrong, hashing PMR strings is exactly as slow as hashing non-PMR
strings. But changing it now would be an ABI break for e.g.
std::unordered_set because it would add a hash code member to
each node.
Similarly, adding specializations of __is_fast_hash corresponding to the
changes for https://wg21.link/lwg3705 ("Hashability shouldn't depend on
basic_string's allocator") will be an ABI break for e.g.
std::unordered_set, MyAlloc>>
We really should have just defined __is_fast_hash to be true for all
specializations of basic_string, instead of only the ones that have a
predefined std::hash specialization.
[Bug target/105886] -mstrict-align is ignorning unalign in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105886 --- Comment #7 from Keven --- Thank you for your fast investigation :)
[Bug target/103100] [11/12/13 Regression] unaligned access generated with memset or {} and -O2 -mstrict-align
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103100 Andrew Pinski changed: What|Removed |Added CC||keven.kloeckner at siemens dot com --- Comment #12 from Andrew Pinski --- *** Bug 105886 has been marked as a duplicate of this bug. ***
[Bug target/105886] -mstrict-align is ignorning unalign in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105886 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|WAITING |RESOLVED --- Comment #6 from Andrew Pinski --- Yes it is a dup of bug 103100 . I hope next week I finish up the patch for it. *** This bug has been marked as a duplicate of bug 103100 ***
[Bug target/105886] -mstrict-align is ignorning unalign in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105886 --- Comment #5 from Keven --- Created attachment 53112 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53112&action=edit source file
[Bug target/105886] -mstrict-align is ignorning unalign in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105886 --- Comment #4 from Keven --- Created attachment 53111 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53111&action=edit Disassembly screen
[Bug target/105886] -mstrict-align is ignorning unalign in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105886 --- Comment #3 from Keven --- Created attachment 53110 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53110&action=edit precompiled file
[Bug lto/105877] GNU strip breaks -flto -g .o files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105877 --- Comment #2 from hubicka at kam dot mff.cuni.cz --- > "strip -g" removed .gnu.debuglto_.debug_info sections. Should LTO remove the > references of stripped debug info? Or should "strip -g" keep LTO debug info? I suppose we should try to immitate what happens without -flto, so probably check for the presence of debuglto sections and avoid producing debug info when they have been stripped? I am not sure how hard would be to implement this especially in situations where part of object files were stripped and others not?
[Bug analyzer/105906] New: fanalyzer strdup false positive leak in loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105906
Bug ID: 105906
Summary: fanalyzer strdup false positive leak in loop
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: contino at epigenesys dot com
Target Milestone: ---
Created attachment 53109
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53109&action=edit
The warning
Hi,
compiling the code with GCC-12.1.0 on Debian I am seeing the fanalyzer warning
in the attachment, which seems to me a false positive leak related to strdup.
Code:
#include
#include
#include
#define LEN 64
char **__epystr_explode(const char *delim, char *str)
{
char **out = NULL;
int i;
if (str == NULL || delim == NULL)
return NULL;
out = malloc(LEN * sizeof(char *));
if (out == NULL)
return NULL;
for (i = 0; i < LEN; i++) {
out[i] = strdup("bla");
if (out[i] == NULL)
goto freem;
}
return out;
freem:
while (--i >= 0)
free(out[i]);
free(out);
return NULL;
}
If I replace strdup with malloc the warning disappears.
for (i = 0; i < LEN; i++) {
out[i] = malloc(10);
if (out[i] == NULL)
goto freem;
}
The same happens if I replace the for loop with a goto loop.
i = 0;
loop:
out[i] = strdup("bla");
if (out[i] == NULL)
goto freem;
i++
if (i < LEN)
goto loop;
[Bug other/105819] GCC 12.1.0 Make failed - Compiled with GCC 4.9.4 and under Mac OS X lion - I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105819 --- Comment #9 from Jakub Jelinek --- (In reply to Jonathan Wakely from comment #6) > Try it again without using a directory called "_Source/_12,1,x" Say _Source/_12.1.x would work, dot is often used separator in filenames that is known to work.
[Bug other/105819] GCC 12.1.0 Make failed - Compiled with GCC 4.9.4 and under Mac OS X lion - I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105819 --- Comment #8 from Jakub Jelinek --- And wouldn't surprise e if spaces wouldn't cause various issues as well.
[Bug other/105819] GCC 12.1.0 Make failed - Compiled with GCC 4.9.4 and under Mac OS X lion - I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105819 --- Comment #7 from Andrew Pinski --- I wonder if we should document what characters in the directories could cause issues. I know @ also causes issues when the documentation is being generated.
[Bug target/105818] ICE: 'global_options' are modified in local context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105818 --- Comment #3 from Kewen Lin --- The different flag bit is OPTION_MASK_SAVE_TOC_INDIRECT. if ((rs6000_isa_flags_explicit & OPTION_MASK_SAVE_TOC_INDIRECT) == 0 && flag_shrink_wrap_separate && optimize_function_for_speed_p (cfun)) rs6000_isa_flags |= OPTION_MASK_SAVE_TOC_INDIRECT; When parsing function foo, the call to optimize_function_for_speed_p return OPTIMIZE_SIZE_MAX as expected, at that time function struct is null. while parsing the decl bar, the cfun is the one created for foo, although there is no cgraph node for it, optimize_function_for_speed_p return OPTIMIZE_SIZE_NO. I think when none cgraph node is found we should still return OPTIMIZE_SIZE_MAX if optimize_size is set. It can fix this issue.
[Bug other/105819] GCC 12.1.0 Make failed - Compiled with GCC 4.9.4 and under Mac OS X lion - I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105819 --- Comment #6 from Jonathan Wakely --- Try it again without using a directory called "_Source/_12,1,x"
[Bug libstdc++/105880] eh_globals_init destructor not setting _M_init to false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105880 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2022-06-09 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org --- Comment #11 from Jonathan Wakely --- (In reply to Chris Johns from comment #10) > And yes the eh_globals single-threaded fallback buffer does have this > problem however for RTEMS that is a corner case because something has called > `exit()` on an embedded realtime system and that typically means a reset is > about to happen. Right. Nobody is going to be creating new threads and throwing exceptions in a function registered with atexit!
[Bug rtl-optimization/101260] [10/11 Regression] regcprop: Determine subreg offset depending on endianness
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101260 --- Comment #18 from Stefan Schulze Frielinghaus --- Fixed for 12 and mainline.
[Bug other/105819] GCC 12.1.0 Make failed - Compiled with GCC 4.9.4 and under Mac OS X lion - I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105819 --- Comment #5 from bug-reports.delphin at laposte dot net --- Thank you for your reply. So, what have I to do ? Please note that GCC v. 11.3.0 was successfully built and installed with the same configuration (./configure). Kind regards,
[Bug middle-end/105905] A possible rounding error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105905 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 Component|c++ |middle-end Last reconfirmed||2022-06-09 --- Comment #1 from Andrew Pinski --- There is not enough information to figure out what is going wrong. It could be fma usage or it could be that they are in 32bit x86 which uses x87 which does fp slightly different. Or it could be an unitizlized variable on their side causing the issue.
[Bug c++/105905] New: A possible rounding error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105905 Bug ID: 105905 Summary: A possible rounding error Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: zhonghao at pku dot org.cn Target Milestone: --- magnum is a data visualization library. I notice that its programmers complained a rounding error in gcc. It occurs when compiling their code in the release version. To fix the problem, they change their test cases, which is a workaround: https://github.com/mosra/magnum/commit/fb51f25a7b613aa5be744deea5a4ddb88f3de064 I also open an issue in magnum. Its programmers can provide more feedback.
[Bug target/105818] ICE: 'global_options' are modified in local context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105818 Kewen Lin changed: What|Removed |Added Last reconfirmed||2022-06-09 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED CC||linkw at gcc dot gnu.org Target|powerpc-e300c3-linux-gnu|powerpc*-linux-gnu --- Comment #2 from Kewen Lin --- Confirmed, failed on powerpc*-linux-gnu.
[Bug libquadmath/105101] incorrect rounding for sqrtq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105101 --- Comment #15 from Jakub Jelinek --- >From what I can see, it is mostly integral implementation and we already have one such in GCC, so the question is if we just shouldn't use it (most of the sources are in libgcc/soft-fp/ , then configuration files in libgcc/config/*/sfp-* and the simple *.c file that uses the soft-fp macros is in glibc in sysdeps/ieee754/soft-fp/s_fsqrtl.c ).
[Bug libquadmath/105101] incorrect rounding for sqrtq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105101 --- Comment #14 from Thomas Koenig --- @Michael: Now that gcc 12 is out of the door, I would suggest we try to get your code into the gcc tree for gcc 13. It should follow the gcc style guidelines, which is quite trivial to do: Comments should be in /* - */ format, and clang-format --style=gnu does the rest. (If you prefer, I can also handle that). Regarding copyright, you can either assign it to the FSF (which would take a bit) or, probably easier, you can use the Signed-off-by: tag as per https://gcc.gnu.org/contribute.html#legal . You would then submit the patch to gcc-patc...@gcc.gnu.org; if you prefer, I can also help a bit with the style issues (ChangeLog etc) for that. It would then be reviewed and, if any problems identified are fixed, applied - which I can also do. How does that sound?
[Bug middle-end/105874] [13 Regression] Incorrect codegen and ICE since g:ed6fd2aed58f2cca99f15331bf68999c0e6df370
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105874 --- Comment #8 from Tamar Christina --- Can confirm that the benchmark works again. Thanks!
[Bug tree-optimization/105904] New: Predicated mov r0, #1 with opposite conditions could be hoisted, between 1 and 1<
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105904
Bug ID: 105904
Summary: Predicated mov r0, #1 with opposite conditions could
be hoisted, between 1 and 1< // using the libstdc++ header
unsigned roundup(unsigned x){
return std::bit_ceil(x);
}
https://godbolt.org/z/Px1fvWaex
GCC's version is somewhat clunky, including MOV r0, #1 in either "side":
roundup(unsigned int):
cmp r0, #1
i hi
addhi r3, r0, #-1
movhi r0, #1@@ here
clzhi r3, r3
rsbhi r3, r3, #32
ite hi
lslhi r0, r0, r3
movls r0, #1@@ here
bx lr
Even without spotting the other optimizations that clang finds, we can combine
to a single unconditional MOV r0, #1. But only if we avoid setting flags, so
it requires a 4-byte encoding, not MOVS. Still, it's one fewer instruction to
execute.
This is not totally trivial: it requires seeing that we can move it across the
conditional LSL. So it's really a matter of folding the 1s between 1<
[Bug target/103320] 12 Regression] Spec 2017 benchmark roms_r fails on PowerPC for -Ofast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103320 Kewen Lin changed: What|Removed |Added CC||linkw at gcc dot gnu.org --- Comment #2 from Kewen Lin --- I also met this issue recently, not sure if roms_r's failure has the same root cause with what we have for perlbench_r, perlbench_r's page [1] highlights the option "-fno-unsafe-math-optimizations " while roms_r's [2] doesn't. One thing to note is that without -funroll-loops roms_r's verification can pass. Maybe it's a good idea to reopen this for more investigation? [1] https://www.spec.org/cpu2017/Docs/benchmarks/500.perlbench_r.html [2] https://www.spec.org/cpu2017/Docs/benchmarks/554.roms_r.html
[Bug target/105493] [12/13 Regression] x86_64 538.imagick_r 6% regressions and 2% 525.x264_r regressions on Alder Lake after r12-7319-g90d693bdc9d718
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105493
--- Comment #6 from CVS Commits ---
The master branch has been updated by hongtao Liu :
https://gcc.gnu.org/g:269edf4e5e6ab489730038f7e3495550623179fe
commit r13-1021-g269edf4e5e6ab489730038f7e3495550623179fe
Author: Cui,Lili
Date: Wed Jun 8 11:25:57 2022 +0800
Update {skylake,icelake,alderlake}_cost to add a bit preference to vector
store.
Since the interger vector construction cost has changed, we need to adjust
the
load and store costs for intel processers.
With the patch applied
538.imagic_r:gets ~6% improvement on ADL for multicopy.
525.x264_r :gets ~2% improvement on ADL and ICX for multicopy.
with no measurable changes for other benchmarks.
gcc/ChangeLog
PR target/105493
* config/i386/x86-tune-costs.h (skylake_cost): Raise the gpr load
cost
from 4 to 6 and gpr store cost from 6 to 8. Change SSE loads and
unaligned loads cost from {6, 6, 6, 10, 20} to {8, 8, 8, 8, 16}.
(icelake_cost): Ditto.
(alderlake_cost): Raise the gpr store cost from 6 to 8 and SSE
loads,
stores and unaligned stores cost from {6, 6, 6, 10, 15} to
{8, 8, 8, 10, 15}.
gcc/testsuite/
PR target/105493
* gcc.target/i386/pr91446.c: Adjust to expect vectorization
* gcc.target/i386/pr99881.c: XFAIL.
* gcc.target/i386/pr105493.c: New.
* g++.target/i386/pr105638.C: Use other sequence checks
instead of vpxor, because code generation changed.
