[Bug middle-end/88784] Middle end is missing some optimizations about unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88784 --- Comment #18 from Qi Feng --- I only learned gcc for about 2 months, and I have to say that I don't fully understand what you guys were saying. Is match.pd the right place to fix this issue? Am I in the wrong direction?
[Bug go/86535] FreeBSD/PowerPC64 - Building Go Frontend support for gcc 7.3.0 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535 --- Comment #20 from Curtis Hamilton --- (In reply to Ian Lance Taylor from comment #19) > People build the gofrontend all the time on GNU/Linux systems. I don't know > if anyone has successful built it on a FreeBSD system. My bad! I was referring to builds on FreeBSD. I know it's not building on FreeBSD/ppc64, so I'll try a build on FreeBSD/X86_64 and report the results.
[Bug go/90635] typo in libgo/configure.ac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90635 Ian Lance Taylor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Ian Lance Taylor --- Thanks. Should be fixed on trunk and GCC 9 branch.
[Bug go/90635] typo in libgo/configure.ac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90635 --- Comment #2 from ian at gcc dot gnu.org --- Author: ian Date: Mon May 27 00:14:02 2019 New Revision: 271640 URL: https://gcc.gnu.org/viewcvs?rev=271640=gcc=rev Log: PR go/90635 libgo: correct typo in USE_LIBFFI AM_CONDITIONAL Only affects the case of passing --without-libffi to configure. Fixes https://gcc.gnu.org/PR90635 Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/178998 Modified: trunk/gcc/go/gofrontend/MERGE trunk/libgo/configure trunk/libgo/configure.ac
[Bug go/90635] typo in libgo/configure.ac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90635 --- Comment #1 from ian at gcc dot gnu.org --- Author: ian Date: Mon May 27 00:13:52 2019 New Revision: 271639 URL: https://gcc.gnu.org/viewcvs?rev=271639=gcc=rev Log: PR go/90635 libgo: correct typo in USE_LIBFFI AM_CONDITIONAL Only affects the case of passing --without-libffi to configure. Fixes https://gcc.gnu.org/PR90635 Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/178998 Modified: branches/gcc-9-branch/libgo/configure branches/gcc-9-branch/libgo/configure.ac
[Bug go/90614] gcc-9.1.0/libgo/go/syscall/wait.c:54:22: error: unused parameter ‘w’ [-Werror=unused-parameter] Continued (uint32_t *w)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90614 Ian Lance Taylor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from Ian Lance Taylor --- Fixed on trunk and GCC 9 branch.
[Bug go/90614] gcc-9.1.0/libgo/go/syscall/wait.c:54:22: error: unused parameter ‘w’ [-Werror=unused-parameter] Continued (uint32_t *w)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90614 --- Comment #5 from ian at gcc dot gnu.org --- Author: ian Date: Mon May 27 00:10:34 2019 New Revision: 271638 URL: https://gcc.gnu.org/viewcvs?rev=271638=gcc=rev Log: PR go/90614 syscall: avoid unused parameter error if WIFCONTINUED not defined Fixes https://gcc.gnu.org/PR90614 Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/178997 Modified: trunk/gcc/go/gofrontend/MERGE trunk/libgo/go/syscall/wait.c
[Bug go/90614] gcc-9.1.0/libgo/go/syscall/wait.c:54:22: error: unused parameter ‘w’ [-Werror=unused-parameter] Continued (uint32_t *w)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90614 --- Comment #4 from ian at gcc dot gnu.org --- Author: ian Date: Mon May 27 00:10:22 2019 New Revision: 271637 URL: https://gcc.gnu.org/viewcvs?rev=271637=gcc=rev Log: PR go/90614 syscall: avoid unused parameter error if WIFCONTINUED not defined Fixes https://gcc.gnu.org/PR90614 Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/178997 Modified: branches/gcc-9-branch/libgo/go/syscall/wait.c
[Bug libgcc/90399] split-stack + shared library + static object construction (C++)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90399 Ian Lance Taylor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-05-26 CC||ian at airs dot com Ever confirmed|0 |1 --- Comment #3 from Ian Lance Taylor --- I do see a failure when I run the program. For me the error is happening when running the global constructors. The global constructor Dummy::Dummy is running before the main program's split-stack global constructor. Dummy::Dummy is a global constructor in the shared library. It runs after the shared library split-stack global constructor, but before the main program split-stack global constructor. Unfortunately, it calls the main program __splitstack_makecontext. That is because __splitstack_makecontext and friends have default visibility rather than hidden; see the visibility attribute settings near the top of libgcc/generic-morestack.c. Basically, with the current implementation, a global constructor in a shared library cannot call __splitstack_makecontext. One possible fix might to use some sort of pthread_once call to let __splitstack_makecontext, and possibly other functions with default visibility, initialize static_pagesize and use_guard_page.
[Bug go/86535] FreeBSD/PowerPC64 - Building Go Frontend support for gcc 7.3.0 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535 --- Comment #19 from Ian Lance Taylor --- People build the gofrontend all the time on GNU/Linux systems. I don't know if anyone has successful built it on a FreeBSD system.
[Bug libbacktrace/90636] [libbacktrace] Tests edtest/edtest_alloc/ttest/ttest_alloc are failing on x64 Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90636 --- Comment #1 from Ian Lance Taylor --- Try changing to the libbacktrace build directory, removing edtest.o, and running "make edtest". Presumably then running "./edtest" will fail with the "missing file name or function name" error. Paste the make output here.
[Bug target/90407] Compilation error of a C function generated from Simulink
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90407 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||segher at gcc dot gnu.org Resolution|--- |INVALID --- Comment #2 from Segher Boessenkool --- I don't know why anything decided that pattern needs splitting -- it matches alternative 2 just fine afaics. You don't show what decided this needs a split. This pattern was deleted five years ago. As Richard says, please try 7.4 or later? Oh, and you use -mvle. There is no mainstream GCC release that has that option. Please report this problem to whoever gave you this compiler.
[Bug other/90381] New test case gcc.dg/tree-ssa/pr88676-2.c fails with its introduction in r270934
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90381 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org --- Comment #4 from Segher Boessenkool --- Are bitfields allocated right to left on all LE configs?
[Bug sanitizer/90639] [10 Regression] Boostrap failure with recent trunk on POWER9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90639 Segher Boessenkool changed: What|Removed |Added Target||powerpc*-*-* Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-05-26 CC||segher at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |segher at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Segher Boessenkool --- I have a patch.
[Bug sanitizer/90639] [10 Regression] Boostrap failure with recent trunk on POWER9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90639 Thomas Koenig changed: What|Removed |Added Target Milestone|--- |10.0 Summary|Boostrap failure with |[10 Regression] Boostrap |recent trunk on POWER9 |failure with recent trunk ||on POWER9
[Bug sanitizer/90639] New: Boostrap failure with recent trunk on POWER9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90639 Bug ID: 90639 Summary: Boostrap failure with recent trunk on POWER9 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: tkoenig at gcc dot gnu.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: --- This is on gcc135, with a clean trunk at r271635. Configure was: ../trunk/configure --prefix=$HOME --enable-languages=c,c++,fortran Error message: Making all in tsan make[4]: Entering directory `/home/tkoenig/trunk-bin/powerpc64le-unknown-linux-gnu/libsanitizer/tsan' /bin/sh ../libtool--mode=compile /home/tkoenig/trunk-bin/./gcc/xgcc -B/home/tkoenig/trunk-bin/./gcc/ -B/home/tkoenig/powerpc64le-unknown-linux-gnu/bin/ -B/home/tkoenig/powerpc64le-unknown-linux-gnu/lib/ -isystem /home/tkoenig/powerpc64le-unknown-linux-gnu/include -isystem /home/tkoenig/powerpc64le-unknown-linux-gnu/sys-include-D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -DCAN_SANITIZE_UB=0 -I. -I../../../../trunk/libsanitizer/tsan -I.. -I ../../../../trunk/libsanitizer -I ../../../../trunk/libsanitizer/include -g -O2 -MT tsan_rtl_ppc64.lo -MD -MP -MF .deps/tsan_rtl_ppc64.Tpo -c -o tsan_rtl_ppc64.lo ../../../../trunk/libsanitizer/tsan/tsan_rtl_ppc64.S make[2]: Entering directory `/home/tkoenig/trunk-bin/powerpc64le-unknown-linux-gnu/libgfortran' make all-am libtool: compile: /home/tkoenig/trunk-bin/./gcc/xgcc -B/home/tkoenig/trunk-bin/./gcc/ -B/home/tkoenig/powerpc64le-unknown-linux-gnu/bin/ -B/home/tkoenig/powerpc64le-unknown-linux-gnu/lib/ -isystem /home/tkoenig/powerpc64le-unknown-linux-gnu/include -isystem /home/tkoenig/powerpc64le-unknown-linux-gnu/sys-include -D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -DCAN_SANITIZE_UB=0 -I. -I../../../../trunk/libsanitizer/tsan -I.. -I ../../../../trunk/libsanitizer -I ../../../../trunk/libsanitizer/include -g -O2 -MT tsan_rtl_ppc64.lo -MD -MP -MF .deps/tsan_rtl_ppc64.Tpo -c ../../../../trunk/libsanitizer/tsan/tsan_rtl_ppc64.S -fPIC -DPIC -o .libs/tsan_rtl_ppc64.o ../../../../trunk/libsanitizer/tsan/tsan_rtl_ppc64.S: Assembler messages: ../../../../trunk/libsanitizer/tsan/tsan_rtl_ppc64.S:105: Error: unrecognized opcode: `stvx' ../../../../trunk/libsanitizer/tsan/tsan_rtl_ppc64.S:107: Error: unrecognized opcode: `stvx' ../../../../trunk/libsanitizer/tsan/tsan_rtl_ppc64.S:109: Error: unrecognized opcode: `stvx' ../../../../trunk/libsanitizer/tsan/tsan_rtl_ppc64.S:111: Error: unrecognized opcode: `stvx' ../../../../trunk/libsanitizer/tsan/tsan_rtl_ppc64.S:113: Error: unrecognized opcode: `stvx' ../../../../trunk/libsanitizer/tsan/tsan_rtl_ppc64.S:115: Error: unrecognized opcode: `stvx' ../../../../trunk/libsanitizer/tsan/tsan_rtl_ppc64.S:117: Error: unrecognized opcode: `stvx' ../../../../trunk/libsanitizer/tsan/tsan_rtl_ppc64.S:119: Error: unrecognized opcode: `stvx' ../../../../trunk/libsanitizer/tsan/tsan_rtl_ppc64.S:121: Error: unrecognized opcode: `stvx' ../../../../trunk/libsanitizer/tsan/tsan_rtl_ppc64.S:123: Error: unrecognized opcode: `stvx' ../../../../trunk/libsanitizer/tsan/tsan_rtl_ppc64.S:125: Error: unrecognized opcode: `stvx' ../../../../trunk/libsanitizer/tsan/tsan_rtl_ppc64.S:126: Error: unrecognized opcode: `stvx' ../../../../trunk/libsanitizer/tsan/tsan_rtl_ppc64.S:250: Error: unrecognized opcode: `stvx' ../../../../trunk/libsanitizer/tsan/tsan_rtl_ppc64.S:252: Error: unrecognized opcode: `stvx' ../../../../trunk/libsanitizer/tsan/tsan_rtl_ppc64.S:254: Error: unrecognized opcode: `stvx' ../../../../trunk/libsanitizer/tsan/tsan_rtl_ppc64.S:256: Error: unrecognized opcode: `stvx' ../../../../trunk/libsanitizer/tsan/tsan_rtl_ppc64.S:258: Error: unrecognized opcode: `stvx' ../../../../trunk/libsanitizer/tsan/tsan_rtl_ppc64.S:260: Error: unrecognized opcode: `stvx' ../../../../trunk/libsanitizer/tsan/tsan_rtl_ppc64.S:262: Error: unrecognized opcode: `stvx' ../../../../trunk/libsanitizer/tsan/tsan_rtl_ppc64.S:264: Error: unrecognized opcode: `stvx' ../../../../trunk/libsanitizer/tsan/tsan_rtl_ppc64.S:266: Error: unrecognized opcode: `stvx' ../../../../trunk/libsanitizer/tsan/tsan_rtl_ppc64.S:268: Error: unrecognized opcode: `stvx' ../../../../trunk/libsanitizer/tsan/tsan_rtl_ppc64.S:270: Error: unrecognized opcode: `stvx' ../../../../trunk/libsanitizer/tsan/tsan_rtl_ppc64.S:271: Error: unrecognized opcode: `stvx' make[4]: *** [tsan_rtl_ppc64.lo] Fehler 1 make[4]: Leaving directory `/home/tkoenig/trunk-bin/powerpc64le-unknown-linux-gnu/libsanitizer/tsan' make[3]: *** [all-recursive] Fehler 1 make[3]: Leaving directory `/home/tkoenig/trunk-bin/powerpc64le-unknown-linux-gnu/libsanitizer'
[Bug libstdc++/90638] Wrong results of pow(complex , T1) function when the T1 type differs from T and from int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90638 --- Comment #2 from Igor Smirnov --- Strange... It came with freshiest available CentOS 7.6.
[Bug libstdc++/90638] Wrong results of pow(complex , T1) function when the T1 type differs from T and from int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90638 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2019-05-26 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- (In reply to Igor Smirnov from comment #0) > The identical problem was found for gcc versions > 4.8.5 (the output below is from it), 4.4.5, 4.4.7. All of these versions have been unsupported by the GCC project for many years. Does the problem still exist in current releases?
[Bug libstdc++/90638] New: Wrong results of pow(complex , T1) function when the T1 type differs from T and from int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90638
Bug ID: 90638
Summary: Wrong results of pow(complex , T1) function when
the T1 type differs from T and from int
Product: gcc
Version: 4.8.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: Igor.Smirnov at cern dot ch
Target Milestone: ---
Created attachment 46413
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46413=edit
output of "g++ -v -save-temps prog1.c"
The following program demonstrates wrong results of pow() set of functions for
of template complex<> argument.
The comments starting from "Actually" show erroneous results:
#include
#include
#include
int main(void)
{
double phi = M_PI / INT_MAX;
std::complex< double > var0 = std::polar(1.0, phi);
std::cout< var1(2,2);
std::cout<< sqrt(var1)
<<'\n'< var2(2,2);
std::cout<< sqrt(var2)
<<'\n'<< pow(var2, float(0.5) )
<<' '<< pow(var2, 0.5)
<<' '<< pow(var2, (long double)(0.5) )
<<'\n'<<'\n';
// Should be:
//(1.55377,0.643594)
//(1.55377,0.643594) (1.55377,0.643594) (1.55377,0.643594)
// Actually:
//(1.55377,0.643594)
//(1,0) (1.55377,0.643594) (1,0)
std::complex var3(2,2);
std::cout<.
The fractional part of the floating point number is discarded and the result
gets completely wrong. There is no any "call ... is ambiguous" messages, which
are usually expected, if such a problem can occur. Compilations of calls of
non-template functions in similar cases are failed with this message, but the
template functions are silently compiled. Meanwhile the user may not even know
that the functions are template.
The particular problem with powers of complex numbers based on built-in types
can be easily solved by adding in the "complex" header a set of separate
template functions for the same first argument of complex type and for all
built-in types at the place of the second argument: float, double, long double
and a few more integer types. This can be done by just a few "copy-paste"
operations in a text editor with a minor additional editing, except for integer
types, since the implementation of the latter depends on the version.
The output of compilation with g++ -v -save-temps prog1.c :
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.5/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin
--enable-initfini-array --disable-libgcj
--with-isl=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/isl-install
--with-cloog=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/cloog-install
--enable-gnu-indirect-function --with-tune=generic --with-arch_32=x86-64
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.8.5 20150623 (Red Hat 4.8.5-36) (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
/usr/libexec/gcc/x86_64-redhat-linux/4.8.5/cc1plus -E -quiet -v -D_GNU_SOURCE
prog1.c -mtune=generic -march=x86-64 -fpch-preprocess -o prog1.ii
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-redhat-linux/4.8.5/include-fixed"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../x86_64-redhat-linux/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/x86_64-redhat-linux
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../include/c++/4.8.5/backward
/usr/lib/gcc/x86_64-redhat-linux/4.8.5/include
/usr/local/include
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
/usr/libexec/gcc/x86_64-redhat-linux/4.8.5/cc1plus -fpreprocessed prog1.ii
-quiet -dumpbase prog1.c -mtune=generic -march=x86-64 -auxbase prog1 -version
-o prog1.s
GNU C++ (GCC) version 4.8.5 20150623 (Red Hat 4.8.5-36) (x86_64-redhat-linux)
compiled by GNU C version 4.8.5 20150623 (Red Hat 4.8.5-36), GMP
version 6.0.0, MPFR version 3.1.1, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (GCC) version 4.8.5 20150623 (Red Hat 4.8.5-36) (x86_64-redhat-linux)
compiled by GNU C version 4.8.5 20150623 (Red Hat
[Bug go/86535] FreeBSD/PowerPC64 - Building Go Frontend support for gcc 7.3.0 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
--- Comment #18 from Curtis Hamilton ---
Created attachment 46412
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46412=edit
Patch to fix undefined types in sysinfo.go and runtime_sysinfo.go
This patch resolves many of the undefines with the exception of _thread,
__umtx_time and vsdoTimekeep.
There is also an error in os_freebsd.go that needs to be fixed:
@@ -12,7 +12,7 @@
//go:noescape
//extern _umtx_op
-func sys_umtx_op(addr *uint32, mode int32, val uint32, uaddr1 uinptr, ts
*umtx_time) int32
+func sys_umtx_op(addr *uint32, mode int32, val uint32, uaddr1 uintptr, ts
*__umtx_time) int32
func getPageSize() uintptr {
mib := [2]uint32{_CTL_HW, _HW_PAGESIZE}
However, new undefines appear. With all the errors, has anyone been
successfully in building the go frontend?
[Bug libstdc++/90634] filesystem::path insane memory allocations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90634 Jonathan Wakely changed: What|Removed |Added Target Milestone|9.0 |8.4 --- Comment #6 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #5) > The correct results with 9.1.0 are: > > allocating 21 bytes > allocating 248 bytes > about to quit. total allocated 269 bytes > freed 248 bytes > freed 21 bytes Proof: https://wandbox.org/permlink/zJVe39jAZtL1p6je
[Bug libstdc++/90634] filesystem::path insane memory allocations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90634 --- Comment #5 from Jonathan Wakely --- (In reply to baltic from comment #3) > (In reply to Jonathan Wakely from comment #2) > > > I'm not sure where the repeated 72 allocations come from, and can't check > > the code right now, but the new code doesn't do it anyway. > > It comes from std::string creation, which then is passed to path constructor. No it doesn't, that's the 21 bytes. With GCC 9.x the 72 bytes is sizeof(path), which comes from allocating a path. It comes from each component of the path creating a vector during parsing, and then if there's only one component it empties the vector again. Those transient allocations could be avoided, so I'll change that for GCC 8.4.0, but there's nothing to do for GCC 9.x as it's already avoiding unnecessary vector operations. > > I think this can be considered fixed. > > hardly. the gcc 9.1 is even worse in that regard, as it allocates 2kB of > memory for the same case > see the line: > > about to quit. total allocated 2131 bytes > > in here: > https://wandbox.org/permlink/u9dEfPh1Zc5pmJ34 You should try using a real compiler and not only rely on wandbox. Maybe there's something wrong with the wandbox compiler, but that result only happens when using Boost (so you should take it up with Boost instead). The correct results with 9.1.0 are: allocating 21 bytes allocating 248 bytes about to quit. total allocated 269 bytes freed 248 bytes freed 21 bytes (In reply to baltic from comment #4) > besides the 269 bytes you have mentioned, is still x10 overhead for a 20 > chars string. and massively adds up, if you store a lot objects. The overhead is linear in the number of components in the path, not the string length. If you have a path with a single filename and no directories then the overhead is nothing like 10x. > for example, when i go around home folder on my machine and save all the > found paths to vector, it takes 2.7GB, while should take ~150MB!! quite an > overhead on a simple task, for a language which strives for efficiency. So don't store them as filesystem::path objects then, store them as strings and create a path as needed. > check out clang, for example: > https://wandbox.org/permlink/u9dEfPh1Zc5pmJ34 > it's smart enough to allocate such short strings inplace: > about to quit. total allocated 0 bytes GCC will also create short strings in place, but with a different limit for what is considered "short". GCC's implementation creates the path components eagerly, so that path::iterator meets the requirements of a forward iterator, whereas the libc++ implementation creates them lazily during iteration, and so is not a valid forward iterator. This fails with libc++: https://wandbox.org/permlink/eas3ZqA2CojecrQJ The implementations have different trade-offs. That is not a bug.
[Bug debug/90441] [9/10 Regression] corrupt debug info with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90441 --- Comment #24 from krux --- objdump -dCrS also prints these errors. It definitely fails to find the entry for main which is present according to objdump --dwarf: <1>: Abbrev Number: 8 (DW_TAG_subprogram) DW_AT_external: 1 DW_AT_name: (indirect string, offset: 0x1ab): main DW_AT_decl_file : 1 DW_AT_decl_line : 8 DW_AT_decl_column : 5 DW_AT_type: <0xc3>
[Bug debug/90441] [9/10 Regression] corrupt debug info with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90441 --- Comment #23 from krux --- But it's so fragile, touch any part of the code and the error disappears. Like change serial3_available to void and you also get an additional symbol: 4160 0003 T mainmain.cpp:8
[Bug debug/90441] [9/10 Regression] corrupt debug info with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90441
--- Comment #22 from krux ---
I can also reproduce it without any linker script, simplified code:
int serial3_available() {}
struct HardwareSerial3 {
int available() { serial3_available(); }
};
HardwareSerial3 Serial3;
void yield() { serial3_available(); }
int main()
{
yield();
}
$ g++-9 -c -fno-exceptions -fno-rtti -flto -g -O2 main.cpp
$ g++-9 -o firmware.elf -g -O2 main.o
$ nm -ClS --radix=d --size-sort firmware.elf
4496 0001 T __libc_csu_fininm: DWARF error: could not
find abbrev number 8
00016424 0001 b completed.7374
8192 0004 R _IO_stdin_used
4160 0043 T _start
4400 0093 T __libc_csu_init
But other tools are fine in this case:
$ llvm-dwarfdump-8 --verify firmware.elf
No errors.
$ gdb firmware.elf
Reading symbols from firmware.elf...
[Bug c++/88095] class nontype template parameter UDL string literals doesn't accepts deduction placeholder
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88095
Jeff Snyder changed:
What|Removed |Added
CC||jeff-gcc at caffeinated dot
me.uk
--- Comment #1 from Jeff Snyder ---
I had a go at fixing this, and the following makes Hana's example work:
---8<---
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -27875,7 +27875,8 @@ cp_parser_template_declaration_after_parameters
(cp_parser* parser,
{
tree parm_list = TREE_VEC_ELT (parameter_list, 0);
tree parm = INNERMOST_TEMPLATE_PARMS (parm_list);
- if (CLASS_TYPE_P (TREE_TYPE (parm)))
+ if (CLASS_TYPE_P (TREE_TYPE (parm))
+ || TREE_CODE (TREE_TYPE (parm)) == TEMPLATE_TYPE_PARM)
/* OK, C++20 string literal operator template. We don't need
to warn in lower dialects here because we will have already
warned about the template parameter. */;
--->8---
[Bug libstdc++/90634] filesystem::path insane memory allocations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90634 --- Comment #4 from baltic <1000hz.radiowave at gmail dot com> --- besides the 269 bytes you have mentioned, is still x10 overhead for a 20 chars string. and massively adds up, if you store a lot objects. for example, when i go around home folder on my machine and save all the found paths to vector, it takes 2.7GB, while should take ~150MB!! quite an overhead on a simple task, for a language which strives for efficiency. check out clang, for example: https://wandbox.org/permlink/u9dEfPh1Zc5pmJ34 it's smart enough to allocate such short strings inplace: about to quit. total allocated 0 bytes
[Bug fortran/90539] [10 Regression] 481.wrf slowdown by 25% on Intel Kaby with -Ofast -march=native starting with r271377
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539 --- Comment #26 from Thomas Koenig --- Author: tkoenig Date: Sun May 26 14:02:51 2019 New Revision: 271630 URL: https://gcc.gnu.org/viewcvs?rev=271630=gcc=rev Log: 2019-05-26 Thomas Koenig PR fortran/90539 * trans-types.c (get_formal_from_actual_arglist): Set rank and lower bound for assumed size arguments. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-types.c
[Bug tree-optimization/90637] New: [10 Regression] ICE in vect_loop_versioning, at tree-vect-loop-manip.c:3055
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90637
Bug ID: 90637
Summary: [10 Regression] ICE in vect_loop_versioning, at
tree-vect-loop-manip.c:3055
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, openmp
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
gcc-10.0.0-alpha20190519 snapshot (r271384) ICEs when compiling the following
testcase at any optimization level (except -Og) and w/ -fopenmp --param
sink-frequency-threshold=90:
int vf;
void
pc (void)
{
int xr, b7;
#pragma omp for simd if (xr) lastprivate (vf) schedule (static, 1)
for (b7 = 0; b7 < 1; ++b7)
{
}
}
% gcc-10.0.0-alpha20190519 -O1 -fopenmp --param sink-frequency-threshold=90 -c
wascdsp5.c
during GIMPLE pass: vect
wascdsp5.c: In function 'pc':
wascdsp5.c:4:1: internal compiler error: in vect_loop_versioning, at
tree-vect-loop-manip.c:3055
4 | pc (void)
| ^~
(sorry, no full backtrace this time)
[Bug libbacktrace/90636] New: [libbacktrace] Tests edtest/edtest_alloc/ttest/ttest_alloc are failing on x64 Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90636 Bug ID: 90636 Summary: [libbacktrace] Tests edtest/edtest_alloc/ttest/ttest_alloc are failing on x64 Linux Product: gcc Version: 9.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libbacktrace Assignee: unassigned at gcc dot gnu.org Reporter: romain.geissler at amadeus dot com CC: ian at gcc dot gnu.org Target Milestone: --- Hi, I am trying to build and test gcc from branch gcc-9-branch, and the tests edtest/edtest_alloc/ttest/ttest_alloc are failing always for the same reason: test1: [0]: missing file name or function name I use: - Linux x64 (runtime kernel is a Linux 4.4 Ubuntu, headers against my toolchain is built are from Linux 4.12) - Binutils 2.32 (from git branch binutils-2_32-branch, configured with --enable-compressed-debug-sections=all) - glibc 2.29 (from git branch release/2.29/master) - gcc 9.1.1 20190524 built with PGO + LTO I have tried to remove PGO/LTO build of gcc, as well as removing --enable-compressed-debug-sections=all in binutils, and these test still fail. I have no idea how to investigate this further, nor if I am the only one to have these failures. Cheers, Romain
[Bug debug/90441] [9/10 Regression] corrupt debug info with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90441 Iain Sandoe changed: What|Removed |Added Status|NEW |WAITING --- Comment #21 from Iain Sandoe --- (In reply to krux from comment #20) > Thanks your patch worked! > > Just fyi: llvm-dwarfdump doesn't understand call-site info: > https://bugs.llvm.org/show_bug.cgi?id=41846 > Not sure if it's relevant. So, what's the status here? I think * we conclude that the revision bisected was not actually responsible for the issue underlying (but caused it to be exposed). * llvm-dwarfdump output isn't reliable as an indication of the problem - do you have dwarfdump? - can you use objdump -W ? * we can now -save-temps for the case(s) of interest. * I'm assuming that the problem is not "fixed" ? (have to verified that on current trunk?)
[Bug libstdc++/90634] filesystem::path insane memory allocations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90634 baltic <1000hz.radiowave at gmail dot com> changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED |--- --- Comment #3 from baltic <1000hz.radiowave at gmail dot com> --- (In reply to Jonathan Wakely from comment #2) > I'm not sure where the repeated 72 allocations come from, and can't check > the code right now, but the new code doesn't do it anyway. It comes from std::string creation, which then is passed to path constructor. > I think this can be considered fixed. hardly. the gcc 9.1 is even worse in that regard, as it allocates 2kB of memory for the same case see the line: about to quit. total allocated 2131 bytes in here: https://wandbox.org/permlink/u9dEfPh1Zc5pmJ34
[Bug debug/90441] [9/10 Regression] corrupt debug info with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90441 --- Comment #20 from krux --- Thanks your patch worked! Just fyi: llvm-dwarfdump doesn't understand call-site info: https://bugs.llvm.org/show_bug.cgi?id=41846 Not sure if it's relevant.
[Bug target/88013] can't vectorize rgb to grayscale conversion code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88013 --- Comment #9 from krux --- (In reply to ktkachov from comment #7) > I tried current trunk (future GCC 9) > GCC 9 learned to avoid excessive widening during vectorisation, which is > what accounts for the large number of instructions you see. Confirmed, the loop is now as described in comment #5 with trunk gcc. Still with vshr+vmovn as mentioned by Ramana. But by the way, the tail is completely unrolled, 15x the following, seems quite excessive to me: ldrbip, [r1, #1]@ zero_extendqisi2 movsr6, #151 ldrblr, [r1]@ zero_extendqisi2 movsr5, #77 ldrbr7, [r1, #2]@ zero_extendqisi2 movsr4, #28 smulbb ip, ip, r6 smlabb lr, r5, lr, ip add ip, r3, #1 smlabb r7, r4, r7, lr cmp ip, r2 asr r7, r7, #8 strbr7, [r0] bge .L1 assert(n >= 16) helps a bit, but n % 16 == 0 doesn't.
[Bug libstdc++/90634] filesystem::path insane memory allocations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90634 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.0 --- Comment #2 from Jonathan Wakely --- The 813 bytes seen with GCC 8.x is due to reallocations within std::vector, as the sequence of path objects in [begin(),end()) is populated. The new code counts the number of components first, so there's no need to keep growing as the path is parsed. The sequence no longer uses std::vector at all, which also reduces sizeof(path). I'm not sure where the repeated 72 allocations come from, and can't check the code right now, but the new code doesn't do it anyway. I think this can be considered fixed.
[Bug middle-end/90605] [10 regression] ICE: in gimplify_cond_expr, at gimplify.c:3998
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90605 Rainer Orth changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Rainer Orth --- Fixed by reversal of culprit patch.
[Bug c/90628] __builtin_mul_overflow writes to const qualified integer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90628
--- Comment #2 from Jeremy ---
(In reply to Marc Glisse from comment #1)
> Thanks for the report.
> (next time, please include a complete, compilable example, with the
> #includes, int main, etc)
Sorry, here is a complete program:-
#include
int
main( int argc, const __attribute__ ((unused)) char *argv[] )
{
const int a = argc;
const int b = argc;
if( __builtin_mul_overflow( a, b, ) )
puts( "overflow" );
printf( "square = %d\n", a );
}
[Bug ada/90624] nt_spawnve may use stack variable escape_char uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90624 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-05-26 CC||ebotcazou at gcc dot gnu.org Summary|nt_spawnve() may use stack |nt_spawnve may use stack |variable escape_char|variable escape_char |uninitialized (in |uninitialized |gcc/ada/terminals.c)| Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou --- Suspicious indeed.
[Bug libstdc++/90634] filesystem::path insane memory allocations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90634 --- Comment #1 from Jonathan Wakely --- The path type was rewritten for GCC 9, and now prints: allocating 21 bytes allocating 248 bytes about to quit. total allocated 269 bytes freed 248 bytes freed 21 bytes The 21 bytes is for the native() string, and 248 bytes is the sequence of path objects in the range [begin(),end()).
