[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=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=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=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 = 0x7f1655731730 ,
__cancel_arg = 0x7ffdf06a0a40, __do_it = 1, __cancel_type = }
timestamp = '\000'
now = 1703339934
[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/fenv.h:63:11: error: ‘fegetexceptflag’ has not been declared in ‘::’ 63 | using ::fegetexceptflag; | ^~~ /src/chroot/libstdc++11/include/fenv.h:64:11: error: ‘feraiseexcept’ has not been declared in ‘::’ 64 | using ::feraiseexcept; | ^ /src/chroot/libstdc++11/include/fenv.h:65:11: error: ‘fesetexceptflag’ has not been declared in ‘::’ 65 | using ::fesetexceptflag; |
