[Bug bootstrap/54179] please split insn-emit.c !
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179 --- Comment #41 from Brjd --- (In reply to Sam James from comment #40) > That came up at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600#c29. IMHO keeping the build at RAM<=1GB would be a good benchmark. Keeping these million-line files might be wrong.I succeed at building it only with -j1. If j>1, the build simply errors. I read comments that j>1 builds might be bad to the drives too. If you know other possible ways to reduce RAM, please tell.
[Bug bootstrap/54179] please split insn-emit.c !
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179 --- Comment #39 from Brjd --- Let me share what I notice in 14.1. Significant improvement in insn-emit.cc and gimple-match.cc. This is good news. Insn-recog.cc is much the same and needs ~ 1.6 GiB RAM. Yet, another possible issue in the future might be gcc/genautomata.cc or insn-conditions.md > tmp-automata.cc where RAM reaches 1.8 GiB. The rest of the build is pretty nice at just 500-600 MiB.
[Bug go/90685] failure of go in gcc-9.1.0 to build in i686-pc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90685 Brjd changed: What|Removed |Added CC||brjd_epdjq36 at kygur dot com --- Comment #5 from Brjd --- I got the same error on x86_64-pc-linux-gnu at libgo/libgotool.a : go1: error: ‘-fsplit-stack’ currently only supported on GNU/Linux go1: error: ‘-fsplit-stack’ is not supported by this compiler configuration I disable the build since it stops at gotools. It is not quite clear if it is supported in all glibc versions, whether -fsplit-stack is needed for the gccgo build or not, and I see that it is disabled for non-glibcs in the gnu.h header because of -fsplit-stack issues which is correct of course. I guess these problems may be serious, e.g. possible memory corruption, segfaults etc. But I was unable to find reliable information in the gcc docs. I would suggest if the checks of compatibility are made at the very beginning when the build is configured initially, so that users know if the go build is supported on their system or not.
[Bug bootstrap/54179] please split insn-emit.c !
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179 Brjd changed: What|Removed |Added CC||brjd_epdjq36 at kygur dot com --- Comment #38 from Brjd --- It is good for 14 but you agree that these files become really huge in size and it is very difficult to open them. 5-10 MB is crazy:)
[Bug bootstrap/54179] please split insn-emit.c !
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54179 --- Comment #36 from Brjd --- I got memory troubles with insn-recog.cc and gimple-match.cc too. Please correct them for gcc 10-13 in the their last .5 releases, so that we can bootstrap.
[Bug target/111570] -march=generic prints error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111570 --- Comment #2 from Brjd --- Thank you and I also read this guide. My point is that the generic arch might be possible in theory. If the gcc builds for the oldest CPU with x86_64, is it possible that code will run on all modern CPU since their subset includes also that of their predecessor. How about making it default to that generic or baseline build for that limited CPU? If I could ask you also more questions, let me ask you about this problem. The guide doesn't mention anything about the specific arch. If -march=cpu what is better -mtune=cpu where cpu is the same as in arch or -mtune=generic so that the code tunes to all CPU kinds of this family.If the tune is empty, is it default generic or native and the arch is not clear either. One question more, I am not able to find a guide about the gcc build and no information whether the gcc may be built in targets like LLVM and clang. For example, is it possible to build first only the LLVM, then stop and resume with clang etc. or first, gcc's only c modiule and its submodules, then stop and resume with its g++ module and submodules, next with libgcc, libstdc++ etc.? It would be great, especially for long bootstraps and stage 2, but I find only make all-gcc, target-libgcc which however build almost all of the compiler.
[Bug demangler/111570] New: -march=generic prints error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111570 Bug ID: 111570 Summary: -march=generic prints error Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: demangler Assignee: unassigned at gcc dot gnu.org Reporter: brjd_epdjq36 at kygur dot com Target Milestone: --- When compiling, it prints out an error: 'generic' CPU can be used only for '-mtune=' switch. However, the compiler help prints out: Known valid arguments for -march= option: i386 i486 i586 pentium ... generic native Not sure if this is a bug or it means something else.
[Bug driver/110408] [13/14 Regression] gcc 13 crashes with %rename in specs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110408 Brjd changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Brjd --- Please ignore it. I test it more and find out that it is my misunderstanding that I can make it the default specs if I use the %rename option. However, the compiler is not designed in this way. Please tell if there are other options. AFAIK currently there are two options to change the specs behavior. First, I can override only a part of the specs file with the %rename option. The shortage here is that it is not the default and I should invoke it manually every time by the -specs=/path-to-my-specs-file. The second way is a rebuild of the GCC or changes in the whole specs file. This is the way I can set the default without invoking in the command line -specs=/path-to-my-specs-file. I do the first one and that causes the error since I use the GCC without -specs. The compiler simply replaces the whole specs with my custom overriding specs and fails.
[Bug driver/110408] gcc 13 crashes with %rename in specs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110408 --- Comment #1 from Brjd --- Test with specs file %rename lib old_lib *lib: --start-group -lgcc -lc --end-group %(old_lib) and hello.cpp g++ hello.cpp -specs=/path-to-specs g++-13: fatal error: specs file malformed after 36 characters compilation terminated. g++12 no error g++-4 no error.
[Bug driver/110408] New: gcc 13 crashes with %rename in specs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110408 Bug ID: 110408 Summary: gcc 13 crashes with %rename in specs Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: brjd_epdjq36 at kygur dot com Target Milestone: --- According to https://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html if I apply this instruction to redefine only a part of the specs file: %rename lib old_lib *lib: --start-group -lgcc -lc -leval1 --end-group %(old_lib) ,it is not necessary to change the whole specs file. Still, in gcc 13 it crashes and returns this error: g++-13: fatal error: specs file malformed after 35 characters compilation terminated. 35 characters is the position after the last character in the old_lib string. I test it with an older compiler gcc 4 and it is wonderful, no error. I suppose that this manual is not updated to work in gcc 13 and there are changes in the syntax.
[Bug target/107551] __builtin_cpu_supports returns a negative integer for "x86-64"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107551 --- Comment #22 from Brjd --- Maybe not changing now is the correct way for now since I may change it blindly not knowing completely what I am doing. Let the developers correct it and will include it in next releases. The compiler is excellent and at least it may build older sourced while the newer ones will be waiting for revisions.
[Bug target/107551] __builtin_cpu_supports returns a negative integer for "x86-64"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107551 --- Comment #21 from Brjd --- Created attachment 54012 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54012=edit i386-builtins-orig-12.2.0.cc
[Bug target/107551] __builtin_cpu_supports returns a negative integer for "x86-64"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107551 --- Comment #20 from Brjd --- The test gcc/testsuite/gcc.target/i386/builtin_target.c is patched. But gcc/config/i386/i386-builtins.cc looks like it is from another version. I attached it as i386-builtins-orig-12.2.0.cc to compare them and asking if you could correct it with your patch.
[Bug target/107551] __builtin_cpu_supports returns a negative integer for "x86-64"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107551 --- Comment #18 from Brjd --- Then rebuild is necessary and impending gcc/config/i386/i386-builtins.cc for the compiler ? gcc/testsuite/gcc.target/i386/builtin_target.c for the test ? gcc/doc/extend.texi is not needed since I am not building docs?
[Bug target/107551] __builtin_cpu_supports returns a negative integer for "x86-64"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107551 --- Comment #16 from Brjd --- I mean that as I can see, your patch makes changes only to the test and not to the compiler ? If it does not, and it changes the compiler source also, then I have to rebuild the whole compiler to test it again. But If only the test is misconfigured, forget about it, and the compiler works great, then I will use it for the next build. Thank you a lot.
[Bug target/107551] __builtin_cpu_supports returns a negative integer for "x86-64"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107551 --- Comment #14 from Brjd --- Maybe it is better if we test it in the next release 12.3 or 13.1 since now the test will be correct, ok, but when building source with the compiler, it will not make any difference and make no problems at all?
[Bug target/107551] __builtin_cpu_supports returns a negative integer for "x86-64"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107551 --- Comment #13 from Brjd --- I am not sure how I can run only this patched test against the newly built gcc. Would you post instruction how it is done. I know it can run in the build tree when building gcc itself, but never test it against the testsuite when ready. I unpack the source, patch the test and then what next?
[Bug testsuite/107553] nested-func-1.m fails due to linker warning about executable stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107553 --- Comment #5 from Brjd --- Thank you. Best regards.
[Bug target/107551] __builtin_cpu_supports returns a negative integer for "x86-64"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107551 --- Comment #11 from Brjd --- Thank you. Best regards.
[Bug target/107551] g++ 12.2 test fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107551 --- Comment #8 from Brjd --- __get_cpuid(0): eax=0xa, ebx=0x756e6547, ecx=0x6c65746e, edx=0x49656e69 __get_cpuid(1): eax=0x106ca, ebx=0x20800, ecx=0x40e39d, edx=0xbfe9fbff
[Bug target/107551] g++ 12.2 test fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107551
--- Comment #6 from Brjd ---
glibc 2.19 on utopic 14.10
You may have already noticed it but just to make sure it may be helpful too,
this is where it crashes in the main for all 4 cases:
gcc/testsuite/g++.target/i386/mv30.C:45:
int main(): Assertion `val == 1' failed.
FAIL: g++.target/i386/mv30.C -std=gnu++20 execution test
else if (__builtin_cpu_supports ("x86-64"))
assert (val == 1);
[Bug objc/107553] objc 12.2 test fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107553 --- Comment #3 from Brjd --- Created attachment 53845 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53845=edit linker issue I think you are right. It is a linker issue and has nothing to do with gcc.
[Bug target/107551] g++ 12.2 test fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107551 --- Comment #4 from Brjd --- I understand that this old cpu is not supported.
[Bug target/107551] g++ 12.2 test fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107551 --- Comment #3 from Brjd --- Created attachment 53844 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53844=edit cpuinfo
[Bug objc/107553] 12.2 test fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107553 --- Comment #1 from Brjd --- I checked it and no failure reported by the same test in gcc 11.2.0.
[Bug c++/107551] gcc 12.2 test fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107551 --- Comment #1 from Brjd --- Maybe the error is since it is a new test appearing firstly in 12.2.0.
[Bug objc/107553] New: 12.2 test fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107553 Bug ID: 107553 Summary: 12.2 test fails Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: objc Assignee: unassigned at gcc dot gnu.org Reporter: brjd_epdjq36 at kygur dot com Target Milestone: --- FAIL: objc/execute/nested-func-1.m This test reports FAIL on Ubuntu x86_64 linux gnu platform gcc-12.2.0/gcc/testsuite/objc/execute/execute.exp ... FAIL: objc/execute/nested-func-1.m compilation, -O0 -fgnu-runtime
[Bug c++/107551] New: gcc 12.2 test fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107551 Bug ID: 107551 Summary: gcc 12.2 test fails Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: brjd_epdjq36 at kygur dot com Target Milestone: --- FAIL: g++.target/i386/mv30.C This test reports fail on Ubuntu x86_64 linux gnu platform. FAIL: g++.target/i386/mv30.C -std=gnu++98 execution test FAIL: g++.target/i386/mv30.C -std=gnu++14 execution test FAIL: g++.target/i386/mv30.C -std=gnu++17 execution test FAIL: g++.target/i386/mv30.C -std=gnu++20 execution test
