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: nor
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 libr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87464
Jonathan Wakely changed:
What|Removed |Added
Severity|normal |enhancement
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102398
Pierre Vigier changed:
What|Removed |Added
CC||pierre.vigier at ymail dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103889
--- Comment #2 from Andreas Schwab ---
Probably specific to musl. Worksforme on openSUSE.
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84920
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|9.5 |---
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 --prefi
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,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103889
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2022-01-02
Status|UNCONFIRM
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/:/li
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,
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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103882
Jakub Jelinek changed:
What|Removed |Added
Resolution|WONTFIX |INVALID
--- Comment #14 from Jakub Jeli
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 w
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-lin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103882
Jose Silva changed:
What|Removed |Added
Resolution|INVALID |WORKSFORME
--- Comment #15 from Jose Silva
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103882
Andreas Schwab changed:
What|Removed |Added
Resolution|WORKSFORME |INVALID
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 th
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 trail
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
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
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 unversi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103890
--- Comment #2 from dave.anglin at bell dot net ---
Is that what we want?
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 t
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 J
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
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
--
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
Stat
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
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&action=edit
Improved patch
The previous patch was too strict. The attached version does a much better
job, but
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33193
Andrew Pinski changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103893
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92453
Andrew Pinski changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #5 f
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.
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)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103370
Richard Biener changed:
What|Removed |Added
Priority|P3 |P4
--- Comment #5 from Richard Biener
41 matches
Mail list logo
