[Bug web/115183] New: GCCGO appears twice at https://gcc.gnu.org/onlinedocs/14.1.0/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115183 Bug ID: 115183 Summary: GCCGO appears twice at https://gcc.gnu.org/onlinedocs/14.1.0/ Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: web Assignee: unassigned at gcc dot gnu.org Reporter: dilyan.palauzov at aegee dot org Target Milestone: --- https://gcc.gnu.org/onlinedocs/14.1.0/ spells twice “GCCGO 14.1 Manual (also in PDF or PostScript or an HTML tarball)”. Likewise at https://gcc.gnu.org/onlinedocs/13.1.0/, https://gcc.gnu.org/onlinedocs/13.2.0/ and https://gcc.gnu.org/onlinedocs/13.3.0/. https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Modules.html contains “they provideS a modular compilation system”.
[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106472 --- Comment #40 from Дилян Палаузов --- Makefile.in contains now: @if gcc-bootstrap @unless target-libbacktrace-bootstrap all-target-libgo: maybe-all-target-libbacktrace @endunless target-libbacktrace-bootstrap @endif gcc-bootstrap @unless gcc-bootstrap all-target-libgo: maybe-all-target-libbacktrace @endunless gcc-bootstrap Isn’t this the same as just: all-target-libgo: maybe-all-target-libbacktrace Or when is gcc-bootstrap true and target-libbacktrace-bootstrap false?
[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106472 --- Comment #36 from Дилян Палаузов --- > maybe this ought to be a `depend=` entry in Makefile.def instead? My understanding is that depend= only has effect for bootstrapped targets, and there is no boot_language=yes in gcc/go/config-lang.in.
[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106472 --- Comment #34 from Дилян Палаузов --- Created attachment 57662 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57662&action=edit Proposed patch This fixes the problem. I do not understand the build system to say, that this is the best approach, so if there are questions I might or might not be able to answer them. I also do not know, if 2×`maybe-` is necessary.
[Bug web/114223] New: Utilize filtering for git://gcc.gnu.org/git/gcc.git
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114223 Bug ID: 114223 Summary: Utilize filtering for git://gcc.gnu.org/git/gcc.git Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: web Assignee: unassigned at gcc dot gnu.org Reporter: dilyan.palauzov at aegee dot org Target Milestone: --- I want to create a treeless-copy of the git://gcc.gnu.org/git/gcc.git . https://github.blog/2020-12-21-get-up-to-speed-with-partial-clone-and-shallow-clone/ explains what treeless is. > $ git clone --filter=tree:0 git://gcc.gnu.org/git/gcc.git > Cloning into 'gcc'... > warning: filtering not recognized by server, ignoring … When I utilize https://github.com/HaleTom/git-bloblessify/ to strip the unneeded git blobs, eventually it reports … Fetching tags and HEAD's trees... warning: filtering not recognized by server, ignoring remote: Enumerating objects: 2342589, done. remote: Counting objects: 100% (316017/316017), done. remote: Compressing objects: 100% (20610/20610), done. remote: Total 2342589 (delta 307150), reused 295435 (delta 295402), pack-reused 2026572 Receiving objects: 100% (2342589/2342589), 929.71 MiB | 6.40 MiB/s, done. Resolving deltas: 100% (1915402/1915402), done. warning: filtering not recognized by server, ignoring remote: Enumerating objects: 2622955, done. remote: Counting objects: 100% (301209/301209), done. remote: Compressing objects: 100% (21051/21051), done. remote: Total 2622955 (delta 293664), reused 280316 (delta 280149), pack-reused 2321746 Receiving objects: 100% (2622955/2622955), 1.01 GiB | 5.50 MiB/s, done. Resolving deltas: 100% (2148507/2148507), done. fatal: bad object 31ff5e249df46ff122b115c86af04022307fafa4 error: git://gcc.gnu.org/git/gcc.git did not send all necessary objects git-bloblessify: clean-up: previous git objects have been restored git-bloblessify: check remote origin config remains correct remote.origin.url=git://gcc.gnu.org/git/gcc.git remote.origin.fetch=+refs/heads/*:refs/remotes/origin/* remote.origin.promisor=true remote.origin.partialclonefilter=blob:none git-bloblessify: exiting with error code: 1 I guess the fatal: bad object 31ff5e249df46ff122b115c86af04022307fafa4 error: git://gcc.gnu.org/git/gcc.git did not send all necessary objects means some network error and retrying might help. However retrying takes very long, and might also not work, because of some other network error. Please utilize server-side filtering on git://gcc.gnu.org/git/gcc.git , so that > $ git clone --filter=tree:0 git://gcc.gnu.org/git/gcc.git does not print > warning: filtering not recognized by server, ignoring
[Bug c++/114220] False positive warning: possibly dangling reference to a temporary [-Wdangling-reference]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114220
--- Comment #3 from Дилян Палаузов ---
> The warning is designed this way explictly because you are returning a
> reference and taking a reference as an argument and in the case of b2, the
> tempory is `std::string("u")` .
> In GCC 14+ (since r14-9263-gc7607c4cf18986), you can add [[gnu::no_dangling]]
> to the z2 function definition to mark it as not returning a dangling
> reference (from the arguments). and the warning goes away.
If the declaration and definitions are in different files, do I have to add
[[gnu::no_dangling]] only to the function declaration ?
That said, is the warning triggered only based on the function declaration
(accepting as parameter a reference to temporary and returning a reference),
when on the function invocation the parameter is indeed a reference to a
temporary?
[Bug c++/114220] False positive warning: possibly dangling reference to a temporary [-Wdangling-reference]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114220 --- Comment #2 from Дилян Палаузов --- Is my reading correct, that the warning is triggered, when a function receives as parameter a reference to a temporary and returns a reference? If this is the only criterion, then it is a wrong assumption, that both references are somehow related.
[Bug c++/114220] New: False positive warning: possibly dangling reference to a temporary [-Wdangling-reference]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114220
Bug ID: 114220
Summary: False positive warning: possibly dangling reference to
a temporary [-Wdangling-reference]
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dilyan.palauzov at aegee dot org
Target Milestone: ---
Created attachment 57598
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57598&action=edit
The inlined programme
This code
#include
#include
static const std::unordered_map hashTable1 = {{2, "u"}};
static const std::unordered_map hashTable2 = {{"u",
"u"}};
const std::string& z1(int m);
const std::string& z1(int m) { return hashTable1.at(m); }
const std::string& z2(const std::string& m);
const std::string& z2(const std::string& m) { return hashTable2.at(m); }
const std::string& z3();
const std::string& z3() { return hashTable2.at("u"); }
int main() {
const std::string& b1 { z1(2) };
const std::string& b2 { z2("u") };
const std::string& b3 { z3() };
const std::string& f1 = hashTable1.at(2);
const std::string& f2 = hashTable2.at("u");
printf("%s %s %s %s %s\n", b1.c_str(), b2.c_str(), f1.c_str(), f2.c_str(),
b3.c_str());
}
produces with g++ (GCC) 13.2.1 20240302:
$ g++ -Wall -Wextra -o a a.cpp
a.c: In function ‘int main()’:
a.c:16:22: warning: possibly dangling reference to a temporary
[-Wdangling-reference]
16 | const std::string& b2 { z2("u") };
| ^~
a.c:16:29: note: the temporary was destroyed at the end of the full expression
‘z2(std::__cxx11::basic_string(((const char*)"u"),
std::allocator()))’
16 | const std::string& b2 { z2("u") };
| ~~^
So std::string as first template parameter is problematic (b2), when only the
second template parameter is relevant (b3), but int as first template parameter
is fine (b1).
I think this is a bug.
[Bug target/113679] long long minus double with gcc -m32 produces different results than other compilers or gcc -m64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113679 --- Comment #13 from Дилян Палаузов --- For clang being buggy from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113679#c11 I filled https://github.com/llvm/llvm-project/issues/81358 .
[Bug target/113679] long long minus double with gcc -m32 produces different results than other compilers or gcc -m64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113679
--- Comment #8 from Дилян Палаузов ---
-fexcess-precision=standard does not ensure consistent behaviour between gcc
13.2.1 20231205 (Red Hat 13.2.1-6) and clang 17.0.5. -msse2 -mfpmath=sse does
for diff.c:
#include
#include
int main(void) {
long long l = 9223372036854775806;
double d = 9223372036854775808.0;
printf("%f\n", (double)l - d);
printf("%i\n", pow(3.3, 4.4) == 191.18831051580915);
return 0;
}
$ gcc -lm -fexcess-precision=standard -m32 -o diff diff.c && ./diff
0.00
0
$ clang -lm -fexcess-precision=standard -m32 -o diff diff.c && ./diff
0.00
1
$ gcc -lm -fexcess-precision=standard -m64 -o diff diff.c && ./diff
0.00
1
$ clang -lm -fexcess-precision=standard -m64 -o diff diff.c && ./diff
0.00
1
$ gcc -lm -fexcess-precision=fast -m32 -o diff diff.c && ./diff
-2.00
1
$ clang -lm -fexcess-precision=fast -m32 -o diff diff.c && ./diff
0.00
1
$ gcc -lm -fexcess-precision=fast -m64 -o diff diff.c && ./diff
0.00
1
$ clang -lm -fexcess-precision=fast -m64 -o diff diff.c && ./diff
0.00
1
$ gcc -lm -msse2 -mfpmath=sse -m32 -o diff diff.c && ./diff
0.00
1
$ clang -lm -msse2 -mfpmath=sse -m32 -o diff diff.c && ./diff
0.00
1
$ gcc -lm -msse2 -mfpmath=sse -m64 -o diff diff.c && ./diff
0.00
1
$ clang -lm -msse2 -mfpmath=sse -m64 -o diff diff.c && ./diff
0.00
1
cl.exe also prints 0.00 and 1
[Bug target/113679] long long minus double with gcc -m32 produces different results than other compilers or gcc -m64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113679
--- Comment #5 from Дилян Палаузов ---
gcc -m64 -fexcess-precision=fast -o diff diff.c && ./diff
0.00
gcc -m32 -fexcess-precision=fast -o diff diff.c && ./diff
-2.00
clang -m32 -fexcess-precision=fast -o diff diff.c && ./diff
0.00
clang -m64 -fexcess-precision=fast -o diff diff.c && ./diff
0.00
gcc -m64 -fexcess-precision=standard -o diff diff.c && ./diff
0.00
gcc -m32 -fexcess-precision=standard -o diff diff.c && ./diff
0.00
clang -m32 -fexcess-precision=standard -o diff diff.c && ./diff
0.00
clang -m64 -fexcess-precision=standard -o diff diff.c && ./diff
0.00
If this excess precision has justification, why are the results different for
32 and 64bit code? With
printf("%f\n", (double)l - d);
printf("%f\n", (double)(l - d));
there is indeed a difference:
$ gcc -m32 -fexcess-precision=standard -o diff diff.c && ./diff
0.00
-2.00
[Bug target/113679] long long minus double with gcc -m32 produces different results than other compilers or gcc -m64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113679 --- Comment #2 from Дилян Палаузов --- This happens only without optimizations: $ gcc -O0 -m32 -o diff diff.c && ./diff -2.00 $ gcc -O1 -m32 -o diff diff.c && ./diff 0.00 $ gcc -O2 -m32 -o diff diff.c && ./diff 0.00 $ gcc -O3 -m32 -o diff diff.c && ./diff 0.00
[Bug c/113679] New: long long minus double with gcc -m32 produces different results than other compilers or gcc -m64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113679
Bug ID: 113679
Summary: long long minus double with gcc -m32 produces
different results than other compilers or gcc -m64
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dilyan.palauzov at aegee dot org
Target Milestone: ---
diff.c is:
#include
int main(void) {
long long l = 9223372036854775806;
double d = 9223372036854775808.0;
printf("%f\n", (double)l - d);
return 0;
}
With gcc (GCC) 13.2.1 20231205 (Red Hat 13.2.1-6), gcc (Ubuntu
9.4.0-1ubuntu1~20.04.2) 9.4.0, clang 16.0.4 and clang 17.0.5:
$ gcc -m64 -o diff diff.c && ./diff
0.00
$ gcc -m32 -o diff diff.c && ./diff
-2.00
$ clang -m64 -o diff diff.c && ./diff
0.00
$ clang -m32 -o diff diff.c && ./diff
0.00
With cl.exe 19.29.3015319.29.30153 (first is x84 - 32 bit, second is 64 bit)
C:\> CALL "C:\Program Files (x86)\Microsoft Visual
Studio\2019\Community\VC\Auxiliary\Build\vcvarsall.bat" x86 10.0.17763.0
C:\> cl diff.c >nul 2>nul & .\diff.exe
0.00
C:\> CALL "C:\Program Files (x86)\Microsoft Visual
Studio\2019\Community\VC\Auxiliary\Build\vcvarsall.bat" amd64 10.0.17763.0
C:\> cl diff.c >nul 2>nul & .\diff.exe
0.00
gcc -m32 produces a different result, compared to gcc -m64, clang 17 (32 and
64bit), and MSCV Visual Studio 2019 (32 and 64bit).
[Bug sanitizer/113123] New: ASAN_OPTIONS=log_to_syslog=true leads to deadlock
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113123
Bug ID: 113123
Summary: ASAN_OPTIONS=log_to_syslog=true leads to deadlock
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: dilyan.palauzov at aegee dot org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
Created attachment 56928
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56928&action=edit
The backtrace as a separate file
I filled the same also at https://github.com/google/sanitizers/issues/1714.
I compile software on Fedora 39/ gcc 13.2.1 20231205 with
export CFLAGS="-g -fsanitize=address -fno-omit-frame-pointer -fno-common
-fsanitize=undefined -fsanitize-recover=address"
export CXXFLAGS="-g -fsanitize=address -fno-omit-frame-pointer -fno-common
-fsanitize=undefined -fsanitize-recover=address"
then I set
ASAN_OPTIONS=log_to_syslog=true:log_path=/tmp/c-asan.log:halt_on_error=false:detect_leaks=0"
UBSAN_OPTIONS=log_to_syslog=true:log_path=/tmp/c-ubsan.log:print_stacktrace=1"
LSAN_OPTIONS=verbosity=1:log_threads=1"
and run the software. The software reaches deadlock. I connect to it with gdb.
Below is the full backtrace. I do not know where the ?? at the end come from,
as I have compiled the software with debug information. I cannot write simpler
software, which reproduces the problem.
In any case the software waits forever in the syslog-Futex call.
Can you find, based on the provided backtrace, the root cause for the deadlock?
#0 0x7f16584f3d9e in __sanitizer::FutexWait (p=0x7f1658a9b2e8
<__lsan::global_mutex+8>, cmp=0) at
../../../../libsanitizer/sanitizer_common/sanitizer_linux.cpp:730
No locals.
#1 0x7f16584f676a in __sanitizer::Semaphore::Wait (this=0x7f1658a9b2e8
<__lsan::global_mutex+8>) at
../../../../libsanitizer/sanitizer_common/sanitizer_mutex.cpp:35
count =
#2 0x7f165850dc40 in __sanitizer::Mutex::Lock (this=0x7f1658a9b2e0
<__lsan::global_mutex>) at
../../../../libsanitizer/sanitizer_common/sanitizer_mutex.h:196
new_state =
locked =
spin_iters =
reset_mask =
state =
reset_mask =
state =
spin_iters =
new_state =
locked =
#3 __sanitizer::GenericScopedLock<__sanitizer::Mutex>::GenericScopedLock
(mu=0x7f1658a9b2e0 <__lsan::global_mutex>, this=) at
../../../../libsanitizer/sanitizer_common/sanitizer_mutex.h:383
No locals.
#4 __lsan_register_root_region (begin=0x7f1653b003d0, size=16) at
../../../../libsanitizer/lsan/lsan_common.cpp:1005
l = {mu_ = 0x7f1658a9b2e0 <__lsan::global_mutex>}
region = {begin = 1, size = 139733947553115}
#5 0x7f16584d9408 in DlsymAlloc::OnAllocate (size=,
ptr=0x7f1653b003d0) at ../../../../libsanitizer/asan/asan_malloc_linux.cpp:39
No locals.
#6 __sanitizer::DlSymAllocator::Allocate (size_in_bytes=15) at
../../../../libsanitizer/sanitizer_common/sanitizer_allocator_dlsym.h:37
ptr = 0x7f1653b003d0
ptr =
v1 =
v2 =
#7 __interceptor_malloc (size=size@entry=15) at
../../../../libsanitizer/asan/asan_malloc_linux.cpp:67
stack = {<__sanitizer::StackTrace> = {trace = 0x7ffdf06a0150, size = 1,
tag = 0, static TAG_UNKNOWN = 0, static TAG_ALLOC = 1, static TAG_DEALLOC = 2,
static TAG_CUSTOM = 100}, trace_buffer = {18446744073709551240,
139733947481999, 140728636932448, 0 , 4, 140728636934472,
140728636936224, 139733954961979, 0, 155648, 154304, 154304, 4096, 0, 1,
155648, 1597440, 1595213, 1595213, 4096, 155648, 5, 1597440, 1916928, 1914033,
1914033, 4096}, top_frame_bp = 1597440}
v1 =
v2 =
#8 0x7f16556c361f in __GI___strdup (s=s@entry=0x7f16557c03e0
"/etc/localtime") at strdup.c:42
len = 15
new =
#9 0x7f16556ec1a9 in tzset_internal (always=) at
tzset.c:402
is_initialized = 1
tz = 0x7f16557c03e0 "/etc/localtime"
#10 0x7f16556ec3bb in __tz_convert (timer=1703339934,
use_localtime=use_localtime@entry=1, tp=tp@entry=0x7ffdf06a0a60) at tzset.c:577
leap_correction = 0
leap_extra_secs = 0
#11 0x7f16556ea664 in __localtime_r (t=t@entry=0x7ffdf06a0a38,
tp=tp@entry=0x7ffdf06a0a60) at localtime.c:30
No locals.
#12 0x7f165573183b in __vsyslog_internal (pri=14, fmt=0x7f16585351a9 "%s",
ap=ap@entry=0x7ffdf06a0f20, mode_flags=mode_flags@entry=0) at syslog.c:160
pid = 0
now_tm = {tm_sec = 0, tm_min = 0, tm_hour = 0, tm_mday = 0, tm_mon = 0,
tm_year = 0, tm_wday = 0, tm_yday = 0, tm_isdst = 0, tm_gmtoff = 0, tm_zone =
0x0}
has_ts =
__clframe = {__cancel_routine = 0x7f
[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106472 Дилян Палаузов changed: What|Removed |Added CC||dilyan.palauzov at aegee dot org --- Comment #27 from Дилян Палаузов --- With gcc 13 at commit 670caa3f043e6a7af72bd76482a79a703a652ee5 (origin/releases/gcc-13) Author: GCC Administrator Date: Tue Jul 25 00:23:26 2023 + Daily bump. after calling export CONFIG_SITE="a" mkdir -p build && cd build && ../configure --enable-threads=posix --enable-nls --disable-multilib --enable-interpreter --with-system-zlib --enable-languages=c,c++,go,lto --enable-targets=all --with-system-unwind --without-x --with-linker-hash-style=gnu --enable-shared --with-build-config=bootstrap-lto\ bootstrap-O3 &> ../c-out && make build fails at stage 3 with libtool: compile: /git/gcc/build/./gcc/xgcc -B/git/gcc/build/./gcc/ -B/usr/local/x86_64-pc-linux-gnu/bin/ -B/usr/local/x86_64-pc-linux-gnu/lib/ -isystem /usr/local/x86_64-pc-linux-gnu/include -isystem /usr/local/x86_64-pc-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I../../../libgo -I ../../../libgo/runtime -I../../../libgo/../libffi/include -I../libffi/include -pthread -L../libatomic/.libs -fexceptions -fnon-call-exceptions -fsplit-stack -Wall -Wextra -Wwrite-strings -Wcast-qual -Werror -minline-all-stringops -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I ../../../libgo/../libgcc -I ../../../libgo/../libbacktrace -I ../../gcc/include -g -O2 -c ../../../libgo/go/golang.org/x/sys/cpu/cpu_gccgo_x86.c -fPIC -DPIC -o golang.org/x/sys/.libs/cpu_gccgo_x86.o libtool: compile: /git/gcc/build/./gcc/xgcc -B/git/gcc/build/./gcc/ -B/usr/local/x86_64-pc-linux-gnu/bin/ -B/usr/local/x86_64-pc-linux-gnu/lib/ -isystem /usr/local/x86_64-pc-linux-gnu/include -isystem /usr/local/x86_64-pc-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I../../../libgo -I ../../../libgo/runtime -I../../../libgo/../libffi/include -I../libffi/include -pthread -L../libatomic/.libs -fexceptions -fnon-call-exceptions -fsplit-stack -Wall -Wextra -Wwrite-strings -Wcast-qual -Werror -minline-all-stringops -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I ../../../libgo/../libgcc -I ../../../libgo/../libbacktrace -I ../../gcc/include -g -O2 -c ../../../libgo/go/golang.org/x/sys/cpu/cpu_gccgo_x86.c -o golang.org/x/sys/cpu_gccgo_x86.o >/dev/null 2>&1 make[4]: *** No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'. Stop. make[4]: Leaving directory '/git/gcc/build/x86_64-pc-linux-gnu/libgo' make[3]: *** [Makefile:2347: all-recursive] Error 1 make[3]: Leaving directory '/git/gcc/build/x86_64-pc-linux-gnu/libgo' make[2]: *** [Makefile:1212: all] Error 2 make[2]: Leaving directory '/git/gcc/build/x86_64-pc-linux-gnu/libgo' make[1]: *** [Makefile:22370: all-target-libgo] Error 2 make[1]: Leaving directory '/git/gcc/build' make: *** [Makefile:1082: all] Error 2 When I use instead --enable-languages=all it works (at least worked on the releases/gcc-13 branch on 2023-04-28)
[Bug go/106747] [12 Regression] Regression: go version does not print a number in 12.x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106747 --- Comment #5 from Дилян Палаузов --- (In reply to Ian Lance Taylor from comment #4) > This is fixed on tip. Want to backport the patch to the GCC 12 branch? This is a regression. It would be good if there is a correction on the GCC 12 branch.
[Bug go/106747] Regression: go version does not print a number in 12.x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106747 --- Comment #3 from Дилян Палаузов --- installing gcc installs two binaries:gccgo and go. The first is OK: $ gccgo --version gccgo (GCC) 12.1.1 20220814 Copyright (C) 2022 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. The second binary, installed by gcc, go: $ go version go version unknown linux/amd64 does not print a version. The problem report is about the second binary.
[Bug go/106747] New: Regression: go version does not print a number in 12.x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106747 Bug ID: 106747 Summary: Regression: go version does not print a number in 12.x Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: dilyan.palauzov at aegee dot org Target Milestone: --- If my observations are correct, in the 11.x series go version printed a version number, while in the 12.x series it prints: $ go version go version unknown linux/amd64 The unknown-version is printed on git commit a3bd980b9b146633e2 ( Daily bump. 20220814) In the 11.x series it printed $ go version go version go1.16.5 gccgo (GCC) 11.2.1 20211010 linux/amd64 This is a regression.
[Bug analyzer/105530] New: Analyzer makes wrong conclusions for the malloc (deallocator, ptr-index) attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105530
Bug ID: 105530
Summary: Analyzer makes wrong conclusions for the malloc
(deallocator, ptr-index) attribute
Product: gcc
Version: 11.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dilyan.palauzov at aegee dot org
Target Milestone: ---
gcc (GCC) 11.2.1 20220413 (compiled from git)
For a.c:
#include
void fr(char* x) {
free(x);
}
__attribute__((malloc, malloc(fr, 1))) char * al() {
return (char*) malloc(10);
}
int main() {
fr(al());
return 0;
}
$ gcc a.c -fanalyzer
prints:
a.c: In function ‘al’:
a.c:8:10: warning: leak of ‘al()’ [CWE-401] [-Wanalyzer-malloc-leak]
8 | return (char*) malloc(10);
| ^~
‘main’: events 1-3
|
| 11 | int main() {
| | ^~~~
| | |
| | (1) entry to ‘main’
| 12 | fr(al());
| |
| | |
| | (2) allocated here
| | (3) calling ‘al’ from ‘main’
|
+--> ‘al’: events 4-5
|
|7 | __attribute__((malloc, malloc(fr, 1))) char * al() {
| | ^~
| | |
| | (4) entry to
‘al’
|8 | return (char*) malloc(10);
| | ~~
| | |
| | (5) ‘al()’ leaks here; was allocated at (2)
|
a.c: In function ‘main’:
a.c:12:3: warning: ‘al()’ should have been deallocated with ‘free’ but was
deallocated with ‘fr’ [CWE-762] [-Wanalyzer-mismatchi[4/1963]
ocation]
12 | fr(al());
| ^~~~
‘main’: events 1-2
|
| 11 | int main() {
| | ^~~~
| | |
| | (1) entry to ‘main’
| 12 | fr(al());
| |
| | |
| | (2) calling ‘al’ from ‘main’
|
+--> ‘al’: events 3-4
|
|7 | __attribute__((malloc, malloc(fr, 1))) char * al() {
| | ^~
| | |
| | (3) entry to
‘al’
|8 | return (char*) malloc(10);
| | ~~
| | |
| | (4) allocated here (expects deallocation
with ‘free’)
|
<--+
|
‘main’: events 5-6
|
| 12 | fr(al());
| | ^~~~
| | |
| | (5) returning to ‘main’ from ‘al’
| | (6) deallocated with ‘fr’ here; allocation at (4) expects
deallocation with ‘free’
|
Now, I do not understand these warnings. First of all, nothing is leaked.
> a.c:12:3: warning: ‘al()’ should have been deallocated with ‘free’ but was
> deallocated with ‘fr’ [CWE-762] [-Wanalyzer-mismatchi[4/1963]
The complier/analyzer is explicitly told by the malloc(fr, 1) attribute, that
fr() is the right way to deallocate the result of al().
> a.c:8:10: warning: leak of ‘al()’ [CWE-401] [-Wanalyzer-malloc-leak]
return (char*) malloc(10); is by itself not a memory leak.
[Bug go/102469] New: gccgo: error: ‘copy’ defined as both imported name and global name, while golang does not produce this error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102469
Bug ID: 102469
Summary: gccgo: error: ‘copy’ defined as both imported name
and global name, while golang does not produce this
error
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: dilyan.palauzov at aegee dot org
CC: cmang at google dot com
Target Milestone: ---
I download the tip of https://github.com/containers/podman/ , commit
b0d1c0fe22da27c88a0e5d . With `go version go1.16.5 gccgo (GCC) 11.2.1 20210728
(Red Hat 11.2.1-1) linux/amd64` calling `make` the error is:
```
CGO_ENABLED=1 GOOS=linux GOARCH=amd64 go build \
-mod=vendor \
-ldflags '-X
github.com/containers/podman/v3/libpod/define.gitCommit=b0d1c0fe22da27c88a0e5de11de08d63ef861347
-X github.com/containers/podman/v3/libpod/define.buildInfo=1632396554 -X
github.com/containers/podman/v3/libpod/config._installPrefix=/usr/local -X
github.com/containers/podman/v3/libpod/config._etcDir=/usr/local/etc ' \
-tags " exclude_graphdriver_btrfs btrfs_noversion selinux systemd
exclude_graphdriver_devicemapper seccomp" \
-o bin/podman ./cmd/podman
go build: when using gccgo toolchain, please pass linker flags using
-gccgoflags, not -ldflags
# github.com/containers/storage/pkg/unshare
unshare.c: In function ‘parse_proc_stringlist’:
unshare.c:137:23: warning: comparison of integer expressions of different
signedness: ‘int’ and ‘size_t’ {aka ‘long unsigned int’} [-Wsign-compare]
137 | for (n = 0; n < used; n++) {
| ^
unshare.c:148:23: warning: comparison of integer expressions of different
signedness: ‘int’ and ‘size_t’ {aka ‘long unsigned int’} [-Wsign-compare]
148 | for (n = 0; n < used; n++) {
| ^
# github.com/containers/podman/v3/libpod
libpod/options.go:81:33: error: ‘copy’ defined as both imported name and global
name
81 |
copy(rt.storageConfig.GraphDriverOptions, config.GraphDriverOptions)
| ^
libpod/container_stat_linux.go:13:49: note: ‘copy’ imported here
13 | "github.com/containers/podman/v3/pkg/copy"
| ^
make: *** [Makefile:300: bin/podman] Error 2
With go version go1.16.8 linux/amd64 on the same system, calling `make`
produces no warngis. Even when I replace `-ldflags` with `-gccgoflags` the
signed/unsigned warning stays, and the `copy` error also stays.
If golang does not emit “error: ‘copy’ defined as both imported name and global
name”, gccgo shall neither.
[Bug other/101834] New: make distclean forgets ./c++tools/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101834 Bug ID: 101834 Summary: make distclean forgets ./c++tools/ Product: gcc Version: 11.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: dilyan.palauzov at aegee dot org Target Milestone: --- On the releases/gcc-11 branch, at commit 990bea6f7e23bd935ad022db6bf4c9de2f74baf3 (HEAD -> releases/gcc-11, origin/releases/gcc-11) Author: GCC Administrator Date: Sun Aug 8 00:18:08 2021 + Daily bump. diff --git a/gcc/DATESTAMP b/gcc/DATESTAMP index d5d1da952c7..3b0c65fa4e8 100644 --- a/gcc/DATESTAMP +++ b/gcc/DATESTAMP @@ -1 +1 @@ -20210807 +20210808 calling #!/usr/local/bin/bash export CONFIG_SITE="a" mkdir -p build && cd build && ../configure --enable-threads=posix --enable-nls --disable-multilib --enable-interpreter --with-system-zlib --enable-languages=all --enable-targets=all --with-system-unwind --without-x --with-linker-hash-style=gnu --enable-shared --with-build-config=bootstrap-lto\ bootstrap-O3 &> ../c-out && make && make install && make distclean && cd .. && rmdir build ; does not delete: build/c++tools build/c++tools/resolver.o build/c++tools/Makefile build/c++tools/server.d build/c++tools/server.o build/c++tools/resolver.d build/c++tools/config.cache build/c++tools/g++-mapper-server
[Bug libstdc++/101060] New: ‘fenv_t’ has not been declared in ‘::’ in 11.1, but is declared in 10.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101060 Bug ID: 101060 Summary: ‘fenv_t’ has not been declared in ‘::’ in 11.1, but is declared in 10.3 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: dilyan.palauzov at aegee dot org Target Milestone: --- Compiling libstdc++ only with $ ../../gcc-11.1.0/libstdc++-v3/configure --disable-libstdcxx-pch --disable-static --prefix=/ --disable-multilib fails for 11.1 with the message below, but does work with gcc 10.3. In both cases I use gcc 11.1 - make "AR_FLAGS=" "CC_FOR_BUILD=" "CC_FOR_TARGET=" "CFLAGS=-g -O2" "CXXFLAGS=" "CFLAGS_FOR_BUILD=" "CFLAGS_FOR_TARGET=" "INSTALL=/usr/bin/install -c" "INSTALL_DATA=/usr/bin/install -c -m 644" "INSTALL_PROGRAM=/usr/bin/install -c" "INSTALL_SCRIPT=/usr/bin/install -c" "LDFLAGS=" "LIBCFLAGS=" "LIBCFLAGS_FOR_TARGET=" "MAKE=make" "MAKEINFO=/bin/sh /src/gcc-11.1.0/missing makeinfo " "SHELL=/bin/sh" "RUNTESTFLAGS=" "exec_prefix=/" "infodir=//share/info" "libdir=//lib" "includedir=//include" "prefix=/" "tooldir=" "gxx_include_dir=//include/c++/11.1.0" "AR=ar" "AS=as" "LD=/usr/bin/ld" "RANLIB=ranlib" "NM=/usr/bin/nm -B" "NM_FOR_BUILD=" "NM_FOR_TARGET=" "DESTDIR=" "WERROR=" all-recursive make[1]: Entering directory '/src/chroot/libstdc++11' Making all in include make[2]: Entering directory '/src/chroot/libstdc++11/include' make[2]: Nothing to be done for 'all'. make[2]: Leaving directory '/src/chroot/libstdc++11/include' Making all in libsupc++ make[2]: Entering directory '/src/chroot/libstdc++11/libsupc++' make[2]: Nothing to be done for 'all'. make[2]: Leaving directory '/src/chroot/libstdc++11/libsupc++' Making all in src make[2]: Entering directory '/src/chroot/libstdc++11/src' Making all in c++98 make[3]: Entering directory '/src/chroot/libstdc++11/src/c++98' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/src/chroot/libstdc++11/src/c++98' Making all in c++11 make[3]: Entering directory '/src/chroot/libstdc++11/src/c++11' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/src/chroot/libstdc++11/src/c++11' Making all in c++17 make[3]: Entering directory '/src/chroot/libstdc++11/src/c++17' /bin/sh ../../libtool --tag CXX --tag disable-shared --mode=compile g++ -I/src/gcc-11.1.0/libstdc++-v3/../libgcc -I/src/chroot/libstdc++11/include/ -I/src/chroot/libstdc++11/include -I/src/gcc-11.1.0/libstdc++-v3/libsupc++ -std=gnu++17 -prefer-pic -D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2 -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=floating_from_chars.lo -fimplicit-templates -fcf-protection -mshstk -c -o floating_from_chars.lo ../../../../gcc-11.1.0/libstdc++-v3/src/c++17/floating_from_chars.cc libtool: compile: g++ -I/src/gcc-11.1.0/libstdc++-v3/../libgcc -I/src/chroot/libstdc++11/include/ -I/src/chroot/libstdc++11/include -I/src/gcc-11.1.0/libstdc++-v3/libsupc++ -std=gnu++17 -D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2 -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=floating_from_chars.lo -fimplicit-templates -fcf-protection -mshstk -c ../../../../gcc-11.1.0/libstdc++-v3/src/c++17/floating_from_chars.cc -fPIC -DPIC -D_GLIBCXX_SHARED -o floating_from_chars.o In file included from /src/chroot/libstdc++11/include/cfenv:41, from ../../../../gcc-11.1.0/libstdc++-v3/src/c++17/floating_from_chars.cc:36: /src/chroot/libstdc++11/include/fenv.h:58:11: error: ‘fenv_t’ has not been declared in ‘::’ 58 | using ::fenv_t; | ^~ /src/chroot/libstdc++11/include/fenv.h:59:11: error: ‘fexcept_t’ has not been declared in ‘::’ 59 | using ::fexcept_t; | ^ /src/chroot/libstdc++11/include/fenv.h:62:11: error: ‘feclearexcept’ has not been declared in ‘::’ 62 | using ::feclearexcept; | ^ /src/chroot/libstdc++11/include/fe
[Bug go/91700] New: Document go version for gcc 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91700 Bug ID: 91700 Summary: Document go version for gcc 9 Product: gcc Version: 9.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: dilyan.palauzov at aegee dot org CC: cmang at google dot com Target Milestone: --- Per http://gcc.gnu.org/gcc-8/changes.html gcc compiles for go 1.10.1 . http://gcc.gnu.org/gcc-9/changes.html states nothing about go, which means, that gcc 9 implements go 1.10.1 I have installed gcc 9.1.1 20190804 and its “go version” reports “go version go1.12.2 gccgo (GCC) 9.1.1 20190804 linux/amd64”. Please update http://gcc.gnu.org/gcc-9/changes.html to state, that it equivalent to the go 1.12 compiler, or fix by other means this inconsistency.
[Bug c/90036] New: False positive: directive argument is null [-Werror=format-overflow=]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90036 Bug ID: 90036 Summary: False positive: directive argument is null [-Werror=format-overflow=] Product: gcc Version: 8.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dilyan.palauzov at aegee dot org Target Milestone: --- See https://sourceware.org/bugzilla/show_bug.cgi?id=24440: Compiling most recent binutils (git/master - commit b05971a652c35ed72d3c95290e18) with gcc 8.3.1 20190330 fails with: make[4]: Entering directory '/root/binutils/binutils' gcc -DHAVE_CONFIG_H -I. -I/git/binutils-gdb/binutils -I. -I/git/binutils-gdb/binutils -I../bfd -I/git/binutils-gdb/binutils/.. /bfd -I/git/binutils-gdb/binutils/../include -DLOCALEDIR="\"/usr/local/share/locale\"" -Dbin_dummy_emulation=bin_vanilla_emulat ion -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Wstack-usage=262144 -Werror -O2 -pipe -g -MT wrstabs.o -MD -M P -MF .deps/wrstabs.Tpo -c -o wrstabs.o /git/binutils-gdb/binutils/wrstabs.c /git/binutils-gdb/binutils/wrstabs.c: In function ‘stab_start_class_type’: /git/binutils-gdb/binutils/wrstabs.c:1476:25: error: ‘%s’ directive argument is null [-Werror=format-overflow=] sprintf (vtable, "~%%%s", vstring); ^~ cc1: all warnings being treated as errors make[4]: *** [Makefile:1061: wrstabs.o] Error 1 The code snippet is: vtable = (char *) xmalloc (strlen (vstring) + 3); sprintf (vtable, "~%%%s", vstring); free (vstring); Comment 1 (https://sourceware.org/bugzilla/show_bug.cgi?id=24440#c1) says: > That doesn't make sense. vstring must be non-null since it has been passed > to strlen already.
[Bug lto/88643] -Wl,--wrap not supported with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88643 --- Comment #11 from Дилян Палаузов --- Reported for ld.gold at https://sourceware.org/bugzilla/show_bug.cgi?id=24415 .
[Bug lto/88643] -Wl,--wrap not supported with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88643 --- Comment #10 from Дилян Палаузов --- With the patch applied this works: clang -flto -fuse-ld=bfd -Wl,--wrap=read -O3 t.c gcc -flto -fuse-ld=bfd -Wl,--wrap=read -O3 t.c gcc -flto -fuse-ld=bfd -Wl,--wrap=read -O2 t.c gcc -flto -fuse-ld=bfd -Wl,--wrap=read -O1 t.c This does not work: gcc -flto -fuse-ld=gold -Wl,--wrap=read -O3 t.c gcc -flto -fuse-ld=gold -Wl,--wrap=read -O2 t.c gcc -flto -fuse-ld=gold -Wl,--wrap=read -O1 t.c
[Bug lto/88643] -Wl,--wrap not supported with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88643 --- Comment #9 from Дилян Палаузов --- With the patch applied to ld.bfd “clang -flto -fuse-ld=bfd -Wl,--wrap=read t.c” does work.
[Bug lto/88643] -Wl,--wrap not supported with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88643 --- Comment #7 from Дилян Палаузов --- As noted at https://sourceware.org/bugzilla/show_bug.cgi?id=24406 this does work with clang+gold and clang+lld, but not with clang+bfd. As this does not work with gcc+gold, the problem is not in the linker.
[Bug lto/89930] New: - -Wl,--wrap= incompatible with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89930
Bug ID: 89930
Summary: - -Wl,--wrap= incompatible with -flto
Product: gcc
Version: 8.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: dilyan.palauzov at aegee dot org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
This is t.c:
#include
#include
ssize_t __wrap_read(int fd, void *buffer, size_t count) {
printf("%s\n", (char*)buffer);
return fd + count;
}
int main() {
int i = read(1, "abc", 5);
printf("%i\n", i);
}
I have gcc 8.3.1 20190311, ld.bfd 2.32.51.20190319, ld.gold 1.16
2.32.51.20190319 and clang 8.0.0.
This works
clang -flto -fuse-ld=gold -Wl,--wrap=read t.c
gcc -fuse-ld=bfd -Wl,--wrap=read t.c
gcc -fuse-ld=gold -Wl,--wrap=read t.c
clang -fuse-ld=bfd -Wl,--wrap=read t.c
clang -fuse-ld=gold -Wl,--wrap=read t.c
This fails
clang -flto -fuse-ld=bfd -Wl,--wrap=read t.c
gcc -flto -fuse-ld=gold -Wl,--wrap=read t.c
gcc -flto -fuse-ld=bfd -Wl,--wrap=read t.c
Since clang+gold works, gcc+gold should also work.
See also https://sourceware.org/bugzilla/show_bug.cgi?id=24406.
[Bug bootstrap/67128] Makefile.in, libcc1 and --enable-shared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67128 --- Comment #4 from Дилян Палаузов --- If an impossible combination is requested, then ./configure shall fail
[Bug lto/84995] Documentation gcc-ar and gcc-ranlib vs {libdir}/bfd-plugins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84995 --- Comment #18 from Дилян Палаузов --- I will sum up the discussion so far on this and other tickets: When one distributes source code software packages, the developers directly or indirectly use AR to create static libraries, when the user wants static libraries. Think on autoconf/libtool packages, where the users of those packages = software developers do not deal with AR. When a mortal user wants to build something with LTO, the user has to pass -flto to the compiler, for any source code package. Doing the LTO build process more complex than that leads to a situation, where LTO is not utilized, due to the complixity of running it. Some distributions install the linker plugin under $libdir/bfd-plugins and make ar/nm/ranlib deal transparently with -flto, but putting the plugin under $libdir/bfd-plugin for using ar/ranlib/nm is apparently kind of secret or too complicated, as not all distributions do this. So sticking to AR for building with LTO is currently not portable. When CMake is used, it chooses the appropriate gcc-ar-4, gcc-ar, llvm-ar-4.0 or llvm-ar (see https://gitlab.kitware.com/cmake/cmake/commit/630235bd9e049a8da47 and https://gitlab.kitware.com/cmake/cmake/commit/75accaae8b6a691b031f2) and ensures, that the just passing -flto will enable LTO. As can be seen from the commits above, instead of installing the linker plugin under $libdir/bfd-plugins, distributions rename gcc-ar to something different. CPython’s autoconf tries to detect if LTO is used and either switches to llvm-lto or (with GCC) uses fat lto objects, but does not use gcc-ar. Likewise valgrind’s ./configure uses gcc-ar, but not llvm-ar, so does libical’s Cmakefile (to enable LTO in old cmake versions). So the solution of compiling platform independent software is not in the distributions, the solution is to do incomplete hacks in the configure steps, and apparently meson has some knowledge how to do this (büt does not append the version number), cmake has the most complete knowledge and experimenting with autoconf nobody provides portable software where LTO is works both under LLVM and GCC. Thus the intention of tweaking ./configure is to achieve portability but nobody managed to achieve it in an optimal way yet. Installing the linker plugin under $libdir/bfd-plugins by the compiler will suggest to all distributions that the linker plugin has to be there and the distributions will ensure that at all time there is a linker plugin, while it is in practice irrelevant from which GCC version the linker plugin comes. It is irrelevant, because the plugin there is only used by ar/nm/ranlib and the differences between the versions of liblto_plugin are insignificant to ar/nm/ranlib. There are now two options: * installing the linker plugin by gcc’s “make install” in $libdir/bfd-plugin which will lead in mid-term to having AR deal with LTO in a portable way * not installing the linker plugin by gcc’s “make install” in $libdir/bfd-plugin. The only portable/cross-platform way to build with LTO is using cmake. Seriously. That said, there are advantages when gcc’s “make install” inserts its plugin in $libdir/bfd-plugins and no disadvantages. While not doing so has only disadvantages. Please explain whe gcc’s “make install” does not insert its linker plugin on the rigth place and how are supposed software developers to write software/build systems, that support LTO on any platform. Finally, not installing the plugin under $libdir/bfd-plugins because of differences in the versions, forces users to use gcc-ar, but it has the very same problems with differences in the versions.
[Bug lto/84995] Documentation gcc-ar and gcc-ranlib vs {libdir}/bfd-plugins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84995 --- Comment #15 from Дилян Палаузов --- Why isn’t liblto_plugin.so tweaked to claim only the GCC LTO files, it can handle? E.g. liblto_plugin.so from GCC7 does not claim files for GCC 8 LTO? I do not get the conclusion here: * liblto_plugin.so from $libdir/bfd-plugins is only magially called by ar/nm/ranlib and there the version number does not matter; * in case where liblto_plugin.so is not called by ar/nm/ranlib the version number matters, but no auto-loading happens, so installing it under $libdir/bfd-plugins is irrelevant So when will it be problematic to do auto loading by ar/nm/ranlib and when can installing the plugin under $libdir/bfd-plugins create problems?
[Bug lto/84995] Documentation gcc-ar and gcc-ranlib vs {libdir}/bfd-plugins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84995 --- Comment #13 from Дилян Палаузов --- At https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70345#c4 is written that “Right now the plugin from any gcc can be used with any gcc.” This is not the same as the last comment. Please clarify again, if any gcc plugin can be used with any gcc. If several plugins can be installed simultaneously and the first one that claims the .o file wins, why aren’t plugins for both GCC7 and GCC8 installed at the same time? Just for gcc8 files, the gcc7 plugin will not claim the responsibility.
[Bug lto/84995] Documentation gcc-ar and gcc-ranlib vs {libdir}/bfd-plugins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84995 --- Comment #11 from Дилян Палаузов --- According to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70345#c4 it does not matter whether liblto_plugin.so.0.0.0 from GCC7 or 8 is installed under $libdir/bfd-plugins: both work for both compiler versions.
[Bug lto/84995] Documentation gcc-ar and gcc-ranlib vs {libdir}/bfd-plugins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84995 --- Comment #9 from Дилян Палаузов --- Yes, $(libdir)/bfd-plugins is a location automatically scanned by ar/nm/ranlib. The question is, why GCC’s “make install” does not put there its linker plugin. As long as nobody installs the linker plugins under $(libdir)/bfd-plugins, how are program ./configure’s supposed to be written in a way, that LTO works with both Clang and GCC?
[Bug lto/84995] Documentation gcc-ar and gcc-ranlib vs {libdir}/bfd-plugins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84995 Дилян Палаузов changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #7 from Дилян Палаузов --- Why doesn’t GCC “make install” put the linker plugin under $libdir/bfd-plugins and how are program ./configure’s supposed to be written in a way, that LTO works with both Clang and GCC?
[Bug other/88691] New: Add support for -fuse-ld=lld (https://lld.llvm.org/)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88691 Bug ID: 88691 Summary: Add support for -fuse-ld=lld (https://lld.llvm.org/) Product: gcc Version: 8.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: dilyan.palauzov at aegee dot org Target Milestone: ---
[Bug bootstrap/87741] Don't build readline/libreadline.a in GDB, when --with-system-readline is supplied
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87741 --- Comment #6 from Дилян Палаузов --- I have misspelled the domain — gnu.gcc.org
[Bug bootstrap/87741] Don't build readline/libreadline.a in GDB, when --with-system-readline is supplied
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87741 --- Comment #4 from Дилян Палаузов --- The mail I send has only text/plain MIME part. Moreover, the mail was not permanently rejected. I want to know why the mail server says "Retry sending later".
[Bug bootstrap/87741] Don't build readline/libreadline.a in GDB, when --with-system-readline is supplied
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87741 --- Comment #2 from Дилян Палаузов --- Created attachment 44905 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44905&action=edit Why don’t the GCC mailservers accept my email to gcc-pathces?
[Bug bootstrap/87741] New: Don't build readline/libreadline.a in GDB, when --with-system-readline is supplied
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87741 Bug ID: 87741 Summary: Don't build readline/libreadline.a in GDB, when --with-system-readline is supplied Product: gcc Version: 7.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: dilyan.palauzov at aegee dot org Target Milestone: --- Please integrate this snippet, so that gdb can skip building the shipped libreadline, when the system-libreadline is used, see https://sourceware.org/bugzilla/show_bug.cgi?id=18632 for details diff --git a/configure.ac b/configure.ac --- a/configure.ac +++ b/configure.ac @@ -253,6 +253,12 @@ if test x$with_system_zlib = xyes ; then noconfigdirs="$noconfigdirs zlib" fi +# Don't compile the bundled readline/libreadline.a in gdb-binutils if +# --with-system-readline is provided. +if test x$with_system_readline = xyes ; then + noconfigdirs="$noconfigdirs readline" +fi + # some tools are so dependent upon X11 that if we're not building with X, # it's not even worth trying to configure, much less build, that tool.
[Bug c/87710] Explicitly mentioned libraries by -lx are not in the DT_NEEDED list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87710 --- Comment #4 from Дилян Палаузов --- Moved to for ld.bfd: https://sourceware.org/bugzilla/show_bug.cgi?id=23811 for ld.gold: https://sourceware.org/bugzilla/show_bug.cgi?id=23812
[Bug c/87710] Explicitly mentioned libraries by -lx are not in the DT_NEEDED list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87710 --- Comment #2 from Дилян Палаузов --- I tried this with -fuse-ld=gold and -fuse-ld=bfd . If you mean the problem is in both ld.bfd and ld.gold, I will report it there.
[Bug c/87710] New: Explicitly mentioned libraries by -lx are not in the DT_NEEDED list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87710
Bug ID: 87710
Summary: Explicitly mentioned libraries by -lx are not in the
DT_NEEDED list
Product: gcc
Version: 7.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dilyan.palauzov at aegee dot org
Target Milestone: ---
Calling “make install” without DESTDIR after building libc-2.28 calls
eventually glibc-2.28/srcribts/test-installation.pl . It creates the file
test-prg7044.c with content:
#include
#include
int main(void) {
printf ("Your new glibc installation seems to be ok.\n");
exit (0);
}
Then calls “gcc /src/glibc228/test-prg7044.c -lc -lBrokenLocale -lpthread
-lcrypt -ldl -lgcc_s -lnsl -lutil -lnss_dns -lnss_compat -lmvec -lresolv
-lnss_db -lm -lnss_files -lrt -lnss_hesiod -lanl -o
/src/glibc228/test-prg7044“, and chechs whether „ldd test-prg7044” contains
BrokenLocale. On my system the comman above invoked with -v prints:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/7.3.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --enable-threads=posix --enable-nls
--disable-multilib --enable-interpreter --with-system-zlib
--enable-libgcj-multifile --enable-languages=all --enable-targets=all
--with-system-unwind --without-x --with-linker-hash-style=gnu --enable-shared
--with-build-config='bootstrap-lto bootstrap-O3'
Thread model: posix
gcc version 7.3.1 20181013 (GCC)
COLLECT_GCC_OPTIONS='-v' '-o' '/src/glibc228//test-prg7044' '-mtune=generic'
'-march=x86-64'
/usr/local/libexec/gcc/x86_64-pc-linux-gnu/7.3.1/cc1 -quiet -v -imultiarch
x86_64-linux-gnu /src/glibc228//test-prg7044.c -quiet -dumpbase test-prg7044.c
-mtune=generic -march=x86-64 -auxbase test-prg7044 -version -o /tmp/ccDutEqy.s
GNU C11 (GCC) version 7.3.1 20181013 (x86_64-pc-linux-gnu)
compiled by GNU C version 7.3.1 20181013, GMP version 6.1.2, MPFR
version 4.0.0, MPC version 1.1.0, isl version isl-0.19-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/include
/usr/local/include
/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/include-fixed
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
GNU C11 (GCC) version 7.3.1 20181013 (x86_64-pc-linux-gnu)
compiled by GNU C version 7.3.1 20181013, GMP version 6.1.2, MPFR
version 4.0.0, MPC version 1.1.0, isl version isl-0.19-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 8ff192ae53ef780b032a40b890e7c233
COLLECT_GCC_OPTIONS='-v' '-o' '/src/glibc228//test-prg7044' '-mtune=generic'
'-march=x86-64'
/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../x86_64-pc-linux-gnu/bin/as
-v --64 -o /tmp/ccZTddK3.o /tmp/ccDutEqy.s
GNU assembler version 2.31.51 (x86_64-pc-linux-gnu) using BFD version (GNU
Binutils) 2.31.51.20181019
COMPILER_PATH=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/7.3.1/:/usr/local/libexec/gcc/x86_64-pc-linux-gnu/7.3.1/:/usr/local/libexec/gcc/x86_64-pc-linux-gnu/:/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/:/usr/local/lib/gcc/x86_64-pc-linux-gnu/:/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../x86_64-pc-linux-gnu/bin/
LIBRARY_PATH=/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/:/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../x86_64-linux-gnu/:/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../lib64/:/lib/x86_64-linux-gnu/:/lib/../lib64/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib64/:/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../x86_64-pc-linux-gnu/lib/:/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-o' '/src/glibc228//test-prg7044' '-mtune=generic'
'-march=x86-64'
/usr/local/libexec/gcc/x86_64-pc-linux-gnu/7.3.1/collect2 -plugin
/usr/local/libexec/gcc/x86_64-pc-linux-gnu/7.3.1/liblto_plugin.so
-plugin-opt=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/7.3.1/lto-wrapper
-plugin-opt=-fresolution=/tmp/ccLuMS4y.res -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s
--eh-frame-hdr --hash-style=gnu -m elf_x86_64 -dynamic-linker
/lib64/ld-linux-x86-64.so.2 -o /src/glibc228//test-prg7044
/usr/lib/../lib64/crt1.o /usr/lib/../lib64/crti.o
/usr/local/lib/g
[Bug bootstrap/86534] Linking gcc with gold fails, when libisl is under /usr/local/lib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86534 --- Comment #2 from Дилян Палаузов --- I can pass --with-isl-lib=/usr/local/lib, I can also compile ld.gold to have implicit -L/usr/local/lib. But if gcc is supposed to be linkable with both ld.bfd and ld.gold, then --with-isl-lib shall not be necessary.
[Bug bootstrap/86534] New: Linking gcc with gold fails, when libisl is under /usr/local/lib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86534 Bug ID: 86534 Summary: Linking gcc with gold fails, when libisl is under /usr/local/lib Product: gcc Version: 7.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: dilyan.palauzov at aegee dot org Target Milestone: --- When ISL is installed under /usr/local/lib, linking GCC with ld.gold does not work, because ld.gold does not have implicit -L/usr/local/lib, contrary to ld.bfd. I asked at https://sourceware.org/bugzilla/show_bug.cgi?id=23413 to imply -L/usr/local/lib. There you can see the whole story, how gcc is built etc. Please consider adding explicit -L/usr/local/lib when building gcc at stage 2 (and probably stage 3), when libisl, libmpc, libmpfr, libz or libgmp are in /usr/local/lib .
[Bug bootstrap/85413] "./configure --with-build-config=bootstrap-lto " != "BOOT_CFLAGS +=-flto "
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85413 --- Comment #2 from Дилян Палаузов --- config/bootstrap-lto.mk contains more tweaks: # This option enables LTO for stage2 and stage3 in slim mode STAGE2_CFLAGS += -flto=jobserver -frandom-seed=1 STAGE3_CFLAGS += -flto=jobserver -frandom-seed=1 STAGEprofile_CFLAGS += -fno-lto # assumes the host supports the linker plugin LTO_AR = $$r/$(HOST_SUBDIR)/prev-gcc/gcc-ar$(exeext) -B$$r/$(HOST_SUBDIR)/prev-gcc/ LTO_RANLIB = $$r/$(HOST_SUBDIR)/prev-gcc/gcc-ranlib$(exeext) -B$$r/$(HOST_SUBDIR)/prev-gcc/ LTO_EXPORTS = AR="$(LTO_AR)"; export AR; \ RANLIB="$(LTO_RANLIB)"; export RANLIB; LTO_FLAGS_TO_PASS = AR="$(LTO_AR)" RANLIB="$(LTO_RANLIB)"
[Bug bootstrap/85413] New: "./configure --with-build-config=bootstrap-lto " != "BOOT_CFLAGS +=-flto "
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85413 Bug ID: 85413 Summary: "./configure --with-build-config=bootstrap-lto " != "BOOT_CFLAGS +=-flto " Product: gcc Version: 7.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: dilyan.palauzov at aegee dot org Target Milestone: --- https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/doc/install.texi;h=64ad2445a335f270200e359812bc9d2213bd2405;hb=HEAD#l2457 says: ./configure --with-build-config=bootstrap-lto is the same as adding -flto to BOOT_CFLAGS, but providing that config/bootstrap-lto.mk contains more code than just adding -flto, this seems not to be correct. Moreover the text in gcc/doc/instal.texi concerning the equivalence originates from 2010, but config/bootstrap-lto.ml was last modified in 2014. In 2010 bootstrap-lto.m4 indeed only added -flto, not it appends also =jobserver.
[Bug lto/84995] Documentation gcc-ar and gcc-ranlib vs {libdir}/bfd-plugins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84995
--- Comment #2 from Дилян Палаузов ---
gcc-ar always uses the latest plugin:
$ cat t.c
#include
int main() {
printf("Z\n");
}
$ x86_64-pc-linux-gnu-gcc-6.4.1 -flto t.c -C -o t.o
$ strace gcc-ar rc t.a t.o prints:
stat("/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../x86_64-pc-linux-gnu/bin/liblto_plugin.so",
0x7fff52b52030) = -1 ENOENT (No such file or directory)
stat("/usr/local/libexec/gcc/x86_64-pc-linux-gnu/7.3.1/liblto_plugin.so",
{st_mode=S_IFREG|0755, st_size=95328, ...}) = 0
access("/usr/local/libexec/gcc/x86_64-pc-linux-gnu/7.3.1/liblto_plugin.so",
R_OK) = 0
$ strace gcc-nm t.aprints:
stat("/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../x86_64-pc-linux-gnu/bin/liblto_plugin.so",
0x7ffd682c9970) = -1 ENOENT (N
o such file or directory)
stat("/usr/local/libexec/gcc/x86_64-pc-linux-gnu/7.3.1/liblto_plugin.so",
{st_mode=S_IFREG|0755, st_size=95328, ...}) = 0
access("/usr/local/libexec/gcc/x86_64-pc-linux-gnu/7.3.1/liblto_plugin.so",
R_OK) = 0
it seems that the last installed liblto_plugin.so version is used, even if old
gcc did the object file.
[Bug target/84926] error: inlining failed in call to always_inline ‘_mm_crc32_u64’: target specific option mismatch _mm_crc32_u64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84926 Дилян Палаузов changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |--- --- Comment #4 from Дилян Палаузов --- Why does COLLECT_GCC_OPTIONS show '-march=x86-64', but https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html does not show x86-64 as valid option for -march? Why doesn't 'make CFLAGS="--verbose -march=native -flto"' work, in terms of detecting that ssse3 is available and there is no conflict? The latter prints: make[3]: Leaving directory '/git/postgresql/src/backend' gcc --verbose -march=native -flto -I../../src/port -DFRONTEND -I../../src/include -D_GNU_SOURCE -I/usr/local/include/libxml2 -c -o pg_crc32c_sse42.o pg_crc32c_sse42.c Using built-in specs. COLLECT_GCC=gcc Target: x86_64-pc-linux-gnu Configured with: ./configure --enable-threads=posix --enable-nls --enable-interpreter --with-system-zlib --enable-libgcj-multifile --enable-languages=all --enable-targets=all --with-system-unwind --without-x --with-linker-hash-style=gnu --disable-multilib --enable-shared --with-build-config='bootstrap-lto bootstrap-O3' Thread model: posix gcc version 7.3.1 20180316 (GCC) COLLECT_GCC_OPTIONS='-v' '-march=native' '-flto' '-I' '../../src/port' '-D' 'FRONTEND' '-I' '../../src/include' '-D' '_GNU_SOURCE' '-I' '/usr/local/include/libxml2' '-c' '-o' 'pg_crc32c_sse42.o' /usr/local/libexec/gcc/x86_64-pc-linux-gnu/7.3.1/cc1 -quiet -v -I ../../src/port -I ../../src/include -I /usr/local/include/libxml2 -imultiarch x86_64-linux-gnu -D FRONTEND -D _GNU_SOURCE pg_crc32c_sse42.c -march=nocona -mmmx -mno-3dnow -msse -msse2 -msse3 -mno-ssse3 -mno-sse4a -mcx16 -msahf -mno-movbe -mno-aes -mno-sha -mno-pclmul -mno-popcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-sgx -mno-bmi2 -mno-tbm -mno-avx -mno-avx2 -mno-sse4.2 -mno-sse4.1 -mno-lzcnt -mno-rtm -mno-hle -mno-rdrnd -mno-f16c -mno-fsgsbase -mno-rdseed -mno-prfchw -mno-adx -mfxsr -mno-xsave -mno-xsaveopt -mno-avx512f -mno-avx512er -mno-avx512cd -mno-avx512pf -mno-prefetchwt1 -mno-clflushopt -mno-xsavec -mno-xsaves -mno-avx512dq -mno-avx512bw -mno-avx512vl -mno-avx512ifma -mno-avx512vbmi -mno-avx5124fmaps -mno-avx5124vnniw -mno-clwb -mno-mwaitx -mno-clzero -mno-pku -mno-rdpid --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=4096 -mtune=nocona -quiet -dumpbase pg_crc32c_sse42.c -auxbase-strip pg_crc32c_sse42.o -version -flto -o /tmp/cch1CzQr.s GNU C11 (GCC) version 7.3.1 20180316 (x86_64-pc-linux-gnu) compiled by GNU C version 7.3.1 20180316, GMP version 6.1.2, MPFR version 4.0.0, MPC version 1.1.0, isl version isl-0.18-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu" ignoring nonexistent directory "/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../x86_64-pc-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: ../../src/port ../../src/include /usr/local/include/libxml2 /usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/include /usr/local/include /usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/include-fixed /usr/include/x86_64-linux-gnu /usr/include End of search list. GNU C11 (GCC) version 7.3.1 20180316 (x86_64-pc-linux-gnu) compiled by GNU C version 7.3.1 20180316, GMP version 6.1.2, MPFR version 4.0.0, MPC version 1.1.0, isl version isl-0.18-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: e97c32a4d3c4d8b00665455dd270ad26 In file included from /usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/include/nmmintrin.h:31:0, from pg_crc32c_sse42.c:19: pg_crc32c_sse42.c: In function ‘pg_comp_crc32c_sse42’: /usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/include/smmintrin.h:846:1: error: inlining failed in call to always_inline ‘_mm_crc32_u64’: target specific option mismatch _mm_crc32_u64 (unsigned long long __C, unsigned long long __V) ^ pg_crc32c_sse42.c:37:18: note: called from here crc = (uint32) _mm_crc32_u64(crc, *((const uint64 *) p)); ^ In file included from /usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/include/nmmintrin.h:31:0, from pg_crc32c_sse42.c:19: /usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/include/smmintrin.h:839:1: error: inlining failed in call to always_inline ‘_mm_crc32_u32’: target specific option mismatch _mm_crc32_u32 (unsigned int __C, unsigned int __V) ^ pg_crc32c_sse42.c:44:7: note: called from here crc = _mm_crc32_u32(crc, *((const unsigned int *) p)); ^ In file included from /usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/include/nmmintrin.h:31:0, from pg_cr
[Bug lto/84934] Installing the lto plugin where binutils will look for it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84934 --- Comment #4 from Дилян Палаузов --- Oh, I have typed on this matter already in the past: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70345
[Bug lto/84995] New: Documentation gcc-ar and gcc-ranlib vs {libdir}/bfd-plugins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84995
Bug ID: 84995
Summary: Documentation gcc-ar and gcc-ranlib vs
{libdir}/bfd-plugins
Product: gcc
Version: 7.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: dilyan.palauzov at aegee dot org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
While ar, ranlib and nm work with LTO, if the plugin is installed in
{libdir}/bfd-plugin, the gcc manual (Optimizing options) recommends the use of
gcc-ar and gcc-ranlib.
Why doesn't the manual recommend installing instead the plugin under
/bfd-plugin?
Providing that both gcc and clang offer LTO and provide linker plugins, none of
them installs by default the plugins under {libdir}/bfd-plugins, gcc recommends
the usage of gcc-ar/gcc-ranlib, clang installs instead clang-ar/clang-ranlib,
how are ./configure scripts supposed to be written in portable way to enable
LTO compilation?
If several gcc versions are installed on a system and hence
/usr/local/libexec/gcc/x86_64-pc-linux-gnu/7.3.1/liblto_plugin.so.0.0.0 and
/usr/local/libexec/gcc/x86_64-pc-linux-gnu/6.4.1/liblto_plugin.so.0.0.0
co-exist, will gcc-ar always use
/gcc/x86_64-pc-linux-gnu/6.4.1/liblto_plugin.so.0.0.0, if the code is compiled
with x86_64-pc-linux-gnu-gcc-6.4.1?
[Bug lto/84934] Installing the lto plugin where binutils will look for it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84934 --- Comment #3 from Дилян Палаузов --- For LLVM I filled the same request: https://bugs.llvm.org/show_bug.cgi?id=36802 .
[Bug lto/84934] Installing the lto plugin where binutils will look for it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84934 --- Comment #2 from Дилян Палаузов --- Builind a linux from scratch system, doing everywhere "./configure && make install" shall work, taking all defaults into account. For gcc+LTO+binutils this does not work. While distros can adjust the exact location, for binutils doing "./configure && make install" the location is "/usr/local/bin/bfd-plugins/", so with gcc's "./configure && make install " this location shall be used by default.
[Bug lto/84934] New: Installing the lto plugin where binutils will look for it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84934
Bug ID: 84934
Summary: Installing the lto plugin where binutils will look for
it
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: dilyan.palauzov at aegee dot org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
For the LTO prime time to arise, "gcc/Makefile install" shall put the
liblto_plugin in a place, where the ar/ranlib/nm tools load it. They load
search for plugins in the {libdir}/bfd-plugins directory.
Currently users detect in autoconf if they will do LTO, then switch
ar/nm/ranlib to gcc-ar/gcc-nm/gcc-ranlib in order to avoid dealing with the
--plugin and because they are unaware of the bfd-plugin directory. This is
unacceptable.
There are several options:
*) ar/nm/ranlib provide a mechanism to show the directory, where they look for
plugins, and gcc installs the plugins there,
*) ar/nm/ranlib ask gcc, clang and the other compilers where they have put
their plugins.
*) gcc and binutils mutually agree on a directory where the plugins are
installed and install/read the plugins there. Assuming that both gcc and
binutils share the same value for {libdir}, being it /usr/local/lib, or
/usr/lib64, gcc could install it in {libdir}/bfd-plugins, clang can do the same
for LLVMgold.so , and then binutils don't change, as they look for the files
there.
What speaks against the third option?
[Bug target/84926] error: inlining failed in call to always_inline ‘_mm_crc32_u64’: target specific option mismatch _mm_crc32_u64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84926 --- Comment #2 from Дилян Палаузов --- make -C src all make[1]: Entering directory '/git/postgresql/src' make -C common all make[2]: Entering directory '/git/postgresql/src/common' make -C ../backend submake-errcodes make[3]: Entering directory '/git/postgresql/src/backend' make[3]: Nothing to be done for 'submake-errcodes'. make[3]: Leaving directory '/git/postgresql/src/backend' make[2]: Leaving directory '/git/postgresql/src/common' make -C port all make[2]: Entering directory '/git/postgresql/src/port' make -C ../backend submake-errcodes make[3]: Entering directory '/git/postgresql/src/backend' make[3]: Nothing to be done for 'submake-errcodes'. make[3]: Leaving directory '/git/postgresql/src/backend' gcc -flto --verbose -I../../src/port -DFRONTEND -I../../src/include -D_GNU_SOURCE -I/usr/local/include/libxml2 -c -o pg_crc32c_sse42.o pg_crc32c_sse42.c Using built-in specs. COLLECT_GCC=gcc Target: x86_64-pc-linux-gnu Configured with: ./configure --enable-threads=posix --enable-nls --enable-interpreter --with-system-zlib --enable-libgcj-multifile --enable-languages=all --enable-targets=all --with-system-unwind --without-x --with-linker-hash-style=gnu --disable-multilib --enable-shared --with-build-config='bootstrap-lto bootstrap-O3' Thread model: posix gcc version 7.3.1 20180316 (GCC) COLLECT_GCC_OPTIONS='-flto' '-v' '-I' '../../src/port' '-D' 'FRONTEND' '-I' '../../src/include' '-D' '_GNU_SOURCE' '-I' '/usr/local/include/libxml2' '-c' '-o' 'pg_crc32c_sse42.o' '-mtune=generic' '-march=x86-64' /usr/local/libexec/gcc/x86_64-pc-linux-gnu/7.3.1/cc1 -quiet -v -I ../../src/port -I ../../src/include -I /usr/local/include/libxml2 -imultiarch x86_64-linux-gnu -D FRONTEND -D _GNU_SOURCE pg_crc32c_sse42.c -quiet -dumpbase pg_crc32c_sse42.c -mtune=generic -march=x86-64 -auxbase-strip pg_crc32c_sse42.o -version -flto -o /tmp/cce8jOUn.s GNU C11 (GCC) version 7.3.1 20180316 (x86_64-pc-linux-gnu) compiled by GNU C version 7.3.1 20180316, GMP version 6.1.2, MPFR version 4.0.0, MPC version 1.1.0, isl version isl-0.18-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu" ignoring nonexistent directory "/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../x86_64-pc-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: ../../src/port ../../src/include /usr/local/include/libxml2 /usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/include /usr/local/include /usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/include-fixed /usr/include/x86_64-linux-gnu /usr/include End of search list. GNU C11 (GCC) version 7.3.1 20180316 (x86_64-pc-linux-gnu) compiled by GNU C version 7.3.1 20180316, GMP version 6.1.2, MPFR version 4.0.0, MPC version 1.1.0, isl version isl-0.18-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: e97c32a4d3c4d8b00665455dd270ad26 In file included from /usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/include/nmmintrin.h:31:0, from pg_crc32c_sse42.c:19: pg_crc32c_sse42.c: In function ‘pg_comp_crc32c_sse42’: /usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/include/smmintrin.h:846:1: error: inlining failed in call to always_inline ‘_mm_crc32_u64’: target specific option mismatch _mm_crc32_u64 (unsigned long long __C, unsigned long long __V) ^ pg_crc32c_sse42.c:37:18: note: called from here crc = (uint32) _mm_crc32_u64(crc, *((const uint64 *) p)); ^ In file included from /usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/include/nmmintrin.h:31:0, from pg_crc32c_sse42.c:19: /usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/include/smmintrin.h:839:1: error: inlining failed in call to always_inline ‘_mm_crc32_u32’: target specific option mismatch _mm_crc32_u32 (unsigned int __C, unsigned int __V) ^ pg_crc32c_sse42.c:44:7: note: called from here crc = _mm_crc32_u32(crc, *((const unsigned int *) p)); ^ In file included from /usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/include/nmmintrin.h:31:0, from pg_crc32c_sse42.c:19: /usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/include/smmintrin.h:827:1: error: inlining failed in call to always_inline ‘_mm_crc32_u8’: target specific option mismatch _mm_crc32_u8 (unsigned int __C, unsigned char __V) ^~~~ pg_crc32c_sse42.c:63:7: note: called from here crc = _mm_crc32_u8(crc, *p); ^~~ make[2]: *** [: pg_crc32c_sse42.o] Error 1 make[2]: Leaving directory '/git/postgresql/src/port' make[1]: *** [Makefile:38: all-port-recurse] Error 2 make[1]: Leaving directory '/git/postgresql/src' make: *** [GNUmakefile:11: all-src-recurse] Error 2
[Bug lto/84926] New: error: inlining failed in call to always_inline ‘_mm_crc32_u64’: target specific option mismatch _mm_crc32_u64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84926 Bug ID: 84926 Summary: error: inlining failed in call to always_inline ‘_mm_crc32_u64’: target specific option mismatch _mm_crc32_u64 Product: gcc Version: 7.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: dilyan.palauzov at aegee dot org CC: marxin at gcc dot gnu.org Target Milestone: --- With the most current code of git://git.postgresql.org/git/postgresql.git, branch REL_10_STABLE, doing make maintainer-clean -j4; PYTHON=/usr/local/bin/python3.6 ./configure --prefix=/usr/local --with-perl --with-tcl --with-gssapi --with-ldap --with-openssl --with-libxml --with-libxslt --with-systemd --with-python --enable-cassert make CFLAGS="-flto" fails with make -C src all make[1]: Entering directory '/git/postgresql/src' make -C common all make[2]: Entering directory '/git/postgresql/src/common' make -C ../backend submake-errcodes make[3]: Entering directory '/git/postgresql/src/backend' make[3]: Nothing to be done for 'submake-errcodes'. make[3]: Leaving directory '/git/postgresql/src/backend' make[2]: Leaving directory '/git/postgresql/src/common' make -C port all make[2]: Entering directory '/git/postgresql/src/port' make -C ../backend submake-errcodes make[3]: Entering directory '/git/postgresql/src/backend' make[3]: Nothing to be done for 'submake-errcodes'. make[3]: Leaving directory '/git/postgresql/src/backend' gcc -flto -I../../src/port -DFRONTEND -I../../src/include -D_GNU_SOURCE -I/usr/local/include/libxml2 -c -o pg_crc32c_sse42.o pg_crc32c_sse42.c In file included from /usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/include/nmmintrin.h:31:0, from pg_crc32c_sse42.c:19: pg_crc32c_sse42.c: In function ‘pg_comp_crc32c_sse42’: /usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/include/smmintrin.h:846:1: error: inlining failed in call to always_inline ‘_mm_crc32_u64’: target specific option mismatch _mm_crc32_u64 (unsigned long long __C, unsigned long long __V) ^ pg_crc32c_sse42.c:37:18: note: called from here crc = (uint32) _mm_crc32_u64(crc, *((const uint64 *) p)); ^ In file included from /usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/include/nmmintrin.h:31:0, from pg_crc32c_sse42.c:19: /usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/include/smmintrin.h:839:1: error: inlining failed in call to always_inline ‘_mm_crc32_u32’: target specific option mismatch _mm_crc32_u32 (unsigned int __C, unsigned int __V) ^ pg_crc32c_sse42.c:44:7: note: called from here crc = _mm_crc32_u32(crc, *((const unsigned int *) p)); ^ In file included from /usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/include/nmmintrin.h:31:0, from pg_crc32c_sse42.c:19: /usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/include/smmintrin.h:827:1: error: inlining failed in call to always_inline ‘_mm_crc32_u8’: target specific option mismatch _mm_crc32_u8 (unsigned int __C, unsigned char __V) ^~~~ pg_crc32c_sse42.c:63:7: note: called from here crc = _mm_crc32_u8(crc, *p); ^~~ make[2]: *** [: pg_crc32c_sse42.o] Error 1 make[2]: Leaving directory '/git/postgresql/src/port' make[1]: *** [Makefile:38: all-port-recurse] Error 2 make[1]: Leaving directory '/git/postgresql/src' make: *** [GNUmakefile:11: all-src-recurse] Error 2 without -flto it works. I use gcc 7.3.1 20180316. With gcc 6.4.1 20180308 it also worked. I don't think this is relevant, but after switching 6->7 I have updated /usr/local/lib/bfd-plugin/liblto_plugin.so.0.0.0 to point to the new location.
[Bug inline-asm/84861] New: -flto with asm() optimizes too much
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84861
Bug ID: 84861
Summary: -flto with asm() optimizes too much
Product: gcc
Version: lto
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
Assignee: unassigned at gcc dot gnu.org
Reporter: dilyan.palauzov at aegee dot org
Target Milestone: ---
When compiling valgrind's coregrind/m_libcsetjmp.c
(https://sourceware.org/git/?p=valgrind.git;a=blob;f=coregrind/m_libcsetjmp.c)
with -lto the functions VG_MINIMAL_LONGJMP and VG_MINIMAL_SETJMP disappear on
amd64 from the coregrind/libcoregrind_amd64_linux_a-m_libcsetjmp.o file:
cd coregrind
WITH LTO:
$ make V=1 libcoregrind_amd64_linux_a-m_libcsetjmp.o
gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../include -I../include -I../VEX/pub
-I../VEX/pub -DVGA_amd64=1 -DVGO_linux=1 -DVGP_amd64_linux=1
-DVGPV_amd64_linux_vanilla=1 -I../coregrind
-DVG_LIBDIR="\"/usr/local/lib/valgrind"\" -DVG_PLATFORM="\"amd64-linux\"" -m64
-O2 -finline-functions -g -Wall -Wmissing-prototypes -Wshadow -Wpointer-arith
-Wstrict-prototypes -Wmissing-declarations -Wcast-align -Wcast-qual
-Wwrite-strings -Wempty-body -Wformat -Wformat-security -Wignored-qualifiers
-Wmissing-parameter-type -Wlogical-op -Wold-style-declaration
-fno-stack-protector -fno-strict-aliasing -fno-builtin -fomit-frame-pointer
-DENABLE_LINUX_TICKET_LOCK -flto -MT libcoregrind_amd64_linux_a-m_libcsetjmp.o
-MD -MP -MF .deps/libcoregrind_amd64_linux_a-m_libcsetjmp.Tpo -c -o
libcoregrind_amd64_linux_a-m_libcsetjmp.o `test -f 'm_libcsetjmp.c' || echo
'./'`m_libcsetjmp.c
mv -f .deps/libcoregrind_amd64_linux_a-m_libcsetjmp.Tpo
.deps/libcoregrind_amd64_linux_a-m_libcsetjmp.Po
$ nm libcoregrind_amd64_linux_a-m_libcsetjmp.o
nm: libcoregrind_amd64_linux_a-m_libcsetjmp.o: no symbols
(for the other coregrind/libcoregrind_amd64_linux_a-*.o files `nm` shows
exported symbols).
WITHOUT LTO:
$ make V=1 libcoregrind_amd64_linux_a-m_libcsetjmp.o
gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../include -I../include -I../VEX/pub
-I../VEX/pub -DVGA_amd64=1 -DVGO_linux=1 -DVGP_amd64_linux=1
-DVGPV_amd64_linux_vanilla=1 -I../coregrind
-DVG_LIBDIR="\"/usr/local/lib/valgrind"\" -DVG_PLATFORM="\"amd64-linux\"" -m64
-O2 -finline-functions -g -Wall -Wmissing-prototypes -Wshadow -Wpointer-arith
-Wstrict-prototypes -Wmissing-declarations -Wcast-align -Wcast-qual
-Wwrite-strings -Wempty-body -Wformat -Wformat-security -Wignored-qualifiers
-Wmissing-parameter-type -Wlogical-op -Wold-style-declaration
-fno-stack-protector -fno-strict-aliasing -fno-builtin -fomit-frame-pointer
-DENABLE_LINUX_TICKET_LOCK -MT libcoregrind_amd64_linux_a-m_libcsetjmp.o
-MD -MP -MF .deps/libcoregrind_amd64_linux_a-m_libcsetjmp.Tpo -c -o
libcoregrind_amd64_linux_a-m_libcsetjmp.o `test -f 'm_libcsetjmp.c' || echo
'./'`m_libcsetjmp.c
mv -f .deps/libcoregrind_amd64_linux_a-m_libcsetjmp.Tpo
.deps/libcoregrind_amd64_linux_a-m_libcsetjmp.Po
$ nm libcoregrind_amd64_linux_a-m_libcsetjmp.o
0052 T VG_MINIMAL_LONGJMP
T VG_MINIMAL_SETJMP
The only difference is "-flto".
It this a problem of LTO, or is the assembler supposed to be tweaked (how?) so
that the symbols get exported?
Having a file containing
asm ("");
does compile, but a file containing only:
asm volatile ("");
fails with "error: expected ‘(’ before ‘volatile’".
Happens with gcc 8.0.1 20180306 (experimental).
[Bug c/82088] New: Implicit conversion "const char *x=" to "const char x[sizeof(...)]="
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82088 Bug ID: 82088 Summary: Implicit conversion "const char *x=" to "const char x[sizeof(...)]=" Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dilyan.palauzov at aegee dot org Target Milestone: --- $ cat a.c const char * const a = "ABCD"; const char b[5] = "EFGH"; $ gcc -O3 -o a.o -c a.c && nm a.o 0008 R a R b $ gcc -fPIC -O3 -o a.o -c a.c && nm a.o D a R b Why doesn't gcc for PIC convert implicitly "const char *x=" to "const char x[sizeof(...)]=" in order to create more read-only data?
[Bug bootstrap/69790] LTO compiling GCC does not work (lib/bfd-plugin path has unclear location)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69790 --- Comment #4 from Дилян Палаузов --- I don't know precisely what I did a year ago. --prefix was either /usr or /usr/local. Nowadays, the documentation of "ld -plugin" and "nm --plugin" state, both tools use by default different paths to find the same file, so I have a symlink between /usr/local/lib/bfd-plugins/ and /usr/local/x86_64-unknown-linux-gnu/lib/bfd-plugins . Despite of this, for gcc 8 doing CFLAGS="-pipe -Wall -Wextra -O3 -fno-fat-lto-objects -flto" CXXFLAGS="-pipe -Wall -Wextra -O3 -fno-fat-lto-objects -flto" LDFLAGS="-Wl,-O1,-s -flto=12" ./configure --enable-host-shared --enable-threads=posix --enable-targets=all --enable-nls --with-linker-hash-style=gnu --with-system-zlib --disable-multilib --enable-languages=c,c++,jit,lto when compiled with 8.0.0 20170427, fails at stage1 with make[5]: Nothing to be done for 'all'. make[5]: Leaving directory '/git/gcc/x86_64-pc-linux-gnu/libgomp/testsuite' make[5]: Entering directory '/git/gcc/x86_64-pc-linux-gnu/libgomp' /bin/bash ./libtool --tag=CC --mode=compile /git/gcc/host-x86_64-pc-linux-gnu/gcc/xgcc -B/git/gcc/host-x86_64-pc-linux-gnu/gcc/ -B/usr/local/x86_64-pc-linux-gnu/bin/ -B/usr/local/x86_64-pc-linux-gnu/lib/ -isystem /usr/local/x86_64-pc-linux-gnu/include -isystem /usr/local/x86_64-pc-linux-gnu/sys-include-DHAVE_CONFIG_H -I. -I../.././libgomp -I../.././libgomp/config/linux/x86 -I../.././libgomp/config/linux -I../.././libgomp/config/posix -I../.././libgomp -I../.././libgomp/../include -Wall -Werror -ftls-model=initial-exec -Wc,-pthread -g -O2 -pipe -Wall -Wextra -O3 -fno-fat-lto-objects -flto -MT alloc.lo -MD -MP -MF .deps/alloc.Tpo -c -o alloc.lo ../.././libgomp/alloc.c libtool: compile: /git/gcc/host-x86_64-pc-linux-gnu/gcc/xgcc -B/git/gcc/host-x86_64-pc-linux-gnu/gcc/ -B/usr/local/x86_64-pc-linux-gnu/bin/ -B/usr/local/x86_64-pc-linux-gnu/lib/ -isystem /usr/local/x86_64-pc-linux-gnu/include -isystem /usr/local/x86_64-pc-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I../.././libgomp -I../.././libgomp/config/linux/x86 -I../.././libgomp/config/linux -I../.././libgomp/config/posix -I../.././libgomp -I../.././libgomp/../include -Wall -Werror -pthread -ftls-model=initial-exec -g -O2 -pipe -Wall -Wextra -O3 -fno-fat-lto-objects -flto -MT alloc.lo -MD -MP -MF .deps/alloc.Tpo -c ../.././libgomp/alloc.c -fPIC -DPIC -o .libs/alloc.o In file included from ../.././libgomp/libgomp.h:123:0, from ../.././libgomp/alloc.c:30: ../.././libgomp/priority_queue.h: In function ‘priority_queue_free’: ../.././libgomp/priority_queue.h:161:45: error: unused parameter ‘head’ [-Werror=unused-parameter] priority_queue_free (struct priority_queue *head) ^~~~ ../.././libgomp/priority_queue.h: In function ‘priority_list_insert’: ../.././libgomp/priority_queue.h:240:13: error: unused parameter ‘priority’ [-Werror=unused-parameter] int priority, ^~~~ In file included from ../.././libgomp/libgomp.h:124:0, from ../.././libgomp/alloc.c:30: ../.././libgomp/config/linux/sem.h: In function ‘gomp_sem_destroy’: ../.././libgomp/config/linux/sem.h:52:31: error: unused parameter ‘sem’ [-Werror=unused-parameter] gomp_sem_destroy (gomp_sem_t *sem) ^~~ In file included from ../.././libgomp/libgomp.h:125:0, from ../.././libgomp/alloc.c:30: ../.././libgomp/config/linux/mutex.h: In function ‘gomp_mutex_destroy’: ../.././libgomp/config/linux/mutex.h:47:35: error: unused parameter ‘mutex’ [-Werror=unused-parameter] gomp_mutex_destroy (gomp_mutex_t *mutex) ^ In file included from ../.././libgomp/libgomp.h:126:0, from ../.././libgomp/alloc.c:30: ../.././libgomp/config/linux/bar.h: In function ‘gomp_barrier_destroy’: ../.././libgomp/config/linux/bar.h:70:58: error: unused parameter ‘bar’ [-Werror=unused-parameter] static inline void gomp_barrier_destroy (gomp_barrier_t *bar) ^~~ In file included from ../.././libgomp/libgomp.h:128:0, from ../.././libgomp/alloc.c:30: ../.././libgomp/config/linux/ptrlock.h: In function ‘gomp_ptrlock_destroy’: ../.././libgomp/config/linux/ptrlock.h:72:58: error: unused parameter ‘ptrlock’ [-Werror=unused-parameter] static inline void gomp_ptrlock_destroy (gomp_ptrlock_t *ptrlock) ^~~ In file included from ../.././libgomp/alloc.c:30:0: ../.././libgomp/libgomp.h: At top level: ../.././libgomp/libgomp.h:774:1: error: ‘inline’ is not at beginning of declaration [-Werror=old-style-declaration] static void inline ^~ cc1: all warnings being treated as errors make[5]: *** [Makefile:659: alloc.lo] Error 1 make[5]: Leaving directory '/git/gcc/x86_64-pc-linux-gnu/libgomp' make[4]: *** [Makefile:904: all-recursive] Error 1 make[4]: Leaving directory '/git/gcc/x86_64-
[Bug plugins/80514] New: --enable-plugin and config/gcc-plugin.m4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80514 Bug ID: 80514 Summary: --enable-plugin and config/gcc-plugin.m4 Product: gcc Version: 6.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: plugins Assignee: unassigned at gcc dot gnu.org Reporter: dilyan.palauzov at aegee dot org Target Milestone: --- config/plugins.m4 is written in such a way, that the plugins are enabled, whenever dlfcn.h or windows.h are found, even when --enable-plugins was not specified. So the default is to enable plugins, whenever possible, but to disable plugins, even when --enable-plugins is enforced but the mentioned headers are missing. Under these circumstances ./configure --help shall print --disable-plugin disable plugin support to indicate that the user has to take only action, when she wants to disable plugins. config/gcc-plugin.m4 also tries to enable plugins by default, if --enable-plugins was not explicitly provided. The line "enable_plugin=$enableval," is not necessary, as this is the default ACTION-IF-GIVEN, just put two consecutive commas to At https://gcc.gnu.org/install/configure.html the option --enable-plugin is not mentioned.
[Bug lto/80407] --as-needed cannot be combined with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80407 Дилян Палаузов changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |MOVED --- Comment #3 from Дилян Палаузов --- Moved to https://sourceware.org/bugzilla/show_bug.cgi?id=21382 .
[Bug lto/80407] New: --as-needed cannot be combined with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80407 Bug ID: 80407 Summary: --as-needed cannot be combined with -flto Product: gcc Version: 6.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: dilyan.palauzov at aegee dot org Target Milestone: --- Created attachment 41185 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41185&action=edit Sample With the attached package I do ./configure and make clean && make LDFLAGS="-Wl,--as-needed" && ./m -- works, prints x make clean && CFLAGS="-flto" make && ./m -- works, prints x make clean && make CFLAGS="-flto" LDFLAGS="-Wl,--as-needed" && ./m -- does not work, prints x-0.libs/lt-m: symbol lookup error: x-0/.libs/libx.so.0: undefined symbol: x Why doesn't --as-needed work with LTO? It happens when I use GNU ld (GNU Binutils) 2.28.51.20170411 with either GCC 7.0.1 20170411 or GCC 6.3.1 20170329.
[Bug lto/79181] New: Not deleting /tmp/cc*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79181 Bug ID: 79181 Summary: Not deleting /tmp/cc* Product: gcc Version: 6.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: dilyan.palauzov at aegee dot org Target Milestone: --- When the linking process is interrupted, some files of the form /tmp/cc?? or /tmp/cc??.ltrans?.o are left. These files shall be deleted when the linker terminates, even if it has been interrupted.
[Bug lto/67111] ld -plugin segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67111 --- Comment #2 from Дилян Палаузов --- I do not have the environment anymore.
[Bug lto/70345] Installing liblto_plugin under $LIBDIR/bfd-plugins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70345 --- Comment #3 from Дилян Палаузов --- Am I correct if I say, that the gcc plugin is backward compatible: the plugin from the newest gcc can be used with any gcc but not vice versa? How do nm and ar determine, if a plugin shall be used, for instance when `nm test.o` is called?
[Bug ipa/71015] [7 Regression] ICE in inline_small_functions, at ipa-inline.c:1881
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71015 Дилян Палаузов changed: What|Removed |Added CC||dilyan.palauzov at aegee dot org --- Comment #4 from Дилян Палаузов --- Probably the same problem in a different case: gcc (GCC) 7.0.0 20160513 (experimental) Copyright (C) 2016 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. I try to compile wxWidgets-3.0.1: /src/wxWidgets-3.1.0/bk-deps g++ -c -o coredll_gtk_choice.o -I./.pch/wxprec_coredll -D__WXGTK__ -DWXBUILDING -I/src/wxWidgets-3.1.0/src/tiff/libtiff -I./src/tiff/libtiff -I./src/jpeg -I./src/regex -DWXUSINGDLL -DWXMAKINGDLL_CORE -DwxUSE_BASE=0 -fPIC -DPIC -Wall -Wundef -Wunused-parameter -Wno-ctor-dtor-privacy -Woverloaded-virtual -Wno-deprecated-declarations -D_FILE_OFFSET_BITS=64 -I/src/wxWidgets-3.1.0/lib/wx/include/gtk3-unicode-3.1 -I./include -pthread -I/usr/local/include/gio-unix-2.0/ -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include -I/usr/include/gtk-3.0 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -I/usr/include/gtk-3.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng12 -DWX_PRECOMP -pthread -pthread -I/usr/local/include/gio-unix-2.0/ -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include -I/usr/include/gtk-3.0/unix-print -I/usr/include/gtk-3.0 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -I/usr/include/gtk-3.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng12 -pipe -O3 -fvisibility=hidden -fvisibility-inlines-hidden ./src/gtk/choice.cpp ./src/gtk/choice.cpp:375:1: internal compiler error: in inline_small_functions, at ipa-inline.c:1881 } ^ DWARF underflow in .debug_info at 4 unrecognized DWARF version in .debug_info at 4 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. Makefile:28498: recipe for target 'coredll_gtk_choice.o' failed make: *** [coredll_gtk_choice.o] Error 1
[Bug lto/70611] New: Compiling binutils with -flto -Wstack-usage fails.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70611 Bug ID: 70611 Summary: Compiling binutils with -flto -Wstack-usage fails. Product: gcc Version: 5.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: dilyan.palauzov at aegee dot org Target Milestone: --- After binutils introduced passing -Wstack-usgage when compiling gas (https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=9780e045073b1719a7a4c6cbe00e4aa7525bd180), it does not compile anymore with -flto: export CFLAGS="-pipe -O3 -fno-fat-lto-objects -flto" export CXXFLAGS="-pipe -O3 -fno-fat-lto-objects -flto" export LDFLAGS="-Wl,-O1,-z,relro,-s" /git/binutils-gdb/gas/configure --with-system-zlib --enable-lto --enable-threads --with-system-zlib --enable-compressed-debug-sections=none make [...] make[2]: Entering directory '/root/binutils/gas' /bin/bash ./libtool --tag=CC --mode=link gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Wstack-usage=262144 -Werror -Wwrite-strings -pipe -O3 -fno-fat-lto-objects -flto -Wl,-O1,-z,relro,-s -flto=8 -L/lib64 -o as-new app.o as.o atof-generic.o compress-debug.o cond.o depend.o dwarf2dbg.o dw2gencfi.o ecoff.o ehopt.o expr.o flonum-copy.o flonum-konst.o flonum-mult.o frags.o hash.o input-file.o input-scrub.o listing.o literal.o macro.o messages.o output-file.o read.o remap.o sb.o stabs.o subsegs.o symbols.o write.o tc-i386.o obj-elf.o atof-ieee.o ../opcodes/libopcodes.la ../bfd/libbfd.la ../libiberty/libiberty.a -ldl libtool: link: gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Wstack-usage=262144 -Werror -Wwrite-strings -pipe -O3 -fno-fat-lto-objects -flto -Wl,-O1 -Wl,-z -Wl,relro -Wl,-s -flto=8 -o as-new app.o as.o atof-generic.o compress-debug.o cond.o depend.o dwarf2dbg.o dw2gencfi.o ecoff.o ehopt.o expr.o flonum-copy.o flonum-konst.o flonum-mult.o frags.o hash.o input-file.o input-scrub.o listing.o literal.o macro.o messages.o output-file.o read.o remap.o sb.o stabs.o subsegs.o symbols.o write.o tc-i386.o obj-elf.o atof-ieee.o -L/lib64 ../opcodes/.libs/libopcodes.a ../bfd/.libs/libbfd.a -lz ../libiberty/libiberty.a -ldl /git/binutils-gdb/libiberty/make-relative-prefix.c: In function 'make_relative_prefix_1.constprop': /git/binutils-gdb/libiberty/make-relative-prefix.c:228:1: error: stack usage might be unbounded [-Werror=stack-usage=] make_relative_prefix_1 (const char *progname, const char *bin_prefix, ^ lto1: all warnings being treated as errors make[3]: *** [/tmp/ccGFedJA.ltrans24.ltrans.o] Error 1 make[3]: *** Waiting for unfinished jobs lto-wrapper: fatal error: make returned 2 exit status compilation terminated. /usr/local/bin/ld: error: lto-wrapper failed collect2: error: ld returned 1 exit status Makefile:769: recipe for target 'as-new' failed make[2]: *** [as-new] Error 1 make[2]: Leaving directory '/root/binutils/gas' I use gcc (GCC) 5.3.1 20160407 and in /usr/local and have symlink /usr/local/lib/bfd-plugins/liblto_plugin.so -> /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/5.3.1/liblto_plugin.so . This happens also when compiling ld.bfd, gprof, binutils/size . I guess the problem is not in binutils, as it fails in libiberty, which comes from gcc. I fails also when I replace libiberty bundled with binutils/master with libiberty comming with gcc/gcc-5-branch .
[Bug lto/70345] New: Installing liblto_plugin under $LIBDIR/bfd-plugins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70345 Bug ID: 70345 Summary: Installing liblto_plugin under $LIBDIR/bfd-plugins Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: dilyan.palauzov at aegee dot org Target Milestone: --- During "make install" please put liblto_plugin.so under $LIBDIR/bfd-plugins, so that ar and ranlib can find the plugin (e.g. when they are invoked from libtool) and operate on lto files.
[Bug bootstrap/70200] builing gcc with -lfto without libunwind
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70200 --- Comment #1 from Дилян Палаузов --- I was wrong, having libunwind, with --enable-cxx-exceptions, thus exporting _Unwind_Resume(), does not help in any way.
[Bug bootstrap/70200] New: builing gcc with -lfto without libunwind
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70200 Bug ID: 70200 Summary: builing gcc with -lfto without libunwind Product: gcc Version: 5.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: dilyan.palauzov at aegee dot org Target Milestone: --- I have the newest gcc-5 (commit e0f9303ca2e71). In my /etc/config.site is written: export CFLAGS="-pipe -O3 -fno-fat-lto-objects -flto" export CXXFLAGS="-pipe -O3 -fno-fat-lto-objects -flto" export enable_silent_rules=yes export LDFLAGS="-Wl,-z,relro,-O1,-s -flto=24" I use binutils 2.26.51.20160310 (ld.bfd, gas, etc). Then I do: /git/gcc/configure --enable-host-shared --enable-threads=posix --with-arch=haswell --enable-targets=all --enable-nls --with-linker-hash-style=gnu --with-system-zlib --disable-multilib --enable-languages=c,c++,jit,lto and at stage_current=stage_last=2 I get "undefined reference to `_Unwind_Resume'", as listed below. Please update the documentation under INSTALL, that in order to avoid this problem, libunwind has to be installed and configured with "./configure --enable-cxx-exceptions". Not passing "-fno-fat-lto-objects -flto" to CFLAGS/CXXFLAGS does not show the problem, even if libunwind is not installed. [ -f stage_final ] || echo stage3 > stage_final make[1]: Entering directory '/home/d/gcc' make[2]: Entering directory '/home/d/gcc' make[3]: Entering directory '/home/d/gcc' rm -f stage_current make[3]: Leaving directory '/home/d/gcc' make[2]: Leaving directory '/home/d/gcc' make[2]: Entering directory '/home/d/gcc' make[3]: Entering directory '/home/d/gcc/libiberty' make[4]: Entering directory '/home/d/gcc/libiberty/testsuite' make[4]: Nothing to be done for 'all'. make[4]: Leaving directory '/home/d/gcc/libiberty/testsuite' make[3]: Leaving directory '/home/d/gcc/libiberty' make[3]: Entering directory '/home/d/gcc/lto-plugin' make all-am make[4]: Entering directory '/home/d/gcc/lto-plugin' make[4]: Leaving directory '/home/d/gcc/lto-plugin' make[3]: Leaving directory '/home/d/gcc/lto-plugin' make[3]: Entering directory '/home/d/gcc/intl' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/home/d/gcc/intl' make[3]: Entering directory '/home/d/gcc/build-x86_64-unknown-linux-gnu/libiberty' make[4]: Entering directory '/home/d/gcc/build-x86_64-unknown-linux-gnu/libiberty/testsuite' make[4]: Nothing to be done for 'all'. make[4]: Leaving directory '/home/d/gcc/build-x86_64-unknown-linux-gnu/libiberty/testsuite' make[3]: Leaving directory '/home/d/gcc/build-x86_64-unknown-linux-gnu/libiberty' make[3]: Entering directory '/home/d/gcc/build-x86_64-unknown-linux-gnu/fixincludes' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/home/d/gcc/build-x86_64-unknown-linux-gnu/fixincludes' make[3]: Entering directory '/home/d/gcc/build-x86_64-unknown-linux-gnu/libcpp' make[3]: Leaving directory '/home/d/gcc/build-x86_64-unknown-linux-gnu/libcpp' make[3]: Entering directory '/home/d/gcc/libbacktrace' make all-am make[4]: Entering directory '/home/d/gcc/libbacktrace' true DO=all multi-do # make make[4]: Leaving directory '/home/d/gcc/libbacktrace' make[3]: Leaving directory '/home/d/gcc/libbacktrace' make[3]: Entering directory '/home/d/gcc/libcpp' test -f config.h || (rm -f stamp-h1 && make stamp-h1) make[3]: Leaving directory '/home/d/gcc/libcpp' make[3]: Entering directory '/home/d/gcc/libdecnumber' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/home/d/gcc/libdecnumber' make[3]: Entering directory '/home/d/gcc/gcc' make[3]: Leaving directory '/home/d/gcc/gcc' Checking multilib configuration for libgcc... make[3]: Entering directory '/home/d/gcc/x86_64-unknown-linux-gnu/libgcc' # If this is the top-level multilib, build all the other # multilibs. # Early copyback; see "all" above for the rationale. The # early copy is necessary so that the gcc -B options find # the right startup files when linking shared libgcc. /bin/bash /git/gcc/libgcc/../mkinstalldirs ../.././gcc parts="crtbegin.o crtbeginS.o crtbeginT.o crtend.o crtendS.o crtprec32.o crtprec64.o crtprec80.o crtfastmath.o"; \ for file in $parts; do \ rm -f ../.././gcc/$file; \ /usr/local/bin/install -c -m 644 $file ../.././gcc/; \ case $file in
[Bug bootstrap/70173] New: make distclean: leaves stage_final and libcc1/compiler-name.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70173
Bug ID: 70173
Summary: make distclean: leaves stage_final and
libcc1/compiler-name.h
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: dilyan.palauzov at aegee dot org
Target Milestone: ---
make distclean
leaves these files:
./stage_final
./libcc1
./libcc1/compiler-name.h
and prints:
make[1]: Entering directory '/home/d/gcc'
rm -f stage_current
make[1]: Leaving directory '/home/d/gcc'
rm -rf stage1-*
rm -rf stage2-*
rm -rf stage3-* compare
cat: stage_last: No such file or directory
rm -rf stage4-* compare3
cat: stage_last: No such file or directory
rm -rf stageprofile-*
cat: stage_last: No such file or directory
rm -rf stagefeedback-*
make[1]: Entering directory '/home/d/gcc'
Doing distclean in libcc1
make[2]: Entering directory '/home/d/gcc/libcc1'
test -z "libcc1.la" || rm -f libcc1.la
rm -f "./so_locations"
rm -rf .libs _libs
test -z "libcc1plugin.la" || rm -f libcc1plugin.la
rm -f "./so_locations"
rm -f *.o
rm -f *.lo
rm -f *.tab.c
test -z "" || rm -f
test . = "/git/gcc/libcc1" || test -z "" || rm -f
rm -f cc1plugin-config.h stamp-h1
rm -f libtool config.lt
rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
rm -f config.status config.cache config.log configure.lineno
config.status.lineno
rm -rf ./.deps
rm -f Makefile
make[2]: Leaving directory '/home/d/gcc/libcc1'
make[1]: Leaving directory '/home/d/gcc'
rm -f *.a TEMP errs core *.o *~ \#* TAGS *.E *.log
rm -f Makefile config.status config.cache mh-frag mt-frag
rm -f maybedep.tmp serdep.tmp
if [ "x86_64-pc-linux-gnu" != "." ]; then \
rm -rf x86_64-pc-linux-gnu; \
else true; fi
rm -rf build-x86_64-pc-linux-gnu
if [ "." != "." ]; then \
rm -rf .; \
else true; fi
rm -f texinfo/po/Makefile texinfo/po/Makefile.in texinfo/info/Makefile
rm -f texinfo/doc/Makefile texinfo/po/POTFILES
rmdir texinfo/doc texinfo/info texinfo/intl texinfo/lib 2>/dev/null
Makefile:2159: recipe for target 'local-distclean' failed
make: [local-distclean] Error 1 (ignored)
rmdir texinfo/makeinfo texinfo/po texinfo/util 2>/dev/null
Makefile:2159: recipe for target 'local-distclean' failed
make: [local-distclean] Error 1 (ignored)
rmdir fastjar gcc libiberty texinfo zlib 2>/dev/null
Makefile:2159: recipe for target 'local-distclean' failed
make: [local-distclean] Error 1 (ignored)
find . -name config.cache -exec rm -f {} \; \; 2>/dev/null
Makefile:2159: recipe for target 'local-distclean' failed
make: [local-distclean] Error 1 (ignored)
[Bug bootstrap/69791] ICE in ultimate_transparent_alias_target, at varasm.c:1263
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69791 --- Comment #2 from Дилян Палаузов --- (In reply to Richard Biener from comment #1) > How did you configure and call make? FLAGS as mentioned. /git/gcc/configure --enable-host-shared --enable-threads=posix --with-arch=haswell --enable-__cxa_atexit --enable-targets=all --enable-nls --with-linker-hash-style=gnu --with-system-zlib --disable-multilib --enable-languages=c,c++,jit,lto make In addition, liblto used is the one provided by gcc 6, which I compiled some days ago.
[Bug bootstrap/69791] New: ICE in ultimate_transparent_alias_target, at varasm.c:1263
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69791 Bug ID: 69791 Summary: ICE in ultimate_transparent_alias_target, at varasm.c:1263 Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: dilyan.palauzov at aegee dot org Target Milestone: --- When I try to pass -flto gcc from is compiled (most recent version from git), I get the following error: export GCC=yes export enable_static=no export enable_shared=yes export CFLAGS="-pipe -O3 -fno-fat-lto-objects -flto" export CXXFLAGS="-pipe -O3 -fno-fat-lto-objects -flto" export LDFLAGS="-Wl,-O1,-z,relro,-s -flto=4 -L/lib64" export enable_silent_rules=yes [ -f stage_final ] || echo stage3 > stage_final make[1]: Entering directory '/home/d/gcc' make[2]: Entering directory '/home/d/gcc' make[3]: Entering directory '/home/d/gcc' rm -f stage_current make[3]: Leaving directory '/home/d/gcc' make[2]: Leaving directory '/home/d/gcc' make[2]: Entering directory '/home/d/gcc' make[3]: Entering directory '/home/d/gcc/libiberty' make[4]: Entering directory '/home/d/gcc/libiberty/testsuite' make[4]: Nothing to be done for 'all'. make[4]: Leaving directory '/home/d/gcc/libiberty/testsuite' make[3]: Leaving directory '/home/d/gcc/libiberty' make[3]: Entering directory '/home/d/gcc/lto-plugin' make all-am make[4]: Entering directory '/home/d/gcc/lto-plugin' make[4]: Leaving directory '/home/d/gcc/lto-plugin' make[3]: Leaving directory '/home/d/gcc/lto-plugin' make[3]: Entering directory '/home/d/gcc/intl' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/home/d/gcc/intl' make[3]: Entering directory '/home/d/gcc/build-x86_64-pc-linux-gnu/libiberty' make[4]: Entering directory '/home/d/gcc/build-x86_64-pc-linux-gnu/libiberty/testsuite' make[4]: Nothing to be done for 'all'. make[4]: Leaving directory '/home/d/gcc/build-x86_64-pc-linux-gnu/libiberty/testsuite' make[3]: Leaving directory '/home/d/gcc/build-x86_64-pc-linux-gnu/libiberty' make[3]: Entering directory '/home/d/gcc/build-x86_64-pc-linux-gnu/fixincludes' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/home/d/gcc/build-x86_64-pc-linux-gnu/fixincludes' make[3]: Entering directory '/home/d/gcc/build-x86_64-pc-linux-gnu/libcpp' test -f config.h || (rm -f stamp-h1 && make stamp-h1) make[3]: Leaving directory '/home/d/gcc/build-x86_64-pc-linux-gnu/libcpp' make[3]: Entering directory '/home/d/gcc/libbacktrace' make all-am make[4]: Entering directory '/home/d/gcc/libbacktrace' true DO=all multi-do # make make[4]: Leaving directory '/home/d/gcc/libbacktrace' make[3]: Leaving directory '/home/d/gcc/libbacktrace' make[3]: Entering directory '/home/d/gcc/libcpp' test -f config.h || (rm -f stamp-h1 && make stamp-h1) make[3]: Leaving directory '/home/d/gcc/libcpp' make[3]: Entering directory '/home/d/gcc/libdecnumber' make[3]: Nothing to be done for 'all'. make[3]: Leaving directory '/home/d/gcc/libdecnumber' make[3]: Entering directory '/home/d/gcc/gcc' make[3]: Leaving directory '/home/d/gcc/gcc' Checking multilib configuration for libgcc... make[3]: Entering directory '/home/d/gcc/x86_64-pc-linux-gnu/libgcc' # If this is the top-level multilib, build all the other # multilibs. # Early copyback; see "all" above for the rationale. The # early copy is necessary so that the gcc -B options find # the right startup files when linking shared libgcc. /bin/bash /git/gcc/libgcc/../mkinstalldirs ../.././gcc parts="crtbegin.o crtbeginS.o crtbeginT.o crtend.o crtendS.o crtprec32.o crtprec64.o crtprec80.o crtfastmath.o";\ for file in $parts; do \ rm -f ../.././gcc/$file; \ /usr/local/bin/install -c -m 644 $file ../.././gcc/; \ case $file in \ *.a)\ /usr/local/x86_64-pc-linux-gnu/bin/ranlib ../.././gcc/$file ;;\ esac; \ done # @multilib_flags@ is still needed because this may use # /home/d/gcc/./gcc/xgcc -B/home/d/gcc/./gcc/ -B/usr/local/x86_64-pc-linux-gnu/bin/ -B/usr/local/x86_64-pc-linux-gnu/lib/ -isystem /usr/local/x86_64-pc-linux-gnu/include -isystem /usr/local/x86_64-pc-linux-gnu/sys-includeand -O2 -g -O2 -pipe -O3 -fno-fat-lto-objects -flto -DIN_GCC -fPIC -W -Wall -Wno-narrowing
[Bug bootstrap/69790] New: LTO compiling GCC does not work (lib/bfd-plugin path has unclear location)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69790 Bug ID: 69790 Summary: LTO compiling GCC does not work (lib/bfd-plugin path has unclear location) Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: dilyan.palauzov at aegee dot org Target Milestone: --- On my system, when I compile gcc using -flto -O3 (meaning LTO is applied to the compiler) I face the problem, that liblto_plugin.so on my system is installed under /usr/local/lib/bfd-plugins , where binutils accepts it. But nm compiled during bootstrapping gcc looks for the plugins under /usr/local/x86_64-pc-linux-gnu/lib/bfd-plugins . nm compiled as part of binutils and as part of gcc should look at the same location for gcc plugins.
[Bug lto/67157] Compiling gcc6 with liblto_plugin, v5.2.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67157 --- Comment #2 from Дилян Палаузов --- I have retried with the most current gcc code. The problem is not solved.
[Bug c/67255] -Wpadded mixes apostrophes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67255 Дилян Палаузов changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #6 from Дилян Палаузов --- Indeed, the problem is not in GCC. Updating libtool 2.4.2 -> 2.4.6 solved the problem.
[Bug c/67255] -Wpadded mixes apostrophes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67255 --- Comment #2 from Дилян Палаузов --- git clone https://cgit.cyrus.foundation/cyrus-imapd cd cyrus-imapd libtoolize autoreconf -i CFLAGS="-Wpadded" ./configure --with-sqlite make 2>&1 | grep righ | sort -u prints: imap/append.h:62:9: warning: padding struct to align 'myrights' [-Wpadded] imap/append.h:62:9: warning: padding struct to align ‘myrights’ [-Wpadded] int myrights;
[Bug c/67255] New: -Wpadded mixes apostrophes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67255 Bug ID: 67255 Summary: -Wpadded mixes apostrophes Product: gcc Version: 5.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dilyan.palauzov at aegee dot org Target Milestone: --- gcc -Wpadded produces output like: file.h:10:3: warning: padding struct to align 'z' [-Wpadded] and like file.h:10:3: warning: padding struct to align ‘z’ [-Wpadded] note the different apostrophe styles around z. When I try to compile a project with -Wpadded, I filter stderr through "sort -u", but some lines appear twice, because of the different apostrophes used by gcc.
[Bug bootstrap/67156] config/bootstrap-debug.mk: STAGE2_CFLAGS += -gtoggle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67156
Дилян Палаузов changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |---
--- Comment #5 from Дилян Палаузов ---
If do-compare in /Makefile.in is substituted with "$(SHELL)
$(srcdir)/contrib/compare-debug $$f1 $$f2" from "config/bootstrap-debug-big.mk"
or "config/bootstrap-debug-lib.mk" or "config/bootstrap-debug.mk", then
comparing files ignores debug information. However in my case, do-compare is
substituted with "cmp --ignore-initial=16 $$f1 $$f2" from config/acx.m4 .
Effectively the latter executes
gcc_cv_prog_cmp_skip='cmp --ignore-initial=16 $$f1 $$f2'
and ./configure contains:
configure-5349-
configure-5350-
configure-5351-$as_echo_n "checking how to compare bootstrapped objects... "
>&6; }
configure:5352:if test "${gcc_cv_prog_cmp_skip+set}" = set; then :
configure-5353- $as_echo_n "(cached) " >&6
configure-5354-else
configure-5355- echo abfoo >t1
configure-5356- echo cdfoo >t2
configure:5357: gcc_cv_prog_cmp_skip='tail +16c $$f1 > tmp-foo1; tail +16c
$$f2 > tmp-foo2; cmp tmp-foo1 tmp-foo2'
configure-5358- if cmp t1 t2 2 2 > /dev/null 2>&1; then
configure-5359-if cmp t1 t2 1 1 > /dev/null 2>&1; then
configure-5360- :
configure-5361-else
configure:5362: gcc_cv_prog_cmp_skip='cmp $$f1 $$f2 16 16'
configure-5363-fi
configure-5364- fi
configure-5365- if cmp --ignore-initial=2 t1 t2 > /dev/null 2>&1; then
configure-5366-if cmp --ignore-initial=1 t1 t2 > /dev/null 2>&1; then
configure-5367- :
configure-5368-else
configure:5369: gcc_cv_prog_cmp_skip='cmp --ignore-initial=16 $$f1 $$f2'
configure-5370-fi
configure-5371- fi
configure-5372- rm t1 t2
configure-5373-
configure-5374-fi
configure:5375:{ $as_echo "$as_me:${as_lineno-$LINENO}: result:
$gcc_cv_prog_cmp_skip" >&5
configure:5376:$as_echo "$gcc_cv_prog_cmp_skip" >&6; }
configure:5377:do_compare="$gcc_cv_prog_cmp_skip"
configure-5378-
after ./configure config.log contains:
configure:5350: checking how to compare bootstrapped objects
configure:5375: result: cmp --ignore-initial=16 $$f1 $$f2
[...]
do_compare='cmp --ignore-initial=16 $$f1 $$f2'
and config.status contains:
S["do_compare"]="cmp --ignore-initial=16 $$f1 $$f2"
So the problem is why do_compare is cmp and not contrib/compare-debug .
[Bug bootstrap/67158] New: ICE dwarf2out.c:19910/gen_inlined_subroutine_die, at : Compiling gcc6.0 with gcc6.0 -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67158
Bug ID: 67158
Summary: ICE dwarf2out.c:19910/gen_inlined_subroutine_die, at :
Compiling gcc6.0 with gcc6.0 -flto
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: dilyan.palauzov at aegee dot org
Target Milestone: ---
I run
/git/gcc/configure --enable-host-shared --enable-threads=posix
--with-arch=haswell --enable-__cxa_atexit --enable-languages=c,c++,lto,jit
--enable-targets=all --enable-nls --with-linker-hash-style=gnu
--with-system-zlib --disable-multilib --prefix=/usr/local/gcc60
/usr/local/gcc60/etc/config.site contains:
export CC=/usr/local/gcc60/bin/gcc
export CXX=/usr/local/gcc60/bin/g++
export CFLAGS="-pipe -O3 -flto -fno-fat-lto-objects"
export CXXFLAGS="${CFLAGS}"
export LDFLAGS="-Wl,-O1,-z,relro,-s -flto=4"
where/usr/local/gcc60/bin contains a freshly compiled gcc6.0 (but without
passing -flto when building it)
and still at stage1:
$ make
[ -f stage_final ] || echo stage3 > stage_final
make[1]: Entering directory '/src/gcc/gcc4'
make[2]: Entering directory '/src/gcc/gcc4'
make[3]: Entering directory '/src/gcc/gcc4'
rm -f stage_current
make[3]: Leaving directory '/src/gcc/gcc4'
make[2]: Leaving directory '/src/gcc/gcc4'
make[2]: Entering directory '/src/gcc/gcc4'
make[3]: Entering directory '/src/gcc/gcc4/libiberty'
make[4]: Entering directory '/src/gcc/gcc4/libiberty/testsuite'
make[4]: Nothing to be done for 'all'.
make[4]: Leaving directory '/src/gcc/gcc4/libiberty/testsuite'
make[3]: Leaving directory '/src/gcc/gcc4/libiberty'
make[3]: Entering directory '/src/gcc/gcc4/lto-plugin'
make all-am
make[4]: Entering directory '/src/gcc/gcc4/lto-plugin'
make[4]: Leaving directory '/src/gcc/gcc4/lto-plugin'
make[3]: Leaving directory '/src/gcc/gcc4/lto-plugin'
make[3]: Entering directory '/src/gcc/gcc4/intl'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory '/src/gcc/gcc4/intl'
make[3]: Entering directory '/src/gcc/gcc4/build-x86_64-pc-linux-gnu/libiberty'
make[4]: Entering directory
'/src/gcc/gcc4/build-x86_64-pc-linux-gnu/libiberty/testsuite'
make[4]: Nothing to be done for 'all'.
make[4]: Leaving directory
'/src/gcc/gcc4/build-x86_64-pc-linux-gnu/libiberty/testsuite'
make[3]: Leaving directory '/src/gcc/gcc4/build-x86_64-pc-linux-gnu/libiberty'
make[3]: Entering directory
'/src/gcc/gcc4/build-x86_64-pc-linux-gnu/fixincludes'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory
'/src/gcc/gcc4/build-x86_64-pc-linux-gnu/fixincludes'
make[3]: Entering directory '/src/gcc/gcc4/build-x86_64-pc-linux-gnu/libcpp'
test -f config.h || (rm -f stamp-h1 && make stamp-h1)
make[3]: Leaving directory '/src/gcc/gcc4/build-x86_64-pc-linux-gnu/libcpp'
make[3]: Entering directory '/src/gcc/gcc4/libbacktrace'
make all-am
make[4]: Entering directory '/src/gcc/gcc4/libbacktrace'
true DO=all multi-do # make
make[4]: Leaving directory '/src/gcc/gcc4/libbacktrace'
make[3]: Leaving directory '/src/gcc/gcc4/libbacktrace'
make[3]: Entering directory '/src/gcc/gcc4/libcpp'
test -f config.h || (rm -f stamp-h1 && make stamp-h1)
make[3]: Leaving directory '/src/gcc/gcc4/libcpp'
make[3]: Entering directory '/src/gcc/gcc4/libdecnumber'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory '/src/gcc/gcc4/libdecnumber'
make[3]: Entering directory '/src/gcc/gcc4/gcc'
/usr/local/gcc60/bin/g++ -std=gnu++98 -g -DIN_GCC -fPIC-fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -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 -static-libstdc++
-static-libgcc -Wl,-O1,-z,relro,-s -flto=4 -no-pie -o build/genmatch \
build/genmatch.o ../build-x86_64-pc-linux-gnu/libcpp/libcpp.a
build/errors.o build/vec.o build/hash-table.o
../build-x86_64-pc-linux-gnu/libiberty/pic/libiberty.a
/git/gcc/libcpp/macro.c: In function ‘_cpp_create_definition’:
/git/gcc/libcpp/macro.c:3268:1: internal compiler error: in
gen_inlined_subroutine_die, at dwarf2out.c:19910
}
^
0x6ecde1 gen_inlined_subroutine_die
/git/gcc/gcc/dwarf2out.c:19909
0x6ecde1 gen_block_die
/git/gcc/gcc/dwarf2out.c:20966
0x6ecf6a decls_for_scope
/git/gcc/gcc/dwarf2out.c:21039
0x6eca8a gen_lexical_block_die
/git/gcc/gcc/dw
[Bug lto/67157] New: Compiling gcc6 with liblto_plugin, v5.2.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67157
Bug ID: 67157
Summary: Compiling gcc6 with liblto_plugin, v5.2.0
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: dilyan.palauzov at aegee dot org
Target Milestone: ---
I have ld.bfd/as 2.25.51.20150808 and the most recent gcc repository.
I do /git/gcc/configure --enable-host-shared --enable-threads=posix
--with-arch=haswell --enable-__cxa_atexit --enable-languages=c,c++,lto,jit
--enable-targets=all --enable-nls --with-linker-hash-style=gnu
--with-system-zlib --disable-multilib --prefix=/usr/local/gcc60 .
For the compilation I use gcc 5.2.0 .
If I have in /usr/local/gcc60/etc/config.site:
export CFLAGS="-pipe -O3 -flto -fno-fat-lto-objects"
export CXXFLAGS="${CFLAGS}"
export LDFLAGS="-Wl,-O1,-z,relro,-s -flto=4"
then building gcc fails at stage1 with the message below. However, if I have
no /usr/local/gcc60/etc/config.site then the build works. I guess that the
problem is not with the linker, but with liblto-5.2.0.
$ make
[ -f stage_final ] || echo stage3 > stage_final
make[1]: Entering directory '/src/gcc/gcc4'
make[2]: Entering directory '/src/gcc/gcc4'
make[3]: Entering directory '/src/gcc/gcc4'
rm -f stage_current
make[3]: Leaving directory '/src/gcc/gcc4'
make[2]: Leaving directory '/src/gcc/gcc4'
make[2]: Entering directory '/src/gcc/gcc4'
make[3]: Entering directory '/src/gcc/gcc4/libiberty'
make[4]: Entering directory '/src/gcc/gcc4/libiberty/testsuite'
make[4]: Nothing to be done for 'all'.
make[4]: Leaving directory '/src/gcc/gcc4/libiberty/testsuite'
make[3]: Leaving directory '/src/gcc/gcc4/libiberty'
make[3]: Entering directory '/src/gcc/gcc4/lto-plugin'
make all-am
make[4]: Entering directory '/src/gcc/gcc4/lto-plugin'
make[4]: Leaving directory '/src/gcc/gcc4/lto-plugin'
make[3]: Leaving directory '/src/gcc/gcc4/lto-plugin'
make[3]: Entering directory '/src/gcc/gcc4/intl'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory '/src/gcc/gcc4/intl'
make[3]: Entering directory '/src/gcc/gcc4/build-x86_64-pc-linux-gnu/libiberty'
make[4]: Entering directory
'/src/gcc/gcc4/build-x86_64-pc-linux-gnu/libiberty/testsuite'
make[4]: Nothing to be done for 'all'.
make[4]: Leaving directory
'/src/gcc/gcc4/build-x86_64-pc-linux-gnu/libiberty/testsuite'
make[3]: Leaving directory '/src/gcc/gcc4/build-x86_64-pc-linux-gnu/libiberty'
make[3]: Entering directory
'/src/gcc/gcc4/build-x86_64-pc-linux-gnu/fixincludes'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory
'/src/gcc/gcc4/build-x86_64-pc-linux-gnu/fixincludes'
make[3]: Entering directory '/src/gcc/gcc4/build-x86_64-pc-linux-gnu/libcpp'
test -f config.h || (rm -f stamp-h1 && make stamp-h1)
make[3]: Leaving directory '/src/gcc/gcc4/build-x86_64-pc-linux-gnu/libcpp'
make[3]: Entering directory '/src/gcc/gcc4/libbacktrace'
make all-am
make[4]: Entering directory '/src/gcc/gcc4/libbacktrace'
true DO=all multi-do # make
make[4]: Leaving directory '/src/gcc/gcc4/libbacktrace'
make[3]: Leaving directory '/src/gcc/gcc4/libbacktrace'
make[3]: Entering directory '/src/gcc/gcc4/libcpp'
test -f config.h || (rm -f stamp-h1 && make stamp-h1)
make[3]: Leaving directory '/src/gcc/gcc4/libcpp'
make[3]: Entering directory '/src/gcc/gcc4/libdecnumber'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory '/src/gcc/gcc4/libdecnumber'
make[3]: Entering directory '/src/gcc/gcc4/gcc'
make[3]: Leaving directory '/src/gcc/gcc4/gcc'
Checking multilib configuration for libgcc...
make[3]: Entering directory '/src/gcc/gcc4/x86_64-pc-linux-gnu/libgcc'
# If this is the top-level multilib, build all the other
# multilibs.
# Early copyback; see "all" above for the rationale. The
# early copy is necessary so that the gcc -B options find
# the right startup files when linking shared libgcc.
/bin/bash /git/gcc/libgcc/../mkinstalldirs ../.././gcc
parts="crtbegin.o crtbeginS.o crtbeginT.o crtend.o crtendS.o crtprec32.o
crtprec64.o crtprec80.o crtfastmath.o";
\
for file in $parts; do \
rm -f ../.././gcc/$file; \
/usr/bin/install -c -m 644 $file ../.././gcc/;\
case $file in \
*.a)\
ranlib ../.././gcc/$file ;; \
esac;
[Bug bootstrap/67156] config/bootstrap-debug.mk: STAGE2_CFLAGS += -gtoggle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67156
--- Comment #2 from Дилян Палаузов ---
It is x86_64-pc-linux-gnu == host == target == build.
To what I see in the root Makefile (copied below) at the end of the build files
in stage2 and stage3 are compared with `cmp', which fails, if one file has
debugging information and the other does not, even if both files have identical
text/data/bss sections.
---
do-compare = cmp --ignore-initial=16 $$f1 $$f2
compare:
@r=`${PWD_COMMAND}`; export r; \
s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \
if test -f stage2-lean; then \
echo Cannot compare object files as stage 2 was deleted.; \
exit 0; \
fi; \
: $(MAKE); $(stage); \
rm -f .bad_compare; \
echo Comparing stages 2 and 3; \
sed=`echo stage3 | sed 's,^stage,,;s,.,.,g'`; \
files=`find stage3-* -name "*$(objext)" -print | \
sed -n s,^stage$$sed-,,p`; \
for file in $${files}; do \
f1=$$r/stage2-$$file; f2=$$r/stage3-$$file; \
if test ! -f $$f1; then continue; fi; \
$(do-compare) > /dev/null 2>&1; \
if test $$? -eq 1; then \
case $$file in \
gcc/cc*-checksum$(objext) | gcc/ada/*tools/*) \
echo warning: $$file differs ;; \
*) \
echo $$file differs >> .bad_compare ;; \
esac; \
fi; \
done; \
if [ -f .bad_compare ]; then \
echo "Bootstrap comparison failure!"; \
cat .bad_compare; \
exit 1; \
else \
echo Comparison successful.; \
fi; \
$(STAMP) compare
if $(LEAN); then \
rm -rf stage2-*; \
$(STAMP) stage2-lean; \
fi
[Bug bootstrap/67156] New: config/bootstrap-debug.mk: STAGE2_CFLAGS += -gtoggle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67156
Bug ID: 67156
Summary: config/bootstrap-debug.mk: STAGE2_CFLAGS += -gtoggle
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: dilyan.palauzov at aegee dot org
Target Milestone: ---
config/bootstrap-debug.mk contains:
STAGE2_CFLAGS += -gtoggle
and in turn stage2 is compiled with -gtoggle, while stage3 is compile without
-gtoggle. This can be seen by comparing stage{2,3}-gcc/Makefile . After
finishing stage3, the build process compares the binaries from stage2 and
stage3, which differ, because they were compiled with/out -gtoggle.
Removing -gtoggle from config/bootstrap-debug.mk:STAGE2_CFLAGS enables to
finish the compilation without errors (during the final comparison)
I compile gcc with
/git/gcc/configure --enable-host-shared --enable-threads=posix
--with-arch=haswell --enable-__cxa_atexit --enable-languages=c,c++,lto,jit
--enable-targets=all --enable-nls --with-linker-hash-style=gnu
--with-system-zlib --disable-multilib
and the gcc-git repository is at the newest state.
[Bug bootstrap/67137] New: --enable-languages=jit and --disable-shared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67137 Bug ID: 67137 Summary: --enable-languages=jit and --disable-shared Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: dilyan.palauzov at aegee dot org Target Milestone: --- /git/gcc/configure --enable-host-shared --enable-threads=posix --with-arch=haswell --enable-__cxa_atexit --enable-languages=c,c++,lto,jit --disable-shared --enable-targets=all --enable-nls --with-linker-hash-style=gnu --with-system-zlib --disable-multilib make at stage2 fails with the message below, trying to build libgccjit.so.0.0.1 . As I pass --disable-shared to ./configure, either configure shall fail, when --enable-languages=jit is also requested, or it shall build libgccjit static. In any case, make may not fail because of impossible combinations of flags to ./configure, it is ./configure which must fail then. make[3]: Entering directory '/src/gcc/gcc2/gcc' /src/gcc/gcc2/./prev-gcc/xg++ -B/src/gcc/gcc2/./prev-gcc/ -B/usr/local/gcc60/x86_64-pc-linux-gnu/bin/ -nostdinc++ -B/src/gcc/gcc2/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -B/src/gcc/gcc2/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -I/src/gcc/gcc2/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I/src/gcc/gcc2/prev-x86_64-pc-linux-gnu/libstdc++-v3/include -I/git/gcc/libstdc++-v3/libsupc++ -L/src/gcc/gcc2/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/src/gcc/gcc2/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -no-pie -g -O2 -gtoggle -DIN_GCC -fPIC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc -o libgccjit.so.0.0.1 -shared \ attribs.o jit/dummy-frontend.o jit/libgccjit.o jit/jit-logging.o jit/jit-recording.o jit/jit-playback.o jit/jit-result.o jit/jit-tempdir.o jit/jit-builtins.o jit/jit-spec.o gcc.o libbackend.a libcommon-target.a libcommon.a \ ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a ../libcpp/libcpp.a ../libbacktrace/.libs/libbacktrace.a ../libiberty/pic/libiberty.a ../libdecnumber/libdecnumber.a -lisl -lmpc -lmpfr -lgmp -rdynamic -ldl -lz \ driver-i386.o \ -Wl,--version-script=/git/gcc/gcc/jit/libgccjit.map \ -Wl,-soname,libgccjit.so.0 /usr/local/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/../../../../x86_64-unknown-linux-gnu/bin/ld: /src/gcc/gcc2/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.a(pure.o): relocation R_X86_64_32 against `.rodata.__cxa_pure_virtual.str1.1' can not be used when making a shared object; recompile with -fPIC /src/gcc/gcc2/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.a: error adding symbols: Bad value collect2: error: ld returned 1 exit status /git/gcc/gcc/jit/Make-lang.in:84: recipe for target 'libgccjit.so.0.0.1' failed make[3]: *** [libgccjit.so.0.0.1] Error 1 make[3]: Leaving directory '/src/gcc/gcc2/gcc' Makefile:4417: recipe for target 'all-stage2-gcc' failed make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory '/src/gcc/gcc2' Makefile:19833: recipe for target 'stage2-bubble' failed make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory '/src/gcc/gcc2' Makefile:908: recipe for target 'all' failed make: *** [all] Error 2
[Bug bootstrap/67128] Makefile.in, libcc1 and --enable-shared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67128 --- Comment #1 from Дилян Палаузов --- To be precise, here is the complete error message, when linking shared libcc1. I use GNU ld 2.25.51.20150804. libtool: link: /src/gcc/gcc-git/./gcc/xg++ -B/src/gcc/gcc-git/./gcc/ -nostdinc++ -nostdinc++ -I/src/gcc/gcc-git/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I/src/gcc/gcc-git/x86_64-pc-linux-gnu/libstdc++-v3/include -I/git/gcc/libstdc++-v3/libsupc++ -I/git/gcc/libstdc++-v3/include/backward -I/git/gcc/libstdc++-v3/testsuite/util -L/src/gcc/gcc-git/x86_64-pc-linux-gnu/libstdc++-v3/src -L/src/gcc/gcc-git/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/src/gcc/gcc-git/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -B/src/gcc/gcc-git/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -B/src/gcc/gcc-git/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -B/usr/local/gcc60/x86_64-pc-linux-gnu/bin/ -B/usr/local/gcc60/x86_64-pc-linux-gnu/lib/ -isystem /usr/local/gcc60/x86_64-pc-linux-gnu/include -isystem /usr/local/gcc60/x86_64-pc-linux-gnu/sys-include -fPIC -DPIC -shared -nostdlib /usr/lib/x86_64-linux-gnu/crti.o /src/gcc/gcc-git/./gcc/crtbeginS.o .libs/findcomp.o .libs/libcc1.o .libs/names.o .libs/callbacks.o .libs/connection.o .libs/marshall.o -L/src/gcc/gcc-git/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/src/gcc/gcc-git/x86_64-pc-linux-gnu/libstdc++-v3/src -L/src/gcc/gcc-git/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -L/src/gcc/gcc-git/./gcc -L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib64 /src/gcc/gcc-git/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.a -lm -lc -lgcc /src/gcc/gcc-git/./gcc/crtendS.o /usr/lib/x86_64-linux-gnu/crtn.o -static-libstdc++ -static-libgcc ../libiberty/pic/libiberty.a -Wl,-soname -Wl,libcc1.so.0 -Wl,-retain-symbols-file -Wl,/git/gcc/libcc1/libcc1.sym -o .libs/libcc1.so.0.0.0 /usr/local/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/../../../../x86_64-unknown-linux-gnu/bin/ld: /src/gcc/gcc-git/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.a(eh_throw.o): relocation R_X86_64_32S against `.text._ZL23__gxx_exception_cleanup19_Unwind_Reason_CodeP17_Unwind_Exception' can not be used when making a shared object; recompile with -fPIC /src/gcc/gcc-git/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.a: error adding symbols: Bad value collect2: error: ld returned 1 exit status Makefile:437: recipe for target 'libcc1.la' failed make[3]: *** [libcc1.la] Error 1 make[3]: Leaving directory '/src/gcc/gcc-git/libcc1' Makefile:319: recipe for target 'all' failed make[2]: *** [all] Error 2 make[2]: Leaving directory '/src/gcc/gcc-git/libcc1' Makefile:12120: recipe for target 'all-libcc1' failed make[1]: *** [all-libcc1] Error 2 make[1]: Leaving directory '/src/gcc/gcc-git' Makefile:908: recipe for target 'all' failed make: *** [all] Error 2
[Bug bootstrap/67128] New: Makefile.in, libcc1 and --enable-shared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67128
Bug ID: 67128
Summary: Makefile.in, libcc1 and --enable-shared
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: dilyan.palauzov at aegee dot org
Target Milestone: ---
As of current master (47dcac97f8004116), Makefile.in contains:
configure-libcc1:
@: $(MAKE); $(unstage)
@r=`${PWD_COMMAND}`; export r; \
s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \
test ! -f $(HOST_SUBDIR)/libcc1/Makefile || exit 0; \
$(SHELL) $(srcdir)/mkinstalldirs $(HOST_SUBDIR)/libcc1; \
$(HOST_EXPORTS) \
echo Configuring in $(HOST_SUBDIR)/libcc1; \
cd "$(HOST_SUBDIR)/libcc1" || exit 1; \
case $(srcdir) in \
/* | [A-Za-z]:[\\/]*) topdir=$(srcdir) ;; \
*) topdir=`echo $(HOST_SUBDIR)/libcc1/ | \
sed -e 's,\./,,g' -e 's,[^/]*/,../,g' `$(srcdir) ;; \
esac; \
module_srcdir=libcc1; \
$(SHELL) \
$$s/$$module_srcdir/configure \
--srcdir=$${topdir}/$$module_srcdir \
$(HOST_CONFIGARGS) --build=${build_alias} --host=${host_alias} \
--target=${target_alias} --enable-shared \
|| exit 1
@endif libcc1
If I run at root-level ./configure --disable-shared, then libstdc++ is build
static and building libcc1 fails with:
/src/gcc/gcc-git/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.a: error
adding symbols: Bad value
collect2: error: ld returned 1 exit status
Makefile:437: recipe for target 'libcc1.la' failed
make[3]: *** [libcc1.la] Error 1
make[3]: Leaving directory '/src/gcc/gcc-git/libcc1'
Makefile:319: recipe for target 'all' failed
make[2]: *** [all] Error 2
make[2]: Leaving directory '/src/gcc/gcc-git/libcc1'
Makefile:12120: recipe for target 'all-libcc1' failed
make[1]: *** [all-libcc1] Error 2
make[1]: Leaving directory '/src/gcc/gcc-git'
Makefile:908: recipe for target 'all' failed
make: *** [all] Error 2
Removing "--enable-shared" from Makefile.(in) solves the problem.
[Bug lto/67111] New: ld -plugin segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67111
Bug ID: 67111
Summary: ld -plugin segmentation fault
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: dilyan.palauzov at aegee dot org
Target Milestone: ---
I have the newest gcc (g207b8288) and binutils (gedc66de).
binutils is configured with "/git/binutils-gdb/configure
--target=armv6kz-hardfloat-linux-gnueabi --with-sysroot=/raspberryOS/
--with-system-readline --enable-gold --with-system-zlib --with-mmap
--with-python=python3"
gcc is configured with "/git/gcc/configure --enable-host-shared
--enable-threads=posix --enable-languages=c,c++,jit,lto --enable-targets=all
--enable-nls --with-linker-hash-style=gnu --enable-interpreter
--enable-libgcj-multifile --with-system-zlib --with-mtune=arm1176jzf-s
--with-arch=armv6kz --target=armv6kz-hardfloat-linux-gnueabi --with-fpu=vfp
--with-float=hard --with-sysroot=/raspberryOS/"
I compile this programm c.c
int main () {
return 0;
}
with
$ ulimit -c unlimited
$ armv6kz-hardfloat-linux-gnueabi-gcc -pipe -O3 -flto -fno-fat-lto-objects
-Wl,-O1,-z,relro,-s -flto=4
-Wl,-plugin,/usr/local/libexec/gcc/armv6kz-hardfloat-linux-gnueabi/6.0.0/liblto_plugin.so
c.c
collect2: fatal error: ld terminated with signal 11 [Segmentation fault], core
dumped
compilation terminated.
$ gdb armv6kz-hardfloat-linux-gnueabi-ld core
warning: core file may not match specified executable file.
[New LWP 19330]
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
Core was generated by
`/usr/local/lib/gcc/armv6kz-hardfloat-linux-gnueabi/6.0.0/../../../../armv6kz-ha'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 get_symbols (handle=, nsyms=, syms=, def_ironly_exp=9) at /git/binutils-gdb/ld/plugin.c:667
667 if (syms[n].def != LDPK_UNDEF)
(gdb) bt f
#0 get_symbols (handle=, nsyms=, syms=, def_ironly_exp=9) at /git/binutils-gdb/ld/plugin.c:667
blhe =
owner_sec =
res =
input =
abfd = 0x128adb0
n =
#1 0x7fdad3f67448 in write_resolution () at
/git/gcc/lto-plugin/lto-plugin.c:476
info = 0x128cf50
symtab = 0x128cf60
syms =
i = 0
f = 0x14d5970
#2 all_symbols_read_handler () at /git/gcc/lto-plugin/lto-plugin.c:643
i =
num_lto_args =
lto_argv = 0x14d57c0
lto_arg_ptr = 0x14d57c0
__PRETTY_FUNCTION__ = "all_symbols_read_handler"
#3 0x0041fe02 in plugin_call_all_symbols_read () at
/git/binutils-gdb/ld/plugin.c:1210
rv =
curplug = 0x1249fd0
#4 0x004155df in lang_process () at /git/binutils-gdb/ld/ldlang.c:6646
added = {
head = 0x1247210,
tail = 0x125ea00
}
files = {
head = 0x125ea00,
tail = 0x124a160
}
inputfiles = {
head = 0x1247210,
tail = 0x12d2d38
}
#5 0x004036c7 in main (argc=43, argv=0x7ffc8b525068) at
/git/binutils-gdb/ld/ldmain.c:419
emulation = 0x7ffc8b525fbf "armelf_linux_eabi"
start_time = 0
start_sbrk = 0x1246000 ""
[Bug libffi/67102] New: Parallel build fails in libffi/configure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67102 Bug ID: 67102 Summary: Parallel build fails in libffi/configure Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libffi Assignee: unassigned at gcc dot gnu.org Reporter: dilyan.palauzov at aegee dot org Target Milestone: --- I configure gcc with /git/gcc/configure --enable-host-shared --enable-threads=posix --enable-languages=all --enable-targets=all --enable-nls --with-linker-hash-style=gnu --enable-interpreter --enable-libgcj-multifile --with-system-zlib --enable-browser-plugin --without-x --with-mtune=arm1176jzf-s --with-arch=armv6kz --target=armv6kz-hardfloat-linux-gnueabi --with-fpu=vfp --with-float=hard --with-sysroot=/raspberryOS/ and then do "make -j4". It fails in armv6kz-hardfloat-linux-gnueabi/libffi/configure (/lib/cpp as preprocessor not found). My preprocessor is "/usr/local/bin/cpp" on $PATH, not /lib/cpp Sequential build does not have this problem. This is possibly a duplicate of PR65726. -- armv6kz-hardfloat-linux-gnueabi/libffi/config.log -- This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by libffi configure 3.9, which was generated by GNU Autoconf 2.64. Invocation command line was $ /git/gcc/libffi/configure --srcdir=/git/gcc/libffi --cache-file=./config.cache --enable-multilib --with-cross-host=x86_64-pc-linux-gnu --enable-host-shared --enable-threads=posix --enable-targets=all --enable-nls --with-linker-hash-style=gnu --enable-interpreter --enable-libgcj-multifile --with-system-zlib --enable-browser-plugin --without-x --with-mtune=arm1176jzf-s --with-arch=armv6kz --with-fpu=vfp --with-float=hard --with-sysroot=/raspberryOS/ --enable-languages=c,c++,fortran,java,lto,objc --program-transform-name=s&^&armv6kz-hardfloat-linux-gnueabi-& --disable-option-checking --with-target-subdir=armv6kz-hardfloat-linux-gnueabi --build=x86_64-pc-linux-gnu --host=armv6kz-hardfloat-linux-gnueabi --target=armv6kz-hardfloat-linux-gnueabi ## - ## ## Platform. ## ## - ## hostname = Ric uname -m = x86_64 uname -r = 3.16.0-4-amd64 uname -s = Linux uname -v = #1 SMP Debian 3.16.7-ckt11-1+deb8u2 (2015-07-17) /usr/bin/uname -p = unknown /bin/uname -X = unknown /bin/arch = unknown /usr/bin/arch -k = unknown /usr/convex/getsysinfo = unknown /usr/bin/hostinfo = unknown /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown PATH: /usr/local/bin PATH: /usr/bin PATH: /bin PATH: /usr/local/games PATH: /usr/games ## --- ## ## Core tests. ## ## --- ## configure:2452: creating cache ./config.cache configure:2596: checking build system type configure:2610: result: x86_64-pc-linux-gnu configure:2630: checking host system type configure:2643: result: armv6kz-hardfloat-linux-gnueabi configure:2663: checking target system type configure:2676: result: armv6kz-hardfloat-linux-gnueabi configure:2721: checking for a BSD-compatible install configure:2789: result: /usr/bin/install -c configure:2800: checking whether build environment is sane configure:2850: result: yes configure:2899: checking for armv6kz-hardfloat-linux-gnueabi-strip configure:2926: result: armv6kz-hardfloat-linux-gnueabi-strip configure:2991: checking for a thread-safe mkdir -p configure:3030: result: /bin/mkdir -p configure:3043: checking for gawk configure:3070: result: gawk configure:3081: checking whether make sets $(MAKE) configure:3103: result: yes configure:3189: checking for makeinfo configure:3216: result: makeinfo --split-size=500 configure:3226: checking for modern makeinfo configure:3241: result: yes configure:3264: checking generated-files-in-srcdir configure:3277: result: no configure:3306: checking for armv6kz-hardfloat-linux-gnueabi-gcc configure:: result: /home/d/rasbperry/gcc/./gcc/xgcc -B/home/d/rasbperry/gcc/./gcc/ -B/usr/local/armv6kz-hardfloat-linux-gnueabi/bin/ -B/usr/local/armv6kz-hardfloat-linux-gnueabi/lib/ -isystem /usr/local/armv6kz-hardfloat-linux-gnueabi/include -isystem /usr/local/armv6kz-hardfloat-linux-gnueabi/sys-include configure:3602: checking for C compiler version configure:3611: /home/d/rasbperry/gcc/./gcc/xgcc -B/home/d/rasbperry/gcc/./gcc/ -B/usr/local/armv6kz-hardfloat-linux-gnueabi/bin/ -B/usr/local/armv6kz-hardfloat-linux-gnueabi/lib/ -isystem /usr/local/armv6kz-hardfloat-linux-gnueabi/include -isystem /usr/local/armv6kz-hardfloat-linux-gnueabi/sys-include--version >&5 xgcc (GCC) 6.0.0 20150803 (experimental) Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. configure:3622: $? = 0 configure:3611: /ho
[Bug lto/65991] maybe-unitialized - false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65991 --- Comment #5 from Дилян Палаузов --- The problem does not appear anymore, since I upgraded gcc 4.9.2 -> 4.9.3 .
[Bug lto/65991] maybe-unitialized - false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65991 Дилян Палаузов changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #2 from Дилян Палаузов --- Despite the custom CFLAGS used when building binutils, there is false positive LTO warning.
[Bug lto/65991] New: maybe-unitialized - false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65991 Bug ID: 65991 Summary: maybe-unitialized - false positive Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: dilyan.palauzov at aegee dot org Target Milestone: --- I have compiled gcc with ../gcc-4.9.2/configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --enable-threads=posix --enable-nls --enable-interpreter --with-system-zlib --enable-libgcj-multifile --enable-languages=all --enable-targets=all --with-system-unwind --without-x --with-linker-hash-style=gnu --enable-multilib --disable-multilib --with-arch=nocona export CFLAGS="-pipe -O3 -fno-fat-lto-objects -flto" export CXXFLAGS="-pipe -O3 -fno-fat-lto-objects -flto" Then I try to compile binutils (at commit 01a97082d0e9) with configure --enable-lto --enable-plugins --enable-threads --enable-gold=yes --with-zlib CFLAGS='-pipe -O3 -fno-fat-lto-objects -flto' LDFLAGS='-Wl,-O1 -Wl,-z,relro -Wl,-s' bintuils utilizies internally -Werror and compiling it fails with LTO error at: make[2]: Entering directory '/mnt/new/src/gcc/binutil-git/gas' /bin/sh ./libtool --tag=CC --mode=link gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -I/home/git/binutils-gdb/gas/../zlib -pipe -O3 -fno-fat-lto-objects -flto -Wl,-O1 -Wl,-z,relro -Wl,-s -o as-new app.o as.o atof-generic.o compress-debug.o cond.o depend.o dwarf2dbg.o dw2gencfi.o ecoff.o ehopt.o expr.o flonum-copy.o flonum-konst.o flonum-mult.o frags.o hash.o input-file.o input-scrub.o listing.o literal.o macro.o messages.o output-file.o read.o remap.o sb.o stabs.o subsegs.o symbols.o write.o tc-i386.o obj-elf.o atof-ieee.o ../opcodes/libopcodes.la ../bfd/libbfd.la ../libiberty/libiberty.a -ldl libtool: link: gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -I/home/git/binutils-gdb/gas/../zlib -pipe -O3 -fno-fat-lto-objects -flto -Wl,-O1 -Wl,-z -Wl,relro -Wl,-s -o as-new app.o as.o atof-generic.o compress-debug.o cond.o depend.o dwarf2dbg.o dw2gencfi.o ecoff.o ehopt.o expr.o flonum-copy.o flonum-konst.o flonum-mult.o frags.o hash.o input-file.o input-scrub.o listing.o literal.o macro.o messages.o output-file.o read.o remap.o sb.o stabs.o subsegs.o symbols.o write.o tc-i386.o obj-elf.o atof-ieee.o ../opcodes/.libs/libopcodes.a ../bfd/.libs/libbfd.a -L/src/gcc/binutil-git/zlib -lz ../libiberty/libiberty.a -ldl /home/git/binutils-gdb/bfd/compress.c: In function 'bfd_compress_section_contents': /home/git/binutils-gdb/bfd/compress.c:161:4: error: 'zlib_size' may be used uninitialized in this function [-Werror=maybe-uninitialized] memmove (buffer + compression_header_size, ^ /home/git/binutils-gdb/bfd/compress.c:88:7: note: 'zlib_size' was declared here int zlib_size; ^ lto1: all warnings being treated as errors lto-wrapper: gcc returned 1 exit status /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../x86_64-unknown-linux-gnu/bin/ld: lto-wrapper failed collect2: error: ld returned 1 exit status Makefile:769: recipe for target 'as-new' failed make[2]: *** [as-new] Error 1 make[2]: Leaving directory '/mnt/new/src/gcc/binutil-git/gas' See also https://sourceware.org/bugzilla/show_bug.cgi?id=18313 .
[Bug target/65212] New: --with-arch=nocona and -msse3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65212 Bug ID: 65212 Summary: --with-arch=nocona and -msse3 Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: dilyan.palauzov at aegee dot org At https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/i386-and-x86-64-Options.html#i386-and-x86-64-Options is written: ‘nocona’ Improved version of Intel Pentium 4 CPU with 64-bit extensions, MMX, SSE, SSE2 and SSE3 instruction set support. I ./configure gcc with --with-arch=nocona, and running afterwards `gcc -Q --help=target` I get (among other things): -march= nocona -mmmx [disabled] -msse [disabled] -msse2[disabled] -msse2avx [disabled] -msse3[disabled] Provided that gcc is instructed to generate code for Intel Nocona, which has SSE3, why is the -msse3 directive not enabled automatically? I expect here to have SSE2 enabled automatically, as under this circumstances (code for Nocona) I do not see a point to disable it.
[Bug libgcc/63772] New: Double included .h files in gcc/gtype-desc.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63772 Bug ID: 63772 Summary: Double included .h files in gcc/gtype-desc.c Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: dilyan.palauzov at aegee dot org The program deheader states correctly, that gcc/gtype-desc.c includes twice basic-block.h and ggc.h . This is probably caused by the fact, that gcc/gengtype.c:open_base_files():static const char *const ifiles[] contains twice the aforementioned .h file. Please make sure, that gcc/gtype-desc.c does not include twice basic-block.h and ggc.h , as one inclusion is sufficient.
[Bug java/63768] New: double included .h file in libjava/.../natFileChannelPosix.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63768 Bug ID: 63768 Summary: double included .h file in libjava/.../natFileChannelPosix.cc Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java Assignee: unassigned at gcc dot gnu.org Reporter: dilyan.palauzov at aegee dot org deheader (git://gitorious.org/deheader/deheader.git) states correctly, that libjava/gnu/java/nio/channels/natFileChannelPosix.cc contains twice #include and one of them is unnecessary.
[Bug web/62211] New: ./configure --with-float= and ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62211 Bug ID: 62211 Summary: ./configure --with-float= and ARM Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: web Assignee: unassigned at gcc dot gnu.org Reporter: dilyan.palauzov at aegee dot org At https://gcc.gnu.org/install/configure.html is written: Options specification --with-fpu=type --with-float=type These configure options provide default values for the -mfpu= option and for -mhard-float or -msoft-float. I want to configure for ARM. In the gcc manual, node 3.1 Option Summary under _ARM Options_ is mentioned the option -mfloat-abi= but -m(hard,sort)-float are not mentioned. In node 3.17.4 ARM Options is mentioned, that -mfloat-abi can be hard, soft or softfp. Does ./configure-ing gcc --with-float=X lead to defaulting the -mfloat-abi option later, when gcc is not called? In such a case, the documentation for configuring gcc shall mention, that --with-float=type on ARM has no impact on -msoft-float or -mhard-float, but on -mfloat-abi . The documentation of GCC does mention neither -mhard-float nor -msoft-float as general options nor as ARM-specific options, so I conclude that these are not permitted. However, the documentation of -mfpu= , where the ARM options are described, mentions: If '-msoft-float' is specified this specifies the format of floating-point values. So apparently, -msoft-float can be passed, when gcc produces ARM-code. Please clarify in the gcc manual if -msoft-float is the same as -mfloat-abi=soft, if -mhard-float is the same as -mfloat-abi=hard and if these, including -mfloag-abu=softfp are impacted by ./configure --with-float .
[Bug other/62095] New: gcc: error: unrecognized command line option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62095 Bug ID: 62095 Summary: gcc: error: unrecognized command line option Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: dilyan.palauzov at aegee dot org When I type gcc -WZ I get gcc: error: unrecognized command line option ‘-WZ’ gcc: fatal error: no input files compilation terminated. But when I type gcc -Wno-Z I get just gcc: fatal error: no input files compilation terminated. I expect in the second case to see "unrecognized command line option "-Wno-Z" Motivation: valgrind uncorrectly detects in configure.ac, if the compiler supports -Wno-tautological-compare by running gcc -Wno-tautological-compare, which prints no error => compiler supports -Wno-tautological-compare . However, during compiling valgrind, gcc manages to output somehow the message, that "-Wno-tautological-compare " is not supported, but I cannot write a simple case where gcc complains about -Wno-tautological-compare .
[Bug lto/62083] lto1: fatal error: bytecode stream generated with LTO version 2.2 instead of the expected 3.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62083 --- Comment #2 from Дилян Палаузов --- Thanks!
[Bug lto/62083] New: lto1: fatal error: bytecode stream generated with LTO version 2.2 instead of the expected 3.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62083 Bug ID: 62083 Summary: lto1: fatal error: bytecode stream generated with LTO version 2.2 instead of the expected 3.0 Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: dilyan.palauzov at aegee dot org I have binutils-2.24 with https://sourceware.org/ml/binutils/2014-01/msg00213.html patch applied, and libtool 2.4.2.444.30-da30-dirty . export CFLAGS='-pipe -flto -O3 -Wl,-S -Wl,--hash-style=gnu -Wl,-O1 -Wl,-z,relro -Wall -Wextra -Wl,--plugin=/usr/lib/bfd-plugins/liblto_plugin.so -fno-fat-lto-objects' export CXXFLAGS=$CFLAGS When I do: git clone http://mail.aegee.org/cgit/aegee-milter cd aegee-milter autoreconf -i ./configure && make I get: lto1: fatal error: bytecode stream generated with LTO version 2.2 instead of the expected 3.0 compilation terminated. lto-wrapper: g++ returned 1 exit status /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.1/../../../../x86_64-unknown-linux-gnu/bin/ld: lto-wrapper failed collect2: error: ld returned 1 exit status What means "generated with v2.2 instead of the expected 3.0" and how can I fix this?
[Bug lto/61967] regression: cannot link with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61967 --- Comment #7 from Дилян Палаузов --- (In reply to Andrew Pinski from comment #6) > (In reply to Дилян Палаузов from comment #5) > > Using gcc-ar instead of ar does not help: > > > > $grep AR\ = Makefile > > AR = gcc-ar > > ... > > > ranlib libgnu.a > > You need to use gcc-ranlib too otherwise the symbol table is also messed up. Okay, using gcc-ranlib did help.
