[Bug testsuite/95720] [11 Regression] New dump output filename strategy invalidates tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95720 --- Comment #19 from Torbjörn SVENSSON --- Forgot to mention the PR number in the commit message, but this ticket is also related to the change. https://gcc.gnu.org/g:86291da0057d01efdaba71f28cad80b69dc703a4 commit r13-2989-g86291da0057 Author: Torbjörn SVENSSON Date: Mon Sep 19 18:52:50 2022 +0200 testsuite: Do not prefix linker script with "-Wl," The linker script should not be prefixed with "-Wl," - it's not an input file and does not interfere with the new dump output filename strategy. gcc/testsuite/ChangeLog: * lib/gcc-defs.exp: Do not prefix linker script with "-Wl,". Signed-off-by: Torbjörn SVENSSON
[Bug c/107127] New: [Regression 11/12] Long compile times on code with C complex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107127 Bug ID: 107127 Summary: [Regression 11/12] Long compile times on code with C complex Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: inform at tiker dot net Target Milestone: --- A generated code using C-style complex arithmetic that compiled nearly instantaneously with gcc 10.4 takes >=30s with gcc 11.3.0 and 12.2.0. How to reproduce: git clone https://gist.github.com/inducer/802e227e86e3ff4fd95aa0fefae462fe.git cd 802e227e86e3ff4fd95aa0fefae462fe git checkout 9eb600e $ time gcc-10 -c post-110.c gcc-10 -c post-110.c 0,05s user 0,02s system 45% cpu 0,155 total $ time gcc-11 -c post-110.c ^C gcc-11 -c post-110.c 0,00s user 0,00s system 0% cpu 23,757 total $ time gcc-12 -c post-110.c ^C gcc-12 -c post-110.c 0,00s user 0,00s system 0% cpu 31,574 total This does not seem to be very sensitive to headers, so I'm not including preprocessed source to start. Happy to supply it if needed. Target: x86_64-linux-gnu Precise versions: gcc version 10.4.0 (Debian 10.4.0-5) gcc version 11.3.0 (Debian 11.3.0-5) gcc version 12.2.0 (Debian 12.2.0-3) x-ref: https://github.com/inducer/loopy/issues/686
[Bug fortran/107000] ICE in gfc_real2complex, at fortran/arith.cc:2243
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107000 --- Comment #17 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #16) > Created attachment 53651 [details] > Revised patch Unfortunately this regresses on gfortran.dg/pr91552.f90, e.g. print *, 2 * [real :: 1, [2], 3]
[Bug c++/107126] GCC accepts invalid out of class definition for destructor with C++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107126 Jakub Jelinek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- (In reply to Jason Liam from comment #2) > Second, i'm already aware that this is rejected by gcc with c++20 as i > provided a demo link https://godbolt.org/z/TYjEzss6q at the first line of my > bug report. One thing is to know that some versions of g++ do that, but the above provides details on what change actually changed the behavior, which is useful information for any further changes. Then it is https://cplusplus.github.io/CWG/issues/1435.html which we perhaps don't implement or don't implement fully.
[Bug c++/107126] GCC accepts invalid out of class definition for destructor with C++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107126 --- Comment #3 from Jason Liam --- (In reply to Jakub Jelinek from comment #1) > This is rejected with -std=c++20 since > r11-532-g4b38d56dbac6742b038551a36ec80200313123a1 > and the commit log states that it is intentional to apply it only for C++20 > mode because the DR wasn't against C++17. > So why do you think otherwise? > https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#2237 > also states: > (Note that this resolution is a change for C++20, NOT a defect report > against C++17 and earlier versions.) Additionally note that i'm already aware of the cwg defect link that you provided because i once used it here: https://stackoverflow.com/questions/71972000/is-having-a-declaration-stackt-for-the-default-ctor-valid-inside-a-class-te/71981884#71981884 But that cwg defect does not apply here. This is a different gcc bug.
[Bug c++/107126] GCC accepts invalid out of class definition for destructor with C++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107126 --- Comment #2 from Jason Liam --- (In reply to Jakub Jelinek from comment #1) > This is rejected with -std=c++20 since > r11-532-g4b38d56dbac6742b038551a36ec80200313123a1 > and the commit log states that it is intentional to apply it only for C++20 > mode because the DR wasn't against C++17. > So why do you think otherwise? > https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#2237 > also states: > (Note that this resolution is a change for C++20, NOT a defect report > against C++17 and earlier versions.) First, you've clearly missed something here because this is not https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#2237 . Note carefully that the above link that you provided was for declarations of ctors and dtors inside the class definition itself and not for declarations at namespace scope. Second, i'm already aware that this is rejected by gcc with c++20 as i provided a demo link https://godbolt.org/z/TYjEzss6q at the first line of my bug report.
[Bug fortran/107000] ICE in gfc_real2complex, at fortran/arith.cc:2243
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107000 anlauf at gcc dot gnu.org changed: What|Removed |Added Attachment #53601|0 |1 is obsolete|| --- Comment #16 from anlauf at gcc dot gnu.org --- Created attachment 53651 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53651=edit Revised patch This variant adds a check after the place Mikael pointed out, and which verifies that the types of all elements of an array ctor are the same. Testing so far indicates that it is robust enough for all cases discussed in this PR, although it mostly emits Error: Cannot convert UNKNOWN to ... for every expression involving a binary operator. Is this going into the right direction?
[Bug c++/107126] GCC accepts invalid out of class definition for destructor with C++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107126 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- This is rejected with -std=c++20 since r11-532-g4b38d56dbac6742b038551a36ec80200313123a1 and the commit log states that it is intentional to apply it only for C++20 mode because the DR wasn't against C++17. So why do you think otherwise? https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#2237 also states: (Note that this resolution is a change for C++20, NOT a defect report against C++17 and earlier versions.)
[Bug c++/107126] New: GCC accepts invalid out of class definition for destructor with C++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107126
Bug ID: 107126
Summary: GCC accepts invalid out of class definition for
destructor with C++17
Product: gcc
Version: 12.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jlame646 at gmail dot com
Target Milestone: ---
The following invalid program is accepted by gcc with C++17. Demo:
https://godbolt.org/z/TYjEzss6q
```
template
struct C
{
~C();
};
template
C::~C() //this is accepted by gcc with c++17
{
}
int main()
{
C c;;
}
```
This has been discussed here:
https://stackoverflow.com/questions/73928601/clang-accepts-out-of-class-destructor-definition-while-gcc-does-not
[Bug c++/96830] GCC does not complain about redeclaration with inconsistent requires clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96830 --- Comment #9 from Jonathan Wakely --- Reduced to show Clang's confusion: https://godbolt.org/z/E1Kq4Gfed
[Bug c++/96830] GCC does not complain about redeclaration with inconsistent requires clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96830
--- Comment #8 from Jonathan Wakely ---
No, I don't think so. Libstdc++ has this for the primary template:
template
requires input_range<_Vp>
class chunk_view : public view_interface>
{
...
class _OuterIter;
class _InnerIter;
And then:
template
requires input_range<_Vp>
class chunk_view<_Vp>::_OuterIter
and:
template
requires input_range<_Vp>
class chunk_view<_Vp>::_InnerIter
Then there is a partial specialization for forward_ranges:
template
requires forward_range<_Vp>
class chunk_view<_Vp> : public view_interface>
{
...
template class _Iterator;
and its iterator type:
template
requires forward_range<_Vp>
template
class chunk_view<_Vp>::_Iterator
Clang is complaining about the latter, but it's right.
[Bug target/107125] New: libobjc fails to build on arc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107125 Bug ID: 107125 Summary: libobjc fails to build on arc-linux-gnu Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: doko at gcc dot gnu.org Target Milestone: --- seen with trunk 20221001 on arc-linux-gnu: first, config/arc/arc-arch.h uses NULL, but doesn't include stddef.h then linking of libobjc fails with: libtool: link: /home/packages/cross/12/p/gcc-cross-ports/gcc/build/./gcc/xgcc -B/home/packages/cross/12/p/gcc-cross-ports/gcc/build/./gcc/ -B/usr/ar c-linux-gnu/bin/ -B/usr/arc-linux-gnu/lib/ -isystem /usr/arc-linux-gnu/include -isystem /usr/arc-linux-gnu/sys-include -isystem /home/packages/cross /12/p/gcc-cross-ports/gcc/build/sys-include-shared -fPIC -DPIC .libs/NXConstStr.o .libs/Object.o .libs/Protocol.o .libs/accessors.o .libs/link ing.o .libs/class.o .libs/encoding.o .libs/error.o .libs/gc.o .libs/hash.o .libs/init.o .libs/ivars.o .libs/memory.o .libs/methods.o .libs/nil_metho d.o .libs/objc-foreach.o .libs/objc-sync.o .libs/objects.o .libs/protocols.o .libs/sarray.o .libs/selector.o .libs/sendmsg.o .libs/thr.o .libs/excep tion.o-shared-libgcc -Wl,-z -Wl,relro -Wl,-soname -Wl,libobjc.so.4 -o .libs/libobjc.so.4.0.0 checking whether the target supports thread-local storage... /usr/arc-linux-gnu/bin/ld: config.status: executing libtool commands .libs/thr.o:/home/packages/cross/12/p/gcc-cross-ports/gcc/src/libobjc/../gcc/config/arc/arc-arch.h:130: multiple definition of `arc_cpu_types'; .lib s/encoding.o:/home/packages/cross/12/p/gcc-cross-ports/gcc/src/libobjc/../gcc/config/arc/arc-arch.h:130: first defined here /usr/arc-linux-gnu/bin/ld: .libs/thr.o:/home/packages/cross/12/p/gcc-cross-ports/gcc/src/libobjc/../gcc/config/arc/arc-arch.h:120: multiple definiti on of `arc_arch_types'; .libs/encoding.o:/home/packages/cross/12/p/gcc-cross-ports/gcc/src/libobjc/../gcc/config/arc/arc-arch.h:120: first defined h ere so better move these vars to a .c file, don't keep them in the header.
[Bug tree-optimization/107121] DEFERRED_INIT misspelled in error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107121 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Jakub Jelinek --- Fixed.
[Bug tree-optimization/107121] DEFERRED_INIT misspelled in error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107121 --- Comment #1 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:d01bd0b0f3b8f4c33c437ff10f0b949200627f56 commit r13-3020-gd01bd0b0f3b8f4c33c437ff10f0b949200627f56 Author: Jakub Jelinek Date: Sun Oct 2 16:42:32 2022 +0200 tree-cfg: Fix a verification diagnostic typo [PR107121] Obvious typo in diagnostics. 2022-10-02 Jakub Jelinek PR tree-optimization/107121 * tree-cfg.cc (verify_gimple_call): Fix a typo in diagnostics, DEFFERED_INIT -> DEFERRED_INIT.
[Bug bootstrap/107119] Bootstrap ICE on 32-bit ARM after r13-2871-g1b74b5cb4e9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107119 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org --- Comment #2 from Jeffrey A. Law --- Does it still happen after this: Author: Jeff Law Date: Tue Sep 27 01:44:38 2022 -0400 Fix ICEs due to recent jump-to-return optimization gcc/ * cfgrtl.cc (fixup_reorder_chain): Verify that simple_return and return are available before trying to use them.
[Bug c++/107124] New: Reference template parameter refers to a temporary object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107124
Bug ID: 107124
Summary: Reference template parameter refers to a temporary
object
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fchelnokov at gmail dot com
Target Milestone: ---
The following program is accepted by Clang:
template
struct A {};
template
constexpr int f(A) { return 0; }
template
constexpr int f(T) { return 1; }
static_assert( f(A<0>{}) == 1 );
But in GCC static assertion fails, because f(A) overload is preferred.
Online demo: https://gcc.godbolt.org/z/9hj4WoT7b
But this is illegal by http://eel.is/c++draft/temp.arg.nontype#3.1, since const
int & I cannot refer to a temporary int 0.
[Bug tree-optimization/107109] ICE on valid code at -O1 on x86_64-linux-gnu: in type, at value-range.h:621
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107109
--- Comment #1 from Zhendong Su ---
Another test that only reproduces at -O2 and -O3.
[508] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
--with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20221002 (experimental) [master r13-3015-g3290dcf1499] (GCC)
[509] %
[509] % gcctk -O1 small.c; ./a.out
[510] %
[510] % gcctk -O2 small.c
during GIMPLE pass: dom
small.c: In function ‘main’:
small.c:2:5: internal compiler error: in type, at value-range.h:621
2 | int main() {
| ^~~~
0x85dab4 irange::type() const
../../gcc-trunk/gcc/value-range.h:621
0x85e731 irange::type() const
../../gcc-trunk/gcc/tree.h:3634
0x85e731 adjust_op1_for_overflow
../../gcc-trunk/gcc/range-op.cc:1373
0x1de43e3 operator_plus::op1_range(irange&, tree_node*, irange const&, irange
const&, relation_kind_t) const
../../gcc-trunk/gcc/range-op.cc:1414
0x1de43e3 operator_plus::op1_range(irange&, tree_node*, irange const&, irange
const&, relation_kind_t) const
../../gcc-trunk/gcc/range-op.cc:1400
0x1de43e3 operator_plus::op2_range(irange&, tree_node*, irange const&, irange
const&, relation_kind_t) const
../../gcc-trunk/gcc/range-op.cc:1424
0x1ce8e58 gori_compute::compute_operand2_range(vrange&,
gimple_range_op_handler&, vrange const&, tree_node*, fur_source&,
value_relation*)
../../gcc-trunk/gcc/gimple-range-gori.cc:1182
0x1ce7435 gori_compute::compute_operand_range(vrange&, gimple*, vrange const&,
tree_node*, fur_source&, value_relation*)
../../gcc-trunk/gcc/gimple-range-gori.cc:694
0x1ce85df gori_compute::compute_operand1_range(vrange&,
gimple_range_op_handler&, vrange const&, tree_node*, fur_source&,
value_relation*)
../../gcc-trunk/gcc/gimple-range-gori.cc:1140
0x1ce7bdd gori_compute::compute_operand_range(vrange&, gimple*, vrange const&,
tree_node*, fur_source&, value_relation*)
../../gcc-trunk/gcc/gimple-range-gori.cc:692
0x1ce8ed0 gori_compute::compute_operand2_range(vrange&,
gimple_range_op_handler&, vrange const&, tree_node*, fur_source&,
value_relation*)
../../gcc-trunk/gcc/gimple-range-gori.cc:1228
0x1ce7435 gori_compute::compute_operand_range(vrange&, gimple*, vrange const&,
tree_node*, fur_source&, value_relation*)
../../gcc-trunk/gcc/gimple-range-gori.cc:694
0x1ce7209 gori_compute::compute_logical_operands(vrange&, vrange&,
gimple_range_op_handler&, irange const&, tree_node*, fur_source&, tree_node*,
bool)
../../gcc-trunk/gcc/gimple-range-gori.cc:913
0x1ce7aae gori_compute::compute_operand_range(vrange&, gimple*, vrange const&,
tree_node*, fur_source&, value_relation*)
../../gcc-trunk/gcc/gimple-range-gori.cc:674
0x1ce85df gori_compute::compute_operand1_range(vrange&,
gimple_range_op_handler&, vrange const&, tree_node*, fur_source&,
value_relation*)
../../gcc-trunk/gcc/gimple-range-gori.cc:1140
0x1ce7bdd gori_compute::compute_operand_range(vrange&, gimple*, vrange const&,
tree_node*, fur_source&, value_relation*)
../../gcc-trunk/gcc/gimple-range-gori.cc:692
0x1ceafd8 gori_compute::outgoing_edge_range_p(vrange&, edge_def*, tree_node*,
range_query&)
../../gcc-trunk/gcc/gimple-range-gori.cc:1358
0x10a218d path_range_query::compute_ranges_in_block(basic_block_def*)
../../gcc-trunk/gcc/gimple-range-path.cc:454
0x10a2882 path_range_query::compute_ranges(bitmap_head const*)
../../gcc-trunk/gcc/gimple-range-path.cc:622
0x112dd90 hybrid_jt_simplifier::simplify(gimple*, gimple*, basic_block_def*,
jt_state*)
../../gcc-trunk/gcc/tree-ssa-threadedge.cc:1418
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[511] %
[511] % cat small.c
int a, b = 1, c;
int main() {
if (b <= 0) {
if (a)
L:
if (b && a <= 6)
b = c;
int e = ~(a + b);
if ((b <= e || a > e) && a)
a = 0;
if (b < 0)
goto L;
if (b >= a)
while (1)
;
}
return 0;
}
[Bug c++/107123] New: Size deduction for vector size in template fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107123
Bug ID: 107123
Summary: Size deduction for vector size in template fails
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: milasudril at gmail dot com
Target Milestone: ---
Host: x86-64_linux_gnu
Target: x86-64_linux_gnu
I tried to write a generic inner product implementation, accepting vectorized
arguments:
```c++
#include
#include
template
concept arithmetic = std::is_arithmetic_v;
template
using native_vector [[gnu::vector_size(sizeof(T)*N)]] = T;
template
auto inner_product(native_vector a, native_vector b)
{
auto const prod = a * b;
T ret{};
for(size_t k = 0; k != N; ++k)
{ ret += prod[k]; }
return ret;
}
auto test(native_vector a, native_vector b)
{
return inner_product(a, b);
}
```
Apparently, it is not possible to deduce N here:
```
: In function 'auto test(native_vector, native_vector)':
:23:25: error: no matching function for call to
'inner_product(native_vector&, native_vector&)'
23 | return inner_product(a, b);
|~^~
:11:6: note: candidate: 'template auto
inner_product(native_vector, native_vector)'
11 | auto inner_product(native_vector a, native_vector b)
| ^
:11:6: note: template argument deduction/substitution failed:
:23:25: note: couldn't deduce template parameter 'N'
23 | return inner_product(a, b);
```
I would appreciate if size deduction worked like for std::array:
```c++
#include
template
auto inner_product(std::array a, std::array b)
{
T ret{};
for(size_t k = 0; k != N; ++k)
{ ret += a[k]*b[k]; }
return ret;
}
auto test(std::array a, std::array b)
{
return inner_product(a, b); // N deduced to 4
}
```
The problem is present on gcc 10-trunk.
[Bug c++/107111] GCC accepts invalid program involving function declaration with pack expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107111 --- Comment #5 from Jason Liam --- Note also that gcc accepts `T v(V...b())` but rejects `T v(V...())`. Note the use of parameter name in the former. Demo: https://godbolt.org/z/hMevdc8TE
[Bug fortran/107122] New: Improve error message wording
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107122 Bug ID: 107122 Summary: Improve error message wording Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: goeran at uddeborg dot se Target Milestone: --- At https://gcc.gnu.org/git?p=gcc.git;a=blob;f=gcc/fortran/openmp.cc;h=ce719bd5d92dc40185a4d0215d5db13b7956acba;hb=HEAD#l6538 there is a message ORDER clause must not be used together ORDERED at %L In my mind, that would read better by adding "with" after "together".
[Bug tree-optimization/107121] New: DEFERRED_INIT misspelled in error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107121 Bug ID: 107121 Summary: DEFERRED_INIT misspelled in error message Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: goeran at uddeborg dot se Target Milestone: --- At the line https://gcc.gnu.org/git?p=gcc.git;a=blob;f=gcc/tree-cfg.cc;h=ade66c54499ff481bb9d58fd5f3c616646514d65;hb=HEAD#l3513 (at the time of writing this message), there is an error mentioning a call of DEFFERED_INIT. Most likely, that should be DEFERRED_INIT.
[Bug bootstrap/107120] New: [13 Regression] trunk fails to bootstrap on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107120 Bug ID: 107120 Summary: [13 Regression] trunk fails to bootstrap on powerpc64le-linux-gnu Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: doko at gcc dot gnu.org Target Milestone: --- seen with trunk 20221001 on powerpc64le-linux-gnu, glibc 2.35, binutils 2.39: /<>/build/gcc/include-fixed/powerpc64le-linux-gnu/bits/floatn.h:88:9: error: multiple types in one declaration 88 | typedef __float128 _Float128; | ^~ In file included from /usr/include/stdlib.h:56, from /<>/build/powerpc64le-linux-gnu/libstdc++-v3/include/cstdlib:79, from ../../../../src/libstdc++-v3/libsupc++/atexit_thread.cc:25: /<>/build/gcc/include-fixed/powerpc64le-linux-gnu/bits/floatn.h:88:20: error: declaration does not declare anything [-fpermissive] 88 | typedef __float128 _Float128; |^ make[7]: *** [Makefile:777: atexit_thread.lo] Error 1 make[7]: Leaving directory '/<>/build/powerpc64le-linux-gnu/libstdc++-v3/libsupc++' make[6]: *** [Makefile:576: all-recursive] Error 1 make[6]: Leaving directory '/<>/build/powerpc64le-linux-gnu/libstdc++-v3' make[5]: *** [Makefile:501: all] Error 2 make[5]: Leaving directory '/<>/build/powerpc64le-linux-gnu/libstdc++-v3' make[4]: *** [Makefile:17947: all-stage1-target-libstdc++-v3] Error 2 make[4]: Leaving directory '/<>/build' make[3]: *** [Makefile:31100: stage1-bubble] Error 2 make[3]: Leaving directory '/<>/build' make[2]: *** [Makefile:31437: bootstrap] Error 2 Configured with: -v --with-pkgversion='Debian 20221001-1' --with-bugurl='file:///usr/share/doc/gcc-snapshot/README.Bugs' --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr/lib/gcc-snapshot --with-gcc-major-version-only --program-prefix= --enable-shared --enable-linker-build-id --disable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --enable-plugin --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --with-libphobos-druntime-only=yes --enable-objc-gc=auto --enable-secureplt --enable-targets=powerpcle-linux --disable-multilib --enable-multiarch --disable-werror --with-long-double-128 --enable-offload-targets=nvptx-none=/<>/debian/tmp-nvptx/usr/lib/gcc-snapshot --enable-offload-defaulted --without-cuda-driver --enable-checking=yes,extra,rtl --build=powerpc64le-linux-gnu --host=powerpc64le-linux-gnu --target=powerpc64le-linux-gnu
[Bug middle-end/107117] "atan2" fails to set the floating-point inexact exception due to constant folding, in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107117 --- Comment #4 from Andreas Schwab --- Whether the inexact exception is raised or not is unspecified in general, and atan2 is no exception.
[Bug target/105753] [avr] ICE: in add_clobbers, at config/avr/avr-dimode.md:2705
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105753
rainer-gcc at wwad dot de changed:
What|Removed |Added
CC||rainer-gcc at wwad dot de
--- Comment #7 from rainer-gcc at wwad dot de ---
Have the same problem (avr-gcc 12.1.0).
It happens, as soon as I change this code:
```
const uint8_t NumOutputs; // initialized in class constructor
uint32_t delayMs; // initialized dynamically in code before
uint32_t threshold = (0x) / NumOutputs;
if(delayMs > threshold)
{
delayMs = threshold;
}
```
to this:
```
const uint8_t NumOutputs; // initialized in class constructor via arg
uint32_t delayMs; // initialized dynamically in code before
uint32_t initialDelayMs; // initalized dynamically in code before
uint32_t threshold = (0x-initialDelayMs) / NumOutputs;
if(delayMs > threshold)
{
delayMs = threshold;
}
```
[Bug c++/96830] GCC does not complain about redeclaration with inconsistent requires clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96830 Oliver Schönrock changed: What|Removed |Added CC||oschonrock at gmail dot com --- Comment #7 from Oliver Schönrock --- It appears gcc's failure to "complain about redeclaration with inconsistent requires clause " might be hiding a small bug in libstdc++: https://godbolt.org/z/vxsY6oohM clang-trunk reports: /opt/compiler-explorer/gcc-snapshot/lib/gcc/x86_64-linux-gnu/13.0.0/../../../../include/c++/13.0.0/ranges:6098:14: error: requires clause differs in template redeclaration requires forward_range<_Vp> ^ /opt/compiler-explorer/gcc-snapshot/lib/gcc/x86_64-linux-gnu/13.0.0/../../../../include/c++/13.0.0/ranges:5797:14: note: previous template declaration is here requires input_range<_Vp> whereas gcc silently swallows the inconsistency?
