[Bug go/105302] New: gccgo for Windows using MinGW-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105302
Bug ID: 105302
Summary: gccgo for Windows using MinGW-w64
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: brechtsanders at users dot sourceforge.net
CC: cmang at google dot com
Target Milestone: ---
I thought I's give building gccgo for Windows using MinGW-w64 another try.
First of all I had to change `configure` to allow me to do that:
```
patch -ulbf configure << EOF
@@ -3577,3 +3577,3 @@
case "\${target}" in
-*-*-darwin* | *-*-cygwin* | *-*-mingw* | bpf-* )
+*-*-darwin* | *-*-cygwin* | bpf-* )
unsupported_languages="\$unsupported_languages go"
@@ -3609,3 +3609,3 @@
;;
-*-*-cygwin* | *-*-mingw*)
+*-*-cygwin*)
noconfigdirs="\$noconfigdirs target-libgo"
EOF
```
Then I added `go` to `--enable-languages=` and I added `--enable-libgo` to the
`./configure` line.
It got pretty far this time, and I actually go a working `gccgo.exe`, but libgo
wasn't such a success:
```
libtool: compile:
/d/Prog/winlibs64-11.2.0ucrt/home/gcc-12-20220417/build_mingw/./gcc/gccgo
-B/d/Prog/winlibs64-11.2.0ucrt/home/gcc-12-20220417/build_mingw/./gcc/
-L/R/winlibs64-11.2.0ucrt/inst_gcc-12-20220417/share/gcc/x86_64-w64-mingw32/lib
-L/R/winlibs64-11.2.0ucrt/inst_gcc-12-20220417/share/gcc/mingw/lib -isystem
/R/winlibs64-11.2.0ucrt/inst_gcc-12-20220417/share/gcc/x86_64-w64-mingw32/include
-isystem /R/winlibs64-11.2.0ucrt/inst_gcc-12-20220417/share/gcc/mingw/include
-B/R/winlibs64-11.2.0ucrt/inst_gcc-12-20220417/share/gcc/x86_64-w64-mingw32/bin/
-B/R/winlibs64-11.2.0ucrt/inst_gcc-12-20220417/share/gcc/x86_64-w64-mingw32/lib/
-isystem
/R/winlibs64-11.2.0ucrt/inst_gcc-12-20220417/share/gcc/x86_64-w64-mingw32/include
-isystem
/R/winlibs64-11.2.0ucrt/inst_gcc-12-20220417/share/gcc/x86_64-w64-mingw32/sys-include
--sysroot=/d/Prog/winlibs64-11.2.0ucrt/home/gcc-12-20220417/build_mingw/mingw-w64
-minline-all-stringops -O2 -g -I . -c -fgo-pkgpath=internal/bytealg
../../../libgo/go/internal/bytealg/bytealg.go
../../../libgo/go/internal/bytealg/compare_native.go
../../../libgo/go/internal/bytealg/count_generic.go
../../../libgo/go/internal/bytealg/equal_generic.go
../../../libgo/go/internal/bytealg/equal_native.go
../../../libgo/go/internal/bytealg/gccgo.go
../../../libgo/go/internal/bytealg/index_native.go
../../../libgo/go/internal/bytealg/indexbyte_native.go -DDLL_EXPORT -o
internal/.libs/bytealg.o
../../../libgo/go/internal/bytealg/bytealg.go:8:21: warning: ./internal/cpu:
Permission denied
8 | "internal/cpu"
| ^
../../../libgo/go/internal/bytealg/bytealg.go:8:21: error: error in import data
at 2329: invalid magic string
```
I feel we're getting closer. Any idea what caused this error?
[Bug go/105302] gccgo for Windows using MinGW-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105302 --- Comment #1 from Brecht Sanders --- P.S.: This attempt was with snapshot version 12-20220417
[Bug c++/105301] [12 Regression] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'overload' in coro_promise_type_found_p, at cp/coroutines.cc:516
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105301 Iain Sandoe changed: What|Removed |Added Last reconfirmed||2022-04-18 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org Status|UNCONFIRMED |NEW
[Bug target/105292] [sparc64] ICE in expand_expr_real_2 on sparc64 when compiling with -mcpu=niagara4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105292 Mikael Pettersson changed: What|Removed |Added CC||mikpelinux at gmail dot com --- Comment #1 from Mikael Pettersson --- I can reproduce with a gcc-11.2.0 cross to sparc64-linux-gnu. ICEs with -mcpu selecting ultrasparc3 or niagara[2347]. Doesn't ice if -mcpu select plain ultrasparc or niagara. Also doesn't ICE if -O3 is reduced to -O2. Still ICEs with gcc-12-20220417.
[Bug c++/105301] [11/12 Regression] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'overload' in coro_promise_type_found_p, at cp/coroutines.cc:516
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105301 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |11.3 Summary|[12 Regression] ICE: tree |[11/12 Regression] ICE: |check: expected tree that |tree check: expected tree |contains 'decl minimal' |that contains 'decl |structure, have 'overload' |minimal' structure, have |in |'overload' in |coro_promise_type_found_p, |coro_promise_type_found_p, |at cp/coroutines.cc:516 |at cp/coroutines.cc:516 CC||jakub at gcc dot gnu.org Priority|P3 |P2 --- Comment #1 from Jakub Jelinek --- Started to ICE with r11-431-g29f0e90d9904d8e0965443d4da4c95ddde5edb1e in fold_builtin*, and since r11-4076-gb003c4b14b3f889e6707db68d2c6545eda7a203b ICEs in checking from coro_promise_type_found_p.
[Bug c++/103868] ICE at end of coroutine when using asio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103868 Iain Sandoe changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org --- Comment #5 from Iain Sandoe --- candidate patch: https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593316.html
[Bug analyzer/105287] [12 Regression] ICE in analyzer get_region_for_local on C++ await cond_var
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105287 --- Comment #4 from Iain Sandoe --- candidate patch for the ICE (I am not sure if there's anything needed on the analyser side). https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593317.html
[Bug c++/105301] [11/12 Regression] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'overload' in coro_promise_type_found_p, at cp/coroutines.cc:516
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105301 --- Comment #2 from Iain Sandoe --- candidate patch. https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593318.html
[Bug debug/104050] '-fcompare-debug' failure w/ -std=c++20 -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104050 --- Comment #2 from Iain Sandoe --- (In reply to Martin Liška from comment #1) > Confirmed. Interesting that one needs -save-temps. Likely started with GCC > 11. I compared the simple from the FE with -save-temps (FAILS) and without (OK) the only difference between the two cases is that the temporary numbers are different by two (the numbers are +2 for the case without save temps). That is the same as the difference shown in the report - but not sure how to analyse that further right now ...
[Bug c++/100052] [11/12 regression] ICE in compiling g++.dg/modules/xtreme-header-3_b.C after r11-8118
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100052 --- Comment #11 from seurer at gcc dot gnu.org --- These failures are still occurring. The revision change doesn't appear to have anything to do with it given it was the "daily bump". Regressions on 11 (power8) on update from 5fb29a72faff6960f6b0c94119ae53af9a013d24, r11-9884-g5fb29a72faff69 to 97eda33b5fa29c2d0b602a44bdc375b034f4f9f3, r11-9885-g97eda33b5fa29c FAIL: g++.dg/modules/xtreme-header-3_a.H module-cmi (gcm.cache/\$srcdir/g++.dg/modules/xtreme-header-3_a.H.gcm) FAIL: g++.dg/modules/xtreme-header-3_a.H module-cmi (gcm.cache/\$srcdir/g++.dg/modules/xtreme-header-3_a.H.gcm) FAIL: g++.dg/modules/xtreme-header-3_a.H module-cmi (gcm.cache/\$srcdir/g++.dg/modules/xtreme-header-3_a.H.gcm) FAIL: g++.dg/modules/xtreme-header-3_a.H -std=c++17 (internal compiler error) FAIL: g++.dg/modules/xtreme-header-3_a.H -std=c++17 (test for excess errors) FAIL: g++.dg/modules/xtreme-header-3_a.H -std=c++2a (internal compiler error) FAIL: g++.dg/modules/xtreme-header-3_a.H -std=c++2a (test for excess errors) FAIL: g++.dg/modules/xtreme-header-3_a.H -std=c++2b (internal compiler error) FAIL: g++.dg/modules/xtreme-header-3_a.H -std=c++2b (test for excess errors) FAIL: g++.dg/modules/xtreme-header-3_b.C -std=c++17 (test for excess errors) FAIL: g++.dg/modules/xtreme-header-3_b.C -std=c++2a (test for excess errors) FAIL: g++.dg/modules/xtreme-header-3_b.C -std=c++2b (test for excess errors) FAIL: g++.dg/modules/xtreme-header-3_c.C -std=c++17 (test for excess errors) FAIL: g++.dg/modules/xtreme-header-3_c.C -std=c++2a (test for excess errors) FAIL: g++.dg/modules/xtreme-header-3_c.C -std=c++2b (test for excess errors) FAIL: g++.dg/modules/xtreme-header_a.H module-cmi (gcm.cache/\$srcdir/g++.dg/modules/xtreme-header_a.H.gcm) FAIL: g++.dg/modules/xtreme-header_a.H module-cmi (gcm.cache/\$srcdir/g++.dg/modules/xtreme-header_a.H.gcm) FAIL: g++.dg/modules/xtreme-header_a.H module-cmi (gcm.cache/\$srcdir/g++.dg/modules/xtreme-header_a.H.gcm) FAIL: g++.dg/modules/xtreme-header_a.H -std=c++17 (internal compiler error) FAIL: g++.dg/modules/xtreme-header_a.H -std=c++17 (test for excess errors) FAIL: g++.dg/modules/xtreme-header_a.H -std=c++2a (internal compiler error) FAIL: g++.dg/modules/xtreme-header_a.H -std=c++2a (test for excess errors) FAIL: g++.dg/modules/xtreme-header_a.H -std=c++2b (internal compiler error) FAIL: g++.dg/modules/xtreme-header_a.H -std=c++2b (test for excess errors) FAIL: g++.dg/modules/xtreme-header_b.C -std=c++17 (test for excess errors) FAIL: g++.dg/modules/xtreme-header_b.C -std=c++2a (test for excess errors) FAIL: g++.dg/modules/xtreme-header_b.C -std=c++2b (test for excess errors)
[Bug ada/105303] New: Assertion_Policy (Pre => Ignore) executes precondition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105303 Bug ID: 105303 Summary: Assertion_Policy (Pre => Ignore) executes precondition Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: simon at pushface dot org Target Milestone: --- System.Generic_Array_Operations starts with -- Preconditions in this unit are meant for analysis only, not for run-time -- checking, so that the expected exceptions are raised. This is enforced -- by setting the corresponding assertion policy to Ignore. Postconditions -- and contract cases should not be executed at runtime as well, in order -- not to slow down the execution of these functions. pragma Assertion_Policy (Pre=> Ignore, Post => Ignore, Contract_Cases => Ignore, Ghost => Ignore); and yet, given this clearly wrong code (compiled with -gnata) with System.Generic_Array_Operations; procedure Transposition is type Matrix is array (Integer range <>, Integer range <>) of Float; procedure Transpose is new System.Generic_Array_Operations.Transpose (Scalar => Float, Matrix => Matrix); Input : Matrix (1 .. 3, 1 .. 4); Output : Matrix (1 .. 3, 1 .. 2); begin Transpose (Input, Output); end Transposition; Ada.Assertions.Assertion_Error is in fact raised, contrary to ARM2012 11.4.2(10): $ ./transposition raised ADA.ASSERTIONS.ASSERTION_ERROR : failed precondition from s-gearop.ads:569 instantiated at transposition.adb:4 The comment noted above is confusing, if not wrong: "Preconditions ... not meant for runtime checking, so that the expected exceptions are raised" -- the checks should not be performed, and the exceptions should not be raised.
[Bug target/105162] [AArch64] outline-atomics drops dmb ish barrier on __sync builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105162 Sebastian Pop changed: What|Removed |Added Attachment #52762|0 |1 is obsolete|| --- Comment #8 from Sebastian Pop --- Created attachment 52826 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52826&action=edit patch You are right. Please see attached an amended patch that only adds the barriers to __sync builtins.
[Bug c++/104051] [coroutines] ICE: tree check: expected target_expr, have call_expr in coro_diagnose_throwing_final_aw_expr, at cp/coroutines.cc:880 since r11-7528-g9ee91079fd5879cb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104051 Iain Sandoe changed: What|Removed |Added Last reconfirmed||2022-04-18 Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Iain Sandoe --- candidate patch: https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593320.html
[Bug c++/105304] New: ICE segfault using ad-hoc concept with -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105304
Bug ID: 105304
Summary: ICE segfault using ad-hoc concept with -Wall
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bjoern at hoehrmann dot de
Target Milestone: ---
GCC 11.2.0 on Linux
❯ g++-11 -Wall -std=c++2a -o x ../mini.cxx
../mini.cxx: In function 'int main()':
../mini.cxx:23:18: internal compiler error: Segmentation fault
23 | }) {
| ^
Please submit a full bug report,
Code:
#include
#include
class X
{
public:
int m(int, int, int = 7) { return 123; }
};
template
void
invoke_m(std::index_sequence_for is)
{
X o;
o.m(Ts()...);
}
int
main()
{
if constexpr (requires {
invoke_m(std::make_index_sequence<4>());
}) {
std::cerr << "ok" << '\n';
}
return 0;
}
Compiles when omitting -Wall.
[Bug c++/105293] g++-8/i586: internal compiler error trying to compile with g++ (evtl. related to qt5/moc bug)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105293 --- Comment #5 from Elmar Stellnberger --- Created attachment 52827 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52827&action=edit 2nd version of patch that should be useable under gcc-8-8.3.0/debian/patches/ Last time I reported that I could not test the patch posted here because the result of package creation with dpkg-buildpackage had vanished. Luckily I found gcc/xg++ and gcc/xgcc which were the required executables that could be installed into /bin/ and tested whether they compiled the new Firefox. g++ with the last patch did not do this. Consequently I have checked out 10.2.2, newer than the last known working good one (10.1.1) from Debian 11 and analysed all changes along the backtrace again. What I found is condensed in the patch above: discover_nonconstant_array_refs (); - was moved up in addition to the other change tested already before If the error is evoked by what is called along the backtrace this needs to resolve it. (I assume now that the Qt5/moc bug is independent and do not use it as reference for the gcc version to compare against any more). Otherwise, the error may stem from something done in a previous pass: during RTL pass: expand Unfortunately this time I was not even able to compile gcc/xg++. Makefiles were garbled, xgcc did not produce a.out (test in Makefile), texinfo files were invalid and I had to copy them from a fresh root and ultimately xg++ stayed the same after all. I had rescued the original g++ as /bin/g++ and that one turned into a link (I know it was a regular file before) although all debian/rules Makefiles only ship into debian/tmp/usr/... and not /. Absolutely no chance to test this second patch! Perhaps someone else can do.
[Bug fortran/103662] [12 Regression] TBAA problem in Fortran FE triggering in gfortran.dg/unlimited_polymorphic_3.f03
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103662 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #12 from Mikael Morin --- Created attachment 52828 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52828&action=edit Fix attempt I think the attached patch avoids the multiple declarations for __class_STAR_p, but the testsuite FAIL remains, so I must be missing important. Is there a -fdump-tree-types or something so that the problem can be seen in dumps (both for eyeballing and for matching with the testsuite)?
[Bug fortran/103662] [12 Regression] TBAA problem in Fortran FE triggering in gfortran.dg/unlimited_polymorphic_3.f03
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103662 --- Comment #13 from Mikael Morin --- (In reply to Mikael Morin from comment #12) > ... so I must be missing important. I must be missing *something* important.
[Bug c++/105289] [11/12 Regression] ICE on partial specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105289 Patrick Palka changed: What|Removed |Added Known to fail||11.2.0, 12.0 Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Target Milestone|--- |11.4 Last reconfirmed||2022-04-18 Ever confirmed|0 |1 Summary|[11 Regression] ICE on |[11/12 Regression] ICE on |partial specialization |partial specialization Status|UNCONFIRMED |ASSIGNED Keywords||ice-on-valid-code CC||ppalka at gcc dot gnu.org Known to work||10.3.0, 9.4.0 --- Comment #1 from Patrick Palka --- Confirmed, started with r11-6483-ge2e2f3f2c9400f.
[Bug c++/105104] [coroutines] ICE during GIMPLE pass: coro-early-expand-ifns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105104
Iain Sandoe changed:
What|Removed |Added
Last reconfirmed|2022-03-30 00:00:00 |2022-4-18
CC||iains at gcc dot gnu.org,
||jakub at gcc dot gnu.org
Status|WAITING |NEW
Keywords||ice-on-valid-code
--- Comment #6 from Iain Sandoe ---
Initial analysis - perhaps some issue with constexpr processing:
When we have a void await_return() in the final_awaiter class:
final.suspend:
frame_ptr->_Coro_resume_fn = 0B;
{
struct final_awaiter Fs [value-expr: frame_ptr->Fs_1_2];
frame_ptr->_Coro_resume_index = 4;
_15 = &frame_ptr->_Coro_self_handle;
D.9844 = std::__n4861::coroutine_handle::operator
std::__n4861::coroutine_handle (_15);
return_object::promise_type::final_awaiter::await_suspend (D.9844);
D.9768 = .CO_YIELD (4, 1, &resume.4, &destroy.4, frame_ptr);
retval.2 = D.9768;
switch (retval.2) , case 0: , case 1: >
:
.CO_SUSPN (&actor.suspend.ret);
:
goto resume.4;
:
goto destroy.4;
destroy.4:
goto coro.delete.promise;
resume.4:
return_object::promise_type::final_awaiter::await_resume ();
}
when the await_resume() function is made to return an int.
final.suspend:
frame_ptr->_Coro_resume_fn = 0B;
{
destroy.4:
goto coro.delete.promise;
resume.4:
}
So we have a dangling label at the end of that scope (which then gives rise to
the crash).
* If I remove the 'contexpr' from the await_resume() function, then it all
works as expected.
* AFAICT, the content is correct in "expand_one_await_expression()".
* Altering the coroutines code to cast the result of the await_resume() to void
makes no difference.
[Bug c++/104020] [coroutines] ICE in co_await function call with initializer_list arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104020 Iain Sandoe changed: What|Removed |Added CC||iains at gcc dot gnu.org Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Iain Sandoe --- As Avi says, this is a dup of 98056. *** This bug has been marked as a duplicate of bug 98056 ***
[Bug c++/98056] coroutines: ICE tree check: expected record_type or union_type or qual_union_type, have array_type since r11-2183-g0f66b8486cea8668
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98056 Iain Sandoe changed: What|Removed |Added CC||me at xecycle dot info --- Comment #18 from Iain Sandoe --- *** Bug 104020 has been marked as a duplicate of this bug. ***
[Bug c++/103963] Coroutine return type needs not be copy- or move-constructible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103963 Iain Sandoe changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2022-04-18 CC||iains at gcc dot gnu.org
[Bug c++/104981] [coroutines] Internal compiler error when promise object's constructor takes a base class of the object parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104981 Iain Sandoe changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2022-04-18
[Bug c++/104981] [coroutines] Internal compiler error when promise object's constructor takes a base class of the object parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104981 --- Comment #1 from Iain Sandoe --- the coroutines code appears to be passing reasonable input to the CTOR build call. coroutines.cc:4922: r = build_special_member_call (p, complete_ctor_identifier, NULL, promise_type, LOOKUP_NORMAL, tf_warning_or_error); I think I will need some help from folks more knowledgeable about the lookup code.
[Bug go/105302] gccgo for Windows using MinGW-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105302 --- Comment #2 from Ian Lance Taylor --- I have no idea why you would get a "Permission denied" error opening an import package. That said I would not expect this to work. Somebody would have to clean up libgo to support Windows.
[Bug go/105302] gccgo for Windows using MinGW-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105302 --- Comment #3 from Brecht Sanders --- What exactly would be the file(s) being opened in this case? When can we expect the libgo cleanup needed for MinGW(-w64) support?
[Bug go/105302] gccgo for Windows using MinGW-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105302 --- Comment #4 from Ian Lance Taylor --- > What exactly would be the file(s) being opened in this case? The file that should be opened is the file internal/cpu.gox in the libgo build directory. > When can we expect the libgo cleanup needed for MinGW(-w64) support? I don't know of anybody who is working on this.
[Bug libquadmath/105101] incorrect rounding for sqrtq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105101 --- Comment #11 from Michael_S --- (In reply to Michael_S from comment #10) > BTW, the same ideas as in the code above could improve speed of division > operation (on modern 64-bit HW) by factor of 3 (on Intel) or 2 (on AMD). Did it. On Intel it's even better than anticipated. 5x speedup on Haswell and Skylake, 4.5x on Ivy Bridge. Unfortunately, right now I have no connection to my Zen3 test system, so can't measure on it with final variant. But according to preliminary tests the speedup should be slightly better than 2x.
[Bug c/100545] ICE with -g: in gen_typedef_die with mode attribute and aligned attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100545 --- Comment #3 from Jason Merrill --- Created attachment 52829 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52829&action=edit fix
[Bug middle-end/104986] [12 Regression] bogus writing 1 byte into a region of size 0 with -fwrapv and -O2 -fpeel-loops since r12-4698-gf6d012338bf87f42
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104986 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #9 from Jakub Jelinek --- The strlen pass itself for its original purpose doesn't use the ranger at all, it is just the warning code that uses the strlen infrastructure and is invoked during the pass that does.
[Bug c/105305] New: ARM32: gcc does not pass all library directories to linker
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105305 Bug ID: 105305 Summary: ARM32: gcc does not pass all library directories to linker Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: rui314 at gmail dot com Target Milestone: --- I'm the author of the mold linker (https://github.com/rui314/mold). As far as I know, gcc always passes all library paths to the linker by -L, but I got a bug report that that's not the case on ARM32. It is reported that gcc does not pass some obvious paths such as `-L/usr` or `-L/usr/lib`. The code to explicitly exclude "obvious" directories is here: https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/gcc.cc;h=bb07cc244e30fbeccc701816db888f497d65eb08;hb=refs/heads/master#l7931 mold and LLVM lld don't have the notion of the default search paths for the sake of build reproducibility. They guarantee that as long as you pass the exact same command line options and input files, the linkers behave exactly the same regardless of the host machine (in LLD, that's guaranteed even across Unix and Windows.) That helps us a lot when we do cross compilation. So, can gcc pass all library paths to the linker on ARM32? https://github.com/rui314/mold/issues/336
[Bug target/105305] ARM32: gcc does not pass all library directories to linker
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105305 Andrew Pinski changed: What|Removed |Added Target||arm*-*-* --- Comment #1 from Andrew Pinski --- Gold also didn't search any by default.
[Bug ipa/105306] New: [12 Regression] ICE: verify_cgraph_node failed (error: semantic interposition mismatch)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105306 Bug ID: 105306 Summary: [12 Regression] ICE: verify_cgraph_node failed (error: semantic interposition mismatch) Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: asolokha at gmx dot com CC: marxin at gcc dot gnu.org Target Milestone: --- g++ 12.0.1 20220417 snapshot (g:000c1b89d259fadb466e1f2e63c79da45fd17372) ICEs when compiling gcc/testsuite/g++.dg/opt/pr59947.C w/ -Ofast: % g++-12.0.1 -Ofast -c gcc/testsuite/g++.dg/opt/pr59947.C gcc/testsuite/g++.dg/opt/pr59947.C:34:24: error: semantic interposition mismatch 34 | template class E ; |^ _ZN1BD1Ev/6 (B::~B()) @0x7fdd9c891880 Type: function definition analyzed alias cpp_implicit_alias Visibility: externally_visible public weak comdat comdat_group:_ZN1BD5Ev one_only Same comdat group as: _ZN1BD2Ev/5 References: _ZN1BD2Ev/5 (alias) Referring: Availability: available Function flags: Called by: _ZN1CI1DED2Ev/9 Calls: during IPA pass: visibility gcc/testsuite/g++.dg/opt/pr59947.C:34:24: internal compiler error: verify_cgraph_node failed 0xcfe1e0 cgraph_node::verify_node() /var/tmp/portage/sys-devel/gcc-12.0.1_p20220417/work/gcc-12-20220417/gcc/cgraph.cc:3873 0xced4f4 symtab_node::verify() /var/tmp/portage/sys-devel/gcc-12.0.1_p20220417/work/gcc-12-20220417/gcc/symtab.cc:1359 0xcee6e7 symtab_node::verify_symtab_nodes() /var/tmp/portage/sys-devel/gcc-12.0.1_p20220417/work/gcc-12-20220417/gcc/symtab.cc:1387 0xfb169c symtab_node::checking_verify_symtab_nodes() /var/tmp/portage/sys-devel/gcc-12.0.1_p20220417/work/gcc-12-20220417/gcc/cgraph.h:682 0xfb169c symbol_table::remove_unreachable_nodes(_IO_FILE*) /var/tmp/portage/sys-devel/gcc-12.0.1_p20220417/work/gcc-12-20220417/gcc/ipa.cc:679 0x10c9be9 execute_todo /var/tmp/portage/sys-devel/gcc-12.0.1_p20220417/work/gcc-12-20220417/gcc/passes.cc:2153
[Bug c++/105307] New: -fmax-errors truncated for concept diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105307
Bug ID: 105307
Summary: -fmax-errors truncated for concept diagnostics
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ich.freak at gmx dot net
Target Milestone: ---
In #92440 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92440) it was remarked
that -fmax-errors=1 truncates the first error "in the middle of the sentence"
and a patch was supplied. However, the problem still persists for concepts:
template concept HasX = requires { T::x; };
template struct S {};
struct NoX {};
S s;
compiled with
> g++ -std=c++20 -fconcepts-diagnostics-depth=3 test.cpp -o test
yields:
>test.cpp:4:6: error: template constraint failure for 'template
>>requires HasX struct S'
>4 | S s;
> | ^
>test.cpp:4:6: note: constraints not satisfied
>test.cpp: In substitution of 'template requires HasX struct S
>>[with T = NoX]':
>test.cpp:4:6: required from here
>test.cpp:1:26: required for the satisfaction of 'HasX' [with T = NoX]
>test.cpp:1:33: in requirements [with T = NoX]
>test.cpp:1:47: note: the required expression 'T::x' is invalid, because
>1 | templateconcept HasX = requires { T::x; };
> | ^
>test.cpp:1:47: error: 'x' is not a member of 'NoX'
And, if we add -fmax-errors=1, we get:
>test.cpp:4:6: error: template constraint failure for 'template
>>requires HasX struct S'
>4 | S s;
> | ^
>test.cpp:4:6: note: constraints not satisfied
>test.cpp: In substitution of 'template requires HasX struct S
>>[with T = NoX]':
>test.cpp:4:6: required from here
>test.cpp:1:26: required for the satisfaction of 'HasX' [with T = NoX]
>test.cpp:1:33: in requirements [with T = NoX]
>test.cpp:1:47: note: the required expression 'T::x' is invalid, because
>1 | templateconcept HasX = requires { T::x; };
> | ^
>compilation terminated due to -fmax-errors=1.
However, the "explanatory errors" that are getting truncated here still
logically belong to the same error and should, therefore, not be truncated.
