[Bug target/103370] [12 Regression] Assembler error building glibc for ColdFire soft-float
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103370 Richard Biener changed: What|Removed |Added Priority|P3 |P4 --- Comment #5 from Richard Biener --- The issue likely has gone latent. m68k is not primary/secondary.
[Bug target/103894] New: ICE: in emit_move_multi_word, at expr.c:3870 with -mno-sse2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103894 Bug ID: 103894 Summary: ICE: in emit_move_multi_word, at expr.c:3870 with -mno-sse2 Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 52110 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52110=edit reduced testcase This seems to be a recent regression. Compiler output: $ x86_64-pc-linux-gnu-gcc -mno-sse2 testcase.c during RTL pass: reload testcase.c: In function 'foo': testcase.c:9:1: internal compiler error: in emit_move_multi_word, at expr.c:3870 9 | } | ^ 0x6c6c3b emit_move_multi_word /repo/gcc-trunk/gcc/expr.c:3870 0xfa3d0b gen_move_insn(rtx_def*, rtx_def*) /repo/gcc-trunk/gcc/expr.c:4145 0x11ade8d curr_insn_transform /repo/gcc-trunk/gcc/lra-constraints.c:4214 0x11af026 lra_constraints(bool) /repo/gcc-trunk/gcc/lra-constraints.c:5161 0x114 lra(_IO_FILE*) /repo/gcc-trunk/gcc/lra.c:2336 0x114c429 do_reload /repo/gcc-trunk/gcc/ira.c:5932 0x114c429 execute /repo/gcc-trunk/gcc/ira.c:6118 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r12-6173-20220102211314-g9ff206d3865-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r12-6173-20220102211314-g9ff206d3865-checking-yes-rtl-df-extra-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.0.0 20220102 (experimental) (GCC)
[Bug c/50581] stdarg doesn't support array types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50581 --- Comment #8 from Andrew Pinski --- I am hearing there is a C23 proposal to that might fix this.
[Bug demangler/92453] write buffer overflow in cplus_demangle()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92453 Andrew Pinski changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #5 from Andrew Pinski --- *** Bug 103893 has been marked as a duplicate of this bug. ***
[Bug demangler/103893] ada demangler heap overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103893 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup of bug 92453. A patch was posted even. *** This bug has been marked as a duplicate of bug 92453 ***
[Bug demangler/103893] New: ada demangler heap overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103893 Bug ID: 103893 Summary: ada demangler heap overflow Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: demangler Assignee: unassigned at gcc dot gnu.org Reporter: amodra at gmail dot com Target Milestone: --- >From https://sourceware.org/bugzilla/show_bug.cgi?id=28736 valgrind c++filt -s gnat vfSO__fffSO ==1573233== Invalid write of size 1 ==1573233==at 0x4848DCC: strcpy (vg_replace_strmem.c:523) ==1573233==by 0x72688C: ada_demangle (cplus-dem.c:338) ==1573233==by 0x726ABA: cplus_demangle (cplus-dem.c:187) ==1573233==by 0x4038E8: demangle_it (cxxfilt.c:66) ==1573233==by 0x403AEC: main (cxxfilt.c:203) ==1573233== Address 0x4a60057 is 0 bytes after a block of size 23 alloc'd ==1573233==at 0x4842839: malloc (vg_replace_malloc.c:380) ==1573233==by 0x737A6B: xmalloc (xmalloc.c:147) ==1573233==by 0x726617: ada_demangle (cplus-dem.c:223) ==1573233==by 0x726ABA: cplus_demangle (cplus-dem.c:187) ==1573233==by 0x4038E8: demangle_it (cxxfilt.c:66) ==1573233==by 0x403AEC: main (cxxfilt.c:203) The following comment in cplus-dem.c:ada_demangle is false for fuzzed input, specifically the part that says "they occur only once". /* Most of the demangling will trivially remove chars. Operator names may add one char but because they are always preceeded by '__' which is replaced by '.', they eventually never expand the size. A few special names such as '___elabs' add a few chars (at most 7), but they occur only once. */ len0 = strlen (mangled) + 7 + 1; demangled = XNEWVEC (char, len0);
[Bug c/33193] slopiness in __real/__imag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33193 Andrew Pinski changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2022-January ||/587531.html Keywords||patch --- Comment #8 from Andrew Pinski --- Patch posted with the rewrite: https://gcc.gnu.org/pipermail/gcc-patches/2022-January/587531.html
[Bug analyzer/103892] New: -Wanalyzer-double-free false positive when compiling libpipeline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103892
Bug ID: 103892
Summary: -Wanalyzer-double-free false positive when compiling
libpipeline
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: cjwatson at ubuntu dot com
Target Milestone: ---
Created attachment 52109
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52109=edit
reduced version of lib/pipeline.c
Using gcc (Debian 11.2.0-13) 11.2.0 from Debian unstable, I tried -fanalyzer on
https://gitlab.com/cjwatson/libpipeline, and I ran into what looks like a false
positive from -Wanalyzer-double-free. I've attached a test case that's reduced
as far as I could. There's no double-free here, just fairly straightforward
freeing of elements of a tagged union, but it looks like the analyzer is
perhaps getting confused by the fact that the freeing is recursive? (The
argstr_get_word and pipecmd_new_argstr functions appear entirely superfluous to
the problem, and I trimmed down their bodies as far as I could, but if I remove
anything else from them then the problem goes away.)
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 11.2.0-13'
--with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-11
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--enable-libphobos-checking=release --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-11-KdLYb3/gcc-11-11.2.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-11-KdLYb3/gcc-11-11.2.0/debian/tmp-gcn/usr
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
--with-build-config=bootstrap-lto-lean --enable-link-serialization=2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.0 (Debian 11.2.0-13)
$ gcc -save-temps -fanalyzer -Wall -Wno-analyzer-malloc-leak
-Wanalyzer-too-complex -g -O2 -Wall -c t.c -fPIC -DPIC -o t.o
t.c: In function ‘pipecmd_free’:
cc1: warning: terminating analysis for this program point: callstring: [(SN: 14
-> SN: 9 in pipecmd_free)] before (SN: 6 stmt: 0): :EN: 67, EN: 77, EN:
87, EN: 97, EN: 107, EN: 117, EN: 127, EN: 137 [-Wanalyzer-too-complex]
t.c: At top level:
t.c:43:6: warning: analysis bailed out early (131 'after-snode' enodes; 491
enodes) [-Wanalyzer-too-complex]
43 | void pipecmd_free (struct pipecmd *cmd)
| ^~~~
t.c: In function ‘pipecmd_free’:
t.c:56:25: warning: double-‘free’ of ‘*(struct pipecmd_process *)((char *)cmd +
8).argv’ [CWE-415] [-Wanalyzer-double-free]
56 | free (cmdp->argv);
| ^
‘pipecmd_free’: events 1-4
|
| 43 | void pipecmd_free (struct pipecmd *cmd)
| | ^~~~
| | |
| | (1) entry to ‘pipecmd_free’
|..
| 47 | if (!cmd)
| |~
| ||
| |(2) following ‘false’ branch (when ‘cmd’ is
non-NULL)...
|..
| 50 | switch (cmd->tag) {
| | ~~
| | |
| | (3) ...to here
| | (4) following ‘case 1:’ branch...
|
‘pipecmd_free’: event 5
|
|cc1:
| (5): ...to here
|
‘pipecmd_free’: events 6-8
|
| 64 | for (i = 0; i < cmds->ncommands; ++i)
| | ~~^
| | |
| | (6) following ‘true’
branch...
| 65 | pipecmd_free (cmds->commands[i]);
| |
| | |
| | (7) ...to here
| | (8) calling ‘pipecmd_free’ from
‘pipecmd_free’
|
[Bug fortran/101762] ICE with "Every subscript of the target specification must be a constant expression"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101762 --- Comment #4 from anlauf at gcc dot gnu.org --- Created attachment 52108 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52108=edit Improved patch The previous patch was too strict. The attached version does a much better job, but needs more testing and provides more concise error messages also for substrings.
[Bug libstdc++/103891] clang-13 fails to compile libstdc++'s std::variant>: error: attempt to use a deleted function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103891 --- Comment #1 from Andrew Pinski --- >Should libstdc++ work as is against clang++? Does it perhaps need a small >tweak? it depends, It might be the case that clang does not implement all of C++20 that GCC implements either. There is also PR 79424 which might be related to your reduced testcase.
[Bug libstdc++/103891] New: clang-13 fails to compile libstdc++'s std::variant>: error: attempt to use a deleted function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103891
Bug ID: 103891
Summary: clang-13 fails to compile libstdc++'s
std::variant>: error: attempt to use
a deleted function
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
Target Milestone: ---
Initially I observed the error as a mold-1.0.0 build failure on clang-13 which
uses gcc-12's libstdc++. Here is a one line reproducer:
#include
#include
std::variant > v;
$ /tmp/gcc-12/bin/c++ -std=c++20 -c tapi.cc
$ /tmp/clang-13/bin/c++ -std=c++20 -c tapi.cc
/<>/gcc-12.0.0/include/c++/12.0.0/variant:460:2: error: attempt to use a
deleted function
_Variant_storage(in_place_index_t<_Np>, _Args&&... __args)
^
/<>/gcc-12.0.0/include/c++/12.0.0/variant:747:4: note: in instantiation of
function template specialization
'std::__detail::__variant::_Variant_storage>::_Variant_storage<0UL>' requested here
: _Base(__i, std::forward<_Args>(__args)...)
^
/<>/gcc-12.0.0/include/c++/12.0.0/variant:742:9: note: in instantiation of
function template specialization
'std::__detail::__variant::_Variant_base>::_Variant_base<0UL>'
requested here
: _Variant_base(in_place_index<0>) { }
^
/<>/gcc-12.0.0/include/c++/12.0.0/variant:1403:7: note: in instantiation
of member function
'std::__detail::__variant::_Variant_base>::_Variant_base'
requested here
variant() = default;
^
...
I attempted to reduce it down to something manageable but ended up with
something else: https://github.com/llvm/llvm-project/issues/52956
I don't really understand how requires() works.
Should libstdc++ work as is against clang++? Does it perhaps need a small
tweak?
Thank you!
[Bug fortran/101762] ICE with "Every subscript of the target specification must be a constant expression"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101762 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #3 from anlauf at gcc dot gnu.org --- Untested patch: diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c index 4971638f9b6..9d37a71abb9 100644 --- a/gcc/fortran/decl.c +++ b/gcc/fortran/decl.c @@ -2525,6 +2525,9 @@ match_pointer_init (gfc_expr **init, int procptr) "initialization at %C")) return MATCH_ERROR; + if (!gfc_check_init_expr (*init)) +return MATCH_ERROR; + return MATCH_YES; } This would result in: pr101762.f90:3:28: 3 | integer, pointer :: x => a(n()) |1 Error: Array 'a' at (1) is a variable, which does not reduce to a constant expression
[Bug fortran/102332] ICE in select_type_set_tmp, at fortran/match.c:6366
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102332 --- Comment #5 from CVS Commits --- The releases/gcc-11 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:718b47e1cd4e667ef3e9b24630f0a2d923d7c802 commit r11-9428-g718b47e1cd4e667ef3e9b24630f0a2d923d7c802 Author: Harald Anlauf Date: Mon Dec 27 23:06:18 2021 +0100 Fortran: avoid several NULL pointer dereferences during error recovery gcc/fortran/ChangeLog: PR fortran/102332 * expr.c (gfc_get_variable_expr): Avoid NULL pointer dereferences during handling of errors with invalid uses of CLASS variables. * match.c (select_type_set_tmp): Likewise. * primary.c (gfc_match_varspec): Likewise. * resolve.c (resolve_variable): Likewise. (resolve_select_type): Likewise. gcc/testsuite/ChangeLog: PR fortran/102332 * gfortran.dg/pr102332.f90: New test. (cherry picked from commit d8f6c48ccb85ecc0d97a84c32b7a1b8f43c64fe4)
[Bug target/103861] [i386] vectorize v2qi vectors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103861
--- Comment #5 from CVS Commits ---
The master branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:9ff206d3865df5cb8407490aa9481029beac087f
commit r12-6173-g9ff206d3865df5cb8407490aa9481029beac087f
Author: Uros Bizjak
Date: Sun Jan 2 21:12:10 2022 +0100
i386: Introduce V2QImode vectorized arithmetic [PR103861]
This patch adds basic V2QImode infrastructure and V2QImode arithmetic
operations (plus, minus and neg). The patched compiler can emit SSE
vectorized QImode operations (e.g. PADDB) with partial QImode vector,
and also synthesized double HI/LO QImode operations with integer registers.
The testcase:
typedef char __v2qi __attribute__ ((__vector_size__ (2)));
__v2qi plus (__v2qi a, __v2qi b) { return a + b; };
compiles with -O2 to:
movl%edi, %edx
movl%esi, %eax
addb%sil, %dl
addb%ah, %dh
movl%edx, %eax
ret
which is much better than what the unpatched compiler produces:
movl%edi, %eax
movl%esi, %edx
xorl%ecx, %ecx
movb%dil, %cl
movsbl %dh, %edx
movsbl %ah, %eax
addl%edx, %eax
addb%sil, %cl
movb%al, %ch
movl%ecx, %eax
ret
The V2QImode vectorization does not require vector registers, so it can
be enabled by default also for 32-bit targets without SSE.
The patch also enables vectorized V2QImode sign/zero extends.
2021-12-30 Uroš Bizjak
gcc/ChangeLog:
PR target/103861
* config/i386/i386.h (VALID_SSE2_REG_MODE): Add V2QImode.
(VALID_INT_MODE_P): Ditto.
* config/i386/i386.c (ix86_secondary_reload): Handle
V2QImode reloads from SSE register to memory.
(vector_mode_supported_p): Always return true for V2QImode.
* config/i386/i386.md (*subqi_ext_2): New insn pattern.
(*negqi_ext_2): Ditto.
* config/i386/mmx.md (movv2qi): New expander.
(movmisalignv2qi): Ditto.
(*movv2qi_internal): New insn pattern.
(*pushv2qi2): Ditto.
(negv2qi2 and splitters): Ditto.
(v2qi3 and splitters): Ditto.
gcc/testsuite/ChangeLog:
PR target/103861
* gcc.dg/store_merging_18.c (dg-options): Add -fno-tree-vectorize.
* gcc.dg/store_merging_29.c (dg-options): Ditto.
* gcc.target/i386/pr103861.c: New test.
* gcc.target/i386/pr92658-avx512vl.c (dg-final):
Remove vpmovqb scan-assembler xfail.
* gcc.target/i386/pr92658-sse4.c (dg-final):
Remove pmovzxbq scan-assembler xfail.
* gcc.target/i386/pr92658-sse4-2.c (dg-final):
Remove pmovsxbq scan-assembler xfail.
* gcc.target/i386/warn-vect-op-2.c (dg-warning): Adjust warnings.
[Bug c++/103783] Ambiguous overload between constrained static member and unconstrained non-static member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103783 --- Comment #4 from David Stone --- A correction to my previous comment: n4868 is technically a C++23 working draft (but claims to have only editorial fixes to the C++20 paper). However, I believe the wording fixes to this section are intended to be a bug fix for wording that was not updated when we added concepts and thus is the intended C++20 behavior.
[Bug libstdc++/103890] Generated baseline symbol file seems to have redundant lines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103890 --- Comment #2 from dave.anglin at bell dot net --- Is that what we want?
[Bug libstdc++/103890] Generated baseline symbol file seems to have redundant lines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103890 --- Comment #1 from Andreas Schwab --- That's because '/\.dynsym/,/^$/' is matching two regions. The first region is the .dynsym section, the second region is starting at the section symbol in the normal symtab. The latter produces the unversioned symbols.
[Bug fortran/103390] [12 Regression] ICE: gimplification failed since r12-4591-g1af78e731feb9327
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103390 --- Comment #6 from sandra at gcc dot gnu.org --- Patch posted: https://gcc.gnu.org/pipermail/fortran/2022-January/057249.html
[Bug libstdc++/103890] New: Generated baseline symbol file seems to have redundant lines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103890 Bug ID: 103890 Summary: Generated baseline symbol file seems to have redundant lines Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Target Milestone: --- Host: hppa*-*-linux* Target: hppa*-*-linux* Build: hppa*-*-linux* When I generated a new baseline symbols file, it has lines with and without symbol versions: FUNC:_ZGTtNKSt11logic_error4whatEv FUNC:_ZGTtNKSt11logic_error4whatEv@@GLIBCXX_3.4.22 FUNC:_ZGTtNKSt13bad_exception4whatEv FUNC:_ZGTtNKSt13bad_exception4whatEv@@CXXABI_1.3.10 FUNC:_ZGTtNKSt13bad_exceptionD1Ev FUNC:_ZGTtNKSt13bad_exceptionD1Ev@@CXXABI_1.3.10 FUNC:_ZGTtNKSt13runtime_error4whatEv FUNC:_ZGTtNKSt13runtime_error4whatEv@@GLIBCXX_3.4.22 [...] None of the other baseline_symbols.txt files duplicate this info. File does pass abi check though.
[Bug c++/103783] Ambiguous overload between constrained static member and unconstrained non-static member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103783 --- Comment #3 from David Stone --- Fedor, it looks like that wording was changed to a non-normative note and expanded in N4868 to say: "There cannot be a static and a non-static member function with the same name, parameter-type-list, and trailing requires-clause ([over.load]).". https://timsong-cpp.github.io/cppwp/n4868/class.static.mfct#2. Later versions of the standard (for C++23) removed the sentence entirely.
[Bug target/103889] gccgo is unable to find its standard library by default on 64-Bit RISC-V due to musl not using multilib but still uses t-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103889 --- Comment #13 from John Doe --- (In reply to Andrew Pinski from comment #12) > Because the Linux-gnu folks will always use lib64 instead of lib here. So > there is no need to fix gcc/config/riscv/t-linux. There is a LSF on purpose > which I thought defined this all for *-*-linux-gnu across distros. What is LSF? Do you mean LSB (Linux Standard Base)? Because the comment in the t-linux64 i386 configuration file explicitly states: > The LSB does not enforce the use of /lib64 and /usr/lib64 I might be repeating myself but other architecture configuration files explicitly include a check to ensure that this directory exists, e.g.: > $(if $(wildcard $(shell echo > $(SYSTEM_HEADER_DIR))/../../usr/lib32),../lib32,../lib) Then again I am personally not very familiar with these configuration files, it just seems odd to me that the RISC-V one doesn't have such a check.
[Bug target/103882] Register corruption in ASM only functions when optization is -O2/-Os/-O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103882 Andreas Schwab changed: What|Removed |Added Resolution|WORKSFORME |INVALID
[Bug target/103882] Register corruption in ASM only functions when optization is -O2/-Os/-O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103882 Jose Silva changed: What|Removed |Added Resolution|INVALID |WORKSFORME --- Comment #15 from Jose Silva --- > IPA RA is a very useful optimization, not something terrible. > that would penalize millions of correctly written inline asm statements in > real-world code It's a useful optimization but GCC offers a terrible implementation of it. As I elaborated before, if I have to always tell the compiler what my inline asm is doing then it's just garbage. If no clobber information is provided the compiler should just bail out of the IPA RA for that given function and follow the ABI strictly. It could also emit a warning telling the programmer that by not providing clobber information the optimization is not as good. With clobber information it should just trust the programmer. If by "correctly written inline asm statements" you mean statements with clobber information, then they wouldn't be penalized because they are providing the necessary information. ~Sensible defaults~ is what I'm talking about. Have you considered that users don't want to RE the kernel just to see what registers are being clobbered? The ABI exists for that reason, if everyone follows that there is no problem. > (except that __attribute__((naked)) > Or just use the syscall function, see syscall(2) man page. > And I've only spent last 23+ years working on GCC, so yes, I can't know the > codebase enough. naked is not supported as an attribute for MIPS targets. It was the first thing I tried when trying to stop the compiler from optimizing the code. The `syscall` function is useless for me because the platform I'm targeting passes the number in $v1 and not $a0. And as I said in the original post, I'm using `-nostdlib' so there's no access to the `syscall` function. Stop making bad suggestions to try and justify a bad compiler optimization implementation. > A hack that you want to propose (forcing noipa on functions that use inline > asm) certainly won't be accepted I have no interest in upstreaming my changes. It was clear from the thread you had no interest in it. I just requested some guidance on the toxic wasteland that is the GCC codebase. If you don't want to help, don't bother responding.
[Bug target/103889] gccgo is unable to find its standard library by default on 64-Bit RISC-V due to musl not using multilib but still uses t-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103889 --- Comment #12 from Andrew Pinski --- (In reply to John Doe from comment #11) > Right, but I assume this problem should also exist on glibc systems which > only have /lib/ instead of /lib64/ then. So apart from adding a > gcc/config/riscv/t-linux-musl file in the future, the existing > gcc/config/riscv/t-linux should also be fixed IMHO :) Because the Linux-gnu folks will always use lib64 instead of lib here. So there is no need to fix gcc/config/riscv/t-linux. There is a LSF on purpose which I thought defined this all for *-*-linux-gnu across distros.
[Bug target/103889] gccgo is unable to find its standard library by default on 64-Bit RISC-V due to musl not using multilib but still uses t-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103889 --- Comment #11 from John Doe --- (In reply to Andrew Pinski from comment #10) > Well RISCV port is new enough that nobody has tested --disable-multilib and > put things in /lib/ really. Really there should be a > gcc/config/riscv/t-linux-musl which does no do any of the multilib stuff and > that should be used for musl only. Right, but I assume this problem should also exist on glibc systems which only have /lib/ instead of /lib64/ then. So apart from adding a gcc/config/riscv/t-linux-musl file in the future, the existing gcc/config/riscv/t-linux should also be fixed IMHO :)
[Bug target/103882] Register corruption in ASM only functions when optization is -O2/-Os/-O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103882 Jakub Jelinek changed: What|Removed |Added Resolution|WONTFIX |INVALID --- Comment #14 from Jakub Jelinek --- There is no special case for inline asm as the whole body of a function (except that __attribute__((naked)) functions need to contain just that), it acts like any other inline asm. And like for any other inline asm, the user needs to tell the compiler what side-effects it has. You can define the whole function in top-level inline asm or in *.s/*.S file, then the ABI applies for it. Or just use the syscall function, see syscall(2) man page. A hack that you want to propose (forcing noipa on functions that use inline asm) certainly won't be accepted, that would penalize millions of correctly written inline asm statements in real-world code. Even if it is limited only to functions that contain just a single inline asm statement and nothing else. Because even those are often desirable for inlining etc. IPA RA is a very useful optimization, not something terrible. And I've only spent last 23+ years working on GCC, so yes, I can't know the codebase enough.
[Bug go/103889] gccgo is unable to find its standard library by default on 64-Bit RISC-V due to musl not using multilib but still uses t-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103889 Andrew Pinski changed: What|Removed |Added Summary|gccgo is unable to find its |gccgo is unable to find its |standard library by default |standard library by default |on 64-Bit RISC-V|on 64-Bit RISC-V due to ||musl not using multilib but ||still uses t-linux Status|WAITING |NEW --- Comment #10 from Andrew Pinski --- Well RISCV port is new enough that nobody has tested --disable-multilib and put things in /lib/ really. Really there should be a gcc/config/riscv/t-linux-musl which does no do any of the multilib stuff and that should be used for musl only.
[Bug go/103889] gccgo is unable to find its standard library by default on 64-Bit RISC-V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103889 --- Comment #9 from John Doe --- (In reply to Andrew Pinski from comment #8) > Also there is much support we can do on modified sources really. Yes, I totally understand that I was just looking for some guidance on how to debug this further to come up with a fix. > But I didn't see any patches which would have modified this part. Right. I also don't think this is a problem introduced by the Alpine patchset. > I suspect there is some funny multilib/non-multilib going on with RISCV port > really. So the problem isn't that gcc/config/riscv/t-linux assumes lib32/lib64 directories to be present? I just find this surprising because other architecture configuration files I looked at include a specific check to ensure that these directories are present.
[Bug go/103889] gccgo is unable to find its standard library by default on 64-Bit RISC-V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103889 --- Comment #8 from Andrew Pinski --- Also there is much support we can do on modified sources really. But I didn't see any patches which would have modified this part. I suspect there is some funny multilib/non-multilib going on with RISCV port really. It might make sense to actually have some real non-multilib MUSL support so you don't need to do --disable-multilib which I think is recorded in general in PR 90077. Each musl target should have its own t-* file which unsets the MULTI* make variables.
[Bug go/103889] gccgo is unable to find its standard library by default on 64-Bit RISC-V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103889 --- Comment #7 from John Doe --- (In reply to Andrew Pinski from comment #5) > I should note that libgo is not able to compile for musl on the FSF GCC > until just recently, after r12-5979. This patch is included with the Alpine version of GCC, see https://git.alpinelinux.org/aports/tree/main/gcc/0040-stddef.h-add-support-for-musl-typedef-macro-guards.patch there are also additional patches which need to be merged upstream before one can use gcc-go on musl (see the Alpine Git for the complete list). As I said: Alpine is currently working on upstreaming these patches. For example, https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587142.html The problem described in this bug report should not be specific to any of those gccgo/libgo patches, it rather seems to be a problem with the default LIBRARY_PATH (see my previous comment). > Is there a way you can test GCC 12? I need to rebase the Alpine patchset for that GCC 12 then I assume, I could that do that if all else fails.
[Bug go/103889] gccgo is unable to find its standard library by default on 64-Bit RISC-V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103889 --- Comment #6 from John Doe --- (In reply to Andreas Schwab from comment #4) > LIBRARY_PATH=/usr/lib64/gcc/riscv64-suse-linux/11/:/usr/lib64/gcc/riscv64- > suse-linux/11/../../../../riscv64-suse-linux/lib/:/lib64/lp64d/:/usr/lib64/ > lp64d/:/lib/:/usr/lib/ Hm, Alpine doesn't have /usr/lib64 and /lib64. Alpine only uses /lib and /usr/lib. However, it seems that gcc/config/riscv/t-linux assumes that the lib64/lib32 directory is present: https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/riscv/t-linux;h=216d2776a183d13ade76642b73b9bf04b0c4694e;hb=HEAD this is contrary to configuration files for other architectures which explicitly check if the system has lib32/lib64, for example, compare this to the configuration file for x86_64: https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/i386/t-linux64;h=d288b0935220cc44998da1994a13aa2902db9509;hb=HEAD#l19 Might this be the root cause of this issue?
[Bug go/103889] gccgo is unable to find its standard library by default on 64-Bit RISC-V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103889 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2022-01-02 Status|UNCONFIRMED |WAITING Target||riscv64-alpine-linux-musl Ever confirmed|0 |1 --- Comment #5 from Andrew Pinski --- I should note that libgo is not able to compile for musl on the FSF GCC until just recently, after r12-5979. Also since this is alpine, this is with some patches, I don't know if those patches change RISCV usage though. Is there a way you can test GCC 12?
[Bug c/103881] Wconversion false positive when using |= and &= with two rvalues in binary op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103881 --- Comment #3 from thomas at habets dot se --- Interesting. So the difference between "x |= a & a" and "x |= f() & f()" is that the latter has passed a somewhat arbitrary level of complexity after which GCC is not able to prove that it's safe, and therefore warns as it being potentially losing precision? It's understandable, but unfortunate. It means that I have no hope of having real world programs be free of false positives for conversion warnings.
[Bug go/103889] gccgo is unable to find its standard library by default on 64-Bit RISC-V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103889 --- Comment #4 from Andreas Schwab --- $ gccgo hellogo.go -o hellogo -v Using built-in specs. COLLECT_GCC=gccgo COLLECT_LTO_WRAPPER=/usr/lib64/gcc/riscv64-suse-linux/11/lto-wrapper Target: riscv64-suse-linux Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,ada,go,d,jit --enable-host-shared --enable-checking=release --disable-werror --with-gxx-include-dir=/usr/include/c++/11 --enable-ssp --disable-libssp --disable-libvtv --enable-cet=auto --disable-libcc1 --enable-plugin --with-bugurl=https://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --with-slibdir=/lib64 --with-system-zlib --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-libphobos --enable-version-specific-runtime-libs --with-gcc-major-version-only --enable-linker-build-id --enable-linux-futex --program-suffix=-11 --without-system-libunwind --disable-multilib --enable-link-mutex --build=riscv64-suse-linux --host=riscv64-suse-linux Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 11.2.1 20211124 [revision 7510c23c1ec53aa4a62705f0384079661342ff7b] (SUSE Linux) COLLECT_GCC_OPTIONS='-g1' '-o' 'hellogo' '-v' '-shared-libgcc' '-march=rv64gc' '-mabi=lp64d' '-march=rv64imafdc' /usr/lib64/gcc/riscv64-suse-linux/11/go1 hellogo.go -quiet -dumpbase hellogo.go -dumpbase-ext .go -march=rv64gc -mabi=lp64d -march=rv64imafdc -g1 -version -L/usr/lib64/gcc/riscv64-suse-linux/11 -L/usr/lib64/gcc/riscv64-suse-linux/11/../../../../riscv64-suse-linux/lib -L/lib64/lp64d -L/usr/lib64/lp64d -o /tmp/cckzhr7m.s GNU Go (SUSE Linux) version 11.2.1 20211124 [revision 7510c23c1ec53aa4a62705f0384079661342ff7b] (riscv64-suse-linux) compiled by GNU C version 11.2.1 20211124 [revision 7510c23c1ec53aa4a62705f0384079661342ff7b], GMP version 6.2.1, MPFR version 4.1.0-p7, MPC version 1.2.1, isl version isl-0.24-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU Go (SUSE Linux) version 11.2.1 20211124 [revision 7510c23c1ec53aa4a62705f0384079661342ff7b] (riscv64-suse-linux) compiled by GNU C version 11.2.1 20211124 [revision 7510c23c1ec53aa4a62705f0384079661342ff7b], GMP version 6.2.1, MPFR version 4.1.0-p7, MPC version 1.2.1, isl version isl-0.24-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 COLLECT_GCC_OPTIONS='-g1' '-o' 'hellogo' '-v' '-shared-libgcc' '-march=rv64gc' '-mabi=lp64d' '-march=rv64imafdc' /usr/lib64/gcc/riscv64-suse-linux/11/../../../../riscv64-suse-linux/bin/as -v --gdwarf-5 --traditional-format -march=rv64gc -march=rv64imafdc -mabi=lp64d -o /tmp/cc1upFah.o /tmp/cckzhr7m.s GNU assembler version 2.37 (riscv64-suse-linux) using BFD version (GNU Binutils; openSUSE Tumbleweed) 2.37.2022-3 COMPILER_PATH=/usr/lib64/gcc/riscv64-suse-linux/11/:/usr/lib64/gcc/riscv64-suse-linux/11/:/usr/lib64/gcc/riscv64-suse-linux/:/usr/lib64/gcc/riscv64-suse-linux/11/:/usr/lib64/gcc/riscv64-suse-linux/:/usr/lib64/gcc/riscv64-suse-linux/11/../../../../riscv64-suse-linux/bin/ LIBRARY_PATH=/usr/lib64/gcc/riscv64-suse-linux/11/:/usr/lib64/gcc/riscv64-suse-linux/11/../../../../riscv64-suse-linux/lib/:/lib64/lp64d/:/usr/lib64/lp64d/:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-g1' '-o' 'hellogo' '-v' '-shared-libgcc' '-march=rv64gc' '-mabi=lp64d' '-march=rv64imafdc' '-dumpdir' 'hellogo.' /usr/lib64/gcc/riscv64-suse-linux/11/collect2 -plugin /usr/lib64/gcc/riscv64-suse-linux/11/liblto_plugin.so -plugin-opt=/usr/lib64/gcc/riscv64-suse-linux/11/lto-wrapper -plugin-opt=-fresolution=/tmp/ccu6Qjw9.res -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc --build-id --eh-frame-hdr -melf64lriscv -dynamic-linker /lib/ld-linux-riscv64-lp64d.so.1 -o hellogo /lib64/lp64d/crt1.o /usr/lib64/gcc/riscv64-suse-linux/11/crti.o /usr/lib64/gcc/riscv64-suse-linux/11/crtbegin.o -L/usr/lib64/gcc/riscv64-suse-linux/11 -L/usr/lib64/gcc/riscv64-suse-linux/11/../../../../riscv64-suse-linux/lib -L/lib64/lp64d -L/usr/lib64/lp64d /tmp/cc1upFah.o -lgobegin -lgo -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib64/gcc/riscv64-suse-linux/11/crtend.o /usr/lib64/gcc/riscv64-suse-linux/11/crtn.o COLLECT_GCC_OPTIONS='-g1' '-o' 'hellogo' '-v' '-shared-libgcc' '-march=rv64gc' '-mabi=lp64d' '-march=rv64imafdc' '-dumpdir' 'hellogo.'
[Bug c++/84920] Better handling of unmatched/ambiguous calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84920 Jonathan Wakely changed: What|Removed |Added Target Milestone|9.5 |---
[Bug go/103889] gccgo is unable to find its standard library by default on 64-Bit RISC-V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103889 --- Comment #3 from John Doe --- (In reply to Andreas Schwab from comment #2) > Probably specific to musl. Worksforme on openSUSE. Might be. Are you also compiling GCC with --disable-multilib on RV64? What's your output of `gcc -print-multi-os-directory` on RV64?
[Bug go/103889] gccgo is unable to find its standard library by default on 64-Bit RISC-V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103889 --- Comment #2 from Andreas Schwab --- Probably specific to musl. Worksforme on openSUSE.
[Bug c++/102398] thread_local works incorrectly outside of main file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102398
Pierre Vigier changed:
What|Removed |Added
CC||pierre.vigier at ymail dot com
--- Comment #1 from Pierre Vigier ---
Hello,
I am facing the same issue with the following program:
a.h
---
#pragma once
struct A
{
static thread_local int x;
};
a.cpp
---
#include "a.h"
thread_local int A::x = 0;
main.cpp
---
#include "a.h"
int main()
{
A::x = 1;
return 0;
}
When I compile with no optimization:
x86_64-w64-mingw32-g++ -c -a.cpp -o a.obj
x86_64-w64-mingw32-g++ -c main.cpp -o main.obj
x86_64-w64-mingw32-g++ main.obj a.obj -o test.exe
The program runs fine.
But, if I use optimizations:
x86_64-w64-mingw32-g++ -c -O1 a.cpp -o a.obj
x86_64-w64-mingw32-g++ -c -O1 main.cpp -o main.obj
x86_64-w64-mingw32-g++ -O1 main.obj a.obj -o test.exe
The program crashes when it tries to access the thread local variable.
x86_64-w64-mingw32-gcc -v:
Using built-in specs.
COLLECT_GCC=x86_64-w64-mingw32-gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-w64-mingw32/11.2.1/lto-wrapper
Target: x86_64-w64-mingw32
Configured with: ../configure --prefix=/usr --bindir=/usr/bin
--includedir=/usr/include --mandir=/usr/share/man --infodir=/usr/share/info
--datadir=/usr/share --build=x86_64-redhat-linux-gnu
--host=x86_64-redhat-linux-gnu --with-gnu-as --with-gnu-ld --verbose
--without-newlib --disable-multilib --disable-plugin --with-system-zlib
--disable-nls --without-included-gettext --disable-win32-registry
--enable-languages=c,c++,objc,obj-c++,fortran
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-threads=posix
--with-isl --enable-libgomp --target=x86_64-w64-mingw32
--with-sysroot=/usr/x86_64-w64-mingw32/sys-root
--with-gxx-include-dir=/usr/x86_64-w64-mingw32/sys-root/mingw/include/c++
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.2.1 20210728 (Fedora MinGW 11.2.1-3.fc35) (GCC)
The same program was working fine on 10.3.1.
[Bug c++/87464] Gcc reports hard error instead of SFINAE out the related method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87464
Jonathan Wakely changed:
What|Removed |Added
Severity|normal |enhancement
Last reconfirmed||2022-01-02
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #5 from Jonathan Wakely ---
Reduced:
template struct enable_if { };
template struct enable_if { using type = T; };
template struct is_const { static constexpr bool value = false; };
template struct is_const { static constexpr bool value =
true; };
template
struct SfinaeTest
{
SfinaeTest() = default;
SfinaeTest(const SfinaeTest&) = default;
template::value, int>::type =
0>
SfinaeTest(const SfinaeTest& other)
{ }
};
int main ()
{
SfinaeTest p;
SfinaeTest c;
SfinaeTest b_c( c); // expected error. Extra gcc-error: see L:13
}
GCC prints two errors, one is the substitution failure error.
Clang only prints one, for the invalid constructor call for b_c. Clang has a
special case for enable_if constraints, where it prints the boolean condition:
:14:4: note: candidate template ignored: requirement '!is_const::value' was not satisfied [with TT = const int]
If we rename the enable_if template, Clang still doesn't show an error, but is
closer to GCC's wording:
template struct require { };
template struct require { using type = T; };
template struct is_const { static constexpr bool value = false; };
template struct is_const { static constexpr bool value =
true; };
template
struct SfinaeTest
{
SfinaeTest() = default;
SfinaeTest(const SfinaeTest&) = default;
template::value, int>::type =
0>
SfinaeTest(const SfinaeTest& other)
{ }
};
int main ()
{
SfinaeTest p;
SfinaeTest c;
SfinaeTest b_c( c); // expected error. Extra gcc-error: see L:15
}
Now clang's note for the template constructor says:
:14:4: note: candidate template ignored: substitution failure [with TT
= const int]: no type named 'type' in 'require'
So the only real difference is that gcc prints the cause of the substitution
failure as an error.
[Bug go/103889] gccgo is unable to find its standard library by default on 64-Bit RISC-V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103889
--- Comment #1 from John Doe ---
[Hm, somehow bugzilla didn't add the description? Adding it again here.]
When compiling GCC with --disable-multilib on 64-Bit RISC-V (RV64), the gccgo
frontend does not seem to be able to find it's standard library:
$ gccgo -v -o hello_world hello_world.go
Using built-in specs.
COLLECT_GCC=/usr/bin/gccgo
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/riscv64-alpine-linux-musl/11.2.1/lto-wrapper
Target: riscv64-alpine-linux-musl
Configured with:
/home/buildozer/aports/main/gcc/src/gcc-11.2.1_git20211128/configure
--prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info
--build=riscv64-alpine-linux-musl --host=riscv64-alpine-linux-musl
--target=riscv64-alpine-linux-musl --with-pkgversion='Alpine
11.2.1_git20211128' --enable-checking=release --disable-fixed-point
--disable-libstdcxx-pch --disable-multilib --disable-nls --disable-werror
--disable-symvers --enable-__cxa_atexit --enable-default-pie
--enable-default-ssp --enable-cloog-backend
--enable-languages=c,c++,objc,go,fortran,jit --with-arch=rv64gc
--with-abi=lp64d --enable-autolink-libatomic --disable-libquadmath
--disable-libssp --disable-libmpx --disable-libmudflap --disable-libsanitizer
--enable-shared --enable-threads --enable-tls --disable-libitm
--enable-host-shared --with-system-zlib --with-linker-hash-style=gnu
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.2.1 20211128 (Alpine 11.2.1_git20211128)
COLLECT_GCC_OPTIONS='-g1' '-v' '-o' 'hello_world' '-shared-libgcc'
'-march=rv64gc' '-mabi=lp64d' '-march=rv64imafdc'
/usr/libexec/gcc/riscv64-alpine-linux-musl/11.2.1/go1 hello_world.go
-quiet -dumpbase hello_world.go -dumpbase-ext .go -march=rv64gc -mabi=lp64d
-march=rv64imafdc -g1 -version -L/usr/lib/gcc/riscv64-alpine-linux-musl/11.2.1
-L/usr/lib/gcc/riscv64-alpine-linux-musl/11.2.1/../../../../riscv64-alpine-linux-musl/lib
-o /tmp/ccLBoAel.s
GNU Go (Alpine 11.2.1_git20211128) version 11.2.1 20211128
(riscv64-alpine-linux-musl)
compiled by GNU C version 11.2.1 20211128, GMP version 6.2.1,
MPFR version 4.1.0, MPC version 1.2.1, isl version isl-0.22-GMP
GGC heuristics: --param ggc-min-expand=100 --param
ggc-min-heapsize=131072
GNU Go (Alpine 11.2.1_git20211128) version 11.2.1 20211128
(riscv64-alpine-linux-musl)
compiled by GNU C version 11.2.1 20211128, GMP version 6.2.1,
MPFR version 4.1.0, MPC version 1.2.1, isl version isl-0.22-GMP
GGC heuristics: --param ggc-min-expand=100 --param
ggc-min-heapsize=131072
hello_world.go:3:11: error: import file 'fmt' not found
3 | import "fmt"
| ^
hello_world.go:6:9: error: reference to undefined name 'fmt'
6 | fmt.Println("Hello, World!")
| ^
However, compiling on x86_64 works as expected:
$ gccgo -v -o hello_world hello_world.go
Using built-in specs.
COLLECT_GCC=gccgo
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-alpine-linux-musl/11.2.1/lto-wrapper
Target: x86_64-alpine-linux-musl
Configured with:
/home/buildozer/aports/main/gcc/src/gcc-11.2.1_git20211128/configure
--prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info
--build=x86_64-alpine-linux-musl --host=x86_64-alpine-linux-musl
--target=x86_64-alpine-linux-musl --with-pkgversion='Alpine 11.2.1_git20211128'
--enable-checking=release --disable-fixed-point --disable-libstdcxx-pch
--disable-multilib --disable-nls --disable-werror --disable-symvers
--enable-__cxa_atexit --enable-default-pie --enable-default-ssp
--enable-cloog-backend --enable-languages=c,c++,d,objc,go,fortran,ada,jit
--disable-libssp --disable-libmpx --disable-libmudflap --disable-libsanitizer
--enable-shared --enable-threads --enable-tls --enable-host-shared
--with-system-zlib --with-linker-hash-style=gnu
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.2.1 20211128 (Alpine 11.2.1_git20211128)
COLLECT_GCC_OPTIONS='-g1' '-v' '-o' 'hello_world' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
/usr/libexec/gcc/x86_64-alpine-linux-musl/11.2.1/go1 hello_world.go
-quiet -dumpbase hello_world.go -dumpbase-ext .go -mtune=generic -march=x86-64
-g1 -version -L/usr/lib/gcc/x86_64-alpine-linux-musl/11.2.1
-L/usr/lib/gcc/x86_64-alpine-linux-musl/11.2.1/../../../../x86_64-alpine-linux-musl/lib/../lib
-L/usr/lib/gcc/x86_64-alpine-linux-musl/11.2.1/../../../../lib -L/lib/../lib
-L/usr/lib/../lib
-L/usr/lib/gcc/x86_64-alpine-linux-musl/11.2.1/../../../../x86_64-alpine-linux-musl/lib
-L/usr/lib/gcc/x86_64-alpine-linux-musl/11.2.1/../../.. -o /tmp/ccjMeGOf.s
GNU Go (Alpine 11.2.1_git20211128) version 11.2.1 20211128
(x86_64-alpine-linux-musl)
compiled by GNU C version 11.2.1 20211128, GMP version 6.2.1,
[Bug go/103889] New: gccgo is unable to find its standard library by default on 64-Bit RISC-V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103889 Bug ID: 103889 Summary: gccgo is unable to find its standard library by default on 64-Bit RISC-V Product: gcc Version: 11.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: bau2wux4sh at pkv73 dot anonbox.net CC: cmang at google dot com Target Milestone: ---
