[Bug target/112959] install.tex needs updates on FreeBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112959 Gerald Pfeifer changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #14 from Gerald Pfeifer --- Thank you Thierry and Rainer - based on your feedback let me close this as resolved.
[Bug target/112959] install.tex needs updates on FreeBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112959 Gerald Pfeifer changed: What|Removed |Added CC||thierry at FreeBSD dot org --- Comment #11 from Gerald Pfeifer --- (In reply to r...@cebitec.uni-bielefeld.de from comment #6) > What's there looks good to me. Cool, thank you. I cherry picked the changes I made to the GCC 14 branch, so they should be in the GCC 14.2 release. > However, one issue mentioned in PR target/112959 is missing, namely the > problem of getting a working Ada bootstrap compiler. I have no idea if > gnat12 has been fixed since and is now able to build Ada on trunk/the > gcc-14 branch. Otherwise, the old GNAT 6.4.1 worked for me, but this > isn't easy to find. Looking at the lang/gnat12 and now lang/gcc13 ports and recent changes including ones like commit 7d359e6b779d96d82f383e3aeee8259057b16df0 Author: Thierry Thomas Date: Wed Dec 13 22:41:20 2023 +0100 lang/gnat12: bootstrap from previous assets by default All assets have been built, and it is now possible to bootstrap without lang/gcc6-aux! (which was a few days after this report was filed) I am hopefully it would work. However, I cannot guarantee. I am temped to mark this report as RESOLVED based on my changes. Thierry, what is your take, in particular related to building GNAT as it comes as part of upstream GCC?
[Bug c++/115008] New: ICE with modules on amd64-freebsd*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115008 Bug ID: 115008 Summary: ICE with modules on amd64-freebsd* Product: gcc Version: 15.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: gerald at pfeifer dot com CC: developer at lorenzosalvadore dot it, nathan at acm dot org, nshead at gcc dot gnu.org Target Milestone: --- Host: x86_64-unknown-freebsd13.2 Target: x86_64-unknown-freebsd13.2 Build: x86_64-unknown-freebsd13.2 Looking at recent test results, but even back to January 1st, I noticed that 1349 modules related tests fail on FreeBSD/amd64. Running some of them manually I see ~/gcc-ref13-amd64/bin/g++ g++.dg/modules/freeze-1_a.C \ -std=c++17 -fmodules-ts g++.dg/modules/freeze-1_a.C:5:19: internal compiler error: Segmentation fault 5 | export void bob (); | ^ 0x82a85b4ae handle_signal /usr/src/lib/libthr/thread/thr_sig.c:301 0x82a85aa6a thr_sighandler /usr/src/lib/libthr/thread/thr_sig.c:244 0x8287134a3 ??? /usr/src/lib/libc/amd64/string/memmove.S:304 alas am not able to get a core dump for some reason (surely unrelated to GCC).
[Bug target/112959] install.tex needs updates on FreeBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112959 --- Comment #5 from Gerald Pfeifer --- Rainer, do you think the three changes I made - and hence the current state of install.texi on trunk - address all the issues you reported and sufficiently well? (I hope Andrew is going to commit the change to bug #97304, which surely would help as well.) If so, I'll see to get them back into the GCC 14 branch as well.
[Bug target/112959] install.tex needs updates on FreeBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112959 Gerald Pfeifer changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |gerald at pfeifer dot com Status|NEW |ASSIGNED
[Bug ada/112958] [12/13/14/15 regression] s-exnllf.ads etc. don't compile on 32-bit FreeBSD/x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112958 --- Comment #6 from Gerald Pfeifer --- FreeBSD i386 is on it's way out: FreeBSD 14 is the last series supporting it; FreeBSD 15 is dropping support for it. Can we disable libgnat (or GNAT) support during configure time?
[Bug driver/97304] Boostrap failure on freebsd: ld: error: unable to find library -lc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97304 Gerald Pfeifer changed: What|Removed |Added CC||gerald at pfeifer dot com --- Comment #18 from Gerald Pfeifer --- (In reply to Andrew Pinski from comment #17) > Testing the removal of the code from the driver. Thanks! Looking into building on FreeBSD 13.2 with LLD (base system) instead of GNU ld (ports) I ran into this again, which is really ... surprising for a naive user. It would be great to tackle this once and for all.
[Bug middle-end/111632] gcc fails to bootstrap when using libc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632 --- Comment #22 from Gerald Pfeifer --- (In reply to Dimitry Andric from comment #21) > Indeed, please merge both commits: > https://gcc.gnu.org/git/?p=gcc.git;a=commit; > h=9970b576b7e4ae337af1268395ff221348c4b34a > https://gcc.gnu.org/git/?p=gcc.git;a=commit; > h=5213047b1d50af63dfabb5e5649821a6cb157e33 Jakub, Ian, if you approve I volunteer to gradually push this to open release branches.
[Bug tree-optimization/114369] tree-vect-loop.cc uses vec_step which is also an altivec intrinsics breaks build when building with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114369 Gerald Pfeifer changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||gerald at pfeifer dot com Last reconfirmed||2024-03-17 --- Comment #3 from Gerald Pfeifer --- I first reported this in July 2019; see https://gcc.gnu.org/pipermail/gcc/2019-July/229869.html and in particular the three responses https://gcc.gnu.org/pipermail/gcc/2019-July/229870.html https://gcc.gnu.org/pipermail/gcc/2019-July/229871.html https://gcc.gnu.org/pipermail/gcc/2019-July/229872.html for some more context.
[Bug debug/112343] New: [14 regression] ICE during GIMPLE pass: dse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112343 Bug ID: 112343 Summary: [14 regression] ICE during GIMPLE pass: dse Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: gerald at pfeifer dot com Target Milestone: --- Created attachment 56486 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56486=edit Preprocessed C source This started in the last 48 hours. /home/gerald/gcc-ref12-amd64/bin/gcc> jcparam.i -O2 -g during GIMPLE pass: dse jcparam.c: In function ‘jpeg_simple_progression’: jcparam.c:514:1: internal compiler error: Segmentation fault 514 | jpeg_simple_progression (j_compress_ptr cinfo) | ^~~ 0x829785baf handle_signal /usr/src/lib/libthr/thread/thr_sig.c:248 0x82978516e thr_sighandler /usr/src/lib/libthr/thread/thr_sig.c:191 If I use -O1 instead of -O2 or omit -g the ICE goes away.
[Bug driver/108350] Windows: invoking gcc via symlink does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108350 Gerald Pfeifer changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED CC||gerald at pfeifer dot com --- Comment #38 from Gerald Pfeifer --- Marking this as RESOLVED FIXED based on the previous comments and affirmative reports on gcc-patches@.
[Bug bootstrap/102675] [12 regression] Bootstrap fails in libsanitizer: 'MD5_DIGEST_STRING_LENGTH' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102675 --- Comment #20 from Gerald Pfeifer --- Thank you, Jakub! I finished testing/preparing the second part of the patch, just did not get to push. So I went ahead and gave your suggested patch a try - and it passes bootstrap, so good to go I'd say! Thanks.
[Bug bootstrap/102675] [12 regression] Bootstrap fails in libsanitizer: 'MD5_DIGEST_STRING_LENGTH' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102675 --- Comment #18 from Gerald Pfeifer --- Thank you, Jakub! I finished testing/preparing the second part of the patch, just did not get to push. I'll give your suggested patch a try tonight!
[Bug bootstrap/102675] [12 regression] Bootstrap fails in libsanitizer: 'MD5_DIGEST_STRING_LENGTH' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102675 Gerald Pfeifer changed: What|Removed |Added Status|WAITING |NEW --- Comment #14 from Gerald Pfeifer --- (In reply to H.J. Lu from comment #13) > Please try this. Thank you, H.J., and sorry it took me to run tests since I ran into unrelated problems. Good news: with your patch GCC is back to bootstrap on FreeBSD! (Will you apply this to GCC and push it upstream to libsanitizer?)
[Bug bootstrap/102675] [12 regression] Bootstrap fails in libsanitizer: 'MD5_DIGEST_STRING_LENGTH' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102675 --- Comment #12 from Gerald Pfeifer --- Created attachment 51658 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51658=edit $WRKDIR/i586-unknown-freebsd11.4/libsanitizer/sanitizer_common/Makefile
[Bug bootstrap/102675] [12 regression] Bootstrap fails in libsanitizer: 'MD5_DIGEST_STRING_LENGTH' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102675 --- Comment #11 from Gerald Pfeifer --- Created attachment 51657 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51657=edit $WRKDIR/i586-unknown-freebsd11.4/libsanitizer/Makefile
[Bug bootstrap/102675] [12 regression] Bootstrap fails in libsanitizer: 'MD5_DIGEST_STRING_LENGTH' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102675 --- Comment #9 from Gerald Pfeifer --- (In reply to H.J. Lu from comment #8) > Does sanitizer_common/sanitizer_platform_limits_freebsd.cpp need any header > files from GCC? >From what I found, that does not appear to be the case. > If yes, why aren't they needed in compiler-rt? > If no, can you filter out these -I options in Makefile? How do I go about that? (I did see your earlier suggestions, just ran out of time and, frankly, the experience on how to practically do this.) If you have a prototype patch to try (and maybe tweak) I'll happily do.
[Bug bootstrap/102675] [12 regression] Bootstrap fails in libsanitizer: 'MD5_DIGEST_STRING_LENGTH' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102675 --- Comment #2 from Gerald Pfeifer --- (In reply to H.J. Lu from comment #1) > That file is FreeBSD specific. Can you use a local patch to force > /usr/include/md5.h, like > > #include_next I tried replacing #include by #include_next ; that did not lead to any change. Using #include "/usr/include/md5.h" restored bootstrap. This confirms my hypothesis that it's GCC's md5.h being picked up that is the issue for this regression.
[Bug bootstrap/102675] New: [12 regression] Bootstrap fails in libsanitizer: 'MD5_DIGEST_STRING_LENGTH' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102675 Bug ID: 102675 Summary: [12 regression] Bootstrap fails in libsanitizer: 'MD5_DIGEST_STRING_LENGTH' was not declared in this scope Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: gerald at pfeifer dot com CC: hjl.tools at gmail dot com Target Milestone: --- Host: *-*-freebsd* Target: *-*-freebsd* Build: *-*-freebsd* This happens on all FreeBSD platforms and versions: CC-HEAD/libsanitizer/sanitizer_common/sanitizer_platform_limits_freebsd.cpp:370 :36: error: 'MD5_CTX' was not declared in this scope 370 | const unsigned MD5_CTX_sz = sizeof(MD5_CTX); |^~~ GCC-HEAD/libsanitizer/sanitizer_common/sanitizer_platform_limits_freebsd.cpp:371 :36: error: 'MD5_DIGEST_STRING_LENGTH' was not declared in this scope; did you mean 'SHA256_DIGEST_STRING_LENGTH'? 371 | const unsigned MD5_return_length = MD5_DIGEST_STRING_LENGTH; |^~~~ |SHA256_DIGEST_STRING_LENGTH It was introduced by commit 2e3d50c09519d1b4899845b21843bae66ecffc2f Author: H.J. Lu Date: Wed Oct 6 10:24:24 2021 -0700 libsanitizer: Merge with upstream Merged revision: fdf4c035225de52f596899931b1f6100e5e3e928 I believe the problem is that this adds #include and some dependencies on constants defined in FreeBSD's /usr/include/md5.h, where GCC features it's on $GCC_SOURCE/include/md5.h which does not provide the required constants and types.
[Bug jit/101491] [11/12 regression] /usr/local/include/libgccjit++.h conflicts between different GCC installations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101491 --- Comment #7 from Gerald Pfeifer --- (In reply to David Malcolm from comment #2) > I'm using $(includedir). What should I be using? Thanks (In reply to Richard Biener from comment #5) > I think a more appropriate place would be where we also install > OpenMP omp.h to (libsubinclude_HEADERS) David, any chance to can have a look following this recommendation? It'd be good for 11.3 to address this - thank you!
[Bug bootstrap/81315] powerpc64 vs building lang/gcc7-devel (on FreeBSD head): xgcc gets segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81315 Gerald Pfeifer changed: What|Removed |Added Resolution|--- |WORKSFORME Status|WAITING |RESOLVED --- Comment #8 from Gerald Pfeifer --- Given GCC 7 is now two generations behind the latest supported release stream (GCC 9) and the lang/gcc*-devel and regular lang/gcc* ports seem to build fine on FreeBSD/powerpc* let me close this.
[Bug bootstrap/102242] [12 regression] analyzer/engine.cc built with clang: /usr/include/c++/v1/typeinfo:346:5: error: no member named 'fancy_abort'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102242 Gerald Pfeifer changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |gerald at pfeifer dot com Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from Gerald Pfeifer --- Passed testing on my regular tester that flagged this issue last night.
[Bug bootstrap/102242] [12 regression] analyzer/engine.cc built with clang: /usr/include/c++/v1/typeinfo:346:5: error: no member named 'fancy_abort'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102242 --- Comment #3 from Gerald Pfeifer --- (In reply to David Malcolm from comment #1) > Sorry about the breakage. That's what my nightly testers are here for to catch. :) > I think I need to #define INCLUDE_UNIQUE_PTR before including system.h, > rather than manually including . Was that what your patch does? In my patch, which passed bootstrap in the meantime, I added #ifdef INCLUDE_MEMORY # include #endif to gcc/system.h and defined INCLUDE_MEMORY early in analyzer/engine.cc. Your patch sounds a little lighter and in fact more portable, so happy if you want to go with it.
[Bug bootstrap/102242] New: [11 regression] analyzer/engine.cc built with clang: /usr/include/c++/v1/typeinfo:346:5: error: no member named 'fancy_abort'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102242 Bug ID: 102242 Summary: [11 regression] analyzer/engine.cc built with clang: /usr/include/c++/v1/typeinfo:346:5: error: no member named 'fancy_abort' Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: gerald at pfeifer dot com Target Milestone: --- Only with clang as bootstrap compiler: In file included from /scratch/tmp/gerald/GCC-HEAD/gcc/analyzer/engine.cc:69: In file included from /usr/include/c++/v1/memory:653: /usr/include/c++/v1/typeinfo:346:5: error: no member named 'fancy_abort' in name space 'std::__1'; did you mean simply 'fancy_abort'? _VSTD::abort(); ^~~ /usr/include/c++/v1/__config:782:15: note: expanded from macro '_VSTD' #define _VSTD std::_LIBCPP_ABI_NAMESPACE ^ /scratch/tmp/gerald/GCC-HEAD/gcc/system.h:777:13: note: 'fancy_abort' declared here extern void fancy_abort (const char *, int, const char *) ^ I am pretty sure this is caused by gcc/analyzer/ChangeLog: PR analyzer/99260 * analyzer.h (class custom_edge_info): New class, adapted from exploded_edge::custom_info_t. Make member functions const. Make update_model return bool, converting edge param from reference to a pointer, and adding a ctxt param. (class path_context): New class. * call-info.cc: New file. * call-info.h: New file. * engine.cc: Include "analyzer/call-info.h" and . and think I have an idea how to tackle this. Prototype patch in testing...
[Bug fortran/100662] intrinsic::ieee_arithmetic fails on aarch, powerpc architectures on FreeBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100662 Gerald Pfeifer changed: What|Removed |Added CC||andreast at gcc dot gnu.org, ||gerald at pfeifer dot com Ever confirmed|0 |1 Last reconfirmed||2021-08-12 Status|UNCONFIRMED |NEW --- Comment #12 from Gerald Pfeifer --- Andreas, is this something you may be able to have a look at? (It's about the architectures you used to "play" with on FreeBSD.)
[Bug jit/101491] [11 regression] /usr/local/include/libgccjit++.h conflicts between different GCC installations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101491 Gerald Pfeifer changed: What|Removed |Added Last reconfirmed||2021-07-18 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #3 from Gerald Pfeifer --- As one data point, gccjit is a "relatively newer" thing for the FreeBSD ports of GCC, e.g. in case of lang/gcc11-devel: commit bb995aaf6e25e33b028fa4b32321864b48f49055 Author: Ashish SHUKLA Date: Tue Feb 23 09:07:37 2021 + - Enable gccjit support Approved by:gerald (maintainer) Looking at the diff it appears the issue was there back then already: --- a/lang/gcc11-devel/pkg-plist +++ b/lang/gcc11-devel/pkg-plist @@ -18,6 +18,8 @@ bin/gcov-dump%%SUFFIX%% bin/gcov-tool%%SUFFIX%% bin/gfortran%%SUFFIX%% bin/lto-dump%%SUFFIX%% +include/libgccjit++.h +include/libgccjit.h Alas it only materialized when lang/gcc12-devel was added: commit 982ce2ea27d8d41ed4f69c6c8f1eb56f04280531 Author: Gerald Pfeifer Date: Mon May 3 10:45:02 2021 + lang/gcc12-devel: New port based on the 20210426 snapshot of GCC 12.0.0 This is the first snapshot from trunk with the GCC 12 designation. It largely is a copy of lang/gcc11-devel. (In reply to David Malcolm from comment #2) > I wonder why this changed recently; as Dimitry notes, this has been > done the same since the initial merger of libgccjit into trunk. I believe we are not looking at a regression in one of the FreeBSD ports nor on the gccjit side, just an issue that's been there "from day 1". Dimitry, is this consistent with your experience? > I'm using $(includedir). What should I be using? Thanks I'm not an expert, yet dug a bit and most include files appear to be installed in lib/gcc11/gcc/i386-portbld-freebsd11.4/11.1.1/include which libgomp/Makefile, libquadmath/Makefile, libssp/Makefile and others have as libsubincludedir = $(libdir)/gcc/$(target_alias)/$(gcc_version)/include Would something like this work for libgccjit as well, David?
[Bug jit/101491] New: [11 regression] /usr/local/include/libgccjit++.h conflicts between different GCC installations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101491 Bug ID: 101491 Summary: [11 regression] /usr/local/include/libgccjit++.h conflicts between different GCC installations Product: gcc Version: 11.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: gerald at pfeifer dot com Target Milestone: --- In the FreeBSD Ports Collection (and presumably similarly other distros) we install different versions of GCC into the same prefix with --program-suffix= --libdir= --with-gxx-include-dir= which has been working very well for years. Recently users reported that /usr/local/include/libgccjit++.h is installed by both GCC 11 and GCC 12 at least, cf. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257060 Looks like this should go into a version-specific directory (such as --with-gxx-include-dir= maybe?
[Bug bootstrap/100560] New: [13 regression] build/gengtype-state.o fails with clang 10.0.1: cannot specify -o when generating multiple output files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100560 Bug ID: 100560 Summary: [13 regression] build/gengtype-state.o fails with clang 10.0.1: cannot specify -o when generating multiple output files Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: gerald at pfeifer dot com CC: marxin at gcc dot gnu.org Target Milestone: --- This started between May 9th 15:40 UTC and May 10th 15:40 UTC. c++ -std=c++11 -g -DIN_GCC-fno-strict-aliasing -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings-Wcast-qual -Wno-error=format-diag -Wno-format -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -no-pie -o build/gengtype \ build/gengtype.o build/errors.o build/gengtype-lex.o build/gengtype-parse.o build/gengtype-state.o version.h ../build-i586-unknown-freebsd11.4/libiberty/libiberty.a c++: warning: treating 'c-header' input as 'c++-header' when in C++ mode, this behavior is deprecated [-Wdeprecated] c++: error: cannot specify -o when generating multiple output files gmake[3]: *** [Makefile:2989: build/gengtype] Error 1 gmake[3]: Leaving directory '/scratch/tmp/gerald/OBJ-0511-2228/gcc' gmake[2]: *** [Makefile:4759: all-stage1-gcc] Error 2 gmake[2]: Leaving directory '/scratch/tmp/gerald/OBJ-0511-2228' gmake[1]: *** [Makefile:25415: stage1-bubble] Error 2 gmake[1]: Leaving directory '/scratch/tmp/gerald/OBJ-0511-2228' % c++ --version FreeBSD clang version 10.0.1 (g...@github.com:llvm/llvm-project.git llvmorg-10.0.1-0-gef32c611aa2) Target: i386-unknown-freebsd11.4 Martin, I saw you made a small change around gengtype that day, alas don't see how that might have triggered this? Any idea?
[Bug target/99422] [11 Regression] ICE in extract_constrain_insn building glibc pthread_create
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99422 --- Comment #15 from Gerald Pfeifer --- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99438 still happens, i.e. i586-unknown-freebsd11.2. Is anyone able to successfully build any 32-bit x86 target?
[Bug bootstrap/99438] New: [11 regression] libgcc/soft-fp/divtf3.c:51:1: error: unrecognizable insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99438
Bug ID: 99438
Summary: [11 regression] libgcc/soft-fp/divtf3.c:51:1: error:
unrecognizable insn
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: gerald at pfeifer dot com
Target Milestone: ---
Target: i586-unknown-freebsd12.2
This is a regression that entered the tree in the last 24 (plus a few
maybe hours):
/scratch/tmp/gerald/GCC-HEAD/libgcc/soft-fp/divtf3.c: In function '__divtf3':
/scratch/tmp/gerald/GCC-HEAD/libgcc/soft-fp/divtf3.c:51:1: error: unrecognizabl
e insn:
51 | }
| ^
(insn 1185 3357 3676 80 (parallel [
(set (reg:SI 5 di [621])
(asm_operands:SI ("sub{l} {%11,%3|%3,%11}
sbb{l} {%9,%2|%2,%9}
sbb{l} {%7,%1|%1,%7}
sbb{l} {%5,%0|%0,%5}") ("=r") 0 [
(reg:SI 5 di [621])
(mem/c:SI (plus:SI (reg/f:SI 6 bp)
(const_int -80 [0xffb0])) [5 A_f[2]
+0 S4 A64])
(reg:SI 1 dx [622])
(mem/c:SI (plus:SI (reg/f:SI 6 bp)
(const_int -84 [0xffac])) [5 A_f[1]
+0 S4 A32])
(reg:SI 0 ax [623])
(mem/c:SI (plus:SI (reg/f:SI 6 bp)
The invocation is
/scratch/tmp/gerald/OBJ-0306-1540/./gcc/xgcc -B/scratch/tmp/gerald/OBJ-0306-154
0/./gcc/ -B/home/gerald/gcc-ref11-i386/i586-unknown-freebsd12.2/bin/ -B/home/ge
rald/gcc-ref11-i386/i586-unknown-freebsd12.2/lib/ -isystem /home/gerald/gcc-ref
11-i386/i586-unknown-freebsd12.2/include -isystem /home/gerald/gcc-ref11-i386/i
586-unknown-freebsd12.2/sys-include -fno-checking -g -O2 -O2 -g -O2 -DIN_GCC
-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag
-Wno-format -Wstrict-prototypes -Wmissing-prototypes -Wno-error=format-diag -Wo
ld-style-definition -isystem ./include -fpic -pthread -g -DIN_LIBGCC2 -fbuild
ing-libgcc -fno-stack-protector -fpic -pthread -I. -I. -I../.././gcc -I/scratc
h/tmp/gerald/GCC-HEAD/libgcc -I/scratch/tmp/gerald/GCC-HEAD/libgcc/. -I/scratch
/tmp/gerald/GCC-HEAD/libgcc/../gcc -I/scratch/tmp/gerald/GCC-HEAD/libgcc/../inc
lude -DHAVE_CC_TLS -o _gcov_merge_add.o -MT _gcov_merge_add.o -MD -MP -MF _gc
ov_merge_add.dep -DL_gcov_merge_add -c /scratch/tmp/gerald/GCC-HEAD/libgcc/libg
cov-merge.c
[Bug bootstrap/98181] Add support for FreeBSD on powerpc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98181 Gerald Pfeifer changed: What|Removed |Added CC||segher at kernel dot crashing.org Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Gerald Pfeifer --- I believe this has been addressed and Segher committed patches for that, so closing this. Please advise in case there's something missing.
[Bug web/32927] Online installation instructions only for mainline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32927 Gerald Pfeifer changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #8 from Gerald Pfeifer --- I dislike it when it appears to reports of mine, still allow me to close this as WONTFIX since it's very unlikely to ever be addressed if it hasn't for 13 years (and it's more of an enhancement, not a critical issue). If anyone wants to give it a go, embedding invocations of gcc/doc/install.texi2html into maintainer-scripts/update_web_docs_git probably is the way to go.
