Severity: normal
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: gcc at octaforge dot org
CC: cmang at google dot com
Target Milestone: ---
Created attachment 48283
--> https://gcc.gnu.org/bugzilla/attachment.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94611
--- Comment #2 from Daniel Kolesa ---
It reproduces on any GCC 9.x series, and when building *any* version of the
official Go compiler (tested 1.12-1.14), and many other projects (e.g. gitea).
I'm not sure if it reproduces on x86_64, as I don't h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94611
--- Comment #3 from Daniel Kolesa ---
The steps I took to reproduce the problem:
1) Grab a Go source release
2) Install gccgo including the 'go' command
3) Then do something like:
cd go-1.x
export GOROOT_BOOTSTRAP=/usr/lib/go/9.3.0
export GOROO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94611
--- Comment #4 from Daniel Kolesa ---
Oh, also, sorry, the process that *actually* gets stuck is go1, not gc1, that
was a typo.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94611
Daniel Kolesa changed:
What|Removed |Added
Target|powerpc64le-linux-gnu |
--- Comment #5 from Daniel Kolesa ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94611
--- Comment #6 from Daniel Kolesa ---
Another thing of note, the gccgo command that hangs is the same on both x86_64
and ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94611
Daniel Kolesa changed:
What|Removed |Added
Target||ppc64le-linux-gnu
--- Comment #7 from Da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94611
--- Comment #9 from Daniel Kolesa ---
it finishes with -fno-var-tracking, though it does take up a few gigs of memory
and takes a while, this is consistent with the default behavior on x86_64 where
it does the same thing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91920
Daniel Kolesa changed:
What|Removed |Added
CC||gcc at octaforge dot org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91920
--- Comment #4 from Daniel Kolesa ---
Yeah, the testcase doesn't really matter, AFAIK the purpose here was just to
provide something that fails in the same way as darktable (which is the project
where this bug shows up).
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc at octaforge dot org
Target Milestone: ---
Since 9.x, using the `-mcall-aixdesc` makes gcc undefine `__linux__`. This
breaks compilation of the Linux kernel as it relies on the older
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91135
--- Comment #3 from Daniel Kolesa ---
Yeah, I noticed as much while investigating this. Question is, should gcc
define it? Is it the kernel that is in the wrong here as I originally thought?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91135
--- Comment #5 from Daniel Kolesa ---
I don't know 100% *what* the kernel uses it for, I just know it does. If I
remove it, linking vmlinux fails (with thousands of undefined references) so it
seems to require that specific ABI for whatever reaso
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91135
--- Comment #7 from Daniel Kolesa ---
The actual reason why the linkage fails without the flag, for anyone interested
https://bugzilla.kernel.org/show_bug.cgi?id=204125#c6
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc at octaforge dot org
Target Milestone: ---
Example code:
```
#include
#include
#include
int main(void) {
std::smatch matches;
auto re = std::regex(R"(a++)&
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc at octaforge dot org
Target Milestone: ---
Attempting to bootstrap GCC on Chimera Linux (https://chimera-linux.org) which
uses LLVM/Clang as its
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113174
--- Comment #3 from Daniel Kolesa ---
this is the preprocessed source: https://0x0.st/HEt7.ii
It's generated with the following command line:
/builddir/gcc-13.2.1_git20231014/build/./prev-gcc/xg++
-B/builddir/gcc-13.2.1_git20231014/build/./prev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113174
--- Comment #4 from Daniel Kolesa ---
I don't think builds with completely unchanged source are going to work, as the
compiler won't even reach this point then (at very least several of them are
necessary for stage 1 to build at all)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113174
--- Comment #6 from Daniel Kolesa ---
If it helps, I have reduced the patches to just the two that strictly necessary
for stage 1 build (I can't get rid of those, sorry, that would be asking for
the impossible), which are:
https://github.com/ch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113174
--- Comment #7 from Daniel Kolesa ---
I just tested this on big-endian ppc64 targeting power4/ppc970; I was able to
successfully bootstrap the compiler. It seems this is really specific to LE
after all (which makes sense I suppose, considering t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113174
--- Comment #8 from Daniel Kolesa ---
I tried an experiment: I canceled the build after initial generation of
insn-recog.cc and patched the offending part with logic from a stage-2
insn-recog.cc I managed to previously capture:
```
--- insn-rec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113174
--- Comment #9 from q66 ---
tested with clang 18.x build and tip-of-tree 14.1 branch, still applies
22 matches
Mail list logo
